EIP-7702 계정 위임: EOA의 코드 설정과 서명 위험

일반적인 이더리움 외부 소유 계정(EOA)은 개인 키로 거래에 서명하고, 계정 자체에 실행 코드가 없습니다. EIP-7702는 이 EOA가 이미 배포된 코드 주소를 가리키는 위임 표시를 계정 코드 자리에 설정하도록 합니다. 위임된 계정으로 호출이 들어오면 클라이언트는 지정된 주소의 코드를 읽고, 계정의 실행 맥락에서 실행합니다. 즉 코드는 다른 주소에 있지만 계정 주소와 잔액, 저장 공간의 맥락은 위임한 계정에 연결됩니다.

이 변화는 계정 주소를 새 계약 주소로 옮기거나 개인 키를 스마트 계약으로 바꾸는 절차가 아닙니다. EOA의 기존 주소와 키는 남고, 올바른 위임 표시를 가진 계정은 계속 일반 거래를 시작할 수 있습니다. EIP-7702가 활성화한 것은 EOA에 코드가 있는 것처럼 호출될 수 있는 실행 경로이지, 하나의 키를 여러 안전한 권한으로 자동 분리하는 기능이 아닙니다.

EIP-7702 규격은 이를 새로운 type-4 set-code 거래와 authorization list로 정의합니다. Ethereum.org의 Pectra EIP-7702 안내도 이미 배포된 코드 주소를 가리키는 메커니즘으로 설명합니다. “스마트 계정 지원”이라는 지갑 화면 문구만으로 계정의 실제 검증 규칙, 위임 코드 또는 복구 기능을 알 수는 없습니다.

먼저 누가 개인 키를 보유하는지와 누가 위임 코드를 배포·관리하는지 구분하세요. 키 소유자가 직접 코드를 점검할 수 있는지, 코드를 바꿀 수 있는 운영자나 업그레이드 권한이 있는지, 계정의 잔액과 토큰 승인에 어떤 영향이 있는지가 보안 판단의 출발점입니다.

EIP-7702의 set-code 거래는 type byte 0x04로 식별됩니다. 일반 거래 필드에 authorization list가 추가되며, 각 항목은 대략 chain ID, 위임할 코드 주소, 권한 계정의 논스, 그리고 그 항목을 승인하는 서명으로 구성됩니다. 권한 계정은 자신의 개인 키로 목록 항목을 승인하고, type-4 거래의 발신자는 바깥 거래를 별도로 서명합니다. 두 역할은 같을 수도, 다를 수도 있습니다.

바깥 거래를 제출하는 발신자가 다른 사람의 유효한 authorization을 포함할 수 있기 때문에, 사용자가 지갑에서 승인한 데이터가 실제로 어떤 위임 주소와 체인 범위를 허용하는지 중요합니다. 승인 서명은 보통 특정 체인 ID를 담지만, chain ID가 0이면 여러 지원 체인에서 적용될 수 있는 범위를 의도할 수 있습니다. 같은 서명이 모든 체인에서 성공한다는 뜻은 아닙니다. 해당 체인의 계정 논스와 프로토콜 지원 등 조건이 맞아야 하며, 반대로 넓은 체인 범위를 승인하면 한 체인에서만 사용할 줄 알았던 서명이 다른 지원 체인에서도 쓰일 여지가 생깁니다.

권한 계정의 논스가 현재 값과 맞지 않거나 코드 상태가 유효하지 않으면 해당 authorization 항목은 처리되지 않을 수 있습니다. 주소 한 글자 차이도 다른 코드 주소를 가리킬 수 있으므로, 지갑 미리보기와 신뢰할 수 있는 체인 탐색기에서 네트워크·계정·코드 주소를 대조해야 합니다. 단순히 “계정 업그레이드”나 “가스 최적화”라는 설명만으로 서명 요청을 이해했다고 볼 수 없습니다.

Ethereum.org의 거래 유형 설명은 type-4 거래가 authorization list를 포함한다고 안내합니다. 수수료는 바깥 거래의 가스 조건과 네트워크 상태에 좌우됩니다. 다른 주소가 거래를 대신 제출하더라도, 그 사실만으로 가스 비용이 사라지는 것은 아닙니다. EIP-7702 type-4 거래와 ERC-4337 UserOperation·paymaster 흐름은 서로 다른 규격이므로 혼동하지 마세요. ERC-4337 흐름은 스마트 계정 UserOperation 안내에서 따로 다룹니다.

