All Core Devs - Execution #197

Transcript

[Music] J oh

for

Tim Beiko: okay we're on welcome everyone to acde

number uh 197 uh basically two big things to chat about today so first is uh laot of implementation and minor spec updates on the Petra work I think it makes sense it first go through this make sure we're all on the same page realm uh where things are at and then next up um talking about the Petra um the Petra scope so we discussed splitting the fork on the last call it seems there was some rough consensus around um around the first half but then a lot of uh open questions around what to do about the second half uh many people and teams have shared their thoughts since then so we can uh have a discussion around that

um then a couple minor things throughout as well but those are the two big ones um first I guess to kick us off uh does anyone want to give an update on where things are with def 3 right now

Parithosh Jayanthi: yeah so we've had d three running for a bit now and um there has been the te airon fix that's already been deployed and I think the te team or the Aragon team was looking at illegal State exception that's happening there um besides that Lighthouse has a state rout mismatch I've um it could potentially be a memory issue on the Node but yeah we

still have to figure out what's going on there uh besides those two points um there's one sort of deposit test that uh philli like PK has done from the team and he's uh written down some um some observations here so please have will look and I don't know Philip do you want to maybe say something about the deposit test

uh yep

I do um so yeah um we basically tried to fill up the pending um uh deposit queue on pectra with 1,000 pending deposits to see how the network behaves and um we expected uh increase of the EO transition times because most

clients need to uh recompute the hashing times uh 100 100,000 and um yeah that could already also be observed but uh most significantly is that uh KATU showed uh quite badly increased block propagation time during these time frames and uh we are not sure where this is coming from but uh yeah basically further investigation is needed to find out to rot case here

Parithosh Jayanthi: yeah thanks um and mik's um already I think posted uh change in the consensus

specs that should potentially help with this so we will be like redoing this analysis um uh once once some PR's done or if there's some new proposal uh or rate limiting or whatever we choose we definitely want to make sure that this is not happening before we um we start doing I gu more public Deets Etc um even though that 100,000 deposits is a large number especially because main net has like 1.1 million valid or 1 million validators but still uh it's a it's something we've observed for now uh besides that we've slowly started planning for devnet 4 um devnet 4 is essentially the same scope as devnet 3

along with a bunch of open eips um ideally with everything related to Builder also with the me workflow also included um there's a bunch of open PRS as well as um yeah clarifications so please have a look and I guess we should first focus on merging those in and finishing the discussions and uh ideally we'd have spec releases done after that and we can point to the spec release for um for the deet uh timeline at least in my head is roughly 2ish weeks unless that unrealistic

Tim Beiko: thank you

um yeah any of the client teams want to chime in on some of the issues we've seen on them 3 or um yeah feels like it was pretty clear um and yes so there are a couple yeah there are a couple uh I think open PRS that people want to discuss on the call so we can uh we can cover those as well um I guess one so yes so we covered the big Q test one other thing uh I think is important as we head to devet 4 is the BLS 12 381 repricings I don't know if uh all the teams have had time to run the

benchmarks um and if someone's like looked into the results of that but if we are to change the gas prices we should try and do it by the next devet 2

Jared Wasinger: so uh just speaking uh from benchmarking gu I would personally say that uh increasing the cost uh 20% across the board would be the most aggressive that I could see the gas bottle still being uh not heavily underpriced um so right now that's what I would opt for

yeah

Gary Schulte: from the basus side uh we've been

doing a lot of uh benchmarking with different Library options and it's it's a little bit difficult for us because a lot of the kind of gas targets are based off of uh kind of a relative performance of EC recover and that's uh one of the precompilers we've identified that we need to optimize so I I think something that's going to help us with giving a flat Target for gas pricing is an agreed upon uh machine metric that that we want to perform a specific uh you know megag gas per second for the BLS pre- compiles specifically the MSM promiles um just initial um benchmarking seems to agree that it is underpriced on what seems to be

um somewhat agreed upon Hardware like using um a gen 11 Nook and like an M1 uh arm machine it seems to be that uh our our initial benchmarking agrees with uh gu that it is underpriced but getting a specific Target is I think it's going to be better to have a specific Machine Target and mega gas per second rather than kind of a relative performance metric for us

thanks anyone from uh W Aragon or nethermind

yeah for uh NE mind um I think uh it was uh Jared from gu proposed potentially doubling the

discount costs uh and based on our initial test with the uh the state um tests and we would support that um because the MSM particularly the G1 MSM uh pre-compile seems maybe underpriced uh but we're seeing quite High variance between tests um um so yeah we need to um look into this further we're going to test out with our own uh bench marking framework to verify the accuracy of the state test uh benchmarks

Tim Beiko: thanks anyone from Aragon or W have time to look into

this

Andrew Ashikhmin: yeah we are at a team offsite so kind of we've been busy with that but for us the results should be very close to those of gu because we use the same uh library and pretty much the same implementation

Tim Beiko: okay and on the red side

uh we did not have time to look at it unfortunately yeah

Tim Beiko: so I guess maybe one thing we could do to move this forward especially if we want it for devet 4 and that um we uh we expect a ship def at for in like 2 weeks is it

seems like everyone agrees that these calls are underpriced um and at least nevermind agrees that like you know the the original proposal of dubling is is probably directionally right so um Jared would you be open to just could you open a PR against the EIP effectively proposing the doubling of the chain of of the gas costs and then we can sorry go ahead

Jared Wasinger: uh no sorry continue

Tim Beiko: I was going to say if you can open the pr this way we can track it as part of the definite for spec and then by next week on even though it's the CL called uh if we've had time to make tests on like more standardized Hardwares uh more

standardized hardware and um also get some numbers potentially from from rest um we can determine whether like those values are correct but um yeah assuming that this is all like the information we get then we can just move forward with the the first proposed the yeah repricing

Jared Wasinger: yeah sure that sounds good okay

