How to run an archive node on Frietor Saar?
What is an archive node?
Simply speaking, an archive node is a full node running without the --seal flag. It stores all the historical data of the blockchain starting from the genesis block. As compared to a typical full node that just holds all the state change data for some latest blocks, an archive node always stores them for each block.
Why is an archive node important?
Developers face limitations when querying recent blocks to ascertain the balance of an address and the status of a smart contract using a full node. This constraint arises because the blockchain continually progresses, making it challenging to obtain comprehensive data. In contrast, archive nodes offer a solution by enabling queries for any specific block at a given point in time.
Archive nodes play a crucial role in various applications on the blockchain, particularly for demanding use cases. These include:
-
Automatic Trading Systems: Historical data is essential for optimizing trading models, allowing automatic trading systems to make informed decisions based on past performance.
-
Verification Modules: State data is necessary for timely transaction verification. Archive nodes provide the required historical context for validating transactions effectively.
-
Analytical Tools: To conduct thorough data analysis, analytical tools rely on full historical data. Archive nodes facilitate the retrieval of complete blockchain history for in-depth analytics.
-
Exchange in Wallets: Some wallets depend on archive nodes to enable fast and efficient transfers on exchanges. By accessing historical data, these wallets enhance their functionality and provide users with a seamless experience.
In summary, archive nodes are instrumental in addressing the challenges associated with obtaining historical blockchain data, enabling developers to meet the specific requirements of diverse applications and use cases.
How to run an archive node on Frietor Saar?
Running an archive node on Frietor Saar is similar to running a full node. The only difference is that you need to remove the --seal flag from the command while starting the node.
-
Follow the instructions in the Run a full node page.
-
Remove the
--sealflag from the command while starting the node. -
Run the following command to start the archive node:
./frietor server --data-dir data -secrets-config secrets_config/aws.json --chain genesis.json --relayer --seal-
The node will start syncing with the network. It will take a few minutes to sync with the network.
-
By Default The Node Will Start Services On The Following Ports.
| Service | Port |
|---|---|
| JSON RPC | 8545 |
| LibP2P | 30301 |
| Metrics (Prometheus) | 10002 |
| GRPC | 9632 |
Check The Node Status
- Run the following command to check the node status.
./frietor statusSetting custom parameters
| Flag | Description | Example |
|---|---|---|
--access-control-allow-origins | The CORS header indicating whether any JSON-RPC response can be shared with the specified origin. | --access-control-allow-origins "*" |
--block-gas-target | The target block gas limit for the chain. | --block-gas-target "0x0" |
--chain | The genesis file used for starting the chain. | --chain "./genesis.json" |
--config | The path to the CLI config. | --config "/path/to/config.json" |
--data-dir | The data directory used for storing Frietor client data. | --data-dir "/path/to/data-dir" |
--dns | The host DNS address which can be used by a remote peer for connection. | --dns "example.com" |
--grpc-address | The GRPC interface. | --grpc-address "127.0.0.1:9632" |
--json-rpc-batch-request-limit | Max length to be considered when handling JSON-RPC batch requests. | --json-rpc-batch-request-limit 20 |
--json-rpc-block-range-limit | Max block range to be considered when executing JSON-RPC requests that consider fromBlock/toBlock values. | --json-rpc-block-range-limit 1000 |
--jsonrpc | The JSON-RPC interface. | --jsonrpc "0.0.0.0:8545" |
--libp2p | The address and port for the libp2p service. | --libp2p "127.0.0.1:1478" |
--log-level | The log level for console output. | --log-level "INFO" |
--log-to | Write all logs to the file at specified location instead of writing them to console. | --log-to "/path/to/log-file.log" |
--max-enqueued | Maximum number of enqueued transactions per account. | --max-enqueued 128 |
--max-inbound-peers | The client's max number of inbound peers allowed. | --max-inbound-peers 32 |
--max-outbound-peers | The client's max number of outbound peers allowed. | --max-outbound-peers 8 |
--max-peers | The client's max number of peers allowed. | --max-peers 40 |
--max-slots | Maximum slots in the pool. | --max-slots 4096 |
--nat | The external IP address without port, as can be seen by peers. | --nat "203.0.113.1" |
--no-discover | Prevent the client from discovering other peers. | --no-discover |
--num-block-confirmations | Minimal number of child blocks required for the parent block to be considered final. | --num-block-confirmations 64 |
--price-limit | The minimum gas price limit to enforce for acceptance into the pool. | --price-limit 0 |
--prometheus | The address and port for the Prometheus instrumentation service. If only port is defined, it will bind to all available network interfaces. | --prometheus 0.0.0.0:9090 |
--relayer | Start the state sync relayer service. PolyBFT only. | |
--restore | The path to the archive blockchain data to restore on initialization. | --restore /path/to/archive |
--seal | The flag indicating that the client should seal blocks. | |
--secrets-config | The path to the SecretsManager config file. Used for AWS SSM. If omitted, the local FS secrets manager is used. | --secrets-config /path/to/secrets/config |