All Core Devs - Execution #62

Transcript

[Music] [Music] [Music]

[Music] [Music] [Music] hello and welcome to Theorem quartet

meeting 62 let's jump right into it we're gonna go to the summary if you click on action item 1 and we're gonna review the actions required and decisions made and suggestions all right so we got action 61 point 1 is the ganache slash spec compliance issue it go aetherium that issue we're gonna come to the back to that in a couple of meetings I don't do we have anything updated on that or but we each should we come to that in the next meeting David not sure probably in the next okay no problem review time frame for hard forks in June

to refresh memories yeah we'll do that in the next item when I pull up the link for the time frames for June Diana's gonna add 9 month out hard for kickoff time frames that one I'm looking here I think that's done Danno didn't do that one get done yeah I also propose for the next batch to add another checkpoint which comes two months after the kickoff VIP proposals what we do which is kind of what we're doing what we did that last week in this week and replacing what the checkpoint fees do a IP is ready to give us more time to review and

work through the e IPS before we hand it off to client development so that's something I'm proposing for the next but we'll see how this goes if we need it okay sounds good the next item is a IP 615 decision discussion at meeting status as a PR will be made EAP 615 is the e IP for subroutines and static jumps for the EVM and I guess that would be Brook or Christian or Powell and it looks like that was done but I'm not positive is anyone here who can speak to

that okay next we have Martin and Alex to confirm whether a IP 689 needs to be implemented it's a work in progress and that that was the status last time this is the address collision of contract address causes exceptional halt that yuuichi originally drafted Martin or Alex is that have any update okay so we can erase that action item for sure I

have an update on that from the testing side that it still needs to be written in tests and it's perhaps that the the intention of the EIP was for it to be updated in the yellow paper which that hasn't happened so like implicitly it exists in the clients because it's already been accepted but explicitly it isn't in the yellow paper or in the test yet okay and that could happen after its explosive after it is accepted require because I think there are collisions in the tests for create - it's not in the yellow paper and I think that's because basically UHE was the yellow paper guy and I don't think anyone picked up that

yeah I don't think we have any yellow paper person right now all right another one is parity to comment on libraries for pre compiles yeah the issue was raised it's an objection to using like shared libraries for the pre compiles and discuss that with the team and know you have no objection to that but one comment might be is that yeah using shared libraries kind of reduces the the benefits of having multiple implementations but we'll just leave it at that but yeah we can go

forward with this and use the shared library there okay action 58 point one was the cat herders looking at a IP one do the cat herders have any updates on that so this the PR has been approved I think two or three IP reviewers but hasn't been merged so I don't know but if it gets merged okay sounds good and that that means that you made changes to e IP one or fixes and you're waiting for those to be merged but it's already been approved after a last call period or after some kind of discussion on there

[Music] okay and what we might want to do is make that a little bit more widespread using reddit or Twitter or other means to make sure that people get their comments and so it doesn't just stay under the radar and then people find out later what happened okay that sounds good so that's all the action is required the decisions made is that there's value in hard fork deadlines

that's sixty one point one sixty one point two is that the first deadline should serve as an upper bound for the maximum number of changes that might go in and subsequent hard fork and do a subsequent hard fork into Istanbul but of course not everything that is proposed by the deadline will necessarily make it into the hard fork sixty one point three is furthermore that as to this particular deadline seven days from today the CIPS today may still be in draft form they're not expected to necessarily be thorough or complete nor an accepted State and of course not expected to have implementations already okay so I actually wasn't here last week can anyone elaborate on exactly what the

summary of that decision was it kind of makes sense but in my opinion that makes it a little bit unclear if if it's in draft form whether or not that's actually something that we can that needs to be AB everything complete before it's an accepted state Hudson my understanding was it it doesn't need to be an accepted state by the deadline just that there has to be a draft but if anyone disagrees speak up agree yeah that's kind of what I read that as to I was just making sure I read it right the IP 615 PR will be made for this that's

decision 61 point 4 that's C I'm gonna open that one subroutines instead oh that's already been addressed so we don't have anyone to speak for that one so we'll skip it suggestions 61 point one more than one EIP document are needed to address three things a quality specification a high-level proposal and an intention to get your change into the next hard Fork today we're kind of focusing on which hard which a IPS are going into Istanbul so we probably won't act on that suggestion today in my opinion unless someone feels strongly that we should and then ganache spec compliance issue it go aetherium it would be helpful to

spin it out into separate repos a suggestion 61 point to disk an Oscar go aetherium have any comments on that nothing from okay um let's see what is the next item okay so part of the actions were to review the timeline for hard Forks to refresh our memories I think that happened last week if the notes are correct but let's go ahead and just go to the roadmap and item two and see what that says so june 19th was the soft deadline for mayor wait sorry May 17th was the hard

deadline to accept proposals for Istanbul that was on an off week so we're gonna do that today and then Friday on the 19th of August is the soft deadline for a major client if lament wait not August July is the soft deadline for major client implementations and yeah we'll go from there after that okay let me see here oh we have the hard fork happening after DEFCON okay well this will be it this will be a trick because we've never done

that before we usually try to have it before DEFCON that'll be interesting okay so no three is the really opposed watch this is a freeze list for the proposed work date when I did the windows we didn't know what Def Con was going to be yeah we expected it to be in November at the time I'm sure hmm maybe we should change it to make sure it's not during Def Con but then that would kind of wreck the rest of the timelines and stuff does anyone feel uncomfortable with having it so close to DEFCON where people usually have stuff going on right afterwards or right before

I would be comfortable making it any earlier you said he wouldn't are you would I would I would not think making it earlier would be a good idea okay sounds good also I guess on the bright side if Def Con goes until the 11th and people stay over in Japan a few days we would actually be in town for the hard fork or the test Food Network upgrade and then or not for the test network upgrade we would actually potentially some of us be in town for the main net upgrade if some of us stay in Japan a little bit longer so that might be beneficial okay and then the rough plan

