この記事は https://eprint.iacr.org/2018/643.pdf を要約したものです。何か間違いがあれば @public_sate まで連絡ください。

大雑把な要約はこちらを御覧ください。

https://speakerdeck.com/sate/cross-blockchain-trading-protocols

XClaim(クロスクレーム) とは

Ethereum × Bitcoin の初めての Trustless cross-blockchain trading protocols です。

クロスチェーン間の取引を行う方法として取引所などの第三者による信頼機関を担保にして行う方法が知られています。しかし、それではブロックチェーンの trustless な特性が損なわれるため、クロスチェーン取引も trustless にしたいです。

従来の Trustless な取引手法は HTLC を用いた Atomic Swap が唯一の手法としてありました。
Atomic Swap については非常に分かりやすい記事があるのでリンクを置いておきます。
https://zoom-blc.com/atomic-swap

XCLAIM は HTLC を用いた Atomic Swap よりも安価で高速な、世界初の Bitcoin 担保資産発酵型のクロスチェーン間取引手法です。

ACCS(atomic cross chain swap) では何故問題か。

これにはセキュリティを維持するための以下の制限があるため、実用性が制限されます。

対話式プロトコルである。
すべての関係者がオンラインである必要がある。
実行中に関係するすべてのブロックチェーンを監視する必要がある。
ブロックチェーン間でクロックを同期する必要がある。(時間を利用したアルゴリズムなので)
事前に確立された安全なオフチェーン通信チャネルに依存する。
転送に長い待機期間が発生する。
クロスチェーンスワップを行う度に、各ブロックチェーンで2つずつ、4つのトランザクションが発生する必要がある。
1. Alice → MultiSig Address 1 on chain A
2. Bob → MultiSig Address 2 on chain B
3. MultiSig Address 2 → Alice on chain B
4. MultiSig Address 1 → Bob on chain A

これらの制限は、クロスチェーン取引を高価で、遅く、非効率にします。

XClaim は担保(backed)トークンを安全に発行する仕組みです。そして上記の制限を克服します。

XClaim が可能にすること

XClaim は以下を可能にします。

クロスチェーンの支払いチャネル
- ユーザーは異なるブロックチェーン間で trustless な支払いをオフチェーンで実現できます。
トランザクションのオフローディング。
- ユーザはネットワークの混雑と高い手数料を克服するために異なるチェーンで一時的に暗号資産のトークン化ができます。
N-way and multiparty atomic swap
- 効率的で複雑なアトミックスワップが実現できます。

さらに、HTLCアトミックスワップと比較すると、XCLAIMは1000スワップで95.7％高速、65.4％安くなっています。

用語説明

CBA(curyptocurrency-backed assets)(暗号通貨担保資産)はブロックチェーンBの暗号通貨に裏付けされたブロックチェーンIの上に展開された資産のことを言います。

b はブロックチェーンB上の暗号通貨。 i(b) は b によって価値を裏付けられたブロックチェーン I 上の暗号通貨。

定義:

backing
- i(b) の価値を保証するために b をロックすること。
issuing
- backing によって保証された i(b) を発行すること。
issuing blockchain
- ブロックチェーンIはCBA i(b) を発行する。
backing blockchain
- ブロックチェーンBは i(b)の価値を自身が発行する暗号通貨 b によって裏付ける。
asset value
- i(b) の生成に使用される暗号通貨 b の単位。
asset redeemability
- i(b) をブロックチェーン B で b に償還できるかどうか。
asset owner
- 現在のブロックチェーン I 上の i(b) の所有者。
asset fungibility
- i(b)が交換可能かどうか。

b の合計量がbacking量が i(b) の合計issuing量に等しい場合、つまり |b| = |i(b)| の場合、CBAは対称(symmetric)であると定義される。

CBAs Actor

CBA Requester
- B の b をロックして、I の i(b) を要求します。
CBA Sender
- i(b) を所有し、所有権をIの別のユーザーに譲渡します。
CBA Receiver
- I の i(b) に対する所有権を受け取ります。
CBA Redeemer
- I の i(b) を破棄して、Bの対応する量の b を要求します。
CBA Backing Vault(vault)
- Bのbに対する i(b) の償還要求を満たす責任を負う（信頼されていない）仲介役をします。
Issuing SmartContract(iSC)
- I での i(b) の正しい発行と交換を管理するパブリックスマートコントラクト。iSCは、Vault の正しい動作を保証します。

Requester , Redeemer そして Vault は I と B 両方のブロックチェーンの秘密鍵/公開鍵のキーペアを持つ必要があります。Sender と Receiver は I のキーペアのみを保つ必要があります。iCS は I 上のスマートコントラクトとして動作します。

Blockchain Model and Assumptions

XCLAIMは、さまざまなコンセンサスメカニズムと信頼モデルを使用して2つの独立したブロックチェーン間の通信を確立します。したがって、ブロックチェーン B または I が攻撃者によって侵害された場合、XCLAIMの正しい機能は保証されません。

セキュリティ要件

XCLAIM の基本要件。

Auditability
- ブロックチェーン B および I への読み取りアクセス権を持つすべてのユーザーは、XCLAIMの動作を監査し、プロトコル障害を検出できます。
Consistency
- |b| = |i(b)| が成り立つ。つまり、同量の b の backing なしで i(b) を発行できない。
Redeemability
- すべてのユーザーは、i(b) を B の裏付け通貨 b と交換するか、I で同等の経済的価値を払い戻すことができます。
Liveness
- XCLAIMのユーザーは、第三者を必要とせずにCBAを発行、転送、およびスワップできます。つまり、liveness は B と I の安全な操作のみに依存しています。
AtomicSwap
- ユーザーは、XCLAIM CBAを I またはネイティブ通貨 i の他の資産とアトミックに交換できます。
Scale-out
- 流通に利用できるCBAsの合計量は、ブロックチェーン B で backing した総量と共に増加します。どのユーザーも、Vault の役割を引き受けることでこの量に貢献できます。
Compatibility
- XCLAIMは、特定の暗号通貨実装に依存しません。その代わりに、ブロックチェーン I ではアセット i(b) を発行できるスマートコントラクトをサポートしている必要があります。ブロックチェーン B では当事者間の基本的な資金振替をサポートされている必要があります。これにより、XCLAIMは、ビットコインなどのスマートコントラクトサポートを提供しない既存のブロックチェーンとの下位互換性を維持できます。

※ Compatibility から言えるように、Ethereum で Bitcoin-backed assets を扱えるが Bitcoin で Ethereum-backed assets は扱えない。

STRAWMAN SOLUTION AND DESIGN ROADMAP

まずは、CENTRALCLAIM という単一の Vault を信頼することでアトミックスワップを実現するアルゴリズムを考えてみましょう。

Protocol issue.(CBA の発行)

Setup
- 最初に Alice は iSC がチェーン I で利用可能であることを確認し、B の単一の vaultを識別します。
Lock
- Alice は I で新しい公開/秘密鍵のペアを生成し、b を vault に送信することにより、Bの vault で資金 b をロックします。これは誰でも検証可能です。これらの資金を vault でロックする一環として、Alice は生成される i(b) の送信先も指定します。つまり、アリスは I の公開鍵を vault への bの転送に関連付けます。
Create
- Vault は、Alice が資金を正しくロックしたことを示す署名付きメッセージを使って iSC に証明しアリスの公開鍵をISCに送ります。 iSCは Vault の署名を検証し、i(b) を作成してロックされた b の量と同量の i(b) を指定された Alice に送信します。

Protocols Transfer(CBAsの送金)

I 上で Alice → Dave 送金

Transfer
- アリスは、iSCに i(b) を I の Dave（公開鍵）に送金ことを通知します。iSCの状態が更新され、Daveが i(b) の新しい所有者になります。
Witness
- Vault は iSC を介して I の所有権の変更を目撃し、Alice がB でロックしていた b を返金できなくします。

Protocols Swap(CBAsを用いた atomic swap)

I 上で Alice ←> Dave swap。

Lock
- アリスはiSCで i(b) をロックします。
Swap
- Dave が合意された i またはIの他の資産を遅延 ∆swap 以内に iSC でロックすると、iSCは i(b) の新しい所有者を Dave に、i の新しい所有者を Alice に割り当てます。
Revoke
- Daveが ∆swap 内で iSC で i を正しくロックしない場合、iSCはロックされた i(b) をAliceにリリースします。
Witness
- Swap が成功すると、Vault は i(b) の所有権の変更を目撃し、アリスがロックしていた b を返金できなくします。

