이더리움 핵심 개발자 최신 회의 요약: PeerDAS 활성화, blob 가스 제한 증가

원제목：《Ethereum All Core Developers Consensus Call #135 Writeup》

저자：Christine Kim

편집：Luccy，BlockBeats

편집자 주：이더리움 모든 핵심 개발자 합의 전화(ACDC)는 2주마다 열리며, 주로 이더리움 합의 레이어(CL)의 변경 사항에 대해 논의하고 조정합니다. 이번은 ACDC 제 135차 전화 회의로, 이번 회의는 Pectra Devnet 1, PeerDAS Devnet 1 및 Simple Serialize (SSZ) 이더리움 개선 제안(EIPs)의 테스트 네트워크 준비에 주로 집중했습니다.

개발자들은 소프트웨어 패키지 유지 관리, EIP 포함 프로세스 및 새로운 이더리움 합의 레이어 업그레이드 명명 등 여러 주제에 대해 심도 있는 논의를 진행했습니다. 또한 회의에서는 Electra 규격 하의 구현 진행 상황, PeerDAS 네트워크 변경이 이더리움 노드의 데이터 처리 및 검증에 미치는 영향, 그리고 blob gas 제한 증가에 대한 복잡한 엔지니어링 문제에 대해서도 논의되었습니다.

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

2024년 6월 13일, 이더리움 개발자들은 Zoom에서 All Core Developers Consensus (ACDC) Call #135 회의에 참석했습니다. ACDC 전화 회의는 2주마다 열리는 시리즈 회의로, 이더리움 재단 연구원 Alex Stokes가 주재하며, 개발자들은 이더리움 합의 레이어(CL, 즉 신호 체인)의 변경 사항에 대해 논의하고 조정합니다. 이번 주, 개발자들은 Pectra Devnet 1, PeerDAS Devnet 1 및 Simple Serialize(SSZ) 이더리움 개선 제안(EIPs)을 위한 제3의 전용 테스트 네트워크 준비 작업에 대해 논의했습니다.

공지사항

개발자들은 두 개의 공지로 회의를 시작했습니다. 이더리움 재단 개발 운영(DevOps) 엔지니어 Parithosh Jayanthi는 이더리움 재단 개발 운영(EF DevOps)에서 일하는 엔지니어 팀인 ethPandaOps 팀이 ethereum-package Kurtosis 모듈의 유지 관리 및 개발을 인수할 것이라고 발표했습니다. 이 소프트웨어 패키지는 과거에 개발자들이 이더리움 테스트 네트워크 및 다양한 클라이언트 구현을 모니터링하고 테스트하기 위한 Grafana 데이터 대시보드와 같은 관련 도구를 시작하는 데 사용되었습니다. Kurtosis 기술 팀에서 ethPandaOps 팀으로의 이관 과정에서 일부 링크가 Kurtosis 팀이 아닌 ethPandaOps 팀이 관리하는 GitHub 저장소로 리디렉션될 수 있으므로 사용자에게 영향을 미칠 수 있습니다. Jayanthi는 사용자에게 소프트웨어 링크를 업데이트하고 ethPandaOps 팀이 발표하는 새로운 버전을 주의 깊게 살펴볼 것을 권장했습니다.

두 번째 공지는 이더리움 재단 프로토콜 지원 책임자 Tim Beiko가 발표했습니다. Beiko는 EIPs를 이더리움 업그레이드에 단계적으로 포함시키기 위한 새로운 프로세스를 도입하기 위해 노력하고 있다고 밝혔습니다. 그는 "Proposed for Inclusion"(포함 제안), "Considered for Inclusion"(포함 고려) 및 "Scheduled for Inclusion"(포함 예정)이라는 레이블을 정의하는 초안 EIP를 작성했습니다. 그는 개발자들이 해당 문서를 검토하고 피드백을 제공하기를 희망하며, 다음 ACD 회의 전에 이 문서를 완료하기를 원합니다.

Electra

다음 Electra 주요 버전 v1.5.0-alpha.3의 코드 규격이 곧 완료될 예정입니다. 개발자들은 합의 규격 GitHub 저장소의 풀 리퀘스트(PR) #3768을 다음 버전에 병합하기로 합의했습니다. 이 풀 리퀘스트는 Nimbus 개발자 Etan Kissling이 작성했으며, "committee_bits" 필드가 데이터의 중간이 아닌 "Attestation"의 끝에 추가되어야 한다고 지적했습니다. PR #3768 외에도 Stokes는 다음 Electra 규격 주요 버전 출시 전에 해결해야 할 다른 미결 문제가 있는지 질문했습니다. Jayanthi는 Zoom 채팅에서 실행 레이어(EL)에서 트리거된 검증기 통합에 몇 가지 미결 문제가 있다고 언급했습니다. Stokes는 회의 후 EL에서 트리거된 검증기 통합 상태를 추적하기로 기록했습니다.

최신 Electra 규격의 구현 진행 상황에 대해 회의에 참석한 대부분의 합의 레이어(CL) 클라이언트 팀은 v1.5.0-alpha.3이 최종 확정된 후 1~2주 내에 새로운 버전을 테스트할 준비가 될 것이라고 밝혔습니다. 개발자들은 몇 주 후에 다음 Pectra 개발 네트워크 Pectra Devnet 1의 일정에 대해 다시 논의하기로 합의했습니다.

PeerDAS

다음으로 개발자들은 PeerDAS의 구현 진행 상황에 대해 논의했습니다. PeerDAS는 이더리움의 네트워크 개선으로, 노드가 blob 거래를 통해 제출된 대량의 임의 데이터를 처리하고 검증하는 능력을 강화합니다. Stokes는 지난 ACDC 회의에서 개발자들이 다른 Pectra EIPs와 동시에 PeerDAS를 병행 개발하기로 결정했음을 회고하며, 개발 네트워크에서 PeerDAS의 별도의 활성화 주기를 통해 이를 실현할 것이라고 밝혔습니다.

Lodestar 개발자 Gajinder Singh은 최근 PeerDAS에 대한 그룹 회의 논의에 따라 개발자들이 Deneb 업그레이드를 기반으로 하여 다른 Pectra EIPs와 분리된 개발 네트워크에서 PeerDAS를 활성화할 것이라고 밝혔습니다. Teku 개발자 Enrico Del Fante는 개발자들이 이전 이더리움 업그레이드 Deneb에서 이미 확인된 안정적인 코드 규격 위에 PeerDAS를 구축하는 것이 변화하는 Pectra 코드 규격 위에 구축하는 것보다 더 쉽다고 언급했습니다. Jayanthi는 현재 PeerDAS 구현을 다른 Pectra EIP 구현과 통합하면 테스트 과정에서 복잡한 문제가 발생할 수 있다고 동의하며, 특히 오류 원인을 찾으려 할 때 더욱 그러하다고 말했습니다. 그는 두 작업 흐름을 분리한 후 두 구현이 더 안정화된 후에 다시 통합할 것을 제안했습니다. Stokes는 이에 동의하며, 개발자들이 약 한 달 후에 PeerDAS와 다른 Pectra EIP 구현의 통합 문제를 다시 논의할 수 있다고 말했습니다.

PeerDAS Devnet 1의 시작에 대한 주제에 대해 클라이언트 팀은 테스트 네트워크 시작 준비가 언제 완료될 것인지에 대한 명확한 추정치를 제시하지 않았습니다. 회의에 참석한 개인의 추정치는 대략 2주에서 1개월 사이였습니다. Stokes는 몇 주 후에 클라이언트 팀이 PeerDAS 구현을 위한 더 많은 시간을 가질 때 개발 네트워크의 일정에 대해 다시 논의할 것을 제안했습니다.

