All Core Devs - Execution #35

Transcript

[Music] [Music] [Music]

[Music] [Music] [Music]

[Applause] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] you all right welcome everybody to the core developer meeting yep audios working let's jump right into it it's been a

month Wow and I'm half awake so apologies in advance let's see if you refresh the agenda which I'll paste into the chat I just added I think I just added testing and that was about it but I anyone wants to look that over let's see and then anyone who's on a phone if you could mute while while everyone else is talking that'd be great so the first agenda topic we're gonna go with testing so Demetri do you have any updates or anybody else in the room on

testing hi ho hello continue developing this RPC Mehta's is a great test tool and i'm upgrading CB client and i found out that some of the tests actually wrong some of the state tests and they're currently investigating what was exactly the issue and refilling those broken tests it is a pull request to the testing repository and if you'd like actually I would like client developers to try out those new updated tests maybe I am wrong maybe my changes to sleepy

client wrong or something but I think those tests were incorrect have you seen have they been acted on hi and how are the clients reacting on the hype I just oh yeah those issues that some of the test might not made it to the hive because older version of test it tried to construct transaction and in some cases the transaction was throwing an exception and then in the blockchain test out of the state test appeared to be without any transaction at all so there are some cases there which

actually I'm just not testing anything just because transaction not constructed in testing so I fixed additional okay but will so well when if you fixed it and pushed it to master we should be able to see we don't see the tank gonna push those state tests in blockchain form to the hive anytime soon I'm using this retest tool now and those tests generated via RPC so both these issues is other issues with cosa

cuz when when I execute the transaction we our RPC on a client it's it's somehow different using the humanoid logic and so sometimes the post date is different like right now I I see that is a mining the word set to zero in the I use a mind block method now and the coin base account is touched and it appears in a final state so it's minor issues like this what scientists differences might might be another okay could you I mean

the test that you think were previously invalid are now fixed could you make a list of those and put it in the old court of this channel yeah those tests I'm committing those tests to pull request to the test repository now supporting open I hope that go client has a state test implemented right yes the pull request number is 437 thank you yeah we can check it out great is there any other updates with testing yep I would add a

bit we had on in the type a meter long huge discussion with with Piper and I thought think also Frederick from parity chipped in a bit at least for part of it where Piper was saying that the Python team actually worked three pi movement ation are using go a theorem and I sorry parity notes in the background to check their the correctness of their web 3 implementation librarian condition and he said that currently that's a huge pain for them to test because essentially it's really really hard to uniformly configure a chain for

different clients and so this kind of ties in nicely together with Dimitri's approach that them so Dimitri wanted to have a unified interface to set up tests for the consensus tests and run them it would be a really nice addition to that if we could actually set them up in such a case that they would also cater for properly testing the artistic methods just because currently there's no unified test suite for our RPC simply because it's really really hard to set up common common states for the nodes so I think it would be really nice to go towards that direction to we something there's a in the interfaces repo there's a

there's a discussion going on I'll just paste it here if I can find it somehow yeah what a rock face is a mod so so we had that interesting discussion and we also had an idea that actually might be had my tab the ecosystem long turn in that and the interesting thing about this test RPC endpoint would be that not only could it actually assemble chains locally and just run transaction and see what happens but it if we have such an endpoint and we that actually can extend it so that it could also export these state tests or whatnot tests and it would be if we have these two-way things

that we can import status and you can export state tests then this kind of becomes a really really powerful thing because all of a sudden we can for example set up bounty page like web service which is a simple interface where you can just configure a chain submit some solidity code submit some transactions and actually have it tested against all client implementations and then it would be a really useful tool for the community where they could just if they for example if I am implementing some quirk in the EVM and I see that this this is a sensitive thing which may or may not be broken in other clients then instead of having to dig through

their source code and either find it or not find it it would be really nice to just I can create quickly a test case and just submit it against all the clients and have it fail or not fail so we're talking about they it would be nice if we had such a tool of course nobody has the capacity to develop such a tool but if we have the RPC endpoints properly spaced out then the rest is mostly just creating a nice enough HTML page or web page ok let's not call it HTML so that might be an interesting thing to pursue what do you mean by export test so basically you have these json text

fixtures or whatnot and to be able to export that I mean just developing a web interface where a user could construct their own test yeah friendly way exporting attacks by exporting it I really meant that for example if I create a test case in in GUI theorem for whatever that it would be really sweet if I could actually export that into a text fixture and just run it against the others without having to actually manually construct the other one the whole thing the web interface would be just something that would be you'd allow the community to actually try and reproduce issues or test issues against different kinds so essentially

my point really with this whole thing was that currently we only have consensus tests for at the IBM and the RPC itself in none of the clients is tested which usually ends up with all the clients have their own little quirks and then we have test RPC and truffle and various other clients just Oh constantly opening bhakta cos that hey this works differently hey artisan cooling in this window Ethan is encoding it that way and weird issues like this and if we were to have some common interfaces or at least we could roll out so that was the plan like develop RPC protocol for the test and any client

with the implementation of the protocol could run the test by using new tests oh yeah but my point was that so the RPC the respect that last time was only for the running consensus tests but the thing that we are discussing with Piper and Fredrik would also allow to after you construct whatever test whatever idiom test and you run it you could actually have a full RPC interface for it where you could actually pull the nose for data and interact with the old example I could ask the node to trace the last transaction that's possible with the current consensus test mechanism well not yet the Newton consensus test mechanism I realize on

our pc fro if you like define test RPC method for tracing the transaction that's it will also be possible yeah but that's not our point that if we if we have to define an API for everything then why not just use anyway we're kind of going into it into the spec details I think that's beyond the point of this discussion now I'll just I'll paste the spec and and everyone who's interested can can actually comment there so we kind of open to suggestion from all the teams because the idea would be that this it is only useful if actually all the teams are kind of implementing something meaningful so it should be kind of a common common thing to do defined all of them so let's let's

