透過 Frame 交易實現原生臨時金鑰輪轉

感謝 @mvicari 的貢獻以及 @asanso 的反饋

摘要

這是我們前一篇文章 透過臨時金鑰對與帳戶抽象實現量子安全 (Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction) 的後續研究。

我們提議將臨時金鑰輪替直接整合到 Frame 交易格式 (EIP-8141) 中，而無需獨立的帳戶抽象 (AA) 層。透過添加一個單例註冊表合約 (Singleton Registry Contract)，簽署權限可以在協議層級與鏈上身份解耦。利用 Frame 交易的原生綑綁 (Bundling) 功能，我們可以在每筆交易中添加一個用於輪替簽署者的 Frame，從而以極低的開銷和最高的一致性實現拋棄式 ECDSA 金鑰，使金鑰輪替能統一提供給所有發送者。

動機

EIP-8141 引入了 Frame 交易，將驗證邏輯與交易發送者解耦，為任意簽名方案開啟了大門。獨立地，在我們之前的研究中，我們展示了在每次交易後進行金鑰輪替（在 AA 層實現）能有效中和 ECDSA 面臨的量子威脅，因為每個暴露的金鑰都會立即失效。

Frame 交易已經為這種輪替邏輯提供了一個自然的歸宿：與其在每個智能合約錢包中獨立實現金鑰輪替，我們可以將其內置於交易格式本身，使其統一提供給所有發送者。

設計

該提案需要兩個組件才能運作：

1. 簽署者註冊表合約

部署在已知地址的單例合約，維護帳戶地址與其當前授權簽署者之間的映射：

mapping(address account => address signer) public signerOf;

我們在 Git 倉庫 中建立了一個此註冊表合約的範例實現。

未來，我們計劃升級此合約，使其也包含處理使用 ECDSA 簽名的 Frame 交易整個驗證 (VERIFY) 過程所需的代碼。

2. Frame 交易中的額外 Frame

為了實現輪替，必須添加一個指向單例合約的 Frame，將授權簽署者更改為下一個簽署者。由於 Frame 交易原生支持綑綁，因此可以將此 Frame 添加到任何交易中，而無需更改協議。

驗證流程

在驗證 (VERIFY) Frame 中，會在註冊表中查找 tx.sender 的當前簽署者。交易簽名將針對該簽署者（而非直接針對 tx.sender）進行驗證。

• 如果 signerOf[sender] == address(0)，則用戶簽名直接針對 tx.sender 進行驗證，保留類似 EOA 的行為作為默認設置。

• 如果驗證通過，tx.sender 的註冊表條目將更新為 nextSigner，完成輪替：

signerOf[tx.sender] = nextSigner;

最後一步是在一個額外的 Frame 中完成的，因為驗證 Frame 無法進行狀態更改。

即使其他執行 Frame 發生回滾 (Revert)，此輪替也必須發生，這反映了在基於 AA 的方法中確定的相同不變性：失敗的交易絕不能在不輪替的情況下留下已暴露的當前簽署者。

輪替切換

如果交易中未包含輪替 Frame，則不會發生簽署者輪替，這使得金鑰輪替功能完全是可選的。用戶只需在交易中添加適當的 Frame，即可在任何以太坊帳戶上決定開啟或關閉該功能。

特性

• 簽署與鏈上身份解耦：帳戶地址永遠不會改變；僅輪替授權簽署者。

• 量子緩解：每個私鑰僅使用一次；即使日後被量子計算機破解，也無法授權未來的交易。

• 預設選擇性加入 (Opt-in)：從未寫入註冊表（或永久設置 nextSigner = 0）的帳戶將體驗標準行為，且無額外開銷。

• 無需針對每個錢包的邏輯：發送者與簽署者的解耦是在交易驗證層處理的，而不是在每個合約內部，因此不需要自定義智能錢包實現。

• BIP44 兼容性：nextSigner 地址可以從 BIP44 路徑衍生，使該方案與現有的分層確定性 (HD) 錢包基礎設施兼容。

與基於 AA 的輪替之比較

我們前一篇文章中基於 AA 的方法在智能合約錢包的 validateUserOp 內部實現了相同的輪替，證明了這種方法在今天是可行的，並展示了 ERC20 轉帳約需 13.6 萬 gas。這種 Frame 交易方法的不同之處在於：

• 輪替是一等公民的協議特性，而不是每個錢包的約定。

• 所有 Frame 交易發送者都能受益，而無需部署或升級智能錢包。

        1 則貼文 - 1 位參與者
  
        [閱讀完整主題](https://ethresear.ch/t/native-ephemeral-key-rotation-via-frame-transactions/24526)