All Core Devs - Execution #31

Transcript

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

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

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

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

[Music] okay I think we are ready to get started let's see yep audio is working great good morning or afternoon or evening everybody I'm gonna get right to the agenda it's been about a month since we've met let's see here so the first agenda item is testing and I don't think

we have anyone in here that can speak to testing is there anyone in here with updates for that if not I'll see if Demetri joins later or anyone else who can speak to it okay no problem let's see the next item is the yellow paper so the yellow paper was put under a an open-source license specifically Gavin put it under the Creative Commons free culture license so that's really good that's an awesome step and I think that

that alleviates a lot of the problems we talked about last meeting and so that's that's a good thing I think you know each he also had an update and the chat log let me pull it up yes so Gavin address the licensing issues and there's been a lot of progress in it Nick savers specifically made some progress so let's see anybody else have comments on that I think

that's an exciting development I talked to some of the KVM team and they weren't able to make it today but hopefully they can make it next meeting for an update anybody else have a comment on the yellow paper issue and so maybe you kind of raised this a few weeks ago I think it's great that Gavin's realizing that's a gift to the community but the questions that I posed at a time kind of still stand in the sense of what will be the what is the routine for updating it particular I'm quite interested in discussing where the EIP should include an update to the yellow paper as a pull request for example just to make maintenance that much more natural and

part of the process so we don't need to discuss now but if we can keep it on the agenda I would be grateful absolutely yes that can definitely stay on the agenda especially when the KVM team comes back wonderful all right anybody else have comments on that okay so the next item a community member wanted to get kind of an update on iwo zoom and specifically some VIPs that are related to e waz 'm or some other EBM efforts so first let's just do a general

awasum update casey if you have anything on that yeah I'm actually here with a lot of II was some contributors so I'm going to hand it over to Alex and Lisbon with everyone involved it webassembly from the foundation we have casey martin pavel hugo and we have two external contributors silver and jake here and i say hello everyone hello

so the eeap's regarding d was on those can be disregarded they are quite old they don't really reflect anything up to date and but we have an org on github called awasum and more specifically there's a repo called design on it so if anyone is interested in getting a better understanding where he was and is currently they should go to github.com slash he wasn't slash design now in the last year the design has been pretty much spec times and which has a couple of parts and and during the design work there there were

two implementations parallel one in javascript and the other one done in c++ and which can be integrated with CBP team and go etherium now during the javascript port there came up an issue which is that in browsers one cannot stop the web assembly thread and there's no way to do certain operations in a synchronous manner and and and he was inspect was written with synchronous operations in mind and so for example s tour and s load and all the calls all of those were synchronous and that works really well if he would like to translate solidity or wiper or

even EVM bytecode to webassembly and having all those operations synchronous really matches how we do idiom currently and but it turned out it's pretty impossible to implement that in JavaScript and to implement it in the browsers and so a new idea came up to move them to an asynchronous model and and the JavaScript implementation was changed to do that and and then there was a quite a big break in and he wasn't in the last year and now we have revisited all these design issues and implementations and the bad news is we still don't have a full decision on the

sync versus aceing and the case you will tell a little anecdote about that after this and but so far it seems we are going with the sync version at least for 40 sprint you are doing here in lisbon and the main point of this print is to finish the c++ implementation we have and to spin up a small internal test net and with two nodes running CDP Tyrian and Cooper port which will be able to run pure web assembly contracts in synchronous mode and it has another part we have yet to finish is the metering

NEP assembly which will be a contract itself and this doesn't really rely on sync or icing and then I guess we need to do to make a decision on the sync and async soon enough but probably we won't have a final say on that in the next few weeks there's a lot other to telepathy wasn't but no point going into in depth because we could talk about it for days and so I just send it over to KC food anecdote might be funny yeah the we're we're prototyping using the synchronous API so the asynchronous

API adds some callbacks and the primary reason for it was that if you want to use promises or fetches or so let's say the contract calls an S load but the browser doesn't have that storage location already loaded then it has to fetch it from the network and then return it back to the wasum instance and the problem is that the browser implementations or maybe it's the the the the spec the browser spec does not the the Oise 'm the walsim instance does not play nice with with promises and so

