原文

Validator Redirected Revenue — clesaege (2026-06-21)

バリデーターによる収益リダイレクト

I. エグゼクティブサマリー

  1. イーサリアムは協調の失敗に陥っています。共有の改善から誰もが利益を得る一方で、他者がフリーライドできる状況では、どの単一アクターも費用を負担したがらないのです。これが持続的な死重損失を生み出し、イーサリアムの長期的な競争力を弱めています。

  2. 本提案は、プロトコルレベルで2つの変更を導入し、イーサリアムバリデータが設定する資金調達メカニズムを構築します。

  3. ステーキング報酬のエコシステム資金へのリダイレクト率(%): もし大半のバリデーターがステーキング収益の一部を割譲することに同意すれば、そのリダイレクト率はすべてのバリデーターにとって義務となります。

    リダイレクトの最大額はステーキング報酬の10%であり、これ以上増やすことはできません。一方、最小額は0%(現状維持)です。プロトコルレベルでは、パラメータ変更は(UP/DOWN/ABSTAIN)であり、UPまたはDOWNはリダイレクト額を固定レートeで増減させます。

  4. 推奨される資金受取人: バリデーターは、資金をリダイレクトしたい受取人アドレスに対する好みも示します。実行クライアントはこれらの静的な好みを取り込み、他のすべての可能な分割との直接対決で勝つ分割(コンドルセ勝者と呼ばれる解決概念)に基づいて、異なるアドレス間で資金を分割するスプリッターコントラクトについて合意に達します。

    プロトコルレベルでは、パラメータ変更は(KEEP/CHANGE/ABSTAIN)であり、KEEPは既存のスプリッターコントラクトを維持し、CHANGEはバリデーターが示した資金受取人の間でリダイレクトを分割する新しいスプリッターをもたらします。

  5. この設計の主な利点は、バリデーターがリダイレクト額と受取人アドレスに関する入力設定を「設定して忘れる」だけで済むため、ガバナンスオーバーヘッドが最小限に抑えられることです。残りの処理は実行クライアントが行います(実装には健全な多様性が期待されます)。もう一つの利点は、プロトコルレベルでのシンプルさです。プロトコルはリダイレクト額の「増減」と、リダイレクトされた資金の行き先を決定するスプリッターコントラクトの「維持または変更」のみを気にします。主な懸念は、設定を行うオペレーターと、彼らにETHを委任する人々との間のプリンシパル・エージェント問題です。

この投稿の目的は、提案された解決策への合意を得ることよりも、プロトコルレベルでの資金不足に対処する必要性、そして議論を促進するための「間違った答え」としての議論を促すことです。したがって、次のセクションでは、対処すべき主要な問題(イーサリアム経済における死重損失の削減)に焦点を当て、その後、なぜバリデーターがそれを解決する長期的なステークホルダーとなるインセンティブの整合性を持っているのかについて説明します。第4セクションと第5セクションでは、それぞれ提案された解決策とそれがもたらす未解決の課題について触れます。

II. イーサリアム経済におけるフリーライダー問題と死重損失

イーサリアムにおける資金調達の課題は、古典的な囚人のジレンマに似ています。

イーサリアムを気にかける2人のアクターを考えます。

  • どちらも貢献しない場合、両者とも資本を保持します。
  • 一方が貢献し、もう一方が貢献しない場合、貢献者は犠牲を払い、他の全員がその費用で利益を得ます。
  • 両者が貢献する場合、エコシステムは成長し、両者が利益を得ます。

囚人のジレンマがアクターが共有インフラに資金を供給するのを妨げる|624.0x132.0

キャプション: 共有インフラへの資金提供を妨げる囚人のジレンマ

3番目の結果が集合的に最適であるにもかかわらず、各個人は資金提供連合から離脱し、他者の貢献にフリーライドするインセンティブに直面します。

この力学により、イーサリアムは安定しているものの非効率な均衡に陥り、誰もが協調的な資金提供から利益を得るにもかかわらず、誰も貢献しない状態になります。

同じ問題は多くの経済システムで発生します。公共財への自発的な支払いは、他者が支払わずに利益を得られる場合、個人が貢献をためらうため、めったに成功しません。

これはイーサリアム経済に死重損失を生み出します。この概念は以下の例で説明できます。

  • 共有インフラの維持には年間50ドルかかります。
  • 6つのプロジェクトがそれに依存しています。
  • 各プロジェクトはインフラから10ドルの価値を得ます。

生み出される総価値は60ドルであり、50ドルのコストを上回ります。エコシステム全体から見れば、このプロジェクトは明らかに資金提供されるべきです。

