EIP-7691: Blob Throughput Increase

Transcript

there was many things about especially focusing on rears we can't sacrifice decentralization and liveness these are just number one meet is about 40% nodes on the cloud and you could assume that these 40% nodes are gigabit connected very much recommend out too but also at the same time if you're even if you're not running a node or you don't want to run that just getting vocal on Twitter once we apply some more optimizations it could help us scale even f [Music] [Music]

ethereum's rollup Centric road map depends on layer TOs and with the Denon upgrade live we are seeing the real world impact of lot but with demand challenges grow as well how do we scale ethereum efficiently without sacrificing decentralization and Network Health take tuned to learn [Music] more welcome back to PE an where we learn about ethereum's Improvement proposals and latest research shaping ethereum ecosystem this is episode 143 brought to you by etherium cat hurters and I'm your host Puja ranjan today we are diving into EIP

7691 the block throughput increase which aims to provide more scalability for rollups and infrastructure provid Provider by increasing the number of blobs per block on ethereum co-authored by paros Janti Tony was Sam Calder Mason Andrew Davis Ana dietr in April 2024 EIP 7691 is set to be included in Petra upgrade if you are wondering what EIP 7691 is and why it's being considered for ethereum upgrade you in the right place so joining us today to break it down are the co-authors of The Proposal paros Janti Sam Calder Tony vter welcome

to P hey thank you for having us yeah thank you for joining also from my side it's been fun talking to you guys offline and having you here but before we dive into the proposal could you briefly talk about yourself and tell us what you are currently working on sure um I can go first hey I'm pyos I work at the eum foundation Panda Ops Team and most of the stuff we do is testing as well as coordination for foxs so all sorts of things that is required to make sure that the next ethereum F happens securely and safely uh I can go next I'm Sam C Mason I'm on the same team as Parry so we work

on a lot of the same stuff currently our main focus is obviously Petra given it's a few weeks or months away but specifically I'm more focused on like the network observability stuff metrics sort of yeah alerting that sort of Realm and starting to now dive a bit more into the analytics world how to you Tony yeah and my name is Tony I'm with the applied research group at airm Foundation recently have been very involved in research around the plop count increase but also the gas limit increase and very recently looking a lot into execution layer research like delayed execution block access lists and that kind of stuff awesome thank you so

much for sharing about you and your work now that we have got introduction covered without further Ado let's peep in hey so today we're going to be talking about EIP 7691 the block throughput increase as well as all the groundwork that went into making sure that we could realistically scale the block throughput of ethereum so the first question question that often comes up is why scale blobs so daab as a fork itself was roughly a year old so it's not a drastic amount of time and we're already talking about increasing the blobs the main reason is that eum has an L2 Centric road map so l2s are the predominant users of Globs today and L2

usage is on upward trajectory we have app chains base themselves are scaling up to 250 Mega we have arbitrum ZK sync we have a lot of different l2s who are all independently scaling their own throughput as well as a lot of applications and other people deploying L tools themselves so there's been a huge demand of blobs over the years and when denb as a fork happened it was the first time we were introducing the concept of blobs so naturally we were relatively conservative with what values we chose for the blobs themselves so so the L1 needed to figure out scaling these blobs and ideally scaling these

blobs reliably over the years failure to do so basically limits the L2 ability to grow sometimes the l2s do fall back on using call data but ideally they don't and ideally there's enough blobs and they're cheap enough that they don't have to think about this or worry about this and Everyone likes the cheap transactions that the road map promises so it is something that ethereum aims to continue delivering and there are Coss a couple of blockers we can't just suddenly increase the number of blobs by let's say a factor of 10 right so we had to First think through what the problem sets could be a large one that was brought up on all cabs for a few weeks or months at a time was recovery post

nonf finality so ethereum's always built to be resilient against the worst case scenarios so what if there's a client bug what if there's a minority client bug majority client land bug whatever we need to be able to recover from this and we need to be able to offer that home stakers are also able to perform under these scenarios they should always be able to sync produce blocks and on average we want to maintain that ethereum has a Val low reog rate so it's reliable and safe to use the other topics were how do we collect this data reliably so of course we can spin up a bunch of nodes on the data center and

then claim that a 10x 100x is fine but that's not reliable collection of data in itself once we collect the data and find a way to collect the data we need to also analyze it and try and find the constraints that the chain has so I think all of these blockers are what we're going to be talking about today across the three of us so to address the first one the edge cases of how the chain looks we had a line of Dev Nets at the end of last year called nonf finality Dev Nets fun fact we also just named them nft Dev Nets in the beginning cuz we didn't know what we would find and we didn't want people to immediately go digging around ethereum itself has a concept of finality which

