저자: shew
개요
가장 복잡한 거버넌스 분쟁은 Pectra 업그레이드 중에 발생했습니다. EIP3074가 Pectra 업그레이드에 포함되었을 때, 특히 ERC4337 팀의 반대에 부딪히면서 엄청난 논란이 일어났습니다.
EIP3074에 문제가 생겨 거버넌스 프로세스를 계속할 수 없습니다. 비탈릭이 EIP7702를 제안한 후에야 ERC4337 팀은 EIP3074에 대한 의심을 끝냈습니다.
GCC Research에서는 Pectra 업그레이드에서 EIP3074와 ERC7702의 거버넌스 문제가 중국 내에서는 거의 논의되지 않았다는 사실을 발견했습니다. 하지만 이러한 거버넌스 문제는 이더리움 거버넌스의 더 근본적인 문제를 반영하기도 합니다. 즉, 코드가 법이라는 전제 하에 누가 코드의 구체적인 내용을 통제할 수 있느냐는 것입니다. EIP3074와 ERC7702의 거버넌스 문제는 이더리움 내부의 실제 거버넌스 과정을 관찰하는 데 좋은 관점을 제공할 수 있습니다.
본 기사의 최종 결론은 ZeroDev가 게시한 논평 기사에서 발췌한 것으로, 이더리움 거버넌스 시스템은 VVRC 모델이라고 지적하고 있습니다. 어떠한 제안이라도 포함하려면 먼저 이더리움의 가치(Value)를 준수해야 하고, 그 다음 제안은 비탈릭이 설계한 비전(Vision)에 반영되어야 하며, 마지막으로 제안은 로드맵(Roadmap)에 반영되어야 하며, 마지막으로 핵심 개발자들이 논의하여 클라이언트(Client) 구현에 통합하게 됩니다.
이전 기사에서 GCC Research가 도입한 EIP2537은 클라이언트 수준의 구현 문제로 인해 하드 포크에 포함되는 것이 지연되었고, EIP3074는 비전 및 로드맵 문제로 인해 하드 포크에 포함되지 않았습니다. 이더리움 코어 개발자들은 Vitalik이 작성한 EIP7702를 최종 계정 추상화 제안으로 직접 선택했습니다.
제안 내용 개요
구체적인 거버넌스 프로세스를 소개하기에 앞서, 본 기사에 포함된 EIP3074, EIP7702, ERC4337의 구체적인 내용을 간략하게 소개하겠습니다.
EIP3074는 실행 계층 제안이며, 이를 실행하려면 노드 소프트웨어 업그레이드가 필요합니다. EIP3074의 핵심 목적은 가스 후원 및 일괄 거래 기능을 구현하는 것입니다. 소위 가스 스폰서링은 사용자가 토큰을 사용하여 가스 요금을 지불할 수 있거나, 사용자가 오프라인으로 가스 요금을 지불할 수 있음을 의미합니다. 그러나 서명 검증 알고리즘의 변경을 허용하는 다른 계정 추상화 제안과 비교했을 때 EIP3074는 사용자가 secp256k1 이외의 다른 서명 알고리즘을 사용하는 것을 허용하지 않는다는 점에 유의해야 합니다. 즉, EIP3074는 모든 계정 추상화 기능을 만족하는 제안이 아니다. EIP3074도 이 점에서 비판을 받았습니다.
의도한 목표를 달성하기 위해 EIP3074는 AUTH와 AUTHCALL이라는 두 가지 명령어를 도입했습니다. AUTH 명령어는 서명을 검증할 수 있습니다. 서명 검증을 통과하면, opcode는 현재 EVM 컨텍스트에서 권한을 서명자의 주소로 구성합니다. AUTHCALL은 컨텍스트에서 권한을 구성한 후 권한 있는 주소를 호출 트랜잭션의 msg.sender로 사용하여 트랜잭션을 시작할 수 있습니다. 어느 정도까지 사용자는 서명을 통해 거래에 사용할 스마트 계약에 자신의 계정을 맡길 수 있습니다. 일반적으로 사용자가 위탁한 이러한 스마트 계약을 호출자 계약이라고 합니다.
사용자 서명의 구체적인 내용은 무엇입니까? 사용자는 다음에 서명해야 합니다.
위 내용의 호출자 주소는 사용자가 위임하고자 하는 호출자 계약 주소를 나타냅니다. EVM은 사용자의 서명 내용이 실제로 서명을 검증하는 계약과 일치하는지 확인하여 사용자의 AUTH 서명 내용이 다른 계약에서 사용되는 것을 방지합니다.
nonce는 거래 재실행을 방지하는 식별자입니다. 그러나 AUTH 명령어는 서명의 nonce가 현재 서명된 EOA의 nonce와 일치하는지 여부를 검증한다는 점에 유의해야 합니다. 이론상, 사용자가 EOA 계정을 사용하여 nonce 값을 늘리는 거래를 시작하지 않는 한, 사용자가 발급한 AUTH 서명은 항상 호출자 계약에서 사용될 수 있습니다. 이는 심각한 보안 취약점이며, EIP3074를 사용하는 사용자는 서명을 얻은 릴레이 서비스 제공자를 신뢰해야 함을 의미합니다. 사용자의 서명을 얻은 릴레이 서비스 제공자가 악의적인 경우, 서비스 제공자는 특정 시간에 사용자의 AUTH 서명을 다시 사용하여 사용자의 자산을 훔칠 수 있습니다.
또 다른 보안 문제는 커밋 필드입니다. 커밋 필드는 특정 작업을 보장하는 데 사용됩니다. 사용자는 커밋에서 서명 권한을 세부적으로 제어할 수 있습니다. 예를 들어, 커밋에 일부 내용을 작성하여 서명 내용이 ETH 전송에 사용되는 것을 방지할 수 있습니다. EIP3074 문서에서 제안자는 커밋 필드를 사용하는 일련의 예를 제시했습니다. 하지만 문제는 commit의 역할이 전적으로 스마트 계약의 정의에 따라 달라지며 본질적으로 선택 사항이라는 것입니다. 다양한 스마트 계약은 커밋의 내용을 완전히 다르게 해석할 수 있으며, 일부 계약은 커밋의 내용을 전혀 읽지 않을 수도 있습니다. 사용자가 EIP3074를 안전하게 사용하려면 스마트 계약을 직접 검토하기만 하면 됩니다.
마지막으로 EIP3074가 현재 이더리움 거래 메모리 풀에 미치는 영향을 소개합니다. EIP3074가 도입된 이후 메모리 풀을 공격하는 방법이 등장할 수도 있습니다. 해커는 많은 수의 계정을 이용해 거래를 시작한 다음, EIP3074 거래를 사용해 거래가 패키징되기 직전에 해당 계정의 ETH를 한꺼번에 빼낼 수 있습니다. 이렇게 되면 이전에 시작된 모든 거래가 실패하게 됩니다. 이러한 유형의 공격은 실행 계층 노드에 상당한 영향을 미치며 본질적으로 DoS 공격입니다. 하지만 EIP3074를 대체하는 EIP7702에도 이 문제가 있는데, EIP7702는 이 문제를 피하기 위해 몇 가지 제한을 도입했습니다. 이에 대해서는 나중에 설명하겠습니다.
위에서 언급한 EIP3074 자체의 문제 외에도, ERC4337의 저자인 요바는 EIP-3074 포함의 의미에 대한 기사에서 더 많은 반대 의견을 제시했습니다. 간단히 말해서, 이러한 의견에는 주로 다음이 포함됩니다.
- 중앙집중화 위험. AUTH 서명의 특수한 속성으로 인해 사용자는 EIP3074 릴레이 서비스 제공자와 기반 인프라를 완전히 신뢰해야 합니다. 동시에 ERC4337과 같은 계정 추상화 프로토콜로 구축된 인프라는 EIP3074와 전혀 호환되지 않습니다.
- 사용자 보안. 앞서 언급했듯이 EIP3074에는 통일된 권한 제어 방식이 없으며, 서명 nonce 설계에도 보안 위험이 있어 심각한 보안 문제로 이어질 가능성이 높습니다.
- 계정 추상화 기능이 불완전합니다. 다른 계정 추상화 제안과 비교했을 때 EIP3074는 완전하지 않으며 사용자 서명 알고리즘을 변경하는 등의 기능을 구현할 수 없습니다.
- 사용자 경험에 문제가 있습니다. 사용자가 자신의 계정을 스마트 계약에 위임해야 하는 경우, 사용자는 AUTH 서명을 수행한 다음 AUTH 서명이 포함된 호출을 체인에 게시해야 합니다. 사용자는 두 번 서명해야 합니다.
EIP7702는 Vitalik이 EIP3074를 대체하기 위해 제안한 것입니다. 이 제안에서는 새로운 EVM 명령어를 도입하는 대신 SET_CODE_TX_TYPE이라는 새로운 트랜잭션 유형을 도입합니다. 사용자가 EIP7702 유형 거래를 시작하면 사용자는 EOA의 기본 기능을 유지하면서 자신의 EOA에 스마트 계약 기능을 추가할 수 있습니다. 간단히 말해서, 사용자는 MetaMask와 같은 지갑을 계속 사용하여 거래를 시작할 수 있고, 다른 사용자는 스마트 계약 형태로 EOA 주소를 호출할 수 있습니다.
간단한 일괄 거래 예제를 통해 EIP7702의 기능을 소개합니다. 사용자는 EIP7702를 사용하여 일괄 호출을 실행할 수 있는 스마트 계약에 EOA 주소를 위탁할 수 있으며, 이후 사용자는 스마트 계약 형태로 EOA 주소를 직접 호출하여 일괄 거래를 시작할 수 있습니다.
기술적 구현 관점에서 볼 때, EIP7702에서 도입된 거래 유형은 기존 거래에 비해 permission_list 목록을 추가합니다. 목록의 구체적인 내용은 [[chain_id, address, nonce, y_parity, r, s], ...]입니다. 여기서 address는 사용자가 위임하고자 하는 스마트 계약 주소이고, nonce는 사용자의 현재 nonce 값입니다. 나머지 y_parity, r, s는 사용자의 서명 결과입니다. 구체적인 실행 프로세스에서는 먼저 처리를 위해 permission_list의 각 항목을 탐색합니다. 처리 방법은 y_parity 등의 서명 매개변수를 통해 EOA 주소를 복원한 후, EOA 주소를 address 주소가 있는 스마트 계약으로 가리키는 것입니다. 그 후, EOA 주소는 계약 기능을 수행하기 위한 호출을 수락할 수 있습니다.
EIP7702의 장점은 매우 명확하며, 가장 핵심적인 장점은 EIP7702를 통해 본질적으로 EOA가 스마트 계약 기능을 가질 수 있다는 것입니다. 이는 ERC4337과 같은 계정 추상화의 기본 규칙과 일치하므로 EIP7702는 계정 추상화 분야의 모든 현재 탐색을 활용하고 기존 인프라를 재사용할 수 있습니다. 예를 들어, EIP7702는 ERC4337의 인프라를 직접 사용할 수 있습니다. 현재 ERC4337은 EIP7702 호출을 지원하는 EntryPoint v0.8을 출시했습니다. 기존 인프라를 재활용한다는 관점에서 볼 때, EIP7702와 ERC4337은 동일한 수준의 분산화를 이룹니다.
물론, EIP7702는 실제로 EIP3074에서 발생한 문제를 완전히 해결하지는 못합니다. EIP3074의 대부분의 문제는 여전히 존재합니다. EIP7702는 계정 계약이 안전하게 구현되도록 요구하지만, 프로토콜 자체는 어떠한 보안도 보장하지 않습니다. EIP7702 초창기에는 일부 개발자가 재생 공격을 방지하기 위해 서명 nonce를 표준화할 것을 제안했지만, EIP7702는 궁극적으로 이러한 제안을 수용하지 않았습니다. 따라서 사용자가 EIP7702를 안전하게 사용하려면 직접 계약의 보안성을 검토해야 합니다.
동시에 EIP7702는 실행 계층에 일련의 문제를 가져올 것입니다. 위에서 우리는 EIP3074를 사용하여 실행 계층 메모리 풀에 대한 DoS 공격을 수행하는 가능한 방법을 소개했습니다. 이러한 접근 방식은 EIP7702에도 유효합니다. 따라서 EIP7702에서는 대규모 DoS 공격을 방지하기 위해 EIP7702를 사용하는 모든 EOA 주소가 메모리 풀에 보류 중인 트랜잭션을 하나만 가질 수 있도록 권장합니다.
요약하자면, EIP3074의 가장 큰 문제는 완전한 계정 추상화 기능을 구현하지 않은 반면, EIP7702는 완전한 계정 추상화 기능을 구현한다는 것입니다. "완전한 계정 추상화"에 무엇이 포함되는지 정의한 사람은 ERC4337의 작성자입니다. 이 글을 읽고 나면 독자들은 EIP3074가 ERC4337 팀의 반대에 부딪혀 결국 EIP7702로 대체된 이유를 이해할 수 있을 것입니다. 전반적인 거버넌스와 논의의 전체 과정은 나중에 소개하겠습니다.
EIP3074 및 EIP7702의 거버넌스 프로세스
EIP3074는 이더리움 코어 개발자 회의에서 아주 일찍 언급되었습니다. 2021년 4월 2일 열린 109번째 회의에서 이더리움 핵심 개발자들은 EIP3074에 대해 간략하게 논의했습니다. 토론 내용은 매우 간단했습니다.
- 알렉세이는 EIP3074 서명 콘텐츠에 보안 위험이 있으며, 이로 인해 사용자에게 심각한 보안 손실이 발생할 수 있다고 주장했습니다. 그는 EIP3074가 AUTH 서명의 구체적인 내용을 더욱 표준화할 것을 제안했습니다. 마틴은 이 제안을 지지했습니다.
- James는 EIP3074가 DoS 공격과 같은 잠재적인 실행 계층 취약점을 가져올 수 있다고 제안했으며 EIP3074가 서면 위협 분석을 제공해야 한다고 제안했습니다.
- 알렉세이와 마틴은 EIP3074 문서의 품질이 평균적이지 않고 읽고 이해하는 데 시간이 많이 걸린다고 불평했습니다.
- 마틴은 EIP3074의 핵심은 애플리케이션, 특히 지갑 개발자와의 협력과 구현이라고 생각합니다. EIP3074의 작성자는 애플리케이션 개발자들과 일련의 교류를 가졌다고 말했습니다.
더욱 흥미로운 점은 비탈릭이 이 회의에서 이더리움이 EOA를 위해 설계된 하나의 거래에 대해 여러 개의 호출을 생성하는 기술적 솔루션이 필요하다고 생각했다는 것입니다. EIP3074에는 보안 문제가 있을 수 있지만, EIP3074는 가능한 기술적 해결책을 제공하며 개발자는 EIP3074를 기반으로 전진해야 합니다.
EIP3074의 보안 문제로 인해 이 회의에서는 런던 업그레이드에 EIP3074를 포함하지 않았습니다.
2021년 6월 11일 열린 115차 회의에서 EIP3074 개발자들은 보안 감사 보고서를 제출했으며, 회의에서는 주로 EIP3074의 보안 문제를 논의했습니다. 간단히 말해서 EIP3074 호출자 계약은 시스템에서 매우 중요하므로 호출자 계약을 관리해야 하는지 여부는 의문입니다. EIP3074 개발자들은 보안을 강화하기 위해 호출자 계약을 공식적으로 증명하고자 합니다.
물론, 호출 주소가 EOA인지 확인하기 위해 msg.sender == tx.origin을 사용하는 일부 계약에 대한 논의도 있습니다. EIP3074가 도입되면 이러한 판단은 무효화되지만, 이 판단의 일부가 실패하더라도 심각한 보안 문제가 발생하지는 않을 것이라는 결론이 나왔습니다. 간단히 말해, 이 회의는 주로 EIP3074 제안자가 핵심 개발자에게 3074의 보안 감사 결과를 소개하는 것이었습니다. 회의의 최종 결론은 3074가 여전히 호출자 계약 문제를 고려해야 하며, 런던 하드 포크에 이를 포함하지 않는 것이 좋다는 것이었습니다.
2021년 6월 25일 열린 116차 회의에서 ERC4337의 핵심 작성자인 요바는 "EIP 3074에 대한 보다 간단한 대안을 위한 사례"라는 제목의 자료를 제출했습니다. 이 자료에서는 EIP3074에 많은 보안 문제가 있다고 지적하고 서명의 커밋 필드 내용을 제한하고 커밋 필드가 {nonce, to, gas, calldata, value, chainid} 형식이어야 한다는 등 일부 내용을 수정할 것을 제안했습니다. 이 서명 모드를 사용하면 EIP3074는 특정 거래를 수행하는 데만 사용할 수 있으므로 거래의 보안을 보장할 수 있습니다.
EIP3074 작성자가 Yova의 제출에 응답한 회의는 다음과 같습니다.
- 호출자 계약 주소가 EIP 사양에 포함되고, 이를 통해 이더리움 핵심 개발자가 보안 문제를 피하기 위해 안전한 호출자 계약을 작성할 수 있기를 기대합니다.
- EIP3074 개발자는 서명의 커밋 내용과 관련하여 이는 전적으로 사용자와 지갑 소프트웨어의 문제이며 EIP에서 규제할 필요가 없다고 생각합니다.
비탈릭은 이 회의에서 다음의 세 가지 사항을 언급했습니다.
- EIP3074는 여전히 양자 저항을 달성할 수 없는 기존의 secp256k1 서명 방식을 사용합니다.
- EIP3074는 향후 호환성이 없으며 EIP3074를 사용해도 EOA를 스마트 계약 계정으로 전환할 수 없습니다.
- EIP3074는 수명이 제한되어 있습니다. EIP 3074는 AUTH와 AUTHCALL이라는 두 개의 사전 조립된 코드를 도입합니다. 그러나 계정 추상화 로드맵에 따르면 이더리움의 모든 지갑은 미래에 스마트 계약 지갑이 될 수 있으며, EIP 3074의 사전 조립된 코드는 앞으로 폐기될 것입니다.
2022년 2월 4일 회의 #131에서 개발자들은 상하이 업그레이드에 포함되어야 할 EIP 유형에 대해 논의했습니다. EIP3074는 논의에 포함되었지만, 개발자들은 단순히 EIP3074의 개발 역학을 동기화했습니다. 회의가 시작되기 전에 nethermind가 "오늘과 내일의 이더리움 지갑 - EIP-3074 대 ERC-4337"이라는 제목의 기사를 썼다는 점은 주목할 만합니다. 이 기사에는 EIP3074에 대한 반대 의견이 전혀 없었습니다.
2023년 8월 3일 회의 #167에서 핵심 개발자들은 또 다른 EIP5806을 논의하면서 EIP3074를 언급했습니다. EIP5806은 EOA가 트랜잭션 중에 대리자 호출을 사용하여 외부 계약을 호출할 수 있도록 하는 프로토콜입니다. 이 방식은 EIP7702와 다소 유사합니다. 그러나 핵심 개발자들은 이 계획의 보안에 의문을 제기하기도 했습니다. 안스가르는 EIP3074는 보안 문제로 인해 과거 하드 포크에 포함되지 않았으며, EIP5806은 더 급진적인 계획이라고 지적했습니다.
2024년 2월 29일 회의 #182에서 개발자들은 EIP3074를 Pectra 업그레이드에 포함해야 하는지에 대해 자세히 논의했습니다. Vitalik은 모든 계정 추상화 표준에는 다음 세 가지 기능이 있어야 한다고 제안했습니다.
- 키 회전
- 키 사용 중단
- 양자 저항 서명과 호환 가능
Vitalik은 EIP5806이 EIP3074보다 더 나은 선택일 수 있다고 지적했습니다. Andrew는 EIP3074가 EIP5806보다 다재다능하다고 생각하며 EIP3074를 사용할 것을 권장합니다. 비탈릭은 앤드류의 주장을 반박했고, 비탈릭은 미래의 모든 지갑은 스마트 계약 지갑이 될 것이라고 믿었습니다. 이런 일이 일어나면 EIP3074에서 도입한 사전 조립된 명령어는 무효화됩니다. ERC4337의 저자인 Yoav는 회의에서 주로 다음과 같은 내용을 담은 긴 연설을 했습니다.
- EIP3074는 이더리움 메모리 풀에 대한 DoS 공격으로 이어질 수 있으며, ERC4337은 이 부분에 대해 많은 연구를 수행했으며 공격을 피하기 위한 몇 가지 규칙을 제공했습니다.
- EIP3074는 일괄 거래를 시작할 때 사용자가 두 번 서명하도록 요구하는데 이는 불합리합니다.
- EIP3074는 중앙 집중식 릴레이 사용을 요구합니다.
Yova는 계정 추상화 솔루션으로 EIP5806을 사용하는 것을 선호합니다.
2024년 3월 14일 183번째 회의에서 핵심 개발자들은 MetaMask의 Dan Finlay를 초대하여 EIP3074에 대한 지갑의 견해를 논의했습니다. 댄은 EIP3074를 지지하며 MetaMask도 EIP3074 테스트를 지원할 것이라고 지적했습니다. MetaMask는 EIP3074를 통해 EOA가 계정 추상화의 모든 기능을 누릴 수 있다고 믿습니다. 보안 측면에서 EIP3074는 지갑 서비스 제공자에게 핫 키와 콜드 키를 분리하는 솔루션을 제공합니다. 지갑 서비스 제공자는 EOA의 EIP3074 서명을 보유하여 거래를 시작할 수 있습니다. 사용자는 일반 거래에서 핫 개인 키를 사용할 수 있지만, 콜드 개인 키는 사용자의 하드웨어 지갑에 저장할 수 있습니다. 비상 상황이 발생하면 사용자는 콜드 지갑에 있는 콜드 개인 키를 사용하여 EIP3074 서명을 철회하는 거래를 시작할 수 있습니다. 핫 개인 키와 콜드 개인 키를 분리하면 지갑 제공업체에 유연성이 제공됩니다.
Vitalik은 EIP3074 내에서 지갑 설계자는 사용자의 EIP3074 서명이 남용되는 것을 방지하기 위해 엄격한 권한 부여 논리를 설계해야 한다고 지적했습니다. 흥미롭게도, MetaMask가 EIP3074 기능을 추가하도록 지원하는 것에 대해 논의할 때, Vitalik은 L2가 과도기적 솔루션으로 사용될 수 있다고 지적했습니다. 즉, 새로운 실행 계층 수정 사항은 먼저 L2 내에서 구현해야 한다는 것입니다. L2에는 자금이 제한되어 있고 심각한 문제가 발생하더라도 심각한 손실이 발생할 수 있기 때문입니다.
Dror Tiros는 토론에서 EIP3074의 보안을 보장하는 가장 좋은 방법은 Ethereum 담당자가 호출자 계약을 직접 제공하는 것이라고 지적했습니다. 하지만 댄 핀레이는 이 계약에 대한 공식 의견에 반대했습니다. 댄은 호출자 계약은 전적으로 사용자에 의해 결정되어야 하며, 시장은 결국 가장 안전한 호출자 계약을 선택할 것이라고 믿었습니다.
Ansgar는 여전히 EIP3074는 한 번에 하나의 거래에만 대응해야 하며, 지갑 서비스 제공자는 사용자 서명을 재사용하여 거래를 시작해서는 안 된다고 주장하지만 Dan Finlay도 반대 의사를 표명했습니다. 댄 핀레이는 EIP3074가 콜드 월렛으로 서명되어야 하며, 그러면 월렛 서비스 제공자가 서명을 재사용하여 사용자를 위해 직접 거래를 시작할 수 있다고 생각합니다. 사용자가 매번 다시 서명해야 하는 경우 콜드 개인 키는 여러 번 사용될 수 있습니다. 이는 핫 개인 키와 콜드 개인 키를 분리한다는 아이디어와 일치하지 않습니다.
이번 회의에서 핵심 개발자들이 논의한 또 다른 중요한 주제는 포함 목록이었습니다. 포함 목록은 이더리움의 검열 저항성을 높이는 수단입니다. 간단히 말해서, 포함 목록을 사용하면 일부 거래가 다음 블록에 직접 포함되도록 커밋할 수 있습니다. 하지만 핵심 개발자들은 EIP3074가 포함 목록과 충돌한다고 지적했습니다.
2024년 4월 11일 185번째 회의에서 대부분의 클라이언트 구현은 Pectra 하드 포크에 EIP3074를 포함하기로 합의했지만 Geth는 EIP3074가 Verkle 트리에서 문제를 일으킬 수 있기 때문에 이에 반대했습니다. Danno는 EIP3074가 서명 재사용으로 이어질 수 있기 때문에 여전히 반대 의사를 표명했습니다. 요아브 역시 반대 의사를 표명했으며, 요아브는 EIP3074와 Blob 트랜잭션을 사용하여 메모리 풀을 공격하는 솔루션을 제안했습니다. 간단히 말해서, 공격자는 각각 많은 양의 데이터를 포함하는 수많은 Blob 트랜잭션을 시작한 다음 EIP3074를 사용하여 이러한 모든 Blob 트랜잭션을 무효화할 수 있습니다.
간단히 말해, 이 회의에서 모든 클라이언트 개발자는 EIP3074가 최종 업그레이드에 포함될 것에 동의했습니다.
2024년 5월 9일 회의 #187에서 핵심 개발자들은 EIP3074를 EIP7702로 대체하는 문제를 처음으로 논의했습니다. EIP7702는 핵심 개발자 회의가 시작되기 전 90분 안에 Vitalik이 완료했습니다. 회의에서 핵심 개발자들은 EIP7702가 EIP3074보다 우수한 표준이라는 것을 인식했습니다. 이번 회의에서는 EIP7702에 대한 반대는 없었지만, 일부 연구자들은 EIP7702도 EIP3074와 마찬가지로 취소 불가능한 속성을 가지고 있어 자금 보안 문제가 발생할 수 있다고 생각했습니다.
2024년 5월 23일 회의 #188에서 핵심 개발자들은 EIP3074를 EIP7702로 대체할 가능성에 대해 논의했습니다. 이 회의의 최종 결론은 Pectra 하드 포크의 계정 추상화 표준으로 EIP3074를 대체하여 EIP7702를 사용하는 것이었습니다. Vitalik은 EIP7702도 EIP3074와 일치하는 일부 돌이킬 수 없는 속성을 가지고 있다고 지적하며, 이는 EIP3074를 논의할 때 광범위하게 논의되었습니다. 더욱 흥미로운 점은 회의에서 많은 수의 ERC4337 대표들이 연설했다는 것입니다.
사실, EIP3074를 EIP7702로 대체하는 것에 대한 논의는 188차 핵심 개발자 회의 전부터 폭넓게 논의되었습니다. 당시 논의 결과는 3074를 대체하는 것으로 나왔기 때문에 코어 개발자 회의에서는 큰 논란이 없었습니다.
로드맵 및 판결
EIP3074가 교체될 것이라는 소식을 접한 후, 계정 추상화의 핵심 인프라인 Zerodev는 3074 사가 이후 이더리움 거버넌스에 대한 반성이라는 제목의 흥미로운 기사를 게시했습니다. 해당 기사는 EIP7702가 모든 사용자에게 이익이 되는 좋은 제안이라고 결론지었습니다. 그러나 EIP3074를 대체하는 EIP7702의 거버넌스 프로세스는 다음과 같은 이유로 최적이 아닙니다.
- EIP3074는 오랜 논의 과정을 거쳤습니다. 위에서 우리는 핵심 개발자 회의에서 EIP3074에 대한 다양한 논의를 소개했습니다.
- EIP3074가 Pectra 업그레이드에 포함되기로 결정된 후, ERC4337 커뮤니티로부터 많은 반대에 부딪혔습니다. 물론, 위에서 지적했듯이 ERC4337의 핵심 개발자인 요바(Yova)는 핵심 개발자 회의에서 EIP3074에 대한 반대 의사를 거듭 표명했습니다.
Zerodev는 ERC4337 커뮤니티가 폭넓게 참여하고 EIP3074의 긴 핵심 개발자 토론 과정 동안 의견을 표현하는 것이 가장 좋은 거버넌스 경로라고 생각합니다.
EIP3074 개발자들은 ERC4337이 거버넌스 실패에 대한 책임을 져야 한다고 생각합니다. EIP3074는 지난 몇 년 동안 거버넌스에 적극적으로 참여했고 ERC4337 핵심 개발자인 yova와 여러 차례 소통했습니다.
ERC4337 커뮤니티는 EIP3074가 거버넌스 실패에 대한 주요 책임을 져야 한다고 생각합니다. ERC4337 커뮤니티 멤버들은 ERC4337의 핵심 개발자인 Yova가 여러 차례 핵심 개발자 회의에서 EIP3074에 반대 의사를 표명했지만, 핵심 개발자들이 이를 듣지 않은 것으로 보인다고 생각합니다. ERC4337 커뮤니티 구성원 대부분은 EIP3074의 거버넌스 역학에 주의를 기울이지 않았으며, 대부분 구성원은 EIP3074가 더 이상 유효하지 않은 표준이라고 생각합니다. ERC4337 커뮤니티는 핵심 개발자들이 ERC4337 커뮤니티와 적극적으로 소통하지 않는다고 생각합니다.
EIP3074와 ERC4337 모두 자신들이 올바른 거버넌스 작업을 수행했다고 믿고 있으며, 다른 당사자가 거버넌스 실패에 대한 주요 책임을 져야 합니다. 분명히 이러한 거버넌스 과정에는 더 깊은 이유가 있습니다.
간단히 말해서, 더 근본적인 이유는 실제로 이더리움의 로드맵입니다. 이더리움 로드맵은 핵심 개발자 회의에 대한 권한을 갖습니다. 계정 추상화에 대한 로드맵은 ERC4337을 중심으로 구성됩니다. EIP7702는 ERC4337 표준과 완벽하게 호환되지만, EIP3074는 ERC4337 표준과 완벽하게 호환되지 않습니다. 따라서 이더리움 로드맵의 관점에서 볼 때 EIP3074는 반드시 교체될 것입니다.
물론, 이더리움 로드맵은 이더리움의 미래에 대한 비탈릭의 개인적인 비전입니다. 이더리움의 거버넌스 과정에서 심각한 분쟁이 발생할 경우, 로드맵 정의자인 비탈릭이 최종 결정권을 갖습니다. EIP3074의 교체는 비탈릭의 판결로 이루어졌습니다.
이더리움의 거버넌스 모델은 가치 ⇒ 비전 ⇒ 로드맵 ⇒ 클라이언트 모델, 줄여서 VVRC 모델입니다. 거버넌스 프로세스는 다음과 같습니다.
- 가치, 특히 지역 사회의 가치. 이더리움 커뮤니티의 가치에는 분산화, 검열 반대 등이 포함됩니다.
- 비전은 실제로 이더리움의 미래에 대한 비탈릭의 개인적인 생각입니다.
- 로드맵 로드맵은 연구자들이 비전을 기반으로 몇 가지 기술적 세부 사항을 제공하고 보다 완전한 구현 로드맵을 제공합니다.
- 클라이언트는 클라이언트의 핵심 개발자에 의해 구현됩니다. 그들은 핵심 개발자 회의 등의 도구를 사용하여 로드맵을 논의하고 로드맵에 있는 요구 사항을 구현합니다.
위의 과정은 이더리움의 실제 거버넌스 과정입니다. Vitalik의 개인적 비전이 Ethereum 거버넌스 모델의 근간에 있다는 것을 알 수 있습니다. 따라서 클라이언트 구현 내에서 심각한 분쟁이 발생하면 Vitalik의 개인적 의견이 최종 결정을 내리게 됩니다.
참고문헌
ZeroDev 소개
널
https://docs.zerodev.app/blog/3074-governance
ZeroDev 소개
널
https://docs.zerodev.app/blog/4337-and-3074-disagreements
계정 추상화 로드맵에 대한 참고 사항 - HackMD
# 계정 추상화 로드맵에 대한 참고 사항 * 피드백을 주신 Vitalik과 AA 팀에 특별히 감사드립니다.
https://notes.ethereum.org/@yoav/AA-roadmap-May-2024
