 Thank you. So I'm going to talk about Syngrity on our subject. I'm still not familiar to pronounce that name, so I might still use the word Shaspur interchangeably in this talk. But Syngrity was the Ethereum 2.0 current code name. Previously it was called Shaspur, so we just named our Ethereum 2.0 current Shaspur as well, because no one was taken that day. And I'm going to do a sort of deep dive into this code base. It's going to be a little bit technical, but first something about me, I'm a Rust developer as a query technologist, and Shaspur is a beacon chance. Syngrity beacon chance built on top of the subject. So first some disclaimers that this is only about beacon chance, because Ethereum 2.0 is a large project, and there will be many phrases to be carried out. The first phrase is 3.0, and we will get a beacon chance hopefully soon enough, but just know that on this beacon chance, in 3.0 at least, there will currently be no sharding, not yet, we don't yet have that. And another disclaimer is our code base was actually quite old, it was written when the 2.1 specification of beacon chance came out, and we still have some part of it still in our runtime, so our code is still like 60 or 80 percent spec 2.0, but this will be based on the newest current spec. And it's also, I'm not going to be like really deep into the beacon chance specification, but I will touch some of it, but this will be more about the Shaspur's implementation, how we built it on top of Safari. I was asked to make this talk biotechnical, hopefully I did it, but most of the time, if you are really familiar with Ethereum 2.0, you probably find this Shaspur story, or if you are really familiar with the script, and not the author of the beacon chance spec or the script, so this part is based on my current understanding, and some of them may be wrong, so it's only 90 percent correct. And just if you are not familiar with those names, so Serenity is going to like try to solve the current Ethereum's really pressing problem, scanning issue with shading, and we are doing that in the first 3.0 through beacon chance, we also have the shiny Shaspur profile state, and Substream is a general blockchain framework that we build at Safari Technologies, so we write everything in full rust, and it's also really related to WebAssembly, which I will talk about a little bit later. But first, it's still about Serenity. Serenity is like the really bare minimal thing, like we don't have anything else, it's just bare minimal to gather and like we want to do further shading, or the actual, like you can actually do state transactions, stuff like that in 3.1 and 3.2, but right now we are just trying to lay out the foundations and make the future work of Ethereum 2.0 easier. So what we have actually in the beacon chance 3.0, so we have one is transfer function that allows you to transfer money from the Ethereum 1.0 into the beacon chance, this is actually more like a board, like your money is rather lost in the Ethereum 1.0, and it stores the validator states and balances, basically this is needed for the proof of state consensus, and also handle the reverse, and those biothermic attachments, and this attachment is to make, justify and finalize block, and those are all terms in CASPER, which I will talk about later, but this is also part of the proof of state algorithm, and we also have some slashing conditions, it's also for the CASPER consensus algorithm, that's for the validators, and yeah, and of course we have CASPER for transfer, and CASPER is actually like the actual definition doesn't really touch the proposers there, but we need a way to make proposers, so currently we have the RANDOL algorithm to do that, which is just getting some random function that allows you to choose a proposer on the chat box, there are some security vulnerabilities, there are also solutions, but right now we are not going to implement, we are probably not, the spec is not the finalize, but from what I understand right now we are just using RANDOL to select proposers, so the thing is, nobody is able to make transactions on a bigger chain, and the only thing you can participate in is become a validator and a test block, propose blocks, but we need a new blockchain, so we need a new blockchain plan, now what do we do? So a blockchain contains a lot of functionalities, the most important part is probably state transition and consensus, why I call it the most important is because that's what, if you're currently looking to the Bitcoin chance specification, this is what you will find, you only find state transition and consensus, and in the future we will also need to figure out, like in the really short term future, we will also need to figure out how our clients actually communicate with other peers, and so we will also have a specification for networking, but the issue is we have all the other parts that we actually need, that is kind of general because we, like if you don't, there's no special specification for that, then we can just use any framework to do that, so the issue is, like you can see, this part we can actually roast them several times, or millions of times, like in party serum, in gas, in other full node plans, however the issue is reusing the code, like reusing this Bitcoin or other transaction queen, or the blockchain part, or the other logic is not very easy, the issue is that the data structure we have is actually really pinned to the state transition and consensus part, so we can't just directly take out like a transaction queen and use it in another plan, and also for Bitcoin Chan, everything is vastly different, like all the block structures are different, the way the consensus work is also different, so there's probably nearly nothing in common, and yeah, exactly, the healthy algorithm which is still the KAC, 2.5.6, and if we want to do it, like you know in 16 plans, like in party serum, you also add a lot of additional complexity that is really hard to handle, so actually this is not the only case, this is not the only case where people try to, like for us we try to first research for the Bitcoin building in party serum, and for teams which tries to build a Bitcoin Chan client, like the Harmony team, they also try to write the Bitcoin Chan client first on an existing code base, but it also doesn't quite work out, so we like this two tries, either we can start from scratch, write a new client, write all the other stuff we need ourselves, or we can try to build it in substrate, so of course we first try the second one because it's easier for us, and what we get from substrate, so we get light plant and web assembly by default, the substrate framework is built with the light plant in mind, so you always have some light plant functionality to work with, and also the web assembly is used to run the runtime, and we get all the hard parts that people just want the default implementation, like we just want a backend, a state backend that works, we just want the transaction current that works, and also the basic Chan syncing, and also the basic JCNRTC stuff, so it's a mostly genuine log time framework, and we actually have a lot more, but probably not covered in this talk, so this comes to our current Shaspard topics, so we have basically, we just need to implement three things, of course there are some comments that we also need to add some supporting steps to it, but basically we just need to implement three things, the runtime consensus, and first things, also the validator logic, but currently we don't yet have the validator logic, and the other things can hopefully all be handled in separate, so we don't need to write it again. So first about the runtime, so if you're familiar with how blockchain works, this line is probably boring, but basically you have a child block, but those blocks will also have a state associated with them, and how we'll transit from one state to another is through a state transition function, so in subtree we call this state transition function also a runtime, so how does it work in subtree, so for subtree we call several functions that can be carried, like I will show an example later, and we talk with the state backend, like if you need to actually start something in the state, you use the state backend, and we make it so that this runtime always will be natively and in WebAssembly both, we also make sure the WebAssembly backcode is written into the state, so this is just so that it is easier to talk with other structured blockchains, and we want to make sure that the state transactions are always deterministic, so I will also talk about it later. So just an example, how things are already defined in subtree, so we have like, these are extra functions that can be carried from a client to a runtime, so for example if a client wants to send a block and further the state transition function, we'll just call the runtime and call this execute block function, or if we want to build a new block ourselves, we want to propose a block, then we use, our client is extrinsic, finalized block is heard in extrinsic, those functions is within the blockchain to generate a block and go further. So we have a few assumptions in subtree, a block is always structured at least with header and extrinsic, we have a few more, so other terms, but there are no other problems here, so we want to make sure that if we have a header, then we want to make sure that it can always be generated from the latest state, or when the transaction, the state transaction is finalized, and we want to make sure that the so-called extrinsic comes in with a certain output, but like, nearly none of the blockchains are outside of a subject flow, for example, in the different aspects, they only have this current route and state route that can be statically generated either when we build a block or we finalize a block, but for this slot, or for this window review, for the assuming one data and for signature, it's always required some external input, so how, you know, there are also like a lot of other stuff in the different aspects in the block body, so what do we have here is that content external output, so the solution is just to move them between extrinsic, so we split extrinsic into two parts, first we call it the inherent intrinsic, which is where we have one prototype, and we generate it internally within the client, so these states are things like the window review, the slot, and the assuming one data, so they are externally inputted into the runtime, and we have actual transactions, which this currently actually includes a Titan, and also slashing, deposition, those kind of stuff in the different channels, so this is how the current intrinsic look like, so like in the actual test, so first we call the, we get some extrinsic data and we call the inherent intrinsic function, which will actually generate an intrinsic for us to push, and this extrinsic will be pushed to the hider's block body, and when we do the, and then when we apply the extrinsic with this transrider as a subsistic, like extrinsic with transaction that they have the actual same thing, so this is the substrate adapter design, so now we have a block structure that looks different when stored internally, when in the specification, so in this case we just generate adapter method that converts this internally, those internal representations into the specification representations, and this of course comes with some performance penalty, but as long as we have all the hatches that can be computed cheaply, then everything should be fine because we are just moving a bunch of values around, there's also the muti-tri support in South Korea that aims to solve this problem, this is mostly for things like, if we need to store a list, or store like a map, but that list or map also has a specification representation, then we will need to do something called really fine, so that's about runtime, and next is about consensus, so for consensus, this is a brief overview of how the Caspers FFG works, this is the current consensus algorithm in Dickenshan, we might switch to Caspers CDC, but nobody's sure about that yet, so how the Caspers FFG works is basically we have a list of validators, and those validators would test block that they think is the next hack, and if a client finds out, okay, enough validators test this block, then this from block and to block from a super majority link, and in some conditions it's then, if some conditions for the super majority link holds, then we mark a block, and as justified, if some further condition holds, then we mark the block as finalized, so in this case we, if no more than two thirds of the validators validates two slashing conditions, then we will always make sure that we don't finalize two blocks at the same slot, so in that case there are those other properties that we make that is BFG-6, so for consensus right in the current Caspers FFG base, with all the slashing and the violation, a test violation logic can be done just in event time, and sometimes we need additional information that doesn't actually meet in the spec, but we also put them into the runtime, because those information are needed by consensus, and this currently we only have one instant, if the latest tests the information from different validators, so how do we actually do the consensus as a first-price rule, so we just delegate everything into a tree like this, which you would call block, like all the important calls, you call block function first, and this import function can then decide, okay so whether I want to upset this block, whether I actually want to set this block as a final term or it's just a leaf, things like that, and this is a straight line, we always have the most of the control for it, so in this case how do we validate the 1.0 data, so we use the inherent extrinsic, but because the logic is kind of in worst, which you need to have the get into the runtime first, and then in the runtime validate it, but of course we can't do the validation in runtime, because in that case the runtime wouldn't be very deterministic, so in this case we make the consensus layer, handle the validation and use that for whatever source it belongs to, so in that case the runtime will just accept whatever value it gets from the 1.0 data, but the consensus layer will handle the validation and actually reject block if the 1.0 data that we have. So the source can be different like we can use party theorem, we can follow it with party theorem or we can just do it through an RTC point or anything else. Another thing about consensus is how do we deploy hardfork for Shaspard, the issue is we wrote the WebAssembly backcode into the state, so how do we change that, the solution, probably there are better solutions, but clearly the thing I'm thinking about is to just upgrade using a very extrinsic, and in this way the consensus layer, yeah the consensus layer, if we want to import it in a particular block, then the consensus layer can actually, can just reject in that particular block, if we don't have this extrinsic thing, we consider the block to be united. And about the results, and I mentioned there are three things we need to implement, but what about networking, so currently there is no noise specification yet, so I'm thinking we can't talk with others, even Chan Chan yet, but because something has its own network layer, so we can spin up a local test site or things like that, but once the specification is out, then we probably will just plug it into the network layer, or in the worst case they will just create a new network layer and use the external function manually to get the block data from a bigger Chan Chan. Yeah, so that's basically it, any questions?