All Core Devs - Execution #97

Transcript

[Music] [Music] so

[Music] [Music] [Music]

Hudson Jameson: hello everyone and welcome to ethereum core developer meeting number 97 i'm your host hudson and we'll get started with agenda item number 1a this is an update to eip 1559 the fee market change for the ethereum

1.0 chain this is going to be from tim who left a comment that's linked in the agenda by the way i updated the agenda like seven minutes ago so refresh the page if you have an old copy of it so tim go right ahead into the update and major questions sure thanks hudson um so just to give a quick background on on 1559 uh i think a lot of folks are probably very familiar with it um is uh it's a proposal to change the ethereum fee market uh so it has a couple nice properties the first is that it hard codes uh the transaction fee in the blocks um so it makes it easier to query what the

right fee should be for a transaction um and the second is that it burns part of the the the transaction fees in each transactions um which uh which creates a nice kind of uh feedback loop between the usage on ethereum and and the amount of fees that is burned um so so a lot of people are in favor of it because of that um and it can also help uh potentially mitigate against some uh some attacks where when the fees become much higher than uh the block reward then miners have an incentive to reorg um so all this to say like a lot of different folks have been interested in this eve for a long time and uh on the basic team we we started uh somewhat championing it again earlier

this summer um so right now uh both us and the vulcanized team have been working on implementations of the eep and nethermine just joined this week i believe they're syncing your little testnet that we have at the moment um so i guess i just wanted to to give this quick update i linked a more detailed one on the awkwardness agenda if people want to read that um and when i was reading through the previous discussions on accordance the biggest reason why uh why people were reluctant to include this eep was the potential denial of service risk on mainnet so this eep uh achieves a lot of its goals by creating

uh by essentially doubling the block gas limits and aiming to keep your average block only 50 full um but it's possible to fill those blocks if you pay if you pay enough um so that means that we're effectively increasing the block size uh in the worst case by by a factor of two um so i guess first of all i just wanted to ask do people see other major risks or have other major concerns with this eep uh the the potential risks of having twice the block size is something we're definitely looking into um but i'm curious yeah i just wanted to see yeah first off if anybody had other major objections or just general thoughts they wanted to

share about it

okay do we have anybody gonna volunteer martin

Hudson Jameson: uh only if he wants to go

Martin Holst Swende: yeah well the problems that i we see with the 5059 it's about denial of service aside from that [Music] it's there are basically no

big issues we see with it but it's it's a bit unclear whether the motivators are this being uh mainly a ux benefit or if it is about the whole value proposition of doing re-orgs and having a value i mean if the minor revenue stems from transaction or the system from mining rewards and how does that affect the security um uh if it makes if it makes sense for miners if managers get a larger

incentive to reorg to get a highly valuable blocks whereas currently it doesn't really make sense to keep mining on this book or that block or it doesn't make sense to mine an old block because they're all about equally worth worthwhile so there are but for yeah it's mainly the um the denial service potential denial service that issues that can be excessive if the block gas limits can be raised to

it

Hudson Jameson: anybody have any insight on that that

they can provide i know that um oh go ahead

Tim Beiko: i i was gonna say i think yeah for for those types of you know security concerns i'm happy to just you know ping people and follow up offline uh so i think that's to me that's fine and already we already had kind of an understanding of those um i think it's mostly if if people have other concerns that they'd want to raise that'd be good to discuss and also i guess um to get a feel for maybe folks like james uh around like what type of testing

and whatnot they would want to see for a nip like this before it went into something like a you know it won't be in the berlin but like a yolo network for whatever whenever the next upgrade is um yeah that would also be very valuable

Rai Sur: i'd also like to know if the denial of service worries people have are from the theoretical standpoint of uh just too many blocks taking too long or if it's more from a kind of practical implementation standpoint of what happens to the existing clients if they have to handle so many big blocks in sequence because right now i don't see the issue as is with the

with the theor like the theory of it because doesn't the base fees just basically just increase and render each block harder and harder to fill for denial service purposes

Tim Beiko: yes but um even if like even if the base fee increases you know there's blocks are not that expensive to fall to fill um so it's like and and i think over a i call it whatever like 30 to 60 minutes it would become uh much too expensive for like much more expensive than say 51 attacking ethereum um but you could still get like a

uh you could still get like a short you know call it 15 to 30 minutes uh fill in your blocks at a reasonable price if you want

um for

i'm curious so nethermine's sort of starting to gear up to work more on 1559 and as has you guys sort of started looking at it is there something that has stood out from your team sometimes if you're here um yeah i can hear

so

Tomasz Stańczak: interestingly i was looking at this potential denial of service attack [Music] before like when i was analyzing just

the just the ap on paper the tre behind it and i i discussed that with a few people and i think we quickly realized that after you calculate the cost of attack then it's it's not that serious for example like with the current current gas prices it would be immediately more costly than uh than 51 attack i think what i what i saw as a potential threat was that this kind of attack you don't you don't need to have the infrastructure in place so you can be a minority miner and start doing that to some extent by just feeling your blocks always and but yeah but it wasn't that's that's critical after we analyze that further

so i almost felt like okay i was over excited about finding some problem and then everyone analyzed it quickly and they said okay it's not a problem

Martin Holst Swende: yeah i i don't know if i follow the reasoning but maybe we could just take that offline so i i'm not sure i understood what you meant

okay

Hudson Jameson: um also um and pardon me if you mentioned this already tim but i think there's like a formal analysis by tim rothgarden um to see and i think that might cover part of this would that be right tim

Tim Beiko: uh so yes there is a formal analysis by tim rufgarden but no i don't think it'll cover that so the

goal of tim's analysis is more around just like the game theoretic properties of the eep so basically you know if we implement this do we actually end up in a spot where the fee market is more efficient you know um but i don't think uh like he might consider some sort of potential uh potential you know attack scenarios but he's definitely not looking at it from like a network security perspective first

Hudson Jameson: got it got it okay thank you any other comments on this all right thanks tim we have some follow up to do offline on this and we can definitely do that um

the next is that oh micah did you have something

Micah Zoltu: i think there's one more thing on the ap one five five nine agenda wasn't there tim