allows it to be live but not finalizing this implies that you're able to continue using ethereum even though the version of ethereum you're using has not been checkpointed and never irreversible right for example if there's a bug in a majority client or a client that has a decent stake in the network and under these conditions it just you might even have multiple Forks of ethereum but the network the chain keeps running however once the bug has been fixed then all of these clients or Forks would need to converge on the same version of ethereum and they would need to finalize again but now imagine a world in which we

increase the blob so much or the gas or whatever we're talking about that the process of downloading and syncing these good blocks might just exceed the rate of production or even the process of verifying it might exceed the rate of production of these blobs now if that's true then we can never realistically recover from a non-f finality event so there's no path to safety so to say and this is extremely scary it's an edge case we want to make sure that we never cause it's an edge case we want to make sure that we're not in right now and poent will never be in so in order to test our hypothesis that this is not what ethereum looks like and increasing

the number of blubs won't put ethereum in the space we set up a DEET it was a very large one so there were close to 600 nodes if I remember right roughly a million validators so equal to/ representing mainnet ethereum we also use the client split offered by client divers unity.org and what we did was at every experiment we would have a healthy Network we then had a few hours or days of non-f finality and then we healed the network again and once we healed the network we would analyze how long it took to heal and just to know this is in a clean El State this basically means that the

execution layer block verification and state access Etc didn't cost a lot of time and the second one is that while we had like 600 to yeah upper limit might even be a th000 nodes we're still talking about 10 to a factor of 20 lower than what main net actually is so while this test helps gives us a lot of confidence it isn't a complete representation of what main net would look like and in order to collect a wider array of data we did a bunch of different rate limits so one thing is we had what 5% gigabit nodes or these are nodes that

you can imagine exists in the cloud and roughly 95% with 20 MV download and 10 MVPs upload for example and then we varied each of these numbers until we figured out kind of what are the limits of what the network should support what are the limits of the network that we could support and just to give you an example based on some measurements main net is about 40% nodes on the cloud and you could assume that these 40% nodes are gigabit connected and the rest are a bit harder to trace down but it gives us a general idea of what is the source of Truth and yeah we started off with spinning up and down all of these

machines it's a lot of cores a lot of ram that we had to rent for a very short duration the experiments themselves tend to be expensive so we tended towards pre-planning a lot of things and as soon as possible kind of ending the experiment and I can go a bit into what the outcomes of the experiment were so one thing that we learned almost straight on was a mental model of what the ethereum P2P layer looks like needs updating so the first version of the nft dev Nets that we had had a very low bandwidth limit applied to it and it was completely flat and we saw that even without really stressing it even without

non-f finality the network was fine but post non-f finality the network actually never recovered this showed us that flat networks help us designed for the worst case scenario however it's quite unrealistic you probably will never achieve an ethereum that has every single node with under 10 MVPs of um Uplink and down Ling or even symmetric Uplink down link that's just not how the network looks we will however always always have some percentage of these nodes who are in the cloud and even home stakers who have more than 10 MVPs who kind of end up doing the frontt of the work right so this mental model of flat

ethereum with very low resources probably is not right we need to update that model and that's where some of the analysis that Sam and ton doing would also play to so the second one is on all the scenarios that we looked at long range sync time seem reasonable so the node is always able to recover from these edge cases even when we go to a flat network of like 20 MVPs to 10 MVPs and bit in the next slide I would be talking about what the conclusion is but we're always able to recover from the worst case scenario and 20 MVPs down versus 10 Mbps up tends to indicate recovery limits I

think once you go below this you're producing stuff too fast in order to be able to catch up to the chain however while doing this we noticed that even on these gigabit nodes they weren't actually saturating their gigabit which means they were pretty much at like the 160 MVPs with roughly 5x Headroom available there and this tends to indicate that there's some sort of puring range request optimization that we are missing and we potentially could look into and one thing we noticed is that when we had a flat network with 100 MVPs down and 50 up the bottleneck observed was in fetching from multiple

peers we were sort of saturating the 50 mbit up but there was a lot more download available even though all the nodes were not downloading or uploading at the same time so there really is a bottleneck in being able to fetch these small chunks from multiple p and this some theories out there as to why this the case and we're also actually able to measure a flat network degradation so 30 MVPs down and 15 up the network starts to degrade around the edges so the target vot rate tends to drop just a little bit and so on and noticeably starts to degrade once you go below 20 MVPs download inten now however this number also is directly related to how

