Faster, Higher, Stronger: introducing the Paris protocol upgrade proposals!

This is a joint post from Nomadic Labs, Marigold, TriliTech, & Functori.

Following the successful activation of the Oxford 2 protocol on February 9th, we are pleased to announce that the Paris protocol proposals, Paris A and Paris B, are ready!

As usual their “true names” are given by their hash: PtParisA6ruu136piHaBC7cQLDP87JEqtczJWP2pLa5QCELGBH5 for Paris A and, respectively, PtParisBQscdCm6Cfow6ndeU6wKJyA3aV1j4D3gQBQMsTQyJCrz for Paris B.

Either proposal, if adopted, would bring the following major updates and improvements to the Tezos protocol, notably:

• Lower latency and faster finality with 10s block times without compromising decentralization or security.
• The activation of the Data Availability Layer (the DAL) on Mainnet, boosting throughput and scalability of Smart Rollups.
• Refinement to Tezos PoS, reducing the delays to acquire and update baking rights and simplifying their computation.

The two proposals differ regarding Adaptive Issuance, Staking, and Adaptive Slashing, a major overhaul of the fundamentals of Proof-of-Stake in Tezos:

• Paris B includes Adaptive Issuance, Staking, and Adaptive Slashing. That is, these features would be immediately enabled upon protocol activation.

• Paris A does not include these features. It offers bakers instead the possibility to vote for activating them later, via a a dedicated on-chain signaling mechanism.

In this article, we give a preview of the improvements described above and expand on the choices provided by both alternatives. Both proposals also include further minor improvements and other changes. A complete list of changes is provided in the Changelog.

10s block times bring lower latency and faster finality

As recently announced, the Paris protocol proposals reduce block time to 10 seconds, lowering latency and enabling faster finality, without compromising on decentralization.

This work builds upon previous foundations, like the adoption of the Tenderbake consensus algorithm and validation Pipelining, which led to halving block time to 15 seconds with Mumbai. In order to reduce block time further, the challenge was to identify and resolve remaining performance bottlenecks without compromising network safety and without forcing Tezos bakers to invest in expensive hardware.

It has always been our core belief that bakers should be able to participate in Tezos consensus with affordable, lower-end infrastructure. This is a core strength of Tezos that inherently impacts safety and decentralization, so we want to preserve it as Tezos evolves.

Based on our experiments, the following minimum specification is both affordable and performant enough to bake blocks on time:

• 3 CPU cores (arm64 or amd64/x86-64 architectures) – 2 are needed by the Octez node and 1 is needed by the Octez baker;
• 8GB RAM + 8GB swap (or 16GB RAM);
• 100GB SSD storage (or similar I/O performance);
• a low-latency, reliable broadband internet connection.

Please see our recent blogpost for a thorough, in-depth analysis of this work.

The DAL activates on Mainnet, boosting Smart Rollups capacity

The Data Availability Layer (DAL) is a foundational step towards ensuring Tezos’ long-term scalability and provides a massive throughput boost for Smart Rollups like Etherlink. It enables Tezos Layer 1 to attest the publication of data living outside Layer 1 blocks, increasing by orders of magnitude the bandwidth of data attested by the Layer 1.

After being tested live on Weeklynet, both Paris proposals enable the DAL on Mainnet — with opt-in (but warmly encouraged!) participation of Tezos bakers.

At its core, the DAL is a permissionless, peer-to-peer (P2P) network, running in parallel with Layer 1. Anyone can join the Tezos DAL and submit and retrieve published data.

Tezos bakers participate in the DAL by attesting the published data’s availability. Concretely, bakers can attest the data seen on the DAL P2P network by including a DAL payload in their attestation consensus operations (the extended format of these operations is retro-compatible, and will be supported by upcoming versions of Tezos baking app for Ledger devices).

Smart Rollups like Etherlink can now retrieve attested data from the DAL, allowing for higher throughput without decentralization trade-offs.

All participants, including Smart Rollup operators and Tezos bakers, engage in the DAL via the DAL node – which is released in the Octez suite as an executable binary called octez-dal-node. It caters to the needs of anyone wanting to engage with the DAL, allowing them to publish, store, and exchange data in the DAL.

