イーサリアムのコア・ガバナンスの解説

イーサリアム財団のNixo Rokish氏によるETHBoulderでのプレゼンテーション。イーサリアムのコア・プロトコルのガバナンス、ハード・フォークの調整方法、誰がイーサリアムを管理しているかについてのよくある誤解、そしてガバナンス・プロセスへの参加方法について解説しています。

このトランスクリプトは、EthBoulderによって公開された元のビデオのトランスクリプト (opens in a new tab)のアクセシブルなコピーです。読みやすさのために軽く編集されています。

はじめに (0:12)

来てくれた6人の友人たち、ありがとう。さて、今日はイーサリアムのコア・ガバナンスについてお話しします。私の名前はNixoです。EF（イーサリアム財団）でプロトコル・サポート・チームを率いています。私たちの任務の1つは、ガバナンス・プロセスをより明確にし、参加するすべての人にとってナビゲートしやすくすることです。なぜなら、イーサリアムにはコア開発者以外にも非常に多くの人々が関わっているからです。

本日の概要は以下の通りです。まず、コア・ガバナンスとは何かについて話します。次に、よくある誤解や、現在のイーサリアムのガバナンスがどのように機能しているかについて説明します。また、他の分散型ガバナンス・システムとの比較、ビルダーが関心を持つべき理由、そして参加するための具体的な方法についても触れます。

では、コア・プロトコルのガバナンスとは何でしょうか？私はノードを運営しています。つまり、自宅にハードウェア（コンピューター）があり、そこでイーサリアムのソフトウェアを実行しているということです。このイーサリアムのソフトウェアをセットアップする際、そのソフトウェアを実行するクライアントを選択する必要がありました。イーサリアムは、クライアント・ダイバーシティのために複数のクライアントを持っているという点でユニークです。その目的は、1つのクライアントがダウンしたり、バグが発生したりしても、ネットワーク全体がダウンしないようにすることです。他のクライアントを持つブロックチェーンは他にもあります。しかし、実際にバグから保護されるような仕組みになっているのはイーサリアムだけです。例えばSolanaを見ると、SolanaにはGTOと呼ばれる別のクライアントがありますが、その採用率は20〜21%に過ぎません。そのため、多数派のクライアントがダウンすると、チェーン全体がダウンしてしまいます。実際に他のネットワークがダウンするのを見たことがあります。これが、イーサリアムが最も回復力があり、安全なブロックチェーンである理由です。

そこで問題になるのは、これほど多くの異なるクライアントと調整しなければならない中で、どのようにしてイーサリアムに変更を加えるかということです。まず、ハード・フォークとソフト・フォークの違いを明確にしましょう。ソフト・フォークは、ハード・フォークほどの調整を必要としません。イーサリアムは主にハード・フォークで機能します。ハード・フォークとは、基本的にすべてのクライアントがイーサリアムの新しいバージョンを構築し、あらかじめ設定された時間にこの新しいバージョンを立ち上げることを決定するものです。依然としてイーサリアムですが、新しい機能や異なる機能が追加されています。そして、自宅でノードを運営している私のようなノード・オペレーターやプロのオペレーターは全員、その新しいバージョンのイーサリアムを受け入れる必要があります。新しいソフトウェアを含めるために、ノードをアップグレードまたは更新しなければなりません。

では、それらのハード・フォークにどの機能を含めるかをどのように決定するのでしょうか？彼らは割り当てられる時間とリソースが限られているため、優先順位について合意する必要があります。セキュリティの欠陥やセキュリティ・パッチ、UXなどを優先します。もし競合する他のブロックチェーンがあるなら、それらに対して競争力を持つ必要があります。そのため、彼らが考慮することの1つは、導入される機能が、将来のロードマップの項目と前方互換性を持っていなければならないということです。