위임에 성공하면 EOA에 실제 계약 바이트코드 전체를 복사하는 대신, EIP-7702가 정한 0xef0100 접두부와 대상 주소로 이루어진 표시가 설정됩니다. 클라이언트의 호출 처리 과정은 이 표시를 확인하고 대상 주소의 코드를 읽습니다. 화면에서 보는 계정 주소와 실행에 쓰이는 코드 주소는 따라서 다를 수 있습니다. 두 주소를 따로 확인해야 하는 이유입니다.

대상 주소가 다른 네트워크에 있다고 해서 그 네트워크의 코드가 현재 체인에서 실행되는 것은 아닙니다. 코드가 해석되는 곳은 위임 표시가 설정된 현재 체인입니다. 같은 20바이트 주소라도 체인마다 배포된 코드가 다르거나 코드가 없을 수 있습니다. 각 체인의 주소와 코드 검증 상태를 따로 확인하고, 사용자 인터페이스가 제시하는 이름이나 로고만으로 주소의 동일성을 판단하지 마세요.

실행 코드는 위임한 계정의 주소와 저장 공간을 사용해 동작할 수 있습니다. 따라서 그 코드는 해당 계정의 ETH를 보내고, 토큰을 전송하거나, 외부 계약을 호출할 권한을 가질 수 있습니다. 지갑이나 애플리케이션이 별도의 정책 모듈을 구현했다면 특정 거래만 허용할 수 있지만, EIP-7702 자체가 “하루 1회만”, “이 토큰만” 같은 제한을 자동으로 덧붙이지는 않습니다.

코드가 프록시나 업그레이드 가능한 계약이라면 오늘 확인한 코드가 나중에도 동일하다고 단정할 수 없습니다. 관리 키, 구현 주소 교체 권한, 변경 지연과 공개 절차까지 확인해야 합니다. 구현이 불투명하거나 운영자 권한을 알 수 없다면, 위임을 계속 유지하는 것 자체가 별도의 신뢰 위험입니다.

위임 코드는 계정에 붙은 플러그인처럼 제한된 권한으로만 실행되는 것이 아닙니다. 구현이 접근 제어를 정확히 만들지 않으면 자산 전송, 토큰 승인, 임의 계약 호출, 저장 값 변경을 허용할 수 있습니다. 계약을 감사했다는 표시 하나만으로 현재 사용자가 승인하는 주소·버전과 감사 범위가 일치하는지도 보장되지 않습니다.

EIP-7702 보안 고려사항은 delegate 코드가 재사용 공격을 막는 nonce, 호출 대상과 calldata, ETH value 및 가스 조건 등을 서명에 포함해야 할 수 있다고 설명합니다. 이런 필드가 빠진 구현은 후원자나 제삼자가 서명자의 의도와 다른 요청을 만들 여지를 남길 수 있습니다. 계정 코드가 어떤 호출을 검증하는지와 외부가 그 검증을 우회할 수 있는지까지 살펴봐야 합니다.

예를 들어 지갑이 호출 묶음 기능을 제공한다면, 사용자는 한 번의 확인으로 토큰 승인과 스왑을 함께 승인할 수 있습니다. 한 호출이 실패할 때 나머지 호출도 되돌아가는지, 승인 한도가 필요한 양으로 제한되는지, 실행 후 승인 권한을 줄일 수 있는지 확인해야 합니다. 별도 paymaster나 서비스가 수수료를 부담한다면 누가 어떤 조건에서 비용을 내는지도 읽어야 합니다. 무료처럼 보이는 버튼이 거래 권한의 범위나 실패 비용을 숨기지 않도록 미리보기 전체를 확인하세요.

보안은 코드 주소의 평판보다 실제 권한과 업데이트 통제에서 결정됩니다. 계정이 호출할 수 있는 대상 계약, 서명 검증의 구현, 긴급 중단·업그레이드 권한, 배포 코드가 검증된 소스와 일치하는지 함께 확인하세요. 모르는 주소를 승인하거나 출처가 불분명한 메신저 링크에서 위임을 요구하는 경우에는 서명을 미루고 공식 지갑 문서에서 해당 동작을 대조하는 편이 안전합니다.

