イーサリアムのガバナンスの全体像
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
イーサリアム愛好家 (ID: ethfans)
、著者: Boris Mann、翻訳: A Jian、Odaily が許可を得て転載。
この記事では、イーサリアムのガバナンスアプローチのさまざまな層を要約しようとします。コアコンセプトはイーサリアムマジシャンフォーラムで公開され、議論を引き起こしました。
私の経歴について少し知りたい場合は、この記事の最後にあるイーサリアム コミュニティへの私のエントリーをご覧ください。私はイーサリアム コミュニティにはまだ慣れていませんが、Drupal CMS をサポートする Drupal Association の設立を支援するなど、オープンソース コラボレーションの経験はすでに豊富です。
「イーサリアム」という用語にはいくつかの意味があります。
「Stiftung Ethereum」としても知られるイーサリアム財団は、クラウドファンディングの運営とネットワークの立ち上げを使命として設立されたスイスに拠点を置く財団です。この財団はイーサリアムの商標も保持しています。彼らはコミュニティの多くのインフラストラクチャも管理しており、テスト フレームワークから Geth クライアントなどに至るまで、イーサリアムの主要ソフトウェアを開発するために複数のチームを雇用/アウトソーシングしています。現在、財団は重要な暗号化/ブロックチェーン研究に従事する研究者やチームを雇用または投資しており、現在は ETH2 研究に重点を置いています1。 Foundation は、年次「公式」開発者カンファレンス (別名「DevCon」) も主催します。しかし、イーサリアム財団はネットワークの技術的な方向性を管理していません。 (著者注 1: 研究も EF の基本的な活動であると示唆してくれた Tim Beiko に感謝します。これは、コミュニティ全体が EF の性質と仕事をどのように見ているかを明確に説明する非常に興味深い議論です。しかし、それはこの議論の中核ではありません。記事です）
イーサリアムのメインネットワークもグローバルなパブリックブロックチェーンであり、世界中の数千のノードによって共同運用されており、トランザクション処理機能とセキュリティはプルーフ・オブ・ワーク・アルゴリズムを実行する「マイナー」によって提供され、マイナーは次のことが可能です。代わりにブロック報酬を受け取ります。イーサリアムブロックチェーン上で流通する中心的な仮想通貨は「ETH」と呼ばれることが多く、この通貨は取引や契約の実行手数料の支払いに使用でき、ネットワーク内で認識される価値でもあります。イーサリアムメインネットのチェーン ID とネットワーク ID は両方とも 1 2 です。 (著者の注 2: イーサリアム プロトコルを実行しているすべてのブロックチェーンとそれに対応する ID については、chainid.network を参照してください。私はこのサイトの保守も手伝っています。)
イーサリアムはコミュニティでもあり、イーサリアム プロトコル、イーサリアム ブロックチェーン上の分散アプリケーション、および関連する分散ネットワーク プロトコル上で何かを実行したいグループを指します。全員の開発は主にメイン ネットワークに集中していますが、時間が経つにつれて、サイド チェーンやレイヤ 2 プロトコルなどを開発する人が増えています。
いくつかの基本的な概念を理解したところで、ガバナンスの階層を見てみましょう。以下にリストされている順序は多少大まかですが、より高いレベルはより低いレベルに循環的に戻ります。
副題
オープンソースのコラボレーション
「オープンソース」は実際には頭字語であり、ライセンスの性質、仕事のやり方、哲学などを指すこともあり、多くの意味も持っています。その意味については記事で説明します。私が後で書いた「オープンベースのピアの共同制作」では、より詳細な定義が使用されており、オープンソースを使用して、オープンソースの使用を許可するコンピューターコードの管理を指します: コードベース管理者、未解決の問題 (課題)、コードへの参加要求(プル リクエスト)、レプリケーション (フォーク)、およびユーザーと寄稿者のグローバル コミュニティ。
ETH1 クライアントのリストはイーサリアム Wiki ページ 3 にあります - ご覧のとおり、今日のクライアントのほとんどはイーサリアム財団によって管理されていますが、実際にはプロジェクト自体を管理するのは個々のチームとその貢献者であり、それぞれから独立しています。ただし、雇用されているかアウトソーシングされているかにかかわらず、全員がイーサリアム財団 (EF) から給与を受け取ります。 2 つの例外は、Parity Ethereum クライアント (プロジェクトは Parity Technologies 社によって管理されている) と PegaSys Pantheon クライアント (ConsesnSys 社によって管理されている) です。プロジェクトはまだアクティブであり、ソフトウェアはノードの実行とメインネットへの接続に使用されるため、これら 2 つのクライアントも「メイン」クライアントとみなされます。 Status用のNimbusクライアントも開発中であり、コード制御の多様性が増していることがわかります。 ETH2 ビーコン チェーン実装の初期のリストでも、これが強調されています。 (著者注 3: 私はこのページの保守を手伝っていますが、すべて編集可能であり、コードはイーサリアム財団の研究部門で働く Virgil Griffith @virgilgr によって保守されています。) (翻訳者注: 著者の記事が書かれたものです) 2019 年 3 月。現在、Parity Technologies は Parity クライアント プロジェクトを放棄し、Parity Ethereum は Open Ethereum プロジェクトに変わりました。)
すべての Ethereum クライアント ソフトウェアはオープン ソース プロジェクトとして管理され、さまざまな数の貢献者がコードを提供しています。 「オープンソース プロジェクトとして管理される」という場合、問題として表現されたバグや機能リクエストは誰でも解決して実行でき、誰でもコード投稿リクエストを使用してコード修正や新機能を送信でき、それらは管理者によって管理されることを意味します。管理者のグループ。管理者は、コードベースへの書き込みアクセス権を持つ人、および/または問題キューの管理を支援できる人です。管理者は組織から報酬を受け取っている場合もあれば、ボランティアである場合もあります。
この点に関する私の提案は、Apache2 ライセンスに移行することです。Apache2 ライセンスは非常に寛容で、営利組織と互換性があり、特許保護が含まれているからです。
オープンソース コラボレーションに長年携わってきた私たちは、多くの点で「勝利」しました。Microsoft は GitHub を買収し、世界で最もオープンな企業になることに尽力しましたが、同時に、核となる規範の多くはオープンソースのコラボレーションはもはや認識されていませんが、開発者であっても例外ではありません。私たちはもっとできることがあると思っています。そして、より多くの新しい開発者がイーサリアムのコア技術スタックのエンジニアになるよう指導し、同時に ETH2 技術スタックが次世代の技術専門家を訓練できるようにしたいと心から願っています。
要約すると、あなたがビジネスマンでテクノロジーに携わっていない場合、オープンソース ソフトウェア開発を取り巻く一連の規範とプロセスを理解することが重要です。オープンソース ソフトウェアは、ほぼすべてのブロックチェーン テクノロジーを支えるだけでなく、現在世界で実行されているほとんどのソフトウェアの基盤でもあります。
副題
プロトコル標準のガバナンス
イーサリアム改善提案 (EIP) プロセスは、標準を提案し、合意に達するために使用されるプロセスです。大まかに言えば、これはプロトコル標準のガバナンスです。これらの標準は、イーサリアム ソフトウェア レベル (つまり、相互運用可能なソフトウェアを実装するクライアントにいくつかの変更が必要) またはネットワーク レベルで適用される場合があります。このネットワーク層は、イーサリアムのメイン ネットワークと、イーサリアム プロトコルを実行する他のブロックチェーンの両方を指します。他のネットワークは、イーサリアム メインネットに従って EIP を組み込んで受け入れるか (現在はほとんどの場合)、独自のアップグレード プロセスを経る可能性があります。
ここで、EIP プロセスを、主にイーサリアム メインネット向けの標準を設計するものとして考えてみましょう。参加者が開発者であるかどうか、そして提案がメインネットにデプロイされるかどうかについては、別の問題です。
……
公開されているすべての EIP は、eips.ethereum.org で確認できます。 EIP-1 は、コア レイヤー EIP (ネットワーク コンセンサス ルールを変更し、展開するには全員の全会一致の同意が必要となる変更) およびその他のタイプの EIP 提出およびレビュー プロセスを指定します。
……
EIP ライブラリにはアプリケーション層用の標準もあり、これは「Ethereum Request for Comment (ERC)」とも呼ばれます。これらの ERC は、独立したコード ベースとプロセスに分割できます (私自身はこの形式を好みます)。
EIP プロセスは非常にうまく機能しており、改善されていると思います。もちろん、教育 (特にネットワークに価値を付加できる技術専門家) は多ければ多いほど良いです。
EIP プロセスの目的は標準化です。つまり、同じソフトウェアを複数のグループが開発できるようにし、全員のソフトウェアが相互運用可能であることを保証します。そしてイーサリアムには複数のクライアントがあり、これは非常に重要です。実際、これはソフトウェアを使用するライセンスよりもはるかに重要です。優れた標準があれば、誰でもそれを実装でき、実装が相互運用可能であることがわかります。
EVM、devp2p、JSON-RPC インターフェイスなど、イーサリアム技術スタックのさまざまな部分に専用の管理者とコードベースを設ける動きが始まっています。これは、イーサリアムメインネットの境界を越えて、より多くの協力者が協力してイーサリアムの相互運用性を改善し、確保できることを意味します。
副題
コア開発者のコラボレーション
AllCoreDev ビデオ会議は、主要なクライアント実装の開発者が共同作業するための方法です。ビデオ会議は 2 週間ごとに開催され、イーサリアム財団の常勤職員であるハドソン・ジェイミーソンが司会を務めます。
同様に、コア開発者会議の議題も、GitHub コード リポジトリのイーサリアム/PM で問題として公開されます。誰でも問題ページにコメントして、参加する時間があることを示したり、質問したり、意見を共有したりできます。
全体として、プロセス全体がテクノロジーに重点を置くように設計されています。コア開発者が考慮するのは、特定の EIP の技術的な健全性だけでなく、より大きなコンテキストにおける特定の「ネットワークの健全性」特性も考慮します。もちろん、あらゆる技術的な決定には技術以外の影響があり、この曖昧さが多くの問題の根源となっています。
さまざまなクライアント チームと話をした後、私が得たフィードバックは、コードの実装には実際にはそれほど時間がかからず、技術的以外の決定やロードマップの論争によってさらなる進歩が制限されているというものでした。
コア開発者は意思決定を行うためにどのようなプロセスを使用しますか?まあ、EIP プロセスの「ライブ」バージョンのようなものですが、2 週間ごとにリアルタイムのディスカッションがある点が異なります。つまり、IETF (Internet Engineering Task Force) スタイル、大まかな合意と実用的なコードがプロセスの中心です。最近の議論では、おそらく不確実性を取り除くために、合意形成と議論の文書化を必要とする追加の手続きの必要性が指摘されています。
EIP とコア開発者のレビュー プロセスを理解するのに役立つツールは、Dan Finlay が描いたフローチャートです。ちょうどここで撮影しました:
副題
ネットワークガバナンス
私は、イーサリアム エコシステム全体で行われるガバナンスの決定を指すために「ネットワーク ガバナンス」という用語を使用します。これは「単なる技術的な決定」よりもはるかに重要です。
オープンソースのコラボレーションからプロトコル標準のガバナンス、コア開発者のコラボレーションに至るまで、上記のすべてのアプローチは、多くの場合、テクノロジーのみを対象としています。コードを書かず、資金を集め、開発者を雇わなければ、できることはほとんどありません。
では、イーサリアム ネットワークは利害関係者の関与を正確に担っているのでしょうか? 「私たち」がより広範なステークホルダーの関与を望んでいる場合、何ができるでしょうか?
注目してください、「私たち」とは何ですか？私自身は、「私たち」を、自分たちをイーサリアムエコシステムの一部と考え、このグループの機能とさらなる進化に関心を持っている人々の広範なグループとして定義します。これまでのところ、すべてのインタラクション方法は、自発的な参加、自ら設定した目標、自己達成に基づいて形成されてきました (これはオープンソース コミュニティではごく自然なことです)。私の知る限り、ハドソン・ジェイミーソンは、エコシステム全体でコミュニティ組織に貢献している唯一のフルタイムの有給人間です。それでも、彼の時間のほとんどはコア開発者との共同作業に費やされています。
最近の多くの論争は、ガバナンス プロセスにおけるネットワーク ガバナンスの位置を理解する方法、ネットワーク ガバナンスを実装する方法、参加方法や声を届ける方法などを中心に展開しています。
「利害関係者が組織化すべきだ」という考え方もある。私はこれを信じていますが、既存のインフラやチャネルを誰もが利用することを歓迎すべきだとも考えています。
プロトコル標準やコア開発者のコラボレーションよりもネットワーク ガバナンスを優先するのは意味がないと思います。これらは同期プロセスに似ています。私たちは技術コミュニティとして、これらの今後の中核となる EIP の内容をより適切に指摘し、広範な利害関係者グループが情報を得ることができるはずです。 ...
私の知る限り、ネットワーク ガバナンスは主にコア開発者の意識に疑問を生じさせることによって引き起こされます。コア開発者は、議論の多いハードフォークを引き起こしたくないなど、ネットワークの健全性を気にしているため、声をあげて合意を破ることができます。ただし、これは主に、関連する EIP がまだ実装されていないという事実によるものと考えられます。現時点で「はい」と言うのはさらに困難です。
副題
……
クライアント ソフトウェアを実行しているノード
最終的に、ブロックチェーン ネットワークの分散化は、誰もがノードを実行できることと、クライアント コード ベースをコピーして独自のクライアントを開発できるなど、実行するオープン ソース クライアント ソフトウェアのさまざまなバージョンを選択できることにかかっています。ほとんどの人よりも古い、パッチが適用されたバージョンを実行しています。
副題
イーサリアムのロードマップ
EIP 以外のもう 1 つの鍵は、イーサリアムのロードマップです。この疑問はベルリンで開催されたイーサリアム・マジシャンカンファレンスで初めて取り上げられ、長期ロードマップについて議論するイベントやオンライン会議の数が増えている。
イーサリアムのロードマップは、これまでのすべてのプロジェクトから繰り返し組み立てられるため、誰もそのロードマップを「完全に管理」しているわけではありません。
ただし、いわゆる「ETH 1.x」と「ETH 2」を強調する価値はあります。
ETH2 と略されるイーサリアム ネットワークの次のバージョンは、(マイナーがプルーフ オブ ワーク アルゴリズムを実行するのではなく) プルーフ オブ ステーク プロトコルに完全に基づいていることを望んでおり、全体的なスループットが大幅に向上するネットワークです。ネットワーク。 ETH2 は依然として主にイーサリアム財団から資金提供を受けた研究者によって推進されています。暫定的な実装計画は 3 つのフェーズに分かれていますが、EIP にはまだ記載されておらず、現在、技術仕様は主に実装者と研究者の協力によって作成されています。
今後の基本的な議論は、より多くの小規模なハード フォークを計画するべきか、それとも少数ではあるがより大きなハード フォークを計画するべきかということです。今では誰もが、頻繁だが小規模なフォークを好むようです。
参加方法は？
詳細については、Ethereum Wiki のロードマップ ページを参照してください。
副題
参加方法は？
上記をすべて読んだ方は、イーサリアム コミュニティに参加したくなるかもしれません。
私は Ethereum Magician フォーラムに多くの時間を費やしています。このフォーラムの良いところは、長い段落やサブ投稿のディスカッションがあることです。 GitHub の問題ページはアクセスしにくく、スレッド形式のディスカッションをサポートしていないため、このフォーラムは EIP ディスカッションのハブにもなっています。