昨年、非常に議論を呼んだ出来事がありました。聞いたことがあるかもしれません。EOFと呼ばれるものです。これはEVM Object Formatの略です。これはフサカのハード・フォーク（ペクトラとフサカの両方だったと思います）に導入される予定だった機能のセットですが、分割されました。そして、それがフォークから外された多くのきっかけの1つは、ヴィタリックがイーサリアムがRISC-Vを採用する可能性について投稿したことでした。それを読んだ多くの人々は、「なるほど、RISC-Vを採用すれば、EOFで検討している機能はRISC-Vにネイティブで備わっている。それなら、なぜプロトコルにこの複雑さを追加するのか？なぜクライアント開発者のリソースをすべてこれに注ぎ込むのか？最終的にRISC-Vに移行するなら、無意味になってしまう」と考えました。

それがEOFにとっての決定打となり、最終的にフォークから外されることになりました。彼らが考慮しなければならないもう1つのことは、クライアントが6つの異なる言語で書かれているため、6つの異なる言語で記述され、厳密にテストされなければならないということです。これは彼らにとって非常に大きなテスト・マトリックスです。そのため、あらゆる小さな設計上の選択が議論の対象となり、意見の不一致を解決する権限を持つ人はいません。そこで生じる疑問は、「誰が決定するのか」ということです。これがガバナンスの核心です。

よくある誤解 (5:23)

そこで、よくある誤解についていくつか取り上げます。1つ目は、ヴィタリックがイーサリアムのプロトコルに何を含めるかを決定しているというものです。その延長線上にあるのが、EFがすべてを管理しているという誤解です。そして3つ目は、すべてが密室での取引であり、インサイダーや古参（OG）がこれらの決定を下しているというものです。

まず1つ目、「ヴィタリックが決定している」について。私はヴィタリックが作成した停滞しているEIPのいくつかを選び出しました。これが意味するのは、ヴィタリックが腰を据えて提案を書き、「これをイーサリアムに導入したい」と言ったにもかかわらず、誰も同意せず、そのまま放置されているということです。彼はこれらをプロトコルに導入することができませんでした。つまり、彼が提案したからといって、すべてが自動的に含まれるわけではないのです。

その延長線上にあるのが、「イーサリアム財団がすべてを管理している」という誤解です。これに矛盾すると思う具体的な例を挙げます。2024年、ガス・リミットについて多くの議論がありました。その理由は、2022年のマージの際にガス・リミットを3,000万に引き上げたからです。これはブロック内で許可される最大計算量です。その後、しばらくは手をつけませんでした。なぜなら、「これが理由でイーサリアムに移行しない」とか「これが現在のイーサリアムのユースケースを制限している」と人々が言うようなボトルネックではなかったからです。

そして2023年後半から2024年初頭にかけて、Solanaが台頭してきてイーサリアムのシェアを奪うだろうというシナリオがありました。そのため、人々はイーサリアムを加速させるために何ができるかを考えていました。その1つが、このガスの指標を引き上げようというものでした。当時、EFやクライアント開発者たちは「他にも心配すべきことがあるので、提案はありがたいですが結構です」という感じでした。しかし、Eric ConnorとMariano Contiの2人が現れて、「いや、ガス・リミットを引き上げる」と言ったのです。ガス・リミットはバリデータが制御するパラメータです。そのため、彼らはバリデータやプロのオペレーターに話しかけ、「ガス・リミットを上げてくれ」と言うだけでよかったのです。

そしてある時点で十分な採用が進み、EFとクライアントは「おっと、これに注意を払わなければ。彼らがやっていることが安全であり、最終的に引き上げる値がネットワークにとって安全なものであることを確認しなければならない」となりました。そのため、彼らはリソースを再配分しなければなりませんでした。ネザーマインドはこのテスト・フレームワークを考案しました。EFはベルリンで多くの作業を行いました。すべてのクライアント開発者がこれをベンチマークしていました。私はこの事例が好きです。なぜなら、何が優先されるかを決定する上で、EFに強制的に対応させたからです。

