Introduction
What is Obol?
Obol Labs is a research and software development team focused on proof-of-stake infrastructure for public blockchain networks. Specific topics of focus are Internet Bonds, Distributed Validator Technology and Multi-Operator Validation. The team currently includes 10 members that are spread across the world.
The core team is building the Obol Network, a protocol to foster trust minimized staking through
multi-operator validation. This will enable low-trust access to Ethereum staking yield, which can be used as a core building block in a variety of Web3 products.
The Network
The network can be best visualized as a work layer that sits directly on top of base layer consensus. This work layer is designed to provide the base layer with more resiliency and promote decentralization as it scales. As the current chapter of Ethereum matures over the coming years, the community will move onto the next great scaling challenge, which is stake centralization. To effectively mititgate these risks, community building and credible neutrality must be used as a primary design principles.
Obol as a layer is focused on scaling main chain staking by providing permissionless access to Distributed Validators (DV's). We believe that DV's will and should make up a large portion of mainnet validator configurations. In preparation for the first wave of adoption the network currently utilizes a middleware implementation of Distributed Validator Technology (DVT), to enable the operation of distributed validator clusters that can preserve validators current client and remote signing configurations.
Similar to how roll up technology laid the foundation for L2 scaling implementations,
we believe DVT will do the same for scaling main chain staking while preserving decentralization. Staking infrastructure is entering its protocol phase of evolution, which must include trust-minimized staking networks that can be plugged into at scale. Layers like Obol are critical to the long term viability and resiliency of public networks, especially networks like Ethereum. We believe DVT will evolve into a widely used primitive and will ensure the security, resiliency, and decentralization of the public blockchain networks that adopt it.
The Obol Network consists of four core public goods:
- The Distributed Validator Launchpad, a CLI tool and dApp 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
- Obol Testnets, a set of on-going public incentivised testnets that enable any sized operator to test their deployment before serving for the mainnet Obol Network
Sustainable Public Goods
The Obol Ecosystem is inspired by previous work on Ethereum public goods and experimenting with circular economics. We believe that to unlock innovation in staking use cases, a credibly neutral layer must exist for innovation to flow and evolve vertically. Without this layer highly
available uptime will continue to be a moat and stake will accumulate amongst a few products.
The Obol Network will become an open, community governed, self-sustaining project over the coming months and years. Together we will incentivize, build, and maintain distributed validator technology that makes public networks a more secure and resilient foundation to build on top of.
Key concepts
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 provided by Distributed Validator Technology (DVT).
Distributed validator technology removes the problem of single-point failure. Should <33% of the participating nodes in the DVT cluster go offline, the remaining active nodes are still able to come to consensus on what to sign and 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
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 mev-boost, or other monitoring or telemetry services on the same hardware to ensure optimal performance.
In the above example, the stack includes geth, lighthouse, charon and lodestar.
Execution Client
An execution client (formerly known as an Eth1 client) specialises 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
A distributed validator client intercepts the validator client ↔ consensus client communication flow over the standardised REST API, and focuses on two core duties.
- Coming to consensus on a candidate duty for all validators to sign
- Combining signatures from all validators into a distributed validator signature
The only example of a distributed validator client built with a non-custodial middleware architecture to date is charon.
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 with.
Distributed Validator Key Share
One piece of the distributed validator private key.
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 key generation ceremony is a type of DKG ceremony. A DVK ceremony produces signed validator deposit and exit data, along with all of the validator key shares and their associated metadata.