Skip to content
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
This repository was archived by the owner on Nov 15, 2023. It is now read-only.

grandpa: cleaner RPC API for proving finality #7115

@andresilva

Description

@andresilva

In #6215 we introduced an RPC API for proving finality of arbitrary blocks by using the existing FinalityProofProvider infrastructure but the current API is rather cumbersome to use. The existing API is:

fn prove_finality(
  begin: Hash, 
  end: Hash, 
  authorities_set_id: u64,
) -> Option<Vec<FinalityProof>>>;

It requires that a user of the API keep track of the authorities set id and also of block ranges spanning a given set. I think we should be able to implement the following API:

fn prove_finality(block: Hash) -> Option<FinalityProof>;

The way this API would work is that it would always generate a finality proof based on the justification from the last block in the set (which is always guaranteed to be persisted).

If a user wants to prove finality for block #52 we figure out what the set id is for that block and what the last block in the session was. Then we have all the data needed for FinalityProofProvider to generate the proof. I think the only thing we need to do is to start persisting the block number of the last block of the authority set so we get a Vec<BlockNumber>. Given any block number we could then perform binary search on this array to figure out what the last block in the set was (and implicitly the set id given by the index in the array).

For some service that is trying to sync and check for finality they would:

  • prove_finality(#1), for which they would get a finality proof that proves finality of all blocks up until the last block in the set;
  • this proof will include all of the block headers, so they can just import them if needed (although it might make sense to make the inclusion in the proof optional and just provide block hashes);
  • they will also now be able to tell what the first block in the next authority set is (i.e. last block in previous finality proof + 1);
  • they loop this process until they get None finality proof, which means they'll be on the latest authority set;
  • afterwards they can start listening to the live justifications using the pubsub API.

Metadata

Metadata

Assignees

Labels

J0-enhancementAn additional feature request.U2-some_time_soonIssue is worth doing soon.Z2-mediumCan be fixed by a coder with good Rust knowledge but little knowledge of the codebase.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions