EIP-7870: Hardware and Bandwidth Recommendations

Transcript

in between 5 years ago and now we had this massive thing called the merge that also changed the requirements fundamentally and we didn't really touch it well if you're trying to be a Staker or if you want to run a full node you want to know like what Hardware you need to buy and you want to know that the hardware that you bought can actually run the ethereum chain if you're wanting to build your own blocks although there is some enshrined propos ability separation mechanism then the hardware requirements might just increase and I think this is the rout here of the contention this is the EIP that sets what a requirement is for a node and these are the type of nodes that would require to do the transition and this is the [Music]

speed welcome back to peep the podcast where we explore ethereum Improvement proposals and break down what's ahead of ethereum ecosystem this is episode 145 brought to you by EC Institute today we are diving into EIP 7870 hardware and bandwidth recommendations and informational proposal documented on January 26 2025 co-authored by multiple developers and researchers The Proposal is currently in draft status EIP 7870 outlines system recommendation for validators and pull notes helping to ensure Network

efficiency and decentralization to help us understand this proposed standard we are joined by some incredible guests today kenry wedderburn a key contributor to ethereum client development paros Janti well known for his work on ethereum testnet and validator monitoring and Tony was a researcher focused on ethereum infrastructure and network optimization welcome you all to Peep and hey thanks for having us hello hey if you have been following P you know Pari and Tony have been keeping us updated on ethereum research and network upgrades they know the drill but

today we are also joined by KF and we would love to hear about his journey as a developer in ethereum let's start with Kev introduction followed by P and Tony yeah hello thanks for having having me I've been in the aerum ecosystem now or the EF for about four or five years before this I was uh developing compiler called No which is for ZK circuits nowadays I do mostly software engineering mostly cryptography and uh yeah I'm currently the team lead for the arc I can continue hey I'm par I'm part of the eth panda Ops Team at the eum foundation we do a lot of work around

testing validators deployments of test Nets and Dev Nets to basically help find bugs before the hit meain hey I'm Tony I've got involved with this EAP during work on analyzing the gas limit increase or analyzing blob through Pro increase and just as a little background I work at the Firm Foundation at the applied research group and have been very involved with everything around gas limits block sizes there was an earlier episode on EAP 7623 another one on the blob increase so I'm very interested when it comes to those topics this is awesome yeah I understand this is like very interesting

combination of lot many field getting together in one proposal because this is a spec recommendation for running ethereum node Kev I find it a little unfair you have been with ethereum foundation for four or five years and this is the first time we are having you I hope to have you more frequent to share what's going on in ethereum EOS system but this is great indeed that we are here to discuss this EIP I believe that this is a very good way of learning about our developers and then we'll get into what they are proposing I understand this proposal talks a lot about specification bandwidth recommendations and so on so forth and Community are eager to understand how they can participate in Solo staking or

becoming a home Staker so without further Ado let's get into the overview of the proposal I guess the first part would be the motivation as to why do we even sort of need these Hardware recommendations if you've sort of been in The Firm ecosystem as of late people are talking about sort of increase in the gas limit all these sort of scaling techniques and in order to know whether we can do any of these things we sort of need to know what Hardware these things are running on the other sort of reason why you need something like this is well if you're trying to be a Staker or if you want to run a full node you want to know like what Hardware you need to buy and you want to know that the hardware

that you've bought uh can actually run the ethereum chain so for protocol developers they should be using these Hardware recommendations in order to run benchmarks so that when you buy Hardware that is specified here we've actually tested against it also over the last years we had some sort of recommendation when the beacon chain launched but there hasn't really been an updating of these recommendations over the last years there's been like some informal changes offered by E Staker or other organizations but nothing that try to Define what can run an ethereum node and I mean in between 5 years ago and now we had this massive

thing called the merge that also changed the requirements fundamentally and we didn't really touch it so it feels like for a few years it's just can kind of implicit understanding of what the requirement is for a node but uh that's very hard to design on and same for the testing world so we just spin up servers based on what we think should be e cheap or what we think should be what majority of stakers have but that still is not the way to go I think the idea of this EIP is to try and strong more strongly Define these are recommendations of what you could run at and then we can use that on the testing side the researchers can use that as an understanding of what

to design the protocol for and stakers can use that as an idea of what to buy for but one thing I do want to mention is that these are still recommendations and I think there's also a lot of discussions about like is this minimal or is this recommended probably the easiest way is if you go to steam and you look at um like what do you need to run a game that's always like required in minimum so ethereum probably will run on a node that has less specifications than what the document specifies I for one still run a machine from fiveish 6 years ago now that I bought for not that much money and it still doesn't consume that many resources so the chances that we're going to bump up values that my

