イーサリアムのガバナンス入門

イーサリアムは誰かに所有されるものではないため、イーサリアムのこれまでの変更と今後の変更に関する決定はどのように行われるのでしょうか? イーサリアムのガバナンスとは、そのような意思決定を可能にするプロセスのことです.

ガバナンスとは

ガバナンスとは、意思決定を行うためのシステムです。一般的な組織構造では、経営陣や取締役会が意思決定の最終決定権を持ちます。あるいは、株主が提案に投票し、変更を成立させる場合もあります。政治システムでは、選挙で選ばれた議員は、有権者の要望を代弁しようとする法案を制定することがあります。

分散型ガバナンス

イーサリアムプロトコルは誰にも所有されず、誰のコントロールも受けていませんが、ネットワークの今後と成長を確実にするためには、変更を実施するか、しないかの決定が必要になります。所有権がないため、従来の組織的なガバナンスとは相容れない形態になっています。

イーサリアムのガバナンス

イーサリアムのガバナンスは、プロトコルを変更するためのプロセスです。ここで重要なのは、このプロセスは、人々やアプリケーションがプロトコルをどのように使用するかには関係しないということです。イーサリアムはパーミッションレスです。世界のどこからでも、誰でもオンチェーン・アクティビティに参加できます。誰がアプリケーションを構築したり、トランザクションを送信したりできるかどうかのルールは設定されていません。ただし、分散型アプリケーションが実行されるコアプロトコルへの変更を提案するプロセスが存在します。非常に多くの人々がイーサリアムの安定性に依存しているため、イーサリアムへの変更が安全で広くコミュニティに支持されるように、社会的および技術的プロセスを含めて、コアの変更には非常に高いハードルが設定されています.

オンチェーン vs オフチェーンガバナンス

ブロックチェーン技術では、オンチェーンガバナンスと呼ばれる新しいガバナンス機能が利用可能です。オンチェーンガバナンスとは、提案されたプロトコルの変更が、通常はガバナンストークンの保有者であるステークホルダーの投票によって決定され、投票はブロックチェーン上で行われます。一部のオンチェーンガバナンスの形態では、提案されたプロトコルの変更は既にコードとして記述され、ステークホルダーが変更を承認するためにトランザクションに署名すると、変更が自動的に実装されます。

反対のアプローチであるオフチェーンガバナンスでは、プロトコル変更の決定は、社会的な議論による非公式なプロセスで行われ、もし承認された場合、その内容がコードとして実装されます。

イーサリアムのガバナンスはオフチェーンで行われており、そのプロセスには様々なステークホルダーが関わっています。

プロトコルレベルではイーサリアムのガバナンスはオフチェーンですが、DAOなどイーサリアム上に構築された多くのユースケースではオンチェーンのガバナンスを使用しています。

分散型自律組織(DAO)の詳細

関係者

イーサリアムコミュニティには様々なステークホルダーが存在し、それぞれがガバナンスプロセスで役割を担っています。プロトコルから最も遠いステークホルダーから始めて、徐々に近づいて見ると、次のようになります。

イーサ保有者: 任意の額のETHを保有している人々。 ETHの詳細。
アプリケーションユーザー: イーサリアムブロックチェーン上のアプリケーションを操作する人々。
アプリケーション/ツールデベロッパー: イーサリアムブロックチェーン上で実行されるアプリケーション(例: DeFi、NFTなど)を作成する人々です。また、イーサリアムと対話するためのツール(例: ウォレット、テストスイートなど)も構築します。 dappsの詳細。
ノード運用者: ブロックやトランザクションを伝播させるノードを実行し、遭遇した無効なトランザクションやブロックを拒否する人々。ノードの詳細。
EIP起草者: イーサリアム改善提案(EIP)の形でイーサリアムプロトコルの変更を提案する人々。 EIPの詳細。
バリデータ: イーサリアムブロックチェーンに新しいブロックを追加できるノードを実行する人々。
プロトコルデベロッパー(別名「コアデベロッパー」): イーサリアムの様々な実装(実行レイヤーのgo-ethereum、Nethermind、Besu、Erigon、Reth、またはコンセンサスレイヤーのPrysm、Lighthouse、Nimbus、Teku、Lodestar、Grandineなど)をメンテナンスする人々。イーサリアムクライアントの詳細。

注: どの個人もこれらのグループの複数に参加できます(たとえば、プロトコルデベロッパーがEIPを主導し、ビーコンチェーンのバリデータを実行し、DeFiアプリケーションを使用することも可能です)。ただし、概念を明確にするために、これらを区別するのが最も簡単です。

イーサリアム改善提案(EIP)とは

イーサリアムのガバナンスで使われる重要なプロセスの1つに、**イーサリアム改善提案(EIP)**の提案があります。イーサリアム改善提案(EIP)とは、イーサリアムの新しい機能やプロセスを定める標準であり、イーサリアムコミュニティの誰もが作成することができます。 EIPの作成、ピアレビュー、ガバナンスへの参加に興味をお持ちの場合は、次を参照してください。

