Fixing Compounding Rewards Liquidity with EIP-8148 — Dmitry C | Lido

Hello everyone again and today I'm going to tell you a story about the money that gets stuck not lost not stolen but still like out of reach and a fixed to it in AIP 8148 and one little knob but to get why the knob actually matters we have to back up a little bit. So here you can see the agenda for the talk so you you could get the idea when you will get bored in the next like 15 minutes or so. But uh for now let me start at the beginning. So quick uh quick history lesson uh it will be really short. Well, for pretty long time on Ethereum, we had uh validators kept at 32 EF, not 33, not 40, at exactly 32 if and when your validator earned rewards and its balance went above the 32 if the system automatically swept the extra out to your uh wallet on the execution layer.

And it sound nice because in this case you are getting like a constant rewards flow but it also means that there were no compounding the um and that was it. So and what were you doing if you had more if like so the answer was pretty simple. You create another 32 if validator and another one another one and so on so forth and as a result the network grew to over 1 million of validators. And the problem with is that it means that a lot of machines chatting with each other over the network every single second. So the if you made an upgrade called an AP7251 the floor stayed the same.

So it's still just searched to Eve to create a validator and it's important because it keeps solid staking still accessible but the ceiling went all the way up from 32 E to 2048. And to actually use this you just pick a new withdrawal credentials type 0x02 that called compounding. And now you get a flexibility. Now you can have like more flexible if amounts on your validator. It can be 32, it can be 40, it can be 64, whatever up to the 248 if.

And it was good like uh it was really good for Ethereum because now um large entities can just combine m their multiple operators into a fewer but bigger validators. And fewer validators means that there are fewer messages flying around the network. It means that fewer signatures has to be checked at every epoch. And in general it means like basically lighter beacon state and lighter beacon state means lighter consensus and just um more room to grow. But what if you just a homestaker um what is for you?

The problem is that with 0x02 credentials, the automatic sweep I was talking about kicks in only when your balance is above 148 if and everything that is below this value keeps compounding on the consensus layer. So rewards are basically trapped there and um in this like world in this situation the solsters have only two viable options. So first um like in the case they have more than 32 if so the first option is you create more um 32 if validators and then well uh you have multiple keys that you have to keep an eye on. It's uh basically more load and just just the same thing. The second approach is to run one maybe that's multiple but bigger zero x02 validators that uh climb toward 148 if but the problem is that well rewards are stuck at the cap and the only real escape is doing manual partial withdrawals but we will get in the minute why it's why it's not the great answer but first let me put into perspective what actually 2048 E is it's kind of easy to say the number even though for me it's maybe a little bit hard to pronounce but uh still um but it's kind of hard to actually feel.

So think about 32 if like basically enough money to buy a car currently. 64 A if is two cars still fine but 2048 AF if it's basically 64 cars and well there are plenty of household that have two cars but uh if you were being told that you have to like get 64 cars before before getting any rewards for any like home stakers if you put it this way it sounds just crazy and if you just well patient enough and you decide okay well I'm just put 32 if up front and then we'll wait while like climb toward the 2048. Well, bad news as well just because at the current staking um APR it will take 162 years to get from 32 E to 2048 and even if even even if you start reach at 1,024 E basically half the current ceiling it will still take 27 years to get to the very top. So one can say okay just do partial withdrawals like get the rewards manually. The problem with this is that first of all it's manual transactions.

So you pay guys for it. You have to get like tooling for this monitoring. You have to keep an eye whether we actually went through. So it's a lot of a lot of it is just a chore. And another thing is that the uh partial door request share the same exit queue and it leads to unpredictable delays with withdrawals.

And if you do like uh small frequent withdrawals and bas that basically what the reward was harvesting actually looks like it becomes like um just unreasonable from practical standpoint. And there is another small cage that is pretty easy to actually miss is that when there is a pending partial withdrawal like uh still on the consensus layer waiting to be applied, you can't actually exit your validator. You have to wait until it's processed. And this thing is actually can get in your way like in the most uh like in the worst moment um for you. Well, so now you might think that well soul sting is like pretty tricky.

So what if I join a pool? Does the problem goes away with it? Let's have a look at this and an example of lighter community sting module. Uh it is sliders permissionless staking module for home stakers. Here's the deal.

You run your validators yourself as a node operator. You provide uh a bond which is just a fraction of set to eve that is required to create a validator and the lighter protocol provides the rest to the validators from the pool and your bond is your skin in the game. If anything gets wrong and you get penalized the bonds covers for you and in the current uh like today it looks something like this. If you have more if to stake, you provide more bond and you create more validators. The catch here is that each one of these validators is basically uh yet another ZX012 if validator and it means that still more keys more val uh the same network pressure and well CSN like didn't cause it but uh it just inherited from how the network is constructed today and there are plans to bring compounding uh to CSM uh it's uh I'm coming 0x02 to CSM module.

Uh it actually will be live like Q4 this year and it was connected to the protocol that tested like basically a few hours ago. So we are actively testing it now. Uh and the idea here there is that you can now create uh bigger validators up to 48 if with 02 credentials and it means fewer keys and overall better capital efficiency. But there is a catch as well just because the bond now must to secure the whole like large validator and instead of like small fine like steps in bond you still box to large and coarse ones. So stakers in this situation boxed in again and we're basically back at square one.

