EIP-7702는 기존 이더 지갑(EOA)을 스마트 컨트랙트 지갑으로 업그레이드하여 보안 강화, 고급 기능, 가스 후원 기회 및 기타 이점을 제공합니다. 과거에는 스마트 지갑을 처음부터 구축해야 했지만, EIP-7702가 도입됨에 따라 기존 지갑도 업그레이드하여 모든 자산과 온체인 기록을 보존하면서 동일한 지갑 주소를 유지할 수 있습니다. 마치 새 번호 없이 유선 전화에서 스마트폰으로 갈아타는 것과 같습니다.
EOA는 위임 스마트 컨트랙트를 가리키는 "위임 지정"을 설정하여 업그레이드됩니다. 위임 스마트 컨트랙트는 스마트 컨트랙트의 로직을 위임하여 EOA를 관리합니다. 결과적으로 업그레이드된 EOA는 기능을 포함하고, 저장소를 설정하고, 이벤트를 발생시키고, 스마트 컨트랙트가 수행할 수 있는 모든 작업을 수행할 수 있습니다. EOA는 새롭게 서명된 EIP-7702 권한을 통해 언제든지 이 위임을 변경하거나 제거할 수 있습니다. 이는 많은 새로운 가능성을 열어주지만, 이 강력한 기능은 신중한 고려와 혁신적인 해결책이 필요한 새로운 보안 과제를 야기하기도 합니다.
EOA가 스마트 계약 지갑 역할을 할 수 있도록, EOA의 EIP-7702 위임자로 사용하도록 설계된 경량 ERC-1967 프록시 계약인 EIP7702Proxy를 개발했습니다. 프록시가 수행하는 기본 로직 전달 외에도, EIP7702Proxy는 EIP-7702 위임 계정의 고유한 몇 가지 과제를 해결하는 다른 기능과 설계 옵션을 포함하고 있습니다. EIP7702Proxy를 설계할 때 한 가지 목표는 "표준 배포" 코인베이스 스마트 지갑과 EIP-7702 위임 코인베이스 스마트 지갑 간의 동등성을 최대한 유지하는 것이었습니다. 즉, EIP-7702 메커니즘에 필요한 추가적인 복잡성을 전용 프록시로 추상화하고 CoinbaseSmartWallet의 기존 구현을 계속 사용하는 것을 의미했습니다. 이 과제에 대한 해결책은 CoinbaseSmartWallet 구현뿐만 아니라 모든 구현 로직에 효과적으로 적용될 수 있으며, 7702 지원 환경에서 EOA의 보안을 유지하는 데에도 도움이 됩니다.
아래에서는 EIP-7702 업그레이드와 함께 사용할 기존 스마트 계약 지갑 구현을 안전하게 적용할 수 있는 구체적인 과제와 해당 설계 솔루션을 설명합니다.
과제 1: 보안 초기화 시행
EIP-7702 구현의 첫 번째 주요 장애물은 초기화 제약 조건입니다. 기존의 스마트 컨트랙트 지갑(CoinbaseSmartWallet 포함)은 일반적으로 배포 과정에서 별도의 팩토리 컨트랙트를 통해 보안 초기화(계정 소유권 설정)를 원자적으로 처리합니다. 이러한 원자성으로 인해 이러한 구현에는 한 번만 호출될 수 있는 보호되지 않은 초기화 함수가 많이 있습니다. 그러나 EIP-7702의 설계상 코드 위임 프로세스("배포"와 동일한 단계) 중에 초기화 호출 데이터를 수행할 수 없으므로, 이 작업은 원자적으로 수행될 수 없습니다.
이러한 단계 분리는 심각한 취약점 발생 가능성을 야기합니다. 구현 계약이 EIP-7702를 통해 EOA에 "배포"될 때, 이 7702 업그레이드와 지갑을 초기화하는 표준 EVM 트랜잭션이 원자적으로 실행된다는 보장은 없습니다. 기술적으로, 권한 부여를 설정하는 코드는 초기화 트랜잭션과 동시에 제출되더라도 독립적으로 적용될 수 있으며, 이는 공격자가 초기화 트랜잭션을 선제적으로 실행하고 스마트 계정의 소유권을 주장할 수 있도록 허용합니다.
해결 방법: EOA 서명이 구현을 원자적으로 설정하고 초기화하도록 요구합니다.
기존 Coinbase Smart Wallet은 UUPSUpgradeable 구현(실제 CoinbaseSmartWallet 로직)을 사용하는 ERC-1967 프록시 뒤에 배포됩니다. 실제 계정 주소의 코드는 ERC-1967에서 정의한 일반적인 저장 위치를 사용하여 구현 로직에 대한 포인터를 저장하는 프록시입니다. 7702와 관련된 초기화 취약점에 대한 저희의 해결책은 모든 구현 로직이 프록시가 실제로 연결을 설정할 때만 활성화(따라서 위험)된다는 점을 인지하는 것입니다. 따라서 원자적 배포 및 초기화를 강제할 수 없는 경우, 원자적 구현 설정 및 초기화를 강제할 수 있습니다.
EIP-7702의 맥락에서 EOA 자체는 계정 변경을 수행하는 최초 권한자이며, 모든 소유자에게 새로운 스마트 계정을 초기화하고 설정할 수 있는 권한을 부여하는 서명을 제공해야 합니다. EIP7702Proxy 계약은 새로운 논리적 구현을 원자적으로 설정하고 계정을 초기화하는 setImplementation 함수를 구현합니다. setImplementation 함수는 다음과 같습니다.
새로운 구현 계약의 주소, 초기화 호출 데이터, 최종 계정 상태의 안전성을 평가할 검증자 계약의 주소, nonce 및 만료 시간과 같은 기본 서명 재생 보호와 같은 주요 데이터가 포함된 EOA의 서명을 확인합니다.
ERC-1967 포인터 값을 새 구현으로 설정하고 제공된 calldata를 새 논리 구현에 대해 실행합니다. 서명에 포함된 검증자가 구현해야 하는 validateAccountState 함수를 호출합니다. 검증자는 최종 계정 상태가 안전한지 여부를 평가하는 로직을 포함하는 구현별 계약입니다. 예를 들어, CoinbaseSmartWallet의 경우, CoinbaseSmartWalletValidator는 계정의 소유권 상태가 null이 아니므로 임의 초기화에 더 이상 취약하지 않은지 확인합니다.
과제 2: EIP-7702 위임 간 공유 스토리지
EIP-7702의 가장 복잡한 과제는 아마도 스토리지 관리와 관련이 있을 것입니다. EOA는 언제든지 로직을 다른 계약으로 재위임하거나 위임을 완전히 삭제할 수 있습니다. 모든 위임은 EOA 주소에서 동일한 스토리지 공간을 공유합니다. 시간이 지남에 따라 여러 계약이 동일한 스토리지에 대한 접근 권한을 공유하면 "스토리지 충돌" 문제가 발생할 수 있습니다. 스토리지 충돌은 두 계약이 동일한 스토리지 위치에 대해 서로 다른 변경 사항을 적용하거나 서로 다른 가정을 할 때 발생하며, 이로 인해 예측할 수 없는 오류가 발생할 수 있습니다.
저장소 충돌 관리는 공유 저장소를 관리하기 위해 변경 가능한 구현 로직을 사용하는 프록시 설계 분야에서 이미 익숙한 문제입니다. 업그레이드 가능한 프록시는 구현을 변경할 수 있지만, 프록시 코드 자체(7702 주소가 아닌 경우)는 변경할 수 없습니다. 이는 업그레이드 프로세스에 결정성과 안정성을 제공합니다. 7702 재위임은 이 공유 저장소를 관리할 수 있는 기본 로직에 완전한 가변성을 제공하는 또 다른 계층을 도입합니다. 이는 임의 위임이 저장소에 미칠 수 있는 영향에 대한 모든 안정성을 근본적으로 제거합니다. 예를 들어, EOA가 A 대리자에서 B로, 그리고 다시 A로 위임하는 경우, 반환된 대리자는 저장소 상태에 대해 가정할 수 없으며, B 대리자가 저장소를 삭제했거나 대리자 A의 로직만으로는 달성할 수 없는 상태로 조작했을 수 있습니다. 이는 위임 모드와 관계없이 모든 7702 위임에 해당합니다. 이전 대리자가 어떤 저장소 위치에든 저장하거나 삭제했을 수 있기 때문입니다.
솔루션: 안전에 중요한 저장 값의 외부화
EOA 위임은 계정 상태에 임의로 영향을 미칠 수 있습니다. EOA가 악의적이거나 파괴적인 계약에 위임된 경우, 현직 위임자는 이를 방지할 방법이 없습니다. 드레인 거래 서명과 마찬가지로, 악의적인 7702 위임을 승인하는 것은 치명적인 결과를 초래할 수 있으며, 이러한 결과로부터 보호하는 것은 저희 설계 범위를 벗어납니다. EXIP7702Proxy는 선의를 가지고 있지만 잠재적으로 혼란스러운 참여자들로 구성된 다중 지갑 7702 기반 생태계에서 예측 가능한 문제로부터 자체 방어하도록 설계되었습니다. 하지만 실제로 악의적이거나 버그가 있는 위임을 승인하는 EOA로부터는 보호할 수 없습니다.
예측 가능한 문제 중 하나는 setImplementation 호출의 시그니처와 변경 가능한 계정 상태로 인한 리스크 과 관련이 있습니다. EIP7702Proxy는 EOA 시그니처를 사용하여 구현 로직을 설정하고 안전한 상태로 초기화합니다. 이러한 시그니처가 재사용될 수 있다면, 이는 문제가 될 수 있습니다. 예를 들어, 시그니처가 최초 소유자를 승인했지만 나중에 침해되어 삭제된 경우, 재사용 가능한 시그니처는 침해된 소유자를 재생성하거나 구현을 강제로 다운그레이드할 수 있습니다.
서명 리플레이를 방지하는 일반적인 보호조치 은 서명 메시지에 논스를 사용하고 검증 후 사용됨으로 태그 입니다. 7702 계정에 대한 리스크: 다른 위임으로 인해 이 논스 추적 저장소가 손상될 수 있습니다. 저장소 추적 논스 사용이 삭제되면 EOA의 setImplementation 서명(mempool에서 공개적으로 사용 가능)이 EIP7702Proxy로 다시 위임할 때 다시 적용될 수 있습니다.
서명이 재생되지 않도록 하기 위해 계정 저장소 외부의 변경 불가능한 계약 위치에 nonce 상태를 유지하는 별도의 NonceTracker 싱글턴을 구현했습니다. EOA만 자신의 nonce에 (점진적으로만) 영향을 미칠 수 있으므로 다른 위임자가 이러한 보안에 중요한 값을 조작하는 것을 방지합니다. NonceTracker는 계정 저장소의 변경 사항과 관계없이 각 setImplementation 서명이 한 번만 작동하도록 보장합니다.
과제 3: 기존 저장 위치 공유로 인한 리스크 증가
ERC-1967에서 정의한 것과 같은 표준 스토리지 슬롯은 여러 대리자 구현에서 사용할 수 있는 일반적인 위치이기 때문에 잠재적인 스토리지 충돌에 특히 취약합니다. ERC-1967 구현 슬롯은 EIP7702Proxy에서 사용되는 유일한 표준 스토리지 위치이며, 프록시가 가리키는 로직 구현의 주소를 저장합니다. 저희 설계는 이 스토리지 위치의 값(계정에서 사용 가능한 대부분의 로직을 결정함)에 관계없이 EIP7702Proxy가 항상 EOA에서 기대하는 계약에 구현 로직을 성공적으로 설정할 수 있도록 보장합니다.
해결 중인 문제를 더 명확하게 설명하기 위해, 계정이 서로 다른 위임(A→B→A) 간에 전환될 때(두 위임 모두 ERC-1967 프록시 패턴을 구현하는 경우), 위임 B는 위임 A가 구현 주소 저장에 사용하는 것과 동일한 저장 슬롯을 자연스럽게 사용한다는 점에 유의하십시오. 위임 B는 위임 기간 동안 의도적으로 또는 자체 위임의 정상적인 부분으로 이 슬롯을 수정하거나 덮어쓸 수 있습니다. UUPSUpgradeable 프록시 패턴에서 구현을 업그레이드하는 로직은 구현 계약 자체에 정의됩니다. 위임 B가 이 포인터 위치에 배치하는 구현에 해당 구현에서 예상되는 upgradeToAndCall 인터페이스가 포함되어 있지 않으면, 위임 A로 돌아갈 때 현재 사용 가능한 로직에는 구현을 변경하는 메커니즘이 존재하지 않을 수 있습니다.
솔루션: EIP7702Proxy에서 업그레이드 메커니즘을 사용할 수 있습니다.
EIP7702Proxy는 구현과 무관한 업그레이드 메커니즘을 프록시 자체에 직접 제공하는 setImplementation 함수를 통해 이 문제를 해결합니다. 이를 통해 중간 위임자가 ERC-1967 구현을 유효하지 않은 구현으로 지정했거나 완전히 제거했더라도, EIP7702Proxy로 다시 위임한 후 원래 EOA는 프록시의 ERC-1967 포인터를 재구성하여 원하는 논리적 구현을 가리킬 수 있습니다.
과제 4: 표준 EOA 동작과의 하위 호환성
EIP7702Proxy의 설계 목표 중 하나는 새로운 스마트 계약 기능 외에도 계정 EOA 기능과의 하위 호환성을 유지하는 것입니다. 주소에 코드가 있는지 없는지는 해당 주소와 상호 작용하는 프로토콜의 실행 흐름에 영향을 미칩니다. 프로토콜은 이 기능을 사용하여 EOA와 스마트 계약을 구분하기 때문입니다. 고려해야 할 두 가지 주요 동작은 서명 검증과 토큰 수신 동작입니다.
서명 확인
스마트 컨트랙트의 서명 검증 표준은 표준 EOA와 다릅니다. 스마트 컨트랙트는 ERC-1271에서 정의한 isValidSignature 인터페이스를 구현하며, 컨트랙트에서 서명의 유효성 여부를 판단하는 임의의 로직을 자유롭게 정의할 수 있습니다. 표준 EOA의 경우, 서명은 표준 ecrecover 검사를 통해 검증되며, 이를 통해 서명자가 예상 EOA 주소로 복귀하는지 확인합니다.
7702 업그레이드 후에도 기존 또는 향후 EOA 서명이 EOA에서 계속 인식되도록 EIP7702Proxy는 isValidSignature 함수를 구현합니다. 이 함수는 먼저 서명 검증을 로직 구현에 정의되어야 하는 isValidSignature 함수에 위임합니다. 검증이 실패하면 최종 ecrecover 검사를 수행합니다. 이 검사가 통과하면 서명은 유효한 것으로 간주됩니다. 이러한 방식으로 EIP7702Proxy를 사용하는 EOA는 스마트 계약 지갑의 isValidSignature 구현 여부와 관계없이 간단한 EOA 서명이 항상 해당 주소에서 인식되도록 보장할 수 있습니다.
토큰 수신
일부 토큰 표준(특히 ERC-1155 및 ERC-721)은 토큰을 관리할 수 없는 스마트 계약에 토큰이 묶이는 것을 방지합니다. 이러한 토큰은 토큰을 수신하는 모든 스마트 계약이 토큰 전송 중에 토큰 계약에서 호출하는 표준 토큰 수신자 인터페이스를 구현하여 이러한 기능을 알리도록 요구합니다. 또한 업그레이드된 EOA의 로직에 네이티브 토큰을 수신할 수 있도록 표준 수신 함수 또는 지불 가능한 대체 수단을 포함하는 것이 중요합니다. 계정은 단기간이라도 ETH 또는 기타 토큰을 수신할 수 없는 상태로 방치되어서는 안 됩니다.
프록시에 초기 구현이 없으므로, ERC-1967 지표가 없는 경우 EIP7702Proxy의 기본 로직으로 변경 불가능한 DefaultReceiver 구현을 포함합니다. 이 수신자는 이러한 공통 토큰 표준에 대한 수신 함수와 수신 후크를 구현하여, 계정이 새로운 구현을 명시적으로 설정하기 전에 토큰 전송을 허용할 수 있도록 합니다.
결론적으로
EIP7702Proxy 설계를 통해 표준 배포된 CoinbaseSmartWallet과 긴밀하게 연계되고 기존 CoinbaseSmartWallet 구현을 계속 사용하면서 EIP-7702 환경에서 발생하는 고유한 보안 문제를 해결할 수 있습니다. 초기화 보안, 스토리지 시간성 및 간섭의 영향, 중단 없는 토큰 처리의 필요성, 그리고 표준 EOA 서명 검증과의 하위 호환성을 신중하게 고려하여 EIP-7702 스마트 계약 지갑을 안전하게 위임하고 관리하기 위한 프록시를 구축했습니다. EIP7702Proxy는 CoinbaseSmartWallet V1 구현을 염두에 두고 설계되었지만, 이 프록시는 궁극적으로 구현 방식에 구애받지 않습니다. 개발자 여러분께서 다른 스마트 계약 지갑 구현의 7702 보호 기능을 위해 이 솔루션을 평가해 보시기를 권장합니다.
BlockBeats의 블록비츠(theblockbeats) 채용 공고에 대해 알아보려면 여기를 클릭하세요.
블록비츠(theblockbeats) 공식 커뮤니티 에 가입해 주셔서 감사합니다.
텔레그램 구독 그룹: https://t.me/theblockbeats
텔레그램 그룹: https://t.me/BlockBeats_App
공식 트위터 계정: https://twitter.com/BlockBeatsAsia
