dydxprotocol · zachfc · Aug 6, 2024 · Aug 5, 2024 · Aug 5, 2024 · Aug 5, 2024
@@ -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",

@@ -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,[email protected]:26656,[email protected]:26656,[email protected]:23856,[email protected]: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.
+
+<!-- 
+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
+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.
@@ -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.
+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.
@@ -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).
 

@@ -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.
@@ -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).
 
 </details>