Tim Beiko: oh yeah so micah your i guess your pr around merging the two transaction pools that's what you're referring to yes are we good to go on that i guess yeah i'd be curious to ask yeah thomas i think thomas is the only person on the call right now who's actually working on the implementation so i yeah i feel like we might want to also just ask afterwards in the the discord channel we have because there's more implementers there but uh yeah i'm curious thomas if you have any thoughts on that like the two the merging of the two transaction

pools and the sort of conversion of legacy transactions the 1559 transactions

Tomasz Stańczak: yeah i like this idea because it was very natural for me to start looking at the legacy transactions as the eip1559 transactions with particular property set in a way that represents the the meaning of the legacy transaction it was very natural and all the code works nicely this way you you literally just set the uh the premium to be gas price and and the base and the fee cup is gas price as well in the transaction and then it's exactly the same behavior almost like you said the premium on the new transaction to be the gas price minus the base fee

and that's it and it's just works out of the box i think i really like this

Tim Beiko: i was also in favor and the only i guess the only concern i potentially have is are there cases where some transactions can't be converted for a reason or another um yeah but maybe that's something that's easier to follow up on offline spot as well

it may be good to have an eip uh not update what is the breakout

room

Tim Beiko: so no there's an implementer's call next thursday so next thursday same time as all core devs uh basically six days from now we have an eip1559 call uh scheduled already so i'm happy

yeah

Hudson Jameson: there's two chat rooms and ethernet discord already for it

yep

Tim Beiko: sorry i'll post the link to the call in the zoom chat here if anyone wants to come but i think yeah maybe these issues are easier to flesh out there and and over the discord in the meantime

Hudson Jameson: great anybody else

Tomasz Stańczak: i just want to say that the ip1559 is like so non-invasive that it can be even like we're thinking of merging it to master and leaving as a as a switch in configuration like on the implementation side it's really not much change

okay that's uh i'd love to look at the pr surprising

just because i looked at the the diff on the the guest pr recently it was huge

Tomasz Stańczak: no it took it took just a few hours and drove like 100 lines

okay okay congrats yeah um okay

Hudson Jameson: i think the next item is eip 2938 account abstraction um i think uh enzar is here to talk about a summary of the discussion over the last few weeks and get opinions about moving to cfi uh for after berlin

Ansgar Dietrichs: yeah exactly hi hi everyone um yes just a brief update

um we've been um obviously uh talking about account obstruction since we published the ap a few weeks ago and uh last two weeks since the last call there was quite a bit of feedback um in general it seems like um a lot of people were pointing out that um basically because we have this this design where we the the the consensus changes would be quite minimal and then you could basically in the in the mempool you have you would have iterative versions that would add more and more advanced support for a um and then the erp itself only fully specifies the the the smallest of these of these versions with only what we call single tenant support and like a lot of people were pointing out that there were a few a few

few of the advanced features that they would really want to to see fully spec out and ready to also be implemented before aa would be before they would consider a useful enough so that there was something like libraries and then also a lot of questions around the the compatibility with sponsored transactions um and so we're currently like just trying to just working out the exact specifications for for these features so they would also be ready and then we had like a small issue with with um around uh transaction has uniqueness there was one edge case where that wasn't guaranteed so we we have two two alternative fixes there as well um yeah and then basically um for for for this call our main question would be um is is this erp and currently in a

state where it could be moved to to cfi obviously within understanding it it's not considered for berlin and for for the hard work after it it's still very possible that people think it's not worth it but but in general it's at least we like we feel like it's in a state where the pieces are there so so could it it's at least yeah it's ready for cfi so i just would be grateful for any feedback there

Hudson Jameson: all right does anyone have any uh feedback

Ansgar Dietrichs: i'm not sure who best addressed this

uh context for

uh getting things into cfi were changed to being considered for inclusion if fpr was properly formed and it would be considered you i feel like you guys are actually even further along than you would need to be that would just be my oh no i'm breaking up for people

Hudson Jameson: yeah you're breaking up a little bit but i i think i heard what you said if this was to be considered for cfi in your estimation they are further along than other eips that would be going into cfi at this point or

rncfi yes yes okay okay

and then what would the

process be to move to cfi

it's the

the idea of is if if the pr was right

Hudson Jameson: yeah you're you're totally cut out now james

you might just bring it up here and then if any strong feelings either way

Martin Holst Swende: so i would say from the gut theme um regarding cfi or efi uh we cannot say i don't think any one of us has started this in sufficient depth to say either way but now we're aware of it at least so maybe in two weeks we

say something about it

okay sure sounds sounds good to me sounds good

Hudson Jameson: any other client teams want to comment yeah let's all look at this for the next two weeks and that'll be good okay so um next up we have the yolo slash yolo v2 and berlin state test up update so this is going to be james if he doesn't sound like a robot anymore

i'm hoping they don't sound like a robot do i sound like a robot

Hudson Jameson: very small amount but it's it's

manageable

yeah okay

robot passable robot all right i promise i'm not a real robot yet um updates updates on the yolo v2 from the team from the team working on deploying it is where we start

okay

Hudson Jameson: so let's just have a team go first the clients that are doing yellow v2 i believe are nether mind and geth and um tip of my tongue what's the other one

Martin Holst Swende: open ethereum

open ethereum and uh do baysu start with like nethermine then sure so they um the two aps

Tomasz Stańczak: that were

being prepared for berlin are obviously in there um i was looking at two nine two nine analyzing that one i think it may be one of the more complex ones but i'm planning like a day or two of work for this one so hopefully soon um i was looking at two five six five i believe so this modex and i still think that the construction of vip was not perfect for analyzing and implementing it in other clients and guests because there was this like excel spreadsheet that was um suggesting some libraries that were available in go suggesting some benchmarks that were also like get specific benchmarks and not providing the exact numbers um i think someone responded there is a

new version of dcip there is a new number with some more details so i'll have to look at that one and there's 2935 which i'm super excited to implement and the question is whether everyone else wants to go with this one in yolo because i think there was some one or two sessions when people are asking whether there is a champion for that a number you are saying anything but i would definitely have to have this to have it in implemented and we can implement it in another mind and show to everyone like how it looks how it behaves so they can decide whether they want it in yellow yeah i think that's it right and the 2718 the transaction wrapper so i