EIP-7702는 authorization list를 처리하면서 위임 표시를 먼저 적용합니다. 그 뒤 바깥 type-4 거래의 실행 단계가 revert되더라도, 이미 처리된 delegation indicator는 되돌려지지 않는다고 규격에 적혀 있습니다. 즉 “전체 거래가 실패했으니 계정 상태도 원래대로일 것”이라고 가정하면 안 됩니다. 거래 영수증의 실패 결과와 계정 코드의 현재 위임 상태를 별도로 확인해야 합니다.

이 차이는 배치 작업, 초기화 호출 또는 sponsor가 대신 제출한 거래를 점검할 때 특히 중요합니다. authorization은 유효했지만 이후 실행 단계가 실패했다면, 기대했던 초기화나 앱 동작은 끝나지 않은 채 위임만 남을 수 있습니다. 반대로 authorization 항목 자체가 처리되지 않은 경우에는 위임이 설정되지 않을 수 있습니다. 탐색기에서 type-4 거래의 상태만 보지 말고, 계정의 코드 표시와 대상 코드 주소도 확인하세요.

지갑이 “실패”라고 표시하더라도 그 실패가 서명 검증, authorization 처리, 외부 호출 가운데 어느 단계에서 났는지 구분해야 합니다. RPC 응답이나 사용자 인터페이스 요약은 상태를 간단히 묶어 보여줄 수 있으므로, 필요하다면 거래 해시, authorization의 권한 계정과 논스, 실제 account code를 공식 체인 조회 도구에서 대조합니다. 승인 요청이 재시도되면 논스가 바뀌어 이전 서명이 무효가 될 수 있으므로 중복 제출 여부도 확인해야 합니다.

이 동작은 한 번의 화면 확인으로 모든 결과가 원자적으로 취소된다고 생각하는 사용자에게 중요합니다. 실험용 계정이나 소액 계정에서 작동을 먼저 확인하더라도, 그 검증이 코드의 안전성을 보증하지는 않습니다. 실제 자산이 있는 주소에 적용하기 전에 서명된 위임의 chain ID, 대상 코드, calldata와 실패 시 잔존 상태를 확인할 수 있는지 점검하세요.

EIP-7702는 새 authorization으로 다른 코드 주소를 지정해 위임을 교체할 수 있습니다. 규격은 null 주소에 위임하는 예외를 두어 현재 위임 표시를 지우고 일반 EOA 코드 상태로 돌아가는 절차도 정의합니다. 그러나 “위임 표시 해제”는 계정에 연결된 모든 위험을 청소하는 전체 복구 명령이 아닙니다.

대상 코드가 계정 저장 공간에 값을 기록했다면 코드 표시를 지워도 저장 값이 자동으로 지워지는 것은 아닙니다. 토큰 계약의 allowance도 위임 코드의 계정 코드와 별도 상태입니다. 이전에 허용한 무제한 지출 권한은 ERC-20 계약에서 별도로 취소해야 할 수 있습니다. 이미 전송한 토큰, 외부 계약 상태 변경, 실행 완료된 거래도 위임을 해제한다고 되돌아오지 않습니다.

새 위임 코드는 같은 계정 저장 공간을 이어 사용할 수 있기 때문에, 서로 다른 코드 버전이 같은 슬롯을 다른 의미로 해석하면 상태 충돌이 생길 수 있습니다. 업그레이드 순서와 저장 레이아웃 호환성을 점검하지 않은 채 코드를 바꾸면 잠금, 오류 또는 접근 손실이 발생할 수 있습니다. 위임 해제 후 다시 연결할 때도 이전 계정 상태가 새 구현에 어떤 영향을 주는지 별도로 점검해야 합니다.

따라서 대응 순서는 문제의 종류에 따라 다릅니다. 현재 코드가 악성으로 의심되면 공식 지갑이 안내하는 해제 또는 신뢰 가능한 새 구현 전환을 빠르게 검토합니다. 이미 토큰 allowance를 승인했다면 토큰 승인과 allowance 점검 안내에서 별도 취소 절차를 확인합니다. 시드 문구·키가 노출되었거나 서명 권한 자체가 공격자에게 넘어갔다면 코드 해제만으로는 키 유출을 해결할 수 없으므로, 지갑 복구와 시드 보관 안내의 기본 대응을 참고하고 안전한 새 계정으로 자산을 옮길 필요도 평가합니다.

먼저 공식 지갑 또는 신뢰하는 앱의 문서에서 EIP-7702 위임을 실제로 지원하는지 확인합니다. 네트워크 이름과 chain ID, 계정 주소, 위임 대상의 정확한 주소, 대상 코드의 배포·검증 상태, 프록시 관리자 권한을 대조하세요. 체인 ID가 0인 넓은 범위인지 특정 체인으로 제한된 서명인지도 지갑 화면에서 이해할 수 있어야 합니다. 화면이 모호하면 서명 데이터를 해석할 수 있는 지갑 문서나 지원 경로를 먼저 확인합니다.

다음으로 위임을 설정하는 authorization 서명과 바깥 거래 발신자, 수수료 부담자를 구분합니다. 바깥 거래가 다른 주소에서 제출되더라도 권한 계정이 동의한 위임 내용을 바꿀 수 있는 것은 아닙니다. 반대로 sponsorship이 있다고 해서 delegate 코드가 안전하거나 승인한 호출만 수행한다는 뜻도 아닙니다. transaction type, authorization list, 호출 대상과 calldata, token allowance 변경이 미리보기와 일치하는지 살핍니다.

이미 위임을 설정했다면 블록 탐색기에서 거래 성공 여부만 보는 데 그치지 말고 현재 계정의 위임 표시가 무엇을 가리키는지 확인합니다. 예상한 코드 주소와 다르면 추가 거래나 토큰 승인을 멈추고, 잘못된 위임 해제나 무작위 재위임을 반복하지 마세요. 거래 비용의 바깥 필드는 이더리움 가스 요금 안내, EOA 논스와 pending 거래는 대기 거래와 논스 교체 안내에서 따로 확인할 수 있습니다.

EIP-7702는 EOA에 실행 코드를 연결하는 표준 거래 형식을 제공합니다. 호출 묶기, 가스 후원, 키 교체나 제한된 세션 권한은 그 위에 구축된 코드와 서비스가 구현할 수 있는 기능입니다. 모든 지갑에 같은 복구 방식이 있거나, 모든 delegate가 토큰·네트워크·기간별 제한을 지원하는 것은 아닙니다.

계정이 스마트 계정처럼 보인다는 사실은 누가 키를 보유하는지, 누가 코드를 업그레이드하는지, 누가 복구 절차를 바꿀 수 있는지를 답해 주지 않습니다. 이런 권한은 서비스 약관, 계약 코드와 실제 설정을 통해 확인해야 합니다. 지원하지 않는 지갑에서는 승인 상태나 코드 표시가 예상과 다르게 보일 수 있어, 본인 지갑이 해당 체인과 기능을 지원하는지 먼저 점검해야 합니다.

Ethereum Foundation은 Pectra 메인넷 안내에서 EIP-7702 authorization으로 EOA가 특정 위임 코드를 가리킬 수 있고 새 authorization으로 교체하거나 취소할 수 있다고 소개했습니다. 실제 구현에서 취소가 어떤 화면과 거래 절차로 제공되는지는 지갑마다 다를 수 있습니다. 표준의 가능성과 제품이 이를 사용자가 이해하기 쉽게 노출하는지는 서로 다른 질문입니다.

이 안내는 계정 구조를 이해하기 위한 교육 자료이며, 특정 지갑이나 delegate를 추천하지 않습니다. 사용자의 목표가 단순 승인인지, 여러 호출 묶기인지, 가스 후원인지, 분실 복구인지 먼저 정리한 뒤 각 기능을 누가 구현하고 어떤 키·서비스를 신뢰해야 하는지 비교하세요. 관련 계정 유형의 차이는 스마트 계정과 ERC-4337 설명에서, EOA의 논스와 거래 대기는 pending 거래 안내에서 확인할 수 있습니다.