that led to an asynchronous version of the of the spec now there's some alternatives where the what the the heat was in spec can remain synchronous and then things get a little bit clunky in the browser and so one of those alternatives was to use web workers and a new JavaScript feature called a atomic dot dot weight that's that so because no js' doesn't have web workers that won't work with or with our testing you know all our testing scripts which are no js' based but at least it would work in the browser at least it

would have worked until this past couple weeks that feature atomic weight alex and martin had a call with a v8 developer and he informed them that atomic dot weight is now disabled in the browser because of Spector and meltdown there's a low CPU oh yeah so so I don't know so we're putting the it would have been nice because then we could you know use the synchronous API would work and we wouldn't have to worry

about doing clunky things in the browser but now we have to well we're gonna proceed prototyping with the with the synchronous version and then and do clunky things in the browser okay awesome thanks for the update so what I gathered from that three sub-point I talked about the EVM 2.0 I I P which I believe is number 48 from 20 December 2015 Martin can we like or can you go in and close that or deprecated it within the IPS repo awesome thanks so that deals with some point a some point B is

something with extending doop and swap with do pin and swap in so that is from Matt de frente could anyone comment on that and what that would have to do with he was him yes it has nothing to do with the awesome he would be extra op codes in the current VM okay and yeah Gregor see you've commented a little bit on that and so is Christian yeah and Alex so what do you guys think of this is this something that needs to go into I

guess a protocol change of some kind I don't understand the technology or the technical stuff enough for it well it's an upgrade to EVM 1.0 it if we jump straight to he was ohm then it's not needed right it depends on how long we think he was him is coming how hard it is to implement this and how important it is okay and the last the last EIP would be 615 that's the one for subroutines and static jumps for the IBM that Greg's

been working on I think this is for EVM 1.5 is that right Greg okay so I guess I'm not up to date on where we're at for EVM 1.5 with II was um is this something where there's gonna be EVM 1.5 and then trans translation II was them or is it still kind of up in the air what's gonna happen I have no idea I haven't been on contract since September so I've been working with seed I don't know his real

name he works with with UHE on just cleaning up cleaning up that proposal and a formal level he's writing a limb formalization now that he's very interested in in getting that part in what will come of it I have no idea you know we discussed it and I don't think we have any particular mechanism for a social practice for making a decision on this it'll happen somehow okay Christian what's your opinion yeah I mean there the main problem is that we

don't really know whether it provides a speed-up at all and the amount of implementation work needed to get a speed-up is probably multiple years so no webassembly is a better alternative yeah the speed-up comes with with 616 not 6:15 okay got it so let me let me go to that one real quick so but we could debate it here but there's really not time this is one hour of the bunch of other stuff a proper

discussion would would take time sure no problem I was just more wanting to get like an overview of everyone's opinion on it and kind of where all of them are at since since the work has been pretty much unfunded since June I would say it's not going to happen in this release you know I've got ideas for a 3.0 that that pulls everything together with transpilation but I haven't worked it out and nobody's paying me to do it right now okay sounds great let's see the next item we pull up the agenda again okay so that that kind

of covers those IIPs is there any other comments on a wasum that's a lot of good updates from from the team there okay item for a stateless client development someone just said they wanted to hear any updates on that does anyone have any updates on that I think it was more there was a blog post explaining it and there was some discussion last time but I don't think anyone took it upon themselves to research or perform anything further on it and it's Alexi here I just wanted to shortly say that I'm hiper didn't join the meeting I think he left some comment

in the in the know Indies thing about that there there is some development of state and stateless client but I understand it is for the sharding because that's actually when the italic talks about it he almost he talks about stated stateless clients and sharding and I think some people refer to my proposal to do state fines before that and I I kind of got distracted from that because I realized it will incur quite a lot of overhead in terms of bandwidth so when I have more data I always come back to that okay great thanks Alexi and everyone welcome Alexi to the coordinate meetings he's

been working on what he calls turbo gas and has been active and kind of breaking down the protocol in a way or not breaking down but I should say improving the protocol and researching some speed ups and death okay cool so that's that's the update for stateless client development the next one would be adding EC and EC mul precompiled for SEC P 256 K 1 that's an EIP that matt opened and i believe it's just an alternative to the pre compiles we recently added and byzantium if i'm not mistaken these pre compiles it's been argued would be a

