Validator Mechanism

Blocks

The basic primitive that underlies blockchain technology is, of course, the block.

A block comprises a set of transactions that a leader (the block proposer) has assembled. A block's contents (its payload) may vary according to the protocol.

  • The payload of a block on DaVinci execution chain is a list of user transactions.

  • The payload of a block on the pre-Merge proof of stake beacon chain was (mostly) a set of attestations made by other validators.

  • Post-Merge beacon chain blocks also contain the execution payload (the user transactions).

Except for the special Genesis block, every block builds on and points to a parent block. Thus, we end up with a chain of blocks: a blockchain. Whatever the contents of blocks, the goal of the protocol is for all nodes on the network to agree on the same history of the blockchain.

A blockchain time moves from left to right and, except for the Genesis block, each block points to the parent block it builds on.

The chain grows as nodes add their blocks to its tip. This is accomplished by temporarily selecting a "leader", an individual node that has the right to extend the chain. In proof of work the leader is the miner that first solves the proof of work puzzle for its block. In DaVinci proof of stake the leader is selected pseudo-randomly from the pool of active stakers.

The leader (usually known as the block proposer) adds a single block to the chain, and has full responsibility for selecting and ordering the contents of that block, though its block must be valid according to the protocol rules otherwise the rest of the network will simply ignore it.

Block Trees

Our neat diagram of a nice linear chain will for the most part reflect what we see in practice, but not always. Sometimes, due perhaps to network delays, or a dishonest block proposer, or client bugs, any particular node might see something more like the following.

In general, we might end up with a block tree rather than a block chain. Again, time moves from left to right and each block points to the parent block it builds on.

In real networks we can end up with something more like a block tree than a block chain. In this example very few blocks are built on their "obvious" parent.

Why did the proposer of block CC build on AA rather than BB?

  • It may be that the proposer of CC had not received block BB by the time it was ready to make its proposal.

  • It may be that the proposer of CC deliberately wanted to exclude block BB from its chain, for example to steal its transactions, or to censor some transaction in BB.

  • It may be that the proposer of CC thought that block BB was invalid for some reason.

The first two reasons, at least, are indistinguishable to the wider network. All we know is that CC built on AA, and we can never know why for certain.

Similarly, why did the proposer of block DD build on BB rather than CC? Any of the above reasons apply, and we can add another:

  • The proposer of DD may have decided on some basis that there was more chance of the wider network eventually including BB than CC. Thus, building DD on BB gives it more chance of making it into the eventual block chain, than building DD on CC.

The various branches in the block tree are called "forks". Forks happen naturally as a consequence of network and processing delays. But they can also occur due to client faults, malicious client behaviour, or protocol upgrades that change the rules, making old blocks invalid with respect to the new rules. The last of these is often called a "hard fork".

Finality

Finality is an existing block proposal mechanism, by which we mean that it takes an existing block tree and prunes it in some way. Finality modifies the branching options of the underlying block tree by making some of its branches inaccessible.

Consider this block tree produced by some underlying consensus mechanisms

An arbitrary block tree with three forks (branches). Any of blocks II, EE, or MM could be the tip of the chain. (The block labels are for convenience and do not imply a particular ordering.)

Last updated