All Core Devs - Execution #96

Transcript

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

[Music] [Music] [Music] [Applause]

[Music] [Music]

[Music] [Music] hello everyone and welcome to ethereum

core developer meeting number 96 i'm your host hudson and we're going to be talking about a good amount of stuff today so we'll jump into it i just updated the agenda if y'all will refresh your page it should reflect the latest request from the agenda comments um and so the first item we were going to do eip upgrades eip and upgrades updates for yellow and yellow v2 but because it was a holdover from last time let's go over eip 1057 first so tim's going to facilitate that part of the discussion because it was requested that someone other than me facilitate that discussion um and uh so that decisions can be made

more clearly was my understanding so tim go right ahead okay uh so i know that greg you had an update last time and things you wanted to go over i think it probably makes sense for us to just start there for you to maybe give like i don't know 30 seconds summary of where things are at and what you'd like to see as a decision moving forward and i think one thing that's like not been uh good in the process for this is just there's been like a lot of implicit decision like so maybe it'd be good for people to i don't know to try and get something more explicit about where we stand on on this after greg has kind of shared his

thoughts um yeah greg over to you okay unmuted yeah this um the prague pow proposal has had a a long and unhappy history um i think it was may of 2018 that it was first proposed we reviewed it uh tentatively accepted it after about seven months of review um people then um woke up got very angry yeah there was a lot of pressure we had a software audit a hardware audit we took it up again we decided that yes

we were going to put it in we published number decisions to do so two weeks later um there was another outcry um some people came on the call who weren't usually there uh one of them insulted us terribly and somehow at the end of the call the decision of the previous two weeks it evaporated and in discussion since then um it was rather not clear what had happened but the most that we could decide is that people were more or less happy with um bendy francesco's compromise

and where i'd like to get to today is either a decision that we actually publish and actually stand by that we don't intend to change it without further serious discussion to go with that compromise um and that compromise we've stated at the at the very top of the current pr uh and we'll remove it once there's a decision one way or the other because it's usually not the thing that would go into an eip but um what we've got here prague pow people

should know by now is a proof-of-work algorithm to replace ether eth was designed to be asic resistant and it no longer is the a6 have caught up and prague pow is proposed to make it uh very very difficult for asics um to get an advantage over gpus um and there's every reason to think by now that it will succeed and every reason to believe that it's a sound algorithm without any bugs and without any design errors so we do not propose that we deploy it immediately or that we

choose a hard fork right now the compromise ban recommended will state as um that we should fully implement it and test it across major clients i believe that is actually already true for a lot of clients and that the clients who do implement this proposal we should deploy on a test net and maintain it on a test net ready to go um to leave open the possibility and threat of future deployment um that means we can keep an eye on the network um

try to uh keep an eye on what hardware is mine finding the network and what they're doing and if we don't like the way it's going because of asics we can switch to the prague pow hash function and kick the a6 off of the network and hopefully people in the business of making a6 will be aware of this and they can factor that into their business decisions as to whether making uh ethereum asics is the best use of their resources and that's that's where it is now so let's open up discussion on that

uh i'm curious about the this kick exploit that was latest determined that it was not actually practically feasible and what happened with the specification did was the specification changed or did you undo those changes or and what's the latest um i think yeah the latest pr um we spent many months um looking at that exploit there is a fix that would make it impossible for that or any similar exploit but kicks exploit we've decided um is literally impossible you can't

pull it off there's all kinds of obstacles and if you get past all of those in the end other clients will look at the blocks you're producing and reject them because their hash is andrea if he made it online can can explain that in some detail if people are really uh interested but it just it's not an exploit that's of any use you've got to make your own asic uh you've got a brute force a table within the block time um you've got to modify the headers in a way that that you're not currently allowed to modify them

is just not exploitable and there's things you could do to make it exploitable but that only makes it more complicated and more intensive so it's just not an issue we don't think it's worth trying to fix um given that we've already audited the code and algorithm we have so the specs been changed just to move that down to the security section so that people know it's there um if in future we think that somehow someone's found a way to uh to get around this we can we can drop the fix in because it didn't take but a few days to

find a fix there was also a vulnerability which the software audit found and that's actually an eth hash vulnerability as well it's it's nearly impossible uh to do on eth right now a few years down the line with better hardware maybe um with um prague pow that vulnerability

it's wasn't clear from what the audit thought and from what we thought that it's even possible to exploit so again we're uh not putting it into the current uh proposal although the security section does discuss it a little bit as to as to why we've decided to let that be um not worth not worth messing with audited code um to put in fixes for vulnerabilities that are damn near impossible uh to exploit and that's the lighthouse evaluation attack right okay pretty much if if we don't think it's worth fixing

uh ether um it's it's not worth fixing product dow where it's not even clear you can exploit it so they have the same level of vulnerability or is there still a difference but it's uncle but it's not worth doing an extra amount on current hardware it's almost impossible to exploit um with eth hash and prog pow makes it so much more difficult it isn't clear you'll ever be able to exploit it okay so it's it's the case that they both have it ethan has it at a at a is at a greater risk although still low

and has it as a less risk and it's not worth doing anything else about because of it yeah much less somewhere three four five years down the line ether might become more vulnerable uh question so with the do you guys know with the current implemented version in the go there my parity um [Music] is that does that do you know if it needs any change

no this this is the code that's been audited this is a code that's been running um uh so we're proposing to to stick with that code um i think in some clients it was implemented well over a year ago um and the reference implementation's been there for a long time so basically if we were to say yes we should go ahead with this compromise the task at hand would be to merge it and activate it the rest exactly yeah um the so the ask here i

i think on the technical side it's very little am i right on that martin uh yeah okay so so so the bigger ask is that i am not presenting this as yet another delay um you know i'm presenting this says we remain serious about this and we remain we remain serious about um not letting a6 become a threat to the network that pretty much whatever the community

sentiment is and sentiment being being defined as feelings i'm not concerned about people's feelings i'm concerned about the security of the network and we have to keep a close eye on that and we do have a way to shut down the a6 um if they look to be a problem so the the the decision is whether or not it gets deployed on the test net that's the decision we're trying to come to today deployed and maintained in a way that it that it can be moved on yes and one thing that's part of that is also mika has a comment in the chat about nethervine but i'd like to hear just like from the

other client teams about the status like uh yeah it's like because i i guess there's kind of two things you can do there right like if it is implemented in all of the other clients then great uh if it's not then maybe it's if we go ahead and deploy it on the testnet you just take the implementations that are ready today and you know don't force it on other clients to implement it um so yeah i don't know that their mind i don't know if anyone from trinity is on um yeah yeah i don't see a need to force it on to all clients as long as we have a you know a reasonable number and there should be enough warning if we make a decision that that other clients

can can pull it in if we decide to go with it at some future point it's it's still good to get updates from the clients of course i want to hear that are we already talking about the uh the it hash replacement like the procbo uh yeah we don't have it connected but uh i remember talking here to pablo about ability to connect the library so i believe there is a c library for it and the bindings to see from c sharp are they not that much work so we we never considered it would be a lot of work to add prop power if needed for basically i know we had an

implementation but i'm not familiar with what version of product probably was so i guess it would be you know some work potentially to brush it up but not starting from scratch um and i don't know if there's anyone from other client teams here sorry there's there's more than one screen of participants on this call which is yeah makes it hard to see everyone promo these changes much like one year and a half ago i'm not sure about status of that to be honest okay so i guess we can assume also it would be like you know behind where it needs to be and there need to be some brush up yeah we can assume that so we forgot to open it here my as i

think i remember a couple months ago um the open ethereum team announced that they just deleted all parts of rockpow and they don't want to maintain it anymore and they don't want to support it so it might be good to to look into that part yeah i agree with that there's there's still some changes in the code but i'm not sure about status so we talking about test nets the yolo v2 is a click is a click network probably doesn't make sense to uh add a proof of work

aspect to that am i correct on that yeah and just maybe to take a step back i think it's worth considering do we want this bundled with anything else at all right um just like because they're you know there is the perception of like this moving forward and then being included on main net despite still having some pushback uh in the community um yeah i'd like to at least like consider if we go ahead and deploy this on some kind of test net it should probably be like isolated in a way um yeah i don't know if anyone feels strongly for or against that

so one essentially roxanne is we've talked about it for years that robson is getting too huge to be used and it's full of spam and it's it's pretty much everybody's just using green kaby or girly and um yeah i think it would be perfectly fine to create a replacement for ops i mean we nobody wants to kill rocks and we can't kill it anyway just it would be nice to launch a proof of work test and that's not robston and if yeah we just we can just uh drop crockpot on top of that and it's not like we would lose the testability of 80 hash since mainnet is running ether so

if you can participate in mainness then your code is probably correct so there's no loss in not having an ath chestnut in my opinion so would we would we have it if we were to release a prague pile test a proof of work test net that had prog power on it would we want to just do it as is today like at muir glacier or should we wait for berlin and have it be uh the new version upgraded or should we does that even better to

separate these two things so release the testnet and don't bind it with the name it'll be easy to do the transition later okay so then we would launch it uh at muir glacier progpal testnet proof of work test a proof of work test net that the new one that happens also to have brocco now well you can probably launch it on et hash and then switch over and block then or block a thousand or something just so that the transition is somewhat tested oh yeah that's a good idea and that for sure should be around your uh with your glacier code so then we're we are operating on like real testing of not not testing multiple

things at the same time so uh i hope this doesn't do real things and i don't want to so we don't have to actually talk about this but i think the reason that developers are not using robson isn't because it's too big it's because it's constantly under attack um like every time i try to do anything on robson i've got to wait half a day or try to get mine because there's some miner out there who's farming robson test.net and refusing to include transactions again i don't want to do a little conversation but someone mentioned that ops is too big and i don't think that's the issue it's the attacks on robson that are the problem yeah probably both yeah it's a bold thing yeah but anyway um so maybe

maybe people maybe dubs will not use robston or a follow-up to robson anymore but uh but i still think robson is pretty much unwieldy at this point so i don't see it would be nice to have an alternative and even if it won't get major usage so basically what's stopping you know the proc like anybody can kind of start their test net if they want uh but like yeah what's stopping you know the program people from going ahead with that um is it the fact that like the test net has to be started you know by the get team is it no it's just the proctor is not merged

in the client so probably you want to have it first motion and just do some minimal clients testing just to make sure that everybody seemingly is okay otherwise it is so it should be sorry i was gonna say i mean the code should be merged and the bindings to activated should be exposed so that somehow you can create the configuration or command line switches to activate it at a certain block uh i think that's the ask and just i guess another another kind of

topic we've been talking a lot about in these past i don't know a couple months is uh the fact that client teams have a ton of work to do and and a limited amount of bandwidth to do it um so i guess i'm just wondering like you know is is what you proposed martin like you know we just merged in the client you expose the bindings is that a way that we can just like enable people who want to work on prongpal to go ahead and do it with like minimal involvement from the client teams um if they don't want to be involved yes i think so because yeah then they are going to be able to

use actual geth version and they can spin up test nets with all the clients who implement it without having to use pr which is bit rotting away and yeah then we wouldn't have to i mean we wouldn't have to maintain and test it and get per se it could definitely be outsourced yeah and i guess that's just what i'm trying to get also from our team i think it's something we don't you know mind if it was included in the client and whatnot but like there is the ongoing maintenance cost of the test net and um yeah i i would rather not bear that cost if possible but i'm

curious yeah with other teams and also greg how possible you feel it is for like the the program people to to take on that cost like if it was exposing the clients um yeah um i just want a point i mean we run uh quite a few notes in the ef and they usually require pretty big machines but if this is more about not that full blocks i mean there are not going to be a lot of depth developers on it and there's not a history of 10 million blocks uh i think the actual require hardware requirements running it are going to be fairly

low so the costs from that perspective are quite low probably then of course there's a maintenance overhead i don't think that's necessarily part of the ask i mean i don't think they ask is hey can can can ethereum core developers please maintain a test net for yeah that's just what i want to make explicit because again like we've had all these calls and and like people come away with different understandings um so yeah is that i guess is that something greg you think would would make sense for praguepal if if it was added as part of the clients

