以太坊協議可能的未來（六）：繁榮篇

有些事物很難歸入單一類別，在以太坊協議設計中，有許多「細節」對以太坊的成功非常重要。實際上，約一半的內容涉及不同類型的 EVM 改進，其餘部分則由各種小衆主題構成，這就是「繁榮」的意義所在。

繁榮：關鍵目標

• 將 EVM 變爲高性能和穩定的「最終狀態」
• 將帳戶抽象引入協議，讓所有用戶享受更安全和便捷的帳戶
• 優化交易費用經濟，提高可擴展性同時降低風險
• 探索先進的密碼學，使以太坊在長期內顯著改善

EVM 改進

解決了什麼問題？

目前的 EVM 難以進行靜態分析，這使得創建高效實現、正式驗證代碼和進行進一步擴展變得困難。此外，EVM 的效率較低，難以實現許多形式的高級密碼學，除非通過預編譯顯式支持。

它是什麼，如何運作？

當前 EVM 改進路線圖的第一步是 EVM 對象格式（EOF），計劃在下一個硬分叉中納入。EOF 是一系列 EIP，指定了一個新的 EVM 代碼版本，具有許多獨特的特徵，最顯著的是：

• 代碼（可執行，但無法從 EVM 中讀取）與數據（可讀取，但無法執行）之間的分離
• 禁止動態跳轉，僅允許靜態跳轉
• EVM 代碼無法再觀察與燃料相關的信息
• 添加了一種新的顯式子例程機制

舊式合約將繼續存在並可創建，盡管最終可能會逐步棄用舊式合約（甚至可能強制轉換爲 EOF 代碼）。新式合約將受益於 EOF 帶來的效率提升。

在引入 EOF 後，進一步的升級變得更加容易，目前發展最完善的是EVM 模塊算術擴展（EVM-MAX）。EVM-MAX 創建了一組專門針對模運算的新操作，並將其放置在一個無法通過其他操作碼訪問的新內存空間中，這使得使用諸如 Montgomery 乘法等優化成爲可能。

一個較新的想法是將 EVM-MAX 與單指令多數據（SIMD）特性結合，SIMD 作爲以太坊的一個理念已經存在很長時間，最早由Greg Colvin 的 EIP-616提出。SIMD 可用於加速許多形式的密碼學，包括哈希函數、32 位 STARKs 和基於格的密碼學，EVM-MAX 和 SIMD 的結合使得這兩種性能導向的擴展成爲自然的配對。

現有研究連結

• EOF:
• EVM-MAX:
• SIMD:

剩下的工作及權衡

目前，EOF 計劃在下一個硬分叉中納入。盡管總是有可能在最後一刻移除它，但這樣做將面臨很大挑戰。移除 EOF 意味着未來對 EVM 的任何升級都需在沒有 EOF 的情況下進行，雖然可以做到，但可能更困難。

EVM 的主要權衡在於 L1 復雜性與基礎設施復雜性，EOF 是需要添加到 EVM 實現中的大量代碼，靜態代碼檢查也相對復雜。然而，作爲交換，我們可以簡化高級語言、簡化 EVM 實現以及其他好處。可以說，優先考慮以太坊 L1 持續改進的路線圖應包括並建立在 EOF 之上。

需要做的一項重要工作是實現類似 EVM-MAX 加 SIMD 的功能，並對各種加密操作的 gas 消耗進行基準測試。

如何與路線圖的其他部分交互？

L1 調整其 EVM 使得 L2 也能更容易地進行相應調整，如果二者不進行同步調整，可能會造成不兼容，帶來不利影響。此外，EVM-MAX 和 SIMD 可以降低許多證明系統的 gas 成本，從而使 L2 更加高效。它還使得通過用可以執行相同任務的 EVM 代碼替代更多的預編譯變得更加容易，可能不會大幅影響效率。

帳戶抽象

解決了什麼問題？

目前，交易只能通過一種方式進行驗證：ECDSA 籤名。最初，帳戶抽象旨在超越這一點，允許帳戶的驗證邏輯爲任意的 EVM 代碼。這可以啓用一系列應用：

• 切換到抗量子密碼學
• 輪換舊密鑰
• 多重籤名錢包和社交恢復錢包
• 使用一個密鑰進行低價值操作，使用另一個密鑰（或一組密鑰）進行高價值操作
• 允許隱私協議在沒有中繼的情況下工作，顯著降低其復雜性，並消除一個關鍵的中央依賴點

自 2015 年帳戶抽象提出以來，其目標也擴展到了包括大量「便利目標」，例如，某個沒有 ETH 但擁有一些 ERC20 的帳戶能夠用 ERC20 支付 gas。

它是什麼，如何運作？