イーサリアム改善提案(EIP)の詳細

正式なプロセス

イーサリアムのプロトコルを変更するための公式プロセスは以下の通りです。

コアEIPの提案: EIP-1 (opens in a new tab)に記載されているように、イーサリアムへの変更を正式に提案するための最初のステップは、コアEIPでその詳細を説明することです。受け入れられると、プロトコルデベロッパーが実装するイーサリアム改善提案(EIP)の公式の仕様になります。
EIPをプロトコルデベロッパーに提示: コミュニティからのインプットを集めたコアEIPを作成したら、プロトコルデベロッパーに提示する必要があります。これは、AllCoreDevs call (opens in a new tab)での議論のために提案することで行うことができます。 Ethereum Magician's forum (opens in a new tab)やEthereum R&D Discord (opens in a new tab)で、すでに非同期でいくつかの議論が行われている可能性があります。

この段階で起こり得る結果は、次のようなものがあります。

イーサリアム改善提案(EIP)は将来のネットワークアップグレードの際に検討される

技術的な変更をリクエストする

優先順位が低い場合や、開発労力に比べて改善効果が十分に大きくない場合には、却下される

最終提案に向けた反復: 関連するすべてのステークホルダーからフィードバックを受けた後、セキュリティを向上させたり、さまざまなユーザーのニーズをよりよく満たすために、最初の提案に変更を加える必要が出てくるでしょう。イーサリアム改善提案(EIP)に必要と思われる変更をすべて反映させたら、プロトコルデベロッパーに再度提示する必要があります。その後、次のステップに進む、または新たな懸念事項が出てきて、提案を再度繰り返し行う必要が出てきます。
ネットワークアップグレードに含まれるEIP: EIPが承認、テスト、実装されると、ネットワークアップグレードの一部としてスケジュールされます。ネットワーク・アップグレードには高い調整コストがかかるため(全員が同時にアップグレードする必要がある)、イーサリアム改善提案(EIP)は一般的にアップグレードのタイミングにまとめられます。
ネットワークアップグレードの有効化: ネットワークアップグレードが有効化されると、EIPはイーサリアムネットワーク上で稼働します。 注: ネットワークアップグレードは通常、イーサリアムメインネットで有効化される前にテストネットで有効化されます。

このフローは非常に簡略化されていますが、イーサリアム上でプロトコルの変更を有効にするための重要な手順の概要を示しています。では、このプロセスにおける非公式な要素を見てみましょう。

非公式なプロセス

既存の作業の理解

イーサリアム改善提案チャンピオンは、イーサリアム改善提案(EIP)を作成する前に、イーサリアムメインネットでの展開を真剣に検討できるよう、過去の作業や提案をよく理解しておく必要があります。これにより、過去に拒否されていない、新しい提案をもたらすことができます。これを調査する主な3つの場所は、EIPリポジトリ (opens in a new tab)、Ethereum Magicians (opens in a new tab)、ethresear.ch (opens in a new tab)です。

ワーキンググループ

最初のドラフトのイーサリアム改善提案は、編集や変更なしにイーサリアムのメインネットに実装されることはまずありません。一般的に、イーサリアム改善提案チャンピオンは、プロトコルデベロッパーのサブセットと協力して、提案の具体化、実装、テスト、反復、提案の最終化を行います。歴史的に、これらのワーキンググループには数ヶ月(時には数年!) の作業が必要でした。同様に、このような変更を行うイーサリアム改善提案チャンピオンは、エンドユーザーからのフィードバックを収集し、展開上のリスクを軽減するために、関連するアプリケーション/ツールデベロッパーを早期の段階で参加させる必要があります。

コミュニティのコンセンサス

ニュアンスを最小限にとどめた分かりやすい技術的改善のEIPがある一方、より複雑でさまざまな形でさまざまな利害関係者に影響を与えるトレードオフが伴うEIPもあります。つまり、コミュニティ内で議論の分かれるEIPも存在するということです。

争点となる提案をどのように扱うか、明確なプレイブックはありません。これは、イーサリアムの分散型設計による結果であり、どのステークホルダーグループも力ずくで他のグループを強制することはできません。プロトコルの開発者はコードの変更を実装しないことを選択でき、ノードオペレーターは最新のイーサリアムクライアントを実行しないことを選択でき、アプリケーションチームとユーザーはチェーン上でのトランザクションを行わないことを選択できるのです。プロトコルデベロッパーは、ネットワークのアップグレードを強制する手段を持たないため、通常、議論がコミュニティ全体の利益を上回ってしまうようなEIPの実装を避けるでしょう。

