이더리움 핵심 개발자 최신 회의 요약: Pectra 업그레이드가 두 개의 하드 포크로 나뉠 가능성

저자: Christine Kim

편집: Luccy, BlockBeats

편집자 주: 이더리움의 모든 핵심 개발자 합의 전화(ACDC)는 2주마다 열리며, 주로 이더리움 합의 레이어(CL)의 변경 사항에 대해 논의하고 조정합니다. 이번 회의는 ACDC 제 134차 전화 회의로, 개발자들은 EIP 7549, EIP 7251, EIP 6110, EIP 7688 등 여러 주요 EIP의 구현 세부 사항과 기술적 도전에 대해 논의했습니다.

또한, 개발자들은 PeerDAS의 구현에 대해서도 심도 있게 논의했으며, 이 데이터 가용성 샘플링 기술은 이더리움 네트워크가 롤업 및 그 데이터 가용성 요구를 지원하는 능력을 크게 향상시킬 것으로 예상됩니다. 회의 중 Pectra를 두 개의 하드 포크로 나누어 업그레이드하자는 제안이 제기되었고, 다양한 EIP의 활성화 시간과 상호 의존성 문제에 대해 논의했습니다.

Galaxy Digital 연구 부사장 Christine Kim은 이번 회의의 주요 내용을 자세히 기록하였으며, BlockBeats는 원문을 다음과 같이 편집하였습니다:

2024년 5월 30일, 이더리움 개발자들은 Zoom에서 All Core Developers Consensus (ACDC) call #134 회의에 참석했습니다. ACDC 전화 회의는 2주마다 열리는 일련의 회의로, 이더리움 재단 연구원 Alex Stokes가 주재하며, 개발자들은 이더리움 합의 레이어(CL, 신호 체인이라고도 함)의 변경 사항에 대해 논의하고 조정합니다. 이번 주, 개발자들은 Pectra Devnet 0 시작 이후의 경험과 해결되지 않은 문제에 대해 논의했습니다. 그들은 또한 Pectra 업그레이드의 범위를 PeerDAS 및 SSZ 컨테이너 코드 변경을 포함하도록 확대하는 가능성에 대해 논의했습니다.

Devnet 0 회고

Pectra가 Devnet 0에서 시작된 상황에 따라, 클라이언트 팀은 하드 포크 활성화 기간 동안 EIP 7549의 영향에 대한 검증 행동을 변경하지 않기로 합의했습니다. 이전 ACDC 회의에서 개발자들은 하드 포크 기간 동안 EIP 7549의 영향이 대량의 무효 검증을 초래하지 않도록 보장하기 위해 여러 가지 방안을 고려했습니다. 업그레이드를 더욱 복잡하게 만들지 않기 위해, 클라이언트 팀은 다른 Pectra EIP와 동일한 시대에 EIP 7549를 활성화하고, 하드 포크 전후로 검증 행동을 변경하지 않기로 결정했습니다.

EIP 7251에 관해서는, 개발자들은 실행 레이어(EL)에서 스테이킹 ETH의 병합을 트리거하는 것을 허용해야 하는지에 대해 여전히 확신이 없었습니다. 이는 Lido와 같은 스테이킹 풀에 이상적인 기능으로, 스테이킹 병합이 노드 운영자에 의존하지 않고 스마트 계약을 통해 이루어질 수 있습니다. Stokes는 몇 주 후 클라이언트 구현에서 검증자 스테이킹 병합의 진행 상황을 점검한 후, 그것들이 EL 작업인지 CL 작업인지 결정할 것을 제안했습니다.

그 후, 개발자들은 EIP 6110에 따른 검증자 예치금 최종 확인에 대한 몇 가지 미해결 문제를 논의했습니다. Teku 개발자 Mikhail Kalinin은 회의 전 GitHub 댓글에서 이러한 문제의 해결 방향을 요약했습니다. Lighthouse 개발자 "sean"은 Engine API의 "GetPayloadBodies" 요청에 대한 버전 관리 문제를 제기했습니다. Stokes는 개발자들이 GitHub에서 이 문제에 대해 작성된 pull request에 의견을 남기도록 제안했습니다.

EIP 7549 변경 사항

Nimbus 개발자 Etan Kissling은 EIP 7549의 구현에 대해 작은 변경을 제안했습니다. "이는 일반화 인덱스의 안정성 문제에 관한 것입니다. 우리가 컨테이너 중간에 새 필드를 추가할 때, 후속 필드는 새로운 인덱스를 할당받게 되어 EIP 4788에 기반한 실행 레이어(EL)의 증명을 깨뜨리고, 다소 오해의 소지가 있습니다. … 따라서, 이 두 가지 문제를 피하기 위해 새 필드를 끝으로 이동할 것을 제안합니다."라고 Kissling은 설명했습니다. 이 변경에 대해 반대 의견은 없었습니다. Stokes는 개발자들이 GitHub에서 Kissling이 제안한 pull request를 확인할 것을 제안했습니다.

EIP 7549에 대한 또 다른 변경 사항은 회의 중에 제안된 것으로, 요청 및 EL에서 트리거된 기타 요청을 EL 블록의 추가 프로그램으로 설계하는 것입니다. 이 변경에 대해 Kalinin은 "제 생각에는, 이는 매우 훌륭한 설계안으로, EL을 단순화합니다… 그리고 이는 기본적으로 실행 레이어 블록에서 일반화 요청에 대한 대안입니다."라고 말했습니다. Stokes는 다음 CL 회의에서 이 주제를 다시 논의할 것을 제안하여 개발자들이 GitHub에서 이 제안을 검토할 수 있는 더 많은 시간을 가질 수 있도록 했습니다.

Pectra 범위 논의

합의 레이어(CL)에 초점을 맞춘 몇 가지 EIP는 Pectra 업그레이드에서 공식적으로 포함되거나 제외되지 않았습니다. 이번 주 회의에서 개발자들은 Pectra에 EIP 7688 및 PeerDAS를 포함할지에 대해 논의했습니다. EIP 7688은 "StableContainer" SSZ 데이터 구조의 일부를 채택하여 EIP 7549의 증명 변경이 향후 호환성을 갖추도록 합니다. 배경 설명으로, SSZ는 CL에서 사용되는 데이터 구조로, 개발자들은 실행 레이어(EL)에서도 이를 사용하기를 희망하고 있습니다. SSZ 전환에 대한 더 많은 정보는 이전 회의 기록을 참조하십시오. PeerDAS는 이더리움에서 데이터 가용성 샘플링의 구현으로, 네트워크가 롤업 및 그 데이터 가용성 요구를 지원하는 능력을 크게 향상시킬 것으로 예상됩니다. 실제로, PeerDAS는 검증자가 블록에 첨부할 수 있는 blob 거래 수를 각 블록당 3개에서 64개 이상으로 증가시킬 것으로 예상됩니다.

이더리움 재단 개발자 운영 엔지니어 Barnabas Busa는 개발자들이 개발 네트워크에서 PeerDAS의 초기 반복 버전을 시작했다고 밝혔습니다. "많은 클라이언트가 많은 문제를 발견했으며, 우리가 실질적인 진전을 이루었을 때 언제든지 새로운 개발 네트워크를 재시작할 수 있습니다."라고 Busa는 말했습니다. Stokes는 개발자들에게 업그레이드 지연을 초래할 수 있는 경우 PeerDAS를 Pectra에 추가할 의향이 있는지를 물었습니다.

별명 "Nishant"인 개발자는 PeerDAS 활성화를 Pectra의 다른 EIP 활성화와 분리하자는 제안을 다시 했습니다. 이는 가능하지만, 별명 "atd"인 다른 개발자는 개발자들이 이러한 업그레이드를 짧은 시간 내에 순차적으로 활성화할 계획이라면 사용자들이 소프트웨어를 동시에 업그레이드해야 한다고 강조했습니다. atd는 "저는 두 달 후에 또 다른 업그레이드를 하면서 포크하는 것은 다소 미친 짓이라고 생각합니다. 모든 사람이 클라이언트를 업그레이드하도록 조정해야 한다면, 두 달 후에 다시 모든 사람이 클라이언트를 업그레이드하도록 하고 싶지 않습니다. 그렇게 되면, 심지어 하나의 릴리스 주기도 부족합니다."라고 말했습니다.

