空谷に吼える

ブロックチェーン/DLTまわりのなにかしらを書いていく所存

インターオペラビリティってなんだっけという話とHyperledger Fabricでのそのへんの情報

「FabricでHTLCとか使えないの?」とか「Fabricと他のブロックチェーンとまたいでAtomicなトランザクションてどうやればいいんすかね?」とかのインターオペラビリティ周りの質問を最近だけで計3回いただいたのでこれを書いておきます。

そもそもブロックチェーンにおけるインターオペラビリティとは

本題のHyperledger Fabricでのインターオペラビリティの話に入る前にインターオペラビリティってなんだっけという話をちょっとします。

インターオペラビリティ(Interoperability)の訳語は「相互運用性」ということになっており、これはすなわち「異なるものを相互に組み合わせて運用できること」ですね。で、この語がブロックチェーンとかDLTの文脈で使われるときには、この「異なるもの」というのは「異なるブロックチェーンネットワーク」のことを指しています。

なお、ここでこの「異なる」というのは必ずしも異種混合Heterogeneousであるというわけではなく、例えばふたつのプライベートなEtheruemネットワーク間のアセット異動のような、同種Homogeneousであってもネットワークを複数またいでいればそれはインターオペラビリティと呼んでいいという認識でいます。異種間で、という含みをもたせたい場合は現状だとクロスチェーンという用語を使うのがいいっぽい。でもこのへんはどうもコンセンサス取れてないのでわたしも含めて用語法が移り変わっていくかもしれないですね。

じゃあ後半の「相互に組み合わせて運用」って何を指しているのかと言うとこれは「ネットワークをまたいだトランザクション(のセット)をAtomicに(それぞれの)台帳にコミットすることを実現できる」ことだと理解しています*1。これのわかりやすい例がアトミックスワップで、BTCとLTCなどの組み合わせでネットワークをまたいだ暗号通貨の交換を交換所などの仲介者なしにAtomicに実現しているらしい技術です(詳しくは知らない)。

Atomicityの重要性

トランザクション(のセット)がAtomicであるというのはどういうことかというのはたぶん説明しなくてもわかってると思うのでここでは説明しませんが(わからないひとは"トランザクション Atomic"でググる)、じゃあなんでそれが重要なのかということについてもたぶんみんなわかってるだろうなーと思いながら一応説明しておくと期待されている結果のセットのうち一部だけが確定されちゃうと困るからです。

先程のアトミックスワップの例はわかりやすくて、BTCとLTCを交換しようと相手と約束してBTC渡したのに、相手がLTC一向に送ってこないやんけ、とかのクソイベントが起きるとあなたはすごく嫌な気分になります。なので、交換なんだからBTCを送るのとLTCを受け取るのをセットで両方とも成功するか、両方とも失敗するかにしといてくれや、という気持ちになりますね。

こういう交換における詐欺的なやつではなくとも、単に台帳L1に記録されているアセットA1を台帳L2に異動しようとしていて、まず台帳L1で削除してその後に台帳L2に書き込もう、とやったら台帳L2を抱えるネットワークで障害が起きていてアセットA1が追加できませんでした、でも台帳での削除は確定しているのでアセットA1はなんだか消滅してしまいました、みたいなことはもう考えるだけで蕁麻疹が出てくるくらい面倒なのでやはり、L1での削除とL2への追加をセットで扱ってくれや、という気持ちになります。

というわけでネットワーク間、台帳間でのトランザクションのセットをAtomicに扱える仕組みがないと困る局面がなかなか多いわけです。

複数トランザクションのAtomicityの実現方法

ブロックチェーン/DLTではもちろん単一のネットワーク/台帳でのそれぞれのトランザクションはそのネットワーク/台帳の中ではAtomicになっています。が、これが異なるネットワークをまたいだトランザクション(のセット)となるとネイティブにそのAtomicityを保護する仕組みはないので、やり方考えないとならんよねというのがインターオペラビリティ問題なわけです。

ここではやや雑、不正確な話にはなってしまいますが、複数トランザクションをセットとして扱いその結果のAtomicityを実現する方法を以下では仲介者Coordinatorを使うやり方と、そうでないものに分けてみます。

仲介者を使う方法

暗号通貨の交換の文脈で言うと、暗号通貨交換所を信頼された仲介者、つまりエスクローとして利用して交換を行うやりかたがふつうに行われています。分散システム的な文脈ではトランザクションマネージャを仲介者として利用した2 Phase Commit/3 Phase Commit(2PC/3PC)がありますね。

この方法の問題点は仲介者に信頼が必要になることです。暗号通貨交換所は交換の当事者双方から送られたをネコババしたり、あるいは払い出し前に破産したり障害が起きたりして引き出し不能になったりはしないだろう、という点について信用しなければ使えません。つまり仲介者の利用によるリスクが発生しているということです。また、取引所はふつう対価として手数料も取るので、追加コストも発生します。

トランザクションマネージャ(あるいはトランザクションコーディネータ)ももしかするとバグっていてAtomicityが崩れたり、ダウンしていてそもそも利用不能だったりするかもしれません。トランザクションマネージャの利用にも同様にリスク、そして運用コストが追加で発生しています。また、ブロックチェーンでのトランザクションロールバックできないので、2PC/3PCといった既に標準的になっている仕組みは使えません。補償トランザクションなどを駆使して自分で仕組みを作り込む必要があります。

というわけで仲介者を使う方法はリスクポイントが増えている、場合によっては追加コストが発生するなどのデメリットあるいは制約があります。

仲介者ナシで実現する方法

上記の通りなので、できることであれば登場人物を増やさずにAtomicityを実現したいところです。そこで、セットに含まれるトランザクションそれ自体に仕掛けをほどこしておくことで一種自律的にAtomicityを実現する方法が検討、実現されています。アトミックスワップは暗号通貨の交換においてのこの方法にあたり、また、アトミックスワップのベースとなっているところのHTLC(Hashed Time-Locked Contract)という仕組みがあるそうです(詳しくは知らない)。HTLCについては↓がわかりやすかったので読んでみましょう。

techmedia-think.hatenablog.com

ここで気をつけておきたいのはHTLCではその結果の確定までの手数自体は増えていることですね。単にAliceがBobにBTCを送る、BobがAliceにLTCを送る、というのであればトランザクション2手で済んでいたところ、事前の合意やシークレットの交換などの手順が追加になっています。暗号通貨の交換での利用であればメリットに対してこの点は許容可能だと思いますが、先程の台帳間でのアセットの単なる異動のようなケースではHTLCなどの仕組みは過剰であると判断してシンプルにやったほうがいい(失敗したら補償トランザクションでなんとかする)という判断もあり得るかもしれません。

Hyperledger Fabricでのインターオペラビリティ

で、本題に入ろうと思ったんですけどちょっともう前段が長くなりすぎたのでこのポストはここまでなんだ、すまない。がんばって読めばわかる資料だけとりあえず紹介しておきます↓。そのうちこれの内容の解説編を書きます。たぶん。

blockchain-fabric.blogspot.com

*1:ちなみに「他のネットワークの台帳を参照する」というだけなのであればそれは外部オラクル問題であってインターオペラビリティ問題ではない認識。

Hyperledger ComposerがDeprecatedのステータスに

ちょっと用があってHyperledger Composerのgithubを見に行ったら2019/8/29付でComposerはdeprecated(非推奨)になったよというお知らせが出ていました。

github.com

Hyperledger Composerはプロトタイピングなどの際にFabric(など)を容易に使い始められるようにネットワーク構築とスマートコントラクト(Chaincode)開発をセットで抽象化して提供してくれるフレームワークです。主にIBMによって開発されていたところ、2018/8/30に以下のお知らせで、IBMはFabric本体に注力するためComposerの開発からは手を引きますと発表されていました。

Composer TSC update

このお知らせ以降もComposer自体はプロジェクトのステータスは変わっていなかったんですが、ちょうど1年くらいで今回のdeprecatedへのステータス変更の運びとなったようです。この間、特に積極的にはアナウンスされなかったので、知らずに新たにComposerを使い始めてしまうひとたちもちらほら見かけていました。ちょっと遅くなった感はありますが、きちんとdeprecatedに変更されたのは良いことだと受け止めています。

最近は公式ドキュメントやブログなどの情報、周辺ツールやクラウドテンプレート、Blockchain as a Serviceなどの発展によって、Composerを使わなくてもFabricのネットワーク構築やChaincode開発がComposer登場当時よりも遥かに容易にできるようになってきていますので、特にネガティブな影響もないかな、と思います。

2019/9/2時点ではHyperledger.org内の以下のComposerの紹介ページには特に変わりがないようですが、そのうちステータス変更が反映されるでしょう。→2019/9/4追記:今見たらこっちもdeprecatedになってました

www.hyperledger.org

Hyperledger Fabric v1.4.2がリリース

2019/7/17付でHLF v1.4.2がリリースされていました。

■HLF v1.4.2リリースノート: Release v1.4.2 Release Notes - July 17, 2019 · hyperledger/fabric · GitHub

公式ドキュメントとしてはv1.4系のドキュメントが更新され、v1.4.2の追加、変更が反映されています。ただしv1.4.2での差分はわかりづらいのでリリースノートを見たほうがいいと思います。

■公式ドキュメント: What’s new in v1.4 — hyperledger-fabricdocs master documentation

気になる新機能、機能強化ですが、主要なところは以下ふたつかな:

  • Kafka to Raft Consensus Migration: KafkaのOrdering ServiceからRAFTへの移行がサポートされたみたいです。手順はこちら

  • Channel rollback on a peer: あるPeerについて指定したBlock Number以降のStateの更新およびBlockを破棄させるPeer Rollback、およびGenesis Block以降を破棄させるPeer Resetが機能追加されたそうです。あるPeerのStateDBを直接いじっちゃってState変になっちゃったわーやべーわーみたいなときに使う機能ですね。破棄した分はOrdering Serviceまたは他Peerから再度取得してくるので正常なStateに復帰できますよという寸法です。

そんで今回のリリースではDeprecationsが重要。

The following functions are deprecated and are targeted for removal in a future release.

とあるのですぐに廃止ではないですが、将来的には廃止の方向なようなので新たに使うのはやめておく、既に使っている場合は違うやり方を準備するなどして備えておきましょう。これも重要そうなところだけ抜粋:

  • Support for automatically vendoring the chaincode shim into user chaincodes: github.com/hyperledger/fabric/core/chaincode/shim ("shim") パッケージは手動でVendoringしなくてもChaincode実行環境のイメージに含まれているものを使ってくれてたんですが、その自動Vendoringがナシになるそうです。代替案としては手動でVendoringしてくださいという話になり、します、はい、ということになります。

  • Support for invoking system chaincodes from user chaincodes: 現状ではユーザーChaincode(ふつうのChaincode)からQSCCなどのSystem Chaincodeを呼び出せるらしいんですが、このSystem CC呼び出しは不可になる模様です。らしい、と書いたのはわたしも前にトライしてみたけど動かなかったからです。。。この辺JIRA見ててもバグとか多かったのと、これ使ってると過剰に複雑になるので、個人的にはなくなるのは賛成、歓迎です。ただしChaincodeの中から生っぽくBlockやTxを触りたくてQSCC使ってるひとはいるかもしれないので、そのひとは代替案を考えなければならないですね(今の所ちょっと思いつかない)。

  • Support for Solo ordering service: RAFTでOrderingノードひとつだけの構成取れるんでSOLOは要らないでしょということな模様。はい。

Oracle Blockchain Platform Cloud Serviceで非-決定論的なChaincodeをインストール、インスタンス化してREST APIで実行

なんの話

  • 非-決定論的なChaincodeを例を挙げて説明
  • Oracle Blockchain Platform Cloud ServiceでChaincodeのインストール、インスタンス化を行う方法を紹介
  • Oracle Blockchain Platform Cloud ServiceでREST Proxyを通じてChaincodeを実行する方法を紹介
  • 非-決定論的なChaincodeの挙動を確認
続きを読む

Enterprise EthereumのQuorumをさくっと机上でお勉強してみたメモ

最近話題のQuorumをとりあえず机上でお勉強してみています。いろいろわからないからお勉強しているのであって当たり前ではありますが、Quorumへの言及では間違ったこととか書くかもしれません。何かお気づきのところあったらご指摘いただけると助かります。

続きを読む

University of Waterlooの研究室がHyperledger Fabricを7倍速くする方法を提案

Hyperledger Fabric(HLF)をリエンジニアリングしてスループットをほぼ7倍(3000⇒20000)にしてやったぜというペーパーをカナダのUniversity of Waterlooの研究室が公開、というニュースが出ていました。

cointelegraph.com

そのペーパーは以下で読めますので読みましょう。

FastFabric: Scaling Hyperledger Fabric to 20,000 Transactions per Second

とりあえず開いたけど英語だし字がつぶつぶしてるじゃん、ヤダーーッ!ってなりましたか?わたしもウッってなりましたががんばって読んだ、そしてわたしはしんせつなのでペーパーの要点を以下にまとめていきます。

続きを読む

Hyperledger Fabric v1.4.1でRAFTのOrdering Serviceをサポート

3/29付でHLF v1.4.1のRC(Release Candidate)1がリリースされ、RAFTのOrdering Serviceサポートが含まれています。まだRC版なんで正式リリースじゃないんですが下記の通りドキュメントにも先んじて追記されてるしまあたぶん撤回されたりはしないでしょう

■HLF v1.4.1 RC1 リリースノート: Release v1.4.1-rc1 Release Notes - March 29, 2019 · hyperledger/fabric · GitHub

既に公式ドキュメントにもRAFT Ordering Serviceの説明が追加されていました。

■RAFT Ordering Serviceの説明: The Ordering Service — hyperledger-fabricdocs master documentation

これまで選べたSoloおよびKafkaはOrdererノードをひとつの組織(Organization)が独占することを(事実上)前提としていますが、RAFTは複数組織間でOrdererノードを分散させることが可能とされています。ていうかわたしはRAFT Ordering Serviceもひとつの組織がOrdererノードを独占するものだと思ってましたが違っていた、そのような説明を受けた方々すまんかった

RAFT自体のお勉強は以下の資料がわかりやすいと思いました。Paxosよりも百倍わかりやすいと言われるRAFTですが、まあまあ難しいです。でもまあFabricのコンセンサスを完全に理解している俺たちにはどうということはなかったぜ

Raft

RAFTそのものがBFT(Byzantine Fault Tolerant)ではなくCFT(Clash Fault Tolerant)なため、RAFT Ordering ServiceもBFTではないことには注意が必要です。そのうちBFT Smartを採用したOrdering Serviceも出るはずです。Ordering ServiceにBFT性が求められるような互いへのトラストが低いコンソーシアムの運用を考えている場合はBFT Smartが早くサポートされるように祈りましょう。

気になるのは速度(スループット)がどんくらい出るかデスヨネー。おそらくはKafkaよりもRAFTのほうがオーバーヘッドが多くて遅いでしょうというのと、OrdererノードをOrganization分散して持った場合にはネットワーク遅延がけっこう効いてきそう。コンソーシアムのトラストのあり方と求められるスループットを考慮してKafka、RAFTそしてBFT SmartからOrdering Serviceを選びましょうね、ということになるんでしょうね