jakiro
著者：Christine Kim、Galaxy：Wuzhu、Bitchain Vision
2024年9月12日、Ethereum Protocol Developersは、ズーム仮想会議を通じて196回目の全コア開発者実行（ACDE）電話会議を開催しました。今週、電話会議は、Ethereum Foundation（EF）の契約支援責任者であるTim Beikoによって開催されました。ACDE電話会議は、開発者がEthereum実行レイヤー（EL）の変更について議論し、調整する隔週の会議シリーズです。
ACDE＃196で、開発者は、Pectra Devnet 3がリリースした最新の更新を共有し、将来開発ネットワークに実装されたさまざまなPectraコードの変更について議論しました。彼らは、アップグレードを2つの部分に分割することを真剣に議論したので、より速いスケジュール（おそらく来年2月までに）でDevNet 3にコードの変更を投稿できるようにしました。開発者は、次のACD電話会議でこれについて最終決定を下すことに同意しました。最後に、「PK910」という名前のEF開発者オペレーションエンジニアは、Ethereum Public TestNet GitHubリポジトリのクリーンアップとその構造を微調整するための彼の研究の最新の開発を共有しました。
Pectra devnet 3
EF開発およびオペレーションエンジニアのParisosh Jayanthiは、Pectra Devnet 3のリリースを導入しました。開発ネットワークは、9月11日水曜日に開始されました。これには、EIP 7251のバリデーターマージの修正と、EIP 7702の仕様を更新しました。これまでのところDevNet 3のテストに基づいて、EIP 7251とEIP 7702の両方が予想どおりに機能しているようです。Jayanthiは、オランダとEthereumjsのクライアントでいくつかの問題が見つかったいくつかの問題があり、両方のクライアントチームがそれらに対処するために取り組んでいると指摘しました。Jayanthiは、EIP 7702はDevNet 3でオンラインであるため、ウォレット開発者に実装をテストし、それらの使用に関するフィードバックを提供することをお勧めします。Tapsを含むPectra Devnet 3に関するすべての情報は、このWebサイトに記載されています。
ペクトラ仕様の更新
Gethの開発者Felix Langeは、ペクトラでのELトリガーリクエストのエンコードの変更を提案しています。背景として、PectraはELのスマートコントラクトを有効にして、CLでバリデーターの引き出しと合併を開始できます。前回のACDコールで、Langeはこれらの要求を解決するためにELクライアントが必要とする作業の量を減らすための提案を共有しました。先週の電話会議以来、Langeは彼の推奨事項と、ELクライアントチームが次の4つのEIPのエンコードを更新するために必要な作業を正式にしています。
-
EIP 7685、一般的な実行レイヤーリクエスト。
-
EIP 7002、ELは引き出しをトリガーできます。
-
EIP 6110、オンチェーン供給バリデーターデポジット。
-
EIP 7251、最大有効バランスを増やします。
開発者は一般に、Langeの提案に同意しました。しかし、「ダスティン」というタイトルのWebのNimbus開発者は、この提案は「無意味に柔軟性」であり、ELシリアル化形式の将来の変更と互換性がないと主張しました。彼はまた、ELがCLに無効な要求を提出するときに、ELクライアントのリクエストの順序とCLクライアントの行動を明確にするために追加の仕様が必要であることを強調しました。Langeは、リクエストの順序を指定するために、エンジンAPIにさらにテキストを追加することに同意します。彼はまた、CLクライアントがELクライアントからの無効な要求を検出したときのCLクライアントの行動をより深く考慮すべきであるというダスティンに同意します。
Ethereum Foundationの研究者Peter Millerは、CLクライアントの現在の仕様の下での論理的な動作に基づいて、CLクライアントは正しい方法でソートされていないELからブロックを拒否する必要があると指摘しました。さらに、ELがCLに共有するリストに無効な要求がある場合、CLはリスト内のすべての有効な要求を処理し、無効な要求を無視する必要があります。ダスティンはミラーに同意し、開発者に適切な文書でこの動作を指定するようアドバイスします。Beikoは、開発者がLangeの提案の問題を解決し、次のACDコールの前にそれを完了する必要があると述べました。
それから、Eragon開発者のAndrew Ashikhminは、EIP 7702の更新を提案し、EOAアカウントコードを設定しました。彼は、EIPで指定された有効性チェックは、古いEIPで指定された有効性チェックと矛盾していることに注目しました。Gethの開発者Matt Garnett（別名「LightClient」）は、一貫性の問題に対処し、EIP 7702の有効性チェックを簡素化する代替手段があると述べました。ほとんどの開発者は、LightClientの提案を最終決定し、Pectra Devnet 4に追加することを好みます。
Pectraに関連する次の議論は、EIP 2537に基づくBLSの事前補償の価格設定に関するものです。Gethの開発者Jared Wasinger氏は、彼のベンチマーク分析によれば、BLSの事前コンパイルの価格は現在規定されている2倍の高さであるべきだと述べました。現在、コストはマルチスレッド実行に基づいています。これは、他の事前補償実行の価格設定の標準ではありません。したがって、単一のスレッドを使用した分析に基づいて、WasingerはEIP 2537で操作される割引テーブルを変更することをお勧めします。オランダのチームは、他のクライアントチームがEIPの独自のベンチマーク分析も簡単に実行できるように、ツールを開発していると報告しました。Beikoはチームに、BLSの事前コンパイルのために独自のベンチマークを実行し、今後2週間にわたってこれらの操作を再リケートするアイデアを考え出すことを勧めています。
ペクトラEIPサプリメント
その後、開発者はペクトラアップグレードに新しいEIPを追加するトピックについて議論し始めました。議論の冒頭で、Beikoは「Pectraにはすでに大量のEIPがあります。これは、コールの前に共有されている意見によると、これは断然最大のフォークです。」 EIP 7742（ELとCLの間のBLOBカウントの分離）は、アップグレードされたリストに含まれることがまだ考慮されているEIPの最も議論の余地のないリストであることは明らかです。
EFの研究者アレックス・ストークスは、ペクトラを2つの小さなハードフォークに分割するというアイデアを再び提案しました。「誰もがそれが非常に大きなフォークであることに同意していると思う。だから、自然なことはそれを2つに分割することです。通常、より小さなフォークのリスクはそれほど少ない。 EIPは、テスト、セキュリティ、レビューの負担に本当に追加されます」とストークスは言いました。ジャヤンティはまた、以前の電話会議でアイデアを提案しましたが、彼はまだ彼がまだ支持していると言いました。「主な理由は、現時点では多くのEIPがあり、スタックの多くのレイヤーに触れる傾向があり、追加するほど、誰もが現在の変更でさえすべての変化をグローバルに理解するのが難しいことだと思います。ジャヤンティは言った。
現在のPectra EIPを2つのブランチに分割できる方法に関して、Stokesは現在開発ネットワークで実行されているすべてのEIPを使用してPectraの最初の部分を公開し、Peerdas、EOF、およびその他の追加のEIPを使用して2番目のEIPを使用して推奨しています。ペクトラの一部。開発者は、そうすることで、来年2月までにペクトラの最初の部分をリリースできると確信しています。「6月の前半しかリリースしない場合、このフォークは失敗になると思います」とEFの研究者Ansgar Dietrichsはズームチャットで述べました。
Beikoはフォーキングのアイデアを好みますが、開発ネットワークからEIPを削除することを警告しています。これにより、クライアントチームにより多くの作業をもたらし、これらのコード変更を準備するためのメインネットをアクティブにするためのタイムラインを短縮するのではなく、拡張する可能性があるためです。独立したイーサリアムプロトコル開発者であるDanno Ferrinは、MainNetをアクティブにするためにDevNet 3のEIPをできるだけ早く改善し、DevNet 4または5からPectra EIPにPectra EIPに移動し、並行して作業することを推奨しています。実際、ペクトラの後のアップグレードでは、DevNet 4または5がDevNet 0になり、開発者はそれをどのように名前にするかがわかりません。
以前の電話会議で、開発者はPectra Fusakaにちなんでアップグレードに名前を付けることに同意しましたが、Verkleの移行のためのアップグレードを維持することにも同意しました。これに関して、フェリンは、コードの変更がメインネットのアクティブ化の準備が整っていることを確信するまで、開発者に事前にアップグレードを予約しないようにアドバイスします。これにより、Gethの開発者Guillaume Balletが怒りを引き起こしました。GuillaumeBalletは、Verkleの移行をリードしており、Verkleの移行が「ずっと前に」準備されていると主張しています。緊張を和らげるために、Beikoは、ペクトラを2つに分割するという目標は、最終的にはより速いタイムラインでペクトラコードの変更をリリースしようとすることであり、その後のVerkle遷移の方法をクリアするのに役立つと述べました。
しかし、より多くのEIPを追加するにつれて、ペクトラアップグレードの2番目の部分が大きくなる可能性があるというリスクがあるため、現在のペクトラEIPリストが同時にリリースされるよりもリリースに時間がかかります。Nethermindの開発者Ben Adamsは質問しました、アップグレードが2つの部分に分割されている場合、ペクトラテストプロセスはどのように進行しますか。この決定がイーサリアムの次の即時アップグレードの範囲に革命をもたらすことを考えると、Beikoは開発者にこのアイデアについて考える1週間を費やすようアドバイスします。彼は開発者に、来週の木曜日のすべてのコア開発者に対するコンセンサスの呼びかけに関する問題に関する最終決定の準備をするように頼みました。
ネットワーク構成構造アライメント
最後になりましたが、EF Dev Operations Engineer “PK910″は彼の作業更新を共有して、Ethereum Public TestNet GitHubリポジトリをクリーンアップし、その構造を微調整して使いやすいように調整しました。彼は、クライアントチームに、Ethereum MainNetとTestNetのノード構成をチェックし、欠落している情報を対応するリポジトリに追加するように依頼しました。
