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

kevaundray · 2025-01-26T21:51:30Z

Original documents are here (for validators):

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

eth-bot · 2025-01-26T21:52:00Z

File `EIPS/eip-7870.md`

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

kevaundray · 2025-01-26T21:53:43Z

EIPS/draft_hardware_and_bandwidth_recs.md

+- Statista states that as of January 2024:
+  - The global average download for broadband is 92 Mbps and the global average upload is 43 Mpbs.
+  - The global average download for mobile is 50 Mbps and 11 Mbps
+- GSMA report showing the state of mobile internet connectivity in 2024 shows that:
+  - The mobile upload speeds in Higher Income Countries (HIC) is about 18 Mbps
+  - The global average mobile download is 48 Mbps.
+


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/

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

kevaundray · 2025-01-26T21:59:09Z

EIPS/draft_hardware_and_bandwidth_recs.md

+
+## Backwards Compatibility
+
+This EIP is informational and requires no protocol changes. We recommend that future EIPs include an assessment of their impact on these hardware requirements.


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

EIPS/draft_hardware_and_bandwidth_recs.md

kevaundray · 2025-01-26T22:31:21Z

EIPS/draft_hardware_and_bandwidth_recs.md

+
+RAM/memory is dominated by state cache. As of January 2025, it is possible to run a full node with 16GB of RAM, however this has been known to not work with all combinations of EL and CL clients in the past.
+
+On 32GB vs 64GB; 32GB works right now, however we recommend 64GB as [preliminary benchmarks](https://hackmd.io/@han/bench-hash-in-snark) have shown that zk-STARKS can consume a significant amount of memory and the difference in cost relative to the entire hardware setup for a validator is insignificant.


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?

EIPS/draft_hardware_and_bandwidth_recs.md

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.

EIPS/draft_hardware_and_bandwidth_recs.md

restakeservice · 2025-01-27T13:36:01Z

good idea!

kevaundray · 2025-01-27T14:40:38Z

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.

EIPS/eip-7870.md

kevaundray · 2025-01-27T16:12:32Z

There doesn't seem to be a discussions-to, so commenting here for now:

What might help to minimise future debate/bikeshedding over what the new minimum should be is a price based guideline to help keep track of the performance growth in what 'commodity hardware' might mean. E.g. what $1000 capex + $100 p/a opex gets you, or what x% of a validator price can get you, or what y% of a validator's annual reward can get you.

I just got a discussion link created for me :)

Will comment here and I can paste it over there:

I have not thought much about this, so I would gather opinions from you and others who have before forming a strong opinion.

If I had to choose one right now, I would perhaps tend towards "x% of a validator price can get you" or "y% of a validator's annual reward can get you" -- and we could figure out what x or y is by answering the question of "how long should it take a validator to recoup their hardware capex"

Co-authored-by: Tim Beiko <[email protected]>

EIPS/eip-7870.md

Co-authored-by: Mercy Boma Naps Nkari <[email protected]>

dapplion · 2025-01-28T03:54:10Z

EIPS/eip-7870.md

+- Samsung 990 Pro
+- Seagate Firecuda 530
+- Teamgroup MP44
+- WD Black SN850X


Do you have to list specific commercial models in an EIP? Can you focus of i/o metrics that are brand agnostic?

indeed i/o metrics would be more generalised and open up more broader choices for people

dapplion · 2025-01-28T03:54:25Z

EIPS/eip-7870.md

+- Samsung 990 Pro
+- Seagate Firecuda 530
+- Teamgroup MP44
+- WD Black SN850X


Do you have to list specific commercial models in an EIP? Can you focus on i/o metrics that are brand agnostic?

CPerezz · 2025-01-28T09:49:49Z

EIPS/eip-7870.md

+
+- The CPU rating is a measure of how powerful a particular CPU is for single and multithreaded respectively. All numbers referenced are normalized according to PassMark.
+
+### Recommended Prebuilds (Attester and Local block builder)


