# MEV Proofs This section looks at the potential of proving MEV stealing with the help of the beacon block root proposed in [EIP4788](https://eips.ethereum.org/EIPS/eip-4788). 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](https://eth2book.info/bellatrix/annotated-spec/#beaconblock) itself - `validators` in [BeaconState](https://eth2book.info/bellatrix/annotated-spec/#beaconstate) [linking](https://eth2book.info/bellatrix/part3/containers/dependencies/#validator) indices to `pubkey` and `withdrawal_credentials` - `fee_recipient`, `transactions`, and `state_root` contained in the [ExecutionPayload](https://eth2book.info/bellatrix/annotated-spec/#executionpayload) in [BeaconBlockBody](https://eth2book.info/bellatrix/annotated-spec/#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: - the node operator owning a specific minipool was opted in to the smoothing pool for a specific block (using the `state_root`) - the block was produced by a specific validator index (using the `proposer_index`) - the `fee_recipient` wasn't the smoothing pool - the last transaction in the block did not transfer ETH to the smoothing pool (using `transactions`) However, the crucial piece that is missing is linking the validator index to the minipool. When a minipool is created, only the pubkey, the withdrawal credentials, and the `deposit_count` of the Deposit Contract are known. The latter can not easily be linked to the validator index, because there can be more than one deposit for the same validator and deposits can be invalid. An area that should be further researched is using ZK proofs against the beacon chain state root to link validator index to pubkey . ## Ruleset The current plan for MEV is to eventually require MEV Boost in [Phase 3](https://docs.rocketpool.net/guides/node/mev.html#phase-3-required). With a trusted oracle, it would be possible to query relay APIs to determine if a MEV boost block was available for a certain slot and detect NOs that build their own blocks instead. With purely on chain data, it would not be possible to distinguish between a block that was legitimately built locally because no ME boost block was available and those that ignored relay blocks to sidechannel MEV. ### Loose Rule Set This is effectively the [Phase 2](https://docs.rocketpool.net/guides/node/mev.html#phase-2-opt-out) ruleset currently in place and the one suggested in the new [penalty system draft](https://github.com/rocket-pool/rocketpool-research/blob/master/Penalties/saturn-system-proposal.md): A block can come from one of the trusted relays or can be built locally as long as the correct fee recipient is used. This rule set could be implemented with the beacon root and a way to link validator indices to pubkeys: To show that a penalty should be applied, a proof could be provided that a block did not use the smoothing pool or the node or the node fee distributor and the last transaction in the block did not go there either. However this version is vulnerable to node operators running their own searcher and extracting MEV without sharing it. ### Strict Rule Set Only blocks from trusted relays are allowed. If none are available, the node operator must not propose a block. Locally built blocks that set the fee recipient to smoothing pool or node fee distributor are no longer allowed. Just as above, this one could be implemented on chain in a post EIP4788 world by providing a proof that the last transaction did not go to smoothing pool or node distributor. This version would introduce a strong dependency on MEV Boost and might lead to slightly lower returns because of missed blocks. Both the loose and the strict rule set are far from ideal. One approach would be to implement both and give the pDAO the ability to switch between the two with a settings change. We could start out with using the loose one and continue to monitor if anyone is exploiting the system and switch to the strict rule set if necessary. The ability to switch might serve as a deterrent in and of itself.
Last changed by  
 
knoshua.eth
124

Read more

RPIP-49 Thoughts

If there is a node operator queue, base validators SHALL be given priority over satellite validators

4/3/2024
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: 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/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
Read more from knoshua.eth
Published on HackMD