Why is Arbitrum Stylus considered the most important technological innovation for L2s this year?
TechFlow Selected TechFlow Selected
Why is Arbitrum Stylus considered the most important technological innovation for L2s this year?
Integrating Stylus into Arbitrum's Layer 2 SDK can provide greater flexibility for third-layer developers.
Navigating Web3 tides with focused insightsAuthor: Yiping, IOSG Ventures
With the mainnet launches of ZKRUs like zkSync and StarkNet, the Layer2 landscape is rapidly evolving. Traditionally, OPRUs such as Arbitrum entered the market first and thus built stronger ecosystems. In contrast, ZKRUs offer technical breakthroughs with higher throughput and lower fees.
In recent months, more activity has shifted from Layer1 to Layer2 in pursuit of faster and cheaper transactions. Ethereum's TVL has declined from nearly $40 billion to $20 billion over the past year. However, Layer2 TVL presents a different picture, with substantial growth indicating accelerating adoption of Layer2 solutions.
Arbitrum leads with over 50% of the Layer2 TVL market share, despite efforts by ZKRUs. Arbitrum’s first-mover advantage has allowed it to maintain dominance.
Analyzing daily transaction counts shows that ZKRUs like zkSync and StarkNet slightly outperform OPRUs in throughput. Nevertheless, Arbitrum retains its ecosystem advantage, even if slightly behind in daily TPS.
OPRUs have existed longer than ZKRUs. However, ZKRUs are now launching their mainnets and attracting users from other ecosystems. As the leader in the OPRU space, Arbitrum is expected to counter the rise of ZKRUs through new updates.
Arbitrum: Stylus
As developers optimize zero-knowledge technologies and costs, ZKRUs may continue gaining market share due to their scalability advantages. However, Arbitrum’s network effects provide resilience against competitive pressure. With innovative solutions like Stylus, Arbitrum can complement its leadership with unique technical capabilities and remain ahead in the Layer2 race.
In short, Stylus is a revolutionary new smart contract environment designed for Arbitrum, enabling developers to write efficient, interoperable programs using programming languages such as Rust, C++, and Solidity.
It opens up general-purpose computing on blockchains and welcomes developers using diverse tech stacks.
WASM
Stylus works by adding a WebAssembly (WASM) virtual machine that runs in parallel with the existing Ethereum Virtual Machine (EVM). Smart contracts written in languages that can compile to WASM execute natively up to 10x faster or more than Solidity, significantly reducing gas fees. The EVM remains fully functional, so existing Solidity contracts continue to operate as they do today. Both VMs operate synchronously, allowing contracts written in different programming languages to call each other while modifying the same underlying blockchain state.
Custom Precompiles
Additionally, Stylus also supports custom precompiles.
Precompiles are low-level modules on Ethereum and Arbitrum used to efficiently execute specific cryptographic or utility functions. For example, there are precompiles for ECDSA signature verification and SHA256 hash computation.
Adding new precompiles requires coordinated upgrades across all validators on the EVM, creating a high barrier. With Stylus, however, developers can easily deploy their own precompiles written in Rust or C++.
For instance, a team could use a cryptography library written in C and deploy it unmodified onto Arbitrum. This would allow those cryptographic primitives to execute at ultra-fast native speeds.
Other contracts can invoke this Stylus "precompile" just like native precompiles to leverage the cryptographic functionality. All gas metering and fraud proofs work automatically.
This enables teams to prototype custom cryptography, special pairing-based curves, and other novel primitives without requiring special chain support. Ethereum researchers could even iterate on EIP proposals by deploying them as Stylus precompiles on Arbitrum.
By empowering developers to natively introduce new cryptographic primitives on-chain, Stylus greatly expands the range of what can be built. Precompiles are no longer limited to functionalities supported by the EVM.
How Stylus Works
Before diving into the broader role of WASM in the blockchain universe, it is crucial to understand how Arbitrum orchestrates the coexistence of EVM and WASM. This isn't merely about having two separate engines—it's a synergistic relationship that enhances the strengths of both.
Arbitrum’s unique architecture enables seamless and synchronous operations between EVM and WASM, thanks to its unified state, cross-VM calls, and compatible economic model.
Smart contracts written in Solidity or other EVM languages compile as usual into EVM bytecode. When executed, these contracts run on the EVM exactly as they do today.
For languages that compile to WASM—such as Rust, C++, and C—the workflow is:
-
Developers use off-the-shelf WASM compilers like Clang or Rustc to compile their smart contracts into WASM.
-
The WASM bytecode is uploaded to the Arbitrum chain in compressed form.
-
The contract owner invokes the `compileProgram` method of the `ArbWasm` precompile, which performs safety instrumentation, gas cost metering, and compiles the code into native code optimized for validator hardware.
-
When called, the contract runs on a WASM runtime like Wasmer, much faster than the EVM, saving gas fees.
WASM metering charges gas before each basic block, rather than per opcode like the EVM. This is more efficient and ensures contracts cannot run away.
EVM vs WASM
These two virtual machines (VMs) run synchronously, allowing them to call each other while sharing the same global state. A single transaction might partially execute in the EVM and partially in WASM, with results seamlessly combined.
Wait—how can two VMs work seamlessly and synchronously?
Polkadot achieves this via XVM. Unlike Polkadot, WASM and EVM can work seamlessly and synchronously on Arbitrum for several key reasons:
-
Single State: Both VMs access the same underlying data structures and state trie. Contracts in one VM can read/write to the same locations as contracts in the other VM, providing a unified view of chain state.
-
Cross-VM Calls: When a transaction interacts with an EVM contract, Geth handles it and returns a result. If the EVM contract then calls a WASM program, the WASM VM takes over to compute that segment.
-
Shared Context: System information such as block data and sender address is available to both VMs. A WASM contract can retrieve the block number just like a Solidity contract.
-
Single Consensus: Validators run both VMs to validate transactions and reach consensus on the correct chain state. Disputes will invoke the unified fraud proof system.
-
Compatible Economics: Concepts like gas metering extend across VMs, ensuring proper computational costs and resource usage in either environment.
For fraud proofs, validators perform bisection in both EVM and WASM execution to identify any invalid steps when necessary. WASM's structure allows the system to guarantee termination and enforce proof validity.
Blockchain | WASM
Arbitrum is not the only platform recognizing the transformative potential of WebAssembly (WASM). Polkadot and Cosmos have also integrated WASM into their ecosystems, each offering a unique set of advantages and features.
Polkadot allows users to develop smart contracts with WASM and supports two languages: AssemblyScript, an embedded DSL, and Ink!, which resembles Rust.
Cosmos, on the other hand, uses CosmWasm as its smart contract runtime, allowing developers to write contracts in Rust.
Before delving into why the blockchain industry has embraced WASM so widely, it's worth examining the specific advantages highlighted by Cosmos and Polkadot:
Cosmos emphasizes the following advantages of WASM:
-
Compatibility with Rust libraries
-
Diverse developer communities
-
Enhanced security, including protection against reentrancy attacks
-
Ease of testing
-
High performance
Polkadot’s WASM runtime offers these characteristics:
-
High performance
-
Interoperability with EVM
-
Platform agnosticism
-
Compact binary size
-
Support for both Rust and AssemblyScript (TypeScript-style)
While Polkadot, Cosmos, and Arbitrum share some common advantages offered by WASM, each platform also has its own unique properties.
The widespread adoption of WASM across these major blockchain platforms underscores its growing importance in the industry, making it critical to understand why this technology is rapidly becoming a cornerstone of modern blockchain architecture.
Why WASM
What is WASM
To understand the synergy between blockchain and WebAssembly (WASM), we must first grasp what WASM is and the driving forces behind its development.
WebAssembly is a binary instruction format that enables code to execute at near-native speed within web browsers. It serves as a compilation target for a range of programming languages, including C and Rust, aiming to be fast, efficient, and secure. WASM effectively bridges the gap between web-based and system-level programming, enhancing web performance and functionality.
The “Web” in WebAssembly highlights its ability to run in JavaScript environments, typically within browsers. In these settings, developers have full access to WASM APIs and comprehensive Web API support, giving them significant control over web behavior.
WASM History
Following the principle of “write once, run anywhere,” WASM emerged as a powerful solution to a set of long-standing challenges. By 2016, many programs introduced new features via domain-specific languages (DSLs), often involving trade-offs between maintenance, efficiency, and security. There was a growing need for a solution that could deliver new functionality to countless servers without compromising on these aspects.
Existing solutions were evaluated and found lacking:
- System Virtual Machines
-
Excessive overhead from frequent startup and shutdown
-
Lack of code visibility for security assurance
-
Too abstracted for performance demands
- Containers
-
Lack of code visibility for security assurance
-
Inefficient due to high-level abstractions
-
Significant overhead from frequent operations
- Language-Level Virtual Machines
-
Frequent modifications required for security
-
Embedded VMs like V8 are resource-intensive
-
Slow adaptation of new languages into secure models
-
Still too abstracted
- Instruction Set Architecture (ISA)
-
Difficult to sandbox effectively
-
Previous Google projects transitioned to WASM
-
Lack of mature implementations
By 2018, WASM development gained momentum, focusing on running across various architectures, servers, and embedded hardware, while supporting multiple languages. Unlike Java, WASM was designed without compromising security. By 2019, a component model was introduced to enhance WASM modules, enabling cross-language interoperability. This allowed solutions such as writing an HTTP library once and using it across multiple languages.
Today, WASM boasts a wide array of features and is increasingly adopted in cloud-native scenarios, including blockchain. Its advantages include:
-
High performance
-
Compact binary size
-
Cross-platform portability
-
Support for multiple languages such as C/C++, Rust, AssemblyScript, etc.
-
Execution within JavaScript engines
-
Strong sandboxing with memory and CPU limits
-
Extremely fast startup times, typically in milliseconds or less
The WASM community continues to push for greater integration and performance across languages.
Understanding WASM’s historical evolution provides valuable context for its current and potential roles in various settings, including blockchain projects like Stylus. This background equips us with nuanced understanding as we explore issues and concerns regarding WASM’s implementation in the blockchain ecosystem.
Stylus Q&A
Language Support
WASM’s developmental journey explains why Stylus is an exciting addition to the Arbitrum ecosystem, but it also highlights certain limitations and concerns. One such concern is language support. While Stylus does expand the Arbitrum developer community to include languages like C++ and Rust, it still falls short in embracing popular languages such as JavaScript and Python.
Although preliminary projects aim to bring Python and JavaScript to WASM, these efforts are not yet ready for broad adoption due to challenges related to garbage collection and performance.
Language Compatibility
Currently, Stylus supports C/C++ and Rust SDKs, integrating seamlessly with their toolchains. Developers can even incorporate third-party libraries, such as native cryptographic implementations, when building smart contracts. The main limitation here is the associated gas cost.
While the Rust SDK is still in early stages, both the Rust and C SDKs lack certain features. For example, the C SDK does not support ABI-exported functions, and modifiers are not yet supported in either SDK.
Currently, there is no native Stylus test environment, though developers can run tests directly within the SDK. For deploying smart contracts, only testnets are currently available, and contract verification is not yet supported. Efforts are underway to bring various ERC tokens and **[Uniswap V2]** into the Stylus ecosystem.
The Dilemma of Language Choice
Choosing between domain-specific languages (DSLs), embedded DSLs (eDSLs), and general-purpose languages involves trade-offs between low-level control and high-level abstraction. Developing a completely new DSL requires significant investment in toolchain and ecosystem development. In contrast, eDSLs—being subsets of general-purpose languages—allow easier integration with existing tools and have a lower learning curve. For example, creating an eDSL within popular languages like JavaScript or Python would be beneficial.
General-purpose languages require SDKs, which introduce additional tooling, increase verbosity, reduce code expressiveness, and involve longer API calls and object manipulations.
Finding the right balance between language choice and eDSL development could be key to attracting a broader developer community while providing user-friendly tools. Current data shows that top crypto developer communities remain centered around Ethereum. However, platforms leveraging Rust for smart contracts—such as Polkadot, Cosmos, and Solana—are gaining attention and experiencing rapid growth in their developer bases.
Performance
WASM significantly improves execution speed and reduces package size. While Stylus has not yet been deployed on mainnet, benchmarking from other networks can serve as useful references. Execution times observed are 4–8 times faster, with compiled sizes reduced by approximately 50%.
Stylus currently imposes size limits on its contracts, with an uncompressed upper limit of approximately 128KB. This restriction makes porting large smart contracts from other languages (like Solidity) challenging. Within the Stylus codebase, this limit is defined as follows:
Notably, WASM incurs some overhead during startup and shutdown. For lightweight operations, the EVM may actually be more cost-effective than WASM.
Interoperability with EVM
EVM and WASM share the same storage slots and state tree, facilitating Stylus’ interoperability with EVM. This is achieved through EVM APIs implemented in WASM, using the popular Host I/O pattern. A comprehensive list of supported EVM APIs indicates full interoperability support.
Custom Precompiled Contracts
This aspect is particularly exciting, as it represents uncharted territory. Custom precompiled contracts have the potential to introduce additional cryptographic primitives on-chain at lower execution costs. They could also reduce inference costs by introducing tensor computation as a precompiled contract. However, there currently appears to be no existing code related to custom precompiled contracts. While precompiles exist in EVM components, they are not hot-swappable.
This feature may still be under development, leveraging WASM’s capabilities. The EVM can invoke functions written in WASM, which are then compiled into machine code.
Reentrancy Features
In contrast to CosmWasm—which adopts an Actor model without reentrancy—Stylus' Rust SDK disables reentrancy by default as a feature flag. Developers have the option to manually enable this functionality.
Enabling reentrancy will require some API adjustments. Developers must exercise caution, particularly around security measures such as flushing storage caches during calls.
Insights
Stylus unlocks new use cases that were previously too gas-intensive under EVM-only environments, such as high-performance cryptography, gaming, and AI. It also enables custom precompiled contracts, allowing developers to add their own cryptographic and foundational features without waiting for upgrades. Previously, we saw non-Ethereum ecosystems like Cosmos and Polkadot adopt WASM. This marks the Ethereum community’s first major embrace of WASM. Overall, Stylus represents a significant evolution in smart contract development, helping Ethereum and Arbitrum scale while maintaining interoperability with all existing applications.
Integrating Stylus into Arbitrum’s Layer2 SDK provides greater flexibility for Layer3 developers. They can now move intensive computations previously exceeding gas limits onto-chain, opening new possibilities. Developers are no longer restricted to Solidity—they can choose Rust or C++ if better suited to their needs and expertise. Custom precompiled contracts allow seamless migration of preferred cryptographic, utility, and helper functions onto-chain for optimal performance. Writing low-level logic directly in the most appropriate language for each use case leads to smoother development. Developers can focus on core product features instead of resorting to workarounds to avoid gas costs. By removing language and gas constraints, Stylus empowers Layer3 builders to use the right tools from the start and deliver the most efficient user experiences.
Stylus also demonstrates Arbitrum’s capacity for large-scale innovation and integration of new virtual machines. Ed Felten, Co-founder & Chief Scientist of Arbitrum & Offchain Labs, mentioned that Arbitrum builds upon industry-standard tools and programming languages, enabling faster test writing and quicker development of new features atop existing systems. OP is advancing further down the ZK path, gradually moving toward hybrid rollup approaches. Optimism is currently collaborating with Risc0, using Zeth to generate zero-knowledge proofs for OPRUs. This solution requires no additional modifications to the OPRU. If you’re interested in Zeth, check out my previous [tweet].
We are highly excited to see AI applications emerge on Arbitrum. Currently, on-chain machine learning is extremely gas-intensive, making development costly. Zero-knowledge ML can reduce costs but introduces significant complexity for developers. If we can implement tensor operations via Stylus as custom precompiled contracts and execute them natively at a fraction of the cost, this would unlock new possibilities for high-performance on-chain machine learning. By enabling developers to quickly build and deploy ML algorithms in familiar languages like Python as easily integrable precompiled contracts, Arbitrum could drive next-generation AI innovation in DeFi, GameFi, and beyond. Stylus’ performance and flexibility will allow us to focus on innovative ML architectures rather than gas optimization. We look forward to seeing the community’s creativity applied to this emerging paradigm.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
IOSG Ventures
