Run with Bazel
Run the beacon node and validator client straight from your checkout, so every code change is one command away from running. bazel run builds the target if needed, then starts it with the arguments you put after --.
The flags are the same as for a normal install, so this page shows only what differs; see the Quickstart for the full walkthrough and Common flags and config file for the flags.
Before you begin
- Build with Bazel works on your machine.
- An execution client running with its Engine API on
http://localhost:8551and a JWT secret file. See Connect your execution client.
Without it--datadir, a development build uses the default data directory (~/.eth2 on Linux, ~/Library/Eth2 on macOS), the same one an installed Prysm uses. Always pass your own data directory so a test build can't change the database of a node you rely on.
Run a beacon node
-
Start the beacon node. Everything after
--goes to the binary:bazel run //cmd/beacon-chain -- \--mainnet \--accept-terms-of-use \--datadir=$HOME/prysm-dev/beacon \--execution-endpoint=http://localhost:8551 \--jwt-secret=$HOME/ethereum/jwt.hex \--checkpoint-sync-url=https://sync-mainnet.beaconcha.in \--genesis-beacon-api-url=https://sync-mainnet.beaconcha.in -
Watch the logs. Bazel first builds anything that changed, then the node starts:
INFO db: Opening Bolt DB path=/home/<USER>/prysm-dev/beacon/beaconchaindata/beaconchain.dbINFO httprest: Starting HTTP server address=127.0.0.1:3500 -
Stop the node with
Ctrl+C, change the code, and run the same command again. Bazel rebuilds only the packages you changed.
bazel run starts the binary inside Bazel's runfiles directory, not your shell's current directory. A relative path such as --datadir=./data ends up under bazel-bin. Use absolute paths, $HOME, or a leading ~/, which Prysm expands itself.
Long flag lists are easier to keep in a YAML file passed with --config-file (refer to the Use a config file page for the format). Flags on the command line override the same keys in the file:
bazel run //cmd/beacon-chain -- --config-file=$HOME/prysm-dev/beacon.yaml
Run a validator client
Pick a testnet above. Never run a development build with mainnet keys.
Import testnet keys into a development wallet. bazel run works for every subcommand:
bazel run //cmd/validator -- accounts import \
--mainnet \
--accept-terms-of-use \
--keys-dir=<PATH_TO_KEYSTORES> \
--wallet-dir=$HOME/prysm-dev/wallet
Replace <PATH_TO_KEYSTORES> with the directory that holds your keystore-*.json files. Then start the validator client against your beacon node:
bazel run //cmd/validator -- \
--mainnet \
--accept-terms-of-use \
--datadir=$HOME/prysm-dev/validator \
--wallet-dir=$HOME/prysm-dev/wallet \
--wallet-password-file=<PASSWORD_FILE> \
--suggested-fee-recipient=<FEE_RECIPIENT_ADDRESS> \
--enable-doppelganger
Replace <PASSWORD_FILE> with a file containing the wallet password, and <FEE_RECIPIENT_ADDRESS> with your address. See Import keys and Set your fee recipient for details.
A development build can contain bugs that make a validator sign conflicting messages. Use testnet keys that aren't active anywhere else, and never run the same keys in two validator clients at once. See Avoid slashing.
Run the built binary directly
bazel run checks the build graph and holds the Bazel server while it builds. When you restart often without changing code, or want to run tests in another terminal, build once and run the output directly:
bazel build //cmd/beacon-chain
bazel-bin/cmd/beacon-chain/beacon-chain_/beacon-chain --config-file=$HOME/prysm-dev/beacon.yaml
Build options go before the target, as usual: bazel run --config=release //cmd/beacon-chain -- … runs an optimized build. See Build with Bazel for the configs.
Check that it works
Ask the beacon node for its version and sync status:
curl -s http://127.0.0.1:3500/eth/v1/node/version
curl -s http://127.0.0.1:3500/eth/v1/node/syncing
The version starts with Prysm/, and is_syncing turns false once the node has caught up.