So now to the solution EAP 8148 one optin knob that fixes both solar and pooling. And here's the idea. So currently the automatic sweep is can like um happens at the hardcoded 248 80 48 if value but with this EAP you can basically say to the network sweep everything about X if to my withdrawal address automatically forever and you say ex whatever you like and this thing is fully optional if you don't touch it nothing changes for you but if you do there is no manual transaction perhaps There's no waiting in exit Q. It just works for you automatically. There are just a few simple rules.

Um your threshold request, your threshold value has to be whole number of if uh somewhere between 32 and48. It can be only set just at or above your current balance and we will get we will get in the minute why it is important and it also can even be baked in the deposit time. So it just can be encoded in withdrawal credentials and your new validator will be created already knowing its own cap for the automatic sweep. All right. What it gives to people?

First for solo stakers it unlocks the automatic harvesting or rewards at the userdefined cap. No gas no f sounds really nice for pooling like for a convenience thinking model. example, you can like think about the model that can um allow creating a more finally sized validators with more flexible bones instead like large and coarse ones like in the 02 CSM for example. Now let's talk uh about how it works under the hood. Uh it's pretty simple, no worries.

Uh in general it includes just three steps that crosses both the consensus layer and execution layer. But everything starts on the execution layer. So the user calls the predeploy uh special system contract and hands it uh the its validator pop key threshold and attaches the fee for this request. This request is then being cued in the smart contract own storage and sits there for a moment. Then at the end of every block uh the system basically calls this contract and drains the queue up to 16 requests per block and then attaches these blocks to the exe exe attaching this request to the execution layer block.

Uh this is like a standard mechanism. It's it was introduced in EP7685 and it it's basically the same as the partial withdrawals. And finally when the requests uh crosses the execution layer and the consensus layer just picks up every valid request and just immediately sets the desired sweep threshold. And from that moment on the automatic sweep works for you at the threshold defined by you. From the user perspective it looks pretty much the same.

You just u just one more step. You have to first call the uh pretty contract with empty input to get the actual like the current fee uh and then you just make uh like the send the actual request attaching your popup key your threshold and obviously the fee. The catch, the only catch here is that fee changes with demand and it can change really drastically because it follows the exponential formula, let's say. And another thing, if you overpay the fee, it won't be uh sent to you back. Um, that's that's pretty much it.

Uh, so sounds pretty easy. And now let's quickly cover a few design decision that, uh, might be interesting. First of all, where to actually store the C threshold um on the consensus layer. So there are like two possibilities we were considering. First is validator because validator already has like a lot of information about validator itself.

I mean val structure uh for example like with credentials um effective ballots and so on. So it sounds like pretty natural to put the threshold there. But we um decided to go another way and like it's actually like way better. It's to add another mapping to the beacon state that will actually hold the threshold. And uh first well actually starting from the glam from this gloss the validator structure is actually considered immutable.

So it was like a good call to not change it there. And in general it I think it sounds nice to keep changing uh something that a lot of system depends on. The second is timing um partial unlike partial withdrawals for example they sit in both cues. First is on the execution layer on its um predeploy contract and the second on the consensus layer. slip threshold requests are different because as I said once they cross the execution layer they applied immediately on the consensus layer and I will tell you why it's safe like in a minute you remember that uh there is a rule that you can set your threshold only at or just above the current balance and the reason for this is that if you could set it lower uh the moment you set it the system could automatically swep the difference and like create the withdrawal and in this case you will just I don't know sneak around the normal system rules and make an instant payout of like whatever the difference is by uh forcing this rule we basically uh prevent the situation and we make it like make it possible to apply the se threshold like immediately because setting the SI threshold doesn't move money by itself and if you actually want to go lower, you has have to do the standard normal partial withdrawal to lower your balance and only then you set the threshold at the value you you chose.

All right, let's bring it home. Um, EP8148 fixes comp fixes rewards liquidity for compounding validators. Rewards are no more stuck on the consensus layer. It's just a one opt-in knob that fixes both situation for solo sters and four pools. It's like completely optin.

If you do nothing, nothing changes for you. And if you think bigger, it it it basically uh helps to eliminate the main reason why people keep avoid using compounding. And more compounding for your data on the network means smaller set and healthier Ethereum overall. So one small knob, one quality of life fix for stakers is actually a win for the whole network. And finally I want to share like just a few thing uh from me that I learned building this.

Uh first if you spot a thing and affirm that you can actually um like improve or make better you can actually do that. You can just write it up you can share it with people people listen and you can actually have it implemented. The second is that consensus specs are really hard. Well, there's just if if like multiple different function defined in different places uh but in the end they all combined and all like large like executable ones and it's really nice. I wasn't like impressed by this.

And finally uh you can build your your AIP using like the already established patterns already like implemented at really useful EAP over there and there are a lot of them. you can just combine them and build your own one. Well, that's that's my talk. Um, thank you everyone. Here you can find the links to the AP itself, the discussion of this AP on the magicians and also to the slides.

Thank you.