uh in a way that allows you know um that allows people working on frog cloud to launch their test net to maintain it kind of as a first-class citizen of the client but then uh to not have the core developers have the like maintenance burden and just you know management burden of the test net and and then and then uh discussing it on every corner call and whatnot it just feels like this one decision that can create like a a lot of like ongoing work um yes it i think martin's explain the work that's involved uh for the clients right now um i'm not asking right now for for volunteers to

um or paid people to to keep such a test net running just some commitment that we're going to lavia obvious we'll have to work on who's going to do that like we always do but i don't see doing that right now if there's a commitment someone will probably stand up to it maybe me and if nobody stands up to it then like other things it will fall by the wayside despite the commitments sorry just a quick point of order can i suggest that we try to move on to the next topic within the next couple of minutes because there is quite a lot on the agenda yeah um it's also very important to settle this

it's been years yeah what else needs to be settled though um i'd like an actual statement published in the notes numbered decision that we intend to stand by so is it is it uh check the chat yeah is it the uh what's the right word like is it good for you if kind of the consensus is you know clients agree like to to merge this you know outstanding prs in um as long as you know they're they're kind of good quality and whatnot um and and that will allow you know prog pal

champions or the proctile community to stand up their own test nets um and manage them as they want but the like the client teams don't want to explicitly take on the responsibility of managing those networks um and having to discuss them on every quartus call and whatnot um with that that's i guess first of all does anyone like strongly disagree with that and second of all would that satisfy your your your concerns craig that's what i'm proposing i'm hoping we have a consensus i don't know if you feel otherwise but i

think we're on board with that yeah sure it works for us i mean we have the code it would be nicer to have it merging and not big truck other than that well everyone can launch their own intestines so there's low no dependency on us so to see so clients merge prog pal code into the code base so it's in an act and it's in a release it isn't activatable for mainnet but it is activatable for people making a test net and we encourage a new proof-of-work test net because

robston is becoming big and then that's it yeah and that test net isn't necessarily maintained by all of us here um yeah yeah i think a nice approach would be to have the code margin that's that kind of that work depends on clients then the community can launch their own proof of work crockpot test that i think that test that seems to be in one piece after i don't know however many weeks or months and if people feel like it then clients can just add default conflicts to to bake it in so so what was that sufficient decision for you greg okay so if i can state it clearly um

the clients um client teams are agreeing uh those who are agreeing to to merge their prague pow code i believe that is essentially the code they already have perhaps tweaking some constants um to merge it in in a way that it can be activated on the main net but it will not be activated on the main net at this time yeah i think that's it and and by i think the activated on the main net part is maybe a bit confusing like

you know available yeah yeah exactly it'll be exposed in the client it's like a feature you can use right but it's not but it's not being merged there's no block there's no heart yeah exactly yeah yeah and and just one last thing and hopefully we wrap this up in the next minute after that but uh andrea has a question about what's the grade of trust we give to a non-official test net um yeah i don't know if anyone has strong opinions there i don't think we've ever considered a differentiation between an official and

a non-official so no i mean the only thing about the po8 testness that we have is that they do require maintenance because someone has to actually run designers and someone has to do the necessary uh unscrewing up when things are screwed up for prior w testnets i mean they just are there's no maintenance really there's no difference between unofficial and official since there are no authorities yep i feel like that's a great place to end this conversation uh so yeah i think that'll be recorded in the notes um hopefully yeah it doesn't come up on the

next call uh and we can all like do you feel like it's kind of address the uncertainty to work greg yeah can you state exactly in english what the consensus is yeah i've already i've already stated agreed okay then then it'll be recorded in in the notes okay number decision we're done with it all right thanks so much tim uh for for handling that one yeah um thank you tim we can move on to um the next part um so the two things we have we have a couple people here who wanted to talk about their eips but before we do that something more

pressing is both the yellow v2 test nets and the feedback from breakout rooms because there was um some confusion and just general feedback about how that went since the last meeting so let's start with yellow v2 and just get some line items done there that james was wanting to talk about uh i actually wanted to have us talk about the eips related to yolo v2 first oh perfect yeah that's fine to move that down um we can have that be later i want to make sure we get to the eips that need to be discussed relating to yolo v2 first okay yeah you can go ahead well that's the or wait am i missing

something that is bls um oh no i have now the agenda's changed again no i'm confused the bls curve eip 20 29 and 35 15 are the are those eips okay um like can you go through each one maybe one by one and see the updates and give the name of the eip um yes well i saw that james prestwich came on to talk about the bls381

377. so that's going to be in reference to house um i hope i'm saying this right cello can help with it i don't know if it's in reference to any updates that are related to yellow v2 yeah i'm i'm there i'm not looking for updates on yellow v2 i want the discussion for the eips to happen uh okay cool we can start with that one then if you want yeah so we let's do the bls curve eip 2929 and then 315. the eip315 discussions because those are related to yolo v2 decisions eip 315 yes 23 15.

23 15. i was reading off though leaving off the first number got it got it okay um cool then that would be um james if you want to give a quick or james prestwich if you want to give a quick spiel for what um you were wanting to talk about uh yeah so our main thing here is at cello we're planning our next hard fork which is going to include a bunch of the things approved for berlin as part of that we started looking at the history of eip 2357 the bls381 precompiles and stumbled onto 2359 as well so matter labs as part of the bls

pre-compile work put together proposals for three different pairing groups um last time this came up in an all-core dev call it was decided to uh you know because they're extremely similar pre-compiles move forward with the one that has applications to eth2 which is uh bos 12381 eip 2537 and to shelve the others until someone came forward with a concrete use case uh so at cello we're considering eip 2359 2539 for inclusion that's the 12 377 pre-compiles uh because we use bls 12 377 throughout

the 377 like curve groups also have some ancillary benefits to recursive zkp's uh not fully recursive but one layer deep and to aztec and alio and a few other like zero knowledge oriented projects in ethereum um so what i wanted to talk about today is that we're going to be including both of these eips alongside each other and would love to be able to contribute the time money and people to upstream that work to geth open ethereum and nethermind so to be clear the only curve that we've

