 Yeah, hello everyone, I'm Robert. I work primarily on a project called PokerDot, but I work a lot with Parity Technologies. I'll be talking today about Parity Technologies' work on not Shasper, very sorry, on Serenity. Basically, what we've been doing so far, we're building it on this platform called Substrate. First, I'm gonna go into what that is, a little bit of background on Sharding, on Casper, on Serenity, Vitalik and Justin, and the others can explain that way better than I can, so I'm sure you've seen their talks as well. And then basically dive into what we've been doing, what we are doing in the future, and what we're doing now on building out all of that. So a lot of you might have heard recently there's been some buzz about Parity Substrate. So what Parity fundamentally is is a blockchain development outfit. We're a group that's built a lot of different nodes for a lot of different chains, so the best known one is the Parity Ethereum node. It's the, other than the Go Ethereum client, it's the most widely used Ethereum node. It's used by infrastructure, it's used as a light client, it's used in a lot of different ways. It's not just an Ethereum node, it supports all kinds of different consensus algorithms and stuff as well. We've done a Bitcoin implementation. Recently announced is that this is soon going to be also modified somewhat into the first alternative Zcash implementation. So we're a blockchain development outfit. And at some point we realize we've been writing these nodes and we're duplicating a lot of the same work over and over again. So stuff like synchronization, peer-to-peer networking, database, Merkle trees, light client algorithms, that kind of thing. It's actually a lot of infrastructure that you have to build around. Ultimately what you really care about is a blockchain developer, which is the state transition system that you're putting together. So that's basically what Parity Substrate is. It's something like a blockchain in a box that you can build a chain with. And it's something that's going to be useful for sidechains and we're also using it in a bunch of our own projects, like to build Polkadot for example, and as well to build the Ethereum 2.0 client. So the way that Substrate works basically is you have LibP2P networking, although you could swap that out for something like DevP2P. My understanding is that Ethereum 2.0 is heavily leaning towards LibP2P right now. So that's what I'll talk about for the moment. LibP2P networking that lets you run a consensus process that does agreement over state transitions that are encoded in WebAssembly that we call the runtime. So the runtime is the actual work of the chain. And this is something that we've designed so that you can upgrade it on the fly for Ethereum 2.0. That's not really a feature that you need. So you don't need it to be WebAssembly. It could actually be native code in this case. But Substrate's general model is around WebAssembly state transitions where the state transition logic itself can be upgraded. And that's gonna be composed maybe of many different reusable components or modules like governance or slashing, staking, for Polkadot, we wrote one for parachains and for smart contracts and that sort of thing. For Ethereum 2.0, we've basically written a runtime from scratch because the beacon chain implementation is very, very unique. So what Substrate gives you is a abstract block format. It's agnostic as to what kind of backing database you use. So it could be like a key value store in base 16, a Merkle Patricia tree. It could be a binary Merkle tree. It could be something like just a key value store column that's not cryptographically committed to if you were writing something like a UTXO based chain. At its core, basically all you have to do to write a chain in Substrate is put together a implementation of function execute block. So that takes in a blob of data and it tells you was that a good block with the backing database. So that's basically what we've done. And it's got some extensible networking and other utilities as well. So one big part of what we're doing is pluggable consensus. So that was a feature of Parity Ethereum for a while to support proof of work as well, proof of authority and contracting system around that. But for Substrate, we've come up with a pretty nice set of abstractions that lets us do a lot of different complex things in Substrate. Like we've done Rotodendron, which is a instant finality probe call that's derived from PBFT. We've got Grampa and Orand, which are a hybrid consensus together. It's something like Casper FFG in the hybrid model. You could do Casper FFG as well with this. You could also do stuff like Ava that Amin was just talking about fairly easily in this model. So it's very, very extensible in that sense. And what you get is hot swappable consensus is one feature we've talked about where essentially you can move between consensus algorithms. For example, if you deploy your chain right now with some relatively simplistic longest chain rule, then you could upgrade it to something else and actually fork the chain onto another system. A hot swappable state transition function. I'm not gonna go through all of these, but one of the ones that I do really wanna stress is that it's got a light client from day one. I'm one of the few people who's written a light client for Ethereum. I can tell you that adding that onto a blockchain node after the fact is awful. It is a lot of work. So having that supported from day one, having networking protocols for it from day one is really, really important to make sure that you can actually have light client infrastructure in the end. Of course, there's things like the module library and if you wanna plug into something like Polkadot, that's supported as well. But to get more to the direct point and the question on the forefront of a lot of your minds with this conference is that Ethereum basically needs to scale. So the EVM can't process the proof of work consensus. The EVM can't process enough transactions for the uses that we're already seeing. That's just the case. Sidechains and bridges, which Bjorn talked about a bit earlier on the main stage, are a temporary solution to this problem, but they only mitigate it. At some point, even if you have a ton of sidechains and a ton of bridges, you're sort of fragmenting the ecosystem, which isn't ideal. And also you're just delaying the scaling issues because at some point, you won't be able to get all those bridge notifications onto the chain as well. So you really need a root-level chain that's scaling. So the solution proposed by the Ethereum research team is Serenity, Ethereum 2.0. So this is a name that's been around for a while. I mean, Serenity has been on the Ethereum roadmaps for years. The exact feature set that it's encompassing is just being nailed down now. So the spec is about 60% complete now. It doesn't cover everything like block authorship, but it does get the core of the state transition system, validator shuffling, changing validator dynasties and collecting attestations and that sort of thing. So the main piece of the sharding design is a beacon chain. And this is what we're building on substrate. So it's sort of a shard coordinator. It manages proof of stake validators. It adds blocks to the chain. It finalizes them. It gets cross links from shards, which are attested to by committees of validators. So all the validators will be split up into small committees, each committee being assigned to a specific shard for a period of time. The assignment is done by a randomness beacon, which is what's called a beacon chain. And basically these guys just attest to blocks that exist on shards. It operates as a proof of stake chain. The validators might take turns proposing blocks, which would be finalized by Casper FFG. So Casper FFG is one of the caspers that's floating around. It's basically just a finality gadget. So the term finality gadget is a bit nebulous, but it's essentially part of a hybrid consensus process where you have a probabilistic consensus algorithm adding blocks to the chain. And then you have finality gadget adding accountable safety onto that. So then if blocks that are finalized by the gadget are reverted, you get this process called accountable safety, which means you can identify who acted in reverting those blocks and punish them. So Casper FFG does that by voting on checkpoints every end blocks. And if you get two checkpoints in a row that gets super majority support, you've finalized a block. It influences the fork choice rule in sharding of the block production system as well. The cool thing about Casper FFG is that you get information on chain about which blocks have been finalized and the slashing conditions are really, really simple. So this is sort of a diagram from the sharding website of what the Casper FFG fork choice rule is doing. So you have some checkpoints which are getting closer and closer to being justified. Like you always follow the most recently justified checkpoint, but then you also look at which messages people are passing around on unjustified checkpoints and use that to influence your target block on the main chain. So shards are basically freestanding chains. They're secured by their own consensus algorithm. They're typically proof of stake and they're linked to the beacon chain via these cross links. These attested to statements that make their way onto the beacon chain. So to look a bit at this diagram that we got from Xiaowei and Ben Ejington, we can see that the architecture of sharding looks something like this. So the proof of work main chain is the anchor layer. This is actually like the Ethereum 1.0 chain. It's got this one directional lockup stuff where you can basically lock up your ether on the existing chain, move it over to the beacon chain and then get the beacon chain tokens for participating as a validator there. Other than that, it's not particularly relevant. The beacon chain is doing this randomness beacon stuff coordinating between validator sets and the shard chains are actually doing computations with a WebAssembly virtual machine. So now I'll get into the part of basically our implementation progress. Like where are we with that? So first I'll zoom back in time. Originally, there was a plan to have a hard fork in Ethereum to implement Casper FFG, to hard fork the Ethereum main chain that we're using now and make a Casper FFG hybrid consensus model with the proof of work that's going on there. So the first step that we took towards sharding shortly after the Taiwan summit was to do this implementation. So that's been closed because this plan has been abandoned, but we did this work, we spun up a test net and we showed that it was at least in a proof of concept stage. So now the plan has pivoted somewhat to incorporate this beacon chain architecture and we are doing ParityTech slash Shasper is the repository. So the developer who's been doing most of the work on this is a guy called Wei Tang from China. We've, the rest of the substrate team has been contributing bits and pieces through architecture and pluggable consensus and that sort of thing. Basically this is a repository that contains more or less everything that's specced out in the state transition aspect of the beacon chain. Block authorship, et cetera, still to do, but as those parts are further specced out those will be added. So most of it exists as a runtime, that piece of WebAssembly code that actually processes the logic of the chain. So what this is is processing new attestations, crystallizing them, handling new validator set changes, and that sort of thing. Substrates native block formats are a bit different than the ones that the beacon chain uses. So the beacon chain will have fields like the Randall reveal or a pin to the proof of work chain, the anchor layer that it's attached to. But substrates native block formats don't really have that stuff. So we use an adapter. So basically on disk we've got one set of block types which are the substrate block types where these extra values are encoded as extrinsics and on the networking layer we've transformed them into Shasper or Serenity blocks so that when you communicate with other nodes like those perhaps built by prismatic labs or lighthouse that they're all using the same block format but actually under the hood it's using a different block format. Ethereum 2.0 is very likely to use LibP2P for networking. So substrate has been using LibP2P from day one. At parity we even did, well to wind back a little bit LibP2P is a set of networking libraries first designed, built and described by protocol labs of IPFS and Filecoin. So this is intended to be a set of cross-platform and future-proof networking libraries. At parity we did an implementation of those in Rust and we've given that back to open source and we're in the process of moving that over to parity Ethereum as well so that parity Ethereum can use LibP2P as a backing network but we're also building substrate out with LibP2P as first class networking. So the next steps, what's next in the implementation side of things for Ethereum 2.0 for us? We are going to see this through. Parity is 100% committed to finishing the Ethereum 2.0 implementation. Thank you. So the next step will be basically better pluggable consensus. So we've now just in the past few days merged the commits into substrate that generalize the consensus framework. I think I've got a picture of this. So we've merged this pull request, you've got a few more coming. What's next is basically to implement Casper FFG on substrate. Start to do that block authorship work so that not just processing the blocks is done on our Shasper repo but actually authoring them as well. One other thing that we'll need is multi-tree support. So the validator set might grow pretty large. Right now it's just stored in this SSZ serialization, simple serialization format that's described in the sharding spec. But if the validator set is large enough and continues to grow dynamically then you would need to probably encode it in some kind of tree structure. So this is a feature where basically rather than having a single storage root in the substrate header you have one that references a few others. But it's also a valuable feature for example, building an Ethereum 1.0 client on substrate because this is roughly the same model that you would use for the accounts tree versus account storage trees in Ethereum 1.0. So one possible application of that could be to probably fairly easily put together a light client in substrate for Ethereum 1.0 or for Ethereum 2.0 shard chains. So I guess I'll conclude it there. Get substrate, give it a try, continue to follow what's going on with Parity's Ethereum 2.0 work. We're doing it a bit quietly in the background but slowly plugging away at it. As the specs solidify, we really intend to keep it up to date, keep our code up to date with what the specs are saying so that we're always on the ball with the sharding stuff. Thank you very much. We have time for a few questions. Hi, thank you very much. My question is, could you maybe elaborate a little bit about the crystallite states? Like in what form are they happening and if it's kind of the benchmarks that you have in proof of stake and if these benchmarks are something centralized or is done in a decentralized way? Yeah, so benchmarking the crystallized state is the question. So the crystallized state is just something from the sharding specification. So basically the state of the chain is spit into two parts. You have the active state and the crystallized state. So the active state contains sort of attestations that have not been processed yet and the crystallized state stores attestations that have been processed and checked and as well like what the head of all the shards are, that sort of thing, as well as the validator set. We haven't benchmarked it yet. It's a bit early stage for that. I mean, there's not really much to benchmark until you have something like block authorship going. But as soon as you have a chain up, you would start to see maybe how many transactions you can process, but right now is sort of the stage more for experimentation. Like there aren't even really, none of the beacon chain implementations are really at the stage where you could attach shards to them yet. So I don't think benchmarking sharding makes that much sense until you actually have shards. You said that the substrate works with the beacon chain, but does it work with the shard chains as well? Yeah, exactly. So you could use substrate to write the beacon chain, which is what we're doing now, and you could also use it to write the shard chains. Like those are most likely going to be proof of stake chains on their own that are running Iwasm as the state transition. From the perspective of the beacon chain, the shard chains are just blobs of data, so we sort of step aside from that problem for now, but you could definitely write an Ethereum 2.0 client for the shard chains in substrate. And in fact, that's what we will be doing as one of the next steps. So do you have any plans to upgrade some of the other products you support, like the Bitcoin, the Zcash one you just announced, the Ethereum 1.0 with substrate once it's up and running and ready to go? Yeah, so it's quite possible that you could do a Bitcoin implementation on substrate. I think with the existing products like Parity Ethereum, particularly with Parity Ethereum, there's a lot of extra code around it, like things like warp sync and the light client protocol and stuff like that, that's a bit different than the way substrate looks at things. So just with that amount of like three years of code, supporting that all over to substrate would be a bit too much work probably. You could definitely write an Ethereum client in substrate, but it's unlikely that the Parity Ethereum code base would migrate over to substrate in the near future. The Bitcoin client is a lot less complex simply because Bitcoin is a lot less complex. So I think it's very possible to do a, at the very least, a UTXO based chain on substrate where you execute Bitcoin script transactions. The question at that point is really just optimization. It's for sure possible to optimize a substrate node to get to the level of like a specialized Bitcoin node, but that would just at this point be duplicating efforts since we've already written one. I think substrate sort of at its niche is more focused on less migrating over existing blockchain products because then people have already done all those pieces of work that substrate is supposed to save you from duplicating and rather focus more towards like new blockchain products to get people off the ground a bit faster. Like we found it to be immensely useful for the charting stuff. Wei wrote up the state transition in like two weeks which he would think is, you know, if someone told you that beforehand you would think that that's impossible but managed to do it just because all of this stuff was completely taken away from developers. Are you using GRPC for the interface at EPI or? GRPC? Yeah. Is there a rust implementation of that? Because I think- I'm actually not familiar with GR, we are using JSON-RPC, like there's some JSON-RPC methods but I'm not familiar with GRPC. Okay, it's just a Google, I think just a Google library. Ah, I gotcha. The Go versions use it. Ah, okay, okay, so like as like a JSON-RPC server. Yeah, yeah. No, so we've written, like Parity has written our own JSON-RPC library and rust. Actually the guy who wrote most of it is sitting right behind you. So, talk to him. But yeah, so a lot of this stuff doesn't exist in Rust yet when we started to use Rust, like these libraries, like we had to write a lot of them ourselves. So, mostly our own code. Just another one off the top of my head. You mentioned alternative networking protocols. Is I2P in any sort of plans or anything like that? I2P, what's I2P? Sorry, say it again for the mic. Covery for Mineros was to have additional privacy guarantees over PDP. Ah, okay, yeah. I don't see why not. Basically none of the code that uses networking assumes anything about the networking protocol that's being used. So it's fairly generic, like usually, at least in the consensus algorithm stuff or the block propagation stuff, it's like you have a stream of incoming messages and a stream of outgoing messages on some topic or some peer-to-peer connection. So it doesn't really matter what you're using for that. LibPTP is one option and that's the one that we've coded up, but it shouldn't be too hard if you have an I2P library that you can link into Rust or do an implementation of that in Rust to slot that in as well. We're not probably going to do an implementation of that ourselves, but it's an open-source project and that kind of contribution is the stuff that we actually really want to see. So if there were to be a pull request open to implement I2P support and substrate, we would definitely review it and merge it. Yeah, we'll do it. All right, that about wraps it up for this room. I'm Corey Petty from the Bitcoin Podcast and Status and there's still some more stuff on the main stage. So thanks guys.