Tim Beiko: thank you anything else on the uh BLS repricing okay and then yeah let's uh yeah let's discuss this um actually yeah so there's a question in the chat about what's the hardware that we recommend um I don't know Jared do you have thoughts on this

Jared Wasinger: um

not really no um I I know for several proposals in the past we've just uh I mean the mod XP repricing comes to mind we've used EC recover as a base but I get that that's not that some people are against that um yeah but no I don't I don't like have a I can't I don't have an opinion on what the specific Hardware should be for a Target right now

Gary Schulte: I think mer had made a a recommendation uh or like had a concurrence of recommendation of like an Intel Nook um 11 as a baseline with a 50 megag gas per second target 32 pairs I

think that would be like coming up with that as a as a standard would be pretty reasonable anyone we're also seeing architecture

Marius van der Wijden: where did the what is what is we what's the r for that

Gary Schulte: for the for the Nook as as rationale I think that's just a common

uh solo taking rig as as a baseline um I don't think that there's going to be many many uh validator nodes out there that're running any on on Hardware lesser than that

Tim Beiko: okay and there's some discussion in the chat about the version number um and yeah we should probably test multiple um architectures um so I guess maybe yeah the if if teams have the capacity to to test it against different architectures

um and at least like report those tests that would be good um I think the more data we can get um the better um but yeah if we can prioritize this in the next week or so that'd be really good so that we could actually make a call definit for not be changing the gas prices uh forever um and yeah I'll let people continue to debate in the chat exactly which uh Nook version to Target anything else on the repricings okay um okay next up as

something that uh uh uh actually Mikel is this something you wanted to be considered for devet 4 your PR about making the execution requests a

side car

Mikhail Kalinin: um yeah probably foret for but generally to GA the feedback and if we want this um this design so we need to do some more work on theps and smart contract okay and yeah actually ideally if we if want this um kind of design yeah we would like to have it for the net for if possible yeah so yeah so the um I can briefly go over the um the proposed change

yeah I think

that' be good thank you

Mikhail Kalinin: yeah yeah Okay cool so this is uh the slight or not yeah it's just an improvement on upon the ideas that already uh were uh proposed previously by fex by client um and um uh some others uh okay so what what this PR uh is is doing actually is the it it proposes the design um of the request that will be as less impactful for El and which allows to add new type of requests as smooth as possible um so the what exactly proposed is the the

first step is to remove the requests from from execution layer beon PL body um and uh entirely serve these request as a side car uh so we had this idea before but now it makes more sense because uh CL keeps the requests aside of the payload out in the B Block um and uh for you know for one of the concerns uh of this approach uh was the optimistic sync safety and to keep optimistic sync safe uh we will need to the request the commit to the list of requests in the El BL header so which is which is fine which is perfectly fine uh

the other part of this uh PR uh um emerged in the discussion with Lucas uh so we want to uh encode those requests in a way that El will not need to parse them at all uh so the proposal is actually to um for the system smart contracts uh to to return the list of requests uh in a way that they are ready to to be served uh to to the CL so it's just basically uh the modification that is required to achieve this goal is to uh prepend the type fight uh before each request entry um and do this in the uh smart contract implementation so this is

doable and I think it's it's not difficult to to to have to have this implemented so then the the El uh gets these requests list from from each of the smart contract uh concatenates them instead of using rlps just concatenates them uh in a list this was proposed by Felix in the in the UniFi request objects PR to the engine API to use this encoding and this this UniFi request list is used in two places first it's it is uh used in the engine API to s for is the request to CL as is um and the other part is that this exact list is used to to compute this

request hash commitment which is put into the E block header and that's basically it so adding a new request type would be a matter of implementing the smart contract and just saying that this is a new request type to to e and the L can handle it by some generic code um so that's that's the it uh the design yeah looks quite quite good to to my opinion and yeah that's it uh and it would be great to get a feedback from yel devs and yeah whether it sound or how does it sound to everyone and uh from SE as well so SE will need to par those requests

from from this um kind of um encoding uh yeah so that's please take a look and oh if we decide to go as I said we need to change the system smart contract we need to update the 7685 EIP uh which is the generic request type so that's that's kind of like the changes that are not done by this PR and just announced there I'm happy to yeah to do this yeah cool Alex thank you

Tim Beiko: thank

you

Mikhail Kalinin: um uh sorry if fex like client want to elaborate on this or you know just provide your comments please go ahead

Felix Lange: so I think it's a great one um The Proposal uh because it means that we have to care even less about the request in my previous proposal we still had to uh know about the output size of the contract objects in order to be able to split it into a list so this is now also removed from the e basically it's just even less knowledge about the about the contracts um and um yeah like you mentioned in the pr the deposit contract is a special one but it's also kind of

the the OG system contract so I guess it's fine if we have to handle it a bit special as the only exception for now and um yeah so I think my big question would be like if it has really been determined that it's fully safe uh for the for the sync because uh yeah with this design I mean the basically the idea behind this design was also a little bit to make it so that we handle the requests in a similar way to how the receipts are actually handled so the main motivation here is also that within the ethereum block body like within the block body we do not actually have the

receipts because the receipts are an output of the block computation and so the receipts uh the the receipts are a separate entity uh and then uh so however the but we do have the receipts route and this is similar here so the request have the request route within the block body so uh I'm a bit curious how it's going to work during the sync if we will be if we will have to somehow sync the requests as a separate object or if they are fully like if it's totally possible to just not have the requests at all within the El after the sync so technically we

don't need them they are only for the CL so I guess it would be fine not to sync like during the snap sync for example we would not sync the the requests and therefore we would not be able to validate the request route however for the blocks which are provided by the CL we would be able to uh verify the request route

Mikhail Kalinin: Yeah so basically this uh uh re request hash U has has to it will be used in in in two places uh into validations first is the block hash validation so the CL gives uh El uh uh the receipts uh the E computes the

