How is an external observer supposed to reliably know when the GRANDPA authorities have changed?

Question

The grandpa.proveFinality rpc provides the justification for the last block by a GRANDPA authorities set (of some set_id) and ancestry headers to prove the finality of a block within the same set_id. But it does not seem to include any indication in the provided finality_proof that the GRANDPA authorities have changed.

So an adversary that has corrupted a(n old) GRANDPA authorities set can forever fool an external observer that the GRANDPA authorities have not changed and the finality proofs being provided by the adversary is infact valid, if the external observer does not have access to the chain's storage (and continuously checks it)?

The only way I can think of solving this is that we can check every single header for ConsensusLog::ScheduledChange or ConsensusLog::ForcedChange digest logs. ConsensusLog::ScheduledChange seems to apply the new set immediately in the same block the digest is emitted, and in the case of ConsensusLog::ForcedChange it applies the new set after delay number of blocks after the block in which the digest is emitted. Is this a reliable way to approach this? Is this how it is intended?

Answer 1

Yes, RPC nodes can lie about an arbitrary number of things. I guess RPC interfaces can be designed to also provide proofs; in this case one could add a new RPC method that provides a proof similar to WarpSyncProof that proves the current authorities.

BUT, ultimately I think such an approach is a losing battle, and the correct trustless solution is to use light-clients instead of RPCs.

The only way I can think of solving this is that we can check every single header for ConsensusLog::ScheduledChange or ConsensusLog::ForcedChange digest logs. ConsensusLog::ScheduledChange seems to apply the new set immediately in the same block the digest is emitted, and in the case of ConsensusLog::ForcedChange it applies the new set after delay number of blocks after the block in which the digest is emitted. Is this a reliable way to approach this? Is this how it is intended?

Indeed, a light-client would do exactly that. It will warp sync to current head then it only follows/imports headers and trusts it has the current authority set by following GRANDPA proofs for new headers, and by following the inner header digests that signal authority changes.

Answer 2

The issue you are describing is called weak subjectivity and it's inherent to Proof-of-Stake systems (some useful links on the subject: https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/ https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity). Your proposed solution doesn't really address the problem since if you control an old authority set you could still make authority set changes to other keys you control, and successfully build an alternative history. Smoldot (a light client for polkadot-based chains), implements the checkpointing approach described in the links above to work around this issue (https://raw.githubusercontent.com/smol-dot/smoldot/main/demo-chain-specs/polkadot.json see lightSyncState section). Polkadot full-nodes provide an RPC endpoint that can be used to generate this checkpoint (https://github.com/paritytech/polkadot-sdk/blob/master/substrate/client/sync-state-rpc/src/lib.rs#L131).

Regarding ForcedChanges these are effectively a coordinated hard fork of the GRANDPA authority set, so the chain of trust is broken, hence why they're not part of warp sync proofs. These are only meant to be used to recover from a disaster scenario (e.g. more than 1/3 of the validators go offline and permanently lose access to their session keys).