revised running a node #476
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| --- | ||
| id: nodes | ||
| title: Nodes | ||
| sidebar_label: Nodes | ||
| --- | ||
|
|
||
| ## What is a node? | ||
|
|
||
| NEAR Protocol runs on a collection of publicly maintained computers or "nodes". All nodes on a network perform and validate transactions, but differ in their ability to produce blocks. | ||
|
|
||
| ## Node types | ||
|
|
||
| For simplicities sake, NEAR has two main types of nodes: | ||
| - Producing nodes (aka "validator nodes") | ||
| - Non-producing nodes (aka "regular nodes") | ||
|
|
||
| ### Non-producing node ("regular node") | ||
|
|
||
| Anyone can run a "regular node" by following one of the methods mentioned in [this guide](/docs/local-setup/running-a-node). | ||
|
|
||
| You may decide to run a node of your own for a few reasons: | ||
|
|
||
| - To view, process, and validate transactions on `MainNet`, `TestNet` or `BetaNet` (†) | ||
| - To view, process, and validate transactions on an independent / isolated local NEAR network (sometimes called "LocalNet"). (††) | ||
| - To join `BetaNet` or `MainNet` as a producing node, aka "Validator Node" (see "[Running a Validator Node](/docs/validator/staking)") | ||
|
|
||
| _( † ) `TestNet` is intended to operate as similarly to `MainNet` as possible with only stable releases, while `BetaNet` follows a weekly release cycle._ | ||
|
|
||
| _( †† ) `LocalNet` would be the right choice if you prefer to avoid leaking information about your work during the development process since `TestNet` and `BetaNet` are *public* networks. `LocalNet` also gives you total control over accounts, economics, and other factors for more advanced use cases (i.e. making changes to `nearcore`)._ | ||
|
|
||
|
|
||
| ### Producing node ("validator node") | ||
|
Contributor
There was a problem hiding this comment. Why? Producing node makes no sense
Collaborator
Author
There was a problem hiding this comment. This was discussed in a thread on slack. @SkidanovAlex was concerned that calling a node "block producing" would be incorrect in the future when chunk producing begins. Do you have a suggestion?
Contributor
There was a problem hiding this comment. No but let's not call them "producing node". For now block producing node is fine |
||
|
|
||
| Producing nodes, also referred to as "[Validator Nodes](/docs/validator/staking-overview)" contribute to the network by producing blocks or chunks. | ||
|
|
||
| To run a producing node, you must have a validator key and be included among the set of block producers. After each [epoch](/docs/concepts/epoch), "validator nodes" are shuffled and randomly selected for the next epoch. | ||
|
|
||
| See "[How do I become a validator](/docs/validator/validator-faq#how-do-i-become-a-validator)" and [validator selection process](https://nomicon.io/Economics/README.html?validator-selection#validator-selection) for more information. | ||
|
|
||
| <blockquote class="warning"> | ||
| <strong>Note</strong><br><br> | ||
|
|
||
| Non-producing nodes still validate every block and are very important to the network. This network of nodes, that view all transactions taking place, help us to be certain that the chain is correct and no invalid state transitions / forks are occurring. | ||
|
|
||
| </blockquote> | ||
|
|
||
| ### Archival vs. Non-archival nodes | ||
|
|
||
| Both producing ("validator") and non-producing ("regular") nodes can be configured to be either archival or non-archival. All nodes are non-archival by default, but you can easily set your node to archival by updating your `config.json` changing `archive` to `true`. | ||
|
|
||
| Its important to note that: | ||
|
|
||
| - Archival nodes store <strong>all</strong> data, from genesis to present. Anytime a new archival node is created, it begins by first syncing all data from genesis to current, then begins to record all future transactions. | ||
|
|
||
| - Non-archival nodes will do a state sync to a recent point, and will only validate from that point forward. They will continue to maintain a recent set of blocks locally, discarding older ones as the chain grows in height. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,68 +1,64 @@ | ||
| --- | ||
| id: running-a-node | ||
| title: Running a node | ||
| sidebar_label: Running a node | ||
| --- | ||
|
|
||
| ## Running a node using `nearcore` | ||
|
|
||
| 1) If you haven't already, you will need to clone [`nearcore`](https://github.com/nearprotocol/nearcore) as well as compile and run the `neard` package using Rust. Please reference [this guide](https://docs.near.org/docs/contribution/nearcore#docsNav) for assistance. | ||
|
|
||
| 2) Download the genesis file: | ||
| - TestNet [`genesis.json`](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/testnet/genesis.json) | ||
| - BetaNet [`genesis.json`](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/betanet/genesis.json) | ||
| - MainNet does not require you to download the `genesis.json` file as it is embedded into `nearcore` | ||
|
|
||
| 3) Download the config file: | ||
| - TestNet [`config.json`](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/testnet/config.json) | ||
| - BetaNet [`config.json`](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/betanet/config.json) | ||
| - MainNet [`config.json`](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/config.json) | ||
|
|
||
| 4) Run the following command replacing the paths & networkId: | ||
| ```bash | ||
| neard --home=<absolute_path_to_the_desired_location> init --chain-id=<networkId> --genesis=<absolute_path_to_the_downloaded_genesis_file> | ||
|
Contributor
There was a problem hiding this comment.
Collaborator
Author
There was a problem hiding this comment. This PR was to add running a node without using |
||
| ``` | ||
| example: | ||
| ```bash | ||
| neard --home=/HOME/USER/near/my-near-node init --chain-id=testnet --genesis=/HOME/USER/near/genesis.json | ||
| ``` | ||
|
|
||
| 5) Either copy the downloaded `config.js` file to the home location chosen above, or only copy paste the `boot_nodes` from the downloaded `config.js` file to the one created by the `neard init`. | ||
|
|
||
| 6) Run: | ||
| ```bash | ||
| neard --home=<same_path_as_above> run | ||
| ``` | ||
|
|
||
| ## Running a node using `nearup` and Docker | ||
| **Note**: The following guides are only for `betanet` and `testnet`. | ||
|
|
||
| ### Install `nearup` | ||
| You can install `nearup` by following the instructions at https://github.com/near/nearup. | ||
|
|
||
| ### Install Docker | ||
|
|
||
| By default, we use Docker to run the client. Follow these instructions to install Docker on your machine: | ||
|
|
||
| * [MacOS Docker Install](https://docs.docker.com/docker-for-mac/install/) | ||
| * [Ubuntu Docker Install](https://docs.docker.com/install/linux/docker-ce/ubuntu/) | ||
|
|
||
| **Note**: You can run a node without Docker by adding the `--nodocker` flag to the `nearup` command and specifying the compiled binary path. See how to do this in the next section: [Compiling and Running an Official Node without Docker](/docs/local-setup/running-a-node#compiling-and-running-official-node-without-docker). | ||
|
|
||
| ### Running `nearup` | ||
|
|
||
|
|
||
| Once `nearup` and Docker are installed, run either `nearup testnet` or `nearup betanet` in your terminal, depending on your preferred network. | ||
|
|
||
|
|
||
| You will then be prompted for an Account ID. You can leave this empty if you would just like to run a regular node. Validators should use the account ID of the account you want to stake with. See [staking](/docs/validator/staking) if you would like to become a validator. | ||
|
|
||
| ```text | ||
| Enter your account ID: (leave empty if not going to be a validator) | ||
|
Contributor
There was a problem hiding this comment. this doesn't exists any more, you have to pass the flag --account-id |
||
| ``` | ||
|
|
||
| A node will then start in the background with Docker. | ||
|
|
@@ -79,8 +75,7 @@ To check the logs inside Docker, run `docker logs --follow nearcore`. | |
| | `0/0/40` | connected peers / up to date peers / max peers | | ||
|
|
||
|
|
||
| ## Compiling and running a node without Docker | ||
|
|
||
| Alternatively, you can build and run a node without Docker by compiling `nearcore` locally and pointing `nearup` to the compiled binaries. Steps in this section provide details of how to do this. | ||
|
|
||
|
|
@@ -125,13 +120,13 @@ If you are running a validator in production you may find it more efficient to j | |
| cargo build -p neard --release | ||
| ``` | ||
|
|
||
| **Note**: Please ensure you include the `--release` flag. Omitting this will lead to an unoptimized binary being produced that is too slow for a validator to function effectively. | ||
|
|
||
| Finally: | ||
| On MacOS or Linux | ||
|
|
||
| ```bash | ||
| nearup betanet --nodocker --binary-path <path_to_nearcore_target_release> | ||
|
Contributor
There was a problem hiding this comment. this is outdated. The new version of nearup doesn't have an option to run docker inside. You can run the entire nearup from docker. https://github.com/near/nearup/tree/nearup_v2
Collaborator
Author
There was a problem hiding this comment. Same as above... existing instructions on |
||
| ``` | ||
|
|
||
| If you want to run `TestNet` instead of `BetaNet` then replace `betanet` with `testnet` in the command above. | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think some reasons for running a regular node include: