Miner (hopefully) faster sync, faster startup if submission made #1015
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
kronosapiens
reviewed
Feb 3, 2022
area
force-pushed
the
maint/miner-client
branch
from
39257ac to
1176115
Compare
kronosapiens
previously approved these changes
Feb 7, 2022
area
force-pushed
the
maint/miner-client
branch
from
3b62891 to
7a795ed
Compare
kronosapiens
approved these changes
Feb 8, 2022
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.
Two (mostly) unrelated improvements:
When syncing past cycles, no need to make the justification tree - they're historical, the time for disputes has passed, so no need to prepare for how we might respond to a dispute. This could be better; some of the lifting to work out keys/values is still done, it's just that the tree that the values are added to performs no-ops and returns nothing, rather than actually building the tree, and so will return quicker than generating the tree and associated proofs. I did is this way because it was easier than picking apart all the bits that generate the justification tree, which are a bit scattered.
Fast-resume if we've made a submission to the cycle. When we generate the next reputation state and save it to the DB, I also save the data required to recreate the justification tree to a json file (not the database, as this is only needed temporarily and does not need to be queried by the oracle). If we've submitted and the miner restarts, it can see that it submitted, and load that state out of the DB and the Justification Tree out of the temporary file, rather than loading the previous state and (re-)applying the reputation update log. This should be a lot quicker, which is good if a restart happens during a dispute, for example.