All Core Devs - Execution #30

Transcript

that's good I think we are now streaming let me just ask the group are we streaming okay great I think we can begin everybody the welcome we're trying to miss time because we have a limit for Google Hangouts I hope that that's gonna work this will be a test run we have a lot to go over today so I'll just jump into it we also have some new people joining so the first thing is gonna be testing updates I am not sure if Casey Ryoichi or anyone else has any testing updates but if you do you can one of you

can go ahead if not we can see if Dmitri joins later so nothing particular for me I'm still doing byzantium episode difficulties okay sounds good so next we have digital cats cause network congestion so let's talk about kind of why this happened and some of the proposals around making it not happen again so the first thing is why

did this happen and what solutions are available so why did this happen I think it's just because there were a lot of people sending out transactions for crypto kitties what is there anybody who wants to kind of elaborate as like a overview of that I mean from a technical standpoint it's pretty simple the yes limit was six point seven million and it is turned out to be an application that had you know what 102 million yeah I guess for a block worth of demand and that's what you said job usage is 11 turns actually it started going up then miners some of the councilmen a bit and it turns out they used to just grown even more and there were any feelings on

that implies for basically fall mm-hmm okay great the first thing so sub-point B as the first idea for something that could help with congestion as stateless clients if you click on B it'll take you to a comment someone made let me see who made that comment there who know that's right Vitalik I think you talked back and forth with him about that do you want to kind of go over that and I guess if it would work you also wrote a blog post on that I believe yeah sure so basically I you know like I kind of have been popularizing the CLS coin

paradigm a lot lately because that's the direction that we're going I'm going in terms of shorting research but like and for those who aren't aware the basic idea behind sales volumes that instead of the client storing the entire space the clients would just store the state route and it would be the responsibility of the section senders or at least a miner to basically package up along with the blog for the transaction the witnesses which are basically Merkel branches that prove all over the parts of the state or the defendant cents a transaction access now I did the math on this and this is theoretically viable

but like in order for the really viable it does require a lot of fairly substantial changes basically because like even after the that we did in very in forestry beggin the gas caught for updating the for the gas cost for accessing accounts are just like weekly small so I did I think the math and I made a Normie to apply to LXE post let's see here if I can just find this right now but like basically it's like there's

two there's two things that make well they're sleeping to make it hard the first thing is that our patricia reott actually instead of like from so one of the idea one of the things that i had suggested resize suggested in further we are we research is the possibility to access such accessed reno has been parallel that's the database optimization just bumping bumping up cash sizes let's see yeah yeah he lost the risk commented that it will be

really really nice to do a sink in an HDD well that's pretty much never going to have an invoice wish to look they look plain here at i'm only state gb document rights to disk cold once per block yeah right so the one the one idea that means like oh yeah there's basically a few ideas in there some of them involve hard work some of them don't the idea that involve hard works basically has to do with sort of bumping of the cost of storage read and particularly bumping up the cost of

storage reads in those cases where the they go to cut they go to contracts that have really big hunks of code v him i so the idea said don't require hard forks probably have to do well the first thing that we do need to know is like basically how much what what kind of game can we make from a paralyzing just breeze because if those games are large then there's a lot of things we can do you know including yeah g 648 including different kinds of witnesses and so forth so that seems like something that's really worth looking into there we go can here's my comments on stateless client banned list little

paste that into the IAM alcohol for deaf skype okay thank you can you all still hear me [Music] hey can everyone still hear me yeah great my internet has died so I'm gonna stop everyone's video for help with that and then I'm also going to try to reset my internet so I'll move on to the next topic before that then so does anyone have any comments on what Vitalik just kind of mentioned so the next sorry to

find the unmute so would this involve us issuing you know if we settled on one of these options that was a hard fork are we talking about doing something specifically for Network scaling in the shorter term in terms of forking not that we have a plan to do that right now but were we to settle on that is that something that we're talking about my own opinion is that that if there are like low effort things we can do than we can wait a mintue content to Noble and if it's valuable we can try to make Constantinople slower and or smaller and plans waited in earlier look it because we depend on I don't I don't hear a

