(WIP) Light client p2p interface

[jinfwhuang]

I created this simple PR to get the conversation going about a p2p approach. As mentioned previously in the thread in #light-client channel in discord, we could very well dismiss this approach after some discussions. Instead, we focus on building a p2p approach based on portal network, and a N-server approach. Regardless, it will be a very useful exercise to think through the input data for the light client.

Copied from the channel's discussion. There are three approaches to the light-client networking:

1. RPC. Clients find the RPC endpoints out of band. The client could optionally use a N server approach to get data input resilience.
2. Extend beacon chain p2p interface. Light client p2p interface is part of the consensus p2p layer. This approach is detailed in this PR.
3. Portal network. A light client joins portal network subnetworks that are particular to beacon chain light clients.

[dapplion]

In current beacon chain gossip channels that include aggregate-able objects, a SelectionProof is required to prevent too many distinct yet valid messages from being propagated.

In a naive implementation of a LightClientUpdate gossip channel, an attacker could craft 2**512 - 1 valid LightClientUpdates with different combinations of the signatures. There must exist some mechanism to limit that.

[jinfwhuang]

In current beacon chain gossip channels that include aggregate-able objects, a SelectionProof is required to prevent too many distinct yet valid messages from being propagated.

In a naive implementation of a LightClientUpdate gossip channel, an attacker could craft 2**512 - 1 valid LightClientUpdates with different combinations of the signatures. There must exist some mechanism to limit that.

This is a valid concern.

Introducing a mechanism akin to "aggregation selection" might be too intrusive. Unlike validator participants, we don't know the set of light client participants. Light client topics participation should be very loose. The servers should be treated as anonymous nodes, coming and going without getting assigned responsibilities.

One cheeky way to ensure that the channel does get spammed is to introduce a deduplication mechanism. Every LightClientUpdate message is deduped/filtered before they are sent to the pubsub channel. For example, here is one way to dedupe LightClientUpdate objects according to the following rule

def select_update(update1, update2) -> LightClientUpdate:
    assert(update1.attested_header == update2.attested_header)  # Otherwise, they are considered distinct
  
    bit_count1 = sum(update1.sync_committee_aggregate.sync_committee_bits)
    bit_count2 = sum(update2.sync_committee_aggregate.sync_committee_bits)
    if bit_count1 == bit_count2:
        as_big_endian_int(update1.sync_committee_aggregate.sync_committee_bits) > as_big_endian_int(update12sync_committee_aggregate.sync_committee_bits):  # This is the tie breaker
           return update1
    elif bit_count1 > bit_count2:
        return update1
    else:
          return update2

Each node will run this dedupe mechanism. Each node will relay a new update of the the same attested hash only if the update has "improved" from the previous version that it saw.

[etan-status]

This is not bullet proof, as the same SyncCommittee may be selected for multiple sync committee periods.

[jinfwhuang]

That is a great observation. In that case, the key must include information about sync period as well.

[dapplion]

Should this PR be closed? Spec already well defined in https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/light-client/p2p-interface.md