原題：「Having a safe CEX: proof of solvency and beyond》
原題：「
原作者: ヴィタリック・ブテリン
原文編集：Double Spending（@doublespending）
Balaji Srinivasan 氏と、議論に協力してくれた Coinbase、Kraken、Binance のチームに特に感謝します。
大規模な集中型取引所がクラッシュするたびによく聞かれる質問は、暗号化を使用してこの問題を解決できるかどうかです。同取引所は、政府のライセンス、監査人、コーポレート・ガバナンスの調査、法人バックトラッキングなどの「法定通貨」プログラムだけに依存するのではなく、暗号証明を作成することで、チェーン上に保持されている資金がユーザーに返済するのに十分であることを証明できる。
もっと野心的なこととしては、取引所が預金者の同意なしに預金者の資金を引き出すことができないシステムを創設する可能性がある。 「悪を行わない」プロフェッショナルな CEX と、「悪を行うことはできない」がプライバシーを漏らす非効率なオンチェーン DEX との間の境界を探ることができます。この投稿では、CEX をよりトラストレスにしようとする歴史的な試み、そのテクノロジーの限界、および ZK-SNARK のような高度な技術に依存する強力な手段について詳しく説明します。
残高表とマークル ツリー: 従来の返済証明
ユーザーを騙していないことを証明するために取引所が暗号を使用しようとした最初の試みは、はるか昔に遡ります。 2011年、当時最大のビットコイン取引所だったMtGoxは、事前に公開されたアドレスに424,242BTCを移動するトランザクションを送信することで、資金を所有していることを証明した。 2013 年に、問題のもう一方の側面、つまりユーザーの預金総額の証明を解決する方法についての議論が始まりました。ユーザーの預金が X に等しいこと (負債の証明) を証明し、X トークンの秘密鍵を持っていること (資産の証明) を証明すれば、支払能力の証明を提供することになります。つまり、取引所に返済できるだけの十分な資金があることを証明することになります。預金者。
デポジットの証拠を提供する最も簡単な方法は、リストを公開することです。すべてのユーザーがリスト内の残高を確認でき、誰でも完全なリストを確認できます: (i) 各残高がマイナスではない; (ii) 合計が申告額である。
リストを作成し、ソルト値をユーザーに非公開で送信します。しかし、これでも残高とその配分が漏れてしまいます。プライバシーを守るため、後続技術であるマークルツリーテクノロジーを採用しました。
緑: チャーリーのノード。青: チャーリーは認証用のノードを受け取りました。黄色: ルート ノード、全員に通知
マークル ツリー テクノロジは、ユーザー残高テーブルをマークル合計ツリーに組み込みます。マークル和ツリーでは、各ノードはペアです。基礎となるリーフ ノードは、個々のユーザーの残高とユーザー名のソルト付きハッシュを表します。各上位ノードでは、残高は下位の 2 つのノードの残高の合計であり、ハッシュは下位の 2 つのノードのハッシュです。マークル和証明は、マークル証明と同様に、リーフ ノードからルート ノードまでのパス上のすべての姉妹ノードで構成される「分岐」です。
# The function for computing a parent node given two child nodes
def combine_tree_nodes(L, R):
L_hash, L_balance = L
R_hash, R_balance = R
assert L_balance >= 0 and R_balance >= 0
new_node_hash = hash(
L_hash + L_balance.to_bytes( 32, 'big') +
R_hash + R_balance.to_bytes( 32, 'big')
)
return (new_node_hash, L_balance + R_balance)
# Builds a full Merkle tree. Stored in flattened form where
# node i is the parent of nodes 2 i and 2 i+ 1
def build_merkle_sum_tree(user_table: "List[(username, salt, balance)]"):
tree_size = get_next_power_of_ 2(len(user_table))
tree = (
[None] * tree_size +
[userdata_to_leaf(*user) for user in user_table] +
[EMPTY_LEAF for _ in range(tree_size - len(user_table))]
)
for i in range(tree_size - 1, 0, -1):
tree[i] = combine_tree_nodes(tree[i* 2 ], tree[i* 2+ 1 ])
return tree
# Root of a tree is stored at index 1 in the flattened form
def get_root(tree):
return tree[ 1 ]
# Gets a proof for a node at a particular index
def get_proof(tree, index):
branch_length = log 2(len(tree)) - 1
# ^ = bitwise xor, x ^ 1 = sister node of x
index_in_tree = index + len(tree) // 2
return [tree[(index_in_tree // 2**i) ^ 1 ] for i in range(branch_length)]
# Verifies a proof (duh)
def verify_proof(username, salt, balance, index, user_table_size, root, proof):
leaf = userdata_to_leaf(username, salt, balance)
branch_length = log 2(get_next_power_of_ 2(user_table_size)) - 1
for i in range(branch_length):
if index & ( 2**i):
leaf = combine_tree_nodes(proof[i], leaf)
else:
leaf = combine_tree_nodes(leaf, proof[i])
return leaf == root
まず、取引所は各ユーザーに残高のマークル合計証明を送信します。ユーザーは、自分の残高が合計額の一部として正しく含まれていることを確認できます。簡単なサンプルコードはここにあります。
この設計の下でのプライバシー漏洩は、完全な貸借対照表の開示よりもはるかに低く、マークルルートがリリースされるたびに各ブランチを中断してプライバシー漏洩のリスクをさらに減らすことができますが、それでもプライバシー漏洩の問題がいくつかあります: チャーリーは知っていますある人が 164 ETH の残高を持っている、2 人のユーザーの残高の合計が 70 ETH であるなど。複数のアカウントを制御する攻撃者は、取引所のユーザーについて多くのことを知る可能性があります。
このスキームの重要な微妙な点は、残高がマイナスになる可能性があることです。ユーザー残高が 1390 ETH であるのに、準備金が 890 ETH しかない取引所が、ツリー内のどこかの偽アカウントの下に -500 ETH 残高を追加することでそれを埋め合わせようとした場合、違います、どうすればいいですか？この可能性は実際にスキームを壊すものではないため、通常のマークル ツリーの代わりにマークル サム ツリーを意図的に使用します。ヘンリーが取引所によって管理されている偽のアカウントであり、取引所がそれに -500 ETH を設定したとします。
グレタさんの認証はパスしません。取引所が彼女のヘンリーのノードに -500 ETH の残高を与える必要があるとき、彼女は無効なノードを拒否するでしょう。イブとフレッドも検証に失敗します。ヘンリーの上の中間ノードの残高が -230 ETH であるため、このノードも無効です。不正流用が検出されないようにするには、取引所はツリーの右半分が残高証明のためにチェックされないことを祈るしかありません。
取引所が、残高証明をわざわざ確認しようとしない、または残高証明を受け取らないと苦情を言っても信じない500 ETHを持っているユーザーを選び出すことができれば、取引所は問題を回避できるだろう。ただし、取引所はこれらのユーザーをマークル合計ツリーから除外することによっても同じ効果を達成できます。したがって、負債の証明という点に限れば、マークル ツリー テクノロジーは基本的にニーズを満たします。しかし、そのプライバシー機能はまだ理想的ではありません。 satoshi または wei を独立したリーフ ノードとして使用するなど、マークル ツリーをより巧妙に使用して改善することができます。ただし、より高度なテクノロジーを使用することで、さらに優れたものを実現できます。
ZK-SNARK を使用してプライバシーと堅牢性を向上させる
ZK-SNARK は強力なテクノロジーです。 ZK-SNARK が暗号化に対して行うことは、人工知能に似ています。人工知能は、さまざまな問題を解決するために数十年前に開発されたさまざまな特殊な技術を圧倒できる汎用テクノロジーです。したがって、もちろん、ZK-SNARK を使用して、債務証明プロトコルのプライバシーを大幅に簡素化し、向上させることができます。
すべてのユーザーの預金をマークル ツリー (またはより単純な KZG コミットメント) に単純に入力し、ZK-SNARK を使用して、ツリー内のすべての残高がマイナスではなく、合計すると請求額になることを証明できます。プライバシーのためにハッシュ層を追加すると、各ユーザーに送信されるマークル フォーク (または KZG 証明) によって他のユーザーの残高が明らかになることはありません。
KZG コミットメントの使用は、証拠として「姉妹ノード」を提供する必要がなく、単純な ZK-SNARK を使用して残高の合計を証明でき、各残高が負ではないため、プライバシー漏洩を回避する方法です。
専用の ZK-SNARK を通じて、上記の KZG の残高の合計とその非負性を証明できます。以下に簡単な例を示します。 「ユーザーの残高のあらゆるビットを構築する」補助多項式 I(x) を導入します (例のために、残高が 2 15 未満であると仮定します)。ここで、16 番目ごとの位置は、実際の残高の場合にのみ保証される差を追跡します。 total is等しい 合計が値に等しいと主張し、値は 0 になります。 z が 128 次の原始根である場合、次の方程式が成り立つことを証明できます。
[ 1 ] 翻訳者注: この多項式の解釈。
これらの方程式を多項式補正に変換し、それから ZK-SNARK に変換する方法については、ZK-SNARK に関する私の記事をここおよび別の場所で参照してください。これは最適なプロトコルではありませんが、これらの暗号の証明を理解できるものにします。
数式を追加するだけで、制約システムをより複雑な設定に適合させることができます。たとえば、レバレッジ取引システムでは、個々のユーザーがマイナスの残高を持つことが許容されますが、それは負債をカバーするのに十分な担保資産がある場合に限られます。 SNARK を使用すると、このより複雑な制約を証明することができ、取引所が密かに特定のユーザーをルールから除外してユーザー資産を危険にさらすことはできないことをユーザーに保証できます。長期的には、この ZK 責任証明の有用性は取引所へのユーザーの預金に限定されず、より幅広い融資シナリオでも使用できます。ローンを組む人は誰でも、そのローンを含む多項式またはツリーにレコードを入力し、ルートがオンチェーンで公開されます。これにより、ローンを求めている人は誰でも、他にあまり多くのローンを借りていないというゼロ知識の証明を貸し手に提供できるようになります。最終的には、法的革新により、この方法でコミットされたローンがコミットされていないローンよりも優先されることさえ可能になる可能性があります。これは私たちと一緒です「分散型社会：Web3の魂を探る」
で説明したアイデアと一致するアイデア: オンチェーンの否定的な評判の概念は、ある形式の「魂に縛られたトークン」を通じて可能になります。
資産の証明
Proof of Assets の最も単純なバージョンは、上で見たプロトコルです。X トークンを保有していることを証明するには、あらかじめ決められた時間に X トークンを移動するか、トランザクションで「これらの資金は Binance に属します」というメッセージを伝えるだけです。取引手数料の支払いを避けるために、オフチェーン メッセージに署名できます。ビットコインとイーサリアムの両方には、オフチェーン署名メッセージ標準があります。
この単純な資産証明手法には、実際上 2 つの問題があります。
コールドウォレットの取り扱い
担保の再利用
セキュリティ上の理由から、ほとんどの取引所はユーザー資金の大部分をコールドウォレットに保管しています。オフラインのコンピューターでは、トランザクションは手動で署名され、インターネットに送信される必要があります。このアプローチは一般的です。私が個人資金を永久にオフラインのコンピューターに保存するために使用したコールド ウォレットは、署名されたトランザクションを含む QR コードを生成し、それを携帯電話でスキャンします。資金が膨大なため、単一のデバイスがハッキングされることによって引き起こされる鍵漏洩の可能性をさらに減らすために、取引所で使用されるセキュリティプロトコルはより複雑になり、多くの場合、複数のデバイス間のマルチパーティ計算が含まれます。この文脈では、アドレスの制御を証明するために追加のメッセージを作成するだけでもコストがかかる操作になります。
取引所は次の方法を使用できます。
● 一部の公開アドレスを長期にわたって維持します。交換では複数のアドレスが生成され、各アドレスの所有権の証明が 1 回だけ発行され、これらのアドレスが再利用されます。これは最も簡単な解決策ですが、セキュリティとプライバシーの点でいくつかの制限が追加されます。
● 多数のアドレスを保持し、いくつかのアドレスをランダムに証明します。取引所は多数のアドレスを保持しており、各アドレスを 1 回だけ使用し、1 回のトランザクションの後は使用しない場合もあります。この場合、交換局は、時々いくつかのアドレスがランダムに選択されるという合意を得る必要があり、交換局は所有権を証明するためにアドレスを「オープン」する必要があります。一部の取引所ではすでに同様の操作に監査人を使用していますが、原理的にはこの手法を完全に自動化した手順に変えることができます。
● より複雑な ZKP アプローチ。たとえば、交換機はすべてのアドレスに 1/2 マルチ署名を設定でき、これらのアドレスの 1 つは異なるキーを持ち、もう 1 つは複雑だが安全な方法で同じキーを持ちます (例: 12/16 マルチ署名)。重要な緊急バックアップのブラインド バージョンを保存します。プライバシーを保護し、完全なアドレスの公開を避けるために、取引所はブロックチェーン上でゼロ知識証明を実行し、その形式でオンチェーンのアドレスの合計バランスを証明することもできます。
もう 1 つの大きな懸念は、担保の再利用を防ぐことです。取引所にとって、準備金を証明するために担保を相互にやり取りすることは多くの場合容易であり、実質的に債務超過に陥ることを回避できます。理想的には、支払い可能性の証明はリアルタイムで行われ、ブロックごとに証明が更新されるべきです。それが現実的でない場合、次善の策は、毎週火曜日の午後 2 時 (協定世界時) にリザーブを認証するなど、取引所間の認証時間を調整することです。
最後の質問は、資産を法定通貨で認証できるかということです。取引所は暗号通貨だけでなく、銀行システム内の法定通貨も保管しています。この点に関して、答えはイエスですが、そのようなプログラムは必然的に「法定通貨」の信頼モデルに依存することになります。銀行自体が残高を認証し、監査人が貸借対照表を認証するなどです。法定通貨は暗号的に検証できないことを考えると、これがこのフレームワーク内での最良のソリューションであり、それでも実行する価値があります。
別のアプローチは、エンティティ A をエンティティ B から分離することです。エンティティ B では、A が取引所を運営し、資産に裏付けられたステーブルコインである USDC を処理します。流出プロセス (この場合 B は USDC 自体です)。 USDC の「責任」はチェーン上の ERC 20 トークンのみであるため、責任の証明は「簡単に」取得でき、資産の証明の問題に対処するだけで済みます。
血漿とバリジウム: アンマネージド CEX を実現できるか?
さらに一歩進んで、取引所がユーザーに返済できるだけの十分な資金を持っていることを証明したいだけではないとします。代わりに、トランザクションがユーザーの資金を盗むことを完全に防止したいと考えています。
ここでの最初の早期採用者の 1 つは、2017 年と 2018 年にイーサリアム研究コミュニティで人気になったスケーリング ソリューションである Plasma です。 Plasma は、残高を独立した「トークン」のセットに分割することで機能し、それぞれにインデックスが割り当てられ、Plasma ブロックのマークル ツリー内の特定の位置に配置されます。有効なトークン転送が行われるためには、トランザクションがツリー内の正しい場所に配置され、ツリーのルートがチェーンにパブリッシュされる必要があります。
Plasma のバージョンのミニマルな図。トークンは、引き出し時にプラズマ プロトコルのルールを適用するスマート コントラクトに保持されます。
OmiseGo は、このプロトコルに基づいた分散型取引所を作成しようとしましたが、それ以来、他のことに移りました。さらに言えば、楽観的なロールアップ プロジェクト Optimism を擁する Plasma Group です。
Plasma の制限 (プルーフ トークンの最適化など) に関する 2018 年の議論では、Plasma の存続可能性に根本的な疑問が投げかけられました。プラズマに関する議論が 2018 年にピークに達して以来、ZK-SNARK は拡張関連のユースケースでますます実現可能になりました。上で述べたように、ZK-SNARK はすべてを変えました。
Plasma の新しいバージョンは、Starkware が validium と呼ぶもので、データがオフチェーンに保持されることを除いて、基本的に ZK ロールアップと同じです。この構造は多くのユースケースに適用でき、集中サーバーがコードを正しく実行したことを証明する必要があるあらゆるシナリオにも適用できる可能性があります。有効期間中、オペレーターは資金を盗むことはできませんが、具体的な実装の詳細によっては、オペレーターが失踪した場合に一部のユーザー資金が滞留する可能性があります。
今では素晴らしいように見えます。CEX と DEX はどちらからも遠く離れています。さまざまな形式のハイブリッド集中化を含む幅広いオプションがあり、効率性などの利点が得られますが、依然として多くの暗号が存在します。学術的な保証が可能です。集中管理されたオペレーターによるほとんどの悪意のある行為を防止します。
ただし、ユーザー エラーをどのように処理するかという、残りの基本的な問題についても考える価値があります。これまでのところ最も重要なタイプのエラーは、ユーザーがパスワードを忘れたり、デバイスを紛失したり、ハッキングされたり、アカウントにアクセスできなくなったりした場合はどうなるでしょうか?
Exchange は、まず電子メールの回復を活用し、それが失敗した場合は、KYC によるより複雑な回復を利用することで、この問題を解決できます。しかし、これらの問題を解決するには、取引所がこれらのトークンを実際に管理する必要があります。ユーザーの資金を合理的に回収できるようにするためには、取引所はユーザーの資金を理由なく盗むことができるのと同じ権限を持つ必要があります。これは避けられないトレードオフです。
理想的な長期的な解決策は自己保管に依存することであり、ユーザーは将来的にマルチシグやソーシャルリカバリウォレットなどのテクノロジーを簡単に使用して、緊急事態に対処できるようになります。短期的には、コストと利点が異なる 2 つの明らかな代替手段があります。
もう 1 つの重要な問題は、クロスチェーンのサポートです。取引所は多くの異なるチェーンをサポートする必要があり、Plasma や Validium などのシステムは、異なるプラットフォームをサポートするために異なる言語でコード化する必要があり、現在の形式では一部のプラットフォーム (特にビットコイン）は、技術のアップグレードと標準化によって解決されると予想されていますが、短期的には、これが保管取引所が今日も保管されているもう一つの理由です。
結論: 将来的にはより良い取引所を目指す
短期的には、取引所には、カストディアル取引所と非カストディアル取引所の 2 つの明確なカテゴリがあります。現在、後者のカテゴリーは Uniswap のような DEX であり、将来的には、ユーザー資金が Validium スマート コントラクトと同様の方法で保持される、暗号化によって制約された CEX も登場する可能性があります。また、仮想通貨ではなく法定通貨の取り扱いを信頼するセミカストディアル取引所も登場するかもしれません。
どちらのタイプの交換も今後も存続しており、保管交換のセキュリティのための下位互換性を向上させる最も簡単な方法は、予備の証明を追加することです。これには、資産の証明と負債の証明の組み合わせが含まれます。両方に適したプロトコルを設計するにはまだいくつかの課題がありますが、すべての取引所が利益を得られるように、両方のテクノロジーを連携させ、可能な限りオープンソースのソフトウェアとプログラムを推進できるし、そうすべきです。
長期的には、少なくとも暗号通貨に関しては、すべての取引所が保管されない方向に進むことを願っています。ウォレットの回復は存在し、資金が少ない新規ユーザーや法的理由でそのような取り決めを必要とする機関には、高度に集中化された回復オプションが必要となる場合がありますが、これは取引所内ではなくウォレット層で行うことができます。法定通貨に関しては、従来の銀行システムと暗号通貨エコシステムの間の移動は、USDC などの資産担保ステーブルコインのネイティブファンドの入出金プロセスを通じて完了できます。しかし、まだまだ道のりは長いです。
[1] 翻訳者注:
➤ 16 桁ごとにユーザーを表します（最初の 15 桁はユーザーの残高を表し、最後の桁はユーザーの残高とこれまでの明細の合計の差を表します）。上の例は 2 人のユーザーを表していることがわかります (読者はここで洞察が必要です)
➤ 主張された平均ユーザー残高: 185
➤ ユーザー 1 の残高: 20 -> 000 0000 0001 0100
差: 20 - 185 = -165
➤ ユーザー 2 の残高: 50 -> 000 0101 0011 0010
差: -165 + 50 -185 = -300
➤ すべてのユーザーを調べた後、最後のユーザーの残高要件は 0 になります
➤ 4 つの方程式の説明
式 1: 再帰の初期値は 0 です
式 2: 各ユーザー残高は KZG コミットメントに対応する必要があります式 3: 各ユーザーのバランスの再帰式、制約バランスは >= 0 であり、< 2 14 ，
< 2 14 (式 3 によれば、再帰式には I(zi) の値が 14 個しかないため、残高 < 2 15 は事務上の誤りであると言われています。
元のリンク
IOS
Android