Chanel to like starting or crack screaming and ends up boiling or heads off into and doing and like doing some kind of emergency change but like in the if there's something imprudent that we can agree on in the medium term that or that I think that's totally fine sounds good ideal for it so regarding that this once they update from the various client clients developers just like various optimizations that they're dealing whether it's like

garbage collection on disk eight caches but never really did anything yeah that's actually so the next few items are kind of over that with the if there's you know sequential disk bandwidth problems and things like that so Before we jump into that yeah let's see if but since the last meaning or the last few meetings if there's been significant changes to like metallics and garbage collection I know that parity is switching from rocks DB to something else so if someone can elaborate on that a few other things so we'll start with the we'll start with the parity team actually so if you can just yeah give an update for any client optimizations things like your database switch all that I'm sorry my donut yeah parity is

switching to own custom database layer it's called parity DB and I can not give out any technical details right now it's on github you can look into it but I don't know exactly what's the idea behind but we are at the limits of what our rocks DB can do and we try to find you in it over the last six months but there's not much room for improvements so we have to totally switch out the database layer okay great yes ok cool off to look at that

anything else parity worth mentioning Oh any other client updates or optimizations you want to talk about no just in general we'll be having a hard time to keep up with this your main network and we are working as we can do to fix any issues as they come up but it's getting us a hard time okay no problem alright so next let's go with the guest team Peter I think you're on

yep so I know that Nick's been working on on some potential basically not writing so much out to disk which should have bit but I think he's a bit stuck on on an issue but so that we're trying to I'm not sure that the parity I think mark is already doing something similar but the idea is that what we would like to do is to keep the maybe the tips of the last state gifts of the last 100 or so blocks in memory and maybe write out only every 100 block and the idea will be that this would raise the memory requirement a bit but it should reduce this sky of

significance thing it does produce really nice results or at least did produce a preliminary test I think we kind of need a proper implementation or I can give you other details but maybe perhaps make hats more infos on it other than that we've also looked at various other databases out there now we also way back we tried Rocksteady and that one didn't produce any noticeable difference for us we tried we looked at norms we looked at some badger DB or whatever it's called we did up until now we haven't found any for example any

database replacement that would just automatically solve our problems we do you think about rolling our own database a few times but we didn't find or have the capacity to do that and we figure that there are better optimizations to work so I'm hoping that because we can get mix next of bashed-up eventually for the next release and let's see now that folks so Peter Aleksey on on the agenda posted very recently that would it be possible to have some optimization improvements if the background miner is disabled and he said something else about readwrite State and from this key

value pairs directly as well as says try structure which will require order of magnitude fewer reads I'm not sure what he means by that but um as far as disabling the miner in the background would that help of course it does help so disabling the miner in the background basically it means disabling the ending state so currently whenever a new block arrives GAF constructs a pending stay basically the next block that things should more or less appear the only issue is that if some people realize until rely on the ending state then we still have to compute that so so the only way to effectively speed it up for everybody is

to drop support for generating not only sure people would welcome such a drastic sorry drop support for generating what pending state pending state mmm so currently we have a lot of AP is that that rely on the actions happening you can not of course you're actually processing the current block and those

think really that meaningful like these days compared to what compared to the head state of a shame especially centroid which someone else and send the transaction and totally possible they like goal out completed on the on gas price or at all or that transaction or I can eat you on yeah sprays like can be meaning soldiers when users singing a series of transactions to a single oh yes right if it's a here's the transaction to make them personally I don't think the pending state is meaningful because it is limited by a blocked number anyway so it means I'm

one hundred thousand transactions waiting them basically you get the next 100 which is just a random slice of the family presence and and the rest won't make it entertaining stick like that not that you get any single transaction take you down execute so in essence what I was saying is that personally I don't see the value in the pending state but we we never wanted to splain simply drop support for it because you who depends on it and where and why but maybe I'm I mean I'm open to opening an