many nodes are in the cloud so once you have like a 40% of the network having gigabit connection then suddenly The Edge nodes could get away with slightly lesser requirements because someone else is doing front of the work and here's a brief example of the non-f finality recovery scenario that looks like at least so the main reason all the nodes don't start up at the exact same time is it just takes time to run these scripts from one machine especially over dozens SL hundreds of machines but you can see that the trend is quite up into the right and eventually almost all the nodes make it back up to head and network finalizes again and a couple of basic conclusions that we come

up to CS are not purely bandwidth limited this is actually great news for us this basically means that if we have a decent set of healthy gigabit nodes in the network once we apply some more optimizations it could help us scale even further than where we are long range syncing itself does not seem to be an issue even at the higher blob counts so what we did was we kept pumping the network in with a lot of blobs such that it was closer to four five and sometimes even six blobs per slot and this is indicative of how it would look post the EIP 7691 change and it seems like the blob fetching as well as verification

was not the bottleneck that we were worried about thankfully however there were a couple of future research streams that did come out of this so blob censorship bya map boost for example could lead to different recovery patterns cuz you could see more blobs that were 0 six or at the max or being dropped as opposed to our test which was more naive so they were like most slots had some blobs in them so the load was more evenly distributed the optimizations of get blobs was mostly not considered this is the optimization in which if an El's mol already has the blob you could fetch it directly rather than the CL downloading it again um at the time of doing these tests not all

the CLS had this feature implemented so this is something that by now almost all CLS do have and also helps a decent chunk with improving our throughput so we will need to redo a lot of these tests to understand some more that and uh more bandwidth constraint nodes might actually be needed in feature ad so whenever we're doing testing we probably will be introducing these bandwidth constraints early on to actually understand how an upgrade affects what we imagine the mental model of ethereum to be and while doing these things we also came to the understanding that formalizing these Hardware requirements and network requirements is becoming more and more important we want to

operate ethereum at closer to what its limit is and it's harder to know what the limit is if you've never defined what the requirements are to run a node so Kev has been putting a lot of work and showing up at ACD and making all of these proposals to try and standardize what an ethereum node can be and it's being done with a roughly 5ish year timeline so the hardware that that's being recommended you can expect to will be good for about 5 years along with recommending Network parameters and both of these things together would help give us a much better idea of a how the optimizations play out B what the network layout and topology could look like and C if we were to approach

scaling from different perspectives for example doing blob parameter only Fox how that would look like and yeah for most of the outcomes of the nft dev Nets so good news there's nothing to worry about ethereum will be finalizing even at these higher block throughputs but the question Still Remains what is a safe number to upgrade to so while the nft Deets were going on we had EIP 7742 which was a way for the cl to tell the El what the blob count should be and this was not implemented on the nft Deets and the reason it wasn't implemented and had been a bunch of months of work put into this is that

there was quite a lot of intricate details we were missing tending to be around gas estimation SL validation of sync and stuff like that on the E so rather spending more time trying to fix it around end of November we decided to go with a more simple approach EIP 7840 and the EIP essentially introduces a blob schedule so the blob schedule would exist on both CL as well as the El so it is redundant data that we were trying to avoid but for sake of speed and simplicity it's faster to just specify it in two locations and this also allows us in our testing to more easily play around with blob numbers so that we can actually make sure that the

network will be fine and the throughput will be it right yeah thanks Terry in this part I want to quickly highlight some of the Empirical research that we did of course not only me that many other people at the Firm Foundation but also at other organizations did in order to in the end Steel Man The Blob count increase for Petra so for the following you might just click a few times this kind of shows you all the research we did there was many things about especially focusing on rears because what Perry just described was the sying problems that come with more data but this Empirical research more focused on rears not really every Miss

slot but especially focusing on roks which means kind of the proposer tried to put a block out but in the end the block was reor on this slide we can see on the top chart the number of rears over time and on the bottom chart we can see the M slots over time and here it's way more important to focus on the top part because the M slots are basically those slots where the proposer didn't show up so miss slot is defined as a slot where we didn't see a block signed by the rightful proposer so this might be just either validators proposers being out of sync in their slot or offline and the top chart showing the r is is more

