원제: "Ethereum All Core Developers Execution Call #184 Writeup" 원저자: Christine Kim 원문 편집: Luccy, BlockBeats 편집자 주: Ethereum All Core Developers Consensus Call(ACDE)은 주로 토론과 조정을 위해 2주마다 개최됩니다. Ethereum 실행 계층(EL)이 변경되었습니다. 이번 ACDE의 184번째 컨퍼런스 콜은 3월 27일 누락된 블록 수가 증가한 이유와 이더리움의 위상과 역사적 성장에 대한 Paradigm 팀의 새로운 연구에 중점을 두었습니다. 개발자들은 회의에서 Bloxroute MEV 릴레이 문제와 프라하/Electra의 두 소급 EIP에 대한 토론을 공유했습니다. 또한 EIP 7547(포함 목록), EIP 5920(PAY Opcode) 및 EIP 7545(Verkle Proof Verification Precompilation)에 대한 개발 업데이트가 논의되었습니다. 갤럭시 디지털의 크리스틴 김(Christine Kim) 리서치 부사장은 이번 회의의 핵심 내용을 자세하게 기록했으며, 블록비스트는 다음과 같이 원문을 편집했습니다.

2024년 3월 28일, 이더리움 개발자들은 ACDE(All Core Developers Execution) 통화 #184 회의에 참여하기 위해 Zoom에 모였습니다. ACDE 컨퍼런스 콜은 이더리움 재단의 프로토콜 지원 책임자인 Tim Beiko가 주최하는 격주 일련의 회의로, 개발자들은 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다.

이번 주에 개발자들은 3월 27일에 누락된 블록이 증가한 원인에 대한 통찰력을 공유했습니다. Prysm 개발자 Terence Tsao는 Bloxroute 팀이 작업 중인 Bloxroute MEV 릴레이 문제로 인해 이러한 상승이 발생했다고 말했습니다. 개발자들은 또한 이더리움의 상태와 역사적 성장에 대해 Paradigm 팀이 수행한 새로운 연구의 핵심 사항에 대해 논의했습니다. 개발자들은 프라하/엘렉트라에서 두 개의 소급 이더리움 개선 제안(EIP), 즉 EIP 7610 및 7523을 포함하는 것을 승인했습니다.

마지막으로 EIP 7547(Inclusion List), EIP 5920(PAY Opcode), EIP 7545(Verkle Proof Verification Precompilation) 등 다른 후보 EIP에 대한 개발 업데이트를 공유했습니다.

메인넷 누락 블록 이벤트

3월 27일에는 누락된 블록 수가 증가했습니다. 일반적으로 이더리움에서는 30분마다 2%~4%의 블록이 누락됩니다. 그러나 네트워크에서 많은 수의 Blob 트랜잭션이 발생하는 기간에는 이 비율이 몇 시간 내에 14% 이상으로 증가합니다. 이 기간 동안 Blob 가격은 10배 이상 증가했습니다. Tsao는 Bloxroute 팀이 MEV 릴레이를 종료하자마자 누락된 블록 문제가 즉시 해결되었다고 말했습니다. Bloxroute 릴레이 문제를 일으키는 세부 정보는 알 수 없으며 Bloxroute 팀은 수정 작업을 진행 중이며 며칠 내에 문제의 전체 사후 분석과 함께 공유할 예정입니다.

"그래서 어제의 누락된 블록은 기본적으로 모든 누락된 블록이 Bloxroute 문제로 인해 발생하기 때문에 고객이 이러한 유형의 작업을 처리할 수 없다는 의미는 아닙니다. 그러나 어제의 트래픽에 어떤 일이 일어났을지에 대한 근본적인 질문은 여전히 ​​남아 있습니다." Tsao는 고객이 이전보다 블록을 느리게 가져오고 있을 수 있지만 이에 대한 결정적인 증거가 없으며 아직 지켜봐야 할 것이라고 말했습니다. 블록 누락 사고에 대응하여 Lighthouse 클라이언트 팀은 "뜨거운 수정된" 노드 성능과 안정성을 향상시키기 위한 버전입니다. 또한 조사가 계속 진행되는 동안 Bloxroute CEO Uri Klarman은 다음과 같이 말했습니다.

이더리움 재단 개발자 운영 엔지니어인 Parithosh Jayanthi는 이 사건으로 인해 개발자가 자동으로 검증자 노드가 로컬 블록 생산으로 돌아가게 만드는 클라이언트 회로 차단기 조건을 재평가하게 되는지 물었습니다. 대부분의 클라이언트에서 회로 차단기 조건의 기본값은 연속으로 5개 슬롯을 놓친 이벤트입니다. Tsao는 너무 쉽게 트리거되는 회로 차단기 조건은 정교한 MEV 공격자가 악용할 수 있는 잠재적인 공격 벡터라고 지적했습니다.

이더리움 재단 개발자 운영 엔지니어인 Parithosh Jayanthi는 이 사건으로 인해 개발자가 자동으로 검증자 노드가 로컬 블록 생산으로 돌아가게 만드는 클라이언트 회로 차단기 조건을 재평가하게 되는지 물었습니다. 대부분의 클라이언트에서 회로 차단기 조건의 기본값은 연속으로 5개 슬롯을 놓친 이벤트입니다. Tsao는 너무 쉽게 트리거되는 회로 차단기 조건은 정교한 MEV 공격자가 악용할 수 있는 잠재적인 공격 벡터라고 지적했습니다.

Prysm 개발자 "Potuz"는 자신의 의견으로는 이번 사건이 릴레이의 클라이언트 다양성 구현 부족과 릴레이와 프로토콜 개발자 간의 의사소통 부족을 강조한다고 말했습니다. "Terence는 일주일 넘게 이러한 얼룩에 대해 이야기해 왔지만 아무도 눈치 채지 못했습니다. 일단 폭발하면 몇 번의 전화 통화만으로 실제로 로그를 볼 수 있는 올바른 릴레이를 얻을 수 있습니다. 이는 용납할 수 없는 일입니다."라고 Portuzzi는 설명합니다.

일부 개발자는 이더리움 생태계의 가시성을 높이기 위해 다음에 네트워크 위반을 보고할 때 서면 게시물을 작성할 것을 권장합니다. 누락된 블록 사건에 대해 더 자세히 논의하기 위해 Ethereum Foundation 연구원 Alex Stokes는 개발자들에게 다음 MEV-Boost 커뮤니티 통화에 참석할 것을 권장했습니다.

현황 및 과거 성장 데이터 분석

Paradigm의 ​​데이터 과학자인 Storm Slivkoff는 이더리움의 상태와 역사적 성장에 대한 새로운 분석을 제공합니다. 그의 연구 결과에 따르면 상태 성장은 이더리움 확장성의 주요 병목 현상이 아닙니다. "우리는 기존 소비자 하드웨어가 장기간, 어쩌면 수십 년 동안 현재의 국가 성장률을 유지할 수 있다는 것을 발견했습니다. 여기서는 저장 용량과 메모리 용량에 대해서만 이야기하고 있다는 점에 유의하세요. 읽기 또는 쓰기가 아래에 선언되어야 한다는 뜻은 아닙니다. 이 프레임워크. 그의 견해에 따르면 이더리움의 "침묵의 살인자"는 역사적 성장입니다.

패러다임 연구팀은 서면 분석에서 "상태는 새로운 이더리움 블록을 구축하고 검증하는 데 필요한 데이터 세트이다. 상태는 컨트랙트 바이트코드, 컨트랙트 저장, 계정 잔액, 계정 논스로 구성된다. 히스토리는 데이터"라고 설명했다. 노드가 최초부터 최신 블록까지 동기화하는 데 필요한 세트 기록은 블록과 트랜잭션으로 구성됨 상태와 기록은 겹치지 않는 데이터 세트 Slivkoff는 기록이 이더리움 상태보다 훨씬 빠르게 성장하고 있다고 덧붙였습니다. 기록 증가에 미치는 영향 가장 큰 사용 사례 속도는 Ethereum에 연결되어야 하는 롤업 및 기타 유형의 프로토콜입니다.

Slivkoff는 개발자들이 다음 이더리움 업그레이드인 프라하/엘렉트라에서 EIP 4444 및 EIP 7623과 같이 역사적으로 증가하는 EIP의 해결을 가속화하는 것을 진지하게 고려할 것을 권장했습니다. 그는 또한 이더리움의 다른 스케일링 병목 현상을 분석하기 위해 추가 분석이 수행될 것이며 이러한 방법은 그의 팀 연구의 다음 단계로 롤업의 스케일링 병목 현상을 분석하는 데 적용될 것이라고 말했습니다. 모든 데이터는 대중이 사용할 수 있도록 오픈 소스로 공개될 것이며 피드백을 환영한다고 Slivkoff는 말했습니다.

Slivkoff의 프레젠테이션에 이어 개발자들은 단기적으로 역사적 성장을 해결할 수 있는 다양한 방법에 대해 논의했습니다. ACDE #180 에서 논의된 바와 같이 개발자들은 병합 업그레이드 전과 같이 특정 기간 동안의 과거 데이터가 이더리움 노드를 통해 데이터에 액세스할 수 없는 경우에도 사용자가 계속 액세스할 수 있는 강력한 대체 네트워크를 구축하고 있습니다. 기록 만료 및 기록 데이터 제공을 위한 대체 옵션에 대한 추가 논의를 위해 Geth 개발자 "Lightclient"는 개발자가 Ethereum R&D Discord 채널에서 "기록 만료"라는 제목의 하위 채널 주제로 대화를 계속할 것을 권장했습니다.

추적성 EIPIP7610 및 7523

개발자는 EIP 7610 및 7523을 구현하는 데 동의합니다. 이는 체인의 특정 유형의 행동을 더욱 제한하기 위해 네트워크 시작부터 소급 적용할 수 있는 규칙을 이더리움 프로토콜에 추가하는 소급 EIP입니다. 이러한 EIP의 이점은 이더리움 테스트 케이스를 단순화하고 빈 계정을 생성하는 엣지 케이스와 같은 다양한 엣지 케이스의 범위를 제한한다는 것입니다. 소급 적용되는 EIP로는 EIPIP2681과 3607이 있다. 개발자는 프라하/Electra에서 두 개의 추가 소급 EIP를 활성화하는 데 동의했습니다. 이러한 EIP가 적용하는 동작에 대한 배경 정보는 여기에서 이전 통화 기록을 참조하세요.