EIP and basically just dropping support for accessing the pending state okay any other comments on that anybody great but Alec I'm hearing some scratching in the background is it like standing mm-hmm okay if you could just mute when you're not talking then I think it'll be good oh sure thank you so next on the agenda we were going through the clients CPP aetherium any updates or relevant optimizations no

major updates from us but we also have some work in progress around refactoring the database layer and that would allow us to easily change the database through so we I think also plan to experiment with that maybe to some database of the musicians as well apart from that part of recently implemented this script to to proxy HTTP RPC request to IPC socket so that allowed us to get rid of the HTTP server in the client this theoretically could be used with other

clients too so I think he continues to improve that also we did some improvements in the common line user interface and I'm working on improving the experience of downloading the link bird in the snatcher I think that's it yeah Thanks that's that's good atheria may s any updates on that no updates still looking forward to he wasn't just doing a lot of maintenance and merging open for

requests and stuff in the in the meantime great thanks Casey harmony it's interesting track that parity has moved from frogs DB to their own database engine cuz we are moving from level db2 rugs to B so we are on the right way to create our own database yes okay so we're almost done with that I need to finalize change because the main scenarios with the database works and we also had to create new pruning mechanism

because old one was based on reference counting and we got rid of reference counting so we have to do a couple of tests and benchmarks and if everything will do a case then we are releasing next week or the week after the next one at the beginning so yeah and after that we are going to focus on the Gasper tests net so that's it

awesome thanks and you mentioned at the very first that you're actually switching to rocks DB is that right yeah we're switching to rocks to me okay yeah you might want to talk to parity if you run into problems cuz it sounds like they were having issues with rocks tbh I don't know if there are different implementations but I guess they don't have and it's not like they have an issues but they just got all that they could from rocks to be and rocks to be is not enough for them as I understand so as I can see so far rocks DB is okay for for us for for for the

harmony so we're doing with it okay great um let's see PI via yeah nothing interesting for report we're just churning away on getting closer to a early alpha release but um same standard work being done just turned away at it cool PI etherium Vitalik is PI etherium worth mentioning at core dev meetings or is it at a point where it's being moved into pi vm o metallic I think he still might be muted

yeah sorry I'm not at that point okay sounds good I believe that's the last client so that kind of went over some of the optimizations that we're talking about and let's see so if we go back to item 2 and some of the sub points oh yes was there a client report yes there was a see Phoebe Klein report they were doing some database changes yeah what about tests yes we actually testing was item number one and no one had any updates really could you give us some updates on testing the meetry yeah I'm

currently working on changing and that source format intern llamo so we now could support tests in the llamo format and in that format we could use a multi-line and to describe some contracts code and that would make it easier we could write Julia for example and this this should be awesome you should look at them if you're on a test repository so we could discuss a new test format maybe you have some thoughts how to do it properly awesome so what does this mean for the clients are they gonna have to do some

immediate changes in order to nothing because the final test won't be changed so it's still JSON final test tube will be Jason it's only affecting the test sources so those who write this they could use a Yahoo and they could describe a better test with proper comments and the multi-line for writing at contract source code okay great anybody have any questions or comments on that alright thanks Dimitri okay so looking here so I think this might have been I

guess tan generally discussed by everyone updating their data bases but a sub-item D is is actually sorry we skipped C would having minimum system requirements to help set up an optimal client or full mode help who did that one oh my cat just jumped on my monitor it went off okay it's back on anyways where is that yeah so just it was RSA management mentioned if there's like minimum system requirements to set up an optimal client node hard drive is one of the most important bottlenecks okay that's actually gonna go into our next item

