docs: add docs and details for the differential state archive #7049
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## feature/differential-archive #7049 +/- ##
=============================================================
Coverage 49.24% 49.25%
=============================================================
Files 578 578
Lines 37443 37443
Branches 2168 2172 +4
=============================================================
+ Hits 18440 18441 +1
+ Misses 18963 18962 -1
Partials 40 40 |
twoeths
reviewed
Aug 26, 2024
| @@ -0,0 +1,79 @@ | |||
| --- | |||
| title: Understanding Historical Sate Regeneration | |||
There was a problem hiding this comment.
Suggested change
| title: Understanding Historical Sate Regeneration | |
| title: Understanding Historical State Regeneration |
twoeths
reviewed
Aug 26, 2024
|
|
||
| **Approach** | ||
|
|
||
| Assume we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, The following configuration for layers implies: |
There was a problem hiding this comment.
Suggested change
| Assume we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, The following configuration for layers implies: | |
| Assume we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, the following configuration for layers implies: |
There was a problem hiding this comment.
Suggested change
| Assume we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, The following configuration for layers implies: | |
| Assume we have the following chain representing the state object of every slot, with the following diff layer configurations `1,2,3,5`. With the assumption that we have 8 slots each epoch, the following configuration for layers implies: |
nflaig
reviewed
Aug 26, 2024
|
|
||
| # Understanding Historical Sate Regeneration | ||
|
|
||
| To run a blockchain client and establish consensus we need latest headers and forkchoice data. This operation does not require to historical data, specially after the epochs which are finalized. Storing the full state information for the finalized slots increase the storage requirement a lot and not suitable for running the node for long time. |
There was a problem hiding this comment.
Suggested change
| To run a blockchain client and establish consensus we need latest headers and forkchoice data. This operation does not require to historical data, specially after the epochs which are finalized. Storing the full state information for the finalized slots increase the storage requirement a lot and not suitable for running the node for long time. | |
| To run a blockchain client and establish consensus we need latest headers and fork choice data. This operation does not require access to historical data, especially after the epochs which are finalized. Storing the full state information for the finalized slots increase the storage requirement a lot and not suitable for running the node for long time. |
|
|
||
| ## Solution | ||
|
|
||
| To overcome the storage problem for the archive nodes we implemented following algorithm to store and fetch the historical sates. |
There was a problem hiding this comment.
Suggested change
| To overcome the storage problem for the archive nodes we implemented following algorithm to store and fetch the historical sates. | |
| To overcome the storage problem for the archive nodes, we implemented the following algorithm to store and fetch the historical states. |
|
|
||
| **Approach** | ||
|
|
||
| Assume we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, The following configuration for layers implies: |
There was a problem hiding this comment.
Suggested change
| Assume we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, The following configuration for layers implies: | |
| Assume we have the following chain which represents the state object every slot, with following diff layer configurations `1,2,3,5`. With the assumption that we have 8 slots each epoch, the following configuration for layers implies: |
| 5. For slot `34` the path we follow `32 -> 24 -> 0`. | ||
| 6. For slot `41` path for the nearest snapshot slot is just one layer directly at slot `40`. | ||
|
|
||
| As you can see with this approach we can find a shorter paths with smaller number of diffs to apply, which generate the nearest full state and reduce the number of blocks we have to replay to reach to actual slot. |
There was a problem hiding this comment.
Suggested change
| As you can see with this approach we can find a shorter paths with smaller number of diffs to apply, which generate the nearest full state and reduce the number of blocks we have to replay to reach to actual slot. | |
| As you can see with this approach we can find shorter paths with smaller number of diffs to apply, which generate the nearest full state and reduce the number of blocks we have to replay to reach the actual slot. |
| \end{align*} | ||
| $$ | ||
|
|
||
| As there are lot of parameters in the system and we don't have accurate values for these so we started few possible estimates. Also as the chain is ever growing data structure the value for `F` is not finite. We decided to do this estimation based on 30 days time period and `mainnet` parameters. |
There was a problem hiding this comment.
Suggested change
| As there are lot of parameters in the system and we don't have accurate values for these so we started few possible estimates. Also as the chain is ever growing data structure the value for `F` is not finite. We decided to do this estimation based on 30 days time period and `mainnet` parameters. | |
| As there are lot of parameters in the system and we don't have accurate values for these so we started few possible estimates. Also as the chain is a ever growing data structure, the value for `F` is not finite. We decided to do this estimation based on 30 days time period and `mainnet` parameters. |
| T_{diff} &= \text{Time to take differential backup}\\ | ||
| T_{replay} &= \text{Time to replay a block}\\ | ||
| R_{full} &= \text{Time to restore full backup}\\ | ||
| R_{diff} &= \text{Tiem to restore differential backup}\\ |
There was a problem hiding this comment.
Suggested change
| R_{diff} &= \text{Tiem to restore differential backup}\\ | |
| R_{diff} &= \text{Time to restore differential backup}\\ |
| title: Understanding Historical Sate Regeneration | ||
| --- | ||
|
|
||
| # Understanding Historical Sate Regeneration |
There was a problem hiding this comment.
Suggested change
| # Understanding Historical Sate Regeneration | |
| # Understanding Historical State Regeneration |
philknows
reviewed
Aug 26, 2024
|
|
||
| Based on these assumptions and system we decided for the following constants. | ||
|
|
||
| | Name | Value | Description | |
There was a problem hiding this comment.
Please also run yarn docs:lint:fix for prettier to fix this table
ensi321
reviewed
Aug 27, 2024
|
|
||
| # Understanding Historical Sate Regeneration | ||
|
|
||
| To run a blockchain client and establish consensus we need latest headers and forkchoice data. This operation does not require to historical data, specially after the epochs which are finalized. Storing the full state information for the finalized slots increase the storage requirement a lot and not suitable for running the node for long time. |
There was a problem hiding this comment.
Suggested change
| To run a blockchain client and establish consensus we need latest headers and forkchoice data. This operation does not require to historical data, specially after the epochs which are finalized. Storing the full state information for the finalized slots increase the storage requirement a lot and not suitable for running the node for long time. | |
| To run a blockchain client and establish consensus we need the latest headers and forkchoice data. This operation does not require to historical data, specially after the epochs are being finalized. Storing the full state information for the finalized slots increase the storage requirement a lot and is not suitable for running the node for long time. |
|
|
||
| **Approach** | ||
|
|
||
| Assume we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, The following configuration for layers implies: |
There was a problem hiding this comment.
Suggested change
| Assume we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, The following configuration for layers implies: | |
| Assuming we have following chain represents the state object every slot, with following diff layer configurations `1,2,3,5`. With assumption that we have 8 slots each epoch, The following configuration for layers implies: |
| Let's take few scenarios: | ||
|
|
||
| 1. For slot `0` all layers collide, so we use the lowest layer which is the snapshot layer. So for the slot `0` we store and fetch the snapshot. | ||
| 2. For slots (0-7) within first epoch we there is no intermediary layer, so we read the snapshot from slot `0`. |
There was a problem hiding this comment.
Suggested change
| 2. For slots (0-7) within first epoch we there is no intermediary layer, so we read the snapshot from slot `0`. | |
| 2. For slots (0-7) within the first epoch, there is no intermediary layer, so we read the snapshot from slot `0`. |
| 1. For slot `0` all layers collide, so we use the lowest layer which is the snapshot layer. So for the slot `0` we store and fetch the snapshot. | ||
| 2. For slots (0-7) within first epoch we there is no intermediary layer, so we read the snapshot from slot `0`. | ||
| 3. For slots (8-15) the path we follow is `8 -> 0`. e.g. For slot `12`, we apply diff from slot `8` on snapshot from slot `0`. Then we replay blocks from 9-12. | ||
| 4. For slot `18` the shortest path to nearest snapshot is `16 -> 0` and rest will follow same as above. |
There was a problem hiding this comment.
Suggested change
| 4. For slot `18` the shortest path to nearest snapshot is `16 -> 0` and rest will follow same as above. | |
| 4. For slot `18` the shortest path to nearest snapshot is `16 -> 0` and the rest will follow same as above. |
| \end{align*} | ||
| $$ | ||
|
|
||
| As there are lot of parameters in the system and we don't have accurate values for these so we started few possible estimates. Also as the chain is ever growing data structure the value for `F` is not finite. We decided to do this estimation based on 30 days time period and `mainnet` parameters. |
There was a problem hiding this comment.
Suggested change
| As there are lot of parameters in the system and we don't have accurate values for these so we started few possible estimates. Also as the chain is ever growing data structure the value for `F` is not finite. We decided to do this estimation based on 30 days time period and `mainnet` parameters. | |
| As there are lot of parameters in the system and we don't have accurate values for these. we started with few possible estimates. Also as the chain is an ever- growing data structure, the value for `F` is not finite. We decided to do this estimation based on 30 days time period and `mainnet` parameters. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Add docs explaining differential state archive.
Description
Keep the reference docs updated.
Steps to test or reproduce