Author: Yiping, IOSG Ventures
The Layer 2 landscape is rapidly evolving as ZKRUs like zkSync and StarkNet launch mainnet. Traditionally, OPRUs like Arbitrum are 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 activities have 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's TVL presents a different picture, with huge growth indicating that Layer 2 adoption is accelerating.
Arbitrum leads with over 50% of Layer2 TVL market share, despite the efforts of ZKRUs. Arbitrum’s first-mover advantage enables it to maintain its dominance.
Analyzing the number of daily transactions shows that ZKRUs like zkSync and StarkNet slightly outperform OPRUs in throughput. However, Arbitrum’s ecosystem advantage remains, despite lagging 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 combat the rise of ZKRUs with their new update.
Decision: Style
As developers optimize zero-knowledge technology and costs, ZKRUs will likely continue to gain market share due to their scalability advantages. However, Arbitrum's network effects provide the ability to remain robust despite competitive pressures. Through innovative solutions like Stylus, Arbitrum can complement its leadership with unique technical capabilities and continue to stay ahead in 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 languages that compile to WASM can be executed natively at speeds 10x or more faster than Solidity, drastically reducing gas fees. The EVM remains fully functional, so existing Solidity contracts continue to run just as they do today. The two VMs operate in sync, allowing contracts written in different programming languages to call each other while modifying the same underlying blockchain state.
Custom precompilation
In addition, Stylus also supports custom precompiles.
Precompiles are low-level modules used on Ethereum and Arbitrum to perform specific cryptographic or utility functions very efficiently. For example, there are precompiles for ECDSA signature verification and calculating SHA256 hashes.
Adding new precompilations requires all validators to coordinate an EVM upgrade, so the barrier to entry is high. With Stylus, developers can easily deploy their own precompilations written in Rust or C++.
For example, a team could use a cryptographic library written in C and deploy it to Arbitrum without modification. This would allow these cryptographic primitives to execute at ultra-fast native speeds.
Other contracts can call this Stylus "precompile" just like they would a native precompile to take advantage of the cryptography. All the gas metering and fraud proofs will work automatically.
This enables teams 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 by deploying them as Stylus precompiles 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. Precompiles are no longer limited to functions supported by the EVM.
How Stylus works
Before diving into WASM’s broader role in the blockchain universe, it’s critical to understand how Arbitrum orchestrates the coexistence of EVM and WASM. It’s not just about having two separate engines; it’s a synergistic relationship that enhances the strengths of both.
Arbitrum’s unique architecture allows seamless and synchronized operations between EVM and WASM thanks to its unified state, cross-VM calls, and compatible economic models.
Smart contracts written in Solidity or other EVM languages compile to 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 compile their smart contracts to WASM using off-the-shelf WASM compilers such as Clang or Rustc.
WASM bytecode is uploaded to the Arbitrum chain in compressed form.
The contract owner calls the ArbWasm precompiled `compileProgram` method, which sets up security instrumentation for WASM, meters its gas costs, and compiles it to 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 the EVM, saving Gas Fee.
WASM metering charges Gas before each basic block, rather than charging per opcode like EVM. This is more efficient and ensures that the contract will not get out of control.
EVM and WASM
The two virtual machines (VMs) run in sync, allowing them to call each other while sharing the same global state. A transaction might be executed partially in the EVM and partially in the 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 structures and state trie. Contracts in one VM can read/write to the same locations as contracts in another VM. This provides a unified view of the chain state.
Cross-VM calls: When a transaction interacts with an EVM contract, Geth processes it and provides a result. If the EVM contract then calls a WASM program, the WASM VM takes over to calculate that part of the result.
Shared context: System information like block data, sender address, etc. are available to both VMs. A WASM contract can get the block number just like a Solidity contract.
Single Consensus: Validators run two VMs to verify transactions and reach consensus on the correct chain state. Disputes invoke a unified 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 between the EVM and WASM execution to identify any invalid steps if necessary. The structure of WASM allows the system to guarantee termination and enforce the validity of the proof.
Blockchain | WASM
Arbitrum isn’t the only platform to recognize the transformative potential of WebAssembly (WASM). Both Polkadot and Cosmos have also integrated WASM into their ecosystems, with each offering a unique set of benefits and capabilities.
Polkadot allows users to develop smart contracts in 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 has embraced WASM so much, it’s necessary to understand the specific advantages that Cosmos and Polkadot highlight:
Cosmos emphasizes 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 advantages provided by WASM, each platform also has its own unique properties.
The widespread adoption of WASM by these major blockchain platforms is a testament to its growing importance in the industry, making it crucial to understand why this technology is quickly becoming a cornerstone of modern blockchain architecture.
Why 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 forces behind its development.
WebAssembly is a binary instruction format that enables code to be executed at near-native speeds 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 secure. WASM effectively bridges the gap between web-based and system-level programming, improving web performance and functionality.
The "Web" in WebAssembly highlights its ability to run in a JavaScript environment (usually found in a browser). In these settings, developers have full access to the WASM API and have comprehensive Web API support, giving them considerable control over the behavior of the Web.
WASM History
Following the principle of "write once, run everywhere", WASM emerges as a powerful solution to a set of long-standing challenges. As of 2016, many programs introduce new features through domain-specific languages (DSLs), which often involve trade-offs between maintenance, efficiency, and security. There is a growing demand for a solution that can provide new features to countless servers without compromising these aspects.
The shortcomings of various existing solutions were evaluated:
- System Virtual Machine
Frequent startup and shutdown creates excessive overhead
Lack of code visibility to ensure security
Performance requirements are too abstract
- Container
Lack of code visibility to ensure security
Inefficiency due to high-level abstraction
Frequent operations bring significant overhead
- Language-level virtual machines
Requires frequent modifications to ensure safety
Embedded VMs, such as V8, are resource intensive
Slow adaptation of new languages to security models
Still too abstract
- Instruction Set Architecture (ISA)
Difficult to effectively sandbox
Previous Google projects have moved from it to WASM
Lack of mature implementation
By 2018, WASM development gained momentum, with a focus on running on a variety of architectures, servers, embedded hardware, and even supporting multiple languages. Unlike Java, WASM was designed without compromising security. By 2019, a component model was introduced to promote WASM modules, enabling 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 features 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 the JavaScript engine
Powerful sandbox with memory and CPU limits
Extremely fast startup times, typically in milliseconds or less
The WASM community continues to work towards 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 context gives us a nuanced understanding as we explore questions and concerns about WASM implementations in the blockchain ecosystem.
Stylus Q&A
language support
The WASM journey reveals why Stylus is an exciting addition to the Arbitrum ecosystem, but it also highlights some limitations and concerns. One of those concerns is language support. While Stylus has indeed expanded the Arbitrum developer community to include languages like C++ and Rust, it has fallen short in embracing popular languages like JavaScript and Python.
While there are initial projects aiming to bring 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 SDKs, and integrates seamlessly with the toolchains of these languages. Developers can even integrate third-party libraries, such as native encryption implementations, when building smart contracts. The main limitation of doing so is the associated gas fees.
Although the Rust SDK is still in its early stages, there are some missing features in both the Rust and C SDKs. For example, the C SDK does not support ABI exported functions, and modifiers are not yet supported in both SDKs.
Currently, there is no native Stylus testing environment, but developers can run tests directly within the SDK. For deploying smart contracts, the 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]** 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 abstractions. Developing a completely new DSL requires significant investment in toolchain and ecosystem development. In contrast, as a subset of a general-purpose language, an eDSL allows for easier integration with existing tools and a lower learning curve. For example, creating an eDSL in a popular language like JavaScript or Python would be beneficial.
Ubiquitous languages require the use of an SDK, which introduces additional tooling, increases verbosity, and reduces the expressiveness of the code, along with longer API calls and object operations.
Finding the right balance between language choice and eDSL development may be the key to attracting a 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 utilize Rust for smart contracts, such as Polkadot, Cosmos, and Solana, are also gaining traction and growing rapidly in their developer communities.
performance
WASM significantly improves execution speed and reduces packet size. While 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, capped at approximately 128KB when uncompressed. This limit makes porting large smart contracts from other languages such as Solidity challenging. In the Stylus codebase, the limit is described as follows:
It’s worth noting that WASM incurs some overhead on 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, which facilitates Stylus' interoperability with EVM. This is achieved through the EVM API implemented in WASM, using the popular Host I/O pattern. The comprehensive list of supported EVM APIs shows that interoperability is fully supported.
Custom precompiled contracts
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 inference costs by introducing tensor computations as precompiled contracts. However, there does not appear to be existing code related to custom precompiled contracts at this time. While precompiled contracts exist for EVM components, they are not hot-swappable.
This feature is likely still under development, leveraging the power of WASM. The EVM can call functions written in WASM, which are then compiled to machine code.
Reentrant Function
In contrast to CosmWasm (which uses the Actor model without reentrancy), Stylus' Rust SDK turns off reentrancy by default as a feature flag. Developers have the option to enable this feature manually.
Activating reentrancy will require some API adjustments. In particular, developers need to be careful about safety precautions such as flushing storage caches during calls.
Insights
Stylus opens up new use cases that are too gas-intensive to use with just the EVM, such as high-performance crypto, gaming, and AI. It also allows for custom precompiled contracts, allowing developers to add their own crypto and other infrastructure 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 that the Ethereum community has adopted WASM. Overall, Stylus represents a major evolution in smart contract development and will help Ethereum and Arbitrum scale while maintaining interoperability with all existing applications.
Integrating Stylus into Arbitrum’s Layer2 SDK provides greater flexibility for layer 3 developers. They can now move intensive computations that previously exceeded gas limits on-chain, opening up new possibilities. Developers are no longer limited to using Solidity, and can choose Rust or C++ if those languages better suit their needs and expertise. Custom precompiled contracts allow for seamless migration of preferred crypto, utility, and other helper functions on-chain for optimal performance. Writing low-level logic directly in a language that fits each use case leads to more fluid development. Developers can focus on core product features rather than taking stopgap measures to avoid gas costs. By removing language and gas limits, Stylus enables layer 3 builders to build the most efficient user experience from the start, using the right tools for their domain.
Stylus also proves that Arbitrum has the ability to make large-scale innovations 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 the original system. OP has gone further on the road of ZKization and has gradually moved towards the idea of hybrid Rollup. Optimism is currently working with Risc0 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 my previous post [Twitter].
We’re really looking forward to seeing AI applications at Arbitrum. Currently, performing machine learning on-chain is very gas-intensive, making development expensive. 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 letting developers 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.
