fix(cryptarchia): don't include not-yet-pruned blocks in the service state #1398
+42
−104
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.
1. What does this PR implement?
As described in many code comments, we defined the
CryptarchiaConsensusState
(which is for recovery) to storeprunable_blocks
as well as the tip and the LIB.Here, the
prunable_blocks
means the blocks 8000 which were pruned from memory (cryptarchia engine) but not from storage.It's good. But in the current implementation, the
CryptarchiaConsensusState
was also storing blocks that are not yet pruned in the cryptarchia engine.Whenever we rebuild the
CryptarchiaConsensusState
, we fetch prunable blocks from the cryptarchia engine and include them into theCryptarchiaConsensusState
.However, those blocks don't need to be included because they are not yet pruned in the cryptarchia engine.
This PR simply removes fetching prunable blocks from the cryptarchia engine.
We should build
CryptarchiaConsensusState
only with the providedprunable_blocks
, which were already pruned from memory but not from storage.Even after this change, the consensus service should work as before, because we anyway prune blocks right before rebuliding the
CryptarchiaConsensusState
. In other words, the previous implementation has worked well, but had an unnecessary call of fetching prunable blocks, which may cause side effects in the future.(FYI, this PR is one of preparations for implementing chain bootstrapping.)
2. Does the code have enough context to be clearly understood?
Yes
3. Who are the specification authors and who is accountable for this PR?
but adding @ntn-x2 @strinnityk as reviewers who have heavily contributed to the state recovery and pruning.
4. Is the specification accurate and complete?
Yes
5. Does the implementation introduce changes in the specification?
No
Checklist
Warning
Do not merge the PR if any of the following is missing: