Announcing Rio, Tezos’ 18th Protocol Upgrade Proposal

This is a joint post from Nomadic Labs, Trilitech, and Functori.

Following the successful activation of the Quebec protocol upgrade, we are happy to introduce the next upgrade proposal. Hello Rio!

As usual the “true” name of the proposal is its hash: PsRiotumaAMotcRoDWW1bysEhQy2n1M5fy8JgRp8jjRfHGmfeA7

The command to inject or upvote the proposal via the Octez client is:

octez-client submit proposals for <baking_key> PsRiotumaAMotcRoDWW1bysEhQy2n1M5fy8JgRp8jjRfHGmfeA7 --force

The Rio proposal seeks to improve Tezos’ scalability, staking experience, and network resilience. The main changes are:

• Adjusted rewards model: 10% of participation rewards are allocated to the Data Availability Layer, an essential component for L2 scalability and the Tezos X roadmap.
• Cycles are reduced to 1 day: Shorter network cycles mean that changes made by bakers, stakers, and delegators take effect faster. Notably, unstaked funds can be unfrozen after just 4 days instead of 10 days. This change does not affect the governance process.
• Lower baker inactivity tolerance: To improve the network’s resilience and reduce risk of slowdowns, inactive bakers lose consensus rights quicker, but can also regain them quicker.

Additionally, the proposal contains a minor fix of the gas consumption model. Gas fees for transactions between (implicit) user accounts were too low compared to the storage costs, and the fix increases these fees by 0.0002 tez. Transactions involving smart contracts are unaffected.

Below we expand on the main changes. For more details and additional minor changes, see the Rio proposal’s changelog.

Adjusted rewards model

The Data Availability Layer (DAL) is key to boosting the scalability of Etherlink and other Tezos rollups, and for realizing the Tezos X roadmap.

To promote a well-functioning DAL, the Rio proposal allocates part of the existing participation rewards to DAL activities. If Rio is adopted, the allocation will be the following:

• DAL rewards: 10%
• Consensus rewards, etc.: 90%

The DAL is only operational if at least 66% of the baking power participates. This impacts how the DAL rewards are distributed.

• If the 66% threshold is met: DAL rewards are distributed among bakers participating in the DAL. Bakers who do not participate forfeit their DAL rewards (10% of total rewards).
• If the 66% threshold is not met: DAL rewards are distributed among all active bakers, regardless of DAL participation.

The purpose of DAL rewards is partly to incentivize honest behavior by participating bakers, and partly to incentivize further baker participation, once the 66% threshold is reached. It is desirable to be comfortably above the threshold, as it ensures stable operation.

Bakers should be aware of the following:

• DAL participation is opt-out: In Rio, baking requires running a DAL node by default, but bakers can opt-out.
• Hardware and bandwidth: Our internal tests indicate that even bakers with low-spec hardware will be able to run the DAL node on their current setup without issues. To learn more, see our post on hardware and bandwidth requirements.
• Cycle minimum participation: A baker must attest at least 64% of the assigned DAL data in a cycle to receive rewards for that cycle (when the DAL is operational).
• Attestation check: DAL nodes can detect if another node makes attestations about DAL data it hasn’t downloaded.
• Dishonest behavior: Attesting dishonestly results in forfeiture of DAL rewards, but no slashing of stake.

For more information see the DAL documentation or our technical brief on DAL incentives.

See also our tutorial for running a DAL node and the FAQ below.

Cycles are reduced to 1 day

The Rio proposal reduces the network cycle length from around 3 days to 1 day – a quality of life improvement for bakers and stakers.

Besides the intuitive benefits of aligning cycle length with a more familiar time unit, shorter cycles also mean shorter delays before staking and baking operations take effect.

• Changes to staked/delegated balance are reflected by consensus rights after 2 days instead of 6 days.
• Unstaking can be finalized after 4 days instead of 10 days.
• Staking parameter changes activate after 5 days instead of 14 days.
• Consensus key activation/deactivation takes 2 days instead of 6 days.
• Attestation rewards are paid out daily instead of every 3 days.

Note that the governance process is unchanged, as the duration of a governance period is still 14 days.

