All Core Devs - Execution #70

Transcript

[Music] [Music] [Music]

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

[Music] [Music]

[Music] [Music] you

hello everyone and welcome to number coordinating number 70 we're gonna get started with Istanbul updates related to clients I think we can just look at Martin's table for that there's a link both at the top of the agenda section and as a link in item number one I believe pretty much everything is done with actually yeah everything's done with death everything's done with Pantheon is everything done with Trinity Jason because it said merged Plus issue but I didn't look at the Blake to F or

like F stuff yeah it's it's working but it's too slow you can you can boss it by putting in too many rounds got it okay and next we have parody I think the Blake to one was the only one left for you all last I looked and we're just waiting for this this meeting unsafe here's any changes to this back just

price the merge wonderful yeah and I think we're gonna talk about the Blake to have stuff today who is that with me Martin yeah to signify if the clients have implemented Genesis activation support and that is kind of important for in order to do testing with like so if I if I can spin a parity in my own little private Istanbul it will be very nice so those teams have implemented Genesis activations porch they may not add it and also we talked about

activation delay switch which is nice to have yeah so I can update the table okay excellent and then there anyone here to speak on behalf of the left okay and then Thomas for another mind it looks like you're all good right except for anything we change for Blake F yes so now we waiting for date s to be available so he can confirm if everything works s in any other clients but yes we have we have like implemented we looked at the discussion around it generally we have

it and we started optimizing it as well and I think I think we already have it under decent speed will be much improved all right excellent okay so now that we've gone over kind of where everyone's at as far as the client updates I know that Jason and Thomas and Paul and a few other people in the Gator chat kind of wanted to address some of the possible like issues that we haven't like hammered out with the stainability IPS especially the fact that some of them haven't been merged in the repository itself so with that let's start with

blake - like - f I should say did we kind of come to a like we have the maximum number of rounds already in there but people are talking about reducing it just to make it it's for my understanding more like easier for gas consumption I guess am I saying that right yeah okay perfect yeah I was actually talk technical this morning I would disagree with that statement I spent quite a bit of time and trying to understand Blake - and Blake to be

specifically and the IP and I was confused and maybe others were as well because the EIP and the discussion over time used different names so initially okay sorry so initially it was called Blake to be precompiled and it turned into your Blake to F function and then it turned into your Blake to be F function and all the if all of these terms are used interchangeably in the IP but it turned out that the EIP right now only focuses on Blake to B which is a specific

configuration of lake two and Blake to be specifies the rounds to be 12 and there's that's it it's fixed Blake to be the configuration itself means that it's 12 rounds it has a specific initialization vector it has a specific set of round constants and a specific buffer size so that's what Blake to be is and the EIP right now even though specifies the F function it it uses its as f function specific to Blake to B so in the end I don't see any reason to add around argument because they to be has

it set at 12 okay Jason I know that you wrote a little bit about this do you have any comments you know no one seems to think that we're gonna need four billion rounds but there is you know maybe the desire to use fewer or more rounds and so so there's the kind of bringing down the limit as kind of wasted bytes so we could use less gas but then also this question of

you know is they're actually usefulness in having the the F function rather than that's that's flexible on rounds versus just pinning it to twelve rounds I don't have enough familiarity with the way it's gonna tie into things like like Z cash and others other than to say that the people who do have more familiarity are saying that they want this flexibility to change the number of rounds so I think that the big confusion is that if you have a fully flexible F function then you would need the number

of rounds you would need an initialization vector and you would need a bunch of other parameters which the current EIP doesn't have but if you want to only support big to B then the EIP is fine but if you change the rounds then you won't have Blake to be any more it will be a different Blake to configuration so that just doesn't seem to be any reason to keep the rounds parameter if we don't introduce the other parameters to Blake to you so maybe just a background Blake to itself is a flexible hashing framework and it has it

has a configuration part and Blake to be and Blake to s our specific configurations of the Blake to hashing framework but they're also not the only q well there is big to be Blake to s and there there are two paralyzed versions of them and there's big 2x which is a version to support variable length I put the paralyzed versions are compatible so the hash you would get from Lake to be on Blake to

BP would be identical but obviously Blake to be versus Blake 2x wouldn't be identical so if you change any of these parameters you you will get a different hash so I'm looking at the EIP and as of 17 days ago from the people who were advocating it they seemed to have reviewed it enough to say this is good to go so it sounds like what they want is just Blake to be is that not accurate have they expressed that somewhere else that I'm not seeing that they want the more flexibility way too expensive compared to Kate Shack or their function

but basically if we could use at some point Blake's 2x that would be useful for us because we don't didn't output up to 256 but we need an output r1 180 and being able to make variations in the in the hash size would be useful for us in the internal in the long run okay so that flexibility is wanted I think I want to hear what other people think but at this point oh go ahead Martin yeah just we're supporting the existing flexibility or did you say that

it doesn't matter no I don't right now the flexibility ability is wrong I'm just saying that in the ideal case that we would want to have it available but if it's going to delay the Istanbul by many months not worthy that would say right so what you're saying is basically as it is right now it is unusable and it doesn't matter to you if we remove the rawest the only thing it would matter and it would improve things for you were so we made it fully generic exactly them saying that's it and then we want Alex opinion on it for instance like s to s is just as good security widened Blake to to be would the would

the parameters be the same for s and B today no you cannot you cannot use this for Blake to s it Blake to s requires different word size and the initialization vector and grant constants I know it's then I was thinking thinking I wonder if the initialization vector what something but no that's that's different and the currency IPS hard-coded at the Blake to be initialization vectors so in that case it should I mean if if modifying it requires a long time I guess just would like to be and just change it to blake to be just things you name to specify

the number from yeah it certainly would delay things i think if we were to make it more generic go ahead Martin no I was gonna just talk about from a testing perspective so as far as I see it modifying the inputs format a bit or dropping the rounds would not be a big problem testing we basically just need to modify the existing test vectors a bit and then regenerate the tests however if we add anything such as adding yeah either making it more generic or making some other change where we introduce one more error

condition then we would need to actually invent new some new test cases from scratch right there was some previous things that Alex where you just want to add the Blake the emmalin field and stuff which minor modification doesn't really make it more yeah it's not the full generalization I would say maybe let's just drop the round set it at 12 call it Blake to be because we don't support anyway when we were looking there I was reading Alex's detailed report on this

one and we also notice that when implementing that they specification transitioned into like two F function but didn't provide any additional parameter C Allah for different support and then we couldn't work with the existing libraries we had to extract it and very strangely assumed the vectors for for like to be but at the same time leave the flexibility of the round so so indeed feel unnatural and wrong in Alex's detailed analysis just confirms it so and here as Martin says I also see that adding this flexibility unless we have some very very detailed statement from the AP proposer some exactly how this facility should look what being

would be more difficult than just dropping the rounds and assuming it's black to be mmm a lighter we can improve it into additional recompile sir just modifying the existing one probably more like adding a new one so the three uses for specifically having flexibility that I saw listed by a blake 2p the Blake 2x and and just the ability to to flexibly change things in and you know he listed this he was specifically

addressing this this question of can we get by with with just like to be function separate and you know it's worth noting I guess that you did say it would suffice for BTC relay style Z cache integration to have just like to be but these other things are you know more capabilities that we have exposed in that function which means they'll want it eventually I don't I don't know enough to do anymore really beyond relay with what he said I think that we should just take note that that might eventually be what

people want we can't guarantee that we would ever make another pre-compile to add that flexibility it's definitely something that we would need to see once I mean you know after Istanbul is done and once people request it for their use case for the purposes of the meeting today I think we've all concluded that we're just gonna keep it Blake to be am i right specifically that means fixing yes that's my understanding so my understanding of the the comments from Zucco is that the first comment where he mentioned the rounds and the different configurations I think those were assuming that this is a fully generic yeah IP I mean that

that's how I read that comment but I probably I could be wrong but the second comment he made specifically with Blake to be itself and had it would be satisfactory for as e-cash bridge great all right it sounds like we can keep it fixed then what was someone sayin for dcpip I mean if at this stage if we only keep Blake to compression function then what just you know we make it - beg to

be because right now like people are going to get access to this and things like oh this is the hash itself and it's not like it's really made if we now decide to let you be so the current IP even if we fix it for Blake to be but still it's the f compression function it still offers a certain amount of flexibility we didn't Blake to be itself because Blake to be can have a keying and can have personalization and can have salting and you could implement all of those with well a regular Blake to be hashing function probably exposes all those

features but with this compression function you can implement them outside and actually the personalization and salting is needed for for the Z cache proof-of-work and then a derp feature you can make use of is that potentially you could have a starting state of a hash for example starting state where you hash like 1 megabyte of data already and you could just hash the next hundred 28 bytes on top of that so that's like some kind of flexibility you have I'm not sure if these are useful but they are there really could be useful I do see cases where it would be useful in okay great so you were asking who

like specifically was who was I guess champion is like because all these things that yeah I agree with you I think James Hancock ran a group of people that included input from like Zuko some people from Stark we're obviously and others and it's unfortunate that we you know oh actually James you're on here I thought that you weren't on here James do you want to address this yeah as far as the stuff in the beginning when is we are thought we

did talk with Zuko we didn't have a ton of resources for implementing so the thought was it's good something in that has the hash function and then if there's any updates that need to happen those can be done as people implement we can figure out what those are sort of pre optimizing for what those are because all the stuff that it has been kind of found out has been after we have had something that someone could work with so for me it gives a good I get it's a good road map for what to do with this okay I think for the sake of time today since we've spent a bit of time on this let's just go with the reality that what we have is oblique to

bei P it needs to be reflected as that so the EIP does need to be better reflected as a blake to bei p the rounds need to be specified so that they can be properly implemented in a way that everyone can understand and make sure they're doing it correctly okay I'll go back to them listen at the beginning of the call and then go back to the keep team who's been doing development and get yes do that okay great Martin did you have a comment yeah before we leave like the big thing so Alex have some other ethics and I was wondering if that's something else we should what do

you think Alex is that something we could handle it a getter or with the keep team through James Hancock something about the yes so the tea fields are the offset counters aka the bytes already pushed into the hashing function and maybe I I would just retract that proposal because if we keep it as it is 128 bits you do have the opportunity to you maybe has something up front outside of EVM and just supplied its starting state so I'm fine with leaving

that as it is it just has to be properly explained that this is hundred 28 bits because this is Blake to be and but we agree to that and the only other change proposal I had is the de length field for the message which is a gas optimization on a VM because for the last the last block has to be zero padded and in evm so I have implemented the the group of work from the cache I mean not fully but and I have an implementation just for measuring the gas and as part of that I used to pick on time and that's where I ran into this

issue it's just awkward in the EVM and it would be much easier just to supply the length and which is also the way other pecan pies work for example the mod X AIP works in a similar fashion but I think we can discuss this outside of the call as well great and in the chat you can see that Matt Longo one of the champions of this had some comments that can be addressed in the awkward of Gator just like we talked about but James and Luiz and others from the Z cache team and Stark where great job on bringing this forward and yeah I think this has been a success of pushing an EIP through

that has a good use case actually I really think it would be good if we can get the decision today I guess the problem is we don't have the the the champions with the technical with the technical I guess ability to be able to comment on what they want for their use case is my understanding we have James in here and Louise but not the other champions who would maybe be able to comment yeah yeah sorry about that

yes always we're complaining and complaining because got it so Martin I don't know if we have the proper people in here to do that right I wanted to have this decide what to do about the emblem and then I thought we could consider it done yeah they I think the Emily is the only the only thing the rounds are decided on get her from from a James press which when he looked at it as far as the only

thing I'd be concerned about is breaking the Asmat saying is breaking the compatibility with the RFC but I think Matt can figure out which what yeah Matt Matt can speak on that he's in here hi Matt James you can just finish your statement feel free well I was gonna say as long as things aren't gonna break the RFC I don't think they'll probably will be a problem but again some of those smaller things that make sense yeah I don't I don't think we're not trying to hold back anything that's just gonna make this easier for the UVM or make the function signature that error from like a gasps we just don't wanna for example

fix the rounds and then kill any future use cases that we don't know Matt I have the RFC open right now at section 3 point 2 which is compression function f is the title and the function itself only has four parameters H which is the state M which is the message T which is the offset counter and F which is a Finance Asian flag it doesn't have the rounds as an input fair enough one sec I'm getting better department as well and going through the PR to make sure that I don't miss my own rationale

and misreport but because F is not an export function I'm less concerned about matching the F function signature and I'm more concerned about matching what F actually accomplishes I'm sure I mean you may have a sec to catch up I'm not sure what's the best way to resolve the confusions because yeah we have taken quite a bit of time yeah that's that's kind of why I was expecting this to potentially go offline because we know that they're in the get er chat and this can just be a

back-and-forth in there and easily be resolved as as not on this call yeah I don't know if you guys do parking lots in the ABC but also happy to stick around for the call and do this live either it's great but sometimes okay then can we do end of the call just stay after a little bit for the people who have been discussing this or would that not be acceptable for some people's time constraints thank you I can stay okay okay for me yep perfect okay let's go ahead and do that and move on to the next thing let's see I think

the only other two things were Jason saying you know suggesting that we might need to increase the cost of ext code copy and how to deal with contracts that break the increasing s load cost just like Aragon and others Jason do you want to comment on those or those things that would be like discussion topics for fixing and future hard Forks or something that we would need to talk about now I think we have to talk about the contracts that break now the X code copy costs being off you know you know we can talk about almost all of these things are just me relaying random

comments made and get her channels and if she said I'm watching so don't know what I summarized already which is that you know X code copy was is now cheaper than a single s load so it's sort of a start of a discussion okay yeah it seems like it could it could be important does anyone have a comment on that the fact that the repricing go ahead Martin yeah I can analogy we're fixing a hole in the roof yeah there's a smaller hole one side just because we've fixed a big one we don't you know we don't need to fix the

second one in the panic it's been there it's going to be there let's fix it in due time if we have to that's my comment about a copy there's nothing we need to fix for Istanbul in my opinion just like first of all I think our position is always that I think we shouldn't do any dramatic change for Franny or so yet he's anymore because our heart Fergus already delayed and we have expressing concerns especially to ask about why we

are delaying the heart work so so I think it might be better for e-stamp or if we just go forward with what we have known just don't change anything so I we can stay on the timeline and don't cause any delays but what I really want to argue about is is that we should really be careful about backward in cut incompatible change in the future there are two things I think because of mists the first is related to like even like the usual ways things like increasing

nice Lord and course um contracts to produce not only that those contracts might be frozen but actually for things like like some contracts like that they mate with time lock seams or stuff we also need to be really careful it doesn't cause some users funny get lost because like you can imagine like furiously before the hartford we had some contract functioning no more and user can withdraw money for a period of time but after the hartford the money's frozen and his funk an experiment is something I think we should be careful

about and second thing what I want to argue about is the procedure that any because the assume communities group growing bigger and bigger and we have more parties submitting changes to the IC IP for assume hard works the issue is that any backwards incompatible change can be used as a tack waiter because someone can try to deploy some contracts and then convince even some auditors some users who use it it works perfectly fun and then after a

year or later they propose and yeah he's saying we're doing and in Packer in Kabul or change and if our core developers got convinced by them the malicious energy might be able to cause um be strapped to the network or cause those contracts that they perversely deploy to be to be attacked or to to stay off some markings so I think this this is something we should be really careful about and we probably should be improving our procedures in the future to make sure that we don't fall in those tracks when the in rodeos by bring about change

yeah I agree with what they said way most of it I think but I'm curious a question for you so what you said about not changing anything for Istanbul was that a comment about sorry really you mentioned that it's too late to change anything at this point was that in relation to the proposed change to Blake I mean I mean we are funny if we change anything but our tradition will always be retold and Jenny's in so we don't cause any delays for for least I'm bored because some users getting angry I - yes and but your what's your

point that you prefer we leave Blake intact or what's your point not to throw in some extra so I think I think the nature like the the leg our position would be to leave the plague - I see is based on base our position but we are fine if we turn that okay so there's a little bit of flexibility there but otherwise we should err on the side of not making changes especially like major changes to a lot of these di Peas just to stay on schedule and to not have more

delays than we already do I think is how I read your commentary yeah okay thank you any other comments on what we just said it was it seemed pretty straightforward to me and I think a lot of us are on the same page I think that last time during the call wave raced very important issue of one a 94 and I while I totally agree that this change is very very important to introduce for the reasons to marking stated I think Y has experiencing some pressure after after the community started commenting on the party delay but as we see already they do miss everything and they're

catching up very quickly and it would be bad for already just step back from those statements about security concerns I think they're reasonable and I think one ah4 can bring a lot of disruption if we don't address this problem with Oregon contracts and probably hundreds of other contracts hmm other comments yeah I'm curious Thomas do you mean address right immediately or do you mean that yes yes I think I'm anything for it it for the

reason that why stated that what we can think that just breaking contracts for a while looking at it works and then fixing it in the in the next four core ended like some kind of emergency and fix would be risky because there can be some contracts that are time locked which means that some some users can lose access to their funds and then never be able to withdraw him after now after the fix counts and they can be just locked out of the period when this might be the only time when they can withdraw the funds hmm have we run into any contracts

publicly that that is a case or is this a speculation based on the fact that this is possible Thomas that was addressed to you if you have an answer yes I've seen the least that was preferred based on this the reviewed at Martin organized with some team sorry I don't remember the name of the team but the the list of contracts was very long and and I beyond the time that would have to analyze every single of them how it exactly behaves at least that's that's my feeling mmm also I don't think every single

owner of this contracts is actually tracking how the change may affect down sir it is speculation but I think it's very reasonable intuition that I'd be difficult and dangerous today I just wanted to discuss this like proposed change to one eight eight four that was suggesting this additional counter that treats the first 2,300 gas and steepened differently I think it was in line what Alexei admitted that it was in line slightly with with his idea of taking the limit counter and the gas counter that's also analyze the the required change for the calculation and for the actual claims implementation I seems to be non-invasive front and simple buff on

day like performance performance wise how it effects often memory requirements and their computation requirements of the clients so I would really like to discuss it more in detail because I think not enough people read it and analyzed the suggestion mmm I believe it solves the problem we found without risks because we taking taking use like using the fact that 9000 gases required for any value calls say so we avoiding the attack vectors or leaving the S load Inc underpriced and so we can raise the price of s float and at the same time secure or for the time being secured all the contracts

that exist and break them and to be clear this would be something that would need to be prepared for Istanbul in order to be effective yes and while I understand that this is this is what Leigh mentioned that maybe let's not change anything for Istanbul but at the same time last week we suggested that this this is a reasonable concern about Istanbul 188 for change and I agree to that and I wouldn't like anyone to just withdraw now because because I'm feeling pressure that we are delaying things I think they're backwards compatibility well sometimes sometimes it's unavoidable but in the cases where

we really see that we are like breaking the attackers contracts that you are mentioning about tendering whistle for this particular case I think we have solution we understand there exist risks they the big contract creators like I reckon I think they raised concerns that is actually very very problematic for them that the did results would be very bad and that they caused a lot of PR trouble but also like undermine the the trust union serum as a platform and our ability to deliberate changes you know you know reasonable way do we have any commentary on that I think it's very

valid concerns personally yeah so I think we I mean we're obviously kind of stuck between a rock and a hard place and in my view the the proposal is kind of convoluted and complex and not properly analyzed so I think that it's very optimistic to try to squeeze it in for Istanbul and I also believe that it if we postpone fixing it

we'll make it better job of it and we can cover perhaps more cases than only I mean things can break for other reasons than defaults the stipend and I think that yeah is the best solution if we and if we have time find the best solution I think that so Thomas thought came to mind if we make a commitment now to fix the contracts including the time-lock contracts that would you know make the ether unaccept accessible then this is a commitment that we're making before

anything breaks with the intention of fixing things that breaks which I believe is different than say what you no way was talking about before when it comes to you know having the perception that we're you know intervening in contracts necessarily if we have this intention beforehand then I think it's the similar thing to when we cleaned up the dust accounts we intervened in that case for the sake of State for states like I guess growth and that wasn't really complained about very much so I think with the right amount of PR about

this I think it would be ok yeah I definitely think if we break things we should fix it afterwards yes but I do think in all the cases where it's just oh it's hard we need to upgrade to a new contract it's a pain in the ass I don't think that needs fixing I just think they need to take that thing and go through with it because they need to change the behavior of the contract because the contracts exhibit some characteristics that we don't want to we don't want yeah the

we want them to change the behavior but there may be cases that legitimately are broken and if it's the case that some ether is trapped for whatever reason that I think yeah we should do something to fix that I just just want to give a fair warning for like this for the approach that we do a commitment and like do a commitment to fix fix everything the issue is we may and another yeah because there may be some time law contracts that just design that you did by like I mean this commitment might not

work it might be count reverse also might I mean it might be problematic but I said our position is always we hope just we don't change anything in cave why I read for a cease and don't cause any delays the I think consistent action will combat PR over time because if if we look back to how people thought about upgrade Forks a year and a half ago how everyone panicked all the time that we're gonna have to etherium suddenly every time we were doing any of these but now today no one's saying that and I

would say the reason is because consistent action has happened that I think in this case stuff like this is going to be happening more with eath 1x and a commitment that you know if something's really like upgrading to behavior that isn't intended is of course the strategy entirely but it we're know we're doing something and we know we can do something to help fix that in the cases that it goes really wrong then as this happens more and we have consistency in action and in plan and a narrative that the PR will form around it what what I was saying is that is not a PR aspect of this but actually

the technical aspect so what I was saying is it's just that we even if may make the commitment we may not be able to fix some contracts unless we do something similar to Yeti 999 which can be problematic for the community so that is just what I what I want to keep learning to the community that we just may not be able to do this commitment okay um the cat herders can write up something about this and pass it on to you before we publish it in order to make sure that we are correctly addressing both your concerns and your

warning in a way that is palatable for people to read I think Thomas I want to give you the last word on this since you do have the option to make more of a formal suggestion with it and you know within the EIP discussion or you know an ethereal magicians thing if you still feel really strongly about this but it's seeming more and more like people do want to go ahead with Istanbul despite the fact that it could break contracts with the idea that we would fix them later so I'd love to hear your last words on this you know yeah sure so do some obtain the foremost specification

of what I suggested I agree with marking that it's not fully analyzed and that's why I was inviting more people to analyze it and I'd love to see these analysis and a more detailed level it is available and it's every magicians on the EIP discussion channel on on guitar as well so I posted in in the same forum on all three channels I in the end actually obviously I trust marking where I got the whole team to actually analyze it after I raise the concern if everyone thinks that yes this is the way to go then orbitally happy to agree with that I would still like to in in any discussion for those concerns to be it

we made clear stairs people can react and discuss on them within the community and I also agree with way that they technically the solution to those contracts potentially broken contracts I agree that it's a speculation it might be it might be non-issue or might be even worse it would be if it was like just one or two contracts with something like half any for two heating them fixing them might be technically challenging and it might require a lot of resources later but in general I totally trust markings like analysis from the security and the the general idea that s felt change is super

important I agree with that as well mmm-hmm because of that change being so important we want to push I guess Istanbul as fast as we can mmm but yeah I would prioritize saying security and backwards compatibility but I understand in this case security is what requires as Thursday would it change okay very good last statements I think that's very reasonable thank you for that I think I want to quickly if anyone has a really quick thing that they need to address that is very Istanbul related otherwise I want to get to picking the block number so we could move on through the

call so is there any other comments that are necessary for Istanbul discussion before we talk about test nuts and stuff okay so we're talking today about picking the block number for the Istanbul testament which would then pick a number for the main net because it would be about a month out from the test net date I wanted to start with eg he's from the in fira team who has dealt a lot over the years with a lot of these tests net deployments main net deployments and I know he had some perspectives and things he wanted to

address here real quick so that we keep that in mind as we're doing this so eg if you want to go ahead and just give a brief kind of what you told me privately if you want yeah sure thanks Hudson yeah the main thing I wanted to bring up was that it seems like as we're coming closer to trying to set the the black numbers for the fort one of the lessons learned in the Byzantium before last year was that we shouldn't try to set both of the test metaphors in the main that Forks at the same time let's let's start with setting the test net fork and see how that goes and I'll go through that too cola finding um that period of stability before revisiting

when when to set that mean that fork so we don't end up having to push it out that's that's the main thing I wanted to highlight today do we have any comments on that I tend to agree that that is one conclusion that a lot of us came to last year in Byzantium I would +1 that especially given that we're still discussing some sort of final issues around some of these eeap's so it seems like yes we can get maybe a test that block but I'm a nerd block feels very early are there downsides to not having them both at the

same time in the client as far as exchanges and others preparing for upgradability and easing their concerns no I don't think so okay great in that case let's just do a test net block and we won't be picking a main net block I know I have the word main net and the agenda but we can leave that out since there are many clients who have merged everything and just some of the things to iron out with Blake to be when should the test net block to happen

should it be one week two weeks three weeks what are we thinking so that's that I think that is something Matt do you think that's something that is possible with working with Alex and others to do those finalization today and merge the IP yeah or James I don't I don't see any problem with us coming to an agreement today Peter not with this back channel I think you've pretty good

about most of us just want to make sure that the rounds are completely fixed but mostly other stuff discussed here it's really about do the clients like how much more fiddling but they want to do if we do change deep so yeah we're happy to play ball yeah it seems like Blake to be was the main thing left out in the end or just the thing that needs to be like finalized before we merge the heaps for sure and cross-check from the clients how they're implementing it okay so yeah did I touch your question

Martin yeah so look John release their their next update somewhere next week mid next week late next week and then how many weeks does anyone have any thoughts on that for how long that takes based on past hard Forks and my opinion I think giving because people less people use the test death in the

main net giving it a a week and a half is probably fair but that's just my first like throwing in that out there yeah I would say two weeks would be preferred this so that brings us basically a month from that which is DEFCON so do we want the hard work the testing that's right before DEFCON they've got it right after DEFCON uh we can have the test net run for more than a month if we want so it's not literally smack dab in the middle of DEFCON that's not a that's not an issue it's more when we want to start the test net because I

think that's the more pressing if we have two weeks for clients to release an update that brings you to like mid-september if you have two weeks for people to upgrade that brings you to early October so it's like the week before DEFCON yeah so just wanted to point that out September that's is that is still a margin before Deb come could do another

week and we're in fourth yeah in fact it's usually preferable to aim for midweek so doing it on the second might be the best option men by the way aiming for midweek is because we don't want to do it on a weekend in case things go terribly wrong okay so how does the second sound for everybody that brings us past Def Con for launching main net if we keep it up for a month we can still have decisions made especially if we want to do it even a little bit longer if like we can't make a decision on the main net number

because Def Con is going on or other things we still have that opportunity to just have the test net run longer and then have the main net block some time mid November that seems reasonable I think there is value to forking the test Nets before Def Con because there's a lot of conversations that do happen at Def Con so that'll be like a nice way to a nice opportunity I guess if we forked it right after DEFCON it feels like a missed opportunity there yeah great okay so anybody else have comments on this or disagreements about having it on the second there's one comment from me um is

it does it make sense to actually do a styling change on the test that's starting with rinkeby which is practically only produced by gas which means that we won't have consensus issues at least at the beginning and then very quickly following up with with the Rob stone which has to two miners practically two types of miners party and get and then continue with with Gurley which has four different coins actually creating blocks so we decrease the chances of consensus issues and they and the test introduces from the perspective of asking the test nets to do that Rob stood and Gourley we would have to talk to those teams and I

believe Peters not here today cuz he's on a flight sorry yep yep rinkeby and Gourley so that would need to be a later discussion but yeah we could do those we could definitely do those before this three week period if as long as they agree to that that would be something we'd have to talk about later or have them on the next call or things like that though but that's a good idea any other comments about it being on the second for Rob stone great we're gonna just do this on the second thing that's what

we're aiming for for the block number again for anyone listening in who doesn't understand how this works we pick a block number that we estimate to be around the second of November however that might be plus one or two days behind or forward from that date based on a lot of like some of the factors of miners and how fast blocks are produced between now and then so for anyone seeing like a headline saying it's on the second if it happens on the first or the third or whatever that's that's normal because of block block times all right yeah second of October that's important

I said November didn't I thank you all right yeah we did a we did a test net number okay I want to move on to Prague now because we have the least authority team on today and they released their audit report a few weeks ago and unfortunately due in part to just people being busy and like just slipping our mind we didn't release in coordination with them until a few weeks later so we released that report officially about midweek this week and for people to look at and I just wanted the least authority team to introduce

themselves who the people who are on the call so that we can familiarize ourself with that if they want to give a quick description of their findings that would also be nice and then we'll provide any commentary that anybody has based on the document any questions they have or concerns or ways that they can improve the document and then in addition if you're not comfortable giving feedback here there is an email address that I posted in the Gator chat and I can repost him there for everyone to send their commentary to so we'll do intros brief summary and then questions comments oh and yeah Liz if you want to take this away sure it's under here from

least authority yeah thanks for the intro Hanson so the report findings well actually yeah finished interest I think also on the call we have hind' and rom and we also have I think Mirko and Yann I think watching the call to Hindi and hinden rom are you there you want to do quick intro of yourselves sure my name is Hindi I'm a program manager at least authority and oversaw the project management along with the list of the proxy audit I do security Arctic's Fogg least Authority is qex

part of your team yes yes hi I'm kicks or young I'm also doing security audits with the authority oh yeah and we also I think Mirko who is also in the project I think he's watching along but wasn't able to actually join so yeah if he has any comments he'll just send us a message on slap or something so um yet to summarize the the findings we have a nice summary also in the the report that might be useful to just spread around to and it's this is the initial report based on the feedback that we get we've got some

clarifications that we've gotten from from you Hudson and the cat and Charles from the cat herders and any other feedback that we get we'll take that into account for the final report so yeah like Hudson said feel free to email us any kinds of feedback for this and we can incorporate it so um the summary here that we we found that generally oh yeah I guess I see on the chat that somebody wants the email address I think it's just Prague powder - audit at least Authority calm but somebody can copy in that text or I'll do it when I'm done yep I can do that definitely and yeah so so we found that it on a high level that

it reaches its design goals and that it's it's reasonable towards its intended economic effect and no major issues there but that said we also we did a lot of we did find one particular attack that we outline in the in the report we also found some I guess I should say potential attack and I think that probably some others on our team can give more details if we want to get into more details on that now and then we also we also had some just recommendations about things that could be done to have better I guess assurances of of Prague pal working as intended in the future so things to look into and to assess and one of the pieces

of feedback that we did get us to clarify a little bit more we might recommend the community does moving forward after the switch to pump oh and yeah just basically things to to just to do to help make sure it continues doing what it's supposed to be doing I guess but yeah I think other thing to add on a high level is that also there's a lot of speculation and I mean we did a lot of research to try to like narrow down the speculation of what can happen in terms of hardware and you know maybe not hardware but like how how the hell this how prong pal could be overcome by like hardware advancements in the future so I guess that's a high level I do recommend it's better it's

much better articulated in our report and I think I'll just let anybody else from released authority team jump in and add anything that I might have left out or not okay um so yeah I can I can just like um go through these suggestions from the from the document and just like say a word or two about it is that interesting to you yeah that'd be great okay cool so the first suggestion was that like power users is the modified

catch-up function like not the Ke$ha push yourself is not what if I would use like a similar to the Blake to situation where you have like parameters and oh actually is round reduced as well so it's like a slight modification and it's not really clear whether or not this is like a proper hash function however is used like well they wanted to round reduce in in the individually it's used very often and chained so probably there's not too much going on which is where we say it achieves its intended design goals basically but this is like a source of unclarity

with one question on that does that yes when you say that it's not doing it static at the end is that the part that we're on leaky chat function um that that is one part but I understand that the padding should not be necessary because it's always the same size but it's like it's it is qualification and it would be nice to have people who like analyze hash functions day by day take a look at it does the current attach do the same non patty or it has the current attached to the entire padding as far as I know it includes the petting okay

thanks okay suggestion to is address the light evaluation method this is about the situation where you have you have like the stages where you first have the C then you compute the cash then you compute the tag and in the dag you just do lookups during the mining and the cash nowadays is small enough or it's getting small enough it's kind of unclear to fit on an ASIC or like the Asics grow and or like you can put more and more SRAM on an ASIC and it's it's

either now or soon or something like this it should be feasible to put enough answer I'm on an ASIC to care to hold the entire cache and then you can with a little bit more computation effort do the mining directly from the cache but it means you don't have the memory bottleneck anymore which is where the security is basically anchored off ethers and profile collect profound heart so this is something where where it's not entirely sure like what the

right now some I'm not like a hardware expert we talked to some people in like especially Bob and it seems that it's either now possible or possible soon and we we got this information like we verified this information from other sources as well is there any questions regarding this one so quick clarification for those listening bob is bob rao he is doing a very extensive hardware audit in addition to the least authority audit that focused on both hardware and software but with a heavier lean towards software and ax just to go

over what you just said did you say that although it met the goal what I've read from that is although it met the goal with increases in hardware like efficiency over time like it might not be you might be able to get advancements through an ASIC that would be prog pal the same attack would work on you - ah got it okay never mind my second question is so you just want to see if I

understand it correctly the thing that would be needed is extremely fast memory directly um yeah some kind of very fast bus and not like the D Ram but some extremely fast thing that's gonna have faster access to the like key to this issue or so when you say so the thing is that if you have the memory on die on the same chip you don't need like GDR bus or HP m or something you just have it on your chip you don't so that's why you get like

waiver access timings access is much quicker and because you need much less much less memory you can you can put it on by now or soon probably does that answer your question so you don't have this this bus that is currently slow all over the industry I yeah it answers my question what I what is not clear to me since I'm also not the hardware expert is like it's this future technology is it now technology or expensive I mean yeah it's hard to evaluate for me yeah this is for

for me it's hard to evaluate so I've been looking over Bob's early audit his should be coming out very very soon it's just in its final stages and from my understanding it's a lot about future hardware when it comes to that type of memory and I might I mean I might be reading the audit wrong but I think it's good Bob's on it's gonna answer a lot more of those questions and speculations yeah so to also add I saw that wrong was I think Romney chatted this - I don't know if you want to say it but it's also

this this kind of memory is also more energy and efficient - oh yes so and then I yeah so I think that as far as whether or not it's a it's available like this kind of tech is available now it sounds like it might be but to get back again I think maybe yeah Bob will help with that particular answer but we did put a recommendation in for that suggestion - about changing the constant data set parents to higher value like 512 so yeah there's that

suggestion for now but yeah this is just another area to keep an eye on and and to possibly just more I guess but I don't know cakes if you have more to add sorry every question and my question is so these suggestions and recommendations did you by any chance discuss them with the proper team and no we didn't with the data set the data set parents it means that the cache computation no I'm sorry never mind no we didn't yeah and this is something that if that would be a good

thing to do um yeah if it's if we wanted to do that now is the good time to do it between the initial report in the final report because we have these recommendations there and we can you make minor edits to the report before the final one but usually just clarification nothing nothing too fundamental in terms of changing the report did we want to go back to the other suggestions there's a few more but I think that those two are probably the the most I guess in-depth ones the other ones are more overall comments I guess you could say I just wanted to be clear is this something the existing proud pal

can easily get past will it take a little bit more work or does it look like a real problem for for Prague how to get past now when you say get past what do you mean by that um to resist the attack we knew going into this that we were in an arms race with the asic builders so how does our armaments look so the the proposition is to increase the constant data set parents from 256 to 512 this constant describes like how many how much data

has to be read for a data from for an item in the dag to be computed so this would make both the lightweight verification we don't have the entire dag faster slower but also the mining and I think increasing it should be sufficient for following many years so I think it's it's easy to it's easy to find some solution I I can't really comment on how long like whether it's 10 or 20 years or 5 or 20 years a yeah I mean like whether or not this the

solution for how long it really holds but I there's leverage to to tackle this definitely yeah I mean I I think that our conclusion with this was that it wasn't it doesn't it doesn't like that it doesn't mess up prog house ability to do its design that if you change this to a higher value that it should be it should be okay also if that's the same problem again so yeah thanks thanks a lot do we have any other commentary or questions for the least authority team before they move on to maybe they're

either they're minor suggestions or wrap things up okay you can go ahead I don't think it matters but yeah so the suggestion three it was to create additional documentation there was some there are some key details that we thought were missing and that improving the documentation would also just generally improve improve how people can help keep an eye on these it pizzette

potential issues in the future and stuff like that so we called out a couple areas there could be more documentation on it another suggestion is explore a formal model of ASIC resistance and this is just something that yeah if particularly if mining continues to be a growing industry which it so far has been but if it continues on that path that just looking at this a little bit more formally would be would be helpful too so yeah just coming up with better security benchmarks for Asics and formal models can you define the how you're

using formally in this case um basically it doesn't mean it's not related to form a logic necessarily necessarily it's more like um yeah like like a sound mathematical model or something or something that you can actually reason about because currently there's like when it comes to ASIC resistance it's mostly yeah we just this is just heuristics basically and it would be nice to to have something that's actually reliable yeah okay are there any other commentary or

questions okay then if not then the last one is just monitor hardware industry advances and wow this sounds like kind of obvious in some ways we just wanted to make sure this got documented and call-outs in specific areas of hardware industry advances that we thought could be particularly a threat I guess you could say to pop pal in the future and so we outline that in a little bit more detail and also we wanted to talk about like the potential incentives of other parties and their hardware like other hardware incentives I mean other incentives for hardware to advance so

like outside of just I guess he's outside of proof-of-work mining and stuff like that so that would be something that I think is also just good for the the community and everybody to maybe have a way to keep an eye on moving forward and of course like this like specialized hardware and stuff in the future of hardware is difficult for all of us to predict but at the same time you know there's certain like I said certain signs and stuff that we're seeing in certain incentives that um that to keep an eye out for and so we just detailed this a little bit more in our last suggestion ok excellent thank you all so much

the team from least authority for coming on and fielding these questions and providing an overview of their initial audit if there isn't any other questions or comments on that you all are free to depart or if you want to stick around and adhere riveting conversation link to be that would also be ok so thanks again and yeah let's go ahead and go back to the Blake to be conversation we have about four minutes left of the meeting so if people need to drop off at the now or once the official meeting time is over that's perfectly fine otherwise we're gonna continue with Blake to be and that should be the last thing on the

is there anything that I missed on the agenda that people want to address before we start on Blake TV all right so we still have Matt in here we still have Alex in here we still have a few other people Martin so who wants to tackle this I know actually I think Matt might be best to start because you've been talking to your team yeah sure well just real quick we've been back channeling through well it's not really about you know we've been on github and whatnot discussing this throughout the call and I think where we are is we're not going to worry about the proposed change in T 0 or T 2 T 1 but Alex makes a great point this is not

really like to be specific this EIP anymore unfortunately you know the RFC doesn't quite have a target the specifies exactly what we're trying to do at the CIP so I think the discussion that we need to have here to sort of close the loop and perhaps even be talking about this Eve is do we want to revise the eat make it clear that that this is for all Blake to 64-bit variants and and then also where we're fine with limiting the rounds which has been another thing we've been discussing back and forth I just want it to be more flexible than fixing it to 10 or 12 because there's some sort of exotic

stuff our team and a few other teams that I've talked to have considered that that would limit so anyway my stance is typically I don't always know what an application developer is going to do with something I'm building and if it's not an attack on the EBM and if it's not dangerous and it's already well tested we give them when you talk about these exotic things what's the order of magnitude of number of rounds you're talking about yeah so actually for the stuff for anything that I've been looking at I would be fine with just a single bytes worth of rounds I think that

as Alex rightly pointed out the 32-bit round was was totally plucked out of air so I don't think that's the right handle I know that it is more more than 12 and I'd say less less than 10,000 but if it were limited to a single bite we'd be okay obviously that's really under any references to these experiments anywhere because I could actually find such

configurations yeah sure so they're reduced and again the only reference we've given you this public is so I think the reduced round is pretty clear for for a future hash variant but no this is all stuff that we've been discussing internally or or in person with folks Alex I'm sorry I don't have anything better written up for you I think that I think that we have some authority to lean on here that it would be reasonable to go below 10 and yeah I mean I guess I guess I guess I'd like an argument as to why we wouldn't want to

allow above 12 I think we wouldn't have had any of this discussion if from the outset it would have been titled that this is as you suggested today that this is a 64 bit flexible Blake 2 compression function because then it would have been more clear he's I mean I've been confused and that's so I guess what I'm wondering is I'm comfortable

going through and and revamping the IP to make sure that it more accurately represents I think I think what a few people are trying to do here that doesn't answer the question of what is what is a reasonable round limit so I think part of what I'm wondering about is what we want to ask implementers to do considering the Istanbul schedule I think our team would be fine dropping it to 16 or a bit three rounds and we would not have any problems and I think that I can turn around the GIP in the next two days in a way that's much more accurate and covers the fact that this handles a bit like like - very much Alex

so from an implementation perspective of what gas wise difference would be to drop the rounds versus having a one-bite for the rounds oh there there's no difference for that it's just hard coded in my case but the implication is on the implementers side because if this is clearly a Blake to be a compression function then they likely can use off-the-shelf software and libraries yeah but if this has the rounds then they cannot they have to implement it themselves duplicate some code make the changes and I think that's where people were really confused because when they

reached out to libraries well of course they realised they cannot use libraries first of all this so they reached out to them and ask for this compression function and whoever has implemented Blake - was really confused that you want the rounds but you don't specify the rest of the configuration absolutely and we had to do that for the gap implementation as well we had to rip out the go crypto a function because they didn't exported at all all right I'm Peter had to rip out began to get assembly implementation so a lot of work has gone into it already so in one sense I think this would have been made more sense to

discuss a couple of months ago at this point to think hasn't everyone already done this I have not if that counts and I mean it's not a blank check but we are here to help we have an interest in getting us there as well yeah for me it doesn't really matter but but it's important I think it's it it would be really good if we decide it's set in stone so we can so I think the only only only reason it could make

sense to set a lower bound on the rounds is to avoid any risk with with the gas usage where baby somehow you know the the one gas per round which was determined somehow with with large rounds it could not be accurate and that could be one motivation to set a lower limit I think to be clear here we performed benchmarks both on large rounds and on smaller odds like one round computation two runs computation so it all fits together terms of the gas price I think it sounds like there may be some

motivations to keep the rounds at this point maybe but decrease the size of it what do you say about that tactic I mean since it has been implemented and if there's a real reason that there gonna be other configurations of 64-bit Blake to I with different rounds and then maybe it makes sense but yes I said we wouldn't have had this discussion if this would have been cleared from the beginning and from from the users perspective the rounds doesn't really

matter it can be hard-coded this is really only a question for testing and client implementation which since that's those have already been Donna it would make sense to update the IP language because that's that doesn't do anything to the hard fork or the implementation schedule yeah I think the yeah if he has to be clarified that's that's for sure and we have when we first talked about Blake to be we had we had asked Zuko and others is Blake to be the only one or is Blake to what's important and then we went into well if that's the only thing that matters that really is the