Even if you suggest different options, could you stick to a single one for the benchmarks in the future? 2 as max if we include RPI which otherwise is definitely non-represented.

Meaning this wouldn't just be the hardware recommendations but also the common denominator for all benchmarks given from now on.
In that way, is significantly easier to compare cryptographic protocols rather than giving benchmarks on an M4 Max and then having no clue if is suitable for Attesters or block builders etc..

If not fixed to a machine, at least fixed to a number of cores a threads would definitely help.

It is not good idea nor practical to do benchmarks on single hardware. You can instead tune your CPU to the provided rating.

Mostly say so because depending on the CPU, it might have AVX-{} support or not. Same with custom instruction sets for asm. RPI won't support Intel's fast modular field custom instruction set for example.

These are all issues that adjusting to rating won't support (IIUC). Also could help to dismiss or incentivize the implementation of such specific backends to squeeze as much perf as possible.

Finally, maybe not as big of an issue (I ignore that part) but different pipelining, cache lines and other kinds of similar properties can also influence some of the stuff we bench. Specifically when we work sometimes within the realm of us/ns.

This was the main reason behind the suggestion. But if there are well-known alternatives that solve that or this can also be "adjusted", please let me know to resolve the comment! cc: @chfast

Storage: That this requires a certain amount of speed may be good to point out. Home stakers have had great success with NVMe that uses TLC NVRAM and has DRAM cache. DRAMless or QLC drives may or may not work, depending on model and client mix.

SATA SSD as well may or may not work, it depends on the model and exact client mix.

Given the strong recommendations for RAM and CPU, I suggest also recommending NVMe with DRAM cache and TLC flash for storage.

O1ahmad · 2025-01-28T15:26:37Z

EIPS/eip-7870.md

+
+- The CPU rating is a measure of how powerful a particular CPU is for single and multithreaded respectively. All numbers referenced are normalized according to PassMark.
+
+### Recommended Prebuilds (Attester and Local block builder)


Is the EIP meant to explicitly avoid providing a basis for these commercial product/hardware recommendations? Still not sure I understand the point/value here without providing transparency into the reasoning and thought process driving the decisions.

It was in the original hardware requirements document, but it was not copied over due to the extensive use of links. I haven't seen any feedback re these builds being unreasonable.

NUC was specifically added because a lot of the existing staker community uses NUC and we provided an alternative model that Pari from panda ops suggested that he has experience with, because Yorick from Eth stakers noted that some places may not sell NUCs. If a user does not want to use these models, they can look at the cpu rating and choose accordingly or make a custom build

Ok cool, got it @kevaundray and mostly makes sense. As discussed before, my concern really only surrounds the empirical nature and openness of the suggestions and reasoning/data supporting them - especially considering coming from an "official" source like an EIP.

kevaundray · 2025-01-28T17:14:44Z

Feedback from EIP maintainers:

Remove brands (including recommended prebuild), so as to not to favour particular brands
Add rationale on how the particular numbers were chosen*
Add hackmd doc to assets folder, so it can be linked in the EIP
Will need a call to action to vote on the statista and GSMA links
Change EIP from Draft to "Ready to review"

These were in the original document, but the supporting evidence for them required a lot of external links.

@SamWilsn just want to confirm, I did not miss anything?

jochem-brouwer

Some questions! 😄 👍

jochem-brouwer · 2025-01-29T07:29:33Z

EIPS/eip-7870.md

+  - Single Thread: 3903
+  - Multithread: 30367
+
+#### ASUS NUC 14 Pro


An idea, but maybe move those recommended prebuilds to an external site (as part of removing the brand names). HackMD will do fine. If there is some kind of external site which actually document and review setups that would also be great (but not aware of any).

This makes sense -- I think people will want some document that has more precise suggestions. It could be a hackmd that says something like "concrete suggestions for EIP XXXX"

EIPS/eip-7870.md

jochem-brouwer · 2025-01-29T07:33:23Z

