Feedback Request for 'R' Protocol Proposal

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!

13 Likes

Allocation of a certain percentage of consensus rewards to DAL participation.

A minimum participation threshold. Bakers must attest at least 64% of the DAL slots in a cycle to receive DAL rewards for that cycle.

Does this mean a 10% cut for all bakers if DAL is not activated?

2 Likes

Question regarding DAL: how much does it cost to run it on a cloud VPS? What are the minimal requirements?

3 Likes

Can you elaborate on the system requirements for a DAL node? It has been mentioned that it would require a separate machine to operate safely. I understand that many bakers run in data centers but could someone explain how it might be achievable in a home baking environment?

4 Likes

I have quite a lot to say about this, but lets start with DAL slashing

Can you do full detailed explanation for DAL slashing?

Is there way this can happen by accident?

Is there any safe guards in place similar to baking?

How do you trigger this on testing?

Is there cooldown on that 0.10% frozen deposit penalty per block?

1 Like

I am not against running DAL overall, but it should NOT be run on any case at home as it leaks your ip

There needs to be solution to run it on seperate VPS on datacenter for home bakers

Reducing rewards by 10% if you are not running DAL is not the way to go especially if there is no way to run it safely now for those baking at home

There will be extra costs from running and maintaining DAL, proposed model does not generate anything for bakers to cover those costs

I also don’t like the idea of creating extra inflation for DAL as it is bad for the tokenomics. Best solution would be to take it from liquidity baking as we are massively overpaying for liquidity now

I would like to suggest that we take 33% of liquidity baking rewards and moving those to DAL to compensate costs. This way tokenomics stay intact are we are moving forward making xtz more scarce

I am also dissapointed that this proposal does not initially include anything for LB as community has been very vocal about it for months

Nomadic labs, Trilitech & TF you need to do better at listening the community

2 Likes

For bakers, it depends on the stake and of course of the cloud provider. For small (stake < 2%) bakers, a cheap ($15 per month) VPS is enough. See Hardware and bandwidth requirements for the Tezos DAL for more details.

3 Likes

We no longer advice against running the DAL node on the same machine. See Hardware and bandwidth requirements for the Tezos DAL - #4 by VincentPoulain.

6 Likes

This is not good enough. Do you mind giving proper explanation how it is good to run it at home?

There is no way around this. It is bad

Running DAL at datacenter on same machine is different story and can be okey if the person running it is proficient in security

I don’t understand what feature you are requesting. Have you tried running a DAL node on a VPS and plugging a home baker on it?

1 Like

Many of us baking at home are using tezbake and there is currently no support for this

I have not tried it as my understanding has been that it is not possible as of now

This proposed change is based on the following principle: both layer 2 and layer 1 are part of Tezos, and since layer 2 is enshrined in layer 1, it is up to the bakers to ensure its security and scalability (technical requirements to do so have been kept reasonable).

Therefore, the proposal actually consists of distributing the rewards between baking and DAL. The figure of 10% is intended as a starting point for discussion. As indicated in the post, we would prefer that this distribution be determined by the convergence of your feedback, or even by governance - we can submit several variants of the proposal, each with a different distribution key.

2 Likes

Hi - The Tezbake team are definitely working on it. Please see:

3 Likes

Yes, but that is only for local machine and does not support running dal on another device as far as I know

The configuration there is:

"configuration": {
         "BAKER_STARTUP_ARGS": [
             "--dal-node",
             "http://127.0.0.1:10732/"

You could point it at another machine (I guess running BakeBuddy on there too but just the DAL service).

3 Likes

“Setting up TezBake natively with the DAL is being worked on and will be available soon. For now, this guide explains how to run an all-in-one TezBake setup with the DAL process running separately from the TezBake processes, on the same machine or on a different machine within your network.”

Clearly says “within your network”

I’ve also talked to them and it is not possible as of now

Fantastic stuff! I like all the proposed changes :grimacing: :handshake:

For people wondering I am running a DAL node on a PI5 (with m2.nvme disk) without any issues :pray: :rocket:

5 Likes

We no longer advice against running the DAL node on the same machine.

Not providing advice does not guarantee that IP won’t be leaked. Similarly, stating that the risk is minimal does not mean it is acceptable to everyone.

(technical requirements to do so have been kept reasonable)

@VincentPoulain there are multiple ways to look at it, and from some, it definitely does not seem reasonable.:slight_smile:

1 Like

In principal I am all yay for R. A few thought.

  1. Having 1-day-cyles means paying out delegators more often leading to more transaction fees which could be an issue for small delegators earning only small rewards. Since payout of delegators is not a protocol topic, maybe payout tools can consider automatic batch payouts every x cycles to reduce.
  2. As far as i understood the probability of exposing the IP address is quite small. I do not understand how it would be possible at all. Maybe wen can get a more detailed risk-assessment, running a DAL node locally for the more concerned bakers?
  3. FYI I am running a DAL node on different machine than my baker but on my local network. The DAL runs on RPi4 with SSD with tezbake on my main machine
  4. regarding disabling inactive bakers: If I am on holiday and for whatever reasons my machine stops baking will I be deactivated after 3 days? That might be not enough time to react in such a case. Just to clarify, can I reativate myself after such an event?
1 Like

Technically, you will be deactivated after one cycle of inactivity. But, given that rights for the next 2 cycles are always set, you are evicted from the consensus committee of cycle n+3 onward – you won’t lose pre-computed rights/baking slots for cycles n+1 / n+2.

Yes, you need to re-register as a baker with e.g. octez-client register key <baking_key> as delegate or similar command for other software.

1 Like