原題: "Ethereum All Core Developers Execution Call #186 Writeup"
原著者: Christine Kim
原編集: Frost, BlockBeats
編集者注:
全コア イーサリアム開発者コンセンサス コール (ACDE) は、イーサリアム実行層 (EL) への変更について話し合い、調整するために 2 週間ごとに開催されます。 ACDE の第 186 回電話会議で、開発者は Pectra Devnet 0 および EIP 3074 実装の準備について話し合いました。彼らは、Pectra Devnet 0 の準備におけるさまざまな顧客チームの進捗状況を詳しく説明し、EIP 3074 仕様への変更案と関連するテストの進捗状況について話し合いました。
さらに、この記事では、Pectra アップグレードに含まれる可能性のある他のコード変更の説明や、イーサリアム EIP プロセスへの変更が L2/RIP プロセスによってどのような影響を受けるかについての説明など、他の重要なトピックについても触れています。 。 Galaxy Digital のリサーチ担当副社長である Christine Kim は、この会議の要点を詳細に記録し、BlockBeasts はその原文を次のようにまとめました:
2024 年 4 月 25 日、イーサリアム開発者は All Core Developers に参加するために Zoom に集まりました。実行 ( ACDE ) コール # 186 会議。 ACDE 電話会議は、イーサリアム財団のプロトコル サポート責任者であるティム ベイコが主催する隔週の一連の会議であり、開発者はイーサリアム実行層 (EL) への変更について話し合い、調整します。今週、開発者は Pectra Devnet 0 および EIP 3074 実装の準備について話し合いました。彼らはまた、Pectra のアップグレードに含めるために他の EIP を考慮すべきであることや、イーサリアムの「ロールアップ中心のロードマップ」を踏まえたガバナンスの変更に関するより広範な考え方についても議論しました。
Beiko は、電話会議中にアカウント チームに Pectra Devnet 0 の最新の進捗状況を共有するよう依頼しました。 Nethermind チームの Marek Moraczyński 氏は、Nethermind はすべての Pectra EIP を実装し、テストしていると述べました。 Besu チームの Justin Florentine 氏は、Besu は Pectra EIP を実装し、Devnet 0 のロールアウトの準備に協力していると述べました。 Erigon チームの Andrew Ashkhmin 氏は、「Erigon が Devnet 0 の完全なスイートに対応する EIP の数を受け入れる準備ができているかどうかはわかりません。その理由の 1 つは、これらの EIP の仕様はまだ変更中であり、Erigon クライアントは新しいバージョンに移行しているためです」と述べています。メジャー バージョン Erigon 3。Erigon 3 と Pectra EIP が完成して Erigon クライアントに一緒に組み込まれるため、これにはチームのリソースと時間がかかります。」 Geth チームの「Lightclient」は、Geth が Devnet 0 の準備が整うまで「あと数日」であると述べました。 Ethereum JS チームの Gajinder Singh 氏は、Ethereum JS も Devnet 0 に「対応する」予定であると述べました。
Lightclient は EIP 7685 をマージし、EL によってトリガーされたリクエストをコンセンサス層 (CL) に保存するための共通フレームワークと、その EIP 6110 および 7002 への影響を作成します。 Beiko氏は、開発者はこのEIPをDevnet 0リリースに組み込み、Pectra EIPの改善を続ける必要があると述べた。
テストに関しては、EFテストチームのマリオ・ベガ氏は、EIP 6110と2537のテストは完了し、EIP 7002とEIP 2935のテストは今週か来週に完了すると述べた。 EIP 3074 のテストは、Devnet 0 に対してまだ準備ができていません。 EF 研究者の Antonio Sanso 氏は、EIP 2537 仕様が更新され、新しいテスト ベクターが GitHub リポジトリに追加されたと述べ、GitHub でそれをチェックすることをすべての人に推奨しています。 EFの研究者Hsiao Wei Wang氏は、CL仕様のテストベクトルに誤りがあると指摘し、その誤りはすぐに修正され、新しいバージョンがリリースされた。
今週の ACDE による EIP 3074 仕様の呼びかけでは、いくつかの変更が提案されています。 Ahmad Mazen Bitar 氏は、EIP 3074 の動作を変更して、AUTH CALL の前に DELEGATECALL ができるようにすることを提案しました。これにより、EIP の使用例が拡張されます。ブロックチェーンウォレットオペレーティングシステムZeroDevの創設者兼CEOであるデレク・ジャン氏は、必要に応じてAUTHメッセージやその他の変更のグローバルな取り消しを容易にする「ノンスマネージャー」を作成することを提案しました。電話会議に参加した一部の開発者は、EIP 3074 への変更は実装が大幅に困難になるため、延期すべきであると考えていました。
Beiko は、開発者が EIP 3074 に対する変更案について個別の分科会セッションで議論することを推奨しています。同氏は、Pectra に EIP 3074 を実装するのに十分な時間を確保するために、開発者は「今後 1 ～ 2 か月以内に」その仕様を最終決定するよう努めるべきであると述べました。 Lightclient は、EIP 3074 ブレークアウト セッションを開催することに同意します。 Devnet 0 については、開発者が将来の Devnet で EIP を別の方法で実装するか、アップグレードから完全に削除することを決定する場合でも、顧客チームは変更を加えずに EIP 3074 を実装する必要があることを Beiko は確認しました。
EIP 3074 の実装の詳細に加えて、開発者は EIP に十分なコミュニティ サポートがあるかどうかについても真剣に議論しました。スクリーン名が「Siri」である開発者の1人は、通話中に「EIP 3074は原理的に悪いものであり、完全なアカウント抽象化を達成する能力を遅らせるだろう」と懸念を表明した。ベイコ氏は、イーサリアム・マジシャンとACDの通話での議論に基づいて、アカウントチームはアカウント抽象化（AA）に関連する他の提案よりもEIP 3074を支持しているようだと答えた。 Beiko 氏は、「これは短期的には最も合意に達した提案であると思われます。この点で、Siri は、顧客チームが単独でこの決定を下すべきではないと考えています。」と述べました。 「私たちは他の利害関係者の意見に耳を傾けるべきです」と Siri 氏は付け加えました。「私たちは、議論の多いハードフォークを作成するという領域に逸れたくありません。他の利害関係者が何を言っているのか、そして彼らがこれをどのように見ているのかを理解するのは良いことだと思います。 . 提案。「
Beiko と Siri は、ACD の通話を超えて EIP に関するより広範な合意を構築する方法についても議論しました。 Chiang 氏は、まず EIP 3074 分科会を開催して EIP の技術仕様を徹底的に議論し、その後 Pectra アップグレードに残すかどうかを決定することを提案しました。 EFの研究者アンスガー・ディートリヒス氏は、「十分な進展がなければ、EIP 3074は廃止されることを理解すべきだ」と述べ、
イーサリアムの共同創設者ヴィタリック・ブテリン氏は、「ユーザーアカウントの機能は今後数年間で変更されようとしている」と付け加えた。外部所有アカウント (EOA)。EIP 3074 などの EIP に関連するアクティベーション アカウント抽象化
開発者は、Pectra アップグレードに含めるべき他のコード変更について引き続き議論しています。 Geth開発者のMarius van der Wijden氏は、EOFのようなより複雑なEIPがPectraに導入されるかどうかに依存するべきだと述べた。 「EOF を含めると、フォークの飽和につながるでしょう。EOF を含めなければ、もっと多くのものを含めることができるかもしれません」と van der Wijden 氏は言いました。
Siri は、セキュリティレビューなしで Pectra に EIP 3074 が含まれることに懸念を表明しました。 Beiko 氏は、EIP 3074 の仕様が完成するまでこの議論を保留することを提案しました。
Bitar さんは、EIP 7212 が Pectra に追加されることを望んでいると言いました。 EIP 7212 は、secp256 r1 楕円曲線で署名検証を実行する新しいプリコンパイルを作成します。これは、ユーザーの生体認証をサポートするハードウェア デバイスで使用できます。 Bitar氏は、イーサリアムトランザクションに署名するための生体認証をサポートすれば、ユーザーエクスペリエンスが大幅に改善されるだろうと述べた。アシヘミン氏もこの提案には賛成だと述べた。 Dietrichs 氏は、これが「ロールアップ改善提案」(RIP) プロセスを通じてレイヤー 2 ロールアップによって実装が承認された唯一のソリューションであると指摘しました。
Dietrichs、van der Wijden、Moraczyński などの他の開発者は、通話データのコストが増加し、最大ブロック サイズが制限される EIP 7623 のサポートを表明しています。 Beiko 氏は、EIP 7623 と EIP 7212 を「検討中」または Pectra への CFI としてマークし、Devnet 0 のリリース後にこれら 2 つの改善提案をサポートするためにクライアント チームの帯域幅を再検討することを推奨しています。
EL のシリアル化メソッドを SSZ に更新することに関連する EIP バンドルに関して、van der Wijden 氏は、これらを Pectra で転送するのは難しすぎるだろうと懸念を表明しました。ゲス チームの同僚であるギョーム バレエもこの評価に同意しています。ブテリン氏もこれに同調し、イーサリアム上に構築されたレイヤー 2 ロールアップの追加のセキュリティ監査オーバーヘッドを排除できるため、少なくともトランザクションのレシートを更新するためのシリアル化方法はイーサリアム自体を超える「重大な価値」を持つだろうと述べた。 ”。 SSZ 関連 EIP の主な後援者である Nimbus チームの Etan Kissling 氏はこの会議には出席していませんでしたが、彼はなぜこれらのコード変更が重要であり、Pectra に含めることを検討すべきなのかについて GitHub に詳細な説明を書きました。
開発者はまた、EOF を再検討しました。独立系イーサリアムプロトコル開発者のダンノ・フェリン氏は、EOFチームがコード変更に関するEL仕様テストを実施していると述べた。 EVMOne と Reth は、EOF 実装を完了したと報告されている 2 つの EL クライアント チームです。フェリン氏は、ゲスのチームは実装に関して「良い進歩」を遂げたと述べた。 Ferrin 氏は、Ballet は Solidity チームの「Daniel」と協力して、EOF と Verkle の互換性に関する懸念に対処していると付け加えました。
Ballet 氏は、Daniel や Dietrichs などの他の開発者との会話に基づいて、EOF の目的を損なうことなく、開発者が EOF のようなコード変更を別のセットで実装する機会を増やすことなく、EOF の範囲を狭めることは困難であると指摘しました。未来。
スクリーン ネーム「Charles C」で活動する開発者は、小規模または大規模な EOF アップグレード間ではなく、サイド カー メカニズム (Blob トランザクションに使用されるものなど) を介して EOF を反復的に簡単に実装する方法を探すことを提案しました。 。 Dietrichs 氏はチャットで、EOF の複雑さが軽減されれば、アカウント チームは Pectra にもっと興味を持つだろうかと尋ねました。 Ipsilon チームは、EOF で最も複雑なコード変更 (「TX create」など) が解決されており、「EOF create」などの機能に対する特定のリクエストを削除しても、EOF 全体の複雑さが大幅に軽減されるわけではないと指摘しました。ちなみに、Ipsilon は EF が資金提供する EVM R&D チームの名前です。 Beiko 氏は、開発者が定期的な EOF 分科会セッションで EOF 実装について議論し続けることを推奨しています。
ACDE #186 で議論された最後のトピックとして、開発者は新しい RIP プロセスを検討するためのイーサリアム EIP プロセスの変更について議論しました。 Dietrichs 氏は、開発者がロールアップ調整、ロールコール、RIP プロセスに関する会議シリーズを開始してから 6 か月が経過したと述べました。現在、これらのプロセスがイーサリアム EIP プロセスにどのような影響を与えるか、また影響を与えるべきかについて未解決の疑問がいくつかあります。ディートリヒス氏は、L2 で進行中の研究課題の 1 つは、ロールアップにとってイーサリアム仮想マシン (EVM) との長期的な同等性が望ましいかどうかであると述べました。同氏はまた、未解決の問題は、L2に実装された変更が最終的にイーサリアムのレイヤー1でのプロトコル決定にどの程度影響を与えるかであると付け加えた。
Geth 開発者 Péter Szilágyi 氏は、L2 で利用可能な一部の機能は、L1 での提供には適していない可能性があり、場合によっては、L2 で利用可能な機能に従っていても、L2 間に違いが存在する可能性があり、それが混乱を引き起こす可能性があると述べました。イーサリアムプロトコルの開発者。 EF 研究者の Carl Beekhuizen 氏は、RollCalls と RIP プロセスでは、イーサリアム プロトコル開発者が L2 で機能をリリースする必要はなく、むしろ Szilágyi 氏が説明したような混乱した状況を避けるために、ロールアップとイーサリアム開発者間のコミュニケーションが改善されると指摘しました。 Van der Wijden 氏は、プロトコル開発者が L2 に実装された変更のサポートに時間を費やしており、L2 自体がシャットダウンするか使用されなくなると、最終的には時代遅れになるか不要になるのではないかと懸念を表明しました。
これらの懸念について、ディートリヒス氏は次のように述べています。「人々は常に、レイヤー 2 が実験され、よりクレイジーになる可能性があると考えてきたと思います。実際に私たちが目にしているのは、ほとんどの人がそうしないことを決定しているということです。少なくとも、おそらくそれが始まっていても、それをやっていましたが、時間が経つにつれて、ほとんどの人はそれをやめました。そのため、現在では、少なくともロールアップ中心のロードマップを考慮すると、ほとんどが最初のレイヤーの仕様に従っていると思います。または、それが私たち全員が考える最良の方法です。エコシステムが進化するためには、ここで進む最善の道など、少なくともレイヤー 2 からの明確なガイダンスとコミュニケーションが必要です。」
以上がイーサリアムコア開発者の最新会議の概要: EIP 3074 の実装準備、ロールアップロードマップの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
