All Core Devs - Execution #199

Transcript

[Music]

Tim Beiko: we are live welcome everyone to acde

number 199 um bunch of uh minor but important Petra updates to today uh so we'll catch up on dev 4 but then also on a bunch of um different uh changes to eips so uh hopefully can close out the subgroup check uh conversation for EIP 2537 um Felix uh had two PRS uh to 7685 he wanted to discuss uh there was a minor change proposed to uh 7702 and then I wanted to uh do a last check on including

7742 um as per the last ACDC and gajinder has a small modification for this as well um so we can chat about all that figure out um how that would look uh first that five spec um and then aside from that uh there was this conversations around validator bandwidth that we never quite got to uh on the last ACD um some stuff for on the gas limit and then um the e apis um to oh and yes the 200 celebration uh would uh happen right before Devcon so uh yeah we can celebrate that at Devcon um to kick us off uh I don't know

do we have uh Barnabas or Perry to talk about how devet 4 is looking

Barnabas Busa: yep I'm here so last week Friday we have uh started dut 4 and we have shut down that MYRY since then we have had a pretty good participation rate uh we have a few clients that are still having some issues uh hopefully we can get some on them so uh clients that are known not to be working are currently Aron and tmjs on the execution layer side and uh grandine seems to be the one that is still struggling uh with a with a few clients

but they are now also proposing some blocks so it seems to be a bit more intermittent

Tim Beiko: sweet um anyone from any of those teams want to chime in with some more context oh ethereum JS looking into it okay any other updates on defet 4 that anyone wanted to bring up

Barnabas Busa: I have started the bad block uh production again this afternoon only we do a single note for now but uh we'll

grow that into like three or four different notes later on

Tim Beiko: anything else on devet 4 oh uh gry solved some of it issues yet um the other one should be self soon nice anything else on

theet 4 not for me

Tim Beiko: okay um next up then BLS so there's been a lot of conversation around potentially uh removing the subgroup checks spting out the subgroup checks um over the past

week couple people have um um a couple people have uh reached out to uh different al2s and and other potential users of BLS as well as investigated the libraries uh themselves um I don't know if we have uh yeah does anyone want to give an update on that um either on the side of the community outreach or the actual libraries

um a

Kev Wedderburn: can given it's working yeah um so on the decision it seems that we're moving

towards uh just having the subgroup checks in uh one reason was that one of the dependencies it's pretty hard to see what it's pretty hard to get good confidence on what will happen if it's removed uh and it's yes it's pretty hard to to read it seems like from our Outreach that the ZK snark folks uh at least the ones we reached out to aren't sort of like saying we want this is the best way to say it um some of them have infrastructure in that makes it pretty hard to switch away from b254 to BLS 12381 um so I'm not sure what the use

case is for this pre-compile art I mean there are possible use cases uh but it's doesn't seem to be like the ZK snark folks uh at the moment

Tim Beiko: thanks anyone else have context on that

Alex Stokes: yeah I could add a little bit um essentially yeah I think the investigation Kev was talking about was really helpful cuz it does sound like uh with his dependency blst it's like not clear what happens if we don't have them the subgroup checks so we'll go ahead and keep them in that gives us like a pretty stable you know interface now to

proceed with like final gas bench marking and then separately yeah we can keep thinking about different use cases and reach out to like different community members to try to get a sense of like uh yeah the expected use of this thing once it's live and yeah that's a thread that can keep running even over the next like month or two but yeah I think we're unblocked at the moment which is good awesome

Tim Beiko: and on the benchmarking um I know it's been a couple of weeks since I followed up there but um my sense is we still didn't have quite a consensus on what the right uh price for uh a subset of the calls should be is that still correct

Kev Wedderburn: uh I think we do now with the

subgroup checks okay uh I think it was to just a 2X the current

costs

Tim Beiko: okay so like the original proposal of uh yeah change adding a factor of two on uh the discount table for those calls

Kev Wedderburn: yeah I believe everyone was on board with that

Paweł Bylica: yeah I'm I'm not sure I fully agree with actually this one because seem it this original gasos doesn't fit like the the shape of the curve we we seeing and we just try to use something that wasn't good fit in the beginning and like

multiply by two but um I think we can like spend next week to like figure it out exactly how this supposed to work and if the other people will be in favor of the original proposal I'm also okay

Tim Beiko: um yeah I think there's probably value if you want to spend a week or so looking at a better uh better proposal um yeah we we and we should I guess yeah we should ideally have a final merged uh gas C scheme in the next uh week or two so that yeah we're not blocked on that to launch future

devits

Kev Wedderburn: uh sorry what was the issue of

the 2x is it just that it's like not exact enough

p

Paweł Bylica: no it feels to me that uh we start with some like I don't know like lookup table that wasn't good in the beginning and we just keep the lookup table by just multiplying everything by two in the same sense we can just create a new lookup table that actually fits the the hour timings more more closely I mean it's the kind of the same amount of marking quir it just it's not like so clear that you multiply by two but it just puts new numbers and maybe it's not even needed

