Bulletproofs++: 第三者による解析が不可能な複数種アセット内包型トランザクションの実現に向けて
Blockstream Research

Bulletproofs++: 第三者による解析が不可能な複数種アセット内包型トランザクションの実現に向けて

Liam Eagen

プライバシーとセキュリティは切り離すことができない性質で、Bitcoinのユーザーが切実に臨んでいるものです。BlockstreamではBitcoinユーザーのプライバシーを改善する様々な手法の開発の最前線で戦っており、GreenやJade内でウォレット利用時のベストプラクティスを簡単に実行できるようにしたほか、MuSig2秘匿トランザクション (CT)といった新技術を発明しています。通常のBitcoinトランザクションで得られるプライバシーはわずかですが、秘匿トランザクションは送金額が伏せられるという大きな進歩をもたらします。今回の記事では完全な匿名性の実現に向けた応用的な研究をいくつか紹介します。

金額および送金経路の双方を秘匿できるUnlinkable Transactionsを求める声はBitcoinの誕生以来大きくなってきています。MoneroやZCashのような仮想通貨ではリング署名やSNARKsの採用をもってプライバシーが強化されていますが、そのどちらも複数のアセットに対応しての完全な匿名性は実現できていません。匿名性を完成させるにはBulletproofs++ (BP++)のとある改善が必須になります。この改善は秘匿トランザクションの効率性を改善しつつ、Trusted Setupを要することなく現在すでに利用できるマルチアセット対応を損なわないものです。

Bulletproofs++は離散対数ベースの新しくより効率的な署名実行システムで、秘匿トランザクションのデータサイズを節約します。秘匿トランザクションはトランザクションの入出力金額の一致を保証しつつ、その実際の金額を隠すものです。秘密裏にアセットが不正発行されたりマイナスの出力金額が生まれることを防ぐため、秘匿トランザクションのプロトコルはレンジプルーフを使用して各出力値の取れる範囲を負ではない特定の範囲に限定します。

初期のプライバシー保護プロトコル例:秘匿トランザクション

現在Liquidで使用されているCTプロトコルはレンジプルーフとアセット秘匿機能ボロミアン・リング署名を利用しているため複数のアセットで利用できます。仮想通貨のプライバシー重視のトランザクションプロトコルとしては最古のものの1つで、Greg Maxwellによる最初期のBitcoinおよびゼロ知識証明に関する研究内容にルーツをたどることができます。それ以来、ゼロ知識証明の分野は爆発的な成長を見せています。Blockstreamは広義のゼロ知識証明研究エコシステムに積極的に参加しており、特にBulletproofs (BP)の開発に力を注いでいます。BPは初めてTrusted Setupなしで確実にプルーフのサイズが小さくなることを保証できた革新的な技術です。

Bulletproofs++がもたらす容量と効率面での改善

トランザクションを安価に保管、実行、検証できることは、どのようなブロックチェーンアプリケーションにとっても望ましい性質です。したがって、秘匿トランザクションに使われる検証技術もできる限りブロックチェーンの容量を取らず、容易に検証できることが期待されます。BP++の64ビットレンジプルーフの容量はわずか416バイトでBPと比較して39%小さく、現在Liquidで使用されているレンジプルーフと比較すると10分の1です。プルーフのサイズが小さいことでトランザクション手数料の削減やノードに必要なストレージの圧縮が実現します。一般的な市販のノートパソコン上でのBP++レンジプルーフの検証はBPと比較して4倍高速化しているため、ブロックチェーンの検証速度に関してもBP++に軍配が上がります。別の基準と比較するとBP++レンジプルーフのサイズはシュノア署名7つとほぼ等しく、検証時間はシュノア署名20個分に相当します。BP++をLiquidに導入することでBPがもたらした革新とこれらのパフォーマンス改善がすべて利用できるようになります。

