Understanding block minting in Cardano

In the Cardano network, only the nodes that were randomly drawn in the given slots and whose registration certificates have been stored in the blockchain can create blocks. It must be verifiable that the newly proposed blocks were minted by the node that won the lottery and was authorized to do so. Come learn about how new blocks are minted and how they are verified.

Why is it necessary to verify blocks?

Decentralization and security requirements are imposed on every public blockchain network. In the context of block production, this means that a random lottery for the selection of block producers and a mechanism for block verification must be established.

Additionally, blockchain networks are open, so anyone can voluntarily and completely anonymously join and start producing blocks. It can also be done by entities that want to deliberately attack the network. It is therefore necessary to define the rules of network operation (protocol). As long as the majority of nodes in the network behave according to the rules (of the protocol), it will be easy for the network to eliminate attacks and regularly append new valid blocks to the blockchain.

Most current blockchains work in such a way that in a given time period one node produces a block and all other nodes verify this block. The proposed block can either be accepted (if valid) or discarded. If more blocks appear in a given time period, there must be a rule that determines which block should be added to the end of the blockchain (it will become the last block). The rule can be dependent on the addition of multiple new blocks (longer chain rule).

Block verification usually consists of verifying concrete cryptographic proof that the block was created by the node that won the lottery. Additional data in the block header can be verified. For example, to verify the authenticity and integrity of the block.

Each block is composed of a header and a body (content). The content of the block is also verified, i.e. transactions are verified. A block can have a valid header, but if the content of the block is invalid, the block cannot be valid either. This article focuses on block production, so we will not be interested in block content. We only need the data in the block header.

A blockchain can be considered decentralized and secure if a wide set of independent nodes are able to append blocks and an attacker is not able to disrupt this process in any way. Honest nodes are able to reach a network consensus at regular intervals.

How Cardano divides time

Cardano divides time into slots lasting one second and epochs lasting 5 days. One epoch lasts 432,000 slots.

When transitioning between epochs, a so-called snapshot is taken.

The snapshots are made by the nodes that actively participate in the Cardano consensus (so in the production of blocks). The snapshots are taken at the end of each epoch and record the stake distribution and delegation status of the network.

Stakers can delegate at any time during the epoch, so the stake of individual pools and their number (new stake pool registrations) can constantly change. The state reflecting the changes is called a live stake. Nodes participating in the network consensus work with the state that is taken during snapshots, which is called active stake. Snapshots provide security, stability, and predictability for the system.

In the image below, you can see the snapshot (candidate for active stake) taken during the transition between epochs. Note the slots that are divided by 20-second intervals. The randomness in Cardano is set so that a new block is produced approximately every twenty slots. Sometimes the time interval between blocks (number of slots) can be shorter, sometimes longer.

On each node, a private lottery takes place in each slot independently of the others. If a node (or more nodes) finds out that it has won the right to mint a block, it becomes the so-called slot leader. It is indicated by yellow rectangles in the picture. We will return to the details later.

Let's go back to the epochs to explain another detail. In the image below, epoch N+3 is in progress (green rectangle). A last snapshot was taken between the transition between epochs N+2 and N+3, but it is not used as an active stake. A snapshot taken at the beginning of the previous epoch N+2 is used as an active stake. This snapshot reflects the state of epoch N+1 (blue rectangle).

The stake distribution and delegation status from the snapshot that was taken at the beginning of the previous epoch is used in the current epoch as an active stake. In other words, the previous snapshot is used as the active stake.

One of the main reasons for this rule is that enough time has passed since the previous snapshot was taken (5 days) to guarantee that the blocks in the blockchain (including the content) will not change.

Preparing the node for minting and verifying blocks

Random lotteries and block minting are based on cryptography in Cardano. The Verifiable Random Function cryptographic primitive is used for the random lottery. Key-Evolving Signature scheme for signing blocks and ensuring immutability of blockchain history.

In this article, we will not cover the cryptographic details, but only the practical use for minting and verifying blocks. It is enough for us to know that pool operators must create several key pairs that will allow them to create the necessary certificates for pool registration and block-producer node operation.

Every pool operator must create the following key pairs:

