長期 L1 執行層提案:用 RISC-V 取代 EVM

進階4/23/2025, 6:02:40 AM
本文提出了一個關於以太坊執行層未來的激進想法,其雄心與共識層的 beam chain 努力不相上下。

本文提出了一個關於以太坊執行層未來的激進構想,其雄心堪比共識層中的 beam chain 項目。該想法旨在大幅提升以太坊執行層的效率,解決主要的擴展瓶頸之一,同時也可以顯著簡化執行層的設計 —— 實際上,這可能是唯一能實現簡化的方法。

這個想法是:將EVM替換爲RISC-V,作爲智能合約所編寫的虛擬機語言。

重要說明:

  • 帳戶、跨合約調用、存儲等概念將完全保持不變。這些抽象機制本身運行良好,開發者也早已習慣。像 SLOAD、SSTORE、BALANCE、CALL 等操作碼將變成 RISC-V 的系統調用。
  • 在這種新模式下,智能合約可以用 Rust 編寫,但我預計大多數開發者仍會繼續使用 Solidity(或 Vyper),只是這兩種語言會適配 RISC-V 作爲後端。因爲用 Rust 寫智能合約 實際上醜陋的,而 Solidity 和 Vyper 。也就是說,開發者的體驗可能幾乎不會改變,甚至幾乎感覺不到差別。
  • 舊式的 EVM 合約將繼續可用,並且可以與新式的 RISC-V 合約進行雙向互操作。本文後面會詳細講解實現方式。

有一個先例是 Nervos 的 CKB 虛擬機,它本質上就是基於 RISC-V 的。

爲什麼要這樣做?

在短期內,以太坊 L1 的主要擴展瓶頸將通過即將推出的 EIP(如區塊級訪問列表延遲執行、分布式歷史存儲及 EIP-4444)得到解決。中期內,我們會通過無狀態性ZK-EVM 進一步優化。但從長期看,以太坊 L1 擴展性的主要限制因素將變爲:

  1. 數據可用性抽樣和歷史存儲協議的穩定性
  2. 保持區塊生產的市場競爭性
  3. ZK-EVM 的證明能力

我將論證,用 RISC-V 替代 ZK-EVM 可以解決(2)和(3)中的關鍵瓶頸。

以下是 Succinct ZK-EVM 在證明以太坊執行層各部分時所使用的周期數量表:

有四個部分消耗了大量時間:deserialize_inputs、initialize_witness_db、state_root_computation 和 block_execution。其中 initialize_witness_db 和 state_root_computation 都與狀態樹有關,而 deserialize_inputs 是將區塊和證明數據轉爲內部表示的過程;因此,超過 50% 的時間實際上與證明數據大小成正比。

我們可以通過將當前的 keccak 16 叉 Merkle Patricia 樹替換爲使用對證明更友好的哈希函數的二叉樹來大幅優化這些部分。如果我們使用 Poseidon,那麼在一臺筆記本電腦上每秒可證明 200 萬次哈希(相比之下 keccak 約爲每秒 15,000 次)。當然,也有很多其他哈希方案可供選擇。總體來說,這些部分有大幅優化的空間。此外,我們還可以通過取消 bloom 來直接移除 accrue_logs_bloom

剩下的就是 block_execution,它佔據了當前證明周期的大約一半。如果我們希望將總的證明效率提高 100 倍,就必須將 EVM 的證明效率至少提升 50 倍。

我們可以選擇創建更加高效的 EVM 實現,減少證明周期開銷。但我們也可以注意到,當前的 ZK-EVM 證明實際上就是在對編譯爲 RISC-V 的 EVM 實現進行證明——那麼我們不妨直接讓智能合約開發者使用 RISC-V 虛擬機。

一些數據表明,在某些有限場景下,這種方式可帶來超過 100 倍的效率提升:

實際上,我預計剩餘的證明時間將主要集中在當前的預編譯合約上。如果我們將 RISC-V 設爲主虛擬機,那麼 gas 費用將反映證明時間,因此經濟上會有壓力促使人們停止使用更昂貴的預編譯合約;即便如此,提升可能也沒那麼誇張,但我們有充分理由相信優化幅度仍然會非常可觀。

(順便說一句,在常規的 EVM 執行中,“EVM 執行”與“其他操作”的計算開銷也是大約對半分的,因此我們直覺上也能預期,通過移除 EVM 作爲“中間層”,帶來的效率提升將同樣巨大。)

實施細節

