$ETH Solo Staker #stakefromhome
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...
GLCstakedCosmos Full Node
Deploy a full node for cosmos chain Cosmos hub is the economic centre of the Interchain cosmos ecosystem. Full node is a node that does not build blocks (non-validating) but stores the chain state and allows direct access to the network. NOTE: full node refers to a non-archival implementation of the node.Cosmos: The Internet of BlockchainsCosmos is an ever-expanding ecosystem of interoperable and sovereign blockchain apps and services, built for a decentralized future.https://cosmos.networkHa...
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...
GLCstakedCosmos Full Node
Deploy a full node for cosmos chain Cosmos hub is the economic centre of the Interchain cosmos ecosystem. Full node is a node that does not build blocks (non-validating) but stores the chain state and allows direct access to the network. NOTE: full node refers to a non-archival implementation of the node.Cosmos: The Internet of BlockchainsCosmos is an ever-expanding ecosystem of interoperable and sovereign blockchain apps and services, built for a decentralized future.https://cosmos.networkHa...
$ETH Solo Staker #stakefromhome
Subscribe to GLCstaked
Subscribe to GLCstaked
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Set up guide for a Bridge Node on Celestia Mocha Testnet
Bridge nodes connect the data availability layer and the consensus layer while also having the option of becoming a validator. Validators do not have to run bridge nodes, but are encouraged to in order to relay blocks to the data availability network.
Bridge Node Functions
Import and process “raw” headers & blocks from a trusted Core process (meaning a trusted RPC connection to a celestia-core node) in the Consensus network.
Validate and erasure code the “raw” blocks
Supply block shares with data availability headers to Light Nodes in the DA network.
Hardware Requirements:
4vCPU / 8GB RAM / 250GB SSD / 1 Gbps Download/100 Mbps Upload OS: Ubuntu Linux 20.04 (LTS) x64
See Official guides for Celestia on setting up a Bridge node here, This document is designed for an easy step by step setup
Dependencies
This will require the same prerequisite software dependencies installed in Step 1 of the Validator Node guide, this guide is intended for running a Bridge node in parallel to a Validator/full node, so should already be installed. However this could be run separate.
Change to root
sudo -i
Install celestia-node
cd $HOME
rm -rf celestia-node
git clone https://github.com/celestiaorg/celestia-node.git
cd celestia-node/
git checkout tags/v0.6.1
make install
make cel-key
You should be in celestia-node directory, verify installed correctly
NOTE: celestia app is what was installed for validator node
celestia bridge init --core.ip <ip-address>:<port>
--core.ip port defaults to 9090, RPC Endpoints can be found here:
Example
celestia bridge init --core.ip https://rpc-mocha.pops.one:9090
We now have a working directory .celestia-bridge and our config should be found at ./config.toml
Start the Bridge Node with a connection to a validator node's gRPC endpoint (which is usually exposed on port 9090), find addresses above.
celestia bridge start --core.ip <ip-address>
Connect to your own validator
to connect to your own validator use the above command like so
celestia bridge start --core.ip http://localhost:9090
Connect to a core team public endpoint
otherwise using one of the public endpoints like so
celestia bridge start --core.ip https://rpc-mocha.pops.one:26657
Stop the node with ctrl + c, as it will be set up as a system service to run continuously in the background.
Once you start the Bridge Node, a wallet key will be generated for you. You will need to fund that address with Testnet tokens to pay for PayForData transactions.
Find address to fund
./cel-key list --node.type bridge --keyring-backend test
Use Existing Key
The custom key must exist inside the Celestia bridge node directory at the correct path default: ~/.celestia-bridge/keys/keyring-test.
Recover Key, with existing seed
./cel-key add <name_of_custom_key> --keyring-backend test --node.type bridge --recover
add flag to the start command from step 3. or to the system service file later at step 5.
--keyring.accname <name_of_custom_key>
Fund the bridge node wallet
Fund the address for the bridge from another wallet, such as sending from validator node/full consensus node. in the working directory
celestia-appd tx bank send [from_key_or_address] [to_address] [amount] --chain-id mamaki --fees [fee] -y
This is a working example, using your own validator gRPC endpoint on the same server, and bridge wallet named ‘bridgewallet’
--core.ip <ip-address>
--keyring.accname bridgewallet <name_of_custom_key>
tee <<EOF >/dev/null /etc/systemd/system/celestia-bridge.service
[Unit]
Description=celestia-bridge Cosmos daemon
After=network-online.target
[Service]
User=root
ExecStart=/usr/local/bin/celestia bridge start --core.ip http://localhost:9090 --keyring.accname bridgewallet
Restart=on-failure
RestartSec=3
LimitNOFILE=4096
[Install]
WantedBy=multi-user.target
EOF
Enable and Start Service
systemctl enable celestia-bridge
systemctl daemon-reload
systemctl start celestia-bridge
Check Status
systemctl status celestia-bridge
Check logs
journalctl -u celestia-bridge.service -f
such as changing the gRPC endpoint you will need to edit the service file
stop the service
systemctl stop celestia-bridge
Open service for editing
nano /etc/systemd/system/celestia-bridge.service
Restart the service
systemctl daemon-reload
systemctl start celestia-bridge
Set up guide for a Bridge Node on Celestia Mocha Testnet
Bridge nodes connect the data availability layer and the consensus layer while also having the option of becoming a validator. Validators do not have to run bridge nodes, but are encouraged to in order to relay blocks to the data availability network.
Bridge Node Functions
Import and process “raw” headers & blocks from a trusted Core process (meaning a trusted RPC connection to a celestia-core node) in the Consensus network.
Validate and erasure code the “raw” blocks
Supply block shares with data availability headers to Light Nodes in the DA network.
Hardware Requirements:
4vCPU / 8GB RAM / 250GB SSD / 1 Gbps Download/100 Mbps Upload OS: Ubuntu Linux 20.04 (LTS) x64
See Official guides for Celestia on setting up a Bridge node here, This document is designed for an easy step by step setup
Dependencies
This will require the same prerequisite software dependencies installed in Step 1 of the Validator Node guide, this guide is intended for running a Bridge node in parallel to a Validator/full node, so should already be installed. However this could be run separate.
Change to root
sudo -i
Install celestia-node
cd $HOME
rm -rf celestia-node
git clone https://github.com/celestiaorg/celestia-node.git
cd celestia-node/
git checkout tags/v0.6.1
make install
make cel-key
You should be in celestia-node directory, verify installed correctly
NOTE: celestia app is what was installed for validator node
celestia bridge init --core.ip <ip-address>:<port>
--core.ip port defaults to 9090, RPC Endpoints can be found here:
Example
celestia bridge init --core.ip https://rpc-mocha.pops.one:9090
We now have a working directory .celestia-bridge and our config should be found at ./config.toml
Start the Bridge Node with a connection to a validator node's gRPC endpoint (which is usually exposed on port 9090), find addresses above.
celestia bridge start --core.ip <ip-address>
Connect to your own validator
to connect to your own validator use the above command like so
celestia bridge start --core.ip http://localhost:9090
Connect to a core team public endpoint
otherwise using one of the public endpoints like so
celestia bridge start --core.ip https://rpc-mocha.pops.one:26657
Stop the node with ctrl + c, as it will be set up as a system service to run continuously in the background.
Once you start the Bridge Node, a wallet key will be generated for you. You will need to fund that address with Testnet tokens to pay for PayForData transactions.
Find address to fund
./cel-key list --node.type bridge --keyring-backend test
Use Existing Key
The custom key must exist inside the Celestia bridge node directory at the correct path default: ~/.celestia-bridge/keys/keyring-test.
Recover Key, with existing seed
./cel-key add <name_of_custom_key> --keyring-backend test --node.type bridge --recover
add flag to the start command from step 3. or to the system service file later at step 5.
--keyring.accname <name_of_custom_key>
Fund the bridge node wallet
Fund the address for the bridge from another wallet, such as sending from validator node/full consensus node. in the working directory
celestia-appd tx bank send [from_key_or_address] [to_address] [amount] --chain-id mamaki --fees [fee] -y
This is a working example, using your own validator gRPC endpoint on the same server, and bridge wallet named ‘bridgewallet’
--core.ip <ip-address>
--keyring.accname bridgewallet <name_of_custom_key>
tee <<EOF >/dev/null /etc/systemd/system/celestia-bridge.service
[Unit]
Description=celestia-bridge Cosmos daemon
After=network-online.target
[Service]
User=root
ExecStart=/usr/local/bin/celestia bridge start --core.ip http://localhost:9090 --keyring.accname bridgewallet
Restart=on-failure
RestartSec=3
LimitNOFILE=4096
[Install]
WantedBy=multi-user.target
EOF
Enable and Start Service
systemctl enable celestia-bridge
systemctl daemon-reload
systemctl start celestia-bridge
Check Status
systemctl status celestia-bridge
Check logs
journalctl -u celestia-bridge.service -f
such as changing the gRPC endpoint you will need to edit the service file
stop the service
systemctl stop celestia-bridge
Open service for editing
nano /etc/systemd/system/celestia-bridge.service
Restart the service
systemctl daemon-reload
systemctl start celestia-bridge
No activity yet