이더리움 핵심 개발자 최신 회의 요약: EIP 3074 제거에 동의, EIP 7702 포함

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

편집자 주：
이더리움 모든 핵심 개발자 합의 전화(ACDE)는 2주마다 열리며, 주로 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번은 ACDE 제 188차 전화 회의로, 개발자들은 이더리움 실행 계층의 변화에 대해 논의하고 조정했습니다.

회의에서는 새로운 실행 API 기능 추가, Geth의 최소 우선 수수료 요구 사항, Pectra 개발 네트워크 0 및 1에 대한 논의, Pectra 분기 범위 및 역사 기록 만료 등 많은 중요한 주제를 다루었습니다. 개발자들은 이러한 주제에 대해 심도 있는 논의와 교류를 진행했으며, Pectra 업그레이드의 범위, 일정 및 구체적인 실행 세부 사항에 대해 일부 합의에 도달했습니다.

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

2024년 5월 23일, 이더리움 개발자들은 Zoom에 모여 All Core Developers Execution (ACDE) call #188 회의에 참석했습니다. ACDE 전화 회의는 이더리움 재단 프로토콜 지원 책임자 Tim Beiko가 주재하는 2주마다 열리는 일련의 회의로, 개발자들은 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번 주 개발자들은 다음 내용을 논의했습니다:

• 실행 API에 새로운 기능 추가, 사용자가 거래의 '반환 데이터'(returndata)에 접근할 수 있도록
• Geth의 최소 우선 수수료 요구 사항
• Pectra Devnet 0 및 1
• Pectra 분기의 범위
• Portal Network의 역사 데이터 만료 통합.

· 그들은 Pectra Devnet 0에서 EIP 3074를 제거하고, 다음 개발자 중심의 Pectra 업그레이드 테스트넷 Pectra Devnet 1에 EIP 7702를 포함하기로 합의했습니다.

거래 영수증에 반환 데이터(returndata) 추가

스마트 계약 프로그래밍 언어 Vyper의 개발자 Charles Cooper는 실행 API의 한 엔드포인트를 조정하여 사용자가 거래 영수증을 받을 때 거래의 반환 데이터(returndata)도 받을 수 있도록 해야 한다고 제안했습니다. Cooper는 현재 개발자들이 반환 데이터를 얻는 일반적인 방법인 거래 추적이 표준화되지 않았고 모든 클라이언트에서 보편적으로 지원되지 않는다고 설명했습니다. Reth 등 클라이언트 팀의 피드백에 따르면, Cooper는 거래의 반환 데이터(returndata)를 얻기 위해 실행 API에 새로운 엔드포인트를 생성하는 또 다른 해결책을 제시했습니다. 개발자들은 전화 회의에서 이 제안에 대해 합의에 도달하지 못했습니다. Beiko는 개발자들이 GitHub에서 계속 논의하고 회의 외부에서 비동기적으로 이 문제를 해결하도록 시도할 것을 제안했습니다.

최소 채굴자 수수료 요구 사항

이후 Geth 개발자 Péter Szilágyi는 최근 몇 주 동안 사용자들이 Geth 클라이언트의 기본 설정에 대해 우려하고 있다고 제기했습니다. EIP 1559가 시행된 이후 Geth 클라이언트는 항상 거래의 기본 최소 우선 수수료 요구 사항을 강제하고 있습니다. 합병 이후 기본 1 gwei 우선 수수료가 제대로 작동하지 않았으며, 최근에야 Szilágyi의 팀이 이를 발견하고 수정했습니다. 이 기본 설정이 복원된 후, 사용자들은 발견했습니다 Geth 클라이언트를 사용하여 생성된 블록이 다른 블록보다 훨씬 비어 있는 것을, 거의 우선 수수료가 없는 거래를 제외했기 때문입니다. 이는 기본 설정이 블록 제안자와 생성자 동적에 부정적인 영향을 미칠 수 있다는 우려를 불러일으켰습니다. 이는 우선 수수료가 없는 유효 거래의 지연 처리를 초래할 수 있습니다.

