Validator Mechanism
Last updated
Last updated
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.
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.
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 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 build on rather than ?
It may be that the proposer of had not received block by the time it was ready to make its proposal.
It may be that the proposer of deliberately wanted to exclude block from its chain, for example to steal its transactions, or to censor some transaction in .
It may be that the proposer of thought that block was invalid for some reason.
The first two reasons, at least, are indistinguishable to the wider network. All we know is that built on , and we can never know why for certain.
Similarly, why did the proposer of block build on rather than ? Any of the above reasons apply, and we can add another:
The proposer of may have decided on some basis that there was more chance of the wider network eventually including than . Thus, building on gives it more chance of making it into the eventual block chain, than building on .
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 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
