deneb

ChainCatcher のメッセージ、Galaxy の研究副社長 Christine Kim が第 123 回イーサリアムコア開発者コンセンサス（ACDC）電話会議をまとめました。Cancun/Deneb アップグレードは 11 月 30 日に Devnet #12 でアクティブ化され、Teku、Lodestar、Lighthouse クライアントソフトウェアおよびすべての実行層（EL）クライアントソフトウェアは現在 Devnet #12 でテスト中です。さらに、開発者は Devnet #11 でのバリデーターの退出問題を発見し、Nimbus クライアントチームがその問題を解決しています。Devnet #11 は問題が解決されるまで通常通り運用されます。CL クライアント Prysm がまだ Devnet #12 に参加していないため、開発者は Prysm クライアントソフトウェアがテストの準備が整うまで Goerli シャドーフォークの計画を延期することに同意しました。Tim Beiko は、今年の年末前のどこかで Goerli シャドーフォークをリリースすることを提案しました。さらに、開発者は "BlockByRoot" および "BlobSidecarsByRoot" リクエストの仕様を明確にするために、CL ノードがこれらのリクエストに特定の順序で応答すべきかどうかを明記することについて議論しました。

ChainCatcher のメッセージによると、Galaxy の研究副社長クリスティン・キムは、イーサリアムのコア開発者が今週第110回全コア開発者コンセンサス (ACDC) 電話会議を開催したとまとめています。開発者たちは会議でイーサリアムのコンセンサスレイヤー (CL) の変更について議論し、調整を行いました。今週、イーサリアム財団の研究者ダンクラッド・ファイストは、イーサリアムメインネットノードが大量のデータを伝播する能力に関するデータ実験結果を紹介しました。彼の発見に基づき、EIP 4844 の仕様を各ブロックあたり最大4つのblobから6つに増やすことを提案しています。さらに、CLクライアントチームはEIP 4788をDenebアップグレードに組み込むことを検討しています。EIP 4788は、スマートコントラクトや分散型アプリケーション (dapps) に対して、CLやバリデーターの残高、活動、報酬などの情報にアクセスするための信頼最小化の方法を導入しています。（出典リンク）

ChainCatcher のメッセージで、Galaxy の研究副社長 Christine Kim が第 108 回イーサリアムコア開発者コンセンサス会議の要約を発表しました。その中で、開発者は EIP-4788 と EIP-6987 を Deneb に組み込んでテストすることを検討することに同意しました。EIP-4788 は、スマートコントラクトを通じて信頼のない検証を行うために、実行層上のコンセンサス層状態証明を有効にします。以前の PR #3175 は EIP へのフォーマット化の過程にあり、EIP-6987 に変更されました。これは、安全上の理由から、罰金（slashed）された検証ノードがブロック提案者として選ばれるのを防ぐためです。開発者は、Deneb 規格に追加の変数と定数を導入し、実行層がコンセンサス層から独立して各ブロックの最大 blob トランザクション数を調整できるようにすることを議論しました。イーサリアムコア開発者の Tim Beiko は、EIP-4844 に導入された新しい SSZ タイプが、今後の SSZ アップグレードとどの程度互換性があるか、または現在の RLP 標準に最適化されるべきかはまだ不明であると、コンセンサス層クライアントチームに警告しました。Ryan は、現在 EIP-4844 で使用されている「flat hash」の SSZ タイプは、RLP 形式化の利点を活かしていないため、両方の面で損をしていると述べました。開発者は、来週の ACDE 電話会議でこの問題について引き続き議論します。さらに、信標チェーン証明サブネット（attnet）の改造は 5 月 4 日にリリースされました。開発者は、信標チェーン API の GitHub リポジトリで PR #317 についても議論しました。最近の MEV-Boost 脆弱性攻撃を考慮して、中継は現在、gossip を通じてブロック内容をブロードキャストする前に検証を行います。この機能は、Lighthouse と Prysm クライアントのカスタムフォークを必要とします。Lighthouse クライアント開発者の Michael Sproul は、すべてのコンセンサス層クライアントで同じ機能を有効にするための標準クエリパラメータを提案しました。Prysm クライアント開発者の Terence Tsao は、ある面でこの機能を導入することは MEV-Boost への依存を増加させると述べました。MEV-Boost はイーサリアム上で MEV を獲得するための一時的なソフトウェアであり、PBS をサポートするために廃止すべきです。(出典リンク)