経済学者は10ドルを死重損失と呼び、経済の競争力を低下させる回復不能なコストである|624.0x193.0

経済学者は10ドルを死重損失と呼び、経済の競争力を低下させる回復不能なコストである

しかし、どの単一プロジェクトも、個別に50ドル全額を支払うことを正当化するほどの価値を受け取りません。結果として、以下のいずれかになります。

  1. インフラは決して資金提供されない。たとえそれが集合的に全員に利益をもたらすとしても。
  2. イーサリアム財団がインフラに資金提供することで死重損失を削減する。直接的に、または関連するすべてのプロジェクトに10ドルを拠出させるための調整コストを負担することによって。
  3. 何らかの慈善家が介入して全費用を負担する。

死重損失を削減できる経済は、そうでない経済よりも優れたパフォーマンスを発揮する傾向があります。共有投資をうまく調整することは、課税のような強制的な手段を用いて死重損失を削減する伝統的な経済システムや、将来の成長のために収益を再投資する企業と競争するために不可欠です。

III. バリデーターはイーサリアムの成長から利益を得る

構造的なレベルで、バリデーターはイーサリアムの成長を支援する明確なインセンティブを持っています。

より多くのアプリケーション、ツール、インフラがイーサリアム上に構築されると、ブロックスペースの需要が増加します。ブロックスペースの需要が増加すると、ネットワークの経済活動と全体的なネットワーク価値が強化されます。

バリデーターはETHをステーキングし、ETH建ての報酬を得るため、以下の正のフィードバックループを通じてエコシステムの長期的な成長から直接利益を得ます。

  1. バリデーターがエコシステムの開発に資金提供する。
  2. エコシステムの開発がネットワーク需要を増加させる。
  3. 需要の増加がETHのバーンを増加させる。
  4. バリデーターはより高い価値の報酬と、ステークされた元本の価値上昇から利益を得る。

バリデーターはエコシステムの成長から利益を得る|624.0x380.0

この整合性にもかかわらず、DAOセキュリティファンドやOctantのような有望だが孤立した取り組みを除いて、バリデーターによる資金調達の調整があまり見られないのはなぜでしょうか?

私たちの仮説は、バリデーターが囚人のジレンマにおける非協力的な均衡に陥っているためです。彼らは非ゼロの金額で報酬を使ってエコシステムに資金提供することで大いに利益を得るでしょうが、他のバリデーターによる離反の現実が、彼らのほとんどを何も貢献しないことに躊躇させています。したがって、次のセクションでは、フリーライダー問題に対処するための解決策を提示します。

IV. バリデーターのリダイレクト: プロトコルレベルの調整メカニズム

核となるアイデアは、バリデーターが3つのことをシグナルする必要があるプロトコルレベルの変更です。

  1. ガス制限の増加に対応する能力(既存)
  2. エコシステムにリダイレクトされるステーキング報酬の割合(ハードフォークが必要)
  3. これらのリダイレクトを受け取るべき受取人アドレス(ハードフォークが必要)

次に、提案された2つの変更点を個別に見ていきます。

  1. リダイレクト率

(2)の主要な要素は、多数決トリガーメカニズムです。バリデーターの51%が0を超えるリダイレクト率をシグナルした場合、その貢献はすべてのバリデーターにとって義務となります。その時点で、すべてのバリデーターは指定された割合を貢献し、それに応じて報酬が減少します。

このアプローチはフリーライダー問題に対処します。バリデーターは一方的な不利益を被るリスクなしに資金提供を約束できます。なぜなら、貢献は過半数が同意した場合にのみ有効になるからです。

事実上、プロトコルはバリデーターが囚人のジレンマの均衡から協力へと移行することを可能にします。バリデーターが収束すると予想されるナッシュ均衡は次のとおりです。

ステーキング収益の損失 = E[ETHへの追加価値]

ETH価格の上昇はステーカーだけでなく全員に利益をもたらすため、ある程度のフリーライドは依然として存在します。したがって、このメカニズムは、ステーカーが資金提供の割合を次の点まで増やすため、最適値に比べて依然として資金不足になります。

ステーキング収益の損失 = sE [ステーカーのみのETH価格上昇による利益]

追加価値Eはどこから来るのでしょうか?集合投資による死重損失の削減という効率性の向上に加えて、以下のループから抜け出すのを助けることによってもたらされます。

a) 人々は将来イーサリアムが資金不足になることを恐れている。 b) 彼らはイーサリアムの成功の見積もりを減らす。 c) 彼らはETHの評価額を減らす。 d) ETH価格が下落する。

