Jason Carver, Daniel Ramirez - Staking without execution clients

Transcript

all right thank you all for being patient there it never never fails there's always technical glitches some somewhere in a presentation uh so I'm very pleased this morning to announce our uh second speakers here joining me here is Jason Carver and Daniel Ramirez both with the ethereum foundation and today they're going to be talking about replacing execution clients in staking setups great thanks so uh as you said I'm Jason also known as Carver online um I've been the the ethereum foundation for about six years uh formerly working on python tooling like pm and more recently on the portal network uh and the r client for it called Trin um I'll get more into the portal Network later and uh in a couple

minutes I'll hand the mic to Daniel but we got a lot to cover so we'll just get started so we're looking at staking and the future of it without a full weight execution client so uh how how are we going going to address this question so first we want to talk about what are we interested in aiming at what's our ideal for for what it would look like to have a lightweight staking system and then we'll back up to where we are today where Daniel will do the technical review of how the consensus client and the execution client talk to each other during staking and then we'll come back to looking at active lines of research right now and how they each move lightweight staking forward and how

they'll add up together to being able to get the full State execution client out of the picture so let's look at lightweight staking what does that mean can mean a lot of things but uh obviously in general we want it to be easy to stake we want it to be easy to start easy to administer the setup and um there's several impediments to that but the one we're going to talk about today is dis space usage so we would love to be measuring dis space usage in the 100 gigabyte or less range rather than the Thousand gigabyte or more range and um the execution clients play a significant role in that of course and uh what they they are incredible pieces of machinery

and they're always getting better but it's hard to imagine optimizing them to the point where they can hit these targets while still being a full client so that takes us to the point of view of thinking okay well seems like we're going to have to seriously consider removing it from the staking setup altogether to hit this goal so in order to really understand what that would look like we have to kind of back up and see how our execution clients used during staking today and so for that I will hand it off to Daniel yeah hi everyone my name is Daniel I have been contributing to multiple projects on the ethereum ecosystem for the last year and a half and now I'm part of the ethereum

protocal fellowship uh yeah so let's talk about how staking works today um well as all of you might know running a validator node is something that uses a lot of resources um but why H well most of the blame can be attributed to the execution clients because if we do a quick comparison we can like we can see that the latest execution client uses about eight times as much disk space as the heaviest heaviest consensus client and the same thing happen with other parameters like memory bandwidth and yeah other things like that um but why

does this happen like what does the execution client do that needs all of the these resources um well it's mainly three things H starting up the out building blocks and validating blocks so let's see how this works under the hood well the two clients you use the engine API to coordinate all these tasks and I will be using these diagrams sequence diagrams to explain all of this so just a quick introduction the the vertical line on the left is the consensus client and the vertical line on the right is the execution client the

horizontal lines just indicate the API calls or the messages that they send to each other to communicate so yeah uh with starting the note H the first thing that happens is that they do a handshake they exchange what engine API methods are available on each one of them and after that the consensus client calls Fork Choice update um which basically tells the execution client this is the latest data I have on the fork Choice update your fork choice and execution client will verify that data and update its Fork choice if it's correct uh now with blog building uh the consensus client is assigned to propose a block and calls purchase updated but

this times with a second parameter called payload attributes um this indicates the execution CL the execution client to update its Fork choice but to also start building an execution payload and after some time the the consensus client will retrieve this payload calling get payload and finally block validation um for validating a block the consensus client receives a bon block it racts its execution payload and sends it to the execution layer to get verified by using the method new payload um I wrote an article explaining all of this in more depth this is the QR code to it if you're interested in

learning more about the engine API H but yeah what does all of this means well it means that to run a validator node you need one client that is able to to respond to three endpoints NE payload for dat and exchange capabilities and what do we need to be able to respond to those endpoints well we need a mechanism to allate blocks a mechanism to build blocks and access to the chain data and well how can we do that on a light way manner we can't right now uh the only way to serve those endpoints is by being a full weight heavy execution layer client but there is some research being done right now by

high like researching how we can solve this and Jason will tell you all about that okay so what are we going to do about this where do we go so a quick recap of the some of the main challenges we have here is we're going to need to validate blocks from peers we're going to need to propose new blocks and uh perhaps outside of the staking scenario we're going to want to look at uh the chain State uh sometimes within it so let's we'll do a a little bit of a spoiler here about some of these Technologies so veral uh proposer Builder separation and portal are going to help us address

these things so let's look at how that's going to be possible um first I'll say that portal is where I've spent um my time in the last year or two um that's where most of my expertise is in um but vertical and PBS are are core and critical components for this plan so I'm going to do the uncomfortable thing talk about them anyway despite not being an expert in them and I have a little bit of an ulterior motive here which is if there are experts in them out there watching this uh and I say something about the future of how they fit into lightweight staking that uh you disagree with then uh at me you know let's let's figure it out together um so uh let's look at validating peer

blocks now just to confirm this is not an optional thing we can't just skip this step because if we skip this step then proposers can make arbitrary State changes and on the network and they become canonical we absolutely must validate blocks coming in from Piers so traditionally the way we're doing this is we get the block from the pier we execute the transactions in that block against the chain State um and then uh compare the final State Route against the the block committed to by the pier and to do that we need the full client unless we include the state access during that block along with the block itself as it's passed around peers um

and by doing that in theory we can have a stateless client that uh reads the state out of the bundle with the block while executing the transactions in it and technically it is possible to do that even with Merkel Patricia trees today um the challenge is that they're too big well they're not always too big in fact often there they would be just fine but it is possible for an adversary to construct a block in a way that would make them much too large and would uh drag the network to a hall so uh it's a non-starter to include with the current tree structure and that is one of the key uh benefits and behind moving to veral so veral is a tree structure that

will allow us to create uh the state witness which is just another way of saying the list of state that was accessed during the block and the proof that that state belongs to the canonical chain so veral allows us to create the state witness that's small enough reliably small enough to bundle with the block uh being passed around to peers and so uh in this future the stateless client can execute those blocks uh without um you know keeping any uh State data locally and I'm going to plant this thought here we won't go deep into it this moment but um when you rip the state out of a client uh and make it stateless it can now only do this one thing which is verify the

transactions in a block that have an attached State witness so uh so with veral we can address validating peer blocks and but that doesn't help us propose new blocks yet so let's look at proposing new blocks which is the process of looking at the transaction pool and including them it's your slot you're the proposer you've got to look at the transaction pool throw them into your block uh order them for for fees and this is obviously going to require State access and really there's no way around this so it kind of seems like we're stuck until the moment that we realize that we can separate the roles so you can be a proposer and then

ask someone else to build the block for you and that is the essence of proposer Builder separation so we it's your slot you say hey Builder make a block for me and in a post veral world uh you act in in many ways like a validator of that block as if you were getting it from a peer you still have to make sure that that block follows the state transition rules um but that block will include the state witness um the block from the Builder will include the state Witness and so you as the proposer can validate it and then uh start passing it around to your peers now me boost is kind of an informal proposer Builder separation

that's available today of course um and uh so so why even include this it seems like we're kind of already there um and the answer is that we want lightweight staking to be something that that we as a community are happy about if every Staker is doing this right um and there are reasons to think that we might not be happy as a community if 100% of stakers were using Meb boost in today's iteration um there are some open questions there's reasons why we want to formalize it more broadly into proposer Builder separation mechanism um so for example uh you know the story for transaction censorship is a little bit

weak in me boost right now um uh but you know that there we're a lot of the way there and uh and there's some great work happening on on formalizing this so we're kind of there maybe maybe we're done we've we've validated the blocks we're proposing new blocks and uh really those are the these core features these core needs of a of a Staker but I want to come back to this question of what is the stateless client capable of and as as I mentioned before basically nothing it's it's useless it's it's useless um if you want to do things like look up your own validator balance you can't do that on a stateless client you

can't do anything with it besides validation of blocks and so um there are lots of things that we might want to do like submitting transactions for withdrawals monitoring the deposit queue um there's even reasons to think that we might um if say proposer Builder separation is uh is in a sort of offline mode you might want to at least build an empty block and you would still need some state to do that um in order to create the new state route and so um there are reasons why we might want access to some State on demand so if you take a stateless client and you uh add in the concept of on demand State then uh you get what I'm going to call a just

