以下為原文內容（為便於閱讀理解，原內容有所整編）：

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

繁榮：關鍵目標

將EVM 變成高性能和穩定的「最終狀態」

將帳戶抽象化引入協議，讓所有用戶享受更安全和便捷的帳戶

優化交易費用經濟，提高可擴展性同時降低風險

探索先進的密碼學，使以太坊在長期內顯著改善

本章內容

EVM 改進

帳號抽象

EIP-1559 改進

VDF（可驗證延遲函數）

混淆與一次性簽名：密碼學的遠期未來

EVM 改進

解決了什麼問題？
目前的 EVM 難以進行靜態分析，這使得建立高效實作、正式驗證程式碼和進行進一步擴展變得困難。此外，EVM 的效率較低，難以實現許多形式的高階密碼學，除非透過預編譯明確支援。

它是什麼，如何運作？
目前 EVM 改進路線圖的第一步是 EVM 物件格式（EOF），計劃在下一個硬分叉中納入。 EOF 是一系列EIP，指定了一個新的EVM 程式碼版本，具有許多獨特的特徵，最顯著的是：

·程式碼（可執行，但無法從EVM 讀取）與資料（可讀取，但無法執行）之間的分離

·禁止動態跳轉，僅允許靜態跳轉

·EVM 程式碼無法再觀察與燃料相關的資訊

·新增了一個新的顯式子程式機制

繁榮：EVM 改進（續）

舊式合約將繼續存在並可創建，儘管最終可能會逐步棄用舊式合約（甚至可能強制轉換為EOF代碼）。新式合約將受益於 EOF 帶來的效率提升——首先是透過子程式特性稍微縮小的字節碼，隨後則是 EOF 特定的新功能或減少的 gas 成本。

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

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

一個組合EIP 的大致設計將以EIP-6690 為起點，然後：

·允許(i) 任何奇數或(ii) 任何最高為2768 的2 的冪作為模數

·對於每個EVM-MAX 操作碼（加法、減法、乘法），增加一個版本，不再使用3 個立即數x、y、z，而是使用7 個立即數：x_start、x_skip、y_start、y_skip、z_start、 z_skip、count。 在Python 程式碼中，這些操作碼的作用類似：

實際實作中，這將以並行方式處理。

·可能會增加 XOR、AND、OR、NOT 和 SHIFT（包括循環和非循環），至少對於 2 的冪模數。同時添加ISZERO（將輸出推送到EVM 主堆疊），這將足夠強大以實現橢圓曲線密碼學、小域密碼學（如Poseidon、Circle STARKs）、傳統雜湊函數（如SHA256、KECCAK、BLAKE）和基於格的密碼學。其他 EVM 升級也可能實現，但迄今為止關注度較低。

現有研究連結

EOF: https://evmobjectformat.org/

EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690

SIMD: https://eips.ethereum.org/EIPS/eip -616

剩下的工作及權衡

目前，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。 以下是這些目標的總表：

MPC（多方計算）是一種已有 40 年歷史的技術，用於將金鑰分成多個部分並儲存在多個裝置上，利用密碼學技術產生簽名，而無需直接組合這些金鑰部分。

EIP-7702 是計劃在下一個硬分叉中引入的一項提案，EIP-7702 是對提供帳戶抽象便利性以惠及所有用戶（包括EOA 用戶）的日益認識的結果，旨在在短期內改善所有用戶的體驗，並避免分裂成兩個生態系。

工作始於 EIP-3074 ，並最終形成EIP-7702。 EIP-7702 將帳戶抽象的「便利功能」提供給所有用戶，包括今天的 EOA（外部擁有帳戶，即受 ECDSA 簽名控制的帳戶）。

從圖表中可以看到，雖然一些挑戰（尤其是“便利性”挑戰）可以透過漸進技術如多方計算或EIP-7702 解決，但最初提出帳戶抽象提案的主要安全目標只能透過回溯並解決原始問題來實現：允許智慧合約代碼控制交易驗證。迄今尚未實現的原因在於安全地實施，這一點是一項挑戰。

它是什麼，如何運作？

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

一個典型的關鍵挑戰是多重破壞問題：

