以太坊開發者近期披露，EIP-8141 的設計取得新進展。該提案嘗試將部分交易功能以可編程合約調用的形式（即「frames」）實現，而非每增加一項功能就修改一次以太坊交易封裝格式。
交易功能已改為可程式化呼叫
此思路涵蓋的功能包括交易到期、聚合簽名、與隱私池相關的 Merkle 樹根，以及交易執行後的斷言檢查。開發者認為，若此套介面足夠通用，當以太坊今後引入新的驗證方式時，錢包、瀏覽器、簽名設備和 Layer 2 無需每次都適配新的交易外殼。
EIP-8141 草案將一筆 Frame Transaction 定義為一組合約調用序列。不同的 frame 可負責驗證交易條件、批准 gas 支付，或執行用戶操作。
目前草案列出了三種模式：DEFAULT、VERIFY 和 SENDER。其中，VERIFY frame 用於檢查某項條件是否滿足，SENDER frame 則代表以交易發送者身份執行操作。多個 frame 還可以組成原子批處理，即要么全部成功，要么整體回滾。
降低錢包與基礎設施協調成本
開發者 Derek Chiang 的核心觀點是，未來新增功能未必都要再設計一套新的交易封裝。只要通過新的 frame 目標和調用模式表達，就可能在保持基礎結構穩定的前提下擴展能力。
以太坊每次修改交易封裝，影響範圍並不只在執行客戶端。錢包、Layer 2、區塊瀏覽器、簽名硬體、軟體庫和各類基礎設施服務商，都要理解並支援新格式。
Chiang 表示，以太坊升級大約每九個月推進一次，若頻繁更改交易封裝，協調成本會很高。相比之下，若 frame 格式能成為較穩定的介面，新驗證方法就可以更多交由合約或指定協議組件處理。
不過，這並不意味著未來所有功能都能繞開網絡升級。EIP-8141 本身仍會修改以太坊共識規則，需要客戶端實現。若涉及新操作碼、預編譯合約或 gas 規則，仍可能需要硬分叉。
EIP-8130 與並行驗證方向
開發者也承認，隨著交易抽象程度的提高，錢包和排序器在執行前分析交易會更加困難。為此，團隊正在研究 EIP-8141 與另一份帳戶抽象草案 EIP-8130 的配合方式。
EIP-8130 提出鏈上 keystore 結構，讓帳戶預先登記參與者和認證合約，並在交易中明確標註認證方式。這樣一來，節點在運行任意錢包代碼前，就能先判斷交易需要哪種驗證流程。對 Layer 2 來說，這有助於限制為一組成本更可預測的認證方式。
Vitalik Buterin 也在另一篇帖子中解釋了相關方向。他將交易拆分為「動作」和「依賴條件」兩部分。前者負責改變以太坊狀態，後者則包括簽名、Merkle 證明或零知識證明等前置條件。若這些依賴彼此獨立，未來就可能並行檢查，從而降低部分交易的處理成本。
已列入 Hegotá，但激活時間未定
官方 Hegotá Meta EIP 已將 Frame Transactions 列為計劃納入的升級內容之一，這意味著其狀態較此前更進一步。但 EIP-8141 目前仍是核心草案，技術細節尚未最終敲定。
接下來仍需推進的工作包括：更新規範、完成執行客戶端實現、搭建開發網絡，以及與錢包和 Layer 2 系統進行互操作測試。開發者還需要評估內存池拒絕服務風險，因為可程式化驗證可能提高篩除無效交易的計算成本。
目前，Hegotá 的 Sepolia、Hoodi 和主網激活時間仍為空白。EIP-8141 已進入升級計劃，但距離最終落地還有一段實現和測試過程。