Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify - do not use bonsai + archive node #1582

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 10 additions & 1 deletion docs/public-networks/concepts/data-storage-formats.md
Expand Up @@ -24,6 +24,11 @@ To run a node with Bonsai Tries data storage format, use the command line option

</p>

:::caution important
Do not run an [archive node](../get-started/connect/sync-node.md#run-an-archive-node) with Bonsai Tries.
Bonsai is designed for retrieving recent data only.
:::

## Forest of Tries

Forest of Tries, also called forest mode, is the default storage format.
Expand All @@ -45,7 +50,11 @@ We recommend using [Bonsai Tries](#bonsai-tries) to save disk space.

### Storage requirements

Forest mode uses significantly more memory than Bonsai. With an [archive node](../get-started/connect/sync-node.md#run-an-archive-node), forest mode uses an estimated 12 TB of storage, while Bonsai uses an estimated 1100 GB of storage. With a [full node](../get-started/connect/sync-node.md#run-a-full-node), forest mode uses an estimated 750 GB of storage, while Bonsai uses an estimated 650 GB of storage.
Forest mode uses significantly more memory than Bonsai.
With a [full node](../get-started/connect/sync-node.md#run-a-full-node), forest mode uses an
estimated 750 GB of storage, while Bonsai uses an estimated 650 GB of storage.
[Archive nodes](../get-started/connect/sync-node.md#run-an-archive-node) must use forest mode, which
uses an estimated 12 TB of storage.

### Accessing data

Expand Down
86 changes: 60 additions & 26 deletions docs/public-networks/get-started/connect/sync-node.md
Expand Up @@ -8,48 +8,73 @@ tags:

# Sync Besu

Besu supports two node types, commonly referred to as [full nodes](#run-a-full-node) and [archive nodes](#run-an-archive-node).

Full nodes have the current state of the blockchain. They can't serve the network with all data requests (for example, the balance of an account at an old block). Full nodes can guarantee the latest state for the blockchain (and some older states, but not all). You can check current balances, sign and send transactions, and look at current dapp data.

Archive nodes also store 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 access historical state data. Archive nodes require more disk space than full nodes.

Besu must connect with other peers to sync with the network. If your node is having trouble peering, try [troubleshooting peering](../../how-to/troubleshoot/peering.md).
Besu supports two node types, commonly referred to as [full nodes](#run-a-full-node) and
[archive nodes](#run-an-archive-node).

A full node consists of an
[execution and consensus client](../../concepts/the-merge.md#execution-and-consensus-clients), 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).

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.
However, archive nodes require more disk space than full nodes.

Besu must connect with other peers to sync with the network.
If your node is having trouble peering, try [troubleshooting peering](../../how-to/troubleshoot/peering.md).

## 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.
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 the average world state sync time, and blockchain download time, for each sync mode on Mainnet. All times are hardware dependent; this table is based on running AWS instances m6gd.2xlarge. Each sync mode also has its own world state database size.
The following table shows the average world state sync time, and blockchain download time, for each
sync mode on Mainnet.
All times are hardware dependent; this table is based on running AWS instances m6gd.2xlarge.
Each sync mode also has its own world state database size.

| Sync mode | Time to sync world state | Time to download blockchain | Disk usage |
| ---------- | ------------------------ |----------------------------|---------------|
| Snap | ~6 hours | ~1.5 days | Average disk |
| Checkpoint | ~5 hours | ~13 hours | Smallest disk |
| Fast | ~1.5 days | ~1.5 days | Average disk |
| Full | ~weeks | ~weeks | Largest disk |

:::note

- As of late 2023, an average Mainnet snap sync consumes around 1000 GB using Bonsai Tries. Read more about [storage requirements](../../concepts/data-storage-formats.md#storage-requirements) across data storage formats and sync modes.

|------------|--------------------------|-----------------------------|---------------|
| Snap | ~6 hours | ~1.5 days | Average disk |
| Checkpoint | ~5 hours | ~13 hours | Smallest disk |
| Fast | ~1.5 days | ~1.5 days | Average disk |
| Full | ~weeks | ~weeks | Largest disk |

:::note Notes
- As of late 2023, an average Mainnet snap sync consumes around 1000 GB using Bonsai Tries.
Read more about [storage requirements](../../concepts/data-storage-formats.md#storage-requirements)
across data storage formats and sync modes.
- Testnets take significantly less time and space to sync.

:::

## Storage

You can store the world state using [Forest of Tries](../../concepts/data-storage-formats.md#forest-of-tries) or [Bonsai Tries](../../concepts/data-storage-formats.md#bonsai-tries). We recommend using Bonsai Tries for the lowest storage requirements.
You can store the world state using [Forest of Tries](../../concepts/data-storage-formats.md#forest-of-tries)
or [Bonsai Tries](../../concepts/data-storage-formats.md#bonsai-tries).
If you're [running a full node](#run-a-full-node), we recommend using Bonsai Tries for the lowest
storage requirements.

## Run a full node

You can run a full node using [snap synchronization (snap sync)](#snap-synchronization), [checkpoint synchronization (checkpoint sync)](#checkpoint-synchronization), or [fast synchronization (fast sync)](#fast-synchronization).
A full node stores a local copy of the blockchain and the current state of the blockchain.
You can run a full node using [snap synchronization (snap sync)](#snap-synchronization),
[checkpoint synchronization (checkpoint sync)](#checkpoint-synchronization), or
[fast synchronization (fast sync)](#fast-synchronization).

:::note Sync nodes for BFT

Snap sync and checkpoint sync are not supported for [QBFT](../../../private-networks/how-to/configure/consensus/qbft.md) or [IBFT 2.0](../../../private-networks/how-to/configure/consensus/ibft.md) networks.
Snap sync and checkpoint sync are not supported for
[QBFT](../../../private-networks/how-to/configure/consensus/qbft.md) or
[IBFT 2.0](../../../private-networks/how-to/configure/consensus/ibft.md) networks.

:::

Expand All @@ -59,7 +84,8 @@ Snap sync and checkpoint sync are not supported for [QBFT](../../../private-netw

We recommend using snap sync over fast sync because snap sync can be faster by several days.

We recommend using snap sync with the [Bonsai](../../concepts/data-storage-formats.md#bonsai-tries) data storage format for the fastest sync and lowest storage requirements.
We recommend using snap sync with the [Bonsai](../../concepts/data-storage-formats.md#bonsai-tries)
data storage format for the fastest sync and lowest storage requirements.

:::

Expand Down Expand Up @@ -156,6 +182,14 @@ The easiest solution in this scenario is to restart fast sync to obtain a new pi

## Run an archive node

To run an archive node, enable full synchronization (full sync) using [`--sync-mode=FULL`](../../reference/cli/options.md#sync-mode).
An archive node stores all historical states of the blockchain.
To run an archive node, enable full synchronization (full sync) using
[`--sync-mode=FULL`](../../reference/cli/options.md#sync-mode).

Full sync starts from the genesis block and reprocesses all transactions.

:::caution important
Do not run an archive node with the [Bonsai Tries](../../concepts/data-storage-formats.md#bonsai-tries)
data storage format.
Bonsai is designed for retrieving recent data only.
:::