lookup table anymore and so that's what I mean exactly

Kev Wedderburn: okay that makes sense

Gary Schulte: when when we were benchmarking in Basu against Nar um we found that we were using the 150% proposal not the 2X and we found that even with 150% the G2 was way overpriced G2 MSM so if we 2x that I think that's going to get even more overpriced

Kev Wedderburn: oh that makes sense sorry I thought everyone was sort of in agreement but yeah it seems like we need to redo the numbers from scratch then

Tim Beiko: if we were to do that uh yeah po what's like the timeline that you'd

expect here is just something that you can Benchmark in a week do you need client teams assistance

Paweł Bylica: um yeah I I don't know but it feels to me that it's kind of the same amount of work we just put different numbers in the end

and

Tim Beiko: well I guess yeah like I one part I want to be sure on is like what's the what's the flow here where um my sense is when we did the 2x proposal every individual client team ran those benchmarks on their on their end um so is so I assume here there's like some

work of proposing a curve uh or like a you know like a lookup table for for prices and then um having clients confirm that is that correct

Paweł Bylica: yes I think what what happened is that with 2x like everyone is within the safety margin right so the worst case out of all this lookup table numbers it's it's fitting like the expectation but there may be some outliers in the in the other side like in other places that makes them like maybe too expensive I don't know um to my understanding gar implementation is is hit by the subgroup checks more than

blst at least what I get from data I received so it's it's it's a bit it's it's more on the G side unless they can fix the performance in the implementation I think it's it's a bit more on their side to propose the numbers if they think like 2x it's like great I I will accept that but uh and so I I don't think we need to take the pre-assumptions from four years ago when when trying to find the the good Gar prices it doesn't save you any work if you just take like this this um yeah this like original

work in gas prices from four years ago we can just put new numbers and and it doesn't make all this process take longer the the long the longest part is just to do the benchmarks and collect data

Tim Beiko: okay um is that something you have the bandwidth to take on and that other teams can assist with

I

Paweł Bylica: I don't know I need to I mean I can plot the data if I get one but I don't think I will be able to Benchmark every client so

Tim Beiko: okay yeah I think I

Paweł Bylica: think we need to figure out how to

exactly do this right I'm not that great at this actually but if there's no one else I can actually do like similar spreadsheet I did some time ago

Tim Beiko: so I think maybe what we can do then is uh we have the testing call on Monday if all of the client teams can make sure to send someone there to who could help with the BLS benchmarks um and pav if you're able to attend that too that would be great and we can yeah zoom into that discussion on Monday um and make sure that we uh yeah we have a plan for benchmarking this

Paweł Bylica: okay I'll try but I think Monday is quite busy for me

actually

right I guess yeah yeah sry Kev yeah

Kev Wedderburn: so what exactly is needed here in order for us to reach a decision is it just uh some set of inputs and then we just show what the timings are uh because I think a bunch of clients have already done that

Tim Beiko: correct yeah so we we we had the clients do this with the 2x proposal so what we need is what's arguably a better proposal than the 2X and something that I guess is more like a granular like yeah a granular repacing per call um and then having the clients rerun the benchmarks on uh on that Hardware or sorry on those

numbers

Kev Wedderburn: okay I see um and po you're saying that the benchmarking process is the hardest part cuz I think we don't need you to actually do that since you've already done it for even one we just need the clients to do that

Tim Beiko: okay yeah I think if if po can propose a set of numbers like a lookup table and then the client teams can Benchmark that we should be good and so we get yeah so I would suggest like sorting out the details of this we can use the R&D Discord um but then on Monday if we can yeah check that we have everything sorted that would be

great and um if you can't make the call directly on Monday pow if there's a way for you to share like a sync um either a proposal or like what's needed for a proposal that would be that' be quite helpful okay okay cool anything else on BLS okay um thanks everyone so yeah we'll move forward with that uh and again we'll keep the subgroup checks as part of the EIP um next up Felix had two PRS he wanted to discuss uh for EIP

7685 is uh Felix on the call

Felix Lange: yes I am can you hear

Tim Beiko: me yes we can um yeah I just posted your first in the chat um excluding the M requests data in the commitments

Felix Lange: let me just quickly explain so basically I am proposing this um because we notice during the implementation of the definite four changes that uh it's very inconvenient for the El to have a empty value of the uh the empty value of the request has depend on which Fork is currently active

so for example this is um if you initialize new chain um and at the Genesis block the fork uh like the pectra fork is active then we need to compute the empty request hash um in the Genesis block and at the with the current definite 4 definition this is basically the request hash with re empty requests lists and uh but in a future Fork this might change so basically every time now um it's just going to add a whole bunch of code to gen initialization where we have to figure out like the the like empty request and then more generally like I