is for April 2024 the next hard fork if you want to go to the roadmap link that will get more information on that and that's the rough plan that will decide here probably in the next month as a final plan but it seems like everyone has agreed to that so far okay proposal for formal process okay for Izzi ip's I'm on the wrong agenda luckily the first three items are the same in almost every agenda I was almost bad okay so we do refer to

the roadmap list that's from the roadmap link so we have a bunch of proposed ones we're gonna finalize these today as accepted or not accepted for the Istanbul heart fork so subroutines and Static jumps for the EVM it looks like that one is done the issue is we don't have anyone on the call that I know of who can speak to this one so I don't know if this actually wants to be put in or not can anyone speak to this one again this is the static or subroutines and static jumps for the ABM [Music] having does anyone object to it I guess

is the better question or I mean who is who has objected to it i yeah i and yeah i guess it would be better if they were on so we could have some kind of discussion about it i don't know quite how to you know should i yeah we can have them on the record just yeah let's put out some reasons and then we can speak to them I mean it's not like we can't like between now and next Friday talk on get her and reach out to them and see if it's like something they can

address yeah so I've my reasons why I don't think I'm not proponent of it and I'm not against it per se I think its probe I mean it's a good thing in the end what they want to do but I think that the benefits that we gain our notes are not imperative with the overhead and the complexity of the EEP in total because it brings a lot of complexity to the consensus engine it brings a lot of overhead as far as I understand it to the actual ground and execution until we

get to a point where the code is actually validated before it's deployed so it can be executed without any additional checks but if I understand it correctly in the first iteration it will actually make things slower because we need to do that ad verification at runtime and the only way to get around that check is to also have the additional e with the EBM versioning which means we have to do two very pretty large consensus changes one with EBM versioning at the at the ploy time the second to implement this whole eat

and the way I see it the big benefits are basically better compilers and better optimizations during population and also better verification and that's especially adversarial verification where you might not actually have the source code because if you actually have the source code then you could do pretty good verification on ast level of a source code yeah so where is he very complex very large no real handsome gains in the areas where I okay that's a that's a fair argument for not having it

in Istanbul I've also seen the argument that it should be divided and some multiple IPS if it were to be implemented at all so that's something that should also be addressed I mean if we want the versioning if the versioning if you want to deploy time verification and versioning then I think it would be better to have that first let's see that it works iron out any kinks for that and then in the second hard work have something that uses this version anything I think it's okay wait am i unmuted yep I'm unmuted okay

so this is an interesting process question for officially confirming VIPs to go to a next hard fork should the champion or at least one of the EIP authors be on the call in order for that to get approved I don't really have a strong opinion either way on that does anyone have a strong opinion they'd like to suggest reasoning for the unless they are there to defend their case yeah I mean I think I don't think we should I mean I don't think we should

change the rule in the moment but it makes sense for me from a process perspective that you show up to the call just so we can have these final discussions yeah okay so what we'll do is we'll try to reach out to the author's after this call and then make a decision using the all core devs get her Channel and the etherium magicians link that's already been posted with the EIP and then Alex point Vera's Ozzy pointed out that the the wiki is out of sync with the official AIP meta that has the links to what is being proposed so can I

get a link to 1679 Alex did you have that open I was curious also like a quick quick run through the room like to get a lay of the land with people generally approved of 6:05 where if they generally are yeah I'm supposed to IP yeah sure go ahead so I think one of the company speak to the what but one of the

only I think close attention to address is a move like extraordinary difficult to write efficient and having some kind of abstractions of subverting calls and particularly local variables would go towards bridging the gap between what what you can do in the EDM and where you actually practically end up doing like like what I want to be writing optimized algorithms like generally is a rule of thumb I think it doesn't BM Kirby if you decided about 30 times more efficient than Brad to consider but yet I think part of that is because of the complexity of happening of this of the of the stack abstraction and having things like the a local

variable stored help immensely with this intentionally even over not having used to have you know compile real languages compile all the way but you don't establish time you just compile to give you in code which would be quite useful so I do you think like the result of substance behind the CIP and them and it doesn't it doesn't attempt to solve problems which which which do exist it would it would be quite quite a big if this was if this wasn't a standard I think of a second development okay do we have any other comments so if in general we would like to like improve EVM over

time I think that's try direction to go but I kind of agree about splitting that and there are proposals how to do it on the practical level and I mean we can give that these tool quite small features in this six one five VIP that can be implemented up front and yeah I kind of agree with Martin about version ink that think deploying that before we can actually verify a deploy time I will sure about

that however also I have some concerns about having versioning implemented and then never use it in the future if if either this one will delight for a long time or for other reasons there are other VIPs have proposed opcodes so versioning if the beats put in in this one without 615 would still have meaning okay can you elaborate on that so for like the chain code ID you could do a versioning you could do the what is it 17:06 I'm not sure with memories but the versioning to require the diversion abit

to be there for the new opcode to work and so we don't need 6:15 in for that versioning IQ to have meaning so we could put those two together and still get a meaningful deployment of the versioning signaling inside of the EVM icons we could also remove Col code if versioning would be Nabal yeah I agree that versioning is a pretty powerful construct and I think it could stand actually on its own even even if 6:15 in the end is never implemented to things that were one more thing about pursing

though is that there are two types of versioning one versioning is the type of Wersching where contact says I want to play by these new cool rules use these new pool of codes another kind of kinda versioning which is for basically awesome in 615 is that versioning version stamp made by the bouncing yes contract has undergone our scrutiny and is certified not to do illegal jumps whatever we're pursing mechanism we have it should encompass both like opt-in voluntary versioning and also this seal of approval type of version okay anybody else

