Run a cluster with MEV-Boost
Charon is in an early alpha state and is not ready to be run on mainnet. Charon's integration with MEV-Boost is also in an alpha state and requires a non-trivial amount of configuration to get working successfully. In future this process aims to be much more automated and seamless from the users perspective.
This quickstart guide focuses on configuring the builder API for a validator and assumes you already have a cluster up and running.
Getting started with Charon & the Builder API
Running a distributed validator cluster with the builder API enabled will give the validators in the cluster access to the builder network. This builder network is a network of "Block Builders" who work with MEV searchers to produce the most valuable blocks a validator can propose. MEV-Boost is a product from flashbots that enables you to ask multiple block relays (who communicate with the "Block Builders") for blocks to propose. The block that pays the largest reward to the validator will be signed and returned to the relay for broadcasting to the wider network. The end result for the validator is generally an increased APY as they receive some share of the MEV.
To configure Charon to use the builder API you simply need to add one flag to the
charon run command.
charon run --builder-api
Configuring Validator Clients
Currently Charon with the builder API enabled is comaptible with two validator clients, Teku (develop branch) & Lighthouse (unstable branch) and requires a decent amount of manual configuration. Work is underway to support all validator client implementations in an mev-enabled distributed validator cluster seamlessly.
Teku Validator Client
For now you must use the develop branch / container image of Teku to have access to the changes that enable compatibility.
Configuring the Teku validator client with Charon follows exactly the same process as their official guide with 2 further conditions.
- First the validator client must be set up to use the
proposerConfig.jsonstructure. This involves including the
--validators-proposer-configflag on the validator client.
- Second the
--validators-proposer-configflag must be equal to
With these 2 conditions in places Charon validators will be able to register to the builder network, submit blinded block and gain a share of the MEV profits.
Lighthouse Validator Client
For Lighthouse we are currently waiting on the following PR to be merged into their unstable branch to enable compatability, please review the PR's status.
If the PR has been merged Lighthouse can be used with Charon. You must use the unstable branch / container image to have access to the changes that enable compatibility.
Configuring the Lightouse validator client with Charon follows exactly the same process as their official guide with some additional conditions.
- The validator client must be set up to use a custom validator_definitions.yml.
- The flag
--builder-registration-timestamp-overridemust be set and the assigned value must be the same across all validator clients.
- The custom validator_definitions.yml must be placed in the
- The custom validator_definitions.yml must follow the structure below, where
voting_public_keyis the pubkeyshare on the validator client and
builder_pubkey_overrideis the associated aggregate pubkey the network will find. You can find these pubkeyshare to aggregate pubkey mapping in the
cluster-lock.jsonfile created during the DKG process.
- enabled: true
- enabled: true
- enabled: true
Note the pubkeyshares in the
cluster-lock.json are base64 encoded and decode to hex. Below is a decoding example for the first
voting_public_key seen above.
echo pkadKH8m7LNgSbebQI4lc4oOFZmA8y+2WRdEFrng6Pf47MVdAaVFKMFsE4uxIB6v | base64 -d | hexdump -v -e '/1 "%02x" ' | (echo -n 0x && cat)
Feel free to update the
suggested_fee_recipient etc. to whatever you have set up for your environment. Note that there either needs to be a different
validator_definitions.yml on each distributed validator based on the keys it holds or a single
validator_definitions.yml file can be used but you must ensure no collisions on the
Verify Charon + Builder API is Functional
Once you have Charon and your Validator Client set up you can verify the set up is functional by reviewing your proposed blocks on Etherscan testnets or on via the Relay API endpoints.
As an example if my validator was the block proposer for block 12853375 on Ropsten I can review the following resources.
Etherscan Ropsten Block 12853375, if we check the
Extra Data field on this page we will see the tag
Flashbots flashblock (Hex:0x466c617368626f747320666c617368626c6f636b). Relays will generally add a tag to the block, this block was submitted via the Flashbots Relay and as a result it has the tag:
Relay Data API, if you navigate to the
Data API section on the Relay Data API you will see an endpoint labeled
proposerPayloadsDelivered. You are able to add a query argument of
block_number to this call to see if a block was submitted via that Relay. Here is the query for the example block 12853375. Blocks that have not been submitted to the Relay will return an empty array