All Core Devs - Execution #67

Transcript

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

[Music] [Music]

[Music] [Music] [Music]

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

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

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

[Music] [Music] you

you you you last time around

Tim Beiko: we had a decision to have a list of both tentatively accepted eeap's and property accepted eats and try to get client implementations for all of them and then depending on how far along we would get with those to potentially split the stem bowl in the

two upgrades so one that would be scheduled this fall and another one early next year so I guess we can start with updates from from any clients around just how they are doing really related to implementation

so I'll

Danno Ferrin: speak for Pantheon we have the eats implemented we don't have product we don't have the EC curve one implemented but we have as well as the specs the IPS out there in our current development branch

alright nevermind we have the eight one

three four four we have twenty twenty eight

Tomasz Stańczak: and the remaining two we are starting soon um we don't have profile it's about adding the bindings for the library us up to go before about it laughing easy arithmetic we we are waiting here for some decisions whether this will be coming in everything else seems to be rather small

you and

Tim Beiko: do we have any other client teams on the call it doesn't look like we have

anyone from

gasser parody right so we'll wait to reference pull requests for implementations for guests and we have drawn with parity having say using the rest implementation and guess using the bindings to the C library so if someone else wants to use the C library it tells an option deep right or that yes this is for for ECB compile

got it thanks really update um so that's basically point one on the agenda but first sublet 4.1 obviously it would be great to have an update from parity and guess on this as well so we should probably have this as an action before the next call to get a status update from from the both from both of them does anyone have anything else to add on this

Tim Beiko: okay um so the second second part of of this agenda item was a last call

for any eeap's that want to be considered for like the tentatively accepted section so in practice this means you know very unlikely for the October part of the fork if it's split but possibly for the January part so anything that's already been proposed in for assemble but that that hasn't been accepted yet so does anyone have opinions or suggestions here

uh hello can you hear me yes we can okay

Casey Detrio: yeah definitely there's a few of

them in there that I'm interested in we're interested on the ey em team unfortunately neither Pavel and our Alex couldn't make the call but we'd like to see particle gas costs 2045 moved into the tentatively accepted category I can elaborate on why I guess in some ways it carries the torch for six one five um there was a call a few months ago and during the six one five discussion people ask for benchmarks to show what

kind of speed improvements could be expected and so it turns out huge speed improvements are possible even without introducing subroutines and changing how it jumps work and we publish benchmarks showing big speed ups that are on the table and so from the awesome teams perspective also this this particle gas cost you know I would argue it even carries the torch for it's an alternative to introducing wasum onto the

one of the big potential benefits of azam was the speed up well it turns out that you get a fixed speed up if you just optimize maybe I'm on the client and which will be a lot easier and having much sooner than integrating Wow's them so I think its first say that radius ting gas costs as the main priority of the he wasn't came so we're definitely interested in that one

Danny Ryan: so one of the things I would like to see with that is a possible schedule of grapes we have particle gas cost what would be the proposed gas costs for all Plenty operations I think that would give us a

better scope for just how impactful it would be

Casey Detrio: yep that's a good point and that's something we want to work on so yeah obviously that a new gas schedule would you know we would not won't have enough time to propose propose that by you know for the ACE tabular part one but for the the follow-up I think there's plenty of time to propose that and I mean once you have the scud once you have the the new gas cost table then the implementation is you know is fairly

trivial with the exception of versioning you know if if it's going to be version then obviously that adds to the complexity but that's a different discussion

James Hancock: before we dive into this more can we get a list of what are the ones that are trying to get in and I can start from that

and say that like you hear me so oh go ahead Leonardo yes sir this is Leah from solidity yeah I think I've also

Leo Alt: wanted to discuss I mean he's not gonna be here

but he wanted to start a discussion on 6:63 regarding some comments about multi by up codes and backwards compatibility

Tim Beiko: yeah there was that comment and Alex left a comment also around potentially having so first comment around having like team attic hard Forks if you want and and the second comment was about Istanbul saying you might be nice to focus on on gas repricing because we already have 1108 1884 as tentatively accepted it might make sense to oh and and 2028 it might make sense to also

consider 2045 which was I believe the one just discussed 2046 and 2200 I thought they just have like this focused around around gas cost changes so weird so so there's those there's 663 which was just mentioned does anyone on the call have other ones they'd like to discuss

yeah I would add 1559 to that the gas market the fee market change I'm interested what ended up with 11 or 9 or its or similar Eve's which were about reduced cost to pre compiles I

mean for a call to bring compiled address or static call to breaking puzzles so 11 on I was on the list is

Danno Ferrin: rejected withdrawn and those this list for the rejected withdrawn was they didn't have a reference implementation two weeks ago so they were declared out of scope for Istanbul the same with the the one about the fee market change because there is no prototype all there is is still designs going on with it on that doesn't mean it's dead in general work should progress it could make the next train but I think we made the decision then that if you didn't have a reference

implementation or was it super simple that it was not specially along to be ready for an October hard work yes and I I would say that

James Hancock: that fits with

talking about the October hard work there is a conversation I think that's worth having when thinking about a January or February other hard fork specifically if we're talking about having rebalancing and repricing really come together within these two forks because we just we just released today a a like a full implementation I'm trying to remember the word implementation study of what it would take to do 1559 and up we can I can go into that woman it's time to talk about that but that is something I'd like to address on this call

