Consensus Improvements Roundtable: Rainbow Staking

Transcript

which is speed of light first principle, minimal slot durations versus the pragmatic incrementalist approach of just picking the lowhanging fruit and not necessarily aiming for for the optimal stuff. So, we're going to get uh Bonab um kicking things off with rainbow sticking. Thank you. Okay. Yeah. So, I'll talk a bit about rainbow staking. uh this uh let's say framework uh that I wrote about last year in a in a post that was trying to make sense of many different ideas that had been published before that by Vital Donrad Justin as well um yeah I'm Barnab

from the protocol architecture team I'm happy to be here so the I would say leading question like that's kind of hiding behind all of this is what will staking look like in five years so there There are many layers to to staking. There's the cons mechanism. There's the leader selection with all the validators. There's the economics of it. Um and the staking experience that we have today could be very different let's say five years from now. So today we have like this single entry point. You have to stake 32 if that signs you up to become a network operator, a validator. And basically you are tasked with doing uh pretty much everything that we can think of that should fit on

a machine that that works for us. In the future uh we think it makes sense to possibly um unbundle the services that validators are doing even further and that's what underpins the idea of rainbow staking. So having much more diversity and many differentiated services done by by different uh service providers. So this is a quick map of stuff that is done today by the machines. Censorship resistance by making blocks. FFG finality gadget function as RPCs. LMD goes for the aable chain syncing the node and the sync committee proposing blocks and being the builders sometimes if you don't outsource it.

But one of the thing that is uh let's say at the core of the staking experience for you as a validator is that your ST this 32 that you put in deposit is fully stashable and this is what we say provides us with this feature that we hope is useful to people who consume Ethereum which is this economic security. There was a lot of debate or there's always a lot of debate on what economic security means. So I want to go a bit into this because I think it's also important to understand why unbundling makes sense. So economic security is really the ability for the network to say X if will be lost if Y happens for some amount X and for some

outcome Y. So for instance, if we ever had a safety fault of the finality gadget FFG, we should be able to say or we will be able to say at least a third of the if that is currently staked needs to be slashed. And so we can um basically evaluate the the total loss of of economic value to to the network. Another part of a of a staking experience is the pressure to delegate.

And I think we've seen now that delegation is almost inevitable in in proof of stake. Like that's just a a natural consequence of the the phenomenon of separation of of capital and labor. And in fact, unlike proof of work where you had to the capital is machines that are doing this this hashing in proof of stake, the capital is e. So it's much more liquid, which means it's also much easier to to delegate. And when you have like a smart contract platform that underpins like the network, it's even easier because now you have all this infrastructure to to do like all these programmatic uh maneuvers that allow people to pull, to delegate, and to have like really sophisticated payout systems.

And so one thing that's also to note is that the the capital let's say for me as an eh holder or for people who are looking for ways to allocate their if is that they they're always seeking yield. That's usually what capital does and so they are they tend to go towards delegating where the capital has the highest efficiency and so where the operators are the most uh capital efficient. When we put these two things together like the economic security and the and the delegation the story gets a bit unclear and in particular the act of delegating bodies a little bit this uh story of economic security like we say x if will be lost

if y happens but we don't really say whose if it is that that gets lost like is it directly the if of people who attacked like when I give my if to lido for instance to to delegate and they are part of validators that are slashed. Is it me who attacked the network? Is it Lido as a protocol? Is it one operator of Lido? It's not always very clear. So the the delegate could be at fault and lose the the stake of their principal. to be the person who who stakes with them. Um and and we have this principal agent problem that means essentially that yeah we can have a faulty agent that can be much

cheaper to corrupt than the amount x that is lost and still get a network fault. It doesn't mean that economic security is a meme. like there's a lot of positive things from having this constraint of X if being lost but it just does not also mean that X is the is the cost of attack to to the network and so why do we still have this idea of economic security or why I think we have it it's because we want to impose a certain amount of discipline on the on the network like we want the principles so the person the people who provide the capital to choose their agents carefully like to choose the operators that they delegate to uh in a way that yeah

they're conscious of the risks that the network carries and they and they also asks their agents to essentially level up like to be as credible as possible uh to provide guarantees that the agents are just not going to get trivially compromised or or participate in in attacks. So for instance, what we're seeing now is innovation with the dual governance of LIDO distributed validator networks and many other systems uh that allow us to be more confident that the agents are not going to be compromised. Another positive effect is uh having this possibly very bad outcome and the commitment that we will go through with it because it's it's programmatic um

