Method 2: Configure on separate validator client
Pre-requisites
Make sure you have downloaded the necessary files according to your choice of validator client. Otherwise, revisit the following pages to download and move them into the /usr/local/bin
directory.
The Validator Client files are downloaded from the same sources as their respective Consensus Clients.
Create new CSM user
By clearly segregating the users and permissions for separate services in your workflow, this will provide additional safeguards against operational mistakes that can lead to slashing via double signing.
Create new folders for CSM data & keys
Create separate folders, import the CSM validator keys, and set appropriate permissions.
Prepare the CSM validator keystores
1) Create 3 new folders to store the validator client data, validator keystore, and the validator keystore password
2) Copy the validator keystores and it's password file into their respective folders
3) Change the owner of this folder to the teku user
4) Restrict permissions on this new folder such that only the owner is able to read, write, and execute files in this folder
Aside from the file extension, the validator_keystore_password file will need to be named identically as the validator signing keystore file (e.g. keystore-m-123.json, keystore-m-123.txt)
Configure the separate VC service
Create a new configuration file for your separate validator client.
Create a systemd configuration file for the Teku Validator Client service to run in the background.
Paste the configuration parameters below into the file:
Once you're done, save with Ctrl+O
and Enter
, then exit with Ctrl+X
. Understand and review your configuration summary below, and amend if needed.
Important: Recall that you will have to use designated fee recipient addresses as a CSM operator.
- Holesky: 0xE73a3602b99f1f913e72F8bdcBC235e206794Ac8
- Mainnet: 0x388C818CA8B9251b393131C08a736A67ccB19297
Refer to the native Teku validator client setup section for more information on the other flags used.
Teku VCStart the CSM Validator Client
Create a new configuration file for your separate validator client.
Reload the systemd daemon to register the changes made, start the Teku Validator Client, and check its status to make sure its running.
The output should say the Teku Validator Client is “active (running)”. Press CTRL-C to exit and the Teku Validator Client will continue to run.
Use the following command to check the logs for any warnings or errors:
Expected output:
Press CTRL-C
to exit.
If the Teku Validator Client service is running smoothly, we can now enable it to fire up automatically when rebooting the system.
Expected output:
Remove duplicates of validator keystores
To prevent configuration mistakes leading to double signing in the future, remove duplicate copies of the validator signing keystores once everything is running smoothly.
Automation Tools
Only 1 instance of ETH Pillar can be running per device. If you are already using ETH Pillar for your own validator node setup, then you will need to use any of the other methods (e.g., ETH Docker) listed in this subpage to import your CSM validator keystores.
Select 4 - Lido CSM Validator Client Only
.
Enter your consensus client (beacon node) address. Example: http://127.0.0.1:5052
Verify the fee_recipient
address is set to the Lido Execution Layer Rewards Vault
.
Generate and import CSM validator keys.
Resources
Documentation: https://docs.teku.consensys.io/introduction
Discord: https://discord.gg/consensys (Select the Teku channel)
Last updated