# How To: Checkpoint Sync This guide covers the additional steps required to checkpoint sync a beacon node from another beacon node that you trust. This guide _does not_ cover setting up an entire node from scratch. :::warning :warning: You should always verify that your beacon node is synced correctly after doing a checkpoint sync. Check [Step 4](#Step-4) for instructions ::: More reading on checkpoint sync: - https://www.symphonious.net/2022/05/21/checkpoint-sync-safety/ - https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/ - https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/ - https://notes.ethereum.org/@djrtwo/ws-sync-in-practice ## EF DevOps Endpoints The EF DevOps team runs a handful of endpoints to help with syncing a testnet node. `Goerli/Prater`: https://goerli.checkpoint-sync.ethpandaops.io `Sepolia`: https://sepolia.checkpoint-sync.ethpandaops.io ## Tutorial ### Step 1 Note down the beacon endpoint you're planning to checkpoint sync from. This can be another beacon node you run, a beacon node that a friend runs, one of the endpoints above, or any beacon node you trust. > Note: The source beacon node *must* be for the same Ethereum network as your beacon node. For this tutorial we will use the EF DevOps Goerli endpoint (https://goerli.checkpoint-sync.ethpandaops.io) ### Step 2 Add the checkpoint sync argument to your client. The flag is different between clients. #### Prysm ``` --checkpoint-sync-url=https://goerli.checkpoint-sync.ethpandaops.io --genesis-beacon-api-url=https://goerli.checkpoint-sync.ethpandaops.io ``` #### Lighthouse ``` --checkpoint-sync-url=https://goerli.checkpoint-sync.ethpandaops.io ``` #### Teku ``` --initial-state=https://goerli.checkpoint-sync.ethpandaops.io/eth/v2/debug/beacon/states/finalized ``` #### Lodestar ``` --checkpointSyncUrl=https://goerli.checkpoint-sync.ethpandaops.io ``` #### Nimbus Requires the `trustedNodeSync` command to be run before the beacon is launched. Read more here: https://nimbus.guide/trusted-node-sync.html ### Step 3 Start your client. Once started, check your logs for details surrounding the checkpoint process. > Note: You must be starting your client with a fresh data directory/database #### Prysm ``` level=info msg="requesting https://goerli.checkpoint-sync.ethpandaops.io/eth/v2/debug/beacon/states/genesis" level=info msg="requesting https://goerli.checkpoint-sync.ethpandaops.io/eth/v2/debug/beacon/states/finalized" ``` #### Lighthouse ``` INFO Starting checkpoint sync remote_url: https://goerli.checkpoint-sync.ethpandaops.io, service: beacon INFO Loaded checkpoint block and state state_root: 0xb6e8c25393411f252775f82b4907298572003ac37acf9422dd2500b5c368a08d, block_root: 0xefe19ea0d99bf45d50d4302f6bbc3feb2c1ec46f8d6e112594ec86b9581596ae, slot: 3480832, service: beacon ``` #### Teku ``` INFO - Loading initial state from https://goerli.checkpoint-sync.ethpandaops.io/eth/v2/debug/beacon/states/finalized INFO - Loaded initial state at epoch 11348 (state root = 0x08dab651bd667b166a0c99b7a21ee455f4f9fadfce0e37dbcee490f5ec841477, block root = 0xa5bd8b3eaadd81f892f120219f3bcee6565a37d045bf0cee4c4023a51def430c, block slot = 363136). Please ensure that the supplied initial state corresponds to the latest finalized block as of the start of epoch 11348 (slot 363136). ``` #### Lodestar ``` info: Fetching weak subjectivity state weakSubjectivityServerUrl=https://goerli.checkpoint-sync.ethpandaops.io info: Download completed ``` #### Nimbus ``` Starting trusted node sync databaseDir=/data/consensus/db restUrl=https://goerli.checkpoint-sync.ethpandaops.io blockId=finalized backfill=false reindex=false Downloading checkpoint block restUrl=https://goerli.checkpoint-sync.ethpandaops.io blockId=finalized Downloading checkpoint state restUrl=https://goerli.checkpoint-sync.ethpandaops.io checkpointSlot=370528 Writing checkpoint state Writing checkpoint block Database initialized, historical blocks will be backfilled when starting the node ``` ### Step 4 Validate that your node is on the expected chain. To do this we'll check the state root of the finalized checkpoint against another source. For this guide we'll use `prater.beaconcha.in` (the beaconcha.in instance for Goerli) but any source that you trust is fine. You will need to know the IP & Port of your beacon node. Default ports: > Lighthouse: 5052 Nimbus: 5052 Teku: 5051 Prysm: 3500 Lodestar: 9596 #### 1. Obtaining finalized checkpoint & state root ##### Option A 1. Open `http://YOUR_NODE_IP:YOUR_NODE_PORT/eth/v1/beacon/headers/finalized` in your browser. 2. Find the `slot` number. 3. Find the `state_root` value. ##### Option B 1. Install `curl` and `jq`. 2. In a new terminal window run: ``` curl -s http://YOUR_NODE_IP:YOUR_NODE_PORT/eth/v1/beacon/headers/finalized | jq .'data.header.message' ``` 3. Find the `slot` and `state_root` values. #### 2. Validate against a known source - In a new tab/window, open https://prater.beaconcha.in/block/SLOT, replacing `SLOT` with the number from step 1. - Check that the `State Root` for the slot matches the value you found in step 1. If it's a match, congratulations :tada:. If it's not a match you should start from scratch by wiping your beacon node and starting from the top.
Last changed by  
 