receipts hash um so the computation is incapsulated in E how it's it's the how it's done it's completely up to L in this according to this proposal uh and then uh this uh the obtained uh re receipts uh uh sorry request hash will be used to compute the block hash um and validate the block hash so if the requests passed from CL are not the one that are that the El is committed to the B cash validation will fail uh the the other part uh is uh the other validation happens uh upon the block execution so the requests obtained from the Block execution will also need

to be validated against this block commitment and if yeah if the block execution gives you uh some different something different than that the block is committed to so the execution of the block will f and these two validations actually um makes us safe uh during the optimistic sync where El runs blocks on its own and uh uh and it can validate the the requests obtained from the execution against the request hash and the same is is done by CL right so the the commitment is validated from both sides so that's that's it that's how it should should work uh and snap sync of course

no uh there is no kind of like you know these chats and yeah it's fine

Felix Lange: so there's no need to download them during the snap swing we basically just don't have to have the request at all for the the okay that's exactly yeah I think

question yeah

Potuz: yeah put M you're proposing so this this request the side cars are going to be gossiped on the CL side and you're proposing this for the next

devet no no no no

Felix Lange: no there's no gossiping of requests um so the thing is that the requests are purely created when the block is executed um it's just a mechanism for for the

um basically every node computes the request on their own because um the the only way in which requests can be generated is via transactions so in fact we are already gossiping the requests in a certain way they are just encoded within the

transactions

Potuz: oh I see but then how how will the CL get the request is this going to be on notify new payload

Felix Lange: yeah basically will get it as an output from the

e

Mikhail Kalinin: yeah c will will get it on the get payload but separately to the payload this is why it is called the

side car

Potuz: no okay so I'm still lost so how will the CL sync a block over gossip will when I

get the block over gossip will I be will I have this request immediately or would I only get transactions send it to the L and then from there get back the the the requests

Mikhail Kalinin: no but you you will get those requests as a part of the

beon blog

Potuz: oh so that that the the proposer will pack requests on the body as it is now

Felix Lange: yeah

yeah yeah yes

Felix Lange: the main problem that we are trying to address is that in the previous like another problem we trying to address in the previous design is that the requests are duplicated so in the previous design before the pr from mik the big problem was we had the um we had the requests in

the El block body and we also had them in the CL block body and I mean technically it doesn't really matter because um they can somehow be discarded or something but it's just kind of a messy thing to have the same object with like slightly different semantics in the two blocks and so with this new proposal they are only in one place which is the CL block body and that's kind of where they have to be as well

Potuz: okay and and and and and this will be constructed one on get payload it's going to come back from the engine yes as separated from the payload but okay perfect this is exact PVS okay this is exactly asvs so this is good I like

this so

Felix Lange: it's like the it's like the

ultimate requests design like there's no no better one

Parithosh Jayanthi: um and this something we want for the next evet or are we waiting for a few more weeks for people to comment on it before we ship it on a

defet I mean I don't really know

Tim Beiko: people like it in the in the chat um I guess does anyone have an objection to bringing it bringing this in for the next fnet because if if everyone is happy with it then yeah we should make the decision right now and this way we can update the specs update the contracts update uh testing um but yeah

does anyone have any concerns or objections with

this

Mikhail Kalinin: there might be some objections from CL but I'm not sure I mean that yeah they have to do more work which is fair because T is the consumer I mean like have to do more work by just you know decoding this

Potuz: wait what's what's the extra work here I thought that on get payload we're going to get these requests we're going to just import them locally uh what's the

Mikhail Kalinin: yeah previously there were some discussion in the uh there was some discussion in the pr about like um encoding particularly of the request

so that the C has to parse some you know some some encoding that is not generic like it's not entirely as it's ssz but it requires unions you know this this kind of discussion

Potuz: yeah so that that I think we have already like relented and and and accepted that we can we can do the parsing as long as there's a commitment of not using unions then in

s

Felix Lange: yeah so this is one of the things in in mik's proposal that is going to be really interesting because they now the requests are just going to be provided as a single bite array and the that has to be parsed by the CL and I mean it's a it is let me just put it right I think

it's okay but it's a custom format so what we're talking about is basically it's like a bite array where you have these type containers and you have to keep checking for the first bite then you will know the size of the next object based on this type bite and then you can basically take it out of the list I think it's a it's a great design honestly it totally works and it's the simplest possible way to send this information but it definitely requires more passing on the CL side than it ever did before

Parithosh Jayanthi: and just one more clarification this would supersede light cl's PR to UniFi request objects as well as your PR

to UniFi list of opaque request right so instead of do those two we would just do M's PR

Felix Lange: yes because in M PR it's like we change it changes the same thing again to make it even simpler basically thanks

Tim Beiko: and to be clear the pr that's super CED is this one I'm pulling in the chat right um so this one we would just close

Mikhail Kalinin: oh this this one will need some I don't know maybe some changes but yeah we need something you know

okay oh the E

Felix Lange: yeah we need to update

Tim Beiko: oh yeah sorry yeah we need to

upate confusing across

Felix Lange: all of the r po so we have the the the

engine API and the eips and the system contracts and we all need changes in some way okay

Tim Beiko: so I guess it seems like everyone is in favor of moving towards this um there's no objections it would be great if by next week's call we could have like the final set of PRS I mean ideally merg but if you know uh if not merged at least like a a clean set of final PRS across every single EIP that and the engine API and whatnot that people can review um but yeah hopefully we can do this async in the next week or so um I don't yeah phelix Mel can either of you take this

on

Parithosh Jayanthi: I left a note in the spec do as needs updates for I think there's three that would need updates right there's the um maxb change request to Flat encoding deposits and withdrawals

Felix Lange: yeah

Parithosh Jayanthi: and then I think there's one more uh change request has flat hash