Nethermind 개발자 Tomasz K. Sta ń czak는 Geth의 기본 최소 우선 수수료 요구 사항이 중요하지 않은 문제라고 말하며, 프로토콜 개발자들이 이를 표준화하거나 강제하려고 해서는 안 된다고 주장했습니다. EF 연구원 Ansgar Dietrichs는 현재 이더리움의 거래 기본 수수료가 매우 낮기 때문에 기본 최소 우선 수수료를 낮추는 것을 제안했습니다. 다른 개발자들은 Geth의 기본 최소 우선 수수료를 고정 금액이 아닌 기본 수수료의 일정 비율로 설정할 것을 제안했습니다. 그러나 Beiko는 이에 반대하며, 우선 수수료는 거래가 블록에 포함되는 비용으로 사용되어서는 안 된다고 주장했습니다. 이는 거래가 다음 블록에 포함되도록 우선 보장하기 위해서만 사용되어야 하며, 기본 수수료의 변동에 따라 설정된 기본 최소 우선 수수료는 기본 수수료의 변화를 왜곡할 수 있다고 덧붙였습니다.

Beiko는 논의의 또 다른 관점은 어떻게 생성자들이 제로 수수료 블록을 생성하고 제안자에게 외부 지불을 보상으로 제공하도록 장려할 것인지에 대한 것이라고 추가했습니다. 이러한 상황은 기본 최소 우선 수수료 요구 사항이 있든 없든 발생할 수 있지만, 기본값을 설정하는 것은 생성자들이 제로 수수료 블록을 생성하지 않도록 장려하는 규범을 형성할 수 있습니다. Szilágyi는 어떤 의미에서 생성자들이 블록에 제로 수수료 거래를 포함해야 하는지에 대한 것이 철학적 문제라고 말했습니다. 네트워크 관점에서 이러한 거래는 유효하므로 블록에 포함되어야 합니다. 그러나 재정적 동기에서 제안자의 관점에서는 제로 수수료 거래를 블록에 포함하는 것이 경제적 이익이 없으므로 포함되어서는 안 됩니다.

개발자들은 Geth 팀이 그들이 가장 좋다고 생각하는 기본값을 설정해야 한다고 일반적으로 동의했습니다. 검증 노드 운영자는 이 기본값을 자유롭게 변경할 수 있으며, 원한다면 다른 실행 계층 클라이언트를 사용할 수 있습니다.

Pectra Devnet -0

이더리움 재단(EF) 개발자 운영 엔지니어 Parithosh Jayanthi는 Pectra 개발 네트워크의 상황을 업데이트했습니다. 첫 번째 개발 네트워크는 지난주 케냐에서 열린 Nyota Interop 이더리움 프로토콜 개발자 오프라인 모임에서 시작되었습니다. Jayanthi는 개발 네트워크가 모든 실행 계층 및 합의 계층 클라이언트를 포함한다고 말했습니다. 그러나 EIP 3074는 집중 테스트가 이루어지지 않았으며 수정해야 할 버그가 존재합니다. 클라이언트 팀은 두 번째 개발 네트워크 Pectra Devnet 1의 출범을 준비하고 있으며, 이는 EIP 2935 구현의 변경 사항을 포함할 것입니다.

Pectra 범위 변경

개발자들은 이후 Pectra 업그레이드 범위의 변화에 대해 논의했습니다. 독립 이더리움 프로토콜 개발자 Danno Ferrin, Reth 개발자 Georgios Konstantopoulos 및 Solidity 팀의 대표들은 Pectra에 EOF를 포함하는 것을 지지했습니다. Geth 개발자 Marius van der Wijden은 그가 EOF 표준을 구현하고 있다고 밝혔습니다. 그러나 그는 EOF의 복잡성으로 인해 EOF를 포함하는 것이 Pectra 업그레이드의 활성화를 확실히 지연시킬 것이라고 강조했습니다. Lodestar 및 EthereumJS 개발자 Gajin der Singh은 Zoom 채팅에서 개발자들이 Pectra의 현재 버전을 출시하는 데 집중해야 하며, 업그레이드 범위를 확대하는 것에 집중해서는 안 된다고 언급했습니다. EF 연구원 Alex Stokes와 Piper Merriam도 Singh의 의견에 동의했습니다.

