# Towards a Trustless Decentralized Liquid Staking Protocol

Decentralized staking protocols are increasingly popular on Ethereum, but are surprisingly difficult to implement in a trustless way. The clear leader in decentralized staking is [Rocket Pool](https://rocketpool.net), which utilizes a permissionless set of validator nodes and economic incentives to securely stake user deposits and offer yield through their liquid staking token: rETH. However, there are currently some barriers to making such a protocol completely trustless. Rocket Pool relies on a small group of reputable individuals and organizations, called the Oracle DAO (ODAO), to perform certain ciritical bookkeeping operations. The ODAO has recently garnered criticism from some in the community, but the ODAO has always been used a last resort for protocol functions, and the Rocket Pool community appears eager to further reduce the ODAO's reponsibilities.

This post will outline some early ideas for building a trust-minimized staking protocol, using only features from Ethereum's upcoming Shanghai upgrade. The goal is not to build a competitor to Rocket Pool, but rather to think about the challenge of trust-minimized staking without every existing constraint of the Rocket Pool protocol. Our proposed design is meant to be as simple as possible, and thus will make some compromises which may be unacceptable for other protocols. Nonetheless, we hope that some of the ideas discussed can be evolved into Rocket Pool and other decentralized staking protocols.

## Overview

A decentralized staking protocol has two primary parties:
1. **Depositors** are users who deposit ETH to be staked by the protocol. In return, they receive a tokenized receipt of their deposit which will accrue value over time via the protocol's staking rewards. These _liquid staking tokens_ are extremely useful for users who want to earn staking yield without staking the minimum validator requirement (32 ETH) and/or without the hassle of running a validator node.
2. **Node Operators** (NOs) are more sophisticated users that run validator nodes to stake the pooled ETH from the depositors. In a decentralized, permissionless protocol, extra care is needed to ensure the NOs do not cause losses to the protocol. Hence, NOs are required to deposit collateral which is penalized in the event that the validator gets slashed. For example, in the current version of Rocket Pool, the NO collateral consists of 16 out of the 32 ETH for the validator as well as an additional amount of RPL (the Rocket Pool utility token).

Most protocols have an additional party which both acts as an oracle and enforces rules on the node operators which are difficult (or impossible) to express with smart contracts alone. The oracle operators usually have to be trusted to perform these actions faithfully, but our design will focus on reducing this trust requirement as much as possible.

To keep things simple, we propose a protocol based on Rocket Pool, but without the additional utility token. Specifically, users deposit ETH into a deposit pool and receive some amount of tmsETH (trust-minimized staked ETH) in return. Node operators deposit 16 of their own ETH as collateral, and the remaining 16 ETH for the validator is taken from the deposit pool.

Similar to rETH, the tmsETH / ETH ratio will appreciate over time as staking rewards are collected. Specifically, the tmsETH price is controlled by the protocol's exchange rate when depositing and/or withdrawing. This is calculated with

tmsETH : ETH ratio = (total tmsETH supply) / (net ETH deposited + net ETH rewards) 

where the ETH deposited refers only to the user deposits (not the NO deposits), and the ETH rewards are the portion of the validator rewards that belong to the protocol rather than the NO.

## Reward Distribution

To incentivize the work of node operators, it is natural that node operators collect proportionally more rewards than the depositors. Most staking protocols have settled on a model where the NOs collect 100% of the rewards on their deposit as well as a small commission (10-15%) of the rewards from the protocol deposit.

Unfortunately, there's a catch. Staking rewards consist of consensus rewards (i.e. from attesting and proposing blocks) as well as execution rewards (i.e. priority fees and MEV). Because NOs are solely responsible for proposing the blocks, there are virtually unlimited ways that an NO could collect MEV rewards, so it is extremely difficult for a protocol to ensure that the node operators fairly share these rewards with the protocol.

Nonetheless, some rough heuristics for detecting MEV theft can be implemented and enforced by an oracle DAO, which is the approach the Rocket Pool is considering. Leaving aside the issues of properly identifying MEV theft in the first place, having the ODAO enforce MEV theft penalties on-chain introduces substantial trust, as these claims are difficult (maybe impossible) to challenge.

This is one major difference between this proposal and existing protocols. Rather than hopelessly try to prevent MEV theft, we simply allow the NO to keep all execution rewards. To compensate for these excess NO rewards, we use a _negative commission_ on the consensus rewards, meaning that the protocol collects commission on the NO's consensus rewards. As a result, no ODAO enforcement is needed, and reward distribution can remain similar on-average.

Logically, this can be viewed as the node operators paying interest to the depositors on the borrowed ETH, which the NOs use to extract MEV. The ideal commission rate is somewhat difficult to compute, because NO rewards are now much more dependent on highly volatile MEV. Furthermore, the ratio of MEV rewards to consensus rewards (on average) will vary over time, indicating the commission rate for a given time period should be determined dynamically, rather than the current locked-in commission rate approach.

The best way to implement this is partially left as an open problem. However, one potential approach is to create a market wherein NOs bid via their commission rate to receive the user deposits. This may allow for discovery of the current fair commission price, which could then used to distribute the incoming withdrawal rewards.

## Beacon Chain State

To control the tmsETH : ETH price, the protocol must track the total amount of ETH staked by the protocol. Unfortunately, beacon chain state is not accessible on the execution layer (at least not until EIP-4788, which remains far away). This is another fundamental barrier to trustlessness in staking protocols.

In Rocket Pool, the ODAO is responsible for monitoring the beacon chain balances of each node and reporting the total balance, as well as penalizing NOs whose validators are slashed. However, it may be possible to achieve this functionality in a trust-minimized way via state proofs alone.

At a high level, a staking protocol has to monitor the following events for all validators:

1. **Deposits**: when the NO or protocol deposits ETH into the deposit contract
2. **Withdrawals**: when a validator collects ETH on the execution layer from the consensus layer
3. **Slashings**: when a validator is slashed on the consensus layer, resuling in a reduction of their consensus layer balance and their eventual exit from the protocol

### Deposits

Trustlessly verifying deposits in the execution layer is already possible today. Any deposit into the deposit contract can be verified trustlessly on-chain using state proofs (see [Appendix 1](#Appendix-1-State-Proofs)). This is primarily useful for verifying the validator withdrawal credentials (see the writeup on [Scrub Checks](#Scrub-Checks) for more information), but can be useful in other ways as well.

### Withdrawals

After Shanghai, verifying withdrawals can be done similarly, because the withdrawals in each block will be [included in the execution layer header](https://eips.ethereum.org/EIPS/eip-4895#new-field-in-the-execution-payload-header-withdrawals-root). Note that we require [0x01 withdrawal credentials](https://github.com/ethereum/consensus-specs/blob/ba690852d65b15a04c174a5221f7172c8e3ba797/specs/phase0/validator.md#eth1_address_withdrawal_prefix) to be used from the start, so all validators will have [partial withdrawals enabled](https://github.com/ethereum/consensus-specs/blob/89f2eae31893639a5ef3b22df6225705bf1a1db0/specs/capella/beacon-chain.md#introduction). This greatly simplifies balance tracking, because we can estimate every beacon-chain balance to be `32 ETH + epsilon` (see [Appendix 2](#Appendix-2-Pending-Rewards-Estimation)), and separately account for any slashing losses.

### Slashings

Unfortunately, the slashing events cannot be directly observed from the execution layer. However, we claim that slasing events can be inferred trustlessly using deposits and withdrawals as a side-channel. Specifically, we propose an optimistic oracle for slashing events, where disputes are resolved by two or more parties participating in an interactive fraud proof. The oracle participants are required to put up a bond -- which will be slashed in case of fraudulent claim -- in exchange for a small revenue paid by protocol rewards. (Note: as in Rocket Pool, it may make more sense to use a utility token for this).

Here is a rough sketch of how the oracle operates:

1. Alice submits a claim to the slashing oracle and puts up a bond. She claims that some validator, operated by Bob, was slashed for X ETH.
2. Bob optionally challenges Alice's claim and puts up a bond. Bob claims his validator was actually slashed for Y ETH (where Y could be zero), and deposits enough ETH into his validator in order to push his balance back above 32 ETH. If Bob does not challenge within the challenge window, Alice's claim is finalized, and she collects a small reward.
3. Once a partial withdrawal of Z ETH occurs, Bob proves to the oracle that his validator balance was 32 + Z ETH.
4. Alice optionally challenges Bob's challenge. If Bob cheated in step 2 by depositing more than Y + Z ETH, Alice can prove this to the oracle and collect Bob's bond. If Alice does not intiate this challenge within the challenge window, Bob collects Alice's bond.

Note that the correctness of this oracle requires at least one honest participant -- otherwise, we have no guarantee that the oracle will report every slashing event. However, fraud proofs enable participation in the oracle to be permissionless, which makes a single honest reporter a virtual guarantee. The exact oracle reward mechanics needed for this are left as an open problem, but one idea is to only reward the first submission which gets finalized.

## Scrub Checks

Another barrier to fully trustless staking protocols stems from a limitation of the Ethereum deposit contract. This is known as the [withdrawal credential exploit](https://github.com/rocket-pool/rocketpool-research/blob/master/Reports/withdrawal-creds-exploit.md), wherein a malicious node operator first sets the withdrawal credentials to something entirely under their control before depositing via the staking protocol. Because the beacon chain uses the withdrawal credentials from the first deposit, the credentials set by the protocol are ignored, allowing the attacker to steal the user-deposited ETH. As a result, Rocket Pool currently has a "scrub check" period, where the ODAO can flag a malicious node operator _before_ they receive any user deposits.

It's worth elaborating on why a trustless scrub check is difficult: verifying BLS12-381 signatures on-chain is not possible without using a precompile ([which doesn't yet exist](https://eips.ethereum.org/EIPS/eip-2537)) or a ZK-SNARK ([which does exist](https://ethereum-magicians.org/t/eip-2537-bls12-precompile-discussion-thread/4187/31), but aren't battle-tested enough for such use cases). As a result, the deposit contract doesn't actually check the deposit data's BLS signature, instead leaving it up to the consensus layer to validate the deposits. The consensus protocol ignores all invalidly-signed deposits until a validly-signed deposit for that pubkey has already been processed. This first valid deposit is used to determine the withdrawal credentials for the validator.

As a result, the obvious versions of a trustless scrub check fail because the fraud proofs cannot validate whether a deposit has a valid signature or not. Note that it may be possible to work around this limitation with a purely EVM signature validation, because gas efficiency is not a large concern in a fraud proof scheme, but implementing this would be a significant undertaking.

However, there is another possible approach to prevent this attack which is entirely trustless, [described by holterhus](https://discord.com/channels/405159462932971535/857072928155762718/1079525698898767893) on the Rocket Pool Discord. The idea is to introduce another permissionless role (called "sponsors") which does the scrub check off-chain (i.e. verifying the validator has correct withdrawal credentials) and then temporarily sponsors the protocol's deposit. The NO can self-sponsor if they are able, or they can pay a fee to a third party to sponsor their validator. After the validator is activated and the first partial withdrawal comes in to the execution layer, the protocol can now verify the withdrawal credentials are correct and refund the sponsor.

## Summary

The above proposal contains early ideas for a trust-minimized decentralized staking protocol. The design differs from Rocket Pool in a few key ways which allow for removal of oracle responsibilities or viable verification of oracle claims via fraud proofs. As a result, our protocol allows for an Oracle DAO which is permissionless, strengthening the assumption of a single honest participant.

This proposal is surely incomplete, and may be updated over time based on feedback and new ideas. Feel free to reach out on [Twitter](https://twitter.com/@tjbecker_) with feedback or contributions!

## Acknowledgements

The design described here is inspired by Rocket Pool and discussions from the Rocket Pool Discord server. Some ideas also came from discussions with Riley Holterhus.

## Appendix

### Appendix 1: State Proofs

The execution layer block headers cryptographically commit to all state contained on-chain at that block. Ethereum stores most of this state either directly in the block header, or in a data structure called a [Merkle-Patricia Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) (MPT) whose root is stored in the header.


This allows for cheap cryptographic verification of any on-chain data, including account balances, storage slots, log events, etc. Specifically, verifying any piece of data requires only the block header and a reasonably short "witness" string, and is efficient enough for some use-cases to be done entirely on-chain.

One minor issue is that verifying the legitimacy of a block header on-chain can be difficult. The EVM `BLOCKHASH` opcode only provides access to the most recent 256 block hashes, so older blocks require more clever verification techniques (e.g. ZK-SNARKs).

Thankfully, all of the MPT logic can be implemented in a generic way, so actually using state proofs is less challenging than it may sound. For instance, [Relic](https://docs.relicprotocol.com) is a trustless protocol designed to simplify state proof verification for on-chain applications. Trust is rooted in an on-chain cache of all historical block hashes, which are verified using a simple ZK-SNARK circuit and compressed into Merkle trees.

#### ZK-SNARKs vs Fraud Proofs

Theoretically, since all of the required state can be verified cryptographically, the oracle operators could compute the required values using a ZK-SNARK, which is then verified on-chain when reporting. Even leaving aside the challenge of developing correct circuits for such complex computations, ZK-powered oracles make other tradeoffs which may be unacceptable for staking protocols.

While they avoid the need for a challenge period, ZK-oracles may still have high latency due to proving times. Large ZK-SNARK proofs have steep hardware requirements, and SNARK verification has higher on-chain gas costs than optimistic reporting; these factors increase the required oracle budget and limit the decentralization of the oracle. With ZK-oracles, the impact of centralization is limited to liveness concerns (i.e. DOS or censorship, rather than invalid reporting), but for protocols where frequent oracle reports are critical to price calculation, oracle liveness is essential.

Alternatively, an optimistic oracle using fraud proofs is incredibly cheap and easy to decentralize. For one, the hardware requirements are identical to existing node operators. Additionally, on-chain state verification is only used to resolve disputes, and in those rare cases still use much less gas than a SNARK verification.

### Appendix 2: Pending Rewards Estimation

Due to automatic partial withdrawals, the balances of all validators in our protocol should remain close to 32 ETH --- i.e. [every few days](https://notes.ethereum.org/@launchpad/withdrawals-faq#Q-How-fast-will-I-be-able-to-make-a-partial-withdrawal-Or-when-will-I-get-access-to-the-excess-rewards-that-are-on-my-validator) their consensus layer balance exceeding 32 ETH will automatically be withdrawn the the execution layer. Without a trustless way to access the beacon state, it may suffice to simply estimate the beacon chain balance of every protocol validator to be `32 ETH + X` for some small value of `X`. (Note that slashed validators are accounted for separately).

The best value for `X` will vary over time depending on the network conditions. If a high level of precision is important, it may be possible to compute the best value of `X` dynamically. To get an idea for how this is possible to do trustlessly, consider an oracle which reports the average partial withdrawal `W` of all protocol validators within the last day, along with a merkle root committing to this computation tree. Since every partial withdrawal is accessible on L1, fraud proofs can be used to ensure its accuracy. Then, you may be able to estimate `X` based on `W` (for simplicity, think `X = W / 2`).