compression that function which we can get from somewhere else and just plug that in and then rather than us to do a solidity implementation now which would be highly which would be much more resource intensive we can get the compression function done and then we can release best practices or libraries that that interface with the with the F function so I think this is a little bit of VIP hasn't follow like the the writing in the IP hasn't followed the evolution of our of the discussion that has happened with the community but is there any any practical use case

for other numbered on 12 ah yes absolutely so if you're talking about any any additional ash configurations that are put together for for example Internet of Things applications and we need to verify that then this will be for compatible if you're talking about frequent for tweaks like what we just saw with SIA not to be clear they didn't change the route but a similar idea to break basics that we need to verify this would be portable so there are definitely I mean there are definitely reasons I understand that it's more difficult to depend potential future development from app developers than it is to point to expected needs

I mean my main concern is this this is like semi flexible because you only have the rounds which is flexible and I do wish we had gotten blank to us in there I agree that if it were properly flexible well ideally it would be completely flexible and it would require a couple of more fields but probably it's too late to change that I don't see why we

couldn't in a future hardboard but yes I do think that would be quite quite a lift considering our timeline well you cannot change the P compile once it's deployed no I know I just mean obviously that's too much of a look before as simple we thought there was something worth doing in the future I think that's a question more for you guys for what is worth one comment if you want to 32 have 32 bytes demise version it probably means you need to separate precompile having kid

in one probably would be horrible in terms of developing against this pre-compile because yeah we have like two or three additional parameters that contains some bytes so it's not really developer friendly to have it in one Pro compiled so so for like pragmatic perspective like I think many people are knowledge by pre-compile in general as it like it's difficult to get them in and if you think now like there's a chance we'll have another Blake to pre-compile in one year I think that might be even more resistance to that I

agree I actually I do not think that I I just don't want to speak to how Austin is going and I don't think and I think it might be the only chance to get it in so if you if you think it's not ideal that I think it will be like that that that that that would be the outcome I would bet on so if it's wrong it would be wrong but to get another test to introduce the fixed one I think it's it's it's it's less likely that's fair I I mean I expected considering the work

that the work that you VM one team is done and and and whatnot I will go away our our team has no need for Blake to s or work for 32-bit or below Aryans but I but I can only speak for our team but we haven't found a strong link to us interrupt reason either and so I just I mean in the same way right like maybe in the future there is a reason that someone starts doing 32-bit focused focused hashes but we haven't okay so what is the decision just to be

clear we're happy to drop down the rounds round slim into two 16-bit if that makes folks more comfortable around abuse and and I'm also either way the IP is is gonna get a bit of a rewrite to make it more accurate what it's actually doing so that's where I am and obviously I've been googling just to find any kind of reference to people trying I'd like to be with different rounds and yeah I

have been unsuccessful finding anything I mean ideally since yeah I mean Blake to you has been around for for a while and there hasn't been any such use so ideally I would go with just a proper Blake to be precompile and then maybe introducing a fluid flexible one but I don't think we have that chance at hand so I would be I would be okay with keeping their the rounds per meter and I don't really have a good answer what size debt should be and because it's really up to people who understand hashing functions more deeply

to know what rounds would be appropriate one thing I have found is a comparison that four rounds of Blake to would be equivalent of a trance of cha-cha and complexity so probably going below four wouldn't be useful but I haven't found any kind of upper bounds so I'm not sure what's the right answer to that I think someone mentioned an argument for one but where we avoid endianness issue yes and I see only reference to 10

or 12 rounds for Blake - in general why do we need 2 bytes that was the recommendation for Zuko from Zuko listed you out to dinner dwell my memories right and also with James and I I think it's a bit of like if I was to try to figure out what's going on with EVM one Mike right now and what you guys are working on versus like what's publicly available about it there's just like the information isn't all out there because the teams that are working on it are

pushing out and pushing out things as they're happening but they're not pushing out things that they're thinking about happening until they've happened because that's just not a really good practice so if the people who are working on it right now will say hey we see reasons for doing 10 or 12 and the hard part of doing the work of getting the F function out has already been done by the implementers because that's who's really the work is added on as for these the work has already been done that's been added on then I don't and we've also verified that there isn't a gas problem with having higher rounds because that's already the benchmarked when people were looking at it I don't

think like necessarily limiting it to oh we couldn't find it on Google so then there is no people working on this it's like the right way to go when we've heard from people who are working on it that 10 or 12 is what they've been looking at can't find it on Google it does not exist so if I'm hearing this if we just go with what's been implemented and tested clean up the EIP so it describes what's been implemented and tested we can just go with this and stop arguing about the rounds because you can set it at the

Blake to be number wrap the necessary EVM code around this to implement like to be and everyone's happy did I miss anything so actually there's one more thing I forgot to mention is Sigma table is only defined for 10 and 12 rounds and the RFC suggest to mod 10 TD rounds when looking into the Sigma table but some implementations don't do that so I wonder you know for a higher number of rounds would the configuration need a different Sigma table so as far as I can

tell the implementations there in the RFC there's the equation about how to compute Sigma from what I remember and all those rounds should be based on the same Sigma values so I think it's not a problem whether the Sigma itself is is hard-coded it only has 12 entries yes but

hard-coded values can be evaluated from the equation so the equation is for takes as far as remember the index as an input so I need to check what's wrong well in any case I think the EIP has to be greatly updated to include all these details I don't think it can just refer to that RFC great so if you guys don't mind either way I'm gonna put together a

checklist of what we agree in this call and in this in the call thread in particular I'll try to be specific about the IP changes and I'll have a PR yeah closing note on this this round stuff I think the reason it's really confusing because the IP just refers to the RFC and the RFC doesn't make the round configurable and therefore I think we're not implementing the NRF see here we're implementing a very specific version of lake two and maybe it would make sense to make this clear that we are not implementing Blake to be or Blake to we

are implementing a really specific version of like - maybe a really specific superset of light-duty well it's a subset of Blake - maybe a superset of Blake to be yeah and I'll put that language together and put it past your exit I imagine I imagine we and I really hope that configurations using different rounds gonna be released because otherwise it seems that this feature was added for no reason Korver did y'all say 12 work has already

been done and the only thing that needs to be updated is the language in the IP and we might as well leave it as it is and have testing exists the tests are already done I would say decisions shouldn't be made on based on work has been done or not until do you have the chance make things right if the if the reasoning is to save us from doing work that has already been done then I would disagree with that but if it was - because we've done work then we should keep it but if the rationale is that these changes would save us from doing work but then that work has already been done and I don't think that is specifically a case to undo I'm not sure I don't think we are discussing any kind of changes just to

save time we are discussing changes to make a good freakin time at least that's my motivations I mean obviously you know this pre-compile is gonna be around a long time I mean we wanted to be robust I think the trade-off is if we make a significant change in the signature that means that we are going to be more Russian and more likely to make mistakes and people will do rework so I do not know enough about the development process to know which is a safer choice but I do think that there is there is a safety concern aside from is this the best possible signature and I think that's we'll all of these teams at this yeah I do like the the proposal from

from Martin to have a IP oriented heart Forks because we wouldn't run into this problem what we are in yeah that's certainly good a change is my expectation I'm planning on following up on Gator with kind of a large like our experience the IP process of barring is helpful for you guys but I think the flip side is if there weren't a fixed heart work maybe just wouldn't have been considered important enough to include an artwork so I think keep specific hard courts wouldn't be awesome for teams like ours that aren't solely focused on pushing and deer import but we that's

good feedback I would love to see a complete feedback from you that would help me tremendously as I'm kind of coordinating helping the process improve as we get a heart for Court I'll get you a full full write-up if not a blog post at least at least some thoughts in theatres because we did also try to get into the last hard work with 1108 and learned a lot about kind of how the process isn't boy oh great don't hold back any commentary go ahead for changing two bytes I don't really care anyone else so that would change the size from 213

to 211 yes seems reasonable from testing perspective it would be kind of easy to adapt the tests I'm just regenerate trivial yeah I'm not sure what what is an upper bound for the rounds for all of you know it could be even bigger than 32 bit so I'm not sure how to make a decision what is a reasonable number but that gets us into sixteen only gets us to ten sixty-four thousand the thing is where they rounds beyond ten million will have

to know okay like it won't go beyond eight million because blocks are limited at this amount of gas room but we would need more than two bytes to get update million you need more than two bytes but it's up to you I'm like we will go with whatever we decide here whether it's one bite or two bites the tests or maybe a bit more cumbersome we're like because we have to think about the edge case it's like how it behaves we're different it's like Sigma modulo that's all X mentions here we have to pick the good range of various test cases with different numbers of rounds so they're the bigger the number the more we have to test but in the end we can test it or

business yeah I really hope there will be a variant released after the hard fork or maybe before which makes sound we do we do plan to share our work it's just really strongly about changing it so I guess I'll give some some more background on why I'm also in favor of dropping the number of rounds is is the you know we've got at least currently an optimized implementation which is you know if we drop to the number down to

two bytes we could probably leave it as is unoptimized and not be worried I'm not worried about it because the cost of calling the pre-compiled makes up for the fact that one gas isn't enough to account for the time it takes to do one round in Python now you know obviously we shouldn't make a decision based on this particular unoptimized implementation but if it makes it easier for other clients to to do a simple implementation quickly then maybe that's maybe there's some value there as well okay I've been trying to follow this but

I don't know what the next step is can someone juice 16 bits or 32 bits and we need the decision soon implementations we do not care as long as can I just pick yeah I like the number 32 better well 32 is already implemented in tests written is the strongest or 32 oh let's do that that all right 32 it is or

martin did you have a comment that I interrupted you yeah Alex did you have a comment yeah I'm really not sure it seems that technically the upper bound we have is just 8 million rounds because it's the the block cast limit or maybe 10 million rounds which which you couldn't address in 16 bit but yeah we are yet to see any kind of configuration which goes above 12 because one of the main benefits the blake 2 specification cites compared to

blake as the the lower number of rounds so i would assume that they would only just want you only go above or below this standard i don't really see how they would go and it could anywhere close to 8 million I agree nothing that we yeah I mean that's why if we went down to one byte I wouldn't bother me it's just which is why I think 16 is fine I think the question really is is it more helpful to to help like Python and other unoptimized implantations or is it more helpful for no one have to make any further changes other than

rationale and history and the rational history naming all of the oh thanks for sticking around Martin so it sounds like 32 test case is already 32 any other comments on that well there was the other proposal the the message length a meter I guess we don't really have time to or do we I mean some people are

sticking around it's all its I almost said night at local time but uh we just have someone make it a suggestion or getter if that's the last thing I mean how did the champions against it or is anybody against it yeah you know I mean from my perspective it's a question of whether we want to stick to the RFC and add the parameter about the rounds or do you don't want to stick to do yours I don't think we're sticking to the RFC anymore because we have two rounds oh yeah yeah this third but it's one change I know I don't really have a

strong opinion here from the perspective of the implementation it's easy to to change this I can speak for GATT client but I can speak for other clients I guess it's harder for sure it's harder than changing the size of rounds so the motivation is I've implemented a I think more efficient implementation of using the pre-compiled on the EVM and the the key optimization is to to keep the context once in memory and keep

reusing it and in that case for the last for the last chunk there is a need to zero out the memory in in the context and it seems to be I mean it seems to be an easy way to avoid them and in the case of the Zika spoof of work there are 512 rounds I mean if there's opposition to doing a very trivial change like like dropping a number of bytes of rounds I'd

pretty sure there's gonna be more on this other change it with require a lot more testing I know my perspective as far as the implementation in God is concerned it's not that easy to change I mean it's easy to change sorry I don't know what are the other use cases for F maybe they will require more I know it's like the question about maybe leaving the freedom to developers that we think are going to

use this recompile is there a high different very large difference between the gas cost of calling the current version the version that you're proposing well it's an extra one byte so that's the only difference in the cost but preparing the message is cheaper on the vm if you don't need to zero out stuff so this difference hit wants every free compile call just be clear because

it's just a message crap I know I don't have a strong opinion here to be honest I'm happy to be though we should stick with what we already have because I think that's typically pragmatic and because I don't think that people are calling this compiler so we're not going to be doing the message frequently so I'm happy to kick up that side if we need that on this call but yeah but if they're not preparing the message to

know how they're going to call the people call oh no no no I just meant this is not how many times you you know like in and use kists we're looking at how how often yeah I mean just this is kind of going back to your own argument how how expensive is this actually going to be verifying equi hash well you need to prepare a message for every handy 28 byte chunk of the input so I can a bit confused when you say that this this isn't gonna be used frequently that

would mean that people won't be using the pre-compile now I'm just I'm asking I'm asking if you have an idea of how big I mean this is you know what how big the difference is going to be so we could actually like assess the damage it sounds like a 20 oz for me like for every single call of 2010 128 bytes as alex says because you need to clear 128 bytes of memory so you have to learn to memory and I think those will be free for every single write or or is it more Alex I think it might be even 40 minds yeah I mean you would you would have to clear it so if you're sending the last chunk is only one byte you have to clear

hundred twenty-seven bytes of the memory yeah so this are for M stores right a single story six I think so it will be 24 gasp plus some logic around it in looping say like maybe 40 gasp for every 128 bits so the bigger problem isn't actually just zeroing at that memory isn't it expensive but if you have a loop where you are you have an input memory and you are splitting it up if you have to support the current weight and you have to have a lot of different conditions how big is the input or you could just zero out everything prior and then overwrite it or you could just copy

the right amount and then zero out the remainder so it becomes way more complex as compared to just being able to set the linked well I mean you guys are obviously the EVM optimization experts and on our team and as long as it's not restricted to functionality of fi if it's if it's cheaper by 20 or 40 gas per invocation on seems worthwhile I think we're starting to burn out is this the last

it's the last thing to decide yep only remaining question let's move it together once we've had a little bit of rest any would agree as long as you're fine with that Matt I can help keep the conversation moving on both sides yeah that's I just want to make sure we resolve this quickly again we don't have nearly as strong a stance on this so if if you guys are happy and we're okay with the implementers fine teams don't yeah let's follow up on it okay thanks so much James for pushing it on both sides and thanks everybody for staying over we will end this now

thanks everyone just to be clear the next call will be in two weeks yeah two weeks from now will be the next halt okay great all right five everyone thank you [Music] [Music]

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

[Music] [Music]

[Music] [Music]