All Core Devs - Execution #21

Transcript

[Music] [Music] time

[Music] thank [Music] am [Music] [Music]

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

[Music] e [Music] okay great all right I think that the

internet can hear us now uh so we can go ahead and get started um on the agenda today all right the first thing is uh P talking about um EIP 96 uh he has some uned comments and issues about the block hash contract so you can take it away P oh uh there's not a lot to talk about today I think in this case but uh I left some comments uh around month ago or maybe even uh more than this and uh so I have I have like different

implementation uh but it has not been finished yet so I cannot talk about this this time um but in the in the main Pro requests uh there are some comments and one uh solid uh serpent related issue about signed integers uh but in general I think this is not finished case in terms what is exact the contract that we going to inject uh in the dedicated account um so Nick and I or Nick has been working on some tests with the version of the contract that I came up with two weeks ago and it seems like uh

what's the progress on that n uh so we eliminated the bag that we found earlier but the I seem to have uncovered another one that only manifests uh when it's added a lot of hashes which I haven't tracked down yet um because reproducing it requires creating all transactions okay so yeah okay I have also there's a PR request to the pr request that also have my test that I was working on some time ago uh so I think uh what I can say now it's like we should try to uh cooperate after the the meeting next week if possible on this

because yeah I was busy with other stuff recently and that's a bit not prepared for this meeting but I hope we can yeah almost finish it uh until the next One MH yeah sounds okay okay cool so yeah sounds like we'll have more information in the next meeting um or actually if we could just finished that up in the EIP itself uh since that one that one's going into Metro right yeah okay great yeah cool all right I'll put that as a to-do uh was

that any any other comments on that all right sweet uh we need to decide names for Metro part one and two or we can just keep it as Metro one and two uh doesn't really matter to me much I think it'd be cool if we had names anybody have any ideas yes sorry go ahead go ahead I was gonna say I like falic suggestion for bizantium and therefore the second one should be called Constantinople wait what was that first suggestion bizantium oh bantian so wait okay maybe this is this

is weird because I was I was thinking about exactly those two cities too Constantinople okay I always say bantine is that just because I'm American or something so bisane is the demm like it refers to things that come from the city of banum uh got it okay that okay you typed it thank you I got it of here now I'm good with that uh any other comments so the Metropolis name is gone uh when we accept different names uh there's two approaches one of them is for the first Fork to be called metropolis and the second to be called something else and for the the other is

that we call the two hard Forks of two completely separate things and um the the brand mopolis can kind of abstractly refer to the whole thing okay yeah I kind of like the idea of it abstractly referring to the whole thing or having uh having like Metropolis B basically like Metro bantin and then Metro Constantinople just whatever people want to use yeah that's that sounds good yeah I what I'm going to do probably is just refer to it abstractly as the whole thing uh but yeah doesn't truly matter except to like I guess it would need to be more

specific for things like um technical or spec papers like the yellow paper so cool all right well uh any other ideas other otherwise this sounds good and we'll probably float it in a few more channels before it's like official M okay cool next one is updates to testing um let me see uh yoichi do you know of any updates there um um okay so me say it changes like uh the gas price CH gas cost change for m x and the status code

in the transaction receips these are already reflected in the tests however uh inm tests the Metropolis version is only one hard work not two yet so so we will work on splitting the changes into two okay great uh let's see anything else or is there any um is there anything that is um impeding any progress or anything that uh we could help you with yoichi or the for the testing team

itself um I think it we can gradually move towards actually using the test Suite the comparing clients and I and probably de Dem also expect um feedbacks from client teams because they might find bugs in the client but yeah probably they will find bugs in the test Suite as well so we are we expect these kinds of feedbacks okay sounds

good um yeah just let us know in the cordev channel um and and I know that I think we're going to get to this in a second but the uh gas prices and op codes um because I know Martin sent some of those in and there was um a few other people on the channel doing that so we'll get to that soon MH okay so um details and implementations of theps uh we I think gu and parity generally have the same updates every week that they're pretty much done uh gu or parody is there any other updates you feel like mentioning no not not really yeah we're

still waiting on test mostly okay great um CP P ethereum anything worth mentioning our updates just correspond to the updates to test that uh just mentioned because that's come from CBP implementation so they have those two updates new modex cost formula and uh uh put in status coding to receipt yeah that's it okay sounds good um and then yeah yoichi um any issues or comments about yellow paper no not much all right cool um vitalic uh pyap