그런 다음 Beiko는 PeerDAS가 이더리움 핵심 프로토콜의 변화가 아닌 네트워크 개선이지만, 여전히 Pectra 업그레이드의 메타 EIP에 코드 변경 사항을 포함시키기를 원한다고 언급했습니다. 메타 EIP 문서는 이더리움 업그레이드에 포함된 모든 핵심 프로토콜 변경 사항을 나열하는 공개 문서입니다. Beiko는 PeerDAS가 Pectra에서 "가장 큰 기능"이라고 언급하며, 하드 포크 활성화가 필요하지 않지만, 개발자들이 Pectra 메인넷 활성화 시 이를 적시에 준비할 수 있도록 문서에 포함되어야 한다고 강조했습니다. 이에 대한 이의는 없었습니다.

blob gas 제한 증가

PeerDAS는 노드가 이더리움 피어 네트워크 레이어를 통해 데이터를 처리하고 전파하는 방식을 변경합니다. 사용자, 특히 Layer-2 롤업이 이러한 변화의 혜택을 보려면 개발자들이 현재 블록당 6개의 blobs 제한을 더 높은 임계값으로 높여야 하며, 이는 더 높은 blob(임의 데이터) 처리량을 허용할 것입니다. blob 제한 변경은 이더리움 핵심 프로토콜에 대한 변경이 필요하며, 이는 개발자들이 이번 주 회의에서 논의한 바와 같이 단순히 프로토콜 기술 스택의 상수 값을 조정하는 것보다 더 복잡한 엔지니어링 작업이 될 수 있습니다.

Stokes는 blob gas 제한을 변경할 때 실행 레이어(EL)와 합의 레이어(CL) 간의 의존성을 분리할 것을 제안했습니다. 현재 blob gas 제한에 대한 모든 변경은 EL과 CL 프로토콜의 변경을 필요로 합니다. Stokes는 이러한 의존성을 끊어 개발자들이 EL에서 하드코딩된 blob gas 제한을 안전하게 제거하고 완전히 CL에 의해 결정되도록 할 수 있는 몇 가지 방법을 제안했습니다. 이더리움 재단(EF) 연구원 Dankrad Feist는 EL과 CL 간의 의존성 문제 외에도 blob gas 제한 변경이 블록의 gas 계산에 미치는 연쇄 반응도 중요하다고 지적했습니다. Feist는 "가장 좋은 방법은 계산 방식을 변경하는 것입니다. gas 가격 계산이 EL에서 발생하는 것은 잘못일 수 있습니다. 그것은 CL에서 발생해야 하지만, 지금 변경하기는 더 어렵습니다. … 이것은 쉽지 않습니다."라고 말했습니다.

개발자들은 blob gas 제한 및 블록 내 gas 계산 변경의 최선의 방법을 계속 조사하기로 합의했습니다. 개발자들은 또한 Pectra에서 PeerDAS를 활성화할 때 blob gas 제한이 증가할 것인지에 대한 논의를 계속하기로 합의했습니다. 개발자들은 이러한 변경 사항이 함께 결합되어야 하는지 아니면 여러 하드 포크로 단계적으로 구현되어야 하는지에 대해 의견이 분분했습니다.

Jayanthi는 이러한 변경 사항을 결합하는 것이 "위험한" 결정이라고 언급하며, 개발자들이 PeerDAS가 메인넷에서 활성화되기 전에 그 구체적인 기능 성능을 알 수 없기 때문이라고 설명했습니다. 이더리움 재단(EF) DevOps 엔지니어 Barnabas Busa는 Pectra 하드 포크의 범위가 이미 매우 크기 때문에 추가적인 코드 변경을 더할 필요가 없다고 덧붙였습니다. Busa는 "핵심은 우리가 이미 많은 EIP를 가지고 있다는 것입니다. 우리는 계속해서 더 많은 내용을 추가하고 있으며, 이는 끝이 없을 것입니다. 따라서 우리는 어딘가에서 선을 그어야 하며, 그것이 우리의 종착점입니다. 저는 향후 1년 반의 테스트 기간 동안 PeerDAS를 출시하고 blob 수를 늘리는 것은 불가능하다고 생각합니다."라고 말했습니다.