帳戶抽象的核心是簡單的：允許智能合約發起交易，而不僅僅是 EOA。整個復雜性來自於以一種對維護去中心化網路友好的方式實現這一點，並防範拒絕服務攻擊。

經過多年的努力，旨在擴展功能的同時限制拒絕服務（DoS）風險，最終得出了實現「理想帳戶抽象」的解決方案：ERC-4337。

ERC-4337 的工作原理是將用戶操作的處理分爲兩個階段：驗證和執行。所有驗證首先被處理，所有執行隨後被處理。在內存池中，只有當用戶操作的驗證階段只涉及其自身帳戶並且不讀取環境變量時，才會被接受。這可以防止多重失效攻擊。此外，對驗證步驟也強制實施嚴格的 gas 限制。

現有研究連結

• 關於帳戶抽象歷史的演講：
• ERC-4337：
• EIP-7702：
• BLSWallet 代碼（使用聚合功能）：
• EIP-7562（寫入協議的帳戶抽象）：
• EIP-7701（基於 EOF 的寫入協議帳戶抽象）：

剩下的工作及權衡

目前主要需要解決的是如何將帳戶抽象完全引入協議，最近受到歡迎的寫入協議帳戶抽象 EIP 是EIP-7701，該提案在 EOF 之上實現帳戶抽象。一個帳戶可以擁有一個單獨的代碼部分用於驗證，如果帳戶設置了該代碼部分，則該代碼將在來自該帳戶的交易的驗證步驟中執行。

主要的權衡似乎是「快速寫入一種讓較少人滿意的方案」與「等待更長時間，可能獲得更理想的解決方案」，理想的方法可能是某種混合方法。一種混合方法是更快地寫入一些用例，並留出更多時間來探索其他用例。另一種方法是在 L2 上首先部署更雄心勃勃的帳戶抽象版本。

它如何與路線圖的其他部分互動？

包含列表需要支持帳戶抽象交易，在實踐中，包含列表的需求與去中心化內存池的需求實際上非常相似，盡管對於包含列表來說靈活性稍大。此外，帳戶抽象實現應該盡可能在 L1 和 L2 之間實現協調。如果將來我們期望大多數用戶使用密鑰存儲 Rollup，帳戶抽象設計應以此爲基礎。

EIP-1559 改進

它解決了什麼問題？

EIP-1559 於 2021 年在以太坊上激活，顯著改善了平均區塊包含時間。

然而，當前EIP-1559的實施在多個方面並不完美：

1. 公式略有缺陷：它並不是以 50% 的區塊爲目標，而是針對約 50-53% 的滿區塊，這取決於方差。
2. 在極端情況下調整不夠迅速。

後面用於 blobs 的公式（EIP-4844）是專門設計來解決第一個問題的，整體上也更簡潔。然而，EIP-1559 本身以及 EIP-4844 都未嘗試解決第二個問題。

此外，還有其他與 EIP-1559 無關的以太坊資源定價的弱點，但可以通過對 EIP-1559 的調整來解決。其中一個主要問題是平均情況與最壞情況的差異：以太坊中的資源價格必須設置得能夠處理最壞情況，即一個區塊的全部 gas 消耗佔用一個資源，但實際的平均使用遠低於此，導致了低效。

什麼是多維 Gas，它是如何運作的？

解決這些低效問題的方案是多維 Gas：爲不同資源設定不同的價格和限制。這個概念在技術上獨立於 EIP-1559，但 EIP-1559 的存在使得實現這一方案更爲容易。如果沒有 EIP-1559，最優地打包一個包含多種資源約束的區塊就是一個復雜的多維背包問題。而有了 EIP-1559，大多數區塊在任何資源上都不會達到滿負荷，因此「接受任何支付足夠費用的交易」這樣簡單的算法就足夠了。

目前我們已經有了用於執行和數據塊的多維 Gas；原則上，我們可以將其擴展到更多維度：如 calldata（交易數據），狀態讀取 / 寫入，和狀態大小擴展。

EIP-7706引入了一種新的 gas 維度，專門針對 calldata。同時，它還通過將三種類型的 gas 統一到一個（EIP-4844 風格的）框架中，簡化了多維 Gas 機制，從而也解決了 EIP-1559 的數學缺陷。EIP-7623是一種更爲精準的解決方案，針對平均情況與最壞情況的資源問題，更嚴格地限制最大 calldata，而不引入整個新維度。

現有研究連結

• EIP-1559 FAQ: EIP-1559 FAQ
• 關於 EIP-1559 的實證分析: Empirical analysis
• 允許快速調整的改進提案: Proposed improvements
• EIP-4844 FAQ 中關於基礎費用機制的部分: EIP-4844 FAQ
• EIP-7706: EIP