mev-boost
mev-boost copied to clipboard
flashbots
Security Risks for Existing Validators?
What are the main security risks for a validator to consider before implementing mev-boost on mainnet?
From my short time researching, it appears that with the current design of using a builder, relay, validator, the validator can be slashed from the relay trivially. Is that accurate or am I misunderstanding it only as a penalty offense such as a missed proposal instead of a full 16ETH slashing?
This is incorrect -- slashing would only occur in the case of double-signing, which is not a risk that using the external builder network poses. See also https://www.bloxstaking.com/blog/ethereum-2-0/understanding-eth2-slashing-preventative-measures/ for more about slashing.
This is incorrect -- slashing would only occur in the case of double-signing, which is not a risk that using the external builder network poses. See also https://www.bloxstaking.com/blog/ethereum-2-0/understanding-eth2-slashing-preventative-measures/ for more about slashing.
Interesting answer. Its hard to believe MEV Boost does come without any risks. For every software module there are risks, known risks and unknown risks. I think there are some possibilities to get rekt by this implementation but time will tell. Would be great for more analysing what could go wrong. Slashing is not only in case of double-signing, there are some more circumstances to get slashed for misbehaviour in proposing (wrong) blocks.
@ChuckNorrison you can find the first audit of MEV-Boost here. I tried to add specifics of what the validators making use of MEV-Boost are assuming and what type of behavior could introduce risks to the validators.
Slashing is not only in case of double-signing, there are some more circumstances to get slashed for misbehavior in proposing (wrong) blocks.
In the current specification, relayers are the actors in charge of validating that blocks coming from builders are valid. Validator client implementations could also validate that the blocks received are valid before including them in the canonical change.
The reason I bring up this question is due to this topic discussion on ethresear.ch
https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177
What is the maximum damage that a malicious relayer could cause after a validator returns a signed header?
Slashing is not only in case of double-signing, there are some more circumstances to get slashed for misbehaviour in proposing (wrong) blocks.
@ChuckNorrison a proposer cannot be slashed for an invalid block, they can only be slashed if they sign two valid but otherwise different blocks
and for those reading the condition that you do not sign two conflicting blocks would (and should) be managed outside the mev-boost software
What is the maximum damage that a malicious relayer could cause after a validator returns a signed header?
the only thing they could do at this point to cause any damage is withhold the execution payload the proposer is committing to via the signing of the header