continue this discussion on that thread yeah let's definitely work to collaborate on that since it sounds like Dimitri has made and another test standards it probably is a little different than what you guys are doing but just to make sure that those match up as well so there's not a bunch of competing ones necessarily I think I think the meet use direction in general is very good just he was more focused on getting the consensus stuff tested yeah it's my primary objective to make all those existing tests like working again yeah so I completely agree with that I was just so the reason why this discussion came up with Piper is that if we are going towards this direction then

let's speck it out and make it useful for other stuff too so that we don't have to create a second test number to our PC on point in you know okay is there anything else on on testing otherwise we'll go to the next topic okay left terrace wanted to discuss a second 12 and that is involving let me look at it real quick and I'll Emily

agenda if you click the link it goes into the comment that left terrace left and it's about s sign type data so left here so if you want to talk about that a little bit and then we'll see if anyone has comments yeah can you hear me yes we can hear you all right so yeah this is basically an AP for to propose an addition of an RPC method to sign arrays for any kind of arbitrary data so that the sign is you I can easily sort of the user what they are signing and so they can actually be sue of the bodies of we are signing because

right now they just see us and they don't know what that is at the same time we wanted to be machine verifiable so the discussion has been continuing for quite quite a long time recently also Christian loot I think he found him a liability issue but the proposal to fix it has already been made using my new API encoding of solidity and the schema has of essentially the beta without being signed so there is also another EAP seven one nine but I would say is like a VIP but on steroids so they also

wanted to how do you say that to create a provable way to the contract that the user has seen it in a particular way so they can also prove that the UI is so in a particular way not only the values that are signed the reason why I mentioned this is that the discussion has been lifting away and it's going a bit of scope right now and I would like to try and ask for the opinion of people here or people from the community of how we can keep vc AP so 7 1 2 2 s leave in the scope as possible and have it and finalized as

soon as possible since many applications made ups including something that my team and I are working on micro ridin waiting for fight live so with with a lot of patience from quite a few months now that's mostly cool does it have a comment on that otherwise I have one yeah I have a comment and I think it's very good that these things are being specified but I would have liked to see some more people in its discussion and I reached out to a couple of people dance dancing life meta mask and we would have

been good if Nick Johnson or Leakey was here as well to weigh in on it but I think there's a at the moment there are huge issues with the way that we have that the clients signs text and that is also something that needs to be sorted out I don't know if that's discussed within the scope of EEP 7 1 2 how or if someone to is only for more complex data types no it's only discusses I think just assigning like an array of data and types data essentially so the user can know what is the time and what is the

value of that he is signing [Music] put some oh I was just noticing on this that it looked like at the very very recently there was an alternative suggested specifically 191 is that something that could work lift heiress 198 so one night one is it's a pretty old one that I wrote a

while back I don't think it solves the problems and I don't yes an appoint one also suffers from some of the problems that our current sine theta has that it doesn't say how large the total envelope of the messages and there's the kind of malleability in that the way it works right now we have the number 9x19 etherium sign message and then lengthen and the message but we don't have the total length which is a big blunder okay that yeah that makes a lot of sense yeah

there's been a bunch of discussion on this so I think this at minimum is this a draft yet lefteris yes has not been just discussion yeah I see this is a candidate for potentially being accepted at some point absolutely and we should at least make it a draft as a PR so I'll make a note to kind of comment on that so 7 1 2 is a PR and work on that by making a comment on that

AIP does any what does it other people have comments on this right I was wondering I just talked to Liddy and he's installing zoom right now maybe we could return to this a bit later yeah no problem we'll put this on great so let's see what's the next agenda topic I lost the tab here we are okay VIP process updates this also will include the etherium magicians meaning that recently happened so the IP editors have been talking and the first step that we're taking in I guess

updating the EIP is in general is making a really nice interface and this is actually all spearheaded by Nick so I should say that out front it's Nick Johnson is making a really cool Jekel based interface where as the IPS are submitted they are automatically entered into a website that's easier to read and easier to collect the data of the e IPS that's not released yet but a lot of PRS are going into work on that and to kind of edit some of the initially IPS to make their header files structurally compatible with the Jeckle hosted website so that's looking really nice and then after that kind of gets going

we're gonna look at re redoing parts of e IP one to make it a little more clear especially to make a better separation between standard track and EIA our C's amongst other things and some of the stuff we've talked about in previous core dev meetings on top of all that at the recent SCC conference about two weeks ago in Paris there was a group called the fellowship of aetherium magicians that met to discuss some of the issues were having with a IPS and governance and kind of aetherium technical topics in general so lain if you could just kind of go over briefly

some of the stuff that came out of that meeting I know you posted really good notes on at 2:00 so we can have that in the notes for this meeting and posted to the Gator chat and stuff like that but if you want to go over that that'd be great hey Hudson definitely thank you can you guys hear me okay yes awesome yeah so as as you mentioned Hudson I took pretty thorough notes at that meeting and I will repost that link here and in Gator as soon as I finished just give you a really quick overview of what sort of the event looked like looked like yeah so by way of background this is an initiative the fellowship of ethereal magicians that was organized by Greg Colvin and Jamie Pitts kind of spun up over the past few months or huge

thanks to those guys for making the effort to do this and get it off the ground and on the sidelines I shouldn't say the sidelines it was actually a workshop at ECC a couple of weeks ago the first meeting of the fellowship was held it was a personally speaking a really positive experience it was a very very full room I don't want to put an exact number on it but it was on the order of probably about a hundred people in that room it could have been sixty or eighty many different groups represented so from throughout the ecosystem which I thought was really excellent it was a lot of kind of high-level meta discussion at this stage given that it was the first meeting so for example Greg shared some stories of some of his previous experiences participating in various consensus based decision-making

processes there's a lot of high-level conversation around the status quo things like how the IP editors are chosen today how the yaki review process works the hard fork process and basically generally how we can do better on those things there was also a lot of experiences shared with how other groups do things which I personally found helpful so for example IETF the internet Engineering Task Force I hope I got that right has some interesting processes that they use holacracy is another sort of consensus mechanism that some folks may have heard of we discussed that we discussed kind of the role of the fellowship of ethereal magicians and and sort of you know the fact that it's technically focused body led by developers and whether there's a

