IOSG Why is Aribitrum Stylus considered the most important L2 technology innovation this year?

Why is Aribitrum Stylus considered the top L2 tech innovation this year?

With the launch of ZKRUs such as zkSync and StarkNet, the Layer 2 landscape is evolving rapidly. Traditionally, OPRUs like Arbitrum were the first to enter the market, therefore they have a stronger ecosystem.

Author: Yiping, IOSG Ventures

With the launch of ZKRUs such as zkSync and StarkNet, the Layer 2 landscape is evolving rapidly. Traditionally, OPRUs like Arbitrum were the first to enter the market, therefore they have a stronger ecosystem. In contrast, ZKRUs have made technological breakthroughs and 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 in the past year. However, Layer 2 presents a different picture, with significant growth indicating the acceleration of Layer 2 adoption.

• IOSG Weekly Report Why is Aribitrum Stylus the most important technological innovation in Layer 2 this year?
• Why is Arbitrum Stylus considered the most important technological innovation in L2 this year?
• Explaining Celestia’s airdrop and economic model, how will the future project’s airdrop method evolve?

Arbitrum leads with over 50% market share of Layer 2 TVL, despite the efforts of ZKRUs. Arbitrum’s first-mover advantage allows it to maintain its dominant position.

Analysis of daily transaction volumes shows that ZKRUs such as zkSync and StarkNet slightly outperform OPRUs in terms of throughput. However, Arbitrum’s ecosystem advantage remains, although it lags 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 field, Arbitrum is expected to counter the rise of ZKRUs with their new updates.

Arbitrum: Stylus

With developers optimizing zero-knowledge technology and costs, ZKRUs may continue to gain market share due to their scalability advantages. However, Arbitrum’s network effects provide the ability to maintain stability even under competitive pressure. With innovative solutions like Stylus, Arbitrum can complement its leadership position 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, allowing developers to write efficient and interoperable programs in programming languages like Rust, C++, and Solidity.

It opens up general-purpose computing on the blockchain and welcomes developers with 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 can be compiled to WASM can be natively executed at speeds 10 times or more faster than Solidity, greatly reducing gas costs. The EVM remains fully functional, so existing Solidity contracts continue to operate as usual. The two VMs operate synchronously, allowing contracts written in different programming languages to call each other and modify the same underlying blockchain state.

Custom Precompiles

In addition, Stylus also supports custom precompiles.

Precompiles are underlying modules used on Ethereum and Arbitrum to execute specific cryptographic or utility functions very efficiently. For example, there are precompiles for ECDSA signature verification and SHA256 hash computation.

To add new precompiles, all validators need to coordinate and upgrade the EVM, which is a high barrier. However, with Stylus, developers can easily deploy their own precompiles written in Rust or C++.

For example, a team can use an encryption library written in C language and deploy it to Arbitrum without modification. This allows these cryptographic primitives to be executed at super-fast native speed.

Other contracts can call this Stylus “precompile” just like they call native precompiles to take advantage of this encryption technology. All gas metering and fraud proofs work automatically.

This allows teams to prototype custom encryption, special pairing-based curves, and other new primitives without any specific chain support. Ethereum researchers can even deploy them on Arbitrum as Stylus precompiles to iterate on EIP proposals.

By empowering developers to natively introduce new cryptographic primitives on-chain, Stylus greatly expands the range of content that can be built. Precompiles are no longer limited to the functionality supported by the EVM.

How Stylus Works

Before delving into the wider role of WASM in the blockchain universe, it is crucial to understand how Arbitrum coordinates the coexistence of EVM and WASM. It is not just having two independent engines; it is a synergistic relationship that enhances the strengths of both.

Arbitrum’s unique architecture allows seamless and synchronous operations between EVM and WASM, thanks to its unified state, cross-VM invocations, 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 compiled into WASM, such as Rust, C++, and C, the workflow is as follows:

• Developers use existing 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 calls the `compileProgram` method of the `ArbWasm` precompile, which sets up security tools for WASM, measures its gas cost, and compiles it into native code optimized for validator hardware.

• When the contract is called, it 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 charging per opcode like the EVM. This is more efficient and ensures contracts do not run out of control.