speed up and let me see the comment that was posted and inside of the agenda there's a comment from mobius development team that's doing ring signature privacy solutions or actually it's the team's not called Moebius I believe that's their product it's clear Maddux that's actually working on this from what I understand so they basically argue that privacy on aetherium is too expensive they have a blog post about it and I wanted to get everyone's opinion I know that we talked about this months ago and it was some pretty positive people were had positive reaction to potentially adding this if I remember

correctly so does anyone have comments I can comment on why it is as it is currently with the precomposed yeah that'd be great EC had a nice email was never intended to be used for a general purpose cryptography it was intended to be used in conjunction with the appearing pretty much and since the parent recompiles are for a specific curve that is parent friendly that's the reason why we chose exactly the same curve also for you see and you see mo okay and so would it be detrimental or add extra weight to just

add these pre compiles because then that would kind of lead down a precedent of adding any pre compiles people want or is this something that is like widely used enough that it would be valuable yeah I think that has to be discussed but in general I think we said but we do not want to add or I mean yeah perhaps not do not want to add any pre-compose but yeah there has to be a really compelling reason okay understood anybody else have comments yeah here from from Sylar I don't know the plans about this ring

signature stuff after the blog post you know that we are working on a new ring signature with the Monaro research team and cause string city or rough city we still didn't decide which name we will go and we also have working Java implementation on our repository if you are interested great yeah if you could post that into the core dev channel or into the chat in the zoom later that'd be great and who'd you say your name was and where you were from Zulu Hungary Abraham Andrew I'm doing he wasn't stuff and III MGS since I think something okay great

I was the one with the paper problems anyway doesn't matter that's right okay yep I I think I have talked to you before definitely perfect okay well great great to meet you on this meeting if I haven't met you before apologies or haven't remember that I met you before on the quartet meeting apologies so I any other comments on that on those pre compiles and opinions so perhaps the he wasn't team could give an opinion about how efficient a he wasn't implementation that would be and if there is any rough estimate on you don't have recent benchmarks the last

benchmark we had was regarding the sha-256 be compiled and the speed I don't really remember but it was a factor of like factor of ten slower so the pre the code written in web assembly and metered using the web assembly rules was consuming probably ten times more gas than the subsidized gas we have chosen for the pre-compiled but that was a single example for sha-256 and probably we were really better choosing

the subsidized gas values for everything every Pig compiled we have and the only time you'll be able to comment about this when we write them compile it into web assembly and meet with them and see their inputs but what about the execution speed itself well that really depends on the actual VM implementation one is using there are probably eight or nine likely even more implementations of webassembly BM and there's at least one jet which should be really fast our journey market under any benchmarks

comparing all these VMs that's why there's a JIT yeah one two percent overhead over running so apparently the jet implementation of wasn't can go up to two percent overhead over native x86 we can't use a chip cannot yes I know okay measuring these jets do we have do we have a non GIPSA

lucien in mind they're a DDoS attack vector so we don't have an upper bound on the calculation time and neither on the compilation time not on the result of the computation of the performance of the result of the copulation thanks it's it's been discussed quite a lot Nick Johnson you can lay it out we can

actually use a JIT but it has to be a special chip that that gives the promise about its performance and that's usually not the case for kids I might be wrong better well yeah it's just designed for webpages don't don't have this issue with DDoS that we do and you said Nick can provide more feedback on this yeah he's he's been arguing it more than than anyone else but I've noticed okay so that'd be good post meeting to kind of bring him in on this yeah Christian's aware of the issues I

just wanted to know what the what the fallback was because all of the performance claims are based on well at all if the performance claims are based on on VA they're not they're not directly usable uh-huh okay and did that did the he wasn't seen answer all your questions questions Christian or to the best of the abilities that we know the information right now at least I don't have any further questions benchmarks yeah I presented those at Def Con I my

to-do list is to turn over to Demetri the the test code that I used it's there wasn't code you tested there was it run on a JIT I'd have to go back and check I think I used watham but I don't remember I'd have to go back and check and please do if you have a tense yeah I can also down in the down in the C++ test yeah within the C++ repo down the test

directory you know pal I'll send you a link there's also a point that it's not I mean there's the comparing the performance of waz them to native but then there's also comparing formative azam to EVM 1.0 so even if it's not as fast as a native pre compile it it's probably still a lot faster than what it would be when implemented in IBM 1.0 yeah as far as speed it it was very close to native so the issue is just it needs to be done

