原作者: ヴィタリック・ブテリンオリジナルのコンパイル: Bayemon.eth、ChainCatcherMike Neuder 氏、Justin Drake 氏、その他の方々のフィードバックとレビューに心より感謝いたします。同様のトピックに関する Mike Neuder、Dankrad Feist、および arixon.eth の以前の投稿も参照してください。現在のイーサリアムの開発状況は二層ステーキングが多いと言えますが、ここでいう二層ステーキングとは、2種類の参加者によるステーキングモデルを指します。※ノード運営者：ノードを運営し、自身の評判や一定量の自己資本を担保として利用します。* エージェント委任者: エージェントは一定量のイーサリアムを誓約します。最低金額はなく、担保以外の他の参加方法にも追加の制限はありません。この新たなダブルステーキングは、ステーキング トークン (LST) に流動性を提供するステーキング プールへの大量の参加によって生成されます。 (Rocket Pool と Lido の両方にこのモデルがあります)。**ただし、現在の二重誓約には 2 つの欠陥があります。*** ノードオペレーターの集中化リスク: すべてのステーキングプールにおけるノードオペレーターの現在の選択メカニズムは依然として過度に集中化されています。* 不必要なコンセンサス負担: イーサリアム L1 はエポックごとに約 800,000 の署名を検証する必要があり、これは単一スロットにとっては大きな負荷となります。さらに、流動性ステーキングプールにはより多くの資金が必要となるため、ネットワーク自体はこの負荷から十分な恩恵を受けられません。したがって、イーサリアムネットワークが各ステーカーに期間に応じた署名を要求せずに合理的な分散化とセキュリティを実現できれば、コミュニティはそのようなソリューションを採用でき、期間ごとの署名数を効果的に削減できます。この記事では、上記の 2 つの問題の解決策について説明します。まず、資本の大部分は、現在の形式でステーキング ノードを個人的に管理したくない人々が保有しており、各スロットの情報に署名し、デポジットをロックしていると仮定します。この場合、ネットワークの分散化とセキュリティに有意義な貢献を続けるために、これらの人々はどのような役割を果たせるのでしょうか?## ダブルステーキングは現在どのように機能しますか?現在、最も人気のある 2 つのステーキング プールは、Lido と RocketPool です。Lido に関する限り、参加している 2 つの当事者は次のとおりです。* ノード オペレーター: Lido DAO によって投票され、実際には LDO 保有者によって選出されることを意味します。誰かが ETH を Lido スマート コントラクト システムに入金すると、stETH が作成され、ノード オペレーターはそれをプレッジ プールに入れることができます (ただし、出金証明書はスマートコントラクトアドレスにバインドされているため、オペレーターは自由にお金を引き出すことができません）* エージェント: 誰かが Lido スマート コントラクト システムに ETH を入金すると、stETH が生成され、ノード オペレーターはそれを質権として使用できます (ただし、出金バウチャーはスマート コントラクト アドレスにバインドされているため、オペレーターは自由にお金を引き出すことができません) ）Rocket プールの場合は次のとおりです。* ノードオペレーター: 8 ETH と一定数の RPL トークンを提出することで、誰でもノードオペレーターになることができます。* エージェント: 誰かが Rocket Pool スマート コントラクト システムに ETH を入金すると、rETH が生成され、ノード オペレーターはそれを質権として使用できます (また、出金バウチャーはスマート コントラクト アドレスにバインドされているため、オペレーターは現金を引き出すことができません)意思）。## エージェントの役割これらのシステム (または、将来のプロトコル変更の可能性によって可能になる新しいシステム) で尋ねるべき重要な質問は、「プロトコルの観点から見ると、エージェントを配置することにどのような意味があるのか?」ということです。この質問の深い意味を理解するために、まず投稿で言及されたプロトコルの変更について考えてみましょう。これにより、削減ペナルティは 2 ETH に制限されます。Rocket Pool はノード オペレーターのステーク量も 2 ETH に削減されます。 Rocket Pool の市場シェアは 100% に増加します/(ステーカーおよび ETH 保有者にとって、rETH がリスクフリーになると、ほぼすべての ETH 保有者が rETH 保有者またはノードオペレーターになります)。rETH保有者のリターンが3%（プロトコル内報酬および優先手数料+MEVを含む）、ノードオペレーターのリターンが4%と仮定します。また、ETHの総供給量は1億であると仮定します。計算結果は以下の通り。複利計算を避けるために、日次ベースで収益を計算します。ここで、Rocket Pool が存在しないと仮定すると、ステーカーあたりの最低入金額は 2 ETH に低下し、総流動性の上限は 625 万 ETH に制限され、ノード オペレーターの収益率は 1% に低下します。もう一度計算してみましょう:攻撃コストの観点から両方のシナリオを検討してください。前者の場合、エージェントには基本的にお金を引き出す権利がないため、攻撃者はエージェントとして登録しません。したがって、意味がありません。したがって、彼らはすべてのETHを賭けてノードオペレーターになります。ステーク総額の 1/3 に達するには、208 万イーサリアムをステーキングする必要があります (公平を期すために、これでもかなり大きな数です)。2 番目のケースでは、攻撃者は、資金をステークするだけで、ステーキングプールが総額の1/3であっても、まだ208万イーサリアムを投資する必要があります。ステーキングの経済性と攻撃コストの観点から見ると、どちらの場合でも最終結果はまったく同じになります。ノードオペレーターが保有するETHの総供給量に占めるシェアは毎日0.00256%増加し、非ノードオペレーターが保有するETHの総供給量に占めるシェアは毎日0.00017%減少します。攻撃コストは208万ETH。したがって、このモデルでは、エージェントは意味のないルーブ・ゴールドバーグ・マシンになっているように見え、合理的なコミュニティは仲介者を排除し、ステーキング報酬を大幅に削減し、ステーキングされたETHの総量を625万に制限する傾向さえあります。もちろん、この記事はステーキング報酬を 4 倍に減らし、ステーキング総額を 625 万に制限することを主張するものではありません。むしろ、この記事のポイントは、適切に機能するステーキング システムの重要な特性は、エージェントがシステム全体にわたって重大な責任を負うべきであるということです。さらに、エージェントが適切な行動をとるよう主にコミュニティの圧力や利他主義によって動機づけられていたとしても問題ではありません; 結局のところ、それが今日の主要な力となっている分散型の高セキュリティのステーキング ソリューションを動機づけているものなのです。## エージェントの責任エージェントがステーキング システムで重要な役割を果たすことができるとしたら、その役割は何でしょうか?答えには 2 つのカテゴリがあると思います。* エージェントの選択: エージェントは、自分の利益をどのノードオペレーターに委ねるかを選択できます。コンセンサスメカニズムにおけるノードオペレータの「重み」は、ノードオペレータに託された賭け金の合計に比例します。現在、エージェント選択メカニズムはまだ制限されています。つまり、rETH または stETH 保有者は ETH を引き出して別のプールに切り替えることができますが、エージェント選択の実際の可用性は大幅に改善される可能性があります。* コンセンサスメカニズムへの参加: 委任者は、コンセンサスメカニズムにおいて特定の役割を果たすことを選択できます。責任は完全なサブスクリプションよりも「軽く」、長い離脱期間やリスク軽減はありませんが、それでもノードオペレーターをチェックし、バランスをとることができます。役割。## エージェントの選択権限を強化する代表者の選択力を高めるには 3 つの方法があります。* プール内の投票ツールの改善* プール間の競争を激化させる* 固定代表権現在、プール内での投票は実際には現実的ではありません。Rocket Pool では誰でもノード オペレーターになれますが、Lido では投票は ETH 保有者ではなく LDO 保有者によって決定されます。 Lido は、LDO + stETH の二重ガバナンスに関する提案を提出しました。保護メカニズムをアクティブにして、新しい投票を防ぎ、ノード オペレーターの追加や削除を防ぐことができます。これにより、stETH 保有者にある程度の発言権が与えられます。ただし、この力には限界があり、さらに強力になる可能性があります。現在、プール間の競争はすでに存在していますが、比較的弱いものです。主な課題は、小規模なステーキング プールのステーキング トークンは流動性が低く、信頼を得るのが難しく、アプリケーションによるサポートが少ないことです。最初の 2 つの問題は、ペナルティの金額を 2 または 4 ETH などのより小さい金額に制限することで改善できます。残りの ETH は安全に入金し、すぐに引き出すことができるため、小規模なステーキング プールでも双方向の変換を維持できます。 3 番目の問題は、LST を管理するための総発行契約 (ウォレットに使用される ERC-4337 および ERC-6900 契約と同様) を作成することで改善でき、この契約を通じて発行されたステークされたトークンはすべて安全であることを保証できます。現在、協定には確固たる代表権はないが、将来的にはそのような状況が存在する可能性が高いと思われる。これには上記のアイデアと同様のロジックが含まれますが、プロトコル レベルで実装されます。物を固めることの長所と短所については、この記事を参照してください。これらのアイデアは現状を改善するものですが、利点は限られています。トークン投票のガバナンスには問題があり、最終的にはいかなるインセンティブのない代理人選択もトークン投票の一形態にすぎません; これが、Delegated Proof of Stake に対する私の主な不満でした。したがって、より強力なコンセンサスへの参加を達成する方法を検討することも重要です。## コンセンサスへの参加流動性ステーキングに関する現在の問題を脇に置いても、現在の独立したステーキング方法には限界があります。単一スロットのファイナリティが使用されると仮定すると、各スロットは理想的には約 100,000 ～ 1,000,000 個の BLS 署名を処理できます。再帰的 SNARK を使用して署名を集約する場合でも、署名の追跡可能性を確保するために、各署名に参加者のビット フィールドを割り当てる必要があります。イーサリアムが世界規模のネットワークになると、完全に分散化されたストレージのビット フィールドだけでは不十分になります。各スロットの 16 MB では、約 6,400 万のステーカーしかサポートできません。この観点から、ステーキングをより複雑度の高い削減可能な層と、より複雑度の低い層に分割することには価値があり、各スロットはアクティブになりますが、参加者は 10,000 人のみであるか、より複雑度の低い層は参加するために呼び出されることが時々しかありません。複雑さの低いレイヤーは削減から完全に免除されることも、参加者にランダムにいくつかのスロット内にデポジットする機会が与えられ、削減の対象となることもできます。実際には、これは、バリデーターの残高上限を増やし、その後残高しきい値 (例: 2048 ETH) を増やして、既存のどのバリデーターがより高いまたはより低い複雑さの層に移動するかを決定することによって達成できます。これらの小規模なステーキングの役割がどのように機能するかについて、いくつかの提案を示します。* スロットごとに 10,000 人の小規模ステーカーがランダムに選ばれ、スロットを代表すると思われる内容に署名できます。小さなステーカーを入力として使用して、LMD GHOST フォーク選択ルールを実行します。小規模ステーカーによるフォーク選択とノードオペレーターによるフォーク選択の間に不一致がある場合、ユーザーのクライアントは最終確認としてブロックを受け入れず、エラーを表示します。このため、コミュニティは状況を解決するために介入する必要があります。* エージェントは、オンラインであり、今後 1 時間小規模なステーカーとして機能する意思があることをネットワークに通知するトランザクションを送信できます。ノードによって送信されるメッセージ (ブロックまたはプルーフ) の計算では、ノードとランダムに選択されたエージェントの両方がノードの確認情報に署名する必要があります。* エージェントは、オンラインであり、今後 1 時間小規模なステーカーとして機能する意思があることをネットワークに通知するトランザクションを送信できます。各エポックでは、10 人のランダムなエージェントが包含リストの提供者として選択され、さらに 10,000 人のエージェントが投票者として選択されます。これらは k スロットの前に選択され、オンラインの存在を確認するメッセージをチェーン上に公開するための k スロット ウィンドウが与えられます。確認済みの選択された各包含リストプロバイダーは、包含リストを公開できます。ただし、各包含リストについて、その包含リスト内のトランザクションが含まれるか、一般の 1 つの選択された有権者の投票により包含リストが利用できないことが示されます。それ以外の場合、ブロックは無効とみなされます。これらの小規模なステーキング ノードに共通しているのは、各スロットに積極的に参加する必要がなく、すべての作業を完了するのにライト ノードさえあれば十分であるということです。したがって、ノードのデプロイメントにはコンセンサス層の検証のみが必要であり、ノードオペレータはアプリケーションまたはブラウザプラグインを通じてこれを実現できますが、これらはほとんど受動的であり、計算オーバーヘッド、ハードウェア要件、または技術的ノウハウを課すことはありません。 ZK-EVMのような高度なテクノロジーが必要です。これらの「小規模な主体」には、ノード オペレーターの 51% 多数によるトランザクション検閲を防ぐという共通の目標もあります。 1 つ目と 2 つ目は、大多数がファイナリティ削減に参加することも妨げます。 3 つ目は検閲に直接関係しますが、多数派ノードのオペレーターの選択の影響を受けやすくなります。これらのアイデアは、プロトコルに実装されたダブルステーキング ソリューションの観点から書かれていますが、ステーキング プールの機能として実装することもできます。具体的な実装アイデアをいくつか示します。* プロトコルの観点から、各検証者は 2 つのプレッジ キー (連続プレッジ キー P と、呼び出し可能なバインドされたイーサリアム アドレス) を設定し、クイックプレッジ キー Q を出力できます。フォーク選択のためのノードの署名情報追跡は P で表され、署名情報は Q で表されます。PQ の保存結果が矛盾する場合、どのブロックの最終決定も受け入れられず、流動性プールがランダムに責任を負います。代表者を選ぶこと。* プロトコルはほとんど変更されませんが、この期間のバリデーターの公開キーは P+Q に設定されます。リダクションの場合、2 つのリダクション可能なメッセージは異なる Q キーを持つ可能性がありますが、同じ P キーを持つことになることに注意してください。リダクション設計はこのケースを処理する必要があります。* Q キーは、ブロック内の包含リストに署名して検証するためのプロトコルでのみ使用できます。この場合、Q は単一のキーではなくスマート コントラクトになる可能性があるため、ステーキング プールはそれを使用してより複雑な投票ロジックを実装し、ランダムに選択されたプロバイダーからの包括的なリストを受け入れるか、含まれるリストが投票に使用できないことを示します。 。＃＃ 結論は正しく実装されていれば、プルーフ・オブ・ステークの設計を微調整することで、次の 2 つの問題を一気に解決できます。* 現在独立してプルーフ オブ ステークを実行するリソースや能力がない人がプルーフ オブ ステークに参加する機会を提供し、より多くの権限を手中に保持します。これには、(i) どのノードをサポートするかを選択する権限が含まれます。 ii) ) プルーフ・オブ・ステーク・ノードを完全に運用するよりも軽いけれども意味のある何らかの方法で、コンセンサスに積極的に参加します。すべての参加者がこれらのオプションの一方または両方を選択するわけではありませんが、これらのオプションの一方または両方を選択した参加者は現状からの大幅な改善を経験します。* イーサリアム コンセンサス レイヤーが各スロットで処理する必要がある署名の数を、たとえ単一スロットのファイナリティ方式であっても、約 10,000 などのより少ない数に削減します。これは分散化にも役立ち、誰もが検証ノードを簡単に実行できるようになります。これらのソリューションでは、問題の解決策は、プルーフ・オブ・ステーク・プロトコル内でユーザーに付与される権限、プルーフ・オブ・ステーク・プロトコル間でのユーザーの選択、プロトコル内での確立など、さまざまな抽象化レベルで見つけることができます。この選択は慎重に検討する必要があり、望ましい目標を達成しながら、プロトコルの複雑さとプロトコルの経済性への変更の範囲を最小限に抑えるために、実行可能な最小限のセットアップを選択する方が良いことがよくあります。
Vitalik の最新研究: LSDFi プロトコルの流動性と分散化の改善との微妙な関係
原作者: ヴィタリック・ブテリン
オリジナルのコンパイル: Bayemon.eth、ChainCatcher
Mike Neuder 氏、Justin Drake 氏、その他の方々のフィードバックとレビューに心より感謝いたします。同様のトピックに関する Mike Neuder、Dankrad Feist、および arixon.eth の以前の投稿も参照してください。
現在のイーサリアムの開発状況は二層ステーキングが多いと言えますが、ここでいう二層ステーキングとは、2種類の参加者によるステーキングモデルを指します。
※ノード運営者：ノードを運営し、自身の評判や一定量の自己資本を担保として利用します。
この新たなダブルステーキングは、ステーキング トークン (LST) に流動性を提供するステーキング プールへの大量の参加によって生成されます。 (Rocket Pool と Lido の両方にこのモデルがあります)。
ただし、現在の二重誓約には 2 つの欠陥があります。
この記事では、上記の 2 つの問題の解決策について説明します。まず、資本の大部分は、現在の形式でステーキング ノードを個人的に管理したくない人々が保有しており、各スロットの情報に署名し、デポジットをロックしていると仮定します。この場合、ネットワークの分散化とセキュリティに有意義な貢献を続けるために、これらの人々はどのような役割を果たせるのでしょうか?
ダブルステーキングは現在どのように機能しますか?
現在、最も人気のある 2 つのステーキング プールは、Lido と RocketPool です。Lido に関する限り、参加している 2 つの当事者は次のとおりです。
Rocket プールの場合は次のとおりです。
エージェントの役割
これらのシステム (または、将来のプロトコル変更の可能性によって可能になる新しいシステム) で尋ねるべき重要な質問は、「プロトコルの観点から見ると、エージェントを配置することにどのような意味があるのか?」ということです。
この質問の深い意味を理解するために、まず投稿で言及されたプロトコルの変更について考えてみましょう。これにより、削減ペナルティは 2 ETH に制限されます。Rocket Pool はノード オペレーターのステーク量も 2 ETH に削減されます。 Rocket Pool の市場シェアは 100% に増加します/(ステーカーおよび ETH 保有者にとって、rETH がリスクフリーになると、ほぼすべての ETH 保有者が rETH 保有者またはノードオペレーターになります)。
rETH保有者のリターンが3%（プロトコル内報酬および優先手数料+MEVを含む）、ノードオペレーターのリターンが4%と仮定します。また、ETHの総供給量は1億であると仮定します。
計算結果は以下の通り。複利計算を避けるために、日次ベースで収益を計算します。
ここで、Rocket Pool が存在しないと仮定すると、ステーカーあたりの最低入金額は 2 ETH に低下し、総流動性の上限は 625 万 ETH に制限され、ノード オペレーターの収益率は 1% に低下します。もう一度計算してみましょう:
攻撃コストの観点から両方のシナリオを検討してください。前者の場合、エージェントには基本的にお金を引き出す権利がないため、攻撃者はエージェントとして登録しません。したがって、意味がありません。したがって、彼らはすべてのETHを賭けてノードオペレーターになります。ステーク総額の 1/3 に達するには、208 万イーサリアムをステーキングする必要があります (公平を期すために、これでもかなり大きな数です)。2 番目のケースでは、攻撃者は、資金をステークするだけで、ステーキングプールが総額の1/3であっても、まだ208万イーサリアムを投資する必要があります。
ステーキングの経済性と攻撃コストの観点から見ると、どちらの場合でも最終結果はまったく同じになります。ノードオペレーターが保有するETHの総供給量に占めるシェアは毎日0.00256%増加し、非ノードオペレーターが保有するETHの総供給量に占めるシェアは毎日0.00017%減少します。攻撃コストは208万ETH。したがって、このモデルでは、エージェントは意味のないルーブ・ゴールドバーグ・マシンになっているように見え、合理的なコミュニティは仲介者を排除し、ステーキング報酬を大幅に削減し、ステーキングされたETHの総量を625万に制限する傾向さえあります。
もちろん、この記事はステーキング報酬を 4 倍に減らし、ステーキング総額を 625 万に制限することを主張するものではありません。むしろ、この記事のポイントは、適切に機能するステーキング システムの重要な特性は、エージェントがシステム全体にわたって重大な責任を負うべきであるということです。さらに、エージェントが適切な行動をとるよう主にコミュニティの圧力や利他主義によって動機づけられていたとしても問題ではありません; 結局のところ、それが今日の主要な力となっている分散型の高セキュリティのステーキング ソリューションを動機づけているものなのです。
エージェントの責任
エージェントがステーキング システムで重要な役割を果たすことができるとしたら、その役割は何でしょうか?
答えには 2 つのカテゴリがあると思います。
エージェントの選択権限を強化する
代表者の選択力を高めるには 3 つの方法があります。
現在、プール内での投票は実際には現実的ではありません。Rocket Pool では誰でもノード オペレーターになれますが、Lido では投票は ETH 保有者ではなく LDO 保有者によって決定されます。 Lido は、LDO + stETH の二重ガバナンスに関する提案を提出しました。保護メカニズムをアクティブにして、新しい投票を防ぎ、ノード オペレーターの追加や削除を防ぐことができます。これにより、stETH 保有者にある程度の発言権が与えられます。ただし、この力には限界があり、さらに強力になる可能性があります。
現在、プール間の競争はすでに存在していますが、比較的弱いものです。主な課題は、小規模なステーキング プールのステーキング トークンは流動性が低く、信頼を得るのが難しく、アプリケーションによるサポートが少ないことです。
最初の 2 つの問題は、ペナルティの金額を 2 または 4 ETH などのより小さい金額に制限することで改善できます。残りの ETH は安全に入金し、すぐに引き出すことができるため、小規模なステーキング プールでも双方向の変換を維持できます。 3 番目の問題は、LST を管理するための総発行契約 (ウォレットに使用される ERC-4337 および ERC-6900 契約と同様) を作成することで改善でき、この契約を通じて発行されたステークされたトークンはすべて安全であることを保証できます。
現在、協定には確固たる代表権はないが、将来的にはそのような状況が存在する可能性が高いと思われる。これには上記のアイデアと同様のロジックが含まれますが、プロトコル レベルで実装されます。物を固めることの長所と短所については、この記事を参照してください。
これらのアイデアは現状を改善するものですが、利点は限られています。トークン投票のガバナンスには問題があり、最終的にはいかなるインセンティブのない代理人選択もトークン投票の一形態にすぎません; これが、Delegated Proof of Stake に対する私の主な不満でした。したがって、より強力なコンセンサスへの参加を達成する方法を検討することも重要です。
コンセンサスへの参加
流動性ステーキングに関する現在の問題を脇に置いても、現在の独立したステーキング方法には限界があります。単一スロットのファイナリティが使用されると仮定すると、各スロットは理想的には約 100,000 ～ 1,000,000 個の BLS 署名を処理できます。再帰的 SNARK を使用して署名を集約する場合でも、署名の追跡可能性を確保するために、各署名に参加者のビット フィールドを割り当てる必要があります。イーサリアムが世界規模のネットワークになると、完全に分散化されたストレージのビット フィールドだけでは不十分になります。各スロットの 16 MB では、約 6,400 万のステーカーしかサポートできません。
この観点から、ステーキングをより複雑度の高い削減可能な層と、より複雑度の低い層に分割することには価値があり、各スロットはアクティブになりますが、参加者は 10,000 人のみであるか、より複雑度の低い層は参加するために呼び出されることが時々しかありません。複雑さの低いレイヤーは削減から完全に免除されることも、参加者にランダムにいくつかのスロット内にデポジットする機会が与えられ、削減の対象となることもできます。
実際には、これは、バリデーターの残高上限を増やし、その後残高しきい値 (例: 2048 ETH) を増やして、既存のどのバリデーターがより高いまたはより低い複雑さの層に移動するかを決定することによって達成できます。
これらの小規模なステーキングの役割がどのように機能するかについて、いくつかの提案を示します。
これらの小規模なステーキング ノードに共通しているのは、各スロットに積極的に参加する必要がなく、すべての作業を完了するのにライト ノードさえあれば十分であるということです。したがって、ノードのデプロイメントにはコンセンサス層の検証のみが必要であり、ノードオペレータはアプリケーションまたはブラウザプラグインを通じてこれを実現できますが、これらはほとんど受動的であり、計算オーバーヘッド、ハードウェア要件、または技術的ノウハウを課すことはありません。 ZK-EVMのような高度なテクノロジーが必要です。
これらの「小規模な主体」には、ノード オペレーターの 51% 多数によるトランザクション検閲を防ぐという共通の目標もあります。 1 つ目と 2 つ目は、大多数がファイナリティ削減に参加することも妨げます。 3 つ目は検閲に直接関係しますが、多数派ノードのオペレーターの選択の影響を受けやすくなります。
これらのアイデアは、プロトコルに実装されたダブルステーキング ソリューションの観点から書かれていますが、ステーキング プールの機能として実装することもできます。具体的な実装アイデアをいくつか示します。
＃＃ 結論は
正しく実装されていれば、プルーフ・オブ・ステークの設計を微調整することで、次の 2 つの問題を一気に解決できます。
これらのソリューションでは、問題の解決策は、プルーフ・オブ・ステーク・プロトコル内でユーザーに付与される権限、プルーフ・オブ・ステーク・プロトコル間でのユーザーの選択、プロトコル内での確立など、さまざまな抽象化レベルで見つけることができます。この選択は慎重に検討する必要があり、望ましい目標を達成しながら、プロトコルの複雑さとプロトコルの経済性への変更の範囲を最小限に抑えるために、実行可能な最小限のセットアップを選択する方が良いことがよくあります。