prepared some bigger work to enable it and i think this will be fine to be implemented as well so we have like two out of six uh but analyzed all of them and i think the the most controversial for us is two five six five because we didn't feel like we could properly analyze it and compare it with the benchmarks

Hudson Jameson: i think martin had a comment on the magician's thread about having some trouble with that eip too that's the one that kelly

Martin Holst Swende: so to make a long story short the original one was a bit here and there and um didn't wasn't it didn't make sense uh it was then

reworked [Music] and modified quite recently i think maybe last week so it actually makes sense and i implemented that in guess and ran benchmarks and my estimate was that yes now with with the changes in 2565 uh the benchmark results are more stable they don't go off the charts cost twice so uh it looks like it makes sense in geth i can't say anything about anyone else but i think the specification although i know mike has some suggestions about how to phrase it

better but i think the specification is defined enough so it can be implemented i also thought however that for yolo v2 we had already removed 2565 i thought we had removed historical block caches i thought we had removed 2718 and we're only going with the previous two plus 29 29 for yolo v2

Tomasz Stańczak: uh yeah and we got an expression last week too and then i noticed that six of those appeared for yellow v2 i mean i'm fine to add some of them but something definitely happened like uh outside of the conversation somewhere

that added all of those eips back

yeah right

Hudson Jameson: i think it could be an agenda error actually is that are you talking about the ones listed in the agenda

it once listed on this this specs the project on under those specs oh which link is yeah

if those are out of sync then i might need to update them okay so what the consensus is

yeah if you so okay

Hudson Jameson: so can we in this call so we can write it down get a canonical what's going what is going in i guess so people aren't doing too much extra work or anything yep

okay

Tim Beiko: so that would be great from the bayesian side yeah i think we agree with

nethermine and and get it was yolo v2 was yellow v1 plus 29.29

Hudson Jameson: um and the other ones were at this point undecided right

so this actually

Pooja Ranjan: so this excel sheet where we have uh listed all the clients uh uh status uh i think uh the um the eips considered for v2 are mentioned there and some like two seven one eight possibly that is for v3 so that could be referred for like whatever was agreed on the last um breakout room meeting so it's two eips from the v1 plus 29.99 and the decision like as much mentioned that for 2565 it was

pending in that meeting but now that we have clarity on it uh probably we can um discuss on it should be included in v2 or should be considered

Martin Holst Swende: yeah let's just briefly give this status update for gas we have a pr which implements the whole url too and uh we're in it appears so well generated around the status and produced state routes for all the tests and we are in sync with bisous on all of those um open ethereum uh have still a couple of diffs uh when implemented on 929 but they're almost there it looks like um

and so where can i rather go with yolo v2 uh at that time as for 2565 i personally don't think we should jam it in all the way to right now but it would be good i think if the other clients some other clients implemented it and checked if the benchmarks if they look good or look bad kind of that's the burning question i mean it's not like it's for 29.29 it's really lots of complexities and semantic changes but for 25.65 repricing it's it's fairly trivial but we need to ensure that

benchmarks don't show any vulnerabilities and

Hudson Jameson: pooja mentioned the google docs link in the chat that's that's a really good thing to use to see where everyone's at as of the september 21st meeting and yeah so it looks like we have everything from yellow v1 plus 2929 are the ones going into yellow v2 is that right

Martin Holst Swende: yeah and regarding tesla by the way um dimitri has done a lot of work on changing a bit so when we modified the gas costs it made some of the

failures go basically fail because they have expected post states that change and so they need to be modified in order to generate a new set of tests but that's coming along um yeah dimitris also asked me to mention that we've had a guy who's worked on testing documentation and he has written a couple of tutorials for generating tests and how to work with uh retested um so there are a bunch of them actually and if anyone wants to yeah learn more about the test process and how they can use the client to

generate tests and these tutorials exist

okay

Hudson Jameson: um that's interesting so yeah check that out is that just an ethereum's organizations github under testing or is there like a repo

Martin Holst Swende: uh good question it sounded really tested but i cannot say right now exactly where they are

okay

Hudson Jameson: no problem retest is um is yeah in the ethereum organization so if you just go there there should be i'm guessing the wiki or something it'll if it's linked to there it can be found um okay let's go over basu now for the yellow v2 update

Danno Ferrin: um we're in the

same position as geth we have the otov1 stuff done and we're in sync with what tests can be generated for

eip-2929 okay

Hudson Jameson: great and um finally open ethereum not sure if there's anyone who can update on open ethereum on the call or if you're muted

yes yes it's here with open ethereum we are for the moment we're not going to participate in in yolo because we don't have the enough resources to to do it

okay

Hudson Jameson: thanks for the update um now for i guess let's get yellow v2

out the door and then we can consider 2718 and 2565 for v3 and then there was a question of eip 2935 needing a champion but i thought vitalik was the champion or do we need someone who's more active as a champion was that the argument

Tim Beiko: yes

okay

Hudson Jameson: sounds good um i can talk to vitalik about that and just ask if he has someone in mind um and this is 29 2935 champion okay yeah i'll just put that down for something to do i guess

thomas is saying in the chat that he can

be the champion for 29.35 wonderful okay to implement it and to convince others to have it okay

Hudson Jameson: cool uh starting next meeting you can start convincing um because we're gonna yeah release v2 then start on v3 and hopefully um yeah i'll leave it to james to kind of continue on what's what's the next steps for v2 and v3 and everything

uh i've

i've i've been thinking about that and i wanted to get thoughts from the group as far as so there's the stage of doing things on a client integration test then like yolo and then the next stage is to get it on to a test

uh the public test nets i'm hoping i'm not a robot at this point um and then into mainnet so as far as from a testing perspective is there a way by like a testing okay perspective saying that do we wanted to go through each eip and say this one has to test it sufficiently that we should move it over or should it be a we looked at yolo v2 and it's and it's green light tested or is there another even better version

Hudson Jameson: i think that the way it should go is after yellow v2 we

only have one more yolo before going to the public test net if we even want that third yolo for berlin i guess and at that point we cut off what's going in or not because we we aren't adding any more eips to consideration for berlin is what it looks like right or is this list not accurate

yeah i i would agree i would agree with that my my what i'm trying to is bridging the yolo world into the main net world how do we say something is ready enough to go to a test net and what's the process for that

Hudson Jameson: ah i see

um because that's the that's the uncharted

territory we're reaching at the moment

Hudson Jameson: well let's think about how we usually do it we usually and i'd also be fine with having i'll go ahead no yo you go ahead i was gonna say how we used to how we would usually do it is the eips would be haphazardly uh added to road maps to go into future hard forks and then we would uh make a put them on the robson test net and then other test nets like gourley and coven and rinkeby would pick their dates to do their forks as well and usually robston would be the first

and so i say after it's been running for at least two weeks on a yolo net i don't see why it shouldn't go into um why it shouldn't go into something like roxton once we've determined that the clients have all built out those eips the ones who want to participate in the you know test net fork or network upgrade or stuff like that which i mean at this point would probably need to be all clients but um you know besides maybe like trinity or others who might not want to participate at that point it'll just depend so all that being said that was kind of

just a long way of saying after yellow v2 i think we should just go into roxton unless we want to

be more going into berlin and then you'll be three going into the next one yeah as well like it's kind of just doing it sooner and smaller in smaller pieces i guess

Martin Holst Swende: counter argument would be that if we do 29.99 but don't have support for access lists and transactions then we may yeah things will become broken between berlin and the next one

oh

Hudson Jameson: that's right i forgot about that

so

maybe add that one

Tim Beiko: i also think maybe we have like two or three eeps that were just discussed that are kind of almost ready um and you know there is kind of a high fixed cost the main net upgrades uh so if you know i agree we probably shouldn't be at the spot where we're considering something brand new uh but i think if you know something can make it into a yellow v3 in the next two three weeks um i personally would rather see like a single upgrade on my net where we can communicate it clearly uh with the stuff that's like 90 done right now then having berlin and then two months after having to communicate again that hey now actually there's another upgrade with

these other things um yeah

do you think we could have the yellow v3 as uh before the next all-chord devs happens

Hudson Jameson: uh we're not even sure what's going into v3 right

Tim Beiko: yeah i don't think so i think we can have the v2 before the next cell chord f because it's not even up yet but i think and then in the next l chord dev if if between now and then xl chord f we can also finalize what's going into v3 then for the call after that so like a month from now we can probably have v3

Tomasz Stańczak: um i think that with the current approach we are risking this uh

yellow thing to grow a lot before it's being merged would it be better to actually decide which of the aps are connected and cannot go by themselves and then build various networks that would just be dedicated to those groups of vips that have to go together so for example 29 29 and access least together but 2935 would be separate and some other things would be separate and then when we decide that the multi-client test net for the given eip works then we can move it to the testnet like ring kb or girly and we're closer to something that we envisioned in the past of being

eap focused rather than the upgrade focus

Hudson Jameson: yes i think that's a good idea i also think uh pooja if this is your document the one that you linked in the side could you add a column it could be after the meeting but add a column for bundled or dependent or like bundle dependent where we link these two the eips together that need to go in together to a fork um that would be a good idea to keep that straight on the document and the only ones that are linked that i can see from this are 29.29 and is access list even in here

Pooja Ranjan: no it was not like as far as i remember

it was decided that it would not be getting into v2 but it would go along on the

main net

Hudson Jameson: oh because it's simple enough that it wouldn't even go into a yellow net or oh

okay

Lightclient: so i guess i was i guess i was under the assumption that there would be a v3 that would have

27 18 and 29 30. 29 30 or 29.35 sorry 29 30.

Lightclient: but that's what we were talking about here

Pooja Ranjan: yeah for access list it was 29.30 that was supposed to get uh with 29.29 on the main net got it

okay

Hudson Jameson: so that's also bundled so 29.29

uh sorry 29 29 27 18 and 29 30 are all kind of grouped up right yes yes okay hmm that is interesting well we know we're not they're not getting into v2 so we could there is a high cost to doing a main net upgrade but at the same time we don't want to spend forever on yolos um the thing that like jumps out to me though is that a lot it seems like the implementation cost for putting 27 18 29 30 and 29 29 into a v3 seems low or if i remember correctly they all three of those eips i

think were like low implementation cost right because i think they're together

Micah Zoltu: so yeah so for some context the these eips most of them actually started bundled with other things and in order to keep modularity in the eips they're split apart but so it's almost more of a clerical reason that they're split than an actual split

Hudson Jameson: i think we should have v3 be the last yellow and have everything that's listed here try to go into v3 but uh that's my opinion james

i

i'd almost rather if we have something that's packaged and and somewhat ready to ship then it would i would rather us something smaller earlier and then ship the next one once after that rather than push keep pushing berlin back you didn't need to do this and then that will just continually pushing out berlin timeline versus we can just say now let's do the small things we have ready plus any security stuff that martin had brought up and then we can have and so then in two weeks we can have the we can decide like a

fork block for robston basically instead of eight weeks from now just adding a fourth block for

austin

Hudson Jameson: anybody else have opinions on this

Alex Beregszaszi: i'm a bit lost um yeah i'll be trying to keep track which uh eips are now part of this yellow v2 or and which aren't but to me there seems to be uh two categories uh one is is is basically the the repricing

uh of of the the storage and call related instructions so 29.29 and that depends on this entire transaction transaction type uh eips as well so i think that that's one group and they seem to need to be going together otherwise a lot of people would be uh i guess disadvantaged on mainnet and then the second category we have is repricing of pre-compiles which have been outstanding for quite a bit and i heard on tesco that some some clients still didn't have the time to look at those so

they don't seem to be ready and then the last category of changes are which are neither of these uh which includes the new pre-compile uh the bls pre-compile it also includes the the block hash stuff and those um seem to be also a bit more out and i'm unclear you know which of these are are now really close to to shipping and i would argue that the more important one would be the repricing and the transaction types around it unless the the pre-compiled repricings are close enough because those are kind of

small to be shipped

