...by Daniel Szego
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego

Friday, August 17, 2018

Syncing Blockchain from a certain block or time

At blockchain synchronization one of the biggest problem is that the full blockchain has to be synchronized and validated from the genesis block. Supposing we have an UTXO based system, it is actually necessary, because there might be UTXO-s which are at the beginning of the chain, but despite they can be spent. We could however consider with an account-balance based system not to download and validate the whole blockhchain just like the last thousand blocks, as the correct state is contained at the last state as well all the other blocks are related only a a consistency and security guarantee. Such an algorithm might have raise the following issues:
- Depending on the consensus mechanism downloading the last thousand block can be as much secure as downloading everything from the genesis block. In proof of work a long range attack from a thousands block in the past is as much impossible as doing a long range attack from the beginning. Similar might be true for proof of stake and other consensus algorithms as well. 
-  The real challenge is however to get the quasi genesis block in a reliable way. Certainly getting thousands blocks that are fake are not necessarily simple, but an attacker could simply send an older version of the chain fragment, let we call it as a replay blockchain fragment attack.      
- To prevent a replay blockchain fragment attack, we can introduce a the block numbers in the block headers. So, first step of the P2P algorithm would be to query the block heights, and bases on the block heights, the blocks with the exact numbers can be queried.
- However, there might be one more attack vector. Even if we have block identity information in the block headers, and attacker might try to build up a blokchcain segment in the future, knowing simply the block id-s and broadcast this fake segment as soon the blocks from the certain id are queried. Let we call this attack as alternative future blockchain fragement attack. There is no known good to implement a chain resolution strategy that can efficiently distinguish between the valid chain and an alternative future.