保障以太坊 EIP-7702 升級：一種安全 EOA 到智慧錢包過渡的代理模式

我們開發了 EIP7702Proxy，這是一個輕量級的 ERC-1967 proxy 合約，旨在用作 EOA 的 EIP-7702 委託代理基本邏輯轉發….可解決 EIP-7702 委託帳戶特有的一些挑戰。本文源自 登鏈社區 所著文章，由 foresightnews 整理、編譯及撰稿。 （前情提要： 以太坊Pectra升級「駭客爽翻」，Wintermute警告：EIP-7702使大量合約部署自動化攻擊） （背景補充：以太坊基金會「一兆美元安全計畫」發佈首份報告：梳理智能合約、基礎設施與雲安全…六大生態挑戰  ） EIP-7702 使簡單的以太坊錢包（EOA）能夠升級為智慧合約錢包，從而提供更高的安全性、高階功能、Gas 贊助的機會和其他好處。從歷史上看，智慧錢包必須從頭開始建立，但隨著 EIP-7702 的引入，傳統的錢包可以升級，並保留其所有的資產和鏈上歷史記錄，且保持相同的錢包地址。這就像從座機切換到智慧手機而無需獲得新號碼一樣。 EOA 通過設定 「委託指定（delegation designation）」，即指向委託智慧合約（delegate smart contract）的指標來進行升級，然後委託智慧合約的邏輯來管理 EOA。因此，升級後的 EOA 可以擁有函式、設定儲存、發出事件以及執行智慧合約可以執行的所有其他操作。EOA 可以隨時通過新的、已簽名的 EIP-7702 授權來更改或刪除此委託。雖然這解鎖了許多新的可能性，但這個強大的功能也引入了新的安全挑戰，需要仔細考慮和創新解決方案。 為了使 EOA 能夠充當智慧合約錢包，我們開發了 EIP7702Proxy，這是一個輕量級的 ERC-1967 proxy 合約，旨在用作 EOA 的 EIP-7702 委託。除了代理執行的基本邏輯轉發之外，EIP7702Proxy 還包含其他功能和設計選擇，可以解決 EIP-7702 委託帳戶特有的一些挑戰。設計 EIP7702Proxy 的一個目標是使 「標準部署」 的 Coinbase 智慧錢包和 EIP-7702 委託的 Coinbase 智慧錢包之間儘可能地保持對等性，這意味著將 EIP-7702 機制所需的額外複雜性抽象到專用代理中，並繼續依賴 CoinbaseSmartWallet 的原始實現。這種挑戰的解決方案可以有效地應用於任何實現邏輯，而不僅僅是 CoinbaseSmartWallet 實現，同時還有助於 EOA 在啟用 7702 的環境中保持安全。 下面我們將介紹具體的挑戰和相應的設計解決方案，這些解決方案使我們能夠安全地調整任何現有的智慧合約錢包實現，以用於 EIP-7702 升級。 挑戰 #1：強制執行安全初始化 實現 EIP-7702 的第一個主要障礙來自其初始化約束。傳統的智慧合約錢包（包括 CoinbaseSmartWallet）通常通過單獨的工廠合約在其部署期間原子地處理安全初始化（建立帳戶所有權）。這種原子性意味著許多此類實現都具有未受保護的 initializer 函式，這些函式只能被呼叫一次。但是，EIP-7702 的設計不允許在程式碼委託過程（與 「部署」 相當的步驟）期間執行初始化 calldata，因此無法原子地完成此操作。 這種步驟分離會產生一個關鍵的漏洞視窗。當通過 EIP-7702 將實現合約 「部署」 到 EOA 時，無法保證此 7702 升級和初始化錢包的標準 EVM 交易將原子地執行。從技術上講，即使同時提交，設定授權的程式碼也可以獨立於初始化交易應用，這可能允許攻擊者搶先執行初始化交易並宣告智慧帳戶的所有權。 解決方案：需要 EOA 簽名以原子地設定 implementation 並初始化 請注意，現有的 Coinbase 智慧錢包部署在帶有 UUPSUpgradeable 實現（實際的 CoinbaseSmartWallet 邏輯）的 ERC-1967 proxy 之後。實際帳戶地址中的程式碼是一個代理，該代理使用 ERC-1967 定義的常規儲存位置來儲存指向其實現邏輯的指標。我們針對 7702 上下文中的初始化漏洞的解決方案包括認識到任何實現邏輯只有在代理實際建立與其的連線時才會變為活動狀態（因此纔有危險）。因此，如果我們不能強制執行原子性的部署和初始化，我們可以強制執行原子性的實現設定和初始化。 EIP-7702CoinbaseSmartWallet合約架構和邏輯委託流程 在 EIP-7702 的上下文中，EOA 本身是對其帳戶進行任何更改的初始許可權，並且必須提供簽名以授權初始化並建立新智慧帳戶的任何所有者。我們的 EIP7702Proxy 合約實現了一個 setImplementation 函式，該函式可以原子地設定新的邏輯實現並初始化帳戶。setImplementation 函式： 驗證來自 EOA 的簽名，其中包括關鍵資料，例如新 implementation 合約的地址、初始化 calldata、將評估最終帳戶狀態的安全性的驗證器合約的地址，以及基本的簽名可重放保護，例如 nonce 和過期時間。 將 ERC-1967 指標的值設定為新的 implementation，並針對新的邏輯 implementation 執行提供的 calldata。 呼叫 validateAccountState 函式，該函式必須由簽名中包含的驗證器實現。 驗證器是一個特定於 implementation 的合約，其中包含用於評估其是否認為最終帳戶狀態安全的邏輯。例如，對於 CoinbaseSmartWallet，CoinbaseSmartWalletValidator 將檢查帳戶的所有權狀態是否為非空，因此不再容易受到任意初始化的影響。 挑戰 #2：跨 EIP-7702 委託的共享儲存 EIP-7702 最複雜挑戰可能與儲存管理有關。EOA 可以隨時自由地將其邏輯重新委託給不同的合約，或完全刪除委託。所有委託共享 EOA 地址上的...