Kelly Olson: so what were you saying kelly before we go on oh yeah i was just uh you know sort of going to agree with uh with you hudson in terms of you know if we could set a you know set this list as you know final candidates for the next hard work uh you know clearly as as access just mentioned some of these uh repricing ones have been outstanding for you know a number of months now so it would be great if we could get those in if they're relatively small changes and not delay them the next part

Hudson Jameson: i see okay um and then thomas you had a do you have a comment about either test nets or

yellow

Tomasz Stańczak: yes i'm just thinking that now uh when i wrote some chance that people started treating yellow as a proxy for berlin and they started pushing for things to go in yolo because they are worried this is the white here to have them on maintenance like the only way so you always just started using different names for berlin really and and then it means that by itself doesn't have the meaning that it was meant to have um i think that what we can start doing is start building the multi-client test nets which are eip specific and when we have all the clients agreeing and implementing this test net and synchronizing it then it can be approved to go to the one of the major test nets that is

available for users so i guarantee robs and ring could be and those those eip specific test nets should always have a bundle of eips that are interdependent that cannot be going by themselves to other test nets so they have to be together if they have dependencies and if there are dependencies but they're not bundled together for example like you you can push um you can push first to nine to nine and to 930 but only later or something like 2 9 2 7 18 you can push it and only later you can push one five five nine because it will require it it's a dependency but it's not bundled because you can push first one of them and then the other so they can be separate test nets but we need to define that they are

having this uh temporary dependency they have to go one after another the other thing is the bundles that can only go together in one hard fork so if you understand the concept so we have the test nets where clients can decide that oh yes we managed to synchronize it between the between the clients and there's like few thousand blocks and everyone is synchronizing it's fine um there are some like quick fast testing and then it can go to a bigger test net for users

Hudson Jameson: if we do that would we would it just be a lot of like smaller hard forks that go on every month or two in your mind at the completion

Tomasz Stańczak: i think it would uh

it would enable it finally as we were hoping for in the past that we could actually have the proper process for uh eip focused uh deliveries

Hudson Jameson: what does everyone else think of that or james specifically if you have thoughts

um i'm

i guess i'm [Music] in between i'd rather just saying stuff will go into the next one and then be better about moving forward with the next one we had kind of this lull for a while which happened with other things beyond uh client work like the

the break we took to talk about other sort of stuff so it would be but i just like that i can i can hear the concerns i want to make sure the stuff that's ready to go goes but i don't want the stuff that's ready to go to wait for the stuff that's almost ready to go because the list of things that are almost ready to go just increases

Hudson Jameson: if we say that list has stopped though and we dedicate to not putting anything else into yolo v3 at this point except for the ones that we've mentioned as possibilities to go into yellow v3 that might solve that

yep yeah

Hudson Jameson: yeah we can just if we get better at saying no then yeah that would work i think what were you saying um micah and james

Micah Zoltu: just to echo what thomas was saying it sounds like yolo v2 really means pre-berlin now like originally yolo i understood it was supposed to mean you know this is not berlin this is just stuff that is pretty easy to implement and so we throw it out there and see how it works maybe it ends in berlin maybe it doesn't who cares but it sounds very much for this conversation like yolo v2 or vlov3 is berlin like that's berlin prep is that correct

it turned into yeah

it turned into that i think the natural process is that stuff goes into a yolo test that

and we don't know if it will go into maintenance but then we start solidifying what actually will go to mainnet through that process so we we started with a maybe things will make it and we end with a this is the step that will make it

Hudson Jameson: yeah and doing it in separate test nets like thomas was um suggesting is a really good idea i think because then it prevents yellow from becoming that pre hard fork um a pre-heart a pre-test net test net that people know their stuff will get in this first one it was inevitable this was gonna happen though because it's the first one so it's kind of hard to not have all of them go in at first i

think i think it'll be easier to say no after this if we put our mind

so

Tim Beiko: i think i agree that maybe maybe uh like if if this time you you want to say yellow v3 is like the pre-berlin because that's kind of what we've done i think the way to avoid that in the future is what thomas proposed um you know having single or small bundles of test nets um that people can try out and then they can just activate one at a time and then that means we'll still need this sort of integration step right because if we want to do say 1559 and i don't know 29 35 in the next hard fork you still need you need some test that where you're trying those two together

and making sure that that doesn't break

Hudson Jameson: hmm yeah i think that's i think i agree with you tim i think for this we should put our foot down nothing else goes into yellow v3 anything that is brought up from now on has to go into v4 or later and v3 should be berlin

Tim Beiko: yeah can we just remove the v3 there's no v4

like oh well

v4 will be the next fork because we'll we'll keep working on client integration test modes or whatever it might not be the next fork but it'll be the next group of vits we're testing

Hudson Jameson: yeah yeah definitely not the next fork necessarily but the next group of eips

being tested and we might not even be able to call it yolo anymore because there'll be multiple test nets potentially with thomas's plan if we if we flesh that out a little bit more offline and agree to do it

Tim Beiko: yeah that's what i meant like yellow v3 is the last kind of multi-eep ephemeral test net and then if after that we can move to like more of a single eve or you know closely bundled eeps that have to be together um then those won't all be like yolos they'll be like you know the

1559 testnet the 2935 that's not the one i like that uh i still need to think more well

i still need to think more about thomas's and uh suggestion and how it fits with

other things but i i think we should think about it and then uh take some uh because that's a change in the process so i want to take a little bit of time

Hudson Jameson: yeah yeah we don't have to decide that today but we do need to decide well we don't have to decide what's going to berlin but we probably should figure out like if we're putting our foot down for things not going in right like i think we we are mostly in agreement with that nothing else should go into v3 right

yes yeah let's get v3 i'm okay with that and then we'll be i'll be better at just saying keeping the scope down on things

and then as i think as we keep that will tend to us having more sort of hard forks because there's stuff that people want me and so then keep going

okay

Hudson Jameson: um that sounds good so is the is the so just to make sure i understand is the agreement for the eips listed on the document puja listed plus uh 27 18.

yeah wait no that's already in there plus 2930 and i felt like there was one more

that's not can we

Tim Beiko: can we list the full list of what would go in v3 and v2 just to make it clear

Hudson Jameson: yeah so v2 we have down that's everything from v1 plus eip um 2929 right

