カンクンのアップグレードには、EIP-4844 以外に何が含まれますか?

2023年4月20日、イーサリアム開発者が第107回コア開発者コンセンサスコール（ACDC）に集まりました。 ACDC は、Ethereum Foundation の研究者である Danny Ryan が主催する隔週の会議シリーズで、Ethereum 開発者が Ethereum Consensus Layer (CL) の変更について話し合い、Deneb に関する進捗状況を更新し、Ethereum EIP-4844 以外に次のカンクン アップグレードに含まれる他の提案について話し合います。

デネブ・デヴネット #5

4月12日の上海でのアクティベーションが成功して以来、イーサリアム開発者はすぐにカンクンの準備に目を向けた。 Cancun は Ethereum Execution Layer (EL) の次のアップグレードの名前であり、Deneb は対応する CL アップグレードの名前です。 ACDE コールでは、開発者は Cancun/Deneb アップグレードの最終的な範囲について話し合いました。この範囲は、EIP 4844、BLOB トランザクション タイプの実装、および devnet #5 のロールアウトから始まる Deneb の準備を中心に据えたものです。

開発者は昨年 10 月から、EIP 4844 向けに devnets とも呼ばれるマルチクライアント テスト ネットワークを立ち上げています。 ACDE コールの議長 Tim Beiko 氏は、EIP 4844 の 5 番目の開発ネットが来週中に開始される予定であると述べました。イーサリアム財団のDevOpsエンジニアであるパリトシュ・ジャヤンティ氏は、来週のDevNetローンチに備えて、イーサリアムJS（EL）やLodestar（CL）などのクライアント向けに試験運用を行っていると語った。
とりわけ、エンジン API に小さな変更が加えられ、「getPayload V3」と「getBlobsBundle V1」の呼び出しが 1 つに統合されました。 Beiko 氏は、この変更がまだ GitHub の EIP 4844 仕様にマージされていないことを強調したが、数日以内にマージされ、devnet #5 でテストできるようになる予定であり、クライアント チームにできるだけ早くこの変更を確認するよう促した。

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

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

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

EL クライアント グループの参加が不足していたため、この問題は次の ACDE 電話会議で再び取り上げられました。

デネブアドオン

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

1. 最初のものは EIP-4788 で、EL の CL ビーコン チェーンのステータスを公開できます。これにより、EL 上で実行されるスマート コントラクトは、ステーキング プール、再ステーキング プロトコル、MEV などに関連する、CL への信頼を最小限に抑えたアクセスが可能になります。Ethereum Foundation の研究者であり、EIP の著者の 1 人である Alex Stokes 氏は、この機能は CL に対する「軽量な」変更であると述べています。電話会議の参加者のうち、EIP 4788 を Deneb に含めることに反対する者はいなかった。 EL クライアント チームは、次回の ACDE コールでこの EIP のサポートについて相談を受ける予定です。

2. EIP-6914 は、ネットワークから完全に退出し、しばらく非アクティブであったバリデータキーを再利用できるようにしています。この EIP は、バリデーターが退出し、新しいバリデーターがネットワークに参加する際に、バリデーター リストが無制限に増加するのを抑えるのに役立ちます。ストークス氏は、EIP 6914 は比較的複雑であり、コードの変更は Deneb の次のハードフォークまで延期されるべきだと述べた。 EIP-6914 の複雑さについて話し合った後、開発者はコード更新の詳細を磨き続けるが、最終的な実装は Deneb の後まで残すことに合意しました。

3. Ryan は、Beacon Chain ジェネシス ブロックからデータをバックフィルし、新しい「履歴概要」コンテンツを作成する潜在的なコード変更を提案しました。このコード変更の詳細は、EIP ではまだ指定されていません。 Ryan は、この変更の提案者である Jacek Sieka (Nimbus (CL) クライアントを構築している Status R&D リーダー) に詳細について問い合わせることに同意しました。
PR 3175 は、処罰されたバリデータがキューから出るときにブロックを提案することを防ぎます。バリデーターの 50% 以上が悪質な行為で処罰された場合、ブロックを提案することは引き続き可能ですが、ネットワークから強制的に追放されます。ライアン氏は、このロジックの変更は比較的小さな CL レイヤーの変更であり、「高障害モード」に対する保護を提供するものだと述べた。

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

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