Managing ETH Validator Keys
Last updated
Last updated
Validator key management is an advanced feature set. It is relatively new and may be missing functionality. Please read the docs carefully and use with caution!
Lattice firmware v0.17.0 or greater is required for managing validator keys.
If you are interested in , you can now manage validator keys using your Lattice1 device with the Lattice CLI.
Please the Lattice CLI and connect to your Lattice before continuing. Read the if you are having issues connecting.
Your Lattice cannot perform your validator duties - it can only serve as a key management system. In order to participate in the daily activities of Ethereum staking, you must set up a separate .
If you would like to create one or more validators, you will need following for each one:
An encrypted BLS private key (a.k.a. "keystore"), which must be imported into your so that it can make signatures for attestations/proposals using your new validator.
An on-chain deposit to the . This transaction must include information about your new validator and sufficient ether to fund it.
Both types of data can be generated with the using the Export ETH2 Deposit Data command. The user flow for running that command will now be detailed.
When you run the Export ETH2 Deposit Data command, you will be asked several setup questions:
You will first be asked what type of withdrawal key you would like to use: BLS or ETH1:
The default option is to use an ETH1 address; if you select this, the CLI will ask you for a (properly formatted) Ethereum address. Please make sure you have access to the associated private key.
You will now be asked to set a deposit amount. By default this is 32 ETH, which is what you should stick with unless you have a good reason to use a different amount.
Now you will be asked about what format of data you want to export. There are two options:
Now that you have defined your parameters, the CLI will start generating data for your first validator. The CLI will run through the following operations for each validator you want to create:
If you selected BLS withdrawal credentials, fetch the withdrawal public key from the Lattice. This is done automatically.
Build some initial deposit data and ask for a signature from the validator's private key. You will need to authorize this signature on your Lattice.
Ask if you want to generate data (i.e. repeat steps 1-3) for the next validator. For example, if you just generated data for validator at index 0, it would ask if you want to now generate data for validator at index 1, and so on until you decline.
Now that all data has been generated, the CLI will ask you where to save that data on your filesystem. By default, it will be saved to a local directory ./deposit-data. The contents of this directory will include:
deposit-X-{timestamp}.json (where X is either -data- or -calldata, depending on selected export type)
For each validator index (i): keystore-m_12381_3600_{i}_0_0-{timestamp}.json
Now that you have the data in hand, you can start your new validator(s)!
Ensure your deposit transaction(s) succeeded and wait for your new validator(s) to become active (~16-24 hours, usually). Your staking machine should automatically start attesting and, if you're lucky, proposing!
Coming soon!
Coming soon!
Unlike the other key management options, voluntary exits are made by your consensus client and do not involve your Lattice. Recall that your consensus client has a keystore for each validator you have added, so it can sign messages with the validator key (but not the withdrawal key).
To perform a voluntary exit, please see your own consensus client's documentation. Here are the related pages for some of the clients:
If you choose BLS-style credentials, the CLI will automatically derive the withdrawal key for each validator according to .
Finally, you will be asked for a validator index at which to start generating data. Note that this index is the i value in the derivation path. If you have not created any validators with this wallet, you should probably start at the 0 index. If you are coming back to create more, start from where you left off.
JSON file for Ethereum Launchpad - This is the default option and is what you should choose if you are using the . The output data will include a JSON file that you can drop directly into your browser. This is recommended for most users.
Raw transaction calldata - If you want to create your own deposit transactions and send them to the yourself, you should choose this option. The output will be a calldata string for each validator, which you can include in a transaction whose msg.value matches the deposit amount you specified in step 2. This is a more advanced option and isn't recommended for most users.
Export the encrypted validator keystore. This is the BLS12-381 private key of your validator, encrypted and serialized according to . This is done automatically. Note that this step takes about 30 seconds for each keystore.
Import all keystore(s) (validator-{i}-{pubkey}-{timestamp}.json) into your on your validator machine. If you are unsure how to do this, please read the docs for your specific . Once keystore(s) are imported you should expect to see new validators on your client which are marked as inactive -- this is because you haven't deposited to them yet!
Now you can make your on-chain deposit(s). If you are using the , take your deposit-data-{timestamp}.json file and drop it into the browser application. You will be prompted to make one deposit transaction per validator using e.g. . If you are instead using raw calldata, form your own transaction(s) and broadcast to the execution layer.
If you would like to stop performing duties for a validator, you can perform a . Note that this is not the same as a withdrawal.