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
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
Subscribe to GLCstaked
Subscribe to GLCstaked
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
DRAFT: Deploy a Lava Provider node and connect to RPC nodes. NOTE: this is for current lava-testnet-2.
Document Last Update: 05/09/23
Lava Protocol: a crypto-market which powers a decentralized RPC layer for Web3.
2.5m+ users, 30+ chains supported, 70b+ RPC calls - you are using Lava without knowing. Lava is the infrastructure that powers access to all blockchains, enabling essential onchain actions such as minting, swapping and transacting.
Lava Chain: is a cosmos PoS layer 1 with $LAVA for settlement, validator nodes secure the chain.
Providers: Provider nodes, are nodes running atop Lavanet connecting to Lava chain for rewards (do not participate in consensus), these nodes provide RPC endpoints of other chains to any consumer.
Consumers: consumers of chain data, paying for access to RPC endpoints to providers.
Hardware requirements:
For Full node (current Testnet): 8GB RAM /100GB SSD Storage/ CPU 4v x64 2.0 GHz. These are minimum specs, and I would recommend more.
This guide will be setup to host the lightweight provider process alongside the node (to provide rpc access to), this means installing lavad binary for running the lightweight provider process, access to a Lava full node must also be provided and should be hosted separately.
Lava docs:
https://docs.lavanet.xyz/provider-setup/
“create one rpcprovider.yml provider config per chain you plan to support on that device. Each one of these .yml files will function as the configuration for a distinct provider process.”
TLS Certificates/Sub-domains: “All providers on lava-testnet-2 must use a domain name and TLS.” Setting up TLS and sub-domains is done later in this guide.
Ports: the only port that needs to be open externally is Nginx https port, by default this is 443, but if you have need to change this then adjust accordingly.
443 # https port for nginx
Lava Full Node:
Lava provider requires connection to a full node to make transactions on the Lava Network. You will need to have access to one, this can be hosted on an external device.
Full Node for Provider:
A Node to provide API Access through lavas lightweight provider process, this will be installed on the same device as the provider and should be setup first.
Library of full node setup guides and scripts: These are my own, deployment guides to get a ‘full node’ setup to a working state:
deployment scripts for full nodes for RPC endpoint provision - GLCNI/RPC-node-deployments
Update and install dependencies
sudo apt update && sudo apt upgrade -y
sudo apt install git curl wget tar unzip jq build-essential pkg-config clang bsdmainutils make ncdu -y
Install Go
Use version 1.20.5 for current binary
wget -q -O - https://git.io/vQhTU | bash -s -- --version 1.20.5
Run source $HOME/.bashrc to take effect
Confirm install is successful
go version
This script is made by osmosis-labs and installs PATH variables to .bashrc and sets up in a way compatible with the rest of the build. Go binary installs to $HOME/.go and $HOME/go/bin
#to remove installation
wget -q -O - https://git.io/vQhTU | bash -s -- --remove
create working directory, this will be for provider configurations later.
mkdir lava-provider
Check for latest version here: replace version accordingly, always use the version tagged latest
cd $HOME
git clone https://github.com/lavanet/lava.git
cd lava
git checkout v0.21.1.2
make install
Confirm Installed
which lavad
lavad --help
When running the binary 1st time it creates the working folder .lava with the following files: app.toml, client.toml, config.toml
The lava provider process needs to connect to a Lava node to interact with the lava network.
Add Lava Node
Add lava rpc endpoint to client.toml in .lava/configs
lavad config node http://<local-node-IP>:26657/rpc/
Test connection to full node:
curl http://<device-IP>:26657/status | jq .result.sync_info.catching_up
This just ensures an external node is reachable by direct query, ensure ports are open on lava node: 26657, 1317, 26656
Set Keyring backend and chain-id
lavad config chain-id lava-testnet-2
lavad config keyring-backend test
“provider-wallet” can be anything. Add --recover flag to import an existing seed.
PROVIDER_ACCOUNT="provider-wallet"
lavad keys add $PROVIDER_ACCOUNT --keyring-backend test
MAKE SURE TO SAVE THE SEED PHRASE
Other commands
# view keys
lavad keys list
# delete keys
lavad keys delete
# view address
lavad keys show $PROVIDER_ACCOUNT --address
Test connection via CLI: it should be set in config client.toml to connect to your own lava node, if it returns the balance of your wallet then lava client is configured correctly.
lavad query bank balances <lava address here>
Ensure your Relay Chain nodes are operational and meet the required specifications. Lava connects blockchain nodes from various networks to consumers, providers can run one or more nodes enabled by lava.
Nodes can be deployed as a ‘full node’ which normally means synced to the network and stores the chain data, non-validating and RPC and/or gRPC/REST API open.
Test Connection to full node:
Check operational, synced, and configured correctly with required API interfaces/ports open. This node should be hosted on the same device so available over http://localhost:<port>
example for ‘Juno’:
curl http://127.0.0.1:26657/status | jq .result.sync_info.catching_up
Generate TLS certificate and Setup Sub-domains (Nginx)
Lava provider requires nodes be registered via a sub-domain/TLS certificates, a detailed guide on how to do this is covered here: sub-domains with NGINX
Getting API and chain specs
Get easy relevant information here: to do this from your node
lavad q spec list-spec
check providers on a specific chain
lavad query pairing providers "<NETWORK_NAME>"
Stake a provider to signal on-chain the $LAVA stake on the Lava network.
Check Balance:
lavad query bank balances <lava address here>
Stake Provider Command Format:
lavad tx pairing stake-provider [chain-id] [amount] [endpoint endpoint ...] [geolocation] [flags]
Parameters:
chain-id - The ID of the serviced chain (e.g., COS4 or EHT1) find in list-spec
ammount - Stake amount in ulava
geolocation - what geolocation the provider/nodes will be hosted, all locations here:.
Endpoint Format:
<sub-domain for node>:<nginx-port>,geolocation
Flags:
--from - The wallet to be used for the provider ($PROVIDER_ACCOUNT).
--provider-moniker - Provider’s public name
--keyring-backend - A keyring-backend of your choosing (e.g., test).
--chain-id - The chain_id of the network (e.g., lava-testnet-2).
--gas - The gas limit for the transaction (e.g., "auto").
--gas-adjustment - The gas adjustment factor (e.g., "1.5").
--node - can be omitted if set in client.toml
Example with Ethereum:
ETH_STAKE_AMMOUNT=<ammount to stake, eg. "50000000000ulava">
ETH_NODE_MONIKER=<whatever moniker for this node>
ETH_SUBDOMAIN=<Subdomain for this node eg. provider-host.com>
ETH_NGINX_PORT=<port used for NGINX>
lavad tx pairing stake-provider "ETH1" $ETH_STAKE_AMMOUNT "$ETH_SUBDOMAIN:$ETH_NGINX_PORT,jsonrpc,2" 2 --from $PROVIDER_ACCOUNT --provider-moniker $ETH_NODE_MONIKER --keyring-backend "test" --chain-id "lava-testnet-2" --gas="auto" --gas-adjustment "1.5"
EVMs usually have only jsonrpc interface: (ws can usually be enabled)
Example with Cosmos:
COS_STAKE_AMMOUNT=<ammount to stake, eg. "50000000000ulava">
COS_NODE_MONIKER=<whatever moniker for this node>
COS_SUBDOMAIN=<Subdomain for this node eg. provider-host.com>
COS_NGINX_PORT=<port used for NGINX>
lavad tx pairing stake-provider "COS5T" $COS_STAKE_AMMOUNT "$COS_SUBDOMAIN:$COS_NGINX_PORT,2" 2 --from $PROVIDER_ACCOUNT --provider-moniker $COS_NODE_MONIKER --keyring-backend "test" --chain-id "lava-testnet-2" --gas="auto" --gas-adjustment "1.5"
Cosmos chains usually have rest, tendermintrpc & grpc interface, all mandatory:
Example with Avalanche:
AVAX_STAKE_AMMOUNT=<ammount to stake, eg. "50000000000ulava">
AVAX_NODE_MONIKER=<whatever moniker for this node>
AVAX_SUBDOMAIN=<Subdomain for this node eg. provider-host.com>
AVAX_NGINX_PORT=<port used for NGINX>
lavad tx pairing stake-provider "AVAX" $AVAX_STAKE_AMMOUNT "$AVAX_SUBDOMAIN:$AVAX_NGINX_PORT,2" 2 --from $PROVIDER_ACCOUNT --provider-moniker $AVAX_NODE_MONIKER --keyring-backend "test" --chain-id "lava-testnet-2" --gas="auto" --gas-adjustment "1.5"
Default http rpc port for avalanche is: 9650
Example with Juno:
JUNO_STAKE_AMMOUNT=<ammount to stake, eg. "50000000000ulava">
JUNO_NODE_MONIKER=<whatever moniker for this node>
JUNO_SUBDOMAIN=<Subdomain for this node eg. provider-host.com>
JUNO_NGINX_PORT=<port used for NGINX>
lavad tx pairing stake-provider "JUN1" $JUNO_STAKE_AMMOUNT "$JUNO_SUBDOMAIN:$JUNO_NGINX_PORT,2" 2 --from $PROVIDER_ACCOUNT --provider-moniker $JUNO_NODE_MONIKER --keyring-backend "test" --chain-id "lava-testnet-2" --gas="auto" --gas-adjustment "1.5"
Default Ports for Cosmos based nodes:-the gRPC server (default port: 9090)-the REST server (default port: 1317)-the CometBFT RPC endpoint (default port: 26657)
Verify Stake
# from wallet
lavad query pairing account-info --from $PROVIDER_ACCOUNT
# from address
lavad query pairing account-info <address>
Create a single configuration file to manage each endpoint/rpc node, each node will have its own dedicated provider process and configuration file.
All configuration files should be located in the default node home directory (e.g., app.DefaultNodeHome/config) or the local running directory.
mkdir lava-provider/config
nano lava-provider/config/rpcprovider.yml
node-urls: The endpoint URL/Sub-domain for nodes to provide on :< NGINX port> network-address: The URL for Lava full node, as it will be local use 127.0.0.1:2221, 2221 will be the default provider port to connect to Nginx service (from Step 4) More examples can be found here: Example for Juno: # Configuration for JUNO Chain
endpoints:
- api-interface: tendermintrpc
chain-id: JUN1
network-address:
address: 127.0.0.1:2221
disable-tls: true
node-urls:
- url: ws://127.0.0.1:26657/websocket
- url: http://127.0.0.1:26657
- api-interface: grpc
chain-id: JUN1
network-address:
address: 127.0.0.1:2221
disable-tls: true
node-urls:
url: 127.0.0.1:9090
- api-interface: rest
chain-id: JUN1
network-address:
address: 127.0.0.1:2221
disable-tls: true
node-urls:
url: http://127.0.0.1:1317
Example for Avax: # Configuration for AVAX Chain
endpoints:
- api-interface: jsonrpc
chain-id: AVAX
network-address:
address: 127.0.0.1:2221
disable-tls: true
node-urls:
- url: ws://127.0.0.1:3333/C/rpc/ws
internal-path: "/C/rpc" # c chain like specified in the spec
- url: https://127.0.0.1:3334/C/avax
internal-path: "/C/avax" # c/avax like specified in the spec
- url: https://127.0.0.1:3335/X
internal-path: "/X" # x chain like specified in the spec
- url: https://127.0.0.1:3336/P
internal-path: "/P" # p chain like specified in the spec
6. Set up Provider Service rpcprovider is a command line tool for setting up an RPC server that listens for requests from Lava protocol RPC consumers, forwards them to a configured node, and responds with the reply. The configuration can be provided via a YAML configuration file or as command line arguments. Command format lavad rpcprovider /path/to/config/rpcprovider.yml <flags>
rpcprovider accepts the following flags:
DRAFT: Deploy a Lava Provider node and connect to RPC nodes. NOTE: this is for current lava-testnet-2.
Document Last Update: 05/09/23
Lava Protocol: a crypto-market which powers a decentralized RPC layer for Web3.
2.5m+ users, 30+ chains supported, 70b+ RPC calls - you are using Lava without knowing. Lava is the infrastructure that powers access to all blockchains, enabling essential onchain actions such as minting, swapping and transacting.
Lava Chain: is a cosmos PoS layer 1 with $LAVA for settlement, validator nodes secure the chain.
Providers: Provider nodes, are nodes running atop Lavanet connecting to Lava chain for rewards (do not participate in consensus), these nodes provide RPC endpoints of other chains to any consumer.
Consumers: consumers of chain data, paying for access to RPC endpoints to providers.
Hardware requirements:
For Full node (current Testnet): 8GB RAM /100GB SSD Storage/ CPU 4v x64 2.0 GHz. These are minimum specs, and I would recommend more.
This guide will be setup to host the lightweight provider process alongside the node (to provide rpc access to), this means installing lavad binary for running the lightweight provider process, access to a Lava full node must also be provided and should be hosted separately.
Lava docs:
https://docs.lavanet.xyz/provider-setup/
“create one rpcprovider.yml provider config per chain you plan to support on that device. Each one of these .yml files will function as the configuration for a distinct provider process.”
TLS Certificates/Sub-domains: “All providers on lava-testnet-2 must use a domain name and TLS.” Setting up TLS and sub-domains is done later in this guide.
Ports: the only port that needs to be open externally is Nginx https port, by default this is 443, but if you have need to change this then adjust accordingly.
443 # https port for nginx
Lava Full Node:
Lava provider requires connection to a full node to make transactions on the Lava Network. You will need to have access to one, this can be hosted on an external device.
Full Node for Provider:
A Node to provide API Access through lavas lightweight provider process, this will be installed on the same device as the provider and should be setup first.
Library of full node setup guides and scripts: These are my own, deployment guides to get a ‘full node’ setup to a working state:
deployment scripts for full nodes for RPC endpoint provision - GLCNI/RPC-node-deployments
Update and install dependencies
sudo apt update && sudo apt upgrade -y
sudo apt install git curl wget tar unzip jq build-essential pkg-config clang bsdmainutils make ncdu -y
Install Go
Use version 1.20.5 for current binary
wget -q -O - https://git.io/vQhTU | bash -s -- --version 1.20.5
Run source $HOME/.bashrc to take effect
Confirm install is successful
go version
This script is made by osmosis-labs and installs PATH variables to .bashrc and sets up in a way compatible with the rest of the build. Go binary installs to $HOME/.go and $HOME/go/bin
#to remove installation
wget -q -O - https://git.io/vQhTU | bash -s -- --remove
create working directory, this will be for provider configurations later.
mkdir lava-provider
Check for latest version here: replace version accordingly, always use the version tagged latest
cd $HOME
git clone https://github.com/lavanet/lava.git
cd lava
git checkout v0.21.1.2
make install
Confirm Installed
which lavad
lavad --help
When running the binary 1st time it creates the working folder .lava with the following files: app.toml, client.toml, config.toml
The lava provider process needs to connect to a Lava node to interact with the lava network.
Add Lava Node
Add lava rpc endpoint to client.toml in .lava/configs
lavad config node http://<local-node-IP>:26657/rpc/
Test connection to full node:
curl http://<device-IP>:26657/status | jq .result.sync_info.catching_up
This just ensures an external node is reachable by direct query, ensure ports are open on lava node: 26657, 1317, 26656
Set Keyring backend and chain-id
lavad config chain-id lava-testnet-2
lavad config keyring-backend test
“provider-wallet” can be anything. Add --recover flag to import an existing seed.
PROVIDER_ACCOUNT="provider-wallet"
lavad keys add $PROVIDER_ACCOUNT --keyring-backend test
MAKE SURE TO SAVE THE SEED PHRASE
Other commands
# view keys
lavad keys list
# delete keys
lavad keys delete
# view address
lavad keys show $PROVIDER_ACCOUNT --address
Test connection via CLI: it should be set in config client.toml to connect to your own lava node, if it returns the balance of your wallet then lava client is configured correctly.
lavad query bank balances <lava address here>
Ensure your Relay Chain nodes are operational and meet the required specifications. Lava connects blockchain nodes from various networks to consumers, providers can run one or more nodes enabled by lava.
Nodes can be deployed as a ‘full node’ which normally means synced to the network and stores the chain data, non-validating and RPC and/or gRPC/REST API open.
Test Connection to full node:
Check operational, synced, and configured correctly with required API interfaces/ports open. This node should be hosted on the same device so available over http://localhost:<port>
example for ‘Juno’:
curl http://127.0.0.1:26657/status | jq .result.sync_info.catching_up
Generate TLS certificate and Setup Sub-domains (Nginx)
Lava provider requires nodes be registered via a sub-domain/TLS certificates, a detailed guide on how to do this is covered here: sub-domains with NGINX
Getting API and chain specs
Get easy relevant information here: to do this from your node
lavad q spec list-spec
check providers on a specific chain
lavad query pairing providers "<NETWORK_NAME>"
Stake a provider to signal on-chain the $LAVA stake on the Lava network.
Check Balance:
lavad query bank balances <lava address here>
Stake Provider Command Format:
lavad tx pairing stake-provider [chain-id] [amount] [endpoint endpoint ...] [geolocation] [flags]
Parameters:
chain-id - The ID of the serviced chain (e.g., COS4 or EHT1) find in list-spec
ammount - Stake amount in ulava
geolocation - what geolocation the provider/nodes will be hosted, all locations here:.
Endpoint Format:
<sub-domain for node>:<nginx-port>,geolocation
Flags:
--from - The wallet to be used for the provider ($PROVIDER_ACCOUNT).
--provider-moniker - Provider’s public name
--keyring-backend - A keyring-backend of your choosing (e.g., test).
--chain-id - The chain_id of the network (e.g., lava-testnet-2).
--gas - The gas limit for the transaction (e.g., "auto").
--gas-adjustment - The gas adjustment factor (e.g., "1.5").
--node - can be omitted if set in client.toml
Example with Ethereum:
ETH_STAKE_AMMOUNT=<ammount to stake, eg. "50000000000ulava">
ETH_NODE_MONIKER=<whatever moniker for this node>
ETH_SUBDOMAIN=<Subdomain for this node eg. provider-host.com>
ETH_NGINX_PORT=<port used for NGINX>
lavad tx pairing stake-provider "ETH1" $ETH_STAKE_AMMOUNT "$ETH_SUBDOMAIN:$ETH_NGINX_PORT,jsonrpc,2" 2 --from $PROVIDER_ACCOUNT --provider-moniker $ETH_NODE_MONIKER --keyring-backend "test" --chain-id "lava-testnet-2" --gas="auto" --gas-adjustment "1.5"
EVMs usually have only jsonrpc interface: (ws can usually be enabled)
Example with Cosmos:
COS_STAKE_AMMOUNT=<ammount to stake, eg. "50000000000ulava">
COS_NODE_MONIKER=<whatever moniker for this node>
COS_SUBDOMAIN=<Subdomain for this node eg. provider-host.com>
COS_NGINX_PORT=<port used for NGINX>
lavad tx pairing stake-provider "COS5T" $COS_STAKE_AMMOUNT "$COS_SUBDOMAIN:$COS_NGINX_PORT,2" 2 --from $PROVIDER_ACCOUNT --provider-moniker $COS_NODE_MONIKER --keyring-backend "test" --chain-id "lava-testnet-2" --gas="auto" --gas-adjustment "1.5"
Cosmos chains usually have rest, tendermintrpc & grpc interface, all mandatory:
Example with Avalanche:
AVAX_STAKE_AMMOUNT=<ammount to stake, eg. "50000000000ulava">
AVAX_NODE_MONIKER=<whatever moniker for this node>
AVAX_SUBDOMAIN=<Subdomain for this node eg. provider-host.com>
AVAX_NGINX_PORT=<port used for NGINX>
lavad tx pairing stake-provider "AVAX" $AVAX_STAKE_AMMOUNT "$AVAX_SUBDOMAIN:$AVAX_NGINX_PORT,2" 2 --from $PROVIDER_ACCOUNT --provider-moniker $AVAX_NODE_MONIKER --keyring-backend "test" --chain-id "lava-testnet-2" --gas="auto" --gas-adjustment "1.5"
Default http rpc port for avalanche is: 9650
Example with Juno:
JUNO_STAKE_AMMOUNT=<ammount to stake, eg. "50000000000ulava">
JUNO_NODE_MONIKER=<whatever moniker for this node>
JUNO_SUBDOMAIN=<Subdomain for this node eg. provider-host.com>
JUNO_NGINX_PORT=<port used for NGINX>
lavad tx pairing stake-provider "JUN1" $JUNO_STAKE_AMMOUNT "$JUNO_SUBDOMAIN:$JUNO_NGINX_PORT,2" 2 --from $PROVIDER_ACCOUNT --provider-moniker $JUNO_NODE_MONIKER --keyring-backend "test" --chain-id "lava-testnet-2" --gas="auto" --gas-adjustment "1.5"
Default Ports for Cosmos based nodes:-the gRPC server (default port: 9090)-the REST server (default port: 1317)-the CometBFT RPC endpoint (default port: 26657)
Verify Stake
# from wallet
lavad query pairing account-info --from $PROVIDER_ACCOUNT
# from address
lavad query pairing account-info <address>
Create a single configuration file to manage each endpoint/rpc node, each node will have its own dedicated provider process and configuration file.
All configuration files should be located in the default node home directory (e.g., app.DefaultNodeHome/config) or the local running directory.
mkdir lava-provider/config
nano lava-provider/config/rpcprovider.yml
node-urls: The endpoint URL/Sub-domain for nodes to provide on :< NGINX port> network-address: The URL for Lava full node, as it will be local use 127.0.0.1:2221, 2221 will be the default provider port to connect to Nginx service (from Step 4) More examples can be found here: Example for Juno: # Configuration for JUNO Chain
endpoints:
- api-interface: tendermintrpc
chain-id: JUN1
network-address:
address: 127.0.0.1:2221
disable-tls: true
node-urls:
- url: ws://127.0.0.1:26657/websocket
- url: http://127.0.0.1:26657
- api-interface: grpc
chain-id: JUN1
network-address:
address: 127.0.0.1:2221
disable-tls: true
node-urls:
url: 127.0.0.1:9090
- api-interface: rest
chain-id: JUN1
network-address:
address: 127.0.0.1:2221
disable-tls: true
node-urls:
url: http://127.0.0.1:1317
Example for Avax: # Configuration for AVAX Chain
endpoints:
- api-interface: jsonrpc
chain-id: AVAX
network-address:
address: 127.0.0.1:2221
disable-tls: true
node-urls:
- url: ws://127.0.0.1:3333/C/rpc/ws
internal-path: "/C/rpc" # c chain like specified in the spec
- url: https://127.0.0.1:3334/C/avax
internal-path: "/C/avax" # c/avax like specified in the spec
- url: https://127.0.0.1:3335/X
internal-path: "/X" # x chain like specified in the spec
- url: https://127.0.0.1:3336/P
internal-path: "/P" # p chain like specified in the spec
6. Set up Provider Service rpcprovider is a command line tool for setting up an RPC server that listens for requests from Lava protocol RPC consumers, forwards them to a configured node, and responds with the reply. The configuration can be provided via a YAML configuration file or as command line arguments. Command format lavad rpcprovider /path/to/config/rpcprovider.yml <flags>
rpcprovider accepts the following flags:
12--fromalicelavad rpcprovider --helplavad tx pairing --help12--fromalicelavad rpcprovider --helplavad tx pairing --help
No activity yet