Vitalik vs 頂級開發者：Web3 虛擬機之爭的〈虛擬圓桌會議〉

每個區塊鏈都有自己獨特的亮點和敘事，從技術上講，區塊鏈的代碼模塊是差不多的，都具有節點通信、共識和執行，但又各自選取了最適合自己的技術和算法，特別是共識算法和執行層的虛擬機技術。 這段時間因為以太坊想從 EVM 節點碼切換成 RISC-V 指令集讓虛擬機這個比較隱秘的技術領域暴露在大眾面前。

前兩天，我彙編了一篇關於 RISC-V 的科普文章，讓大家了解它的過去和未來。

evm 變 RISC-V？ 聊聊 RISC-V 的前世今生和 Web3 領域的應用

今天，我希望從更全面的、綜合性地跟大家分享一些虛擬機的內容，本人不才，對虛擬機的研究學習不深，取個巧，我從網上將各項目的虛擬機大佬的設計構思或點評做一番混編，讓大家可以了解各個虛擬機的異同。

在整理素材時，我感覺這些觀點的碰撞特別像中國春秋戰略時期的百家爭鳴，所以靈機一動，我將他們的表達按現在流行的圓桌會議 / Space 形式整合在一起，呈現一場 “虛擬的圓桌會議” 給大家，突出 “爭鳴” 這一動效性，君子和而不同嘛。

為便於快速掌握核心論點，這里通過結構化表格橫向對比主流 Web3 虛擬機的關鍵特性，提煉自全文 10+ 技術領袖的深度討論。

涵蓋 RISC-V、WASM、EVM 等 9 類方案的架構設計、性能表現與落地挑戰等：( 左右滑動查看完整表格 )

2024 年以太坊社區關於 RISC-V 替代 EVM 的提案引發激烈討論，我們虛擬邀請各流派 VM 設計者，從技術本質、生態適配性、ZK 友好性等維度展開交鋒……

首先歡迎 @VitalikButerin[1]，Ethereum 聯合創始人，EVM 作為開創性的虛擬機，現在大家都知道了你想有更好的創新，可以和我們講講嗎？

網友朋友們，你們好！ 我是 Vitalik，中國網友喜歡叫我 “小 v”（笑～）。 大家都知道了我近期發表的 EVM -> RISC-V 的建議提案，大家可以去論壇查看原文[2]（中文版[3]），這裡我就不再贅述，只說一些關鍵的部分：

• 用 RISC-V 取代 EVM，作為智能合約編寫的虛擬機語言這一想法雖然有些激進——事實上，這可能是實現這一目標的唯一途徑。

• 以太坊 L1 擴展存在幾個限制因素中，執行效率是主要的擴展瓶頸之一，我們需要提高效率並顯著簡化執行層。

• 舊版 EVM 合約將繼續運行，並與新版 RISC-V 合約完全雙向兼容。 有多種實現方式：

• 破壞性最小的方案是同時支持兩種虛擬機。

• 更激進的方法是將現有 EVM 合約轉換為調用用 RISC-V 編寫的 EVM 解釋器合約，運行其現有 EVM 代碼。

• 通過協議明確支持「虛擬機解釋器」概念，要求其邏輯用 RISC-V 編寫。 EVM 將是首個實例。

• 未來還可支持其他語言（MOVE 可能是候選方案）。

• 開發體驗可能幾乎不受影響，開發者甚至可能察覺不到變化。

• Nervos ckb VM 已開創先例，其本質上就是 RISC-V 實現[4]。

謝謝 @VitalikButerin 向我們分享以太坊的最新計劃，我有看到在原貼中有很多人表示支持，也有一部分錶示方案有待進一步研究，鑑於本次主題為虛擬機的橫向優劣勢討論，我們就不再細說原貼中的一些有關 RISC-V 可行性的細節。 當然，我們也邀請了其中一些符合本主題的嘉賓參與下面的話題。

有請我們今天的第二位嘉賓：[6] 創始人 & CEO，原 ConsenSys 成員，參與以太坊基礎設施和工具的開發，深度參與了以太坊客戶端（如 GETH 或 Parity）的優化工作，是一個對 VM 設計和實現很有經驗和發言權的一個人。

首先，Vitalik 的帖子令人振奮。 我從以太坊主網上線前就開始接觸 EVM，可以明確地說——我們當時就知道它存在缺陷，如今這些問題依然存在。 但不可否認，它已成為構建真正去中心化應用的基石，對此我們心懷感激。 [src[7]]

請問為什麼你們選擇開發 FuelVM 而不是採用其它已有方案呢？

