Products
Open-source
Restaking
dApp
Enterprise Dashboard
Validators
Connect
On-Chain
DeFi
Solutions
Protocols
Company
Docs
Products
Solutions
Protocols
Company
Docs
With the upcoming Shapella upgrade launching on the Ethereum Mainnet (April 12th), ETH stakers will be able to fully withdraw their staked positions (the 32 ETH collateral they deposited per validator). This process is composed of two steps:
The Validator Exit operation has been possible since the inception of the Ethereum Beacon Chain (Consensus Layer) and will not be particularly affected by the Shapella upgrade.
This operation requires the validator’s validation key to sign a VoluntaryExit message and broadcast it to the Consensus Layer. It has become an industry standard that the validation keys are protected by the node operator themselves and are rarely shared with customers; having the same validation key in multiple places exposes the staker to slashing risks.
With the upcoming Shapella upgrade, it is required of Ethereum staking operators to offer validator exit flows to users. This post will explore the various proposals that operators have suggested for validator exits so far and the security principles that should be taken into consideration in order to create a safe exit flow.
The problem we are trying to solve is the following:
As an ETH holder staking on dedicated ETH validators through a node provider, I want to notify my operator to perform an exit for some of my validators so that I can initiate the unstaking of my staked positions
An operator may expose an API endpoint that can be queried by the authorized customer to sign (and possibly broadcast on CL) a VoluntaryExit message with the validation key of the requested validators to exit.
This process is done synchronously during the API call.
.png)
Although it seems quite straightforward, performing synchronous tasks with validation keys is a (highly) insecure practice (principle #1). A validation key is a critical component that must be kept confidential to ensure the safety and security of the stakers' positions. Every interaction with them should be done in asynchronous processes with a focus on key isolation. Exposing an API route that can perform synchronous signatures with validation keys opens the door to many issues:
This flow creates other security concerns that we will illustrate in the next example.
This is the same process as above but with an asynchronous process:
An operator may expose an API endpoint that can be queried by the authorized customer to register a request to sign, and broadcast on a CL, a VoluntaryExit message with the validation keys of the requested validators to exit.
This request is then processed via an asynchronous process (which could be a manual operation or a cronjob in the private infrastructure of the operator) that performs the signature and broadcasts the message to the CL.
.png)
This flow has the advantage of keeping the isolation of validation key related processes while being demand-based, however, any action that can be performed on a stake (like exit / unstaking) should rely on the staker’s own wallet security (principle #2).
In this scenario, all authorized users can initiate the unstaking flow of their stake. This breaks fundamental security used to initially create the stake and receive rewards. For example most stakers rely on:
for all their crypto operations. Unstaking positions can have a high business impact for an asset manager, for example, and should rely on approval flows / other security practices that the staker uses for every crypto operation.
The above flows also have the same issue that they are fully off-chain (users query an API to gain access to perform their exits), operators should be publicly accountable for the exit delays they impose to the users and this data should be publicly auditable on-chain by anyone (principle #3)
An operator provides signed VoluntaryExit messages to the staker. This way the staker can broadcast messages with a CL rpc at any time.
This flow is actually interesting as it leaves the staker in control of exiting its validators without needing to trust the operator to do it for them (if the operator disappears for example). But there are multiple issues with this approach:
In this case, an ExitRequestContract is deployed and enables any address to emit an event on-chain to request the exit of a validator (basic implementation):
The flow works as followed:
.png)
This approach respects all above principles:
“Relying on the chain to request validator exits to node operators provides increased security and auditability.”
– Nicolas Maurice, Alluvial Co-Founder and CTO
Possible criticisms:
These Exit Flows are complicated, and come down to one fact: exits can only be triggered by the validation key (the operator) and not by the withdrawal credentials (the staker).
A new model for exits, which we call “dual-key exits” is being discussed following proposals from Paradigm and Lido to make it possible for the withdrawal credential wallet to trigger the exit of a validator from the execution side.
Lido is currently drafting an EIP called “Withdrawer initiated exit requests” that introduces an official ExitContract (similar to the Deposit Contract approach) to emit events with some anti-DoS protection.
This dual key approach would solve a lot of pain points for stakers:
One of the next Ethereum protocol hard forks, Cancun, could include this EIP which would contribute a lot to the ecosystem’s security and safety.
Kiln is the leading enterprise-grade staking platform, enabling institutional customers to stake assets, and to whitelabel staking functionality into their offering. Our platform is API-first and enables fully automated validators, rewards, and data and commission management. With over $2.2b stake under management, Kiln has a particularly strong track record on Ethereum as we run about 3% of the network; this includes 22,000+ validators with 0 slashing events.
Thanks @pwnh4 for writing this article
