All Core Devs - Execution #66

Transcript

[Music] [Applause] [Music] hey everybody we're live now core devs

um can anyone just say something so I can make sure the input this working wall on the stream hey Tim can you hear me yes okay great so if there's any issues with YouTube's Lane please jump in otherwise I'm hoping this is all work in you yeah I'm keeping an eye on it oh great okay so I'll post the agenda in her chat here have a bunch of things to go over today I think the main thing we wanted to resolve is basically what eats go in Istanbul last call we got to nearly final resolution

on a lot of them so hopefully we can accomplish that today literally right before this call James Hancock updated the Istanbul reference EEP so I'll post that in the chat as well here and so so far we really only have four eats that have been properly accepted 11:08 1702 2024 2028 there's a couple that have been rejected on the last call James said have a look at that and then ping him if there's anything that seems odd here because he can't make the call today and then yeah I think the first

thing is just to go over these eeap's that we talked about last week

Tim Beiko: that we didn't get a final resolution on the first one of which was 1344 does anyone want to chime in on that

well I'm here can you guys hear me okay yeah so I'm champion 44 from

Bryant Eisenbach: what I can tell there isn't a whole lot of contention about it going in there's some talk about implementation details behind it and I'm not quite sure how much needs to be captured in the IP at this point or how much is actually just implementation details that discussed

sorry so I guess with the core certainly

Péter Szilágyi: the chain ID e IP we're talking about that one I guess this is a bad one so the previous more complicated ones were rejected and then the question is whether this can go in

yeah so it's it's the one that has opcode our code returns a chain ID there were some discussion of whether the chain ID comes from the the field that's in the transaction or if we make like a field that's inside the client and rided by a client there's there's a little trade-off there but I don't think anyone's two against ed actually going in yeah

Péter Szilágyi: looks good to me probably I would

say that it's safer to take take the chain ID that's within the chain and not the transaction because I think homestead transactions are still valid which don't have a chain ID so that might be a bit of a surprise your smart contract all of a sudden can or can have can receive different chain IDs on the same chain

yeah

Bryant Eisenbach: I definitely agree with you there and I think there was another IP about adding it to json-rpc so it even make more sense in that case do you just have a client provided number

yeah I mean seems with the obvious to me

Tim Beiko: does anyone have any objections there

1344 or do we agree it's accepted for Istanbul

Alex Beregszaszi: just to clarify it it means that the chain idea of code is entirely decoupled from the transaction and the use for accepting the transaction is outside of the head set of this scope

Bryant Eisenbach: yeah so that it all it says is that there's an opcode when you call it returns a number we don't know what the number is but it returns a number and the implementation detail is doesn't come from transaction doesn't come from somewhere inside the client sounds like it's safer and just generally I think more people aren't on

board with a client just providing a number and that number is the same one that that transactions would get rejected if they don't have that number there was a question on whether like you know you want to go deeper maybe inside the different EIP about actually rejecting transactions that don't have that number at some point so we don't run into the situation but there's there's so many ways to jump down the rabbit hole on this one I think just you know considering it a number that is provided by

not

Alex Beregszaszi: I guess the last clarification there was some discussion what would happen if there is no chain ID in the transaction then there were

different proposals that you know it what what would be the value returned but all of these issues are a non-issue if the value comes from the client and not from the transaction

Bryant Eisenbach: that is correct yes

Tim Beiko: so Alex just to be clear does this address your concerns

Alex Beregszaszi: I just wanted to to clarify it too to myself and maybe to two others on the call it sounds reasonable to me

cool

Tim Beiko: so do we have consensus that this is accepted does anyone disagree okay so

13:44 will be part of Istanbul next one on the list was the whole set of 1283 / 1706 / 2200 and I'm seeing from the get there was some issues that were brought up this week that don't seem to have been addressed I don't know if anyone can comment on that

okay weird question

Péter Szilágyi: where are you pulling these numbers from because I'm I

can't find the list that you're looking at

from the

Tim Beiko: agenda so on github and so 1283 was the one around that gas metering for s store that got removed from Constantinople then 1706 was the fix the first Ambo and then on the last call I believe why I had proposed EEP 2200 but that might still be a PR and not a proper EP yet which was basically a combination of both then we post the PR in the chat

and if no one on the call has strong opinions we can maybe move on and then you know have a another call for it later on

if if people are looking at the poll requests that just posted I think I guess one go ahead one one thing that I would ask is does anyone oppose but I mean

Péter Szilágyi: accepting some variation of this thing because from my perspective the thing that we have to decide is whether we want to implement this feature and I think if we accept if we do want to implement this feature and

probably kind developers will start hacking on it and there will be minor tweaks but to be honest probably the three EITS are more or less the same thing so technical variations aside it's it's trying to do the same thing

and

Tim Beiko: that's the consensus we had on the last call I think like feature wise it seemed like people agreed but the sort of documentation issue hadn't been worked out and I believe how well I hope I'm pronouncing your name right had highlighted an issue about it last week so I think that was the main the main remaining concern so let me

just get the link from the git er so this is a link to the issues that were that were brought up um I don't know if anyone can speak to this

Alexey Akhunov: oh yeah so sorry this is Alexa so now um I guess basically the whole thing was about into in 2002 - mm X turbot which I

think was migrated from another e then is now checking the remaining gas at the end of at the end of the opcode is checking the remaining gas and if the remaining gas is it more than just is it less or more more this is less than 2300 then it basically fails so which is basically something explicitly depending on gas left and I think there was a bit of problem with that so it might actually preclude certain optimizations that's what I understood from Farrell and so I was suggesting to make to restructure it in a different way basic is he charge man didn't make a mandatory

charge of 2300 in the beginning of the opcode so that it doesn't have a branching on the gas the remaining gas and then adjust all the other bits to refund a bit more and somebody pointed out that it's it's not equivalent because because of the refund limit because their funds are limited to the half of the of the spent gas and things like this so yeah I don't know where that conversation went I don't really have a strong preferences either way but just that was my suggestion

so