在設計 FuelVM 時，我們研究了多種架構： 指令集架構 (ISA)：MIPS、RISC-V、x86、ARM，虛擬機方案：WASM ，以及區塊鏈專用 VM：EVM、BitcoinScript、MoveVM、SVM 等等。 它們各自都有亮點，但都無法完全滿足我們的需求，等下我會談談我對這些選型的一些分析結論和思考。 在那之前，我希望屏幕前的你也一併思考這三個核心問題：[src[8]]

好的，感謝以上嘉賓的自我介紹，接下來我們依據 @IAmNickDodson 的研究順序挑選出一些具有代表性的 VM 項目 / 技術，請各位說說你們的看法和分析，如果有不同觀點也請隨時參與進來。

這些 CPU 指令集最初為早期微芯片和嵌入式設備設計

（有時需額外處理）和。

（見後文 CISC 部分） 、（參考 StARkware/Valida 的研究）。

即便 ZK 技術能降低節點計量需求，高吞吐場景下仍需預計算 / 共享證明，此時仍需抗 DoS 機制（計量仍有價值）。 [src[9]]

Georgios KonstantOPoulos[10]（Paradigm[11] 合夥人兼 CTO）如果您喜歡 @VitalikButerin 的提案，那麼您一定會喜歡我們在過去幾個月裡慢慢開發的這個 R55[12]... [src[13]]

0xpedro.eth/acc[14]：R55 允許您使用純 Rust 編寫智能合約，並通過 RISC-V 在以太坊客戶端中執行。 通常，Solidity 會編譯為 EVM 字節碼，但 R55 會將 Rust 編譯為 RISC-V 指令，這是一個可以釋放硬件優化潛力的開源框架。 在以太坊上使用 Rust？ 有趣但棘手。 RISC-V 本身並不了解以太坊的狀態（存儲、調用等），因此 R55 添加了系統調用。 使用 RISC-V 的 ecall，Rust 合約可以讀取存儲（例如 SLOAD）、調用合約或發送日誌——從而無縫地將 Rust 與以太坊連接起來。

R55 仍在開發中，需要對 gas 和安全性進行調整，但未來令人興奮：rollup 或應用鏈可以運行原生 Rust 合約，或者 zkEVM 可以利用 RISC-V 進行加密操作。 在我看來，Rust 的安全性和速度使其成為以太坊的利器。 R55 能否為以太坊帶來一波 Rust 開發者浪潮？ 或許現在還為時過早，但值得一看。 [src[15]]

Dave Rauchwerk[16]：@VitalikButerin 這是一個很棒的想法。 RISC-V 的一個關鍵優勢是其明確的可擴展性。 我們應該研究定義一組定制的 RISC-V 指令，專門用於加速核心的、性能至關重要的 EVM 操作碼。 RISC-V 的開放特性允許在通用 CPU 執行之外使用專用硬件實現（ASIC、FPGA）。 這為通過直接在矽片中加速核心 EVM 邏輯，顯著提升 L1 TPS 提供了途徑，其速度可能比當前的軟件解釋或 JIT 方法快幾個數量級。

可驗證性和安全性：與復雜的傳統 ISA 相比，RISC-V 的模塊化和簡潔設計使其更易於形式化驗證。 經過形式化驗證的 RISC-V 核心執行 EVM 邏輯，可以提供更強大的運行時行為保障，這對於保障高價值智能合約的安全至關重要。 RISC-V 可能通過以 EVM 為中心的自定義指令得到增強，為實現更高性能、更安全、更可擴展的 LAYER 1 提供了一條引人注目的途徑。

另外，將現有的 EVM 實現與潛在的 RISC-V 軟件模型進行基準測試。 revive/POLkaVM 看起來很棒 - 它目前僅針對 RV32EM，值得討論。 [src[17]]

Koute[18]（Parity Technologies[19] PolkaVM 的負責人）：正好提到了 PolkaVM，那我就詳細解釋一下 PolkaVM 是什麼以及它的工作原理。

PolkaVM 目前支持帶有 Zbb 擴展的 riscv64emac，但與大多數（所有？）其他 RISC-V VM 不同，它不能按原樣運行 RISC-V 二進製文件（它實際上不是 RISC-V VM！）。 離線時，我們會提取您使用普通編譯器構建的普通 RISC-V ELF 二進製文件，然後將其轉換為更受約束、更高效的自定義字節碼，該字節碼專為 VM（而不是像 RISC-V 那樣的原生硬件）使用而設計。 我們的想法是盡可能地消除 VM 本身的複雜性（需要在鏈上運行），將盡可能多的複雜性放入離線工具（可以在鏈下運行），並通過刪除不必要的功能來提高安全性（例如，在原始 RISC-V 中，您可以跳轉到任何地址；在 PolkaVM 字節碼中，代碼地址空間是完全虛擬化的，您無法跳轉到任何地方，並且字節碼甚至不會加載到程序可訪問的內存中）。

性能方面，我們非常接近裸機性能[1]；它與最先進的 WASM VM 一樣快 *，wasmtime 但保證了 O(n) 的重新編譯時間，並將程序重新編譯為本機代碼的速度提高了數百倍。 具體來說，從原始 PolkaVM 字節碼開始將程序重新編譯為本機代碼，比緩存重新編譯的工件並根據其哈希值查找要快得多（換句話說，重新編譯程序比計算其哈希值更快），而且這還不會 * 犧牲運行時執行性能。

我們主要使用 RISC-V 並不是因為它對於 VM 來說是一種特別好的字節碼（），而是因為它並且相對為其他東西，所以我們可以兼得兩全其美——（您可以使用現有的編譯器和編程語言，例如前幾天我將 Quake 移植到 PolkaVM），但您也可以獲得自定義、優化的字節碼的好處（）。 [src[20]]

[21]：@VitalikButerin 聲稱，用 RISC-V 替換以太坊虛擬機 (EVM) 可以將零知識 (ZK) 證明的效率提高 50 到 100 倍。 然而，RISC-V 真的更勝一籌嗎？ EVM 已經穩定運行了大約九年，是一個久經考驗的平台，而 RISC-V 在區塊鏈執行環境中缺乏豐富的實際經驗。 雖然 PolkaVM 已經採用了 RISC-V，但我認為它尚未得到充分驗證，因為它尚未在主網上得到徹底驗證。

EVM 專門針對智能合約執行進行了優化，而 RISC-V 則設計為通用架構，可能缺乏針對區塊鏈用例的定制優化。 雖然 RISC-V 的多功能性允許使用其他區塊鏈的編程語言，但 Vitalik 本人指出，利用現有 SOLidity 進行改進更為可取。 將整個生態系統過渡到新的架構是一項艱鉅的挑戰。

在軟件中實現 RISC-V 不可避免地會導致性能下降。 使用模擬器進行基於軟件的執行會引發對其高效處理任務能力的質疑。 另一方面，採用 RISC-V 硬件將帶來巨大的過渡成本。 我認為 ZK-EVM 已經能夠滿足當前需求。 考慮到開發成本、過渡所需的工作量以及不可預見的錯誤的可能性，用 RISC-V 替換 EVM 似乎並非一個可行的方案。

雖然過渡到 RISC-V 可能會帶來潛在的好處，但我認為改進 ZK-EVM 和優化現有的 EVM 是更實用、更穩定的替代方案。 [src[22]]

[23]（Cartesi[24]’s VM CORE Developer）：作為積極參與開髮用於區塊鏈應用的 RISC-V 虛擬機 Cartesi Machine[25] 的開發者，我想分享一些支持 RISC-V 在以太坊執行層探索方面的觀點。

我認為採用 RISC-V 的最大優勢之一是可以立即訪問成熟的工具和生態系統。 無需構建完全定制的環境，使用 RISC-V 可以讓開發人員（以及核心協議）充分利用 GCC 和 LLVM 等編譯器、調試器、庫，甚至 Linux 等完整操作系統數十年來積累的經驗。 與較新、缺乏實踐檢驗的工具鏈相比，這顯著降低了開發人員的門檻，並可能降低編譯器 bug 帶來的風險。 這與允許使用 Rust 甚至 C++ 等語言編寫的合約通過標准後端編譯，以以太坊為目標的目標非常契合。 對於那些質疑 LLVM 或 GCC 中 bug 的人來說，使用 COMPCert[26] 等經過形式化驗證且目前能夠以 RISC-V 為目標的編譯器來增強安全保障是可行的。 從更大角度考慮，甚至可以在涵蓋 RISC-V 特權 ISA 規範的虛擬機（例如我正在開發的虛擬機）上，在經過正式驗證的 RISC-V 操作系統內核（例如 seL4[27]）上運行應用程序，這對於要求在操作系統環境中運行的更複雜的應用程序來說是一種可能性。

一些人提出的性能擔憂並非空穴來風，但可以解決。 根據我的經驗，RISC-V 在正確實施的情況下並不會犧牲執行性能。 雖然 u256 操作自然會分解為多條指令，但在實踐中，在經過良好優化的 RISC-V 虛擬機中，在大多數情況下，這樣做的成本應該不會對性能造成太大影響。 此外，虛擬機級別的優化技術可以顯著降低這些成本，因為 RISC-V ISA 具有足夠的可擴展性，可以添加針對區塊鏈的自定義擴展，從而優化常見的加密操作（例如 Keccak256）。

我認為，將未來的執行層建立在像 RISC-V 這樣標準化、開放且支持良好的 ISA 之上，將提供堅實的基礎。 它提供了一條利用現有軟件生態系統的途徑，有可能簡化開發人員的體驗，並受益於 RISC-V 領域未來硬件的進步。

