All Core Devs - Execution #202

Transcript

for [Music] [Applause]

Tim Beiko: thank you welcome everyone to acde

number 202 uh we have a pretty packed agenda today as you've hopefully all seen um and also quick heads up I'll have to jump out at the hour and Alex will take over uh for the last 30 minutes uh assuming we go for more than 60 Minutes uh with the current agenda which I believe we like do will so uh we'll talk about how things are going with Petra implementations ideally get to a spot where we finalize this spec um I've tried to list all of the outstanding issues uh these are ones I could find um if we get through that I think that'll be good and then a bunch of other things to cover so step around four fours um

gas pricing and uh transaction or payal tizes a bunch of other eips and then a few announcements at the end um I guess to kick us off uh do we have Carrie or Barnabas uh to give a quick update on uh death Nets yes

Parithosh Jayanthi: yeah uh so we have um make still live and what people are actively using to test on um that's still based on Petra devet 4 specs and client teams are slowly making Headway into implementing devet 5 specs there's been a consensus specs uh release already and on the interrup channel on the E R&D chat I have linked kosis config for bezu

as well as teu uh they're able to um produce blocks post Spectra with the diamond five specs including over six blobs as the max so in case anyone else is ready and it seems like loar might actually be um we can start expanding that F expanding that file and testing more and more interrupt um I think that's the current status once we have all the open PRS merged I think the testing team will um update tests as well as make a test uh El release and then we should have everything locked in for that

Tim Beiko: thank you um yeah nice to see there's at least a first client pair on the network any other client team or anyone have

other thoughts comments about makeer devet 5

Felix Lange: um yeah big quick question which branch are you going to be using for

GU

Parithosh Jayanthi: uh for now we're using light Lance Branch but if you tell me which branch to use I can change that it's we do not

have

Felix Lange: so we have every I think we have basically everything for five on the master Branch except for the 7702 transaction pool so basically you cannot submit 7702 transactions through gu right now on the master Branch it would still be interesting to run it though like if you guys could like run it like just you know like or maybe I can just try myself but basically if you want to

I have no idea also like how up to date M branch is but I guess yeah we can figure that out yeah no

Parithosh Jayanthi: worries I can try it out and let you know what happens

Tim Beiko: okay anything else on test Nets okay then uh let's move into the spec uh discussions uh so first one I have uh is uh this replacement for 7742 we agreed to remove 7742 on last week's call um and then on the Discord

discussed instead passing some configurations in Genesis by client has ANP for it which um it seems like most teams were in support of um but because it was introduced last week we uh wanted to wait and see if there were any objections um I guess yeah anyone have concerns about the CIP or um yeah an objection to moving forward with it as the way to pass the blob configurations okay if not then I guess we should get this merge and add this to

the Petra specification um and this will be the way that we include uh or that we pass the blobs uh to the eel any other questions comments and I guess maybe one thing there is do we want to have this um I guess we we put this towards devet 6 h not devet 5 correct given that we already have some clients launched for deit 5 okay I'll take the silence as a yes um great so okay I'll add um I'll add the

EIP to the Petra spec uh after the call if possible it'd be nice to get this actually merged um as I don't seem it doesn't seem like there's any issues uh with the pr as it stands and uh yeah we can get this out of to

De six

Tim Beiko: um okay next up uh 7702 so there was a proposal by um Proto to make uh the chain ID uh U 256 um this came up on E magicians I kind open the pr and then there was a separate proposal uh by Felix to just remove the chain ID altogether

um I don't know if anyone has an update or context on this and uh strong preface preferences um it seems like re has some objection uh to this

as was

Justin Florentine: leaning towards Proto's suggestions but it sounds like he may had a change of heart looking at the chat love yeah go ahead

P

Protolambda: yes I think the solution by Felix is more elegant where I was mostly looking to preserve some functionality um with the Gen size but Felix has a suggestion to to remove it

all together and so then you rely on the Chain ID in the outer transaction and that chain ID has the right size so then there's no problem

Felix Lange: yeah so I mean maybe some context about my proposal so it seems there was also maybe a bit of a misunderstanding about it so um yeah it's um I just literally raised this proposal because I thought it's B silly to you know have such large chain idies repeated uh over the course of like many authorizations when they're literally all going to be the same value or zero so that's basically where my proposal comes from but I don't I mean ultimately we do need these um large we do need support for like

large chain IDs anyways so that's the thing there isn't really any way around that anyone here from RE to actually yeah I think

Tim Beiko: Roman

yeah

yes uh so the the push back regarding the u56 IDE uh like it felt like uh the increase is unnecessary with the motivation that was provided and I do have uh and you can read the comment to get more context I do have uh push back

regarding uh the excluding the ch from authorization the push back being that we're introducing a new primitive uh that is akin to the transaction but we're making it context dependent so for example if I have some kind of authorization router and I have bundler for different chins like and I want to see for which chain ID the authorization was signed and in my view it doesn't make sense to exclude it from the object itself yeah

so either way it's I'm

really sorry for like maybe raising my proposal because I was kind of hoping that we would just you know be able to finalize this spe but it seems this is more complex than I thought so I

Tim Beiko: guess the yes so Proto's original proposal is a relatively simple change as I understand it um it just changes the like Yeah The Way We cast this value does if there are concerns with your approach Felix like does anyone have concerns with Proto's suggestion

Felix Lange: I mean the thing is we can literally just change it now for whatever like I guess for definite 5 is already too late because we're literally just launching it so we're not going to

have it there so for sure there will be another before we go like what the like so let's just aim for the next devet to figure out the whole signature situation and I do have some other stuff in the pipeline for the signature as well that we're dis discussing as we speak so I do think that you know there may be another chance change coming to the 7702 signature stuff anyways so that's the thing like it really all depends on like where we settle in the end but it's very uncontroversial now to just accept that we will enlarge the uh chain ID to un 256 is very easy change to make so we can just agree to that today and then the issue will be gone

