イーサリアム改善提案およびアップグレードプロセス改善提案
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
、著者：Tim Beiko、翻訳および校正：Peter Chen & A Jian、Odaily が許可を得て転載。
まとめ
この投稿は、DevconV (第 6 回イーサリアム開発者カンファレンス) での Danno Ferrin と私との会話の大まかな記録です。この記事では、過去 1 年間にコミュニティによって提案されたいくつかの EIP プロセス改善提案について説明し、それらを統合フレームワークに組み込んで、イーサリアムをよりスムーズにアップグレードする方法をガイドします。私たちはこれを「駅模型」と呼んでいます。
副題
まとめ
過去 1 年間にコミュニティから寄せられたいくつかの提案に基づいて、私たちはイーサリアム ネットワーク上のアップグレードを調整するための新しい方法を提案します。具体的には、次のように考えています。
コミュニティに明確な予測可能性を提供するために、アップグレードは年に 2 回行われる必要があります。
アップグレードには、リリースの準備ができているイーサリアム改善提案 (EIP) のみを含める必要があり、まだ議論中の改善は次のアップグレードに組み込む必要があり、現在のアップグレードを遅らせることはできません。
イーサリアムの改善提案はワーキンググループによって独立した方法で開発されるべきであり、完了した場合にのみアップグレードに含めることが検討されるべきです。
イーサリアムの改善提案と作業グループには、コミュニティに連絡し、関連する EIP に関するコミュニティの質問に答える擁護者または代表者が必要です。
イーサリアムのアップグレードの歴史について簡単に話しましょう。フロンティア、ホームランド、ビザンティウム、コンスタンティノープルを含む最初のいくつかのネットワーク アップグレードは、1950 年代の家族旅行に似ていました。お父さんとお母さんが車の荷解きをし、私たちは後部座席に乗り、お気に入りのおもちゃを持っていくこともありました。彼らは私たちを目的地まで安全に連れて行ってくれるでしょう。
これは過去のアップグレードの単純な例えですが、これらのアップグレードでは、コア開発者がほとんどのイーサリアム改善提案を作成し、イーサリアム コミュニティは組織的かつ計画的な方法でコミュニティと通信できるほど十分に小さかったため、フォークとアップグレードはスムーズに完了しました。
……でも、忙しい時もありますよ！急いで消火活動をしなければならなかったことが何度かありました。そのような場合、私たちは基本的に全員が兵士です。上海での Devcon 2 中のサイバー攻撃、DAO によるイーサリアム フォーク、コンスタンティノープルのアップグレード前の土壇場で発見された弱点のいずれであっても、コミュニティは常に団結してバグを修正し、問題を解決し、ユーザーが適切なタイミングでノードをアップグレードできるようにします。 。
画像の説明
～エセリウム色の滝～
今まではイスタンブールアップグレード。アップグレードの計画を開始したとき、私たちはワークフローを十分に把握していたので、アップグレード プロセスをより徹底的に計画することにしました。私たちはアップグレードプロセスの各段階にタイムノードを設定し、イーサリアムの改善提案から最終的なメインネットのアップグレードまで詳細な計画を立てました。いつの間にか、私たちはイーサリアムのウォーターフォール モデルのような状態になっていました。
しかし、これらの計画された時間ノードのうち、実際に時間通りに完了するノードは何個あるでしょうか?一つだけあり、それが始まりです。
実行中に多くの問題が発生しました。より重要な理由の 1 つは、イーサリアム コミュニティが前回のアップグレード以来大幅に成長し、イスタンブールのアップグレード提案のレビューを開始する時期が来たとき、コア開発者は単なる 1 つのイーサリアム改善提案ではなく、30 を超えるイーサリアム改善提案をパッケージ化する必要があったことです。コメントすべき提案がいくつかあります!
画像の説明
イーサリアム・イスタンブールの最終改善提案のリストを入手したときはすでに夏の真っ最中で、当初の計画ではこの頃にはクライアントの実装が完了しているはずでした。これが起こったとき、開発プロセスが予想をはるかに下回っていることに多くの人が気づき、イスタンブール後のベルリンのアップグレードをよりスムーズに進める方法について多くの提案がなされました。ここで、これらの提案のいくつかについて議論し、それらをいわゆる「鉄道駅モデル」に組み込むことにします。
画像の説明
副題
イーサリアム 1.X は EIP 開発プロセスの変更を試みる
イスタンブールのアップグレード中、最初に開発プロセスの問題を解決しようとしたのはアレクセイ・アクノフでした。彼はブログ投稿 (編集者注: 中国語訳については記事末尾のハイパーリンクを参照) を書き、ReTestEth を使用してワーキング グループを形成し、イーサリアム プロトコルの改善に貢献するメンバーの数を増やす方法を説明しました。既存のコア開発者の負担。 「pre-1.x」の改善プロセスでは、提出されたイーサリアム改善提案は主に Geth、Parity、Aleth のクライアント開発者によって実装され、その場合イーサリアム改善提案はこれらのチームによって共同で改善されます。クライアントがイーサリアム改善提案の最終仕様に同意すると、参照テストを生成できます。 Aleth はテストを生成できる唯一のクライアントであるため、これらのテストを生成するには、すべての Ethereum 改善提案が Aleth に実装される必要があります。次に、EF のテスト チームがこれらのテストを実行し、すべてのクライアントが実行する適合性テストを作成します。
-スライドショーの写真はアレクセイの元の投稿から抜粋-
このプロセスにはいくつかのボトルネックがあります。それは、メインのクライアント実装チーム、参照テストを生成する Aleth、および EF のテスト チームによって作成された適合テストです。作業効率を向上させるために、アレクセイはワーキンググループを設立するというアイデアを提案しました。これらの作業グループは、イーサリアムを改善したいという願望を共有する一部の人々で構成されます。彼らは、イーサリアム改善提案の初期段階から開始し、最終バージョンに多かれ少なかれ近い、または最終バージョンに到達するように提案を改良するのに役立ちます。このようにして、クライアント開発者は、成熟したイーサリアム改善提案、おそらく少なくとも初期実装、および関連する未解決の質問のほとんどがすでに回答されているのを見ることができます。
これに加えて、EF テスト チームによって開発された新しいテスト ツールである retesth を使用すると、ワーキング グループがあらゆるクライアント (現在は Geth、Aleth、および Hyperledger Besu) に必要な EIP リファレンス テストを生成できるようになります。したがって、このワーキンググループの枠組みは、イーサリアムの改善提案の改良プロセスを分散化するだけでなく、テストのボトルネックやプレッシャーも軽減します。
eEIP アドボケート
イスタンブールのアップグレードの準備中に、すべてのコア開発者が電話会議を開催することは珍しくありませんでしたが、誰も特定のイーサリアム改善提案について話しませんでした相互依存性や競合する提案により、アップグレード プロセス全体の進行が大幅に遅れる可能性があります。
画像の説明
-これらの問題について話し合うためのワークショップの開催にご協力いただいた国会議員とボリスに感謝します-
チャンピオンの役割は、EIP の連絡窓口となり、EIP のディスカッション コーディネーターとして機能し、アップグレード プロセスがスムーズに進み、適切な人材が適切な議論に参加できるようにすることです。彼らはすべての作業に責任を負うわけではなく、必ずしも自分たちで実装する必要はありませんが、イーサリアム改善提案の実装における主要人物となり、アップグレード プロセスをコミュニティ内のメンバーと十分に伝達することに尽力する必要があります。
副題
EIP中心のフォーク
EF チームの Martin Holst Swende 氏が最近提案したもう 1 つのアイデアは、イーサリアム ネットワークのアップグレード プロセスをより EIP 中心になるように調整することです。アップグレードに焦点を当て、アップグレードの各段階ですべてのイーサリアム改善提案が確実に確実に歩調を合わせようとするのではなく、各 EIP を成熟させることに重点を置き、成熟したリリース可能な EIP についてのみアップグレードを計画する方が良いでしょう。
イーサリアム改善提案をドラフト段階からメインネットのアクティベーションに成功させたい人がいる場合、このフレームワーク内でそれを行う方法は次のとおりです (元の提案から引用。読みやすくするために若干の編集を加えています)。
ステップ 1: ACD から承認を得る
イーサリアム改善提案が存在すると仮定すると (ステップ 0)、ALCORIEDEV (フォーラム) は、最初にイーサリアム改善提案が「仮承認」されるかどうかを決定します。 「仮承諾」（または「前向き」）とは、主要なクライアントとエコシステムの関係者がイーサリアムの改善提案に対して前向きな姿勢を持ち、EIPをコードベースに統合してテストを開始するための（よく書かれた）PRを喜んで受け入れることを意味します。ただし、この段階ではアクティベーションの実際のブロックの高さは指定されません。
この「予備承認」ステータスは、EF、ConsenSys、さらには MolochDAO などのプロトコルのアップグレードに資金を提供する組織にとっても有用なシグナル伝達メカニズムです。資金の大部分がメインネットの立ち上げを促進する取り組みに確実に費やされるように、資金はいくつかのフェーズ (つまり、「初期受け入れ」の前後) に分割できます。
ステップ 2: 実行
ACD が明確な指示を与えると、開発者や他のイーサリアム改善提案作成者は、その実装とクライアント向けのアップデートのリリースに取り組むことができます。
実装された機能がメイン クライアントにマージされると、このマイルストーンは完了します。
ステップ 3: テストケース
この機能をクライアントで「アクティブ化」できるようになったので、この機能のクロスクライアント テストを生成できるようになりました。テスト ケースにはハッピー パス テストと癖/エッジケース テストが含まれている必要があります。このステップは、 EVM（イーサリアム仮想マシン）を理解して理解している人が一緒に実行し、エラーの可能性を最小限に抑えます。
この段階では、セキュリティレビューも実施し、そのレビュープロジェクトを「セキュリティ上の考慮事項」の名の下にイーサリアムの改善案にフィードバックする必要があり、限界的な問題や問題点を発見することにもレビューの焦点を置く必要があります。見落とされやすい。このフェーズの完了は、テスト チームの承認によって示されます。
ステップ 4: ACD 最終承認
「それでは、1 か月後にテストネット上でこのイーサリアム改善提案 (ブロック高さ X) をアクティブ化し、2 か月後にメインネット上でこのイーサリアム改善提案 (ブロック高さ Y) をアクティブ化しましょう。」 すべてのクライアントは次のリリースにアップグレードを含めます。 、コマンドラインフラグを介してイーサリアムの改善提案を今から1週間延期することも現実的です。
複数のイーサリアム改善提案が同時にステップ 4 に到達した場合、イーサリアム改善提案に内部依存関係/結合がある可能性がある (これにより、不必要なテスト干渉）。
画像の説明
- ジェームス・ハンコック、とても鮮明な絵を描いてくれてありがとう！ -
このフレームワークを使用すると、イーサリアムの各改善提案を独自のペースで進めることができるため、アップグレード プロセス中の議論の時間と範囲が削減されると同時に、プロセスが以前よりも予測可能になるため、テスト チームへのプレッシャーも軽減されます。締め切り前に慌ててテストに集中する必要はありません。
副題
イーサリアム改善提案 1872
イーサリアム ネットワークのアップグレード プロセスをスムーズにするためのもう 1 つの提案は、Danno Ferrin によって提案された提案 1872 です。インフラストラクチャの中核部分としてイーサリアムに依存する企業が増えるにつれ、私たちはネットワークのアップグレードをより予測可能にすることに取り組む必要があります。
この提案では、マイクロソフトの火曜日の定期パッチリリースと同様に、イーサリアムがネットワークアップグレードのデフォルトスケジュールを採用することを提案しています。そうすることで、イーサリアム ノードを実行している人々は、潜在的なアップグレードを監視する可能性が高い時期を知ることができます。つまり、この提案は次のことを行うことを提案しています。
メインネットのアップグレードをデフォルトで月の第 3 水曜日に実行するようにします。米国とヨーロッパの主要な祝日のほとんどを避けるために、できれば 1 月、4 月、7 月、または 10 月に実行します。
アップグレードが予定どおりに展開されない場合、(コンスタンティノープルのアップグレード中に発生したように) 翌月の第 3 水曜日まで延期されます。
いつでもどこでも問題が発生したらすぐに解決する
この EIP は、予期せぬ状況に対処する当社の能力を制限するものではなく、アップグレードの不確実性に関する市場の懸念を軽減し、同時にコア開発者の数を減らすために、6 か月ごとの固定アップグレードなどのデフォルトの周期性を強調するだけです。プロセス。
また、これは、現在のアプローチと「1 つのイーサリアム改善提案、1 つのアップグレード」アプローチ (つまり、EIP 中心のフォーク アプローチ) との間の「中間点」も提供します。
副題
駅模型
上記の推奨事項の一部を組み合わせることで、現在の「空港の運営方法に近づける」プロセスよりも鉄道駅の運営方法に近いプロセスに到達しました。
現在、私たちのアップグレードは航空券の購入の仕組みに似ています。日付と時間が固定されており、たとえ遅延があったとしても手荷物検査によって全員を飛行機に乗せるよう努めています。
私たちは、人々が荷物を手に駅に到着し、すぐに出発し、次に空いている電車に乗って出発するモデルに移行することで、ネットワークのアップグレードが現在よりもはるかにスムーズになると考えています。
具体的には、駅モデルは主に 4 つのパーツで構成されます。
まず、各イーサリアム改善提案は独立して進める必要があります。ワーキンググループは提案を推進することができ、イーサリアム改善提案が準備完了状態になった場合にのみ、ネットワークのアップグレードをスケジュールします。
第二に、イーサリアムの改善提案と作業グループには擁護者が必要です。これらのチャンピオンは、イーサリアム改善提案の代表者およびデフォルトの連絡先として機能する必要があります。彼らは、AllCoreDevs またはその他のフォーラム上のコミュニティに提案を伝達する責任を負い、EIP の実際の実装者である場合とそうでない場合があります。
第三に、何が行われたかを公開します。ネットワークをアップグレードする場合は、リリースの準備ができているすべての EIP をアップグレードに組み込みます。まだ議論中の提案については、エスカレーションは予定されていません。同様に、土壇場でプロポーザルに問題が発生した場合は、アップグレード全体を延期するのではなく、次のアップグレードに移行します。
