All Core Devs - Execution #184

Transcript

[Music] e time

Tim Beiko: okay welcome everyone to acde number number 184 uh we have a bunch of stuff to cover today um first we'll talk about uh what happened on mainnet over the past day or so then there's a couple things we missed last call that were important so I bumped them up to the top of this agenda to make sure that we uh can cover them uh so the state growth uh work by the Paradigm team and then um there to Retro retroactively apply theps that uh we wanted to finalize but have like bued for two or three calls now and then just quick shout to the denen theps uh and what uh what I suspect will take the

bulk of the call uh is talking about Petra uh so there's some updates uh on uh 2537 which is included around gas costs um Mike had some updates about the a questions we had around uh inclusion lists last time um Alex can you please stay muted uh thanks um and then um yeah we have a ton of eips that people wanted to discuss and provide updates for for pectra um we'll see how much time we have left when we get there but I think at the end we probably want to time block a good like 15 20 minutes uh to actually hear from the different client teams around what are we including in uh

the first uh what are we including in the fork and and and trying to build for in our first Dev Nets um um because we already have a couple things and and I think having like a finalized scope as a at least a first uh um yeah a first set of death Nets will be valuable so um yes the kick is off uh main net Miss slots so we saw a bunch of those yesterday Terren before the call you you you mentioned it as well so do you maybe want to share an overview of what you saw and we can we can go from there

Terence Tsao: yeah definitely thanks for having me so uh what happened yesterday was that well let's go back to how like consensus work right so block reference blocks but if today we see reference on

the Block but if the block never arried or like in that case the block will never be imported so on so basically on that case that the block is missed considered to be missed by the client right so we have seen few of those before even last acbc last Thursday I mentioned it on average we see um 10 to 20 of those um instance um per day so we have been looking here and there and then we basically come to conclusion that we have seen those gossip from old the client implementations we have seen those gossip from old Builders so we kind of suspect it was like a really

issue so anyway so let's sorry has a question yeah so those blobs are never been seen so essentially yes they are never arrived at least from my notse perspective it could be dropped by the earlier uh it could be dropped by the ear I mean it could be dropped earlier already but from my Note I've never seen those blobs okay so let's go back to yesterday what happened was um I guess there was heavier um blob traffic I think at the highest point we see like 53 like gr per buy so that's basically 10 times more um blob rate then basically what we had two days ago so I I think at the high point it was at 1/4

of the code data price just um just to give a reference on like how much higher it was right and because of those uh because of those blobs are appearing more frequently and because of those then we are seeing more instance of that so at the high point we're seeing like um 20 to 30 um those type of blocks basically they never have blogs so we cannot import those right so they kind of result in like two to three Miss block um for eoch and then he has becoming a lot more alarming so we kind of like send send a few telegram message to basically the relayer to the Builder and then what happened at the end was

that block Rod um turn off their relayer and everything started working again right so right now um we're right now like there's a strong evidence this is like a blocks Rock like BBN issue so because of the BBN they basically dro the blob somewhere along their Network and so basically their relay has been shut up until they figure it out so we hope to see a post mot from them soon at the end from the consistent client there's this this also bacon API basically to allot uh to to basically prop get blocked and then we're also hardening that implementation to make sure that block can still be propagated even the blog has been seen on the

network right so yesterday's M blog wasn't so much about like client couldn't handle that type of workflow because I I I basically content that all the Miss block will costed by the block RW issue there's probably like 99% of it so so so so but but but then there is still that fundamental issue that okay what happens under yesterday's traffic uh I I I suspect client yes may import block slowly before but that's something that I don't really have a strong evidence on that's something that still remain to be seen but yeah that just an update

Tim Beiko: thanks I really appreciate the context um there's a question in the

chat from Perry uh mentioning you know whether we should re-evaluate how the circuit breaker Works in this case um because I believe the the current fistic is five consecutive slots and obviously we didn't quite hit that yesterday so um yeah anyone have thoughts on this

Terence Tsao: yeah so I think even for the circuit breaker it wasn't close to hitting that I think maybe the circuit breaker is too loose but then again right if you make the circuit breaker too loose then it kind of becomes Gable basically people can just trigger the circuit breaker to basically uh Force the next SL validator to go to local building I think like perhaps like there I mean I I know Alice St has been

talking about like implementing more relayer specific circuit breaker say that today if you see a Mis block from a certain relayer and then there's some proof and then you basically disconnect with a relayer but there's a lot of work um to to to be done there

Danny Ryan: yeah I agree that if like if you go more fine grain than the circuit breakers are now they have to be Rel specific um which there are probably there are certainly like proofs and messages that can be passed around there are probably actually like heuristics that could be calculated locally without passing around um additional information but those aren't going to

cat

Tim Beiko: I guess this is maybe a naive

question but um why not make it Epoch based rather than consecutive like we know in practice I understand why at the merge we want wanted it consecutive uh but I think now given what we know about like the makeup of the validator set and and um and you know the different Builders um like like uh could we do something like find the 95th percentile amount of Miss slots in an Epoch and you know trigger it there

Danny Ryan: um it becomes such an attack Vector right like if I uh turn off you I turn off that boost for everyone then you know I can keep my

Boost on and get way more profitable blocks um so like any anything in that direction becomes like very attackable um and even even the like the consecutive ones that we have right now like five consecutive like that could be just like outwardly bought by a malicious relay and turned off for everyone so I just I think that if we got go any more fine-tuned it just it probably has to be like actor specific

Tim Beiko: got it my take anyone else have thoughts on this

Peter Davies: do we agree that this is serious enough that like something should have

happened because like as far as I can tell like actual users of the network like weren't significantly affected so are we happy to say that like this is bad but it's not so bad that like emergency shut off fou should be kicking in

Danny Ryan: I kind of went in that direction honestly um barring independent actor shut offs

oh pus

Potuz: yeah besides my obvious comment about BBS I wanted to mention two different things about this incident uh one of them

is that most probably the fact that there's lack of client diversity within relays have made this happen second is that uh Terren has been talking about these blobs for over a week and no one paid attention to this and once it exploded it only took a couple of phone calls to get to the right relays to actually look at their logs uh this I think is unacceptable and yeah those are I guess my main two complaints about this that Terence has been talking about this and calling everyone and we even talked about this in ACD and really didn't pay attention to the fact that they were losing those

blocks uh if we could look at those logs or if those logs were made probably public we could do that work

Tim Beiko: got it thanks um there's a comment by Alex I get two comments in the chat one by Alex saying you know we should wait for the Post morum um that before making any decisions on a solution um that's reasonable and then there's also a comment by Anar around uh the way 1559 works right now makes this worse because 1559 is base fee b or sorry is block based rather than uh slot or time based

