-
Notifications
You must be signed in to change notification settings - Fork 66
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: enhance Obol vs Others comparison documentation
- Loading branch information
1 parent
1c7f55f
commit ba3246f
Showing
1 changed file
with
75 additions
and
29 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,60 +1,106 @@ | ||
| --- | ||
| sidebar_position: 2 | ||
| description: Some of the key terms in the field of Distributed Validator Technology | ||
| description: A comprehensive comparison of Obol's Distributed Validator Technology with other implementations | ||
| --- | ||
|
|
||
| # Obol vs Other DV Implementations | ||
|
|
||
| This page outlines the unique features of Obol's DV implemenation, constrasting with other DV implementations. We built Obol’s DVT as a middleware to keep Ethereum secure, resilient, and composable. See also the blog article [Why We Built Charon as a Middleware](https://blog.obol.org/why-we-built-charon-as-a-middleware/). | ||
| ## Table of Contents | ||
| - [Introduction](#introduction) | ||
| - [Key Differentiators](#key-differentiators) | ||
| - [Security First: No Private Keys on Chain](#no-private-keys-put-on-chain) | ||
| - [Cluster Independence](#cluster-independence-clusters-can-upgrade-independently) | ||
| - [Direct Communication](#cluster-independence-no-reliance-on-a-common-p2p-gossip-network) | ||
| - [Client Compatibility](#works-with-existing-validator-clients-and-pki) | ||
| - [Pure ETH Economics](#no-non-eth-token-risk) | ||
| - [Flexible Reward Distribution](#non-custodial-reward-splits) | ||
|
|
||
|  | ||
| ## Introduction | ||
|
|
||
| ## No private keys put on chain | ||
| This document outlines the unique features and advantages of Obol's Distributed Validator Technology (DVT) implementation, comparing it with alternative approaches in the ecosystem. Obol's DVT was specifically designed as a middleware solution to enhance Ethereum's security, resilience, and composability. For a deeper dive into our architectural decisions, check out our blog article [Why We Built Charon as a Middleware](https://blog.obol.org/why-we-built-charon-as-a-middleware/). | ||
|
|
||
| Obol's distributed key generation (DKG) event generates key shares for each node within the DV cluster. The entire validator key NEVER exists in one place. Keys are generated locally on the nodes, and can be backed up. The private keys of Obol DVs are NEVER uploaded to the internet or published on-chain. | ||
|  | ||
|
|
||
| An alternative approach to doing this is to split it into shares, encrypt each share with the public key of a node operator, and publish the encrypted private key on chain. The operators’ node key could then decrypt the validator private key. In our opinion, this is not secure. We believe that the safest approach is to avoid the existence of a singular private key, and certainly never to post any private key to a public blockchain network. | ||
| ## Key Differentiators | ||
|
|
||
| ## Cluster independance: Clusters can upgrade independently | ||
| ### No Private Keys Put on Chain | ||
|
|
||
| In an Obol DV cluster, nodes use LibP2P to communicate directly with each other, and communications are end-to-end encrypted with TLS. Clusters are independent from one another, can run different versions of Charon, and don't need to upgrade together. This means that when a new version of Obol’s Charon is released, Obol DV clusters can upgrade on their own time, individually from other DV clusters. Charon will NEVER require a hard fork or simultaneous updates across clusters for any upgrades. | ||
| **🔐 Enhanced Security Model** | ||
|
|
||
|  | ||
| Obol's distributed key generation (DKG) process implements a cutting-edge approach to key management: | ||
| - Keys are generated locally on participating nodes | ||
| - The complete validator key never exists in a single location | ||
| - Key shares are distributed securely among cluster participants | ||
| - Backup mechanisms are provided for key shares | ||
| - Zero exposure of private keys to the internet or blockchain | ||
|
|
||
| ## Cluster independance: No reliance on a common P2P gossip network | ||
| **🚫 Why We Don't Use On-Chain Key Distribution** | ||
|
|
||
| In an Obol DV cluster, nodes use LibP2P to communicate directly with each other, and communications are end-to-end encrypted with TSL. This direct communication of nodes within a cluster improves latency, and makes cluster communications harder to attack with a denial of service (DOS) attack. It also allows an Obol DV cluster to be run within a private network. This may allow cost savings on data egress costs, for operators running cluster nodes across multiple locations of a single cloud provider, for example. | ||
| Some implementations split and encrypt validator keys with node operators' public keys before publishing on-chain. We consider this approach suboptimal because: | ||
| - It creates a single point of failure during key generation | ||
| - Exposes encrypted private key material to public networks | ||
| - Introduces additional attack vectors through the key distribution process | ||
|
|
||
|  | ||
| ### Cluster Independence: Clusters Can Upgrade Independently | ||
|
|
||
| ## Works with existing validator clients and PKI | ||
| **🔄 Flexible Upgrade Path** | ||
|
|
||
| We built Obol’s DV implementation as a secure and trust-minimised middleware architecture. Our middleware client, Charon, doesn’t replace anything in the client stack, instead it sits between the consensus and validator clients. Node operators integrating the Charon DVT middleware into their stack can continue to use the same clients and private key infrastructure as before, albeit with a different key generation method. | ||
| Our architecture enables: | ||
| - Independent cluster operations | ||
| - Asynchronous version upgrades | ||
| - No coordinated hard forks required | ||
| - Seamless version compatibility management | ||
|
|
||
| The alternative approach to DV design is to replace the validator client with a DV-native client, which has custody of the private keys and the capability to sign arbitrary data. However, in our opinion a full validator client capable of signing and exfiltrating arbitrary data without the oversight of a second software implementation has much higher risk of causing correlated slashing. | ||
|  | ||
|
|
||
|  | ||
| ### Works with Existing Validator Clients and PKI | ||
|
|
||
| This gives the benefit of having both Charon and the existing validator client as failsafes, greatly reducing the odds of unintended slashing. Even in the worst case scenario where Charon is compromised by a supply chain attack or a remote code execution attack, or the Obol team become bad actors and push a malicious release, Charon cannot do a lot of damage as a middleware. If a compromised Charon client proposes a potential double vote or surround vote for a validator to sign, the validator client will check its anti-slashing database, see that it has already signed something conflicting, and simply refuse to return a signature. Charon could propose that a validator should sign an invalid block, but the chain would reject this and simply consider the proposal missed - a much better outcome than slashing. | ||
| **🔗 Middleware Architecture Benefits** | ||
|
|
||
| ## No non-ETH token risk | ||
| Obol's Charon client: | ||
| - Acts as a secure middleware layer | ||
| - Preserves existing client infrastructure | ||
| - Adds distributed validation capabilities | ||
| - Maintains compatibility with standard tools | ||
| - Provides additional security through dual validation | ||
|
|
||
| Obol makes no changes to Ethereum’s standard bonding and reward mechanism, and does not require nodes to post any bonds additional to the 32 ETH required for a validator. To pay out rewards to operators, splitter contracts like [Obol Splits](../intro/obol-splits.mdx) can be used to withdraw and share rewards on a continuous basis. This allows products like liquid staking protocols to be built on top of Obol, implementing a bond or unique token into their protocol, should they choose to do so. | ||
|  | ||
|
|
||
|  | ||
| **🛡️ Enhanced Security Through Separation** | ||
|
|
||
| The alternative approach is to create a token and require stakers to pay operators in that token. This would require stakers to keep a balance of the network token ready for fee paying, in order to continue using the staking service. This mechanism would be informed by oracles, which decide when to post rewards and punish operators. This alternative model has some drawbacks. Namely, the varying price of the network’s unique token will change relative to the price of ETH: operators are not able to determine their commission as a percentage of ETH staked, and stakers likewise must consider the additional initial cost of purchasing the token to determine their long-term rate of return on their staked ETH. | ||
| The middleware approach provides multiple advantages: | ||
| - Dual validation of signatures | ||
| - Protection against supply chain attacks | ||
| - Mitigation of remote code execution risks | ||
| - Prevention of unauthorized key usage | ||
| - Reduced risk of correlated slashing | ||
|
|
||
|  | ||
| ### No Non-ETH Token Risk | ||
|
|
||
| **💎 Pure ETH Economics** | ||
|
|
||
| ## Non-custodial reward splits | ||
| Our implementation: | ||
| - Maintains standard 32 ETH validator bonds | ||
| - Requires no additional token holdings | ||
| - Simplifies economic calculations | ||
| - Reduces complexity for operators | ||
| - Enables flexible reward distribution | ||
|
|
||
| (see also the [docs page on Splits](../../learn/intro/obol-splits.mdx), and the [Splits.org blog article](https://splits.org/blog/obol-ethereum-resilience/).) | ||
|  | ||
|
|
||
| To pay out rewards to operators, splitter contracts like Obol Splits can be used to withdraw and share rewards on a continuous basis. Two key goals of validator reward management are: | ||
| 1. To be able to differentiate reward ether from principal ether such that node operators can be paid a percentage of the *reward* they accrue for the principal provider, rather than a percentage of *principal and reward*. | ||
| 2. To be able to withdraw the rewards in an ongoing manner without exiting the validator. | ||
| This allows products like liquid staking protocols to be built on top of Obol, implementing a bond or unique token into their protocol, should they choose to do so. | ||
| ### Non-Custodial Reward Splits | ||
|
|
||
|  | ||
| **💰 Advanced Reward Management** | ||
|
|
||
| The Obol Splits system provides: | ||
| - Clear separation of principal and rewards | ||
| - Continuous reward distribution | ||
| - Flexible splitting configurations | ||
| - Non-custodial operation | ||
| - Integration with liquid staking protocols | ||
|
|
||
|  | ||
|
|
||
| For detailed information about reward distribution, please refer to: | ||
| - [Obol Splits Documentation](../../learn/intro/obol-splits.mdx) | ||
| - [Splits.org Technical Overview](https://splits.org/blog/obol-ethereum-resilience/) |