Stylus: Solve the Scalability Issue V2

Overview

The layer 2 landscape is evolving rapidly as zero-knowledge rollups (ZKRUs) like zkSync and StarkNet have launched mainnets. Traditionally, optimistic rollups (OPRUs) like Arbitrum were first to market and benefited from stronger ecosystems. In contrast, ZKRUs have touted advantages in technology, with higher throughput and lower fees for massive transaction volumes.

In recent months, more activity has migrated from layer 1 to layer 2, seeking faster and cheaper transactions. Ethereum’s total value locked (TVL) has decreased from almost $40B to $20B in the past year. However, layer 2 TVL paints a different picture, with massive growth indicating a boom in layer 2 adoption as users shift assets from layer 1.

Arbitrum leads with over 50% market share of layer 2 TVL, despite ZKRUs’ hardwork. Arbitrum’s first-mover advantage has allowed it to maintain a dominant position.

Analyzing daily transaction counts shows ZKRUs like zkSync and StarkNet slightly outpace OPRUs in throughput. Yet Arbitrum’s ecosystem strength persists despite trailing in daily TPS.

OPRUs have been around longer than ZKRUs. However, ZKRUs are launching their mainnets and attracting users from other ecosystems. The 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 costs, ZKRUs may continue gaining market share given their scalability advantages. But Arbitrum’s network effects provide resilience despite competitive forces. With innovative solutions like Stylus, Arbitrum can complement its leadership with unique technical capabilities and remain frontrunner in the layer 2 race.

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

It opens up blockchain to general computation and welcomes developers with different tech stacks.

Rich Language Support

Arbitrum Stylus is an exciting new programming environment for Arbitrum chains that will enable developers to write smart contracts in languages like Rust, C++, and C, in addition to Solidity. Stylus will allow these different languages to work together seamlessly, with full interoperability between contracts written in different languages.

According to data from Electric Capital, there are approximately 23,000 crypto developers. This number has doubled in the past three years. However, compared to developers in the tech industry, it is still relatively small. There are around 17.4 million developers using JavaScript and 2.2 million developers using Rust. These figures far exceed the number of crypto-native developers.

Stylus will have a huge impact by vastly expanding the number of developers who can build on Arbitrum. There are millions of developers familiar with languages like Rust and C++ compared to the tens of thousands who know Solidity today. By supporting these languages natively, Stylus will make it easier for developers to build Web3 applications without having to learn a new language like Solidity.

WASM

Stylus works through the addition of a WebAssembly (WASM) virtual machine that runs alongside the existing Ethereum Virtual Machine. Smart contracts written in languages that compile to WASM can be executed natively at speeds 10x or faster than Solidity, slashing gas costs. The EVM remains fully functional, so existing Solidity contracts work exactly as they do today. The two VMs operate synchronously, allowing contracts in different languages to call each other while still modifying the same underlying blockchain state.

Custom Precompiles

Besides, Stylus also enables custom precompiles support.

Precompiles are low-level modules on Ethereum and Arbitrum that execute specific cryptographic or utility functions very efficiently. For example, there are precompiles for ECDSA signature verification and for computing SHA256 hashes.

Adding new precompiles requires a coordinated fork by all validators to upgrade the EVM, so the bar is high. With Stylus, developers can deploy their own Rust or C++ precompiles with ease.

For instance, a team could take a cryptography library written in C and deploy it unmodified to Arbitrum. This would allow ultra-fast native execution of those cryptographic primitives.

Other contracts could then call into this Stylus “precompile” to leverage that cryptography just as they would a native precompile. All gas metering and fraud proofs would work automatically.

This enables teams to prototype custom cryptography, exotic pairing-based curves, and other novel primitives without any special chain support. Ethereum researchers could even iterate on EIP proposals by deploying them as Stylus precompiles on Arbitrum ahead of any mainnet upgrade.

By empowering developers to bring new cryptographic primitives natively on-chain, Stylus significantly expands the horizons of what can be built. Precompiles are no longer limited to just the functionality supported by the EVM.

How Stylus works

Before we delve into the broader landscape of WASM’s role in the blockchain universe, it’s crucial to understand how Arbitrum harmonizes the co-existence of EVM and WASM. This isn’t just about having two separate engines; it’s about a synergistic relationship that amplifies the strengths of both.

Arbitrum’s unique architecture allows for seamless and synchronous operations between EVM and WASM, thanks to its unified state, cross-VM calls, and compatible economics.

Smart contracts written in Solidity or other EVM languages compile to EVM bytecode as normal. When executed, these contracts run on the EVM exactly as they do today.

For languages that compile to WASM, like Rust, C++, and C, the workflow is:

1. The developer compiles their smart contract to WASM using an off-the-shelf WASM compiler like Clang or Rustc.
2. The WASM bytecode is uploaded to the Arbitrum chain in compressed form.
3. The contract owner calls the compileProgram method of the ArbWasm precompile, which instruments the WASM for security, meters it for gas costs, and compiles it to native code optimized for the validator's hardware.
4. When the contract is called, it runs on a WASM runtime like Wasmer much faster than the EVM, saving gas costs.

The WASM metering charges gas before each basic block rather than per-opcode like the EVM. This is more efficient and ensures contracts can’t run out of control.

EVM <> WASM

The two VMs run synchronously, allowing them to call each other while sharing the same global state. A transaction may execute partly in EVM and partly in WASM, with the results seamlessly combined.

Wait, how can two VMs work seamlessly and synchronously?

Polkadot implements this by XVM. Different from Polkadot, Wasm, and EVM can work seamlessly and synchronously on Arbitrum for a few key reasons:

• Single state: Both VMs access the same underlying data structures and state trie. A contract in one VM can read/write to the same locations as a contract in the other 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 an outcome. If the EVM contract subsequently invokes a WASM program, the WASM VM takes over to calculate that portion of the result.
• Shared context: System info like block data, sender address, etc. is made available to both VMs. A Wasm contract can get 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 invoke the unified fraud proof system.
• Compatible economics: Concepts like gas metering extend across VMs, ensuring appropriate costs and resources for computation in either environment.

For fraud proofs, the validator bisects over both EVM and WASM execution as needed, identifying any invalid steps. WASM’s structure allows the system to guarantee termination and enforce the validity of proofs.

Blockchain ❤️ WASM

Arbitrum is far from alone in recognizing the transformative potential of WebAssembly (WASM). Both Polkadot and Cosmos have incorporated WASM into their ecosystems, each offering a unique set of benefits and capabilities.

Polkadot allows users to develop smart contracts in WASM, supporting two languages: AssemblyScript for an embedded DSL and Ink!, a language similar to Rust.

Cosmos, on the other hand, utilizes CosmWasm as its smart contract runtime, allowing developers to write contracts in Rust.

Before delving into why the blockchain industry has embraced WASM, it’s instructive to examine the specific advantages highlighted by Cosmos and Polkadot:

Cosmos emphasizes the following benefits of WASM:

• Compatibility with Rust libraries
• A diverse developer community
• Enhanced security, including prevention of reentrancy attacks
• Ease of testing
• High performance

Polkadot’s WASM runtime boasts these features:

• High performance
• EVM interoperability
• Platform agnosticism
• Compact binary size
• Support for both Rust and AssemblyScript (in a TypeScript style)

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

The widespread adoption of WASM across these major blockchain platforms attests to its growing importance in the industry, making it crucial to understand why this technology is rapidly becoming a cornerstone of modern blockchain architectures.

Why WASM

What is WASM

To grasp the synergy between blockchain and WebAssembly (WASM), it’s essential to 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 speeds within web browsers. 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 divide between web-based and system-level programming, thereby enhancing both web performance and capabilities.

The “Web” in WebAssembly highlights its capability to run in JavaScript environments, commonly found in browsers. Within these settings, developers have full access to the WASM API, as well as comprehensive Web API support, granting them considerable control over web behavior.

WASM History

Developed with the principle of “write once and run anywhere,” WASM emerged as a compelling solution to a set of long-standing challenges. As of 2016, many programs were introducing new features through Domain-Specific Languages (DSLs), which often involved trade-offs between maintenance, efficiency, and safety. There was a growing need for a solution that could deliver new functionalities to countless servers without compromising these aspects.

Various existing solutions were evaluated for their shortcomings:

• System Virtual Machines
• Excessive overhead for frequent spin-ups and downs
• Lack of code visibility for safety assurance
• Too abstracted for performance requirements
• Containers
• Inadequate code visibility for safety
• Inefficiencies due to high-level abstractions
• Significant overhead for frequent operations
• Language-Level Virtual Machines
• Required frequent modifications for safety
• Embedded VMs like V8 were resource-intensive
• Slow to adapt new languages to the security model
• Still too abstracted
• Instruction Set Architectures (ISAs)
• Difficult to efficiently sandbox
• Previous Google projects transitioned from it to WASM
• Lack of mature implementations

WASM development gained momentum by 2018, with a focus on running on various architectures, servers, embedded hardware, and even supporting multiple languages. Unlike Java, WASM was designed without compromising safety. By 2019, a component model was introduced to elevate WASM modules, enabling cross-language interoperability. This allowed for solutions like writing an HTTP library once and using it across multiple languages.

As of now, WASM boasts an array of features and is increasingly adopted in cloud-native scenarios, including blockchain. Among its advantages are:

• High performance
• Compact binary size
• Cross-platform portability
• Support for multiple languages like C/C++, Rust, AssemblyScript, and more
• Execution in JavaScript engines
• Robust sandboxing with memory and CPU limitations
• Extremely fast startup times, often in milliseconds or less

The WASM community continues to strive for greater integration and performance across languages.

Understanding WASM’s historical evolution offers valuable context for its current and potential roles in various settings, including blockchain projects like Stylus. This background equips us with a nuanced understanding as we explore questions and concerns about WASM’s implementation in the blockchain ecosystem.

Widespread interest in Stylus

Language Support

The journey of WASM sheds light on why Stylus is an exciting addition to the Arbitrum ecosystem, but it also brings into focus some of the limitations and concerns. One such concern is language support. While Stylus does extend the Arbitrum developer community to include languages like C++ and Rust, it still falls short in embracing popular languages such as JavaScript and Python.

While there are nascent 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

Stylus currently supports C/C++ and Rust SDKs, integrating seamlessly with toolchains for these languages. Developers can even incorporate third-party libraries, such as native cryptography implementations, when building smart contracts. The primary constraint in doing so is the associated gas cost.

While the Rust SDK is still in its early stages, both Rust and C SDKs have some missing features. For instance, the C SDK lacks support for ABI export functions, and modifiers are not yet supported in either SDK.

As of now, a local Stylus test environment is not available, but developers can run tests directly within the SDKs. For deploying smart contracts, the testnet is currently the only option, and it does not yet support smart contract verification. Efforts are underway to bring various ERC tokens and Uniswap V2 into the Stylus ecosystem.

Language Choice Dilemma

Choosing between a Domain-Specific Language (DSL), an embedded DSL (eDSL), or a general-purpose language presents a trade-off between low-level control and high-level abstractions. Developing a brand new DSL requires significant investment in the toolchain and ecosystem development. In contrast, an eDSL, being a subset of a general-purpose language, allows for easier integration with existing tools and a lower learning curve. For instance, creating an eDSL in popular languages like JavaScript or Python would be advantageous.

General-purpose languages necessitate the use of SDKs, introducing additional tooling, increased verbosity, and less expressive code, coupled with longer API calls and object operations.

Striking the right balance between language choice and eDSL development could be key to attracting a broader developer community while providing user-friendly tools. As current data suggests, the top crypto developer community remains centered around Ethereum. However, platforms like Polkadot, Cosmos, and Solana, which utilize Rust for smart contracts, are also gaining traction and experiencing rapid growth in their developer communities.

Performance

WASM significantly enhances execution speed while reducing bundle size. Although Stylus has not yet been deployed on the mainnet, benchmarks from other networks serve as useful references. Execution times have been observed to be 4–8 times faster, and the compiled size has been reduced by approximately 50%.