but I will be back with more changes to the 7702 anyway so yeah

Tim Beiko: I would I would prefer to get us as close to final as possible and so if there's no objections for the u56 change I would move forward with that one and then yeah if there are other things we want to discuss after like we we can um but yeah anyone oppose them to uh moving forward with the basically this would be like clients PR um let me post it in the chat here but to basically make this value uh U2 56 and then we'll just CL close uh Felix's

spr

Felix Lange: yeah we can do that for now but as I

said I will be back so anyways we we may revisit this for the next one okay

Tim Beiko: um yeah Perry the pr just link 9143 is the u56 pr and that's what we'd go for and then um 9152 is Felix's PR which we will uh close

Lightclient: did we agree to do that for def5 that was my understanding but just want to make sure everybody else was in agreement there

Tim Beiko: so I guess base this base who

already have this in because they're live on defet 5 I guess in practice we will not hit this limit unless we explicitly try to like spam it

uh just to maybe clarify a bit there is no defet 5 yet we're just doing local test so it's just a go oh okay okay um so yes

Tim Beiko: so then because this is such a small change I would include this in DEET 5 definitely not run another dep net just for this yeah any objections to including U 256 and DEET 5 Okay cool so let's move forward with

that one um so again that's uh PR 9143 that will add to the defit five specking anything else on 7702 okay uh next up we had a lot of uh movement on the BLS pre-compile spec uh Merrick you've uh opened a lot of these PRS and have been kind of leading the discussion uh do you want to give some context on your different PRS and where we're at with regards to BLS pricing

Marek Moraczyński: yes of course uh so we benchmarked BLS compiles and split it into three PRS to discuss them

separately overall the operations will be less expensive and we Benchmark it with a group of people from different teams and checked for EVMS uh so evm one NE mind bzu and G and yeah I guess we come up with the final gas pricing so please check those gas pricing uh the currently it is being merged so we should include it in next devet um yeah and that's mostly it about gas pricing and there is one more PR from pav about BLS uh remove redundant multiplication promiles and the thing is

that right now we have two operations with the same pricing that do the same thing so multiplication and multiscalar multiplication for k equal 1 and Pavo suggested that because of this the multiplication is not needed and can be removed and generally six people Express support for this personally I'm also weekly in favor of this change um it makes sense and even if for some currently unknown reason we want to add multiplication in the future it will be easier to add it later than to remove it um in the future when it was already added in evm

yeah so that's mostly it and uh we can discuss this multiplication what people think about it

Tim Beiko: thank you and before we do uh the M removal does anyone have concerns with the gas prices that have been merged otherwise we'll assume those are final and we should include them in devet 5 as well but last call if someone has objections or concerns I know we've been discussing this for a few weeks now okay amazing um yeah again thank you uh merik for the PRS and everyone who's

uh participated in the benchmarking conversations um removing the all pre- compiles anyone in opposition for this if not and I guess uh testing and like implementation wise I assume it's fairly simple to remove these pre compiles but is there I don't know some like uh complexity that yeah people are concerned with

Mario Vega: I mean the the only things that we were ready to release before this so I think it's going to be yet another delay

for test release um it's fine I mean if it if it's if it has to go in it has to go in it's not a problem

Tim Beiko: thank you uh Gary I saw you come off mute quickly

Gary Schulte: oh I was just going to say that um we would need to um Shuffle the pre-compile um uh addresses and then uh yeah to to Mario's point at least what what blocking Bas is is the not only the gas cost now but also just remove of all from the reference tests

Tim Beiko: and so oh yeah because the pr does

the pr actually change oh yes okay so it changes like yeah what's that zxf basically and uh removes a couple addresses so yeah so we need to make sure that we have the right pre compiles with the right addresses um then

Ben Edgington: uh and also add tests uh just to make sure that the pre pre compiles aren't there after it as well

Tim Beiko: yes we've had many devet and mainnet issues due to adding and removing BLS promiles so definitely we want to test both that the ones we expect to be there are there and working and that the ones we previously removed are not there um yeah but in general guess this is the

right time if we are going to do such a change um yeah just to make sure that uh we have defet five running with the final set of pre-c compiles with the final set of gas prices so even though it's a non-trivial spec change it does feel one like one that's worth um yeah including in the next devet and even having a small delay in terms of like getting the test out if um yeah if if that's a version we're going to

Shi y

I think we have historically tried not to overload promiles like this um I think the obvious caveat with this being

just the number of pre- compiles in 2537 so if people like this change let's go ahead and move forward with it okay

pushing back

Tim Beiko: last call yeah last call for objections otherwise I think we can merge this one and and track the pr for div 5 as well okay sweet let's do it then H again thanks everyone who helped uh yeah finalize the spec in the past couple weeks I know there was a lot to do there um next up uh EIP 2935 there was

an update to the system contract uh like clients do you want to give some context on this

hello

Lightclient: um so we had a handful of audits on these different system contracts and not much was found but for 2935 we had a few small changes mostly just to bring them in line with the other system contracts that we had so I think the main two changes was changing the buffer length from 88192 to 8191 this isn't as necessary for 2935 because the block number is always

monotonically increasing by one uh and instead of the time stamp which is generally increasing by 12 but might possibly change a different amount sometimes it's skipped so we just made this change more to be uniform across the board the other big change was instead of returning zero like the block hash instruction currently returns we revert when the argument uh the argument for what block number you're requesting is out of bounds with what's available this is also again just to be uh more consistent with the other system contracts that we have and just improves the correctness a little bit so that it's clear that the response for this contract is um yeah an

error instead of responding with zero so that's pretty much it and that's just updated the hatress with the new code

thank you uh gun