not much cool all right we can move on to uh item two determining gas prices for new OP codes and pre-compiled uh so that is mainly Martin I trying to look at what he wrote yeah oh hey Martin I didn't see you come in here okay joed little little while ago just just came home awesome um yeah so let me paste into the allore dev channel uh my latest uh uh measurements from a while back um I don't really know how to uh how we go how we're going to go about to decide

the the gas costs we should compare them with the old one or we should if we should try to um decide on what kind of CPU architecture is the target one and then try to reach 10 million gas per second uh so basically what I'm trying to do is just provide some numbers and you can take it collectively from there I don't know okay so one thing that I wanted to bring up about this is if the gas prices are misconfigured what is the risk to the network or is that something that it wouldn't be super harmful before we could change it again at the Metropolis

part too realistically it would just mean a network slowdown so if it was uh like if it's we terribly miscalculate then it the network like there's a risk of Dos attacks like last year if we slightly miscalculate then like an attacker will be able to put push the uncle raid up to like 25% instead of 15% but otherwise it'll H along fine okay that that's a little yeah that's actually better than the risk I thought I would have um and one thing that we can mention with these I mean the new things that we're adding now they're all CPU intensive so they're they're kind of easy to measure as

opposed to something which is more uh depends on the size size of the state or or whatever so I think we could we can make pretty good uh detailed analysis on on what the cost should be but then the question is how do we decide what the optimal is and should we should we make any other changes while we're at it and like well I guess we should not but okay um the other thing just oh go ahead sorry um some of these operations uh use code that is uh heavily tailored towards or at least on some architectures it's

it's assembly intensive or or something like that uh is are machines like like arm and other architectures in scope here and should we check the performance there too or should we just assume that it's probably fine what's your thoughts on the matter I'm in oh I think Christian was gonna say something we're all very polite here yeah withal do you want to go ahead I'm

in inclined to say just checking it just on standard computers should be enough because I I don't expect any I don't see any a prior reason why these op codes should be much worse on arm than anything else that happens in ethereum do we have uh I mean can we easily test that on arm we can test it then perhaps we should just run it once and just check that it's not terribly off and yeah don't we have like a the like a on embedded devices and so

forth mobile phones yeah uh I think go has a build for for arm architecture yes uh C C++ does not we can try working on that but it might take too much time to be worth it are any of these libraries optimized for have assembly optimization for x86 I guess they also they even have smt uh optimizations so you could assume that they're they're not optimized for arm so if you disable all the optimizations and

do a measurement that would be the upper band for arm yeah fair enough so in terms of C++ uh we don't have any assembly enabled uh in the underlying big number library that we are using uh but the reason for it was mostly it was easier to integrate this way so far so the library called mpir has then like different paths for different architectures even for different uh revisions of of Intel CPUs and so on but we haven't enabled that

because it was harder to to build on Windows I think uh but it speed UPS the the performance by by seven times more or less so the benchmarks are there uh from my side are for the code that has not been optimized for particular uh 64 bits uh x 86 architecture so the other thing I wanted to mention

so Tim um he like a week and a half ago was talking about putting parody benchmarks up and I know he had worked on them before did he ever put those up or um I guess follow-up question should there be a centralized place for all this or is this something that can just stay in the cordev channel and we keep up with yeah I think AR published some benchmarks for parity the other day intive Channel Yeah the code for the benchmarks is there someone just needs to run them compared to other informations on the same machine okay I missed that link I might try to find it

um Okay cool so let's we should get some people on that like cuz I feel like this has been going on for a while so we probably just need a group of people and I I know Tim volunteered so I might try to get in contact with him um and then yeah so you were asking Martin should this be on one I guess type of should this be targeting one type of architecture you were saying I'm I'm kind of saying that we're to get the numbers we have some numbers to go on and some code to go on the next step is how do we well to actually decide on the values to

use that's kind of my take on it okay um H how has that worked in the past uh for for instance Homestead like is it as simple as just deciding in a chat or was there like a anything formalized online or because I wasn't here back when Homestead or I wasn't you know on the cev's thing when Homestead was happening yeah me neither vitalic do you remember how it worked or Christian

did we have such things in Homestead yeah actually you may have not had any changes but I guess this would have been yeah actually you wouldn't have had that many so maybe this would be yeah that'd be way too long ago like Frontier just a launch yeah so um I'm going to think more on this and maybe Martin if we could collaborate on getting this figured out but I think we can just figure out who in the chat has talked about running these and then if we need to get more numbers that's fine and then if not start throwing out recommendations for people to comment on yeah generally I find that if you

