Once a full node connects to peers, firstly it will try to construct blockchain fully. If it is a completely new node and has no blockchain at all from the previous, it only knows one block, called the genesis block, which is statically embedded in the client software. Starting with block #0 (the initial block), the genesis block, the new node will have to download many many (almost thousands) blocks to synchronize with the network and re-establish the full block‐ chain. The process of ‘syncing’ the blockchain starts with a message called version message, as that contains a node’s current blockchain height (number of blocks). This height is called as BestHeight. A node will check the version messages from its peers, know how many blocks they
…show more content…
Hence it deduces that its own local blockchain is longer than its peer’s. The peer that has the longer blockchain has more blocks than the other node. They can identify which blocks the other node needs in order to ‘catch up’. It will identify the first 500 blocks to share and transmit their hashes using an inv (inventory) message. The node missing these blocks will then retrieve them, by issuing a series of getdata(another special message) messages requesting the full block data and identifying the requested blocks using the hashes from the inv message. Let’s assume for example that a node only has the genesis block. It will then receive an inv message from its peers containing the hashes of the next 500 blocks in the chain. It will start requesting blocks from all of its connected peers. It requests for spreading the load and en‐ suring that it doesn’t overwhelm any peer with requests. The node keeps track of how many blocks are ‘in transit’ per peer connection, meaning blocks that it has requested but not received, checking that it does not exceed a limit (MAX_BLOCKS_IN_TRANS‐
Hence it deduces that its own local blockchain is longer than its peer’s. The peer that has the longer blockchain has more blocks than the other node. They can identify which blocks the other node needs in order to ‘catch up’. It will identify the first 500 blocks to share and transmit their hashes using an inv (inventory) message. The node missing these blocks will then retrieve them, by issuing a series of getdata(another special message) messages requesting the full block data and identifying the requested blocks using the hashes from the inv message. Let’s assume for example that a node only has the genesis block. It will then receive an inv message from its peers containing the hashes of the next 500 blocks in the chain. It will start requesting blocks from all of its connected peers. It requests for spreading the load and en‐ suring that it doesn’t overwhelm any peer with requests. The node keeps track of how many blocks are ‘in transit’ per peer connection, meaning blocks that it has requested but not received, checking that it does not exceed a limit (MAX_BLOCKS_IN_TRANS‐