Gajinder Singh: yeah as one of the 2935 contract authors U I think 81 uh from 8192 to 8191 shift is okay I mean even though it's not really required as you already mentioned uh but I I didn't really get the reasoning for changing uh if it's out of bounds then uh changing it to revert instead of returning zero

Lightclient: I mean there's kind of three

responses when you return zero there's return zero revert or respond with the block cash and this reduces the number of possible responses to handle to two

Gajinder Singh: so we are itly basically diverting Away From the Block cash Behavior

Lightclient: which is fine because this is a system contract and if we end up plugging this into the block cach we can have an adapter that sort of handles this behavior and provides like the Legacy Behavior correctly

Gajinder Singh: so okay so what you're suggesting is that if we come to that point where for example in 7709 we use system contract for resolving block cash we basically can

handle it on that level to return zero if we want at that point

Lightclient: yeah I think it's pretty easy to do that

Gajinder Singh: yeah okay makes sense

Tim Beiko: um and I saw also on this PR there was a comment by guom asking about the actual audits uh so we got four done I believe and the last one finished up uh I think last week uh and so yeah the we were hoping to maybe present the results today but then putting everything together is taking a bit more time so hopefully early uh January we can present um yeah present the different Audits and and yeah share all the

findings but um yeah for now I think those were the most major changes that uh came out of it anything else on 2935 um I guess one question is yeah do we want to merge this PR in and have this also for Dev Net 5 um yeah given it's still yeah there's still some comments and um discussion or um yeah is it better to wait a bit more on this one

Gajinder Singh: uh I think me light client and gam we can just discuss and close this out

maybe today or by tomorrow we can have it

inet 5

Tim Beiko: okay okay then yeah let's do that let's try to get it merged uh by the end of the week and then uh also include it for de 5 anything else uh on 2935 okay if not that was the last Petra spec uh update on the agenda anything else with regards to the Petra specs that people wanted to discuss otherwise then yeah I think we're

starting to look good um Perry has a question around the Builder API I don't know if anyone has updates this

Alex Stokes: yeah I think I can speak to this uh I think the main thing was just the ssz standardization as a transport um there's a PR and yeah I think it's pretty close to merge in um but that being said it can kind of happen in parallel with all of this I don't think we need to block on a particular

dep not

Tim Beiko: okay anything else about a pectra spec okay nice well yeah well done

everyone hopefully this is uh the beginning of the end polishing the specs um yeah last call on picture before we move on if not um Piper posted an update on EIP 44s uh Piper do you w to give some Contex on this

Piper Merriam: cool uh just to quickly recap uh we've got agreements on all clients for activating a partial 44s which is a full which is a drop of pre-merge data of just block bodies and receipts uh from all execution clients the timeline for that is May 1st

2025 um and we've got resolution on the things that weren't uh that were still a little bit fuzzy last time uh we are going uh clients will be bumping the eth protocol version um the new protocol version can go live anytime between now and then and the idea is that the date in which clients can stop supporting the old client protocol version is May 1st 2025 uh this also kind of removes the concept of an activation date this isn't that May 1st is the activation date for the new protocol version May 1 becomes kind of the date in which clients can stop supporting the other one so this eliminates kind of the need for like a coordinated activation date um anybody

who's planning on doing a 7801 based solution is going to do that in a completely separate and completely isolated subprotocol um and then the handful of Cl and then the clients who are implementing portal for things like RPC or other things are kind of orthogonal to this because that is just sort of like external facing client behavior and isn't really related to the dev P2P related changes so I think we have resolution on everything um anybody have any comments on that or anything that they want to throw in cool the main thing here is that clients need to get going on getting their

support for this uh uh implemented and live on the network before that May 1st date so that we can have clients active on the network testing the new protocol version kind of moving over onto it so that we don't have a a big shift right at the at the May 1 timeline that's all that I have

Tim Beiko: thank you uh Roman

do you have any coordinated tesing process rather than doing it on Main something like def equivalent for the for the networking

prodical to

Piper Merriam: uh I don't have anything specific to

share on that at at this time um I will get with teams and see what kind of testing people uh want to make sure that they're doing

Tim Beiko: I assume we should at least run this on the test Nets before um and I'm pretty sure like we had sepolia at the merge I think hosi launched post merge if I recall correctly um yeah

Piper Merriam: I don't have a strong opinion on this uh the protocol version bump is a uh it it doesn't actually change anything in any of the message payloads so we're not actually talking about any kind of change in sort in terms of uh

payloads going between clients that doesn't suggest that we still shouldn't test this um um but it is uh technically a very minor change

Tim Beiko: yeah okay so we yeah we can definitely discuss um yeah we we we should discuss like a roll out strategy uh we can do this uh I think uh actually I guess client says we should just make this part of Petra and run the dev net test Nets um I don't know when the first Petra test Nets will Fork but obviously we're hoping it's before May 1 um would client teams feel

comfortable um yeah combining this or is it going to delay people's spectral releases

um what I

Lightclient: what I mean specifically is not immediately dropping history because we do one to get P Tri before then but to do the version bump where clients don't serve the history over the eth wire version 70 and they continue serving the history over the previous versions so all the clients still have the history they don't have to implement the actual history dropping in their database um it's just more like how is the behavior of the client observe on the network and I think that this is pretty easy to implement but what it gives us is then at the point on like

May 1st whenever clients start actually dropping the data they have a very good base of the network that they can start connecting to who will serve the protocol they expect

Felix Lange: so in that case we might also think about adding like a flag and err about this it's definitely something we can consider because I mean you don't really want to connect to all the peers just to figure out that like they're the other kind that you don't need like if you still need to download the history after the cut off date which you shouldn't then yeah I mean you can try to find peers but it's just going to take you potentially a long time to iterate through all of them just to figure out

