🦏
ETH Home Staking Collection
DVT Home Staking Curriculum
DVT Home Staking Curriculum
  • The DVT Home Staking Curriculum
  • Curriculum breakdown & timeline
  • Understanding ETH validators
    • Introduction to ETH Validators
    • Roles & Responsibilities of a node operator
    • Rewards and penalties
    • Importance of client diversity
    • Distributed Validator Technologies (DVTs)
    • Economics of using DVTs (WIP)
      • Diva Staking (WIP)
      • Obol (WIP)
      • SSV (WIP)
    • Bonded Validators
    • Economics of bonded validators (WIP)
  • Hardware & systems setup
    • Setup Overview
    • Hardware & system requirements
    • Procuring your hardware
    • Assemble your hardware
    • Practicing for free on Cloud VMs
      • Google Cloud
      • Alibaba Cloud
  • Linux OS, Networking, & Security
    • Install and prepare the OS
    • Networking & network security
    • Device level security setup
    • Verifying checksums
  • Installing & configuring your EL+CL clients
    • Set up and configure execution layer client
      • Nethermind
      • Besu
      • Geth
      • Erigon
      • Reth
    • Set up and configure consensus layer client
      • Teku BN
      • Nimbus BN
      • Lodestar BN
      • Lighthouse BN
      • Prysm BN
  • Keystore generation & MEV-Boost
    • Validator key generation
    • Set up and configure MEV-boost
  • Native Solo Staking Setup
    • Validator client setup
      • Teku VC
      • Nimbus VC
      • Lodestar VC
      • Lighthouse VC
      • Prysm VC
    • Depositing 32 ETH into your validator
    • Exiting your validator
  • Monitoring, Maintenance, and Updates
    • Set up monitoring suite
      • Installing & configuring Prometheus
      • Installing & configuring Node Exporter
      • Installing & configuring Grafana
      • Beaconcha.in App API
      • Client Uptime Check
    • Maintenance & Updates
      • Nethermind
      • Besu
      • Teku
      • Nimbus
      • Lodestar
      • Updating the monitoring suite
      • Preparing for Pectra
  • DVT Setup
    • Diva Staking
      • Diva Staking client setup
        • Default - All-in-one setup
        • Advanced - with standalone Lodestar VC
      • Registering your Diva node
      • Updating your Diva client
      • Monitoring your Diva Node
    • Obol
      • Techne Bronze Speedrun (Launchpad)
      • Obol + Bonded Validators (Techne Silver)
        • Obol + Lido CSM
    • SSV
      • SSV + Lido CSM (WIP)
      • SSV Operator
      • SSV Staker
  • Bonded Validators Setup
    • Lido CSM
      • Generating CSM keystores
      • Set Fee Recipient Address
        • Method 1: Configure on validator keys
        • Method 2: Configure on separate validator client
        • Verifying Fee Recipient Registered on MEV Relays
      • Upload/Remove/View validator keys
      • Rewards & bonds
      • Exiting CSM validators
        • "Lazy" exits (TESTNET ONLY)
        • Proper Exits
      • Role/Address management
      • Monitoring
      • Automations
        • CSM with ETHPillar
        • CSM with ETH Docker
        • CSM with Dappnode
    • Puffer
      • Non-Enclave: 2 ETH
    • Ether.fi
      • Receive distributed validator keyshares
    • Stader (WIP)
    • Rocketpool (WIP)
  • Liquid Staking Vaults
    • Stakewise V3
  • Mainnet
    • Mainnet Deployment
    • Heroglpyhs (WIP)
  • Best practices
    • Slashing prevention
    • Maximising uptime and performance
    • Optimising security
    • Managing your withdrawal wallet
  • Tips
    • Advanced networking
    • Downloading files from your node
  • Useful resources
    • General resources
    • Holesky Faucets
  • Automation/tools
    • ETHPillar
    • ETH Docker
    • Automated power on/off
      • Wake-on-LAN (WoL)
      • Network UPS Tools (NUT)
    • Validator Healthcheck Alerts
  • Solo Stakers Guild
    • Lido CSM+SSV+Obol (Testnet)
Powered by GitBook
On this page
  • Install the dependencies - Java Runtime Environment
  • Download Teku
  • Configure the Teku Consensus Client
  • Start the Teku Consensus Client
  • Verify the Initial State roots (Checkpoint Sync)
  • Resources
  1. Installing & configuring your EL+CL clients
  2. Set up and configure consensus layer client

Teku BN

PreviousSet up and configure consensus layer clientNextNimbus BN

Last updated 5 months ago

Install the dependencies - Java Runtime Environment

sudo apt-get update
sudo add-apt-repository ppa:openjdk-r/ppa
sudo apt-get -y install openjdk-21-jre libjemalloc-dev

Download Teku

the latest version of Teku and run the checksum verification process to ensure that the downloaded file has not been tampered with.

cd
curl -LO https://artifacts.consensys.net/public/teku/raw/names/teku.tar.gz/versions/24.10.2/teku-24.10.2.tar.gz
echo "1cc76913f3b85987e2a60c9b94c6918d31773ebd3237c5fdf33de366fa259202 teku-24.10.2.tar.gz" | sha256sum --check

Each downloadable file comes with it's own checksum. Replace the actual checksum and URL of the download link in the code block above.

Make sure to choose the amd64 version. Right click on the linked text and select "copy link address" to get the URL of the download link to curl.

Expected output: Verify output of the checksum verification.

teku-24.10.2.tar.gz: OK

If checksum is verified, extract the files and move them into the (/usr/local/bin) directory for neatness and best practice. Then, clean up the duplicated copies.

tar xvf teku-24.10.2.tar.gz
sudo cp -a teku-24.10.2 /usr/local/bin/teku
rm -r teku*

