Fraud Proof Scrubs

Instead of the current challenge period that relies on trusted oracles to scrub, this design allows fraud proofs during a challenge period to prevent the withdrawal credential exploit described in Scrub Check - Withdrawal Credentials in a trustless manner.

Design

The general flow is similar to what we have now:

1. The node operator initiates a first deposit of 1 ETH to the beacon chain.

2. During a scrub period, a fraud proof can be submitted.

3. a) If no fraud proof is submitted, the remaining 31 ETH can be deposited.

4. b) If a valid fraud proof is submitted, the minipool is scrubbed: ETH is returned to liquid stakers and RPL is slashed and awarded to the person providing the proof.

The crucial difference in Step 2 is that fraud (frontrunning the deposit to set different withdrawall credentials) is verified on-chain and does not rely on trusted oracles. Instead, a verifiable proof can be submitted by anyone. To achieve this, we use the Deposit Root of the Incremental Merkle Tree maintained by the Solidity Deposit Contract as a source of truth for all deposits that happened before, by storing it in Step 1.

Each deposit to the deposit contract adds a DepositData object to a incremental Merkle Tree that contains:

• pubkey of the validator the deposit is for

• withdrawal_credentials of the validator

• deposit amount

• BLS12-381 signature of the validator However this signature is not verified by the deposit contract.

If someone is attempting the withdrawal credential exploit, then the Deposit Root at time of first deposit must contain a leaf with the same pubkey as the minipool and a valid signature. Conversely, if it is not possible to prove existence of such a leave, then the deposit executed by the Rocket Pool smart contracts is guaranteed to be the first valid deposit for this pubkey and the withdrawal credentials will be set correctly.

Verifying the signature as part of the fraud proof is necessary to prevent griefing of node operators: Anyone can deposit 1 ETH for a given pubkey together with a made up signature. Such a deposit would be rejected by the beacon chain because of the invalid signature, but it would be part of the deposit data merkle tree. So in a fraud proof system without signature verification, an attacker could frontrun a deposit with an invalid signature and scrub a legitimate minipool.

Implementation Complexity

Ideally, there would be multiple implementations of a "watchtower" software that allows anyone to run scrub checks and submit fraud proofs. The smartnode already implements a check of the Deposit Merkle Tree including signature verification as part of the oDAO scrub duty. Generating the merkle tree proof is comparable to the process for claiming rewards under the merkle rewards system.

As explained above, the smart contracts have to implement signature verification. EIP 2537 is considered for inclusion for Cancun and would introduce new opcodes that make that straight forward, see for example this Deposit Verifier.

Even without EIP 2537, it should be possible to implement the necessary operations (Map to Field and the Pairing). This would add significant implementation complexity and result in higher gas cost of signature verification. But it would only be necessary when a fraud proof is submitted and the gas cost would be covered by the penalty taken from the scrubbed minipool.

Security Considerations

Just like Verifiable Off-Chain Calculations, this is a form of optimistic fraud proofs and requires at least one honest participant. See Fraud Proof Challenge Period for security implications. It is worth pointing out that the current oDAO scrub system has similar trust assumptions: It requires not only one but at least 51% honest participants and censorship and DoS during the 12 hour period are a risk.

Alternatives

Any design that doesn't split the deposit up in two parts appears to be challenging: Theoretically, it may be possible to generate a ZK proof, that no invalid withdrawal credentials have been set for a certain pubkey against a root. But this would require generating such a proof against an existing root before depositing and hoping that nobody else deposits while the proof is generated or the transaction is pending, because any deposit would change the root and invaldiate the proof.

Another consideration may be to prove validity of a deposit instead of proving fraud. The main disadvantage of this approach is increased gas cost.

With EIP 4788, it would also be possible to prove that withdrawals credentials have been incorrectly set (or prove that they have been correctly set) against the beacon root. The drawbacks are the delay between deposit and data on the beacon chain and increased gas cost of the proof.