【特別インタビュー:前編】日本IBMブロックチェーンテクニカルリーダー 紫関 昭光 氏

【特別インタビュー:前編】日本IBMブロックチェーンテクニカルリーダー 紫関 昭光 氏

ブロックチェーン業界で活躍するプレイヤーにスポットライトを当てる特別インタビュー、今回は日本IBMのブロックチェーンテクニカルリーダー・IBM Cloud Meisterの紫関昭光氏です。

前編・後編の2部構成でお届けいたします。
まずは、インタビュー前編です。

※本記事の最後に後編へのリンクがございます。

IBMとブロックチェーンの関係は

IBMは Hyperledgerプロジェクトの創設メンバーであり、Hyperledger Fabricの開発に貢献しています。同社は独自のBaaS「IBM Blockchain Platform」も提供しています。今回は、IBMでブロックチェーンクラウドリーダー・IBM Cloud Meisterとして長年活躍されている紫関昭光氏にお話を伺いました。

▼公式
IBM Blockchain Platform

インタビュー:前編

ブロックチェーンとの関わりについて


ブロックチェーンにはいつ頃から注目していましたか? またそのきっかけを教えてください。

2016年、あるメーカーに対してクラウドのアーキテクチャ作成を支援していた際、その会社の方が 「ブロックチェーンのことを誰か専門家に聞きたい」とおっしゃいました。それだったら自分で説明しようかなと思ったのがきっかけです。
当時はまだHyperledgerプロジェクトが立ち上がったばかりでした。日本のメンバーを集めたいとのことで、大手ITベンダーやシステムインテグレータが集まって、みんなで盛り上げていこうという雰囲気でした。


ブロックチェーンクラウドリーダーとして、社内ではどのようなお仕事をされていますか?

当初はまだ興味先行で、本番のプロジェクトはスタートしていませんでした。とはいえPoCはたくさんできていたので、それをリードしていくというのが主な仕事です。
ブロックチェーンに最初に興味を持ったのは、どちらかというとR&D部門です。しかし、テクノロジーありきでスタートしたためにユースケースが置き去りにされてしまい、それ以上なかなか発展しませんでした。そこである時期から、もっとユースケ-スを大事にしなければと考えるようになりました。
最近は、ブロックチェーンは「テクノロジー」ではなくて「ポリティクス」であるとIBMの中では認識されています。


ブロックチェーンは「ポリティクス」である、とはどういうことでしょうか?

政治家が派閥を大きくしていくイメージです。仲間に入るとこういうメリットがあり、これだけのフィージビリティがありますよというのを示していくわけです。
「ネットワーク効果」というものがあります。これは、参加者が増えるほどネットワークの価値が高まり、ますます参加者が増えるという仕組みを指します。
ブロックチェーンのネットワークも同じです。最初に成功したビジネスネットワークができると、新しい人がどこかに入ろうとしたとき、やはりその大きいところに入っていきます。小さいネットワークより、すでに動いている大きいネットワークに入る方がメリットがありますから。
我々の「TradeLens」は、いまや海運業者の6~7割が加入しており、今後ますます吸引力を増していくと思われます。マースク(Maersk)をはじめトップの海運業者たちが入っているコンソーシアムがあれば、みんなそこに入っていくだろうということです。


ブロックチェーンの今後とIBMの取り組み


御社がブロックチェーンに取り組む上で、どのようなゴールを目指されていますか?

IBMの一番の目的は、テクノロジーではなくてビジネスの課題を解決することです。ブロックチェーンで解ける問題はたくさんあります。そこで、お客様と一緒に解いていこうとしています。

テクノロジーの話もすると、ブロックチェーンのノードは、AWS、Azure、IBMクラウド、あるいはオンプレミスなどさまざまなところに立っていますが、そこを限定してしまうとブロックチェーンの設計思想に合いません。そこで我々は、クラウドの世界ではマルチクラウドを提案していますし、Kubernetesをプラットフォーム層に置くことで、すべて同じ環境で使えるように推進しています。テクノロジーとしてはここを重視しています。


ブロックチェーンは今後、どう変化していくとお考えですか? エンタープライズの導入が進んでいく中で、どのような未来像を描いているのかお聞かせください。

ブロックチェーンに世間が興味を持ち始めたのは仮想通貨の文脈です。しかしHyperledger Fabricが目指しているのはそこではありません。本当にやりたいのは「100%は信頼できない人と、信頼関係をテクノロジーで作っていく」ということ、そこがポイントです。

これまでのビジネススタイルではメーカー系列があり、内部の関係者たちは相互の信頼関係がありました。しかしこれからの世の中は業種業界・国境を超えてネットワークでビジネスをすることが増えていきます。そこで、企業・人間関係に代わる信頼をテクノロジーで保証するというニーズがあります。ブロックチェーンはまさにそのテクノロジーであり、これがHyperledger Fabricの目指すところです。

ただ悩ましいのが、ブロックチェーンというテクノロジー自体がまだ信用されていないせいでなかなか先に進まないことですね。導入が進んでいくための条件として、3つのポイントがあります。

一つ目は、ニーズがあることです。独立した企業が従来の垣根を越えた信頼を形成して連携ビジネスをつくり、GAFAのような巨大グローバルIT企業に対抗するというニーズは、やはり実際にあります。

