原生帳戶抽象 + 抗量子威脅：EIP-8141 為何還沒成以太坊 Hegotá 主打功能？

EIP-8141 由 Vitalik 親自站台，試圖從協議層讓帳戶擺脫單一簽名路徑束縛，支援多簽、Gas 代付、抗量子簽名等功能。儘管獲得「考慮納入」狀態，但因實作複雜度高，尚未成為 Hegotá 升級的主打功能。 （前情提要：能破解比特幣的量子電腦開始動工了？Nvidia 投資的 PsiQuantum 目標明年商轉） （背景補充：量子計算不會殺死加密貨幣，只會逼它變得更加強大） 上週，以太坊核心開發者會議上正式討論 EIP-8141 是否納入 Hegota 升級，結果出人意料，這項由 Vitalik 親自站台的提案，並未被列為 Hegota 的「頭條功能」，而是獲得了「考慮納入」（CFI）的狀態。 而本週，Google 量子 AI 團隊發布最新白皮書，表示在其給定的硬體假設下，破解 ECDLP-256 所需的物理量子位元估算，相比此前大幅下降 20 倍。雖然不代表量子攻擊近在眼前，卻實實在在提醒我們，如果帳戶體系未來無法靈活更換驗證邏輯，那麼今天很多關於錢包體驗的討論，最終都可能演變成安全問題。 雖然站在協議推進的現實角度，EIP-8141 目前仍然太重，尤其是在客戶端實作、交易池安全和驗證複雜度上，尚未形成足夠扎實的共識。 但站在當下這個時間節點，EIP-8141 值得討論和認真審視的地方，似乎真的越來越多。 一、EIP-8141 到底要解決什麼？ EIP-8141 由 Vitalik Buterin 與 timbeiko 等核心貢獻者推動，正式名稱為 Frame Transactions（幀交易）。 如果用一句更容易理解的話概括，它想做的其實不是單獨增加某個錢包功能，而是試圖從協議層讓任何帳戶都不必再被單一的 ECDSA 簽名路徑所束縛，而是可以擁有更靈活的驗證與執行邏輯。 這也意味著，多簽、Gas 贊助、金鑰輪換、社交恢復，甚至未來接入抗量子簽名方案，都不再只是外掛在錢包外部的一層能力，而有機會成為以太坊帳戶體系裡的「原生成員」。 如果只看表面，EIP-8141 討論的，是一組看起來非常具體的能力：用穩定幣支付 Gas、把多步操作合成一筆交易、支援更靈活的簽名方式、甚至為未來的抗量子簽名預留空間。可以說，多年來從 ERC-4337 到 EIP-7702，圍繞錢包體驗的很多改進，本質上都在讓帳戶不再只是一把私鑰，而是一個可以自定義規則的入口。 問題在於，這些改進確實讓錢包越來越像智能帳戶，但始終沒有真正觸及以太坊最底層的預設帳戶模型。 眾所周知，在現有體系下，以太坊帳戶大體分成兩類。一類是外部擁有帳戶，也就是大家最熟悉的 EOA，它由私鑰控制，可以主動發起交易，但缺乏可編程能力；另一類是合約帳戶，也就是智能合約本身，它可以執行複雜邏輯，卻不能自己主動發起交易。 這就導致發起交易的能力，與單一私鑰簽名長期被綁定在一起，只要這個前提不變，很多用戶今天覺得理所當然應該擁有的能力，比如靈活更換簽名規則、讓別人代付 Gas、在私鑰遺失後恢復帳戶控制權，或者未來平滑遷移到新的密碼體系，都很難真正成為帳戶的預設能力。 如果你用過 imToken 或其他 Web3 錢包，你大概率也遇到過這些痛點，譬如錢包裡有一堆 USDC，但沒有 ETH 就發不出交易（因為 Gas 只能用 ETH 支付）；丟了助記詞就徹底丟了錢，無法恢復；一筆「授權 + 交換」的操作要簽名兩次、確認兩次等等。 這些問題，並不是錢包產品「不夠好」，而是以太坊帳戶模型本身的設計結果。 從這個角度看，過去兩年的演進其實已經非常清晰，ERC-4337 在不修改協議的前提下，把帳戶抽象先在應用層跑了起來；EIP-7702 又進一步證明，EOA 並非完全不能擴展，至少可以臨時獲得部分接近智能帳戶的能力。 也就是說，以太坊並不是不想做帳戶抽象，而是一直在用更溫和、更保守的方式，逐步逼近這件事。而 EIP-8141 的出現，意味著這條路徑走到了一個新的節點。它不再滿足於在現有體系外圍再疊一層智能帳戶能力，而是試圖把帳戶抽象直接嵌入交易模型本身，讓帳戶從協議層開始就具備可編程的驗證與執行邏輯。 這也是為什麼 EIP-8141 會在今天重新升溫。一方面，上層錢包體驗已經越來越接近原生帳戶抽象，協議層遲早需要跟上；另一方面，量子計算帶來的長期壓力，也正在把「帳戶能否靈活更換簽名方式」從一個遙遠的技術議題，提前變成必須認真考慮的現實問題。 二、EIP-8141 如何運作？ 歸根結底，EIP-8141 引入了一種全新的交易類型——幀交易（Frame Transaction），交易類型編號為 0x06。 如果說傳統以太坊交易的基本邏輯是一筆交易對應一次呼叫，那麼 EIP-8141 想做的，就是把一筆交易拆解成一組可以按規則順序執行的「幀」，從而把原本捆綁在一起的驗證、付款、執行三件事拆開處理。 每個「幀」有三種執行模式： VERIFY（驗證幀）：負責驗證交易是否合法，它會執行帳戶自定義的驗證邏輯，如果通過，就呼叫新引入的 APPROVE 操作碼來授權執行並指定 Gas 上限。 SENDER（發送幀）：執行實際操作，如轉帳、呼叫合約等。呼叫者位址就是交易發送者本人。 DEFAULT（入口幀）：以系統入口位址作為呼叫者，用於部署合約、驗證 Paymaster 等場景； 這套機制的意義，並不是交易能做得更複雜，而是第一次把「驗證、支付、執行」三件事，從帳戶動作中拆解出來，並交由協議原生排程。 畢竟過去，誰來驗證交易、誰來支付 Gas、誰來執行真實操作，基本都被綁在同一個帳戶動作裡，而在 EIP-8141 的設計下，這幾件事可以被拆成不同的幀，由協議按明確順序依次執行，也正因為如此，帳戶不再只能依賴單一私鑰去「整體簽字」，而開始具備更接近可編程執行主體的形態。 舉個具體例子，假設你想用 USDC 支付 Gas 來完成一筆 Swap，在 EIP-8141 的框架下，這件事理論上可以被組織成一條完整的幀流程：先由帳戶驗證簽名和執行權限，再由支付方或 Paymaster 驗證自身願意承擔費...