2017年9月6日、日本銀行と欧州中央銀行は、ブロックチェーン技術に関する共同調査プロジェクト「Project Stella」の調査結果を公表し、複数のコンピューターで共通のデータを管理するブロックチェーン技術が、中央銀行が運用する決済システムに適用できるかを実験しました。決済処理の多い時でも、日銀が現在運用する決済システムと同じ速度で処理できることを確認している一方で、日銀ネットなど中央銀行の処理システムは大規模なため、現時点でのブロックチェーンの応用は適さないとも指摘しています。
概要
日本銀行と欧州中央銀行は2016年12月に、金融市場インフラへのブロックチェーン技術（DLT）の応用可能性を調査するための共同調査プロジェクト「Project Stella」を立ち上げています。
日本銀行と欧州中央銀行はProject Stellaの第一段階として、それぞれの資金決済システムにおける既存機能の一部がブロックチェーンを用いた環境下で、効率的かつ安全に再現できるかどうかに関して、掘り下げた実証実験を行っています。具体的には、日本銀行と欧州中央銀行が運営する即時グロス決済（Real-Time Gross Settlement：RTGS）システムである「日銀ネット」及び「TARGET2」の流動性節約機能を、オープンソースとして利用可能なブロックチェーン基盤を用いて再現した上で、各種の実験をしました。Project Stellaにおける成果の発表は初めてで、今後も研究を続け、随時結果を発表すると述べています。
今回の調査における主な結果は以下の3点であると日銀は述べています。
- 今回のブロックチェーンに基づくシステムは、日銀ネットとTARGET2における平時及びピーク時と同等のトラフィック量に関して、現行のRTGSシステムとほぼ同等のパフォーマンスを得ることが確認された
- ネットワーク規模（ノード数）を増大させたり、ノード間の距離を拡大した場合に、処理時間の増大がみられた。さらに一部のノードが取引処理に参加しないといった傾向もみられた
- 検証ノード（台帳に記録される取引の共有・処理に責任を有するノード）における障害や、誤ったフォーマットで記載された取引指示といった課題に対処する可能性を持ち合わせており、システム全体のアベイラビリティ（可用性）が高い可能性を確認できた
実験環境
今回の実証実験におけるブロックチェーンでは、オープンソースのブロックチェーン基盤の一であるHyperledger Fabric（バージョン0.6.1）が使用されており、Fabric上で以下2つのスマートコントラクトを実装することで、実際に決済システムを想定しています。
- 取引指図における振替のみを実行する単純なスマートコントラクト
- 流動性節約機能（金融機関が日銀へ支払いをする際に資金不足であった場合に、即座に拒否せずに待機させて、新たな支払い指図などと組み合わせることで流動性を担保する機能）を実行するスマートコントラクト
ブロックチェーンの効率性
規模の影響
今回の実験では、取引検証作業に携わるノード数を増やしていった場合にパフォーマンスに与える影響を検証しています。単純なスマートコントラクトの結果によれば、検証ノード数と処理時間はトレードオフの関係にあり、ノード数が増加するとブロック上に記録されるまでの時間が長くなることが確認されています。またそれは流動性節約機能を実行するスマートコントラクトの結果でも同様の傾向が現れています。しかし、よく見ると4ノードから13ノードまではさほどパフォーマンスに差がないことから、ノードの台数においては最適な幅があるということがわかりました。
画像：日本銀行
ノード間の距離の影響
次に、一部のノードがその他のノードから離れた場所にある場合に、それがパフォーマンスにどのような影響を及ぼすかについて検証しています。総ノード数を4つとして以下2つの状況を想定しています。
- 4台のノードのうち3台が同じ場所に集中して残り1台が離れた場所にある「集中型シナリオ」
- 2つの離れた場所にそれぞれ2台のノードが位置する「拡散型シナリオ」
画像：日本銀行
実験結果をみると、集中型シナリオでは、ノード間の距離を変えても大きな影響はみられないことが分かった一方で、拡散型シナリオではノード間の距離が長い場合には、処理時間が増加することが明らかとなりました。つまり、合意形成に必要な数のノードが近接している場合では比較的短時間でコンセンサスに到達することに対して、遠距離に配置されているノードの同意がなければ合意形成できないような場合には、より時間がかかることが分かったこととなります。
しかし、4台数だけだと、ノード間の距離の検討としては十分と言えず、集中型シナリオにおいて数台の分散があるパターン、拡散型シナリオにおいて数台のクラスターが幾つかに別れいてるパターンにおける結果が重要になってきます。もし、今後引き続き実験が行われるのであれば、こういった観点での実験が期待されます。
ブロックチェーンの安全性
検証ノードの障害
ブロックチェーンの効率性追求する一方、中央銀行における決済システムでは、安全性も非常に重要視されます。
まずブロックチェーンにおいては、検証ノードの障害やネットワークの切断などにより、1台またが複数の検証ノードが合意形成に関与できなくなった場合、そのノードが復旧後にネットワークに再接続した上で、正常に機能している他のノードの台帳に合わせて自身の台帳を更新する必要があります。
今回の実験では、4台のノードのうち1台を、一定時間に渡って停止させた後、再起動させ、他のノードの台帳と同期しキャッチアップができるかという検証しています。結果として、合意形成に必要な数のノード（ノードが4台の場合には3台）が機能し続ける限り、1台のノードに障害が発生しても、システム全体の可用性（アベイラビリティ）は維持されることが確認されています。このグラフの斜めの線は、経過時間における確定したブロック数を表すものですが、ノードが止まっても、傾きを保っているため、ノードのダウンが全く影響をもたらしていないことがわかります。そして復旧時もその傾きが変わらないなため、他のノードに影響与えることなく復旧できていることもわかります。
従来のデータベースだと、復旧時は多くのデータ通信が発生するため、不可上昇が発生し、処理速度が落ちる傾向がありますが、それがないことがわかります。また、結果によると停止させた時間にかかわらず、普及には30秒以内に復旧したとあるため、かなり復旧能力は高いといえるでしょう。
画像：日本銀行
誤ったフォーマットの取引指図
次に、取引指図の一部が誤ったフォーマットで送られてきた場合に、その障害を乗り越える必要もあります。今回の実証実験では、そのような不正指図の占める割合を0%から80%まで増加させた時に、どのような影響を及ぼすかを検証しています。こうした不正指図は、ブロックチェーン基盤側ではなく、アプリケーション側のスマートコントラクト内で定義されたエラー検知機能で対処されます。実験結果によれば、システム全体としては不正指図の割合に関わらず、正しいフォーマットの取引指図を遅滞なく処理できることがわかっています。
秒間取引指図件数（RPS）を10件と100件に固定したシナリオの下では、不正指図の割合を徐々に増やしても、処理時間の中央値と最大値は、それぞれ0.5~1秒、1~1.3秒の間でほぼ横ばいで推移することが以下の図から分かります。
画像：日本銀行
最後に
ここまで見てきた結果をまとめると、ノード数やノード間の距離が増えるほど合意形成に時間がかかる一方で、ノードの切断や誤ったトランザクションフォーマットといった障害に対しては一定の効果があることが分かっており、ブロックチェーンの特徴が綺麗に現れていると考えられます。
また、今回の実証実験における報告書では最後に以下のように述べられています。
結論として、今次調査では、将来に向けて有益な結果が得られた。もっとも、検証結果は、あくまでも実験環境で行われたものであり、本番環境におけるDLTの実用可能性について評価するものではない点には留意が必要である。また、DLTは技術として十分成熟しておらず、現時点では、日銀ネットやTARGET2のような大規模なシステムへの応用には適さないと考えられる。
今回の実証実験は第一段階であることを考えると、ブロックチェーンの応用可能性が感じられる内容であったのではないでしょうか。その一方で、中央銀行が抱えるような非常に大規模な処理においては、処理件数やノードに関する制約・さらなる障害に対応できる耐障害性など、まだまだ検証の余地があり、本番環境を想定した実験環境での実用性を証明していく必要がありそうです。
また、今回はHyperledger Fbric 0.6.1を使用したとあり、現状の1.0とはだいぶ差分があります。例えばCA(認証局)に対する影響についてです。0.6ではCAを1つしか持つことができないため、単一障害点となると指摘がされています。しかし、1.0では認証局を複数持たせることができるようになったため、この懸念はすでに晴れております。
今後も最新のブロックチェーンはDLTを用いて、その可用性・可能性が実験されていくでしょう。そういった活動により、ブロックチェーンの更なる可能性が証明されていき、世界に広まっていくとおもうと、本当に面白いですね。
