Ethereum Withdrawals: Exit Request flows

Ethereum Withdrawals: Exit Request flows

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:

  1. Validator Exit: validators join the exit queue, they remain active in the meantime, and wait to be exited
  2. Validator Withdrawal: exited validators’ balances are minted on the withdrawal_credential wallet of the Execution Layer

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.

Exit Flows setups comparison

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

1. On-demand synchronous exits

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.

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:

  • If the API is compromised, attackers have direct access to the validation key infrastructure, depending on the role management attempted, attackers could:
  • If the API can only perform exit signatures - exit all validators run by the operator
  • If the API can perform other signatures with validation keys - slash validators
  • Possible DoS vectors on the most critical component of the operator’s infrastructure
  • Any issue in the API route’s implementation in future software releases can have dramatic consequences

This flow creates other security concerns that we will illustrate in the next example.

2. On-demand asynchronous exits

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.

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:

  • Multi-sig wallets (Gnosis Safe) with defined quorum
  • Custody solutions (Fireblocks, Ledger Enterprise) with custom approval flows
  • Hardware wallets (Ledger Nanos) with pin security and offline signing

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)

3. Exit Messages sharing

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:

  • It does not rely on principle #2 or #3
  • Exit messages should be generated on-demand to avoid any exposure to a leak of all exit messages (principle #4)
  • It requires technical skills to download signed transactions and broadcast them to a CL rpc
  • It is not future proof as VoluntaryExit message signatures are only valid for the current and next hard forks of the network

4. On-demand on-chain exit requests

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):

Goerli example here

The flow works as followed:

  1. A staker calls the requestExit function of the ExitRequestContract for one or many validators, one ExitRequest(caller, pubkey) is then emitted per validator.
  2. The operator watches the new events on the contract and check for each event if:
  • a. Validator pubkey is actually run by them
  • b. Caller address is the withdrawal credential of the validator’s pubkey
  • If a. and b. are correct: sign and broadcast the VoluntaryExit message for the validator

This approach respects all above principles:

  • #1 operation performed on validation keys is done asynchronously and in total isolation
  • #2 the unstaking flow is triggered by the withdrawal_credential wallet, and therefore is managed by the security setup of the staker
  • #3 operator is accountable as anyone can see when an ExitRequest is made (event block timestamp on the EL) and when the exit is actually performed (exit block of the validator on the CL)
  • #4 it is an on-demand flow, where only requested exit are signed and where the user actually has nothing technical to do on its side

“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:

  • Users have to pay gas fees for exits ⇒ in practice gas consumption for emitting an ExitRequest event is pretty low (one exit request = 25428 gas which is about 1$ at current gas & eth price)
  • Possible DoS vector as anyone can emit events on these contracts ⇒ gas cost and 12 second block times make a great rate-limitation, also there is low pressure as exit broadcast timing is not meant to be super fast (a 1h delay is considered fine)

Onwards

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:

  • No need to trust an operator anymore to unstake
  • Applies principles #2 and #4 (#1 and #3 become irrelevant)
  • Less risky work to perform operator-side on the validation key infrastructure

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.

About Kiln

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.

Want to stake your ETH? Contact our sales team

Thanks @pwnh4 for writing this article

Subscribe to our Newsletter
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.