All Core Devs - Execution #40

Transcript

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music] hey Vitalik could you meet your mic

alright I think we are on hi everybody alright so what we're gonna do is let's see Oh Danny meet you Mike - oh no problem alright we're on the agenda yay the first thing is testing so Demetri I know you posted an update in the agenda do you want to also talk about the update yeah so we finally started the discussion about this genesis format and we have one hour genesis scheme jason scheme that is taking the four months

and it's declaring how's this forum how's it feels of Genesis should look like what as I am dating how it should look like I keep this drink if it's required field or not and from this pull request that I posted in that link we could now move on and come to a better understanding of what we want from this in general Genesis format so I advise everybody like to read that link and discussion on test repository okay awesome the CPP aetherium the only aetherium client that's implementing these new testing features right now

alright and I'm like so only one person working on that okay talk to me after about getting more help on that I think we had a thread going around about that if you're not involved in it I think you're in the thread though email it was an email thread about getting more help on the testing side yeah remember some I don't remember where okay I'll resend it to you no problem thanks for the update yeah alright now we're on to client updates that's let's start with guess and Peter you know sorry have a hard time finding the onion button the

problem so while regarding client updates I don't think we have anything too spectacular you're focusing mostly on performance we released basically our previous release was last week which is kind of give or take 20-30 percent faster and lighter than the previous ones we still have a lot of ideas that we're currently benchmarking and trying to implement I think that's that's the only meaningful update I can give you now okay cool parody no real update here either just want to say thank you to everyone

involved in recent issue and helping it get get it fixed so quickly you're welcome well I mean I didn't grats on that smooth oh yeah definitely that was that was super smooth and I said you're welcome like I did anything but I did not fix the bug at all just to me be clear everyone did a really great job all right next we'll have harmony aetherium J we just released and this release I have mentioned before is about rocks the beach Union and some memory improvements we also have planned a new one

so it's good that we started to have some time for planning and some project micromanagement or yeah and we also we plan to start work on that release during next week and we also plan to update our Casper implementation according to latest changed in the EIP on the next weekend right in paraty this network so here all updates I guess thanks thank you next we have is anyone here for CPP etherium if not we can just skip that

one me oh there we are Dimitri sorry go ahead so from my changes I already posted like I have a branch at testing branch that is a working process it's a modification to existing city be Clanton which I ran the test VR this earpiece images and yeah I have a success on executing execution of state tests state does work like really fine but well timing is not exactly like it takes ten minutes to execute all of the death but is mostly because CPP codebase is not optimized to

run the RPC request and that some optimization required to submit to client and I also did research and the state test could be generated via air PC into blockchain test and location test could be executed without mining without proof of work check but well there's a main stopper for me is that CPP client is not ready is not optimized also Andre is working on a CBP client optimization and improvements he like many pull requests I seen from here please come in come across him but all he could say

better was he is work that's it ok great Trinity yes we pushed out our first alpha I guess that was like a week and a half two weeks ago and yay yes exciting and we had somebody fully sink and they synched on to the etherium classic chains we're working on a bunch of performance fixes and things like that as well as just like bug fixes a lot of scrambling right now looking to put out another kind of named release next week with a lot of new fixes in it

so Piper by when you said somebody managed to sink does is this light sink or fast sink this is perfect so yeah and could we have any numbers on it I'd be really curious I think it took close to four maybe a half or four days and that didn't include the actual States they blew up yeah once then once we got to a sinking mistake due to the being on the classic chain yeah okay thank you just curious it's great that you sink to

the one true aetherium chain instead of this other chain so at least there's that what's next Pegasus has anyone there for that Daniel or do you have any updates on the consensus into things hello Daniel I think you're muted oh sorry I was muted no no updates from me at the moment though I don't represent Pegasus okay oh yeah I always sorry I always get that conflated yeah is anyone here from Nimbus or XT reham or mana I didn't really think so

jion's here so let's go ahead and get a whisper update if you don't mind YUM this week but whisper whisper words we released v6 some time ago we're just working like right now I'm working on the Express on an experiment to get early p2p to work with whisper the goal is to see if we can teach deaf p2p you know in the in the median term so it's more of an experiment platform at the moment and yes over the summer I am going to

participate like with the help of martin i'm going to create say sorry to have and all the other security audit of whisper update the documentation and the release will be will be over i think will be complete sorry awesome great update and last but not least turbo gas hello i go but i just want to say that my kind of the lightest one of the latest version is still sinking and i think is about thinking about five days and its current in a block five point zero seven and this is the this is actually this sort of the archive mode

which preserves the entire history and it's currently the database size is about two hundred ten gigabytes just pretty good i mean i will be able to get it down even more so I think this at this point I'm pretty I mean I'm not satisfied with the performance but actually I'm going to stop here and I'm going to try to prepare for the the release which is currently what I'm working on is this thing called East tester but the idea is that I realized that the the way that's currently the implementations are tested are like the the the with the test that Dimitri is working on are actually they test it

indirectly via CPP serum client by putting them into these which we called the hive so there isn't actually direct tests on like the this kind of test on to the older clients and this is a bit of a shame so and also I didn't find adequate test for the the reorg so that's why I'm writing this - which will be able to communicate with a node I'm using this peer-to-peer he is in protocol and be able to basically feed whatever blocks at once cause the reorg of the arbitrary ways and hopefully maybe I'll be able to get some tests a test there as well but I'm

not sure yet about a pest yeah that's my goal and then after that if I succeed doing this I will just clean up some RPC implementation and I think I'm going to do the first release that's that's it for me it sounds like you're walking exactly the same thing that I do well we yes but it's in a slightly different way so you were I did review your the tested and retested and the the the way that you do it use fire RPC interface which will have to be implemented in every client but I'm trying to do it in a way that does not require change any changes in existing clients so basically do the same test but without any changes so you

basically you're gonna just take any client and test it you know regardless of whether they have this I'm not sure if I well it is still the same thing cuz my goal was to not there like introduced new RPC meters playing well yeah okay yes definitely so like if you find a way to implement those methods without introducing new ones I can go get some information from the clients like the bloke Rho beta is a transactional data and I need to write yeah I'm actually I have you on skype so we will keep talking about it yeah okay cool Aleksey also security which instance do you use

to run what do you mean which means I mean the machine which oh okay so I use the are you basically I run my test on two types of machines they're both in Google Cloud so the specification is for CPUs I'm not sure the the more cpu's 26 gigabyte of memory and one of them has SSD I think 500 gigabytes of SSD another one has 500 K bytes of HDD and I get kind of compare them with each other that's that's it and I currently the the memory consumption actually fixed it up to it con it doesn't consume more than 6 gigs of memory in terms of the heap allocation it probably does

consume more in terms of because it uses memory mapped files so I assume that the operating system actually uses more but in terms of a go heap it doesn't go above 6 gigabytes okay and I guess those 5 days is on SSD a right yeah the thing that I just said to you it's an SSD so the HDD is falling behind but not too much so in my blog post you could see the graphs that are that a HDD is falling behind but it's still possible to do that when they both sort of sink to the end I will publish another updated comparison for everybody to see and I also publish the the disk

breakdown because because of the database I'm using it's very easy to break down like what what exactly is consuming this 210 gigabytes of work is the account storage what is this the contract storage what is the preimage is what is the rate receipts and stuff like that so I will publish that to quite soon quo in a few days when I finish syncing ok thank you okay thanks for the update alexey sharding client you are the next one up Kiev feel free to go ok good hey guys role working here on sharding and forget just wanted to do a quick update

on where we are now so we have essentially finished the minimal charting protocol implementation currently have we no proposers and notary is performing the responsibilities interacting with the starting manager contract and you know having implemented this using similar models as guest does and making sure that we're extensible with their interfaces aside from that we're holding off a little bit on the latest research on kind of random D contains and dynamic shout count properties that have been worked on in that research just because those things are currently in flux and we're trying to basically be as scrappy and as efficient as possible our first release will basically involve kind of a containerized system where we have you know anyone can download this conclude the repo run like maybe a doctor or a

kubernetes config and see like proposers notaries all performing the responsibilities and kind of observing the state of the shard network on your local computer so it'll be more of a prove concept release and that's essentially where we are right now also exploring peer-to-peer networking through a goal a p2p and that's also something that's in flux with the research so at the moment we're just trying to get something that works and there's a line with the current spec that's out there it's that sounds great yeah so and I guess later when what when it makes sense I will talk a bit about like some of our latest and beacon chain and short research which big does change

the and the kind of roadmap around around fairly significantly especially fact factory in Jasper in but I do think that like all of that still still is work that's basically going along on the same track so have you have done anything regarding like shorting the peer-to-peer network or is everything so far still being gossiped through the same net yeah it's all being gossiped at the moment and essentially you know we're we're mostly focusing on the workflow of just the proposers and the notary's interacting with each other thinking about thinking about sync of chartres chain data and we

still haven't really figured out reorg so that's something that we're gonna be working on next yeah except from that we're trying to not and not do anything that will be extremely disrupted by changes on the research side okay no I mean that's still really great progress thank you all right awesome so we'll probably do now as we'll go II was um because we're kind of in the research / client / whatever section so he was him then KVM and whatever else Everett is working on and then we'll do Vitalik and his his update with Dani and Justin whoever else wants to get part of a part of that update so 4e wasum Casey did you want to give an update yeah sure

mostly we've been focused on making a Bach Explorer that's II wasn't friendly for the impending test net launch and also jake has been working on a abstraction around hair off so we can swap out binary n which is a wasum interpreter for watham which is a JIT engine so it should be faster than parody if we can do that right now I'm working on integrating specifically as well as a benchmarking module for Hira so that we can test performance of well different interpreters and widgets as

well as certain bytecode that can cause the Khajiit to take much more time to compile JIT bombs we're not so worried about those for the test at launch we'll just let people blow it up if they figure out how nice that's a good that's a good way to do it all right now Everett if you're on and want to give any updates on I think I think you might be working on Kay wasum now I actually haven't kept up yeah can you guys hear me yeah I can hear you great awesome yeah so I kind of in parallel with other you awesome work

around you know just infrastructure you need for a test net we've also been having discussions about just kind of more the technical side of how we're gonna integrate EVM and he was them together on you know a single blockchain and I'm not super familiar with the sharding plans but basically the approach I've taken is kind of try to allow as much flexibility on the K specification side as possible so basically I've taken all of the blockchain level kind of update functions or op codes that you get an EVM so these are like the call-out codes and create op codes and things like block hash which queries something about the blockchain State and I've pulled

them out into their own file that we're calling the ke e I for aetherium environment interface and they essentially just define the abstract updates that have to happen on the blockchain side or queries that have to happen through the blockchain to to implement those you know particular pieces of functionality and then they allows you to kind of take two K definitions and mash them together so then I'm going to take ke VM and remove that functionality to a VM and then just mash it together with uses functionality and make sure the resulting thing still passes the test basically and then once that thing passes the tests then it

should be fairly straightforward to take the Kei and mash it together with chaos 'm and get a model of you know ke wasum and yeah and there's been a lot of discussion about what the EEI is to me it just seems like you know a bunch of abstract you know state changes that you can trigger on the blockchain from the VM and the VM should only handle execution level details so the VM for EVM is just you know the stack the word stack and the local memory and pretty much nothing else so things like add all completely within the VM fragment and not at all on the EEI side whereas

something like self-destruct you know falls on the on the EDI side another thing that's come up is you know there's some kind of sticky op codes with EVM like call code and you know just kind of historically not great things and we'd like to you know limit their use in azam so we're thinking you know it'd be nice to say okay there's this set of abstract state update functions that clients can implement for the ethereum blockchain and the you know each different each of different vm these different execution engines sorry like II was and for instance can choose which subset of that

it actually exposes to contract so right now the you know the subset is just the entire thing and it's all exposed to EVM but we're thinking for instance okay will break self-destruct into two operations one which is you know just to self-destruct all it does is destroy the account another which is just a transfer funds and I've heard arguments against transfer fund like a transfer funds primitive that I honestly don't it doesn't make sense to me because you can already transfer funds just you have to kind of jump through this create slash self to start loop instead to do it so I think we should just have affirmative for it and maybe we can you know expose that primitive the transfer funds primitive to you Azam but the EDM

whenever it calls self destruct it always has to call both self destruct and transfer funds of the EEI level the maintain backwards compatibility so sorry that was probably a lot but does that does that over does the overall idea make sense sounds good to me my obviously wouldn't understand it but it sounds like there's a lot of good progress being made mostly just been a lot of discussions and then we have occasional updates to the EEI spec which is that he wasn't / design and it probably should be moved to something more like aetherium slash GDI but you know we'll just develop it for now and then work on

it later okay great thanks for the update and then we have the talaq and Dani and Justin are on to give any further things besides metallic what if he needs mm-hmm yeah um so do we want to start talk about our and if Casper and sharding updates no yeah absolutely your your on okay great it's oh yeah there's one major link that I want to send but I'm going to push it into the Skype channel first and then maybe send it over a little done there we go it's a it's a notes on ethereal

eggs do you see it let me look real quick then you have Skype Oh yep I see it do you want that to be public or will it crash it I don't we can move it the basic idea here is that this as a sort of substantial reworking of intermediate steps in the roadmap though not the final product and the main kind of material difference is so what this specification says is that it is a beacon chain that basically is a proof of stake chain that kind of hangs

off of so you can sort of call it a side chain of the main chain and this beacon chain implements Casper FFG validation so it implements like voting justifying finalizing based in the same way that Casper FG did essentially though with some simplifications it also implements basic kind of short management though there are some parts of short management that are currently sort of not specified here and that's in part because like it's in part because we wants to sort of preserve optionality about how those parts of all those parts of all over time the significant difference is that this kind of roadmap would basically

involve me and that for the hybrid Casper FFG part basically we and we just end up not going with the version that had Casper FFG as a contract on the etherion main chain and instead like basically everyone's the deploy hybrid proofs take as a kind of prelude to full proof stake in charting then what we can do is we can just run the beacon chain and because the speak in chain kind of implicitly links to the main chain it can be used to finalize the main chain but it does so without being sort of directly inside the main chain so the key thing that this would mean is that like the only contract written in

viper or written in whatever that would exist at any points in the roadmap is basically a contract that allows you to call a function to send 32 eath along with some arguments it would burn the 32 beef and it would create a wok and everything else would be processed by the rest of the system so I like I'll stress again that like the functionality that this provides is basically like at least in the short term is basically very similar to the functionality that I'm Casper if gia as a contract had with an exception that this particular mechanism is one-way right so it basically means that if someone deposits

32 Ethan to this contract then that 32 eath is basically just in there until a future or hard fork implements the part that allows that 32 if to get withdrawn I mean into a shard and where the the shard state transition function is more fully enabled so the so basically the main advantages of this are one that the even the the Casper components as somewhat more separate from via maintain which basically means that it can be developed kind of more inch less

intrusive lis in some ways so basically it can be its and developed as a as a separate chain and it can have its own rules about how invoke messages are passed around the network how blocks are passed on the network how blocks are included and you don't really have to worry about like interactions between Casper related transactions and knowing Casper related transactions and like what gets processed in parallel and what's not and so forth because there's a much clearer wall between the two systems so though what the beacon chain does is also the beacon chain is essentially a a full proof of stake chain so the beacon chain has a proof of stake based block

proposal mechanism but every block in the fold proof of stake chain also references a block in the main chain so that's the sense in which the whole crew stakes chain kind of hangs off the main chain and so if the proof stake chain finalizes itself then whatever proof of stake block gets finalized points to a main chain block and so like that kind of gets indirectly confirmed by the abreu stake system so other benefits of this are that basically it removes the need to develop a lot of infrastructure around to have completely separate proof state games where you have one which is

the Casper game you know first a game and the other is a shortened crew State game because here there were basically be only one validator said only one way to get into the validator said only one kind of validator right from the start and basically what with them and also the actual development of the one system will be much more directly a kind of on route to the development of the of what we expect the sort of final later stage sharding system to look like right so basically the idea would be that this beacon chain would once Louise Queen once the beacon chain is fully operating

once there's a substantial number of deposits on it once the sharding part is enabled once the shard state transition function is enabled then that beacon chain basically is what would already be the main chain of the of the sharding system and the basically you would not really need to be that much work that we needs to be kind of redone all over again in order to move from the kind of partially done casper step to the full casper in Chardon leagues kind of its so it describes you know basically what the

blocks and the beacon chain are what the fields in the beacon chain are what the state is it includes the different parts of the state are split into it describes the fortress rule it describes the SK transition function there is also a Python implementation that implements like I mean it's somewhat outdated now but um but it implements most of the core logic and then I believe Danny has his own private Forks that's even more advanced at this point so another important feature of this is that this

particular you might notice that in the perfect state in this particular premise take chain the proof of stake deposit size reduces from a minimum of 1,500 if to exactly 32 eath basically because like by in the short term using BLS signatures for basically signature for signature aggregation which has the property that if you have say like a fairly large number even a thousand of elevators that sign the same message that in order to all of those signatures can be combined into one signature and in order to verify that signature you

basically need just one signature of your vacation operation plus a fat one elliptic curve addition for every participant and it'll look - and there's about a thousand elliptic curve addiction additions and regular signature verification so the cost of an elliptic curve addition is fairly tiny so what and in the short term and as far as the goal of wanting to have something that's kind of quantum proof and ideal ideally kind of purely hash-based in the long term we are simultaneously exploring like basically in the long term replacing the BLS based system with the Starks and like there's reason to believe that if

we use the right hash function then using Starks to verify aggregate signature may not be if that bad either once it's once the tech has developed a bit more mmm so I guess like just to kind of re summarize all of this the intention is that basically this as both a roughly the current direction for the sharding roadmap and also essentially a replacement for the Casper FFG roadmap and now it does keep the algorithm for Casper FF Jia basically in the same way

as people like in terms of like what people vote for a justification finalization like Dynasty changes and so forth roughly as it already is but it does mean that it gets implemented like basically in native code instead of being implemented in Viper and this had basically with this but at the same time this beacon chain is also something that pushes us much further along the way toward a kind of final product arted system and we get because of like things being written natively and kind of optimizations involving bit masks that aren't really available in the EVM as well as signature aggregation this design can basically scale up to well

the theoretical maximum which is like assuming 10 million eath participate participating about 300,000 validators and it can likely even survive in be yeah absolutely absolute practical max which is 4 million validators which is basically it absolutely everyone spitting and there's numbers for why basically like it could work flying even like it couldn't work even under those conditions which is and basically point but basically the kind of worst-case behavior and even the average case behaviorism substantially more feasible than it was under the old road map one of the main things that so the main

things that we lose from this are basically a number one that the ability to deposit into caspere and then withdraw from Casper without without future artworks if that's really desired then it's possible to and guess potentially put some kind of gadget where basically the contract can verify some pls aggregate second assure and be and vote to approve trolls but and but like that's still decided whether or not like still and there's obviously different perspectives about whether or not that makes sense and the other major weakness is that unfortunately this does lose signature

abstraction so one thing that it does though arguably it does somewhat reduce the Anita the need for some of the fancier schemes basically because the minimum speaking amount goes down from 1032 efn so this radial or individuals participating and speaking directly becomes more viable oh no Danny or Justin do you have any yes or anything that I missed or you think I should say more of or you want to say I think you covered most of it to be clear we're

saying we're gonna deprecated di piece and 11 in favor of this new design this funny me for a couple months now and something that as someone who's been working a lot on this Casper contract it took a second to kind of digest and be comfortable moving forward I am totally in paper this way to go and I think it gets us where you want to be sooner rather guys could you talk a little bit about the proposal of shire blocks I know you mentioned under the dog metallic that in an initial release like you could say you can you can make the cross links be the Merkel routes and lots of data so yeah can you talk more about the roles of the roles and proposers in the system how you envision

that sure that's a very good question so woody I mean I used the word cross-linked a lot right so it's a kind of define the term very clearly the basic way that like this category of designs works is that you have like a separate chain for every short and these chains are kind of progressing on their own in parallel and once in a while a some particular block from every shard would basically be attested to by a randomly sampled committee of validators on the main chain so basically on the main chain some randomly sampled committee of alligators wouldn't come together and say we all we've all verified like the portion of the short

chains after the since the last cross lake up until this block we think it's all correct and here's some here's the hash of a block in here what we all signed we all signed it this aggregate signature would get published and published in a mansion and verified on the main chain and then that basically updates to being the main chains current view of what the latest block on that particular chart is right so the long-term visions here is that you can basically imagine that like if let's say on average we have one block appearing in the beacon chain say every of five seconds

then one epoch would happen every 500 seconds which is about every eight minutes which once again is that gets down from the previous epochs we were we were thinking about which was but we felt was something like 15 minutes and every but basically every year some there would be a cross link made from some number of shards so if 10% of the veil of all the validators are deposited it would be from 10% of all the shards and so you could see that like say any given shard would have a new cross link that gets added to the

main chain once every hour and I mean if we want we could always like crank up the number of cross links at some at some cost to the efficiency or the efficiency of the system we're just increasing overhead like generally basically the cross next what happened might happen something like once every hour for a shard and then the but even in between cross links you can generally trust the chain to have like the short chains own growth be fairly good at kind of no not reverting in the short range so if I walk even guess like two or three confirmations in one of the shower

chains that's already a pretty good level of security but so that's kind of a long-term goal these short if he wants to be lazy so if we wants to just say you know we'd we want quadratic shorting out the door as fast as possible and we don't care about one hour of work times we just want the five thousand or five to ten thousand TPS already gone damn it then the strategy that we could take is basically instead of cross links when referring to a short chain cross links are basically just blobs that come from that are connected to a shard and there's some proposer that's assigned to a shard where that proposer is the one is the one that would basically have the ability to create a cross link right so one of the things that's not yet listed

in this document is the exact rules by which show proposals would be selected but generally all what happened is that he would all of the valid every validator would be randomly assigned to some shard for a fairly long period of time to be a proposer and then in this very naive simplified design like basically every time a across link has created some new proposal would get selected and that you proposer would have the ability to a propose an ex cross link but in the longer term model basically the set of proposed risk in that shard would kind of between themselves ends up creating and pushing forward the chain until some block in the chain would get me cross we get included in a cross link and these person in these two

perspectives are kind of are kind of equivalents to each other in some sense basically because you can view the version were across and link is a block of a chain as being a version of the proposal were a classic cross link is a pointer to a block where the chain is basically just a device that be a short proposer is used to coordinate amongst all of each other themselves which blob to push for inclusion as a cross like so but basically the long term goal is the cross links are just this way of linking between charge from charge chains to the main chain and if we want to do something shorter term that's lazier then we can just say that cross links are pointers to blocks of data that are

proposed to a particular proposal that was assigned to some shard for a first time for only one period of time so I guess as far as like like before we were kind of thinking that it would be like Casper release than sharding release but maybe close together this is kind of combining them into Casper sharding right to make it like standpoint want to come before the other so for example it's possible for for Casper to come before Chardon even though they would both live in the beacon chain and

actually I'd say that's more likely to happen that that Casper comes before shouting at this point in terms of other bits and pieces that I I wanted to share one of the kind of advantages of this is also I mean of moving away from having Casper FG in the in the currency chain is is most more security and that's kind of a consequence of the one-way deposit so it's not possible to do withdrawals until there is state in the shards and that that means that

effectively the the deposits will be will be frozen for quite some time and it means we can kind of launch with more confidence and potentially experiment and move faster another thing is because it's all native code in the beacon chain the EVM there's going to be some simplification so we don't have to worry about gas we don't have to worry about gas limits and it's also more future proof because the kind of the end goal the end game of a theorem is is effectively to deprecate EVM 1.0 as we know it so it's also more future proof as metallic said because it's much closer

to the final design another thing it does is that it allows to unlock new functionality and especially the the BLS signature stuff which you know radically changes the the performance properties of of the design another advantage what kind of nice finished and nice things you have is that the beacon chain will have possibly five second blocks so fast the blocks and less variance another thing is that in in general there'll be more unity between the Casper and sharding and the teams that developing these two projects so I think that's good you know more network

effects there another thing to mention maybe is that I mean Nutella code you said it that there's going to be a lot of reuse capital so infrastructure between like between cusp and shouting the all the way from the the capital that is deposited the 30 to Eve's all the way down to messages gossip channel signatures called points aggregation mechanisms accounting and kind of from a from a high level I'd say that large parts of of Casper actually come for free if you're given