important here because roks are actually based on the number of so there is definitely some dependence on the number of data and how it relates to reor and with a blob throughput increase we are of course were worried that the number of reor Might increase um luckily what we can see in this chart is that since the tenun hardw workk the number of rears is is trending down and is as low as it hasn't been for quite some time at the beginning when blobs were rolled out this looked a little bit different there were some yeah some difficulties to resolve at the beginning but then as of now the network looks very very healthy and we see only very few reor nowadays

we see the same basically on this chart where we can also see the tun hardw workk happening and then especially the number of rears for professional entities Trend it down to very low numbers while for solo stakers and Rocket pool for example rockol stakers it stayed kind of it remained the same and the reason for that is basically because solos sters and Rocket pool validators same as many of the unidentified validators are the users that are heavily using or heavily relying on local building and are not using MEF boost and on the next page we can see this yeah we can see the on the

left hand side the MEF boost Builders and on the right hand side the local Builders and then the reor rates and we can see that while people might often think that solar stakers are doing worse when it comes to R it's actually the local Builders right so local builders in a disadvantage because they don't use M boost which means they don't have access to this very fast um block propagation that the relays take over so this is very important to not conf use in the context of when we talk about increasing the hardw requirements that come with Lop frin increase that it's most of the times not really the MEF boost solo stakers that are struggling

but really those if solo stakers are struggling then it's most likely those that are not using meth boost this is very important to mention and on this chart we can see the evolution of the re Orcs over the number of blobs per block and as we can see is right when tenun was shipped so right at the beginning we see big bars and then it kind of calms down and nowadays we have a very few rears so now we are at today's yeah reor grade and here we can see Harry already indicate that it's very important to also look at the distribution of blops over blocks and here we can see that blops are very unevenly distributed over

blocks so we either see blocks with zero blops or we see blocks with six blops this was way worse right after the then hard fork and the situation is definitely improving but nowadays so as of today it's still the case that we see either blocks with zero blops or blocks with six blops most often yeah and then Sam will now focus a little bit on the especially on one of This research pieces that gave the EOP the final push I would say yeah cool yeah so I've just gone over all the research and the dev Nets and everything and we have this EIP that's sort of sitting there temporarily

has a placeholder Target and Max but we don't know what to set that value to so actually deciding that parameter the priorities are pretty simple so we can't sacrifice decentralization and liveness these are just number one but then obviously we just want as much throughput as possible and if you look at the top secret research on the right like more blob count more good it's pretty simple but we actually we need to pick something that's you know not going to break the network so when you sort of chart how that looks you've got decentralization on the left on the vertical axis and then Max blobs on the horizontal green is main net today we want this EIP to be in that gold area we don't want any home stakers to drop off

so we've got to pick where along that on that gold line or yellow line we can set the max blobs too uh and obviously like yeah avoiding hom steg a drop off that's like a horrific outcome for this CIP if it does happen so just to recap on the home stakers they're ethereum's most valuable asset decentralization is the whole point but unfortunately they're also the most bandwidth constrainted and especially with upload and this is really unfortunate considering they have to when they go to propose a block they have to publish this block to their peers along with all the blobs so upload really comes into into play here and potentially the hardest problem is for us it's just really hard to observe how

they performing where we don't have any metrics or data directly from them like historically we can see the blocks that were created by home stakers but then we would observe them on data center notes and it sort of invalidated the data a little bit and it was an unknown and there was no real data for this at all so we sat down as a team and sort of brainstormed some ideas turns out we've already got a data pipeline called zaru that captures a lot of this timing data so like you know when a block is seen when a blob is seen on a node when an adastation is seen on a node and it all gets aggregated and then like anonymized and then published back to the community and we rely on it a lot internally but it doesn't have any home Staker data so

we came up with a plan to open it up to the community and a bunch of people from the community signed up they submitted the form and now they run a side card next to their Beacon node that sub commits this timing data to us in a privacy preserving way quick shout out we're definitely ke to get more data if you're interested and this sounds cool to you yeah follow that QR code uh or hit one of us up and we'll get you on boarded so we ran this scheme for about six to 8 weeks to get enough data and it offered a fresh perspective on the problem so finally we were able to identify the blocks that were created by hakers and then actually like seen on the other side of the network by these home stakers as well like closing the loop which was awesome and this E3

search post was yeah it sort of dived into the data and it comes to this final conclusion at the end of why we picked six and n and this is sort of yeah the final conclusion so there's a lot going on on this graph I'll uh I'll just dive into it a little bit so this is block arrivals as seen by home users when the block is created by a home user and it's built locally so no Mev boost involved and this is like worst case worst case worst case worst case so no Mev boost which is what Tony talked about before so there's no relay on the other side proposing and and spreading the block on their end as well which they usually have high bandwidth and they're well