Tim Beiko: yes and that includes the bls pre-compiled if i remember it correctly

Hudson Jameson: i said v1 stuff so that includes bls so v1 is 2315 simple subroutines uh it is also eip-2537 bls curves that's the v1

v2 only adds one eip 2929 gas cost increases for state access opcodes for v3 we would have 2718 type transaction envelope that needs to be bundled with 29.35 historical uh wait sorry 2718 type transaction envelopes that needs to be bundled with the access list eip which i forgot the number 29 30 29 30 29 30 that also needs to be bundled with a third thing what was that

25 65 is it

Micah Zoltu: 29.29 access list yeah we really should not do the gas replacement without access lists like we didn't need to draw both

oh okay got it yeah

Hudson Jameson: yeah yeah so 27 18 29 29 and 29 30 are three bundled ones for v3 and then finally the one that isn't the ones that aren't bundled but will go into v3 um we have a champion for 29.35 and that seems like a pretty small change do we want to go ahead with that for v3 i wasn't sure if that's even was that even cfi uh james do you

know which one is 35 uh save

Hudson Jameson: historical block hashes in state 29.35 i'm blanking on if that one even got very far in the process

Martin Holst Swende: yeah i wonder if it did

i know we had planned on talking about it the breakout session a few weeks ago but there wasn't anyone there to champion it i don't think it's been thoroughly discussed

Hudson Jameson: let's leave that out for v3 as my recommendation so we don't run into more delays since it hasn't been thoroughly discussed although it does have a champion now and it can be one of the first ones to go into the whatever we decide to do after yellow v3 um and then 2565 sounds like a lot of stuff there was resolved recently so that should go into v3 right

or is that one i think no so it's i mean the specification is resolved

Martin Holst Swende: what remains is for all i mean each client team to check if it if the new prices would cause problems for them got it or if it looks good

okay

Hudson Jameson: so is that is that a recommendation from you to not put it into v3 or is that just a statement of what's going on right now

Martin Holst Swende: i think we should not schedule it i don't know it's a bit of a recursive dilemma so i mean if we schedule it um we might have to take it out because it might be another service on some clients if we don't schedule it

maybe people won't do the benchmarks and

we'll never find out i mean event on

Kelly Olson: on eip2565 those benchmarks can be done today without any changes to the gas because we know what the gases for the test vectors and the test sectors aren't changing so if that's a concern right it seems like what we need is just you know basu and another mind if uh open ethereum isn't participating in in these yellow type things to just run through the existing test textbook uh test sectors that are already there

right and then scale it by the actual uh post-games they don't actually have to implement it

Kelly Olson: exactly

Hudson Jameson: what do others think about including this into yellow v3 or not

Alex Vlasov: uh before we go much further um there is a at least that was before the bot has merged uh painting draft to adjust the numbers and in 2537 which is bls 1231 big compile those were just changes of the constants and i didn't merge them uh so like people who already had also b2 implementation wouldn't need to go into the code base and adjust it once again so i can either merge it and it goes into v2

or i can wait until v3 and it's up to developers

yeah wait i think yeah

Hudson Jameson: to make it a little easier i'd say wait but it's up yeah it's up to devs like you said okay um hmm so we're at a bit of a question mark on 2565 going into v3 or not

Kelly Olson: um i mean on 2565 maybe is there someone from another mind or or basu that could commit to you know if they can run the benchmark which is you know likely already in their their testing today you know over this weekend we could resolve whether it's going to be a denial of service issues for them or not

i mean we have run the benchmarks on open ethereum and the pricing was crafted uh explicitly to not cause those issues for open ethereum uh they haven't been run for batsu and neptune so it is work to be done but you know uh you know some of them were relaxed for open ethereum so the question is is another miner bests are going to be slower than either gas or open ethereum

uh can anyone from basu or nethermine comment yeah

Tomasz Stańczak: this particular pre-compile most likely in netherlands might be quite slow i mean that's that's why i'm looking at those benchmarks and trying to find the exact numbers to run it with um

not to not to miss anything that is like the area of attack on the pricing of two five six five um why it would be potentially more expensive is because because we still use their the standard big integer library and the two five six fives only suggests the libraries that are not easily incorrupt incorporatable into netmine because i think there is a gmp library suggested which is uh not on the permissive license it's gplv2 i guess and the other benchmark was done with some like internal call library so maybe that one is more optimized i think this is possible that we can rewrite it in that mind

with the current libraries that we have and it will work but i need the benchmarks to keep exact numbers like some the least i think i mentioned it already like few months ago and uh and there was only this extra spreadsheet that doesn't leave the numbers so just describe some benchmarks which are referred somewhere else

Martin Holst Swende: yeah then i would say let's not

schedule it

Hudson Jameson: there seems to be a little bit of so or not a little bit there seems to be unknowns um enough that if the client devs feel it's going to take a good amount of effort and time to resolve this or there could be things pop up maybe it shouldn't go into v3 like martin's suggesting

does basu have an opinion

Tim Beiko: we haven't benchmark it either um i mean we could in the next two weeks if that was if that was kind of the main blocker yeah but we don't have this strong opinion

Kelly Olson: yeah i mean the only other thing i would add on that is that um you know while the gmp and openssl and other libraries are recommended that's really those are only benchmarked because the rust bigint library is particularly poor performance at this operation which is which is surprising so the go the go library is you know perfectly performant and i would expect probably you know maybe not exact uh same

performance for you know say the standard libraries and net or in in java but um but you know i i guess my point is is that i don't know that it's going to require a library change for those clients so it may really just be changing the gas pricing well and then similarly on the bestu side you know as mentioned before there's not you know in terms of doing the benchmark these test sectors should already exist in bezu so they should be able to be run you know presumably with a few commands um so it should be relatively trivial work without even changing any of their code

yeah

Tomasz Stańczak: so i think that the net library should be very similar either slightly worse or slightly better to the go one it's just the the way the ap was written it looked like it was suggesting to move

from the built-in libraries in towards gmp because they were more efficient so i i started thinking right maybe this erp requires much more efficient libraries to be added which would be written in c or rust or whatever and that's why that's why it looks like a potentially big eip because it require building and testing