machine can't run are in the next year are quite low but at the same time I think it's good to have like a target for the future the idea is that if you buy a machine today you shouldn't buy one that is comparable to mine from 6 years ago you should probably buy one that will last you the next 5 years and I think this document tries to clarify some of those things right I think it's a good point on the minimal so for minimal we did think about it for a bit but this is actually quite a non-trivial thing to Define especially now that we have multiple clients and the minimal requirements would likely change per hard Fork maybe even per client update so just moving on to sort of the two

types of nodes that you might want to run so the first one is a full node and uh this is basically a node that just follows the chain like usual and the second one is a validator so you pay 32 e and then you can become a validator and the validator has two duties uh you can say one of them is ATT testing to blocks and the other is actually building blocks or proposing blocks we spent a lot of time on the local block building part if you look at the table the part that has the highest requirements are local block building so if we look here basically all of the uh nodes have 4 terabyt storage and this is just mainly because all of the nodes are still storing

history you can likely run it with 2 terabytes but uh it's definitely not recommended if we can get for uh by the end of the year then I imagine these Hardware requirements would go down to 2 terabytes if we look at memory for example as well the full node has 32 GB and this is mainly because you can run these on 32 GB the reason we've sort of pushed it to 64 gabt is there is this other sort of project called a beam chain and we've done some benchmarks and we noted that if you try to switch to postquantum the memory requirements do increase by quite a lot so this just gives us sufficient head room the number of cores and threets that we've chosen 8

and 16 is quite sort of standard nowadays the reason why we chose 4 and8 for a full node is because you can do four and8 as a full node and the pass Mark CPU rating if you don't know what a pmark CPU rating is you can just think of it as a number that's used to sort of characterize the performance of your CPU uh so just saying eight cores is not enough to let people know how powerful their CPU needs to be and then we get to sort of the most contentious part of this document which is the bandwidth uh download and upload speed so as you can see for a local block Builder we've set 100 uh download and 50 upload and this is the reason why this is so high is

because the local block builder needs to propagate the block within a very short amount of time currently we've sort of like uh informally just said two seconds and uh the worst case block let's just say two megabytes to prop to send it to eight people within two seconds you need quite a lot of bandwidth for the tester it's 5025 and Freddy full node it's 5015 the 15 megabits per second was because uh parry's team did some benchmarks and they figured out that I think it was around 12 megabits per second is uh sort of where the upload speed that you can have and the network wouldn't break one thing to note here is that the full node specifications are

sort of the closest to minimal that you can get and this is because there's this notion that you should be able run a full node at home so we sort of haven't pushed up the requirements for a full node as much as we could for like a tester and local block Builder just because we know that with the testers and local block Builders validators they're already paying 100K so they can sort of afford to have these more higher specs requirements I think to also just add to the upload topic if any of the listeners have listened to the previous one on blob inrease so there were a round of tests done in November where we did the non-f finality test and

essentially once you had non-f finality in order to recover you need some amount of like base bandwidth cuz every node is trying to like sync up whatever it has missed as well as upload whatever it has to other nodes so that they can sync up and what we tried was having a flat Network basically every node on the network just has something like 10 MVPs and that Network sort of break LS even on regular operation let alone under non finality so around like 12ish MVPs is what we estimated as for a flat Network what is required of course ethereum is not a flat Network you have some people who have really fast internet some people in the data center some people at

home and so on so kind of a naive estimation is roughly like 15 MVPs such that even if every node on the network has this we'll be fine but yeah there's a lot more complexity trying to achieve a the bandwidth number and that's also why I think Kev mentioned or that's one of the reasons Kev mentioned that internet is sort of a tricky one to try and give a recommendation on also because it's not that easy to change right yes so I think this is where we spent most of our time sort of trying to get this EIP pushed through and yeah just as Perry said you can't sort of buy yourself better internet after some sort of limit and it depends on the infrastructure or sort of where you're located so this is most of the important parts of the EIP to be honest the rest

of is mostly there if you want to get into the particular details of like what sort of storage do you need what sort of hard drive do you need yeah maybe to adds because you already mentioned that bandwidth was the most contentious point this kind of opens the do um this box of what do we do with local builders in the future in general right because do we always want to have people with low Hardware requirements bu being able to build their own blocks or are we fine as soon as we have some censorship resistance mechanism in place are we fine to kind of push people over to using PBS do we need some enshrined version of PBS to do so because we also