that they have this new protocol version that you don't support so this is kind of for me the counterargument to dropping the like to adding new protocol version It's kind of useless for the clients which actually still rely on it so yeah I mean I thought the consensus was like at the time when we made the decision a consensus was that since we will like any client will be allowed to drop history it's not safe to rely on History being available bya eth anymore after this cut off date so that's thing you just have to have an alternative mechanism by that time

um AR the that

Jacek Sieka: yeah I don't think we should burden dis V5 with this because it's

really just um transition thing like you know a year from now or two years from now or whenever this will practically be all clients because they will have had to find a different way

Felix Lange: that's okay I mean we can we can remove the flag I mean that's the thing about enr like flags are free there I mean it doesn't really cost us much it's going to cost us like three bites just adding like or maybe four I don't know just adding a simple flag like I don't know H1 or something I don't know no

Jacek Sieka: I me I just think it's fine like we do this on the consensus side without a flag and it kind of just works you know nobody really bothers with

Piper Merriam: so I think that the the thing here is that the clients that need the

history still and are still trying to get it from the old protocol version or the clients that didn't update which are the clients who won't know about this flag I think that that um this is solving a problem that we don't have all of the clients are in agreement that they're going to to modify their clients so that they don't need to be able to download history over this and if they do then they need to find an alternate mechanism so I'm not sure that there's a um if there's like somebody here who really needs that maybe they can speak up but I don't see that we should Implement something for a problem that we potentially don't have

Felix Lange: okay but this is a good point with the with the non-updated clients that

like they need to basically I mean at some point you will have to update anyway but yeah that's kind of thing we can't just like force everyone to update right away

and I think

Piper Merriam: I think that's the argument for why this should potentially be included with Petra because um my understanding is that there are some reasonable subset of clients in the network that only upgrade at Fork boundaries

Felix Lange: but what should be included dropping history or

Piper Merriam: uh support for the new protocol version it doesn't even have to include the full history drop but just support for the new protocol version so that those that do choose to upgrade and implement the drop Will can get uh

support for it

Felix Lange: but the thing is that it's kind of funny because it's it's kind of backwards I mean so when you um when when you upgrade to a client that like drops the history before then it's like you don't need the new version because you could just get the new history still from the old protocol but it's like it's only for the clients which want to download so these are the non-upgraded ones you know what I mean like I don't really get it

Jacek Sieka: why I feel yeah likewise I feel the new protocol version is equally useless to a discovery flag

Felix Lange: yeah you don't really need this new version

because when if you if your client tries to download history from the old version then it doesn't speak the new protocol so if we Implement e70 that you know doesn't serve history before the merge then the old clients can't use it so they I don't

you

Piper Merriam: uh correct but the idea is that before the drop date the clients will still be willing to serve the old protocol version as well and after the drop date some of the clients or all of them or none of them or whatever can choose to stop serving the old protocol version so the point is to get the new protocol version out

if

Ahmad Bitar: if they opt to stop stopping to support they just opt to stopping 69 and 68 and only support

70 if they don't want to stop supporting then they just keep supporting 69 sorry

so everyone has strong opinions about this can we listen to Jim's message and either figure it out Bing court on a breakout next year

Tim Beiko: yeah it doesn't seem like we're going to resolve this in the next two minutes and uh we do have a bunch of other things on the agenda so yeah I think we can try to move this uh to the history expired Channel um and then yeah if two weeks async is not sufficient then um let's find a time in January to schedule a breakout and dive into this more um anything else on History expiry

aside from this issue that we haven't covered yet okay um next up then uh there was a proposal on the consensus specs uh with regards to uh Max payload sizes that could affect the execution layer uh if we decide to limit the encoded transaction size um leave uh yeah AR the duck uh you have the issue up do you want to give some context on this and how it affects the execution

layer

Jacek Sieka: uh I can quickly speak to it I mean I don't know

Tim Beiko: oh I think we just lost you uh we lost your audio

Jacek Sieka: uh you're back and oh can you hear me

yeah now we can but you were gri the past 30 seconds

Jacek Sieka: oh bummer so uh uh on the consens layer we have a limit for how much data we can send in a single frame this limit is because we can't really validate all data synchronously uh we can only validate some of the data synchronously so we have like a maximum amount of data that

in one frame uh that limit is set at 10 megabytes and for blocks in particular that limit can get exceeded if the gas price goes up because the blocks can become very large uh we're not there yet we've like this this limit was set in belatrix uh and it was set assuming kind of a gas price of uh gas limit of 30 million I think uh with a bit of uh spare room and if we want to increase the gas limit well then we need to increase this or do something about this limits uh the limit is a spam protection

mechanism basically so in Petra uh there's a gas schedule change that makes it more difficult to create these massive blocks but uh doing it this way kind of just kicks the can down the road uh so there's an issue open in the consensus spe repo that discusses a few ways in which we could fix this more permanently um the ones that are the most interesting right now are uh to either let the census layer and the execution layer agree on the maximum size of the transaction list in the execution uh payload uh this basically means that

block Builders and mols and so on have to consider the size in bytes of the transaction when before they add it to to the block uh so this effectively this is almost like multidimensional pricing except you know the currency is bytes um the other solution that has been proposed is to kind of compute this limit from the current gas limit uh that has a few downsides it's very difficult to implement in the consensus layer uh Gossip in the consensus layer was never really meant to transmit uh single chunks of data this large it's part of the reason why we

don't why we package blogs and blobs into separate messages um so the other alternative here is that we kind of agree on the limit and then or we derive limit from the gas limit and then consensus clients will have to deal with it anyway that opens up uh some technical complexity so I would encourage everybody that's working on the execution plan to think a little bit about this like what it would mean for the mempool if the size the total size of the transactions that are included in the block is given kind of like an upper bound and this upper bound would be you know um Hefty but not