"Francesco"라는 스크린 이름을 가진 개발자는 네트워크 변화가 blob 수의 증가를 동반하지 않는다면 PeerDAS를 제거하여 "Pectra의 위험을 줄일 수 있다"고 제안했습니다. Francesco는 "blob 수가 증가하지 않는다면 Pectra의 PeerDAS는 도대체 어떤 이점이 있는가?"라고 질문했습니다.

PeerDAS 테스트의 어려움을 더 설명하기 위해 Jayanthi는 blobs를 이더리움에 도입하는 EIP 4844의 테스트가 blobs가 이더리움 메인넷에서 실제로 어떻게 작동하고 영향을 미치는지를 완전히 시뮬레이션하지 못했다고 지적했습니다. Jayanthi는 "문제는 테스트 네트워크가 매우 어렵다는 것입니다. 우리는 실제로 4844와 관련된 많은 훌륭한 테스트를 수행했지만, blobs가 메인넷에서 작동하는 방식은 테스트에서의 작동 방식과 완전히 일치하지 않습니다. 우리는 실제로 약한 노드에서 문제가 발생하는 것을 보았습니다. 우리는 시간상의 도전과 같은 유사한 상황을 보았으며, 이는 우리가 개발 네트워크에서 PeerDAS와 blob 수 증가가 정상적으로 작동하는 완벽한 상황을 시뮬레이션할 수 있더라도, 이는 메인넷에 대해 실제로는 아무런 의미가 없다는 이유이기도 합니다. 그래서 저는 우리가 한 번에 모든 것을 완료하기보다는 단계적으로 진행해야 한다고 생각합니다."라고 말했습니다.

EF 연구원 Ansgar Dietrichs는 blob 수 증가와 PeerDAS를 연관짓는 것은 잘못된 것이라고 언급하며, 단순히 PeerDAS만으로도 개발자들이 blob 수 값을 선택해야 한다고 강조했습니다. 개발자들이 이더리움 메인넷과 동일한 숫자를 선택할 수 있지만, PeerDAS가 사용해야 할 숫자에 대한 결정은 반드시 내려져야 합니다. 동일한 숫자를 선택하는 유일한 이유는 개발자들이 PeerDAS의 복잡성을 증가시켜 오류가 발생할 경우 현재 Deneb 규격의 blob 전파 메커니즘으로 되돌릴 수 있도록 하기 위함입니다. Dietrichs는 테스트 복잡성에 대한 우려가 그가 Pectra가 두 개의 하드 포크로 활성화되어야 한다고 생각하는 주장을 더욱 강화한다고 덧붙였지만, 이는 그가 PeerDAS가 blob 수 변경과 분리되어야 한다고 생각한다는 것을 의미하지는 않았습니다.

SSZ 업데이트

Kissling은 SSZ와 관련된 세 개의 EIP의 진행 상황 업데이트를 공유했습니다. 그는 이러한 EIP의 구현 작업이 Teku, Grandine 및 Lighthouse를 포함한 여러 클라이언트에서 진행되고 있다고 언급했습니다. 그는 개발자들이 이러한 SSZ EIP의 개발 네트워크 일정에 대해 논의하기 시작할 수 있으며, 다음 ACDC 회의에서 이를 Pectra 업그레이드의 범위에 포함시킬 수 있을 것이라고 말했습니다.

F-Star 명명

Ethereum Magicians에 게시된 글에서는 Electra 이후의 다음 이더리움 합의 레이어(CL) 업그레이드 이름에 대해 논의했습니다. 개발자들은 Prague 이후의 실행 레이어(EL) 업그레이드 이름을 오사카(Osaka)로 결정했습니다. 후보 CL 업그레이드 이름으로는 Fulu, Felis, Formosa 및 Funi가 있습니다. 이러한 이름은 Beacon Chain의 여섯 번째 전체 네트워크 업그레이드에 적용되는 "F"로 시작하는 주요 별 명명 관례를 따릅니다. Stokes는 통화 중 개발자들에게 Magicians 게시물에 대해 이 주제에 대한 의견을 남기도록 요청했습니다.