이더리움 핵심 개발자 최신 회의 요약: Pectra 업그레이드 시작, PeerDAS 구현 진행 논의

원문 제목：《Ethereum All Core Developers Consensus Call #138 Writeup》
저자：Christine Kim
편집：Ladyfinger，BlockBeats

편집자 주：
이더리움 모든 핵심 개발자 합의 전화(ACDC)는 2주마다 열리며, 주로 이더리움 합의 레이어(CL)의 변경 사항에 대해 논의하고 조정합니다. 이번은 ACDC 제 138차 전화 회의로, Pectra Devnet 1의 시작, 신호 블록체인 및 엔진 API 구조의 변경, 안정적인 컨테이너 이더리움 개선 제안(EIPs)인 EIP 7688 및 EIP 7495를 Pectra에 포함시키는 것, PeerDAS의 업데이트 등 여러 주제를 다루었습니다. 회의 중 개발자들은 Pectra 업그레이드 준비 상황을 검토하고 PeerDAS 구현에 대한 몇 가지 미해결 문제와 제안에 대해 논의했습니다. 또한 Nimbus 개발자 Etan Kissling은 EIP 7688 및 EIP 7495의 구현 작업 진행 상황을 공유하며, 이러한 제안이 이더리움 데이터 직렬화 방법 업그레이드에 중요한 의미가 있음을 강조했습니다. Galaxy Digital 연구 부사장 Christine Kim은 이번 회의의 요점을 상세히 기록하였으며, BlockBeats는 원문을 다음과 같이 편집하였습니다:

2024년 7월 25일, 이더리움 개발자들은 Zoom을 통해 제 138차 전 핵심 개발자 합의(ACDC) 회의를 개최했습니다. ACDC 회의는 2주마다 열리는 회의 시리즈로, 개발자들은 이 회의에서 이더리움 합의 레이어(CL), 즉 신호 체인의 변경 사항에 대해 논의하고 조정합니다. 이번 주 회의는 이더리움 재단(EF) 연구원 Alex Stokes가 주재했습니다. 개발자들은 다음 내용을 논의했습니다:

· Pectra Devnet 1의 시작

· 신호 블록체인 및 엔진 API 구조의 변경

· 안정적인 컨테이너 이더리움 개선 제안(EIPs)을 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 클라이언트는 상태 전환을 올바르게 수행하기 위해 실행 페이로드의 특정 부분에 접근해야 합니다. 그러나 기존 설계로 인해 이러한 클라이언트는 실행 페이로드 내의 일부 불필요한 정보를 무시하게 됩니다.

Pectra 업그레이드는 CL 클라이언트가 실행 레이어(EL)에서 필요한 상태 전환 데이터를 요청하거나 로컬에 블록의 핵심 부분을 저장하도록 요구합니다. Pectra 업그레이드 이후 CL 클라이언트의 효율성을 높이기 위해 Potuz는 실행 상태 전환에 필요한 핵심 정보를 집중 저장하는 "bindedexecutionpayload_envelope"라는 새로운 구조의 도입을 제안했습니다. 이러한 개선은 CL 클라이언트가 상태 전환을 계산할 때 속도와 효율성을 크게 향상시킬 것입니다. 그는 또한 이러한 조정이 간단한 직렬화(SSZ) 형식과 같은 미래의 네트워크 업그레이드와의 호환성을 보장할 것이라고 강조했습니다.

Lighthouse 프로젝트의 개발자 Mark Mackey는 이러한 변경이 시행되지 않으면 Pectra 테스트넷에서 CL 클라이언트의 성능이 영향을 받을 수 있다고 경고했습니다. Teku 프로젝트의 개발자 Mikhail Kalinin은 이에 대해 신중한 입장을 보이며, Pectra에서 EIPs 구현의 복잡성을 해결하기 위해 프로토콜을 변경할 필요가 있는지 의문을 제기했습니다. Potuz는 기존 프로토콜 설계에 근본적인 문제가 있다고 주장하며 수정이 필요하다고 강조했습니다. 그는 "현재의 설계는 개념적으로 결함이 있으며, CL 상태 전환에 필수적인 데이터와 완전히 무관한 데이터를 동일한 수준, 동일한 메시지에서 혼합하고 있습니다. 따라서 현재의 설계는 잘못되었으며, 우리는 이 오류를 수정하기 위해 노력하고 있습니다."라고 말했습니다.

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

Devnet 2의 엔진 API 업데이트

