Execution Client 4444s Rollout Plan

Goals: Determine whether the rollout of 4444s should bump the eth protocol version or not.

TLDR: We should probably bump the eth protocol version.

Is the bump required?

Short answer is “No”

The actual message payloads to the eth protocol do not change, and so the the bump is purely anchored to client behavior.

Exploring client behavior

Lets look at what happens in both cases to a client that doesn’t update.

If we do bump the eth protocol version, then the client will remain on the old version of the protocol while updated clients will migrate to the new version. Assuming broad adoption of the new protocol version, clients that do not update will face a diminished group of viable peers. The peers that such a client can find will continue to serve them historical data from pre-merge. Such a client may face degraded performance while attempting to establish reliable peer connections.

If we do not bump the eth protocol version, then all clients will remain on the same version. Clients that update will provide empty responses to requests for historical block data. In connections between updated and not-updated clients there will be requests for historical block data which the updated client does not have. Some clients may choose to implement functionality to disconnect clients that ask for pre-merge data. A client that does not update will see a network of nodes that predominantly do not answer their requests for data and will face degraded performance during sync until they find reliable peers.

Results of this behavior

Both of these seem to result in clients that do not update facing some form of degraded performance.

Not updating the protocol version means that clients that do choose to update will also face data requests for data they do not have from clients that do not update.

Not updating the protocol version also means that clients will have to make subjective decisions about how to treat requests for pre-merge data, such as whether to they disconnect. This client behavior can be well defined if we do update the protocol version.

Conclusion

It seems that there are some mild benefits to bumping the eth protocol version. Specifically, allowing updated clients to have well defined behavior in how they deal with incoming requests for pre-merge data.

Protocol Fragmentation and EIP-7801

There may be some concerns around protocol fragmentation, which I believe are anchored to the idea that those implementing 7801 may want to stay on the old protocol version to enable transfer of pre-merge history data.

Two viable solutions for this would be to:

• Issue those requests over the new protocol version and have clearly defined exceptions to the handling behavior of those requests defined in the EIP-7801 protocol
• Mirror the GetBlockBodies/GetReceipts messages in whatever new DevP2P sub-protocol gets defined for EIP-7801

Both of these can avoid fragmentation of the eth protocol and allow for all clients to move to the new protocol version regardless of whether they implement 7801 or not.

https://github.com/ethereum/EIPs/pull/9087 has updated 7801 to be a fully separate protocol.