Casey Detrio: back to the the question about reducing gas costs to

pre compiles there is the IP 2046 in the proposed section so that's yeah I mean that looks like an option to be moved up to tentatively accepted

what was that number again 2046 static calls me to precompose I mean it looks

Danno Ferrin: simple the question there is do the benchmark support it so for January it

should be easy if we can get you know someone run benchmarks on it

so

Tim Beiko: do we want to agree to move 2046 to tentatively accepted does anyone disagree with that

I'm

Tomasz Stańczak: just like to ask if we measured how would the combined result of the LPN implementation and the reduce static call affect the performance of the avians like the pre-compose because we'll be going down from 1200 to something like 190

yeah that's that's a good point that's why we need to get some follow-up

because it technically it's a simple it's just a gas cost changing

Rick Dudley: do we have some sort of analysis or simulator that can show us you know if you look at the contracts on chain what these gas changes would do to the existing contracts

you

James Hancock: No and for me that for those kind of guests costs or ones we're talking about

gas cost that's like the what should be the barrier for them to being moved from tentatively accepted to actually getting in I guess is the changes are small but instead of having a lot of work around limits implementations and testing there should be a lot of work about investigating the effects of the gas changes

well well

Rick Dudley: we all know you know this gas bucketing thing is an abstract problem I mean we we there's just a lot of the way the gas model works there just is naturally a lot of work that has to be done to assert that these gas changes are safe that's just the nature of gas well the theory of gas at least

so I mean I I'm at all four I'm very aggressively in favor of changing gas pricing to make it better and I and I actually understand that it'll be a continuous effort but because it is going to be a continuous effort I feel like we should have a more formal approach to making the changes

Casey Detrio: I mean there there is a pretty good benchmark system a couple of them actually the one for pricing pre compiles and both when we're done by Marcus Wendy but where it gets complicated with this 2020 46 I mean the

the benchmark scripts they'll benchmark the pre compiles themselves but not really considering calling them from other contracts but it doesn't seem like at the whole point the the IP explains that it's just reducing the cost back from you know when it was raised what when the when the cost of call was raised and the cost of call was raised because when you call another contract you know there's disk latency but when you call it pre-compile there is no disk latency so it doesn't this 20 you know in theory doesn't make 7206 charge the

same for calling a pre compile as it does to call a p contract but benchmarks of calling you know contractors calling precompile yeah I don't think that's been done yet

Tomasz Stańczak: generally think that just analyzing the existing contracts when bringing gas down maybe it's not the most important think in a way that we could this way explore any security issues like we cut in with 1283 but performance wise I think we should be much more worried about bringing the

gas much down and then someone posting the contract that would spin the EVM the same thing and if it's underpriced it can close the trouble is in the past

Rick Dudley: yeah so I mean I mean I'm just security focused generally speaking so I completely agree with what you're saying in terms of what the engineering exercise should be but the approval process should include I mean we should be able to literally analyze all the existing contracts on chain and say that this isn't going to cause any of them to become a Doss factor I I'm not trying to make extra work for people it just seems like we've already run into this problem

once and it's in something that's like very well understood to be a hard but just a hard thing to into it so I feel like since when you spend so much time again I think it's important to fix the gap you know to improve gas and so we're gonna spend a lot of time doing it so why not just you know run some tests to make that process you know formalize some tests to make that process better that so I understand what you're saying about the engineering effort

and I completely agree with that but I don't not trying to disagree with that yeah agreed

Tomasz Stańczak: I think we have amazing work from Marcus Wendy on particular opcodes analyzing the pricing current pricing

and the relation to the actual cost but we don't have the same tooling for or analyzing contracts at least not posted as a research or report showing the results and the other thing is I wonder if the precompose were ever analyzed we've always analyzed with the cost of coal as something that is soon or the precompose were analyzed as the independent thing with whatever the call cost is and the pre-compose are priced properly that's why I was asking about the EEP one 108 in combination with 2046 if that still are safe

as far as I know at least the existing EC

peering pre-compile which is 1108 is about was benchmark only one based on just the code which is executed without anything which touches the EVM at least in a parent emotion so based on

Tim Beiko: on this discussion do we want to move any of the gas costs eeap's into tentatively accepted kind of

dependent on those types of benchmarks unfortunately Martin's not on the call and and it doesn't seem like they're the champions for most of the eeap's are either or do we want to go over to specific eeap's and and and and discuss those and and then on a case-by-case basis perhaps move them in or out

Danno Ferrin: I'm kind of thinking we should leave them proposed unless we're certain we want to do it we're just waiting on a nice we're getting quite late to be moving the

chairs around before we shift on a hard fork if we're gonna do it so we should probably go over them but I'm a little skeptical

or

Casey Detrio: was there an expectation that today was that this meeting was the last one to move on to generally accepted is that no longer the case and it will be an option on later calls

yeah so

Tim Beiko: this meeting was the last one to move to tentatively accepted and I think even that it's probably probably means more the second part of Istanbul if it's broken down than the first one and so that's just why I was asking because if there's some we need we'd like to have in we probably should

discuss them today and and try to get consensus on them rather than waiting a few more weeks there to do that

James Hancock: I would support them in with the with the as conditions that you had said where the tentatively most of the ones that are intended ly executive have some kind of implementation that is tricky to test and gas ones have their own specific one and I feel that is totally fair to to put them in that category

because if they don't get it done in the next a little bit then their first route but they can at least be in attendance fully accepted and not in the out of bucket

generally I agree I would just

Tomasz Stańczak: suggest going over them one by one so we clearly state that they're going to tentatively accept it instead of just taking them as a home but I generally think that we are all right to move them to tentatively accepted

okay let's go to the list yeah let's delete it yeah and I guess just to clarify the list the ones the ones that were that were proposed were 663 for the swap in dupe then 20 45 which we kind of talked about 20 46 2200 and which was already in I believe but

there was a comment about it and then 1559 does anyone have anything else there like to propose a bring up so it's a it's a different least that I see here because I see 1559 was rejected and seven proposed oh okay yes

Tim Beiko: yes so you're working from the meta EEP I was just looking at the agenda and the comments that people have in there we can we can definitely go through the list of proposed because it's pretty small and the only one that's yeah not in that and was rejected as the 1559 which James mentioned

earlier on the call that he'd still like to discuss given their the report from today so yeah let's go through the proposed lists and and and and just include 1559 as well as probably best discussion does that make sense yes cool so just in order 663

unlimited swap in dupe I'm not going

Tomasz Stańczak: to move it to tentatively accepted

there's anyone what about the concern about multivitamin structions is there any want to speak to that on the other side

Leo Alt: yes we were talking about that yesterday I mean not inside this little

team and also with Pavel and I don't know how how I feel about accepting it or like doing it without discount versioning because as and reposted he already wrote a test that breaks that would be broken with the multi by top code I mean Pavel suggests just can the current could the current contracts to see if this would affect any but still even if you don't affect any at the moment or if you can get like confirmation that most contracts wouldn't be affected how do you feel about this being a general conceptual

problem

so where's that test that he broke it with using the theory magician's thread

Danno Ferrin: is that also broken for push once we push 20 are those safe from that as well

those are wait

Leo Alt: I think those are safe

okay oh just on the thread

Leo Alt: okay yeah I guess this can just go on the thread I just wanted to bring that to your attention

yeah

Casey Detrio: just to add to this versioning issue versioning you know this might

also be a good a good combination with 28 2014 5 the particle gas costs and the only way to it's obviously much longer discussion than we can have in any one call so and the only way to continue the discussion and leave them as options for you know for Istanbul part two is by moving them to generally tentatively accepted so I'm definitely in favor of moving these two tentatively accepted so that we can

continue the discussion

Tim Beiko: great so does that anyone opposed moving it to tentatively accepted okay so let's do that next one on the list was 1350 to specify the address range for pre-compiled slash system

contracts

Danno Ferrin: this is one where we're not sure if there's any EVM impacts on it hasn't been much discussion on the positions thread about

it

I

Tim Beiko: I don't recall much discussion on the core dev Scala ballot either at the very least kind of in the in the past handful of of calls does anyone feel strongly that this should be in for Istanbul and if not should we just reject it from Istanbul and and leave it as a consideration for another upgrade if anyone comes on a future call and and and advocates for it

Danno Ferrin: I think we can get the value out of this without having to

put it as part of a hard for just get a practice that certain ranges are reserved I think this is an out of hard four key IP and also going to get people advocating that too so let's look at unless there's objection

Casey Detrio: the same for 18:03 as well

Tim Beiko: okay does anyone disagree with moving 13:52 and eight 18:03 out of Istanbul

that's fine great so let's do that thirteen thirteen

fifty two 1803 moved out so that leaves each thirteen eighty in the middle so reduce gas costs for call to self

Danno Ferrin: I think that falls on the same category that Rick has mentioned about needing to have some more analysis on the gas impact so that could go to tension on that conditioned on good

announces

Tomasz Stańczak: yeah I would agree let's move it to tentatively but let's have the results of benchmarks for all the VIPs that are affecting gas cost

Tim Beiko: sounds good does anyone oh sorry does

anyone disagree okay and then just to be sort of I guess numerically consistent the next one would be 1559 although it's not exactly in the list and and I know James you wanted to give an update on that

James Hancock: yeah it's okay to give that that one last

okay

Tim Beiko: sure so then the next one would be if 1985 same limits for certain EVM parameters does anyone feel strongly this should be pushed into positively

accepted otherwise I think the default should probably be its dropped from from Istanbul

I mean ah my second day marty swenders mentioned risks with this one from the last call or like to close ago but I would like to see some work on it because it's long outstanding so I would like to see it in tentatively accepted and some further discussion discussion on it but I'm not strongly favoring it

Danno Ferrin: so that's about to not kill it

yeah yeah but a week a week vowed to not kill it

yeah

Casey Detrio: I know Alex cares about this one so I voiced his support and his absence

you mean Alex 8x6 Alex yeah Eric yeah

Tomasz Stańczak: let's move it to tentatively accepted then

yeah and just for the for the record what would we like to see out of this one so what would it take for it to go from tentatively to fully accepted reference tests with the extreme numbers breakage is proud of what I want to say I want to see how the clients act we're

presented with the values outside the ranges

Tomasz Stańczak: yes this will be important and also what marketing mentioned is the question of whether we look at it only from the EVM perspective but also from outside of EVM perspective because it affects how we define what the transaction is constructed properly or not in the same for probably a few other items within the domain like probably non-block headers but this is the idea right so do we only change the way we look at gasoline it's in a VM inside or when we and deserialize and accept or are out P or not

yeah

Danno Ferrin: I think the

reference test can handle will it accepted valid RL piece of block headers and transactions so I think that's really what we need is unit tests this is reference tests I think is what we need out of it

great in 1985 okay

Tim Beiko: next one on the list is 2045 particle gas

costs which we kind of hinted out earlier yeah and I think

Danno Ferrin: this one we need the table of proposed and the same gas analysis we're asking for all the gas

was although it might be harder without an

implementation

Casey Detrio: absolutely we do have an implementation for this

so do we want to move this to tentatively and accept it as well does anyone disagree with that

Tomasz Stańczak: just didn't see much discussion only because I believe it was added quite later

look

Danno Ferrin: it was proposed at the deadline and there was a lot of stuff that got discussed before a key didn't get near it so it's because there wasn't

room to discuss and mostly I'd say let's not kill it yet

yeah I'm

Tomasz Stańczak: not opposing it I I think it's a interesting change and just would like to see more discussion in it and some benchmarks as for the others

that makes sense so 2045 as tentatively accepted as well and final one on this list was 2046 reduced gas costs for static calls made the pre compiles and so

Tim Beiko: does anyone disagree with this moving

it to tentatively accepted okay so I guess yeah just for the record it's worth stating again all these gas cost ones we're moving into tentatively accepted still would require you know a lot more benchmarking done to be to be considered to be shipped on a hard fork but hopefully having them and having your final list helps us focus the discussion and and and give the team's championing those the sort of signal that they need to work on those benchmarks and then now that we're over with this list James do you want to talk

about 1559

yes so

James Hancock: we had Matt slipper do a implementation study of 1559 and further go into specifically I we're in the goth codebase and what changes would need to be made in order to implement it and he recommended a 2/4 process as one of the updates one introducing the transaction fee change and then also so both transactions so both transaction types exist at the same time and then a transition function that will make it so over ty over a period of time the gas to the 1559 will be given more allocation and and the original

transaction type will get less allocation and then after that there'll be a second fork which will clean up the old transaction type and then we'll unlock any that's left of this million gas limit that hasn't been reached with that function so the reason why it's important to talk about with this conversation is in the process of going through 1559 we realized that we're the taking away gas is easy to do but it's the more difficult part is going to be incentivizing wallets and users to use the new transaction type

during the time when there's this transition of them both existing and the simplest solution to solve that is to provide an incentive to move to the second transaction type and specifically gas costs is the is the easiest way to do that so with the reduction of gas costs or any changes to gas costs being tied to using the new transaction type means that's where we get our incentivized leverage from so if if we go through a fork that goes that does a very heavy and on optimizing gas price and gas costs and we and we don't have this fee changes at the same time we

lose that incentive mechanism for transition

Danno Ferrin: so 1702 is clearly-defined would have rules applied to the current contract address in the version of the contract

James Hancock: this would propose a different scheme where any gas prices would not be tied to the contract version of the executing code but to the transaction originating the call no matter how far down the stack

Rick Dudley: can you repeat that question I'm not trying to entirely understood it

so

Danno Ferrin: 1702 the version is applied to the current contract message frame whatever contract message creamer in so when I was implementing it in Pantheon the gas price changes would only affect you know if we version the gas price changes it would only affect the contract version but I want to make sure if I'm hearing this correctly that this would propose not that strategy but a different strategy which is the gas cost changes don't matter about what current contract were in it's about the transaction that initiated all the calls so if the transaction came in with a new format all of the contracts would get the reduced fee they recall no matter when

they were deployed whereas if you called with the old format they would all have the old version it would matter when these contracts were deployed

Rick Dudley: yeah so I mean this is sort of I guess anticipates you know my previous comments anticipated these sorts of discussions right when we're having all these things that are messing around with the gas cost there they're gonna you know it's not clear what the interference is gonna be right so for I wasn't aware of 1702 when I proposed his sort of changes and I think it's just a matter of when 1702 gets in if 1702 gets in before 1559 then it would apply to you know the old

transaction types and the new transaction types if it's withheld to be applied with 15 to 59 then it would only apply to the new transaction type so there has to be a ranch you know there's a big branch in the code that says it's a new transaction or an old transaction

and there's

James Hancock: specification for how to do this process in the implementation study as well

did that

Rick Dudley: did that answer the question because I'm not I'm not still I'm not entirely sure

that that like

Danno Ferrin: I think it did because we haven't decided what's gonna be assigned to any track any versions it's so here's notes who's

kind of on the bubble because transactions of versions are falling out of favor son sixteen six fifteen has been withdrawn by the authors so we could just let this win and have something to figure it out when it's ready to come back in the scene

Rick Dudley: yeah I mean I think in terms of timing I I hope you know part of the reason we took our time and got this proposal written and have been talking to people who were running simulations I've talked to a number of teams that do simulations I'm continuing to talk to teams that do simulations is because this transition having to transaction types on the network at the same time as pretty

intense but I can't figure out another I mean to me it's just the parsimonious way of allowing you know we're changing how transactions work so every piece of software that interacts with the system is either reading or writing transactions so we can't we can't just get rid of them right so so the reason we're taking our time is to make sure that we actually have sufficient testing in place and obviously that testing those testing frameworks those harnesses what-have-you could be reused in these cases where we have potentially interfering the IPS Ori IPS that you know we want to test them all together right I mean we're we're gonna have to be taking Forks of death and then and then running those Forks of death in and

running in simulation and so I think that that should just be a part of the process you know once we've done that obviously you know moving forward all the IPS could use that process

I have

Tomasz Stańczak: mixed feelings here so there are a few things first of all the specification doesn't define clearly of dis split into two stages on the second thing is it was already rejected so I'm kind of unwilling to have some some kind of situation when we reject something and resurrect and it opens opens the door for others

to start resurrecting

cubes so how does it get

Rick Dudley: how would it get into insistent bull part 2 I mean is this what we're doing moving forward having a part 1 part 2 and if you get rejected from part 1 you're rejected from part 2

Danno Ferrin: I think that was when we proposed part 2 that was that the other asaji would still be going on whether it's in April or July and things that are rejected are still in asaji Oh still eligible for that I think the original idea for the 2 part was just to have the biggest ones and not have it collect everything which would have been the EC generic contracts and Prague pal coming in January because those those require a

bit more client implementation time and testing effort and the smaller ones were consisting mostly of gas cost changes we could get reference tests together much easier for proposed hard fork of the test net beginning in September so I think that's what was the original idea of it and I do sympathise if we're going to keep the trains running on time we need to set deadlines when the cabin door closes the planes on its way if you're not in you know talk to your travel agent yet and

you took it the I so

James Hancock: I respected that was in the context of the October for it so it's a lot different now that we're talking about

using all of the gas cost changes at the at the same time which that is an important part of getting the adoption of this the having the incentive mechanism work for 1559

so

Danno Ferrin: what if instead of applying a different gas schedule on each version of the transaction what if there is a multiplier that the old ones cost 1.1 as much and they cost 1.2 as much up until it cost 2 times as much or five times as much from the gas to get away multiplier because was that approach considered or or was the schedule approach found spare to that for something

I mean

Rick Dudley: we didn't really think about adding an artificial

multiplier to make gas more expensive again that seems to me to be less parsimonious I mean where here's how I'm looking at the conversation right now and apologies because I admit I'm not I'm not participating all the time but if if if collectively we agree that 1559 is important which I don't know how people feel about that then and we agree that we need to have an incentive ization mechanism to have people move to 1559 which i think is something that we can we should all be able to agree to or disagree to very quickly then then we need to provide the you know I'm not I'm

not opposed to the policy at all of saying something's postponed or what-have-you but if all the gas fee changes are used well yeah all the gap all the gas reductions are used then we have to come up with this not other method that is probably going to be more complicated so it I just it just seems no matter what we you know by by partitioning the the changes that seems to me to be the most parsimonious solution I'm totally open to doing other things that add to me more complexity and I'm open to suggestions I'm fine if it's if you know if the EIP wasn't ready

it wasn't ready I'm not I'm not upset about that either but I'm not in any particular rush frankly but but I am concerned about about how we're going to incentivize people to transition to the new transaction type that that's my concern

Danno Ferrin: I think a plug-in to different schedules based on how the transactions put in the system I think is is more difficult than the transactions executed looking up on a table and applying a multiplier to the gas cost I think that one is much less of an impact on the code then using multiple schedules and using multiple schedules I think provides unneeded complexity I mean it is one way

to incentivize it but I think the cost is higher than we expect

I'm

Tomasz Stańczak: think we should make a strong statement that we generally would like to see 1559 as the as a moving forward for the entire network but I would like to keep discussing in in separation from under Yves and say it should have its own way of incentivization and not not be delivered by other gas cause changes so I remember in April that was suggested to like split the block gas limit in half and 1/2 would be reserved just for 1559 style transactions is that

I don't mean that's still the case

that's

Rick Dudley: still the case ok so I mean then if the you know old fee market and block gas and if that's filled up there's a natural incentive for people to go to you know like the express lane that's you know with it's more open and deeper

well that's yes

Rick Dudley: but that incentive is at the user level not at the developer level right so someone has to actually write the patches to the changes oh yeah and they're not incentivized to do that if they you know if their transactions get through if

they don't push a patch and their transactions just work then they're gonna wait till the last minute you might as well just do a hard switch

right yeah

James Hancock: and that includes ui/ux changes for wallets as well so that it's not it's not like a wallet can say hey just use new transaction it's a pretty it'll be pretty significant

Tomasz Stańczak: yeah for that reason that the sooner we say that we seriously consider that change to be introduced the better for their wallet creators to adjust at the same time the amount of discussion that we having around it now would say that maybe it's too early to say from be in

Istanbul

yeah I mean that's totally

Rick Dudley: fine with me I mean I'm happy I wanted there to be a discussion around the document so I you know it's it's I mean that's what I said in in the magician's so yeah I mean I'm happy to just have a discussion regarding this document and maybe additional documents but I don't know if that'll be necessary or not so at a minimum I'm happy to have a discussion about this one

and I would and

James Hancock: I would echo that with my proposal to talk about it is also in the same spirit

Danno Ferrin: so considering how fresh the document is and how much coping questions there are

I do think it is there's too much uncertainty to get

in a January fork but

