Add EIP: Hardware and Bandwidth Recommendations

[kevaundray]

Original documents are here (for validators):

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

[eth-bot]

✅ All reviewers have approved.

[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]

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.

[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.

[g11tech]

hey @kevaundray , if you could get the linter/bots to pass, we can merge this PR and then you can continually update this basis discussion and feedback

[github-actions]

The commit d61b83b (as a parent of 1c30144) contains errors.
Please inspect the Run Summary for details.

[kevaundray]

hey @kevaundray , if you could get the linter/bots to pass, we can merge this PR and then you can continually update this basis discussion and feedback

Should be mergeable now :)

[kevaundray]

@g11tech bump on merging this

[Marchhill]

Maybe this section could be expanded slightly, it doesn't give a clear rationale to me

[g11tech]

lgtm for draft, whether to anchor in time via title or having it as a living EIP, that call can be taken at moving to review time

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...