幾週前，我們宣布了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 友好）。我們注意到，這仍然是一個正在進行的研究領域。
工程努力
本地EVM 證明合約比低級證明復雜得多，以至於即使構建單個原生EVM 證明也將是一項巨大的工程工作。然而，KEVM 的存在意味著有可能形式驗證證明的EVM 方面的正確性。
鑑於迄今為止我們為構建Specular 所投入的工程資源數量，我們認為這是一個高估。此外，如上所述並在帖子中承認，許多問題實際上可以通過形式的方法來解決。
腳註
[1] 我們使用術語EVM 語義，包括以太坊黃皮書中定義的交易間和交易內語義。
[2] 為了消除歧義，我們將實現以太坊的軟件稱為客戶端程序，並將它們的實例（即運行該軟件的實際節點）稱為客戶端。
原文：Specular，由DeFi 之道翻譯編輯。
來源：DeFi之道