펙트라 7702

개요

EIP-7702는 EOA에 코드를 추가하는 메커니즘을 정의합니다. 이 제안은 기존 이더리움 계정인 EOA가 단기적인 기능 개선을 받아 애플리케이션의 사용성을 높일 수 있도록 합니다. 이는 새로운 트랜잭션 유형인 4를 사용하여 이미 배포된 코드에 대한 포인터를 설정함으로써 수행됩니다.

이 새로운 트랜잭션 유형은 권한 부여 목록을 도입합니다. 목록의 각 권한 부여 튜플은 다음과 같이 정의됩니다.

[ chain_id, address, nonce, y_parity, r, s ]

**주소(address)**는 위임(EOA가 사용할 이미 배포된 바이트코드)입니다. chain_id는 특정 체인(또는 모든 체인의 경우 0)에 권한 부여를 잠급니다. **논스(nonce)**는 특정 계정 논스에 권한 부여를 잠급니다. **(y_parity, r, s)**는 권한 부여 튜플의 서명으로, 권한 부여가 적용되는 EOA(권한자라고도 함)의 개인 키에 의한 keccak(0x05 || rlp ([chain_id ,address, nonce]))로 정의됩니다.

null 주소로 위임하여 위임을 재설정할 수 있습니다.

EOA의 개인 키는 위임 후에도 계정에 대한 완전한 제어권을 유지합니다. 예를 들어 Safe에 위임하더라도 계정이 다중서명이 되는 것은 아닙니다. 여전히 모든 서명 정책을 우회할 수 있는 단일 키가 존재하기 때문입니다. 앞으로 개발자는 시스템의 모든 참여자가 스마트 컨트랙트일 수 있다는 가정하에 설계해야 합니다. 스마트 컨트랙트 개발자의 경우, tx.origin가 EOA를 참조한다고 가정하는 것은 더 이상 안전하지 않습니다.

모범 사례

계정 추상화: 위임 컨트랙트는 호환성을 극대화하기 위해 이더리움의 광범위한 계정 추상화(AA) 표준과 일치해야 합니다. 특히 ERC-4337을 준수하거나 호환되는 것이 이상적입니다.

무허가성 및 검열 저항성 설계: 이더리움은 무허가성 참여를 중요하게 생각합니다. 위임 컨트랙트는 단일 "신뢰할 수 있는" 릴레이어 또는 서비스에 하드코딩되거나 의존해서는 안 됩니다. 릴레이어가 오프라인 상태가 되면 계정이 먹통이 될 수 있기 때문입니다. 일괄 처리(예: approve+transferFrom)와 같은 기능은 릴레이어 없이 EOA 자체에서 사용할 수 있습니다. 7702가 지원하는 고급 기능(가스 추상화, 프라이버시 보존 출금)을 사용하려는 애플리케이션 개발자의 경우 릴레이어가 필요합니다. 다양한 릴레이어 아키텍처가 있지만, 최소한 엔트리 포인트 0.8 (opens in a new tab)을 가리키는 4337 번들러 (opens in a new tab)를 사용하는 것을 권장합니다. 그 이유는 다음과 같습니다.

• 릴레이를 위한 표준화된 인터페이스를 제공합니다.
• 내장된 페이마스터 시스템을 포함합니다.
• 상위 호환성을 보장합니다.
• 퍼블릭 멤풀 (opens in a new tab)을 통해 검열 저항성을 지원할 수 있습니다.
• init 함수가 EntryPoint (opens in a new tab)에서만 호출되도록 요구할 수 있습니다.

즉, 계정에서 요구하는 유효한 서명이나 사용자 작업(UserOperation)을 제공하는 한 누구나 트랜잭션 스폰서/릴레이어 역할을 할 수 있어야 합니다. 이는 검열 저항성을 보장합니다. 맞춤형 인프라가 필요하지 않다면, 게이트키핑 릴레이에 의해 사용자의 트랜잭션이 임의로 차단될 수 없습니다. 예를 들어, 메타마스크의 위임 툴킷(Delegation Toolkit) (opens in a new tab)은 메타마스크 전용 서버를 요구하는 대신, 모든 체인의 모든 ERC-4337 번들러 또는 페이마스터와 명시적으로 작동합니다.

지갑 인터페이스를 통한 탈중앙화 애플리케이션(dapp) 통합:

지갑이 EIP-7702를 위해 특정 위임 컨트랙트를 화이트리스트에 추가할 것이라는 점을 고려할 때, dapp은 7702 권한 부여를 직접 요청할 것으로 기대해서는 안 됩니다. 대신 표준화된 지갑 인터페이스를 통해 통합이 이루어져야 합니다.