そして、ここにスクリーンショットを貼ったこの馬鹿げたツイートが好きです。どこかのニュースメディアがEric ConnorとMariano Contiをコア開発者と呼んでいるからです。彼らはコア開発者ではありません。Eric Connorはステーカーでありコミュニティ・メンバーでした。Mariano Contiは元MakerDAOのアプリ開発者でした。しかし、イーサリアムの開発は従来のソフトウェアの仕組みとは全く異なる世界であるため、コア・パラメータが変更されているのを見て、「ああ、彼らはコア開発者に違いない」と思われただけです。彼らはそうではありませんでした。これは、コミュニティ・メンバーが参加して「この変更を見たい」と言い、それを実現させた一例に過ぎません。

「すべてが密室での取引であり、インサイダーや古参（OG）が決めている」という誤解については、なぜそう思われるのか少し理解できます。基本的にこれらのガバナンス・コールに参加すると、そこには100人もの人々がいます。彼らは皆、進行状況にとても慣れているように見えます。あなたは迷子になり、これらの決定がどのように下されるのか全くわかりません。「まだ私の話す番じゃないの？」という感じで、同じ10人の意見を聞いて決定を下しているように感じられます。

実力主義と参加者の統計 (10:18)

しかし実際のところ、イーサリアムの開発は、私がこれまで見てきたほとんどのソフトウェア開発よりも実力主義です。このスクリーンショットに写っているすべての人々（これは私がランダムにスクリーンショットを撮ったACDコールの3枚のうちの1枚です）は、誰一人としてここに任命されたわけではありません。全員がただ参加しただけの人たちです。彼らはこのプロトコルに多くの時間を費やしてきた開発者たちです。彼らは、この分野で才能ある開発者として人々に認められ、常に良い決定を下している人たちであり、ここにいる誰も任命されたわけではありません。

私は1年ちょっと前にEFに参加したばかりです。これらの統計を取りました。2025年3月までしか遡れません。つまり1年未満です。All Core Dev（ガバナンス・コール）の平均参加者数は98人です。つまり、平均して98人がこれらのコールに参加しています。それ以降の1回のコールでの最大参加者数は153人でした。それはペクトラのメインネットの日付を決定していた日だったと思います。そして、過去1年間だけでユニーク参加者の合計は567人です。私はこの指標がとても気に入っています。なぜなら、毎回同じ100人がこれらのコールに参加しているわけではないことを示しているからです。アプリ開発者、研究者、あるいは議論されている機能について聞いた誰かが、反対や支持の声を上げるために現れ、その後は別のコールには来ないのです。

ガバナンス・プロセスの仕組み (11:52)

これは少し退屈なスライドですが、目を通すことが重要だと思います。これが現在のイーサリアムのガバナンスの仕組みです。これらのフォークの1つが議論されているとき、最初に起こるのは、割り当てられた時間枠の間に人々がヘッドライナー提案を提出できるということです。ヘッドライナー提案とは、このフォークのために人々に結集してもらいたい主要な機能のことです。コミュニティ・メンバー、研究者、コア開発者など、本当に誰でもこのヘッドライナー提案を提出できます。その後、期間が終了し、ガバナンス・コールでどれが理にかなっているかを議論します。人々は主張し、議論し、次のフォークのためにどれを選ぶべきかについてコンセンサスが形成されます。

それに続いて、マイナーな機能を選択します。つまり、フォークを牽引する主要な機能である必要はない、より小さなものです。そして、この期間中ずっと、機能固有のデブネットがあります。デブネットはテストネットのようなもので、開発者がこれらの機能をテストし、イーサリアム上で実際に機能していることを確認するためのプライベートなテスト・ネットワークです。そしてある時点で機能のフリーズ（凍結）が行われます。主要な機能について議論し、マイナーな機能について議論し、通常はフォークのヘッドライナーとなる機能固有のデブネットを実行しました。そして、これは注釈付きの機能フリーズです。なぜなら、その時点でこのフォークにこれ以上機能を追加しないことを決定したからです。すべての機能を一緒に実行し、すべてが良好であること、何も壊れないことを確認します。しかし、何かが進行を遅らせ始めたり、フォークが遅れたり、複雑すぎたりした場合、その時点でも機能が外される可能性があります。

