From c31320e9444b1cd5cf9a63f2b610ccad66471755 Mon Sep 17 00:00:00 2001 From: zach Date: Tue, 6 Aug 2024 14:23:35 -0400 Subject: [PATCH] Apply feedback to Run a Full Node page (#253) --- .../_meta.json | 4 +- .../optimize_full_node.md | 78 +++++++++++++++++++ .../running_full_node.md | 60 -------------- ...et_up_full_node.md => set_up_full_node.md} | 4 +- .../upgrades/cosmovisor.md | 2 +- .../upgrades/upgrading_sidecar.md | 2 +- pages/introduction-onboarding_faqs.mdx | 2 +- 7 files changed, 85 insertions(+), 67 deletions(-) create mode 100644 pages/infrastructure_providers-validators/optimize_full_node.md delete mode 100644 pages/infrastructure_providers-validators/running_full_node.md rename pages/infrastructure_providers-validators/{how_to_set_up_full_node.md => set_up_full_node.md} (98%) diff --git a/pages/infrastructure_providers-validators/_meta.json b/pages/infrastructure_providers-validators/_meta.json index 79f65b76..4da77aca 100644 --- a/pages/infrastructure_providers-validators/_meta.json +++ b/pages/infrastructure_providers-validators/_meta.json @@ -1,8 +1,8 @@ { "hardware_requirements": "Hardware Requirements", "required_node_configs": "Required Node Configs", - "how_to_set_up_full_node": "Set Up a Full Node", - "running_full_node": "Run a Full Node", + "set_up_full_node": "Set Up a Full Node", + "optimize_full_node": "Optimize Your Full Node", "running_a_validator": "Running a Validator", "snapshots": "Snapshots", "full_node_streaming": "Full Node Streaming", diff --git a/pages/infrastructure_providers-validators/optimize_full_node.md b/pages/infrastructure_providers-validators/optimize_full_node.md new file mode 100644 index 00000000..d42fb9f1 --- /dev/null +++ b/pages/infrastructure_providers-validators/optimize_full_node.md @@ -0,0 +1,78 @@ +# Optimize Your Full Node +Optimizing your full node helps keep it online, up to date, and operating quickly. Faster nodes have an advantage over slower nodes because they tend to receive new data first and they minimize the time between placing and resolving orders. Optimize your full node by connecting to trusted nodes, taking precautions against falling out of sync with the network, and configuring storage settings. + +> 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 a 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/set_up_full_node.md), start your node with the following command: + ```bash + stystemctl start dydxprotocold + ``` + +- To start your node with Cosmovisor or with the `dydxprotocold` binary, you must include the flag `--non-validating-full-node=true`. The flag disables the functionality intended for validator nodes and enables additional logic for reading data. Your CLI may prompt you to configure additional variables in your environment or include them in your command. + + To start your node with Cosmovisor, run the following command: + ```bash + cosmovisor run start --non-validating-full-node=true + ``` + + To start your node with `dydxprotocold`, run the following command: + ```bash + dydxprotocold run start --non-validating-full-node=true + ``` + +## Save a List of Trusted Nodes +Specify a list of healthy, stable nodes that you trust. Your node prioritizes connecting to those nodes, speeding up the process of connecting or re-connecting to the network. Connecting directly with a peer node is faster than connecting to a seed node and then finding new peers. + +### Save a List of Persistent Peers +You can save a list of healthy, stable nodes in the `persistent_peers` field of your `config.toml` file. + +Request a list of healthy peers for your deployment from a [Live Peer Node](../infrastructure_providers-network/resources.mdx#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,1c64b35055d34ff3dd199bb4a5a3ae46b9c10c89@3.114.126.71:26656,3651c82a89f8f4d6fc30fb27b91159f0de092031@202.8.9.134:26656,580ec248de1f41d4e50abe132b7838348db55b80@176.9.144.40:23856,febe75fb6e70a60ce6344b82ff14903bcb53a209@38.122.229.90:26656 +``` + +### Replace Your Address Book File +As an alternative to persistent peers, you can replace your node's local address book with the latest address book from a trusted provider. The address book file contains the latest connection information for peers from that provider. + +Download an up-to-date `addrbook.json` file for your deployment from an [Address Book](../infrastructure_providers-network/resources.mdx#address-book-providers) provider. + +Save it in your `/.dydxprotocol/config` directory, replacing the existing `addrbook.json` file. + +## Prepare to Restore Your Node +To minimize downtime in case your node falls out of sync, make preparations to restore your node quickly. + +Your full node can fall out of sync with the rest of the network for a variety of reasons, including a bad software upgrade, unexpected node crashes, or human operational error. To re-sync with the network, your full node needs to replay the history of the network, which can take a long time. + +You can speed up the re-syncing process significantly by providing your node with a snapshot. 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 it to recover to that saved state before replaying the rest of the history of the network, saving you time. + +### Configure Your Node's State Sync Setting +You can use state sync, a configuration setting that allows your node to retrieve a snapshot from the network, to ensure that your node can be restored quickly if it falls out of sync. + +To use state sync for quick recovery in case your node falls out of sync, follow the instructions for your deployment from a [State Sync](../infrastructure_providers-network/resources.mdx#state-sync-service) service. + + + +### Save a Snapshot on Your System +As an alternative to state sync, you can use a snapshot that you have saved on your node's system to restore your node if it falls out of sync. + +To save a snapshot on your system for quick recovery in case your node falls out of sync, install a snapshot for your deployment from a [Snapshot Service](../infrastructure_providers-network/resources.mdx#snapshot-service). + +## Configure a Pruning Strategy +To reduce the amount of storage your node requires, dYdX recommends the following pruning setting, configured in your `app.toml` file: + +```bash +# app.toml +pruning = "everything" # 2 latest states will be kept; pruning at 10 block intervals +``` + +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. \ No newline at end of file diff --git a/pages/infrastructure_providers-validators/running_full_node.md b/pages/infrastructure_providers-validators/running_full_node.md deleted file mode 100644 index 538cc01b..00000000 --- a/pages/infrastructure_providers-validators/running_full_node.md +++ /dev/null @@ -1,60 +0,0 @@ -# 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.mdx#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,1c64b35055d34ff3dd199bb4a5a3ae46b9c10c89@3.114.126.71:26656,3651c82a89f8f4d6fc30fb27b91159f0de092031@202.8.9.134:26656,580ec248de1f41d4e50abe132b7838348db55b80@176.9.144.40:23856,febe75fb6e70a60ce6344b82ff14903bcb53a209@38.122.229.90:26656 -``` - -## 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.mdx#address-book-providers) provider. - -Save the `addrbook.json` file in your `/.dydxprotocol/config` directory. - -## Restore 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. - -Your full node needs a backup plan to replay the history of the network in case it falls out of sync. You can prepare a backup for your node in one of two ways. - -### 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). - -### 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.mdx#state-sync-service) service. - -## Optimize Pruning Settings -In general, dYdX recommends the following pruning setting, configured in your `app.toml` file: - -```bash -# app.toml -pruning = "everything" # 2 latest states will be kept; pruning at 10 block intervals -``` - -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. \ No newline at end of file diff --git a/pages/infrastructure_providers-validators/how_to_set_up_full_node.md b/pages/infrastructure_providers-validators/set_up_full_node.md similarity index 98% rename from pages/infrastructure_providers-validators/how_to_set_up_full_node.md rename to pages/infrastructure_providers-validators/set_up_full_node.md index 638c0801..9a1f2682 100644 --- a/pages/infrastructure_providers-validators/how_to_set_up_full_node.md +++ b/pages/infrastructure_providers-validators/set_up_full_node.md @@ -1,5 +1,5 @@ # Set Up a Full Node -Installing and running a full node allows your system to participate in a dYdX Chain network. +Installing and running a full node allows you to read orderbook and on-chain data from a network, as well as place, confirm and cancel orders directly on that 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. @@ -253,4 +253,4 @@ curl localhost:26657/status When your full node's latest block is the same as the network's latest block, your full node is ready to participate in the network. ## Next Steps -When your full node is up to date with the network, you can use it to read live data and configure additional settings. Learn more on the [Running a Full Node](../infrastructure_providers-validators/running_full_node.md) page. \ No newline at end of file +When your full node is up to date with the network, you can use it to read live data and configure additional settings. Learn more on the [Running a Full Node](../infrastructure_providers-validators/optimize_full_node.md) page. \ No newline at end of file diff --git a/pages/infrastructure_providers-validators/upgrades/cosmovisor.md b/pages/infrastructure_providers-validators/upgrades/cosmovisor.md index 694a11eb..6131ae19 100644 --- a/pages/infrastructure_providers-validators/upgrades/cosmovisor.md +++ b/pages/infrastructure_providers-validators/upgrades/cosmovisor.md @@ -8,7 +8,7 @@ We recommend validators to use `cosmovisor` to run their nodes. This will make l When Cosmovisor activates an upgrade, it does a backup of the entire data directory by default. This backup can take a very long time to process unless the user does aggressive historical-state-pruning using the `pruning` [configuration on the node](../required_node_configs.md). -As long as you have access to a previous state [snapshot](../snapshots.md), we recommend setting the environment variable `UNSAFE_SKIP_BACKUP` to `false` which skips the data backup and allows a much faster upgrade. If your node is configured to only keep a small amount of historical state, then you may be able to get away with running the backup quickly. +As long as you have access to a previous state [snapshot](../snapshots.md), we recommend setting the environment variable `UNSAFE_SKIP_BACKUP` to `true` which skips the data backup and allows a much faster upgrade. If your node is configured to only keep a small amount of historical state, then you may be able to get away with running the backup quickly. More information about Cosmovisor settings can be found in the [Cosmovisor documentation](https://docs.cosmos.network/main/build/tooling/cosmovisor). diff --git a/pages/infrastructure_providers-validators/upgrades/upgrading_sidecar.md b/pages/infrastructure_providers-validators/upgrades/upgrading_sidecar.md index cc7b5b7f..e2906194 100644 --- a/pages/infrastructure_providers-validators/upgrades/upgrading_sidecar.md +++ b/pages/infrastructure_providers-validators/upgrades/upgrading_sidecar.md @@ -1,3 +1,3 @@ -Starting in `v5.0.0`, all validating full nodes should be running the [Sidecar](../running_full_node.md#slinky-sidecar). Non validating full nodes do not need to run the sidecar. +Starting in `v5.0.0`, all validating full nodes should be running the [Sidecar](../optimize_full_node.md#slinky-sidecar). Non validating full nodes do not need to run the sidecar. Follow instructions [here](https://docs.skip.build/connect/validators/faq#how-do-i-upgrade-the-connect-binary) to upgrade the sidecar. diff --git a/pages/introduction-onboarding_faqs.mdx b/pages/introduction-onboarding_faqs.mdx index cad773f0..28a51dc5 100644 --- a/pages/introduction-onboarding_faqs.mdx +++ b/pages/introduction-onboarding_faqs.mdx @@ -24,7 +24,7 @@ - Running a full node will eliminate the latency between placing an order and when the actual order is gossiped throughout the network. Without your own node, your order will need to first be relayed to the nearest geographic node, which will then propagate it throughout the network for you. With your own node, your order will directly be gossiped. - Additionally, running a full node allows you to use [full node streaming](./infrastructure_providers-validators/full_node_streaming.md), a feature that aims to provide real-time, accurate orderbook updates and fills. -- Instructions on setting up a full node can be found [here](./infrastructure_providers-validators/how_to_set_up_full_node.md). +- Instructions on setting up a full node can be found [here](./infrastructure_providers-validators/set_up_full_node.md).