イーサリアム改善提案(EIP)チャンピオンは、すべての関連するステークホルダーのフィードバックを求めることが期待されています。もし、あなたが論争中のイーサリアム改善提案(EIP)のチャンピオンになったとしたら、自分の提案に対する合意を得るために、反対意見に対処する必要があります。イーサリアムコミュニティの規模と多様性を考えると、コミュニティのコンセンサスを測るために使用できる単一の指標(コイン投票など)は存在せず、EIPチャンピオンは提案の状況に適応することが期待されます。

イーサリアムネットワークのセキュリティだけでなく、プロトコルデベロッパーは、アプリケーション/ツールデベロッパーやアプリケーションユーザーの価値を重視してきました。これは、アプリケーション/ツールデベロッパーやアプリケーションユーザーがイーサリアムを使用して開発することが他のステークホルダーにとってエコシステムを魅力的なものにするという観点によるものです。さらに、イーサリアム改善提案(EIP)は、異なるチームによって管理されているすべてのクライアントに導入される必要があります。そのため、このプロセスの一環として、変更が価値あるものであり、それがエンドユーザーを助けたり、セキュリティ問題を解決するものであることを、プロトコルデベロッパーの複数のチームに納得させることが大切です。

意見の不一致への対応

さまざまな動機や信念を持った多くのステークホルダーがいるため、意見の相違が生じることも少なくありません。

一般的に、意見の相違は、問題の根本を理解し、誰もが意見を述べることができるように、パブリックフォーラムでの長時間の議論の中で処理されます。一般的には、一方のグループが譲歩するか、あるいは望ましい中間妥協案になります。 1つのグループが強く反対しているのであれば、特定の変更を強制すると、チェーン・スプリットにつながる可能性があります。チェーン・スプリットとは、一部の関係者がプロトコルの変更を抗議した結果、互換性のない異なるバージョンのプロトコルが動作し、そこから2つの異なるブロックチェーンが生まれることです。

DAOフォーク

フォークとは、ネットワークに大きな技術的なアップグレードや変更が必要となり、プロトコルの「ルール」を変更することです。イーサリアムクライアントが新しいフォークルールを実装するには、ソフトウェアのアップデートが必要となります。

DAOフォークは、2016年のDAO攻撃 (opens in a new tab)への対応でした。この攻撃では、安全でなかったのコントラクトから、ハッキングによって360万ETH以上が流出しました。このフォークにより、欠陥をもったコントラクトから新しいコントラクトに資金が転送され、ハッキングでETHを失った人が回収できるようになりました。

この行動指針はEthereumコミュニティの投票で行われました。どのETH保有者も、投票プラットフォーム (opens in a new tab)上のトランザクションを介して投票することができました。フォークの実行は、投票の85%以上に支持されました。

ここで重要なのは、プロトコルがハッキングを元に戻すためにフォークしたものの、フォークを決定する際の投票の重要性については、いくつかの理由から議論の余地があるということです。

投票率は驚くほど低かった
ほとんどの人が投票が行われていることを知らなかった
投票がETHの保有者のみを代表するものであり、システムの他の参加者を代表するものではなかった

コミュニティの一部がフォークを拒否したのは、The DAO事件がプロトコルの欠陥ではないと考えたことが主な理由です。彼らはEthereum Classic (opens in a new tab)を結成するに至りました。

現在、イーサリアムコミュニティでは、システムの信頼できる中立性を維持するために、コントラクトのバグや資金の損失の場合には介入しないという方針を採用しています。

The DAOハッキング事件をもっと見る

フォークの有用性

イーサリアムとイーサリアムクラシックは、健全なフォークの良い例です。 2つのグループは、いくつかの基本的な価値観においてお互いに強く意見を異にしていましたが、それぞれの行動方針を追求するのは、リスクに見合う価値があると考えました。

イーサリアムガバナンスの成功には、政治的、哲学的、経済的な大きな違いに直面しても、フォークできることが大きな役割を果たしています。フォーク機能がなければ、対立が続き、最終的にイーサリアムクラシックを形成した人々は消極的な参加を余儀なくされ、イーサリアムの成功のビジョンはますます異なったものになっていました。

ビーコンチェーンのガバナンス

イーサリアムガバナンスプロセスでは、スピードや効率性と、オープン性や包括性がトレードオフになることがよくあります。ビーコンチェーンの開発を加速させるために、プルーフ・オブ・ワークのイーサリアムネットワークとは別に立ち上げられ、独立したガバナンスが行われています。

仕様と開発実装は常に完全にオープンソースであったものの、上記で説明したアップデートの提案に使用される正式なプロセスは採用されていませんでした。プロセスを省略することにより、研究者と実装者が迅速に変更点を特定し、合意することができました。

2022年9月15日にビーコンチェーンがイーサリアムの実行レイヤーとマージされた際、Parisネットワークアップグレードの一環としてマージが完了しました。提案EIP-3675 (opens in a new tab)は「最終確認」から「最終版」に変更され、プルーフ・オブ・ステークへの移行が完了しました。

マージの詳細