All Core Devs - Execution #88

Transcript

[Music] [Music] [Music]

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

[Music] [Music]

[Music] [Music] hello everyone and welcome to the etherium core developer meeting number 88

there's seeing the audio yep audios working let's get started on the agenda the first one the integration updates for the berlin a ip's james do you want to take this one yep so i made a proposal way of tracking the e IPS that are giving integration testing as a way of getting the clients to all communicate and have that be a way of testing all the multi clients let me find that the IP and I can just show you I can just show people it's in my github and while you're looking for that

if anyone is on the agenda and wants to click agenda item one Berlin a ip's link it pops up a Google sheets like page that has some of the status updates for the EIP s almost there no worries it has an it hasn't been merged so it makes it harder to find sometimes [Music] to the be ours here we go

okay how did you post it I didn't - seven there we go this is one that will make sense to look at and then hopefully we'll get it merged okay soon and I can just share my screen too and I'm gonna put this on the messenger and zoom and it's also in the getter channel thank

you so we've had the eligible for conclusion has been the step I think it just kind of gives people some context so we're looking at separating the EIP standardization process and the network upgrade process and we already have this natural step which is efi as part of the first part of the network upgrade process and this we buy my strategy has been to capture the emerging things that happen so rather than like layout something in advance that may or may not be what we actually need so i can a

chiral step that we've it seems like we've arrived at is as part of integration testing rolling out ephemeral test nets that have some version of an EIP that then clients the different clients can choose to take part of and then can sync and then you are able to test client features as well like a fuzz testing clients and stuff like that is a lot easier when all of the clients have toggleable versions of the IPS so none of these a IPS are in a state that is saying it will go into maenette it's in a state that their clients wanted that the the core devs want to test more and

then it can go back to efi or it can move forward depending on what is learned there it's really important the community realizes that these are meant for integration testing between clients not for deploying your dev code or testing your things on production there are other test nets that are that can be used for that like this will it will be nuked is the disclaimer I put a very large one up there and so the current specification for that is EIP to 537 which is the BLS curve BLS pre-compile and i marked that that is in a that EIP is in the state that the

clients need to get to that point yeah IP 2 3 1 5 is the subroutine z IP and it's still working on being specified and then option 1 of a IP to 5 6 5 we have decided not to include it based on some feedback from the open aetherium team at least not and when I say not include I mean not have it be part of this specification as soon as there are as a version of it that makes sense it can the ephemeral testing can be dip can be redeployed and it isn't saying anything about whether it will anything about maintenance to be Tripoli clear and then this is a way I've been

tracking getting ready for it and this is kind of a subversion of the like the proverbial in the IP that the birth of the spreadsheet that puja put together so clients signalling their intention then they agree on the specification which that hasn't happened yet because we're still looking to finalize it's 2 3 1 5 and then after they're merged and clients have merged those changes then we can roll out the testament that syncs all of them and that's a good update if anyone has questions or clarifications or thoughts yeah it's a fication

so I think this is a really good approach and I just wanted to make it clear about this Yolo be one name in my opinion should also be the name produce state tests and any client that can run state tests should accept Yolo b1 as a name of a fork on that state test yeah that's bigger I think the first case is that I've been recently our named Berlin and I mean they they can be

regenerated but pleased and I think we should regenerate them to Yolo b1 but yeah I just wanted to say preemptively that trying should not merge activate all these things under the name Berlin in my opinion but under Joel obi-wan does anyone have thoughts rumors on that I'm happy to add that to the specification of this do they eventually get taken out and only Berlin remains yes so what I can see as a problem if if we start putting out things which says they are Berlin and our Berlin

activatable and someone updates to that client today and doesn't do anything for another six months and then we roll up the real Berlin and he sits with an old client that hey it has pretty and already way I don't have to do anything then we might buy meat the problem okay that makes sense yeah anyone have what's the word strong feelings either way about about this or would would oppose having that be part of the standard for this kind of Testament I think that sounds good thanks for

