Skip to main content

Synopsis

This specification document describes a client (verification algorithm) for a blockchain using GRANDPA. GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement) is a finality gadget that will be used by the Polkadot relay chain. It now has a Rust implementation and is part of the Substrate, so likely blockchains built using Substrate will use GRANDPA as its finality gadget.

Motivation

Blockchains using GRANDPA finality gadget might like to interface with other replicated state machines or solo machines over IBC.

Definitions

Functions & terms are as defined in ICS 2.

Desired Properties

This specification must satisfy the client interface defined in ICS 2.

Technical Specification

This specification depends on correct instantiation of the GRANDPA finality gadget and its light client algorithm.

Client state

The GRANDPA client state tracks latest height and a possible frozen height.

Authority set

A set of authorities for GRANDPA.

Consensus state

The GRANDPA client tracks authority set and commitment root for all previously verified consensus states.

Headers

The GRANDPA client headers include the height, the commitment root, a justification of block and authority set. (In fact, here is a proof of authority set rather than the authority set itself, but we can use a fixed key to verify the proof and extract the real set, the details are ignored here)

Justification

A GRANDPA justification for block finality, it includes a commit message and an ancestry proof including all headers routing all precommit target blocks to the commit target block. For example, the latest blocks are A - B - C - D - E - F, where A is the last finalised block, F is the point where a majority for vote (they may on B, C, D, E, F) can be collected. Then the proof needs to include all headers from F back to A.

Commit

A commit message which is an aggregate of signed precommits.

Misbehaviour

The Misbehaviour type is used for detecting misbehaviour and freezing the client - to prevent further packet flow - if applicable. GRANDPA client Misbehaviour consists of two headers at the same height both of which the light client would have considered valid.

Client initialisation

GRANDPA client initialisation requires a (subjectively chosen) latest consensus state, including the full authority set.
The GRANDPA client latestClientHeight function returns the latest stored height, which is updated every time a new (more recent) header is validated.

Validity predicate

GRANDPA client validity checking verifies a header is signed by the current authority set and verifies the authority set proof to determine if there is an expected change to the authority set. If the provided header is valid, the client state is updated & the newly verified commitment written to the store.

Misbehaviour predicate

GRANDPA client misbehaviour checking determines whether or not two conflicting headers at the same height would have convinced the light client.

State verification functions

GRANDPA client state verification functions check a Merkle proof against a previously validated commitment root.

Properties & Invariants

Correctness guarantees as provided by the GRANDPA light client algorithm.

Backwards Compatibility

Not applicable.

Forwards Compatibility

Not applicable. Alterations to the client verification algorithm will require a new client standard.

Example Implementations

None yet.

History

March 15, 2020 - Initial version All content herein is licensed under Apache 2.0.