EIPS/eip-7870.md

+
+## Specification
+
+### Recommended hardware and bandwidth specifications


Maybe include a date here, so if users stumble upon this EIP they will know that this is recent, and not recommended specifications of 3 years ago.

jochem-brouwer · 2025-01-29T07:34:11Z

EIPS/eip-7870.md

+
+This EIP is informational and requires no protocol changes. We recommend that future EIPs include an assessment of their impact on these hardware recommendations.
+
+## Security Considerations


I think I'd like to see a section about "Future". What could we expect in the future? Would we need more storage? If I build a node using the recommended settings, what is the target duration that this setup is usable and needs no hardware upgrades?

Off the top of my head, this is what I can think of. Kind of hard to be comprehensive and I'm sure there are nuances that are missed or mistakes:

Full node

Download and upload speed goes down once we have peerDAS

Storage will go down once we have EIP444

Storage and RAM will go down once we have stateless (unclear how stateless clients will do state cache for re-org protection)

CPU could go down further once we snarkify the EL block

CPU and storage might go up depending on how far we increase the gas limit and whether we have EIP4444 and stateless

Attesters

They inherit all of the changes from full nodes (though attesters sample more, so higher bandwidth)

Download speed goes up due to increase in blobs

Block builder

CPU usage goes up once we have stateless due to the need to create the stateless proofs

Download and upload speed initially goes down to peerDAS

Upload speed and cpu requirements goes down due to epbs due to having more time to create the execution payload

Download and upload speed goes up due to increase in blobs

CPU requirements increase due to the addition of heavier proofs like zkvm (probably will need a GPU)

(One note here is that until we have zkvm proofs, you can still block build but at a lower throughput by setting the maximum number of blobs you can do in your EL based on your bandwidth requirements)

I think the main entity that will change significantly is the block builder.

Other changes to consider:

State network: This refers to the portal state network -- it would in theory, allow us to increase the gas limit and so it would increase builder requirements and the download speed of attesters and full nodes.

The argument here is that if we increase the gas limit, we increase the rate of state growth and eventually no-one but centralized parties will be able to hold the state and they could deny access or censor the rest of the network. But with state network, we would always be able to retrieve the state (at a slower throughput).

Delayed state root: depending on your client and how long it was taking to compute the state root, the builder cpu requirements can go down

FOCIL; This effectively puts a lower bound on the block size and I think mostly affects block builders, in practice, I think the FOCIL limit will be negligible and won't affect the specs.

Rainbow staking derivatives: This will add more roles -- separating the centralizing components like block building from the other components at the very least.

It has been argued that this might give folks reason to pump up the requirements for the centralizing components even further like block building. I am unsure about how this will play out.

Co-authored-by: Jochem Brouwer <[email protected]>

jtraglia · 2025-01-29T15:28:41Z

EIPS/eip-7870.md

+### Recommended Prebuild (Full node)
+
+#### Raspberry Pi 5
+
+- 4 core
+- 4 threads
+- CPU Rating
+  - Single thread: 1487
+  - Multithred: 3428


I'm a little concerned that a RP5 would be unable to function as a full node. Can anyone confirm this works? For one, storage speeds are quite important and it only operates at PCIe 2.0 speeds (like ~500MB/s). This might be do-able, but it's not something I would recommend today. Instead, I would suggest a Rock 5 Model B which is all-around better.

Apparently a RP5 works. Very cool. Consider my concern withdrawn.

See: https://x.com/EthereumOnARM/status/1880258026676146618

jtraglia · 2025-01-29T15:28:53Z

EIPS/eip-7870.md

+- 4 threads
+- CPU Rating
+  - Single thread: 1487
+  - Multithred: 3428


Suggested change

- Multithred: 3428

- Multithread: 3428

jtraglia · 2025-01-29T15:34:07Z

EIPS/eip-7870.md

+- Teamgroup MP44
+- WD Black SN850X
+
+In particular, we recommend purchasing NVMe M.2 instead of SATA as NVMe has higher throughput.


