Charon - The Distributed Validator middleware client

This repo contains the source code for the distributed validator client Charon; a HTTP middleware client for Ethereum Staking that enables you to safely run a single validator across a group of independent servers.

Charon is accompanied by webapp called the Distributed Validator Launchpad, for distributed validator key creation.

Charon is used by Enterprises and DAOs to distribute the responsibility of running Ethereum Validators across a number of different running instances and client implementations.

A validator deployment that uses the Charon client to hedge client and hardware failure risks

This repo contains the GoLang source code for the middleware, a docker-compose file for deploying the client in a local dev environment, and deployment files for deploying this client to a test cluster. To get started:

# Setup env vars, copy .env.template and then manually enter the correct secrets for the likes of Eth1 nodes etc.
cp .env.template .env

# Local development
make up

First you need to have Go 1.17 installed, then you need to run Go build:

# On mac with homebrew installed
brew install go

# Used for building from source
go build

# Run the charon client
./charon --help

In descending order, the Charon client checks the following places for client configuration info:

• From environment vars beginning with CHARON_, with hyphens substituted for underscores. e.g. CHARON_BEACON_NODE=http://....
• From the config file specified with the -config-file flag as YAML, e.g. beacon-node: http://...
• From CLI params, e.g. --beacon-node http://...

Charon is written in Go. Notable dependencies:

• Go Ethereum: Ethereum libraries
• Prysm: Eth2 libraries
• spf13/cobra: CLI interface
• spf13/viper: Config management
• gRPC and gRPC-Gateway: REST API interfaces

Charon is set up to run a release with Github Actions triggered by a Tag. To tag a commit for release run:

git tag -a v0.1.0 -m "Charon v0.1.0: Getting Started"

• I don't want to wait to sync a full testnet, what can I do?
  • You can use what's called weak subjectivity sync, which basically accepts a checkpoint from another node and starts from there. You can get a checkpoint from infura by calling (with the appropriate env vars set):

  curl https://${INFURA_PROJECT_ID}:${INFURA_PROJECT_SECRET}@eth2-beacon-prater.infura.io/eth/v1/beacon/states/finalized/finality_checkpoints
  

  • Then take the state root from this response + the epoch and set them in the TEKU_WS_CHECKPOINT env var and restart your docker-compose. Teku should start a sync from the checkpoint epoch you've given it instead of from the start.

• Teku fails to start on a new chain if there is data in the temporary db stored in ./local/.data/teku/. Error is like:

  beacon  | Supplied deposit contract (0x77f7bed277449f51505a4c54550b074030d989bc) does not match the stored database (). Check that the existing database matches the current network settings.
  

  • Fixed by rm -rf ./local/.data/teku

• charon test beacon errors with an error something like: panic: parse 192.168.2.2:5051: first path segment in URL cannot contain colon.

  • The issue is beacon-node URIs need to specify a scheme, prepend IP addresses with http://.

• If you put your laptop into standby while running the local containers (e.g. overnight), when your computer un-suspends, prometheus will fail to scrape endpoints with errors like unable to append, out of bounds, time too far into the past or too far into the future.

  • The issue is the containers system clocks get way out of sync. Fix by turning them off and on again, classic.