so our next item is is there a bottleneck not just on disk bandwidth but on sequential disk bandwidth and I believe the taliking you commented on that was there anything you wanted to add um yeah so basically you I was just wondering like whether so we know for example that an SSD re was that an SSD can do one SSD reagent you know in about 100 microseconds but in order for an SSD to do 20 SSD read where we know what all 20 of the keys are advanced was I'd say 2,000 microseconds or as I think much more it does microseconds because the answer that question can vary

significantly impact like what we'd end up doing from a scalability standpoint both and there was a coin implementations and for any client devs have a comment on that like any opinions so if I understood correctly have we ran were you asking if we've kind of run tests for SSDs versus hard drives or is it a little deeper than that no no I'm just asking RSA or

random SS eries parallelizable so if you have 20 years that you want for like 20 locations that you want to reaffirm in SSD then first of all can you do that can you do that in less than 20 times the time that it would take in order to just the do a thing over you and then if the answer is no well that is that would makes me sad and if the answer is yes and the folo obvious well does that transcend these kind of going up Siddal of the the level of like a level DB or some other DB I'll call for an answer yeah and then and I kind of and then on top of that I know I can't translate into like either you and multiple tree

reads in parallel or ideally some way to do the different parts which we read in parallel or public somewhere okay it sounds like we don't really know so that's something that we can look up for next time random google search on it gives back some results that say that usually reading concurrently on an SSD on 16 to 64 threads are quite beneficial and they can they can be a lot faster than sequentially reading stuff so if you are really multiple stuff from an HDD at the

same time it says that AUD is about twice as fast and SSD can be done 230 times as fast now the question is of course so if you are reading and writing these massive database so is level DB database and others usually they write out entire blocks and I think they can pretty much saturate bandwidth pretty nicely on SSDs so in theory they are fast in practice it probably depends on the load but it's definitely worth investigation thanks Peter we also get the benefit that we we might be able to

do database reads while would do computations right so if we if you know we're at an actual load stuff from we can preload it into our cache while we process the transaction before that something like that okay so Alexi just commented on the agenda if anyone wants to refresh their page and he said that he can do experiments with parallel SSD reads if we if we want so I said that'd be great thanks so thanks Alexi if you can do those and then comment on the next agenda that I'll put up today or tomorrow that that'd be really cool so one of the important things to keep in

mind is that at least for Goethe reom often the block processing time boils down to database writes right bottlenecks and for example leveldb compactions compacting and his right house terabytes of compacted data I'm not sure parallel reads will matter so you're sure but it specifically writes even more than reads that are the bottleneck right now mmm I think we both are the bottlenecks and leveldb has this so the the design of level DB is to create a stable stable stream of data

which means that it doesn't give you data back as fast as it can or it doesn't write out data as fast as it can rather it tries to be stable so if there's a static form a right cue then instead of writing the first three items immediately in the last three items one minute later it tries to spread out the writes and spread out the weeds and throttle them so whatever whatever you are benchmarking these stuff and you see that there's a big lag on reads or writes many times it may be simply level to be throttling because it's busy doing something else or just throttling it's basically I'm just saying that it's not trivial to benchmark the thing

okay okay great I think I think we're good on that anybody else have comments okay great the last sub point for two is vitalik having some ideas on gas cost changes and scalability relevant client optimizations we've gone over scalability relevant client optimizations a bit Vitalik if you want to go over anything else from that comment he left the gas changes and whatnot I mean I don't think there is anything beyond what said what basically the point is that I still think that state reads the render price that's what everything boils down to any like if like service like if there were

two things that I could do to improve etherium said well if there are three things I could do to improve etherium scalability that are fairly quick one of them would be to increase like further increase the price of reads because those are probably still be dominant on sector the second thing is something like ecig 48 and the third thing would probably be if some collect the two states clearing or like X go inside the strain yeah I think it was like 168 169 be ended up wearing one and what is I which that EP were referring to 648 a sterilization and then like if there was

a fourth thing that would obviously be like basically making reads even even more expensive and improving the more country and then making sailors clients liable but that would be it and that's obviously I've been a bit harder to do backwards compatible okay got it anybody have comments on any of that no well regarding making reads more expensive it will be interesting to see how that would actually what the effect what the impact that would have on the on the last life period where it's been

