原標題：《Long-term L1 execution layer proposal: replace the EVM with RISC-V》
作者： Vitalik Buterin
編譯：KarenZ，bitget交易所
4 月 20 日，Vitalik Buterin 在 Ethereum Magicians 平臺提出一項關于以太坊長期 L1 執行層的重要提案。他建議采用 RISC-V 架構取代現有的 EVM（以太坊虛擬機）作為編寫智能合約的虛擬機語言，旨在從根本上提升以太坊執行層的運行效率，突破當前主要的擴展瓶頸之一，同時大幅簡化執行層的簡潔性。
bitget交易所 對該提案進行了全文編譯，旨在幫助讀者了解這一技術設想。以下為提案原文的編譯內容：
本文提出了一個關于以太坊執行層未來的激進想法，其雄心程度不亞于共識層的 Beam Chain 計劃。該提案旨在大幅提高以太坊執行層的效率，解決主要的擴展瓶頸之一，并顯著簡化執行層——事實上，這可能是實現這一目標的唯一途徑。
核心構想：用 RISC-V 取代 EVM，作為智能合約編寫的虛擬機語言。
重要說明：
- 賬戶體系、跨合約調用、存儲等概念將完全保留。這些抽象設計運作良好且開發者已習慣使用。SLOAD、SSTORE、BALANCE、CALL 等操作碼將轉變為 RISC-V 系統調用。
- 在此模式下，智能合約可用 Rust 編寫，但我預計多數開發者仍會繼續使用 Solidity（或 Vyper）編寫合約，這些語言將適配 RISC-V 作為新后端。因為用 Rust 編寫的智能合約實際上可讀性較差，而 Solidity 和 Vyper 更清晰易讀。開發體驗可能幾乎不受影響，開發者甚至可能察覺不到變化。
- 舊版 EVM 合約將繼續運行，并與新版 RISC-V 合約完全雙向兼容。實現方式有幾種，本文后續將詳細探討。
Nervos CKB VM 已開創先例，其本質上就是 RISC-V 實現 。
為何這樣做？
短期來看，即將實施的 EIP（如 區塊級訪問列表 、 延遲執行 、分布式歷史存儲及 EIP-4444 ）能解決以太坊 L1 的主要擴展瓶頸。中期將通過無狀態性和 ZK-EVM 解決更多問題。長期來看，以太坊 L1 擴展的主要限制因素將變為：
- 數據可用性采樣和歷史存儲協議的穩定性
- 保持區塊生產市場競爭性的需求
- ZK-EVM 的證明能力
我將論證，替換 ZK-EVM 為 RISC-V 可以解決（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-ary Merkle patricia tree 替換為使用使用易于證明的哈希函數的 binary tree，這些部分可以得到大幅優化。如果使用 Poseidon，我們可以在筆記本電腦上 每秒證明 200 萬次哈希 值（相比之下，keccak 約為 15,000 hash/sec）。除了 Poseidon，還有許多其他選擇。總的來說，這些組件有很大優化的空間。此外，我們可以通過 移除 bloom 來消除 accrue_logs_bloom。
剩下的 block_execution 約占當前證明周期（prover cycles）的一半。若要實現 100 倍的整體證明效率提升，EVM 證明效率至少需要提升 50 倍。解決方案之一是為 EVM 創建更高效的證明實現，另一方案是注意到當前 ZK-EVM 證明器實際是通過將 EVM 編譯為 RISC-V 進行證明，直接讓智能合約開發者訪問該 RISC-V 虛擬機。
部分數據顯示在特定情況下效率提升可能超 100 倍：
實際應用中，剩余的 prover 時間可能主要由當前的預編譯（precompiles）操作占據。若將 RISC-V 作為主虛擬機，Gas schedule 將反映實際證明時間，經濟壓力將促使開發者減少使用高成本預編譯。即便如此，增益也不會如此顯著，但我們有充分的理由相信，這些增益將非?？捎^。
（值得注意的是， 常規 EVM 執行 中 「EVM 操作」 與 「其他操作」 的耗時占比也接近 50/50，因此我們直觀認為，移除 EVM 作為「中間層」將帶來同等顯著的增益）
實施細節
該提案有多種實現方式。破壞性最小的方案是同時支持兩種虛擬機，允許合約任選其一編寫。兩類合約都能訪問相同功能：持久化存儲（SLOAD/SSTORE）、持有 ETH 余額的能力、發起 / 接收調用等。EVM 與 RISC-V 合約可互相調用——從 RISC-V 視角看，調用 EVM 合約相當于執行帶特殊參數的系統調用；而接收消息的 EVM 合約會將其解釋為 CALL。
從協議角度看更激進的方法是將現有 EVM 合約轉換為調用用 RISC-V 編寫的 EVM 解釋器合約，運行其現有 EVM 代碼。即，如果一個 EVM 合約有代碼 C，EVM 解釋器位于地址 X，那么該合約將被替換為頂層邏輯，當從外部以調用參數 D 調用時，調用 X 并傳入 (C, D)，然后等待返回值并轉發。如果 EVM 解釋器本身調用該合約，要求運行 CALL 或 SLOAD/SSTORE，那么合約就執行這些操作。
折中方案是采用第二種方案，但通過協議明確支持「虛擬機解釋器」概念，要求其邏輯用 RISC-V 編寫。EVM 將是首個實例，未來還可支持其他語言（Move 可能是候選方案）。
第二和第三種方案的核心優勢在于，它們可極大簡化執行層規范?？紤]到即使是移除 SELFDESTRUCT 這樣的漸進式簡化都困難重重，這種思路可能是唯一可行的簡化路徑。Tinygrad 遵循「 代碼不超過 1 萬行 」的硬性規定，而最優區塊鏈底層理應能輕松滿足這一限制，并進一步精簡。Beam Chain 計劃有望大幅簡化以太坊共識層，而執行層若想實現類似提升，這種激進變革可能是唯一可行之路。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