Felix Lange: yeah we need to yeah so the flat hash I'm not actually what is the commitment can you sorry for dragging this out but mik what is the commitment is it the flat hash commitment or is it the no it's yeah it's has to be right because it's just lit it's literally a hash of the whole yeah yeah okay yeah it's it's it's fine by me okay

yeah so that one so this flat hash thing then has to be changed a little bit to just basically specify that it's the hash over like the request hash is the hash over this over this output and um yeah anyway we will get this done I will implement it in the contracts and yeah

aome Oliver

um I seem to recall that right now we're gossiping the requests over P2P in the block bodies should we remove this in this case

Mikhail Kalinin: sorry what do you mean so it's it it's in the blog body in the beacon blog body it still remains

there but not it's it's removed from the execution

layup part

okay yeah that was it

Tim Beiko: okay uh well thanks Felix thanks Mikel anything else on this okay and then uh next up uh so devet 4 want to make sure that we cover all the other uh open questions so okay so there was the pr26 11110 but this we need to change um then there were two PRS to 7702 not allowing authorization non-sql to to the 64 minus one and then

adding a bunch of clarifications to align the spec with the tests um yeah does anyone have context on these or want to uh chat about them let me post them in the chat here um yeah and it seems there some conversation uh on the pr right before the call okay if no one wants to discuss it

we can move on but uh people should ideally uh review this as we uh as we finalize this scope for defet 4 um anything else that people feel is kind of urgent to discuss for devet 4 and that we should get sorted out in the next week or so

Parithosh Jayanthi: yeah I think the Builder spec PR should get some last looks and get merged in so that people can start working on it

Tim Beiko: okay do you mind share in the chat if you have it handy

Parithosh Jayanthi: yeah just it

Tim Beiko: thank you anything else on dev that 4 that we

should be looking into before next week okay otherwise yeah so the two main things are um mik's PR which Felix and him will will will follow up on and then all of the BLS uh repricings um so uh hopefully we we get some agreement around uh benchmarks but we'll at least have a PR open to uh change the gas cost by a factor of two like we originally discussed um and then a bunch of other things that have been flagged in uh the deit force spec already anything else okay and if not uh yeah one quick

thing as well I'll give a shout for is we've uh put up an RFP to audit all of the contracts in um in pectra uh so we have this open now it'll be open until uh October 11th hopefully by then the code is pretty much finalized but we hope to get a bunch of different uh people looking at the contract and uh both fuzzing them doing some static analysis and more um I'll post the link in the chat but if uh you're interested and listening um you can find us on the uh ethereum request for proposals REO and I think that covers everything around

implementations um anything else before we move on to the uh Fork split okay um so Fork split so on last week's call uh it seems like we had rough agreement on uh at least the first half of Petra so moving from what devet 3 was uh into production um a bunch of teams shared some thoughts uh this week so Aragon uh Aragon was like slightly opposed to the idea of uh splitting the fork partially because um one it it would just like grow the second half of things um and

potentially de prioritize veral um I think prism was in favor of uh Fork keeping devet 3 as the the first half of Petra but then also opening the door for um more changes in the second half including potentially the epbs EIP uh and one thing they were explicit about is not raising the blob count in the first half um loadstar um wants to basically uh keep first half as devet 3 as well and then uh basically has uh like yes some proposals for the second half some of which are not already included um nether mind feels strongly about keeping uh the scope as is if we

do the split but it's also fine with keeping the fork in one piece then um vitalic has a proposal uh to actually add something to the first half which is uh a blob increase and a 7623 to bound the block size and then um ref uh supports freezing both half both halves as is um so yeah there's a lot here um I guess one place to start is maybe uh on the first half so it seems like there's a lot of support for freezing the first half of the fork and that's roughly

Where We R the last call um but then uh yeah I think vitalic and uh sorry I forget who was the other one who wanted something else in the first half I think vitalic might have been the only one who want something added to the first half aside from the the the base people who came on to argue for the blob increase last week but yeah maybe let's start here uh if you're on the call vitalic do you want to give the

Vitalik Buterin: yeah yeah I'm here okay I think uh basically a blob account inrease I think is something or a blob Target increase is something that will be extremely valuable and to me the key

stat basically is that if you look at the level of usage right now of blobs it's like basically somewhere around 75% of the Target and I think it's uh important to keep in mind basically that one big difference uh between the uh blob market and the like regular evm Market is that the blob Market is made up of a much smaller number of larger actors and so even though it feels like a nice and constant 75% like I think it is undoubtedly true that there are layer TOS that are consider that

would cons would have a used blobs if more more space is available but are making the decision not to precisely because they know that if they come in then they themselves are going to be enough to make blobs be no longer cheap for both themselves and for everyone else um so I think it's really important to think about like some of those long-term effects and generally the facts that the etherum ecosystem really has turned a corner to the point where ler 2s including blob based ler 2s actually can offer people a sub

1ent transaction fees and this is momentum that is extremely important to build on and generally the ecosystem will needs to SC is scaling and needs to scale and wants to see assurance that it actually can scale and this is uh something where that the L one is committed to going going along with the one um and so my uh s so one um so this is this to me is an argument for um of increasing the blob Target so the reason why I

suggested EAB 7623 along this is because a lot of people's concerns around a blob get increase have to do with worst case situations and currently the worst case block size is about 2.7 megabytes um that which is using call data and E 7623 basically knocks that down to roughly 1 Megabyte and so if we do a blob 7623 and simultaneously a BL Target increase so even some like 2X is uh which is actually more than I

advocated would still reduce the the the theoretical maximum block size by a factor of about a third um so I basically view 7623 as something which which adds a really valuable safety feature um another and so that's uh one of the other um uh suggestions and then another question is basically are there other ways to mitigate some mitigate the issue involving the the problem with like worst cases