um so it sort of doesn't know about the miss slots um so like this is also something that we we've considered this in the past um but that we should potentially um consider in the future is you know if we switch 1559 to time based then it can um it can take Miss slots into account a bit better um okay and some comments that we should have probably had like a more formal uh written uh warning about the somewhere where's the best place to just follow this Con conversation um I know Alex it seems like uh you were working

on like relay specific um uh circuit breakers um you know if people want to follow this better where should they go

yeah um the MEO Community call would be one option um I think many of us here will push blo rout and others for postmortem which will share in like the usual channels um yeah

okay anything else on this uh Anar

Ansgar Dietrichs: as well but I was just curious why the default behavior is not for Builders

to release blobs once they see their block kind of signed on the peer to-peer because at that point Alex said unbounding concerns but at that point basically the content of the block is already leaked so even if you have worries that you might be too late anyway with even with releasing the blocks at that point for the block to be accepted at least you have a shot whereas and and the contents of the blocks themselves are not the sensitive part so so I'm curious why why that's not default kind of fallback Behavior

Alex Stokes: the builders could do this especially if they've seen the block signed but I'm not sure clients are written a way that support this like out of the box

the

Danny Ryan: the contents of the blobs also could be

sensitive

Alex Stokes: that's an assumption right they could have but if the block if the block signed then like the exchanges happened so it's fine after that

Danny Ryan: oh yeah no I know but from like an unbundling perspective

Tim Beiko: sure okay um yeah because we are kind of packed agenda wise I think uh we can probably leave it at that uh have the conversation on a MBO Community call and then um if people who attend that can just share any sort of postmortem post postmortem or things that come out of uh of it with the rest of awfs that would be great that would be great uh I read

the time based 1559 at the same time um but okay let's move on

uh next up uh we had uh the R's team has been looking into State growth and put out a really good article going um going into the details um we've wanted to cover this for one or two calls uh but didn't have the time so I wanted to make sure we got to it today um I don't know georgos or storm either of you yep storm is on the call um storm feel free to take the stage or screen

Storm Slivkoff: hi there uh let me share the screen and store M worth in

train uh okay am I is my screen visible slides

yes

Tim Beiko: yes

Storm Slivkoff: great uh so hi everyone I'm storm uh I'm a data scientist and data engineer at Paradigm and so I work a lot with the ref team and something that we think about all the time is how do we use data to navigate different design trade-offs so whether we're trying to decide the optimal value for some parameter or we're trying to decide between different architectures uh data often plays a huge role in those decisions uh so today I want to share some data relevant to ethereum scaling road map and specifically on state

growth and history growth and we think this data could be pretty helpful for figuring out if or how ethereum should scale Beyond its current level so ethereum is a really complex system has many different bottlenecks on how much it can scale this is a rough sketch of how we've been thinking about the problem so starting at the top we have the gas limit that's the ultimate governor of things like block size and Ops per block Downstream of those things we have our familiar bottlenecks like history growth and state growth and each of these bottlenecks has its own relationship to the nodes Hardware constraints so each box here is a pretty

deep Rabbit Hole um and today I'm just going to touch on a subset of it so starting with State growth uh a couple weeks ago georgeos and I put out this research blog post walking through some State growth data um so today I'll touch on those results and then after that I'll go through some of the results for our next blog post which is on his growth so this right here is a highle view of how all state on ethereum is currently being used uh the total State size is around 245 gabt on dis for bre at least and the size of each rectangle here represents the portion of those

bytes occupied by different contracts or contract categories so for example uh ER c20s are the biggest category and they take up around 6 67 of the 245 GB and this isn't probably too big of a surprise but um the biggest contributors to state are tokens uh erc20 is and ERC 721s this is because every user balance of every token typically requires its own storage slot and there's a lot you can learn about ethereum just by staring at this graph um if you want to play around with it uh this is an interactive visualization in the blog post and you

can sort of just click around and find your favorite protocols in there uh but to keep it brief I'm just going to move through these charts pretty quickly uh if you'd like more detail feel free to reach out to me or georgos so that was a chart of the state distribution this is a chart of the state growth over time and showing the relative contributions from each category so here every vertical bar represents one month since ethereum's Genesis and the y axis is the number of gigabytes that the state grew during that month so you can see that state growth

peaked around 6 Gigabytes a month at the end of 2022 and now it's currently around uh 2.5 gigabytes a month uh which is actually the lowest it's been since 2021 you can see that the main reason that state growth is down um is the decline of nft usage shown in blue here and state growth from erc20 has actually been increasing um every year for the past few years and that's shown in green so if we take the integral of State growth uh we can see the toal State size over time uh starting at Zero from Genesis and going all up all the

way up to the 245 gabyt that were at today um and state hasn't been growing exactly linearly but it's kind of more linear than you might expect uh even going back uh like four or five years so from this uh we can make a rough projection of how big the state might get in the future and there there's a lot of assumptions you have to make in order to do this but under a very simple model uh we find that existing consumer Hardware can sustain current rates of State growth for a very long time uh probably decades and note that I'm only talking about storage capacity and memory

capacity here uh this isn't saying anything about the reads or the rights to State um under under this framing I'm considering reads and rights to be part of State access rather than State growth this is also not saying anything about what would happen if the gas limit were to change so State growth we often think about as a pretty big bottleneck on ethereum scaling but from these numbers I'm actually not super worried about State growth in the short term or the medium term um however the thing that makes me very uncomfortable is history growth and I think history growth is kind of a silent killer that hasn't gotten as much

attention but even after 4 4844 I think it's going to be a major problem and so maybe my hottest take of the day is that EIP 4444 history expiry should be given very high priority for inclusion in the next hard fork and maybe even sooner than that if it's possible and we should also be looking at uh other eips that reduce history growth like 7623 pretty closely so diving into some data uh this is a graph of ethereum's History growth rate over time and like the last graph the y- axis here is showing the number of gigabytes that history grows during each

month for each contract category so a few things pop out here um one is that the history growth rate is much larger than the state growth rate by almost an order of magnitude another is that the main driver of History growth is Bridges which here includes um like l2s and rollups and then finally until the last month or two history growth the history growth rate has been like rapidly accelerating for many years now and note that since this is the rate of growth um if the rate of growth is increasing then the total amount of

History can increase very rapidly so if we take the same graph and normalize it to 100% we can see the relative contribution from each uh category something pretty interesting here is that there's been kind of four distinct epochs of how ethereum has been used over the years so in the beginning uh first couple years very little is happening on chain um almost nothing relatively speaking um and of what is happening it's pretty hard to identify a lot of these early contracts it's kind of like

archaeology but then around 2018 2019 we see the rise of ERC 20s around 2021 2022 we see dex's and D5 become the dominant use case and then in 2023 Bridges become the largest use case so this is this is a good illustration of how things have become more and more complex over time so one of the big questions you might be thinking is how do blobs affect history growth and if rollups are the biggest contributor to history growth will 4844 dramatically reduce history of growth so this is the same chart as

before except now we're zooming in so that each vertical bar represents one day instead of one month and you can see that after Denon history growth from Bridges has fallen by about 50% and overall history growth has fallen by about one3 so history growth is still quite large but um it's it's also a pretty rapidly evolving situation um you know everyone saw all the craziness that happened yesterday with blobs so it's it's something to keep an eye on before we get a sense of how The Blob Dynamics will play out in the long term so I'll wrap it up with a

comparison of State growth and history growth um and how they compete for node resources so as I mentioned before uh history growth is a much larger storage burden than State and the problem is not just that history is Big it's also growing really quickly even after Denon So within just a couple gear the storage burden for a full node is on track to surpass 2 terabytes and this is mostly due to history growth uh but there's there's a direct fix for this which is EIP 4444 um history expiry so um this current graph shows where we're going right now and

then here um I'm adding in projections of how 4444 affects the storage burden um so the main difference with 4444 is that nodes would only store a Year's worth of History so at steady state the history storage burden transforms from the red line into the pink line and then the total storage burden changes from the black line into the Gray Line and you can see that this makes a massive difference to the storage burden um and makes things more sustainable for the next few years and Beyond this like I said uh we should also look pretty closely at EIP

7623 to reduce the the history growth rate and Tony has done a lot of good analysis on this and you should check it out if you haven't seen it so This research is still a work in progress um we're still in the middle of analyzing other scaling bottlenecks and trying to tie it all together with the gas limit we also want to analyze the in of l2s with the same methodology and see how they might be different to main net so that's all I have for today um again one of the main goals here is to leverage data to help improve um the design of ethereum and the node clients

so if there's any variation or followup to this data that you think would be helpful please reach out uh we'd be interested in possibly collaborating we're going to publish a few more blog posts on this topic and we're also open sourcing everything uh that I showed today so thanks for your attention and thanks to all the people on this call that have already given us a lot of uh useful feedback

Tim Beiko: thanks thank you uh excellent work um and yeah thanks for sharing the sneak peeks on the history side as well we had a question from Andrew who has his hand up

Andrew Ashikhmin: um yeah thank you storm for the great presentation um and I know that you

haven't gone into the state access yet but I i' just like to comment that uh one problem that I see with the uh with the state size is not only the storage requirements but also that the bigger the state the slower the access to it because it all boils down to something like a B+ three and uh the the complexity there is logarithmic right so you will you will like if you have a huge State then each exess will be slower yeah that's the only thing I'd like to note

Storm Slivkoff: yeah uh completely agree um we're still figuring out the best way to sort

of uh measure and Benchmark that but um it's definitely something we're thinking about

Tim Beiko: thanks any other questions comments okay um oh

Lucas

Łukasz Rozmej: yeah so one comment from me I totally agree with the uh conclusions uh that EAP 4444 and uh the C data cost increase should be prioritized and thank you for a great analysis

thanks great thanks

Tim Beiko: what would be the the transition stage

exactly

Ahmad Bitar: so given that clients can drop blocks that are um earlier than certain points uh let's say uh merge or deposit contract or something like that um if we agree on a certain point that all clients can drop before some clients can uh drop these uh blocks and some other nodes could opt into keeping them uh for whatever reason and they can also opt in to keep serving them on the P2P network if they want to uh but this will make the P2P Network some nodes have all the blocks uh and some nodes will have will

be able to serve part of the blocks and there's an EIP that I proposed earlier that will solve also this issue of finding uh the peers that will be able to serve you the blocks that you need

Tim Beiko: right I think yeah that that definitely seems reasonable as like a path to full removal I think if if if we were to do that I would I would almost call that like deprecated you know like kind of like we did with self-destruct where we in the fork before we flagged that you know it was going to go away so you could have something similar here where you say you know as of this point serving say pre merge block data is optional and you know some clients might

choose to do it but uh you should assume it's deprecated and then you know as as of a fork after that or whatever then it becomes um um yeah it becomes kind of Gone by default but there seems to be some push back about this in the chat and Danny you have your hand up

Danny Ryan: yeah I just want this this Point's brought up been brought up many times without doing that and having an alternative distribution method that new freshly clients syncing can utilize like I don't know torrent portal whatever um there's just a concern that the quality of service to syn a new node could significantly degrade um during that transitionary period um I think if one

or two of these distribution methods are well specified and have high quality service then you could have a a decreation period um but without that then you're just putting the kind of the syncing of new nodes in a very t place during that period

Tim Beiko: okay and oh Amad uh did you have another comment

or still your

Ahmad Bitar: yeah I would I would just like answer Danny and some of the comments so like my idea here is not to keep this forever uh that we can have this only as a transitionary uh

uh period till uh till like we have a solidified uh archival solution uh another thing is that uh the the rate that nodes will start dropping historical data is not as high as we think it will be uh ex uh existing nodes will not suddenly after the fork decide okay I want to prune all of this history away uh right now and uh data will become unavailable uh on in a single day I think most of the nodes will um opt into keeping the current configuration keeping the history until they actually need to start pruning uh because their drive for example does not fit any more

data

and I

Danny Ryan: I might agree with some of those assumptions I just doing that transitionary period and having an unknown time Horizon I think is is potentially dangerous if there if it's stepwise and there the assumptions are stated and the time frame is known then I think it could make sense

yeah

Lightclient: I kind of feel like we have a path forward and it seems a little weird to me to try and take a different path as an intermediary step when we kind of know what we want the long-term future to look like it's just a matter of rolling out supporting era figuring the last things that need to be figured out about how this supports the era format post merge and then rolling those types

of things out

Tim Beiko: right then given we have the error format for pre merge block I think last time we discussed this the rough plan was to try and set up some out of network retrieval scheme um whether it's Torrance or or portal or something like that and then um start have clients start using that sometime this year um and then um and then stop you know start suring like pre-merge blocks um start serving pre merge blocks on that Network this year and potentially stop serving them sometime next year on the peerto peer Network um I guess yeah yeah sorry go ahead