decided on for yellow v2 or uh or as inclusion to berlin either one is the bls 12 381 not the 377 is that correct yes that's correct but you're wanting to contribute code for 377 for potential eventual inclusion into an ethereum hard fork right uh yeah we would like to contribute time and code to both of these because we're going to be building them into a geth fork regardless uh so we have already you know high quality go and rust implementations for 377 the rest is already implemented into cello blockchain the go is by the same implementer who

did the uh geth 381 work um so because these pre-compiles are so similar like they're almost spec respect the same with the curves changed um we feel like it's very small additional work to include 25 39 as well as 25 37. and we're prepared to do a bunch of that work and would love to get it uh considered for yolo v2 and potentially for berlin i object cool um why martin um i don't think

that it's i mean for yolo v2 we're kind of hoping to roll it out like now more or less and just throw in new curves 12 new pre-compiles because they share the same form as the previous ones uh yeah i i think they need to be fast tested from the ground up uh for a long time um before there can be any you know before it can be considered proven to be mature well the implementations especially in

rust are already mature and deployed in the wild the go implementation we are prepared to do the work for fuzz testing that and you know doing the integration work we will be doing that ourselves for our own get fork in the next few weeks anyway um james hancock what's your perspective on 377 in berlin or yolo v2 um because i have my opinion but i'll hold off for now the it's the so i read the concern that that the bls precompiles are complex and require a lot of testing and fuzz testing and so if ceelo wants to do fuzz testing

i i would think that that would kind of help your concerns martin but i does that does it like if a team is willing to do to help with fuzz testing and resources to make sure that both are safe and you still and you still and all and the core devs are still able to say is it enough or not like it isn't like we hand it off and say it's just going to be whatever if they say it's okay then it's okay but if they actually do a lot of fuss testing from the ground up for both pre-compiles then doesn't does does that help resolve concerns around security for both of those uh can i answer that yeah so uh this is similar to the original bls curves

and the things and [Music] the original bls curves were fast tested for weeks on end and months on end and then marking came here with marius and they found about seven or nine consensus bugs including assembly issues so from this perspective uh the fact that an external team fast test does it is not assurance enough that it's actually correct i think that's one of market's problems well here i should add from a completely practical perspective well first of all change your pls 281 to 377 is trival parametrization change um so it can be just taken a current code base uh

butcher like 20 lines of code and make it for a new curve and the second it's always confusing when you say you found a lot of consensus issues yes there was a problem with assembly which wasn't called by me in go because i didn't try this particular assembly backhand but the rest of problems wasn't in the part which is not under the control of client developers uh so like the biggest objection was that these precompiles are too complex and there was never a like there was never found an error in actual mass implementation for all these pre-compiled uh there were some a little bit trivial mistakes

in the integration of the code base and some constants were wrong at some clients so i think this is much this is not like uh i don't try to say that it's uh not a problem it is still a problem uh but it doesn't inflate the complexity of that changes and pre-compiles in general and as just kind of history shows like fast testing is a core part which is can be considered like a black box by client developers as is first of all easier because it's stateless

um and then which is done much more proper than it's usually what people think yeah so my point really wasn't to to try to dig up past rather but my point i wanted to say is that there's always some room for some errors and uh and essentially it just requires effort conscious effort from people who've been doing this for the past five years just to make sure that it's actually okay maybe there's high chance that you are completely right that if it's just changing a few constants then it's probably not much that can go wrong but still i would argue that if you

change a few constants i don't know what implication that has on on the assembly code i don't know whether it takes different paths or not so yeah these are yes you are right that there are probably nothing that can go wrong but somebody still has to be convinced of that yeah yeah i mean there is always possibilities that anything can go wrong with any change in the code base uh so but there should be some merits uh what is sufficient to consider that this code is kind of safe and nice enough to give it a try and i just argue that for such changes there are kind of separate parts one is integration another one is

mathematical implementation and the letter can be very well tested and there is already experience how to test it and even the change in it can be very small yeah um really quick uh because this is like we would not be considering this if it were not a minimal code based change uh to the existing 3d1 work uh because it is so similar in implementation and the math is essentially identical except for parameter changes uh martin would it be sufficient for you uh to consider it if we brought it up to the same testing and integration standards as the

existing 381 work i am sorry to say no because not that i don't i mean i think that if we want berlin to happen anytime soon then we should just put a lid on it yeah i was i was going to say that martin's concern wasn't addressed the fact that we've kind of been doing this for a while with berlin and adding something at this stage in the game is would be would just make it that would provide a precedent that anyone could just come in after this point and add even more eips than we've already been adding because last week we even added some more

like some stuff from uh the one that is a security thing for doses and um other stuff like that i forgot the number of it but yeah so i i think putting it putting three was it 377 was the one 377 in berlin bls 12 377 would be like not possible at this point but that's that's my opinion i wanted to hear it i mean nothing is possible but i um i would object yeah yeah yeah that's what i meant is there any decision or like a time frame when people uh want to implement berlin uh if we just don't look at it as well we

have to fix those vulnerability with use these changes to uh storage of code so we have to rush it as soon as possible because berlin was planned first to summers and was also very delayed and so i mean i didn't see any dates or like some solid intentions for people to include it and at least to understand uh what is uh sentiment in this area would be uh interesting to hear that that is going to be a long conversation and i want to i i want to wrap up my thoughts on where where i am with this so i do so the sentiment of let's not add things to late berlin i definitely agree with

my cur my current concern around the just the bls precompiles in general is i i still observe that there is more testing that needs to be done before it is considered safe for the network and so if so if it's the case that adding this other eip delays berlin then then yes i would agree uh with hudson's point if it's the case that we can have some more resources to help make sure that testing gets done then in fact it could help make berlin be sooner because the both if both of them are being tested more than the then the original bls precompiled eip can be reached can reach a safer point quicker

which then means berlin can be sooner and yeah in case i wasn't like completely clear before the proposal here is not we're just going to add a new eip to the plate what we'd like to be doing is spending time and resources on helping with the testing and integration of 381 and as a consequence the testing and integration of 1237 becomes almost trivial got it okay you had mentioned that you had wanted both in berlin that's what confused me uh i would love to have both in berlin and i think that we can

bring 1237 up to the same standard as 12 381 very quickly um i'm not i'm not looking to push back or delay berlin this is a if we can get it in on the time frame and to the same standard as the nearly identical approved eip and and help with the testing and that's why the nuance of that i don't that i that i don't know and the question is if the celo team is being is helping with the other with the original bls pre-compiled testing is that something that will

accelerate us to be being able to say it will be safe for maintenance well and will that happen regardless of if 377 goes in or is that like a condition of cello helping um it is not a precondition uh what we're doing right now is trying to plan our hard fork timeline and part of that is going to be dependent on berlin's timeline and what eips are approved and implemented for bruin we really like maintaining upstream compatibility and we're trying to contribute back to the upstream repos more going forward that's going to be a big chunk of my job

from now on is trying to help contribute back to gath and open ethereum okay um it's not like a blocker for the resources but we do need to understand this process a little better so that we can prioritize understood i think just to wrap this one up uh because we don't need the death team to be a broken record um not in a negative way but in a like we we've heard their concerns i regardless of people think they're valid or not they are concerned so it sounds like 377 won't be going forward at this point um from a decision standpoint today it can definitely be brought back in the future as a item um but i don't think a decision on 377 is going to change today

based on the primarily on the guests team's opinion so uh i have a quick like process question on that um you know reviewing the past all core dev calls uh and you know as you said earlier we approved eips as recently as the previous call was there a concrete decision taking taken to you know like stopping that uh what i would like to know is how we can uh better interact with and facilitate this process and make it easier on you guys going forward for the next time sure and i think the difficult way the difficult thing in answering that is

that each eip has different levels of complexity so it's treated with different levels of scrutiny on whether or not it can go into things like ephemeral test that's like yellow v2 or into eventual hard forks like berlin so when it comes to what you can do to best get like solid decisions it's going to be on a per eip basis but i can say for 377 my opinion on that is that because it is more complex even if it is similar to 381 because it is still has high complexity and is different than a lot of the other arguably more complex than any of the other eips going into yellow v2 besides bls 12 381 that we uh where was i going there

that it probably like is going to require a lot more discussion a lot more offline discussion so um i don't have a great answer for you this process the all core devs calls in this process has already always been messy that's kind of how decentralized governance is and i think that's the best i can give as far as an answer uh cancer to work in principle allowed to set something which would be considered a standard for like how much any particular eep or like let's say complex eve should be worked on and tested to be included not like in principle without objections

that it's too complex if it's tested to a certain degree i am not since i'm not on the testing team i can't speak to that but i can say that that doesn't sound like a bad idea in my opinion that would be something if someone came up with those standards and then presented them to those who do the bulk of the work testing it would kind of fall into their lap since they're the ones doing the work that's my opinion so basically i'm just kind of saying you can do whatever you want whether or not it's accepted by the broader people doing the work is another question did that answer your question alex well i mean my question was just to have

a certain degree of consistency in the process in general and like this work by james i hope it will allow to kind of make a standard for exist we already seen historically how like what work was done for uh 381 and was recent testing by guest team for uh consistent consensus tests and status so i think we can just try to follow the same process and document it a little more so it will be just one to one correspondence and then it will not scare people that it's just uh too difficult to implement okay i understand uh does anyone else

have comment on that i thought i heard someone unmute but i could be wrong okay um i have just a general one which is i still um um the the biggest unknown for me related to berlin is how much is sufficient testing for the bls precompile and at what point do we reach there just just in general like the the the eip that is already being considered because the the rest of it is all pretty clear about what can happen and when can happen and that's that's still kind of the

unknown to me oh well here you can try to separate this into i would say three different parts one was more like one is more or less historical from 1962 where there was a full spec with explicit uh implementation details on what on whatever you would want to do so if you would implement it this way like results will always be consistent if you implemented it properly uh then in principle for more specific curve uh bls 12381 you could use external libraries but then in principle what you would

want to do is at least to do a kind of good case testing first so that on inputs which are valid you get the same results and it's very difficult to get different results here uh if you didn't implement it properly like it's very different difficult to get the same results here if you didn't prevent it properly on the same destructors then goes negative result negative inputs but those are also dependent on the binary interface in the integration part which is the third point yeah and then the fourth one will be integration into clients so it's more or less this way uh if i try to answer a question well i mean to

to be frank that i i i am more confident that you are going to be okay with the amount of testing that needs to happen it's the the core the core devs in general when does that point happen so that that's a question for the the client developers what that is and that's just that's just the current open question for me when it comes to berlin in timing and one of the reasons i haven't been as trying to say when there will be a date because i do not have a concept of when that will be for client developers okay for yeah that's it i think we understand the problem uh we'll try to find a solution i don't think that solution will come today so

let's move on to the next one yep thank you hudson uh i think that's you james or was there other there were other eips right for yellow v2 yeah there's other eips the next one was 29.29 and that one was vitalik and martin and there was someone had an update to that i think right now there was a question from alex vlassoff about it uh that i think was addressed in the chat yes it was addressed on a conversation okay all right text wasn't up to date that's it okay um are there updates um on implementations for that is that what

you're wanting to ask james no i wanted to have that that was brought up as an issue so if that was resolved we can move on okay last one i guess being 2315 simple subroutines yes that's one that still has an open question from greg about which version they're going with i believe is that right greg uh you're muted greg if you're talking all right can anyone else answer for that one if greg is unable to use tech right or like comms right now okay i'm back i'll probably right i'm back if i unplug my anyway um there's a question left but we don't

have time to take it up today it can move to the magician's thread but the there's a proposal for preventing um jumping in and out of subroutines and we need to decide whether we want to uh include that part of the proposal and i'm inclined at this point to say yes but there's still one issue i need to understand and probably sorry just one quick question on 2350 and i'm not sure if this has been brought up before has anyone thought about interactions between 2350 and codemoralization you'd have to ask someone who's doing

code mercurialism yes yes that was part of alex's uh accident suggestions was around code mercallization and i believe alexi well that that was looked at by the e21x teams the hope was that it'd actually make it easier but the so the from my memory we had all agreed that we would do the said jump like stopping jump internal jumping features except for greg you were still on the fence about it um yeah it looks like it could break existing code to do more than than we've already tested

um but am i am i remembering that right martin yeah that what that the like adding in the feature to stop the destinations was something everyone wanted but greg was holding back for um more or less yeah well it and then we need like this feasibility study kind of thing where we wanted to check so if this was enabled would it actually break contracts and i dumped out all the contract code and analyzed them and a lot of it was just false positives and there are

a few remaining ones which are basically contracts being used as storage so that you yeah how is it now you call it and then it does yeah you delegate call it and then it copies a chunk of its own code into memory sorry into memory um yeah and kind of dynamically loads pieces of code and those they are there are a couple of them which might be disrupted or not but there was some manual work left and we didn't quite finish the analysis

because the the ball was more or less dropped with you know greg being a bit opposed and no one really pursuing it so then is that something that if it got into yolo v2 the that kind of manual work could be done and finished and evaluated so i think uh i don't know if the implementations of this more advanced 2315 ready sufficiently ready to be merged in the old v2 um there are yeah i mean it's it's a bit more advanced implementation now i understood that what we're running

now is ready to go and yes i think everybody's fine with what we have now we have no no issues with what we have now so then so so so it will take a lot it'll take it's a com it's a kind of a complex change so it'll take more work than it's probably worth for yellow v2 but so even though the previous consensus was everyone uh was but if greg is now agreeing that we should implement that feature then it if it's not for yolo v2 we could still say that that is the new consensus there's there's the original proposal um and then there's a pr to make two

changes one of the changes was easy and has been merged the other change was more difficult to implement might break existing code i found aesthetically displeasing and so it's on the table as to whether to put it in and that that is the one yeah and i i think the the main proponents of the alternate versions are experts aussie and pablo bilika and i don't know if they're on the call and if they're still um yeah pursuing this sort of ax6 on the call

do you have microphone available alex yeah i kind of lost the track in the discussion but if the question is whether i'm still in favor of this restriction then the answer to that is yes um yeah i'm not sure what's there any any other question that was it um and but pablo isn't here i was in favor of that change but uh i think i can't say

much more at this point because i wasn't like really keeping precise track of what's going on in this in this subject for longer so i don't need to update myself with the exact status i think we mostly had issues with feasibility of implementation of the change we proposed and that was kind of resolved but i think there's there's no final stamp on that on that part yeah it was implemented in galitharium another thing is this change adds quite a bit of an overhead to uh jumping and it makes tv more complex and adds some runtime

overhead uh i think it's fine uh based on a few benchmarking i did but i think there's still like quite a lot to implement if we wanted in another mind of visual and open ethereum um whereas the existing one is ready to go okay so that would be a we target for yolo v3 kind of thing and the original version is what will make it into yellow v2 i think that sounds like a better idea yeah okay yeah i just wanted to get uh to come to a decision on whether even if we agreed on it if it should be for the for

scheduling for yellow v2 or yolo v3 and it's if it seems like the the consensus or the agreement is that although the we're leaning towards making the decision yes it shouldn't be done for yolo v2 that sounds right to me cool thank you that's that's all i had hudson okay great we can move on to the next item then unless uh was there yeah that was that you said okay so um we tried a thing where we had a breakout room chat and the discord and we had some calls that were made

i think in the process of doing that there was some confusion about the purpose of both the chat room and the calls because it was kind of talked about differently and a little bit like not as clear as we could have made it so uh pooja since you did a lot of the work around that can you describe and practice how how you think the breakout room uh discord chat and the call went and then we can get other opinions too and then we can better define it right you know after we talk about it a little bit yeah sure so first let me provide the overview of what happened in

past 15 days so there were two meetings concluded in past 15 days since the last all-core dam meeting when we decided to have this channel it was on consecutive monday at 1400 utc the goal was to collect feedback from the clients on proposal and get a consensus to move ahead with the implementation on certain proposals that were discussed in the code meeting itself and then update the client status in the code meeting originally it was planned for having like one eip per breakout meeting but uh the group group thought that it would be good to have discussion on the euro v2 and both the meetings were dedicated

on that so that they can come up with some some conclusion on which eip to be implemented the agenda and the summary is added in the ethereum slash pm github and there was some discussion slash confusion around the meeting channel as hudson mentioned uh well it's something new so a little bit of confusion is understandable it was also discussed in the last meeting uh when we had this breakout meeting uh about the frequency like how and how often we should have it the general uh feeling was like we can have it once a week once a week but for a shorter duration like 30 to 45 minutes only like people can come try to talk about one or two proposals just discuss and go

back to work and this schedule the proposed schedule is not forever but it's on a need basis right now clients are working on yolo v2 so maybe once a week is a good catch up for them as well rather than having it in two weeks and this meeting does not need like 20-25 people like in all coder meetings just six to ten people six clients and then the author of the proposal and people who are implementing and people who have concerns or suggestion are welcome to join but at the same time yeah go ahead sorry i'll just take a couple of more minutes and i'll be refreshed so at the same time i understand these meetings to be productive

uh it's important that we get representation from most of the clients and it is not possible for everyone to keep track of every channel what is going on and when a meeting is planned because we are generally publishing it in the channel when the meeting is planned so i i can add the author slash implementer slash champion or slash people who are uh who are needed for that meeting in the agenda as well as the breakout room channel also i'm also taking care of calendar invite that is going out every week so if people are interested and comfortable sharing the email please email me on discord and i think that this can be a way to bring people together and

uh have them on the same page okay so i was under the impression that these rooms were on an as needed basis which is kind of what you said right right and that these and that not i didn't think that every client needed to attend i thought it was only the people involved in the sub discussions so for instance like any like if there's an eip and there's a few people arguing over the semantics of it then only they need to come to the meeting to discuss their differences because not every client may be invested in that decision right but what happens when we when group is taking a decision on a particular proposal