so full transaction and if all those transactions would have taken more gas or if we could have yeah we would just have spread out the spread of the transaction onto more blocks and made the situation worse over the situation has become better I mean it's like I think that like in general right the only the purpose of repricing operations is I think more to improve the worst case and it is to improve the average case like I think there definitely are ways where we can encourage developers to meet right they're smart from their contracts and ways that are better and

we can kind of improve improve incentivization better but the more important thing is also like I think like we do have to also be proactive about like thinking about the case where there where there is an actual attack on the network well I think so I think the risk of an attack is ironically enough less than it was a year ago mainly because like at this point in attacks that even feels like a sort of for gas usage was just enough driving transaction fee is up to up to two dollars and would burn through you know millions a million dollars in a few days but even still it's worth being concerned about okay great anybody else okay so last thought for me

I think off chain solutions for crypto kitties it was part of the thing that could help solve at least for them specifically some of the scaling issues and some of the network congestion issues so things like state channels I've heard that kind of being thrown around as a solution so I thought that was interesting so anyone looking at like how to fix the network it's basically client optimizations future scalability improvements like blockchain charting and then off chain solutions like state channels that can be combined with other things to increase increase transactions yeah yeah yeah I mean like I guess I've kind of informally considered like each channel

solutions out of scope for the court house call because they don't work don't require anything any a consensus solely or layer Network layer changes they're kind of separate networks that are links to etherium but like there it's that that's definitely something they like developers should be holding very close onto their radars cool someone on the agenda asked about quantum resistant cryptography and plans to include it and I think someone said that account abstraction is necessary yeah well okay technically it's not necessary but like I personally don't see the point in trying to create one specific quantum

algorithm I think we might as well go straight for account abstraction and we can tell him that like that's already already going into Kasper and well okay I've got abstraction going into Kasper is forecast for signatures and then I can with abstraction breakdown that actually is something that I didn't want to bring up because like there was that each research thread we only have about four or five different proposals that I actually think do a better like substantially better job the name anything we've had before us and a balancing between me um having as a little complexity on out of consensus

and having as a little income points that he in front of two thousand sort of thing at the same time I don't know how to did you see that research bread yet and if if not I couldn't try to find it yeah if you can link that into a chat that'd be great or into the zoom meeting or something like that but um and yeah I think that that would be good great any other comments okay cool all right listen of like actually like ask

people to try hard to provide feedback on that over I mean like we sent the the next few days or so well like it could affect both the sharding roadmap and like it seems like what like if something sensible get stopped at a crib and it would it would make sense that the mainline in the medium-term as well hmm okay great can someone post this in the zoom chat my my get her client crashed but if someone could post that link and zoom for those who aren't in the coordinate chat that'd be great perfect Thank You Martin okay so yeah people could go and comment on that that

would help a lot the next item is introducing the KA VM team and Kay Viper team so we have Everett Hildebrandt and we have let me find I just met you this morning Bayesian Park yes thank you guys so Everett if you want to just to introduce you to and what KVM and k viper are and just kind of give a general overview that'll help us lead into the next discussion which is a follow up on the yellow paper okay can you guys hear me fun yes we can okay well the KBM was a well is a formalization of the ethereal virtual

machine in language that are reports on which is K K is kind of a operational semantics framework that ends up giving you a bunch of software development tools once you've specified your your languages languages definition and K so what we did is just formalize the EDM following the yellow paper almost directly and when we were confused we looked at source code in the various clients but yeah and then now we have we have even branches I think for the Byzantium update although there's a bunch of unmerged branches in the K repo right now because we've all been kind of busy with school stuff just end of