yeah

Lightclient: I just say that's that's kind of how I think that we should proceed

Tim Beiko: what's the best way for people to follow this like um is it in the Discord

this the Discord Channel History

expor

Ahmad Bitar: is it called State expiry or history expiry

his yeah

Lightclient: history expiry and execution R&D

Tim Beiko: okay um I think we could probably continue the conversation around history expiry there um any other final questions on just the overall presentation before we move on

okay well yeah thanks again uh storm

and George for putting this together um yeah this is really good okay hopefully we can get through these next couple things quickly so uh these two retroactive eips uh first one was um 7610 uh we discussed this a few calls ago um and there were some questions around whether this would be uh compatible with veral or not um I don't know if anyone's looked in into that or what the current status on this one is

um yeah I think um it is compatible with vericle uh because uh we have this consideration that um if we switch to

vericle uh is there any easy way we can determine if the account has empty storage or not uh so in order to solve it uh so according to the current bre spe because there is no notion of storage route anymore so it might be a problem but in order to solve it we can we can choose to discard the useless storage during the B transation uh specifically if an account has zero NS and zero runtime code then the storage can be discard and it is totally fine as because the WR time code is zero so this storage are not accessible and uh we have 28 accounts in total eligible for

it on the ex main at so uh by doing this um like we can no account will be eligible for tracking this special scenario that uh the destination of the deployment has n n storage and um yeah and also after the transactions the E can be disabled automatically because in veral the storage route returned is always empty so this additional condition is basically useless and the client team can choose to remove it or it's also fine to keep it so yeah I don't think it's a blocker for

veral yeah g

Guillaume Ballet: uh yeah so basically everything that uh that Gary said is is correct uh I mean it does that the CIP effectively Auto dis itself was with verle I remember a couple weeks ago uh someone was asking how would 5806 uh affect this and I remember discussing it with Adrian I think he's here uh but the our conclusion although I don't remember the details so I hope he's here but our conclusion was that it would not happen because uh because you can't really create accounts uh uh like

you don't have storage uh you cannot write storage when

uh edge cases of transa of accounts that

could exist um because um they're very old um in particular like most of these problems have gone away because anything that was created after spear Dragon was deployed um the NDS got bumped to one if it was a contract created and I think that what I'm hearing is there's a reasonable case for taking the opportunity of the vericle transition to remove these edge cases by um bumping the nons on accounts that have storage and um deleting storage for um contracts with no code no Nots

um yeah so uh I would choose to

remove the storage uh because they are useless and very safe to delete

Peter Davies: I think it's also worth like pointing out but like um like this Edge case only exists um in the case of a ludicrously implausible intentional attack on ethereum so it's entirely you know we don't necessarily need to H we should be designing our semantics here based on what's easy for CES to implement that's reasonable rather than um what like makes the most sense for people doing it intentionally because someone's probably attacking ethereum if this ever happens so I for for example if we delete the

storage um during the verical transition it's possible that someone has the ability to deploy code at that address because they found a hash Collision um and what happens will depend on whether they do that deployment before or after the vericle transition normally I would be against any such Behavior but given that I don't think this is likely to happen at all and yeah I don't think it's a thing we should be worried about we should just be like what's the easiest least complex thing we can do the results in all clients having the same behavior

Tim Beiko: so I guess uh one thing to to

clarify is is the veral complexity like part effectively would would be part of the veral eips or is this something we need to consider in the case of 7610 um my understanding is this is something we would include as part of veral to deal with this like to sort of deal with the consequences of this but just is that correct

um I think it can be applied right now and uh whenever we switch to verle we need to think about how to

uh yeah

Tim Beiko: okay um I guess in this case does it seems like all this like potential

concerns have been addressed and like even though we might need to figure out the right uh you know the the right interaction with the vergal transition there should be a way to do it and it's just a matter of how rather than if does anyone like oppose just retroactively applying the CP from Genesis okay no objections um and then we had an other similar EIP uh so s uh sorry what's the number 7523 um this is Peter's the IP which uh basically cleared some empty accounts that were missed in the spirous dragon

hard Fork uh did this before the merge and so the EIP makes the assumption that there are no empty accounts uh on any post merge Network or network which uh applies um this uh or or or sorry or would applies uh spirus dragon at Genesis um and I believe we've had two people verify that Peter's uh script was correct um yeah Peter do you want to add more context

Peter Davies: um yes so this is the E that says that there are no um empty accounts after the merge and that the Pres that um we no longer Define what behavior is in the presence of empty accounts and

that everyone should just when operating in a Pur merged context should just proceed on the assumption that empty accounts simply can't exist and in particular this allows the deleting of a large number of test cases um it allows some types of special case code to be removed um there are edge cases that have never occurred which now can never occur it's just useful for everyone uh yes at this point um me and um Marius vand have both um manually checked that there are nod accounts um in the current head or at any point after the merge um M I think we can just proceed with this um you could always do more checking

I've not seen any demand for more checking um and I think that people generally think that me and Marius are both reasonable and diligent people who will have checked thoroughly does anyone have like any objections at this point

Łukasz Rozmej: uh yeah luas so there is a question of uh is that true for other chains that are evm compatible right because if we unrine this as a evm thing and they are incompatible with that if they have any edge cases that occurred then that might be a problem for them

uh yes this is a good point so um the thing you've got to bear in mind here is that in order to have an empty account your chain must be

extremely old um the creation of empty accounts was abolished at the end of 2017 and effectively every VM compatible chain is more recent um in particular any sort of rollup is like the concept of rollups is just way more recent um I have checked quite carefully and I am confident that the chains that can have empty accounts on them are ethereum where they have been manually cleaned um robon which is now dep deprecated um ethereum classic um ethereum classic I manually cleaned all the empty accounts I haven't done any sorts of checking but I did

that correctly on ethereum classic but I did like go through and try and delete them all um and also there are some extremely old ethereum classic test Nets but could have empty accounts on them um my position is given that we've cleaned things off Etc um I I don't think we should block stuff on a ethereum because it might break something on an ethereum classic test net and I'm confident that every yes I and I'm confident that like every other context is applies the other significance of course is that Etc doesn't have the merge um and this specification says that after the merge there are nod accounts so technically

it's a valid um it's valid on on etherum classic and as everyone is saying in the chat like we're not respons for E classic so it's not like we're throwing people under the bus like we have to think about it etherum classic has to think about it and everyone else just has to observe that they launched their chain after the end of 2017 um and adopted there's a question in the chat about

Peter Davies: chains without EIP 158 um um chains with oh so chains without EIP I would have to look into that I'm not aware um