mean there are certain cases where you want to produce blocks just for testing purposes but there's not going to be any kind of Cl so it doesn't really it's not really necessary to that with the request at all and then it's like it's just nicer if you this hard code this empty value there like that's the main motivation honestly and um yeah that's only possible if it is not dependent on for so this is where the proposal comes from and um I mean the corresponding change in the engine API I only propose it just because we feel like it's much easier if there's a canonical sort of requests

list that is shared both on the engine API and it's also used for the commitment right now we already have this B forcation of the commitment and the engine API I personally think it's quite bad so basically you we have to uh what happens is when we commit compute the commitment we have to add these type bites uh for the request but then in the very last minute on the engine API the type bites were removed and so this already means right now that we have two different representations of the request list one which is only for the commitment and only which is one which is only for the engine API and so I'm just proposing to make these two the same again by also removing the empty

request from the list which is shared on the engine API and adding back the

typ bite

Tim Beiko: thank you um anyone have comments starts on this okay reth is in favor uh I know teu I think approved the changes as well uh on the pr directly ethereum JS is in favor does anyone I guess disagree with this change or have like significant concerns

Felix Lange: I'm pretty sure if I had proposed on the ACDC next week there

would have been some backlash because it does mean that the CLS have to add one more check which is that they have to now validate that the request items are given in strictly increasing order just to ensure that for example because with the typ bite it again introduces an ambiguity that wasn't there before however I do think it's a minimal it has minimal impact but it doesn't have some impact on the seals so uh maybe someone from the SE side should speak up and I mean I I think it's a minimal impact but definitely has an impact the C as well

Tim Beiko: any c on the call have strong opinions okay so load star should be

okay uh Lucas from teu had already plus one it so my sense is we can probably go ahead and include these two PRS as part of the devet 5 spec um and aim to get them uh get them oh they're already part of the de five spe awesome um yeah and aim to get them merged by next week's ACDC and if there's any CL uh level issue that comes up we can address that on next week's call

Felix Lange: um yeah okay thank you

Tim Beiko: yeah thanks fix anything else on this topic

well enough from me

Tim Beiko: okay um moving on then uh next up we had

a proposed change for 7702 um so I I haven't quite followed the conversation on this but supposedly it was uh due to some back and forth on each magicians um yeah I don't know does anyone have context on this PR uh to remove the delegation behavior of

EXT code up codes yeah

uh just quick context so 77 to currently introduces a new type of account that can change its code hash uh this is currently somewhat possible if the contract has delegate call and since uh the delegate call changes you know only if it uses in the same uh transaction as creation um but this is

kind of a strictly new kind of way of changing the code hash because it can happen even if the code doesn't include self-destruct even if the code doesn't include delegate call so it weakens the uh guarantees that one gets from looking at the code hash of an account if a contract relies on that to um trust the way that the account is going to behave uh it could be vulnerable because it's able to sort of temporarily masquerade as a different kind of contract um so it does seem like something that we should look into um we've looked we found a couple of code samples that appear to be affected um but nothing really too serious uh but we

haven't really done a a thorough search so the proposal here is to uh only delegate code execution so EXT code hash would and EXT code uh copy would just act on the delegation designator um instead of kind of following the delegation pointer that seems uh just sort of more normal in line with what a an evm proxy is and and so it just seems like it would uh just be less surprising in terms of the effect on applications

Felix Lange: it should be noted that the code has will still change all right like if you change the delegation you will have a different code has anyways or is the code has going to be reported

as the hash of Delegation

or

uh do you mean after this proposed change

Felix Lange: yeah so I mean you were saying

sorry go ahead

Felix Lange: so you were saying that basically the point of this is to ensure the account cannot change its code hash uh unexpectedly but I think if we don't do the delegation we still have to take the hash of the delegation code yeah so that basically means we still have you can still change the code hash of the account with 772

yes that that's right so um there's a stricter version of this proposal uh

look more conservative which is to to do kind of like eof contracts and just um look at the prefix so it wouldn't change as you say although in this case if it does change it it would at least not correspond to different code because the delegation designator is not um valid um valid code right but it is another option that I I would also be open to

consider

Felix Lange: yeah I thought we actually have a proposal in UF that says any code that starts with zxf is immediately forbidden from for looking at isn't that the case

uh from executing yeah

Felix Lange: yeah but also like from

being introspected yeah

oh interesting yeah you cannot

Paweł Bylica: you cannot look it up it will just behave as a like some Sentinel value so for

Felix Lange: so it only returns Z XF basically yeah so maybe that's what we should do for the delegation as well just but then it's actually worse because you can't you don't even know it's a delegated account basically you don't know anything about the account and maybe that actually makes the problem worse

well if in yeah so Ansgar is saying it's ef0 and in the case of delegated accounts it could be ef01 which is the prefix so that would allow to to distinguish but I don't know that

is important