need for a separate process or body to discuss kind of the political side of things there was some conversation around how to get more voices involved right so even though there were as I said on the order of 100 people in the room obviously not everyone participated so that was something people agreed as important and generally consensus that meeting in person is important right that you know flame wars have existed since the beginning of time online and coming together and meeting in person and showing our faces a few times a year is a really important process part of the process of building consensus and sort of the outcome of this meeting which was intended to be preliminary is that there will be a larger event I don't know called a workshop or something which is very likely to happen in Berlin around July and there's a

little bit of a question around how its funded and whether you know some organizations are going to stump up some money to help people who couldn't otherwise come forward to attend as I said I will share the link for those notes again here in the zoom meeting and also in Gator ok thanks very much Lane is there anyone else who attended or has comments on the meeting in general hey everyone my name is Raul Sohn introduce myself I'm part of prismatic labs and we're building the first charting client or again we're currently we're currently in the typing charting workshop this past week and we will be hosting a

meeting discussing our implementation for phase 1 of sharding happening tomorrow at 11:00 a.m. GMT - for if anyone is interested we have a prismatic lab skidder channel where we will be will be discussing this information and putting out a comprehensive road map of our first development Sprint's to get it into an example of phase 1 working so I just wanted to jump in and let you guys know what we're working on you guys know that you get this being one of the first clients in which this is actually being implemented so yeah thank you all for the opportunity Thanks roll yeah that's really exciting I'm and stick around because we're gonna be talking about the type of a meet up a little bit and I think that's what it was called and go over some of the stuff

people did and sharding and things and then I see leggy just joined is there anyone else who has comments on the etherium magicians meeting or governance Epic's in general that they want to discuss or talk about okay let's go back to the topic of AIP 712 now that League is here so basically left eros brought up the topic of VIP 712 to see if we can get some traction on that and I know that you've been very involved in that discussion so if you want to give your kind of voice on this can you hear me well yes we can that's great yeah good that we talked and talked

about that I basically like the idea I just think we need an upgrade path and the idea of one my product was online one day it's not to replace it basically but to make an envelope that we have an upgrade path because we've seen like in the discussion of seven one two there are some things that would like left-terrorists was saying extend to scope too much like in the end translations as a problem how to display the content to the user because at the moment it's like from the user experience wouldn't be too good would solve some problems but will be too good so the main important thing for would be for me is that there's an upgrade path and there is even like the simpler thing that could be done first because I was talking to for example the guys who do the music for closest they could do with

simpler stuff first they channels and that would be like what one line one can can already do perhaps you should finalize one of the simpler ones first and then that perhaps even use that as a container for seven one two and they asked the main question is do we need backward compatibility because at the moment state-of-the-art it's it's basically broken it's in compatibility old signed data method because of the length field in the middle of the whole thing and were also backtracking in this one EAP I was doing there where that came in that this old quirk from Bitcoin that is just an

implementation detained and survived and got a bit there was an encoding problem basically GUI theorems encoding it in ASCII trousers encoding it binary and in the end we don't even need that because we have the whole length and just subtract the prefix there yep yes so it's just rather minor note it's also important to know that ledger and treasure are doing it differently which means that probably signing is really really freaky currently in the ecosystem so I don't I'm not sure whether it's worthwhile to try to keep backward compatibility the interesting question

that we should not however forget is there might be some clients depending on it which means the only fair thing thing to do is to actually reach out to the community and see who depends on it and make sure we don't break anything yeah we can make it much cleaner if we don't need backward compatibility if we need it I think one mine one is a really good thing otherwise I think the prefix is still good because the main thing to currently is to like make it different anomaly ends action from no transaction and I think but later on we even need a context there to differentiate between different state renders for example and I think a context could hurt that I was

calling it prefix and there's one thing but prefix people don't really like the prefix perhaps because of the old incompatibilities their solution is just call it context that we give some context where for what it designing is because from the UI perspective you also can then do like trust on first sight things that you know when you first interacted for example with state channel the user can make mark a field I interacted with that one and when he signs something for another thing we can make it clear to the users that it's a different thing linkie can you maybe explain the prefix a bit more because I I'm not sure I

totally understand the utility at the moment there's just one prefix us basically it's just a serum signed message like this all prefix signing that's basically the prefix that is there that this from another transaction if it has this prefix it cannot be a normal transaction so but if you could do different prefixes you can do differentiate between different state genders or different use cases because we will have the same problem with solve currently I think later on also because then English only between transactions and for example stations but between other use

cases that also want like we need I think we need the use case or the context as a field in there but couldn't that just be part of the application so if you want differentiation of something you just add extra fields that after is the thing is that you want to be able to have no malleability so that if I have a data signed for a state channel it doesn't happen to coincide and can be parsed as data for some contract which does something else or I mean so it's good if we have a general framework like EEP 191 let's set out kind of where is that identifier for the context and

within that we can have 7 1 2 as one of the variants okay are there other comments on this I'm also for not maintaining backwards-compatibility because I also think I also believe that there are no production systems that rely on this because it's so totally broken right now anyway yeah for this I also have to second that we shouldn't maintain

compatibility if if we wanted to do what Peter suggested so ask the community if anybody's a depends on it how would we even do this we're still small enough we can look at some of the major projects and see who hasn't commented in the thread because I thought I saw something where treasurer was in there at least and there's only like four or five major Hardware wallets there's only five or so major mobile browsers and then there's multiple clients but we can cover them all pretty quickly as well so it's not impossible at this point to get what

would be considered broad consensus and if we and if we miss one it's I mean as long as there is consensus amongst most of them I would say that's good enough to get the EIP approved and then changes in the actual clients that are then you know put in release notes and stuff that's my take on it other IP editors might have a different opinion but that's how I see this kind of moving forward so what we'll do is I put this I already have the agenda for next meeting up on the PM github repository so I already added this again so we can talk