doing this James it looks really good and then from there do we want to continue going through the updates from the teams for eg IP yes really um yeah let me grab that the spreadsheet that you have I can just show that one and I'll share my screen again so we can go through four to three one five has

there been well let's yeah two three one five have we finished the specification and enough to actually address whether or not we've implemented them so let's call it the original 2015 has been changed regarding the gas cost and I have a currently open PR to change the gas costs a bit and I think everyone I think it's been given a general thumbs up I haven't really heard from open ethereum on this recent change but now

that B sue at least has approved it and updated the tests accordingly but if I can just get a thump up I would merge that and on the other so the other part of the subroutine is whether or not to apply the restrictions proposed oxic and right a snare and people that discussion is told it's the longer but for the test net I think we agreed to use the non-restricted subroutine proposal from Greg right yeah yeah but if if just if we just if I'm just gonna

go ahead like I will take the merge button on this and I think we're finalized open etherion yeah that's mmm let discuss this after the call I'll take take a look at it just didn't have the chance and as for us so we have a poor requests to address the recent changes in the specification so it's probably it's merged and then there's still another PR for this this when you say recent specification are you talking about Alex's maxixe

restricted updates or the original one ice I assume that it has been changed but like I said I haven't really taken a look at how it changed after the call so so yeah so the most recent change has been just a bump the gas costs for the three up codes right but the consensus has been not not to restrict the subroutines right I would say that discussion is still ongoing

yeah the consensus is to implement a version that is not restricted on to yellow version one and then use that as a way to move forward discussions after that as to what to extract what to restrict and how much to restrict so this is a good example of one that it would likely not go to maintenance in its current state but it is being used as a as part of integration testing better better understand what state it should go into if it does it all they for so I'll follow up on merging that

and then on clients says for that after this call for e IP to 5:37 let's just go down through the clients okay change proposal to to the subroutines different up codes from the ones currently in the IP it is being discussed from like a month ago but nothing really happened I wonder if that would be something were to be included a in Yolo or it's fine to have it for there for later on I this

was this is part of the call that we had is this part of the call that we had on T three one five no we didn't had a chance to discuss it but it's been posted on on the magician's for quite awhile ago well I've had it sounded like it was it was going to be the closer to the one with gray Greg's changes with a few updates from Martin as the specification and we were just going to go with that now so what I mean is currently the three up codes have the three instructions have enough code like B to b5 b7 or something like that and there's a suggestion to get user linor

opcode space somewhere else so the opcode here means textual and byte which is on the bite the instruction is steep what at bite is doing I think that it totally makes sense but I don't think we need to change it for Joe Lobo what were you gonna say Peter now I was just asking whether it does it really matter where the bytecode is I mean what the number is it does today extend that so far we every single opcode we have is leaner we

don't have like gaps random gaps mostly but this this would open just like a new page in the in the opcode table with the gaps in between the only only real effect I can see is it goes back to what is the goal of the test it is the goal of this test net for only for clients to to interact with each other and I've like a place where people can try to break it or is this also a test network the users can try out the new functionality I mean nobody stops users from trying it out but yeah but alex has a pointer that if someone makes an

experimental compiler which is a subroutine and then we swap out the old code is this like presupposing and it would go into main it well I mean it's I would have also had problems with deep things being out of order if we somehow reserve this opcode but then didn't make sense to figure on or something okay but I don't think that the whole whole issue here so if the original issue is that we don't want to leave a gap and just change this back so that there's no gap

and done I mean I don't think anybody cares about the OP code so if there's even a slight reason why you would want to change it just change it and that change can be integrated at the same time that the changes for the Martinus talking about post call can be merged right yeah well I would have to regenerate the stuff but yeah this actually makes it PR now we can merge it and I can test cases it can be done pretty soon trivial changes I guess something you could do x''k yeah yeah

cool anything else on the two three one five before you move on for AIP to five three seven the BLS pre-compile let's just start at the I forgot what we call it but the readiness in the implementation implementation status for death I remember there was eight an open PR with the pre compile code in it yeah so forget that PR is a bit hanging in the air so about two weeks ago we we started

just really heavily testing it we doing it Martin and Mary started passing it and well the bomber side of it is that I personally found at least three concerns issues on the crusher Martin and Marcus found some Crashers they also found a consensus issue in the assembly code where they just essentially the PR ships ago implementation and two variations of assembly implementations and the assembly codes did not match I mean there were some carry issues or for certain inputs they just produce different outputs and we're talking

about 14th lines of assembly code and while the author of the PR iterated a bit but essentially what you guys need to know is that so Martin and Maurice found an issue in assembly code the response was that here I let's just add these ten lines of assembly code because whoops we forgot about a carry then later Maurice was asking why is this algorithm so complicated the response was yeah well maybe we can just cut this algorithm out and that we can get rid of four-fifths of the assembly code and then on top of all of this on Monday the PR was updated and old

existing assembly code was deleted and we just got fourteen thousand lines of brand-new assembly code so at this point I honestly cannot imagine how anyone would expect us to actually merge this and fork this into a life that's not one essentially denied we almost got it and replaced four days ago I think two weeks ago I made amends on get your chat sets if you have any doubts about assembly code itself and you don't want to check it then just there is a pure go

implementation you can ask you just use this one and always decorated its feed center the window or gas prices which were proposed in SAP recompile and I think no one ever thought about it and try to make this decision and this decision should be made by gas containers not by me or an original author CPR like if you don't want to have assembly just said and almost like it will just delete it altogether the problem is not with the assembly the problem is that the problem is that we found issues in the assembly so the problem is that the PR wasn't fast

against it own itself so the our mania problems is that we're rushing into it's fine to have assembly but it is not really fine to rush into a fork when when the implementation itself wasn't properly vetted so that's that's mostly my concern but maybe market you had some other thoughts because they were the one that we buzzing there's something I think you know it's just to reduce exposure like any potential attacks or or like consensus problem surface and if

it's a final calls and in just to eat also simply at least for now and then spent time on just buy me more CPU cycles on just a single implementation without assembly or any as a form of branching yeah also one of the problems is that the good thing about having some diversions and go versions was that we were able to do differential pausing because actually finding crashes is very rare and we probably I mean like there's probably no Crashers in the implementation of what I fear is that

there are differences between the this the goaling implementation and from other implementation roster see which causes consensus issues and we are not we're not being able to do differential processing against the roster see implementations because it's a pain in the ass to do basically and since they have not been merged into the other clients we cannot even do slow fast testing using the actual binaries and evoking them ideally we would have just integrated the libraries

on on some so fossa which called the libraries and directly but that's yeah we haven't been able to do that properly so I would estimate that Foster Singh the clients against each other in a differential mode that's a couple of weeks work we will also need to replicate the benchmarking and make sure that the goaline the gas implementation pure goal and based on the gas schedules I mean it theoretically doesn't stop us from merging something for the test that

but I think we're kind of skeptical of going live with anything this one highlight that going live with anything on a near-term future oh well first of all as far as I know Maurice has eaten has kind of fix the problem was linking out the go rapper for Rast library which actually could allow to differentially tests library against library without client integration of course if we assume that openness here iam would include my PR in terms of integration when I was doing quasi testing myself

well I did it against the assembly which is like which didn't have problems and crashes and they don't have any divergences with rust implementation I think this assembly back-end was called EDC or some so I exist but I don't expect that I would find anything in in pure go implementation for reasons that says implementation is based on other work we shall battle tested against start perverse - if we just agrees it well I just got out the assembly performance wouldn't be

an issue and then we can just spend more time on pausing just strictly against kind of final piece of code without any additional branching inside based on the implementation right has to be several weeks the word yeah I separate some weeks of work for cut assembly or just to say that it's the number of cycles spent advising is kind of acceptable yeah the letter well this is just a matter of number of course in a machine

