All Core Devs - Execution #28

Transcript

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

[Music] [Music] [Music]

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

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

[Music] [Music] [Music]

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

[Music] [Music] [Music]

[Music] you [Music] Peter you able to hear us okay great I think we can get started then

hey everybody let's go ahead and hit the agenda let me also make sure can everyone hear us on the YouTube pulp so the first one is testing that's just more if there are any updates that are relevant I don't really know if there are for the fuzzer or for any of the test cases I think here each is the only one who might have some insight into that yuuichi do you know of anything on test occasions I'm doing the visibility I'm talking some so this case is in the Google spreadsheet in turn red to green

in some cases I see a test case and I find it already in the repository and iconic green and so on so some bureaucracy is going on both hazard size she actually activities but I cannot really describe it it's the best place is the fashion channel but okay it's private well no I I don't see anyone who can explain that in this meeting right now unfortunately no problem we can just talk about that the next meeting or if martin ER dimitri or anyone comes in we can ask them all right moving on to item two the Byzantium fork review so during

DEFCON three about to air I guess two weeks ago we had a meeting with some of the court developers we announced it in the channel and it was an in-person meeting with about oh I'd say at least ten people where we kind of talked about the issues that we had with the Byzantium release some of the things we learned and some of the things we might want to do better there was a lot of different there was a lot of different things discussed that could be possible future changes to how we do hard Forks the ones that were most discussed is having a dedicated release manager that's something that that's kind of a

role that I served last time but because I couldn't dedicate my full attention to it a lot of things kind of got left behind especially the EIP surrounding Byzantium so I think that having someone do the role in a full-time capacity or maybe with a few other things and a related role would be really good so that is still a ways from you know like deciding officially on that finding anybody for that that kind of thing so I think that I think that that would be a good next step the other thing is oh maybe having a cadence for hard Forks so

there's some different software projects that have release cycles so like you do a release once every two weeks or you know you do a release once every six months Peter I know guest has something like that could you kind of give an example of how your project does releases or tries to stay on a schedule sure so and of course for napkin with a bit out of control now but generally we try to do bi-weekly releases and the idea is kind of simple whatever makes it the master gets released in after two weeks and if your feature didn't get on master in two weeks then no problem you

have the next set schedule next to release to get your stuff in and as long as so this the downside of this is that people can get annoyed that their favorite stuff didn't make it but in general it's actually quite beneficial because as long as you have regular releases you know that even though your stuff didn't make it in this release you don't have to wait an eternity or who knows how much to get you're stuck in the next release and this kind of worked well so previously with the guest 1.4 family we ages to do releases because everybody wanted to get their stuff in and we did releases every few months so it was really painful if your stuff was at half

but since we switched over to this release model it was all the friction cut kind of just got dropped and I think we're discussing during Def Con that this might be an interesting approach for hard forks to because currently what happens during hard Forks is that everybody has their petty IP that they really would like to get included and then basically we start to delay the hard folks because some a IP is missing and because we have absolutely no idea when the next the IP will be so one of the ideas was that if we could do a more or semi more regular hard Forks to the protocol updates then maybe we could

just say that well ok your IP wasn't finished in time no problem it will be in the next one now of course maybe I would just give the word back to Hudson but this obviously won't be such a tight schedule as two weeks or even two months but rather much longer but I think Hudson can can pick up the pace from here ya know that was a great explanation and exactly it wouldn't be something like a two-week release cycle it'd be something like six to eight month release cycle where you have a period of picking the EIP s having a strict cutoff date having kind of an implementation phase with a priority order for the e IPS and then a very conservative testing phase with

some rules on when you know we should raise a flag for you know postponing a hard fork what are the conditions for that to happen etc after I see you're also in the channel is there a release model that parody generally follows that you would feel like describing it all or at core release schedule this means basically a new better channels opened every six weeks but we are currently not where we are looking a bit behind right now that we are planning to do minor

releases every six weeks okay cool so yeah basically one of the harder parts about this is figuring out the timing basic how to how long at the time should the whole release cycle be and then also within that how long should that be for planning implementation testing and any other minor phases in between those even so some of the timelines discussed were a six month or eight month full release timeline with something like one month or two core dev meetings to decide what e IPS are going in for that six to eight month period and then like four months for implementation and three months for

