Why is Arbitrum Stylus considered the most important technological innovation in L2 this year?

Why is Arbitrum Stylus the top L2 technological innovation this year?

With the launch of ZKRUs like zkSync and StarkNet, the Layer2 landscape is rapidly evolving. Traditionally, OPRUs like Arbitrum were the first to enter the market, thus having a stronger ecosystem. In contrast, ZKRUs have made technological breakthroughs, offering higher throughput and lower fees.

In recent months, more activity has migrated from Layer1 to Layer2 in search of faster and cheaper transactions. Ethereum’s TVL has dropped from nearly $40 billion to $20 billion in the past year. However, the TVL of Layer2 presents a different picture, with significant growth indicating the accelerated adoption of Layer2.

Arbitrum leads with over 50% of the Layer2 TVL market share, 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 like zkSync and StarkNet slightly surpass OPRUs in throughput. However, Arbitrum’s ecosystem advantage remains, albeit 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 costs, ZKRUs may continue to gain market share due to their scalability advantages. However, Arbitrum’s network effects provide the ability to remain robust despite competition. With innovative solutions like Stylus, Arbitrum can complement its leadership position with unique technical capabilities and continue to stay ahead in the Layer2 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 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 can be compiled into WASM can be natively executed 10 times or more faster than Solidity, significantly reducing gas costs. The EVM remains fully functional, so existing Solidity contracts continue to operate normally. 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 efficiently execute specific cryptographic or utility functions. For example, there are precompiles for ECDSA signature verification and computing SHA256 hashes.

Adding new precompiles requires coordination among all validators to upgrade the EVM, so the barrier is high. 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 and deploy it to Arbitrum without modification. This allows these cryptographic primitives to be executed at super-fast native speeds.

Other contracts can call this Stylus “precompile” just like they would call a native precompile to leverage the cryptographic technology. All gas metering and fraud proofs will work automatically.

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

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

How Stylus Works

Before delving into the broader 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 about having two independent engines; it is a synergistic relationship that enhances the strengths of both.

Arbitrum’s unique architecture allows for seamless and synchronized operation 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 invoked, it runs on a WASM runtime like Wasmer, which is much faster than the EVM, thus saving gas fees.

WASM metering charges gas before each basic block, rather than per opcode like the EVM. This is more efficient and ensures that contracts do not spin 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 can be partially executed in the EVM and partially in the WASM, with the results seamlessly combined.

But wait, how can two VMs work together 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 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 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 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 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 perform bisecting in both EVM and WASM executions to identify any invalid steps if necessary. The structure of WASM allows the system to guarantee termination and enforce proof validity.

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, allowing 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 to test
High performance

Polkadot’s WASM runtime offers these features:

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 demonstrates 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 WASM

What 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 enables code to be executed at near-native speed within web browsers. It serves as a compilation target for a range of programming languages, including C and Rust, and is designed for speed, efficiency, and security. WASM effectively bridges the gap between web and system-level programming, thereby enhancing web performance and functionality.

The “Web” in WebAssembly highlights its ability to run within the JavaScript environment, typically found in browsers. In these settings, developers have full access to the WASM API and enjoy 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 functionalities through domain-specific languages (DSLs), often involving trade-offs between maintainability, efficiency, and security. There was an increasing demand for a solution that could provide new functionalities 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
Excessive abstraction for performance requirements

– Containers

Lack of code visibility to ensure security
Inefficient due to high-level abstraction
Significant overhead from frequent operations

– Language-level virtual machines

Frequent modifications required for security
Embedded VMs, such as V8, resource-intensive
Slow adaptation of new languages to security models
Still too abstract

– Instruction Set Architectures (ISAs)

Difficult to sandbox effectively
Previous Google projects shifted towards WASM
Lack of mature implementations

By 2018, WASM development gained momentum, with a focus on running on various architectures, servers, and embedded hardware, and 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 allowed for solutions like writing an HTTP library once and using it in multiple languages.

So far, 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
Platform portability
Support for multiple languages such as C/C++, Rust, AssemblyScript, etc.
Execution in JavaScript engines
Powerful sandbox with memory and CPU limits
Extremely fast startup time, typically in milliseconds or less

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

Understanding the evolution of WASM provides valuable background 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 development history 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 adopting popular languages like JavaScript and Python.

Although there are initial 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.

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 of doing so 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 supported in both SDKs yet.

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 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 trade-off 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 SDKs, which introduce additional tools, increase verbosity, and reduce 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 broader developer community while providing user-friendly tools. According to current data, the top cryptocurrency developer community still revolves around Ethereum. However, platforms utilizing Rust for smart contract development, such as Polkadot, Cosmos, and Solana, are also gaining attention and experiencing rapid growth in their developer communities.

Performance

WASM significantly improves execution speed and reduces package size. Although Stylus has not been deployed on the mainnet yet, 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%.

Currently, Stylus imposes size limits on its contracts, with an upper limit of approximately 128KB uncompressed. This limitation makes it challenging to port large-scale smart contracts from other languages like Solidity. In the Stylus codebase, this limitation 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 facilitates interoperability between Stylus and EVM. This is achieved through the implementation of the 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 a lower execution cost. They can also lower inference costs by introducing tensor computations as precompiled contracts. However, currently, there seems to be no existing code related to custom precompiled contracts. While EVM components exist for precompiled contracts, they are not hot-swappable.

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

Reentrancy

Unlike CosmWasm, which adopts an Actor model without reentrancy, the Rust SDK of Stylus has reentrancy disabled by default as a feature flag. Developers have the option to manually enable this feature.

Enabling reentrancy will require some API adjustments. Developers need to be cautious, especially with regards to refreshing storage caches and other security precautions during the invocation process.

Insight

Stylus has opened up some new use cases that consume too much gas when using only the 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 basic functions 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 previously gas-limited intensive computations 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 directly in the language that suits each use case results in smoother development. Developers can focus on core product functionality rather than resorting to workarounds to avoid gas costs. By eliminating language and gas limitations, Stylus enables third-layer builders to use the right tools for their domain from the start and create the most efficient user experience.

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 industry tools and programming languages. They can write tests more quickly and develop new features on top of the original system. OP has made further progress on the path to ZKization and is gradually moving towards a mixed Rollup approach. Optimism is currently working with Risc0 to use Zeth to generate zero-knowledge proofs for OPRU. With this solution, Optimism does not need to make any 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, performing machine learning on-chain consumes a lot of gas, making development costly. Zero-knowledge ML can reduce costs but also introduces significant additional complexity for developers. If we can implement tensor operations as custom precompiled contracts through Stylus and execute them natively 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 like 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!

ArbitrumStylus

Was this article helpful?

93 out of 132 found this helpful