EIP 2537, BLS 사전 컴파일됨

Geth 고객 팀은 EIP 2537 BLS 곡선 작업의 가스 비용을 추정하기 위해 몇 가지 벤치마크를 완료했습니다. 이러한 새로운 서비스는 프라하/엘렉트라 업그레이드에서 활성화될 예정이며 개발자는 현재 이러한 서비스에 대한 가격을 평가하고 있습니다. Reth 팀의 한 대표는 그의 팀이 이러한 작업의 가스 비용을 결정하는 데 도움을 주기 위해 BLS 곡선 작업에 대한 추가 벤치마크도 완료할 것이라고 말했습니다.

EIP 7547(목록 포함)

ACDC #130 에서 논의된 것처럼 개발자는 프라하/Electra 업그레이드에 EIP 7547을 포함하는 것을 강력하게 고려하고 있습니다. 이번 주 이더리움 재단 연구원인 Mike Neuder는 EIP 7547이 계정 추상화와 호환되도록 수정하는 방법에 대한 최신 정보를 공유했습니다. 계정 추상화는 이더리움에서 사용자가 제어하는 ​​계정인 외부 계정(EOA)에 더 큰 유연성과 프로그래밍 가능성을 도입하기 위한 지속적인 이니셔티브입니다. Neuder는 EIP 7547과 Account Abstraction EIP 간의 호환성 문제를 해결하기 위해 세 가지 다른 접근 방식을 제안했습니다. 이러한 솔루션에 대해 Neuder는 "포괄적 디자인의 복잡성처럼 느껴지지만 이 세 가지 옵션이 효과가 있다고 생각하며 이 문제를 해결하기 위한 마법의 총알은 없을 것이라고 생각합니다. 나는 그렇지 않습니다."라고 말했습니다. 그럴 것이라고 생각합니다." 이러한 문제를 해결하기 위해 더 나은 디자인을 찾으십시오.

Beiko는 제한된 시간 동안 별도의 세부 세션에서 목록 디자인 통합에 대한 논의를 계속할 것을 권장합니다.

프라하/엘렉트라의 기타 EIP 후보

다음으로 개발자들은 프라하/Electra 업그레이드를 위한 다른 후보 EIP 목록을 검색했습니다. 여기에는 다음이 포함됩니다.

EIP 5920(PAY opcode): Ethereum Foundation 연구원인 Sam Wilson은 이 opcode에 대한 테스트가 시작되었다고 언급했습니다.

EIP 7609(TLOAD/TSTORE의 기본 비용 절감): Vyper 컴파일러 기여자 Charles Cooper는 EVM에서 TLOAD 및 TSTORE opcode의 가격이 더 저렴해야 한다는 자신의 견해를 반복했습니다.

EIP 2935 및 7545(상태 및 Verkle 증명 확인 사전 컴파일에서 기록 블록 해시 보존): Geth 개발자 Guillaume Ballet은 Verkle 구현에 향후 이점을 제공할 코드 변경으로 이 두 가지 제안을 제안했으며 그 동안 더 넓은 범위에 대한 도움말 경고가 있습니다. 다가오는 Verkle 업그레이드의 이더리움 생태계.

EOF(Ethereum Object Format): Besu 클라이언트 유지관리자 Danno Ferrin은 EOF EIP가 여러 클라이언트 팀에 의해 구현되고 있으며 이를 위한 참조 테스트가 작성되고 있다고 말했습니다. 그는 개발자들에게 보다 자세한 업데이트를 위해 EOF 준비 매트릭스를 참조하도록 요청했습니다.

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

EIP 7664(액세스 키 Opcode): OPLabs 개발자 "Protolambda"는 액세스 목록을 활용하여 AUTH/AUTHCALL opcode의 기능을 향상시키는 EIP 3074에 대한 대체 제안을 제안했습니다.

EIP 6493(SSZ 거래 서명 체계): Protolambda는 또한 이더리움 데이터 검증의 보안과 효율성을 향상시키기 위해 SSZ 관련 코드 변경에 대한 지원을 표명했습니다.

개발자들은 이 목록의 어떤 EIP가 프라하에 대해 우선순위를 두어야 하는지 논의할 시간이 없었습니다. Beiko는 목록을 다시 검토하기 위해 2주 후에 다음 ACDE 전화 회의가 시작될 때 시간이 차단될 것이라고 말했습니다. "앞으로 몇 주 동안 우리는 오늘 제기된 모든 문제를 더 깊이 살펴보고 결정을 내려야 합니다. 이는 우리가 앞으로 나아가고 싶다면 2주 안에 완전히 명확하지 않거나 아직 밝혀지지 않은 사항이 있을 것이라는 뜻이라고 생각합니다. 아무것도 이 분기점에 들어갈 수 없습니다.”라고 Beiko는 말했습니다.