Ethereum 2.0 implementation updates 4Q2018/Prysmatic Labs: Implementing Ethereum 2.0 Today (Devcon4)

[Applause] [Music] hello everyone shall we and finder and foundation research thing so in research team we do research on the next generation in certain protocols and we also drew some proof of concept to verify our ideas so today this is a lightning Hawk and it will be more about the implementation part so first let's a quick recap that now may already know that from Tally's talk lab Casper shouting and pick random be concerned they are all together right now and we I prefer to call it serenity and know these circles our current world is server 1.0 and poof up work chain and the serenity is quite different but it's still extension of the external 1.0 and we will have those fantastic future like the four pop-ups take a good random number generator and the blockchain shot in for scalability problem and we will have a whole new brand brand new beacon chain and many xiaochun's in this ecosystem to realize it so if we abstract the different chains into okay make it into three levels so the if I'm a user of the faux fur auction I can make a deposit country on the pure double chain I mean I say I can say that hey I want to pass it at my 32 Easter and I want to be for one of the other editors and the validators is a long list of the visitors and those letters will be sued or Rendell a travel into many groups we call that this process the community shoveling so the mention is still here the pure documentary is still here and the blog is proposed but when we do the big hunch and black proposed the pecans and black will point to a reference make a reference that point to the proof-of-work chain and there will be a committee lack there will be a sight and be able to verify and attest earth become black so this committee they have to send their vote them super to say hey yes this blog is valid and then we call this process the attestation so instruction is similar the Charter will also be a committee that will be assigned to validate some specific shot block and the shopvac the vehicle we have to verify this blog and make their attestations so um the following process is similar just propose a block they refer sit and notice that the retention Park and shadow can be fast early and the proof of work chip so that's the simple high-level overview of this system and I won't know when focus on long talk about the kind side so I think high is the heart of Israel right now we never happy to have many deaths and things they are working on the system and we want to shout out their name here we have harmony lighthouse lost our numbers Pantheon's prison and parity substrate Chester and Trinity we have a active highs right now and now research team and always find their researchers develops we are walking on the open source you have repository and it's a community walk and everyone can make an issue and get some input down here and I also wanted to shout out to Danny Ryan and he he organized by weight to you community call and so are some ongoing discussion with Rico Thank You Danny and all these pies they are all open sourcing up I think yeah um with this um a strong community we can have a chance to read aside idea black transistor so that's some example that list are some question issues that we are working on for example that because there are many roads on the internet for the proof of stake system because everybody literally have to broadcast their individual votes to say hey this block is valid or and if we want to have them like thousands shots in this system the trapeze is not good for network traffic so how to make how to build an efficient signature application protocol or in the cryptography thinking that's a problem and also we have a chance to change the IOP data serialization into something more efficient or simpler and for the name walk scilab there's a problem is that because for I'm the I say that the validator will be rendered I traveled to a stylist I will be aside to very day sounds basic shot English basic Thai slots which means that when the condition by later they will they will be asked to hey I have to wear it it welded shut lock like in ten minutes for example then they it's easy in protocol but if we say that in the network layer they have to move their peers they work in two different network so it will cause a lot carnation tie to the peer discovery and thinking so we need to redesign a new technology and new pH management system to deal with it so our current idea is that we can use the liquid to pick a zips up china's to gossip channels to like a sigh of shot for sounds basic channels in that way we can reduce the connection overhead and I like to spend some time for the presentation so because we have a big concern reference that and in a flag effect the current spec but now we also want to hold it in to the production environment because I want to make a test now in Python yay and Trinity is the seventh one point okay we've built with Python led by Piper Miriam and his and his team the snake tremors and it's open source now you can check their website and link to the repository and if we see the architectural layer by layer there will be an echo layer and state extrusion they're like beacon chance state machines different from evn it's quite simple and for a shot we will have like it wasn't in the system and different chains and different Kairos because we now we are using the validator or not minor and the last I want to encourage you to check out those resource 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 and next Ron found prismatic left he will give you a talk about their golden exultation [Music] all right well so thank you shall we for the amazing presentation I think it's been so incredible how ever since kind of the etherium charting 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 aetherium 2.0 and I just want to give a little bit of a background 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 shardene Kaspar and a general upgrade to the etherium network there is no token there is no there's 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 so why exactly did we start and how exactly does this happen so we fast-forward kind of we'll go back to the late 2017 where italic had a basic charting FAQ explaining the possibility of having a parallelizable world computer this was the start of kind of a new initiative there were it was very very high level in the sense that it didn't really go into much detail of how this would work you know like how feasible would this be from an implementation perspective and essentially a bunch of a bunch of blockchain developers like me and my team were you know scouring gaiter going through github issues trying to get a grasp if like 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 Def Con marks the first time all of us actually meet in person so it's been an amazing amazing time yeah so what does it mean to work on earth 2.0 working on s 2.

0 means at a very high level operating under constraints and we have to understand that we have a currently functioning you know maintained client that runs a proof-of-work chain right now where there are real people with invested at applications bid alerts as we've seen and a lot of a lot of initiatives to kind of keep this going and make it into you know 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 a theorem 2.0 shall we explain it's going to be a side chain of sorts is going to be basically a parallel chain that is then pegged to the proof work chain as a way to create a full Kaspar FFG enabled proof stake chain and what this means is that we must have to be very very careful with our crypto economic design how we are more 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 20 we initially started doing a biweekly 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 many 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 aetherium 2.0 to be able to come in and just build out parts of our implementation we've been leveraging get coined extensively so thank you very amazing tool it's a it's an incredible tool every time I 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 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 change as per spec and yeah 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 you know we've been like aetherium as kind of italic puts it was kind of a scrappy attempt to build a work on the world computer and f 2.0 will actually be the world computer so under this set of constraints we have to consider you know how will the underlying tech stack improve this efficiency and reduce as much overhead as possible so we can maximize the throughput that we get from the system as well as the usability so one of things that we've been using is there's a lot of kind of a lot of discussions around all the ES 2.0 teams using Lib PDP which is a very popular networking library maintained by protocol labs aside from that we've been using Google's popular G RPC framework for a 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 a scalability of a blockchain is truly having a base layer that does this job good enough so the 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 you know 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 and how it does things aside from that it's very batteries included so it prefers simplicity over magic we have a lot of other languages that just seem you know like they're written 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 we believe in the power of Geth gas has been is an incredible project it's been battle tested it's gone through a lot of upgrades and even then like it maintains you know the robustness and flexibility of a language as greatest 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 be sure a great developer experience as well as user facing piece of software so if you guys check out our repo you know 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 were very much we aim to be very much on the bleeding edge the thing about the interim 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 the 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 we've been a little bit more you know we've been taking a little more risks and implementing something further ahead so we've been careful with you know 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 interact the people interacting in aetherium 2.0 so in s 2.0 we have an entity called a beacon node and we also have validator clients so why establish the separation right so a beacon node essentially serves as like the source of randomness for a theorem 2.0 it processes kind of information that is aggregated across shards it processes the votes from validators on shards and it also determines casper FFG rewards and penalties to people involved so if you guys imagine running a current guest node or a parody 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 you know 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 gonna be your main interface as a user into you know participating in securing the etherium network for the future right and specifically everyone needs 32 eath to participate so this is a number you can't go higher or lower at the moment and what would 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 short assignments state transitions and everything that happens in that 2.

0 aside from that you have your little validator client which is your user user facing piece of software so one thing we can imagine is that a beacon node can be something hosted by a provider like in Fuhrer you can run your own beacon node for example staking pool providers can run a bunch of beacon nodes so ideally you know these these machines are not going to be as resource intensive as the ones that we have today however like as a user we want to make it also say you can run your own be conduct 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 could be them through it through you know 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 you're a company you know we as an example when I give a shout out to rocket pool these guys are awesome they're working kind of a staking architecture for people to get involved even if you don't have the 30 to eath 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 you want to stake 32 eath you want to participate in the network so one of the 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 what 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 we also 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 know that theorem 2.0 API right and like I said these are very lightweight can be spun all types of devices so I can even imagine having your phone as as the entity that you know stores private keys and can help with signing the transactions required so what does beacon change 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 includes a lot of a lot of issues 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 right protocol buffers provide this by directionality of essentially you know having a good standard for a public API allowing notes 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 into the situation where like on the sender and I'm really happy with what I'm sending the recipe has no idea right as of today a lot of the current aetherium clients they don't even implement all the web 3 endpoint methods that the other clients do that's something we're going to actively try to avoid and at 2.0 so just to give you guys an example of gee our PC connection metrics so G RPC is kind of like a framework put together by Google for this remote procedure call service optimization and currently you know when you use JSON RPC you get around you know almost a 10 order which in reality is about like a 6 you know 6 times order of throughput compared to JSON RPC when you see a proto bus why is this in particular you know why is this important well we want to make sure like I said want to reduce the mutt as much friction as possible which we knows using a 2.0 to make it so that you don't need to worry about this as a user you don't need to worry about like the bottlenecks that you'll obtain from this aside from that here are some utilities that will provide our client for you guys to use and that are gonna be basically like you know public packages that can be imported across other projects so if you guys went to Justin's Drake I just in Drake's randomness talk for s 2.

0 we're going to be leveraging the power of a six basic rigs to create a verifiable delay function source of randomness for a tearoom 2.0 so it's really cool because you can actually have a public API where you can query the randomness like unbiased able strong randomness I'm a theorem 2.0 nodes that you can use in your applications we're gonna have a very robust key value store using both DB which is a write optimized database specifically you know very well very well created for block chains as well as the signature aggregation library using VLS so the cool thing is that in previous iterations of kind of the etherium 2.0 spec there are 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 I'll check so in this case we get the wonderful BLS signature aggregation tool aside from that the beacon note serves as a source of shards shuffling and cross shard communication so on the con the beacon chain spec right now that shadow I pointed out in the official etherium repo there is essentially not enough mention about cross communication that is a very active area of research but the beacon nodes are finality and the way committees are handled gives us a strong way to kind of 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 we have a very simple format in the ammo where you can specify like hey you know I want I want it I want to specify a test for a fork choice in the theorem 2.0 I want to specify what happen with a signature aggregation I want to know exactly you know like 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 testings 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 ERP see responses getting shuffled into shards and performing the responsibility of basically a testing and proposing to shard blocks and you know it was just really interesting to see how this implementation efforts give us a really good idea of kind of where the spec is a lot of a specification right now is mostly like oh we should do block processing we should be for chips but nobody really tells you like okay where should this live who should be doing this how I should validate or clients interact so by being a very bleeding-edge focus 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 that's I think been really a really amazing experience working with the etherium research team on this so what are the next steps for us 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 is most of the core core kind of items will remain the same what's really lacking is kind of logistics around exactly validator client interactions how that's going to work and such working on benchmarks and metering extensively for applications so we want to make sure we understand if our signature aggregation is done properly you know how many validated clients can we realistically have attaches G RPC processes as well as work on sharp p2p which is a very big kind of umbrella term all right so our next major milestone is something that I'm really happy to kind of announce so we will be doing a test net cluster of beacon nodes and validators and that's something that you know we 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 faucet eath can basically deposit your eath to become validators get on board at as validators into the beacon chain kind of 2.

0 and can start performing your responsibilities and that it's a very exciting kind of prospect and we really hope that you know people will leverage prism to the best of their ability and understand all the tools that we have to offer and of course you know this is a constant you know work in progress our constantly iterating on this and we'll have a lot more for you guys in the coming months so staying tuned stay tuned for this yeah so some learning resources there's a lot of information out there if you guys like a path 2.0 now called serenity so there's an F 2.0 devs handbook if you guys don't 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 that is out there I mean earth 2.0 went from being something that might happen maybe it could be there maybe it's feasible to being like it's gonna happen and we're all gonna do it so thank you everyone let's do some questions so have a bit of time for questions yeah yeah hi my name is Josh I got a quick question yes it at 2.0 and charting and beacon chains are gonna run parallel with proof-of-work Shane is that true yeah so essentially 2.

0 is going to be a new chain a new system for proof of State Caspar f of G where you have the proof work chain running in parallel with it the reason we do this is so that we make it easier for people to deposit eath as a one-way deposit into the 2.0 chain so you want to leverage the fact that like people have current eath they want to leverage that to become valid leaders so that's kind of why we're kind of synchronizing the two at the moment okay do you foresee the proof of work chain being deprecated right now yes I foresee that so the way we're gonna do that is probably going to migrate the entire state of the current Provo 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 you want proof of work to be deprecated over time yeah great thank you yep yeah hey two questions first a Ewing does does this clan prism client intend to deprecate get always something it's a good question I think the gas team has been really busy right now with all the hard fork situation and testing and making sure everything goes up to par I'm not quite sure exactly what their plans are moving forward but yeah I mean they have so much experience and go that you know love for them to get involved as well I'll try to be more specific we'll get B off of work like a theorem one or we'll do they intend to implement 2.0 surrender I am Not sure okay sorry okay and the second question sorry is are you funded by consensus that you intervene yeah we received funding from Aragon nest we received a major grant from with UN Foundation a $500,000 in the latest wave so I was super nice thank you if we received ECF and one Shannon blockchain labs a few other organizations but it's all been grants we haven't taken any equity you know we're not we're not kind of full time you're walking full time the team yeah on this okay great awesome thank you yeah so we have one more question yeah hey can you talk more about running a validated client on their smartphone do you know your particular wor sure ideally like if it's gonna run on a smartphone a--probably just be like the private key kind of signing functionality of the validator client we still haven't designed exactly like what it would look like on mobile because there are still things to be done on the spec but ideally like yes like we want to make it as lightweight as possible if you're running on your phone and obviously phones have like availability assumptions like you know 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 right so thank you everyone appreciate it [Applause] you