Original author: Yiping, IOSG Ventures

The Layer 2 landscape is rapidly evolving as ZKRUs like zkSync and StarkNet launch mainnet. Traditionally, OPRUs like Arbitrum are the first to market and therefore have a stronger ecosystem. In contrast, ZKRUs are technological breakthroughs that offer higher throughput and lower fees.

In recent months, more activity has migrated from Layer 1 to Layer 2 in search of faster and cheaper transactions. Ethereum’s TVL has dropped from nearly $40 billion to $20 billion over the past year. However, Layer 2 TVL presents a different picture, with huge growth indicating that Layer 2 adoption is accelerating.

Arbitrum leads the way with over 50% Layer 2 TVL market share, although ZKRUs also put in their efforts. Arbitrums first-mover advantage allows it to maintain its dominant position.

Analyzing the number of daily transactions shows that ZKRUs like zkSync and StarkNet slightly exceed OPRUs in throughput. However, Arbitrum’s ecosystem advantage remains, despite falling slightly behind in daily TPS.

OPRUs have been around longer than ZKRUs. However, ZKRUs are launching their mainnets and attracting users from other ecosystems. As a leader in the OPRU space, Arbitrum is expected to counter the rise of ZKRUs with their new updates.

Arbitrum：Stylus

As developers optimize zero-knowledge technology and cost, ZKRUs will likely continue to gain market share due to their scalability advantages. However, Arbitrums network effects provide the ability to remain robust despite competitive pressures. Through innovative solutions like Stylus, Arbitrum can complement its leadership position with unique technical capabilities and continue to stay at the forefront of the Layer 2 race.

In short, Stylus is a revolutionary new smart contract environment designed for Arbitrum that allows developers to write efficient, interoperable programs in programming languages ​​​​like Rust, C++ and Solidity.

It opens general computing to blockchain and welcomes developers using different technology 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 a language that compiles to WASM can execute natively 10 times or more faster than Solidity, significantly reducing gas costs. The EVM remains fully functional, so existing Solidity contracts continue to function as they do today. The two VMs operate synchronously, allowing contracts written in different programming languages ​​to call each other while also modifying the same underlying blockchain state.

Custom precompilation

In addition, Stylus also supports custom precompiles.

Precompilation is a low-level module on Ethereum and Arbitrum used to perform specific cryptographic or utility functions very efficiently. For example, there are precompilations for ECDSA signature verification and calculation of SHA 256 hashes.

Adding new precompilations requires all validators to coordinate upgrading the EVM, so the threshold is high. With Stylus, developers can easily deploy their own precompilers written in Rust or C++.

For example, a team can take a cryptographic library written in C and deploy it to Arbitrum without modification. This will allow these cryptographic primitives to execute at ultra-fast native speeds.

Other contracts can call this Stylus precompilation just like they call native precompilation to take advantage of the encryption technology. All gas metering and fraud proofing work automatically.

This allows the team to prototype custom cryptography, special pairing-based curves, and other novel primitives without any special chain support. Ethereum researchers can even iterate on EIP proposals early by deploying them as Stylus precompiled versions on Arbitrum.

By giving developers the ability to introduce new cryptographic primitives natively on-chain, Stylus greatly expands the scope of what can be built. Precompilation is no longer limited to features supported by the EVM.

How Stylus works

Before delving into WASMs broader role in the blockchain universe, its crucial to understand how Arbitrum orchestrates the coexistence of EVM and WASM. Its not just about having two separate engines; its a synergistic relationship that enhances the strengths of both.

Arbitrums unique architecture allows seamless and synchronized operation between EVM and WASM, thanks to its unified state, cross-VM invocation and compatible economic model.

Smart contracts written in Solidity or other EVM languages ​​are compiled into EVM bytecode as usual. When executed, these contracts run on the EVM, just like 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, such as Clang or Rustc, to compile their smart contracts into WASM.

• WASM bytecode is uploaded to the Arbitrum chain in compressed form.