雖然道路複雜，但我相信，RISC-V 在可擴展性、工具成熟度和長期可維護性方面的潛在優勢，使其成為未來區塊鏈執行環境非常值得追求的方向。 目前，區塊鏈領域中許多現有的 RISC-V 虛擬機證明了，穩健且可立即投入生產的 RISC-V 實現是可以實現的。 具體來說，我認為 Cartesi Machine 展現了利用標准開放 ISA 的強大功能。 它是一款穩定、高性能的 RISC-V 模擬器，實現了標準的 RV64GC ISA，能夠運行整個 Linux 軟件棧和未經修改的 RV64GC ELF 二進製文件。 至關重要的是，它完全確定性，甚至包括浮點運算。 對於那些好奇並想了解它運行能力的人，我推薦使用我的 WebCM[28] 實驗進行實驗，這是一個無服務器終端，通過模擬由編譯為 WebAssembly 的 Cartesi Machine 模擬器驅動的 RISC-V 機器，直接在瀏覽器中運行虛擬 Linux。

目前，L1 提案專注於零知識證明，而 Cartesi 目前則通過交互式欺詐證明、利用確定性執行和狀態 Merkle 證明來實現鏈上驗證。 儘管驗證機制有所不同，但 Cartesi 確認，在 RISC-V 之上構建一個可驗證且確定性的執行環境是可行且值得的。

當然，將 RISC-V 直接集成到 L1 並進行零知識證明會帶來獨特而重大的挑戰，尤其是在 Gas 計量、定義狀態交互的精確係統調用以及針對 RISC-V 指令優化零知識電路方面。 在零知識證明的特定環境下的性能也需要深入研究。 幸運的是，許多 RISC-V 零知識虛擬機項目已經在針對這些方面進行研究和開發。

關於實施策略，我認為應該認真考慮一種“激進的方法”，即定義一個協議，將編譯為 RISC-V 的虛擬機解釋器的概念融入其中。 這種方法將開闢一條道路，使以太坊的核心 RISC-V 虛擬機能夠保持最小化和簡單化，同時仍然足夠靈活，能夠容納 EVM 之外的不同虛擬機解釋器，從而為開發人員在虛擬機開發中提供更多自由。

簡而言之，我相信利用像 RISC-V 這樣的標准在工具、開發人員熟悉度、靈活性，甚至長期硬件加速的潛力方面都具有巨大的優勢。 我使用 Cartesi Machine 的工作經驗強化了這樣一種觀點：RISC-V 是下一代可驗證區塊鏈計算的強大且可行的基礎。 看到它被認真考慮用於以太坊的核心執行層，我感到十分興奮。 [src[29]]

[30]：大家好，我是 Nervos CKB-VM 的原始設計者和現任維護者。 在 Nervos 看來，選擇 CKB-VM 完全出於第一性原理的思考：我們想要的是一個的沙盒，並且盡可能輕量地運行在商用 CPU 上。 事實證明，CPU 指令集才是最佳選擇，而 RISC-V 則在其他選擇中脫穎而出，當然還有其他開源 RISC CPU 內核，但在我們看來，RISC-V 是最受關注的，這意味著會有更多人參與開發工具鏈。 對我們來說，這將是一個巨大的優勢。

當我們討論 EVM 與 RISC-V 時，我建議我們更進一步，要么比較兩者都包含預編譯，要么比較兩者都不包含預編譯的優缺點。 我們不要將包含預編譯的 EVM 與不包含預編譯的 RISC-V 進行比較，或者反過來，在我看來，這種比較並不恰當。 假設使用 JIT 或 AOT RISC-V 實現，或者引入 AVX 指令，我們可能獲得與使用無預編譯 RISC-V 虛擬機的 EVM 相當的性能。

據我們所知，RISC-V 是 7 年前的最佳解決方案，在可預見的未來，它仍然是我們認為的最佳解決方案。 如果有人說 RISC-V 是硬件解決方案，那就這樣吧，我們已經通過純軟件實現了它，並且它仍然完美地滿足了我們的需求。 從這個意義上講，我們對目前的情況感到滿意，並將繼續沿著這條道路前進。 [src[31]]

CKB-VIRTUAL Machine（CKB-VM）是一個基於 RISC-V 指令集的虛擬機，用於在 Nervos CKB 上執行智能合約，用 Rust 編寫。 大家有興趣可以看 2018 年時 @Xuejie Xiao 發表的文章：An Introduction to Nervos CKB-VM[32]，看看他們那時候的思考，很棒的分享！

