이더리움 핵심 개발자 최신 회의 요약: 메인넷 상태 및 성장 데이터 분석, 프라하 업그레이드 제안

원문 제목：《Ethereum All Core Developers Execution Call #184 Writeup》
원문 저자：Christine Kim
편집：Luccy，BlockBeats

편집자 주：

이더리움 모든 핵심 개발자 합의 전화(ACDE)는 2주마다 열리며, 주로 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번은 ACDE 제 184차 전화 회의로, 이번 회의에서는 3월 27일 블록 수가 증가한 이유와 Paradigm 팀의 이더리움 상태 및 역사적 성장에 대한 새로운 연구에 중점을 두었습니다.

개발자들은 회의에서 Bloxroute MEV 중계 문제와 Prague/Electra에서의 두 개의 소급 EIP에 대한 논의를 공유했습니다. 또한 EIP 7547(포함 목록), EIP 5920(PAY 연산자) 및 EIP 7545(Verkle 증명 검증 사전 컴파일)에 대한 개발 업데이트도 논의되었습니다.

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

2024년 3월 28일, 이더리움 개발자들은 Zoom에서 All Core Developers Execution (ACDE) call #184 회의에 참석했습니다. ACDE 전화 회의는 이더리움 재단 프로토콜 지원 책임자 Tim Beiko가 주재하며, 개발자들은 회의에서 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다.

이번 주, 개발자들은 3월 27일 블록 수가 증가한 이유에 대한 통찰을 공유했습니다. Prysm 개발자 Terence Tsao는 이 증가가 Bloxroute MEV 중계 문제로 인해 발생했다고 밝혔으며, Bloxroute 팀이 이 문제를 해결하고 있다고 전했습니다. 개발자들은 또한 Paradigm 팀의 이더리움 상태 및 역사적 성장에 대한 새로운 연구의 요점을 논의했습니다. 개발자들은 Prague/Electra에 두 개의 소급 이더리움 개선 제안(EIP)인 EIP 7610과 7523을 포함하기로 승인했습니다.

마지막으로, 그들은 EIP 7547(포함 목록), EIP 5920(PAY 연산자) 및 EIP 7545(Verkle 증명 검증 사전 컴파일)와 같은 다른 후보 EIP의 개발 업데이트를 공유했습니다.

메인넷 블록 누락 사건

3월 27일, 누락된 블록 수가 증가했습니다. 일반적으로 이더리움에서는 30분마다 2%에서 4%의 블록이 누락됩니다. 그러나 네트워크가 대량의 Blob 거래를 경험하는 동안 이 비율은 몇 시간 내에 14% 이상으로 증가했습니다. 이 기간 동안 blob 가격은 10배 이상 상승했습니다. Tsao는 Bloxroute 팀이 MEV 중계를 종료하자마자 누락된 블록 문제는 즉시 해결되었다고 말했습니다. Bloxroute 중계 문제의 세부 사항은 아직 명확하지 않으며, Bloxroute 팀은 수정 프로그램을 연구하고 있으며, 향후 며칠 내에 해당 수정 프로그램과 문제에 대한 전체 사후 분석을 공유할 예정입니다.

"그래서 어제 누락된 블록은 클라이언트가 이러한 유형의 작업량을 처리할 수 없다는 것이 아니라, 기본적으로 모든 누락된 블록이 Bloxroute 문제로 인해 발생했습니다. 하지만 여전히 어제의 트래픽 하에서 무슨 일이 발생할지에 대한 기본적인 질문이 있습니다. 저는 클라이언트가 블록을 가져오는 속도가 이전보다 느릴 수 있다고 의심하지만, 이는 제가 확실한 증거를 가지고 있지 않은 사항이며, 지켜봐야 할 일입니다,"라고 Tsao는 말했습니다. 누락된 블록 사건에 대응하기 위해 Lighthouse 클라이언트 팀은 노드 성능과 안정성을 높이기 위한 "핫픽스" 버전을 발표했습니다. 또한 조사가 진행 중이지만, Bloxroute의 CEO Uri Klarman은 X에서 이 문제가 Bloxroute 중계와는 무관하며, 이더리움에서 blob의 일반적인 전파 방식과 관련이 있다고 생각한다고 밝혔습니다.

이더리움 재단 개발자 운영 엔지니어 Parithosh Jayanthi는 이 사건이 개발자들이 클라이언트 차단 조건을 재평가하게 만들 것인지 질문했습니다. 이러한 조건은 자동으로 검증자 노드가 지역 블록 생산으로 되돌아가게 만듭니다. 대부분의 클라이언트에서 차단 조건의 기본값은 연속적으로 다섯 개의 슬롯을 놓치는 사건입니다. Tsao는 너무 쉽게 트리거되는 차단 조건이 복잡한 MEV 행위자가 이용할 수 있는 잠재적 공격 매개체가 될 수 있다고 지적했습니다.

