Economics of Compounding, Pro Operator and Resilience - Staking Nerd Talk - Episode 2

Transcript

Intro

[Music] Welcome everyone. My name is Remy. Um I'm happy to be joined by Yoro. Hello Yoro. How are you doing? I am doing great. Uh playing. Yeah. Welcome to our second episode for the sticking uh talking nerd. Uh uh yeah, nerd talk that way. Sorry. Yeah, the sticking nerd talk. Yeah. Um I'm already confused about what we're doing here today. But as this is my normal way of going through the day.

I'm happy that uh we managed to find enough topic for the second episode. Um and we have a few different topics to talk about today. Uh the first one I wanted to talk about was the economic of compounding validators which is based on a nice uh post by Jim McDonald from attestant. He decided to check out the rewards over time for if you are to go compounding or not and if you are to manage the rewards. Um but let's go back to what a compounding validator uh is. Uh so the idea for compounding is that the rewards

Economics of Compounding

that you get just keep on being on your validator balance without having to be withdrawal every once in a while. So the E if stays on balance and eventually it gets uh to be used as uh part of the formula to um compute the rewards that you get and the chances that you get for being part of a sync committee or um being selected for block proposal. You also get more reward as you get more effective balance. But the effective balance is only um computed as you get to a higher integer value on your

validator's balance. with the um case of the uh hysterosis zone uh where you need to be at least point 25 if above that integer value for the effective balance to count right so combining rewards um are they worth it are they interesting I guess it depends on how much you want to stake If you have a lot more than 32 if it makes a lot of sense to to choose a compounding uh validator.

Mhm. And it it also depends on like how you want to use that E, right? So people were used to the regular withdrawals. So, if you want to use this ETH as part of some kind of DeFi protocol, maybe you want to send it away and invest it in in something else. But if you are a true staker believer, if you believe in the staking protocol on Ethereum, it makes a lot of sense to simply use a compounding validator and the consensus rewards that you get will just um end up on your balance and eventually you'll get more rewards because of it.

What's your take on on this uh your um very simply uh do it if the 0.1% additional APY or of course right that's that's just for compounding but also um being able to earn the APY on more ETH is compelling to you. So if you have 32 but you have another 10 and you like yeah I don't care that the APY is a little higher. I just want to actually be able to earn on those 10. um by all means go for it, right? What you're giving up is liquidity. So if

you're the kind of guy who's like, "Yeah, I actually have a number of validators running and every nine days that sweeps some ETH into my account, which I then, you know, sell on a whatever monthly basis and use to deframe my costs." Or if you're if you're really doing well, living completely off of, right? Or at least help with the bills in some way. If that's what you're doing, then just keep doing that. Um, because you're not interested in compounding anyway. You're looking at liquidity. So, you know, the that's the trade-off. I I don't think there's a right or wrong answer here, or rather they're both right answers. Just depends on what's right for somebody's

financial situation. in uh Jim's post uh he did some comparation with um different kind of um managed or unmanaged or like uh compounding or not compounding validator and over a long period of time it makes a lot of sense to um use a compounding validator right yeah again if you want that ability to earn on the additional and my answer doesn't change right It makes sense if what you're after is to say, I want to earn as much as possible from the ETH and I want to just have it sit there as much as possible. Have it sit there. Um,

then surely you want, you know, say you start with a 32 ETH validator, you want that to be 33, 34, 35 and so on and so on and so on and earn on that. But if your theory in life is no, no, no, I have all the ETH I want. That's enough exposure. Thank you. I just want the liquidity every nine days and then sell it for you for whatever your local um fiat is, right? And pay bills, then don't do anything. Don't compound. Good point. And I think you also have to take into account that even if you're using a compounding validator, you will still get execution rewards. So no matter what, yes, uh you will get

rewards that will be liquid and that will be accessible in in one of your wallets. Very true. Yes. And um that's a good point. And Jim's numbers assume that these will also be put back into the validator in some kind of managed way, right? So in a managed manual way. Yeah. that every so often you take these rewards and put them back on. I believe in his post he mentioned that um if you want to do this properly, you you might want to wait until you have like one E or like 1.25 E until you top up your validator.

Exactly. Or shall we say enough to get to that threshold, right? So say your validator by itself is already at 75. Then once you have 0.5 accumulated through your E rewards or a little more in it goes and you get to that next threshold. So I think one of the take of that article was that if you want to really go all in on ETH and you want to do it on a long time over a 10-year period, you might get up to five or up to was it 7% more rewards overall. um if you were to use a compounding validator compared to just um a regular validator. I did

not see that. No, I saw so in percentage points what I saw from Tim was 0.1% higher APY max. I mean he he did um a table at the end of the the post if you want to go check again and like over 10 years uh since it's compounding um you get you get slightly more rewards. Okay. Uh I can check again. Yeah. Yeah. But but yeah, so that's that's only if you want to go all in and and probably if your strategy is is to stay in Eve, which which is hard to which is hard to picture for any reasonable u person. Um like like staying all in for this long,

but maybe maybe that's um that's something people might be interested in, right? For sure. Um this can also be used um for some corner cases. So say you have a number of validators and for whatever reason set these up with different withdrawal addresses and you're no longer happy with that setup and you want it all on one withdrawal address. Typically you'd have to exit and redeposit. This gives you a chance to not do that. take any validator you own where you control the withdrawal address which is the address you want from now on. Maybe you got a new hardware wallet or whatever, right? Um

and then you can consolidate all the others in there and um they will use because the consolidation is under the hood and exit and deposit just without going through your withdrawal wallet first. um all of the ETH is now on the on the on the target vat and that can have some tax implication as well. So if you're Yes, potentially because you're not actually receiving the heat. Yeah, it stays in there, you know. So you withdraw it, it might be classed and ask your tax accountant because this gets complex, but it might be classified as you now have it and now you have to pay

whatever difference in value it had from when you originally bought it. Whereas if it stays in the if it stays staked, then you know you only pay once you take it out of state again. But that depends extremely highly on where you live and how your taxes work. So talk to your accountant about that. And this is true for consolidation, but it's also true for compounding uh validator, right? So, as you get regular withdrawals, maybe there's tax implications for you. But if the reward stays on the validator's balance, maybe it's uh preferable for you in terms of taxes. Yeah, this really depends. Um, and it might make actually

your tax accounting more difficult in some jurisdictions. So, some jurisdictions they say, well, once it's in your validator balance, you could grab it at any time. Yeah. So, your rewards are taxable the moment you receive them. Um, they don't really mean that. They don't mean every 6.4 minutes. Okay. Um, I think if you do something reasonable, again, I'm not an accountant. Talk to your tax accountant. Yada. Exactly. But typically, if you do something reasonable like um we're recording it once a week, um, your tax authorities are typically happy with that, right? But again, it depends. Some jurisdictions, that's exactly how it works. you have to tax it as you receive

it. Other jurisdictions say, "Hey, uh, we only care once you go back into whatever the local currency is. Once you sell it, then we want our taxes." It all depends. Taxes are already a nightmare. I didn't want this to be um to be a taxing nerd talk, but uh, let's not talk too much about that. All right. Um, I think that's pretty much all I had. uh with this topic, maybe we could uh talk about another one. Um we we had this Do you want to also maybe link people to your guide as to how to actually do these consolidations? Well, well um we will put a few links at the at the bottom of

the video in the descriptions if um if you guys want to learn more about this, including the um the link to Jim's article for sure. Yeah. Uh we had a few different topics suggested uh by uh different users. One of uh them was the path to being a professional operator. Um uh you you are a professional operator, Yoric. Um tell us more about this. Oh god. Um I'm wondering whether I actually want to um because that's that's a tall lift, right? We're not going to go into how do I build a company on sticking top, but maybe to dip your toe in, if you're a solo operator now, how could I be an

Pro Operator

operator for various sticking protocols? That's I would say semi-pro, that's definitely where it starts, right? Um, in a nutshell, you take a look at the protocols you want to be um working with or for. We had one on recently, Aztec, right? There's a couple others. Um I think uh Rocket of course exists. The Lido CSM. Yeah, the Lido CSM. I think node set does something with stake wise. Yep.

Right. Um and basically you look at their um con SSV is another one where you can be a node operator. uh you look for from a technical perspective you look at their um description of how to spin up a node and that's typically standalone and then you think about well if I just run their component which is often just an outlet client or something of that nature can I point it to my existing consensus layer client and execution layer client that I'm already running for um you know for my solo and the answer is of course you can uh a Couple things you need to keep in mind. One is that

