Gloas: initially valid bids can be made invalid by application of the parent payload

[michaelsproul]

In the case where a builder exits in the payload of slot N, their bid(s) for slot N + 1 which were validated against the state at slot N (sans payload N), can become invalid by the time of block processing for slot N + 1 (due to the exit).

This is similar to the issue with packing voluntary exits, which can be invalidated by EL exits in the delayed payload:

Note: Because execution request processing is deferred, a request in parent_execution_requests can invalidate a voluntary exit in the same block. For example, a withdrawal request for a validator will cause a voluntary exit for the same validator to fail, invalidating the entire block. When selecting voluntary exits to include, proposers must take heed of this interaction.

From: https://github.com/ethereum/consensus-specs/blob/v1.7.0-alpha.14/specs/gloas/validator.md#voluntary-exits

I believe a similar note for the bid itself is required, else proposers risk committing to a bid which is invalid once applied. This issue applies somewhat to gossip as well, so an alternative fix would be for gossip validation to take into account the side-effects of the parent payload (when building on Full).

[michaelsproul]

Concrete example from Codex 🤖

---

Exits still provide a concrete accepted-then-invalid example. The withdrawal is delayed, but deactivation is immediate.

Consider epoch 100, slot N + 1:

• Builder B is active:

  • deposit_epoch = 90
  • finalized_checkpoint.epoch = 99
  • withdrawable_epoch = FAR_FUTURE_EPOCH
  • balance = 2,000,000,000 Gwei
  • no pending payments or withdrawals

• B bids 500,000,000 Gwei, leaving the required 1,000,000,000 Gwei minimum.

• The full payload belonging to parent block N, built by another builder, contains an authorized BuilderExitRequest for B.

Gossip validation at slot N + 1:

1. Loads block N’s post-state, where the exit has not yet been applied.
2. Advances it to slot N + 1.
3. Sees B as active and able to cover the bid.
4. Accepts and caches the bid.

When processing the proposal at slot N + 1:

1. process_parent_execution_payload applies the exit request first
2. initiate_builder_exit sets B.withdrawable_epoch = 100 + 64
3. Although withdrawal remains delayed until epoch 164, is_active_builder immediately becomes false because it requires withdrawable_epoch == FAR_FUTURE_EPOCH
4. process_execution_payload_bid consequently rejects with BuilderNotActive (note: Lighthouse error variant name)

[jtraglia]

Hey Sproul, we made this PR on Friday to fix this:

• Reject bids from builders exited by the parent's payload #5580

[michaelsproul]

Oh nice! I had missed that!

[jtraglia]

Merged that PR!