Tim Beiko: to come back to Peter's point around

do we want this feature and can people just hack on it you know that get to something given that we're supposed to hard fork the test nets on I think it was August 14 so this is like two and a half three weeks from now do we feel there's sufficient time to resolve those issues

well I think I'm missing something but okay it is working in two weeks the test nuts that's kind of news to me but does anyone so you know that we were talking about which he I piece to get expect

that anyone here things that we're going to the fork in two weeks yeah and

Tim Beiko: to be clear I took this number from the original roadmap we had first amble so I think August 14th was was date and then the next and then the upgrade was supposed to be right after Def Con I I don't have to date handy but it was something like October 16th and that was a point farther down the agenda but obviously yeah it does have an impact if we have like the amount of time we have to to implement these changes

want

Péter Szilágyi: to be honest and as long as we

don't have a find a list of the IPS I don't see the point of agreeing on on a date simply because we have absolutely no idea how much work it would take but I can promise you that this list won't be done in two weeks

that sad is it time for discretion about schedule sorry

Danno Ferrin: is it time to have a general discussion about schedule

and what we think our current schedules achievable yeah maybe that's not very high piece first and I didn't want to divert discussion okay so I guess if this EEP

Tim Beiko: was independent of the hard work schedule is this something

we agree that we want for Istanbul

Péter Szilágyi: so this it is relatively simple I mean I haven't looked into the technical details but the previous one that was cancelled in the end it's it's not a hard G I P to code so it's maybe 50 lines of code so I don't see any particular issue of excluding this just because of timing concerns and I think it's a it's a useful feature so unless there's a technical reason to do not accept it I think we should go forward with some variation of this

- we still talking about 1283

Tim Beiko: yes

so

Alex Beregszaszi: I

think 1283 is implemented in most of the clients but last call we we said that it should go together with 1706 which is the the extra check for for the course with the stipend only I don't think that's implemented anywhere but that's where Pavel brought up his other option which would introduce kind of a new semi static mode

sorry

Péter Szilágyi: can you please link to the ID because I have no idea what he is you guys are talking

man

Alex Beregszaszi: so the comment from Pavel is the last last message from

Tim on the chat okay and that says that the calling a contract with a stipend only would disallow a store in any other state modification except logs this would be another option to solve the rien fancy issue discover the 1283

my question is maybe to Peter and others on the call I do like this semi semi static mode idea but is it is it realistic to be implemented

I'm still looking for the EIB

Alex Beregszaszi: it's a comment

certainly IP

Péter Szilágyi: well this discussion that you refer to that says the IP won't 1706 discussion I have no idea what the IP 1706 is

1706 was the oh yeah

Alex Beregszaszi: I see where he confused so yeah it's the 70 1706

discussion it is 1706 is on the VIPs website but pebbles comment is just an alternative solution and you don't need to know what 17:06 does because you can just handle the idea it's

wrong

Danno Ferrin: so 1706 see I was just the part where they charge the 2300 check and filling out that store 2200 includes that entirely

you

Tim Beiko: so is it worth moving on to something else or do we want to wrap up this discussion or does everyone just need time to look at the different options

so just

Péter Szilágyi: just to react I I mean I haven't seen this semi static thing up until now or I somehow missed it but personally I don't really like the idea of introducing yet another internal state to the EVM that tracks whatever I mean from my perspective it's going we're going to shoot ourselves in the foot eventually with the more these behavioral subtleties we introduced so

if there's an alternative that can work around not having these special cases then I would go with that

one

Danno Ferrin: alternative is to hide it behind the versioning flag only allowed 1283 to be used on newly deployed code with the 1702 1702 is the version AIP that's discussion later down which of these yet peas we have are subject to versioning and which ones are going to be under all versions of DVM on that section the one that's enumerated in 1706 is to use the versioning but people felt that they wanted to have this available to previous existing deaf developers because we try to

Constantinople there's a some feeling that we should try it at least subversion

zero yeah

Péter Szilágyi: so honestly I myself I'm not a fan of version that counts because that again it's just it's just essentially we're going to have to maintain two idioms so that's a different discussion but I would really like to not have special features for different versions as much as possible

[Music] so

Danno Ferrin: this is more different accounting in different versions not as special featuring different versions

Péter Szilágyi: but if there's a way to solve it for

uniformity for everybody then why would we pick a solution that doesn't solve it for old accounts

Alexey Akhunov: my comment on the the versioning IP or whatever whatever number was I sort of remember originally the reason why it came up there was two reasons why it came up first of all was the IPO 615 which was the static jump and other and other extensions to the EVM which has now been withdrawn and so and then another reason for that was the potential introduction and she was

mentioned into the the serum 10.0 which is now also not very so very uncertain probably not gonna happen so I would say that it actually from my point of view the we sort of lost the appeal for it we lost the real initial reason why the account versioning was proposed

so

Danno Ferrin: so that's the discussion I want to have after we get it some resolution today Pisa was the number two on the discussion and I kind of agree if we don't have 615 or EVM do any versioning now or do we bring it in dad but do we want a table 1283 and discuss versioning

or do we want to get resolution on 1283 first

so oh sorry go ahead

Péter Szilágyi: I just wanted to say that if there is a version of topic III that that can solve all the issues for all the counts and doesn't require versioning and doesn't require behavioral changes to the AVM I mean adding extra subtle EVM modes then I would just go with that and problem soft self-contained the IP done

Danno Ferrin: I think it's a trail Emma I don't think we can get all three

Alexey Akhunov: well I I think it this is what the CIP - two zero

zero that's right it it's basically the combination of the the old one the 1283 plus this extra fix for the for the step and and it doesn't introduce any extra Vivian features I think that's what it is

so does it make oh sorry go ahead well then

Péter Szilágyi: that's exactly what I wanted to say is that if if this last version funny 0 0 let me to 0 0 fixes it done

that seems like the correct choice to make and it seems like a good thing to have in the next card for so unless somebody can actually say legitimate technical reason why 2200 shouldn't go in I don't see a reason why you can go in

