-
Notifications
You must be signed in to change notification settings - Fork 990
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
The Header MMR (One MMR To Rule Them All) #1716
Merged
Merged
Conversation
This file contains 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
6 tasks
works with fast sync not yet in place for initial header sync
rebuild header MMR after we validate full txhashset after download
antiochp
force-pushed
the
simple_header_mmr
branch
from
October 11, 2018 19:12
f3ba4cd
to
59232ae
Compare
no need to pass position when appending
Sugarraidd
approved these changes
Oct 15, 2018
antiochp
changed the title
[WIP] The Header MMR (one MMR to rule them all)
The Header MMR (One MMR To Rule Them All)
Oct 15, 2018
Merging. |
antiochp
added a commit
to antiochp/grin
that referenced
this pull request
Oct 15, 2018
* header MMR in use within txhashset itself works with fast sync not yet in place for initial header sync * add the (currently unused) sync_head mmr * use sync MMR during fast sync rebuild header MMR after we validate full txhashset after download * support missing header MMR (rebuild as necessary) for legacy nodes * rename to HashOnly * cleanup backend.append() * simplify vec_backend to match simpler append api
antiochp
added a commit
that referenced
this pull request
Oct 15, 2018
* header MMR in use within txhashset itself works with fast sync not yet in place for initial header sync * add the (currently unused) sync_head mmr * use sync MMR during fast sync rebuild header MMR after we validate full txhashset after download * support missing header MMR (rebuild as necessary) for legacy nodes * rename to HashOnly * cleanup backend.append() * simplify vec_backend to match simpler append api
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
txhashset
header_head
)sync_head
)txhashset::extending
now extends header MMR (in addition to output, rangeproof, kernel)txhashset::readonly_extending
extends header MMR (in addition to output, rangeproof, kernel)txhashset::header_extending
extends header MMR in isolation (for header validation, where we do not yet have full blocks)txhashset::sync_extending
extends sync MMR only (for handling batches of headers during sync)txhashset.zip
receiving node now re-builds header MMR based on headers in db prior to validating the reconstructed txhashsetheader_head
- this allows us to safely rewind and reapply headers as necessary based on current most work chainNone of this is consensus breaking, we just add the MMRs in this PR.
Consensus breaking changes will come in a separate PR.
TODO (this PR) -
Optimizerebuild_header_mmr()
andrebuild_sync_mmr()
or are they acceptable for now?skiprewind()
on "next header" forheader_extending
andsync_extending
.header_head
- confirm this is ok if/whenhead
andheader_head
differ.chain::init()
TODO (potentially separate PR) -
header.previous
withheader.prev_root
.prev_root
prior when validating blocks and headers.Optimizations/Improvements to think about -
rewind()
on "next header" during header extension (we can live without this initially).