means that we really have an incentive to make client diversity work and that prevents against what I would call oopsy slashing where we have a consensus bug in a majority client and we finalize like something bad and then a lot of stake uh could be could be lost. So having economic security is I believe good but it does impose like a lot of constraints and pressures on the on the network. In particular for home operators, uh it's a it makes the picture like a little bit more difficult for them because they apply really untrusted like they just look like an address on the on the network like you don't have an offchain signal of their

credibility like a DAO or a corporation or or something. So that makes them fairly capital inefficient because they have to convince you of the fact that they're not going to be trivially compromised or participate in an attack. Another thing that's a little sad about home operators that today they're not really a large enough contingent to block super majority from capturing finality. So I believe we have about five to six% of solo stakers on the network and maybe 3.5% more participating in rocket pool and the lido committee staking module. So it's really far below uh the 33% that would be needed to to prevent finality from

happening if the other part was uh captured. And so if they're not so effective at that layer like why are they still needed in my opinion for multiple things? The first reason why we really want to have home nodes on the network is because we assume that by being so numerous and by having so distinct preferences from trusted operators, they are going to be very good at providing censorship resistance. And the way that they do that today is essentially via local building. So if they are proposed the task of building a block, if they decide not to outsource it, they can decide to outsource it. But if they

decide not to, they will impose their view of the network via this uh this building. That's the first feature. Another feature that they have is you can think of them as an active layer of monitoring. They are paid to be around and to attest uh their view of the network. Uh so that can come in handy. Let's say the network was sufficiently under attack like we know that we have uh this reserved army that's ready to to step up. You could make the case that uh over non-staking but still validating nodes like full nodes could also be part of of that line of defense. They're also following the network, they're also executing the

rules and they would also detect uh if something went uh wrong. So the question is can we get the best out of what the home nodes have to offer and maybe make the picture better for them. Uh yeah so today we're doing local building like that's the contribution I picture three roles the role of attesting like that's the envelope of voting the role of including that's the little truck and the role of building with the with the crane. So yeah, local building is their way of including uh transactions and if they outsource uh now they're not really providing the role of including transactions which is the dotted line

because now they're not sure that the builder will will provide it for them. So when we unbundle like we we might lose some of these properties. So we we have to be a little bit careful. The one way that we can recover the participation of home nodes in these essential services that they're really good at is to allow them to specialize in some of these goals. And in particular, I believe that decoupling the pressure that economic security imposes on home nodes would be a very good direction for making them just more powerful on the network. So when we try to fit every type of node commercial or home node through the same pipe and this pipe is essentially bound to this idea

of economic security being fully slashable having a ton of risk we don't really put these home nodes like in the on the on the best footing and and for some of these services uh we don't actually require like this extreme pressure to be efficient to be trusted to not get smashed uh at all And so can we uh separate these two kinds of of services like the ones that don't require economic security from the ones uh who do? And so that's pretty much the pitch of rainbow staking saying we can have on the one side a category of service which is fully slashable like heavy services and on the other side a category of

services which is not slashable and the the services that are slashable could be fairly specialized quite thin have very sophisticated actors capital efficient that provide it and on the other side the non-lashable services could be much broader much more fault tolerant than the than the heavy services. So that's the first separation. Let's say vertical. And then I believe that since we are seeing delegations to be such a natural phenomenon in these in these services, we might as well also enshrine the fact that these delegations exist.

And so we can have this horizontal separation where for each type of service we can make the distinction between operators and and delegators. to make a bit of a distinction between the two. So yeah, heavy services are slashable, light services are not. The purpose of stake in heavy services is really to provide economic security. So to make these commitments of saying money will be lost if something bad happens. For light services, the stake is a little different like we can call it stake, but it's more there to provide civil resistance and leader selection mechanism. So we want to be able to select the people who are good at providing the the light service for

heavy services because of that economic security. We expect them to be fairly intermediated meaning like you will have agents that are sophisticated that might have like longer chains of intermediation like for instance like there is a protocol has node operators under it like it's very like it's not just a single person with a box. Whereas for light services, we would want them to be like easy to provide and and just like directly provided by by operators as much as as possible. Um something about heavy services is since they carry risk, it means that the yields or the cash flows that are um earned by the operators are not funible to one another. That's one reason why we