the compilot you have to compile at the time you load um you know at the time you load the contract you can't you can't do it as a chit unless the jits pretty carefully designed for the purpose not even then I think there's a pretty big risk of an attack vector yeah I mean the problem is no we don't want to implement more pre-compiled because each precompile needs a custom metering implementation or a custom metering role and it gets more complicated and it requires a hard fork and it would be better to just switch to a better VM so that we don't

have to you know discuss you know pre compiles anymore yes I mean it's not only the metering it's the fact that we require a specific implementation for each of the pre compiles and there might be differences in the action implementations and the chance of an unintended hotfoot so it sounds like benchmarks need to be had in order to figure this out completely or to make arguments for or against the inclusion of these you know he was on versus in the EVM the freaking wise I mean it's

one thing that there needs to be multiple implementations and but if I remember the Byzantine pre-comp eyes it took quite a while to figure out the actual subsidized gas values for them and partly of course because the implementation differences so that that may be an important point if we have like pep assembly metered and we don't need to figure out those subsidized veins is that something that Martin did when we write before Byzantium Alex was that his estimations okay I remember he was the one who was updating

the repo but yeah there were a few people definitely reasons for webassembly probably other reasons against it but we never properly rated which properties are more useful to us and the speed benchmark speeds is only one property out of that and definitely need to be benchmarked again because any benchmarks done we're probably done two years ago or year and a half and a lot to changed in the webassembly spec since okay sounds good so also perhaps another generic comment on pre compiles and VM and things like

that so adding a new pre-compiled would only give us a constant speed up or a constant reduction in costs and if we can achieve the same or a similar thing with an improved virtual machine it will get us much further because an improved version machine gets this constant speed up for every conceivable routine and furthermore it also gets this so for the moment with the speed-up it allows us to implement other scaling schemes like plasma and troop it and yeah just this generic verify a blockchain state transition often the chain in side the

virtual machine and this is much easier with webassembly because we can use existing c or other code to do that and don't have to okay that sounds good yeah that that's a good point and I think that it sounds like the consensus amongst those who are implementing a lot of this stuff within the virtual machine is that it would not be a good use of time to implement these pre compiles and our current VM compared to working on a newer virtual machine that will have these same cost benefits that they're looking for at least that they describe that

they want in the blog post okay any other comments on that okay the next item on the agenda item six introducing minor heuristic child pays for parent I have a little bit of info from a comment on the agenda but I'll have Alexia introduce the concept and what his ideas behind that yes so it's just to get people's opinion on that so what I've noticed a couple of days ago that so if you go to either scan and then if you

inspect the dependent transaction the tab and so Anna sorted by the gas price in descending order you might notice that very often on top of that there would be some transactions which are hanging there for probably like minutes and hours which pay like a thousand Giga Way of fees and so when I drill down to it I realized that some of them are actually most of them are the the transactions which are dependent on the other ones via unknowns and the ones that are basically they're dependent on in really a small fee and that's didn't look like an attack to me but somebody just making a mistake so they sent they

would send the first transaction with this very small fee and it wouldn't do mind and then instead of replacing that using like my bullet they would just send another one with a huge fee but with the next loans and none of these transactions will be mined so and if you familiar with the Bitcoin you probably know that there's this thing called the parent they search out pay for parent so I'm not sure how much benefit we can get in a theorem from that but I was gonna I thought it might be an attack vector that you might want to close out so that's basically it so the problem but that is at any theorem basically I

can specify that I have a transaction I give it 3 million gas and I give it one thousand bigger way of transaction fees but basically the minor has no guarantees that the transaction will actually consume 3 million gas so the only guarantee the miner has is the transaction will consume 21,000 gas basically a plain ether transfer anything about that is just hoping to be consumed so it means that if if basically attack vector is a type pushing a transaction which truly consumes 3 million gas and I push it in for example one way and then I push in another transaction which I say consumes again 3 million with 1000 way bigger why

sorry and I mean and from the outside it would look that I could execute both transactions for 500 500 gigabyte and in reality my second transaction will immediately return so the miner will almost get nothing out of it whereas the first transaction will be extremely long running and the miner gets penalized word yeah understand that there is just a whether it's worth the trade-off because it it is possible to basically fill up the mempool with lots of these pairs I'm just wondering if there's any impact on the client because of that so [Music]

