BIF: Blockchain Integration Framework
Blockchain Integration Frameworkとは
Accenture の開発者が開発している ブロックチェーンのインターオペラビリティのためのFramework
permissonedブロックチェーン上のデータをプラットフォーム (e.g. Hyperledger Fabric, Quorum, etc.) に依存せず、中間者無しで交換するコミュニケーションモデルを定義する。
https://gyazo.com/630bd1038c4e928312c5eecef1a4b731
Interoperability validators は、基本的には既にそのBlockchainのガバナンスやコンセンサスに参加しているnodeが行う。
そうでない場合もあり、その場合は外部のdiscoverableなnodeが行
Etaro.icon > 後者の場合は「中間者無しで」ではなくなる
yudetamago.icon >
A transfer validator is a distributed ledger participant who may take specific actions in the transfer mechanisms and provide certain services to the other participants of the distributed ledger
Any well-known participant, within and outside the local distributed ledger, is a good potential candidate
BIFによるインターオペラビリティの分類
Connector approach
non-trusted blockchain gatewayによるtransfer protcolの構築 (e.g. Interledger) blockchain of blockcahins approach
複数のブロックチェーン "zone" を 中央ブロックチェーン "hub" につなぐ (e.g. Cosmos) BIF approach
permissioned blockchainに特化した設計 (将来的にはpermissionlessな方にも拡張)
BIFの構成
BIFアーキテクチャ
実装から、BIFは以下のようなアーキテクチャとなっていると思われる。
BIF Client (BIFを利用したいサーバー等)
(external HTTP)
BIF API
(internal message exchange via zmq)
BIF Validators
(external HTTP)
each Web API for each Blockchain (各ブロックチェーンのRPCを直接叩くのではなく、フロントとなるWeb APIがあることを想定)
(external HTTP)
each Blockchain (Fabric, Besu, Quorum, Corda, etc.)
これらのrelation
BIF API : BIF Validators == 1 : N
BIF Validators set : Web API for Blockchain == 1 : N
Web API for Blockchain : Blockchain == 1 : 1
また、BIF v0.1はドラフトであり、ここから最適化が行われていくだろう。
BIF API
BIF Validatorsへのアクセスを提供するAPI
まだ何も実装されてない
BIF Validators
BIF配下の各ブロックチェーンとのやり取りを担当するコンポーネント
BIF validator同士のコンセンサスはRaftで行われる (実装としてetcdを採用)
BIF validatorへのリクエストはメッセージを介して行われる (実装としてzmqを採用)
Validator起動時にConnectorを注入できるようになっている
BIF Validatore Plugin Connector
各ブロックチェーンと実際に通信するプラグイン
BIF Validator起動時に注入可能
Connectorの層で各ブロックチェーンのWeb APIを叩くようになっており、ブロックチェーンごとに異なるインタフェースの違いを吸収する
BIFで実現可能な接続のパターン
shuntak.icon > Valueを送るかDataを送るかというのは本質的に違いはないので、分類として微妙な気がする
Use case examples in Whitepaper
2.1 Ethereum to Quorum Asset Transfer
User AがEtherum 上のassetをQuorumにコピーするシナリオを想定
必要項目
User AがどちらのLedgerにもaddressを保有している
Ethereum のvalidator 1 (BIF Validators がEtherum Nodeを運営しているという場合もある)
Quorumのvalidator 2 (BIF Validators がQuorum Nodeを運営しているという場合もある)
User Aにサービスを提供しているService AppとService Server
Etaro.icon > Service Server がUser Aのkeysを持っているはず
shuntak.icon > validator 1と validator 2はそれぞれ複数のnodeで構成されてるはず(でなければセキュリティを担保できない)
手順
1. Ethereum上のUser Aのasset をLockする
User Aのpriv keyでService Server がEthereum にTXを送る
EthereumのvalidatorがEventを検知し、そのTXにsignしてServerに送信
Etaro.icon > Ethereumのfinality検証を真面目にしているわけではないのでこちら側は完全にNotary型
Client App側のStatusが更新される
2. Quorum 上でassetをUser A addressにtransferする
Service Server からQuorumにUser Aにasset を付与するTXを送信
QuorumのvalidatorがそのEventを検知し、そのTXにsignしてServerに送信
Etaro.icon > ここでQuorum側のvalidatorsが複数であるならばConsensus検証を行うのと同等のセキュリティを担保できる可能性がある
Client App側のStatusが更新される
3. LockされていたEthereum 上のassetをunlockする
Service Server がEthereum にunlock TXを送る
EthereumのvalidatorがEventを検知し、そのTXにsignしてServerに送信
Client App側のStatusが更新される
2.2 Escrowed Sale of Data for Coins
CoinとDataのアトミックスワップ
User Aがデータを買おうとしてる
User Bがデータを売ろうとしてる
User A, Bそれぞれが順次CoinとDataエスクローし、両方ともエスクローしたことを確認したら、BIFのAPIがアンロックしてUser A, Bに送付する
FabricにData, BesuにCoinが載ってる
BIFのレイヤーにはAPIのみ
shuntak.icon > シーケンス図的にはrelayの検証をしてない
shuntak.icon > unlock用の鍵はAPIが持ってる?
2.4 Stable Coin Pegged to Other Currency
User Aが独自ledgerを運営/管理しているowner
User Aはその独自ledger にBIF のinterfaceに対応したContractをdeployしている
Etaro.icon > example tokenをonly owner(User A) でmint/burnするContractを作っておくってだけかと。
この独自ledgerとBitcoinのtwo-way-pegを実現したいケースを考える
With Permissionless Ledgers (BTC)
Bitcoin Blockchain 上でTTPが管理しているExampleCoin Reserve WalletにBTCを送信すると、同額のCoinがOther Blockchainでmintされる
Other Blockchain でcoinをburnするとBTCをredeemできる
Etaro.icon > 単純なNotary型
USDなどのfiat currencyも同様に実装する
2.5 Healthcare Data Sharing with Access Control Lists
BesuとFabricの例
User A: 患者。自分の過去の病歴をサービス提供者に開示して、新しいエントリを追加してもらう
User B:サービス提供者。患者から病歴の読み込み・書き込み権限をもらい、新しいエントリを追加する
流れ
1. User Bがアクセスを要求して、User Aに確認がいく
2. User Aが許可すると、APIはBesuからassetを取得
3. assetをverifyして、署名が違っていればabort
4. APIからvalidatorを経由してFabricに新しいassetを作成する
5. User Bにデータを渡す
yudetamago.icon>
User Aの過去のデータはBesuにあって、User Bが提供しているサービスで使っているチェーンはFabricの想定?
シーケンス図は、User AのデータをUser Bが提供しているサービス(チェーン)にコピーすることでデータ共有しているということ?
(User Bに対してはアクセス制御は出来ていそうだが)verify assetするためにはvalidatorはBesuから情報を取ってこれる必要あり?
アクセス制御自体はAPIでやる?
Etaro.icon > Validatorsは besuもHLFもどっちもNode持ってるマンかな
2.6 Integrate Existing Food Traceability Solutions
shuntak.icon > 中央のアプリケーションはおそらく小売店が管理してる(end to endでサービス提供したいのは小売店なので)
シナリオ
消費者は食品トレーサビリティの結果を判断して食料品購入の判断をしたい
小売店と食品製造業者でそれぞれ異なる食品トレーサビリティシステムを利用している
しかもそれぞれ異なるDLT上で構築されている
小売店はend to endの食品トレーサビリティを提供したい
BIFの使われ方
データ記録時
小売業、食品製造業者ともにアプリケーション→BIFのAPI経由でDLTにアクセスし、データを書き込む
シーケンス図によると、どちらのDLTに書き込むべきかはBIFのAPIでハンドリング
データ統合
BIFのAPI経由でDLTにアクセスし、データを取得する
互いのDLTで足りないデータがあれば書き込んでおく
shuntak.icon > 両方のDLTに書き込みしてるが、小売店のDLTだけに書き込めば良いのでは
消費者利用時
アプリケーション→BIFのAPI経由でDLTにアクセスし、データを取得する
データ統合により完全な食品トレーサビリティ情報が作成されている
問題点・疑問点
shuntak.icon > 他の例と同様にBIFのAPIが鍵を持ってそう
shuntak.icon > このシーケンス図によると、データ登録時、食品製造業者も小売店のアプリケーションを利用しなければならないが、実際には利用する必要ないのでは(BIFも不要なのでは)
2.7 End User Wallet Authentication/Authorization
User Aは2つ以上のchainでそれぞれ別のidentity (pub/priv key)を持っている
User AはそれらのIdentityをそれぞれのpriv keyを管理することなく、 single APIで扱いたい
BIFでその一元管理を行う
手順
1. Register with BIF
Etaro.icon > 普通にBIFのservice serverにuserとして登録するだけ
2. Import PKI to BIF keychain component
BIF のkey chain componentにchain Aと chain B両方のPriv keyをimport
3. BIFサーバーから両方のchainを叩いてもらう
BIFのkeychain component は 複数のchainに対してTXを送信する Connector pluginを持っている
Etaro.icon > ただのservice serverよろしこスタイル
その他所感
yudetamago.icon >
「2. Example Use Cases」のところにCordaの例は無し?
shuntak.icon > validator set自体はraftで合意形成してるっぽい
Raft実装のEtcd使ってる
DLTがBFTのとき壊れるんじゃね