don't want to rely on relays being able to censor the network so this whole topic around local block Builders is currently I think something that the community discovers as yeah worth getting into the discussions and sharing their opinions I think it's a very important topic and currently it as we already can see on the light here on the EAP we are already kind of distinguishing and differentiating here between aders and local Builders because we can assume that most tators are using meth boost but it makes it very clear that in the future if you want to still build your own blocks and not talking about fallback from MEF boost if there is a livess issue but really if you're

wanting to build your own blocks although there is some enshrined propos ability separation mechanism then the hardware requirements might just increase and I think this is the the root here of the contention right I think right now you're sort of in a position where if you don't have sort of sufficient Hardware you can just build a block that's uh not that great this is not sort of how I see it in the future because once we add stuff like ZK proving where you actually need to prove like the block that youve built there is sort of a minimum amount of Hardware that you definitely do need like maybe you can foro your eight cores in that the document says and just build an

empty block but if you need to ZK prove there's this minimum flaw that gets added and this is also sort of added with fossil as well because if fossil enforces that you need to add in let's say 16 transactions then you have no choice in the matter right yeah the same applies basically also to state so I think it's very interesting um especially the C because we could probably do an episode on the CP every year because something might change every year um as soon as we roll out statelessness or as soon as we do CK EVMS um as soon as the gas limit increases the BL fruit Bridge increases peas and so on so yeah it's a very interesting it's a very interesting one

let's put it that way right yeah I think there's still sort of conversations about whether we should have this as a live EIP versus whether we should push out a new EIP whenever things change so you can imagine four fours coming out end of the year and we need to modify this so it's either I have a preference for a live EIP just because I think if we keep making changes tracking all of the eips or like figuring out what is the latest one it becomes a bit of a headache sure I mean I truly believe that this is one of a kind proposal we have not seen so so many eips in informational category and this proposal is adding value as an informational proposal that's what I feel but I still would

like to uh get into some followup questions if that's [Music] okay all right the first of all I me thank you for this overview C and P and Tony adding some more context I know this proposal is touching so many proposals you mentioned about fossil blob through put increase qu dat and so many proposals so it's very important to understand like the need for having this proposal although Pari gave some context when we started talking about the specification of Hardware it was at the time of launch of Beacon chain which was approximately 5 years ago so that's like pretty long time that we had been done but historically General recommendation

for hardware and bandwidths are part of specs repo so this is one question that is always there in my mind like why do we need to document is an EIP what do you think is the main motivation to propose this as a proposal rather than keeping it as as a form of spec repo yeah I think the initial idea was that if it's an EIP it's extremely visible and the second one is it becomes part of the space that you can reference in other eips I can give you an example when we were talking about verle and veral transition the question was how fast can the transition happen and this is problem irrespective of what

stateless approach we choose the question Still Remains how do we transition the tree right so now if I tell you that you can use 1,000 leaves that has a certain Computing overhead Ram overhead Etc I can do the transition 10x faster if I do 10,000 leaves but the question comes in what's the hardware required to support option one and option two and without a definition for what Hardware a node is supposed to run that becomes a very hard guesstimation so in the future if we have this as an informational EIP we can say these were the values chosen because this is the EIP that sets what a requirement is for a node and these are the type of nodes that would require to do the transition

and this is the speed we can achieve so it kind of closes the loop a bit more and same for fossil and a lot of other eips right you can reference it in a way that you wouldn't be able to if it was a random specification on consensus specs or if it's like an eth magicians post it can live in any of those locations but I think having it as an informational EIP makes it a bit tighter integrated to where it's useful yeah I think initially I was sort of saying why does this need to be an EIP and after a while I sort of realized that there needs to be some point at which we say we have rough consensus on this and the EIP uh process was sort of a good shelling Point here

that is good to hear I'm going to get back to you and talk more about EIP process and and about your experiences but before that let's get over with the specs and other questions which are there soen it suggest that the proposal is a general recommendation and you also mentioned in your overview that this is a general recommendation and perhaps with even with lower specification things will run I was following the comments on Fellowship of ethereum magician which is generally a good placeholder for for any kind of discussion with respect to any EIP there was a suggestion from nexo who is one of the contributor of each Staker community so she mentioned about rather publishing this as an EIP with simple external links we can perhaps publish a Target

