エンジニアがブロックチェーンを学ぶべき3つの理由

# ブロックチェーン技術とは
誤解を恐れず言うと、ブロックチェーンとは改ざん不可能なデータベースである。
ある地点で承認された情報の塊（ブロック）を、ネットワーク参加者が連鎖（チェーン）的に積み上げていく事で、過去のデータは書き換え不可能に収束していく。
ブロックチェーン技術はかなり前から注目されている技術であるが、仮想通貨での利用例ばかりが取り上げられ、「自分には関係のない世界の技術」と一線を引いている人も多いのではないだろうか。
この記事では、なぜエンジニアがブロックチェーン技術を学ぶ必要があるか、その有益性に関する情報を整理する。

# なぜ有益なのか
## 1. コピーではなく、真のデータを参照可能
異なるシステム間で情報連携を行う場合、これまでは「ファイル連携」と言う手段が好まれてきた。
より正確には、ファイル連携以外の選択肢がなかった。
特に、一度に連携する情報量が多い場合や、送信先のシステムがメンテナンス等で停止することが考えられる場合、REST APIは選択肢から外れてくる。MQという選択肢もあるが、たかが情報を連携するだけなのに、ミドルウェアを自前で準備して可用性を担保する仕組みまで用意するには少し面倒だ。ファイル連携の場合、「つくって、置く」と言うシンプルな構造であるがゆえ、面倒なことを考える必要がなかった。

しかし、実行処理自体がシンプルになっても、準備と確認の作業はどうしても必要になる。まず、配置先のファイルサーバ（SFTPサーバ）を準備してSFTPユーザを作成する必要がある。次に、通信要件に沿って、特定の送信元からのみアクセスを受け付けるように整理する必要がある。また、ファイル連携された情報そのものが間違っている可能性もあるため、定期的にリコンサイル処理を行わなければならない。連携されたファイルがサーバに溜まり続けないような仕組化も必須要件になってくる。

ブロックチェーンはこの問題をシンプルに解決する。A社とB社の異なるシステムは同じデータを参照しているため、それが間違っている可能性を考慮する必要はない。ブロックチェーン基盤さえあれば、SFTPユーザを用意して接続テストを行う必要もない。ファイルが生成されて保管場所を考慮する必要もない。ブロックチェーン上で更新された情報を参照するだけで良い。

## 2. 一貫性が保証される
AシステムからBシステムへ法定通貨を移動するとき、Aシステムではマイナスのキャッシュフロー、Bシステムではプラスのキャッシュフローが発生する。この時問題になるのが、Aシステムではマイナスのキャッシュフローが発生したが、Bシステムではシステム障害によりキャッシュフローが発生しなかった場合である。仮に同システム内で処理が行われる場合は、2つの処理を1トランザクションにまとめることで、ロールバックにより一貫性が保証される。しかし、全く異なるシステム間でトランザクションを保証することは難しい。仮に何かしらの理由で処理が失敗する場合に備え、アラートログの仕込みやリコンサイル処理を行い、気付いたベースでシステムメンテナンス回避といった方法を取るしかなかった。

仮想通貨を交換する場合も同様の問題が発生する。1BTCと10ETHを交換するとき、Aさんが1BTCを送金するのと、Bさんが10ETHを送金するのはどちらが先かで揉めることは想像に難くない。どちらか一方が裏切る可能性があるからである。
仮にBさんが悪徳業者である場合、Aさんが1BTCを送っても、Bさんから送られるはずの10ETHはいつまでたっても届かない。見ず知らずのインターネット上の取引相手である場合、AさんはBさんから永久に10ETHを徴収することができないだろう。

ブロックチェーンではスマートコントラクトという技術によりこの問題を解決する。スマートコントラクトとは、プログラムが自動的に実行される仕組みである。ブロックチェーン上にこのプログラムを埋め込むことにより、あらかじめ定義された処理が「必ず」実行される。仮想通貨を交換する例では、AさんからBさんへ資金が移動した場合、BさんはAさんに対して資金を移動するというプログラムを事前に埋め込んで置くことで、取りはぐれのリスクがゼロになる。

