Where precisely lies the trust in a snapshot?

Question

Nomadic Labs recently introduced the concept of snapshot as a way to speed-up the syncing of new tezos nodes.

It is mentionned several times that there exists a certain minimal amount of trust that cannot be removed while using snapshot to sync. What i would like to understand is

• what exactly needs to be trusted in a snapshot ?
• in which manner a snapshot could be malicious ?
• does the new node do more than just checking the hash of the last block ?

Thanks a lot!

Answer 1

Here is how the import works for you:

• you download a snapshot from a usb key found in a dark alley
• you start importing it, it displays the block hash it is importing
• you check in several places that this hash is indeed from the main chain
• if it checks up, you let it continue

Here is what the snapshot must contain (full variant):

• the current state of the ledger (balances, staking rights, etc.)
• the block header and operations of the whole chain

Here is how it is read and checked (not necessarily in order):

• the block headers are hashed locally, and since each block header contains the hash of its predecessor, the import procedure makes sure that all the headers included in the snapshot form a chain that starts at the imported block, and ends up at the expected genesis of mainnet
• the operations of each block are hashed, and the resulting lists of operation hashes are compared to the ones included in the imported block headers
• the context is imported, key by key, and the hashes of each key are recomputed locally
• the global hash of the context, which includes the hashes of all the keys, is computed, and the import procedure makes sure that it matches the hash written in the block header of the predecessor
• the current protocol is retrieved by reading a specific key in the context, so it is checked too as it is part of the context hash
• finally, to get some values that are the result of applying each block, such as the current lifetime of operations, and that are not included in the context, a single block application (using the protocol gathered above) is performed to get these values, and the resulting context hash is also checked

To validate new blocks after that, what the node needs is the context at that block, a few result values from the last block application, and a few block headers and operations from the past, all of which we've just shown to have been checked.

TL;DR: Hashes containing hashes that contain other hashes containing even more hashes, and that up to the genesis block, and up to each and every entry in the context, plus just a single run of block validation to make really sure. It is up to YOU to check the first hash of the series on more than one website or node, and then the import procedure does the rest.

Answer 2

The trust relies in two elements:

1. the hash of the last block in the snapshot (is it really on the official chain ?)
2. the source code of your node (is it really doing what you think it does ?)

For (1), you have to check multiple trusted sources. You can check on TzScan or another block explorer that the hash is in the main chain. You can also directly query public nodes.

Then, if the hash is correct, your node will automatically validate all the data in the snapshot, as it would do if the blocks were coming from other nodes on the network. So, if you trust the source code of your node, everything should be checked, and any invalid data would be discarded.

By validation, I mean:

1. Check that the context hash is the one expected (the context is stored in a Merkle tree computing a global hash of the context)
2. Apply each block in the snapshot in turn, i.e. apply the transactions and other operations on the previous context to compute the new context. Check that the generated context has the same hash as in the block.