以太坊未來展望:EVM升級與帳戶抽象引領協議繁榮

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

撰文:Vitalik Buterin

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

繁榮:關鍵目標

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

Vitalik 關於以太坊可能的未來(六):The Splurge

EVM 改進

解決了什麼問題?

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

它是什麼,如何運作?

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

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

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

Vitalik 關於以太坊可能的未來(六):The Splurge

在引入 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:
  • 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 代碼替代更多的預編譯變得更加容易,可能不會大幅影響效率。

Vitalik 關於以太坊可能的未來(六):The Splurge

帳戶抽象

解決了什麼問題?

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

  • 切換到抗量子密碼學
  • 輪換舊密鑰(廣泛被認爲是推薦的安全實踐)
  • 多重籤名錢包和社交恢復錢包
  • 使用一個密鑰進行低價值操作,使用另一個密鑰(或一組密鑰)進行高價值操作

允許隱私協議在沒有中繼的情況下工作,顯著降低其復雜性,並消除一個關鍵的中央依賴點

自 2015 年帳戶抽象提出以來,其目標也擴展到了包括大量"便利目標",例如,某個沒有 ETH 但擁有一些 ERC20 的帳戶能夠用 ERC20 支付 gas。以下是這些目標的匯總圖表:

Vitalik 關於以太坊可能的未來(六):The Splurge

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 上實現最高的數據效率是必要的。

Vitalik 關於以太坊可能的未來(六):The Splurge

現有研究連結

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

查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 9
  • 分享
留言
0/400
SelfRuggervip
· 11小時前
V神你说的都对啊啊啊
回復0
绿蜡烛收集家vip
· 07-15 02:02
V神出手了说明有好事啊
回復0
GateUser-9ad11037vip
· 07-14 15:00
V神又出新作了~细节决定成败了属于是
回復0
夜不撸毛vip
· 07-14 04:50
EVM还得继续卷啊
回復0
StealthDeployervip
· 07-14 04:47
V在干啥呢又折腾代码
回復0
巨鲸资深观察员vip
· 07-14 04:45
瓦胡塔升级过后这些技术瓶颈不攻破难哦
回復0
夜间创世纪vip
· 07-14 04:44
代码频率异常 又有深夜部署计划了
回復0
TokenSherpavip
· 07-14 04:25
其实,*叹气* 这个提案缺乏适当的历史背景……让我来分析一下为什么evm 1.0从第一天起就是有缺陷的
查看原文回復0
资深链上考古学家vip
· 07-14 04:24
上车只看v神的脸
回復0
查看更多
交易,隨時隨地
qrCode
掃碼下載 Gate APP
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)