From 0c543bf5376f3dbf508e9a3e708177ebdac2eaa6 Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 27 Sep 2022 15:04:39 +0100 Subject: [PATCH] fix typo --- src/pages/docs/fundamentals/sync-modes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/docs/fundamentals/sync-modes.md b/src/pages/docs/fundamentals/sync-modes.md index 10bbf20d42..18284b4ab5 100644 --- a/src/pages/docs/fundamentals/sync-modes.md +++ b/src/pages/docs/fundamentals/sync-modes.md @@ -63,4 +63,4 @@ Alternatively, the consensus client can grab a checkpoint from a trusted source ## Summary -There are several ways to sync a Geth node. The default is to use snap sync to create a full node. This verifies all blocks using some recent block that is old enough to be safe from re-orgs as a sync target. A trust-minimized alternative is full-sync, which verifies every block since genesis. These modes drop state data older than 128 blocks, keeping only checkpoints that enable on-request regeneration of historical states. For rapid queries of historical data an archive node is required. Archive nodes keep local copies of all historical data right back to genesis - currently about 12 TB and growing. The opposite extreme is a light node that doesn't store any blockchain data - it requests everything from full nodes. These configurations are controlled by passing `full`, `snap` or `light` to `--syncmode` at startup. For an archive node, `--syncmode` should be `full` and `--gcmode` should be set to `archive`. Currently, due to the transition to proof-of-stake, light-sync dot not work (new light client protocols are being developed). \ No newline at end of file +There are several ways to sync a Geth node. The default is to use snap sync to create a full node. This verifies all blocks using some recent block that is old enough to be safe from re-orgs as a sync target. A trust-minimized alternative is full-sync, which verifies every block since genesis. These modes drop state data older than 128 blocks, keeping only checkpoints that enable on-request regeneration of historical states. For rapid queries of historical data an archive node is required. Archive nodes keep local copies of all historical data right back to genesis - currently about 12 TB and growing. The opposite extreme is a light node that doesn't store any blockchain data - it requests everything from full nodes. These configurations are controlled by passing `full`, `snap` or `light` to `--syncmode` at startup. For an archive node, `--syncmode` should be `full` and `--gcmode` should be set to `archive`. Currently, due to the transition to proof-of-stake, light-sync does not work (new light client protocols are being developed). \ No newline at end of file