time to profit and this could be then externally linked to any actively maintained list that has specs and examples of Hardware that currently fits that requirement I'm curious to hear your thought on this like do you believe that adding external links and keeping it somewhere else would add more value although you partially answered the question just wanted to cement on the idea I think having it as a EIP in retrospect is probably the best way I think we just need the sort of the confirmation that we've agreed as a maybe not everyone agrees of it but we have this rough consensus on this document if I was to publish it at let's say some other website then then I don't

think it would have the same sort of confirmation that I would like that makes a lot of sense yeah okay let's move on to the next topic which is like one of the most contentious topic you mentioned about the upload speed so the EIP specification although paros mentioned that why we are going with 12 Mbps and the number 12 for the general node running and then there are different specifications added there in The Proposal yeah uh the biggest one the highest one here is about local blog building as you guys mentioned that you guys have spent a lot of time in local blog Builder part it is like most contentious and people want to understand because that's where they people can make

profit it is mentioned in the proposal that if a builder cannot meet these speed they risk slower propagation and causing late block but again going back to the comment which was there in the FM it suggests that generally speaking it has been noted that the validated Peak usage is viable than like 10 Mbps upload speed only and we are giving 50 MVPs this is like more than five times I mean five times plus because if we are considering less than 10 MVPs is it an arbitrary number or were there any research or any kind of a you know benchmarking happening in the background for this recommendation maybe I can give

some context before we get into the question so the problem here with local block Builders is basically they have to get their block out themselves right me boost users can rely on the relay they get the header from the relay they assign the header of the block which is a very small object and then the relay helps them in propagation so even though if you have a very weak internet connection for example you have 10 megabits upload and you're still using meth boost then everything will work fine very likely because the relay will take over the propagation part and everything will work very smoothly the problem is more if you're a local

builder then you might run into troubles when you try to get a very big block at the beginning of the slot and then it needs to propagate through the whole network and this is not something very new so we saw local Builders being outperformed by MEF boost Builders basically since the merch so already since the merch we saw local Builders being reor more often local Builders missing more attestations testing to the wrong head of the chain so local Builders have always been those that performed the worst the unfortunate part here is that local Builders are also a big yeah to to solo stakers right to home stakers so often times local Builders are also

those that are actually running their noes from their basement and not from some AWS instance so we shouldn't confuse local builders this with um solo stakers because it's two different sets but many people are basically in both sets and as soon as we have some fallback for using MEF poost trustless I think we can relax a bit on local block building and reconsider for what we actually need local block building at that point and maybe a bit more to follow up on concrete numbers right and positioning I would say out of N Run on ethereum I have relatively good

monitoring and a nice setup so even while so I have a node running at home and on average the node I have is at about 4 4 and A2 mb per second and there are two peaks today at uh 10 mb/ second even now while I'm having this video call on Zoom my home internet has not peaked about 10 MV per second right this is um quite easy and still well within the requirements but I do think if we were to canonicalize today's requirements that doesn't adequately address the needs of the protocol tomorrow so if this document was to say

you can recommend it Hardware a recommended Network usage is 4 MV per second this is great cuz that means I don't have to do anything if I have a 4 MVPs connection but what happens if we increase the block size to 60 million Gess or what what happens if we increase the number of blobs which will happen with Petra anyway right so you do always want to have a bit of headro and the target of the document will always be the average naive case but if you're for example someone who's a bit more performance oriented you could probably play with your minimum number of PE used you can mess with a lot of different layers to get the usage down if that is

what you care for but again the document is always at the average case so the average case would say we have roughly a 3ish x Headroom for scaling the protocol with the needs and you might also notice that earlier I had said that the flat network was taken about 12 MVPs then suddenly I'm saying 3 MVPs why is the difference that again plays into what Tony was saying we don't have a flat Network on ethereum there are these sophisticated entities with block Builders there are gigabit nodes that basically are making it easier for me to run a node at home in some ways so that's why the numbers are also a bit all over the place but again we would design for the average case and ideally

the network performs better than the average case but that is still what you designed for yeah and maybe to add to that because youve already mentioned right now that we have ways how maybe local Builders can already limit themsel in what they're doing when building a block there is for example the max blops flag that some clients have already implemented I think most clients want to implement it which basically is a flag that you as a validator you can set if you're still locally building blocks then it will not include more blobs to your block then set in that flag and this kind of allows proposers to still do local block building but not risking

let's say under pias building a block with yeah to number of blobs and then risking being reok because the block would very likely be out there very late so there are those constraints of course local block Builders can always build small blocks right as long as they have access to State and everything local block Builders could always build a very small block don't include any call data make sure the block is able to propagate as fast as possible but in the long run of course this can't be the goal here because this creates situations that we already observed today where local block Builders are not even able to fill the block up to the EAP 1559 Target So currently 80 million gas so local block