Prysm 개발자 "Potuz"는 이 사건이 중계에서 클라이언트 다양성 구현의 부족과 중계 및 프로토콜 개발자 간의 소통 부족을 부각시킨다고 말했습니다. "Terence는 이 blob에 대해 일주일 넘게 이야기해왔지만, 아무도 이를 주목하지 않았습니다. 폭발하자마자 몇 통의 전화를 걸면 올바른 중계기가 실제로 그들의 로그를 확인할 수 있습니다. 이는 받아들일 수 없습니다,"라고 Potuz는 말했습니다.

일부 개발자들은 다음 번 네트워크 위반 사항을 보고할 때 서면 게시물을 작성하여 이더리움 생태계의 인지도를 높일 것을 제안했습니다. 누락된 블록 사건에 대한 추가 논의를 위해 이더리움 재단 연구원 Alex Stokes는 개발자들이 다음 MEV-Boost 커뮤니티 전화 회의에 참석할 것을 권장했습니다.

상태 및 역사 성장 데이터 분석

Paradigm의 데이터 과학자 엔지니어 Storm Slivkoff는 이더리움의 상태 및 역사적 성장에 대한 새로운 분석을 수행했습니다. 그의 발견에 따르면, 상태 성장은 이더리움 확장성의 주요 병목 현상이 아닙니다. "우리는 기존의 소비자 하드웨어가 현재의 국가 성장률을 오랜 시간 동안 유지할 수 있으며, 아마도 수십 년 동안 가능하다는 것을 발견했습니다. 제가 여기서 말하는 것은 저장 용량과 메모리 용량입니다. 이는 이러한 프레임워크 하에서 읽기 또는 쓰기를 선언하는 것이 아닙니다." 그의 관점에서 이더리움의 "침묵의 살인자"는 역사적 성장입니다.

서면 분석에서 Paradigm 연구팀은 "상태는 새로운 이더리움 블록을 구축하고 검증하는 데 필요한 데이터 세트입니다. 상태는 계약 바이트 코드, 계약 저장소, 계좌 잔액 및 계좌 무작위 배열로 구성됩니다. 기록은 노드를 창세기부터 최신 블록까지 동기화하는 데 필요한 데이터 세트입니다. 기록은 블록과 거래로 구성됩니다. 상태와 역사는 비중복 데이터 세트입니다."라고 설명했습니다. Slivkoff는 역사적 성장 속도가 이더리움 상태보다 현저히 빠르다고 덧붙였습니다. 역사적 성장률에 가장 큰 영향을 미치는 사용 사례는 롤업 및 이더리움에 브리징이 필요한 다른 유형의 프로토콜입니다.

Slivkoff는 개발자들이 다음 이더리움 업그레이드인 Prague/Electra에서 역사적 성장을 해결하기 위한 EIP를 가속화하는 것을 진지하게 고려할 것을 제안했습니다. 예를 들어 EIP 4444 및 EIP 7623과 같은 것입니다. 그는 또한 이더리움의 다른 확장성 병목 현상을 분석하고 이러한 방법을 롤업의 확장성 병목 현상 분석에 적용하기 위한 추가 분석이 진행될 것이라고 밝혔습니다. Slivkoff는 모든 데이터가 공개 소스로 제공될 것이며, 피드백을 환영한다고 말했습니다.

Slivkoff의 발표 후, 개발자들은 단기적으로 역사적 성장을 해결하는 다양한 방법에 대해 논의했습니다. ACDE #180에서 논의된 바와 같이, 개발자들은 강력한 대체 네트워크를 구축하고 있으며, 일정 기간의 역사적 데이터(예: 병합 업그레이드 이전의 역사적 데이터)가 이더리움 노드를 통해 접근할 수 없는 경우에도 사용자가 여전히 이러한 데이터에 접근할 수 있도록 하고 있습니다. 역사 만료 및 서비스 역사 데이터에 대한 대체 옵션에 대한 추가 논의에서 Geth 개발자 "Lightclient"는 개발자들이 이더리움 연구 Discord 채널에서 "역사 만료"라는 제목의 하위 채널 주제로 대화를 계속할 것을 제안했습니다.

소급 EIPIP7610 및 7523

개발자들은 EIP 7610 및 7523의 구현에 동의했습니다. 이들은 소급 EIP로, 이더리움 프로토콜에 규칙을 추가하여 네트워크 시작부터 소급 적용할 수 있으며, 체인 상의 특정 유형의 행동을 추가로 제한할 수 있습니다. 이러한 EIP의 이점은 이더리움 테스트 사례를 단순화하고, 빈 계좌 생성과 같은 다양한 엣지 케이스의 범위를 제한하는 것입니다. 두 개의 소급 적용된 EIP에는 EIPIP2681 및 3607이 포함됩니다. 개발자들은 Prague/Electra에서 추가 두 개의 소급 EIP를 활성화하는 데 동의했습니다. 이러한 EIP가 어떤 행동을 제약하는지에 대한 배경 정보는 이전 통화 기록을 참조하십시오.

EIP 2537, BLS 사전 컴파일

