원제: "Ethereum All Core Developers Execution Call #187 Writeup" 원저자: Christine Kim 원저자: Luccy, BlockBeats

편집자 주: ACDE(All Core Ethereum Developers Consensus Call)는 EL(Ethereum Execution Layer)에 대한 변경 사항을 논의하고 조정하기 위해 2주마다 개최됩니다. 이번 회의에서 개발자들은 Pectra Devnet 0 준비, EIP 3074 구현 업데이트, 실행 계층의 직렬화 방법을 MPT에서 SSZ로 전환하는 시급성에 대해 논의했습니다. 개발자들은 Pectra Devnet 0 준비 외에도 새로운 EIP 제안, 기존 EIP에 대한 토론 및 분석, 스마트 계약 및 거래에 대한 영향 분석에 대해서도 논의했습니다. 그 중 EIP 7702에 대한 논의는 참석자들의 폭넓은 관심을 끌었으며, 해당 제안은 EIP 3074를 대체할 잠재적인 솔루션으로 여겨졌다. 갤럭시디지털의 크리스틴 김 부사장은 이번 회의의 핵심 내용을 구체적으로 기록해 블록비스트가 원문을 다음과 같이 정리했다.

2024년 5월 9일, 이더리움 개발자들은 ACDE(All Core Developers Execution) 통화 #187 회의에 참여하기 위해 Zoom에 모였습니다. ACDE 컨퍼런스 콜은 이더리움 재단의 프로토콜 지원 책임자인 Tim Beiko가 주최하는 격주 일련의 회의로, 개발자들은 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번 주에 개발자들은 Pectra Devnet 0 준비, EIP 3074 구현 업데이트, EL의 직렬화 방법을 MPT에서 SSZ로 변환하는 시급성에 대해 논의했습니다.

Pectra Devnet-0 업데이트

Ethereum Foundation 개발자 운영 엔지니어인 Barnabas Busa는 그의 팀이 최초의 Pectra 개발자 중심 테스트 네트워크의 클라이언트 구성을 테스트하고 있으며 5월 13일 월요일까지 Pectra Devnet 0의 안정적인 구성을 보장하기 위해 노력할 것이라고 말했습니다. Pectra Devnet 0 준비 추적기에 따르면 Geth, Nethermind 및 EthereumJS 클라이언트 팀은 Pectra 코드 사양을 완전히 구현했습니다.

전화 회의에서 Besu 개발자 Justine Florentine은 모든 Pectra EIP가 Besu에서 구현되었지만 그의 팀은 여전히 ​​코드 디버깅을 위해 열심히 노력하고 있다고 말했습니다. Erigon 개발자 Andrew Ashikhmin은 그의 팀이 EL 트리거 가능 철수인 EIP 7002를 제외한 모든 EIP에 대한 작업을 시작했다고 말했습니다. Reth 팀은 Zoom 채팅에 구현 추적기에 대한 링크를 게시하여 Erigon 팀과 마찬가지로 EIP 7002에 대한 작업이 아직 계류 중임을 보여주었습니다.

CL 클라이언트 측에서 Grandine 개발자 Saulius Grigaitis는 모든 EIP가 구현되었지만 그의 팀은 EL 클라이언트로 실행할 때 몇 가지 버그에 직면했다고 말했습니다. Lighthouse 팀 대표는 Pectra Devnet 0에 대한 완전한 구현 준비가 거의 완료되었으며 엔진 API의 사양을 업데이트해야 한다고 말했습니다. Teku 개발자 Mikhail Kalinin은 엔진 API 사양에 이러한 업데이트를 추가하기 위해 노력하고 있다고 말했습니다.

EF 테스트 팀의 Mario Vegas는 개발자들이 EIP 3074, AUTH 및 AUTHCALL opcode 및 기타 여러 EIP에 대한 테스트 사례를 추가하기 위해 노력하고 있다고 말했습니다.

EIP-3074 업데이트