EOF에 대한 논의 후, 개발자들은 EIP 7702의 진행 상황에 대해 논의했습니다. EIP 7702는 이더리움 공동 창립자 Vitalik Buterin이 EIP 3074의 대안으로 제안했습니다. EIP 7702의 중요한 세부 사항인 그 가역적 설계는 여전히 해결되지 않았습니다. 'dror'라는 이름의 개발자는 Zoom 채팅에서 "EIP 7002는 EIP 3074의 한 버전으로, 이전에는 nonce와 체인 ID(chainID)가 있는 버전만 수용되었습니다. 이제 이들이 제거되었으므로 우리는 이러한 제한에 대한 이유를 다시 논의해야 합니다. 저는 이러한 제한에 대한 논의를 다시 시작할 것을 제안합니다."라고 썼습니다. Besu 개발자 Daniel Lehrner는 지갑 개발자에게 EIP 7702 설계에 대한 더 많은 의견을 요청할 것을 제안했습니다. Erigon 개발자 Andrew Ashikhmin은 사용자가 지갑을 우회하여 권한을 철회할 수 있는 방법이 필요하다고 강조했습니다.

Beiko는 EIP 7002의 실행 세부 사항에 대해 별도의 소그룹 회의에서 계속 논의할 것을 제안했습니다. 동시에 개발자들은 Devnet 0에서 EIP 3074를 제거하고 Devnet 1에 EIP 7702를 추가하기로 합의했습니다.

Pectra에 추가될 계획인 다른 두 개의 EIP는 EIP 7623(칼ldata 비용 증가)와 EIP 7212( secp256 r1 곡선의 프리컴파일 지원)입니다. EF 연구원 Toni Wahrstätter는 EIP 7623의 최신 진행 상황을 공유했으며, 스마트 계약 지갑 개발자 Ulaş Erdoğan은 EIP 7212의 최신 진행 상황을 공유했습니다. 개발자들은 이 두 EIP가 Pectra에 포함되어야 하는지에 대해 합의에 도달하지 못했습니다.

Pectra 일정 예상

Konstantopoulos는 개발자들이 이더리움 메인넷에서 Pectra 업그레이드를 언제 활성화해야 하는지에 대해 언급했습니다. 통화 전에 공유된 문서에서 Reth 클라이언트 팀은 2024년 말까지 업그레이드를 시도하는 것이 "가치가 크지 않다"고 작성했으며, 개발자들은 2025년 초에 업그레이드를 출시할 준비를 해야 한다고 밝혔습니다. EF Panda Ops 팀(EF 개발자 운영 팀의 하위 집단)도 통화 전에 문서를 공유하며 Pectra 일정과 범위에 대한 그들의 의견을 표현했습니다. 그들은 Pectra를 두 개의 분기로 나누어 하나는 올해 활성화하고, 다른 하나는 MaxEB, EOF 및 가능성 있는 peerDAS를 포함하여 내년 초에 활성화할 것을 제안했습니다. Jayanthi는 EF Panda Ops 팀이 의견이 일치하지 않지만, 개인적으로 Pectra의 범위를 두 개의 분기로 나누어야 한다고 생각한다고 밝혔습니다. 그는 Pectra 업그레이드의 엣지 케이스와 EIP 상호작용이 아직 테스트되지 않았다고 지적했습니다.

EF Solidity 개발자 Alex Beregszaszi는 만약 EOF가 Pectra에 포함되지 않는다면 이러한 코드 변경이 이더리움의 업그레이드에 영원히 포함되지 않을 것이라는 우려를 표명했습니다. Geth 개발자 Marius van der Wijden과 Guillaume Ballet는 이에 반대하며, EOF의 이점이 충분히 뚜렷하므로 몇 개의 분기가 더 지연되더라도 그 유용성은 여전히 존재한다고 주장했습니다.

Beiko는 먼저 peerDAS와 blob 크기 증가를 어떻게 우선 처리할 것인지에 대해 합의한 다음, 업그레이드의 나머지 범위를 결정할 것을 제안했습니다. 그는 다음 주 All Core Developers Consensus (ACDC) 회의에 참석할 개발자들이 이 주제에 대해 집중적으로 논의할 것을 희망했습니다. 그는 개발자들이 다음 ACDE 회의에서 Pectra의 범위를 최종 확정할 준비를 하기를 바랐습니다.

Portal Network 및 역사 만료

마지막으로 Merriam은 Portal Network 팀이 Pectra와 병행하여 역사 만료 버전을 출시하기 위해 프로토콜 개발자와 협력할 준비가 되었다고 언급했습니다. Portal Network에 대한 더 많은 정보는 여기에서 확인할 수 있습니다.