二つ目は、事例が出てくることです。いい事例は特にリテールの世界でお客様の目にふれだしていて、これならできるのかなという感覚が醸成されつつあります。

三つ目は、テクノロジーをきちんと理解することです。しかし、Hyperledger Fabricのテクノロジーを一般の人が完全に理解するのは難しいです。だから、「テクノロジーはよくわからないけれども、この人が言うなら信用できる」という人が現れることが大事です。例えばTCP/IPやRDBも仕組みを完全に理解している人はほとんどいませんが、知識のある人を信用して皆使っています。これと同じです。

Hyperledger Fabricの遷移と最新バージョン(v2.0)について


それでは、Hyperledger Fabric について伺っていきたいと思います。Hyperledger Fabricはこれまでどのように変化してきましたか?

初期のv0.6ではBFT(ビザンチン・フォールト・トレランス)をつくりましたが、パフォーマンスが出ませんでした。その後v1.0になり、Kafka や Raft による CFT(クラッシュ・フォールト・トレランス)に変化してきました。そして先日v2.0が出ました。

この流れで重要なことの一つは、プライベートデータの扱いです。ブロックチェーンはデータを共有するというのがスタートですが、ビジネスユースだと誰とでも共有できるわけではありません。そこでチャネルが出てきました。しかしチャネルだとオーダラー(Orderer)にはデータが流れてしまうということで、今度はプライベートデータコレクションが出てきました。

▼関連記事
Clique PoA, IBFT, Raftの違いと選び方


そしてv2.0になったわけですね。

はい。v2.0で解決したことの一つ目は、定義体の爆発問題です。チャネルやプライベートデータコレクションでは、ビジネスネットワークの参加者がNだとするとNの順列組合せのような非常に多い定義体が必要でした。

二つ目は、Centralized/Decentralizedに関することです。パーミッション型のブロックチェーンだと管理主体が不可欠ですが、それだと従来の中央集権と同じではないかという指摘もありました。この問題に対してこれまでも取り組んできましたが、最終的にはチェーンコード(Hyperledger Fabricにおけるスマートコントラクトのこと)のライフサイクル管理と、オーダラーが結局一つの組織にしか入らないという二つの問題が残りました。それらを解決したのが今回のv2.0です。

チェーンコード自体はそれぞれの組織のピア(Peer)の管理者が自分でインストールするのである意味独立していたのですが、パラメータ(特にエンドースメントポリシー)は誰かが決めたものに追随するしかありませんでした。これを投票制にできるようになったのが一つ。もう一つは、オーダラーのノードを組織に分散し、チャネルの役割分担ができるようになりました。これによって、Decentralizedに向けて大きく前進しました。


なるほど。Hyperledger Fabric v2.0の目玉は、プライベートデータの扱いが容易になったことと、よりDecentralizedになったことなんですね。今回のアップデートについて、紫関さんはどうお考えですか?

ユースケースが広がるという意味で、プライベートデータが扱いやすくなったのは明るいニュースだと思います。
「コンセンサス」という言葉について、ブロックチェーンにおける意味と一般的な意味とは違うと思います。一般的な「コンセンサス」は、取引する両者がその時々に応じて合意し契約することです。しかしブロックチェーンの「コンセンサス」は違います。

一つ目は、あらかじめ決められたルールがチェーンコードに書かれていて、そこから逸脱していないということ。二つ目は、同時にたくさん入ってきたトランザクションに皆が同意する一意の順番がつくということです。
v2.0である種のアーキテクチャをつくると、取引業者間でのダイナミックなコンセンサスをある程度カバーできるようになります。それで、ユースケースの幅が広がるのではと考えています。



他のエンタープライズ向けブロックチェーン(CordaやQuorumなど)と比較したとき、Hyperledger Fabricを選ぶ理由は何だと思いますか?

私がいいなと思っているのは、ガバナンスがオープンだということです。オープンソースとオープンガバナンスは似て非なるもので、その意味でCordaQuorumはかなりクローズドだと私は思っています。それに対してHyperledgerは非営利団体Linux Foundationのもとにあり、ライセンス、機能を決めていくプロセスの透明性、誰もがコントリビューションできる点など、非常にオープンです。

例えばこういうこともあります。Hyperledger Fabric は去年の今頃v2.0のα版が出ていました。その目玉としてFAB TokenというHyperledger Fabric上でトークンを実装できる機能があり、そのコンセンサスの仕組みをUTXOにしました。ですが、その必要性があるのか議論され最終的には不要だという結論に至りました。このように、オープンにディスカッションされてきて今があります。このオープンさが他にはない特徴です。

またアーキテクチャとしては、コンセンサスの仕組みを含めてPluggableになっているのが特徴です。よりよいものに変えていこうということで最新バージョンではKafkaを非推奨 (deprecated) にして Raft に切り替えましたし、StateDBにしてもCouchDB・LevelDBと選ぶことができます。そのため、アプリケーションやユースケースの場を選ばず、なんでも対応できるのがHyperledger Fabricの強みです。実際にエンタープライズでのユースケースはHyperledger Fabricが多いです。

※ インタビューは後編に続きます。

インタビューカテゴリの最新記事