アカウントベースのブロックチェーンの匿名性について

私たちは長い間、暗号通貨の匿名性というテーマに興味を持っており、この分野のテクノロジーの発展を追跡しようとしています。 私たちの記事では、動作原理についてすでに詳しく説明しました。 機密取引 Moneroでも実施されました 比較レビュー この分野に存在する技術。 しかし、今日のすべての匿名暗号通貨は、Bitcoin - Unspent Transaction Output (以下、UTXO) によって提案されたデータ モデルに基づいて構築されています。 イーサリアムのようなアカウントベースのブロックチェーンの場合、匿名性と機密性を実装するための既存のソリューション (たとえば、 メビウス または アステカ族）スマートコントラクトでUTXOモデルを複製しようとしました。

2019年XNUMX月、スタンフォード大学とVisa Researchの研究者グループが リリース プレプリント 「Zether: スマート コントラクトの世界でプライバシーを目指して」 著者らは、アカウントベースのブロックチェーンで匿名性を確保するアプローチを最初に提案し、機密（残高と送金金額を隠す）トランザクションと匿名（受信者と送信者を隠す）トランザクション用の XNUMX つのバージョンのスマート コントラクトを提示しました。 私たちは提案されたテクノロジーが興味深いと考えており、その設計を共有したいと思います。また、アカウントベースのブロックチェーンにおける匿名性の問題がなぜ非常に難しいと考えられているのか、そして作者がそれを完全に解決できたかどうかについても話したいと思います。

これらのデータモデルの構造について

UTXO モデルでは、トランザクションは「入力」と「出力」で構成されます。 「出力」の直接の類似点は財布の中の紙幣です。各「出力」には何らかの額面があります。 誰かに支払うとき（トランザクションを形成するとき）、XNUMX つ以上の「アウトプット」を費やします。この場合、それらはトランザクションの「インプット」となり、ブロックチェーンはそれらを支出済みとしてマークします。 この場合、支払いの受取人 (または、小銭が必要な場合はあなた自身) は、新しく生成された「出力」を受け取ります。 これは次のように図式的に表すことができます。

アカウントベースのブロックチェーンは、銀行口座とよく似た構造になっています。 彼らはあなたの口座内の金額と送金金額のみを扱います。 アカウントからいくらかの金額を送金する場合、「出力」を書き込むことはなく、ネットワークはどのコインが使用され、どのコインが使用されなかったのかを記憶する必要がありません。 最も単純なケースでは、トランザクションの検証は、送信者の署名と残高の金額を確認することになります。

技術の分析

次に、Zether が取引金額、受信者、送信者をどのように非表示にするかについて説明します。 その動作原理を説明する際に、機密バージョンと匿名バージョンの違いに注意してください。 アカウントベースのブロックチェーンでは機密性を確保するのがはるかに簡単であるため、匿名化によって課せられる制限の一部は、このテクノロジーの機密バージョンには当てはまりません。

残高と送金額の非表示

Zether の残高と送金額を暗号化するために暗号化スキームが使用されます エル・ガマル。 以下のように動作します。 アリスがボブを送りたいとき b アドレス別のコイン（公開鍵） Y、彼女は乱数を選択します r そして金額を暗号化します。

どこ C - 暗号化された金額、 D - この量を解読するために必要な補助値、 G - 楕円曲線上の固定点。秘密鍵を掛けると公開鍵が得られます。

ボブはこれらの値を受け取ると、同じ方法で暗号化された残高にそれらを追加するだけです。そのため、このスキームは便利です。

同様に、アリスは残高から同じ値を差し引きます。 Y あなたの公開鍵を使用します。

受信者と送信者を非表示にする

UTXO での「出力」のシャッフルは、暗号通貨の初期に遡り、送信者を隠すのに役立ちます。 これを行うために、送信者自身が送金を行う際に、ブロックチェーン内のランダムな「出力」を収集し、それらを自分のものと混合します。 次に、リング署名を使用して「出力」に署名します。これは、関係する「出力」の中に送信者のコインが存在することを検証者に納得させることを可能にする暗号メカニズムです。 もちろん、混合されたコイン自体は使用されません。

ただし、受信者を隠すために偽の出力を生成することはできません。 したがって、UTXO では、各「出力」には独自の一意のアドレスがあり、これらのコインの受信者のアドレスに暗号的にリンクされています。 現時点では、秘密鍵が分からない限り、一意の出力アドレスと受信者アドレスの間の関係を特定する方法はありません。

アカウントベースのモデルでは、ワンタイム アドレスを使用できません (そうしないと、すでに「出口」モデルになってしまいます)。 したがって、受信者と送信者はブロックチェーン内の他のアカウントと混在する必要があります。 この場合、実際の残高は変更せずに、暗号化された 0 コインが混合アカウントから引き落とされます (受信者が混合の場合は 0 が追加されます)。

送信者と受信者は常に固定アドレスを持っているため、同じアドレスに転送する場合は同じグループを使用して混合する必要があります。 これを例で見ると簡単です。

アリスがボブの慈善活動に寄付することに決めたが、その送金は外部の観察者に対して匿名のままにすることを希望したとします。 次に、送信者フィールドを偽装するために、アダムとアデルのアカウントも入力します。 ボブを非表示にするには、受信者フィールドにベンとビルのアカウントを追加します。 次の投稿で、アリスは自分の隣にアレックスとアマンダ、ボブの隣にブルースとベンジェンを書くことにしました。 この場合、ブロックチェーンを分析すると、これら XNUMX つのトランザクションには、交差する参加者のペアが XNUMX つだけ存在します (アリスとボブ)。これにより、これらのトランザクションの匿名化が解除されます。

トランザクションレース

すでに述べたように、アカウントベースのシステムで残高を隠すために、ユーザーは残高と送金金額を暗号化します。 同時に、自分の口座の残高がマイナスではないことを証明する必要があります。 問題は、トランザクションを作成するときに、ユーザーが現在のアカウントのステータスに関する証拠を作成することです。 ボブがトランザクションをアリスに送信し、それがアリスから送信されたトランザクションよりも前に受け入れられた場合はどうなりますか? この場合、ボブのトランザクションが受け入れられる前に残高証明が作成されたため、アリスのトランザクションは無効とみなされます。

このような状況で最初に下される決定は、取引が実行されるまでアカウントを凍結することです。 しかし、分散システムでこのような問題を解決するのは複雑であることに加え、匿名スキームでは誰のアカウントをブロックするかが明確ではないため、このアプローチは適切ではありません。

この問題を解決するために、このテクノロジーは入ってくるトランザクションと出ていくトランザクションを分離します。つまり、支出は貸借対照表に即座に影響を及ぼしますが、受け取りは遅れて影響を及ぼします。 これを行うために、固定サイズのブロックのグループである「エポック」の概念が導入されます。 現在の「エポック」は、ブロックの高さをグループ サイズで割ることによって決定されます。 取引を処理する際、ネットワークは送信者の残高を即座に更新し、受信者の資金を貯蔵タンクに保管します。 蓄積された資金は、新しい「時代」が始まるときにのみ受取人が利用できるようになります。

その結果、ユーザーは資金を受け取る頻度に関係なく (もちろん残高が許す限り) トランザクションを送信できます。 エポック サイズは、ブロックがネットワーク内を伝播する速度と、トランザクションがブロックに入る速度に基づいて決定されます。

このソリューションは機密転送にはうまく機能しますが、後で説明するように、匿名トランザクションでは深刻な問題が発生します。

リプレイ攻撃に対する保護

アカウントベースのブロックチェーンでは、各トランザクションは送信者の秘密キーによって署名され、これにより検証者はトランザクションが変更されておらず、このキーの所有者によって作成されたものであることがわかります。 しかし、伝送チャネルを傍受していた攻撃者がこのメッセージを傍受し、まったく同じ XNUMX 番目のメッセージを送信した場合はどうなるでしょうか? 検証者はトランザクションの署名を検証し、その作成者であることを確信し、ネットワークは送信者の残高から同額を再度償却します。

この攻撃はリプレイ攻撃と呼ばれます。 UTXO モデルでは、攻撃者は使用済みの出力を使用しようとしますが、それ自体は無効であり、ネットワークによって拒否されるため、このような攻撃は関係ありません。

これを防ぐために、ランダム データを含むフィールドがトランザクションに組み込まれます。これは nonce または単に「ソルト」と呼ばれます。 ソルトを使用してトランザクションを再送信するとき、検証者は nonce が以前に使用されているかどうかを確認し、使用されていない場合はトランザクションが有効であるとみなします。 ユーザーのノンス履歴全体をブロックチェーンに保存しないようにするために、通常、最初のトランザクションではゼロに設定され、その後 XNUMX ずつ増加します。 ネットワークは、新しいトランザクションの nonce が前のトランザクションと異なることを XNUMX つずつ確認することしかできません。

匿名転送スキームでは、トランザクションの nonce を検証するという問題が発生します。 明らかに、転送の匿名性が解除されるため、nonce を送信者のアドレスに明示的にバインドすることはできません。 また、処理中の他の送金と競合する可能性があるため、参加しているすべてのアカウントのナンスに XNUMX を追加することもできません。

Zether の作者は、「エポック」に応じて暗号的にノンスを生成することを提案しています。 例えば：

それは x は送信者の秘密鍵であり、 ゲポック — エポックの追加ジェネレーター。「Zether + 」形式の文字列をハッシュすることで取得されます。 現在、問題は解決されているようです。送信者のナンスを公開せず、関与していない参加者のナンスに干渉しません。 ただし、このアプローチには重大な制限が課せられます。XNUMX つのアカウントが「エポック」ごとに送信できるトランザクションは XNUMX つだけです。 残念ながら、この問題は未解決のままであり、現時点では Zether の匿名バージョンは使用にほとんど適していないと私たちは考えています。

ゼロ知識証明の複雑さ

UTXO では、送信者はマイナスの金額を費やしていないことをネットワークに証明する必要があり、そうでなければ何もないところから新しいコインを生成することが可能になります (なぜこれが可能なのかについては、以前の記事のいずれかで書きました) 物品）。 また、混合されているコインの中に自分に属する資金があることを証明するために、リング署名で「入力」に署名します。

アカウントベースのブロックチェーンの匿名バージョンでは、証明のための表現がはるかに複雑になります。 送信者は次のことを証明します。

1. 送金額はプラスです。
2. 残高はマイナスではありません。
3. 送信者は転送金額 (ゼロを含む) を正しく暗号化しました。
4. 天びんの残高は送信者と受信者に対してのみ変更されます。
5. 送信者は自分のアカウントの秘密キーを所有しており、実際には送信者リスト (関係者の中に) に載っています。
6. トランザクションで使用される Nonce は正しく構成されています。

このような複雑な証明の場合、著者らは混合物を使用します。 防弾の （ちなみに、著者の一人がその作成に参加しました） シグマプロトコル、シグマ弾と呼ばれます。 このような声明を正式に証明するのはかなり困難な作業であり、その技術を導入しようとする人の数が大幅に制限されます。

その結果は？

私たちの意見では、Zether のアカウントベースのブロックチェーンにプライバシーをもたらす部分は、今すぐ使用できると考えています。 しかし現時点では、このテクノロジーの匿名バージョンでは、その使用に重大な制限が課せられ、その実装には複雑さが伴います。 ただし、著者がこの本をリリースしたのはほんの数か月前であることを無視すべきではなく、おそらく他の誰かが現在存在する問題の解決策を見つけるでしょう。 結局のところ、これが科学のやり方です。

出所： habr.com