比特币客户端的最初版本使用广泛的 OpenSSL 库来进行交易的签名和验证。依赖第三方库听起来很合理，但后来因签名解析代码的不一致性而暴露出问题。这一问题后来在 BIP66 的修订中得到修复，确保对 ECDSA 签名的严格编码，并在 Bitcoin Core v0.12（2016）中将 OpenSSL 依赖替换为 libsecp256k1。大约在 2012 年，比特币核心开发者 Pieter Wuille，网名“sipa”，偶然在 Bitcointalk 论坛看到 Hal Finney 的帖子。
libsecp256k1 的目标是为 secp256k1 曲线上的密码学操作提供最高质量的库，主要目的是在更广泛的比特币生态系统中发挥作用。libsecp256k1 的 API 设计为健壮且不易被误用，以防止用户进行可能导致资金损失的不安全操作。libsecp256k1 使用 C 语言编写，且不依赖任何其他库，因此只使用专门为该项目编写的内部代码。因此它也被设计成能够在受限设备上运行，例如广泛用于硬件钱包的微控制器。
从很早开始，libsecp256k1 就将质量保证作为重点，随着时间的推移不断改进和打磨。存在一种称为“穷尽测试”的特殊保障形式，用以在曲线的所有可能取值范围内测试库的功能。由于实际的 secp256k1 曲线约有 2^256 个点，因此会使用一个较小但相似的曲线进行穷尽测试，以使执行时间保持在可接受范围内。测试的一个重要部分是确保恒定时间行为，这对签名尤为重要。
将焦点从 QA 转向新特性，在过去十年里 libsecp256k1 及整个 Bitcoin 协议的一个重大里程碑，是 Schnorr 签名的引入。它们是 Schnorr Taproot 软件分叉在 2021 年末激活的关键部分，相较于 ECDSA 签名，具有诸多优势，包括在标准假设下可证明的安全性、更加紧凑，以及能够在其上实现诸如密钥与签名聚合等多种构造，从而实现更高效的多签名方案。BIP340 的规范与实现均由当前三位 libsecp256k1 维护者 Pieter Wuille、Jonas Nick 和 Tim Ruffing 共同完成。
毋庸置疑，验证数字签名是比特币共识引擎中最重要且对安全至关重要的代码路径之一。快速的签名验证对交易和区块传播都至关重要，并能加速新参与者的初始区块下载（IBD）。我们此前已经提到，大约十年前 libsecp256k1 首次取代 OpenSSL 时实现了约 5 倍的加速。
随着时间推移，进一步的性能改进被实现，最近的一项调查显示，libsecp256k1 现用各自的最新版本在 ECDSA 签名验证方面大约比 OpenSSL 快 8 倍。到目前为止，我们的重点一直放在 libsecp256k1 的验证功能上，因为它对节点运行者和矿工的性能最关键。另一面是签名，即为交易创建数字签名以花费资金的过程。
使这一过程变得微妙的是涉及到机密密钥材料。libsecp256k1 通过避免数据相关分支来对抗所谓的“侧信道攻击”，即根据输入数据的不同执行不同的代码。这不仅是理论上的担忧，实际也发生过多次，需要发布修补程序（例如版本 0.3.1 和 0.3.2）。
2014 年，Pieter Wuille 与 Gregory Maxwell 已经在为该库开发一套全面的测试集。测试发现 OpenSSL 在对数值平方时会给出错误结果，这一严重的安全相关漏洞被登记为 CVE-2014-3570。 Gregory Maxwell 也在一次偶然中发现 Bernstein 与 Yang 的算法的另一种变体，具有更低的下界，从而在签名和验签方面带来另一轮显著的加速。
safegcd 实现的正确性（安全性）已通过一个名为 Rocq（前称 Coq）的专用定理证明软件以及可验证 C 程序逻辑形式化验证。这项令人印象深刻的工作由 Russell O’Connor 与 Andrew Poelstra 完成，他们表示整个 libsecp256k1 都可以以同样的方式被验证。我们现在已经证明 libsecp256k1 主要用于创建和验证比特币交易中的数字签名，并以尽可能安全高效的方式来实现，但这并非止步于此。
每当提出涉及 secp256k1 曲线的密码学操作且被视为对比特币生态有益的其他提案时，相关代码很可能被视为库的范围内。这也在持续推进，为 Silent Payments 添加一个新模块，该模块是一种隐私保护的静态可重复使用地址，发送方与接收方在支付前无需交互。让我们拭目以待 libsecp256k1 在未来十年的发展！有兴趣的读者可查看 secp256k1lab，这是一个用于原型设计和实验的 secp256k1 曲线的 Python 实现。
发表评论