原題: "Ethereum All Core Developers Consensus Call #138 Writeup"
著者: Christine Kim
編集者: Ladyfinger、BlockBeats
編集者注:
イーサ All Core Developers Consensus Call (ACDC) は、イーサリアム コンセンサス レイヤー (CL) に対する変更について話し合い、調整するために 2 週間ごとに開催されます。これは 138 回目の ACDC カンファレンスコールであり、Pectra Devnet 1 の立ち上げ、ビーコンブロック本体とエンジン API 構造の変更、Pectra への安定したコンテナー Ethereum Improvement Proposals (EIP)、つまり EIP 7688 と EIP 7495 の組み込みについて取り上げます。 PeerDAS のアップデートやその他のトピック。会議中、開発者は Pectra アップグレードの準備状況を確認し、PeerDAS 実装に関するいくつかの未解決の質問と提案について話し合いました。さらに、Nimbus開発者のEtan Kissling氏もEIP 7688とEIP 7495の実装作業の進捗状況を共有し、イーサリアムのデータシリアル化方式をアップグレードするためのこれらの提案の重要性を強調しました。 Galaxy Digital のリサーチ担当副社長である Christine Kim は、この会議の要点を詳細に記録し、BlockBeats はその原文を次のようにまとめました:
2024 年 7 月 25 日、イーサリアム開発者は第 138 回オールコア開発者コンセンサス (ACDC) を開催しました。 )Zoom経由)ミーティング。 ACDC カンファレンスは、開発者がビーコン チェーンとしても知られるイーサリアム コンセンサス レイヤー (CL) に対する変更について話し合い、調整する隔週の一連の会議です。今週のセッションは、イーサリアム財団（EF）の研究者アレックス・ストークス氏が主催しました。開発者は以下について議論しました:
・Pectra Devnet 1の起動
・ビーコンブロック本体とエンジンAPI構造の変更
・EIP 7688およびEIP 7495として知られる安定コンテナEthereum改善提案(EIP)のPectraへの組み込み
· PeerDAS の更新とメインネットでの実装スケジュール
Devnet 1 は、7 月 23 日火曜日に公開されました。ただし、ネットワークが不安定です。イーサリアム財団のDevOpsエンジニアであるパリソシュ・ジャヤンティ氏は、開発ネットの立ち上げ直後にエリゴンのクライアントが問題に遭遇したと語った。その後、devnet 上で EIP 7702 トランザクション ブロードキャストが発生し、ネットワークが 3 つの状態に分割されました。開発者はクライアントをデバッグし、チェーン分割の問題を解決しています。
Prysm 開発者 Potuz は、ビーコン チェーン ブロックの実行負荷構造の大幅な改善と、それに対応するエンジン API の調整を提案しました。この提案は、コンセンサス層 (CL) クライアントによる状態遷移データの保存と処理のプロセスを簡素化することを目的としています。 Pectra アップグレードの実装により、CL クライアントは状態遷移を正しく実行するために実行負荷の特定の部分にアクセスする必要があります。ただし、既存の設計では、これらのクライアントは実行負荷内の一部の重要でない情報を無視します。
Pectra のアップグレードでは、CL クライアントが必要な状態遷移データを実行層 (EL) にリクエストするか、ブロックの重要な部分をローカルに保存する必要があります。 Pectraのアップグレード後のCLクライアントの効率を改善するために、Potuz氏は、実行状態の遷移に必要な重要な情報を集中的に保存する「bind_execution_payload_envelope」と呼ばれる新しい構造を導入することを提案した。このような改善により、CL クライアントの状態遷移の計算速度と効率が大幅に向上します。また、これらの調整により、Simple Serialization (SSZ) フォーマットなどの将来のネットワーク アップグレードとの互換性が確保されることも強調しました。
Lighthouse 프로젝트 개발자인 Mark Mackey는 이러한 변경 사항이 구현되지 않으면 Pectra 테스트넷에서 CL 클라이언트의 성능에 영향을 미칠 수 있다고 경고했습니다. Teku 프로젝트의 개발자인 Mikhail Kalinin은 Pectra에서 EIP 구현의 복잡성을 해결하기 위해 프로토콜 변경이 실제로 필요한지 의문을 제기하면서 주의를 표명했습니다. Potuz는 기존 프로토콜 설계에 근본적인 문제가 있으며 수정이 필요하다고 주장합니다. 그는 "현재 설계는 개념적으로 결함이 있다. CL 상태 전환에 중요한 데이터와 전혀 관련 없는 데이터를 같은 수준, 같은 메시지에 섞어 놓은 것"이라며 "따라서 현재 설계가 잘못됐다고 생각하고, 열심히 노력하고 있다"고 지적했다.
Stokes는 개발자가 GitHub에서 이 제안에 대해 계속 논의할 것을 권장합니다.
위 논의와 관련하여 Geth 개발자 "Lightclient"는 엔진 API에 대한 또 다른 변경 사항을 제안했습니다. 이 변경은 EL 클라이언트의 블록 변환을 더 쉽게 하기 위한 것입니다. EL 클라이언트는 블록의 null 및 void 필드를 해석하여 블록 버전을 결정합니다. 그러나 프라하의 EIP 7685로 인해 포크 일정이 없으면 EL 클라이언트는 이러한 필드를 기반으로 블록 버전을 구별할 수 없습니다. 과거 업그레이드 일정을 참조하는 오버헤드를 피하기 위해 Lightclient는 모든 요청을 엔진 API의 단일 유형으로 통합하여 EL이 해석을 위해 CL에 전달할 수 있도록 제안합니다.
Lightclient는 EL과 CL 간에 청크 해석이 다르며 이 경우 CL이 요청 데이터를 표현하는 데 더 적합하다는 점을 지적합니다. "블록 자체를 다룰 때는 씨엘처럼 '이건 벨라트릭스 블록이다'라는 개념이 없어요. 포크된 블록의 종류를 잘 구분한 것 같아요. 그런데 온엘에서는, 이것이 거의 모든 클라이언트가 구현되는 방법이라고 생각합니다. 우리는 모든 블록 유형을 나타내는 블록을 가지고 있으며, 예를 들어 null 값의 존재를 사용하여 해당 [포크]가 활성화되어 있는지 확인합니다."
Nimbus 개발자 "Dustin "는 Lightclient의 제안이 EL 및 CL에 대한 블록 해석의 복잡성을 완전히 다루지 못했다며 이 제안에 반대했습니다. "EL에서 CL로 복잡성과 혼란을 옮길 뿐이며 두 위치 모두 실행 가능합니다. CL로 옮긴다고 해서 문제가 해결되는 것은 아닙니다. ... 단지 문제가 옮겨질 뿐입니다."라고 Dustin은 말했습니다.
Stokes는 CL이 요청 해석을 처리하는 데 더 적합하다고 주장하며 개발자가 GitHub의 Potuz 및 Lightclient가 제안한 엔진 API 변경 사항을 자세히 살펴볼 것을 권장합니다.
Nimbus 개발자 Etan Kissling은 SSZ에 대한 Ethereum 직렬화 방법 업데이트를 추진해 왔습니다. Pectra의 목적을 위해 그는 스마트 계약 개발자가 향후 SSZ 관련 변경 사항과 호환되기 위해 신뢰할 수 있는 데이터 구조를 도입하기 위해 두 개의 중간 EIP인 7688과 7495를 식별했습니다. Kissling은 이미 Rocketpool과 같은 유동 스테이킹 풀은 물론 Teku 및 Lodestar와 같은 다른 클라이언트 팀의 지원을 받고 있다고 언급했습니다.
Stokes는 CL 클라이언트 팀에게 Pectra에 새로운 EIP를 추가하지 말라고 경고합니다. "Pectra는 이미 매우 큽니다. 특히 PeerDAS가 포크에 포함된다면 더욱 그렇습니다. 어느 시점에서 우리는 포크의 크기와 그것이 초래하는 위험에 대해 매우 현실적이어야 합니다. 다시 한번 말하지만, 저는 Etan의 의견에 동의합니다. 여기에는 이유가 있습니다. 이 기능은 공백 상태에서 가치가 있지만 나는 이것이 우리가 해본 것 중 가장 큰 하드포크 중 하나이거나 가장 큰 것이며 가볍게 여겨서는 안 된다고 생각합니다."라고 그는 말했습니다.
Pectra devnet은 아직 PeerDAS 및 EOF와 같은 많은 EIP를 통합하지 않았기 때문에 개발자들은 이러한 EIP가 실제로 Pectra devnet에 추가될 수 있는 시기에 대해 몇 가지 우려를 제기했습니다. 이와 관련하여 Jayanthi는 먼저 개발자가 이러한 EIP를 업그레이드에 포함해야 하는지 명확하게 결정할 것을 권장합니다. Jayanthi는 또한 devnet에서 CL과 EL EIP를 함께 테스트할 때 병목 현상이 발생한다고 경고했습니다. 그는 Zoom 채팅에서 다음과 같이 썼습니다. "10개의 직접 EIP를 함께 배송하면 조합하여 포크하고 테스트하는 것이 매우 복잡해집니다. 그리고 우리는 직접 EIP만 가지고 있는 것이 아닙니다."
Mackey는 애플리케이션 개발자로 구성된 EigenLayer 팀처럼 이를 공유했습니다. Pectra에서 활성화할 계획이 무엇인지 파악하기 위해 노력하고 있으며, 이 두 EIP에 대한 지속적인 명확성이 부족하여 노력에 장애가 되고 있습니다. Lighthouse 개발자 Sean Anderson은 이러한 EIP가 애플리케이션에 얼마나 중요한지 판단하기 위해 Ethereum의 애플리케이션 개발자로부터 더 많은 의견을 얻을 것을 권장합니다.
Stokes는 개발자가 Pectra Devnet 1 문제를 해결하는 데 집중할 수 있도록 나중에 이 논의를 다시 논의할 것을 제안합니다.
개발자들은 PeerDAS의 최신 진행 상황에 대해 심도 있는 토론을 했습니다. Anderson은 CL(Consensus Layer) 클라이언트 팀이 PeerDAS 개발넷의 이전 라운드에서 발견된 문제를 적극적으로 수정하고 새로운 개발넷을 출시하기 전에 구현의 안정성을 보장하고 있다고 보고합니다. Lodestar와 EthereumJS 개발자 Gajinder Singh은 최근 PeerDAS 구현자 회의의 피드백을 기반으로 커뮤니티가 다음 Pectra devnet에 PeerDAS를 통합하는 데 관심이 있다고 말했습니다.
Stokes는 이더리움 재단(EF) 연구팀 및 기타 개발자와의 논의를 바탕으로 구현의 복잡성을 줄이기 위해 메인 네트워크에서 PeerDAS를 처음 활성화할 때 샘플링 기능을 생략해야 할 수도 있다고 제안했습니다. 그는 PeerDAS의 완전한 구현에는 배포, 샘플링 및 재구성이라는 세 가지 주요 기능이 포함된다고 설명했습니다. "현재 Pectra의 PeerDAS 사양은 이 세 가지 작업을 다루고 있습니다. 직관에 따르면 샘플링 기능이 아마도 구현에서 가장 복잡한 부분일 것입니다. 샘플링이 극복할 수 없는 문제를 야기한다면 Pectra에서 구현하는 것을 고려할 수 있습니다. PeerDAS의 범위를 줄이거나 조정하면서 얼룩을 제거할 수 있습니다."라고 Stokes는 설명했습니다.
Stokes는 아이디어에 대한 공식적인 제안을 개발하고 개발자 커뮤니티와 함께 더 자세히 탐구하겠다고 약속했습니다. 싱은 이를 지지한다. Stokes는 또한 PeerDAS가 Pectra 업그레이드에 공식적으로 포함될 것을 권장했습니다. 이에 대한 응답으로 Jayanthi는 이것이 Pectra 사양을 기반으로 PeerDAS 사양을 재정의하는 것을 의미하는지 물었고 PeerDAS와 Pectra devnet을 병합하면 둘 다 불안정하기 때문에 디버깅 노력이 복잡해질 수 있다는 점을 지적했습니다. 그는 사양이 안정될 때까지 두 워크플로의 독립성을 유지해야 한다고 제안했습니다. Teku 개발자 Enrico Del Fante는 Jayanthi의 의견에 동의합니다.
Stokes는 PeerDAS 구현에 초점을 맞춘 많은 개발자가 회의에 참석할 수 없었다고 언급했습니다. 그는 다음 PeerDAS 구현자 회의에서 PeerDAS의 향후 단계에 대해 계속 논의할 것을 제안했습니다.
Lighthouse 프로젝트 "Dapplion"의 개발자는 장기적인 체인 분할 시 클라이언트가 메인 체인과 보다 효과적으로 동기화할 수 있도록 개선 계획을 제안했습니다. 그는 기존 [BeaconBlocksByRange V2] RPC 프로토콜에는 특정 제한 사항이 있음을 지적했습니다. "롱 포크된 블록을 동기화해야 하고 어느 지점이 메인 체인인지 확실하지 않은 경우 현재 프로토콜에 따라 A만 제출하면 됩니다. 슬롯 범위에 따라 노드는 정확하다고 생각되는 블록을 반환합니다. 상태 메시지를 통해 이 정보를 쿼리할 수 있지만, 이 프로세스는 비동기식이며 현재 메인넷에 심각한 포크 상황은 없지만 일부 문제가 발생할 수 있습니다. 앞으로도 유사한 사건이 발생한다면 이는 해결해야 할 문제가 될 것입니다."
Dapplion은 자신이 제안한 솔루션이 비교적 간단하며 향후 Pectra 업그레이드에 포함될 수도 있다고 추가로 설명했습니다. 이러한 개선이 임박하지는 않았지만 Stokes는 참석한 개발자들이 제안을 주의 깊게 검토하고 GitHub에서 자신의 생각과 제안을 공유하도록 권장했습니다.
以上がイーサリアムコア開発者の最新ミーティングの概要: Pectra アップグレードの開始、PeerDAS 実装の進捗状況についてのディスカッションの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