what I'm kind of hearing is that it's pretty much this the EIP as it stands now without it being split up is something that would not be able to effectively go into Istanbul according to everyone who's spoken up about the timeline portion of it so that seems to be kind of a result and although there's some good things in the EIP it should be split up to make it a little easier to digest over time so with that I would say that we should definitely talk with their team and see what they think of that idea and then pushing it back to April if that is something that is that we can like split it out in a way that

makes it makes it easier for people to agree on yeah also mentions that sort of one of the benefits beside the verifiability is performance but can we actually put some numbers on that so can i I haven't been following the CIP so all J's if I I missed this but do we know exactly what performance improvements improvements could be expected from this so for example if I think there would be hack you mentioned the C++ implementation do we have some

numbers from how a smart contract could be rewritten to perform better with the CIP rather than without I don't believe you have any numbers of that maybe they will done some time ago but I don't have access to them but what I know there were not strictly benchmarking of that so we don't have active actively maintained implementation of it however it would be possible to do a site implementation the reason I'm asking is because so I kind of have the feeling that people are a big area this yeah it

because it seems large but probably if we could put some numbers on it and demonstrate that it is good because this and this and this then might maybe people would be a lot more open to actually doing it if they can see some tangible benefits yes as far as I've been able to tell in discussions it has not been I mean the speed improvements roll speed improvements has not been like the primary argument for this not what I've heard one of the agreements is it's easier to map stuff to Wasson if they decent yeah okay I can accept that

reasoning but then let's get rid of the performance arguments from the IP okay that's something we can also talk to their team about I'm guessing they probably ran something but just to timebox this let's go ahead and move on to the next one we got a big list to go through and we'll follow up with this on the all coordinate guitar channel I'm gonna write that down as a note for me to do specifically jumps okay on all four David Guetta so the next one is 663 unlimited swap and doop instructions I

think this one was already accepted yeah this one was a simple one that was already Alex wasn't this already accepted am I wrong I don't think it was properly discussed oh okay Oh unlimited swap and doop instructions but this would be something which can be made compatible with six one one proposals from six one five so this could be one of the ways to split up six one five okay and it looks like it has

all the necessary stuff within the EIP does anyone have any comments on it seems like a good idea to me even though I don't really understand it okay we don't really have strong feelings on it cuz maybe not a lot of people have looked into it so we can just say it's going in oh and if you hear background noise that's my cats so that's not me making chirps any other comments on this okay is this something oh go ahead yeah

this enable what what are the big wins about this I was just trying to unmute on one side it is solving a similar problem to what six one five is solving it subroutines because in the subroutines and in six one five the idea would be that you could access multiple stack items and they achieved that by introducing the

gate local well basically a local they call it get local but I think that's actually for the function parameters the subroutine parameters so when six one five you would have two ways to access items from the stack and that means you would be able to access more than sixteen items on this stack without moving items back and forth to memory and 6:63 just extends the stack access to be able to type this more than 16 items hmm now I think this has to be well discussed I don't think in its

current form with a discussion this should be accepted but it should be properly discussed and maybe some limitations need to be put in and especially consideration should be made so that this could be a precursor to the changes in 6 105 and the main benefit with accessing more stack items is making it simpler for compilers for example solidity to support bigger functions where people currently can experience issues like messages from the compiler to stack to deep where they use too many variables or variables and

input arguments and the only solution developers have currently is to split those up into two multiple functions well are they to buy constructions which I like like prefix like which one bad there are three options listed in the IP one is as what you explained having an immediate value another one is requiring a a push up front okay technically it's not requiring a push but rather taking the

value from the stack but you would want to extend this with with validation that it requires a push up front but then we're getting into six one five territory so I think there should be discussed in depth off of this call is this might take long okay we can definitely do that question pricing wise arbitrary duplication compared to memory accesses so why is doing dupe 255 better than pushing that into a memory slot and reading it later well it's cheaper because you don't pay for the number of

slots used in the stack but you do pay for memory extensions also stack based which is good for recursive calls hmm okay so I'm probably not going to argue against this because I'm not familiar with the design absolutely just one thing I could get I would add is that since we do have 1,000 I think I'll go yeah our settlement is currently 1k honestly I never really understood the reason of limiting accessing these items to only to talk 16 words because it's I

mean we're storing the whole thing in memory anyway we don't have any specialized CPUs or aetherium that would benefit of in the 16 limit so from my perspective raising removing this limit seems like a good extension even if it's not too valuable it just seems like an arbitrarily chosen limit that doesn't feel make sense so it makes sense from the perspective that there's a limited number of course only the push instructions have the data sections and if we do option a then it screws a bit with the jump test analysis yeah I think option a should only be introduced with

together with account versioning or even versioning okay let's do any other comments in the aisle core devs Gator chat so we can move on to the next one but it won't be going into Istanbul as Alex mentioned it'd be better to have a more full discussion on this okay the next one is 1077 oh good I do think pretty much every single IP proposed needs more discussions I'm not sure we can actually make decisions

maybe with a few exceptions on this list of 35 where we can say it's accepted or rejected but I think every like the majority of them you need a lot more discussions where we need to figure out whether they can be considered for Istanbul or not well yeah but I guess what we can decide this with GIPS would surely not make it and then everything that remains is tentatively slated for example anding consideration that's not ideal but I guess that's what we have right now so yeah I agree with you I don't know if there has been enough

coordinated discussion on all of these to make hard and fast decisions except for the ones that have been discussed sitting like a significant amount and I think part of that is that there needs to be more getter discussion on certain ones and theory Magicians discussion to kind of get at least a few people to say yes or no on some of these so yeah let's just run through these then and get a firm yes or no on the ones that we can and then when we can't we'll just have them slated as pending so we would need another section on the meta which would be actually don't we already have proposed so we would basically have

