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
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 participation1 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.2 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.
- 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.3
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:
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.4 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.5
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.6
- Penalties for double signing (see the discussion of slashing below) are not proportional to the double signer’s stake.
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
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).
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.7 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.8
In Tenderbake, just as in Emmy*:
- Participation in consensus (both baking and endorsement) is rewarded.
- A delegate must have a minimal stake to participate.9 (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.
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 + 1represents the required threshold for agreement,10 and
7000is the value fixed for the total number of endorsement slots (see parameters
consensus_thresholdin the documentation).
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 present11 endorsers.
An endorser is considered present12 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
8192is the number of blocks per a cycle and
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!
Perhaps the network is running slow … ↩
… for instance, once the network outage passes. ↩
An offline baker is (as standard) considered to be a Byzantine baker — a Byzantine baker is one that, by definition, does not properly act according to the consensus algorithm, and the simplest way to not act according to the consensus algorithm is to not act at all! Whether this is by accident (poor network) or design (actively hostile to the network) is, from the point of view of designing a consensus algorithm, unimportant. ↩
See this discussion of the consensus parameters: “Since deposits are locked for a period of PRESERVED_CYCLES, one can compute that, at any given time, about ((BLOCK_SECURITY_DEPOSIT + ENDORSEMENT_SECURITY_DEPOSIT * ENDORSERS_PER_BLOCK) * (PRESERVED_CYCLES + 1) * BLOCKS_PER_CYCLE) tokens of all staked tokens should be held as security deposits. For instance, if the amount of staked tokens is 720,000,000 ꜩ, then roughly 8.74% of this amount is stored in security deposits.” ↩
The bottleneck here is the node. Each baking/endorsement event requires its own small deposit, which imposes its own small overhead. A node that is busy processing the I/O operations needed to update the data structure storing the security deposits, is a node with less time for validating its next block. ↩
A block’s payload is the sequence of non-consensus operations contained in the block. Preendorsements and endorsements contain the hash of the payload they refer to. ↩
Even if there are two blocks at the same level and round, honest bakers will (pre)endorse only one of them so safety is preserved. ↩
The reader might be familiar with the notion of
token_per_rollin Emmy* which was used to denote the minimal stake needed to participate in consensus. In Emmy*, rolls played a role in the computation of baking and endorsement rights. In Tenderbake, this is no longer the case because rights are computed from delegates’ stake. Thus rolls are only used to determine the voting power of a delegate. ↩
A block at level
l+1must include endorsements for a block at level
las a proof that agreement has been reached at level
l. These endorsements must correspond to at least two thirds of the total slots. ↩