1703865537
到这里，我们已经讨论了参与者可以发布交易，并将交易纳入区块链，这一切似乎很神奇。事实上，上述整个过程都是通过比特币网络完成的。比特币网络是一个点对点的网络，沿用了很多已有的点对点网络的理念。在比特币网络里，所有的节点都是平等的。没有等级，也没有特殊的节点，或所谓的主节点。它运行在TCP网络上，有一个随意的拓扑结构，每个节点和其他的随机节点相连。新的节点也可以随时加入。可以试着现在就下载比特币节点软件，把你的个人电脑注册为一个节点，这个节点的权限和比特币网络里所有其他节点都是一样的。
1703865538
1703865539
由于随时有新的节点进入，也有旧的节点离开，所以比特币网络事实上一直在变化。并没有强制的规定节点何时明确地离开网络，只要一个节点有3个小时没有音讯，就会慢慢地被其他节点忘记。通过这个方式，网络非常缓和地处理节点下线问题。
1703865540
1703865541
上文提到，每个节点和其他随机节点相连，网络中并不存在一个确定的地理学意义上的拓扑结构。那么一个节点是如何加入网络的呢？当你启动一个新节点的时候，先向一个你知道的节点发送一个简单的消息。这个节点就是你的种子节点，当然，有多种不同的方法可以查找种子节点。然后你就会问你的种子节点是不是还知道其他什么节点？在链接到一个新的节点后，你可以重复这个过程许多次，最后你可以选择和哪些节点相连，这时，你就成为比特币网络里一个完全合格的节点了。这些步骤里有很多随机性，理想的情况就是你能和一些随机组的节点相连。为了加入网络成为网络节点，你只需知道一开始怎么和其中一个节点链接就行了。
1703865542
1703865543
那加入网络到底有什么好处？当然是为了维护区块链。当我们发起一个交易的时候，我们想让整个网络都知道。这是通过一个“泛洪”（flooding）的算法完成的［有时候我们称之为“八卦”（gossip）协议］。如果爱丽丝要转账给鲍勃，她的客户端发起一个交易，然后把这笔交易告知所有和她的客户端节点相链接的其他节点，这些节点会进行一系列核验，决定是否接受并转播这笔交易。如果核验通过，这些节点会将这笔交易信息传播给与其相连的其他节点。当节点接收到一个交易信息后，会把交易放入一个交易池，但需要注意的是，交易池里的交易还没有被打包进区块链。如果节点接收到的交易在交易池里已经存在，就不会再次把它传播出去。这样，就确保了泛洪协议会自动终结，而不是让一个交易在网络一再被传播永不停止。由于每个交易都有一个独一无二的哈希值，所以节点可以非常方便地查询某个交易是否在自己的交易池里。
1703865544
1703865545
节点接收到一个新交易信息时，如何核验呢？这里有四个关卡：第一个也是最重要的一个是交易验证，也就是验证交易在当前的区块链中是有效的，节点会针对每个前序交易的输出运行核验脚本，确保脚本的返回值都为真；第二，检查是否有双重支付；第三，如前文所述，节点会检查这笔交易信息是不是已经被本节点接收过；第四，节点只会接收和传递在白名单上的标准脚本。
1703865546
1703865547
上述所有检查都是合理检查，所有节点很好地执行这些检查能够使网络健康、稳定地运行，但实际上并没有规则强制节点执行这些检查。虽然如此，每个节点还是有必要进行检查的——因为比特币网络是一个点对点的对等网络，任何人都可以随时加入，总有一些节点会发出双重支付，或者非标准脚本的交易，甚至彻底就是非法交易。
1703865548
1703865549
由于网络传递有延迟，不同的节点可能会有不同的交易池。当有双重支付攻击的时候，这个现象会变得十分有意思。假设爱丽丝想把同一个比特币支付给鲍勃与查理，于是，爱丽丝几乎同时发出两笔交易。有些节点先听到爱丽丝→鲍勃交易，有些则先听到爱丽丝→查理交易。当一个节点接收到了这两个交易当中任何一个，它就会把接收到的交易放入交易池中，之后，它听到了另一个交易，看上去像是双重支付交易，这个节点就会把它丢弃掉不再向外传播。结果就是众多的节点会对“哪一个交易应该被纳入区块链”产生分歧。这种情况被称为竞态条件[1]（race condition）。
1703865550
1703865551
好在对于比特币来说，这完全不是问题：打包下一个区块的矿工会打破这个僵局，他会决定哪个交易会最终打包进这个区块。如果爱丽丝→鲍勃的交易进入区块，那些听到爱丽丝→查理的节点会把爱丽丝→查理的交易从交易池里剔除，因为那是一个双重支付；而那些听到爱丽丝→鲍勃的节点也会把这个交易剔除出去，因为这笔交易已经被纳入区块链。因此，一旦这个区块被传播以后，就不再有前面说的分歧了。
1703865552
1703865553
由于每个节点默认保留最早接收到的交易，所以节点在网络上的位置就很重要。如果两个矛盾的交易或区块在网络上两个不同地方被发起，它们会同时向整个网络广播，节点先接收到哪个交易取决于它在网络的位置。
1703865554
1703865555
当然，这基于一个假设：不管接收到什么信息，每个节点均保留最早接收到的交易。但是比特币网络是一个对等的网络，节点并不被强制要求这么做，任何节点都有权按照其他逻辑行事，并按照所选的逻辑决定到底保留哪个交易、转播哪些交易，我们会在第5章的矿工奖励部分讨论这个问题。
1703865556
1703865557
1703865558
零验证交易和费用替代策略(replace-by-fee)
1703865559
1703865560
在第2章我们讨论了零验证交易，即一旦交易在网络中广播，接收方就立即接受交易。零验证交易不是用来防止重复支付的，但由于矿工的缺省行为是把先接收到的交易放入交易池，这样，在零验证交易里就很难实现重复支付，同时，由于零验证交易非常方便，因此变得越来越普及。
1703865561
1703865562
自从2013年，矿工的缺省行为变成了“费用替代策略”, 即节点在遇到有冲突的交易时，会把交易手续费更高的交易放进自己的交易池，把手续费更低的替换出去。站在矿工的角度，由于收益更高，因此也是理性的选择——至少在短期看是这样。但是这种费用替代策略却使多重支付攻击变得更容易了。
1703865563
1703865564
因此，费用替代策略受到了不少争议，这些争议一方面从技术层面讨论在费用替代策略中是否可以真正阻止多重支付；另一方面从哲学层面讨论比特币是不是应该要尽可能支持零验证，或直接放弃费用替代策略。我们这里就不再赘述这些讨论了很久的争议了，但最近比特币核心代码倒选用了“有选择权的”（opt-in）费用替代策略的做法，也就是交易可以标记自己是否适用费用替代策略。
1703865565
1703865566
上面说的是交易的传播。至于区块的传播，即矿工挖到一个矿（打包一个区块），然后将区块加入区块链，这个过程与新交易的传播过程类似，也受同样竞态条件的限制。如果两个有效的区块同时被挖到（也就是有两个矿工同时获得了记账权力时），只有其中一个区块可以进入长期共识链，哪个区块被最终纳入长期共识链取决于其他节点选择在哪个区块上扩展区块链，未被纳入的一个即被丢弃。
1703865567
1703865568
核验一个区块要比核验一个交易复杂得多。除了确认区块头部，确定里面的哈希值是在可以接受的范围内，节点还必须确认区块里的每个交易。最后，一个节点往外传播的区块必须是最长的一条区块链上新加入的区块（当然，“最长的区块链”取决于节点对区块链当前状态的认识）。只有这样才可以防止区块链分叉。但就像传播交易时一样，节点同样可以执行它自己的逻辑：它可以选择传递无效的区块，也可以选择传递在共识链上更早加入的区块而不是最新加入的区块。这样就会造成一个分叉，不过这种情况是协议可以承受的。
1703865569
1703865570
泛洪算法（flooding algorithm）的延迟情况到底怎样呢？我们一起看一下图3.9，这张图展示了区块被网络中不同数量的节点接收所花费的时间（秒）。三条线分别代表区块被网络中25%、50%、75%的节点接收到所需要的时间。可以看到，由于网络带宽的限制，比较大的区块需要30秒左右才能传播到大部分的节点。所以这个协议不是很有效率。在互联网上30秒是比较长的时间了，在比特币的设计里，简便是第一位的（简单的网络、节点可随时加入或退出），而效率是第二位的，所以在比特币网络里，一个区块可能需要经过很多节点才到达最远的节点。如果网络采取自上而下的设计，那我们就需要使任何两个节点的距离都很短。
1703865571
1703865572
网络大小
1703865573
1703865574
比特币网络大小很难测量，因为它随时都在变化，而且没有一个中央权威机构。有些人通过研究给了一些估计：往高说，每个月可能有100万个IP地址成为比特币网络的节点（也可能是临时成为节点）。往低说，大约只有5 000~10 000节点永远在线并处理交易。这个数字有点出乎意料得小，但是截至本书完成时，并没有证据表明永远在线的节点数量在升高或降低。
1703865575
1703865576
1703865577
1703865578
1703865579
图3.9 区块传播时间
1703865580
1703865581
注：展示了区块被网络中不同数量（百分比）的节点接受所花费的时间。
1703865582
1703865583
资料来源: Yonatan Sompolinsky和Aviv Zohar, 加快比特币交易的传播速度 (Accelerating Bitcoin’s Transaction Processing,2014)。可从下述网址获得https://eprint.iacr.org/2013/881。数据由Yonatan Sompolinsky和Aviv Zohar授权使用
1703865584
1703865585
存储空间需求
1703865586