accepted and rejected on the meta and then proposed would be the ones we can't decide today so so far six fifteen is can't decide today 663 is can't decide today 10:57 which is prog pal i already mention this and the on Twitter and on getter and on an etherion magicians but we had our hardware our auditor not be able to do the audit anymore and so because of that and because of the fact that many of the questions that were brought up about prog Pao had to do with the amount of time that would take to actually build an ASIC and in the amount of time it would take or the efficiency

gains compared to a GPU a group of GPU miners and stuff like that we're gonna try to put the hardware piece back in I think we're approving at a hardware otter in the next couple days we have we found one who doesn't have a conflict of interest who isn't a giant ASIC manufacturer anything like that so that's really promising but also the reality of this is it won't get into Istanbul most likely because the audit should will likely not be done before is Stan bull if that changes between now and the next awkward to have meeting I'll let everyone know since we still

have some proposed ones to come up with so forth as far as the status I propose that this go into the stay in the proposed EIP section as something that is still pending further information from the audit okay doesn't sound like there's any other comments on that yeah I think from the beginning when we accepted it the first time and the second time I thought that the second time was but it was dependent on the audit and I think the question is

whether we would like to move forward from that one thing or the other that's what that's I mean that's that one decision and but if they always find something then we can always with gold up until the very last moment and that I mean the question is not if the audit doesn't find anything do we want to go forward with it because if he has some people need actually start implementing it and if they already find some issues then it's down the drain anyway well the problem is the audit might not get done until after the hard fork is our issue right that's hardware efficiency ordered right no this is both software and hardware

I'm only speaking to the fact that the hardware one was delayed which also delayed the software one because the audit package was a package to be signed by all parties involved and it wasn't able to be signed because of the dropping out of the hardware Auditor yeah so this is both software and hardware audit change whether the community wants or doesn't want to go yeah can I just quickly suggest we had these previous a IPs where we said if the person who proposed the EAP wasn't

available we would ask them to be available to have the discussion doesn't that apply to this VIP as well I'm filling that role as champion even though it didn't hog for the IP I'm just listening to the discussion mostly I do have one concern that I asked Hudson to add to the audit I'll detail it into a getter but I would want the auditors opinion if we do it as written before we go forward because I'm kind of of the opinion there's one thing that needs to be changed so I'll detail it and as not to derail this this meeting but I don't think the EIP as written today you should go forward without the audit confirming or recommending a change

so I'll detail that in and a fem thread okay so it sounds like if the de-facto champion is saying that it shouldn't go forward without potentially a change then that needs to be dealt with so yeah I'm still holding my position that the likelihood of it getting delayed until April is greater now because of the fact that the audit might not get done until after the hard fork in which case we can't really take out something we've already put in when it comes to something like this I love your jokes but now I think that their

likelihood of it going to April is greater now and that I will explore how long the audits gonna take over the next week and then update the all core devs chat about it so it'll just stay and proposed for now even though it has been tentatively approved pending the audit according to the second time we approved the CIP there's a possibility for a delay a coin desk if you're listening I have not officially delayed this at all neither has the core devs we're just saying we need to spend more time looking at the timeline and I'll make sure that I'll get that posted well after press time today great okay IP 1108 is to reduce the alt b and 128

pre-compile gas costs let's see if the champion is here hi wonderful and it looks like everything on here is this is the one for cross what's it called for making multiple libraries for generic op codes is that right so that's not actually what 29 which is just like for ball sports yep you're right I can give a bit of a background to say a few more I think it

would be a very very strong bonds with cerium sure so I think this guy he's been in the works for a while and in previous part folks it wasn't because well I'm partly because the existing client imitations either rod some of the BN on to eight freakin bhai brothers didn't justify his guests possible and also the the value of doing reducing the gasket was more speculative of things the concert being changing quite significantly there's a number of companies or organizations developing trivia see preserving technology being solutions on the etherium I'm CJ as to take the privacy provider so one of them

and we use elliptic curve dropping extensively you know you know protocol and on smart contracts alongside the relative metal ads see step and at the moment the the precompile Gasca Judaism but as quests from bottleneck to deploying more advanced and innovative crypto system second solve a lot of Syrians so what address some of the variants technical limitations such as a lack of privacy or a transaction throughput and so so actually in the IKEA are to give a description of their some of the things that we as be

deploying to theorem were the people hard costs low and offer the start to be actually practical things like confidential widget voting having a confidentially centralized exchanges as part of all the fillings things like that and the I'm gonna I'm after time boxes to just another minute so we can go right so fast enough to justify help when a quite a few people and the institution is building what I'm feeling today to do more advanced innovative things with

there and I think the whole ecosystem community will benefit from this he happy significantly also for the Elm yet that the actual iron has already implemented to the major clients so the implementation work should be extremely denied okay questions about the benchmarks that published so the benchmark listed for the two one one beta release and the benchmarks after pairing optimizations are you're listing the exact same test vectors and I'm just curious if if you on the second time did it take the exact same answer did you take the ones that were performed the worst

no we just so I just took the I literally just Claire took a fan of the previous benchmarks from the same tests and there was an intention to kind of gain this benchmark it would be interesting if you could run the benchmarks for the full set because it's not sometimes you know the worst case is differ especially when you changed the invitation around will be optimizations and suddenly someone other or these perspectives become the dominant worst behavior might be I mean I could just say that anecdotally from from AG like

messing around running tests like the these were outliers so is a belief I'm very happy to publish to do the same benchmarks again on the same computer that they already know once were made on yeah forget the same kind of numbers I'm all for it and if I can chime in for a second chair from a very high level the reason these were priced so high in the first place was to prevent to us attacks from a relatively new on chain primitive right we have no evidence that

gos attacks are forthcoming the actual compute time cost of these is much lower than the gas costs would imply what we do have a lot of evidence is that developers are excited about these a lot of projects at every eath global hackathon working on snarks and on chain verification of snarks and signatures right so we've gotten rid of the reasons to price these hi and we have a lot of reasons to make these more accessible to everyone um I have a quick question is this something that the pre compiled for elliptic curve linear combinations a IP

that would make that generic enough we wouldn't need this or is that not the case because I know there's other AIPS where that is the case I believe this is the ulti n specific pairing operation it's not the general with the curve operations okay so that wouldn't be included in there I mean I've no idea if that's okay but I and I totally agree that if we can make these cheaper we definitely should because we went through all the trouble of putting them in there and if no one's using them then it's wasted effort and it's extremely cheap I mean it's really easy for us to just lower the price but we just need to make sure that we know okay so it sounds

like this is approved pending a benchmark that will be reviewed by the next meeting correction regarding the generic one the genic one does support be in one to eight and the proposal for generic precompile but i don't think this should make any difference to the question whether the specific being one to eight pecan pie it should be adjusted or not oh yeah but apparently the one that we have is not usable because it's too expensive and if there's no point to make to keep it that expensive and I mean even if we add the generic one there's no no reason to keep this one unusable yeah you're just saying what

Alex just said basically right yeah okay so yeah approved pending a full or more full benchmark sounds good we're not gonna get through all these today I'm calling it now but uh well we'll see what we can do precompiled call up code to remove call cost from four pre-compiled contracts that's AIP 1109 and that one it's loading as a Jordi's VIP so can I have a quick comment yeah sure I've been commenting on that one and

initially it was a different the the proposal was very different it was about changing the existing calls to behave differently if they are targeting a pre-compile but that was changing to proposing a specific opcode but I couldn't read Geordi for a couple of months he wasn't responding on on the the forum so I made another AIP the last one on the list 2046 which practically is doing the original proposal it only changes static call to behave differently I think these two should be discussed at the same time but I'm not sure if you can discuss them properly

today okay so you don't want to really discuss 2046 today I mean 2046 and 1109 they are practically solving the same problem just different proposals for the same I think they should be discussed together but I'm not sure if we can discuss them together today mmm just add my two cents I like the original approach to that we can if we can make the code original cause a bit smarter that seems better than introducing yet another opcode which does the exact same thing just as pricing whoa oh I've been talking and I'm on

mute I said okay we will table that one and that'll stay in the proposed category both of those and then hopefully Jordi can chime in and if not we'll just use Alex's if everyone agrees on that one yeah yeah so after this is done I think it was James Hancock who was keeping up with which ones are accepted rejected and proposed is that right James so we're noting it in the in the chart while we're talking Oh wonderful so there's a Google Doc and so now there's three places for these to be

there's the wiki there's the meta EIP and there's a Google Doc the Google Doc is gonna be most updated the meta EIP is going to be probably at least updated along with the wiki at this point and that's more because James is doing the work so we'll just use his source of truth next up does anyone else have comments I'm just wondering why Cannot we keep the meta key IP updated oh we can't I should know anyone was doing it I mean anybody can submit a PR James are you cool doing that as well

now but I can work on the wiki too I mean I'm working on the testing on coordinating testing so I kind of have to do this already so I'm doing it okay thanks so much so the next one would be net gas metering for s store without dirty maps this was the same happy that we looked out from Constantinople I what's the difference between this one and the one that turned out to be broken and I can't comment on that because I've

seen the Dupree request when it was added back in there's no difference it's the same proposal but it the author once he proposed it together with account versioning and only enable the change on accounts which followed the newer version so from a process optics I would prefer to see this one under in the EIP number since we already tried to deploy it and how to pull it out actually I think it's good I mean it is the exact same yeah so why should it be changed number the exact same implementations we pulled out it's not is it a different

one it looks like the exact same one it's a tweak it's a small change but I think a new VIP would make it clear that we're doing the version of it with the change this is the the old one there's no change made to it yet but I would agree what was said that probably a new version of it should be made which has this changed saying it's only Nabal Tom's on a specific version and it requires the account we're discussing the reason why it fails previously and

why that you don't add correctly okay uh Phil could you let Wade know of our request it's also if you didn't catch all that it's gonna be in the notes and probably the summary after this call hey Phil you're muted if we if you're talking okay I'll reach out to Phil afterwards and make sure that our way I can even reach out to just way directly on getter so to clarify this as as was implemented for Constantinople but requiring the versioning bit turned on I

think so but it's not clear because the author hasn't fully explained it that's why I agree there should be a new IP referencing 1283 and explaining the differences so I don't think we can actually make a decision because we don't know what the complete proposal is yeah this is definitely gonna stay and proposed for now and I'll talk to way afterwards about creating a new VIP so that's gonna be an action item for me if we are going to propose a new EIT that is essentially a tweak of an old man perhaps we should retain the original authorship so since

the Johnson kind of developed the whole thing would be nice I had talked away about that before and to Nick and I think it was decided that way was going to maintain authorship of that particularly IP because of the changes that it made from Nick CIP and Nick was okay with that what's the next one and this list is long ad chain ID opcode that's 1344 I felt like this was non-controversial if I remember yeah I think one one extra out code one extra might loss right I

know also that someone has while competing eat I guess he didn't make requests to this meta EEP but the other Eve proposes you could I don't know how about test the certain number if the chain ID was active at that point or something included here its 1965 and 1959 okay so these those three are also annex or yeah I guess those should be discussed at the same time okay what

were the two 1959 and 1965 okay I thought it was 85 for a second okay we'll start with 1965 method to check if chain ideas valid at a specific block number that was ronan and they aren't here and 1959 is also ronan so do those go together is the same EIP even one as an opcode and what is a pre compile I advocated for the pre-compile it's a preserve opcode space so I think the choice is really between 1965 and 13 44 okay and let me just look at how complete the CIP is okay the spec and

