原題:Ethereum All Core Developers Consensus Call #107 Writeup

原題:

2023 年 4 月 20 日、イーサリアム開発者は第 107 回コア開発者コンセンサスカンファレンスコール (ACDC) に集まりました。 ACDCは、イーサリアム財団の研究者であるダニー・ライアンが司会を務める隔週のカンファレンスシリーズで、イーサリアム開発者がイーサリアムコンセンサス層（CL）への変更について議論し、デネブに関する進捗状況を更新し、イーサリアムEIP-4844以外の他の提案について議論します。次回のカンクンのアップグレードに含まれます。

Deneb Devnet #5 

最初のレベルのタイトル

4月12日に上海でアクティベーションが成功して以来、イーサリアム開発者は初めてカンクンの準備に注目するようになった。 Cancun はイーサリアム実行層 (EL) の次のアップグレードの名前であり、Deneb は CL に対応するアップグレードの名前です。 ACDEの通話中、開発者らはEIP 4844を中心とするカンクン/デネブのアップグレードの最終範囲、BLOBトランザクションタイプの実装、devnet #5の立ち上げから始まるデネブの準備状況について議論した。
開発者は昨年 10 月以来、EIP 4844 用のマルチクライアント テストネット (devnet とも​​呼ばれる) を立ち上げてきました。 ACDEカンファレンスコールの議長であるティム・ベイコ氏によると、EIP 4844の5番目のdevnetは来週中に開始される予定だという。イーサリアム財団の DevOps エンジニアであるパリトシュ・ジャヤンティ氏は、来週の開発ネットの立ち上げに備えて、イーサリアム JS (EL) や Lodestar (CL) などのクライアント向けにパイロットを実行していると述べた。

特に、「getPayload V3」呼び出しと「getBlobsBundle V1」呼び出しを 1 つにマージするエンジン API に小さな変更が加えられています。 Beiko 氏は、この変更はまだ GitHub 上の EIP 4844 仕様にマージされていないが、devnet #5 で変更をテストできるように数日以内にマージされる予定であることを強調し、Beiko 氏はクライアント チームにこの変更をできるだけ早くレビューするよう促しました。できるだけ。ETHTokyo次に、開発者は、チェーンの再編成が発生した場合に BLOB トランザクションをブロックに再挿入する方法について話し合いました。この質問は、Geth (EL) の開発者 Péter Szilágyi 氏の著書で尋ねられました。PPT上記のプレゼンテーションで提案されました (Szilágyi's で入手可能)

詳細については、を参照してください。) 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) を実装する将来のアップグレードで壊れる可能性があります。

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

Deneb Add-Ons

最初のレベルのタイトル

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

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

2. EIP-6914、この提案では、ネットワークから完全に削除され、一定期間アクティブになっていないバリデーター番号を再利用できます。この EIP は、バリデーターが終了し、新しいバリデーターがネットワークに参加する際に、バリデーター・リストが無限に増大することを軽減するのに役立ちます。ストークス氏は、EIP 6914の複雑さは比較的高く、コードの変更はデネブ後の次のハードフォークまで延期されるべきだと述べた。 EIP-6914 の複雑さについて議論した後、開発者はコード更新の詳細に引き続き注力することに同意しましたが、最終的な実装はデネブまで残されました。
4、PR 3175 3. Ryan は、Beacon Chain ジェネシス ブロックからのデータのバックフィルと新しい「歴史的概要」コンテンツの作成を含むコード変更の可能性を提案しました。このコード変更の詳細はまだ EIP に指定されていません。 Ryan は、この変更の提案者である Jacek Sieka (Status の研究開発責任者、Nimbus (CL) クライアントを構築している) に詳細を問い合わせることに同意しました。

、この提案により、ペナルティを受けたバリデーターがデキュー時にブロックを提案できなくなります。バリデーターの 50% 以上が悪意のある動作でペナルティを受けた場合でも、それらのバリデーターはネットワークから強制的に削除されている間もブロックを提案できます。このロジックの変更は比較的小規模な CL 層の変更であり、「高故障モード」に対する保護を提供すると Ryan 氏は述べています。5. EIP-6493。CL では SSZ でフォーマットされているが、EL では異なる方法でエンコードされている BLOB トランザクション タイプをノードが処理する方法に対処します。この EIP は、レイヤ間の一貫性を実現するための Ethereum シリアル化フォーマットの更新の一部です。 Ethereum シリアル化形式に関する詳細な背景情報は、前もって読むことができます。。

開発者記録