원제: "Ethereum All Core Developers Execution Call #184 Writeup"
원저자: Christine Kim
편집자: Luccy, BlockBeats
편집자 주:
이더리움 커뮤니티에서는 이더리움 EL(Ethereum Execution Layer) 개선 사항을 논의하고 협상하기 위해 ACDE(All Core Developers Consensus Call)가 2주마다 개최됩니다. 이번 ACDE의 184차 컨퍼런스 콜은 3월 27일 잘못된 블록 수가 증가한 이유와 이더리움의 위상과 역사적 성장에 대한 Paradigm 팀의 새로운 연구에 초점을 맞출 것입니다.
개발자들은 컨퍼런스에서 Bloxroute MEV 릴레이 문제와 프라하/Electra의 두 소급 EIP에 대한 토론을 공유했습니다. 또한 EIP 7547(포함 목록), EIP 5920(PAY Opcodes) 및 EIP 7545(Verkle Proof Verification Precompilation)에 대한 개발 업데이트에 대해서도 논의했습니다.
갤럭시디지털 연구담당 크리스틴 김 부사장은 이번 회의의 핵심 사항을 자세히 기록했고, BlockBeasts는 원문을 다음과 같이 편집했습니다.
2024년 3월 28일 이더리움 개발 커뮤니티는 All Core Developers를 위한 Zoom 회의를 소집했습니다. 실행(ACDE) 호출 #184 ACDE 호출은 이더리움 개발과 관련된 결정이 논의되고 조정되는 격주 일련의 회의입니다. 이더리움 재단이 지원하는 주요 코디네이터인 Tim Beiko가 토론과 합의 구축을 주도했습니다.
이번 주에 개발자들은 3월 27일에 잘못된 블록이 증가한 원인에 대한 통찰력을 공유했습니다. Prysm 개발자 Terence Tsao는 Bloxroute 팀이 작업 중인 Bloxroute MEV 릴레이 문제로 인해 이러한 상승이 발생했다고 말했습니다. 개발자들은 또한 이더리움의 상태와 역사적 성장에 대해 Paradigm 팀이 수행한 새로운 연구의 핵심 사항에 대해 논의했습니다. 개발자들은 프라하/엘렉트라에 두 개의 소급 이더리움 개선 제안(EIPs 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 공격자가 악용할 수 있는 잠재적인 공격 벡터라고 지적했습니다.
Prysm 개발자 "Potuz"는 자신의 의견으로는 이번 사건이 릴레이의 클라이언트 다양성 구현 부족과 릴레이와 프로토콜 개발자 간의 의사소통 부족을 강조한다고 말했습니다. "Terence는 일주일 넘게 이 얼룩에 대해 이야기해 왔지만 아무도 눈치채지 못했습니다. 일단 폭발하면 몇 번의 전화 통화만으로 실제로 로그를 볼 수 있는 올바른 릴레이를 얻을 수 있습니다. 이것은 용납할 수 없는 일입니다."라고 Portuzzi Say는 말합니다.
일부 개발자는 이더리움 생태계의 가시성을 높이기 위해 다음에 네트워크 위반을 보고할 때 서면 게시물을 작성할 것을 권장합니다. 누락된 블록 사건에 대해 더 자세히 논의하기 위해 Ethereum Foundation 연구원 Alex Stokes는 개발자들에게 다음 MEV-Boost 커뮤니티 통화에 참석할 것을 권장했습니다.
Paradigm의 데이터 과학자 엔지니어 Storm Slivkoff는 이더리움의 상태 및 역사적 성장에 대한 새로운 분석을 수행했습니다. 그의 연구 결과에 따르면 상태 성장은 이더리움 확장성의 주요 병목 현상이 아닙니다. “우리는 기존 소비자 하드웨어가 장기간, 아마도 수십 년 동안 현재의 국가 성장률을 유지할 수 있다는 것을 발견했습니다. 여기서는 저장 용량과 메모리 용량에 대해서만 이야기하고 있다는 점에 유의하십시오. 이 프레임워크. 그의 견해에 따르면 이더리움의 "침묵의 살인자"는 역사적 성장입니다.
서면 분석에서 패러다임 연구팀은 다음과 같이 설명했습니다. “상태는 새로운 이더리움 블록을 구축하고 검증하는 데 필요한 데이터 세트입니다. 상태는 계약 바이트코드, 계약 저장소, 계정 잔액 및 계정 내역으로 구성됩니다. 생성부터 최신 블록까지 노드를 동기화합니다. 기록은 블록과 트랜잭션으로 구성되며 기록은 겹치지 않는 데이터 세트라고 Slivkoff는 덧붙였습니다.
Slivkoff는 개발자들이 EIP 4444 및 EIP 7623과 같은 다음 이더리움 업그레이드 프라하/엘렉트라의 역사적 성장을 해결하는 EIP의 속도를 높이는 것을 진지하게 고려할 것을 권고했습니다. 이러한 방법을 적용하여 롤업의 확장 병목 현상을 분석합니다. Slivkoff는 팀 연구의 다음 단계로 모든 데이터가 공개 소스로 사용될 것이며 피드백을 환영한다고 말했습니다.
Slivkoff의 프레젠테이션에 이어 개발자들은 역사적 성장을 해결하기 위한 다양한 방법에 대해 논의했습니다. 단기적으로 ACDE #180에서 논의된 바와 같이 개발자는 병합 업그레이드 전과 같은 기간 동안 특정 과거 데이터를 사용하여 Ethereum 노드를 통해 데이터에 액세스할 수 없는 경우에도 사용자가 계속 액세스할 수 있는 강력한 대체 네트워크를 구축하고 있습니다. 기록 만료 및 기록 데이터 제공을 위한 대체 옵션에 대한 추가 논의인 "Lightclient"는 개발자가 "기록 만료"라는 제목의 하위 채널 주제에서 Ethereum R&D Discord 채널에서 계속 대화할 것을 권장합니다.
개발자는 EIP 7610 및 7523을 구현하는 데 동의합니다. 이는 체인의 특정 유형의 행동을 더욱 제한하기 위해 네트워크 시작부터 소급 적용할 수 있는 규칙을 이더리움 프로토콜에 추가하는 소급 EIP입니다. 이러한 EIP의 이점은 이더리움 테스트 케이스를 단순화하고 빈 계정을 생성하는 엣지 케이스와 같은 다양한 엣지 케이스의 범위를 제한한다는 것입니다. 소급 적용되는 EIP로는 EIPIP2681과 3607이 있다. 개발자는 프라하/Electra에서 두 개의 추가 소급 EIP를 활성화하는 데 동의했습니다. 이러한 EIP가 적용되는 작업에 대한 배경 정보는 여기에서 이전 통화 기록을 참조하세요.
Geth 고객 팀은 EIP 2537 BLS 곡선 작업의 가스 비용을 추정하기 위해 몇 가지 벤치마크를 완료했습니다. 이러한 새로운 비즈니스는 프라하/엘렉트라 업그레이드에서 활성화될 예정이며 개발자는 현재 이러한 비즈니스에 대한 가격을 평가하고 있습니다. Reth 팀의 한 대표는 그의 팀이 이러한 작업의 가스 비용을 결정하는 데 도움을 주기 위해 BLS 곡선 작업에 대한 추가 벤치마크도 완료할 것이라고 말했습니다.
ACDC #130에서 논의한 바와 같이 개발자들은 프라하/Electra 업그레이드에 EIP 7547을 포함하는 것을 강력히 고려하고 있습니다. 이번 주 이더리움 재단 연구원인 Mike Neuder는 EIP 7547이 계정 추상화와 호환되도록 수정하는 방법에 대한 최신 정보를 공유했습니다. 계정 추상화는 이더리움에서 사용자가 제어하는 계정인 외부 계정(EOA)에 더 큰 유연성과 프로그래밍 가능성을 도입하기 위한 지속적인 이니셔티브입니다. Neuder는 EIP 7547과 Account Abstraction EIP 간의 호환성 문제를 해결하기 위해 세 가지 방법을 제안했습니다. 이러한 솔루션에 대해 Neuder는 "포괄적 디자인의 복잡성처럼 느껴지지만 이 세 가지 옵션이 효과가 있다고 생각하며 이 문제를 해결하기 위한 마법의 총알은 없을 것이라고 생각합니다. 나는 그렇지 않습니다."라고 말했습니다. 우리는 그럴 것이라고 생각합니다." 이러한 문제를 해결하는 더 나은 디자인을 찾으십시오.
Beiko는 제한된 시간 동안 별도의 브레이크아웃 세션에서 목록 디자인에 포함할 다른 후보 EIP에 대한 논의를 계속할 것을 제안했습니다
EIP 5920(PAY opcode): Ethereum Foundation 연구원 Sam Wilson은 이 opcode
EIP 7609(TLOAD/TSTORE 기본 비용 절감)에 대한 테스트 작업이 시작되었다고 언급했습니다. ): Vyper 컴파일러 기여자 Charles Cooper는 TLOAD 및 TSTORE opcode가 EVM에서 더 저렴하게 가격이 책정되어야 한다는 자신의 견해를 반복했습니다
EIP 2935 및 7545(상태 및 Verkle 증명 검증 사전 컴파일에서 과거 블록 해시 보존): Geth 개발자 Guillaume Ballet은 Verkle 구현에 향후 이점을 제공할 코드 변경으로 이 두 가지 제안을 제안했으며 동시에 더 넓은 범위에 경고하는 데 도움이 됩니다. 다가오는 Verkle 업그레이드의 이더리움 생태계.
이더리움 객체 형식(EOF): 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는 말했습니다.
위 내용은 최근 이더리움 핵심 개발자 회의 요약: 메인넷 상태 및 성장 데이터 분석, 프라하 업그레이드 제안의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!