just throw out like a list of like here's what it can be and then people will just give their opinion that way yeah so for example in the gu that I put in the all qu of now there is a a calculation for what the gas price should be if we go for 10 mlion G per second on my particular machine uh and I think all the new operations should be increased by half or by they're at like 60% most of them 60 to 90 they should be increased a bit and it looks like all

the the old ones are heavily uh overpriced right now particular like particularly ripe MD um yeah so so I'd probably suggest that we raise the gas limits from the current suggestions in the e okay I took note of that um and uh one other thing so I we might have talked about this before but in order to test this on different computers I guess would doing this on

Azure or AWS across different um you know packages that have different like CPU GPU specs would that be beneficial not GPU things I can't imagine um yeah I I don't know enough about how these tests work but I was just thinking something that would optimize running them all right um so yeah next steps for that I'm going to let me put that as my to-do I'll talk to Martin more about it and we'll figure out a way to find some more people to run these on their

machines get some more data if we need and if not just start suggesting things for people to comment on yeah um sounds good is there anyone I mean maybe we should form some small group Who Um can look into this yeah AR Ary is there anyone from parody side who's ran this or would be good to help uh with this at least from running it on parody yeah I can help with that good okay great yeah and then we can make suggestions for the next call Great okay so the primaries are going to

be Martin and arcadey and I'll get in there too just to kind of learn more about it great and then yeah by the next allore Dev call we should wrap that up um let's see uh any other comments on that uh um think of anything okay great next one review time estimate for testing and release um it's going to be August in a few days and I believe we originally said something like August to September for testing and release would be ideal um I know that last time let me go to the last agenda there was a couple of

like very important do uh and I wanted to go over each one of those and see where we were at so let me put those down okay so the first one um Nick and vitalic you were working on um the 9698 and addressing concerns with gas scheduling in 198 uh what's the progress on that okay so for 96 um We are continuing well Nick is working on the tests and we'll continue to go back and forth and then and we'll report back to the group when we have something that looks like it's passing everything for 98 98 is the intermediate State rout removal right so I remember

that the thing that we had wanted to do was basically replace the 3 like starting from the Metropolis block replace the 32 bytes with the intermediate State Route with a single bite that is a one if the transaction passed and a zero if it failed is that right yeah worked okay then like I don't think there's any gas related stuff that needs to be figured out there then for 198 so that's modular exponentiation um the main thing that still needed to be figured out was the multi corat multiplication complexity formula and I had suggested one a few days ago and it seemed that and it's

it's basically a piecewise quad quadratic that tries to approximate a like end to the power of 1.6 and people seemed relatively fine with it yeah that already hit the test cases yes okay then yeah I don't think there's anything else yeah there was a couple other to-dos let me go through the rest of them I think only uh two more because we already talked about gas benchmarks and op code gas data uh so the EIP for minor reward reduction was going to be combined potentially with 669 and I actually haven't checked on that did anyone uh happen to put in the minor reward

reduction let me let me actually check out that EIP okay so so speaking of these kinds of tests I forget did we have the block tests for any of the block specific eips so that includes 98 right because 98 cannot have transaction tests so 98 when we implemented 98 we had to change I think all blockchain tests because all of them include some transaction

receipts h okay so it looks like okay yeah vitalic commented on the 669 um and a lot of people commented on it so we'll need to read through that um because there's some there's some back and forth about it uh Nick also was in on that conversation this is a long thread okay well look at this a little bit more but this isn't something that has to be done like today it can be figured out by the next cordev meeting um but yeah I think that we came to

consensus last cordev meeting that we are doing the issuance reduction um unless something major comes up and I do see a few people from the community who are against it so we might look at it at least one more time uh let's see oh one more thing uh Alex Miller said is there been any discussion about um implementing an issuance Decay curve in a series of eras um my instinct is no because we'll probably be switching over to hybrid proof of Stak before the second era hits anyway okay

cool all right and then the last thing put I changes in 669 that's already been defined and I didn't see anybody who had a problem with that um that would be actually that's just in that's actually in 669 it's called 649 but the URL is for 669 so yeah we'll figure that out okay the number is 649 because it was originally open as an issue um but the polar request number is 669 okay got it cool cool all right I think that was the last to-do that I saw from the last time uh now hold on can I just ask question about the the new one that Nick