[33]: @VitalikButerin 為以太坊制定的 RISC-V 計劃非常大膽，但 MIPS 的成熟度和傳統使其成為一匹引人注目的黑馬——一套非常適合低延遲 ZK 證明的固定指令集。 MIPS 已經運行了 40 年的關鍵系統—— Ethereum 可以利用這種穩定性，實現類似（甚至更優）的效率提升，同時降低採用像 RISC-V 這樣被過度炒作且仍在成熟的 ISA 的風險。 既然 MIPS 已經得到驗證，為什麼還要押注 RISC-V 的成長陣痛呢？ [src[34]]

專為瀏覽器 / 隔離環境執行任意代碼設計：優勢：多（但帶來額外開銷），劣勢：（學術研究認為性能較低，但需辯證看待）、。

理論上 WASM 是不錯的選擇，但實際開發中調試極其痛苦。 與我們交流的多個 All in WASM 的團隊都表示後悔。 相比之下 RISC-V/MIPS 更易理解，這或許正是 Succinct/RISC0 等團隊選擇它們的原因。 [src[35]]

[36]（Sequence[37] 聯合創始人）：@VitalikButerin 我知道這有點牽強，但不妨考慮一下 Offchain LABs 團隊開發的 EVM+/Stylus 作為未來的 L1 執行層。 它完全兼容 EVM 字節碼，可在 WASM VM 中運行，並且支持任何支持 WASM 的語言（例如 Rust），性能顯著提升，同時在運行時保持與 EVM 字節碼合約的完全互操作性。 感覺這是在保持兼容性的同時最簡單的升級路徑。 [src[38]]

[39]：許多人認為 WASM 是區塊鏈虛擬機的理想選擇，主要是因為 WASM 是為軟件實現而設計的（如果這說得通，我們先忽略它）。 您是否知道，在 WASM 誕生之前，JavaScript 的一個子集 asm.js 曾一度流行？ asm.js 後來演變成了 WASM，並且不知何故變得比 asm.js 最初的願景要龐大得多（恕我直言，現在 WASM 看起來更像是一個乾淨、全新設計的 JVM，而不是 asm.js）。 但我們不要忘記 asm.js 最初的目標：人們渴望一個能夠確定性地映射到原生 CPU 指令的軟件 IR，而不是 90% 時間都能夠做到的 JIT。 如果 RISC-V 能夠實現這樣的目標，我認為它非常適合用作軟件虛擬機。 [src[40]]

[41]（Delphinus Lab[42]）：雖然 @VitalikButerin 力挺 RISC-V，但 ZK 虛擬機不是只有這一條技術路線。 ZK 虛擬機也不是 ETH 的專屬，它是一個獨立的可能比 ETH 生態更大的東西，ETH 需要 ZKVM，ZKVM 卻並不局限於以太坊生態。 [ src[43]]

ZK 系統使用 RISC 即精簡指令集，這裡又有兩種選擇，第一種是 Cairo 這樣的 ZK 特定語言自建一個自定義的指令集（學習曲線過於陡峭），第二種是使用現有的指令集。 RISC-V 就是其中之一。 @RiscZero[44] , @SuccinctLabs[45], @NexusLabs[46] 和 @a16z[47] 支持的 Jolt 這幾家都是基於 RISC-V 的 ZK 虛擬機項目。

早在 2018 年，以太坊生態就啟動了 eWASM 項目，EVM 的發明者 @gavofyork[48] 曾表示過 WASM 取代 EVM 的可行性，Polygon 創始人 @sandeepnailwal[49] 也一直是 WASM 的堅定支持者。 然而，eWASM 最終未被廣泛採用，原因包括工程複雜性、優先級調整以及 L2 方案的興起，在後續發布的路線圖中，eWASM 被擱置。

@VitalikButerin 發布提案後，Zebra 創始人@shumochu[50]，1kx 研究合夥人 @_weiDai[51] 等人都指出，WASM 也許比 RISC-V 更適合以太坊執行層，原因如下：

RISC-V 設計初衷是用於硬件實現，而不是作為中間表示。 如果用作以太坊合約的執行層，仍需構建一個虛擬機層來處理 gas 消耗和控制執行流程，這增加了複雜性。

WASM 沒有跳轉指令，代碼結構簡單，易於驗證合約屬性。

開發者可以用目前幾乎所有主流編程語言編寫程序編譯為 WASM，學習成本大大降低。 Miden 創始人 @bobbinth[52] 進一步建議，如果追求 ZK 友好性，可以設計比 RISC-V 更優的指令集，或者用 WASM 組件模型。 [src[53]]

我所在的 @Delphinuslab[54] 就開源了業界第一個 ZKWASM 虛擬機，雖然目前還只有 solidity 的 SDK，但實際上，ZKVM 的合約結算可以去任何鏈上，未來也完全可以拓展到 Solana, Sui 等等 EVM 異構鏈上。

1. 讓更多的開發者使用自己最熟悉的編程語言進入區塊鏈世界，不用強迫每個人學 Solidity（和更複雜更小眾的區塊鏈語言）或者 Rust

2. 讓更多 Web2.5 網頁小程序可以實現一鍵上鍊，如果完全跑通，數以千計的瀏覽器小程序都可以快速部署到區塊鏈上

3. 打破不可能三角，實現去中心化、效率、安全的平衡。 [src[55]]

這兩大 CPU 指令集均非開源： ARM 屬於 RISC 精簡指令集，x86 屬於 CISC 複雜指令集。 隨著 CPU 硬件演進，二者都變得極其複雜。 值得注意的是，雖然 CISC 因複雜性在 CPU 領域逐漸被 RISC 取代，但在區塊鏈場景中 CISC 反而更具優勢。 [src[56]]

[57]：x64 太過重量級（當我們第一次嘗試 RISC-V 時，居然有人正在使用 x64 構建區塊鏈虛擬機！），而 Arm 可能存在許可問題，也可能不存在。 [src[58]]

首個區塊鏈 VM，專為比特幣編程設計：

專為區塊鍊和比特幣交易模型打造、適應對抗性環境、支持多籤等基礎操作

功能極其有限、受比特幣網絡處理能力嚴重製約。

我們從 Bitcoin Script 繼承了 P2SH（支付到腳本哈希）這一強大範式——條件編程。 這種可修剪的程序範式（執行後可從全節點刪除）能支持：場外交易 / 多簽錢包 / 商品拍賣等豐富場景。 比特幣架構啟示我們：VM 設計必須與交易模型深度協同。 [src[59]]

：由 Meta 團隊開發的區塊鏈專用 VM，強調安全性：

：區塊鏈原生設計、對抗性計量支持、配套專屬語言 Move

：為實現安全犧牲了大量狀態靈活性、過度 RISC 化（見前文分析）、生態分裂（SUI/aptos 存在不兼容變種）。

2020-21 年 Move 生態幾乎停滯。 我們放棄採用是因為不願受制於無法創新的他人架構，且其 "安全" 特性更多是 RISC 系統的包裝，並不能阻止糟糕的代碼編寫。 當時的形式化驗證僅適用於簡單方法而非完整應用，性價比極低。 [src[60]]

堪稱區塊鏈界的 PHP，支撐著數千億價值的智能合約：

區塊鏈原生設計、完善的計量機制、全生態兼容、Solidity 語言久經考驗

256 位字長設計、僅支持調用 / 合約，缺乏腳本功能、缺少條件編程（無 P2SH 等價物）、基於過度簡化的交易模型、效率低下（字長和操作碼設計導致大量計算浪費）、高度狀態化設計導致存儲訪問成為性能瓶頸。

雖然有些團隊聲稱通過新型數據庫或狀態訪問方案解決了問題，但本質上這些計算本可避免。 EVM 適合快速建立生態，但從交易模型和設計空間角度看缺乏創新。 Vitalik 的喊話或許正是意識到這一點。 [src[61]]

[62]：RISC-V 是否真的比 EVM 更好尚不清楚。 EVM 基於堆棧，因此其寄存器文件很小。 EVM 操作的是 256 位數字，如果小得多的值占主導地位，這可能會成為一個問題。 然而，證明器可以訪問實際的執行軌跡，因此它可以為較小的值選擇更輕量的實現選項（例如，32 位值的字節分解佔用的行數比 256 位值的字節分解佔用的行數要少）。 [src[63]]

另一個方面是智能合約形式化驗證的成本。 EVM 的指令集 (ISA) 比 RISC-V 更有限，因此 F/V 總體上會更複雜。 RISC-V 智能合約通常會包含更多循環和更多內存操作，而這兩者都會給 F/V 帶來問題。

例如，一項研究 (/www.cs.utexas.edu/~isil/solis.pdf[64]) 表明，大約五分之一的 EVM 智能合約包含一個或多個循環。 由於 EVM 操作的是 256 位值，因此在 RISC-V 代碼中需要更多循環。 即使循環展開，也會導致更大的 SMT 查詢。

RISC-V 擁有更豐富的內存模型，應該會有更多的內存操作（例如，EVM 擁有 1024 個 256 位堆棧，而 EVM 則擁有 16-32 個 32/64 位寄存器）。 因此，混疊（兩個語法上不同的表達式指向同一內存位置）將是一個更嚴重的問題。 這反過來會影響靜態分析，例如調用圖重構、指向分析等。

我預計，與 EVM 智能合約相比，對存在循環 / 混疊的 RISC-V 智能合約進行形式化推理將更具挑戰性。 [src[65]]

：Solana 虛擬機近年崛起：

