NewProofBuilder operates in terms of tree size #622
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
roger2hk
approved these changes
Apr 28, 2025
|
|
||
| span.SetAttributes(logSizeKey.Int64(otel.Clamp64(cp.Size))) | ||
|
|
||
| func NewProofBuilder(ctx context.Context, treeSize uint64, f TileFetcherFunc) (*ProofBuilder, error) { |
Contributor
There was a problem hiding this comment.
Do we need to mention "no correctness checking of the root hash for the given tree size is performed." in this function doc comment?
Collaborator
Author
There was a problem hiding this comment.
I don't think so, it's probably more surprising that a call to this function would go off and start making network requests before calling one of the .*Proof functions below.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR makes
NewProofBuilderrequire only a tree size, rather than a fullcheckpoint.This is safe as generated proofs must be verified against checkpoint root hashes by the consumer anyway; any inconsistency will be detected at that point, and brings it into line with most other proof building implementations (Trillian, GoSumDB, tlog, etc.)
The change provides a means to construct consistency proofs without having to hold both checkpoints (e.g. if you're trying to convince someone else of consistency between a checkpoint they hold, and a newer checkpoint you hold - this is exactly what happens during the tlog-witness protocol).