そして、いくつかのデブネット（2つの場合もあれば10の場合もあります）の後、ある時点でクライアントはすべて、これが安定していると判断します。現在の状況を信頼し、良い状態にあると判断します。これをイーサリアム・メインネットに展開することを考え始めます。彼らはクライアントのリリースを切り出し、その後、EFのセキュリティ・チームがバグ・バウンティを出す30日間の期間があります。彼らはセキュリティ監査を契約します。そして、その30日間の期間の終わりに、テストネット上でフォークを立ち上げます。これらはHoleskyのように、聞いたことがあるかもしれないテストネットです。ここでは、フォークが稼働する前にアプリ開発者が自分のものをテストできます。すべてが問題ないことを確認するために、これらは通常それぞれ最低14日間設けられます。以前に機能固有のデブネットや一般的なデブネットを経ているため、大きな問題は予想していませんが、歴史的にはこれらのテストネットのいくつかを壊したことがあります。そのため、これはすべてのバグを見つけて潰すための最後の機会のようなものです。

そして、パーミッションレスなテストネットが安定すると、メインネットの日付が選ばれます。それに続いて、30日間のバッファがあります。この30日間のバッファが存在するのは、L2やプロトコルがフォークの準備をするためにこれを要求したからです。つまり、最低30日間あり、その後フォークが行われます。

コールの構造と調整 (15:01)

この期間中ずっと、いくつかの主要なコール・シリーズが行われています。これらはすべてYouTubeでライブ配信される公開コールです。主要なものはACDEとACDCです。Eは実行レイヤーの略で、トランザクション、スマート・コントラクトのデプロイ、メンプールの管理などです。ACDCはコンセンサス・レイヤーで、バリデータの管理やスラッシングなどのバリデータに関するものです。そして、これらは木曜日に交互に行われます。つまり、毎週木曜日にACDがあり、1つはACDE、次はACDCというように続きます。

ACDEとACDCのコールは、現在作成中のフォークと、将来に向けて検討しているフォークに焦点を当てています。ACDTのコールは、より詳細で複雑な内容です。これらは、クライアントが解決できないバグや、現在取り組んでいるフォークについて解決する必要がある実装の詳細について話し合うものです。現在、次に予定されているフォークはグラムステルダムです。そのため、これらのACDTコールは、グラムステルダムに導入されるePBSやブロックレベルのアクセス・リストに関する会話で占められています。これらは非常に技術的なコールです。

そして、ブレイクアウト・コールがあります。ブレイクアウト・コールは、コミュニティ・メンバー、研究者、開発者が「2つ先のフォークでイーサリアムに導入したい機能がある」と言うものです。そのため、彼らは毎週、毎月、または隔月でこれらのコールを主催し、実装の詳細を徹底的に議論し、仕様を変更して反復し、人々が抱くすべての質問や既知の未知数に一般的に対処して、2つ先のフォークに含まれるのに最適な状態であることを確認します。これらはファシリテーターが決定したときにいつでもスケジュールできます。

進化するプロセス (15:29)

皆さんに強調しておきたいことの1つは、このプロセスは決して静的なものではないということです。私が今説明したこのプロセスは、稼働してから1年も経っていません。イーサリアムは10年間稼働しています。しかし、それは常に変化しており、常に変化する理由は誰も責任者ではないからです。そして、このプロセスは最も効率的な運用方法を見つけ出すために進化しています。効率的とは言いますが、イーサリアムのガバナンスの評判は、非常に停滞しており、物事を通すのが難しく、混乱しているというものです。それは、100人から500人の人々が決定を下している場合、これが機能していること自体に私は正直驚いているからです。