區塊鏈原生設計、對抗性計量支持、可編譯為原生代碼、高性能設計

架構複雜難懂、Rust 等語言開發體驗差、缺乏成熟的專屬語言。

我們未選擇 SVM 主要因其交易模型假設——類似以太坊的簡單設計更追求速度而非複雜多方結算，這與我們規劃的交易模型不匹配。 [src[66]]

（StarkWare 生態經理）：@IAmNickDodson 精彩分析！ 要是能包含 CarioVM 就更好了。 [src[67]]

：未包含只是因為 2020/21 年調研時它尚未進入我們視野。 我是 Cairo 和 STARK 技術的忠實粉絲。 [src[68]]

（StarkWare 聯合創始人）： @IAmNickDodson 絕佳的討論！ 唯一建議是加入 Cairo 分析。 我來試補充： 優勢：專為區塊鏈 +zksTARK 效率設計、線性類型安全、高效的 Gas 計量（Sierra），劣勢：知名度 / 工具鏈完善度較低 :) [src[69]]

：感謝大家的精彩點評，最終你們的結論是什麼呢？ 有哪些洞見是可以分享給我們大家的呢？

：研究所有 VM 後我們意識到：虛擬機本身的重要性被高估了。 理論上這些 VM 都能（除 BitcoinScript 外）以不同效率完成所需計算。 真正關鍵的是 VM 與交易模型的協同設計。 許多鏈過度關注 VM 卻忽視交易模型——這才是區塊鏈行為的核心。 [src[70]]

FuelVM 的獨特之處正在於此，這些是 FuelVM 的複合優化 [src[71]]：

• 內存效率（共享內存上下文減少拷貝）

• 寄存器與內存的智能利用（如將完整交易置於可視內存實現運行時自省）

• 極致減少 IO 訪問

• 強化交易層能力（讓交易承擔更多，VM 承擔更少）

• 交易模型兼具狀態訪問與多資產 / 多條件 / 多執行模式流轉能力

• CISC 與 RISC 的黃金平衡

• 無全局狀態樹（UTXO 模型通過時間回溯天然防雙花）

• 所有操作碼為計量效率優化

• 支持謂詞條件編程等多樣化程序類型

• 配套 Sway 語言兼具 Rust 性能與 Solidity 開發體驗

傳統認知認為區塊鏈 VM 應追求極簡指令（出於安全和原生代碼編譯考慮）。 但問題在於：樂觀驗證場景下每個操作都需計量。 VM 越簡單，實現相同功能所需操作碼越多，鏈上計量計算量就越大。 因此 FuelVM 選擇設計更多高效操作碼——用更少操作完成更多功能。 你可以將 FuelVM 視為 CISC 與 RISC 的融合體。 雖然更多指令通常意味著字節碼體積增大（在帶寬受限場景會有影響，但壓縮可緩解），但這能顯著降低樂觀驗證的計量開銷，為開發者提供更強大的工具。 即便在 ZK 場景，複合操作也能獲得更好的優化效果。。 [src[72]]

有想對其他 VM 技術選型的工程師說的嗎？ 比如以太坊 :)

：如果以太坊選擇 RISC 路線，必須同步考慮交易模型。 VM 只是拼圖的一部分——RISC-V 無法解決代幣核算、突破智能合約範式、構建支撐全人類與機器人的高性能區塊鏈應用等問題。 Fuel 選擇做正確而非流行的事，這意味著持續的痛苦（看看我們的代幣就知道），但也為開源區塊鏈生態提供了新的設計範式。

如果你正在考慮構建區塊鏈，並需要深度契合區塊鏈本質的架構，FuelVM/Sway 值得考慮。 性能表現更是瘋狂：M4 處理器上 15 萬 TPS，10 毫秒軟確認，從烤麵包機到超算都能運行。 你可以了解更多有關 FuelVM 的信息：Why the FuelVM is the EVM but greatly improved and what this means for the future of blockchain[73]

[74]：關於 ZK 的另外一點，首先，這只是我個人對零知識的看法，RISC-V 有兩種與零知識相關的不同用例：1）用於表達將被 ZK 證明的程序的虛擬機 /IR，2）ZK 驗證器運行的底層平台。 一個簡單但不准確的類比是，在零知識證明算法有一個虛擬機（要點 2）。 它們應該分開討論。

Nervos CKB-VM 採用嚴格的無預編譯設計，完美契合了第二點：你可以將 ZK 驗證器代碼編譯為 RISC-V 代碼，並在 Nervos CKB-VM 上運行該 ZK 驗證器。 從這個意義上講，Nervos CKB 將能夠靈活地支持任意的 ZK 解決方案。 換句話說，我認為 Nervos CKB-VM 是 ZK 算法虛擬機 (VM) 的不錯選擇。