shouting so large parts of Casper kind of a subset of the infrastructure that we want to build out for for shopping so that's kind of nice and another kind of point is that when once we start merging the validated roles of Casper and shouting then we also potentially get better security and the reason is that we can have atomicity of the roles you can't be a caster validator without being a shouting validate or vice versa and it means that if for some reason we we mess up the incentives in such a way that it's it's for example very profitable to be a Casper validator but you know being in Shawnee but at the

data it's not so great because you have to do all this work and you don't get much much income from it well tough luck if you want to be one you have to be the other so that's kind of nice in terms of my final just final updates on the on the shouting thing there's this recent idea of one bit custody bonds and and these are really really cool and just wants to give an update so basically in ensuring you have validated voting on the availability of of some piece of data like a chart block and you know we can have an honesty assumption and we

can trust the votes that are being made Oh what we can do is we can have this idea of a custody bond which is that when you make a vote there's some sort of crypto economics in which highly incentivizes you to actually have custody of the data for which year voting availability for and one of the recent discoveries is that basically we can we can have this enhanced voting mechanism where the validator most likely has custody of the data add basically the same cost of making a plane vote with the signature and it all works really nicely with the the BLS

aggregation okay cool thanks for that I think we're good on the research updates unless there's anything final okay great and then Vitalik if you can mute oh sure the next thing on the agenda is net gas metering for s store operations Nick is that yours or was yours at one that's mine oh go right ahead then because there's been discussion in that agenda about it as well okay so I mean the basic idea for anyone who isn't familiar is that we have a bunch of cases already

where contract execution would result in making changes to a storage value and then changing it back so the net change is none an example of this would be using authorizations and the answer 20 tokens if you if a contract wants to authorize another contract and then revoke it afterwards after the operations complete and a bunch of other cases where it'd be useful to be able to do this but it's cost prohibitive because of the cost of his stores and so the seat proposes to change how is store in its load are charged for so that if you so you're charged in the end based on the changes you actually need made that need to be persisted to disk so

multiple writes the same value on the each charge once and if you reset it to its original value then you don't even get charged for that and set for the read cost so the idea here is to improve the usefulness of this store and also reduce excessive gas costs for operations that actually aren't as expensive as they're being charged for at moment okay anybody have any opinions on that that's gonna be one of the things we talked about as a possibility for Constantinople and just so I'm making sure Nick this is something that would go into a hard fork right yes absolutely and yeah I would love to see here is included for

Constantinople I think it's relatively straightforward and it would make a whole bunch of use cases available now cool I only have a comment I think that yeah I can make sense it's nice easy shouldn't have an impact on performance I would like to make a comment we need to come to agreement which changes would be included in the next card fork and then as soon as possible because we need time to prepare the test that's a good good thing to say Demetri I agree and I think that we are

going to try to do that over the next few weeks if we decide that we want Constantinople to be happening before the end of the year so actually let's go ahead and skip skinny create to an EIP to 10 and just talk about Constantinople for a second and then we'll get back to those since those are in the list of potential a I P s for the hard fork we've gone back and forth about when to do Constantinople and I'm kind of just wanting to hear what everyone's thoughts are about maybe doing it before the end of the year or as soon as possible either one because we don't have a timeline for some of the research ones

that we might want to bundle into a huge hard fork I think it would be prudent to talk about anyone's opinions if they want to have it and this year given the recent report from the caspere team it seems less likely that we will have anything cancer-related ready to go in the original timeline in which case Constantinople should mainly dedicate it to improvements that we have queued up and wanting to go unrelated stage it seems sensible I agree yeah and it looks like we have enough AIPS now to

justify a hard fort because before we were just on bit wide shifting and block hash refactoring and now we have a few other things that like skinny create two that might want to be might want to go in there and stuff like that of course keeping in mind that there will take a lot of time for testing and we're not gonna rush anything like we've done in previous Forks that needed to be rushed because of emergency situations that the like so any other comments on timing of Constantinople otherwise I'll throw out some suggestions before or after death gum that's a good suggestion anybody else oh I just mean last year I think

there's a fork kind of soon before Def Con and people were concerned about that because if something bad happened and we're all calm but the con the counter to that was it was after DEFCON people might have much work through Def Con so just something something to keep in mind as we plan this I know we don't even know which ones are going in but let's just not put ourselves in some weird predicament around up yeah so it's the middle of June right now it is one two three four five about five months till DEFCON something around that area so I think we can do a hard fork in less than five months

does that sound does that sound right for the amount of VIPs we may have going in which would be about three or four of different varying levels of difficulty yeah I think the IQs themselves are fairly straightforward so the bottom that would probably be testing here so if that if we agree with that would it make sense to devote a section of the mix towards to considering all the proposals and approving them no absolutely what we'll probably do is this time we're gonna go over them just to make sure it's on everybody's radar and the next time we'll do approvals or

non approvals just to make things quick oh sorry just second wow the cat just clawed me all right I think I'm good now so with that what we'll do is the next call we'll try to get a little bit more detail and which ones are gonna be approved for now let's just go over some of the ones that might go in I pee 1:45 bitwise shifting we already talked about how it's well-formed it's not a hundred percent implemented or tested but it's one that we've agreed on in the past does anyone have any dissenting opinion on that or any

comments on including it test coverage for bit while shifting should be pretty easy it's just state test transitions nothing that you don't have I think we have unit tests for Midway's already implemented and I could make logging tests onto it wonderful EW 210 block hash refactoring that's another one that I think we already said we want to go in anybody remember if we said that or not in my last I saw there was still some

questions about the robustness of the block cache refactoring code and whether it should be well rejected so that I think it's probably a good idea to include it if we can but we need to knuckle down and figure out exactly how it's convention yeah actually if you look at item six I forgot about this I put at item six some of the concerns that Martin hole seven they had specifically to clarify it is to tenth italics let me look real quick yeah this is metallics so I guess clarifying that it does not change the current semantics when invoked via block hash that so it doesn't deliver older blocks do you have

any comments on some of the concerns listed in the agenda Vitalik me yeah look up what the uh oh you just cut out are you there I'm here yes wonderful you said you're gonna look it up in a second yeah let's see you wouldn't it make sense to rewrite it using the new shift off codes as the gas consumption counted bridge if when we do the opcode call transition if the cost is eight hundred

guests but in the Kolkata actually suddenly have a million guesses hmm yeah the 1 million is definitely something that should not be fitting that that should exist regardless of like bought gas limits and like I guess the other thing worth pointing out is that clients don't have to implement it by making in the opcode vehicle like it's just an alternative way of implementing it okay is this something that you could work on as far as updating it to some of the latest they sure talked about yeah and also just reference item six on the

agenda to for some of the questions that Martin had specifically they're also listed in the agenda comments wonderful so if we can get that sorted out we can put the IP to ten and if we want the next one on the list is account abstraction I think we already I think we tabled that pretty much permanently because it was too complicated as that's something that's needed for any future research he thinks we would need to put in I think the main kind of like the main thing in the abstraction category that's really valuable for people in the here and now is the skinny create two because that does make us state channels and for things are much easier agree I really like to see that so if we so what

we can do is instead of doing account abstraction we can just do skinny create to where they can be separate right yeah it's totally okay in that case we'll table account abstraction I'll leave it in the list for now but I don't think anyone's advocating for it is anybody know okay the next one ext code hash is that one that we said that was gonna be in there I basically looked through old notes and saw that this was one that Nick brought up and that we talked about it would be pretty cool Nick do you want to go through and just do a quick paragraph explainer sure I mean basically the idea

is we currently have a way to fetch code but although we already have the pre-computed code hash there's no efficient way to fix that inside the VM and there are a bunch of situations where it's useful to be able to do so and there's no reason it should cost as much as it does so this is just a suggestion to add a very simple table code that features the code hash without requiring levian code to fish nashit themselves so does anyone want to advocate for that other than Nick or have any strong opinions either way I think it's oh go ahead laine justjust

curious Nick do you have an example use case like a high-level in this case where this would be useful yeah so for instance by wrote a smart contracts that is able to check another contracts by code for disallow drop codes such as you know his store or call and you can have multiple contracts with the same byte code but and if you could fetch the hash you could efficiently just record which byte codes you've scanned in the past but presently it requires fetching all the code and in hashing it any other case where you want to like check whether a contracts code corresponds to some set of known good codes that are

allowed is another use case yeah that sounds useful so for example white listing contracts for something yeah I mean I personally I believes there's a lot of bad reasons you might do that but there are also some good reasons to do that so cool and there is an ethereal magicians thread that talks about it more so one thing Nick I think that at least the on the EIP website there's a lot of things that are TBD oh that's okay nevermind those are just test cases and implementation so that's something that would need to be done after we approve it pretty much yeah but maybe a little

more detail and the EIP would be helpful for people to understand it more it looks pretty straightforward though yeah I mean if people have specific things that that are unclear I'm very happy to expand on them yep and then I know Martin Martin's all for it because he said so online and in the past and then and so the ox had a need some clarification for a few things on the magician's form so if you can take a look at that Nick before next call we can address those then you know wonderful any other comments on that IP ok the net gas metering for s store

operations we already talked about that a little bit and it gave an overview what did people think about putting this in Constantinople definitely you know hmm to answer Alex's question just now do any of these VIPs have impacts on scalability in sharding so on on the shorting side basically none of them do and that doesn't matter especially because the sharding roadmap

is kind of starting with this separate beacon chain skinny creates who makes the channels easier and state channels are definitely a very valuable short-term scalability technology another thing we could do to improve scalability is we could improve scalability of privacy and the way that we would do that is by adding an EIP that dramatically reduces the gas cost of EC at NEC mall and and pairings and making sure that all of the major implementations have optimized implementations of those operations so that doesn't introduce any kind of new gas well any kind of new to us

vulnerable Adeus and I actually think that's something that probably could be valuable right guys like if we can knock the cost of any of these rings signature applications down from the current like 200,000 something gas per participant to something like 30,000 gas per participant then I think we'll see a lot more like a Furion based privacy solutions in the short term and we'll probably see a lot more ZK smart stuff as eg snarks can also help with shorts our scaling already I'm not sure and oh and speaking of snarks and a IPS I forget is Blake I know Blake too like I know Zuko really what really wanted

that in there and there's theoretically I can't believe agents floating around does that I just wanted to comment on the this snark so the the Experian based privacy solution so I had a chance with some people in there so they've done some benchmark about the actual putting the like ezekias archetype transactions on Assyrian and the main gas cost seems to be not the actual computation of the elliptic curve signatures but actually the storage cost of nullifiers because they need to keep forever the registry of the nullifiers that already been spent so that nobody

can double spend them again and that seems to be the by far the major cost not the so the actual EC signatures are basically just really insignificant compared to that so the cost of a storage Sawat is 20,000 gas and if you if it's just a matter of indices that if you cut the size of the indices down you can probably amortize it down to like five to seven yes and we'll probably more like seven to seven to ten thousand gas but the cost of verifying a snark even with currents up with them the more recent snark protocols is still in the hundreds of thousands okay I see okay so from all that Vitalik is there

anything actionable the you wanted from those suggestions either a IP is being created may be looking for some the IPS that might already be out there um and I'd actually be interested in seeing people's opinions on number ones that I guess cost reduction for a little to curve math and Hubbard Scoob lake so I know previously we we tabled the Blake like to be addition to our the Blake to be addition to the pre compiles because we were waiting for awasum and we were saying we didn't want to add a bunch of

pre compiles in the meantime because that would take away from other research development and improvements I would argue that I the things that have changed now is like obviously number one this roadmap by which he was them is definitely going into the new sharding land and not like if EVM 11.0 main chain which all realistically kind of delay its availability and number two is just that like given that most of the work is already done and like in some ways it is actually lower complex lower complexity

then a lot of the under yet can use because it's kind of fairly contained I suppose it's propaganda like obvious we just seeing that it's like bleak is legitimately very fast hash function and then DM elliptic curve stuff like I else I think that's like I know that there is already there was already work on me on integrating a faster library for that into gap so like if the coin set faster libraries already that I think cutting the gas sounds a no-brainer okay can someone do an EIP on that if someone or Vitalik if