Felix Lange: well I mean the contract could kind of know that it's a delegated account and like reject interacting with it for example so that would be the main advantage here just being able to detect within the evm that the delegation is active for this account and you could be like you know I'm not talking to that account because it's a delegated one that's certainly something but the contract would have to be aware of this concept anyway so it doesn't apply to the old contracts because they don't know anything about this it's like just that would be a new security pattern that you have to introduce into your very important protocol like basically ensure that yeah this is just Fallout from 7702 adding so much new attack

Service uh yeah

Daniel

yeah um so just one problem I have with this proposal is that um right now all the up codes that inter that that interact with code like the call or code has are completely oblivious of code delegation they they just get the code of the target if we do this change the code delegation is not transparent anymore to the AVM because we need like two ways to retrieve code one that follows the delegation for calls and another one like in The Proposal X code has and the others that don't um so this breaks a bit the Assumption of 77 to that the evm

in the end does not have to be aware of it um also in the future when we introduce new up codes that Interac with code it might be a bit error prone because we have to be careful which of the two ways in case of 772 be used to to retrieve the code so that's like my one my one doubt about this change

okay

Tim Beiko: um and yeah ongard do you want to talk about the eof style Behavior you brought up in the chat

Ansgar Dietrichs: no I'm actually not not 100% sure

it could be that uh you have um actually only Returns the kind of zxf hash as the magic kind of hash if if you try to code inspect it um I think if that's the case we should probably revisit this now that we actually reuse the zxf domain basically for for other things uh things other than URF um but what I'm saying is it would probably there would probably be value in having a if we want to just return a magic bite which like like a hash of a magic kind of pre kind of prefix or something um as the response now in the 7702 case as well which I personally think would be just another principal step towards kind of like getting rid of quot inspection and then

I think we should make sure that it's not the same um kind of magic hash that um they use for for UF because I do think there's value in being able to distinguish those two cases and they also conceptually not the same right

Tim Beiko: um yeah I guess it still feels like there's some discussion to be had on this to actually understand the sort of second order impacts and like yeah what it would look like implementing in

the evm um what's the right way to like move this conversation forward um is the E magician thread sufficient now do we want to have a breakout on this in the next week or two

Lightclient: um I would love to just hear from some more D Developers I am weakly in favor of this change I guess you know it's to me it's pretty much okay how it is but it's also okay to change it I don't think that this is this is not something I'm super worried about but if there are more examples that could motivate changing the behavior like I'm open to hearing

them the ones that I've seen are pretty contrived examples

thanks gam um yeah

Guillaume Ballet: if you're looking for an example it's an it's not a dep developer example at least not directly but when it comes to any stateless gas cost model if you have to do a jump um to a different location you're going to potentially incur a significant price for opening a new group um and what happens in that case is that some operation you think is prettyy cheap because it's just checking the code hash is going to have a jump to a location

open it and pay maybe uh like 1,900 gas like 21,000 extra gas um that could be surprising uh that could be that could be breaking some contracts that expect xcode hash to be fairly cheap so yeah just for your information that's going like doing it uh the current way is going to have an impact returning a default hash Let's us just go to the current header that we already know about and that's pretty cheap so yeah it in terms of gas this could introduce a very surprising um significant cost in the future so I'm in favor of this

proposal because it would keep the Fairly cheap price that we expect

Lightclient: wait why is it that cheap though you don't know if it's going to be warm or cold right the account that

you have code sizing

Guillaume Ballet: you're going to call uh right that's true but I mean instead of being warm once or cold uh once it's going to be warm and cold twice yeah

Lightclient: I mean the same order of magnitude and people need to be writing contracts to deal with changes in gas costs like we could easily just say in the future that this needs to be twice as expensive so I don't really see that as that

compelling either

Tim Beiko: um yeah freno um I guess do you have a sense of whether there would be concerns of using the sort of hardcoded uh return value like ongar was proposing or yeah do you not have a a good

I don't have a super strong opinion but it it do you mean like um if there was a way to uh tell AP part that an account has been

delegated

Tim Beiko: so more that like yeah instead of returning the delegated account we just return like a magic bite like ZX efo1 um for any yeah

I think that's fine okay yeah

um because

Tim Beiko: yeah I think I I I do agree that in the past we would um like we we've said we want to move towards less introspection and that feels like a clean way to move uh a bit further Direction um but yeah I don't know was there a use case to actually return the delegated or the the delegator account

there are certainly use cases

you w could come up with but the I think not a critical

Tim Beiko: yeah

yeah and nothing that exists already

Tim Beiko: so I think if that's the direction that like I don't know this group feels weekly in favor of then maybe we should modify this PR have a hardcoded value um returned and then try to get a last round of feedback from application developers on that before

definit 5

cool that sounds good I can make the change

Tim Beiko: awesome uh thank you very much um yeah so let's do that and then uh once you have the pr open just uh send us a