and I think there's two other options right one of them is to basically do the EIP that increases the Min minimum blob base fee which basically means that if we ever enter a fe Market condition uh Discovery condition then the period of full blocks would be about three times shorter than otherwise would be so that's one option and then another option is um actually to abandon the idea that there has to be a 2X Divergence between Target and Max and basically say you know either increase the target to four without increasing the max or increase the target to four or five but uh increase the yeah

increase the max to seven or eight for example um I mean or yeah I guess more more aggressively yeah onar suggests a 69 right yes thank you both 7762 is the one that I had in mind there so that would have the Practical effect that if we have if we enter a one of these like Blaha price Discovery periods then the it would like cut the maximum possible length of a period of Maximum usage by a factor of of two3 so I think I mean the reason why we need to think about this is because like if you just look realistically to me it's

just clear that a like just scaling actual us uh usage is just incredibly important and know if ethereum does not offer this then like people will find it elsewhere and people are going to have in secure blockchain experiences that are just not on ethereum right and the it's and I would even argue that like even a 33% blob increase is probably more valuable than like even three of the facts at this point so if you just like look at know the ratio of effort to Value just like the amount of

actual value here is uh uh quite high in terms of uh increasing the increasing the amount of activity that can happen and so I think there's a lot of value in doing a uh T Target increase and at the same time as uh thinking through um like adding like 7623 in order to try to mitigate the effect of this and allow some of other increases to be higher

Tim Beiko: okay thanks for sharing there's

been a lot of conversation in the chat um so I think there's uh definitely one thread uh that the present team raised last week as well around just like measuring the impact of this um another thread is that um basically the idea that uh if if we do uh increase the blob count and we want 7623 and we maybe want the fee Market replacement and we maybe want uh 7742 now we're like at a 4 EIP Fork effectively um that's like starting to be its own thing um but yeah I guess maybe the strongest opposition seems to be from Poes around

like just the the measurements of this so maybe pus you want to share your thoughts there

Potuz: yeah I'm just worried that even increasing the target but keeping the limit which seems like reasonable and and safe but we we have not gotten any data about this we we haven't seen a single study that says how much it takes for nodes to actually be sinking uh recovering from a long reor I mean those are the things that will change because it's not bandwidth on the happy case but bandwidth when you actually need to SN several blocks in a time at a time and it would be nice to see if if this is actually safe uh the measurements that we've seen are based on on average

bandwidth which is certainly not what you need of the tip uh it'd be good to see a serious study that proves that this is safe and then we'll support it but without data it seems that we're just changing numbers because we we just came up with these numbers out of our head

Vitalik Buterin: yeah I mean I'd argue that honestly we have had the study and the study is three working like increasingly fine for 9 months of operation like a 33% increases within range of like gas limit increases that we've done many times uh many times on chain and I think we also just like have to take the uh

like also take seriously the uh other side of the argument right which is basically all of the risks that that come from more blob gas prices going up 10 100 way again like we yeah actually have to balance those considerations at

point and marus

Marius van der Wijden: yeah but it's not really a 33% increase it's it's more like a 66% increase because you're not like when we increase the BL uh we not only increasing uh the limit on the consensus layer but

we're also increasing the average number of transactions up transactions that are sent to the network on the execution layer in the transaction

Vitalik Buterin: right but that's right but that's still a 33% increase on the total load right

Marius van der Wijden: oh yeah

Vitalik Buterin: yeah

okay

Marius van der Wijden: that's true yeah yeah

Tim Beiko: so I guess um yeah I maybe be curious to hear if like other teams share kind of

prism's view around the like measurement issues like um or do other teams assuming like for a second like that we didn't have all the other Petra scope issues like is like yeah do people generally want to see more measurement on on on this or like yeah how how do do we feel about increasing the blog capacity

uh enrio

Enrico Del Fante: yeah we just want to share the we we have some discussion internally about

this and for instance just just a data point to couple of days ago a guy showed up in our uh Discord uh saying that he missed the block and was was a homer uh that F back building locally and he had to uh his local e uh selected six blobs and then he ended up uh being reor uh the block has been reached the the the network fine but then the blobs was not able to reach on time and has been reor and then and this B this is an home Stager and has not very big upload

bandwidths but it's still something that is concerning some of the longtail of Home Saker that not doesn't have enough bounds and uh so I I I think that the target increase to to four is kind of reasonable but I also think that some of the home Stager could have been impact also now and what could be something like having a parameter on the execution layer for these guys that says please if you're if we are about to propose a block please don't kind of limit the number of blocks that uh the local yel will select just

to accommodate their potential upload bound with in this case it could be an option that could be abused for sure but yeah thinking I'm just putting my foot in in in this and any uh yeah my my just asking if that could make sense something like that to to go in the direction of helping those situations

thanks uh we have Francis and ancar

uh thanks guys uh I just want to mention one thing like we are always talking about home stakers with like low

band weights cannot sync like properly but we haven't actually defined a minimum requirement about home home Staker span with like limit like are we going to say that if they have only one megabytes per second upload link and we're going to tolerate that like forever um I guess like what I'm trying to say that we probably need a better measurement or like better minimum spec for the B Network requirement so that we can talk about things like in more concrete manners like not kind of like in like people like reports about okay I have issues but I don't know what your bandwidths and what I don't know what

like

Tim Beiko: yeah like I think this would be

good like the to do we we clearly don't have this today and like if I were doing it what I suggest is something like you look at around the world what is like some median amount of bandwidth that you can get across different countries and what's like the share of countries that you want to cover with ethereum um but yeah I doubt we're going to get this uh today

actually like what one quick uh information about that I actually did a like uh kind of like quick search um so according to like those speed testing sites the medium is about like 60 or 70 megabytes per second upload link um and like for the like maybe long tail of

things like for the two for 200s country it's around like 3 to four megabytes per second up the link um so depends on like how we are thinking about like thinking in terms of like Max like burst speed that is needed for Block propagation it seems kind of like reasonable like within within that range but we definitely need like more concrete analysis of that

