# RPIP-49 Thoughts ## RPIP-42 > The protocol SHALL be able to penalize stake at the node level I think this needs to be more specific. As is, this puts the burden of concrete implementation on the team/kane. --- > If there is a node operator queue, base validators SHALL be given priority over satellite validators - Do we have to worry about people being stuck in queue indefinitely as we saw with full minipools in the past? - This is a sybil incentive. Why are base validators only allowed < `base_num` ? Similar logic to [RPIP-28: Deposits Under the Minimum](https://rpips.rocketpool.net/RPIPs/RPIP-28) applies here, but with node level penalties we have increased interest to not create sock puppets. - If we were to allow more base validators, do we want to enable base -> satelite migration? --- I think considerations that lead to choosing 4 and 1.5 ETH and motivation behind base > satelite under NO queue should be explained in the RPIP directly eventually ## RPIP-44 > `expected_credit_from_exit`; this represents the amount of ETH the NO expects to receive as their share from validator exits that have begun but not yet completed > - The procotol SHALL update expected_credit_from_exit when exits are begun or completed How does this work in cases of slashed validators? Is impact of correlated slashings ignored? ## RPIP-46 - [RPIP-33: Implementation of an On-Chain pDAO](https://rpips.rocketpool.net/RPIPs/RPIP-33) calls for formation of a security council and defines some initial powers. These powers are exclusively related to "pausing the protocol" by enabling/disabling various aspects: - deposits for rETH - bond reductions - balance and reward updates - node registration - creation of new minipools - auctions - It appears that the Security Council is meant to intervene quickly in cases of active exploits or known bugs. RPIP-46 expands this role to one that is supposed to make decisions about economic state of the protocol. - I'm a bit worried about this, especially because Security Council members could be selected before passing of this RPIP, not giving voters a chance to select adequate candidates. --- > Because this involves voters modifying voter_share, there is an acknowledged conflict of interest here. As a result, changing the voter_share heuristic SHALL require a supermajority vote with at least 75% of the vote in support of any change. - How is the supermajority helping? In cases of >85%, voters are supposed to lower `voter_share`, the self-interest would be to not lower in this situation, requiring a higher majority appears worse in that scenario. - Note also that there might be disagreement about the correct sizing of an increase/decrease and a higher majority requirement increases the chance of a stalemate. - Alternative: guardrail that only allows increasing of `voter_share` if we are below the target --- - We have to specifiy how variable shares interact with NOs claiming rewards at discrete times. ## RPIP-50 This seems quite different than burn in a few ways: - Assuming we just keep doing it indefinitely, there is a divergence over time where LPing has less and less impact as liquidity accrues compared to burn - The contract being upgradeable means the subset of RPL holders that have voting power can repurpose or redistribute te value at any time. Therefore and contrary to burn it can not be viewed as value going to RPL holders without voting power
Last changed by  
 
knoshua.eth
44

Read more

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
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
Read more from knoshua.eth
Published on HackMD