This chapter will take you through how to become a validator on the eth2 testnet Medalla.
If you generated your signing key using the eth2 launchpad, and wish to import it into the Nimbus client, this page is for you.
If you're an advanced user running Ubuntu, we recommend you check out this excellent and complementary guide.
If this is your first time playing with Nimbus, make sure you install our external dependencies first.
This tutorial assumes basic knowledge of the command line.
To start validating on the
git clone https://github.com/status-im/nim-beacon-chain cd nim-beacon-chain
Patience... this may take a few minutes.
build/beacon_node deposits import --data-dir=build/data/shared_medalla_0 <YOUR VALIDATOR KEYS DIRECTORY>
<YOUR VALIDATOR KEYS DIRECTORY> with the full pathname of your
validator_keysdirectory to print the full pathname to the console.
You'll be asked to enter the password you created to encrypt your keystore(s) in the Generate Keys section of the Launchpad process. Don't worry, this is entirely normal. Your validator client needs both your keystore(s) and the password encrypting it to import your keys (since it needs to decrypt the keystore in order to be able to use it to sign on your behalf).
This will build Nimbus and its dependencies, and connect you to Medalla. You should see that the beacon node has launched with your validator attached:
WRN 2020-08-03 16:24:17.950+02:00 Validator not in registry (yet?) topics="beacval" tid=11677993 file=validator_duties.nim:53 pubKey=a9c4df36 INF 2020-08-03 16:24:17.951+02:00 Local validator attached tid=11677993 file=validator_pool.nim:21 pubKey=a9c4df36 validator=a9c4df36 INF 2020-08-03 16:24:17.951+02:00 Local validators attached topics="beacval" tid=11677993 file=validator_duties.nim:61 count=1 INF 2020-08-03 16:24:17.958+02:00 Starting beacon node topics="beacnde" tid=11677993 file=beacon_node.nim:875 version="0.5.0 (31b33907)" nim="Nim Compiler Version 1.2.6 [MacOSX: amd64] (bf320ed1)" timeSinceFinalization=81350 head=ebe49843:0 finalizedHead=ebe49843:0 SLOTS_PER_EPOCH=32 SECONDS_PER_SLOT=12 SPEC_VERSION=0.12.2 dataDir=build/data/shared_medalla_0 pcs=start_beacon_node
Tip: to 🎨 on the graffitwall, pass the graffiti parameter like this:
make NODE_PARAMS="--graffiti='<YOUR_GRAFFITI>'" medalla
If you deposited after the genesis state was decided (August 2nd 1300 UTC), your validators will have been put in a queue based on deposit time, and will slowly be inducted into the validator set after genesis. Getting through the queue may take a few hours or days.
The best way to keep track of your validator's status is medalla.beaconcha.in (click on the orange magnifying glass at the very top and paste in its public key).
To keep track of your syncing progress, have a look at the output at the very bottom of the terminal window in which your validator is running. You should see something like:
peers: 35 ❯ finalized: ada7228a:8765 ❯ head: b2fe11cd:8767:2 ❯ time: 9900:7 (316807) ❯ sync: wPwwwwwDwwDPwPPPwwww:7:4.0627 (280512)
peerstells you how many peers you're currently connected to (in the above case, 35 peers)
finalizedtells you the most recent finalized epoch you've synced to so far (the 8765th epoch)
headtells you the most recent slot you've synced to so far (the 2nd slot of the 8767th epoch)
timetells you the current time since Genesis (the 7th slot of the 9900th epoch -- or equivalently, the 316,807th slot)
synctells you how fast you're syncing (4.0627 blocks per second), how many blocks you've synced so far (280,512), along with information about 20 sync workers linked to the 20 most performant peers you are currently connected to (represented by a string of letters and a number).
To dig into
sync a little:
sync: <sync worker map>:<number of active workers>:<current syncing speed in blocks/second>
The string of letters -- what we call the
sync worker map (in the above case represented by
wPwwwwwDwwDPwPPPwwww) represents the status of the sync workers mentioned above, where:
s - sleeping (idle), w - waiting for a peer from PeerPool, R - requesting blocks from peer D - downloading blocks from peer P - processing/verifying blocks U - updating peer's status information
The number following it (in the above case represented by
7) represents the number of workers that are currently active (i.e not sleeping or waiting for a peer).
Finally, makes sure you stay on the lookout for any critical updates to Nimbus. This best way to do so is through the medalla-announcements channel on our discord.
To update to the latest version, disconnect from medalla and run:
git pull && make update
Once the update is complete, run
make medalla to reconnect to the network.
Looking forward to seeing you on Medalla! 💛
Keys are stored in the
build/data/shared_medalla_0/ folder, under
validators - make sure you keep these folders backed up.
secrets folder contains the common secret that gives you access to all your validator keys.
validators folder contains your keystores (encrypted keys). Keystores are used by validators as a method for exchanging keys. For more on keys and keystores, see here.
Note: The Nimbus client will only ever import your signing key -- in any case, if you used the deposit launchpad, this is the only key you should have (you can generate the withdrawal key from your mnemonic when you wish to withdraw).
Metrics are not included in the binary by default - to enable them, use the following options when starting the client:
make NIMFLAGS="-d:insecure" medalla
You can then browse the metrics by connecting to:
Make sure this port is protected as the http server used is not considered secure (it should not be used by untrusted peers).
For instructions on how to spin up a beautiful and useful monitoring dashboard for your validator and beacon node, see this page.
You can start multiple local nodes, in different terminal windows/tabs, by specifying numeric IDs:
make medalla NODE_ID=0 # the default make medalla NODE_ID=1 make medalla NODE_ID=2
Simply import as many keystores as you wish before running
make medalla. Nimbus will automagically find your keys and attach your validators. See key management for more information on where we store your keys.
To give you some context, we (the Nimbus team) are currently running 170 validators per beacon node on our AWS instances.
To change the TCP and UDP ports from their default value of 9000 to 9100, say, run:
make BASE_PORT=9100 medalla
You may need to do this if you are running another client.
make medalla-deposit VALIDATORS=2 # default is just 1
You can customise your beacon node's parameters using the
make NODE_PARAMS="--tcp-port=9100 --udp-port=9100" medalla
Note: the above command has exactly the same effect as
make BASE_PORT=9100 medalla
A complete list of the available parameters can be found here (use a parameter's
name field to set it).
Log files are saved in
Some of the provided options (such as
--network=medalla) are essential while others (such as the ones controlling logging, metrics, ports, and the RPC service) are there for convenience.
The Goerli testnet parameters (
$(GOERLI_TESTNETS_PARAMS), are defined higher up in the Makefile, here.