🧑‍🍳Baking - Creating blocks on the Tezos blockchain (DEPRECATED)

PLEASE REFER TO: https://opentezos.com/baking

Introduction

The following characteristics set the Tezos blockchain apart from other blockchains:

1. On-chain governance, making it possible for the protocol to evolve by upgrading itself through successive amendments.

2. The Liquid Proof-of-Stake (LPoS) consensus, ensuring a low-carbon footprint and a coin delegation mechanism (explained below).

3. The Michelson development language used for smart contracts, providing a solid basis for formal verification.

This document provides a detailed introduction to:

• the consensus algorithm, and

• the mechanism for creating blocks -- or baking, as it is known on Tezos.

Definition of the main concepts

Block: A set of operations for validation. A block contains, besides operations, information such as the current block number, information about the previous block, and also the time at which it was validated.

Baking: Creation of new blocks on the Tezos blockchain by participants known as bakers, who are given a reward for each block that they bake. A baker may also be referred to as a delegate.

Preendorsement/Endorsement: In addition to creating new blocks, bakers may approve blocks made by other bakers. They are known as preendorsements (1st approval phase) and endorsements (2nd approval phase) of a block.

Delegation: Every Tez holder (XTZ or ) can transfer the baking and voting rights associated with their Tez to a baker. The holder always retains control of their funds and may change delegate at any time.

Stake: To have the right to be recognized as a baker in a network, a Tez holder must possess at least 6,000 in their staking balance (own balance + delegated balance). Voting rights are also indexed to the staking balance.

Cycle: Period of time during which 8,192 blocks are created on the Tezos blockchain. Also used as a unit of time. It corresponds to roughly 2 days, 20 hours, and 16 minutes (based on 30 seconds per block created if no baker has missed their baking slots).

Fitness: Score representing the quality of the chain up to a given block. In the current protocol, the fitness includes its version (currently 2. Version 0 was used by Emmy, and version 1 by Emmy+ and Emmy*), the level of the current block as the third component, the round at which a preendorsement quorum was observed by the baker, the opposite of predecessor block’s round as the forth component (the predecessor is taken for technical reasons), and finally the block’s round (as the fifth component).

Slot: A slot is a position available for a block creation or an endorsement: each cycle has 8,192 baking slots and 2,097,152 endorsement slots. At the start of each cycle, the protocol assigns a list of bakers to each slot using a uniform law weighted by staking balance. The first baker on the list is tasked with baking or endorsing as appropriate. If they don't, the next baker is given the task, etc.

Round: A period of time (made up of 3 phases) during which a given validator (selected to produce a block) proposes a block, obtains preendorsements, and then endorsements. If, for certain reasons it fails, we go to another round, and so on.

Node: A Tezos node is a peer (a machine) on the peer-to-peer network. It keeps a copy of the current state and propagates the blocks baked and operations performed to the other peers. A node is not necessarily a baker, but a baker is always associated with one or more nodes. Nodes are running in one of the following three modes, with respect to how they keep the chain history:

• In archive mode, they keep the whole history of the chain. As of year-end 2020, an archive node takes up around 80GB.

• In rolling mode, they keep the minimum data required to operate the chain, with the oldest information being deleted regularly.

• In full mode (the default mode), they keep all the information in a rolling mode, plus the minimum data required to reconstitute the entire chain from the genesis block. Thus, the full mode combines elements of the archive and rolling modes.

Contents of a block

A blockchain is made up of a series of blocks. Each block consists of a header and a list of operations. The header contains key data related to the block's validity, such as:

• The block-level or the block height in the chain

• The round at which the block has been created

• The block predecessor's hash, which is used to chain the blocks together

• The block's timestamp

• The signature of the baker that produced the block

• The block's fitness, assigning a score to the chain up to the current block

The block's body then contains a list of various operations (transfer of Tez, deployment of smart contracts, etc.) up to the maximum size permitted under the protocol (currently 512KB per block).

Liquid Proof-of-Stake and delegation

Baking rights are attributed on Tezos randomly but proportionally to the staking balance (own balance + delegated balance). A Tez holder may:

• become a baker if they possess at least 6,000 in their own funds or by delegation

• delegate their Tez to a baker, to participate in the consensus

In practice, certain bakers may pass on some of the rewards they receive to the individuals who delegated their Tez to them. This distribution may encourage others to delegate their Tez, thereby increasing the delegated balance of these bakers and so their staking balance, i.e. their chance of baking/endorsing.

