Endpoint for querying light blocks. #50
Conversation
| // If true, indicates that the light client is not aware of the current epoch finalization | ||
| // committee for it's highest finalized block. | ||
| bool current_committee_unknown = 3; | ||
| // If true, indicates that the light client is not aware of the next epoch finalization | ||
| // committee for it's highest finalized block. | ||
| bool next_committee_unknown = 4; | ||
| // If true, the response should include a proof of the next epoch finalization committee for | ||
| // the 'to' block. | ||
| bool next_committee_required = 5; |
There was a problem hiding this comment.
Discussion: I am not so sure about having these flags, since they will result in the parsed return type having options for this information, but the user specified whether they are present already.
I find that it is usually better for an API to introduce separate functions instead of flags, since it eliminates the error handling of the option.
Also, do we need this many flags? Maybe we could have a separate entry point, just with a proof of current and next committee for a given block or just always provide them as part of this entrypoint.
| // Representation of a generic Merkle proof. | ||
| // A Merkle proof can be canonically converted to a root hash by converting each of its | ||
| // branches to bytes, concatenating them, and then taking the SHA256 hash of the result. | ||
| message MerkleProof { |
There was a problem hiding this comment.
Suggestion: On top of this, we should probably have new type wrappers for each type of merkle proof that we will expose.
|
|
||
| // Branches of a Merkle proof. | ||
| // A Merkle branch is either raw data bytes or a sub-Merkle proof. | ||
| message MerkleBranch { |
There was a problem hiding this comment.
Suggestion: Consider moving this into MerkleProof as a sub-type.
| message LightBlocksItem { | ||
| oneof item { | ||
| // A finalization entry proving that a block is finalized, and checkable knowing | ||
| // the finalization committee for the epoch of the block. | ||
| EpochFinalizationEntry finalization_entry = 1; | ||
| // A Merkle proof of what the next or current epoch finalization committee is for a block. | ||
| MerkleProof committee_proof = 2; | ||
| } | ||
| } |
There was a problem hiding this comment.
I have been a while since we talked about this, but could we avoid the oneof by making the committee_proof an optional field?
I think this makes more sense, since the committee_proof is tied to a finalization_entry which has to be emitted right before it.
| message LightBlocksItem { | |
| oneof item { | |
| // A finalization entry proving that a block is finalized, and checkable knowing | |
| // the finalization committee for the epoch of the block. | |
| EpochFinalizationEntry finalization_entry = 1; | |
| // A Merkle proof of what the next or current epoch finalization committee is for a block. | |
| MerkleProof committee_proof = 2; | |
| } | |
| } | |
| message LightBlocksItem { | |
| // A finalization entry proving that a block is finalized, and checkable knowing | |
| // the finalization committee for the epoch of the block. | |
| EpochFinalizationEntry finalization_entry = 1; | |
| // A Merkle proof of what the next or current epoch finalization committee is for a block. | |
| optional MerkleProof committee_proof = 2; | |
| } |
Purpose
Add a GRPC endpoint for querying light client blocks. This returns a stream of proofs that can be used to catch up a light client from one block to another.
Changes
Checklist
hard-to-understand areas.