開發者駁斥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 在這裡並沒有帶來任何簡化。