This is a joint post from Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda & Functori.
With the Lima upgrade set to activate on Dec 19, at block 2,981,889, let’s look ahead to what’s next for Tezos. For our 13th upgrade proposal to come in 2023, we will journey from Lima in the Pacific to the gateway of India in the Arabian Sea: Mumbai.
There are 3 major innovations coming in the Mumbai upgrade proposal, in addition to other improvements. We recently wrote about how smart rollups are coming to Tezos, and with Mumbai they officially arrive. With the capabilities that Smart Rollups provide, the rails to reach 1 million TPS are in place. In addition, we are introducing Epoxy—our validity rollup (aka ZK-rollup) solution — on testnets. And lastly, Tezos is getting faster: we are reducing the block time to 15 seconds!
Smart Rollups activated
The activation of smart rollups in Mumbai is the result of an intense year-long undertaking. Smart rollups offer a powerful scaling solution for Tezos, allowing anyone to deploy decentralized WebAssembly applications with dedicated computational and networking resources. Smart rollups have been available on the Mondaynet testnet since the Lima proposal, but have undergone a number of significant improvements in their design and implementation during the development of Mumbai.
First, while in Lima each rollup had a dedicated inbox, in Mumbai there is only one global inbox shared by all rollups, which enables more use cases. Second, decentralized applications running on rollups can now retrieve information from a “reveal-data channel”, enabling access to data sources external to the inbox or even external to the Tezos blockchain. And third, smart rollups are forward compatible with the Data-Availability Layer (DAL), a data sharding feature that is in the works for improving scalability.
Epoxy: Validity Rollups on Mondaynet testnet
Validity rollups (also known as ZK-rollups) are coming to Tezos starting with Mumbai (in addition to Smart Rollups). This will be introduced gradually over multiple upgrades. Our implementation of validity rollups is named Epoxy, and allows for instant finality due to SNARK’s proof-of-validity, as opposed to the “refutation game” used by Optimistic Rollups. Epoxy allows for applications to be built on Tezos which do not necessarily need to rely on Tezos’ Layer 1 to publish and distribute data, but rather can implement their own data availability layers. This will enable building privacy-preserving solutions which require keeping sensitive information (reified as part of their state or transactions) private from the public Layer 1.
Epoxy will be soon available on Mondaynet and allows Tezos’ economic protocol to host new validity rollups written as circuits for the aPlonK proving system. The first instance that will be originated on Mondaynet is a transactional rollup handling tickets – that is providing a similar functionality to what TORUs do, but benefiting from instant validation.
Pipelining is fully deployed, giving us 15 second block times!
The validation pipelining project has been transforming the protocol’s internal business logic, and different milestones have been deployed with the Kathmandu and Lima protocol upgrades. Our end goal was clear from the start: streamlining the internal validation process without compromising the security of the chain.
Mumbai brings the final installment of this project, which delivers optimizations in the protocol by separating the validation from application of blocks and operations. This allows blocks and operations to be propagated faster, giving us confidence to reduce block times. With Mumbai, we halve the minimal time between blocks from 30s to 15s.
To summarize, in Kathmandu we first focused on applying this new validation discipline to manager operations—e.g. transactions and smart contract calls, which are the ones which consume the most resources. In Lima, we extended our scope to all operations supported by the Tezos economic protocol, and to how blocks are handled when nodes receive them. And now in Mumbai, pipelining is brought to the baker, so the block payload (smart contracts, etc.) is not executed before the proposed block is propagated—the block must only go through a lightweight validity check (see our previous discussions on pipelining for more details).
Since baking will only consist of sorting and validating selected operations and signing the block, the delay in block propagation is reduced significantly, giving us sufficient confidence to safely halve minimal block time to 15 seconds.
This is the second time Tezos reduces block times via on-chain protocol amendment. They were first cut in half from 1 minute to 30 seconds with the adoption of the Emmy* consensus algorithm, activated in Granada. And now with Mumbai, they are halved again to 15 seconds. We will continue to streamline the implementation of the Tezos economic protocol and the Octez suite to bring faster block times.
Other Improvements
-
Implicit account tickets: With Mumbai, implicit accounts can receive, store and send tickets to other implicit accounts and originated contracts. In the previous protocols, tickets could only be stored in contract/TORU storage or sent to other contracts/TORUs. With this upgrade, contracts may also send tickets to implicit accounts so that they can store and send to other entities later; or tickets can be exchanged between implicit accounts.
-
RPCs for ticket balances: We added two RPC endpoints to improve the visibility of ticket ownership.
-
<contract-id>/all_ticket_balancesendpoint that returns a complete list of tickets owned by a given contract by scanning the contract’s storage. It can only be used for originated contracts. In conjunction with the ticket update field in transaction receipt, this enables indexers to reconstruct a “global ticket table” that keeps track of all ticket ownership -
<contract-id>/ticket_balanceendpoint that returns the given contract’s balance of the ticket with specified ticketer, content type, and content. It can be used for implicit accounts, originated contracts, and rollups. This can be used to double-check ticket ownership.
-
-
New Michelson operations: First, we extended the Michelson opcodes
AND, OR, XOR, NOT, LSLandLSRto support logical operations onbytes. Their semantics are similar to those onnat. Second, we added an opcode to convert betweenbytesandnat.
Now it’s your turn
As it was the case in 2022, we are pushing to make 2023 a year of ground-breaking advances, and Mumbai brings to life the monumental work initiated in Kathmandu and continued with Lima. Of course, the technical advances in smart rollups and validity rollups (Epoxy) will only really show their power once new applications are built with them. So we encourage the Tezos developer community to build with these technologies and show everyone what is possible.
To learn more about Smart Rollups:
- The road to a million TPS (and beyond): Smart rollups are coming (blog post).
- Why the next generation of optimistic rollups are a game-changer for Tezos (blog post).
- Scaling Tezos with rollups (presentation by developers).
- Look to our blog for articles on Epoxy in the coming weeks.
Anyone interested in getting started with building a smart rollup node can reach out to contact@nomadic-labs.com.