• ERC-5792 (wallet_sendCalls): dapp이 지갑에 일괄 호출 실행을 요청할 수 있게 하여, 트랜잭션 일괄 처리 및 가스 추상화와 같은 기능을 용이하게 합니다.

• ERC-6900: dapp이 지갑에서 관리하는 모듈을 통해 세션 키 및 계정 복구와 같은 모듈형 스마트 계정 기능을 활용할 수 있도록 합니다.

이러한 인터페이스를 활용함으로써 dapp은 위임을 직접 관리하지 않고도 EIP-7702가 제공하는 스마트 계정 기능에 접근할 수 있으며, 다양한 지갑 구현 전반에 걸쳐 호환성과 보안을 보장할 수 있습니다.

참고: dapp이 7702 권한 부여 서명을 직접 요청할 수 있는 표준화된 방법은 없습니다. dapp은 EIP-7702 기능을 활용하기 위해 ERC-6900과 같은 특정 지갑 인터페이스에 의존해야 합니다.

자세한 정보:

• ERC-5792 사양 (opens in a new tab)
• ERC-6900 사양 (opens in a new tab)

공급업체 종속 방지: 위 내용과 일치하게, 좋은 구현은 공급업체에 중립적이고 상호운용 가능합니다. 이는 종종 스마트 계정에 대한 새로운 표준을 준수하는 것을 의미합니다. 예를 들어, Alchemy의 모듈형 계정(Modular Account) (opens in a new tab)은 모듈형 스마트 계정을 위해 ERC-6900 표준을 사용하며 "무허가성 상호운용 가능한 사용"을 염두에 두고 설계되었습니다.

프라이버시 보존: 온체인 프라이버시는 제한적이지만, 위임 컨트랙트는 데이터 노출과 연결성을 최소화하기 위해 노력해야 합니다. 이는 ERC-20 토큰으로 가스 지불(사용자가 공개 ETH 잔액을 유지할 필요가 없어 프라이버시와 UX가 향상됨) 및 일회성 세션 키(단일 장기 키에 대한 의존도를 줄임)와 같은 기능을 지원함으로써 달성할 수 있습니다. 예를 들어, EIP-7702는 스폰서 트랜잭션을 통해 토큰으로 가스를 지불할 수 있게 하며, 좋은 구현은 필요 이상의 정보를 유출하지 않고도 이러한 페이마스터를 쉽게 통합할 수 있도록 합니다. 또한, 특정 승인의 오프체인 위임(온체인에서 검증되는 서명 사용)은 사용자의 기본 키를 사용하는 온체인 트랜잭션을 줄여 프라이버시 보호에 도움이 됩니다. 릴레이어를 사용해야 하는 계정은 사용자가 자신의 IP 주소를 노출하도록 강제합니다. 퍼블릭 멤풀(PublicMempools)은 이를 개선합니다. 트랜잭션/사용자 작업(UserOp)이 멤풀을 통해 전파될 때, 그것이 전송한 IP에서 시작되었는지 아니면 p2p 프로토콜을 통해 릴레이된 것인지 알 수 없습니다.

확장성 및 모듈형 보안: 계정 구현은 새로운 기능과 보안 개선 사항에 맞춰 발전할 수 있도록 확장 가능해야 합니다. EIP-7702를 사용하면 업그레이드 가능성이 본질적으로 가능합니다(EOA는 향후 로직을 업그레이드하기 위해 언제든지 새로운 컨트랙트에 위임할 수 있기 때문입니다). 업그레이드 가능성을 넘어, 좋은 설계는 완전히 다시 배포할 필요 없이 모듈성(예: 다양한 서명 체계나 지출 정책을 위한 플러그인 모듈)을 허용합니다. Alchemy의 Account Kit가 대표적인 예로, 개발자가 검증 모듈(ECDSA, BLS 등과 같은 다양한 서명 유형용)과 사용자 정의 로직을 위한 실행 모듈을 설치할 수 있게 해줍니다. EIP-7702가 활성화된 계정에서 더 큰 유연성과 보안을 달성하기 위해, 개발자는 특정 구현에 직접 위임하기보다는 프록시 컨트랙트에 위임하는 것이 권장됩니다. 이 접근 방식은 각 변경 사항에 대해 추가적인 EIP-7702 권한 부여를 요구하지 않고도 원활한 업그레이드와 모듈성을 허용합니다.

프록시 패턴의 장점:

• 업그레이드 가능성: 프록시가 새로운 구현 컨트랙트를 가리키도록 하여 컨트랙트 로직을 업데이트합니다.

