著者: Hank Han、Mint Ventures 研究員

1. はじめに

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

10月7日に公開された「<プロトコルとステーキングプールの変更により、分散化を改善し、コンセンサスオーバーヘッドを削減できる」というタイトルの記事で、Vitalik氏は、現在のイーサリアムステーキングメカニズムを最適化し、イーサリアムの集中化をさらに削減するための参照パスを提供しました。コンセンサスロード。これらのアイデアのいくつかはステーキングメカニズムに大きな変化をもたらし、イーサリアム開発の主な傾向と一致しているため、記事を解釈し、さまざまなソリューションがステーキングトラックに与える潜在的な影響を分析します。

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 はイーサリアムのロードマップ (参考: https://twitter.com/VitalikButerin/status/1588669782471368704/photo/1) のマージ ブランチに含まれており、イーサリアムの長期目標の 1 つです。しかし、イーサリアム関係者はSSFが数年以内にローンチされるとは予想しておらず、準備作業としてVerkle TreesやDankshardingなどの大規模なアップグレードが必要になるだろう。

2.3 解決策

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

2.3.1 代表者選出権限の拡大

委任者の選択権限を拡大するということは、委任者の選択肢を拡大することを意味し、委任者がステーキングサービスプロバイダーやノードオペレーターの選択においてより積極的な立場を持てるようになります。現時点では、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 合意に基づく参加

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

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

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

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

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

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

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

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

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

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

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

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

出典: https://notes.ethereum.org/@vbuterin/saking_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エコシステムを強化し、ユーザーを惹きつけて参加させます。

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

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

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

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

3.2.1 代表者選出権限の拡大

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

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

    • 潜在的な影響: ステーキング サービス プロバイダー自体をより分散化することはできますが、ユーザーは大手ステーキング サービス プロバイダーをより信頼できるようになるため、ステーキング サービス プロバイダー自身がより分散化することはできません。その一部が委任者に転送されるため、元のガバナンス トークンの価値取得が減少する可能性があります。

    • 採用可能性分析

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

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

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

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

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

    • 採用可能性分析

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

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

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

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

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

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

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

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

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

3.2.2 合意に基づく参加

コンセンサス参加の基本的な考え方は、より単純なバリデータがコンセンサスに参加できるようにすることです。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 という数値を使用することには、大きな参照価値があることがわかります。

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

  • 潜在的な影響

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

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

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

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

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

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

出典: https://etherscan.io/chart/ethersupplygrowth

出典: https://www.validatorqueue.com/

  • 採用可能性分析

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

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

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

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

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

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

<Vitalik: エンドゲーム>、出典: https://vitalik.ca/general/2021/12/06/endgame.html

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 つのオプション

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

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

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

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

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

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

4. 結論

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

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

参考文献

  • <分散化を改善し、コンセンサスのオーバーヘッドを削減できるプロトコルとステーキングプールの変更>

  • <Ethereum はプロトコルにさらに多くのものを組み込むことに問題ないでしょうか?>

  • <シングルスロットファイナリティへの道>

  • イーサリアムロードマップ: シングルスロットファイナリティ

  • <Proof of Stake の概要>

  • <ゴルディロックスを見つけられるか?Liquid Staking Token のネイティブ設計である「2 層」ステーキングについての考察。>

  • <エンドゲーム>

  • <The Beacon Chain Ethereum 2.0 の説明をまず読んでください>

  • EIP-7251 に関する FAQ; MAX_EFFECTIVE_BALANCE の増加 – HackMD