作者：Jonas Nick
來源：https://blog.blockstream.com/op_checkshrincs-a-hash-based-signature-opcode-for-post-quantum-bitcoin/
目前，還沒有在比特幣中集成後量子簽名方案的具體方案。在過去一年中，Blockstream Research 一直在研究這個問題。這篇文章分享了我們已經學到的東西，並且主張：優化後的基於哈希函數的簽名，是比特幣量子抗性的務實選擇，近期就能部署。本文還介紹了 “SHRINCS” 和 “SHRIMPS”，它們是建立在成熟的密碼學假設之上的、簽名體積最小的後量子簽名方案；然後，勾勒一個具體提議的雛形。
最新類型的比特幣輸出將資金鎖定在一個 Schnorr 公鑰上，花費這些輸出需要一個有效的 Schnorr 簽名。然而，Schnorr 簽名在量子計算機面前是脆弱的。添加後量子簽名驗證的最自然的辦法，是使用一種後量子選項來延展 Taproot 腳本樹。 在一次軟分叉升級後，一個比特幣輸出可以同時承諾一個 Schnorr 公鑰和一個後量子簽名公鑰。因為 Taproot 只會揭曉實際被花費的腳本的默克爾樹路徑，用戶可以繼續使用 Schnorr 簽名來花費（它體積較小，因此交易手續費將比較便宜），交易的成本幾乎不會改變。 後量子選項可以在腳本樹上靜靜等候。僅當足夠強大的量子計算機出現之後，用戶才需要換用第二種路徑：使用後量子簽名來花費，那時候才需要付出更高的交易成本。
後量子升級的失敗情形
實現量子抗性的升級可能會因為不同的原因而失敗，對這些情形的主動規避，塑造了後文要討論的設計抉擇。
- 吞吐量暴跌。如果簽名的體積太大，區塊空間很容易就用盡，許多用戶將完全無法確認交易。
- 驗證成本。如果驗證簽名的計算要求太高，完全驗證節點的數量將減少，這會影響網絡的中心化。
- 簽名成本。應該讓硬件簽名器和資源有限的設備能在合理時間內生成簽名。
- 密碼學被攻破。使用了無法長期保持為真的安全假設。
- 無人採用。升級提議過於複雜，或者無法集成到現有的基礎設施。只有你自己採用這種提議是不夠的：如果網絡上其他人都被攻陷了，你的錢幣哪怕是完美安全的，在經濟上也毫無價值。
- 實現的複雜性。提議的實現重包含了 bug，或者無法抵禦攻擊，而出於比特幣的共識規則的特殊性，人們將不得不永遠維護這套代碼，不能意外地引入哪怕是最輕微的不兼容性。
能夠避開這些陷阱的提議，才有機會獲得粗略共識。
標準候選
第一組候選是由 NIST（美國國家標準及技術研究所）標準化的方案。這些方案都已經存在，並且有可用的實現，只需稍加努力，就可以轉化為比特幣升級提議（BIP）。比較的基準是用在 Taproot 輸出中的 Schnorr 簽名方案。如果每一筆交易都使用 Schnorr 簽名，按照當前交易的平均大小，比特幣網絡可以（相當於）每秒處理 6.5 筆交易。本文中用到的所有 TPS（每秒處理交易數量）都假設平均每筆交易帶有 2.27 個輸入和 2.64 個輸出（這是在 2026 年 3 月 30 日測算的 90 日平均值，根據 transactionfee.info ），並且比特幣區塊的體積限制保持不變。
Schnorr 簽名支持當前的錢包基礎設施所依賴的特性，尤其是 BIP 32 未硬化的密鑰派生。它也促成了整個生態系統近年在比特幣上部署的效率升級（比如 MuSig2），以及計劃中的隱私性和效率提升（比如門限簽名、靜默支付和跨輸入的簽名聚合）。
- ML-DSA，基於 “格（lattice）” 假設。吞吐量將下跌到每秒處理半筆交易（按 NIST 安全等級 3 計）；並且，Schnorr 簽名的所有特性都會消失，包括 BIP 32 未硬化的密鑰派生。
- SLH-DSA，基於哈希函數。哈希函數是比特幣已經依賴的保守假設，因此可以將 NIST 安全等級 1 作為目標。不過，吞吐量將進一步下跌到每秒處理 0.36 筆交易；同樣，Schnorr 簽名的特性也會消失。
這兩種方案都不是手到擒來的解決方案，並且它們都會讓網絡吞吐量暴跌。提高區塊體積限制可以緩解吞吐量問題，但將一個有時效性、務實的後量子升級跟有爭議的區塊體積提升綁定在一起，不太可能成功。最好單獨討論區塊體積限制。
需要更多研究的候選
由 NIST 標準化的方案們都易於部署，但它們的犧牲是難以接受的。其它候選承諾有更好的取捨，但在部署變成可靠選擇之前需要多得多的研究和時間。
- Falcon^WS 是一種較新的基於格的簽名。它提供了顯著更優的簽名體積（吞吐量在 NIST 安全等級 5 下可以達到 1 TPS），但它還很不成熟，無法考慮部署。把它放在這裡，是為了演示在格的基礎上最終可能實現什麼東西。
- 匹配 Schnorr 簽名特性集合的格簽名，比如 BIP 32 和門限簽名。這是一個值得進一步研究的有前景的方向。不幸的是，添加這些特性會顯著增加簽名的體積（相比忽略這些特性的格方案），可能會讓吞吐量低於 Falcon^WS 的大約 1 TPS 。比如說，一種修改後的 Raccoon-G 方案支持層級式確定性密鑰派生（包括非硬化派生），但是公鑰體積達到了 16 kB，簽名體積是 20 kB 。
- SQIsign，基於 “同源（isogenies）”。簽名體積很漂亮，吞吐量可以上升到大約 3.6 TPS（安全等級 5），而且同源有望支持 Schnorr 簽名的特性。棘手的地方是它的密碼學假設，遠遠不如格假設成熟。被攻破的風險是真實的，而且可能短期內都無法消除。要對新的密碼學假設建立信心，需要花費許多年時間。
- 區塊層簽名聚合，用一個簡潔的證據（一個 SNARK）聚合一個區塊中的所有簽名。保守估計，每個區塊需要一個 500 kB 的證據，那麼吞吐量大概是 6.7 TPS 。最近在這條路線上出現的提議有 BitZip 和 LeanVM 。還有一些開放問題，比如誰來計算證據、如何避免挖礦中心化，而且工程複雜性也相當大。
優化基於哈希函數的簽名以及簽名配額
所有這些候選都存在於同一個多維的取捨空間中：安全假設、效率、特性和複雜性。對基於哈希函數的簽名來說，兩種方向似乎非常有前景。其一，我們可以添加一個新的維度：帶狀態性（statefulness），從而打開全新的設計空間。其二，我們可以接受稍微增加協議的複雜性，換來顯著的性能提升。兩相結合，基於哈希函數的簽名就會成為有吸引力的候選。不加入新的密碼學假設，就能提供更高的效率， 而且其密碼學依然相對容易解釋和實現。
“需記憶性” 用到了一個內置於每一種基於哈希函數的簽名方案的概念：“簽名配額 ”，這個參數表明了單個公鑰可以安全簽名新消息的次數。在 SLH-DSA 中，配額被設為 2^64，對於任何實際應用場景來說，幾乎就是無限大。有意縮減配額可以讓最終簽名的體積更小，然而一旦用盡配額，一個公鑰的安全性就會被打破。
簽名配額為 2^64 時，SLH-DSA 簽名的體積是接近 8 kB，那麼吞吐量是 0.36 TPS 。將配額減少到 2^40（每個公鑰 1 萬億次），也依然是夠用的：按當前的區塊體積，不停簽名幾百年也用不完配額。按這個更小的配額參數， 簽名體積將下降到 5.7 kB，吞吐量提高 33% 。
SHRINCS
那麼簽名配額可以降到多低呢？在比特幣基礎層上，最佳安全習慣不鼓勵地址複用，所以一個普通的公鑰只會簽名幾次。因此，簽名預算可以降得很低。對於需要超過這個數量的用戶，可以提供一個後備選項。這種構造讓一個公鑰有兩條簽名路徑：緊湊路徑，在配額以內，製作出小體積簽名；另有一條總是可用的備用路徑，製作無需記憶簽名次數的簽名。
緊湊路徑用起來也是有代價的：簽名人必須一直追蹤自己的簽名次數，防止超出配額。這個計數器就是 狀態，依賴於它的方案就是 帶狀態的 。在桌面錢包和移動端錢包這樣的環境中，備份-導入 是常態化操作，難以支持帶狀態性。重新導入一箇舊備份，就會在不知不覺中將計數器回滾到一個已經用過的數值。隨後的簽名會複用狀態，這可能會讓用戶的資金置於危險之中。比特幣開發者們，包括我們在 Blockstream Research 的團隊，一直在努力保證比特幣產品抵禦誤用。帶狀態的方案天然是更脆弱的（相比無狀態的方案）。最初探索這個方向時，我們的看法是，這雖然是一種有趣的技巧，但並不怎麼實用。
然而，有一種裝置可以防止用戶意外損壞狀態：專用的簽名設備。在初始化的事後，設備會生成種子詞並設定初始狀態，然後，這份狀態就只會存在於這個設備中，永遠不會離開。這個設備會製作緊湊的簽名。因為這一狀態可以公開，軟件錢包可以添加一項額外的安全檢查，在交易廣播之前驗證一個就緒的簽名沒有複用狀態。 如果這個簽名設備丟失、損壞或被替換了，那麼用戶可以將種子詞導入一個新設備，它會自動退出到無狀態路徑上，製作出無狀態的、體積更大的簽名。將狀態完全保留在設備上，就可以消除用戶弄壞它的可能性。
我們將得到的構造命名為 “SHRINCS”。它依賴於兩個核心想法：
- 讓一個公鑰可以使用兩種簽名路徑：緊湊的、帶狀態的路徑，和一個無狀態的後備路徑。
- 設計非常高效的緊湊路徑：其中的細節已經超出了本文的範圍，但這種構造是直接建立在已有的基於哈希函數的簽名方案之上的。
吞吐量對比：
- SLH-DSA：0.36 TPS
- 簽名配額下降到 2^40 的 SLH-DSA：0.48 TPS
- SHRINCS 緊湊路徑（簽名體積為 580 字節）： 最高可達 3 TPS（假定每個簽名都使用緊湊路徑）
SHRINCS 的風險特徵與其它後量子候選方案顯著不同。那些方案帶有影響網絡上每一個用戶的系統性風險：低吞吐量、可疑的密碼學假設、共識協議變得脆弱。相反，SHRINCS 依賴於局部化的風險：各個設備的狀態管理。考慮到安全部署的可能性以及這些吞吐量數字， SHRINCS 就不再只是一種有趣的技巧，而是一種務實的量子抗性選項。
SHRIMPS
在 SHRINCS 方案中，將種子詞導入一個新的設備是昂貴的，因為這會觸發無狀態後備路徑，從而產生體積更大的簽名。不過，這樣的事情在一個密鑰的生命中不會太多。SHRIMPS 利用這一點，專門為這些備用設備添加了第二條緊湊路徑。使用 1000 個簽名的配額，這條路徑會產生體積大約為 3000 字節的簽名。這是主設備簽名體積的 5 倍，但依然比後備路徑（SLH-DSA 簽名）小 2.5 倍。
優化後備路徑
帶狀態性是前面提到的兩個方向之一。第二個方向是優化無狀態後備路徑自身。
從 SLH-DSA 簽名的 7,872 字節（0.36 TPS）開始，可以疊加這些優化：
- 削減簽名配額到 2^40 ，簽名體積將縮減到 5,792 字節（0.48 TPS），體積縮減了大約 26% 。
- WOTS+C（Blockstream 的密碼學家 Mikhail Kudinov 是其聯合作者之一）和 PORS+FP，它們是 SPHINCS+ 的直接可用的永華，但沒有被 SLH-DSA 方案採用。這可以將簽名體積縮減到 5,060 字節（0.54 TPS），也就是進一步縮減了大約 13% ，而且不影響性能。唯一缺點是偏離了 NIST 的標準。
- 接受 5 倍長的簽名和密鑰生成時間，可以帶來額外大約 11% 的體積縮減，得到 4,496 字節（0.60 TPS）。
- 允許每字節的驗證時間上升到 Schnorr 簽名的大約 1.5 倍，可以再削減大約 13%，得到 3,896 字節（0.69 TPS）。
全部加在一起，可以讓一個無狀態的基於哈希函數的簽名體積縮減到 SLH-DSA 簽名的一半。再狠一點，以更長的簽名或驗證時間為代價，還可以繼續縮減簽名的體積。
一個幼稚的提案
本提案依賴於兩個設計原則。
其一，不增加驗證時間（相比 SLH-DSA 方案）。這是為了避免讓區塊體積限制在未來更加難以提高。 這也顯著簡化了 SNARK 證據的生成，如果區塊層面的簽名聚合能被採用的話。
其二，拋棄 “全方位適用一種簽名” 的想法，為具體的應用場景引入多種簽名方案。
- 桌面端和移動端的 layer-1 錢包無法安全地保存狀態，但它們通常有更快的 CPU 。它們可以使用犧牲簽名時間、換來緊湊性的無狀態簽名方案：在 2^40 的簽名配額下，簽名體積為大約 4,496 字節。這個配額已經遠遠超出了意外可能達到的次數。
- 專用的簽名設備可以設計成能夠安全地保存狀態，但它們的處理器通常較弱，所以提高簽名的成本並非正途。SHRINCS 和 SHRIMPS 使用帶狀態的簽名來保證簽名體積較小，並且簽名速度較快。無狀態的備用路徑使用 2^32 的簽名配額（沒有人會在一個硬件簽名器上重複按一個按鈕 40 億次）；主設備的簽名體積大約是 580 字節；備用設備的（緊湊）簽名體積將是大約 3,000 字節，備用路徑的簽名體積將是大約 4,336 字節。
- 閃電節點天然是帶狀態的，並且能夠從更快的簽名速度中獲得好處。通道更新使用跟專用簽名設備的備用路徑同樣的無狀態方案：2^32 的簽名配額，大約 4,336 字節 的簽名。即將達到 40 億次簽名次數的節點可以輪換成新的公鑰。合作式通道關閉應該可以使用 SHRINCS 緊湊路徑（大約 580 字節）。
結果是四種相互結合的專用簽名變種。實際吞吐量在 0.60 到 3.04 TPS 之間，遠遠超過標準的 SLH-DSA 方案的 0.36 TPS 。
開放問題和缺點
本提案更多是一個起點，而不是已經完成的設計。它也有缺點，並且還有一些為解決的問題：
- 驗證時間優先於體積：本提案可以進一步優化簽名體積，代價是驗證時間。目前，每字節的驗證成本比 Schnorr 簽名低 6 倍，所以，理論上區塊體積可以變成 6 倍而不會增加區塊驗證時間。更嚴謹的論證需要更好的基準測試。（譯者注：網絡的帶寬瓶頸不會允許我們做這樣瘋狂的事。）
- 同質性和隱私性降低：允許組合多種簽名方案而不是隻使用一種簽名方案，將同時降低這些方案的隱私性。
- 覆蓋面與 layer 2：有沒有哪些應用場景是本提案 沒有 覆蓋到的？本提案會如何與 layer-2 協議互動？
- 未來的 SNARK 聚合：簽名方案該如何設計，才能為未來可能通過軟分叉引入的基於 SNARK 的簽名聚合做好準備？這應該成為今天的考慮因素嗎？
- 簽名時間：在不同的計算平臺上，多長的簽名時間是可以接受的？更好的簽名時間基準測試將讓我們可以顯著縮減簽名體積。
- 參考實現：C++ 代碼，還是一種形式化規範？在 LLM（大語言模型）時代，共識關鍵代碼的形式化驗證比以往更可行了。
下一步呢？
比特幣後量子升級的設計空間是很大的，而且沒有哪種簽名方案是顯然的正確選擇。即使如此，優化之後的、帶狀態的基於哈希函數的簽名，相比今天可用的標準方案，可以提供更好的取捨。它們有希望保持比特幣可用，而無需依賴於未來的軟分叉。與此同時，對更加長遠的提升措施的研究，比如更好的基於格的方案、簽名聚合，以及基於同源的密碼學，應該並行推進。
幸運的是，部署問題跟簽名方案的選擇很大程度上是獨立的：新的基於哈希函數的操作碼可以通過 Taproot、 Taproot v2 或 BIP 360 “支付到默克爾根” 來發布。
在基於哈希函數的簽名方案之上，通過帶狀態性帶來優化，這個領域還沒有得到充分的探索。帶狀態性還有沒有可能帶來其它優化呢？謹慎的工程設計能否保證帶狀態裝置的安全性？各 layer-2 協議能夠直接利用帶狀態的簽名嗎？
想要了解基於哈希函數的簽名以及它們的參數，可以閱讀我們的論文《為比特幣考慮基於哈希函數的簽名》。這裡的腳本可用來推導本文中出現的數字。GitHub 上還能找到一個 C++ 語言的 SHRINCS 實現，以及一個 Simplicity 語言的驗證者，還有一份規範草案。SHRINCS 已經可以部署到生產環境中：我們在 Liquid 側鏈上已經演示了它，每個人都能自己嘗試它。
（完）