proposed we talking about uh receipts uh I thought you guys said a few minutes ago that we replac it with the one or zero uh that's so that's specifically the intermediate State Route field of the receipt yes but I'm looking at the E right now and it says about it says either the return data and any return revert data so which he are you looking at yeah which I'm looking at one link from accepted what number 658 okay because I updated the one I submitted

to um I'm looking at the one status uh yeah I'm not wait let me look here 58 did you say no no 6 658 658 that's what I just said oh sorry I thought you just said 58 uh 658 um okay you made an update about two weeks ago um yeah so are you on the latest update Martin cuz I'm seeing where blocks block numbers than Metro Fork block number the intermediate State Route is replaced by a status code with a bite indicating zero for failure and one for success I was looking at a bit

above that in the motivation oh yeah it says both actually yeah since everyone refers to the CIP by the number 98 I went ahead and clarified on E 98 as well which one we're going with oh thank you yeah so so we going to modify 98 to incorporate my one rather already done that okay all right well shall I just close this poll request yeah well no yeah keep the poll well we'll figure it out later yeah okay yeah but keep the main page for the Eeps updated uh so we can always go there and check which ones a plan for ad option so basically on that page what we should do is remove 658 we shouldn't

close the poll request but we can note that 98 now has the things that were in 658 is that I I think I followed that okay sounds good um as a kind of more broader in general point of procedure I've been noticing that there's that because we have this mechanism where an EIP is an issue first and then becomes a poll request it has been causing some annoyances because basically the community gets used to debating ANP while it's still in the issue form and then when it Go HS to the implementation phase it becomes confusing because there's suddenly three different numbers for the same thing M personally I'm a fan of starting straight out in shoes

sorry in polar quests um the only reason i' open an issue as if I had a vague suggestion that wasn't mature enough to write an e about um I'd have to think about that more but that sounds okay so far Casey did you I I know it was either Casey or Greg months ago had some opposition of that Casey or Nick do you remember what that was maybe I don't remember the concrete detail but I like remember some opposition yes Casey remember oh go ahead the opposition would have just been the annoyance that Bellic mentioned ah okay yeah and I you know what I remember it now and I think Greg or someone predicted something like this

would happen so we might we might move to update that so that everything's a poll request that that might be easier to rip that Band-Aid off now uh does anyone else have any procedural uh suggestions as far as this goes cuz the main one is just the numbers being messed up but I didn't know if there was anything else is there a way to actually block comments on a given issue number because the annoying thing is you can close it but everyone can comment on it still so not as far as I know yeah this is for you're saying PRS or issues or both um

it yeah both doesn't matter but any like from Administration point of view like ability to to mute the the commenting or disable commenting in particular cases like to enforce actually uh moving from one one issue to to to another PR request but I'm just asking if this is this is a technical option I think admins should have this I'm not sure they do yeah we we looked at it before and we didn't but I mean this was six months ago maybe even oh hang on no on the right hand side bar there is a lock conversation option ah

cool all right we can do it yep that sounds like a good idea for us to do um and yeah I'm we have to like figure out how actually to use it but at least there's an option yeah okay well we'll go through a training of some kind and um actually on that note eventually we need to clean up all of the EIP editors um there's like a bunch of editors right now let me actually go to all but there's let's see oh actually oh wait Nick are you are you no longer an editor I should Beed oh wait

on the wrong repository never mind that's yeah no so right now we have Martin Beezy valal Jeff Gavin Fabian me Casey Nick and Greg and for the most part vitalic Martin Jeff and gav uh and Fabian to an extent haven't really been as active uh as far as editing so we probably should get some new people in there um AR is going to ask just so that we have kind of cross client coverage on this stuff uh if you could like go back to parody and ask if anyone wants to be an EIP editor we can add them to the EIP editor Channel um unless you have

someone in mind right now not right now but we'll pick someone okay it's the most exciting job ever I show you yeah it's pretty um no it's not don't listen to Nick but you know whoever you don't like at parody send them our way we'll give them something that they'll hate okay so um anyways and yeah anybody else who has a nomination um or anything just let us know um who's in here right now vitalic do you want to be an editor in here or are you um I'm fine either way yeah

and it's only like as representative of someone who goes in and like actually has the authority to close out stuff so we might just we might just keep who we have we we'll kind of talk it over later okay so oh Nick could you mute oh sorry all right great but yeah no we'll talk about it later to see if like because we might even change editor responsibilities to make it a little bit more relx so we don't have to like have a certain amount of work done per editor or something like that um and it could just be kind of more chill uh the next item oh is there any other comments yeah I do have one um is my mic on yep it is