paint so we can tentatively add it to the dev 5 spec as well um sweet anything else on this topic okay um and then uh next up so EIP 7742 on the CL call last week uh we seem to want to move this to the fork uh to separate the blob count from uh to have the the CL Drive The Blob count um there so I guess and then sorry there was a proposal by gajinder to change this um he opened the

draft PR uh for it so I don't know G Jinder do you want to maybe give it bit of context on your draft PR yep

Gajinder Singh: so uh basically um with 7742 uh what will happen is that CL will send the Target and which can basically change theoretically block to block and uh so the way this impact the fees uh the Fe the way this impact how Fe is calculated on E is that uh we have basically an excess gas accumulator and where we culate where we uh accumulate some delas on each block how how much it's below the

Target or above the Target and then uh use it to calculate the fee uh with the uh of uh in a way that uh so we have an update fraction which basically makes sure that the factor by which the fees up goes up and down by which basically this Delta uh Delta effects the f is less than 1.15 uh because excess gas by this update fraction is exponentiated so uh the problem with a dynamic Target is that uh this you can't basically you can't you don't have a constant upd

fraction uh so what this EIP does is it normalizes the Delta against some some Target it and then accommodates it and then there is a normalized upd fraction that is used to exponentiate and get the gas cost so everything else stays the same but now when you are calculating the excess gas you are basically calculating normalized excess gas and uh so which is basically Target uh uh which is which is Target minus gas used uh by the Target times some constant factor and that that factor we have chosen arbitrarily so that factor could be

chosen up or down depending upon how large or smaller this number to

we

good Jinder your mic is a little hard to understand maybe move a little bit further back or um I don't know if you could switch to another mic if possible if not just some feedback

it's not great but yeah maybe all right

Gajinder Singh: so uh yeah basically that describes uh the change I was almost done

Tim Beiko: thanks yeah I think that's that's uh yeah we we can somewhat hear you now um anyone have feedback or

thoughts on this change I know it's it's uh been I think the pr was open uh uh yeah just yesterday so any yeah any comments thoughts

Alex Stokes: yeah so I mean I think the main thing to do today is just to move this to SFI so that you know we have it um there is this question I think the issue uh that gender's pointing at is that the like base fee adjustment uh constant doesn't like it it's hardcoded essentially for the fact that we have six blobs and so we'd have to change it eventually anyway and then this is just now figuring out the right way to make it flexible enough under

7742 uh so everything works works nicely um yeah so I mean I think we can iterate on that but then separately we do want some blob in crase and pectra it sounds like and this is uh required

Tim Beiko: right okay maybe you has to flip the conversation around do any does anyone on the El side have a concern with moving 7702 to pectra as it exists today um and then maybe we can take some more time to review gender's proposal in the next week or so last

call okay so let's move uh 7742 to pectra um I'll make the change right after the call we can uh yeah have an async conversation um on the pr that g Jinder pull up and then hopefully resolve this by next week's ACDC um and yeah Barnabas is asking uh if there's any client implementation started 47742 I guess not much oh ethereum JS and loadstar have uh P The

Works uh basy should be ready by the end of next week okay uh prism is in the work um so okay some clients have started um sweet anything else on 7742 okay and then um lastly devet 5 so we had a couple PRS today that we decided we're going to add um it seems there still issues with devet 4 um yeah do we want to spend at least another week working on devet 4 and revisit a final devet spec devet 5 spec um in the next week or

two okay I have a plus one from Barnabas um to we move forward with that um and yeah I think the only PR we mentioned today that uh is not tracked there doesn't exist yet is the change to 7702 so as soon as we have that we can include it um to the devit 5 spec okay anything else on pectra before we move on okay then uh next up uh wanted to touch on the validator bandwidth uh point that was brought up on the last call and we didn't quite get to um I don't know is Ryan on this

call if not I can just share his uh his questions um I'll just post the agenda Link in the chat as well um but yeah quickly so the first one was giving the emerging giving the emerging importance of validator bandwidth uh and driving real world disaster contingency planning for the validator set how do we feel about the existing scope and rigor of bandwidth re search uh are we doing a great job can we close the gap um C there's at least two different research area uh Research into internal bandwidth dynamics of the protocols and client implementations and research uh into the external bandwidth Supply available across the world um and how that's

expected to grow expand um how it changes in different parts of the world and what not um and he he links and E research posts with some more like tactical versions of this yeah anyone have thoughts comments on this okay if not uh yeah I will Point people to the eth research thread and we can continue there I know there's already um some responses by I believe some Lighthouse folks around uh what's happening on the client side um yeah so so we can continue the conversation on E

research and next up uh Julio had a proposal for the gas limit uh EIP that uh we discussed a couple weeks ago um yeah Jun do you want to talk about EIP

77 M

Giulio Rebuffo: yeah so first of all if possible I would like to give a little update on 7783 just from an implementation point of view uh so right now um I was able to implement it into RAF Aron and Gaff um and and and that works I know nethermind also planed to do an implementation but I don't know if they actually did it but I think they did um so this is just an update uh then regarding

