이더리움 핵심 개발자 최신 회의 요약: Pectra 수정 및 준비, PeerDAS 진행 상황

원문 제목：《Ethereum All Core Developers Consensus Call #139 Writeup

저자： Christine Kim

편집： Ladyfinger ， BlockBeats

편집자 주：

이더리움 모든 핵심 개발자 합의 전화(ACDC)는 2주마다 열리는 일련의 회의로, 이더리움 합의 계층(CL), 즉 신호 체인의 변경 사항을 논의하고 조정하는 데 중점을 둡니다. 제139회 ACDC 전화 회의는 이더리움 재단(EF) 연구원 Alex Stokes가 주재하였으며, 회의 내용은 Pectra Devnet 2의 수정, Devnet 3 준비, PeerDAS 구현 진행 상황 및 이더리움 노드 분포에 대한 새로운 데이터 등을 포함했습니다.

회의 중 개발자들은 Pectra Devnet 2의 안정성과 존재하는 문제를 검토하고, 다가오는 Devnet 3의 준비 작업에 대해 논의했으며, PeerDAS의 구현 진행 상황에 대해 심도 있는 논의를 진행했습니다. 또한 EIP 7688 제안도 참석자들 간의 광범위한 논의를 불러일으켰으며, 이 제안은 이더리움 데이터 직렬화 방법의 잠재적 변경을 지원하기 위해 앞으로 호환 가능한 데이터 구조를 도입하는 것을 목표로 하고 있습니다. Galaxy Digital 연구 부사장 Christine Kim은 이번 회의를 상세히 기록하였으며, BlockBeats는 원문을 다음과 같이 편집하였습니다:

2024년 8월 8일, 이더리움 개발자들은 Zoom을 통해 제139회 핵심 개발자 합의 전화 회의(ACDC)를 개최했습니다. ACDC 전화 회의는 2주마다 열리는 일련의 회의로, 개발자들은 이곳에서 이더리움 합의 계층(CL), 즉 신호 체인의 변경 사항을 논의하고 조정합니다. 이번 주 전화 회의는 이더리움 재단(EF) 연구원 Alex Stokes가 주재하였습니다. 개발자들은 Pectra Devnet 2의 수정, Devnet 3 준비, PeerDAS 구현 진행 상황 및 이더리움 노드 분포에 대한 새로운 데이터에 대해 논의했습니다.

Pectra 업데이트

Stokes는 EF의 연구원 Hsiao Wei Wang이 Pectra 합의 계층(CL) 규격의 공식 업데이트 버전 alpha .4를 곧 출시할 예정이라고 발표했습니다. 이 버전은 이전 버전에 대한 여러 개선 사항을 포함하고 있으며, 가까운 시일 내에 발표될 예정입니다.

Pectra Devnet 2에 대한 주제에 대해 EF 개발자 운영 엔지니어 Barnabas Busa는 네트워크가 안정적이며 85%의 네트워크 참여도를 달성했다고 밝혔습니다. 실행 계층(EL) 클라이언트에는 해결해야 할 몇 가지 작은 문제가 있으며, 주로 EthereumJS와 Erigon과 관련이 있습니다. 대부분의 CL 클라이언트는 Devnet 2에서 안정적입니다. 그러나 Busa는 Prysm 클라이언트에 대해 추가 조사가 필요한 작은 문제를 언급했습니다. EF DevOps 엔지니어 Parithosh Jayanthi는 Lighthouse, Teku 및 Besu 노드 간의 문제에 대해 클라이언트 팀의 조사가 필요하다고 덧붙였습니다.

이후 개발자들은 devnet 시작의 커뮤니케이션 프로세스를 개선하는 방법에 대해 논의했습니다. Prysm의 개발자 Kasey Kirkham은 Zoom 채팅에서 Devnet 2 시작 시간에 대한 자신의 무지함을 지적했습니다. Devnet 3의 시작 정보가 모든 클라이언트 팀에 정확하게 전달될 수 있도록 개발자들은 Pectra의 테스트 진행 상황을 업데이트하기 위한 정기적인 주간 회의를 설정하기로 결정했습니다. 구체적인 시간은 아직 정해지지 않았지만, 이러한 회의는 매주 월요일에 열릴 것으로 예상되며, Dencun 업그레이드 전의 테스트 전화 회의와 유사할 것입니다. Jayanthi는 이러한 회의가 짧고 효율적이며, 15분에서 30분 사이로 제한되어 Pectra 관련 devnet 테스트 업데이트를 논의하고 PeerDAS 및 EOF devnet 등의 주제를 포함할 것이라고 제안했습니다.

Pectra Devnet 3에 대한 논의 중 개발자들은 Devnet 2와 일치하는 EIP 구성을 계속 사용할 것이라고 재확인했습니다. 또한 Devnet 3는 최신 설계의 EIP 7702를 처음으로 통합할 것이며, 팀은 Pectra 핵심 EIP와의 호환성을 보장하기 위해 이를 세밀하게 테스트할 것입니다. Lodestar 팀의 Gajinder Singh은 Devnet 2에서 발견된 EIP 7251, 즉 MaxEB 제안의 문제에 대해 언급하며, 이미 디버깅이 이루어졌지만, 향후 Pectra devnet에서 해결책을 검증하기 위해 더 깊은 테스트가 필요하다고 말했습니다.

ACDE #193에서 논의된 바와 같이, CL 클라이언트가 EL blob 거래 메모리 풀에서 blob을 가져올 수 있도록 허용하는 새로운 Engine API 규격이 있습니다. 이 방법은 "getBlobsV1"이라고 불립니다. 남용을 피하기 위해 Teku 개발자 Enrico del Fante는 CL 규격에 대한 몇 가지 명확화를 제안했습니다. Stokes는 개발자들이 이러한 명확화를 검토하고 Pectra Devnet 3에서 이 방법의 사용을 테스트할 계획이라고 제안했습니다.

개발자들은 mplex 프로토콜의 폐기에 대해 논의했습니다. Mplex는 CL 클라이언트가 단일 통신 링크에서 여러 데이터 흐름을 전송하는 데 사용되었던 프로토콜이지만, 현재는 그 유지 관리자가 폐기하였습니다. 클라이언트 팀은 yamux와 같은 새로운 데이터 흐름 재사용 기술로 전환할 계획입니다. Lodestar의 Phil Ngo는 그들이 yamux의 통합 및 테스트 작업을 완료했으며, 두 프로토콜을 장기적으로 유지하는 것보다 새로운 프로토콜로 직접 전환하는 것을 선호한다고 발표했습니다. Nimbus의 Etan Kissling도 그들의 팀이 yamux를 테스트하고 있다고 밝혔습니다. 개발자들은 다른 CL 클라이언트 팀의 프로토콜 전환 진행 상황을 계속 주시하고, 향후 몇 달 내에 mplex에서 새로운 재사용기로의 마이그레이션 전략을 다시 평가할 계획에 합의했습니다.

Etan Kissling은 Pectra 주제에서 EIP 7688에 대한 논의를 제기했습니다. 이 제안은 스마트 계약 개발자가 이더리움 실행 계층(EL)의 데이터 직렬화 방법이 RLP에서 SSZ로 전환될 때 계속 사용할 수 있도록 앞으로 호환 가능한 데이터 구조를 도입하는 것을 목표로 하고 있습니다. 비록 Pectra 업그레이드 자체가 SSZ를 완전히 구현하지는 않지만, EIP 7688의 제안은 Pectra EIP가 데이터 변경 측면에서 앞으로 호환성을 보장하기 위한 것입니다.

Alex Stokes는 Pectra 업그레이드에 EIP 7688을 포함하는 것에 대해 신중한 태도를 보이며, 업그레이드 규모가 이미 상당히 크다고 언급했습니다. Parithosh Jayanthi는 회의 중 EIP 7688이 가장 빠르면 Devnet 5에서 테스트될 수 있다고 언급했습니다. Lodestar, Prysm, Teku 및 Lighthouse 팀의 대표들은 이 제안에 대해 지지를 표명했습니다. Stokes와 Beiko는 모든 기존 Pectra EIP가 안정 상태에 도달하기 전까지는 Pectra에 새로운 EIP를 추가하는 것을 피해야 한다고 제안했습니다. Kissling은 이 제안을 수용하고, 이 주제를 다시 논의하기에 가장 좋은 시점이 언제인지 질문했습니다. 구체적인 답변은 없었지만, 팀은 일반적으로 Pectra Devnet 5 시작 전에 EIP 7688을 다시 평가해야 한다고 생각했습니다.

