From ccc4ac4420dbc8c73f85b17dc3f9f64ef7746b30 Mon Sep 17 00:00:00 2001 From: Jane Wang Date: Mon, 21 Jun 2021 11:22:10 -0400 Subject: [PATCH 1/3] Add instruction for setting archival node without nearup --- ...de.md => run-archival-node-with-nearup.md} | 53 ++-- .../run-archival-node-without-nearup.md | 277 ++++++++++++++++++ website/sidebars.json | 3 +- 3 files changed, 312 insertions(+), 21 deletions(-) rename docs/develop/node/archival/{run-archival-node.md => run-archival-node-with-nearup.md} (60%) create mode 100644 docs/develop/node/archival/run-archival-node-without-nearup.md diff --git a/docs/develop/node/archival/run-archival-node.md b/docs/develop/node/archival/run-archival-node-with-nearup.md similarity index 60% rename from docs/develop/node/archival/run-archival-node.md rename to docs/develop/node/archival/run-archival-node-with-nearup.md index c04f3fd2492..bd91d712d08 100644 --- a/docs/develop/node/archival/run-archival-node.md +++ b/docs/develop/node/archival/run-archival-node-with-nearup.md @@ -1,11 +1,39 @@ --- -id: run-archival-node -title: Run an Archival Node -sidebar_label: Run an Archival Node -description: Run an Archival Node +id: run-archival-node-with-nearup +title: Run an Archival Node with nearup +sidebar_label: Run a Node with nearup +description: How to run an Archival Node with nearup --- -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`. + +
+Heads up

+ +Running an archival node is very similar to running a [validator node](/docs/develop/node/validator/running-a-node) as both types of node use the same `nearcore` release. The main difference for running an archival node is a modification to the `config.json` by changing `archive` to `true`. See below for more details. + +
+ + +## Prerequisites + +- [Git](https://git-scm.com/) +- [Nearup](https://github.com/near/nearup): Make sure [`nearup`](https://github.com/near/nearup) is installed. You can install `nearup` by following the instructions at https://github.com/near/nearup. + +--- + +### Steps to Run an Archival Node using `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 +``` + + +### Configuration Update + +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 main 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. @@ -22,23 +50,8 @@ 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 diff --git a/docs/develop/node/archival/run-archival-node-without-nearup.md b/docs/develop/node/archival/run-archival-node-without-nearup.md new file mode 100644 index 00000000000..9ee3e091883 --- /dev/null +++ b/docs/develop/node/archival/run-archival-node-without-nearup.md @@ -0,0 +1,277 @@ +--- +id: run-archival-node-without-nearup +title: Run an Archival Node without nearup +sidebar_label: Run a Node without nearup +description: How to run an Archival Node without nearup +--- + +
+Heads up

+ +Running an archival node is very similar to running a [validator node](/docs/develop/node/validator/running-a-node) as both types of node use the same `nearcore` release. The main difference for running an archival node is a modification to the `config.json` by changing `archive` to `true`. See below for more details. + +
+ + +## Prerequisites + +- [Rust](https://www.rust-lang.org/). If not already installed, please [follow these instructions](https://docs.near.org/docs/tutorials/contracts/intro-to-rust#3-step-rust-installation). +- [Git](https://git-scm.com/) +- Installed developer tools: + - MacOS + ```bash + $ brew install cmake protobuf clang llvm + ``` + - Linux + ```bash + $ apt update + $ apt install -y git binutils-dev libcurl4-openssl-dev zlib1g-dev libdw-dev libiberty-dev cmake gcc g++ python docker.io protobuf-compiler libssl-dev pkg-config clang llvm + ``` +--- + +### Choosing your `nearcore` version + +When building your NEAR node you will have two branch options to choose from depending on your desired use: + +- `master` : _(**Experimental**)_ + - Use this if you want to play around with the latest code and experiment. This branch is not guaranteed to be in a fully working state and there is absolutely no guarantee it will be compatible with the current state of *mainnet* or *testnet*. +- [`Latest release branch`](https://github.com/near/nearcore/releases) : _(**Stable**)_ + - Use this if you want to run a NEAR node for *mainnet* or *tesnet*. This version is used by validators and other nodes and is fully compatible with the current state of *mainnet* or *testnet*. + + +## `testnet` + +### 1. Clone `nearcore` project from GitHub + +First, clone the [`nearcore` repository](https://github.com/near/nearcore). + +```bash +$ git clone https://github.com/near/nearcore +$ git fetch origin --tags +$ cd nearcore +``` + +Checkout to the branch you need if not `master` (default). Latest release is recommended. Please check the [releases page on GitHub](https://github.com/near/nearcore/releases). + +```bash +$ git checkout tags/1.19.0 -b mynode +``` + +### 2. Compile `nearcore` binary + +In the `nearcore` folder run the following commands: + +```bash +$ cargo build --release --package neard --bin neard +``` + +This will start the compilation process. It will take some time depending on your machine power _(e.g. i9 8-core CPU, 32 GB RAM, SSD takes approximately 25 minutes)_ + +The binary path is `nearcore/target/release/neard` + +### 3. Initialize working directory + +In order to work properly, the NEAR node requires a working directory and a couple of configuration files. + +- `config.json` - Configuration parameters which are responsive for how the node will work. +- `genesis.json` - A file with all the data the network started with at genesis. This contains initial accounts, contracts, access keys, and other records which represents the initial state of the blockchain. +- `node_key.json` - A file which contains a public and private key for the node. Also includes an optional `account_id` parameter which is required to run a validator node (not covered in this doc). +- `data/` - A folder in which a NEAR node will write it's state. + +Generate the initial required working directory by running: + +```bash +$ ./target/release/neard --home ~/.near init --chain-id testnet --download +``` + +> You can skip the `--home` argument if you are fine with the default working directory in `~/.near`. If not, pass your preferred location. + +This command will create the required directory structure and will generate `config.json`, `node_key.json`, and `genesis.json` for `testnet` network. + +> **Heads up** +> The genesis file for `testnet` is big (6GB +) so this command will be running for a while and no progress will be shown. + + +### 4. Replacing the `config.json` + +The generated `config.json` will be missing a `boot_nodes` parameter (it is empty) so we will need to replace it with a full one. You can do this one of two ways: + +1. Download `config.json` [here](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/testnet/config.json) and replace it in your working dir (`~/.near/config.json`). + +or + +2. Run the following commands: + +```bash +$ rm ~/.near/config.json +$ wget ~/.near/config.json https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/testnet/config.json +``` + +### Configuration Update + +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 not running 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). + + +### 5. Get data backup + +The node is ready to be started however you must first sync up with the network. This means your node needs to download all the headers and blocks that other nodes in the network already have. You can speed up this process by downloading backups in one of two ways by downloading the latest archival data backup from a public S3 bucket. + +| Network | URL | +| ------- | ------------------------------------------------------------------------------------------- | +| testnet | https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/testnet/archive/data.tar | + + +1. Download and unpack the [tar file](https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/testnet/rpc/data.tar) to `~/.near`. + +or + +2. Run the following commands: + +```bash +$ wget ~/.near/data.tar https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/testnet/rpc/data.tar +$ tar -xf ~/.near/data.tar +$ rm ~/.near/data.tar +``` + +### 6. Run the node +To start your node simply run the following command: + +```bash +$ ./target/release/neard --home ~/.near run +``` + +That's all. The node is running you can see log outputs in your console. It will download a bit of missing data since the last backup was performed but it shouldn't take much time. + + +## `mainnet` + +### 1. Clone `nearcore` project from GitHub + +First, clone the [`nearcore` repository](https://github.com/near/nearcore). + +```bash +$ git clone https://github.com/near/nearcore +$ git fetch origin --tags +$ cd nearcore +``` + +Next, checkout the release branch you need (recommended) if you will not be using the default `master` branch. Please check the [releases page on GitHub](https://github.com/near/nearcore/releases) for the latest release. + +For more information on choosing between `master` and latest release branch [ [click here](/docs/develop/node/validator/compile-and-run-a-node#choosing-your-nearcore-version) ]. + +```bash +$ git checkout tags/1.19.0 -b mynode +``` + +### 2. Compile `nearcore` binary + +In the `nearcore` folder run the following commands: + +```bash +$ cargo build --release --package neard --bin neard +``` + +This will start the compilation process and will take some time depending on your machine's CPU power. _(e.g. i9 8-core CPU, 32 GB RAM, SSD takes approximately 25 minutes)_ + +The binary path is `nearcore/target/release/neard` + +### 3. Initialize working directory + +In order to work NEAR node requires to have working directory and a couple of configuration files. + +- `config.json` - Configuration parameters which are responsive for how the node will work. +- `genesis.json` - A file with all the data the network started with at genesis. This contains initial accounts, contracts, access keys, and other records which represents the initial state of the blockchain. +- `node_key.json` - A file which contains a public and private key for the node. Also includes an optional `account_id` parameter which is required to run a validator node (not covered in this doc). +- `data/` - A folder in which a NEAR node will write it's state. + +Generate the initial required working directory by running: + +```bash +$ ./target/release/neard --home ~/.near init --chain-id mainnet --download +``` + +> You can skip the `--home` argument if you are fine with the default working directory in `~/.near`. If not, pass your preferred location. + +This command will create the required directory structure by generating a `config.json`, `node_key.json`, and downloads a `genesis.json` for `mainnet`. + + +### 4. Replacing the `config.json` + +The generated `config.json` will be missing a `boot_nodes` parameter (it is empty) so we will need to replace it with a full one. You can do this one of two ways: + +1. Download `config.json` [here](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/config.json) and replace it in your working dir (`~/.near/config.json`). + +or + +2. Run the following commands: + +```bash +$ rm ~/.near/config.json +$ wget ~/.near/config.json https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/config.json +``` + +### Configuration Update + +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 not running 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). + + +### 5. Get data backup + +The node is ready to be started however you must first sync up with the network. This means your node needs to download all the headers and blocks that other nodes in the network already have. You can speed up this process by downloading backups in one of two ways by downloading the latest archival data backup from a public S3 bucket. + +| Network | URL | +| ------- | ------------------------------------------------------------------------------------------- | +| mainnet | https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/mainnet/archive/data.tar | + + +1. Download and unpack the [tar file](https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/mainnet/rpc/data.tar) to `~/.near`. + +or + +2. Run the following commands: + +```bash +$ wget ~/.near/data.tar https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/mainnet/rpc/data.tar +$ tar -xf ~/.near/data.tar +$ rm ~/.near/data.tar +``` + +### 6. Run the node +To start your node simply run the following command: + +```bash +$ ./target/release/neard --home ~/.near run +``` + +That's all. The node is running and you can see log outputs in your console. It will download a bit of missing data since the last backup was performed but it shouldn't take much time. + + +>Got a question? + + Ask it on StackOverflow! diff --git a/website/sidebars.json b/website/sidebars.json index b99fc618c51..cfcd2937fff 100644 --- a/website/sidebars.json +++ b/website/sidebars.json @@ -89,7 +89,8 @@ "label": "Run an Archival Node", "ids": [ "develop/node/archival/hardware-archival", - "develop/node/archival/run-archival-node" + "develop/node/archival/run-archival-node-with-nearup", + "develop/node/archival/run-archival-node-without-nearup" ] }, { From 294c162d4e0f6791ed221d1b73ae0cd4950a2907 Mon Sep 17 00:00:00 2001 From: Jane Wang Date: Mon, 21 Jun 2021 11:36:10 -0400 Subject: [PATCH 2/3] Fix broken link --- docs/roles/integrator/exchange-integration.md | 32 +++++++++---------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/roles/integrator/exchange-integration.md b/docs/roles/integrator/exchange-integration.md index 0c95240f775..491b1b2a16d 100644 --- a/docs/roles/integrator/exchange-integration.md +++ b/docs/roles/integrator/exchange-integration.md @@ -916,7 +916,7 @@ Returns: ### Get info about the FT You can get `name`, `decimals`, `icon` and other parameters by calling the next function: - - using NEAR CLI: + - using NEAR CLI: ```bash near view ft_metadata @@ -952,7 +952,7 @@ You can get `name`, `decimals`, `icon` and other parameters by calling the next HTTP/1.1 200 OK Alt-Svc: clear Via: 1.1 google - access-control-allow-origin: + access-control-allow-origin: content-length: 604 content-type: application/json date: Wed, 02 Jun 2021 15:51:17 GMT @@ -985,7 +985,7 @@ You can get `name`, `decimals`, `icon` and other parameters by calling the next ### Simple transfer -To follow this guide, please check the [step by step instructions](/docs/tutorials/create-transactions#low-level----create-a-transaction) on how to create a transaction first. +To follow this guide, please check the [step by step instructions](/docs/tutorials/create-transactions#low-level----create-a-transaction) on how to create a transaction first. In order to send a fungible token to an account, the receiver must have a storage deposit. This is because each smart contract on NEAR must account for storage used, and each account on a fungible token contract is a key-value pair, taking up a small amount of storage. For more information, please see [how storage works in NEAR](/docs/concepts/storage-staking). To check if account has deposited the storage for this FT do the following: @@ -1021,7 +1021,7 @@ Get storage balance of the account. `storage_balance_of` function returns the am HTTP/1.1 200 OK Alt-Svc: clear Via: 1.1 google - access-control-allow-origin: + access-control-allow-origin: content-length: 173 content-type: application/json date: Wed, 02 Jun 2021 14:22:01 GMT @@ -1070,11 +1070,11 @@ Get the minimum storage required for FT. (The storage used for an account's key- HTTP/1.1 200 OK Alt-Svc: clear Via: 1.1 google - access-control-allow-origin: + access-control-allow-origin: content-length: 357 content-type: application/json date: Wed, 02 Jun 2021 15:42:49 GMT - + { "id": "storagebalancebounds", "jsonrpc": "2.0", @@ -1095,7 +1095,7 @@ Get the minimum storage required for FT. (The storage used for an account's key- "max": "1250000000000000000000" } ``` - + Basic fungible tokens are simple smart contracts that don't have variable storage as compared to a smart contract that might store free-form text, for instance. The only storage needed is for an accounts key-value pair, which will always be covered by the `1250000000000000000000` yoctoⓃ storage balance. If there is not enough deposit for the storage or returned value is `null` - you should deposit more storage with the next command: @@ -1138,7 +1138,7 @@ Transaction: { ] } ``` - + ```bash http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=broadcast_tx_commit \ params:='["DgAAAHNlcmhpaS50ZXN0bmV0AEKEp54fyVkp8dJE2l/m1ErjdhDGodBK8ZF6JLeHFMeZi/qoVEgrAAAPAAAAZnQuZGVtby50ZXN0bmV0JYbWPOu0P9T32vtUKnZSh+EaoboQqg0/De2i8Y+AjHIBAAAAAg8AAABzdG9yYWdlX2RlcG9zaXQCAAAAe30AQHoQ81oAAAAAILSd2XlDeBoAAAAAAAAAZF7+s4lcHOzy+re59VErt7LcZkPMMUVgOJV8LH5TsLBBv+8h/5tZ6+HFwxSp605A4c46oS9Jw4KBRXZD07lKCg=="]' @@ -1592,7 +1592,7 @@ You can get the same info later by the transaction hash from the previous call: - using NEAR Explorer: https://explorer.near.org - @@ -1633,7 +1633,7 @@ Transaction: { ] } ``` - + ```bash http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=broadcast_tx_commit \ params:='["DgAAAHNlcmhpaS50ZXN0bmV0AEKEp54fyVkp8dJE2l/m1ErjdhDGodBK8ZF6JLeHFMeZofqoVEgrAAAgAAAAZGV2LTE2MjMzMzM3OTU2MjMtMjEzOTk5NTk3NzgxNTm8Xq8BTIi6utG0424Gg7CknYzLH8RH/A409jq5o0zi7gEAAAACCwAAAGZ0X3RyYW5zZmVyPwAAAHsicmVjZWl2ZXJfaWQiOiJkZXYtMTYyMzMzMzkxNjM2OC01ODcwNzQzNDg3ODUzMyIsImFtb3VudCI6IjEifQBAehDzWgAAAQAAAAAAAAAAAAAAAAAAAABCwjqayKdpWgM6PE0ixzm/Gy0EtdpxVn0xehMTBReVfVAKIBTDPoPSaOdT8fAhk343F5uOMfSijhTqU2mWV3oD"]' @@ -2267,13 +2267,13 @@ Now, let's try to follow the steps described in the previous section and determi ```json {"receiver_id":"dev-1623693121955-71667632531176","amount":"10","msg":"take-my-money"} ``` - + 4. Loop through `result` » `receipts_outcome` until finding the object where `id` is equal to the value from step 2. Similar to step 1, this object will also contain a `status` field that should contain the key `SuccessReceiptId`. Again, if this isn't there no fungible tokens were transferred, otherwise get the value of the `SuccessReceiptId`. In the above example, this value is `4Tc8MsrJZSMpNZx7u4jSqxr3WhRzqxaNHxLJFqz8tUPR`. 5. Similar to the previous step, loop through the `result` » `receipts_outcome` until you find the object where the `id` matches the value from step 4. In that object check that `outcome` » `status` has the `SuccessValue` field. This `SuccessValue` represents how many fungible tokens the receiving contract is "returning" to the fungible token contract. Note that in the example above the value is `Ijki`, which is the base64-encoded version of `"9"`. At this point, we know that 10 fungible tokens were sent (from step 3) and 9 were taken. For additional clarity, let's take a look at one more optional aspect. In step 4 we isolated an obeject in `result` » `receipts_outcome`. There's an array of `receipt_ids` that's particularly interesting. The first element in the array is the receipt ID `EB69xtJiLRh9RNzAHgBGmom8551hrK2xSRreqbjvJgu5`. If we loop through the `result` » `receipts_outcome` and find this as the value for the `id` key, we'll see what happened in the function `ft_on_transfer` which takes place in the contract receiving the fungible tokens. In this object the `status` » `SuccessValue` is `IjEi` which is the base64-encoded value of `"1"`. -In summary: +In summary: 1. A user called the fungible token contract with the method `ft_transfer_call` specifying the receiver account, how many tokens to send, and custom info. 2. The receiver account implemented `ft_on_transfer`, returning `"1"` to the callback function on the fungible token contract. 3. The fungible token contract's callback is `ft_resolve_transfer` and receives this value of `"1"`. It knows that 1 token was returned, so subtracts that from the 10 it intended to send. It then returns to the user how many tokens were used in this back-and-forth series of cross-contract calls: `"9"`. @@ -2312,7 +2312,7 @@ Transaction: { http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=broadcast_tx_commit \ params:='["DgAAAHNlcmhpaS50ZXN0bmV0AEKEp54fyVkp8dJE2l/m1ErjdhDGodBK8ZF6JLeHFMeZn/qoVEgrAAAgAAAAZGV2LTE2MjMzMzM3OTU2MjMtMjEzOTk5NTk3NzgxNTnrbOQ93Wv9xxBwmq4yDYrssCpwKSI2bzjNNCCCHMZKNwEAAAACEAAAAGZ0X3RyYW5zZmVyX2NhbGxeAAAAeyJyZWNlaXZlcl9pZCI6ImRldi0xNjIzMzMzOTE2MzY4LTU4NzA3NDM0ODc4NTMzIiwiYW1vdW50IjoiMTAwMDAwMDAwMCIsIm1zZyI6InRha2UtbXktbW9uZXkifQBAehDzWgAAAQAAAAAAAAAAAAAAAAAAAABQh3k+7zG2m/Yz3O/FBrvLaBwR/5YRB5FbFnb27Nfu6BW/Wh77RFH7+ktBwGLBwFbJGxiumIcsqBiGXgg1EPMN"]' ``` - + To get details of this transaction: ```bash @@ -2322,7 +2322,7 @@ http post https://archival-rpc.testnet.near.org jsonrpc=2.0 method=EXPERIMENTAL_
**Example response**: - + ```json { "id": "myid", @@ -2521,7 +2521,7 @@ http post https://archival-rpc.testnet.near.org jsonrpc=2.0 method=EXPERIMENTAL_ Let's examine this responce. * `result` » `transaction_outcome` » `outcome` » `status` » `SuccessReceiptId` is `83AdQ16bpAC7BEUyF7zoRsAgeNW7HHmjhZLvytEsrygo` - * check `result` » `receipts_outcome` » `0` » `outcome` » `status` and find `Failure` status there + * check `result` » `receipts_outcome` » `0` » `outcome` » `status` and find `Failure` status there ## Blocks and Finality @@ -2542,7 +2542,7 @@ http post https://rpc.mainnet.near.org method=block params:='{"finality":"final" as the height of the block. ## Running an Archival Node -Please refer to configuration changes required in `config.json` for archival node by referring to the documentation on [Run an Archival Node](/docs/develop/node/archival/run-archival-node). +Please refer to configuration changes required in `config.json` for archival node by referring to the documentation on [Run an Archival Node](/docs/develop/node/archival/run-archival-node-with-nearup). ## Staking and Delegation From c8a3512a3584ef09802ed9468e5a9f5bbdcf3e0f Mon Sep 17 00:00:00 2001 From: Jane Wang Date: Tue, 22 Jun 2021 15:29:24 -0400 Subject: [PATCH 3/3] Add comment on testnet rc --- .../node/archival/run-archival-node-without-nearup.md | 6 ++++-- docs/develop/node/validator/compile-and-run-a-node.md | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/develop/node/archival/run-archival-node-without-nearup.md b/docs/develop/node/archival/run-archival-node-without-nearup.md index 9ee3e091883..26d13639763 100644 --- a/docs/develop/node/archival/run-archival-node-without-nearup.md +++ b/docs/develop/node/archival/run-archival-node-without-nearup.md @@ -35,8 +35,10 @@ When building your NEAR node you will have two branch options to choose from dep - `master` : _(**Experimental**)_ - Use this if you want to play around with the latest code and experiment. This branch is not guaranteed to be in a fully working state and there is absolutely no guarantee it will be compatible with the current state of *mainnet* or *testnet*. -- [`Latest release branch`](https://github.com/near/nearcore/releases) : _(**Stable**)_ - - Use this if you want to run a NEAR node for *mainnet* or *tesnet*. This version is used by validators and other nodes and is fully compatible with the current state of *mainnet* or *testnet*. +- [`Latest stable release`](https://github.com/near/nearcore/tags) : _(**Stable**)_ + - Use this if you want to run a NEAR node for *mainnet*. For *mainnet*, please use the latest stable release. This version is used by mainnet validators and other nodes and is fully compatible with the current state of *mainnet*. +- [`Latest release candidates`](https://github.com/near/nearcore/tags) : _(**Release Candidates**)_ + - Use this if you want to run a NEAR node for *tesnet*. For *testnet*, we first release a RC version and then later make that release stable. For testnet, please run the latest RC version. ## `testnet` diff --git a/docs/develop/node/validator/compile-and-run-a-node.md b/docs/develop/node/validator/compile-and-run-a-node.md index 66a85d9e984..0563fc50de9 100644 --- a/docs/develop/node/validator/compile-and-run-a-node.md +++ b/docs/develop/node/validator/compile-and-run-a-node.md @@ -36,8 +36,10 @@ When building your NEAR node you will have two branch options to choose from dep - `master` : _(**Experimental**)_ - Use this if you want to play around with the latest code and experiment. This branch is not guaranteed to be in a fully working state and there is absolutely no guarantee it will be compatible with the current state of *mainnet* or *testnet*. -- [`Latest release branch`](https://github.com/near/nearcore/releases) : _(**Stable**)_ - - Use this if you want to run a NEAR node for *mainnet* or *tesnet*. This version is used by validators and other nodes and is fully compatible with the current state of *mainnet* or *testnet*. +- [`Latest stable release`](https://github.com/near/nearcore/tags) : _(**Stable**)_ + - Use this if you want to run a NEAR node for *mainnet*. For *mainnet*, please use the latest stable release. This version is used by mainnet validators and other nodes and is fully compatible with the current state of *mainnet*. +- [`Latest release candidates`](https://github.com/near/nearcore/tags) : _(**Release Candidates**)_ + - Use this if you want to run a NEAR node for *tesnet*. For *testnet*, we first release a RC version and then later make that release stable. For testnet, please run the latest RC version. ## `localnet`