以下文章旨在重点介绍有助于多年来为比特币软件客户端用户保留可靠体验的开发里程碑。我们展示了几个对于维护网络的去中心化特性和减轻其参与者的资源负担至关重要的升级。我们描述了如何进行无数数量级的优化，以便比特币网络能够在不显着增加新用户和现有用户的参与成本的情况下，支持交易活动的增长。最后，我们注意到这些改进都在一个更大的、系统的协议开发方法中，该方法利用了来自大 O 复杂性概念的见解，并利用更智能的算法，更有效地利用网络资源。
签名缓存
发布: 比特币-Qt 0.7.0
验证 ECSDA 签名是在对等节点级别完成的最计算量大的操作之一。由于它们需要针对每个交易进行验证，因此任何多余的验证都会导致最终用户出现明显的资源开销。早期的软件版本就是这样，它们会在签名进入节点内存池之前和之后验证签名。它们进入一个区块。
为了提高效率，开发人员创建了一个缓存，允许节点存储先前验证的签名，并在交易进入已接受的区块后跳过重复的工作。
此外，签名缓存还缓解了由专门设计的交易带来的 DoS 向量，这些交易可能导致比特币客户端停滞。
更多信息
Ultraprune + LevelDB
发布: 比特币-Qt 0.8.0
Ultraprune 是比特币软件的第一个主要升级之一，旨在解决与验证来自区块链的交易数据相关的开销。以前版本的比特币参考客户端维护着所有交易输出（已花费或未花费）的索引。Ultraprune 通过深入了解您只需要跟踪未花费的输出，并且输出一旦花费就可以完全从索引中删除，从而显着减小了该索引的大小。
为了实现这一点，实现了一种新的数据库布局，该布局将未花费的交易输出分配到紧凑的自定义格式中，以减小验证工作所需的信息的大小。
为了进一步优化系统的性能，Ultraprune 与 LevelDB 同时推出，后者弃用了旧的 BDB 数据库技术。总体而言，影响显着: 具体取决于其硬件，用户在验证区块链数据时可能至少可以体验到数量级的改进。这种新的数据库结构也将为将来在修剪和更轻量级的比特币完整节点实现方面的研究铺平道路。
更多信息
并行脚本验证
发布: 比特币-Qt 0.8
虽然这是一个更为细微的改变，但将脚本验证过渡到更加并行的过程消除了区块验证时间中的大量开销。早期版本的软件会在每次 UTXO 获取之间验证来自输入的脚本数据，由于所有操作的线性处理，从而造成性能问题。这违反了高效计算过程设计的基本原则，该原则规定在可能的情况下，计算应该与 I/O 作业同时进行。考虑到这一点，区块验证机制重新设计，以便能够将脚本检查分配到并行线程，以便在客户端完成从区块获取所有 UTXO 之前完成其验证。为了实现这一点，脚本检查操作在处理交易后存储在队列中，并与其他输入验证作业分开处理。
因此，通过更有效地利用对等节点的资源，对链尖的同步速度快得多。在实现测试期间，开发人员在对之前版本的软件进行基准测试时，注意到速度提高了 35% 到 100%。
更多信息
先头部同步
发布: 比特币核心 0.10
为了进一步缩短初始区块下载时间，核心项目在 2014 年后期引入了一种重要的重新架构，该架构是节点用于与工作量最多的有效链同步的机制。
最初，引导一个新的比特币客户端的过程将涉及用户从单个对等节点获取区块数据，因此任何中断或连接质量下降都会显着延迟该过程。随着区块链尺寸不断增加，这将导致有时需要大量时间才能完成同步，很大一部分用户报告了多天的时间段，具体取决于他们的硬件。
先头部同步使用一种新的方法完全缓解了这个问题，该方法涉及节点首先从单个对等节点下载和验证区块头，然后从多个其他对等节点并行获取区块数据。
自从比特币的早期以来，关于初始区块下载时间的抱怨就一直存在。随着先头部同步的出现，该软件在易用性方面取得了重大进步。节点不再浪费数小时在不可靠的同步上，现在可以利用他们的整个对等节点网络并显着缩短引导时间。通过使用更智能的算法，对比特币长期可持续性的这一关键方面进行了另一个渐进的改进。
更多信息
区块文件修剪
发布: 比特币核心 0.11
对旧数据的修剪是中本聪在他的白皮书中首次描述的概念，作为解决磁盘空间不足的一种潜在解决方案。不幸的是，最初的设计不充分，无法按其创建者想象的那样实现。七年后，随着区块链规模达到 100 多吉字节，今天我们所知的区块文件修剪的引入为资源有限的用户带来了重大利好。
区块文件修剪利用了与 Ultraprune 相关的先前工作；最初下载和验证了区块链的用户现在可以丢弃超过 288 个区块的原始数据。因为这些节点仍然保留着完整的 UTXO 集，所以它们仍然能够验证未花费的数据，这足以完全验证新的区块并防止潜在的双重支付。
当然，修剪意味着仍然需要足够的存档节点来提供完整的区块链数据。另一方面，这项创新通过使保持存档节点更加经济高效，扩展了验证者的范围。总体而言，该解决方案是我们为加强网络多样性而提供的选择中一个受欢迎的补充。
更多信息
libsecp256k1
发布: 比特币核心 0.12
经过测量后，人们确定，在解决区块链下载效率低下问题之后，下一步是解决交易验证及其繁重的计算负载的瓶颈。核心项目通过使用一个专为优化 ECDSA 操作的性能而设计的新库来着手解决这个问题。ECDSA（椭圆曲线数字签名算法）是比特币公钥基础设施的基石，每次用户移动硬币时都会使用它，使用其私钥对消息进行签名。为了维护账本的完整性，这些签名需要由网络中的每个对等节点进行验证。
早期开发人员一直在考虑从最初的 OpenSSL 库迁移，经过 5 年的设计考虑、测试和同行评审，Pieter Wuille 的 libsecp256k1 库被引入作为其替代品。正如预期的那样，该实现导致了每个比特币交易背后的签名验证过程的速度大幅提升。基准测试报告表明，与 OpenSSL 实现相比，速度提高了 5-7 倍。对于用户而言，这将转化为节省通常用于 ECSDA 操作的引导时间的一半，ECSDA 操作是同步从头开始的新节点的最费力的步骤之一。
考虑到比特币交易活动的增长，此升级对于保持网络对等节点的合理用户体验至关重要。又一次，减少算法复杂性为用户提供了更有效地利用其资源的方式，并大幅降低了新参与者的准入门槛。
更多信息
- 比特币-Qt 0.12.0 发布说明
- Andrew Poelstra (andytoshi) 关于 libsecp256k1 的安全性和测试
- Greg Maxwell 关于测试 libsecp256k1 揭示 OpenSSL 中的错误
- Greg Maxwell 在 DevCore 上的演示
- Hal Finney 关于 libsecp256k1 的帖子
内存池限制
发布: 比特币核心 0.12
比特币软件的一个长期存在的漏洞是它无法正确处理对等节点内存池的泛滥。实际上，攻击者可以发送大量低价值、低费率的交易，这些交易会累积在内存池中，直到它超过可用的内存。这会导致内存资源相对较少的节点在活动异常期间崩溃。对此的唯一有效措施是提高软件的最低中继费用，这仍然没有对内存池的潜在大小设置上限。
为了解决这个问题，核心项目的开发人员实施了严格的内存池最大尺寸，并制定了具体的逐出策略，按费用对交易进行排序，并首先逐出支付最低费用的交易。为了防止具有相同费用的交易重新进入内存池，节点会将其有效最低中继费用率提高到与最后逐出的交易的费用率加上初始最低中继费用率相匹配。
最大尺寸的配置留给用户决定，默认尺寸为 300 兆字节。此更新为内存资源有限的节点用户提供了更加稳健的体验，并且总体上使整个网络更加可靠。
更多信息
在第二部分中，我们将讨论建立在上述技术基础上的更近期的改进，这些改进进一步提高了网络的稳健性和可扩展性潜力。