not sure I understand the question so if so basically like what I can do now is an attacker let's say I can just generate lots of small lots of pairs of transactions like first transaction with with non zero will be paying a very small fee let's say one gig away which will not be mined for days and days and days in the second one with non Swan which is gonna pay a higher fee and I can generate lots of those and then there will be stuck in the everybody's mental for a very long time so I just wonder if that's the problem hmm what currently at least in criterion we may

gained about 4,000 the most expensive transactions so if your transaction is is too cheap so to say to make it into the top four thousand then it will get evicted and once your cheap transaction gets evicted your expensive transaction gets evicted with it because because it's not executable anymore okay understand currently you cannot really attack the network with it okay thank you very much Mikael do you have any comments on how the Java client handles this as far as dimple and what it does with smaller

transactions not now I guess I have to go to watch in the code how it cope with that but I I suppose it's pretty same like I go okay sounds good and did I answer your question alexei about feedback for the item yes it does thank you very much great okay the next agenda topic so there's been discussion lately about creating a real a network of nodes to mitigate issues and just some background on this there also Grif did a comment recently about 9 hours ago

that's near the bottom of the agenda major issues with transaction propagation there's a channel that has a lot of major exchanges that kind of help each other troubleshoot transaction propagation issues and because of how many transactions they're pushing out and a lot of the problems they're having getting their transactions into aetherium right now because of the increase in popularity people are looking for different solutions one of those being a relay network and I know Alexi has some knowledge on this because he's been discussing some of the detriments of having a relay network of nodes that directly connect to each other mainly because that would create a a kind of privilege network and make

less of a mesh network that would not benefit small miners so Alexi can you kind of define what people are talking about when they say a relay network and then your opinion on why that wouldn't be a good idea I mean I'm not an expert in this subject I must say but that's just what I've been kind of maybe I'm completely wrong in my assumptions but what I understand if if so the rail relay network as far as understand is some kind of high speed connections or direct connection between the major miners so that they never really produce the on code blocks because they can just

route transaction to each other directly and very fast and so and that would improve the unco rate and probably will bring it to zero but then you know it's is that the dangers dangers that if I'm a small minor I mean I have to first get into that group otherwise my profitability will be smaller because I will have to be on the periphery and and I won't be included into this like a powerful ring of players who were just just given each other transaction very quickly so and I don't know at the moment it looks like the etherium because of these people don't like this unco rate but I think it might be designed that it's still a mesh network

it doesn't didn't actually form that ring of power for miners which I see is the sort of a good thing but it's kind of there is another side of the coin so that's why I think we we need to try to to improve the network without creation of the second like like isolated another super network because we want things to be homogeneous and that's my just my opinion many some people will say that is all I have known on assumptions yeah yeah is there anyone else who has any opinions or want to correct any definite or want to correct any definitions that were just discussed

hmm so one of my questions actually is regarding what the issue actually is so is it a lock propagation issue or is it transaction propagation issue so it looks like it is a transaction propagation issue is what my understanding is and that's what Grif is describing in here so its transaction propagation out of networks and nodes with are not networks nodes with high throughput so like bit tricks and in fira and so that's kind of the issues that have been going on what I've kind of seen in there are exchanges that the suddenly the clients stop relaying the

transactions or the it's and they're not able to push out the transactions fast enough I'm just getting some some more feedback from other channels that so my kind of the flaw in my definition is that I am assuming that there this relay network will only connect miners but I think the idea was also that this relay network who include other kind of operators like exchanges and things like this so maybe that changes the picture but from my personal experience I must say that I've done I've synced the recently node and then it's got like a huge SSD drive and and it does actually

struggle to to keep to keep up and then very very often it just drops out to the network has to catch up and I I see that the other people experience the same thing and yeah so a lot of it people just kind of make the assumption that clients like death and parity aren't designed for high throughput and that causes transaction propagation issues I know deaths been working on some of that because there's been some fixes before for issues that have been filed by exchanges but I didn't know Peter if you had any other comments on that or if

you've noticed any of the same issues no so since the last quite a few releases we haven't heard any particular issues that would target guests and transaction propagation itself I mean so know perhaps know what one thing that what we could check is how different clients propagate transactions or how many transactions different clients keep for example I can describe how GUI theorem handles transactions at how it propagates them I'm not sure how parity does it because for example if there's a conflict between how the two of them do it and maybe so worst case scenario or

