はじめに
堅牢であることを求められるITシステムではバックアップセンターを用意して被災した際のデータ保護やサービス復旧の迅速化を行います。
一方でビットコインを代表としたブロックチェーン技術においては分散型であるため、被災時に従来のシステムとは違った動き方をします。
本記事では非ブロックチェーンと比較して、如何にブロックチェーン技術は被災に強いかを説明してみました。尚、本筋のブロックチェーンに関する知識は前提としているのでご容赦ください。
オススメ書籍
非ブロックチェーンでの送金
AさんがBさんの口座にお金を振り込むとします。
その場合、Aさんの口座を管理している銀行システムとBさんの口座を管理している銀行システムとで通信が行われます。また、災害やシステムエラーでデータが飛んでしまわないように、バックアップとして別拠点にミラーリングされている場合はその通信も発生します。
取引が発生したその瞬間に、Aさんの口座を管理している銀行システムがダウンしてしまうと仮定します。
そのような場合、直前に発生した取引のどこまでが反映されてどこまでは未反映としてデータを戻す必要があるのかはシステム設計に依存します。
これはRPO(Recovery Point Objective)と呼ばれる、システム障害発生時に過去のどの時点までデータを復旧させるかという目標値を要件とします。
このあたりはシビアで、Aさんの口座残高が減っていてBさんの口座残高が増えていない、という事態を避ける必要があるからです。
また、システムがダウンしてそれがバックアップセンターに切り替わるまではサービスが利用できません。
ブロックチェーンでの送金
一方、ブロックチェーンの場合はこのあたりの議論がかなり簡単になります。
実際にどのような動きになるのか、見てみます。
AさんがBさんに送金を行うとします。
この送金をブロックに取り込みチェーンに繋ぐことに誰かが成功すれば送金が成功です。
Aさんの取引は各ユーザにばらまかれ、それぞれが計算中のブロックに取り込みます。
例えば、そんな時に大規模な災害があり一部のクライアントの端末がダウンしたとしても無事だったクライアントがブロックの解を発表すれば問題なく成約します。
上の図ではXとZのシステムがダウンしてしまいましたが、動いているどれかの端末でブロックへの計算が続きます。
もちろん、クライアントが激減すれば取引成立までの時間は多めにかかってしまいますが、上で気にするような「Aさんの残高が減ってるのにBさんの残高が増えていない」という事は起こりえません。
データを戻すのか？という概念がそもそもなくて
- ブロックに書き込まれたデータは成約済み
- ブロックに書き込まれていないデータは成約できず
この原則で動き続けます。
このシステムダウンへの強さは、分散管理型台帳であるブロックチェーンの強みです。
終わりに
ブロックチェーンはデメリットもあります。
成約済みと思ったら別のブロックが伸びてくることで取引が消える可能性があったり、そもそも成約までの時間は誰も保障してくれません。
ただし、災害対策という観点で見ればシンプルな動きをするためとても扱いやすいです。
そんなことを考えながら思考を可視化してみました。ご参考になれば幸いです。