like my kind of opinion is that um yeah i' I'd have no like EIP 158 is the same era so if you have EIP 158 at launch you didn't you probably didn't have any um thing out any empty accounts um I will I will make a note to look into this but someone would have to tell me what these chains are uh yeah someone mentions maybe

nosis um yeah my sense is I think you know we've talked about this for over a year at this point uh if someone wants to pay nosis about it they can also run the same script we've run on their chain and and clear stuff um I do think we should just move forward with it and and um yeah like I I

think the the EIP makes it clear like what are the conditions under which it should be activated um and um yeah it is like a nice clarification for ethereum so I don't know any objections on moving this forward and by moving forward it's like considering it retroactively applied from Genesis okay and I guess tively applied from the mer oh sorry corre before yeah yeah yeah sorry um yes

Tim Beiko: and I guess on this point um I've been thinking so I think this is like our fourth retroactively applied EIP uh if if I'm not mistaken and they're not really documented anywhere um so I think I'll probably put together a meta EIP

that uh tries to list those so that when we do make these changes um that you know people should consider and and that have been like decided after uh a specific hard Fork um they're at least documented somewhere so um I'll put together a draft uh with uh all the with the two IPS we we we discussed today and then all the ones we've did in the past um and I'll shout it out on all cordev in the next uh week or so um anything else on the

meta eips or sorry the retroactive eips okay um so we have about 40 minutes left um there's two quick updates that

we have to do uh that we quickly should cover on extra included or considered stuff and then a bunch of updates on uh potential eips so um we'll do the two included things uh so far or the included in the CFI thing um for everyone else who has updates on like the long list of stuff uh consider that you'll have probably one or two minutes to give an update on the most relevant new things um and then we'll keep the end of the call to sort of discuss what should go in um and how we scope the first stets um but first uh Marius you did some analysis on uh the BLS gas costs is me

here

Guillaume Ballet: um okay uh he might be on holiday actually

oh

Tim Beiko: okay so if meis is not here anyone else have comments on the BLS gas cost otherwise I just posted the link um we can continue the discussion I think if there's no comments or questions

uh yeah I think go ahead

Dan Cline: um yeah I was just going to say that we uh are going to do some benchmarking uh for the libraries that we'll be using in ref which are going to be different than the ones that Mar's posted in The Benchmark um so uh yeah we'll post these in the Discord when we have them

Tim Beiko: got it thanks uh Alex you're gonna say

something

Alex Stokes: yeah oh first off just plus one to benm Mark another libraries that'd be really helpful um um yeah so Marius did some benchmarking with his software stack um I think the documents pretty self-descriptive there's kind of an open question around subgroup checks which is like this cryptography detail of the promiles um and yeah just the update there is that works underway and yeah it's moving along

Tim Beiko: got it any other questions or comments on that

Danny Ryan: and the sub group check was the

really expensive part and by work on to decide if it must to be in there

Alex Stokes: right so the way the EIP is written right now there's subgroup checks that are essentially required for the pairing precompile they are effectively like suggested or recommended for the others but they are very expensive uh so I know Antonio is looking at benchmarking them for these other expensive calls and then it kind it becomes a question of do we want to mandate them meaning higher cost for users or can we skip them and then you know it'd be cheaper to use but then you'd have to be more careful as a user to not you know shoot yourself in the

foot so to speak um there might be a new version of these H group checks that are the best of both worlds where they're cheap enough and then also secure so uh yeah that works

on

Tim Beiko: thanks

Dan Cline: um yeah one comment on subgroup checks uh given that there's like multiple libraries uh that Implement these operations uh we would have to I mean the benchmarks for each of them will guide this uh agree but um like if there's a newer faster one it's only implemented in one library then I'm not sure we can

recommend uh like decreasing the cost for example um but I guess that should obvious

Alex Stokes: yeah I mean the idea would be that every implementation would use the new thing

Dan Cline: yeah yeah

Danny Ryan: I mean if they're off an order of magnitude that's OB place to look into

Tim Beiko: okay uh so we can keep discussing this uh think um yeah and last question maybe we can just answer in the chat but someone's asking if there's any links or information they can to understand why uh we need the subgroup checks um so

yeah someone has self tiet s seems like Dan has so thanks

um next up uh so we have uh CFI uh the inclusion list CIP on the last uh CL call I believe and um there were some concerns there that were raised around how it would interact with account abstraction and I believe Mike has an update on those concerns

yeah hey Tim hey everyone thanks I'll try and be pretty brief here um I have one diagram to share to kind of help visualize this and I'll start by saying also um Poes has this doc I'll I'll paste it in the chat that also

covers this um this issue really well so for more context I'd point the interested reader there um hopefully you can see my screen so I'll just give like a really high level view of this issue and then talk talk through these three options at the end which are three things that I think we can do to resolve it um so the context here is that we're the slot n plus proposer and we're deciding um you know where to where to build our block as the or which block to use as the parent um and this is our our current view so we saw the slot n block and we saw um we basically like the the proposal for 7547 is that the inclusion list is composed

of two different like objects the first object is the summary the second is the list of transactions um the point for doing like a summary instead of the full transaction list and contrib and um committing to just the summary is to solve this free da problem um which we talk about here I'll send this link to just so everyone has it it um right so we saw the slot end block and we saw the slot end summary but we didn't actually see the slot n transaction list that corresponded to the summary um and the way that could happen is if we saw the slot n plus1 block which included the slot n summary um and we confirmed that thei by the slot n plus one transactions so this is kind of like part of the

inclusion list mechanism is we ensure that the summary is included in the block that the summary entries are satisfied um but remember we didn't see the actual slot and transaction list that corresponded to the slot and summary so now we're work kind of here and it's it's my time to propose a block it's slot n plus two and my Fork Choice says that slot n is actually the head of the chain so now I'm building on slot n for whatever reason let's just say slot n plus one didn't get enough um out of stations for me to consider at the head and in order for my block that proposed to be valid I need to include the slot in summary in my slot in plus two block um and I need to satisfy the entries in the slot and summary but I

can't be guaranteed that the that I have access to all the slot and transactions that were in the slot and inclusion list because I didn't see this object on the network so this is the kind of weird situation where if um if we don't resolve this then the slot n plus2 proposer can't actually produce a valid block that is the that that is the child of slot n they would have to build on slot n plus one so yeah I guess the there's a few issues here um one thing we can do and I guess so this is kind of we we haven't even touched the the issues around 3074 yet and so I'll talk about the three options and then I'll

