カルダノ財団が、Plutus V3で利用できるBLS12-381関連機能をAikenからどう使うか、その実装例と解説を公開した。財団の公式X投稿は、数千の署名を一つに集約し、1回分に相当するコストで検証できる可能性を強く打ち出している。
これは、Cardanoへ新しい暗号機能が追加されたというニュースではない。BLS12-381の組み込み関数はすでにPlutus V3で利用できる。今回のニュース価値は、その機能を公開鍵集約、署名集約、検証へどう組み立てるのかが、開発者の読めるAikenのコードと設計パターンとして示されたことにある。
同時に、「数千署名を1回分のコストで検証」という説明には重要な成立条件がある。主な対象は、多数の署名者が同一メッセージへ署名する場合だ。署名の生成や収集、公開鍵の事前確認、集約までオンチェーンだけで完結するわけでもない。本稿では、何が効率化され、どこからがアプリケーション側の責任になるのかを整理する。
新機能ではなく「使い方」が公開された
BLS12-381をめぐるCardano側の流れは、今回の発表から始まったものではない。まずCIP-0381で、BLS12-381に必要な演算をPlutusで扱うための組み込み関数が定義された。その機能がPlutus V3へ入り、Changアップグレードを通じて利用可能になった。今回、カルダノ財団が公開したのは、その先にある「実際にどう組み合わせるか」のガイドである。
暗号プリミティブが台帳に用意されていることと、開発者が安全なアプリケーションとして使えることの間には距離がある。開発者は、どのデータをオフチェーンで準備し、何をPlutus V3スマートコントラクトへ渡し、どの前提を検証すべきかを決めなければならない。組み込み関数の一覧だけでは、その全体像までは見えにくい。
財団のAiken実装リポジトリは、その距離を埋める材料だ。公開鍵集約や署名集約などを、抽象的な機能紹介ではなく、Aikenから利用するコードとして追えるようにした。「眠っていた」とは未実装だったという意味ではない。基礎機能は存在していたが、具体的な利用設計が見えにくかったという意味だ。
BLS署名は何を集約できるのか
BLS12-381は、BLS署名の検証に使われる楕円曲線とペアリング演算の基盤である。ここで重要なのは、BLS署名には複数人の公開鍵や署名を集約できる性質があることだ。
たとえば、1,000人の参加者が、まったく同じ「提案Aを承認する」という承認文へ署名するとする。通常の署名方式を素朴に扱えば、検証側は1,000個の公開鍵と1,000個の署名を受け取り、署名者ごとの確認を繰り返すことになる。
BLS署名では、各参加者の公開鍵を一つの集約公開鍵へ、各署名を一つの集約署名へまとめられる。同一メッセージに対する集約であれば、検証側は「集約公開鍵」「集約署名」「全員が署名した同じメッセージ」の関係を確認できる。
その確認に使われるのがペアリング検証だ。数式を追わなくても、二つの対応関係を照合する検査だと考えるとよい。集約公開鍵とメッセージから得られる関係が、集約署名の側と一致するなら、集約された署名が条件を満たすと判断できる。Plutus V3は、この検証を構成するBLS12-381関連の組み込み関数を備えている。
ただし、暗号学的な署名の成立と、「誰が承認メンバーなのか」「必要な定足数を満たしたか」というアプリケーション上の判定は別である。集約検証が成功しても、参加者名簿や権限、失効した鍵の扱いまで自動的に正しくなるわけではない。
「数千署名を1回分のコストで検証」の成立条件
財団の表現が成立する中心的なケースは、署名者全員が同一メッセージへ署名し、公開鍵と署名がオンチェーンへ渡される前に集約されている場合だ。Plutus V3スマートコントラクトが受け取るのは、個別署名の長い列ではなく、事前集約された公開鍵と署名、対象メッセージ、そしてアプリケーションの判定に必要な情報となる。
この形なら、最終的な暗号検証の仕事量を署名者数から切り離せる。署名者が10人から1,000人へ増えても、オンチェーン側が1,000回の個別署名検証を繰り返す設計にはならない。この意味で、署名者数に比例しない定数コストの検証を設計できる。
一方、この説明を次のように一般化してはいけない。
- 署名者ごとに異なるメッセージへ署名する異なるメッセージの一般的な集約検証は、同一メッセージ向けと同じ定数コストの主張には含まれない。
- 「1回分」は、トランザクション全体が無料になる、あるいは通常の単独署名検証と完全に同額になるという意味ではない。集約結果の受け渡しやアプリケーション固有の判定には別の処理がある。
- 誰を集約へ含めるか、必要な人数が参加したか、各鍵が有効かという確認は残る。最終ペアリング検証を集約できることと、承認フロー全体を省略できることは同じではない。
したがって、正確な読み方は「条件を満たす同一メッセージ集約では、オンチェーンの最終暗号検証を署名者数に比例させずに済む」である。数千という規模は大きな可能性を示すが、実際のコストと処理能力は個別DAppのデータ設計や判定ロジックを含めて測る必要がある。
オフチェーンとオンチェーンの役割分担
BLS署名の集約は、オンチェーン処理を減らす代わりに、必要な準備を消してしまう技術ではない。処理をどこへ置くかを明確に分ける設計である。
| オフチェーン側の主な責任 | オンチェーン側の主な責任 |
|---|---|
| 各参加者による署名生成 | 渡されたメッセージと集約結果の最終検証 |
| 署名と公開鍵の収集 | Plutus V3のBLS12-381組み込み関数によるペアリング検証 |
| 公開鍵の有効性確認とProof of Possession（PoP）の確認 | DApp固有の権限、定足数、状態遷移などの判定 |
| 公開鍵と署名の集約 | 検証結果に応じたトランザクションの受理または拒否 |
ここでいう「外部サービスやオラクルに依存せずネイティブに検証できる」とは、最終的な暗号検証をPlutus V3スマートコントラクトの組み込み関数で実行できる、という範囲の話である。署名者同士の通信、署名収集、集約結果をトランザクションへ運ぶ仕組みまで不要になるわけではない。
この分担は弱点ではなく、BLS集約の設計上の要点だ。高頻度かつ参加者数に応じて増える作業をオフチェーンへ置き、台帳が合意すべき最終結果をオンチェーンで検証する。どちらか一方だけを見るのではなく、二つを一つのシステムとして設計する必要がある。
rogue-key attackをどう防ぐか
公開鍵を単純に足し合わせればよい、という理解には落とし穴がある。悪意ある参加者が、他の参加者の公開鍵との関係を利用して細工した鍵を登録すると、本来署名していない正当な参加者まで署名に加わったかのような集約結果を成立させられる場合がある。これがrogue-key attack（不正鍵攻撃）の直感的な姿だ。
同一メッセージ向けの高速な集約検証を安全に使うには、各参加者が登録した公開鍵に対応する秘密鍵を本当に保持していることを、集約前に確認する必要がある。その代表的な仕組みがProof of Possession（PoP）、すなわち秘密鍵保有の証明である。
PoPは、集約署名の検証時に思い出して追加すればよい付属機能ではない。公開鍵の登録時や参加者セットの更新時に検証し、未確認の鍵を集約へ混ぜない運用が前提となる。さらに、鍵の更新や失効、参加資格の変更をどう反映するかもDApp側の設計課題だ。集約関数が正しく動くことだけでは、公開鍵管理の安全性は保証されない。
財団のAiken例が示す応用範囲
財団の公開物で確認できるAiken例の中心は、公開鍵集約と署名集約である。そこにKDF（鍵導出関数）やVRF（検証可能なランダム性を扱う仕組み）の例も含まれ、BLS12-381関連プリミティブが署名の一用途だけに閉じないことを示している。
公開鍵集約の例は、複数の鍵をどう一つへまとめるかを扱う。署名集約の例は、複数署名を集約し、同一メッセージの場合と異なるメッセージの場合で検証条件がどう変わるかを考える土台になる。VRFとKDFの例は、同じ暗号プリミティブ群から、検証可能性や鍵材料の導出に関わる別の構成を作れることを示す。
ただし、KDFの例をオンチェーンで秘密を保持できるという説明や、本番環境でパスワードを保存する推奨例として読むべきではない。公開台帳上のデータは秘密の保管場所にはならず、サンプルはプリミティブの利用法を示すものだからだ。
一方、ペアリング基盤からはBBS+のような高度な署名方式も応用領域として考えられる。しかし、今回確認できたAiken実装例は公開鍵集約、署名集約、KDF、VRFであり、BBS+まで完成したサンプルDAppが提供されたという意味ではない。実装済みの例と、同じ基盤から検討できる応用領域を分けて読むことが重要になる。
「production-ready」をどう読むべきか
財団は基礎となる暗号プリミティブを「production-ready」と表現している。ここで本番利用の準備が整ったとされる対象は、Plutus V3から利用するBLS12-381の基礎プリミティブである。この表現を、公開されたサンプル一式や、それを組み込んだ個別DAppまで自動的に本番保証されたという意味へ広げてはいけない。
サンプルコードには大きな価値がある。開発者はゼロから組み合わせを推測するのではなく、動く構成を読み、試し、自分の設計と比較できる。しかし本番DAppに採用するなら、少なくとも次の確認は別途必要になる。
- DApp固有の脅威モデルと第三者レビュー
- PoPを含む公開鍵の登録、更新、失効手順
- オフチェーンの収集・集約処理が失敗した場合の扱い
- 想定する署名者数とデータ構成でのコスト計測
- 不正な入力、重複参加、参加者セット変更への対応
基礎プリミティブが本番向けであること、利用例が公開されていること、個別アプリケーションが安全に運用できることは、三つの異なる段階だ。今回のガイドは二つ目を大きく前進させた。三つ目は、各開発チームが監査と運用設計を積み上げて到達する領域である。
眠っていた機能が、設計可能な部品になった
カルダノ財団の公開は、Plutus V3へ新しい魔法を追加したのではない。CIP-0381を経て利用可能になっていたBLS12-381の機能を、Aiken開発者が検討しやすい部品へ翻訳した。公開鍵集約、署名集約、VRF、KDFの例をたどれることは、ドキュメントと実装の間にあった空白を狭める。
とりわけ同一メッセージの署名集約は、多数参加者の承認を扱いながら、オンチェーンの最終検証を参加人数に比例させない設計の選択肢になる。その価値は「全部をオンチェーンへ載せる」ことではなく、オフチェーンの準備とオンチェーンの検証を適切に分けることで生まれる。
次に見るべきなのは、公開例を土台にした監査、PoPと鍵ライフサイクルの運用、実データでのコスト計測、そして具体的な採用例だ。基礎プリミティブ、サンプル、実運用の境界を保ちながら採用が進めば、眠っていた機能はCardanoの設計空間を広げる現実的な部品になっていく。