HLFクロスチェーン事例、手法集2020春
TL;DR
Hyperledger FabricはGo、Javascript、Javaをはじめメジャーな言語での開発が可能であるため、HTLC型、Relay型そしてTTP(Trusted Third party)型全てにおいてクロスチェーンによる接続は原理的には可能である場合がほとんどであると言える。ただし、relay型の場合は接続先のチェーンのコンセンサス形成を検証する必要があり実装の難易度は高くなることが想定される。
① Ubin / Jasper
Quorum vs Corda、HTLC型 wiith Intermediary
② IBMの論文
Corda vs Fabric、relay型
③Project Stella(第2フェーズ)
Fabric v.1.1 vs Corda v2 vs Elements v2.14、HTLC型
④Project Stella(第3フェーズ)
ILP vs Fabric
⑤ ドイツ取引所のCorda vs HLFのPoC
Fabric vs Corda
⑥中国建設銀行トレードファイナンスプラットフォーム
⑦Fabric Interoperability: Atomic Commit Between Channels Using HTLC & HTLA
Fabric vs Fabric、Hashed BTL Protocol
⑧Hyperledger Labs Blockchain Integration Framework
汎用的接続、TTP型
事例、手法紹介
① Ubin / Jasper (Canada中銀、Singapore中銀、JP Morgan、Accenture)
publish date: 2019-6-10
1. 採用チェーン:Quorum vs Corda
2. 伝達手法:HTLC wiith Intermediary
HTLCを用いるがチェーン間の伝達は原則媒介が行う。想定するのはアトミックスワップではなく、一方向の国際送金。下図は、仲介者IntAを通じてBank1からBank2へ国際送金を行うシナリオ。
https://gyazo.com/1e26906a6c330eba9f084cb3282fec4c
細かいシークエンス図は以下の通り。
https://gyazo.com/56da5bc07ec3f6dc8711961508cc8e5a
SenderはTの間アセットをロックアップする。仲介者はこれを受け、receiver側のチェーンで同じシークレットのハッシュを使ってアセットをロックアップする。receiverはシクレットを知っているのでアセットをアンロックできる。アンロックにより、仲介者はシークレットを知ることができるのでSenderのロックしたアセットをredeemできる。
仲介者を使っているが10の処理>Tとなればatomicityは崩れる。
https://gyazo.com/7a65cc49ae1416a64f2ada488de8d2c2
3. その他設計案
仲介者不在型
Bankが両方のネットワークにノードを持っていることを想定する。チェーン間の伝達はBank2の内部で行う。
https://gyazo.com/3439b1eaafcee11f47e2be275beacc07
複数通貨サポート型
仲介者あり、ペグトークンに近い形。相手のネットワークに同一の貨幣を用意する。
https://gyazo.com/838d5a81d99ce34301471d860fc313d4
参考
課題
• HTLCはintermediaryが伝達に失敗すると失敗する
• 複雑なネットワークへの耐性やスケーラビリティ問題
• ノード間の直接通信は単一障害点
解決案
• Using gateway nodes that act as servicenodes for its network participants
• Leveraging on a centralized connector between networks, where networks register and connect directly to the broker
• Having an additional DLT to established connections between the networks
② IBM論文:Enabling Enterprise Blockchain Interoperability with TrustedData Transfer
publish date: 2019-11-4
1. 採用チェーン:HLF vs HLF
2. 伝達手法:TTP型
相手方のチェーンにデータと検証可能なproofを伝達し、relayを行う。今回relayを担うのはProtocol Buffersと呼ばれる両チェーンのネットワークを共有したプロトコル。相手方のチェーンの情報の検証はコントラクトで行われる。(上図ではconfiguration management コントラクトで相手方のチェーンのidentityなどが保持され、data accceptanceコントラクトにおいて具体的な検証が行われる)したがって、インターオペラビリティには事前相手方のチェーンの参加者のidentityなどを知っている必要がある。
tomoaki.icon > 証明書を事前に両チェーンで共有することになるのかな
tomoaki.icon > relay型だから相手のチェーンからの情報がvalidかつfinalizeしている検証があるよね
tomoaki.icon > Protocol Buffersは誰が運営するのか、図から推測するとチャネル内の組織に属さない
moonty_sal.icon protobufはプロトコルで使う型を共有するためにつかってるぽいっすね(Protocol Buffersは一般用語っす)
https://gyazo.com/4f982dd1f67f7c3d74eb70802fbe0bd8
上図のフロー解説
(1)送り先のチェーンのクライアントアプリケーションはローカルのrelayサービスにアクセスしたいチェーンのネットワーク名、レッジャー、コントラクト、関数を指定して引数と一緒にリクエストを送る。この時、事前に決めたverification policyも添える。
(2) ローカルのrelayサービスは指定されたネットワークにアクセスし、データを取得しに行く。
(3) 送り先のチェーンのrelayサービスはリクエストをシリアライズし、バイナリーのメッセージを送信します。
(4) 送り手のチェーンではメッセージのシリアライズを復号し、転送するネットワークを特定する。
(5) 指定されたネットワークのpeerに対してverification policyに従いつつqueryを投げる。
(6) コントラクトの関数を実行する各peerはExposure Control contractを参照しquery主がデータをreadする権利があるかどうか判別数する。
(7) peerはそれぞれverification policyを満たすようにproofを作成する
(8) 送り手のチェーンのrelayサービスは結果をシリアライズし、メッセージを返します。
(9) 返事はアプリケーションに送られます
(10) 最後にアプリケーションはproof付きの返事を元にtxを作成します。
tomoaki.icon > initialization phaseでverification policyが作成される。
tomoaki.icon > 相手方のチェーンをreadして、その値を使ってtx発行するシナリオ
tomoaki.icon > verification policyのpeerの署名がproof
interoperabilityの定義
the semantic dependence between distinct ledgers for the purpose oftransferring or exchanging data or value, with assurances of validity or verifiability
セキュリティの保証
1) confidentiality : 相手方のチェーンのクライアントの公開鍵で暗号化
2) integrity : 事前にMSP証明書を共有することで署名検証を行う
3) availability : DoS攻撃への耐性は今のところないが、後から耐性を実装できるとのこと
他のチェーンへの拡張(ネットワークconfiguration、アイデンティティマネージャー有りのチェーン)
Cordα:notaryの署名を検証すれば拡張可能。
Quorum:署名付きのqueryレスポンスをpeerが行うことで拡張可能
3. その他
TradeLens (TL) We.Trade間のクロスチェーンの例
https://gyazo.com/029ba1952baf066bb0cbfab2492f4c25
フューチャーワーク
• We plan to implement protocols for cross-network transactions and events and incorporate asset exchanges to enable a wider array of use cases.
• We will leverage technologies like decentralized identifiers 12 and verifiable credentials 13 to build decentralized frameworks for the sharing of network identities and configurations. • We will also investigate the construction of an optimal verification policy from a network’s consensus policy
③Project Stella:日本銀行・欧州中央銀行による分散型台帳技術に関する共同調査報告書(第2フェーズ)
publish date: 2018-03-28
1. 採用チェーン:Fabric v.1.1, Corda v2, Elements v2.14
2. 伝達手法:HTLC
https://gyazo.com/f393bbd5aaafeea4688b442f014b4d9c
3. その他
一般的なHTLC型のアトミックスワップ。分散型台帳技術によるDVP決済の実現。
④Project Stella:日本銀行・欧州中央銀行による分散型台帳技術に関する共同調査報告書(第3フェーズ)
publish date: 2019-06-04
1. 採用チェーン:ILP v3, Fabric1.2.1
2. 伝達手法:HTLCなどを活用した手法。具体的には以下の5種
Trustline(つけ払い台帳、ネッティング、オフチェーン)
On-ledger hold/escrow using HTLC(オンチェーンのエスクロー、一般的なHTLCに近い)
Third party escrow(第三者にエスクローをするHTLC)
Simple payment channel(共通台帳に口座を保有する2者間でネッティングし、支払はで署名付き指図で台帳外で実行される)
conditional payment channel with HTLC(署名付き指図は HTLC を用いて台帳によって確実に実行される)
3. その他
安全な台帳間送金を保障する支払方法は、on-ledger escrow 、 conditional payment channel 、および third party escrow。送金参加者は、自身の責任でtrustline や simple payment channel を採用可能だが、支払人の破綻リスクに晒されている点について意識すべきである。また、タイムロックには「フリー・オプション問題」が発生する。
⑤ドイツ取引所Deutsche Börseを中心としたDVPのPoC
publish date: 19 Nov 2019
1. 採用チェーン:HLF vs Corda
2. 伝達手法:不明
3. その他
delivery-versus-payment transaction based on DLTを行うプラットフォーム。
HLF equityチェーン
Corda マネーチェーン
⑥中国建設銀行のトレードファイナンスプラットフォーム
publish date:
1. 採用チェーン:不明
2. 伝達手法:不明
3. その他
⑦Fabric Interoperability: Atomic Commit Between Channels Using HTLC & HTLA
publish date:
1. 採用チェーン:HLF vs HLF
2. 伝達手法:Hashed BTL Protocol (Inspired from HTLC)
3. その他
⑧Hyperledger Labs Blockchain Integration Framework
publish date:
1. 採用チェーン:〇〇 vs 〇〇 (Hyperledger Fabric, Quorum)
2. 伝達手法:TTP(ただしチェーン内のバリデーターがTTPを担うを推奨)
複数のオペレーターによるTTP型であり、そのオペレーターはチェーン内のコンセンサス形成を担うノードが担うことでチェーンのセキュリティと同等のセキュリティでチェーン間の伝達を行う。
https://gyazo.com/630bd1038c4e928312c5eecef1a4b731
3. その他
開発はまだまだ進んでいない。相手方のチェーンのコンセンサスアルゴリズムの理解(バリデーターローテションなど)が必要でゴールまでの道のりはまだまだ遠い。
shuntak.iconetaro.iconyudetamago.iconによる圧倒的まとめ
Hyperledger Fabricはクロスチェーンは向いているのか?
クロスチェーンに向いているどういうことか
・理論的フレンドリー(原理的にクロスチェーンは実現可能か)
・実装的フレンドリー(実装する上でライブラリーなどはあるか)
・ライトクライアントフレンドリー(ライトクライアントに負荷が小さい設計は可能か)
1. HTLC型(atomic swap)
理論的フレンドリー
衝突耐性のあるハッシュ計算ができる必要がある(SHA256など)
あとはタイムロックができる必要がある(ブロックやtxの順序づけができない場合はタイムロックできない?)
tx finalityのタイミングでpre-imageが公開されるようになっているか
実装的フレンドリー
SHA256などのハッシュアルゴリズムのライブラリはあると良い
相手側のチェーンに合わせて変更できると良い
ライトクライアントフレンドリー
- 原則HTLCではswapを行う2者が自らがシークレットの取得を行う必要があり、大変。頻繁にオンラインであることが前提。Ubin Jasperは媒介を取り入れてここの負担を小さくしているのではないか。
HLFで向いているか
HyperLedger FabricのコントラクトはGo、Javascript、Javaなどで記述可能
Quorumで向いているか
Keccak-256、sha256、RIPEMD-160 対応
2. Chain Relay型
理論的フレンドリー
- txが正当かつファイナライズしているかの検証ができる必要がある
- 相手方のチェーンのコンセンサスの仕組みに対応する(IBFTの場合validator setがrotationするので、その条件を理解する)
実装的フレンドリー
相手型のチェーンのコンセンサスアルゴリズムに依存する
署名アルゴリズムやハッシュアルゴリズムを相手のチェーンに合わせて変更できると良い
ライトクライアントフレンドリー
- 基本的にrelayを誰かがやってくれれば負担はない。パプリックチェーンの場合はrelayerにrelayのインセンティブをつけることが多い。プライベートの場合はインセンティブをつける必要特にない。relayする組織を設ける、自分でやるなど方法は多数。
HLFで向いているか
相手型のチェーンのアルゴリズムに依存するが、コントラクトはGo、Javascript、Javaなどで記述可能であるため実装の難易度はさておき、原理的には可能な場合が多い。
Quorumで向いているか
相手型のチェーンのアルゴリズムに依存する。コントラクトはsolidityだと検証難易度が高くなりそう。IBFTの場合validator setがrotationするので相手方のチェーンでの検証は難しい。
tomoaki.icon > まだちゃんと調べてない
3. Trusted Third Party型
理論的フレンドリー
- TTPの署名検証
実装的フレンドリー
- オンチェーンで検証する場合はオンチェーンでtxの送信者を判別する機能(ethereumではmsg.sender)
ライトクライアントフレンドリー
- TTPが勝手にチェーン間のコミュニケーションを実行してくるのでライトクライアントは特別に必要な作業はない。
HLFで向いているか
基本的にTTPをトラストするので実装自体の難易度は低い。組織単位でのオンチェーンでのバリデーションは容易。
tomoaki.icon > 組織レベルでのバリデーションは検証済み。identityレベルのバリデーションは未検証。
Quorumで向いているか
msg.senderによってTTPのバリデーション可能
HTLCの脆弱性
確率的ファイナリティ(PoW)
参考