위의 논의와 관련하여 Geth 개발자 "Lightclient"는 엔진 API에 대한 또 다른 변경을 제안했습니다. 이 변경은 EL 클라이언트가 블록 변환을 보다 쉽게 수행할 수 있도록 하는 것을 목표로 합니다. EL 클라이언트는 블록 내의 빈 필드와 빈 필드를 해석하여 블록 버전을 결정합니다. 그러나 프라하의 EIP 7685에 따라 분기 일정이 없으면 EL 클라이언트는 이러한 필드를 기반으로 블록 버전을 구분할 수 없습니다. 과거 업그레이드의 일정 참조에 대한 오버헤드를 피하기 위해 Lightclient는 모든 요청을 엔진 API 내의 단일 유형으로 통합할 것을 제안했습니다. EL은 이를 CL에 전달하여 해석할 수 있습니다.

Lightclient는 블록의 해석이 EL과 CL 간에 다르며, 이 경우 CL이 요청 데이터를 표현하는 데 더 적합하다고 지적했습니다. "우리가 블록 자체를 처리할 때 블록은 '이것은 벨라트릭스 블록이다'라는 개념이 없습니다. CL에서와 마찬가지로요. 여러분이 다양한 유형의 분기 블록을 구분하는 데 잘하고 있다고 생각합니다. 그러나 EL에서는 거의 모든 클라이언트 구현이 이 방식으로 진행되고 있으며, 우리는 모든 블록 유형을 대표하는 블록이 있으며, 존재하는 값의 빈 값을 사용하여 그 [분기]가 활성화되어 있는지를 결정합니다."

Nimbus 개발자 "Dustin"은 이 제안에 반대하며 Lightclient의 제안이 EL과 CL에서 블록 해석의 복잡성을 충분히 해결하지 못했다고 말했습니다. "이것은 복잡성과 혼란을 EL에서 CL로 전이하는 것일 뿐이며, 두 곳 모두에서 실행 가능합니다. CL로 이동한다고 해서 문제가 해결되는 것은 아닙니다. … 단지 문제를 이동시킨 것일 뿐입니다."라고 Dustin은 말했습니다.

Stokes는 CL이 요청의 해석을 처리하는 데 더 적합하다고 주장하며, 개발자들이 Potuz와 Lightclient가 GitHub에서 제안한 엔진 API 변경 사항을 더 면밀히 살펴보도록 권장했습니다.

Pectra의 EIP 7688 및 7495

Nimbus 개발자 Etan Kissling은 이더리움 직렬화 방법을 SSZ로 업데이트하기 위해 노력하고 있습니다. Pectra의 목적을 위해 그는 스마트 계약 개발자가 의존할 수 있는 데이터 구조를 도입하기 위해 두 개의 중간 EIP인 7688과 7495를 확인했습니다. 이는 미래의 SSZ 관련 변경과 호환됩니다. Kissling은 Rocketpool과 같은 유동성 스테이킹 풀 및 Teku와 Lodestar와 같은 다른 클라이언트 팀의 지원을 받았다고 언급했습니다.

Stokes는 CL 클라이언트 팀에게 Pectra에 새로운 EIP를 추가하지 말 것을 경고했습니다. "Pectra는 이미 매우 큽니다. 특히 우리가 결국 분기에서 PeerDAS를 갖게 된다면요. 언젠가는 우리는 분기의 크기와 그것이 가져오는 위험을 매우 현실적으로 바라봐야 합니다. 다시 말하지만, Etan이 제시한 이 기능이 진공 상태에서 가치가 있다는 이유에 동의하지만, 이는 우리가 수행한 가장 큰 하드 포크 중 하나이거나 가장 큰 것 중 하나이며, 가볍게 여겨져서는 안 됩니다."라고 그는 말했습니다.

개발자들은 이러한 EIP가 Pectra devnet에 실제로 추가될 수 있는 시기에 대해 우려를 표명했습니다. Pectra devnet는 PeerDAS 및 EOF와 같은 많은 EIP를 아직 포함하지 않았습니다. 이에 대해 Jayanthi는 개발자들이 업그레이드에 이러한 EIP를 포함해야 하는지 명확히 결정할 것을 제안했습니다. Jayanthi는 또한 CL과 EL EIP가 함께 하나의 devnet에서 테스트될 때 병목 현상이 발생할 수 있다고 경고했습니다. 그는 Zoom 채팅에서 "10개의 직접적인 EIP를 함께 배포하면 조합에서 포크를 테스트하는 것이 매우 복잡해질 것입니다. 그리고 우리는 단지 직접적인 EIP만 있는 것이 아닙니다."라고 썼습니다.

