Add EIP: Hardware and Bandwidth Recommendations for Validators and Full Nodes

[kevaundray]

Original documents are here (for validators):

• Hardware: https://hackmd.io/G3MvgV2_RpKxbufsZO8VVg?view
• Bandwidth: https://hackmd.io/DsDcxDAVShSSLLwHWdfynQ?view

[eth-bot]

File EIPS/eip-7870.md

Requires 1 more reviewers from @g11tech, @lightclient, @SamWilsn, @xinbenlv

[kevaundray]

GSMA link is https://www.gsma.com/r/wp-content/uploads/2024/10/The-State-of-Mobile-Internet-Connectivity-Report-2024.pdf?utm_source=website&utm_medium=button&utm_campaign=somic24

Page 39 for the upload speeds of HIC and page 5 for the 48 Mbps figure.

Statista link is: https://www.statista.com/statistics/896779/average-mobile-fixed-broadband-download-upload-speeds/

[kevaundray]

Let me know how you would want these to be referred to in the document

[kevaundray]

Would the recommendation here require another EIP if this gets finalized?

In any case, I don't think it belongs here since this section is explicitly about whether the EIP breaks backwards compatibility

[kevaundray]

I saw that EIPs 2926, 2938, 3298, 3416 and 3607 also used hackmd links however the contents of them can easily be changed, so I wonder if there is a rule about using them?

[smartprogrammer93]

Given EIPs are immutable once they become final, does it make sense to place these requirements in an EIP? I expect requirements will need to be updated in a couple of years. In that case, we will need to create a different EIP amending this one. Then, operators will need to check 2 different EIPs to know what the current requirements are. Seems impractical to me.

[restakeservice]

good idea!

[kevaundray]

Given EIPs are immutable once they become final, does it make sense to place these requirements in an EIP? I expect requirements will need to be updated in a couple of years. In that case, we will need to create a different EIP amending this one. Then, operators will need to check 2 different EIPs to know what the current requirements are. Seems impractical to me.

In the call someone mentioned that, the status of this could be changed to "live" and we modify it in-place instead of creating a new EIP each time. I would defer to the EIP maintainers regarding that and whats possible there.

I agree that creating a new EIP whenever we change specs is undesirable.

[cshein45]

MOVEMENT

[kevaundray]

@yorickdowne @potuz Thanks for the comments on hardware -- any comments on bandwidth?

[github-actions]

The commit fda25ca (as a parent of e2c2d40) contains errors.
Please inspect the Run Summary for details.

[kamilchodola]

General question to this one:

Should we better treat that as "Recommended setup" or "Minimal setup"?

Minimal would be then something we can refer to and adjust to it - having any users on our support lines which will be struggling with weaker setups could be then advised to think of any improvement and referred to this EIP.
Recommendation always gives quite a bit of room for complains.

Also having "Minimal supported setup" in place we can adjust any benchmarking tools to it and then make a proper assumptions.

[kamilchodola]

Are all those numbers applied based on some research made? Or based on experience from discussions with stakers?

From Nethermind perspective those are super comfortable.

Also shall we distinguish EL and CL requirements to be treated separately? I saw a lot of setups where actually both are running on different machines.

[kevaundray]

I think the average user would likely run these on the same machine?

The rationale for them is in the linked hackmd in the comment box, we could not include all of those links so the EIP has been somewhat watered down

[kamilchodola]

One thing I'd suggest doing prior to applying that is to do any research among community either by pool on X or anything else which can have bigger outreach.

If it will appear that 51% of users have weaker than specified setup (which is super unlikely but still) we could potentially open a route for some unexpected attacks because we will test on too good hardware.

At least worth to know in case of noticed issue which affect weaker setups how much network (in terms of nodes) is put in danger.

[kevaundray]

We could alternatively, test against the old NUCs for a year too though the current idea was that instead of us polling N validators, we would give them a tool to allow them to assess themselves and decide when they would want to update

[kevaundray]

General question to this one:

Should we better treat that as "Recommended setup" or "Minimal setup"?

Minimal would be then something we can refer to and adjust to it - having any users on our support lines which will be struggling with weaker setups could be then advised to think of any improvement and referred to this EIP. Recommendation always gives quite a bit of room for complains.

Also having "Minimal supported setup" in place we can adjust any benchmarking tools to it and then make a proper assumptions.

This would be treated as "recommended" -- you can use weaker hardware but they would not be tested/benchmarked against is the thinking. The minimum is somewhat client specific, so I'd be hesitant to add that maintenance burden and it also would likely change more often per hardfork vs recommended due to the headroom.