Vitalikの最新研究：LSDFiプロトコルと流動性は、分散化を高め、コンセンサス過負荷を減らすためにどのように変わるべきか？

本稿では、現在のLSDFiプロトコルおよび流動性プールに存在するノードオペレーターの中央集権リスクと不要なコンセンサス負担という2つの課題に焦点を当てます。

執筆：Vitalik Buterin

翻訳：bayemon.eth, ChainCatcher

現在のEthereumの発展状況は、多くの二重ステーキング（two-tiered staking）を含んでいると言えます。ここで言う二重ステーキングとは、2種類の参加者が存在するステーキングモデルを指します。

• ノードオペレーター（Node Operator）：ノードを運営し、自身の評判や一定額の自己資本を担保として差し入れる
• デリゲーター（Delegator）：デリゲーターは一定量のEthereumをステーキングし、最低額の制限はなく、担保以外の参加方法にも追加の制限はありません

この新興の二重ステーキングは、多くの参加者が流動性ステーキングトークン（LST）を提供するステーキングプールによって生み出されています。（Rocket PoolやLidoはいずれもこのモデルです）。

しかし、現在の二重ステーキングには2つの欠点があります：

• ノードオペレーターの中央集権リスク：現在すべてのステーキングプールにおいてノードオペレーターの選定メカニズムが依然として過度に中央集権的である
• 不要なコンセンサス負担：Ethereum L1は各Epochごとに約800,000の署名を検証する必要があり、これは単一のslotにとって非常に大きな負荷です。さらに、流動性ステーキングプールには多くの資金が必要ですが、ネットワーク自体はこの負荷から十分な利益を得ていません。したがって、Ethereumネットワークが合理的な分散性と安全性を実現でき、各ステーキング参加者が毎回署名する必要がなければ、コミュニティはこのようなソリューションを採用し、各slotの署名数を効果的に削減できます。

本稿では上記2つの問題を解決するためのソリューションについて述べます。まず仮定として、大部分の資本は現在の形で自らステーキングノードを管理したくない人々が保有しており、各slotで情報に署名し、預金をロックし、資金が削減された者に再配分することを望まないとします。この場合、これらの人々はどのような役割を果たし、ネットワークの分散化と安全性に引き続き有意義な貢献ができるのでしょうか？

現在の二重ステーキングはどのように機能しているか？

現在最も人気のある2つのステーキングプールはLidoとRocketPoolです。Lidoの場合、参加者は次の2者です：

• ノードオペレーター：Lido DAOの投票によって選出され、これは実質的にLDO保有者によって選ばれます。誰かがETHをLidoスマートコントラクトシステムに預けるとstETHが作成され、ノードオペレーターはそれをステーキングプールに投入できます（ただし、引き出し証明書はスマートコントラクトアドレスに紐付いているため、オペレーターは自由に引き出せません）
• デリゲーター：誰かがETHをLidoスマートコントラクトシステムに預けるとstETHが発行され、ノードオペレーターはそれをステーキングに利用できます（同様に、引き出し証明書はスマートコントラクトアドレスに紐付いているため、オペレーターは自由に引き出せません）

Rocket Poolの場合は次の通りです：

• ノードオペレーター：誰でもノードオペレーターになれます。8ETHと一定量のRPLトークンを提出するだけです。
• デリゲーター：誰かがETHをRocket Poolスマートコントラクトシステムに預けるとrETHが発行され、ノードオペレーターはそれをステーキングに利用できます（同様に、引き出し証明書はスマートコントラクトアドレスに紐付いているため、オペレーターは自由に引き出せません）。

デリゲーターの役割

これらのシステム（または将来のプロトコル変更によって有効化される新しいシステム）において、プロトコルの観点からデリゲーターを設ける意味は何かという重要な問いがあります。

この問いの本質を理解するために、まず投稿で言及されたプロトコル変更、すなわちスラッシュペナルティを2ETHに制限する場合を考えます。Rocket Poolもノードオペレーターのステーキング額を2ETHに下げ、市場シェアが100%になると仮定します（ステーキング参加者やETH保有者にとって、rETHがリスクフリーになるため、ほぼすべてのETH保有者がrETH保有者またはノードオペレーターになるでしょう）。

rETH保有者のリターンは3%（プロトコル内報酬と優先手数料＋MEVを含む）、ノードオペレーターのリターンは4%と仮定します。また、ETHの総供給量は100 millionsとします。

計算結果は以下の通りです。複利計算を避けるため、日単位で収益を計算します：

今、Rocket Poolが存在しないと仮定すると、各ステーキング参加者の最低預入額は2ETHに下がり、流動性総量の上限は6.25 millions ETHとなり、ノードオペレーターのリターンは1%に下がります。再度計算します：

攻撃コストの観点からこの2つのケースを考えます。最初のケースでは、攻撃者はデリゲーターとして登録しません。なぜなら、デリゲーターは本質的に引き出し権限を持たないため意味がないからです。したがって、彼らはすべてのETHをステーキングしてノードオペレーターになります。ステーキング総量の1/3に到達するには2.08 millions ETHを投入する必要があります（公平に言えば、これは依然としてかなり大きな数字です）。2つ目のケースでは、攻撃者は資金を投入するだけで、ステーキングプール総量の1/3に到達するにはやはり2.08 millions ETHが必要です。

ステーキング経済学と攻撃コストの観点から、2つのケースの最終結果は全く同じです。ノードオペレーターが保有するETHの総供給量シェアは毎日0.00256%増加し、非ノードオペレーターが保有するETHの総供給量シェアは毎日0.00017%減少します。攻撃コストは2.08 millions ETHです。したがって、このモデルではデリゲーターは意味のないRube Goldbergマシンとなり、合理的なコミュニティは中間者を排除し、報酬を大幅に減らし、ステーキングETH総量を6.25 millionsに制限することを選ぶでしょう。

もちろん、本稿はステーキング報酬を4分の1に減らし、総量上限を6.25 millionsに固定することを主張するものではありません。むしろ、本稿の主張は、うまく機能するステーキングシステムには重要な属性が必要であり、デリゲーターがシステム全体で重要な責任を担うべきだということです。さらに、デリゲーターがコミュニティの圧力や利他的な動機によって正しい行動を取る場合でも問題ありません。結局のところ、これこそが今日、分散化と高い安全性を持つステーキングソリューションを推進する主な力なのです。

デリゲーターの責任

デリゲーターがステーキングシステムで有意義な役割を果たせるとしたら、その役割は何でしょうか？

私は2つの答えがあると考えます：

• デリゲーターの選択：デリゲーターは自分の利害をどのノードオペレーターに委任するかを選択できます。ノードオペレーターのコンセンサスメカニズムにおける「重み」は、委任された総ステーキング量に比例します。現在、デリゲーターの選択メカニズムは限定的で、rETHやstETH保有者はETHを引き出して他のプールに切り替えることができますが、実際の選択肢は大幅に向上可能です。
• コンセンサスメカニズムへの参加：デリゲーターはコンセンサスメカニズムで一定の役割を果たすことができ、全額ステーキングよりも責任は軽く、長い退出期間やスラッシュリスクもありませんが、ノードオペレーターの抑制役を担うことができます。

デリゲーターの選択権強化

代表選択権を強化する方法は3つあります：

• プール内の投票ツールを改善する
• プール間の競争を増やす
• 代表権を固定化する

現在、プール内での投票は実際には現実的ではありません。Rocket Poolでは誰でもノードオペレーターになれますが、LidoではLDO保有者が投票権を持ち、ETH保有者ではありません。LidoはLDO＋stETHの二重ガバナンス提案を出しており、保護メカニズムを有効化して新たな投票を阻止し、ノードオペレーターの追加や削除を防ぐことができます。これによりstETH保有者にも発言権が与えられますが、依然として限定的であり、より強力にすることが可能です。