EVM and WASM

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

Wait, how can two VMs work seamlessly and synchronously?

Polkadot achieves this through 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 structure and state Trie. A contract in one VM can read/write to the same location in a contract in the other VM. This provides a unified view of the chain state.

• Inter-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 compute the result for that portion.

• Shared context: System information such as block data and sender address is available to both VMs. A WASM contract can retrieve block numbers 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 a unified fraud proof system.

• Compatible economics: Concepts like gas metering extend to each VM, ensuring appropriate computational costs and resources in either environment.

For fraud proofs, validators will bisect the EVM and WASM executions to identify any invalid steps if necessary. The structure of WASM allows the system to guarantee termination and enforce the validity of proofs.

Blockchain | WASM

Arbitrum is not the only platform that recognizes 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 using WASM and supports two languages: AssemblyScript, an embedded DSL, and Ink!, which is similar to Rust.

On the other hand, Cosmos uses CosmWasm as its smart contract runtime, enabling developers to write contracts in Rust.

Before delving into why the blockchain industry is so receptive to WASM, it is necessary to understand the specific advantages highlighted by Cosmos and Polkadot:

Cosmos emphasizes the following advantages of WASM:

• Compatibility with Rust libraries

• Diverse developer community

• Enhanced security, including protection against reentrancy attacks

• Easy testing

• High performance

Polkadot’s WASM runtime has the following characteristics:

• High performance

• Interoperability with EVM

• Platform agnosticism

• Compact binary size

• Support for both Rust and AssemblyScript (TypeScript-style)

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

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

Why Choose WASMWhat is WASM

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

WebAssembly is a binary instruction format that allows code to be executed in web browsers at near-native speed. It serves as a compilation target for a range of programming languages, including C and Rust, with the aim of being fast, efficient, and secure. WASM effectively bridges the gap between web and system-level programming, enhancing web performance and functionality.

The “web” in WebAssembly highlights its ability to run in a JavaScript environment, typically found in browsers. In these settings, developers have full access to the WASM API and extensive 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 set of long-standing challenges. By 2016, many programs introduced new features through domain-specific languages (DSL), which often involved trade-offs between maintainability, efficiency, and security. There was an increasing demand for a solution that could provide new capabilities to countless servers without compromising these aspects.

The shortcomings of various existing solutions were evaluated:

– System Virtual Machines

• Excessive overhead from frequent startups and shutdowns

• Lack of code visibility to ensure security

• Abstracted away performance requirements

– Containers

• Lack of code visibility to ensure security

• Inefficiency due to high-level abstractions

• Significant overhead from frequent operations

– Language-Level Virtual Machines

• Need for frequent modifications to ensure security

• Resource-intensive embedded VMs, such as V8

• Slow adaptation of new languages to the security model

• Still too abstract

– Instruction Set Architectures (ISA)

• Difficult to sandbox effectively

• Previous Google projects shifted towards WASM

• Lack of mature implementations

By 2018, WASM development gained momentum, focusing on running on various architectures, servers, and embedded hardware, even supporting multiple languages. Unlike Java, WASM’s design does not compromise on security. By 2019, a component model was introduced to enhance WASM modules and achieve cross-language interoperability. This allows solutions like writing an HTTP library once and using it in multiple languages.

Today, 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

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

• Execution in JavaScript engines

• Powerful sandbox with memory and CPU restrictions

• Extremely fast startup time, usually in milliseconds or less

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

Understanding the evolutionary history of WASM provides valuable context for understanding its current and potential role in various settings, including blockchain projects like Stylus. This background gives us a nuanced understanding when exploring questions and concerns regarding the implementation of WASM in the blockchain ecosystem.

Stylus Q&A

Language Support

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

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

Language Compatibility

Currently, Stylus supports C/C++ and Rust SDKs, seamlessly integrating 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 for doing such things is the associated gas cost.

While the Rust SDK is still in its early stages, both the Rust and C SDKs have some missing features. For example, the C SDK does not support ABI export functions, and decorators are not yet supported in both SDKs.