thanks um yeah Anar yeah

Ansgar Dietrichs: I just wanted to briefly say so my proposal for what to do today would be that we um ideally agree on at least a Target increase to four um I think the case for that I mean I said

there's a little bit of push back there on the call today as well but I think we have relatively broad agreement on that and specifically going from 3 to 4 uh a year later right we ship 4 to four at the beginning of this year we'll ship P at the beginning of next year um I think the average global bandwidth increases by like 30% every year anyway so like that's basically just keeping step with that and given how strategically important it is I think that would be a good Baseline to agree on and then maybe we just delay delayed the decision on whether we go beyond that with also Max increase on collecting a few some additional data first um I think I personally would prefer to also do that then later on but but I see that there's a bit more resistance there so maybe

postpone that decision and just agree on the as a minimum basically that we will increase the target to four that that I think would be very productive to do

too

Tim Beiko: um yeah I guess I'd be curious if this is something that there is Broad agreement um and then you know if again trying to keep the the the scope of Petra tight like if this is something there is agreement on like is this the one thing we would change in Petra if we could only change and then there there are some concerns around the home stakers um

and I don't know how we resolve those but yeah maybe I like I guess maybe one one question is like if uh yeah what would we want to know to like be confident that we could do this increase um yeah I don't know if like anyone who's has some concerns around just like the the current stakers like um what's yeah what's the data that we'd want to see to be confident with this

Lightclient: I mean isn't there already a lot of data from home Staker saying the current load is too high

Gary Schulte: is that anec toal data from from

folks that are B with constrain though I mean uh we're only going to hear from the squeaky Wheels

Lightclient: I'm just saying that we are already at capacity for some people and increasing the target is going to put more people at capacity and Beyond so like I don't really know what data we can provide since there's already data saying that we're kicking people off the network or making it difficult for them to do their duties as a home validator

and

Tim Beiko: and then yeah there's a yeah there's a comment in the chat around uh rolling out I don't want at the prod and that this will help with bandwidth but um

yeah I don't know if anyone has more context on that they want to share like the timeline uh yeah okay Perry saying this would take months to roll out and analyze um yeah

Lightclient: I mean is it crazy to have a fork after what's already specified for devet 3 that's focused just on increasing the blob throughput and doing the preparations for pios like to me that the risks the situation of just making the current Fork take even longer gives us more time

to roll out these improvements for the CL networking gives us some time to improve the bandwidth consumption of the El transaction pool for blobs and still keeps us from getting into a situation where we bundle it with the full pios and eof or whatever else is in the next hard Fork that could take another one one and a half years

Tim Beiko: um yeah I guess it's worth having that conversation I just want to make sure also we don't forget uh the hands that were already up so like pis let's do po Ben and Perry and then come back to to this yeah

Potuz: uh yeah so just a quick comment a couple of quick comments I I I kind of

feel that there's a double standard here in that the the data that we have that our users are complaining about being reart uh and losing blogs is anecdotal uh but then on the other hand the data that we have that the notes are safe with an increase it's also mostly the anecdotal we we we don't have good metrics um and I would like this these two set of data to be put up to the same standards and second it seems to me that this change is just very minor so it's easy to implement it's just as much as when when we were talking about like changing the issurance curve which was a oneliner it's one this kind of things

that we can actually measure we can take some time to measure and if we decide that it is safe this is shipped in less than a day so I don't I don't see how why we need to agree today on an increase when we have a lot of time to measure and make this change in less than just a few minutes on every client

Tim Beiko: thanks uh yeah Ben

um throwing off

Ben Edgington: on like clients maybe Three Forks um just a a comment that you know e could go in that second one probably um but I just wanted to say with any um incre increase in Target

blob limit we should probably seriously consider 77 62 which is the Min fee um just so that the few Market isn't unpredictable um and there's been the research here stud on that and base whats it for instance

Tim Beiko: thanks

and again it's a it's a on line change um let's you yeah Perry Max and Tony

Parithosh Jayanthi: yeah I think I mostly agree with what uh pter is saying I don't necessarily think we have to agree today but we have to agree that we intend to do this so we can collect the data

required um I do think clients are anyway implementing I don't want messages there's going to be a reduction there and we can analyze the reduction as well as figure out um for example reor rates for home stakers um we mostly know what validator indexes comply to home Staker IP addresses um and we can check the Rog rate for that and see how bad it is right now so then we eliminate the anecdotal part and we actually have raw facts in front of us and then we can make a decision based on that I guess the commitment now is then to figure out that is this stuff we want to spend time analyzing and doing or is something

as higher priority um thanks uh do zo Max and then

Tony

yeah I just wanted to say on the data point I do uh respect the desire for data driven decision- making and I think we already have a lot of data on this because of the fact that the fee Market is sort of broken we know that uh we've had periods of sustained you know high percentage of the gas of The Blob limit used so we've had six blobs used for a long time and we can use that data uh to support a move which what ancar suggested would be 4 six which is the same limit and we've already had periods where we're operating near the limit for long period of time so uh I think we can go look at that data and and make a

decision based on that I also think we should consider doing uh 7762 as other have mentioned because much of the much of the disagreement about that was basically oh we're going to reach capacity soon and then this isn't going to matter but of course now we're increasing capacity again we should expect to see more periods of price Discovery happening

um Tony

Toni Wahrstätter: yeah I've just published um some analysis on the Rio grade um a very recent analyzes how the whole situation played out and it looked like since we shipped 4844 the reor grade is basically

trending down so we are at a level um that is way better where we were let's say a year ago for example and especially interesting is the fact that blocks with six blobs are not way more often are not significantly more often reor than for example a blop a block with three blops or even one blop so I think think it's very hard nowadays to really attribute the re the fact of being reor to the number of blops I think there are many more variables like the slot in index in an Epoch um the fact if the previous um proposer is playing timing games and so on that have a way bigger impact on the on the r rate

