Feat: fat checkpoints #95
Open
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.
Close #92
Supports two types of checkpoints:
BundleState).a fully squashed view of all diffs up to that point.
Fat checkpoints act as skip-list anchors, speeding up state lookups and
reducing the cost of traversing the checkpoint chain.
Checkpoint Chain Structure
Each checkpoint internally stores:
prev: the previous checkpoint in the linear history,mutation: either a barrier or the execution result of a tx/bundle,fat_ancestor: an optional link to the closest previous fat checkpoint,accumulated_state:Nonefor light checkpoints,Somefor fat ones.The chain always forms a backward-linked list:
Fat checkpoints (*) introduce skip-edges
allowing fast traversal backward through accumulated state windows.
How Accumulated State Is Built
A checkpoint becomes fat when
.fat()is invoked on it. The accumulationlogic depends on whether a fat ancestor exists.
Case 1: No Fat Ancestor Exists
This happens near the beginning of the block, before any fat checkpoint is
created. The accumulated state is built by squashing all diffs from the
start of the chain up to this checkpoint:
This creates a baseline-accumulated snapshot.
Case 2: A Fat Ancestor Exists
Let the history be:
When C6 becomes fat, we do not reuse accumulated state1–state3.
Instead, we start from C4 and only apply from there as the fat ancestor
checkpoint already includes its own diff:
State Lookup Logic
Given a checkpoint
C9(light), state access proceeds through these layers:state9)C6.fat_ancestor-> C3This ensures:
TLDR
fat checkpoint.
fat_ancestorprovides skip-list–style acceleration by linking fatcheckpoints together.