-
Notifications
You must be signed in to change notification settings - Fork 35
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
4 changed files
with
128 additions
and
70 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
109 changes: 48 additions & 61 deletions
109
pages/infrastructure_providers-validators/running_full_node.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,73 +1,60 @@ | ||
| # Running a Full Node | ||
|
|
||
| ### Save your Chain ID in `dydxprotocold` config | ||
|
|
||
| Save the [chain-id](../infrastructure_providers-network/network_constants.mdx#chain-id). This will make it so you do not have to manually pass in the chain-id flag for every CLI command. | ||
|
|
||
| ```bash | ||
| dydxprotocold config chain-id $CHAIN_ID | ||
| # Run a Full Node | ||
| Running a full node allows your system to participate in a dYdX chain network. The recommended settings and best practices on this page help ensure your node stays healthy and up to date with the network. | ||
|
|
||
| > Code snippets on this page use example values. Replace them with your own. See the [Network Configuration](../infrastructure_providers-network/network_constants.mdx) section of the documentation for network constants and other resources you need to configure a full node. | ||
| ## Prerequisites | ||
| You need a running, non-validating full node that is connected to network. | ||
|
|
||
| - If you created a system service for your node by following the instructions on the previous page, [Set Up a Full Node](../infrastructure_providers-validators/how_to_set_up_full_node.md), start your node with the following command: | ||
| ```bash | ||
| stystemctl start dydxprotocold | ||
| ``` | ||
| - To start your node with Cosmovisor, include the flag `--non-validating-full-node=true`. Cosmovisor may prompt you to configure additional variables in your environment or include them in your command. | ||
| ```bash | ||
| cosmovisor run start --non-validating-full-node=true | ||
| ``` | ||
| > The flag `--non-validating-full-node` is required. It disables the functionality intended for validator nodes and enables additional logic for reading data. | ||
| - To start your node directly with the `dydxprotocold` binary, include the flag `--non-validating-full-node=true`. `dydxprotocold` may prompt you to configure additional variables in your environment or include them in your command. | ||
|
|
||
| ```bash | ||
| dydxprotocold run start --non-validating-full-node=true | ||
| ``` | ||
| > The flag `--non-validating-full-node` is required. It disables the functionality intended for validator nodes and enables additional logic for reading data. | ||
| ## Connect to Healthy Peers | ||
| To keep your full node up to date, connect to healthy peers with the latest state of the network. Request a list of healthy peers for your deployment from a [Live Peer Node](../infrastructure_providers-network/resources#live-peer-node-providers) provider. | ||
|
|
||
| From the list of healthy peers that you retrieve from peer node provider, choose any 5 for your node to query for the latest state. Add a comma-separated list of those peer addresses to the `persistent_peers` field in your `config.toml`, like in the following example: | ||
|
|
||
| ```yaml | ||
| # config.toml | ||
| # Example values from Polkachu for dydx-mainnet-1 | ||
| persistent_peers=83c299de2052db247f08422b6592e1383dd7a104@136.243.36.60:23856,[email protected]:26656,[email protected]:26656,[email protected]:23856,[email protected]:26656 | ||
| ``` | ||
|
|
||
| ### Getting a Snapshot | ||
|
|
||
| See [snapshot service](../infrastructure_providers-network/resources.mdx#snapshot-service). | ||
|
|
||
| ### Starting a Full Node | ||
|
|
||
| Find the seed node's ID and the IP address from [Resources](../infrastructure_providers-network/resources.mdx#seed-nodes). Then, run the following command to start a non-validating full node. | ||
|
|
||
| For example, | ||
| ```bash | ||
| dydxprotocold start --p2p.seeds="..." --bridge-daemon-eth-rpc-endpoint="<eth rpc endpoint>" --non-validating-full-node=true | ||
| ``` | ||
|
|
||
| 💡**Note**: if you want to disable gRPC on your full node, it is important to start the node with the | ||
| `--non-validating-full-node=true` flag. Otherwise, the application will require that gRPC be enabled. | ||
|
|
||
|
|
||
| ## Staying up-to-date with the Latest State | ||
|
|
||
| ### Connecting to Healthy Peers | ||
|
|
||
| In order for the full node to have the latest state, it needs to connect to peers which have the latest state Use the following links to get a list of live peers which have the latest state | ||
|
|
||
| https://services.lavenderfive.com/mainnet/dydx#live-peers | ||
|
|
||
| https://polkachu.com/live_peers/dydx | ||
|
|
||
| Update `persistent_peers` in the config.toml file to include a randomly selected list of 5 peers from the list of live peers obtained using the links above | ||
|
|
||
| ### Snapshots | ||
|
|
||
| Snapshots contain a compressed copy of the chain data which allow the full node to bootstrap to a recent state in the blockchain. A list of snapshot services can be found [here](../infrastructure_providers-network/resources.mdx#snapshot-service). | ||
|
|
||
| ### State sync (Alternative to snapshots) | ||
|
|
||
| State Sync enables a new node to join the network by obtaining a snapshot of the application state from a state sync node at a recent height. This eliminates the need to fetch and replay all historical blocks. A list of state sync services with instructions are listed below | ||
|
|
||
| https://polkachu.com/state_sync/dydx | ||
|
|
||
| https://services.lavenderfive.com/mainnet/dydx/statesync | ||
|
|
||
| https://autostake.com/networks/dydx/#state-sync | ||
|
|
||
| ### Address Book | ||
| ## Save an Address Book | ||
| Download the latest `addrbook.json` file, which stores configuration details that help your node efficiently connect to peers in its network. Download an up-to-date address book file for your deployment from an [Address Book](../infrastructure_providers-network/resources#address-book-providers) provider. | ||
|
|
||
| The **`addrbook.json`** file is used to store configuration details that help a node connect to other peers in the network more efficiently. This can be obtained from the one of the below services and needs to be stored in the `config` folder. | ||
| Save the `addrbook.json` file in your `/.dydxprotocol/config` directory. | ||
|
|
||
| https://polkachu.com/addrbooks/dydx | ||
| ## Back Up Your Node | ||
| > If you followed the procedure on the previous page, [Set Up a Full Node](../infrastructure_providers-validators/how_to_set_up_full_node.md), you already have a snapshot installed. | ||
| https://services.lavenderfive.com/mainnet/dydx#latest-addrbook | ||
| Your full node needs a backup plan to replay the history of the network in case it falls out of sync. You can back up your node in one of two ways. | ||
|
|
||
| https://autostake.com/networks/dydx/ | ||
| ### Snapshot | ||
| You can use a **snapshot** stored on the system that your node runs on. A snapshot contains a compressed copy of the application state at the time the snapshot was taken. If your node falls out of sync, a snapshot allows the node to recover to that saved state before replaying the rest of the history of the network. This speeds up the syncing process because you avoid replaying the entire history of the network, instead starting from your stored application state snapshot. To use a snapshot to back up your full node, install a snapshot for your deployment from a [Snapshot Service](../infrastructure_providers-network/resources.mdx#snapshot-service). | ||
|
|
||
| ## Pruning Settings | ||
| ### State Sync | ||
| You can use **state sync**, a set of configuration settings that allow your node to retrieve a snapshot from the network. If your node falls out of sync, it queries a state sync node for a verified, recent snapshot of the application state. This speeds up the syncing process because you avoid replaying the entire history of the network, instead starting from the network's most recent application state snapshot. To use state sync to back up your full node, follow the instructions for your deployment from a [State Sync](../infrastructure_providers-network/resources#state-sync-service) service. | ||
|
|
||
| For optimal storage, use the following pruning setting in the app.toml file: | ||
| ## Optimize Pruning Settings | ||
| In general, dYdX recommends the following pruning setting, configured in your `app.toml` file: | ||
|
|
||
| ```bash | ||
| # 2 latest states will be kept; pruning at 10 block intervals. | ||
| pruning = "everything" | ||
| # app.toml | ||
| pruning = "everything" # 2 latest states will be kept; pruning at 10 block intervals | ||
| ``` | ||
|
|
||
| If the full node is being used for historical queries, a custom strategy should be used to maintain more states. This will increase storage requirements. | ||
| However, if you want to use your node to query historical data, configure a custom pruning strategy to retain more states. Retaining more states increases storage requirements. |
e326659There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You must have Developer access to commit code to dYdX Trading on Vercel. If you contact an administrator and receive Developer access, commit again to see your changes.
Learn more: https://vercel.com/docs/accounts/team-members-and-roles/access-roles#team-level-roles