Tenderbake has been injected

You may recall from earlier this year our in-depth discussion of Tenderbake, our new classic-style consensus algorithm that offers quick and deterministic finality and safety under asynchrony.

Since then, and in collaboration with Functori, we have prepared Tenderbake for inclusion in the next Tezos protocol upgrade proposal Ithaca. A big thank you to the incredible and amazing Functori for their incredibly amazing collaboration!

In this post, we will complement our previous discussion of Tenderbake with a recap of some practical aspects of the new consensus algorithm: what does Tenderbake mean for you, how can you use it, and what benefits will it bring? We will overview the most important points here, and you can find further details in

• the full Tenderbake documentation, and
• the Tenderbake changelog.

Overview

Recall that when determining which block to add to the blockchain, Tenderbake proceeds in rounds, starting from round 0:

• If there is enough timely participation at round 0, then consensus is reached and a decision is made.
• If there is not enough timely participation¹ at round 0 then we go to round 1, and so forth.

Provided that at least two thirds of the total active stake participates honestly in consensus, then a decision is eventually taken.² In the current implementation of Tenderbake the duration of each round increments by 15 seconds, starting from 30 seconds: thus the deadline for participation in round 0 is 30 seconds, that for round 1 is 45 seconds after that, and so on. So in normal conditions, when consensus is reached promptly at round 0 every time, we can expect Tenderbake to add one block every 30 seconds.

Note that:

• Tenderbake has deterministic finality after just two blocks. In normal conditions, when the network is healthy, decisions are made at round 0, after 30 seconds. This means that in normal conditions the time to finality is about one minute.
• Finality is guaranteed under an assumption that at most one third of the active stake is Byzantine (a Byzantine participant is one that is either offline and so unresponsive, or responsive but not following the rules). This is a standard assumption, but it does have the corollary that the chain will halt if more than one third of the active stake is offline.³

Speaking of bakers — baker daemons now endorse as well. Indeed, Tenderbake bids farewell to the concept of endorser daemon from the Emmy family of consensus algorithms which Tezos has used to date. Goodbye endorser daemon; thank you for the years of service!

The baker also emits a new kind of consensus operation called a preendorsement.

Aside from the new kind of consensus operations, there are changes to the block metadata and RPCs, so Tezos tool developers — for example, developers of block explorers and indexers — are invited to check the metadata and RPC changes so that their tools can be seamlessly updated.

Finally, there are notable improvements to the incentives mechanism, which we describe next:

The incentives mechanism

The deposit scheme

In Emmy*

In Emmy*, each time a delegate wants to bake or endorse, it must put down a deposit as a guarantee of honest behaviour. That is: in Emmy* there is a deposit for each individual baking and endorsement action, which is computed such that security deposits are around 10% of the total stake.⁴ Double signing in Emmy* is penalised by forfeiting the entirety of the deposits made by the delegate during the cycle when the double signing was made.⁵

This design has some drawbacks:

• If a delegate becomes over-delegated (meaning that their stake is not sufficient for their required deposits) then this may lead to the delegate missing slots and thus slowing down the chain.
• Handling deposits requires I/O operations. This imposes communication and computational overheads, which may slow down block validation.⁶
• Penalties for double signing (see the discussion of slashing below) are not proportional to the double signer’s stake.

In Tenderbake

Tenderbake takes steps to address the issues above.

In Tenderbake’s new deposits scheme, delegates still need to put down deposits as a guarantee against double signings, but this deposit is now based on the delegate’s stake rather than on individual baking/endorsement actions. Deposits are frozen when baking and (pre)endorsement rights are allocated to stakeholders, five cycles in advance.

The deposit amount is determined by the stake a delegate has during the so-called active cycles: two cycles in the past and five cycles in the future. To be precise, a delegate’s frozen deposit at cycle c is 10% of the highest stake during cycles c-2 to c+5.

Delegates can put an upper limit on their deposit by using the client command set deposit limit. In particular a delegate can set this limit to zero, and then the delegate will lose its baking rights in 7 cycles. To be able to bake again, the delegate would have to reset the deposits limit or simply unset it (with the client command unset deposit limit).

Slashing

In Tenderbake, we say a delegate double signs when it bakes or (pre)endorses two blocks at the same level and round, but with different payload hashes.⁷ Double signing is penalised by slashing (forfeiting) a part of the delegate’s deposit:

• Double baking is penalised by slashing 640 ꜩ (or the whole deposit, if less than 640 ꜩ).
• Double (pre)endorsement is penalised by slashing half of the deposit. This means that a wrongdoer who double (pre)endorses twice during a single cycle will lose their entire deposit, and thus lose baking rights for the rest of the cycle.

These penalties reflect the relative severities of double baking versus double (pre)endorsement: double baking must be penalised because it wastes resources, but double (pre)endorsement could fork the chain, which would be much more serious.⁸

Rewards

In Tenderbake, just as in Emmy*:

• Participation in consensus (both baking and endorsement) is rewarded.
• A delegate must have a minimal stake to participate.⁹ (The minimal stake for becoming a baker is 8000 ꜩ in Emmy* and 6000 ꜩ in Tenderbake.)

However in Tenderbake, baking rewards and fees can be dispensed immediately, thanks to the new deposit scheme.

The block, its payload, and baking rewards

In Tenderbake we distinguish between the payload producer and the block producer:

• The payload producer is the baker who selects the non-consensus operations to be included in the block; we refer to these operations as the block’s payload.
• The block producer is the baker who signs the block.

The payload producer is typically the same as the block producer — but not necessarily! For instance, if consensus is not reached within a given round and the baker has committed to the block proposed at the given round by endorsing the proposed block, then it might be that at a later round the baker is forced to propose a block with the same payload. In such a case the payload producer may differ from the block producer.

Given this separation:

• Operation fees as well as a fixed baking reward of 10 ꜩ go to the payload producer, because the payload producer selected the operations.
• A bonus for including endorsements above the required threshold goes to the block producer, to incentivize him/her to play fairly.

To be precise, a block producer who includes endorsements corresponding to x extra endorsement slots receives a bonus of 0.004286 * max (0, x - 4667) ꜩ, where

• 4667 = 2/3 * 7000 + 1 represents the required threshold for agreement,¹⁰ and
• 7000 is the value fixed for the total number of endorsement slots (see parameters consensus_committee_size and consensus_threshold in the documentation).

Endorsement rewards

Endorsement rewards are distributed at the end of each cycle, because only endorsers actively participating during the given cycle are rewarded. Such actively participating endorsers are known as present¹¹ endorsers.

An endorser is considered present¹² when the number of slots corresponding to its endorsements which are included in blocks is at least two thirds of its total slots during the cycle. Therefore an endorser may be rewarded even if some of its endorsements are not included.

A present endorser is rewarded proportionally to its stake, and not proportionally to its allocated slots. To be precise, a present endorser with x percent of the total active stake during a cycle, is rewarded with 0.002857 * x * 8192 * 7000 ꜩ where

• 8192 is the number of blocks per a cycle and
• 7000 is the consensus_committee_size mentioned above.

Happy Tenderbaking (remember to update!)

Please remember to update to the latest version of Octez — otherwise, your baker might end up being a Byzantine baker simply by virtue of running out-of-date software, and nobody wants that! You can learn more about Tenderbake in the full documentation and changelog.

That’s it! Stay tuned for another blog post on testing Tenderbake. Until then, we wish you all the best for the New Year: may all your chains reach prompt and productive consensus!