7790 um I did some asynchronous coordination amongst clients and it seems that uh um I was able to kind of come to I think I was able to kind of come to an agreement for um agreement across the clients uh across most people at least um um on on on the actual guidelines uh so so the guidelines I came up with that came up where was basically um a target of 60 million gas over two years and I talked this with nethermind and they were fine with it Aron is fine with it I went to GF and Peter told me that there is no reason

not to increase it at least that's what Peter told me um yes there were some concerns from bzu I haven't heard nothing from ref yet but I think uh well I think but really I didn't really or but like at least from a technical point of view it seems that there is really no no reason not to increase it I think um at least at least after discussing it most people agreed at the end of the day right so um yeah there were some concerns from bisil yesterday but I hope they're cleared so I mean I think we're kind of also ready to kind of at least take a decision here because I mean seems that at least the majority

agrees maybe maybe nethermind can confirm or if Peter zag is on the C he can also just confirm I don't know if he is but yeah

Guillaume Ballet: um he's not I it's presumably not on the call because he's on holiday but I can like he we discussed that in a stand up and I confirmed that he he agreed

Giulio Rebuffo: okay so what about nether M just so that we are sure that you're also on board is there something from

NE

Tim Beiko: uh there's a comment in the chat from Ben that saying never mind it's good

Giulio Rebuffo: okay

and okay and B no some concerns yesterday I hope they're cleared and uh yeah and what about ra because I nothing from ref if they have an opinion or not an opinion

um are we talking about including this imp pectra

Giulio Rebuffo: no uh it's not an artwork it's like you can it's actually you can include it also a bit afterwards so like it's not an artor like the AP is not an so you don't need to

Tim Beiko: right it's like the default the default behavior that you ship with the client which also doesn't have to be the same across clients right like um yeah

yeah yeah and

um I don't currently have an opinion on

this uh I don't know who you reach out to but uh I haven't heard anything

Giulio Rebuffo: okay and yeah so regarding the okay so there are some uh um some hands so who wants to start

Tim Beiko: yeah maybe let's do light client and then we'll do enrio yeah

Lightclient: yeah I think my general feeling on this is that we have some work that we need to do around history and we haven't completed that work and it feels very weird to sort of skip over the thing that's kind of necessary to just do a very easy change to the protocol and increase the footprint of

clients I would really like to see some progress on 44s made before we talk about increasing gas I mean

Giulio Rebuffo: I mean yeah but at the same time regarding history and already kind of talked about it a lot is that even if you don't commit to it so first of all this is a very easy change yes and it can imp last day the testing is really trivial to do like it's just tracking a number so I'm just going to say that out of the way and the second but the other thing is that is regarding history growth if you choose not to do it you're going to end up with eating um the 4 terab Mark for comfortable SP running in the same amount of time pretty much right it doesn't make a difference so I mean I

mean if if it's just I mean I don't know you I know that it's for just kind of a preference because you feel it's lazy but from a practical point of view there is I think objectively no difference whether you do the limit increase or not so yeah so okay anyway

Tim Beiko: and let's maybe do enrio and then Ben

Enrico Del Fante: um if I'm not mistaken we send gas limit as a configuration uh for the proposer uh through the Mev boost when we do proposal registration of the Builder Network so it's just a comment that if this happens then this this

interaction must be changed and it's kind of static and it works

no

Giulio Rebuffo: well not really well not really I mean after all you can still suggest it and if you don't specify the Builder is going to use whatever they have which is that perspective

Enrico Del Fante: honestly it was just a comment that says uh there is an interaction it's not pure El thing is there is an interaction with the the way CL talked to them Builder and we we have to do some consideration there yeah

Giulio Rebuffo: yeah but yeah

Enrico Del Fante: it's minimal but is something

that we need to care about okay

thanks

Barnabas Busa: uh with regards to history uh history growth is slowed uh from blobs cuz a lot of the data is now going into blobs rather than into uh call data um also the the way it increases linearly over two years means the average increase over the entire period would be only 15 million so that's the impact you got to think about rather than the end impact um and I hope progress has been

made on 44s by then and also that we've included the C data increase so I mean if it if cold data goes into fusaka faka maybe takes six months say um then it's only gone up to uh 37 million gas by that time for instance it's not you know it's not a straight shot to um 60 million and we can also hold F at any time

Giulio Rebuffo: can I also add something really quickly because I see uh some people you in the says I for that says that basically uh that that basically the impact of their shipping it is not

strong well the thing is that actually the beginning um I Heard way higher numbers from people not 60 million the beginning it was more close to 90 reason why it's 60 is because we would like first to merge KS before actually making it more significant but since 60 million is a start why not and also it's just a best a better way to increase the gas limit so yeah like objectively it's a better way to increase the gas limit so I don't really so SE comes actually from so 60 million is just uh it just comes from basically something that clients think they can handle mean I mean the ones I talked to that's what you think they can handle quite well that's where the 60 million comes from and but if if it

weren for some things it could also be 90 so in reality in the future it's probably going to go up with the Qs being merged so yeah yeah anyway

Tim Beiko: yeah let's do uh Stokes and then Marius

Alex Stokes: yeah I mean I think you might have just touched on my question but I do wonder where the 60 million number is coming from like did we just decide to double where we're at now and then go from there

Giulio Rebuffo: yeah basically um so basically kind of yes and we basically first of all we we kind of tried to go for multipliers I mean I worked out with nethermind and we first it was uh we went for

multipliers um so the first multiplier was like 90 million because because uh U because there was some consensus between Aron and neine that 100 Gaby of state was the max they would allow then they basically then we basically said no okay wait but maybe but the maybe there are some other things that might get in the way maybe we should actually wait for some hies to emerge so we actually just say 60 million and 6 mil is actually very conservative it's very slow increase it's a low impact immediately but it's yeah and just one thing actually and actually one other thing I want to just also say up some add some more things so um that I am seeing so

the testing I I saw somebody talking about testing why testing is for this AP trivial like it's just tracking a number like you basically set a bunch of flags on a devet and you just see if the number goes up it's really and it's very and it's deterministic so it's not there is almost no unknowns there it's they just like it's easy to implement it's easy to test it's low effort and it's is and it's okay um yeah

so yeah so yeah yeah I'm

Alex Stokes: I'm not opposed raising the gas limit but I would want to see like a more rigorous analysis around all the various considerations before picking a particular number

Giulio Rebuffo: yeah 6 is just what I mean we I mean I can tell you that um that Aron

can definitely do 60 million um I mean the numberb seems to to indicate actually quite potentially quite I mean there are numbers this is actually based on numbers like it's not like just taking out random just out of multipli it's actually based on number so uh then the main reasons is kind of that we P6 milon was the cold because we doubs about about the cold data and and and some opical don't scale very well that's the FDR from that perspective but yes it is actually it is of course not just taken out of my head and just put it there for fun right

Alex Stokes: anyway yeah and I think just communicating yeah again with more data and your analysis and thinking would

help help people get more comfortable with it

Giulio Rebuffo: I I I mean I wrote some block post I also wrote like an entire night some verle and yeah you can go check it out I post it on Discord so I can I can I can share it with you later

Tim Beiko: um Marius

yeah

Marius van der Wijden: so I think we are again having two debates at the same time uh one debate is uh whether we should increase the gas limit and whether we should or maybe we even have three debates whether we should increase the gas limit whether uh or what the what the good gas limit should

be um and the the the other debate is like about the mechanism of increasing the gas limit and while I agree that we should increase the gas limit um I am not knowledgeable enough about whether I whether 60 million is the is the is a good number to land on um I think that needs to be more research and we made some numbers but the problem is these a lot of the like worst cases grow exponentially with the amount of gas you have in a block um or

at least quadratically with the amount of gas that you have in a block so um we need to have a lot of like we need to really make sure that it works um and and the other thing the the mechanism for it I just don't agree with I don't think we should do these these gradually increases I think we should do steps um steps of 1 million or five million gas or something uh do a step decide everyone decides that we should do a step and we will ship the next client version with this step as the default and uh most people will update uh so the the the gas limit will be raised

gradually to that next step we will see how it works um and uh then we will uh we will make a decision on the next step I think this automatically like this automatic gradually in increases just uh it's it's not great it would in the case that something happens and this is um 60 million is not the uh it just doesn't work and we see it it breaking uh then we would need to do uh basically an emergency release of all the clients um to vote on the gas liit again and I don't think that's good so in my in my opinion we should do bigger

steps and um and uh yeah have time to evaluate um the impact of these steps

Giulio Rebuffo: yeah I mean The Graduate increase is just back better because you don't need to coordinate right like what you're saying yes we do it in steps but then then you need everyone to upgrade and it's hard to measure it's objective just hard to measure right doing a little steps also takes time it takes duration time it's inefficient from uh from um from a management point of view and also that's and also like and also also the 60 million is kind of research like it's not like as I said before it is kind of research not like I just took

it out of my head I discussed it for like an entire week with with nether M so it's not like something I we we just came up with in our sleep right there are actual numbers behind it and um and and also 60 million is just also 6 over two years is just really small like it's it's just kind of just to start something right and it's easy change but anyway yeah anyway

Tim Beiko: um okay let's do Gom and Ben and then uh ideally wrap up like again I think there's uh clearly different opinions on this this is not something we also need

like full consensus on um we uh well it be good to have like rough alignment we can have different teams um uh we can have different teams like yeah test different things on their clients um yeah

y

Guillaume Ballet: uh yeah so it's just a remark on the veral document and it's entirely my fault that this got published with this mistake um like Julio you asked me does the proof size increase logarithmically which is what your document says and uh the proof does increase logarithmically but the witness increase linearly so I think we should actually do some more um you know dimensioning or whatever