## 3.コストの大幅削減
1.で述べたように、ファイル連携からブロックチェーン管理に移行することで、SFTPサーバの管理を排除し、ファイル自体も管理不要となる。このような「手段」として必要だったものがブロックチェーンにより駆逐されていく。

もう少し話を広げると、誰かが管理してきた中央的管理者も不要になっていく。
これまで信頼とは、誰かが認めた証明書を拠り所にしてきた。例えば、銀行に100万円を預けた場合、銀行が「あなたは100万円を私たちに預けています」という証明書を提示することで事実が担保されてきた。仮に銀行が「あなたは20万円しか預けていません」と言った場合、事実とは無関係に20万円しかないことになる。

ブロックチェーンはこの銀行の役割を自律的に代替する。Aさんが100万円保有していることは改ざん不可能な形でブロックチェーン上に記録され、恣意的な誰かの操作によって変更されることはない。生態系維持のためにこれまで誰かが負担していた中央管理コストは分散技術によって置き換わろうとしている。

# ブロックチェーンと分散型台帳技術の違い
ブロックチェーンと似た言葉に「分散型台帳技術(DLT)」というものがあるので補足しておきたい。
ブロックチェーンと分散型台帳技術はイコールではなく、含有関係にある。分散型台帳技術(DLT)の1つにブロックチェーンというものがあり、BitcoinやEthereumがこれにあたる。一方、Rippleや下記で述べるCordaは、ブロックチェーンではないものの分散型台帳技術(DLT)というカテゴリーに属する。
この記事では、世の中一般的に浸透している「ブロックチェーン」という言葉で紹介してきたが、より正確なタイトルは「エンジニアがDLTを学ぶ3つの理由」ということになる。

# Cordaという1つの解
金融機関のような機密情報を扱うシステムにおいて、全ての情報が公開されているブロックチェーンはプライバシーの問題に抵触する可能性がある。
また、古くから利用されているレガシーなシステムの場合、古い技術に強依存していて新しい技術を取り入れることが難しい場合もあるかもしれない。
部分的にDLTへ代替可能な処理があったとしても、全体最適としてわざわざブロックチェーンを取り入れるべきなのかは疑問が残るのも不思議ではない。

Cordaは最も規制の厳しい金融業界向けに分散型台帳技術を適用したオープンソースプラットフォームである。以下3つが大きな特徴として上げられる。

## 1. 当事者間のみで取引が完結する
ブロックチェーンでは一般的に、全ての参加者が全ての取引を確認することができる。言い換えれば、取引内容は全世界に公開され、プライバシーを守ることは事実上不可能となっている。Cordaでは、このパブリックなブロックチェーンの上にプライベートなネットワークを作ることができ、「知る必要のある」範囲で情報共有を可能としている。

## 2.既存のシステムとの親和性
CordaはJVM上で動くため、Java(Kotlin)で実装することが可能となっている。金融機関や大規模システムでは、Javaで作成されているものが数多く存在しており、世界に700万人いるといわれるJavaユーザにとっては参入障壁が小さいだろう。EthereumはSolidityという専用の言語を使用しなければならず、Ethereumを利用するためだけにSolidityを学ぶのは...という理由で避けてきた人も多いはずだ。また、データの永続化に既存のRDBMSを利用することができ、従来のシステムとの親和性を意識したアーキテクチャとなっている。

## 3.実績と協賛パートナーが多い
Cordaは既に70以上のパートナー企業と提携して実証実験を行ってきている。日本ではNTTデータやSBI、海外ではアクセンチュアやMicrosoft、Amazonなどの巨大企業も数多く参加している。既に実証実験段階を終えたという記事もあり、いよいよ本格的に利用され始めるだろう。

# DLTの発展と今後
Bitcoinのホワイトペーパーが2008年に公開されてから約10年が経った今、DLTは金融業界のみならずあらゆるシステムで利用され始めている。Corda以外にも特徴的なDLTは数多く存在し、その発展スピードは今後も加速していくだろう。DLTを人ごとにせず、時代の流れに置いて行かれないよう日々キャッチアップしていくことが、DLT時代を生きるエンジニアにとって必須スキルとなっている。