プール間の競争は現在も存在しますが、比較的弱いです。主な課題は、小規模なステーキングプールのステーキングトークンの流動性が低く、信頼を得にくく、アプリケーションのサポートも少ないことです。

ペナルティ額を2または4ETHなどの小額に制限することで、最初の2つの問題を改善できます。残りのETHは安全に預け入れ・即時引き出しが可能となり、小規模なステーキングプールでも双方向交換が成立します。LSTを管理するための総発行コントラクト（ERC-4337やERC-6900のようなウォレット用コントラクトに類似）を作成することで、発行されたすべてのステーキングトークンの安全性を保証できます。

現在、プロトコル内に固定化された代表権は存在しませんが、将来的にはこのようなケースもあり得ます。これは上記のアイデアと同様のロジックをプロトコルレベルで実装することを意味します。固定化の長所と短所については、この記事を参照してください。

これらのアイデアは現状の改善ですが、提供できる利点は限定的です。トークン投票ガバナンスには問題があり、最終的にどのような非インセンティブ型の代理選択もトークン投票の一形態に過ぎません。これは私がDelegated Proof of Stakeに対して持つ主な不満の一つです。したがって、より強力なコンセンサス参加方式の実現を検討する価値があります。

コンセンサス参加

流動性ステーキングの現在の問題を考慮しなくても、現在の独立ステーキング方式には制限があります。single-slot finalityを使用すると仮定すると、理想的には各slotで約100,000～1,000,000のBLS署名を処理できます。たとえ再帰的SNARKsで署名を集約しても、署名の追跡性のために各署名に参加者のビットフィールドを割り当てる必要があります。Ethereumがグローバル規模のネットワークになれば、完全分散型のビットフィールドストレージでも十分ではありません。各slotの16MBでは約6,400万のステーキング参加者しかサポートできません。

この観点から、ステーキングをより高い複雑度のスラッシュ可能なレイヤーと、より低い複雑度のレイヤーに分けることは価値があります。高複雑度のレイヤーは各slotで有効ですが、参加者は1万人程度に制限され、低複雑度のレイヤーは時折呼び出されて参加します。低複雑度のレイヤーはスラッシュを完全に免除するか、ランダムに参加者に数slot内で預け入れ・スラッシュの機会を与えることができます。

実際には、バリデータの残高上限を引き上げ、その後残高閾値（例：2048ETH）を増やすことで、どのバリデータが高複雑度または低複雑度レイヤーに入るかを決定できます。

以下は、これらの小規模ステーキング役割がどのように機能するかについての提案です：

• 各slotで、1万人の小規模ステーキング参加者がランダムに選ばれ、そのslotを代表する内容に署名できます。小規模ステーキング参加者を入力としてLMD GHOSTフォーク選択ルールを実行します。小規模ステーキング参加者主導のフォーク選択とノードオペレーター主導のフォーク選択に一定の乖離がある場合、ユーザーのクライアントはどのブロックも最終確定として受け入れず、エラーを表示します。これによりコミュニティが介入して状況を解決することを強制します。
• デリゲーターはトランザクションを送信し、ネットワークに対してオンラインであり、次の1時間小規模ステーキング参加者として活動する意思があることを宣言できます。ノードが送信するメッセージ（ブロックや証明）の計算には、ノードとランダムに選ばれたデリゲーターの両方がノードの確認情報に署名する必要があります。
• デリゲーターはトランザクションを送信し、ネットワークに対してオンラインであり、次の1時間小規模ステーキング参加者として活動する意思があることを宣言できます。各エポックで、10人のランダムなデリゲーターがinclusion list providerとして選ばれ、さらに1万人のデリゲーターが投票者として選ばれます。これらはk-slot前に選ばれ、k slotのウィンドウ内でチェーン上にオンラインであることを確認するメッセージを投稿できます。確認されたinclusion list providerはinclusion listを公開でき、各inclusion listについて、そのリスト内のトランザクションを含めるか、一般的な1人の投票者による「リストが利用不可」という投票を含める必要があり、そうでなければブロックは無効と見なされます。

