Module smoldot::sync

Syncing, short for synchronizing, consists in synchronizing the state of a local chain with the state of the chain contained in other machines, called remotes or sources.

Note: While the above summary is a bit abstract, in practice it is almost always done by exchanging messages through a peer-to-peer network.

There exists multiple syncing strategies, depending on the amount of information that is. desired and the distance between the highest block of the local chain and the highest block available from the syncing sources. The all module provides a state machine that combines several syncing strategies into one.

Security considerations

Eclipse attacks

While there exists various trade-offs between syncing strategies, safety is never part of these trade-offs. All syncing strategies are safe, in the sense that malicious remotes cannot corrupt the state of the local chain.

It is possible, however, for a malicious remote to omit some information, such as the existence of a specific block. If all the remotes that are being synchronized from are malicious and collude to omit the same information, there is no way for the local node to learn this information or even to be aware that it is missing an information. This is called an eclipse attack.

For this reason, it is important to ensure a large number and a good distribution of the sources. In the context of a peer-to-peer network where machines are picked randomly, a minimum threshold of around 7 peers is generally considered acceptable. Similarly, in the context of a peer-to-peer network, it is important to establish outgoing connections to other nodes and not only rely on incoming connections, as there is otherwise the possibility of a single actor controlling all said incoming connections.

Malicious runtimes

Synchronizing the chain requires executing a piece of WebAssembly code known as the runtime. Each chain has a different runtime, stored on chain, and this runtime can be modified as part of a the transactions in a block.

There are two safety considerations concerning executing runtime code:

• The execution could take a lot of time, or possibly be stuck in an infinite loop.
• The execution could modify a lot of storage items. Smoldot needs to store every single storage item change, and a lot of modification could make the memory usage of smoldot explode.

The Substrate model, and thus the smoldot implementation, intentionally do not do anything to address these two safety issues. In other words, the runtime of a chain is considered to never be malicious. After all, a chain whose runtime is intentionally trying to crash a client is borked and there is no reason to connect to it.

Modules

• all
  All syncing strategies grouped together.
• all_forks
  All-forks header and body syncing.
• para
  Parachains and parathreads syncing.
• warp_sync
  Warp syncing.