Dissecting Ethereum delegated staking from a security perspective — Part 1
As the number of platforms offering delegated Ethereum validators as a service grows, so does the interest in evaluating its associated risks. This post aims to help users interested in these services, as well as professionals reviewing or building such platforms. We will discuss the risk associated with:
- The high-trust relation between depositors and platforms’ operators
- The initial deposit of funds to the staking platform
- How penalizations and slashes are dealt with
- The withdrawal of deposited funds
Over the course of the last few months, Coinspect has been engaged in auditing delegated Ethereum staking platforms. One of our most recent projects involved the auditing of SenseiStake smart contracts, whose report is already published on our website. This platform allows users to deposit funds to create an Ethereum validator, and in exchange, receive an NFT representing the validator’s ownership.
Throughout multiple audits we have observed the lack of a unified source of technical information discussing the risks and technical details associated with Ethereum Staking. Therefore, we are starting a series of articles on security considerations for Ethereum delegated staking platforms.
In this first article, we will discuss the potential security issues of Ethereum staking on delegated platforms, and present multiple sources of information for those interested in learning the details of Ethereum staking.
1. The deposit function
To start the validator’s staking process, a deposit to the legacy-named ETH2 deposit contract should first be made. This deposit is done by calling the deposit function, which takes the following parameters:
- The validator’s BLS12–381 public key.
- The validator’s withdrawal credentials, which could be a BLS12–381 public key hash or a withdrawal recipient address.
- A BLS signature, used to prove that the signer is in control of the validator’ private key (proof of possession), preventing rogue attacks to the BLS aggregation property.
- A hash of the data sent, used by the deposit function to check data integrity.
In the second part of the article series we will provide a detailed explanation of the deposit function and its parameters. Follow us on Twitter to stay tuned!
Now that we have a basic understanding of the deposit function, let’s look into what could potentially go wrong for someone depositing 32 ETH via a delegated staking platform. Note that the considerations we’ll bring up are also relevant for platforms offering deposits of a smaller amount, even though we don’t directly analyze them in this article.
2. Practical considerations for Ethereum staking platforms
In a typical delegated staking platform, users must first deposit 32 ETH. The platform is then responsible for operating the validator, and normally does not share the validator BLS private key (the one used to operate the validator) with the depositor. Depending on who has the withdrawal_credentials, the platform can either be custodial (the platform retains the credentials) or self-custodial (the user controls the credentials). Since the platform is responsible for operating the validator, there is an inherent risk of slashing or penalization to the user’s 32 ETH deposit. However, the risks of a compromised staking platform stealing depositors’ funds can be mitigated and reduced to acceptable levels as we will see below.
We can divide potential issues with Ethereum staking platforms into two categories: those arising from an excess of trust, and those resulting from implementation mistakes or oversights.
2.1 Excess of trust
2.1.1 Deposit front-run by a malicious operator. A rogue operator can initialize a validator using their withdrawal credentials and front-run a user’s initial deposit to steal these funds. Since the user’s deposit would come in second place, it would be processed as a top-up to the malicious validator.
Recommendation: Explore the multiple options presented on Lido Finance’s post and pick the most suitable solution. Platforms offering pre-deposited validators are one of the safest alternatives for depositors looking to prevent this issue. Through the purchase of such validators, depositors are less likely to experience any problems that could arise after the initial deposit and before the validator is confirmed as deposited by the consensus layer, as we’ll see later in this section.
2.1.2 Malformed BLS signature. An invalid signature submitted by the validator’s operator would only be noticed by the consensus layer after a ~12hs period, which could cause deposited user funds to be lost.
Recommendation: The staking platform could assume the risk of submitting an invalid BLS signature by offering pre-deposited validators. Otherwise, they could utilize off-chain software to verify the BLS signature of the validator to be funded before submitting the deposit.
2.1.3 Validators’ public keys reuse. When reusing a public key / depositing to an existing validator, the existing validator is topped-up with deposited funds. For instance, depending on how the platform instantiates validators, a malicious operator could 1) create a validator and 2) reuse that validator’s public key to 3) steal the victim’s funds by having them deposit to the previously created validator.
Recommendation: Although checking whether a public key was already used in the platform could help, it would not be sufficient. It is therefore necessary to consider public keys from validators not run by the platform, which cannot be performed on-chain. A safer alternative for the user is to follow the previous recommendation and let the staking platform assume the risk by offering pre-funded validators.
2.1.4 Staking platform retaining withdrawal credentials. Custodial platforms are those which keep possession or require users to provide the validator withdrawal_credentials — no matter whether those are BLS keys or ETH1 addresses. Users depositing into these kinds of platforms take the risk of losing funds since they won’t be able to freely withdraw them.
Recommendation: Depositors should choose self-custodial staking platforms over custodial ones. On the other hand, staking platform builders should consider offering an experience as trustless and transparent as possible by applying the recommendations presented in this post. Examples of self-custodial platforms could be 1) those which require the depositor to generate and keep the withdrawal_credentials, or 2) platforms that declare the withdrawal_credentials as the address of a smart contract shared between the depositor and the platform.
2.2 Implementation mistakes or oversights
2.2.1 Penalizations or slashing not considered. Each validator’s balance is dynamic and might decrease during its life cycle due to penalties or slashes. Presupposing that the balance of a validator can only increase (due to staking rewards) might break invariants assumed by the staking platform.
Recommendation: Platforms should handle situations where withdrawn funds are less than those originally deposited. Consider the effective balance concept when performing operations based on the validator’s balance.
2.2.2 Unsupported deposit withdrawal mechanism. Staking platforms or contracts not supporting the mechanism for unstaked funds withdrawal could trap depositors’ funds forever.
Recommendation: As this mechanism is not officially confirmed, staking platforms should not rely on a specific implementation for the withdrawal process. Instead, consider implementing a more flexible mechanism to withdraw deposited funds.
2.2.3 Exit queue cooldown period not considered. When a validator requests to exit, it is placed into an exit queue until the exit is processed by the network. Ignoring the cooldown period once the validator leaves the exit queue can lead to unexpected situations for users and platform operators. Varying on the implementation, it might cause depositors’ funds to be lost.
Recommendation: Resulting funds and fees should only be computed once funds are successfully withdrawn after the cooldown window (~27hs) has elapsed.
3. What’s next?
Now that we have highlighted the potential risks associated with Ethereum delegated staking platforms, feel free to check out SenseiStake’s security audit report.
We will be offering more in-depth context and information in our upcoming delivery. Follow us on Twitter to stay up-to-date.