개발자들은 Pectra Devnet 0 사양에서 EIP 3074를 유지하는 데 동의했지만 이를 대체하기 위한 대체 EIP인 EIP 7702가 논의되었습니다. Geth 개발자 "Lightclient"는 EIP 3074에 대한 최신 브레이크아웃 세션을 요약했습니다. 여기서 참가자들은 사용자 제어 계정 프로그래밍 가능성 개선과 관련하여 Pectra 업그레이드에서 우선 순위를 정해야 할 변경 사항을 논의했습니다. Lightclient에 따르면 모든 참가자는 완전한 기본 계정 추상화가 Ethereum에서 구현되려면 아직 몇 년이 걸린다는 데 동의합니다. 그러나 이것이 외부 소유 계정(EOA) 기능의 변경에 우선순위를 두는 것을 의미하는지, 아니면 EOA를 스마트 계약 지갑으로 마이그레이션하는 것을 의미하는지에 대해서는 의견이 일치하지 않습니다. ACDE 컨퍼런스 콜 전날인 5월 8일, 이더리움 공동 창업자인 비탈릭 부테린(Vitalik Buterin)은 새로운 EIP인 EIP 7702를 제안했습니다. 이를 통해 이더리움은 단일 거래 중에 EOA가 스마트 계약 지갑처럼 작동하도록 지원하는 새로운 거래 유형을 지원할 수 있습니다. Lightclient는 EIP 3074 브레이크아웃 세션 참가자들이 일반적으로 EIP 7702에 대해 긍정적이라고 말했습니다. 그러나 그는 나중에 EIP 7702와 관련하여 해결해야 할 중요한 세부 사항이 여전히 남아 있다고 덧붙였습니다. 예를 들어, EIP 7702 거래를 취소하는 방법과 그러한 거래의 가스 비용을 조정하는 방법에 대한 세부 정보는 여전히 불분명합니다.

EIP 7702가 승인되어 Pectra 업그레이드에 포함되면 EIP 7702는 EIP 3074와 유사한 결과를 달성하지만 Ethereum에서 새로운 opcode를 생성하지 않고 EIP의 안정성을 향상시키기 때문에 EIP 3074를 대체하는 것으로 간주됩니다. 새로운 EOA 동작. EF 연구원 Ansgar Dietrichs는 Zoom 채팅에서 EIP 7702를 Pectra에 포함하는 것을 고려할 것을 제안했으며, EIP 3074를 7702로 교체할지 여부에 대한 공식적인 결정은 약 2~4주 내에 이루어질 것입니다. 제안이 구현 준비가 된 것으로 간주되기 전에 추가 작업이 필요하다는 것이 통화 중 EIP 7702에 대한 개발자의 논의에서 분명해졌습니다. Nethermind 개발자인 Ahmad Mazen Bitar는 EIP 3074에 대해 이미 수행된 작업이 7702 구현에 재사용될 가능성이 낮다고 지적했습니다. Beiko는 개발자가 Devnet 0용 EIP 3074 구현을 계속 진행하고 나중에 Devnet-1 사양을 다시 검토해야 함을 확인했습니다.

EIP-7685, SSZ 및 EIP-6110

그런 다음 개발자들은 EIP 7685에 대해 Nimbus 개발자 Etan Kissling이 제기한 몇 가지 우려 사항, 즉 공통 실행 계층 요청에 대해 논의했습니다. 이번 주 전화 회의 의제에 대한 GitHub 댓글에서 Kissling은 Universal Execution Layer 요청에 대해 제안된 설계가 필요한지, 그리고 SSZ로 전환하는 데 더 나은 기회를 사용할 수 있는지 물었습니다. 이는 개발자들이 병합 업그레이드 이후 어려움을 겪고 있는 문제입니다. 실행 계층에서 업데이트될 것으로 예상되는 직렬화 형식입니다. 통화 중인 대부분의 고객 경영진은 Pectra에서 EIP 7685를 유지하는 것을 지원하며, 클라이언트의 낙관적 동기화와 같이 운영에 EIP를 포함하는 데 장애가 되는 경우 설계를 다시 검토합니다.

