Goal
Add a keeper crate that owns the consistency boundary between accountsdb and ledger, and exposes one API for the transaction processor and SVM runtime.
Why
accountsdb stores account state. ledger tracks transaction and execution results along with block/slot context. Those two views must stay synchronized so runtime code does not duplicate consistency logic.
Scope
- Define the
keeper crate and its API boundary.
- Define the coordination path that pairs account-state changes in
accountsdb with execution/result recording in ledger.
- Keep
accountsdb and ledger invariants aligned after each transaction or slot.
- Make the API usable from both the transaction processor and the SVM runtime.
Constraints
- Start with the smallest correct surface.
- Avoid validator-style flow and keep the design execution-engine oriented.
Goal
Add a
keepercrate that owns the consistency boundary betweenaccountsdbandledger, and exposes one API for the transaction processor and SVM runtime.Why
accountsdbstores account state.ledgertracks transaction and execution results along with block/slot context. Those two views must stay synchronized so runtime code does not duplicate consistency logic.Scope
keepercrate and its API boundary.accountsdbwith execution/result recording inledger.accountsdbandledgerinvariants aligned after each transaction or slot.Constraints