atd는 PeerDAS가 Pectra에 포함되고 논의된 EIP 중 가장 "흥미로운" 코드 변경이라고 덧붙였습니다. Stokes는 업그레이드 지연을 초래하더라도 PeerDAS를 Pectra에 포함시키기를 원한다고 밝혔습니다. Grandine 클라이언트 개발자 Saulius Grigaitis는 PeerDAS를 지원하기 위해 Pectra에서 EIP 7549와 EIP 7688을 제거하자는 제안을 했습니다. 이는 EIP 7688 구현 세부 사항에 대한 논의를 촉발했습니다. 개발자들은 코드 변경에 대해 합의에 도달하지 못했으며, 다음 ACDC 회의에서 이 제안을 다시 논의할 예정입니다.

PeerDAS에 대한 주제에서 개발자들은 Pectra를 두 개의 하드 포크로 나누는 아이디어를 계속해서 저울질했습니다. 이더리움 재단 개발자 옵션 엔지니어 Parithosh Jayanthi는 개발자들이 Pectra를 두 개의 업그레이드로 나누면, 향후 Pectra 두 번째 부분에 더 많은 EIP를 추가하지 않도록 주의해야 한다고 경고했습니다. Jayanthi는 "제가 언급하고 싶은 것은, 만약 우리가 두 개의 포크로 나누는 것을 고려한다면, 다음 포크에서 더 많은 새로운 EIP를 추가하지 않도록 매우 조심해야 한다는 것입니다. 우리가 이를 할 수 있을지 모르겠습니다. 만약 우리가 1년 또는 1년 반 전에 어떤 것을 약속할 수 있다면, 우리는 항상 새로운 아이디어를 제안하고 우선순위가 변하고 있습니다."라고 말했습니다.

두 개의 업그레이드에 대한 논의를 계속하면서, Lighthouse 개발자 "sean"은 PeerDAS와 현재 Pectra EIP 목록 간에 많은 상호 의존성이 없다고 예상했습니다. 따라서 이 두 가지는 별도로 진행될 수 있으며, 개발자들이 이들의 구현에 대해 더 자신감을 가질 때 쉽게 통합될 수 있습니다. Atd는 이 의견에 동의하며, 이러한 내용을 별도로 개발하고 테스트한 후 Pectra EIP, PeerDAS 및 EIP 7688을 통합하는 데 큰 위험이 없을 것이라고 생각했습니다.

Busa는 Pectra EIP와 PeerDAS를 계속 테스트하되, 코드 변경을 PeerDAS가 개발 네트워크와 테스트 네트워크에서 Pectra EIP보다 한 epoch 늦게 활성화되도록 설계할 것을 제안했습니다. 그는 이것이 이미 Devnet 0에서 Pectra EIP와 PeerDAS 테스트를 수행하는 방식이라고 지적했습니다. Busa는 "실제로 변경할 필요는 없습니다."라고 말하며, PeerDAS가 다른 Pectra EIP가 준비될 때까지 준비되지 않은 경우, 개발자들이 해당 코드 변경을 업그레이드에서 제거할 수 있다고 덧붙였습니다. 이는 PeerDAS의 서로 다른 활성화 epoch가 클라이언트 팀의 작업에 어떻게 영향을 미치는지에 대한 여러 질문을 불러일으켰습니다. 결국, 개발자들은 PeerDAS 및 Pectra EIP를 계속 개발하기로 합의했지만, 전제 조건은 PeerDAS가 개발 네트워크와 테스트 네트워크에서 서로 다른 epoch에 활성화되는 것이었습니다.

앞서 언급한 바와 같이, 개발자들은 EIP 7688이 Pectra에 포함될지 여부에 대한 논의를 다음 ACDC 전화 회의로 미루기로 합의했습니다.