Ethereum 2.0 Devcon5

welcome to the 8th to Q&A session and what we're gonna do is I'm gonna add some very very basic questions just to get you all up to speed and then I'm gonna open the microphone to the crowd just a few things I'd so like the whole thing about validator rewards and so on I don't know if you want to like dig into it otherwise you know I think it's consensus that we can skip those questions make sense yeah cool all right so maybe let's start with Joe can you give us an update I over they interrupt locking and what you achieve and what that exactly means so we had this lock-in is what we called it it's kind of a workshop for a week out in Muskoka Canada and I guess we got somebody from Muskoka here pretty so basically the idea was that we like basically trap all the developers in this place and make them join our two cult and then we'll work on our clients together and reduce the round-trip time for communication for everybody on getting their clients to interrupt Interop is essentially being able to talk over live p2p to the individual clients and gossip baptists stations and block proposals with validators kind of like shared among the individual clients everything that you need without sinking and so we were expecting I think eight clients game seven got two Interop and that was really exciting I think we thought that there were probably only be three or four that would achieve interrupt in that time which means that all the individual clients are really doing a great job so um I think that that gives us more higher probability that will make some early q1 don't quote that but but there that's kind of like the idea right now so where people are saying when they want to see a beacon chained up and so I think there's a higher probability of that now so just to give an update does everyone know what if two is formed by how many clients we have and all of that I'm asking the crowd because otherwise we should give a primer okay like apparently everyone knows all right so um so I I don't know like so we have a couple of the clients here we have meme Nimbus we have lighthouse we I I just like I can't these two specification team we have a lodestar as well and we have anyone else oh oh sorry yeah JD okay quills is here their prototyping phase one and two all right which of the clients is the one that's most advanced lodestar does a really good job at fuzzy tests and other clients we blow them up like yeah lighthouse thought they weren't gonna you know panic we made them panic they fixed it we made them panic again those are best lying a full time oh no that's what we got best in the browser all right the adieu the existing clients here wanna give a really quick update maybe we start with okay we don't start with you yes yeah nimbus first of all yeah thanks to consensus and and the organizers of the entropic was really really really good to get together their work out a lot of practical little details that have to be worked out when you're trying to make two pieces of software work you'd think that it's easy like their suspect everybody just writes the code and then you know boots it up and it works and that's obviously not the way it works we have a pretty complex product coming out and they're having very many basic building blocks that have to fall into place like that's the networking that's the cryptography that's this pack itself and I think really valuable was finding out and using each other's clients as stress tests as a first sort of fast testing platform so that we could feel out where the other clients have put their effort the most and then that's how we could improve our own client to sort of match that level so I think Interop was great for this we found lots of bugs lots of issues lots of places where the thinking was not consistent between the kinds and that was sorted out during that intro I mean there was a lead-up to the interrupt where were clients were sort of pairing off and trying to solve some of the initial things to make it smooth right so that's that's probably why we saw so many successes right on the spot as well like yeah thank you Artemis so after Interop we ripped out our rust implementation of lit p2p were the Java client so we went for the JVM lit b2b that was built by harmony and we put that in and now we're kind of working on some sync issues and some implementation issues to kind of get ready we're turning our team over to start working on a sharding client we're leaving our beacon chain client with the production team who's going to kind of like get the more hardened for production and yeah that's kind of where we are we're going to work on a new sharding client that's going to be built in Kotlin just super set of Java and also compiled to machine code notes sir yeah Interop we started we kind of broke into several different sub teams we're working on getting lodestar kind of productionize we have a lot of optimization to do to really get to like this production level that Danny was talking about and we also were kind of looking ahead at a light client work so we start we've started to prototype some of that work out and we're hopefully going to start contributing back to the spec a little bit thank you that house we're going well I mean focus at the moment is to target feature completeness so phase zero feature completeness we're getting quite close we're just sort of polishing off the integration to f12 the deposit contract we're also working on some slashing protection for validators so this is kind of the idea of feature complete being that we can run the protocol we can we have everything we need to run and we can run off the deposit contract but not necessarily can we run to say a year and use reasonable disk usage so that's something we're working on now is trying to figure out how to optimize that database storage so that so that we can run for a long time yeah so I think the next thing for us is we really need to start testing more public test nets we need to get one of our own public test nuts up and we also need to start doing test nets with other clients using the f1 chain as the source of deposits so we can test this like dynamic validator set because this is the thing that we didn't test at Interop yeah that's that's awesome we're we're also really trying to help foster the cool team to to make sure that they can keep researching the the next phases whilst still delivering phase zero yeah so Trudy was a Interop we had a lot of fun working with everyone since then we've been just sort of merging in all the things we found there nothing major but just a lot of like tiny little things as I'm sure other people found the big thing arrest will be performance so Trinity is a client written in Python so well it's great in terms of being readable and very approachable and accessible we definitely have to deal with sort of this performance penalty we accept by choice so that'll be a lot of our work moving forward for the next couple months is making really fast interpreter code well thank you I am losing my voice so excuse me so the quilt team has been focused on doing research around phase two building on execution environments and doing some early prototypes on basically the stateless paradigm so we are already building execution environments that are operating with in a stateless way and we built a simulation within lighthouses kind of based code base where we now have shard chains or multiple char genes interacting with the beacon chain and we're able to actually run the state execution on that as well and run these execution environments on it as well and so we have been I guess kind of what we're doing next is expanding that to include more simulations of what the state market might look like advancing on what may be ease for some of those contract frameworks as well yeah you guys want to give an update yeah we're going on all sorts of things adding add some additional tests to phase zero justin Drake did some excellent work making phase one look really nice and easy to reason about an elegant a lot of research and thought and conversations around phase two and more recently some conversations around potential alternate structures with phase one that might allow more rapid cross-linking and better communication between shards at the same time working on some standards helping drive the standards process on BLS Karl's been looking into key store formats pushing on the deposit contract stuff which is formally verified and ready but we're waiting on the be lost standardization to launch that oh and opening up the conversations around the coming public test nets with with the clients and always kind of providing support and answering questions on a client side so just keeping everything moving forward yep and I've been coming up with this alternate structure is for faster cross-linking that Danny mentioned that we should have some information about me maybe very soon also data availability here there's a data field there's been a lot of kind of progress on different kinds of data availability proving mechanisms there was also that interesting coded Merkle tree paper from Agra a couple of days ago that lets you do I raise your coated roots with much smaller fraud proofs which is also really which was also really nice also we're thinking about half fee mark it's simple a simplification and coming and coming up with ways to and deal with edge cases and really real your markets and all of those issues I guess I've been thinking about optional upgrades one of them is the idea of a secret leader election so right now beacon proposes and Shah proposes they're known in advance that they're going to create a block and then these these leader based systems suffer from denial of service attack surface and so what if we can have a system where you don't know ahead of time who will be creating the next block that would be much more resilient another kind of optional security upgrade that I've been working on for some time and it's still ongoing and we making lots of progress is the the vdf project to have an unbiased ball randomness and I guess I've also been thinking you know maybe a decade into the future on on e3 and how to make a quantum secure at least ten years I'd say damn bonus is 30 Dan also said don't quote me on that all right I'm gonna open up now to questions from the audience I wanna go first you mean teaching a lot of work on themarket one thing that I would love to see is a bit of a high level abstraction so that you can specify how fast you want a transaction to happen like I wanted to happen in a minute or five minutes or an hour or I don't care and then and then it builds you like however much it should the market rate would be for that right you could pay more and then it would refund you the difference because right now it's guesswork like trying it trying to you know guess the right amount of gas although the gas this is the sort of problem that EAP a one five five nine is meant to basically eliminate like users would in the normal case either transactions just included immediately anyone else questions Oh okay we have cable so can you come over please - she actually have questions so the number of straws i do - times we start with 1024 so i'm wondering what why - stitch number especially together with a large number of agitators there will be significant costs on camera cause especially as starting of the easter - is that concern that maybe we may not be able to reach so many nodes or validators at the beginning and so this is one of the one one of the things that this kind of faster cross-linking proposal might actually end up changing potentially but I think in general the justification here is that we're trying to kind of but there's two different kind of constraints that we have one of the constraints is the load on the beacon chain so we want like the higher the shard count the more scalability but on the other hand higher the showery take out the more cross links on the beacon chain and the more expensive the beacon chain will be the process in the other constraints that we have is just like the higher the total throughput of the system the higher the harder it is to be like to be a block Explorer the higher the risk that some historical data will eventually just end up being forgotten completely and so forth so the scalability that we that were expecting like the data throughput that we're expecting the number though like we've committed numbers between 1 to 10 megabytes per second and that seems kind of to be close to the upper limit of people of like what people are fine with so far and for the vote on the beacon chain like we've done numbers and it seems like beacon chain blocks can in the worst case be verified in like about us about a second now is it so yeah so once again it's they kind of like that much but not more sort of thing yeah I think there was like four million validated were starting to encroach over a second so yeah I personally want to be concerned want to be conservative or speaking to a number so I kind wants to I personally really wants to avoid the mistake that we made of like in eighth one where because the chain was heavy like Sophie people wants to run a note like I would prefer a beacon chain note to be just a thing that you would run by default rather than like running only what you need it and that does necessitate kind of fairly like strange it performance requirements yeah I agree things are the faster harder does to I mean on the concern that that won't be enough validators to start with we're essentially handling that by only doing the Genesis once we have sufficient validators so will the current numbers are 65,000 validators to Megan if another idea that we're considering is that even even if we go four thousand shots in the very long term we could you know we could slowly enable them ratcheted up so start maybe with sixty four shots and then over time have it increased because at the very beginning there's gonna be very little activity and it might be worth using less shots yeah speaking of block times or a process block processing times it's it's important to remember there are cases where we have to process blocks which are not necessarily good ones that might be spammed might be maliciously constructed that takes time away so we need to have a little bit of a buffer and that also affects the way that messages propagate in the network so we're using an epidemic network which basically means that all the data is replicated all over the network and the longer it takes to process or the longer full block processing takes the less validation we can do ahead of time meaning that the more risk there is that the data that the network will be flooded by bad data or that it will be slow either of those two right so so there's also that argument that if we can do more good validation upfront and still maintain low latencies we also gain in other parts of the system as a whole yes I'm wondering what the plan is in general terms for handling of VRC 20 assets in particular transfer functions as a developer it's somewhat difficult from user experience standpoint and there's been many proposals er c-23 for instance as an interesting proposal but as we transition to e 2.0 I'm curious what the general plan is for handling those assets because there's just hundreds of whom just migrating them to two-threes and it sort of feasible curious your thoughts so kind of unrelated to the whole transfer from thing which I agree needs to be reformed somehow another issue another reason why things need to be reformed anyway is that assets are probably the major category of application that we expect like in any particular token will need to be accessible in all shards like most applications agree like realistically unless you're in the top 10 you could just live inside of one shard and you could expect people to just move their points to your shard do stuff inside of your application then go somewhere else but tokens need to be able to move to be moved around everywhere and so like the idea of a token as being a balance of one particular model with a contract is not something that can really survive and so you'd expect like token Holdings to themselves be more like individual contracts and when like when that happens you're pretty much like it's an opportunity to kind of reform other things about how the standard works as well another question I had just to go back to Justin you you just a minute ago mentioned that it could start with 64 shards previously I hadn't heard this so can you expand on that a little bit more as to how that could happen because previously the response was that it you'd be under utilizing it but is that really the only consideration that you'd be under utilizing the beacon chain the throughput that that's made available why couldn't we start with the lower number and then scale up what you have like validators sitting out and not really activated I mean the validators do all sorts of things one of them is cross-linking and so technically speaking to reduce number of shards is pretty trivial like when they do the crosslink some of these cross-links will just be hard-coded to zero and that will this zero hash will mean that there's no data flowing through the respective shots but you know these validators would still be providing value for example they'd be contributing towards the finality of the beacon chain and all sorts of other things I mean one one good reason to start with lower shots is in lower counties that you know maybe more network stability we wouldn't have so many short subnets that that's a nice thing was also it allows for services like like block explorers to give them a bit of breathing space to ramp up to to bigger numbers as to how we increase to higher number of shots we can have some sort of automatic schedule or we could kind of push this to this also social consensus layer with with hot folks so this is a possibility that it could start much lower yes and I think it's the natural thing to do I think right yeah yeah because I've heard for many people and I'm sympathetic to the idea that block space should be economically valued or it has economic implications and it should be valued highly and if you have a and a bunt overabundance of it then you end up devaluing the transactions that are contained in it I mean that's a good point if we have few fewer shots in music that we can really test the new you know gas market with VIP one one five nine which by the way is awesome it just seems to solve so many problems hi I'm Kent I'm the head of R&D at a shape shift and I'd love to hear more from you Vitalik about the use of phase one and the data availability context this excites me a lot because it seems to me that a lot of the really vexing challenges with e 2.0 are are in phase two with the Chardonnay ease and Crossgate trot cross during communication this could effectively really give us a very nice bridge where we have layer two solutions with Starks and snarks so kind of a two-fold question to what what extent is the data availability aspect being Specht out and built with those particular use cases in mind and also if you could shed some light on the big research challenges and questions as that aspect is built out sure so their existing a scalability solution already like plasmid group is doing a demo of it like a theory I think at Def Con they called them optimistic roll-up an optimistic roll-up basically works by publishing transaction data in a very compressed form on chain but not doing like the execution on chain and optimistic because you avoid executing you only have a little bit of data and especially because data is relative is very cheap relative to computation even on the East one system you can achieve scale a scalability of like 10 to 100 X like the theoretical max throughput is somewhere around 3000 CPS if like everyone were to just use optimistic roll-up for moving coins around and if 2 could potentially take make optimistic roll-up even more powerful because instead of using the ease one chains data store off the store that's a store this data to make sure that it's available you would be storing that data on these two chain and you would basically kind of feed into these one side merkel proofs that prove that hey this data actually has been accepted by youth too and so if you imagine like even if say we reduce the chard kale and some they're like even the scalability at the beginning is toward the lower end and say there is one megabyte per second of data then if we talk about say 20 buy transactions then that's 50,000 transactions a second that could fit inside of a rollup and that's and it's like a system that could like the logic for for kind of doing it is something that is being developed already I think the main challenge that would need to be solved as AG you it needs to have at least a minimal sort of fee market on the youth suicide so that optimistic roll-up real layers would at least have the ability to kind of pop publish their data and I think that is one of the things we're actively thinking about and the other challenges if you do want to use phase one as a date availability layer of on eighth one you need to go down the finality gadget road and expose it to data to state routes to eath one so you can make proofs against it so depending on as we talked about in the last session depending on kind of parallel roadmaps and how long expected things gonna take it may or may not be worth it right next question Oh Marty hey Martin yeah so I came a little late so I hope this question hasn't been asked if so I'll just excuse myself but the question is around the process by which a particular execution environment is chosen for a shard if there's like some auction going on or renting that space and also what might happen if you need to change something about the execution environment like forking it or something like that look in all of the proposals were considering so far I think blocks would have the ability to contain space for multiple execution and by kind of environment spaces in them and so basically like you would expect like it's ultimately the block proposes that chooses what to include and different people it would would be able to bid but like you would expect I mean if at least popular execution environments to have a presence and be executed even in every slot in the show the shards in in which they're located to be clear the execution environment is defined on the beacon chain and thus available on all of the shark chains and so when you make a block you're kind of signaling this block is for this execution environment and thus the data in this block or chunk of data maybe multiple is for that execution environment and so you can kind of think of say this this block was for execution fire in a this block was for execution of IRB and the next one was for a like the actual blockchain of a is like this this subset of the the actual shard chain and on the forking I think so the nice thing about it is you could actually define migration paths such that you could deploy a new Yi and have some sort of migration from previously to new Yi and I do expect these things to kind of emerge in a standards standards way kind of like in the ERC standards but I could also see that certain ease especially like the eath 1e could still maybe be subject to hard-working to upgrade and manipulate depending on the kind of social dynamic remnant yes yes so I'm saying that would be a like to actually change in EE would require kind of changing changing the actual code of the protocol and an irregular state change there are options to migrate an upgrade ease without doing that but there it might still be like a social tool to coordinate and manipulate these things will the E's be permissioned or like is you're not gonna so if you want to add a new EE do you need to fork anything or can you just add new use transaction for your deposit requirements so we do the beacon chain doesn't get filled up too much but like anyone like it would be able to do it you're not optioning them like some of the guys and as are you expecting applications expecting applications some of the bigger ones to have their own EE yeah possible some a lot of a lot of like the reasons you might have an e like it doesn't actually make sense and it might just make sense to operate within an e but I do funny that you asked that I have thought it could be like certainly an a way to advertise like if the casino has their own e come join us gaming e I mean there's probably some yeah some data that we would want to store that no one else wants to so yeah or maybe not data but more like how you optimize the structure of accessing certain things in a fraction of a second block time would be really good yeah I think it might be like another tier of developer that makes an EE it might be someone that's working really deeply in protocol research or like zero knowledge proof research or something they really know what they're doing and they can't do it anywhere else and then they'll go to that but then you know like kind of typical developer that's at the application layer would probably want to stay away from it any other question from the audience I mean while we're waiting for a question I mean maybe it's put a bit of cold water on the like I mean it's the ease of a beautiful piece of layer of abstraction and very useful in the context of migrating in f1 into if - but there is also the possibility that you know E's you know add extra friction between them in addition to the friction between shots and you know there's also the possibility that we'll have unsustainable ease so ease for example without statement similar to what we have right now and if one and if they become popular then you know it's all sorts of complicated questions so it is possible that at least in the short and medium term we will roll out with some sort of default and shrine de some sort of you know native if tui which just acts and behaves like somewhat like if one does today and you won't have that much room to play with in the medium term and then in the long term we open up the ease to everyone rate but how do you manage that process of opening up to everyone right well that will happen under consensus layer and one day we say hey anyone can can publish an e so you know going back to the permissioning question maybe they you know no one will be able to publish is for some time I'm not saying it will happen there it's a possibility all right questions how much thought is there been to a transparent sharding where that developers don't have to UM figure out which are they want to be on because if you give them that choice maybe they all just all choose to be on the same shard I mean that's one of the really good benefits of opening up two E's is that all this innovation on transparent shouting can be done at the application layer and assess consensus like designers we don't have to bother about that and so if if you nail polka dot or whatever comes up with some cool innovation that can be integrated with very little friction and there's already ideas out there for you know using the shards as you know fungible data availability resource that can be used and kind of decoupling the the the logical centralization of the application from the underlying resource which is shorted who decides where the application goes like does the application get to decide what shard it goes on or is it do they have no control over that I mean at the lower level the every de lives in the beacon chain and it's made accessible to every shard but then you know then it becomes a question of for the dab developers how do they want to you know I've you know restrict themselves to a specific shard or have some sort of virtual or virtual virtual execution environment which is separate from the the consensus level concept also within e development there's there's a few things you can do and you know when when this opens up as well I think there are a couple questions so one one question is do you have to deploy to the beacon chain and do you also have to deploy to multiple shards or do you automatically have it available across all the shards so that's one piece but also within your execution environment you could technically build some basic level of scheduling yourself as well saying I will only operates or in you know certain transactions on short five four you know this series of epics or shard five six and seven for this series of epics so there's a lot of flexibility and how how you can write these and how you may be able to enforce the load balancing yourself just within the semantics behind an execution environment are we going to retain the financial Lego that we've got a plug and play between composability that are we losing that or compromising that with the sharding from a tooling perspective well right now you can you know you can plug compound and die together or something if you don't know if your Lego blocks are now on different shards and they can't interrupt without cross shard links which might be slower and have some penalty I mean I get the concern but I think all of the kind of T Phi integrations like for just as one example I've seen in practice I don't think any of them really break from me synchrony one of the reasons why is that half of these integrations just happen to do with like one system containing a token from another system but tokens are a thing that's like they've probably easier than anything else to move across shards you just like yank the contract over and like one one myrtle branches and it's like somewhere else wherever you want it to be him I think the thing and then if you look at like even unit swap for example just moves tokens around you move the token to the unit swap shard swap it move a token somewhere else so most of the the integrations do kind of work like work that way the ones that don't are basically the ones that involve kind of synchronous we calling other Apple other applications but like even in that case a lot of a lot of the calls are AC like dude tends to be a a synchronous or at least would be perfectly fine if you didn't move in did them in an asynchronous way so now we start given the applications that we know about I think that's a you kind of like a smaller risk that a lot of people think I mean I could see like execution environment fragmentation being in up even a bigger issue than shorter than short fragmentation if not handled correctly and that's it's definitely something that we're thinking very actively about how to smooth over and I mean concretely it might turn out that crush team communication is actually faster on if - then you know an f1 transaction if one on average is 15 seconds and you know two ways that we could have fast crushed our communication is one we have this new proposal where we have cross links in every slot on the beacon chain you know we might have crossed cross link regular collaborate and communication in just just a few slots and then the other way kind of which is generic is to use optimistic cross links where basically you have some sort of off chain mechanism to gauge the probability that some cross link will eventually make it into the beacon chain and get finalized but you don't have 100% probability that will happen and then you you can design your application around that and benefit from the low latency can you do any some kind of automated garbage collection and start moving smart contracts that want to be on the same chain together so that they're faster so I think the space the cross interaction around multiple shards I think there should generally be a set of tooling within the hll sort ESL's that are used within solidity viper anything else so from a developer perspective if you accept asynchronous as you know a basic concept construct of communication across shards you can have tooling that does that through message passing you could have tooling that does that through you know two-phase commit you know system if you need some type of atomic transaction you could have you know tooling that so I think from a dot developers perspective you're going to have more tooling in these languages that you would go ahead and and utilize for the problem that you need so yeah the archive notes look like forth to and our blog explorers ready for this if you're a blog explorer you would pretty much have to download every blog on every shard which is one to ten megabytes per second x 86,400 and we're talking 80 to 100 gigabytes a day so it's like you have you have like more hardware requirements and then of course so that like that's one issue - hi Ricardo requirements going up in another issue is that you'll have to deal like I kind of understood with you to basically more things or being kind of lawyer to a fight than before so if you have execution environments and then within execution environments we're also planning to push forward on transaction abstraction and so now you don't like you don't have yo ways and contracts as different costs of things anymore and then you have crossed our transactions the different ways of implementing them and so your responsibility to and have understands popular layer 2 protocols will realistically end up increasing and that's another thing that you might need to what that you'll probably needs to watch out for so I guess you know in general for being a general-purpose black explorers like realistically is one of the things that will get harder all right we have time for one last question make it quick so as a DAP developer that has an IRC 20 asset is there anything specifically we should do or maybe not do right now no I mean in the in the future when I think I'm inclined to just say like don't don't think about the problem now and like in the future as the X execution environments and if start becoming more nailed down then you'll be able to have think more about like how to design design the kind of token and like application specific details around across shard context but no migrations like there is a possibility you'll have to do a one-time token upgrade but that could also be done with a wrapper knowing that tokens are the most used function in the current chain is it not worth considering hard coding them and by making them much more efficient than they are right now or taking a snapshot potentially what hard coding make them more efficient well because right now they execute code just to do basic functionality of the token the cord is like fairly is small right like execution of EVM code is not like a dominant factor of like watching over and overhead time like the one okay so the thing that I would look into like if we wants to like really optimize tokens have only things that I would look into I mean one is to just like review like the whole year see 20 transfer from architecture and like think hard about do we wants to build into a much higher level of language standards a more explicit like pay for token with function calling em strategy another thing to look into is that actually one kind of functionality that I think well light will likely put in is the ability to store pieces of contract code on the beacon chain and then have the ability to just reference them by address and this would like this would prevent things like account abstraction like tokens not being abstracted and or token it's already being abstracted all these other things from blowing up witness sizes because you know instead of having a piece of code in your witness you'll just be able to point to an index so a lot of those games have kind of been factored into the existing design already another thing to look into either would it be I know redesigning user accounts so that you would have the benefit of kind of being able to like you would be able to get the efficiency benefits of being able to hold many units of a token within one particular package that could get passed around between shards but like there's trade-offs there right because from a privacy point of view if you want to improve your privacy it actually makes sense to kind of separate out all of you all of your token holdings from from each other and even have multiple accounts per tokens so it's like in general I feel like there's a way like the optimizations are needed but there's generally ways to make the optimization without enshrining too many things it's important to note the the notion of owning ether actually becomes a layer two concept in ease so the only thing that owns ease is the actually easy has a balance and then there's some sort of presumably some sort of account model and state model within that ee that's defined that allows you to actually have a right to a portion of that either and so we've actually instead of enshrining tokens we're not like d shrining either within within the alright we have to stop here sorry everyone do you want to talk less herded coded things at the end of the day is better you know so I'm not having like a yeah you know like a ERC hard-coded just gonna be better because less hard Forex less nonsense to deal with from a p.m. perspective you