Privacy Pool

概要

Tornacdocashの延長線上にあるようなアイデア

スマートコントラクトをベースにしている

Tornadocashがマネロン規制などでBANされた過去の教訓を元に、反社などとの関わりが無いことをzkp(membership proofとexclusion proof)できる。

1.秘匿送金の歴史

これまでMonero,Dash,Grinなど多くの秘匿送金を可能にするブロックチェーンが開発されてきた。

中でもZcashの設計はTornadocashにも受け継がれており、今回のPPにもその影は残っている。

1.1 Zcash

ZCashはゼロ知識証明を使ってTo, From, Amountを秘匿化した状態(shielding)で送金することができるUTXOベースのブロックチェーン。

秘匿化されたとしても二重支払いが行われていないか？使用されたコインは確かに送信者が保有しているか？について検証する必要があるため、UTXOは以下のように全てコミットメント(Note Commitmentと呼ぶ)として管理される

https://scrapbox.io/files/64ffbf265b7836001b582680.png

ただコミットメント化しただけでは、それが未使用かどうか判断できない。

ノードはCommitment(Note Commitment Treeと呼ばれるMerkle Treeに格納される)とNullifierを保持して、Txを秘匿化しつつ検証することができる

https://scrapbox.io/files/64ffdf9dd02ec1001bc0fdd0.png

https://scrapbox.io/files/64ffd65b2fd31a001cdd35fc.png

論文中の画像を引用。L:note Commitment, U:Nullifier

Zcashは規制回避の仕組みとして、このような秘匿化されたTxをBitcoinと同じようなただのUTXOベースのTxに変換し、内容を公開(desheilding)する機能が提供されている。これはViewing Keyと呼ばれるTxごとに作成される公開鍵を使用して提供される機能であり、これを使うと送金者は全ての情報を開示することができる。受信者も使用することができるが、送金者の情報は公開することができない。

このViewing keyの仕組みを使うとTxに関する情報をほぼ全て公開してしまうが、怪しいアドレスとの取引が無いことを証明することができる。

ちなみにshieldingよりもdeshieldingなTxの方がよく使われているので、個人的にzcashの存在意義に疑問符がつく

1.2Tornadocash

TornadocashにもNullifierの仕組みが使用されているが、Viewing keyは鍵生成アルゴリズムをProtocolに組み込む必要があることなどから実現されていない。

仕組みとしてはZcashと同じような機能を提供していたので、流動性が高いEthereumにハッカーらが集まっていたのがBANされた原因であり、「ZcashがオッケーでTornadocashがダメ」と誤解される要因とも言える。

2. Privacy Pool

2.1 今まで保証できなかったこと

Nullifierをつかったアプローチでは、外部から見えるるのはTxが送信されるタイミングだけで、誰がこれらのTxを送信または受信しているか、またどのコインがどの前のコインと「同じコイン」であるかといったパターンについて知ることができない

しかし、deposit/withdrawlには例外がある

depositではCoin ID(L:Note Commitment)は以前のコインを無効にする必要なしに作成される。

与えられたLとLを追加した外部イベントとのリンクが公開されている。言い換えれば、depositはその過去の取引履歴とは切り離されていない。

Tornado CashではシステムへのETHの預金、Zcashでは新しいZECコインの採掘などが該当する。

新しいCoin ID(L:Note Commitment)を追加せずにNullifier(U)が消費されることにより、withdrawalと対応するdepositとのリンクが切れ、過去の取引履歴とのリンクも切れる可能性がある。

ただし、withdrawalイベントの後に発生した将来のトランザクションとリンク付けることができる。

2.2 Assosiation setの導入

ユーザーは自分のwithdrawalと以前に行われたdepositとの関連性をzkpするのではなく、Assosiation setと呼ばれるメンバーシップの一員であることを証明する。

実装ではsubsetと呼ばれている？

Assosiation setは、以前に行われたdepositの完全なサブセットやユーザー自身のdepositだけで構成されるセットなど任意に構成可能で、ユーザーはAssosiation setを指定するためにそのMerkleルートをPublic Inputとして提供する。

ユーザーに対して同じコインIDを両方のケースで葉として使用して、2つのMerkleブランチをzkpすることを要求する

https://scrapbox.io/files/64f9206eb893b7001ba5c49f.png

ユーザは以下の二つの証明を要する

1. ユーザのcoin IDがcoin ID treeのどこかにあることの証明

(すべてのコインIDの合計セットのルートであるRへのMerkleブランチ)

2. その同じcoin IDがユーザが提供したAssosiation setのどこかにあること

(提供されたAssosiation setのルートRAへのMerkleブランチ)

WithdrawalがどのDepositから来たのか、または非二重支出の証明を超えて情報をまったく提供しないことをユーザーに要求するのではなく、ユーザーに資金の起源のセットを提供させる。このセットは彼らが望むだけ広くまたは狭くすることができる。

つまりMerkle ForestのようにAssosiaction Setを構築しろってこと？

どこからどこまでを秘匿化するか調整できそう。blacklistとは違う？

2.3 Assosiation setの使い方

