Skip to content

Why Vero

There are already several validator client implementations – so why we need another one?

Client Diversity

Much has been written about the importance of client diversity over the years. Bugs in complex systems are unavoidable. In blockchain systems, they can have severe consequences – from halting the chain to confirming invalid transactions. Ethereum has encouraged multiple teams to develop independent implementations to reduce the impact of any individual bug. But for the network to be resilient, all these different implementations have to actually be used. A network where a (super)majority of validators runs the same client is not much better than a network that only runs a single client.

From the point of view of a node operator, switching to a fallback client in case of a bug is far from enough as it can easily be too late to react at that point – your validator may have already attested to a buggy version of the chain. Exclusively using minority clients works, but that does not seem like a good long-term solution as it relies on inaccurate self-reported client usage data.

Where does Vero come in?

At Serenita, one of our top priorities since the very beginning was to ensure our validators do not attest to a chain that is only considered valid by a single client implementation (which could be due to a bug in that client). Our envisioned solution was to protect against single-client bugs, regardless of how many others used the client in question. In practice this means verifying a single client's view of the chain against another client's, both on the CL and EL side.

We found a few options that seemed to fulfill that requirement:

  1. Vouch combined with its majority attestation strategy
  2. DVT - SSV (does not support attestation consensus)
  3. DVT - Obol's Charon

The above options are solid choices. However, each of those options also comes with some downsides.

  1. Vouch

    Vouch does not support the Ethereum remote signing API and is therefore not compatible with remote signing software like Web3Signer. This makes it non-trivial to switch to. In case of an issue with Vouch, it would also be hard to switch back to a different setup.

    Furthermore, Vouch has in a way become a victim of its own success - it is already being used by a lot of large node operators. And while there has never been an issue with it, if an issue were to occur, it would affect a large portion of the network.

    TLDR: not trivial to switch to, already used by a lot of large node operators

  2. DVT - SSV

    Registering validators with the ssv.network is expensive, as encrypted partial validator keys need to be published in transactions on Ethereum mainnet.

    To run validators on the ssv.network, the SSV cluster needs to pay a network fee. This requires managing and monitoring a balance of SSV tokens.

    At the time of writing it is not possible to configure an SSV cluster in a way that would prevent validators from following the wrong chain.

    TLDR: expensive validator registrations, SSV token requirement

  3. DVT - Obol's Charon

    The Charon middleware client is not open-source, requiring an additional use grant from Obol for production use.

    Obol's team also took a different approach and did not implement their own validator client, instead choosing to go with a middleware approach, standing between existing validator clients and beacon nodes. That approach required some Charon-specific changes in beacon nodes. Again, any issue with Charon would be non-trivial to recover from.

    TLDR: license, non-standard middleware approach

The biggest shared risk for all of the above options was downtime. An issue in any of the above implementations would require an urgent fix from their respective maintainers. It would be challenging to switch back to a different kind of setup in case of an issue. All three of the above solutions also share critical dependencies, including:

  • attestantio/go-eth2-client (communication with beacon nodes)
  • ferranbt/fastssz, pk910/dynamic-ssz (SSZ data manipulation, encoding/decoding)

A bug in any of those dependencies could easily affect all three of the above at the same time.

In the end, we decided to implement a validator client ourselves, and that's how the idea of Vero was born – a simple multi-node validator client that would protect our validators from client bugs.

In August of 2024, we made Vero available to everyone with a completely open-source license, hoping broader adoption helps improve the resilience of the Ethereum network.

With Vero and a multi-node setup, node operators no longer need to worry about exact client usage data. It is easy to switch to —and switch back from— in case any issue were to occur.

What if there's a bug in Vero?

Vero is a lot less complex than Ethereum clients. And while there will never be a guarantee of Vero being bug-free, we take every possible measure we can to minimize the chances of serious bugs within Vero:

  • a small codebase – fewer lines of code mean fewer chances for bugs
  • high test coverage
  • regular cross-client integration testing in local devnets using ethereum-package

Still, if you encounter an issue with Vero, you can temporarily switch back to any other validator client – easily, quickly and without slashing risk.

Feature comparison

Attestation consensus

  • Requests data from multiple beacon nodes before attesting.
  • Only attests if a defined threshold of them agrees on the attestation data.
Attestation consensus
Traditional VC ❌
DVT - Charon ❌
DVT - SSV ❌
Vouch ✅ (majority attestation strategy)
Vero ✅

Slashing detection

Monitors slashing events on the network and immediately stops performing validator duties as soon as any of the locally managed validators get slashed.

Slashing detection
Traditional VC 🟠 (only Teku)
DVT - Charon ❌
DVT - SSV ❌
Vouch ❌
Vero ✅

Ethereum remote signing API

Supports remote signers using the Ethereum remote signing API.

If you're already using a remote signer using this API, Vero is very easy to switch to without any slashing risk (the slashing protection data stays in-place). In case you end up not liking Vero, you can switch back just as easily.

Ethereum remote signing API
Traditional VC ✅
DVT - Charon ✅
DVT - SSV ❌
Vouch ❌
Vero ✅

Gnosis Chain support

Supports performing validator duties on Gnosis Chain.

Medium to large node operators on Gnosis Chain - read this! There are not many options when it comes to EL clients on Gnosis Chain. Nethermind likely has a supermajority there. With only 2 nodes, Vero allows you to run Nethermind and Erigon side-by-side and only attest if both of the implementations agree. This way, you never risk getting stuck on a buggy chain!

Gnosis Chain support
Traditional VC ✅ (most of them)
DVT - Charon ❓
DVT - SSV ❌
Vouch ❌
Vero ✅

Open Source

Vero is completely open-source without any strings attached. It is released as a public good to strengthen the Ethereum network, make running multi-node setups more accessible and thereby improve the client diversity situation.

Open Source
Traditional VC ✅
DVT - Charon ❌
DVT - SSV ✅
Vouch ✅
Vero ✅