この設計はフリーライダー問題に部分的にしか対処していません。なぜなら、ステーキングしていないETH保有者もバリデーターによるリダイレクトから利益を得るからです。しかし、すべてのバリデーターの集合内では、リダイレクトはグループにとっては任意ですが、個人にとっては義務です。これは、死重損失削減問題に対する伝統的な経済の解決策(課税)にはオプトアウトがないことと比較して改善点です。

私たちは、リダイレクト率を**最大10%**に制限することを提案します。これは、什分の一の歴史や、収益の10%を社会に還元するという規範を考慮すると、自然なシェリングポイントとなります。さらに、この上限は、リダイレクトが不正なアクターへの再分配のために100%にまで引き上げられるという理論上の最悪のシナリオを制限します。これについては次のセクションでより包括的に扱います。

現在の約3500万〜4000万ETHのステーク量と1.91%の報酬率では、現在、チェーンのセキュリティ維持のために年間約70万ETHがバリデーターに与えられています。5〜10%のリダイレクトでも、バリデーターがリダイレクト率を0%(現状維持)まで下げる選択肢を保持しているため、不当な強制をすることなく、エコシステムにかなりの資金(年間約5万〜7万ETH)を提供できます。

  1. リダイレクト受取人

リダイレクト率の決定は比較的簡単ですが、より複雑な問題は資金をどのように割り当てるべきかを決定することです。

このセクションでは、バリデーターがどのように好みを表明するか、それらがどのように集約されるか、そしてリダイレクト受取人の最終リストの構築という3つの質問に分けて説明します。

Q1: この提案の下でバリデーターはどのような変更を行う必要がありますか?

バリデーターレベルで必要なのは、以下の指定のみです。

  1. リダイレクトされた資金を受け取るべきコントラクトアドレスまたはEOA
  2. 各アドレスへの割合

例えば、バリデーターは0xABC…に60%、0xXYZ…に40%と設定するかもしれません。頻繁な参加を必要とする他のメカニズムとは異なり、バリデーターは単に設定して忘れることができ、いつでも手動で設定を変更するオプションがあります(実際には、一度設定されるとデフォルトが固定されると予想されます)。このアプローチにより、本来得られたはずの収益を割譲するバリデーターが、自分のお金がどのように分配されるかをコントロールできます。

次に、次の質問に移りましょう。

Q2: 異質なバリデーターの好みを、資金の分配方法を定義する単一のスプリッターコントラクトにどのように集約しますか?

提案の実行後、メカニズムは0のリダイレクト率と0アドレスをリダイレクト受取人として開始します。128ブロックごと(約5分ごと)に、最初のバリデーターは、既存の「キング・オブ・ザ・ヒル」を打ち破って新しい「キング・オブ・ザ・ヒル」となる新しい候補スプリッターコントラクトを提案できます。候補がバリデーターの設定された好みに合致していれば、それが新しいキング・オブ・ザ・ヒル・スプリッターコントラクトになります。バリデーターの推奨受取人への合致度が既存のキング・オブ・ザ・ヒルと同等かそれ以下であれば、既存のキング・オブ・ザ・ヒルが維持されます。

これで、最終リストに関する最後の質問に取り組むために問題を絞り込みました。

Q3: 候補スプリッターコントラクトが、現在のキング・オブ・ザ・ヒルよりもバリデーターの好みに合致しているかどうかをどのように判断しますか?

私たちは、プロトコルが既存のキング・オブ・ザ・ヒルをKEEPするかREPLACEするかを決定するために、距離指標(マンハッタン距離など)を使用することを提案します。3つのリダイレクト受取人を例にとると、

バリデーターの理想的な分配: [20%; 0%; 80%]

既存のキング・オブ・ザ・ヒル・スプリッターコントラクト: [50%; 25%; 25%]。距離は30%+25%+55%= 110%

候補スプリッター: [30%; 50%; 20%]。距離は10%+50%+60%= 120%

したがって、バリデーターは、提案された代替案と比較して好みに近いため、現在のキング・オブ・ザ・ヒルを維持することに自動的に投票します。

実行クライアントが候補とキング・オブ・ザ・ヒルのスプリッター間の比較方法を実装する方法には、ある程度の多様性があるでしょう。例えば、凸型効用関数(例: メカニズムに大量を割り当てるか、全く割り当てないか、中途半端な量は割り当てない)などです。バリデーターは、資金の割り当て方法に不満がある場合、スプリッターコントラクトに割り当てられる金額をゼロまで調整することもできます。全体として、この「キング・オブ・ザ・ヒル」メカニズムは、コンドルセ勝者である資金分配に収束します。これは、直接対決の投票で他のどの分配にも勝る分配です。また、プロトコルレベルでのシンプルさも保証されます。オプションは既存のスプリッターコントラクトを「KEEP」するか「REPLACE」するかのいずれかのみです。

