作者：Yiping, IOSG Ventures
本文為IOSG原創內容，僅做產業學習交流之用，不構成任何投資參考。如需引用，請註明來源，轉載請聯絡IOSG團隊取得授權及轉載須知。本文所提及所有項目均不構成推薦及投資建議。
隨著像zkSync 和StarkNet 這樣的ZKRUs 推出主網，Layer2格局正在迅速演變。傳統上，OPRUs 如Arbitrum 是首個進入市場的，因而擁有更強大的生態系統。與之相反，ZKRUs 在技術上有所突破，提供更高的吞吐量和更低的費用。
近幾個月，更多的活動從Layer1遷移到了Layer2，以尋求更快、更便宜的交易。以太坊的TVL過去一年從近400 億美元降至200 億美元。然而，Layer2的TVL 呈現出不同的畫面，巨大的成長表明Layer2的採用正在加速。
Arbitrum 憑藉超過50% 的Layer2 TVL 市場份額領先，儘管ZKRUs 也付出了努力。 Arbitrum 的先發優勢使其能夠保持主導地位。
分析每日交易數量顯示，像zkSync 和StarkNet 這樣的ZKRUs 在吞吐量上略微超過OPRUs。然而，Arbitrum 的生態系統優勢依然存在，儘管在每日TPS 上稍微落後。
OPRUs 出現的時間比ZKRUs 長。然而，ZKRUs 正在推出他們的主網，並從其他生態系統吸引用戶。作為OPRU 領域的領導者，Arbitrum 預計將透過他們的新更新來對抗ZKRUs 的崛起。
Arbitrum：Stylus
隨著開發者優化零知識技術和成本，由於其可擴展性優勢，ZKRUs 可能會繼續獲得市場份額。但是，Arbitrum 的網路效應提供了儘管有競爭壓力也能保持穩健的能力。透過像Stylus 這樣的創新解決方案，Arbitrum 可以用獨特的技術能力補充其領導地位，並繼續在Layer2競賽中保持領先。
簡而言之，Stylus 是一個為Arbitrum 設計的革命性新智慧合約環境，它允許開發者用像Rust、C++ 和Solidity 這樣的程式語言編寫高效、互通的程式。
它向區塊鏈開放了通用計算，並歡迎使用不同技術棧的開發者。
WASM
Stylus 透過增加一個與現有的以太坊虛擬機器（EVM）並行運行的WebAssembly（WASM）虛擬機器來運作。編寫在可以編譯為WASM 的語言的智能合約可以以比Solidity 快10 倍或更多的速度原生執行，大幅降低燃氣費用。 EVM 依然完全功能性，所以現有的Solidity 合約仍然如同今天一樣正常運作。兩個VM 同步操作，允許用不同程式語言編寫的合約相互調用，同時也能修改相同的底層區塊鏈狀態。
自訂預編譯
此外，Stylus 也支援自訂預編譯（Precompiles）。
預編譯是Ethereum 和Arbitrum 上用於非常有效率地執行特定加密或實用函數的底層模組。例如，有用於ECDSA 簽章驗證和計算SHA256 雜湊的預編譯。
要新增新的預編譯需要所有驗證者協調升級EVM，因此門檻很高。而使用Stylus，開發者可以輕鬆部署他們自己用Rust 或C++ 寫的預編譯。
例如，一個團隊可以使用用C 語言編寫的加密庫，並且未經修改地將其部署到Arbitrum。這將允許這些加密原語以超快的本地速度執行。
其他合約可以呼叫這個Stylus “預編譯”，就像它們呼叫原生預編譯一樣，來利用該加密技術。所有的燃氣計量和欺詐證明都會自動工作。
這使得團隊能夠在沒有任何特殊鏈支援的情況下，原型自訂加密、特殊的基於配對的曲線和其他新型原語。以太坊研究者甚至可以透過在Arbitrum 上以Stylus 預編譯的形式部署它們，先行迭代EIP 提案。
透過賦予開發者在鏈上原生地引入新的加密原語的能力，Stylus 大大拓展了可以建構的內容的範圍。預編譯不再僅限於EVM 支援的功能。
Stylus 的工作原理
在深入探討WASM 在區塊鏈宇宙中的更廣泛角色之前，理解Arbitrum 如何協調EVM 和WASM 的共存是至關重要的。這不僅僅是擁有兩個獨立的引擎；這是一種增強兩者優勢的協同關係。
Arbitrum 的獨特架構允許EVM 和WASM 之間進行無縫和同步的操作，這要歸功於其統一的狀態、跨VM 調用和相容的經濟模型。
用Solidity 或其他EVM 語言編寫的智能合約會像往常一樣編譯為EVM 字節碼。當執行時，這些合約在EVM 上運行，就像它們今天一樣。
對於編譯為WASM 的語言，例如Rust、C++ 和C，工作流程是：
- 開發者使用現成的WASM 編譯器，如Clang 或Rustc，將他們的智能合約編譯為WASM。
- WASM 字節碼以壓縮形式上傳到Arbitrum 鏈。
- 合約所有者呼叫`ArbWasm` 預編譯的`compileProgram` 方法，該方法為WASM 進行安全工具設置，對其進行Gas成本計量，並將其編譯為針對驗證器硬體優化的本地程式碼。
- 當合約被呼叫時，它在像Wasmer 這樣的WASM 運行時上運行，比EVM 快得多，從而節省了Gas Fee。
WASM 計量在每個基本區塊之前收取Gas，而不是像EVM 那樣按操作碼收費。這更為高效，確保合約不會失控。
EVM 與WASM
這兩個虛擬機器（VM）同步運行，允許它們在共享相同的全域狀態的同時互相呼叫。一個交易可能部分在EVM 中執行，部分在WASM 中執行，並且結果無縫地組合在一起。
等一下，兩個VM 怎麼能無縫地和同步地工作？
Polkadot 透過XVM 實現這一點。與Polkadot 不同，WASM 和EVM 出於幾個關鍵原因可以在Arbitrum 上無縫地和同步地工作：
- 單一狀態：兩個VM 都存取相同的底層資料結構和狀態Trie。一個VM 中的合約可以讀/寫到另一個VM 中的合約相同的位置。這提供了對鏈狀態的統一視圖。
- 跨VM 呼叫：當一個交易與EVM 合約互動時，Geth 處理它並提供一個結果。如果EVM 合約隨後呼叫了一個WASM 程序，WASM VM 接手以計算該部分的結果。
- 共享上下文：像區塊資料、發送者地址等系統資訊對兩個VM 都是可用的。一個WASM 合約可以像Solidity 合約一樣取得區塊號。
- 單一共識：驗證者運行兩個VM 以驗證交易並就正確的鏈狀態達成共識。爭議將調用統一的欺詐證明系統。
- 相容的經濟學：像Gas計量這樣的概念延伸到各個VM，確保在任一環境中都有適當的運算成本和資源。
對於詐欺證明，驗證者會在EVM 和WASM 執行中進行細分（bisect），以必要時識別任何無效的步驟。 WASM 的結構允許系統保證終止並強制證明的有效性。
區塊鏈| WASM
Arbitrum 並不是唯一一個認識到WebAssembly（WASM）變革潛力的平台。 Polkadot 和Cosmos 也都將WASM 整合到了他們的生態系統中，每個平台都提供了一組獨特的優勢和功能。
Polkadot 讓使用者用WASM 開發智慧合約，並支援兩種語言：一種嵌入式DSL 的AssemblyScript 和類似Rust 的Ink!。
另一方面，Cosmos 使用CosmWasm 作為其智能合約運行時，允許開發者用Rust 編寫合約。
在深入研究區塊鏈產業為何如此接受WASM 之前，有必要先了解Cosmos 和Polkadot 突出的具體優勢：
Cosmos 強調WASM 的以下優點：
- 與Rust 函式庫的兼容性
- 多樣化的開發者社區
- 增強的安全性，包括防止重入攻擊
- 易於測試
- 高效能
Polkadot 的WASM 運行時具有這些特點：
- 高效能
- 與EVM 的互通性
- 平台不可知性
- 緊湊的二進位大小
- 同時支援Rust 和AssemblyScript（TypeScript 風格）
儘管Polkadot、Cosmos 和Arbitrum 共享WASM 提供的一些共同優勢，但每個平台也都有自己獨特的屬性。
這些主要區塊鏈平台對WASM 的廣泛採用證明了其在行業中日益增長的重要性，這使得理解為何這項技術正在迅速成為現代區塊鏈架構基石變得至關重要。
為什麼選WASM
WASM 是什麼
為了理解區塊鏈和WebAssembly（WASM）之間的協同作用，首先必須了解WASM 是什麼以及其發展背後的動力。
WebAssembly 是一種二進位指令格式，可讓程式碼在Web 瀏覽器內以接近本機速度執行。它作為一系列程式語言（包括C 和Rust）的編譯目標，旨在快速、高效且安全。 WASM 有效地彌合了基於Web 和系統層級程式設計之間的鴻溝，從而提高了Web 效能和功能。
「Web」 在WebAssembly 中突出了其在JavaScript 環境（通常在瀏覽器中找到）中運行的能力。在這些設定中，開發者可以完全存取WASM API，並且具有全面的Web API 支持，賦予他們相當大的控制Web 行為的能力。
WASM 歷史
遵循「一次編寫，到處運行」的原則，WASM 出現作為一組長期挑戰的有力解決方案。截至2016 年，許多程式透過領域特定語言（DSL）引入新功能，這通常涉及維護、效率和安全之間的權衡。有越來越多的需求尋求一種解決方案，該方案可以在不影響這些方面的前提下，為無數伺服器提供新功能。
評估了各種現有解決方案的不足：
– 系統虛擬機
- 頻繁啟動和關閉帶來過多的開銷
- 缺乏程式碼可見性以確保安全
- 對效能需求過於抽象
– 容器
- 缺乏程式碼可見性以確保安全
- 由於高級抽象而效率低下
- 頻繁操作帶來顯著的開銷
– 語言級虛擬機
- 需要頻繁修改以確保安全
- 嵌入式VM，如V8，資源密集型
- 適應新語言到安全模型緩慢
- 仍然過於抽象
– 指令集體系結構（ISA）
- 難以有效沙箱
- 先前的Google 專案從其轉向WASM
- 缺乏成熟的實現
到了2018 年，WASM 開發獲得動力，重點是在各種架構、伺服器、嵌入式硬體上運行，甚至支援多種語言。與Java 不同，WASM 的設計沒有妥協安全性。到2019 年，引入了一個元件模型以提升WASM 模組，實現跨語言互通性。這允許了像一次編寫HTTP 庫並在多種語言中使用它這樣的解決方案。
至今，WASM 擁有一系列功能，並在雲端原生場景（包括區塊鏈）中越來越多地被採用。其優點包括：
- 高效能
- 緊湊的二進位大小
- 跨平台可攜帶性
- 支援多種語言，如C/C++、Rust、AssemblyScript 等
- 在JavaScript 引擎中執行
- 帶有記憶體和CPU 限制的強大沙箱
- 極快的啟動時間，通常在毫秒或更短時間內
WASM 社群繼續努力實現跨語言的更大整合和效能。
了解WASM 的歷史演變為我們提供了有價值的背景，用於了解其在各種設定（包括像Stylus 這樣的區塊鏈專案）中的當前和潛在角色。這項背景讓我們在探索有關WASM 在區塊鏈生態系統中實現的問題和疑慮時，具備了細緻的理解。
Stylus Q&A
語言支援
WASM 的發展歷程揭示了為什麼Stylus 是Arbitrum 生態系統的一個令人興奮的補充，但它也突顯了一些限制和疑慮。其中一個疑慮就是語言支援。雖然Stylus 確實擴大了Arbitrum 開發者社群以包含像C++ 和Rust 這樣的語言，但它在接納流行語言如JavaScript 和Python 方面還有所不足。
雖然有初步的專案旨在將Python 和JavaScript 帶到WASM，但由於垃圾收集和效能問題的挑戰，這些努力尚未準備好廣泛採用。
語言相容性
目前，Stylus 支援C/C++ 和Rust SDK，與這些語言的工具鏈無縫整合。開發者甚至可以在建立智慧合約時整合第三方函式庫，例如原生加密實作。做這樣的事的主要限制是相關的gas 費用。
雖然Rust SDK 還處於初級階段，Rust 和C SDK 都有一些缺失的功能。例如，C SDK 不支援ABI 匯出函數，而修飾符在兩個SDK 中都還未支援。
目前，沒有本機Stylus 測試環境，但開發者可以直接在SDK 內執行測試。對於部署智慧合約，目前只有測試網是唯一的選項，而且它還不支援智慧合約驗證。目前正在進行努力，以將各種ERC 代幣和**[Uniswap V2](https://twitter.com/evmcheb/status/1697537852522049990)** 引進Stylus 生態系。
語言選擇的困境
在領域特定語言（DSL）、嵌入式DSL（eDSL）和通用語言之間做選擇需要在低階控制和高階抽象之間權衡。開發全新的DSL 需要在工具鏈和生態系統開發上做出重大投資。與此相反，作為通用語言的子集，eDSL 允許更容易地與現有工具集成，並具有更低的學習曲線。例如，在像JavaScript 或Python 這樣的流行語言中建立eDSL 將是有益的。
通用語言需要使用SDK，這引入了額外的工具，增加了冗長性，並減少了程式碼的表達性，同時伴隨著更長的API 呼叫和物件操作。
在語言選擇和eDSL 開發之間找到正確的平衡可能是吸引更廣泛開發者社群的關鍵，同時提供使用者友善的工具。根據目前數據顯示，頂級加密開發者社群仍集中在以太坊周圍。然而，利用Rust 進行智慧合約的平台，如Polkadot、Cosmos 和Solana，也在獲得關注，並在其開發者社群中快速成長。
效能
WASM 顯著提高了執行速度並減少了套件大小。雖然Stylus 尚未在主網上部署，但其他網路的基準測試可以作為有用的參考。觀察到的執行時間快了4-8倍，編譯後的大小減少了約50%。
Stylus 目前對其合約設有大小限制，未壓縮時上限約為128KB。這項限制使得將大型智能合約從其他語言（如Solidity）移植過來變得具有挑戰性。在Stylus 程式碼庫中，此限制如下所述：
值得注意的是，WASM 在啟動和關閉時會產生一些開銷。對於輕量級操作，EVM 實際上可能比WASM 更具成本效益。
與EVM 的互通性
EVM 和WASM 共享相同的儲存槽和狀態樹，這有助於Stylus 與EVM 的互通性。這是透過在WASM 中實現的EVM API 來實現的，使用流行的Host I/O 模式。支援的EVM API 的全面清單表明互通性得到了全面支援。
自訂預編譯合約
這個方面特別令人興奮，因為它代表了未知的領域。自訂預編譯合約有潛力以更低的執行成本將額外的加密原語引入鏈上。它們還可以透過引入張量計算作為預編譯合約來降低推理成本。然而，目前似乎還沒有與自訂預編譯合約相關的現有程式碼。雖然EVM 組件存在預編譯合約，但它們不是熱插拔的。
這個功能可能仍在開發中，利用WASM 的能力。 EVM 可以呼叫用WASM 編寫的函數，然後將其編譯為機器碼。
可重入功能
與CosmWasm（採用沒有可重入功能的Actor 模型）相反，Stylus 的Rust SDK 預設關閉了可重入功能作為一個功能標誌。開發者有選擇手動啟用此功能的選項。
啟動可重入功能將需要進行一些API 調整。特別是在呼叫過程中刷新儲存快取等安全預防措施方面，開發者需要小心謹慎。
洞見
Stylus 開放了一些在僅使用EVM 時太耗費gas 的新用例，如高效能加密、遊戲和AI。它還允許自訂預編譯合約，使開發者可以添加自己的加密和其他基礎功能，而無需等待升級。在過去，我們看到一些非以太坊生態系統採用了WASM，如Cosmos 和Polkadot。這是以太坊社群首次採用WASM。總體而言，Stylus 代表了智慧合約開發的重大進化，將有助於以太坊和Arbitrum 實現擴容，同時與所有現有應用保持互通性。
將Stylus 整合到Arbitrum 的Layer2 SDK 可為第三層開發者提供更大的靈活性。他們現在可以將以前超過gas 限制的密集計算移到鏈上，從而打開新的可能性。開發者不再只限於使用Solidity，如果Rust 或C++ 更符合他們的需求和專長，也可以選擇這些語言。自訂預編譯合約允許無縫地將首選的加密、實用程式和其他助手函數遷移到鏈上以獲得最佳效能。以適應每個用例的語言直接編寫低階邏輯會導致更流暢的開發。開發者可以專注於核心產品功能，而不是為了避免gas 成本而採取權宜之計。透過消除語言和gas 限制，Stylus 讓第三層建構者能夠從一開始就使用適合其領域的正確工具，建立最高效的使用者體驗。
Stylus 也證明了Arbitrum 有能力進行大規模革新，並且整合新的虛擬機器。 Ed Felten, Co-founder & Chief Scientist of Arbitrum & Offchain Labs 提到Arbitrum 是基於業界熱門工具和程式語言開發。他們可以更迅速地編寫測試以及在原始系統之上開發新功能。 OP 在ZK 化的道路上走的更遠，已經逐漸走向了混合Rollup 的思路。 Optimism 目前和Risc0 合作，使用Zeth 為OPRU 產生零知識證明。使用這套解決方案，Optimism 並不會對OPRU 進行額外的修改。如果你對Zeth 有興趣，可以看我之前寫的[推特](https://x.com/glazecl/status/1709947992168710174?s=20)。
我們非常期待在Arbitrum 上看到AI 應用。目前，在鏈上進行機器學習非常耗費gas，使得開發成本高。零知識ML 可以降低成本，但也會為開發者帶來顯著的額外複雜性。如果我們能透過Stylus 實現張量操作作為自訂預編譯合約，並以一小部分的成本原生執行它們，那麼就會為高性能的在鏈上機器學習打開新的可能性。透過讓開發者用他們熟悉的語言（如Python）快速建構和部署ML 演算法作為易於整合的預編譯合約，Arbitrum 可以推動DeFi、GameFi 等領域的下一代AI 創新。 Stylus 的效能和靈活性將使我們能夠專注於創新的ML 架構，而不是gas 優化。我們期待看到社群的創造力應用於這個新興範式。
