Coconut認証(Coconut Credentials)は、複数の発行機関が分散して発行し、利用者が「必要な属性だけ」を毎回別人のように見せられる匿名クレデンシャルの方式です。2019年のNDSS(Network and Distributed System Security Symposium)で発表された論文を出典に、仕組みと実測性能、そして2026年時点でどの実装が動くのかを、実際に手元で走らせた結果まで含めて整理します。
まとめ:Coconut認証の要点
Coconut認証は、University College Londonとchainspace.ioのAlberto Sonnino氏ら5名が発表した選択的開示クレデンシャル方式です。Pointcheval-Sanders署名にWaters署名とBGLS署名の性質を組み合わせ、n個の発行機関のうち任意のt個から部分クレデンシャルを集めれば1つのクレデンシャルが完成します。発行機関同士は通信不要で、単一の発行者が裏切ってもクレデンシャルを偽造できません。
ただし閾値の設定は自由ではなく、論文は正直者多数(n/2 < t)を前提に置きます。性能は検証10.497ミリ秒、クレデンシャル132バイトと軽量である一方、Ethereum上での検証は約215万ガスを要します。実装面では、論文の参照実装もEU実証で使われたChainspaceも更新が止まった一方、DECODEプロジェクトの暗号基盤だったZenroomは現在も開発が続き、シナリオ名を変えてCoconutを提供しています。以下、各論点を一次情報にあたって解説します。
Coconut認証の定義と、従来の匿名クレデンシャルとの違い
選択的開示クレデンシャルは、発行された証明書のうち一部の属性だけを検証者に見せる技術です。論文はここに3つの不足があると指摘しています。単一の発行者に署名鍵を預ける方式は、その発行者が不正を働けば任意のクレデンシャルを偽造できます。閾値署名は分散発行こそできるものの、再ランダム化やブラインド発行に対応しません。CL署名を使うHyperledgerのidemixも、発行者は信頼された第三者1者です。
Coconut認証は、汎用・完全分散の閾値発行・再ランダム化可能・マルチショーを同時に満たす方式としては著者らの知る限り初のものだ、と論文は位置づけています。核となる暗号技術はゼロ知識証明とブラインド署名です。前者の基礎はゼロ知識証明(ZKP)とは何かで扱っていますが、Coconutではこれを「属性mが条件φを満たすことだけを示す証明」として発行時と提示時の2回使います。
再ランダム化が効くため、同じクレデンシャルを何度提示しても検証者側からは毎回別の値に見えます。これがベアラトークンとの決定的な差です。
7つのプロトコルとt-out-of-nの集約
arXiv版v4(2020年3月16日改訂)が定義するプロトコルは、Setup・KeyGen・AggKey・IssueCred・AggCred・ProveCred・VerifyCredの7つです。このうちIssueCredはさらにPrepareBlindSign・BlindSign・Unblindの3アルゴリズムに分解されます。利用者から見た発行から検証までの流れは次のとおりです。
| 手続き | 実行者 | 役割 |
|---|---|---|
| PrepareBlindSign | 利用者 | 属性を隠した発行要求 |
| BlindSign | 各発行機関 | 中身を見ずに部分署名 |
| Unblind | 利用者 | ElGamal鍵で復元 |
| AggCred | 利用者 | t個をラグランジュ補間で集約 |
| ProveCred | 利用者 | 再ランダム化して所持証明 |
| VerifyCred | 検証者 | ペアリング検査で確認 |
集約はラグランジュ基底多項式による多項式補間で、秘密の分散値から元の値を指数部のまま復元します。利用者はn個の発行機関に要求を投げ、到着順を問わず先に返ってきたt個を使えるため、残りが応答不能でも手続きが止まりません。発行機関同士が互いに通信しない設計なので、論文はこれを非同期環境を前提にした方式だと説明しています。検証鍵の集約であるAggKeyは一度実行すれば済み、発行機関を増やしても検証コストは増えません。
3つの安全性要件と、閾値信頼が成り立つ2つの前提
論文が定義する安全性要件は3つです。t個未満の正当な部分クレデンシャルしか持たない攻撃者が検証者を騙せない偽造不可能性、発行時に発行機関が属性mについて「φを満たす」以外を学べないブラインド性、検証者が発行機関と結託しても属性を学べず提示同士を結び付けられない非連結性です。ブラインド性と非連結性は何台の発行機関が結託しても保たれますが、偽造不可能性だけは結託台数に条件が付きます。
その条件が1つめの前提です。論文は正直者多数(n/2 < t)を明示的に仮定しており、tは自由に決められません。総数nの過半数を超える値にしないと、悪意ある発行機関だけでクレデンシャルを勝手に発行できてしまいます。
2つめの前提は鍵生成側にあります。論文は、実装が採用したKate氏らの分散鍵生成プロトコルについて、安全性ではなく生存性のために弱同期を必要とし、かつ不正な発行機関が全体の3分の1以下であることを要求すると明記しています。つまり署名の集約が要求する過半数条件と、鍵を配る段階が要求する3分の1条件は別物で、厳しいほうに合わせて設計する必要があります。発行機関の構成を決めるときは、tの値より先に、n個の運営主体が実質的に独立しているかを確認してください。同一組織でノードを3台立てても分散にはなりません。
論文の実測値:ミリ秒台の暗号処理とEthereum検証の215万ガス
暗号プリミティブの実行時間とクレデンシャルサイズ
論文の実装はPythonで、petlibとbplibを使い、ペアリングはBarreto-Naehrig曲線上でOpenSSLを演算バックエンドとして動かしています。3.6GHz Intel Xeonの8コアDellデスクトップで、私的属性1つの条件で各手続きを10,000回実行した平均値は次のとおりです。
| 手続き | 平均[ms] | 標準偏差[ms] |
|---|---|---|
| PrepareBlindSign | 2.633 | 0.003 |
| BlindSign | 3.356 | 0.002 |
| Unblind | 0.445 | 0.002 |
| AggCred | 0.454 | 0.000 |
| ProveCred | 1.544 | 0.001 |
| VerifyCred | 10.497 | 0.002 |
AggCredの値は発行機関2つを前提とした測定で、その他の手続きは発行機関数に依存しません。最も重いVerifyCredがペアリング演算を含むため約10ミリ秒かかります。クレデンシャル本体は132バイトで、私的属性1つを扱う場合の通信量は発行要求516バイト・発行応答132バイト・検証提示355バイトです。公開属性1つなら発行要求32バイト・検証提示162バイトまで下がります。
スマートコントラクト検証のガスコスト
Ethereum実装ではzkSNARK検証用のalt_bn128プリコンパイル契約を使ってペアリング検査を行いますが、それでもオンチェーン検証は高価です。Go実装のEthereumを、12GBメモリのIntel Core i5ノートPC(Ubuntu 17.10)で動かし、公開属性1つで100回測定した結果、クレデンシャル作成のCreateが27.45ミリ秒・約23,000ガスであるのに対し、Verifyは120.17ミリ秒・約215万ガスに達します。内訳の大半は楕円曲線のスカラー倍算をネイティブのコントラクトとして実装した部分で、これだけで約170万ガスを占めます。
論文は、私的属性を扱う完全な検証にはG2上の乗算が3回必要で、当時のブロックガス上限800万を超えると述べています。オンチェーンで毎回検証する設計は現実的でなく、検証はオフチェーンに寄せるか、公開属性1つに絞る前提で組むことになります。
3つの応用例とDECODEプロジェクトでの実装
論文が設計した応用は、支払いの匿名性を確保するコインタンブラー、匿名のまま署名できる電子請願システム、検閲回避用プロキシの配布システムの3つです。このうち前2つはChainspace上に実装され、性能評価まで行われています。
Coconutは論文だけで終わらず、EUのHorizon 2020プロジェクトDECODE(助成協定番号732546)で実装されました。DECODEの開発者向けサイトは、DECODEアプリの認証フローについて「UCLのCoconut論文に基づき、Zenroomを使って実装した」と明記しています。ZenroomはDyne.orgが開発する暗号処理VMで、DECODEの暗号基盤にあたります。バルセロナ側では、市の市民参加プラットフォームDecidim向けのDDDCパイロット用にZencodeで書かれた一連のコントラクトが用意され、電子請願の作成・署名・集計まで論文の応用例をなぞる構成になっています。
CORDISによればDECODEは2016年12月1日から2019年12月31日まで実施され、EU拠出額4,987,673.75ユーロ、バルセロナ市のInstitut Municipal Barcelona Innovació i Tecnologiaが調整役を務めて終了しました。アムステルダムでは2つの実証が走っており、混同しやすいので区別しておきます。パスポート情報から18歳以上であることだけを示す年齢証明パイロットはZenroomを使い、2018年12月18日に市CTOオフィスでソフトローンチ、2019年1月15日にPakhuis de Zwijgerで公開デモを行いました。一方、地域プラットフォームGebiedOnlineへの属性ベースクレデンシャル統合で使われたのはIRMAで、こちらはCoconutとは別系統です。
Zenroomで動かすCoconut:2026年8月に実行した発行から検証まで
DECODEが終了して6年以上たった今も、Zenroomの開発は続いています。GitHubのdyne/Zenroomは2026年7月13日に更新があり、最新リリースはv5.37.2(2026年7月7日)です。実装の中身も確かにCoconutで、暗号処理本体のcrypto_credential.luaは冒頭に「Coconutに基づくゼロ知識証明スキーム」と記し、著者としてDenis Roio氏とCoconut論文の第一著者であるAlberto Sonnino氏の名前を挙げています。
ただし、そのまま動かそうとすると引っかかります。公式リポジトリのdocs/examples/zencode_coconut/にある古いサンプルは冒頭がScenario coconutで、npm版のzenroom 5.37.2で実行すると「required extension not found: zencode_coconut」で失敗しました。シナリオ名がcredentialへ変わり、文も「create credential keypair」から「create credential key」のように改められているためです。現行のサンプルはdocs/examples/zencode_cookbook/credential/側にあります。
実際に動く最小の3本を挙げます。発行機関が要求に署名する契約、利用者が証明を作る契約、検証者が確かめる契約です。
Scenario credential: issuer sign
Given that I am known as 'MadHatter'
and I have my valid 'keyring'
and I have a 'credential request' inside 'Alice'
When I create the credential signature
and I create the issuer public key
Then print the 'credential signature'
and print the 'issuer public key'
Scenario credential: create proof
Given that I am known as 'Alice'
and I have my 'keyring'
and I have a 'issuer public key' inside 'MadHatter'
and I have my 'credentials'
When I aggregate all the issuer public keys
and I create the credential proof
Then print the 'credential proof'
Scenario credential: verify proof
Given that I have a 'issuer public key' inside 'MadHatter'
and I have a 'credential proof'
When I aggregate all the issuer public keys
When I verify the credential proof
Then print the string 'ok'
鍵生成・発行要求・署名・集約・証明生成・検証の7契約をこの順にnpm版zenroom 5.37.2へ渡したところ、2026年8月15日時点で全ステップが成功し、検証契約が成功メッセージを返しました。生成されたcredential_proofのフィールドはkappa・nu・pi_v・sigma_primeの4つで、論文がΘとして定義する所持証明の構造とそのまま対応します。実行ログが示す曲線はBLS381で、論文のBarreto-Naehrig曲線から更新されている点も確認できました。日本語圏の解説はCoconutの概念説明で止まるものがほとんどですが、動かして確かめる経路は現在も残っています。
2026年時点の実装マップ:参照実装の停止とNymのcompact e-cash移行
Zenroom以外の実装は、ほとんどが更新を止めています。GitHub APIで確認した2026年8月15日時点の状況は次のとおりです。日付はデフォルトブランチの最終コミット日です。
| リポジトリ | 言語 | 最終コミット | 位置づけ |
|---|---|---|---|
| dyne/Zenroom | C | 2026-07-13 | DECODE由来・現役 |
| asonnino/coconut | Python | 2020-09-24 | 論文の参照実装 |
| nymtech/coconut | Go / Rust | 2022-10-27 | Nymの旧単独実装 |
| chainspace/chainspace-prototype | Python | 2018-10-10 | 評価に使った台帳基盤 |
| musalbas/coconut-ethereum | Python | 2018-05-08 | Ethereum版ライブラリ |
nymtech/coconutはGoとRustの両方を含みますが、READMEは「現状ライブラリ同士に相互運用性はない(曲線のハッシュ方式が異なる)」と明記しています。評価基盤だったChainspaceは2018年10月を最後に開発が止まり、2019年2月には白書著者5名のうち4名がFacebookのブロックチェーン部門へ移りました。買収したのは技術ではなく人材だとFacebookは説明しており、コードは公開されたまま更新されていません。
商用運用は、一次調査の範囲ではNymだけです。NymはCoconut署名方式を出発点に、自社研究者のAnia Piotrowska氏とAlfredo Rial Duran氏が拡張した匿名クレデンシャルをzk-nymと名付け、Nymミックスネットへのアクセス権証明として使っています。ただし現在のコードはCoconutそのものではありません。2026年8月14日時点のnymtech/nymリポジトリでは、本番のクレデンシャルはcommon/nym_offline_compact_ecash/に置かれたnym-compact-ecashクレートが担い、依存する曲線もzkcryptoのbls12_381をNymがフォークしたnym-bls12_381-fork(0.8.0-forked)に変わりました。Coconutの名が残るのは分散鍵生成まわりの2クレート、CosmWasmコントラクト本体のnym-coconut-dkgと共有型のnym-coconut-dkg-commonだけです。閾値発行という設計思想は引き継ぎ、署名方式は入れ替えたと読むのが正確でしょう。
プライバシー保護を売りにする基盤側の動向を追うなら、ゼロ知識証明を中核に据えたAleoの概要も併せて確認しておくと比較の軸が増えます。
JWTやOIDCではなくCoconut型を選ぶ条件と、見送るべき場面
結論から言えば、社内システムの認証・認可でCoconut型のクレデンシャルを選ぶ理由はほぼありません。JWTの署名検証は公開鍵1つで完結し、実装も運用も枯れています。Coconut型が優位に立つのは、次の3条件が同時に成り立つ場合に限られます。発行者を1者に絞れない(または絞ると不正リスクが許容できない)こと、同一利用者の複数回の提示を検証者に結び付けられては困ること、そして提示のたびに属性の一部だけを開示したいことです。年齢だけを示す本人確認、居住地だけを示す住民投票、支払い済みであることだけを示すアクセス権が典型例です。
逆に見送るべき場面もはっきりしています。発行機関を複数の独立した主体で運用する体制がないなら、閾値発行の利点は絵に描いた餅です。前述のとおり運用側には過半数条件と3分の1条件という2つの制約があり、これは技術ではなく運営主体の分散でしか担保できません。検証を毎回オンチェーンで行いたい場合も、215万ガスという実測値の前では設計を見直したほうが早いでしょう。単に署名方式の強度や鍵長を比較したいだけなら、ECDSAとRSAの違いのような一般的な選定軸のほうが実務に直結します。
よくある質問
Coconut認証とゼロ知識証明は何が違いますか?
ゼロ知識証明は「秘密を明かさずに命題の真偽を示す」暗号技術の総称で、Coconut認証はそれを部品として使うクレデンシャル方式です。Coconutは発行時に属性を隠すためのゼロ知識証明と、提示時に所持を示すためのゼロ知識証明の2種類を組み合わせ、さらにブラインド署名と閾値集約を加えて1つの方式に仕立てています。
ブラインド署名だけを使う方式と何が違いますか?
ブラインド署名は発行者に中身を見せずに署名してもらう技術ですが、それだけでは発行者が1者に固定され、同じ署名を何度も見せると提示同士が紐づきます。Coconutは閾値発行で発行者を分散させ、再ランダム化で提示ごとに見た目を変える点が加わります。
発行機関はいくつ用意すればよいですか?
tとnは方式のパラメータですが、論文は正直者多数(n/2 < t)を安全性の前提に置くため、tはnの過半数を超える値にする必要があります。さらに論文の実装が使う分散鍵生成プロトコルは不正な発行機関が3分の1以下であることを要求するので、実質的に独立した運営主体をn個そろえられるかが先に問われます。
いま試すならどの実装を使えばよいですか?
動かして学ぶならZenroomが最短です。ただしシナリオ名がcoconutからcredentialへ変わっているため、リポジトリに残る古いzencode_coconutのサンプルではなくzencode_cookbookのcredential配下を使ってください。論文どおりの参照実装asonnino/coconutは2020年9月から更新が止まっており、学習目的に限るのが無難です。
検証に10ミリ秒かかるのは実用上遅くありませんか?
論文当時のPython実装かつ8コアデスクトップでの測定値であり、サーバー側の1リクエストあたりの処理としては十分に軽量です。問題になるのはスマートコントラクト内で検証する場合で、Ethereum実装のVerifyは約215万ガスと高額なため、オンチェーン検証を前提とした設計は避けるべきです。