Two Roads in the DVT journey: Comparing OBOL and SSV flows
Distributed Validator Technology (DVT) is revolutionizing the Ethereum staking landscape. As Ethereum transitions to its Proof-of-Stake consensus mechanism, the need for decentralized, secure, and efficient validator operations becomes paramount. DVT addresses this by enabling validators to operate in a distributed manner across multiple nodes, enhancing security and redundancy. This innovative approach not only bolsters the robustness of the Ethereum network but also aligns with its foundational ethos of decentralization. As we delve deeper into the realm of Ethereum staking, understanding DVT becomes essential for every stakeholder in the ecosystem.
Both Obol and SSV stand as forward-thinking solutions within Ethereum’s staking ecosystem, drawing upon several shared principles and methodologies. At their core, both systems prioritize Byzantine Fault Tolerance (BFT) to ensure robustness and security against adversarial actions. Neither system acts as a custodial solution, ensuring users maintain ultimate control and sovereignty over their assets. Both platforms share a visionary belief that the future of Ethereum lies in decentralized, at-home staking, proposing an active-active setup, maximizing uptime and potential rewards for stakers.
In this article, we’ll unpack the unique design choices of both solutions according to their philosophies, then explore their implications on flows for both stakers and operators.
Terminology
- DVT: Refers to Distributed Validator Technology, a system designed to facilitate decentralized operations for an Ethereum validator through independent, non-reliant operators.
- Ethereum Validator: A single 32 ETH stake represented by a BLS key
- Key Share: A partition derived from a validator’s BLS key, utilized by DVT nodes to collaboratively manage the validator.
- Distributed Validator (DV): An Ethereum validator symbolized by a BLS public key, collaboratively managed by multiple corresponding private keys.
- Distributed Validator Cluster: A collection of Ethereum-based nodes, inclusive of DVT clients, networked together to jointly manage one or multiple distributed validation entities.
- VaaS provider: Validator as a Service provider represents a category of staking services where you deposit your own 32 ETH for a validator, but delegate node operations to a third-party operator. In this article we will consider only non-custodial VaaS provider.
I. Different approaches to DVT
While often lumped together, DVT solutions like Obol and SSV have distinct designs. There are three primary categories of DVT solutions today:
- DV Middleware: This is the most fundamental implementation of DVT where a DV middleware client is introduced into the validator stack (i.e. sits between the validator and consensus clients).
- DV Operator Network: This is an implementation of distributed validators that provides a network of validator operators that is utilizing DVT. It has a ready-made networking and tokenomic layer to facilitate and incentivize operators.
- DV-Based Staking Product: This is an implementation of a full staking product (i.e. liquid staking protocol, staking-as-a-service, etc.) that utilizes DVT within their operator set, allowing people to stake on a service operated by DVs.
Obol operates as a DV Middleware, while SSV functions as a DV Operator Network.
Intriguingly, Lido is developing the Simple DVT module (Mainnet planned for March 2023), a DV-Based Staking Product, notably for liquid staking, that skillfully integrates both the Obol and SSV solutions.
Additionally, Diva, a DV-Based Staking Product not discussed in detail here, is a Liquid Staking DV solution, in contrast to Lido’s implementation which is based on external DV solutions.
Obol approach
DV Middleware: A Strategic Choice for Composability
Obol has designed their DV implementation as a middleware client, named Charon, that integrates into the middle of a standard validator architecture, sitting between the validator and consensus clients. This design choice was made to remain true to Ethereum’s core tenant of composability.
As a middleware, Charon can be integrated into various staking architectures without impacting other design choices including network architecture, token-design, etc.
Ensuring Security in Ethereum PoS
Obol’s middleware design also focuses on maximizing the security of validators. As a middleware, Charon does not require run-time access to private keys. This design choice ensures that Charon, acting as a mediator between beacon nodes and validator clients, doesn’t have the capability to execute potentially slashable actions. Should Charon ever face a security breach, the existing validator clients act as a protective barrier. They meticulously cross-check every action, dramatically curtailing the chances of any slashing events.
Additionally, Obol pioneered the use of Distributed Key Generation (DKG) to create key shares for each node within a cluster without the full validator private key ever existing in its entirety at any given moment. This ensures that no one node or operator (in a multi-operator cluster) can be compromised and lose the validator private key.
Further Charon also reduces correlation risk in the consensus layer. Ethereum’s Proof of Stake consensus has a unique characteristic: it severely penalizes validators that display correlated behavior. To break it down, if a validator goes offline and a significant number of other validators follow suit, the consequences become increasingly severe. The repercussions also intensify if multiple validators face slashing within three weeks of an initial slashing event.
As a DV middleware client, Charon mitigates correlation risk in many ways. First, since the DV middleware does not replace any client, it allows validators to be set up with any combination of existing execution, consensus, and validator clients, which ensures resiliency to any single client bug or failure.
Additionally, Obol adopted a strategy of using isolated clusters. Instead of connecting all of Obol’s clients, known as Charon, to a common gossip network, they established self-contained clusters. Each of these clusters leverages direct TCP connections, ensuring efficient communication without the risks of a single point of failure. This approach not only ensures more efficient bandwidth usage but also offers a heightened security level. It grants institutional operators the flexibility to distribute validators within an entirely private network, placing keys on hosts that remain shielded from public internet exposure.
The Obol Labs core team is also actively researching a specification, in collaboration with Nethermind, for defining a DV middleware protocol that will allow for a multi-client implementation. This will further reduce correlation risk.
SSV approach
Coordination in Ethereum Staking
Before digging into the SSV design, we first need to understand more about Ethereum’s Proof of Stake.
Ethereum’s PoS design is unique in the blockchain ecosystem, where each validator is a BLS key representing a 32 ETH stake. Such a design inherently adds layers of complexity to the staking journey for both stakers and operators. The necessity for detailed coordination and manual steps detracts from the ideal of a streamlined, autonomous blockchain operation.
Before digging into how SSV proposes to enhance the staking experience, first, let’s see below the steps required if you would like to stake your ETH through a non-custodial VaaS provider.
Disclaimer: in the below scheme we consider that the validator key generation is part of the VaaS provider duty, but the user can also generate the key himself and share it to the provider. Also, in the below process, the provider never has access to the funds of the staker, he only manages the validator keys and operation.
After examining Ethereum’s staking mechanism for stakers who opt out of directly managing nodes, it’s evident that both stakers and operators face challenges. A process that, while secure, can be time-consuming.
Recognizing these challenges, SSV mainly focuses on creating a DVT network that solves these banners, emphasizing non-coordination and permissionless.
Zero-coordination: Validator Distribution
Indeed, SSV simplifies the staking process by leveraging smart contracts, where key shares are encrypted and stored on-chain, allowing for a zero-coordination staking flow. Users can independently stake their $ETH by building their validator’s cluster, selecting operators either directly through the SSV interface or programmatically via an SDK. Once stakers make their selections, each encrypted key-share can be discovered and decrypted by the associated operator, without any coordination required.
While the on-chain storage of encrypted key shares streamlines the staking process, it also opens up the keys to a spectrum of security risks. Storing encrypted key shares on-chain raises security concerns, as smart contract vulnerabilities and the transparent nature of blockchain transactions could leave validator keys susceptible to exposure.
DV Client Integration
Ethereum’s multiple client implementations safeguard its network by ensuring client diversity, a key factor in maintaining robust security and system-wide resilience.
SSV’s integration with Ethereum clients is designed to be seamless, as it incorporates a tailored validator client. This design allows SSV clients to seamlessly plug with each Ethereum client without the need to adapt.
In contrast, Charon development requires adjustments from each consensus client team to ensure compatibility. But Obol’s middleware is not just an isolated solution but a step towards standardizing DV Middleware clients. The adjustments required for consensus clients to integrate with Charon are not exclusive to Obol’s use but are part of a broader initiative to ensure DV clients are replaceable and adaptable. This effort aligns with creating a more flexible and resilient Ethereum ecosystem, where Obol collaborates with Nethermind to establish the Distributed Validator Protocol to design DV middleware specification.
Currently, Charon is the most advanced DV middleware, yet achieving uniform compatibility with all Ethereum clients across every duty remains a work in progress. Although most clients support the majority of these duties, they typically lack in two or three areas. As of now, only Lodestar fully supports all required duties (see here), but it’s expected that compatibility will improve over time as developments continue.
While Charon is governed by a Business Source License, SSV’s code is not. However, the utilization of SSV technical stack mandates fees paid in their own token, effectively introducing a specific form of compensation for its use.
II. DV staking and operating flows
Having explored the design choices of both solutions, let’s delve into how these decisions influence the DV flows from both the staker’s and operator’s perspectives.
Operator Topology
In any Ethereum DV solution, it’s logical to require two synchronized Ethereum nodes: the Execution and Consensus layers. Select your clients based on the compatibility with the DVT solution (as they are still in active development some might not be fully compatible) and, of course, client diversity.
As mentioned, Charon is crafted as a middleware that sits between a beacon node and a validator client. In contrast, an SSV client manages the key duties and establishes connections to both the execution and beacon nodes.
Both solutions provide the option to set up private clusters, where all operator nodes are under the management of one individual or entity — referred to as ‘solo clusters’ in Obol and ‘private islands’ in SSV — or public clusters, which are composed of nodes run by multiple, distinct operators.
Below is a diagram illustrating example operator infrastructure setups: one without DVT, and the others employing either Obol or SSV.
Also, while SSV makes staking permissionless for users and makes possible operators stake to scale effortlessly, it’s good to mention how operating a solo cluster via Obol is advantageous for solo-stakers or Staking-as-a-Service providers aiming to harness the robustness of their validators. Indeed, when you manage a DV cluster individually, it’s way more flexibility to employ a distinct validator client for each operator and all running in a private network (VPC). Additionally, Charon enables the configuration of multiple beacon nodes, deftly handling failovers if a beacon node encounters issues. As a result, this setup offers very good resilience against client release failures and potential host incidents — ensuring an almost uninterrupted validation.
Here is an example of a very resilient Obol solo cluster:
Now that we’ve covered the setup for operators, let’s look at how validator keys are split into shares, shared among operators, and managed within a DV cluster.
Keys Splitting and Distribution
It’s important to mention that each solution facilitates easy validator distribution for users via a user-friendly interface, while also providing SDKs and Smart Contracts that enable developers to build applications on top of the technology, further expanding its utility and integration potential.
That being said, let’s delve into how — for both solutions — validator key shares are splitted and distributed among operators.
SSV
SSV’s design eliminates the need for coordination. Once an operator is up and running, stakers can proceed to the SSV launchpad or using the SDK and effortlessly select operators to establish a DV cluster. It’s essential for stakers to have enough $SSV tokens to cover operator fees for validator management and contribute to the DAO treasury, which supports the network’s growth and ongoing development. Also, because of this fees market, once launched, SSV operators need to register to be operational.
The key splitting for SSV starts with an existing validator BLS key, generated at a central point in the process. To split this key into encrypted shares, stakers utilize a tool, available as a CLI or soon as a desktop app, which encrypts each share with the corresponding operator’s public key, ensuring only they can decrypt it. This centralized creation of key shares contrasts with the Distributed Key Generation (DKG) approach in the MPC world, where a shared key is created collectively without any single party ever controlling the full key.
SSV introduces a Zero-Coordination DKG protocol, accessible via the ssv-dkg CLI. Although not yet fully audited, this protocol facilitates the distributed creation of key shares without requiring operators to manually coordinate, common in other DKG implementations.
The SSV team clarifies that their DKG protocol is an optional feature and not mandated within the network, leaving the choice to individual operators.
In scenarios where an operator is not running the ssv-dkg binary, the DKG process can’t be initiated for the all DV cluster, as depicted in the below screenshot.
A notable feature of SSV’s Zero-Coordination DKG is its resharing capability. This process overcomes the limitations of manual resharing, allowing for the reassignment of existing validator keys to new operators seamlessly and without any manual coordination.
However, it’s crucial to recognize that within SSV, when not using DKG, the initial Ethereum Validator keys must be generated centrally before being distributed. In contrast, through the DKG ceremony, key shares are generated directly.
Obol
Obol’s stack incorporates Distributed Key Generation as a fundamental component, unlike SSV, where DKG is considered as an additional tool. In Obol, the DKG process necessitates coordination among operators to create key shares.
When it comes to operator coordination for a solo cluster in Obol, there are two methods. You can employ a DKG to generate key shares to ensure that the full private key never resides on the same host simultaneously. Alternatively, you can also split a private key centrally and distribute key shares on each node, though you would lose some security qualities with this approach.
For Obol’s group clusters, one operator, takes the lead in initiating the cluster creation. Once the cluster is configured, the rest of the cluster participants can join in. From there, the DKG ceremony is facilitated to generate the key shares and activate the cluster. The full cluster creation process can be facilitated via the launchpad or programmatically with the use of the Obol-SDK.
A distinction of Obol from SSV is its independence from pre-existing validator keys. Charon, Obol’s client, generates key shares directly during DKG ceremonies, just as SSV does through a DKG ceremony. As a result, there’s never a single point where the complete Ethereum BLS key is stored. The deposit data file is generated and stored across operator hosts, allowing the staker to deposit funds without any party holding the complete validator key.
This method boasts strong security yet also has a potential drawback; if key shares are lost beyond a certain threshold, the validator could be compromised. Even the loss of a single share, while not fatal, reduces the high availability of the validator since the current system does not yet support re-sharing of keys. Operators are therefore encouraged to back up their key shares folder meticulously. Obol and SSV are both developing key re-sharing protocols, which, once implemented, will significantly increase the system’s resilience by allowing the substitution of lost keys. Until this enhancement is in place, the most prudent measure for operators is to back up their keys to preserve the validator’s integrity.
As for enhancing the DKG process, Obol recognizes the trust required when stakers delegate their stakes to node operators. The team is actively exploring ways to bolster the DKG verification process, embracing a “Don’t trust, verify” philosophy. This includes implementing measures to verify the group public key and the integrity of the cluster_definition_hash. They are exploring advanced cryptographic techniques such as Verifiable Secret Sharing (VSS), Publicly Verifiable Secret Sharing (PVSS), and Zero-Knowledge Proofs to reinforce the security of DKG, though these methods are still being developed and are resource-intensive. More detailed discussions on DKG Verification can be found here in their documentation.
This proactive approach to research and development underlines Obol’s commitment to enhancing the trust and security aspects of the DKG process within their platform.
Keys Discovery and Management
Transitioning from the intricacies of key splitting and distribution, we now turn to the subsequent phase of validator keys’ lifecycle: discovery and management within a DV cluster.
Obol
After the completion of the DKG ceremony, each operator finds their respective key shares securely stored within their node’s designated folder.
Like we said above, Obol strategically leverages already established validator clients. Their DV Middleware, Charon, operates as an intermediary, ensuring it neither accesses Ethereum keys nor signs data on a whim. Charon primarily streamlines communication between consensus and validator clients. Its responsibility lies in achieving consensus on data that needs authentication, accumulating these approvals, and then broadcasting them across the network. This protective layer is perceived as a safeguard. Should Charon be breached, its potential for destruction remains limited due to its dependence on the original validator clients.
This is a composable design that focuses on improving the security and resiliency of validators with the least disruption to existing staking architectures. However, it doesn’t inherently change the level of coordination or expertise in establishing and running an Ethereum validator.
SSV
SSV client, diverging from Obol, has integrated a tailor-made validator client that will discover validators keys directly on-chain thanks to a set of smart contracts. Once stakers delegate a validator on their platform, the key share for each operator is encrypted — leveraging the corresponding operator public key — and is then archived on-chain. Consequently, as an SSV node becomes operational, it identifies its assigned keys and determines the specific operators it needs to interact with.
In essence, SSV’s smart contracts oversee:
- Streamlined coordination amongst stakers and operators.
- Seamless discovery of validator key shares for operators.
However, this approach is not without its drawbacks. Storing encrypted keys on-chain exposes them to potential threats from malicious actors, which could compromise the security of the validators and introduce vulnerabilities. As with any technological decision, this presents a trade-off that stakeholders must weigh, balancing their needs and the security of their assets.
MEV Dynamics
As we delve deeper into DV cluster flows, the concept of Maximal Extractable Value (MEV) emerges as a significant factor. MEV refers to the maximum value that can be extracted from block production in excess of the standard block reward and gas fees. This phenomenon occurs when validators, reorder, insert, or censor transactions within a block to maximize their profits. Both Obol and SSV support Flashbot’s MEV-Boost client, enhancing their capabilities in this domain.
In DV clusters, aligning on MEV client and relay support is essential for optimal operation. Successful MEV extraction requires that all operators within a cluster support the same MEV relays. Mismatches in relay support or operators opting out of external block building can result in missed MEV opportunities, or, in worse cases, missed block proposals. Therefore, achieving consensus among operators on their MEV strategy is key to ensuring efficient and profitable MEV extraction within a DV cluster.
Obol’s design, encompassing both solo and group clusters, simplifies MEV management. In solo clusters, where one entity controls all nodes, MEV strategy is more straightforward. Even in group clusters, despite requiring consensus, the inherent coordination facilitates a controlled and predictable MEV environment.
Contrastingly, SSV’s MEV landscape is more complex due to cluster formation based on staker choices. This leads to a wide variance in relay support across clusters, potentially affecting validator rewards. For instance, if each operator in an SSV cluster uses MEV-Boost but supports different relays, only the cluster leader can broadcast the constructed block, mirroring the liveness of non-DVT validators. A lack of consensus on running MEV-Boost might prevent reaching an agreement for the duty. Furthermore, if a non-MEV operator compiles the block, it will be executed without MEV rewards.
To address this, SSV operators are motivated to support as many relays as they can, enhancing the likelihood of overlap and maximizing MEV rewards. Additionally, SSV mitigates the impact of relay compatibility issues by displaying MEV compatibility on their web interface, assisting stakers in forming clusters with aligned MEV strategies. For detailed insights on SSV’s MEV state, refer to the in-depth article here.
Conclusion
DVTs are revolutionizing the staking industry, significantly enhancing decentralized and secure active-active validator operations.
This advancement is not only benefiting seasoned validators but also opening doors for at-home stakers, allowing them to participate in Ethereum’s security more effectively and seamlessly.
Obol and SSV, each with their distinct methodologies, tackle these challenges in their unique ways. To make informed decisions, stakers and operators should carefully weigh the advantages and limitations of each option. As previously mentioned, the Lido Simple DVT module combines both DV solutions, harnessing the strengths of both Obol and SSV. This emerging trend is one that many others may choose to follow.
As an aside, and to wrap up this article: Regarding at-home staking, some are already exploring extreme setups, like the remarkable DVStakers experiment in rural Kenya. Such a setup, relying on solar panels and Starlink, would never have been imaginable before the rise of DVT. Ethereum’s staking future is bright!
