TL;DR: It’s not just about smart contracts and scaling. The next generation of optimistic rollups are a plug’n’play solution for running any software on Tezos.
This is a joint post from Nomadic Labs, TriliTech, Tarides, and Functori.
With the Jakarta upgrade and Transactions Optimistic Rollups successfully activated, it’s time to look ahead to the next major step in Tezos protocol development: Smart Contract Optimistic Rollups (SCORUs).
These next-generation optimistic rollups don’t just enable smart contracts. They are a platform for running any type of software, including emulating the Ethereum Virtual Machine (EVM), and having all computation made verifiable on the Tezos blockchain. That is a game changer for Tezos functionality.
As explained in the recent preview of the upcoming ‘Kathmandu’ protocol upgrade proposal, they will hit test networks soon, while mainnet activation is expected to be included in ‘L’ protocol upgrade proposal.
For a general understanding of optimistic rollups and the rationale behind them as a scaling solution for Tezos, check out our blog post on this topic. See also our blog post on Transaction Optimistic Rollups (TORUs).
Let’s jump in.
From transactions to general computation
Where TORUs have a fixed design focused on enabling higher transaction throughput while being highly decentralized, SCORUs can do whatever they are programmed to. Executing smart contracts is just one of many use cases. In fact, general computation optimistic rollups might have been a better description, but here we are.
For this, a different rollup dispute mechanism is needed.
TORUs are limited to transactions due to a simpler design of this mechanism. If a commitment published by a node operator is wrong, an honest operator can neutralize it by broadcasting a single L1 operation containing proof.
This one-step procedure means the proof must be small enough to be included in a single L1 operation, putting a limitation on the number and complexity of operations you can do between two commitments.
Smart contract rollups remove this limitation by using a different, more advanced dispute mechanism. Rather than being settled in one operation, it works as an interactive process between two rollup node operators.
This refutation game plays out over multiple rounds and Layer 1 blocks. The parties start broad and step by step narrow down the area of contention. When the exact point is found, and the required proof is small enough to be included in a Layer 1 block, the dispute can be resolved.
The bottom line: Interactive proofs remove the limit to the complexity of rollup operations that can be handled by Layer 1, opening the door for general computation.
| Transaction rollup | Smart contract rollup | |
| Functionality | Asset transfers (simple) | General computation (complex) |
| Who can be a node operator | Anyone | Anyone |
| User restrictions | None | Configurable at deployment |
| Admin rights | None | Configurable at deployment |
| Dispute mechanism | Single step (non-interactive) | Refutation game (interactive) |
| Operation complexity | Limited | Unbounded |
The rollup “computer”
To understand the design of SCORUs, think of a computer connected to a network.
The rollup itself is like an IP address on the network, through which users can access the computer “hardware” – a virtual machine run by rollup node operators.
The hardware has no inherent functionality. All functionality comes with an operating system that needs to be installed first. This we call a kernel.
A kernel can be an Ethereum Virtual Machine (EVM) emulation, enabling Solidity smart contracts. It can also be a simpler, single-application kernel that focuses on, e.g., transactions of assets. Or something completely different. As such, there are different ways to design a rollup “stack”.
| The Tezos rollup “stack” | ||
| Computer analogy | EVM rollup example | Transaction rollup example |
| Solidity smart contracts | ||
| Operating system | Kernel (EVM engine) | Kernel (Transaction engine) |
| Hardware | Virtual Machine (Wasm) | Virtual Machine (Wasm) |
| IP address | Rollup address | Rollup address |
| Network | Tezos blockchain | Tezos blockchain |
At the time of launch, we will make a simple kernel with transaction functionality similar to TORUs available for demonstration purposes. A proof-of-concept kernel in the form of a token exchange using BLS signatures will also be available. The latter is meant to be integrated with the in-development data-availability layer to demonstrate the next-level scaling potential of Tezos. We are also actively working on an EVM kernel, though with a release date that is yet to be determined, and a Michelson kernel is being researched.
As with an operating system, kernels can be updated or replaced at any time, though it depends on how the host rollup is configured. Staying with the server hardware analogy, these rollups come with a kind of boot sector which defines a number of its properties at the time of deployment, such as who can update the kernel, if anyone.
The Proof-generating Virtual Machine
With all this talk of hardware and operating systems, keep in mind that the whole point of rollups is to execute off-chain and verify on-chain.
Rollup operations are processed off-chain, on Layer 2, by dedicated rollup nodes. They continuously post commitments on the Tezos main chain, Layer 1, representing updates to the state of the rollup.
As it works with optimistic rollups, commitments are treated by default as correct but can be disputed within a given timeframe by anyone else running a rollup node. For those situations, a Proof-generating Virtual Machine (PVM) is implemented in the Tezos protocol. It’s a slightly modified virtual machine that can output a proof that operations have been processed correctly. The rollup node can use this implementation to produce a proof and post it to Layer 1, where it will be checked by the Layer 1 nodes.
This on-chain process is only activated when a dispute needs to be resolved, and only for a small execution step, once the exact point of contention has been pinpointed through a refutation game.
WebAssembly as the (initial) base layer
The first virtual machine, and PVM, for Tezos rollups will run WebAssembly, or Wasm – a low-level assembly-like language, which is well on track to become a standard for high-performance applications on the web. It’s designed as a compilation target for other languages, much like how desktop programs are compiled into a binary format.
Starting with a Wasm VM means Tezos will instantly be able to welcome a much larger developer community by supporting a number of popular programming languages. Notably C, C++, and Rust all have good Wasm-compilers. Support for blockchain specific languages like Tezos’ Michelson and Ethereum’s Solidity can be added through kernels or with new (proof-generating) virtual machines added in future protocol upgrades.
For integrating Wasm, we had the advantage that the reference interpreter of Wasm is written in the same language used for the Tezos protocol: OCaml! For any programming language, you need to specify how it works. One way to do this is to program a virtual machine declaratively – that is, in a way that makes it easy for others to understand how it’s meant to work by simply reading the code. That is a reference interpreter.
So we have been able to integrate the official definition of Wasm into Tezos – with some modifications enabling it to produce proofs about its execution.
Calling all builders
Some kernels will be provided by protocol developer teams, but we encourage ecosystem builders to start developing their own, innovative kernels.
For this we provide a native token bridge based on Michelson tickets, similar to the one used for TORUs, and a bare-bones execution environment supporting token exchanges between Layer 1 and Layer 2, interaction with Layer 1 smart contracts, gas monitoring, and self-governance.
We also provide safe Rust bindings to the Wasm PVM. The point is to let kernel developers think less about I/O on the blockchain, how blocks work etc., and instead provide an abstract layer that makes it more like working with files as in a standard computer program.
The kernel has access to the full state of the rollup (Layer 2), but any I/O with Layer 1 has to go through the rollups inbox/outbox, asynchronously. For this task, the bindings are like an API, so, for instance, if you want to send an asset from the rollup to a Layer 1 address, there’s a ready-made function for that.
With these bindings, developers can write a kernel, compile it to WebAssembly, and know that its interaction with the Tezos blockchain will be reliable and secure. We chose Rust because it is a popular language with a mature toolchain providing robust compilation to Wasm.
Opening up Tezos
With this design of optimistic rollups, Tezos opens itself up to interacting with all kinds of software systems and making their operation verifiable on the Tezos blockchain. This puts Tezos solidly at the forefront of blockchain technology.
Wasm establishes a highly flexible and future-proof base layer that doesn’t exclude support for currently popular execution environments like the EVM, or the well known security-focused environment of Michelson, while still inviting Rust and C/C++ developers on board.
Each rollup will be highly configurable, and will have governance modules for kernel upgrades. In this sense, a rollup will offer everything that parachains, subnets, app-chains and similar scaling solutions used by other blockchains do.
The difference from most of these is that rollups on Tezos offer all that while being secured by a time-tested, highly decentralized and censorship resistant Layer 1: the Tezos main chain.
We believe this to be the future of blockchains, and we are excited to be building it with the Tezos community!