gas filters out some transactions parity filters out some other transactions and at the end it only the lowest common denominator gets through so it might also be something like that so it would be nice exploring whether there's banished and some conflict or what the different queue limits are for parity and GUI cerium yeah and I know Martin's been communicating with some of these some of these nodes and people who operate nodes that have high throughput of transactions so we can get you in touch with some of these people as well to kind of get there so they've they've been doing some issue issues in github and sometimes they're harder to describe I feel like so we'll get you in touch

with them specifically but that's a good point that if two clients act differently that could be detrimental to some people who are pushing out a lot of the transactions from one address and maybe they're getting filtered out any other comments on this it looks like there's just going to need to be more exploration on the scope of this of this problem and so we can get better definitions maybe for the next meeting okay the next item on the agenda fork release management for Constantinople we

had discussed release management before something like I think it was two meetings ago the meeting right after DEFCON three and that that what was brought up is maybe having more of a project manager or borrowing from some release schedules that other projects perform where they do releases every X amount of months like six months or eight months and doing that for hard Forks so that we define parameters for what goes into a hard fork after a certain amount of time and then give them enough time for implementation and

testing I think that's still a good idea I'm back working full hours at the etherium foundation so I may have some time to start to write up some stuff about that and there's a miner who does some videos on YouTube named bits B trip and who sent me some really good documents outlining some of the possible ways that we could improve our processes so I'm gonna look at those more does anyone else have any comments on like maybe when we should do Constantinople and the ideas around having a release management process within aetherium for hard Forks

okay when we have more people in here in the next meeting we'll probably discuss more about Constantinople between now and then I might try to round up some of the EIP s that are meant to go that are potentially going to go into Constantinople the most popular or discussed one being accountable to happen I think the general consensus was that it was a very difficult problem to solve but that it was something that people wanted does anyone remember kind of where we came to on account abstraction the last few meetings I know I have n notes somewhere it's the there's some new threads on the e3

search forum about account abstraction and that's kind of where the discussion is left off that's right but Alec wanted feedback on that okay so yeah let's go next meeting let's collect the feedback from that and have vitalik or other researchers discuss what came of that thread to see if we're any closer to cracking the problem of figuring out the best way to perform a count abstraction or implement of count abstraction any other comments on release management Constantinople account abstraction or anything else we just talked about okay let's go ahead and get to client updates

will start with death I saw there was some tweets from you Peter about some cool new features that are coming out and gets 1.8 and some speed ups that you've been able to do since our last core death meeting where we discussed that if you want to elaborate yeah sure so feature wise well I'm not sure it's it doesn't necessarily affect the entire ecosystem whether it's nice features that we're trying to do for example a nice tracing API so that anyone can write their own little JavaScript racers and run it so you could also do that previously but we put a lot of effort to clean that up we also put a lot of effort now to so

even until now we could generate go ate the ice for contracts so you could just lock in either the ABI or the solidity code and could generate you go wrap around it now we have the same thing for working for events to our subscriptions but these kind of learn the niceties and probably the rest of the model at least I and a few others we'll be focusing on for the next release is somehow to have to make gas a lot more performant Nick had this idea way back that we mentioned a few times with on the code of meetings which he kind of passed on and I picked it up now it's actually the idea why it's really nice it's kind of solid it

has a ton of corner cases but it kind of seems that we managed to reduce the data base rights both by quantity and this guy wise by about 60% so this this won't help initially sink a node but it will at least make your desk fill up one one-third of the time as fast as previously and apart from that we're also kind of short is exploring a few garbage collection ideas that would also entail really organizing our entire database we kind of tried to do that a few times usually the limit is that fast sink doesn't so the way fasting was

designed it it's really horrible from the perspective of garbage collection so we're actually were thinking about figuring out how we could do garbage collection properly or how we could speed up the database properly and then just roll a brand-new synchronization to aid it so but but that one would probably affect affect the network a bit so we're just trying to play around with ideas and probably make a proof of concept and if it turns out to be worth whether we'll probably get to the IPS or that somehow try to get some feedback from other clients too because I know for example that as far as I know if you're MJ and Harmony Day also in

