3

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?

2 Answers 2

3

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.

2
  • Thank you for your answer @adrian While going thru the WarpSyncProof, I noticed that it only checks for scheduled changes... github.com/paritytech/substrate/blob/… What about forced changes? Wouldn't a force change break verification here? Commented Aug 27, 2023 at 15:04
  • Also, a bit off-topic, WarpSyncProof doesn't seem to address the fact that an old validator set can always still provide a divergent view of the chain (since old validators are not under the threat of slashing) and that we need to bootstrap our observer correctly so that it can follow the chain within the "slashing window". Commented Aug 27, 2023 at 15:04
3

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).

1
  • Thank you for the response! I'll look into the links and info you have provided. Commented Aug 31, 2023 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.