Additionally, we should mention that we recommend NVMe drives with DRAM and TLC flash. QLC flash is slower and has a lower write endurance, meaning they may fail sooner.

jtraglia · 2025-01-29T15:35:07Z

EIPS/eip-7870.md

+
+For validators that want to build blocks locally, we recommend global bandwidth figures inline with the global average for fixed broadband: 100 Mbps download and 50 Mbps upload.
+
+*If a block builder does not have the recommended bandwidth, we recommend that they build a block that is partially full and or one that includes less blobs.*


Suggested change

*If a block builder does not have the recommended bandwidth, we recommend that they build a block that is partially full and or one that includes less blobs.*

*If a block builder does not have the recommended bandwidth, we recommend that they build a block that is partially full and or one that includes fewer blobs.*

jtraglia · 2025-01-29T15:37:51Z

EIPS/eip-7870.md

+### RAM
+
+RAM/memory is dominated by state cache. As of January 2025, it is possible to run a full node with 16GB of RAM, however this has been known to not work with all combinations of EL and CL clients in the past.


Just a nit. I would prefer if the section header were "Memory" and replace "RAM" with "memory" in the paragraph. At the beginning, we could do "Memory (RAM) is dominated by..."

jtraglia · 2025-01-29T15:39:12Z

EIPS/eip-7870.md

+| Node type | Storage | RAM | CPU Cores | CPU Single Thread/Multithread rating | Download/Upload speed |
+| -------- | -------- | -------- | --------| -------- |--------|
+| Full node     | 4TB     | 32GB    | 4 cores/8 threads  | 1000 / 3000 | 50 Mbps / 15 Mbps |
+| Attester      | 4TB     | 64GB    | 8 cores/16 threads | 3500 / 25000 | 50 Mbps / 25 Mbps |
+| Local block builder | 4TB     | 64GB    | 8 cores/16 threads | 3500 / 25000 |  100 Mbps / 50 Mbps |


Can we format this table so everything is aligned? So it's easier to read when viewing markdown source.

Also, for consistency with the other fields, we should add spacing around "/" in the CPU cores column. And "cores" should be lowercase in the column title.

Yep, for future reference, I used: https://codebeautify.org/markdown-formatter#

jtraglia · 2025-01-29T15:42:36Z

EIPS/eip-7870.md

+  - Single Thread: 3520
+  - Multithread: 25158
+
+### Recommended Prebuild (Full node)


To match the order of the recommended hardware table, the full node section should be first.

jtraglia · 2025-01-29T15:43:46Z

EIPS/eip-7870.md

+
+- Statista states that as of January 2024:
+  - The global average download for broadband is 92 Mbps and the global average upload is 43 Mbps.
+  - The global average download for mobile is 50 Mbps and 11 Mbps


Missing punctuation.

Suggested change

- The global average download for mobile is 50 Mbps and 11 Mbps

- The global average download for mobile is 50 Mbps and 11 Mbps.

jtraglia · 2025-01-29T15:44:09Z

EIPS/eip-7870.md

+  - The global average download for broadband is 92 Mbps and the global average upload is 43 Mbps.
+  - The global average download for mobile is 50 Mbps and 11 Mbps
+- GSMA report showing the state of mobile internet connectivity in 2024 shows that:
+  - The mobile upload speeds in Higher Income Countries (HIC) is about 18 Mbps


Missing punctuation.

Suggested change

- The mobile upload speeds in Higher Income Countries (HIC) is about 18 Mbps

- The mobile upload speeds in Higher Income Countries (HIC) is about 18 Mbps.

jtraglia · 2025-01-29T15:44:39Z

EIPS/eip-7870.md

+
+#### Attesters
+
+For attesters, we recommend: 50 Mbps download and 25 Mbps upload.


The colon isn't really necessary here.

Suggested change

For attesters, we recommend: 50 Mbps download and 25 Mbps upload.

For attesters, we recommend 50 Mbps download and 25 Mbps upload.

github-actions · 2025-01-29T16:58:30Z

The commit 93c4c0b (as a parent of 51efb62) contains errors.
Please inspect the Run Summary for details.

draft

e352bf6

github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-informational labels Jan 26, 2025

eth-bot added the e-consensus Waiting on editor consensus label Jan 26, 2025

kevaundray commented Jan 26, 2025

View reviewed changes

github-actions bot added the w-ci Waiting on CI to pass label Jan 26, 2025

kevaundray commented Jan 26, 2025

View reviewed changes

EIPS/draft_hardware_and_bandwidth_recs.md Outdated Show resolved Hide resolved

kevaundray added 2 commits January 26, 2025 22:09

Update EIPS/draft_hardware_and_bandwidth_recs.md

cab4358

add rationale for 64GB RAM (only for validators)

ac4b879

kevaundray commented Jan 26, 2025

View reviewed changes

kevaundray added 2 commits January 26, 2025 22:38

Copy over authors

f1b23a1

use simpler word

41abebe

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels Jan 26, 2025

potuz reviewed Jan 27, 2025

View reviewed changes

EIPS/draft_hardware_and_bandwidth_recs.md Outdated Show resolved Hide resolved

smartprogrammer93 reviewed Jan 27, 2025

View reviewed changes

unnawut mentioned this pull request Jan 27, 2025

Add refs to hardware and bandwidth requirements ReamLabs/ream-study-group#6

Open

chfast reviewed Jan 27, 2025

View reviewed changes

EIPS/draft_hardware_and_bandwidth_recs.md Outdated Show resolved Hide resolved

add note about passmark

460725d

requirements -> recommendations

31374a5

kevaundray changed the title ~~Add EIP: Hardware and Bandwidth Requirements for Full Nodes and Validators~~ Add EIP: Hardware and Bandwidth Recommendations for Full Nodes and Validators Jan 27, 2025

github-actions bot removed the w-ci Waiting on CI to pass label Jan 27, 2025

This was referenced Jan 27, 2025

Consensus-layer Call 150 ethereum/pm#1265

Open

Execution Layer Meeting 204 ethereum/pm#1253

Open

github-actions bot added the w-ci Waiting on CI to pass label Jan 27, 2025

eth-bot changed the title ~~Add EIP: Hardware and Bandwidth Recommendations for Full Nodes and Validators~~ Add EIP: Hardware and Bandwidth Recommendations for Validators and Full Nodes Jan 27, 2025

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels Jan 27, 2025

timbeiko reviewed Jan 27, 2025

View reviewed changes

EIPS/eip-7870.md Outdated Show resolved Hide resolved

Update EIPS/eip-7870.md

a5972f2

Co-authored-by: Tim Beiko <[email protected]>

timbeiko reviewed Jan 27, 2025

View reviewed changes

EIPS/eip-7870.md Outdated Show resolved Hide resolved

kevaundray added 2 commits January 27, 2025 16:42

Co-authored-by: Joseph Livesey <[email protected]>

073e30a

block builder -> local block builder

d331e69

bomanaps reviewed Jan 27, 2025

View reviewed changes

kevaundray and others added 3 commits January 27, 2025 17:42

Update EIPS/eip-7870.md

cba4b17

Co-authored-by: Mercy Boma Naps Nkari <[email protected]>

Update EIPS/eip-7870.md

1da4dce

Co-authored-by: Mercy Boma Naps Nkari <[email protected]>

Update EIPS/eip-7870.md

39dad68

Co-authored-by: Mercy Boma Naps Nkari <[email protected]>

github-actions bot removed the w-ci Waiting on CI to pass label Jan 27, 2025

Update EIPS/eip-7870.md

555d4b7

Co-authored-by: Mercy Boma Naps Nkari <[email protected]>

github-actions bot added the w-ci Waiting on CI to pass label Jan 27, 2025