connected so it really helps the home Staker these are locally built blocks so there's no help there uh yeah SOLO stakers or home users yeah they don't have good upload they don't have good download and then also on the other side seen by these same group of users so we're really really talking worst case and then finally we just bolt on the absolute worst case block size in Erp 7623 just to really like completely cover all our bases so then on this chart the black dots on the left these are the actual individual arrival times and we can draw a trend line for P95 which is the red one cross and this means that 95% of the arrival times

exist underneath this line so 5% is above and we can sort of like consider these outliers I suppose but this trend line actually arrives a Max of nine which is pretty good considering this is like yeah so many worst case stacked on top of each other and it still supports a bum which is great in reality like main net doesn't actually work like this we don't just have locally built blocks and we don't have you know bandwidth starved on both the block proposer and the other side of the network so to sort of like reinforce that this is safe this chart is a bit more realistic so this is solo stakers and home users but they're using me relay to publish

that block and it's also only using the average block size of the last like three months or something and this one if we do the exact same thing it actually arrives at a way further you know sort of predicted Max of 20 so in reality like what we can actually support safely is probably between 9 and 20 we just can't know and we'll we'll probably like have a better idea post Petra and as we get more data and as more people start contributing their data but for now nine is like the safest and yeah it seems to be the best point on that that Gold Line that we referenced earlier yeah that's all thank you very much thank you so much you all for explaining this it was very interesting to learn about these many

numbers bar you started with sharing about blockers Dev Nets and the name of the devet nft devet was pretty interesting obviously I understand this is an update to existing specs so we were expecting a lot of number to you know verify why we are getting this number where obviously Sam's chart which was very interesting played a big role there you also mentioned about Hardware requirement of the EIP which was good and the best part of it was it seems like the spec is more or less there for 5 years because there was some discussion around you know how we are going to put the status do we need to keep updating these aspects and things like that perhaps one day we will have a

discussion specific on that proposal that's pretty interesting proposal so we'll get there and Tony you have shared list of so many researchers would love to add some or all of those links to our resources section so people who are interested into diving a little bit more deeper may be able to get to understand these things so thank you you all all for sharing all these details with us all right yeah it was fascinating I mean when we see all these numbers as a non-developer I can say it may not make sense to me as much as it will make sense to any developer and people who are curious fantastic presentation I will say that a lot of the analysis and

the approaches taken to the analysis is also kind of the first time we're trying this out I think Sam was already involved in the initial decision for choosing 36 right with the call data test do you maybe want to just briefly mention how that was and how that was different yeah so when we did 4844 for the first time like blobs were a completely new concept so we had really no basis to go off like we do with this so a couple people at the ethereum foundation we sort of organized a Big Blocks test where you could essentially fill blocks with transactions that just blew out the block size a bit that would simulate essentially as if we added blobs on top

for those blocks and then we could analyze how that performed you know what the attestation rates were if it got reared for example I think there was two individual tests for this that were done about 18 months ago and they gave like a rough idea of something essentially just like if we roll out 4844 with 36 like is it going to completely blow up the network work and we saw no but it it was definitely like a a very early version of yeah this analysis that we've and this sort of model that we've come to it was sort of as good as we were going to get I think but yeah it ended up working thank you for sharing I think that was my very first question if I remember the number correctly it was 3x6 and you

[Music] already I have a question if you would want to put up that uh chart on screen very well this question is with respect to reor chart and I noticed that it was with respect to different entities and we were trying to see what was the reor situation with different entities I understand the explanation given there was because it was locally building and not me boost but I want to understand does it any way get affected with the number of participant for that particular entity I mean participation does it yes I'm talking about this chart because I see one of them which is like kind of almost similar the okay I this is for solo stakers so wow that is good

so I was thinking that this is going all consistent and others have more variation so we're just trying to understand does the number of participants affect this chart in any way yes so it's often times difficult to empirically analyze RS just because of the many different impact um factors yeah that play out when it comes to R for example staking pools nowadays are playing timing games so they are risking propagating their block a little late to gain more me which also has a significant impact on the rrate and what this chart kind of shows you that is that many professional

entities as of tenun could get their R grade down to a certain level and this is mainly because of meth boost right this is not really because solo stakers are doing worse or rocket pool validators are doing worse it's mainly because they are those users that are yeah more rarely using meth boost in the end it just happens to be the case that solo stakers are also the users that are doing local building most often times do we expect with epbs and other proposals is proposals which are in proposed in future may be able to help streamline it even better yes exactly so epbs can help on that front then of course inclusion