Protocol: Redeem(CBAs の償還)

Dave は I上の i(b) を iCS でロックして、B の Vault から b を受け取ります。i(b) はその後破棄されます。

Setup
- Dave は B で公開鍵/秘密鍵ペアをします。
Lock
- Dave は i上の iCS で i(b) をロックし、i(b) の償還を要求します。この時、Dave は B の新しい公開鍵を償還のターゲットとして指定します。
Release
- Vault I 上の i(b) のロックと償還要求を目撃し、B 上の Dave の指定された公開鍵に資金 b を送金(release)します。
Burn
- Vault は iSC で b が B で償還されたことを証明し、iCS は I でロックされた i(b) を burn します。

ここまでの例で明らかに Vault に信頼を置いている事がわかります。単一障害点を持ち、さらに悪意のある動作を行うことで利益を出すこともできます。しかしながら、監査可能性を実現しているという点で現実世界のシステムより既に優れています。

この時点で、CENTRALCLAIM は Auditability とCompatibility を満たします。
次からは、CENTRALCLAIM を改善して他の要件を満たしていきます。

XCLAIM SECURE DESIGN

XLAIM は主に以下の手法により CENTRALCLAIM の制限を克服します。

Chain Relays: Cross-Chain State Verification
- チェーン I 上で B のライトクライアントとして動作することで、B の Transaction Inclusion Proof による正しい動作の検証を可能にする。
- Consistency と Liveness を満たす。
Tribunal: Incentives via Collateralization
- Vault に担保を作らせることで Vault に対して Trustless な仕組みを実現する。
- 担保を撤回する時に一定時間の遅延を設けさせる。
- 発行の際にコミットメントを行わせる。
- Redeemability(為替レート一定における) を満たす。
Mitigating Exchange Rate Fluctuations
- 2 に加え、過剰担保/担保調整/自動生産の仕組みを加える。
- Redeemability(為替レートが変動する場合) を満たす。
Multi-vault System: Removing Single Points of Failure
- 担保を納めた任意のユーザが Vault になることができる仕組みを実現する。
- Vault の単一障害点を除去できる。
- Scale-Out を満たす。

iCS Design

Chain Relays: Cross-Chain State Verification

chainRelay はチェーンBのトランザクションをI上でトレースします。chainRelay は SPV またはライトクライントに匹敵する機能を持ちます。つまり、chainRelay は B のブロックヘッダーを保存し、iSCに以下の2つの機能を提供します。

Transaction Inclusion verification
- chainRelay は I の backing blockchain である B のすべてのブロックヘッダーを保持します。各ブロックヘッダーには、そのブロックが含む全てのトランザクションからなるマークルツリーのルートハッシュが含まれます。ブロックにトランザクションが含まれているかを確認するには、ルートからそのトランザクションを示すリーフへのマークルツリーパスを提供するだけで十分です。
- 上記の機能は iCS の一部として非対話形式で実行できます。

- **Consensus verification** - chainRelay はあるブロックヘッダーが B の合意形成参加者の大多数によって合意されていることを検証できます。XCLAIM ではコンセンサス検証は B のコンセンサスアルゴリズムに依存します。 - Proof-of-Work の場合 - 難易度調整ポリシーを認識し、受信したヘッダーがチェーン上にあるこを検証する。 - Proof-of-Stake の場合 - Staking epoch を認識し、ブロックヘッダーのしきい値とマルチシグネチャにより選出されたリーダの署名を検証する。 - Proof-of-Authority の場合 - コンセンサス参加者が事前に定義されている場合は明らかです。 - そうでない場合はアルゴリズムに対応する機能を chainRelay に足す必要があるかもしれません。

XCLAIM は chainRelay を使用して、前章の Protocols を改善します。

Protocol issue

b を Vault でロックする時に生成したトランザクションの inclusion Proof を iCS に示します。chainRelay は inclusion proof を検証し資金が b が正しくロックされたことを確認できた場合、iCS 内の対応する量の i(b) を発行します。

Protocol redeem

redeemer が redeem リクエストを行った後、Vault は資金bを B のトランザクションで redeemer に送金します。そして、そのトランザクションが CBA の redeem リクエストに対応することを証明する必要があります。すなわち、| b | = | i(b) |を証明します。これは、最大遅延 ∆I_redeem 以内にbを redeemer に送信するトランザクションを chainRelay に提示することによって行われます。 Vault が順守できなかった場合、金銭的ペナルティが発生し、iSC は償還者への払い戻しを行います。

遅延

Inclusion proofs を正しく検証するには chainRelay は最新のブロックヘッダーを持っていなければなりません。ここで許容される遅延 ∆relayは∆B + ∆submit + 2∆I とします。∆submit はブロックヘッダーを chainRelay に送信するトランザクションがブロードキャストされるまでの遅延です。一個のトランザクションで n個のブロックヘッダーを送信する場合の遅延は ∆submit + n（∆B + 2∆I） になります。

Liveness の証明

chainRelay は Issue プロトコルを非対話形式にします。 Vault を信頼して b のロックを確認する代わりに、 iCS が issuer によって提供された Transaction Inclusion Proof を検証します。

攻撃者が Issue を止めるためには I または B のトランザクションをすべて制御する必要があります。

攻撃者が Swap/Transfer に不正を働くためには iCS 自体を修正する必要があります。

これは今回のブロックチェーンBとIの持つセキュリティ仮定では不可能です。

したがって Liveness を達成しています。

Consistency の証明

iCS は提供された Transaction inclusion proof が正しい場合のみその時ロックした b と同量の i(b) を発行します。 |b| = | i(b) | が常に成り立ちます。

攻撃者が iCS を改ざんできない限りこれを覆すことはできません。

したがって Consistency を達成しています。

Tribunal: Incentives via Collateralization

不正行為に罰を課す手段として担保を利用することで XCLAIM の誠実な行動を奨励します。iSC のこのコンポーネントのことを Tribunal と呼びます。具体的には Vault を iSC に登録する際に担保金 i_col をロックします。Vault が Redeem Protocol が正しく実行されたことを証明できない場合 iSC は担保を自動的に使用して買い手に保証し追加の罰金も支払います。

Vault が誠実に振る舞うインセンティブとして担保が機能するには少なくとも以下の条件が成り立っていなければなりません。

$$i_{col} \ge b_{lock} * \varepsilon(i, b)$$

b_lock はB の vault でロックされている b の量を示します。ε(i, b) はoracle O によって提供される為替レートです。この時点で ε(i, b) は一定とします。つまり、I で担保している価値の総量は B でロックしている価値の総量以上でなければならない。

Redeemability の確保

ユーザは iCS の Vault が十分な担保を持っている場合にのみ、その Vault を対象に issue Protocol を開始できる必要があります。ただし、以下の脆弱性を孕みます。

Vault は Issue Protocols を完了する前に担保金の撤回(Withdraw)を試みることができます。
複数のユーザが同一の Vault に対して同時に Issue Protocols を試みることができます。片方のロックされた資金は担保によって保護されないかもしれません。

Attack case of tribunal.

上記の攻撃の緩和策を示します。

Deferred Collateral Withdrawal
- Vault はネットワーク遅延を利用して、B に資金がロックされることを確認してから担保金の Withdraw を試みて罰せられない状態を作ろうとします。
- これを防ぐために Simple announce-delay withdraw schema を導入します。
- Vault は withdraw の際に iSC を介さなければならず、この時、担保金の withdraw を公にアナウンスします。ユーザは ⊿withdraw 以内に Issue Protocols を完了させた後、Vault は残った担保を引き出すことができます。
- ここで ⊿withdraw > ⊿relay。⊿relay は前項目で定義されたもの。

Collateralized Issue Commitments
- 複数の Issue によって同じ領域の Vault の担保を使用して資金 b をロックするのを防ぐIssue Protocols のセットアップ時に登録ステップを導入します。
- 初めに、Requester(Issue する人) は iSC に i(b) の発行リクエストを登録します。これにより対応する量の Vault の担保が一時的にロックされます。次に ⊿commit( > ⊿B + ⊿relay) 以内にリクエスターは Issue Protocols の残りのステップを安全に実行できます。つまり、iSC は事前に登録された発行リクエストのみを受け入れます。
- 悪意のある Requester が登録ステップを繰り返して担保を永続的にロックさせること(griefing attack)を回避するために、Requester は登録ステップで担保を提供する必要があります。これは issue が失敗した時払い戻しされます。複数の担保付きコミットメント登録ステップを並行して作成できます。しかし、iSC は先着で一つのコミットメント(登録ステップ)のみを受け入れます。
- 最悪の場合でも、Requster の損失は I の取引手数料のみです。

Redeemability の証明(為替レートが定数)

XCLAIM で担保を導入することで、経済的に合理的な Vault に不正行為の動機がないことを保証します。

Vault が担保して価値の総量は常にロックしている価値を上回っている仮定があるため、Redeem 時に Vault が誤った動作をすると Vault の担保金は Redeemer に奪われます。さらに、誠実な行動をした場合に得られる手数料を得ることが出来ません。したがって、Vault は不正な行動をするとマイナスの効用があるためその戦略を実行しません。

また、前述した担保撤回の延期(Deferred Collateral Withdrawal)と担保された発行コミットメント(Collateralized Issue Commitments)によりネットワーク競合状態を悪用した搾取もできません。

XCLAIM はゼロサムゲームであるため、悪意のある Vault と Redeemer の共謀が利益をもたらさないことも分かります。

したがって、経済的に合理的な攻撃者の仮定のもと為替レートが一定の場合、Redeemability を達成しています。

Mitigating Exchange Rate Fluctuations

為替レートは実際に変動します。その場合にも Redeemability を確保するために以下を施します。

Vault が過剰に担保金を持ちます。
Vault のロックしている担保を調整できるようにします。
i の極端な価格下落が発生した際の金銭的な損失を防ぐために自動精算を導入します。

Over-collateralization(過剰担保)

ε(i, e)の急激な低下による障害の軽減に役立ちます。為替レートの変動を考慮するために過剰担保のバッファー r_col ∈ {R≥1} を定義します。セキュリティのため、XCLAIM のライフサイクルは次の条件を満たしていなければなりません。

$$i_{col} \ge b_{lock} * (r_{col} * \varepsilon(i,b)) \ge b_{lock}$$

Over-collateralization factor r_col は XCLAIM のセキュリティパラメータになりあｍす。これにより requester が安全にロックできる b、安全に発行できる i(b) の最大量を定義します。

$$max(i(b)) = \frac{i_{col}}{r_{col} * \varepsilon(i,b)}$$

既に安全に発行された i(b) を

$$i^-{col} = i(b) * r{col} * \varepsilon(i, b)$$

とすると残りの担保金は

$$i^+{col} = i{col} - i^-_{col}$$

と表せます。

The adjustment of the vault’s collateral and

the notion of automatic liquidation
(担保調整と自動生産)

過剰担保は短期的には極端な変動を緩和するのに役立ちます。しかし、長期的に安全に処理するには不十分です。このために Vault の担保の調整を有効にし、iCS による i(b) の自動精算の概念を導入します。

担保 i_col の単純なマルチステージシステムを導入します。

Observed collaterarl rate を定義します。これは耐えうる変動の具合を表しています。(r^*_col 倍分の余裕があることを表している)

$$r^*{col} = \frac{i^-{col}+i^+{col}}{b{lock} * \varepsilon(i,e)}$$

さらに精算(liquidation)が発生するしきい値を定義します。

$$r_{col} \gt r^{liq}_{col} \gt 1.0$$

説明を簡単にするために r_col = 2.0 として進めます。そして次のようなマルチステージシステムを定義します。

Secure Operation
- Vault は Redeemability を確保するために必要以上の担保をロックしています。
- r^*_col ≥ r_col を満たしている限り安全に withdraw できます。つまり、r_col倍以上の余裕ある担保があります。
Buffered Collateral
- r^*_col ≥ r_col を満たしていないが安全な動作を保証するのに十分な余剰担保(Buffer)があります。
- この場合新たな i(b) は発行できません。
Liquidation
- 担保率(Observed collateral rate)が限りなく 1.0 に近い場合(e.g, r^liq_col = 1.05)、iCS は自動的にすべての i(b) を redeem します。
- r^*_col - 1.0 > ε(i,b) の分は手数料の支払いに割り当てられます。
- これは担保率が 1.0 を下回った場合に、ユーザが経済的損失に直面するのを防ぐために必要です。

Redeemability の証明