have LIDO which is essentially a protocol that makes funible the performance of different node operators. But for light services since there's not real risk because there's no slashing we can have like much more funible provision of of yield or cash flows if we have them at this layer and we can also have much higher fall tolerance because the risk may not be uh slashed and it can have like different um penalties. For the heavy services, we need this very high alignment between the principal and the agent because again there's risk. Whereas for light services, it can be very low and if the agent is not doing what you want them to do, you can very frictionlessly delegate away from from them.

And so yeah, that's a picture I presented at protocol B, but it's kind of my view of the ideal, let's say, state of the protocol, which is not one where we have a single, let's say, type of entity that does everything, but more like we have groups that do different things and that are keeping each other in check. And I think that the best way to have resilience on the network to ensure that these different groups like the the political economy that that results from having separated between different providers who are specialized and very optimized for for their for the for the role that they do makes for a healthy network where uh we can just yeah rely on the

fact that we're not dependent on a single type of of provider. It it's in a way thinking of plurality at the scale of of protocol design. What is this down the left? Oh yeah. Yeah. So I I'll I'll talk about this. So the includers are the ones who Let me I I'll ramp up to this. Um so one key light service is fossil. So fossil is a censorship resistance gadget that selects every slot in the current parameter. It's 16 16 includers who propose bundles of transactions that must be included into the into the block. So it's a service that you only

need to pick 16 people and they only need to give you like these list of transactions and the network can enforce that they are included. So that's a very powerful service to to augment the censorship resistance of of the network. you select 16 nodes, but actually the honesty assumption is very weak. Like you only really need one node out of 16 that does a good job for censorship resistance like to to apply to the to the network. Once we have technologies such as ZKVM datability sampling, hopefully you can even provide that service with very weak hardware and very low capital. So much weaker than what you would need um for for staking and ad

testing. And so that means that we can actually have two different versions of FOC. So one which is the one that we're currently developing where the roles are bundled. So where the validators are the ones who are also the includers and one which we call light force which could even be hidden behind your wallet. So as long as you have some positive balance you could sign up to be one of these includers. Uh you could have the correct view of a chain through ZKVN and D like sampling is very efficient. You could have a stateless pool at the back. You would still be pretty light and you could just participate as an encoder with this very weak assumption. And maybe sometimes you're offline, but it

doesn't really matter. Like it's a very fault tolerant service because you again you really only need like one of the person you sample at any given time to to give you like the the correct view and to to provide censorship resistance essentially. And so I think that's a a very powerful option for us to have censorship resistance provided almost like as a swarm at the network level. So if we are able to separate let's say the light services from the heavy state from the heavy services um there are some benefits to having like this firewall. So on the one hand we can have better censorship resistance let's say provided by the light services but on the other hand that also means that we

can have perhaps stronger assumptions on the providers that provide the heavy services. So we can still keep in my opinion the testing layer fairly permissionless but maybe we could even consider like having slightly higher minimum effective balance to participate at that layer if you could also participate in the other layers more permissionlessly. That might be a good idea because again I think we really need to get to faster finality soon. Uh the quickest way is to shrink the validator set which doesn't mean kicking people out like again today we have a million validators but we really have 8,000 nodes behind them. So even matching this would be would be would be effective. But we could also be

thinking of what this separation buys us in terms of assumptions on the on the heavy services. And I think that's an important question that we should ask ourselves. Another point on the economics of light services. So I'm saying let's send people away to these light services. But the question that would come is well are they paid? Are they incentivized? Like this is the part where it's a little bit more tricky. We have actually designs for incentivized for sale. So it's possible. The question is whether it's desirable because the minute you put incentives the minute me jumps into the picture and can easily derail the mechanism purpose which is censorship

resistance. Um there are questions like for instance let's say I invested recently in a better staking note because mine burnt out. Um so now I have this midsized note at home. Can I still use it for something useful? like even if I want to do if I don't want to attest but I don't want to just do like a wallet thing um we are talking a lot about RPCs partial state provision like that's a lot of designs that are currently being discussed and so yeah another alternative is this idea of home provers with the protocols that distribute work. So in my opinion in the future like we won't lack um options for services that fall under that category and we may even have like alternatives

to to incentivize them such that uh people are paid for the useful work that they provide uh to the network and so what should we do given this picture? uh I think shipping and seeing all of this tech that enables this future uh go live will really reshape our perspective in terms of what's possible with these different light services and heavy services in particular I believe after ZKVM full D and seal ship like we have a very different perspective on what being a node means and what are the multiple possibilities of providing value to the network beyond just being like a single bundled staking node then we might have

