Pectra 7702

추상적인

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

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

[chain_id, 주소, 논스, y_parity, r, s ]

주소는 대표단입니다 (이미 배포된 바이트코드는 EOA에서 사용될 것입니다) chain_id는 특정 체인(또는 모든 체인에 대해 0)에 권한을 고정합니다 nonce는 특정 계정에 권한을 잠급니다 (y_parity, r, s)는 인증 튜플의 서명으로, 인증이 적용되는 EOA의 개인 키(권한이라고도 함)에 의해 keccak(0x05 || rlp ([chain_id, 주소, 논스]))로 정의됩니다

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

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

모범 사례

계정 추상화: 위임 계약은 호환성을 극대화하기 위해 이더리움의 광범위한 계정 추상화(AA) 표준에 부합해야 합니다. 특히, 이상적으로 ERC-4337을 준수하거나 호환되어야 합니다.

무허가 및 검열 저항 디자인: 이더리움은 무허가 참여를 중시합니다. 위임 계약은 하드코딩하거나 단일 "신뢰할 수 있는" 중계기나 서비스에 의존해서는 안 됩니다. 릴레이가 오프라인으로 전환되면 계정이 손상될 수 있습니다. 배치(예: approve+transferFrom)와 같은 기능은 릴레이어 없이 EOA 자체에서 사용할 수 있습니다. 7702(가스 추상화, 개인정보 보호 인출)로 활성화된 고급 기능을 사용하려는 애플리케이션 개발자에게는 릴레이가 필요합니다. 다양한 릴레이 아키텍처가 있지만, 다음과 같은 이유로 4337 번들러 (opens in a new tab) 를 최소한 진입점 0.8 (opens in a new tab) 로 가리키는 것을 권장합니다:

• 릴레이를 위한 표준화된 인터페이스를 제공합니다
• 내장된 페이마스터 시스템 포함
• 순방향 호환성 보장
• [public mempool](https://notes.ethereum.org/ (opens in a new tab) @yoav/unified-erc-4337-mempool)을 통해 검열 저항을 지원할 수 있습니다
• Init 함수는 EntryPoint (opens in a new tab) 에서만 호출할 수 있습니다

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

지갑 인터페이스를 통한 디앱 통합:

지갑이 EIP-7702에 대한 특정 위임 계약을 화이트리스트에 올린다는 점을 고려할 때, dApp이 7702 승인을 직접 요청할 것으로 예상해서는 안 됩니다. 대신, 통합은 표준화된 지갑 인터페이스를 통해 이루어져야 합니다:

• ERC-5792 ('wallet_sendCalls'): dApp이 일괄 호출을 실행하기 위해 지갑을 요청할 수 있도록 하여 트랜잭션 배치 및 가스 추상화와 같은 기능을 용이하게 합니다.

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

이러한 인터페이스를 활용하면 dApp은 위임을 직접 관리하지 않고도 EIP-7702에서 제공하는 스마트 계정 기능에 액세스하여 다양한 지갑 구현 간의 호환성과 보안을 보장할 수 있습니다.

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

자세한 정보:

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

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

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

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

프록시 패턴의 이점:

• 업그레이드 가능: 프록시를 통해 새로운 구현 계약을 안내하여 계약 로직을 업데이트합니다.

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

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

프록시 패턴(Proxy Pattern)의 단점:

• 외부 행위자에 대한 의존성: 안전하지 않은 계약으로 업그레이드하지 않기 위해 외부 팀에 의존해야 합니다.

보안 고려 사항

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

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

앞으로 개발자는 시스템에 참여하는 모든 참가자가 스마트 컨트랙트가 될 수 있다는 가정 하에 설계해야 합니다. 또는 nonReentrant 수정자 패턴을 사용하여 재진입 가드를 통해 명시적인 재진입 보호를 구현할 수도 있습니다. Open Zeppelin의 Reentrancy Guard (opens in a new tab)와 같이 감사된 수정자를 따르는 것을 권장합니다. 또한 임시 저장 공간 변수 (opens in a new tab)를 사용할 수도 있습니다.

초기화 보안 고려 사항

EIP-7702 위임 계약을 구현하면 특히 초기화 프로세스와 관련하여 특정한 보안 문제가 발생합니다. 초기화 함수(init)가 위임 프로세스와 원자적으로 결합될 때 심각한 취약점이 발생합니다. 이러한 경우 프론트러너가 위임 서명을 가로채고 변경된 매개변수로 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(표준 초기화 코드로, 변형 계약 없음)를 사용하여 배포된 계약에만 위임해야 합니다. 그렇지 않으면 귀하의 위임은 다른 모든 EVM 체인에서 귀하의 계정을 위험에 빠뜨립니다.

사용자가 위임된 서명을 수행할 때, 위임을 받는 대상 계약을 명확하고 눈에 띄게 표시하여 피싱 위험을 완화하는 데 도움을 주어야 합니다.

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

알려진 구현

EIP-7702의 특성상 지갑은 사용자가 제3자 계약에 위임하는 것을 도울 때 주의를 기울이는 것이 좋습니다. 아래는 감사된 알려진 구현 모음입니다.

하드웨어 지갑 가이드라인

하드웨어 지갑은 임의의 위임을 노출해서는 안 됩니다. 하드웨어 지갑 분야의 합의는 신뢰할 수 있는 위임자 계약 목록을 사용하는 것입니다. 위에 나열된 알려진 구현을 허용하고 사례별로 다른 구현을 고려할 것을 제안합니다. EOA를 계약에 위임하면 모든 자산을 관리할 수 있으므로 하드웨어 지갑은 7702를 구현하는 방식에 신중을 기해야 합니다.

컴패니언 앱의 통합 시나리오

게으른

EOA가 여전히 평소처럼 작동하므로 별다른 조치가 필요하지 않습니다.

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

인지

사용자에게 코드를 확인하여 EOA에 대한 위임이 있음을 알리고, 선택적으로 위임을 제거할 것을 제안합니다.

일반적인 위임

하드웨어 제공업체는 알려진 위임 계약을 화이트리스트에 올리고 소프트웨어 동반자에서 지원을 구현합니다. ERC-4337을 완벽하게 지원하는 계약을 선택하는 것이 좋습니다.

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

사용자 지정 위임

하드웨어 제공업체는 자체 위임 계약을 구현하고 이를 목록에 추가하여 소프트웨어 동반자에 대한 지원을 구현합니다. ERC-4337을 완벽하게 지원하는 계약을 구축하는 것이 좋습니다.

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

페이지 마지막 업데이트됨: 2025년 10월 22일

p (opens in a new tab)

w (opens in a new tab)

c (opens in a new tab)

+6

기여자 확인하기