Vitalik :中央集権型取引所はどのように資金証明を行うのか?
著者:Vitalik
編訳:董一鸣,ChainCatcher
重要な中央集権型取引所が崩壊するたびに、よくある疑問が提起されます。それは、私たちが問題を解決するために暗号技術を使用できるかどうかということです。取引所は、ユーザーに対する負債を支払うのに十分な資金をオンチェーンで保有していることを示す暗号証明を作成することができます。これは、政府の許可、監査人、取引所の運営や個人の背景を審査する企業ガバナンスなどの「法定」手法に依存するのではなく、です。
取引所は、預金者の同意なしに資金を引き出すことができないシステムを構築することができます。潜在的には、「悪いことをしない」という志を持つ良い人のCEXと、「悪いことをすることができない」が、現在は非効率的でプライバシーが漏洩するオンチェーンDEXの間の全スペクトルを探ることができます。この記事では、取引を信頼なしに近づけるための一歩または二歩の歴史的な試み、これらの技術の限界、そしてZK-SNARKsやその他の先進技術に依存する更新されたより強力なアイデアについて詳しく探ります。
バランスシート と Merkle ツリー :古典的な 清算能力証明
取引所は、ユーザーを欺いていないことを証明するために暗号学的手法を最初に試みたのは、かなり昔のことです。2011年、当時最大のビットコイン取引所であるMtGoxは、424242 BTCを事前に公表されたアドレスに送信することで、資金を保有していることを証明しました。2013年には、顧客の預金の総規模を証明する別の側面を解決する方法について議論が始まりました。顧客の預金がXに等しいことを証明し(「負債証明」)、Xコインの秘密鍵の所有権を証明すれば(「資産証明」)、あなたは清算能力の証明を得ることができます:取引所はすべての預金者に返済するための資金を持っていることを証明したのです。
預金を証明する最も簡単な方法は、単に(ユーザー名、残高)のペアのリストを公開することです。各ユーザーは、自分の残高がリストに含まれているかどうかを確認でき、誰でも完全なリストを確認して(i)各残高が非負であること、(ii)合計金額が賠償金額であることを確認できます。もちろん、これはプライバシーを損なうため、私たちは少しシナリオを変更できます:ハッシュ(ユーザー名、salt)、残高のペアのリストを公開し、各ユーザーにsalt値を個別に送信します。しかし、これでも残高が漏洩し、残高の変動パターンが漏洩する可能性があります。プライバシーを保護する願望は、次の発明へと私たちを導きました:Merkle ツリー(またはハッシュツリーとも呼ばれる)技術。
緑:Charlieノード。青:Davidノード、Charlieが受け取るノードで、彼の証明の一部として。黄:ルートノード、皆に公開される。
Merkleツリー技術は、顧客の残高表をMerkle sum treeに配置することです。Merkle sum treeでは、各ノードは(残高、ハッシュ)のペアです。下層の葉ノードは、個々の顧客の残高とsaltedユーザー名のハッシュ値を表します。各上層ノードでは、残高は下の2つの残高の合計であり、ハッシュ値は下の2つのノードのハッシュ値です。Merkle sum証明は、Merkle証明と同様に、葉から根へのパス上の姉妹ノードで構成されるツリーの「枝」です。
取引所は、各ユーザーにその残高のMerkle sum証明を送信して、彼らの残高を証明します。ユーザーは、彼らの残高が合計の一部として正しく含まれていることが保証されます。簡単なコード例は、++こちら++から見つけることができます。
この設計におけるプライバシー漏洩は、完全に公開されたリストよりもはるかに少なく、各回のルートを公開する際に枝をシャッフルすることでさらにプライバシー漏洩を減らすことができますが、いくつかのプライバシー漏洩は依然として存在します。Charlieは、ある人の残高が164ETHであり、2人のユーザーの残高が合計70ETHであることを知ることができます。多数のアカウントを制御する攻撃者は、取引所のユーザーに関する大量の情報を知る可能性があります。
このスキームの重要な微妙な点は、負の残高の可能性です:もし取引所が1390ETHの顧客残高を持っているが、890ETHの準備金しかない場合、ツリーのどこかの偽のアカウントの下に-500ETHの残高を追加して差額を埋めようとしたらどうなるでしょうか?実際、この可能性はこのスキームを破壊することはありませんが、これが私たちが特にMerkle sumツリーが必要な理由です。仮にHenryが取引所が制御する偽のアカウントであり、取引所がそこに-500ETHを置いたとしましょう。
Gretaの証明検証は失敗します:取引所は彼女にHenryの-500 ETHノードを提供しなければならず、彼女はそれが無効であるため、そのノードを拒否します。EveとFredの検証も失敗します。なぜなら、Henryの上の中間ノードのETHの合計が-230であり、それも無効だからです!盗難から逃れるために、取引所はツリーの右半分の誰も残高証明を確認しないことを望まなければなりません。
もし取引所が500ETHの価値のあるユーザーを特定でき、これらのユーザーが証明を確認することに気を使わないか、証明を受け取ったことがないと不平を言ったときに信じられないと信じているなら、彼らは盗難の罰から逃れる自信を持つことができます。しかし、取引所はこれらのユーザーをツリーから除外することもでき、同じ効果を得ることができます。
したがって、負債証明の目標を達成するためだけであれば、Merkleツリー技術は基本的に負債証明スキーム(proof-of-liabilities)と同じくらい良いです。しかし、そのプライバシー属性は依然として理想的ではありません。Merkleツリーをより巧妙に使用することで、例えば++各satoshiまたはweiを個別の葉にする++ことができますが、最終的には、より現代的な技術を用いて、より良い方法があります。
ZK-SNARKsを用いたプライバシーと堅牢性の改善
ZK-SNARKsは強力な技術です。ZK-SNARKsが暗号学において果たす役割は、トランスフォーマーが人工知能において果たす役割と同じかもしれません:それは非常に強力な汎用技術であり、数十年前に開発された特定のアプリケーション技術の多くの問題を完全に打ち砕くでしょう。したがって、もちろん、私たちはZK-SNARKsを使用して責任証明プロトコルのプライバシーを大幅に簡素化し改善することができます。
私たちができる最も簡単なことは、すべてのユーザーの預金をMerkleツリー(またはより簡単に、++KZGコミットメント++)に入れ、ZK-SNARKを使用してそのツリー内のすべての残高が非負であり、合計がある主張された値に等しいことを証明することです。プライバシーのためにハッシュの層を追加すれば、各ユーザーのMerkleブランチ(またはKZG証明)は他のユーザーの残高を漏洩することはありません。
KZGコミットメントを使用することは、プライバシー漏洩を回避する一つの方法です。なぜなら、証明として「姉妹ノード」を提供する必要がなく、単純なZK-SNARKを使用して残高の合計を証明し、各残高が非負であることを証明できるからです。
私たちは、上記のKZGにおける残高の和と非負性を証明するために特別用途のZK-SNARKを使用できます。これを実現するための簡単な例があります。私たちは補助多項式を導入し、それが「各残高のビットを構築」します(例として、残高があると仮定します)そして、各16の位置でオフセットされた累積和を追跡します。したがって、実際の合計が主張された合計と一致する場合にのみ、その合計はゼロになります。もしzが-128次の単位根であれば、次の等式を証明できます。
有効な設定の最初の値は0 0 0 0 0 0 0 0 0 0 1 2 5 10 20 -165 0 0 0 0 0 0 0 0 1 3 6 12 25 50 -300 …
このような方程式を多項式チェックに変換し、さらにZK-SNARKに変換する方法については、私の++ZK-SNARKに関する記事の++++こちら++および++こちら++でのさらなる説明を参照してください。これは最適なプロトコルではありませんが、これらのタイプの暗号証明が最近ではそれほど奇妙ではないことを示しています!
数個の追加の公式を加えることで、このような制約システムはより複雑な環境に適応できます。例えば、レバレッジ取引システムでは、個々のユーザーが負の残高を持つことは許容されますが、その前提として、彼らは担保保証金のある資金をカバーするのに十分な他の資産を持っている必要があります。SNARKは、このより複雑な制約を証明するために使用でき、ユーザーは取引所が他のユーザーの資金にリスクをもたらさないことを安心できます。
長期的には、このZK負債証明は、顧客の取引所での預金だけでなく、より広範なローンにも使用されるかもしれません。誰かがローンを借りるとき、そのローンを含む多項式またはツリーに記録が残され、その構造の根がチェーン上に公開されます。これにより、ローンを求める人は、貸し手に対して、他のローンを借りすぎていないことをZK証明で提供できます。最終的には、法的な革新により、このように約束されたローンは、約束されていないローンよりも高い優先度を持つことができるかもしれません。これは、++「分散型社会++ ++:++ ++Web3の魂を探す」++で議論されているアイデアと完全に同じ方向に私たちを導きます:何らかの形の「魂のトークン(soulbound token)」を通じて、チェーン上に負の評判または担保の概念を構築することです。
資産証明
資産証明の最も簡単なバージョンは、上記で見たプロトコルです:あなたがX枚のコインを保有していることを証明するためには、事前に合意された時間に、またはデータフィールドに「これらの資金はBinanceのものである」と含まれる取引でX枚のコインを移動させるだけです。取引手数料を回避するために、オフチェインの情報に署名することもできます。ビットコインとイーサリアムの両方には、オフチェイン署名情報の標準があります。
この単純な資産証明技術には、2つの実際的な問題があります。
- 「コールドストレージ」 の取り扱い
- 担保の二重利用
セキュリティ上の理由から、ほとんどの取引所は顧客の資金の大部分を「コールドストレージ」に保管します:オフラインのコンピュータ上で、取引は手動で署名され、インターネットに転送されます。私が個人資金のために設定したコールドストレージは、署名された取引を含むQRコードを生成する恒久的にオフラインのコンピュータを使用していました。私はスマートフォンでそれをスキャンできます。現代の取引プロトコルはさらに複雑で、しばしば複数のデバイス間でのマルチパーティ計算を含みます。このような設定を考えると、アドレスの制御を証明するための追加情報でさえ、高価な操作です!
取引は以下のいくつかの経路を取ることができます:
- いくつかの公開された長期使用のアドレスを保持する。取引所は、いくつかのアドレスを生成し、各アドレスに対して一度証明を公開して所有権を証明し、その後これらのアドレスを再利用します。これはこれまでのところ最も簡単なスキームですが、セキュリティとプライバシーを保護する方法にいくつかの制限を追加します。
- 多くのアドレスを設定し、ランダムにいくつかを証明する。取引所は多くのアドレスを持ち、場合によっては各アドレスを一度だけ使用し、取引後に退役させます。この場合、取引所は時折ランダムにいくつかのアドレスを選択し、所有権を証明するために「開く」必要があるプロトコルを持つかもしれません。一部の取引所は監査人と類似のことを行っていますが、原則としてこの技術は完全に自動化されたプログラムに変わる可能性があります。
- より複雑なZKPオプション。例えば、取引所はすべてのアドレスを1/2のマルチシグに設定し、各アドレスの鍵が異なり、もう一つは「重大な」緊急バックアップ鍵のブラインド版を、12/16のマルチシグのような非常に高いセキュリティで保存します。プライバシーを保護し、アドレスの全集合を露出させないために、取引所はブロックチェーン上でゼロ知識証明を実行し、この形式のアドレスの合計残高を証明することもできます。
もう一つの主要な問題は、担保の二重利用を防ぐことです。取引所は、実際に清算能力がない場合に、担保を相互に移動させて準備金証明を行うことが容易です。理想的には、清算能力の証明はリアルタイムで行われ、各ブロックの後に証明が更新されるべきです。これが現実的でない場合、次善の選択肢は、異なる取引所間で固定のスケジュールを調整することです。例えば、毎週火曜日のUTC 14時に準備金を証明することです。
最後の問題は、法定通貨で資産証明を行うことができるかということです。取引所は単に暗号通貨を保有するだけでなく、銀行システム内に法定通貨を保有しています。ここでの答えは、可能ですが、そのようなプログラムは避けられない「法定通貨」信頼モデルに依存することになります:銀行自体が残高を証明し、監査人がバランスシートを証明することができます。法定通貨が暗号的に検証できないことを考慮すると、これはその枠組み内でできる最善のことですが、それでもやる価値があります。
もう一つの方法は、取引所を運営し、USDCなどの資産で裏付けられたステーブルコインを処理する実体と、暗号通貨と伝統的な銀行システム間で現金を移動させるプロセスを処理する実体(USDC自体)をきれいに分けることです。USDCの「負債」は単にチェーン上のERC20トークンであるため、負債証明は「無料」であり、資産証明だけが必要です。
Plasma とvalidium:CEXを拘束から解放できるか?
私たちがさらに進みたいと仮定しましょう:私たちは取引所がユーザーの資金を盗むことを完全に防ぎたいのです。
この分野での最初の大きな試みはPlasmaであり、これは2017年と2018年にイーサリアムの研究コミュニティで人気のあったスケーリングソリューションです。Plasmaの仕組みは、残高を一連の個別の「コイン」に分割し、各コインにインデックスを割り当て、PlasmaブロックのMerkleツリーの特定の位置に配置することです。コインを有効に移転するには、取引をツリーの正しい位置に置く必要があり、ツリーの根はチェーン上に公開されます。
Plasmaの過度に単純化されたバージョンの図。コインはスマートコントラクトに保管され、引き出し時にPlasmaプロトコルのルールが強制されます。
OmiseGoはこのプロトコルを基にした分散型取引所を試みましたが、それ以来、彼らは他のアイデアに移行しました---この点に関しては、Plasmaグループ自体もそうであり、現在はoptimistic EVMのロールアッププロジェクト++Optimism++です。
2018年に想定されたPlasmaの技術的限界(例えば、++コインの断片化の証明++)は、見る価値がありません。2018年のPlasmaの議論のピーク以来、ZK-SNARKsはスケーリングに関連するユースケースでより実行可能になり、上記のように、ZK-SNARKsはすべてを変えました。
Plasmaのアイデアのより現代的なバージョンは、Starkwareが呼ぶところの++validium++です:基本的にZK-rollupと同じですが、データはチェーン外に保存されます。この構造は多くのユースケースに使用でき、集中型サーバーがいくつかのコードを実行し、その正しい実行を証明する必要がある状況を想像できます。validium内では、オペレーターは資金を盗む方法がなく、実装の詳細によっては、オペレーターが消えると一部のユーザー資金がロックされる可能性があります。
すべてが本当に良いです:CEXとDEXは二元的な対立関係ではなく、実際には、効率性のような利点を得ながら、中央集権的な運営者がほとんどの形の乱用に関与することを防ぐためのさまざまな形の混合中央集権の選択肢があることが証明されています。
しかし、この設計空間の右半分では、最も基本的な問題について議論する必要があります:ユーザーエラーの処理。これまでのところ、最も重要なエラーのタイプは、ユーザーがパスワードを忘れた場合、デバイスを失った場合、ハッキングされた場合、または他の方法でアカウントへのアクセスを失った場合にどうするかです。
取引所はこの問題を解決できます:最初は電子メールによる回復で、これが失敗した場合は、KYCを通じてより複雑な回復形式を行います。しかし、このような問題を解決するためには、取引所がコインに対する実際の制御を持っている必要があります。ユーザーアカウントの資金を良い理由で回復する能力を持つためには、取引所は権限を持っている必要があり、悪い理由でユーザーアカウントの資金を盗むために使用される可能性もあります。これは避けられないトレードオフです。
理想的な長期的解決策は、自己保管に依存し、++マルチシグ++ ++および社会的回復ウォレット++](https://vitalik.ca/general/2021/01/11/recovery.html)などの技術を補完して、ユーザーが緊急事態に対処できるようにすることです。しかし短期的には、明らかにコストと利益が異なる2つの代替案があります。
結論:より良い取引所の未来
短期的には、明らかに2つの取引所「カテゴリ」があります:管理型取引所と非管理型取引所。今日、後者は単にDEX、例えばUniswapのようなものであり、将来的には、ユーザーの資金がvalidiumスマートコントラクトのようなものに保管される暗号学的に「制約された」CEXも見ることができるかもしれません。私たちはまた、法定通貨ではなく暗号通貨を信頼する半管理型取引所を見るかもしれません。
これらの2つのタイプの取引所は引き続き存在し、管理型取引所のセキュリティを向上させる最も簡単な後方互換性のある方法は、準備金証明を増やすことです。これには、資産証明と負債証明の組み合わせが含まれます。これら2つのために良いプロトコルを策定することには技術的な課題がありますが、私たちは可能な限りこの2つの分野で進展を遂げ、ソフトウェアとプロセスをオープンソース化して、すべての取引所が利益を得られるようにすべきです。
長期的には、すべての取引所が非管理型であることにますます近づくことを望んでいます。少なくとも暗号通貨に関しては。ウォレットの回復は存在し、小額の新規ユーザーや法的理由からこのような取り決めが必要な機関のためには、高度に集中化された回復オプションが必要かもしれませんが、これは取引所自体ではなく、ウォレットレベルで行うことができます。++magic.link++と++Polymarket++などのプラットフォームとのインタラクションの方法は、このアプローチの一例です。法定通貨に関しては、伝統的な銀行システムと暗号通貨エコシステム間の流動性は、資産で裏付けられたステーブルコイン(USDCなど)の現金の流入/流出プロセスを通じて行うことができます。しかし、私たちがこの目標に完全に到達するまでには、まだ時間がかかります。
Balaji Srinivasan、Coinbase、Kraken、Binanceのスタッフとの議論に特別な感謝を申し上げます。