Add an Eventsream endpoint

[Ktl-XV]

tl;dr: Implement the equivalent of Beacon API Eventstream

There is an issue in Glados to measure content propagation latency in the portal network, this is particularly relevant to the goal of serving tip data on Portal.

Using https://lab.ethpandaops.io/beacon/slot/live?network=mainnet as inspiration on how this could look down the line a similar approach can be used.

EthPandaops uses Xatu to collect and process the data from their own nodes and also nodes from the community. The data flow looks something like this:

graph LR;
    nodeA[Beacon Node] --> sentryA[Xatu Sentry*];
    nodeB[Beacon Node] --> sentryB[Xatu Sentry*];
    sentryA --> pandas[EthPandaOps];
    sentryB --> pandas;
    pandas --> pipeline[Data Pipeline];
    pipeline --> viz[The Lab Visualization];

Loading

• Fun fact: most of the complexity (it is relatively simple) of Xatu Sentry is logic to measure and fix clock offsets

A possible future approach can be to add Portal support to Xatu, and also collecting data from community nodes, but for the time being the proposed data flow is the following:

graph LR;
    trinA[Trin Node] --> glados[Glados];
    trinB[Trin Node] --> glados;

Loading

Currently Glados calls Portal nodes when making audits and census. Since measuring content propagation latency is out of scope for Trin (and all Portal clients), gossip events should not be stored in Trin, but just sent to Glados which can store them and do the computations to measure latency. Given this a Push approach makes more sense than a polling one

Xatu gets data from Beacon Nodes using the Beacon API Eventstream which uses Server-Sent Events (SSE). It appears that there were no strong opinions when selecting this technology for the Beacon Streaming API protocol.

Using SSE will make it easier to eventually add Portal support to Xatu and make it easier for other Beacon API clients to use Portal. The downside for Trin is that jsonrpsee does not support SSE, which means having to break the jsonrpsee abstraction and using hyper directly.

For the first iteration only the OFFER events would be available in the Eventstream API

[KolbyML]

I need to read more into this, I wonder what the justification of an event stream was for the Beacon Chain? I am assuming the complexity was justified for the Validator Node which requires the https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi/eventstream eventstream endpoint.

If glados is the only piece of software that would use something like this, I am not sure the complexity is justified. Expressively as EL's to my knowledge don't support an endpoint like this.

My potential concerns are

• could this affect performance
• is the complexity justified?
• how much complexity does this add.

We already have a event's system which could be exposed/reused for this endpoint https://github.com/ethereum/trin/blob/master/crates/portalnet/src/events.rs

But this events provider in Trin has never really been used to date, the code has been added but has been practically abandoned. There was idea's of using an eventstream like you are proposing now like 2 years ago at the Portal Boulder Summit as a way to debug the network, and I think https://github.com/ethereum/trin/blob/master/crates/portalnet/src/events.rs was the outcome of that.

So I am not sure, I do have concerns, they may not be a problem. I would be interested in what others think @morph-dev

I do know that we want to be able to handle massive tons of offer's very fast, so it might be hard/bottleneck if we had to send all these responds to an http eventstream. The JSON-RPC is already extremely slow compared to using Trin directly as a library.

Anyways what do you think?

[Ktl-XV]

Thanks for the response.

For CL clients the eventstream is afaik also used by block builders and relays. EL clients have the eth_subscribe method which instead of using SSE uses an RPC subscription over websockets/ipc.

With Ephemeral Headers implementing the eth-subscribe method might make sense to allow a client to monitor transactions of certain addresses, or new blocks in general. If this method is implemented offer could be a subscription type, lowering the complexity added to Trin that would only be useful for monitoring.

If implemented right I think the performance penalty should be proportional to the amount of opened subscriptions, so users focused on performance should make fewer (or no) subscriptions.

On SSE vs RPC: SSE is higher complexity, but might also have better performance since a single subscription can be used for all event types. RPC would likely be easier to implement (especially with the portalnet events), but requires a separate connection per event type.

I have no opinion on if the complexity is justified, they are a monitoring tool, which are especially useful when bugs happen and nice to have if everything is OK. They could also help showcase the u

An alternative that was proposed is to use logs to measure content propagation latency, From experience, this works for a small number of nodes, but this scales very poorly, might get expensive and also adds complexity downstream, because logs might have an undocumented breaking change, and also are not standardized across clients (if eventually we want to monitor other clients).

To get an idea of the volume, what is the rate of offers?