Danny Ryan | Ethereum 2.0 | CrossLink Taipei 2019

hello I'm Danny Ryan I work at the etherium foundation on e to a research specs and a lot of coordination on the project in general and today I want to talk to you about some things in the e to a roadmap a little bit further down the line and some of the challenges and some of the trade-offs that we've been thinking about and to start off also give you just an introduction to the intr 2.0 to kind of ground you in the architecture so we just finished at DEFCON which was yeah super exciting it highlighted much progress especially on aetherium 2.0 last time at Def Con we're really just first getting some basic specs together and getting the various teams and people involved in the project sorry but we also had many discussions at Def Con which highlighted a lot of confusion and different and and concern about different parts of the roadmap and how it may or may not affect users may or may not affect developers and things like that so after Def Con one of my goals is to better communicate the technical roadmap to you and developers in general and to discuss the trade-offs and to also give like clear indication about the path that we plan to take following these trade-offs so today I'm going to talk to you about the general aetherium to architecture just get everyone grounded in that this new shard proposal which we're actually working on which has some really nice benefits execution environments or E's what they are and why they may or may not be a good thing and a two-way bridge between a31 and theorem 2 during the development of theorem 2 technically how we might do it and also just the various trade-offs about when and way why and how we may do it so as they said we'll start with just general look at the theorem to Architecture so this in a nutshell is our building it's very simple obviously it's divided into phases of development and so we'll look we can look at each phase of development to help better understand the system and how the different pieces link together what we call phase zero it's just a really a pure proof of stake chain so we have the existing existing ethereum chain is that proof work chain the pink chain at the top keeps chugging along where and we build this new chain in parallel to it called the beacon chain which is as I said a peer proof of stake chain and it serves as the system level infrastructure the system level chain that kind of links everything together in the new sharded structure of aetherium - and so what happens in phase zero is really we have Valladares that live on the beacon chain they build the beacon chain they finalize the beacon chain they make they participate together to create random numbers through a process we call R and L and in general just kind of like get the core infrastructure together such that the rest of the system can be linked unto it there is this this tie to the existing aetherium chain but it's single single directional in that deposits can be made into the beacon chain to become a validator from aetherium one but you can't necessarily you can't at this point move eath back into a theorem one if you say you were done validating so phase zero we have many teams working on this very actively specifications are in a very stable place although there's a couple changes I'll discuss later and people are working on test nuts and error op ability between clients cool so phase 1 is when we add the chard chains to this system the chard chains being each one of those you can think of as its it's very similar to the existing theorem chain but we have n of them wherein is to be debated and discussed but each one of these chard chains then connects to the beacon chain at phase zero these chard chains we just any phase one these chard chains are just data chains there's no sort of notion of state and state execution upon these short chains there's no user level accounts contracts and the things that you think of in a theorem it's just a creates a highly scalable data availability layer these pink links back into the the beacon chain or what we call cross links and they serve as kind of the routing of the chard chain back into the beacon chain and they also serve this point of communication between the these chard chains and the Chartres proposed new sharding proposal that I'll discuss in a moment discusses like the the trade-offs on the frequency with which you might make these links so at this point you have validators building the beacon chain and you also have valid it or sampled in two committees to build these chard chains and to link them back references of the chard chain back into the beacon chain kind of unifying the system phase two is where you add this notion of of State and an execution upon the chard chains this is where you get the things that you think of in a theorem today accounts tokens balances transfers contracts all those all those types of things and specifically the path that we're taking right now or at least deeply investigating is stateless execution rather than the more stateful execution which exists in the existing aetherium chain and I'm going to discuss that in a couple of sections from now so really it's beacon chain is the system we connect the all of these shard chains to it these shard chains are very similar to the existing etherium chain and thus we get some multiple and scalability by having a number of these shard chains in parallel some of the intricacies and trade-offs come in how we actually connect them to the beacon chain and how we allow them to communicate and part of the last part of phase 2 is phase I don't know what phase this is maybe two maybe two and a half if which point the existing aetherium chain disappears gets rolled into this into this system this is the final form cool so that's the theorem - it provides a scalable data availability layer and many multiples and scalability compared to today but I want to talk to you now about this other thing that's coming up on the roadmap and has been a big point of discussion in the past really just three three or four weeks and it's this new sharp proposal and one of the main benefits is a better UX but at what cost so previously cross-links the things that link sharp chains back into the beacon chain would happen on every epoch this is once per six minutes and we would have a thousand shards 2024 and because of this cross-linking happening only every epoch you end up with at layer one a epoch length cross shard latency so if I want to communicate from shard one to shard - I might have to wait approximately six minutes and run our communicate communicate back it's a wait another six minutes it's definitely not a great user experience and potentially also a tough developer experience and there's all sorts of problems that arise around paying for transactions and where you have eath in which chains and we are investigating all sorts of more complicated ways to evaluate state and optimistic determined state on different shards to help facilitate better communication and I'll get into that a moment so this is what it looked like this is has some pretty bad latency so hopefully this will go okay but we had the beacon chain would be built this cross link was formed of this chain chain a we'll call that other chain chain B and then cross link is formed to chain be at the point that the cross link was formed a chain a now you could make proofs about things in chain B so say communes action happen and went into there but now we have to wait until across thing is form and chain be before we can communicate back to chain a and so this is only happening on like a couple of blocks but actually this would be 64 blocks at potentially six seconds a lot of time so you have like a lot of black time and how these cross links are formed like you know this cross link that's cross linked to the seatback happens that epoch happens and so because of this you can have more you can have more shards but you have a lot lower a lot longer latency in the new proposal we're discussing cross linking every shard at every slot and reducing the number of shards to 64 at least at least to start we can discuss that a moment but the really great thing is this proposal allows for cross shard transactions to happen at the slot latency and so instead of waiting six minutes for transaction from shard one to hit shard two we can make a transaction on shard 1 and the immediate next slot something around 10 seconds we can have the communication happen the east transfer the contract call hit and so we can facilitate a much better user experience and so this new proposal more concretely looks like the chains being built in parallel as normal but at each each beacon chain slot we can point to a new shard block to facilitate communication so if at the second beacon chain block we link to here then the next blocks the next blocks know about the new beacon chain state can facilitate consuming transactions and receipts to transact from each one so pretty much at every slot we get a nice communication infrastructure through the beacon chain so some benefits funny enough fewer shards at the beginning ultimately ends up a reduced complexity and so it actually might be a benefit in getting this thing out to production in time to market certainly a better user experience and potentially even a better developer experience just things still don't happen cross shard with atomicity but you can potentially have a better developer tooling and languages to deal with this quicker quicker guarantees of latency and we ultimately think by moving this proposal because some of the reduced complexity and the amount of shards and the complexities in dealing with cross sure communication quicker time to phase one and ultimately phase two which is I think is a net benefit to the community it also reduces the need for complex fee markets we've been discussing all sorts of like if I'm exists I have a thon shard one but I want to participate on shard to I need to get eath over there to participate in the fee market which has quite a high latency which like induces some bad new acts so we had all sorts of like burgeoning proposals on how to handle the complex flea markets but because now you can move eath in a single slot it reduces as much of the need for these fee markets it also reduces the need for dealing with optimistic state optimistic state being in shard one I create a transaction I know it's going to affect shard two at some point so maybe I can then give that information about it affecting shard two optimistically and kind of like push state along and shard two and then only ultimately when the crossguard communication does happen it like ultimate resolves the state but anyway these are very calm flex models that we were looking into but this greatly reduces the need for looking into these if not eliminates them altogether so major benefit certainly some trade offs so we've been discussing having a thousand twenty four shards for every year now so having fewer shards start would ultimately reduce the total scalability but there's some caveats to that and I'll get them into a moment we'll also likely might have longer slot times because we want to have more rounds of communication per slot because we want to have essentially it the beacon bot created shard blocks for that slot created at two stations and then a new beacon block rather than having sharp blocks built at exactly the same time as beacon slots beacon blocks this should just help the lag time on the communication between shard box okay some other trade-offs things that I've been thinking about a lot because I work with a lot of the sorry because I work with a lot of the implementers and the implementation teams that have been working on interoperability and working on test nets it's something that's been keeping me up at night is that this requires some changes to phase zero and if not if we didn't change things if a zero then when phase one would come we'd have some legacy code that we have to deal with and it might it could could lead to delay in phase zero test nets this is largely mitigated by having a subtractive phase zero release so instead of in phase zero having the infrastructure for cross-links essentially just cutting the cross-linked infrastructure out such that we can kind of keep everything moving forward and and not have to worry about testing this new idea before phase there continues forward so the current thoughts on this proposal are it's pretty the the win on the developer experience and the user experience seems too high for us to not go down this path also there's some recent research that what is it stark where did on large blocks I think blocks 512 kilobytes testing large blocks on the eath one network in the uncle rate the propagation times were very good in the uncle rate was very low so we're pretty sure that we can have fewer shards but larger blocks to facilitate a similar amount of data availability than the original proposal when we had 1,024 shards so still something on the order of 1 megabytes or 3 megabytes of data will be they had availability per second and we have a PR up for review right now that's largely just subtractive from phase zero to ensure that we don't have engineering delays on the phase zero release to test nets and production cool so it's one thing that we've been thinking about and talking about a lot there's another one execution environments how abstract can we get and is it worth it so previously in these two designs and in the current at the are in one chain we have this like very stateful model in the sense that the core consensus has store has assumes that it has access to all the state at all times to both read to read from and write to so the the execute and also the the notion of execution the notion of transaction the notion of accounts the notion of the tree structure all in the data structure is all like very deeply enshrined in in the consensus so what does that actually look like so this is this kind of a glimpse into this model for a theorem one where we have the state within the consensus we have access to the state the state tree and we have this like one execution engine that has hard-coded rules about execution transactions and the account model and structure and then we have the chain that kind of like just has transaction data and we use the consensus to execute on this transaction data to modify an update state so but now we're looking in this model we call execution environments which is a state with both a stateless model and it's also highly it makes execution highly abstracted and and generally extensible so there's really two things happening at once in this proposal to move a move to stateless and I moved to abstracting execution so what does this actually look like so in the previous model we had state and we had hard-coded rules and instead and here we have this like blob of we have this the state route so it might be 32 bytes representative of the state or a digest of the state and we we have this like execution code that is wasum code that can be specified on like it more of an on-demand and user level and so and in our chain we have our normal transaction data but we also have what we call witnesses which is essentially showing up in the block with the database that you need to execute that actual transaction data against the state and not just the database but the proofs that that data is valid with respect to the current state route so what does it actually mean it means if I want to transfer value from account a to account B I can't just assume that my my transaction that says move five eath from A to B that that data the the accounts and the balances are actually available I have to prove that the what this current state of both those counts are with the witness data so that when the execution code is executing on the transaction data and the State Route it can modify and update the seer the cool thing about execution environments is also that these aren't predetermined by the consensus protocol instead they can be added by by the user level so instead of us presuming that we have all the right answers and know exactly how accounts and execution should be built upon etherium this is now like an extensible item such that it can grow and evolve over time and the really nice thing one of the really nice things here is that it gives us a nice migration path for aetherium one in two or three room two because we can actually fork if they're in one into a theorem two as an execution environment so essentially take the existing State Route of ethereum put it into here with an EVM interpreter and Merkel witness verifier as the execution code so some of the benefits is because we end up taking a lot of the complexities of how states operate how rent all these all these various things out of the core consensus and move it into layer two we might actually be able to have a faster time to market because we don't have to spend we can continue to research these concepts and develop these concepts after the core like consensus is rolled out and it allows the this like scalable data availability engine to be used in any number of ways so this core base layer we want to be used for decades and decades to come and I think to presume that today we know exactly how it should be used and how it should be structured we don't actually know that and so this just kind of allows it to be a little bit more future proof right so layer one becomes a little less locked in it can be just be a general scalable data layer it allows for experimentation over time clear path from eighth one day to and future proof in the sense that it creates more abstraction between the various layers and so like on the internet the internet is built a number of like protocols that are just layered on top of each other such that some of the thank you essentially tcp/ip doesn't have to change and we can just change the protocols on top so similarly with these one we don't have to change the state of Olivia veil ability layer but the actual ways in which we interact with it can grow and evolve over time so a little more future proof there's definitely some trade-offs it might be too abstract so a lot of the lot of the conversations we had of Khan were confusion around what this layer adds what you should be doing with this layer who should be writing E's and why and so we found it to be we're finding it to be at least in those early stages it's a bit of a tougher developer narrative and and there's some confusion around what E's are actually good for so we we do plan on helping to better better communicate this especially as the ideas and inspects evolve there's all so some of the worry is around potential fragmentation these and some respects could end up like competing with each other or you could have five really good e's but these although these can communicate asynchronously you now have to deal with potential fragmentation of applications across these so some things are definitely thinking about as we develop this concept a little bit more so the current thoughts is that it's definitely a net positive not definitely it appears to be a net positive as we continue to explore it but we still have time to like experiment with the design space as we do as we build out phase zero and phase one gonna spend more time better communicating and the future proofing I think at least personally I see is like a very major win for a theorem - cool I'll quickly talk about - a bridge so tightly coupling the consensus of a theorem 1 and a theorem to whether it's worth it when we should maybe do it and so essentially I mentioned early earlier that etherium - initially you can no there's only there's a unidirectional bridge of eath such that eath can be transferred from a theorem 1 into theorem 2 but the initial architecture does not allow for the transfer back and this is for a handful of reasons primarily to do that requires us tightly coupling the development of the theorem 1 and the hard forking of a theorem one with the theorem 2 and it also puts the two systems the kind of the risk the risk of each affects the other so before we deem it theorem 2 stable and robust in production it seems unwise to tightly couple these two things so here just is that like unidirectional transfer we can move eath into the beacon chain but not not back but there ends up being issues here we discuss widely at Def Con clearly issue clearly concerns from users and potential validators it opens up questions and issues of liquidity and it also maybe more importantly opens up issues of fungibility between eath 1 & 8th - if we allow for liquidity on 82 so some sort of transfer mechanism before there's before eath 1 is forked into eath 2 or before there's a bi-directional bridge very likely there might end up being very likely almost certainly there'd be two tokens traded eath 1 any two on exchanges there's definitely a concern both of ours and a validator community at large so we're looking at ways to mitigate that and there's just we want to encourage validation in these early phases but there's definitely like a high risk because there's an unknown lockup period and so also looking to mitigate that so - a bridge errors in both directions there's a few different paths the Potala highlighted on 8th research recently one is to embed an each one light client into eath to this but into the actual the EVM but this would require some hard working to facilitate BLS 12 381 support and you end up only having a light client level security essentially what happens the important part is this light client proof so we can handle we have these ease 1 voting periods on 8th to where we handle we facilitate eath 1 deposits in ds2 but then we'd also have these light client proofs about eat about finality in eath - that go into eath one that could then once you've proven that something was finalized in a 2 you could consume receipts about transfers and have withdrawals on each one so again this requires some hard-working coordination on 8th one which is difficult at times so this is probably not the most likely path the other option is to have eighth one nodes run eath to run eighth - software so either in as full beacon beacon chain clients or just as like lions the nice thing is that this path allows us to use for now the finality mechanism so we can not only use this mechanism to facilitate transfers between eath one and A two we could also use it to leverage the security of the validators for me to to secure the phone chain which I think people are pretty excited about that's usually called the finality gadget proposal but you still need an a mechanism to expose the eath to state route in eath one and so there's a couple of discussions on heath research on how to do that some might involve miners essentially like putting in the block the latest teeth one finalize route and people if it's invalid err or yeah if it's invalid for any reason that people will just filter that out of the fork choice this does also have the additional benefit of once we've exposed that state route and eath one and have a solid mechanism for doing that we can use the highly scalable data availability player from eath to within each one to do fun things like seek a rollup and optimistic role so major benefits of doing to a bridge is to prevent to eats from being traded on exchanges and kind of like confusing the users and and validators and developers we get nice finality and allows us to use these to date available later soon but there's definitely some trade-offs and there like I mentioned the reason that we're not doing it initially is because eath - although we're very confident the design we want to see it proven in production before we have it affect the security and the risk profile of each one and by we also that the the entangling of the security of each but we also the sooner that we entangle the the product the protocols then we actually excusing the sooner that we entangle the protocols the the less the more that the development of each kind of encumbers each other such that the eath one eath one moves much slower than eath - at this point because there's a lot of concerns around the actual user base and it just takes a lot of coordination to get hard forks on our production network so the sooner that we we tie these things together we might potentially slow down these two development and the forking cycle and there are this add some additional overhead to eath one notes oh the overhead of validating we can chain client is relatively my current thoughts on this is that we likely should enable a to a bridge before we add validator liquidity but probably after phase one is stable in production again there's a lot of like moving pieces in parallel that may affect when or if this actually is done yeah so that that's that's it thank you we're constantly trying to see a balanced design and roadmap and world of trade-offs give our on the profile speaker Danny do we have any questions for our speaker Danny what's up yeah hey thanks so when we talk about this new short proposal and taking the short countdown from a thousand twenty four to say sixty four where it is sixty four come from where this is full come from right right so much of the much of the load on the beacon chain is with respect to cross linking with respect to bringing the frequency that which you bring shards into the beacon chain and so in Prior proposal with 1024 shards and epoch lengths of 64 your cross linking on average 16 shards per slot and so this adds some induces some overhead on the beacon chain both in terms of block size and in terms of the computational cost and so 64 ends up being it's in that range of 16 such that it's still feasible to computationally process the overhead of all char of those shards into the beacon chain the multiple comes from both the extension of a lot times and some of the computation tricks that we can do to reduce that overhead ultimately okay thank you last question yeah when you talk about try to prevent to easier exist I don't know how technically you can do it and only thing I can think about is have the easier Wales sale of all the e so what and the property can prevent but I don't know how technically you can do it well you can technically do it if if they're the east between two portions of the system each one and eighty two are totally fungible and exchangeable then there is no need for an additional token to represent the system so if you have if you have eath one and you have e2 and you have ether over here and you have to go over here and they can't transfer then like very certainly if I have an exchange order book like I have I would have these listed as two different things but if there is a transfer mechanism between the two it's like having eath and different accounts or different like domains of accounts and so then you have like if you have fungibility there's no need for two tokens and if you did have two tokens listed on your exchange like certainly you could do that but they should trade at the exact same price because they are totally fungible with each other okay thank you and do have one more question over there all the different charts will have the same execution environments and what would be the way for someone to propose a new execution environment and getting that in right so the there's still some debate on how you expose execution environments to shards and whether there's optionality and doing that like whether an execution environment can be specified just for one chart or it's always for all shards but the the simplest proposal is for each execution environment you actually have shard count state routes associated with it so that it can be operated within each shard and have a state associated with each shard and the second part of the question oh how do you propose these so similar to deploying a smart contract on aetherium 1 and similar to maybe deploying a smart contract onto a shard deploying execution environment actually looks and feels and is extremely similar if not exactly the same to deploying a smart contract onto the beacon chain and so the there'd be some sort of special transaction to deploy this bit of code and deploy some sort of like Genesis state to the smart contract or to the to the execution environment but importantly because the beacon chain is sync is if you're syncing any part of the system you have to be syncing the beacon chain we have to bound this state size and bound computation on this thing so there would be some sort of high either lockup or high ether burn to be able to deploy things onto the beacon chain so some sort of like like either burn or type of a rent model okay because from what I was reading I didn't perceive it as being something that he can be done he never mentioned Liz Waid so that's that's great so it would be like dude applied your awesome blog for how Jurek's kitchen environment works on to the beacon chain and that gets kind of like propagated to desire someone to use right that's it becomes available to shards executes and when you make a shard block you specify the execution environment or the set of execution environments that it executes upon and the yeah the essentially look whatever whatever costs it costs you deploy to the Zippy containing these execution environments and needs to bound the state size of the contain thank you very much for your time if you have any more questions please feel free to talk to our speakers afterwards ok thank you very much