no it's not just a matter of number of course it's also about actually building the passing framework and making sure that the the input generation is good and yeah it's it's actual coding hours it's not just CPU hours I actually don't know what's your strategy on building is a father so far my observations were that if initial corpus is kind of seeded with test vectors from kind of consider related tests from my repository then more or less I didn't see that father

has ever found new branches it's more or less means that cannot test any further for for kind of plain errors and crashes in other branches of code and actually making the inputs or which I up really well it it's not that hard and I think I have it written already turn even while it's not an easy work it's it's a matter of how you would want to do the causing I actually don't know what's with your

fighting straight at your eyes a black box or a white box well we're there's a bit of a detour but we use the go first so we have made the coverage guidance and improve the corpus that way if we compile with other known go native things then we run into different problems that need to solve the Quraish instrumentation in other ways no I just means that you can immediately get the coverage almost up to the limit which you will not ever exceed by seeding the corpus was tests at least it's what is at least this is

the behavior of the rest implementation and various fasteners for it the so understanding that this is the hesitation around maintenance far as getting this merged to be part of Yolo is there like a path for that or kind of time for that or amount of work for that that you see Martin I guess you'll know he's kind of easy because we can always

racket so I mean nobody cares if the viola dies yeah so then so then just merging for that wouldn't be it wouldn't be an issue and as they're still outstanding safety concerns that I think the Geth team is trying to convey but that is something that I think we can work on between the Geth team I sorry I'm not familiar with who was the one who was pushing the PRS that Marius was merging was that from Alex's team I'm not I mean what do you mean for peers which Myra suppose merging oh the

Assembly March oh okay well the author of the PR gasps yes owner who is never on this call but more or less I can talk to him directly telegram we actually had this discussion that it is actually may be wiser to remove the assembly at least one of the engines which was last tested by him actually it's also possible from all other perspective to remove the assembly all together it wouldn't be a problem for Matt's wife okay just guess do you have final thoughts I wanted to timebox this for the rest of

the updates it's a good time to Reno to that Yolo that this was something that would be resolved before going into Robson or something that we care about breaking so just to get some context as to things to be as like concerns versus when they need to be resolved by what what they're being resolved for yeah and like traditionally within you know the court have security and making sure that the network has stable has been paramount so we're all keep that in mind as we go forward we trying to work

together on this stuff so yeah James if you want to continue mmm open aetherium for which Ford to 5:37 just updates on the implementation so we're currently focusing on the pull request by Alex it's under review and I expect it to be merged soon if no sudden problems arise great Basu merged ok hon someone will update that one I can touch this no I can't also do that here nevermind I believe he's not here at the

moment yeah they're gonna be coming in late what job is this here I see Thomas got here oh great yeah yeah I'm gonna call that's for the BLS will be probably working on me this weekend so I'm thinking of two things first of all I'll check if it's possible to just do it with the harami codes that we have now or is it actually introducing some additional operations that are only possible with the with the PRS from all X and then we'll just write the wrapper for C sharp and and I'll try to provide it to the get in to do some fuzzing together but I can do any promises for this weekend but that's does about that this we can all be tested and merged ok

band aetherium J s or Trini I don't think I see anyone from Jay s we can move on then from from that Hudson ok perfect next up we have EFI review for the EIP 2046 in the IP 2565 I copy pasted these from the last agenda but I think you addressed earlier James that at least

for 2565 that's something where it wasn't because of an something with open aetherium we're not going to go forward with that on this Fork is that is that what you mentioned or as party going in Yolo one about that and that isn't about Berlin and there still needs to be discussion about the gas costs and things around that and there's ongoing it's so be good to have a conversation about it okay and Kelly can give an update on that in a second I bet because I think that's the that is the EIP that Kelly's involved in right yes okay first though 2046 the reduce gas cost for statics calls may Dupree compiles I think this has to do with 22 666 the one item number three can someone update on

that EIP and any thoughts around it I can update on to 666 perfect or well more or less initial I else kind of included the proposal of 2046 into the to 666 and with my kind of more radical approach which Martin was mentioned once that you can just make pre-compile call like pure cold costs equal to zero and absorb this additional overhead into the pricing was a pre-compiled itself so this was actually a result which I kind

of okay this this approach was included in his results which he also published for repricing of specific free compiles and else's a chat function in EVM itself more or less work justly presents what is a first of all what is the performance right now in at the current state of clients of go of gas and openness you and second the pricing formulas are more complicated in a sense that they no longer always operate on sums like price per hashing of 32 bytes of the input now pricing depends on internal structure for example the hash

functions which accept input by blocks which are not always equal to certain two bytes so kind of different ranges of input lengths will result into the same price for kind of actual computation spent on evaluating their hash function like for example 4kj function the in boot lengths must be chunked into 136 bytes and like no so we're caching like zero and the country bytes that we've seen from purpose of actual time spent on

computation all this is reflected in formulas LC because the call cost was reduced to zero it also would require to increase the price of PM add and multiply every compiles being multiplied is kind of negligible change and be and ads should be pumped like I think twice and something but it still would result in the net costs which much smaller which are smaller for end-users Mullis this is just a proposal to get the pricing interline with actual

performance and efficiency quick question before I open it up to everyone else would you say that two six six six supersedes 2046 or as a complimentary oxy kind of asked to removes the direct proposal to reduce precompile call cost to zero from to 666 that's why I at least 2046 mod X and another one we should remember by number which assigns first I think thousand and twenty for the numbers of address fest and space to bring compiles but more or less though

so logically kind of come all together if we if one reduces a call to break compile to zero or maybe not some nonzero number then it's necessary to check that all pricing is not affected by this and there are no internal compensation in pricing or is this fact that's why mod X pre pricing is also tend to freak fired and for all other pre compiles I just did some urgent measurements to I said do some adjustments or just change the pricing formula but just to preserve the fact that there is no kind of attack that cost of execution was kind of high

but the cost of like the north nominal price of the recompile call was low because it's internally taking into account so seven hundred guests which are paid right now okay do does anyone have comments questions okay thanks for the update on to 666 2046 you said was Alex's right or act six yeah okay execute have any update on that it looked like there was a comment in to 666 about having some like offhand

discussions about stuff with 2046 yeah it was so I don't don't remember now but it's it's in the discussion the link to the the previous or could have call probably a month or two ago when we discussed this last and I think during that call so this is what I commented on to 666 and during that call we agreed that the the actual number proposed in 24:46 is not the final number it was to be determined through I guess benchmarking and in that awkward call if

I felt if we were on the opinion that it would make sense to extend 2046 but like the final proposed number and introduced the restrictions for the BN precompile and we also suggested to you to maybe do the other repricing set Radley and I think it would be better just to have like a more focused call regarding this and not all cadets just to you know finalize these details and because justice all could've Cole doesn't seem to be the best venue to to discuss imbibe repricing topic agreed in that case would you want to take lead on

making that call and just sending out like a like message in the core dev getter that just says whoever wants to join a call can you know talk at this time or something or James just do you want to handle that I can do that okay there's people who are interested and messaged me and I can I have made a theory MPM calendar so this would be something I would add to it and I can add whoever would like to be invited to the call to beyond the list before that and then I X Eclipse figure out when would be a good time after this call sounds good

okay thanks everyone now on to 2565 repricing the EIP one day 198 mod exp precompiled that d kelly yeah so just a quick update two weeks ago when we came in we had to pass forward for the repricing one was simple parameter change and updating the open aetherium library and the other one was a slightly more complicated pricing formula and not changing the open aetherium library what we've decided to go with is the the pricing formula change so we did work with artem on the open aetherium team to see if we could put in a different library unfortunately

