Substrate: Expose GRANDPA finality API

[octol]

To support bridges better we need to expose GRANDPA finality. We are going to need two types of APIs:

1. Subscription based API where we continuously stream finality proofs (justifications) as they become available. This has been started at #5732 and is now merged!
2. On demand API that clients can use to fill in missing proofs. This has been started at #6215 and is now merged!

The next step is tracked by #7115

CC: @andresilva

[andresilva]

For the on-demand API I was thinking that the API should be something like grandpa_proveFinality(Hash) -> Option<FinalityProof>.

@svyatonik I was thinking that we could use FinalityProof's for this since they allows us to prove finality for an arbitrary block using a justification of a later block (which is important since we won't have justifications for all blocks). But you mentioned the other day that the light client could use the full-node GrandpaBlockImport instead in which case the finality proofs would no longer be necessary. Any comments on this?

@tomusdrw Would you mind sharing a brief overview of the use-case of these APIs for bridges? There are some details about authority set changes that may need to be addressed and having a better picture of the use-case would help make sure that the API provides what we need.

[svyatonik]

Yes - I was thinking of switching regular light block import from using FinalityProofs to Justifications - now when we have all required information in digests, I do not see any point in maintaining separate code path for light client. We may still keep FinalityProof as a separate entity, though, if it is useful to anyone.

[tomusdrw]

The use case for bridges is:

1. Subscription: Get headers that are finalized by Grandpa in real time, by subscribing to a stream of notifications. We are not interested in ALL blocks that become finalized, but only the ones that there exists Justification for. Basically as soon as the client imports a justification for some block, we want this information to be emitted via RPC. The payload should contain the header details and the justification itself, so that it can be relayed to some other "light client" (namely on-chain light client), where we can import & verify the finality proof (or justification).
2. On Demand: When the bridge (or rather relayer: think "on-chain light client") goes offline, and then goes back on-line it should be able to request the latest finalized header over RPC and should get the same data as required by Subscription API. AFAICT it will also require the caller to provide last finalized header it knows of, so the RPC should prepare a proof that includes all intermediate headers (and validator set chages, etc).

[octol]

Thanks very much @tomusdrw and @svyatonik for the input :)

I started working on a draft at #6215. Still a bit to go though as that mainly just querying the existing FinalityProofProvider

[octol]

Follow up issue to refine this further here #7115

[bkchr]

@octol so this issue can be closed?

[octol]

@octol so this issue can be closed?

I think we can close it as soon as #6215 is merged

[octol]

With #6215 merged we can probably close this now. As mentioned earlier, the next step is tracked by #7115