 Hello everyone, I'm Xiaowei from the research team and today my talk is about toward Eastern 2.0 Shodding universe. And also before it's complete and delivered, there is a gap between now and the end game. So what do we show built for it? So this is the well-known Eastern roadmap that I don't need to go through again. The outline is quite simple. All the spaces have its own goals and however from the design to production, there's actually like, it's actually like this. So in practical, it's like a twisted highway layer by layers and connected. So the the current approach is much better than the early Shodding and Casper design like in the 2017. And where there were no beacon chain between the East 1 chain and East 2 chain and the Shodding chains actually, they were depending on the East 1 chain. But however, even with the beacon chain, we still have to confer the backward compatible issues for it. And for the design areas, sometimes it's vertical and sometimes it's horizontal. And that I recall that back in 2017, research team has received some feedback from the community, from the client things that we should have more incremental listen in the design philosophy. That is to add more, to add many small incremental steps, step by step changes, instead of a few large sounder drums to compare this to different strategies. And for example, when we are building a city with incremental strategy, we should start from the base construction and then build the small houses. And then nearby the small houses, we build the higher buildings. That's the incremental plan it looks like. And for the sounder plan, with the sounder implementation, we would draw the blueprint very, very carefully and start to construct. And suddenly the castle just landed. So I'd say that the current approach in this tool is much more toward incrementalism design. But there's still something that we need to think about. So the disadvantage of the incremental design is that in the part of view, you can see that it might waste some time to build the face and faces. And there's also the Bico fallacy thing. You can see that Bico has a very, very good sense of the smell, but with a very limited eye sign. So it's possible the prey is just in front of them, but it's downwind. So they can't see the prey, even if the prey is very close to it. So it's that in the protocol design. So that's why we usually have to go back and forth and to fix problems that are hidden somewhere. Okay, so Yasek and I organized a survey recently. The survey was for the Eastern community, and especially the developers. And one of the questions is what core chain properties or functionalities do you want to see implemented in East 2.0 or East 2.1.x? So we got about 69 people answer this question. And I categorized them with some simple text as below. And the top three wishes, there are scalabilities, profile stake, and the gas and free model improvement. Those three different requirements. But in some point, they are overlapping. Sorry. They are overlapping in the East 2.0 design map. So I select some of the topics based on the top wishes today to introduce to you. And these three topics include the abstract and the stacking and aggregation. And some significant changes that will help them in the East 2.0 shading universe. So the first one is the layer 1 account abstract. So it has been discussed in the East 1.x as well that in the abstract account model, all contracts are for world contracts. So there's no all accounts are for world contracts. So there are two main strategies. One is the abstract we only abstract the signature. And another one is we do full abstraction include the nouns, gas and payment. And sorry. And with the guaranteed transactions. And also if we got into the East 2.0 EEs, we will have the each EE can have its own different exclusion environments. And also each environment can have different account abstract model inside it. So it's very fixed, flexible and very easy to plug into one to each other. And another topic I want to talk about is the EIP 1559. It's the free market model change created by Taliq and Eric Connor. And so in this scheme, we will have a dynamic base free value. And this value is addressed by the utilization rate. So if the utilization rate is over 50%, this spatial variable will be will increase. And if it's sorry, if the utilization rate is under 50%, this value will be decreased. So since it's updated automatically, it's allowed the user doesn't have to do more work on this. The wallet service can help to define the fair free for the users. So it actually essentially makes a lot of UX beta and the current state crawl. And also the best free is always burnt. This design rationale is to prevent the miner or the proposal from manipulating the free in order to extract more free from the user. So generally, it will be a more fair model than the state crawl. And before talking about the state king, I want to mention the Casper FHG again. So Casper FHG is the finality protocol for the S2O. So the validator, the duty of validator has three steps. One is to make deposit to the S1 deposit contract. And the second one is when the block has enough, has to vote for the current epoch, the current checkpoints. And if the checkpoint got enough votes we call that this checkpoint is justified. And also if the checkpoint is, if the checkpoint has the justified descendants, we call this block or this checkpoint is got finalized. So that's the basic of a data duty. And we also know that the misbehaved validator, they will get slashed. So what is slashed? Slashed is that it will, in protocol, deduct the validator's balance from the protocol. So after migrating to the full proof of state system, it will introduce a new economic model. So Colin Myers from Consensus has been working on this economic models for a while. And the model is based on the current foreign space. I encourage people, especially the economist, to take a look at his work and give feedback for the economic side. So similar to the mining pool, we can expect that there will be a staking pool in the near future. And if the validator are not online for a while and they can't finalize any checkpoints, so they will be penalized as well. So based on that, it's very important to have a stable networking environment for the proof of state validators. And the next topic is about the network latency. So this message are the most overhead of the charging network, including the attestations, which is the boat between the big engine and the short chains. And the second one is the transition. So the transition is only in the charging network. And also there are blocks, including the beacon block of there and also the short blocks. So and we have cross link. So the short block will point to the beacon block and the beacon block would refer to the short block sometimes. That's called the cross link. So the cross link is included in the attestation data per short chain and then got included in the big engine. So also the short chain has its own subnet, it's very clear, but sometimes the cross short networking communication is frequent. So with the latest, it's to make, we have four million validators, 64 stars per epoch and six seconds beacon block time. And we will lead to 64,000 individual signatures on the beacon chain. But the news is that this individual signature can be aggregated into the smaller message. And in the shorting network side, we have 64 kilobytes block data capacity and three seconds short block time. And it will lead to about like 21 kilobytes per seconds in per shot. So that's the overhead here. And about the networking layers, it's to all use the LEP2P as the base networking protocol. So under the networking layer, it's the peer connection. So the peer connection, it depends on the peer discovery protocol which you are using. And the true business logic is the message is broadcasting with the publish and subscribe system. So we use the gossip sub protocol to broadcast the subnet messages inside the short chains. So yeah, but imagine that if we have like 10, 1,064 short chains and about four million validators, it will be very large. And also, we will have to think about the peer-to-peer network topologists. So there are three possible cases which is the structured topologists and also the unstructured topologists. And that includes the flooding, gossip, epidemic and random work. So the gossip sub is included in this category. And also, it's possible to combine the structured and unstructured topology into the hybrid model. So this is an example of how can we implement it simply. So in this simple model, the validators are, they can broadcast the message inside the short by using the gossip sub protocol. And only the proposal of the given slot of the given shot, they are the only one who have to collect all the signatures for the given shot. So for the given shot. So the overhead only inside the subnet. And only the validators, only the proposals have to exchange the aggregated signatures. But this simple model has two counts which is introducing the validator privacy. And other nodes can need to trust the list proposals. And if the proposal doesn't do their work well, then the rest of the validators will lose the reward from it. So it's too easy. Another one is implemented by consensus research team. It's called HANDL. HANDL allows the aggregation of thousands of signatures just under a second. And organized, it's done by organizing the connection in levels. So it's more like a structured design. It's doing well but we also need to think more about how can we utilize the hybrid model more efficiently. So this tool is a collective but great work. So I think Justin just mentioned about that and I want to highlight again. So we have the EIP, Ease research, and magicians, and Ease tools make this out of sideline. You can find more deeper knowledge from it. And also there's a bounty initiated by Justin. And you can get five Ease if you found any bug from the current Bikan-Cheng spake. And finally I want to say that even we are facing, while the Bikan-Cheng protocol is almost done, there are some optimizations that kind things are working on. And generally I'm very optimistic of what's happening and exciting about how can we solve this problem in the next few stages. And okay, so I'm co-hosting a breakout with Yasec tomorrow morning. And if you are interested in knowing more about how the developer experience looks like in the phase one and phase two stage, please come with us and join the breakout session. And if you want to know more about these two discussions, there's a chance that if you travel after the Japan tour and you can come to Taiwan, there's a conference called Crosslink, and just typing crossing dot Taipei. Okay, that's the slide I created. Thank you.