Danno Ferrin: I think it's a good idea and I think we should continue with

it

Tim Beiko: so we're gonna have to open it tentatively accepted section for the next hard fork no just kidding yeah cool so so I just and just for like carroty do we want to say 1559 stays withdrawn or rejected from Istanbul but you know we obviously want to see this

change and just point people towards the document

Danno Ferrin: yeah so maybe we should change rejected withdrawn to say missed the boat or something a little softer

sure

Tim Beiko: I think for now just did not get into EIP one discussions let's just say it's out of Istanbul

yeah

James Hancock: and the asterisk is when we're talking about gas changes we should also think about 1559 in context

yeah I

Tim Beiko: great so I think we made it through the first actually because I think we made it through the first agenda item but I just saw there was a comment about 2200 in the github agenda I don't know if anyone can speak to that but

basically a proposal to flat out reject 2200 yeah so I'm not sure if anyone has strong opinions there if not it might make sense that to pause the discussion until someone who does is is on the call

Danno Ferrin: so looking at the github there's three arguments for that it hasn't been submitted filings a draft which can be fixed really relatively easily it's based on 1706 which is not still a draft it's actually replacing 1706 so really 1706 be withdrawn but the most substantive argument is about two things relating to alternative fixes for 1283

my take on it as a remor so far down the process that we know there's there's so many ways we could fix this we got to pick one and unless the one that 2,200 proposes is objectively wrong we're living perfect be the enemy of the better maybe it is objectively wrong that's probably the discussion we need to have

them and

Tim Beiko: just because no one is jumping in to sort of counter argue that I think it might make sense to just to not remove it from the tentatively accepted list and and potentially have this

conversation on the next college because the person who posted the comment this can't make it and neither is his wife who's been championing

to seep yeah yeah

Danno Ferrin: the best one to defend it because he's got the most details on it I seem to recall that the second argument about that one of the arguments about why don't we just give a bigger refund later was withdrawn last week one of these arguments I think was withdrawn if way has better memory about it but I'm not me personally I'm not seeing anything that says that except propose a solution is not objectively false you know we're picking colors but I shed at this point but if it's objectively wrong we should

fix it so that's what we need to look for is those sorts of requests

okay

Casey Detrio: so would there still be a chance to move twenty-two hundred from tentatively accepted to accepted for mr. bule in October or

you know the customer

Tim Beiko: its tentatively accepted I feel like for what the consensus was for all of the tentatively accepted ones was if we can get the implementation then soon enough that we can hard for it to test that's

still on September fourth then it it makes sense to to have that be far as the October fork and realistically I guess that means you know if the clients have not implemented it by the next call then it's probably not making it to October because the next call is mid-august and we'll have one that'll be late August which is like a week before the fork so I feel like next week is probably sorry next call is probably the one where if there's if the clients have not all implemented implemented it and there's still implementation detail state to figure out then it would get push back to January this is just my my opinion

though so I'm sure everyone else thinks about this

I would be in favor of changing this requirement from Darice they're all clients are implementing it too just there are tests like tests available and it serum tests that can cover pretty Korea P if there are tests then we don't have to have all of the clients implementing it straight away nothing I mean if you say like in two weeks even we can have the tests and the clients follow-up so get in party will be important and if they are there and if

we have tests it's enough yeah the reason I was

Tim Beiko: I was focusing on client implementation is because the call two weeks from now will basically be two and a half weeks before the test net hard work and and from last call it seemed like pretty much the minimum time you would want between like releasing your new version and actually forking the network

and the next fork after so there's part one of this temple part two of his temples in January and an Asiago is in April

Tim Beiko: so there there wasn't like a final consensus on either of those I think way

last time had an objection with January saying maybe February would be better so say that part two would be sometime q1 and then there was discussion about whether or not the next update should be in April or a bit farther so like around

July okay would

Danno Ferrin: look at it as maybe we're pulling Asiago up two months in pulling brie up three months the way we're going at it right now

so January February

James Hancock: then April May for the next four whatever's after Istanbul

Danno Ferrin: probably July July every February July feels a

bit better than doing two three month Forks but you know maybe we'll be good at it by then I don't know I think it's too early to call Asiago I think we need to see how Istanbul the first lands

so

Casey Detrio: does that mean part two is the name is Asiago

know part two is is the big just the

Tim Beiko: in the interest of time because we could spend a full hour figuring out the name I know conformance testing was the second point

on the agenda and a lot of people wanted to discuss this and it kind of ties it to what you were mentioning

Thomas yeah

Tomasz Stańczak: my mention was more about we say that it's enough to have reference implementation why I wouldn't like to have situation when you have one reference implementation and is considered to be enough for inclusion in the artwork because the testing is much Gordon for other clients usually than just a reference implementation because testing has to be in the end based on a reference implementation so it's a bit more of a strong requirement

so

Danno Ferrin: I don't see Dimitri on the call to speak to this

but one of the things that he's been writing is a tool called retest death and what it does is it takes the reference tests and instead of expecting applying to read the jason i'm an expected client to expose json-rpc ports so in theory you can stand up right now a left and get both support it you could right to represent against Alec their gif and have the fillers figure it out from there Pantheon should be coming in about a week or two so from that you can write your reference tests for wherever your reference implementation is and I think it's on hopefully it's going to show up on parity shortly that would be great if it could and Trinity will be agreed at two but this is a tool that you know we don't have to be a let