• 사용자 정의 초기화 로직: 프록시 내에 초기화 함수를 통합하여 필요한 상태 변수를 안전하게 설정합니다.

예를 들어, SafeEIP7702Proxy (opens in a new tab)는 EIP-7702 호환 계정에서 위임을 안전하게 초기화하고 관리하기 위해 프록시를 어떻게 활용할 수 있는지 보여줍니다.

프록시 패턴의 단점:

• 외부 행위자에 대한 의존성: 안전하지 않은 컨트랙트로 업그레이드하지 않도록 외부 팀에 의존해야 합니다.

보안 고려 사항

재진입 가드: EIP-7702 위임의 도입으로 사용자의 계정은 외부 소유 계정(EOA)과 스마트 컨트랙트(SC) 사이를 동적으로 전환할 수 있습니다. 이러한 유연성 덕분에 계정은 트랜잭션을 시작하는 동시에 호출의 대상이 될 수 있습니다. 결과적으로 계정이 자신을 호출하고 외부 호출을 수행하는 시나리오에서는 msg.sender가 tx.origin와 같아지며, 이는 이전에 tx.origin가 항상 EOA라는 점에 의존했던 특정 보안 가정을 약화시킵니다.

스마트 컨트랙트 개발자의 경우, tx.origin가 EOA를 참조한다고 가정하는 것은 더 이상 안전하지 않습니다. 마찬가지로 재진입 공격에 대한 안전장치로 msg.sender == tx.origin를 사용하는 것은 더 이상 신뢰할 수 있는 전략이 아닙니다.

앞으로 개발자는 시스템의 모든 참여자가 스마트 컨트랙트일 수 있다는 가정하에 설계해야 합니다. 대안으로 nonReentrant 제어자(modifier) 패턴과 함께 재진입 가드를 사용하여 명시적인 재진입 보호를 구현할 수 있습니다. OpenZeppelin의 재진입 가드(Reentrancy Guard) (opens in a new tab)와 같이 감사를 받은 제어자를 따르는 것을 권장합니다. 또한 임시 저장소 변수(transient storage variable) (opens in a new tab)를 사용할 수도 있습니다.

초기화 보안 고려 사항

EIP-7702 위임 컨트랙트를 구현하면 특히 초기화 프로세스와 관련하여 특정한 보안 과제가 발생합니다. 초기화 함수(init)가 위임 프로세스와 원자적으로 결합될 때 심각한 취약점이 발생합니다. 이러한 경우, 프론트러너(frontrunner)가 위임 서명을 가로채고 변경된 매개변수로 init 함수를 실행하여 잠재적으로 계정의 제어권을 탈취할 수 있습니다.

이 위험은 기존 스마트 컨트랙트 계정(SCA) 구현을 초기화 메커니즘 수정 없이 EIP-7702와 함께 사용하려고 시도할 때 특히 관련이 있습니다.

초기화 취약점 완화 솔루션

• initWithSig 구현
  표준 init 함수를 사용자가 초기화 매개변수에 서명해야 하는 initWithSig 함수로 교체합니다. 이 접근 방식은 명시적인 사용자 동의가 있어야만 초기화를 진행할 수 있도록 보장하여 무단 초기화 위험을 완화합니다.

• ERC-4337의 EntryPoint 활용
  초기화 함수가 ERC-4337 EntryPoint 컨트랙트에서만 독점적으로 호출되도록 요구합니다. 이 방법은 ERC-4337이 제공하는 표준화된 검증 및 실행 프레임워크를 활용하여 초기화 프로세스에 추가적인 보안 계층을 더합니다.
  (참조: Safe 문서 (opens in a new tab))

이러한 솔루션을 채택함으로써 개발자는 EIP-7702 위임 컨트랙트의 보안을 강화하고 초기화 단계에서 발생할 수 있는 프론트러닝 공격으로부터 보호할 수 있습니다.

저장소 충돌: 코드를 위임한다고 해서 기존 저장소가 지워지는 것은 아닙니다. 한 위임 컨트랙트에서 다른 위임 컨트랙트로 마이그레이션할 때 이전 컨트랙트의 잔여 데이터가 남습니다. 새 컨트랙트가 동일한 저장소 슬롯을 사용하지만 다르게 해석하는 경우 의도하지 않은 동작이 발생할 수 있습니다. 예를 들어, 초기 위임이 저장소 슬롯이 bool를 나타내는 컨트랙트에 대한 것이었고, 후속 위임이 동일한 슬롯이 uint를 나타내는 컨트랙트에 대한 것이라면, 이러한 불일치로 인해 예측할 수 없는 결과가 발생할 수 있습니다.

