V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

avatar
Mint Ventures
10ヶ月前
本文は約16532字で,全文を読むには約21分かかります
潜在的かつゆっくりとした変化。

1. はじめに

イーサリアムのステーキングとその関連デリバティブは、間違いなくここ 1 ~ 2 年で最もホットなトピックです。 Beacon ChainからThe Merge、Shanghai Advancedまで、LSTからDVT、ResakingとLSTfiに至るまで、私たちはステーキングと関連トラックの台頭と急速な発展を目の当たりにしてきました。その背後にある推進要因を調査すると、その開発がイーサリアムステーキングのパラダイム変化に由来していることを見つけるのは難しくありません。したがって、イーサリアムのステーキングパラダイムが長期的にどのように進化し、関連トラックや主要プレーヤーにどのような影響を与えるかについても考える必要があります。

Vitalikは10月7日に次のタイトルで出版されましたこの記事では、現在のイーサリアムのプレッジメカニズムを最適化するためのいくつかの計画を提案し、イーサリアムに集中度をさらに下げてコンセンサス負荷を軽減するための参照パスを提供しました。これらのアイデアの中には、ステーキング メカニズムに大きな変更をもたらすものや、イーサリアム開発の主なトレンドと一致するものもあります。そのため、記事を解釈し、さまざまなソリューションがステーキング トラックに与える潜在的な影響を分析します。

2. 記事のレビュー

2.1 二重誓約の現状

Vitalik 氏は、イーサリアムの現在のステーキング パターンを 2 層ステーキングと呼んでいます。このステーキング モデルには、ノード オペレーターと委任者という 2 つの層の参加者が存在します。

  • ノードオペレーター: ノードオペレーターはイーサリアムノードの操作を担当します。

  • 委任者: 委任者、さまざまな方法でステーキングに参加するユーザー (ノード自体の実行を除く)。

現在、委任者がステーキングに参加する主な方法は、Lido や Rocket Pool などのステーキング サービス プロバイダーが提供するサービスを利用することです。

2.2 問題点

Vitalik 氏は、二重層プレッジ モデルが 2 つの問題、つまりプレッジ トラックの集中化リスクとコンセンサス層への不必要な負担をもたらしたと考えています。

  • ステーキングトラックの集中化リスク: 委任者がETHをプレッジした後、ノードを選択するにはLidoなどのサービスプロバイダーが必要ですが、特定の選択メカニズムはさまざまな角度からノードオペレーターの集中化リスクをもたらします。例えば、Lido が DAO 投票を通じてオペレーターを決定する場合、ノードオペレーターは市場シェアを拡大​​するために大量の LDO を保有する傾向にある可能性がありますが、Rocket Pool では 8 ETH を誓約すれば誰でもノードオペレーターになれるため、強固な財務力を持つ企業が参加できます。事業者は市場シェアを直接「買う」ことができます。

  • コンセンサス層への不必要な負担: 現在、イーサリアムのコンセンサス層は各エポックで約 800,000 個の署名を集約して検証する必要があります。シングル スロット ファイナリティ (SSF) の目標を達成するには、イーサリアムは 1 つのスロットで 800,000 個の署名を集約して検証する必要があります。つまり、タスクは変更されず、時間は元の 1/32 に短縮され、実行中のノードのハードウェアに対する要件が高くなります。現在の 2 層ステーキング構造から判断すると、検証作業のほとんどはノード運営者によって行われており、検証者の数は多いものの、実際に検証者を実行する主体は多様ではありません。言い換えれば、ノード数の増加はイーサリアムの集中化を軽減するものではなく、イーサリアムに対するコンセンサス負担を増加させています。したがって、検証ノードの数を減らすことができ(処理する必要がある署名の数を減らす)、それによってイーサリアムのコンセンサス負荷を軽減できます(より集中化されているように聞こえます。集中化を軽減するためのサポート措置については、次のセクションで説明します) )。

追加の背景知識:

スロット (タイムスロット): 新しいブロックがコンセンサスに含まれるまでに必要な時間を指し、イーサリアムのスロットは約 12 秒です。各スロットで、ネットワークはブロック提案者としてバリデーターをランダムに選択します。バリデーターは、新しいブロックを作成してネットワーク上の他のノードに送信する責任を負います。さらに、各スロットではバリデータ委員会がランダムに選択され、その投票によって提案されたブロックの有効性が決定されます。つまり、すべてのバリデーターが特定のスロットの検証作業に参加する必要はなく、通常は選択された委員会のバリデーターのみが参加でき、委員会の投票の 2/3 でスロットのステータスを有効にすることができます。各スロットはすべてのバリデーターが参加する必要がないため、ネットワーク負荷の管理が容易になります。

エポック (ピリオド): 32 スロットを含む期間を指します。イーサリアムのエポックは約 6.4 分です。エポックでは、バリデーターは 1 つの委員会のみに参加でき、ネットワーク内のすべてのアクティブなバリデーターは、このエポックでの「アクティブ」ステータスを示す証拠を提示する必要があります。各エポックの最初のスロットは (通常は) チェックポイントとも呼ばれます。

