元のタイトル: Ethereum All Core Developers Consensus Call#107Writeup

原著者: Christine Kim (削除を加えて編集)

2023年4月20日、イーサリアム開発者が集まり、第107回コア開発者コンセンサスカンファレンスコール（ACDC）が開催されました。 ACDC は、イーサリアム財団の研究者ダニー ライアンが主催する隔週のカンファレンス シリーズです。この会議では、イーサリアム開発者がイーサリアム コンセンサス レイヤー (CL) の変更について話し合い、デネブに関する進捗状況を更新し、イーサリアム EIP-4844 に加えてその他のことについて話し合います。提案は次回のカンクンのアップグレードに含まれる予定です。

デネブ・デヴネット #5

4月12日に上海でアクティベーションが成功して以来、イーサリアム開発者はすぐにカンクンの準備に注目した。 Cancun はイーサリアム実行層 (EL) の次のアップグレードの名前であり、Deneb は CL に対応するアップグレードの名前です。 ACDEの電話会議中、開発者らは、EIP 4844を中心とするカンクン/デネブのアップグレードの最終範囲、BLOBトランザクションタイプの実装、devnet #5の展開に向けたデネブの準備状況について議論した。

開発者は昨年 10 月以来、EIP 4844 用のマルチクライアント テスト ネットワーク (devnet とも​​呼ばれる) を立ち上げてきました。 ACDEカンファレンスコール議長のTim Beiko氏は、EIP 4844の5番目のdevnetが来週中に開始されると述べた。イーサリアム財団の DevOps エンジニアであるパリトシュ・ジャヤンティ氏は、来週の開発ネットの立ち上げに備えて、イーサリアム JS (EL) や Lodestar (CL) などのクライアント向けに試験運用を行っていると述べた。

その中には、エンジン API に小さな変更があり、「getPayloadV3」呼び出しと「getBlobsBundleV1」呼び出しが 1 つにマージされています。 Beiko 氏は、この変更はまだ GitHub 上の EIP 4844 仕様に統合されていないが、devnet#5で変更をテストできるように数日以内に統合される予定であることを強調し、Beiko 氏はクライアント チームにこの変更をレビューするよう促しました。できるだけ早く。

次に、開発者は、チェーンが再編成されたときに BLOB トランザクションをブロックに再挿入する方法について議論しました。この質問は、Geth (EL) 開発者の Péter Szilágyi が ETHTokyo でのプレゼンテーションで尋ねたものです (詳細については、Szilágyi の PPT を参照してください)。 Ryan 氏は、BLOB トランザクションが通常のトランザクションから分離されているため、再編成された BLOB はパブリック メモリプール内のトランザクションからのみ取得できると述べました。 mempool をバイパスするトランザクション (MEV トランザクションやバンドルなど) が多数あることを考慮すると、すべての BLOB (mempool をバイパスするトランザクションも含めて) を再構築できることを保証する 1 つの方法は、CL に各ブロックの BLOB データを EL に渡すことです。その後、EL はブロックが完了するまでそれをキャッシュできます。あるいは、ネットワークは、メモリプールをスキップしたトランザクションを送信したユーザーに、チェーン再編成イベントでトランザクションを再送信するよう要求することもできます。

Szilágyi 氏は、前者を好むと述べました。これは、BLOB データを EL に転送することで、メモリプールをバイパスするトランザクションであっても、再編成時にトランザクションを再挿入できるようにするものです。 Szilágyi 氏の意見では、EL への追加負荷は重大ではなく、プロセスが煩雑すぎてノードがサポートできない場合、開発者は EL と CL 間のメッセージを調整して負荷を軽減できます。 「最も簡単な解決策は、コンセンサス クライアントが新しいペイロードを送信するときに、実行クライアントに BLOB を提供することです」と Szilágyi 氏は述べています。 Ryan 氏は、提案されたソリューションはシンプルではあるが、EL 層と CL 層の間の抽象化をさらに破壊することになると答えました。さらに、このソリューションでは、ノードが完全なデータを保存するという前提が強制されますが、将来のデータ可用性サンプリング (DAS) アップグレードの実装では、この前提が崩れる可能性があります。