about this in two weeks and just see where we're at so we can continue to get this moving any other comments on this okay great the next item is actually metropolis but I kind of want to skip that just because I think it would do us I think it would be better to talk about research updates and the recent sharding related meetings because with the updates from there we'll be able to better get a sense of what needs to potentially go into metropolis or even if we don't get a

sense of that we kind of know where research is at with sharding and Casper and that kind of stuff so Vitalik sincere leading a lot of these efforts if you could explain kind of what the recent meetings what they produced and then we'll go with some other people in the room and kind of get their take on this specifically with Casper and sharding not doesn't have to go into too much detail about where we're at our timelines or anything but just what you think came out of the meetings okay retreat I would say focus on ninety percent on Casper there was a bit of a stir around sharding there was a bit of an astro section because like myself in pelada needed to work well

there was shorting was definitely the main theme so we spent three days talking about a variety of I was just sorting related topics going through the charting phase one specs are just been published about a week ago and when basically going through the various details like the Commodore proposed again James execution games and some people brought up like very a sub issues with the current protocol we cannot we came up with some improvements we'll probably do another round of thing of thinking

about improvements generally kind of got everyone and who was there on the same page so that included both the kind of core cerium research team and people from parody's status prismatic labs pegasus which is exid Kim synthesis team and a couple of other independent people otherwise godsend of whom I got to know we show there were talks about like various kind of theoretical crypto economic issues to deal with designing

sharding protocols talks about what the roadmap would look like and what the longer-term would look like so the basic roadmap is the multi stage approach where agent one is basically an implementation of sharding that is kind of rooted inside of the main chain and where the main chain and where there is no state transition function so basically it's not charting anything that like the data that's being included in the chi in the shorter chain doesn't actually about getting process s transactions it's just considered to be appended data in the system I guess consensus on the data that so like that

by itself is mainly useful for you know like things like play only ROI or like Twitter on the blockchain or whatever then in parallel and the likely to come soon after that would be stage 2 where we basically finalized the FT transition function and create a way for our clients to own execute the state transition function for an event in charge do this sum depends on finalizing extraction into plans on finalizing Wadhams and it depends on finalizing the GM the new Merkle tree which is no long which is as of today likely to be no

longer a a Patricia tree is likely to be a a sparse binary myrtle tree with some some kind of second layer compression that makes the basically just as ignitions with like one-fifth the complexity very convenient we've employed both my clients on eggs execution functionality and cross yard functionality and then stage four is what we call a tight coupling where we basically try to incorporate the short chains and into the main chain together so does the main chain become is would be considered invalid if any of any invalid charge in black I guess in and we expect us having to develop the same

time as a full Kaspar so we expect hybrid tests were to happen in parallel with somewhere in between us stage one to stage three of the via shorting rollout and cool yeah yeah sure so I just maybe to add to that a little bit definitely a lot of really interesting discussions one thing that's definitely worth noting is on the third day we had a big meet up and that meet up is actually recorded and so anyone can check it out we did two panels one with a bunch of the node implementers and then the second one with just a bunch of

researchers you know Vitalik lab John and Justin and you know everybody and check that out on YouTube it's on all star panel etherium if you youtube that it should come up taipei as well yeah it was really really exciting a lot of a lot of good idea propagation for sure awesome that sounds good so what I'm gathering from that is that there is whereas I'd say some parts last year there was this notion that Casper would go in before sharding it sounds like

Casper's gonna be on a shard now no that's incorrect so this is very important basically the sharding spec is specifically designed so that the charting rollout is like absolutely totally independent of what happens on the main chain as long as the main chain continues to work and provides the functionality of like basically having bots and accepting transactions so the Casper FFG rollout will happen on the main chain and it will basically happen and be rolled out in parallel with the shortening roll out of school they're separate processes that we expect will be real like we happen and be square on the same time okay understood

does an EIP need to be created for Casper as complete definitely so regarding of implementing cast first all the components are so number one there is the there is the fortress rule change number two there is the change there is one heart working I change to the protocol which is basically the mechanism where a cast for votes can be included for free and there's another hard-working change to the protocol which is basically cutting mining rewards and adding a chance for sneaking rewards so the consensus complexity is specifically designed to be relatively

low basically because most of the heavyweight is the lifting is done by the viper contract which is in progress of being affordable a verified by a but the runtime team now the other third part of a ESX task for implementation is the voting strategy so this is basically the proof of stake behavior that's equivalent to mining and proof of work and that one needs to be implemented across and implemented across clients I see okay and is the idea potentially to have this go in to go into Byzantium metropolis part two it depends on timing

like if timing has it what if we want to weaken so we have this rough list or Constantinople just be the Casper fork and at the same time I'm Alexi whatever other things we wanted to do if we decide we want to do a couple of other things faster and then then like you might be okay des and I called I can Staunton opal and then Casper can be again Eli can be called where the next part for it is I see okay that's an important decision to make and yeah I said Byzantium I meant Constantinople a second ago okay well that's something we can discuss a little bit more but before we jump into that does anybody else who was at the event or have any comments about the event like roll or Peter yes absolutely I think you know it's

important to mention that there were a lot of different charting client implementation teams there and one of the things that we were discussing was ensuring figuring out at what point are we going to converge and and possibly work together towards the test and implementation one of the things that we discussed was creating a common loafer there's already a starting repo in the etherium github where we plan on having more structured markdown documents aligning everyone on maybe like the smart contract API they will use for the charting manage your contract one of the things that could be useful perhaps if you could mention vitalik was how charting will be done through the contract and how that's different than maybe the the the Casper contract and plans to maybe merge that global

validator set into one in the future yeah so in it's definitely so like it definitely has to go to eventually some where's the validator set and merge all the functionality ISM into one the ER I guess the general philosophy here so far is basically that like phases wanted to be of sharding and phase one access for both going to kind of happened separately for in what city and eastern and ease of implementation reasons and so they can both actually be independent of each other and like you know and also being kind of self-contained and safer so if Casper fails so during what during phase

