DendrETH: A trustless oracle for liquid staking protocols
=========================================================

The [DendrETH project](https://github.com/metacraft-labs/DendrETH) has implemented a zero-knowledge circuit capable of proving successful state transitions based on the beacon chain [light client sync protocol](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/sync-protocol.md). The project is currently aiming to implement a zero-knowledge circuit capable of proving the [Casper finality conditions](https://arxiv.org/abs/1710.09437) by processing the attestation messages of the entire Ethereum validator set. This work has led us to explore efficient constructs for implementing recursive zero-knowledge circuits for BLS aggregation, validator set membership tracking, validator duties tracking and more.

We believe that these building blocks are well-suited for solving a pressing problem that all liquid staking protocols face: How can a smart contract keep track of the on-chain performance of the created validators without relying on a set of trusted oracles that inevitably introduce additional security risks and economic overhead to the protocol?

In particular, after the introduction of [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788), all liquid staking protocols will benefit from the presence of security-audited zero-knowledge circuits providing the following proofs:

### 1. Proof of Total Locked Value

Given a merkle accumulator containing all public keys of the validators created by the liquid staking protocol, provide a proof for the sum of the balances of all validators at the last finalized epoch.

### 2. Proof of Total Rewards Potential

Given a merkle accumulator containing a set of validator public keys (this scales from a single validator to the entire set of validators created by the liquid staking protocol), provide a proof that indicates the maximum number of rewards that the set of validators were eligible for within the canonical finalized history. This takes into account the block proposal duties and the sync committee duties of the validators.

Since the maximum possible profit from a block cannot be determined without knowledge of all attestations that were broadcast in the network, we assume that the potential reward is equal to a running average of the last N blocks leading up to the slot of the proposal.

Similarly, since the maximum MEV profit from a block cannot be known, we can model it as a public input for the circuit which can be set by the liquid staking protocol (and potentially managed dynamically).

Please note that the circuit can verify the presence of a transaction within the block that distributes the MEV rewards to the liquid staking protocol, but unfortunately this doesn't rule out the possibility that the proposer was paid some additional sum by the builder out-of-band. Some of these difficulties in the tracking of MEV rewards are likely to be resolved in the planned [Proposer-Builder Separation](https://ethereum.org/nl/roadmap/pbs/) upgrade of Ethereum that will enshrine the MEV distribution within the base protocol.

### 3. Proof of Poor Validator Performance

Given a **Proof 2** obtained for a particular validator as described above, provide a proof that the validator has earned less than a *target* percentage of the maximum rewards (e.g. 90%). Such a proof can be used to penalize or evict particular operators from the protocol. The circuit compares all recorded withdrawals of the validator (while taking into account any deposit top-ups) to the *total rewards potential* to determine whether the validator is meeting the target performance.

### 4. Proof of Slashing

Certain protocols can benefit from explicit proofs for slashing events, which can be provided either as regular SSZ merkle tree proofs or as zero-knowledge components that can be embedded in larger proofs.

### 5. Proof of Deposit

A common mitigation for the well-known [validator deposit front-running attack](https://medium.com/immunefi/rocketpool-lido-frontrunning-bug-fix-postmortem-e701f26d7971) is the execution of 1 ETH initial deposit before the rest of the 32 ETH are committed. Proofs for verifying that a validator with a particular index and the desired withdrawal credentials has been created can be provided both as regular SSZ merkle proofs and as zero-knowledge circuit components.

## Rationale

The development of the proposed zero-knowledge circuits is motivated by several key factors and considerations.

Firstly, the reliance on trusted oracles in liquid staking protocols poses a significant risk. These oracles have the power to influence token prices within the protocols, potentially favoring certain users and shifting profits disproportionately. This centralized control contradicts the fundamental principles of decentralization and trustlessness that underpin blockchain technology.

Secondly, the oracles in question control a substantial amount of funds within the protocol. To ensure their continued participation and prevent potential defection, it is essential to provide them with adequate compensation. Additionally, given the substantial power they possess, the oracles become prime targets for hackers. This necessitates significant investment in maintaining their security infrastructure, further contributing to the overhead associated with the existing liquid staking protocols.

In practice, the current costs associated with oracles in the already deployed liquid staking protocols have been subject to criticism, raising concerns regarding the economic efficiency and viability of the protocols. Therefore, it becomes crucial to explore alternative approaches that can address these concerns and potentially reduce costs while enhancing overall security and trustlessness.

The zero-knowledge circuits envisioned in this proposal can be developed as a public good - a reusable solution that can potentially replace the use of trusted oracles in all existing and future liquid staking protocols. When leveraged, this solution will eliminate the variable costs associated with trusted oracles in favor of the fixed cost of verifying zero-knowledge proofs on chain (expected to be less than 500K gas per update).

By introducing these trust-minimized oracle alternatives, the DendrETH team aims to enhance the security, decentralization, and economic efficiency of liquid staking protocols. The reduction in reliance on trusted oracles and the associated costs can lead to a more robust and sustainable ecosystem, fostering greater user confidence and participation.

## Technical Details

### Integration through a Fixed Set of Withdrawal Credentials

If the liquid staking protocol uses a fixed address in the withdrawal credentials of all created validators (or a small fixed set of addresses), then no modifications are necessary to the smart contracts responsible for deposits. The DendrETH zero-knowledge circuits will scan the entire set of active validators, identifying all validators using the specified withdrawal credentials.

### Integration through a Merkle Accumulator for the Validator Set

If the liquid staking protocol uses a more dynamic set of withdrawal addresses, the smart contracts responsible for executing deposits has to be modified to record the root hash of a binary SHA256 merkle tree constructed over an append-only list of `(validator_public_key, deposit_index)` tuples. To compute this value incrementally, the smart contract needs to store only *log(N)* SHA256 values (tree branches) in a very similar way as the [official deposit contract](https://github.com/ethereum/consensus-specs/blob/e4a9c5fa29def20c4264cd860868f131d6f40e72/solidity_deposit_contract/deposit_contract.sol#L69).

The DendrETH team offers a reference reusable implementation here:

https://github.com/metacraft-labs/DendrETH/blob/main/beacon-light-client/solidity/contracts/validators_accumulator/ValidatorsAccumulator.sol

### Proof of Total Locked Value

#### Public Inputs

The following public inputs must be supplied on-chain during the verification of the proof:

- `withdrawalCredentials[N]`: The fixed set of withdrawal addresses, used by the protocol.
- `validatorsAccumulator`: The root hash of the merkle accumulator described above (for protocols based on a dynamic set of withdrawal addresses).
- `stateRoot`: The current beacon state root against which the proof were generated (obtained through the mechanism described in EIP-4788).
- `totalLockedValue`: The total locked value amount that will be verified by the circuit (this value is expected to be stored in the contract and updated with a transaction that also submits a corresponding ZK proof).

#### Circuit Logic

The circuit performs the following verification steps:

1. **BeaconState Fields Verification**: The circuit uses SSZ merkle proofs to verify the following additional private inputs against the provided `stateRoot`:

* `currentEth1DepositIndex` matches the `eth1_deposit_index` field of the state (numerically)
* `currentEpoch` matches the `slot` field of the state (by dividing by `SLOTS_PER_EPOCH`)
* `currentValidatorsRoot` matches the `validators` field of the state (as a SSZ `hashTreeRoot`)
* `currentBalancesRoot` matches the `balances` field of the state (as a SSZ `hashTreeRoot`)

2. **Commitment Mapping**: A general-purpose commitment mapping circuit establishes a correspondence between `currentValidatorsRoot` value (a SSZ `hashTreeRoot`) and a Poseidon root hash of an equivalent tree of records (`currentValidatorsRootPoseidon`). Similarly, we perform an incremental computation of a Poseidon commitment map for the `validatorAccumulator` (`validatorAccumulatorPoseidon`).

3. **Validator Status and Balance Verification**: The circuit receives up-to-date validator details as private inputs and verifies them with Poseidon merkle proofs against the `currentValidatorsRootPoseidon` value. Each validator public key is also verified with a Poseidon merkle proof against the `validatorsAccumulator` and the corresponding deposit index in the accumulator is compared against the `currentEth1DepositIndex` value (obtained from the state). A validator is relevant for the total locked value computation only if its deposit index was already processed in the state and its activation and exit epochs enclose the `currentEpoch` (please note that we allow the merkle proof verification of the activation and exit epochs to fail if the deposit of the validator hasn't been processed yet). Similarly, for each validator we process a SSZ merkle proof against `currentBalancesRoot` and the balance of the relevant validators is summed up in `rangeTotalValue`. In the array of validator details, we require that the validator indices are strictly increasing and the circuit produces a tuple with the following values:

* `rangeStart` (the first deposit index in the array of supplied validator details)
* `rangeEnd` (the last deposit index)
* `rangeTotalValue` (the summed balance of all active validators)
* `rangeDepositsCount` (the number of processed validators)

4. **Range Aggregation**: The circuit combines a number of ranges by verifying that there is no overlap in the indices. `rangeTotalValue` and `rangeDepositsCount` are summed up. We require the final aggregated range to have the same number of deposits as the `validatorsAccumulator`. This ensures that all deposits in the accumulator have been processed because the "no overlapping" check ensures that we cannot process the same deposit twice.

5. **Hashing and Output Generation**: The public inputs are hashed. The circuit outputs the first 253 bits of the SHA-256 hash of the public inputs to make circuit verification more cost-effective.

## Project Timeline

* **August 2023** - Functional proof of concept implementation of the "Total Locked Value" circuit that will provide realistic estimate for the operational latency and cost of the final solution.
* **September 2023** - Final version of the "Total Locked Value" circuit with suitable documentation for audit purposes. Early prototype of the operator software. Start of development the "Proof of Slashing" and "Proof of Deposit" proofs.
* **October 2023** - First production-ready version of the operator software, capable of creating proofs for total locked value, deposits and slashings. The software is likely to depend on the services of cloud operators such as AWS.
* **Rest of 2023** - Audit and further improvements to the operator software.
* **2024 Q1/Q2** - Development of the “Total Rewards Potential” and “Poor Validator Performance” proofs.