one consensus layer client only ever has one set of me relays. So you'll want to find that um set, you know, that kind of vin diagram where all of the people you're working with can agree on whatever it is you are actually running. You know, you can't be if if they all have different sets, you need to find that middle of the vin diagram where and that could be another mess. That could be another mess. Exactly. Um, and other than that from a technical perspective, you know, how do I actually point them to my CL and CL? Well, we're not going to get into that on this talk.

That gets really far too deep. But in a nutshell, you know, you could do it on local host. You can do it over LAN. Um, if you're in Docker, you can do it with bridge networks, you know, so that they all just talk inside a network that's not even exposed to the host. There's a number of ways of doing that. I highly recommend to try and fully test net first, right? Don't go into this mainet if you don't understand how works. You're going to learn more about networking than you probably currently know. If you're already an expert, then more power to you. But for a lot of operators, they just set it up, they follow a guide, they use a tool, whatever. They don't really understand

how the networking works under the hood. You'll have to learn at least enough to know, okay, where are these um API ports on the consensus and execution layer? How do I make them accessible? How do I secure them if I need to do that with a firewall? And how do I have then some other service of mine connect to them and consume that API? In some case I believe uh yeah in some case I believe just being a pro operator is running a a key for someone else and in in that case all you have to do is import the key and run it yourself right.

When you say import run a key for someone else you mean like which which ah for another key. Yeah, just for another for another entity or like for someone else like like if you have a friend who doesn't have a node and if you have a friend and you want to run their key, sure. Yeah, they in that case it's very simple. Um if you're not engaging with any of this LST stuff, right? Um you would just import the key, set a separate fee recipient for that, of course, right? Which needs some tweaking for some of the clients. Yeah, it needs some tweaking to some of the clients. Yeah, in in the systemd world like the SAS is etc. Um I think for the

most part you have to manually edit a JSON file. Um you might know that better whether tools like your E wizard expose that. Yeah, I believe there's for some you need to for somebody to validate their client you you just do a manual file edit. Yeah. Yeah, you need to create a JSON file manually. Um, with the EORE project that I maintain, it's just ED key set recipient. There's a a wrapper for key manager API that and just talks to the key manager API of the Albert client and sets it that way, right? I believe ultimately want to think about JSON files. Yeah, ultimately being like a pro is is being able to provide like a good service to

potentially someone else. And and part of being able to provide a good service is is just being able to run nodes in a way that um are always online and then uh have good efficiency in terms of like being able to to stick accordingly to the protocol, right? I I did a talk on this by the way. um when we can find a link um last year during one of the lighter shindics and the thing I said then I think I think I still believe now and that is the main difference between someone who does this for a living and somebody who does it for themselves is monitoring and that's really what it

is always go wrong it's perfectly normal but the point is you want to know um even better is if you know before they go so wrong that you're down which is part of like giving a good quality to your client right in in the end. Absolutely. Yeah. So monitoring alerting is the thing right. So you'll you'll learn how to use Grafana, how to use its alerting mechanisms which are built into Grafana. It can alert you through a whole bunch of things. Uh Telegram, Discord, Slack, email, um SMS, even all kinds of things, right? So um that's a whole skill set in and of itself to it.

Alerts so that you're not getting spammed with nonsense. Um the very lowlevel start way to start is to start with beacon chain alerting. Um yep it at least will let you know you know if you use their stat collector let you know if you're running low on disk space. That's helpful. Um and it will let you know if you're actually down. It won't maybe alert you ahead of time if something doesn't look quite right, but it will alert you when things have gone wrong. So that's that's good. Yeah.

Awesome. That's um that's all I had about this. Other than that and like when you're looking at things like SSV, you know, you're like, well, how do I attract stake there? Well, the answer typically is you need to become a verified operator. Um Lo CSM is starting something like this as well. So there you would look at each individual um project and see what they require to verify someone. It might be that you know um your stuff is resilient um stays up that you're verified as a person. Sometimes they want you as a business, a registered business before they will verify you. Do you know if

they um if they're doing KYC as well? Uh some are. Yeah. Um I think Lido says I haven't looked into this very deeply. They have they have a blog post like last week I think they're looking at um allowing anonymous running still but also connecting it to social media accounts and um activity on their forums etc. I see. Um I guess we're good to go for the next topic, which is uh the advanced strategies to um prevent validators from uh finalizing a super majority bugs and

Supermajority Bug and Resilience

and improve potentially the resilience of of everything. Um I think the main way to get there is to run minority client. That's that's my uh my take there. And and we already have like good clients. Um all of the consensus and the most of the execution clients are pretty good right now. Um running a manity one is is very easy. Migrating from one client to the other one is is like the way to go. That's the KISS keep it simple uh strategy there. Uh there's a bunch of different ones. Um if if people want to talk about the advanced one um and I'm not sure you have a few talk about advanced strategies, right? So um

there is a website let me just see whether I can find this is it supermajority.info the one uh that gives you the stats for all the usage for the client has the yeah that's the one that I'm sorry I should have been coming better prepared. Uh I believe there's client diversity. Yeah I don't think I want that one. Um okay if you go to supermajority.info and you click on risk simulator that's where the um advanced strategies come in right so there you can say which clients am I running and which of those are faulty and am I using an attestation consensus

threshold so what on earth is an attestation consensus threshold imagine for a moment um and we'll get into in a second of how this actually works. But imagine for a moment that you're not running one client, you're running three, four, five, or six, a whole bunch of them. And you have a consensus threshold. So they all need to agree or uh say you're running five, four or five need to agree before um you say, you know, I am going to sign this. So what is this for? Why? That that's really a rather advanced strategy, right? Why would this be desirable? What does it do for a solo

staker and what would need to happen networkwide for this to actually be useful? So what we're projecting against here is the thing that happened on Oleski on Oleski three clients never mind G and BU had the same bug, the same consensus impacting bug. So while say you're running BU that's a minority client wonderful um unfortunately together with G and never mind that's a super majority so at some point you know we actually had super majority clients one client one bug and one client could have the chain so that's no longer the case we should all pat ourselves on the back so now we have

a new fear unlocked wonderful and the new fear is well what happens if two or three clients or four clients have the same bug and together they get over this threshold. What are the odds though? Like what are the odds that like two or three clients have the same bug minimal? Well, there's clearly not zero, right? So, this is the thing with odds and probabilities. The odds are clearly not zero. Yeah, as we saw in LHQ, sure it's a test net. It did exactly what it was supposed to do, which is find this kind of stuff before it hits mainet.

The odds are still not zero. If you take a small probability and you have the odd of that happening every day and it's independent of the previous day and you go over decades, then at some point it becomes an almost certainty that you hit this thing, right? You know that. So that is not on in any given day. You know, the odd is still really small in a given day, but over time eventually, you know, if these are independent odds, you're just going to it's almost guaranteed that we're eventually going to hit that.

Um, so we can all pray and cross fingers that it doesn't happen. That's probably good enough for years at least, but probably good enough is not very confidence inducing. So what do we do about it? Um, so imagine now that and this is something that's near and dear to my own heart. We're we're testing this right now and I I want to encourage other large operators to be um serious about this. Imagine now that 40% of stadium I'm using 40% only. So we have a nice safe buffer above the one/3 threshold. Y but roughly 30 40% of chip stake are running a circuit breaker setup. This

attestion attestation consensus threshold. So what I'm imagining here is they're running all six consensus layer clients, all five execution layer clients, and they're saying five of six of these consensus layer clients need to agree for me to sign anything. That means that now any four can be faulty in a correlated way, have the same bug, and we're still good at this point. Have we reduced the likelihood of this happening to zero? No, we have not.

Obviously, you know, if I have the same bug or six have the same bug, risk screwed. However, we've truly mitigated it. You know, like the the likelihood, the probability of that happen has happening has become even smaller. Um, and I still have some resilience. Like if I say five or six, if I'm doing maintenance on one of my backend servers, no problem. still testing, right? And what kind of tool um can can make this possible? There are currently only two tools that can do this. Um that's why I'm saying it would be good to test it on test net and then maybe see whether other um client teams want to get on board. The two tools that can do