これらの小規模ステーキングノードの共通点は、各slotで積極的に参加する必要がなく、軽量ノードだけで全ての作業が可能なことです。したがって、ノードのデプロイはコンセンサスレイヤーの検証だけで済み、ノードオペレーターはアプリやブラウザ拡張機能を通じて実装できます。これらのアプリや拡張機能はほとんどが受動的で、計算負荷やハードウェア要件、技術的知識の要求も低く、ZK-EVMのような先進技術すら不要です。

これらの「小さな役割」には共通の目標もあります：51%の多数ノードオペレーターによるトランザクション検閲を防ぐことです。1つ目と2つ目は大多数によるファイナリティの巻き戻しも防げます。3つ目はより直接的に検閲に焦点を当てますが、多数ノードオペレーターの選択の影響を受けやすいです。

これらのアイデアは、プロトコルに実装する二重ステーキングソリューションの観点から書かれていますが、ステーキングプールの機能としても実装可能です。以下は具体的な実装アイデアです：

1. プロトコルの観点では、各バリデータが2つのステーキングキーを設定できます：1つは継続的なステーキングキーP、もう1つは呼び出し可能なEthereumアドレスにバインドされ、迅速なステーキングキーQを出力します。ノードのフォーク選択署名情報はPで追跡し、署名情報はQで表現します。PQのストレージ結果が一致しない場合、どのブロックも最終確定として受け入れず、流動性プールがランダムに代表を選びます。
2. プロトコルは基本的に変わりませんが、そのバリデータの公開鍵はそのslotでP+Qに設定されます。スラッシュに関しては、2つのスラッシュ可能なメッセージが異なるQキーを持つ場合がありますが、同じPキーを持ちます。スラッシュ設計はこの状況に対応する必要があります。
3. Qキーはプロトコル内でブロックのinclusion listへの署名と検証にのみ使用されます。この場合、Qは単一のキーではなくスマートコントラクトでもよいので、ステーキングプールはより複雑な投票ロジックを実装し、ランダムに選ばれたプロバイダーからのinclusion listや、十分な数の「リストが利用不可」という投票を受け入れることができます。

結論

適切に実装すれば、Proof of Stake設計の微調整で2つの問題を一挙に解決できます：

• 今日、独立してProof of Stakeを運用するリソースや能力のない人々にも、Proof of Stakeに参加する機会を提供し、より多くの権限を彼らの手に残すことができます：（i）どのノードをサポートするかを選択する権限、（ii）完全なノード運用よりも軽量だが依然として意義のある方法でコンセンサスに積極的に参加する権限。すべての参加者が1つまたは2つの選択肢を選ぶわけではありませんが、どちらかを選んだ参加者は現状より大きな改善を享受できます。
• Ethereumコンセンサスレイヤーが各slotで処理する署名数を削減し、single slot finality制度下でも約1万人程度の小規模な数に減らせます。これにより分散化が促進され、誰でもバリデータノードを運用しやすくなります。

これらのソリューションについては、異なる抽象レイヤーで問題解決の方法を見つけることができます：Proof of Stakeプロトコル内でユーザーに権限を与える、Proof of Stakeプロトコル間でユーザーが選択する、プロトコル内で設立するなどです。この選択は慎重に検討すべきであり、通常は最小限の設立を選ぶことで、プロトコルの複雑性や経済設計への影響を最小限に抑えつつ、期待される目標を達成するのが最善です。

特に、Mike Neuder、Justin Drake、および他の方々のフィードバックとレビューに感謝します。また、Mike Neuder、Dankrad Feist、arixon.ethによる類似テーマの記事もご参照ください。