Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: update state:history storage to 1:1 #1561

Merged
merged 1 commit into from
Oct 29, 2024

Conversation

carver
Copy link
Collaborator

@carver carver commented Oct 29, 2024

I don't have strong feelings about what the new ratio should be. I just picked one, mostly to kick off discussion. Now, we have more information than we did at the 99:1 ratio selection.

The new ratio is still a loose guess. But it is based on some recently acquired state data, specifically:

A recent average amount of new state generated is about 1.75MB / block or ~375 GB per month. Let's make room for 10 years of intremental state at that rate, which gives us a network size of: ~45 TB.

The typical history node can fill up 35GB of storage with a ~2% radius, implying a network size of: ~1.75 TB.

45 TB / 1.75 TB ~= 25:1 ratio

Inspired by conversation and data collection here: https://discord.com/channels/890617081744220180/1089234065816821860/1300370058366947370

@carver carver self-assigned this Oct 29, 2024
@carver carver marked this pull request as ready for review October 29, 2024 05:39
@carver carver requested a review from morph-dev October 29, 2024 05:39
@morph-dev
Copy link
Collaborator

I wanted to get #1558 merged first and I would have started this topic myself :). I agree that 99:1 is broken and we should do something about it.

Based on the discussion during meeting, my impression is that we want different ratio based on total storage capacity (different ratio for 100 MB vs 1 GB vs 10 GB). I also think that we should start measuring and dedicating some storage to Beacon as well.

With this being said, I think that at the moment we don't have to do any special math, as we will have to redo it again, most likely soon. So I'm in favor of just doing 1:1 or even dedicating more storage towards history (as this is closer to actual current usage).


Somewhat related to this, now that we have cli flags to specify storage per network, I would like to restart the discussion about enabling state network by default. My original concerns were:

  • state network not yet storing very useful data - this is still my concern
  • implementing unified radius - this is no longer my concern because:

So my only remaining concern is that state network doesn't have very useful data, yet. So if you or anybody else still feel like we should enable it, I wouldn't be against it.

This approach to balancing storage will not last long. We will implement
a more sophisticated approach in the near future.

Rather than trying to guess what the state:history ratio will be, we can
just look at it short term.

If we add in the data from block 21M + 6 months, then the ratio gets to
about 1:1. So technically we are still over-allocating for state right
this moment, but it gives us plenty of runway, and is close enough that
it shouldn't cause major problems.
@carver
Copy link
Collaborator Author

carver commented Oct 29, 2024

So I'm in favor of just doing 1:1 or even dedicating more storage towards history (as this is closer to actual current usage).

Yeah, let's do 1:1 to just not overthink it. We can put the extra thought into whatever scheme we come up with next :)

I wanted to get #1558 merged first and I would have started this topic myself :)

Hah, yeah I spawned this PR when reviewing that one.


So my only remaining concern is that state network doesn't have very useful data, yet. So if you or anybody else still feel like we should enable it, I wouldn't be against it.

Yeah, looking back I was having a mini manic moment on trying to enable it then. I think it's pretty clear that the stability of state isn't really approaching history. So I at least would want to wait past Devcon. Some other reference points I might think about for calling it stable enough to turn on by default:

  • 21M state & up added
  • A couple weeks of glados showing >=99.9% on state audits for the first 1M and the 21M+ state
  • A glados audit for recent state (Maybe ~3 block lag is okay for now)

Copy link
Collaborator

@morph-dev morph-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@morph-dev morph-dev changed the title feat: update state:history storage to 25:1 feat: update state:history storage to 1:1 Oct 29, 2024
@carver carver merged commit 45f1ec6 into ethereum:master Oct 29, 2024
9 checks passed
@carver carver deleted the state-history-ratio branch October 29, 2024 19:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants