July 21, 2023

Stylus in Action: Unleashing the Power of Arbitrum's Fraud Prover - Part 2

The Balance Ecosystem encompasses a wide range of innovative products and developments in various DeFi and Web3 technology areas.
Balance is poised to build bridges between the theoretical and practical sides of finance so that there is a means in which we can provide real-world solutions and create value driven products within the web3 space.

Balance Capital

In Part 1 of our article, we explored the introduction of Stylus, a revolutionary programming environment and WebAssembly (WASM) virtual machine integrated into Arbitrum's tech stack. 

Stylus enables developers to deploy contracts written in various programming languages, including Rust, C, and C++, alongside EVM contracts on the same chain. In Part 2, we will delve into the technical aspects of Stylus, discussing its lifecycle, from coding and compilation to execution and proving. Let's dive in!

Coding Stylus Contracts

The magic of Stylus begins with writing smart contracts using programming languages that can be compiled into WebAssembly (WASM). 

Initially, Stylus offers support for Rust, C++, C, and "BF" (Brainfuck). For example, we'll take a look at a cryptographic primitive, secp256r1, implemented in C. Stylus-supported languages include an "Ethereum API," which allows developers to access EVM-specific functionality similar to Solidity. This ensures that virtually anything achievable in Solidity can be replicated in Stylus, preserving full EVM equivalence.

For cryptographic purposes, reference implementations are often written in C, so we'll use C compatibility to deploy a secp256r1 signature verifier without any modifications. 

Below is an example of the Stylus contract code:

(Contract code for Rust version was also deployed using the p256 crate.)

Compilation of Stylus Contracts

The compilation of a Stylus program involves two steps:

a) Off-chain Compilation: Developers compile the code off-chain using any standard WASM compiler. In this case, our contract is written in C, so we'll use Clang. The compiled WASM code is then posted on the Arbitrum chain in a compressed format, defining the contract's behavior deterministically. However, at this stage, the contract cannot be called, as calls will simply revert.

b) On-chain Compilation: Users interact with ArbWasm, a new precompile for managing user programs, and call the compileProgram method. This step lowers the WASM to the native assembly of each Arbitrum node's hardware, producing an efficient executable tailored for their specific environment. 

Additionally, this step instruments the WASM to guarantee safe execution and deterministic fraud proofing within Arbitrum's VM. Instrumentation includes gas metering, depth-checking, memory charging, and other mechanisms to ensure computational resources are paid for and results are universal.

The key difference between Stylus and Nitro at this stage is that Stylus enables running arbitrary "untrusted" WASMs, whereas Nitro relies on a specific, trusted WASM (nitro-geth) for proving fraud.

Execution of Stylus Contracts

Stylus contracts are executed using Wasmer, the premier WASM runtime. Executing native code via Wasmer is significantly faster than executing with Geth, leading to notable gas savings compared to equivalent operations in the EVM. Nitro's EVM-style contracts continue to be executed in the same EVM-equivalent manner as they are currently. The system identifies whether a contract is EVM or WASM-based via a special contract header, and then executes it using the corresponding runtime, either nitro-geth or stylus-wasmer. 

Stylus and Nitro contracts are part of the same state machine, allowing them to access and modify the same state trie and make cross-contract calls to each other. The developer doesn't need to consider the language of the called contract; interoperability is seamless.

Proving Fraud with Stylus

The Stylus proving model builds upon Nitro's fraud prover, "Arbitrator." Just as validators bisect over Geth's execution history for Nitro contracts, they now bisect over user programs' execution. Thanks to the instrumentation during compilation, this process guarantees the termination and determinism of fraud proofs. Validators identify a single invalid opcode after a logarithmic-bounded number of steps, whether it belongs to Geth or a novel user WASM.

Excitingly, a complete, working fraud prover for Stylus has been developed. This includes proving fraud over all the functionality described in this article. The team is now focusing on language features, tooling, efficiency improvements, and finalizing pricing.

Conclusion 

Stylus marks a significant milestone in layer 2 smart contract development, introducing a versatile and efficient programming environment for developers. The combination of EVM contracts and WASM-based contracts in Stylus opens the door to new possibilities. The future of Stylus is promising, bringing us closer to the realm of EVM+ and fostering innovation within the Ethereum ecosystem.