bench: prototype deterministic multiscale history anchors - #37
Open
runyuan-wang wants to merge 1 commit into
Open
runyuan-wang wants to merge 1 commit into
runyuan-wang wants to merge 1 commit into
Conversation
9 tasks
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
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.
Summary
deterministic multiscale anchor per eligible Commit;
v0.1.4 benchmark registration/evidence.
Author: Wang Runyuan
Motivation
LayerFS already supports direct lookup of a known Commit and direct Merkle-root
content Diff. The remaining question is narrower: Branch membership validation
currently walks
parent_commit_id, andDiffRequest::BranchCommitsperformsthat validation before content Diff. This prototype measures whether a tiny,
derived cross-scale sidecar can reduce that planning work as history grows.
This is inspired by established skip indexing, Git commit-graph, and Merkle DAG
lineage precedents. Spectral sparsification is only a design analogy; this PR
makes no LayerFS theorem claim.
Design
For Commit ordinal
i, the multiscale sidecar stores one ancestor at distancelowbit(i)when the distance exceeds one. The rule is deterministic,non-adaptive, and rebuildable from canonical history. A fixed checkpoint route
stores one 10-Commit jump at eligible positions.
The sidecars are in memory only. They are not authoritative and never enter the
Store. Deleting them leaves the original history fully usable.
Evidence
Two formal runs used identical deterministic fixtures at depths 1, 10, 100, and
1000. Every result matched the current public operations exactly, and the Store
database bytes, counts, canonical storage, and Commit IDs remained unchanged.
At depth 1000, the compact logical metadata budget is 0.957% of Store bytes.
Direct known-Commit lookup already visits zero parent nodes and is not improved.
Returning complete history is also still linear. The measured benefit is limited
to ancestry validation and Branch-Commit Diff planning.
Validation
cargo fmt --checkcargo test— 4/4 prototype tests passcargo clippy -- -D warningspython3 verify.py --output results/analysis.json— all gates pass1e81e9bScope boundaries
This PR does not propose a production persistence format or threshold, modify
the formal v0.1.4 benchmark contract, optimize direct historical reads, add
changed-path Bloom filters, or claim that sparse anchors are universally better.
It supplies a small reproducible experiment for deciding whether a later Store
index design is worth discussing.