We have released BPX Beacon Client 3.1.0 beta 1 and Execution Client 1.1.0 beta 1. This release introduces some major changes in the synchronization of both clients.
💾 Download BPX Beacon Client 3.1.0 beta 1:
https://github.com/bpx-network/bpx-beacon-client/releases
💾 Download BPX Execution Client 1.1.0 beta 1:
https://github.com/bpx-network/bpx-execution-client/releases
Beacon Client: Optimistic import
Optimistic import allows the beacon client (BC) to import, process, and consider a beacon block for its head, even though execution client (EC) has not validated its execution payload. Thus, syncing this block optimistically hoping that the block will be eventually validated by the EC.
Optimistic import was devised to enable the EC syncing mechanism called snap sync by which they download a snapshot of the current state from their P2P network, and then proceed to download backwards the blocks and transactions filling its history.
Optimistic import is only used until the EC reaches full synchronization. After catching the head of the execution chain, subsequent blocks are fully validated as before. Nodes are not allowed to farm or validate unfinished blocks while they are still ‘optimistic’ because they can’t yet guarantee their view of the head of the chain is correct.
In the latest beta version, optimistic import is enabled by default, but it is possible to disable it in the config. This causes BC synchronization to be interrupted until EC synchronization is complete.
Execution Client: Snap syncing
BPX has been launched with support for full block-by-block synchronization only. Release 1.1.0 beta 1 enables snap syncing and uses it as default sync mode.
Instead of starting from the genesis block and processing all the transactions that ever occurred (which could take weeks), snap sync downloads the blocks from execution clients P2P network assuming state transitions to be correct. Downloading all the blocks is a straightforward and fast procedure and will relatively quickly reassemble the entire chain.
Many people assume that because they have the blocks, they are in sync. Unfortunately this is not the case. Since no transaction was executed, we do not have any account state available (e.g. balances, nonces, smart contract code, and data). These need to be downloaded separately and cross-checked with the latest blocks. This phase is called the state trie download phase. Snap sync tries to expedite this process by downloading contiguous chunks of state data, instead of doing so one-by-one, as in previous synchronization method. EC downloads the leaves of the trie without the intermediate nodes that connect the leaves to the root. The full trie is regenerated locally. However, while this is happening, the blockchain is progressing, meaning some of the regenerated state trie becomes invalid. Therefore, there is also a healing phase that corrects any errors in the state trie. The state sync has to progress faster than the chain growth otherwise it will never finish.
A node that is using snap sync will switch to block-by-block sync once it has caught up to the head of the chain. The block header to sync up to is provided by the beacon client. Snap syncing is about 10 times faster than before.
Future plans
Thanks to the introduction of optimistic import and snap syncing, we expect that beacon client full synchronization will no longer be needed in the nearest future. BC will be able to sync using some lightweight protocol. Freshly installed beacon client will be fully synchronized in under 2 minutes, regardless of the blockchain size. On the other hand, snap synchronization for the EC will take much longer. Until the EC catches up on head, the BC may continue to import and keep syncing the beacon chain in optimistic mode.
Is there a guide on how to move our coins and prepare for the shut down of V2?