# Fraud Proof Challenge Period Fraud Proofs have been suggested as a potential alternative for multiple oDAO duties. This section explores the security of optimistic fraud proofs and how it relates to the challenge period and other variables. The challenge period aims to protect against censorship attacks. The first type of censorship to consider is on the block builder level: An attacker can attempt to get builders to exclude the fraud proof transaction from their blocks. If they succeed for every block in the challenge period the fraud goes unreported. One could imagine an attacker using MEV boost relays for something like this, but then a single validator building a block locally during the challenge window could thwart the attack. The second type of censorship requires collusion with a majority of all validators. These validators would not only exclude the fraud proof, but would also fork out blocks from other validators that include it. This attack would require a high level of coordination since forking requires direct intervention of participants, but would be resilient against individuals building locally. Besides the high level of difficulty of both attacks, [Ethereum is inherently censorship resilient](https://hackingdistributed.com/2016/07/05/eth-is-more-resilient-to-censorship/): censorship creates a DoS vector that could cost validators priority fees while it lasts. It is also [possible to detect forking censorship](https://ethresear.ch/t/reducing-challenge-times-in-rollups/14997) and the challenge period could increase when it is likely. Nevertheless, I believe it is possible to make censorship attacks crypto-economically not viable. These are the variables to consider in this context: - The cost to exclude a transaction scales with the **reward** a challenger would receive for a successful fraud proof, because it determines the priority fee a challenger can pay for inclusion. The payment for censorship needs to make up for that lost reward. - The cost also scales with the length of the challenge period or the **number of blocks**. Under block level censorship, the attacker needs to pay the reward every block, under forking censorship only for 51% of blocks. - On the other side of the equation is the **value at risk**: how much an attacker stands to gain if the fraud goes unreported. For the block level censorship, the math is relatively straight forward: Say for example that a challenger would earn 1 ETH for a successful fraud proof and is willing to pay up to 0.8 ETH in priority fees and the challenge period is 12 hours (3600 blocks). Then as long as value at risk is below 2880 ETH, block level censorship is not profitable since: $$ 0.8 \cdot 3600 = 2880 $$ The math is less clear in the case of forking censorship. Since validators are colluding in this attack, the cost doesn't scale with number of blocks, but per member in the cartel: As a floor value, each member should demand at least the same amount they would make from including the fraud proof, but in practice the price might be much higher. Looking at [Rated Network](https://www.rated.network/?network=mainnet&view=nodeOperator&timeWindow=30d&page=1) in an absolute worst case scenario a 51% cartel would need over 20 members. So the safe level in the above example would be: $$ 0.8 \cdot 20 = 16 $$ Looking at this in the context of some of the oDAO duties: ## Fraud Proof Scrubs The value at risk is the 24 ETH that a minipool receives from the protocol. A reward of 1.2 ETH together with the existing 12 hour challenge period would provide safety against the floor value under the forking censorship scenario. Note that while an attacker might create many minipools at once and then attempt to censor all fraud proofs, the reward and thus also the censorship cost scale linearly with the number of minipools. ## MEV Stealing Proofs The value at risk is the penalty that would be applied, but no more than 8 + 2.4 ETH. We have a natural "challenge period" from the [minimum 27 hours](https://eth2book.info/bellatrix/annotated-spec/#min_validator_withdrawability_delay) before a validator can be withdrawn. A reward of 0.52 ETH would protect against forking censorship. As above, stealing with multiple minipools would not improve the attack. ## Balance Submission At worst, the value at risk can be seen as the amount of rETH that can be minted at an incorrect ratio times the divergence from the correct price. But MEV bots would immediately start taking advantage of the incorrect price once the challenge period passes and the realizable profit would be even less than that. The value at risk can be limited by implementing [guardrails] or scaling the challenge period based on the price delta of the update. To protect against forking censorship, a sizeable reward would be necessary. Say for example that 20k ETH worth of rETH can be minted and we limit the price delta to 1%, then a 10 ETH reward would be sufficient.
Last changed by  
 