one is relatively easy to just like issue of age harder to work before you can just tell people to run to run switch on your notes to fall back to work and if sharding pages one two three fails and basically only affects the user of the system and then shortening phase four and tasks for phase two are the kind of great reemerging and you know in the elevator stuff can be unified and everything to be going to flat side and that's when we'll basically start recommending that like onew activity be done them inside of the charting system and we'll have goodies alike a hopefully functionality within you know something like five to twelve seconds but we'll see you cool yeah one of the other things I wanted to mention

is that my team is focused right now on a local test and implementation of phase one sharding on basically a private private appear in blockchain where we will forego certain some of the p2p considerations that's one of the biggest unknowns that that all the shouting teams got out of the event that the peer-to-peer networking for sharding is something that we still have to store a long ways ahead figuring out so we will we will just get the whole into an example working without p2p on a local test net and and then after that we will proceed from there by collaborating with all the other starting teams jump in there this is Ben from

consensus so it was great to be at the workshops and awesome ideas discussed like rel and prismatic I think we have a sort of practical bent at consensus we're keen to get on with making implementations and rails identified some of the critical points so we all need to talk to one another I think our other concern would be to try to accelerate some of the timelines that were discussed during the course of the workshop where we came to make this happen as soon as possible and that will require a lot of collaboration so we need to set up the mechanisms to make that happen but yeah thanks for the invitation everybody it was a it was a great week just to add a slight slightly

go back to what Rahul said previously that currently the peer-to-peer networking layer of aetherium is really non friendly with sharding so Guardian network just assumes that everybody wants to talk with everybody and it's just big blob of protocol and with the sharding if we want to split up between blockchain to 100 charts then all of a sudden you don't really want to talk to people outside of your shard or there are certain nodes that will want to talk to multiple shards certain certain those that will jump in between shots and these are really features that the current beauty protocol does not support now felix has been trying to spec out I

think he's working at least three concurrent the IPS on trying to push forward in this direction but I think it's a it's definitely a thing that we kind of need to pay attention to that charting will not be possible without beautiful overhaul so that's it we shouldn't forget about it and only focus on their cousin sports who's Felix at the meetings yes okay okay one more interesting problem at least from my perspective is really interesting and that's why I'm bringing it up is that we had a very nice discussion about so as

long as for example if you have two smart contracts and we communicate within a short there are various solutions that you can do but for smart contracts that communicate between shards it's kind of less trivial because the obvious solution so people when you kind of have to access data between multiple shots that data that might actually change between or while you are accessing it then it becomes all of a sudden this distributed system synchronization problem and we had the really nice discussions in how locks could work or could blow up or how for example really interesting challenges that what happens for example if you if you try to obtain basically you to run the transaction you want

something from the other shard but then your shard all of a sudden reorganizes which is a really interesting challenge and we also want to bit into thinking whether for example message-passing architectural versus versus the classical locking mechanism would be more appropriate so going towards queueing theory and is sequential communicating processes stuff now we don't have any concrete solution so we are just debating the upsides and downsides the reason I wanted to mention it is that I think this is a hard problem to solve and it's definitely can use a lot of people in the community

thinking about them and just bring up ideas so if I think we should this is something that the community should feel free to jump in and try to figure out speaking of community interactions and other fruitful debate that came out of this was discussion around the Pine Valley of storage on the etherion blockchain we had a lot of questions about rent at the the meetup and specifically discussions about how we're going to interact with smart contract developers to understand their needs like to get there get there and get their voices heard to implement this so I was wondering if it Helen a little bit about this discussion yeah so basically the idea that we talked a lot about is

storage grants which basically means that if you have a contract that contract has to pay some amount of PS per block per byte in order to in order to uh stay alive and the reasoning behind this is that right now there is this imbalance we are on the one hand creating like a very short whipped contract is arguably a bit too like it's you expensive but like more generally creating contracts that last forever is way too cheap and there's a whole bunch of different exploitability vectors so like for example gas Dogen launched about one or two weeks ago which basically it uses

a mess door filling to kind of save a sort of save up yes when gas prices are very low and as I can and then the gas token contract can be called and on you didn't consume that so again to basically have it clear one of its storage keys and give you the 10,000 items like unit gas refunds whatever the gas price is much higher yeah so basically the holes like the entire system does a bad job of but properly sufficiently pricing contracts creation making contract creation pricing non-volatile and I'm making out of correct them in correct incentives to

clean up storage you know like right now I basically no one really cleans up storage even even despite the other than ten thousand yes and their refund so there's a pretty strong between all of that and the desire to I keep are a small state size which is what may be important different one fastening things to be viable in the long term there's some idea of basically charging per bite in that question the contract origins and become fairly like the Asian major proposal that a lot of people are in favor of and when we need so there are like some different versions of this

that we discuss that we discussed we spent a lot of time discussing the user experience issues so basically look in what way was having to a keep contract to like arm the user experience I mean what we could we reduce those harms in what way could we simplify the edge of the developer experience again I'm actually right in I'm in the process of writing up a proposal based on a contract or a direction right now like I feel like the research community it like feels that something like something like it is important and it's and there's a lot of discussion going on

going on right now about the details okay thanks for talaq as the community does want to get involved with research forms be the best place to go yeah okay great are there other comments about the meeting or the topics discussed okay great so yeah it sounds very promising everything seems to be moving faster than anticipated so that's great I'm I'm on the fence about asking about timelines only because the meeting just

happened so what I think I'm gonna do is not ask about timelines so coin desk doesn't put out an article saying we're gonna be done tomorrow and are done with sharding or Casper tomorrow and we'll talk about that the next time as far as metropolis go ha wait what was that again Vitalik hi Peter hi regional I know you're listening nice that's the editor and another coin desk person let's see what I'm looking last at the last meeting notes because we talked about where'd it go oh so we agreed upon a few things that are gonna be in

Constantinople particularly EIP 145 for bitwise shifting and the EVM block hash refactoring is something that is likely to happen because it's gonna help a lot with some of the things we have coming up that's EIP 210 and then there's some other ones we are looking to add potentially just something that reduces gas cost if we can if we can do that and it makes sense um so we were initially gonna finalize things over the next month or so but with this recent meeting I think that everyone's real anxious to get a hard fork out and that's understandable from the community's perspective I should say

