撰文：imToken

上週，以太坊核心開發者會議上正式討論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 驗證自身願意承擔費用的條件，隨後完成對應資產的費用支付，最後再執行真正的swap 操作操作。

這樣一來，Gas 支付與主交易就能被納入同一條原子流程裡，要麼全部成功，要麼全部回滾。

對使用者來說，最直觀的變化就是許多以前必須拆成兩三步驟、並且中間存在失敗風險的操作，未來可以更像一次完整動作，因此這種原子性也是EIP-8141 想解決用戶體驗碎片化問題的關鍵之一。

那這對錢包用戶意味著什麼？從結果來看，最直觀的變化至少有四層：

• Gas 支付被抽象：錢包裡有穩定幣，不再意味著你還必須額外準備一點ETH 才能操作，未來由DApp、Paymaster 或其他贊助方代付Gas，會變得更原生；
• 多步驟操作合併：像「授權+ Swap」「授權+ 質押」這類現在經常需要多次簽名的流程，有機會被打包成一筆更完整的操作；
• 帳戶安全規則被打開：多簽、社交恢復、每日限額、時間鎖、金鑰輪換，這些都不再只是某個錢包產品額外提供的高級功能，而開始有機會建立在更原生的帳戶邏輯之上；
• 簽章方案不再必須被ECDSA 單一路徑鎖死：這讓帳號未來遷移到不同密碼體系，包括後量子簽章方案，第一次擁有了協定層意義上的可能性；

三、為什麼沒成為Hegotá 的頭牌？

一個很容易被忽略、但對錢包用戶來說非常關鍵的點是：即便EIP-8141 最終落地，現有帳戶體係也不會因此被整體推翻。

即使你現在使用的是imToken 等既有的Web3 錢包，也不需要遷移，因為它向後相容，現有的EOA 位址可以繼續使用，只需要在適當的時候選擇「升級」帳號的驗證邏輯。

但反過來看，也恰恰是因為它改得足夠深，它才沒有在最新一輪討論裡直接成為Hegotá 的頭牌功能。不過，依照2026 年的EIP champion 流程，CFI（Considered for Inclusion） 的意思並不是被否定，而是進入認真考慮階段，但還沒到最終拍板上線的時候。

換句話說，核心開發者並不是不認可EIP-8141 的方向，而是在承認其價值的同時，也認為它目前仍然太「重」。

畢竟原生帳戶抽像不像ERC-4337 那樣可以先由少數錢包、基礎設施和應用逐步推動，它一旦進入協議層，就意味著所有執行層客戶端都要認真實現、測試和協同，這會天然提高推進門檻，也會讓核心開發者在fork 規劃時更偏向穩妥。

那接下來會發生什麼事？可以拆成兩條線來看：

• EIP-8141 既然處於CFI 狀態，就說明它仍在被持續評估之中，提案作者會繼續補足圍繞交易池安全、驗證規則和客戶端實現的關鍵細節，後續ACD 會議也會重新審視它是否具備進一步前推的條件；
• 如果這些不確定性能夠被持續壓縮，它就有機會在後續升級中進入更實質的納入階段；如果不能，它也完全可能被順延到更晚的升級週期；

實事求是地說，EIP-8141 也並非唯一的原生帳戶抽象提案，本身更不是某種現成的後量子簽名方案，無法直接解決量子計算問題，但它的重要性在於，它第一次為帳戶擺脫ECDSA 單一路徑提供了協議層意義上的出口。

從這個角度看，EIP-8141 的真正價值，並不在於它是不是唯一正確答案，而在於它把“原生帳戶抽象的終局究竟應該長什麼樣”這個問題，第一次非常完整地擺到了以太坊協議討論的桌面上。

它不是唯一方案，但它確實是目前最雄心勃勃、也最接近「完整原生AA」想像力上限的方案之一。

無論EIP-8141 最終是否能趕上Hegotá，這場討論本身至少已經說明了一件事：

以太坊並沒有在原地等待問題發酵，而是在用日拱一卒地為下一代帳戶體系提前鋪路。