Provable Forking For Katana And Bonsai Trie
Remote forking infrastructure that starts from canonical state, materializes proof-backed paths, and recomputes local roots without full cloning.
Proof-backed forks without full-state cloning
A fork should avoid full-state cloning without losing root continuity or proof provenance.
Katana imports canonical state lazily; Bonsai `PartialTrie` and multiproofs keep root computation verifiable as local paths materialize.
- Boundary note
- Most of the evidence lives in infrastructure code and internal state flow, which is harder to explain than a user-facing product feature.Readers unfamiliar with tries need help understanding why imported-state correctness is a first-class concern.
- Evidence path
- Imported canonical state / Selective trie materialization / Proof-backed root continuityPublic proof lives in the Katana and Bonsai repos; linked PRs are the fastest entry points.
- What it proves
- Public evidence of sequencer and state-depth work
- Foundation for the sharding story because imported-state execution stays credible
How the data moves through the system
First read the data path. Then use the code hooks as pointers to the mechanisms that make the claim inspectable.
The fork starts from canonical remote state, not a full local clone.
Only touched paths materialize locally; proofs and cached nodes preserve root continuity.
Local roots recompute from partial imported structure without treating missing state as locally owned.
Forking becomes selective import through canonical updates, RPC reads, and proof-aware tries.
Missing nodes are inserted from proofs, not guessed or preloaded wholesale.
Local writes and later reads still produce roots explainable against imported proof data.
Cached proof nodes keep repeated reads and root checks from restarting at zero.
Unchanged keys keep original proof material while forked writes use cached nodes for later proof generation.
How the system progresses
A short staged view of the system from start to final output.
Import canonical remote state
The fork starts from canonical updates, not an eager clone.
Materialize only the proof-backed paths you need
The runtime fetches and materializes only required trie paths.
Recompute verifiable local roots with cache continuity
Lazy fetch, snapshots, and caching reduce startup cost without breaking root continuity.
Public proof lives in the Katana and Bonsai repos; linked PRs are the fastest entry points.
- Inspect Katana for canonical state updates, fork backend import, lazy RPC reads, and remote-state execution.
- Inspect Bonsai Trie for `PartialTrie`, `insert_with_proof`, multiproofs, cached proof nodes, and root continuity.
Finish the evidence first. The full-screen environment is the closing section.
Open the full-screen environment for this project
One project mechanism, isolated from the article.
Forked State: Proof Fetch View
Which proof nodes a fork fetches, how they fill a partial trie, and why roots stay verifiable.
Proof-fetch forking: start from a remote root, fetch needed proof nodes, fill the partial trie, compute a fork root.
Open environmentPartial Patricia Trie: Structure View
How Edge/Binary nodes form, proof nodes fill gaps, and a fork copies the partial trie.
A structure view for partial Patricia tries: edges, binary splits, root updates, and fork copies.
Open environment