there was some compilation problems on windows with that library so we won't be going that route so at this point in artem has has implemented a draft PR for the pricing formula change i am in the of revising the EIP to reflect what you know the specifics of exactly what the new pricing formula change should be and then the next step once that's done I can share that with the the guest team and hopefully we can get a draft PR there so I think we've got the path forward that will work for both open aetherium and death and we have a PR for open aetherium and we will shortly have an updated e IP and hopefully a PR for

forget okay thank you does anyone have any other comments on any of the efis we've talked about or e IP to 666 so this can be the stat reduced gas cost for static calls the mod exp pre-compile or the EIP to 666 any comments or questions okay next up we have a IP 1559 update I know there was a recent call on that that apparently a lot was discussed and maybe got done I don't have all the details but I think was gonna talk about that Oh wonderful go ahead yeah a couple of

deaths from the increment of course it was yesterday so first is about the PR about removing the block size and transaction size writers from this it so the plan was to create a separate IP for the writers and then we would have to decide if we want to make that dependency for the 1559 or not so this is the first update so I don't know if we can merge the PR about removing the writers or not basically I don't know if you want to start testing it with our result the writers so this is something we have to decide second

update yeah we talked about non proof of orc networks and we were wondering if if 1559 is valuable in those context and if yes what we'll be the impact on the implementation because CCIP is designed with the transition phase in it so what if we if you want to start directly with with it 1559 rules on the consortium network for example or so yeah we discussed about simulation versus test net so we have some discussion with a

yin yang from recognized and barnaby about simulation so what would be the best path to test the CIP do we want to deploy some test net and and play with real users or do we want to implement some agent simulators and last about stages about the escalator chip approach which is a narrative of the zip or also we we talk about the possibility of combining them so yeah this is also topic we we have to discuss yeah that's

it thanks for the update anyone have any comments and that implementers call was uploaded the other day to the etherium Foundation YouTube channel so the same channel that's hosting this video the implementers call number two is on there for IP 1559 the next item is if everyone can rush there oh go ahead there I wanted to say there's really good mock-ups and things that were done by Dan so people who areas should should go and check out that video to be able to see that part and give feedback awesome yeah Dan Finley from meta mask right yes awesome okay next up if you refresh the

agenda I put this one in kind of late but it's an EIP to limit the size of a net code I believe that's Martin if he could go ahead yes leave it aside so yeah last one is pretty trivial suggestion from me and actually can Powell and I think a couple of people have been touched touching the same idea we should place then limit on the size of any code we chose not limit to be twice the size will be the variable code size and a reasoning being twofold one that init code can be used

to attack jump test analysis and it passed thing down historically in 2017 and even if yeah so there's also one more possible future motivation for this if we implement subroutines which are restricted because if we do so than the jump test analysis become a bit more complicated and thus it becomes even trickier for clients to do to protect themselves against attacks of this kind

so regardless if we go that route or not this would be a good thing to have it's my take on okay great anybody have comments this is the thing that came up on the subroutine call right Martin yes so discussions about subroutine kind of reminded me of this whole thing I've had it lying around for a couple of years

actually and just never submitted it before we go but I think it's relevant regardless if we regardless of whether we what kind of sub routine maintenance this makes clients less easily attackable okay thanks Martin anybody else okay the next item is Berlin timing I don't know if there's an update on this or not James now we're focusing on the on Yolo and getting BLS implementations into a state that makes

it comfortable for us to decide that okay item number seven is the e IP IP working group / IP IP Survey edson if you want to give an update on that yeah so medicine from the theorem counters the IP IP group as working on a on a survey getting stakeholder feedback just a reason on why how so the IP IP group is for the EAP improvement process improvement hum implies change changed another posit the way this can

