# Snapshots

1. Restore full nodeDB data and the latest 128 executor states.
**pros:**
`This will allow to reduce the restore time.`
**cons:**
`
1. The backup time will increase as we need to follow the full smt to save only the require information.`
`
2. This would avoid to query info in a certain block. For instance: get the account nonce in this specific block.
`
2. Restore everthing in node and executor.
**pros:**
`Full functionality. Everything included`
**cons:**
`1. Executor backup time (~1h). Testnet size 20GB and XGB compressed`
`2. Executor restore time will be huge (~10h and raising)`

### Avoid storing the statedb executor information on the node config file:
Create a new proto or edit one of the current protos to allow access the statedb directly (getNodeByKey) or call methods for backup and restore.

### Geth sync:
**Snaps:**
Snap sync starts from a relatively recent block and syncs from there to the head of the chain, keeping only the most recent 128 block states in memory. The block header to sync up to is provided by the consensus client. Between the initial sync block and the 128 most recent blocks, the node stores occasional snapshots that can be used to rebuild any intermediate state "on-the-fly". The difference between the snap-synced node and a full block-by-block synced node is that a snap synced node started from an initial checkpoint that was more recent than the genesis block. Snap sync is much faster than a full block-by-block sync from genesis.


Summary:
1. **Download and verify headers of the blocks:** Snap sync works by first downloading and verifying the headers for a chunk of blocks.
2. **Download block bodies and receipts. In parallel, download raw state data and build state trie:** To sync the state trie, Geth first downloads the leaves of the state trie for each block without the intermediate nodes along with a range proof. The state trie is then regenerated locally.
3. **Heal state trie to account for newly arriving data:** While the state is being downloaded, the blockchain is also progressing at the same time and invalidating some of the regenerated state data. This means it is also necessary to have a 'healing' phase where errors in the state are fixed. It is not possible to monitor the progress of the state heal because the extent of the errors cannot be known until the current state has already been regenerated.

**CheckPoints:** The approach that we try to follow. Downloading the infor from a relied source and start syncing from there.

###### Note: more info at https://geth.ethereum.org/docs/fundamentals/sync-modes