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](https://github.com/attestantio/vouch) + [Dirk](https://github.com/attestantio/dirk) (validator and key management software by [attestant.io](https://attestant.io). They also have some blog posts introducing the two: [vouch intro](https://www.attestant.io/posts/introducing-vouch/) [dirk intro](https://www.attestant.io/posts/introducing-dirk/))
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