Liquid Proof-of-Stake (LPoS) provides the option for a Tez holder to retain ownership of their funds while delegating their associated (voting, baking) rights to a baker. This principle differs from the delegated Proof-of-Stake (DPoS) of other blockchains, in which participants vote for a restricted number of block validators.

Baking

In Tezos we call participants in the block validation process delegates. Each delegate can:

• act as a baker, creating and signing blocks, and/or

• act as an endorser, approving blocks by issuing an endorsement operation (endorsements visible at the block level n + 1 relate to the block level n).

Baking and endorsement rights are attributed at random, several cycles in advance. To deter dishonest behavior (e.g. double baking or double endorsement), each delegate must place a fixed quantity of Tez as a security deposit for a limited time (five cycles), which will be confiscated if they attempt to compromise the chain.

Prospective bakers must meet the following requirements:

• Server available round the clock and stable internet connection

• At least 8GB of RAM

• SSD disk (preferably with more than 100GB storage)

• At least 6,000

Endorsement

Among the bakers, a list of endorsers is drawn up for each block. Their role is to approve the blocks created by the baker -- i.e. to officially approve the block.

To approve a block at level n, the endorsers each add a signature operation that is included in the n + 1-level block. Once the block n + 1 is baked, no more endorsement operations are accepted for block n.

Each block has 7,000 endorsement slots. There is no obligation for a baker to include endorsements with endorsing power more than 4,667 but the baker will receive a bonus proportional to the extra endorsing power of the endorsements included.

An endorser may obtain several endorsement slots for a given block. They will then be rewarded for each endorsement slot completed (i.e. for each slot validated).

Options for baking

In practice, blocks are baked and endorsed automatically. There are several options for setting up a baker, each with its own advantages and disadvantages. Here are some baking options, with links to more information:

• Kiln and Ledger Nano: https://gitlab.com/tezos-kiln/kiln. An intuitive plug-and-use method for setting up a node and baker.

• BakeBuddy and Ledger Nano: https://www.bakebuddy.xyz/. An intuitive plug-and-use method for setting up a node and baker.

• Remote Signer and Ledger Nano: https://github.com/obsidiansystems/ledger-app-tezos.

• Remote Signer via the Cloud: https://www.ecadlabs.com/signatory.

The following links provide information on how to set up a baker:

• https://github.com/tzConnectBerlin/baking-support

• Tezos Node Setup & Maintenance by BakingBenjamins

Remote signing

Remote signing software is one way to reduce the exposure of private keys during baking operations. In the block validation process (baking/endorsement), the software interacts with a private key management system (e.g. Ledger Nano S, a remote machine communicating via a secure channel).

Remote signing involves physically separating baking/endorsement requests originating from the network and intended for a given delegate, from that delegate's signing operation. The Tezos client implements several built-in signing mechanisms (unix, tcp, http, and https) that use different communication channels to send signing requests for the baker.

The following events occur during a remote signing operation:

1. The node sends a signing request to the remote signing software that interacts with the private key management system.

2. The remote signing software verifies what the operation involves − usually the creation of a block or an endorsement (The third, rarer option is a nonce revelation.) − then sends it to the key management system, which signs the operation.

3. The signature is then validated by the remote signing software and sent back to the Tezos node, which propagates the operation to the network.

The key should preferably be held in a hardware vault so it is never directly accessible on the network. Moreover, it is more secure to ensure that the hardware vault authorizes only block signing rather than the signing of just any transaction (i.e. such as not to create a blind signing mechanism).

For example: Ledger Nano S together with Kiln meets these two conditions.

Baker selection

In each cycle n, baking/endorsement rights at cycle n + 5 are randomly attributed as follows.

A stake snapshot is a picture of the status of the stake of each network participant in cycle n - 2.

A random seed is generated at cycle n based on certain information contained in the previous blocks. This seed is then used to select the validators (from those in the stake snapshot) to which baking/endorsement rights are attributed at cycle n + 5.

Rights are allocated using the following mechanism:

• For each block, a list is drawn up, setting an order of priority for bakers and endorsers.

Once listed, a baker, therefore, has to wait for at least seven cycles before being eligible for selection. Bakers are thus aware of their baking/endorsing rights at least seven cycles in advance.

Rewards for bakers and endorsers

Bakers are crucial because they operate the chain by creating blocks and checking the integrity of the data they contain. Each baked block leads to the creation of new Tez to incentivize the bakers to perform baking and endorsing operations.