this right now are ver so valid. Client that works with web 3 signer in the back. So if somebody has a web three signup setup already, which is incredibly common with bro operators, they could slot in Vero and um set up this consensus threshold, right? As the client and Vero is designed to work against a multiclient back end. It was created exactly for this problem. The other one is vouch with Durk, but if you're not already running voucher, this is a large lift. I wouldn't recommend, you know, as a pro to throw out web three signer with a bath water as it were. Um to say this is a risk, you know, I I don't like the risk. We're

going to mitigate the risk and we're going to completely get rid of our signing infrastructure. No, no, no, no, no, no. Um in the future, if this works a lot on test net and and people get confident with it, I'd hope that other clients, you know, Lighthouse, Prism, Nimbus, Teo, Grinian, Loadar, etc. um offer this concessives threshold option in their validator client. That'd be very nice. Yeah. Yes. And that way your an operator could say if I'm running Prism now, I continue to run Prism. I'm making two changes. One, I'm adding a whole bunch of additional backend servers with a variety of different clients on it. And two, I'm

configuring Prism for a threshold. If 40% of stake does this then what happens in normal state nothing at all everybody is attesting everybody is just as well as it was before what happens if say you know three or four clients have a correlated bug like happened to us inki 40% will stop a testing entirely um which means we did not finalize the wrong chain we did not um justify the blockchain either. That's which would be ideal for the whole network as well which is ideal. Well, first let's be selfish. I always like to appeal to

people's own profit, right? Not their beta. Yeah. Um which means my uh stake is now not stranded. If we're finalizing the wrong um chain, this is what happened on Oleski. Just to do a recap because not everybody might remember this. we could not come back to the right chain without getting slashed and losing all ETH. Um there was a way to rescue Hleshki by turning off slashers. Actually, we can't do that on mainet. So on mainet, what would happen is either you go back to the right chain and you get yourself slashed or um you stay on the wrong chain and get inactivity

Outro

leaked down until the chain finalizes again. There go anywhere between four and 12 E per validator, maybe more depending on how much stake pat the wrong, you know, the wrong consensus here. And then before you say anybody says, dude, that's never going to happen. Um, Circle and Tether will um just make the buck canonical. You're talking about Ethereum civil war. We do not want to get there. All of these outcomes are extremely bad. um it would require some kind of social consensus and like and we don't have the tech to do anything about it, you know, like if you're saying to all core devs um make

this buck canonical, they've already said in the past we're not going to do that. Some are saying yeah that would be the right thing and then the other half is saying absolutely freaking not. Never. So that's what I'm saying. Ethereum civil war, right? Um let's avoid that. Yes. So we already avoided it by um going getting off supermajority clients. Now we have a smaller probability of the same thing happening again because now you need a correlated bug. Let's make that even smaller still. Um the reality is circuit breaker designs nobody ever wants to run them even in trai until they're needed. And then the guys who didn't want to run

them are the ones who are shouting the loudest why there's no circuit breaker. So maybe I don't know maybe I'm I'm you know a naive person and think we can do better in Ethereum than trap file. For sure. I I believe we can do better. And with many of these questions it often boils down to like what kind of risk are you willing to assume and what's your risk management strategy? Um correct. We're not going to get it to zero, right? We're not going to get this risk to zero. We can't. But we can manage it. We can reduce it further than it is now.

I was honestly I was feeling very chill about it up until the Heski incident. Then I was thinking h okay this isn't as unlikely. The probability is not as low to zero as I thought it was. um it was caught in test net so everything worked the way it's supposed to didn't happen on mainet but there's a part of me now that says you know this isn't as close to zero as I'd like it to be yeah I believe many people were shaken by the incident on hleski some more than others and a couple like the the sky is falling you know and I think they calmed down a little when when the

pector update went through Okay. You know, certainly the sky wasn't falling, but awesome. I believe that's that's all we had to say about this topic as well. And that will conclude our episode for today. Thanks, uh, Yoro. Um, if you guys have any um if you guys have any topics you you'd like to discuss, uh, we're very open to any suggestion either through the comments of on this video or through Discord or Reddit. if you want to reach us out, um we're happy to uh take your input on like what we should be talking next. Hopefully, um this can continue and we can have like a bunch of other uh topics to include here.

Absolutely. Thank you. Until next month. Until next time. See you guys.