Participation by Tezos bakers in the DAL is optional. However, published data is only considered attested if it has collected attestations representing at least 66% of the aggregated stake of designated bakers.

Therefore, to ensure the DAL becomes a successful foundation for a high-throughput Tezos ecosystem — baker participation is essential! Here are a few pointers to get started:

• Data Availability Layer (Octez and Tezos Protocol Docs)
• The Data Availability Layer (Tezos Docs)
• How to join the Tezos DAL as a baker, in 5 steps (Tezos Docs)

Adaptive Issuance, Staking, and Adaptive Slashing

Adaptive Issuance and Staking — only activated in Paris B — is a major overhaul of Tezos’ Proof-of-Stake mechanism, adapting the economics of tez to fit better with real-world usage, as argued in the Tezos Agora post “Why adaptive inflation matters for Tezos”, and to increase the chain security. This fresh new design is the result of a thoughtful rework of the initial one in the Oxford protocol proposal, based on both extensive testing, and feedback gathered from interactions with bakers, tooling and infrastructure providers, and other Tezos ecosystem members.

The Paris B proposal also introduce Adaptive Slashing, a refinement of the slashing mechanism that aims to distinguish innocent mistakes from deliberate attacks.

Paris A does not include Adaptive Issuance, Staking, and Adaptive Slashing (more on this below). In Paris A, these features are activated if a signaling mechanism is used by bakers.

Adaptive Issuance

The proposed mechanism ties the protocol’s regular issuance of tez to the ratio of staked tez over the total supply. In other words, the value of consensus participation rewards is no longer determined by fixed protocol constants. Instead, it is recomputed automatically at the end of each blockchain cycle, in order to nudge the staked fund ratio towards a protocol-defined target of 50%. When the ratio of staked funds decreases and diverges from the target, emission rates will increase, incentivizing participants to stake funds to re-approach the target, and vice versa.

Other rewards and incentives unrelated to staking are unaffected by the Paris protocol proposals, and their values remain set by fixed constants. Notably, the value of the Liquidity Baking subsidy remains a fixed amount.

The original implementation of Adaptive Issuance could cause abrupt fluctuations in participation rewards after the mechanism becomes active. Instead, the progressive min-max bounds mechanism implemented for Paris ensures that issuance rates change gradually over 6 months, smoothing the transition to the new system and allowing bakers to adjust fees progressively.

Staking

The Paris proposals introduce a new role — staker — in addition to delegate (baker) and delegator. Stakers contribute to their chosen baker’s security deposit without the baker taking custody of their funds, for which they are allocated a proportional share of rewards automatically by the Tezos economic protocol. Unlike liquid delegation, staked funds are frozen and are subject to slashing, in proportion to their contribution to their chosen baker’s deposit.

Bakers and stakers can modify or remove their stakes via an improved dedicated manual interface which replaces auto-staking and the set deposit limit operation. Changes in staked balances affect baking rights after 2 cycles. Unstaked funds become finalizable (they are unfrozen) after 4 cycles.

Bakers can configure their staking policy by setting parameters that explicitly state the desired limits to staking capacity, including the possibility of refusing third-party stakes. By default, delegates do not accept any funds from stakers.

To encourage staking over liquid delegation, staked and delegated funds have different weights in the computation of a delegate’s baking and voting powers: staked funds (their own and those from stakers) count twice as much as delegated funds.

The report from a recent live testing experience on Weeklynet provides several usage scenarios for bakers and stakers, and gives further insight into how to observe and analyze the impact of manual stake adjustments.

Adaptive Slashing

As stakers are subject to slashing if their chosen bakers misbehaves, the effect of penalties extends to more users. It becomes important then to differentiate between sporadic incidents arising from involuntary errors, from malicious, sustained attacks.

Adaptive Slashing refines the computation of slashing penalties for double-attesting blocks according to the total attestation power of those involved in double-attesting a single block.