lists because they argument this often times as soon as we have inclusion lists we have enough power with the solo stakers to still determine the contents of a block does enforce sensorship resistance so there are many things that play into that but I would say the future for that is looks kind of bright with all the proposals that are floating around solving that well thank you I think my next question is for a ma in the presentation you briefly mentioned about um home steers concern of bandwidth constraints I understand sometimes when we are talking about spec changes it may come up with tradeoffs so what are if there are any risk or

concerns with increasing blob through put and U do you think it will affect home Staker too much or like we having enough mitigation plan in place yeah cool I think it's just a reality that if we increase blobs like we will lose a certain percent of the network that's just naturally how this the network is sort of structured we think that it's at like an acceptable rate at the moment and this increase you know will not make a material impact to these these users I think also one thing that sort of helps us out here and counteracts that function where increase blobs and we lose participants yeah there's other optimizations that are happening under

the hood so Parry mentioned at the get blobs optimization which fetches the blobs from the execution layer mle which already has them it's already spent the bandwidth on fetching those blobs things like that and other peer-to-peer optimizations sort of counteract this so I think for this Fork I'd actually be surprised if there's any if any sort of drop off or issues for home stakers but yeah it's a very complex system I'd be way more worried if this was like a three or four or five times threport increase but it's not so yeah should be all good for the home stakers thank you I think it is good as you mentioned in your presentation as well like etherum

do not want to compromise in decentralization we definitely will have some laws but would not be significantly affecting the network very well my next question is for paros as he has been involved into all testing Dev Nets and all sort of things so we understand that there had been some network monitoring since 10 maybe with an example if you can let us know what monitoring tools were used that help us get data to indicate that Network can safely scale with the numbers that we are proposing with this proposal well most of the data collection tends to happen via zatu so that's what Sam and Andrew as well as Matty who relatively recently joined the

team mainly work on we do tend to deploy a version of zatu for most Deets so that we actually get this sort of data and we can analyze it ourselves as well and Philip from the team has built this tool called gomi and Gumi allows us to submit blobs at a finer green level so we can tell it that we want to see an average of seven blobs on the network even if it's higher than the Target and G will try to make that happen and then we use zatu to try and visualize how that impacts the the network in itself so it's kind of two or three Tools in in our Arsenal that we use to achieve the goal but the kind of downside of this

approach is whenever we're looking at Dev Nets we tend to only have data center nodes like for example in the nft dev Nets I need 500 600,000 machines I reasonably cannot get that at home so likely I will be using Data Center nodes so one thing we started doing around November is using a few of these Linux tools as well as anable to apply like a bandwidth as well as Network limitation on these Cloud nodes so we can artificially induce latency we can artificially induce band with limitations and so on so that goes a decent bit to help but that's kind of the Crux of the problem so P2P is hard I

don't think we figured out one simulation strategy that's worked one devet strategy that's worked or one data collection strategy that's worked it's likely that it's always is going to be like a super set of hey we've tried two to three different things they all point in this right direction and that's why we made the choices that we make I do know that the EF is planning on investing a bunch of resources over the next year to help us demystify the P2P layer a bit more so that we can have a lot more guarantees if that's via simulation Deets data collection we're not sure yet but there's some plans in place to try and make that better that is encouraging and I understand

there are some bounties for some other research work ongoing are there any bounties for like tool providers or people who may build up new tools nothing right now I think if someone's interested in simulations and interested in P2P simulation specifically I think we'd be happy to talk but in general we're still at the phase we're gaining the best of what tools we have right now and we're yet to figure out what the meaningful Next Step would be I would love to share this piece of information with each similar team maybe we can get someone who would be interested in P2P simulation and may be able to come forward and help us on that talking about ethereum's broader

road map as we are looking ahead how does this proposal fit into ethereum's long-term scaling road map especially with pias coming up the EIP which we are expecting with the following upgrade and I would also love to understand should infrastructure provided start preparing for further data availability upgrades yeah sure so I would say the blob through increase now to 69 is only a first step so it's kind of one step we had to take because we realized that rollups have the demand and we kind of need to yeah provide the supply and then of course the next bigger goal should be ped us which would

