エディ・ラザリン著編集: シシ**序章：****a16z は、暗号化分野で重要な地位を確立し、詳細な記事で業界の発展を導き、認知機能の向上と変革に必要な指針を提供してきました。最近、a16z はトークンエコノミーを超えた問題に焦点を当てています。 「トークン設計」に関する講演から始まり、「トークン学：トークン経済学を超えて」、そして待望の「プロトコル設計」コースが続きました。コースの講師として、a16z cryptoのCTOであるEddy Lazzarin氏は、トークンエコノミーを超える鍵はプロトコル設計にあり、トークン設計は補助的な手段にすぎないと繰り返し強調しました。プロトコル設計に焦点を当てたこのコースで、彼は 1 時間以上にわたって貴重な洞察と啓発を起業家にもたらし、プロジェクトの成功におけるプロトコル設計の重要な役割を深く理解するのに役立ちました。この記事はその簡易翻訳です。さらにエキサイティングなコンテンツについては、翻訳の全文バージョンへのリンクをご覧ください。 **### **プロトコル進化の固有の法則**#### **インターネット プロトコル: 相互作用の絆****インターネットは、さまざまな種類のプロトコルを含むプロトコル ネットワーク**です。 HTTP の状態図のように簡潔なプロトコルもあれば、Maker プロトコルの相互作用図など非常に複雑なプロトコルもあります。以下の図は、インターネット プロトコル、物理プロトコル、政治プロトコルなどのさまざまなプロトコルを示しています。下の画像の左側には、交差点のインタラクティブな地図が表示されています。これは私たちにとって見慣れた興味深いものです。これらのプロトコルに共通するのは、プロトコルの核となるコンポーネントである複雑なグループの行動を促進する、形式化された対話型システムであることです。インターネット プロトコルの威力は、人間と人間のやり取りだけでなく、ソフトウェアも接続できることにあります。私たちは、ソフトウェアが適応性と効率性が高く、メカニズムを統合できることを知っています。そのため、インターネット プロトコルは、最も重要ではないにしても、おそらく最も重要なタイプのプロトコルの 1 つです。#### **プロトコルの進化: Web1 - Web2 - Web3**以下のグラフでは、横軸はプロトコルの分散化と集中化の度合い、つまりプロトコルの制御の度合いを表しています。縦軸には合意された経済モデルがあり、特に経済モデルが明示的であるか不特定であるかを示しています。この違いは微妙に見えるかもしれませんが、重要な意味を持っています。**Web1: 分散型で明確な経済モデルがない**Web1 時代のプロトコル (NNTP、IRC、SMTP、RSS など) は、明確な経済モデルがなく、価値の流れ、所有権、アクセス権、支払いメカニズムの点で中立的でした。その中で、Usenet は、投稿やファイルを交換するための今日の Reddit に似たプロトコルです。 IRC は初期に広く使用されていたチャット プロトコルで、SMTP と RSS は電子メールとコンテンツの購読に使用されました。Usenet は、ユーザーが特定のカテゴリのサブサーバーに関連するコンテンツを投稿できるようにする、分類法で構成されたプラットフォームです。これは初期のインターネット文化の重要な部分であり、HTTP の外部に存在していました。 Usenet を使用するには、特定のクライアントと Usenet をサポートするインターネット サービス プロバイダー (ISP) が必要です。 Usenet は、誰でも実行できる、常に変化する多数のニュース サーバーに分散されており、投稿は自動的に他のサーバーに転送され、分散システムを形成します。ユーザーが Usenet へのアクセス料金を直接支払うことはめったにありませんが、2000 年代後半には商用 Usenet サーバーの料金を支払い始めた人もいます。全体として、Usenet には明確なプロトコル経済モデルが欠けており、ユーザーは独自のトランザクションを通じてそれを使用する必要があります。これらの Web1 プロトコルはアーキテクチャ的に類似しており、同じ値から派生しています。プロトコルに関する知識がほとんどなくても、プロトコルがどのように機能するかを理解することができます。これは、**Web1 プロトコルの読みやすさと明確なテンプレートの重要性を示しています。 **ただし、これらのプロトコルは時間の経過とともに徐々に失敗や変更に直面してきました。失敗の理由は 2 つの側面に起因すると考えられます: 1 つは特定の機能が欠如しており、Web2 の競合他社と競合できないこと、2 つ目は資金調達が困難であることです。 **最終的に、プロトコルの成功は、分散型アプローチを採用し、特定の機能を組み込む持続可能な経済モデルを開発できるかどうかにかかっています**。要約すると、Web1 プロトコルは分散型として分類でき、明確な経済モデルがありません。**Web2: 集中化と明確な経済モデル**Web2 は興味深い傾向をもたらしました。Reddit が Usenet などのフォーラムに取って代わり、WhatsApp や iMessage などの集中メッセージング システムが IRC などのフォーラムに取って代わりました。電子メールはまだ存在しますが、スパムの問題に直面しています。また、RSS は Twitter とあまり競合しませんでした。 **Web2 は Web1 プロトコルの制限に対処し、特定の機能を提供します。 ** 電子メールやその他の分散型プロトコルでは、メッセージの正当性、送信者の身元、権限、経済的関係を検証できないため、スパムへの対処が問題になります。未成熟な分散システムでは、これらの機能がないため、集中型の競合他社が独自の機能を提供することで以前のシステムを上回るパフォーマンスを発揮できます。**Web2 プロトコルは完全に所有者の管理下にあり、ビジネス ポリシーと法律によってのみ制限されます。 **Web1 プロトコルの開発を推進するには、より明確な経済モデルが必要です。しかし、分散型コンセンサス、検証可能なコンピューティング、および暗号化技術ツールを活用せずに、分散型を維持しながら明確な経済モデルを達成することは不可能です。 **契約は通常、設計領域の左下隅から右上隅まで移行します。電子メールなど、プロトコルが事実上集中化される場合があります。電子メールの 50% 以上が集中型電子メール サービス プロバイダーによって処理されており、電子メールは高度に一元化されています。電子メールは、スパム問題、経済モデルの欠如、DNS 登録コストの共有、高額なスイッチング コストなどのプレッシャーにさらされています。実行可能な経済モデルが存在しない場合、電子メールは大手テクノロジー企業のサイドプロジェクトとしてのみ持続可能です。スパムを削減する方法は規模の経済とデータ バインディングに依存しており、数百万の電子メール アカウントをホストする企業にとっては、異常を検出することが容易になります。さらに、スイッチングコストも重要な要素です。ここで、プロトコルのさまざまなコンポーネントに影響を与える **2 つの重要な集中力**を認識する必要があります。これらはプロトコル設計プロセスのあらゆる段階で常に作用しており、ネットワーク効果とスイッチング コストです。 ****ネットワーク効果は、システムが拡張され、広く使用されるにつれて電力が蓄積する現象です。切り替えコストとは、ユーザーが現在のシステムを離れて別のシステムに切り替えるために必要な経済的、認知的、または時間的なコストを指します。 **電子メールの例では、Gmail を使用するユーザーにとってスイッチング コストは非常に重要です。 Gmail を使用していても独自ドメインを持っていない場合、切り替えコストが高くなります。ただし、独自のドメイン名を所有している場合は、メール サービス プロバイダーを自由に切り替えて、引き続き任意のサービス プロバイダーを使用してメールを受信できます。企業は、プロトコル設計を通じてユーザーに特定のコンポーネントの使用を強制または奨励することでスイッチング コストを増加させることができ、それによってユーザーが他のサプライヤーに切り替える可能性が低くなります。Reddit を例に挙げると、モデレータがサブフォーラムを一方的に制御できるシステムであり、分散化と集中化の境界があいまいになります。誰でもモデレーターになれるのは分散化の一形態と見なされるかもしれませんが、最終的な権限が管理者 (Reddit チームなど) の手に残っている場合は、完全に集中化されたシステムであることに変わりはありません。高品質のユーザー エクスペリエンスは中央集権とは何の関係もありませんが、高品質のユーザー エクスペリエンスを提供するには財政的な支援が必要になることがよくあります。 ** Web1 の時代では、資金不足のため、分散型プロトコルでは優れたユーザー エクスペリエンスを提供できないことがよくあります。 **高品質のユーザー エクスペリエンスを提供するには、資金が重要な役割を果たします。**Web3: 分散化された明確な経済モデル****Twitter、Facebook、Instagram、TikTok などの Web2 プラットフォームでは、プラットフォームのインターフェイスの決定に従い、ユーザーの選択肢は限られています。 **しかし、Web3 によって導入された分散コンポーネントはプロトコルをどのように変更するのでしょうか?暗号化とブロックチェーン技術を利用すると、経済性を明確にして分散化をサポートしながら、信頼への依存を減らすことができます。 **Web3 は、明確な経済モデルを備えたオープン性、相互運用性、オープンソースを提供し、プロトコルに資金を統合して持続可能な開発を達成し、すべての価値の独占を回避する機能を提供します。 ****開発者としては、明確な経済モデルを備えた分散システム上に構築することを選択することが最善の選択です。 **この方法**により、協定外で経済関係を発展させることなく、システムの存続が保証され、それに関連する経済関係が理解されます。 ** 安定性と価値の獲得の観点からは、これは別の方法で検討する必要があります。分散システム上に構築することを選択することは、潜在的なリスクを回避し、耐久性があり、可能な限り最大のシステムになる可能性のあるプロジェクトを構築するため、重要です。インターネット自体は完全に分散型システムであるため、インターネットの構築はもはや狂気の行為とはみなされません。同様に、オープンソース プログラミング言語の使用と Web ブラウザーへの依存は、野心的なプロジェクトを構築するための強固な基盤となっています。集中システム上での構築には制限があり、プロジェクトの規模と範囲が妨げられる可能性があります。 Web3 には、より大規模で野心的なプロジェクトを構築できる優れた開発者が集まります。他のシステムまたはプラットフォームが出現して、既存の Web2 プラットフォームと競合し、規制を遵守して競争上の優位性を持ち、Web2 プラットフォームと激しく競争する可能性があります。**Web2 ネットワークの最大の問題は、その脆弱性と過剰に最適化されたビジネス モデルです。これらのネットワークは、目標に関係のないものを無視して特定の指標の最適化を追求するため、イノベーションや新製品の開発が欠如します**。独占を形成するほどではない強力なネットワーク効果を持っていますが、弱点への対抗策には脆弱です。対照的に、**Web3 は、分散化と明確な経済モデルを通じて、より回復力があり革新的なスペースを提供します。 **豊かで多様な熱帯雨林の生態系と同様に、Web3 システムはあらゆる種類の興味深いものの開発に適したインフラストラクチャとプロトコルを確立し、イノベーションのためのより肥沃な土壌を提供します。暗号通貨とトークン経済モデルを活用することで、参加者は創造性とリスクテイクが報われ、システムの開発が促進されることが保証されます。したがって、**Web3 は、経済資源の蓄積のみに依存するのではなく、より優れたエコシステムの持続可能性とイノベーションの可能性を備えています。 **明確な経済モデルと分散化機能により、Web3 は単一分野への過剰な最適化と集中的な蓄積の苦境から逃れ、真の意味でのイノベーションと発展を実現します。暗号化技術とトークンエコノミーモデルを導入することで、Web3 は参加者により大きな創造的なスペースとリターンメカニズムを提供し、より価値のある永続的な方向へのシステムの開発を促進します。### **Web3 プロトコルの設計ケース**#### **ケースの背景と設計目標**興味深い例から始めましょう。「Stable Horde」は、画像と Web2 プロトコルを生成するための無料システムです。これは、ユーザーが画像の生成を手伝ってくれる他の人に依頼できる共同レイヤー機能を使用します。クライアントはタスクをワークキューに送信し、ワーカーは推論処理を実行して結果を結果ストレージに送信します。クライアントはそこから結果を取得して、ワーカーに Kudos ポイントを支払うことができます。 Stable Horde では、Kudos はタスクに優先順位を付けるために使用される無料ポイント システムです。ただし、キューが長くなると、コンピューティング リソースの寄付の制限により、イメージの生成にかかる時間が長くなります。私たちは興味深い問題に直面しました。それは、プロジェクト本来の精神を破壊する集中化の危険を冒さずに、オープン性と相互運用性を維持しながら、このシステムを拡張してより大きく専門化する方法です。 **提案の 1 つは、Kudos スコアを ERC20 トークンに変換し、ブロックチェーンに記録することです。しかし、単にブロックチェーンを追加するだけでは、偽結果攻撃など一連の問題が発生する可能性があります。プロトコル設計プロセスを再考してみましょう。 **常に明確な目標から始めて、次に制約を考慮し、最後にメカニズムを定義する必要があります。 **システムを設計するには、目標を測定し、効果的なメカニズムを特定する必要があります。制約には内因性と外因性の形式があり、設計範囲を制限することでメカニズムをより明確に特定できます。メカニズムは、清算、価格設定、ステーキング、インセンティブ、支払い、検証などのプロトコルの本体です。設計は制約内に収まり、明確に定義された目標を達成する必要があります。**Web3プロトコル例：不安定錯乱**「Unstable Confusion」と呼ばれるまったく新しい Web3 プロトコルに移りましょう。以下では、既存の Web2 プロトコル「Stable Horde」を Web3 プロトコル「Unstable Confusion」に変換するというコンテキストで提案されているいくつかの興味深い方向性について概説します。前述したように、**誤った結果を送信することには問題があるため、ユーザーが必要なものを確実に取得できるメカニズムが必要です**。これは「検証推論」と呼ばれます。簡単に言うと、推論を検証して、その結果が期待どおりであることを確認する必要があります。もう一つの問題は、「Stable Horde」の労働者に関するものです。ワーカーは、要求された順序でデータベースに次のタスクをリクエストし、最も早くリクエストを行ったワーカーにタスクを割り当てます。しかし、お金が関係するシステムでは、**労働者**はより多くの報酬を得るために大量のタスクを要求する可能性がありますが、実際にはタスクを完了するつもりはありません。これらは低遅延を求めて競合し、タスクを取得し、システムの輻輳を引き起こす可能性があります。 **上記の問題を解決するために、いくつかの解決策が提案されている。 1 つ目は、ネットワークにとって有益な方法でタスクを競い合い、従業員の貢献に応じて報酬が支払われる「貢献に比例した支払い」です。 **2 つ目は**「柔軟な参加」です。つまり、従業員が低コストでシステムに自由に参加または退出できるため、より多くの参加者が集まります。 **最後に** 「低遅延」、つまりアプリケーションの応答性と速度がユーザー エクスペリエンスにとって重要です。 ** 私たちの目標に戻りますが、画像生成のための分散型で相互運用可能なマーケットプレイスを構築することです。まだ重要な制約がいくつかありますが、これらは後で追加、変更、またはより具体的な詳細が追加される可能性があります。これで、さまざまなメカニズムの実現可能性を評価できるようになりました。**潜在的なメカニズムの設計****1. 検証メカニズム**ゲーム理論や暗号学などの手法を使用して、推論の正確さを確保できます。ゲーム理論のメカニズムは紛争解決システムで使用でき、ユーザーは紛争をエスカレートし、特定の役割によって仲裁されることができます。継続的監査またはサンプル監査は、従業員の作業をレビューし、タスクが別の従業員に割り当てられていることを確認し、どの従業員が監査に合格したかを記録することによるもう 1 つのアプローチです。暗号におけるゼロ知識証明は、推論の正しさを検証するための効率的な証明を生成できます。従来の方法には、信頼できる第三者機関やユーザーのレビューが含まれますが、集中化のリスクとネットワーク効果があります。他に考えられる検証メカニズムには、複数の作業者に同じタスクを完了させ、その結果からユーザーが選択することが含まれます。これにはコストがかかるかもしれませんが、コストが十分に低い場合は、アプローチとして検討できます。**2. 価格戦略**価格設定戦略に関しては、オーダーブックをオンチェーンで確立できます。ガスなど、オンチェーンの検証可能なコンピューティング リソース プロキシ メトリクスを使用することもできます。このアプローチは、単純な自由市場とは異なります。そこでは、ユーザーが推論に対して支払ってもよい金額を投稿するだけで、作業者はそれを受け入れることができ、タスクを競うために入札することもできます。代わりに、ユーザーは、特定の推論に一定量のコンピューティング リソースが必要となり、コンピューティング リソースの量が価格を直接決定するガスのようなプロキシ メトリックを作成できます。これにより、機構全体の動作を簡素化することができる。あるいは、オフチェーンのオーダーブックを使用することもできます。これは、運営コストが低く、非常に効率的である可能性があります。ただし、問題は、その注文帳の所有者がネットワーク効果を自分自身に集中させる可能性があることです。**3. 収納機構**作業の結果がユーザーに正しく提供されることを保証するために、保存メカニズムは非常に重要ですが、信頼のリスクを軽減し、作業が正しく提供されたことを証明することは困難です。ユーザーは、期待した商品が届かないことについて苦情を言うのと同様に、商品が配達されたかどうかを疑問に思うことがあります。監査人は計算プロセスを検証し、出力結果の正確性をチェックする必要がある場合があります。したがって、出力はプロトコルに表示され、プロトコルがアクセスできる場所に保存される必要があります。ストレージメカニズムに関しては、いくつかのオプションがあります。 1 つはデータをオンチェーンに保存することですが、これにはコストがかかります。もう 1 つのオプションは、専用のストレージ暗号化ネットワークを使用することです。これはより複雑ですが、ピアツーピア方式で問題を解決しようとします。あるいは、データをオフチェーンに保存するという選択肢もありますが、そのストレージ システムを管理する人が検証プロセスや最終的な支払いの送信などの他の側面に影響を与える可能性があるため、これにより別の問題が生じます。**4. タスク割り当て戦略**タスクの分散方法も考慮する必要がありますが、これは比較的複雑な領域です。タスクのサブミット後にワーカーが自らタスクを選択することも考えられるし、タスクのサブミット後にアグリーメントによりタスクを配布することも考えられ、ユーザーやエンドユーザーに特定のワーカーを選択させることも可能である。それぞれのアプローチには長所と短所があり、どのワーカーがどのタスクをリクエストできるかをプロトコルが決定する方法の組み合わせも検討してください。タスクの割り当てには、多くの興味深い詳細が含まれます。たとえば、プロトコルベースのシステムでは、ワーカーにタスクを割り当てるかどうかを決定するために、ワーカーがオンラインで対応可能かどうかを知る必要があります。各作業者の能力と負荷も把握する必要があります。したがって、プロトコルではさまざまな追加要素を考慮する必要がありますが、初期の単純な実装には含まれていない可能性があります。#### **分散型プロトコル設計の重要なポイント****集中化のリスクにつながる可能性のある 7 つの重要な設計要素**これらには、電子メール、支払いシステム、評判、ストレージ、マッチング、価格設定システム、検証システムによって導入されたスペースの名前付けが含まれます。これらの要素は、ネットワーク効果や高いスイッチング コストにより集中化される可能性があります。ネットワーク効果の蓄積を緩和し、ネットワーク効果をプロトコルに取り込み、分散制御層をプロトコルに構築することでプロトコルを管理し、システムの長期的な健全性を確保します。分散型制御は、揮発性トークンや、評判システムや輪番選出メカニズムなどの他のガバナンス設計を使用して実現できます。**スイッチング コストを削減し、相互運用性を促進します**起業家がシステム上にアプリケーションを構築することを奨励するには、スイッチング コストを削減し、異なるシステム間の相互運用性を促進することが重要です。高額なスイッチングコストの導入を回避し、オフチェーンのオーダーブックやサードパーティの検証システムへの過度の依存を減らします。**Web3 テクノロジーを使用して分散システムを作成**Web3 のツールと原則を活用して、起業家に力を与え、過度の集中化を回避するシステムを設計します。 Web3 原則を採用したプロトコルは通常、より大規模で、より長寿命で、より活気に満ちたエコシステムの活力を備えており、最大手の既存企業が設定した境界を超えて革新的な探索の肥沃な領域を提供します。**綿密な調査と最適なソリューションの選択**プロトコルを設計して戦略を決定するときは、さまざまな側面を詳しく検討する必要があります。認証には、通常、暗号化ソリューションが最良の選択です。価格設定の点では、オンチェーンの検証可能なコンピューティング リソースを使用するプロキシ メトリクスは、さまざまな推論タスクや機械学習タスクに適応できます。タスクの割り当てに関しては、作業者の能力やステータスをリアルタイムに更新するプロトコルを採用し、タスクを公平に配分し、作業者がタスクを受け入れるかどうかを自主的に選択できるようにしています。ストレージの問題については、プロトタイプシャーディングテクノロジーなどのソリューションを検討して、短期間で問題を解決し、一時的なストレージ方法を採用することができます。分散システムを設計する場合、上記の考慮事項は、長期的な堅牢性と分散特性を備えたシステムを構築するのに役立ちます。原文：Protocol design: Why and how翻訳された全文バージョンへのリンク:
a16z暗号化起業コース：「トークン設計」に続いて「プロトコル設計」を開始
エディ・ラザリン著
編集: シシ
序章：
**a16z は、暗号化分野で重要な地位を確立し、詳細な記事で業界の発展を導き、認知機能の向上と変革に必要な指針を提供してきました。最近、a16z はトークンエコノミーを超えた問題に焦点を当てています。 「トークン設計」に関する講演から始まり、「トークン学：トークン経済学を超えて」、そして待望の「プロトコル設計」コースが続きました。コースの講師として、a16z cryptoのCTOであるEddy Lazzarin氏は、トークンエコノミーを超える鍵はプロトコル設計にあり、トークン設計は補助的な手段にすぎないと繰り返し強調しました。プロトコル設計に焦点を当てたこのコースで、彼は 1 時間以上にわたって貴重な洞察と啓発を起業家にもたらし、プロジェクトの成功におけるプロトコル設計の重要な役割を深く理解するのに役立ちました。この記事はその簡易翻訳です。さらにエキサイティングなコンテンツについては、翻訳の全文バージョンへのリンクをご覧ください。 **
プロトコル進化の固有の法則
インターネット プロトコル: 相互作用の絆
インターネットは、さまざまな種類のプロトコルを含むプロトコル ネットワークです。 HTTP の状態図のように簡潔なプロトコルもあれば、Maker プロトコルの相互作用図など非常に複雑なプロトコルもあります。以下の図は、インターネット プロトコル、物理プロトコル、政治プロトコルなどのさまざまなプロトコルを示しています。下の画像の左側には、交差点のインタラクティブな地図が表示されています。これは私たちにとって見慣れた興味深いものです。
これらのプロトコルに共通するのは、プロトコルの核となるコンポーネントである複雑なグループの行動を促進する、形式化された対話型システムであることです。インターネット プロトコルの威力は、人間と人間のやり取りだけでなく、ソフトウェアも接続できることにあります。私たちは、ソフトウェアが適応性と効率性が高く、メカニズムを統合できることを知っています。そのため、インターネット プロトコルは、最も重要ではないにしても、おそらく最も重要なタイプのプロトコルの 1 つです。
プロトコルの進化: Web1 - Web2 - Web3
以下のグラフでは、横軸はプロトコルの分散化と集中化の度合い、つまりプロトコルの制御の度合いを表しています。縦軸には合意された経済モデルがあり、特に経済モデルが明示的であるか不特定であるかを示しています。この違いは微妙に見えるかもしれませんが、重要な意味を持っています。
Web1: 分散型で明確な経済モデルがない
Web1 時代のプロトコル (NNTP、IRC、SMTP、RSS など) は、明確な経済モデルがなく、価値の流れ、所有権、アクセス権、支払いメカニズムの点で中立的でした。その中で、Usenet は、投稿やファイルを交換するための今日の Reddit に似たプロトコルです。 IRC は初期に広く使用されていたチャット プロトコルで、SMTP と RSS は電子メールとコンテンツの購読に使用されました。
Usenet は、ユーザーが特定のカテゴリのサブサーバーに関連するコンテンツを投稿できるようにする、分類法で構成されたプラットフォームです。これは初期のインターネット文化の重要な部分であり、HTTP の外部に存在していました。 Usenet を使用するには、特定のクライアントと Usenet をサポートするインターネット サービス プロバイダー (ISP) が必要です。 Usenet は、誰でも実行できる、常に変化する多数のニュース サーバーに分散されており、投稿は自動的に他のサーバーに転送され、分散システムを形成します。ユーザーが Usenet へのアクセス料金を直接支払うことはめったにありませんが、2000 年代後半には商用 Usenet サーバーの料金を支払い始めた人もいます。全体として、Usenet には明確なプロトコル経済モデルが欠けており、ユーザーは独自のトランザクションを通じてそれを使用する必要があります。
これらの Web1 プロトコルはアーキテクチャ的に類似しており、同じ値から派生しています。プロトコルに関する知識がほとんどなくても、プロトコルがどのように機能するかを理解することができます。これは、**Web1 プロトコルの読みやすさと明確なテンプレートの重要性を示しています。 **ただし、これらのプロトコルは時間の経過とともに徐々に失敗や変更に直面してきました。失敗の理由は 2 つの側面に起因すると考えられます: 1 つは特定の機能が欠如しており、Web2 の競合他社と競合できないこと、2 つ目は資金調達が困難であることです。 最終的に、プロトコルの成功は、分散型アプローチを採用し、特定の機能を組み込む持続可能な経済モデルを開発できるかどうかにかかっています。要約すると、Web1 プロトコルは分散型として分類でき、明確な経済モデルがありません。
Web2: 集中化と明確な経済モデル
Web2 は興味深い傾向をもたらしました。Reddit が Usenet などのフォーラムに取って代わり、WhatsApp や iMessage などの集中メッセージング システムが IRC などのフォーラムに取って代わりました。電子メールはまだ存在しますが、スパムの問題に直面しています。また、RSS は Twitter とあまり競合しませんでした。 **Web2 は Web1 プロトコルの制限に対処し、特定の機能を提供します。 ** 電子メールやその他の分散型プロトコルでは、メッセージの正当性、送信者の身元、権限、経済的関係を検証できないため、スパムへの対処が問題になります。未成熟な分散システムでは、これらの機能がないため、集中型の競合他社が独自の機能を提供することで以前のシステムを上回るパフォーマンスを発揮できます。
**Web2 プロトコルは完全に所有者の管理下にあり、ビジネス ポリシーと法律によってのみ制限されます。 **Web1 プロトコルの開発を推進するには、より明確な経済モデルが必要です。しかし、分散型コンセンサス、検証可能なコンピューティング、および暗号化技術ツールを活用せずに、分散型を維持しながら明確な経済モデルを達成することは不可能です。 **契約は通常、設計領域の左下隅から右上隅まで移行します。電子メールなど、プロトコルが事実上集中化される場合があります。電子メールの 50% 以上が集中型電子メール サービス プロバイダーによって処理されており、電子メールは高度に一元化されています。電子メールは、スパム問題、経済モデルの欠如、DNS 登録コストの共有、高額なスイッチング コストなどのプレッシャーにさらされています。
実行可能な経済モデルが存在しない場合、電子メールは大手テクノロジー企業のサイドプロジェクトとしてのみ持続可能です。スパムを削減する方法は規模の経済とデータ バインディングに依存しており、数百万の電子メール アカウントをホストする企業にとっては、異常を検出することが容易になります。さらに、スイッチングコストも重要な要素です。ここで、プロトコルのさまざまなコンポーネントに影響を与える 2 つの重要な集中力を認識する必要があります。これらはプロトコル設計プロセスのあらゆる段階で常に作用しており、ネットワーク効果とスイッチング コストです。 **
**ネットワーク効果は、システムが拡張され、広く使用されるにつれて電力が蓄積する現象です。切り替えコストとは、ユーザーが現在のシステムを離れて別のシステムに切り替えるために必要な経済的、認知的、または時間的なコストを指します。 **電子メールの例では、Gmail を使用するユーザーにとってスイッチング コストは非常に重要です。 Gmail を使用していても独自ドメインを持っていない場合、切り替えコストが高くなります。ただし、独自のドメイン名を所有している場合は、メール サービス プロバイダーを自由に切り替えて、引き続き任意のサービス プロバイダーを使用してメールを受信できます。企業は、プロトコル設計を通じてユーザーに特定のコンポーネントの使用を強制または奨励することでスイッチング コストを増加させることができ、それによってユーザーが他のサプライヤーに切り替える可能性が低くなります。
Reddit を例に挙げると、モデレータがサブフォーラムを一方的に制御できるシステムであり、分散化と集中化の境界があいまいになります。誰でもモデレーターになれるのは分散化の一形態と見なされるかもしれませんが、最終的な権限が管理者 (Reddit チームなど) の手に残っている場合は、完全に集中化されたシステムであることに変わりはありません。高品質のユーザー エクスペリエンスは中央集権とは何の関係もありませんが、高品質のユーザー エクスペリエンスを提供するには財政的な支援が必要になることがよくあります。 ** Web1 の時代では、資金不足のため、分散型プロトコルでは優れたユーザー エクスペリエンスを提供できないことがよくあります。 **高品質のユーザー エクスペリエンスを提供するには、資金が重要な役割を果たします。
Web3: 分散化された明確な経済モデル
**Twitter、Facebook、Instagram、TikTok などの Web2 プラットフォームでは、プラットフォームのインターフェイスの決定に従い、ユーザーの選択肢は限られています。 **しかし、Web3 によって導入された分散コンポーネントはプロトコルをどのように変更するのでしょうか?暗号化とブロックチェーン技術を利用すると、経済性を明確にして分散化をサポートしながら、信頼への依存を減らすことができます。 **Web3 は、明確な経済モデルを備えたオープン性、相互運用性、オープンソースを提供し、プロトコルに資金を統合して持続可能な開発を達成し、すべての価値の独占を回避する機能を提供します。 **
**開発者としては、明確な経済モデルを備えた分散システム上に構築することを選択することが最善の選択です。 この方法により、協定外で経済関係を発展させることなく、システムの存続が保証され、それに関連する経済関係が理解されます。 ** 安定性と価値の獲得の観点からは、これは別の方法で検討する必要があります。分散システム上に構築することを選択することは、潜在的なリスクを回避し、耐久性があり、可能な限り最大のシステムになる可能性のあるプロジェクトを構築するため、重要です。
インターネット自体は完全に分散型システムであるため、インターネットの構築はもはや狂気の行為とはみなされません。同様に、オープンソース プログラミング言語の使用と Web ブラウザーへの依存は、野心的なプロジェクトを構築するための強固な基盤となっています。集中システム上での構築には制限があり、プロジェクトの規模と範囲が妨げられる可能性があります。 Web3 には、より大規模で野心的なプロジェクトを構築できる優れた開発者が集まります。他のシステムまたはプラットフォームが出現して、既存の Web2 プラットフォームと競合し、規制を遵守して競争上の優位性を持ち、Web2 プラットフォームと激しく競争する可能性があります。
Web2 ネットワークの最大の問題は、その脆弱性と過剰に最適化されたビジネス モデルです。これらのネットワークは、目標に関係のないものを無視して特定の指標の最適化を追求するため、イノベーションや新製品の開発が欠如します。独占を形成するほどではない強力なネットワーク効果を持っていますが、弱点への対抗策には脆弱です。
対照的に、**Web3 は、分散化と明確な経済モデルを通じて、より回復力があり革新的なスペースを提供します。 **豊かで多様な熱帯雨林の生態系と同様に、Web3 システムはあらゆる種類の興味深いものの開発に適したインフラストラクチャとプロトコルを確立し、イノベーションのためのより肥沃な土壌を提供します。暗号通貨とトークン経済モデルを活用することで、参加者は創造性とリスクテイクが報われ、システムの開発が促進されることが保証されます。
したがって、**Web3 は、経済資源の蓄積のみに依存するのではなく、より優れたエコシステムの持続可能性とイノベーションの可能性を備えています。 **明確な経済モデルと分散化機能により、Web3 は単一分野への過剰な最適化と集中的な蓄積の苦境から逃れ、真の意味でのイノベーションと発展を実現します。暗号化技術とトークンエコノミーモデルを導入することで、Web3 は参加者により大きな創造的なスペースとリターンメカニズムを提供し、より価値のある永続的な方向へのシステムの開発を促進します。
Web3 プロトコルの設計ケース
ケースの背景と設計目標
興味深い例から始めましょう。「Stable Horde」は、画像と Web2 プロトコルを生成するための無料システムです。これは、ユーザーが画像の生成を手伝ってくれる他の人に依頼できる共同レイヤー機能を使用します。クライアントはタスクをワークキューに送信し、ワーカーは推論処理を実行して結果を結果ストレージに送信します。クライアントはそこから結果を取得して、ワーカーに Kudos ポイントを支払うことができます。 Stable Horde では、Kudos はタスクに優先順位を付けるために使用される無料ポイント システムです。ただし、キューが長くなると、コンピューティング リソースの寄付の制限により、イメージの生成にかかる時間が長くなります。
私たちは興味深い問題に直面しました。それは、プロジェクト本来の精神を破壊する集中化の危険を冒さずに、オープン性と相互運用性を維持しながら、このシステムを拡張してより大きく専門化する方法です。 **提案の 1 つは、Kudos スコアを ERC20 トークンに変換し、ブロックチェーンに記録することです。しかし、単にブロックチェーンを追加するだけでは、偽結果攻撃など一連の問題が発生する可能性があります。
プロトコル設計プロセスを再考してみましょう。 **常に明確な目標から始めて、次に制約を考慮し、最後にメカニズムを定義する必要があります。 **システムを設計するには、目標を測定し、効果的なメカニズムを特定する必要があります。制約には内因性と外因性の形式があり、設計範囲を制限することでメカニズムをより明確に特定できます。メカニズムは、清算、価格設定、ステーキング、インセンティブ、支払い、検証などのプロトコルの本体です。設計は制約内に収まり、明確に定義された目標を達成する必要があります。
「Unstable Confusion」と呼ばれるまったく新しい Web3 プロトコルに移りましょう。以下では、既存の Web2 プロトコル「Stable Horde」を Web3 プロトコル「Unstable Confusion」に変換するというコンテキストで提案されているいくつかの興味深い方向性について概説します。
前述したように、誤った結果を送信することには問題があるため、ユーザーが必要なものを確実に取得できるメカニズムが必要です。これは「検証推論」と呼ばれます。簡単に言うと、推論を検証して、その結果が期待どおりであることを確認する必要があります。もう一つの問題は、「Stable Horde」の労働者に関するものです。ワーカーは、要求された順序でデータベースに次のタスクをリクエストし、最も早くリクエストを行ったワーカーにタスクを割り当てます。しかし、お金が関係するシステムでは、労働者はより多くの報酬を得るために大量のタスクを要求する可能性がありますが、実際にはタスクを完了するつもりはありません。これらは低遅延を求めて競合し、タスクを取得し、システムの輻輳を引き起こす可能性があります。 **
上記の問題を解決するために、いくつかの解決策が提案されている。 1 つ目は、ネットワークにとって有益な方法でタスクを競い合い、従業員の貢献に応じて報酬が支払われる「貢献に比例した支払い」です。 2 つ目は「柔軟な参加」です。つまり、従業員が低コストでシステムに自由に参加または退出できるため、より多くの参加者が集まります。 最後に 「低遅延」、つまりアプリケーションの応答性と速度がユーザー エクスペリエンスにとって重要です。 ** 私たちの目標に戻りますが、画像生成のための分散型で相互運用可能なマーケットプレイスを構築することです。まだ重要な制約がいくつかありますが、これらは後で追加、変更、またはより具体的な詳細が追加される可能性があります。これで、さまざまなメカニズムの実現可能性を評価できるようになりました。
潜在的なメカニズムの設計
1. 検証メカニズム
ゲーム理論や暗号学などの手法を使用して、推論の正確さを確保できます。ゲーム理論のメカニズムは紛争解決システムで使用でき、ユーザーは紛争をエスカレートし、特定の役割によって仲裁されることができます。継続的監査またはサンプル監査は、従業員の作業をレビューし、タスクが別の従業員に割り当てられていることを確認し、どの従業員が監査に合格したかを記録することによるもう 1 つのアプローチです。暗号におけるゼロ知識証明は、推論の正しさを検証するための効率的な証明を生成できます。従来の方法には、信頼できる第三者機関やユーザーのレビューが含まれますが、集中化のリスクとネットワーク効果があります。
他に考えられる検証メカニズムには、複数の作業者に同じタスクを完了させ、その結果からユーザーが選択することが含まれます。これにはコストがかかるかもしれませんが、コストが十分に低い場合は、アプローチとして検討できます。
2. 価格戦略
価格設定戦略に関しては、オーダーブックをオンチェーンで確立できます。ガスなど、オンチェーンの検証可能なコンピューティング リソース プロキシ メトリクスを使用することもできます。このアプローチは、単純な自由市場とは異なります。そこでは、ユーザーが推論に対して支払ってもよい金額を投稿するだけで、作業者はそれを受け入れることができ、タスクを競うために入札することもできます。代わりに、ユーザーは、特定の推論に一定量のコンピューティング リソースが必要となり、コンピューティング リソースの量が価格を直接決定するガスのようなプロキシ メトリックを作成できます。これにより、機構全体の動作を簡素化することができる。
あるいは、オフチェーンのオーダーブックを使用することもできます。これは、運営コストが低く、非常に効率的である可能性があります。ただし、問題は、その注文帳の所有者がネットワーク効果を自分自身に集中させる可能性があることです。
3. 収納機構
作業の結果がユーザーに正しく提供されることを保証するために、保存メカニズムは非常に重要ですが、信頼のリスクを軽減し、作業が正しく提供されたことを証明することは困難です。ユーザーは、期待した商品が届かないことについて苦情を言うのと同様に、商品が配達されたかどうかを疑問に思うことがあります。監査人は計算プロセスを検証し、出力結果の正確性をチェックする必要がある場合があります。したがって、出力はプロトコルに表示され、プロトコルがアクセスできる場所に保存される必要があります。
ストレージメカニズムに関しては、いくつかのオプションがあります。 1 つはデータをオンチェーンに保存することですが、これにはコストがかかります。もう 1 つのオプションは、専用のストレージ暗号化ネットワークを使用することです。これはより複雑ですが、ピアツーピア方式で問題を解決しようとします。あるいは、データをオフチェーンに保存するという選択肢もありますが、そのストレージ システムを管理する人が検証プロセスや最終的な支払いの送信などの他の側面に影響を与える可能性があるため、これにより別の問題が生じます。
4. タスク割り当て戦略
タスクの分散方法も考慮する必要がありますが、これは比較的複雑な領域です。タスクのサブミット後にワーカーが自らタスクを選択することも考えられるし、タスクのサブミット後にアグリーメントによりタスクを配布することも考えられ、ユーザーやエンドユーザーに特定のワーカーを選択させることも可能である。それぞれのアプローチには長所と短所があり、どのワーカーがどのタスクをリクエストできるかをプロトコルが決定する方法の組み合わせも検討してください。
タスクの割り当てには、多くの興味深い詳細が含まれます。たとえば、プロトコルベースのシステムでは、ワーカーにタスクを割り当てるかどうかを決定するために、ワーカーがオンラインで対応可能かどうかを知る必要があります。各作業者の能力と負荷も把握する必要があります。したがって、プロトコルではさまざまな追加要素を考慮する必要がありますが、初期の単純な実装には含まれていない可能性があります。
分散型プロトコル設計の重要なポイント
集中化のリスクにつながる可能性のある 7 つの重要な設計要素
これらには、電子メール、支払いシステム、評判、ストレージ、マッチング、価格設定システム、検証システムによって導入されたスペースの名前付けが含まれます。これらの要素は、ネットワーク効果や高いスイッチング コストにより集中化される可能性があります。ネットワーク効果の蓄積を緩和し、ネットワーク効果をプロトコルに取り込み、分散制御層をプロトコルに構築することでプロトコルを管理し、システムの長期的な健全性を確保します。分散型制御は、揮発性トークンや、評判システムや輪番選出メカニズムなどの他のガバナンス設計を使用して実現できます。
スイッチング コストを削減し、相互運用性を促進します
起業家がシステム上にアプリケーションを構築することを奨励するには、スイッチング コストを削減し、異なるシステム間の相互運用性を促進することが重要です。高額なスイッチングコストの導入を回避し、オフチェーンのオーダーブックやサードパーティの検証システムへの過度の依存を減らします。
Web3 テクノロジーを使用して分散システムを作成
Web3 のツールと原則を活用して、起業家に力を与え、過度の集中化を回避するシステムを設計します。 Web3 原則を採用したプロトコルは通常、より大規模で、より長寿命で、より活気に満ちたエコシステムの活力を備えており、最大手の既存企業が設定した境界を超えて革新的な探索の肥沃な領域を提供します。
綿密な調査と最適なソリューションの選択
プロトコルを設計して戦略を決定するときは、さまざまな側面を詳しく検討する必要があります。認証には、通常、暗号化ソリューションが最良の選択です。価格設定の点では、オンチェーンの検証可能なコンピューティング リソースを使用するプロキシ メトリクスは、さまざまな推論タスクや機械学習タスクに適応できます。タスクの割り当てに関しては、作業者の能力やステータスをリアルタイムに更新するプロトコルを採用し、タスクを公平に配分し、作業者がタスクを受け入れるかどうかを自主的に選択できるようにしています。ストレージの問題については、プロトタイプシャーディングテクノロジーなどのソリューションを検討して、短期間で問題を解決し、一時的なストレージ方法を採用することができます。
分散システムを設計する場合、上記の考慮事項は、長期的な堅牢性と分散特性を備えたシステムを構築するのに役立ちます。
原文：Protocol design: Why and how
翻訳された全文バージョンへのリンク: