# The Road to Eth 2, Phase 2 & Phase 2 Testnet (Devcon5)

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2020-10-09
- Duration: 22:38
- Topics: blockchain, smart contracts, distributed ledger, Science & Technology
- Watch: https://streameth.org/watch/yt-8yMh0Nxyqks
- YouTube: https://www.youtube.com/watch?v=8yMh0Nxyqks

## Description

By Will Villanueva, Matthew Garnett

Background
With the coming release of Eth 2 phase 0 and the beacon chain, it's timely to chat about the subsequent phases, phases 1 & 2. We've seen significant progress and movement in both.

Active Work:
- Scout https://github.com/ewasm/scout, an Ethereum 2.0 Phase 2 execution prototyping engine
- Phase 1 & 2 simulated test grounds to deploy execution environments and enable cross shard experimentation 
- Multiple stateless execution environments are currently being built
    - Ethereum 1 EE (ethereum 1 on ethereum 2)
    - Ethereum 2 focused EE (iteration on the ethereum 1 model)
    - ZK Rollups
    - Token Transfers
- Migration of Eth 1 into Eth 2 (Preliminary)
- Wasm as the language of Eth 2 and benchmarking progress
- Multiproofs, stateless systems, and partials
- Alternative proposals supporting scheduled computation and load balancing across shards
- Relay network and fee market to support Eth 2's stateless paradigm

Abstract
Phase 2 brings the shards to life - it is what introduces state execution via wasm, smart contract capability and more. We'll be sharing the current progress and thoughtspace behind phase 2. We'll also chat about the overlap between phases 1 & 2 (aka Phase One and Done) as a design/paradigm shift. Follow us for a chat on defining/introducing the current state of phase 2, terminology, and ways to get involved as a developer in building execution environments.

Slides here :
https://docs.google.com/presentation/d/159LsIOopETzlqYdsiz4wSI1CYasqMHxMF9DHayvCxW4

Devcon V: Day 1: Room 9

## Transcript

[Applause] so microphone in here so hopefully car with me I'll be drinking my apple juice here and talking about okay so can everyone hear me in the back excellent yeah I think people can probably just move up here people just want it yeah they went out and feel like this yeah these two front corners to zoom here people can sit up here - yeah so if yeah there are people like waiting outside I think people just [Music] [Music] cool well thank someone for coming again sorry you know this session is about twenty minutes will likely spend few minutes going over it to show a quick demo but first we want to get content out of the way so just that way so this is the road to eat soup is to and is to test this in general this talk and a lot of the work of phase two has mainly been a collaboration between two teams so and we're team that has formed under R&D within consensus and then he was a team yeah and so we have been working a lot of things in collaboration here and over the coming few days here at DEFCON with multiple sessions we're working together on so we'll come give an overview on that for this talk I'm going to breeze through a lot of things I don't expect everyone to necessarily follow every piece but I want to kind of just bring some of these ideas the more kind of a lot of people's minds and then I think over the coming months this content comes out and our things come out a lot of this would probably kick click a little bit better so okay gold talk will bring everyone up to date on phase two or phase two is at right now I've set some the terminology behind the current space and then share progress and a quick demo so I'm just doing it for those of you just to catch up real quick v-0 so basically if to split up into two main phases for launch three main phases there's phase zero which is a beacon chain which you can basically summarize is managing a lot of the overhead logic of the system even organizing layer manages finality z' of the shards it lets start to check themselves crosslink so they can communicate with each other and he can trust that the shard will never ever changed that reaches the point of finality so this time the vegan chain also manages those who are staking their funds and becoming validated Isabel it manages their duties these one is where we have the shards that come into play and here we really bring the shards to point stability and make sure that everything that's working and as far as shuffling these committees together can actually bring this thing to to a degree of stability in phase one will allow for data uploads so there's ways that each one can interface with with to just whether phase one is launched by itself phase two this is what I say kind of brings the shards to life this is where we have steena execution this is where we begin talking about things like spark contracts transactions across shards pieces like that so this is kind of breaks the systems of life and this is where you get the real utility so I'm going to give like a real quick summary of some things that are easy one and hopefully and draw that back that's a - so you guys are general understanding the space behind you - so then each one you can consider there to be one execution environment that's enshrine the evil one so basically there's a hard-coded transaction execution framework within if you need to change it you need a port so as an example a transaction he's one is nonce gas price gas limit to value data we do our LP encoding and then we apply a signature if we want to add a field or we wanna remove a field or change the field it's gonna require to work right also in each one we have this global state right this global state that includes everyone's accounts and in their accounts you have these fields not to balance storage or OH - that is organized into what we call a Patricia Merkle tree so if we want to change that accumulator that data structure if you want to add fields to the count structure if we want to remove fields then we're going to have to have a fork on the system so again what we're saying here is that we have everything kind of enshrined and hard-coded into each one so eat to kind of follows this radical shift and it's where we realize that we're consensus layer it doesn't necessarily need an opinion on that transaction structure doesn't necessarily need an opinion on what the global state looks like and in fact the court consensus layer is really good at ordering pieces really good at managing some of the parts being like validators flashings rewards for choice rules and defining the tooling for example means - we have e waz them as as the main set of tooling by which of execution happens either so it's really good at that and so any - we take kind of this radical shift though and we say we don't need an opinion on what a transaction necessary looks like we don't need an opinion on how this D is affected these things can be minimalistic and we can write these ourselves and so this is kind of a goofy diagram but I think it can be like really interesting and very illustrative so within each to on a single shard you could have multiple different basically frameworks that are running so we can have each one running on one shard we could have the UTS model a bit Bitcoin like model running on a shard you can have a roll-ups system on a shard we can have an eighth to a count model say we want to learn from each one use new accumulators make things a little bit more efficient have better structures can you build a new model that's geared towards e2 and Waze and centric we could have something like sexy we could run Libra on Heath two and so this is this is really cool you can set the semantics you had these execution environments to basically operate different fright attics and so some people might kind of think of it as you know maybe an interesting analogy is you can kind of create this execution space or execution environment that might be akin to basically provisioning different VMs that that set the semantics of what can occur one thing to keep in mind for example within this galaxy in f1 all these contracts can communicate with each other synchronously seeing within a account model and all these different pieces once you start communicating across these various pieces like me there would be asynchronous communication involved I'm so diving deeper what does this look like that they can chain stores a7 pure reducing functions which gives the rules by which transactions will run within an execution environment it down is this D and transitions to a particular rule so I'll kind of show you this so it is what you could consider there being a regular function here block includes a bunch of transactions so our data or our arguing that we passing the function is this transaction list it begins with the states we didn't do when we get a new stain s prime if we go into a stateless model which I'll talk about in a moment I'll breathe through breeze through you can call because we're putting in a pre state route hash and getting a posterior hash directly so what what we have in basically tune with in phase two we have this system where we can pull down these Waze of basically bounding constructs it's definitely set the rules of how you affect state and how transactions are coming in what the transaction looks like how its validated and then you can go ahead and bind each of these different models to to those two that wasnít script so we do not need one you can still model another account model that's running on Eve two of these can all go in tandem and they have the same key reduce attention um so right now we have Scout so Scout is something that was originally pushed forward by a by Alex and he wasn't even it's a prototyping engine where we can already begin building execution in fact it's these different execution environments that brought on 82 and we have a link here basically all it comes down to is what you saw the diagram is the process block function pre-state group takes block data's argument and we get a post a group or posting view into it so a couple things execution environments are not necessarily analogous to smart contracts they define an execution environment where start contracts came back basically they can define was I'm spawning otherwise I'm and I actually really liked it quote from Robert rust but he is e to abstract that fixed execution semantics have almost any conceivable programmable rock chain in a similar way to how easy one extracted the fixed semantics of digital tokens currency and of early launching at quaint era so this is really powerful you've run a lot of systems so he was a statistician happens in consensus to each shard everything is e wise them you want to gives you tooling and gives you a concept of gas limit metering host runtime functions that can be called so you can pass the beacon state the start state into your functions you can access a lot of these core utilities on a shard the state would likely have a list of hashes and those are the pre hashes of all these execution of parts that followed this reducing function so you know what the last date was so everything's stateless and so this this means that press with they've kind of talk in this right here this means that we do need some type of expensive mechanism in the system called state providers we might need real layers we may not there a lot of different Bolton that are in place right now and so but the stateless paradigm is interesting I'm just gonna break it down as quick as possible all this is that when you include a transaction you basically include the database with your transaction so if willkommen whele is transferring five shard to or if I eat to Alex as an example with my transaction I need to show a proof that my account looks the way it does when I'm Alex this account looks the way it does I'm sure that I have ID he has to show that we have to show that he has maybe to be things account and then we can make an update and we can update the state there so basically the stateless system you can consider each transaction comes with a database built in that rolls it to a murkily that has this official proof I won't go to refreshes but every execution time you can set up their own their own accumulators on different pieces so merging proofs this is if you have a bunch of transactions together they'll all have their own Cruiser what I said is you know the analogy is a database with your transaction you can kind of merge these together while giving funds jill 10 giving funds to mouth you have one proof you can just read from that and that would get such of all these accounts again this is a really high-level overview but hopefully it helps in in some way there's a switch over that happens so one seat two runs we're gonna bring each one and we're going to start running each one underneath to it so we call this the switchover there's work right now happening on building than ds1 execution environment that then we'll go ahead and run on one of the charts and underneath it to part of that one of the big pieces we need to build the EDM in Waze me which there is already some market going on around that and we want to expand these one to have more functionality to be aware of sharks crushed our transactions accountants traction a lot of work here to do if to eat the general definition of this is we want you to be compatible with these one running on it and running within a shard and being able to expand across multiple charts but there's a lot of things we've learned since then better accumulator formats that are better ways to structure things we also want to create a more wasn't centric system and so this is called we may be migrating towards this concept of an e to e e which is an iterated or improved version on some of the constructs that we have costco transactions again i'm going to kind of breeze through this there's basically gets run into a few different models we have asynchronous which we rely on the court protocol this is what it provides at the layer one level we have fast asynchronous these are somewhat complex systems where we optimistically make decisions and then we can have some synchronous systems as well this falls into delays in execution you could do even some form of roll-ups optimistic roll-ups hybrid later run into approaches for what the core protocol provides if you're doing any synchronous let's just talk about this as an example hom cindy ourselves a cello is solidity high-level programming languages VIPRE should provide proper tooling this means that imagine basically cross shard calls are akin to the concept of programming with the concept of threads so this means that in essence that tooling should be there for developers and as a developer is writing a smart contract they're going to have to be more aware of a synchronous systems message driven approaches one one thing that people have talked about is an actor/model two things commits emos blocking read/write these are all constructs you find across threads this is kind of how it was extracted in the system latency for these models are reduced to the time to finality so depending on there are some you know other poses that come but that is that is the limitation other changes in know that so deaths will likely be faster due to POS and sharding web 3d Thursday has to interface if you're doing with these one shouldn't actually chain it's not much under the foot it changes significantly but those libraries need to be updated to deal with some of the new execution environments like into execution environment we need more wise of centric smart contract languages this is also how it's going to affect the general dev acts should I don't eat eating so one question is are you protocol researcher or developer do you have an idea which only makes sense as in EE some type of flexibility you need that's outside of what exists in these core contract Wranglers and I would say but if you don't learn about this you may be left behind if you don't learn to leverage then your infrastructure to your advantage so this there will be a new kind of tier of developer which thinks of et which is more of a protocol flexibility enhanced layer and a smart contract developers as well so we've been working quote civically and also in tandem with that he wasn't even working on the simulators for phase one two so we already have this working we're able to simulate multiple shards being able show with the beacon chain it's a command line tool what we're building is not production focused so it builds local validators and keys it's not a network to test that it simulates Forks it simulates reorg the main goal of this is that the test ground for running a tease and simulating cross shark behaviors so with the simulator what the goal is is that we already do research and build these EES mimic cross our behavior mimic Forks mimicry orgs and with that we can already we can already have some development moving forward and what we would have with an actual phase two [Music] she is I mention this this is another tool Matt Matt bill which is kind of an early concept at what a state provider wheeler in might be it keeps the state locally and it communicates with block producers and builds these multi proofs of witnesses that you need in a stateless system and it's also tooling through doing the transfers their token so we've kind of already have an early early piece of that so there's a bunch of keys that he was in team and Cokely involved with and benchmarks I'm gonna let like Alex talked a little bit as well then we're gonna mostly show something upcoming talks so yeah can you guys see generally it's it's light enough yes my name is Alex I'm part of the wasn't engine is the things we have been most admitting in the past equipments the exception of she has done of course I meant so we have multiple motivations for doing these things one we wanted to prove that this can be done in the challenging time frame we have that unchain on a given pop absolutely motivation one motivation to is to give you guys the best practices had to buy des and had to bite optimizes etc so there are clear distinction between the two they're the first to disappear the super token they're kinda like compatible that they eat 1/3 structure but the poles and sheep are not so the first two and it doesn't it is not very useful but it's like in the baseline turbo thought there might be something that you could be used with this each one switch over and sheets and all might be used for pure e to dedicated e we have bunch Podrick next and however I really want you guys to keep an eye on these sessions and accommodate so tomorrow we have an hour and a half long session and he wasn't past present future we're gonna have a long talk about benchmarking where we gonna show all these numbers and all the response we have a bit in ease and that's a really good starting point to come to day three for the 2.0 talk now that's a two hour long session but don't be afraid it's it has a ton of small talks and you can explain all these is one by one and but before that we can have a long interval own version of word wheel has done today we also have a couple of minutes for Q&A between those sessions but the big place to ask questions is on the last day that's a 90 minute session to only have questions and nothing else and and tomorrow also there's this developer experience which Howie is really useful to you guys because that's really focused on and questions for getting great experience I'm not sure that you're gonna do the demo yeah yeah so long oh yeah so real quick so we'll do demo Matt's gonna like running all walk in an overview in the dev X will kind of get a similar talk to what I just gave that session and also in this he was a 2.0 session we're gonna give a very in-depth version of this demo and explain what we're building and what it is in the long term so come to that and we'll lecture some code and actually express that but I guess what we just want to show at this point is yeah go for it yeah at this point is that [Music] yeah so what we're gonna show at this point is that we have these like systems running real quick let's just be like a minute so what we do the simulation in this case were fast boarding the beacon chain to move to these ones working epic so this is occurring to the lighthouse guys loving the logs so now we have shark chained zero running that's operating so we actually have an execution environment running on the shark chain right now and it's completely stateless so we are managing state via this tool or this binary which is akin to what a state provider may have in the long term so they already a progress on this and also the goal is that we can run all the EES that we just talked about Alex shared within this simulation as well and we can continue to stand and so I prostrate behavior so in this case we can set up a transfer of proof is set up locally you have a global version of the state you send it to a block producer so we have endpoints to interact with block producers and to interact with the system as a whole and the new route is set up and then you can look at the tool track for balance and this is really cool we have this running and so we're pretty close from already doing basic operation of smart contracts so we already have kind of a a prototype that actually built this it's really cool that has that's able to continuously spawn continued watching and so I think you know before the new year around the new year will already you know have some basic contracts running on this this will be expanded there's a lot of cleanup I want to make this a and friendly tool that's very configurable and is running 16 shards at once and then people begin doing this little I would say general timeline to get into a really clean state we're looking at at some time by the end of this year or in January and hopefully by that point we can have some peace we'll have some basic contracts going you guys have any questions let me know follow me during the conference most of all attend those sessions yeah it's gonna be a lot of stone and still we're excited [Applause] you