Geth 클라이언트 팀은 EIP 2537 BLS 곡선 작업의 가스 비용을 추정하기 위한 몇 가지 벤치마크 테스트를 완료했습니다. 이러한 새로운 작업은 Prague/Electra 업그레이드에서 활성화될 예정이며, 개발자들은 현재 이러한 작업의 가격 책정을 고려하고 있습니다. Reth 팀의 한 대표는 그의 팀이 BLS 곡선 작업에 대한 추가 벤치마크를 완료하여 이러한 작업의 가스 비용을 결정하는 데 도움을 줄 것이라고 밝혔습니다.

EIP 7547, 포함 목록

ACDC #130에서 논의된 바와 같이, 개발자들은 EIP 7547을 Prague/Electra 업그레이드에 포함하는 것을 강력히 고려하고 있습니다. 이번 주, 이더리움 재단 연구원 Mike Neuder는 EIP 7547을 계좌 추상화와 호환되도록 수정하는 방법에 대한 최신 정보를 공유했습니다. 계좌 추상화는 사용자 제어 계좌(EOA)에 더 큰 유연성과 프로그래밍 가능성을 도입하기 위한 지속적인 노력입니다. Neuder는 EIP 7547과 계좌 추상화 EIP 간의 호환성 문제를 해결하기 위한 세 가지 다른 방법을 제안했습니다. 이러한 해결책에 대해 Neuder는 "이것은 포괄적 설계의 복잡성처럼 느껴지지만, 저는 이 세 가지 선택이 실제로 효과적이라고 생각하며, 이 문제를 해결하기 위한 만병통치약은 없다고 생각합니다. 우리는 이 문제를 해결하기 위한 더 나은 설계를 찾지 못할 것이라고 생각합니다."라고 말했습니다.

Beiko는 제한된 시간 내에 별도의 그룹 회의에서 포함 목록 설계에 대한 논의를 계속할 것을 제안했습니다.

Prague/Electra의 다른 후보 EIP

다음으로, 개발자들은 Prague/Electra 업그레이드의 다른 후보 EIP 목록을 검토했습니다. 이들은 다음과 같습니다:

EIP 5920(PAY 연산자): 이더리움 재단 연구원 Sam Wilson은 해당 연산자의 테스트 작업이 시작되었다고 언급했습니다.

EIP 7609(TLOAD/TSTORE의 기본 비용 감소): Vyper 컴파일러 기여자 Charles Cooper는 TLOAD 및 TSTORE 연산자가 EVM에서 더 저렴하게 가격 책정되어야 한다고 재확인했습니다.

EIP 2935 및 7545(상태 및 Verkle 증명 검증 사전 컴파일에서 역사 블록 해시 값 저장): Geth 개발자 Guillaume Ballet는 이 두 제안을 코드 변경으로 제안했으며, 이는 Verkle 구현에 미래의 이점을 제공하고, 더 넓은 이더리움 생태계에 다가오는 Verkle 업그레이드를 상기시키는 데 도움이 될 것입니다.

이더리움 객체 형식(EOF): Besu 클라이언트 유지 관리자인 Danno Ferrin은 EOF EIP가 여러 클라이언트 팀에 의해 구현되고 있으며, 이들을 위한 참조 테스트가 작성되고 있다고 밝혔습니다. 그는 개발자들에게 더 자세한 업데이트를 위해 EOF 준비 매트릭스를 참조할 것을 요청했습니다.

EIP 7212 및 EIP 3074(secp256r1 곡선 지원 및 AUTH/AUTHCALL 연산자의 사전 컴파일): Besu 개발자 Matt Nelson은 L2 롤업이 구현 중인 이 두 EIP를 강조했습니다. 그는 이더리움과 롤업 간의 호환성을 장려하기 위해 이 두 EIP가 Prague에서 채택되어야 한다고 강조했습니다.

EIP 7664(접근 키 연산자): OPLabs 개발자 "Protolambda"는 접근 목록을 활용하여 AUTH/AUTHCALL 연산자의 기능을 강화하는 EIP 3074의 대체 제안을 제시했습니다.

EIP 6493(SSZ 거래 서명 계획): Protolambda는 이더리움 데이터의 보안성과 효율성을 높이기 위해 SSZ와 관련된 코드 변경을 지원한다고 밝혔습니다.

개발자들은 이 목록에서 어떤 EIP가 Prague에 우선적으로 적용되어야 하는지 논의할 시간이 없었습니다. Beiko는 2주 후 다음 ACDE 전화 회의가 시작될 때 시간을 차단하여 이 목록을 다시 검토할 것이라고 밝혔습니다. "앞으로 몇 주 동안 우리는 오늘 제기된 모든 문제를 더 깊이 연구하고 결정을 내리기 위해 노력해야 합니다. 이는 우리가 계속 진행하고자 한다면, 2주 후에 아직 완전히 명확하지 않거나 지정되지 않은 사항은 이 분기에는 포함되지 않을 가능성이 있다는 것을 의미합니다."라고 Beiko는 말했습니다.