第一條將作為一個單獨的用例，我對零知識證明的內部機制不太熟悉，因此無法判斷 RISC-V 是否是一個合適的解決方案。 我懷疑零知識證明算法的某些特性可能會影響在零知識證明算法構建虛擬機的選擇。

我可能錯了，但我感覺 @VitalikButerin 可能在這裡談論的是第 2 點，或者是 ZK 算法下的適當 VM ，所以也許我們不必討論 RISC-V 是否適合 ZK 證明？

：zksync 已準備好進行以下更改： 新的證明系統 Boojum2 已經是 RISC-V，有一些事情將使整個以太坊（不僅僅是 ZKsync）受益： 全新 Solidity - > LLVM - > RISC-V 編譯器即將推出。 [src[76]]

ZK 方向的（如果擴展 L1 在節點驗證時無需重新執行 那麼這幾個 zkvm 的將替代 zkevm），@SuccinctLabs[78] 和 @RiscZero[79] 都是 zk risc-v vm, @UntoLabs[80] sol 生態的一個核心開發者出來做的鏈 ，執行層 vm 是 risc-v vm。 [src[81]]

：非常感謝各位大佬的精彩分享，本次 “” 就到此結束了。 因時間和篇幅原因，還有很多特色的虛擬機我們不能一一引薦了，可能未來我會再繼續更新或增加第二場。 各位觀眾如需了解詳情，可點擊每個觀點 / 發言結尾處的 [src]。

在這場 “虛擬圓桌會議“ 中，我們看到不同區塊鏈項目選擇了截然不同的技術路線——EVM 追求生態兼容，RISC-V 專注硬件效率，WASM 擁抱多語言開發，MoveVM 強調資產安全，FuelVM 則突破性能極限。 這恰恰說明，在區塊鏈的世界裡，沒有放之四海而皆準的最優解，只有最適合自身發展目標的權衡取捨。

通過這場技術辯論，我們得以窺見：

• 以太坊選擇保守升級，是因其生態價值優先

• Nervos 擁抱 RISC-V，源於對硬件友好的極致追求

• APTos/Sui 押注 MoveVM，體現對安全性的偏執

• Fuel 另闢蹊徑，用混合架構突破性能瓶頸

這些選擇背後，是各團隊對"區塊鏈應該是什麼"的不同答案。 理解這些技術決策的邏輯，或許比爭論孰優孰劣更有價值——它讓我們看到這個領域真正的多樣性，也預示著 Web3 未來可能呈現的百花齊放格局，很精彩，不是嗎？

本文內容為公開技術討論的匯總與重組，旨在對當前主流 Web3 虛擬機技術進行客觀對比與分析。 文中提及的所有項目、技術方案及產品（包括但不限於 EVM、RISC-V、WASM、MoveVM、FuelVM 等）均基於開發者社區公開討論內容整理，僅代表相關發言者的個人觀點，不代表本文作者或發布平台的立場。

1.：本文對虛擬機的討論僅限技術層面，不構成對任何項目、代幣或產品的背書或推薦；

2.：區塊鏈技術迭代迅速，文中信息基於 2025 年公開資料整理，實際發展可能已發生變化；

3.：加密貨幣及區塊鏈項目存在市場風險、技術風險與監管不確定性，請讀者務必自行研究並謹慎決策；

4.：本文內容絕不構成任何形式的投資建議，所有技術分析不應作為投資依據。

區塊鏈技術仍處於快速發展階段，任何技術選型都需結合具體應用場景評估。 我們鼓勵讀者通過項目官方文檔、審計報告等一手信息進行獨立判斷。

本文內容系根據互聯網公開資料（包括但不限於技術論壇、社交媒體、開發者文檔等）進行採集、匯總及重組而成。 為保持行文連貫與可讀性，編者對原始內容進行了以下處理：

：包括但不限於觀點摘錄、語句提煉、段落重組及必要的斷章取義，部分內容可能存在上下文缺失；

：涉及中英文互譯的內容可能存在語義偏差或表達差異，非逐字直譯；

：部分專業術語或技術描述已作通俗化處理，可能損失原始精度。

• 所有觀點及技術論述的最終解釋權歸原作者所有，請以每個觀點結尾標註的[src]原始鏈接內容為準；

• 本文未經提及的項目方、技術團隊或發言者事前授權，僅作為技術討論的公益性整理；

• 若內容存在表述不當、版權爭議或侵權嫌疑，請聯繫 @OPEnBuildxyz[82] 及時告知，我們將第一時間核實並修正。

本文遵循合理使用（Fair Use）原則，旨在促進區塊鏈技術知識的傳播與討論，不用於任何商業用途。 引用時請註明原始來源並遵守相關版權法規。