干货 | 深入探索比特币的安全模型（上）
另外，每个区块链系统都将创世块硬编码到了节点软件中。你可能会觉得，“共享历史” （即，账本）是一种社会契约 —— 一旦某个区块的历史足够悠久，网络中的所有参与者之间都会达成共识，认为这个区块永远都不会被回滚。当开发者选定一个早期挖出的区块并用它来创建检查点时，更多是作为一种公认的完整性检查，而非对历史的客观描述。
除了检查点之外，节点如何实现自引导也是一个问题。目前，比特币节点的自引导流程是检查节点是否在本地存储了之前从对等节点那里了解到的数据。如果没有的话，节点将查询一组被硬编码到软件中的 “DNS 种子”。这些种子负责维护一个连接良好的比特币节点的列表，并将这个列表返回给你的节点。
正如我们可以从代码中看到的那样，Bitcoin Core 0.13 目前使用由 Pieter Wuille、Matt Corallo、Luke Dashjr、Christian Decker、Jeff Garzik 和 Jonas Schnelli 运行的 DNS 种子。任何人都可以使用 Pieter Wuille 的比特币种子生成器软件或 Matt Corallo 的软件来运行 DNS 种子。但是，他们必须说服某个全节点实现的开发者将他们的 DNS 种子主机添加至对方的软件。
新节点的引导过程仅仅依赖 6 个 DNS 种子，这看似又是一个极端中心化的单点问题。但是别忘了，比特币的安全模型只需要你连接到一个诚实的对等节点，就足以抵御女巫攻击。
因此，一个新的节点只需能够连接到一个没有遭受攻击的 DNS 种子即可，这个种子会返回诚实节点的 IP 地址。但是，为了防范所有 DNS 节点因某种原因全都无法访问的情况，还有一个备用方案 —— 一个被硬编码到软件中的可靠节点 IP 地址的列表，会随着每个新版本发布而更新。
在围绕这些初始化参数构建的安全模型下，全节点运营者不需要信任 X 个 DNS 种子或 Y 个 Bitcoin Core 软件开发者会向他们提供真实的数据，只需要相信有 1/X 的 DNS 节点没有遭受攻击，或 1/Y 的 Bitcoin Core 软件开发者会诚实地审查被硬编码的对等节点更改的有效性即可。
从更深层次来看，你在运行一个全节点时，会在一定程度上信任你正在运行的硬件和软件。
你可以采用多种方法将你的二进制文件的签名与 van der Laan 的进行核对，以此验证软件是否可靠，但是很少会有人愿意惹这个麻烦。至于如何验证硬件的可靠性，这是个棘手的问题。如果你需要一个安全的硬件解决方案，最接近的选择是 ORWL。如果有人试图篡改 ORWL，会触发它的 “自毁” 机制。
但是，由于 CPU、RAM 等重要硬件通常都是专有的，你永远也无法 100% 确定它们不会遭到入侵。
当你开始研究比特币系统中不同参与者之间的关系时，会发现自己如坠五里雾中。
运行全节点的目的是保护你的金融主权。这就意味着，一旦你安装并运行了特定版本的软件，即表明你与该软件以及其他所有网络参与者都达成了一项协议 —— 不仅你会遵守该软件的规则，而且其他网络参与者也必须遵守这些规则。
因此，如果人们想要对软件的规则做出无法向后兼容的更改，你必须运行新版本的软件来表示你明确同意这些规则更改。另一方面，如果是向后兼容的规则更改，即使你不同意，也可以在网络中实行。
有人高度概括了比特币内部的分权制衡：
比特币治理的三大权力部门：
全节点（可以否决矿工和开发者）
矿工（可以否决开发者）
开发者（可以帮助其他人绕开某些否决）
需要注意的是，全节点软件不会自动更新，这是设计使然。自动更新会导致权力的天平向开发者倾斜，让开发者可以在未经节点和矿工许可的情况下强制更改规则。
可惜的是，虽然规则更改在技术层面上有可能是向后兼容的，但是多年来的经验告诉我们足够有创意的软分叉也是可以实现违背旧版本规则的更改的。例如，Vitalik Buterin 曾经提过这样一个设想：通过软分叉将比特币的区块时间从 10 分钟缩短到 2 分钟，这必然会加快比特币的发行速度。
面对不喜欢的软分叉，全节点有一张王牌：利用硬分叉与其他支持软分叉的矿工划清界限。这（在设计上）执行起来很难，而且引发了关于如何衡量共识和找到经济比重高的节点等诸多问题。
从技术上来说，这种硬分叉可以通过将挖矿算法从双 SHA256 改成另一种哈希函数来实现。一旦成功，所有 SHA256 ASIC 矿机将无法用来挖比特币。因此，节点运营者应该时刻警惕比特币生态中发生的变化，并提醒矿工越权会有被取代的风险。
许多博弈论都会讨论矿工操作及其对比特币安全性的威胁，我在之前的文章中推测了挖矿生态可能会发生怎样的变化。虽然比特币挖矿的中心化程度不尽如人意，但是迄今为止依然运作良好。这是因为比特币矿工投入了大量资金，他们不会冒着巨大的损失在一个受到所有人监视的系统中作恶。
很多比特币用户使用轻量级客户端而非全节点访问网络，因为前者需要消耗的资源要少得多，但依然能够提供很强的安全性。
使用简易支付验证（SPV）的客户端会下载整条链上所有区块的区块头的完整副本。这就意味着，自比特币诞生以来，下载和存储需求会随时间的推移呈线性增长。详情见比特币白皮书的第 8 节。
中本聪在白皮书中写道，SPV 客户端 “无法自行验证交易，但是通过把交易与区块链关联起来，它可以看到网络中的节点已经接受了该交易，随着越来越多区块上链，则进一步证实网络已经接受了该交易”。SPV 假设经过 X 个区块确认后的交易伪造成本极高。
SPV 看似具备堪比全节点的安全性，但是它引入了额外的假设：只要一个区块的区块头和工作量证明有效，它包含的所有交易也都是有效的。因为 SPV 客户端不会验证本文第 1 节中提到的所有共识规则，所以它们假设响应交易查询请求的节点已经验证过了共识规则。
另一个较小的安全性差异在于对等节点有可能向你隐瞒信息。如果你运行了一个全节点，对等节点可以向你隐瞒未确认的交易和区块。但是，一旦你从对等节点那里获得了一个区块，就没人可以向你隐瞒这个区块中的任何交易。另一方面，如果你运行的是 SPV 客户端，对等节点有可能向你提供区块头，然后隐瞒对应区块中的交易信息。
SPV 客户端可以查询某个地址的相关交易。尽管对等节点使用虚假交易来 SPV 客户端会付出很高的代价（需要挖出一个带有充分 PoW 的区块），但是它们可以谎称 SPV 客户端用来查询交易的布隆过滤器（bloom filter）没有结果。另外还要注意的一点是，由于布隆过滤器的缺陷，SPV 在隐私性上遭受了严重破坏。
BitcoinJ 在一篇文章中很好地阐述了 SPV 的安全性模型。关于未确认交易，他们指出：
在 SPV 模式下，只要你所连接的节点将某个交易转发给你，你就只能相信这个交易是有效的。如果攻击者能够确保你所连接的节点都是他的，就可以向你发送一个完全无效的交易（花费根本不存在的钱），而你会认可这个交易是有效的。
对于普通用户来说，SPV 的安全性已经 “足够高” 了。尽管如此，我们还可以利用 SPV 欺诈证明对其进行改进。虽然人们已经就欺诈证明进行了一些讨论，但是关于如何将它们构建到比特币协议内的提案尚未实现。
如果你没有运行全节点（以及实际用它来验证交易），那你至少要在一定程度上信任第三方，这会导致安全性模型产生差异。请注意，这不需要所有用户和企业直接在 Bitcoin Core 的 RPC API 上构建他们的软件。
一些替代基础设施配置包括但不限于：
1）使用安卓版比特币钱包、GreenAddress 或 Stash 等移动钱包配置仅查询你自己的全节点的钱包。
2）在 SPV 节点库（如 BitcoinJ）上构建应用并将这些应用设置成仅连接你自己的全节点。在 BitcoinJ 中，这可以通过定义你自己的 SeedPeer 并在初始化过程中将其传递给你的 PeerGroup 来实现。通过 libbitcoin，你可以使用该示例定义与特定节点的网络连接。
3）构建一个兼容 Bitcoin Core 的 JSON-RPC API 的代理服务器。这个 API 不仅会向第三方服务发送一些调用，也会通过调用本地全节点自动验证第三方服务返回的数据。BitGo 的 BitGoD 软件就是一个例子。这种混合模型可以达到两全其美的效果：你可以使用第三方提供的高级功能，同时保留自己的金融主权。
显然，运行自己的全节点是最安全的方案，需要的假设也最少。构建一台能够运行可靠全节点的计算机只需几百美元。你不妨算一下这笔账，再决定是否值得付出这些来保护自己的金融主权。
感谢 Kristov Atlas、Eric Martindale、Andrew Miller 和 Kiara Roble 对本文的审阅和反馈。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。