describe where 3074 fits in here um right so one option is to reorg this slot and block too say okay we didn't see a transaction list for the slot and summary so we're going to reorg that block that doesn't seem great um we could not accept the slot end block as a potential um head of the chain in the fork Choice view which is how we treat um 4844 blocks um so 4844 blocks we don't accept them into the force Choice Fork Choice view unless we've seen the blobs and then the third option is to reconstruct um the slot and transaction list from this slot n plus1 block um and this is actually where the 3074 um issues come in so the reason 3074 causes

an issue is because without 3074 we know that the slot and summary transactions um are either in the slot n block itself or they're in the slot n plus1 block um with 3074 instead of the transaction from an account being included there's a chance that that account had balance drained by an external um by an external account and so in that case the the satisfaction of the summary entry um I apologize this is like complicated but yeah whatever I'm getting close don't worry um that that account could have been drained by a different account and so in that case reconstructing the um slot and

transaction inclusion list is not possible from just the slot end transactions and the slot end block so this is the kind of issue um yeah those are the three options and yeah I guess there's there's one thing that can make 3074 work with um with reconstruction which is if the um if we can check not only that a transaction from the account has been included but if we can pull out the 3074 transaction that invalidated the transaction that was originally in the in the inclusion list then that works too um and yeah so basically I think

there is a way we can do reconstruction with 3074 but as mari's pointed out this becomes a slightly more complicated um proposition so yeah I guess the the last thing I want to say is that um you know this does feel like it kind of creates some complications around the inclusion list design but I do think there's three options that that actually do work and I also don't think that there's going to be like a silver bullet to fix this because this is like fundamentally an issue about how transaction inclusion works and how like inclusion lless are are designed so like I don't think waiting um yeah I I don't think like we're going to find a better design that that doesn't be faced that doesn't um have

these same issues that has to that it has to resolve um and we can make it work with 3074 specifically which is a nice compromise um the enshrine 437 Things become a little more complicated um but yeah since we don't know we're going to go for in shrin 4337 I think those realities can be worked out in in a future scenario so yeah I think we can still do um 7547 in Electra for for those realities and um because we do have three options to consider I think it'll probably be the type of thing where it's worth writing up a short dock explaining the details here but yeah that's that's kind of where I see the 3074 Plus 7457 um relationship so yeah sorry that was a little longer than I

expected um wanted to quickly shout out the people in the channel who've been working on this gender Matt Marius pan Terren ongar Daniel and Sean um lots of lots of attention on this in the past few days so hopefully we can get it resolved quickly happy to take questions online or off

let's do one question by Danny and then move on

Danny Ryan: on the diagram um if we have just to help my understanding say the slot n plus one block does not exist I'm the slot n plus2 proposer I see I see everything that I see except for that n plus1 so I I can't do reconstruction rate so I I don't even really can can I even build on in at point

right at this point um you wouldn't consider slot and valid this

block valid because it's um the leaf chain so it's like or it's the leaf block so it it's a candidate for the head of the chain but it doesn't have a full summary accompanying with it so part of the part of the check would be if it's a leaf block it has to have a valid I if it's not a leaf block then you can maybe do this reconstruction thing

Danny Ryan: um but it's like why why does this case matter right

this case matters because there is a situation where this block was the head and then it got reorg so it's only it's only mattering in the reor case so it's a bit of an edge

yeah yeah but I

Danny Ryan: I'm just I'm like

in the event that n plus two didn't see interesting because

Potuz: without notable

what was that PO sorry you can

Potuz: you can make an attack in which you make you build a block that is not

reable yeah basically like if

if slot n plus1 gets built and is not reorderable then that's a problem

Potuz: so so you s you send the IL to everyone you send the I to no one but you collude with the next slot Builder and then you guarantee that the next slot can just come and it's never going to be

reared okay I

Tim Beiko: I'm sorry but we are uh pressed on time so yeah um but yeah thanks Mike for sharing the update um and yeah we can then she discuss this in another breakout room um so okay so I'll move us to the big list um I guess yeah try to keep it to about one minute and I think I think all the eips here except one have been presented before so like assume that everyone on the call has context and try to focus on like what is new and or special about at EIP and why it's relevant uh Charles you had uh two of them uh that uh we didn't get two last calls so 5920 uh payop code and

then uh 7609 decreasing the cost of t- load and

t- store

Charles Cooper: um uh hi I'm Charles I work on viper um I want to present two um kind of ux related eips um the first is pay um I brought it up on a few calls before but basically it allows you to send ether without transferring execution context um people have pointed out that you can use self-destruct for this but we are trying to deprecate self-destruct so I don't think we should depend on like the particular semantics of how

self-destruct works right now um I think it's a super important EIP because uh right now in order to send ether you need to transfer calling context and this has related resulted in a lot of bugs before um for instance um um actually one of the reasons that the whole call um gas schedule is so complicated right now is because of these artifacts um from you know when when send had a 2300 gas s in hardcode or something and if we had had pay that just would have never

happened from the beginning um so it prevents a whole class of re and um other kinds of bugs related to calling condex and um in previous calls uh the main uh as far as I know agreed that it should get into the evm but the main objection is that the testing complexity is somewhat High um that's the summary and then for EIP 7609 um this is a proposed to make the pricing of trans and storage cheaper and slightly more complicated uh excuse me

second

Tim Beiko: I guess any question comments on pay

uh uh yeah so on pay um that got some special attention uh a couple of weeks ago from the testing team and the eels team we used as our prototype e IP uh for testing the EIP process and we actually have a bunch of tests and stuff written for it already so we can uh help a lot with that

Tim Beiko: got it

um so if there's no

Charles Cooper: if that resolves the the testing objection then I would

really like it to be considered um for CFI well and then um yeah just cly

Tim Beiko: we can do the CFI discussion and inclusion at the end for everything

um yeah

Charles Cooper: just oh okay um and then the other one is transing storage pricing um I think that honestly transing storage was mispriced to begin with um basically it should be cheaper than uh warm storage for a lot of reasons um it doesn't interact with the database ever uh it doesn't interact with refunds uh the basically the rules around it around the implementation much simpler um there's some other weird things like in the current gas schedule you can allocate a

lot more transient storage then you can allocate warm storage slots so this CIP fixes that um and um one thing I changed is the the I added a little more analysis around um how much you can allocate so there's one parameter coefficient uh in thep which is currently set to one and basically uh the the amount you can allocate grows sublinearly with respect to the gas limit in a single transaction uh it grows up roughly the square root of the gas limit and um there are it makes it cheaper in most use cases that you want and it adds

better bounds for um how much Transit stor you can allocate and I think uh that's the quick run down I'm happy to answer any questions

Tim Beiko: okay uh if there's no questions then uh let's move on thanks Charles for the uh for the updates uh next up Gom you had two veral uh related eips or at least veral adjacent eips so one about uh historical Block hashes in the state and then uh the veral uh proof pre-compile do you want to give some quick cont text on those

Guillaume Ballet: yeah U so I have a very quick

presentation don't worry if I share I don't I don't know if you guys can see the slides but it's going to be very very short so uh it's just actually a reminder so we had this uh EIP by toas and vitalik about storing the the state uh in in the contract turns out uh so this CIP was stalled but we discovered while running the veral test net that actually stateless clients need a way to be passed the block has in sorry block hashes uh to be able to to execute the block hash instruction so we created a Revival PR against that that EIP so we're effectively completely hijacking this this EIP um the short uh summary

for uh for the CIP or of of the changes at least is that uh we changed the way the four gets activated it used to be number based but since then we we had the merge so now we do time based uh time based transition uh we uh no longer store the entire history we just store a ring buffer of 256 blocks and uh there was this weird activation period where the fork would have happened but you could not use the the block hash instruction using the the contract just yet uh so we got rid of that we made it simpler we just say at the fork transition we will uh simply copy the last one 156 blocks and that will be it um and why do we want it in prag uh yes

it's required for verle uh but we uh sorry for the typo uh we can we can sort of uh include some uh veral veral EIP this way uh signal that uh that it's that it's happening and uh it's quite simple in fact there's already an implementation running on the veral test net and it's also useful even before veral so there was this proposal for by Peter around the time we were in stul last year where uh what I call light client diversity so instead of striving uh to get every uh every forth person to install a different uh a different client uh we just make sure that uh

whatever is the majority client just also works as a light client to uh to a minority client to make sure there's no catastrophic super majority bug um so that's pretty much it uh yeah why why why we want that now because it could be used even before veral and then due to the complexity of the veral change it's also nice to be able to do some stuff that is uh light before uh before the actual fork and while I'm at it I'm going to talk about 7545 so the main uh the main reason is uh for like the main the rational or the purpose of this of this CIP is to abstract the way smart contracts verify

proof because we're going to switch from MPT to uh to a new three format so that means all the proof uh the proof format will change I realize this is the former version of my slide so I'm sorry if it's a bit cryptic uh but yeah the idea is we want to be able to also handle the trans transition we don't want every smart contract in uh out to to know to have to guess when it's performing the transition so just receiving a blob a blob that is a proof of uh of some state that would be on one L1 or or on an L2 allows for for example I mean typically L2 L2 uh contracts to to not have to

worry about which proof format they have to handle you can you can release one contract at any time you want before the fork uh without having to rush at the last minute to to release the the contract right at the right at the sorry a contra that can handle the new proof system right at the time of the fork and uh yeah once again why in prag um because uh we want to signal that uh because it has to be because Prague is the last Fork before veral so if we want people to uh especially l2s but Bridges and whoever needs to to handle proofs to to be ready for veral and not have to rush once again uh they it would

have to be released in Prague so that uh people have the time to to update their contract and make sure it's veral ready and yeah that's pretty much it

thanks Gom uh vitalic you have your hand up yeah um so first I wanted to just suggest making the size of the buffer um 8192 instead of 256 and the reason for this is basically that like in practice a lot of people don't a lot of applications end up not using the 256 like block hash precompile that has existed since launch and the reason

basically is that it gives a window that's like actually pretty tiny um and uh so 256 time 12 is going to be 3,000 72 seconds so less than an hour um and in general the like we have had outages that are on of the ethereum chain that are longer than an hour and one roughly one week is kind of the standard length of time that's generally accepted as s safe for uh rollups like it's the time that we we've been kind of assuming that uh a user is going to reliably be able to get a transaction included on Chan at least once in that time um and so if we

can increase the length to that higher number um then we'll be able to like applications would actually be able to guarantee that like if something happens on chain then a user will be able to submit something that involves sub submitting a proof of it before the time runs out yeah there's

Tim Beiko: some support for this in the chat um because we're a bit pressed on time I think we can we can move on for this but I think yeah generally it seems like there's support to just match the P perams from uh 4788 which has uh 8, uh 192 okay any questions on the pre-compile EIP otherwise we'll move

on okay uh next up on the list uh Dano you wanted to give a quick update on

EOS sure um let me share I can't I have a new Zoom so I can't share I'll just post this into the chat so

Danno Ferrin: as far as the status of uh um eof uh we're into the point where basically the specs are locked down and we're writing reference tests and implementation I posted a Readiness Matrix that shows the EVMS that are um reporting their status of what they're working on Bas is almost completely done along with evm one there's just some issues with TX create they're going

through some of the final um standards for what a transaction might look like um RM which is the one that re uses is starting implementation and I know there's old implementations for GU and Ne nethermind from the um from the big eof days back in Shanghai um so there's probably they're not fully blank on that but they do need to bring it up to date um so that's uh mostly the the status of the is that people are implementing it and we're getting reference tests written

Tim Beiko: awesome thanks any questions on E okay yeah thanks for sharing the Matrix and there's a comment uh by R that they need to update uh that table

um yeah it is

Dragan Rakita: few weeks old and I need to update on the progress with him

awesome okay uh let's keep moving that um Matt you had two from uh from your end so uh EIP 721 two uh so the R1 pre-compile and then uh 3074

Matt Nelson: um yes that sounds good um thanks everyone yeah so I think um I'll be super super brief in interested time with 7212 uh it seems that with the rips and the kind of adoption on l2s it would make sense to try to include this

pre-compile on L1 as well just so we don't break any compatibility and we can make sure that wallet development stays the same across the two layers uh that's kind of the same thing with 3074 um moving from you know spoke to some of the the mamass team and did some due diligence on the consensus side as the Bas Su team um on 3074 and 71 7212 um so hopefully moving to include those and you know show the support of those uh from this team to those uh so you know I don't think we need to dive into the specifics of 3074 right now but U motioning for support from uh from Basu I'll be yeah that's it I'll be very brief yeah there's some support comments for 7212 in the chat from G and W um

anything else on otherwise on the 3074 Point uh Prolo had the new EIP addressing uh what he believes is a new Edge case um so there's a draft for it EIP 7664 uh Prolo do you want to give some um do you want to get some context on this

for sure thank you for the time so this e is brand new drafted it yesterday it's called e 7664 what this e does is enhancing the utility of access list such that contracts can basically require a user

