GLCstakedSUI Network - complete guide to run a Node & Validator
SUI is a layer 1 blockchain designed by Mysten Labs from the ground up in smart contract specific language called MOVE This guide will go over installing a Full Node and Validator from scratch in order to run a Sui network node, assumes a fresh install of Ubuntu 20.04LTS. Hardware Requirements: Node Requirements: Full node requirements are lower, but storage can be expected to increase over time CPUs: 2 RAM: 8GB Storage: 50GB Validator Requirements: Validators perform work and deal with chain...
GLCstakedEasy Guide to Gnosischain Validator - with Lighthouse
This guide is help you set up a Gnosischain Validator, this will cover the full set up on a local device installed with Ubuntu 20.04 LTS. We will be using Lighthouse for consensus layer client and Nethermind for our Execution layer client. Gnosischain merge is on the horizon, this guide is intended to be merge ready the set up will cover steps and configuration needed to run post merge, and today. Gnosischain is using Ethereum Proof of Stake consensus with the Beacon chain to select validator...
GLCstakedAztec Sequencer- Public Testnet
This is a full guide to setup an Aztec Sequencer on Public Testnet, using Docker Compose and your own Sepolia Ethereum node (same device)Aztec Network- A privacy first Layer 2 on EthereumAztec is a zk-rollup allowing developers to build decentralised applications that preserve user privacy without compromising security or decentralisation. Aztec team co-developed Plonk, a highly efficient and universal zk-SNARK proving system that has since become foundational across the ZK ecosystem. Plonk’s...
$ETH Solo Staker #stakefromhome
Share Dialog
GLCstakedSUI Network - complete guide to run a Node & Validator
SUI is a layer 1 blockchain designed by Mysten Labs from the ground up in smart contract specific language called MOVE This guide will go over installing a Full Node and Validator from scratch in order to run a Sui network node, assumes a fresh install of Ubuntu 20.04LTS. Hardware Requirements: Node Requirements: Full node requirements are lower, but storage can be expected to increase over time CPUs: 2 RAM: 8GB Storage: 50GB Validator Requirements: Validators perform work and deal with chain...
GLCstakedEasy Guide to Gnosischain Validator - with Lighthouse
This guide is help you set up a Gnosischain Validator, this will cover the full set up on a local device installed with Ubuntu 20.04 LTS. We will be using Lighthouse for consensus layer client and Nethermind for our Execution layer client. Gnosischain merge is on the horizon, this guide is intended to be merge ready the set up will cover steps and configuration needed to run post merge, and today. Gnosischain is using Ethereum Proof of Stake consensus with the Beacon chain to select validator...
GLCstakedAztec Sequencer- Public Testnet
This is a full guide to setup an Aztec Sequencer on Public Testnet, using Docker Compose and your own Sepolia Ethereum node (same device)Aztec Network- A privacy first Layer 2 on EthereumAztec is a zk-rollup allowing developers to build decentralised applications that preserve user privacy without compromising security or decentralisation. Aztec team co-developed Plonk, a highly efficient and universal zk-SNARK proving system that has since become foundational across the ZK ecosystem. Plonk’s...
Share Dialog
$ETH Solo Staker #stakefromhome
Subscribe to GLCstaked
Subscribe to GLCstaked
How to run a Ethereum validator connected to RocketPool node: for Native Restaking with Eigen layer
NOTE: Rocketpool does not support repointing validators to eigenpods, you cannot run a ‘minipool’ with eigen layer native restaking. This feature is currently still in development.
RocketPool node operators can use their EL and CL clients under `rocketpool node` and connect a separate validator client, which can point to an eigenpod for native restaking. This is a ‘reverse hybrid setup’, with a new validator key/s and new validator client on its own connecting to the RocketPool full node endpoints.
This Guide covers how to set up a new separate validator client using RocketPool endpoints as a full node connection, and creation of a new validator key setup for a custom Eigenpod for Native Restaking.
Existing Rocketpool Node operators: interested in Native restaking , can save on resources, and only need to add another validator client without another full node: Storage approx: 1.2TB (pruned) growing + bandwidth required to keep a node in sync.
Not using Rocketpool, you can setup a full node easily with Nethermind Sedge and ignore Step 3
Native Restaking: enables the reuse of ETH on the consensus layer to extend ETHs cryptoeconomic security to other applications, native restakers can opt in using their validator
Repointing validators: to eigenpod for native restaking, is essentially setting the withdrawal address of the validator to a custom eigenpod contract, under control of the controller address. withdrawal credentials can either be repointed or set up upon creation of new validator key/s
Controller Address: address creating the EigenPod in Step 2 is responsible for all subsequent restaking and withdrawal operations from that EigenPod.
Pod Address: address of EigenPod contract created by controller, use this for the eth1-withdrawal-address
Create Eigen Pod Open the EigenLayer App and connect your Web3 wallet, making sure you are connected to Ethereum mainnet.
Connect your Controller account (any Ethereum wallet you control)> Create EigenPod > confirm Transaction > get contract address
Once confirmed, get the Pod Address from here
Staking Deposit CLI: https://github.com/ethereum/staking-deposit-cli/releases/
Generating a new validator key and deposit data to be imported to validator client later. NOTE: it is advised to do this offline, I downloaded the binary to a offline device to generate keys. Confirm that the binary URL is genuine.
Download for Linux:
mkdir deposit-cli && cd deposit-cli && wget https://github.com/ethereum/staking-deposit-cli/releases/download/v2.5.0/staking_deposit-cli-d7b5304-linux-amd64.tar.gz
extract the file.
tar -xvf staking_deposit-cli-d7b5304-linux-amd64.tar.gz
Make executable.
cd staking_deposit-cli-d7b5304-linux-amd64
chmod +x deposit
Create New Key:
This creates x1 new validator key, with a new Mnemonic phrase and with withdrawal address set to the eigenpod contract created in Step 1.
./deposit new-mnemonic --num_validators 1 --chain mainnet --eth1_withdrawal_address <your Eigen Pod contract here>
Decrypt Key
Running through the steps, you will be prompted to create a ‘Decrypt key’ this is a password for the validator key/s
SAVE THIS PASSWORD: it is required later
SAVE MNEMONIC /SEED
The deposit CLI will generate a seed to derive keys from, you MUST WRITE THIS DOWN, as this is required to restore or withdraw validators. You will be asked to confirm the seed in the next window.
Key Generation
Validator keys will then be generated and placed in the folder ./validator_keys
If you created x1 Keystore, you will have two files one for deposit_data and the other is the validator key to be imported to the validator client.
Backup the files that look like deposit_data.. .json and keystore-m-13281-3600........ .json
A full node can be setup with Nethermind Sedge
A one-click setup tool for PoS network/chain validators and nodes. - NethermindEth/sedge
# run setup
sedge cli
Select network: Mainnet > Select Node Type: Full Node > Generation path: Default > Set up validator: No > Expose all ports: Yes
Ensure that Port for Consensus http endpoint is 5052, or change accordingly on the validator docker-compose.yml file
We need to open http rpc on rocketpool node to connect a separate validator client to the consensus client running within the rocketpool stack. A Validator client needs to communicate with a Beacon node endpoint to communicate with the beacon chain/consensus layer of Ethereum.
Expose Consensus endpoint:
Open config with rocketpool service config
go to the Consensus Client (ETH2) category and check the Expose API Port box
Port Settings: Ufw settings, if running this on the same device, ideally you wish to keep the port closed to external access.
sudo ufw status
Confirm that 5052 is not allowed, or create a rule to deny
sudo ufw deny 5052
Rocketpool is hosted on another device:
If you are connecting to the Rocketpool node on another device, then the port will need to be allowed:
sudo ufw allow 5052
You may have to Port forward this port in your router settings, to avoid exposing the node externally to anyone with access to the device IP. You can specify allow only to a specific device local IP on your network.
sudo ufw allow 5052 from <ip of destination device>
NOTE: You do not need to expose the Execution endpoint, as the beacon node connects to this and is setup already within rocketpool.
To connect to this beacon node (consensus client): if your node's local IP address were 192.168.1.45, then use in the validator configuration later
- --beacon-nodes=http://192.168.1.45:5052
Make working directory for eigenpod validator and keystore/s
mkdir -p eigenpod/keystore
mkdir -p eigenpod/validator-data
Create File for Decrypt Key
nano /home/$USER/eigenpod/keystore/password.txt
Enter the password used earlier in Step 2, This is our decrypt key that we created earlier, the password for our keystores. Enter the password the same as before without spaces, ctrl + o to write to file then ctrl + x to save and close.
Move Validator Keys
Place the validator_keys folder which contains both deposit_data.json and keystore.json validator key, move to ./eigenpod/keystore/
sudo cp /path/to/validator_keys $HOME/eigenpod/keystore/
You will need to specify the exact keystore name and extension, which will look something like keystore-m_12381_3600_0_0_0-1694155614.json
cd eigenpod
sudo docker run --volume $PWD/keystore:/var/lib/keystores --volume $PWD/validator-data:/data sigp/lighthouse lighthouse account validator import --datadir /data --keystore /var/lib/keystores/validator_keys/<keystore-file> --reuse-password --password-file /var/lib/keystores/password.txt --network mainnet
This will import the keystore, into the correct directories and format for lighthouse validator client it will look like this if successful:
If you get errors, double check the password.txt You should now have a folder eigenpod/validator-data/validators with the imported keystores.
This guide is using Lighthouse for the validator client, other clients can be used, but the import and template for validator config will be different.
Check for latest releases here:
nano docker-compose.yml
version: "3.9"
services:
validator:
container_name: validator-eigen-client
image: sigp/lighthouse:v4.3.0
network_mode: "host"
volumes:
- ./validator-data:/data
- ./keystore:/keystore
command:
- lighthouse
- vc
- --network=mainnet
- --beacon-nodes=http://localhost:5052
- --graffiti=
- --debug-level=info
- --validators-dir=/data/validators
- --secrets-dir=/keystore
- --suggested-fee-recipient=<controller-address>
logging:
driver: json-file
options:
max-size: 10m
max-file: "10"
This is setup to connect to the rocketpool beacon node through docker network
Set fee recipient address for execution rewards, this can be any Ethereum address you own, such as the controller address used to create and control the eigenpod.
Start the Validator Client
docker compose up -d
docker compose logs -f validator
with successfully imported validators and working connection to a beacon node endpoint, you should see something like this.
With active validator client and imported keystores, now need to make the deposit using the deposit_data......json created in Step 2.
Head to the Deposit launchpad
Confirm both URL and Contract address from the docs:
Contract Address: 0x00000000219ab540356cBB839Cbe05303d7705Fa
You will go through several checklists before getting to the deposit which will prompt a transaction to confirm from your wallet.
At this stage, the validator should be operational and waiting for inclusion for the deposit, to be an active validator
Updating client
stop the validator
cd eigenpod
docker compose down
edit the version tag with latest release:
nano docker-compose.yml
# Restart Validator
docker compose up -d
Additional Options for Lighthouse validator
sudo docker run -it sigp/lighthouse lighthouse vc --help
How to run a Ethereum validator connected to RocketPool node: for Native Restaking with Eigen layer
NOTE: Rocketpool does not support repointing validators to eigenpods, you cannot run a ‘minipool’ with eigen layer native restaking. This feature is currently still in development.
RocketPool node operators can use their EL and CL clients under `rocketpool node` and connect a separate validator client, which can point to an eigenpod for native restaking. This is a ‘reverse hybrid setup’, with a new validator key/s and new validator client on its own connecting to the RocketPool full node endpoints.
This Guide covers how to set up a new separate validator client using RocketPool endpoints as a full node connection, and creation of a new validator key setup for a custom Eigenpod for Native Restaking.
Existing Rocketpool Node operators: interested in Native restaking , can save on resources, and only need to add another validator client without another full node: Storage approx: 1.2TB (pruned) growing + bandwidth required to keep a node in sync.
Not using Rocketpool, you can setup a full node easily with Nethermind Sedge and ignore Step 3
Native Restaking: enables the reuse of ETH on the consensus layer to extend ETHs cryptoeconomic security to other applications, native restakers can opt in using their validator
Repointing validators: to eigenpod for native restaking, is essentially setting the withdrawal address of the validator to a custom eigenpod contract, under control of the controller address. withdrawal credentials can either be repointed or set up upon creation of new validator key/s
Controller Address: address creating the EigenPod in Step 2 is responsible for all subsequent restaking and withdrawal operations from that EigenPod.
Pod Address: address of EigenPod contract created by controller, use this for the eth1-withdrawal-address
Create Eigen Pod Open the EigenLayer App and connect your Web3 wallet, making sure you are connected to Ethereum mainnet.
Connect your Controller account (any Ethereum wallet you control)> Create EigenPod > confirm Transaction > get contract address
Once confirmed, get the Pod Address from here
Staking Deposit CLI: https://github.com/ethereum/staking-deposit-cli/releases/
Generating a new validator key and deposit data to be imported to validator client later. NOTE: it is advised to do this offline, I downloaded the binary to a offline device to generate keys. Confirm that the binary URL is genuine.
Download for Linux:
mkdir deposit-cli && cd deposit-cli && wget https://github.com/ethereum/staking-deposit-cli/releases/download/v2.5.0/staking_deposit-cli-d7b5304-linux-amd64.tar.gz
extract the file.
tar -xvf staking_deposit-cli-d7b5304-linux-amd64.tar.gz
Make executable.
cd staking_deposit-cli-d7b5304-linux-amd64
chmod +x deposit
Create New Key:
This creates x1 new validator key, with a new Mnemonic phrase and with withdrawal address set to the eigenpod contract created in Step 1.
./deposit new-mnemonic --num_validators 1 --chain mainnet --eth1_withdrawal_address <your Eigen Pod contract here>
Decrypt Key
Running through the steps, you will be prompted to create a ‘Decrypt key’ this is a password for the validator key/s
SAVE THIS PASSWORD: it is required later
SAVE MNEMONIC /SEED
The deposit CLI will generate a seed to derive keys from, you MUST WRITE THIS DOWN, as this is required to restore or withdraw validators. You will be asked to confirm the seed in the next window.
Key Generation
Validator keys will then be generated and placed in the folder ./validator_keys
If you created x1 Keystore, you will have two files one for deposit_data and the other is the validator key to be imported to the validator client.
Backup the files that look like deposit_data.. .json and keystore-m-13281-3600........ .json
A full node can be setup with Nethermind Sedge
A one-click setup tool for PoS network/chain validators and nodes. - NethermindEth/sedge
# run setup
sedge cli
Select network: Mainnet > Select Node Type: Full Node > Generation path: Default > Set up validator: No > Expose all ports: Yes
Ensure that Port for Consensus http endpoint is 5052, or change accordingly on the validator docker-compose.yml file
We need to open http rpc on rocketpool node to connect a separate validator client to the consensus client running within the rocketpool stack. A Validator client needs to communicate with a Beacon node endpoint to communicate with the beacon chain/consensus layer of Ethereum.
Expose Consensus endpoint:
Open config with rocketpool service config
go to the Consensus Client (ETH2) category and check the Expose API Port box
Port Settings: Ufw settings, if running this on the same device, ideally you wish to keep the port closed to external access.
sudo ufw status
Confirm that 5052 is not allowed, or create a rule to deny
sudo ufw deny 5052
Rocketpool is hosted on another device:
If you are connecting to the Rocketpool node on another device, then the port will need to be allowed:
sudo ufw allow 5052
You may have to Port forward this port in your router settings, to avoid exposing the node externally to anyone with access to the device IP. You can specify allow only to a specific device local IP on your network.
sudo ufw allow 5052 from <ip of destination device>
NOTE: You do not need to expose the Execution endpoint, as the beacon node connects to this and is setup already within rocketpool.
To connect to this beacon node (consensus client): if your node's local IP address were 192.168.1.45, then use in the validator configuration later
- --beacon-nodes=http://192.168.1.45:5052
Make working directory for eigenpod validator and keystore/s
mkdir -p eigenpod/keystore
mkdir -p eigenpod/validator-data
Create File for Decrypt Key
nano /home/$USER/eigenpod/keystore/password.txt
Enter the password used earlier in Step 2, This is our decrypt key that we created earlier, the password for our keystores. Enter the password the same as before without spaces, ctrl + o to write to file then ctrl + x to save and close.
Move Validator Keys
Place the validator_keys folder which contains both deposit_data.json and keystore.json validator key, move to ./eigenpod/keystore/
sudo cp /path/to/validator_keys $HOME/eigenpod/keystore/
You will need to specify the exact keystore name and extension, which will look something like keystore-m_12381_3600_0_0_0-1694155614.json
cd eigenpod
sudo docker run --volume $PWD/keystore:/var/lib/keystores --volume $PWD/validator-data:/data sigp/lighthouse lighthouse account validator import --datadir /data --keystore /var/lib/keystores/validator_keys/<keystore-file> --reuse-password --password-file /var/lib/keystores/password.txt --network mainnet
This will import the keystore, into the correct directories and format for lighthouse validator client it will look like this if successful:
If you get errors, double check the password.txt You should now have a folder eigenpod/validator-data/validators with the imported keystores.
This guide is using Lighthouse for the validator client, other clients can be used, but the import and template for validator config will be different.
Check for latest releases here:
nano docker-compose.yml
version: "3.9"
services:
validator:
container_name: validator-eigen-client
image: sigp/lighthouse:v4.3.0
network_mode: "host"
volumes:
- ./validator-data:/data
- ./keystore:/keystore
command:
- lighthouse
- vc
- --network=mainnet
- --beacon-nodes=http://localhost:5052
- --graffiti=
- --debug-level=info
- --validators-dir=/data/validators
- --secrets-dir=/keystore
- --suggested-fee-recipient=<controller-address>
logging:
driver: json-file
options:
max-size: 10m
max-file: "10"
This is setup to connect to the rocketpool beacon node through docker network
Set fee recipient address for execution rewards, this can be any Ethereum address you own, such as the controller address used to create and control the eigenpod.
Start the Validator Client
docker compose up -d
docker compose logs -f validator
with successfully imported validators and working connection to a beacon node endpoint, you should see something like this.
With active validator client and imported keystores, now need to make the deposit using the deposit_data......json created in Step 2.
Head to the Deposit launchpad
Confirm both URL and Contract address from the docs:
Contract Address: 0x00000000219ab540356cBB839Cbe05303d7705Fa
You will go through several checklists before getting to the deposit which will prompt a transaction to confirm from your wallet.
At this stage, the validator should be operational and waiting for inclusion for the deposit, to be an active validator
Updating client
stop the validator
cd eigenpod
docker compose down
edit the version tag with latest release:
nano docker-compose.yml
# Restart Validator
docker compose up -d
Additional Options for Lighthouse validator
sudo docker run -it sigp/lighthouse lighthouse vc --help
<100 subscribers
<100 subscribers
No activity yet