Aura + GRANDPA: how block production and finality actually work

A common source of confusion for new validators is the difference between producing a block and finalizing one. On many modern chains these are two distinct mechanisms running side by side. Block production, often handled by Aura, decides who authors the next block. Finality, often handled by GRANDPA, decides when a block can never be reverted. Keeping them separate is a deliberate design choice with real consequences for how a node behaves.

Aura: slot-based block authoring

Aura, short for Authority Round, is a simple and predictable way to decide who builds the next block. Time is divided into fixed slots, for example one every two seconds. For each slot, a deterministic function of the slot number and the current authority set selects exactly one validator as the author. If it is your slot, you build and broadcast a block. If it is not, you wait and import the block that arrives.

The appeal of Aura is that it is cheap and leader selection is unambiguous: every honest node computes the same author for a given slot. The weakness is that if the chosen author is offline, that slot is simply empty, producing a brief gap until the next slot's author steps in. Aura by itself gives you a growing chain of blocks, but it does not, on its own, tell you which fork is the final one.

Aura answers "who builds the next block." It does not answer "which block is irreversible." That is a separate question, and it is why finality needs its own mechanism.

GRANDPA: finality as a separate vote

GRANDPA, short for GHOST-based Recursive Ancestor Deriving Prefix Agreement, finalizes blocks. Rather than voting block by block, validators vote on the highest block they believe is valid, and GRANDPA finalizes the common ancestor that a supermajority agrees on. Because a vote for a block is implicitly a vote for all of its ancestors, one round of voting can finalize many blocks at once. Finalization requires agreement from validators representing more than two-thirds of the stake.

Once a block is finalized by GRANDPA, it is irreversible under the protocol's honesty assumptions. No fork can replace it. This is a stronger guarantee than the probabilistic finality of proof-of-work, where a block only becomes progressively harder to reverse as more blocks are built on top.

Why split the two jobs

Separating authoring from finality lets each mechanism be simple and optimal for its purpose. Block production can be fast and lightweight, keeping the chain moving at a steady cadence. Finality can be deliberate and stake-weighted, providing strong guarantees without needing to run on every single block in lockstep. The chain advances at the speed of Aura and settles at the speed of GRANDPA, and the two do not have to move at the same rate.

Finality lag, and why it is usually fine

Because finality runs as a separate process, finalized height typically trails the current block height by a small margin. This gap is called finality lag. Under normal conditions it is a few blocks and no one notices. Under heavy load, or if a portion of the validator set is slow or offline, finality can lag further while block production keeps advancing. The chain is still producing blocks; it is just taking longer to declare them irreversible.

For an operator, this distinction is practical. A node that follows finalized height will appear to lag the tip when finality is slow, even though nothing is wrong with the node itself. Monitoring should track both the current height and the finalized height, because they answer different questions: how fast is the chain moving, and how fast is it settling.

What a validator does in this system

• Authoring: when your slot comes up, build and broadcast a block.
• Importing: for every other slot, validate and import incoming blocks.
• Voting: participate in GRANDPA rounds so finality can progress.
• Staying reachable: your absence turns your slots into gaps and slows finality if enough of the set is missing.

Understanding that these are separate responsibilities explains a lot of validator behavior. A node that stops authoring but keeps voting is behaving differently from one that stops voting. And a chain whose finality is lagging is not necessarily a chain that has stopped, it is a chain that is still moving while settlement catches up.