This guide will provide you with a minimal instruction set if you intend to test:

• Spinning up a zhejiang testnet node using Geth&Lighthouse with Docker(-Compose)

• Exiting/withdrawing a validator on zhejiang testnet

• Preparing withdrawal credential changes

Feel free to check out elementary guides on how to run testnet nodes with the help of Docker or Docker-Compose.

Also, if you’re generally keen on running a production (or testnet) Ethereum node with Docker, check out the awesome eth-docker.net project.

• Very fast node initialisation time (i.e. no extended sync periods + takes less than 2GBs of disk space)

• Easy to obtain testnet ETH

• It’s a short-lived, public testnet particularly designed for brief operation tests

• Dry-run prior to more established testnets like Sepolia & Goerli which will follow in February/March ´23

As an example client pair we’ll use Geth & Lighthouse on an Ubuntu instance & pre-installed docker-compose - feel free to adapt to different client pairs using this documentation.

Navigate in a terminal/CLI to your user’s /home directory. Create a project directory with subfolders

$ mkdir -p zhejiang/{geth,lighthouse-bn,lighthouse-vc,JWT,validator_keys}; cd zhejiang

Retrieve configuration files for the zhejiang genesis from a repository maintained by the Ethereum Foundation

$ git clone https://github.com/ethpandaops/withdrawals-testnet.git

Generate a JasonWebToken (JWT) so that the execution and consensus client can communicate securely

$ openssl rand -hex 32 | tr -d "\n" > "$(pwd)/JWT/jwtsecret"

Provide Geth with the testnet genesis configuration

$ docker run -it -v $(pwd)/geth:/root/.ethereum -v $(pwd)/withdrawals-testnet/zhejiang-testnet/custom_config_data/genesis.json:/genesis.json ethpandaops/geth:master --datadir /root/.ethereum init genesis.json

Depending on your Docker configuration every Docker command should be preceded by sudo

Copy & paste the below attached Docker-Compose code in a newly created file to be named “docker-compose.yaml” located in the project directory /zhejiang 👇

Start the Docker-Compose environment

$ docker-compose up

Eventually, stop the docker-compose environment: $ docker-compose stop

For stopping only the beacon or execution or validator client services use:

$ docker-compose stop execution/consensus/validator

Steps 1-4 are well-documented elsewhere:

1. Add network to your local metmask

2. Receive 33 zETH from a faucet

3. Generate validator keys (e.g. with Staking-CLI) using 0x00 credentials (for test purposes)

4. Deposit via zhejiang launchpad

5. Look out for your validator on a block explorer

6. Move generated keys into project folder subdirectory /validator_keys

7. Import validator key(s) to Lighthouse

   👉 based of the project directory /zhejiang prompt:

$ docker run -it -v $(pwd)/lighthouse-vc:/root/.lighthouse -v $(pwd)/validator_keys:/validator_keys -v  $(pwd)/withdrawals-testnet/zhejiang-testnet/custom_config_data:/zhejiang sigp/lighthouse:capella lighthouse --testnet-dir zhejiang account validator import --directory /validator_keys

Provide the consensus client with the necessary information in order to be released from consensus duties.

While your validator client is running in the background prompt:

$ docker-compose run --rm --no-deps -v $(pwd)/lighthouse-vc:/root/.lighthouse -v $(pwd)/withdrawals-testnet/zhejiang-testnet/custom_config_data:/zhejiang consensus lighthouse --testnet-dir zhejiang account validator exit --beacon-node http://beacon:5052  --keystore /root/.lighthouse/custom/validators/<0x_yourvalidatorkey>/voting-keystore.json

Edit the validator key directory and voting-keystore.json filename accordingly

Note for mainnet: node operators have to keep on running their node until the validator reaches its assigned exit epoch (s. block explorer) - if it is shutdown too early, the validator will incur penalties.

…also known as “BLS to Execution” operation. This operation comprises of a message broadcast to the network which will lead to a change from the BLS withdrawal credentials (0x00) to a regular Ethereum address (0x01) of your choice.

