Update EIP8025 p2p protocol

[frisitano]

Description

• Remove changes to Metadata and GetMetaData. We deprecate these modifications to prevent potential future conflicts with the core protocol.
• Introduce ExecutionProofStatus rpc, which can be used to communicate the latest block and slot that the peer has received and verified sufficient execution proofs for to be considered valid. This is used for peer selection in the sync protocol.
• Introduce ExecutionProofsByRange rpc, which can be used to sync a contiguous range of proofs from a peer. Often useful when initially connecting to a network / filling large gaps.

[kevaundray]

cc @nalepae re ExecutionProofStatus

[kevaundray]

Not a request for change, just an observation: This allows count == 0, which seems consistent with DataColumnSidecarsByRange

[kevaundray]

Perhaps we write a short note on why this allows us to not need Metadata?

[frisitano]

Do you mean adding context to explain why we don't include it in the Metadata rpc? Makes sense to me. If we add this, we can also mention that for the mandatory proofs hardfork, we will deprecate this type and integrate the inner data into Metadata.

Will wait for guidance from @jtraglia if this note aligns with spec standards.

[kevaundray]

Do you mean adding context to explain why we don't include it in the Metadata rpc?

yep exactly

Will wait for guidance from @jtraglia if this note aligns with spec standards.

sounds good ser

[nalepae]

The byRoot request contains a proof_types parameter.
This is not the case for the byRange request.
Is it on purpose?

[frisitano]

The byRoot request contains a proof_types parameter. This is not the case for the byRange request. Is it on purpose?

Yes, it was intentional. The idea is that ByRange should be used to sync large ranges of proofs for which the client has no proofs. On the contrary, ByRoot should be used to fill gaps where the client has some proofs but not a complete set.

What do you think about this? Does it sound reasonable?

[kdeme]

In case a node does not have EIP8025 enabled, MUST the node not register this protocol and thus not respond on this request?

Basically, what replaces the current GetMetaData v4 execution_proof_aware field to denote a node is not running optional-proofs.

[kevaundray]

Yep exactly -- so if a node doesn't register this protocol, it means they don't support 8025

[frisitano]

The baseline assumption is that a peer does not support this protocol. If the peer signals support via "eproof" key in their ENR then this implies that they do support the protocol. Only the peer initiating the connection has visibility of the other peers' ENR. This creates an information asymmetry: the peer initiating the connection knows the peer supports eproof, but the peer receiving the inbound connection request does not, because it cannot see the peer's ENR. To address this asymmetry, the node initiating the connection MUST invoke the request upon connection if it also supports execution proofs.

[kdeme]

The baseline assumption is that a peer does not support this protocol. If the peer signals support via "eproof" key in their ENR then this implies that they do support the protocol.

Yes, that makes sense. But should we not explicitly add that somewhere in the specs?

To address this asymmetry, the node initiating the connection MUST invoke the request upon connection if it also supports execution proofs.

So should we add something like this or similar:

"The dialing client MUST send a ExecutionProofStatus request upon connection when optional execution proof–aware."

[frisitano]

Good point, yes, I think that's a good suggestion I will add it.