ミンブルウィンブルの新提案：非対話型トランザクション、ライトコインとグリンが恩恵を受ける

元のタイトル: 「Mimblewimble は非対話型トランザクションを実現でき、Litecoin、Grin などが恩恵を受ける」
執筆者: David Burkett、Grin++ 開発者 翻訳者: Satuoxi

技術が使いにくかったり、ユーザーフレンドリーでなかったりすると、広く採用されることは難しくなります。以前のMimblewimbleプロトコルでは、実装するためには送信者と受信者が同時にオンラインでやり取りする必要があり、関連プロジェクトの大規模な適用が妨げられていました。今日、Grin++ウォレット開発者のDavid Burkett氏は、LitecoinやGrinなどのブロックチェーンプロジェクトに適用できるMimblewimble非対話型トランザクションをサポートする提案を発表しました。

David Burkett 氏は Litecoin フォーラムの開発者セクションで次のように述べています:

1 月の最大のニュースは、Mimblewimble で非対話型トランザクションをサポートする方法を見つけたことです。 MW プロトコルを使用する上での最大の難しさは、送信者と受信者が通信する必要があり、両者がオンラインである必要があることです。新しい提案により、この必要性がなくなり、ユーザーエクスペリエンスの大きな障壁が取り除かれると同時に、コールドストレージ経由の受信も可能になり、ハードウェアウォレットのサポートが容易になります。

開発側では、libmw のビルド プロセスが完了し、libmw-ltc のローカル ビルドが機能しています (libmw-core と libmw-ltc を同じ親ディレクトリにチェックアウトすると、libmw-ltc をビルドできるはずです)。今後 1 か月ほどで CI/CD を設定する予定です。

さらに、複数のテーブルにわたるアトミック更新をサポートするトランザクション処理機能を備えた堅牢なデータベース フレームワークを構築し、コインに依存しないブロック データベースのクエリと更新を実装しました。これらは、LTC 固有のブロック ヘッダーとブロック モデルで部分的にテストされています。

セキュリティ監査の結果は Grin++ からのものであるため、Grin++ と libmw にすべての修正を適用し、監査人による最終レビューを待つことになります。 C++ の実装は非常に複雑であることが判明し、関連する監査から教訓を得ることができました。このプロセスの一環として多くのことを学び、その結果、Grin++ と libmw のコードベースは大幅に改善されました。この監査を可能にしてくれた Grin、Beam、LTC コミュニティの貢献者に改めて感謝します。

Grin++ に関しては、計画されていたハードフォークが成功し、ハードフォーク前の同期の問題が解決され、これまでで最も安定したバージョンである Grin++ 0.7.5 が利用可能になりました。

2 月の最優先事項は、すべての検証と一連のテストを含む、Litecoin 拡張ブロック (EB) のコンセンサス ルールを実装することです。これはコードの最も重要な部分なので、すべての詳細が正しいこと、およびコードに完全なテスト カバレッジがあることを確認するには時間がかかることがあります。それが完了したら、拡張ブロック (EB) の API を開発して、LBMW を既存の Litecoin コードベースに統合できるようになります。

また、新しい一方的トランザクション提案を徹底的に検討することにも重点を置き、大きなセキュリティ上の問題が見つからない場合は、コミュニティからのフィードバックを得るために LIP (Litecoin Improvement Proposal) を作成します。

この投稿から、David Burkett 氏が現在 Litecoin 向けに開発している Mimblewimble アプリケーション ソリューションはまだ初期段階にあり、最大の進歩は非対話型トランザクションの提案であることがわかります。

では、この魔法のようなソリューションはどのように実装されるのでしょうか?提案の翻訳を見てみましょう。

Mimblewimble オフライン取引提案

Mimblewimble ブロックチェーン プロトコルは、ペダーセン コミットメント、シュノア署名、および「カットスルー」と呼ばれる新しい技術を使用して、ビットコインなどの暗号通貨のプライバシーとスケーラビリティを向上させます。これらの利点がもたらされる一方で、高額な代償を支払う必要もあります。これまで、MW トランザクションを構築するには、送信者と受信者の間でやり取りして出力を作成し、トランザクションに共同で署名する必要がありました。この論文では、Mimblewimble プロトコルのスケーラビリティとプライバシーへの影響を最小限に抑えながら、一方的なトランザクションを実現する方法を提案します。

