Apply feedback to Run a Full Node page #253
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| @@ -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. | |||
There was a problem hiding this comment.
Add reasons a person would want a full node
Improved from "participate in a network"
Please verify that "read orderbook and on-chain data" is accurate
| # 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. | ||
| # 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. |
There was a problem hiding this comment.
Adds reasons a person would want to optimize
| @@ -2,7 +2,7 @@ | |||
| "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", | |||
| "running_full_node": "Optimize Your Full Node", | |||
There was a problem hiding this comment.
Updated title and reframed the page -- now about configuring an existing node for success
There was a problem hiding this comment.
should we rename the file name to reduce confusion?
There was a problem hiding this comment.
Will do in the next round of changes
| 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 Persistent Peers | ||
| Save a list of healthy peers to more quickly and reliably read the latest data from the network. |
There was a problem hiding this comment.
Please verify this is accurate
| ## 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 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. |
There was a problem hiding this comment.
Please verify this is accurate
| 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. | ||
|
|
||
| ## Prepare to Restore Your Node |
There was a problem hiding this comment.
Reframed this section from "Restore your Node" -- the page is about optimizing your node to keep a healthy connection, so this section is about configuring your system so that you can restore right away/ automatically if you need to. There should be procedures on another page and we should link to them from here when they're done
|
|
||
| ### 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. |
There was a problem hiding this comment.
Need to create a procedure for doing this in another PR
| @@ -2,7 +2,7 @@ | |||
| "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", | |||
| "running_full_node": "Optimize Your Full Node", | |||
There was a problem hiding this comment.
nit: we should update the filename accordingly
| "running_full_node": "Optimize Your Full Node", | |
| "optimize_full_node": "Optimize Your Full Node", |
There was a problem hiding this comment.
if/when you do this can you add a redirect to next.config.js? some paths are indexed in google/etc and used in other places, we should try to keep the original paths
There was a problem hiding this comment.
update the filename to optimize_full_node.md to match the comment above
| @@ -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. | |||
| ```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. | ||
| - 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. |
There was a problem hiding this comment.
nit: this is basically duplicate info across Cosmovisor route and the direct binary route.
can we dedup this?
| ## 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. | ||
| ## Customize Node Settings | ||
| The following recommended settings and best practices help ensure that your node stays healthy and up to date with the network. |
There was a problem hiding this comment.
nit: noticed that we use hyphenated version above, so I think we should be consistent? no preference on which way, but just want consistency
| The following recommended settings and best practices help ensure that your node stays healthy and up to date with the network. | |
| The following recommended settings and best practices help ensure that your node stays healthy and up-to-date with the network. |
There was a problem hiding this comment.
good callout, I actually messed up a different one. It should be hyphened when its a compound modifier before a noun (up-to-date addrbook.json) but not hyphenated when used as part of a sentence (up to date with the network), so planning to leave this one as is and fix a spot where I hyphenated when I shouldn't have
| > 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 Your Node's State Sync |
There was a problem hiding this comment.
I think this is more automated than manually downloading snapshots, so would it make sense to recommend this over the manual snapshot route? if so, can we move this section to be above the other option?
There was a problem hiding this comment.
That makes a lot of sense. Also, from our discussion, it seems like practically you'd want to do a little more than save one snapshot (you'd want your own process to update the saved snapshot). I'll reorder like you suggested, and longer term I wonder if it makes sense to take this out. Could seem like were recommending saving one snapshot. I think if we remove the snapshot section it should be in another PR that also addresses the step in Set Up a Node
| You can use a snapshot saved on the system on which your node runs to restore your node. | ||
|
|
||
| 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). |
There was a problem hiding this comment.
I think this can be made more clear. Currently, the word "back up" and "install" are confusing.
The main point to get across here is:
- you should download snapshots from snapshot service providers
- then use the downloaded snapshot to restore/overwrite your node state (https://docs.dydx.exchange/infrastructure_providers-validators/how_to_set_up_full_node#step-8-use-a-snapshot-as-your-nodes-initial-state)
| 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). | ||
|
|
||
| > 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. |
There was a problem hiding this comment.
should we remove this?
the snapshot outlined in the "set up" doc is for the initial start up. IMO, this is about acquiring a new snapshot (ie snapshot at a higher height)
|
|
||
| ### 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. |
There was a problem hiding this comment.
State sync is a process that automates the state syncing process by automatically fetching snapshots.
I think it's worth reading this doc and summarizing it in 1-2 sentences here for a high-level overview of this approach. I found this part to be sufficient:
... state sync, which allows a new node to join a network by fetching a snapshot of the application state at a recent height instead of fetching and replaying all historical blocks. This can reduce the time needed to sync with the network from days to minutes.
..., the good news is that the upcoming 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. We’ll explain how in this article, but first some background.
|
|
||
| ### Save a Snapshot on Your System | ||
| You can use a snapshot saved on the system on which your node runs to restore your node. |
There was a problem hiding this comment.
From our convo, i think this approach is about proactively downloading snapshots from snapshot providers and saving them on your system to reduce the time for your node to use the latest snapshot. I think this text can use clarification to get this point across.
|
|
||
| - 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 |
There was a problem hiding this comment.
for my understanding, does this command not need the --non-validating-full-node=true flag?
There was a problem hiding this comment.
It does require the flag, but the Set Up a Full Node procedure has you set up a system service that includes the flag already. So this just calls out that if you're coming here from the Next Steps of that procedure, this is how its set up
| Save it in your `/.dydxprotocol/config` directory, replacing the existing `addrbook.json` file. | ||
|
|
||
| ## Prepare to Restore Your Node | ||
| Prepare to restore your node quickly in case it falls out of sync, minimizing downtime. |
There was a problem hiding this comment.
nit / personal preference: will defer to you
| Prepare to restore your node quickly in case it falls out of sync, minimizing downtime. | |
| To minimize downtown, prepare to restore your node quickly in case it falls out of sync. |
There was a problem hiding this comment.
Updating to:
To minimize downtime in case your node falls out of sync, make preparations to restore your node quickly.
Thought process: starting with "To minimize downtime, ..." is fine, but also ending with "in case it falls out of sync" requires the reader to hold context in mind til the end of the sentence to understand that we're minimizing "out of sync" downtime. Until the end of the sentence, a reader doesn't know what downtime we're talking about
| 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. |
There was a problem hiding this comment.
This is for me/us -- note to self to revisit this and add a procedure to set this option
| 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 | ||
| In general, dYdX recommends the following pruning setting, configured in your `app.toml` file: |
There was a problem hiding this comment.
| In general, dYdX recommends the following pruning setting, configured in your `app.toml` file: | |
| To reduce the amount of storage your node requires, dYdX recommends the following pruning setting, configured in your `app.toml` file: |
This PR addresses feedback in PR 247 (see original comments there)
I called out a few places I'd like to double check
As long as this is an improvement to the live docs I'd like to publish this frame and add on piece by piece. There is definitely more detail to add (more context around optimizations, procedures for restore, etc) which I plan to do via Linear tickets for individual sections