feedback

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": "Optimize Your 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",

pages/infrastructure_providers-validators/running_full_node.md → pages/infrastructure_providers-validators/optimize_full_node.md

@@ -1,5 +1,5 @@
 # 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.
+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.
 
@@ -10,21 +10,24 @@ You need a running, non-validating full node that is connected to a network.
   ```bash
   stystemctl start dydxprotocold
   ```
-- To start your node with Cosmovisor, 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. Cosmovisor may prompt you to configure additional variables in your environment or include them in your command.
+
+- 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 
+  cosmovisor run start --non-validating-full-node=true
   ```
-- To start your node directly 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. `dydxprotocold` may prompt you to configure additional variables in your environment or include them in your command.
-
+
+  To start your node with `dydxprotocold`, run the following command:
   ```bash
   dydxprotocold run start --non-validating-full-node=true 
   ```
 
-## Customize Node Settings
-The following recommended settings and best practices help ensure that your node stays healthy and up to date with the network.
+## 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
-Save a list of healthy peers to more quickly and reliably read the latest data from the network.
+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.
 
@@ -36,38 +39,40 @@ From the list of healthy peers that you retrieve from peer node provider, choose
 persistent_peers=83c299de2052db247f08422b6592e1383dd7a104@136.243.36.60:23856,[email protected]:26656,[email protected]:26656,[email protected]:23856,[email protected]:26656
 ```
 
-### Save an Address Book File
-Save an address book file of trusted nodes operated by a provider to more quickly and reliably connect to the network.
+### 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 the `addrbook.json` file in your `/.dydxprotocol/config` directory.
+Save it in your `/.dydxprotocol/config` directory, replacing the existing `addrbook.json` file.
 
-### Configure a Pruning Strategy
-In general, dYdX recommends the following pruning setting, configured in your `app.toml` file:
+## Prepare to Restore Your Node
+Prepare to restore your node quickly in case it falls out of sync, minimizing downtime.
 
-```bash
-# app.toml
-pruning = "everything" # 2 latest states will be kept; pruning at 10 block intervals
-```
+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.
 
-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.
+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.
 
-## Prepare to Restore Your Node
-Prepare to restore your node quickly in case it falls out of sync. 
+### 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.
 
-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 must replay the history of the network.
+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.
 
-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 time.
+<!-- 
+Cosmos SDK 0.40 release will include automatic support for state sync, and developers only need to enable it in their applications to make use of it. Replace above with a procedure.
+-->
 
 ### Save a Snapshot on Your System
-You can use a snapshot saved on the system on which your node runs to restore your node.
+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 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).
+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).
 
-> 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.
+## Configure a Pruning Strategy
+In general, dYdX recommends the following pruning setting, configured in your `app.toml` file:
 
-### Configure Your Node's State Sync
-You can use state sync, a configuration setting that allows your node to retrieve a snapshot from the network, to restore your node.
+```bash
+# app.toml
+pruning = "everything" # 2 latest states will be kept; pruning at 10 block intervals
+```
 
-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.
+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.