be done through their moving towards something or moving away from something so moving towards a goal setting moving away is problem-solving so a way to do this is we decided to go with problem-solving way to start solving problems is to first identify them and to get that from a community is can be done through a survey so we asked mostly emotional questions what's your biggest frustration and what should be its fear with current EAP process frustrations are a good signal to see current problems and fears are good signal to see problems that people first

see so the results of that survey we always has a few other questions such as what do you currently like about the EAP process that would represent things that we shouldn't change it also was a good indicator for Curtin values the community had over the P positive in theory my general findings from that are that people who liked that the process is structured has legitimacy and focuses on the technical aspects that the barrier of entry is low and then the bar for approval is pretty high and that

it's transparent and allows some fair and thorough review as far as the results found for the fears and frustrations they fit in three categories which we can make into a roadmap for the next few steps those categories are formalizing decision making increasing clarity in the process and within the specifications and increasing the capacity to push a ipsec completion so will most likely automatically be in that order decision-making clarity and then increasing capacity so currently our

career discussions I've been around decision making namely how can we separate the EAP process in the Hartford quinary coordination process to make both those processes more clear also how can we make decision-making more independent why of course so how can we make this is making asynchronous from the live calls that we have every two weeks that's currently Hudson do you have anything else to add no that was a great overview thanks for stepping up on that survey in the overview Edson anybody have anything to add comments or anything I just it's

been really good to be able to reference that one when we when we've been thinking about things in the EIP call so thank you for taking initiative fund making that happen okay if there's nothing else on that we have testing updates as the next item anybody have testing updates that are worth mentioning okay the last item review previous decisions made and any action items taken so we have the notes here thanks to Brent and Jim for doing the

notes decisions made eighty-seven point one from last time is that both AIP 23 15 and 25 37 so subroutines and the BLS curve have been accepted into Berlin the ephemeral Berlin test net named Yolo to test these Berlin di peas is going to be created eighty-seven two point one twenty three fifteen twenty five thirty seven and 2565 might be included in Yolo I think is what the note is describing they're looking at it a little bit closer I don't know if 2565 is gonna be going in necessarily anymore that's still pending some stuff so that

decision item needs to be clarified a bit further that's eighty seven point two point one so 87.3 2046 is pending results from an open aetherium benchmark that's been somewhat updated today I'd say that I'd say that's a result that's resolved okay eighty-seven point for simple subroutines from the EVM for the EVM twenty fifteen has some outstanding specification issues get resolved by Tuesday with a call that also got resolved and there's next steps on that 87.5 the last decision made from the last notes the BLS curve operations EIP 25:37 is going to have a pre compile listed by

Alex blasts off by early next week to make it final Alex did you include the pre compiled list into the BLS curve operation EIP sorry I didn't understand the question actually no problem he did means the numbers yeah yeah yeah okay yeah I mean it was included last call almost the same day or Monday yep okay cool actions required there's seven of these eighty-seven point one a decision required on looking at the smart contract code for simple subroutines

that was addressed by the meeting a six point two that's from two meetings ago completed last week James to reach out to Alexi for Merkel ization and simple subroutines eighty six point three ongoing Prague how compromise proposal to be decided on test net than pocket is what the compromise proposal is referring to eighty seven point four update AIP bought with withdrawn that is still ongoing for my understanding I don't think there's movement on that but on the bad people that it that is changed more into working on the EIP standardisation process which I could actually talk about a little bit maybe

after this okay after you finish this list sure 87.5 movie IP 2583 - withdrawn that's that been merged James that can't be until til DeWitt until the statuses are were resolved oh that's right two more left 87.6 james hancock to review efi e IP and accept an existing pull request that happen 87.7 a SiC to review Berlin EIP and accept existing poll requests accent have you looked at the Berlin EIP in a bit okay great then that's resolved okay so

