Node synchronization
Besu supports two node types and two synchronization modes on public networks.
Node types
Full nodes
A full node consists of an execution and consensus client, and stores a local copy of the blockchain. With a full node, you can check current balances, sign and send transactions, and look at current dapp data.
Full nodes can guarantee the latest state of the blockchain (and some older states). However, they can't serve the network with all data requests (for example, the balance of an account at an old block).
Run a full node using snap synchronization.
Archive nodes
An archive node is a node that also stores the intermediary state of every account and contract for every block since the genesis block. Archive nodes can do everything full nodes do, and they can also access historical state data. This means that archive nodes require more disk space than full nodes.
Run an archive node using full synchronization.
Do not run an archive node with the Bonsai Tries data storage format. Bonsai is designed for retrieving recent data only.
Sync modes
The following table summarizes the recommended public network sync modes:
| Sync mode | Recommended use | Besu version requirement |
|---|---|---|
| Snap | Full nodes on Mainnet and public testnets. | 22.4.0 or later |
| Full | Archive nodes on smaller networks. Not recommended on Mainnet. | Any |
Checkpoint sync is deprecated. When you select checkpoint sync, Besu performs snap sync instead.
Private networks might require different sync configurations. See Node synchronization for private networks for more information.
Besu must connect with other peers to sync with the network. If your node is having trouble peering, try troubleshooting peering.
Snap synchronization
Snap sync is the default sync mode for all named networks
except dev.
You can enable snap sync using --sync-mode=SNAP.
You need Besu version 22.4.0 or later to use snap sync.
By default, Snap sync prunes historical block data for
pre-merge PoW blocks, retaining only the
headers and the genesis block.
To download the full PoW block history, set
--snapsync-synchronizer-pre-checkpoint-headers-only-enabled
to false. However, this will increase the sync time and disk space usage.
Instead of downloading the state trie node by node, snap
sync downloads as many leaves of the trie as possible, and reconstructs the trie locally.
To enable serving snap sync data to other nodes, set
--snapsync-server-enabled to true.
You can restart Besu during a snap sync in case of hardware or software problems. The sync resumes from the last valid world state and continues to download blocks starting from the last downloaded block.
See how to read the Besu metrics charts when using snap sync.
Full synchronization
Full sync is the default sync mode for the dev network.
You can enable full sync using --sync-mode=FULL.
Use full sync with Forest of Tries to run an
archive node.
Full sync starts from the genesis block and reprocesses all transactions.
You can optionally download and sync pre-merge Ethereum history from ERA1 archive files instead of relying on peered nodes for the data.
Do not run full sync with the Bonsai Tries data storage format. Bonsai is designed for retrieving recent data only.
Sync times
To sync with a public network, Besu runs two processes in parallel: the world state sync and the blockchain download.
While the world state syncs, Besu downloads and imports the blockchain in the background. The blockchain download time depends on CPU, the network, Besu's peers, and disk speed. The blockchain download generally takes longer than the world state sync. Besu must catch up to the current chain head and sync the world state to participate on Mainnet.
The following table shows estimates for each sync mode on Mainnet. All times are hardware dependent.
| Sync mode | Storage format | Node type | Mainnet sync time |
|---|---|---|---|
| Snap | Bonsai | Full node | ~12-16 hours |
| Full | Forest | Archive node | ~weeks |
The Bonsai snap sync estimate is based on May 2026 burn-in results for the Besu 26.5.0
release cycle on AWS m8g.2xlarge instances.
The observed sync time range includes differences in peer sets and disk speed.
By default, snap sync prunes historical block data for pre-merge PoW blocks.
Downloading full PoW blocks could double the download time.
Full sync takes significantly more time than snap sync, and we do not recommend using it on Mainnet.
See the storage estimates for the different sync modes and node types.
Testnets take significantly less time and space to sync.