DAS の実装に関して、Szilágyi 氏は、このアップグレードではデータの可用性に関して変更する必要がある他の期待事項があると述べ、開発者に「それまでにそれを理解するよう努める」ようアドバイスしました。 Ryan 氏もこれに同意し、チェーンの再編成と BLOB トランザクションの再挿入に関する状況について他の開発者に意見を求めました。 Lodestar (CL) クライアントの開発者である Gajinder Singh 氏は、MEV トランザクションはパブリック メモリプールをバイパスする最も一般的なタイプであり、MEV トランザクションは実行時に特定のチェーン状態に大きく依存しているため、トランザクションの実行後にトランザクションを削除することは重要ではないと述べました。チェーンのステータスが変更されたため、チェーンの再編成。MEV トランザクションの再実行が必要になる可能性があります。

EL クライアント グループの参加がなかったため、この問題は次回の ACDE 電話会議で再び提起されました。

デネブアドオン

Deneb のアップグレードでは、EIP-4844 に加えて、他のコードのアップグレードも考慮されます。

1. 1 つ目は EIP-4788 で、EL の CL ビーコン チェーンのステータスを公開する可能性があります。これにより、EL で実行されるスマート コントラクトは、ステーキング プール、再ステーキング プロトコル、MEV などに関連する CL への信頼を最小限に抑えたアクセスが可能になります。 EIPの作成者の1人であるイーサリアム財団の研究者アレックス・ストークス氏は、この機能はCLに対する「軽量な」変更であると述べた。電話会議では、EIP 4788 をデネブに含めることに反対する人はいませんでした。次回の ACDE コールでこの EIP をサポートするために、EL クライアント チームからの意見を求めます。

2. EIP-6914、この提案では、ネットワークから完全に離脱し、一定期間非アクティブだったバリデーター番号を再利用できます。この EIP は、バリデーターが終了し、新しいバリデーターがネットワークに参加する際に、バリデーター・リストが無限に増大することを軽減するのに役立ちます。 Stokes氏は、EIP 6914の複雑さは比較的高く、コードの変更はDenebの次のハードフォークまで延期されるべきだと述べた。 EIP-6914 の複雑さについて議論した後、開発者はコード更新の詳細に引き続き注力することに同意しましたが、最終的な実装は Deneb の後まで残されました。

3. Ryan は、ビーコン チェーン生成ブロックから開始してデータをバックフィルし、新しい「履歴概要」コンテンツを作成するコード変更の可能性を提案しました。このコード変更の詳細はまだ EIP に指定されていません。 Ryan は、この変更の提案者である Jacek Sieka (Status の研究開発責任者、Nimbus (CL) クライアントを構築している) に詳細を問い合わせることに同意しました。

4. PR 3175、この提案は、罰せられたバリデーターがキューから出るときにブロックを提案できないようにします。バリデーターの 50% 以上が悪意のある行為で処罰された場合でも、これらのバリデーターはネットワークから強制的に排除されながらもブロックを提案することができます。 Ryan 氏は、このロジックの変更は、「高故障モード」に対する保護を提供する比較的小規模な CL 層の変更であると述べました。

5. EIP-6493、この提案は、CL では SSZ 形式でフォーマットされているが、EL では異なる方法でエンコードされている BLOB トランザクション タイプをノードが処理する方法を扱います。この EIP は、レイヤ間の一貫性を実現するためにイーサリアムのシリアル化形式を更新する取り組みの一環です。 Ethereum シリアル化形式の背景情報の詳細については、以前の開発者ノートを参照してください。

デネブ全体の議論では、開発者は次のアップグレードに EIP-4844 とともに EIP-4788 および EIP-3175 を含めることに傾いています。