-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Endpoint for querying light blocks. #50
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -3540,3 +3540,53 @@ message DryRunSuccessResponse { | |||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
// A request from a light client to catch up from a trusted block to a subsequent finalized | ||||||||||||||||||||||||||||||||||
// block. | ||||||||||||||||||||||||||||||||||
message LightBlocksRequest { | ||||||||||||||||||||||||||||||||||
// The highest finalized block currently trusted by the light client. | ||||||||||||||||||||||||||||||||||
BlockHashInput from = 1; | ||||||||||||||||||||||||||||||||||
// The target finalized block to catch the light client up to. | ||||||||||||||||||||||||||||||||||
// The request will fail if this is not descended from the 'from' block. | ||||||||||||||||||||||||||||||||||
BlockHashInput to = 2; | ||||||||||||||||||||||||||||||||||
// 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; | ||||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
// 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Suggestion: On top of this, we should probably have new type wrappers for each type of merkle proof that we will expose. |
||||||||||||||||||||||||||||||||||
// The branches of the Merkle proof. | ||||||||||||||||||||||||||||||||||
repeated MerkleBranch branches = 1; | ||||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
// 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Suggestion: Consider moving this into |
||||||||||||||||||||||||||||||||||
oneof branch { | ||||||||||||||||||||||||||||||||||
// Raw data bytes. For this case, 'raw_data' is the representation of the branch | ||||||||||||||||||||||||||||||||||
// as bytes. | ||||||||||||||||||||||||||||||||||
bytes raw_data = 1; | ||||||||||||||||||||||||||||||||||
// A sub-proof. For this case, the root hash of 'sub_proof' is the representation | ||||||||||||||||||||||||||||||||||
// of the branch as bytes. | ||||||||||||||||||||||||||||||||||
MerkleProof sub_proof = 2; | ||||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
// An item produced in response to a `LightBlocksRequest`. | ||||||||||||||||||||||||||||||||||
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; | ||||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||||
Comment on lines
+3584
to
+3592
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have been a while since we talked about this, but could we avoid the
Suggested change
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.