semester things and and wrapping all that up but more recently we've been looking into supporting some higher-level languages so back over the summer there was kind of some experimental prototypes in that direction just extending the EDM with some high-level languages and more recently de Jun has been leading efforts on making semantics for Viper well maybe maybe not leading the direct semantics efforts but he's certainly working a lot on the semantics of Viper which we originally gave semantics in terms of a translation to EVM so maybe dejan can talk a little bit about that or quite

young you hear me yes so yeah so yeah I'd like to quickly talk about the our project for the Viper so the our goal is to provide some formal tools for the Piper language so as a first step we follow lies the the language semantics on the top of KM specifically we formalized actually the the piper compilation itself so roughly speaking if you think about this has a translating its own implementation of the viper compiler into some mathematical definition and inkay so

which means that we kind of - let me get another compiler a Byford compiler so that you can cross check each other to test them as a good side effect actually we found some bugs in the production compiler also helped to improve some design of the language by proposing some new features so based on this based on these therefore more semantics we are right working on two tools the formal tools one is the verifier for the piper programs and another is verifier for the viper compiler itself so let me introduce a little bit details about

these tools so the first by for I mean program verifier or the by programs is that we actually have some the core engine for the verification but we'd like to make it more usable and is used by the contract developers so we are thinking to provide some annotation language features into the piper programs so that the contract developers can describe their intention of their contract into their source code and then actually we can take the source code annotation and verified it the properties are satisfied by the program contract programs so right now we are using the ERC 20 token implementations

by Philips as a testbed for our verifier but once we have done this we are thinking to move move on to verify the Casper contract as Petaling proposed database program verify your idea for the verifier for the compiler so we also have inque a kind of program deck inference checker which means that which takes two programs and checks that they are equivalent or not so using this program Givens checker actually can verify that the piper programs and the EVM programs are compiled down to from the piper you can verify two programs equal or not

which means that you can actually verify the compiler is correct for each instance of compilation another application of me using the program difference checker is that suppose you want to migrate solidity contract into piper then you want to make sure that actually by four programs actually equivalent with the solidity one so what we can do is that we take two if program to IBM byte codes we want each generate from the each language and then it can actually verify their - EVM programs equivalent which means that you correctly my created the original

solidity programs so that's the compiler verification idea so yeah we are working on these two and then hoping to finish in a short time and actually we released a yeah yeah actually a fillip posted the link to that so fill it right down right off the blog post about this while you've done and we are really thinking - plenty - so yeah please check it out I'll try it alright thank you so much for the intro there anybody have any comments on KVM or any of the other stuff it's also worth noting and let me put a link to this in the in the chat so

maybe someone can afford it - the Skype channels we also have essentially from ke VM this compilation - a web-based and and human readable hopefully eventually documentation of the KVM semantics so we're kind of calling this like the jello paper it's meant to be sort of like the yellow paper except that it can be fully compiled into an implementation for evm right now it's like sort of early stages it was compiled directly from the existing return to KVM semantics did you just cut out I know we could still hear fill your internet everything anyway so so yeah so the idea is essentially to be able to compile

this jello paper into a full implementation of the EVM that could even potentially be used in a client one day unfortunately right now is sort of compiled from the semantics that we've mainly been for the trooper and for our own tools so maybe for those who don't have a good familiarity with K it might be a little bit difficult to read but we're hoping to get input and continue to refine it until it's completely human readable and also complete executable specifications awesome that's great news and feel sorry I didn't even introduce you if you want to do just a couple sentence in trail sure so I guess I'll get some background on the KVM project while I do that the KVM project is split across two entities right now which is the

University of Illinois where Professor Gregorio Shu is a professor and has a research lab that works on formal semantics and also the spin-out startup run time verification Inc which is intended to commercialize the technologies developed like before his lab so I'm kind of we having smart contract strategy @rv which is like the commercial side of the collaboration and I'm also a PhD student at Cornell great cool anyone have any comments on all that it sounds like a lot of cool stuff going on okay great so the next item is a follow-up to what we talked about last