如果有1000 個帳戶的驗證函數都依賴某個單一值S，且目前值S使得記憶體池中的交易都是有效的，那麼有單一交易翻轉S 的值可能會使記憶體池中的所有其他交易失效。這使得攻擊者能夠以極低的成本向記憶體池發送垃圾交易，從而堵塞網路節點的資源。

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

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

ERC-4337 被設計為一種額外協議標準（ERC），因為在當時以太坊客戶端開發者專注於合併（Merge），沒有額外的精力來處理其他功能。這就是為什麼 ERC-4337 使用了名為用戶操作的對象，而不是常規交易。然而，最近我們意識到需要將其中至少部分內容寫入協議中。

兩個關鍵原因如下：

1.EntryPoint 作為合約的固有低效性：每個捆綁約有 100,000 gas 的固定開銷，以及每個使用者操作額外的數千 gas。

2. 確保以太坊屬性的必要性：如包含清單所建立的包含保證需要轉移到帳戶抽象使用者。

此外，ERC-4337 也擴充了兩個功能：

·支付代理（Paymasters）：允許一個帳戶代表另一個帳戶支付費用的功能，這違反了驗證階段只能存取發送者帳戶本身的規則，因此引入了特殊處理以確保支付代理機制的安全性。

·聚合器（Aggregators）：支援簽章聚合的功能，如 BLS 聚合或基於 SNARK 的聚合。這對於在 Rollup 上實現最高的資料效率是必要的。

現有研究連結

關於帳戶抽象歷史的演講：https://www.youtube.com/watch?v=iLf8qpOmxQc

ERC-4337 ：https://eips.ethereum.org/EIPS/eip-4337

EIP-7702：https://eips.ethereum.org/EIPS/eip-7702

BLSWallet 程式碼（使用聚合功能）：https://github.com/getwax /bls-wallet

EIP-7562（寫入協議的帳戶抽象）：https://eips.ethereum.org/EIPS/eip-7562

EIP-7701（基於EOF 的寫入協議帳戶抽象）：https://eips.ethereum .org/EIPS/eip-7701

剩下的工作及權衡

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

這種方法的迷人之處在於，它清晰地表明了本地帳戶抽象的兩種等效視角：

1. 將EIP-4337 作為協議的一部分

2. 一種新的EOA 類型，其中簽名演算法為EVM 程式碼執行

如果我們從對驗證期間可執行程式碼複雜度設定嚴格界線開始——不允許存取外部狀態，甚至在初期設定的gas 限制也低到對量子抗性或隱私保護應用無效——那麼這種方法的安全性就非常明確：只是將ECDSA 驗證替換為需要相似時間的EVM 程式碼執行。

然而，隨著時間的推移，我們需要放寬這些界限，因為允許隱私保護應用在沒有中繼的情況下工作，以及量子抗性都是非常重要的。為此，我們需要找到更靈活地解決拒絕服務（DoS）風險的方法，而不要求驗證步驟必須極度簡約。

主要的權衡似乎是「快速寫入一個讓較少人滿意的方案」與「等待更長時間，可能獲得更理想的解決方案」，理想的方法可能是某種混合方法。一種混合方法是更快地寫入一些用例，並留出更多時間來探索其他用例。另一種方法是在 L2 上首先部署更雄心勃勃的帳戶抽象版本。然而，這面臨的挑戰是，L2 團隊需要對採用提案的工作充滿信心，才能願意實施，尤其是確保 L1 和/或其他 L2 未來能夠採用相容的方案。

我們還需要明確考慮的另一個應用是密鑰儲存帳戶，這些帳戶在L1 或專用L2 上儲存帳戶相關狀態，但可以在L1 和任何相容的L2 上使用。有效地做到這一點可能要求L2 支持諸如L1SLOAD 或REMOTESTATICCALL 的操作碼，但這也需要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-4844 機制所引入的關鍵不變數（即：在長期內，平均使用量剛好接近目標值）。

現有研究連結

EIP-1559 FAQ: EIP-1559 FAQ

關於EIP-1559 的實證分析: Empirical analysis

允許快速調整的改進提案: Proposed improvements

原文連結