You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The execution layer may be run in different modes to suit different use cases, from re-executing the blockchain's world state to only syncing with the tip of the chain from a trusted checkpoint.
238
238
239
-
Full sync downloads all blocks (including headers, transactions, and receipts) and generates the state of the blockchain incrementally by executing every block from genesis.
239
+
#### Full sync {#full-sync}
240
+
241
+
A full sync downloads all blocks (including headers and block bodies) and regenerates the state of the blockchain incrementally by executing every block from genesis.
240
242
241
243
- Minimizes trust and offers the highest security by verifying every transaction.
242
244
- With an increasing number of transactions, it can take days to weeks to process all transactions.
243
245
244
-
#### Full snap sync {#snap-sync}
246
+
[Archive nodes](#archive-node) perform a full sync to build (and retain) a complete history of the state changes made by every transaction in every block.
247
+
248
+
#### Fast sync {#fast-sync}
249
+
250
+
Like a full sync, a fast sync downloads all blocks (including headers, transactions, and receipts). However, instead of re-processing the historical transactions, a fast sync relies on the receipts until it reaches a recent head, when it switches to importing and processing blocks to provide a full node.
245
251
246
-
Snap sync verifies the chain block-by-block, just like a full archive sync; however, instead of starting at the genesis block, it starts at a more recent 'trusted' checkpoint that is known to be part of the true blockchain. The node saves periodic checkpoints while deleting data older than a certain age. Those snapshots are used to regenerate state data when it is needed, rather than having to store it all forever.
252
+
- Fast sync strategy.
253
+
- Reduces processing demand in favor of bandwidth usage.
247
254
248
-
- Fastest sync strategy, currently default in Ethereum mainnet
249
-
- Saves a lot of disk usage and network bandwidth without sacrificing security
255
+
#### Snap sync {#snap-sync}
250
256
251
-
[More on snap sync](https://github.com/ethereum/devp2p/blob/master/caps/snap.md)
257
+
Snap syncs also verify the chain block-by-block. However, instead of starting at the genesis block, a snap sync starts at a more recent 'trusted' checkpoint that is known to be part of the true blockchain. The node saves periodic checkpoints while deleting data older than a certain age. These snapshots are used to regenerate state data as needed, rather than storing it forever.
258
+
259
+
- Fastest sync strategy, currently default in Ethereum Mainnet.
260
+
- Saves a lot of disk usage and network bandwidth without sacrificing security.
261
+
262
+
[More on snap sync](https://github.com/ethereum/devp2p/blob/master/caps/snap.md).
252
263
253
264
#### Light sync {#light-sync}
254
265
@@ -271,16 +282,14 @@ Optimistic sync is a post-merge synchronization strategy designed to be opt-in a
271
282
272
283
#### Checkpoint sync {#checkpoint-sync}
273
284
274
-
Checkpoint sync, also known as weak subjectivity sync, creates a superior user experience for syncing Beacon Node. It's based on assumptions of [weak subjectivity](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) which enables syncing Beacon Chain from a recent weak subjectivity checkpoint instead of genesis. Checkpoint sync makes the initial sync time significantly faster with similar trust assumptions as syncing from [genesis](/glossary/#genesis-block).
285
+
A checkpoint sync, also known as weak subjectivity sync, creates a superior user experience for syncing a Beacon Node. It's based on assumptions of [weak subjectivity](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) which enables syncing the Beacon Chain from a recent weak subjectivity checkpoint instead of genesis. Checkpoint syncs make the initial sync time significantly faster with similar trust assumptions as syncing from [genesis](/glossary/#genesis-block).
275
286
276
-
In practice, this means your node connects to a remote service to download recent finalized states and continues verifying data from that point. Third party providing the data is trusted and should be picked carefully.
287
+
In practice, this means your node connects to a remote service to download recent finalized states and continues verifying data from that point. The third party providing the data is trusted and should be picked carefully.
277
288
278
289
More on [checkpoint sync](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice)
279
290
280
291
## Further reading {#further-reading}
281
292
282
-
There is a lot of information about Ethereum clients on the internet. Here are few resources that might be helpful.
283
-
284
293
-[Ethereum 101 - Part 2 - Understanding Nodes](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a)_– Wil Barnes, 13 February 2019_
285
294
-[Running Ethereum Full Nodes: A Guide for the Barely Motivated](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31)_– Justin Leroux, 7 November 2019_
0 commit comments