Skip to main content

Arthera nodes

The Arthera node binary can be used to run the following types of blockchain nodes:

Users can submit transactions to a validator, or they can submit transactions to a read-only node or API node, and then transactions will be propagated across the network.

  • Validator node: emits and validates events generated by the protocol (other validators) and get rewarded for their work
  • API node: is typically used by dApps to talk to the blockchain using the RPC or WebSocket protocols. It holds all the history of the blockchain. It does not emit events is not rewarded for being online.
  • Tracing node: an API node that has additional information for transaction tracing, to allow developers to perform tracing queries. It holds all the history of the blockchain.
  • Gateway node: typically runs in a secure, local environment as a 'gateway' node. It can receive transactions from clients and it will propagate them to the network.

API nodes and Tracing nodes are also called archive nodes because they hold all the history of the blockchain.

Synchronization​

Nodes synchronize with the blockchain using either full (default) or snap sync:

  • full sync (default): a full block-by-block sync generates the current state by executing every block starting from the genesis block. A full sync independently verifies block provenance as well as all state transitions by re-executing the transactions in the entire historical sequence of blocks
  • snap sync: does not sync the entire history and is much faster. Snap sync starts from a relatively recent block and syncs from there to the head of the chain, keeping only the most recent N block states in memory. The difference between the snap-synced node and a full block-by-block synced node is that a snap synced node started from an initial checkpoint that was more recent than the genesis block. Snap sync is much faster than a full block-by-block sync from genesis. Snap sync allows pruning old data to save space.

Pruning​

Pruning is the process of erasing older data to save disk space.

Pruning rules

  1. Do not try to prune an archive node. Archive nodes need to maintain ALL historic data by definition.
  2. Ensure there is at least 8 GB of storage space still available on the disk that will be pruned. The node stops when it hits this limit.
  3. The node is fully synchronized until it got out of storage.

There are two types of pruning:

  1. Manual pruning: to perform this operation, ensure that Pruning rules are satisfied. Stop the node, and run the following command:
docker run -it -v $HOME/arthera:/data arthera/arthera-node:1.2.1-rc.3 --cache 4000 snapshot prune-state
  1. Automatic pruning: a node can prune its data while it is running. It works in two modes:
  • --gcmode full: aggressive pruning (discards old VM tries). Needs extra RAM so please use in combination with the --cache 15000 (or more) flag.
  • --gcmode light: less aggressive than the full mode and uses less RAM

Database healing​

When there is problem to open the database it's recommended to start the automatic healing with the command below:

docker run -it -v $HOME/arthera:/data arthera/arthera-node:1.2.1-rc.3 --cache 4000 db heal --experimental

Database export​

Before there is problem to open the database it's recommended to start from a stopped node the export with the command below where 6783 is the last epoch you want to export so adapt this number or remove the 2 last numbers:

docker run -it -v $HOME/arthera:/data arthera/arthera-node:1.2.1-rc.3 --cache 4000 export genesis /data/epoch6783.g 1 6783