Gossipsub: randomize peer id to avoid trivially linking validator to libp2p transport information

[arnetheduck]

With regards to ethereum/consensus-specs#593

Gossipsub messages are signed by the peer id / peer public key (libp2p/specs#140), meaning it's possible to link an attestation to a peer id, and therefore trivially lookup transport details of a validator.

@raulk:

The peer ID is a hash of the public key. If you’re using a recoverable signature, you should be able to match on pubkey, but once you have the pubkey, the conversion to a peer ID is trivial

[raulk]

Note that if the node does not participate in the discovery protocol, or it does not participate with that ID, it should not be lookable.

In other words, a validator can sign the pubsub message with its validator key without publishing their presence in a discovery system.

A node could also have multiple identities, and to mask the origin site of a pubsub message, a validator could sign the message with its validator privkey, but publish it to the topic under a different identity.

[cheatfate]

@raulk Ethereum2 uses BLS12-381 elliptic curve for signature/verification purposes and LibP2P uses ED25519, SECP256/384/521r1, SECP256k1 (all of this curves are not pairing-friendly).

[jannikluhn]

Messages can be optionally signed, and it is up to the peer whether to accept and forward
unsigned messages.

Signing seems to be optional, can't we just disable it?

[arnetheduck]

Signing seems to be optional, can't we just disable it?

sure - but then all clients must do the same, and forward unsigned messages.

if messages are not signed, one can not use blacklists to control spam, so we must also implement rules for forwarding only "good" messages (#122) such that spam is contained.

[cheatfate]

Gossipsub message has PeerID and peer's signature and peer's public key stored if message signature is enabled. And this signature is useless without proper peer identification, but this peer identification must be done in custom validation procedure, which is not protocol default.

Custom validation can be done by query DHT for message's PeerID to be sure that PeerID can be found in network. Without such validation gossipsub's PeerID, Peer's public key and signature can be forged without any problems. Nobody can validate your message until it will not perform DHT lookup for message's PeerID.

Using this fact we can make validator's anonymous inside of gossipsub network.

To preserve privacy of validator nodes we need to implement on of the follow approaches:

• Do not use PeerID and Peer signature in gossipsub messages.
• Give application ability to forge PeerID and Peer signature for every message it publishes to network.

Because every Ethereum2 node will have registry/list of all validator’s public keys, every validator who publish new message must sign it with its own private key. Every message also needs to include the validator index, which is all you to recover the public key.

To check if message is valid, every node, which participates gossipsub network and working as relay for gossipsub messages, must check if message’s public key are in the validator’s registry/list and properly signed. If everything is fine it can retransmit message further. Otherwise message must be dropped.

The only problem in this scheme, that other nodes which are not validators must participate in the same gossipsub protocol topic, in such way nobody will know who was message originator, otherwise malicious node can subscribe validator's topic and obtain all the validator's real PeerIDs and addresses by just simple call to gossipsub.getPeerList(topic).

[arnetheduck]

this is being solved in vacp2p/nim-libp2p#372 and libp2p/specs#294