Configure the Teku Consensus Client

We will be running the consensus client and validator client of Teku as separate services so that there is more flexibility to configure a failover node for maximum uptime when you decide it is needed.

Create an account (teku) without server access for the Teku Consensus Client & Validator Client to run as a background service. This type of user account will not have root access so it restricts potential attackers to only the Teku Consensus Client & Validator Client services in the unlikely event that they manage to infiltrate via a compromised client update.

sudo useradd --no-create-home --shell /bin/false teku

Create a directory for Teku to store the blockchain and validator data of the Consensus layer. Move the validator_keys directory into this folder. Then set the owner of this directory to the teku so that this user can read and write to the directory.

sudo mkdir -p /var/lib/teku_beacon
sudo chown -R teku:teku /var/lib/teku_beacon
sudo chmod 700 /var/lib/teku_beacon

If there are no errors, create a systemd configuration file for the Teku Consensus Client service to run in the background.

sudo nano /etc/systemd/system/tekubeacon.service

Paste the configuration parameters below into the file:

[Unit]
Description=Teku Beacon Node (Holesky)
Wants=network-online.target
After=network-online.target
[Service]
User=teku
Group=teku
Type=simple
Restart=always
RestartSec=5
Environment="JAVA_OPTS=-Xmx6g"
Environment="TEKU_OPTS=-XX:-HeapDumpOnOutOfMemoryError"
ExecStart=/usr/local/bin/teku/bin/teku \
  --network=holesky \
  --data-path=/var/lib/teku_beacon \
  --ee-endpoint=http://127.0.0.1:8551 \
  --ee-jwt-secret-file=/var/lib/jwtsecret/jwt.hex \
  --initial-state=https://holesky.beaconstate.ethstaker.cc/ \
  --metrics-enabled=true \
  --metrics-port=8008 \
  --p2p-port=9000 \
  --rest-api-enabled=true \
  --rest-api-interface=0.0.0.0 \
  --rest-api-host-allowlist=<Internal_IP_address> \
  --rest-api-port=5052 \
  --builder-endpoint=http://127.0.0.1:18550 \
  --validators-builder-registration-default-enabled=true \
  --builder-bid-compare-factor=100 \
  --p2p-nat-method=UPNP 

[Install]
WantedBy=multi-user.target

Once you're done, save with Ctrl+O and Enter, then exit with Ctrl+X. Understand and review your configuration summary below, and amend if needed.

Teku Consensus Client configuration summary:

  1. --network: Run the Consensus Client service on the ETH Holesky testnet

  2. --data-path: Specify the directory for Teku to store data related to the consensus client

  3. --ee-endpoint: URL to connect to the execution layer client

  4. --ee-jwt-secret: File path to locate the JWT secret we generated earlier

  5. --metrics-enabled: Enable monitoring of Consensus Client metrics

  6. --p2p-port: Sets the port for peer-to-peer communication. Defaults to 9000.

  7. --rest-api-enabled: Allows the validator client to connect to this consensus client. Also allows monitoring endpoints to pull metrics from this service

  8. --rest-api-interface: Sets the IP address to connect to the REST API of the consensus client that will be used by the DVT clients. Use 0.0.0.0 here and restrict to specific host IP addresses of your device using --rest-api-host-allowlist.

  9. --rest-api-host-allowlist: Sets the IP address that is allowed to connect to the REST API of the consensus client that will be used by the DVT clients. Use the internal IP address of your device here (check by running ip a) - e.g. 192.168.x.x. Defaults to 127.0.0.1 otherwise

  10. --rest-api-port: Sets the port to connect to the consensus client

  11. --builder-endpoint: URL to connect to external builders (e.g. MEV relays)

  12. --validators-builder-registration-default-enabled: Required when using external builders to build blocks (e.g. MEV relays)

  13. --builder-bid-compare-factor: What is the multiplier (in %) of the value of externally-built blocks in order to outsource block building vs building blocks locally. Set to 100 to be indifferent. Default =90

  14. --p2p-nat-method=UPNP: Enables your Consensus Client to better discover and connect to other Consensus Clients in the ETH network without needing to use port forwarding

Start the Teku Consensus Client

Reload systemd to register the changes made, start the Teku Consensus Client service, and check its status to make sure its running.

sudo systemctl daemon-reload
sudo systemctl start tekubeacon.service
sudo systemctl status tekubeacon.service

Expected output: The output should say Teku Consensus Client is “active (running)”. Press CTRL-C to exit and Teku Consensus Client will continue to run. It should take just a few minutes for Teku to sync on the Mainnet.

Use the following command to check the logs of Teku Consensus Client’s syncing process. Watch out for any warnings or errors.

sudo journalctl -fu tekubeacon -o cat | ccze -A

Expected output:

Press Ctrl+C to exit monitoring.

If the Teku Consensus Client service is running smoothly, we can now enable it to fire up automatically when rebooting the system.

sudo systemctl enable tekubeacon.service

Verify the Initial State roots (Checkpoint Sync)

  1. Verify the Block Root and State Root with your journalctl output

  2. journalctl output

Resources

--initial-state: Enables nearly instant syncing of the Consensus Client by pointing to one of the checkpoint sync URLs here -

Go to on your browser and search for the slot number (slot).

Releases:

Documentation:

Discord: (Select the Teku channel)

Download
https://eth-clients.github.io/checkpoint-sync-endpoints/
https://holesky.beaconcha.in/
https://github.com/Consensys/teku/releases
https://docs.teku.consensys.io/introduction
https://discord.gg/consensys
Example output of the Teku consensus client running on the mainnet
This example runs on the goerli testnet. You should see a different initial state URL being printed on Holesky.
testnet example: prater.beaconcha.in