LogoLogo
SDKAPI
Version-v1.4.0 (current)
Version-v1.4.0 (current)
  • Learn
    • Introduction
      • Obol Collective
      • OBOL Incentives
      • Key Staking Concepts
      • Obol vs Other DV Implementations
      • Obol Splits
      • DV Launchpad
      • Frequently Asked Questions
    • Charon
      • Introduction to Charon
      • Distributed Key Generation
      • Cluster Configuration
      • Charon Networking
      • CLI Reference
    • Futher Reading
      • Ethereum and Its Relationship With DVT
      • Community Testing
      • Peer Score
      • Useful Links
  • Run a DV
    • Quickstart
      • Quickstart Overview
      • Create a DV Alone
      • Create a DV With a Group
      • Push Metrics to Obol Monitoring
    • Prepare to Run a DV
      • How and Where To Run DVs
      • Deployment Best Practices
      • Test a Cluster
    • Running a DV
      • Activate a DV
      • Update a DV
      • Monitoring Your Node
      • Claim Rewards
      • Exit a DV
    • Partner Integrations
      • Create an EigenLayer DV
      • Create a Lido CSM DV
      • DappNode
  • Advanced & Troubleshooting
    • Advanced Guides
      • Create a DV Using the SDK
      • Migrate an Existing Validator
      • Enable MEV
      • Combine DV Private Key Shares
      • Self-Host a Relay
      • Advanced Docker Configs
      • Beacon node authentication
    • Troubleshooting
      • Errors & Resolutions
      • Handling DKG Failure
      • Client Configuration
      • Test Commands
    • Security
      • Overview
      • Centralization Risks and Mitigation
      • Obol Bug Bounty Program
      • Smart Contract Audit
      • Software Development at Obol
      • Charon Threat Model
      • Contacts
  • Community & Governance
    • Governance
      • Collective Overview
      • The Token House
      • The RAF
      • Delegate Guide
      • RAF1 Guide
    • The OBOL Token
      • Token Utility
      • Token Distribution & Liquidity
      • TGE FAQ
    • Community
      • Staking Mastery Program
      • Techne
    • Contribution & Feedback
      • Filing a Bug Report
      • Documentation Standards
      • Feedback
  • Walkthrough Guides
    • Walkthroughs
      • Walkthrough Guides
  • SDK
    • Intro
    • Enumerations
      • FORK_MAPPING
    • Classes
      • Client
    • Interfaces
      • ClusterDefinition
      • RewardsSplitPayload
    • Type-Aliases
      • BuilderRegistration
      • BuilderRegistrationMessage
      • ClusterCreator
      • ClusterLock
      • ClusterOperator
      • ClusterPayload
      • ClusterValidator
      • DepositData
      • DistributedValidator
      • ETH_ADDRESS
      • OperatorPayload
      • SplitRecipient
      • TotalSplitPayload
    • Functions
      • validateClusterLock
  • API
    • What is this API?
    • System
    • Metrics
    • Cluster Definition
    • Cluster Lock
    • State
    • DV Exit
    • Cluster Effectiveness
    • Terms And Conditions
    • Techne Credentials
    • Address
    • OWR Information
  • Specification
Powered by GitBook
On this page
  • Distributed validator
  • Distributed Validator Node
  • Execution Client
  • Consensus Client
  • Distributed Validator Client
  • Validator Client
  • Distributed Validator Cluster
  • Distributed Validator Key
  • Distributed Validator Key Share
  • Distributed Validator Threshold
  • Distributed Validator Key Generation Ceremony
Edit on GitHub
  1. Learn
  2. Introduction

Key Staking Concepts

Some of the key terms in the field of Distributed Validator Technology

PreviousOBOL IncentivesNextObol vs Other DV Implementations

Last updated 5 days ago

This page outlines a number of the key concepts behind the various technologies that Obol is developing.

Distributed validator

A distributed validator is an Ethereum proof-of-stake validator that runs on more than one node/machine. This functionality is possible with the use of Distributed Validator Technology (DVT).

Distributed validator technology removes some of the single points of failure in validation. Should <33% of the participating nodes in a DV cluster go offline, the remaining active nodes can still come to consensus on what to sign and can produce valid signatures for their staking duties. This is known as Active/Active redundancy, a common pattern for minimizing downtime in mission critical systems.

Distributed Validator Node

In the above example, the stack includes Geth, Lighthouse, Charon and Teku.

Execution Client

An execution client (formerly known as an Eth1 client) specializes in running the EVM and managing the transaction pool for the Ethereum network. These clients provide execution payloads to consensus clients for inclusion into blocks.

Examples of execution clients include:

Consensus Client

A consensus client's duty is to run the proof of stake consensus layer of Ethereum, often referred to as the beacon chain.

Examples of Consensus clients include:

Distributed Validator Client

  • Coming to consensus on a candidate duty for all validators to sign.

  • Combining signatures from all validators into a distributed validator signature.

Validator Client

A validator client is a piece of code that operates one or more Ethereum validators.

Examples of validator clients include:

Distributed Validator Cluster

A distributed validator cluster is a collection of distributed validator nodes connected together to service a set of distributed validators generated during a DVK ceremony.

Distributed Validator Key

A distributed validator key is a group of BLS private keys, that together operate as a threshold key for participating in proof of stake consensus.

Distributed Validator Key Share

One piece of the distributed validator private key.

Distributed Validator Threshold

The number of nodes in a cluster that needs to be online and honest for their distributed validators to be online is outlined in the following table.

Cluster Size
Threshold
Note

4

3/4

Minimum threshold

5

4/5

6

4/6

Minimum to tolerate two offline nodes

7

5/7

Minimum to tolerate two malicious nodes

8

6/8

9

6/9

Minimum to tolerate three offline nodes

10

7/10

Minimum to tolerate three malicious nodes

Distributed Validator Key Generation Ceremony

To achieve fault tolerance in a distributed validator, the individual private key shares need to be generated together. Rather than have a trusted dealer produce a private key, split it and distribute it, the preferred approach is to never construct the full private key at any point, by having each operator in the distributed validator cluster participate in what is known as a Distributed Key Generation ceremony.

A distributed validator node is the set of clients an operator needs to configure and run to fulfil the duties of a Distributed Validator Operator. An operator may also run redundant execution and consensus clients, an execution payload relayer like , or other monitoring or telemetry services on the same hardware to ensure optimal performance.

A distributed validator client intercepts the validator client ↔ consensus client communication flow over the , and focuses on two core duties:

The only example of a distributed validator client built with a non-custodial middleware architecture to date is .

A distributed validator key generation ceremony is a type of DKG ceremony. A ceremony produces signed validator deposit and exit data, along with all of the validator key shares and their associated metadata. Read more about these ceremonies .

mev-boost
Go-Ethereum
Nethermind
Erigon
Prysm
Teku
Lighthouse
Nimbus
Lodestar
standardised REST API
Charon
Prysm
Lodestar
Teku
Lighthouse
Vouch
here