Currently, there is no local Stylus test 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 introduce 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 balance between low-level control and high-level abstraction. Developing a brand-new DSL requires significant investment in toolchain and ecosystem development. On the other hand, as a subset of general-purpose languages, eDSLs allow for easier integration with existing toolsets and have a lower learning curve. For example, creating eDSLs in popular languages like JavaScript or Python would be beneficial.

Generic languages require the use of SDK, which introduces additional tools, increases verbosity, and reduces code expressiveness, while also resulting in 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 cryptocurrency developer community is still concentrated around Ethereum. However, platforms that use Rust for smart contract development, such as Polkadot, Cosmos, and Solana, are also gaining attention and growing rapidly in their developer communities.

Performance

WASM significantly improves execution speed and reduces package size. Although Stylus has not yet been deployed on the mainnet, benchmark tests on other networks can serve as useful references. The observed execution time is 4-8 times faster, and the compiled size is reduced by approximately 50%.

Stylus currently has size restrictions on its contracts, with an uncompressed upper limit of around 128KB. This limitation makes it challenging to port large smart contracts from other languages (such as Solidity). In the Stylus code repository, this limit is described as follows:

It is worth noting that WASM incurs some overhead during startup and shutdown. 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 tree, which contributes to the interoperability of Stylus with EVM. This is achieved by implementing an EVM API in WASM, using the popular Host I/O pattern. The comprehensive list of supported EVM APIs indicates comprehensive support for interoperability.

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 can also lower inference costs by introducing tensor computation as precompiled contracts. However, there currently appears to be no existing code related to custom precompiled contracts. Although the EVM component has precompiled contracts, they are not hot-swappable.

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

Reentrancy

In contrast to CosmWasm (which adopts the actor model without reentrancy), Stylus’s Rust SDK has reentrancy disabled by default as a feature flag. Developers have the option to manually enable this feature.

Activating reentrancy will require some API adjustments. Developers need to be cautious, especially in terms of refreshing storage caches and other security precautions during the calling process.

Insights

Stylus has opened up new use cases that are too gas-consuming when using only EVM, such as high-performance encryption, gaming, and AI. It also allows for custom precompiled contracts, enabling developers to add their own encryption and other foundational features 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 the Ethereum community has adopted WASM. Overall, Stylus represents a significant evolution in smart contract development that will help Ethereum and Arbitrum achieve scalability while maintaining interoperability with all existing applications.

Integrating Stylus into Arbitrum’s Layer2 SDK provides greater flexibility for third-layer 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 using Solidity; if Rust or C++ better suits their needs and expertise, they can choose these languages. Custom precompiled contracts allow for seamless migration of preferred encryption, utilities, and other helper functions onto the chain for optimal performance. Writing low-level logic in a language that suits each use case directly leads to smoother development. Developers can focus on core product functionality rather than devising workarounds to avoid gas costs. By eliminating language and gas constraints, Stylus enables third-layer builders to use the right tools for their domain from the start and build the most efficient user experiences.

Stylus also demonstrates Arbitrum’s ability to innovate on a large scale and integrate new virtual machines. Ed Felten, Co-founder & Chief Scientist of Arbitrum & Offchain Labs, mentioned that Arbitrum was 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 path to ZKification and has gradually moved towards the idea of a hybrid Rollup. Optimism is currently partnering with Risc0 to use Zeth to generate zero-knowledge proofs for OPRU. With this solution, Optimism does not need to make additional modifications to OPRU. If you are interested in Zeth, you can check out my previous [tweet](https://x.com/glazecl/status/1709947992168710174?s=20).

We are very excited to see AI applications on Arbitrum. Currently, conducting machine learning on-chain is very gas-consuming, making development costs high. Zero-knowledge ML can reduce costs but also brings significant additional complexity for developers. If we can use Stylus to implement tensor operations as custom precompiled contracts and natively execute them at a fraction of the cost, it will open up new possibilities for high-performance on-chain machine learning. By allowing developers to quickly build and deploy ML algorithms as easily integrable precompiled contracts using familiar languages like Python, Arbitrum can drive the next generation of AI innovation in fields such as DeFi and GameFi. The performance and flexibility of Stylus 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.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!