EIP-7702는 간단한 이더리움 지갑(EOA)이 스마트 계약 지갑으로 업그레이드될 수 있게 하여 더 높은 보안성, 고급 기능, 가스 후원 기회 및 기타 이점을 제공합니다. 역사적으로 스마트 지갑은 처음부터 구축되어야 했지만, EIP-7702의 도입으로 기존 지갑을 업그레이드할 수 있으며 모든 자산과 온체인 히스토리를 유지하고 동일한 지갑 주소를 유지할 수 있습니다. 이는 새 번호 없이 유선 전화에서 스마트폰으로 전환하는 것과 같습니다.
[이하 생략]驗證器是一個特定於 implementation 的合約，其中包含用於評估其是否認為最終帳戶狀態安全的邏輯。例如，對於 CoinbaseSmartWallet，CoinbaseSmartWalletValidator 將檢查帳戶的所有權狀態是否為非空，因此不再容易受到任意初始化的影響。
도전 #2: EIP-7702 위임에 걸친 공유 저장소
EIP-7702의 가장 복잡한 도전은 아마도 저장소 관리와 관련될 것입니다. EOA는 언제든지 자유롭게 해당 로직을 다른 계약에 다시 위임하거나 완전히 위임을 삭제할 수 있습니다. 모든 위임은 EOA 주소의 동일한 저장소 공간을 공유합니다. 시간이 지남에 따라 여러 계약이 동일한 저장소에 대한 접근을 공유하면 "저장소 충돌" 문제가 발생할 수 있습니다. 두 계약이 동일한 저장소 위치에 대해 서로 다른 변경을 수행하거나 서로 다른 가정을 할 때 저장소 충돌이 발생하며, 이는 예측할 수 없는 오류로 이어질 수 있습니다.
저장소 충돌 관리는 이미 프록시 설계 영역에서 익숙한 문제로, 변경 가능한 구현 로직을 사용하여 공유 저장소를 관리합니다. 업그레이드 가능한 프록시가 구현을 변경할 수 있더라도, 프록시 코드 자체(비 7702 주소의 경우)는 변경할 수 없습니다. 이는 업그레이드 프로세스에 확정성과 보장을 제공합니다. 7702 재위임은 이 공유 저장소를 관리할 수 있는 잠재적 로직에 완전히 가변적인 계층을 도입합니다. 이는 기본적으로 임의 위임이 저장소에 미칠 수 있는 영향에 대한 모든 보장을 제거합니다.
예를 들어, EOA가 위임 A에서 B로 위임한 다음 다시 A로 위임하면, 반환된 위임은 해당 저장소 상태에 대해 어떤 가정도 할 수 없습니다. 위임 B는 저장소를 지우거나 위임 A의 로직만으로는 달성할 수 없는 상태로 조작했을 수 있습니다. 이는 위임 패턴과 관계없이 모든 7702 위임에 적용됩니다. 이전 위임이 어떤 저장소 위치에서든 무언가를 저장하거나 삭제했을 수 있기 때문입니다.
A → B → A 위임 패턴으로 인한 위임 A의 무효 상태 예시
솔루션: 중요 저장소 값의 외부화
EOA 위임은 계정 상태에 임의로 영향을 미칩니다. EOA가 악의적이거나 파괴적인 계약에 위임하면 현재 위임으로는 이를 방지할 수 없습니다. 서명된 드레이너 트랜잭션과 마찬가지로, 악의적인 7702 위임을 승인하면 재앙적인 결과를 초래할 수 있으며, 이러한 결과를 방지하는 것은 우리의 설계 범위를 벗어납니다.
(이하 생략)스마트 계약의 서명 검증 표준은 표준 EOA와 다릅니다. 스마트 계약은 ERC-1271에서 정의된 isValidSignature 인터페이스를 구현하고, 계약이 서명을 유효하다고 간주하는 임의의 로직을 자유롭게 정의할 수 있습니다. 표준 EOA의 경우, 서명은 표준 ecrecover 검사를 통해 검증되며, 이 검사는 서명자가 예상된 EOA 주소로 복구되는지 확인합니다.
7702 업그레이드 후 기존 또는 향후 EOA 서명이 계속 EOA에서 인정되도록 보장하기 위해, EIP7702Proxy는 먼저 서명 검증을 논리적 구현에 정의된 isValidSignature 함수에 위임하고, 검증에 실패하면 최종 ecrecover 검사를 수행하는 isValidSignature 버전을 구현합니다. 이 검사를 통과하면 서명이 유효한 것으로 간주됩니다. 이러한 방식으로 EIP7702Proxy를 사용하는 EOA는 스마트 계약 지갑의 isValidSignature 구현과 관계없이 간단한 EOA 서명이 항상 해당 주소에서 인정됨을 보장할 수 있습니다.
토큰 수신
일부 토큰 표준(특히 ERC-1155 및 ERC-721)은 토큰이 관리할 수 없는 스마트 계약에 갇히는 것을 방지하려고 합니다. 이러한 토큰은 토큰을 수신하는 모든 스마트 계약이 표준 토큰 수신기 인터페이스를 구현하여 이 기능을 선언하도록 요구하며, 이 인터페이스는 토큰 전송 중에 토큰 계약에 의해 호출됩니다. 마찬가지로 중요한 것은 업그레이드된 EOA의 로직에 네이티브 토큰을 수신할 수 있는 표준 receive 함수 또는 payable 폴백이 포함되어야 한다는 것입니다. 계정은 매우 짧은 시간이라도 ETH 또는 다른 토큰을 수신할 수 없는 상태여서는 안 됩니다.
초기 구현이 없는 우리의 프록시로 인해, ERC-1967 포인터가 없을 때 EIP7702Proxy의 기본 로직으로 변경할 수 없는 DefaultReceiver 구현을 포함했습니다. 이 수신기는 receive 함수와 이러한 일반적인 토큰 표준의 수신기 후크를 구현하여 새 구현을 명시적으로 설정하기 전에 계정이 토큰 전송을 수락할 수 있도록 보장합니다.
결론
EIP7702Proxy 설계는 표준 배포된 CoinbaseSmartWallets와 긴밀하게 일치하고 기존 CoinbaseSmartWallet 구현을 계속 사용하면서 EIP-7702 컨텍스트에서 발생하는 고유한 보안 과제를 해결할 수 있게 해줍니다. 초기화 보안, 스토리지 일시성 및 간섭의 영향, 중단 없는 토큰 처리에 대한 요구, 표준 EOA 서명 검증과의 역방향 호환성을 신중하게 고려함으로써, 우리는 EIP-7702 스마트 계약 지갑을 안전하게 위임하고 관리하기 위한 프록시를 구축했습니다. EIP7702Proxy의 설계는 CoinbaseSmartWallet V1 구현을 고려했지만, 이 프록시는 궁극적으로 구현과 무관합니다. 우리는 개발자들이 이 솔루션을 평가하여 다른 스마트 계약 지갑 구현에 대해 7702 보호를 수행하기를 권장합니다.
원문 링크：https://blog.base.dev/securing-eip-7702-upgrades
블록템포(BlockTempo) AI 어시스턴트가 우수한 영어 기사를 번역해 드렸습니다. 번역이 불분명한 부분이 있다면 양해 부탁드립니다.
블록템포(BlockTempo)는 고품질 기술 콘텐츠 플랫폼과 오프라인 공간을 통해 개발자가 더 나은 Web3 빌더가 되도록 돕는 Web3 개발자 커뮤니티입니다.
블록템포(BlockTempo) 웹사이트 : learnblockchain.cn
개발자 기술 인증 : decert.me
B 스테이션 : space.bilibili.com/581611011
유튜브 : www.youtube.com/@upchain
