(Brainstorming) Anonymous validators: possible options at the p2p level

[nkeywal]

Tldr: what can we do at the p2p level if we want the validators (and may be any node actually) to remain anonymous? Is I2P an option?

There are a few reasons to allow the validators to stay anonymous, i.e. hiding the relationship validator public key <-> ip address:
It allows to DoS them, and possibly censor them.
It allows to hack them, and possibly get access to the private key used to sign the message.
It helps to identify the real person behind the validator, hence the public key, hence the funds who were used to stake.

See #5 for more context. It seems reasonable to say that it will being anonymous will be necessary for some validators at least.

Here are the possibility I see (not exclusive):

• VPN: the usual mechanism. Has a cost & put the trust in the VPN provider, which is not always reasonable (https://www.nbcnews.com/feature/edward-snowden-interview/exclusive-snowden-docs-show-uk-spies-attacked-anonymous-hackers-n21361). Validators can switch from one IP to another if they wish.
• Tor: Tor is not supported by Ethereum v1, because of the dependency to Kademlia/UDP. It’s a known issue (for example: TOR support ethereum/mist#455) We could change that for Ethereum 2.0, as Kademlia is not that much used in Ethereum today. Of course if we add thousands of user nodes to the Tor network it’s going to be an issue (https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf). But it can work if just a few validators are using it. One issue here: QUIC is UDP based, and Tor does not support UDP nor QUIC today (https://lists.torproject.org/pipermail/tor-dev/2018-March/013026.html)
• I2P: This could be a valid option. It was proposed for Ethereum v1 a while ago, but was abandoned. (https://github.com/ethereum/EIPs/pull/765/files). Do we know why? It seems Monero has chosen to rely on I2P, and implemented a C++ version of it (https://getkovri.org). Monero nodes will be I2P nodes.
  Many other possible off-the-shelf options to find and look at (freenet?...)
• Implementing ourselves some parts of the onion protocol, or, more precisely, have a kind of Tor/I2P protocol for Ethereum nodes (i.e. not depending on/using the Tor/I2P network). This could make sense at the libp2p level for example.

None of these options are incompatible. It could make sense, for example, to have nodes on the public ip network & nodes on Tor.

At this stage, I’m wondering about I2P support. Anyone has insights on it? On implementing ourselves some parts of Tor/I2P, the devil is in the details, so it’s easy to under-estimate the final cost of these kind of things. But leveraging the work done (or to be done) somewhere else (libp2p? :-) ) could make sense as well.

[Swader]

I would just like to reference ethereum/consensus-specs#157 as an issue somewhat related to this. It seems like we'll be encouraging people to run their own beacon nodes to be validators, which would mean no amount of privacy on validators will help since beacon nodes must remain "public". An attack on a validator's BN will therefore be equivalent in DoS-iness to an attack on a validator itself.

[Mikerah]

There are several network level anonymity proposals for Bitcoin such as Dandelion++ and P2EP

[fjl]

Leaving pubsub privacy aside for a second and focusing purely on discovery, privacy could work as follows:

There is one discovery topic per shard. proposers register for that topic just like everyone else syncing the shard. Attester nodes don't register and simply look for random shard participants. Proposals are broadcasted by everyone on the shard's pubsub topic and will be received by attester nodes.