Author: Andrei Smirnov, Senior Protocol Engineer at DV Labs

For the first article of our new, technical-content focused DV Labs blog, Senior Protocol Engineer Andrei explains the protocols enabling Charon to serve as an effective distributed validator client.

Ethereum’s Validator Protocols

The validator stack

Validators propose and attest to the validity of blocks, a critical role in the Ethereum blockchain’s consensus mechanism. Validators run on a node, which is synced with the Ethereum chain and can serve virtually any number of validators. A typical validator node stack includes three main components: an execution layer client, a consensus layer client, and a validator client. Each client is software that serves a specific purpose, and follows the Ethereum 2.0 protocols to remain compatible with the other clients. This means that a node stack can be configured from a combination of clients from different vendors. 

No matter what client combination a node is running, it will execute the same protocols, which are standardised by the Ethereum 2.0 specifications. The graphic below shows the role of each protocol within the validator stack. Only two DV nodes are displayed here for example. In reality, your cluster will consist of more nodes depending on the desired BFT properties.

Engine API

The Engine API facilitates communication between the Consensus Layer (CL)  and the Execution Layer (EL). It is responsible for validating and executing blocks of transactions on your local execution layer client, so that your consensus layer client knows it is following along with the real chain and not one with invalid blocks in it.

Beacon Chain API

The Beacon Chain API manages interactions between a Validator Client and the Consensus Layer, including:

• Block data (proposed and signed blocks)

• Validator information (active validators, balances)

• Attestations and aggregate signatures

• Sync committees participation

• Network health and configuration data

Charon’s Protocols

Distributed Validator Technology enables a single Ethereum validator to be run on multiple nodes via key distribution and threshold signing.  This is made possible by the DV middleware client Charon, positioned between validator and consensus clients. Validator private key shares are generated through a distributed key generation (DKG) ceremony, ensuring that the full key never exists. Multiple Charon clients come to consensus on validator duties and behave as a single unified proof-of-stake validator, achieving byzantine-fault tolerance given a supermajority of honest nodes.

In a DV powered by Charon, all Charon instances must talk to each other to reach a BFT consensus on every validator duty. Other stack components (EL, CL, VC) do not communicate with their “counterparts” in the other nodes of the cluster, only Charon is communicating between nodes. 

Charon establishes a P2P network as a transport layer for multiple protocols running inside Charon. That is, all Charon instances within a DV cluster constantly talk to each other, maintaining the four key protocols: PeerInfo, Priority, ParSigEx, QBFT. The first three protocols are designed to exchange nodes' information such as the cluster state, partial signatures, etc, and are specific to Charon.

Until now, Charon has used the QBFT consensus algorithm to reach consensus between nodes’ Charon clients. (QBFT stands for Quorum Byzantine Fault Tolerance, and is an extension to Istanbul Byzantine Fault Tolerance (IBFT), which is in turn a redesigned version of Practical Byzantine Fault Tolerance (PBFT).) There are a large variety of BFT consensus algorithms, each with its own properties, optimised for specific use cases. QBFT is not the “best” consensus algorithm in the world, but rather the best choice of a battle-tested protocol suiting the needs of a typical DV cluster. (usually 4 or 7 nodes, which need to communicate over sometimes-unreliable public internet.)

From Charon V2 onwards, the user will be able to choose which consensus algorithm they want to use, as the cluster configuration will support pluggable consensus algorithms. Currently, work is being undertaken to explore replacing QBFT with Alea-BFT and other algorithms, as they may provide better properties demanded by Charon. Alea BFT is an asynchronous consensus algorithm, and should be supported in the next major release of Charon. 

This is the typical work done by protocol engineers: we are responsible for researching new protocols and algorithms, for integrating 3rd party components into Charon, and for precise tuning for optimal performance. Rather than always inventing new protocols, it is easier to use 3rd party implementations and focus on integrations. At DV Labs, the protocol engineering team consists of several engineers, working alongside cryptography researchers.

If this is interesting to you, don’t hesitate to get in touch with me directly, or use our jobs site to apply for an open role or submit a general application. Thanks for reading, and keep an eye out for future improvements to Charon!