Avoid reprocessing deposits at startup

[ajsutton]

Description

Currently at startup Teku loads all deposits from disk and replays them to recreate the merkle tree. We should investigate ways to store the merkle tree to disk instead to avoid the need to replay these deposits.

I believe you can just store the right hand edge of the tree since deposits always append but we'd likely have to update our merkle tree implementation to handle that.

Also need to ensure we can still create blocks that may need to get the merkle tree root omitting some of the more recent deposits (ie we may have received up to deposit 1000, but the Eth1Data in the current state is only at deposit 900, so we need to act as if we had a merkle tree only containing the 900 deposits).

[rolfyone]

potentially related: https://eips.ethereum.org/EIPS/eip-4881

[ajsutton]

New deposit merkle tree supporting snapshots has now been integrated but we're not actually using the snapshot functionality to avoid replaying deposits.

[zilm13]

I think I got a clear view on this finally and think it could be split into several PRs:

1. Teku API to get finalized snapshot
2. Teku flag to start from snapshot file (not sure on format) and perform all block events stuff without relying on its DB, instead query EL for everything
3. Teku flag to make snapshot part of OnDiskStoreData, saving and loading to be able to restart without file option
4. Optimization PR to not validate deposits which are already in finalized tree
5. Remove block deposit events from DB

After 2nd we could be confident on performance of the approach and adjust a plan

[ajsutton]

Yep I think that looks good. The snapshot format should just be the DepositTreeSnapshot from the spec (SSZ encoded).

[zilm13]

@ajsutton I think we could close this one as completed.
Do I need to add something to docs or Changelog?
EIP https://eips.ethereum.org/EIPS/eip-4881 is still in draft.
There is API PR, but still not merged ethereum/beacon-APIs#245
Looks like we should keep everything in "--X"

[ajsutton]

I think we keep it open as long as the options are still --X since we're not supporting the feature yet. And we also want to include a deposit snapshot in our releases to avoid having to load all the deposits initially (which lets ELs prune data more aggressively). Possibly that should be a separate ticket as we need to work out a decent way to keep them reasonably up to date.

[zilm13]

Got you

And we also want to include a deposit snapshot in our releases to avoid having to load all the deposits initially

I forgot about this part, will try do something for it

[zilm13]

Completed with #7039