The table below lays out the changes as proposed in Rio. In practice, some drift is expected due to occasional higher-round blocks, and all time values are approximate minimum values.

Lower tolerance for inactive bakers

Another change in Rio is stricter monitoring of baker inactivity.

Unresponsive bakers slow down the network, because their assigned blocks are not completed in the first round(s). To keep the network resilient and able to quickly adapt to bakers going offline, Rio contains the following changes:

• Inactivity: Bakers are marked as inactive after 2 days instead of 8 days.
• Reactivation: Bakers can return to active status in 2 days instead of 6 days.

A baker that is marked as inactive no longer receives consensus rights and must re-register as a baker to participate again.

Strong ecosystem involvement

We are grateful for the extensive feedback we have received from ecosystem stakeholders during the feedback rounds.

These early inputs have allowed us to better account for the experience of bakers, stakers, and other stakeholders when shaping individual features. Notable changes resulting from this feedback are:

• The tolerance for baker inactivity is slightly higher than initially proposed.
• New constants are exposed in the RPC endpoint.
• There is no slashing for dishonest DAL behavior (only forfeiting DAL rewards).

We also gained a better understanding of questions and concerns among stakeholders, some of which we address in the FAQ below.

This kind of feedback is invaluable to us, and we are happy to put forward a carefully refined proposal for broader community consideration.

Next steps

While the Rio proposal undergoes the governance process, we invite bakers and other stakeholders to join the ‘rionet’ testnet and run a DAL node.

A release candidate for Octez v22, which contains the Rio proposal as well as general improvements, will be announced soon.

Regardless of the changes contained in Rio, we generally encourage bakers to begin running DAL nodes on mainnet, as reaching the 66% DAL threshold is an important step on the road to Tezos X.

As always, we can be reached in Tezos Discord #baking channel for further questions and feedback.

Let’s go to Rio!

Frequently Asked Questions (about Rio):

Q: Do 1-day cycles mean more frequent payouts for delegation?

A: Not necessarily. Unlike rewards from staking which are distributed automatically, the protocol doesn’t define anything about paying out rewards from delegation. Any distribution of these rewards happens at the baker’s discretion, including the amount and frequency.

Q: Are DAL rewards shared with stakers and delegators?

A: DAL rewards are allocated and distributed the same way as other participation rewards. DAL rewards from staked funds are automatically added to the staked balances, while rewards from delegated funds accrue to the baker’s spendable balance. These will typically be paid out to delegators by the baker, unless the baker decides to treat DAL rewards differently.

Q: Why was 10% chosen for DAL rewards?

A: 10% was presented as a starting point for discussions during feedback rounds, and suggestions for alternative values were encouraged. The feedback did not show a general preference for a higher or lower value, and as a result 10% was chosen as the value to move forward with in Rio. As with other protocol parameters, it can evolve over time.

Q: Do bakers get a 10% cut in rewards if the 66% DAL participation threshold isn’t met?

A: No. The 10% allocation to DAL participation only has a noticeable impact on rewards when the 66% threshold is met. When the threshold is not met, the DAL rewards are distributed among all active bakers in proportion to their baking power.

Q: What’s the point of DAL rewards that effectively only kick in when the DAL is already operational?

A: The DAL is something we believe the ecosystem will welcome and support, and the intent is not to remove baker rewards if the DAL is not active. DAL rewards are meant to 1) incentivize honest behavior by DAL participants, and 2) push participation comfortably above the 66% threshold once the DAL is operational.

Q: Do DAL rewards affect the Liquidity Baking subsidy?

A: No. The Liquidity Baking subsidy is a protocol constant set to a fixed rate of 5 tez/minute. DAL rewards come out of the existing participation rewards (mainly for baking and attestation). It means they also vary based on the issuance rate defined by the Adaptive Issuance mechanism.

Q: Do you recommend running the DAL node on the same machine as the baker?

A: As long as the machine lives up to the DAL requirements, the DAL node can run on the same machine as the baker. Note that depending on network composition, there’s a small possibility that a DAL node’s IP address can be determined through its RPC endpoints. This could in theory be used for a Denial-of-Service (DoS) attack. We deem the risk of this very low compared to general risks of running public machines.