Announcing Nairobi, Tezos’ 14th protocol upgrade proposal

This is a joint post from Nomadic Labs, Marigold, TriliTech, Oxhead Alpha, Tarides, DaiLambda, & Functori.

Following the successful activation of the Mumbai protocol upgrade on March 29th, we are happy to unveil our latest Tezos protocol proposal, Nairobi.

As usual, Nairobi’s “true name” is its hash, PtNairobiyssHuh87hEhfVBGCVrK3WnS8Z2FT4ymB5tAa4r1nQf.

The Nairobi protocol proposal contains several updates and improvements to the Tezos economic protocol, the most prominent being:

• An up to 8x increase in TPS for certain manager operations (including tez transfers and smart contract calls).
• Improved gas model for signatures to reflect the cost of different curves.
• Renaming endorsements to attestations.
• Faster propagation of pre-attestations to reach consensus earlier.
• New host functions for Smart Rollups, and new internal Layer 2 messages allowing rollup kernels to be aware of Tezos protocol upgrades.

In this article, we give a preview into the improvements described above. More in-depth descriptions can be found in Nairobi’s technical documentation. This protocol proposal includes further minor improvements and other changes – a complete list is provided in the protocol proposal’s Changelog.

Increased TPS thanks to a finer-grained gas model

Currently, the gas cost of signature verification for manager operations is a flat-tax constant, which over-approximates the required resources. With Nairobi, their cost depends on the cryptographic curve used and the size of the payload.

For instance, the gas cost of checking the signature of a tz1 or implicit account will be significantly smaller than those for a tz3, in order to better reflect the difference in computational costs associated with signature verification when using the ed25519 (tz1) and p256 (tz3) cryptographic curves. See this entry in Nairobi’s Changelog for further detail (including breaking changes).

Thanks to this finer-grained accounting of the gas costs for signature verification, the maximum number of manager operations (transactions, smart contract calls, Smart Rollups maintenance operations, etc.) that can be included in a block has increased by a factor of about 8.

Consequently, we observe a similar 8x increase in performance for certain common operations, such as basic tez transactions between tz1 or tz2 accounts¹. For smart contract calls the number will be lower, and operations involving ‘tz3’ accounts will see no increase due to their more computationally demanding signature scheme.

Renaming Endorsements to Attestations

The term “endorsement” might incorrectly convey the idea that bakers (validators) approve of the contents of a block – that is, of the transactions and other operations chosen by the payload producer – even though in reality they are merely attesting that a valid block has been produced. Moreover, ongoing work towards a Data Availability Layer will change the behavior of consensus operations in a way that makes the term “endorsements” less fitting.

We propose thus to rename endorsements into “attestations” – a more precise term, which reflects better past, present, and potentially future semantics of these consensus operations.

With this protocol proposal, we begin this process by launching the deprecation of the endorsing_rights RPC endpoint, introducing attestation_rights as a replacement. This symbolic step is not breaking, as both old and new names would be available if Nairobi is activated on Mainnet. In future protocol proposals, we intend to go beyond symbolic steps though, and may have to introduce breaking changes in API names – which will be communicated with ample notice.

Fine-tuned validation pipelining for faster consensus

In order to keep Tezos consensus both live and fast, it is paramount to ensure consensus operations are validated and propagated swiftly – especially after Mumbai halved block time from 30 to 15 seconds on Mainnet. To this end, this protocol proposal fine-tunes its Mempool module, which implements the business logic used by the Octez node’s to validate operations in the mempool.

With Nairobi, an Octez node’s prevalidator would initialize mempool validation faster, and it would moreover accept consensus operations that are slightly in the future or branched in cousin blocks². As a result, the node can immediately propagate pre-attestations for blocks which have just been validated but which have not yet been applied. Consequently, bakers participating in a consensus committee would be able to communicate their votes in the pre-attestation voting phase faster, which should lead to reaching consensus earlier on block proposals.

Continuous Improvement of Smart Rollups

Tezos is the constantly evolving blockchain so it is only fitting that Smart Rollups, its general-purpose Layer 2 solution, follow the same path.

This new protocol amendment, if deployed on Mainnet, will enable additional host functions for all Smart Rollups. Nairobi also introduces a new kind of Layer 2 internal message which allows to broadcast to all originated rollups the activation of new Tezos protocol upgrades on Layer 1.

Buckle up, ‘Nairobinet’ test network will launch soon

Note that if Nairobi is voted in by the community, upgrading to Octez v17.0 (or later) will be necessary for participating in consensus.

In order to allow the community to start testing the Nairobi proposal as soon as possible, a release candidate for Octez v17.0 will be published in the coming days, and a dedicated protocol test network Nairobinet is also scheduled to begin soon. More information about this test network will be available on https://teztnets.xyz/.

Read more about Tezos test networks here, and don’t hesitate to reach out in the Tezos Developer Slack or in the Tezos Discord if you need help getting started.