了解 EVM 本地設計的 Optimist...

首頁
專家專欄
了解 EVM 本地設計的 Optimistic Rollup 的關鍵優勢

了解 EVM 本地設計的 Optimistic Rollup 的關鍵優勢

發表於 2022-10-02 16:12 作者： Defi之道

幾周前，我們宣布了 Specular—一個具有新穎 EVM 本地設計的 Optimistic Rollup—並且很高興看到我們的 Twitter 线程激發了關於如何最好地設計此類系統的興奮和討論。在這篇文章中，我們想澄清一下我們認爲 EVM 原生方法相對於其他 Optimistic rollup 方法的一些關鍵優勢，包括 Optimism 和 Arbitrum 正在進行的工作，通過在較低級別 VM 上定義的欺詐證明系統來追求 EVM 等效性。

在我們开始之前，這篇文章假設您對 optimistic rollup (ORU) 有基本的了解；以及現代以太坊 ORU 如何依賴負責裁決爭議的鏈上交互式欺詐證明機制。可以在此處找到對相關先前工作的廣泛調查。

背景

Optimism 和 Arbitrum 正在推出一種利用現有以太坊客戶端基礎設施的新架構，以便與現有的以太坊工具和 L2 智能合約（稱爲 EVM 等效性）完全兼容。由客戶端執行導致的狀態轉換爭議通過鏈上驗證的交互式欺詐證明 (IFP) 解決。爲了支持 IFP，客戶端程序被編譯爲較低級別的目標 VM（例如 MIPS 或 WASM），可以在（MIPS/WASM）指令級別爲其構建狀態轉換證明。然後將生成的二進制文件提交到鏈上，允許鏈上驗證者以較低級別 VM 語義的粒度強制執行其執行。

至關重要的是，這種較低級別的 VM 方法完全不知道 EVM 的存在及其語義。因此，它不是按照意圖強制執行 EVM 語義[1]，而是強制執行較低級別的語義來執行據稱實現了 EVM 的特定二進制文件。因此，這種設計技術 (1) 排除了多個以太坊客戶端程序[2]的無許可和信任最小化參與；(2) 導致難以獨立審計且無法正式驗證的臃腫、過大的可信計算庫（TCB）；(3) 遭受頻繁觸發但不透明的升級過程的困擾，進一步增加了安全審計开銷。

爲了解決這些問題，我們主張採用我們認爲更簡單、更自然的 EVM 原生方法來處理 IFP。也就是說，我們建議在單個 EVM 指令級別顯式地在鏈上執行 EVM 語義。下面我們將描述這種設計相對於較低級別的 VM 方法的一些優點。

客戶端多元化

雖然以太坊網絡由包括 Geth、Besu 和 Erigon 在內的不同客戶端運行（然而目前採用率不足），但當前的 L2 解決方案還沒有接近支持客戶端多樣性。這很重要，因爲我們希望防止由軟件錯誤/漏洞引起的無效 ORU 狀態轉換因爲未檢測到和無可爭議而出差錯。

Optimism 團隊提出了一種潛在的解決方案，該解決方案通過爲許多列入白名單的客戶端程序中的每一個包括一個鏈上二進制承諾，將較低級別的 VM 方法擴展到多客戶端設置。驗證者必須准備好參與涉及其中任何一個的挑战階段，只有在他們設法贏得所調用的挑战階段的門檻時才能贏得整體爭議。

這種方法只提供外在的客戶多樣性，而不是證明系統本身的內在。每個客戶都有自己的獨立證明系統與之關聯。事實上，這只是一種通用的縱深防御技術，任何 Rollup 都可以在使用多數票組合不同證明系統的方案中使用（例如，甚至將 Optimistic Rollup 和 ZK-rollup 組合到一個多重證明系統中））。雖然它可能會提供一些客戶端多樣性的表象，但在單獨使用時會引入多個問題：

1.客戶端程序的參與是許可的。也就是說，客戶端程序的編譯二進制文件必須作爲白名單程序提交到鏈上，才能被允許參與爭議解決。

