Add config instruction for archival node

docs/develop/node/archival/hardware-archival.md

@@ -33,11 +33,14 @@ _Verify AVX support on Linux by issuing the command ```$ lscpu | grep -oh  avx``
 
 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 |
+| Cloud Provider | Machine Size    | Linux                     |
+| -------------- | --------------- | ------------------------  |
+| AWS            | c5.2xlarge      | $250 CPU + $300 storage † |
+| GCP            | c2-standard-8   | $220 CPU + $300 storage † |
+| Azure          | Standard_F8s_v2 | $180 CPU + $300 storage † |
+
+_( † ) The storage cost will grow overtime as an archival node stores more data from the growing NEAR blockchain._
+
 
 <blockquote class="info">
 <strong>Resources for Cost Estimation</strong><br><br>
@@ -53,3 +56,6 @@ All prices reflect *reserved instances* which offer deep discounts on all platfo
 - Azure — https://azure.microsoft.com/en-us/pricing/calculator
 
 </blockquote>
+
+> Got a question?
+> <a href="https://stackoverflow.com/questions/tagged/nearprotocol"> > <h8>Ask it on StackOverflow!</h8></a>

docs/develop/node/archival/run-archival-node.md

@@ -0,0 +1,64 @@
+---
+id: run-archival-node
+title: Run an Archival Node
+sidebar_label: Run an Archival Node
+description: Run an Archival Node
+---
+
+Running an archival node is the same as a [validator node](/docs/develop/node/validator/running-a-node) as both types of node use the same `nearcore` release. The key difference for running an archival node is a modification to the `config.json` by changing `archive` to `true`.
+
+The `config.json` should contain the following fields. Currently, NEAR testnet and mainnet have only 1 (indexed [0]) shard and that shard is tracked. In the future, there will be the possibility to track different or multiple shards.
+
+```
+{
+  ...
+  "archive": true,
+  "tracked_shards": [0],
+  ...
+}
+```
+
+Please make sure that the node is stopped while changing the `config.json`.
+
+Once the config has been changed, you can restart the node and the node will start syncing new archival data. In the case where you want the full archival history, you can delete the data dir and start the node from scratch syncing full history or use one of the latest backups containing the data directory snapshot which can be copied under the near home dir (default: ~/.near/data).
+
+All archival data backups can be downloaded from the public S3 bucket, which contains latest daily snapshots:
+
+| Network | URL                                                                                         |
+| ------- | ------------------------------------------------------------------------------------------- |
+| Mainnet | https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/mainnet/archive/data.tar |
+| Testnet | https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/testnet/archive/data.tar |
+
+---
+
+## Steps to Run an Archival Node
+
+Make sure [`nearup`](https://github.com/near/nearup) is installed. You can install `nearup` by following the instructions at https://github.com/near/nearup.
+
+First, retrieve a copy of the latest archival snapshot from S3:
+```bash
+  $ wget -b https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/{testnet|mainnet}/archive/data.tar
+```
+Then run:
+```bash
+  $ nearup run testnet
+```
+Wait until initialization finishes, use the following command to follow logs:
+```bash
+  $ nearup logs --follow
+```
+Then run:
+```bash
+  $ nearup stop
+```
+```bash
+  $ tar -xvf data.tar -C ~/.near/testnet/data
+```
+Finally, run the following command and the node should start syncing headers at ~97%:
+```bash
+  $ nearup run testnet
+```
+
+>Got a question?
+<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
+  <h8>Ask it on StackOverflow!</h8></a>

docs/develop/node/community/node-community-updates.md

@@ -1,41 +1,52 @@
 ---
 id: node-community-updates
-title: Node Community Updates
-sidebar_label: Node Community Updates
-description: NEAR Node and Validator Community Updates
+title: Node Community Requests and Community Updates
+sidebar_label: Node Community Requests and Updates
+description: NEAR Node and Validator Feature Request Process and Community Updates
 ---
 
-## NEAR Validator Community Channels
 
-NEAR Protocol will communicate with validators using these channels:
+<blockquote class="info">
+<strong>Did You Know?</strong><br><br>
 
-1. Releases of `nearcore` are on Github repository of [`nearcore`](https://github.com/near/nearcore/issues).
+As a node operator, you are welcome to create feature requests and submit bug reports on [Github](https://github.com/near/nearcore/issues) 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 to indicate that this issue is related to `Node Experience`.
 
-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)
+</blockquote>
 
-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).
+## Feature Request and Bug Report
 
+The NEAR team is actively solicitating feedback from the Node and Validator Community, and offers a process for the community to engage in feature / enhancement requests and to submit bug reports. Besides the existing NEAR Validator channels, the NEAR team is introducing a formal process for feature requests and bug reports.
 
-<blockquote class="info">
-<strong>Heads up</strong><br><br>
+With respect to the experience of operating a NEAR node, all bugs and feature enhancements are publicly 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).
 
-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.
+- **New feature / Enhancement request:**
+  - Please create a [`Github issue`](https://github.com/near/nearcore/issues)
+  - Tag `nodeX`
+  - The issue will be reviewed and filtered through `Incoming Requests` column in the Github project [`Node Experience`](https://github.com/orgs/near/projects/18), where they will be groomed and slated for development based on priority
 
-</blockquote>
+- **Bug report:**
+  - Please create a [`Github issue`](https://github.com/near/nearcore/issues)
+  - Tag `nodeX` and `Bug`
+  - The issue will be reviewed and filtered through `Incoming Requests` column for more immediate attention in the Github project tracker [`Node Experience`](https://github.com/orgs/near/projects/18)
+
+
+---
 
+## NEAR Node 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. 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).
 
-**Runtime Alerts:**
+3. Discussions on upcoming changes and early ideation are on [gov.near.org](https://gov.near.org/c/staking-delegation/5).
+
+---
+
+## 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.
 
@@ -49,3 +60,7 @@ The tags we propose are as follows:
 
 
 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.
+
+>Got a question?
+<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
+  <h8>Ask it on StackOverflow!</h8></a>

docs/develop/node/intro/keys.md

@@ -7,17 +7,17 @@ description: NEAR Node Key Management
 
 ## What are Keys?
 
-In public key cryptography, there is a key pair, one public and one private, to sign and send verifiable transactions across the network. NEAR takes the common approach of using public keys for identity and private keys for signatures. Internally the NEAR platform uses ed25519, one of several "elliptic curves" that produce secure cryptographic results quicky. Specifically, we use `tweetnacl` in JavaScript and `libsodium` in Rust.
+In public key cryptography, there exists a key pair, one public and one private, to sign and send verifiable transactions across the network. NEAR takes the common approach of using public keys for identity and private keys for signatures. Internally the NEAR platform uses ed25519, one of several "elliptic curves" that produce secure cryptographic results quickly. Specifically, we use `tweetnacl` in JavaScript and `libsodium` in Rust.
 
 ## Are there Different Types of Keys?
 
-There are 3 types of key pairs on the NEAR platform
+There are 3 types of key pairs on the NEAR platform:
 
-- Signer Keys (aka. account keys, access keys, etc)
+- Signer Keys (e.g. account keys, access keys)
 - Validator Keys
 - Node Keys
 
-**Signer Keys** are the ones we all know and love. They're used by all accounts on the network to sign transactions like `sendMoney` and `stake` before sending them to the network. Signer keys are not related to running a node in any way. End users who sign up through the [NEAR Wallet](https://wallet.betanet.near.org/) get their own signer keys, for example. These are the keys that humans think about and keep safe.
+**Signer Keys** are the ones we all know and love. They're used by accounts on the network to sign transactions like `sendMoney` and `stake` before sending these transactions to the network. Signer keys are not related to running a node in any way. End users who sign up through the [NEAR Wallet](https://wallet.near.org/) get their own signer keys, for example. These are the keys that humans think about and keep safe.
 
 There are two flavors of signer keys currently available, `FullAccess` keys and `FunctionCall` keys. The first has unrestricted control to "act on behalf of an account" (as used by NEAR CLI and NEAR Wallet to get things done for you). The second is limited to contract storage and compute. Both flavors of keys can be revoked by the account holder. There is no limit to the flavors of keys that the NEAR platform can handle so we can easily imagine keys for voting, shopping, conducting official business, etc. each with their own access controls on our data, programmable time limits, etc. But keep in mind that you do have to pay rent on keys issued to your account.
 
@@ -47,19 +47,19 @@ When a validator is elected during an epoch, they have the opportunity to stake
 </blockquote>
 
 <blockquote class="warning">
-<strong>heads up</strong><br><br>
+<strong>Heads up</strong><br><br>
 
 If validator keys are changed _during an epoch in which the validator is staking_, the validator's output will be rejected since their signature will not match (new keys). This means the validator will, by the end of the epoch, not be able to meet the minimum validator output threshold and lose their position as a recognized validator. Their stake will be returned to them.
 
 </blockquote>
 
 For concrete examples of keys being used as identifiers, you can see a list of validators and active nodes on various NEAR networks here:
 
-- NEAR TestNet (staking currently disabled)
+- NEAR testnet (staking currently disabled)
   - https://rpc.testnet.near.org/status
   - https://rpc.testnet.near.org/network_info
 
-- NEAR BetaNet
+- NEAR betanet
   - https://rpc.betanet.near.org/status
   - https://rpc.betanet.near.org/network_info
 

docs/develop/node/intro/types-of-node.md

@@ -7,11 +7,15 @@ 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"
+### 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. You can see a real-time view of NEAR network validator nodes on the [NEAR Explorer](https://explorer.near.org/nodes/validators).
 
-## 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.
+### RPC Node
+RPC nodes are RPC service providers 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 [an Open Source & Public Goods grant from the NEAR Foundation](https://near.org/grants/). For more information, please check out Community section in the documentation and reach out in the Validator Channels on [Discord](https://discord.gg/ZMPr3VB) and on [Telegram](https://t.me/near_validators).
 
-## 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.
+### Archival Node
+Archival nodes store full blockchain data, and build an archive of historical states. These nodes are useful for block explorers, chain analysis, and infrastructure providers.
+
+>Got a question?
+<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
+  <h8>Ask it on StackOverflow!</h8></a>

docs/develop/node/intro/what-is-a-node.md

@@ -7,17 +7,19 @@ 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.
+It is important to keep in mind all nodes run the same codebase, with different configurations. As such, we have split up the documentation for running different types of node into sections specific to the type of nodes.
 
 ## 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` (†)
-- 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
+- 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 run applications that heavily depend on RPC performance and/or availability.
+- 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, block explorer, etc.
 
-_( † ) `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`)._
 
-_( †† ) `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`)._
+>Got a question?
+<a href="https://stackoverflow.com/questions/tagged/nearprotocol">
+  <h8>Ask it on StackOverflow!</h8></a>