現在のLiquidの秘匿トランザクションや従来のBPレンジプルーフでは値がある一定の範囲内にあることを、その値の各ビットに関する知識を使って証明します。例えばある値が[0, 2^64 -1]の範囲内にあることを証明するには64ビットの知識を使います。Bulletproofs++ではより大きな底を使うことができるため、ある数字を表すのに必要な桁数が減少します。例えば[0, 2^64 - 1]内の整数を表すのには16進数で16桁で足り、2進数と比べて桁数が4分の1になります。これはReciprocal Argumentと呼ばれる新しい手法によってLookup Argumentの実装が可能になったことで実現しました。Lookupとしてインスタンス化されたReciprocal ArgumentのことをLog Derivative Lookup Argumentとも表現します。次節で詳しく見ていきましょう。

複数アセット対応とReciprocal Argument

Reciprocal ArgumentとはBulletproofs++プロトコル内で1つのトランザクション内で複数のアセットを取引するために利用される手法です。これにより異なる種類のトークンが混在するトランザクションでも入力・出力ともに秘匿することができます。「ゼロ知識証明の中に表がある」という比喩を用いると理解しやすいです。

Reciprocol Argument とは、そのゼロ知識証明内の表を使用する手法であると考えることができます。表の中で位置と金額を指定すると、その位置でその金額を足し引きできます。トランザクションの入出力にはそれぞれアセットの種類と金額が個別にあるので、すべての種類について入出力の金額が一致していることを検証するために表に種類ごとの金額をまとめることにします。入力すべてについて種類ごとに分けられた欄に金額を加算し、出力すべてについて種類ごとに分けられた欄から金額を減算して、最後にすべての欄の金額がゼロになっていれば一致したことがわかります。

擬似コードで表現すると:

# Start with empty table
T = {}

# Add all the inputs
for (v, t) in I:
    T[t] += v

# Remove all the outputs
for (v, t) in O:
    T[t] -= v

# Check all the amounts in the table are zero
for (t, v) = T.items():
    assert(v == 0)

Bulletproofs++の実装状況

現時点ではlibsecp256k1zkpに「ノルム」引数を追加する2つのプルリクエストのうち1つ目がマージされています。これはBPの「内積」引数を応用し、BP++のデータサイズの小ささを実現するためのプリミティブです。次の予定はレンジプルーフに対応させる2つ目のプルリクエストの導入です。その後はマルチアセット対応の実装と既存のアセットをBP++形式に静かにマイグレーションするのに必要なプルーフの実装を予定しています。libsecp256k1zkp内に実装することでその最高峰のパフォーマンスを享受でき、Liquidへの導入もスムーズに行なえます。

より長期的にはBP++の柔軟性とBlockstreamでの他の研究内容を組み合わせることでLiquid上のトランザクションを完全に秘匿化する道筋が見えています。トランザクション間の関連性を秘匿し、送金額も秘匿する(Liquidの場合はアセットの種類も秘匿する)この技術がいつかBitcoin自体に導入される可能性もあるでしょう。

トランザクション間の関連性を秘匿するトランザクションプロトコルはゼロ知識証明の研究における最先端の1つで、特にTrusted Setupを前提としない場合は難易度が高いとされています。BP++はLiquidにおけるマルチアセット対応の関連付け不可能なトランザクション秘匿プロトコルを実現する計画で中心的な要素技術です。

CTの中核にBP++を利用する話とは別に、トランザクション間の関連性を秘匿するには一層複雑なステートメントをゼロ知識証明できるようになる必要があります。この目標に関しては現在も積極的に研究を進めています。

プライバシーは初めからBitcoinの精神の一部でした。マネーには真の代替可能性(Fungibility)が必要で、Fungibilityの実現にはプライバシーが必要だからです。私達の目標はBP++を第一歩としてこのプライバシーをBitcoinエコシステムにもたらすことです。SimplicityにBP++を実装すれば、Simplicityに対応したプロジェクトはどれでもBP++を統合し利用できるようになります。

このトピックについて詳しく知りたい方は“Bulletproofs++: Next Generation Confidential Transactions via Reciprocal Set Membership Arguments” ペーパーの最新版をIACR eprint アーカイブから無料でご覧いただけます。また、GitHubから鋭意開発中の実装状況もレビューしていただけます。

If you have specific preferences, please, mark the topic(s) you would like to read: