將Stylus集成到Arbitrum的Layer2 SDK可為第三層開發者提供更大的靈活性。

作者：Yiping，IOSG Ventures

隨著像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合約仍然如同今天一樣正常運行。 兩個VMs同步操作，允許用不同程式設計語言編寫的合約相互調用，同時還能修改相同的底層區塊鏈狀態。

自定義預編譯

此外，Stylus也支持自定義預編譯（Precompiles）。

預編譯是Ethereum和Arbitrum上用於非常高效地執行特定加密或實用函數的底層模塊。 例如，有用於ECDSA簽名驗證和計算SHA256雜湊的預編譯。

要添加新的預編譯需要所有驗證者協調陞級EVM，囙此門檻很高。 而使用Stylus，開發者可以輕鬆地部署他們自己用Rust或C++編寫的預編譯。

例如，一個團隊可以使用用C語言編寫的加密庫，並未經修改地將其部署到Arbitrum。 這將允許這些加密原語以超快的本地速度執行。

其他合約可以調用這個Stylus &ldquo； 預編譯&rdquo；， 就像它們調用原生預編譯一樣，來利用該加密技術。 所有的燃氣計量和欺詐證明都會自動工作。

這使得團隊能够在沒有任何特殊鏈支持的情况下，原型自定義加密、特殊的基於配對的曲線和其他新型原語。 乙太坊研究者甚至可以通過在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的結構允許系統保證終止並強制證明的有效性。

區塊鏈&nbsp；|& nbsp； 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效能和功能。

&ldquo； Web&rdquo； 在WebAssembly中突出了其在JavaScript環境（通常在瀏覽器中找到）中運行的能力。 在這些設定中，開發者可以完全訪問WASM API，並且具有全面的Web API支持，賦予他們相當大的控制Web行為的能力。

WASM歷史

遵循&ldquo； 一次編寫，到處運行&rdquo； 的原則，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&amp； 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]
**引入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 &amp； Chief Scientist of Arbitrum &amp； Offchain Labs提到Arbitrum基於業界熱門工具和程式設計語言開發。 他們可以更加迅速地編寫測試以及在原用系統之上開發新功能。 OP在ZK化的道路上走的更遠，已經逐漸走向了混合Rollup的思路。 Optimism現時和Risc0合作，使用Zeth為OPRU生成零知識證明。 使用這套解決方案，Optimism並不用對OPRU進行額外的修改。 如果你對Zeth感興趣，可以看我之前寫的
[推特]
。

我們非常期待在Arbitrum上看到AI應用。 現時，在鏈上進行機器學習非常耗費gas，使得開發成本高昂。 零知識ML可以降低成本，但也會為開發者帶來顯著的額外複雜性。 如果我們能通過Stylus實現張量操作作為自定義預編譯合約，並以一小部分的成本原生執行它們，那麼就會為高性能的在鏈上機器學習打開新的可能性。 通過讓開發者用他們熟悉的語言（如Python）快速構建和部署ML算灋作為易於集成的預編譯合約，Arbitrum可以推動DeFi、GameFi等領域的下一代AI創新。 Stylus的效能和靈活性將使我們能够專注於創新的ML架構，而不是gas優化。 我們期待看到社區的創造力應用於這一新興範式。