in time State client so this jit State client is something that we you know is an important piece of the puzzle for how do we get towards this lightweight staking and uh our answer for that uh is the portal Network so let's look at just at the portal Network and how that can help us get to jit State clients so portal is a network that was specifically designed for the idea of on demand selective access to state in a way that's verifiable against the canonical chain so um so you can join this peer-to-peer Network and you store some small sliver

of the chain and uh for any pieces that you don't have you just go find the pier that does have it and download it that uh you have enough information between what the pier gives you and you already have those together are enough to validate this data against Real chain information so when we take that on demand State access and we pair it together with a with a stateless client right we can stand on the shoulders of the stateless client uh teams here and we can get Block verification now we've got we're on our way towards a jit State client um or really we there um it's worth noting here that of course to get State on demand will necessarily have

higher latency um we're never going to be as fast at finding peers who have state and downloading it from them as we would to load it in a single shot from local a local SSD but uh if that means reducing our dis storage needs from a terabyte to a couple gigabytes we figure that's a trade-off that a lot of people would be uh happy to make especially when you're not in the middle of say proposing or block we're talking about using this OnDemand State access for uh for sort of noncritical path moments so how do we get to this Leg State client it's useful to look at how

um at this as sort of two axes and there's on demand state which I've just talked about with with portal and then there's of course the execution clients that have already been built um and uh and the idea is that with if we take portal uh which gives us on demand State as we're heading towards it now this is by the way portal is in sort of an alpha situation you can uh look at it and check it out but it's probably only ready for you if you're happy browsing GitHub repos it will be ready for more people soon um so we take the portal client and we add in the stateless client we embed a stateless client and we've got a jit State client um and you know that stateless client is a

relatively straightforward thing to pull out of existing execution clients they just can kind of rip out all the local state storage and learn how to read the state witness that's embedded with the block um but the question is you know these execution clients might want to make jit State clients themselves and the question is how do they get there well from the stateless client to a jit State client is sort of an unknown path there's um a lot of challenging questions that that of course we've looked at from the the portal Network and we've been able to design our clients around those needs from the beginning and it's not clear that say taking the existing execution client Network and adding some features will help get them to to On Demand State

access um so you know if if they want to build their own solution they can um and you know we'll we'll race them there to the jit State client it'll be fun um but of course they do have the other option of just joining the portal Network right so they can either import a portal client into their own execution client or they can Implement their own uh version of a portal client using the public specs from Portal Network and we of course welcome that and if there are any client teams out there listening that are interested in this uh please reach out and we'll be happy to help so with that with a jit State client uh veral and uh the proposer Builder

separation will be well on our way towards a lightweight staking future so that's it for now and I think we have maybe a minute for questions great thank [Applause] you yeah we do are there any questions from the audience so perfect H thank you very much not that I really understood most of the detail that you were presenting but just a very general question as a staking uh um operator is it something that um you expect everyone to move to to save costs and to be more efficient when providing the services or is it something um that

only specific um uh operators will adopt in the future yeah we think there there will be a lot of incentives to move for for most stakers to move this direction the the big downside is if you do need uh you know close to instant random State access for some reason or if you or if it's important to you to be your own block Builder those those would be two reasons why you wouldn't move this direction any other questions from the audience here yep um so right now the consensus layer is pretty sensitive to latencies like

how how could this impact like the performance of a validator running on a stateless client based that now like the latency is getting even shorter like we talking about not 12 seconds to propose a Blog and send it but four like how does it impact right so the um the higher latency that um I mentioned before about sort of on demand State access uh often would uh sort of make it impossible to to do your staking duties that's why it's important that everything that you do as the Staker in your slot or a verifying blocks all of that has to be done stateless so that that's why veral is a a hard requirement for for this path um we can't we can't introduce latency there without without

causing problems so yeah I think you have you have the right idea excellent well Jason Danielle thank you very much for an excellent presentation yeah [Applause] thanks