Overview: To participate in the public testnet known as Zhejiang, the first public effort to test Ethereum’s upgrade to enabling validator withdrawals with a hardfork called "Shanghai-Capella" or also known as EIP 4855.
Goals: To test your staking setups, practice voluntary exits and validator withdrawals.
Staked ETH: With the new ability to withdraw staked ETH since beacon chain genesis on December 1 2020, this upgrade to Ethereum POS will add flexibility and attract the next wave of stakers and innovation.
Client Diversity: Within the Ethereum network of nodes, you want to improve Ethereum's client diversity by choosing a minority execution and consensus client combination.
Timeline: Assuming this testnet is thoroughly tested, mainnet Ethereum could be upgraded sometime in March 2023.
As of early February 2023, Besu is the most minority execution client with 6.8% of nodes. Lodestar is by far the most minority consensus client with 0.29% representation.
How Staking on Ethereum Works
Acquire some hardware (laptop, desktop, server) or rent a VPS (cloud server): You need to run a node to stake.
Sync an execution layer client
Sync a consensus layer client
Generate your validator keys and import them into your validator client
Monitor and maintain your node
A Ethereum node consists of the Execution Layer + Consensus Layer.
A Ethereum Staking node is the previous plus a Validator client.
Prerequisites
This guide was written for aspiring Ethereum stakers who have basic familiarity with command line tools and it was tested against Ubuntu 22.04.1 LTS client. You’ll want a dedicated cloud VPS or local desktop/server/laptop running a clean install of Ubuntu preferably.
If using a VPS or remote server, install and start the SSH client for your operating system:
Pro Staking Tip: Highly recommend you begin with a brand new instance of an OS, VM, and/or machine. Avoid headaches by NOT reusing testnet keys, wallets, or databases for your validator.
Wait a few seconds, then verify that Chrony is syncing time.
chronyc tracking
Step 4. Download Zhejiang configuration files
#Setup git directory
mkdir ~/git && cd ~/git
#Clone the testnet config files
git clone https://github.com/ethpandaops/withdrawals-testnet.git
#Make a directory to store config files
sudo mkdir -p /var/lib/ethereum/zhejiang
#Copy config files to default location
sudo cp -R ~/git/withdrawals-testnet/zhejiang-testnet/custom_config_data /var/lib/ethereum/zhejiang
Step 5. Setup Execution Layer Client
Setup your execution layer client, your choice of Nethermind, Erigon, Geth or Besu.
Only one execution layer client is required per node.
Hyperledger Besu is an open-source Ethereum client designed for demanding enterprise applications requiring secure, high-performance transaction processing in a private network. It's developed under the Apache 2.0 license and written in Java.
Nethermind is all about performance and flexibility. Built on .NET core, a widespread, enterprise-friendly platform, Nethermind makes integration with existing infrastructures simple, without losing sight of stability, reliability, data integrity, and security.
Erigon is an implementation of Ethereum innovating on the efficiency frontier, written in Go.
Geth - Go-ethereum (aka Geth) is an Ethereum client built in Go. It is one of the original and most popular Ethereum clients.
sudo cp -a $HOME/nethermind /usr/local/bin/nethermind
Download the testnet configs.
cd /usr/local/bin/nethermind/configs
wget https://raw.githubusercontent.com/NethermindEth/nethermind/master/src/Nethermind/Nethermind.Runner/configs/withdrawals_devnet.cfg
Create a service user for the execution service, as this improves security, then create data directories.
Generate the JWT secret, a file used by both the execution and consensus client, add read access privileges for the consensus client and setup ownership permissions
Generate the JWT secret, a file used by both the execution and consensus client, add read access privileges for the consensus client and setup ownership permissions
Generate the JWT secret, a file used by both the execution and consensus client, add read access privileges for the consensus client and setup ownership permissions
Generate the JWT secret, a file used by both the execution and consensus client, add read access privileges for the consensus client and setup ownership permissions
Finally, start your execution layer client and check it's status.
sudo systemctl start execution
sudo systemctl status execution
Press Ctrl + C to exit the status.
Step 6. Setup Consensus Layer Client
To strengthen Ethereum's resilience against potential attacks or consensus bugs, it's best practice to run a minority client in order to increase client diversity. Find the latest distribution of consensus clients here: https://clientdiversity.org
Lodestaris a Typescript implementation by the Chainsafe.io team. In addition to the beacon chain client, the team is also working on 22 packages and libraries. Finally, the Lodestar team is leading the Ethereum space in light client research and development and has received funding from the EF and Moloch DAO for this purpose.
Lighthouse is an Ethereum client with a heavy focus on speed and security. The team behind it, Sigma Prime is an information security and software engineering firm who have funded Lighthouse along with the Ethereum Foundation, Consensys, and private individuals. Lighthouse is built in Rust and offered under an Apache 2.0 License.
Teku is a Java-based Ethereum 2.0 client designed & built to meet institutional needs and security requirements. Dedicated to building enterprise-ready clients and tools for interacting with the core Ethereum platform, Teku is Apache 2 licensed and written in Java, a language notable for its maturity & ubiquity.
Nimbus is a research project and a client implementation for Ethereum 2.0 designed to perform well on embedded systems and personal mobile devices, including older smartphones with resource-restricted hardware. The Nimbus team are from Status the company best known for their messaging app/wallet/Web3 browser by the same name. Nimbus (Apache 2) is written in Nim, a language with Python-like syntax that compiles to C.
Prysm is a Go implementation of Ethereum 2.0 protocol with a focus on usability, security, and reliability. Prysm is developed by Prysmatic Labs, a company with the sole focus on the development of their client. Prysm is written in Go and released under a GPL-3.0 license.
Install Lighthouse Consensus Client
Install rust dependency
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
When prompted, enter '1' to proceed with the default install.
Finally, start your consensus layer client and check it's status.
sudo systemctl start consensus
sudo systemctl status consensus
Press Ctrl + C to exit the status.
Check your logs to confirm that the execution and consensus clients are up and syncing.
journalctl -fu execution | ccze
journalctl -fu consensus | ccze
Example of Synced Execution Client Logs
Nethermind
A properly functioning Nethermind execution client will indicate "block nnn ... was processed". For example,
Nethermind.Runner[2]: 2023-02-03 00:01:36.2643|FCU - block 16001 (fd781...c2e19f) was processed.
Nethermind.Runner[2]: 2023-02-03 00:01:36.2643|Block 0xd78eaabc854f4e4a844c5c0f9ccf45bed0b2f13d77ea978af62d0eef2210c2e19f was set as head.
Erigon
A properly functioning Erigon execution client will indicate "Handling new payload". For example,
erigon[41]: [INFO] [02-04|01:36:50.362] [2/15 Headers] Waiting for Consensus Layer...
erigon[41]: [INFO] [02-04|01:37:00.273] [2/15 Headers] Handling new payload height=14001 hash=0x1b2476a50d976536c2846a907ceb4f88cff4d0129ad...
Geth
A properly functioning Geth execution client will indicate "Imported new potential chain segment". For example,
geth[4531]: INFO [02-04|01:20:48.280] Chain head was updated number=16000 hash=2317ae..c41107
geth[4531]: INFO [02-04|01:20:49.648] Imported new potential chain segment number=16000 hash=ab173f..33a21b
Besu
A properly functioning Besu execution client will indicate "Fork-Choice-Updates". For example,
Known error in Lodestar/Besu consensus logs: As noted in Lodestar's discord, there will be a noisy error about updating eth1 chain cache. This does not seem to affect node syncing or validator duties.
Example error output:
error: Error updating eth1 chain cache JSON RPC error: Number of requests exceeds max batch size, batch Error: JSON RPC error: Number of requests exceeds max batch size, batch at JsonRpcHttpClient.fetchBatch (file:///usr/local/bin/lodestar/packages/beacon-node/src/eth1/provider/jsonRpcHttpClient.ts:151:15) at processTicksAndRejections (node:internal/process/task_queues:95:5) at Eth1Provider.getBlocksByNumber...
Example of Synced Consensus Client Logs
Lodestar Consensus
A properly functioning Lodestar consensus client will indicate "info: Synced". For example,
Use the Testnet faucet to acquire at least 32 Zhejiang testnet ETH for 1 validator. It may take a few moments, sometimes up to an hour, for the funds to appear in your wallet. Or request funds from the ethStaker Discord in the #request-zhejiang-eth channel. Alternatively, use the POW faucet by pk910
For security and privacy reasons, it is best practice to use a brand new unused ETH address for these testnet activities. Avoid re-using any of your existing mainnet ETH addresses.
Step 8. Generate Validator Keys
With two easy methods, your can setup your mnemonic keys with either:
cd $HOME
wget https://github.com/ethereum/staking-deposit-cli/releases/download/v2.4.0/staking_deposit-cli-ef89710-linux-amd64.tar.gz
Verify the SHA256 Checksum matches the checksum on the releases page.
echo "c2b12a9e515f904ca359ec39dfbd7022dfefe881c1796ce42319df0a2da05560 *staking_deposit-cli-ef89710-linux-amd64.tar.gz" | shasum -a 256 --check
Example valid output:
staking_deposit-cli-ef89710-linux-amd64.tar.gz: OK
Only proceed if the sha256 check passes with OK!
Extract the archive.
tar xvf staking_deposit-cli-ef89710-linux-amd64.tar.gz
mv staking_deposit-cli-ef89710-linux-amd64 staking-deposit-cli
cd staking-deposit-cli
Make a new mnemonic and replace <ETH_ADDRESS_FROM_IDEALLY_HARDWARE_WALLET> with your ethereum withdrawal address, ideally from a Trezor, Ledger or comparable hardware wallet. Adjust number of validators accordingly.
Run the following, in case of this error: RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment.
export LC_ALL=C.UTF-8
export LANG=C.UTF-8
Wagyu Instructions
For the Wagyu key gen app, make sure to select the Zhejiang network and follow the guided steps.
Wagyu (formerly known as StakeHouse) is an application aimed at lowering the technical bar to staking on Ethereum 2.0.
If using rsync, copy your validator keys from your local computer to your staking node with the following command. Change ssh port if needed.
rsync -a "ssh -p 22" <directory-with-keys>/*.json <username>@<remote_host>:/home/<username>/staking-deposit-cli/validator_keys
Don't lose your keystore password and write down your 24 word secret mnemonic key! Ideally keep this offline but for testnet purposes it's okay to save digitally for your convenience.
Step 9. Sign up to be a Validator at the Launchpad
After running the staking deposit tool, you will have a deposit_data-##########.json file which you'll upload to the Launchpad.
Your deposit_data file is located in the following location:
ls $HOME/staking-deposit-cli/validator_keys
Ensure your MetaMask is switched to the Zhejiang Testnet network.
Follow along the instructions at the Launchpad. You'll complete this process when you've uploaded your deposit_data-##########.json file and sent the corresponding 32 Zhejiang testnet ETH deposit to the Zhejiang staking deposit address.
The Zhejiang network staking deposit address is 0x4242424242424242424242424242424242424242
After sending the deposit with Metamask, verify your deposit was completed on a block explorer.
Step 10. Setup Validator Client
Setup Lighthouse Validator
Create a service user for the validator service, as this improves security, then create data directories.
Storing your keystore password in a text file is required so that Teku can decrypt and load your validators automatically.
Create a file to store your keystore password. Type your password in this file.
nano $HOME/validators-password.txt
To exit and save, press Ctrl + X, then Y, then Enter.
Confirm that your keystore password is correct.
cat $HOME/validators-password.txt
When specifying directories for your validator-keys, Teku expects to find identically named keystore and password files.
For example keystore-m_12221_3600_1_0_0-11222333.json and keystore-m_12221_3600_1_0_0-11222333.txt
Run the following command to create a corresponding password file for every one of your validators.
for f in /var/lib/teku/validator_keys/zhejiang/keystore*.json; do cp $HOME/validators-password.txt /var/lib/teku/validator_keys/zhejiang/$(basename $f .json).txt; done
Setup ownership permissions, including hardening the access to this directory.
Verify that your keystore file was imported successfully.
cd /usr/local/bin/prysm
sudo bazel run //validator:validator -- accounts list \
--wallet-dir=/var/lib/prysm/zhejiang/validator-data
Once successful, you will be shown your validator's public key. For example:
Showing 1 validator account
View the eth1 deposit transaction data for your accounts by running `validator accounts list --show-deposit-data`
Account 0 | strictly-pro-puma
[validating public key] 0x8d9138fcf5676e2031dc4eae30a2c92e3306903eeec83ca83f4f851afbd4cb3b33f710e6f4ac516b4598697b30b04302
Monitor your validator's status and performance at https://zhejiang.beaconcha.in by entering your validator's public key.
Create a systemd unit file to define your validator.service configuration.
sudo nano /etc/systemd/system/validator.service
Paste the following configuration into the file. Replace <enter-eth-address-here> with your suggested fee recipient ETH address.
If you wish to customize a graffiti message that is included when you produce a block, add your message between the double quotes after --graffiti.
Finally, start your validator client and check it's status.
sudo systemctl start validator
sudo systemctl status validator
Check your logs to confirm that the validator clients are up and functioning.
journalctl -fu validator | ccze
Example of Synced Validator Client Logs
Lodestar Validator
A properly functioning Lodestar validator will indicate publishing of attestations. For example,
Feb-1 03:33:30.228 info: Published aggregateAndProofs slot=2662, index=13, count=1
Feb-1 03:37:48.393 info: Published attestations slot=2699, index=20, count=1
Feb-1 03:46:36.450 info: Published attestations slot=2713, index=2, count=1
Feb-1 03:53:48.944 info: Published attestations slot=2765, index=21, count=1
Feb-1 04:01:48.812 info: Published attestations slot=2809, index=17, count=1
Lighthouse Validator
Feb 08 01:01:0 INFO Successfully published attestations type: unaggregated, slot: 12422, committee_index: 3, head_block: 0xabc111daedf1281..., validator_indices: [12345], count:1, service: attestation
Feb 08 01:01:30 INFO Connected to beacon node(s) synced: 1, available: 1, total: 1, service: notifier
Teku Validator
teku[65367]: 03:50:51.761 INFO - Validator cc1f3ade status is active_ongoing.
teku[65367]: 03:50:52.203 INFO - Validator *** Published attestation Count: 1, Slot: 31362, Root: 90FC0DF4D5958E469134A015203B53B3FB94A0FC1038FB2462882906D4A729A2
After making your 32 ETH deposit, your validator is placed into queue for activation which typically takes 6-24 hours. Once activated, your validator begins staking and attestation duties. Learn more about the depositing process.
I stand upon the shoulders of giants and as such, invite you to stand upon mine. Use my work with or without attribution; I make no claim of "intellectual property." My ideas are the result of countless millenia of evolution - they belong to humanity.
Congrats on setting up your Zhejiang “Withdrawals” staking node!