hackers to figure out how to make the filler work we can follow the instructions that Dimitri's left online to write the reference test so I think that is something that you know as developers and authors of these noob's that we should you know for the next community hard work I personally want to apply it on the hard rule and not only do you have to have a reference implantation you need to have test cases ideally test cases in the form of reference of reference tests and for the gas changes these are like the ideal tests because there is no easy things that says trivial' the test is like great let's test it in a reference method so it's something we could throw against other clients to make sure that they have the same logic as they're writing it so I you know we definitely should I don't

know who's up for it just write some of these reference tests for these changes that we think should be going in if it's your eat you know find the docs that Dimitri wrote and spit it up against get or how that that's for your reference limitation is

yes what we

Tomasz Stańczak: what we see is that all the eaves proposers are very happy to implement as much as they can but very often they obey start because they have to wait for some of the client developers to deliver the implementation for them if we deliver a good set of tools and retest s something amazing something that we really need and then there is a bigger chance that they eat will be produced in a more holistic way the one that will allow us

to introduce something without really worrying whether it can be implemented or not

Danno Ferrin: yeah cuz Demetri earlier today on the git er said so if an ape is accepted I see the proposal is test section the question is how obligated to provide the test for the eat there will be many Eve's and only one testing team here's an example kind of test might be needed for the new opcode and you may link to something in the aleph repo so no this is something that you know we can't just throw over the fence and hope the q18 handles I think we need a B you know this is this yeah we need to we need a pitch in and do these things at all

levels

and

Casey Detrio: the direct answer is there isn't anybody if I'm just being Frank about it or not to mince words

Tim Beiko: so given that like Dimitri is not on the call

and sorry I'm here he is oh he is yeah our hand around Dimitri oh sorry did I sell retest that sufficiently for

you

Dimitry Khokhlov: yes thanks very much you know like describe it very well well it actually supports get right now and the state tests so you could run and you could generate the state tests using the get version a let's is not stable and the blockchain test generation is not supported yet so I guess for blockchain test I will have to use a left test it this is the one I used all the time and the state test could be generated

Danno Ferrin: are the blocking tests generated straight

from the state tests or doesn't need functioning inside of a left work right now

is

Dimitry Khokhlov: the difference between those group of tears that option tests could contain many blocks and many transactions and some malicious blogs and state tests is a basic form of tests with one transaction so it could easily be converted into simple block chain test with one block and one transaction and this test run by hive so see it's it's

enough to create a simple one transaction test these changes that include like you Europe could include the change and you could test it with one transaction it should be enough so majority of the test cases could be implemented by this one transaction change so it's not that's very critical that's function test unless you're supported mother but like it's going to be implemented soon

Tim Beiko: so are we agreeing and using retested to generate the the

testing for for all the tentatively accepted and accepted oops and and trying to get not only Dimitri to do that to try it involve as many people as possible in generating those tests

Alex Gluchowski: sounds like a good idea we're already doing this for ap in 1962

yeah

Rick Dudley: sounds like a good idea to me as well

Tim Beiko: great so yeah let's just make sure to communicate that clearly that EEP champions slash teams should be looking at retest at and

and and trying to generate the the reference that's further for their eats um does anyone else have anything else about testing they want to discuss

Tomasz Stańczak: one thing is that even if we assume that all the eat champions generate the test I would love to say some like central law has green light from the testing team from from Dmitriy to say that the test coverage for the given eaves is is enough like they still some overseeing process and generally we should focus now on testing since we have the least of accepted tentatively accepted ifs the

testing should be just our focus now and we should clearly state okay we transition to testing stage now the next requirement is the set of tests and this is the way we're going to implement everything

Tim Beiko: that seems pretty reasonable is there a way to ensure that there's not like a duplication of work so that the testing team doesn't do and the the eat champions don't like do the same work in parallel

Dimitry Khokhlov: I have some ideas well he

the byte code you could apparently detect the patterns which are repeated in an already implemented test well this is just an idea

you maybe it makes most sense that the EAP champions like are responsible to produce this test in order to deduplicate the work well

Casey Detrio: one thing has been the first testing team has been working on for a while is generating code coverage reports in particular

guess and parity so this would show the code coverage of both the state test suite and and they was testing corpus and where any gaps are or and so forth so it would be nice if that could be published on the kind of dashboard and I assume another priority will be to get hive tests up and running again because that seems to be don't for maintenance right now where I mean it's up but yeah the the test clearly aren't while working correctly on the hive dashboard

don't

Tomasz Stańczak: love this - here - on this call mm maybe during the next call because testing will be our focus now so obviously Demetri can give us some update now on what stage we are already but maybe they the - directly admit we are you involved in hive as well

Dimitry Khokhlov: I'm involved in the party of providing the blockchain test from the status that we have and I is probably not working right now because there was some changes the blockchain test organization I split the folders from you need to do some changes

to the script of the

hi

Casey Detrio: yeah sometimes the hype team is a hard time keeping up with

Dimitri

Tim Beiko: okay so I guess just to summarize this we're saying if champions should should should own generating the reference test for the reaps but we should also have the testing team kind of as a central point

you know looking at everything yin and green lining it and we should try to get the hive team on the next call to discuss this in more detail does that make sense

