撰文：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 操作。
This way, the Gas payment and the main transaction can be included in the same atomic process—either both succeed or both are rolled back.
對用戶而言，最直觀的變化是，許多過去必須拆分成兩三步、且中間存在失敗風險的操作，未來將更像一次完整的動作，因此這種原子性也是 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á，這場討論本身至少已經說明了一件事：
Ethereum 沒有坐等問題惡化，而是在穩步為下一代賬戶體系鋪路。