[research] What are the privacy needs of current P2P projects?

[gpestana]

It would be very helpful to start understanding what are the privacy requirements and current vulnerabilities of current projects using IPFS, Dat and other P2P networks. This study could be used as basis for new or improved features of existent p3lib modules.

[Mikerah]

Hi There!

I have been following your work for some time and I'm really excited about this library.

For some background, I work on ETH2.0, which is Ethereum's major upgrade to PoS and sharding. I have been working with others for the past several months on various aspects of networking and there has been little talk about using various privacy-preserving primitives in ETH2.0.

As a starter, I looked into potentially adapting Dandelion++ for transaction (or in ETH2.0's case, attestation) sending. However, I quickly realized that in PoS networks, we need some form of long-term identity at the network layer in order to properly penalized misbehaving nodes.

Anyways, it would be great to have your expertise in building scalable, privacy-preserving networks to Ethereum and see what you think of various proposals around networking are.

[gpestana]

Hey @Mikerah! Thanks! That sounds like an interesting open problem. Based on my understanding, Dandelion++ and onion routing (but not Tor) seem to be good matches for enhancing privacy while keeping a long-term identities, since privacy comes from adding noise and plausible deniability instead of changing network identifiers. I need to get more context and read carefully the current Serenity specs, but it seems to me that DHT-based service discovery and the way gossip subscriptions are stored (I believe as a DHT key-value, but will need to double-check) might disclose too much information about validators to curious peers/adversaries. For example, the problem I see with pubsub subscriptions in a DHT in that a rendezvous point (represented as a specific CID) are used to store provider records, one per subscriber. In this case, if I want to learn who is subscribing to a particular channel (say beaconchain-03), I just need do a DHT provider request to the correspondent CID.

We've been entertaining a new idea for privacy preserving DHT lookups and rendevouz points based on centralized and/or decentralized Private Information Retrieval systems. Not sure if this is a good match for your case, but could be. Some rough notes on that can be found here

I'm trying to get more context here, do you have any other pointer suggestions than these: https://github.com/ethresearch/p2p/issues/5 https://github.com/ethresearch/p2p/issues/10 https://github.com/ethresearch/p2p/issues/11 ?

[Mikerah]

Here are the current networking specs: https://github.com/ethereum/eth2.0-specs/tree/dev/specs/networking

We are using libp2p to build out our client and currently have a working implementation of gossipsub: https://github.com/libp2p/specs/tree/master/pubsub/gossipsub#implementation-status

The currently proposed discovery mechanism uses Kademlia's peer discovery table. It's called discv5. However, it's still unclear whether ETH2.0 will also take advantage of Kademlia's content routing capabilities. We are still researcher DHT alternatives since Kademlia would make ETH2.0 for susceptible to eclipse attacks.

There has also been some discussions on using onion routing as well but these are still in the air.