external libraries

Kelly Olson: yeah yeah unfortunately that was an artifact of rust having a particularly bad big library or at least for this specific modular exponentiation so you know other libraries other sort of standard libraries we wouldn't expect that so uh a lot of that work was done and modifications were really because of this problem with russ so you know the the goal was to not require any library changes

um and it was even sort of the repricing was done in such a way to not require that on open ethereum uh either

okay

Hudson Jameson: um hmm james what do you think i mean

Kelly Olson: one thing okay yeah i'm just gonna say i'm happy with um with folks from another mind or vesu to collect those benchmarks and you know just just see what the you know gas per second looks like with their current implementation and the current test vectors that are already in uh in their clients

today

Tomasz Stańczak: i think it would be enough to clean up the eip description

and just remove what is not needed remove what was like the work in progress and describe what it changes and i think someone was suggesting that in the discussion the ip is just um it doesn't like split properly what is the change and what is what is the history what is the benchmark and how do we test it

yeah agree there is a there is a new pr that does clarify the three changes that are made into them function and then a slight change the complexity formula so there's a pr and i'm happy to share that in the chat after this call oops

Hudson Jameson: i was on mute sorry um

i'm already i've already heard from from at least one client dev that we should probably delay this one to not put in v3 so i'm thinking we should go with that because there doesn't sound like there's a lot of assuredness about this one being you know not delaying the rest of them i think that's kind of what i'm picking up but it's really hard to find consensus on this one um james

i would say uh let's say basically there's two weeks for res resolve the client concerns and if it doesn't happen

by then then it doesn't happen

but okay

Hudson Jameson: so v3 that makes sense so we have everything for v3 right now except for that eip which is now dependent on these benchmarks if they happen right

yeah if they do happen by the next time then i say we can do it

okay

Hudson Jameson: um so that'll be up to the client teams and then uh also to kelly's team to update the pr and communicate with the client teams um how best to move forward with this um uh does that sound good kelly

Kelly Olson: yeah that works great then i'll work directly with

those two client teams to uh to run through and look at the benchmarks

cool and you can keep us in the ethereum are you in the ether rnd discord if you're not let me know but um yeah there's a channel an all core devs channel on there removed from getter okay great so next up

Tim Beiko: let's fit let's finish this one up i should say yeah can we sorry like i know we kind of did this already but we just talked for another 20 minutes so can we just get like a summary of v1 like or v2 v3 um just to make it easier for

Hudson Jameson: sure so i'll try to do this people stop and correct me if i'm wrong in v1 we have 2315 simple subroutines and 2537

bls 12 381 curve operations for yellow v2 we have eip 2929 gas cost increases for state access opcodes for v3 we have eip 2718 type transaction envelopes and eip 2930 optional access list and then for uh eip2935 save historical block hashes and state will not be any yolos for the time being and eip 2565 repricing of the mod exp precompile will be

determined next meeting if it is going into v3 so to summarize we have um v2 has one of the three bundled eips that deal with transaction types and gas cost around state access opcodes um and then v3 sorry and then yeah so and then v3 has the other two of that three three eip blunt bundle which is 2718 and 2930. 25.65 the repricing of the mod exp pre-compile will be decided next time if it's going into v3 and then is that accurate anybody

um yeah

James Prestwich: uh one of the outcomes of the previous call was that we uh did not want to put 2539 into yolo v2 but left the door open for things after that uh is 2539 also on this list or should i plan on uh delaying that work until after uh v3 as well

Hudson Jameson: i would say delay it till after v3 but james and others what do you think

yeah

the context of last time was that v3 would be post or land stuff but now it's kind of the v3 is getting us closer to berlin so it would be whatever's after that

okay yeah i keep working on it

all right yeah we're uh we're standing up a test net for it ourselves

Hudson Jameson: thanks james great or thanks both to james's but mostly prestwitch oh okay okay um is everyone clear on what okay puja just asked a question what was the question it was um 27-11 oh did we not go over that one

uh that

Pooja Ranjan: was also um in my mind was supposed to be bundled together so do we have any decision for that

eip

Micah Zoltu: it is cfi but there was some issues

people brought up with it particularly the batch transactions piece and then some minor issues with the expiring transactions so most likely one of the breakout sessions we discussed that most likely what will happen is we'll split that out and the first piece of that that will go in will be sponsored transactions i don't think there's anything that's pressing enough that it needs to go into berlin it's basically ux improvements and so i'm guessing that at this point it probably will not make it unless someone someone else wants to push hard for it i'm not going to push hard for it for berlin

Lightclient: i don't want to push super hard but i do feel like a smart are continuing to rack up debt by using meta transactions and so the

sooner that we can give them some sort of layer one uh escape patch for that is the best

okay noted

Micah Zoltu: that is very true there there are like six eips people have drafted for meta transaction standards and on every single one of them i tell them hey this is going to be obviously as soon as we get this and they're like yeah but i don't know how long it's going to be so they keep building stuff yeah i mean if it was if we had a clear schedule for when the next hard fork would be i would be happier to say let's just wait uh wait a second till this next one and four or five months but you know it could be june or later for the next hard fork and then we've like

spent another i don't know eight to ten months of smart contract of developing smart contracts and better transaction systems that are going to be obsolete once we uh have this reach layer one

Hudson Jameson: i understand the concern but we do have to kind of go in order and the first one is resolving the issues that mica outlined so with those resolved we'd be able to better indicate if it's going into future ephemeral test nets and then from there when it's going into a fork i guess

Micah Zoltu: um so if there's if there's desire to get a good sponsor transaction specifically by itself then i could have that extracted out into a separate eip within a couple of days i think my next early next week i would say if there's driving there's not and

that's slow priority for me yeah i've talked to a handful of people building these meta transaction systems and it seems like batching transactions is a pretty critical element so i think that sponsored transactions alone um if that's the best that we can do it may it may not make sense to do on its own

oh okay

Micah Zoltu: yeah batching there's some serious i think it was the guest team that mentioned it but i think other teams reiterated that batch transactions create a bunch of complexity in the clients that people wanted to avoid and also it overlaps with rich transactions and account abstraction which are also going in so it gets hard and complicated especially with the timeline on berlin

