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,
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.
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
implicit account will be significantly smaller than those for a
in order to better reflect the difference in computational costs
associated with signature verification when using the
p256 (tz3) cryptographic curves. See this
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
tz2 accounts1. 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.
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.
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 blocks2. 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.
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.
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
These observations arise from our experiments using the TPS benchmark tool distributed with the Tezos protocol and the Octez suite. See this earlier blog post for further detail on how to replicate this experiment. ↩
Unpacking the jargon: operations in Tezos are branched (that is, they reference) an earlier block hash. By “slightly in the future”, we mean consensus operations not branched in the predecessor of the target block (also known as the “grandfather block”) but rather on other close descendants. Then, a “cousin block” is a block who shares a grandfather with another block – usually the successor of a block proposal for a different round than the current mempool head. ↩