to statically Define um a certain input to the contract this is functionality we losing with 3074 where previously you were able to basically enforce that the transaction input data matches the contract call call data and so by using access lists we can allow contracts to um require these inputs to be clared in a transaction without coupling it tightly to the account model to the call stack or anything like that and also this just generally like besides that decoration of inputs it it basically fills this original motivation

of the Berlin EIP EIP 29 30 there the original motivation described that hey we can use this for statelessness or for for these static uh analysis type purposes and this this implements exactly that and doesn't add additional resources but fills this Gap that 3074 leaves

thanks any questions comments uh you have oh you muted Your Love

Yoav Weiss: hi yeah um so one

question regarding U yeah can you hear me

Tim Beiko: yes we can now

okay so regarding

Yoav Weiss: uh regarding the latest uh the latest addition to 3074 with a a supporting value that's something that I uh until yesterday I thought it was um I thought it was safe enough because similar attack vectors existed similar service existed before but yesterday's problem with blobs made me uh made me realize that there may be a problem so I wanted to like bring it up see if anyone has any comments so with u uh with blobs we have an eviction protection policy where

uh we don't we don't allow a type two transactions to uh replace by fee uh type three blob but uh if we allow if we allow a 307 for to uh drain H to drain accounts to move E from accounts uh how do we uh how can we fix the uh the policy for blobs so that uh we don't get a lot of a lot of blob evictions as a den of service attack

Tim Beiko: does anyone have an answer to that or thoughts

Lightclient: uh why is it different than the current situation because you could

today have you know in number of blob transactions sitting in TX pools and then work with a builder to build a block with in number of transactions from those accounts that are 21,000 gas transfers just sweeping the account balances out and then all of those blobs become invalid it's a bit more expensive today but I think the fundamental tax still exists yeah yeah that that's what I initially thought but then I uh so I realized that the current policy the the current eviction policy doesn't let you replace by fee on um on a blob so a blob is more expensive to propagate but once it's been propagated you cannot propagate another transaction

from the same

you can

Lightclient: can you definitely can replace but it's much higher I forget the exact number I think you have to maybe double the base fee of the Bob yeah I think it was 2x but but like you still are paying this roughly same amount because I I don't think you have to 2x the priority fee for execution I might be wrong but like you're only 2x in the blob base fee so as long as the base fee stays kind of below you're paying the amount

right so

Yoav Weiss: uh so you're saying there's no uh so there is no concern where uh um so invalidating invalidating a large number of blobes doesn't become doesn't become significantly cheaper uh

with a single transaction with multiple off calls

Lightclient: I think it becomes about three times cheaper because I think it's about 7,000 gas to go through the O process off call process to sweep the account maybe a bit more so you're saying 7,000 per account to sweep versus 21,000

Yoav Weiss: um yeah except that uh with with the with doing it with an EA transaction without 3074 you do need you are paying much more for this 21k because you need replace because uh the protocol knows that you are actually replacing a blob

where uh here uh here the transaction doesn't have to pay any higher fee because it doesn't come from the same EA anymore

Lightclient: the protocol this is only a transaction pool charistic the protocol doesn't care if you receive a block it's not going to enforce that the block that's coming in that that transaction is paying you know enough to

to the

Tim Beiko: okay I think sorry guys I'm talking about a private Builder we're I think we we're GNA need to take this offline uh because we only have three minutes left um yeah but thanks for bringing up the concern you have we can definitely uh yeah keep discussing it um okay so there's two more quick ones to

go over one was uh so so I guess Proto B sorry Prolo on your access keop code the general feeling seems to be that people think it's interesting but need to review uh it a bit more um you wanted to also bring up the ssz EIP

right I'd like to give some Layer Two perspective on the S E so and now this e has been discussed yeah it's just that I think the it's kind of underestimated where 374 other or 3074 the uh the inclusion this e these things rely on transaction typing a lot but then there there's a lot more to say for

ssz outside of this you know the new set of eips specifically specifically for transactions today they're just very difficult to prove and to prove a attributes of this also applies to receipts and so like this proofing this is a big deal for Layer Two both for scale and for security for scale if you think about charting like we can sample data all we like we cannot sample the evm execution the same way we're not there yet so what this means is that all these rollups they're registering their data through the EPM and basically duplicating the registration of this blob data or and

then pulling information from layer one is all going through the EFM well this all could just be like a nonm operation this could just verify through the commitments we already have in the ethereum chain so the state today is basically we're forcing a certain bottleneck through the EFM and we're duplicating data and we are making it very difficult to prove the attributes that exist in the chain today in the the history now we can fix this by just improving the merization improving the representation of this data in the history and then for security

specifically layer twos end up implementing all kinds of workarounds to verify the data today these workarounds are generally less safe less sane really just a lot more complicated than they need to be and so This Ss e fixes this by improving the the layout of the the data improving the merization of the data for all the types and I think this is really important for the the future of of Layer Two to be able to scale and to securely verify layer one data thanks

Tim Beiko: thank um we'll take one comment and then try to wrap up because I know we're already at time

H

Gom

Guillaume Ballet: yeah just to add to that uh uh uh sorry ssz Mer ization uses shat 256 instead of K kak or Kack I never know how to pronounce it and this is also better for

z z

Tim Beiko: thanks um okay we're already at time I think um I was hoping we could have like a bunch of time for client teams to share their preferences today but um we already have stuff included in the fork um do people want to make a case for anything else being included as we work on the first Dev Nets um I think we can

take one minute for that uh reading the chat 3074 seems to be the only one that's been like repeatedly mention there's been a couple mentioned of other things um yeah the people have a strong preference on like making this decision now for some of the things do we prefer to push this back two weeks and give people more time to digest everything that happened today um any strong preference

Matt Nelson: maybe better to get some opinions now so we can start working on any prototypes we' want for the dev Nets

Tim Beiko: okay I think yeah based on like the

chat yeah I I think it's probably better to wait uh two weeks to start uh I mean I don't think client teams have implemented everything that's already included so far so we can definitely start with that um and then block off the first basically block off all of the next ACDC or acde sorry to discuss any additions um and I think yeah in the next two weeks we should dive deeper into all the stuff that's been brought up today um and uh yeah aim to make a decision then um and I think anything the implication is like I think anything that's like not fully figured out or

specified uh two weeks from now is probably not going to make it into this Fork if we want to move forward um does that make sense to people okay thanks everyone I appreciate you all getting through uh all of this today uh this was a big one um yeah so uh again please review everything we've discussed um and we'll we'll block off the the first part at least of the next call for um discussions around what's going in the next

for um yeah thanks every

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.