Develop with pleasure!

福岡でCloudとかBlockchainとか。

BEAMが提供する監査機能

BEAM Mimblewimble

MimblewimbleではPedersen Commitmentにより取引する量が秘匿され、さらにスクリプトがなくPedersen CommitmentのBlinding Factorがそのコインの所有権を証明するキーになる。そのため、Perdersen Commitmentを見ただけでは誰から誰へのいくらの送金なのかは分からない。

そんなMimblewimbleをサポートするブロックチェーンの１つがBEAMだが、BEAMではウォレットが当局向けの監査機能を提供する↓

https://github.com/BeamMW/beam/wiki/Wallet-audit

ウォレットが提供する監査機能

監査機能を提供するBEAMのビジネスウォレットはどのように監査機能を実現しているのか？

監査人向けの鍵ペア

ビジネスウォレットは監査用に公開鍵/秘密鍵のペアを作成する。この鍵ペアの内、公開鍵のみが監査人に渡される。監査人が複数いる場合は、その監査人の数分、鍵ペアが作成される。

監査人はこのこの公開鍵を使って、ユーザーのトランザクションをトラッキングする。

トランザクションへのタグ付け

監査人がユーザーのトランザクションをトラッキングできるようにするために、ビジネスウォレットはトランザクションにタグ付けを行う。

BEAMのMimblewimbleトランザクションはトランザクションカーネルに Excess（Blinding Factorの総計）とSchnorr署名の一部であるnonceがセットされるようになっているが、同様にトランザクション毎のカーネルを利用して、そこにタグをセットするようにしている。この時、監査人が複数いる（監査用の公開鍵が複数ある）場合、その数分タグは作られる。また、取引相手にも監査人がいる場合は、その公開鍵の分のタグもセットされる。

タグの内容

この時付与するタグは以下のように、トランザクションカーネルのExcessと、監査用の公開鍵、秘密鍵を使ってビジネスウォレットにより計算される（Hはハッシュ関数、|は結合を表す）。

  1. nonce = H(カーネルのExcess | 監査用公開鍵) * 監査用秘密鍵を計算する。
  2. タグはNonce2 = nonce * G。

↑のように計算されタグはトランザクションカーネルのKernel.Signature.Nonceにセットされる。

監査人は、フルノードを実行し全ブロックのデータをダウンロードする必要がある。そして、各ブロックのトランザクションカーネルにセットされているタグについて、自身の監査対象かどうかを検証する。この検証は監査人が持っている監査用の公開鍵を使って以下のように検証される。

  1. Nonce = H(カーネルのExcess | 監査人が持つ監査用公開鍵) * 監査人が持つ監査用公開鍵
  2. 計算したNonceがブロック内のトランザクションカーネルにセットされているKernel.Signature.Nonceと一致すれば、それが監査対象のトランザクションと識別できる。

※ 任意のデータ（カーネルのExcess | 監査用の公開鍵）を監査用秘密鍵に乗算した生成したのたタグの秘密鍵で、タグはそれに対応する公開鍵で任意のデータを監査用の公開鍵に乗算することで得られる。

このあたりの仕組みはステルスアドレスのアプローチに似てる。

トランザクションの詳細情報へのコミットメント

上記のタグに加えて、トランザクションの詳細情報へのコミットメントもトランザクションのカーネルに追加する。

トランザクション詳細のコミットメントの作成

トランザクションの詳細情報とは以下の情報を指す。

  • トランザクションのインプット/アウトプットの内、ビジネスウォレットが所有するインプット/アウトプット
  • 上記インプット/アウトプットの所有権の証明と金額
  • トランザクションに関連する任意のデータ
TxDetail = {自分のインプット＋署名、自分のアウトプット＋署名、その他任意のデータ}

このTxDetailをデータとし監査用秘密鍵を使ってHMACでハッシュ値を計算する。

Nonce1 = HMAC(監査用秘密鍵, TxDetail)

続いて、nonce1を使って以下を計算する。

PrivateKey = Nonce1 * H(G * Nonce1 | TxDetail)

算出したPrivateKeyにGを乗算したものをKernel.Excessにセットする。

Kernel.Excess = G * PrivateKey

上記のようにトランザクションの詳細情報へのコミットメントが作成され、トランザクションカーネルに付与される。

監査人によるコミットメントの要求

監査人は以下の検証を行う。

  1. 監査人はタグによりマッチするトランザクションを確認したら、ユーザーに対してトランザクションの詳細情報と対応するG * Nonce1を要求する。
  2. 監査人がユーザーからトランザクション情報を受け取ったら、それが本当にトランザクション作成時に作られたコミットメントと一致するか検証する。
    具体的には、(G * Nonce1) * H(G * Nonce1 | TxDetails)を計算し、それがKernel.Excessか検証する。それが一致すれば提供されたトランザクション詳細はコミットメントを作成する元となった情報であることがわかる。
  3. トランザクションの詳細情報にあるインプット/アウトプットのUTXOがブロックに存在するか検証する。
  4. 使用されたインプットが、以前受け取ったトランザクション詳細のアウトプットの中に存在することをチェックする。
  5. インプットを使用済みとマーキングし、アウトプットをUTXOとして認識する。

上記のようにコミットメント方式を利用して、トランザクションの詳細情報をやりとりしている。

監査人ができること/できないこと

上記のように監査人はタグにより監査対象のユーザーのトランザクションを識別し、その取引の詳細情報を照会しコミットメント合致するか検証する。

提供されるトランザクション情報から、ユーザーが所有するインプットとアウトプットの情報が明らかになる。各UTXOの所有権は電子署名により証明されるため、自身が保有しないUTXOを自分のものであると申告することはできない。また、インプットは必ずそれより前に自分のアウトプットであると申告したものであることから、監査人はユーザーのトランザクショングラフを構築することができる。

逆にできないことは、トランザクションアウトプットが本当は自分が所有するものにも関わらず、トランザクションの詳細に含めなかった場合、そのUTXOは監査人から認識されなくなる。そのUTXOは監査外で使用することができる。ただし、その決済は監査を受けたものとは認められず、またそのUTXOを使用するトランザクションを監査対象に含めた場合、そのUTXOの出処となるアウトプットが監査人に認識されていないため、不正なアウトプットと認識される。つまり、監査を受けたUTXOは合法的に取引可能で、監査を受けていないUTXOは合法的に取引できなくなる。

所感

現状、ZcashはMoneroなど匿名通貨は日本の取引所では扱われていない。匿名通貨により通貨のトラッキングができず、ダークウェブやマネロンの温床になるという危険性は分かる。一方で、個人のプライバシーや通貨のFungibilityといった側面が犠牲になる。そういったなんとも言えない状況において、BEAMのような匿名機能を持つ通貨がこういった監査機能を提供するのは重要な要素かもしれない。BEAMが提供するのはあくまでオプトインな監査機能だが、当局にとって必要な監査のレベルとプライバシー/Fungibilityとのバランスとそれを技術的にどう担保するかについてはもっと議論が必要になってくると思う。