インターオペラビリティってなんだっけという話と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でのインターオペラビリティ
で、本題に入ろうと思ったんですけどちょっともう前段が長くなりすぎたのでこのポストはここまでなんだ、すまない。がんばって読めばわかる資料だけとりあえず紹介しておきます↓。そのうちこれの内容の解説編を書きます。たぶん。