you could do any IP to reduce gas cost like a simple one I think that'd be helpful we can bring that up next time okay sorry I just remembered Vitalik I just remembered the way I said that the the storage cost was actually overwhelming the elliptic signature because it is possible with at least where the Starks to actually aggregate many signatures into many basically such transactions into one and you reduce the cost of the signature verification but you cannot read a Greg eight the no defiers so in when you start aggregating the cost of storing nullifiers becomes the main costs century yeah that's the context narc is still like very

substantial right so yes the benefits are like okay so the benefits of having a snark which is like cutting the gas cost of a snark by factoring I would say let's say for the sake of example we managed to cut it from like 700 thousand to two hundred thousand so first of all that's a 10% scalability Ganga's who stole the broadcast one of eight mil of eight million seconds it improves usability because I mean it means that he needs to wait for a smaller number of things before you publish us before he can aggregate all of them and publish a snork and that and that reduces the lane so you have the application and so at any given like acceptable fee level the latency of an application could

potentially go down by a factor of three and third I'm not just thinking of snarks I'm also thinking of other tech where it occurs tough dominates one of so to give very particular examples one is BOS signatures and like ever getting signatures and stuff in that category another is ring signatures and the more expanded stuff involving like peterson commitments and range proofs and all that and I mean there's a lot of other fancy stuff that you can do with elliptic curves as well okay that sounds like a good argument for it so we'll put the

Blake to be stuff on the agenda next time and I'll let Zuko and Jay Jay Gary bird know that this is back on as a potential for going into the next hard fork does anyone have any other comments I think that like Zuko and his news people are willing to put some work into this to figure out some implementations that are compatible across clients but I know they found some forego and rust and Python I believe so yeah any other comments on that if I can derail things a little bit in the back topic I want to take people's temperature on potentially

introducing other elliptic curve points as we know points curves such as P 256 which would be useful for verifying a bunch of non blockchain stuff Oh Vitalik could you meet I'm sorry we'll meet right now I am detecting a lack of compassion please on the other side of yeah that's got a bit of theme today so Nick if you want to plead your case I'll definitely include it in the list for next time you know I mean the really short version is obviously my

particularly use cases DNA SiC we're places like CloudFlare and others are starting to make Peter SIG's really widely used but it does seem to be the curve of curve of choice for a lot of asymmetric crypto applications outside blockchain and it'd be really useful to be able to do like an easy verify for for those curves as well yeah so I mean I think it's all good but what I could the Train that I could see with this kind of thing is that remember this thing about the RISC architectures of CPUs where some people we used to have like really processors with the really

complex instructions and some people came around and say let's do the very simple things but very cheaply so maybe there is a way to essentially just sort of generalize it in a very small set of instructions which could implement any of the elliptic curve so yeah so I actually asked it happens a couple of months ago and the feedback I got was that you can't really have a generic elliptic curve library because not all curves have like there are certain subsets of curves that are a lot more amenable to computing than others but what about the general kind of field arithmetic library finite field medic library then you can do it very cheaply

then you can implement anything you want we already have my dad and we do have mod mole right like I don't think that finite theorist mistake is the bottleneck like I feel like it's the goo like even for elliptic curve implementations it's more the goo around the finite field that's worth music that's the bottleneck right so like for example in mold requires something like 500 phone average 384 elliptic curve additions and analytic or of addition itself is like something like 10 field operations so you have like basically 5000 years but many thousand units of glue even within one elliptic curve multiplication units of glue and balls like five etherium op codes that's ten thousand times you know

like 50 gasp and that already gets in five hundred thousand guy feet and what kind of glues that do you know basically yeah I mean part of it is just like pushing and popping and just the fact that you have to like call add a bunch like while loops I see okay I feel like if we like I'm talking here about adding pre-compile is not new up codes and if we did so we can clients can potentially implement multiple curves using the same underlying library because I know there

are semi generic ECDSA libraries that can support multiple curves so the additional complexity curve should be fairly minimum that's more like adding new standard libraries in your codes oh yeah sorry HD I thought it would be a cup of course yes it makes sense for it compiles so is there an EIP created for this already Nick there is not because I wanted to sort of as I say take people's temperatures first and before I write something yeah great well sounds like there's not super hard opinions either way or I actually couldn't tell was Vitalik opinion dissenting are just more

commenting on the overall idea of pre compiles no I was just making the comments that were already most of the way there to having pre compose for finite field operations and the like basically and you might want to do this yourself like look through the some of the elliptic or the contracts that I wrote that implemented elliptic curve multiplication in servants and we're basically the gun owner in various glue but Alec you're cutting out and like that's if you want yeah and if we wants to increase the efficiency of

like doing elliptic curve operations then we do need a precompile that's kind of a bit further from the middle in some way just some minor thing that I noticed while we did the BN 256 optimizations a few months back is that at least for the BN 256 six we have multiple opcodes I mean multiple pre compiles and any actual easy case not whatever verification will use multiple cause multiple implications of the same optos and or pre combust and there's a really interesting issue that one thing that every else

each and every one of those are pre-compose does is verified that the curve point is actually valid and the verification is insanely expensive and because we have multiple freaking powers to create complexes of behavior we actually repeat the same verification over and over and over again mmm I don't really have any particular point to say with this just that it may be something we need to pay attention to like if we try to do that like actually compute how much point verification costs right that's just verification of the equation y cube equal Y squared equals x cubed plus B which is possible

I can see how that's comparable to the cost of what so the cost of an easy add but an easy mole I expects to be much bigger than that right so I guess yes right so I'm not sure as far as I know basically it is the cost of an ECMO basically I as your saving data points is curve is like on the order of the cost of any Cemal I think but I may be mistaking it was long time that's that's like mathematically not possible so if like that sounds like there's software optimization opportunities and there somewhere this does an interesting point

though which is that people have raised in the past which is should we reduce the gas cost for calling pre compiles because at the moment it is the same gas cost is calling any other account because of which it speaks to Sloane's anybody I guess I'll write up need for that too I think there is already eat for that I think is written by Jordi I just saw it

today but Georgie but Lina I think you could just find it oh that's cool that's convenient all right in that case yeah if you could write the key for that that'd be great Nick any other comments on that the specifically is the 256 I love dat curve okay sorry my knee-jerk reaction is adding new pre compiles I'm against adjusting the guessed cost of existing ones is a lot easier does that mean I mean you're against adding precompiled full stop or I mean what sort of use case makes that compelling

enough to add it's just the trade-off because yeah I mean first its want recompile then it's three or four more pre compiles and one of the promises of II was them is that you know it allows users permits users to deploy their own pre compiles so once you start getting into the you know three four five more pre compiles it's probably worth looking at you know deploying you azam onto the main chain but I mean we can nothing we can do here will accelerate the the

deployment he was them but there is a bit of a trolley problem because adding new pre compiles can slow down the development of he wasn't why well it would slow down the potential adoption of it on the main chain I mean either you adopt you wise I'm on the main chain or you don't and then you have a bunch of pre compiles yeah I guess the challenge is that like adding Bri compiles in part contributes to delaying he wasn't because you all would also have to implement a version of the briefing file or is that not the thing thing and it's more just a matter of like resources ya know it's more just

a matter of coordinating on what's the next you know thing that's gonna be adopted on the main chain could add three compiles implemented in wasum and then that will kind of make it smoother transition to just using them as proper walls and contracts yeah that would be a good stepping stone I think so explain that again real quick Everett and and Casey what would be the stepping stone well to provide implementations of the pre compiles in webassembly without rather than you know having an implementation in Python and an

implementation in go and and so forth well that's also assuming that we have a timeline for he was on which I think as most people's concern well I don't even have to you don't need a timeline for II was um to add the pre time some files in web assembly itself because you're gonna have to implement the three key files in some language right so you could you know go implement them and see or in whatever right or you can implement in and web assembly and then it will smoothly transition to being just a normal web assembly or what be wasn't contract in the future as opposed to if you do it and see then the transition will be less I mean either way if you add three compiles now when he was and

comes online basically we're just going to implement those pre compiles as you know webassembly contracts and so if you do the work now to implement them in webassembly I think it's gonna be comparable to doing it you know in some other language and it'll just be a little smoother in the future if you implement them and web assembly then every client there has to include I was an interpreter right now rather than when he wasn't is really and it may even be a different wasn't the temperatures that if changes are made between now well rival interpreters are fairly standardized at this point it's azam that is not quite nailed down so I think doesn't that mean you could end up with

it wasn't interpreter and and he wasn't and to sega couldn't you then end up with to viens one for the walls um you wrote the the pre compiler and one three wasn't he wasn't as just wasn't so you know the goal one of the design goals of the ye Hwa's m is to be able to use vanilla wasum interpreters but it would mean that each client would have to incorporate a wasone interpreter if Nona wasn't jet engine if the guest costs are gonna be low enough on the for the pre compiles but you wouldn't then you wouldn't need to have implementations of

all the pre compiles just I just don't think it's reasonable to ask clients to implement wasn't viens just for they don't need to implement them though I mean Firefox already has a waz an engine so does Chrome sort of even is there's dozens I mean maybe not doesn't there's a lot of that no it's running browsers so that's not terribly relevant I guess I guess the main I see this is the one of the main risks of implementing pre compose but their semantics is not easy well it could be quite complex weather whereas the semantics of the opcodes should be pretty simple so it introduces

the risk of the consensus failures because if multiple clients especially in different languages use different libraries which sometimes give you different results then you have a potential consensus failure and another thing I wanted to note is that currently is the italic mentioned that some a part of this glue is the swapping and duping on it on the stack I you know a currently because three gasps do you do this operations on a stack and I think we might see whether it's actually over priced you know because I also saw that in gold serum for example there is a lot of kind of a cost of the stack allocation memory maybe that could be optimized and we could bring the cost of this glue down somehow so Alexi I wasn't entirely clear on your

stance it sounded to me like you were arguing for precompiled but I wasn't fair no no I'm just arguing that we might still find the way to to implement what I was asking before instead of pre-compile is implementing like lowering the down the cost of implementing the arbitrary elliptic curve arithmetics directly on a VM and I wasn't talking about it as amazing okay well in terms of consensus failures I think precompile is implemented and Wasson is world's better than pre-compile is implemented as some external library that because the client calls out to because everyone has to agree on how to execute was in any way I agree but I don't think it makes sense

to try and introduce this now as opposed to when introducing any wasn't VM I don't think it's reasonable to expect clients to embed it was an interpreter so that they can hear you know I mean we don't we don't have to we don't have to say the clients have to have and you as an interpreter because you know wasum can be compiled to LLVM I'm pretty sure so we can just write the contract in some language that compiles the wasum and then have the walls and codes say this is the pre compile that we agree the network will run and then also compile it to you know a binary that can be linked into a c implementation right so it's not you know we're losing that flexibility here I think the point though is that we have a single you know Wasson contract or a

single contract in a language that we all agree on execution for that the pre-compile is implemented in so that's an improvement but even with that like inking isn't ago for instance there's a long trivial undertaking you know something like implement P 256 as a pre compile goes from pencil and red lines of code to a thousand lines of code yeah I mean I I mean I'm not entirely sure of the implementation cost these things I guess I'm just arguing for the benefits of doing the pre compiles in wasum which I think KC has also argued for similar benefits another benefit is that it becomes easier to kind of decide on the gas cost of the briefing piles because

you just look at the kind of consensus implementation of it and this meter it and you know see what the gas cost is but anyway so I guess this isn't you know these are just some things to consider okay so we have a few options here we'll be talking about this more in the next meeting definitely the last item which we won't even really go into that much just skinny create - it seems like there's universal support for that is anyone against that and then yeah cuz for better state channels and all that and then I think Peter you had a comment in the agenda about restrictions on the

execution context let's see if there's as Peter going Peter might have had to leave okay we could talk about that next time and I think Vitalik actually gave an agenda to comment that actually addressed that anyway so yeah well we'll have skinny create - as one of the options next time and hopefully that EIP will be a little further along so we can talk about it because I think I think it's pretty new Vitalik is it would you consider it pretty much done or is there more is there much more to be done with it probably not much more hmm okay cool then we'll bring that up next time that's the end of the list and we're over time already so well in two weeks

we'll reconvene and focus a lot more on what a I P is we'll go in to Constantinople so we can start having a timeline developed thanks everybody for coming today and any of the other stuff we talked about let's just take it offline to the core dev chat and get her thanks everybody bye thank you [Music] [Music]