開發者駁斥Vitalik：前提假設有誤，RISC-V並非最佳選擇

本文來自：以太坊開發者 levochka.eth

編譯｜Odaily星球日報（@OdailyChina）；譯者｜Azuma（@azuma_eth）

編者按：

昨日，以太坊聯合創始人 Vitalik 發布了一篇關於以太坊執行層升級的激進文章（詳見《Vitalik 激進新文：執行層擴容“不破不立”，EVM 未來必須被迭代》），文中提到希望用 RISC-V 取代 EVM 作爲智能合約的虛擬機語言。

此文一出，立即在以太坊開發者社區激起了軒然大波，多位技術大佬對該方案表達了不同看法。文章發布後不久，一線以太坊開發者 levochka.eth 在原文下文撰寫長文反駁了 Vitalik 的觀點，其認爲 Vitalik 對證明系統及其性能進行了錯誤的前提假設，RISC-V 無法兼顧“可擴展性”和“可維護性”，或許並非最佳選擇。

以下爲 levochka.eth 原文內容，由 Odaily 星球日報編譯。

請不要這樣做。

這個計劃並不合理，因爲你對證明系統及其性能進行了錯誤的前提假設。

驗證假設

據我理解，該方案的主要論點是“可擴展性”（scalability）和“可維護性”（maintainability）。

首先，我想討論可維護性。

事實上，所有 RISC-V zk-VM 都需使用“預編譯”（precompiles）來處理計算密集型操作。SP 1 的預編譯列表可見於 Succinct 的文檔，你會發現它幾乎涵蓋了 EVM 中所有重要的“計算性”操作碼。

因此，對基礎層加密原語的所有修改都需要爲這些預編譯編寫並審計新的“電路”，這是一個嚴重的限制。

確實，如果性能足夠好，執行客戶端中“非 EVM”部分的可維護性可能會相對容易。我不確定性能是否會足夠好，但我對這部分的信心較低，原因如下：

• “狀態樹計算”（state tree computation）確實可以通過友好型預編譯（如 Poseidon）大幅加速。
• 但能否以優雅且可維護地方式處理“反序列化”（deserialization）尚不明確。
• 此外，還存在一些棘手細節（如 Gas 計量和各種檢查），這些環節可能屬於“區塊評估時間”，但實際上更應歸類爲“非 EVM”部分，且這些部分往往更容易面臨維護壓力。

其次，關於可擴展性的部分。

我需要重申一點，RISC-V 不可能在不使用預編譯的情況下處理 EVM 負載，絕對不行。

所以，原文中“最終證明時間將主要由當前的預編譯操作主導”這一說法雖然技術上正確，但過於樂觀 —— 它假設未來不會有預編譯，而事實上（在這個未來場景中），預編譯仍會存在，且與 EVM 中計算密集型操作碼（比如籤名，哈希，以及可能出現的大型數模運算）完全一致。

關於“斐波那契”（Fibonacci）示例，很難在不深入極底層細節的情況下做出判斷，但其優勢至少部分來自：

• “解釋器”（Interpretation）與“執行開銷”（execution overhead）的差異；
• 循環展開（減少 RISC-V 的“控制流”，Solidity 能否實現尚不確定，但即便單個操作碼仍會因解釋開銷而產生大量控制流/內存訪問）；
• 使用更小的數據類型；

這裏我想指出，要實現第 1 點以及第 2 點優勢，必須消除“解釋開銷”（interpretation overhead）。這與 RISC-V 的理念一致，但這不是我們目前討論的 RISC-V，而是一種類似的“（?）RISC-V” —— 它需要具備某些額外能力，比如支持合約概念。

問題來了

所以，這裏存在一些問題。

• 若要提升可維護性，你需要一個能編譯 EVM 的 RISC-V（帶預編譯）—— 這基本就是現狀。
• 若要提升可擴展性，則需要完全不同的東西 —— 一種可能類似 RISC-V 的新架構，它能理解“合約”概念，兼容以太坊運行時限制，並能直接執行合約代碼（且無“解釋開銷”）。

我現在假設你指的是第二種情況（因爲文章的其餘部分似乎暗示了這一點）。我需要提醒你注意，此環境外的所有代碼仍將用當前 RISC-V zkVM 語言編寫，這對維護有重大影響。

其他可能性

我們可以將字節碼從高級 EVM 操作碼中編譯出來。編譯器負責確保生成程序保持不變量，例如不會出現“棧溢出”（stack overflow）。我希望看到在普通 EVM 中展示這一點。正確編譯的 SNARK 可以與合約部署指令一起提供。

我們還可以構建一個“形式化證明”（formal proof），證明某些不變量得以保留。據我所知，這種方法（而不是“虛擬化，virtualization”）已在某些瀏覽器上下文中使用。通過生成這種形式化證明的 SNARK，你也可以實現類似的結果。

當然了，最簡單的選擇是硬着頭皮去做……

構建一個最小的“鏈式”MMU

你在文章可能隱含表達了這一點，但請允許我提醒：若想消除虛擬化開銷，必須直接執行編譯後的代碼 —— 這意味着你需要以某種方式防止合約（現在是可執行程序）寫入內核（非 EVM 實現）內存。

因此，我們需要某種“內存管理單元”（MMU）。傳統計算機的分頁機制可能不必要，因爲“物理”內存空間近乎無限。此 MMU 應盡可能精簡（因爲它與架構本身處於同一抽象級別），但某些功能（如“交易原子性，atomicity of transactions”）可移至該層。

此時，可證明的 EVM 將成爲運行於此架構的內核程序。

RISC-V 可能不是最佳選擇

有趣的是，在所有這些條件下，適合這項任務的最佳“指令集體系結構”（ISA）可能不是 RISC-V，而是某中類似於 EOF-EVM 的東西，原因在於：

• “小型”操作碼實際會導致大量內存訪問，現有證明方法難以高效處理。
• 爲減少分支開銷，我們在近期的論文 Morgana 展示了如何以預編譯級性能證明“靜態跳轉”（static jumps，類似 EOF）代碼。

我的建議是，構建一個對證明友好的新架構，配備一個最小的 MMU，允許將合約作爲單獨的可執行文件運行。我不認爲它應是 RISC-V，而應是一種專爲 SNARK 協議限制優化的新 ISA**，甚至部分繼承 EVM 操作碼子集的 ISA 都可能更好 ——** 如我們所知，不管我們願不願意，預編譯都會一直存在，所以 RISC-V 在這裏並沒有帶來任何簡化。