everything else is fine doesn't have test cases but I don't think test cases are needed for something like this right or not for not for a pre compile that they would write down in the EIP am I wrong I would like test cases but I don't think it should be longer today okay yeah it actually test cases is TBD yeah we can maybe go ahead and just accept or deny this one so it's between so the first one to get the current sane ID is a trivial implementation the other

ones I think maybe are not I mean the client to maintain a mapping of all the historic charities which on the main earth would not be a problem and well did we ever actually change chain ID in the history of any network no I wants to make it sorry that's our other thing that I think we just enabled it during the oh nothing or shocking about homestead or at the homestead yeah Dana what were you saying that you said it is

it's to support like to change like etherium classic and other ones that want to do a contentious work away from any of the other etherium change like a contentious robson fork or something yes it's a delay in the ground for if something else did someone wants to break out from ethereum a net which the chain ID right that's why there's also some models of non maintenance where when they fork they change their ID to make it clear that they change the rules of the change it's not always a

contentious point and it's not always working off of main net but I think that would be something that could be introduced on their own clients I don't know if it's a requirement from a net client to support it would be my opinion of it so I think they both to go in but I also think they can go in independently afford free compiles like custom pre compiles that maybe this kind of fits into neatly that that non main net networks and add a custom freakin file that does this 13:52 is the next on

the list okay let me try to get ronan and see if they can advocate for this at any point and say which one they prefer since they submitted to and we'll just table this and for now I'd say where does anyone else have an opinion between the two of them I concur with Martin that the opcode one team that is really should be a thing I mean get the current chain ID here the current chain idea and you can do whatever you want with it and I mean you if a fast train ID is important for

a contract and they can even store it or something whereas the alternative where you can look up look up the chain ideas an arbitrary past 20 time and one of them one of the weird quirks is that why does why does the EIP specify that you should test whether the chain ID is something versus just return it it would seem a lot more meaningful for me to just return it under the contract and do what every warm but I actually asked them about that on the PR the as far as I understood it it's because it's considered that how was it at an earlier point in history if you know on say 95

it was considered that even ox 0 that was about a chain ID so it was something to that effect that the subset only decreases maybe but he did answer that question on the tr4 that each so I motion we take we accept 1344 and we tabled 1965 for further discussion okay that sounds good to me all right you said we accept that yeah

yeah there to talk about them then we reject their second one I mean that 19 I think 1965 can go in with both of them I think 1959 is the only one we need to reject that's two versions of the of the historical one historical and current I believe can both go in I I don't I don't really agree with having two mechanisms to do the same thing I mean just equality so there's no consensus we need a table both of them as a possible to take this offline and three yeah yeah that's why I was saying I need to reach

out to Ronan so I'll put that down reach out to Ronan oh yeah and Bryan I know I know Bryan I actually don't know if I've ever met Ronan no I've met Ronan okay 13:52 specify restricted address range for pre compiles and system contracts was that Alex I'm guessing yeah so Alex if you want to give just a quick I don't I thought this was just setting out address range spaces for pre-compiled so it doesn't seem controversial there were

some suggestions that it made may not require hard work it should be just accepted or made final and maybe some tests would need to be added into the test suite well it should not so shouldn't even be in this list okay cool [Music] attend to like refuse creation contact creation contract these addresses actually that's an interesting question

because on private works it's totally possible in the genesis of contract on these services so at that point is Eve needs to let us know clients now how should we handle that there another problematic thing is if we specify that this isn't a restricted address range is that previously when we had the clean ups and during this alone whatever part for where we cleaned up the empty accounts we actually accidentally deleted the right handy and then every client now has this weird special clause in the code base that

bragging B is a special snowflake and the reason why rest of them were a special snowflake is because somebody actually sent why wait one way to every one of them so that they they become non-empty but I think we only send one way to the first 256 and then okay what happens with the large the higher ones so it's a bit of a weird I mean it doesn't BCIT doesn't really provide any value but it does make reasoning about things a bit more complicated because all of a sudden you can misinterpret things or easily well it is certainly prerequisites to some other realities

which don't want to list every single precompile when making calls to pecan pies cheaper as an example right so one thing that I think should be answered by this EEP is if there is an existing network which has a vm code on one of these services what will happen those I mean those future p-switch lower the cost of recompile calls how should they handle that I found a question sam-i-am well honestly I would say that pre-compile should be at least in gap we have a list of the compiles and hard coded

and in my opinion if you want to make freaking virus free so to say I mean calling them then essentially if they shouldn't depend on the address rather they should depend on on how the chain is configured if the chain defined that we have eight pre-compile them it doesn't matter what you have on what address those eight cap the fee waiver and the rest of them have to pay in my opinion that would be the logical behavior yeah I agree because those contract they exist as methods already in the VMware as the other stuff needs to be looked up from this okay so it sounds like there's needs to be more

work on this Alex can we like bring this together and the femme oh you're muted if you're talking sorry I didn't catch up oh yeah I was just saying is it okay for this to be tabled yeah sure definitely should be further discussed there's just a discussion URL which probably is there the best place to do it okay oh yeah there is one I thought there wasn't for a second there is an ethereal missions thread okay great so there's a few people who are on the call today who came on the call specifically to advocate for their EIP so instead of

going in order anymore for the last 15 minutes let's run through those II IPs I know that a big one was the fee market change for the eath 1.0 chain it's 1559 Rick is that the one you're championing championing yeah yeah that's me I I don't see how we could possibly make it in Istanbul I mean well let me let me rephrase it's actually possible that we make it in Istanbul but it seems unlikely so I don't know from a process perspective how to move forward I mean we're making