Note: currently around ~60% or ~300,000 mainnet validators have BLS credentials and need to make a one-time change to a regular Ethereum address in order to fully or partially withdraw their stake or rewards.

Find out how to identify withdrawal credentials by entering a validator index on beaconcha.in:

If you want to test changing withdrawal credentials from 0x00 -> 0x01, check out these Docker instructions utilising a programm called ethdo by attestant.io.

The official Staking-Deposit-CLI by the EF will be updated and include similar functionality shortly.

👉 Broadcasting of your BLS-to-execution key change will NOT happen before the (Zhejiang) Shanghai/Capella fork scheduled for the 07th of February 3 p.m. UTC

timbeiko.eth

@TimBeiko

There were some config issues in launching the network, but the devops and client teams are looking into it. The Shapella fork is planned for Tuesday 3pm UTC

10

6:13 PM • Feb 2, 2023

Up until then the generated message is just stored in a local pool. Once Shanghai/Capella is triggered, the BLS-to-execution messages will be automatically broadcasted/gossiped over the network to your peers.

As soon as a node holding your BLS-to-execution message proposes a block, the message will be executed.

Note for mainnet:

• Be aware that changing withdrawal credentials involves providing withdrawal private keys. Thus,***never* trust* instructions from a random stranger writing blogposts on mirror.xyz or elsewhere - instead: follow official announcements from client teams and developers*

• BLS-to-execution messages cannot be broadcasted until after the Shanghai/Capella hard fork

• beaconcha.in have announced they will provide a web interface for dragging & dropping a signed credential-change.json file and submit it to the network

****

Please keep in mind this is a testnet guide that may contain mistakes and that takes shortcuts which come with trade-offs. It could quickly become outdated as it’s subject to ever evolving network and client changes.

****

featured image CC BY-NC 2.0 by Matthew Warner

********

This post was supported by a grant from a CLR funding round held by EthStaker, mainly matched by the EF.

This guide will provide you with a minimal instruction set if you intend to test:

• Spinning up a zhejiang testnet node using Geth&Lighthouse with Docker(-Compose)

• Exiting/withdrawing a validator on zhejiang testnet

• Preparing withdrawal credential changes

Feel free to check out elementary guides on how to run testnet nodes with the help of Docker or Docker-Compose.

Also, if you’re generally keen on running a production (or testnet) Ethereum node with Docker, check out the awesome eth-docker.net project.

• Very fast node initialisation time (i.e. no extended sync periods + takes less than 2GBs of disk space)

• Easy to obtain testnet ETH

• It’s a short-lived, public testnet particularly designed for brief operation tests

• Dry-run prior to more established testnets like Sepolia & Goerli which will follow in February/March ´23

As an example client pair we’ll use Geth & Lighthouse on an Ubuntu instance & pre-installed docker-compose - feel free to adapt to different client pairs using this documentation.

Navigate in a terminal/CLI to your user’s /home directory. Create a project directory with subfolders

$ mkdir -p zhejiang/{geth,lighthouse-bn,lighthouse-vc,JWT,validator_keys}; cd zhejiang

Retrieve configuration files for the zhejiang genesis from a repository maintained by the Ethereum Foundation

$ git clone https://github.com/ethpandaops/withdrawals-testnet.git

Generate a JasonWebToken (JWT) so that the execution and consensus client can communicate securely

$ openssl rand -hex 32 | tr -d "\n" > "$(pwd)/JWT/jwtsecret"

Provide Geth with the testnet genesis configuration

$ docker run -it -v $(pwd)/geth:/root/.ethereum -v $(pwd)/withdrawals-testnet/zhejiang-testnet/custom_config_data/genesis.json:/genesis.json ethpandaops/geth:master --datadir /root/.ethereum init genesis.json

Depending on your Docker configuration every Docker command should be preceded by sudo

Copy & paste the below attached Docker-Compose code in a newly created file to be named “docker-compose.yaml” located in the project directory /zhejiang 👇