There are up to 20 Tez paid in baking rewards, and 20 Tez paid in endorsing rewards per block (for a total of 40 Tez per block). Block rewards are split into two parts: a fixed part (10 Tez for the payload producer who selects the transactions to be included in the block and the first authorized to propose a block with that payload, and at most 10 Tez as a bonus for the block producer who proposes the block. In case of re-proposal, the payload producer might be different from the block proposer. Otherwise, it should be the same), and a variable part which is a bonus for the block producer, depending on the number of endorsements included (beyond the 4,667 endorsements threshold).

Baking rewards (fixed and variable) on each block are paid immediately, whereas endorsements rewards are paid at the end of each cycle, under the conditions of participating in the consensus (performing endorsement operations) more than 2/3 of its expected number of slots; and if they reveal their nonces. Baking and endorsement rewards follow the formulas below:

where $e$$\in$[0; 2,333] = the number of extra endorsements slots beyond the threshold of 4,667.

The baking rewards are 20 Tez at most, for a fully endorsed block (not counting the transaction fees).

where$s$ = number of endorser’s slots.

An endorser may have several slots among the 7,000 slots available in a given block, depending on its stake. The more stake a baker has, the more slots it gets per block.

Issuing new Tez

As stated above, each time a block is created and validated, new Tez are created.

The per-block reward can be used to estimate that a block produces a maximum of 40 Tez. Extending this per-block reward to the number of blocks baked per annum at a rate of two blocks per minute (105,120 per annum excepting leap years), then the number of Tez increases by at most 5.51% in year 1 (in 2018). Since the rewards are fixed, this percentage declines over the years.

The growth in the "money supply" does not apply solely to bakers. If a Tez holder delegates them to a baker who passes on a portion of their rewards, that Tez holder will also benefit from the new money created.

Several phenomena independent of the baker can lead to fluctuations in their return:

• Not all Tez might be active in the baking process, increasing annual return.

• The time interval between blocks could be more than 30 seconds, decreasing the annual return.

• The full 7,000 endorsements might not have been gained, decreasing annual return.

A holder delegating their Tez may wish to select a reliable baker who pays them interest. The estimated return can be observed based on the amount of Tez delegated:

• https://www.stakingrewards.com/earn/tezos

Modeling a baker's gains (Deprecated)

With the following assumptions:

• Number of active rolls in the year one = 84,156 (correct at the time of writing)

• One block baked per minute

• 7,000 endorsements for each block

…a baker possessing one roll (= 6,000) will create on average one block per month, and will endorse around 7,000 blocks per month. This is close to 480 Tez earned per annum on average, or a return of approximately 6%. This value is slightly higher than the 5.51% stated above because we assume here that there are inactive rolls, which means active rolls earn more revenue than in a situation where all rolls are active.

A baker also receives fees for the transactions they include in any blocks they create. These fees depend on supply and demand, but the gains are currently well below the reward for creating the block itself (≈ 0.1% of the baker's gains in 2019).

Continuing the assumptions above, here is an example showing what a baker who retains their baking rewards can earn in a year, according to how many they hold:

Modeling table of rewards, assuming that 673248k Tez are in circulation

Alice has only 1 roll at the outset and Bob has 10. After ten years, Alice is still baking with a single roll whereas Bob has five more. This reveals the critical mass applicable to bakers. Unlike smaller bakers, larger ones earn a linear increase in the number of rolls they hold over time.

These results are simulations based on assumptions, and so a baker's actual revenue may not be the same as the figures shown in this table.

Security deposits and penalties

To discourage double baking/endorsement¹ a security deposit is required.

The security deposit remains physically in the account but is locked up for a period of five cycles (around two weeks). The corresponding Tez are always taken into account when calculating slots, but they cannot be spent or used as a new security deposit until they have been released again.

All security deposits are frozen when rights for a cycle are being drawn. On mainnet, rights for a cycle are determined 5 cycles in advance, and a delegate has a specific deposit associated to each cycle. We only retain one deposit: the highest deposit of all cycles in a timeframe of 7 cycles, so that we are always able to punish proportionally to the capacity to harm in this timeframe. If a validator double signs (it double bakes or it double (pre)endorses (which means voting on two different proposals at the same round), the frozen deposit is slashed). The slashed amount for double baking is DOUBLE_BAKING_PUNISHMENT = 640 Tez. The slashed amount for double (pre)endorsing is a fixed percentage RATIO_OF_FROZEN_DEPOSITS_SLASHED_PER_DOUBLE_ENDORSEMENT = 1/2 of the frozen deposit. Bakers are advised to hold at least 10% of the total number of Tez used for baking purposes. By default, the required deposits are automatically determined to maximize the active stake. However, no baking/endorsements slots will be assigned to a delegator who has not enough security deposit.

When a double baking/endorsement is observed, an accusing baker may provide evidence in a block for a period of five cycles starting from the fake operation. As a reward for the accuser, half the culpable baker's deposit goes to the accuser. The other half of the deposit is destroyed.

[1]: Double baking (or double (pre)endorsement) means baking ((pre)endorsing) two different blocks at the same level and round, with the same key, which may temporarily cause the chain to fork.

Actions prejudicial to the network

The following actions result in the punitive seizure of the security deposit:

• Double baking: A dishonest baker may try to bake two blocks at the same block height in the chain. However, to be able to do this, they would have been drawn at random and then deposit 640 Tez per block baked.

• Double endorsement: A dishonest endorser could attempt to endorse two blocks at the same block height in the chain. Half of the total deposit is forfeited.

• Seed slash: a baker is asked to provide random seeds to feed into the baker selection algorithm. To avoid the algorithm being deterministic, the seeds are given in a hashed form. The baker undertakes to deliver in the following cycle the seeds corresponding to the hashes sent. If they do not do so, they do not earn a reward but may still get back the associated deposit.

The protocol allows a window of five cycles during which an accuser may demonstrate evidence of double baking or double endorsement (several times if necessary). The dishonest baker will then lose the security deposit(s) placed for the fake operation up to the latest point in the cycle (which may be costly, especially if the baker has done a lot of baking/endorsing over the relevant period).

Minimum time delay before baking a block

The minimum time delay between two blocks is 30 seconds, reached if the baker is of priority 0 and has gathered at least 66.7% of the endorsements. If the priority 0 baker fails to bake, the priority 1 baker may then bake after a certain time, defined by a so-called round duration function.

To be able to bake as rapidly as possible, the baker must gain enough endorsements (66.7%, that is, endrosements with endrosing power of at least 4,667 out of 7,000). Rounds follow the structure below:

$round \_ duration(0)=minimal \_ block \_ delay\\round \_ duration(r+1)=round \_ duration(r)+delay \_ increment \_ per \_ round =minimal \_ block \_ delay+(r+1)∗delay \_ increment \_ per \_round$

Round duration thus increases linearly with DELAY_INCREMENT_PER_ROUND = 15s, MINIMAL_BLOCK_DELAY = 30s,r = round.

Any block baked ahead of the minimum time delay is automatically rejected under the protocol's rules.

Over-delegation

A security deposit is required to bake and endorse properly. This amount remains locked up over a timeframe of seven cycles. In addition, a baker cannot spend Tez that have been delegated to them or use them as security deposits.

A baker is said to be over-delegated when they do not have sufficient funds themselves relative to their stake. However, they do not miss slots because of a lack of security deposit and thus will not slow down the chain anymore².

The over-delegated baker will not maximize its staking power, since more Tez are delegated compared to what it should own (10% of the total staking balance).

To keep a portion of its balance spendable, a baker can set a deposit limit:

tezos-client set deposit limit for <delegate> to <deposit_limit>

, and unset this limit with the command:

tezos-client unset deposit limit for <delegate>

[2]: Before Ithaca amendment, over-delegated bakers could end up losing slots (thus not gaining the associated rewards) because they hadn't sufficient funds to cover the security deposits for all their attributed slots.

Inactivity

A baker who refuses or is unable to bake or endorse for five cycles will be treated as inactive by the chain, and can no longer be picked as a baker/endorser.

The inactive baker must wait for seven cycles after reactivating their account, before they can bake again.

This mechanism is designed to ensure that a baker who is no longer active, does not slow down the chain.

Attacks

The attacks potentially targeting a baker include:

• DoS (denial of service attack): Suppose Bob knows that Alice is about to bake a block with priority 0. He may decide to launch a DoS attack to prevent Alice from publishing her block correctly, thus damaging Alice's reputation. If the attack is sustained, and if Bob appears toward the top of the list of potential bakers (especially if he has priority 1), then he may also be able to steal Alice's block.

• Theft or loss of a private key: Holding the private key is the only way to gain access to the associated Tez and to sign various operations. Thus it is vital to keep the private key safe and secure (e.g. in a hardware wallet).

• Eclipse attack: An attacker can try to cut off (or take control of) the connection between the baker and the network nodes to which they are connected. Thus, the attacker could send the isolated baker blocks that are not part of the consensus.

Summary diagram