 So my talk is about building the Ethereum 2.0 short substrate. So before I go into the talk, a short introduction of me. I'm Wei Tang. I'm a call developer at Party Technology, and I work on Ethereum and Ethereum 2.0. So we really want to in this talk talk about how we got involved into Ethereum 2.0 and some quite hard lessons we learned in the process. So like our journey for Ethereum 2.0 is really about building a generic blockchain framework because at Party we build a lot of blockchains, and we really want to make sure we don't write too many duplicate codes. So the first thing I remember for the Ethereum 2.0 was the hybrid Casper. I said time we were experimenting with building, having a generic engine design in our Party Ethereum plant. So we have support for finality and real-time support for custom fortress rules. So in that case, adding the hybrid Casper FIJ turns out to be quite a relatively easy task. So we had a working hybrid Casper implementation quite early, and it actually works. So but later it comes to the second phase, which is we decided to build a separate blockchain for Ethereum 2.0. So for us, we moved to the beacon-subject runtime. So for the hybrid Casper, there's really some performance issues, and we had to abandon that to create a separate blockchain for Ethereum 2.0. And what I mean by beacon-subject runtime is basically beacon-chan isosubject runtime. So I really want to go into some of the details of how we think the beacon-chan can work on subtree runtime, but before that, probably a really short introduction about the subtree runtime. So subtree is an engine to build blockchains, and we figure out that there are two main things that every blockchain needs. It's basically consensus and state execution. It's really hard to generate the consensus part, because different consensus can require different, like, entirely different structures, like some consensus need finality, some don't need finality, some consensus need to just need the past block or something, and other probably need to like to refer back to a lot of previous block. And also, some consensus need to have a lot of accelerated data. Some doesn't really need that. And also, we have those vast majority of different folks trying to do it. That's really hard to generalize, but we have some helpers. And the second part is state execution. So we figure out we probably can generate the state execution part, and we just call it runtime. So we have our current subtree runtime design has some fixed things. Like, we have a definition of block. We have something like extrinsic, which includes what we all know called transactions, and the other part is the inherent intrinsic, which includes things like timestamp, satellite guide, and we also have digitized item, which is similar to LOX in serum. And we have a definition of runtime externalities, basically how the runtime talk reached the outside world. So we have all these things, and they have some different structures. And one thing we want to figure out is how we can reuse those structures and make it work for building our assume 2.0 client. Because if we can do that, then we can reuse a lot of the subtree contract and get something for free, like the networking or the subject light plan particle. So what we end up doing is we create a vapor block. This is basically says that we create a separate block definition. This block definition, we call it vapor block, follows a subtree definition of what a block is. Basically, there's a defined structure. And we also have the unmodified beacon block. And for each beacon block, we make sure that there is a unique corresponding vapor block. So in that case, given a beacon block, you can always generate a vapor block, but you might need some past block data. It may not be so trivial, but it should be in theory possible to generate a vapor block. We also have a vapor state, which also is a vapor structure on top of the beacon state. And this vapor state follows a subtree definition. And the state is basically a Markov tree. And this Markov tree also has a definition in a subject. And what we do, and that Markov tree is different, is currently different than what is defined on Ethereum 2.0. So what we do, we define a child tree. And this tree structure is exactly the same as the beacon tree structure. This is like a working library you can use on separate. So we define a child tree. And in this child tree, we'll follow exactly what the beacon block is. And we store the actual beacon state in the vapor state. So there's always a child tree, which has the exact state root of the beacon state. And we wrap it with some other state, probably some cache or other information that such we need. So to look into the actual thing, it will be like this. Like this is a standard beacon block. We have the slot definition, block root, state root, block body and signature, things like that. And for the subtree block, we basically make it like this. So you can say some of the items are exactly the same as what is on the beacon block. So there's a unique corresponding. And for stuff that doesn't have a definition that is consensus-specific, for example, the slot and the signature, we just put it on the digits, because it's in the header, it's always readable, no matter if you're a full clan or a light clan. And the last thing we need to care about is this state root, because in the end, we need to verify this block structure. The issue is, even if there's a unique correspondence, this signature is still a beacon block signature. So it doesn't verify this state root, but instead it verifies a beacon block state root. So in that case, we need to find a way to make sure that we can also verify this state root. So how do we do that? We basically, it's not shown here, but we basically create a second dedistractor that creates the proof. So an additional, the state proof that goes from the beacon state root into the subject state root, the vapor block state root, that we need. And while we're doing this, so this is all about reusability. So when we create this vapor block and we create a consensus engine in Subject, we can then just directly plug it into Subject and it will work with the rest of the subject code base so we can get a separate networking and also the subject light plant component for free. And that we'll be working on in certain 2.0. So we need to have some obstacles. That's why, so the issue is we try to do too early of this thing in the specification process. The issue is, at that time the specification is still changing a lot and that creates a lot of problem for us because for each new release, we are basically rewriting everything. And that kind of slowed down the process quite a little bit. We still lack a little bit of primitives. We have the child marco tree structure, but we currently don't have a binary marco tree child tree set up, so that thing that is we are adding. The BRS works on the runtime by itself, but the issue is if we don't add new primitives, the BRS will be too slow for production. So that's also some primitives we need to add. And because we are kind of not too fast on that, the current plans is we do a two-client setup. So basically, we have the subject runtime plans still in place, but we still want to catch up with the rest of the team. So what we plan to do is we want to build a beacon corp and we want to plug the beacon corp. In the future, we want to plug this beacon corp into the subject runtime. But currently, we are also using this beacon corp to build an Ethereum 21.0 client without subject runtime. But we are still trying to use a limited set of subject components so that we can reuse things and not write too much. And later, still using this beacon corp, we want to build a full subject runtime on top of it. So this two-client setup is basically one with subject runtime and another with not. And we didn't join the interim on site, but I tried to hack it at home, and it mostly works last month. So basically, we are talking about writing generic clients and for our Ethereum 21.0. So in the beginning, we have hybrid Casper, which unfortunately, we need to abandon because of performance issues. And later, we decided to build beacon chain on a subject runtime using what is called a Viper block. In this way, we can reuse a lot of the subject components. And our current plan is to build double clients. Basically, the first client is for without subject runtime to catch up with the midnight release and the rest of team schedule and another with subject runtime so we can continue to explore building a really generic blockchain framework for everything. So that's all. Thank you.