(Brainstorming) An attempt at validator privacy inspired by Dandelion++

[Mikerah]

Here, I outline an approach that is based on Dandelion++ (an easier version to understand can be found here), which is targeted for the Bitcoin network. I have made amendments in an attempt to make this relevant for ETH2.0 networking requirements. Note that most likely none of the privacy guarantees from Dandelion++ will be transferred over to this proposal and is mainly a part of the brainstorming on p2p privacy in ETH2.0

If there are any issues with some of the assumptions I have made, please leave a comment! I am in the process of gaining experience in this field and I am fully aware that I might make a lot of naive assumptions. Also, sorry for the lack of structure. Writing isn't my strong suit.

The adversarial model that I am going to assume is the same put forth in the Dandelion++ paper. It will be restated here for ease of understanding.
The adversarial model is as follows:

• A botnet can establish an arbitrary amount of outbound connections to nodes and can corrupt any node (Beacon node, validator node, etc) in the network
• A botnet is trying to connect validators' actions to IP addresses.
• Any adversarial host cannot influence an honest node to create outbound connections.
• All adversaries log as much information as they can about the state of the network e.g. timestamps, attestations, control packets,etc

The Dandelion++ protocol works in 3 phases:

• A random subgraph of the underlying P2P network topology is selected. This subgraph is known as the anonymity graph. In Dandelion++, it is an approximate 4-regular graph.
• Stem phase: During this phase, a peer sends pseudo-randomly selects 1 peer to send a message to. Once a message is relayed to another peer, that peer does the same thing and relays the message to another pseudo-randomly selected peer. This path is on the anonymity graph.
• Fluff phase: When the stem phase ends, the last peer to receive the message now, using diffusion, broadcasts the message to all the other nearby peers.

Note that not all nodes would need to adapt the above approach in order to take advantage of some of the privacy guarantees.

The main issue with the Dandelion++ protocol is that it increases latency in the p2p network. For a cryptocurrency like Bitcoin, where it takes on average 10 mins to create a block, this might not be an an issue. However, for ETH2.0, where block creating is done within seconds, this is going to be a serious issue.

Currently, the networking in ETH2.0 is based on a pubsub system called gossipsub. All the shards are topics and nodes can subscribe to a particular topic i.e. shard in the network. Validators are pseudo-randomly assigned to shards by the beacon chain. Thus, upon being assigned to a shard, a validator must subscribe to that shard in order to receive messages related to that shard. Similarly, if it wants to publish to that shard.

One way to apply a Dandelion++-like approach is to apply the first 2 phases of Dandelion++ before applying gossipsub. So, route messages through a randomly generated anonymity graph then route messages using the gossipsub protocol. Doing this would make it harder for an adversary to discover the source node of the message but they could find the node that did the actually spreading of the message to the rest of the subscribed nodes. This method provides a way to obfuscate the source of a message. Depending on how much privacy at the p2p level is acceptable, this may be enough.

[jannikluhn]

Interesting approach! It sounds similar to onion routing protocols, but it's probably easier to implement and more resilient because paths can be generated on the fly (disclaimer: haven't read the paper yet).

For this to work reliably though, the anonymity graphs cannot span multiple shards. Otherwise, messages will likely end up at nodes that have no connections to peers from the target shard and gossiping from there would fail. This probably reduces the anonymity as shard networks can be quite small, but I'm unsure to what extent.

This also means that potentially a single node on an anonymity graph can drop messages (just a small fraction, but those with a perfect success rate). And as a result, sybil attacks as discussed in #6 become cheaper. I guess to counter that one can send the same message via multiple paths (at the cost of some bandwidth and anonymity).

It may be interesting to simulate this (e.g. using Wittgenstein) to explore all these different trade-offs (and also compare it to plain gossiping which also gives you some amount of privacy).

One small modification that would make sense is to let nodes on the stem decide probabilistically if the stem phase should end or not (instead of using a fixed hop count). Then not even the first node knows the validator.

[Mikerah]

With your expertise in writing these types of simulations, how do I go about doing so myself?

[jannikluhn]

The simulations I've done so far were implemented using the OOMeT++ framework. I'm not sure I can recommend that though as it's not very convenient to use and it's a bit dated. So I'd suggest to first look into Wittgenstein (even though personally I haven't worked with it yet), considering that it was specifically designed for these kinds of simulations.

[rairyx]

Hi @Mikerah I'm working on a Dandelion++ implementation on libp2p's gossipsub, it's built for an anonymous distributed message broadcasting network called Raven. But I think it might be useful for transaction and validator privacy in Eth2.0 too.
I'm wondering how did the simulation go? I'm thinking of doing a simulation/integration testing for the implementation.

[Mikerah]

@rairyx I haven't had the time to do a simulation. However, I did have a chat with Giulia Fanti, the lead author of the Dandelion++ paper. She said we need to be careful about the degree of the overlay mesh and thus how we compose both protocols.

[Mikerah]

@rairyx Upon skimming the code, it seems like the changes aren't too major. In order to get more eyes on it, I will try to add to the libp2p pubsub spec and see if there are other issues that might appear.

[rairyx]

Thank you very much for your feedback @Mikerah. Do you mean the degree of gossipsub's overlay mesh?
I will try to add to the libp2p pubsub spec
Can you explain a little more?
It's almost done, what's your thought about testing?

[rairyx]

One more question about Dandelion++, for stemming phase anonymous graph, is line graph better than 4-regular graph as the Dandelion++ paper mentioned for better unlinkbility?

[Mikerah]

Can you explain a little more?

If we wanted to use this in Eth2.0, it needs to be specified so that other clients can implement it unambiguously in their respective programming languages.

is line graph better than 4-regular graph as the Dandelion++ paper mentioned for better unlinkbility?

This depends on the tradeoffs the system designers want to make. If transaction linkability is an important concern for the system in question, then one should use a line graph for the stem phase. Otherwise, using an approximate 4-regular graph provides enough privacy guarantees. I would say that for your PoC, maybe make it modular so that anyone can decide what they want to use.

[rairyx]

Thanks for your answer. I wonder for 4-regular graph, does it mean a node has to have 4 or more peers?

[Mikerah]

does it mean a node has to have 4 or more peers?

It means that a node accepts/chooses 2 incoming connections and 2 outgoing connections. This is done by the node at the beginning of an epoch.

[rairyx]

Thanks

[unixpi]

@Mikerah current thoughts on whether this is this still an avenue worth pursuing?