5人のユーザ(Alice, bob, Carl, David,Eve)のうち、1人(Eve)が反社だとする

Suppose also that this is publicly known. The public may not know Eve’s real-world identity, but they have enough evidence to conclude that the coins sent to the address that we are labeling “Eve” are stolen. This is often the case in practice: most of the illicit funds that have been identified flowing into Tornado Cash have come from a DeFi protocol exploit, an event which is visible on the public blockchain.

と仮定されているが、これはSDN ListなどのBlacklistがある前提？

この5人がそれぞれWithdrawalする際、どのassosiation setを指定するか選択できる。

彼らのassosiation setには自分のdepositが含まれる必要があるが、他のアドレスのどれを含めるかは自由に選択できる

https://scrapbox.io/files/650135674bf857001cdcb08d.png

この自由度のおかげで、反社の1人をassosiation setに含めないようにアドレスを選択することで、プライバシーを最大化した上で不審なアドレスとの関わりを断つことができる。

assotion setを最大化させることがプライバシーの最大化に繋がるので、この例で彼らはassosiation set = {Alice, bob, Carl, David}

と選択するはずである。

https://scrapbox.io/files/64f9307b4154a3001b660171.png

2.4 Assosiation Setの構築

Assosiation Setを構築するにあたり、以下二つのzkpが必要になる

black listを元にproofを作るか、white listを元にproofを作るかはどっちでも良い。規制とか社会的要求次第

1. Inclusion Proof(Membership Proof)

特定の一連のdepositを識別し、それらのdepositだけを含むAssosiation setを構築する

2. Exclusion Proof

怪しいと判断される一連のdepositを特定し、それらのdepositを除外したAssosiation setを構築する

https://scrapbox.io/files/64fff4349fe271001b4efcc4.png

ユーザーがAssosiation setに含めるdepositを手動で選択して選択するようなことはせず、Assosiation set Provider(ASP)と言うAssosiation setを生成する第三者を呼び出すことができる。

ASPはAIやスマートコントラクトで構成されることが想定されており、Assosiation set tree のrootをオンチェーンに公開することが推奨されている。

Assosiation setをどのくらいの頻度で更新するのかなどについては、プロトコルの設計によって異なる。

仮にSDN Listを元にするとして、後からリストに追加された犯罪者については、リストに追加されるまで暴れ放題？

3. Arbitrary denominations

3.1multi in, multi out

UTXOモデルなZcashのように、各トランザクションは複数の入力(入力ごとにNullifierの公開が必要)と複数の出力(各出力にCoin IDの公開が必要)を持つこともできる。

Nullifierの有効性を証明することに加えて、以下のように作成されるコイン合計額が、使用されているコインの額面の合計を超えないことを保証する追加の証明(Value Commitment)を各取引に追加することで実現できる。

https://scrapbox.io/files/64fff86ba39540001c01d6fd.png

この設計は、UTXOベースのようにdepositを(暗号化されていない)inputとして扱い、withdrawalsを(暗号化されていない)outputとして扱うだけで、depositとwithdrawalsをサポートするように拡張できる。

この拡張を加えるとネイティブに分析を簡素化するように設計を制限できる。

例えば部分的なwithdrawalsを許可することで、トランザクションが1つの暗号化されたinputと2つのoutputを持つことができる

withdrawalsを表す1つの暗号化されていないoutputと、将来のwithdrawalsに使用できる残りの資金を表す暗号化されたoutput

3.2 Arbitrary denominationsの課題

とはいえ、この設計はいささか直感的ではない。

例えば、ユーザーが10コインの預金を行い、それを1 + 2 + 3 + 4コインの4回の引き出しで支出した場合、直感的にはこれらの4つの引き出しすべてを元の10コインの預金をソースとして扱いたい。

しかし、実際には最初のwithdrawalsは10コインのdepositをソースとして持っているが、その後2番目のwithdrawalsは、最初のwithdrawalsから生じた9コインのおつりをソースとして持っており、以降も同様となってしまう。

また、これだとASPが中間のDepositを確認しAssosiation setに追加する必要がある

https://scrapbox.io/files/64fff945181467001c3a6daf.png

この例の4つの引き出しすべてが元の10コインの預金をソースとして主張できるように(直感的に)したい場合、同時に2つの問題を解決する必要がある。

1. 各部分的な引き出しを互いに公然と関連付けないようにすること

2. 各部分的な引き出しに、そのAssosiation setの一員としてdepositを主張させること

3.3Arbitrary denominationsの改善

もし部分withdrawのみ(multi in-multi outは無視)をサポートし、各withdrawが単一の元のdepositを持つことを確実にするなら、Txを介して情報のコミットメントを伝播させるとシンプルに実現できる。

具体的には、TxにCommitment hash(coinID+hash(r))を含むことを要求し、ZK-SNARKにTx内のコミットメントがその親Txと同じ値にコミットすることを証明させる

bindのためにいくつかのランダム値rを追加

親Txがwithdrawである場合は、元のdepositのcoin IDにコミットメントすることを単純に要求できる。

その結果、チェーン内の各Txは、元のdeposit coin IDへのコミットメントを含む必要があり、この値がTxが提供したAssosiation setにあることが証明される。