SSZ로의 전환에 관해 Kissling은 공통 실행 계층 요청(Common Execution Layer Request)의 새로운 디자인 형식이 레거시 직렬화 형식 MPT 및 RLP를 기반으로 하므로 개발자가 SSZ로 전환함에 따라 업데이트해야 한다고 설명했습니다. 그는 SSZ로의 이동을 지연하는 것은 개발자가 계속해서 새로운 MPT/RLP 데이터 구조를 생성하는 경우에만 더 많은 작업을 생성하게 될 것이라고 지적했습니다. 그러나 SSZ 안정 컨테이너인 EIP 7495를 Pectra에 포함시키려는 경영진 클라이언트 팀의 강력한 지원은 없습니다. "Dustin"이라는 개발자는 Zoom 채팅에서 SSZ 전환을 연기하기로 한 결정은 "미친 짓"이며 EL에서 제대로 작동하지 않는 SSZ 라이브러리 문제는 "심각한 문제"라고 썼습니다.

온체인 공급 검증인 예금인 EIP 6110과 관련하여 Kissling은 예금 순서에 대한 질문을 제기했습니다. Kalinin은 이 문제가 "중요한 우려 사항"이며 주요 스테이킹 풀과 협력하여 더 깊이 조사할 것이라는 데 동의했습니다.

EOF 업데이트

온체인 공급 검증인 예금인 EIP 6110과 관련하여 Kissling은 예금 순서에 대한 질문을 제기했습니다. Kalinin은 이 문제가 "중요한 우려 사항"이며 주요 스테이킹 풀과 협력하여 더 깊이 조사할 것이라는 데 동의했습니다.

EOF 업데이트

독립 Ethereum 프로토콜 개발자 Danno Ferrin과 EF Solidity 연구 책임자 Alex Beregszaszi가 EOF 구현 노력에 대한 업데이트를 공유했습니다. 맥락상 EOF는 개발자가 Pectra 업그레이드에 통합을 고려하고 있는 EVM(Ethereum Virtual Machine)을 개선하기 위한 일련의 코드 변경입니다. EOF용 Meta-EIP가 완성되었습니다. 개발자들은 또한 EOF에서 트랜잭션 생성 프로세스를 단순화했으며 EOF의 클라이언트 구현을 위해 노력하고 있습니다.

EIP-7623 업데이트

전화 회의에서 "William Morris"라는 대화명을 사용한 개발자는 EIP 7623의 통화 데이터 저장에 대한 가스 비용 변경에 대한 우려를 제기했습니다. 그는 이러한 변화를 통해 일부 사용자는 거래를 통합하여 더 낮은 요율로 거래할 수 있게 되고, 이를 통해 레이어 2 롤업(L2) 및 기타 참가자가 보다 저렴하게 네트워크 거래로 이동할 수 있도록 가스 할인을 위한 2차 시장 생성을 장려할 것이라고 설명했습니다. 에. 그는 이러한 문제를 해결하기 위해 고정 요금으로 통화 데이터 비용을 추가하는 대체 EIP인 EIP 7703을 권장했습니다.

Buterin은 Morris의 우려가 타당하지만 EIP 7623의 결과로 통화 데이터에 대한 2차 시장이 실제로 생성될 가능성은 높지 않다고 말했습니다. 그러한 시장에 참여하기로 선택한 사용자의 수가 극도로 제한되기 때문입니다. Buterin은 EIP 7623의 영향을 받는 주요 플레이어가 2차 개발 팀인 Starkware 및 Inscription Creator라고 언급했습니다. 그는 2차 콜데이터 시장의 전체 주소 지정 가능 시장은 작지만 콜데이터를 통해 최대 블록 크기 제한을 늘리면 개발자가 블롭가스 한도를 늘릴 수 있어 이더리움의 L2 지원 능력이 확장될 수 있기 때문에 이점이 매우 높다고 덧붙였습니다. . Vitalik은 또한 Morris가 제안한 것처럼 통화 데이터 비용의 균일한 증가는 현재 EIP보다 L2 및 기타 이해관계자에게 더 가혹한 영향을 미칠 것이라고 말했습니다. Buterin은 통화 전 블로그 게시물에서 Blob의 가스 가격에 대한 더 많은 생각을 공유했습니다.

