글쓴이: 크리스틴 김
작성: Luccy, BlockBeats
Pectra Devnet 0 준비 외에도 개발자들은 새로운 EIP 제안을 논의하고 기존 EIP를 분석하며 스마트 계약 및 거래에 미치는 영향을 분석했습니다. 특히 EIP 3074의 잠재적 대체재로 여겨지는 EIP 7702에 대한 논의가 큰 주목을 받았습니다.
갤럭시 디지털의 리서치 부사장인 크리스틴 김은 회의의 주요 내용을 자세히 기록했으며, 블록비스트는 이를 아래와 같이 번역했습니다.
2024년 5월 9일, 이더 개발자들이 줌(Zoom)에서 ACDE(All Core Developers Execution) 회의 #187에 모였습니다. ACDE 회의는 이더 재단의 프로토콜 지원 책임자인 팀 베이코(Tim Beiko)가 주최하는 격주 회의로, 개발자들이 이더 실행 계층(EL)의 변경 사항을 논의하고 조율하는 자리입니다. 이번 주 회의에서는 펙트라 데브넷 0(Pectra Devnet 0) 준비, EIP 3074 구현 업데이트, 그리고 EL의 직렬화 방식을 MPT에서 SSZ로 전환해야 하는 시급성에 대해 논의했습니다.
Pectra Devnet-0 업데이트
이더 재단 개발자 운영 엔지니어인 바나바스 부사는 그의 팀이 최초의 개발자 중심 테스트 네트워크인 펙트라(Pectra)의 클라이언트 구성을 테스트 중이며, 5월 13일 월요일까지 펙트라 데브넷 0(Pectra Devnet 0)의 안정적인 구성을 확보하기 위해 노력할 것이라고 밝혔습니다. 펙트라 데브넷 0 준비 현황 추적기에 따르면, Geth, Nethermind 및 EthereumJS 클라이언트 팀은 펙트라 코드 사양을 완벽하게 구현했습니다.
컨퍼런스 콜에서 Besu 개발자 Justine Florentine은 모든 Pectra EIP가 Besu에 구현되었지만, 그의 팀은 여전히 코드 디버깅 작업을 진행 중이라고 밝혔습니다. Erigon 개발자 Andrew Ashikhmin은 그의 팀이 EIP 7002(EL 트리거 가능 인출)를 제외한 모든 EIP 작업에 착수했다고 언급했습니다. Reth 팀은 Zoom 채팅에서 구현 진행 상황 추적기 링크를 공유하며, Erigon 팀과 마찬가지로 EIP 7002 작업이 아직 진행 중임을 보여주었습니다.
CL 클라이언트와 관련하여 Grandine 개발자 Saulius Grigaitis는 모든 EIP가 구현되었지만 EL 클라이언트 실행 시 몇 가지 버그가 발생했다고 밝혔습니다. Lighthouse 팀 관계자는 Pectra Devnet 0용 구현이 거의 완료 단계에 있으며 엔진 API 사양 업데이트가 필요하다고 언급했습니다. Teku 개발자 Mikhail Kalinin은 엔진 API 사양에 이러한 업데이트를 추가하는 작업을 진행 중이라고 밝혔습니다.
EF 테스트 팀의 마리오 베가스는 개발자들이 EIP 3074, AUTH 및 AUTHCALL 오퍼코드, 그리고 다른 여러 EIP에 대한 테스트 케이스를 추가하는 작업을 진행 중이라고 밝혔습니다.
EIP-3074 업데이트
개발자들은 EIP 3074를 Pectra Devnet 0 사양에 유지하기로 합의했지만, 대안으로 EIP 7702가 논의되었습니다. Geth 개발자 "Lightclient"는 EIP 3074 관련 최근 브레이크아웃 세션을 요약했는데, 참가자들은 Pectra 업그레이드에서 사용자 제어 계정의 프로그래밍 가능성을 개선하는 데 우선순위를 둘 변경 사항에 대해 논의했습니다. Lightclient에 따르면, 모든 참가자는 이더 에서 완전한 네이티브 계정 추상화가 구현되기까지는 아직 몇 년이 더 걸릴 것이라는 데 동의했습니다. 그러나 이것이 외부 소유 계정(EOA) 기능 변경을 우선시해야 한다는 것을 의미하는지, 아니면 EOA를 스마트 계약 지갑으로 마이그레이션해야 한다는 것을 의미하는지에 대해서는 의견 차이가 있었습니다. 이 ACDE 회의 하루 전인 5월 8일, 이더 공동 창립자 비탈릭 부테린은 이더 새로운 트랜잭션 유형을 지원하여 EOA가 단일 트랜잭션 내에서 스마트 계약 지갑처럼 작동할 수 있도록 하는 새로운 EIP인 EIP 7702를 제안했습니다. Lightclient는 EIP 3074 브레이크아웃 세션 참가자들이 EIP 7702에 대해 전반적으로 긍정적인 태도를 보였다고 밝혔습니다. 그러나 그는 EIP 7702와 관련하여 아직 해결해야 할 중요한 세부 사항들이 있다고 덧붙였습니다. 예를 들어, EIP 7702 거래를 취소하는 방법이나 이러한 거래의 가스 비용을 확장하는 방법 등에 대한 세부 사항은 여전히 불분명합니다.
EIP 7702가 승인되어 Pectra 업그레이드에 포함될 경우, EIP 3074를 대체하는 것으로 간주될 것입니다. 이는 EIP 7702가 EIP 3074와 유사한 결과를 달성하면서도 이더 에 새로운 오퍼레이션 코드를 생성하지 않고, 새로운 EOA 동작에 대한 정적 분석을 더욱 용이하게 하기 때문입니다. EF 연구원인 Ansgar Dietrichs는 Zoom 채팅에서 EIP 7702를 Pectra에 포함하는 것을 고려하고, EIP 3074를 대체할지 여부에 대한 공식적인 결정을 약 2~4주 내에 내릴 것을 제안했습니다. 컨퍼런스 콜에서 개발자들이 EIP 7702에 대해 논의한 내용을 보면, 이 제안이 구현 준비가 되었다고 간주되기 전에 추가적인 작업이 필요하다는 것을 알 수 있습니다. Nethermind 개발자인 Ahmad Mazen Bitar는 EIP 3074를 위해 이미 수행된 작업이 7702 구현에 재사용될 가능성은 낮다고 지적했습니다. Beiko는 개발자들이 Devnet 0에 대해서는 EIP 3074 구현을 계속하고, Devnet-1 사양은 나중에 다시 검토해야 한다고 확인했습니다.
EIP-7685, SSZ 및 EIP-6110
이어서 개발자들은 Nimbus 개발자인 Etan Kissling이 제기한 EIP 7685 관련 우려 사항, 특히 일반 실행 계층 요청에 대해 논의했습니다. Kissling은 이번 주 컨퍼런스 콜 의제에 대한 GitHub 댓글에서 일반 실행 계층 요청에 대한 제안된 설계가 필요한지, 그리고 이 기회를 활용하여 병합 업그레이드 이후 개발자들이 실행 계층에서 업데이트하기를 원했던 직렬화 형식인 SSZ로 전환하는 것이 더 나은지 질문했습니다. 컨퍼런스 콜에 참여한 대부분의 실행 계층 클라이언트 팀은 Pectra에서 EIP 7685를 유지하는 것을 지지했지만, 클라이언트의 낙관적 동기화와 같이 운영에 EIP를 포함하는 데 문제가 발생할 경우 설계를 재검토할 것을 제안했습니다.
SSZ로의 전환과 관련하여 키슬링은 일반 실행 계층 요청에 대한 새로운 설계 형식이 기존 직렬화 형식인 MPT와 RLP를 기반으로 하므로 개발자가 SSZ로 전환할 때 업데이트해야 한다고 설명했습니다. 그는 SSZ로의 전환을 미루면 개발자들이 계속해서 새로운 MPT/RLP 데이터 구조를 만들어야 하므로 오히려 작업량이 늘어날 뿐이라고 지적했습니다. 그러나 실행 계층 클라이언트 팀은 Pectra에 SSZ의 안정적인 컨테이너인 EIP 7495를 포함하는 것에 대해 강력한 지지를 보이지 않았습니다. "더스틴"이라는 개발자는 Zoom 채팅에서 SSZ 전환을 연기하기로 한 결정은 "미친 짓"이며, 실행 계층에서 SSZ 라이브러리가 제대로 작동하지 않는 문제는 "심각한 문제"라고 언급했습니다.
EIP 6110과 관련하여 온체인 공급 검증자 예치금에 대해 키슬링은 예치 순서 에 대한 의문을 제기했습니다. 칼리닌은 이것이 "중대한 우려 사항"이라는 데 동의하며 주요 스테이킹 풀과 협력하여 보다 심층적인 조사를 진행하겠다고 밝혔습니다.
EOF 업데이트
이더 프로토콜 독립 개발자인 다노 페린과 EF 솔리디티 연구 책임자인 알렉스 베레그자시는 EOF 구현에 대한 업데이트를 공유했습니다. EOF는 이더 가상 머신(EVM)을 개선하는 일련의 코드 변경 사항이며, 개발자들은 이를 펙트라(Pectra) 업그레이드에 통합하는 것을 고려하고 있습니다. EOF의 메타 EIP는 최종 확정되었습니다. 또한 개발자들은 EOF에서 트랜잭션 생성 프로세스를 간소화했으며, EOF의 클라이언트 측 구현을 진행하고 있습니다.
EIP-7623 업데이트
컨퍼런스 콜에서 "윌리엄 모리스"라는 닉네임을 사용하는 개발자는 EIP 7623에서 콜데이터 저장에 대한 가스 비용 변경 사항에 대해 우려를 제기했습니다. 그는 이러한 변경으로 일부 사용자가 거래를 통합하여 더 낮은 가격으로 거래할 수 있게 되고, 결과적으로 가스 할인을 위한 유통시장 형성되어 레이어 2 롤업(L2) 및 기타 참여자들이 네트워크에서 더 저렴하게 거래할 수 있게 될 것이라고 설명했습니다. 그는 콜데이터 비용을 고정된 비율로 인상하는 대안 EIP인 EIP 7703을 제안했습니다.
부테린은 모리스의 우려가 타당하지만, EIP 7623으로 인해 콜데이터의 유통시장 형성될 가능성은 실제로 낮다고 밝혔습니다. 그러한 시장에 참여하려는 사용자 수가 극히 제한적일 것이기 때문입니다. 부테린은 EIP 7623의 주요 영향을 받는 참여자는 레이어 2 개발팀인 스타크웨어(Starkware)와 인스크립션) 제작자라고 지적했습니다. 그는 콜데이터 2차 시장의 전체 규모는 작지만, 콜데이터를 통해 최대 블록 크기 제한을 늘릴 수 있는 잠재력은 매우 크다고 덧붙였습니다. 이는 개발자들이 블롭 가스 한도를 늘려 이더 의 레이어 2 지원 능력을 확장할 수 있도록 해주기 때문입니다. 비탈릭은 모리스가 지적했듯이, 콜데이터 비용의 완만한 증가가 현재의 EIP보다 레이어 2 및 기타 이해관계자들에게 더 심각한 영향을 미칠 것이라고 언급했습니다. 부테린은 컨퍼런스 콜에 앞서 블로그 게시물을 통해 블롭 가스 가격 책정에 대한 자신의 생각을 더 자세히 공유했습니다.
EIP 7623의 공동 저자인 토니 바르슈타터는 부테린의 의견 관점 동의하며, 대부분의 L2 서버가 실질적인 관점에서 통화 데이터에 대한 유통시장 만들지는 않을 것이라고 밝혔습니다. 바르슈타터는 "실질적으로, 특히 그러한 시장은 참여자 간의 신뢰와 높은 수준의 협력이 필요하다는 점을 고려할 때, 실현 가능성이 매우 낮습니다. L2 서버 입장에서 데이터를 L1 서버에 게시하고 싶다고 가정해 보세요. 하지만 어떤 주소가 데이터를 게시할지, 데이터가 최종적으로 어디에 도달할지 알 수 없습니다. 실질적으로는 맞춤형 인덱스 등이 필요합니다. 따라서 실현 가능성이 매우 낮다고 생각합니다."라고 말했습니다.
Reth 개발자인 Georgios Konstantopoulos는 EIP 7623이 Pectra에 통합될 경우 블롭 가스 한도를 늘리는 방안을 검토하고 있는지 질문했습니다. Konstantopoulos는 EIP 7623과 함께 블롭 가스 한도가 증가하지 않으면 EIP가 "많은 문제를 해결하지 못할 것"이라고 말했습니다. EF 연구원인 Dankrad Feist는 블롭 가스 한도를 이더 최대 블록 크기 수준으로 늘리는 것을 제안했습니다. 이는 calldata 비용 증가로 확보되는 공간을 블롭(대형 바이너리 객체)으로 채우는 것을 의미합니다. EF 연구원인 Ansgar Dietrichs는 EIP가 블롭 가스 한도 증가와 결합될 때 유용할 뿐만 아니라 보안 관점에서도 유용하다고 언급했습니다. 최대 트랜잭션 및 블롭 수를 포함하는 블록으로 인해 네트워크가 불안정해지는 것을 방지할 수 있기 때문입니다.
EIP 7623이 스마트 계약 및 거래에 미치는 영향 분석과 관련하여 Wahrstätter는 자신의 제안이 사용자 98%에게는 영향을 미치지 않을 것이라고 밝혔습니다. Beiko는 또한 EF 개발자 운영 엔지니어인 Parithosh Jayanthi가 EIP 7623을 고려하여 blobgas 제한이 구체적으로 어느 정도 증가할지에 대한 심층 분석을 진행할 수 있다고 언급했습니다.
EIP 7609의 새로운 대안
컨퍼런스 콜에서 "Charles C"라는 닉네임을 사용하는 개발자가 스마트 계약의 재진입 공격을 방지하기 위한 새로운 EIP(이더리움 혁신 계획)를 제안했습니다. Charles는 이 제안이 스마트 계약 보호를 위한 두 개의 새로운 오퍼코드를 생성하며, 이전에 제출했던 EIP 7609의 대안이라고 설명했습니다. EIP 7609는 Pectra에서 TLOAD/TSTORE 오퍼코드의 기본 비용을 줄이는 것을 목표로 했습니다. Charles는 EIP 7609가 Pectra에 포함되지 않은 이유를 알 수 없으며, 재진입 공격을 방지하는 비용 효율적인 방법에 대해 개발자들의 의견을 계속 수렴하고 있다고 밝혔습니다. 그는 OpenZeppelin의 Reentrancy Guard나 TLOAD/TSTORE 오퍼코드와 같은 기존 솔루션은 탈중앙화 애플리케이션 개발자들이 기본적으로 사용하기에는 비용이 너무 많이 든다고 지적했습니다. Beiko는 개발자들이 이 새로운 EIP에 대한 의견을 이더 Magicians 포럼에서 Charles에게 전달할 것을 제안했습니다.
