All Core Devs - Execution #27

Transcript

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

[Music] [Music] [Music]

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

you okay I think we're gonna go ahead and start let's do a test someone from the stream talked up that didn't work let me try this again okay great we're working perfect all right so to the agenda what do we got here so instead of the fork review going first let's do testing first cuz then from there we can talk about the review so if Martin or Casey could you go over because there's kind of some confusion

amongst people the two types of fuzzers that we're using if we're if we can talk about that and which ones or which one found the majority of the bugs mm-hmm okay so yes we have there are two different tracks on the post testing and the one we start with earliest was based on tests of generating random state test and then we use that to execute in pi-theorem cpp parity yeah and then we compare the outputs after every

operation because with there have been modifications made to the clients or actually to the raw ibm's so that for each instruction made it outputs JSON blob with the internal state respect remembering so forth and yes we just do that run them and compare out that notifies of everything and differs and that enable us to find changes that might not have been consensus necessarily there it's only a different memory but which could become consensus issues a lot the first approach

it's that one's pretty slow right now it's using docker containers for everything I'm working right now and grew up in your own that died in your system I don't know how will fit Python into it but maybe make resistant container instant anyway that one found I think it found three floors Constance's issues the other approach is is using a Lib Buster and it's a framework being developed by guido Branca mmmm yes earlier written process for a Bitcoin and yeah a lot of stuff

and it is using instrumental versions of gap and parity where it's instrumented them to master code coverage basically so live constant based approach is that the input is guided by the coverage so it makes multiplication so it sees it gets better path coverage from anyway important and it kind of makes better and better inputs to get really good coverage and it also checks for minor discrepancies in the execution looking at the trace and the the memory contents on the stack confidence to stuff like

that I think that so that passer is a lot quicker it manages to do thousands of executions per second because both of the clients are basically compiled into one binary that you just run that's extremely lot quicker I think it's found two issues for three from testers to from that one and yeah we're we're running all Fosters on the server or on several servers and we'll keep running in mm-hm okay cool and did we start when did we start running those before the fort because that's gonna help us kind of

review the fork in general not that long a couple of weeks we've been women basically messing with the higher the testifed base faster since before the summer but there's been a lot of work I'm getting all the courts ironed out from the EVM binaries and getting the and the individual I outputs to align because there are differences to the implementations okay yeah okay great so that yeah that's that's kind of what I thought and I think I think we're getting donated some server resources soon so that should help take the load off and so that that's gonna help a

little bit so yeah any other comments on testing and like you were saying we're just improving on that more adding more servers many other comments from you or Casey or anybody the case is some something to be improved because after the book there are still unemployment in the test cases many many new test cases were proposed as to me yeah because uh can you guys hear me yeah yep okay when

the when either of the fuzz testers finds a consensus bug that test case may not may not work as a as a state test because oftentimes the bug is only a difference in a certain some steps in the trace but then the state route is the same at the end of the of the tests and since state tests only check the state route they don't compare the the traces the execution traces in order to convert in order to create state tests from bugs at the buzzer fines they have to be manually

created so that it so that the bug ends up with a different state route and so that still needs to be done for for the bugs that it's found okay interesting great so it sounds like we're still in progress on some of those things and let us know if you guys needs more support on that if we can call in people from other teams or from the community again to kind of help with some of that especially the manual cases because I don't know how many volunteers are still actively working on that since the last time we did a call for participation most of the newly proposed cases based

on already known bugs that has been already fixed given that me and lots of people know the cover indeed would be enough family these test cases will prevent regressions in the future but cannot really I think okay I see so they're not urgent because we've already fixed the one they've been found in a different suite and we've already fixed it just for future clients and stuff okay so yeah if there's anything else with the testing I'm gonna go ahead to item two if you want to refresh your

agendas I just kind of updated it to put things in order so this is just a review of the Byzantium fork so just kind of a verbal review I think it was three or four days before we had the Byzantium fork we had some one emergency emergency patch with parity we had a few more in the days following I think two more and then we had a and those were consensus bugs for those three to four patches and then the day before or two days before we had a guest denial of service bug that would have taken nodes offline

the 1.7.1 notes and then so a 1.7.2 note was released and then in the case of parody they released one point seven point six which was bug free and Byzantium compatible they also then released one point Arkadiy you might need to correct me buzz it one point eight point Oh perfect oh yeah if you could turn your microphone up a little bit Arkadiy okay so yeah so that was kind of the build up

to it and there we kind of got some feedback from the community and from Bitcoin maximalist and people who hate us that we were putting out a ton of fixes beforehand but in my estimation or I guess my opinion I would say that because of the way we were running the fuzzers this was kind of not even expected but this is something that definitely could have happened and it did so I don't really feel that badly that we had some releases right beforehand I think it's it's not good but like it's better to do that than to you know ignore fuzzers or to ignore test cases so that that's kind of where I am on this granted I think in the

future we should definitely have some provisions to run the fuzzers for a longer time before we declare the hard fork in this case we wanted to somewhat keep in mind the block times to make sure that they didn't get too long and that we didn't have the hard fork around Devcon but we could have definitely planned this out better so I think Vitalik you mentioned you had some thoughts on this so if you want to start and then we can kind of go around the room like thoughts on what aspect of it particularly were you thinking code improvement or basically what you think was wrong this time and then provements for the future yeah so like so first of all I guess when back when

we had a record dev meeting I think it was something like four weeks ago so September 22nd like I got the impression when ia was suggesting four points to be seven million I got the impression that you know and when I before then suggested three weeks I had the impression that basically literally two days after the meeting on September 22nd we would release the hard work version and like actually give people three weeks to do the full upgrade and yet somehow this just ended up not happening so that was like yes in the future like I would prefer we actually do give the literal three weeks between release of the client and release of the four code so like I realized metropolis was a

weird situation because we didn't have the itis age to fight against but in any in any kind of commerce situation it seems more prudent to do it that way but at least that was one thing that I remember saying the aside from that I mean I think that we in terms of just roll out and the kind of quality in general we did probably did the best that we could given the self-imposed timeline and the thing that I what the other main takeaway that I got just basically is that we should be a much more conservative about the kinds of changes that we're going to integrate

and basically be afraid of consensus complexity and particularly be afraid of consensus complex things that give up 1.1 X improvements when we can use the same effort to do things that give us a 20x improvement okay something else that I heard a lot and I know Gavin went on given word - coin desk and and did some tweets and other things to kind of argue the case that the amount of time between bugs before the hard fork warrant a two-week stoppage an emergency basically an emergency stop and two-week

delay at least for the hard fork um so is that the kind of metric that we need to have in the future for a like basically say if there is a bug X amount of days before the hard fork that there should be an emergency stop or is that something that's not a good metric to measure by I think the ocean you also need to take into consideration what what the emergency stop means because if the merchants table means releasing two three four or however many clients and convincing the entire ecosystem to stop then that's a completely different ballpark than if the emergency stop

meaning maybe updating a contract to just yeah I should I should be more clear on that so emergency stop to me means if there is a planned hard fork on a Tuesday and it's like a Sunday the Sunday before and we find a bug that we delay the hard fork for a certain amount of times hour days I should say or blocks yeah but that's still the pencil exactly what Speer said how good how good my thumb dynamic is our hand break in that situation I see so what and actually yeah what is it good what is a good dynamic hand very cuz you're saying is that can we do it by a contract is that is that a possibility because I heard some people saying that and another saying that

poses a centralization risk while garlic's it's not one way that we could say we could prevent too much centralization or too much power in a contract is maybe just so instead of having a contract that kind of directs when the whole fork would happen you basically would still hard-code the four o'clock in to the client and maybe just have a contract that could just stop the fork meaning that basically if the contract sugared before the fork then basically clients go on without forking because this way it's it's bit less

control that makes sense but who would be responsible for declaring that a fork could be stopped would that be I guess client teams and prominent community members decide it on a yearly basis or something oh yeah I'm sure we could I mean I think the issue of who has the case or which persons have the keys to you know set the hardwork or delay the hard work I think that can dissolve I'm curious about to take the call implementation because there was some concerns that it wouldn't work for lifetimes so do we have those kinds of technical limitations is that that it's

having anything in the contract states that complicates I clients to and and for example fasting to so that's why I was suggesting that we try to keep it as simple as possible that maybe it's easy enough because if you try if you want to set the fork block in the contract and all of a sudden all the clients need to keep track of the contracts throughout the lifetime of the chain and that things get messy but if we have for example if every client is hard-coded that okay serenity will for CAD block I don't know six million and then at block five million nine nine nine and nine the client checks whether the fork is still on or not and it's enough

and did you say like clients could handle that so so if if there are light servers available then sure but I'd so all in all we the other thing have to need to be aware is that these should be emergency measures so for example I assume that if we postpone a hard work that eventually all clients will issue an update that will remove the four clock or change the four block number so we only need to have this emergency break you'll need to make it functional for a few days if there is an emergency so we yeah I think that's a good idea I think that's something that we could

definitely do and something else and this was actually brought up in chat which is another good metric is the like the rate of new bugs like how quickly they are discovered back-to-back but is that actually a good measure of how ready we are or is that something that happens very randomly because we're using a fuzzer somewhere in between yeah I'm really cautious to actually use that as a measure of readiness because of how random a fuzzer can act or you know what I mean like once it finds a bug it's just you know it found it because of random inputs no okay so we

know we've kind of gone over you know some of them that some of the measures that we need to take potentially so the contract is one of them something else the metalic mentioned was having clients have like a cutoff day for their releases be a little more strict about that so that we can then have better timelines for we have X many weeks for testing we have this many weeks for a test net period going up something else might be and this isn't something that actually affected pork butt I think we could have had a more concerted effort to get to mess with the new opcodes on the test net

because by the hard fork date I don't even know if we tested all of the opcodes exactly at least I'm unaware that we did I was gonna say that in my mind the test net deployment it served us in getting some error reports on from services which like for Aoife scan hadn't diplomatic status so they using the test that they could implement the status and there was a problem with gas estimations but it didn't actually find any real critical bugs only like on the side kind of bugs but what the test Nets deployment did was force the client the

implementations to actually include the byzantium code in the master which enabled us to do fast testing and not have to use rebase brushes on everything just to be able to get to it so I kind of disappointed in I don't think I don't think that chestnut deployments give a lot of interesting testing for consensus stuff it gives a bit of I mean it's a bit of help for the community to be able to try out new stuff but I don't think we should rely on it too much for testing I I agree with you except for I think that that might change when we get

to Casper because that's such such a massive I guess difference in how things are done at a consensus level I feel like that's gonna be a noticeable difference on tests that the people are gonna want to see mm-hmm for example one thing that so up code style probably our consensus tests or whatever tests can be a fairly good thing but not working why is the consensus tests are worthless of course so seeing how the whole network behaves how how peers start dropping off or not dropping off when they split different change so for example I remember in Olympic when we had to change split and the entire network fell apart and was it really a pain in the

ass to merge it back together and I think that that test networks are really valuable in this respect yeah that makes sense this time around there was the the Deaf p2p or the version 5 flag that get had implemented but parody wasn't compatible with and that type of thing we could catch by running the rate simulations in hive to make sure that peer you know peer network protocols are compatible yeah but so what you cannot run in hive is for example if if you have a network and let's say half of

your nodes don't update or a lot of lazy people don't update and those are scenarios that are really hard to test out in a simulated environment right so I was kind of wanting the opinion from the Gath team and also just just to clarify the opinion from the parity team so parody has an auto update feature it was broken up until one point seven point six I believe or maybe it was was which where was it broken Arkadiy great so that feature though that is actually is that it is that anything that can be

opt out or is that something if you have the parity client you have to participate in opt in oh I see so you and you started it like gives you an option [Music] I see okay so Peter the gift team I think in the past has been reticent to have a feature like that but what see what you guys is opinion today on having something that is an optional something kind of like what miss does where they have a

protected repo that has like a file that has the latest get the latest get release that they can sync to missed from people who download it so the important thing to know with missed is that misty has a user interface so basically when you start mist and it can just pop your window the do you want to upgrade or not and death on the other hand is meant to run in the background probably without before possibly without even having any user interface or user interaction at all and that means that gap would need kind of to figure it out itself whether to update or not update all to update and that becomes a bit problematic I see because you don't want

anything on a headless install stopping the whole execution of the backend process in order to warn someone of something yes the point is that if for example let's say that the next change is running cat in the background do you really want that process to start thinking of itself yeah that makes sense so I know maybe I don't know if people are so people using gas or art I'm I would say they are probably either running mist in which case you do have the auto update or they are possibly running installs from Ubuntu BPA's or

whatever in which case if auto updating again becomes a bit messy how do you update it we could basically download the binary engine just switch over to some newer binary when you run the old one but I don't know yeah I mean I would think that if I was like a service running it either having a message pop up like along with all the like a Furion console mode having a message pop up or having it as a command-line option for those who don't want to who want to know when an updates happening and their node can go offline but otherwise they just want it to be up so basically for those subset of people it's not a huge it's not a huge portion

of people running death I would say but it's enough to where that little bit might help people who cuz that those are also the same people who would forget to update in the first place the ones who have a full node running and they just leave it on all the time and once it goes offline they just restart it again it's not like critical to their infrastructure or anything those kind of people might be benefited by something that actually warns their node or stops their node or things like that if they decide to opt in yeah I guess so for quite a long time we had a version Oracle and guess that basically every hour or so or whatever check the smart contract and just reported if there was a newer version that you were running

but it was kind of annoying to always keep bumping the version numbers and we didn't really see the benefit as basically it was just a log deep inside your user logs and then I don't think anyone is actually looking at their logs so maybe maybe what we could do is basically have an opt-in mechanism where it's a node you just kind of stop and force you to update if you opt in but I don't know who would do that yeah I mean like I think if it's if it's a command line option I think it I mean even if just one person does it what are we at like 10,000 nodes or something like even if just a subset does it I

mean depending on our growth and how many nodes will be there in the future like that I mean it might it won't hurt I guess is what I'm trying to say yeah the other problem is that the width we're kind of trying to do the bi-weekly releases yeah that's true so if if every second week your node stops then they're going to get angry really fast yeah no I think it's more for the critical hard fork releases as what art o is what our kadhi was referring to so what they have by default is critical so that would be Arkadiy am i right to say that that would be hard fork only like releases so what would be considered a critical update yeah okay

so yeah yeah this is something we'll discuss more probably or you can discuss with your team Peter but yeah just kind of wanted to get people thinking and I should actually also say Mikhail at the Java team what what what about you guys do you all have any kind of plans or ideas around an auto update mechanism actually we didn't have such plans or I've heard about parity way to to work around critical updates and might be able to in some future we will implement something like that in my opinion this approach is pretty good and since we have UI we could do that cool yeah yeah

cuz harmonies a front-end so more has a UI so that that would be really cool all right so we've kind of gone through updating we've gone through some lessons learned and so for the actual for any future hard Forks or major protocol updates that require coordination I think that we should have an EIP in place that designates things like time between the last bug found and the hard fork how long the test net should rot won't run things like that and so I think Nick mentioned he wanted to help

with that and then I can help with that I talked to rob at ëthe Waterloo and I think he also mentioned that he'd be happy helping with something like that so an Arkadiy if there's anyone else from the parity team who wants to feel free to get them involved I'll probably be starting on that when I get a free moment which will might not be before DEFCON but we'll get it done in the next will at least start on it in the next month great same thing with getting the e ip's kind of on track they've been a little sloppy still lately so we're we're still trying to get those we need to merge all of the Byzantium ones and finish the meta EIP for that mom which i think who's on is

it Casey and Alex doing the meta ai peas the others are done yeah I have a PR for the birth for that already ok perfect it doesn't it doesn't need some polishing ok no problem cool is there anyone else who has opinions on how the hard fork went how it should go in the future any comments okay great the next item on the agenda core team updates so I'll just go through the core teams and if you have anything you want to talk about for parody I know they just had a major release which has a lot

of cool features so they can talk about that if they want if the gift team has any major fixes or releases they want to discuss anybody has cool stuff we'll start with guests nope everybody's preparing for daca okay great parity Java no cool I know you guys were working on some of the testing stuff are y'all still working I think it was getting on getting the state tests implemented or did is that what y'all

finished last time I have started to work on a high of integration high that's what it was sorry I got a confused and we have started to work and then before that work and III just got back to it today because I had to fix some issues which was which were related to the fork so yeah I guess I will continue the work on integration during next week yeah I think me if there is something wondering about it sure thanks

Martin a theory I'm Jess Casey is there anything no I don't think so cool Oh Arkadiy just said that snappy compression support is in parity now so that's great no problem and then CPP aetherium is there anyone here who can speak to that I don't know while reading the Android he is working on the quick estate sinking I'm still removing some sanitizer warnings about

the big rocks and so on [Music] okay great am I missing I guess Oh Python so the talaq any updates on that um the main thing we've been working on in Python most recently is just making Paiute app work with Python three better and just in general it's having trouble connecting to the network in getting peers so trying to fix that sure and so I think Piper Miriam was working on some type of python implementation how is how is that related to Piatt Thap it's fairly separate so far okay sounds good and

then do you want to give any kind of a research update metallic cuz that'll kind of go into our next section of what we may expect for Constantinople even though it's real early to kind of suggest stuff yeah so we just released a look a draft which is B of the Kasper paper and I can actually just publish that ain't in here so like basically theoretically a Casper may well be at the stage where we may actually just wants to go ahead and try doing it in the doing for the next fork you know even if that sounds ambitious okay cool so when you say Casper you mean hybrid

proof of steak the finality gadget not Vlad's thing okay sounds good yeah that sounds old that's actually sounds more doable and I know there's a number of other VIPs we've talked about including Matt Matt Dean perrantes a different elliptic curve precompiled that he wanted to put in and just a number of other things the Blake to be function that Zuka wanted to put in as well as Jaden so we will probably start collecting those in the next few months

probably PostNet Khan is one will really dive down into that yep because sounds good so as far as Constantinople goes we don't need a timeline today at all but if you wanted to include the Casper and the finality gadget and stuff like that the first steps went when do you think that would be done or is there any kind of timeline like qq2 yeah so there's a so there's already a Python implementation which is like almost done well there was one that was done for the previous version but this version is simpler and Karl is in the process of doing switching that over and it should be done I would even say very soon and the other thing is that the parts that

aren't done I would say but basically the parts that aren't done Erik find details of the contract and so it like the actual spec of the fork is not going to be particularly complex that's basically just add add some Bal and increase the Bell and some of contracts then I change the fork choice rule and add a couple of by adding a couple of function calls going into the going into the Casper contract so if there was details change that's technically it just would not affect so like what happened the actual like anything of the clients implementation by much okay sounds good so the next thing is there any other updates from anybody that they

wanted to shout out cool the next agenda item was website update so some people were discussing if there's going to be a website update that website has managed aetherium dorgon's managed by the etherium foundation and there's been discussion to do an update to the website a new theme and new content that's gonna take some time to curate but just so everyone knows that is in progress there is a group coming together in order to you start to accomplish that so there's no timeline but it we do we are aware that people want an update to that and we are working on it mm-hmm so the next item cross-team quake 3

arena session so this is the most important item obviously number one will quake 3 work on the latest operating systems ubuntu 16.04 yeah we will have to check that out anyways yeah maybe you can run in wine or something anyways yeah that's kind of a joke one but for real we'll probably talk offline about getting a core dev meeting set up or something at at the Met DEFCON maybe I don't know if we'll have the time but if we can then we will the next coordinate meeting will be in four weeks because in two weeks we'll be at DEFCON so what

we'll do is yeah four weeks from now we will have our coordinate meeting that will be on the 17th of November if I'm not mistaken hmm so that that'll work fine let's see I think that that is everything on the agenda so does anyone have anything else Oh Christian you were talking about web assembly it was meant as a joke for a quick hey does anyone remember when someone did a contract in like mutant or lll that like was

actually a pre a compiled quake contract I think it started with solidity and then turned into the some JavaScript version of quake right yeah it was like a solidity contract oh here it is it's called ether quake Oh II redid this here y'all go an implementation of quake 3 and aetherium oh yeah is it Viper doing some cool stuff right now metallic I I think yeah and while Viper is let's it's not sure if there is any particularly cool like a mega cool thing to announce accept that

like development discontinuing there is a web compiler for it now otherwise just going well did you I saw something that it's gonna be like to formally proven or something or tested by some organization oh yeah yeah I think that might be that might be connected to that KVM group yeah I thought that was it and then um now that actually we're on that topic real quick wasn't there something with bamboo yuuichi where you recently implemented a vault contract and there's been some progress in bamboo I'm I'm starting to get the external other contributors one of them implemented new materials and how you can learn what you

re in bunker nice and then solidity just had a new release so congrats on that Christian there were some cool features thanks I think that covers all the languages cool does anyone have anything else yeah I know I was just wondering you keep 86 208 is that is that still in any way shape or form planned or it's gonna be replaced by something else I think that's still in kind of thinking about it mode okay is it still or both of those still required for serenity so

theoretically EBT sexists what are we not required for implement for Casper okay cool let's see yeah I think that's it that's all the agenda anybody else have comments cool all right well thanks everybody we'll talk to you in four weeks and we'll see most of you at DEFCON yep bye everyone bye Cheers [Music]

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

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

[Music] [Music] [Music]

[Music]