現在のMimblewimbleプロトコル

Bitcoin と同様に、Grin も UTXO モデルを使用します。トランザクションは、使用する入力を含め、同等またはそれ以下の価値の新しい出力を作成し、入力の所有権を確認する範囲証明に署名して構築することによって作成されます。
Bitcoin とは異なり、Grin は機密トランザクション (CT) テクノロジを使用しているため、入力と出力はペダーセン コミットメント (rG + vH) になります。入力に追加される署名とは異なり、各トランザクションにはトランザクション カーネルの一部である署名が 1 つだけあります。

トランザクションが有効になるためには、次の条件を満たす必要があります (簡単にするために、トランザクション手数料とトランザクション補償は無視します)。

1. 出力コミットメントの合計から入力コミットメントの合計を引いた値はカーネルコミットメントと等しくなければなりません。つまり、(r_out1..nG +v_out1..nH) - (r_in1..nG +v_in1..nH) = r_kern*G です。

2. 既知のメッセージ ベース ポイント G のカーネル超過値 (rk = sum(ro1..n) - sum(ri1..n)) の署名。

3. すべての出力値が非負であることを証明する範囲証明。

これら 3 つの組み合わせにより、送信者が入力の所有者であることを証明し、トランザクションで新しいコインが作成されないことが保証されます。

このプロトコルでは、送信者 (アリス) と受信者 (ボブ) が、お互いの入力と出力のブラインド要因が公開されないように、トランザクションを構築するために対話する必要があります。これは 3 つのステップから成るプロセスです。

アリスは入力を使用して署名されていないトランザクションを作成し、出力と rangeproof (出力と入力のブラインド ファクターの差を含む中間カーネル) を変更し、Schnorr 署名された nonce を送信します。
2. ボブは出力と範囲証明を作成し、カーネルコミットメントの自分のシェアを追加して実際のトランザクションカーネルを生成し、ノンスにコミットし、トランザクションカーネルの部分的な署名を提供します。
アリスはカーネル署名に署名し、2 つの署名を集約します。

プロトコルは機能し、アリスがボブに制限なく資金を送金することを可能にしますが、プロトコルのインタラクティブな性質により、セキュリティ、使いやすさ、プライバシーに関するいくつかの課題が生じます。トランザクションを構築するには、ユーザーがキーをオンラインで保持するか、何らかの形式の帯域外通信が必要になり、プライバシー侵害や MITM 攻撃につながる可能性があります。

非対話型トランザクションの設定

長い間、レンジプルーフを作成し、シュノア署名を構築するには情報に基づいた出力ブラインド係数が必要であるため、ミンブルウィンブル プロトコルでは非対話型トランザクションは不可能であると広く信じられていました。

この問題を解決するには、まず、ブラインド係数を送信者と受信者の両方に知らせ、他の誰にも知らせない方法を見つける必要があります。 Diffie-Hellman 鍵交換アルゴリズムは、この問題を解決するのに非常に適しています。送信者は、キー ペアを生成し、受信者の pubkey (公開キー) を使用して ECDH を実行し、ブラインド ファクターとして使用できる共有秘密を生成します。送信者は受信者の出力、ブラインド要素、署名を生成して、有効なトランザクションを作成できます。

しかし、この解決策には 2 つの明らかな問題も伴います。

最初の問題は、送信者が依然として公開鍵と値を受信者に渡す必要があるため、プライバシーを損なうことなくそれを出力の一部として含める必要があることです。しかし、データを送信する明確な方法はありません。これをカーネルの一部にすることはできません。カーネルが出力にリンクされ、プライバシーの利点が失われてしまうためです。

2 番目の問題は、アリスとボブの両方が資金の鍵を所有することになり、ボブが資金の唯一の所有者にならず、紛争を解決できないことです。ボブだけが出力を使用できることを確認する方法が必要です。

新しい提案

範囲証明では約 32 バイトのデータを暗号化できることが判明しました。たとえば、既知のキー blake2b(output_commitment) を使用すると、いくつかの追加データを公開コミットできます。 rangeproof で「暗号化」したデータがハッシュであれば、実際に必要なデータを公開することができます。これにより、次の内容を含む新しいデータ ブロック (output_data) を含めることができます。

