以太坊EIP-8141新提案：不動交易信封，靠「框架」擴充功能引熱議

以太坊（ETH）開發者正在為EIP-8141微調設計方向，希望在不改變交易信封（transaction envelope）的前提下擴充交易功能。這項提案的核心，是把交易到期時間、聚合簽章、隱私池默克爾根（Merkle root）等功能，改以合約呼叫的「框架」形式呈現，而不是直接塞進交易信封裡。

據Wu Blockchain（吳說區塊鏈）報導，以太坊開發者Derek Chiang於台灣時間7日清晨5時37分，說明了EIP-8141最新的設計方向。EIP-8141官方文件將此提案稱為「框架交易」（Frame Transaction），定義為一種新的交易類型，把交易驗證、執行與手續費支付拆分成多個框架來處理。

這項設計的重點，在於盡量不去更動交易信封本身。交易信封是錢包、區塊瀏覽器、軟體開發套件（SDK）與第二層（Layer2，L2）基礎設施共同讀取的基本格式，一旦更動，受影響的不只是以太坊主網，周邊工具與服務也得跟著調整。

EIP-8141等於是把新功能塞進「框架」裡，藉此降低整體協調成本。以太坊升級週期本來就長，如果每次新增交易功能都得動到交易信封，整個生態系的因應成本可能會愈墊愈高，這正是提案背後的問題意識。

根據EIP-8141文件，框架交易會把驗證、手續費支付授權、使用者操作執行拆分成有先後順序的多個框架。文件顯示，這種交易類型最多可容納64個框架，且每個框架各自設有獨立的執行氣體（gas）與狀態氣體上限。

對一般使用者而言，這套設計與批次交易、替代手續費支付、金鑰更換等「帳戶抽象化」（account abstraction）功能息息相關。過去使用者大多被綁在私鑰管理與持有ETH繳費的模式上，一旦帳戶抽象化落地，智慧帳戶、代付交易、多筆操作一次處理等功能都能更廣泛地被應用。

不過框架方案在帶來彈性的同時，也引發複雜度的爭論。Chiang在上個月25日發布於Ethlabs的文章中寫道，以太坊核心開發者社群近來傾向接受框架的彈性，而不是採用較僵化的帳戶抽象化提案。同一篇文章也提到，Base提交的EIP-8130再度掀起這場爭論。

EIP-8130是透過鏈上帳戶設定與新交易類型來實現帳戶抽象化的提案。官方文件說明，交易可明確指定要使用的驗證者（authenticator），讓節點不必執行任意錢包程式碼即可過濾交易，這與EIP-8141試圖透過框架讓驗證與執行更廣泛抽象化的取向並不相同。

Wu Blockchain報導指出，Chiang認為過度抽象化可能降低交易的可讀性。因此開發者正評估把EIP-8141與帳戶標準EIP-8130結合，在框架之上加上結構性限制，希望在維持彈性的同時，補強錢包與基礎設施能夠解讀的框架。

本刊先前報導，EIP-8141的實作追蹤與框架測試網討論仍在持續進行，當時就有評估指出，光是實作議題保持開放，並不代表已經確定會納入主網或特定升級版本。

這次的討論顯示，以太坊交易格式的研究，已經從單純擴大處理量，走向重新設計交易結構本身的階段。爭論焦點在於：該驗證的條件與實際要執行的動作，應該分離到什麼程度，而錢包與L2又該如何解讀這樣的結果。

對台灣用戶而言，這項討論影響的與其說是短期價格，不如說是使用體驗。如果框架結構真的被採用，錢包的手續費處理方式、多筆操作的批次執行、帳戶救援或金鑰更換的方式都可能隨之改變。反過來說，如果實作負擔加重，錢包與基礎設施業者的因應速度就會成為關鍵。

EIP-8141目前在官方文件上仍屬草案階段，是否真的會納入主網、何時實施，都要等核心開發者討論與用戶端測試完成後才能確定。