that's all the decisions from last time I'm gonna go over the decisions to be referenced on the notes this time we're not decisions but I guess action items and I'll mention if it's a decision as well so continuing to update the ephemeral test net yellow meta hypee and Berlin EIP is a continuing action item that James is going to handle James Hancock will follow up with open etherium acts ik and Martin to discuss AIP 2315 simple subroutines after this call to merge changes boom I don't know if I don't think that's the one that requires a call that's the other that's the next thing I'm talking gonna talk about and then James to coordinate with

axe ik and interested parties on a precompiled gas cost changes call sometime in the near future and then finally the last item Kelly to continue working with open aetherium team for the EIP 2565 repricing of mod exp pre-compile is there anything that sounded off to anybody or any decisions or action items that I'm missing from this call and if we should add we should add merging the ephemeral VIP ah right so merging the ephemeral he IP into the IP is repository that's yeah yeah good one the test net specification okay and and so just to be clear so 22 315 has

the changes and gas cost has been merged into the spec by right like five minutes ago and this is the spec that will go will be live on the yellow test net I think it's still waiting for the accident yep I read it yeah except just needs to do one more PR and then that's the one that's gonna go in Artem well now X needs to do one pure gonna need to regenerate the examples in the bugs Oh yap yap you're right sorry I missed that part and Kareem will need to regenerate the but I if you want to make changes no

planetarium and I guess you can just take the opcodes I think already posted somewhere I don't recall exactly where they were posted x''k do you know where those were post was that in a theory of magicians thread the changes yes yeah it wasn't the the main the discussion URL of the IP it's it's within the bottom ten comments okay and a to do is also that you're going to do an PR to change that within the EIP itself so we can finally

that we can say that that's going into yellow after test2 regenerated and a few other steps occur and I can reach out to all the clients when that when that stit the specification step is it's fully ready great Artem does that clear everything up kind of I mean still like see at least some PR to the EIP that would declare that after that PR the EIP would be final or rather not final but the would be the version that will be deployed on the yellow Testament but yeah that's I'll take a look at the the proposed changes remaining yeah I don't

know if there's like a status indicator within the EIP that anyone's ever used to indicate it's going into an ephemeral test net because we've never done an ephemeral test net but what we'll do with that as James will organize outside of the IP when that's done and let everybody know yeah I mean I guess what you could do is on Merl test net specification you could put on implement 2015 at commit hash bla that's a good idea we have another thing so part of the EIP IP meetings that we've been talking about is let me just

share my screen again so this is a little bit easier to see so part of going into I didn't actually hit the share button part of going and allowing more asynchronous things to happen like this is a beginning of that because we can have clients signal and then this be updated that specification and stuff is accepted so we we've been talking about updating statuses for the IP sanitization process and having final being I get that a specification is in the final state and that that and then having that be separate as to if that is to be included or not so this might

actually be a good test case for that where we could make the EIP this version of it final just so it can then people can know what needs to be implemented for Yolo and then additional changes after that could be made but it would be - an updated e IP that updates this one that makes sense just to clarify final wouldn't mean that the spec is frozen yes I think for this particularly IP example I don't know if we want to freeze the spec if we know we're gonna change it so soon after potentially because then we'd be finalizing things all the time if it's

yeah but we can discuss that on the next d IPP meeting yeah I was gonna say that is the longer discussion we should have elsewhere yeah no problem okay and thanks for that update yeah these these charts are nice we had really good conversations about them last the IP IP meeting and have some notes for the video for those interested who want to go to the etherium cat herders github to the e IP IP repo we have and also on our youtube channel we have the video yeah and I can add that I can add the hash let's add that to the two dues for yours so that people are all just all the clients are clear what version is being implemented so for action items continuing updating the ephemeral test

net yellow meta a IP with including PR hashes or I guess commit hashes yeah you have enough tabs open oh this is only one of three windows alright is there anyone else who has any other things before we go we can cut this early going once going twice alright the next meeting is going to be June 12th at 1400 UTC thanks everyone for coming and thanks to the note takers and everyone else who participated bye okay Cheers thank you thank you

[Music] [Music] [Music]

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

[Music]