V. 未解決の課題

この提案は資金調達に関する調整問題を解決するのに役立ちますが、対処しなければならないいくつかの手に負えない懸念も提起します。

1. バリデーターのカルテル化

最も重大なリスクはカルテル形成です。

バリデーターの過半数が共謀した場合、理論的にはリダイレクト率を上げて、その資金を自分たちにリダイレクトすることができます。例えば、バリデーターの51%がリダイレクト率を最大10%に設定し、リダイレクト受取人を自分たちで資金を分割するスプリッターに設定することで、他の49%からステーキング報酬を「盗む」ことができます。共謀による価格下落が、そのような悪意のある行動を経済的に不採算にする要素もあります。

2. プリンシパル・エージェント問題

(1)で提起された問題は、ステーキングオペレーターを考慮に入れると、より深刻になります。

現在、ETHの約90%はソロステーカーではなくオペレーターを通じてステーキングされています。オペレーターは顧客が提供した資本を使ってバリデーターになります。オペレーターは通常、ステーキング報酬の割合によってインセンティブを得ますが、ETH保有者は主に元本の長期的な価値を重視します。

オペレーターが設定メカニズムを制御する場合、彼らは改善されたオペレーターエクスペリエンスなど、自分たちに利益をもたらすプロジェクトへのリダイレクトを優先するかもしれません。これはユーザーがあまり気にしないことです。この問題に対する最善の答えは、顧客がリダイレクトの投票設定を気に入らない場合に移行できる、オペレーターの競争市場です。

3. 発行シグナリング

もう一つの影響は、バリデーターが報酬の一部を貢献する意思を示すことが、イーサリアムの発行率が必要以上に高いという証拠として解釈される可能性があることです。

バリデーターが報酬の10%を放棄する意思は、発行量を10%削減する能力があると解釈される可能性があります。

反論

今日、ほとんどのユーザーは純粋に金銭的価値(利回りやリスク)に基づいてオペレーターを選択しています。

もしこのようなメカニズムが実装されれば、ユーザーが価値観に基づいてオペレーターを選択するという新たな競争軸が加わります。例えば、ユーザーはリダイレクト率を5%に設定し、受取人をイーサリアムを量子耐性にするチームに設定するオペレーターとのステーキングを好むかもしれません。一部のオペレーターは、ユーザーが直接好みを設定できるようにするかもしれません。

時が経つにつれて、これはステーキングオペレーターの中央集権化を逆転させる可能性があります。なぜなら、価値観は、金融リターンが享受するネットワーク規模の利益よりも本質的に多元的だからです。また、個人がエコシステム内の重要なプロジェクトへの資金提供方法に直接影響を与えることができるため、より多くのソロステーキングを促進するかもしれません。

さらに、私たちが提案する投票メカニズムの下では、カルテル行動は安定しません。つまり、バリデーターが純粋に貪欲に駆られ、このプロセスを利用して自分たちにより多くの資金を流そうとすると仮定しても、「キング・オブ・ザ・ヒル」オプションは、どのバリデーターにも現状よりも多くの利益を与える安定した分配に落ち着くことはありません。数学的な説明については付録を参照してください。

発行量削減の議論は大きく2つの陣営に分かれています。一方は、機関が特定の仮定に基づいてステーキング製品を構築していることを考慮すると、信頼性を維持するために、リーンイーサリアムの後でなければいかなる削減も行うべきではないと考えています。もう一方は、発行曲線はステークされたETHの増加に伴って減少せず、欠陥があるため、2027年第1四半期にも調整が必要であると考えています。この提案は発行量削減の議論とは独立して機能します。それにもかかわらず、コアイーサリアムの資金調達の必要性を考えると、リダイレクトが純粋な削減よりも優れた代替手段として機能する良い道筋があります。

次のステップ

私たちは、EIP(Ethereum 改善提案)として提出するための技術的な実装に取り組む前に、さらなるフィードバックを求めています。この次の投稿では、質問が寄せられ次第更新されるFAQが掲載されます。

EIPの承認を妨げる解決不可能な懸念があったとしても、危機時に活性化できる緊急時の偶発事態計画があることが不可欠であると考えています。そうすれば、危機時にゼロから始める必要がありません。

11件の投稿 - 5人の参加者

トピック全文を読む