• Stake pool key pair (cold key)
• Key-Evolving Signature (KES) key pair (hot key)
• Verification Random Function (VRF) key pair (hot key)
• Stake address key pair (cold key)

Each pair of keys consists of a private key (a signing key) which the owner (that is, the pool operator) must keep secret. Further from the public key (verification key) which can be published. In the images, the signing key will be shown in red and the verification key will be shown in green.

All pool nodes use a signing VRF key for private lottery and a signing KES key for signing newly minted blocks.

In the picture below you can see the pool operator who created all the necessary keys for operating the pool. He inserted the signing VRF and KES keys into the hot storage in the node. Note that a verification stake pool key is used for pool identification (ID). A signing stake address key serves for withdrawing rewards from the reward account.

In order for verification to be possible, the verification VRF and KES keys must be available to all nodes in the network. In addition, it is necessary that the keys are correctly associated with a specific pool operator. This is achieved through an ID (stake pool key). Certificates are used to distribute keys.

All pool operators must register the pool and insert (among other things) a verification VRF key into it. They must also create an operational key certificate and insert a verification KES key (also called an operational key) into it. All certificates are distributed through Cardano transactions and are stored in the blockchain.

In the picture below you can see the pool operator who created the pool registration certificate and the operational key certificate and inserted the required public keys into them. Let's add that both certificates must be signed by the signing stake pool key.

ADA holders delegate their stakes to the chosen pools through a pair of certificates, a stake address registration certificate, and a delegation certificate. These certificates are also stored in the blockchain. Delegated ADA coins increase the total stakes of pools.

In the image below you can see the user who created the certificates needed for stake delegation. Note that the stake pool key (ID) is included in the delegation certificate.

In the image below, you can see how stakers and pool operators submit certificates to the blockchain through transactions during an epoch. Certificates will remain stored in individual blocks (including all verification keys). The image is for illustrative purposes only. A block can contain multiple certificates. You also see a snapshot that will reflect the stake distribution and delegation status of the network for a given epoch.

In order for a node to be ready to verify blocks proposed by other pools in the network, it must maintain a local state with all the necessary information. A node must be able to verify incoming blocks quickly without unnecessary searching for information in the blockchain.

Nodes track a set of active stake addresses. Tracked data contains the stake credentials (key or a hash of the script) from each stake address registration certificate. Nodes update the set based on the validation of transactions in incoming blocks. Nodes are able to verify transactions that withdraw staking rewards from reward accounts (part of every registered stake address).

Nodes track a set of active stake pools, which they index based on the verification stake pool keys (more precisely, hashes of the keys). Furthermore, the node tracks information related to operational key certificates, including a counter that represents the serial number of the certificate. Only the certificate with the highest counter number is valid (all older certificates with a lower counter number are invalid).

