# mev-boost circuit breaker proposal

## what?

the merge supports an "external builder network" where proposers can work w/ specialized actors to get execution payloads skillfully crafted to maximize validator rewards.

these specialized actors have the responsibility to ensure the availability of the execution payloads they build and if they fail in this responsibility it will look like the proposer failed to propose a block from the protocol's point of view.

this failure mode -- a "liveness" failure -- should be prevented at most costs as it means less transaction throughput for users and an overall reduced quality of service.

there are several mitigations for this type of failure and this proposal specifies a "last resort".

specifically, **users of the external builder network will implement a "circuit breaker"** (random resource for more info: https://martinfowler.com/bliki/CircuitBreaker.html) using globally available inputs (simply, the chain) to decide if they should make a local decision to stop using the external builder network.

there are ongoing efforts at other places in the protocol stack to tolerate "soft" failures (e.g. one missing proposal due to intermittent network degradation) including a monitoring and reputation system that should incentivize high-quality operation of nodes on the builder network (and so minimize liveness failures).

## how?

the decision to use the external builder network depends on CL configuration (and is thus implementation-dependent) and we will assume the *beacon node* software has the ultimate authority to implement policy here. CL implementations generally have a separate *validator client* that drives requests for block production and based on the configuration will either use the external builder network or prefer their local EL node to construct execution payloads.

this proposal then suggests that regardless of which pathway the validator client uses, **the beacon node will force all execution payload construction requests to the *local execution client* after the circuit breaker condition is met**.

### circuit breaker condition

|Name | Value | Units |
| -------- | -------- |-------- |
| MAX_ALLOWED_MISSING_SLOTS | 5 | slot(s) |

beacon clients will keep an online running tally of the total number of "missed" slots since the last valid proposal. if this quantity exceeds `MAX_ALLOWED_MISSING_SLOTS`, then any requests for a remote execution payload will be forcibly routed to the local execution client.

**note**: clients should count all blocks in the block tree at a given slot, even if not on the canonical chain. otherwise, a reorg'ing adversary could trivially disable mev-boost. thank you @terencechain for pointing this out.

### recovery condition

for simplicity (and a bit as a strawman example), this proposal suggests that the circuit breaker can only be triggered once and cannot be reset automatically.

the only way to reset the state is to restart the beacon node where the aforementioned missing slots tally will be 0.

# notes

this spec is very simple as it would be nice to have something implemented before the merge ships soon(tm).

we can easily imagine more complex policies around the circuit breaker condition and the recovery condition (e.g. online recovery that does not require a hard restart).

consider this document a contribution to get the conversation started.

# other resources

@realbigsean suggests a broader set of circuit breaker conditions here: https://github.com/sigp/lighthouse/issues/3355

thanks to @terencechain for bringing to my attention :)