有多種方式可以實現這一提案。其中最不具破壞性的方式是同時支持兩種虛擬機,允許合約可以用任意一種編寫。兩種類型的合約都可以訪問相同類型的功能設施:持久化存儲 (SLOAD 和 SSTORE)、持有 ETH 餘額、進行調用或接收調用等。EVM 合約和 RISC-V 合約可以相互調用;從 RISC-V 的角度來看,調用 EVM 合約就像是使用某些特殊參數進行系統調用;而接收到該調用的 EVM 合約則將其解釋爲一次 CALL 操作。

從協議的角度看,更激進的方式是:將現有的 EVM 合約轉化爲調用一個用 RISC-V 編寫的 EVM 解釋器合約。也就是說,如果一個 EVM 合約包含代碼 C,而 EVM 解釋器的地址是 X,那麼該合約就被替換爲一個頂層邏輯:當從外部接收到調用參數 D 時,調用地址 X 並傳入參數 (C, D),然後等待返回值並將其轉發。如果解釋器本身在執行過程中嘗試進行 CALL 或 SLOAD/SSTORE 操作,那麼合約就去執行它。

還有一種折中方案是執行上述第二種方案,但在協議層面上顯式引入“虛擬機解釋器”的概念,並要求其邏輯用 RISC-V 編寫。EVM 將成爲第一個被實現的解釋器,但未來還可以支持其他虛擬機(例如 Move 就是一個可能的候選者)。

第二和第三種方案的一個關鍵優勢在於:它們能大幅簡化執行層的規範。實際上,這種激進的想法可能是實現簡化的唯一可行路徑,因爲即使是像移除 SELFDESTRUCT 這樣的漸進式簡化也非常困難。

Tinygrad 項目有一個嚴格的規則,即代碼不能超過 10000 行;而一個最優的區塊鏈底層協議應當也能在這一範圍內,甚至更小。Beam chain 項目在大幅簡化以太坊共識層方面展現出了巨大潛力。但如果想在執行層獲得類似的進展,也許只有像這樣徹底性的變革才能實現。

聲明:

  1. 本文轉載自 [Ethereum Magicians]。所有版權歸原作者所有 [Vitalik Buterin]。若對本次轉載有異議,請聯系 Gate Learn 團隊,他們會及時處理。
  2. 免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
  3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明,否則禁止復制、分發或抄襲翻譯文章。

長期 L1 執行層提案:用 RISC-V 取代 EVM

進階4/23/2025, 6:02:40 AM
本文提出了一個關於以太坊執行層未來的激進想法,其雄心與共識層的 beam chain 努力不相上下。

本文提出了一個關於以太坊執行層未來的激進構想,其雄心堪比共識層中的 beam chain 項目。該想法旨在大幅提升以太坊執行層的效率,解決主要的擴展瓶頸之一,同時也可以顯著簡化執行層的設計 —— 實際上,這可能是唯一能實現簡化的方法。

這個想法是:將EVM替換爲RISC-V,作爲智能合約所編寫的虛擬機語言。

重要說明:

  • 帳戶、跨合約調用、存儲等概念將完全保持不變。這些抽象機制本身運行良好,開發者也早已習慣。像 SLOAD、SSTORE、BALANCE、CALL 等操作碼將變成 RISC-V 的系統調用。
  • 在這種新模式下,智能合約可以用 Rust 編寫,但我預計大多數開發者仍會繼續使用 Solidity(或 Vyper),只是這兩種語言會適配 RISC-V 作爲後端。因爲用 Rust 寫智能合約 實際上醜陋的,而 Solidity 和 Vyper 。也就是說,開發者的體驗可能幾乎不會改變,甚至幾乎感覺不到差別。
  • 舊式的 EVM 合約將繼續可用,並且可以與新式的 RISC-V 合約進行雙向互操作。本文後面會詳細講解實現方式。

有一個先例是 Nervos 的 CKB 虛擬機,它本質上就是基於 RISC-V 的。

爲什麼要這樣做?

在短期內,以太坊 L1 的主要擴展瓶頸將通過即將推出的 EIP(如區塊級訪問列表延遲執行、分布式歷史存儲及 EIP-4444)得到解決。中期內,我們會通過無狀態性ZK-EVM 進一步優化。但從長期看,以太坊 L1 擴展性的主要限制因素將變爲:

  1. 數據可用性抽樣和歷史存儲協議的穩定性
  2. 保持區塊生產的市場競爭性
  3. ZK-EVM 的證明能力

我將論證,用 RISC-V 替代 ZK-EVM 可以解決(2)和(3)中的關鍵瓶頸。

以下是 Succinct ZK-EVM 在證明以太坊執行層各部分時所使用的周期數量表:

