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: censorship creates a DoS vector that could cost validators priority fees while it lasts. It is also possible to detect forking censorship 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.
5/25/2023Instead 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/2023Immunefi 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/2023This 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