an easier time also articulating like the things we really want from our node and so yeah I think we should accelerate on all of these tech tree and revisit the question every couple of months to to see where we're at yeah thank you [Applause] any questions Yeah, I don't know how super related it is, but if the staking uh limit goes down to one ETH as has been said

sometimes, uh obviously the the APY for those that stay would go down. Do you think that would be enough of incentive to for someone to stake one E as as little as money? You mean if more people st the APY would go down? It would like proportionally the the the gain of someone uh staking money would be much less. So would people actually do it?

Yeah. So that's that's a point about capital efficiency. So I have fixed cost to staking and this cost will go like way way lower and and I believe in the meme of smartwatch staking that that Justin has like you might be able to stake with like a Raspberry Pi or something very very light. But it's true that the more capital you put on your fixed cost the more capital efficient you are. And compared to staking pools that are able to put thousands of ETH on a single node or a single protocol or things like this, like you're always going to be at a bit of a disadvantage when it comes to like the real yield that you get from. So there was a lot of conversations like last year around issuance and how we should be thinking

about the relative earnings of solo sters versus home operators versus professional operators. I would say the question is still not settled but I don't think we should do anything about it until we figure out more about this larger picture of future staking but yeah I think it's a universal truth of capitalism that the more capital efficient you are like the better you will fair in any system that that ranks you according to that metric. Yeah. Yeah.

How about one question is um if we unmodle all the roles into lots of specialized operators, how does this impact the ability to very simply have social consensus or organization to have for the chain? Because today everything is so simple that there's only one thing to do which is for the chain. If there are eight operators, how do you contact them? What do they need to do in order to Yes, I agree. So I think um the worry that I have is the operators that are effectively in control of the chain are the at testers today and as I was saying like the home operators don't really have a blocking minority there. So there's a lot of like signals or things

that they couldn't really do. My again coming back to this picture which is not at all an argument but more like a mental model. I think once we get to that world, we may also have like much more tangible ways of triggering things such as a community reaction. So let's say for instance all these like millions of wallets that are passively doing for sale at the back they might be emitting like messages to say I've seen these transactions. These messages might have chromes of other wallets saying we've also seen these messages. Over time, you can build actual evidence that can be used to programmatically trigger like certain actions. So today, we're kind of reliant on only having the

testers performing their role. If the testing layer was fully compromised and was starting to censor, it wouldn't be like so easy, I think, to to say, oh, something's off like we could do it, but there would be like a bit more of like community organization. So the idea with this is giving us the tool to make much more automatic and programmatic like the the reaction and the uh the courses of action that we would want to take if let's say people were making inclusion lists but weren't included on chain because they were still censored by the testers in the model that we would have with heavy fossil is the same people like the testers are the ones who are also making police and so now when you

have two groups and they're both doing like different things. You might be able to have like much more uncorrelated signals from either side and then be able to uh programmatically trigger courses of action based on these signals. It's a rough picture. The rainbow sticking post goes a little bit more into detail on this, but I think that's yeah will be the main value proposition to to have better signals from entities that are uncorrelated from each other.

If we have permissionless uh uh signature aggregators, so where would they fit? They would fit in includers. Um I I'm not sure that we would need for instance economic security behind these aggregators. Uh but for example in being protocol they come with proof. So you don't actually need any security from them because they will be provable. Yeah. So you might So there's basically two types of faults that you want to prevent against. First class is safety faults and the second class is livveness faults. So you might still want to have some kind of economic penalty for livess fault like let's say if somebody is not doing their job. Um, in the case of let's say light fossil, I don't actually

think lifeess faults should be penalized. Like I think if I was to point my Eve to Justin because I believe he will do a good job as a person making up inclusion list and I see that over time his performance has degraded. I can just like point my Eve away from him. for services that are maybe more critical like a aggregation perhaps we would want to consider like economic penalties for livess codes like if you are signing up to be an aggregator and you're not doing your job maybe we do actually want to slash you but it might be much lower risk than fully slashable for instance so it could be like just partially slashable but if we have permissionless aggregation then maybe I can delegate my

eat to for example Justin and if his performance goes down then I'll probably might to someone else. Yeah, that could be a way to do it. Yeah. Okay. Thank you. Yep. Thank you.