EIP 7623의 공동 저자인 Toni Wahrstätter는 Buterin의 의견에 동의하며 실용적인 관점에서 볼 때 대부분의 L2는 통화 데이터를 위한 2차 시장을 만들지 않을 것이라고 믿었습니다. "실용적인 관점에서 볼 때 이는 실현 가능성이 매우 낮습니다. 특히 이러한 시장에는 참가자 간의 신뢰와 높은 수준의 조정이 필요하다는 점을 고려하면 더욱 그렇습니다. L2로서 귀하의 데이터를 L1에 게시하고 싶지만 그렇지 않다고 상상해 보십시오. 어떤 주소가 데이터를 게시할지, 데이터가 어디에 저장될지 알 수 없습니다. 실용적인 관점에서 보면 색인 등을 사용자 정의해야 합니다.”라고 Wahrstätter는 말했습니다.

Reth 개발자 Georgios Konstantopoulos는 EIP 7623이 Pectra에 포함된 경우 개발자가 blobgas 제한을 늘릴 가능성을 조사하고 있는지 물었습니다. EIP 7623과 함께 제공되는 증가된 블롭 가스 제한 없이는 EIP가 "많은 문제를 해결하지 못한다"고 Konstantopoulos는 말했습니다. EF 연구원 Dankrad Feist는 이더리움의 최대 블록 크기가 변경되지 않는 지점까지 blob 가스 제한을 늘릴 것을 제안했습니다. 즉, 통화 데이터 비용이 증가함에 따라 확보된 공간이 blob(바이너리 대형 객체)으로 채워질 것임을 의미합니다. EF 연구원인 Ansgar Dietrichs는 이 EIP가 Blob Gas 제한의 증가와 결합될 때 유용할 뿐만 아니라 보안 관점에서도 네트워크가 최대 트랜잭션 및 Blob 수를 포함하는 블록의 영향을 받지 않도록 보장할 수 있다고 말했습니다. 그리고 불안정합니다.

EIP 7623이 스마트 계약 및 거래에 미치는 영향을 분석하는 문제와 관련하여 Wahrstätter는 자신이 제안한 제안이 98%의 사용자에게 영향을 미치지 않을 것이라고 말했습니다. Beiko는 또한 EF 개발자 운영 엔지니어인 Parithosh Jayanthi가 EIP 7623을 고려하여 블롭가스 한도를 높이는 세부 사항에 대해 심층 분석을 수행할 수도 있다고 언급했습니다.

EIP 7609의 새로운 대안

컨퍼런스 콜에서 '찰스 C'라는 닉네임을 가진 개발자는 스마트 계약의 재진입 공격을 방지하기 위한 새로운 EIP를 제안했습니다. Charles는 이 제안이 스마트 계약을 보호하기 위해 두 개의 새로운 opcode를 생성하고 Pectra에서 TLOAD/TSTORE의 기본 비용을 줄이는 것을 목표로 이전에 제출한 EIP 7609 제안에 대한 대안이라고 말했습니다. Charles는 EIP 7609가 Pectra에 포함되지 않은 이유를 확신하지 못하며 비용 효율적인 방식으로 재진입을 방지하는 방법에 대해 개발자로부터 피드백을 계속 수집하고 있다고 말했습니다. 그는 OpenZeppelin의 Reentrancy Guard 및 TLOAD/TSTORE opcode와 같은 현재 솔루션은 분산형 애플리케이션 개발자가 기본적으로 사용하기에는 너무 비용이 많이 든다고 지적했습니다. Beiko는 개발자들이 Ethereum Magicians 포럼에서 이 새로운 EIP에 대한 피드백을 Charles에게 제공할 것을 권장했습니다.