SHRINCSとは？Blockstream社が提案する耐量子署名

三倉大司 • 2026年06月23日

ビットコインの量子コンピュータに対する議論・対策はどこまで進んでいるのか疑問に思う方は多いでしょう。一般的に公開鍵から秘密鍵を導出する攻撃（Shorのアルゴリズムによる楕円曲線離散対数問題の解読）にリスクがあるとされており、来たる量子コンピュータの脅威に備え、コミュニティでは量子耐性を持つ暗号の研究と様々な提案がなされています。

本稿では、こうした提案の1つとして、Adam Back氏がCEOを務めるBlockstream社が2025年12月に発表した耐量子署名「SHRINCS」について解説します。SHRINCSはハッシュベースのアルゴリズムを用いた署名方式であり、ビットコインならではのアドレスの利用方法を活かして効率のよい署名サイズを実現している点で注目を集めています。

同社は2026年3月3日、ビットコインのサイドチェーンであるLiquid Network上でSHRINCSを用いた署名を構築・ブロードキャストすることに成功したと発表しており（トランザクション例：その１、その２）、量子耐性獲得に向けた研究が継続的に進められていることが伺えます。

もっとも、こうした研究はスピード重視ではなく、慎重な決断も重視されています。詳しくは以下の記事をご参照ください。

耐量子暗号の署名のサイズが大きすぎる問題

本題に入る前に耐量子暗号（以後PQC：Post-Quantum Cryptographyと表記）の署名サイズが大きすぎる問題について触れなくてはなりません。

現在ビットコインで用いられているSchnorr署名のサイズは64バイトです。これは平均して1秒当たりに約6.5トランザクション（TPS：Transaction Per Second）を扱うことができます。

一方でNIST（アメリカ国立標準技術研究所）によりFIPS 205として標準化されたPQCの暗号の一つであるSLH-DSAの署名サイズはなんと約7,872バイトとされ、およそ123倍の大きさです。これは、平均して1秒間に0.36トランザクションを扱う性能であり、ブロックサイズの圧迫が懸念されています。つまり、ビットコインコミュニティとしては署名サイズを如何に小さくしながらPQCを導入していくかが一つの焦点となります。

ここで登場するのが今回紹介するSHRINCSです。SHRINCSは最小で324バイトの署名サイズを実現しており、1秒間に約4.1トランザクションを扱える性能です。

それぞれの署名を比較すると以下の図になります。

横軸は署名サイズを表しており、右に行くほどサイズが大きくなることが見て取れます。また左側の縦軸は1秒間に処理することができるトランザクションの数、右側の縦軸は1ブロック当たりに消費されるUTXOの数が示されています。

図より左上に位置するほど署名サイズが小さく、多くのトランザクション・UTXOを扱えることが伺え、図ではP2TR keyspend（Schnorr署名）が位置しています。その後、SHRINCS、SLH-DSAが続きます。

「SHRIMPS」はSHRINCS同様Blockstream社が提案するポスト量子署名の1種であり別記事にて解説します。「SPHINCS+」は後ほど本稿にて扱います。

量子耐性を持つ署名の提案SHRINCS

ハッシュ関数は、量子コンピュータを用いても原像を求めるために膨大な計算量が必要とされており、出力長を長くすることで量子攻撃への対策が可能だと言われています。

ハッシュ（関数）ベースの署名であるSLH-DSAは前項で触れたとおり署名サイズが大きいことが問題視されていました。そこで、Blockstream社のJonas Nick氏とMikhail Kudinov氏により署名サイズ改善を目的に提案されたのが「SHRINCS」です。

そもそもSLH-DSA署名のサイズが大きいのは「署名バジェット」と呼ばれる署名回数の制限に2^64という膨大な数を設定しているのが要因で約8KBというサイズになっています。ビットコインではアドレスの再利用は非推奨（公開鍵が露出してしまうため）であり、1つの鍵が署名を行う回数は1回もしくは少数であるため、署名バジェットを小さくすることが可能です。

一方で署名バジェットを超えて署名を行うとセキュリティ的な脆弱性が生まれます。そこでSHRINCSの発想としては、どの鍵で署名を行ったか順番も含めて記憶しておき、署名バジェットを小さくしたコンパクトルートと署名回数を忘れた場合に署名サイズの大きい鍵でも署名が可能なフォールバックルートの2つのパスを用意するという考えです。

ここで用語を整理しておきます。

ステートフル（Stateful）：何回署名を行ったか（状態）を記憶すること
ステートレス（Stateless）：状態を保持しないこと

SHRINCSのユースケースとして通常時は、専用デバイスによるステートフルな署名で署名サイズを抑え、デバイスの故障・紛失などによりシードフレーズを用いたバックアップを行った際は状態が失われた状況のため、フォールバックとしてステートレスな署名が行われます。

具体的にSHRINCSは以下の図のような構成で構築されます。

ステートフルな署名は「Unbalanced XMSS」、ステートレスな署名は「SPHINCS+」が用いられます。両者をハッシュ化することでSHRINCSの公開鍵が作成されます。

ステートフル方式：Unbalanced XMSS

XMSSとはeXtended Merkle Signature Schemeの略で、NIST SP 800-208で推奨されているステートフル・ハッシュベースのPQC署名です（LMSと並んで掲載。FIPS標準であるSLH-DSAとは異なり、ステートフル方式特有の運用要件があるため「推奨」という位置づけ）。

構造としてはワンタイム署名（OTS：One-Time Signature）により292バイトの署名を実現しており、マークルツリーを用いることで状態を記憶しています。

Unbalancedとはマークルツリーが以下の図のような不均衡な形であることを示します。

SHRINCSではXMSS用に最適化されたワンタイム署名（OTS）である「WOTS+C：Winternitz One-Time Signature with Checksum」が用いられており、Unbalancedマークルツリーにより上から1番目、2番目・・・の署名であることがわかりやすく表現されています。

💡

興味深いのはマークルツリーの深さが1つ深くなるごとに署名サイズが16バイト増加する点です（深さ1で324バイト）。これによりアドレスを使いまわすほど署名サイズが増大し、トランザクション手数料も高くなるため、アドレスの再利用を抑制するインセンティブが生まれます。

ステートレス方式：SPHINCS+

状態を保持できなくなった場合のフォールバックとして提供されるのがSPHINCS+という署名で3~8KBのサイズです。（厳密にはSPHINCS+の変形版）

💡

豆知識：SPHINCS+をNISTが標準化したものが「SLH-DSA」であるため、両者の構造はほぼ同じです。

SPHINCS+はPQC署名のユーティリティ（有効な部分）を複数の層に重ねて構築されるため、署名サイズが増大するが状態を記憶しておく必要がないのが特徴です。これは、巨大な構造により同じ鍵を2回選択してしまう可能性が統計的に無視できるほど小さいことに起因します。

ビットコインにおいては再署名をする回数が膨大である必要はないため、より小さい構造のSPHINCS+を用いることで署名サイズを削減することも可能であることから3KBから8KBというレンジでサイズを変えることができます。

提案されている署名は他にも存在

本提案のSHRINCSはバックアップから復元を行うことでフォールバックパスしか使えない仕様となっており、サイズが大きい署名しかできないのが欠点としてあります。そこでバックアップにおいても比較的小さい署名を提供できるように提案されたのが「SHRIMPS」です。

SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices

Abstract: SHRINCS achieves very small hash-based signatures using a stateful signer while still allowing for static backups. However, its efficient stateful path requires transferring state to any new device, which is error-prone, so in practice any restored or secondary device will typically fall back to large stateless signatures. SHRIMPS removes this single-device constraint. In settings where each key is used for only a small number of signatures (as is typical in Bitcoin), a static seed bac…

Delving Bitcoinjonasnick

また、オフチェーン署名においては署名の頻度が極めて高く、ハッシュベース署名が持つ署名回数の上限が短期間で枯渇してしまうため、SHRINCSを含むハッシュベースの署名用いることが困難です。そのためroasbeef氏は、オフチェーンの署名認証に格子ベースの署名方式を提案しています。

Post Quantum Lightning: Layer by Layer

Hi y’all, Over the past few weeks I’ve received some direct and indirect questions asking how the rise of quantum computers may affect the Lightning Network. I searched and didn’t see anything concrete written on the topic, so I figured that I’d write something up! To answer the question of how quantum computers may affect the design of Lightning, a useful starting point is recognizing that any layer that uses cryptography that rests on classical security assumptions requires modifications. S…

Delving Bitcoinroasbeef

SHRINCSを含むハッシュベースPQC全般の課題は、BIP32で定義されるHDウォレットの非ハード化派生、つまり公開鍵だけから複数の子公開鍵を階層的に生成する機能が失われることであり、今後も議論は続いていくでしょう。

まとめ

ビットコインへのPQC導入における最大の課題は署名サイズの肥大化です。現行のSchnorr署名（64バイト）に対し、NISTが採択したSLH-DSAは約7,872バイトと123倍もの大きさになります。

この問題を解決するためBlockstream社が提案したのがSHRINCSです。通常時はステートフルなUnbalanced XMSSで最小324バイトの署名を実現し、デバイス紛失などで状態が失われた場合はSPHINCS+によるステートレスなフォールバック署名（3〜8KB）に切り替わる二段構えの設計となっています。

課題としてはバックアップ後に大きい署名しか使えない点やHDウォレットの非ハード化派生が失われる点が挙げられており、引き続き議論が続いています。

三倉大司

大学では量子コンピュータのゲート方式を中心に、QAOAを用いた問題解決手法の研究を行っていました。また、GPT をはじめとする Transformer アーキテクチャにも関心を持ち、機械学習モデルの構造理解や応用に取り組んできました。現在は日本ビットコイン産業株式会社の R&D 部門に所属し、主に Lightning Network（LN）関連技術の調査・研究開発を担当しています。特に、LN におけるネットワーク中心性の向上やルーティング効率改善に関するテーマに興味を持ち研究しています。