yeah so I'm looking at 98 uh which is an issue um and that's the one linked on from the read me as well there's no actual po request for that oh I thought there was let me look what there's one but it was referenced in uh initial abstraction changes for Metropolis 86 but I don't think it's part of it anymore yeah that's true yeah I'm not really seeing anything oh actually you commented on it in June

does this have an EIP OHP have an Associated PR okay yeah that was actually directed at vitalic and that was June 14th do you know if this has a PR vitalic which one EIP 98 um I'm not sure if it does oh okay wait this is actually wait no sorry 98 no 98 corresponds to 658 okay let me put well no well yeah it does I guess um so should should we then instead of closing 658 amend it to incorporate all of 98 to make it amend

it to be 98 well we should amend 658 to be the thing that we agreed on okay okay so basically should well then would 658 be called 98 that it can be called either one but is there a preference I mean it obsoletes 98 but since that never took Force I guess it makes more sense to just number it 98 and say that this is now 98 now yeah metalic since you were on 98 what would do you have a preference um I guess 98 because that's what we've been calling it more yeah so we will call PR 658 uh EIP 98 and incorporate

EIP 98 changes into PR 658 so someone will just have to go through and make sure everything from 98 issue is in PR 658 I'll do that since it's my PLL request okay thanks Nick um I'm GNA put that commment in right now and then what we'll do is we will link 98 to 658 on the read and fix that uh Casey I think you did that last last time would you be able to just jump in and do that after this oh sure thanks so much um the reward for a job well done is more work okay so I put the comment in there

um and is there any other comments on eips I have on the same oh yep sure um so I'm not entirely familiar I'm looking at the 658 request I'm not enely familiar with the um uh with this intermediate receipt uh but my question is how related is that to the transaction receipt RPC call not at all so it it wouldn't make any sense to include the status for revert would it make any difference includ it in in in test change you still only have two values success or failure you don't accommodate

revert um well so failure implies well revert is one of the reasons you can have a failure yeah so sorry what are you suggesting whether it would make sense or any difference to have three codes so if you look at the revert PR back in the day there was a proposal that at some point call could be adjusted or a new call could be made which returns three values uh success failure or revert I see and I wonder if bringing that to the um this this receipt would make sense what do other people

think I don't as as a summary could you do that in like a one or two sentence summary I think I got lost in the middle that so should I go sure go ahe yeah so my question is would it make sense to uh have three values in that field H one meaning success another one meaning the revert up code was used and the third one meaning it was just a generic failure so what would the generic failure well anything that's not a revert op code but I think the problem is that that complicates the abstraction because now we we have basically three types

of instead of two yes and for backwards compatibility reasons we'd have to see all uh illegal jumps for example it it's yeah it's basically the same kind of error as a throw right well recent versions of Sol output reverts anyway so only older versions will will emit invalid jumps yeah but but yeah but I'm just thinking that any any any application who wants to react to these operations they still need to consider those two failure modes as one and the same because no I'm sort of assuming that if it detects a revert then that's because it's expecting that that contract

supports it and it's going to go look uh it's going to go trace it to determine what the revert data was like the exception data whereas a a failure that is due to a revert there's no point in doing that because you know there won't be any yeah but I'm still not sure I'm not convinced either way um on the one hand more data doesn't really hurt no zero is failure when is success to line up with the return status code of a call rather than with the conventional Unix return codes think of it as a bull rather than a status

code yeah does this receipt has the um the gas limit and the g the used gas in it yes used gas but it doesn't have the the starting gas on it no but you can get that from the original transaction well I guess you could use that to determine that rever was used not Oh you mean well yes that should be the only failure that uses less than all the game that's true yeah I mean I don't have a good understanding of uh of this receipt anyway uh where I'm coming from is I would like to see in the long term the ability to see that revert was used in a

call within within the VM and it would be really nice to have same level of visibility in the RPC if any of these have nothing to do with this then I have no comment on it I I would suggest that this is easy enough to add at the client level we can add an RPC call that returns that gives you return data although no we discuss it brings problem with like clients and thinking yeah I'm not sure maybe those who understand it would

like to think a bit about this and come back later on sounds good yeah Alex could you post at the bottom of the relevant eips just kind of posing this question and then yeah we can we can definitely bring it back later on I just like to raise again I mean if we if we're going to have several failure modes I would really like success to be zero and then have an infinite number of failure modes yes if it's well if it's going to be compatible with call then that's good but if it's not then we may as well go with a conventional multi return thing currently it's a bull so I think one makes sense for success but if it becomes an enum then yes zero makes sense okay any other comments on

