계정 추상화(AA)는 이더리움 생태계의 장기적인 발전을 위한 중요한 방향이며, 외부 계정(EOA)과 계약 계정 간의 경계를 허물고 지갑의 프로그래밍 가능성, 보안성, 그리고 업그레이드 용이성을 높이는 것을 목표로 합니다. 가장 널리 사용되는 AA 구현 솔루션인 EIP-4337은 EntryPoint 기반 스마트 계약 지갑(Safe, Stacks, Argent 등)에서 널리 사용되었습니다. 그러나 EIP-4337은 독립적인 거래 풀과 진입 계약 메커니즘을 도입하기 때문에 온체인 네이티브 기능, 운영 복잡성, 그리고 생태계 호환성 측면에서 여전히 한계가 있습니다 .
계정 추상화 사용 기준을 더욱 낮추고 기본 지원을 강화하기 위해 Vitalik은 2024년에 EIP-7702를 제안하여 Pectra 업그레이드에 포함했습니다. EIP-7702의 핵심 아이디어는 원본 EOA가 트랜잭션을 시작할 때 지정된 주소의 계약 코드(contract_code)를 실행하고, 이 코드를 사용하여 트랜잭션의 실행 로직을 정의할 수 있도록 하는 것입니다.
EIP-7702는 트랜잭션 수준 코드 삽입이라는 새로운 메커니즘을 도입하여 사용자 계정이 사전 배포된 계약 코드에 의존하는 대신 각 트랜잭션에서 실행 로직을 동적으로 지정할 수 있도록 합니다. 이는 정적 코드 기반 기존 권한 모델을 깨고 유연성을 높이며, 새로운 보안 문제를 야기합니다 . isContract 및 extcodehash와 같은 판단 로직에 의존하던 계약은 무효화될 수 있으며, 호출자가 순수 EOA라고 가정하는 일부 시스템도 우회될 수 있습니다. 감사자는 삽입된 코드 자체의 보안을 검증 할 뿐만 아니라 동적 환경에서 다른 계약 시스템에 미치는 잠재적 영향을 평가해야 합니다.
본 기사에서는 Beosin 보안팀이 EIP-7702의 설계 원칙과 주요 기능에 초점을 맞추고, 이를 기반으로 구축된 AA 지갑이 감사 과정에서 직면할 수 있는 보안 위험을 체계적으로 정리하고, 보안 연구원들이 이 새로운 패러다임 하에서 기술적 과제에 더 잘 대처할 수 있도록 실용적인 관점에서 감사 프로세스와 제안을 제시합니다 .
1. EIP-7702 소개
1. EIP-7702 기술 개요
EIP-7702는 새로운 트랜잭션 유형 0x04(SetCode)를 도입하여 EOA가 이 트랜잭션을 통해 계약 코드 실행을 승인할 수 있도록 합니다. 트랜잭션 구조는 다음과 같습니다.
rlp([체인_아이디, 논스, 가스당 최대_우선순위_수수료, 가스당 최대_수수료, 가스_한도,
목적지, 값, 데이터, 액세스 목록, 권한 부여 목록, 서명_y_패리티, 서명_r, 서명_s])
권한 부여 목록(authorization_list)에는 여러 권한 부여 목록이 포함되어 있으며, 트랜잭션을 실행하지 않는 개시자의 권한 부여 동작도 포함될 수 있습니다. 내부 구조는 다음과 같습니다.
권한 부여 목록 = [[체인 ID, 주소, 논스, y_패리티, r, s]]
이 중 chain_id는 사용자 권한이 적용되는 체인을 나타내며, 값은 실행 체인의 체인 ID와 같거나 0이어야 합니다. chain_id가 0이면 EIP-7702를 지원하는 모든 EVM 체인에 대해 권한이 적용됨을 의미하지만, nonce와 같은 다른 매개변수도 일치해야 합니다. Address는 사용자가 권한을 부여한 대상 계약 주소를 나타냅니다.
승인이 완료되면 시스템은 승인된 사용자의 코드 필드를 0x ef 0100 || 주소로 변경합니다. 여기서 주소는 승인된 계약 주소입니다. 승인을 취소하려면 SetCode 트랜잭션을 실행하여 주소를 0 주소로 설정하기만 하면 됩니다.
2. EIP 7702의 장점
(1) 유연성 및 맞춤화
추상 계정은 스마트 계약에 계정 로직을 작성하여 필요에 따라 기능을 유연하게 맞춤 설정할 수 있습니다. 예를 들어, 사용자는 개인이나 기업의 다양한 시나리오에 맞춰 다중 서명, 소셜 복구, 한도 제어 등을 구성할 수 있습니다. 이러한 설계는 계정의 기능적 확장성을 크게 향상시키고 기존 외부 계정(EOA)의 한계를 극복합니다.
(2) 강화된 보안
추상 계정은 다중 인증, 거래 한도, 소셜 복구 등 다층 보안 메커니즘을 제공합니다. 사용자가 개인 키를 분실하더라도 신뢰할 수 있는 연락처 또는 다중 인증(MFA)을 통해 계정을 복구할 수 있으므로 기존 계정에서 개인 키 분실로 인한 영구적인 자산 손실을 방지할 수 있습니다. 동시에, 한도 관리와 같은 기능을 통해 악의적인 대량 자금 유출을 방지할 수 있습니다.
(3) 가스 최적화
Abstract 계정은 유연한 가스 추상화 메커니즘을 지원하여 사용자가 제3자를 통해 가스를 지불하거나 다른 토큰을 직접 사용하여 거래 수수료를 지불할 수 있도록 합니다. 이 메커니즘은 사용자의 운영 비용을 절감할 뿐만 아니라, 특히 초보 사용자나 복잡한 다단계 거래 시나리오에서 블록체인 사용 절차를 더욱 간소화합니다.
(4) Web3 대중화 촉진
사용자 경험과 보안을 최적화함으로써, 추상 계정은 사용자에게 블록체인의 복잡성을 숨기고 Web2에 더 가까운 편리한 운영 환경을 제공합니다. 이러한 설계는 일반 사용자의 학습 비용을 절감하고 , 더 많은 사람들이 Web3 애플리케이션에 어려움 없이 참여할 수 있도록 하며, 탈중앙화 기술의 대중화를 촉진합니다.
2. EIP-7702 실무에서의 보안 위험 분석
EIP-7702는 이더리움 생태계에 새로운 활력을 불어넣고 적용 시나리오를 확장했지만 불가피하게 몇 가지 새로운 보안 위험도 야기했습니다.
1. 권한 리플레이 공격
EIP-7702 모델에 따라 사용자가 권한 부여 파일의 chain_id 필드를 0으로 설정하면 해당 권한이 여러 체인에서 유효함을 의미합니다. 이러한 크로스 체인 범용 권한 부여 설계는 일부 시나리오에서 유연성을 향상시키지만, 명백한 보안 위험을 초래합니다.
서로 다른 체인에서 동일한 주소의 계정 ID가 동일하더라도 기본 계약 구현은 완전히 다를 수 있다는 점에 유의해야 합니다. 즉, 공격자가 다른 체인에 악의적인 버전의 계약을 배포하고, 해당 체인에서 동일한 주소의 권한 부여 행위를 이용하여 예상치 못한 작업을 수행하여 사용자 자산에 위험을 초래할 수 있습니다.
따라서 지갑 서비스 제공자나 프런트엔드 상호작용 플랫폼의 경우 사용자가 이러한 권한 부여 작업을 수행할 때 사용자 권한 부여에서 선언된 chainId가 현재 연결된 네트워크와 일치하는지 명확하게 확인해야 합니다. 사용자가 chainId를 0으로 설정한 것이 감지되면 해당 권한 부여가 모든 EVM 호환 체인에 적용되고 악의적인 계약에 의해 남용될 수 있음을 사용자에게 상기시키는 명확한 위험 경고가 제공되어야 합니다 .
또한 서비스 제공자는 오용이나 피싱 공격의 위험을 줄이기 위해 UI 계층에서 기본적으로 chainId 0에 대한 권한을 제한하거나 금지할지 여부도 평가 해야 합니다.
2. 계약 호환성 문제
(1) 계약 콜백 호환성
계약 주소로 자금을 이체할 때, 기존 ERC-721, ERC-777, ERC 1155 및 기타 토큰 계약은 표준 콜백 인터페이스(예: onERC 721 Received, tokensReceived)를 호출하여 이체 작업을 완료합니다. 수신 주소가 해당 인터페이스를 구현하지 않으면 이체가 실패하거나 자산이 잠길 수 있습니다.
EIP-7702에서는 set_code 연산을 통해 사용자 주소에 계약 코드를 할당하여 계약 계정으로 만들 수 있습니다. 이 경우:
사용자 주소는 계약으로 간주됩니다.
계약이 필요한 콜백 인터페이스를 구현하지 않으면 토큰 전송이 실패합니다.
사용자는 자신도 모르게 주류 토큰을 받지 못할 수도 있습니다.
따라서 개발자는 사용자가 위임한 대상 계약이 주류 토큰과의 호환성을 보장하기 위해 관련 콜백 인터페이스를 구현하는지 확인해야 합니다.
(2) tx.origin 검증 실패
기존 계약에서 tx.origin은 거래가 사용자에 의해 직접 시작되었는지 여부를 확인하는 데 자주 사용되며, 계약 호출과 같은 보안 제어를 방지하는 데 사용됩니다.
하지만 EIP-7702 시나리오에서는:
사용자는 중계자 또는 번들러가 실제로 브로드캐스트하는 승인 거래에 서명합니다. 거래가 실행될 때 tx.origin은 사용자 주소가 아닌 중계자 주소입니다.
msg.sender는 사용자 신원을 나타내는 지갑 계약입니다.
따라서 tx.origin == msg.sender 기반 권한 검증은 합법적인 사용자 작업을 거부 하고 신뢰성을 떨어뜨립니다. 마찬가지로 tx.origin == user와 같은 계약 호출에 대한 제한도 실패합니다. 보안 판단의 기준으로 tx.origin을 사용하지 않고 서명 검증 또는 권한 부여 메커니즘을 대신 사용하는 것이 좋습니다.
(3) isContract에 대한 잘못된 판단
많은 계약은 isContract(주소)(주소 코드 길이 확인)를 사용하여 계약 계정이 에어드랍, 스냅업 등과 같은 특정 작업에 참여하는 것을 방지합니다.
require(!isContract(msg.sender), 계약이 허용되지 않습니다.)
EIP-7702 메커니즘에 따라 사용자 주소는 set_code 트랜잭션을 통해 계약 계정으로 변경될 수 있으며, isContract는 true를 반환합니다. 계약은 합법적인 사용자를 계약 계정으로 잘못 식별하고 사용자의 작업 참여를 거부하여 사용자가 특정 서비스를 이용할 수 없게 하고 사용자 경험에 부정적인 영향을 미칠 수 있습니다.
계약 지갑이 점점 더 보편화됨에 따라, isContract를 기반으로 실제 사용자인지 확인하는 방식은 더 이상 안전하지 않습니다. 서명 검증과 같은 더욱 정확한 사용자 식별 방법을 사용하는 것이 좋습니다.
3. 피싱 공격
EIP-7702 위임 메커니즘이 구현되면 사용자 계정의 자산은 위임된 스마트 계약에 의해 완전히 통제됩니다. 사용자가 악의적인 계약을 승인하면 공격자는 이를 이용하여 계정 자산을 완전히 통제할 수 있으며, 이로 인해 자금이 빠르게 이체되거나 도난당할 수 있습니다. 이는 매우 높은 보안 위험을 초래합니다.
따라서 지갑 서비스 제공업체는 EIP-7702 유형의 거래 분석 및 위험 식별 메커니즘을 가능한 한 빨리 지원하는 것이 중요합니다. 사용자가 위임된 거래에 서명할 때 프런트엔드는 대상 계약 주소를 명확하고 눈에 잘 띄게 표시하고, 계약 출처 및 배포 정보와 같은 보조 정보를 결합하여 사용자가 잠재적인 피싱 또는 사기 행위를 식별할 수 있도록 지원함으로써 서명 오류 위험을 줄여야 합니다. 또한, 지갑 서비스는 계약 코드 오픈소스 상태 확인, 권한 모델 분석, 잠재적 위험 작업 식별과 같은 대상 계약에 대한 자동화된 보안 분석 기능을 통합하여 사용자가 승인 전에 더욱 안전한 판단을 내릴 수 있도록 지원해야 합니다.
EIP-7702에서 도입된 위임 서명 형식은 기존 EIP-191 및 EIP-712 서명 표준과 호환되지 않는다는 점에 특히 유의해야 합니다. 위임 서명은 지갑의 기존 서명 경고 및 대화형 메시지를 쉽게 우회할 수 있어 사용자가 악의적인 작업에 서명하도록 속일 위험을 더욱 증가시킵니다. 따라서 지갑 구현에 이 서명 구조의 인식 및 처리 메커니즘을 도입하는 것은 사용자 보안을 보장하는 핵심 요소가 될 것입니다.
4. 지갑 계약 위험
(1) 지갑 계약 권한 관리
많은 EIP-7702 지갑 계약은 로직 업그레이드를 지원하기 위해 프록시 아키텍처(또는 내장 관리 권한)를 사용합니다. 그러나 이는 권한 관리 위험을 증가시킵니다. 업그레이드 권한을 엄격하게 제한하지 않으면 공격자가 구현 계약을 변경하고 악성 코드를 삽입하여 사용자 계정을 변조하거나 자금을 도난당할 수 있습니다.
안전 팁:
다중 서명, 다중 요소 인증 또는 시간 잠금 메커니즘을 사용하여 업그레이드 권한을 제어합니다.
코드 및 권한 변경은 엄격한 감사와 보안 검증을 거쳐야 합니다.
업그레이드 프로세스는 사용자의 알 권리와 참여 권리를 보장하기 위해 공개적이고 투명하게 진행됩니다.
(2) 저장 충돌 위험 및 데이터 격리
지갑 계약 버전이나 다른 지갑 서비스 제공업체가 동일한 저장 슬롯을 재사용할 수 있습니다. 사용자가 지갑 서비스 제공업체를 변경하거나 지갑 로직을 업그레이드하는 경우, 저장 슬롯을 재사용하면 상태 변수 충돌, 데이터 덮어쓰기, 읽기 이상 등의 문제가 발생할 수 있습니다 . 이는 지갑의 정상적인 기능을 손상시킬 뿐만 아니라 자금 손실이나 권한 이상도 초래할 수 있습니다.
안전 팁:
전용 스토리지 격리 솔루션(예: EIP-1967 표준)을 사용하거나 고유한 네임스페이스를 활용하여 스토리지 슬롯을 관리합니다.
계약을 업그레이드할 때는 가변적인 중복을 피하기 위해 스토리지 레이아웃이 호환되는지 확인하세요.
업그레이드 과정에서 저장 상태의 합리성을 엄격하게 테스트합니다.
(3) 지갑 내부의 Nonce 관리
지갑 컨트랙트는 일반적으로 사용자 작업의 실행 순서를 보장하고 재전송 공격을 방지하기 위해 내부적으로 nonce를 설정하고 직접 관리합니다. nonce를 부적절하게 사용하면 사용자 작업이 정상적으로 실행되지 않습니다.
안전 팁:
Nonce는 동일성(또는 증가)을 엄격하게 확인해야 하며 건너뛸 수 없습니다.
함수는 nonce를 직접 수정할 수 없습니다. nonce는 사용자 작업이 수행될 때만 동기적으로 업데이트됩니다.
Nonce 교착 상태를 피하기 위해 Nonce 이상에 대한 장애 허용 및 복구 메커니즘을 설계합니다.
(4) 함수 호출자 권한 확인
보안을 위해 지갑 계약은 키 함수의 호출자가 지갑 소유자 계정인지 확인해야 합니다. 두 가지 일반적인 방법은 다음과 같습니다.
오프체인 서명 승인
사용자가 개인 키로 일련의 작업에 서명하면, 지갑 계약은 체인에서 서명이 적법하고 만료되었으며 해당 논스를 충족하는지 확인합니다. 이 방식은 EIP-7702에서 권장하는 릴레이 트랜잭션 모드(사용자 오프라인 서명 + 릴레이 에이전트 트랜잭션)에 적합합니다.
호출 제약 조건 (msg.sender == address(this))
사용자 작업 기능은 계약 자체에 의해서만 트리거될 수 있으며, 이는 본질적으로 외부 개시자가 계정 자체여야 함을 보장하는 호출 경로 제어 메커니즘입니다. 이는 실제로 호출자가 원래 EOA여야 한다는 것을 요구하는 것과 같습니다. 왜냐하면 이 시점의 계약 주소는 EOA 주소이기 때문입니다.
3. 전망: EIP-7702 및 미래 AA 지갑 표준
EIP-7702의 도입은 기존 계좌 모델의 혁신일 뿐만 아니라, 계좌 추상화 생태계에도 큰 활력을 불어넣습니다. 사용자가 계약 코드를 로드할 수 있게 됨으로써 향후 지갑 설계 및 계약 시스템 개발에 대한 폭넓은 가능성을 제시하고, 보안 감사 기준에 대한 새로운 요구 사항을 제시합니다.
1. EIP-4337과의 공진화: 듀얼 모드 호환성을 향해
EIP-7702와 EIP-4337은 설계 목표가 서로 다르지만, 전자는 계정 코드 로딩 메커니즘을 재구성하는 반면, 후자는 완전한 거래 입력 및 패키징 생태계를 구축합니다. 그러나 두 가지 모두 상충되는 것은 아니며, 매우 상호 보완적입니다.
● EIP-4337은 “범용 거래 채널”과 “추상적 계정 실행 인터페이스”를 제공합니다.
● EIP-7702를 사용하면 사용자 계정에서 주소를 변경하지 않고도 동적으로 계약 논리 기능을 부여할 수 있습니다.
따라서 지갑은 앞으로 듀얼 모드 지원 아키텍처를 채택할 가능성이 있습니다. 즉, EIP-4337을 지원하지 않는 체인에서는 가벼운 대안으로 EIP-7702를 사용하고, 오프체인 패키징과 다중 사용자 집계가 필요한 시나리오에서는 EIP-4337의 전체 프로토콜 스택을 계속 사용할 수 있습니다.
이러한 듀얼 모드 메커니즘을 통해 지갑은 커널 계층에서 보다 유연한 계정 권한 모델, 다운그레이드 메커니즘 및 롤백 솔루션을 지원할 수 있습니다.
2. MPC, ZK 등 새로운 지갑 로직에 대한 지원 및 영감
EIP-7702에서 옹호하는 계정 계약 메커니즘은 MPC 지갑, ZK 지갑, 모듈형 지갑과 같은 현재 인기 있는 새로운 아키텍처와 자연스럽게 통합될 수 있는 잠재력을 가지고 있습니다.
● MPC 모드에서는 서명 동작이 더 이상 단일 개인 키에 의존하지 않고 여러 당사자의 협력적인 의사 결정에 의존합니다. EIP-7702와 MPC의 융합으로 생성된 서명은 동적으로 로드되는 계약 로직을 제어하여 더욱 유연한 실행 전략을 구현할 수 있습니다.
● ZK 지갑은 개인 키 정보를 노출하지 않고 영지식 증명을 통해 사용자 신원 또는 권한을 검증합니다. EIP-7702와 결합하여 ZK 지갑은 검증 완료 후 특정 로직 계약을 일시적으로 주입하여, 특정 개인정보 보호 조건이 충족될 때만 특정 로직을 자동으로 실행하는 등 개인정보 보호 계산 후 개인화된 행동 전개를 실현할 수 있습니다 .
● 모듈형 지갑은 EIP-7702를 사용하여 계정 로직을 여러 모듈로 분해하고 필요할 때 동적으로 로드할 수 있습니다.
따라서 EIP-7702는 위에서 언급한 고급 지갑에 대해 더욱 고유한 실행 컨테이너를 제공합니다. 사용자 주소를 변경하지 않고도 다양한 계약 논리를 주입할 수 있으며, 기존 계약 배포 프로세스에서 발생하는 주소 종속성 문제를 피하고 사전 배포의 필요성을 없애고 계정 동작의 유연성과 결합 기능을 크게 향상시킵니다.
3. 계약 개발자 및 감사자에 대한 의미
EIP-7702는 개발 패러다임에 근본적인 변화를 가져올 것입니다. 계약 개발자는 더 이상 호출자를 기존 EOA 또는 고정 계약 계정으로 간주하지 않고, 새로운 메커니즘에 적응해야 합니다. 호출자 ID는 거래 프로세스 중에 EOA와 계약 상태 간에 동적으로 전환될 수 있으며, 계정 동작 로직은 더 이상 정적으로 고정되지 않고 수요에 따라 유연하게 변경될 수 있습니다. 이를 위해 개발자와 감사자는 다음과 같은 사항을 갖춰야 합니다.
더욱 엄격한 발신자 확인 및 권한 판단 논리를 도입했습니다.
호출 경로가 동적 계약 논리의 영향을 받는지 확인합니다.
msg.sender.code.length == 0, isContract() 등의 동작에 의존하는 잠재적인 취약점을 식별합니다.
정적 호출 및 위임 호출의 경계 제어와 같은 계약 논리의 컨텍스트 종속성을 명확히 합니다.
툴체인 수준에서 setCode 시나리오의 시뮬레이션과 복원 분석을 지원합니다.
즉, 코드 보안은 더 이상 단순히 배포 전 문제가 아니라 통화 및 트랜잭션 중에 검증해야 하는 동적 프로세스가 되었습니다.
IV. 결론
EIP-7702는 계정 추상화(AA)를 위한 더 가볍고, 네이티브하며, 유연한 구현을 도입하여 일반 EOA가 단일 트랜잭션에서 계약 로직을 전달하고 실행할 수 있도록 합니다. 이 메커니즘은 기존의 정적인 계정 동작 가정을 깨뜨립니다. 개발자는 더 이상 계정 주소의 코드 상태만으로 동작 모델을 결정할 수 없으며, 호출자의 신원과 권한 경계를 파악해야 합니다.
보안 분석의 패러다임 전환이 뒤따릅니다. 감사의 초점은 더 이상 특정 주소의 권한 여부에 국한되지 않고, 거래에 포함된 계약 로직이 현재 상황에서 무엇을 할 수 있는지로 전환됩니다. 각 거래는 독립적인 동작 정의를 포함할 수 있으며, 이는 계정에 더 강력한 기능을 제공하고 보안 감사에 대한 요구 사항을 더욱 강화합니다.