testing or something like that it's still very very early these are still suggestions but that's kind of what was discussed let me see if I get opinions in the room about any of this especially if you have commented on this before sure so I'll start if nobody else wants so the reason why I I at least personally think this is a good idea is because one of the problems that we personally solve it Byzantium was that we had a lot of VIPs written up they were kind of ok is ready but there were a lot of

information missing and it was really really hard to implement it and really hard to synchronize between different clients because for example parity had an implementation that was one of the specs and the mass spec was updated and then we employed the difference back and it gets messy from there so if we could have some meaningful cut-off dates - for example arbitrarily many weeks to define what the IP will do and then we only change the spec if something really goes wrong with it then at least kind developers we'll have a stable thing to work based on and then we don't have to postpone because somebody implemented a difference back rather we could just have hard deadlines that okay you had four months please do it it's much cleaner from an implantation perspective

I agree I think that also builds on stability any other comments on kind of this hard fork guidelines or future you know flags we put in place III need it I know someone was taking notes I think it was Martin and he's not able to join today or right now so a lot to get those next time and discuss this in detail that I remember there being a few conditions for delaying a hard fork maybe oh he'll be here in five minutes sweet okay we might I might just wait for him to kind of say some of his thoughts as well but are there any other opinions right now okay cool yeah if Martin comes in

we'll discuss it a little bit more we'll back up to that topic and if not then we'll just discuss it next coordinate meeting so the next item movie IPS activated and Byzantium too finalized we are still behind on that additionally I believe that Nick savers on get er that might be his actual name I'm not sure he had a PR that was similar to a PR that a free wrote down a meta a IP that described all the Byzantium changes so Nick said that it doesn't link to the actually I Peas his met it has met an EIP that he made so in that case he can

withdraw his PR in favor of the meta e IP that a free has so that'll that'll be just fine and so we're all aware of that the next topic item unless there was any any comments on that just a quick comment oh I don't have any made up the IP it's a misunderstanding so you're right I think it's Alex or Casey that has one I could go look yeah I'm looking it up right now and

going to go to pull requests and search okay yes so this is it was I think it was Casey's and or maybe that's the process for finalizing but regardless someone wrote a meta a piece Oh we'll just need to make sure that's completed and merged in hey Martin welcome to the call can you hear us thank you yes sir great and then does anyone know who gasps she is is that hello

whoever just joined can you identify yourself please oh it looks like you eat she actually posted the EIP link so let me go to that you know free and I independently found it's a 609 that's not made by equal Byzantium okay it's case she's great so whoever just entered his name is G H a s could you identify yourself hello [Music]

hello I'm not sure what your name is um yeah I'm for maybe 20 years I try to just list the position because um um the world's them even and and yeah that's no problem so um I'll talk to you

on get her after this but thanks for joining no okay so Martin we were talking just a second ago let me just run back to the agenda about the hard fork guidelines we talked about during Devcon and we kind of went over the basics of the potential for six to eight month release period per hard fork some of the like like the fact that we might have some you know red flags that would stop us from releasing a hard fork or maybe delay it we didn't really go into any of the signaling systems for that we also said that it would be something like in testing or the choosing the EIP is implementation and

release so if you wanted to I know you took notes during that that we can bring up for next week's meeting once we give them a little cleaned up but did what what is your opinion on the kind of the things we discussed at that meeting right so I have some notes about that and I stopped along to Nick that it was to start forming them into eat we haven't done so yeah but some of the things that itself in those notes is [Music] yeah we should should have picked your requirements for for the for the eat crap probably has an infant after didn't

different science but maybe otherwise because it's better to study and yeah regarding signaling about being made any real progress except to say that we really want to have more dynamic signaling systems we also yeah yeah it's Oh looks I don't really want for something else as they are I need to clean them up a bit then perhaps start turning them into neat that would make and if ever wants to get part of it that's a great idea and yeah we'll be looking forward to that especially if we

can make the EEP and then edit early work on it together as we kind of discuss and coordinate meetings what the next steps will be and hopefully eventually get some sort of release manager all right so let's move on to the next topic which is the proof of authority test net unification Piper put that in and I don't think he's able to make it today so let's I'm gonna just think I'm gonna speculate on what he meant by that I think that currently ranked B only works for death and unpair D there covin tests net only works for

parity so I'm guessing Piper's probably talking about that either that unification or the creation of a new proof of Authority test net that just works across all clients so Peter what what's your opinion on that and especially given that you have a new really awesome tool called puffeth that starts to kind of bridge the gap between these things so uh yeah I think that the pain point is probably and everybody kind of feels the pain point pain point in the community too is that it's kind of pain to actually test your depth across the stat works because Rob's done is yeah we know Rob's done but even though coupon and drink we are both

potentially better alternative to Rob's and they aren't really cross compatible so it's it's annoying and I'm guessing Piper the reason why he was asking to unify the test nut is because they started to pick up development on the Python client again and I'm guessing they would also like to roll out a proof of authority consensus engine but I don't think they want to implement two of them or were third well for that matter so that's why I think Piper brought up the subject now with regard to to the customers engines in itself I'm going to say so basically current we

have to do proof authority test that works : from parity based on agra and bring me test that work from gas based on click I'm not too familiar with the aura so I cannot meaningfully comment on that but the reason why I'm personally not a big fan of that authority test Network is because it's a really complex complex scheme so I think the parity people really tried to make the their proof of 30 protocol actually meaningful for lots of various use cases and really flexible which is really nice but it also in means that it's kind of hard to implement whereas whereas the click

proof authority product was kind of always meant as the simplest possible engine that just works and can be dumped on top of any other client implantation so from my perspective I do think click is simpler now regarding whether we if people want to actually do a combined proof of authority test not whether we should stick with click or maybe dream up a third one that's I from my perspective it doesn't matter that much but I kind of agree that it would be nice to have a really a again a common test network between clients ok cool I don't think our cadiz here today so I

don't unless a free you want to give a comment from the parity side it's no problem if you all don't have an opinion today since this just got sprung up in the core dev meeting I totally it would be nice to have a cross client pya test network but I can't really comment on any plans to it anything like click 2:30 right now no problem yeah I kind of agree that this is the I think this is the the friction point of this cross type of authority test network is that adding click to parity means it's a burger on parity people adding our two gas means it's a burden on on us and basically it's a burden on

every other client to implement either of them one thing to keep in mind with with a two different proof of the two different POA protocols is that the parity one as I understand is contract based whereas the guessed one rinkeby is header based and ultimately as clients start implementing the Casper chest net um those will be contract based consensus protocols hmm interesting it's starting to sound like a good move would

be a proposal for a third test net that maybe starts to mimic some of the things that that like yeah things like the future Casper test net has especially I mean we're definitely gonna have to go through the pros and cons of both of those approaches it's way too early to do that yet but but that's interesting and something we should think about for the future coordinate meetings is if the third one should be created actually that was an interesting idea so as far as I know V was already working on on having a Casper that's not work I think maybe blood also yeah so one thing that so basically adding various proof of

authority to different clients will be a pain in the ass anyway so maybe it's a long shot but maybe we can try to instead add or start adding Casper just play around with that idea or just you know a subset of I'm not sure I don't know how how far Casper it is or whether it's actually usable on the test at work so maybe if you can give your ideas on I'm sure so as I understands the like there's already a fold a Python implementation of Casper and a test the network is well there I mean there have already been

kind of successful moments the every test that works between basically what 2pi you thought no it's running on the same laptop and we're currently trying to expands that and actually have it kind of run across the internet in a self-sustaining way though currently the obstacles have more to do with stuff and stuff involving pi e theft and stuff involving Casper so theoretically like basically it's I'd even say it's getting to the point where it's ready for implementation and other clients - okay and then based on what you're saying I would take that maybe so if we if we

want to aim stability with a test network and maybe it won't be the best idea to make it based on Casper just about now well so the way that Casper works rate is that you can have some clients that that use the Casper fortress ruin some clients that use the proof of work for a stroll and basically unless there is an attack then the two of them should always give the same answer so you can look like the way that the Casper test oh you owe the talaq your mic went out yep we could hear you now you were saying how the cache test networks yeah

so first of all it's only it only becomes a cow's protest like the Casper part of the algorithm only turns on when the Casper contractor the watch dinner and it has enough ether deployed and even then if an individual clients is not Casper aware then they can just keep following proof of work so we can basically have a test that work and literally test the entire trend and if that's what we want to do mmm my question really is that that so with Rob Stan the reason people don't like use Robson is because it's not reliable if some of the greater you want to attack now the question is if a Casper test at work could we provide some guarantees that if I if I ran yeah okay so the

properties of that Casper realistically has is that yeah if an attacker has more than fifty percent of all the hash power then they could do attacks that would prevent you and you blocks from being finalized but they cannot revert any old blocks so I mean you do have this kind of partial guarantee and if we want to make the proofs take sides safe then basically all we'd have to do is just like assign 90% of the e third so like 10 or 20 people that we trust and just run it between us okay so all you know it's it's an interesting idea although it's quite heavy the implantation

tonight but you maybe should explore this a bit maybe yeah so the reason why I was suggesting that maybe we could go down this path is because if we if you realistically want to roll out Casper in whichever heart fork then eventually people need to start implementing it and Olympic Olympic Network possibly have fun Network that fell apart quite a few times while implantations got it right so maybe it would be nice to have a have a test that for this one that people actually want to use to hammer it upon anyway I think but I think it's mostly depends on an individual client

developers actually looking into a protocol and seeing if it makes sense or not it probably is a lot of work and yeah that that's an interesting idea as well hmm okay are there any other comments on this topic cool the next steps if you guys could bring it back to your to your core teams and just kind of discuss this and next week or two weeks from now come back with an opinion that'd be great I think that would help a lot I know something like copies collection but it

is not actually coverage correction I wiII be very used only when and when it's inside its core core the contract which will be which I think that this is about a different topic if I'm

understand I'm currently with the opcode if you could go in and put this on the agenda and the issue section github what we can do is we can move this to two weeks from now where this might start being discussed if you could do that please oh thank you so much so there's nothing else on the proof of authority test net the next thing would be the core team updates so we can start out good pipers joining actually well wait till he comes in and we can see what he was meaning on that and we can just go over what we just talked about hey Piper can you hear us hey Piper can you hear us

I can yes perfect we actually were just on your agenda topic for a proof of authority test net unification so we went over the kind of the basis the fact that there is rinkeby that runs on click and covin that runs on Ora ranked B as headers based Kovan is contract based and so we were either thinking maybe having a third proof Authority test net or if the goal is to have a cross client test net in general maybe moving on to the Casper test net that's already built in Python and having that be one of the

second option for a cross client test net so when you put in that agenda item what was your intention yes was actually just to form a small group out of this route to figure out what a common proof of Authority based test net but everybody could agree upon was so I was hoping to get somebody from the parity team somebody from the DOE team and somebody from who's familiar enough with the Casper research at minimum and then and then we could sort of take it from there and then come back with an idea yeah I think that's a great idea so go team parity team and Casper team

if you guys could go back to your teams and get someone to reach out to Piper or we can coordinate through the all core devs getter I think I think that can definitely work out and we can have like a separate Gator Channel you guys will maybe contact me directly get her as a good way and we can set up a dedicated channel for this perfect any other comments on that Piper or anyone else that's the extent of what I wanted to get done on that topic perfect alright great so let's go to the core team updates so

let's start with go I guess any and basically these updates are not for any hard for it's just anything you want to give a shout out about the project anything you've implemented or justinep any news updates so for now we are just so the most interesting update that I could give is that Felix is working on on somehow figuring out finalizing the EIP way sorry IP proposals for the for the new discovered protocol and I'm kind of really looking forward to that because that would actually allow notes to properly find each other instead of

kind of looking for needles in the haystack but I think that's the and that doesn't really have to do anything with coherent development but I think that's the the most interesting thing that that could be as interests to another body great C++ with Christian right looking for the undo button I think okay no problem offer you anything with with parity no not really we have some changes in our

team structure so some core developers are not available anymore for the parity serum client but we probably noticed that you're talking to a free or Mike instead of Akari and on the code side we are doing some major refactoring and we are having some upcoming code audits so much there's not much as I can bring up right now okay sounds good and did you say that was mark are you um probably Mike okay great I'll keep that in mind thank you um let's see a theory MJ SVM I think that the KC or I'm trying to see if anyone

else in the room myselfin an axe if we've been XX proposed a road map to the to an e Waze and test net I think right now we're aiming to get that up and running sometime in January great etherium J and Mikkel we have faced with database issue which causes a couple of annoying things like huge memory footprint and the processing is

getting slower so we are working on actually we are doing a research and we think that it's a good time to switch database engine we are looking at drugs the B so this is the most important and the only one I think we're working at the moment yeah so in the next release we will have we're going to have maybe a new database engine we also implemented a snappy compression so okay something like that awesome sounds good um Piper let me know if I'm saying this

wrong but I believe that the client portion of your codebase is PI EVM maybe we've got another name in mind but I'm not quite ready for that yet but its first this probably EVM goes we've got the Byzantium rules all passing in tests right now which is an awesome milestone to hit and the networking code for running it as a white client is coming along really well so things are moving forward and we have a general plan with the Kasper research team for starting the initial parts of them migrating from the PI um code base to PI ABM all right and then Vitalik pi

F app not much on the PI you that front the main thing that were although I know that the guys that are working on the test on the Casper tests that are working on the test that and that will involve probably some improvements to PI you have the stuff that's already happened is basically Python 3 compatibility other than other than that most of what I personally been focused on is more Casper and sharding research stuff which is nothing very big but a lot of progress on small things including like Casper incentivization

stainless client design Merkle tree optimization gas rules and a few other things there is like about 5 or 10 threads on the Youth Research Forum ok great and then yo Ichi I know you're working on a number of projects I think bamboo and maybe Isabel not sure if that falls into your field that you have any updates for your projects that you're working on the research qualitative meeting so the specification so I'm now trying K AVM as a specification I find this very simple pull request to see how it's going to demerged and I'm reading

it through trying to quick typos and Sol [Music] accountable safety proof for the more realistic setting where the validators it can change okay great I think that was anybody else in the room have any relevant updates to their clients or projects all right that's the last Genda item does anyone

have any other agenda items that aren't listed what done you forgot the fbiís item he added one agenda left comment let me check it so there his question was whether we could have just a general idea of what we want to include in Constantinople not specifically IP is just in general that's a good idea does anyone want to comment on that I know that the talaq was kind of previously leading that conversation when we were discussing this during Byzantium so I'll have that Alex started that anyone else can chime in I'm not sure I have any new thoughts since

Byzantium yeah well what were the if you could go over kind of the thinking during Byzantium about what you feel should be going in and Connor what might be right so the behind the ideas I had or basically to focus to a focus on state size control stuff so I had those um downsides deletion and like basically like dust the kills clearing I'm yeah if he's the gaff made way back in the day and if one thing we could possibly do what's the next step for that is to just cut down no or just do analyses and see you know like or

ideally even just basically put out a sorted list of all accounts with their balance and then we could just see you know ago like if we cut out all the items below some balance threshold than how many would be left which could be interesting aside from hmm I can give you a list I mean I can generate you one of those lists in okay yep sure that would be great otherwise the other thing I wanted to do is could try to take this time to make better implementations for the elliptic curve stuff beast for like

the freaking house that we did so that we can reduce the gas costs to something comparable to the detective I don't think I had any a particular kind of big ideas aside from that cool alright anybody else have comments to that or things they add on that they might want to see in Constantinople yeah I think it's important to have something that does help clean up the state a little bit and additionally anything that needs to be implemented to

help with some of the future changes particularly abstraction if we're still going down that path or yeah yeah probably just go ahead oh no that was that was all I had okay for abstraction I could probably keep thinking about it more the main debate is just like what version of abstraction with a abstraction I think one of the things we we need kind of to debate first is that bothers me the most is whether we allow a transaction to be included multiple times and what the

cons are mostly what I'm personally worried about is that currently at least a single hash so every transaction is uniquely identified by a hash same goes for a receipt so hash can uniquely identify when it was included in a block if we allow a transaction to be includes multiple times then in theory it can lead to multiple hashes sorry no it can lead multiple hashes mean to reference the same transaction or oh Jesus Christ is mixed up so it can lead to one hash referencing multiple transactions and this may be a strange thing for people in general it may break software so I don't mind doing this but it should be