anything else on texting

Tim Beiko: okay so the next agenda item was basically looking at the test that upgrade and next steps for Istanbul I feel we've kind of done this ad hoc across the the rest of the call but does anyone have

anything they want to add on this okay and I think it might just be worth noting that it would be good on the next call to pick a block for the for the test net just because it'll be the last Oh it'll be the second to last call before we actually want to fork yeah and the last the next agenda item was reviewing the previous decisions and action items from from the last calls but I just wanted to leave this space if anyone has anything else they want to

discuss okay so the previous call basically we had a lot of a lot of a lot of each they got both accepted and accepted I won't go over the entire list because we kind of react rehashed it already and and we didn't have any outstanding action items

and

Tim Beiko: then the call before that because we didn't get to reviewing stuff on a previous call we had again a lot of eeap's accepted in terms of the decision

so no need to go back over these the actions required were reviewing 1283 1706 this seems to be happening and we touched on that earlier around around the 2,200 discussion some note about the next i'll court have calls which we're having right now 13:44 which we've accepted and then continue discussing 1962 so

we've definitely done that so next step on the agenda is just updates from either working groups testing clients or research so if anyone has anything they

want to share please do well i mean

Rick Dudley: we already covered it but just for completeness there's a document up at eath magicians i'm an existing thread i don't know where we put the links for the for these meetings but there's a link in the fourth magician and each magicians with with the proposal that that like james already said that basically covers how we would actually write the code I'm still I have sort of a first pass analysis of the impact how people feel about this proposal we

may do in a more in-depth economic impact as well for

AIP one five five nine was there an intended timeframe between phase one and phase two how long would be given

Rick Dudley: yeah I mean that I don't feel comfortable you know sort of unanimously making that decision so I think you know we just need to open it up to the community and have a conversation I'm open to just the next fork whatever that plan is I don't think we need to plan a fork just for that change I think whatever Forks go in it would be good to just sort of get into a cadence and and follow along

decades

Danno Ferrin: so something on the

order of six months

yeah that seems

Rick Dudley: fine with me I mean maybe three months instead of six but I don't you know I'm really open to

suggestion sir cool

Tim Beiko: thanks for the update Rick anyone else have anything they want to share

Alex Gluchowski: I just wanted to clarify there was a question earlier and recall that or some somebody said that they didn't start working on on some EAPs because they

were only tentatively accepted and some decisions had to be made so to clarify the tentatively accepted he keeps our like they must be implemented they are going in either in in October or in in January definitely is that correct

Tim Beiko: so my understanding especially with the ones we've added today is the clients should begin the implementation but some of them still have like outstanding issues whether this is like for the gas cost the benchmarks for prog pal there was the audit so clients should start on

the implementation but I don't think we're ready to assume it'll get included in an upgrade for sure if the sort of outstanding issues with these eeap's don't don't get resolved does that make sense

so

Alex Gluchowski: maybe we should and call them somewhat differently because some of these heaps are like we know that we need to flip them and it's just a matter of getting the like the check is done and some others are still maybe not not decided completely that doesn't make sense to take differentiate within these

two types

i with nothing for go ahead and to tively accident sorry oh go ahead I think for tentatively accepted deities

Tomasz Stańczak: we know exactly there are some actions required so for profile we need audit for 1962 we waiting for day for the review of a correctness of its right I've seen some discussions on awkward deaths for some others we wait only for benchmarks or

because repricing and I

think that Saints really this is just reactions that are needed so

Casey Detrio: my understanding is that the ones that are currently in tentatively accepted would still need to move to accepted and that would start happening either after testing activation or after main that you know the October quark the main network happens then that's when the discussion begins to remove VIPs from the tentatively accepted list up to the accepted list that's what how I would expect it to go

and

James Hancock: the big the big question there is if

it's part of the October or the January 1 and then that will be kind of decided by those things and I think it's also important to say just for people who are listening to this from the outside that saying that it's in now doesn't mean that there isn't going to be something that comes up through testing that didn't that we have to kick an EIP out due to something we don't understand yet so it isn't like a we're going to do everything where we are locked in to all of these being yet as these are the yeses and everyone should move forward that these are the ones until we find out a reason for them not to be

yeah I

Tim Beiko: I will +1 that James and one

thing I'd maybe like to propose is having the next call so the mid-august one be the last call for something to go from the tentatively accepted accepted list so where it's basically the last chance for something to be included in the october fork which anyway is just timewise it kind of is but maybe that's a way we can better sort of discriminate between the two forks is moving whatever's tentatively accepted to accept them didn't ask in the next call using that accepted list for the october fork and then continuing the discussion on the other tentatively accepted list

for the sort of q1 2020 fork

yeah yeah

Tomasz Stańczak: i think the strong message for the community these are aps and these are the actions that we are expecting from both champions and community to deliver as benchmarking testing and pointing out any vulnerabilities security wise and the clear message as well what we rejected is not coming back so people know that there is ten or eleven a piece as we see on the list that they clearly considered for istanbul and this is what we are focusing on now

you

Tim Beiko: great does anyone else have anything they want to bring up okay then for the first time in what seems like months we finished early so happy to give everybody four minutes back thanks everyone

Thanks [Music]

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

[Applause] [Music] [Music]

[Music] [Music] [Music]

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

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