A command-line tool for managing common tasks in Ethereum 2.
Binaries for the latest version of ethdo can be obtained from the releases page.
You can obtain the latest version of ethdo using docker with:
docker pull wealdtech/ethdo
ethdo is a standard Go program which can be installed with:
GO111MODULE=on go get github.com/aaron-alderman/ethdoNote that ethdo requires at least version 1.13 of go to operate. The version of go can be found with go version.
If this does not work please see the troubleshooting page.
The docker image can be build locally with:
docker build -t ethdo .You can run ethdo using docker after that. Example:
docker run -it ethdo --helpNote that that many ethdo commands connect to the beacon node to obtain information. If the beacon node is running directly on the server this requires the --network=host command, for example:
docker run --network=host ethdo chain statusAlternatively, if the beacon node is running in a separate docker container a shared network can be created with docker network create eth2 and accessed by adding --network=eth2 added to both the beacon node and ethdo containers.
ethdo needs a connection to a beacon node for many of its features. ethdo can connect to any beacon node that fully supports the standard REST API. The following changes are required to beacon nodes to make this available.
Lighthouse disables the REST API by default. To enable it, the beacon node must be started with the --http parameter. If you want to access the REST API from a remote server then you should also look to change the --http-address and --http-allow-origin options as per the Lighthouse documentation.
The default port for the REST API is 5052, which can be changed with the --http-port parameter.
Nimbus disables the REST API by default. To enable it, the beacon node must be started with the --rest parameter. If you want to access the REST API from a remote server then you should also look to change the --rest-address and --rest-allow-origin options as per the Nimbus documentation.
The default port for the REST API is 5052, which can be changed with the --rest-port parameter.
Prysm enables the REST API by default. You will need to add the parameter --grpc-max-msg-size 268435456 to be obtain to obtain large sets of information such as the list of current validators. If you want to access the REST API from a remote server then you should also look to change the --grpc-gateway-host and --grpc-gateway-corsdomain options as per the Prysm documentation.
The default port for the REST API is 3500, which can be changed with the --grpc-gateway-port parameter.
Teku disables the REST API by default. To enable it, the beacon node must be started with the --rest-api-enabled parameter. If you want to access the REST API from a remote server then you should also look to change the --rest-api-interface, --rest-api-host-allowlist and --rest-api-cors-origins options as per the Teku documentation.
The default port for the REST API is 5051, which can be changed with the --rest-api-port parameter.
ethdo contains a large number of features that are useful for day-to-day interactions with the Ethereum 2 blockchain.
ethdo uses the go-eth2-wallet system to provide unified access to different wallet types. When on the filesystem the locations of the created wallets and accounts are:
- for Linux: $HOME/.config/ethereum2/wallets
- for OSX: $HOME/Library/Application Support/ethereum2/wallets
- for Windows: %APPDATA%\ethereum2\wallets
If using the filesystem store, the additional parameter basedir can be supplied to change this location.
If using docker as above you can make this directory accessible to docker to make wallets and accounts persistent. For example, for linux you could use the following command to list your wallets on Linux:
docker run -v $HOME/.config/ethereum2/wallets:/data ethdo --basedir=/data wallet listThis will allow you to use
ethdowith or without docker, with the same location for wallets and accounts.
All ethdo comands take the following parameters:
store: the name of the storage system for wallets. This can be one of "filesystem" (for local storage of the wallet) or "s3" (for remote storage of the wallet on Amazon's S3 storage system), and defaults to "filesystem"storepassphrase: the passphrase for the store. If this is empty the store is unencryptedwalletpassphrase: the passphrase for the wallet. This is required for some wallet-centric operations such as creating new accountspassphrase: the passphrase for the account. This is required for some account-centric operations such as signing data
Accounts are specified in the standard "/" format, for example the account "savings" in the wallet "primary" would be referenced as "primary/savings".
ethdo supports a configuration file; by default in the user's home directory but changeable with the --config argument on the command line. The configuration file provides values that override the defaults but themselves can be overridden with command-line arguments.
The default file name is .ethdo.json or .ethdo.yml depending on the encoding used (JSON or YAML, respectively). An example .ethdo.json file is shown below:
{
"store": "s3",
"storepassphrase": "s3 secret passphrse",
"account": "Personal wallet/Operations",
"verbose": true
}ethdo also supports environment variables. Environment variables are prefixed with "ETHDO_" and are upper-cased. So for example to provide your account passphrase in an environment variable on a Unix system you could use:
export ETHDO_PASSPHRASE="my account passphrase"If set, the --quiet argument will suppress all output.
If set, the --verbose argument will output additional information related to the command. Details of the additional information is command-specific and explained in the command help below.
If set, the --debug argument will output additional information about the operation of ethdo as it carries out its work.
Commands will have an exit status of 0 on success and 1 on failure. The specific definition of success is specified in the help for each command.
ethdo will by default not allow creation or export of accounts or wallets with weak passphrases. If a weak pasphrase is used then ethdo will refuse to continue.
If a weak passphrase is required, ethdo can be supplied with the --allow-weak-passphrases option which will force it to accept any passphrase, even if it is considered weak.
Account passphrases are used in various places in ethdo. Where they are used, the following rules apply:
- commands that require passphrases to operate, for example unlocking an account, can be supplied with multiple passphrases. If they are, then each passphrase is tried until one succeeds or they all fail
- commands that require passphrases to create, for example creating an account, must be supplied with a single passphrase. If more than one passphrase is supplied the command will fail
In addition, the following rules apply to passphrases supplied on the command line:
- passphrases must not start with
0x - passphrases must not contain the comma (,) character
Command information, along with sample outputs and optional arguments, is available in the usage section.
There is a HOWTO that covers details about how to carry out various common tasks. There is also a specific document that provides details of how to carry out common conversions from mnemonic, to account, to deposit data, for launchpad-related configurations.
Jim McDonald: @mcdee.
Special thanks to @SuburbanDad for updating xgo to allow for cross-compilation of ethdo releaes.
Contributions welcome. Please check out the issues.
Apache-2.0 © 2019, 2020 Weald Technology Trading Ltd