generally it is better to have every client's representation to get their consensus if they want to get involved or want to implement that proposal or not so i mean like for example i just have shared the link offer the next agenda so it includes three eip uh eip2935 that is save historical block hashes eip2718 type transaction envelope and eip2972 rap legacy transaction so if i mean of course the author are important here people who are implementing these things are important if clients and representation is also there i think the decision making process could be faster what do other people think because

there's kind of a two ways we could go there we could go with people just as needed or uh every as many clients as can attend i would rather it not be al cordev's part two and that and have it be a place to talk to have more specific conversations that not everyone needs to attend and i think it might need to be i think it might be that if someone wants to use it they can use it but maybe like the organizers like me and james and pooja shouldn't be dictating what what gets a breakout room it maybe should be the more the awkward dead

participants so that can make it more so it's as needed unless there's like a really big issue that's not coming out like getting resolved or something what was that micah i think the the one request i would have for these breakouts is that if in all core devs which is where they break out from someone has a strong opinion a negative or pot usually negative about some eip that person shows up to kind of argue it at the breakout if that kind of the whole point of the breakout right so we can take those arguments out of the awkwardness cause our just call them be productive and then we can debate that somewhere else and if only the author shows up to the breakout then we have to wait until next week and we argue back and all hard dips call again

and so it'd be nice if whoever is like the the antagonist for keeping something out or whatever could actually show up to the radio yeah i'm not a fan of that because that means that you just organized another meeting for us so you're just not a fan of breakout rooms in general or the way we've designed them but the point of well for example martin opposes a one of the eips which means that if essentially you just uh assigned mark in one more week one more meeting every time somebody wants to do something because since he's the security beat he's going to be arguing against every single vip from a security perspective yeah i got what you're saying okay we do

want to avoid that so we hmm so we we shouldn't be compulsory trying to get people into the calls i do so i do think that if we have i mean i understand micah that it's important that we get the people to talk about uh uh uh to talk about something on the call and if we don't have the right people then a decision can't be made but we should just accept that if the people aren't there to make a decision then we're not able to make one yeah i think that as long as it's clear up front so we can just not have the call like it kind of sucks to schedule a meeting for an hour and schedule your day and then you show up and then the person who needs to be there to talk to doesn't show up i would rather just not have the call

at all in that case which is which is fine like i'm i'm not saying this is bad just i think that is important to save everybody's time it's clear who's going to be there ahead of time so we know you know hey if martin's the only person that opposes us just this is an example and he's not going to be there then the rest of us shouldn't bother showing up we're all going to agree and waste each other's time got it okay yeah setting expectations and then i also think that it's worth because we have discussions that start kind of going for devs and we could it would be great if the organizers like puja and us would be able to point out okay this is something that's worth a breakout room and then if the participants agree then we we organize and schedule it for

them and we get uh like that because if it's just left to the clients happen i also don't think it's gonna super there's gotta be some kind of scheduling force to make to do it but having a breakout something is taking too long on awkward devs okay we'd have more discussion that needs to happen let's not take 45 minutes on it here let's take that 45 minutes of the and have and make sure we have the right people there to talk about it and then that happens in a breakout session the other suggestion i saw from the breakout room chat was i forgot who who said this i think a few people maybe but having more synchronous communication lines or not more but utilizing the ones we have like ether magicians and really

you know figuring out if people have like basically holding people to discussions there so that we get some kind of consensus around issues that pop up there needs to be a balance between no action and you know between no action at all and forcing people to do something there should be an in between um because otherwise they'll just be ossification as there already is in a lot of ways yeah and the coordinating getting those parties together and talking is good so the one uh one thing that that i find as not like very good about like asynchronous

communication here is that things get delayed for very long time like conversation does happen in the other magician forum and other places we have different channels for that but if there are some proposals that we might want to you know come to a conclusion real quick i think these breakout rooms might help but of course it is completely dependent on what uh everybody here in the group thinks like if they agree if they want to show up they want to continue this i'll be happy to organize it but if it is something uh yeah i mean completely up to that grip like like an example of a good one i don't think we should do it this time but for the subroutines 2315 like a continued discussion on

uh what needs to be done or what is done and have the people that are there show up for it is something that would fit because there is there's still some unknowns and more discussion to have we don't need to have that here and a lot of it can happen in a breakout room and then we can report on the discussion to the all core devs for an official decision oh okay yeah something like that would work i think a good in between is basically the breakout room is open for people to use whenever they want it's not going to be about a specific topic unless unless they say i wanted about the specific topic right now as a temporary topic that we discussed in a core dev meeting and we had like issues on um we should push first for a synchronous communication in the ether

magician's thread and in the all core dev chat and or whatever other means of asynchronous communication you want to use and then if that doesn't work after a single core dev meeting that's when there's going to be suggestions for a breakout room if there needs to be better communication that's quicker and holds people a little more accountable i think that's fair a fair ask to get things moving a little bit it's a trade-off because it is kind of like peter was saying kind of forcing people who might need to be involved in a lot of these decisions into the ring but for important decisions that really aren't solved asynchronously i think i think the breakout rooms are important and the the it shouldn't be the focus

should be on getting consensus not making a decision so having everybody understand and resolve concerns and the decision making can happen on this call so that's why that way we don't have to have all clients on the call okay um so any other comments on this before i kind of say what was just said again as one of the decisions just wanted to have clarity on the call that is getting like like in the last meeting people suggested to have this meeting on monday and uh they wanted to discuss these proposals so is it still valid because this was supposed to be updated based on the all code meeting what is the decision here

um what was the meeting on monday going to be about just a general list of eips or certain ones uh those are for the eips considered for yellow v2 are there any major disagreements in the eips decided for yellow v2 currently besides anything related to testing around bls 12 381 uh there's one two nine three five uh unfortunately in absence of any champion that could not have been discussed in the previous two meetings though it was like in the agenda so people wanted to discuss that to be considered or not to be considerable um interesting okay what do people what do people in the

call think uh just so i'm not talking continuously the mica's points of 29 35 and 27-18 [Music] are stuff to still talk about that we didn't get to today so talking about that on a breakout call would be great since it's already scheduled and people probably already have it in their calendars it might be a good idea to go ahead if anyone can make it something fruitful will come of it and then we can really start the new set of expectations after the monday meeting does that sound good and the role the cat herders can do is figure out who needs to be there and then figure out if they can be yeah sounds good we'll go ahead with that um