此外，由於二進制承諾隨版本的變化而變化，Optimism 的治理過程也處於升級任何客戶端程序（甚至只是其編譯工具鏈）的關鍵路徑上。
理想情況下：客戶端程序可以參與和升級，而無需經過 ORU 的治理。

2.有一個強大的信任假設，即大多數客戶端程序正確地實現了 EVM。這可以解釋爲 K-of-N 版本或 N-of-N 版本編程。

正如我們在下一節中指出的，這尤其成問題，因爲客戶端程序難以審計。
理想情況下：只需一個客戶端程序即可正確實現 EVM（即使用經典的 N 版本編程）。

3. 驗證者別無選擇，只能准備運行每個列入白名單的客戶端程序來解決爭議。

由於爭議過程中的額外冗余，這不僅昂貴且緩慢，而且操作上也更加復雜，因爲驗證者必須學習如何配置和運行每個程序。
操作復雜性隨着客戶數量的增加而增加，對可以包含多少客戶端程序設置了實際限制。

總而言之，我們認爲這種設計不能有效地分配信任——客戶端程序包含是許可的，必須信任大多數人才能正確實現 EVM 語義，並且支持的數量實際上會受到信任、devops 和一般操作復雜性問題的限制。

我們的方法提供了內在的客戶端多樣性，因爲鏈上驗證者對客戶端程序是不可知的。所有客戶端都使用相同的證明系統進行交互。任何支持 EVM 語義的程序都可以無許可參與，並且只有一個程序必須實現正確的語義才能檢測/爭議故障。驗證者還可以真正選擇運行他們最熟悉的任何客戶端程序，從而提供更簡單的 devops。

因此，EVM 本地 ORU 爲無需許可、信任最小化的客戶端多樣性提供支持。雖然這兩種方法都可以檢測惡意注入的狀態轉換（例如，由無效交易引起的），但只有 EVM 本地方法能夠可靠地檢測和解決錯誤/漏洞。

可審計性

ORU 的 TCB 必須是可審計的和/或可正式驗證的，以確保其可信度。現有的 ORU 達不到這個目標。

客戶端程序信任假設

在較低級別的 VM 方法中：因爲鏈上驗證者在目標 ISA 指令級別（而不是較高級別的 EVM 語義）強制執行客戶端程序，因此僅檢查驗證者不足以確定等價性將強制語義與 EVM 的語義相比較。ORU VM 的強制語義由列入白名單的客戶端二進制文件隱式確定。如果不審計整個客戶端程序和編譯器，就不可能先驗地確定這些語義是否等同於 EVM 語義。而在外部客戶端多樣性的情況下，這個問題會進一步惡化，因爲語義是由多數共識決定的（通過爭議機制表現出來），需要對所有或至少大多數客戶端程序和編譯器進行審計。

因此，TCB 不僅包括驗證者，還包括每個客戶端程序，以及與每個程序關聯的編譯器工具鏈和二進制提交生成器。TCB 臃腫的規模和復雜性造成了明顯的軟件錯誤/漏洞風險，這些風險可能會影響 ORU 的安全性，並相應地增加審計开銷。

我們強調，它不像捎帶由上遊客戶端程序（即 Geth）的維護者進行的安全審計那么簡單，因爲該程序必須定制以支持一步證明生成（請參閱此處和此處的 Geth 分叉）。此外，由於鏈上驗證者無法訪問存儲區塊、交易和帳戶/存儲狀態的以太坊數據庫，因此他們必須插入原像預言機組件以允許 MIPS/WASM 代碼查詢數據庫。

在 EVM 本地方法中，EVM 語義由鏈上驗證者明確實施。由於無需許可和信任最小化的客戶端多樣性，ORU 的整體安全性不會在很大程度上依賴於任何單個客戶端程序的正確性。因此，EVM 本地 ORU 的 TCB 僅包括鏈上驗證者。這很好，因爲 TCB 的有限範圍允許它更容易審計，並且相對於正式的 EVM 規範完全可以正式驗證，正如我們在下面談到的那樣。

驗證者信任假設

EVM 本地和較低級別的 VM 方法都在 TCB 中包含一步形式驗證者。雖然較低級別的 VM 驗證者可能更易於實施和審計（由於指令集較小），但考慮到端到端實施和/或審計系統其余部分的難度——尤其是客戶端和編譯器。

此外，形式驗證——尤其是 KEVM——使競爭環境更加公平。KEVM 是使用支持 Solidity 智能合約形式驗證的 K-Framework 實現的 EVM 的可執行形式規範。因此，KEVM 是 Specular 的完美補充，因爲它提供了正式的規範和一套驗證工具，使我們能夠正式驗證我們的鏈上驗證者。我們正在積極參與這一研究方向，目前正在與 KEVM 團隊合作探索利用 KEVM 的各種方法。

另一方面，正式驗證採用低級別 VM 方法的 ORU 的 TCB 是不可行的。雖然可以正式驗證 MIPS 驗證者，但這並不能保證 EVM 語義的執行。爲了實現這樣的保證，Geth 本身——連同它的編譯工具鏈——必須經過形式驗證；然而，鑑於這些程序的復雜、計算無界和並發的性質，這實際上是不可能的。

因此，EVM 本地 ORU 的 TCB 可以根據現有的、經過充分測試的正式規範進行形式驗證，而較低級別的 VM 方法則不能。

編譯器信任假設

在較低級別的 VM 方法中，引入了高度定制的編譯工具鏈來支持一步證明生成。然而，這個工具鏈並不成熟。編譯器和目標 ISA 都是定制的（參見此處和此處）。Nitro 爲原像預言機和收件箱添加了幾個自定義 WASM 操作碼，而 Cannon 則添加了幾個自定義 MIPS 系統調用。目標運行時模型也受到若幹約定或約束的修改和約束。例如，Nitro 和 Cannon 都對內存進行了默克化處理，以實現簡潔的一步證明，而不會泄露整個內存空間。Cannon 還要求將編譯後的程序和輸入/輸出加載到內存的特定位置。此外，Nitro 和 Cannon 都將浮點指令替換爲軟浮點實現（參見此處和此處‌）。@pepyakin 寫了一篇很棒的博客文章‌，它涉及到使用 WASM 作爲目標 ISA 的其他復雜性。

這些定制中的任何一個都可能無意中改變已編譯的 Geth 二進制文件的行爲，因此必須進行廣泛的審計。鑑於編譯器工具鏈的不成熟，x86 Geth 和 MIPS/WASM Geth 之間的一致性不能被視爲給定的。

EVM 本地方法沒有任何這些問題——正常的執行和爭議解決在相同的抽象層面上運行，並且在實踐中密切共享代碼路徑。

TCB 升級

頻率

雖然以太坊客戶端程序經常升級，但以太坊協議本身往往一年只硬分叉幾次。實際修改 EVM 語義的硬分叉甚至更少見，大約一年一次。此外，許多這些更改（例如共識）不會影響執行語義。因此，與採用較低級別 VM 方法的 ORU 相比，EVM 本地 ORU 的 TCB 需要相對較少的升級。相比之下，較低級別的 VM 方法需要每次客戶端升級時都升級 L1 合約，因爲更改必須反映在鏈上新的二進制承諾中。

此外，我們預計以太坊協議和 EVM 規範最終會以某種形式穩定下來。這有兩個含義：

從長遠來看，EVM 本地 ORU 的 TCB（或等效意義上的鏈上驗證者）的升級頻率將會降低——最終趨於零。另一方面，個別客戶端程序可能會繼續經歷旨在提高性能和修復錯誤的升級，從而在較低級別的 VM 方法中觸發頻繁必要的 TCB 升級。
EVM 本地 ORU 可以與以太坊同步穩定。這是因爲負責开發 Specular 的社區可能會放棄其 L1 合約升級密鑰，而不會失去向客戶提供性能升級和錯誤修復的能力。另一方面，一旦 Optimism 團隊扔掉了鑰匙（正如他們所說的那樣），就不可能及時進行此類升級（如果有的話）。這使得這樣做是一項風險更高的工作，即使外部客戶多樣性計劃提供了輕微的保護措施——以至於它可能永遠不夠安全，無法擺脫它們。

因此，我們認爲放棄（快速）升級密鑰的最安全和最實用的途徑是通過 EVM 本地 ORU 設計。

透明度

較低級別 VM 方法中 TCB 的大小和復雜性導致升級過程不透明。例如，客戶端的升級方式不如以太坊規範透明，後者需要經過慎重的提議 (EIP) 流程。對特定於 ORU 的工具鏈組件的升級，例如 Golang-to-ISA 編譯器，仍然更不透明。

在我們的方法中，語義驗證與實現這些語義的客戶端程序之間存在明顯的區別。因此，更容易辨別升級是否會潛在地影響語義的解釋——審計人員只需要查看 L1 合約源代碼中的差異。

結論

由於上述原因，我們相信 EVM 本地設計可提供卓越的安全性和信任屬性。

感謝 Patrick McCorry 對這篇文章的反饋和意見。

附錄

在本節中，我們對 @kelvinfichter 深思熟慮的博文‌中的具體摘錄做出回應，他在博文中總結了（他的觀點）兩種方法之間的權衡。雖然這篇文章承認了上述大部分觀點，但它也提出了一些有趣的問題。

升級

Optimism 基本可以在不觸碰任何智能合約的情況下自由修改客戶端代碼

二元承諾仍然必須改變。在治理過程中如何處理對安全關鍵合約代碼的修改和對合約中編譯和提交的安全關鍵客戶端代碼的修改之間應該沒有有意義的區別。任何一方的修改都會對較低級別 VM 方法中 Rollup 的安全性產生不利影響。

此外，雖然確實任何人都可以計算客戶端代碼版本之間的差異，以查看升級中發生了什么變化，但在實踐中審核跨越數萬到數十萬個 LoC 的代碼庫的更改更具挑战性，因爲任何給定修改的影響都不太清楚。
此外，由於客戶端的更改不需要傳播到證明，EVM 更新不會觸發新的智能合約審計。原生 EVM 故障證明必然受上遊 EVM 更改的支配。以太坊硬分叉大約每年兩次，並且這些硬分叉中至少有一個通常會引入 EVM 調整（一些比其他更多，例如在倫敦硬分叉中引入 EIP-1559）。如果本地 EVM 證明系統想要維持上遊 EVM 等效性，則必須升級證明合約。

在 EVM 本地方法中需要審計的相同硬分叉也可能會在較低級別的 VM 方法中觸發審計。在我們看來，單個客戶端的工程/審計工作的差異並不顯着——正如前面所討論的，EVM 原生方法在多客戶端案例中領先。

引入新功能

嘗試在 EVM 之外引入新功能時，具有本地 EVM 證明的系統可能會更加困難。以調用數據（calldata）壓縮爲例 […]

我們同意 EVM 範圍之外的某些功能（例如調用數據（calldata）壓縮）可能有助於爲用戶實現低交易成本（盡管最近數據可用性層的發展利用了對以太坊的現有信任，這可能不是立即需要的）。較低級別的 VM 方法在這裏確實具有更大的靈活性。然而，所有的希望都不會消失。

通過將 L2 擴展與 EVM 語義分離，我們可以專注於確保鏈上驗證者的安全性。可以引入不同的驗證者來支持 L2 擴展，從而保持核心 EVM 驗證者獨立且完整。我們目前計劃插入零知識證明技術來驗證此類擴展。雖然在 SNARK 中執行 EVM 語義可能很復雜，但數據壓縮（calldata）等 L2 擴展更易於處理，因爲語義規範完全在我們的控制之下（因此可以設計爲對 SNARK 友好）。我們注意到，這仍然是一個正在進行的研究領域。

工程努力