Open claravanstaden opened 1 year ago
@g11tech I see you changed the issue title from "last update" to "best update". I am not sure "best update" will work, because say in sync period (of 64
slots) 1 the best update is slot 10
, and in the next update the best update is slot 120
, there will be a where the beacon state won't contain block roots for slots 11
-63
. Unless I misunderstand how the best update works, maybe it already looks at the most recent block in a sync committee period.
If the period is 64 slots:
so period 0 's best update is slot 10 and has lets say finalized header at slot 6 period 1's beast update us slot 120 and lets say has finalized header at slot 100
So 2 states will be store for slot 6, 100
Does this make it clear and usable for you?
That won't work for my use case, because block_roots
only stores 64
block roots, so the two saved states will not cover slots 7
- 36
.
ok will reach out to you to understand your usecase
Is your feature request related to a problem? Please describe.
A light client might require the beacon state for all sorts of state proofs. In my case, I would like to use
block_roots
for ancestry proofs. I have a finalized beacon header, and now want to provide that a beacon header is an ancestor of the finalized header. To do that, I need at least one finalized header beacon state per sync committee period to import older beacon blocks.Describe the solution you'd like
A flag to optionally persist the last finalized header beacon state on disk. A nice extra would be to say how many states should be persisted (e.g. 50, and if there are more states they will pruned).
Describe alternatives you've considered
I could update this parameter myself: https://github.com/ChainSafe/lodestar/blob/unstable/packages/beacon-node/src/chain/archiver/archiveStates.ts#L12
Additional context
Context on Discord: https://discord.com/channels/593655374469660673/621838504955084830/1074751947728498811