Arbitrum Stylus: A New Standard for Smart Contract Composability

Introduction

From wrestling with bytecode on Etherscan to guarding against all sorts of code exploits in Solidity, the EVM tech stack of blockchain development is quite different from that of a web2 tech stack for many developers, thus creating a “gap” between the Solidity-EVM tech stack and the mainstream languages such as Rust, C++, or Python. As the blockchain space continues to mature, there is a great need to bridge this developer gap and allow for a much more composable web3 development.

Within this article, we will introduce Offchain Labs’ latest project, Arbitrum Stylus, unveiled at the Blockchain Applications Stanford Summit (BASS) conference during Stanford Blockchain Week. Arbitrum Stylus is a landmark project that aims to create a new standard for smart contract composability through unifying the execution environment of the EVM with that of WASM. First, we will discuss some of the motivations behind this project, before diving into some of the project’s implementation details, and finally discussing the project’s impact in the web3 space.

Motivation for Arbitrum Stylus

Arbitrum Stylus was developed to address two key problems in blockchain development: (1) the accessibility of blockchain development, and (2) the executional efficiency of smart contracts.

Making Blockchain Development more Accessible

Developer Report by Electric Capital. Image from Source [1]. Retrieved Oct 20 2023.

According to Electric Capital’s Developer Report, there are currently around 20,000 monthly active blockchain developers [1]. Although this number has greatly increased over the past few years, it is still orders of magnitude behind the millions (or tens of millions) of developers that mainstream general-purpose languages such as Rust or C++. As the blockchain space continues to grow, there is an increasing need to streamline the process for onboarding millions of new smart contract developers.

One of the best ways to do this is through integrating the smart contract development process with existing mainstream languages, such as Rust or C++. This is the approach that many non-EVM ecosystems, such as Solana and Cosmos have adopted, with Rust emerging as the de facto smart contract language in those ecosystems. The EVM ecosystem, until now though, primarily relies on its own distinct programming language Solidity to write smart contracts. Arbitrum Stylus, however, seeks to change this through allowing blockchain developers to write smart contracts in mainstream languages such as Rust and then deploy on EVM-compatible chains.

Making Smart Contract Execution more Efficient

Over the past few years, as decentralized applications have exploded in popularity, there has been a dramatically increased demand for on-chain computation, especially on the Ethereum network. This spike in network demand has led to exorbitant gas prices. This in turn has spurred a flurry of innovation in increasing the transactional throughput of public blockchains, and Arbitrum is one of the most prominent projects and ecosystems in this space. This includes the flagship Arbitrum One L2 chain, as well as the Arbitrum Nitro tech stack.

Arbitrum Stylus is a natural extension of all these and the latest solution in Arbitrum’s toolkit. Compared to previous solutions, which focus on optimizing the inter-transactional efficiency of transactions (such as batching transactions through rollups), Stylus focuses on optimizing the intra-transactional level – specifically, how each transaction is executed. Through allowing contracts to be executed in WebAssembly (WASM), Stylus contracts are an order of magnitude faster, promising lower gas fees, as well as having access to memory that can be up to 100-500x cheaper than using the EVM [2].

Stylus: Providing WASM + EVM Composability

WebAssembly and Arbitrum Nitro

To understand why Stylus is so much more efficient and composable than a traditional EVM engine, we need to first understand the role of WebAssembly, or WASM. WASM is a form of assembly language, which means that it is essentially machine-readable binary code, rather than human-readable languages such as Rust or C++. Instead, these human-readable languages need a “compiler” to transform them into machine-readable “assembly languages” before they are executed.

WASM in particular, as its name suggests, is an assembly language optimized for web browsers, to increase the executional speed of primarily Javascript-based Web applications. By being a portable, modular and easily executable assembly language, WASM allows developers to directly write code snippets in a variety of mainstream languages, such as Rust or C++ [3].