• The contract owner calls the `ArbWasm` precompiled `compileProgram` method, which sets up the security tooling for WASM, gas costs it, and compiles it into native code optimized for the validator hardware.

• When the contract is called, it runs on a WASM runtime like Wasmer, which is much faster than EVM, thus saving gas fees.

WASM metering charges Gas before each basic block rather than per opcode like EVM. This is more efficient and ensures that the contract does not get out of hand.

EVM and WASM

The two virtual machines (VMs) run synchronously, allowing them to call each other while sharing the same global state. A transaction may be executed partially in EVM and partially in WASM, and the results are combined seamlessly.

Wait, how can two VMs work seamlessly and in sync?

Polkadot achieves this through XVM. Unlike Polkadot, WASM and EVM work seamlessly and synchronously on Arbitrum for several key reasons:

• Single state: Both VMs access the same underlying data structure and state trie. A contract in one VM can read/write to the same location as a contract in another VM. This provides a unified view of the chain status.

• Cross-VM calls: When a transaction interacts with an EVM contract, Geth processes it and provides a result. If the EVM contract subsequently calls a WASM program, the WASM VM takes over to calculate the results of that part.

• Shared context: System information like block data, sender address, etc. are available to both VMs. A WASM contract can obtain the block number just like a Solidity contract.

• Single Consensus: Validators run two VMs to validate transactions and reach consensus on the correct chain state. Disputes will invoke the Uniform Fraud Proof System.

• Compatible economics: Concepts like gas metering extend to individual VMs, ensuring appropriate compute costs and resources in either environment.

For fraud proofs, the verifier bisects the EVM and WASM executions to identify any invalid steps if necessary. WASMs structure allows the system to guarantee termination and enforce the validity of proofs.

Blockchain - WASM

Arbitrum isnt the only platform to recognize the transformative potential of WebAssembly (WASM). Both Polkadot and Cosmos have also integrated WASM into their ecosystems, with each platform offering a unique set of benefits and features.

Polkadot allows users to develop smart contracts using WASM and supports two languages: AssemblyScript, an embedded DSL, and Ink!, which is similar to 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 is so accepting of WASM, it is necessary to understand the specific advantages that Cosmos and Polkadot stand out:

Cosmos highlights the following advantages of WASM:

• Compatibility with Rust libraries

• Diverse developer community

• Enhanced security, including protection against reentrancy attacks

• Easy to test

• high performance

Polkadot’s WASM runtime has these features:

• high performance

• Interoperability with EVM

• Platform agnostic

• Compact binary size

• Supports both Rust and AssemblyScript (TypeScript style)

While Polkadot, Cosmos, and Arbitrum share some common benefits provided by WASM, each platform also has its own unique attributes.

The widespread adoption of WASM by these major blockchain platforms demonstrates its growing importance in the industry, making it critical to understand why this technology is quickly becoming a cornerstone of modern blockchain architecture.

Why choose WASM

What is WASM

In order to understand the synergy between blockchain and WebAssembly (WASM), one must first understand what WASM is and the driving force behind its development.

WebAssembly is a binary instruction format that enables code to execute at near-native speed within a web browser. It serves as a compilation target for a range of programming languages, including C and Rust, and is designed to be fast, efficient, and safe. WASM effectively bridges the gap between Web-based and system-level programming, thereby improving Web performance and functionality.

Web in WebAssembly highlights its ability to run in a JavaScript environment (usually found in the browser). In these settings, developers have full access to the WASM API and have comprehensive Web API support, giving them considerable control over Web behavior.

WASM History

Following the principle of write once, run anywhere, WASM emerged as a powerful solution to a long-standing set of challenges. As of 2016, many programs introduce new functionality through domain-specific languages ​​(DSLs), which often involves trade-offs between maintenance, efficiency, and security. There is a growing need for a solution that can provide new functionality to countless servers without compromising these aspects.

The shortcomings of various existing solutions were assessed:

- System virtual machine

• Frequent startup and shutdown brings excessive overhead

• Lack of code visibility to ensure security

