All Core Devs - Execution #163

Transcript

foreign [Music] [Applause]

Tim Beiko: okay uh we should be live um so welcome everyone to acde number 163 um have a basically a lot of Cancun stuff on the agenda today um and then some well engine API decisions also probably fall uh within that and then if we have time we can even talk about the validator spec um I guess uh to start off uh is dencrat here yes dencrat is just joining amazingly um okay so I guess the kick us off uh dengra that you wanted to propose a

change to the blob limit uh for eip4844 do you want to take a minute to walk us through um well you know obviously why you want to do that but mostly um sort of the tests you've been doing um that you think Justified the change

Dankrad Feist: uh yeah so I mean I'm not gonna repeat everything because I represent I presented that already on an httpc last week so if you want to have the extended version then I recommend listening to that recording um so the summary is um we ran some tests on mainnet where we created blocks of large sizes so we we simulated a sustained load

um and uh that we we tried that between 128 kilobytes and one megabyte um and so we did 260 kilobytes to 512 and 768 kilobytes um in between and um so in all those tests um the network looked stable like we didn't see like um lots of validators going offline or anything like that or like attestations being massively delayed so none of this happens um what did happen on one of the one megabyte tests um is that one of the blocks got reworked so that block was late was after the four second deadline just

passed like by just hundreds of milliseconds so very close and so uh majority of a validation that tests to it and so the next uh proposal re-oricted um didn't happen on any of the other tests and um as a comment like even in the normal conditions we sometimes see uh blocks up to like 3.5 seconds into the slot sometimes and um so like we probably don't cause this but probably uh not by delaying the block by four seconds but probably our delay was only added up to like a proposal that was already pretty slow so I would attribute that to the very aggressive four second

deadline and reorging rather than to our tests like nothing else went wrong other than that block being led um and so my recommendation based on these tests is that uh we should consider raising the the limits to six blocks rather than um uh four and and the targets to three um because uh yeah we don't see any problems with uh with these loads and our 68 kilobytes um yeah please have a look at the data and see um if you can agree with that um also as a comment from last week I think so the the tests were sustained loads so we created 10 blocks in a row

with these capacities so we didn't just send a single block um yeah got it and yep and maybe final comment if anyone has a look at this test and find something that they would really like to see um uh we we are we still have all the infrastructure up to do these tests um so ideally if if there are any more tests we should do I don't think we need more but if anyone thinks we do then we should do this soon because uh it costs a lot to run these notes and we probably want to Sunset them in the next few days otherwise

Tim Beiko: awesome thanks

anyone have comments or thoughts on this and I guess oh yeah please yep go ahead

Alex Stokes: oh I was gonna say it seems pretty reasonable um maybe it's worth doing the experiment one more time although they're kind of expensive but if no one has any reason not to then yeah I didn't consider it any specific experience

Dankrad Feist: you mean 768 kilobytes because that's what we're attempting or what would you like to see we did two of these by the way two at 768 kilobytes and two at one megabytes

of sustained

Alex Stokes: yeah maybe we're more just at like the yeah the numbers we're going and then just try a different day different network conditions see what

thank you

Mikhail Kalinin: you want to suggest to increase these um numbers right from the beginning or after I don't know a month of evaluation on the

main map I mean

Dankrad Feist: I would suggest doing it from the beginning like changing it each time is at least according to the current setup is the hard Fork so that's a lot of coordination and takes a lot of our time here

um so I think it's reasonable to just do this from the beginning and like we are doing the decoupled blocks which should actually uh be a lot more gentle than the experiments I've done um if what we're claiming and stimulating us too so I would suggest doing this from the beginning

Tim Beiko: does anyone think we shouldn't do this or has issues with this uh Gary has a question about like yeah what's the max we've pushed the network did we reach 1.5 2 megabyte blocks

Dankrad Feist: so

it's hard to create sustained Blobs of that size because you just are not going to get all your transactions in and you're competing with other people who want to put in transactions so one one megabyte was okay although um even there we didn't all get into all the blocks that we wanted to um we did in that process create some blocks that were significantly larger I think the largest was 1.7 megabytes um but yeah I'm I first I don't I don't think we will see instability I don't have any indication on my net that it does will create instability um and second um I yeah

I kind of it's difficult I don't think we're gonna learn that much because we're gonna see very erratic loads in practice

okay I

Tim Beiko: guess does anyone disagree with this change

Ansgar Dietrichs: well and I don't there's a group I say and I don't think this is a high chance but it won't just this very briefly also do temperature check around pushing the two all the way to four eight um so like up to one megabyte maximum I

assume most people would be much better uncomfortable with that or because we do have the uh blob decoupling chunking to give us some extra robustness um so I I don't know I would still think it's worth considering but if people of course feel uncomfortable you might like three two six sorts of good compromise

Tim Beiko: I think uh dapline has a question around what's the added disk requirements going from you know two to three to four targets right

Dankrad Feist: I don't know the numbers out of my

head but I mean it's an easy computation in this case right yeah one block is 128 kilobytes over the retention period

Tim Beiko: Okay so uh okay so Ben is saying two per slot is 33 gigabytes over 18 days um so three would be like around 50 ish and four would be uh 66 I guess and then you know up to potentially

well yeah I guess that's the average adult you're gonna get but probably a bit more you can go past the target I guess yeah any question

Alex Stokes: yes is it too late to do three six on devnet6 I mean basically I think we should just roll this out as soon as possible and see what happens

Tim Beiko: yes I think if we decide this we should decide it you know if not now then on the call Monday so that it's it's part of devnet6 yeah

Alex Stokes: it seems like it's worth doing because

sorry go ahead now go ahead