this okay great um so at this point we were at the review time estimate for testing and release so um as far as that goes does anyone have any estimates or comments or uh wishes for when this would when testing would start and maybe yoichi who might have the best perspective on when we could start testing I don't see a reason why not now of course there are certain things um so if if you have already implemented two

hard Forks instead of one um you have to start these hard for at the same block because the test cases on the asum and there are certain undetermined gas costs so you have to set this undetermined gas cost manually maybe you have to look at the CPP implementation to figure out the gas cost formula uh tentatively used but why not now um I mean okay I remember I do remember some time ago vitalic sent us some bug reports on the tests when he tried the PM on the test Suite

about Metropolis changes so why not now yeah okay I'm incl to agree cool so we're saying that basically by so would it be good to say that by next cordev meeting anything that is outstanding here should should be cleared up so that we can then set a like date for testing we can kind of come up with a date today or a block number or whatever but by next time we can kind of confirm it based on um hold on I should we be get to the point where we have all all major clients 100%

passing tests before we start setting dat oh I I kind of thought that so far wait which clients aren't is it just pyap or is it multiple well I mean I thought like not all of the go of the tests and C++ are even up yet right like we don't even have test I see I see you're saying yeah um yeah we can still we can still kind of try to come up with an idea of it though but I I agree we should have that going um today let's at least come up with like an like an idea of what we would be aiming for though so get like if we get

the rest of the C++ test up would like so I think it would be a good idea to first set like our goals for two and four weeks from now so like one example for a goal would be two weeks from now we should have literally all tests implemented in C++ including block tests for the op codes that only that are block related so things like EAP 96 and 98 and for and extremely optimistically two weeks but realistically four weeks um have all tests passing okay um as far as resources go for that how many resources do we have right now I think it's still mainly Demitri yichi Martin and a few community

volunteers is there anyone else who's doing that right now actually I think it's mainly UI and MRI are doing oh okay yeah that's right Mark yeah so if that case yichi do you need more resources or is there something that the other teams can provide um well and I mean that in order to make weak thing so if the other teams have resources maybe they can um try to resolve existing errors visible in Hive framework and I guess that's the best

way to resolve differences resolve uncertainties so and I mean obviously client implementers themselves are far more better than I am in fixing this or determining the cause of this problems so that's the best way to help I so yes um solving existing Pro existing errors visibly in Hive okay so basically if you're a client and you have an error please go to the getter channel that I'm pasting in here uh it also has a Skype Bridge so if you'd rather be in Skype but I I mean it'd be ideal to have one person from

each client team who is basically the person who can you know talk about and work with the testing team on um errors or just fix them themselves and then report back so if we could get people to do that I think we can make the two-e goal if we do that but otherwise we're kind of relying on just like two two to four people if the some of the community volunteers even step up to do do this in two weeks yeah but actually I already have some regular contact people uh with respect to testing problems with parity I always talk to with parity and know with go I usually talk contact with

Felix and so on so it's kind of starting right great however um in many clients I still see several hundreds or even 1,000 on hive runs so um it's uh far from Clear okay um vitalic you mentioned major clients what in your opinion is a major client um because I know that there was some recent work with JavaScript and other stuff what do you think um so I would say top three are are gu parody and plus and if we can be more well the more

expansive thing to do would be to add Python and add JavaScript okay but as far as requirements like if we hit the two weeks and Python and JavaScript aren't done that's not a showstopper for you in your opinion I'd say no like I mean it is a sign that would make me that would make me uh worried enough that I'd like try to really dig into the P into the pum and see why it wasn't working but all right cool any other comments on this um Casey actually what's the full update on the JavaScript VM I think last time we all talked it was up to I think it was able to sync to like spirus dragon is that

right uh no last time it was up to Tangerine whistle aka the E150 um but as of yesterday it's passing all the spirus dragon tests so work on metrop on the Metropolis CPS um Can can start on the JavaScript on JavaScript client great based on the resources working on that right now but are you thinking that two weeks uh it would be able to be done or are you thinking more like it it shouldn't be considered as a core client at this point for the actual launch no two we not two weeks is not enough time to um Implement all Metropolis on uh in in the 3js VM okay no problem cool all right so that is

