diff --git a/docs/develop/node/archival/hardware-archival.md b/docs/develop/node/archival/hardware-archival.md index 811e9503db5..ea3fcc4a1e2 100644 --- a/docs/develop/node/archival/hardware-archival.md +++ b/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._ +
Resources for Cost Estimation

@@ -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
+ +> Got a question? +> > Ask it on StackOverflow! diff --git a/docs/develop/node/archival/run-archival-node.md b/docs/develop/node/archival/run-archival-node.md new file mode 100644 index 00000000000..c04f3fd2492 --- /dev/null +++ b/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? + + Ask it on StackOverflow! diff --git a/docs/develop/node/community/node-community-updates.md b/docs/develop/node/community/node-community-updates.md index 58f714af961..9a992821fbf 100644 --- a/docs/develop/node/community/node-community-updates.md +++ b/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: +
+Did You Know?

-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) +
-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. -
-Heads up

+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 -
+- **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? + + Ask it on StackOverflow! diff --git a/docs/develop/node/intro/keys.md b/docs/develop/node/intro/keys.md index 936fd20e29b..97e7c1c5016 100644 --- a/docs/develop/node/intro/keys.md +++ b/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,7 +47,7 @@ When a validator is elected during an epoch, they have the opportunity to stake
-heads up

+Heads up

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. @@ -55,11 +55,11 @@ If validator keys are changed _during an epoch in which the validator is staking 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 diff --git a/docs/develop/node/intro/types-of-node.md b/docs/develop/node/intro/types-of-node.md index 34d62210d20..3e2dbb7302e 100644 --- a/docs/develop/node/intro/types-of-node.md +++ b/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? + + Ask it on StackOverflow! diff --git a/docs/develop/node/intro/what-is-a-node.md b/docs/develop/node/intro/what-is-a-node.md index 71caff3337a..bc64b550110 100644 --- a/docs/develop/node/intro/what-is-a-node.md +++ b/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? + + Ask it on StackOverflow! diff --git a/docs/develop/node/maintenance/maintenance.md b/docs/develop/node/maintenance/maintenance.md index 1d5ae0385bf..37cdb69e720 100644 --- a/docs/develop/node/maintenance/maintenance.md +++ b/docs/develop/node/maintenance/maintenance.md @@ -7,7 +7,7 @@ description: NEAR Node Maintenance and Network Updates ## Updating a Node -As a decentralized network, every update to NEAR Protocol needs some coordination between end users, platforms, developers, and validators. [`nearup`](https://github.com/near/nearup) provides scripts to launch NEAR Protocol `TestNet` and `BetaNet` nodes. Unless it is executed with the switch `--binary-path`, `nearup` will automatically update the local binaries if NEAR's boot nodes fork the network and change the genesis checksum. +As a decentralized network, every update to NEAR Protocol needs some coordination between end users, platforms, developers, and validators. [`nearup`](https://github.com/near/nearup) provides scripts to launch NEAR Protocol `testnet` and `betanet` nodes. Unless it is executed with the switch `--binary-path`, `nearup` will automatically update the local binaries if NEAR's boot nodes fork the network and change the genesis checksum. For security-critical applications and for validators, `nearup` can run a locally compiled binary of [`nearcore`](https://github.com/near/nearcore), but such updates have to be done manually. Since validators are responsible for creating new blocks, coordination in this process is necessary to avoid any network stall. @@ -15,16 +15,16 @@ For security-critical applications and for validators, `nearup` can run a locall ## Planned Updates NEAR merges node updates from [nearcore releases](https://github.com/near/nearcore/releases) as follows: -- `BetaNet` every Monday at 00:00 UTC. The release tag is mapped with `x.y.z-beta` -- `TestNet` every Monday at 00:00 UTC. The release tag is mapped with `x.y.z-rc` -- `MainNet` is not yet subject to planned releases +- `betanet` every Monday at 00:00 UTC. The release tag is mapped with `x.y.z-beta` +- `testnet` every Monday at 00:00 UTC. The release tag is mapped with `x.y.z-rc` +- `mainnet` is not yet subject to planned releases -Once `MainNet: Restricted` is live, planned updates to `TestNet` and `MainNet` will come via coordination with validators. +Once `mainnet: Restricted` is live, planned updates to `testnet` and `mainnet` will come via coordination with validators.
Heads up

-`BetaNet` provides cutting-edge testing grounds for validators, with weekly updates and frequent hard-forks. `BetaNet` is using the `beta` branch of `nearcore`, which is merged every Wednesday at 00:00 UTC and deployed on NEAR boot nodes shortly after. +`betanet` provides cutting-edge testing grounds for validators, with weekly updates and frequent hard-forks. `betanet` is using the `beta` branch of `nearcore`, which is merged every Wednesday at 00:00 UTC and deployed on NEAR boot nodes shortly after.
@@ -35,3 +35,7 @@ We may issue a `[CODE_YELLOW_TESTNET]` or `[CODE_YELLOW_MAINNET]` if the network NEAR Protocol team will use the tag `[CODE_RED_TESTNET]` or `[CODE_RED_MAINNET]` in the Validator Announcement channel on [Discord](https://discord.gg/xsrHaCb), followed by email instructions for coordination. Some updates may follow a confidential process, as explained on [nearcore/SECURITY.md](https://github.com/near/nearcore/blob/master/SECURITY.md) docs. NEAR's team will be mostly active on [Github](https://github.com/near/nearcore), and with limited participation on Discord and Telegram. + +>Got a question? + + Ask it on StackOverflow! diff --git a/docs/develop/node/rpc/hardware-rpc.md b/docs/develop/node/rpc/hardware-rpc.md index f32527bccd3..f6f928ace9b 100644 --- a/docs/develop/node/rpc/hardware-rpc.md +++ b/docs/develop/node/rpc/hardware-rpc.md @@ -34,8 +34,8 @@ 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 | +| AWS | c5.2xlarge | $250 CPU + $20 storage | +| GCP | c2-standard-8 | $220 CPU + $20 storage | | Azure | Standard_F8s_v2 | $180 CPU + $10 storage |
@@ -52,3 +52,7 @@ All prices reflect *reserved instances* which offer deep discounts on all platfo - Azure — https://azure.microsoft.com/en-us/pricing/calculator
+ +>Got a question? + + Ask it on StackOverflow! 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 530eee0f82e..4c2f4555683 100644 --- a/docs/develop/node/validator/compile-and-run-a-node.md +++ b/docs/develop/node/validator/compile-and-run-a-node.md @@ -5,7 +5,7 @@ sidebar_label: Compile and Run without Container description: Compile and Run a NEAR Node without Container in localnet, testnet, and mainnet --- -This doc is written for developers, sysadmins, DevOps, or curious people who want to know how to compile and run a regular NEAR node natively (without containerization) for one of the following networks: +This doc is written for developers, sysadmins, DevOps, or curious people who want to know how to compile and run a regular NEAR validator node natively (without containerization) for one of the following networks: - [`localnet`](/docs/develop/node/validator/compile-and-run-a-node#localnet) - [`testnet`](/docs/develop/node/validator/compile-and-run-a-node#testnet) @@ -204,7 +204,7 @@ $ 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. Currently `1.19.0` as of 5/25/21. +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) ]. @@ -283,3 +283,7 @@ $ ./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/docs/develop/node/validator/deploy-on-mainnet.md b/docs/develop/node/validator/deploy-on-mainnet.md index 7262171ec7c..97b6282125f 100644 --- a/docs/develop/node/validator/deploy-on-mainnet.md +++ b/docs/develop/node/validator/deploy-on-mainnet.md @@ -1,19 +1,19 @@ --- id: deploy-on-mainnet -title: Deploy Node on MainNet -sidebar_label: Deploy Node on MainNet +title: Deploy Node on Mainnet +sidebar_label: Deploy Node on Mainnet --- -Deploying a node on MainNet is similar to deploying on TestNet and BetaNet: -1. Create your MainNet wallet -2. Deploy your MainNet staking pool -3. Build and run your MainNet validator node +Deploying a node on mainnet is similar to deploying on testnet and betanet: +1. Create your mainnet wallet +2. Deploy your mainnet staking pool +3. Build and run your mainnet validator node -### 1. Create your MainNet Wallet +### 1. Create your mainnet Wallet - Go to [wallet.near.org](https://wallet.near.org/) and create an account. -### 2. Deploy your MainNet Staking Pool +### 2. Deploy your mainnet Staking Pool You can instantly deploy the staking pool with [near-cli](https://github.com/near/near-cli), using the command `near call`: ``` @@ -35,7 +35,7 @@ The command will invoke the `staking-pool-factory` from [NEAR Core Contracts](ht If your POOL_ID is "buildlinks", the staking pool factory will deploy a contract called "buildlinks.poolv1.near", and your node will appear in the Explorer as "buildlinks.poolv1.near"
-### 3. Build and run your MainNet validator node +### 3. Build and run your mainnet validator node - Clone the [`nearcore`](https://github.com/near/nearcore) repository: @@ -73,3 +73,7 @@ target/release/neard init --chain-id="mainnet" --account-id=Got a question? + + Ask it on StackOverflow! diff --git a/docs/develop/node/validator/hardware.md b/docs/develop/node/validator/hardware.md index a22f49b9722..0f83636f6d6 100644 --- a/docs/develop/node/validator/hardware.md +++ b/docs/develop/node/validator/hardware.md @@ -34,8 +34,8 @@ 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 | +| AWS | c5.2xlarge | $250 CPU + $20 storage | +| GCP | c2-standard-8 | $220 CPU + $20 storage | | Azure | Standard_F8s_v2 | $180 CPU + $10 storage |
@@ -52,3 +52,7 @@ All prices reflect *reserved instances* which offer deep discounts on all platfo - Azure — https://azure.microsoft.com/en-us/pricing/calculator
+ +>Got a question? + + Ask it on StackOverflow! diff --git a/docs/develop/node/validator/running-a-node-macos-linux.md b/docs/develop/node/validator/running-a-node-macos-linux.md index a3ae67e4303..ababcb64b39 100644 --- a/docs/develop/node/validator/running-a-node-macos-linux.md +++ b/docs/develop/node/validator/running-a-node-macos-linux.md @@ -2,7 +2,7 @@ id: running-a-node title: Run a Node on Linux and MacOS sidebar_label: Run a Node (Linux and MacOS) -Description: How to run a NEAR node using nearup on Linux and MacOS, with or without using Docker. +description: How to run a NEAR node using nearup on Linux and MacOS, with or without using Docker --- This doc is written for developers, sysadmins, DevOps, or curious people who want to know how to run a NEAR node using `nearup` on Linux and MacOS, with or without using Docker. @@ -43,7 +43,7 @@ Once `nearup` and Docker are installed (by following instructions in previous se nearup betanet ``` -_(If you prefer to use `TestNet` then just replace `betanet` with `testnet` in the command above)_ +_(If you prefer to use `testnet` then just replace `betanet` with `testnet` in the command above)_ You will then be prompted for an Account ID. You can leave this empty if you would just like to run a 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. @@ -121,7 +121,7 @@ On MacOS or Linux nearup betanet --nodocker --binary-path path/to/nearcore/target/release ``` -If you want to run `TestNet` instead of `BetaNet` then replace `betanet` with `testnet` in the command above. +If you want to run `testnet` instead of `betanet`, then replace `betanet` with `testnet` in the command above. You will then be prompted for an Account ID. You can leave this empty if you would just like to run a 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. @@ -171,3 +171,7 @@ Starting NEAR client... Node is running! To check logs call: `nearup logs` or `nearup logs --follow` ``` + +>Got a question? + + Ask it on StackOverflow! diff --git a/docs/develop/node/validator/running-a-node-windows.md b/docs/develop/node/validator/running-a-node-windows.md index 65296bf1a74..f036effadeb 100644 --- a/docs/develop/node/validator/running-a-node-windows.md +++ b/docs/develop/node/validator/running-a-node-windows.md @@ -111,3 +111,7 @@ The README for `nearup` (linked above) may be **all you need to get a node up an ``` You might be asked for a validator ID; if you do not want to validate, simply press enter. For validation, please refer to the [validation section](validator/staking.md). + +>Got a question? + + Ask it on StackOverflow! diff --git a/docs/roles/integrator/exchange-integration.md b/docs/roles/integrator/exchange-integration.md index e84f0021076..46c3addd271 100644 --- a/docs/roles/integrator/exchange-integration.md +++ b/docs/roles/integrator/exchange-integration.md @@ -794,43 +794,7 @@ http post https://rpc.mainnet.near.org method=block params:='{"finality":"final" as the height of the block. ## Running an Archival Node - -- Setting up an archival node is the same as a [regular node](/docs/develop/node/validator/running-a-node), but modifying your `config.json` by changing `archive` to `true` and specifying `tracked_shards`. Please make sure that the node is stopped while changing the config. - -The config should contain the following fields, currently NEAR testnet and mainnet have only 1 (zero indexed) shard and that shard is tracked. - -``` -{ - ... - "archive": true, - "tracked_shards": [0], - ... -} -``` - -In the future there will be the possibility to track different or multiple shards. - -- 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 just 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 the 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 start archive node - -Make sure [nearup](https://github.com/near/nearup) is installed. - -1. `wget -b https://near-protocol-public.s3.ca-central-1.amazonaws.com/backups/{testnet|mainnet}/archive/data.tar` -2. `nearup run testnet` -3. Wait until initialization finishes, use `nearup logs --follow` -4. `nearup stop` -5. `tar -xvf data.tar -C ~/.near/testnet/data` -6. `nearup run testnet` - should start syncing headers at ~97% +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). ## Staking and Delegation diff --git a/website/sidebars.json b/website/sidebars.json index c57139ec23e..a9c9017ef17 100644 --- a/website/sidebars.json +++ b/website/sidebars.json @@ -90,9 +90,10 @@ }, { "type": "subcategory", - "label": "Run a Archival Node", + "label": "Run an Archival Node", "ids": [ - "develop/node/archival/hardware-archival" + "develop/node/archival/hardware-archival", + "develop/node/archival/run-archival-node" ] }, {