progress but you know it's a pretty complicated change sure so it would just be delayed till the next hard fork yeah that's pretty much the process and you would continue to work on it and we can discuss it and further quartet meetings as it comes up or needs to be discussed okay so yeah so that that one I think we should you know assume that you know it's possible that it'll make it in because it's so far ahead which is good but but it's difficult to say I mean it seems unlikely right now I've never seen this so apologies and think stupid but skimming it could you also try to try to

briefly talk how I mean not here rather on the IP how this whole thing that's not working for certain transaction propagation because the transaction pool logic is really heavily tied into how the whole how miners accept different transactions and if we start changing the that logic that maybe the networking layer needs some patches - yeah I'd be happy to make those changes can you just make an issue so that I I'll address it in the in the IP yeah okay next up I'm going let's go to e IP 2045

which I'm actually not even sure if this is a proposed one necessarily but Casey was in here to talk about that today so Casey if you want to just for a couple minutes discuss what this is and if people should look at it or what's next yeah sure hey so it is proposed it's the there's a PR pending to add it to the to the MIDI IP for Istanbul but in brief gas costs are balancing three separate things disk IO Network IO and computation currently disk IO is over T over utilize and is the biomech network and computation are underutilized so because they're they're overpriced is the main reason they're

underutilized so there's the e IP to reduce the price of call data which will help better utilize Network IO there's an e IP to increase the price of s load which will help rebalance disk i/o there's e IP to increase the price of s store and create U and so forth and that makes it possible to boost the block gas limit while maintaining the same rate of state growth if we boost the bot gas limit while simultaneously increasing the price of state growth that's effectively the same as keeping the block gas limit the same but reducing the price of all other operations all the non state expanding operations so

that's again the computation and network related operations which is reading the the price of transaction data and and call data or call data how much can we reduce the price of transaction data depends on when bandwidth becomes a bottleneck how much we reduce the price of computation depends on when computation computational op codes become the bottleneck so currently computational opcodes are we'll see not the bottleneck even in an unappetizing so that's what Martin swen d's recent benchmark showed that s load is the biggest bottleneck and so the EIP to

increase the price of s load proposes taking it from two gas costs of 200 to a gas cost of 800 even after that 4x increase in the cost of s load it would still be the bottleneck according to those those benchmarks so and note that these benchmarks were done on gas so just using the speed of computation on gas the benchmarks show that that use the cost of disk IO needs to be raised substantially or the cost of computation should be reduced or a combination of both because the costs are all relative so reducing one is the same as raising the other its equivalent so what's kind of crazy is if you benchmark gas against

an EVM implementation that's optimized for speed computational speed which like EVM 1 which is what we did and and the graphs of those benchmarks they're linked in the agenda and they're in the IP and they show that we can get a like a 10x speed up from just from optimizing the EVM so that the proof-of-concept the fast EVM implementation that does this is it's called EVM one and Pavel he wrote it for fun during Christmas break but so that's two significant speed ups which are basically low-hanging fruit right now so the first is just

rebalancing the cost to the current death and parity speeds and then the second speed-up is optimizing death and parody to get the same speed up as EVM one or you could just you know use EVM one but a fun thing to try is them to take EVM one and benchmark some of the most optimized EBM contracts and so we did this with the contract that that Zack Williamson wrote he was speaking on the call earlier the contract called the wire strudel it implement the same that implements EC Mall so this is the elliptic curve multiplication the

precompile that was added in Byzantium so it implements the same thing and it beats the precompile in gas costs in computation time EVM 1 it executes its EC ball in 500 microseconds and that's compared to native rust which parodies is for the for that pre-compile x gifts in 300 microseconds and death is more as more optimized with the some native go and assembly and it runs in 100 microseconds but the fact that the EVM bytecode that does the same thing as a

native pre-compiled in and 500 microseconds compared to you know 300 or wondered I think those results are pretty shocking you know to optimize interpreter executing an optimized bytecode can achieve speed not not a lot slower I mean I would almost say it's near native and even that a result of 500 microseconds isn't the best we can do there's more optimizations remaining there like a well-known one for elliptic curves montgomery multiplication that wasn't done on wire strudel because why should was optimized for gas cost and not speed and the price of you know mall versus mod wall is is not not really

accurate to to the runtime so the more optimized one would be even faster if you benchmarked it although it cost more gas at the current gas right now I mean I'm in a time boxes that's it so when two assets Zack if that's right about you know that those current benchmarks for wire strudel it could be optimized to be even faster than that right yeah yeah as you said over multiplication probably the speed it up by may be effective - so the DI optimize the gas smoke not for runtime yeah so I mean that that's it the conclusion is there's room

for substantially reducing the the gas costs of computation and we need you know fractional or to some way to price opcodes below below the minimum unit of one okay thank you and is there a discussion link for this which would see IP specifically yeah magicians all right okay great and then lastly I think this is gonna be one of the last ones James Prestwich is advocating for a couple of AI PS if you

can explain the EIP what their name is and spend a few minutes explaining what it is and if you want people to comment on a certain thing so the first one I wanted to talk about is 2024 this is Blake to pre-compile so far if your game only supports shot to a very normal standard hash function and check X 256 which is completely weird and an accident of history for people like me and the Z Cash Foundation and the ipfs team who worked with different hash functions that are common and well-known these days like Blake - it would be nice to have access to those on Shane some

specific things this gives us is echo hash evaluation efficiently right now it takes 16 million guests to evaluate one equi hash at low security parameter further chains that are going to use it at higher security parameters it would take 32 or 64 million gasp to do that so I have a use case in mind for this today that I could implement you know it's just the Blake to precompile comment on that the benchmarks that I just referred to there's even a point optimized like to be write code that Zack did which reduces the gas goes by a lot

