<p>A full node needs to process all blocks in order to establish which &quot;coins&quot; (UTXOs) exist without having to trust anyone</p>
<p>The getblocks and inv messages are an efficient way to do this.</p>

CC BY-SA 4.0
2022-04-30T12:30:03.423Z
2022-04-30T12:30:03.423Z
RedGrittyBrick
<p>It seems there are two questions here.</p>
<ul>
<li><p><strong>Why do nodes need to download all historical blocks?</strong> Fully-validating nodes must learn the full state of the ledger (&quot;who owns what/how much currently&quot;) that resulted from all previous transactions before they can validate new ones. The only way to learn this, without trusting any other third party to just tell them, and be convinced the result is correct, is by actually going over that entire history and seeing that every transaction they're told about checks out.</p>
</li>
<li><p><strong>Why does the block download mechanism involve so many back-and-forth messages?</strong> That's just how the download protocol works. Some of the complexity is due to permitting block download to operate in parallel from multiple peers simultaneously, and other complexity is due to trying to prevent being sent blocks by malicious peers which later turn out to not be in the best chain, and thus constitute wasted effort. To combat that, nodes will first download and validate block headers (which is fast and cheap), and then fetch blocks along those validated headers.</p>
</li>
</ul>

CC BY-SA 4.0
2022-04-30T15:24:30.450Z
2022-04-30T15:24:30.450Z
Pieter Wuille
<p>My understanding of updating a node's incomplete blockchain is that:</p>
<p>A node with an incomplete blockchain (let's say its been offline for some time) will send a <em>getblocks</em> message and then will receive an <em>inv</em> response with the latest 500 blocks from the most updated machine.</p>
<p><strong>What I don't understand is that when you originally set up a full-node, it is downloading blocks from the network and adding them successively starting from the genesis block (which is encoded into the full-node's client software). So why can't it download the latest block from the network rather than sending many messages.</strong> &lt;-- Or is this understanding blatantly wrong - that is, new full-nodes are not downloading blocks from the network.</p>

<synchronization>
Why Don't Nodes Download Blocks off the network directly instead of sending various messages to other nodes?
Jamo
# Why Don't Nodes Download Blocks off the network directly instead of sending various messages to other nodes?

(Asked by: username_0 on 2022-04-30)

My understanding of updating a node's incomplete blockchain is that:

A node with an incomplete blockchain (let's say its been offline for some time) will send a *getblocks* message and then will receive an *inv* response with the latest 500 blocks from the most updated machine.

**What I don't understand is that when you originally set up a full-node, it is downloading blocks from the network and adding them successively starting from the genesis block (which is encoded into the full-node's client software). So why can't it download the latest block from the network rather than sending many messages.** <-- Or is this understanding blatantly wrong - that is, new full-nodes are not downloading blocks from the network.

**Tags:** synchronization


---

## 2 answers

### Answer by username_1 on 2022-04-30. Score: 1

A full node needs to process all blocks in order to establish which "coins" (UTXOs) exist without having to trust anyone

The getblocks and inv messages are an efficient way to do this.


---

### Answer by username_2 on 2022-04-30. Score: 0

It seems there are two questions here.

* **Why do nodes need to download all historical blocks?** Fully-validating nodes must learn the full state of the ledger ("who owns what/how much currently") that resulted from all previous transactions before they can validate new ones. The only way to learn this, without trusting any other third party to just tell them, and be convinced the result is correct, is by actually going over that entire history and seeing that every transaction they're told about checks out.
* **Why does the block download mechanism involve so many back-and-forth messages?** That's just how the download protocol works. Some of the complexity is due to permitting block download to operate in parallel from multiple peers simultaneously, and other complexity is due to trying to prevent being sent blocks by malicious peers which later turn out to not be in the best chain, and thus constitute wasted effort. To combat that, nodes will first download and validate block headers (which is fast and cheap), and then fetch blocks along those validated headers.


---