remove requires field

a3eb5ca

dapplion reviewed Jan 28, 2025

View reviewed changes

CPerezz reviewed Jan 28, 2025

View reviewed changes

O1ahmad reviewed Jan 28, 2025

View reviewed changes

poojaranjan mentioned this pull request Jan 28, 2025

EIP Editing Office Hour Meeting 50 ethcatherders/EIPIP#377

Open

31 tasks

cshein45 approved these changes Jan 28, 2025

View reviewed changes

jochem-brouwer reviewed Jan 29, 2025

View reviewed changes

Update EIPS/eip-7870.md

93c4c0b

Co-authored-by: Jochem Brouwer <[email protected]>

jtraglia reviewed Jan 29, 2025

View reviewed changes

kevaundray marked this pull request as ready for review January 29, 2025 16:47

kevaundray requested a review from eth-bot as a code owner January 29, 2025 16:47


		## Backwards Compatibility

		This EIP is informational and requires no protocol changes. We recommend that future EIPs include an assessment of their impact on these hardware requirements.


		RAM/memory is dominated by state cache. As of January 2025, it is possible to run a full node with 16GB of RAM, however this has been known to not work with all combinations of EL and CL clients in the past.

		On 32GB vs 64GB; 32GB works right now, however we recommend 64GB as [preliminary benchmarks](https://hackmd.io/@han/bench-hash-in-snark) have shown that zk-STARKS can consume a significant amount of memory and the difference in cost relative to the entire hardware setup for a validator is insignificant.


		- The CPU rating is a measure of how powerful a particular CPU is for single and multithreaded respectively. All numbers referenced are normalized according to PassMark.

		### Recommended Prebuilds (Attester and Local block builder)


		## Specification

		### Recommended hardware and bandwidth specifications


		This EIP is informational and requires no protocol changes. We recommend that future EIPs include an assessment of their impact on these hardware recommendations.

		## Security Considerations


		For validators that want to build blocks locally, we recommend global bandwidth figures inline with the global average for fixed broadband: 100 Mbps download and 50 Mbps upload.

		If a block builder does not have the recommended bandwidth, we recommend that they build a block that is partially full and or one that includes less blobs.

		### RAM

		RAM/memory is dominated by state cache. As of January 2025, it is possible to run a full node with 16GB of RAM, however this has been known to not work with all combinations of EL and CL clients in the past.

	- The global average download for mobile is 50 Mbps and 11 Mbps
	- The global average download for mobile is 50 Mbps and 11 Mbps.

	- The mobile upload speeds in Higher Income Countries (HIC) is about 18 Mbps
	- The mobile upload speeds in Higher Income Countries (HIC) is about 18 Mbps.


		#### Attesters

		For attesters, we recommend: 50 Mbps download and 25 Mbps upload.

	For attesters, we recommend: 50 Mbps download and 25 Mbps upload.
	For attesters, we recommend 50 Mbps download and 25 Mbps upload.

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

Are you sure you want to change the base?

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

Conversation

kevaundray commented Jan 26, 2025 • edited Loading

eth-bot commented Jan 26, 2025 • edited Loading

File EIPS/eip-7870.md

kevaundray Jan 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smartprogrammer93 left a comment • edited Loading

Choose a reason for hiding this comment

restakeservice commented Jan 27, 2025

kevaundray commented Jan 27, 2025

kevaundray commented Jan 27, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dapplion Jan 28, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CPerezz Jan 28, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevaundray commented Jan 28, 2025

jochem-brouwer left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Jan 29, 2025

kevaundray commented Jan 26, 2025 •

edited

Loading

eth-bot commented Jan 26, 2025 •

edited

Loading

File `EIPS/eip-7870.md`

kevaundray Jan 26, 2025 •

edited

Loading

smartprogrammer93 left a comment •

edited

Loading

dapplion Jan 28, 2025 •

edited

Loading

CPerezz Jan 28, 2025 •

edited

Loading