피싱 위험: EIP-7702 위임이 구현됨에 따라 사용자 계정의 자산이 스마트 컨트랙트에 의해 완전히 제어될 수 있습니다. 사용자가 자신도 모르게 악의적인 컨트랙트에 계정을 위임하면 공격자가 쉽게 제어권을 얻고 자금을 훔칠 수 있습니다. chain_id=0를 사용할 때 위임은 모든 체인 ID에 적용됩니다. 불변 컨트랙트에만 위임하고(프록시에는 절대 위임하지 마십시오), 배포자가 다른 곳의 동일한 주소에 다른 것을 배포할 수 없도록 CREATE2(표준 initcode 사용 - 변성(metamorphic) 컨트랙트 제외)를 사용하여 배포된 컨트랙트에만 위임하십시오. 그렇지 않으면 위임으로 인해 다른 모든 EVM 체인에서 계정이 위험에 처하게 됩니다.

사용자가 위임된 서명을 수행할 때, 피싱 위험을 완화하기 위해 위임을 받는 대상 컨트랙트가 명확하고 눈에 띄게 표시되어야 합니다.

최소한의 신뢰 표면 및 보안: 유연성을 제공하는 동시에 위임 컨트랙트는 핵심 로직을 최소화하고 감사 가능하게 유지해야 합니다. 컨트랙트는 사실상 사용자 EOA의 확장이므로 어떠한 결함도 치명적일 수 있습니다. 구현은 스마트 컨트랙트 보안 커뮤니티의 모범 사례를 따라야 합니다. 예를 들어, 생성자 또는 초기화 함수는 신중하게 보호되어야 합니다. Alchemy가 강조했듯이 7702에서 프록시 패턴을 사용하는 경우 보호되지 않은 초기화 함수로 인해 공격자가 계정을 탈취할 수 있습니다. 팀은 온체인 코드를 단순하게 유지하는 것을 목표로 해야 합니다. Ambire의 7702 컨트랙트는 약 200줄의 Solidity 코드로만 구성되어 있으며, 버그를 줄이기 위해 의도적으로 복잡성을 최소화했습니다. 기능이 풍부한 로직과 감사를 용이하게 하는 단순성 사이에서 균형을 맞춰야 합니다.

알려진 구현

EIP-7702의 특성상, 지갑은 사용자가 제3자 컨트랙트에 위임하도록 도울 때 주의를 기울이는 것이 권장됩니다. 아래 목록은 감사를 받은 알려진 구현 모음입니다.

하드웨어 월렛 가이드라인

하드웨어 월렛은 임의의 위임을 노출해서는 안 됩니다. 하드웨어 월렛 분야의 합의는 신뢰할 수 있는 위임자 컨트랙트 목록을 사용하는 것입니다. 위에 나열된 알려진 구현을 허용하고 다른 구현은 사례별로 고려할 것을 제안합니다. EOA를 컨트랙트에 위임하면 모든 자산에 대한 제어권이 부여되므로, 하드웨어 월렛은 7702를 구현하는 방식에 주의해야 합니다.

컴패니언 앱을 위한 통합 시나리오

지연(Lazy)

EOA가 여전히 평소와 같이 작동하므로 수행할 작업이 없습니다.

참고: ERC-1155 NFT와 같은 일부 자산은 위임 코드에 의해 자동으로 거부될 수 있으며, 지원팀은 이를 인지하고 있어야 합니다.

인지(Aware)

코드를 확인하여 EOA에 위임이 적용되어 있음을 사용자에게 알리고, 선택적으로 위임을 제거할 수 있는 옵션을 제공합니다.

공통 위임

하드웨어 제공업체는 알려진 위임 컨트랙트를 화이트리스트에 추가하고 소프트웨어 컴패니언에서 이에 대한 지원을 구현합니다. ERC-4337을 완벽하게 지원하는 컨트랙트를 선택하는 것이 권장됩니다.

다른 컨트랙트에 위임된 EOA는 표준 EOA로 처리됩니다.

사용자 정의 위임

하드웨어 제공업체는 자체 위임 컨트랙트를 구현하여 목록에 추가하고 소프트웨어 컴패니언에서 이에 대한 지원을 구현합니다. ERC-4337을 완벽하게 지원하는 컨트랙트를 구축하는 것이 권장됩니다.

다른 컨트랙트에 위임된 EOA는 표준 EOA로 처리됩니다.

페이지 최근 업데이트: 2026년 4월 3일

p (opens in a new tab)

c (opens in a new tab)

j (opens in a new tab)

+6

기여자 보기