ファイナリティ: 分散ネットワークにおけるトランザクションの「ファイナリティ」とは、トランザクションがブロックの一部となり、大量の ETH が破壊されてブロックチェーンがロールバックされない限り変更できないことを意味します。イーサリアムは「チェックポイント」ブロックを通じてファイナリティを管理します。チェックポイントのペア (隣接するエポックの最初のスロット) がステーキングされた ETH の総数から 2/3 を超える投票を受け取った場合、チェックポイントのペアはアップグレードされます。 2 つのチェックポイントのうち新しい方が「適切な」状態になり、古いチェックポイントが最後のエポックで取得された適切な状態から「最終」状態にアップグレードされます。平均すると、ユーザー トランザクションは、次のチェックポイントから 0.5 エポック離れた、エポックの途中のブロックに存在します。これは、トランザクションが 2.5 エポック、つまり約 16 分で完了することを示しています (0.5 エポック後、次のチェックポイントに到達します。別のエポックの後、次のチェックポイントは適切な状態を取得します。別のエポックの後、次のチェックポイントは最終状態を取得します)。理想的には、エポックの 22 番目のスロットでエポック チェックポイントの妥当性が達成されます。したがって、トランザクションの平均完了時間は 14 分 (16+ 32+ 22 スロット) です。

シングル スロット ファイナリティ (SSF、シングル スロット ファイナリティ): ファイナリティは、各スロットがブロックを生成した直後に達成されます。現在、イーサリアムがブロックをファイナライズするのにかかる時間が長すぎるため、ほとんどのユーザーはトランザクションをファイナライズするまでに約 15 分も待ちたくないため、高いトランザクション スループットを実現したいアプリケーションの開発が制限されます。さらに、ブロックの提案と最終化の間の遅延により、短期間の再編成の機会が生まれ、攻撃者が特定のブロックを検閲したり、MEV 抽出を実行したりするために悪用される可能性があります。段階的アップグレード ブロックを処理するメカニズムも非常に複雑で、イーサリアム コードベースの中で軽微なバグに対して最も脆弱な部分の 1 つです。これらの問題は、ファイナライズ時間を 1 スロットに短縮することで解決できます。 SSF はイーサリアム ロードマップの The Merge ブランチに含まれています (参照:https://twitter.com/VitalikButerin/status/1588669782471368704/photo/1)、これはイーサリアムの長期目標の 1 つです。しかし、イーサリアム関係者はSSFが数年以内に開始されるとは予想しておらず、準備作業としてVerkle TreesやDankshardingなどの大規模なアップグレードが必要になるだろう。

2.3 解決策

ヴィタリク氏は、現在の委任者が本来の役割を果たしていないと指摘し、委任者により多くの権利と義務を与えることで上記の問題は両方とも解決できると考えた。この問題を解決する 2 つの主な方法は、代表者選択権限の拡大とコンセンサスへの参加です。

2.3.1 Expanding delegate selection powers

委任者の選択権限を拡大するということは、委任者の選択肢を拡大し、ステーキングサービスプロバイダーやノードオペレーターを選択する際に、より積極的な立場を委任者に与えることを意味します。現時点では、stETHまたはrETHを保有するデリゲータが資金を直接出金し、他のステーキングプールにプレッジできるため、この方法は実際に部分的に存在しますが、オペレータを直接選択できない、出金が不十分であるなど、多くの制限があります。 。

Vitalik 氏は、委任者の選択肢を広げる 3 つの方法について言及しました。

  • プール内の投票ツールの改善、プール内での投票の最適化、つまりステーキング プール内での投票を最適化し、プール内のユーザーが独自のノード オペレーターを選択できるようにしますが、この方法は現在存在しません。 Rocket プールでは、あらゆるステーカーがノード オペレーターになることができます。Lido では、LDO ホルダーがノード オペレーターを決定しますが、Lido は LDO + stETH の 2 層ガバナンス モデルを提案しています (提案リンク: https://research. lido.fi/t/) ldo-steth-dual-governance/2382)。

  • プール間の競争が激化し、プール間の競争が強化されます。つまり、ステーキングプール間の競争のレベルが高まり、委任者がより豊富な選択肢を得ることができます。しかし実際には、ロングテールステーキングプールのLSTは、流動性、信頼性、dappの受け入れの点で不利な立場にあり、Lidoのような主要プロジェクトと競合することができないため、デリゲーターには選択の余地がありません。 Vitalik氏は、流動性、信頼、dappの受け入れという3つの問題は、委任者が直面するスラッシュリスクを軽減するためにスラッシュ罰金の額を削減し、ユーザーがいつでも約束したETHを引き出すことができるようにするなどの一連の措置によって解決できると考えています。これにより、LST の流動性と信頼性の問題が解決され、同時に、統一された LST トークン標準も導入され、すべてのステーキング プール LST が統一された契約を通じて発行され、さまざまな DAPP に対する LST の互換性とセキュリティが確保されます。

スラッシュについて:

スラッシュとは: イーサリアムコンセンサスでは、バリデーターが積極的に実行するために特定のインセンティブメカニズムが必要です。イーサリアムコンセンサスに参加するには、バリデーターは事前に一定量のETHを誓約する必要があります。バリデーターが不適切な行動をした場合、ステーキングされたETHが削減される可能性があります。不正とみなされる行為には主に 2 つのタイプがあります。スロット内で複数のブロックを提案すること (曖昧さ) と、矛盾する投票を送信することです。

スラッシュの量を減らすと、委任者が直面するリスクを軽減できる理由: 現在の 2 層プレッジ構造では、委任者は誓約された ETH のみを提供し、検証者の動作は実際にはノード オペレータの動作となるため、オペレータが悪意を持った場合、 、それは委任者があなたに代わって罰せられる原因になります。 Rocket Pool などのプロジェクトでは、エージェンシーの問題を軽減するために、ノードオペレーターが一定量の誓約済み ETH を寄付する必要があります。スラッシュできるETHの量がノード運営者の取り分でカバーできる範囲までイーサリアムレベルで削減された場合、委任者はスラッシュのリスクを排除でき、プレッジサービスプロバイダーは委任者がいつでも資金を引き出すことができるようになります。一定量の流動性を確保する必要はありません。

  • 統合された委任、ネイティブ統合委任: つまり、イーサリアムは、イーサリアム プロトコル レベルでプレッジに参加するときに委任者にノード オペレーターの選択を強制するなど、上記の関連する委任機能を直接ネイティブに統合します。

2.3.2 Consensus participation

コンセンサス参加により、委任者はイーサリアムコンセンサスに追加の負担をもたらすことなく、より軽い方法でイーサリアムコンセンサスに参加することができます。 Vitalik 氏は、多くの代表者はこれを望んでいないことを認め、彼らは単に最も単純な方法で LST を開催したいだけですが、コンセンサスに積極的に参加する代表者もいるだろうとも信じています。 Vitalik は、イーサリアム ネイティブ統合とサードパーティ プロジェクト統合という 2 つの実装ソリューションを提供します。これらについては、以下で 1 つずつ説明します。

2.3.2.1 イーサリアムのネイティブ統合

イーサリアムのプロトコル レベルでは、バリデーターはまず、複雑なバリデーター (より複雑なスラッシュ可能層) と単純なバリデーター (より複雑度の低い層) の 2 つのタイプに分類され、それぞれがイーサリアムのパフォーマンスと分散化を確保するために異なるタスクを引き受けます。

  • 複雑なバリデータ: イーサリアムの主な検証と計算作業を引き受け、常にオンラインに保つ必要があります。各複雑なバリデーターによって誓約された ETH の量は 2048 ETH (Vitalik が示した例) まで増やす必要があり、これにはスラッシュのリスクが伴います。ネットワーク全体の複雑なバリデーターの数は 10,000 に制限されています。

  • シンプルなバリデータ: クォータ制限やステーキングしきい値はなく、スラッシュの影響を受けず、一部のスロットでのコンセンサスに参加するだけで十分です。

  • シンプルなバリデーターのソース: ステーキング サービス プロバイダーを通じてステーキングに参加し、複雑なバリデーターに ETH を提供する委任者、および独立してシンプルなバリデーターになりたいネットワーク内のユーザー。 (注: Vitalik は元の記事でシンプルなバリデーターを指すためにスモール ステーカーを使用しました。以下では、スモール ステーカーとシンプルなバリデーターは同じ意味で使用されます)

  • 単純なバリデーターが機能するためのいくつかの可能な方法

    • 各スロットには、承認する州に投票するためにランダムに選ばれた 10,000 人の単純な検証者がいます。

    • 委任者はトランザクションを送信して、自分がオンラインであり、承認するブロック ヘッダーに投票するために次の 1 時間簡単な検証者になる意思があり、作業が完了したらサインアウトする必要があることを宣言できます。

    • デリゲートはトランザクションを送信して、自分がオンラインであり、次の 1 時間は単純なバリデータになる意思があることを宣言できます。各エポックでは、10 人の代表者がランダムに選択されてブロック推奨リストが作成され、10,000 人を超える代表者が投票者として選択されます。この部分の単純な検証者はサインアウトする必要がなく、オンライン要件は時間の経過とともに期限切れになります。

  • 上記 3 つのソリューションの特徴は次のとおりです。これらはすべて、ノード オペレーターによる 51% の攻撃を防止し、イーサリアムの検閲耐性を向上させるように設計されています。 1 つ目と 2 つ目の解決策は主にファイナリティが逆転するのを防ぎますが、3 つ目の解決策はネットワークの検閲耐性に重点を置いており、単純な検証者はより多くの作業を行う必要があります。

  • 軽量参加の前提条件: 単純な検証者が使用できる超軽量クライアントがあり、携帯電話や Web ページを通じて検証作業を完了できます。これには、軽量イーサリアム クライアントに関する関連研究 (Verkle Tree、ステートレス、など)、バリデーターの参加閾値を下げることを目的としています。

    V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

ソース:https://notes.ethereum.org/@vbuterin/staking_2023_10

2.3.2.2 サードパーティプロジェクトの統合

サードパーティプロジェクトの統合とは、主にステーキングプール自体のアップグレードを通じて、イーサリアムコンセンサスへの委任者の参加を実現することを指します。中心的なアイデアは、委任者グループの希望を反映するために、コンセンサス投票プロセスに委任者と検証者の共同署名を導入することです。 Vitalik が提案する 3 つのオプションは次のとおりです。

  1. ステーキング プールは、バリデーター アカウントを開くときに 2 つのステーキング キー、つまり P (永続的ステーキング キー) と Q (イーサリアム アドレスが呼び出されたときの実際の出力結果であるクイック ステーキング キー) を宣言します。ノードはそれぞれ、特定のフォークによって選択されたメッセージの P と Q の署名を追跡し、P と Q の選択が同じであれば検証は成功し、異なる場合は検証は失敗します。ステーキング プールは、現在のスロットの Q キー所有者として委任者をランダムに選択する責任があります。

  2. 検証者は各スロットで誓約公開鍵 P + Q をランダムに生成し、各スロットの投票署名は検証者と委任者による共同計算を必要とします。各スロットは異なるキーをランダムに生成するため、スラッシュが発生すると関連する属性の問題が発生し、この問題に対処するために特定の設計を行う必要があります。

  3. Q を委任者が直接保持するキーとしてではなく、スマート コントラクトに入れます。スマート コントラクトによって管理される Q は、多様なトリガー条件を導入できるため、ステーキング プールにより豊富な投票ロジックを導入できます。

2.3.3 概要

Vitalik 氏は、上記のソリューションが適切に採用されれば、プルーフ オブ ステークの設計を調整することで一石二鳥 (誓約の一元化を減らし、イーサリアムのコンセンサス負荷を軽減) を達成できると考えています。

  1. 現在 PoS に参加するためのリソースや能力を持たない人々に参加の機会を提供し、より多くの権限 (サポートするノードを選択する権限を含む) を与え、より軽量でありながら有意義な方法で参加できるようにします。同時に、ヴィタリック氏は、すべての参加者がこれら 2 つまたはいずれかのオプションを選択するわけではないが、どのオプションを選択しても現状を改善できる可能性があるとも指摘しました。

  2. イーサリアム コンセンサス レイヤーがスロットごとに処理する必要がある署名の数を減らすと、単一スロットの決定論的実装であっても、約 10,000 に減らすことができます。これは分散化に貢献し、誰もがバリデーターノードを実行しやすくなります。

上記のソリューションは、プール内選挙の最適化、プール間競争の強化、イーサリアムのネイティブ統合など、さまざまな抽象レベルにありますが、それらの目標は、イーサリアムのプレッジ集中化とコンセンサス負荷という現在の問題を解決することです。 Vitalik 氏は、特定の実装ソリューションは採用前に慎重に検討する必要があり、最適なソリューションはプロトコルの変更を最小限に抑えながら望ましい目標を達成する必要があると考えています。

3. ステーキング関連トラックへの影響の分析

3.1 ステーキング関連トラックの概要

@SakingRewards によるイーサリアム ステーキング エコシステムの部門を参照すると、下から検証者レイヤー、ステーキング レイヤー、ブリッジング レイヤー、DeFi インフラストラクチャ レイヤー、および最上位の構造化製品レイヤーに分割できます。内部の論理関係とそれぞれの値は次のように要約できます。

  • ベリファイアー層: P2P やステークフィッシュなどのノードオペレーターに代表され、ステーキング層またはソロステーキング顧客に最低レベルのハードウェアリソースを提供します。これらには、DVT テクノロジーを提供するサービス プロバイダーの SSV および Obol も含まれます。検証者層は、誓約層のハードウェア関連の問題を解決します。

  • プレッジレイヤー: Lido と Rocket Pool に代表されるプレッジサービスプロバイダーは、委任者から資金を受け取り、委任者に代わってノードオペレーターとインターフェースをとり、再ステークの概念を提案したEigenLayer を含むイーサリアムのコンセンサス検証を実行します。プレッジ層は、委任者の PoS への間接的な参加を金融商品にカプセル化し、参加のしきい値を下げ、より多くのプレッジシェアをイーサリアムに導入します。

  • ブリッジ層: これは、ステーキング層によって発行された LST (リキッド ステーキング トークン) を指します。ユーザーは LST を通じてさまざまな DeFi プロトコルに参加します。ステーキング サービス プロバイダーは、LST-ETH 取引ペアを Curve などのプロトコルに追加して、委任者に引き出しのための流動性を提供します。ステーキングに参加する委任者の機会費用を削減します。

  • DeFiインフラストラクチャと構造化された製品レイヤー:LSTの価値ストレージと収益性を利用して、派生製品やサービスを開発し、より多くのLSTアプリケーションシナリオを作成し、DeFiエコシステムを強化し、ユーザーを惹きつけて参加させます。

V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

出典: https://twitter.com/SakingRewards/status/1711409661734219886/photo/1

ステーキング エコシステムでは、ステーキング層が過去と次をつなぐ中心的な役割を果たします。つまり、より多くのステーキング株式をイーサリアムに導入し、LST を通じて DeFi システムに流動性を提供します。プレッジ レイヤーの中核的な位置により、それ自体の変更がプレッジ エコシステム全体に変化を引き起こすことができるため、関連するソリューションがプレッジ レイヤー プロジェクトに与える影響の分析に重点を置きます。この記事のステーキング トラックは主にステーキング レイヤーを指します。

3.2 上記のソリューションがステーキングトラックに及ぼす潜在的な影響

上記のソリューションの実装の角度は異なりますが、それらはすべてステーキングトラックに影響を与えます。以下では、さまざまなソリューションの影響を分析し、対応するソリューションの採用の実現可能性を推測します。

3.2.1 Expanding delegate selection powers

以下は、ヴィタリック氏が言及した委任者の選択肢を拡大するための 3 つの選択肢の潜在的な影響の簡単な分析です。

  • プール内の投票ツールを最適化します (プール内のより良い投票ツール): つまり、ステーキング プール内の投票を最適化し、プール内のユーザーが独自のノード オペレーターを選択できるようにします。

  • 潜在的な影響: ステーキング サービス プロバイダー自体をより分散化することはできますが、ユーザーは主要なステーキング サービス プロバイダーをより信頼できるため、ステーキング トラックの集中を軽減することはできません。元々ステーキング サービス プロバイダーによってより制御されていたオペレーターのオプションは、その一部が委任者に転送されるため、元のガバナンス トークンの価値取得が減少する可能性があります。

  • 採用可能性分析

    • 全体的なコストは小さいです。イーサリアムのコンセンサス層を変更する必要はなく、プレッジ サービス プロバイダーが独自のメカニズムを変更するだけで済みます。

    • 既存のステーキング サービス プロバイダーに対するインセンティブの欠如: このソリューションでは、既存のステーキング サービス プロバイダーが積極的に変更し、開発コストやガバナンス トークンの有用性の低下によるコストなど、より大きなコストを負担する必要があります。

  • 概要: プレッジの集中化の問題は部分的に解決されますが、コンセンサス負荷の問題は解決できず、最終的な効果は平均的なものになる可能性があります。導入コストは低いですが、既存のプレッジサービスプロバイダーにはそれを行うインセンティブがなく、導入する可能性は低くなります。この機能を使用して市場に参入する新しいステーキング サービス プロバイダーが存在する可能性があります。

  • プール間の競争を強化する(プール間の競争を増やす):つまり、デリゲーターに豊富な選択肢を与えるために、ステーキングプール間の競争を強化します。現時点で、ユーザーを引き付ける際の異なるステーキングプール間の主な違いは、LST の流動性、信頼性、および dapp の受け入れにあります。 Vitalik氏は、上記の3つの違いを減らし、プレッジサービスプロバイダー間の競争を強化するために、スラッシュの量を減らし、統一されたLST標準を導入することを提案しました。

  • 潜在的な影響: ステーキングサービスプロバイダー間の差異が減少し、Lido などの主要プロジェクトの市場シェアが減少し、ステーキングトラックの集中化が減少します。対応する dapp がより多くの LST ステーキングプールをサポートできるため、LSTfi エコシステムがより繁栄する可能性があります。 ; ステーキングサービス商工会議所 他の側面での差別化を図るために、競争の方向性は、特に MEV 撤退戦略において、LST 自体のステーキング収入に向かう可能性があります。

  • 採用可能性分析

  • 全体的なコストは中程度です。このソリューションでは、イーサリアム コンセンサス層への変更は必要なく、新しい LST トークン標準の導入と、ユーザーのスラッシュ シェアと新しいLST規格を採用。ただし、採用プロセス中に、多数の既存の LST 保有者が自分の LST を新しい統一標準 LST に交換する必要があるため、ここで多額の移行コストがかかります。

  • 既存のプレッジ サービス プロバイダーに対するインセンティブの欠如: このソリューションでは、既存のプレッジ サービス プロバイダーが事前に特定の変更を加え、一定のアップグレードおよび開発コストを負担し、多額の LST 変換コストとリスクを伴う必要があります。このソリューションの採用により、既存のサービスプロバイダーは市場シェアの低下による圧力にも直面しています。

  • 要約: 誓約の集中化の問題はかなりの程度解決されましたが、コンセンサスロードの問題は解決できず、問題の解決は不完全です。全体的な導入コストは中程度ですが、既存の質権サービスプロバイダーにはそれを行うインセンティブがなく、導入の可能性は低いです。この機能を使用して市場に参入する新しいステーキング サービス プロバイダーが存在する可能性があります。

  • ネイティブ統合委任 (Enshrined delegation): ユーザーがノードオペレーターを直接選択する、イーサリアムが独自の LST トークン標準を立ち上げるなど、上記の関連する委任機能をイーサリアムプロトコル層に直接組み込みます。

  • 潜在的な影響: 前述のプール間競争方式と同じ影響ですが、イーサリアム プロトコル層のサポートにより、対応する変換のセキュリティがある程度確保されます。ユーザーがイーサリアムプロトコル層での委任に参加すると、イーサリアムコンセンサスに対する検証作業が増えるため、イーサリアムコンセンサスの負担が増加する可能性があります。

  • 実現可能性分析を導入する

  • 全体的なコストは高くなります。関連する委任機能をネイティブにサポートするには、イーサリアム コンセンサス レイヤーをアップグレードする必要があります。

  • これはアップグレードの本来の意図に反する可能性があります: イーサリアムに対するコンセンサスの負担が増加します; 委任者がプロトコル レベルでホスティングするノード オペレーターを直接選択する方法は本質的に DPoS に近く、これは Vitalik が望んでいない結果である可能性があります。見る。

  • 概要: これにより、誓約の一元化の問題は大幅に解決されますが、コンセンサス負荷の問題が増加します。同時に、アップグレードのコストは比較的高額であり、イーサリアムに特定の変更を加える必要があります。採用される可能性は非常に低いです。

3.2.2 Consensus participation

コンセンサス参加の基本的な考え方は、より単純なバリデータがコンセンサスに参加できるようにすることです。2 つのソリューションの違いは、イーサリアムのネイティブ統合を通じて実装されるか、サードパーティ プロジェクト内で実装されるかです。

3.2.2.1 ネイティブ統合

Vitalik 氏のアイデアによれば、イーサリアムのネイティブ統合ソリューションは、ネットワークを 2 つのグループ (複雑なバリデーターと単純なバリデーター) に直接分割します。複雑なバリデーターの誓約しきい値は 2048 ETH に増加され、バリデーターの数は 10,000 に制限されます。バリデーターはリアルタイムでオンラインに留まり、主な検証と計算作業を担当する必要があります。一方、単純な検証では、バリデーターを使用する必要があるだけです。軽量クライアントを実行するための独自の機器。特定の時間にコンセンサスに参加し、投票などの軽量タスクのみを実行します。

注: 2048 ETH は元の記事で Vitalik によって示された例ですが、その後の計画で採用される数字になる可能性が高くなります。記事内のVitalikとの組み合わせ元の記事で Vitalik が引用した EIP-7251 の説明とから、このデータには実用的な意味があることがわかります。2048 ETH は、平衡状態にあるバリデーターの数を理想的なレベルに制限し、イーサリアムのコンセンサス負担を軽減できます。 . SSF実装への道を切り開く。同時にVitalik氏は、実用的なアプローチを提案しました: イーサリアムはまず移行としてEIP-7251を統合することができます。つまり、バリデーター残高の上限を2048 ETHに増やし、下限の32 ETHを維持し、その後、全体として2048 ETHを使用します。誓約制限: バリデーターが独自の層を選択できるようにするため。要約すると、次の分析で分析に 2048 ETH という数値を使用することには、大きな参照価値があることがわかります。

V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

出典: https://notes.ethereum.org/@vbuterin/single_slot_finality

  • 潜在的な影響

  • 誓約の集中化とイーサリアムコンセンサスの負荷問題を同時に解決できます。ネイティブ統合により、大多数の委任者やその他の一般ユーザーがシンプルかつ低コストの方法でコンセンサスに参加できるようになり、分散化が大幅に改善されます。複雑なバリデーターの数の制限により、コンセンサスに達することの難しさと各スロットの署名の合計サイズが軽減され、イーサリアムに対するコンセンサスの負担が軽減されます。

  • プレッジサービスプロバイダーのサービスや DVT などのセキュリティ技術の価値はさらに高まり、普及率はさらに向上します。単一の複雑な検証者は、より積極的なネットワーク検証を実行し、非常に高いオンライン速度を確保する必要があるため、関連するハードウェア運用 次元のしきい値が増加するにつれて、DVT などのセキュリティ技術の価値がさらに強調される; 2048 ETH のプレッジしきい値により、当初はソロでプレッジできたほとんどのユーザーが委任者に頼るようになる; 上記に基づいて、プレッジ サービス プロバイダーの普及率DVT などの技術サービスプロバイダーも増加します。

  • ステーキング トラックの市場規模には上限があるでしょう。Vitalik のビジョンでは、単純なバリデーターがコンセンサスに参加する方法は、独自に超軽量ノードを実行することです。委任者部分からのプレッジされた ETH は、プレッジ サービス プロバイダーに追加の TVL を作成しません。また、単純なバリデーターとなる他のユーザーは、プレッジ サービス プロバイダーを通じて委任者になる必要はありません。なぜなら、彼ら自身がウルトラライト ノードを実行する必要があり、誓約者サービスプロバイダーのためにそれらをホストし、対応するホスティング料金を支払う必要はありません。したがって、ステーキングサービスプロバイダーが獲得できるTVLは2,048万ETHの上限に達します。

  • 質権サービスプロバイダーおよび関連プロジェクトの長期的な成長は停滞する可能性がある

  • 短中期的にはまだスペースがあるが、動機は不十分であり、現在の市場規模から判断すると、EIP-1559とマージ後、ETHの総供給量は約1億2000万で安定している。約2,800万、プレッジ率は約23.29%とステーキングトラックにはまだ改善の余地があるが、出入りするバリデーターの行列状況から判断すると、ETHステーキングの増加は減少に伴いボトルネックとなっている。オンチェーン取引量が増加しなければ、MEV 収入が大幅に増加すると、プレッジ数は安定した均衡状態に陥り、成長に勢いが欠けてしまいます。

  • 質権サービスプロバイダーや DVT などのテクノロジープロジェクトの成長は長期的には停滞します。Lido に代表される質権サービスプロバイダーから SSV に代表される DVT プロジェクトに至るまで、その収入モデルは、その質権収入に対して一定の割合の手数料を請求することになっています。資金の一部です。委任者の資金の上限が 2,048 万 ETH である場合、この部分の資金は現在の 2,800 万 ETH よりも少なくなりますが、将来の MEV 収入が十分に増加しない場合 (つまり、プレッジ率が十分に増加しない場合)、ステーキングトラックの絶対的な収入規模は減少するどころか増加することはなく、長期的には成長の源泉はありません。

V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

ソース:https://etherscan.io/chart/ethersupplygrowth

V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

ソース:https://www.validatorqueue.com/

  • 採用可能性分析

  • 全体的なコストは膨大です。イーサリアムのコンセンサス参加ルールを変更する必要があります。

  • イーサリアムの長期的な開発利益に沿って、長期的にはバリデーターの階層化アーキテクチャが導入される可能性があります。

    • イーサリアムの長期的な開発目標の 1 つは、バリデーターの同様の階層化アーキテクチャの導入を必要としています。ブロックが大きくなるにつれて (状態拡張の問題)、将来的には数百の大きなノードだけが完全なノードを実行する条件を備えることになると指摘しました。イーサリアムは、より多くの人がコンセンサスに参加できるようにする別の軽量な方法を見つける必要があります。許容できる信頼性のなさと検閲への抵抗。同時に、イーサリアムのパフォーマンスとセキュリティを向上させるシングルスロット決定論 (SSF) などの機能を実現するには、2 種類のバリデーターも連携して動作する必要があります。 2 種類のバリデーターには異なる責任があり、異なるステーキング ルール (階層化) を適用する方が合理的です。

    • バリデーターの階層構造は、イーサリアムのロードマップや関連記事で何度も登場しており、単純なバリデーターがコンセンサスに参加するための条件を作り出すことを目的として、多数の軽量クライアント関連ソリューションが計画および研究中です。

    1. PBS や Danksharding などの重要なアップグレードからも、階層化と分業に関する同様のアイデアが見られます。プロのノードに、より困難な作業 (BLOB やビルディング ブロックの保存など) を引き受けさせて効率を確保し、より軽量なノードをコンセンサスに参加させて、分散化を確保する。

    2. から主なアイデアから、検証の SNARK 化 (軽量化) は、単純な検証者がコンセンサスに参加するための参照方法を提供することであることがわかります。また、イーサリアムのロードマップでは、ステートレス、The Verge などの関連研究がすべて、ユーザーが超軽量ノードを実行できるように準備を進めていることがわかります。

V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

ヴィタリック: エンドゲーム、出典:https://vitalik.ca/general/2021/12/06/endgame.html

V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

The Verge 関連コンテンツ、出典:https://twitter.com/VitalikButerin/status/1588669782471368704

  • 概要: プレッジの集中化とコンセンサス負荷の問題を同時に解決できます。導入コストは非常に高く、イーサリアムのコンセンサス層での PoS ルールの変更が必要ですが、これはイーサリアムの長期的な開発利益と一致しており、関連する準備はイーサリアムのロードマップに部分的に反映されています。長期的には採用の可能性はありますが、短期的に実現する可能性は低いです。

3.2.2.2 サードパーティプロジェクトの統合

Vitalik氏はまた、イーサリアムのネイティブサポートなしでステーキングプールを通じてのみ実装される実装計画も提案しました。その核心は、検証者の秘密鍵をそれぞれ P と Q の 2 つの部分に分割し、それぞれ検証ノードとユーザーに渡し、ユーザーが P と Q の共同署名を通じてコン​​センサスに参加できるようにすることです。

  • 潜在的な影響: ステーキングサーバーの集中化の問題をある程度解決できますが、ユーザーの参加プロセスが比較的複雑であり、参加意欲が低い可能性があるため、効果は不確実です。この計画は、どちらかというと質権サービスプロバイダーの内部調整であり、トラックのレイアウトにはほとんど影響しません。

  • 実現可能性分析を導入する

  • 適度な実装コスト: イーサリアムのコンセンサス層に大きな変更は必要ありませんが、既存のプレッジ サービス プロバイダーは、鍵の分割、保管、共同署名の設計を含む、より複雑なアップグレードを実行する必要があると同時に、ユーザーを単純なコンセンサスに参加させる必要があります。検証。

  • プレッジ サービス プロバイダーが負担するコストが増加し、既存のプロジェクトがアップグレードする動機にならない可能性があります。まず、バリデーター秘密鍵の分割と保管、そして第 2 にユーザー UX の設計により、既存のプレッジ サービス プロバイダーに一定のアップグレード コストが発生します。しかし、既存のサービスプロバイダーにこれ以上の利益をもたらすことは困難です。

  • 検証ロジックが複雑になると、イーサリアムの作業負荷が増加する可能性があります。より複雑な検証ロジックには、P と Q によって署名されたメッセージの比較などが含まれます。

  • 概要: プレッジサーバーの集中化の問題をある程度解決できますが、その効果は不確実であり、トラックプロジェクトのパターンへの影響はほとんどありません。既存のプロジェクトがこれを採用する可能性は低いですが、新しいステーキング サービス プロバイダーがこの機能を使用して市場に参入する可能性があります。

3.3 概要

Vitalik氏は記事の中で特定のソリューションに対する好みを明確に表明していませんでしたが、ソリューションの効果と影響を分析し、Vitalik氏の以前の記事とイーサリアムのロードマップからの情報を組み合わせることで、何が起こるかを推測することはできます。

  • 代表者選択権限の拡大に向けた 3 つの解決策

  1. 問題は完全には解決されていません。代表者選択権限の拡大に関連する解決策は主に誓約集中の問題に対して最適化されていますが、解決策の効果は不確実です。デリゲートステーキングプールを中心とする現在の 2 層ステーキング構造は本質的にすでに DPoS に近いため、デリゲート選択権限を拡大するソリューションは既存の構造を壊すものではなく、DPoS の特性を強調することさえできるかもしれません。同時に、この関連ソリューションはイーサリアムのコンセンサス負荷の問題を解決するものではなく、委任をネイティブに統合するソリューションもイーサリアムのコンセンサスの負担を増加させる可能性があります。

  2. 既存のプレイヤーが採用するインセンティブは小さい:この方向の解決策は既存のプレッジサービスプロバイダーの利益を損なうことになると同時に、プール内選挙を最適化しプール間競争を強化するソリューションもプレッジサービスプロバイダーの支援を必要とするしたがって、既存のプレッジ サービス プロバイダーには、関連するソリューションを採用するインセンティブがほとんどありません。

  3. 短期的には、新しいプロジェクトに採用される可能性があります。新しいステーキング サービス プロバイダーは、市場に参入し、既存のプロジェクトと競合するためのより分散型の機能としてこれを使用する可能性があります。

  • コンセンサス参加に向けた解決策について

  1. ネイティブ サポート ソリューションは長期的なソリューションになる可能性があります。ネイティブ サポート ソリューションは、Vitalik が言及したステーキングの集中化とイーサリアムのコンセンサス負荷の問題を同時に解決できます。一方、同様の階層化されたバリデーター アーキテクチャを実装する準備が進行中です。短期的に達成するのは難しいですが、長期的には十分可能です。

  2. 代表者選択権限の拡大と比較すると、サードパーティ統合ソリューションは誓約の一元化の問題を大幅に解決できますが、コンセンサス負荷の問題は解決できません。デリゲート選択権限の拡大と同様に、既存プレーヤーがこの機能を導入するインセンティブが小さいという問題もありますが、短期的には、新しいステーキングサービスプロバイダーがこの機能を利用して市場に参入する可能性があります。

V God のステーキングに関する長い記事を詳しく読んでください: 彼のコンセプトはステーキング トラックにどのような影響を与えるでしょうか?

4. 結論

Vitalik の多くのスピーチや記事には、イーサリアムは中立的かつミニマリストであり続けるべきであるという核となる考えが見られます。多くの機能 (アカウントの抽象化、流動性ステーキング サービス、プライバシー アカウントなど) によってイーサリアムの競争力は向上しましたが、イーサリアムはすべての機能を直接統合することを選択したわけではなく、一部の機能の構築をサードパーティ プロジェクトに任せています。多くのサードパーティプロジェクトも、イーサリアムが残した提案にうまく答え、独自の市場でのポジショニングを見つけました。ただし、イーサリアム自体が進化し続けるにつれて、サードパーティのプロジェクトが直面する問題と機会も変化しています。これらの参加者にとって、これは適応力を試すだけでなく、将来について深く考え、終盤のチャンスを予測して掴む時間でもあります。

この記事の分析では、Vitalik の仮定に基づいて、現在のステーキング トラック関連プロジェクトが将来直面する可能性のある変数について包括的な演繹を試みました。 Vitalik氏は関連記事でイーサリアムの終了の可能性を計画しているが、現在の計画は新たな市場の需要や技術の進歩によって変更される可能性があるため、将来は依然として不確実性に満ちている。この絶えず変化するシナリオでは、ゲーム終盤の思考と現在のウィンドウ ボーナスを獲得する能力を備えたプレイヤーだけが、長期的なレースで優位に立つことができます。

参考文献

オリジナル記事、著者:Mint Ventures。転載/コンテンツ連携/記事探しはご連絡ください report@odaily.email;法に違反して転載するには必ず追究しなければならない

ODAILYは、多くの読者が正しい貨幣観念と投資理念を確立し、ブロックチェーンを理性的に見て、リスク意識を確実に高めてください、発見された違法犯罪の手がかりについては、積極的に関係部門に通報することができる。

おすすめの読み物
編集者の選択