time there's a link to doesn't remain the case that the yellow paper is intended to be a theorems formal specification that was initially brought up by Ben Edgington so we have been Edgington and here today as well as Daniel Ellison there from Pegasus which is a consensus core client team so actually I'll let Daniel and Ben introduce themselves Daniel if you want to go first and then Ben if you want to just quick quick intro and if you want to mention what Pegasus is if I didn't explain it correctly okay hi everyone I'm Dan Ellison I've met some of you before I work at consensus just to clarify I'm not currently on the Pegasus

team but I'm doing a lot of language research and as people like x-act know I've been trying to revive lll which is actually working out quite well my interest here is languages so that's me great thanks Ben hi everybody my name is Ben Edgington I'm I'm in the Pegasus team within concerns so pegasus means protocol engineering and systems we're relatively new team but they're focusing on core blockchain protocols research and development of course at the moment it's fully focused on the theorem slight emphasis on

private if they're in networks but definitely intention is to span the whole space and be very active in the public etherion space as well so I'm in the research and development part of Texas awesome thanks Ben so now back to the topic about the yellow people paper being the formal specification anyone who's talked to I don't see Gavin in here today but is anyone here who was sent by Gavin to speak about the yellow paper or who has gotten a response together with respect to the yellow paper comments from last time or the licensing of the yellow paper and he said he's happy to put the

yellow paper repository under a Creative Commons license so far he didn't do it yet because he's busy so he's currently considering which CC license so but if anyone wants to help to figure out just reach out to him he said he will be able to do it around in around three weeks so this one out awesome that's a good update so basically Ben brought this up last time and we went through this but um basically the questions are doesn't need to Rene in the formal specification and if not what replaces it I kind of want to throw in a third option does there

only have to be one as long as they're compatible with each other I'm not versed and how these type of formal specifications for this for this stuff needs to go down but can anyone answer the question you know is there a possibility of interoperability so maybe I can say a couple words about that the AVM is testable in executable so if you had another executable or testable specification you could check interoperability of those two or you could check agreement of those two specifications but I don't see a way to mechanically check conformance of the yellow paper with other executable specifications certainly though could

try to kind of get a merge of the two because the yellow paper has a lot of useful English prose and and other high-level overviews of the EVM that help implementers and certainly helped our team to implement the KVM so I think what Philip was saying earlier makes a bit of sense essentially have an executable specification that also is human readable now I think K itself is human readable but I don't know if other people think so so I think it's probably best to kind of get more English prose style stuff in there for people to get a better overview of the of the whole thing at once yeah I agree and I also I

don't think it's necessarily a bad thing to have multiple specifications especially if client developers are aware of that but you also don't want to fragment efforts too much like it is nice to have a very small number so they can all still be audited and check very thoroughly every time they're updated I know at one time Gavin had a yellow paper committee that dealt with the responsibility of keeping the yellow paper updated I'm not sure what the status is on that maybe we can talk to Gavin if he can attend the next core dev call or just offline or off call talk to him about it but I think something like that in a collaboration between KVM and the yellow paper would be good now for general discussion about this anybody

have any thoughts on if it should remain the formal spec or anything else about what we've been discussing me running public so an open license is kind of vidi-vidi important it's a bit surprising the yellow paper hasn't been licensed so I believe that's the first step for first step for the yellow paper side KVM so I was reading the master branch of KVM for a while and the Byzantium changes hasn't hit the master branch yet so and yes in

some cases the English state paragraphs very short they look like comments to the code so there are death some work to do but JVM has already got the license so people can work together to make it better already okay great so it kind of just sounds like the the destiny of the yellow paper is up to a certain extent to the yellow paper creators and whether or not it's licensed and I and I agree with you that's a good first step anybody else have comments yeah we'd

love of course to also move ke VM to more like foundation ownership so you know the domain the repo whatever I mean if you guys want to take control of some of that it's pretty much cool I could hook you up with some people to talk to about that since on these calls I don't represent the foundation but I think metallic and other people would love to help with something like that on the other hand if this EVM semantics is still in the Kay framework organization then every time the Kay framework itself is upgraded you guys will be fixing the syntax and so on and that's a nice thing but I mean it's it's a small thing yeah

