# Validator Privacy Notes from ETHresear.ch

###### tags: `Tag(HashCloak - Validator Privacy)`

Source: https://ethresear.ch/search?q=validator%20privacy

[toc]

## 1. Packetology: Validator Privacy - (06/16/2020)
https://ethresear.ch/t/packetology-validator-privacy/7547

### Written by: https://twitter.com/JonnyRhea

* About the state of Validator privacy linking this post: https://github.com/ethresearch/p2p/issues/5 from 2018 as proof that this has been an potential issue for a while.
* The main reason for the delay in working on research for validator privacy may be that there has not been a proven way to expose validator IP addresses, that doesn't mean it isn't possible though.
* The post tries to answer the question of "What is the simplest way to deanonymize validators?"
* Summary: "Batched deposits resulting in consecutive validator indices running on the same node is a dead giveaway. This can be easily exploited. At a minimum, we should suggest some best practices for splitting keys across nodes."
* From the comments, it seems that this issue could be solved on the client side and signatures disabled to obsure the origin of the messages (as opposed to gossip's initial design/intention.) This sticks out though:
> "Sure, this will definitely work. We could also wall off validating nodes with other nodes and cycle those ips. We could even use Cloudflare to protect us from denial of service attacks, but relying on large scale sophisticated setups just encourages centralization and is a disappointing outcome. ETH2 protected by Cloudflare is not a great message." - https://twitter.com/JonnyRhea

## 2. Sentry Node Architecture Overview - (Cosmos)
https://forum.cosmos.network/t/sentry-node-architecture-overview/454
### Written by: Jack Zampolin
* Is a potential solution for added DoS resistance for nodes without the need for Validator Privacy (VP) just yet.
* The general idea seem to have "Sentry Nodes" spun up on VPS that have a direct connection to the validator during a DDoS attack. These sentry nodes are always available for validator nodes to connect to if needed in the event of a DDoS attack(or can be always roured through to hide IP addresses?)

## 3. Exploring a Hybrid Networking Architecture for Improved Validator Privacy in Eth2.0
https://ethresear.ch/t/exploring-a-hybrid-networking-architecture-for-improved-validator-privacy-in-eth2-0/7207
### Written by: Mikerah**

#### Motivation
ETH2.0 is a P2P network built on top of Libp2p. It uses a gossip-based pubsub algorithm to propagate messages between peers in the network and uses Discv5 for peer discovery.
#### Hybrid P2P Networking Structure
A possible way to remedy this disconnect between state of the art anonymous networking protocols based on a client-server architecture and ETH2.0’s P2P architecture is to consider a hybrid architecture in which ETH2.0 has both client-server and P2P elements.
* We consider an application of such an architecture to increase the anonymity of peers in the ETH2.0 network.

#### Assumptions
In both ideas, we assume the existence of some PKI infrastructure for managing the nodes in their respective ACN design. Note that in any practical deployment, PKI infrastructure needs to be carefully considered and not glossed over.

##### Approach 1: Onion Routing
The first approach we consider is one based on onion routing.
* In onion routing, encrypted messages are sent through a series of proxies and are decrypted (hence onion) at each step.
* The nodes along the path don’t know who the original sender of the message is, just the nodes that are adjacent to it in the path.

**Problems:**
There are several problems with this approach.
1. This increases the latency of a given validator’s message propagation.
2. This technique also increases the bandwidth a given validator might need if it decides to be both a validator and a node in this specialized onion routing network.
* Another issue that arises is that as described, nodes in this onion routing network are altruistic.
* This may become a problem as the network scales and given that Sybil attacks have been observed on real world onion routing networks in the past. Potentially having incentives (rewards and penalties) for maintaining the quality of service of the network is to be determined.
* Finally, this scheme is not metadata resistant and is thus not secure against a global passive adversary.
* This means that validators can still be de-anonymized through traffic analysis, correlation attacks, etc.

##### Approach 2: Mixnets
The second approach we consider is based on mix networks, namely the Loopix design.
* In the Loopix design, there’s 3 components to the mixnet:
* clients,
* a PKI system
* and the mix nodes.
* Further, there is a separate category of mix nodes that are called providers that provide extra services for clients depending on the application.
* The mix nodes are in a stratified topology.
* Path selection for messages are created independently and streams of messages are sent according to an exponential distribution.

A hybrid architecture incorporating a Loopix-based approach is as follows:
1. Have nodes in the network that would serve as mix nodes.
2. Validators would send their messages through the mixnet.
3. The providers at the edges of the mixnet would propagate the message to the other validator nodes.

This scheme’s privacy notions are:
* *Sender-Receiver Third Party Unlinkability:* The sender and receiver are unlinkable by any unauthorized party.
* *Sender Unobservability:* An adversary can’t tell if a sender sent a message or not
* *Receiver Unobserability:* An adversary can’t tell whether a receiver received a particular message

**Problems:** The main issue with this approach is the increased latency needed to send messages, and the need for cover traffic which affects scalability.
* Although the Loopix design provides a tunable tradeoff between latency and cover traffic, the tradeoff needs to take into account the fact that validators need to be timely in their delivery of messages to other peers in the network.

#### Conclusions and Future work
Future work would be to attempt an implementation and determine whether these networks would benefit from in-protocol incentivization for proper quality of service.

From comments, read :
* https://loki.network/
* https://petsymposium.org/2019/files/hotpets/proposals/coordination-helps-anonymity-new.pdf
* https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_winter.pdf

## 4. Considerations for Network-level Validator Privacy in Proof of Stake
https://ethresear.ch/t/considerations-for-network-level-validator-privacy-in-proof-of-stake/6422
### Written by: Mikerah
> In this post, I outline various considerations regarding network-level validator privacy and things to take into account before settling on any particular methods/strategy. I’m looking for feedback on these considerations and more ideas.

#### Overview
Validator privacy concerns itself with masking/obfuscating (or potentially) removing the link between validator’s IP addresses with their on-chain identities. The rationale is to make attacking validators much harder in order to increase the overall robustness of the network.

#### Desiderata
In order to maintain the scalability benefits of sharding and proof of stake, we need to consider how much privacy is necessary (or even possible) in order to determine what protocols would suit the needs of the system.
* **Low latency**: atency has a direct impact on the profitability of being a validator.
* **Low bandwidth**: Bandwidth affects the accessibility of being a validator.
* **Accountable**: If we were to adopt a pure anonymous protocol for validators this can leave the network vulnerable to sybil and other kinds of DoS attacks on the network.
* **Availability favoring**: The current protocol is designed to value availability over consistency.

#### Current Solutions
* **Tor**: It’s the most well-known and well-studied ACN. Moreover, the tooling is there for integration. The main ramifications is it’s effects on latency and bandwith, although it is a low latency favoring network.
* **i2p**: It’s less studied than Tor and has less tooling for it.
* It has been deployed for a long-time and hasn’t been attacked as far we can tell.
* It’s design is also better suited for the p2p nature of ETH2.0’s design as it employs a p2p architecture instead of a client-server architecture.
* **Mixnets**: Provides anonymity in the face of a global passive adversary (think NSA) but none have been deployed for applications other than email/chat. They tend to be low latency and high bandwidth and have a client-server architecture.

#### Open Questions
* **How does using an ACN affect the fault tolerance of the overall network?**
* There has been no work done to see how fault tolerant ACNs are.

* **How does composing ACNs affect the overall robustness of the network?**
* Composing ACNs with orthogonal properties has been proposed in the literature to overcome the anonymity trilemma. However, this hasn’t been done in practice.
* **Given our conditions, what kind of threat model is sufficient?**:
* By the anonymity trilemma, the strongest threat model comes at the expense of having a practical ACN. In other words, if we want validators to be safe from a global active/passive adversary, we would need to give up the requirement of low latency and low bandwidth.

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

### Written by: Mikerah
https://github.com/ethresearch/p2p/issues/11
* Github post by Mikerah - (Brainstorming) An attempt at validator privacy inspired by Dandelion++
* General brainstorming about how to use an idea like Dandelion++ (initially proposed for BTC) to increase Validator privacy in ETH 2.0. Issues with latency aren't as much of a concern in BTC, but with ETH 2.0 low-latency is very important.

## 6. Anonymity: a ZKP to remove the mapping ip address / wallet’s public key of a validator

### Written by: Nicolas Liochon
https://ethresear.ch/t/anonymity-a-zkp-to-remove-the-mapping-ip-address-wallets-public-key-of-a-validator/6049

> Short post about using zk proofs to add another public key to validators to use to receive funds when they want to exit with their 32 ETH + PoS.

With the validators participating on the p2p network, it’s easy (and trivial if you use Handel) to deduce the mapping between validator’s wallet public keys (pk) <–> ip address. Simply track pk’s committee membership over time and compare with the ip addresses actually participating. A few epochs are enough to deduce the one-to-one mapping.

Hiding behind Tor is a good solution, but can be complicated at scale. Tor has also been attacked in the past. We may spend more time of Tor-like solutions going forward; AFAWK Mikerah is already working on this.

* In the comments Mikerah stated:
* I think it’s possible to have:
* 1) anonymous onboarding of validators and
* 2) still be held accountable.
* Indeed, the cryptographic primitives needed for this are currently not efficient. I do have some more thoughts around. I may post something later for feedback.
## 7. Python implementation of the libp2p netwroking protocol - experimental
https://github.com/libp2p/py-libp2p
* Python implementation of the libp2p netwroking protocol - experimental
## 8. De-anonymization using time sync vulnerabilities

### Written by: Alex Vlasov

https://ethresear.ch/t/de-anonymization-using-time-sync-vulnerabilities/7610
* how time-sync vulerabilities (attacks) can aid more sophisticated and/or stealth attacks. If the attacker can adjust the clocks of vulnerable nodes, they could affect their behavior in a noticeable way. This plays into Validator privacy, because by monitoring the network, attackers could figure out which nodes where validator nodes.
> Time shifts of lower magnitudes (several slots) will result in prominent behavior too. I.e. attestation delayed by several slots will be included several slots later (and validator will receive fewer rewards) - that can be determined from block stream.
* If attackers are able to use "time" as a way to distinguish between validators the attack becomes easier to mount and:
> Therefore, the assumption that an attacker can directly control significant portion of nodes leads to a de-anonymization problem which differs significantly from the problem that we discussed here, in the write up. And thus deserves a separate train of investigation. See for example, Packetology: Validator Privacy.

## 9. Against anonymity pool incentives
https://ethresear.ch/t/against-anonymity-pool-incentives/6011

### Written by: Barry White Hat

#### Intro
Recently we have had some interest in mixers. A major problem of mixers is the size of the anonymity set. To maximize the size of the anonymity set. One idea that has been proposed is to provide incentives to increase the size of the anonymity set.

Two forms have been proposed;
1. Force miners to mine rewards directly into the privacy pool.
2. Deposit all the collateral in the mixer into some interest bearing contract and use the interest to reward people propositional to the amount they have deposited.