1. 送信者の一時的な公開鍵。

2. 受信者の公開鍵。

3. 出力値（ECDHE（送信者の鍵、受信者の鍵）を使用して暗号化されます）

4. 出力ブラインド係数（ECDHE（送信者の鍵、受信者の鍵）を使用して暗号化）

次に、出力を検証するための次のコンセンサス ルールを追加できます。

1. 各 rangeproof は blake2b(output_commitment); を使用して巻き戻すことができます。

2. 各出力には output_data (sender_pubkey、receiver_pubkey、および追加の暗号化データを含む) が含まれている必要があります。
   3.ripemd160(blake2b(output_data))は、巻き戻された範囲証明データの最初の20バイトと一致する必要があります。

ノードはすべての UTXO の output_data を保存する必要があるため、後で使用するときに、入力を検証するための新しいコンセンサス ルールを 1 つ要求することもできます。
各入力には有効な署名が含まれている必要があります: sig(receiver_pubkey, input_commitment)

入力と出力は通常どおりに削減され続けるため、送信者が資金を再使用できないことを保証しながら、受信者に資金を送信する方法が提供されるようになりました。

安全

送信者と受信者の両方が出力のブラインド係数を知っているため、カーネルに対して現在の UTXO セットを検証するだけでは不十分です。これには最近のすべての入力の署名を検証する必要があり、ステークが類似しているため、新しいノードは最後の X ブロック (X はコインベースの成熟度) 内のすべての入力の署名を検証することをお勧めします。

そして、それは今日では達成されそうにない攻撃ポイントを依然として残すことになるだろう。この攻撃は次のように機能します (過去 1 日間の入力署名が検証されていると仮定)。

1. アリスはボブへの出力を含むトランザクションを作成します。

2. ボブはアリスが購入したものを相手に送ります。

3. 何日も（あるいは何年も）経っても、ボブはまだコインを使い切っていません。

4. アリスは過去 1 日 + 1 ブロックの大規模な再編成を強制します。彼女はブラインドファクターを知っており、1 日より古いブロックのトランザクションの署名を検証していないため、ボブの出力を自分自身に送り返すことができます。

この攻撃では、理論的にはどの年齢のコインでも使用できますが、使用できるのは攻撃者が以前に送信したコインで、受信者が使用していないコインである必要があります。ただし、このような攻撃のメリットが再編成攻撃のコストを上回る可能性は低いでしょう。ただし、念のため、大量のコインを受け取った場合は、カーネルの追加コストをほとんどかけずに、自分でコインを使うだけでこの攻撃を防ぐことができます。

プライバシーの問題

キーペアが再利用されない限り、上記のスキームによって追加のプライバシーが漏洩することはありません。これを保証するために、何らかの形式のステルス アドレス (ISAP または DKSAP) をサポートするように出力データにかなり小さな変更を加えることを提案します。

支払い証明

支払いは今ではかなり簡単に証明できるようになりました。支払いを証明するために必要なのは、元の出力、rangeproof、output_data、およびrangeproofのMMRメンバーシップを示すmerkle proofだけです。

マルチ署名ウォレット

現在、マルチ署名ウォレットに資金を安全に送金するには、送信者とすべての受信者間のやり取りが必要です。新しい提案では、マルチ署名ウォレットのプライバシーを犠牲にして、この必要性を排除します。

その他の改善点

出力の一部として追加データを送信する方法ができたため、手数料やその他のデータをカーネルから output_data 構造に移動できるようになりました。これによりプルーニングが可能になり、ブロックチェーンのサイズが縮小されます。

謝辞

再編成攻撃の詳細な説明を提供してくれた John Tromp 氏、防弾とマルチ署名ウォレットに関するアドバイスを提供してくれた Jasper van der Maarel 氏、カーネルの詳細を出力データ構造に移動するよう提案してくれた Phyro 氏に感謝します。また、上記のデザインに関する貴重なフィードバックを提供してくれた Daniel Lehnberg、Antioch Peverell、Phyro、Vladislav Gelfer にも感謝します。

ソースリンク: litecointalk.io