nowadays than the number of blobs so I would say um it looks like the network is definitely ready to to have more blops I would be more concern concerned about the maximum El payload side um size than the block size just because it can be so variable um compared to blobs that are just a constant size increase just um if you haven't seen it I will also post the the most recent analysis that I just did today in the chat and I think it's a good idea like Perry said to make it more granular to look into what are Solo stakers doing and also split between meth boost users and MEF boost users because I think even that has a way bigger impact on the r

grade than the number of blobs nowadays

thank you um Ahad yeah just

Ahmad Bitar: wanted to agree with the last two points Tony said about solo sckers and U my Boost and no my Boost because um trending down uh reorgs does not mean that solo sers are not struggling it just means that uh uh big operators are finding better ways to optimize against being reorg and um like adjusting their timings of of posting the blocks adjusting their timings to be exactly profitable and at

the same time uh not get re- ored out so yeah I think that's mostly it not that thenon suddenly fixed the oring um but yeah

thanks um enrio

Enrico Del Fante: yeah it's exactly the same things from Amed uh I do think that the Improvement is just uh infrastructure optimization rather than uh yeah clients being more optimized for for sort of sing actually what my my example before was actually an example specifically for a home Saker that P back to local local product local

build and if he had not Fallen back and choose the the Builder he probably would haven't been reor out so it's just uh be more resilient to to maintain local building instead of just uh systematically uh give block production away

Tim Beiko: okay I guess trying to summarize all of this and then uh yeah the past couple calls we spent discussing scoping like I think it's pretty clear that there's like a strong bias towards keeping uh the first half of Petra as close to dev3

as possible and then there's like some desire to maybe increase uh capacity in this fork with a lot of caveats um and the work for that could be relatively small but obviously not trivial um I think the four eips that sort of uh are are being discussed around this are uh 7623 so uh capping the call data uh 7742 the assigning the blood count only to the CL um potentially 7762 with the fee uh the minimum fee repricing and then there's no EIP for the BL count change but something around that um and then it seems also clear that like for

the second half of Petra we have these two huge things Petra Pi Das sorry and eof that are in progress that are not stable yet like neither of their individual Dev Nets are stable and we haven't even tried to put a devet with the two together so there's still a lot of work there um as much as people say that we would want to keep the spec Frozen there it seems unrealistic that like nothing will come out in the next you know six months that we decide to include um so I think one way to move forward is we keep the scope of pectra a as definite 3 we keep these blob eips these four eips I just mentioned uh module the one that doesn't exist yet to

actually increase the blob count as CFI for Petra a um in the next few weeks slash months uh depending on how long it takes we actually run the numbers on staking and I think there's a broader conversation to have around that like what numbers do we actually want what does it look like um and then try to like build the confidence around whether we think this is the right time to do it or not if it turns out that we're all happy with the numbers then we just include these relatively small changes alongside pectra a and uh you know we shouldn't delay things too much and we get some increase in capacity if we're unhappy with the numbers we can debate what to do then um and then for pectra B which I think we should just accept as

effectively fusaka at this point which is the next Fork we have eof and pias which we've already included in pectra a um be the main things and we can CFI as much stuff as we want but we I think having the commitment be that we don't include new things until we're actually ready to implement them is probably the best gate because you know once we have eof and pieras relatively stable then we'll have a big list of things that everyone thinks is extremely important and we can debate what to include from that but at least we're not gradually adding more things as we haven't uh while we haven't actually implemented eof in P us um and I think in the world we're like 763 and all the blob stuff

doesn't make it to Petra a we can decide to either um move it to pectra b or you know if we feel that it's so urgent it needs its own fork in the middle we can have that conversation but that feels like the most practical Way Forward um yeah and as much as I would like to like close the scope and say that we're going to commit to these things and not add anything else I think it's it's just like an unrealistic thing to commit to but I think we can commit to not making decisions about inclusions until we're actually ready to write more code and this maximizes how long we have to actually think about different proposals um um and can we commit to some suet the pectra that would not move out so I

would say yes I would say eof and pias which are already included um so like my proposal is that pectra V is eof and P Das and we don't add anything else until both those two things work on devet and we feel confident that we can actually add a bunch of other eips um and I don't think that like we can make a decision today about whether we want some small blob increase fork in between Petra a and Petra B I think if you know the situation changes a lot we'll be able to make that call it's relatively trivial to implement this like set of blob IPS but we uh yeah I I don't know that this like something we

should commit to today um but at least we get a scope for pectra a uh that's relatively finalized uh it's pretty clear that we prioritize looking into the blob increase and then we keep eof and pias as the focus for pectra b um and we don't do anything else into that fork until those two are done but it's possible we add more stuff like you know uh pris uh prism was talking about 7732 for example and stuff like that but we can have that discussion when we actually have e EP uh eof and P us implemented um any strong objections uh and yeah we call this fusaka yes thanks Trent so

like what I would do practically if we agreed at this is I'll update the pectra meta EIP I'll remove eof and pias move those as included for fusaka I'll remove anything else that was CFI uh for uh pectra except 7623 and 7742 um add I think we should add the max fee the Min fee uh for the blobs increase we don't have a PR yet for the blob the actual blob increase but we we can uh add that when it's there and then if anything else was CFI for uh for fusaka or Petra we just move that there and the only two things included in fusaka would be eof and perod as for

now

okay

any objections uh yeah g

Guillaume Ballet: uh not an objection per se just uh clarification uh what happens to whatever well the only thing that was uh that was CFI for fusaka so far

Tim Beiko: right veral so I think look we can leave it in the faka we can leave it as CFI for fusaka realistically we're not going to do this all in the same Fork if we want to open another yeah if we want to open another meta EIP today for Amsterdam like I can do that too

um I think at this point I would almost wait until we're like farther along with fusaka to open the Amsterdam uh EIP but so um yeah so yeah veral should stay cf5 I mean I'm happy to open an Amsterdam meta EIP as well to like have it be clear

Guillaume Ballet: um yeah as you want just

Tim Beiko: uh okay yeah I think I think

Guillaume Ballet: don't drop it

Tim Beiko: yeah okay yeah makes sense and I'll try I don't know if the EIP bot will let me do this but I'll try and do this all in a single PR so that it's all kind of clear in one place but um I'll see if the EIP bot is uh yeah let's me push this

through um okay anything else on the fork scope and there there was a a a a comment in the chat around uh from Bar B around like implementation estimates for the four block VIPs um so I think yeah in the next couple weeks it would be good to like think through both the data we want to see but also the overhead of implementing these and you know we can make a call uh about the inclusion once once we know a bit better but I think uh for everyone who's like

in favor of pushing this um we should um yeah Now's the Time to collect data and then also try to like look into reasons why this uh could be an issue um okay anything else on

Petra um oh yeah has

Ben Edgington: anyone implemented

Marius van der Wijden: 7742 on

Ben Edgington: the E Side by any chance because then we can already start doing some basic test and seeing if we can start

increasing the blob easily just from the CL side but we would need at least one El team to do this one El and one C team to do this

Parithosh Jayanthi: I would hold off on that at least for now purely cuz there's enough changes for devet 4 maybe we can coordinate on this after and by then we should have some more analysis data

Tim Beiko: um thanks um and I know Max Max you came on today as well because you wanted to share some updates about 77 62 I'm surprised we have the time to actually go into this but um seems like we do so

yeah do you want to give some updates on the conversation that happened on the about the EIP over the past couple weeks

yeah I would just uh like to plug a few things from data always basically gave a very thorough database investigation of what this would mean for prices and I think the maximum increase this would cause to average price per blob for the rollups was uh I believe 16% for uh base going from like an average of six cents to an average of s BL feel very uh cheap and then also uh some some of the rollups have expressed

support for this whereas they would be the ones are kind of potentially by them uh including base uh Express strong support for the proposal so I added those to The eth Magicians thread if anybody's interested in uh taking a look at those disc sorry the eth magician thread

Tim Beiko: thank you and I just uh posted uh the that data uh always analysis in the chat as well um any anything else people want to chat about before we wrap up okay well oh yeah

I

sign

Lightclient: uh yeah well so what is the target Petra at this point

Tim Beiko: so devet 3 we CFI these four blob related IPS or three IPS that exist and then uh this hypothetical blob increase um we investigate all the blob stuff in the next few weeks um if def if Petra without that is ready to ship uh you know before that's uh that's decided then we ship this at that point we can have a conversation around whether we want a special small blob fork in in between um for Petra B which we'll call fusaka we have eof and pieras included we Implement those we don't add

anything else until those two are implemented we see a a bunch of stuff in the coming months as it comes up um and then when we have a stable Dev net running both Pier Das and eof then we decide what if anything we want to include alongside those in the fork and then we also uh yeah draft The Meta EIP for Amsterdam to highlight that veral let CFI for it

Lightclient: yeah I think I'm asking more about what when are we trying to have a frozen spec for pectra and do like do we have a Target that we're working for right now because there's been some things thrown around even like forking early next year and to

do that working backwards it kind of means that we really need things Frozen in November and we need to start thinking about doing test Nets in December

so I think based on one month away

Tim Beiko: based on like the discussions we had around defet 4 today it seems we need at least a couple weeks for devet 4 uh to go live I think it would be ideal if by next I guess if by next ACD we are launching devet 4 we should figure out whether this is the last devet we want to launch for Petra or not and this includes you know do we want to include all the blob stuff

Lightclient: um I'm pretty certain that we will have another devet after devnet 4

okay

Tim Beiko: yeah so this gives us but I think this gives us roughly like a month to make the final decision around yeah uh all the blob stuff and then in parallel to this um yeah once we have the definit you know defet 4 find some bugs fix them you know we start getting towards a a spec freeze um and I think how quickly we can spec freeze the specs depends on how many bugs and issues we find um but um yeah I would consider this we don't quite have this etherum development but I'd consider today like the feature freeze of pectra and like maybe we do this blob stuff maybe we don't but we

don't consider anything else and then um hopefully in the next month we get to a spec freeze

Lightclient: okay so Dev de 4 is a good Target before all core devs in two weeks to have that launched

Tim Beiko: that would be great

Lightclient: or is that too optimistic or can we do sooner

Tim Beiko: Perry said we could do two weeks

Lightclient: yeah I mean that feels that feels like a good timeline because there's now still some changes that need to be made given the removal of of the request from the e block and some updates to the engine API

Tim Beiko: and then the gas prices for like it's kind of small but gas prices for BLS and then a

bunch of other small PRS so yeah I think two weeks is like realistic but it one week would feel very short um and obviously we can we can chat about this on next week's call but I yeah if aing to launch devet 4 for two weeks from now feels yeah feels good

Lightclient: okay so let's try and get all of the spec changes merged by early next week definitely before allore devs next week I think everything is open that we want to change about def 4 I don't think there's anything that's being discussed that doesn't have a PR yet it's just a matter of putting them all into the specs and then hopefully the week after devet 4 we can launch

yeah I think I

like that devet for specs by ACDC and then devet 4 live by acde

Lightclient: cool

Parithosh Jayanthi: and we also have one more Avenue for discussion that's the testing call on Monday so if there's some PR that I don't know need some more discussion please raise it and we can still do the synchronous on Monday so we have everything closed by ACD next week

sounds great

Tim Beiko: okay anything else before we wrap up great well yeah thanks everyone uh

ending five minutes early uh got Spectros scoped uh timeline for death 4 um yeah appreciate everyone's participation and we'll talk to you all very soon

Andrew Ashikhmin: bye

thank you thanks thank you byebye bye h

[Applause] e

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