next up uh we have account abstraction update uh there's an explainer posted by sam wilson uh and i know i think sam's here today to if you want to quickly go over kind of what the updates are with account abstraction sam uh sure so um vitalik and the rest of the quilt team or and the quilt team rather we've put together an explainer for the eip and the ipa has also been published we're kind of wondering what the next steps are to get it considered for inclusion um but yeah i think we're at a pretty good state now that we want to get some some feedback from people who would use the count of abstraction and people who would be implementing it

and also uh hi and stay here from the quill team as well um so just to very briefly point out we think actually we that the um the important um difference from the erp to previous um proposals on account abstraction is that we um were successful in bringing the consensus changes down to like a very simple minimum so right now in our proposal the consensus changes would only be around a new transaction type and in combination obviously with the type transactions eip um and then a nonce opcode that might even be broken out of the eip it's just returning the crown transaction runs and the pay gas up code that pays for an a transaction and that's literally it and then we

we we have quite a bit of rationale about how we would avoid all the issues that are usually associated with the kind of selection like um basically i think it's sometimes people talk about amplification attacks and all of these things so basically the idea is that mempools have very strict rules and about what kinds of a transactions they accept those are also rather simple but but they are there like just on the memphis level and then the nice thing about that is that you could could start with a very restrictive set initially that only supports limited single user use cases and you'd already get some benefits of a right you have to have native bundling you have other other forms of signatures they could use in all these things but it's only like for single user use cases and then later

on you could just basically um add or like extend these mempool rules without ever like adding any further consensus changes um to to to allow for for these more advanced a users and so i think that that like because of the in the past a had like rather complex consensus implications that people are rather skeptical but with these recent changes and we try to really like bring boil that down to to like a very simple easy easy to read to understand like explainer we think that that that it's really not that that big of a change anymore and we just as some said we just basically at this point would want to hear some feedback on like whether the

core developers think this is something that could potentially move forward to being considered conclusion or if there are any major concerns for us to address okay people will look at that and uh what can get back to you on that what where should they give you feedback is there like a theory magician's thread or something else there is so we initially linked to the old discussion we thought that that wasn't a good idea so now we created a new uh magician's post it's still a pending pr uh to the to to the eip and so you have to be a little bit careful to find the right uh magicians post but it's it's easy to find and also you can find us in the r d discord we have an account obstruction

channel there as well okay thank you we have about three minutes left um and i think the last eip related thing other than the 1559 update if we have time is evm 384 from axic um if you want to go ahead with that just if you can make it pretty short acts like that'd be great three minutes is tough um so this is an update on on the work we have done in the past four weeks and most of the work was actually done by paul and jared from the team um so last time four weeks ago we we had three different versions of the op codes and we had a yule implementation and we had numbers on

haddos compare and we have advanced on on both directions because we um we had a hunch that um the the coding you'll might not be the most optimal one and we thought that half as a language might be better um and we also had some ideas how to improve maybe bottlenecks on the op codes so one bottleneck the major bottleneck we had on the upcodes is a number of stack items each of them required um i shared a document uh which explains four different versions of the opcodes you went through in the past four weeks and the important one is the last one v7 um which has a single stack item

and packs memory offsets into that single stack item um so this might might sound a bit uh weird but this is the uh this is the version which uh has the least amount of changes compared to how the evm operates today [Music] and provides all the speed benefits we have found um and then regarding the the half versus you i don't have the the number handy but i think uh oh actually just as an example the one of the versions um the half version was how much is that yeah the half version was like 40

percent more efficient than the yule version so it was a good indicator that we should focus more on the hot version um and the end result is that basically from what were we where we had four weeks ago with the virgin tree and and duel that was roughly 18 milliseconds compared to that with the half and the v7 option we are at the at 5.5 milliseconds and comparing this 5.5 milliseconds to at least on this single benchmark against the native code um it is 5.5 milliseconds versus 4.3 milliseconds for the native code so i think this gives us a really good

indication that we are on the right track to be really performant and we think that this v7 design is something which is unlikely to change in any major way and probably it is a good time to to encourage people to to maybe write an actual proper pairing operation using these up codes and we also suggest to take a look at the half code we have as an inspiration on how to do it efficiently once we have such a pairing implementation written i think we could make a final decision better you know this is an actual uh you know solution compared to the pre-compile

but the numbers suggest that this is a this is really promising the numbers are really good okay thank you we're about a minute over um where can people go to get the latest on 1559 tim or actually if you want just a minute i think you can do it yeah i think it's probably so i mean to get the latest there's a discord channel we have monthly calls and i post them on twitter um happy to link those wherever people want i i think what would help 1559 now more than just like general updates is getting a feeling for what core developers see as the major risks uh so the last time there was a proper update on the eep was

i don't know call it six months ago um and i believe the major uh the major risk that was highlighted was the fact that the network might just not be able to handle blocks that are uh twice the size of current blocks even if it's for a very short period of time so that's something we're working on on on addressing right now and and you know building small test nets to test and gradually growing them um but i think what would be most valuable for for the people working on 1559 is knowing are there any other kind of major objections or major uh issues that people see with the proposal um and and what's kind of the next best time to bring it back to awkwardev you know is it once we have data that says

um you know like here's an intuition that proves that like we could handle these blogs for a while um is there something else people would want uh would want to see um yeah i think that'd be the most useful thing i don't know if we have time to do that now if we want to put it maybe as the first thing on the next call i'd say first thing on the next call and do some asynchronous digging until then within text like text form like in the core dev chat and stuff just asking straight up so we have some a little bit of answers before then yeah we did that two weeks ago and there wasn't really any answers so that's yeah okay okay um yeah let's have it be the first item next time and if people uh can get a chance to respond to tim

that'd be really helpful okay the next meeting is going to be october 2nd 2020. that's in two weeks uh thanks everyone for coming and have a good weekend thanks edson thank you [Music] [Music]

[Music] [Music] [Music] [Music] [Applause]

[Music] [Music]

[Music] so [Music] you