If a low fraction of the total attesting stake is involved, this would result in the offending baker and stakers receiving moderate penalties. These increase smoothly as the greater the stake involved is until a critical level is reached (defined as one third of the total attesting stake). At the critical level (and beyond), bakers and stakers incur in the maximum penalty: being slashed 100% of their deposit.

See this design document for further detail.

Paris A, Paris B and feature activation

As we mentioned earlier, Paris B includes Adaptive Issuance, Staking, Adaptive Slashing while Paris A does not include them.

Paris A: the protocol proposal does not include Adaptive Issuance, Staking, and Adaptive Slashing. Instead, it offers the option to activate them later via a separate per-block voting mechanism, where bakers can signal for or against enabling these features. If net support stays above 80% over a long enough period, the feature activates. A similar vote to gauge baker sentiment has been running since Oxford 2 was activated, and we want to emphasize that the activation of Paris A would reset the current vote.

Specifically, the per-block voting mechanism enabled by Paris A works as follows:

• Bakers can vote for (On) or against (Off) the activation of the guarded features, and they can also vote Pass. Absence of signaling equals a Pass vote.
• Bakers’ votes are weighted by their staking power, as in the on-chain governance mechanism.
• The vote is driven by an exponential moving average (EMA) whose half-life is two weeks. That is, it takes two weeks for the EMA to rise from 0% to 50%, assuming only votes in favor are casted in favor in the period.
• Activation of the features requires the EMA to reach a supermajority of 80% On votes out of all On + Off votes. Pass votes are not counted.
• There is no time limit or quorum requirement for the vote
• If the EMA reaches the 80% On supermajority, an adoption phase of around two weeks (5 cycles) launches, after which the features are activated.
• There is no mechanism for deactivating Adaptive Issuance after the Adoption phase launches. Continued signaling is possible, but the EMA will have no effect on the status of these features.

Paris B: Adaptive Issuance, Staking and Adaptive Slashing would activate roughly two weeks (5 cycles) after the proposal is activated on Mainnet, without any additional vote (and regardless of the status of the currently active signaling mechanism).

Paris B offers bakers an opportunity to activate Adaptive Issuance, Staking and Adaptive Slashing right away, if they are already satisfied with the merits of the proposal and want to see it come to effect as soon as possible. Paris A allows the debate on the merit of the features (or lack thereof) to extend further, but comes of course with the opportunity cost of deferring their adoption if they are deemed useful.

Adaptive Issuance, Staking, and Adaptive Slashing would be active on Mainnet earlier with Paris B than they would be with Paris A, even after assuming that 100% of votes are in favor. Under such a scenario, the necessary inertia of the signaling mechanism implies a minimal time to activation of roughly 6 weeks after protocol activation. More conservative participation scenarios would entail delays of at least 6 months.

Further Proof-of-Stake refinements

Both Paris proposals implement further changes to Tezos Proof-of-Stake which are independent of Adaptive Issuance, Staking, and Adaptive Slashing. These changes allow for a simpler computation of baking rights, and reduce the length of a number of delay and grace periods in Tezos Proof-of-Stake. The updated values for the protocol constants governing these periods are chosen by taking into account Tenderbake’s deterministic finality, and the network’s current social organization.

One key change is shortening the consensus rights delay to 2 cycles – that is the wait period for newly computed consensus rights to take effect. This change propagates further to other periods and delays, notably:

• The delay for new or updated Consensus keys to become active is now 2 cycles.
• The grace period for baker’s inactivity period is now 3 cycles — plus 2 extra cycles for bakers that have just been (re-)activated.

See for further details on all changed constants.

Exciting times ahead

The Paris proposals are packed with features aimed at making Tezos faster, enabling higher throughput and standing on (even) stronger foundations.

We are quite proud of the proposal content, and the effort put into developing these features. If they are announced today, it is also thanks to the feedback from, and continuous exchanges with, tooling and infrastructure builders, bakers, and the Tezos community at large.

On that note, we would like to invite everyone to reach out to us on Tezos Discord for further questions and feedback. And stay tuned to the new #baking-announcements channel.

Let’s continue building a bright future for Tezos together.