Vitalik新提議：用RISC-V取代現EVM

這篇文章爲以太坊執行層的未來提出了一個激進的想法，這個想法與 Beam 鏈對共識層的努力一樣雄心勃勃。它旨在大幅提高以太坊執行層的效率，解決主要的擴展瓶頸之一，並且還可以大幅提高執行層的簡單性——事實上，這也許是唯一的方法。

想法：用RISC-V取代EVM作爲編寫智能合約的虛擬機語言（譯者注：RISC-V是指基於精簡指令集計算RISC原理建立的開放指令集架構，V表示爲第五代RISC）。

重要澄清：

• 帳戶、跨合約調用、存儲等概念將保持完全相同。這些抽象工作得很好，開發人員也習慣了它們。 SLOAD、SSTORE、BALANCE、CALL 等操作碼將成爲 RISC-V 系統調用。
• 在這樣的世界裏，智能合約可以用 Rust 編寫，但我預計大多數開發人員會繼續用 Solidity（或 Vyper）編寫智能合約，這將適應添加 RISC-V 作爲後端。這是因爲用 Rust 編寫的智能合約實際上相當醜陋，而 Solidity 和 Vyper 的可讀性要高得多。或許 devex 的變化很小，開發人員可能幾乎不會注意到這種變化。
• 舊式 EVM 合約將繼續有效，並將與新式 RISC-V 合約完全雙向互操作。有幾種方法可以做到這一點，我將在本文後面進行介紹。

一個先例是 Nervos CKB VM，它基本上是 RISC-V。

爲什麼這麼做？

短期內，以太坊 L1 可擴展性的主要瓶頸將通過即將推出的 EIP 得到解決，例如塊級訪問列表、延遲執行和分布式歷史存儲以及 EIP-4444。從中期來看，我們將解決無狀態和 ZK-EVM 的進一步問題。從長遠來看，以太坊 Layer1 擴展的主要限制因素是：

• 數據可用性採樣和歷史存儲協議的穩定性
• 希望保持區塊生產市場的競爭性
• ZK-EVM 驗證能力

我認爲用 RISC-V 替換 ZK-EVM 可以解決 (2) 和 (3) 中的一個關鍵瓶頸。

這是 Succinct ZK-EVM 用於證明 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 VM。

一些數據表明，在有限的情況下，這可以使效率提高 100 倍以上：

實際上，我預計剩餘的證明時間將主要由今天的預編譯所主導。如果我們將 RISC-V 作爲主要虛擬機，那麼 gas 計劃將反映證明時間，因此將存在經濟壓力來停止使用更昂貴的預編譯；但即便如此，收益也不會如此令人印象深刻，但我們有充分的理由相信，收益將非常顯著。

（順便說一句，“EVM”和“其他東西”之間大約 50/50 的分割也出現在常規 EVM 執行中，我們直觀地預計，從 EVM 作爲“中間人”中移除的收益應該同樣大）

實現細節

有多種方法可以實現此類建議。破壞性最小的方法是支持兩個虛擬機，並允許在任意一個虛擬機中編寫合同。兩種類型的合約都可以使用相同類型的設施：持久存儲（SLOAD 和 SSTORE）、持有 ETH 餘額的能力、撥打和接聽電話的能力等。EVM 和 RISC-V 合約可以自由地相互調用；從 RISC-V 的角度來看，調用 EVM 合約似乎是在進行帶有一些特殊參數的系統調用；接收該消息的 EVM 合約會將其解釋爲 CALL。

從協議角度來看，一種更激進的方法是將現有的 EVM 合約轉換爲調用用 RISC-V 編寫的 EVM 解釋器合約的合約，該合約運行其現有的 EVM 代碼。也就是說，如果 EVM 合約具有代碼 C，並且 EVM 解釋器位於地址 X，則該合約將被替換爲頂層邏輯，當從外部使用調用參數 D 調用時，使用 (C, D) 調用 X，然後等待返回值並轉發它。如果 EVM 解釋器本身調用合約，要求運行 CALL 或 SLOAD/SSTORE，那麼合約就會這樣做。

中間路線是採用第二種選擇，但爲其創建一個明確的協議功能 —— 基本上，將“虛擬機解釋器”的概念奉爲圭臬，並要求其邏輯用 RISC-V 編寫。 EVM 將是第一個，但也可能還有其他（例如，Move 可能是一個候選者）。

第二和第三個提案的一個主要好處是它們極大地簡化了執行層規範 —— 事實上，這種想法可能是唯一可行的方法，因爲即使是像刪除 SELFDESTRUCT 這樣的漸進式簡化也非常困難。 Tinygrad 有一條嚴格的規定，即代碼量永遠不超過 10,000 行；最佳的區塊鏈基礎層應該能夠很好地適應這些邊界，甚至更小。光束鏈的努力對於大大簡化以太坊的共識層具有很大的希望。但對於執行層來說，要想獲得類似的收益，這種徹底的改變可能是唯一可行的途徑。