Stylus currently imposes a size limit on its contracts, capping them at approximately 128KB when uncompressed. This constraint makes it challenging to port extensive smart contracts from other languages like Solidity. The limitation is specified in the Stylus codebase as follows:

It’s worth noting that WASM incurs some overhead for spinning up and down. For lightweight operations, EVM might actually be more cost-effective than WASM.

Interoperability with EVM

EVM and WASM share the same storage slots and state trie, facilitating Stylus’s interoperability with EVM. This is achieved via EVM APIs implemented in WASM, using the popular Host I/O mode. A comprehensive list of supported EVM APIs in WASM suggests that interoperability is fully supported.

Custom Precompiles

This aspect is particularly exciting as it represents uncharted territory. Custom precompiles have the potential to bring additional cryptographic primitives on-chain at much lower execution costs. They could also facilitate on-chain machine learning by introducing tensor computations as precompiles to reduce inference costs. However, there doesn’t appear to be any existing code related to custom precompiles at this time. While precompiles exist for the EVM component, they are not hot-swappable.

It’s likely that this functionality is still under development, leveraging the capabilities of WASM. EVM can invoke functions written in WASM, which can then be compiled down to machine code.

Reentrant Functionality

In contrast to CosmWasm, which employs an actor model without reentrant capabilities, Stylus’s Rust SDK includes reentrancy as a feature flag that is turned off by default. Developers have the option to manually enable this feature.

Activating reentrancy will necessitate some API adjustments. Developers will need to be cautious, particularly when it comes to flushing the storage cache during calls, among other safety precautions.

Insight

Stylus opens up new use cases like high-performance cryptography, gaming, and AI that were too gas-intensive on EVM alone. It also enables custom precompiles, allowing developers to add their own cryptography and other primitives without waiting for upgrades. In the past, we have seen some non-Ethereum ecosystem adopting WASM, like Cosmos and Polkadot. This is the first time, Ethereum community has adopted WASM. Overall, Stylus represents a major evolution in smart contract development that will help Ethereum and Arbitrum scale while remaining interoperable with all existing applications.

Integrating Stylus into Arbitrum’s layer 2 SDK unlocks greater flexibility for layer 3 developers. They can now move intensive computations on-chain that previously exceeded gas limits, opening up new possibilities. Developers are no longer constrained to Solidity if other languages like Rust or C++ better suit their needs and expertise. Custom precompiles allow seamlessly migrating preferred cryptography, utilities, and other helper functions on-chain for optimal performance. The ability to write low-level logic natively in languages tailored to each use case results in more streamlined development. Instead of workarounds to avoid gas costs, developers can focus on core product functionality. By eliminating language and gas limitations, Stylus enables layer 3 builders to access the right tools for their domain and build the most efficient user experiences from the ground up.

Stylus has also proven that Arbitrum is capable of large-scale customization and integrating new virtual machines. Ed Felten, Co-founder & Chief Scientist of Arbitrum & Offchain Labs, mentioned that Arbitrum is developed based on popular industry tools and programming languages. This allows them to write tests and develop new features more rapidly on top of the existing systems. OP has gone further down the path of ZK and is gradually moving towards a hybrid Rollup approach. Optimism is currently collaborating with Risc0, using Zeth to generate zero-knowledge proofs for OPRU. With this solution, Optimism doesn’t need to make additional modifications to OPRU. If you are interested in Zeth, you can check out my previous tweets.

We are very excited to see AI applications on Arbitrum. On-chain machine learning is currently extremely gas-intensive, making development costly. Zero-knowledge ML can decrease costs but also introduce significant additional complexity for developers. If we can implement tensor operations as custom precompiles through Stylus, executing them natively at a fraction of the cost, it opens up new possibilities for performant on-chain machine learning. By empowering developers to rapidly prototype and deploy ML algorithms as Stylus contracts with their familiar language like Python, accessible as easy-to-integrate precompiles, Arbitrum can enable the next generation of AI innovation in DeFi, GameFi, and more. The performance and flexibility of Stylus will allow us to focus on novel ML architectures rather than gas optimization. We look forward to seeing the creativity of the community applied to this emerging paradigm.