Revisions for setting up a full node #232
Conversation
|
Someone is attempting to deploy a commit to the dYdX Trading Team on Vercel. A member of the Team first needs to authorize it. |
|
|
||
| ## Prerequisites | ||
| - Linux (Ubuntu Server 22.04.3 or later recommended) |
There was a problem hiding this comment.
Is Linux the only OS this works on? Asking because there's a .zip and .tar.gz source code download
There was a problem hiding this comment.
nope you can run this on any ARM or AMD64 servers, which should cover newer Macs and AMD based windows too
| ## Prerequisites | ||
| - Linux (Ubuntu Server 22.04.3 or later recommended) | ||
| - 8-core CPU (ARM or x86_64) |
There was a problem hiding this comment.
Is "8-core" accurate? I assumed this is what was meant by 8-cpu.
| # Set Up a Full Node | ||
|
|
||
| > Examples on this page are for mainnet deployments by dYdX token holders. For information on alternative deployment types, including testnet deployments in the United States, see the [Network Constants page](../infrastructure_providers-network/network_constants.mdx). |
There was a problem hiding this comment.
Please check for accuracy
There was a problem hiding this comment.
This works for now but unfortunately the deployment information is kind of spread out between documents. Like for example, the resources page has some info too
|
|
||
| ## Download the `dydxprotocold` binary and initialize the data directory | ||
| The binary contains the software you need to operate a full node. Initializing a data directory dedicates a folder on your system to recordkeeping, such as logging. |
There was a problem hiding this comment.
Please check for accuracy
zachfc
changed the title
|
|
||
| ## Fetch and install the latest `genesis.json` file | ||
| The `genesis.json` file defines an initial state for the dYdX chain. |
There was a problem hiding this comment.
Please check for accuracy
| ``` | ||
|
|
||
| When you start your full node it will automatically use the snapshot you saved to its data directory. |
There was a problem hiding this comment.
Please check for accuracy
Let me know if I can be more specific than "uses"
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
|
||
| ## Prerequisites | ||
| - Linux (Ubuntu Server 22.04.3 or later recommended) |
There was a problem hiding this comment.
nope you can run this on any ARM or AMD64 servers, which should cover newer Macs and AMD based windows too
| # Set Up a Full Node | ||
|
|
||
| > Examples on this page are for mainnet deployments by dYdX token holders. For information on alternative deployment types, including testnet deployments in the United States, see the [Network Constants page](../infrastructure_providers-network/network_constants.mdx). |
There was a problem hiding this comment.
This works for now but unfortunately the deployment information is kind of spread out between documents. Like for example, the resources page has some info too
| ## Prerequisites | ||
| - Linux (Ubuntu Server 22.04.3 or later recommended) | ||
| - 8-core CPU (ARM or x86_64) |
| 1. Find the latest `Release protocol` from the [v4 Chain Releases](https://github.com/dydxprotocol/v4-chain/releases/) page. Download the compressed source code file appropriate for your system. | ||
|
|
||
| For example, to use `Release protocol/v5.0.5` on Ubuntu, download `Source code.tar.gz`. |
There was a problem hiding this comment.
Hmm this might be off. We want them to download the dydxprotocold-xyz.tar.gz files (example) rather than the source code
pages/infrastructure_providers-validators/how_to_set_up_full_node.md
Outdated
Show resolved
Hide resolved
pages/infrastructure_providers-validators/how_to_set_up_full_node.md
Outdated
Show resolved
Hide resolved
| The binary contains the software you need to operate a full node. Initializing a data directory dedicates a folder on your system to recordkeeping, such as logging. | ||
|
|
||
| 1. Find the latest `Release protocol` from the [v4 Chain Releases](https://github.com/dydxprotocol/v4-chain/releases/) page. Download the compressed source code file appropriate for your system. |
There was a problem hiding this comment.
nit: it would be good to add some command line instructions on how to do this too.
https://gist.github.com/steinwaywhw/a4cd19cda655b8249d908261a62687f8?permalink_comment_id=3924479
| 1. Find the latest `Release protocol` from the [v4 Chain Releases](https://github.com/dydxprotocol/v4-chain/releases/) page. Download the compressed source code file appropriate for your system. | ||
|
|
||
| For example, to use `Release protocol/v5.0.5` on Ubuntu, download `Source code.tar.gz`. |
| For example, to use `Release protocol/v5.0.5` on Ubuntu, download `Source code.tar.gz`. | ||
|
|
||
| 2. Extract and rename the binary from `Source code` to `dydxprotocold`. Move the file to a directory in your `$PATH` so that you can initialize it with your command line. |
There was a problem hiding this comment.
Overall, i think we should try to paste in snippets of code that basically does the step whenever possible.
- The renaming part might be necessary, but the "move file" is prob not necessary.
- Alternatively, you can create a symbolic link instead of renaming:
ln -s /path/to/target my_link
- Also, do we define $PATH somewhere? First time seeing it on this page
There was a problem hiding this comment.
I think that defining $PATH should be out of scope for this. I think it falls into general developer knowledge/ not dYdX domain/ something users should Google. In my mind the same goes for things like curl, "command line", RAM, NVME storage
Happy to discuss, and defer to you if you think the audience needs guidance on adding things to their PATH
| ``` | ||
|
|
||
| When you have confirmed that your full node is up to date with the rest of the dYdX |
There was a problem hiding this comment.
We should prob add some section or page around when the node needs to be upgraded to the new binary.
This should prob be another PR tho
|
|
||
| ```bash | ||
| nohup dydxprotocold start |
There was a problem hiding this comment.
I'm not sure, I kept it from the existing content. I'll remove it for now because more straightforward examples are better and it sounds unnecessary
| --home=$DYDX_HOME | ||
| --non-validating-full-node=true | ||
| > /tmp/fullnode.log 2>&1 & |
There was a problem hiding this comment.
why do we need to pipe the logs here?
There was a problem hiding this comment.
We don't -- I'll remove it so the example is simpler
pages/infrastructure_providers-validators/how_to_set_up_full_node.md
Outdated
Show resolved
Hide resolved
|
|
||
| # Example values | ||
| FULL_NODE_IP_ADDRESS=192.168.0.150 |
There was a problem hiding this comment.
One way on Mac is runningipconfig getifaddr en0 (wifi) or ipconfig getifaddr en1 (ethernet)
I'm tempting to say this should be out of scope, too. There are a lot of ways to get your IP and a few factors for whether a command works or not, but at the end of the day most developers will have a way to get the one they want to use (probably by googling it), whether it's for a VM or their physical machine
There was a problem hiding this comment.
gotcha, i think we should skip
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
|
Hey @ttl33, could you take another look at this whenever you have time? Implemented most of your suggestions -- the things I have not addressed:
Also, I'll use this PR to merge: #236 |
pages/infrastructure_providers-validators/how_to_set_up_full_node.md
Outdated
Show resolved
Hide resolved
| > For example, for protocol version 5.0.5 on an AMD system, download `dydxprotocold-v5.0.5-linux-amd64.tar.gz`. | ||
|
|
||
| Alternatively, you can install the latest release protocol by modifying [this curl command](https://gist.github.com/steinwaywhw/a4cd19cda655b8249d908261a62687f8) for your case. |
There was a problem hiding this comment.
instead of pointing to another github gist, I recommend pasting in the actual curl command that the user can copy/paste to download dydxprotocold-v5.0.5-linux-amd64.tar.gz
IMO, we should minimize the number of redirects to other sites
| The `dydxprotocold` binary contains the software you need to operate a full node. You must use the same version of the software as the network to which you want to connect. | ||
|
|
||
| 1. Find the current version of the dYdX network. |
There was a problem hiding this comment.
should we explain how to figure this out? IMO, there's a pretty good chance users on this site don't know how to do this
There was a problem hiding this comment.
Definitely -- I don't know how to do it and need to find out. Do you know what the best way or best options are?
|
|
||
| **Option 1:** Rename the file. Edit the filename from `dydxprotocold-<version>-<architecture>` to simply `dydxprotocold`. You might need to add your current directory to your $PATH or move the file to a directory in your $PATH. | ||
|
|
There was a problem hiding this comment.
should we add the example command like the following?
mv dydxprotocold-v5.0.6-linux-arm64 dydxprotocoldThere was a problem hiding this comment.
Yes, I'll add this and start doing that with each step that calls for it
I do think using example values is clearer, like mv dydxprotocold-<version>-<architecture> dydxprotocold. They call attention to custom attributes and stop the user from trying to run a command as-is
| **Option 2:** Create a symbolic link to the file using the name `dydxprotocold`. Run the following command: | ||
| ```bash | ||
| ln -s /path/to/your/binary dydxprotocold |
There was a problem hiding this comment.
should we continue using the same example like this?
| ln -s /path/to/your/binary dydxprotocold | |
| ln -s mv dydxprotocold-v5.0.6-linux-arm64 dydxprotocold |
There was a problem hiding this comment.
Reformatting these to both use "/path/to/dydxprotocold--" -- it's my opinion that variables/example names are clearer than "real" values, because it stands out from cases where we want them to run a command as-is and also helps users understand how things connect
Definitely debatable and we should apply the same formatting to all examples when we decide, so happy to discuss
| Using the `--home` command line flag, provide the path to your data directory. | ||
|
|
||
| Once you have entered your parameters, your command should resemble the following: |
There was a problem hiding this comment.
this example doesn't seem necessary
| Run your command to start the full node. | ||
|
|
||
| 2. Monitor your full node's progress by tailing the log (optional). |
There was a problem hiding this comment.
we should skip instructions like > /tmp/fullnode.log 2>&1 & and tailing your logs.
i think users should be able to choose and we should be less opinionated about this
|
|
||
| # Example values | ||
| FULL_NODE_IP_ADDRESS=192.168.0.150 |
There was a problem hiding this comment.
gotcha, i think we should skip
| 3. Confirm that your full node has finished syncing by comparing its current block to the dYdX chain. The full node is caught up with the dYdX chain head when it reaches the dYdX chain's current block. | ||
|
|
||
| To determine your full node's current block, use a block explorer like this example on [mintscan.io](https://www.mintscan.io/dydx). |
There was a problem hiding this comment.
This tells you the network's latest height. Not your full node's block height.
| To determine your full node's current block, use a block explorer like this example on [mintscan.io](https://www.mintscan.io/dydx). | ||
|
|
||
| To determine the dYdX chain's current block, use the program [v4block_subscribe.py](https://github.com/chiwalfrm/dydxexamples/blob/1d46b7a75499205d9c1c1986ae4ae8f21b6c1385/v4block_subscribe.py). |
There was a problem hiding this comment.
This is how you find your full node's height. I recommend not using this script, but rather something more simple.
does this work?
curl localhost:26657/status
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
…ode.md Co-authored-by: ttl33 <19664986+ttl33@users.noreply.github.com>
|
Closing this PR, comments will be addressed in a rewrite of this page, PR #241 |
Site: https://docs.dydx.exchange/infrastructure_providers-validators/how_to_set_up_full_node
GitHub: https://github.com/dydxprotocol/v4-documentation/blob/main/pages/infrastructure_providers-validators/how_to_set_up_full_node.md
Revising this page for clarity -- since I've been here there's been some confusion from customers about this and the following topic, Running a Full Node. This rewrite:
I called out a couple places to check for accuracy in particular, but really the whole thing needs to be vetted by an engineer. If something is even a little confusing/ seems off to you, please call it out