the community wants to get changes out and for things to get done but there's not that many super radical changes happening in Constantinople currently without Kasper or sharding and so from my perspective I think that we shouldn't be rushing to get a date out for the hard fork even though we were initially saying we were having things like a count abstraction in there that's now delayed we were thinking it was gonna come out in the first half of this year I think delaying it's gonna be the best bet or not delaying really we never set an official date but pushing it out further sounds like a better idea what what is it what's everyone's thought on that well I think currently I was um I would generally just say that like I

think we should try to move the move away from the idea that not hard Forks are the only thing to get excited about because like at least I personally feel like get the impression that you know a community is definitely excited about the big about the big ones but you know if no one's going are going around and saying like yeah you know like yet you know BRR et cetera or whatever the numbers are so I think that like as far as um not me like meeting people feel that there is that there is continued real progress that we'll see you soon like even things like clients optimizations and making like clients work much better or are also totally

worthwhile targets you'll probably end up ultimately improving user experience by more than that next base protocol changes can at least in the short term what was your comment Peter yes I always only saying that as far as I know the only thing that's actually fixed that would be nice to ship in the next heart Fork is the shifting UPS so nothing else is really set in stone so I don't believe there is actually one other positive thing that we wanted to a consider which is I know that idea yes the cryptographic the

elliptic curve the otm 128 operations one became faster by a factor Delta n so if parity manages to and possibly harmony managed to speed up there's a bit to like it might be cool to try to cut down the gasp requests for those operations by a factor of like three to five or so because that would really go a long way in making like racing is your stuff is like your knowledge group to talk with more viable yeah so just to save a few concrete numbers so basically we have some funnier BN 256 curve we have currently three operations addition multiplication and pairing and we kind of switched out our our library or

implementation for these the addition was fairly cheap so that one got about a 2x improvement multiplication got 20 to 25 X improvement in the etherium so that's that's insanely fast and bearing is about I think 4x give or take so about four times faster than our previous implantations was with the current so I the problem is that these are the raw benchmarks which are kind of I think here the meaningful thing would be if we could find of course the pure to benchmarking pure lead of course is important from a denial-of-service perspective but I think it would also be

really helpful if we could have some meaningful tests to actually run I mean meaningful contracts that use these and not just call additions a gazillion times one after the other one test that I did find was Christians Z cash rocks the verification contract and the currency I so I kind of turned it into hive test and it's it performs really well so actually running the whole cash verification on ongoing theorem with the current code is about I think 25 milliseconds that's how much it takes on my laptop and well a tongue-in-cheek thing that I'm kind of currently happy

about is that the BN 250 basically that contract so the Z cash verification is currently about three times faster into a theorem currently than parity which kind of I assumed and then the same optimizations can be applied to parity and get them on par with these speed ups yeah that's really good news because I know there's been a lot of discussion about it being very slow to do these elliptic curve functions on the ethereum blockchain so it sounds like at a client level it's sped up faster that's cool yeah though so it's still not spectacularly fast and for example a

really a really interesting thing that I only realized now while doing is optimized version is that the curve that we are using so the official basic to verify that point is on the curve or respects all the requirements in the official curve it requires one less multiplication so essentially just parsing a content a binary blob into a curve point in our curve is a lot more expensive than in the view show curve so that was a bit of a bummer when I realized it but there's nothing we can do about it one potential thing that what I was actually considering but this

this should be benchmark is that for example our pre compiles in the elliptic curve they kind of so for example when I did the peering points when I parse them so every time I want to do an operation I need to revalidate that they are valid curve points and maybe if we could somehow split the validation and the operation itself then then it could make it a bit cheaper gas wise but maybe it's too dangerous I don't know these are just random thoughts cool yeah that sounds really awesome okay cool so is there any other comments about metropolis time line VIPs going in anything like that otherwise we'll talk

about it of course next meeting and come up with some more ideas around timing and how far along some of the research topics are so but I guess have something question that you kind of asked is do we want to make a hard fork pretty soon ish with not that much content or do we want to save up for a gigantic pile of hard work right yeah I think that it was that we should make a hard for that actually makes sense and currently we don't have enough content for it to make sense yeah the hard fork we would have like if we did a hard fork tomorrow with what we've

agreed on it would be two things I think 2e eye peas and then potentially one more if it would get suspect out the rest of the way I think it's Vitalik s-- one that isn't fully spect out yet let me look at which one that is real quick where is that oh it was a I P 210 block hash refactoring was the other one that needed to be need some more work right my personal my take on it is that I would rather have more hard Forks with less content in H than having gigantic artworks help make it so that people

would get used to hard Forks as a potential side effect but don't forget that hard folks are always a huge strain on Demetri and yuuichi yeah that's true so I mean if we started this if we decided all right we're doing these two e IPS for a hard fork you know starting tomorrow or something not the hard for tomorrow but starting testing in a month or two like that would put a big rush on them actually I should I should clarify with Demetri Demitri if we were to decide on doing a hard fork with tui IPs with this new testing framework you developed would that would that interrupt progress with that or would that be something that

you'd be able to implement the new testing framework at the same time you're putting these tests in I actually prefer to restore the existing test functionality is the client and the new testing tool but if merely need to you could still use old testing tool to create tests was a new rules currently Yoichi adding new tests or beat while shifting is that the hard work you're talking about actually yes that's the hard fork I'm talking about oh so so this time tests are already on the way a couple of pull requests from George TV this new tests already other through

test pool okay interesting so that's actually not as much of a showstopper as I thought it would be well yeah but we're talking about bitwise shifting here oh yeah that's the one that he just said was test we're going in right yes but that's fairly easy to test so though I didn't think about that yeah okay and block cache refactoring would be much more difficult as what I'm guessing yeah okay yeah so look we don't have consensus on this today I don't even have an opinion

