要約: 先週最もホットなトピックは、間違いなく ZKsync の公開エアドロップ検証インシデントでした。当初、著者は TON の DApp 開発に関する学習体験を研究し、執筆していましたが、この物議を醸すインシデントを見て、コミュニティでの広範な議論を引き起こしました。という感想があったので、それを皆さんにも共有できればと思い記事を書きました。一般に、ZKSync のエアドロップ計画は所有権の証明に基づいた配布方法を採用しており、開発者、コアコントリビューター、および ZKSync の在来種のデゲンクジラへの報酬に重点を置いており、これにより、在来種のデゲンクジラが笑っているような状況が生じています。呼んでいる。
長い間、Web3 業界は、Airdrop を通じてユーザーを製品の使用に引き付けるパラダイムを形成してきたようです。プロジェクトのコールドスタート。これは特にレイヤー 2 トラックに当てはまります。潜在的なエアドロップに対する開発者とユーザーの期待を誘導することで、開発者は積極的に DApp を構築して維持するように刺激され、同時にユーザーは開発の初期段階でターゲットのレイヤー 2 に積極的に資金をブリッジするように刺激されます。ターゲットのレイヤー 2 で実行されるプロジェクトに参加します。DApp は、エコロジーを活性化するという目的を果たし、標準になりました。
つまり、これまでは、ZKSync のエアドロップに対するユーザーの期待は、一般に、直接の競合相手である Arbitrum と Optimism の 2 社に基づいていました。もちろん、業界の影響力、ベンチャーキャピタルの背景、資金調達規模などの観点から見ても、この結論は論理的です。しかし、結果は大きく異なり、過去の経験を再利用して ZKSync に参加する多くのユーザーにつながります。システム内で期待どおりの報酬が得られるかどうかについては、コミュニティ内で広範な議論が巻き起こっています。
この論争の背後にある理由を調査し、将来への参考となる影響について議論するには、Arbitrum と Optimism の以前のエアドロップ ルール設定を見直すのは当然のことです。まず、2023 年 3 月に遡る Arbitrum のエアドロップ活動を振り返ってみましょう。Arbitrum のエアドロップ総供給量の 11.62% が Aribitrum ユーザーに割り当てられ、Arbitrum のエアドロップの 1.13% が Arbitrum エコシステムで実行されている DAO に割り当てられました。エアドロップアクティビティの設定は、2023 年 2 月 6 日のスナップショット データに基づいています。ユーザーに対する特定のルールは次のとおりです:
各ルールには特定のスコア計算方法があり、スコアの上限は 15 ポイントであり、このスコアはユーザーが受け取ることができる Arb の数を決定するために使用され、線形関係として近似できます。ただし、開始報酬は3ポイントから始まり、上限報酬は10,200Arbです。 DAOの報酬については、活動評価方法に基づいて直接決定され、最終的に137のDAOがエアドロップを受け取り、そのうちTreasureとGMXがそれぞれ800万Arbを最も多く受け取りました。それは本当に大きな利益です。
次に、Optimism について見てみましょう。Arbitrum とは異なり、Optimism のエアドロップは複数のラウンドで実行され、配布された報酬の総数は 2022 年 6 月まで遡ることができます。合計 5% の報酬が 260,000 のアドレスに配布されました。これまでに 4 ラウンドのエアドロップが実施されました。各ラウンドのエアドロップの具体的なルールは次のとおりです。
上記のレビューから、インタラクションの数が次のように使用されることを見つけるのは難しくありません。特定のアクティビティ設定における重要な参照指標。一般に、より頻繁に対話するユーザーはより大きな報酬を受け取ります。ただし、この暗黙のルールは ZKSync によって放棄されたようです。ZKSync のエアドロップ設計では、ZKsync ユーザーの資格と割り当ては 4 つの連続したステップに分けて選択および計算されます。具体的なルールは次のとおりです。
特定のルールから、インタラクションの数は報酬の計算に関係しておらず、単一アカウント内の資金の量とリスク資産を割り当てる意欲に重点を置いていることがわかります。したがって、結果が発表されたとき、過去の経験に依存し、ZKSync で頻繁にやり取りしていた多くのファンやスタジオはショックを受けました。これが論争全体の原因でもありました。潜在的なエアドロップを受け取るアドレスの数を増やすために、このユーザー グループは通常、大きな資金をできる限り複数のアドレス グループに分散することを選択します。これらのアドレス グループは通常、数百、さらには数千であり、特定のグループに参加するために少額の資金を使用します。考えられるいくつかのインセンティブ行動を決定し、自動化されたスクリプトまたは手動の方法を通じて頻繁に対話し、潜在的な利益を高めるためにタスクを完了します。 ZKSync のエアドロップ設定により、この戦略は無効になります。頻繁にやり取りする多くのアドレスが支払う手数料は、受け取った報酬よりもさらに高額であり、このグループの人々の間で当然のことながら不満が生じます。
そして、この状況を変えることを期待して、メディアはZKSync関係者に圧力をかけました。しかし、公式の態度を見る限り、彼らも非常に厳しいものであり、圧力に耐えてルールを変更しなかったため、現在の状況が起こっているようです。議論によって引き起こされたいくつかの潜在的な邪悪な行為に対する非難と正当化は、この世論戦のハイライトです。
結果から判断すると、双方の訴えは理解できるように思えますが、善悪はどのような角度から議論するかしかありませんが、考えるべきことはいくつかあると思います。 Web3 プロジェクトの段階 コア バリュー ユーザーは誰か、またはコールド スタート段階でどのような種類のユーザーに動機を与える必要があるか。
早期参加者向けのエアドロップ報酬は、Web3 プロジェクトの効果的なコールドスタート方法であることが証明されています。優れたエアドロップメカニズムの設定は、プロジェクトがシードを引き付けるのに役立ちます。初期段階で効率的にユーザーをサポートし、同時にプロトコルの主要な動作をユーザーに使用させることでユーザー教育を完了し、製品の粘着性を高めます。これは、長い間、ほとんどの Web3 プロジェクトのエアドロップ設定がインタラクティブな行動を動機付けることに焦点を当ててきた根本的な理由でもありますが、これにより報酬を獲得するための敷居が低くなり、活動が容易になるという欠点がありました。魔女の襲撃に遭遇する。インタラクティブな動作は自動化およびバッチ化が容易なため、多くの専門チームにバッチ操作の余地が与えられます。大量のロボット アカウントが流入すると、プロトコルは一時的には偽りの繁栄をもたらしますが、これらの「ユーザー」は通常、徐々に生き続けます。それだけでは、プロジェクトの将来の発展に原動力を与えることはできません。報酬を受け取った後、そのほとんどは資金回転率を高めるために現金化され、それによって利益が増加します。本当に価値のあるユーザーを失う価値はありません。
では、なぜこのメカニズムが初期にうまく機能したのでしょうか? これは当然のことですが、当時はほとんどのユーザーがこのインセンティブ メカニズムについて考える習慣がまだ形成されておらず、インタラクティブな動作が行われていたためです。まだ比較的純粋な実際のユーザーに属しているため、これらのユーザーにインセンティブをより効率的に分配することができ、結果として生じる富効果もプロジェクト当事者が上記の利益を達成するのに役立ちます。実際のユーザーを効果的に引き付けることは明らかに不可能です。私の個人的な感想の 1 つは、主なインセンティブ オブジェクトとしてインタラクションを伴うエアドロップ活動の有効性は、Arbitrum エアドロップの時点までに基本的にピークに達しているということです。
これは、ZKSync が資産の相対的なサイズに基づいて価値のあるユーザーを識別するための基礎としてインタラクション番号の使用を放棄したい根本的な理由でもあります。ただし、この資産証明方法には問題がないわけではありません。魔女の攻撃のリスクはより効果的に特定して排除することができますが、それに伴う新たな問題は、独占によって引き起こされる富の不均等な分配です。
Web3 プロジェクトの中核となる価値の 1 つは、ボトムアップの分散型自律性モデルであることを私たちは知っています。これは、草の根ユーザー（少額の資本を持つ実際のユーザー）のサポートがプロジェクトの発展の基礎であることを意味します。結局のところ、一部のクジラ ユーザーが注力し、より持続可能な開発形態を形成できるのは、草の根ユーザーが十分に存在する場合にのみです。十分に大きい。そうなると、所有権証明書の配布システムは、コールドスタートの初期段階でクジラ利用者に明らかな利益をもたらすことになり、草の根利用者にとって効果的なインセンティブを形成することが難しくなり、当然のことながらまとまりを形成することは不可能となる。コミュニティ。
最終的な分析として、Web3 プロジェクトの場合、コールド スタート メカニズムを設計するときは、製品にとって価値のあるユーザー プロファイルを慎重に検討し、上記のモチベーションを効果的に高めるために、現在の環境に基づいて対応するメカニズムを設計する必要があります。同時に、魔女の攻撃を可能な限り避けることが最優先です。したがって、独自のコールド スタート メカニズムを設計する方法は非常に貴重なトピックであり、ディスカッションのために私の X にメッセージを残していただければ幸いです。楽しいオプションを一緒にブレインストーミングしてみましょう。
X リンク: https://x.com/web3_mario
以上がZKSync エアドロップが物議を醸した、Web3 プロジェクトのコールド スタートのジレンマを見てみましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