too too Hefty so that we actually have a fair chance of transmitting these blocks within what currently is the 4 second um time limit now when we reason about this on the consensus side um one of the things we think about is that um we have an amplification Factor when blocks go out and then they have to pass through a number of hops before they get to the Final Destination so you can basically say that like you know a 10 megabyte block on a 10 megabit line takes x amount of time to transmit in full before it can move to the next top and we need to squeeze all that in and

some validation within 4 seconds so the Practical kind of limits that we're talking about like we should probably should stay within you know I think the theoretical maximum we thought about at the time was around 2.5 Megs not sustained uh and that would be one kind of Li that would happen just look at the is and then take it from there yeah

Tim Beiko: thank you for sharing uh yeah the background here light Cent has a question in the chat asking around asking about what the upper bound we're

looking for is because um yeah with 7623 we have uh bound the block size um so like yeah is that sufficient or do we need to do something else

7623 is that uh gas repacing for

Tim Beiko: yes

yeah there's still no bound so

Tim Beiko: yes there's a bound that's dependent on the gas limit yes

Jacek Sieka: yeah so it's this link between the gas limit and the size of the block that is the problem as long as the size of the block is determined by the gas limit no matter what the gas limit is then as long as we

don't have an upper bound on where the gas limit can go we also don't have an upper bound on where the block size can go and this is the problem uh so imagine we have you know Giga gas limit or whatever right and we have a massive block even with the electro change and that that's something that we should think about how to address in the longer term

Tim Beiko: so I guess yeah one thing we have discussed on this topic in the past is bounding the gas limit in protocol and having something like a Max gas limit in protocol um still allowing validators to like lower

it if needed um but if there is like a specific point at which the you know the block size is concerning that's another solution that's like a relatively minor consensus change the obvious downside here is then expanding the gas limit beyond that

um yeah uh yeah uh let's do Amad first and then appes

Ahmad Bitar: yeah um so one thing here is that even if you limit the transaction size you can always add more transactions that has that add to the size so unless like there is some mechanism to limit

the size of the whole like all of the transactions in the block which is uh very hard to reason about uh I don't think this approach will work uh I think that transaction like gas limit is enough to reason about if we want to set a limit to a singular transaction size then maybe we should limit the uh like add the gas limit per transaction um like I don't think any transaction should exceed 30 million gas or 20 million gas even but uh um that is uh definitely something to think about and analyze uh but yeah I don't think uh uh sitting as

for for for for for the transaction uh is is is a solution

Jacek Sieka: yeah we're not talking about that uh we're talking about the total list of transactions limiting a single transaction can inefficient it's better to have a single large one than you know thousand small ones so I don't think that is an efficient way of addressing this particular problem

um let do po is

Potuz: yeah I wanted to mention that among all the options uh it seems to me that it's limiting the size of the slice as yek is

suggesting uh it's actually safer and it's less back prone uh we have two different limits one is on the network gossiping and the other one is on the gas limit the gas limit is up to the community to decide and and it's in principle it should vary more often than the bandwidth requirements that we can handle on the consensus layer it seems much easier to let the latest one up to core deps to the side this is how much clients can actually handle on the gossip sub and we are going to gossip up to this limit and then it's e easier to reason about that the gas limit is

handled by the El purely by the and then the Builder is going to refuse to build blocks that are larger than the consensus limit so then you have these two guys that are actually separated uh so you keep them logically separated limits and you don't need to be doing like complicated computations you just know that whatever the community decides for the gas limit they are allowed to do but then the Builder is never going to build a block that is not going to be propagated by the consensus Network

okay thanks uh light client

Lightclient: uh it doesn't seem like we're really looking that deeply into the capping a single trans liit transaction uh size

but I just wanted to say that I definitely opposed to that approach I think there's a possibility that in the next couple years we see a lot of consolidation and the number of transactions due to 7702 and due to 437 gaining more popularity so you can imagine there only being a handful of transactions in a block so in which case it would not be great to limit the transaction size in general though I feel that limitting transaction size uh or transactions size arbitrarily in the consensus layer is pretty wonky and I would definitely prefer to either fix the gas limit so these constants are like uniform across the stack or to make the message size some sort of product of

the gas limit

thanks let's do Ben

Ben Edgington: um block building with uh the gas limits already an MP hard problem and if you're also then throwing in the bite limit you're making it combination much much harder um so if there is an easier solution it would be better

Tim Beiko: thanks um AR duck I don't know if your hand is still up or you had one more comment yeah

Jacek Sieka: uh one more comment like uh I will note that uh we can pretty much compute the maximum sizes

from the gas limit which means that if we do impose maximum gasas limit then we're also effectively imposing a maximum block size and then we've also solved the problem uh and then the way that I imagined that this would work is that you know the maxim gas it is set by developers indeed and increases on hard Forks or decreases of hard Forks or whatever it does um but it's almost the same thing except that we don't have a bite limit or we have a derived bite limit

thanks the down

Jacek Sieka: oh sorry yeah one

more thing the downside yeah so the downside of that approach is that um one that we've noticed while investigating this is that there is a very big difference between what a practical transaction looks like and what a So-Cal attack transaction looks like the TA transaction is all zeros uh it's very large and also entirely useless There's no practical reason for sending these massive transactions to pay um the other thing that this limit poorly captures is the fact that we use compression while the limit is set on the uncompressed data so and this is because you can uh play with uh compression bonds

and things like this so it's easier to Define it in terms of the uncompressed data but it kind um this representation doesn't one to one correspond to the actual Network effect it has so there's a little bit of complexity in choosing a number and the final thing is that uh it competes with uh blobs in terms of bandwidth so when the block goes out we have to transmit both blocks and blobs any increase that we do to the block comes at the expense of the amount of network bandwidth that we have available for blogs in the design that we have today also interesting to keep in

mind

I

Péter Szilágyi: just like to say that I think that this is something needs to be done um using gas on the execution layer I think various people have like played with like ideas of various sorts of special caps that could be imposed I think imposing those sorts of caps is just going to create weird edge cases in the block building process and cause issues and we have a mechanism for preventing people from using too many resources which is that we charge them gas for the resources and so I think we should focus on like gas based Solutions

Tim Beiko: thanks um let's do okay pols and then

move on from this and continue the conversation on the issue afterwards

Potuz: all right so there are a bunch of misunderstandings in the chat um so and and I wanted to address this thing of that the Peter was mentioning of course it seems that the best solution would be that if this is handled purely in terms of gas but it's actually not trivial to do this like multi-dimensional gas does not address this directly you have to have some sort of constraint by constraint based system for pricing and this is actually complicated uh eventually we might get there but uh as mentioned several times we have a gas limit that allows for these theoretical attack blocks that are very large but

most blocks are much smaller even if we increase the gas limit a lot uh so in principle I don't see any problem in allowing the gas limit to increase but preventing this attack blocks just by hard capping the size of the block this can be done at the e in a fairly simple manner uh and of course we can then see what is the right solution at the gas pricing level so that we avoid this with gas instead of like just Harding the size of the block but I think it's fair to allow score devs to hard capap the size of the block because we're doing this already on the consens layer anyway way and just leave the community to

allow them to hardap the gas limit which are and keep these two as separate as possible

Tim Beiko: okay thanks um yeah let's continue this conversation I think clearly there's much to discuss um hopefully we can uh yeah get to a resolution in the next few weeks um okay next up we have a bunch of different uh EIP discussions um first off was Andrew from Aragon uh that had concerns about removing new block hashes from

e69 um Andrew do you want to sure sure

Andrew Ashikhmin: uh so um um like in Aragon we support ethereum and and polygon and and nois chain um uh and polygon uh hasn't gone through merge they use it like kind of a proof of State consensus but it's different from from that of ethereum and basically they still use new block and new block hashes messages uh but and but uh e e69 potentially can still be beneficial to polygon because it

drops the the Bloomfield um uh and uh yeah do the total like Drop like we can um have a work around about like regarding dropping the total difficulty but um we definitely need new block and new block hashes for polygon and I'm arguing that we should not remove them from e69 because it doesn't bring any benefits for ethereum because they already uh they're already not used after the merge so like if we remove them and uh we can potentially reuse the same op op codes but it just pointless like I

it doesn't uh bring any benefits so uh I'm arguing that we shouldn't do it because um yeah it doesn't bring any benefits but it it introduces incompatibility and incompatibility with other blockchains such as polygon

Felix Lange: so I'm fine with not dropping them I think it's it's totally reasonable to have these messages the mechanism is very simple um I'm actually not sure if we have even deleted implementation of it in G I think I mean they are practically not used but um yeah it's it doesn't hurt to have them in the protocol

anyway

Andrew Ashikhmin: um yeah understand that it is a balancing act that like we we we should care about ethereum first and foremost for sure but I I just think I'm thinking still we we have to be mindful of the broader ecosystem and uh kind of I mean I'm pretty

Felix Lange: happy that the P2P protocol is kind of shared at least with some systems so I do think that it's fine for me personally as the maintainer of the spec to you know like figure out ways to incorporate you know other systems needs a bit into these specs as long as it's in the real of like what the protocol is designed for which is you know handling the chain um how we will do this the

long term I don't really know but for now just like keeping these messages in the protocol is not a big issue for the spec at all it's literally not a lot of text and yeah like I would just keep it cool

Tim Beiko: okay thanks anyone oppose the keeping yet okay well we can move forward with this um I will have to hop off uh in the next minute or so so we'll hand it over uh to Alex to run the the rest of the call um and maybe just introducing like yeah the next thing we had on the agenda um there

was an update uh to an EIP we discussed a while back uh the wormholes EIP asking for feedback um I I don't think the person who did this is on the call um but yes I don't know if uh we want to discuss this live on the call or people want to just review async um if there's any comments concerns we can discuss those now but otherwise I think I just point people towards the um yeah the pr and yeah it's something that uh is like for the next for so yeah doesn't

seem like the most urgent thing to discuss on a call um okay we'll hand it over to Alex then uh and yeah take it from you thanks everyone

Alex Stokes: thanks Tom let's see so we covered that and right so yeah there was a comment here just to close loop on this normal thing uh it sounds like they're just looking for feedback so yeah uh take a look at this PR 980 when you have a chance next up

uh let's see this is E7 Alex

Péter Szilágyi: sorry do you mind if I jump in something um a very quick thing that uh

I'd point out um there is on the discussion of the one hold IP um uh a small a potential for legal risk because obviously this sort of tech could be used for people people to do money laundering stuff um and there have been cases where people have been prosecuted for developing anonity Tech um so I think if there is going to be a process where people want to implement this we may need to like think about that issue um intentionally

Alex Stokes: right yeah I mean I think there are a lot of additional considerations it sounds like from the comment here that they're just looking for technical feedback on the implementation um so yeah I mean to

start if anyone's interested we can just take a look at that and yeah like we were saying I think it's probably quite a ways away from any particular hard for conclusion so these other questions are very very important as you call out um but yeah probably not something we need to handle right now thanks

all right okay so next up we have EIP 7808 uh this wants to reserve part of the transaction type range for rips uh the way this works is that EIP 2718 gives us transaction types that all of you I think are very familiar with and uh yeah essentially the CIP wants to

claim the upper half of this range for rips so essentially RBS can use them for their own purposes uh let's see this is from corl you have onar do one of you want to add some more context

Carl Beekhuizen: yeah so basically a bunch of the things that we would like to be able to ship for l2s are constrained by this um many of the things surrounding for example account abstraction uh in TR account abstraction require new transaction types and l2s themselves would also like to have a more principled way about reasoning about transaction types so uh much like we discussed on ACD a few months ago with uh EIP

