2017年3月ごろの私は貿易金融の実証実験（※2）を前年7月に終え、その後の、保険証券の実証実験（※3）のまとめをしている頃でした。世の中ではHyperledger Projectが2016年2月の発足から1年ほど経ち、その主要なフレームワークのFabricがv0.6を経て、アーキテクチャを大きく変更したv1.0のリリースが近づいていました。また、Ethereumをエンタープライズ領域に適用するための取組みであるEnterprise Ethereum Alliance（EEA）は少し前の2017年2月に発足しました。仮想通貨のブロックチェーンから企業での利用に向けて本格的な取り組みが具体的に進展していった時期に当たります。
当時話をした10の論点はブロックチェーンについてシステム開発の原則を元にブロックチェーン技術見つめたものでした。基本的にはブロックチェーンも従来の技術とは全く異なる未知の技術ではなく、従来の原則をもとに理解可能という基本的なメッセージは同様です。しかし、この2年間で環境が大きく変わった部分があるので、そういった点を中心に本稿を書いていきたいと思います。

図：ブロックチェーンシステム開発の10の論点

要件に合わせて適切なものを選ぶという点では変わりません。主要なブロックチェーン基盤は2017年春の段階でおおむね出そろっていたと考えてよく、2019年春の現時点でも基本的には同じです。Quorumがはっきりと言及されていなかった程度かと思います。各基盤が実績を積み重ねバージョンアップを果たして今に至っています。
例として活発な開発が続き、事例も多いHyperledger Fabricを取り上げると、v1.0が2017年7月にリリースされ、その後四半期ごとのリリースサイクルが確立され、2019年1月にはFabric初の長期サポート版（Long Term Support： LTS）であるv1.4がリリースされました。そして、v1.0の後の初のメジャーバージョンアップであるv2.0のリリースが今年予定されています。V2.0ではOrdering ServiceにRaftという合意形成アルゴリズムが導入される予定です（※4）。V1.4はLTSをうたっていますが、その期間は1年です。短期の実証実験であれば十分に長いのですが、実用システムで使うには短いです。他のOSS製品でも、例えばRDBMSのPostgreSQLは5年、JavaScriptランタイムのNode.jsは2.5年なので、1年のLTSはまだまだ短く、一般的なソフトウェア製品と比べるとまだ成長段階といえると思います。

単純なシステムの置き場所をどこにするかという点では、必ずしもクラウドではなく、要件に応じて判断するということは変わりません。しかし、Blockchain as a Service（BaaS）の選択肢が増えてきたのは当時との大きな違いです。クラウド事業者によって管理されるブロックチェーン環境を利用することにより、構築のための初期投資を抑えたり、専門知識の不足を補ったりすることがある程度できる可能性があります。一方で、地域、利用できる製品/バージョン、スケーラビリティ、相互運用性などが希望通りとはいかない可能性もあります。代表的なBaaSサービスには次のようなものがあります。IBM Blockchain Platform（Fabric）（※5）、Oracle Blockchain Cloud Service（Fabric）（※6）、Amazon Managed Blockchain（Fabric, Ethereum）（※7）。Hyperledger Fabricが各社で採用されていて、ブロックチェーン基盤の人気の一つの指標になると思います。
各社のサービスでは独自の拡張機能が使える場合があります。例えばOracleではFabricのステートデータベースにBerkeley DBが使える、AmazonであればOrdererのバックエンドに独自のQLDBが使われるといったものがあります。

Fabric v1.xでは当初はチェーンコードの対応言語がGoのみでしたが、後からNode.jsとJavaといった一般によく使われるものがサポートされるようになりました。そのためチェーンコードをかなり実装しやすくなりました。外部アプリケーションからFabricにアクセスするためのSDKもNode.js、Go、Java用などがあります。開発の活発度に差があるので、プログラミング言語だけではなく、開発の活発度や実装されている機能を考慮して選択します。Node.jsのものが開発も活発で使いやすいです。ちなみに、私は開発ツールにはVisual Studio Codeを使うことが多いです。なお、Hyperledger Composerは主な開発者の関与が少なくなってしまったため、使用するのであれば、プロジェクトの状況を確認したほうがよいでしょう（※8）。
Ethereumは相変わらず、独自のSolidityと付き合う必要がありますが、開発ツールとしてIDEのRemix（※9）、テストフレームワークのTruffle（※10）が出てきて開発はだいぶ楽になってきました。

3つの論点を中心に2017年からの2年間を振り返ってみました。ここで取り上げたこと以外にもたくさんの変化はありますが、次元の違う劇的な変化があったというよりは、実用サービスの基盤として着実に進化してきたと思います。今後も改善が続いていくと思いますが、パフォーマンス、スケーラビリティ、プライバシーといった点ではまだ課題があり、既存の基盤の大きな変化や、全く新しい基盤の登場もありうると思うので、まだまだ目の離せない技術であり続けると思います。