 I'm Xiaowei, I'm from a certain foundation research team. So in research team, we do research on the next generation, Eastern protocols. And then we also do some proof of concept to verify our ideas. So today is a lightning talk and this will be more about the implementation part. So first, let's a quick recap that now we already know that from Tali's talk that Casper, Sharding, and Brandon Beacon-Chen they are all together right now. And I prefer to call it serenity. And these circles, our current world is Ethereum 1.0 and the proof of work trend. And the serenity is quite different, but it's still an extension of the Ethereum 1.0. And we will have those fantastic future like the full proof of stake, a good random number generator, and the blockchain Sharding for scalability problem. And we will have a whole new brand, a brand new Beacon-Chen and many Shardchains in this ecosystem to realize it. So if we abstract the different chains into, we can make it into three levels. So if I am a user of the proof of work trend, I can make a deposit on the contract on the POW chain. And I can say that, hey, I want to deposit my 32 ether and I want to be one of the validators. And the validators is a long list of the validators and those validators will be should or randomly shoveled into many groups. So we call that this process the community shoveling. So the main chain is still there. The POW main chain is still here. And the block is proposed. But when we do the Beacon-Chen block proposed, the Beacon-Chen block will make a reference that points to the proof of work chain. And there will be a committee that there will be a site and be able to verify and attest a Beacon block. So this committee, they have to send their votes to say, hey, yes, this block is valid. And then we call this process the attestation. So in the short chain, it is similar. The short chain will also be a committee that will be assigned to validate a subspecific short block. And the short block, the validator will have to verify this block and make their attestation. So the following process is similar. Just propose a block and then reference it. And notice that the Beacon-Chen block and the short block can be faster than the proof of work chain. So that's the simple, high-level overview of this system. And now I want to talk about the client side. So I think client is the heart of Ethereum right now. We are happy to have many devs and teams that are working on this system. And I want to show the other name here. We have Harmony, Lighthouse, Lowstar, Nimbus, Pantheon, Prison, and Parity Substract Tractor, and Trinity. We have eight active clients right now. And now our research team and all these clients, their researchers, developers. We are working on the open source GitHub repository. And it's a community work. And everyone can make an issue and give some input down here. And I also want to shout out to Danny Ryan and he organized the weekly community call. And so now some ongoing discussion on the weekly call. Thank you, Danny. And all these clients, they are open source now. I think they are. With this strong community, we can have a chance to decide the ideal blockchain system. For example, there are some question issues that we are working on. For example, because there are many votes on the internet for the profile state system, because everybody literally have to broadcast their individual votes to say, hey, this block is valid. And if we want to have 1,000 shots in the system, the traffic is not good for network traffic. So how to build an efficient signature aggregation protocol or in the cryptography thinking, that's a problem. And also we have a chance to change the ILP data serialization into something more efficient or simpler. And for the network side, there's a problem is that because I say that the data will be randomly shoveled to a site, or it will be a site to validate some basic shots in a basic tie slot, which means that when the validator, they will be asked to, hey, I have to validate the big shot block in 10 minutes, for example. Then it's easy in protocol. But if we say that in the network layer, they have to move their peers' network into different network. So it will cost a lot of connection time to do the peer discovery and thinking. So we need to redesign a new topology and a new peer management system to deal with it. So our current idea is that we can use the Lik-P2P GASIP channels to assign a shot for some specific channels. In that way, we can reduce the connection overhead. And I'd like to spend some time for the Python implementation. So because we have a big chain reference on GitHub that reflect the current space. But now we also want to put it into the production environment because we want to make a test in Python. Yay. And Trinity is the 71.0 client built with Python led by PyPymerium and his team, the Snake Chambers. And it's open source now. You can check their website and link to the repository. And if we see the architecture layer by layer, there will be Neco Layer and the state extrusion layer, like Big chain state machine. It's different from EVN. It's quite simple. And for the shot, we will have E-Wazen in the system and different chains and different client roles because we know we are using the V-Data, not the miner. And the last, I want to encourage you to check out those results if you want to participate more. And I think we are doing something really cool here. And thank you for community contribution. And thank you for your listening, too. And next, we're all found Prismatic Lab. He will give you a talk about their golden implementation. Thank you. Well, so thank you, Xiaowei, for the amazing presentation. I think it's been so incredible how ever since kind of the Ethereum sharding efforts first spun up, there was essentially nobody working on this. There were a few reference implementation, a few reference specs out there, a few blog posts. But in the span of less than a year, there have been more than eight teams just aggregating, coming together, and putting together something that will work in production as the next iteration of our platform. So today, I will be talking about implementing Prism, which is our go client for Ethereum 2.0. And I just want to give a little bit of a background on kind of who we are. So my name is Raul. And I am the co-founder of Prismatic Labs. So we are an independent team of developers that aggregated to build an implementation for sharding, CASPER, and a general upgrade to the Ethereum network. There is no token. There is no presale. There's nothing of that sort. We just want to create a public good. We understand how powerful this would be for everyone to use. And we want to create something that is production grade, using the best software engineering practices to build a client like this. So why exactly did we start? And how exactly does this happen? So we fast forward kind of go back to the late 2017, where Vitalik had a basic sharding FAQ, explaining the possibility of having a parallelizable world computer. This was the start of kind of a new initiative. It was very, very high level in the sense that it didn't really go into much detail of how this would work, like how feasible would this be from an implementation perspective. And essentially, a bunch of blockchain developers like me and my team were scouring, going through GitHub issues, trying to get a grasp if this is viable or not. So we started asking ourselves, who is working on this? Who wants to work on this? And just join us on an implementation effort. So we put together a call on Reddit and our whole team assembled organically through the internet. And actually, this DevCon marks the first time all of us actually meet in person. So it's been an amazing time. So what does it mean to work on F2.0? Working on F2.0 means at a very high level, operating under constraints. And we have to understand that we have a currently functioning, you know, main chain client that runs the proof of work chain right now, where there are real people with invested applications, butlers, as we've seen, and a lot of initiatives to kind of keep this going and make it as robust as possible so we can get to our goal of achieving a world computer. The problem is that when upgrading the system, this isn't exactly going to be a hard fork. So what this means is that at F2.0, shall we explain it's going to be a side chain of sorts. It's going to be basically a parallel chain that is then pegged to the proof of work chain as a way to create a full CASPER FFG-enabled proof of stake chain. And what this means is that we must have to be very, very careful with our crypto economic design, how we onboard people into the system, and how we can get the same level of scale of usability and a much, much larger level of throughput. So what is the road so far? Ever since we started in around January of 2018, we initially started doing a bi-weekly development update. We wanted to be as transparent as possible about these efforts. We understand that given the spec is so kind of young, we need as much discussion around some of these problems. We need people criticizing, we need people coming in and being like, you guys should not do it this way. You should try this way instead. Aside from that, we've been big fans of having extensive onboarding documentation. So we've been able to onboard a lot of contributors that have not been as familiar with Ethereum 2.0 to be able to come in and just build out parts of our implementation. We've been leveraging Gitcoin extensively. So thank you Vivek for this amazing tool. It's an incredible tool. Every time we make a bounty, we get tons of people just coming in and flocking to it. And it's just been a great experience, just onboarding people into the community. I think that's the way to go. Aside from that, we've also been doing bi-weekly development updates. So we've been frequently posting about everything we do. And on October 3rd, we released our very first POC of the current Beacon Chain Shasper spec. And yeah. Cool. So what does it mean to create an entirely new system? It means that we have the opportunity to make better and more robust design choices. So in that sense, Ethereum, as Vitalik puts it, was kind of a scrappy attempt to build a world computer. And F2.0 will actually be the world computer. So under this set of constraints, we have to consider how will the underlying tech stack improve this efficiency and reduce as much overhead as possible so that we can maximize the throughput that we get from the system as well as usability. So one of the things that we've been using is there's a lot of discussions around all the F2.0 teams using libp2p, which is a very popular networking library maintained by Protocol Labs. Aside from that, we've been using Google's popular GRPC framework for communication between processes. So we want the friction to be as little as possible. We want nodes to be able to just work. You can spin up a node, you can communicate, you can run a validator client. You don't need to think about it. And in our eyes, what we see as scalability of a blockchain is truly having a base layer that does its job good enough so that applications don't even need to consider it. Aside from that, we picked Go as our tool. Go is an incredible language for blockchains in particular, where you have so many concurrent processes. It's very concise. And what's really great about Go is that when we're collaborating as a team, it feels like almost every file has been written by the same person or the same group of people because it's so strict in how it does things. Aside from that, it's very batteries included. It prefers simplicity over magic. We have a lot of other languages that just seem like they're coming from some arcane alien knowledge. And there's a lot of crazy kind of constructs in there. However with Go, we have the simplicity that everyone that wants to contribute to a blockchain project, they basically can just come in, they'll understand what's going on in the code. All they need to understand is to read more about the context, read our documentation, and we'll always gladly onboard them. So we believe in the power of Geth. Geth is an incredible project that's been battle tested. It's gone through a lot of upgrades. And even then, it maintains the robustness and flexibility of a language as great as Go. So exactly what does Prism encompass as a client for you guys? We are careful to design this knowing that a lot of people in this room will probably be using this client as a theorem 2.0 launches. And we want to ensure a great developer experience as well as a great user-facing piece of software. So if you guys check out our repo, fully open, always welcome. So it's prismatic labs slash prism. We've put a lot of work together on implementing the beacon chain, making sure we have up-to-date documentation on how this works, have parity with the spec. One of the biggest things is that we're very much, we aim to be very much on the bleeding edge. The thing about the Ethereum 2.0 spec is that it's very much still in the works. So there are a lot of core functionality and logistics about how validators will work that are still kind of being designed. A lot of R&D efforts specifically around the cryptography behind this. And we've been taking a little bit more risks in implementing something further ahead. So we've been careful with kind of how we design the system, what architecture we pick, how users will interact with this, and what exactly are the roles of the people interacting in Ethereum 2.0. So at 2.0, we have an entity called a beacon node, and we also have validated clients. So why establish a separation? So a beacon node essentially serves as like the source of randomness for Ethereum 2.0. It processes kind of information that is aggregated across shards. It processes the votes from validators on shards. And it also determines the CASPER FFG rewards and penalties to people involved. So if you guys imagine running a current geth node or parity node, in the future, that's going to be what we call running a beacon node. Aside from that, we have an abstraction of a validator client, which is essentially like a wrapper that can help you kind of interact with your private keys. However, you can store your private keys elsewhere, such as in a hardware wallet or your other preferred methods. This validator client will actually be shuffled by the beacon node into shards. And it's going to be your main interface as a user into participating and securing the Ethereum network for the future. And specifically, everyone needs 32E to participate. So this is a number you can't go higher or lower at the moment. And what will this look like kind of from a software architecture perspective? So we have a beacon node that serves as a single source of truth for kind of shard assignments, state transitions, and everything that happens in that 2.0. Aside from that, you have your little validator client, which is your user-facing piece of software. So one thing we can imagine is that a beacon node can be something hosted by a provider like Infura. You can run your own beacon node, for example. Staking pool providers can run a bunch of beacon nodes. So ideally, these machines are not going to be as resource-intensive as the ones that we have today. However, as a user, we want to make it also so that you can run your own beacon node. Validator clients can be run anywhere. And these are very lightweight pieces of software. Ideally, we might even abstract it even more, such that validators, all you need to do is really manage private keys. And that can be done through your hardware wallet and have a little interface for you to do that. Aside from that in the system, we also contain the idea of shards. And one question we get a lot is, I want to run multiple validators. How can I do that? Say you're a company. As an example, I want to give a shout out to Rocket Pool. These guys are awesome. They're working on kind of a staking architecture for people to get involved, even if you don't have the 32Eath. So what would that look like? One of the things that we don't want to happen is this, right? So we don't want you to have to spin up a single client every single time you want to stake 32Eath. You want to participate in the network. So one of the things we've gotten around is actually creating a multi-tenant validator client architecture. So in the sense that like validator assignments are live streamed for a subset of public keys. So for example, I'm running a validator client on my laptop or my computer at home. I manage 10 public keys on there. I can send an API request to my beacon node for the assignments for those 10 public keys, and I get a stream telling me exactly when I need to do my job. I don't need to do anything. I just have one machine. I trust it, and things get done. So essentially, this also allows for validator as a service sort of opportunities. At Prism, we're going to be shipping our own in-house validator client that you guys can use, but it should be a very simple piece of software that any other person can create as well, as long as it conforms to the beacon node at the theorem 2.0 API. And like I said, these are very lightweight, can be spawned on all types of devices. So I can even imagine having your phone as the entity that stores private keys and can help with signing the transactions required. So what does a beacon chain kind of public API look like? And one of the things that we want to do is we want to improve upon the current system, which currently uses JSON RPC. I'm sure a lot of you are familiar with that here. It includes a lot of issues with standardization, and it's not something that I think we believe is robust enough for a theorem 2.0. So instead, we're going with protocol buffers. And protocol buffers give you a lot of benefits. So as an example, say we have two nodes communicating with each other. Protocol buffers provide this bidirectionality of essentially having a good standard for a public API, allowing nodes to know exactly what to expect and allow them to interact with each other in a way that we know will work, even cross clients. Whereas with JSON, for example, every client needs to write kind of their own way of doing things. You're in this situation where on the sender end, I'm really happy with what I'm sending, the recipe has no idea. As of today, a lot of the current Ethereum clients, they don't even implement all the Web3 endpoint methods that the other clients do. That's something that we're going to actively try to avoid in that 2.0. So just to give you guys an example of GRPC connection metrics. So GRPC is kind of like a framework put together by Google for this remote procedure call service optimization. And currently, when you use JSON-RPC, you get around almost a 10 order, which in reality is about a six times order of throughput compared to JSON-RPC when you're using a protobus. In particular, why is this important? Well, we want to make sure, like I said, we want to reduce as much friction as possible between nodes using F2.0 to make it so that you don't need to worry about this as a user. You don't need to worry about the bottlenecks that you'll obtain from this. Aside from that, here are some utilities that we'll provide in our client for you guys to use and that are going to be basically public packages that can be imported across other projects. So if you guys want to adjust in Drake's randomness talk for F2.0, we're going to be leveraging the power of ASIC rigs to create a verifiable delay function, source of randomness for Ethereum 2.0. So it's really cool because you can actually have a public API where you can query the randomness, like unbiassable, strong randomness from Ethereum 2.0 nodes that you can use in your applications. We're going to have a very robust key value store using BoltDB, which is a right optimized database, specifically very well created for blockchains, as well as the signature aggregation library using BLS. So the cool thing is that in previous iterations of the Ethereum 2.0 spec, there were a lot of questions around how can we do efficient signature aggregation. We have a lot of validators voting on blocks. How can we get them basically doing their job in a way that we don't have to worry about the bottleneck of verification on chain. So in this case, we get the wonderful BLS signature aggregation tool. Aside from that, the Beacon node serves as a source of charge shuffling and cross-chart communication. So on the Beacon chain spec right now that Xiaowei pointed out in the official Ethereum repo, there is essentially not enough mention about cross-chart communication, but it's a very active area of research. But the Beacon nodes finality and the way committees are handled gives us a strong way to begin on an approach towards that. Another thing is we're going to be building a common client testing framework. So we want to make it so that we have a very simple format in YAML where we can specify, like, hey, I want to specify a test for a fork choice in Ethereum 2.0. I want to specify what happened with signature aggregation. I want to know exactly what this would look like, what the result would be, and have a comprehensive test suite so that even if people are not familiar with their client and are coming from other client teams, they can come in and test things robustly end to end. So we did a POC kind of early October in which we essentially had our Beacon node on the left. And on the right-hand side, you guys can see validator clients that are connected, receiving streams of GRPC responses, getting shuffled into shards, and performing the responsibility of basically testing and proposing to shard blocks. And it was just really interesting to see how disimplementation efforts give us a really good idea of where the spec is. A lot of the specification right now is mostly, oh, we should do block processing. We should do fork choice. But nobody really tells you, OK, where should this live? Who should be doing this? How should validator clients interact? So by being a very bleeding edge focused implementation team, we get to answer a lot of these questions ourselves and kind of come up with designs that would make sense in light of the spec and oftentimes come up and be like, hey, there might be a bug in the spec. And that's, I think, been a really amazing experience working with the Ethereum research team on this. So what are the next steps for us at Prismatic Labs? There's still a lot of work to do on the Beacon Chain spec. Part of it is due to research. But one of the things I like to say is that the research at this point is most of the core items will remain the same. What's really lacking is logistics around exactly validator client interactions. That's going to work in such working on benchmarks and metering extensively for applications. So we want to make sure we understand if our signature aggregation is done properly, how many validator clients can we realistically have attached to GRPC processes as well as work which is a very big umbrella term. So our next major milestone is something that I'm really happy to announce. So we will be doing a test net cluster of Beacon nodes and validators. And that's something that we aim to deal with the other client implementation teams as well. But we want to make it so we have a very simple system where you guys can obtain FaucetEth, can basically deposit your ETH to become validators, get onboarded as validators into the Beacon Chain, kind of 2.0, and can start performing your responsibility. And it's a very exciting kind of prospect. And we really hope that people will leverage Prism to the best of their ability and understand all the tools that we have to offer. And of course, this is a constant work in progress. We're constantly iterating on this. And we'll have a lot more for you guys in the coming months. So stay tuned for this. Yeah, so some learning resources. There's a lot of information out there if you guys look up at 2.0. Now call Serenity. So there's an F2.0 Devs handbook if you guys want to learn more about this. We have the spec. We have a repo. We have our bi-weekly kind of implementer calls that are kind of in parallel with the core Devs calls. And overall, all of that is out there. I mean, F2.0 went from being something that might happen. Maybe it could be there. Maybe it's feasible to being like it's going to happen. And we're all going to do it. So thank you, everyone. Is there some questions? Cool. So I have a bit of time for questions. Hi, my name is Josh. I just had a quick question. You said at 2.0 and charting and beacon chains are going to run parallel with proof of work chain. Is that true? Yeah, so essentially 2.0 is going to be a new chain, a new system for proof of state, Casper FFG, where you have the proof of work chain running in parallel with it. The reason we do this is so that we make it easier for people to deposit ETH as a one-way deposit into the 2.0 chain. So we want to leverage the fact that people have current ETH. They want to leverage that to become validators. So that's why we're kind of synchronizing the two at the moment. OK. Do you foresee the proof of work chain being deprecated right now? Yes, I foresee that. So the way we're going to do that is probably going to migrate the entire state of the current proof of work chain into a contract on a shard in the future. In the meantime, that still hasn't really been designed. But yeah, we would still keep the same state. But in the future, ideally, we want proof of work to be deprecated over time. Great. Thank you. Yeah. Yeah. Hey. Two questions. First, does this Prism client intend to deprecate GATH? Or is something that's a good question? I think the GATH team has been really busy right now with all the hard fork situation and testing and making sure everything goes up to part. I'm not quite sure exactly what their plans are moving forward. But yeah, I mean, they have so much experience and go that we'd love for them to get involved as well. I'll try to be more specific. Will GATH be proof of work, like Ethereum 1? Or will do they intend to implement 2.0, serenity? I am not sure, actually. Sorry. OK. And the second question, sorry, is are you funded by consensus that you're not funded or anything? Yes. Are you entirely voluntary? Yeah, we received funding from Ergon Nest. We received a major grant from the Ethereum Foundation of $500,000 in the latest wave. So it was super nice. Thank you, EF. We received ECF and One Chain Blockchain Labs, a few other organizations. But it's all been grants. We haven't taken any equity. We're not kind of that. You're working full-time, the team on this? OK. Great. Awesome. Thank you. Yeah. So we have one more question. Yeah. Hi. Can you talk more about running a validated client on a smartphone? Do you know any particular word? Sure. Ideally, if it's going to run on a smartphone, it'll probably just be the private key signing functionality of the validated client. We still haven't designed exactly what it would look like on mobile, because there are still things to be done on the spec. But ideally, yes, we want to make it as lightweight as possible if you're running on your phone. And obviously, phones have availability assumptions. You might not always have connection. We want to make sure that you're prepared for that and have some way to protect you against those things. So there are some compromises for running on the phone. But there hasn't been designed yet. So I can't give a strong answer to that. Thank you. All right. So thank you, everyone. Appreciate it.