Builders are basically at 7 million gas or something on average so they don't even fill the block up to the Limit and this is very likely because the public M Pool is just decreasing in size and in the long run we might see local block Builders being more on the side of taking over completely new responsib abilities for example being includers um making sure the network stays sensorship resistant and that kind of roles and I would guess that that's just my personal opinion that local block building might not be as important as guaranteeing censorship resistance through inclusion lists or something similar one thing I do want to push back on though is I

think local block building is still different from Full nodes and I do want to clarify that even if for example Tony says local block building is not that important it will continue to be important to be able to syn a full node locally and keep up with the chain and so on right yeah I totally agree with that yeah I think the requirements are also different because for full nodes right we kind of accept that they can fall out of sync if they're able to catch up of course this is the most important thing here right should always be able to sync the network right super important I definitely agree yeah I guess the answer p is original question so the 50 megabytes per second basically we when we was at the drawing board it

was like how do we figure out a number for this and the natural number that we came about was just to look at what the global internet average is just because local block Builders they should have basically what the average is we also looked at sort of what is the worst case block that you can push through the network and like roughly how much megabits per second do you need for that and we saw that it was roughly around the average number that we came up with so like if you have a 2 megabyte block and you need to send to like eight people and that's like 16 megabytes of data and if you need to send that within like two seconds uh this is 8 megabytes so you roughly need 64 megabits per

second upload so this is roughly where the the 50 the number 50 came from if you look at bit more on um people who tried estimating more so there was one approach where you tried using peers you're connected to and trying to estimate what bandwidth they have based on how fast you can pull data from them so there have been some other approaches but I think with every approach we tried there was a different blocker which is why a more naive approach of yeah this is the average speed this is what we want to design for was the desired way to go also for example if I have a GU node at home I say get prism I don't want get prism to

take 100% of my available bandwidth because then I cannot be having this video call if you want a home Staker right so you do want to set sort of s upper limits and this is also something that gu and prism need to sort of know themselves if there's 50 MVPs gu cannot assume that it has the entire 50 MVPs neither can prism so they also need to sh it's like a shared resource so I think that's why more more naive average based approach is kind of enough yeah I don't think we would ever be designing it such that we're we say yeah this is going to go from 49.9 MVPs to 50.1 MVPs and that's why we can't make this change

I don't think that's the intent of the limit at least right and I think sort of using numbers there was a suggestion to sort of look at the network and see what people are doing or like take a subset of the network and this is sort of a bit harder and we're not actually sure that this is like a foolproof way because what if you take a subset of a network that is not representative of the whole network yeah I mean if you just take everyone who's on AWS you'll just get larger numbers than if you take everyone who's in this particular country or something like this so yeah this is why I think it's a reasonable compromise especially for local block building it makes a lot of sense and at the end of the day it is recommendations I think it would be a good idea to keep it generic

and keep some Headroom as paros mentioned and uh thank you than you Tony for explaining the difference between like local block Builder and how people using M boost get benefited in like BL building there so thank you for that I have a related question while we are talking about this uh numbers it may be with respect to capacity consideration it was mentioned in the overview that currently it is 4 terabyte and it may run with 2 terabyte it is possible when 44s are there we we can get the space size smaller we can use that but it's not there yet and that's why the for terabyte is being recommended so instead of giving a hard number what do you guys think about having what do you call is

like a range of numbers there like do you think that may encourage more users to join and participate considering Hardware costs are generally a key factor for participation and node running there yeah I think that gets into the discussion of then minimal versus recommended because if I say two to 4 tbte then that sort of implies that 2 tbte is the minimum requirement versus recommended is probably around 4 terabyte and I think there were enough trap doors in this discussion to begin with that I think we didn't want to open more trap dos but also just for context right I have a node at home that node

currently takes 1.4 tab I have a 2 TB hard drive if we don't ship 44s before that I would have to upgrade so it would be already prudent to suggest the 4 tbte upgrade considering this is a forward-looking document rather than a historic one I'm not sure if there will other considerations that would c yeah I'd be super up for adding more nuances with the full node part just because I personally think full nodes are sort of the most important sort of node types in the document so sort of saying like for full nodes you can do two terabytes but here's why we did sort of say some of that in the rationale part but for validators I would be up for just putting like these concrete numbers just

because of the Freddy 2 Eve stien that you sort of need to pay anyways for Hardware cool and I would also like to get into the part of like you know selection of clients sometimes we have noticed that the selection of clients are also with respect to the hardware availability so would you say if uh there are any client specific optimization that perhaps a user can reduce to consider this Hardware requirement for certain no types maybe I can add with that so as already mentioned the the max blops feature is maybe something that um people with low bandwidth want to look out for if they want to continue doing local block building then of course um differences in the node themselves right for example

I run a lot of ref or Aragon noes because I need archive notes that are not super big on dis I think many different notes are optimized for different things so every user should find his perfect note combination and then of course getting away from yeah majority notes um supporting the the smaller notes I would say this is basically how I would um approach that that problem very well and moving forward I have a question with respect to benefit or maybe the use case whenever we are documenting a proposal we would want to consider some basic use case of that proposal obviously here it is a lot of use case because we are providing specification but it was also mentioned during the overview that it is

kind of a document which can be linked to many other eips so I'm curious to understand as of date maybe par or Tony you can also answer that because you guys have championed proposal 7691 and 7623 as of date if this proposal is under required section of any proposal do you think it can be either mentioned or considered as required proposal for any proposal the today or in future yeah I think it could be I think I would go back to the example of the veral transition right or whatever transition we choose I can imagine if we're deciding the specifications for how such

a transition needs to look like we would need a definition of what is a supported mode in which case this could be a required proposal however I don't know one that might need it in this year or maybe in the next year so potentially it's something for for future folks to decide and I mean Kev is Kev is also a bit deeper in the ZK and proving world so maybe he also has some examples on where it's useful for that yeah I guess we're sort of on the research benchmarking side for some of the ZK stuff and moving up from four cores to eight cores has really sort of helped us given that some of the research is going to take at least five years to reach fruition on the ZK VM or ZK evm side we

probably need an nde type called aover I decided not to add it in because that would probably open up another kind of worms given theover needs GPU support Etc so yeah that's where we are currently of the ZK stuff glad you decided not to include that the smaller the proposal is better for us better for people who are reviewing and trying to move into the finalization stance by the way the reason I mentioned this like the reason I wanted to understand like if this proposal can be used as a required section is because that will give us this Clarity whether we should keep it as living or as finalized stage I understand the preference here is to keep it as living and keep it updating as we go because we may be expecting

obviously we will be expecting some changes in specs in near future however if this will be considered as a proposal that can be under required section generally speaking the dependent proposal may not move forward unless this proposal has higher status so it is a good idea to keep it into General track move it towards final rather than keeping it towards living that's number one argument and number two argument is As on date this requirements are good to run node with whatever is going on on ethereum Main net when the scenario changes we may come up with a different proposal it can be considered as you know interface kind of proposal like e

versions that we keep on adding this like proposed by get Team every time we are pumping the version and we are having a new proposal this helps us to provide a generic pacification at one point of time in ethereum history for example if we are going to tie it with the Petra upgrade if we think that this pacification is good with the Petra upgrade we should perhaps move the proposal along with the Petra upgrade I mean this is what I think and um I'm sure there are more discussion ongoing in the ecosystem and we would be in a position to decide how we take it forward but yeah would love to hear your thought on that would you be okay moving

forward with the normal track and move it towards the final status I think there was someone who was against of calling it required just because technically these aren't strict requirements so I guess I need to think a bit more about it yeah maybe just one problem I could see with that approach would be that we would have a new hardware requirements EAP every fork and this would kind of be very time consuming of course now we have to update that informational EAP too but yeah maybe having it really Shi as a standard EAP yeah would maybe cause some confusion especially if the requirements change and now in the informal EAP we just have one place that is always

supposed to be up to date I understand the concern there and whatever I shared before is just my general opinion based on the experience that I have seen here with the proposals those are being proposed to become a standard I generally think that it would be a good idea to move the proposal to a standard and it can be recorded as a part of meta for that particular upgrade yeah I would recommend to maybe talk more about this in order to push this proposal towards the review status to last call or wherever you see it going fit I would like to continue this discussion a little bit more towards your general experience as an e author to me it seems inevitable for a client developer to

eventually become an EIP author or maybe a reviewer and I assume this is your first EIP correct me if I'm wrong but as a new EIP author how has been your journey I guess this is the first EIP I've written myself I believe I've been co-ord on other eips uh the journey was quite straightforward there wasn't really much I think the hard part was just basically getting agreement on the EIP itself not really pushing stuff through I went to I think it was the EIP editing hours which are pretty useful in just figuring out is there anything missing from the EIP and getting help from genda Sam you and all the others in there so I think it