Barnabas Busa: uh so before we started off at 116 yesterday and we had made some progress on it but there's still quite some uh paintings that have not joined yet so this is more of a pre and sixth one so you're gonna be relaunching it with most clients uh hopefully in the coming week if we want to make some kind of modification or it's entirely feasible

Tim Beiko: um okay so there's a question as well as

like uh testing this in the transaction pool so basically yeah are there any issues potentially before the block building funnel um I don't know if there's any thoughts on that or if that's something we can maybe try on

devnet6 if not it was just kind of an orthogonal question right but separately yeah we should probably span Mentos and make sure that thing Falls over

Tim Beiko: I think we can probably move forward to

have this at least on devnet6 and test it out there we can also do tests for the for the mempool and then yeah once um yeah once we have that running uh we can reevaluate if uh we want to uh keep it like that potentially move it to 4 8 or even lower it back down to two four um but yeah any objections to moving into three six for Dev dead six uh Ansgar

Ansgar Dietrichs: yeah I was just going to say Islam is this any chance before it I would rather have it started for it and we can always

lower it back down because I think we get just better insights right because there's nothing that would be a problem with three six that won't show up with 4 8 but the other way around at night so if we at least if we want to consider it at all for um right before I think it would be better to start with the larger limit

does anyone think we should consider for it aside from Nascar

Alex Stokes: how much data do we have from the experiments not granted

uh out for it

Dankrad Feist: yeah we have to we have two series of that um as I said nothing major happened to the network it's just that one of the blocks was

delayed so one uh once once block was

opened

Alex Stokes: right okay um I feel like I heard chatter about devnet7 so we could do three six and if that looks good I'll put up we could also go the other way

I

Tim Beiko: yeah I I think I'd also go that route uh there's a question by Lucas around increasing the attestation time which yes seems like a whole different can of worms

Dankrad Feist: um I don't know I think that would be a topic for apdc but I yes I think that's a good idea yeah

Tim Beiko: okay so we can discuss that next week or

Danny I see you coming off the back of me I was having technical difficulties right when on the girl was suggesting for eight so I kind of missed that

Danny Ryan: my gut was that we didn't have data indicating that that was a good idea and that on test Nets we're not going to get that data because it doesn't look like mainnet so I'm was there an argument that I missed I apologize

Ansgar Dietrichs: argument was just that we do we will do the block decoupling so we get some extra in chunking so we'll get some extra robustness um with that and even

without that extra robustness we already only had very minor issues um at that size so it seems worth at least considering for me in it and if we want to at least consider it it seems better to start the test net on the upper side to see any potential issues come up there and then we can always lower it for later tested rather than the other way around but if the stronghold parenthesis is 3 6 then I think it's also fine to do that instead

Danny Ryan: yeah I guess I I'm um I'm not sure that I would still test that data and then be convinced that we're good on mainnet because it's just extremely different topology but uh we can take the step towards three six and keep talking

Tim Beiko: yeah okay yeah okay I think I think three six probably makes sense to start so uh let's do that Ansgar says he can open the pr for it um so on the on the El side um so if someone can do the corresponding PR on the CL specs um we can move to count to three six and uh have this part of devnet6 does that make sense everyone

Danny Ryan: um and when is done at six or second time uh if we are doing this release like ASAP or if I can do this release in the end of the next week

Tim Beiko: um so Dev that six already had started but will be relaunched next week

Danny Ryan: okay so this is a get this out tomorrow with death hunters and things um rather than wait till the couple other things worked on thank you

Tim Beiko: yes that's uh yeah and um yeah I guess next thing on the agenda was devnet6 uh Barnabas I know you've been tracking down all the PRS uh this week uh do you want to give a quick update on uh where we are both from a spec perspective and like you mentioned uh earlier uh basically the first uh release or Live cast I've done at six

Barnabas Busa: sure so basically our contestants back has been uh released and we have all agreed uh we're going to do if we're going to change this uh to three and six I think this will require another release maybe uh I don't know if there's any changes in The Coincidence back for and then for execution eips we also have uh most of the or all the PRS merged and for engine API there is uh one more open car 98.

and other than that everything else is emerged we currently have the 116 running with load star and uh Deku on the CIA side and we have never mind ethereum JS uh and bezel is not working just yet but they are already part of it and guest is also not working just yet but they are also part of it so hoping to the Lighthouse also at the end of the day without any validators just to see if they can join the network and sync it up

and then hopefully next week we're going to be able to onboard a few more client things it is relaunch

Tim Beiko: nice and I guess okay so you mentioned this execution API PR um this is about adding a field to the receipts for transactions um so I'm curious the block is the blocker there yeah or I guess what is the blocker there too uh get this merged I see like client in Roberto we're going back

and forth on it but

are you

Barnabas Busa: curious about the opinion of uh the field apps on this one

Gajinder Singh: so I think on this uh on this uh for execution apis added against used and did I guess price that's what we're talking about right yeah yeah so this PR is I mean it's not contentious and it was sort of mostly available and Roberto asked to include

an extra field so this basically include these fields in the RPC uh and basically does not affect devnet or the consensus right but also I think uh I mean it's non-contentious so we can just approve it there are some edits regarding some typos I think we can just include them and try to manage this

VR

Tim Beiko: and I see there's a comment by like science around uh there's more RPC changes for Cancun so we wanted to merge all of them together is that still the case I don't know if you have a mic

that's

fine

Lightclient: hey yeah I think this is like this is mostly it I'm not sure how we need if there needs to be changes for the RPC to submit blob transactions and we I don't know I'm not sure if there's anything else that needs to be changed uh probably something for like the actual transaction objects to denote to their blob transactions as well

Tim Beiko: are you saying that even if we merge this there's some other change that will

need to be done in order to expose The Blob transactions via Json RPC is that right or two right

I don't think

Lightclient: that we have the blob transactions defined or uh like each get blocking and we don't have them defined I mean we kind of accept them for send raw transaction because we just get rlp so I'm not sure if that anything needs to be done if I want to submit a Blog transaction to the transaction pool but I think that there are still some things around like the actual transaction object that need to be specified

Tim Beiko: got it in that case

does it I don't really think this is blocking the definite though yeah right so does it make sense to like whether or not we merge this have as like a Target get for devnet 7 the one after this to have full Json RPC support for broad transactions um I have one thumbs up uh two thumbs up okay okay so let's I mean you know we can or cannot merge this but I think yeah let's not have the full RPC support in scope for devnet6 and uh let's try to Target that for devnet7 I have one more uh

thing to mention that we would like every client to include a trusted top filed flag in their implementation where we could possibly overwrite the sort of txt or J file before for that that should happen uh yes this should happen during uh run time and not during compilation time okay any client have a problem or objection with it there is another in the top of this back oh okay I see yeah the resection okay

nice okay anything else on devnet6 okay perfect and uh yeah so we have a call uh Monday as well about 444 so we can discuss uh any specifics with the client implementations and whatnot uh there um okay so next up uh the rest of Cancun um Alex you had a question around the spec for four seven eight eight uh so you can do this first and I think after that it probably makes sense to hear from clients one last time about um whether there's anything else we want

to include alongside the currently included eips so that uh we can start um basically finalizing the scope of implementation for Cancun um but yeah Alex do you want to talk about uh the issues around uh 4788

and state growth there

Alex Stokes: so eip4788 uh this is essentially a cross layer EIP so what it's doing is taking the parent beacon block route from the CL and the CL sends that over with each execution payload the execution layer then basically writes that into the execution state in a place that everyone can look up

and so now we have access to this inside the VM which is really good for a lot of different applications so the question here is what exactly does this look like uh the way the ap's written now is there's a pre-compile that kind of exposes this part of the state and the question then is like what is the interface to the to this pre-compile essentially um we've had a little back and forth about this and uh we talked about this some on the the alcohol last week but essentially where things have gotten to now is that uh it's written by the root and then basically what's behind the route is uh

the the timestamp uh from the header so the idea is like if I want to use this thing I could call it pre-compile with the root and if the root was valid I'll get back the timestamp I can then use the timestamp if I want an evm to like prove the slot and do all sorts of things from um the thing is the way this works uh is that there's no easy way now to limit how many rights there are before it was written by say the the time stamp in the header so you could do like some ringwether thing based on time um so what that means is it's written now the EAP has like unbalanced big growth and the calculation is something like 80 megabytes per year assuming to block

every slot so you know it's not nothing um and generally be good just to like found this where we could so the question then is how do we do that a really natural way is just to flip how this thing is indexed so rather than do uh you know the key is the root and the values of time stamp is you just flip it and then have some like you know say modular some period of time for the timestamp and then now this thing is bounded so this works the one thing that's a little weird is that if we really want to like stick to some variants that the El does not know any CL information then what the El gets is every 12 seconds every seconds per slot you this gets another route and then you know the

thing you would naturally do is just write every last sentence or every second since you last wrote you would write through it again and what this means is that basically there's like 12 rights of which 11 will like never be used

Danny Ryan: zeros right because it doesn't know that they're what happened in the middle

well you do because nothing changes I suppose it doesn't

Alex Stokes: well but this yeah and so here's the other thing is that like anyone reading this will just probably optimize it and be like hey like there's only one right every 12 seconds that's just what I'm going to do um you could well okay actually Danny

the reason you wouldn't do that is because you won't callers could probably be able to like give any time stamp so the idea is like for this time stamp kind of which law are you in and here's the route

Danny Ryan: um well you could also argue that colors know when blocks happen and you can just well so yeah yeah I mean the semantics are a bit weird if you have something that you can call on like modulo 11 but I I don't see something I don't see anything wrong with those semantics

Alex Stokes: yeah yeah any questions it would be best to ban the state growth so then yeah I guess we just go ahead

and make the Swap and then that's that from there I'd really like to all agree on cooking this and Cancun

Tim Beiko: okay and yeah just to separate those two things so first any objections to just bounding the size of growth um given the depth of history that we want

Danny Ryan: given that we'd have the 12x multiplier on timestamp uh is there uh what's the size of the Ring buffer

or

Alex Stokes: we could still Target about a day so that's what I was thinking just to mirror the period on the CL because we

have a similar construction there um and we can figure it out so that's the same amount of data basically that's like 230

legs

Danny Ryan: oh no that's not I mean bounded generator 30s magnets is better than unbounded 80 magazine in my opinion not that

it is so but still yeah I don't know hi

Danny Ryan: yeah and that number is I'm doing 225

times 32 times 32 to get the bytes

Alex Stokes: okay yeah uh let's see I mean we can make the windows shorter

Danny Ryan: so anyways it's 330 kilobytes I apologize that's much better I yeah yeah that's fun

Alex Stokes: um either way the mirrors can be tuned

so it's like a small bounded amount of space and like I've talked to different staking pools they're okay with any of these different designs in terms of different Optics and like as long as it's not like you have to get your transaction in the same block that the route is

Tim Beiko: you know I think they're they're okay with you know some amount of Look Look Behind and I think it's probably much easier to start it off bounded even if we eventually wanted it to grow unbounded for whatever reason but if we do the other way around uh we will never be able to bound it because someone will be relying on the first beacon route that was ever posted for something

Alex Stokes: yeah exactly

Tim Beiko: so just not have yeah like whether it's a day whether it's like an hour whether it's a week I think that will lead to like different design and like applications and we should probably nudge towards that yeah

Danny Ryan: I'm like I don't love the like rights for every second it doesn't really matter I have as I'm thinking about it now like it is nice because you could upgrade the slot time and the execution there would never have to know which is is a nice property um so maybe that that makes it worth it in and out itself um but I'm I'm pretty fine with

those of

Tim Beiko: any objections I guess anyone think you

should not do this

Marius van der Wijden: I also don't like the the extra rides oh I think which like the the caller knows the timestamp so they should just give it to us

Danny Ryan: if you don't know seconds per slot on the execution there I think you do need to sweep the interim

all

Alex Stokes: right but you could just say the time stamp and the header is the value and then like you're suggesting there

are some are just zeros and then it's

right

Danny Ryan: yeah I mean you either need to do that with the with a map or with a ring buffer if you do the map you have the abandoned growth you do the ring buffer you have to write these are zeros or the root so the interim time slots time seconds

uh Dano

Danno Ferrin: um not an objection to the the idea about just some design questions why put the pre-compile at the High apps and not at the next pre-compiled position

Alex Stokes: it can go wherever

so the precompile on the state for the compiler or in separate places right here right like three file is actually below the list slots at least

Alex Stokes: it's not right now but it could be um yeah like it's I think it's a little weird to have them be separate right because you could still call this state separately I think it makes sense to have the people probably like an interface around the state at that address from there I just copied this from EAP I forget but essentially there was an earlier EIP that suggested moving block hashes from the execution layer uh to like a similar method where you'd have them in the states and I think the idea

is just this is a staple brick and pile so like toss it say at the top of the address space rather than at the bottom

Danno Ferrin: it doesn't care it calls it and gets a value and now we have to check two separate ranges for pre-compiles so from implementation it'll be easier just to group them together and I don't think that the uh the stateful distinction is terribly useful to an implementation because it's going to be going to some method that's going to do something completely unrelated to evm operation execution

Alex Stokes: yep sure

Danny Ryan: yeah my God is to not have it in the high ranges if this is a stateful pre-compile just accept that we have saved for free files and put them with

the rest has been my intuition

yep

Marius van der Wijden: totally especially because we have already like tests for it and all the all the precomplettes have have one way at least like the first 10 24 and we also have those set um on basically every test net and so there's a bunch of things that can go wrong because compile doesn't have any money so just having them in the normal pre-compiled range okay they are always funded

Alex Stokes: yep that's easy to do and I can definitely do that okay

Tim Beiko: any other comments or thoughts so I guess uh yeah last thing for Cancun um I'd be curious to hear from client teams of like the eips we've been discussing in the past few weeks um is there anything that folks think should go uh in Cancun so um I can post the link in the agenda

are in the chat sorry right here um but basically uh we have already 11 53 48 44 and 67.80 so the trends in storage blog transactions and self-destruct removal um and then we had a bunch of cfid ips so uh 27.35 the BLS recompile 4788 which we just talked about um and then a couple uh up codes so M Copy pay and then the revamped call instructions which we discussed last time yeah uh I see uh is this wreck from nevermind it's also uh yes okay yeah so uh some support in nethermine for four seven eight eight

yeah I don't know if any client team wants to just share their thoughts about but they'd like to include if not I mean does anyone not want to intrude 4788 okay this is the last chance let's include 4788 final chance if anyone has an objection

and then of the rest of the basically four other eips so um BLS M Copy pay and the revamp call instructions is there anything else that people would like to include

Andrew Ashikhmin: well Aragon would like to include the player op code

Tim Beiko: okay so there's a comment for pay a covered for M Copy in the chat that came at the same time I guess yeah let's start with pay does anyone feel strongly for against the payoff code

nearest and tamash are saying they'd like to keep the school yeah go ahead

Marius van der Wijden: yes um I feel strongly against the payoff code because it introduces a new way how basically I don't know how how accounts can be touched which is always um kind of complicated I also don't really see the point in having the payoff code when we have the the call of course already I know yeah I know that there are some security issues

with the call-out codes um but yeah it's I don't know it's it it it it doesn't strike me as very uh much needed right now um and uh so it's not really a priority for me so I don't think we should rush it into into a heartfelt yeah

Tim Beiko: Andrew I don't know if you wanna make the case for the

payoff Builder

Andrew Ashikhmin: no I think well there is no consensus then it's okay to skip it

Tim Beiko: okay um I guess the next one so uh like

clients you mentioned M Copy and Charles see you have your hand up I assume it's about this as well you wanna either of you want to do a quick picture and copy

Charles Cooper: uh yeah I wanted to talk about M Copy and pay uh a well let me address pay first I think it's uh pretty important to uh first of all I work on viper I think it's pretty important to or get into the evm I understand there's concerns about you know implementation complexity um but it is important to be able to have a way to transfer ether without transferring you know execution context there's a lot

really like I don't know I have to go through the list but you know I think like 30 to 50 percent of you know these high profile hacks are related to actually transferring ether and people are always switching to using weth instead of eth um and um we have a lot of you know warts in the evm that are kind of like a result of having to you know deal with this gas stipend for a call people are always trying to like um figure out how to transfer either and then you have to do these um either explicitly check for re-entrancy or

you know try to try to hard code a limited gas type and in order to prevent you know these kinds of weird things with computational being transferred to to not yourself so that's that's the case for pay I understand if it you know doesn't make it into this hard Fork but I think that it should be really strongly considered um maybe for the next one uh and then the case for M Copy uh is is in my view pretty straightforward to uh it's pretty straightforward to implement it doesn't have too much well as far as I know any interaction with the other VIPs

um it would help compiler this generate like much better code really so improving on code size and gas anybody's interested I can you know kind of prototype some some things to see really how much better code size would be handgas with M Copy as opposed to the current state of things where we have to you know issue you know a bunch of a lot of other stores in Androids which is in my opinion kind of wasteful especially when we have called Data copy

and code copy and and and the the semantics of it are are pretty clear to everybody too I think so okay yeah I think that's the case

Tim Beiko: got it thanks uh Andrew

Andrew Ashikhmin: um yeah I have a question about um uh Faith the pay of code versus the um proposed call to app code does code 2 also suffer from the re-entrancy problem

that's uh pesos

Charles Cooper: uh as far as I know call 2 doesn't

really change anything except uh gas observability and it removes the output buffer so yes it still transfers execution context The Colony which is the fundamental problem with transferring ether using any call off code

Andrew Ashikhmin: understood

Tim Beiko: okay

Charles Cooper: somebody asked them yeah uh if there's the transfer property of self-destruct self-destruct transfers all ether pay allows you to send some amount of ether and it's also a lot less wasteful in

terms of gas and um I suppose touching because you don't have to create a straight contract

Tim Beiko: okay so I think yeah given like the the points Marius raised it probably makes sense to not include pay for now um and I know uh yeah I guess I'm curious to hear on the M Copy side from client teams um get seems to have internal disagreement about whether to include it

nethermine seems to be leading towards not including more in the fork um so I don't know yeah do any of the team feel strongly in favor against including

M Copy

Lightclient: I really don't see the arguments for nothing including M Copy it's extremely simple and it makes the functionality we already have with the identity contract is it a game changing feature for ethereum it's not but it's a relatively simple thing and if we want to have any chance of doing a lot of the changes that we're trying to do in the future then we need to be able to like do more than just like the one thing that we want to do in the fork

and so I don't think I'm copy is adding that much the service area

Tim Beiko: and I I think there's a couple comments in the chat about so Basu has a PR for M Copy but then maybe uh yeah maybe it makes more sense to be bundled with eof and then Marius is asking if anyone looked at memory expansion attacks would copy all right Charles I don't know if you have an answer to this

I mean why would it be any different than with the identity contract

Marius van der Wijden: uh it's not it's not and we had I think

we had uh issues with the identity

Lightclient: that's that's what these are like separate things and like if we have a problem with the identity three compile then we need to sort that out

Charles Cooper: no I think the issues one of the issues with the identity pre-compile having to do with having to you know transfer execution context to the identity pre-compile and transferring call frames and stuff um so I think copies actually simpler than the identity copy here

it's

Danno Ferrin: yeah it's definitely simpler the memory expansion attacks on M Copy is the same surface as M store and M store 8. it's all about where the highest bit of the ride ends in the copy

so it doesn't truly open up any new novel surfaces it's just the same well-trodden surfaces from my perspective

yeah the

Charles Cooper: um yeah exactly and also called it a copy and uh code copy uh of the same surface for rights maybe not reads but for for reads the the surface is the same as M load and identity copy sorry if you have domain preview file and uh because it's priced the same as other uh copy operations

so that's

Marius van der Wijden: basically what I was asking if

someone has already looked at it and you guys seem very confident that it's not an issue there is a there is a cost which is memory expansion costs right

Tomasz Stańczak: but there is no quadratic cost on the length of copied in the proposed solution so if you if you copy a lot of words then you have just linear increase of the cost which opens potentially attack if you cannot load to memory just that particular copy even if you copy in the same place so you don't have memory expansion cost at all because you're not expanding memory but you actually expanding a lot to Temporary memory needed for the VM right

or you're doing it by

work

Charles Cooper: no you're not uh the spec is written it says that memory expansion works as if you copy to a temporary buffer but all real memory copy implementations uh just a branch to see if that there's overlap and if the overlap is a certain way then it copies backwards instead of forward so there's no actual temporary buffer happening

Tomasz Stańczak: okay yeah so at the paragraph perspectively doing word by word copy okay thanks sorry

but no it's a reasonable concerned

Tim Beiko: maybe uh so on get

invasive seem somewhat split on this dimash uh you said that you'd rather not have new things in uh in uh okay you're neutral now um I don't know

Aragon do you have yeah uh neutral

Danno Ferrin: it can wait for eof if there's not if there's if there's it is a fairly laid ad and with the with the pushback I just don't think it's worth pushing it through

Tim Beiko: I guess there's anyone still strongly

feel we should include it and maybe one option is um if the concern is mostly around the scope of the fork um does it make sense to leave that as like the one CFI thing Implement everything else and see you know how we're feeling in a couple weeks uh in terms of implementation or if we wanted to do this should we make the decision now so that we can start setting up uh both testing and like implementations that supports the entire scope

we'll need tests

Danno Ferrin: but I think the block

pre-compiles are more important than these tests so I need to be prioritized in order from the testing team

you mean the begin root pre-compass yeah

Tim Beiko: yeah oh uh okay so that uh I think people are like at best neutral around the EIP for the fork and I guess two options is one we just push it back to the next fork and another option is maybe we um leave it as the only CFI things and we

see how implementation goes with everything else and whatever we want to add it in a few weeks

Lightclient: yeah I feel like if we can't do in copy in this course then we have no chance of doing eof ever like the surface of the eof is quite a bit bigger I think than what we're facing right now in terms of these so I would prefer that we try to do in copy now and try and just understand like is the surface too big like we can always remove it later on if we're like is it just people feel uncomfortable with this costume surface because that's been the biggest thing that I've heard so far is that it kind of the increase of

thrusting surface makes people uncomfortable and I would rather go down the path and figure out what happens in a couple months if we try and implement it put it in the forks do the tests and if people still feel that way in a couple months and then if they do then would you remove it

Tim Beiko: but if we don't do it then we're never going to be able to see the exchange uh tomash do you still have your hand up for your previous time or do you want to add I see you have

Tomasz Stańczak: um lower my cancer I wrote in the in a chance that uh well I agree with the

reasoning of light client that this seems to be um simple reasonable change in line with many of our goals like a week away from pre-composed or going towards cof so for that reason it perfectly makes sense is an AP and the only reason why I staying potentially now is if the teams feel like we don't want to add more things to test more things to to cross-test so it's more of a scope of the fork question rather than the EIP itself

Lightclient: right yeah I totally get that and I am the same boat around these things but I think that we need to test ourselves a

little bit if we're still thinking about having you on the roadmap because if we can't like again like at least I don't think we're gonna build the surfaces area for UOB is quite a bit larger in the evm than what we're facing right now and to me it's like if we go down this path and we think this area was too big we had to take out in copy the last minute that's a pretty good sign that we're probably not going to be able to do eof and maybe we should like just make that decision

Tim Beiko: I guess uh yeah so uh based on Lucas's comments um I'd be curious to hear just like from the testing teams um I don't know Mario Mario if you're on um and yeah

these oh yeah I see okay uh Mario Vega like yeah do you think M Copy significantly like slows down testing efforts or is it reasonably simple to write tests for

I

Mario Vega: I think we can definitely paralyze at the moment um the problem might be that we also have um hype testing for example for 404 so that might so if anyone wants to jump in to test and copy uh the status I mean it's definitely welcome two so I don't see there's I mean Mario's had some garments that the scope might be to grow but I I don't think I totally agree

um in my opinion it should be doable but yeah any and if anyone wants to jump into to implement those tests those the state tests or M Copy that that would be very nice

Tim Beiko: and the state tests are the one using the new python execution test right

Mario Vega: exactly exactly so we um let's do is we have to implement status for um this 48 488 so I'm sorry 47 888 and we already have a test for 48.4 and we have to translate the 1153 tests uh to python so that's the the remaining to this in in terms of status for execution

layer um I think we can do and copy but um yeah if anyone wants gambin also to help with this that's obviously gonna help a lot

Charles Cooper: uh I think probably from the Epsilon team was uh designing uh the tests and was starting to write them up but I uh just being here to see uh what the progress of that is

Tim Beiko: okay so I guess based on all of this does it make sense that add M Copy in

and then in the next call or the one after if we see that like you know testing is like bottlenecked by it and or client implementations feel like it's I don't know too much to add we can always remove it so like we can prioritize basically implementing um 4788 and all the other eips that are already included um add this one as well and then you know if it is a relatively small change we keep it in but if we find some um yeah significant cause of delay um then we should consider pulling it up and also by doing that close the door to anything else being included in Cancun

Mario Vega: yeah sounds good to me I mean we can give it a try to just see how how much it will remaining this this we have to implement and then we can give an update into two weeks and see if it's it was too much yeah yeah we can simply remote sounds good

Tim Beiko: any objections or final thoughts okay so uh we will add M Copy in um alongside 4788 if in a couple weeks we feel like M Copy is like significantly slowing down things either from an implementation or testing perspective or just kick it out

and we also will not add anything else to the fork so this means the fork will effectively have um 1153 4844 6780 um so the transient storage block transaction self-destruct removal and then today we've added four seven eight eights that we can block roots and then M Copy and then there's three other things that were CFI um are just not included in this fort yeah does that make sense to people what else do we have on the agenda um okay next up uh yeah Mikhail I you

had this change to the engine API we discussed uh I don't know if it was last week or three weeks ago on ACDC about uh having a single structure a single method sorry for the V3 engine API calls you want to give some contacts on that

Mikhail Kalinin: yeah thanks to the edges real quick um update from that so we decided to move with uh one method one structure approach since we three since Cancun so this is the DPR uh it has a couple of validations that your clients has to do uh police everyone take a look any objections to how I expect out um surprise them as I'm aiming to merge this early next week and

after this gets merged we can outline engine apis back for Cancun which I guess will include a couple of probably a couple of other things one of them is deprecation of exchange transition configuration that people were waiting for but one time now there is probably the Builder override flag which worth discussion so that's it so please take a look at this VR um those who are interested

Łukasz Rozmej: yeah I have a question would it be

reasonable to I know it would be a breaking change to also apply it to V2 uh to like not allow the Wonder uh I know it's a breaking chain but it shouldn't break anything we already passed the fork everyone is using it too so

questions

Mikhail Kalinin: yeah I wouldn't by default I would not change this back that is a little bit of serious final life uh the the main goal for this change is uh that it prevents us us from uh ever growing complexity of support in all versions that we had before and I think that for v2 we can uh remain it we can

just leave it as

is

Łukasz Rozmej: okay it would slightly simplify our code base because we had this generic uh way of doing that and now we will be specifically um yeah it's fine and I think Never mind already has this implemented as your proposal right now so we have it

Tim Beiko: any other thoughts comments um okay so and then last thing we had on

the agenda this is more of a CL thing um but uh basically Enrico wanted to chat about uh honest validator behavior for data availability um and Duty production uh do you want to give some quick context there

Enrico

Enrico Del Fante: yeah sure um so I was bringing this up because I have this I remembered this conversation around we probably Discord with any other guys and the implication of that could have some engineering implications which do do one way or the other but point is

that should we uh start uh validating a testing and producing blocks uh before we actually have downloaded all the blobs up to the very end of the availability window or we could start doing duties once we reach the head and downloaded everything because from the spec at least uh things I remember before we could consider everything valid only until we have the entire uh datability window downloaded and very builted am I right here

Danny Ryan: yeah so based on past conversations and based on how the spec

is written right now you would be short circing short circuiting the validity condition um if you started a testing before um and it's not the intended Behavior so I believe that that's how the honest Behavior would read based off of the is date available function but if that's not clear I think we should

Enrico Del Fante: so actually they said the use the ux will be slightly uh affected here if you have if you wanna for instance switch uh CL and you just just remain with the same yell this is already in sync then you wipe out of the

base which means that you can checkpoint thing quickly reach the head and then wait the full to be downloaded and the client should start behaving like we should download all the datability as quick as possible while it's not just an historical thing that currently is is kind of low priority download background we should start changing internally how how the client behaves there because we want to to reach the availability boundary as quick as possible right

Danny Ryan: so I mean you could imagine some like local

ux affordance where you could just dump that data and import it directly if there was actually like a if this ux you thought was like really high priority um but I do think that if we don't do that da Check and kind of just when you're when you're initially syncing then we kind of like begin to break the uh the honest behavior um not radically so but uh we're putting a chip in it in a way that I think could not

true

Enrico Del Fante: right okay so it's an item that we actually have to work on because yeah

Danny Ryan: what's the amount of data

on the current window

well

Enrico Del Fante: gigabytes don't have the number at the moment but we'll be yeah three days 33 gigabytes I don't know it's calculated on four blobs

yeah is that three six or four two four so yeah it

Enrico Del Fante: will take some time and yeah it's kind of yeah it could be felt by by the users for sure

yeah

Mikhail Kalinin: how many people want to think about the for this data 30.

I'm just wondering how much time it will take for this data because there is the El uh client which is sinking as well so it probably won't be yeah yeah

I'm

Enrico Del Fante: I'm focusing particularly if you already have an ear that is up and running uh if you if you have to think both of them definitely you still have to think uh the L2 uh probably they will the year will take more time but there will be contentions on the bandwidth for sure so yeah everything will be

slower

Tim Beiko: okay I'm not 100 sure what the right

next step is here yeah let's pick it up on the third call

Danny Ryan: um yeah if they're you know there's a ux that we care about then there might be some like standards around dumping and porting data and stuff um but I'm happy to pick it up there when we have more people with context

Enrico Del Fante: well the the action point here is maybe make things definitely uh clearer in the validator honest validator just drop them a real line it says clearly okay

Danny Ryan: at least for my understanding maybe yeah I can put up a appear under that just I think it's implicitly clear with the the definition of the function but a note that just says you know note thus you must backfill

um yeah as you can consider a considered valid until all valid blobs have been downloaded

Enrico Del Fante: what do you mean by all in this case could be related to the blobs that are your marketing at the moment so the for the for that block by all here is intended by all blobs for in for the entire developing window

Danny Ryan: yeah and I um I'll do a pass on it just to make sure language is clear you know based off of a handful of iterations that might be as you point out not so clear um but I'm happy to do that

Enrico Del Fante: yeah thanks

Tim Beiko: okay so Marius wanted to talk more about

the blob number um we can do that but right before I guess uh Barnabas you wanted to give a shout out to the new testnet call next Thursday so we can do that and then if anyone doesn't want to chat about blobs uh wants to leave they can drop off and we can use the rest of the call to go into more blob conversation yeah Barnabas

Barnabas Busa: yes we will have our first uh key call next week on Thursday at 12 30 UTC time and we will see a client everyone at least one person from each

client team to show up uh to this we would also like load operators to auto shop in this meeting

Tim Beiko: um is there a oh I guess on the call you're going to decide when Genesis would happen for the network

Barnabas Busa: yes we expect it to happen on

Thursday

Tim Beiko: we we should still consider Gordy and sepolia as like the main pestnuts and if like there's a world where uh then

kuna's already happened when this goes live maybe not but um if this is gonna go live in September we shouldn't count on it as like a test match for this Fork correct

Barnabas Busa: uh well I assume then Kun will if it doesn't happen before September then we can also use this does not to test thank you also right

Parithosh Jayanthi: yeah I would actually say that we should definitely use this one because the idea is that this test net this is bigger than girly and bigger than me net so it would be the first opportunity for us to test like how we perform with the last number of validators

Tim Beiko: in that case and I unfortunately I don't

think I can make the call because it's 4 30 a.m I think my time um but uh I would potentially push to start it one or two months before September 15th um so that we're like if yeah if we're ready to Fork a first test net or second test net in the summer then um having uh this one ready would be would be good

Barnabas Busa: uh we would probably need uh I I don't think we would have the time okay multiple months before the September deadline because we would need like

proper client releases and uh through this quite some Organization for this because we plan to run our values or set them in that uh significantly larger and for that we like playing teams will probably need dedicated infrastructure uh running so this is going to be a significant uh deployment and got it requires quite some planning so this is why it would be very good if we could have someone from which apparently shot in this call next week because we're gonna discuss the details

Tim Beiko: okay sounds good any any kind you have thoughts or comments you want to share

if anyone wants to not talk about blobs more uh this is your chance to drop otherwise uh Marius you had some comments saying the get team felt uncomfortable with uh the three six change

Marius van der Wijden: uh yes sorry um I I joined five minutes late so I missed the discussion at the beginning of the call um well apparently this decision was made yes so I have prepared a statement no I've not prepared a statement

um but the thing is we during these tests we've seen that with uh one megabyte blocks we start to lose attestations quite quickly um what this suggests to me is and these blocks are possible right now what that suggests to me is that we already have two big of a of a of a gas limit and it could already be the case that if someone would would send these big blocks for an extended period of time

um then a lot of nodes would not have enough time to to attest to them and thus we would lose a lot of attestations

Dankrad Feist: now there's no indication though that um this is like so yes we lose attestations but why do we lose them it is only due to the reason that um these blocks are late like that they arrive past the four seconds um Slow Time and blocks arriving very close to that already happens like I mean look at look at those graphs and see that even outside our tests you see those late blocks not quite as like but like very close to that and you

see drops and other stations

Marius van der Wijden: yes

Dankrad Feist: so I think the argument here is not that this is too this is this is like there's no sustained effect on the network like all those notes are well able to catch up with the network they just see that particular booklet so I think um the case is actually just that our four second deadline is too aggressive and not that this is too much load for the network

Marius van der Wijden: yeah but like we have that uh four second deadline for a reason right

but we can change it

Danny Ryan: I mean I would actually suggest that well but we do not have we that's a

that's not something we do tomorrow that's not something we got a lot dated on

the time

Dankrad Feist: like I mean I want to push back against the the claim that this is not stability of the network okay but it is very aggressive that deadline that we have

Danny Ryan: but so I think the strongest argument here is that when you increase the um the target of large data payloads which you do with blobs um so you would regularly get that you decrease the cost to push that over a threshold with call data

Marius van der Wijden: that's exactly my point um like we can do this right now and the only thing that is prohibiting us from

creating these Big Blocks is called and with 4.4 we make this attack way cheaper um we all like we we have to all be like clear about this like this this is this is the case and we're fine with it um and I'm also fine with decreasing the cost for this attack because I don't I still think this this attack is kind of extremely costly and cannot be sustained for very long but I think India we just have to be clear about this we're making this this attack more possible than it is right now and uh with increased blocks uh plop

count we make it even uh even easier to do and uh so my suggestion would be to start slow with uh 2 4 which is already kind of high in in in most cases and um and then we can if we see that this works uh reliably on Main act for a long time we can we can increase it

Dankrad Feist: yeah I think this is yeah I mean I just think that's it's too conservative like in my opinion even three six I mean I'm pushing for that because I I've seen that this worked reliably

but I know that there's a lot of demand out there there are so many teams right now building on those blobs and really wanting those and we already violated delivering these like it's uh it's just like we we're always making the most conservative decisions and like it's like

yes because we have to I and it's like a it's it's a it's a billion dollar ecosystem and if we make Rush decisions and we we realize that um 10 or 20 of the notes are falling off the network because they cannot reliably um follow the chain anymore then that is really

Dankrad Feist: there's no reason there's no

reason that indicates what you're saying that is completely wrong like I would like I I think that's ridiculous like we haven't seen like a late attestation doesn't mean that you're pushed off the network a later station just means that you miss a little bit of your report you're still finalizing the chain and so on and that the block has a higher chance of being weird yeah that's true but I mean I would suspect that in this case where this happens because we have seen like a 1.7 megabyte block that was included no problems so there's there's a high chance that this proposal already had other problems going on like

they're probably only published there maybe maybe they're actually like gaming Mev and published their block two seconds late already and uh in this particular instance it went wrong so I don't know um and you've had your hand after a while

Ansgar Dietrichs: yeah I would say just in terms of um process here I think marius's concerned and someone warranted at least sounds to me like but given that we debated this quite a bit earlier and there was I mean even some people in favor of right um I think I'd personally been like be against walking respect now because some people have also already left the call and um we can always change the spec uh

at some of the future calls before we actually have the fog it seems like a saying default for the for the test net at least and I think if this is a concern then I think we should just in general study potential ways to address this the potential change of the second window also I think a potential call data cost increase a small one for um concluding might be something you would want to consider um but I think walking in the earlier decision back now would just not be the proper process here

Tim Beiko: well I guess so on the process but like I think you know we're still in the main call time and I think pretty much all the 444 people are still here but um the the thing I'd want to avoid is like if we if we drop

it's like doing having clients do useless work of like implementing the change and then reverting it in two weeks

um so yeah so

Dankrad Feist: I mean the change is just changing a constant right

Tim Beiko: right so I I mean if that's if that's the case yeah I'd probably lean towards we keep three six for the devnet but I do see maris's argument where like the devnet is not going to tell us about the potential concerns with sound magnet right then I don't think we're going to resolve that in the next like five minutes but we can discuss it on

the call Monday potentially

Marius van der Wijden: so I'm I'm not against um having the definite with three six if um we don't take this as an indication um for a minute because it's it's useless like it's it's just like it's just different uh for

my net so um yes so does it make sense so Marius

Dankrad Feist: I mean my character came here if you're making this argument you should make the argument that actually like we should limit current blocks much more than we should limit blocks strange that we're making always these decisions

we are always much much more conservative on whatever new we're introducing compared to all the existing stuff that's already like pretty

dosable yeah

Dankrad Feist: like I'm sorry like like the same Force why you're not so coming to the same Force out here and say we should limit blocks to 700 kilobytes because then I will take you more seriously but this one I feel like it's just it doesn't make sense to me

Marius van der Wijden: that's nice of you if you if you take me more seriously then um I've been saying for for for for for a really long time that 30 million guests is too much and it's a lot

Dankrad Feist: um sure but I mean clearly like the

ethereum like Community as a whole has not considered that to be what the direction they want to take argument now it seems not fair that suddenly all core deaths override the ethereum community on this in the case of blocks that's clearly like if this is the case then maybe we should um we should add the voting to the network on blocks the same way it works on gas now and let the community decided what they're comfortable with

Tim Beiko: by six months

yeah I think like so I actually we're not going to resolve this now I do think like it's probably worth going ahead with the three six on the devnet um and then maybe using the call the 444 call on Monday to focus on specifically what we would want to see to convince ourselves that like this is safe for mainnet if there's anything missing I don't know Marius if you can be there on Monday or someone from guests can be but yeah I think it probably makes sense to have like a longer discussion about that there yeah Lucas uh

I'm not sure how serious of a suggestion that was but we currently vote on the gas limit which is basically the same thing right okay anything else before we wrap up okay well thanks everyone um uh so we decided okay we're keeping three six for the devnet we'll see whether we want to make this um the main net constants and we can discuss on the 444 call Monday uh what potential issues there are with making three six

um yeah uh moving 360 maintenance sweet anything else okay well thanks everyone talk to you all on Monday

thanks a lot thank you thank you bye

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