Obol
Research — Distributed Validator Tech
Distributed validator tech is a means of running a single validator across multiple devices. The structure of the Ethereum blockchain makes it very resilient, but if you get down to the individual validator level there are some challenges that operators face on a proof of stake network. Obol provides a way for validator operators to ensure the services they provide the Ethereum network are much more reliable. They do this by introducing a middleware layer into the stack of clients that make up a validator that allows for the creation of a distributed validator, which means a single validator can be spread across multiple machines. We’ll cover the problems that currently exist, the benefits a distributed validator provides, and we’ll close it out with the components of a validator and how Obol fits in.
To keep it simple, with a proof of stake network participants stake their assets on a validator and perform functions like proposing blocks for the chain in exchange for more tokens. In order to ensure these participants act correctly, if they do something detrimental to the network some of their stake is “slashed”. Right now a validator on Ethereum has 32 ETH staked on a single machine and if that machine goes down for whatever reason then it is subject to that slashing penalty meaning they would lose ETH. The initial thought is, “well just spin up another validator with the same key in case the first one goes down”. The danger with that is that if two validators are using the same key, that’s a slashable offense. So if the power goes out, if the internet goes down, if something goes wrong with the machine’s hardware or maybe a problem with its software, this is a bunch of stuff out of an operator’s control that can cause down time. An operator can invest in various things to try and mitigate some of these. They could have a backup generator on hand to restore power quickly, run redundant hardware like extra hard drives or networking cards in case of a hardware failure, perhaps have a Starlink internet option in case their hard line internet has an outage. All of these solutions cost money to cover the operator in a tail risk scenario so most of the time those resources are sitting completely idle, wasteful, but perhaps worth it depending on the slashing penalty they mitigate.
Get Prezzel’s stories in your inbox
Join Medium for free to get updates from this writer.
Using Obol, operators are able to spread a validator across multiple machines. The bare minimum for a distributed validator setup is four machines where three have to be active in order to keep operations running. All of sudden if one of the operators suffers a power or internet outage, it’s fine. If there is some problem with a machine then an operator doesn’t need to be on call 24/7 to get the machine back to a healthy state. The fault tolerance introduced by having multiple machines means operators don’t need to expend extra resources to cover tail risks, and the machines that are part of the distributed validator can be cheaper than the previous standalone machine since they don’t need to contain any redundant hardware. The math eventually crunches down to “is the distributed validator approach cheaper than all the stand alone high availability strategies?” and we’ve seen this play out in software engineering already and know it’s a better option. Furthermore, I wouldn’t be surprised if this is just the first stage of making validators highly available where we see them start to move into a containerization approach and built right into the major cloud providers interfaces for people to quickly access and scale. If you want to dig more into how software has scaled over the last 10 years you can search for stuff like “docker”, “kubernetes”, “software as a service”, “containers”. Right now people are thinking about the individual operators, but I suspect as institutions enter the space and want to have a baseline of yield via staking there will be a strong market for running their own validation services on the major cloud providers that’ll require this distributed approach to meet availability service level agreements at minimal cost that’ll be refined over time. Another worthwhile benefit to add is the fact that with the distributed validator approach there is no longer a single private key located in a central location for a malicious party to pursue and compromise, meaning there is also a significant improvement to security by distributing validators.
There’s a stack of clients that goes into running a validator, Obol fits neatly into that stack with their middleware layer to provide this distribution capability to validators. At the top there’s the execution client which listens for new transactions on the network, executes them in the EVM, and tracks the state of the chain. After the execution client produces data, there’s a consensus client that runs the proof of stake consensus algorithm allowing the various nodes to reach agreement on the state of the chain. At the bottom of the stack is the validator client which holds the private key of the validator and uses it to do things like attest to the state of the chain, you can search up “attestation” if you want to learn more about that process.
Obol adds a distributed validator client that slots in between the consensus and validator client layers that’s called Charon. When an operator goes to distribute a validator they use the “distributed validator launchpad” provided by the Obol team as a public good. This facilitates the distributed key generation ceremony which creates the key material across the various machines. Once the key material is created, the validator can be activated. Now that a validator has a distributed validator key (DVK), the Charon clients across the machines communicate and if it can reach the threshold of 3 out of 4 of those key shares then it’ll be able to use them in aggregate to sign off as if it had a single private key. The 3 of 4 setup is the simplest and implementations can be more sophisticated to account for multiple outages or malicious parties. So it’s a pretty straightforward concept to understand that solves a lot of large problems for operators. A term you may be interested in if you want to go deep on how these keys work is “BLS signatures”.
Adding fault tolerance around the core infrastructure that runs Ethereum is a necessary step as the chain matures that serves to improve the ability of current operators as well as creates the conditions for new institutional operators to easily enter the space, both of which will strengthen the chain. The operational and security challenges of stand alone validators will phase out as Obol and other distributed validator services gain adoption with operators. Their implementation with Charon seems simple enough and it’ll be interesting to see the next stage of evolution in this line of thinking if these various clients get split across containers in the same way we’ve seen enterprise software evolve. We may see people running on mobile devices or perhaps some out of the box raspberry pi offerings, a lot of interesting ways this could go. Overall the benefits of a distributed validator approach easily outweighs any challenges introduced by the middleware it requires, that’ll make it a core piece to how Ethereum will run going forward.