was pretty smooth well thank you so much for that feedback I personally believe that office hour are going to be helpful for new and existing authors to let them know what is required as Next Step because we have seen many more eips going stagnant and we don't want that we want that author should be around and we are there to support so I'm assuming that you may have received a decent amount of support that was needed in order to pursue this proposal but in future or even with the experience if you may have any recommendation that may help you move this proposal even better with the help of EIP editing or reviewing team please feel free to provide us some feedback on that all

right with that I am getting towards the close of the like the last set of questions that I have how long do you expect these specs to remain valid we did discuss about like it may change every year it may change with every upgrade but as we also noticed that these recommendations are not for just today we are also giving room for near future we may see some UPG coming in future do you think it would be good for next couple of years or maybe more my personal opinion is that the full node specs should be sort of down only the local Builder specs probably up only uh and the appr specs also up only so for full nodes I hope that it you

don't need to change anything yeah I hope you can be able to run a full node on like your MacBook for example also there are upgrades that kind of Follow That Trend right with pias if you have a full node it should either keep your bandwidth usage the same or reduce it if you have a validator one validator it should be roughly the same as what it is now if you have a ton of validators then your bandwidth usage should go up so that's also moving this concept of yeah if you have something like 8 million State chances are you can afford a Reit connection but if you have 100,000 Stak maybe you can only afford a 50 MVPs connection if you have a full node you shouldn't be even able to afford it

should be very cheap and easy to run a node so I think the trend is also exactly like what Kev said some numbers go down some numbers go up but we are relatively stable for quite some time I mean literally six-year-old machine and uh I want to see how many more years I can get out of it and we wouldn't doubt that paritosh you are our leg testing team engineer we would definitely rely on whatever you are suggesting is good right here anyway uh that brings us to like my next question like what is the next step for this proposal from the process point of view I can recommend that this proposal is currently in draft so it has to go on review status it is not required to be there for any limited amount of days or

number of period but for last call there is a requirement of 14 days if we keep it informational only so keeping that in mind how soon do you think that we can move the this proposal to review do you see any planned discussions or revisions before moving this proposal towards final status I don't know of any plan sort of revisions I do know that there is this extra question which doesn't block the EIP on sort of how do we determine the cost of the hardware that people should be buying at least for validators like should it be 6 months should it be like 10% of however much you pay um this isn't blocking per say

on this document in terms of next steps I don't yeah I thought that once we merged it it was kind of done if I'm very honest yeah I'm not sure no we would want you to be a little bit more around with us so the general process is you can make a simple PR to move it to the review status keep it for a week or two then make another PR to move it to the last call and whenever you make the last call PR you have to add 14 days from the date you are making PR that's when we can move it to final status so please do not just leave it as is because if you do then it will be moved towards stagnancy after 6 month the bot will kick it out of the normal uh process and

it will be marked as a stagnant EIP may not be as useful as we are hoping it to be please feel free to Ping us whenever you're making a PR please tag it on the office hour agenda item we would love to review it and so it can move sooner okay that makes sense I think we can probably bring it up in ACD as to whether we should do this Live status versus uh finalizing and then I can push another PR to to do whatever we say in either case it has to go under review so even if we are not moving towards final moving towards living status the next stage for this particular proposal is review so soon as you make the proposal to review status is good we can still make the decision of moving it into living and Final at

that point okay sounds good yeah very well we are heading towards the end of this conversation would you have any thoughts or suggestions for ethereum Community regarding this proposal any call to action you would like to share with this platform I could share the same call to action that I I think I already shared in the blob increase episode namely that theat data base of the e panda Ops people is still open to receive data from community members so it would be very cool to have many community members contributing their data so the data of their own noes directly to the xatu database which will then in turn help us to have a more

complete picture of the whole situation and analyze things around rears um around mest stations and everything that comes with increasing limits way better so this is mainly my own wish here we also now have a Dap node package so if you have dap node you can more easily install the tool is called contributor so you can more easily install contributor the e panda Ops Blog has a blog post on how you can apply it's still permission to apply and we have to give you an API key so you can send the data and as of today I think we are at 70 individuals who are sending us data which is not that bad that's roughly I think around like 5% of

the network or a bit low more than 05% of the network that is um actually actively sending us information which is great I think we want to try and get this to maybe 1 2% of the network actively sending us information so we have a good sampling of how things are very well thank you for sharing that generally speaking we always encourage Community to participate in active discussion and we do have Fellowship of ethereum magician page where they can add their thoughts and their comments with respect to this specific EIP and I would like to also respond to one of the comment that Kev mentioned earlier it was about like there is one open but unrelated comment like about the cost of the hardware so just for information the

