Repository navigation
feat: stop history pruning after certain checkpoint - #25656
Conversation
|
This will have to be ported manually to aztec-node. |
aa50227 to
6962aea
Compare
6962aea to
fa395e3
Compare
spalladino
left a comment
spalladino
left a comment
There was a problem hiding this comment.
Requesting changes: the new history validation also runs on nodes without a pin, and it changes startup and snapshot-sync behaviour for every v5 node. Details are in the inline comment on snapshot-sync.ts.
Written by Claude
| if (worldStateDirectory && (await hasWorldStateDatabase(worldStateDirectory))) { | ||
| await validateLocalWorldStateHistory(config, log, genesis); | ||
| if (historyStartCheckpoint !== undefined) { | ||
| log.info('Using existing world-state database with compatible retained history', { historyStartCheckpoint }); | ||
| return false; | ||
| } | ||
| } |
There was a problem hiding this comment.
IIUC what happens here is that if the historyStartCheckpoint is set, then we'll refuse to use a snapshot? I'm worried this could lead to excessively long syncing times. Maybe we could sync anyway, but regenerate world state from archive?
EDIT: I think I understand now. You cannot "backfill" world state entries you already pruned. So the best you can do is get a new archiver snapshot, an old world state one from another snapshot bundle, and then have world state sync the missing entries from the archiver. But that's extra complexity, so we stick with picking a snapshot with the old world state. Is that the case?
There was a problem hiding this comment.
no, the scenario is:
- we have local state
- our config is updated to say "we need to retain full history from this block onwards"
- node restarts (since it's an env var change)
- on boot we check if our local state is compatible. If it isn't (ie our local db has state from block N but env var says to keep state from block N - 100) we refuse to start
- otherwise we print the above log and continue.
There was a problem hiding this comment.
Why the submodule changes?
There was a problem hiding this comment.
I'll double check they are the same commits as v5-next but I hadn't bootstrapped properly before working on this code and committed with deleted submodules. See 6962aea
| if (checkpoint) { | ||
| maxSnapshotBlock = BlockNumber(checkpoint.startBlock + checkpoint.blockCount - 1); | ||
| } | ||
| throw new Error( | ||
| `Snapshot is at checkpoint ${latestBlock.checkpointNumber}, after requested checkpoint ${historyStartCheckpoint}`, | ||
| ); |
There was a problem hiding this comment.
I find this bit confusing. Why is it a problem for the snapshot to be at a later point in time than the requested history?
EDIT: I think I understand now: we want to sync from a snapshot that has an old archive and world state, so we can sync state and regen world state from there, without pruning, right?
fa395e3 to
3c139ba
Compare
3c139ba to
c08b2d1
Compare
2 participants
Allow pinning history to a certain checkpoint number.
Related to A-2390