단 한 번의 서명으로 지갑 코드를 바꾼다: 이더리움 EIP-7702의 명암

1. 오랜 지갑에 새로운 기술을 가르친 업그레이드

2025년 5월 7일 10시 05분 11초 UTC(에포크 364032), 이더리움 펙트라(Pectra)가 메인넷에서 활성화되며 EIP-7702가 도입되었습니다. 비탈릭 부테린, 샘 윌슨, 안스가르 디트리히스, lightclient는 2024년 5월 7일 이 핵심 표준안을 작성했습니다. 목적은 'EOA에 코드를 영구 설정하는 새 트랜잭션 유형'이었습니다. 기존 개인키 계정은 새 주소로 옮기지 않고 스마트 계약 기능을 얻었습니다.^[1][2][6]

코드 설정 트랜잭션은 0x04 타입과 [chain_id, address, nonce, y_parity, r, s] 승인 튜플 목록을 사용합니다. 유효한 튜플마다 0xef0100 접두사와 대상 주소를 합친 위임 지시자(0xef0100 || address)가 계정 코드에 기록됩니다. 이후 EOA의 코드 실행은 포인터가 가리키는 바이트코드를 따릅니다. 개인키는 유지되지만 실행 중에는 지정 계약처럼 동작합니다.^[1]

이 설계는 원자적 일괄 처리, 제3자 가스비 후원, 패스키 인증, 지출 한도, 주소 보존 복구를 가능하게 합니다. 이더리움 재단은 위임이 기본적으로 체인별로 한정되고 논스(nonce)에 묶이며, 소유자가 교체하거나 해제할 수 있다고 설명했습니다. 이는 재전송과 영구 잠금 위험을 줄이는 장치입니다.^[2]

2. 우연이 아닌 설계된 지속성

승인 목록은 트랜잭션 실행 전, 발신자 논스가 증가한 직후 처리됩니다. 후속 실행이 실패하거나 리버트(revert)되어도 이미 기록된 위임 지시자는 롤백되지 않습니다. 위임은 새 승인으로 교체하거나 영(zero) 주소로 초기화할 때까지 남습니다. 세션 만료형 권한이 아니라 지속되는 계정 소프트웨어입니다.^[1][3]

사양서는 위임 코드가 계정에 '무제한 접근'하므로 지갑이 철저히 감사해야 한다고 경고합니다. 일반 사용자는 임의의 바이트코드를 검증하기 어렵습니다. 개인키로 일반 EOA 상태를 되찾을 수 있지만, 악성 코드가 활성화된 동안 실행된 거래까지 되돌리지는 못합니다.^[1][3]

잘못 구현된 위임 코드는 악의적인 공격자가 서명자의 EOA에 대해 거의 완전한 통제권을 확보하도록 허용할 수 있다.^[1]

— EIP-7702 사양서, 보안 고려사항

3. 승인 위임 피싱이라는 새로운 공격 표면

시큐리티 얼라이언스(Security Alliance)는 지갑 업그레이드를 사칭해 악성 계약으로의 SetCode 위임을 유도하는 피싱을 주요 위협으로 꼽습니다. 공격자가 악성 코드를 가리키는 승인을 받으면 계정을 통제해 자산을 탈취할 수 있다는 경고입니다. 시드 구문이 아니라, 속이는 화면에서 받은 유효한 동의 서명이 무기가 될 수 있습니다.^[5]

이는 승인 피싱의 구조를 바꿉니다. 기존의 많은 피싱은 피해자에게 유해한 전송이나 토큰 승인을 서명하게 만드는 데 집중했습니다. 반면 EIP-7702에서는 유효한 승인 튜플 하나가 0x04 트랜잭션에서 처리되면, 후속 실행이 실패해도 영구 코드 포인터가 남습니다. 2025년 12월 프리프린트 연구진은 이 상시 상태 변경을 질적으로 새로운 피싱 유형이라고 규정했습니다. 지속성은 사양으로 확인되지만, 공격 유형에 대한 평가는 연구진의 프리프린트 주장입니다.^[1][4]

공격 반경은 다른 체인으로도 확장될 수 있습니다. 승인 튜플은 기본적으로 특정 체인에 묶이지만, chain_id가 0이면 모든 EVM 네트워크에서 유효합니다. 시큐리티 얼라이언스는 chain_id=0 서명이 다른 체인에서 재전송되어 동일 주소의 악성 계약을 활성화할 수 있다고 경고합니다. 지갑이 위임 대상 계약 주소를 사용자에게 명확히 표시해야 하는 이유가 바로 여기에 있습니다.^[3][5]

4. 프리프린트 논문과 검증의 경계

2025년 12월 13일, 마카오시티대학교의 Minfeng Qi·Tianqing Zhu, CSIRO Data61의 Qin Wang·Shiping Chen, 울릉공대학교의 Ruiqiang Li 연구진은 'EIP-7702 Phishing Attack' 프리프린트를 arXiv(2512.12174v1)에 공개했습니다. 연구진은 초록에서 EIP-7702가 초래하는 위협을 다음과 같이 요약했습니다.^[4]

우리는 이 설계가 질적으로 완전히 새로운 유형의 피싱 공격을 가능하게 한다는 점을 보여준다^[4]

— 민펑 치 외, EIP-7702 피싱 공격 (arXiv 프리프린트 2512.12174v1)

논문의 실험과 온체인 측정치는 동료 평가 전인 프리프린트 저자들의 주장입니다. 본 기사는 피해 규모나 보급 통계를 확정 사실로 쓰지 않습니다. 다만 보안 경고는 앞서 존재했습니다. 2024년 5월 EIP-7702는 이미 원시 승인 서명을 사용자 인터페이스에 노출하지 말라고 명시했습니다.^[1][4]

5. 인터페이스가 구축한 방어 경계선

생태계의 방어선은 역할 분담입니다. ethereum.org 지침은 지갑이 특정 위임 계약을 화이트리스트로 관리할 것을 전제로 하며, 디앱(dApp)이 EIP-7702 승인을 직접 요구하지 말고 ERC-5792(wallet_sendCalls) 같은 표준 지갑 인터페이스를 사용하도록 안내합니다. 하드웨어 지갑에도 임의 위임을 노출하지 말고 신뢰할 수 있는 위임 계약 목록을 쓰라고 권고합니다. 이는 프로토콜이 강제하는 보장이 아니라 인터페이스 계층의 제약과 권고입니다.^[3]

시큐리티 얼라이언스는 네이티브 지갑 흐름과 검증된 계약만 이용하라고 안내합니다. 영(zero) 주소(0x0000000000000000000000000000000000000000)로 위임하면 일반 EOA로 돌아갈 수 있습니다. 안전은 사용자 분석이 아니라 인터페이스 차단에서 나옵니다. EIP는 "이 인터페이스를 안전하게 제공할 수 있는 방법은 없다"고 명시합니다.^[1][5]

이 분업이 EIP-7702의 진정한 유산입니다. 기존 계정에 스마트 계정 기능이 부여되었으나 단 한 번의 서명으로 코드가 영구 변경되는 만큼, 보안의 중심은 지속적 감시에서 인터페이스 통제로 이동했습니다. 제안자들은 학계의 분석이 나오기 1년 반 전부터 표준 사양서에 지갑의 방어 의무를 명확히 기록해 두었습니다.^[1][2][4]

애플리케이션은 사용자에게 승인 서명을 제안할 수 있다고 기대해서는 안 되며, 따라서 그러한 인터페이스를 제공하지 않는 것이 지갑의 의무이다.^[1]

— EIP-7702 사양서, 애플리케이션 및 지갑과의 상호작용