on this anymore just cuz I don't really know so Martin you're saying that we should have multiple with small additions to it no one is really advocating for a giant hard fork but no one's also saying that you know when we should have the next hard fork so we'll have to discuss this more okay any other comments on that alright so we got the last thing on here is client and research updates a lot of clients who couldn't make it here today to their updates and the agenda so if people want to look through that I'll be

going over them as we hit those clients the first one will go with as parody so parody posted theirs as a text update and offerees also here a free I know y'all just had a major release that put some really cool features and do you want to kind of just go over this yes can you you know I'm at a conference Mobius it's just a break right now I hope it's not too noisy oh it's a little but I could still hear you pretty clearly so go right ahead okay yeah I posted my issue I can just read through it yes we had a major release and we finished integrating our collective Muslim virtual machine and we are deploying it to the common test Network to see some

more live testing yes we are about to finish to outsource our actual user interface or our wallet to a standalone attack on what again some details about some more minor things like might sink to spots getting a command-line interface we are completely overhauling how we deal with execute yeah factoring our engine for our future PRS implementations and obviously the first one will be Casper if you have any

questions let me know great thanks the only question I have is do you have any insight from parodies participation in the e was and retreat that happened right after at the CC was theirs have you heard of any collaboration with the other was of client development teams I probably was on vacation in the last two weeks after a conference so I don't know exactly if there was any but I know that at the conference they were productive discussions and I hope this will continue after that okay thanks I can speak I can speak to there was some stuff if you want to do awesome update as well yeah that'd actually be awesome we you you were at the where you were

you at the rich some yeah you were not in Taipei but I mean in Paris we did okay I'm calling them both a retreat for some reasons I'm talking about the Paris wasum thing let's just do that real quick go ahead and do that update and then we'll do death after cool yes so we did I called that awasum University in Paris it was really really great we had we had Sergei from the Paradis team there with us we also had folks from true--but who've been working on some was some stuff and a couple of other teams that joined us for part of the week or so that we were doing a sprint in Paris you know we disgusts there are definitely some differences between the implementations so for example the way we do metering is a bit different

there's a couple approaches here like one is metering contracts at deploy time versus metering them at runtime and there's a trade-off here and one gives more flexibility around kind of changing gas prices in the future there's some consensus sorry I should mention we had Martin from Definity with us as well so kind of a lot of the folks working on on wasum there was definitely some discussion that it would make sense to come to consensus on some things like clique metering and you know maybe shared libraries across the different implementations the only other thing I'll say on wasum today is we're still definitely making progress moving forward you know aiming to get a waz I'm testing it up on the order of weeks from now there was some conversation between

the e azam team and the folks in Taipei about the connection between was demand sharding I don't know if italic or anyone else wants to speak to that or what that wrote that might look like but it just sounds like it hasn't been worked out yet the timing there and kind of you know whether we're still aiming to get you was him into a shard or into sharding more generally or whether there's a chance I might go to may not I guess we haven't sort of figured that out yet so I mean regardless of mean that is I think I'm pretty sure it's absolutely clear that like was amiss really is going into sharding and going into all shards interesting so it wouldn't be a VM addition that would happen before sharding it sounds like well I mean if we want we could decide to try to find a

ways to incorporate wasn't one the meanness but I in the shards is definitely happening and the shards are I think I believe it like it is consensus that shards are never going to see one single block of like old style EDM execution interesting okay sounds good so wait does that mean that like solidity wouldn't work on sharding I might be I think I might have understood that wrong so so what did he could work through two channels one is the easy answer was I'm transpiler and the other is what it is currently reworking itself the compiling of Julia and Julia has some EDM and I believe is pointing to

have walked them at the back end interesting okay that sounds good and yeah I I have seen the solidity was and and that's looking that's looking pretty good right now okay thanks for answering the questions let's move on unless anyone else has comments let's move on to gets updates yep so we don't really have any too spectacular updates we did basically I think it was about one and a half months ago we did a major release and since then they're kind of just polishing up the stuff and just trying to figure out what next major feature we want to add which is basically what I

think currently the most painful point is is during this is the synchronization and we had had a discussion about that in Taipei along with the party team and Fredrik and we were kind of thinking about somehow converging on on a new synchronization model because both fasting and warp sync are starting to break down and show different signs of issues and so currently I'm just playing around with with a few ideas that may or may not work out so that's and Felix is also playing around with a with the discovery protocol ideas roads were playing around with my client ideas

marking they get playing around with the signer ideas so I think currently we just we want to make sure that any bug that we find in the industry in our country get fixed and just trying to pick a direction that's that will bear fruit for the next major race okay thank you very much next we can do the C++ client which would be Powell and Andre yeah so mostly it's like colorful the work was about to add support for Aladdin engine and so that's all of the stuff going on around the VM and EMC interface and the second

part done by Andre it's mostly bug fixing and improvements related to database peer-to-peer network blockchain sync and yeah that's that's all yes unless somebody want to add something to that continue to fix issues around synchronization and database we're good question are you what synchronization are you guys working on currently so by fixing the issues I meant mostly the

forcing because it still has some bugs we need to really trying to debug that but we have as well the warp sync type of synchronizations implemented as well it knows not to actually finished but it works already so we use parities work protocol for that and okay I'm just asking because if there's a there's even a potential chance that sync photo cause might get bumped up and you probably you guys will

also be interested in it yeah sure there's no okay and one more comment is that I'm also interested in any future ideas for intermediated watching perhaps due to the state size yeah in fact I think Peter wasn't mentioned by you that parody actually talked to you at SCC a little bit about or maybe it was the type a meeting about being broken broke no so it's a I mentioned it actually I

think I also mentioned it here that I talked quite a lot with Frederick about it in Taipei and we discussed the various issues around the fasting warp sync and they're basically both of them are kind of crumbling under the load and we kind of need something that's more flexible I mean both of them can be patched but maybe it is better to just figure out something that can scale for the next two years instead of the next two months yeah great love crab collaboration the next one is harmony they're not able to be here but they said that they did a

release with performance improvements 1.70 and 1.71 is the latest version they also have good progress on Casper research and they're waiting for updates from paya Thap to adopt them and set up a test network from scratch the one that they currently had fell apart last week the cause was deposit or it fell apart a week ago because of deposits scaling factor became 0 is what they said so they're gonna be redoing that from scratch it sounds like I don't think there's anyone here from aetherium Jas is there okay Trinity the PI AVM one Webb 3 version four is nearing a stable release and the

first Trinity alpha is around the corner there polishing up some minimal MVP with a minimal subset of light clients Inc json-rpc api and you can do Python repple with a web 3 instance so that's pretty exciting what do we got next we did a research update already quick question regarding Trinity I'm not just so I'm not sure whether you talked to them or I'm not sure how how well you know how they're progressing so it's a pity that Piper's not here that rappelled Python replicative caught my eye do you think whether they are that

is going to be shipped inside Trinity or whether it would be an external to reading the update it sounds like it's gonna be shipped with it but that's just for me reading this update I have no other of their information ok ok finally turbo goth implemented the hash file optimization hashes of the top 5 levels of the state hex tree and memory mapped file it says there's a medium article that kind of explains it a little bit that's linked on the agenda and the test turbo goth update fixed a lot of tests started to fix the API functionality and

started the test sync with normal memory quote normal memory is 4 to 16 gigabytes and found a lot of issues so he's fixing them now that's from alexey whether any other updates Rolla you kind of gave an update earlier but did you have anything else from prismatic labs or Ben do you have anything from Pegasus that you feel like mentioning sure so I in the chat I mentioned the the meeting that we're having where we're going to be discussing our exact development sprint for phase 1 charting but my team also I linked the Gator channel there and you guys are interested you can join there and track our updates will be releasing also bi-weekly development updates to be a medium and our mailing list that's on

our website so you know if anyone wants to know more just definitely PM me for more information that's that's basically it nothing as specific from consent aside we press on with development of our client and will be open sourcing it when it's in a sort of fit state to do so so watch this face oh you say that was a client which was the language sure so we are developing a full etherion client services this has been mentioned we haven't made a formal announcement of it yet but it's no secret and so that will be developed and open sourced and

provided as a consensus supported client and we fully magnetic impossible and sharding is part of that so we're doing the charting client alongside that as well awesome oh man I feel embarrassed now Jason Carver's here Jason are you on he might just be listening hey you're with the you're with the Trinity team right yeah I'm working on transitioning over to it but I've done some contributions are you asking about the the integration with the Python rebel yeah do you know about that I think it's a very early stage idea but in terms of if you want a Python ripple for connecting to other

clients then I don't think it's much different than just using web 3pi yeah so I sent my so for example the reason why this was brought up in in the Inca theorem that going on since forever ship with a console and the Christian console is kind of like really really legacy based so basically to go if they go JavaScript interpreter and it's it's based on a kind of a notes back it works fine as long as you don't want to do really fancy stuff so as long as you use it as a simple CLI tool or debugging tool it's fine but if you want to enter a fancy JavaScript territory it's it's

not suitable and so what we're kind of considering is so we don't really want to grab the console because it's it's valuable debugging tool but we're actually wondering whether we would we could actually create a completely separate aetherium console that is just the JavaScript console based on low GS or whatever greatest latest and greatest to Larry's and the latest web 3GS and then people could actually connect to going theorem those or basically any other node and and have a really nice way of interacting with it and since you guys said that you're actually considering creating a wrapper for Python I was actually wondering if you can actually make a Python console to

then it would be really awesome to have both the JavaScript and the Python console that can attach to basically any other node yeah that sounds amazing I mean from from our point of view it would just take a little bit of wiring code to say you know if your guess instance has all the connection parameters you need you could start up you know a Python repple with web 3 instruments already configured ready to go I don't think it would be all that much work honestly hmm ok so uh I think I just want to pop this idea along that if so for example for us it's we don't really want to drop the JavaScript console because everybody kind of got used to that and it doesn't

really matter what do we find in a better language it's kind of just in the community or everybody's used to it but I think it would really awesome to be able to actually provide different or other means to to interact with nodes Singapore yep awesome I think that was the last client or research so Nick Johnson joined Nick we talked about di Pisa leer and I briefly mentioned your stuff but not a lot of detail so if you want to go over any of your updates to what you've been working on in the e ip's repo and your Jekyll stuff go right ahead sure yes Reformation so I've been

working on some changes to make it more accessible and readable and indexable and so on I've converged with the EPS repo into a Jekyll site which means automatically build an HTML version from all of the eats and index them by type II stations you can see a preview of that on a record top can have dot io / beeps like it on the set it didn't hire a couple of minor changes to the format of the header of weeks they all now have to be so if you have an outstanding me it will need to be adjusted accordingly

before submitting I'm also adding a Jekyll as very logical Trevor scripts which will automatically Chi tips for validity on all open requests and that has identified a couple of issues need to be addressed in order to fix bills specifically there are two weeks one nine eight and seven seven eight that are unmerged reference to alleged heaps so if the authors of those two one may ashes for telex and seven seven ages Felix's would be able to work with me on getting them polished off and merged a greater since they're both referenced from either

handful heaps or from other ones internally and in particular one nine eight legs a copyright assignment which the telecom self needs to add nobody else can edit on this behalf so it would be really good to get those merged so that we can fix the build and then to what a net checking of humans there's also half a dozen teeps most the older ones that are referenced from equine there's examples of good eats but actually I've merged either and those are less urgent but it would still be good if anyone wants to go over them and help merge the morphic from there almost that exchanges tongue and I wasn't meant by implement writing up a meter eeep documenting some suggested changes to

the Eve's process so they can wait for the next meeting that's thanks Nick great update and I posted the link in the alt chord F skitter and in the chat here and on YouTube so that's all around does anyone have any other comments updates anything like that we're out of agenda items okay thanks everybody we'll talk to you in two weeks and shout out to Lane for writing up the notes to this he's done it for the last few meetings and he's doing it for this one so Lane great job and we'll see you all in two weeks thanks everybody yeah thank you Cheers

[Music] [Music] [Music]

[Music] [Music] [Music]

[Applause]