原文標題：《Ethereum All Core Developers Consensus Call #138 Writeup》
作者：Christine Kim 編按：
以太坊所有核心開發者共識電話（ACDC）每兩週舉行一次，主要討論並協調以太坊共識層（CL）的變更。本次為ACDC 第138 次電話會議，本次會議涵蓋了Pectra Devnet 1 的啟動、信標區塊體和引擎API 結構的變更、將穩定容器以太坊改進提案（EIPs）納入Pectra，即EIP 7688 和EIP 7495 以及PeerDAS 的更新等多個議題。會議期間，開發者們審議了 Pectra 升級的準備情況，並探討了關於 PeerDAS 實現的一些未解問題和提案。此外，Nimbus 開發者 Etan Kissling 也分享了 EIP 7688 和 EIP 7495 的實施工作進展，強調了這些提案對以太坊資料序列化方法升級的重要性。 Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeats 將原文編譯如下：2024 年7 月25 日，以太坊開發者透過Zoom 舉行了第138 次全核心開發者共識（ ACDC ）會議。 ACDC 會議是每兩週舉行一次的會議系列，開發者在這些會議上討論並協調以太坊共識層（ CL ），也稱為信標鏈的變更。本週的會議由以太坊基金會（ EF ）研究員 Alex Stokes 主持。開發者們討論了以下內容：
· Pectra Devnet 1 的啟動
· 信標區塊體和引擎API 結構的變更
· 將穩定容器以太坊改進提案（ EIP s ）納入Pectra ，即EIP 7688和EIP 7495
· PeerDAS 的更新及其在主網上的實施時間表
Pectra Devnet 1 Pectra
Devnet 1 於7 月23 日星期二上線。然而，網路並不穩定。以太坊基金會開發維運工程師 Parithosh Jayanthi 表示， Erigon 用戶端在 devnet 啟動後不久就遇到了問題。接著，一個在 devnet 上廣播的 EIP 7702 交易導致網路分裂成三個狀態。開發者正在調試客戶端並解決鏈分裂問題。
引入 ExecutionPayloadEnvelope
Prysm 開發者 Potuz 提出了對信標鏈區塊執行負載結構的重大改進，以及對引擎 API 的相應調整。這項提議旨在簡化共識層（ CL ）客戶端儲存和處理狀態轉換資料的過程。隨著 Pectra 升級的實施， CL 用戶端需要存取執行負載的特定部分來正確執行狀態轉換。然而，現有設計導致這些客戶端忽略了執行負載中的一些非必要資訊。
Lighthouse プロジェクトの開発者である Mark Mackey は、これらの変更が実装されない場合、Pectra テストネット上の CL クライアントのパフォーマンスに影響が出る可能性があると警告しました。 Teku プロジェクトの開発者である Mikhail Kalinin 氏は、Pectra での EIP 実装の複雑さに対処するためにプロトコルの変更が本当に必要なのかどうか疑問を呈し、慎重な姿勢を示しました。ポトゥズ氏は、既存のプロトコル設計には根本的な問題があり、修正する必要があると主張している。同氏は、「現在の設計は概念的に欠陥がある。CLの状態遷移にとって重要なデータと全く無関係なデータが同じレベル、同じメッセージ内に混在している。したがって、現在の設計は間違っていると思う。我々は懸命に取り組んでいる」と指摘した。このエラーを修正するには。」
Stokes は開発者に対し、GitHub でこの提案について議論し続けることを奨励しています。
上記の議論に関連して、Geth 開発者の「Lightclient」はエンジン API への別の変更を提案しました。この変更は、EL クライアントにとってブロック変換を容易にすることを目的としています。 EL クライアントは、ブロック内の null フィールドと void フィールドを解釈することによってブロックのバージョンを決定します。ただし、プラハの EIP 7685 により、フォーク スケジュールがなければ、EL クライアントはこれらのフィールドに基づいてブロック バージョンを区別できません。過去のアップグレードのスケジュールを参照するオーバーヘッドを回避するために、Lightclient は、すべてのリクエストをエンジン API の単一タイプに統合し、EL が解釈のために CL に渡すことを提案します。
Lightclient は、チャンクの解釈が EL と CL で異なること、そしてこの場合 CL がリクエスト データを表すのに適していることを指摘しています。 「ブロック自体を扱っているときは、CLのような『これはベラトリックスブロックだ』という概念はありません。皆さんは、さまざまなタイプのフォークブロックをうまく区別したと思います。しかし、On ELでは、これが、ほぼすべてのクライアントの実装方法だと思います。すべてのブロック タイプを表すブロックがあり、たとえば null 値の存在を使用して、[フォーク] がアクティブかどうかを判断します。」
Nimbus 開発者 "Dustin 」は、Lightclient の提案が EL と CL のブロック解釈の複雑さに十分に対処していないと述べて、この提案に反対しました。 「複雑さと混乱をELからCLに移すだけで、どちらの場所も実行可能だ。CLに移しても問題は解決しない。…問題が移るだけだ」とダスティン氏は語った。
Stokes 氏は、リクエストの解釈を処理するには CL の方が適していると主張し、開発者には GitHub で Potuz と Lightclient によって提案されたエンジン API の変更を詳しく調べることを推奨しています。
Nimbus 開発者 Etan Kissling は、イーサリアムシリアル化メソッドの SSZ へのアップデートを推進しています。 Pectra の目的として、同氏は、スマート コントラクト開発者が将来の SSZ 関連の変更と互換性を保つために信頼できるデータ構造を導入するために、2 つの中間 EIP 7688 と 7495 を特定しました。 Kissling 氏は、Rocketpool のような流動的なステーキングプールだけでなく、Teku や Lodestar などの他のクライアントチームからもすでにサポートを受けていると述べました。
Stokes は CL クライアント チームに Pectra に新しい EIP を追加しないよう警告しています。 「Pectra はすでに非常に大きくなっており、特にフォークに PeerDAS を導入することになった場合にはなおさらです。ある時点で、フォークのサイズとそれがもたらすリスクについて非常に現実的になる必要があります。繰り返しになりますが、私は Etan の意見に同意します。これには理由があります。」この機能は単体でも価値があるものですが、これは私たちがこれまでに行ったハードフォークの 1 つ、または最大のものであり、軽視すべきではないと思います」と彼は言いました。
Pectra devnet にはまだ PeerDAS や EOF などの多くの EIP が組み込まれていないため、開発者はこれらの EIP が実際に Pectra devnet にいつ追加できるかについていくつかの懸念を表明しています。この点に関して、Jayanthi 氏は、まず開発者がこれらの EIP をアップグレードに含めるべきかどうかを明確に決定することをお勧めします。 Jayanthi 氏は、開発ネット上で CL と EL EIP を一緒にテストするときにボトルネックがあるとも警告しました。彼は Zoom チャットで次のように書いています。「10 個の直接 EIP を一緒に出荷すると、フォークして組み合わせてテストするのが非常に複雑になります。そして、私たちは直接 EIP だけを持っているわけではありません
Mackey は、アプリケーション開発者の EligenLayer チームと同じように試みていることを共有しました。」 Pectra で何がアクティブ化される予定であるかを把握することは困難ですが、これら 2 つの EIP が引き続き明確でないことが、その取り組みの障害となっています。 Lighthouse の開発者である Sean Anderson 氏は、Ethereum 上のアプリケーション開発者からこれらの EIP についてさらに多くの情報を得て、それらがアプリケーションにとってどれほど重要かを判断することを推奨しています。
Stokes は、開発者が Pectra Devnet 1 の問題の解決に集中できるように、後日この議論を再検討することを提案しています。
開発者は、PeerDAS の最新の進歩について徹底的なディスカッションを行いました。 Anderson 氏は、コンセンサス レイヤー (CL) クライアント チームが、PeerDAS の Devnet の前回のラウンドで発見された問題を積極的に修正し、新しい Devnet を立ち上げる前に実装の安定性を確保していると報告しています。 Lodestar と EthereumJS の開発者 Gajinder Singh 氏は、最近の PeerDAS 実装者会議からのフィードバックに基づいて、コミュニティは次の Pectra devnet に PeerDAS を統合することに関心を持っていると述べました。
Stokes 氏は、イーサリアム財団 (EF) 研究チームや他の開発者との議論に基づいて、実装の複雑さを軽減するために、最初にメイン ネットワーク上で PeerDAS をアクティブ化するときにサンプリング機能を省略する必要があるかもしれないと提案しました。同氏は、PeerDAS の完全な実装には、配布、サンプリング、再構成という 3 つの重要な機能が含まれると説明しました。 「現在、Pectra の PeerDAS 仕様はこれら 3 つのタスクをカバーしています。私の直観によると、おそらくサンプリング機能が実装における最大の複雑さのポイントです。サンプリングが克服できない課題を引き起こす場合は、Pectra で実装することを検討できます。数値を増やすPeerDAS の範囲を縮小または調整しながら、BLOB の数を減らすことができます」と Stokes 氏は説明しました。
Stokes は、このアイデアに関する正式な提案を作成し、開発者コミュニティとさらに検討すると約束しました。シン氏もこれを支持している。ストークス氏はまた、PeerDAS を Pectra のアップグレードに正式に含めるよう推奨しました。これに対して Jayanthi 氏は、これは Pectra 仕様に基づいて PeerDAS 仕様を再定義することを意味するのかどうかを尋ね、PeerDAS と Pectra devnet をマージすると、両方とも不安定であるためデバッグ作業が複雑になる可能性があると指摘しました。同氏は、仕様が安定するまで 2 つのワークフローの独立性を維持する必要があると提案しました。 Teku 開発者の Enrico Del Fante 氏も Jayanthi 氏の意見に同意します。
Stokes 氏は、PeerDAS の実装に注力していた多くの開発者が会議に参加できなかったと指摘しました。同氏は、次回の PeerDAS 実装者会議で、PeerDAS の将来のステップについて引き続き議論することを提案しました。
Lighthouse プロジェクト「Dapplion」の開発者は、長期的なチェーン分割が発生した場合にクライアントがより効果的にメインチェーンに同期できるようにする改善計画を提案しました。同氏は、既存の [BeaconBlocksByRange V2] RPC プロトコルには特定の制限があると指摘しました。「長くフォークされたブロックを同期する必要があり、どのブランチがメイン チェーンであるかわからない場合、現在のプロトコルによれば、A を送信するだけで済みます。スロット範囲に応じて、ノードはステータス メッセージを通じてこの情報を照会できますが、このプロセスは非同期であるため、現時点ではメインネットに重大なフォーク状況が発生していない場合に問題が発生する可能性があります。同様の事件が将来発生する場合、これは解決する必要がある問題になるでしょう。」
Dapplion はさらに、彼が提案した解決策は比較的単純で、今後の Pectra のアップグレードに含まれる可能性もあると説明しました。これらの改善は差し迫ったものではありませんが、Stokes 氏は出席した開発者に対し、提案を注意深く検討し、GitHub で意見や提案を共有することを奨励しました。
以上是以太坊核心開發者最新會議摘要：Pectra 升級啟動、PeerDAS 實現進展探討的詳細內容。更多資訊請關注PHP中文網其他相關文章！