then allow us to scale the network much further but first by finally introducing some availability sampling that would then allow solo stakers to also to still participate without being worried about those linear scaling increases that come with linear Hardware requirement increases and this is then definitely I would not say the end goal but this is the next big milestone that etherum definitely um yeah has on its Mission yeah and I think beyond that there's also pias at least as it's written today tends to be reconstruction and sampling on like one dimension and there's also longer term plans of doing like two

dimensions and so on so I think there's a research road map already for a roughly 100x blob increase over the long term and I think pias already delivers a roughly 10x improvement over the current state there's also a lot of discussions about decoupling forx from blob parameter Forks so that's a interesting approach as well and the main idea is that the type of research that needs to be done for deciding if a blob increas is safe or not is very different from the type of research testing Etc that needs to be done to see if a fork is safe or not there's a lot more implementation complexity of course with

a fork than it is with a blob parameter change especially in the example I showed you with the config once you change the config numbers clients will be able to accept it and increase the block count the longtail of the problem is mostly data collection analysis roll out figuring out scheduling and stuff like that so it's going to be really interesting to see how that plays out I don't think we've had one yet but in general it does make sense so that we can offer these more conservative upgrades but we can do them more often rather than doing massive jum um every year or every half a year or so so we do see a lot of upcoming changes in future

yeah very well while we are talking about this proposal I understand adoption of any proposal which is deployed on a network upgrade has a lot of importance we would love to understand how it has affected different teams and this proposal is not just affecting ethereum code developers but also layer to rollup providers and other INF structure operators are there any suggestion or guidelines or maybe any checklist that L2 teams and infrastructure provider should be aware of in order to take advantage of this increased block throughput yeah I'm not sure if there are anything to be careful about I think rups just get a lot of space for posting

their data even more space than they have today and apart from that they will not have to think about moving to posting called data again because this was often times in the discussion that if we don't scale up the blops rollups will be forced to move to call data posting again or even post on some other data availability chains and yeah this is kind of also a guarantee for rollups that aerum sticks to the mission of scaling vertically through layer twos I think there's maybe one fure that we've tried differently this time around typically we've had the target Max symmetric so or like half so gas limit is 30 15 Target we've had 36 as the blob

and this is the first time I guess we've had an asymmetric number so we have 69 so the update fraction is going to change it shouldn't meaningfully play a role to l2s Etc but maybe they have some custom logic that might need some updating I'm really not sure but it is a difference as to how we're doing it now as opposed to traditionally right yeah so this means that the base fee can scale faster downwards then it can scale upwards but for rollups this shouldn't really yeah get into their way maybe this is a great opportunity for L2 and other infraa provider to maybe participate in the test net and come up with any

requirement if they may have if it is not being compatible they can suggest like they are looking for some more guidelines and inputs so it's another good thing to happen I wanted to ask this thing I think I missed it earlier about decoupling Fork that you mentioned is that with respect to etherum main only right we not talking about layer to because we will be going with the blobs here yeah this is just for ethereum inet so you can imagine in a world where we had this we could have done a blob increase 3 months ago 5 months ago whatever based on these rorate charts down uh trending downwards we could have said okay hey a lot of problems we noticed that the launch of Danon seem to

be solved we have this brand new optimization that seems to help why not already ship a blob increase while Electra work continues parallel awesome thank you so we have some upcoming proposals how to do Network upgrade in this new model looking forward to it I think the hardest part will be finding out a naming scheme cuz we can do a lot of blob parameter increases really quick and we don't have that many Fork names left yeah I think this time we have to get on numbers alphabets are 26 only very well we are coming close to the end of the podcast do we have a few more sections to go I just wanted to understand here or maybe if you guys

want to share some message for the community for those who want to contribute or get involved Beyond developers and uh researchers stakers and end users how they can contribute to the discussion and testing around this prop yeah I've got a really easy one and I'm going to Shi the Z2 stuff again uh it is actually just the best way for like a tight feedback loop with us and with the researchers and with the community if you contribute your data and run that that side car next to your node it's sort of something that we've never had before and it it will do the work for you so you you just set it up and it will sort of complain on your behalf if

things start to go badly on your set up but also at the same time if you're even if you're not running a node or you don't want to run that just getting vocal on Twitter or contributing in the E res search posts stuff like that is always a really good way I know that everyone who writes those posts definitely looks at every comment that comes in so yeah I would recommend that and especially around the fork uh being vocal on Twitter yeah things like that we definitely pay attention to so I would recommend that maybe to add to that so as I'm also very big KATU user I can also very much recommend KATU also for validators to use the data to look up their own performance because you can