Start the Docker-Compose environment

$ docker-compose up

Eventually, stop the docker-compose environment: $ docker-compose stop

For stopping only the beacon or execution or validator client services use:

$ docker-compose stop execution/consensus/validator

Steps 1-4 are well-documented elsewhere:

1. Add network to your local metmask

2. Receive 33 zETH from a faucet

3. Generate validator keys (e.g. with Staking-CLI) using 0x00 credentials (for test purposes)

4. Deposit via zhejiang launchpad

5. Look out for your validator on a block explorer

6. Move generated keys into project folder subdirectory /validator_keys

7. Import validator key(s) to Lighthouse

   👉 based of the project directory /zhejiang prompt:

$ docker run -it -v $(pwd)/lighthouse-vc:/root/.lighthouse -v $(pwd)/validator_keys:/validator_keys -v  $(pwd)/withdrawals-testnet/zhejiang-testnet/custom_config_data:/zhejiang sigp/lighthouse:capella lighthouse --testnet-dir zhejiang account validator import --directory /validator_keys

Provide the consensus client with the necessary information in order to be released from consensus duties.

While your validator client is running in the background prompt:

$ docker-compose run --rm --no-deps -v $(pwd)/lighthouse-vc:/root/.lighthouse -v $(pwd)/withdrawals-testnet/zhejiang-testnet/custom_config_data:/zhejiang consensus lighthouse --testnet-dir zhejiang account validator exit --beacon-node http://beacon:5052  --keystore /root/.lighthouse/custom/validators/<0x_yourvalidatorkey>/voting-keystore.json

Edit the validator key directory and voting-keystore.json filename accordingly

Note for mainnet: node operators have to keep on running their node until the validator reaches its assigned exit epoch (s. block explorer) - if it is shutdown too early, the validator will incur penalties.

…also known as “BLS to Execution” operation. This operation comprises of a message broadcast to the network which will lead to a change from the BLS withdrawal credentials (0x00) to a regular Ethereum address (0x01) of your choice.

Note: currently around ~60% or ~300,000 mainnet validators have BLS credentials and need to make a one-time change to a regular Ethereum address in order to fully or partially withdraw their stake or rewards.

Find out how to identify withdrawal credentials by entering a validator index on beaconcha.in:

If you want to test changing withdrawal credentials from 0x00 -> 0x01, check out these Docker instructions utilising a programm called ethdo by attestant.io.

The official Staking-Deposit-CLI by the EF will be updated and include similar functionality shortly.

👉 Broadcasting of your BLS-to-execution key change will NOT happen before the (Zhejiang) Shanghai/Capella fork scheduled for the 07th of February 3 p.m. UTC

timbeiko.eth

@TimBeiko

There were some config issues in launching the network, but the devops and client teams are looking into it. The Shapella fork is planned for Tuesday 3pm UTC

10

6:13 PM • Feb 2, 2023

Up until then the generated message is just stored in a local pool. Once Shanghai/Capella is triggered, the BLS-to-execution messages will be automatically broadcasted/gossiped over the network to your peers.

As soon as a node holding your BLS-to-execution message proposes a block, the message will be executed.

Note for mainnet:

• Be aware that changing withdrawal credentials involves providing withdrawal private keys. Thus,***never* trust* instructions from a random stranger writing blogposts on mirror.xyz or elsewhere - instead: follow official announcements from client teams and developers*

• BLS-to-execution messages cannot be broadcasted until after the Shanghai/Capella hard fork

• beaconcha.in have announced they will provide a web interface for dragging & dropping a signed credential-change.json file and submit it to the network

****

Please keep in mind this is a testnet guide that may contain mistakes and that takes shortcuts which come with trade-offs. It could quickly become outdated as it’s subject to ever evolving network and client changes.

****

featured image CC BY-NC 2.0 by Matthew Warner

********

This post was supported by a grant from a CLR funding round held by EthStaker, mainly matched by the EF.