TL;DR: Transaction optimistic rollups are an experimental solution meant for short-term scaling and for adapting ecosystem infrastructure to work with rollups, while smart contracts rollups are under development.
With the Jakarta protocol proposal, the first step on the road towards scaling Tezos with optimistic rollups has been taken.
To quickly recap: Optimistic rollups enable higher throughput by moving the computationally demanding validation of transactions away from the main chain, Layer 1, to dedicated nodes, Layer 2.
This approach is far from new, but optimistic rollups do so while delegating consensus – the authority to determine the true state of the Layer 2 ledger – to Layer 1.
All data necessary to verify correctness of rollup activity remains available on Layer 1, along with an on-chain dispute mechanism for automatically correcting dishonest behavior by rollup nodes.
This way, optimistic rollups enable the use of powerful, centralized systems for validation of Layer 2 activity, while integrity is ultimately ensured by the security and censorship resistance of the Layer 1 protocol that hosts the rollup.
For a broader understanding of optimistic rollups and the rationale behind them as a scaling solution, we recommend our recent blog post on the topic.
TORUs as a stepping stone
Transaction Optimistic Rollups, TORUs, are the first implementation of optimistic rollups in the Tezos protocol. As the name implies, they allow for exchanges of assets, but not execution of smart contracts.
The purpose of TORUs is to
- Demonstrate Tezos’ ability to implement scaling solutions through protocol upgrades
- Provide a first implementation of optimistic rollups for ecosystem developers to start experimenting with
- Pave the way for smart contract optimistic rollups – a more advanced implementation, expected to be part of a protocol proposal later in 2022.
TORUs should be treated as a short-term and experimental scaling solution. For this reason, they are introduced with a sunset of 1 year. This can be changed in future protocol upgrades, should the community desire it.
A roll of tickets
A transaction optimistic rollup is an entity with its own address residing on the Tezos main chain.
The rollup holds assets that are deposited from – and that can be withdrawn back to – the main chain, Layer 1. These assets can be transferred across rollup-native Layer 2 addresses at a higher throughput than what is possible on Layer 1.
Deposited assets are represented as Michelson tickets in the rollup. These are a special type of tokens that were introduced in the Edo upgrade in 2021.
With FA2 tokens (Tezos) and ERC-20 tokens (Ethereum), you don’t actually hold the token in your account. Rather, each token has a centralized smart contract that acts like a bank, keeping track of how much your account holds.
Tickets change this. They are recognized directly by the protocol and can be passed around freely without interacting with a centralized smart contract. If traditional tokens are like a bank account, tickets are like an unforgeable dollar bill. As close to true ownership as it gets.
Besides this desirable property, using tickets has the benefit of simplifying the code when used in TORUs. For a deep dive on Michelson tickets, check out this blog post by our friends at Marigold.
Built to promote decentralization
Optimistic rollups on Tezos are implemented as part of the Tezos protocol directly, and not as smart contracts. This is often called enshrined rollups.
An immediate benefit is that it allows for a specialized, more gas- and storage-efficient implementation. For example, deploying a TORU is way less costly in terms of storage than deploying a smart contract of similar complexity. And as Tezos evolves with further upgrades, new features and optimizations can boost functionality and throughput of all enshrined rollups.
The way TORUs are integrated into the protocol makes them highly decentralized and facilitates broad participation. By design, they are
- Permissionless: Anyone can deploy a new TORU, and anyone can be a node operator for any existing rollup.
- Easy to use: TORUs are identified by specific addresses with the prefix txr1. Layer 2 addresses inside the rollup have the prefix tz4. Furthermore, the interface is designed to make interacting with rollups similar to interacting with a smart contract.
- Accessible: It is fairly simple to run a rollup node, which is a (experimental) daemon being developed as part of the Octez code-base. Once configured, it scans for rollup instructions in Layer 1 operations, executes the instructions, and posts a hash representing the updated rollup state to Layer 1.
TORUs on Tezos are not run by a single company or group of people. No one “owns” a smart contract containing the TORU. There’s no admin key. Once deployed, the network “owns” the rollup.
No rules can be applied other than the semantics of included operations. It’s not possible to prevent someone from depositing a ticket or from exchanging this ticket.
Rollup node operators also don’t decide which Layer 2 operations will be processed, or their order of processing, as this is determined by their inclusion in Layer 1 blocks. Any attempt at circumventing this will be neutralized by the Layer 1 dispute mechanism.
Using a TORU
Interaction with a TORU happens using the following workflow:
Depositing: Assets are sent to a Layer 1 smart contract which locks them and mints a corresponding Michelson ticket. The smart contract then sends a transaction containing the ticket and a recipient Layer 2 address to the rollup. It’s worth noting that such ticket minting contracts are not part of the rollup itself and should be seen as a trusted third party. We imagine NFT marketplaces and DEX’s integrating this feature, as some trust is already placed in their existing smart contracts by the users.
Transferring: Just as on Layer 1, a Layer 2 address is tied to a private key held by the owner, which is used to sign transactions. Instructions for the TORU – signed transactions – are included in Layer 1 operations, but only interpreted by dedicated rollup nodes scanning the blockchain for these.
Withdrawing: If the recipient of a rollup transfer instruction is a Layer 1 address, the rollup sends the ticket(s) to that address on Layer 1, though it will remain frozen until the dispute period is over. This period will be two weeks initially, but might be changed in the future. Once unfrozen, the ticket can be exchanged for the underlying asset with the smart contract that minted it.
Rollup users who also control a Layer 1 address can of course choose to interact with the rollup by including instructions for their Layer 2 address in Layer 1 operations themselves. However, we expect that most end users will interact with rollups via trusted third-party nodes that batch multiple Layer 2 transactions in a single Layer 1 operation. For example, a wallet provider might run a node that batches all Layer 2 transactions submitted by users of the wallet.
Such batching of transactions is an essential part of the efficiency of rollups. Through the use of BLS signatures, multiple transaction signatures can also be aggregated into one, which means even more Layer 2 transactions can be included in each Layer 1 block.
Why TORUs are experimental
It bears repeating that TORUs are an experimental solution. They should only be used by projects that are prepared to migrate to a different solution within a year.
The design chosen for TORUs allows for a simpler and faster integration of rollups, but has the side-effect that the maximum throughput of an individual TORU is capped at a lower level than required for long-term scalability.
A conservative estimate puts throughput for each individual TORU at 300-500 tps. Total throughput can be increased by running several rollups in parallel, but the design of TORUs means there is a hard limit imposed by Layer 1 blocksize at around 900 tps.
These numbers are however highly dependent on the ecosystem’s use of tools for optimizing rollup capacity, with aggregation of transaction signatures being a major factor. Potential Layer 1 block congestion is another factor.
All in all, TORUs should be seen as a short-term scaling solution and a way for the ecosystem to begin adapting infrastructure to working with rollups, while smart contract optimistic rollups, SCORUs, are being developed.
SCORUs are likely to eventually become the preferred solution for all rollup use cases, as they don’t just add smart contract functionality and other new functionality, but also are far more scalable in terms of throughput.
We will cover SCORUs in much more detail in future blog posts, as their inclusion in a protocol upgrade proposal approaches. Stay tuned!