With Arbitrum’s Nitro upgrade, because all disputes on-chain are played out in WASM, this means that Nitro has a working fraud system for any arbitrary WASM [2]. And because Arbitrum Nitro is able to provide fraud proofs for any WASM code, this means that it can provide fraud proofs for any program that compiles down to WASM.

Arbitrum Stylus primarily adds a WASM execution engine on top of this existing WASM fraud prover inherited from Arbitrum Nitro, based on one of the leading WASM engines called Wasmer, which executes code much faster than Geth executes EVM bytecode [2]. With both an execution engine and a proof engine, this enables smart contracts to be completely written, executed, and proved in WASM. Given that many mainstream languages, such as Rust and C++ are able to compile directly into WASM, this in turn is how Arbitrum Stylus allows blockchain developers to write, deploy, and execute smart contracts in a wide variety of mainstream general-purpose languages.

Comparing the EVM with Stylus EVM+. Image from Source [2].

Coherence in the EVM+ Engine

Arbitrum Stylus provides developers with the extra option to write contracts in Rust and other WASM-compatible languages, without having to sacrifice the ability to write and execute smart contracts in Solidity. By having two co-equal executional engines of the EVM and WASM, Stylus also provides developers with the option to write part of their application in Solidity, and another part in Rust.

This, however, raises a question: how does the Stylus VM manage the coherence between the two different engines? How does it know when to switch between EVM and the WASM VM?

Firstly, Solidity and other EVM-based contracts are compiled into the same bytecode, then executed as they normally would in a pure EVM engine. WASM-based smart contracts, such as those written in Rust for example, will be annotated by an extra “header” at the beginning of the contract. Thus, when these contracts are called, the Stylus VM is able to tell which contracts require the EVM engine, and which contracts require the WASM engine. This design also accounts for a large degree of interoperability, where contracts written in WASM can make calls to contracts written in Solidity, and vice versa. This is also the main way in which Stylus differs from other blockchains that have adopted WASM execution engines: Stylus ensures that WASM contracts are completely composable and interoperable with EVM ones, allowing for backwards compatibility and WASM contracts to tap into EVM liquidity.

Another perspective to look at Stylus’ dual engine of EVM and WASM is to see the blockchain as a “world state machine” that undergoes certain state transactions as defined in the EVM. In Ethereum, the on-chain state is represented through a Trie-structure, or a tree-like data structure used to store and retrieve data efficiently [4]. Both Stylus’ EVM and WASM engines use the same Trie-structure to read and write data to and from the “world state machine.” Both engines produce some given state change to update the world state; the only difference is how they compute this state change.

Cost Savings of the EVM+ Engine

Previously, we’ve already hinted that using the WASM engine can allow for substantial cost savings due to the increased executional efficiency. We can now examine how this is achieved. To do so, let’s consider a single ADD instruction, say for 2 + 3.

In the EVM, we would need to do the following steps [5]:

1. Pay for gas, requiring multiple look-ups of an in-memory table
2. Consider tracing, even if disabled
3. Pop two items of the simulated stack
4. Add them together
5. Push the result

We can see that only Step 4 really involves the addition of these two integers, whereas all the other steps are “boilerplate instructions” within the EVM system that all cost exorbitant amounts of gas relative to the calculation itself.

On the other hand, suppose we used WASM for this simple ADD operation. We only need one step:

1. Execute a single x86 or ARM ADD instruction

Comparison of EVM ADD and WASM ADD. Image from Source [7].

We can see here that this is 150x cheaper than the EVM add. Given all these gas savings, Stylus VM has even introduced a new subunit of “gas,” called “ink,” currently defined by default as 1/10000 of 1 gas, and even configurable by the chain owner [5].

