Mt.Goxの破綻後に発表された取引所の支払い能力を証明するプロトコルProvisionsのホワイトペーパー↓
http://www.jbonneau.com/doc/DBBCB15-CCS-provisions.pdf
仮想通貨を取り扱う取引所では、一般的な銀行の仕組みである部分準備金銀行のようなアプローチはコミュニティから良しとされず、顧客が預入をしているコインの総量以上のコインを取引所が保有していることが求められる傾向がある。実際に顧客が預けたり取引所上で購入したコインの総量と同じ量のコインを実際に取引所が持っていない場合、一斉に引き出しが発生すると一部の顧客はコインを引き出すことができないし、取引所がハッキングを受けたり、破綻した場合、不足しているコインは顧客の元に戻ってこない可能性が高い。
取引所の破綻そのものを回避する仕組みはないものの、顧客が預入・取引しているコインを取引所が確かに支払うことができることを証明する仕組みは、顧客の資産保護という点で重要だ。↑のProvisionsでは暗号学的な仕組みを利用して取引所の支払能力を証明するためのプロトコルを提案している。
ざっとホワイトペーパーの内容を見てみる↓
Proof of Solvency
取引所に支払能力があるかどうかは、単純に取引所の総資産 ≧ 取引所の総負債
であることが証明できればいい。このためProof of Solvencyを構成するは以下の3つのプロトコルで構成される。
- プロトコル1 資産の証明
取引所が署名可能なBitcoinの合計量にコミットした証明 - プロトコル2 負債の証明
取引所のすべての顧客のBitcoinの残高にコミットした証明 - プロトコル3 支払能力の証明
負債の証明と資産の証明のコミットメントの差を準同型的に計算し、支払能力を証明する
Provisionsは、Confidential Transactionなどでお馴染みのPedersen Commitmentやゼロ知識を使ってこれらのプロトコルを実現する。
表記
- gとhを楕円曲線のグループGのジェネレータ(固定値)とする。
- yを公開鍵、xを秘密鍵とする。
- xとyの関係は、と表記する(一般的な楕円曲線の公開鍵と秘密鍵の表記はだけど、このホワイトペーパーでは←を使う)。
プロトコル1資産の証明
プロトコル1では取引所が持つ総資産へのコミットメントを生成する。この時重要なポイントが、取引所が実際にいくらの資産を保有しているのかを明かすこと無く資産の証明ができること。
総資産へのコミットメントの作成
取引所はまず公開鍵の匿名セットを用意する(yは公開鍵)。このセットの内、取引所が実際に対応する秘密鍵xを知っている公開鍵のセットをSとする。SとPKの関係は。また、0か1の値を持つを定義し、取引所が秘密鍵を知っている場合はs = 1、知らない場合はs = 0とする。公開鍵にロックされているビットコインの量をとすると、取引所の総資産は↓のように表現できる。
ここで、公開鍵が持つコインの量には取引所が秘密鍵を持っている分と持っていない分が含まれ、持っていない分についてはなので合計に加えられない。PKが与えられれば検証者は(誰でも)ブロックチェーンを確認することで各の量を確認できる。
続いてを使って以下の式を定義する。
この式ではが、を秘密鍵としたときの公開鍵となることが分かる。先述したように誰もがの値を知ることができるので、誰もがを計算できることになる。
取引所は毎にランダムな値を選択して、以下のPedersen Commitmentを作成する。
ここではgとは異なる別のジェネレータhとランダムに選択した秘密鍵から生成した公開鍵になる。については取引所が秘密鍵を知らない場合0なので、その場合では実質。
このコミットメントをi=1,..,nまで足していくと
と、取引所の資産の合計額へのコミットメントが出来上がる。
※ 合計額へのコミットメントを公開するだけで実際の合計額が明らかになる訳ではない。
(のAssetsが実際に取引所が所有する=秘密鍵を持つコインの合計)
ちなみにが取引所の本当の総資産かどうかは分からない。支払能力を証明するには総負債以上の総資産があることが証明できれば良いのでコミットメントには含まれていない余剰金があっても問題はない。
総資産へのコミットメントの証明
総資産へのコミットメントが計算できても、の公開鍵に対する秘密鍵を本当に取引所が所有しているのだろうか?という疑問は残る。
これが証明できないとが実際に取引所の管理下にある資産なのか分からないので、取引所は合計額を秘匿したままゼロ知識でこれを証明する。
証明のためまず取引所は各i毎にランダムな値を選択して以下のようなのPedersen Commitmentを作成する。
このコミットメントは以下のようにの部分を量に対するPedersen Commitmentに置き換えることができる。
として以下のように記述する。
が取引所の資産の下限値であることを証明するのに、取引所は[1], [3], [5]を満たす以下の数量の知識を証明する。
この証明によりの時、取引所が公開鍵に対応する秘密鍵を知っていることを検証者に確信させる。
取引所はΣプロトコルを利用した以下のProtocol 1を使って[6]の知識を証明する。
プロトコル1自体は対話型のプロトコルになっているけど、これはFiat-Shamirヒューリスティックというのを使用すると非対話型にできるみたい。
プロトコル2負債の証明
まず顧客毎に顧客の一意な情報(ユーザー名、メールアドレス、口座番号など)とランダムに選択したnonceを使って顧客毎のコミットメントCIDを生成する(※異なる顧客に同じエントリーを与えられないよう顧客毎の一意な情報からCIDは生成される)。
全顧客のCIDとその残高及び、残高のrange proofを持つ、債権者リスト(LiabList)を作成する。この債権者リストには取引所が顧客数を秘匿するため残高0のダミーの顧客が含まれている場合もある(残高があるダミー顧客を追加しても良いが、追加した分債務は増える)。
債権者リストは大まかに以下のようにして作られ、できたリストを公開する。
- 顧客の残高に対するPedersen Commitmentを作成する。この時残高をm-bitの二進数で表す(mはで計算)。
- 1で計算した残高の各bit毎にPedersen Commitmentを作成する。
- 各顧客ごとに、取引所がPedersen Commitmentに使用したランダム値と残高の各bit値を知っていることを証明=range proofを生成する。
- 顧客の固有情報とnonceを使ってCIDを計算する。
- 顧客分↑を計算したら、全顧客分の債権リスト = <CID, 残高の各bit値のリスト, ゼロ知識>, ...を生成し公開する。
残高をm-bitの2進数にしてるのが不思議だが、おそらく残高をオーバーフローさせてマイナス残高を設定できないようにするためと思われる(マイナスの残高が加わると総負債が減って見えてしまう)。各bitは0か1かのどちらかであり、それを証明するのにステップ3でrange proofを作っているのか?
各顧客は以下の手順で自分の残高が正しいか検証することができる。
- 取引所にログインして、今回の使用されたCIDのnonceの値と、残高のPedersen Commitmentを作成するのに使われたランダム値を取得する。
- 1のnonceを使って今回のCIDを計算し、それが公開されている債権者リストの中にあるか確認する。(リストの中に無い場合は取引所が不正を働いていることになる)
- 債権者リストの中に自分のデータがあれば、自分の債権リストの自分のデータの残高の各bit値のリストが正しい残高のコミットメントになっているか検証する。
基本的に顧客が確認できるのは自分の残高が間違っていないかということで、債権者リストの他の顧客のデータを見たからといって他の顧客の残高が分かるわけではない。
これらの具体的な計算が以下のProtocol2↓
そして債権者リストのすべての 残高の各bit値のリストを合計すると、総負債額へのコミットメントが計算できる。
債権者リストの拡張
債権者リストのCIDと残高へのコミットメントをリーフとしたマークルツリーを構成することで負債の証明を拡張することもできる。ツリーの内部ノードは2つの子ノードのハッシュとそれらの残高の合計のコミットメントが含まれるようになる。そうやって計算したマークルルートには全顧客の残高の合計へのコミットメントが含まれる。各顧客は自分の残高からマークルルートまでのパスが提供されれば検証が可能だ。このツリーを生成する場合、取引所の証明の生成時間が2倍になるため、オプションとされている。
プロトコル3 支払能力の証明
プロトコル1で総資産額へのコミットメントが計算され、
プロトコル2で総負債額へのコミットメントが計算されたので、
が0へのコミットメントであれば、総資産額と総負債額はイコールであることになり、取引所に支払能力があることを証明できるということみたい。(hの指数はランダム値なのにこの計算で0へのコミットメントになるというのがイマイチしっくりこない。。)
びったり同額になるということはなく余剰金が発生するケースも考えれる。その場合、余剰金へのコミットメントを作成し(当然range proofも一緒に作る。)
が0へのコミットメントか確認する。
制限事項
- Provisionsはある時点における支払能力の証明を提供するのであって、その後の取引所の行動を含め、顧客の資産を確実に保護するプロトコルではない。
- Provisionsでは公開鍵で口座の所有権を管理しているので、一度も使用されたことのないP2PKHのアドレスやP2SH、複雑なマルチシグなどのアドレスタイプについてはサポートしていない。基本的に取引所はP2SHのマルチシグでコインを管理していることが多いと思うので、実際に導入する際はP2SHベースのアドレスタイプをサポートする拡張が必要になる。
- ProvisionsのプロトコルにFiat-Shamirヒューリスティックを利用することで非対話型のプロトコルになるが、この場合trusted setupが必要になる。trusted setupはしたくないので、将来的にzk-SNARKsなどを利用したproof of solvencyを模索してる模様。
というのがProof of Solvencyのプロトコルの概要みたい。
この他に悪意ある取引所が結託して取引所間で資産のアドレスを共有する結託攻撃へのアプローチや、総資産へのコミットメントを作成する際の匿名セットの選択方法など、詳しい内容はホワイトペーパー参照。