Mackey는 EigenLayer 팀과 같은 애플리케이션 개발자들이 Pectra에서 계획된 활성화 내용을 파악하려고 노력하고 있으며, 이 두 EIP의 지속적인 불확실성이 그들의 작업에 장애가 되고 있다고 공유했습니다. Lighthouse 개발자 Sean Anderson은 이더리움의 애플리케이션 개발자들로부터 이러한 EIP에 대한 의견을 더 많이 수집하여 그것들이 애플리케이션에 얼마나 중요한지를 파악할 것을 제안했습니다.

Stokes는 개발자들이 Pectra Devnet 1의 문제를 해결하는 데 집중할 수 있도록 이 논의를 나중에 다시 방문할 것을 제안했습니다.

PeerDAS 업데이트

개발자들은 PeerDAS의 최신 진행 상황에 대해 심도 있는 논의를 진행했습니다. Anderson은 합의 레이어(CL) 클라이언트 팀이 이전 PeerDAS devnet에서 발견된 문제를 적극적으로 수정하고 있으며, 새로운 devnet을 시작하기 전에 구현의 안정성을 보장하고 있다고 보고했습니다. Lodestar와 EthereumJS의 개발자 Gajinder Singh은 최근 PeerDAS 구현자 회의의 피드백에 따라 커뮤니티가 다음 Pectra devnet에 PeerDAS를 통합할 의향이 있다고 전했습니다.

Stokes는 이더리움 재단(EF) 연구팀 및 다른 개발자들과의 논의에 따라, 메인넷에서 PeerDAS를 초기 활성화할 때 샘플링 기능을 생략해야 할 수도 있다고 제안했습니다. 이는 구현의 복잡성을 줄이기 위한 것입니다. 그는 "현재 PeerDAS의 Pectra 내 규격은 이 세 가지 작업을 포함하고 있습니다. 제 직감은 샘플링 기능이 구현 과정에서 가장 큰 복잡한 점일 수 있다는 것입니다. 만약 샘플링이 정말로 극복하기 어려운 도전을 가져온다면, 우리는 Pectra에서 blob의 수를 늘리고 PeerDAS의 범위를 줄이거나 조정하는 것을 고려할 수 있습니다."라고 Stokes는 설명했습니다.

Stokes는 이 아이디어에 대한 공식 제안을 작성하고 개발자 커뮤니티와 더 논의하겠다고 약속했습니다. Singh은 이에 대해 지지 의사를 표명했습니다. Stokes는 또한 Pectra 업그레이드에 PeerDAS를 공식적으로 포함시킬 것을 제안했습니다. 이에 대해 Jayanthi는 이것이 Pectra 규격의 기초 위에서 PeerDAS 규격을 재정의해야 한다는 것을 의미하는지 질문하며, PeerDAS와 Pectra devnets를 통합하는 것이 두 가지 모두 불안정하기 때문에 디버깅 작업을 복잡하게 만들 수 있다고 지적했습니다. 그는 규격이 안정되기 전까지 두 작업 흐름의 독립성을 유지해야 한다고 제안했습니다. Teku의 개발자 Enrico Del Fante도 Jayanthi의 의견에 동의했습니다.

Stokes는 PeerDAS 구현에 집중하는 많은 개발자들이 이번 회의에 참석하지 못했다고 언급했습니다. 그는 다음 PeerDAS 구현자 회의에서 PeerDAS의 향후 단계에 대해 계속 논의할 것을 제안했습니다.

BeaconBlocksByRange V3 추가

Lighthouse 프로젝트의 개발자 "Dapplion"은 클라이언트가 장기간 체인 분할이 발생할 경우 더 효과적으로 메인 체인과 동기화할 수 있도록 돕기 위한 개선안을 제안했습니다. 그는 기존의 [BeaconBlocksByRange V2] RPC 프로토콜이 일정한 한계를 가지고 있다고 지적했습니다. "긴 분기의 블록을 동기화해야 할 때, 어떤 분기가 메인 체인인지 확실하지 않을 경우, 현재 프로토콜에 따라 슬롯 범위를 제출하면 노드는 자신이 올바르다고 생각하는 블록을 반환합니다. 상태 메시지를 통해 이러한 정보를 조회할 수 있지만, 이 과정에는 비동기성이 존재하여 몇 가지 문제를 일으킬 수 있습니다. 현재 메인넷에서 심각한 분기 상황이 발생하지 않았지만, 미래에 유사한 사건이 발생할 경우 이는 해결해야 할 문제입니다."

Dapplion은 그가 제안한 해결책이 상대적으로 간단하며, 심지어 다가오는 Pectra 업그레이드에 포함될 가능성이 있다고 설명했습니다. 이러한 개선이 시급한 것은 아니지만, Stokes는 참석한 개발자들이 이 제안을 면밀히 검토하고 GitHub에서 그들의 의견과 제안을 공유할 것을 권장했습니다.