IOSG Ventures: Why is Arbitrum Stylus the most important technological innovation in L2 this year?
With the launch of mainnets like zkSync and StarkNet, the Layer 2 landscape is rapidly evolving. Traditionally, OPRUs like Arbitrum were the first to enter the market, thus having a more robust ecosystem.Original Author: Yiping, IOSG Ventures
With the launch of mainnets like zkSync and StarkNet, the Layer 2 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 technical breakthroughs, offering higher throughput and lower fees.
In recent months, more activity has 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 significant growth indicating that the adoption of Layer 2 is accelerating.
Arbitrum leads with over 50% of the Layer 2 TVL market share, although ZKRUs have also made efforts. Arbitrum's first-mover advantage allows it to maintain its dominant position.
Analysis of daily transaction numbers shows that ZKRUs like zkSync and StarkNet slightly outperform OPRUs in throughput. However, Arbitrum's ecosystem advantages still exist, even though it lags slightly in daily TPS.
OPRUs have been around longer than ZKRUs. However, ZKRUs are launching their mainnets and attracting users from other ecosystems. As the leader in the OPRU space, Arbitrum is expected to combat 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 competitive pressures. With innovative solutions like Stylus, Arbitrum can complement its leadership position with unique technical capabilities and continue to lead 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 using programming languages like Rust, C++, and Solidity.
It opens up general computing to the blockchain and welcomes developers using different tech 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 executed natively at speeds 10 times faster or more than Solidity, significantly reducing gas fees. The EVM remains fully functional, so existing Solidity contracts continue to run as they do today. The two VMs operate in sync, allowing contracts written in different programming languages to call each other while also modifying the same underlying blockchain state.
Custom Precompiles
Additionally, Stylus supports custom precompiles.
Precompiles are low-level 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 SHA 256 hash computation.
Adding new precompiles requires all validators to coordinate an upgrade to the EVM, making it a high barrier. With Stylus, developers can easily deploy their own precompiles written in Rust or C++.
For instance, 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 super-fast native speeds.
Other contracts can call this Stylus "precompile" just like they would call native precompiles to leverage that cryptographic technology. All gas metering and fraud proofs will work automatically.
This enables teams to prototype custom cryptography, specialized pairing-based curves, and other new primitives without any special chain support. Ethereum researchers can even iterate on EIP proposals by deploying them as Stylus precompiles on Arbitrum.
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 EVM-supported functionalities.
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. This is not just about having two independent engines; it is a synergistic relationship that enhances the advantages of both.
Arbitrum's unique architecture allows for 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 compiled to WASM, such as Rust, C++, and C, the workflow is:
Developers use existing WASM compilers like Clang or Rustc to compile their smart contracts to WASM.
The WASM bytecode is uploaded to the Arbitrum chain in a compressed form.
The contract owner calls the
ArbWasmprecompile'scompileProgrammethod, which sets up security tooling for WASM, meters its gas costs, and compiles it to native code optimized for validator hardware.When the contract is called, it runs on a WASM runtime like Wasmer, which is much faster than the EVM, thus saving on gas fees.
WASM metering charges gas before each basic block, rather than charging by opcode like the EVM. This is more efficient and ensures that contracts do not run 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 may execute partially in the EVM and partially in WASM, with the results seamlessly combined.
Wait a minute, how can the 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 structures and state Trie. Contracts in one VM can read/write to the same locations in contracts 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 a result. If the EVM contract subsequently calls a WASM program, the WASM VM takes over to compute the result for that part.
Shared Context: System information like block data and sender addresses is available to both VMs. A WASM contract can access 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 across both VMs, ensuring appropriate computation costs and resources in either environment.
For fraud proofs, validators will bisect the execution in EVM and WASM 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 recognizing 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: an embedded DSL called AssemblyScript 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 has embraced WASM, it is essential 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
Ease of testing
High performance
Polkadot's WASM runtime features:
High performance
Interoperability with EVM
Platform agnosticism
Compact binary size
Simultaneous support for Rust and AssemblyScript (TypeScript style)
While Polkadot, Cosmos, and Arbitrum share some common advantages offered by WASM, each platform also has its 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
To understand the synergy between blockchain and WebAssembly (WASM), it is essential first to grasp what WASM is and the driving forces behind its development.
WebAssembly is a binary instruction format that enables code to be executed in web browsers at near-native speed. It serves as a compilation target for a variety of programming languages, including C and Rust, designed to be fast, efficient, and secure. WASM effectively bridges the gap between web-based and system-level programming, enhancing web performance and capabilities.
The "Web" in WebAssembly highlights its ability to run in JavaScript environments (typically found in browsers). In these settings, developers have full access to the WASM API and comprehensive support for web APIs, granting them considerable control over web behavior.
History of WASM
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 (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.
Various existing solutions were evaluated for their shortcomings:
System Virtual Machines
Frequent starts and stops incur excessive overhead
Lack of code visibility to ensure security
Performance demands are overly abstracted
Containers
Lack of code visibility to ensure security
Inefficiency due to high-level abstractions
Frequent operations incur significant overhead
Language-level Virtual Machines
Require frequent modifications to ensure security
Embedded VMs, like V8, are resource-intensive
Slow to adapt new languages to security models
Still overly abstracted
Instruction Set Architectures (ISA)
Difficult to effectively sandbox
Previous Google projects shifted from ISA to WASM
Lack of mature implementations
By 2018, WASM development gained momentum, focusing on running across 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, enabling cross-language interoperability. This allowed for solutions like writing an HTTP library once and using it across multiple languages.
To date, WASM boasts a range of features and is increasingly 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
A robust sandbox with memory and CPU limits
Extremely fast startup times, often within milliseconds or less
The WASM community continues to work towards greater integration and performance across languages.
Understanding the historical evolution of WASM provides 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 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.
While there are preliminary 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 issues.
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 cryptographic implementations, when building smart contracts. The main limitation for doing so is the associated gas costs.
While the Rust SDK is still in its early stages, both Rust and C SDKs have some missing functionalities. For example, the C SDK does not support ABI-exported functions, and modifiers are not yet supported in either SDK.
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 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 abstraction. Developing an entirely new DSL necessitates significant investment in toolchain and ecosystem development. In contrast, as a subset of general-purpose languages, eDSLs allow for easier integration with existing tools and have a lower learning curve. For example, creating an eDSL in popular languages like JavaScript or Python would be beneficial.
General-purpose languages require the use of SDKs, which introduces additional tooling, increases verbosity, and reduces the expressiveness of the code, accompanied by longer API calls and object manipulations.
Finding the right balance between language choice and eDSL development may be key to attracting a broader developer community while providing user-friendly tools. Current data shows that the top crypto developer community remains concentrated around Ethereum. However, platforms utilizing Rust for smart contracts, such as Polkadot, Cosmos, and Solana, are also gaining attention and rapidly growing within their developer communities.
Performance
WASM significantly improves execution speed and reduces package size. Although Stylus has not yet been deployed on the mainnet, benchmarks from other networks can serve as useful references. Observed execution times have improved by 4-8 times, and the compiled size has decreased by approximately 50%.
Stylus currently has size limits on its contracts, with an uncompressed upper limit of about 128 KB. This limitation makes it challenging to port large smart contracts from other languages (like Solidity). In the Stylus codebase, this limit is described as follows:
It is worth noting that WASM incurs some overhead during 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 trees, which aids in the interoperability of Stylus with the EVM. This is achieved through the EVM API implemented in WASM, using popular Host I/O patterns. A comprehensive list of supported EVM APIs indicates that interoperability is well-supported.
Custom Precompile Contracts
This aspect is particularly exciting as it represents uncharted territory. Custom precompile contracts have the potential to introduce additional cryptographic primitives on-chain at lower execution costs. They can also lower inference costs by introducing tensor computations as precompile contracts. However, there currently seems to be no existing code related to custom precompile contracts. While EVM components have precompile contracts, they are not hot-swappable.
This feature may still be under development, leveraging the capabilities of WASM. The EVM can call functions written in WASM and then compile them to machine code.
Reentrancy Feature
In contrast to CosmWasm (which adopts an Actor model without reentrancy features), Stylus's Rust SDK has reentrancy disabled by default as a feature flag. Developers have the option to manually enable this feature.
Activating the reentrancy feature will require some API adjustments. Developers need to be cautious, especially regarding security precautions like refreshing storage caches during calls.
Insights
Stylus opens up new use cases that are too gas-intensive when using only the EVM, such as high-performance cryptography, gaming, and AI. It also allows for custom precompile contracts, enabling developers to add their own cryptography and other foundational functionalities 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, which will help Ethereum and Arbitrum scale while maintaining interoperability with all existing applications.
Integrating Stylus into Arbitrum's Layer 2 SDK provides greater flexibility for third-layer developers. They can now move previously gas-limited intensive computations on-chain, opening up new possibilities. Developers are no longer limited to using Solidity; they can also choose Rust or C++ if those languages better suit their needs and expertise. Custom precompile contracts allow for the seamless migration of preferred cryptography, utilities, and other helper functions onto the chain for optimal performance. Writing low-level logic directly in a language suited to each use case will lead to smoother development. Developers can focus on core product features rather than resorting to 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, creating the most efficient user experience.
Stylus also demonstrates Arbitrum's capability for large-scale innovation and the integration of new virtual machines. Ed Felten, Co-founder & Chief Scientist of Arbitrum & Offchain Labs, mentioned that Arbitrum is developed based on industry-popular tools and programming languages. They can write tests more quickly and develop new features on top of the original system. OP has gone further down the path of ZK, gradually moving towards a hybrid Rollup approach. Optimism is currently collaborating with Risc 0 to generate zero-knowledge proofs for OPRU using Zeth. With this solution, Optimism does not need to make additional modifications to OPRU. If you're interested in Zeth, you can check out my previous Twitter.
We are very much looking forward to seeing AI applications on Arbitrum. Currently, performing machine learning on-chain is very gas-intensive, making development costly. Zero-knowledge ML can reduce costs but also brings significant additional complexity for developers. If we can implement tensor operations as custom precompile 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 allowing developers to quickly build and deploy ML algorithms as easily integrable precompile contracts using familiar languages (like Python), Arbitrum can drive the next generation of AI innovations in DeFi, GameFi, and beyond. The performance and flexibility of Stylus will enable 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.