checking checking that's the gas doesn't make the the witness larger um yeah I sorry for the miscommunication

Tim Beiko: okay um anything else that hasn't been uh brought up yet okay I think we can continue these conversations I think um yeah and again like while it would be ideal to get some consensus on this it's

also not something that like requires a hard work or that Cavs effectively control at the end of the day um um okay last thing we had on the agenda for today uh again from fedix so add official revert uh error codes um for all of uh the apis in uh I believe the engine API um Felix no

different one okay uh yeah so

Tim Beiko: so I put up the pr in the chat yeah do you want to give some

context

Felix Lange: yeah so this came up pretty suddenly so we have received um this issue multiple times over the years that people have complained that uh there is no standard way to get access to the revert data when accessing contracts using the East call East estimate gas or east TR access list operations and so um yeah we would like to uh basically introduce our way the way we've been handling it in G as sort of like the official one so and in G we have this like error code three that we use for this purpose and um yeah I mean it's it it's I don't know for us it's the most important thing just to have a defined error code and just basically ensure

that all the clients behave the same way because right now in a lot of the client libraries for the RPC you have this these huge kind of function uh with different like matching different behaviors of the apis matching on error messages and so on just to figure out if it's this error and then somehow trying to extract this this data from the from the error in some way so I don't know I mean I'm also open to having a different solution but I mean for us it's the easiest to propose the one that we use already and um yeah I'm just open to hear like what other people think

Ameziane Hamlat: um yeah I I think from basos side

it it makes totally sense because this is something I wanted to do recently basically comparing the results the puts from uh G and Basu on um on E call and I had this issue because we have uh different uh returned codes and uh basically payload um and uh yeah it it was very hard actually to uh to to do the comparison so um yeah I am totally in favor of it just I was wondering why we would not have a code that is similar to what we have currently in the in Gina API something you know around minus

32,000 currently in B we return minus 32,000 which is basically a server error when we uh when we have um when we have this kind of error

Felix Lange: yeah so I can answer this uh it's a I think it's kind of a common misund understanding that Jason RPC error code must be negative so basically there is absolutely no need for for the error codes to be negative it's just that the Json RPC specification um you predefined certain errors and these predefined errors are not taken to like they don't have to be used for everything but in for some reason in ethereum we have always only

used the arrows which are predefined by the Json RPC specification but in fact it's they made these negative so that you have the full positive error code range available to to your application which ethereum is like ethereum is an application of jsonrpc so we have all the positive numbers available for our use U it's just that we for some reason only use the eror codes that are in that spec and the the aror codes that are in the Json orc speca only most of them are for internal use by um the Json RPC subsystem itself so basically the most eror codes that are defined by the Jon RPC spec are just used to notify the Cent that their request is malformed in some basic way or something and then the

server error that we use for all things is just it's like the generic error code like the generic server error in HTTP you know like you can use it but it's not descriptive of the actual error

okay

Tim Beiko: any other comments on the proposal okay maybe yeah we can have another couple teams have a look and uh if there's no objections we can move forward with it but um yeah we can probably continue this I

think okay yeah thanks Felix um last thing I had on the agenda so uh on last week's uh ACDC we agreed to cancel the award Dev call uh during Defcon um I would suggest probably canceling the one after as well as a lot of people tend to travel back or take time after the week and we'll have a whole week of people being together um any objections to canceling the call on the 21st or any strong preference instead cancel the one like before Defcon um but right after feels like it's probably the right timing okay no objections so we'll have acde

number 200 right before defc con um oh actually Barnabas is AOS right um anyone else in

barnabus uh yeah

Marius van der Wijden: we need to ship

man yeah so

Tim Beiko: exactly so I'm keeping the call before defc con so so we ship before and then we ship at Devcon I think this the right um and we get the 200 before defon H yes so we have the call on November 7th yeah yeah of course um so we have acde on November 7th ACD sorry yeah ACD on

November 7th ACDC on November 14th oh no sorry acde on November 7th no ACDC on 14th no ACD on 20 1st and then back on the 28th yeah uh and Marius will be here at 14 UTC okay Maris Barnabas um does everyone want the call on the 21st we can keep the 21st if people feel strongly about that okay my oh more 21st um okay bunch of people want to keep the

21st uh my proposal then is we should probably merge the testing call uh so we usually have the Monday testing call um that would be on like the 20 uh or sorry on the 18th um so keep that together um and have like maybe an informal call for whoever's there on the 21st um but cancel fully the 14th um okay and Barnabas might also do the testing call Great anything else people want to discuss before we wrap up okay then I think we can uh leave it

at that uh thanks everyone I'll post the summary shortly on uh the Discord um and talk to you all soon

take care everyone everyone by by bye everyone everyone is

he h [Applause]

for for

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