7587 which reserved behalf of the pre-compile range for use by the uh uh rip prot the rips um this will do the same for uh the the transaction types and just for context here uh this range is uh 128 uh transactions wide so this would be assigning 64 to both so we're nowhere near this limit on mayet or something so it's or on L1 so should be a constraint

Alex Stokes: yeah it's hard to imagine we would have this many transaction types at L1 which you know maybe I'll have to eat my word someday but this seems

pretty pretty straightforward

Carl Beekhuizen: yeah and if need be we can also become like suers seed this this this EIP with something more concrete that that divides up the range more carefully in the future but for now I think this is a a reasonable thing to do

Alex Stokes: yeah and it seems like we could merge this outside of any hard Fork schedule so essentially yeah I think we just need agreement on the idea anyone think we should not do this okay I think the next step is maybe to

move the CIP from draft to the next stage um but yeah sounds like there's no push back so thanks okay next up

uh we have EIP 4803 lots of eips today um let me paste the link here so yeah this was basically capping transaction gas um essentially there's no reason for it to be bigger than this and let me see if there was a comment here I'm not entirely sure why this was here there's a note that says unclear what cons was and if this PR should be reverted does anyone here have any more

context on the CIP

Felix Lange: I mean the basic idea is pretty simple right it's just that the gasm has a practical limit of 64 bits so we can just treat it as that this this is something that all the client implementations have done as far as we know like just they treat it as a un 64 so it's for all intents and purposes it has been retractive applied

Alex Stokes: right okay I'm not sure yeah apologies I'm not sure what the action item here was

Felix Lange: I mean I guess it has to be updated in the executable spec

Alex Stokes: right

Felix Lange: so can someone from eels can you comment on this like are you

treating guess 64 bits in the spec or

Danno Ferrin: so there whether it's a u64 or an I64 signed or unsigned I think it's one and as written in the agenda it's

sign

Péter Szilágyi: um I can jump here on this so um the current system I think um in spec um is that uh I think we technically might actually treat gas um as an unbounded um signed integer which is supported in Python um this um and basically there's two sets of issues here the first issue that happens here um is that there are some things that

bounds that are impossible to hit in any plausible scenario but that someone has to put a Bound in the code it's like the issue with like we've capped the nons at um 2 to the 64 minus one um despite the fact that it's completely implausible that anyone is ever going to to achieve a not on any account of 2 to 64 minus one um the the second issue which I think we're going to have to work on is um dealing with the issue of um exactly how bounded um different like objects in things are so we've had situations where people have written tests um that involve um rejecting transactions with

nonces of 2 to the 64 and the problem we've had is that um those um those tests like they just don't process because some clients when told to put um something greater than that doesn't fit into a u64 into a transaction non field just fail to pass um the the field at all um so I think this is an area that needs like a sort of coherent thinking it's something that I've been thinking about um I will write an issue on the execution specs repo and post it um probably in the allore dev's channel um and we could

sort of move from there because we don't really have a particularly coherent way of thinking about how fields are that are capped by size are capped and what's the consequences of those caps

Alex Stokes: okay then uh yeah yeah just share the issue once you have it any other comments on this at the moment okay thanks

Felix Lange: I mean sorry

sorry sorry just was a bit late

Felix Lange: so notably I mean this is an e which is basically

it's it says it's in a review stage but in practice it's like in the final stage but since it is sort of final if we want to make an update we can just make another E that like further restricts it or changes it or whatever but I would say that you know like it doesn't feel so productive to resurrect these like super old Eeps and try to change your status when literally they are in the past and like have been dealt with

Alex Stokes: so you're saying we should just ignore the

CIP

Felix Lange: no I mean it's basically active but what I mean is like we could I mean it just seems weird that we're discussing super old e and trying to change yeah you could just make a new

one I mean

Alex Stokes: okay anything else on this okay then we'll move to the next set here on the agenda there's just a number of announcements and yeah the first one here is 9216 let me grab a link for that one and essentially yeah I think the update here is just that uh this has been merged there was some language here uh updated in EIP

7723 around different statuses uh for parts of the IPS throughout the ACD process um just yeah updating again how we use some of these things there's this notion of CFI SFI and then how they relate to Deb nuts we covered this I think last week on ACD so yeah should be pretty straightforward and I think the update here is just that this has been merged okay next up uh a new ebm resource pricing working group uh so devida and ongar uh have an announcement here I don't one of you on on the call

we're both here I think oh hey

Alex Stokes: yeah

would you like to give y yep

if I can share my screen for one minute also need more context yeah so um this is um the gas schedule that was used um initially to set gas prices and then like uh it was used once again I think in EAP 150 and then um we didn't use it um um anymore but essentially like um what uh we are doing with asgar is we are doing some research on resource pricing focus on like multi-dimensional resource pricing

uh but we think that there is like some interesting uh benchmarking SL modeling work that can be done uh it will both like support the work we're doing and also potentially help us um with this repricing of op codes that we want to do um so basically here uh what um was done is like um resource prices were set in a pretty principle way right like uh you can already see that there is multiple resources many of you have seen this but like for who has not seen I just like go very quickly over it um and then um what each res course there is an approximation of how much it will

cost right in like for for example compute uh in micros seconds history bytes etc etc and then um there is a gas limit which was 3 million in this case uh now it's much higher but then there is also a gas limit for um uh each resource and then basically the full cost was computed by like um aggregating like all the resource cost so this is already in line with what we want to do with resource pricing um so we think like U it would be really interesting to get like some clients involved to help us basically refresh this like we've never like refreshed it like there's been like some

eips that touch like specific op codes that I also reported here but um um most of these are stale I know there there is some interest in like um uh doing repricing uh and I think this Benchmark can also help doing more principal repricing as well um yeah most of the op codes are on the compute side but we are also quite interested on like uh the ones on the iio side and um yeah so this is kind of like the initial focus of the working group but I believe asgar has also like two or other three topics I don't know if you want to add um um Anar more detail on that

Ansgar Dietrichs: yeah sure and maybe

you can oh keep your screenshot head on second because I think people are curious to see that um yeah so so so basically the the ad and is said like there's both now more active research again going ongoing on the kind of the longer term path here and uh I mean I feel like in a way multi-dimensional pricing is is is almost a bit of a meme at this point but it's it's actually I think it's not even going to be that big of a change once we actually are ready to to do the full thing but that's definitely going to take a few a few more Hard workor Cycles um to get to get there um so the idea was to just see because there's already a lot of like individual efforts ongoing right now of people thinking about individual bits and pieces of hey could we do like some

sort of shorter term repricing we had these ideas of just taking all of like this all of these basic compute e compute up codes and setting their price to one and I know people have been working actively on on on pre-compile benchmarking and so basically the idea would just be let to to have us to to basically create a working group um to bundle uh all of these uh indiv ual efforts um and um make sure we can work towards something that uh I mean I would say my target would be to try to have something shippable for fusaka I mean of course who knows fusaka is already getting pretty full so maybe it would be fusaka plus one um but either way basically like work on the more like short-term shippable things um yeah was

saying the the focus would be the kind of just a onetime repricing and one I'm not meaning we would never reprice things again it just means like a static repricing not not the not the multi-dimensional um um but there also some other small things that I think could be part of could be in scope for like short-term changes around like Block Level pricing around um um a few a few other tweaks like this this gas Sheltering kind of um fix so so basically just all things fee markets in like a more shortterm Focus um and yeah the idea was just to get that at home I think for now we were thinking the best thing to start would just be to say create a Telecom Group uh I think that D already created one we can we could share the link in the Al's

Channel and then take it from there and then in the new year maybe start with a A breakout call and um yeah try to make progress but yeah I don't know maybe people have feedback

Alex Stokes: um there were some comments in the chat just about other threads uh here but yeah I think this sounds like a nice way forward if you post a link to a group on Discord and people can join and yeah looking forward to any work that starts up here in January

Ansgar Dietrichs: right and yeah by the way just just I said because do asked whether that's connected with these other

efforts already ongoing Yeah so basically the the point specifically is not for like us to like to basically start or lead this necessarily um we were thinking maybe we can like basically help as like coordinators and and with some some of our own ideas but but but the point is to to just say hey there's already now several in several kind of several different groups in the in the C of space right now are all working on on some portions of this so let's just make sure that all happens in a coordinated way that's that's primarily the intention here

Alex Stokes: yeah makes sense any uh questions from anyone here about this any other questions okay thank

you and to wrap up the agenda here two calls for input uh so yeah again let me just grab the links here so the first one uh is around changing essentially what meta means uh relative to the eips and the IP process I'll just put the link here uh let's see Sam opened this I'm not sure if he's on the call or if anyone else here would like to say anything more but yeah I think ultimately just take a look um there's some conversation here and I think the ask for this group right now is just to take a look at this okay otherwise there's one

more uh let's see here porly draw s 675 this is around retroactively activated eips and yeah again just a call for input uh for changing some of the semantics here so yeah take a look at that and otherwise uh yeah I don't know if anyone here has anything else i' like to say about either of those

Pooja Ranjan: yeah maybe I can add some context here generally sure generally we discuss some of the uh discussions those are are happening on different forums like all cord meeting or Fellowship of ethereum magician or even on Discord and uh if we collect some kind of questions and

concerns from the community with respect to any proposal we try to discuss those in EIP IP meeting and based on the uh discussion of eipi meeting if editors want to make a um decision on that we we invite people to share their comment on call for input so this call for input is basically suggesting that whatever was discussed in the last eipi meeting uh these changes could be implemented we provide a one month time period for Community to add their thoughts so particularly talking about uh these two call for input there is this one discussion that happened yesterday it was with respect to how we are using meta currently meta as defined in EIP 1

is mostly related to press uh processes however it has been used used as a upgrade meta so this particular call for input is to U clarify that either uh we need to move all upgrade e to informational or we might want to update the EIP 1 so whatever people feel good they can go ahead and add their comment and similarly the other one um as per the process um editors and the community do not want to maintain an active list of Registries and that's why there is this um call for input to forcibly close that particular proposal so please take a look and add your feedbacks and

comments to that

Alex Stokes: cool thanks P okay I think we have covered everything on the agenda uh any final comments from anyone otherwise we can go ahead and wrap up I guess maybe just to call out there was a question in the chat around devet 5 timing because I think that's probably a very relevant thing for everyone here um I think it will launch as soon as we have a sufficient number of clients ready so I would treat the devet 5 launch date as

imminent meaning uh yeah to the extent you can with the holidays uh please make progress on the the at five specs okay anything else otherwise we'll go ahead and wrap up a few minutes early today

Kev Wedderburn: um is this working

Alex Stokes: yeah we can hear you

yeah

Kev Wedderburn: uh yeah I wrote in the chat um we've been working on sort of a hardware requirement stock for validators that's sort of been sent around initially for some internal feedback uh and it' be be good to sort of get feedback from The Wider ACD and community and this is like related to

gas re pricing because when you're benchmarking you sort of need to choose the hardware specs right

Alex Stokes: right is there anything you'd like to share right now

Kev Wedderburn: uh I can share the link in the chat or in the uh AC uh the Discord

Alex Stokes: okay uh yeah I think Discord would be good when you're ready okay anything else otherwise we'll close out for the day and yeah happy holidays everyone

Gary Schulte: happy holidays

Alex Stokes: bye bye

everyone happy holid everyone happy holid days happy J

oh

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