[Feature] Reduce the Amount of DB Space the Beacon Chain Needs #71

New Issue

2022-06-24T12:55:37Z

abdulrabbani00 commented

2022-06-24 12:55:37 +00:00

(Migrated from github.com)

Overview
- Request
Potential Solution
- Alternative Solutions
Additional Context

Table of contents generated with markdown-toc

Overview

Requester: @abdulrabbani00
Epic Link: None yet.

Request

With the current estimations, we believe it would take about 396GB of day per day to store the beaconState.. This amount of data is unfeasible to store, therefore we need another solution.

Potential Solution

Store Intermediary States and Build the State as Needed.

One way to drastically reduce the footprint of the beaconState is to store every X number of states. We can ipld-lize these states. If someone asks for a beaconState in-between the intermediary states, the watchers can rebuild the state desired state on the fly.

Capture the BeaconState at Slot 128 and 256, write the raw states to the DB.
A client request comes in for slot 255.
We rebuild every intermediary state from 128-255 and serve it to the client.
i. The DB will contain the correct stateRoot, so we can check after rebuilding each state to ensure it was done correctly.
We do not write the newly calculated states to the DB.
i. If we ever see that there is a high demand for the beaconState, we can consider further solutions.
a. Storing the state closer together, instead of storing it every X slots we store it ever X/Y slots.

Alternative Solutions

Perhaps we don't store the BeaconState at all. It might make sense to have the watchers query the lighthouse client every time they want a BeaconState. If we use the highest SPRP offered, we can load the beaconState at a max of 155ms (best case scenario).

Additional Context

- [Overview](#overview) - [Request](#request) - [Potential Solution](#potential-solution) - [Alternative Solutions](#alternative-solutions) - [Additional Context](#additional-context) <small><i><a href='http://ecotrust-canada.github.io/markdown-toc/'>Table of contents generated with markdown-toc</a></i></small> # Overview - **Requester**: @abdulrabbani00 - **Epic Link**: None yet. ## Request  With the current estimations, we believe it would take about 396GB of day per day to store the `beaconState`.. This amount of data is unfeasible to store, therefore we need another solution. # Potential Solution  ## Store Intermediary States and Build the State as Needed. One way to drastically reduce the footprint of the `beaconState` is to store every X number of states. We can ipld-lize these states. If someone asks for a beaconState in-between the intermediary states, the watchers can rebuild the state desired state on the fly. 1. Capture the BeaconState at Slot 128 and 256, write the raw states to the DB. 2. A client request comes in for slot 255. 3. We rebuild every intermediary state from 128-255 and serve it to the client. i. The DB will contain the correct `stateRoot`, so we can check after rebuilding each state to ensure it was done correctly. 5. We **do not** write the newly calculated states to the DB. i. If we ever see that there is a high demand for the `beaconState`, we can consider further solutions. a. Storing the state closer together, instead of storing it every `X` slots we store it ever `X/Y` slots. ## Alternative Solutions  * Perhaps we don't store the `BeaconState` at all. It might make sense to have the watchers query the `lighthouse` client every time they want a `BeaconState`. If we use the highest [SPRP](https://lighthouse-book.sigmaprime.io/advanced_database.html?highlight=database#database-configuration) offered, we can load the beaconState at a max of 155ms (best case scenario). # Additional Context

dboreham commented

2022-10-13 12:21:24 +00:00

By avoiding storing beacon state in our DB, growth rate is currently around 600MB/day.

dboreham commented

2023-01-31 19:56:46 +00:00

I think this one is resolved now?

i-norden commented

2023-02-01 18:22:50 +00:00

Agreed, it is superseded by: https://github.com/cerc-io/ipld-eth-beacon-indexer/issues/77 we still need to figure how to store state data in a compact manner.

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/ipld-eth-beacon-indexer#71