• Too abstract about performance requirements

- container

• Lack of code visibility to ensure security

• Inefficient due to high-level abstraction

• Frequent operations bring significant overhead

- Language-level virtual machine

• Requires frequent modifications to ensure safety

• Embedded VMs, like V8, are resource intensive

• Slow adaptation of new language to security model

• still too abstract

- Instruction Set Architecture (ISA)

• Difficult to effectively sandbox

• Previous Google projects moved from it to WASM

• Lack of mature implementation

By 2018, WASM development gained momentum with a focus on running on various architectures, servers, embedded hardware, and even supporting multiple languages. Unlike Java, WASM is designed without compromising security. By 2019, a component model was introduced to enhance the WASM module and enable cross-language interoperability. This allows solutions like writing an HTTP library once and using it in multiple languages.

To date, WASM has a range of capabilities and is increasingly being adopted in cloud-native scenarios, including blockchain. Its advantages include:

• high performance

• Compact binary size

• Cross-platform portability

• Supports multiple languages, such as C/C++, Rust, AssemblyScript, etc.

• Executed in JavaScript engine

• Powerful sandbox with memory and CPU limits

• Extremely fast startup times, typically in milliseconds or less

The WASM community continues to work toward greater integration and performance across languages.

Understanding the historical evolution of WASM provides us with valuable context for understanding its current and potential roles in various settings, including blockchain projects like Stylus. This background gives us a nuanced understanding when exploring issues and concerns surrounding WASM implementation in the blockchain ecosystem.

Stylus Q&A

language support

WASMs evolution reveals why Stylus is an exciting addition to the Arbitrum ecosystem, but it also highlights some limitations and concerns. One of the concerns is language support. While Stylus has certainly expanded the Arbitrum developer community to include languages ​​like C++ and Rust, it falls short in embracing popular languages ​​like JavaScript and Python.

While there are preliminary projects aimed at bringing Python and JavaScript to WASM, these efforts are not yet ready for widespread adoption due to challenges with garbage collection and performance issues.

Language compatibility

Currently, Stylus supports C/C++ and Rust SDK, seamlessly integrating with the tool chains of these languages. Developers can even integrate third-party libraries, such as native cryptographic implementations, when building smart contracts. The main limitation of doing something like this is the associated gas cost.