lamented fasting so that's how they also sink and if we're all of a sudden we'll be unable to provide data to fast sinkers then basically you're kind of killing if you're MJ we don't want to do that anything so that's what we've been up to oh yeah and we are aware of of memory should you're in sync we were trying to fix that just so that people don't forget okay sounds good thanks for the update next let's go with the C++ team let's see Christian this this part has found some

good progress there are some fixes in apps and so on and EVM see updates to to make you as an integration easier I think that's that's all I have to say for now okay thank you next is there anyone from parity in the room I don't think there is okay let's go with harmony McHale thanks Hudson yeah regarding your previous question about painting transactions I just double checked with the code and there

are some different logic theorem J implements and if transaction hasn't been include included in a certain number of boxes chat it's just a wicked from the pool so it doesn't matter it doesn't address to a reason of why it has not been included in the block so yeah that's how it copes with that okay and some updates from us we have started to work on Casper implementation and on the other hand we are still fighting work performance improvements we have met some difficulties that haven't been

expected by us and we plan to release database improvements first and in the next release where when we were planning to work on the reduce memory footprint and the proven processor speed I'm afraid to make an estimation regarding database release but this is number one priority for our team so as soon as we manage that over least that's that's all from us thanks thank you okay aetherium Jas basically mainly the

same updates we gave earlier well the entire theory MJS team is focused on the he was M right now okay sounds good thank you let me just check to see what clients I'm missing I don't think anyone from PI AVM is here but I know that Piper left an update so I'll just read that where did he put that he said that implementation of full med sync and PI VM is underway the foundation for running PI VM is a stateless client is running as a going on implementation for a simplified F gas station pricing

algorithm is in progress for web 3 P and an alpha release 2 pi VM based client is happening he also said that the research team may or may not be there but charting and research development continues which I know that they're helping a little bit with they're doing a little bit in the collaboration with the research team so that is the PI EVM update I believe that that is all of the clients are there any other clients or major projects that want to give an update lexy if you want to talk about turbo

death at all and where you are in that feel free otherwise if you don't have much of an update we can know I sort of data that I've collected when so first of all I would say that they're kind of my plan with this is that just to first of all it's experimental there's some optimizations I can do of course I when I did the fork of go theorem I've started making changes I broke a bunch of stuff like slight client and oh like a fast thing they absolutely don't work at the moment so but I don't worry about this because I just experimenting so a couple of things that I wanted to analyze and I have some data now if you saw my list of the improvements that I

want to check out so one of them was the reducing the state size on a disk and the idea there was that so the way that the state is Thornton disk there is a lot of repetition so lots of hashes are written multiple times and so I'm currently running like the the analysis on the full state so until yesterday but before that I was running the smaller set and so the data I had was when I synced to the block 2.2 million and it extracted about so there was about 100 million state tree foo nodes and extracted about 75 million unique hashes which were contained in those nodes and so then I counted how many times each hash unique

hash is actually repeated on a disk and the most frequent hashes were repeated 669 times and then I did some analysis of like if we were let's say hard code some of the caching hashes in the memory let's say just out of the interest and how many how much disk space we're gonna save by this and I mean I had this graph which I might give you give you later on but basically you can get up to 20 gigabytes savings in the disk but that would require you to hard-code 32 million hashes which is could be quite a lot and another P another data point that I have for you is that another idea

was to reduce the memory memory usage for the for these extra trees that we have in so basically the stage of the theorem is stored in this extra trees and so in the turbo gas in the clients and I'm currently trying to hack around is that I'm trying to as much as possible keep the state in memory never he forcible never actually touch the disk so that everything and I'm trying to push it to the limit and so what I realized that I analyzed that you know how many nodes are actually like fully occupied and not fully occupied so if you look at all the nodes in these extra

tree so about half of them are the actual leaves the values usually they connect through some so-called short nodes and another half is the full nodes which are basically like arrays of 16 elements and they're kind of issue imagine this visually that would be on the bottom there will be all these values and then on top of them they will be like sort of pyramid build up so this is the weight of this pyramid is approximately the same as the weight of the bottom of it and so if I look at the tree which corresponds to about block 2 million then there will be about 140,000 full nodes which are these 6017 cells

elements and there's 151 value nodes and what the interesting bit is that out of 140 K full nodes there are 44,000 node which is a third are only with the two children so this is my it was my suspicion before and then there's a similar amount of nodes with the three children so here there is a potential for improvement by you know you know especially it's storing these the nodes with only two children in a more compressed way so that we can spend even more memory on a holding state so my hope is basically at least for this for the initial thing to try to basically fly through the like first 4 million nodes if it's possible just using the

