- x86-64 architecture
- requires Curl
- requires Docker, recommended versions;
- Docker Engine v20.10.18 and above
- optional AWS Account, if near datalake on AWS S3 to be used
- optional Near Account, for Write Transactions & Custom Signers
- depends on Aurora Relayer2, Web3-compatible relayer server for Aurora
- depends on Aurora Refiner, allows users to download all NEAR Blocks and get all information relevant to Aurora
git clone https://github.com/aurora-is-near/standalone-rpc
cd standalone-rpc
git checkout {version tag}
./install.sh
Installer configures standalone-rpc, downloads required Near and Aurora snapshots and starts containers to serve RPC
and sync with blockchain. Depending on your network bandwidth and CPU downloading of snapshots and syncing with the
chain may take some time. All installation artifacts and chain data are placed under standalone-rpc/srpc2
directory.
Upon installation, the RPC endpoint is served at http://127.0.0.1:20080/ as well as on the public IPs of your computer.
By default, standalone-rpc installer is configured to work on mainnet
and near blocks to be consumed from nearcore
. See installer usage for more details.
Usage: install.sh [options]
Options
-n {mainnet|testnet} network to use, default is mainnet.
-r {nearcore|datalake} near source for indexing, default is nearcore.
-w {number [1-256]} number of workers used for downloading near snapshots, default is 256.
NOTE: On some OS and HW configurations, default number of workers may cause high CPU consumption during download.
-s if specified then snapshots are ignored during installation, default downloads and uses snapshots.
NOTE: Ignoring snapshots may cause refiner not to index near chain. This can only be a valid option
if near source is selected as datalake otherwise refiner will not be sync with near core from scratch.
-h prints usage
Examples
./install.sh -n mainnet -r datalake -s
AWS_SHARED_CREDENTIALS_FILE=~/.aws/credentials ./install.sh -r datalake -s
After installation completes, standalone-rpc should start to serve RPC and catch up with the network. You can always
stop and start standalone-rpc by executing the ./stop.sh
or ./start.sh
scripts placed under srpc2
directory.
The software in this installation is updated automatically. Whenever Aurora releases a new image, it will be downloaded, and services are restarted.
This is however not true for the included database and chain files. These are only downloaded initially when running ./install.sh
. Keep your node running to prevent going out of sync.
cd standalone-rpc
./uninstall.sh
IMPORTANT this operation does the followings
- stops and removes Aurora standalone-rpc related docker containers, volumes and networks
- deletes configuration
- asks user for deletion of data, default does not delete
The default installation does not support write transactions. It just sets up a placeholder account and a file for further customizations. To enable write transactions with your account, you need to follow the steps below:
- Create an account on testnet/mainnet and load some NEAR on it.
- Export the account's keypair and name into
srpc2/config/relayer/relayer.json
(check the original file for format). - Change the
signer
value in thesrpc2/config/relayer/relayer.yaml
to the account's name. - Restart standalone-rpc.
- Aurora Relayer2 configuration can be changed from
srpc2/config/relayer/relayer.yaml
. Some configuration changes can be applied without requiring a restart, please see repository page for more details about configuration. - standalone-rpc uses Nginx as a reverse-proxy before Aurora Relayer2 RPC endpoints. To change Nginx configuration, edit the config file
srpc2/config/nginx/endpoint.conf
, and restart standalone-rpc
For those who already have a running Aurora Standalone RPC with version v2.0.2
, the existing Near Data can be reused.
Meaning that, installer can skip the time-consuming Near Snapshot download step and use the Near Data of existing installation.
Follow the below steps, if you prefer the reuse existing Near Data.
- change directory to previous installation
- checkout version 2.1.0
- run installer with migration option and pass the current directory as parameter
- You can also use existing data by cloning repo from scratch to another directory. In that case, instead of current
directory, you have to pass the path to
v2.0.2
installation directory with-m
option - When it is run with migration option, installer does stop the previous installation before starting new one, but it does not do any cleanup on previous installation data or configuration, it is users responsibility to keep or delete them
- Never delete the following directories of the previous installation, after migration they are linked and reused by the
new version
<previous standalone-rpc path>/near
<previous standalone-rpc path>/engine
cd ~/repo/standalone-rpc/
git fetch
git checkout v2.1.0
./install.sh -m .