that seems much less likely if that's requirement yeah i'm planning to implement some uh derivation of 2711 over the next few weeks so hopefully maybe by the next meeting can have a little bit more insight to what that may actually look like on an implementation standpoint

Martin Holst Swende: so which one which one specifically are we talking about fast yeah yeah i'm thinking of doing the batched and the sponsored transactions as one implementation so the problem with batched isn't so much the what the implementation will look like the problem we see is more like theoretical um that you in order to verify the batch um i have i mean

right now if there is a transaction which concludes one million gas you it either works or it doesn't and it charges something but if you have a batch and you execute 10 transaction and then eventually find out that no um the batch the total batch cannot be included in a block because the tenth transaction cannot be executed because number nine uh burned uh the remaining value or something like that so yeah so i mean i i think like the idea

was that each of these transactions in this batch would specify their own gas limits and then the overall batch would specify some gas price and a signer who would who is basically saying that they will pay for this entire batch of transactions and all that needs to be done to validate it is they need to go through and verify the signature for each of those transactions if it's not the same as the overall sender right but they can have interplay effects right so if one of the transaction makes a later transaction invalid um then they all need to be well how can you want them to be applied atomically right well how can you make a later

transaction invalid because we can already verify in constant time if the transaction is valid so that means we should therefore be able to verify in constant time if all the transactions are valid

Micah Zoltu: i think there's a miscommunication here so there's there's there's two ways we can go about this one is the entire thing is atomic at either all the batch succeeds or all the batch fails the other way is it's not atomic meaning that each individual transaction will succeed or fail on its own and they will charge gas separately if i remember correctly there's a separate problem if you go with the ladder which is i think what my client's talking about where the they're not atomic but i don't remember what the problem was i guess brought it up i don't know if you remember martin

i think we're we're getting kind of closer to the end

of the call so it might be just from a yolo v2 v3 perspective that there's more work that needs to be done than it can for this time but i if if the next fork is in june i don't think we're doing things correctly so i i would much rather it be q1 of next year we can take this offline i can spend a little time and think through some of these edge cases as well

okay

Hudson Jameson: thanks okay is everyone clear on what's going into yellow v2 and v3

and we will have this in the notes and updated in the chart i'm guessing um that might already be worked on actually

yep yeah and i'll create separate tabs for yellow v1 v2 v3 all stay together in this excel sheet that would be helpful for people to drink it

Hudson Jameson: thank you the sheets really well done everybody who'd worked on it i don't know who worked on it i'm guessing it was puja and james um next up i had light client comments on a few eips and we've already gone over all of them i think except for maybe the status of 2584

Lightclient: um yeah that's right

Hudson Jameson: that was guillaume

and he's not here to talk about that did you have an update light client or were you just wondering uh i mean i am wondering what the status of the binary tri migration is and i'm generally just curious to know what people are thinking is the status of stateless ethereum in general because i think that it's an important thing to have before we have phase 1.5 which is potentially going to happen in the next 12 to 18 months and stateless ethereum has been uh you know in progress for about at least a year now and it seems like it's really cooled down in the last four or five months and i was just wondering uh if anyone has more insight and so why that is and how we can

reinvigorate it um so one thing that i'd say about that is that the primary people working on that would be the quilt team right i don't think the cool team is the primary uh people working on it i think the primary people who were working on it were you know piper was sort of leading that effort so there was a lot of work that piper was helping coordinate around the witness spec i think there was someone from turbo guest and maybe paul drazki spent a little time on the witness spec and and then obviously guillaume has spent

some time on the binary trial migration but it's to me it appears that a lot of this work is like reaching the point where it's getting solidified and it's starting to broach into you know getting it through governance and it doesn't i'm not seeing what the clear path is like we have a an eep that says how to go from uh patricia merkel tree to a binary tree but there's no one who's coming here to you know ask what are the next steps what are the next steps and i'm afraid that we're going to go six months down the line without this happening and then you know phase 1.5 is going to be right around the corner and we're going to get into a situation where we're going to ship phase 1.5 and every e2 validator has to be a full

e1 node which you know there's concerns around that yeah i understand i think talking to piper would be the best bet because i know he was at one time like you mentioned leading it up um see if that's why that's dropped off and yeah i'd be interested to hear why it's dropped off myself but i don't know if we'll have any answers today unfortunately fair enough yeah that was a very interesting um piece of research though that i'd be super curious to hear where the full status is of it

uh as far as i'm aware they're still working on it we just don't have oh you're meeting james you just talked

and then got muted the right people on the call to give updates yeah oh um that the the work is ongoing we just don't have people on the call to give an update on it is there anyone on the call who has like better direct communications with these people and to ask them to come to the next meeting or start coming to meetings a little bit more regularly

you almost only thank you

Hudson Jameson: thanks martin um we have about six minutes left there's nothing else on the agenda did i miss anything is there other discussion points or updates uh ansgar you had a comment um oh that was just a comment i thought it

was a question maybe uh just about the yeah go ahead

no

Ansgar Dietrichs: i just wanted to say there were there were some concerns about how to best uh like um combine a and sponsor transactions obviously i don't want to kind of uh hold up the progress and sponsor transactions just something i will be looking into over the next few weeks to figure out to just make sure

there's some duplicated effort there that's all okay

Hudson Jameson: great um is there any other updates from anybody or discussion topics okay looks like we can probably end this one early um i do want to mention um that i'm starting to brainstorm ways

to improve the all core devs call and just our processes in general so we're not like starting to get known as the bitcoin uh you know ossifying very slow never does anything layer um so i think that i'll start pulling people in and if you're interested in being involved in that reach out to me but i'll pull in some people to kind of help brainstorm some around some of that but if you have good ideas about how to make the meeting better or feedback for myself or for james or others who usually play a bigger role in the call please reach out we love feedback uh hurt my feelings let me know where i'm doing bad

uh hit me up all right the next call is going to be october 16th at 1400 utc thanks everyone for joining have a great day

cheers thanks edson thank you cheers [Music] so

[Music] [Music] [Music] so [Music]

[Music] [Applause] [Music] so

[Music] [Music] you

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