Restaking Protocols: Exposing the Achilles' Heels

Transcript

[Music] Oh. Hey. Hey. [Music] Hello. Hello everybody. My name is Ray.

I'm a senior researcher from Stora and I'm going to talk today about restaking in general. We're going to break down the major design elements that we've seen and then we're going to talk about potential weak point in each design element as we go along. Um, so who who am I? Uh, I've been a security researcher for the last 11 years doing vulnerability research in embedded system web 2 and obviously web 3. I've been working for a lot of companies that uh requested to be anonymous. Um, yeah, if that seems mysterious and it means you're listening closer to the presentation, that's good.

If it means that you want to look me up, I don't have social media by design, so uh, you can catch up with me during the event. Uh, incredible. Let's start. So what is uh what is restaking? Okay. Um reststaking is basically the act of allowing a user to secure more than one service uh during uh in Ethereum in general. So you have the beacon which is how we secure the consensus layer and that all that assets are locked away in one place. But you might want to use those assets to also secure other AVS, other networks, other uh applications that require multiple validators to to make sure that they're correct.

So what is a staker? Uh the staker in this position is anybody who have any assets that they want to secure uh the uh the protocols with. If for example, you want to have a game, let's say on Poly Market uh where you want to bet on the result of a soccer game, you can trust one oracle to tell you what was the result. But that's a bit too centralized for us. So what we can do also is we can have multiple different independent validators and if one of them misbehaves, if one of them tries to say the wrong result because they want to game the system, then they will be punished. The issue with that is there's a relation between how much stake is in a specific application versus the possible profit. So in order to beat this consensus mechanism, if you can

profit more than about 30% of the value of the total stake pool, then you can just beat the staking. One of the reason why Ethereum is so secure is because Beacon has enough that 30% of it is pretty hard for most of us to achieve. So in a regular staking algorithm, you have the staker, which we we know it's the same as any other staker, and we have the stake manager. So this is an entity that abstracts away a lot of the different possible stakers that you can have. You can have direct native staking on the beacon, but you can also have some liquid staking, some other markets that you want to use those assets to secure other parts of DeFi in general.

So the stake manager conglomerates that keeps a ledger of all your various other stakes and the various location where they're at and it combines them into a single number and single value that then you can later use. The delegation manager is the entity that the staker manager communicates with. Right? So if you can imagine the staker manager uh keeps all your various uh wallets, all your various validator accounts uh and it connects them into a single abstract pool. You still want to delegate it to somebody, right? You want to have somebody who will manage that fund for you. This is a way to optimize your stake even further to claim more rewards and to use uh your stake in a more efficient manner. So where the stake

manager uh abstracts away all your various pots, the delegation manager is how you sign up to an operator. So as a user you connect to the stake manager all your various funds and then the the uh another thing you have to do is connect to an operator sign up sign up for somebody who will manage your funds. After you do this you're done. The operator oops we went too far. The operator is sort of like your broker with in regular stocks right? So the operator manages all your funds and puts it in builds a portfolio for you. And this is transparent. you can see which which portfolio which asses the operator signs up for and as in real life where

you should trust your broker in DeFi you should trust your operator. So don't sign up to any random operator that has no track record right sign up for somebody who you trust who you think they will make money for you. Obviously, if there's some uh some operator who does high risk, right, uh uh potential AVS that have potential for high slashing, but also high rewards, it is up to you to decide whether or not that's something you want to sign up to. The operator talks with the AVS through the allocation manager. So, if we go back to the analogy that we had before, which is the stock market, we can think of the operator as a broker and the allocation manager as the stock market.

The operator has the ability to allocate a percentage of the funds that they that they manage in their portfolio into different AVS's autonomous verified services. This is how remember when we gave the example of the soccer field. This will be one application right you can have other uh other AVS other application uh and they sign up to this network they sign up to this for sticking because they have the opportunity to increase their potential stake pool. That is their incentive. Remember how we said that in order to attack this consensus mechanism, the potential gain has to be more than 30% of the total stake. By having a connected system, by incentivizing users to have multiple restakes, you increase the average uh pool for each one of

those ads. No longer do you have to decide, do I put all my money in Ethereum, for example, to claim some reward. Uh you you can now split it between multiple different services. And if you're a service provider, if you're building an AVS and the rewards that you can offer might not be as competitive as other services, there's still some incentives for people to diversify and still have a portion of their stake into your service. Overall, increasing the the um the balance between all of them and the overall security. So that's the allocation manager. The main role for that is to make sure that each operator can allocate a percentage of their funds. And if the worst thing happens, if an AVS decides that that specific operator misbehaved, for example, they

missed a voting period for some AVS's or perhaps they voted something that is wrong trying to game the system, they will be slashed. A portion of the money that is allocated through that will be reduced. So that's the that's what the allocation manager does. Now when a slashing event happens, the allocation manager can't communicate directly with the operator. Imagine a scenario where the bank tells you you lost half your funds but you have to tell other people that you lost half the funds right you don't you're just not going to say that right you don't have to broadcast it so for that regard allocation manager doesn't communicate directly with the operator if there's a slashing event they communicate with the delegation manager the delegation manager I remind you is the hub that connects the users and the

operators this is where you can connect with your abstract funds that were in the stake manager into a specific broker So that is the entry point where the allocation manager communicates with. So far so good. Everything looks incredible. So you you have your stake manager, you put your money there. Uh you want to withdraw. Obviously, you're going to have to talk with the delegation manager because a portion of it might have been slashed. And it's the delegation manager responsibility to make sure that if there was a slashing event, you will be slashed. But if you have funds in the system after the slashing event, you shouldn't be slashed retroactively, right? You take the risk only from the point where your money is in the system. So if you have a situation where a slashing event occurred and your money entered the

system afterwards, you should not be slashed. You should still be able to withdraw your funds. So looks good, right? No problem. The system just works. Obviously, it might seem like it's very complicated, right? I talked about a lot of different components. I talked about the various part of the system. And hopefully I managed to instill some ideas of why they have to be separated, why you have to have those different systems because you're connecting different stakes and you want to connect them to different uh services. So that's why you have to have those layers of abstractions and then you can secure each module uh separately but also you have to care about how they interface with with each other. So let's talk about uh the issues.

So the first Achilles heel out of two that we're going to talk about is the allocation manager. Right? So this is the entity I'll remind you that was supposed to be in charge of how we how each operator allocates funds a percentage of the total money that they that they hold into the various services that they want to do the portfolio if we took the the stock analogy. So one of one of the potential issues what happens if the operator can over represent in this example I gave strict numbers it usually is done with percentages you usually allocate 50% of your funds 10% of your funds not strict one ETH half ETH there's a lot of good reason why you want to allocate percentages right imagine in the stock market right you

buy a specific stock you don't want to re-update this right you have your position in that stock and that position can grow or reduced. So percentages make a lot of sense, but it's easier to see whole numbers. So imagine a situation where an operator can somehow allocate more than 100% of their total funds, right? In this case, 150%. The issue with that is if there was a slashing event that were to occur, it won't be possible for all those three services to be slashed at the same time. Obviously, you can't slash 150% from 100% position. But they don't know that when they give out the rewards, right? they give the rewards based on what they see allocated to them. So the game in restaking in general is whether or not you can shift

the balance between possible risk and possible rewards. So all the examples that I'm going to show here are based on critical findings that we saw in major restaking protocols. This is not to say they are incredible protocols. They're incredible protocols but it's worth keeping in mind that this is a complicated system. So this is part one of the issues that could happen. The second potential issue, the second Achilles heel if you will is in the delegation manager, right? So the delegation manager handles a lot of things. It connects between operators and user. It maintains the slashing history to make sure that if you had any additional funds enter or left the system, you will always be slashed based

on if you are present during a slashing event. But just like the regular consensus, just like the regular um beacon chain where there's some delay because you you don't want to run away with the money, imagine a situation where an operator knows or a user knows that there's about to be a slashing event and they would shift the funds, delegate to a different operator, withdraw them immediately, right? In this case, they don't really hold any of the risk, but they did get reward over the period uh as if that risk really happened. So obviously that's no good, right? So we have to do artificial uh delay some sort of mechanism to make sure that users can't run away with the money that they have to hold the risk of their reporting that they're doing. So

that's it, right? Two two legs. We have eight minutes. Maybe I talk too fast. I was nervous. No, don't don't trust anybody, right? There's a third leg. Um, so the stake manager obviously, right? Imagine this. You as a stake manager have to keep an accurate ledger. Obviously, if for example on the beacon, but you can imagine other positions where you have stake, if you are slashed in one of those, you no longer represent the correct amount of funds. So the potential risk that you take is no longer accurate to maintain this ledger is extremely complicated, especially if you support multiple strategies, multiple markets, multiple positions that could go up and down in price. And it's the stake manager job to make sure

