Idea on how to diversify beacon clients

In light of the recent/ongoing issues with the beacon chain, I would like to propose/get feedback on the following method to achieve client diversity.

Consider the following setup:

* Beacon client 1: Lighthouse
* Beacon client 2: Prysm
* Beacon client 3: Teku
* Validator client: [Vouch]( + [Dirk]( (validator and key management software by []( They also have some blog posts introducing the two: [vouch intro]( [dirk intro](

Basically, vouch can work with most of the major beacon clients. You just have to modify the vouch config file accordingly.

Now let’s assume I restart vouch once a day (takes only seconds). Before every restart I modify the config file and chose any of my beacon clients at random. This can be easily scripted. Important: there is **no** risk of slashing because keys are managed by Dirk.

If there is a problem with a particular beacon client, just take it out until it has been fixed. If everyone would run such a setup, we should (in theory) get good diversity plus it would be easy to just switch to another beacon client if one has a problem.

Two issues I can think of with this approach:

* Vouch and Dirk may become dominant and thus a single point of failure. However, afaik, APIs are being developed to decouple validator clients from beacon clients. So in theory you can use any combination of them. If so, then maybe that can be randomised as well. Could be more dangerous though because you face potential slashing risks.
* Additional resource consumption. Running multiple beacon clients will inevitably lead to higher resource consumption.

Any thoughts? Also paging /u/jgm-orinoco

What do you think?

10 Points
Upvote Downvote

Leave a Reply

Your email address will not be published. Required fields are marked *

GIPHY App Key not set. Please check settings


  1. You can have a look at this exact setup here: []( and here’s a guide to set it up: [](


    It’s also possible to run 2 vouch services and point each vouch to a different beacon (e. g. vouch-a points to lighthouse, vouch-b points to prysm as their primary beacon).

    Our experience with this very setup is positive.

  2. This is a big topic, but here are a few thoughts and comments on the OP and comments to date.

    # What are we trying to achieve with client diversity?

    Quite simply, what we are trying to achieve is to *keep the chain going*. If there was a single perfect beacon node implementation of a perfect specification we could all use that. But the implementations have bugs and trade-offs, and the specification continues to evolve. As such, we want to try to keep the chain going in the face of imperfect implementations of an active (and itself imperfect) specification.

    # Do Vouch and Dirk help with this?

    Yes. Beacon nodes are complex, with many moving parts. Having a single beacon node opens you up to any number of failures, from a bug in the code to a denial of service attack to a misconfiguration. Being able to run multiple beacon nodes reduces the risk of any single failure resulting in the inability to validate.

    Also, the most common cause of slashing events to date has been duplication of keys. Dirk does not duplicate keys, instead using distributed key generation and a majority threshold signing system to provide resiliency without that risk.

    # Are we just moving the single point of failure around?

    Somewhat, but one of the design goals of Vouch is to try to keep things as simple as possible. Vouch does validating: no key management, no slashing protection, no extraneous transactions. Another is to be defensive with the data obtained from beacon nodes, because our external boundary is a lot closer to our validating code then those of validator clients that come bundled with beacon nodes. A third is to be standards-compliant, as we have to talk to multiple beacon nodes. These things all help to reduce the amount of active code present, and keeping Vouch focused on a single task keeps the codebase small.

    Vouch also has an open API to talk to Dirk, at []( so anyone can create an alternative to Vouch with similar functionality if they wish. And Vouch is stateless when working with a remote signer such as Dirk: this again keeps the code footprint down, and allows multiple instances of Vouch to run at the same time on different servers, or in a fast failover mode, without slashing risk.

    Of course Vouch isn’t perfect, and there are no doubt bugs present, but by reducing the footprint of Vouch and accessing multiple beacon nodes at the same time it can help to work around issues with both code-based and operational failures. We believe that small processes with well-defined interfaces can be much more reliable than larger codebases with diverse requirements, and work on that basis.

    # Can we eliminate the risk of the chain stopping entirely?

    No, but we can continue to reduce it. The more beacon node implementations the better, but only as long as they are being used. Vouch allows newer implementations to be added to the mix of active beacon nodes without the downsides of the potentially being a little rough around the edges, and allow users to benefit from their features. We will continue to support as many beacon nodes as is feasible to help in this aim.

  3. So this rotates what program is validating each time it restarts? Am I understanding correctly?

    If so, I’m not sure the databases are cross compatible to do that. Could be wrong, not sure.

    And if it’s on a pattern… (Day 1 Prysm, Day 2 Lighthouse, Day 3 Teku, repeat) Then you have to worry about people being on the same pattern.

Windows keeps crashing …

Tribe 13: Request for Startups — Crypto, The Future of Money | by Brayton Williams | Boost VC