RPC for receiving proofs towards execution outcome for the light client

[MaksymZavershynskyi]

We need to add an RPC endpoint that given the following:

• Transaction or receipt id;
• Current head of the light client.

Returns:

• The proof of this execution outcome that can be verified by the light client using the head block. The proof should include:

  • The merkle path in the head merkle tree towards the block that includes the execution outcome;
  • The inner_rest_hash and BlockHeaderInnerLiteView of the block that includes execution outcome;
  • The merkle path in the block towards the execution outcome.

• If transaction/receipt is not known a special error should be returned;

• If head is behind the block that contains the outcome another special error should be returned;

• If head is not the part of the canonical chain a third special error should be returned.

We also need to do the following:

• Use structured RPC for this endpoint;
• We also need to add instructions on how to verify such proof following the format here: [Spec] Light Client NEPs#60 So that @k06a can implement it in Solidity;
• Expose it in near-api-js because that's what our bridge code is using.

[MaksymZavershynskyi]

Assigning to @bowenwang1996 since he is working on the light client implementation and setting priority to P0 since it is a blocker for the bridge implementation.

[bowenwang1996]

@nearmax from the light client side, if they want to verify the authenticity of a transaction are they going to need proofs to every single receipt generated by the transaction?

[MaksymZavershynskyi]

@bowenwang1996 For now they would need a proof to the receipt that did a specific function call. So this RPC endpoint will be used together with another RPC endpoint that returns receipts for the given transaction (I assume we have such RPC endpoint).

[bowenwang1996]

@nearmax just realized an issue while implementing this: proofs for execution outcomes are garbage collected so they will only be kept for five epochs. Will we run an archival node for the light client?

[MaksymZavershynskyi]

@nearmax just realized an issue while implementing this: proofs for execution outcomes are garbage collected so they will only be kept for five epochs. Will we run an archival node for the light client?

Yes, but for now, let's not focus on that.

[bowenwang1996]

@nearmax there is a missing piece in the merklization of things (we missed some proofs) -- that's why I am asking. If we think that using archival nods is fine, I'll add the proofs and garbage collect them so that we don't have to worry about the impact on disk usage too much.

[MaksymZavershynskyi]

@nearmax there is a missing piece in the merklization of things (we missed some proofs) -- that's why I am asking. If we think that using archival nods is fine, I'll add the proofs and garbage collect them so that we don't have to worry about the impact on disk usage too much.

Sounds good.

[MaksymZavershynskyi]

FYI. Missing part -- near-api-js wrapper. @bowenwang1996 volunteered to implement it.

[bowenwang1996]

Nearcore implementation: #2737
NEP spec: near/NEPs#78
near-api-js provider implementation: near/near-api-js#337