A Tezos node stores data in two ways:
- store: a set of blocks
- context: the data, associated with a block, necessary to validate the next block.
Baking - producing a valid block on top of an existing one - requires the context of the block you are trying to build on top of. For exmaple, in order to decide whether an operation is valid, you need to know:
- all account balances (you don’t want anyone to spend money they don’t have, include operations when they can’t pay gas etc)
- all smart contract storage
However, for a very few cases described below, the context is not sufficient, and you need more things in the node storage.
Is it possible to bake using only the context?
Nonce revelation
When the baker has produced a block with a level divisible by 64, they must include a commitment to a nonce, then reveal the nonce during the first 256 blocks of the following cycle. Otherwise, they lose their endorsement rewards.
Revelation goes as follows:
- context keeps track of every level of unrevealed nonce per baker
- when a new cycle starts, or when the baker starts, baker queries context, gets a list of unrevealed levels
- baker queries store to get the block hashes of unrevealed levels
- baker feches nonce in the nonce file and reveals it
Step 3 is necessary because the nonces are stored with the format "<block_hash>": "<nonce>".
If the baker has migrated servers between the commit and the reveal, and restored from a very recent snapshot, step 3 will fail and they will lose their endorsement rewards, even if they ported their nonce file to the new server. This is a somewhat commom occurence.
There are two solutions:
- index the nonce file per level instead of per block hash
- deterministic nonces: for a given level, the baker will always generate the same nonce, derived from the private key using HMAC scheme, or otherwise from a secret seed known to the baker. There is an old implementation available.
Deterministic nonce is better because it removes the necessity of the nonce file altogether. All that’s needed to bake is the current context and the consensus key.
Reward distribution using the current context
Tezos baking rights are based on snapshots of staking balances, taken at random during a cycle. For public bakers, reward distribution therefore requires knowledge of all delegators’ balances during this snapshot.
In practice, everyone relies on TzKT and Tzstats for this information. In theory, it is possible to fetch this data from the context when the snapshot was taken. TRD supports this (with an archive node backend).
The context already has a map of all bakers’s staking balances of the snapshot used to calculate the current cycle’s rights.
It is stored in the Cycle object. For a given level, the context contains the data of several Cycle around the current cycle.
Does it make sense to also store all the delegators and their balances there as well?
Pro:
- you can pay rewards using only a daemon attached to a node, without any requirements on the store or a third party indexer
Con:
- it bloats the context: the node does not need this data otherwise than for helping a baker to pay out its rewards
Baking should be simple
To encourage decentralization, we must remove pain points from baking. The two suggestions above will encourage more tez holders to bake.
