# 'Prysm x Merge' - Terence Tsao

- Speakers: Terence Tsao
- Channel: [ETHGlobal](https://streameth.org/ethglobal)
- Date: 2021-10-09
- Duration: 30:28
- Topics: prysm, terence tsao, ethereum, ethglobal, merge, eth2, prysmatic labs
- Watch: https://streameth.org/watch/yt-paz8sMnytDg
- YouTube: https://www.youtube.com/watch?v=paz8sMnytDg

## Description

Join Terence from the Prysm team for a run through of how everyone will be able to participate in blockchain consensus in ETH2.

----------------------------------------------------

Follow us: https://twitter.com/ETHGlobal
https://ethglobal.co
Email: hello@ethglobal.co

## Transcript

already looks like we are almost good to go so um yeah next up we have terence from prismatic labs who will talk about how prison plans to interrupt with other e1 clients and i think he's here already hi yeah can you hear me hey yes i can thank you for having me it's great to be here so um let me share my screen one second yeah i'm super excited to be here so uh can you see my screen all right are you able to i can yep looks good and then you can hear me as well right cool can i go yep the stage is yours okay thank you so much so hi everyone my name is terence i'm from prismatic labs i'm most known for my work on prison which prism is a e3 client so in this talk i will go through more on the client implementation side on what's our perspective on rainy sun the hackathon which portland does doing a great job hosting and the upcoming emerge so let's get started so um agenda so um i will touch base on consensus on execution most importantly the separation of concerns here but i was given that i i always came through them rather quickly since the early presenters already did a really good job on covering them so if you haven't checked out the all the previous presentations i highly recommend you to do so it's a recording on youtube and then for the second half i will cover more client implementation details and i will dive deeper into the code changes some of the design decisions that we made and my goal is to hope to attract more client implementers into this ecosystem whether it's for prismatic labs similar prime lighthouse tycoon and the ether1 stuff or the e2 stuff there's so much to do and the more people can get the better so um i read this article by bernard b a couple days ago and there's this court that caught my eye it says that ethereum today is what e2 developers are calling if the one the current proof reward chain that we all know and love ethereum tomorrow isn't it one or e2 it just is 3m right and i highly recommend you to check this piece out it was a great read so um from this i would try to refrain myself from saying e1 or e2 instead i would be using the proper terminologies which is beacon chain becomes the consensus layer it is responsible for the agreement of data right and beacon chain will be represented by uh well what today is called the beacon node the beacon of client their prism their lighthouse their nimbus their uh tackle and i'm sure most of you guys have had experience with them whether it's for staking whether it's for playing it wrong and yeah and then there's this current ethereum channel where it's the execution layer and then this is responsible for interpretation it's responsible for um transaction of the data and this is represented by the pre-emerged proper work client and that's like yeah and that in mind and so much more so let's go to some graphic representations right so now we have essentially two chains and two chances they're going in on the same time and both of them have consensus right then you have your current ethereum chain which operates under proof-of-work consensus it has its uh application network where they're gossiping um application block and then you have your stage fee you managers receive account balances and stuff like that then on the other end of the universe you have european chin which is operate under proof of state consensus and then this and this prefer and this vision change govern under validators now not not the miners and and if the chain consists of what we call management data is it's it's governed by validators right you track validated balances you track the latest smashing and so that and the network is gossip via consensus objects how much the validator balances has what uh what the validators are voting whether the validities are performing priority or nicely and then you have your b condition state which tracks the balance the randomness finality and all the fun stuff right so there is a subtle thing here that is the deposit contract and because of the vision chain itself cannot cannot come to cannot come to life he needs some sort of bootstrap mechanism right so it's bootstrap the stickers on the beacon chains bootstrap using this deposit contract into the carrying ethereum chain to deposit 32 each so there is this various tiny subtooling here so here's more graphical representations and the you can kind of think of like beacon chin the consensus there as a wrapper on top of the execution layer which is the so-called current ethereum chain and so under this merge right the it's a the execution layer no longer needs proof of work because it can pick you back on the proof-of-stake consensus that bitcoin chain operating right so it no longer needs the agreement on data it needs the agreement on transaction ordering right so so so its focus becomes execution only and that's like evm that's state sex management that's transition ordering that's the gossiping of the transaction data right so note that you don't need to transaction a typical block anymore you just need transact transaction data and you do realize in this model i also added the data layer as well and the for the second time i won't cover so much into like what the data layer consists but the data layer is more for like data hungry applications for robs and stuff like that and then it's also connected into onto the beach engine so the building chain essentially becomes this spine chain the governments do everything so now we have two chains right which means that there's essentially two pieces of software and the hard question right is that how do they communicate with each other right how do they interrupt with each other right like what's the communication protocol for that right so um so far we have came up with a minimal viable protocols that we can provide to get them to interrupt there's four essentially json or physicals there assemble block new block set head finalize block i can go over them quickly in detail so assemble block is when the consensus layer asks the execution layer to uh help me produce a block and then where new block is consistent layer as seen as situation layer to to process and verify this plot and set head is essentially the transcendence layer tell me the execution layer that hey this is the new head of the chin because you don't you don't need to run four shots anymore i can run fortress myself and this is a new hat so just follow it and finalize block is essentially um there's this knife finality property on the proof of state now the execution layer to leverage that property it tells the execution layer to say hey this is finalized blog and maybe everything before this one let's block that we need we no longer care you can do some nice uh pruning and stuff so very high level definition we can go more into detail and these definitions are also um covered in the merge spec and the randy some spec that proto um pulled out earlier so take a look at that as well so i'm gonna take a little um turn and start that more into client implementation details and uh so the client i'm working on is prison and it's one of the four through implementation our client is written in girl and so you can go it has this natural interability with the current institution client which i will go more into detail later and that's our jihad page give us a follow and give us a star and yeah we'll be really happy so there is some decent decisions that we made and i will go through them one by one so we use protobuf and we use grpc so you may ask why protobot why grpc right and we actually we did that a lot right so we we're a huge proponent of grp for the boxing pc because we love the compactness of the format the low overhead and then the strong typing right bytes or bytes integers are integers and we love the ability to essentially generate schema via spec and the spec is actually really useful for both servers and client the spec could be forward and backward compatible changes that cover them really nicely and it has better communication primitives right you have http 2 by default you get bi-directional streaming we get concurrent requests over single connection and all that right and we also can support rest we can support red ql using um its photoshop as well right and then the performance is probably slightly better even for the smaller table and stuff like that so um so the argument again so the argument against protobox grpc here is that rest does have the more simplicity um human readable format stuff like that it the stairlessness part is very nice and it has more features to support existing infrastructure such as like caches reverse proxy and all that stuff and stuff like that so but the end of this but the end of the day is that we we can transcode grpc to json very easily with the gateway and that's what we're doing today so we can support both and this is purely a clan implementation detail here's some code examples i will go through like some code examples and then i will let you see what it looks like in the in the product of grpc word right so this is the beacon block changes under the merge and proto show that earlier as well this is what's defined it's python it's it's pretty readable right it's very readable actually right you get fields and then you get the ordering and you get how many bytes are in the field and this is what it looks like for um pro above right it is it is readable as well right you you you you you get the fields you get the ordering you get how many bytes size on the ssc for the ssd stuff right and this is and so this was the execution payload and that's what the new field is it's essentially what the eth1 blood becomes you trans you translate the eat one block in into the execution payload and then the payload gets appended inside the beacon block body and stuff so it's the last field it's field night and here is the uh bitcoin state changes so the beacon state changes has this new field it's called latest execution payload header and then the header consists of the current data data executions block hash parent has choice-based and all that fun stuff but it's it's readable in python and it's also readable in in under pro above and they and then here we define the ssd size so we know like when we marshal or marshall when you have to root we can get the consistent data behind it this is why i would say right so um so now the next question we have to answer is that right how do consensus and execution know start right so now there's probably two pieces of software two pieces of software that we have to consider so you start your execution node which is your current ethernet get candidate and nevermind more right so you launch a command and the attribution node has a rpc server and i'm just using github as example right now and i use a545 um local host and now it name startup node which essentially has this um preferred no client that listens to a545 and then you start your validate client so there's so there's three steps to it and it's not pretty right like don't get me wrong like this kind of sucks to have to like type this and launch this three times and stuff like that so a cool hackathon idea that anyone wants to work on is um essentially trans uh translate this into a more uniform front front-end stuff so whether you can launch it with a script or relaunch it with a ui and stuff like that and i think uh i think the community could really benefit so how do the how does how how do the interactions look like right so um you can think of this like two distinct events right so there's two things that that so two things that could happen either you're processing a blog or you are producing a blog right so to process a blog it's very simple you get your typical bitcoin blog from the p2p gossip and then it goes to the networking service and then it goes to the state transition service right and at the stage transition service you you break that block apart then you get this execution payload which is what the which is which is consists of application data and then you pass that into the um if one proof of word client service and then you pass that to the get your an smi node and then they will verify that and then tell you whether hey this is valid data this is i can perform valid as execution on top then they will return the status then you can safely confirm that hey it might become blockchain is correct so that's on the processing side right and now this is another um event it's as a validator you get to produce blog right you get to propose blog and that's how you make your most money so to propose a blog it's the same um it's the same path right you you essentially you determine you're the proposer of a slot then you ask your um guest note be like hey i'm producing can you give me some data to produce and then get what return execution payload and then you package that into the block you pass it to the valve that the client the validated client then signs up on the data and then and then and then you broadcast the entire network so there's two paths but it's pretty similar to the to to in it's pretty similar into this process how we process and how we propose the only difference is that we add this additional step that we have to check with uh the execution client so um so i was actually surprised that the lines of changes that so the amount of exchanges were not so much and it's pretty nice so far if you look at our um branch it's probably like five injury lines of changes and the but keep in mind this is not production level code right we're doing a proper concept here so this is pretty prediminary so so the number of main lines of code may increase later right but with that said i do think the heavy hitting is on the e1 client side they're doing more subtraction by addition so respect and props to the e1 client for doing a lot of those work as well right so prison probably has like what 25 package as of today and then the only changes are in those package so probably 20 percent of the time views are getting changed so um so here's just one the main addition right so before you um so before you so after you process the blog you check with this application a execution client on the validity of the data so you essentially you break the you take the block you you look inside the body you get the execution payload and then you basically pass the transfer the you translate the payload from our protobuf data to json data and then you insert that into the execution client and an execution client will tell you whether the data is valid and if it's valid then you can process the block very simple right and then on the other side to produce a block you you essentially ask the execution client to give you the latest payload load and then you return the payload back to the beacon block and we can block it signed by the validator and gets broadcast over the network so again it's very simple so um here's a few screenshots that we did have the interruption running earlier so i i just cover a few screens i put up a few screenshots for fun there are the same screenshots that poor posted earlier this is just a prison beacon node inserting application execution data integrated onenote and this is a view on the e1 node is it's producing block and importing new chain segment and this is the validator client about the client are attesting the blog and also proposing the blog right like now i'm gonna go through a few more slides of of design decisions so um we use bazel and we get this a lot right white bazel and um prism is a model ripple so instead of using the default gold build system our team relies on the basal build system to manage uh to manage the this mono reports uh structure right we love it because of its reproducible build it has a sandbox environment and the builds are pinned with proper dependencies such as gold versions right and this would be guaranteed to have the same um outcome despite like different developers users may have different machines they did right so some common issues that i've seen right that bars introduced uh because of the environment is different than being shipped to users there's just messy dependency management when dealing with the monorepo with multiple programming language right and be so snacks he also has remote caching and then he has advanced dependency analysis and stuff so we have a uh base of goli 3m repo it's a bazel friendly copy of pro ethereum it's nice because we do have gold bindings we take advantage of using go we create gold bindings on top of uh on top of json or pc so we no longer need uh json rpc cards for the opticals that we need to do and stuff like that so check out the report if you're interested it's very it's very cool and here's just an example of when we call a sample block to if you want to produce a um execution block and we can just literally dial the um file the http client in this case is the in this case is get nethermine and it was just called assemble block that's it plain and simple we also use um this ssc library it's called fast sse so uh a quick rewind right what what is ssd so ssc is a serialization format that's used in e2 he essentially converts two standards the first standard is encoding and decoding so how do we decode e2 data such as speaking block and patient state right we essentially want we essentially want a string of advice that can be sent over the network or stored in the database and that string of bytes has have to come to consensus with each other then the second one is materialization so how do we find the hash of a data and and in this case we don't say hash we say the virtual root of the data right so f so we use this as ssc library it's it's essentially generated code so it's very fast and if you're working on this ssc related fields check out that repo and it's it is very interesting and there's a lot more what can be done there as well so just to recap on the api we have our own ethereum api that's that the protobuf spec that that we implemented it has more advanced features in terms of just like bi-directional streaming and then it's a little bit more powerful then we have the standard e2 0 api which we also comply as well so um and then the default um then the default endpoint on the beacon chain on the beacon though is three five zero zero so if you're playing around with it you're doing cool hackathon project where they definitely use those and uh the next one is matrix right and make sure it's super useful in terms of debugging and then and then monitoring and then we use prometheus for scraping matrix their default uh 8080 on the beacon node 8081 on the valve client and then we use refund on to be specialized to basically for visualization and uh here's a cool one that our community member build right and then maybe a cool hackathon idea for this is that someone could combine the matrix uh for um between node and also the execution node combine them to the same place to visualize performance to visualize like transaction related interesting um fields and topics and stuff like that and uh just another idea for our true hackington project then yes i'm personally very excited to hope hopefully to have a merge test net very soon we're working towards that i think there's uh some great value in understanding how the merge will work once we have a test net with the community and then people can interact with dabs and then you can visualize the network performance and stuff like that i think they'll be very useful and very valuable as well and uh getting towards the end so to contribute feel free to join our discord or check our github open issues we have a contribution guide as well and uh and not just for prison prismatic labs right please do check out other youtube clans they're not here today but um they are not here presenting today but they also are doing amazing work and actually and they could use help as well so uh check out uh thaiku lighthouse nimbus and all star there's definitely tons of work there and they are also amazing and uh yeah and that's for me thank you for having me and shout out to it bobo for on hosting such an awesome event great thanks for all the insights uh we have a couple of questions that i want to relate to you so first of all while your talk was going on there was a lively discussion already going on in the chat with regards to uh execution responsibility and basically the the overall question was like why not implement the eth1 execution functionality into the beacon node software directly the person who was asking this yes he already got a reply via the chat but he wants to hear your opinion on this as well right right i think um i think there's two sides for this so i think there's need to this um short to mid term and it's long term writing to me to short term uh having the separation of concerns is nice giving the timing constraint and stuff like that and and you also lower the risk right you don't want to redevelop ebm you don't want to be developed transaction pool you don't want to redo all those writers it takes years of engineering research expertise of that right and then we want to leverage as much as possible so having a separation of concerns it's nice and so now the question is that how can we make the process better right whether it's uh launching a unit five uh front end to essentially to to kind of make people think that we're actually not running multiple process but we are running multiple process so i think that's a really good hackathon each project to think of and i think people should pursue that then another question right here will the public testnet also interact with other non-prison clients and any time frame for the test that yeah so the goal for the testnet is to be multi-clan-ish to start with so there will be lighthouse they're doing great work tactical of course they're the first one that's doing it and invest as well so you will be multi you will definitely be multi-client uh talking with multiple of each one sorry a situation plan as well right so timeline i think um this week we'll be making a lot more progress to be honest we've probably made so much progress less the past week than we have for the whole month so i think we're close i think next week or and early next week with uh with the leadership of proto and stuff we should be able to launch up a semi uh semi devnet and once that goes well we can go off to publish and then lastly a rather technical question why are you using bazel instead of pure go oh yeah i feel like covered that so long story short we use space such as the resource of the reproducible build because of the mono repo each setup that we have and the and also because of the remote and then the local caching and stuff like that and i get that right bazel is there's a little bit of learning curve and stuff like that but once you get used to it it's not too bad it's just it it it is super fun uh i think that's it in terms of question thank you so much for for joining and sharing all those insights with us