Consolidate node documentation #739
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| --- | ||
| id: hardware-archival | ||
| title: Hardware Requirements for Archival Node | ||
| sidebar_label: Hardware Requirements | ||
| description: NEAR Archival Node Hardware Requirements | ||
| --- | ||
|
|
||
| This page covers the minimum and recommended hardware requirements for engaging with the NEAR platform as an Archival node. | ||
|
|
||
|
|
||
| ## Recommended Hardware Specifications | ||
|
|
||
| | Hardware | Recommended Specifications | | ||
| | -------------- | ----------------------------------------------------------------------- | | ||
| | CPU | 4-Core (8-Thread) Intel i7/Xeon or equivalent with AVX support | | ||
| | RAM | 16GB DDR4 | | ||
| | Storage | 2 Terabyte SSD | | ||
|
|
||
| _Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh avx```. If the output is empty, your CPU is not supported._ | ||
|
|
||
|
|
||
| ## Minimal Hardware Specifications | ||
|
|
||
| | Hardware | Minimal Specifications | | ||
| | -------------- | -------------------------------------------------------------------------- | | ||
| | CPU | 4-Core (8-Thread) Intel i7/Xeon or equivalent with AVX support | | ||
| | RAM | 8GB DDR4 | | ||
| | Storage | 1.5 Terabyte SSD | | ||
|
|
||
| _Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh avx```. If the output is empty, your CPU is not supported._ | ||
|
|
||
| ## Cost Estimation | ||
|
|
||
| Estimated monthly costs depending on operating system: | ||
|
|
||
| | Cloud Provider | Machine Size | Linux | | ||
| | -------------- | --------------- | ---------------------- | | ||
| | AWS | c5.2xlarge | $150 CPU + $20 storage | | ||
| | GCP | c2-standard-8 | $250 CPU + $20 storage | | ||
| | Azure | Standard_F8s_v2 | $180 CPU + $10 storage | | ||
|
|
||
| <blockquote class="info"> | ||
| <strong>Resources for Cost Estimation</strong><br><br> | ||
|
|
||
| All prices reflect *reserved instances* which offer deep discounts on all platforms with a 1 year commitment | ||
|
|
||
| - AWS | ||
| - cpu: https://aws.amazon.com/ec2/pricing/reserved-instances/pricing | ||
| - storage: https://aws.amazon.com/ebs/pricing | ||
| - GCP | ||
| - cpu: https://cloud.google.com/compute/vm-instance-pricing | ||
| - storage: https://cloud.google.com/compute/disks-image-pricing | ||
| - Azure — https://azure.microsoft.com/en-us/pricing/calculator | ||
|
|
||
| </blockquote> |
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,51 @@ | ||
| --- | ||
| id: node-community-updates | ||
| title: Node Community Updates | ||
| sidebar_label: Node Community Updates | ||
| description: NEAR Node and Validator Community Updates | ||
| --- | ||
|
|
||
| ## NEAR Validator Community Channels | ||
|
|
||
| NEAR Protocol will communicate with validators using these channels: | ||
|
|
||
| 1. Releases of `nearcore` are on Github repository of [`nearcore`](https://github.com/near/nearcore/issues). | ||
|
|
||
| 2. Bugs and feature enhancements are tracked in the Github project tracker [`Node Experience`](https://github.com/orgs/near/projects/18). Node operators are welcome to create new issues for features and bugs, and to add these issues into the [Github project tracker](https://github.com/orgs/near/projects/18). | ||
| - **New feature / Enhancement requests:** | ||
| - Please create a [`Github issue`](https://github.com/near/nearcore/issues) | ||
| - Tag `nodeX` | ||
| - Filter them through `Incoming Requests` column in the Github project tracker [`Node Experience`](https://github.com/orgs/near/projects/18), where they will be groomed and moved into `Backlog` based on priority | ||
| - **Bug reports:** | ||
| - Please create a [`Github issue`](https://github.com/near/nearcore/issues) | ||
| - Tag `nodeX` and `Bug` | ||
| - Put it at the top of the `Incoming Requests` column for more immediate attention in the Github project tracker [`Node Experience`](https://github.com/orgs/near/projects/18) | ||
|
|
||
| 3. Technical support and troubleshooting by the NEAR team are available in the Validator Channels on [Discord](https://discord.gg/ZMPr3VB) and on [Telegram](https://t.me/near_validators). | ||
|
|
||
| 4. Discussions on upcoming changes and early ideation are on [gov.near.org](https://gov.near.org/c/staking-delegation/5). | ||
|
|
||
|
|
||
| <blockquote class="info"> | ||
| <strong>Heads up</strong><br><br> | ||
|
|
||
| As a node operator, you are welcome to create bugs and feature requests on Github to improve the experience of running a node. Head to [`nearcore`](https://github.com/near/nearcore/issues) repository on Github to open an issue, and don't forget to tag the issue with the `nodeX` tag. | ||
|
|
||
| </blockquote> | ||
|
|
||
|
|
||
|
|
||
| **Runtime Alerts:** | ||
|
|
||
| To keep our network healthy and minimize the damage of potential incidents, the NEAR team would like to establish a process with which we communicate updates and emergency situations with validators so that they can respond promptly to properly sustain the operations of the network. To this end, we propose that we use different tags in important messages to validators so that they can be easily picked up by automated systems on validators’ end. | ||
|
|
||
| The tags we propose are as follows: | ||
|
|
||
| `[CODE_RED_<network_id>]` where `<network_id>` is either `MAINNET` or `TESTNET`. This represents the most dire and urgent situation. Usually it means that the network has stalled or crashed and we need validators to take **immediate** actions to bring the network up. Alternatively it could mean that we discovered some highly critical security vulnerabilities and a patch is needed as soon as possible. If it is about mainnet, we expect that validators will react immediately to such alerts, ideally within 30 minutes. | ||
|
|
||
| `[CODE_YELLOW_<network_id>]` where `<network_id>` is either `MAINNET` or `TESTNET`. This represents a less urgent announcement. Usually it means the release of a protocol change or a fix of a moderate security issue. In such cases, validators are not expected to take immediate actions but are still expected to react within days. | ||
|
|
||
| `[CODE_GREEN_<network_id>]` where `<network_id>` is either `MAINNET` or `TESTNET`. This usually means some general announcement that is more informational or doesn’t require actions within a short period of time. It could be an announcement of a release that improves performance or a fix some minor issues. | ||
|
|
||
|
|
||
| Call-to-actions for technical teams if the network is stalling and there's the need to coordinate a manual node restart. Such messages begin with `[CODE_RED_BETANET]` or `[CODE_RED_TESTNET]`, and will be posted in the read-only Validator Announcement channel on [Discord](https://discord.gg/xsrHaCb). The same message may be repeated in other channels, to have higher outreach. | ||
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| --- | ||
| id: types-of-node | ||
| title: Types of Node | ||
| sidebar_label: Types of Node | ||
| description: Types of NEAR Node | ||
| --- | ||
|
|
||
| You can run three different types of node - Validator Node, RPC Node, and Archival Node. | ||
|
|
||
| ## Validator Node | ||
| Validator Nodes are the operators of the NEAR blockchain and are essential to the health of the network. Validator nodes participate in the consensus and produce blocks and/or chunks" | ||
|
|
||
| ## RPC Node | ||
| RPC Nodes are RPC service providers for that provide public RPC endpoints for developers to use. The NEAR Foundation currently maintains a public RPC endpoint `http://rpc.mainnet.near.org/` that is free for everyone to use. However, any participants are encouraged to run their own RPC node and offer RPC services through a grant from the NEAR Foundation. For more information, please reach out in Validator channels on Telegram or Discord. | ||
|
|
||
| ## Archival Node | ||
| Archival Nodes store full blockchain data, and build an archive of historical states. These nodes are useful for block explorers, chain analytics, and infrastructure providers. |
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,23 @@ | ||
| --- | ||
| id: what-is-a-node | ||
| title: What is a Node | ||
| sidebar_label: What is a Node | ||
| description: What is a NEAR Node and Why Run a Node | ||
| --- | ||
|
|
||
| NEAR Protocol runs on a collection of publicly maintained computers (or "nodes"). All nodes are running the same `nearcore` codebase with the latest releases available on [Github](https://github.com/near/nearcore/releases/). In the following section, we will introduce three types of nodes. | ||
|
|
||
| It is important to keep in mind all nodes runs the same codebase, but with different configurations. As such we have split up the instructions for running different nodes into different sections. | ||
|
|
||
| ## Why run a Node? | ||
|
|
||
| You may decide to run a node of your own for a few reasons: | ||
|
|
||
| - To join a network as a validator running a "validator node". Running a validator node is a public good and you are effectively securing the NEAR network and earning rewards. | ||
| - To develop and deploy contracts on a node connected to `MainNet`, `TestNet` or `BetaNet` (†) | ||
|
Contributor
There was a problem hiding this comment. I don't see it to be a good reason to run your own node. I think it is better to say something along these lines:
Contributor
Author
There was a problem hiding this comment.
Yes! Validator node cost estimate: https://docs.near.org/docs/develop/node/validator/hardware Thanks! |
||
| - To develop and deploy contracts on a local (independent and isolated) node (sometimes called "LocalNet"). (††) | ||
| - To quickly extract blockchain data that can be used for chain analytics | ||
|
|
||
| _( † ) `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 (ie. making changes to `nearcore`)._ | ||
|
Contributor
There was a problem hiding this comment. I believe we stick to lowercase naming (
Contributor
Author
There was a problem hiding this comment.
Yes, I was thinking of the same naming convention while reading the docs. Sometimes they are TitleCase, sometimes camelCase, and sometimes lowercase. In code, they seem to be consistently lowercase. I will convert all to lowercase for consistency. |
||
Oops, something went wrong.
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.
non-NEAR members cannot label issues or move issues on those boards. We need to create GitHub templates with the pre-set labels to let people create the issues with the specific labels.