PeerDAS 업데이트

Prysm 클라이언트 팀의 대표는 회의에서 PeerDAS 구현의 최신 진행 상황을 보고하였으며, "blob sidecar" Engine API 요청의 필요성에 대한 논의를 촉발했습니다. Alex Stokes는 다음 PeerDAS 소그룹 회의에서 PeerDAS가 Engine API에 필요한 조정 사항에 대해 심도 있는 논의를 진행할 것을 제안했습니다. 그는 또한 한 EF 연구원이 공식 규격 초안을 작성했으며, 샘플링 메커니즘을 PeerDAS에서 제거할 것을 제안하여 업그레이드 과정의 복잡성을 줄이는 것을 목표로 하고 있다고 언급했습니다. 그러나 최근 PeerDAS 소그룹 회의에서 참석자들은 이 조치가 향후 하드 포크를 통해 샘플링을 다시 도입하는 데 어려움을 증가시킬 수 있다는 우려를 표명했습니다. 또한 샘플링 메커니즘의 제거가 Pectra에서 blob gas limit의 안전 증가에 미치는 영향은 아직 명확하지 않습니다. 실행 계층(EL)과 합의 계층(CL)에서 blob gas limit을 분리하는 제안인 EIP 7742가 이번 주 전화 회의에서 다시 제기되었습니다. Stokes는 이 EIP를 업데이트할 것이며, 다음 CL 전화 회의에서 그 포함 가능성과 Pectra의 blob gas limit 조정과 관련된 주제를 논의할 계획이라고 밝혔습니다.

연구 업데이트

이번 주 전화 회의에서 개발자들은 세 가지 연구 주제에 집중하여 논의했습니다. 첫째, 그들은 EIP 7251 하에서 검증자가 합병 시 스테이킹 ETH 잔액을 병합할 때 발생할 수 있는 엣지 케이스를 탐구했습니다. Etan Kissling은 검증자 잔액이 병합 기간 동안 오랜 시간 동안 업데이트되지 않을 수 있으며, 이는 프로토콜이 동기화 위원회 책임을 잘못 할당하게 만들 수 있다고 제안했습니다. 이에 대해 Alex Stokes는 이 문제가 프로토콜이 검증자 퇴출을 처리하는 상황과 유사하다고 응답하며, 이 엣지 케이스를 합의 계층(CL) 규격에 기록하되 기존의 합병 설계를 변경하지 말 것을 제안했습니다.

그 후 개발자들은 이더리움 네트워크 계층의 변경, 특히 "quic ENR entry"의 도입에 대해 논의했습니다. Quic는 빠른 UDP 인터넷 연결을 의미하며, 이는 노드가 데이터를 송수신하는 데 도움을 줍니다. Stokes는 GitHub에 pull request(PR)를 생성하여 quic ENR entry의 구체적인 변경 사항을 더 자세히 설명할 것을 제안했습니다.

마지막으로, ProbeLab은 이더리움 네트워크의 노드 운영 상황에 대한 지속적인 분석을 공유했습니다. 보고서에 따르면 현재 이더리움 네트워크에서 8335개의 노드가 운영되고 있으며, 그 중 42%가 Lighthouse 클라이언트를 사용하고 있습니다. 미국에서 운영되는 노드는 총 수의 36%를 차지하며, 약 절반의 노드가 데이터 센터에 배치되어 있습니다. Prysm의 개발자 "Potuz"는 데이터 센터에서 호스팅되는 Lighthouse 노드 수가 자가 호스팅 노드 수를 초과하는 현상에 대해 호기심을 보였습니다. Stokes는 이는 Lighthouse 클라이언트의 주요 사용자 집단이 기관 및 전문 노드 운영자를 포함하기 때문일 것이라고 추측했습니다.

회의가 끝날 무렵, Potuz는 팀이 그가 제출한 실행 유효 페이로드 구조 조정에 대한 PR을 검토할 것을 촉구했습니다. 이 제안은 이전 ACDC 전화 회의에서 처음 제기되었습니다. Potuz는 신속한 의사 결정의 중요성을 강조하며, 이러한 변경 사항이 개념적으로 간단하더라도 이를 합의 계층(CL) 규격에 통합하는 것은 상당한 도전이 될 것이라고 지적했습니다. 그는 개발자들이 이 작업을 조속히 시작할 것을 제안했습니다.