Viable Ethereum Node Operation Mechanism
In this post we will go over the importance of validators on the Ethereum Proof-of-Stake consensus layer, the current state of their privacy and why it is important for these entities.
Additionally we will go deeper into describing the current threats and attack vectors, as well as the compromises made that enable these threats. The compromises are tightly correlated to other parameters, crucial for correct functioning of the network - such as network latency. We will also describe these parameters and their role of being bottlenecks for improving validator anonymity.
To overcome these issues, we analyse a potential solution which involves creating a private pre-network using
.We describe the potential implementation in detail, the current development details as well as it’s overall impact on the network.
At the end we present our insights from this analysis and come to a conclusion why the proposed potential solution with sufficient guarantees is feasible for the Ethereum consensus layer.
Introduction
Note: It is expected that the reader has a high level understanding of the Ethereum Proof of stake consensus mechanism.
In Ethereum’s Proof-of-Stake consensus layer, validators are entities that are responsible for bringing the network to a consensus and to a finalized state. To become a validator, one must stake a fixed amount of Ether (32 Ether currently), which is necessary for the security of the network - but also necessary for disincentivising the validator for performing malicious actions, which would contribute for preventing the network to come to a consensus. In such cases, when the validators do not follow the consensus layer rules, they will be penalised appropriately, and in some cases they will be also excluded from the network. The penalties and rewards are described in more details here.
In contrast to that, the validators are rewarded by a small amount of Ether for appropriate behaviour according to the consensus layer rules - which serves as an incentive to continue participating in the network.
The Ethereum consensus layer is designed in a way that validators have different roles, which are assigned for each slot and might be different. The validator roles (or duties) are the following:
- Attestations
- Aggregations
- Sync committee aggregations
- Block proposals.
The validators are rewarded according to the importance of the duty they are performing for the slot, as well as the current state of the network. The importance of each duty is different.
Block proposals are the most important messages. Attestations are also very important, because they essentially vote what is valid and what is not. However because of the proportions of the obligation delegation (one block proposer vs many attesters), the emphasis on valid block proposals is set much higher. Additionally there is a buffer for the amount of the attestations necessary for justification and finalisation of a block, which means the network would continue forward even if not all validators have attested properly.
In order for blocks to be proposed, the validators with a block proposer duty should be active/online in the first place and then respond to their role appropriately.
There is an inherent risk of suboptimal functioning of the consensus layer, as well as network stall, from validator inactivity.
Validator anonymity
Various different actors might have malicious purposes and motivations for network attacks. Some attacks are possible by making large groups of validators inactive, as well as targeting block proposers.
Additionally because of the significance of the stake in the network and the large amount of assets required, the validator security and anonymity is very important on personal level.
Network level security and personal security and anonymity is very important for proper functioning of the consensus layer and increased validator participation.
Network security and anonymity
Since the start of the Beacon chain, up to this point no major network attacks, validator targeting attacks or any major threats to the functioning of the network have happened. However there is non-zero probability of such attacks, especially with the network becoming increasingly more popular. This might be contradictory with the reasoning that the larger the network becomes, the more secure it is. But this is different type of security, it is not about the ability to control large portion of the network - threat of large network control, but making the network not functional - threat of DDoS attacks and targeting.
To prevent DDoS attacks, it is important to ensure that the validators cannot be easily linked. By linking we mean the relationship between the validator’s ID on the consensus layer (virtual identity) to their IP addresses (physical identity).
Each validator client is a separate entity from a Beacon node. The validator clients manage the credentials for one or multiple validators, create consensus messages (based on data obtained from the beacon nodes), sign and publish consensus messages to a single or multiple beacon nodes. The beacon nodes are blockchain nodes responsible for participating in the blockchain network. They are subscribed to, and publish messages to certain gossipsub topics, as defined by the consensus protocol. The beacon nodes participate in the p2p network. They also store the blockchain data, and maintain connection with an execution engine client (ETH1 client).
The current way of ensuring the un-linkability property holds true (validator ID <> phyisical IP address) is by the properties of the beacon node ↔ validator relationship, and additionally the messaging design on network level. The beacon nodes are responsible for the p2p communication and message propagation, and the validator clients are responsible for constructing consensus messages (such as block proposals, and attestations) and sending them to beacon nodes in a trusted manner.
The gossipsub p2p messages are propagated by the beacon nodes, by using StrictNoSign message signature policy for the gossipsub p2p **messages at network level.
The reasoning behind this approach of network security is that even if we know where this message comes from on network level (IP address of the beacon node), we can’t be sure about the validator IP address (it is not exposed anywhere). The message does not contains any validator exposing fields as well. Additionally because of the idempotency property of the messages, a validator could submit the consensus messages to multiple beacon nodes.
This method of protection has been sufficient so far. However there are still risks of metadata analysis attacks.
Breaching the validator privacy can have big unwanted effects on the state of the network. The consequences are that block proposers could be targeted and DDoS attacked. This would lead to destabilising the network. Additionally because of the staking amounts (and their monetary value), validator operator de-anonymisation is possible. This can have various different consequences and also might decrease the willingness for network participation.
Decomposing Proposal from Inclusion
While not fully resistant to metadata analysis attacks, the current method up to this point has been fairly successful in practice. There have been proposals in the past for stronger network level validator privacy, which addressed similar concerns. However the issue is that in order to increase the validator anonymity additional latencies are introduced, because of the extra steps involved to increase the anonymity.[^1] [^1]: We are constrained by the block periodicity less potential time drift (as a bounded estimation value)
Network latencies are very important for the Proof-of-Stake consensus layer that Ethereum utilises, and it plays an important role in the slashing and reward distribution in the network. Validators are quite sensitive to the network latencies, and solutions which increase latencies by a large margin would not be feasible.
Validators rewards are dependent on the inclusion delay of their messages.
Solution constraint and requirements
With these considerations and constrains in mind, we’ve worked towards a solution which would improve validator anonymity. With the latency constraint still in place, we’ve worked towards finding more optimal solution - rather than fully focusing towards the strongest anonymity possible (this would make the proposal infeasible).
The solution consists of obfuscating the IP address of the originating beacon node (the originating node that the validator has published the message to), by introducing an opt-in private network: VENOM.
VENOM: Viable Ethereum Node Operation Mechanism
Our idea is that this private network should be opt-in at start, and that even if desired it would take time for this network to become part of the formally defined consensus layer specification.
However because of security benefits that the network provides, the validators might be implicitly incentivised for joining the network.