memory without even touching the disk only for rights of course but not for reads so that's what I'm trying to achieve at this moment and that's it for me great thank you for the update all right I believe that is every client and project that needs to go over stuff I have client improvements to alleviate issues but we kind of went over that with the client updates and some of our discussion on actually what you just described someone also wanted to add to the agenda this is Griff again updates on scaling so will we see any scaling improvement from Constantinople we don't

have finalized IPs yet for Constantinople so that's not really a question we can answer concretely but he also asked if there's going to be improvements because of Caspar FFG so let's see here guesses on the time frame for scaling improvements so because there's a lot of network congestion right now and the people are finding that in order to get their transaction and you know and under a few minutes they need to pay high fees that people are wondering about scaling so does anyone have any general ideas about scaling and whether or not Caspar's gonna alleviate some of that or if we're gonna have other improvements outside of

client optimizations mmm caspere is just consensus protocol isn't it that was my understanding so I don't really see why Casper would happen basically what we need so scaling is more so currently were kind of limited about database and processing stuff due to being limited by the database so whether we run proof of work or Casper that just kind of just boils down to wasting or not wasting GPUs on it but I don't think it matters much from a block processing standpoint yeah that and he actually Griff even said I

expect this not to be the case but it's worth asking so anything else with constantinople that would have that we've discussed as potentials for going in the constantinople that would alleviate some of the issues we've been they've been having with scaling since disk IO is the bottleneck and it's still not clear how much room we have to optimize you know by optimizing the database how many more how much more gas per second you know the average or even

high-end computer you know will be able to process I think there's still plenty of room at least to you know verify hit the limit on on disk IO by optimizing the database that's that's the most important thing right now okay great thanks for the answer I'll go ahead short term I kind of agree but I think it's important to know that so basically we can optimize the database and let's say we make it ten times faster or more optimal which gives us room to grow for our ten times our

current size but eventually we'll we will get back to the same point where we won't be able to do any database optimizations anymore and by that time we need to be able to shard our data apart does anyone have any updates on sharding I know that that's ongoing research and there's been a lot of progress but vitalik isn't able to make it today to give an update has anyone heard any updates and there are some really interesting threads on the e3 Search forum about the state tree so the Merkel tree format that will be used you know for for starting there's some

interesting ideas on on these asynchronous accumulators or merkel mountain ranges that sound very promising so there's a lot of exciting [Music] proposals that are being discussed great so to answer everyone's question about where Constantinople and sharding is that some of those can be answered by going to the a3 search forms so that that's good information someone also mentioned in a comment they wanted to talk about the decision process for e IPs that is something that I also want to work on hopefully in q1 and that's

specifically what that means is kind of updating the IP one a little bit more because I know there's been a lot of confusion about where ERC's fit in and Casey and Nick and others have talked before about doing some improvements Greg - about doing improvements to the EIP process so it definitely can use more improvements we've added an EIP editor Nick saver on get github he's been doing a great job cleaning up the EIP x' and y' ohe has also been added as an editor and he's been doing some cleanup of e IPS so we've been kind of trudging through that a bit and I hope to dedicate more time personally to it in order to get some of that done which I've said before but

this time I actually feel like I might have the time so that's that's that's hopefully gonna be good so the yeah as far as the decision process goes community consensus and then the editors getting enough time to go in and actually merge the commits or the kind of how it goes down what GIPS go in and which ones don't but it should be noted that if you have an e rc or an e IP that you've created it's good to actually start implementing them even before they get officially approved because part of the criteria for certain e IPS is having example implementations so for example e ER c 20 token was implemented well before the e IP was

actually finalized so and I know that crypto kitties I think had a IP 770 or something around that number for non fungible tokens implemented before the CIP before the e IP will be finalized so having an implementation like that in the wild is very positive for your e IP getting approved that's all I have on that is there any other comments on the ip's okay great any other comments on anything else that's not on the agenda or anything anyone else wants to say okay well thanks everyone for joining

we'll meet back up in two weeks hopefully we'll have more people around and some representation from some of the research team and parity and others so that we can get more updates and dive into some of these issues a little bit deeper thanks everybody see in two weeks [Music] [Music] [Music]

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

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