we have enough efforts that rely on KD and now that we'd probably do that no matter lived alright thank you anybody else have comments yeah the the other cool thing about the ke BM is that it actually they said it was an executable spec maybe maybe it was already mentioned that it actually runs in passes all the state tests well maybe not all of them but certainly close to being able to pass them all so in the same way that every other client runs in and passes those those test cases the

the ke BM SPECT can can do that as well yeah you can even also use it to potentially generate test cases so eventually it could even if it was desirable to replace something like CPP aetherium for that job I would love to see that happen nah no offence the CPP etherion but seeing the test cases generated by the speck versus just one of the implementations would make me a lot more confident that CPP etherium wasn't the actual spec yeah that's sort of the argument that was made in the KVM paper that the yellow paper is at the human

readable spec but CPP aetherium right now is the actual machine implementable spec okay cool let me see it's Dmitry Dmitry actually dropped off I was hoping he could comment on on this but we'll have to wait till next time okay anybody else have comments so in summary the yellow paper there needs to be some changes over the next month Gavin needs to communicate what the license changes are gonna be and the steps starting for that and then hopefully from there there can be some communication between KVM and the yellow paper the maintainer z' of

the yellow paper so that there can be some coordination going forward it sounds like the KVM is gonna be going full steam ahead and that sounds really cool as well really exciting project guys thanks for thanks for coming on so I think thanks for having us I think that the next item is going to be so I don't know if there's any official statement today but if a free did you want to talk about the parody ether proposal or Yuda I didn't know if that needs to be brought up next time after there's more research and more finalization of some of the ideas actually I don't want to talk about it

except for one comment maybe that we at parity don't really want to follow up on the proposals because we hear the free thinkers clear and loud and so yeah any more thoughts into approving okay great and I and I'm sure there'll be like a formal declaration or even in formal declaration outside of the call but thanks for thanks for mentioning that offering okay great we can go on to the next one then the proof of authority test net unification is there any updates Piper I just leave this in here every time but if there's

not that's okay no there's no updates right now nothing nothing right now cool and we've already gone over the core team updates so we actually got through this real quick guys were 15 minutes before our hour-and-a-half mark does anybody have any other comments questions agenda items they want to bring up that were not included in the agenda okay great so thank you everybody for joining will we will let's actually look at this two weeks from now is the 29th that should work

is there any that's almost New Year's but do who's like taking off on the 29th and does anybody I won't be anywhere near internet you want me there anybody else as long as there's a majority of people I think we'll keep the meeting on we uh yeah I just I guess I couldn't decide like who would be online during that but we can definitely postpone it if we want say that for that Piper you could speak first yeah I was just saying

unless there's a reason that we need to have it in two weeks let's just push it down more week to get it out of the middle of that holiday walk yeah I agree let's bring this to the Skype and get her channels and then I will announce it in the agenda that I post on there but we'll definitely delay by at least a week if not two weeks because a week after that is the fifth and people will still be kind of getting back into the swing of things so we might do two delays is anyone opposed to doing it to a two-week delay rather than a one-week delay which would mean it would be a month until the next cortes meeting well I think unless there's something very urgent or something big

happening I don't expect that most of the court the teams who be doing a lot of hard a lot of work in this and the period I think it's very common for most a lot of teams to taking time some time off and not to some major releases so I don't think it would be a big problem I I agree what is what is four weeks from now my cat is literally covering up my calendar on the screen because they won't leave is it the 12th yes okay let's just have the next meeting on the 12th everybody

cool with that I understand when I ask a question like that if everyone speaks up at once it's gonna be chaos but I just felt like a general all right cool everybody all right thanks we're gonna see everybody back on the 12th and everybody have a good holiday depending on where you are in the world and if you're celebrating bye everybody Cheers [Music] [Music]

you