Nodes track active delegation certificates (all stake addresses that are delegated to the hash of the verification stake pool keys (IDs).

In order to play the leader slot lottery and calculate staking rewards per epoch, nodes must know how much stake is delegated to the pools. This is the sum of all stake addresses delegated to each individual verification stake pool key (again, hashes of the keys).

In the image below, you can see a pool node that maintains a local state with all the necessary information it needs to maintain for the verification of blocks (and transactions). Note that the node knows about all registered pools. It knows the hashes of their stake pool keys and their total stakes. It also knows about all active KES (operational) and VRF keys.

Some sets are constantly updated (for example the UTxO set changes with every newly added block) while others refer to the previous snapshot (active stake). To ensure that all nodes work with the same state regarding block production, a live stake cannot be used.

The figure below shows how the snapshot of the epoch becomes the basis for building the local state. All certificates (and delegations of stake addresses) are put into sets so that they are available for quick block verification.

Now you know what is necessary for a node to be able to mint new blocks and verify those proposed by other pools.

Minting of the block

Imagine that no slot leader was elected in the previous few slots. A new lottery round for the current slot is now running privately on each pool. This is a private lottery because it is necessary to use a signing VRF key that is available only to the pool operator and no one else (if the key is not compromised).

In order for a node to determine if it becomes the slot leader, it must use the VRF function. The VRF function takes several parameters as input and produces a VRF output. The input for the VRF function is the slot ID (current slot), Nonce, and signing VRF key (it is stored in hot storage on the node).

The nonce is calculated as the XOR of two values: the epoch nonce and the extra entropy. The epoch nonce is a hash that is created by using the first 2/3 of VRF outputs from the blocks that have been produced in the previous epoch. The extra entropy is an optional value that can be injected by anyone who submits a valid stake pool registration certificate with a non-empty nonce field. The extra entropy can be used to increase the randomness and security of the system or to recover from a compromised epoch nonce.

The VRF function on every node generates a random output (Y) and proof (⍴) for the current slot. The node compares the VRF output with a threshold that depends on its total stake. If the output is below the threshold, the node is elected as a slot leader and can mint a block in that slot.

In the image below you can see how all the pools in the network played the lottery in the given slot and compared the VRF output with the threshold. Node 7 became the slot leader.

In most cases, only one slot leader is elected in a slot. Let's assume that in our scenario as well. The slot leader has the right to build a block. The node must construct a block header and insert valid transactions into the body.

Node inserts this information into the block header:

• The block number, which is the sequential number of the block in the chain.
• The slot number (slot ID) in which the block was minted.
• The previous block hash, which is the hash of the header of the previous block in the ledger.
• The block issuer. It is the verification key of the stake pool operator who minted the block.
• The VRF output (Y) and proof (⍴).
• The block size, which is the size of the block in bytes.
• The block body hash. It is the hash of the body (transaction and data).
• The operational certificate.
• The protocol version. It is the version of the protocol parameters that are used for the block validation.

You can see the block in the image below. Don't be fooled by the proportion sizes. In practice, the block header is significantly smaller than the block body. In the first step, the VRF function is used to determine if the given node has become the slot leader. If so, the node inserts all necessary data into the header block and signs the block by the signing KES key (stored in hot storage on the node).

The signed block is ready to be sent to the Cardano network. The block will be distributed worldwide to all other Cardano nodes via relay nodes. The other nodes start by verifying the information in the block header and if it is OK, proceed to verify the body.

Block verification

Verification of the proposed block is a very easy matter for the nodes since they have all the necessary information (including cryptographic material) ready in the active sets.

A block will be considered valid if the following conditions are met.

The VRF outcome is a random value that determines the eligibility of the stake pool operator to mint a block in a given slot. The VRF proof is a cryptographic proof that shows that the VRF outcome was generated by the stake pool operator using their VRF key pair. Both can be easily verified.

The node that is going to verify the incoming block needs to know the nonce of the current epoch. It is not a problem since all honest nodes use the same nonce (used the same process to get it). The node uses a VRF verify algorithm to check if the VRF outcome and proof match with the public VRF key (it is taken from the active set) and the epoch nonce. The node also checks if the VRF outcome is below a threshold that depends on the stake of the node that proposed the block. If these checks pass, then the node accepts that the block candidate was minted by a valid slot leader.

It is important to note that this verification will only be successful if the pool with the same stake pool key (ID) has registered, which had to take place at the latest in the epoch corresponding to the used snapshot (active stake).

Another part of the verification is the KES signature check. The proposed block must contain a verification key certificate in the header. Remember that nodes have a list of active operational key certificates available in their local state.

The counter of the operational key certificate in the block must not be smaller than the counter of the operational key certificate in the active set of the node that verifies the block.

In the image below, you can see how the node verifies the header of the newly arrived block, for which it uses the information it has prepared based on the certificates stored in the blockchain.

Only some verifications regarding VRF and KES keys are indicated in the picture. Of course, it is necessary to verify all parameters in the header, i.e. block serial number, block size, link to the previous block, etc.

Conclusion

Block minting is designed so that no one else can mint a block in a given slot other than the slot leader. For this, the node needs to be registered in the blockchain through a certificate and have a sufficiently large total stake. In addition, it must have a valid KES key for the given KES period (the private key for signing blocks is changed at regular intervals to protect the history of the blockchain). All cryptographic material for block verification is available to all participants in the blockchain. Nodes do not accept a block that does not pass verification.