you're accurate. It's the stake manager main goal to make sure that the value that it represents to the delegation manager is the correct value. Incredible. So yeah, we're done, right? No more issues, no more problems. This is a bit of foreshadowing, right? As I said previously, don't trust anybody. Verify, check. Let's check the next slide. Boom. Another leg. Uh, incredible. So, Beacon is a complicated piece of code. I don't know if you had the privilege to look at it. You can.

There's a lot of open source implementations that you can just look. The one specifically that I'm referring to was about half a million lines of code. Uh it is incredible, incredibly complicated, an amazing piece of code. We have an anecdote uh when Perra was was being finalized, right? So not yet the spec for it wasn't yet fully completed. So we didn't yet know exactly what's going to happen in the Pectra upgrade. It just so happens that I was lucky enough to rumage in the code and see what happens. And this is a true story that was caught well in advance and it was fixed and no no funds were at risk and all the parties did an amazing job fixing it. But the issue was that during the upgrade process, somebody decided that when you upgrade to PCRA to

the new version, um maybe the validators that are not yet activated, the validators have less than 32 ETH. So they're they don't participate in the in the consensus mechanism, but they can still hold funds there. So during the upgrade, somebody decided that we'll move them to a different queue to a pending queue. What's the harm, right? Yeah, it will just be in that other queue. And once they become active, it'll return them back to the regular system. The issue is that this was not documented. This was nowhere in the then uh specification for PCRA. Uh and the issue with that is it's it gives it gives user a way to hide their money.

Remember how we said it's a game of risk versus reward. Imagine a scenario where I have 31 ETH in one validator or heck, maybe I have 62 ETH in two different validators that are not yet activated. I I participate in a very risky restaking position. And what I do is before before the upgrade or actually during the upgrade, I do something malicious, right? I try to attack. Oh no, you'll be slashed. You're going to lose a lot of money. But during the upgrade, all their funds are moved to a new queue that is not documented. So for the stake manager, it appears as if all your funds are magically slashed. So you can't slash half of or 100% of zero.

So after the upgrade, you can invest an additional ETH into any any one of those validators and make them active again and revive them, but the slash has already occurred. It would look to the protocol as if you just gained a huge reward. This is a way to bypass slashing completely. So you can say yeah you can only do it once but you can do it once for any amount of money that you want because you can have specify any numbers of validators and obviously that's not good. We don't want to encourage that. Uh so the beacon itself is a moving target. The idea behind this presentation is not to scare you away if you want to develop a risk-taking protocol or interface with a staking protocol. The core idea behind this

presentation is to show some of the complication that can arise and if you want to integrate with our staking protocol you have all the tools you need to ask the correct question right if you're an AVS you might want to ask them how they interface with operators right if if you're in a Solana or EVM or doesn't matter which chain this architecture is something that we kind of narrow down to obviously there can be something that is a bit different but the core concepts are there you might call it a network, a service, an AVS, an NCN, right? There might have different name, but it's the same core feature. So hopefully now you have some insights about the various components, some complications and some anecdotes about areas where they uh broke down.

Perfect conclusion. Uh there is no other leg. Uh well, we'll see once I go to the next slide. Um restaking is very smart. It makes the entire chain more efficient and we always strive to be a perfect market efficiency. It gives you the flexibility to secure more areas of the protocol. Whereas liquid staking, which you might think in your head, why not liquid staking, right? Everything you said, yeah, you can just do liquid staking, but liquid staking doesn't allow you to secure other services. In that regard, it might be a bit too broad. Restaking is specifically here to make sure that the entire ecosystem is more secure to bring more life to AVS's to make sure that we grow and we have

the best ecosystem that we can and it's complicated but it's not needlessly complicated. Hopefully I managed to give an insight in that regard but if not you can think of it and you can talk to me in the hall and maybe I can give you some insights as to why this is the simplest solution we have right now. Not needlessly being complicated, not trying to be overly smart, but the minimum requirements need in order to achieve the things that we need to achieve from this system. Thank you very much for being in my lecture. You can uh reach me on Telegram or you can reach Star Tour. We're doing a lot of audits and we're doing a lot of security regardless. Uh and you can uh meet me in the halls.

Obviously, no Twitter, uh no social media, but I'm in person here and I'll be here until Friday. Thank you very much and I hope you have a wonderful event. [Applause]