 There's no microphone in here, so hopefully there with me I'll be drinking my apple juice here and talking as loud as I can. So can everyone hear me in the back? Excellent. Awesome. Okay. Yeah, I think people can probably, there's room up here if people just want to, yeah, they can just go ahead and fill in this, yeah, these tooth-wrung corners. It's the room here. People can sit up here. Yeah. So if, yeah, there are people like waiting outside, I think people just keep coming in and probably have a little space of thought and just stand over here and walk over here. Yeah. Cool. Alright. Cool. Well, thanks everyone for coming. Again, sorry for having to be here with me. It's my voice. So this session is about 20 minutes. We'll likely spend a few minutes going over it to show a quick demo. But first we want to get the content out of the way, so just f-y-y. So this is the Road to Eath 2, Phase 2, and Phase 2 test net. In general, this talk and a lot of the work on Phase 2 has mainly been a collaboration between two teams. So folks, and we're a team that has formed under R&D within consensus, and then EWASM team at Eath. And so we have been working on a lot of things in collaboration here. And over the coming few days here at DevCon, we have multiple sessions that we're working together on. So we'll kind of give an overview on that. Before 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 to the forefront of a lot of people's minds. And then I think over the coming months, as content comes out and more things come out, a lot of this will probably click a little bit better. So, okay, go talk. I want to bring everyone out to date on Phase 2, where Phase 2 is at right now. Set some of the tournament knowledge, find the current space, and then share progress in a quick demo. So I'm just going to, for those of you just to catch up real quick, Phase 0. So basically, Eath 2 is split up into two main phases for launch, three main phases. There's Phase 0, which is the beacon chain, which you can basically summarize as managing a lot of the overhead logic of the system, be it an organizing layer, manages the finalities of the shards, it lets shards check themselves in via cross links so they can communicate with each other. And you can trust that the shard will never, ever change. It reaches a point of finality. So this is kind of the beacon chain. It also manages those who are staking their funds and becoming validators as well. It manages their duties. Phase 1 is where we have the shards that come into play. And here we really bring the shards to a point of stability. And make sure that everything that's working and as far as shuffling these committees together can actually bring this thing to a degree of stability. In Phase 1, we'll allow for data uploads. So there's ways that Eath 1 can interface with Eath 2 just when Phase 1 is launched by itself. Phase 2, this is what I say, kind of brings the shards to life. So this is where we have data execution. This is where we begin talking about things like spark contracts, transactions across shards, pieces like that. So this kind of brings the system to life. And this is where you get the real utility out of Eath 2. So I'm going to give a real quick summary of some things under Eath 1. And hopefully we can draw that and connect that to Eath 2. So you guys have a general understanding of the space behind Eath 2. So in Eath 1, you can kind of consider there to be one execution environment that's enshrined in Eath 1. So basically there's a hard coded transaction execution framework within Eath 1. If you need to change it, you need a fork. So as an example, a transaction Eath 1 is non-scas price gas limit to value data. We do RLP encoding and then we apply signature. If we want to add a field or we want to remove a field or change a field, it's going to require a fork, right? Also in Eath 1, we have this global state, right? This global state that includes everyone's accounts. And in their accounts, you have these fields, non-scalant storage with codash. That is organized into what we call a Patricia Merkel tree. So if we want to change that accumulator, that data structure, if we want to add fields to the account 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 Eath 1. So Eath 2 kind of follows this radical shift. And it's where we realize that the core consensus layer doesn't necessarily need an opinion on that transaction structure. It doesn't necessarily need an opinion on what the global state looks like. And in fact, the core consensus layer is really good at ordering pieces, really good at managing some of the parts behind validators, slashings, rewards, fork choice rules, and defining a tooling. For example, in Eath 2, we have EWASM as the main set of tooling by which execution happens under. So it's really good at that. And so in Eath 2, we take kind of this radical shift, though, and we say we don't need an opinion on what a transaction necessarily looks like. We don't need an opinion on how the state 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 really interesting and very illustrative. So within Eath 2 on a single shard, you could have multiple different, basically, frameworks that are running. So we could have Eath 1 running on one shard. We could have a UTXO model, a Bitcoin-like model running on a shard. We could have a roll-ups system on a shard. We could have an Eath 2 account model. Say we want to learn from Eath 1, use new accumulators, make things a little bit more efficient, have better structures. We could build a new model that's geared towards Eath 2 and WASM centric. We could have something like Zexi. We could run Libra on Eath 2. And so this is really cool. You can set the semantics behind these execution environments to basically operate different frameworks. 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 set the semantics of what can occur. One thing to keep in mind, for example, within this galaxy of Eath 1, all these contracts can communicate with each other synchronously. Same with an account model and all these different pieces. Once you start communicating across these various pieces, likely there would be a synchronous communication involved. So diving deeper, what does this look like? The beacon chain stores a set of pure reducing functions, which gives the rules by which transactions will run within an execution environment. It gowns the state and transitions to a particular rule. So I'll kind of show you this. So in Eath 1, you could consider there being a regular function here. A block includes a bunch of transactions. So our data or our argument that we pass through the function is this transaction list. It begins with a state. We get a new state, S prime. If we go into a stateless model, which I'll talk about in a moment, I'll breeze through. You can call this a pure function because we're putting in a pre-state root hash and getting a post-state root hash directly. So what we have in basically Eath 2 and within Phase 2, we have this system where we can pull down these WASM, basically bounding contracts that set the rules of how you affect state and how transactions are coming in, what the transaction looks like, how it's validated. And then you can go ahead and bind each of these different models to that WASM stream. So we can have Eath 1, UTXO model, another account model that's running on Eath 2. These can all go in tandem and they have the same pure reducing function. So right now we have Scout. So Scout is something that was originally pushed forward by Alex and EWASM team and it's a prototyping engine where we can already begin building execution environments, these different execution environments that run on Eath 2. And we have a link here. Basically, all it comes down to is what you saw in the diagram. There's a process block function with a pre-state root, takes block data as an argument, and we get a post-state root or post-state view into it. So a couple things, execution environments are not necessarily analogous to smart contracts. They define an execution environment where smart contracts can run. Basically they can bind WASM spawning other WASM and I actually really like the quote from Robert Drost. With EE's, Eath 2 abstracts that fix execution semantics of almost any conceivable programmable blockchain in a similar way to how Eath 1 abstracts the fixed semantics of the digital tokens currency in the early blockchain Bitcoin era. So this is really powerful. We can run a lot of systems on Eath 2. So EWASM, state execution happens within the consensus to be shard. Everything is EWASM. EWASM gives you tooling, it gives you a concept of gas limit, metering, host runtime functions that can be called so you can pass the beacon state with shard 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 environments that follow this reducing function. So you know what the last state was. So everything's stateless and so this means I pressed with Dave kind of a talk in this earlier, this means that we do need some type of incentive mechanism in the system called state providers. We might need relayers, we may not. There are a lot of different pulses that are in place right now. But the stateless paradigm is interesting. I'm just going to 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 Wilville and Oweva is transferring five shards or five ETH to Alex as an example, with my transaction, I need to show a proof that my account looks the way it does and that Alex's account looks the way it does. I have a show that I have five E. He has to show that, we have to show that he has maybe two ETH accounts 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 into a Merkle rule that has this official proof. I won't go into refreshes. But every execution environment can set up their own accumulators, own different pieces. So merging proofs, this is if you have a bunch of transactions together that all have their own proofs or what I said is the analogy is a database with your transaction. You can kind of merge these together while giving funds to Jill, giving funds to Mel. You have one proof and you can just read from that and now we can touch all these accounts. Again, this is a really high level overview but hopefully it helps in some way. There's a switchover that happens. So once ETH2 runs, we're going to bring ETH1 and we're going to start running ETH1 under ETH2. So we call this the switchover. There's work right now happening on building an ETH1 execution environment that then we'll go ahead and run on one of the shards in under ETH2. Part of that, one of the big pieces, we need to build the EVM in Watson, which there is already some work going on around that. And we want to expand ETH1 to have more functionality to be aware of shards, cross-shard transactions, account extraction, a lot of work here to do. ETH2EE, the general definition of this is we want ETH2 to be compatible with ETH1 running on it and running within a shard and being able to expand across multiple shards. But there's a lot of things we've learned since then, better accumulator formats, better ways to structure things. We also want to create a more wasm-centric system. And so this is called, we may be migrating towards this concept of an ETH2EE, which is an iterated or improved version on some of the constructs that we have. Cross-shard 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 core protocol. This is what it provides at the layer 1 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 delayed state execution. You could do even some form of roll-ups, optimistic roll-ups, hybrid layer 1 and 2 approaches. For what the core protocol provides, if you're doing asynchronous, let's just talk about this. As an example, HLLs and DSLs, HLLs, solidity, high-level programming languages, Viper 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 asynchronous systems, message-driven approaches, one thing that people have talked about is an actor model, two-phase commit schemas, locking read write. These are all constructs you find across threads, and this is kind of how it gets abstracted into the system. Latency for these models are reduced to the time to finality. So depending on the proposals that come, that is the limitation. So DAPS will likely be faster due to POS and sharding. Web 3, Ether's JS interface, if you're dealing with ETH1, shouldn't actually change that much under the hood. It changes significantly. But those libraries need to be updated to deal with some of the new execution environments, like ETH2 execution environment. We need more wasm-centric smart contract languages. This is also how it's going to affect the general DAPS. Should I fill in an EE? So one question is, are you a protocol researcher or a developer? Do you have an idea which only makes senses in EE? Sometimes with flexibility you need that's outside of what exists in these core contract frameworks? And I would say, but if you don't learn about this, you may be left behind. And if you don't learn to leverage, then you're infrastructure to your advantage. So there will be a new kind of tier of developer which thinks of EE, which is more of a protocol, flexibility-enhanced layer, and smart contract developers as well. So we've been working close specifically and also in tandem with EWASM2. We've been working on a simulator for Phase 1, too. So we already have this working. We're able to simulate multiple shards in communication with the beacon chain. It's a command line tool and what we're building is not production-focused. So it builds local validators and keys. It's not a networked testnet. It simulates forks. It simulates reorgs. The main goal of this is that it's a test ground for running EE's and simulating cross-sharp behaviors. So with the simulator, the goal is that we can already do research and build these EE's, mimic cross-sharp behavior, mimic forks, mimic reorgs. And with that, we can already have some development moving forward in what we would have within an actual Phase 2 development time. When it shows. Sheath is, you mentioned this, this is another tool that Matt built, which is kind of an early construct of what a state provider or wheeler 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 for doing the transfers to tokens. So we kind of already have an early piece of that. So there's a bunch of EE's that EE was in team and put involved with benchmarks. I'm going to let Alex talk a little bit as well and then we're going to also show some upcoming talks. Can you guys hear me? Is it loud enough? Yeah, so my name is Alex. I'm part of the EE was in team. This is the things we have been mostly doing in the past couple of months. The exception of Sheath that's done, of course, by Matt. So we have multiple motivations for doing these things. One, we wanted to prove that this can be done in that challenging time frame we have. So that means there's a time we can spend on chain on a given block. So that was motivation one. Motivation two is to give you guys the best practices how to write EE's, how to write optimized EE's, et cetera. So there is a big distinction between the two there. The first two, there's something in the turbo token. They're kind of like compatible with the E1 tree structure but the poles and Sheath are not. So the first two, I mean, SMPT is not really useful but it's like a good baseline. Turbo token might be something which could be used with this E1 switchover. And Sheath and poles might be used for a pure E2 dedicated EE. We have a bunch of other things. However, I really want you guys to keep an eye on these sessions in the coming days. So tomorrow we have an hour and a half long session that E1 was in the past and future. We're going to have a long talk about benchmarking where we're going to show all these numbers and all the results we have with the EE's. 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 has a ton of small talks. And we're going to explain all these EE's one by one. But before that we're going to have a long intro, a long version of what Will has done today. And we're also going to have a couple of minutes for Q&A between those sessions but the big place to ask questions is the AMA on the last day. That's a 90 minute session to only have questions and nothing else. And tomorrow also there's this developer experience which probably is really useful to you guys because they're purely focused on questions regarding the developer experience. I'm not sure that you're going to do the demo now? Yeah, yeah, so we'll do the demo. Matt's going to like run it and I'll give an overview. A couple things in the DevX we'll kind of give a similar talk to what I just gave that session. And then also in this EE was in 2.0 session we're going to give a very in-depth version of this demo and explain what we're building and what it is in the long term. So we'll come to that and we'll just code and actually express that. But I guess what we just want to show at this point is... Yeah, yeah, go for it. Yeah, at this point is that... Yeah, so what we want to show at this point is that we have these systems running real quick so just be like a minute. So what we do with the simulation in this case we're fast-forwarding the beacon chain to move to the phase one fork epic. So this is occurring. See the lighthouse guys loving the logs. So now we have a shard chain zero running that's operating so we actually have an execution environment running on the shard 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 we already have a progress on this and also the goal is that we can run all the EE's that we just talked about Alex shared within the simulation as well and we can continue to expand and show across shard behaviors. So in this case we can set up a transfer, a proof is set up locally, you have a local version of the state, you send it to a block producer so we have endpoints to interact with block producers to interact with the system as a whole and a new EE route is set up and then you can look at the tool check 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 prototype that actually built this and this is really cool that's able to continuously spawn and continue to watch it and so I think before the new year around the new year we already have some basic contracts running on this this will be expanded, there's a lot of cleanup I want to make this a clean and friendly tool that's very configurable and is running 16 shards at once and then people can begin doing this I would say general timeline to get it to a really clean state we're looking at some time by the end of this year or in January and hopefully by that point we'll have some basic contracts running if you guys have any questions let me know follow me during the conference most of all, attend those sessions yeah, there's going to be a lot to show so we're excited