There is, however, one caveat to all these gas savings, namely, it requires gas to activate the Stylus VM in the first place, currently set to a fixed rate of 114 million gas. In addition, calling a Stylus program itself currently takes about 128-2048 gas [5]. Thus, activating the WASM environment just to optimize for a single ADD operation for two integers may not necessarily make economical sense. However, for smart contracts that are memory-intensive, all these savings will compound, offsetting this “activation cost.” For example, a call that allocates 3.8 MB of RAM in the EVM would cost ~32 million gas, whereas in the Stylus WASM VM this would only cost ~64 thousand gas, providing a saving of 500x [6]. A corollary to this is that memory-intensive applications are simply not possible on the vanilla EVM, as one quickly runs up against all sorts of gas limits. However, this becomes completely possible in the Stylus VM, given the orders of magnitude cheaper RAM becomes using a WASM runtime.

Unlocking New Use Cases with Stylus

1. Memory-Intensive Applications

As discussed above, one of the most exciting parts about Arbitrum Stylus is its enabling of memory-intensive applications on-chain. This unlocks a whole new class of applications, such as generative AI NFTs, high-frequency trading, and on-chain gaming [7]. Indeed, Stylus VM may be a landmark technology that allows for AI, notorious for its high memory demands, to be computationally viable on-chain, and be fully interoperable with EVM contracts.

2. Alt-VM Composability with EVM Liquidity

Moreover, Stylus’ EVM compatibility and ability to allow WASM-based contracts to be interoperable with native Solidity contracts means that these WASM contracts can fully tap into the massive liquidity and user base on the EVM. Recall that we’ve mentioned before that many alternative VMs, such as Solana and Cosmos, use WASM-compatible languages such as Rust to execute their smart contracts. Stylus’ WASM engine means that developers in these alternative VMs can easily port their contracts over to the EVM ecosystem and immediately take advantage of the EVM’s liquidity.

3. General-Purpose Libraries, Precompiles, and Debugging Infrastructure

Another advantage of Stylus allowing developers to use mainstream languages such as Rust and C++ to write their smart contracts is that developers can make use of the massive amounts of general-purpose libraries that support these mainstream languages that contain everything from on-chain computation to cryptographic primitives to file I/O.

More importantly, developers can benefit from sophisticated tooling infrastructure built for these mainstream languages. This not only includes advanced package managers, but also familiar debugging infrastructure, such as the GDB toolkit in C/C++. All this will likely greatly increase the development familiarity of web3, and allow for a much simpler onboarding process into blockchain development and the EVM stack.

4. Bringing On-Chain Computation to the IoT for DePIN

With WASM’s increased executional efficiency, Stylus VM may open the door to integrate on-chain computation with portable devices in the Internet of Things (IoT) – including everything from traffic lights to smart fridges to smartwatches. Although WASM was originally intended for browser environments, its portable, modular architecture and efficient execution has made it a perfect fit for IoT devices, which require small and efficient runtimes [8].

Thus, Arbitrum Stylus’ WASM VM is a natural fit for the growing trend of Decentralized Physical Infrastructure Networks (DePIN), which seek to use blockchain networks and novel token incentives to maintain physical infrastructure, from WiFi systems to solar-powered batteries [9]. As much of DePIN relies on integration of the blockchain stack with IoT devices, Arbitrum Stylus could serve as an important gateway to allow for these devices to both efficiently run WASM based computation and tap into EVM-liquidity through the Arbitrum ecosystem [10].

Conclusion

Throughout this article, we’ve explored in depth the motivation, implementation, and impact of Arbitrum. Stylus. By enabling developers to write and deploy smart contracts in a wide variety of mainstream languages, Stylus makes blockchain development both more accessible and efficient, combining mainstream composability with EVM liquidity to unlock a wide range of novel applications, especially those that are memory-intensive. Thus, Stylus is arguably a landmark project in defining the next generation of composable smart contracts, becoming a platform that is able to blur the boundaries between web2 and web3 development to create a more efficient, integrated, and performant blockchain development stack.

Disclaimer：

1. This article is reprinted from [STANFORD BLOCKCHAIN CLUB]. All copyrights belong to the original author [Rachel Bousfield；Jay Yu]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.