[builder API] Beacon chain health checks

[realbigsean]

Description

Provide some basic configurable chain health checks to determine whether or not we should propose blocks through the builder API.

I'm proposing we add three new flags, each controlling a condition that describes a "healthy beacon node". And if all three conditions are met, the builder API will be used.

• --builder-fallback-skips default value 3
  • the number of slots prior to the proposal slot that have been skipped
• --builder-fallback-skips-per-epoch default value 8
  • the number of slots in the last 32 slots that have been skipped
• --builder-fallback-epochs-since-finalization default value 3
  • the number of epochs since the chain has finalized

Would appreciate feedback on both conditions and defaults 🙂

[thegostep]

This is beautiful. Some questions:

• Why these default values? I the more conservative the defaults are, the more false positives there will be, the more customer support will be needed, and the higher the risk of targeted attacks.
• I like that these checks are on a rolling basis, this allows for the nodes to automatically recover.
• should any of these be standardized with other clients?

[realbigsean]

thanks @thegostep !

Why these default values? I the more conservative the defaults are, the more false positives there will be, the more customer support will be needed, and the higher the risk of targeted attacks.

Definitely open to changing them, but went with conservative values to (hopefully) favor liveness because fallback here still results a proposal which seems most important to me. The proposer still gets block rewards, tx fees, and the network still gets attestation inclusion and a new set of transactions included. False positives aren't ideal but some number of false positives would likely be worth it to save from a missed proposal. I have no idea how high or low this number is though.

I understand default values that are too low could have the effect of making targeted attacks easy enough to pull off that they become more frequent than having no checks at all. Because there's incentive to ensure another proposer doesn't do any transaction ordering. But my hope would be that there is enough diversity in configuration to make these attacks less feasible.. and that the attacks themselves aren't actually that easy to pull off. If they are that easy to pull off, I would worry that setting higher defaults might not actually help prevent attacks, they might just ensure chain conditions are worse when they happen. If an attacker can induce skip slots easily, I also am not sure why they would target fallback from mev-boost vs just inducing an extra skip because they both have the same effect of keeping the next proposer from getting mev.

It seems to me like a bigger risk than a targeted attack (maybe I'm naive) would be a bug in a relay which serves a large portion of the network. And in this scenario lower fallback values seems better generally.

I'm not tied to these defaults in any way but this was generally my thinking.

should any of these be standardized with other clients?

I think implementations should be diverse so we probably don't want to standardize too much. It might make things more difficult to game, and it also might give us better insight into what conditions are helpful/harmful/too high/too low.