比特幣雜誌
核心問題：libsecp256k1，比特幣的加密核心
比特幣圈內人士常說“不要相信，要驗證”或“私鑰不在手上，幣就不是你的”，有時甚至聲稱比特幣“有數學支撐”。但這些格言最終究竟意味著什麼？這些複雜的數學原理又是如何付諸實行的呢？大多數讀者肯定知道，比特幣設計的一個基本要素是公鑰密碼學，更具體地說是數位簽名，它無需中心化機構即可證明所有權。但鮮為人知的是，支撐這種橢圓曲線數學運算的底層軟體是什麼？為了確保以最安全、最高效的方式運行，並持續改進，又付出了哪些努力？讓我們深入了解「libsecp256k1」的精彩歷史和發展歷程。這個庫最初只是一個小型業餘項目，但經過多年的發展，它已成為保護價值數萬億美元資產的共識規則的重要組成部分。
創世紀
出於我們尚未完全清楚的原因，中本聰選擇了一條名為「secp256k1」的橢圓曲線來創建和驗證比特幣的數位簽章。比特幣客戶端的初始版本使用了廣泛應用的OpenSSL程式庫來進行交易簽名和驗證。從軟體工程的角度來看，依賴第三方函式庫似乎是一個合理的方案（尤其是像橢圓曲線這樣具有領域特定性和複雜性的函式庫）。
雖然最初選擇了使用加密技術（例如加密演算法），但後來發現由於簽章解析程式碼的不一致性，這個選擇存在問題。在最壞的情況下，這甚至可能導致意外的鏈分裂。當時的一個教訓是，OpenSSL 並不適合像比特幣這樣對共識要求極高的系統。後來，BIP66 解決了這個問題，它確保了 ECDSA 簽名的嚴格編碼。之後，在 2016 年初發布的 Bitcoin Core v0.12 中，OpenSSL 依賴項被 libsecp256k1 取代。
但回顧一下，libsecp256k1 計畫的最初動機主要是出於對潛在加速效果的好奇。 2012 年的某個時候，比特幣核心開發者 Pieter Wuille（網名「sipa」）偶然發現了 Hal Finney（因在 2009 年收到中本聰的第一筆比特幣交易而聞名）在 bitcointalk 論壇上的一個帖子。
在題為「加速簽名驗證」的文章中，討論了一種利用所謂「自同態」（更具體地說是利用所謂的GLV方法，即Gallant-Lambert-Vanstone方法）的優化方案，而這種自同態只有某些橢圓曲線才允許，secp256k1恰好是其中之一。 Hal Finney本人使用OpenSSL原語實現了該方案，後來甚至將其作為PR提交給了Bitcoin Core。儘管它展現了強大的性能，但…
速度提升了約 20%，但最終由於擔心程式碼複雜性增加以及無法保證所涉及的加密技術是可靠的，該功能從未合併。
Pieter Wuille 決定從零開始建立一個新的庫，其「secp256k1」程式碼庫的初始提交可以追溯到 2013 年 3 月 5 日。僅僅一周後，該庫就能夠驗證完整的區塊鏈（當時區塊高度約 225000），又過了一周，簽名功能也得以實現。經過一段時間的測試，該程式庫最終得以在 Bitcoin Core 中取代 OpenSSL，首先用於簽章功能。
錢包（版本 v0.10，2015 年）以及最終用於共識機制中的 ECDSA 簽名驗證（版本 v0.12，2016 年）。這些努力絕對值得：根據 Core 中的 PR 描述，使用 libsecp256k1 進行簽名驗證的速度「提升了 2.5 到 5.5 倍」。諷刺的是，這還不包括先前提到的內同態優化，因為出於專利侵權的考慮，該優化預設並未啟用。直到 2020 年專利到期後（在版本 v0.20 中啟用），該優化才得以激活，並帶來了約 16% 的顯著速度提升。
隨著時間的推移，該專案吸引了其他幾位貢獻者。這自然包括從一開始就與 Pieter 在 Blockstream 密切合作的人員，即當時的首席技術長 Gregory Maxwell 和研究員 Andrew Poelstra。 2015 年，Jonas Nick 和幾年後的 Tim Ruffing 也加入了進來，他們都是 Blockstream 的研究員，並且多年來一直擔任 libsecp256k1 的維護者。他們負責制定新的加密演算法。
他們制定協議（包括詳細的安全證明），並透過實施和審查將其付諸實踐，因此稱他們為「全端密碼學家」非常貼切，正如蒂姆·拉芬喜歡這樣描述自己一樣。
偶爾，甚至比特幣領域之外的密碼學家也會做出貢獻。
libsecp256k1。其中一個值得注意的例子是 Peter Dettman，他是 C#/Java 加密庫 BouncyCastle 的維護者之一，至今仍不時提出各種效能改進建議。他的主要貢獻之一是在 2021 年使用「safegcd」演算法實現了模逆運算，從而安全地提升了效能，該演算法基於 Daniel J. Bernstein 和 Bo-Yin Yang 的一篇論文。
為什麼要重新發明輪子？
libsecp256k1 的目標是為 secp256k1 曲線上的加密操作提供最高品質的函式庫，其主要目的是服務更廣泛的比特幣生態系統——Bitcoin Core 只是它的主要客戶端。 libsecp256k1 的 API 設計穩健可靠，難以被濫用，以防止使用者執行不安全的操作（例如，自行編寫加密方案），從而避免在最壞的情況下造成資金損失。它專注於單一橢圓曲線，並將功能限制在特定操作上。
對於比特幣而言（即主要用於交易的簽名和驗證），程式碼運行速度更快，審查也更簡便，與其他實現方式相比，維護負擔更輕，整體品質更高。 libsecp256k1 使用 C 語言編寫，不依賴任何其他函式庫，因此僅使用專為該專案編寫的內部程式碼。正因如此，它也適用於微控制器等資源受限的設備，而微控制器通常用於硬體錢包。
三思而後行
libsecp256k1 從早期就非常重視品質保證，並在多年來不斷改進和完善。如今，它的測試程式碼覆蓋率接近 100%，只有滿足這項標準的新模組才有機會被合併。除此之外，還有一種特殊的品質保證形式，稱為「窮舉測試」。其基本思想是針對曲線上所有可能的值來測試庫的功能。由於實際的 secp256k1 曲線包含約 2^256 個點，因此無法進行窮舉測試。為此，我們使用了一條特殊的、規模小得多但非常相似的曲線，其階數僅為兩位數或三位數，因此可以在合理的時間內輕鬆完成測試。測試的另一個重要部分是確保恆定時間行為，這對於簽名尤其重要，我們將在下文中看到。
施諾爾：一個全新的世界
我們將工作重心從品質保證轉向新功能，過去十年 libsecp256k1 以及整個比特幣協議的一個重要里程碑是引入了 Schnorr 簽名。作為 2021 年底啟動的 Schnorr/Taproot 軟分叉的重要組成部分，Schnorr 簽章相比 ECDSA 簽章具有諸多優勢，包括在標準假設下具有可證明的安全性、更加緊湊，以及支援許多其他構造，例如金鑰和簽章聚合，從而實現更有效率的多重簽章方案。 BIP340 規範和實作皆由 libsecp256k1 的現任三位維護者 Pieter Wuille、Jonas Nick 和 Tim Ruffing 共同完成。
libsecp256k1 對您的節點和網路都很有好處
毋庸置疑，驗證數位簽章是比特幣共識引擎中最重要（如果不是最重要）且安全至關重要的程式碼路徑之一。無論鎖定腳本中包含多麼複雜的腳本路徑和額外的支出條件，最終交易中很可能至少會涉及一次簽名檢查，以確保交易確實是由被花費代幣的所有者創建的。對於如此關鍵的操作，我們希望程式碼盡可能健壯、經過充分測試且效能卓越。快速簽章驗證對於快速交易和區塊傳播至關重要，同時也能加快網路新參與者的初始區塊下載 (IBD) 速度。我們先前已經提到，大約十年前 libsecp256k1 首次取代 OpenSSL 時，速度提升了約 5 倍。隨著時間的推移，效能得到了進一步提升，最近的一項調查顯示，使用最新版本的 libsecp256k1 進行 ECDSA 簽章驗證的速度比 OpenSSL 快約 8 倍。
簽字可能很危險，所以務必謹慎。
到目前為止，我們主要關注的是libsecp256k1的驗證功能，因為它對節點運行器和礦工的性能至關重要。另一方面（coin並無雙關之意！）是簽名，即為交易創建數位簽名以便支出資金的過程。這個過程的脆弱之處在於它涉及私鑰材料。如果這些材料以任何方式洩露，最壞的情況下可能會導致資金的災難性損失，因此必須在實現層面格外謹慎。 libsecp256k1試圖透過避免資料依賴分支來抵禦所謂的“側通道攻擊”，即避免根據輸入的資料執行不同的程式碼片段。這是一項不小的任務，對於現代編譯器而言需要額外的努力，因為現代編譯器有時“過於智能”，它們會在編譯軟體時嘗試優化程式碼，並添加一些我們明確不希望看到的資源節省分支。這並非僅僅是理論上的擔憂，而是已經發生過不只一次，需要發布補丁程式（例如 0.3.1 和 0.3.2 版本）。我們還使用名為「valgrind」的工具測試了重要的恆定時間特性，該工具最初是為調試記憶體問題而開發的。透過使用它來尋找操作敏感資料的程式碼中的任何分支，我們可以偵測是否有潛在的側通道攻擊風險。
另一種洩露機密資訊的方式是無意中將其留在記憶體中。覆蓋記憶體區域以確保其被擦除聽起來很簡單，但必須以一種能夠防止編譯器在編譯過程中因程式碼最佳化而乾擾的方式來完成這項工作。我們採取了非常謹慎的措施來確保這種情況不會發生。
一些幸運的意外
在庫的開發過程中，不只一次出現了意想不到的有趣情況。 2014 年，Pieter Wuille 和 Gregory Maxwell 已經開始著手為該庫編寫一套全面的測試套件。為了提高可靠性，他們採取的策略之一是使用特殊的隨機輸入，將庫內部函數的行為與其他實作進行比較驗證。這導致 OpenSSL 在進行平方運算時出現錯誤結果，這是一個嚴重的安全漏洞，已提交為 CVE-2014-3570（「Bignum 平方運算可能產生錯誤結果」）。
幾年後，Pieter Wuille 提出了一種新的方法，用於計算先前提到的用於計算模逆的「safegcd」演算法所需迭代次數的界限（或極限）。這使得該界限得以縮小，從而加快了計算速度。但這還不是全部。 Gregory Maxwell 幾乎是偶然地發現了 Bernstein 和 Yang 演算法的另一個變體，其界限更低，從而在簽名和驗證方面都實現了另一個顯著的加速。
值得一提的是，「safegcd」實現的正確性（即安全性）已使用名為「Rocq」（原名「Coq」）的特殊定理證明軟體和「可驗證C」程式邏輯進行了形式化驗證。這項令人印象深刻的工作由Russell O'Connor和Andrew Poelstra完成，他們指出libsecp256k1的整個函式庫都可以用同樣的方法進行驗證。
密碼學仍在不斷發展
我們現在已經證明，libsecp256k1 主要用於創建和驗證比特幣交易中的數位簽名，並儘可能以最安全、最高效的方式實現，但這還不是全部。每當有其他提案涉及基於 secp256k1 曲線的加密操作（理想情況下，這些操作應以 BIP 的形式形式化），並且被認為對整個比特幣生態系統有益時，相關程式碼很可能被納入該庫的開發範圍。在這種情況下，只要開發者有足夠的時間進行實作和審查，這些提案很有可能最終會被整合到 libsecp256k1 的發布版本中。先前，ElligatorSwift 模組就曾出現過這種情況，該模組對於實現節點 P2P 通訊的加密至關重要[參見 BIP324；此處有深入討論]。最近，MuSig2 也採用了類似的方案，MuSig2 是一種基於 Schnorr 簽章的金鑰聚合方案，它能夠以節省空間且保護隱私的方式建立 n 對 n 多重簽章。目前，我們正在努力添加一個用於靜默支付的新模組。靜默支付是保護隱私的靜態可重複使用位址，無需在付款前進行任何互動。此外，還有更多功能即將推出：例如 Schnorr 簽章批次驗證、DLEQ 證明、FROSTETC。讓我們拭目以待 libsecp256k1 未來十年的發展！
對 libsecp256k1 有興趣的讀者可以查看並試用 secp256k1lab，這是一個用 Python 實現的 secp256k1 曲線，旨在用於原型設計和實驗。 5
千萬不要錯過擁有《核心特刊》的機會——其中收錄了許多核心開發人員撰寫的文章，解釋了他們自己參與的項目！
本文為《比特幣雜誌》最新一期印刷版「核心特刊」的編按。我們在此分享，旨在讓讀者提前了解本期雜誌探討的觀點。
[1] https://gnusha.org/pi/bitcoindev/55B79146.70309@gmail.com/
[2] (#2061， https://github.com/bitcoin/bitcoin/pull/2061 )
[3] https://delvingbitcoin.org/t/comparing-the-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1-over-the-last-decade/2087?u=thestack
[4] [ https://www.arxiv.org/abs/2507.17956 ]
[5] https://github.com/secp256k1lab/secp256k1lab/
這篇文章《核心問題：libsecp256k1，比特幣的加密心臟》最初發表在《比特幣雜誌》上，作者是Sebastian Falbesoner 。
