以太坊未來路線圖:EVM升級、帳戶抽象和1559改進

FlashLoanLarry

2025-07-20 06:10:03

以太坊協議可能的未來(六):繁榮

以太坊協議設計中有許多重要的"細節"對其成功至關重要。實際上,約一半的內容涉及不同類型的EVM改進,其餘部分則由各種小衆主題構成,這就是"繁榮"的意義所在。

繁榮:關鍵目標

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

EVM改進

解決了什麼問題?

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

它是什麼,如何運作?

當前EVM改進路線圖的第一步是EVM對象格式(EOF),計劃在下一個硬分叉中納入。EOF是一系列EIP,指定了一個新的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代碼中,這些操作碼的作用類似於:

for i in range(count): mem[z_start + z_skip * count] = op( mem[x_start + x_skip * count], mem[y_start + y_skip * count] )

實際實現中,這將以並行方式處理。

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

剩下的工作及權衡

目前,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。整個復雜性來自於以一種對維護去中心化網路友好的方式實現這一點,並防範拒絕服務攻擊。

一個典型的關鍵挑戰是多重失效問題:如果有1000個帳戶的驗證函數都依賴於某個單一值S,並且當前值S使得內存池中的交易都是有效的,那麼有一個單一交易翻轉S的值可能會使內存池中的所有其他交易失效。這使得攻擊者能夠以極低的成本向內存池發送垃圾交易,從而堵塞網路節點的資源。

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

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

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

兩個關鍵原因如下:

EntryPoint作爲合約的固有低效性:每個捆綁約有100,000 gas的固定開銷,以及每個用戶操作額外的數千gas。
確保以太坊屬性的必要性:如包含列表所創建的包含保證需要轉移到帳戶抽象用戶。

此外,ERC-4337還擴展了兩個功能:

支付代理(Paymasters):允許一個帳戶代表另一個帳戶支付費用的功能,這違反了驗證階段只能訪問發送者帳戶本身的規則,因此引入了特殊處理以確保支付代理機制的安全性。
聚合器(Aggregators):支持籤名聚合的功能,如BLS聚合或基於SNARK的聚合。這對於在Rollup上實現最高的數據效率是必要的。

剩下的工作及權衡

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

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

將EIP-4337作爲協議的一部分
一種新的EOA類型,其中籤名算法爲EVM代碼執行

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

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

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