Gossip recently computed light client data

[eserilev]

Gossip recently constructed light client data when POST validator/contribution_and_proofs is called

i've chosen this endpoint, because its already publishing data to the network, it's called at every slot for validators in an active sync committee, and a POST seems like the better method to trigger publishing data to the network vs GET

Keep track of the latest broadcasted finality and optimistic updates. That way, even if the POST validator/contribution_and_proofs endpoint is spammed with junk data, we'll only gossip the same finality/optimistic update once.

[dapplion]

Is this part of the spec? This way the entire network will broadcast the updates at once

[eserilev]

agreeed that it seems very wasteful for everyone to broadcast light client updates at once. The spec doesnt seem to mention how this should work, I've reached out in the light client channel on eth r&d discord for further clarification

[eserilev]

Etan has suggested that we restrict the initial light client data publishing to the current sync committee. I think that sounds reasonable to me, but it would require introducing a new beacon api endpoint. I'll work on speccing something out.

[michaelsproul]

Why do we need a new beacon API? Could we implement something based on the existing sync committee subscription API? e.g. only publish if we have received a sync committee subscription in the last N epochs.

I think we could get that info from the NetworkService which processes the sync committee subscriptions, or by hooking into the existing HTTP handler. Hooking the HTTP handler might be cleaner, as the network code mostly uses channels to communicate so I'm not sure if we should be reaching into it to read info.

[eserilev]

yeah, you're right, we don't need a new beacon api, I think overloading one of the http endpoints makes the most sense