Update enr / peer status upon BPO schedule change

[terencechain]

When a new BPO schedule gets activated, a node may want to discover new peers and goodbye old peers if they are on different schedule, we should consider this part of enr or some other fields like statusv2

[raulk]

The main objection to representing BPO forks as forks at the p2p layer ¹ was the potential increase in client-side code complexity. Specifically, the need to replicate the boilerplate typically required for handling forks, which would undermine the purpose of the "express" BPO mechanism.

However, during the May 19th ACDT call, it was proposed this could be addressed by implementing a secondary lightweight code path to handle BPO. This path would intercept or wrap the currently active physical fork, "overlaying" the BPO config on top of it. As per the ForkDigest, we'd "mix in" the digest of the current BPO values in some canonical form (SSZ vector?). This approached seemed to gain quiet consensus.

Benefits of adopting this solution:

• Field reuse in ENR and Status Req/Resp. The ENR's next_fork_version and next_fork_epoch fields can directly reflect the corresponding values from the BPO config, if defined.
• Conceptual accuracy. BPO forks are physically represented as forks at the protocol level, because they are consensus-breaking changes.

Further discussion happening here.

Footnotes

1. In two sites: the ENR record and the Status Req/Resp data structure. ↩

[raulk]

First round of feedback has been gathered on the fork_version solution proposed here: ethereum/EIPs#9818.

Consensus is trending AGAINST representing BPO hardforks as forks in the protocol by assigning them a fork_version and introducing a generic upgrade function that updates the BeaconState on a BPO fork.

Instead, the least contentious solution seems to be to patch fork_digest to overlay current blob schedule metadata. This can be achieved via a bitmask, or by mixing in blob schedule related fields into the preimage of the hash. This mechanism achieves p2p topic segregation and current fork advertisement (via the Status req/resp). Another suggested alternative was to add new BPO fields to the Status response, but that wouldn't roll over topics and would introduce unsafety at the p2p layer (mixture of peers with different validation rules under the same topic).

To solve for the need to signal the next BPO fork the node will follow, there are two proposals:

1. Add metadata about the next programmed BPO fork in the Status response.
2. Add new fields to the ENR (next BPO fork and next BPO max).

The second solution is preferrable, since the ENR record is shared via discv5 and it doesn't require connecting to the peer in order to learn about their next planned BPO fork.

Finally, a few people suggested simply throwing away the need for BPO forks in the CL entirely. This would be achieved by not enforcing a concrete MAX_BLOBS in the gossip validator, and instead bounding to the absolute maximum ever MAX_BLOB_COMMITMENTS_PER_BLOCK, currently 4096, but noting that it could be lowered.

Relaxing this rule was strongly discouraged. In addition to the problems cited above, it's preferrable to continue performing cheap structural checks at the edges of logic (p2p validator) where they incur little computational cost, in order to prevent propagation of payloads that are doomed to inevitably fail later in the EL. We also wouldn't be able to downscore peers who haven't followed (on a parameter downgrade), nor would they be able to downscore us if they didn't follow the fork (on a parameter upgrade). All of this introduces new failure modes that would require deeper analysis, all in exchange for lesser system safety, which doesn't seem like a desirable tradeoff.

[jtraglia]

Closed with this merged PR:

• Modify fork digest to distinguish BPO forks + add entry to ENR #4354