🤔 Need blocks and a snapshot? Use the bundle API to always get the latest compatible backups.
|snap_wax_2019-07-16-07-30.tar.gz||Wasabi S3||2.68 MiB||8b37f0711c2d5cfadcc8576b671dabb0|
|snap_wax_2019-07-16-06-30.tar.gz||Wasabi S3||2.67 MiB||a8ff34861d26a1dce75938e57411a390|
|snap_wax_2019-07-16-05-30.tar.gz||Wasabi S3||2.67 MiB||fbee146594bb41c1115c907ff192c16e|
|snap_wax_2019-07-16-04-30.tar.gz||Wasabi S3||2.67 MiB||edb21110f53a6c549ca109c73e53c829|
|snap_wax_2019-07-16-03-30.tar.gz||Wasabi S3||2.67 MiB||4077015b449897e9ca3d824fef4edbc6|
|snap_wax_2019-07-16-02-30.tar.gz||Wasabi S3||2.67 MiB||cbcb553bcc08501e8ae390f4968e1984|
|snap_wax_2019-07-16-01-30.tar.gz||Wasabi S3||2.67 MiB||d7631a181453dec3733f198b4a098011|
|snap_wax_2019-07-16-00-30.tar.gz||Wasabi S3||2.66 MiB||5775f5e1fbb2d4b0555aea3be2517d54|
|snap_wax_2019-07-15-23-30.tar.gz||Wasabi S3||2.65 MiB||deb0e903b3f644ff6ffca2b55124a36e|
|snap_wax_2019-07-15-22-30.tar.gz||Wasabi S3||2.65 MiB||129dee5d906f0f4775ae92514bd40fbf|
|snap_wax_2019-07-15-21-30.tar.gz||Wasabi S3||2.65 MiB||42a7b3f69fc7aecfe1f1a03da4a5edea|
These snapshots are platform agnostic and taken from our own cluster of API nodes.
They can be used with or without a blocks log.
This is a great way to get synced to the network within a minute, you can see the original notes on Github. There are a couple of points to be aware of:
- The snapshots contain all the consensus state required to bootstrap a node at a given head block, so there's no need for long replays to build
statefrom the blocks log.
- This sync method is intended for producing nodes, however if you don't intend on supporting history data, it will work perfectly for API/full nodes.
What's The Catch?
After being accustomed to long replay times via Block backups, the near instant snapshot sync seems like magic. But the magic comes at a cost:
- If you want to support retrospective chain data via the RPC API or P2P, then you must provide a blocks log that contains blocks up to the snapshotted block. The blocks log may contain additional blocks, they will be applied as part of the startup process.
- These snapshots do not support any plugins, so this doesn't support history data.
How To Use
First, you must do some preparation. Remove the
state directory if it exists, then you need to make a decision. If you want to support old chain data, then you must have a
blocks directory with a block log containing data up to, or past the head block referenced in the snapshot.
Download the snapshot, uncompress it and start
nodeos with the
snapshot flag pointing to the absolute location of the fresh snapshot.
You can use the one-liner in the example to always download the latest snapshot. We also have a Snapshots API which orders the archives in chronological order, newest first.
# Move to your local wax directory, removing the existing state directory (if relevant) cd /opt/wax rm -rf state # Download the latest snapshot wget $(wget --quiet "https://eosnode.tools/api/snapshots?network=wax&limit=1" -O- | jq -r '.data.s3') -O snapshot.tar.gz # Uncompress tar xvzf snapshot.tar.gz # Start the chain and sync from the provided snapshot ./start.sh --snapshot "$(ls -t snapshots/*.bin | head -n1)" # Tail the logs to watch the sync in all its glory tail -f log.txt