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