where we are there uh any other comments on any of this basically the verdict is we'll try to get all of the clients passing the test in two weeks preferably so that we can then reassess and try to set a hard date block number for the next two months because we'll need some time for testing cool all right next item uh make a decision on the hard Fork meta eips uh that was Alex and basically he's just talking about um combining so there's like a few eips that are meta eips that just include information like uh what

block number it started on and other um like what eips were included in different hard Forks like Homestead um you know spous dragon and all that stuff so Alex you can go ahead um yeah so there is the E2 233 which just explains the process um it would be nice to actually merge it it's just an informal uh well it's a type meta or is it informal anyway um that just describes that for every hard Fork there should be such a meta EIP created which lists the code names of the fork the block numbers they were activated and

all the e which were included um and now on top of that we have uh three heart Forks uh heart Fork meta APS written up 706 708 709 um and KY kept them really updated I think they should be done at this stage and it would be nice to merge them because they are likely to change since they are for past hard Forks um I think 609 is the one for Metropolis uh which is is not final yet so it there's no need to merge it uh it would be nice to get just a generic uh idea whether people like this or and if

anyone is against it if not then I would hope to merge it yep I'm totally for it the only thing would be uh I've been talking to some people about the naming convention for them so do you have a preference on the naming convention like only because if we put these in there it might be scattered in a chart if it's just called like 233 and 240 whatever or 607 608 like so maybe we could just like name it meta Homestead or meta blah blah blah and like a different chart oh they do have a title oh okay I might have not seen that so like 607 is heart Fork meta spio Dragon I see oh okay I didn't look at the latest one I

looked at the the other one sweet okay and I think the late the the last issue the last Pro request is 676 by Casey which adds them to a list on the read me got it okay and 223 is just a formal process for hard Forks so that is okay so that just defines what what steps and processes go into doing a hard Fork right um yeah I think I think what it mostly defines that there should be such an anip created

um great it it could be updated I guess that's the biggest chunk which needs to be reviewed by people so 233 is where most of the comments are needed rest of them should be ready to merge okay yeah I agree um let me go to here I'm going to paste into the chat and into the all core devs for people to comment on um but yeah otherwise yep that's good any objections all right great we'll uh start uh merging those in after a little

bit of review I think I've already reviewed one or two of them um EIP okay so the next item item three is EIP 663 uh that also is Alex and that is a unlimited Swap and dup instructions um yes so the motivation is right now uh Swap and dup are limited to the top 16 items and there's uh the only way to reach any items below is to pop items first um and this uh EP introduces a two new instru directions one for swap one for dup which take an immediate

value and can reach up to the full depth of uh 1024 items um now the reason for this is if uh have function calls uh are usually structured in an evm uh code is first the return position would be pushed and then the uh arguments H when the function finishes where likely and the return values would be but on the stack and there's no easy way to reach if there more than 16 items there it's not easy way to reach the return uh return value uh well the the return position which was like the first

parameter um and this well okay so kind of this is a problem a compiler issue which can be worked in many cases uh but I wonder if if there are in any optimizations in G or parity uh which take this 16 stack limit into account and put away the rest of the stack in a less accessible Place uh or there's any reason not to be able to access the entire stack if there is no such reason uh I think it would be useful to make this possible so I have a concern that this effectively encourage is misuse of the

stack um like it seems to me that it would be far more sensible to store local variables in memory rather than stack the whole time because that creates this dependency on the particular dep of the stack um I'm also concerned that adding a new OP code that has an immediate argument uh complicates P code whereas currently only one One op code has an immediate argument which is the push op codes um regarding the immediate it would be the entirely the same as push uh push to Works yes but currently um passing by code is almost embarrassingly simple and

the more op codes we add with immediate arguments um the more difficult that becomes and in fact this will break any existing code that passes by code um because it was not like it actually requires new passes so another concern it will also break existing contracts because currently anything is legal uh between uh so any sequence of bites is legal in code even if it's not a legal op code and uh if an OP code is changed to be a multi-b op code which it was previously not then jump this analysis will shift and so if you jump over something which

you only use as data and not as code and it contains something that will be a a multi up code later then uh the code following this noncode uh will not work anymore but it applies to push as well sure but push was known before yeah so things like break it might break existing contracts yeah like the Purity Checker from italic but does that mean we never will introduce any any up code which has an immediate way you personally I very much like the way the EV currently only has one immediate thing and and I argued

against Greg's introduction of new immediates for the CD instructions as well um I think that if we're going to change to eosm or something that would be a good time to completely restructure things but in the meantime we should try and keep the Simplicity of existing op code structure well regarding this part I do have like the alternative version where a push is required before up code um which which wouldn't introduce any media but would reduce the usefulness a tiny bit so what about the other half of my comment about using memory instead of

Stack because imagine if the evm had only had like swap one uh and dup one from the very start writing uh language which expected local Vari the stack would never have been an option how would you have architected it then and why not do it like that now sorry I was cting out um I mean there's the tradeoff between number of instructions and and code size uh you could even today write code which only uses a DP one nothing

else yes but I don't think that the overhead of storing locals in bimy instead of Stack is overly high and it's something the optimizer can easily uh pull out onto the stack if it determines that it's possible and and cheaper um and it seems like a more sensible general purpose way to do it it's also the way that traditional compilers and processes work but just a single comment to that um the the gas cost can be higher to not encourage I mean that was in there as well uh well actually what's the EIP the way it is written up it had the push required

upfront um instead of the immediate and because of that it was obviously more expensive uh than the current dup instructions but yeah I I do I do understand your concerns okay so um is there any other um

discussion on this or Alex do you have a proposal for either bringing this back to the EIP or um having more commentary yeah I think I will take it offline just wanted to get an initial reaction to it okay sounds good and yeah feel free to put it on the agenda for next week too uh let's see and then the last one is EIP 2115 um this is a bit wise shifting instruction on the evm to replace 145 that Alex brought up so go ahead yeah yeah the 145 was the original version of it there were like three versions two issues and T the latest PR um so the only one which needs to be taken care of

is 215 which is the proquest and this is ongoing for like a year and a half at this point and the idea is to introduce shifting operations uh shift left shift right and arithmetic right shift and it's only for 256 bit values and that's it um the benefit it provides um even any standard any standard contract usually uses a call data load to get the the first uh slot and the top 32 bits of that contain the function selector H and in every case in order to retrieve a

function selector the Contra test to shift right which is accomplished by division currently um and there a lot of other use cases mostly in hasing functions for shifting very useful and uh uh things like um any any bite building methods what this introduces uh is cheaper ways to shift left it's a 10-fold decrease compared to so like currently implementing it with um a division and multiplication and exponentiation it usually cost around 35 gas uh and if it take the shift instrctions natively at Tre gas that's a

10 10-fold reduction in gas cost regarding that so any any comments on I think nobody was really objecting against it anytime in the past a few of us were trying to Champion it but nothing really happened I think the spec is fairly complete yeah I see Greg's commented on it and uh let's see uh and then yeah Nick's Nick's good on it from April so this would be okay cool in the evm yeah that this seems like everyone's pretty much agreeing on it um I'd say it's good to go is there

anyone in here who kind of objects to it the people who've been following it and commenting on it seem okay I think it's a bigger mission that we haven't had it from the start so yeah I think it's a good idea um the question is is it slated for metropolis and do we have time to implement it I say earli for part two okay I I wouldn't propose it for this one well then that means we now have more than one thing for part two so hooray all right yeah so that actually one of the reasons we have part two is to kind of look at putting in a few more things um like this ones that aren't as potentially not as expansive as 98 or uh 86 or whichever one we're putting in

there but yeah I think it could even fit this one but it would just put an unnecessary stress on people implementing it I I agree I I think it's better to have it for part two um which we don't know when that's happening but I'm going to get s q1 2018 but I mean maybe sooner we'll see um let's see what is next oh I think that might be the last official item were there any other comments on that so even if if you're not getting it into this part of metropolis uh I would be happy to take any any other comments in uh flesh it out even sooner um does it need I mean do you feel like

it needs a lot of flashing out because if not then maybe we can just Market as accepted and merge it um I think it's only only two or three of us which have ever fully reviewed it and that's p and Greg probably it would need a few more eyes okay great yeah um feel free to reach out on the cordev channel for people to look at it but I mean looking at this the people who review evm related Chang everybody except for maybe Martin beey has looked at this so cool yeah we'll get some more feedback um is there any other non-agenda topics or comments or anything anyone wants to bring

up okay great um I think we're good then uh everybody have a good weekend and I will I've written some notes that I'll put put in the agenda comment and hopefully start Doling out to people uh every after every corev meeting I get busy and then like get lacks on uh on uh sending out reminders to people but I'm going to try to not do that this time all right cool uh great meeting everybody and talk to you in two weeks bye byebye bye bye [Music]

[Music] [Music] [Music] he Jesus [Music] [Music]