# Consensus layer Block proposal privacy using Dandelion and RLN, high level overview (TL;DR form)

- Validator privacy is of big concern for the consensus layer. Currently privacy on network level is ensured by using "no-sign-policy", as well as striping the origin related fields for the originating consensus layer gossipsub message. This can be problematic and the validator privacy can be breached by network metadata analysis attacks.
- A way to increase privacy, and to make it harder to breach the publisher-message unlinkability is the validators to propagate the messages through multiple beacon nodes. This is possible because the consensus messages are idempotent. The downside of this approach is that more pressure is added to the network (because of message duplication) and also the publisher-message unlinkability is not guaranteed, it just makes metadata analyis attacks harder (we do not claim that our solution leads to guaranteed properties, but we do claim that it is better than existing solutions).
- A constraint to keep in mind are the consensus layer rules - more specifically the latency related rules. Not respecting the latency rules can have big negative impact on the network as a whole, as well as individually for each validator. Latency constrains mean that there is a specific time window within a slot at which the validator duties should be performed (block proposals, attestations, etc). Not performing the validator duties on time will have negative impact on the validator, depending on the duty and other consensus layer rules.
- Another constraint we need to deal with is that we can't change the Ethereum consensus layer rules. This is because of the inner dependencies of the fields/structures defined in the specification, as the fields/structures and algorithms are proposed as they are for a reason. For example removing the `proposer_index` field can have protocol wide implications.
- What we need is a way to obfuscate the message publisher and to ensure publisher-message unlinkability. Because of the constrains we need to consider an external solution, something aside of the consensus layer protocol. Additionaly because of the latency constrains, we have limitations on what kind of solution we can use, and to which extent. The latency constrains are tight, but there is still a space for experimentation.
- Given these constrains we must find the optimal privacy solutions, which will not degrade or have any negative consequences on the network. This means that the solution offering maximal privacy for all scenarios without any assumptions is infeasible, because currently the setup to establish such privacy is expensive in terms of latency and thus infeasible for our usecase.
- The solution we propose is adding an extra step, before the consensus messages are propagated to the network. This step is a anonymous pre-network, through which the consensus messages are sent first, in order to obfuscate the sender. This network will be implemented using the solution proposed in the Dandelion++ paper. In fact, the Dandelion method will be embedded to the gossipsub protocol at the p2p networking layer.
- The network participants will be the validators of the beacon chain. However because this network is anonymous, it's succeptible to spam attacks. To prevent this, RLN should be implemented to the network as a construct which provides spam resistance in anonymous environment. Thus the validators that need to participate in the network, must register themselves to a RLN smart contract. The validators that spam the anonymous network will be slashed and removed from the private network. This does not mean that the validators will be slashed from the consensus layer - it will just mean that they would not be able to join the private network again, thus their consensus layer messages will be broadcasted directly.
- What we propose is starting with only adding obfuscation to the block proposal messages. Other types of messages (attestations, etc) shall be propagated as they currently are, without any obfuscation. This is because the block proposal messages are rare (in comparison to attestation) - only one per slot compared to many more other type of messages. The RLN proof and Dandelion network propagation takes time. Because of the message quantity to the Consensus layer network, although small the validaton time will have big impact on the other network messages. Under normal network conditions, there is some spare room for block proposal latency, which we can use to generate the RLN proof and perform the network obfuscation. Wether this time is enough, will be seen after practical experiments are concluded. After the initial implementation we have an opportunity to work on parameter optimisation, especially on the ZK-Proof side of things.