Tim Beiko: so does anyone on this call have a technical reason so I think at the very least it makes sense to use 2200 as this sort of going forward point for discussions on this so at last week's

call I think we were so spread out across all these different oops does it make do we want to say 2200 is accepted or do we still need to flesh out those technical details before we're comfortable accepting it

you accepted but do you understand that there are some new optimizations reintroduces

Tim Beiko: does anyone oppose accepting 2200 okay

Péter Szilágyi: at this point we should just implement it and then have a discussion based on

an existing implementation whether it's meaningful or not

Tim Beiko: sounds good and just to be 100% sure I understand this is the equivalent

of accepted right yes okay make sure

Tim Beiko: next one on the list was 10:57 prague pal I'm not sure if everyone here saw but there was a blog post about the audits that came out this week basically saying that I think the audit should be done by the end of August I'll post a blog post in the chat does

anyone want to speak to

Prague pal

Danno Ferrin: oh no one else is interested is anyone else interested in a word about it

Péter Szilágyi: well I guess it's just a question I think the the hard part in Cracow is actually implementing it but as but as far as I know more or less every client already has implemented it so I guess the discussion is whether we go ahead with it or not and that probably depends on on the result of the audit

right

Danno Ferrin: and I don't think you got it's gonna come back

without remediation recommendations I do have a concern about the hash rate changing at the fork block and a potential change stalling issue and that's something that they're looking at and I think the timing that the auditors coming back I don't think we'll have enough time to fully digest or mediate it before we need to decide go no go for a test then according to the original schedule the test that should have been launched the attest that putting the easiest amel changes should been launched by the time the audit comes back so for those reasons I am not comfortable putting it in Istanbul I'd much rather see something like this um either in the next fort in April or on its own work independently if either developer

support it well

Péter Szilágyi: just to counter that I guess if the if if profile is so there are we can expect that there won't be changes made to the

profile I mean I don't think we don't know it's gonna come back from the audit yes minor suggestion what so if

Danno Ferrin: we don't know what's gonna come back from the audit should we wait until we know what comes back from the audit

Tim Beiko: and on that point the auditors lease Authority said they would come and present this audit on an all-court have skål once it's done but realistically that'll be end of August early September

Bryant Eisenbach: I also think you'd like the political contentiousness of it

having it in Istanbul would be a risk for Istanbul being adopted I think the majority of people would prefer to be its own separate Fork

and Peter sorry we kind of jumped in while you were talking you were saying something is all no so essentially what I wanted

Péter Szilágyi: to say is that from how is this really ultra separate a IP that could be pulled even at the last minute so one alternative would be to consider it

doable and and if the if the auditor says basically if the auditors come back and tell us that it's a no-go for whatever reason then it's I think it should be really easy and simple to just tear it out even at the last moment so from this perspective it's I think it's a bit of an easier EIP then than all the other ones which which mess with the IBM because this one is just this standalone separate thing that doesn't touch consensus doesn't touch anything or I mean doesn't touch execution concerns

but what is the last moment is it before the chestnut launches or is it before

Maine and launches well my question is that previously after I think after the Byzantium art for book I don't know which I know of course a temple so that's where we have issues so

Péter Szilágyi: I had the suggestion that instead of heart instead of working off the test that what we could do is create the so-called shadow fork where we when we essentially create we don't upgrade the test at rather we just create a side chain for the test that so we still propagate the same transactions we just start executing with a new rule engine this wouldn't be what I won't say that it wouldn't be public it would be public but clients

who don't buy before switch over to it rather they could have a special flag that says play around with this whatever test nut and then you have the feedback that you can see if the clients agree between each other you can you can test everything but it's it's not live yet officially so the chain this chain would be discarded anyway for could be discarded but I don't know a I don't really want to figure out a new new forking strategy at this point

and we also haven't for the test nets yet so I don't I I mean I agree with Peter that we should continue as the cortes have already said which is

accepted pending on the audit given that technically pulling it out isn't that big of a thing then I don't think we need to say hey let's stop it today when there actually isn't anything running to you and stop it from being in

Danno Ferrin: are we going to for contestant accredited jewelry who is scheduled out because if we're not going to move the schedule out it has been stated the audit will not come back before we have to commit the code to test them to correct forking strategy

well the schedule was gonna be a later part on this call so far we're just going through

the eyepiece

Danno Ferrin: okay so if it can be pulled out part of a test net

then consider it in

Tim Beiko: okay and I think we might want to reduce the after the schedule but for now does anyone have any final comments on

PayPal

Tim Beiko: okay moving on the last one was 1962 there was an update for it posted in the agenda

I'll share this on the chat

Alex Gluchowski: I can summarize what has been done since last week the discussion on the call and in forums we integrated the suppose Faust client into

gas now it compiles seamlessly so tourists have a choice whether they want to use rust with some additional compiling compilation or just use the C++ version just make it then we have wrong we started the fuzzy testing and running for six days already now with 32 core so it's like over over a half a year as a testing running with 12 million operations per hour and we indeed found four cases where the clients mismatched it was due to the last version not following the input specification precisely which was corrected no problems in the arithmetics

itself were found and finally we have implemented the Daniel library for conveniently calling the EAP which is what you just referred to you can take a look at the examples there it's just if you want stuff go to call the function we have some further questions from the community which we we need to get answers to understand what but what's decided to do so there is a concern that we should have multiple separate addresses for this precompile we would like to understand what's to take some decision on this and we can do either

version it's it's up it's very easy to adopt at the moment the library hides all the complexity of having the first byte determining the operation but if if you guys decide that it's better to have separate errors as we can easily sweetens this is the first question second question is is the current pace of fuzzy testing enough or do we need to increase add more hardware to support more than 32 parallel processes so that we can we get two years of CPI CPU time in testing um and yeah the guest metering is in progress so we have the

gues metering functions are there we just need to get the proper constants and we want to collect more data for this and then we will proceed to the state tests and implement the tests which can be run by every client consistently and there was a concern about the specification we wanted to prepare it for this call but unfortunately Alex who's in charge compiled got sick so he needs a few more days to recover then we'll all do the the second part the first part was the specification for the input formats which we already have and the second part was for the what what's actually happening the formulas which are very

