# 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](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#pos-staking-validators). 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](https://kb.beaconcha.in/rewards-and-penalties).

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.

[At each slot, a **single** validator (block proposer) proposes a block, while the other validators are attesting for the beacon block head (LMD GHOST vote) and the epoch checkpoint block (FFG vote).](https://kb.beaconcha.in/attestation)

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).

[The consensus layer is partitioned in two-component model, which consists of beacon nodes and validator clients.](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-client-architecture/)

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](https://github.com/libp2p/specs/blob/master/pubsub/README.md#message-signing) 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](https://ethresear.ch/t/packetology-validator-privacy/7547).

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 transaction anonymity additional latencies are introduced 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.](https://kb.beaconcha.in/attestation#the-effects-of-the-inclusion-delay-on-the-attestation-reward)_

## 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.

## What is a 'futures' market?

The Dojima rice market, established around 1716, is widely considered to be the world’s first organized futures exchange. Instead of directly exchanging money for rice on the spot, merchants would agree on a price and future date at which rice and money would be exchanged. This allowed farmers and consumers to hedge their risk. As a result, information about the abundance or lack of rice would travel across the country as fast as rice merchants carried it.

The current EIP-1559 spec uses an adjustment function (23) with the form

$$
f(x)=1+h(x)
$$

V. Buterin (personal communication, October 2020) suggests an alternative functional form, motivated by the fact that the function $1+x$ is well approximated by $e^x$ when $x$ is small (where

$e=2.718 \ldots$ is Euler's number):
$$
f(x)=e^{h(x)},
$$
where $h$ is an increasing function equal to 0 at $G_{\text {target }}$. Decomposable update rules with an adjustment function of this form are especially aesthetically appealing when written in product form (24):
$$
\alpha\left(B_1, B_2, \ldots, B_{k-1}\right)=r_0 \cdot \prod_{i=1}^{k-1} \zeta\left(B_i\right)=r_0 \cdot \prod_{i=1}^{k-1} e^{h\left(g\left(B_i\right)\right)}=r_0 \cdot \exp \left\{\sum_{i=1}^{k-1} h\left(g\left(B_i\right)\right)\right\} .
$$
For example, plugging in the function $h(x)=\left(x-G_{\text {target }}\right) / 8 G_{\text {target }}$ used in the current EIP-1559 spec:
$$
\begin{aligned}
\alpha\left(B_1, B_2, \ldots, B_{k-1}\right) &=r_0 \cdot \exp \left\{\frac{1}{8} \sum_{i=1}^{k-1}\left(\frac{g\left(B_i\right)-G_{\text {target }}}{G_{\text {target }}}\right)\right\} \\
&=r_0 \cdot \exp \left\{\frac{1}{8}\left(\frac{\sum_{t \in B_1 \cup \cdots \cup B_{k-1}} g_t}{G_{\text {target }}}-(k-1)\right)\right\} .
\end{aligned}
$$

## FeedBase Oracle

> Decomposable Update Rule
This encodes two different restrictions. First, the base fee of a block should depend on only the base fee and the contents of the most recent block. Second, the adjustment function ζ depends only on the contents of the most recent block Bk−1 and not on its base fee.

## New Transaction Type

- On a timescale of a few slots, the cost of censorship is still linear in the number of slots for which you want to censor, but with a much better constant. Without crLists, a dominant builder only incurs the opportunity cost of not including the transaction, per slot. With crLists, they are forced to fill each block to its gas limit, which is many times more expensive