Enter Mumbai — Why It's Significant

A closer look into the Mumbai protocol and why it’s potentially one of the most significant protocol upgrades to take place on Tezos yet.

Originally published at Tezos Commons News

By William McKenzie


1,100 words, 6 minute read

Enter Mumbai  Why Its Significant image 1

It goes without saying that 2022 was the year for development within the Tezos ecosystem. Shortly after the year began, the long awaited plans for scaling were introduced by Nomadic Labs.

Fast forward to today, scaling is moving at a rapid pace with protocol Mumbai. Let’s dive into some of the features and dissect why they’re significant.

Enter Mumbai #

Enter Mumbai — Why It's Significant, image 2

The Mumbai proposal and the road to 1 million transactions per second (“TPS”)is coming.

Recently, we were treated to a sneak peek at some of the features for the upcoming Mumbai protocol upgrade from Nomadic Labs. As we move further towards the mass scalability plans announced earlier in 2022, Mumbai is aiming to take it a step further.

Protocol Mumbai will introduce the following features:

Let’s quickly go over some of the features and why they’re significant.

Smart rollups will allow anyone to deploy decentralized WebAssembly applications with dedicated computational and networking resources. They have been in use on testnet. With Mumbai, additional design and implementation improvements are being made.

Per Nomadic Lab’s blog post, they detail some of the improvements.

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.

Next, ZK rollups (validity rollups) are also being introduced and will be rolled out gradually over several upgrades. The first implementation known as “Epoxy”, will allow for applications to be built on Tezos which do not necessarily need to rely on Tezos’ Layer 1 to publish and distribute data. It will enable the building of privacy preserving solutions which rely on keeping data sensitive.

More information on this feature will be shared in the coming weeks, so stay tuned for that.

Tickets are getting some improvements. In case you’re unfamiliar with tickets, this feature was introduced in the Edo protocol upgrade. The unique feature of tickets is that they contain the address of the contract they come from. This in turn, allow many use cases such as simplifying tokenization contracts and ensuring that access rights can be transferred simply outside of a given contract to name a few.

With Mumbai, implicit account tickets and RPCs for ticket balances changes are being introduced. For implicit accounts, they will now be able to receive, store, and send tickets to other implicit accounts and originated contracts. Additionally, two RPC endpoints will be added to improve the visibility of ticket ownership.

Shorter block times! #

Why are you not staking your tez anon?, image 2

A little while back, we were first introduced to validation pipelining in the Kathmandu upgrade.

Gabriel Alfour shared some insight in our blog post.

The basic idea with pipelining is that right now, block producers send blocks in their entirety. Then, when consensus nodes receive these blocks, these nodes execute the blocks in their entirety. The reason behind this is that right now, nodes have to agree on the state of Tezos literally after processing each block, and so you need to execute the blocks to know the resulting state hash.

The problem with that is it slows consensus a lot. There is no reason to wait for the block to be executed before performing consensus operations (spreading blocks, voting on a block, etc.). You can and should be able to do both in parallel. So, that’s the main idea of pipelining. The goal is to have block verification done in parallel with consensus. In the best case, this can result in blocks that are 2 times faster.

In the real world, I’m not sure how much this will help but it will reduce the loads of the nodes on the network. Basically, it’s a free gain. It’s an optimization for Layer-1 and it doesn’t sacrifice anything.

This work will continue into protocol L as well, where we’ll see most of the benefits from the speedups.

Protocol Lima took this a step further, per Nomadic Labs blog post.

The Lima protocol proposal extends pipelined validation to all remaining classes of operations, and to blocks themselves. When receiving a new block from its peers, a node will only check the validity of the block before forwarding it to other peers, speeding up block propagation on the network. Afterwards, the node will then apply the block.

The upcoming step will be to extend pipelined validation to block production itself, reducing the effort (and hence time) required for bakers to propose new blocks. Along with further upcoming optimizations, this opens the door to reduced block times.

With Mumbai, the final installment of these efforts towards pipelining is being made. This will allow block times to get reduced in half from 30 seconds to 15.

Nomadic Labs detailed this in further length on their blog post.

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).

This will be the second time Tezos reduces its block times via its on-chain governance. The first being witnessed in protocol Granada with the activation of Emmy*.

Tezos’ technical evolution is worth taking note.

Looking Forward #

Enter Mumbai — Why It's Significant, image 4

There’s a whole lot to be excited about in terms of development this year for the Tezos ecosystem. With 3 major features all geared towards scaling in the upcoming Mumbai protocol, the long awaited 1M TPS figure may not be such a stretch in the foreseeable future. Be on the lookout for more information on the features as injection nears!