This page contains a summary of the changes brought by the Tenderbake merge request (!3738). Please refer to the documentation and to this blog post for an overview of the Tenderbake consensus algorithm and its motivation.
The whole incentives scheme has been updated. In particular the security deposit mechanism has been overhauled. See the documentation.
Rolls do not play an essential role anymore, in that the computation of delegates’ rights is based directly on the delegates’ stake. Snapshots are still used: it is the entire delegate’s stake that is snapshot. Rolls still play the following roles:
A delegate can participate in consensus (receiving baking and endorsing rights) if it has at least
A delegate’s voting power in the governance process is still in terms of rolls, as in Hangzhou.
Baking and endorsing rights are no longer independent of each other:
delegates that participate in consensus at a given level are called
validators in Tenderbake and validator rights in
Tenderbake are similar to endorsing rights in Emmy*. Baking rights are
deduced from endorsing rights: the baker at round
r is the
validator that owns the endorsing slot
The layout of the endorsement operations has changed. It consists of a level, a round, a slot, and a payload hash. A validator emits at most one endorsement per round, but can emit more endorsements per level; therefore, the current high-water mark mechanism used by the signer has been adapted (see Signer).
There is a new consensus operation, preendorsement, with the same layout as an endorsement.
There is a new anonymous operation, double preendorsement evidence, with the same layout as a double endorsement evidence.
There is a new manager operation, set deposits limit, which takes an optional positive integer argument. When the limit argument is given, the given limit on the signer’s security deposit is set. When the limit argument is not present, the previous limit is unset and no limit is imposed.
branch field of non-consensus operations is set by default by
the Octez client to
HEAD~2. Setting the
branch field to
HEAD~1 may result in the operation not being included
because it will not be anchored on a block belonging to the
chain. (The blocks at the current and previous levels are not
The block fitness (included in the shell part of the block header) changes, mainly to allow block candidates to be accepted by nodes.
The protocol part of the block header changes as follows:
it no longer contains the priority entry.
it contains two additional fields:
payload_hashis the hash of the sequence of the block’s non-consensus operations
payload_roundis the round at which the block’s payload has been first proposed (at the current level); it is equal to the block’s round in case of a fresh proposal and it is strictly smaller in case of a reproposal.
As in Emmy*, a block includes a set of endorsements for the predecessor block. These endorsements constitute a quorum and serve as a justification that the previous block has been agreed upon. In case of a reproposal, a block also includes a quorum of preendorsements for the same round to justify that the payload is indeed a reproposal.
The following protocol parameters have been removed:
blocks_per_roll_snapshot(it is replaced by
The following protocol parameters have been introduced:
baking_reward_fixed_portion= 10 tez
baking_reward_bonus_per_slot= 0.004286 tez
endorsing_reward_per_slot= 0.002857 tez
max_slashing_period= 2 cycles
double_baking_punishment= 640 tez
minimal_block_delay is reused to specify the duration of round 0.
The values of the following protocol parameters has changed:
tokens_per_rollhas changed from 8000 to 6000 tez.
The receipt of a block has a new field:
proposer, which is the
public key hash of the block’s payload
producer. Recall that the payload producer
may be different from the block producer, which is stored in the field
Previously, some internal transfers of tokens did not generate balance updates. Also, a credit balance update was not always balanced by a debit balance update. In order to make token movements easier to audit, we have remedied that by introducing new ‘kinds’ and ‘types’ of balance updates. Hence, balance updates in the metadata are now always balanced, i.e. the sum of credits is equal to the sum of debits.
The balance updates have been updated as follows:
The new balance categories
legacy_feescorrespond to the old
feescategories, and are only generated during migration (their
There is a new type of
simulationwhich is for internal use only (when a smart contract simulation run is performed via the RPC
originwill not appear in metadata during normal operation on mainnet.
The following new balance types have been introduced:
deposits, with the kind
deposits, and 3rd field
nonce revelation rewards, with the kind
nonce revelation rewards;
double signing evidence rewards, with the kind
double signing evidence rewards;
endorsing rewards, with the kind
baking rewards, with the kind
baking bonuses, with the kind
block fees, with the kind
storage fees, with the kind
double signing punishments, with the kind
lost endorsing rewards, with the kind
lost endorsing rewards, 3rd field
delegate, 4th field
participation(a boolean with value
trueif and only if the reward was lost because of insufficient participation), and 5th field
revelation(a boolean with value
trueif and only if the reward was lost because of unrevealed nonces);
liquidity baking subsidies, with the kind
commitments, with the kind
invoices, with the kind
The following new balance types are for internal use, they will not appear in the metadata during normal operation on mainnet, but may appear on test networks, or in sandboxed mode:
“bootstrap” with the kind
“initial commitments”, with the kind
“burned”, with the kind
“minted”, with the kind
The following balance types represent external sources of tokens that can only be debited : nonce revelation rewards, endorsing rewards, baking rewards, baking bonuses, liquidity baking subsidies, invoices, initial commitments, bootstrap, minted
The following balance types represent destinations of tokens burned that can only be credited : storage fees, double signing punishments, lost endorsing rewards, burned
The receipt for (pre)endorsement operations contains three fields:
balance_updates, which is always empty;
delegate, the signer’s public key hash;
(pre)endorsement_power, the number of slots the delegate had at the corresponding level.
The receipt for double preendorsement evidence operations has the same format as for double endorsement evidence operations.
The receipt for set deposits limit operations has one field: the
A more detailed documentation of balance updates is available here.
The following RPCs have been removed or renamed:
../minimal_valid_timehas been removed
../context/delegates/<pkh>/frozen_balance_by_cyclehas been removed
../context/delegates/<pkh>/frozen_balance, has been renamed to
../context/delegates/<pkh>/balance, renamed to
The following RPCs have changed:
Instead of an optional list of
cyclearguments, the RPC only takes one optional
max_priorityhas been renamed to
The output field
priorityhas been renamed to
Instead of an optional list of
cyclearguments, the RPC only takes one optional
The output is now grouped per level. For each level, the output contains the delegates’ rights and the estimated time at which the rights can be exercised. For each delegate that has some rights at the given level, the output contains the delegate’s public key hash, the delegate’s first slot, and the delegate’s endorsing power.
The following RPCs are new:
../helpers/round: gives the round of a block.
../helpers/validators: is a variant of
endorsing_rightsRPC, used by the Octez baker daemon.
../context/delegates/<pkh>/current_frozen_deposits: gives the current amount of the delegate’s frozen deposits, in contrast to
../<pkh>/frozen_depositswhich returns the initial amount (that is, at the beginning of a cycle) of the frozen deposits. The two amounts are different only when the delegate has been punished.
../context/delegates/<pkh>/frozen_deposits_limit: gives the frozen deposits limit of a registered delegate.
../context/delegates/<pkh>/participation: gives information on the participation (in consensus) of a registered delegate, as follows:
expected_cycle_activityindicates the number of endorsing slots the delegate is expected to have in the cycle based on its active stake. This number does not necessary equal the number of slots the delegate actually has, which are also dependent on the cycle’s seed.
minimal_cycle_activityindicates the minimal endorsing slots in the cycle required to get endorsing rewards. It is computed based on the
missed_slotsindicates the number of missed endorsing slots in the cycle so far.
missed_levelsindicates the number of missed levels for endorsing in the cycle so far.
remaining_allowed_missed_slotsindicates the remaining amount of endorsing slots that can be missed in the cycle before forfeiting the rewards.
expected_endorsing_rewardsindicates the endorsing rewards that will be distributed at the end of the cycle if activity at that point will be greater than the minimal required; if the activity is already known to be below the required minimum, then the rewards are zero.
The signer’s messages were of the form
<magic_byte><chain_id><block|endorsement> and are now of the form
the magic byte has changed from
0x01 for blocks and
0x11 for blocks,
0x12 for preendorsements,
0x13 for endorsements.
The high-water mark for blocks and (pre)endorsements is now given by both the level and the round of the signed block, respectively of the signed (pre)endorsement. The signer is authorized to sign whenever the level is strictly higher than the previous level, or the level is the same, but the round is strictly higher.
There is no endorser daemon anymore. Its role is performed by the baker daemon. The baker daemon takes the same options as in Hangzhou.
tezos-client bake for has been changed:
It takes a (possibly empty) list of delegate references. It then bakes a block and (pre)endorses this block, using the rights of all the specified delegates. When the list is empty is does so for all delegates whose secret keys are known.
It performs a full consensus round: it “proposes” a block (that is, it injects a block candidate), it preendorses the block, and it endorses the block, if possible.
The following commands have been added:
tezos-client propose for: forge and inject a candidate block (a proposal).
tezos-client preendorse for: forge and inject a preendorsement operation.
tezos-client endorse for: forge and inject an endorsement operation.
tezos-client set deposits limit for <src> to <deposits_limit>: sets the deposits limit for a registered delegate.
tezos-client unset deposits limit for <src>: remove the deposits limit of a registered delegate.