authors May note that whatever comment they receive on Fellowship of ethereum magician if that is not directly related with specs it's not mandatory to close before the proposal can be moved forward so you are free to accept or reject that comment last suggestion but it is always a good place to have all these Pro and against comments at one place and that's why we highly recommend people to participate and leave their comment at Fellowship of etherum magician so I'm looking forward to collect some more feedbacks and thoughts on there and before we wrap up today's session I want to get to the most interesting side of this conversation which is called rapid fire round I love this part I know peran Tony has answered some of the questions

before so we have collected some new questions for you you but uh let's start with Kev Kev just to give you some overview of how this round goes we try to ask you some question which can be responded either in one word or one sentence we'll try to keep it in less than one [Music] minute so are you ready oh y cool for you most exciting upgrade so far probably Petra because there been quite a few bugs that have been interesting cool ideal validator set up to you currently because I have a minus Forum I'd say the minus Forum that I have more crucial is it CPU or the ram I

think Ram at the moment uh just because state is one of the biggest bonck currently or will be as well future of node Hardware what would you consider as ideal configuration I think we're going to have uh a lot more types of nodes in the network in the future and basically I think the network is going to start leveraging asymmetry which is what you see between full nodes and validators now that makes sense okay the final one here one word advice for node operators please try to send your data to the eend of Ste thank you so much and I'm glad I kept it with sentence as well because yes of course some of the questions could not have been answered in just one word very well my next set of questions

are for paros so paros easy to tell best client consensus or execution I actually like consensus which is nice easy deployment is it on Main net or test net test net fastest way to debug a network issue get everyone in one room and start looking at logs hardest bug you have fixed o I don't have an immediate answer no CL most used command in your terminal it's probably Docker ps- a to find what container are running favorite ethereum testnet I really like the merge Shadow for the first one well thank you so much it was real quick I was hoping that you

can say a little bit more about hoodie but that's all right that's true actually hoodie is a new network that we have and it's the first Network that that I actually got to name cuz every other test net has been named ahead of time so the naming convention is quite straightforward a testnet has to be named after a metro station doesn't matter where in the world it has to be hard to pronounce and it has to be difficult to spell so most people so far have spelled hoodie with an e in the end so it succeeds there hoodie is also I think you usual way you pronounce it is more like hoodie like the one you wear but there's no e at the end so you also

pronounce it a bit different find a Canada speaker if you want to know the actual pronunciation and uh it's a metro station in Bangalore that's great thank you for sharing and I believe you have also tweeted about it that tweet contains quite a lot of information and there some lore um we also in the office in the EF have all the city maps where all the test Nets are named with a pin as to where the test net is so robon rink be girly so gir is after gir a bhof and there's a bunch of them so all of them are testnets all of them hard to name hard to spell and so on and to Gary's Point what is life without whims so we create arbitrary rules for test Nets that was my question as well thank

you for answering that moving on to Tony so Tony the first question here is biggest bottleneck in scaling according to you definitely bandwidth I would say most underrated Hardware component storage one word to describe writing an EIP I would say being precise favorite open- source project ethereum what would you call as one essential Dev tool that's a good question there are many Dev tools let's say because I've always been a fan of one specific tool that no depth developer ever uses in production but I would say remakes one word for ethereum's future different entities

with different skills very well done thank you so much Tony and I'm really glad that you did not describe writing an EIP as complicated the password was precise because I have heard from many developers like they are good in providing specification but they don't want to keep up with writing documenting and like going through the process so if you come up with precise eaps precise proposals I don't find it's going to be complicated we are around to support you with the process part of it although Jim beo has done an incredible job in explaining the process for core developers especially and we are changing some processes to make it easier for people to like you know stay update with eips which are being

considered for Network upgrade and that's wrap for today's episode we had a great discussion on EIP 7870 hardware and bandwidth recommendation and its role as an informational EIP huge thanks to Kev paros and Toni for breaking it all down and highlighting the importance of this well defined specification for Network efficiency and hopefully decentralization ethereum is constantly evolving and conversation like this on peep pep will help Drive meaningful progress if you found this episode insightful be sure to check out the proposal share your feedback and contribute to shaping ethereum's Future

Special thanks to my colleagues at EC Akash and vein for their support in putting this episode together if you enjoyed it don't forget to subscribe and share until next time keep exploring keep building and keep perfecting ethereum this is Puja ranan sign off