Requirements for Portal usage in EL client for history data expiry (EIP-4444)

[kdeme]

Write up of the different parts that an EL client will have to either implement or use from a Portal library or Portal node when using the Portal Network as alternative for history chain data (EIP-4444).

Current status

• Node Discovery Protocol v5 aka discv5 + ENR: Note that this is part of devp2p stack and there is nothing Portal specific to it.
• Portal Wire Protocol: Base wire protocol that all sub-networks use.
• uTP over discv5: Reliable stream protocol for payloads > than discv5 maximum payload.
• Portal History Network

Potentially in the future

If #287 and #291 get merged and thus chosen as solution for validation of block headers as part of the chain post merge, then for the second PR, an additional requirement is added for validation of these block headers:

• Access to the BeaconState.historical_summaries: https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#beaconstate

When using the Portal Network for this, this translates to the requirements:

• Portal Beacon Chain Network: For access to historical_summaries + consensus LightClient objects (see next item)
• Consensus Light Client sync: For access to latest consensus header (roots)

However, an EL/CL combo does have directly access to this, but afaik the EL itself does not. One could for example decide to define an extra engine_api call (or other json-rpc namespace) to push this data to the EL.

Or specifically for the second item, implement the libp2p version of the consensus light client (which I believe some EL clients have).

[acolytec3]

Is fluffy written as a module capable of being bolted on to the nimbus el client? That's what I'm doing in my proof of concept work with the EthereumJS client and ultralight and it seems to work reasonably well so far.

[kdeme]

Is fluffy written as a module capable of being bolted on to the nimbus el client?

Yes, that's the idea. We have an issue open on this (status-im/nimbus-eth1#2147).
I'm first still adding a higher level API though to make it easier to instantiate all the moving parts.

it seems to work reasonably well so far.

Yes, I think thanks to the Portal architecture, libraries/clients will naturally lean into having a modularity that allows for this.
I think one thing to be wary of in the future is when a certain Portal sub-network requires data that potentially can be gathered from another Portal sub-network, to provide an interface for this instead of directly accessing that sub-network.

[GrapeBaBa]

We have encountered such a problem. Although go-ethereum and erigon are both EL developed by Go, and the codes of their p2p packages are basically the same, due to the dependency issues of GO language and the early implementation of p2p, they were not considered to be provided to other projects as dependency libraries. At present, we can only fork one of their projects to develop shisui, and the other project can only be referenced by copying.
A better way may be to extract the p2p package into a public project as a basic dependency library, and similar public packages such as jsonrpc may also be included. However, this may require the EL teams to promote it.