really really clear that we want to do this and what effect it will have yeah I think the reason the original account abstraction and the IP allowed for didn't require unique hashes that allowed for the same transaction to be included as multiple hashes was because it it was sort of a half step to avoid changing the transaction format so for you the reason the reason why it allowed it it allowed in you I'm a hash to be a curse to occurred twice is because it also tried to abstract the

non scheme and the problem is that if he abstracts a non scheme then it will be possible for someone to create a non scheme that accepts anything so in which so if we wants to avoid that then we basically have to have an abstraction waddle that still forces the non scheme they continue being in effect yeah I guess the question is whether the non scheme is a good thing or a bad thing yeah that can be debated this may not be the place for this sort of debate but is it not I know I'll do this on any IP I don't want to sidetrack us mm-hmm no

worries okay any other comments on kind of the abstraction piece here I guess the more general question is whether in an account abstraction yet he is in scope for Constantinople or and the current one is 86 the only ein talks to there that proposes a way to do account abstraction an indention origin abstraction what for example if we if we keep the non scheme somehow and we we

still enforced an a scheme then we still can do account abstractions simplify stuff a bit yeah so we still can have account abstraction Constantinople we just need to figure out the nose first yeah pretty Byzantium I think everyone got hung up on 86 because of the non stuff so maybe coming up with an alternative EIP that yeah I can do that okay perfect Vitalik if you could do that that'd be great okay without getting into details I can maybe say the high level thing of what I was thinking of which was whether we can keep the nonsense traction but keep the invariant on transaction hashes

being required to be unique that's a terrible idea because it basically places the entire waste of historical transaction hashes into the implicit state third point one more thing if that is something that the EIP broke or or almost broke I think there was a version that maybe fixed it is that currently to calculate the address of the contract the deployed contract we only need access to actually the sender plus the nonce and I think the the proposed a contra account transact abstraction thing also required the blockchain state

to figure out the deploy address and I think that's problematic if you are for example out of sync or if you are signing the offline transaction or stuff like that so I would very much prefer if we could have contract address is generated in such a way that you can do it without having access to the block chains of that does sound like an interesting idea hmm all right cool any other comments on this but the other question besides whether account abstraction is in scope for constants you know what would be if changing the transaction format which

might be useful in achieving account abstraction so if if changing the transaction format is in scope for constant snowball so that would be dependent on if we're doing abstraction or not or would that be something that would just benefit I'm adding a fraction little we be done without that I'd say okay what but it could improve it is what case I'm guessing yeah could be done it could be done without it but it could also potentially be a much cleaner if if true if we are willing to change the transaction format okay right all right here there's if if change is really warranted for I don't think it should be

that much of a problem since for example with in Byzantium we already change the receipt format which means that clients already support working with two types of receipts so doing the same thing for transactions shouldn't be technically too hard but of course it's nice if we don't it yeah it's also not just clients it's all the web wallets like my integer wallet and so forth yeah most problematically the hardware wallets but I'm guessing hardware wallets will have some issues with the abstract that counts anyway so that would be interesting yeah so getting them in on the conversation I think would help a

lot I I know that Lee and the team from my ether wallet I'm sure would love to be involved in the conversation so once an EIP is that I'll pass that along to them if they're if there does become an EIP the specific to modifying modifying that you probably also want to ping let your own presser that's true yeah the hardware wallets are definitely gonna want to be involved okay cool anything else all right cool that was the last agenda topic any other agenda

topics or things anyone wants to bring up I'm refreshing the agenda I think Tim was saying maybe discuss a three to six month roadmap for feature and priorities but I think it's still a little early for that since we're still trying to come up with a better process for that and and we just discussed Constantinople which would kind of be a road map in a way for the next hard fork so I think that's fine and then some people are interested in discussing ether recovery or ether rescue or whatever people want to call it options my understanding is that parity is still wanting to take point on coming up with some of the

either a IPS or strategies surrounding that so at this point I think it's a good idea to wait for parity or other people who have a high stake in this to come up with public proposals yes we are right now so much news right now okay sounds good all right since there's nothing else I think then that can be the end of the core dev meeting thanks everyone for coming and we will meet again in two weeks take note that because of different time shifts or daylight savings time or whatever across

certain you know countries to adjust it because it's still 1,400 UTC for the time that the meetings happen see everybody in two weeks everybody have a good day [Music] [Music]

[Music]