Although the Rust SDK is still in its infancy, both the Rust and C SDKs have some missing 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 local Stylus testing environment, but developers can run tests directly within the SDK. For deploying smart contracts, testnet is currently the only option, and it does not yet support smart contract verification. Efforts are currently underway to bring various ERC tokens and **[Uniswap V2](https://twitter.com/evmcheb/status/1697537852522049990)** into the Stylus ecosystem.

The dilemma of language choice

Choosing between domain-specific languages ​​(DSLs), embedded DSLs (eDSLs), and general-purpose languages ​​requires a trade-off between low-level control and high-level abstraction. Developing a new DSL requires significant investment in toolchain and ecosystem development. In contrast, as a subset of a general-purpose language, eDSL allows easier integration with existing tools and has a lower learning curve. For example, it would be beneficial to create an eDSL in a popular language like JavaScript or Python.

A common language requires the use of an SDK, which introduces additional tooling, increases verbosity, and makes the code less expressive, along with longer API calls and object operations.

Finding the right balance between language choice and eDSL development may be the key to attracting the wider developer community while providing user-friendly tools. According to current data, the top crypto developer community is still concentrated around Ethereum. However, platforms that leverage Rust for smart contracts, such as Polkadot, Cosmos, and Solana, are also gaining traction and growing rapidly among their developer communities.

performance

WASM significantly improves execution speed and reduces packet size. Although Stylus has not yet been deployed on mainnet, benchmarks from other networks can serve as a useful reference. Observed execution times are 4-8 times faster and the compiled size is reduced by approximately 50%.

Stylus currently has a size limit on its contracts, with an upper limit of approximately 128 KB uncompressed. This limitation makes porting large smart contracts from other languages ​​such as Solidity challenging. In the Stylus code base, this limit is described below:

Its worth noting that WASM incurs some overhead when starting up and shutting down. For lightweight operations, EVM may actually be more cost-effective than WASM.

Interoperability with EVM

EVM and WASM share the same storage slots and state trees, which facilitates Stylus interoperability with EVM. This is achieved through the EVM API implemented in WASM, using the popular Host I/O pattern. A comprehensive list of supported EVM APIs demonstrates that interoperability is fully supported.

Custom precompiled contract

This aspect is particularly exciting because it represents uncharted territory. Custom precompiled contracts have the potential to bring additional cryptographic primitives on-chain with lower execution costs. They can also reduce the cost of inference by introducing tensor computations as precompiled contracts. However, there appears to be no existing code related to custom precompiled contracts. Although precompiled contracts exist for EVM components, they are not hot-swappable.

This feature may still be under development, taking advantage of WASMs capabilities. The EVM can call functions written in WASM and then compile them into machine code.

Reentrant functionality

In contrast to CosmWasm (which uses an Actor model without reentrancy), Stylus Rust SDK turns off reentrancy as a feature flag by default. Developers have the option to enable this feature manually.

Activating reentrant functionality will require some API adjustments. In particular, developers need to be careful when it comes to security precautions such as refreshing storage caches during calls.

Insight

Stylus opens up new use cases that would be too gas-intensive when using only the EVM, such as high-performance encryption, gaming, and AI. It also allows for customizing precompiled contracts, allowing developers to add their own encryption and other basic functionality without waiting for upgrades. In the past, we have seen some non-Ethereum ecosystems adopt WASM, such as Cosmos and Polkadot. This is the first time WASM has been adopted by the Ethereum community. Overall, Stylus represents a significant evolution in smart contract development and will help Ethereum and Arbitrum scale while maintaining interoperability with all existing applications.

Integrating Stylus into Arbitrums Layer 2 SDK provides greater flexibility for Layer 3 developers. They can now move intensive computations that previously exceeded gas limits onto the chain, opening up new possibilities. Developers are no longer limited to Solidity but can also choose Rust or C++ if those languages ​​better suit their needs and expertise. Custom precompiled contracts allow for seamless migration of preferred cryptographic, utility and other helper functions onto the chain for optimal performance. Writing low-level logic directly in a language adapted to each use case leads to smoother development. Developers can focus on core product features rather than taking quick fixes to avoid gas costs. By removing language and gas constraints, Stylus enables third-tier builders to build the most efficient user experiences from the start, using the right tools for their domain.

Stylus also demonstrates Arbitrums ability to innovate at scale and integrate new virtual machines. Ed Felten, Co-founder Chief Scientist of Arbitrum Offchain Labs mentioned that Arbitrum is developed based on popular tools and programming languages ​​in the industry. They can write tests more quickly and develop new features on top of legacy systems. OP has gone further on the road of ZKization and has gradually moved towards the hybrid Rollup idea. Optimism is currently working with Risc 0 to use Zeth to generate zero-knowledge proofs for OPRU. Using this solution, Optimism does not need to make additional modifications to OPRU. If you are interested in Zeth, you can read what I wrote before [Twitter](https://x.com/glazecl/status/1709947992168710174? s= 20).

We are very much looking forward to seeing AI applications on Arbitrum. Currently, performing machine learning on the chain is very gas-intensive, making development costs high. Zero-knowledge ML can reduce costs, but also introduces significant additional complexity for developers. If we could implement tensor operations as custom precompiled contracts through Stylus and execute them natively at a fraction of the cost, it would open up new possibilities for high-performance on-chain machine learning. By allowing developers to quickly build and deploy ML algorithms as easy-to-integrate precompiled contracts in a language they are familiar with (such as Python), Arbitrum can drive the next generation of AI innovation in DeFi, GameFi, and more. Stylus performance and flexibility will allow us to focus on innovative ML architectures rather than gas optimization. We look forward to seeing the creativity of the community applied to this emerging paradigm.