We are pleased to announce that our protocol-R upgrade proposal is almost ready!
Before it is finalized, we invite bakers and the community at large to provide us with your feedback. This is partly to verify support for the proposed features within the Tezos community, which ensures a smooth governance process, and to allow for potential adjustments of the proposal based on community inputs.
It is also an opportunity to answer your questions regarding the proposed changes.
Taking into account the feedback requires time for performing a security and implementation analysis. The consideration of feedback is therefore divided into three phases:
- January 7 to January 17, 2024: Possible to provide feedback on both the definition of the changes and their parameterization.
- January 17 to January 24, 2024: Possible to provide feedback only on the parameterization of changes.
- January 24 to the proposal’s publication, expected mid-February 2024: finalization of the implementation of the proposal (background work for the technical teams)
Proposed changes:
- Cycle length is reduced to 1 day
We propose to adjust the number of blocks per cycle to make Tezos L1 cycle last approximately one day – or, more precisely, 10800 blocks.
The rationale behind this change is to improve the user experience of all Tezos users – bakers, stakers and delegators alike – by expressing Proof-of-Stake and consensus-related delays in friendlier time units, while also reducing them significantly.
A few resulting changes entail:
- The waiting period for finalizing an unstake operation (4 cycles) is reduced from ~11 to 4 days.
- New bakers will earn baking rights faster, as baking power will be updated daily.
- Attestation rewards will accrue daily.
- Adjustments to a baker’s staking parameters will become active after 5 days, instead of ~14 days.
- Similarly, the delay when (de)activating a consensus key on mainnet will be reduced from ~6 days to 2 days.
The proposed changes have no significant influence on the duration of the on-chain governance process. The protocol constant defining the length of governance periods is adjusted from 5 to 14 cycles, which translates to 14 days in ‘R’, compared to 14.22 days currently on Tezos mainnet.
Concretely, these changes entail adjusting the value of the BLOCKS_PER_CYCLE and CYCLES_PER_VOTING_PERIOD protocol constants. Meanwhile, certain other protocol constants that are expressed in cycles keep their current values. As a result of the shorter cycle duration, their duration will also be shortened.
| Constant | Description | Current value | Current duration | R value | R duration |
|---|---|---|---|---|---|
| BLOCKS_PER_CYCLE | Length (in blocks) of a blockchain cycle | 30720 blocks | 2.84 days | 10800 blocks | 1 day |
| CYCLES_PER_VOTING_PERIOD | Length (in cycles) of a governance period | 5 cycles | 14.22 days | 14 cycles | 14 days (Roughly unchanged) |
| CONSENSUS_RIGHT_DELAY | The number of cycles consensus rights are computed in advance. | 2 cycles | 5.69 days | 2 cycles (Unchanged) | 2 days |
| BLOCK_PRESERVATION_CYCLES | Minimal number of cycles that the node software should keep. | 1 cycle | 2.84 days | 1 cycle (Unchanged) | 1 day |
| DELEGATE_PARAMETERS_ACTIVATION_DELAY | Delay before changes to delegate staking parameters take effect | 5 cycles | 14.22 days | 5 cycles (Unchanged) | 5 days |
- New Baking and DAL attestation rewards model
The objective of this change is to make layer 2 – notably Etherlink – more scalable by making the DAL operational on mainnet. This requires at least 66% of the Tezos stake to run DAL nodes, and the ‘R’ proposal adapts rewards for bakers to reward DAL participation. It also introduces measures to punish dishonest DAL attestation behavior, in the form of slashing.
The proposal introduces the following changes:
– Allocation of a certain percentage of consensus rewards to DAL participation. A suggested percentage is 10%, but we would prefer to set it based on a consensus coming from this feedback round. We can also propose several variants of R, each with a different value for this percentage, and use the governance process for deciding.
– A minimum participation threshold. Bakers must attest at least 64% of the DAL slots in a cycle to receive DAL rewards for that cycle.
–Slashing of dishonest behavior. To ensure the integrity of the network, this mechanism detects and sanctions bakers that make attestations about DAL data they haven’t downloaded. Bakers proven to be dishonest can be penalized from 100 tez up to 0.10% of their frozen deposit per block.
– Participating in the DAL will be enabled by default, though a parameter will allow bakers to disable it. Bakers opting out would not be eligible for DAL participation rewards.
- Reduced tolerance to baker inactivity
In protocol proposal R, absent bakers would become inactive, and consequently excluded from consensus committees, after 3 days instead of 14 days. This will allow network health to recover faster in case of prolonged absence by a significant part of the total stake.
This is a consequence of the reduction of cycle duration to 1 day, as discussed above. The change introduces a new protocol constant, TOLERATED_INACTIVITY_PERIOD, which governs the length of the tolerance period before not-sufficiently-active bakers are marked as inactive.
Currently on mainnet, this period is defined to last 3 cycles. Given that consensus rights are known 2 cycles in advance, this entails that with protocol proposal R, absent bakers will be effectively excluded from the consensus committee after 3 days (3 cycles), instead of the current 14.22 days (5 cycles). The delay for re-activating a baker would also be shorter: 2 cycles, so 2 days, instead of 5.69 with Quebec.
| Constant | Description | Proposed value in R | Expected duration in R | Current value | Current duration |
|---|---|---|---|---|---|
| TOLERATED_INACTIVITY_PERIOD | Length (in cycles) of the tolerance period before insufficiently-active bakers are marked as inactive. | 1 Cycle | 1 day | 3 cycles | 8.53 days |
- BLS signature scheme (tz4) allowed for baking - Experimental: activated only on weeklynet running alpha protocol
BLS signatures enable a single consensus operation to represent all attestations for a block, rather than one operation per attesting baker. BLS is the only signature scheme that allows for such grouping.
This paves the way for a further reduction in block time, as well as simplifications such as rewards for stakers for each and every block, with no need to keep attesting rights.
On top of these features, bugfixes and performance improvements will be integrated to the proposal.
We value your inputs
As mentioned above, we encourage all bakers and community members to participate in this thread by asking questions, sharing their thoughts, and providing feedback on the proposed changes. Your input is invaluable as we finalize the proposal and prepare to announce that R is ready.
Thank you in advance for your contributions!
