최근 이더리움 핵심 개발자 회의 요약: Pectra 업그레이드 출시, PeerDAS 구현 진행 토론

원제: "Ethereum All Core Developers Consensus Call #138 Writeup"
작성자: Christine Kim
편집자: Ladyfinger, BlockBeats

편집자 주:
Ether All Core Developers Consensus Call(ACDC)은 Ethereum Consensus Layer(CL)에 대한 변경 사항을 논의하고 조정하기 위해 2주마다 개최됩니다. 이번 컨퍼런스 콜은 138회 ACDC 컨퍼런스 콜로, Pectra Devnet 1 출시, 비콘 블록 본체 및 엔진 API 구조 변경, Pectra에 안정적인 컨테이너 EIP(Ethereum Improvement Proposals) 포함, 즉 EIP 7688 및 EIP 7495를 다룹니다. PeerDAS 업데이트 및 기타 주제. 회의 동안 개발자들은 Pectra 업그레이드 준비 상태를 검토하고 PeerDAS 구현에 관한 몇 가지 공개 질문과 제안에 대해 논의했습니다. 또한 Nimbus 개발자 Etan Kissling은 EIP 7688 및 EIP 7495의 구현 작업 진행 상황을 공유하면서 이더리움 데이터 직렬화 방법을 업그레이드하기 위한 이러한 제안의 중요성을 강조했습니다. 갤럭시디지털의 크리스틴 김 연구부사장은 이번 회의의 핵심 내용을 자세히 기록했고, BlockBeats는 원문을 다음과 같이 정리했습니다.

2024년 7월 25일, 이더리움 개발자들은 제138차 All-Core Developer Consensus(ACDC)를 개최했습니다. ) Zoom을 통해 )회의. ACDC 컨퍼런스는 개발자들이 비콘 체인이라고도 알려진 Ethereum Consensus Layer(CL)에 대한 변경 사항을 논의하고 조정하는 격주 일련의 회의입니다. 이번 주 세션은 이더리움 재단(EF) 연구원 Alex Stokes가 주최했습니다. 개발자들은 다음 사항에 대해 논의했습니다.

·Pectra Devnet 1 출시

·비콘 블록 본체 및 엔진 API 구조 변경

·EIP 7688 및 EIP 7495로 알려진 Pectra에 안정적인 컨테이너 Ethereum 개선 제안(EIP) 통합

· PeerDAS 업데이트 및 메인넷 구현 일정

Pectra Devnet 1 Pectra

Devnet 1이 7월 23일 화요일에 출시되었습니다. 그러나 네트워크가 안정적이지 않습니다. Ethereum Foundation의 DevOps 엔지니어인 Parithosh Jayanthi는 Devnet이 출시된 직후 Erigon 클라이언트에 문제가 발생했다고 말했습니다. 그런 다음 devnet에서 브로드캐스트된 EIP 7702 트랜잭션으로 인해 네트워크가 세 가지 상태로 분할되었습니다. 개발자는 클라이언트를 디버깅하고 체인 분할 문제를 해결하고 있습니다.

ExecutionPayloadEnvelope 소개

Prysm 개발자 Potuz는 비콘 체인 블록 실행 로드 구조에 대한 주요 개선 사항과 그에 따른 엔진 API 조정을 제안했습니다. 이 제안은 CL(Consensus Layer) 클라이언트가 상태 전환 데이터를 저장하고 처리하는 프로세스를 단순화하는 것을 목표로 합니다. Pectra 업그레이드 구현을 통해 CL 클라이언트는 상태 전환을 올바르게 수행하기 위해 실행 로드의 특정 부분에 액세스해야 합니다. 그러나 기존 설계로 인해 이러한 클라이언트는 실행 로드에서 중요하지 않은 일부 정보를 무시하게 됩니다.

Pectra 업그레이드를 위해서는 CL 클라이언트가 EL(실행 계층)에서 필요한 상태 전환 데이터를 요청하거나 블록의 중요한 부분을 로컬에 저장해야 합니다. Pectra 업그레이드 후 CL 클라이언트의 효율성을 높이기 위해 Potuz는 실행 상태 전환에 필요한 주요 정보를 중앙에 저장하는 "bind_execution_payload_envelope"라는 새로운 구조를 도입할 것을 제안했습니다. 이러한 개선으로 인해 상태 전환 계산 시 CL 클라이언트의 속도와 효율성이 크게 향상됩니다. 그는 또한 이러한 조정을 통해 SSZ(Simple Serialization) 형식과 같은 향후 네트워크 업그레이드와의 호환성이 보장될 것이라고 강조했습니다.

Lighthouse 프로젝트 개발자인 Mark Mackey는 이러한 변경 사항이 구현되지 않으면 Pectra 테스트넷에서 CL 클라이언트의 성능에 영향을 미칠 수 있다고 경고했습니다. Teku 프로젝트의 개발자인 Mikhail Kalinin은 Pectra에서 EIP 구현의 복잡성을 해결하기 위해 프로토콜 변경이 실제로 필요한지 의문을 제기하면서 주의를 표명했습니다. Potuz는 기존 프로토콜 설계에 근본적인 문제가 있으며 수정이 필요하다고 주장합니다. 그는 "현재 설계는 개념적으로 결함이 있다. CL 상태 전환에 중요한 데이터와 전혀 관련 없는 데이터를 같은 수준, 같은 메시지에 섞어 놓은 것"이라며 "따라서 현재 설계가 잘못됐다고 생각하고, 열심히 노력하고 있다"고 지적했다.

Stokes는 개발자가 GitHub에서 이 제안에 대해 계속 논의할 것을 권장합니다.

Devnet 2용 엔진 API 업데이트

위 논의와 관련하여 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 변경 사항을 자세히 살펴볼 것을 권장합니다.

Pectra의 EIP 7688 및 7495

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 업데이트

개발자들은 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의 향후 단계에 대해 계속 논의할 것을 제안했습니다.

BeaconBlocksByRange V3 추가

Lighthouse 프로젝트 "Dapplion"의 개발자는 장기적인 체인 분할 시 클라이언트가 메인 체인과 보다 효과적으로 동기화할 수 있도록 개선 계획을 제안했습니다. 그는 기존 [BeaconBlocksByRange V2] RPC 프로토콜에는 특정 제한 사항이 있음을 지적했습니다. "롱 포크된 블록을 동기화해야 하고 어느 지점이 메인 체인인지 확실하지 않은 경우 현재 프로토콜에 따라 A만 제출하면 됩니다. 슬롯 범위에 따라 노드는 정확하다고 생각되는 블록을 반환합니다. 상태 메시지를 통해 이 정보를 쿼리할 수 있지만, 이 프로세스는 비동기식이며 현재 메인넷에 심각한 포크 상황은 없지만 일부 문제가 발생할 수 있습니다. 앞으로도 유사한 사건이 발생한다면 이는 해결해야 할 문제가 될 것입니다."

Dapplion은 자신이 제안한 솔루션이 비교적 간단하며 향후 Pectra 업그레이드에 포함될 수도 있다고 추가로 설명했습니다. 이러한 개선이 임박하지는 않았지만 Stokes는 참석한 개발자들이 제안을 주의 깊게 검토하고 GitHub에서 자신의 생각과 제안을 공유하도록 권장했습니다.

위 내용은 최근 이더리움 핵심 개발자 회의 요약: Pectra 업그레이드 출시, PeerDAS 구현 진행 토론의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!