This blog post first cuts to the chase and describes how to use blockchain snapshots, then describes what snapshots are, and finally explains their benefits and caveats.
Using a Snapshot
We have made it very easy to use blockchain snapshots to synchronize a Stealth client. The following information is presented in more detail at the Stealth snapshot wiki page.
- Download or update your copy of the Stealth client source directory.
- Build the client.
- Stop the current client if it's running.
- Run the command download-stealth-snapshot.
- Start the client.
The magic here is the command download-stealth-snapshot that takes care of downloading the snapshot archive, verifying it, unpacking it to the right location, and preparing the Stealth data directory. Again, see the Stealth snapshot wiki page for the exact instructions.
Advisory for StealthExplore API Endpoints
If you don't understand the title of this section, you can skip it.
For those who run the StealthExplore API, the current version of the snapshot does not have StealthExplore API information. We plan to have separate snapshots for the StealthExplore API in the future.
Until then, bringing up a StealthExplore API endpoint with a snapshot is simply a matter of adding a line to the StealthCoin.conf file: "reindexexplore=1".
Don't forget to remove this line after you restart with the snapshot, or you will have to wait for the client to reindex the StealthExplore on the next restart.
What Is a Snapshot?
In short, a snapshot contains the minimal files to run a full Stealth client without waiting for block verification or processing. A snapshot has all the block information from the genesis block to a recent block. From this recent block, the Stealth client downloads any blocks newer than the snapshot. This method is much faster than downloading blocks starting from Block 1 and verifying each one. In other words, snapshot blocks are treated as if they are valid, without any processing.
A snapshot includes all the blockchain data as a flat file database, where the raw data for each block is laid out sequentially. In other words, Block 0 (genesis) is first in the file, then Block 1, etc., in the order these blocks were created and added to the blockchain. For the curious, these files are called "blk0001.dat", "blk0002.dat", and so on. Collectively these blocks are called "blkNNNN.dat" files.
Additionally, a snapshot contains information that facilitates quick retrieval of arbitrary block data from the disk drive. This information takes the form of data structures called "block indices" and "transaction indices". Files that contain this information reside in a directory called "txleveldb", and are collectively called "the transaction database" (which is somewhat of a misnomer because it contains general block information as well).
Without the transaction database, retrieving blockchain data would take so much time that the blockchain itself wouldn't be usable.
How Is a Snapshot Different from a Bootstrap?
A bootstrap is like a snapshot, except a bootstrap doesn't have the transaction database. When bootstrapping, each block is read, in order, from a single-line flat file database called "bootstrap.dat". Each block is sequentially validated, written to the "blkNNNN.dat" files, and indexed in the transaction database ("txleveldb"), which is created during bootstrapping.
For a blockchain as large as Stealth's, with its nearly 34 million blocks, bootstrapping can take about a week, or longer.
Pros and Cons of Snapshots
There are three different ways to synchronize a Stealth client:
- Download blocks from peers (other Stealth clients).
- Bootstrap.
- Use a snapshot.
Downloading a blockchain from peers is perfectly valid and requires little interaction from the user, but is somewhat slower than a bootstrap. It also involves validating every block and transaction in the blockchain.
Bootstrapping requires a little more interaction from the user in that the user must download the bootstrap and unpack it in the Stealth data directory. Bootstrapping is a little faster than synchronizing from the network. Another advantage is that it creates a very clean blockchain database in that there is no chance that any non-main chain blocks will be included in the client's database. Like synchronizing from the network, bootstrapping involves the validation and processing of every block in the blockchain.
In contrast to synchronizing from peers and bootstrapping, using a snapshot is very fast. In essence, the client's blockchain database is already synchronized up to the newest block contained by the snapshot. Additionally, Stealth snapshots are prepared such that they are clean of any extra data (non-main chain blocks), and are perfectly organized (where all the blocks are stored in sequential order).
Snapshot Caveat
The only caveat of snapshots is that the blockchain data contained therein is not validated by the client using the snapshot, meaning the snapshot is assumed to represent the correct blockchain. This situation introduces an element of trust into an otherwise trustless system, and for some users any trust is understandably a deal breaker. These users are encouraged to bootstrap or synchronize from the network.
Cryptographic Verification
While validation of the block data is not part of using a snapshot, Stealth snapshots can be verified as authentic using cryptographic signatures. This type of authentication is provided by the download-stealth-snapshot script, which employs Gnu Privacy Guard (GPG). This authentication verifies that the Stealth team published the snapshot.
The fingerprint of the signing key is 332282A12DD6124BCBEBD27BC0D62C36BBFB97D1, and has been submitted to these key servers:
More technical details about cryptographic verification of the snapshot is in the README file downloaded by the download-stealth-snapshot script.