1703865592
1703865593
1703865594
图3.10 区块链的大小
1703865595
1703865596
注：全节点必须保持整个区块链，在2015年年底，区块链大小在50GB以上。
1703865597
1703865598
轻量节点
1703865599
1703865600
除了完全有效节点之外，还有一种轻量节点(nightweight nodes)，或者称为轻客户端，也叫简单付款验证（Simple Payment Verification，简称SPV）客户端。事实上，在比特币系统里的大部分节点都是轻量节点。这些节点不会存储整个比特币区块链，它们只存储它们所关心的、需要进行核验的部分交易。如果你使用一个钱包软件，那里面就会有一个SPV节点，这个节点只会下载向你的账户付款的交易及区块头部。
1703865601
1703865602
一个SPV节点的安全等级远不如全节点。它可以核验那些很难被挖到的区块——因为它有区块头部数据，但它不能核验一个区块里所有交易记录的有效性——因为它没有所有的交易历史记录，也没有那些未被消费的比特币的列表。SPV节点只验证那些和它们相关的交易，所以它们必须依赖那些全节点去验证网络上的其他所有交易。这虽然是一种安全性上的妥协，却不是个坏主意：轻量节点依赖全节点去处理那些比较难的工作，但当某个区块由于某些原因未被矿工挖出来时（挖矿成本巨大），这些轻量节点也会做一些核验来确保这个区块不会被拒绝。
1703865603
1703865604
作为一个SPV节点可以节省很多资源。区块头部的大小只是整个区块链的千分之一。所以轻量节点不需要几十G的存储空间，只需要几十MB即可，即使一部智能手机也能成为比特币网络的轻量节点。
1703865605
1703865606
比特币是一个开源协议，比特币网络一定是由实现方式各不相同的软件系统在无缝交互。这样，即使有些软件系统有缺陷，也不至于使整个比特币网络瘫痪。比较好的现象是，人们用不同的语言不断地重新实现协议，有些人用C++、有些人用Go语言，还有不少人用其他语言。不好的现象是，绝大部分的节点都会调用比特币官方客户端的资源库（bitcoind library），这个库是比特币核心代码开发者们用C++开发的库，而且有些节点用的是过时的版本。所以，即使在同一时间，大家运行的客户端都略有不同。
1703865607
1703865608
[1]竞态条件也可理解为紊乱情况。——译者注
1703865609
1703865610
1703865611
1703865612
1703865614
区块链技术驱动金融：数字货币与智能合约技术 3.6 限制与优化
1703865615
1703865616
最后我们要谈一下比特币协议的一些内在限制，以及优化的难度。在比特币2009年刚问世的时候，它的协议有许多内在的硬性限制，那是因为在那时没有人会想到它会发展成一个重要的国际货币。比如每个区块的平均时间、块的大小、每个区块的签名数目、切分性、比特币总量、区块奖励结构等。
1703865617
1703865618
比特币的总体数量与记账奖励很可能永远都不会改变，因为那样经济影响太大。矿工与投资人都在比特币现有的框架内投入巨资，如果这个框架改变了，会对他们产生巨大冲击。所以，社区基本达成共识，不管这些特性好或不好，都不应该改变。
1703865619
1703865620
但其他一些方面的改善可以让所有人受益——因为一些初始设计事后来看确实不太合理。其中最主要的是比特币系统的交易处理能力。每秒钟比特币网络到底可以处理多少交易？这个硬伤来自对区块大小的硬性规定，每个区块大小限定在1MB，每个交易大约是250字节，所以每块最多容纳4 000个交易。平均每隔10分钟，有一个矿工获得记账权利，所以每秒钟只能处理7个交易，这就是比特币网络的交易处理能力！似乎改掉这些限制只是需要改掉源代码的某些常数这么简单，实际上却并不容易，后面我们会简单分析一下原因。
1703865621
1703865622
比特币的交易处理能力到底属于什么水平？和前主流的一些信用卡公司相比，比特币这个处理能力实在太低了。我们可以做一下比较：维萨（Visa）平均每秒处理2 000笔交易，峰值每秒处理10 000笔交易。贝宝（PayPal）的交易处理能力比维萨弱，但峰值时每秒也能处理100笔交易。比特币无法处理这种量级的交易。
1703865623
1703865624
另一个限制是比特币用的密码算法。现在只有几个哈希函数算法和一个签名算法可以使用。比特币使用的签名算法是ESDSA——一种secp256k1的椭圆曲线数字签名算法（见第1章），大家担心在比特币的一生（大家都希望是很长的一生）中，这个算法可能会被攻破。哈希函数也有同样的问题，比特币使用的SHA-1也有弱点，进10年来，对SHA-1的分析也逐步取得了一些进展（尽管并不致命）。为了改变这些问题，我们不得不加强比特币的脚本语言来支持新的密码算法。
1703865625
1703865626
修订协议
1703865627
1703865628
那我们到底怎样才能修订比特币协议并引入一些新特性呢？你也许认为这很简单，只要发布一个新版本，然后更新所有的节点。但事实上非常复杂，实际中，我们根本无法假定所有的节点都会更新版本。网络里的某些节点会无法获取新版本，或无法及时获取新版本。绝大多数节点更新了协议、部分节点没有更新的后果是否严重，取决于协议更新的内容。按照产生的结果，协议修订可以分为两种类型：一种会造成硬分叉，另一种会造成软分叉。
1703865629
1703865630
硬分叉
1703865631
1703865632
通过修订协议引入新的特性，可能会使前一版本的协议失效。即运行新版协议的节点认定为有效的区块，会被运行旧版协议的节点认定为无效。而由于我们不能确保每个节点都会更新协议，我们只能假定大部分节点已经升级（新节点），但还有部分节点没有升级（老节点），很快，最长的那个区块链分支里包含的某些区块会被老节点认定为无效区块，因此，老节点会认为其他的分支（在这个分支中，所有新节点认为有效的区块都会被排除在外）才是最长、有效的区块链分支，并一直扩展这个分支，直到它们更新了版本。
1703865633
1703865634
这种改变称为硬分叉，它使得原先的链分裂了。网络上的所有节点会根据其所运行的协议版本去扩展两条不同的区块链，当然，这两个分叉再也不会合并。那些老节点只要不更新版本，就被永远地排除在了另一条链之外，这是比特币社区所不能接受的。
1703865635
1703865636
软分叉
1703865637
1703865638
另一种修订是加入新的特性，让现有的核验规则更加严格。那样老的节点依然会接收所有的区块，而新的节点会拒绝一些。这样的改变叫作“软分叉”。这可以避免硬分叉所造成的永久分裂。
1703865639
1703865640
我们如果引入可以产生软分叉的新版协议，会有什么后果呢？运行新版协议的节点会使用一些更严格的规则，现在，假定绝大部分节点都更新了新版协议并执行新的规则（这是产生软分叉的关键，因为老节点不会执行新规则，新节点的数量要足够多才能够竞争最长的链）。这种情况下，老节点可能会挖到一些无效的区块——因为这些区块中包含一些在新规则下无法核验通过的交易，然后，老节点会知道它们核验有效的区块不被别的节点接受（即使它们并不知道原因），这使得老节点的矿工会去更新协议。而且，如果新节点用它们的区块扩展了老节点的分支，那么，老节点也会转而扩展这个分支，原因是新节点核验通过的区块，老节点也必定能核验通过。这样就没有硬分叉了，只是会有很多临时的小型分叉而已。
1703865641
[
上一页 ]
[ :1.703865592e+09 ]
[
下一页 ]