What is Obol Network?

Obol has the potential to make Ethereum more robust and decentralized; it does this by removing the single point of failure in running a validator on Ethereum. The network utilizes different implementations of Distributed Validator Technology (DVT).DVT is “a new infrastructure primitive that enables a validator key to be split and run between independently operating validator machines”

The Obol Network consists of four core public goods:

The DV Launchpad, a CLI tool and User Interface for bootstrapping Distributed Validators Charon, a middleware client that enables validators to run in a fault-tolerant, distributed manner Obol Managers, a set of solidity smart contracts for the formation of Distributed Validators in unique ways Obol Testnets, a set of on-going public incentivized testnets that enable any sized operator to test their deployment before serving for the mainnet Obol Network. Obol is best thought of as another layer in a typical Ethereum validator client stack that replaces an individual with a group

Distributed Validator Technology on Eth2

DVT, a joint research effort supported by the research team and a grant from the Ethereum Foundation, seeks to bring better infrastructure resilience to the eth2 Beacon Chain The solution aims to offer an active-active redundancy configuration for institutional providers, staking pool operators, and at-home validators to mitigate potential failures at the Validator Client (VC) and Beacon Node (BN) level

• Building in Active/Active redundancy

The most popular failover process for validators today is described as active/passive redundancy. This represents the idea that a validator is running on active infrastructure, but should that infrastructure fail, a backup set of infrastructure is activated; in other words, the backup is ‘passive’, or offline, until needed.

This creates at least two problems. First, validators miss rewards for downtime–the time it takes the operator to switch from an offline validator to a backup validator is time you are unable to perform your validation duties and, so you are penalized. Second, an extremely severe penalty can occur if your original validator comes back online while your backup is also running and you end up with an equivocation (aka “double-signing”) event–a so-called “slashable” offense in Ethereum. Committing this offense will result in your validator (ie 32ETH) being slashed/penalized and forcefully exited from their active validator position over a period of 27 days. This penalty is necessary because signing a particular block multiple times with one key can be a malicious attempt to corrupt the network–or it could be unintentional–but the network is unable to differentiate the two.

How does Distributed Validator Technology (DSV) through the Obol network work

Obol aims to solve the drawbacks of running active/passive systems by introducing active/active redundancy through different variations of DVT. Active/Active redundancy is the idea that the redundant systems are always running. Instead of a validator running on one machine, a validator is run across multiple machines creating fault tolerance. Each machine works together to act as a fault tolerant cluster and can withstand a portion of the nodes failing (eg 2 of 7). Despite a portion of machines in the cluster failing, the group of nodes is still able to fulfill its validator duties.

A group of individuals (or a solo validator) can come together to run a distributed validator cluster. These operators take part in what is known as a Distributed Validator Key Generation Ceremony - each operator generates a private piece of the group key used in validation on the Ethereum network. The technical details are beyond the scope of this First Look, but what is important to understand is that each operator works together to create their own pieces of the key, the entire key is never created in full and does not exist on the internet at any point (which adds a layer of security) and the threshold signing scheme means that up to ⅓ of operators can be offline without affecting the cluster’s ability to perform its duties.

Middleware called Charon, built by Obol, sits between the validator and consensus clients (see the Obol icon in the above diagram). Multiple Charon clients are able to act together as a single validator by communicating and coming to consensus on validator duties to simulate one single, unified validator (and, hence, not double-signing). This middleware implementation will enable validators to use any client that supports the Beacon Chain standard HTTP API and validators can maintain their existing remote signing infrastructure. This will allow for an easier adoption path for validators with existing stake looking to migrate over to using Charon.

how Distributed Validator Technology help with decentralization on Ethereum 2.0 or other Proof-of-Stake chains

• Eth2 Validator Responsibilities & Potential Failure Modes

The key areas of responsibility for validators on the eth2 network, which are also key determinants of their associated reward performance and operative risk, can largely be grouped into two categories: Liveliness and Safety.

Liveliness: Do not go offline. If you go offline, make sure you aren’t offline when everyone else is.

Safety: Do not produce slashable attestations or blocks through double-signing. Make sure you do not run multiple instances with the same key.

Keep your validator private key safe. Protect against potential compromise. Today, different potential modes of validator failures are mitigated through different solutions. Protecting against failures in liveliness at the Beacon Node and Validator Client level is primarily achieved through redundancy in associated components such as hardware provider, hardware location, cloud provider, cloud location, and validator client(s). Due to anti-correlation penalties in Eth2, which are designed to multiply slashing penalties if a group of validators commits similar offenses at the same time, diversified configurations and redundancy are particularly important for validators of all sizes. Most providers leverage active-passive redundancy configurations to protect against service defaults in one or more infrastructure components of their primary setup. In this type of configuration one or multiple secondary nodes serve as a backup upon detected node failure. This type of protection is difficult to implement and requires extended expertise and testing if you are an average at-home validator or operate a trustless staking pool. In addition to this, the current specifications and implementations create a limitation to the sub-component level at which redundancy can be introduced. Validator Clients for example need to communicate with dedicated, client-specific Beacon Node instances making active failover between nodes that operate on different clients an impossible task.. Safety measures for slashing protection already exist at both the local level, which is enabled by default in existing validator clients such as Prysm. In addition, slashing protection can be implemented remotely. Unfortunately, neither of these can protect against faulty configurations where multiple validator instances are run with the same validator key or local slashing protection is deactivated for performance gains. Unfortunately, one of the root causes for recent slashing events that have occurred on the eth2 chain has been a result of these types of faulty setups. To date, there has not been a single, out-of-the-box solution that effectively mitigates all the aforementioned potential modes of validator failures — the release of the Secret Shared Validators middleware changes this.