そこでTimは2025年4月に「All Core Devsの再構成」という投稿を行い、それが現在の仕組みの提案となりました。その理由は、それ以前はイーサリアムで何に焦点を当てるべきかについて、ある種の一貫したシナリオがあったからです。マージという巨大なプロジェクトがありました。誰もがとても興奮していました。ほとんどの人はとても興奮していましたが、マイナーはそうではありませんでした。そしてマージに続いて、出金がありました。私たちは、人々のETHがコントラクトにロックされ、「二度とETHを取り出せない」というようなFUD（恐怖、不確実性、疑念）が広まることを望んでいませんでした。そのため、できるだけ早くそれを出荷しなければなりませんでした。その後、プロト・ダンクシャーディングがあり、そしてペクトラが来ました。ペクトラは関連性のないさまざまなEIPの寄せ集めのようなもので、一貫したシナリオがありませんでした。一貫性がないために人々がただ物を詰め込んでいたため、非常に大きくなり、テスト・チームが「範囲が大きすぎる。これらすべてをテストすることはできない」となったため、2つの異なるフォークに分割しなければなりませんでした。

そのため、Timがこれを行った動機は、これらのフォークをできるだけ焦点が絞られ、一貫性のあるものに保つ方法を考える必要があるということでした。そして、ヘッドライナーがその答えのようなものでした。その目的は、誰もがそのフォークが何についてのものかを知っていると感じられるようにすることを優先して出荷し、25もの異なるEIPを詰め込む必要がないようにすることでした。

上のもう1つのスクリーンショットは、TimがこれらのEIPの組み込み段階の定義を提案しているものです。ここで私が言いたいのは、このプロセスが官僚的すぎると言う人が時々いるということです。しかし実際に起こっているのは、人々がこのガバナンス・プロセスに参加して「どうやってEIPを導入するの？」と尋ねると、10年間そこにいる人々が「まあ、ただやるだけだよ」と答えることです。そして人々は「これはひどい」となります。そのため、これらの定義が行っているのは、外部の人がこのプロセスに参加しやすくするために何が起こっているかを説明することです。なぜなら、もしあなたがここに来て「EIPが1つある。イーサリアムのガバナンスには興味がない。ただこの1つのEIPを導入したいだけだ」と言うなら、あなたはこのEIPを導入するための評価基準、チェックリスト、非常に明確なステップバイステップの手順を求めるからです。つまり、これらのことのほとんどは、EIPを導入しにくくするために人々が従わなければならない官僚的なルールを作ることではなく、プロセスがどのように機能するかを説明することなのです。

3つ目は、Forkcastでの時間の経過に伴うコミットです。Forkcastは私のチームの製品で、現在のチームが結成された昨年の半ばに、チームのメンバーであるWolfram Markが作成しました。そして、人々がフォークとやり取りし、フォークに何が含まれ、それが自分たちにどのような影響を与えるかを確認するために使用する、非常に標準的なリソースになりました。これらはすべて2年も経っていません。つまり私が言いたいのは、このプロセスは大きく変化するということです。決して静的なものではありません。足を踏み入れるのが難しい、凍りついた官僚主義ではないのです。

比較可能なガバナンス・システム (20:21)

ここで手短に、イーサリアムのガバナンスに最も似ていると思われる分散型ガバナンス・システムについて触れたいと思います。ここで私が言いたいのは、これは持続可能であるということです。100人から500人の人々が決定を下せるというのは驚くべきことですが、現実世界では持続可能です。これが機能している例を私たちは実際に目にしています。

IETFはInternet Engineering Task Forceの略です。TCP/IPやHTTPを作成した、ボランティア運営の標準化団体です。今日私たちが自由なインターネットを利用できていることに最も貢献している組織です。Linuxカーネルは、Linuxオペレーティング・システムのコアです。インターネット・サーバー、Androidスマートフォン、スーパーコンピューターを動かすオープンソース・ソフトウェアです。そこでの違いは、Linus Torvaldsによる慈悲深い独裁者モデルのようなものを持っていることです。しかしそれでも、17,000人以上の貢献者がいるというのは驚異的です。

これに似ていないものとしては、オンチェーンのトークン投票を持つ他のブロックチェーンがあります。イーサリアムは、いかなる種類の投票メカニズムも意図的に避けています。なぜなら、私の意見では、それは乗っ取りの手段につながり、人々が最高のコードを書く人をただ信頼するという実力主義にするインセンティブをなくしてしまうからです。それからL2があります。彼らはマルチシグを持っています。セキュリティ評議会を持っています。これらは、これらの決定を下す任命された役職のようなものです。そしてそれにはトレードオフがあります。より中央集権的ですが、動きは速いです。

ビルダーが関心を持つ理由 (22:38)

では、なぜビルダーはガバナンスに関心を持つのでしょうか？なぜなら、ビルダーこそが文字通りイーサリアムが作られた対象だからです。イーサリアムはコア開発者のために作られたのではありません。バリデータのために作られたのでもありません。時々、これらの人々はそのことについて混乱します。イーサリアムのコア開発者とバリデータはイーサリアムに奉仕し、イーサリアムはビルダーとユーザーに奉仕するのです。

そして誰もが、AIを使っていて細部にこだわりすぎ、この小さなことを修正しようとして、ズームアウトしてプロジェクト全体の目的を見失ってしまうという経験をしたことがあるでしょう。コア開発者も、コア開発プロセスを完璧にしようとするあまり、そのようになることがあります。そのような場合、ビルダーが参加することが非常に重要です。なぜなら、コア開発は非常に多くの時間を消費するため、彼らはほとんどの場合、イーサリアム上で構築を行っていないからです。彼らはコア開発に深く関わっています。それが彼らの時間のすべてを奪います。そのため、アプリ・ビルダーは本当に努力して参加し、「ねえ、これが必要だ。これはイーサリアムにとって不可欠だ」と言う必要があります。その視点がそこにあることを確認し、彼らがコア開発者のためだけに働くように型にはめられないようにするためです。

参加方法 (24:40)

では、どのように参加したり、自分の機能を導入したりするのでしょうか？これは一般的なアドバイスのようなものですが、最善だと思います。自分のペインポイント（悩みの種）について大声で主張してください。Twitterに行き、ブログ記事を書き、ペインポイントの解決策を特定してください。自分を助けてくれそうなことについて推測してください。同じペインポイントを持つ他の人を見つければ、一般的にそのペインポイントに対処するために存在するEIPを見つけるか、それを行うEIPを書くのを誰かに手伝ってもらうことができます。

私がオープンソース・ソフトウェアについて気に入っていることの1つは、一般的に資金力のある企業が、自分たちが使用しているオープンソース・ツールの維持に開発時間とリソースを割り当てるということです。そして最終的には、多くの異なる企業が協力してこれを維持することになり、それがイーサリアムでも機能する方法になり得ます。したがって、特定したペインポイントがある場合、同様のペインポイントを持つBaseの開発者を見つけることができます。Baseは資金力のある組織であるため、機能を出荷したり、イーサリアムのハード・フォークを通じて機能を管理したりするために、おそらくリソースを割り当てることをいとわないでしょう。

最後にいくつかのリソースを紹介します。Forkcast.org — ここでは、フォークに何が含まれるか、特定の利害関係者にどのような影響を与えるかを確認できます。アプリ開発者であれば、アプリ開発者向けのセクションがあります。ウォレット開発者、コンセンサス・レイヤーのクライアント開発者であれば、それらがどのように影響するかについてのセクションがあります。YouTubeには、それらのコールの動画がすべてアップロードされています。これらはforkcast.org/callsページにも埋め込まれており、そこには要約や発言者の属性があるため、それらのコールをナビゲートしやすくなっています。EIPディレクトリ、Ethereum Magiciansフォーラムでは、潜在的な解決策や書きたいEIPについて他の人と話し合うことができます。そして間もなく、私のチームはプロトコル・サポート・サイトを立ち上げます。素晴らしい出来栄えです。まだ共有する準備はできていません。私のメールアドレスもそこにあります — nixo@ethereum.org (opens email client)。以上です。