有四個部分消耗了大量時間:deserialize_inputs、initialize_witness_db、state_root_computation 和 block_execution。其中 initialize_witness_db 和 state_root_computation 都與狀態樹有關,而 deserialize_inputs 是將區塊和證明數據轉爲內部表示的過程;因此,超過 50% 的時間實際上與證明數據大小成正比。

我們可以通過將當前的 keccak 16 叉 Merkle Patricia 樹替換爲使用對證明更友好的哈希函數的二叉樹來大幅優化這些部分。如果我們使用 Poseidon,那麼在一臺筆記本電腦上每秒可證明 200 萬次哈希(相比之下 keccak 約爲每秒 15,000 次)。當然,也有很多其他哈希方案可供選擇。總體來說,這些部分有大幅優化的空間。此外,我們還可以通過取消 bloom 來直接移除 accrue_logs_bloom

剩下的就是 block_execution,它佔據了當前證明周期的大約一半。如果我們希望將總的證明效率提高 100 倍,就必須將 EVM 的證明效率至少提升 50 倍。

我們可以選擇創建更加高效的 EVM 實現,減少證明周期開銷。但我們也可以注意到,當前的 ZK-EVM 證明實際上就是在對編譯爲 RISC-V 的 EVM 實現進行證明——那麼我們不妨直接讓智能合約開發者使用 RISC-V 虛擬機。

一些數據表明,在某些有限場景下,這種方式可帶來超過 100 倍的效率提升:

實際上,我預計剩餘的證明時間將主要集中在當前的預編譯合約上。如果我們將 RISC-V 設爲主虛擬機,那麼 gas 費用將反映證明時間,因此經濟上會有壓力促使人們停止使用更昂貴的預編譯合約;即便如此,提升可能也沒那麼誇張,但我們有充分理由相信優化幅度仍然會非常可觀。

(順便說一句,在常規的 EVM 執行中,“EVM 執行”與“其他操作”的計算開銷也是大約對半分的,因此我們直覺上也能預期,通過移除 EVM 作爲“中間層”,帶來的效率提升將同樣巨大。)

實施細節

有多種方式可以實現這一提案。其中最不具破壞性的方式是同時支持兩種虛擬機,允許合約可以用任意一種編寫。兩種類型的合約都可以訪問相同類型的功能設施:持久化存儲 (SLOAD 和 SSTORE)、持有 ETH 餘額、進行調用或接收調用等。EVM 合約和 RISC-V 合約可以相互調用;從 RISC-V 的角度來看,調用 EVM 合約就像是使用某些特殊參數進行系統調用;而接收到該調用的 EVM 合約則將其解釋爲一次 CALL 操作。

從協議的角度看,更激進的方式是:將現有的 EVM 合約轉化爲調用一個用 RISC-V 編寫的 EVM 解釋器合約。也就是說,如果一個 EVM 合約包含代碼 C,而 EVM 解釋器的地址是 X,那麼該合約就被替換爲一個頂層邏輯:當從外部接收到調用參數 D 時,調用地址 X 並傳入參數 (C, D),然後等待返回值並將其轉發。如果解釋器本身在執行過程中嘗試進行 CALL 或 SLOAD/SSTORE 操作,那麼合約就去執行它。

還有一種折中方案是執行上述第二種方案,但在協議層面上顯式引入“虛擬機解釋器”的概念,並要求其邏輯用 RISC-V 編寫。EVM 將成爲第一個被實現的解釋器,但未來還可以支持其他虛擬機(例如 Move 就是一個可能的候選者)。

第二和第三種方案的一個關鍵優勢在於:它們能大幅簡化執行層的規範。實際上,這種激進的想法可能是實現簡化的唯一可行路徑,因爲即使是像移除 SELFDESTRUCT 這樣的漸進式簡化也非常困難。

Tinygrad 項目有一個嚴格的規則,即代碼不能超過 10000 行;而一個最優的區塊鏈底層協議應當也能在這一範圍內,甚至更小。Beam chain 項目在大幅簡化以太坊共識層方面展現出了巨大潛力。但如果想在執行層獲得類似的進展,也許只有像這樣徹底性的變革才能實現。

聲明:

  1. 本文轉載自 [Ethereum Magicians]。所有版權歸原作者所有 [Vitalik Buterin]。若對本次轉載有異議,請聯系 Gate Learn 團隊,他們會及時處理。
  2. 免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
  3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明,否則禁止復制、分發或抄襲翻譯文章。
即刻開始交易
註冊並交易即可獲得
$100
和價值
$5500
理財體驗金獎勵!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.