knoshua.eth
73

Read more

MEV Proofs

This section looks at the potential of proving MEV stealing with the help of the beacon block root proposed in EIP4788. A relatively straight-forward approach would be to use merkle proofs against the beacon root to objectively determine when a node operator has stolen MEV according to some rule set and apply a penalty accordingly. However there are some challenges around what data the beacon root gives us access to and some limitations for what rules can be verified. State Proofs The beacon block root would give access to: The proposer_index contained in the BeaconBlock itself validators in BeaconState linking indices to pubkey and withdrawal_credentials fee_recipient, transactions, and state_root contained in the ExecutionPayload in BeaconBlockBody So unfortunately, a pure state proof approach doesn't appear to be possible with the beacon root alone. For example it would be possible to prove that:

5/25/2023
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 -WITH CRED] in a trustless manner. Design The general flow is similar to what we have now: The node operator initiates a first deposit of 1 ETH to the beacon chain. During a scrub period, a fraud proof can be submitted. a) If no fraud proof is submitted, the remaining 31 ETH can be deposited. 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.

5/24/2023
Chronos

Immunefi Bug Bounty Impacts in scope look reasonable. Pays out $100k - $30k for critical findings, $15k for high, and $5k for medium. Payout are in their native token and vesting: All the rewards given will have a vesting schedule of 2 months, managed by a smart contract. This seems pretty annoying for whitehats and benefit to the protocol is unclear to me. Multisig There is a 5/8 multisig consisting of 4 team members and 4 people from the ecosystem (Byte Masons, Sphere Finance, Deus DAO, Equalizer). It appears that the entire team and 3 of 4 ecosystem members are anon. I could only find information about Blake Hooper, founder of Equalizer.

5/6/2023
Bug Report - Rocket Pool ETH Transfer Attack

This bug report was produced by @rileyholterhus and knoshua, submitted via Immunefi and addressed in commit 63f718e and commit f657846 before the Atlas upgrade. Summary If a group of attackers directly transfers their ETH to a minipool, they can cause a node operator to lose up to 16 ETH. In this exploit, rETH holders receive both the transferred funds and the 16 ETH the node operator loses, so there is an incentive for rETH holders to collude for a profit. This collusion can occur in a trustless manner, which increases the likelihood of it happening. The attackers will profit by holding 33% of the rETH supply, and they can use unclaimed partial withdrawals to offset the exploit cost (slightly lowering this percentage). There also exist theoretical ways to make the exploit more efficient/profitable . We believe that a few relatively simple changes can make this attack impossible. Main Idea In Rocket Pool's upcoming Atlas upgrade, the distributeBalance function has logic that depends on the minipool's balance (which we will refer to as $b$). If $b \geq 8$ ETH, the minipool assumes that the node operator (NO) has completed a full withdrawal from the beacon chain. Since the NO only provides 8 of the 32 validator ETH, $b < 24$ ETH is considered a net loss of funds, resulting in a slashing of the NO's RPL collateral. This logic creates two potential attack vectors for malicious actors seeking to exploit the accounting system: By frontrunning a victim NO's distributeBalance call with a manual transfer, an attacker can cause the NO to inadvertently trigger a slashing of their RPL collateral. This is possible if the NO uses the public mempool for their transaction (which most Ethereum users do). By manually transferring ETH and calling beginUserDistribute themselves, an attacker can trigger an RPL slashing after the user distribution wait time has passed (currently set to 14 days). This method does not work if the NO completes a full withdrawal during this period, but there are realistic scenarios (see below) where the user distribution wait time is shorter than the validator full-withdrawal wait time. This is especially true if Atlas is deployed prior to the Shanghai/Capella hard-fork.

4/21/2023
Read more from knoshua.eth
Published on HackMD