Fixing delegated ETH staking with EIP-8205 - Dima Gusakov

Transcript

Okay. Now the screen told me that I can go. Cool. Hello. My name is Dima and today we're going to be talking about EIP-4844 5. But before we will do that, I need to tell you something. I need to tell you that Ethereum delegated staking has a major issue. Like a huge one. And this is not a brand new AI discovered thing that you might expect. Like Ethereum delegated staking has been with us for how many? Five, six years?

And maybe it's something brand new AI discovered. It is not. It is an issue that has been with Ethereum staking from day one of Beacon Chain. So from the very inception. Take a look at this post. The name speaks for itself. Deposit contract exploit. And you will be surprised that this message has been published in November 2019 and the exploit is still there. And probably you haven't heard of it because if you look at the numbers, this is not the most popular post so ever.

So let me explain the issue so that you can better understand what it is and how we propose to fix that. To understand the issue, we need to take a little overview over how the deposit is made to validator on Ethereum network. It all for sure starts with the so-called deposit action or the transaction to a deposit contract where your 32 ETH is transferred to a deposit contract so that it can land on your validator.

But since execution layer and consensus layer are pretty loosely connected, at least from the execution layer side. There are not that many checks on the execution layer, and most of the checks and processing happens on the consensus layer. The check that is particularly interesting for us in this case is a check whether there is a validator with a given public key already on the consensus layer. If it is, we top up the existing validator. So, all of the deposit funds will be added to the balance of the existing validator. If we do not have a validator, then in this case we will create a new validator, and what's

important, we will set withdrawal credentials. What's withdrawal credentials? Very simple. This is an Ethereum address where both validator rewards and the principal, should the validator be exited or slashed, will be transferred. Amazing. So, what we need to remember from this picture? Two things we need to remember to understand the issue. The first one is that validator withdrawal credentials are set once and cannot be changed later on. So, whether whenever the validator is already created, you cannot change withdrawal credentials. This is simply not allowed.

And the second thing is whenever we follow the path of topping up the validator, the Ethereum network actually ignores the information about withdrawal credentials in the deposit message because the validator already exists, and technically speaking, there is no point of checking this withdrawal credentials. Okay, that was an overview of the deposit and a quick background. Now, to the issue itself. To understand the issue, we need to take a look at Alice and Bob.

Alice provides ETH or delegates ETH, and Bob runs validators. And this is what we basically call delegated staking. So, what happens in between Alice and Bob in case of delegated staking? Well, there are two main things. The first one is Bob prepares the deposit data, the data that should be signed and propagated to the network to make a deposit to a validator, and within this deposit data Bob is using Alice's withdrawal credentials. But, you might ask why Bob is signing this data?

Because this data should be signed by the validator private key. Okay. And then, in a normal situation, Alice will take this deposit data, will prepare a deposit transaction, attach her ETH, propagate this transaction to a mempool, then this transaction will be mined, boom, we have a deposit to a validator, everything is great. But, this is assuming that Bob is not a malicious actor. If Bob is a malicious actor, then what he does is he secretly prepares a second deposit data, a second deposit message, where instead of using Alice's withdrawal credentials, he's using his own withdrawal credentials.

And then, whenever he notices that there is a transaction in the mempool by Alice with the with the original with the expected deposit message, he front-runs the transaction. Hence, his transaction is now mined first, hence, he win the race where his transaction was considered as a validator creation transaction, and Alice's transaction was considered as a top-up, and as you remember, on a top-up we are not checking withdrawal credentials. So, what Bob just did, Bob had just stolen Alice's ETH.

Oh my god. Now, we need to do a bit of a verification. Is it really an issue because I see from you guys that you might have questions, and I've written out a few so that we can save a little of time. First of all, a very obvious question. Why Alice would not just use private mempool? Like it's simple. You use private mempool, your transaction is never disclosed before it's added to the block. Super cool. You cannot be front-run. Well, in this case, Bob can not wait. He can skip waiting for transaction and front-running the exact transaction. He can just assume approximately the time when Alice will propagate the

transaction and make a one ETH deposit beforehand, before Alice even tries to propagate transaction. And if Alice would not make an additional check that by the time she propagates the transaction with her deposit, the validator is not yet created and there are no messages in the queue to create the validator, she will lose funds. Okay, let's assume Alice is an advanced actor. And before propagating a message, she checks whether there is a malicious transaction already mined.

In this case, yes, Bob will not be able to steal Alice's funds. But he would also not risk his own ETH because by depositing 31 ETH more, he will be able to recover the full amount and the economical risk for Bob in this case is basically negligible. So it doesn't matter which path we follow, Alice is always vulnerable. Alice is vulnerable by default. So if the problem is that bad, how does Ethereum delegated staking even exist? Because just for your reference, almost 70% of ETH staked is staked via delegated staking.

There are two main ways how protocols are currently protecting from this terrible vulnerability. And they can be This These These are two high-level things. Um which doesn't mean that all of the protocols have like just one of these two implementations. These are more of a groups. So, let's take a look at the first one, which is one ETH pre-deposit. One ETH or more one Why one Why Why Why one ETH, I'm sorry, is because if you make a deposit to a validator less than one ETH, it will not appear on uh the beacon chain. It would not be processed by beacon chain. So, the minimal size of the deposit is one ETH.

And in this case, the delegator asks validator runner to have his own capital at stake, precisely one ETH in most cases, so that delegate so that validator runner owns both validator private key and a fraction of a stake, which means that it makes no long no more sense for the validator runner to do any front run because he's depositing his own funds. And whenever the validate this one ETH deposit is processed, even though the validator is not activated yet because one ETH is not enough to activate a validator, the validator is already added to the registry. So, a further 31 ETH deposit can be safely made, or if

we're talking about staking protocols, EIPs 4788 might be used to make a trustless proof here. But this approach comes with the downsides. The first and probably the main downside is that in this approach, you are facing double entry queue. Cuz you need to wait first for your one ETH deposit to pass through all of the queue, then your validator appears, and you can verify that the validator has appeared with correct withdrawal credentials, and then you make a remaining deposit, which should also pass the deposit queue.

And the thing is that the second deposit is actually the majority of the validator principle, which sits with absolutely no rewards while you're waiting for this pre-deposit to be processed. And there's also an issue with the trapped bond. If, for example, something goes wrong, then you need to find this additional 31 ETH as an operator to recover your funds. Let's talk about the second approach. Uh the second approach, the one that is mostly used by Lido core in a protocol called trenches, is a committee of off-chain guardians. There is no bond involved here.

Uh instead, there is a committee of off-chain signers that check whether the as of the current deposit root, there are no malicious transactions. And deposit root is a wonderful field that if unchanged, indicates that there were no new deposits processed. Super useful. So, as of So, the committee of signers signs the message saying that as of the current deposit root, there were no malicious transactions detected. And when we make a deposit, if the deposit root remains the same, we can confidently make deposit being sure that no one had inserted a transaction before us.

But this approach also comes with the problems. And the main one is off-chain trust. As you all know, most of the recent hacks are ba-bam off-chain. Yeah. So, we really don't want to have an off-chain trust or we want to have it in as fewer places as possible. And the second thing is tight coupling because if you rely on deposit root being unchanged, you need to have it unchanged unchanged from the moment the guardians have started checking at the state till the moment your deposit lands and your deposit transaction is mined. Which makes it pretty easy for anyone willing to, for example, prohibit Lido from

making deposits to just make a one ETH deposit to a random validator or maybe to your own validator. It doesn't matter. Like every 5 minutes. And that would effectively stop uh Lido or Trenches from being able to make any deposit because it will take more time for the Guardians to make a check, to gather quorum, and to propagate the transaction compared to your deposits. And if you're looking for a more detailed analysis, it's already boring enough, but a more boring version is available uh by scanning the QR code on the screen.

So, what we wanted to say by that? We want to say that there is an issue. And we are achieving the same results, the protocols, delegators are achieving the same results, the result they are protecting from this issue, but they are doing numerous efforts. And even though I was able to classify most of the protection schemes into two categories, it doesn't mean that these two are two standard implementations. No. Each and every protocol has its own bespoke implementation with its own caveats, with its own audits, with its own costs.

So, protocols and delegators are spending orders of magnitude more on uh fixing this issue compared to what they could have spent if there was a unique solution for that, a solution that fits them all. And the other problem is that imagine you are new protocol. You will have to either choose or adopt or develop a protection scheme from that because what I started my talk with is that deposit contract exploit has been with us from day one of Beacon Chain, and it is still here. So, our Beacon Chain and our method of delegated staking is vulner- vulner- vulnerable, and it remains the

same for over 5 years. So, what's the solution for that? Well, I guess you already guessed it. It's EIP-8205. Um and in my opinion, this is the way how we're going to fix it uh once and for all. So, let's dive into the idea. And take my word, it's going to be very fast. So, there are four main I'm not quite sure if it's really visible or not, but you can listen to me and you will get the idea. Step number one, we sign a commitment. Step number two, we propagate this commitment. Step number three, we verify the commitment.

And step number four, we make a safe deposit. The first two steps are done by validator owner. The second two steps are done by ETH holder or ETH per staking protocol or ETH delegator. Let's look a little bit deeper. So, how commitment look like looks like. Commitment is almost identical to a deposit message that we have right now. But unlike deposit message, there is no deposit amount. The commitment is only aimed to pair your validator public key with the with the withdrawal credentials. And this commitment is signed using a validator private key, for sure. Then, the signed