basically check when did my blocks arrive in Australia when did my blocks arrive in the US and so on so it's there's a tons of data ready to be explored and super interesting for every valid dat out there and I think there's also a recorded TC session of you showcasing how to use data set right right right yeah we are going to add those links here please share it with us and we would love for our followers listeners Watchers to maybe follow all those links and get more information about that very well with that we have come to the most interesting section of this [Music] podcast we have recently started section called rapid question round where we try

to collect answers from you either in one word or one sentence we'll try to keep it in within 1 minute but if it is not that's not a problem we want you guys to go ahead with honest and interesting answer for community so if you are ready maybe we can start with paros what is the key to successful ethereum upgrades spending a lot of time actually specifying what the edge cases are and then trying to trigger those edge cases on a lot of Deets and I think having multiple teams looking at a certain problem or a certain for really helps with that diversity of thought I remember this really strongly during the merge a while a lot of the devs working on it were extremely worried but we took

solace in the fact that we weren't the only one looking at this problem there were a group of like I don't know 50 to 100 devs at the time looking at this problem so it gives you some sort of confidence and solace in knowing that you're not the only team looking at this but instead there's multiple teams multiple angles multiple approaches to try and make sure that ethereum is success F that's definitely not one sentence but what do we expect when we are talking about successful ethum upgrades very well uh the next one here is favorite testing related EIP inetra ooh The Blob schedule increase actually I like that way yeah that would be the favorite favorite tool for ethereum test Nets uh right now Dora you have been an author and tester as well so what is

easier writing an EIP or testing I really didn't like writing an EIP I prefer testing you're good testing strategy I like making a lot of lists so I tend to have really long lists really long notes and go from that biggest challenge in testing EIP or upgrade keeping eye on so many different client combinations one overlooked testing tool ooh I would actually say zatu I don't think we call it out enough for testing a testing challenge you would turn into a meme the client diversity it's we have a lot of Clans St us now your favorite ethereum meme so far oh wait there's a great one from Sam that's just saying I

am a researcher now testing ethereum in one word or phase rewarding well thank you so much for all these answers these were all great very well so let's go ahead with Sam so Sam your favorite ethereum execution client uh I run them all but never mind one word to describe ethereum staking enoy enjoyable biggest challenge for node operators I would say uptime and maintainability most exciting ethereum infrastructure or upgrade Pedas for sure one word to describe solo staking a little chaotic yeah chaotic most underrated ethereum tooling project the ketosis ethereum package I think it has

a lot of like rep within the core devs now but outside of the cevs it's still sort of finding its feet one key Improvement needed in validator ux I think the consolidation stuff that is coming in in Petra for sure will be a big burn your go-to tool for monitoring ethereum nodes actually zaru as well I use it personally one word to describe me's impact also chaotic future of decentralized infra in one word complex well thank you Sam well done here I was hoping the answer to the question of staking was like it would be challenging more challenging because they always keep on fighting as you said with the up

time and things like that but yeah chaotic is there as well okay that we can move on to Tony starting now most exciting ethereum upgrade right now right now so we're talking about Textra let's say 7702 so the account abstraction pushes happening there he challenges in scaling ethereum bandwith one word to describe ethereum's decentralization let's say m magic my favorite word was Beauty that's the beauty of like e that's a good one favorite rollup solution netive rollups very pilot recently most underrated ethereum infrastructure project I mean I cannot mention again so let's go for

kosis one word to describe padas neartime future of scaling biggest barrier to mass adoption of ethereum ux most critical ethereum research Focus Skilling one word to describe the future of modular blockchain design vertical integration what drives you to contribute to ethereum the people the community and the core values within the community well done very well done you all thank you so much for answering all these questions I hope our listeners may also find it interesting as well as informative as we wrap up this has been an incredibly insightful discussion

thanks to all co-authors for their work in bringing this proposal closer to mainnet deployment yeah thank you for having us thank you very much yeah yeah thank you for those looking for additional resources on EIP 7691 we will try to add as many as possible links in the description section you may also find links to follow our guest so please check out description of your podcast as well as YouTube a huge thank you to Paris Sam Anon for taking the time to share an overview of this proposal and to all our call participants for joining us here I would like to express my gratitude to my colleague at ethereum C especially Akash and Ving for their

support in producing and coordinating this series for the community and of course thank you to all our listeners if you enjoyed this episode don't forget to subscribe and share and we will be back with another interesting proposal or ethereum research update for you until next time keep building keep scaling and keep perfecting ethereum this is Puja ranan signing off