3.4 coin merge

balance-summing attacksに対するプライバシーを向上させるためにcoin mergeのサポートが推奨されている。

たとえば、10枚のコインを入金し、7.2859だけwithdrawした後で、2.7141をwithdrawした場合、これらの2つの引き出しは金額のみに基づいて相関する可能性があり、推測できる。

具体的にコインがいくつか残っている場合に次の入金と一緒にマージさせる。

このようなシナリオに適応するために、Txが一連のコインIDにcommitすることを要求し、複数のinputを持つTxは、その親Txの合併をコミットすることを要求する。

withdrawには、commitされたすべてのcoin IDがassociation setにあるというproofが含まれる。

以下直訳のみ(2023/09/12)

4.Additional Proofs

4.1 Re-Proofing

ユーザーがdepositをwithdrawするには、depositに関する秘密の情報を必要とする。

シナリオ1:Aliceが自分の資金を引き出すために、Assosiation setのmembership proofを作成して公開した場合

後で、彼女は異なるセットに対する証明を提供することが必要な商人に対して資産を使う場合、新しい証明を商人のAssosiation setに対して生成できる。

同様に、Aliceは初期のAssosiation setの更新バージョンに対して新しい証明を生成できる。

シナリオ2:特定のイベントの調査

一連のオンチェーンのコインに関与する悪い行動が起こり、調査の結果これらのコインがどのinputから来たかセットが明らかになったと仮定する。

対象のコインがAssosiation setが小規模なコミュニティであるwithdrawalから来た場合、またはオンチェーンの証拠と他の情報の組み合わせにより、イベントの背後に誰がいるかについて部分的な情報が明らかになったため判明するなど

この場合、他のメンバーは自分たちの無実を証明し加害者の身元を明らかにするために、そのイベントからの除外を証明する。

4.2 Bilateral Direct Proofs

シナリオ3

Aliceが引き出した資金を銀行に預けたい場合、銀行は資金の出所に関する完全な情報を求める場合

その場合、Aliceは自身のdepositのみを含むassosiation setを作成し、このセットに対する証明を構築する。

この証明を共有することは、受信者がそれをさらに広めないという信頼を前提とし、他にステークホルダがいない場合にのみプライバシーに貢献すると言える

もう一つの高度なオプションは、Aliceが次のいずれかの記述が正しいことをゼロ知識で証明することです：

(i)「この引き出しはこの関連セットに含まれています」、または

(ii)「私は銀行です」

(iii)「この特定のタイムスタンプサービス（サーバーまたはブロックチェーンであることができます

証明をリアルタイムで受け取る銀行のみ（iii）で、自分たち自身が証明を作成しなかったことを知っている（ii）場合、その証明を信頼できるでしょう。

証明が他の誰かの手に渡った場合、その証明が偽造されていないことを受信者に説明するのは難しいでしょう。これにより、プライバシーの漏洩に関する対立当事者のリスクの大部分が取り除かれます。

4.3 Sequential Proofs

depositおよびwithdrawトランザクションタイプに加えて、プロトコルは既存のコインIDを消費し、他の誰かが所有する新しいコインIDを生成する内部送金操作をサポートする必要がある。

例えばAliceが所有するコインIDを消費し、Bobが提供したパラメータで新しいコインIDを作成する内部送金を行う場合(=AliceがコインをBobに送金する場合)、Bobはそのコインを即座に消費しCarlに送金したい

ここで関連性の遅延という課題が発生する。

資金の出所がAliceではなくAliceのウォレットから資金を盗んだ可能性がある他の誰かかもしれないため、ASPはBobの新しいコインを直ちにAssosiation setに追加する意思を持たないかもしれない。

また、スピーディな取引が求められるdefiの文脈では、この関連性の遅延は致命的なUXをもたらす。

関連性の遅延は、Aliceが事件を報告する時間を与えたり、第三者がそれを検出する時間を与えるために存在した方が良い。

この問題の可能な解決策は、ユーザーのウォレット内のコインが十分に時間が経ってしてAssosiation setに含まれるような場合、ユーザーはそれらをプライバシーを保護しないトランザクションを通じて送信することができるというもの。

Assosiation setに追加されるど古い歴史は無視でき、より最近の歴史は先に渡す必要があるという考え方

情報の漏洩を最小限に抑える具体的な方法として、BobがCarlに支払う際にBobは支払いの生成に使用されたMerkleブランチと秘密情報をCarlに直接提供する。これにより、CarlはBobが見ているものと同じものを見ることができるようになる。

つまり、Aliceからの支払いがコインの履歴に含まれていたことを見ることができる。

後で、いくつかの悪人に関連する多数のコインが堆積され、すぐに再循環されたことが判明した場合、Carlは彼のコインが悪人から切り離されたソースから来たことを証明することができる。

https://scrapbox.io/files/65004d48ec0889001b209559.png

気になる点

Ethereum以外もおけ？

アドレスとか鍵生成は？

ただのホワイトリスト

deposit-withdrawlなど、外とのつながりも秘匿化できるの？[

参考資料