straightforward arithmetics we just need to put the formulas there and put a gas meter in constants in place and then everybody can follow the instructions and implement this recompile directly from the specs it's a very straightforward process it took us just one week to implement the C++ version so I don't expect much difficulty we are still happy to assist in anybody so yeah to do to come to recap the questions we need separate addresses for operations or can we keep one with this library increasing or not if I the testing parallelism yeah that's two questions

ok so since everybody's silent

Péter Szilágyi: I myself I'm not familiar with the IP apart from ok I saw it before but that's kind of it however is there a particular reason why people were asking to have separate

pre-compose

Alex Gluchowski: I think the main reason was the usability of calling the it's more natural to call different become files for different operations although they are doing their reasons in code under the code I think this is addressed by the library because the library makes it very easy to call any elliptic curve any any operation it backs all the

parameters together with nice typing with every entity like the point or a point there having separate structure so I think this is addressed by this but if anybody disagrees we can switch to also having different addresses

Danno Ferrin: so I've been asking for the four addresses one of my big concerns is we have to read the byte stream and interpret the first byte and based on that branch on four different functions for the gas calculation if we're doing four separate not just constants but I mean straight-up different formulas for calculating the gas this sounds like something that should be split up into at least four and because there's a g2 g3 separation

of seven methods to calculate the gas so we don't have to basically run the library program to calculate the gas if we keep the gas function where there's you know the seven main branches get seven main functions the second thing this also matches the design pattern of what went on with the EC with the RPM 128 functions there's a pad I multiply and a pairing check this one this in this library adds an exponentiation step and it's also for G 1 and G 2 so I also follow what we've been doing with our other pre-compiled were there there is basically one function and not one giant sumption hiding seven different functions but for a different gas calculation formulas I

think would be a better reflection of the true complexity of what's going on here I think parameter rising the particular curves is fine but I think the operation should be should match existing pattern we have without

Alexey Akhunov: I actually now I just thought about it I also think that from the point of view of the I mean I know a lot of people read the read the bytecode and when you read the bytecode and you see the pre-compiled cost usually that basically you put the address of the caller of the of the pre-compiled onto the stack and you do another six things in a stack and I need you the call and usually you know if you know what you're calling you can

actually see from the bytecode that what you're actually pulling however if you encode the function as the first byte of the parameter then it actually ends up in memory somewhere and it might not be obvious where okay so I guess from the EVM byte code readable it will be easier to identify which pre-compile you're calling and it might not also be easier from a static analysis point of view but as I said that not many people read the bytecode sometimes I do

so but

Alex Gluchowski: okay so we can switch to this does anybody disagree with switching to two having separate addresses for the operations well then

it seems that there is a consensus so we will just change the code to this then the second question is do we need to increase the parallelism or do you guys think it will be enough to have thirty-two parallel processes for the remaining time

Danno Ferrin: until we have an implementation that's written by the patent author the the first testing is good but we won't get the real value until we have the independent permutation in the

fuzzum yeah so here I

Péter Szilágyi: would be nice if Martin could weigh in

or who adores anyone who has been fuzzing because from my perspective I can't meaningfully say anything

Alex Gluchowski: so if if everybody's sound I assume we can continue for like this for now I'm like if if somebody has a concern that this is not enough please just post it to the forum or the chat and then we can increase in my opinion 32 is fine because we're gonna run it for several month and it's gonna be over all years of CPU run time which with 12 million

operations % very per hours would be fine

Tim Beiko: thanks Alex and and again just for clarity are we saying we want this accepted for Istanbul and and to start working on independent implementations or phrase another way wanna pose having this accepted and and starting to work on client implementations

at work so

Péter Szilágyi: if you guys want to fork anything when two weeks then I can guarantee that this will make it so at this point if anyone wants to create an

alternative implantation

so

Alex Gluchowski: we already have two different implementations in different languages one was created in one week so if somebody wants to create it in different language we can assist and even help with resources so the question is whether whether anybody wants to it at all because the formulas are just direct like it's purely functional there is no state the complexity is actually much lower than lower complexity functions with state by orders of magnitudes it's people can

just use what we have with a choice of rust or C++ but if somebody wants to implement a separate version then it's perfectly doable now if if at all there is such a desire and we should simply define a criteria of whether like for this recompile which is a very long awaited to be compiled for from in two years from now maybe it may be last but like and I think since the the first one was like the end of a six is like 1/2

years right so and this is the final one we want meet any update on this until we have a like fully flexible wasn't implementation because it covers all the cases people who want to do anything with elliptic curves will be able to do it if we find a new curve people can use it and so on so if we want this at all in theorem ever we should just define criteria and say okay when this is fulfilled and we can include it if we don't define the criteria now then I mean if if the criteria is never going to be fulfilled and it will never make it into the etherium and it's gonna be a pity

because people really know this if you can define criteria now then we can see okay can we can we fulfill them by for this

hard work so there's

Danno Ferrin: a criteria that beacon chain is using for their launch and that is to independent author representations folio the compatible to be you can chain so I think that's one criteria that should be added is that there should be an implementation independently I'm willing to do that but I agree with Peter the deadline if we're gonna fork pretty schedule is where the risk is I mean that yeah keys are supposed to be finished in may not continue to be had to go through halfway through July so that's one of the issues were having with the schedule is it if we had those details aware about the

yucky was that it made it would've been easier to get that independent application done before the

floor

Alexey Akhunov: well you know I would say this so basically after this process of weeding out and I'm pretty sure that most of the IP is now gonna be dropped out and if we say that this is if we're going to stick to the schedule then it looks like for example this AIP might not make it okay that's fine but we basically going to end up with maybe like three or four very simply a piece to implement and that's fine if we want to do that so just to keep up to the schedule but that also means that if these things are

pretty simple then I would also propose that to do another upgrade maybe shortly after that one with the more substantial features because basically the Easton bow is going to be pretty much chain ID the little bit of gas reduction and what's something else that was it was a thing so there will be like three things right so but firm for me now that the the one that this precompile is actually one of the main features of the next

oh of the next function yeah

Péter Szilágyi: yeah so I kind of agree there that just for the net gas metering and 414 ID

I don't see a reason to hard fork because it's just a huge coordination and I mean I don't see the value of it but from my perspective I'm perfectly fine if we decide that we want to have I don't know profile and this one in and we're going to push the fork up until the point where these two get in I think that from my perspective that is acceptable

there's

Danno Ferrin: also intrinsic gas cost reductions and Blake to be it was missed in that list

so

Tim Beiko: there was only a single more EEP

that someone wanted to discuss which was 1884 and I think Alex you asked if Martin had thoughts on that and he's not on the call so it might make sense to just move to the scheduled discussion now because we've been kind of hinting at it across every single deep does that make sense

Danno Ferrin: let's do schedule

so

Tim Beiko: yeah like Alex I was saying right now the accepted eats we have for Istanbul are the chain ID up codes the net gas metering and then the I'll be and pre-compiled as well as

Blake to be an account versioning

and no no the there's

Alexey Akhunov: also this 2028 which is their intrinsic gas reduction

yes I forgot about that one

Péter Szilágyi: did we accept account versioning

Danno Ferrin: about a month ago yes

yeah but no discussion was that there's absolutely no point in it because nothing's going to use yeah I think I would

Alexey Akhunov: yeah I would suggest to actually retract it because I don't see the point in doing account versioning anymore

so

Péter Szilágyi: if something's going to use it then sure but if we're going to introduce account versions and we

absolutely have zero use cases for it then that seems like a dangerous path

Danno Ferrin: I agree with that that was one of the things that's on the agenda right before the schedule I think is which IP is going the new b1 free account versioning which ones don't and you're right it was brought in for 615 it was brought in for you watch them and since those have been pushed strongly out of Istanbul the authors are like giving up on it because of funding of political issues but I still think they're valuable and I particularly can want to come back but 1702 was really the name word for that and if we don't have any need for it then let's just keep everything on one more time do you think that makes sense

Casey Detrio: it has been suggested to use versioning 1702 for the particle guess cost

reductions that we'd like to do in the particle gas costs

20 bab 2045 there's bunsen like I think I think I symbol at this moment we don't like ofre IP is a pretty simple but there's but the thing is I still I would still propose that we include the conversion in testing because that would be really I mean they

will provide a stable ground because there are other use depending on that for example Citroen the IPS and also if we want to like do some other stuff like I also have some other yeah ideas that have yuppies depending on a conversion in so if we have a really stable ground for house - yeah curry works I think we could sing so wait

Alexey Akhunov: I don't think that the straight versioning sorry state ran the IP is actually dependent account versioning

they actually can't the the the snake conflict some of it were conflicting with it so which means that they are basically have to be seasick kind of made in sequence sort of way but they're not depending on account versioning

Wei Tang: yeah but I mean I wouldn't like like I would pretty opposed if we do provider the stay runs like additional account items without a conversion because in that way you will be you're like quite a match for the account

RL piece so yeah

Péter Szilágyi: I concern against against this basically

with the account versioning is that that seems like an abstraction that we want to ask so that later we can be a stuff on top of it but you don't have yet the stuff that we want to build on top of it and my concern is that you're going to shoot ourselves in the foot by deploying an account versioning that later may turn out to be not perfectly suitable for whatever use cases that's why I personally would say that account versioning should go in when we actually have a use case for it

yeah like what I'm saying is that I've seen is a good seeing if own clans can implement it so is it would be like a lot easier for

other features to appear appearance have a conversion in like like if if if we only like if if we don't include it in testing is kind of like because it's a big feature like it kind of like pushed into the future and then those features depending on reversing will be like quite hard I think way I bought another suggestion

Alexey Akhunov: on this line and then also I've put it an agenda too you know

two times in a row for the meetings but we never managed to get to it so it's called the pre-emptive refactoring but yeah so I understand what you're talking about but maybe if we get to this point we can discuss there

Tim Beiko: yeah these Pascal's we haven't gotten through a lot on the agenda so in that spirit maybe just to bring back the conversation around the roadmap I wish we wanted to discuss it seems there's like three big things that might benefit from extra time on the road map so 1962 which we just discussed Prague pal

because the audit will be due late August so realistically mid September you know everyone will have wrap their heads around the audit and then the third one I know LXi we've discussed Europe's and you've mentioned before that you know you might not be ready for the actual estate of all deadlines so I guess there's two sides to this one is how much extra time would we need if we wanted to take on these more ambitious changes and second how do we make sure that if we extend that the deadlines were not in the same position two months from now because we got sort of an whole other barrage of EPA to go through

Danno Ferrin: if we

delay we don't accept any more ease if you're not on the list to come on I don't think we should allow any more open calls for keeps that's gonna be the next time in the community open call happens my thought is we have to realistic options as to the delay one month or two delayed three months because we don't want to be trying to do the hard work over Christmas that's not an ideal situation

Alexey Akhunov: or another option is to not delay and just basically do you know do what we already have and try to do whatever we can to that to that timeline we had and then see because it's again I mean this is the another experiment to we're trying to do here and maybe we can do

the another heart for up shortly after that because we discussed in the past that we kind of want it to be I mean a lot of people wanted to make it the hard works which are more meaningful but also potentially as soon as something is ready and then the high quality and is really in demand why not put it in

also

Wei Tang: just want to say from from plant implementations for perspective I think I think I think we will be really in favor of having simple hard works done complex rhymes you just simpler to test

and harder to make some mistakes and nice things out

Tim Beiko: so one idea we discussed that Pegasus so I'm kind of stepping out of the salute ater role here is having the hard fork as scheduled then potentially having another hard fork in January which would include whatever was too big / too ambitious / too contentious for Istanbul and in parallel trying to start organizing another sort of public hard fork for April so you would have or maybe it could be later than April but basically that we'd have

Istanbul as on schedule whatever it was too big for Istanbul in another hard fork shortly after and then a bit after that to have another hard fork that's you know open for new EEP submissions which would basically happen in parallel to

this Istanbul plus hard fork does it does I mean we have a hard fork coming up after like a plan after some board that is only like two or three months after east on board so like I think guys fight a short time and I just worry that

we don't have enough time to like because some release can means some class may need like a balancing and bounds for the release and then we still need a lot of time in firm the community and to gather the miners exchangers on the same page so I just think that might be a little short yeah and we also need a lot of time for testing

Péter Szilágyi: I think the idea was that that for example we can take a list that we currently have and shut you and make it into two hard Forks essentially everything that's that's simple and that

can be finished really fast and essentially we have everything that's accepted up until now goes into that category that one can probably be implemented fast and then we can get this studies whole procedure of testing it and rolling it out etc but concurrently we can already start working on on the second part of that list and say proc pal or the crypto stuff that's so essentially we don't have to wait until this time of hard for classes to start working on under heavy PRS so that would be the I guess the advantage of this approach where we have this Istanbul is the open PR where

anyone could suggest anything and then we have this follow up PR which is just hand-picked heavy modifications where the teams can actually focus on on those two or three IPS which are really happy and it's not opened up to the public and in the meantime yes concurrently we can already start planning for the next public thing to get extra stuff in

so I guess we can do do these Forks on two threads that was the suggestion you know I started in Atlanta

interrupting and

Danno Ferrin: here's an idea let's keep the opening dates the same and just move the actual hard work out for July

Tim Beiko: oh so so you would open them the same time as you

would have opened the April one is that what you're saying

Danno Ferrin: yeah because I think we're gonna need the time to sit through all the entries

so does anyone disagree with this from a schedule perspective to break a stand all out into two parts have our agreed-upon schedule which implies we fork a test net in two weeks or three weeks time and then we have the extra well obviously need some dates for the extra Forks but the main net upgrades would happen in January and July so I'm still convinced that you cannot for this test not in two weeks time okay

Péter Szilágyi: because there are AI PS to be implemented those need to be implemented

just need to be somewhat tested because people still rely on the test nut so you can't just blow it up and after it's implemented and semi tested or it seems to be solid but then clients need to do the releases people need to upgrade to that that's not people otherwise the test that's going to fall apart and become unusable you need I would say after everything all the IDS are implemented they seem to be working okay cross client minitest that also work at that point if clients with the release I would say you still need two weeks to convince people to operate and I think shorter is not really realistic it's just going to be chaos

I just think January days he's a little

bit short because he's only like two or three months after after the October the first one October 1 so if we move that little bit further like to February I think a little better so

Danno Ferrin: I think the original idea was that we actually tried to implement this B or D a piece on the schedule date for original Istanbul October and only if we see that it's not enough time like by by a few weeks then we can work them over to this second part but we actually have a chance to also get them in October

I know so I you can't you can't split so if you

form the test that then you need to stick to that I can't for the test not with half the IPS and then do a big fork with extra deities and wait

Tim Beiko: to come back to your point you're saying January is too early even if we're just doing this extra Istanbul keeps correct

like

Wei Tang: my phone is like after is too short because we to to Hartford in a row which is too short to each other because clients will need to like make releases and we need

to inform other people

even if you figure the test nights right okay

Alex Gluchowski: can somebody summarize the bigger a piece which will go in the second part

part ow ec mole yeah what was the third potentially some of this different yeah please yes so far I think we've got the potentially one of the stay 20 apiece

and then there was if we don't have time to do the precompile that would be pre compiled and

Tim Beiko: coming back to your point Peter around the two weeks not being realistic no matter what if we push that out one month so instead of mid-august mid September and then hard work instead of mid-october mid-november does anyone feel and then also have a hard fork potentially in February which is you

know still like a 3-4 months yeah I guess I'm just trying to see if we do push out Istanbul one month because anyway like there's no way we get it out in two weeks what does a schedule look like

we'll

Alex Gluchowski: be able to include the all the big a piece like what's on the other ones except 1962

will one month after meaning yeah no so

Tim Beiko: I think what Peter was saying is that with one month we could probably

but the current timeline for Istanbul is not realistic even if it's only the simple

IPS so therefore we need to push it back anyways well my concern is not with Istanbul rather with the tester so this number for for test nuts

Tim Beiko: so you're saying you would be comfortable keeping the October date of mid-october but perhaps pushing the

test net date yeah so for example I would I think sort of thing if you want to really really push Istanbul and I would say if we pick late August ID on and the harvest beginning of September I don't know 1st

of September in a Saturday as the as the hard fork for for Istanbul for the test pass co-op stone then depending on the eyepiece if the Yankees are implementable within one or two weeks and that's realistic that weekend will release within two weeks and I let nobody upgrade within two weeks and if we if we keep this timeline and I don't think we need to push the main that Istanbul further because I mean

Tim Beiko: so September 4th is basically the middle of the week of the first week of September would it make sense to agree to that for

Istanbul test net then keep what we had was I believe October 16th as Istanbul main net and and I I don't know what the next work looks like but maybe sleep in our back pocket the idea around potentially having your January / February far work along with one later in 2020 where we accept new eeap's does that make sense

well I think

Péter Szilágyi: at this point I would say that we should either

decide so if we want so I guess this crypto VI is legitimately useful so if the ideally we want to get that in then option a is to do two hard Forks one of them fast so to say and the other one soonish enough afterwards and if we if we go down that path and we should probably already now decide that we want to do the second hard for flow to it I don't know in January and we want that EIT in so people can work on it already or if we don't want to do hard Forks then I would push the main Istanbul a bit so that there's a chance to get it into the origin Istanbul

so if this EIP is worthy to be included then I would figure it out now how to include it

Danno Ferrin: so there's a meta discussion I think as to how we want to handle our network kind of creative works going forward do we want regular predictable force or do we want to have Forks where we get that you know what we think the demand is are we gonna fix the date or are we going to fix the features the advantage of fixing the date is we can do them more regularly we can do them twice two three times a year but the downside is we have to be harsh when things get close to the end and things aren't ready we have to look at you and say great idea you're going on the next train you're not going on this train so that's kind of you know the moment of truth which

model do we want to adopt obviously I'm an advocate of the scheduled next train approach but I don't know if there's not consensus around that to commit to it

propose an idea actually AIP like several months several weeks or months ago 21:20 2123 a signal signaling based version I think in that case we

wouldn't need to have this discussion today like if we do any similarly based of Hartford we would and implementing whatever features when they are ready and then they deployed to exchangers and miners and then the heart fur can be automatically logged in whenever enough of the network have already upgraded their chant version so so in our case you will be raised of like more convenient for you we

Danno Ferrin: still have to come to consensus as to

when to fire that contract we need to have some governance ran who has the keys to update the numbers on that contract

so

Tim Beiko: because there's I guess clearly a lot of discussion to be have and that we have another call next week and that a lot of people are not on this call it might be worth punting the discussion around the schedule to the next call but perhaps just agreeing to move the test net date for Istanbul because no matter what we will have to do that so would anyone disagree with just moving the test net date to Istanbul and at to September 4th sorry and then having your follow-up

conversation around the hard fork schedule we want past that so I think I do and good people good way forward if we so the problem is that

Péter Szilágyi: if we just say that ok let's discuss it next week then we're going to be in exact same position next week just before movie costs so my in my opinion the hard work in the festival in two weeks it's not going to happen so we need to push that so what we could do is say that ok we will fork Istanbul on the on Wroxton at on the fourth of September and for this fork we surely know that we have the kind of

list of VIPs which which we should list now so that all the kind developers know that we want these in and let's try to target that fork today already so that client developers know what's happening and they can seriously consider including the whole thing and then after after this we can also say that beside these five GIS that are surely going in here's three more that you should start working on seriously and the next week we can we can discuss where Villar at

Danno Ferrin: I like it

Alex Gluchowski: sounds good

okay and just for for clarity so hard

for King at the test net on the fourth what is the list of EITS we want you know as must-haves and what are the other ones that we want this seriously start working on them

I think we should have the list be finalized nix on next call so that gives an opportunity for people who are on this call to have a their input

but

Danno Ferrin: I think we should get a preliminary list down

already I don't I don't want to say this is it without having at least a little bit of time for we've changed how we're gonna do things and give someone that was

on anticipating okay but

Péter Szilágyi: we do have I think

it was a list of five VIPs that seems that we will surely accept and they were done of two more EITS that would be really awesome to have but they either might require some extra input auditors or they might require some extra work that's what long time but I think you should have this witness that unless somebody starts yelling really really loudly that's what we're going to go

Tim Beiko: so looking at the PR you put up James and and my notes from this call that just happened right now what seems to be the list of stuff that's going in and has been accepted is 1108 1702 twenty twenty

four twenty twenty eight and then thirty thirteen forty-four was added on this call and then on this call the ones that are seem to be tentatively accepted ie start working on them and will figure out if we can put them in seem to be

twenty two hundred nineteen sixty-two Prague pal which I forget 5757

Péter Szilágyi: could we have a written list

somewhere so there's gonna be notes there's gonna be notes from this call that's why I'm trying to enumerate them to make it easy for whoever is taking the notes I'll share them and awkward absolutely yeah and I'll

we can update the forklifts the

1679 to have a list of the yeses and then the tentative yeses and the tentative yeses can be this more list of once we want both need for their work

Tim Beiko: exactly and so right now just for to wrap this up aside from 2200 1962 and 10:57 is there anything else we want on this list

Danno Ferrin: I think we should move 1702 account versioning into the next fork maybe because I think we kind of a consensus nothing in this list requires it

yeah I mean I mean MANET at this moment but I still want to propose we included in

testing the earliest possible date might still be the first Eastham were hard for because at this moment we have three plant implementations draft implementations which I just think it would be really good it doesn't affect my night but I think this is a really cool thing to have if we kind food it in you know it's time for testing we could

Alexey Akhunov: we could actually do something as I said the preemptive refractory instead so that in the future if you needed to do

this AIP it will be super simple because a lot of complexity is now actually in the refactor

Wei Tang: yeah but if you do the same thing

Danno Ferrin: but we don't have any we don't have any IDs targeting version one and not version zero is the big issue right now

like like saying

Wei Tang: we implement the conversation it doesn't really affect a man that because they don't have version one and version zero is backward compatible

so

Péter Szilágyi: I guess the reason why I'm reluctant to go down this

path is because we have this e IP that we figured that we needed in the end it turned out that we don't need it and I'm questioning the viability of it so why do we need at all in the future

I mean actually because I really like urge anyone who still thing like that who like try to keep some more comments I reveal something yucky because like I really hope that we have a stable foundation for like the current the current description of the IP Santiago

is really lecture bare minimum like absolute bare minimum you need to implement a conversion in and I just think it would be really great if we can have this so that we have a really stable foundation about whenever we need a conversion in we can have this foundation so that other ifs can build things easily on top of that

Danno Ferrin: unless there's reference tests against it testing some form of it I don't know to be able to validate or refactoring Monsta lurkin oh yeah various clients is compatible I think we are working on

some reference tests at this moment so yeah I just hope I just have all the other plans can take a look and do some review and included in

in in your Eastern board heading okay so can we

Danno Ferrin: can we table this and finish the discussion online and during the next call about where 1702 lands

Wei Tang: yeah

Tim Beiko: just because we only have five minutes left on this call is there anything that's missing from this list we have of what we'd like client implementers to prioritize for the test net upgrade

Casey Detrio: okay

where's the they want to increase the cost of s load I forget the number

that's 2,200 so that's falled in the sort of tentative let's try and get it in column but it's not fully accepted yet because it's eighteen eighty four sorry by the one I asked to discuss oh yes

Tim Beiko: for that one we kind of got in the schedule discussion instead do we want to discuss it now

Danno Ferrin: technically it's just price changes technical issues I don't think of the big ones Cohen there is a new

lock code self balance

that's me now it seldom UK more technical but if we need eighty 1238 and 7006 we don't like we need 200

Tim Beiko: just to be mindful of time let's just yeah part the discussion until after 1884 so do we want to include 1884 in either the sort

of tentative list or the yeah in either side

Alexey Akhunov: I don't think we ever got to discuss it to be honest so okay I would say yes but you know we never really had we never go to that that far

Danno Ferrin: maybe we have that be the first item on next call

yes so this is

Péter Szilágyi: I guess Martin's PID and he is not here I can't say just a couple words of it just food for thought for next week the ideas that Martin did a lot of benchmarks on essentially he was measuring how much time individual opcodes take in the gut implantation

compared to their price and then he picked out that there are a few hot codes which compared to the other ones are really cheap gas wise but they computationally more than the others rather need us try to balance it out so that one guests approximately can require the same computing resources whether that's subtraction or whether that's data retrieval and this is essentially a trivial VIP so unless there's something somebody has a reason not to do it I think we could do it but I agree that let's postpone discussing we're accepting it one marking is here

next week but the IP itself is probably

five lines of code so it's it's so yeah

Tim Beiko: let's add that as the first agenda item for next call and have people review it in the meantime because we have a final minute does anyone have anything they want to bring up that they feel hasn't been addressed it can be resolved quickly

Alex Beregszaszi: can you state the final list of accepted and then the final list of tentatively accepted

yes yeah

Péter Szilágyi: please also state the title of the EIP because the numbers

don't mean

okay got it so for the test net hard fork on September 4th the list of accepted VIPs are and I'm trying to pull out James P are here because the titles are in it 11:08 was the first one which is reduced alt b and 128 precompile gas cost 20 24 / 152 was Blake to be 20 28 is called a de gas cost reduction and 13 44 is the chain ID up code the one that was

contentious is 1702 the account versioning so we're not sure where that one fits it's currently it accepted but might move to the other side or might get dropped so we still need to have that conversation on the tentatively accepted side the eats are twenty two hundred which is the combined 1283 plus 1706 around a store which got the one that got pulled out of Constantinople 1962 this is the pre compiled we discussed on the call today let me try to get the name 1962 I can't find a name for this one they need to give

operations operations thank you ten fifteen seven which is Prague pal and so so just a and then you have 1702 were account versioning we're not sure where that ends up so we have for 1884 yeah yeah so 1884 is in our tentatively accepted column as well

Alex Beregszaszi: I have two comments probably as agenda items for the next call for this list the first one is for Blake to probably two weeks ago there was an issue raised by one of the people close to Blake to I believe where it's you cash and that hasn't been

addressed yet so I'm not sure if Blake you're gonna be finalized within the time frames so probably it is a good topic to discuss next call and the other question I have is regarding the 1960 to 1962 states that it depends on a gas cost reduction to precompile because some of the ability reasoning is that some of the operations are so cheap that call cast itself it would be bigger than the the cost of the operation and it would there would be a big drawback and the question is is it still a requirement and if it is then what happens if none of the production

pre-compile cope with actually IPS are accepted

Alex Gluchowski: it's not a requirement because it's mostly for the hire like the greatest benefit comes from the heavy operations like spare like bearings so it makes sense to do it in any case regardless of what are

the leonetti's

Alex Beregszaszi: could you update to 1962 you happy to make this clear because currently it states that it requires the reduction

and then

just to know for the community this is the last week for any IPT it on either one of those lists on the accepted or the tentatively accepted

great

Tim Beiko: we're a bit over but is there anything else anyone wants to bring up argent lee okay and i think one important thing also that a lot of people have have mentioned we want to discuss and still have never gotten to you it's just like conformance testing and and initiatives around retest that and stuff like that so it might be worth having that discussion on the on the next

callers off

Casey Detrio: sorry you clarify if this week or next week is the last opportunity to get on the tentative accepted list

next Friday expert okay and you know there's still a couple

lurking that

Casey Detrio: even if they don't make it into you know in October it'd be good to target them for January and it wasn't clear if the target for January would only come from the tentatively accepted list or a broader list

yeah I think I'm go ahead Peter no I just want Stan so that I would say that if we if we

Péter Szilágyi: go down the path of doing the double work I mean splitting out some EITS because we want them in but they are too heavy or they need a bit more work then I would say that for the set for that second Fork whatever is not on this this list won't

make it for that list because otherwise we just end up in the same situation where we have all these tiny stuff that we discussed

and the other ones agree

Tim Beiko: so basically if anything that's already been proposed for Istanbul that has not been accepted or tentatively accepted yet for next Friday is the last deadline to potentially be included but we're not looking at brand-new oops and a note about next Friday's call

so we have a weird rotation schedule but next Friday's call will be at 10:00 p.m.

UTC which is middle of the night Americas and man I think morning Europe and I forget where for Australia so it'll be 10:00 p.m. UTC on the Thursday so this means Friday morning in Europe and the night of Thursday to Friday in America no Danielle has a comment in the chat it'll be next Friday because this call was kind of one we added just because there was too much stuff to discuss last time around but we're not moving everything back one week so there is also a call next Friday one last comment we said

Alex Beregszaszi: we tentatively accepted

1962 which is the easier ethnic and that states that it supersedes 1829 which was also proposed and and has maybe a smaller feature set can we just agree that 1829 is rejected because we said the 1962 which is the superset is is tentatively accepted

anyone disagree

Danno Ferrin: if we need that formal stuff sure all the lists I've seen have always confined 1962 and 1829 considering them to be one thing so to formally say 1829 is out of the forks I

think is fine

great

Tim Beiko: okay well thank you everyone we'll see you all next Friday

Péter Szilágyi: thank you very much and then client developers start coding everything

Tim Beiko: yes basically

thanks for buying thank you have a nice weekend you [Music]

you [Music]

[Music] [Music] [Music] [Music] [Music]

[Applause] [Music]

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