launchpad
18676

Read more

Withdrawals

In this document I will include all the methods to make full withdrawals with the different clients and also show some examples about how to do a BLS to Execution change with ethdo tool. General assumptions Instead of using a long public key in all the queries, I just refer to it as $validator. export validator="0xb37101f32ee0d54ca6958764d21bd416b397c0a199d5ff447b8cd41bba89d78da9d12622134cc8a3cafe30daad85cd46" We assume for full withdrawal the withdrawal credential of type 0x01. If you have an address that is 0x00, then proceed to the bottom of the doc where it discusses how to convert a BLS (0x00) address into an execution address (0x01) All of our beacon nodes use port 4000 for API communication.

2/5/2024
How to run a node on the Holesky testnet?

Who is this guide for? This guide is meant to be a starting point and provides a mid-level summary of the required steps. It is not intended to be a beginner's guide, so copying and running commands from here may not work without some tweaking. The testnet is meant to mimic a chain that is post-merge. Therefore, the genesis state will be in a merged state. The chain will have to go through a the shapella fork at epoch 256. The JSON-RPC endpoint, faucet, and other tooling URLs can be found on https://holesky.ethpandaops.io/ Which version/branch do I use? Consensus layer

9/28/2023
ETH Withdrawals FAQ

Who is this guide for? If you run Ethereum validators, you can start testing withdrawals and preparing for withdrawals to go live on mainnet. Look out for Goerli and Sepolia, as these will fork before the mainnet. Before that, there will be devnets and mainnet shadowforks. DO NOT ATTEMPT TO CHANGE YOUR BLS KEYS ON MAINNET until the client software is ready to accept your BLS key changes. Each client team will announce once they are ready. We will provide a testnet environment where the BLS change can be tested out without any risk! [toc]

7/26/2023
How to run a node on the Zhejiang testnet?

Who is this guide for? This guide is meant to be a starting point and provides a mid-level summary of the required steps. It is not intended to be a beginner's guide, so copying and running commands from here may not work without some tweaking. The testnet is meant to mimic a chain that is post-merge. Therefore, the genesis state will be in a merged state. The chain will have to go through a fork on both EL and CL at the same time. This fork is called Shanghai on the EL side and Capella on the CL side. These two events will be triggered simultaneously. This is achieved by EL forking at a specific time rather than at a block number, and CL forking at a specific epoch. What is in the Zhejiang testnet? The Zhejiang testnet aims to test the following features:

2/6/2023
Read more from launchpad
Published on HackMD