Proof-of-stake#
Overview#
The consensus algorithm in Tezos is based on the proof-of-stake mechanism. Proof-of-stake means that participants in the consensus algorithm are chosen in function of their stake (the amount of tokens a participant has). The same mechanism is used in the Tezos governance.
If one does not have enough stake to participate on its own or does not want to set up the needed infrastructure, (s)he can use delegation, possibly complemented with staking. Indeed, in Tezos, it is the delegates that may participate in consensus. However, at each level, not all delegates necessarily participate, and their participation weight may differ. The selection of the delegates’ participation rights at a level is done by running a PRNG (pseudo-random number generator). The PRNG’s seeds are obtained from random data that are regularly produced and stored on the blockchain. Thus, the procedure is deterministic in that delegates’ rights are uniquely determined from the seed; and it is random, in that its seed (and hence its results) cannot be predicted too much in advance.
Delegation and Staking#
A delegate is any user account registered as
such. This is done by self-delegating, that is, emitting a delegation
operation (see below) in which the specified delegate is the same as the
operation emitter (its signer). Note that tz4 accounts cannot be registered
as delegates.
Any account (user account or smart contract) can specify a delegate
through a delegation operation. Any non-delegate account can change or revoke its delegate
at any time, again through a delegation operation. However, the change only
becomes effective after CONSENSUS_RIGHTS_DELAY + 2 cycles. The
value CONSENSUS_RIGHTS_DELAY is a protocol constant. A delegate cannot stop self-delegating.
A delegate participates in consensus and in governance in proportion to their baking power and voting power respectively.
The voting power of a delegate is the total amount of tez owned by all the accounts that delegate to it (including the delegate itself), with no distinctions made between staked and non-staked tez.
The baking power is similar, except that non-staked tez are weighted less than staked tez, and there are additional considerations such as overstaking and overdelegation. See the Baking Power page for more details.
Moreover, to participate in consensus and governance, the delegate needs to be active and to meet minimal balance requirements.
Delegates and delegators may stake their tez. Staked tez are security deposits that may be forfeited in case the baker does not follow (some particular rules of) the protocol. Besides, as mentioned above, staked tez are weighted higher than non-staked tez when computing the baking power.
Consensus key#
The key used by a delegate to sign blocks and consensus operations is called the
consensus key. By default, this is the delegate’s private key, called its
manager key. However, a delegate may specify another, dedicated key for this
role. See this page for further important details. In particular,
both the delegate key and the consensus key give total control over the
delegate’s funds: indeed, the consensus key may sign a drain operation to
transfer the delegate’s free balance to an arbitrary account. In relevant RPCs,
like /chains/main/blocks/head/helpers/baking_rights, both the delegate’s
manager and consensus keys are listed.
If the adaptive issuance feature is activated, it grants delegators the ability to become ‘stakers’ by placing security deposits. These deposits would contribute to their delegate’s stake and could be subject to slashing penalties if their delegate misbehaves. The staking power of funds placed by stakers and delegates is three times that of delegated funds.
Active and passive delegates#
A delegate can be marked as either active or passive. A passive delegate cannot participate in the consensus algorithm.
A delegate is marked as active at its registration.
A delegate becomes inactive at the end of a cycle if it has failed to
participate in the consensus algorithm at all during this whole cycle.
This is specified by the TOLERATED_INACTIVITY_PERIOD protocol
constant, which is currently equal to 1 cycle.
Delegates’ rights selection#
Tezos being proof-of-stake, the delegates’ rights are selected at random based on their baking power. Let us detail the selection mechanism used in Tezos.
Random seed#
To each cycle is associated a random number called the seed. This seed is used within its cycle to generate pseudo-random values in the protocol, in particular for selecting delegates to participate in consensus.
For more information on randomness generation, see randomness-generation.
Slot selection#
Delegates’ rights to participate are determined using the alias method, more precisely using Vose’s algorithm (see also this more pedagogic description; the algorithm is the last one listed there). This algorithm samples from a discrete probability distribution, which is given by the stakes of a specific cycle: the probability to sample a particular delegate is its stake in the cycle over the total stake in that cycle.
Concretely, the delegates’ rights at a given level are expressed in terms of the (quantity of) slots that the delegate owns at that level. This quantity represents the delegate’s weight in consensus. We note that, in the long run (that is, on average over many levels), the number of slots is proportional to its stake. The owner of a slot is obtained by sampling using the algorithm mentioned above. More precisely, given a level and a slot (which is just a non-negative integer), the mentioned algorithm is invoked to assign a delegate to the given slot. Its input is the probability distribution given by the stakes retained for the cycle to which the level belongs. And whenever the algorithm needs to draw a random value, this is obtained using a simple procedure which has as its initial state: the level, the random seed for the cycle to which the level belongs, and the slot.
Proof-of-stake parameters#
Parameter name |
Parameter value |
|---|---|
|
10800 blocks |
|
2 cycles |
|
6,000 ꜩ |
|
600 ꜩ |
|
1 cycle |
Further External Resources#
The original design of the proof-of-stake mechanism in Tezos can be found in the whitepaper.
The adaptive issuance feature documentation.
Other presentations of the Tezos’ proof-of-stake mechanism can be found in the Open Tezos entry.