為替レートが変動するケースを許容するために Vault は余剰担保(バッファ)を使用します。 Vault は担保を更新できるため、楽観的なケースでバッファが枯渇した倍でも XCLAIM は安全に動作します。何故なら、バッファが枯渇したケースでは自動生産によりユーザの経済的損失が損なわれないようにするからです。

誤作動するケースは担保した価値の総量がロックした価値の総量を下回る場合のみですが、iSC の自動生産システムによりこれは防がれます。なので、iSC の動作を変更しない限りはこのケースに到達することはできず、ブロックチェーンのセキュリティ仮定においてこれは起こりえません。

したがって、為替レートが一定でないケースにおいて Redeemability を達成します。

Multi-vault System: Removing Single Points of Failure

これまで単一の Vault を仮定していましたが、XCLAIM は簡単にマルチ Vault システムに拡張できます。つまり、iSC に登録して担保を提供することで誰もが Vault になることができます。Issue や Redeeem を行うユーザは複数の Vault から自由に選択することができます。各 Vault ごとに担保率と手数料が設定されており、これにより自由市場を作成します。

複数の Vault が存在するため Redeeem に失敗した場合、次のいずれかを選択できます。

失敗した Vault から担保から払い戻される。
別の Vault を使用して redeem を再試行する。

Ensuring correct automatic liquidation

単一の Vault が自動精算をてしてもシステム全体には影響しません。iSC はブロックの量に対応する i(b) の償還と、vault の利用可能な担保から差し引かれる追加の小さな手数料 i が提供されます。

不十分なユーザが redeem を実行した場合 XCLAIM のすべてのユーザに精算を均等に分配します。

Scale-Out の証明

構造上、すえてのユーザは、担保 i_col をロックすることにより　iSC on I に Vault として登録できます。つまり、 Vault のセットは動的に変更でき、事前定義されていません。すべてのユーザが安全に発行可能な CBA の合計量 max(i(b)) を増やすことは簡単です。

攻撃者は新しい Vault の登録を防ぐために以下のことが考えられます。

I 上のすべての資産を制御する。
I にトランザクションが含まれないようにする。

しかし、これらはブロックチェーンのセキュリティ仮定のもと不可能です。

したがって、 B と I の安全な操作のもとで XCLAIM は Scale-Out を達成します。

XCLAIM の仕様

セキュリティ対策

Chain Relay Poisoning

ブロックチェーンの51%攻撃が達成されなければ問題ありませんが、された場合の対処方は今回の手法では明記されていません。

Replay Attacks on Inclusion Proofs

Issue と Redeem のトランザクションにユニークな id を降って replay アタックできないようにする。

Counterfeiting

Vault がロックされた資金を移動することを検出し、Transaction Inclusion Proof を iCS に提出して供託を奪う。

Permanent Blockchain Splits

ハードフォークについて。

ISCの公開キー（またはそのダイジェスト）を、識別子に加えて、発行と引き換えの一部としてBで公開されたトランザクションに含める。

次に、IとI 0のi（b）バランスを同期する2つの可能性を特定します。

I_0 に Iのチェーンリレーを展開し、逆も同様にiSC [24]とiSC0の状態を継続的に同期する。つまり、ハードフォークしたやつもチェーンリレーで管理。
両方の iSC を再展開する。

Denial-of-Service Attacks

ブロックチェーン全体に DoS をしかけるのと同程度に難しい。

Sybil Attacks and Extortion

シビル攻撃：1人の悪意ある人が複数の低担保ボールトを作成することによる金銭的利益を得る可能性があります。
対策：

iSCは iCS は最低限必要な担保額を保証する。
iCS は利用回数に応じた料金制 "Pay-per-issu" を保証する。
２つを満たすことでユーザーは低担保ボールとを簡単に除外できます。

Extorion：適切な制限がなければ、ボールトは償還の実行に極端な料金を設定する可能性があります。
対策：

iSCは償還の実行に料金を請求できない。
iCS は発行中に償還の料金を事前に合意することを強制する。
のうちいずれかを強制する必要があります。

Conclusion

信頼を必要とせずに、ブロックチェーン間で CBA を発行、譲渡、交換、および償還するシステムである XCLAIM を紹介しました。XCLAIM は一般的な設計で多くのブロックチェーン間取引について当てはめることができます。また、既存のアトミックスワップを用いた手法よりも効率的です。