> For the complete documentation index, see [llms.txt](https://docs.soniclabs.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.soniclabs.com/sonic/node-deployment/archive-node.md). # Archive Node Archive nodes store the entire history of the Sonic chain, including all historical states, transactions, and blocks since the genesis block. These nodes handle historical data requests, useful for chain explorers or apps that require historical chain information. However, they do not validate transactions or create new blocks, which is the role of validator nodes. To run an archive node on the Sonic mainnet or testnet, follow the steps below. ## 1. Build Sonic Client and Tooling The minimal configuration for a Sonic archive node is a Linux server with **4 vCPU, 32 GB of RAM**, and **local SSD storage**. We recommend at least **8 vCPU** and **64 GB of RAM**, but **128GB of RAM** is generally preferable for high-demand nodes. You will need **≈3TB of free local SSD** space to achieve good performance and speed. The configuration details depend on your specific use case. The IOPS throughput and random access latency of the state DB persistent storage determine the performance of Sonic. For a smooth installation and fast response time, we recommend a **local NVMe** or a **local SSD** drive. A remote block device, e.g. AWS Elastic Block Store (EBS), does not provide the required latency and IOPS performance. {% hint style="info" %} The system firewall must allow TCP and UDP connections from/to port 5050. For the rest of the firewall setup, see [Node Hardening, Tier 1](/sonic/node-deployment/node-hardening/tier-1-essentials.md). {% endhint %} Building the Sonic binary requires the essential software compilation tools and the Go language version [1.26 or newer](https://go.dev/dl/) to be available. Please refer to your Linux distribution manuals to obtain the development tools installed on your system. ### Build Sonic Client Download the Sonic source code from the following GitHub repository. ``` git clone https://github.com/0xsoniclabs/sonic.git cd sonic ``` Switch to the most recent [Sonic release](https://github.com/0xsoniclabs/sonic/releases). ```bash git fetch --tags && git checkout -b v2.2.5 tags/v2.2.5 ``` Build the Sonic binary using the provided configuration. ```bash make all ``` Install the new binaries to the bin folder for system-wide access (optional). `install` makes them belong to `root`, so the node itself can't modify them. ```bash sudo install -o root -g root -m 0755 build/sonic* /usr/local/bin/ ``` ## 2. Prime Sonic State DB Download the most recent network archive genesis file for the [**Sonic mainnet or testnet**](https://genesis.soniclabs.com)**.** ```bash curl -JLO https://genesis.soniclabs.com/latest-sonic-archive.g ``` The genesis file will be used to prime your local state database and will allow you to join the network and synchronize with it. ### Prime the Database Use the `sonictool` app (created during the building process as `build/sonictool`) to prime a validated archive state database for the Sonic client. Start the genesis expansion. ```bash GOMEMLIMIT=50GiB sonictool --datadir --cache 12000 genesis latest-sonic-archive.g ``` The last step of the genesis processing is the state validation. Please double-check that the output log contains the following messages with details about the verified state. Please note that **the state root hash** will be different and **should correspond with the expected state** provided for the latest genesis file on the [download page](https://genesis.soniclabs.com/). {% tabs %} {% tab title="Sonic Mainnet" %} ``` StateDB imported successfully, stateRoot matches module=gossip-store index=1 root="1ccba39...9ea2be" ``` {% endtab %} {% tab title="Sonic Testnet" %} ``` StateDB imported successfully, stateRoot matches module=gossip-store index=1 root="9601e5...c3d639"P ``` {% endtab %} {% endtabs %} ### Pruned Database (optional) If you don't need the full archive history, but still want the node to respond to the RPC requests addressing newly created blocks, you can prime your node using a pruned genesis file. This significantly reduces the size of the state database on your node. Download the most recent **pruned** genesis file for the [Sonic mainnet or testnet](https://genesis.soniclabs.com/latest-sonic-pruned.g) and follow the same priming procedure as described above using the downloaded file. ``` curl -JLO https://genesis.soniclabs.com/latest-sonic-pruned.g GOMEMLIMIT=50GiB sonictool --datadir --cache 12000 genesis latest-sonic-pruned.g ``` Your node history will start at the block and epoch of the used genesis file. You can find the exact values on the download page. Once started, the node will begin processing new blocks and providing the related information normally. Requests touching pre-genesis block history will fail with an error. ## 3. Synchronize With Network With the Sonic app created and the database primed in the previous step, you are ready to start the node and synchronize its state with the network. * Use the node database path (``) from the previous step. * Use ≈90% of the RAM as the GOMEMLIMIT value. * Use ≈12 GiB of the RAM as the --cache value. To answer RPC requests, also enable the HTTP and WebSocket interfaces. The flags below listen on `127.0.0.1` only and enable only the standard method groups. That's the safe starting point, for example with a proxy on the same machine forwarding requests to the node. ``` --http --http.addr=127.0.0.1 --http.port=18545 --http.vhosts=localhost --http.api=eth,web3,net,sonic ``` ``` --ws --ws.addr=127.0.0.1 --ws.port=18546 --ws.api=eth,web3,net,sonic ``` {% hint style="warning" %} Before you listen on another address, enable more method groups, or allow browser apps (CORS), follow [Node Hardening, Tier 1](/sonic/node-deployment/node-hardening/tier-1-essentials.md): it covers which settings fit public and private RPC nodes. Enable `debug` or `trace` only on a dedicated node, behind the access controls in [Tier 4](/sonic/node-deployment/node-hardening/tier-4-control-access.md). {% endhint %} {% hint style="info" %} Please obtain and explicitly specify the external IP address of your node as a starting flag to help with the inter-node peer-to-peer connectivity. {% endhint %} Now, start your node with the sonicd application. ```bash GOMEMLIMIT=50GiB sonicd --datadir --cache 12000 --nat extip: ``` {% hint style="info" %} **Crash traces.** Also set `GOTRACEBACK=crash` (next to `GOMEMLIMIT`), so the node prints a full trace, and leaves a core dump if your system collects them, when it crashes. If the node must listen on a port below 1024 (e.g. 80), grant that in its systemd service with `AmbientCapabilities=CAP_NET_BIND_SERVICE`, not with `setcap` on the `sonicd` binary: file capabilities make Go suppress crash traces. The [starter service file](/sonic/node-deployment/node-hardening/appendix-a-starter-service-file.md) shows both. {% endhint %} ## 4. Secure Your Node Once the node is in sync, run it as a systemd service under its own user instead of from a shell: the [starter service file](/sonic/node-deployment/node-hardening/appendix-a-starter-service-file.md) sets this up. Then work through [Node Hardening](/sonic/node-deployment/node-hardening.md), starting with [Tier 1](/sonic/node-deployment/node-hardening/tier-1-essentials.md).