message is submitted to a system contract somewhat similar to what we have in EIP-7002. So, basically through a generalized message bus um between execution layer and consensus layer. And then this commitment is stored in the consensus layer state, but it's not stored there forever. There is a lifetime, so that we can be sure that because this propagating this message is basically free of charge other than you you are trying to submit a ton of them, uh there will be a lifetime for this message. And it's it's discussable how long it should live, but something like 3 month can be very good.

Okay, so this is the commitment. How this commitment is done enforced on the consensus layer? It all starts with the validator deposit. And in our case, the first validator deposit because EIP itself guarantees that there can be no situation where you have both the validator and the pre-commitment for the validator. So, we assume that this is a first deposit and the validator hasn't been created yet. And the first thing we check is whether this validator is pre-registered or not, whether there is whether the message with the pre-registration has been propagated to the network or not. If not, we simply continue in a way like we do right now. So, no changes. But if it

is a pre-commitment message, then we do this missing check that is currently missing. We are checking whether withdrawal credentials in the deposit message and in the pre-commitment are the same. And if they are the same, we create a validator. If they are not the same, we simply ignore the deposit and the funds that were that were sent to a deposit contract will remain temporarily locked there. Well, that's a bit of a shame, but there is now a confidence that if there is a pre-registration message that pairs a given public key to a given withdrawal credentials, only this

combination can be transformed into a validator and not not other unless until we have this pre-registration on the execution on the And the final thing, how protocols and delegators will use that? Well, very simple. First of all, node operator will make pre-registration and will propagate this message. Second, he will submit the deposit data or the signature for the deposit message. Then the staking protocol not being scared, but and not making like a custom whatever things they are doing right now. No, a protocol or a delegator will simply verify if there is a correct

pre-registration message on the consensus layer, and if it is, but either delegator or a protocol can make a secure deposit. A deposit that is 100% guaranteed to transform into correct validator with no exploit, with no risk. Okay, and that that's pretty much it. That's the core idea of EIP. It literally took me like less than 5 minutes to explain that. Now to again to questions that you might have and that I've already written down. First question, probably the hottest one. Should every protocol and every delegator make some upgrades with if this EIP gets implemented? And the

answer is no. Only the protocols that are using guardians or the Lido-like system, which is Lido and one product one another protocol, will have to upgrade because the guardians flow is now broken. The pre-deposit flow is not broken, and we have no idea what uh private companies called node operators are using, but they are likely using systems that rely on off-chain trust. So, again, no major changes for them. If we say that only Lido will have to upgrade, we can come to a conclusion that it's beneficial only for Lido, which is for sure not true. Why? Because

any other protocol that is currently using one ETH pre-deposits, for example, or whatever other trust system they are using will now have the opportunity to transition to this pre-registration system, which is simple, neat, does not does not have any disadvantages of the current systems that we described. So, this EIP is beneficial for any delegated staking. Staker. Oh, sorry. I was about to show the answer. Uh and the final thing, what's the cost of implementation and what's the cost for Ethereum?

Uh the cost is almost nothing. This is one of the simplest EIPs that I've ever saw uh when it comes to implementation. You just need a message bus, which is basically a copy-paste of a hundred not not hundred, but at least three message buses that we already have. And there are a few little changes to a consensus spec when it comes to very first validator deposit. And that that's pretty much it. And provided that the pre-registration messages will not live forever, that they will have lifetime, there is also no risk of state overflowing or whatever.

So, let's quickly summarize what are the benefits and what are the effects of EIP 8205. For Ethereum, it's fixing a long-standing critical vulnerability. It's making delegated staking safe by default and not with some shenanigans that every protocol have to do that. And what rhymes with my own feelings more the most is that now we will reduce barriers for the for more decentralized protocols. If it's if it we we will make it simpler for the new staking protocols to emerge, we will see more protocols.

And right now, when you need to at least deal just with this issue alone, it's already a big blocker. And if we remove this blocker, that would be better for Ethereum. And for the staking protocols and delegators, we simply add simplicity, safety, and trustlessness. So, as a next step, uh I'm happy to announce that lighter contributors have already proposed EIP-8205 as a non-headliner for Hagota. But, it is you guys, you guys sitting here in the room, you watching this in recording, who will decide whether it's worth implementation or not, whether it's needed for Ethereum or not. So,

please scan the QR code, jump to Ethereum Magicians discussion, and I hope I did not the most terrible job of convincing you that this EIP is indeed a solution to a real problem that we have on Ethereum right now. Thank you.