and then when you benchmark in an EVM one and a best EVM implementation it would be plenty cheap enough without a pre combine without a freaking pile so the thing about echo is that you have to do 32 indications so even if you reduce it by an order of magnitude you're still looking at one point six million gas per invocation in order to verify a set of Z cache headers for example you'd need to do somewhere in the neighborhood of 30 to 40 in vacations depending on how much security you want right it's a reduction of more than an order of magnitude but okay great so how much are we talking on chained optimized gas cost today yeah um

so I'm happy to show this was good with you because it but yeah basically is about 30 X okay so about 30 X so we're looking at look then you get a 10 X on top of that because it's the speed-up from an optimized EVM optimized with appropriate gas costs in quote that's what the proposal is to instead of adding more free compiles to reprice EVM opcode cost so that we don't continually need more freaking vials and did we land on accept it for that one no no yeah but I'm just commenting that it helps here

I'm sure okay but the question here is whether this is a useful thing within the next about 11 or with an 11 month lead time assuming that the next time monk has hard fork has about the same lead time we're looking at 12 months at so at 23 to 24 month lead time for something like this I think you know even assuming that this optimization comes out in two years it puts us in a really uncertain place with the launch of eath 2 and it's a full year slower so for those of us who are looking to end comment things it's really not a it's not a meet in the middle kind of auction

it's a hold off and we'll see what the landscape looks like in a year and if we can connect you with Zach and Casey to further this discussion I think that would help because of our time restraints on the call and then if you want to come next week James or a two weeks from now and continue the discussion just because I didn't give you a ton of time that's perfectly great as well I will probably be on a plane at the time oh it's two weeks from now sorry so we're we holding these discussions for two more weeks yes as if they are completed and ready to not

implement it but if they are completed by as far as being merged as a draft and having the motivation and specification sections and things like that they can be considered for Istanbul as long as you spur discussion on fellowship of a theory magicians in the all core devs get her channel and get a little bit of consensus on it that is one possibility other possibilities include like tokenized assets you can do or like I mentioned with ipfs you can do a lot

more verification of off chain data using these using blink too you can also use it for deep red cross chain interoperability like two is a relatively like uncommon but normal hash function out in the wild yeah and actually I think we have Brad here to talk about that today after you're done with your comment Martin yeah I was gonna say so we have and have had for a long time PTC relay I mean we have possibility to do cross chain swaps with Bitcoin the biggest but it's not if if you'd like to read my

extensive articles on why BTC really is infused I'd be happy to link them yeah so I'm happy to like point you to them if you shoot me a message after this one of the like main really cool things that differentiates this from BTC really is that the Z cache team is considering fly client merkel mountain range commitments for their next hard fork which would be about six months from now so getting a blake to pre compile into a theory i'm on you know a slightly longer timeframe would allow you to do not just a z cash relay which would be primitively expensive but the like ideal minimal fly client relay which is it which is a

orders of magnitude more efficient than relaying over every header um so it's it's kind of like a unique opportunity here because the z cache team is looking at hard working in features specifically for this as well oh yeah okay because it's really really never never to go so yeah so sorry we're going overtime everyone but I definitely wanted to introduce Brad Miller if you want to do a quick intro Brad and then just say why you're here so I'm Brett Miller I'm the developer

relations manager at electric coin company and honestly James did a phenomenal job framing you know a lot of the reasons why we want this I was really here just to show support and to make sure that we at least have some more time to try and make sure this can make it in the Istanbul we're very interested in seeing it push through and I'm personally shepherding this effort on the electric coin company side and I can coordinate also with the Z cash foundation so you know I think all of the technical reasons the James laid out at least present a strong case for it and now it's just a matter of making sure we find the appropriate people to a champion this board yeah one thing I would like to add that so

here we kind of have two approaches one of them is cases one EVM Oracle that one probably I mean I mean honestly I'm not sure how whether that would fly ever because that would require all clients to use a single legal implantation so that's probably a very political thing but that said the pre-compiled approach to me seems like trivial the idea to be or feature to add because essentially for example Blake do is a popular hash function it's implemented by in probably in every single language out there so probably integrating that would be half

an hour's worth of work so from this perspective if there is a legitimate use case I think adding pre-compile for a couple of high-profile function seems a no-brainer there's also been quite a bit of work already done on this which is you know another I think you know positive somebody add electric coin company previously did quite a bit of work on this Jay grabber she she was I guess one of the two authors on the original VIP as well as a reference implementation so we discussed it like two years ago or positive yes I just never got in there are also use cases for Blake to asks where's the precompile

include Blake to us functionality or just like to be this one was just for Blake to be I believe okay yes I guess we can make a make a list of for example Emily make a list of hashes that we would like supported and I mean adding one hash reading the five of them is probably the same effort maybe testing them is a bit more effort but it's not really an effort to support new hash function so I don't really see the reason why we wouldn't do it I mean we compile address space is kind of

infinite adding code is just pulling in an external library because obviously nobody is going to implement it from scratch it's just figuring out the gas prices yeah I didn't mean to suggest that we should do you know P 2045 and reduce all the computational gas costs instead of adding Blake to B but just that just to point out that the need to add Blake to B now you know there is another option which would supersede both the potentially superseded both the pre compiled for like to be and many other news cases okay all right thanks everyone there is a fellowship of a

theory magicians forum for Blake to be the people can participate in and I think Brad and James are monitoring that one as far as I know and that's in the EIP thanks everyone for coming today and we'll talk more on the awkward ebbs get our channel to try to kind of wrangle in some of these AI peas that are still stuck and proposed and as quickly as possible decide on which ones are being implemented for Istanbul thanks everybody and we'll see you in two weeks goodbye right

[Music] [Music] [Music]

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

[Music] [Music]

[Music] [Music]