この記事はKyash Advent Calendar 2019の24日目の記事です。
こんにちは。株式会社KyashでCTOをしている椎野と申します。皆さんご存知の通り現在キャッシュレス市場は非常に盛り上がりを見せています。今年は各種Payサービスによるポイント還元や政府によるキャッシュレス還元などを通じてキャッシュレス決済に触れる方々が非常に多くなりました。
支払いにおいては各種Payサービスを通じて、その利便性を多く享受できるようになったと感じることが増えましたが、お金を送る送金では果たしてどうでしょうか？先日忘年会で会計で割り勘をする際に、友人はLINE Payをメインで使っていて、私はKyashアプリを使っていて、当然サービスを超えて送金ができないため、結局現金で集金して支払うという羽目になってしまったのですが、こういうことって結構あるかと思います。サービスの垣根を超えてお金を送り合うことができれば便利だなと常々考えています。
私たちKyashのビジョンはお金の移動にかかる様々なコストを下げ、スムーズに価値移動ができるインフラを作ることです。国やサービス・事業ドメインの垣根をなくして価値移動ができる世の中にしたいと願っています。
今回は、この垣根をどのようになくすことができるかをテクノロジーの観点で考察してみることにしました。
様々ある送金ネットワーク
送金ネットワークと一口に言っても様々な種類があります。長年利用されている銀行を介した送金で利用される銀行ネットワーク（全国銀行資金決済ネットワーク）、国際送金で世界最大のネットワークであるSWIFT（国際銀行間通信協会）ネットワーク、暗号通貨を利用した国際送金を実現するRipple、また各種Payサービスで提供している送金ネットワークなど、仕組みはそれぞれで大きく異なるものの、価値を移転するという点では表面上ではほぼ同じことが実現できています。ここではその仕組みを一つずつ見てみたいと思います。
全国銀行資金決済ネットワーク
全国銀行資金決済ネットワーク（全銀ネット）は主に国内の送金に利用されており、このネットワークに接続しているのは金融機関のみで、そのうち銀行、信用金庫、信用組合、労働金庫、農業協同組合に限られています。
実際この全銀ネットを利用した送金の流れを図にすると以下のようになります。
AさんからBさんに送金する際、表面上は実際の現金が送られているように見えますが、口座を持っている金融機関間で送られているのは電子信号によるメッセージのみです。実際の現金を取り扱っているのが日本では中央銀行である日本銀行であり、金融機関が日本銀行に開設している口座間で資金の移動を行なっています。なので物理的に資金の移動を金融機関同士で送り合うということはしません。私たちが各金融機関が送り合う電子信号を信頼することで送金が成り立っています。
国際間送金ネットワーク
国際間送金ネットワークは新旧、形態様々なものがあります。ここでは代表的なSWIFTネットワークとRippleネットワークを取り上げてみます。
SWIFTネットワーク
SWIFTネットワークは現時点において世界最大の送金ネットワークです。国内における送金と比較して時間や手数料はかかるものの、国外の金融機関口座を指定して送金が実現できている点では表面上では国内送金と変わりはありません。ただし裏側の資金の移動はやや複雑です。
国内送金との比較で大きく異なる点は、1. 世界をまたぐ中央銀行的な役割を果たす機関がない、2. 国によって通貨が異なるため必要な通貨を備蓄する必要があることです。上の図で流れを追うと、Aさんが国外のBさんに送金する際、Aさんの口座が開設されている金融機関から必要な通貨が備蓄されている123銀行（※注：コルレス銀行 (Correspondent Bank)：通常大手銀行がこの役割を担います）を介して、Bさんの国でコルレス銀行の役割を担う金融機関456銀行をさらに介してBさんの利用する銀行に送金メッセージが行われます。実際の資金の流れは、123銀行に開設されている456銀行の口座に123銀行が日本円で入金し、456銀行に開設されている123銀行の口座から456銀行が現地通貨で出金して、宛先であるBさんの利用する銀行に着金処理をすることで、実態としての送金は完了します。
Rippleネットワーク
アメリカのRipple社によって運営されているネットワークで、ネットワーク上で扱われているのは暗号通貨XRP（リップル）です。このXRPを通じて送金の仕組みが実現されています。暗号通貨を扱うという点でブロックチェーン技術を利用していると考えられがちですが、合意形成には独自のコンセンサスシステムを用いてビットコインの弱点でもあるスケーラビリティなどを克服する仕組みを用いて運用されています。
Rippleが前述のSWIFTと大きく異なるのは、従来の金融機関だけではなく、仮想通貨や電子ウォレットに紐づいた台帳（口座）もネットワークに接続できるような設計になっている部分で、この仕組みはInterledgerと呼ばれています。文字通り、XRPを通じて各種台帳を繋げることがコンセプトのコアな部分になっています。
Rippleはゲートウェイを介して、各台帳（口座、ウォレット）に対して送金メッセージを送ります。ゲートウェイでは、実際の通貨（法定通貨や暗号通貨など）とRippleネットワークで扱われるIOUという約束手形を相互に変換する入り口の役割を果たします。ゲートウェイではAさんの預かり金相当のIOUをAさんのRipple上のウォレットに入金し、AさんがそのIOUをBさんのウォレットにメッセージとして送信し、Bさんが受け取ったIOUをゲートウェイを介して返却することで、その価値と同等の通貨として出金することを可能とします。このIOUの取引における基軸通貨がXRPとなります。（厳密にはXRPそのものをウォレット間で送信するのではなく、XRPのIOUを送信します。）
各種Payサービスにおけるネットワーク
すでに世界中には様々な決済サービスが存在し、サービスによっては独自の送金ネットワークを有しています。日本においては、PayPay、LINE Payなど大手IT企業や、私たちKyashのようなFintechベンチャーが提供している決済・送金サービスなど複数存在しています。ネットワークの構築方法は各社で様々な形態を取っているかと思いますが、各社ネットワーク上の台帳を中央管理する仕組みは共通していると思われます。
AさんからBさんに送金する場合、銀行口座やクレジットカードなどで日本円で保有ウォレットに入金し、台帳上では入金額に相当するバリューとして保持されます。Aさんはそのバリューを電子信号メッセージによってBさんのウォレットにバリューが移転されます。前述の全銀ネットと同じく、台帳上で資産の移転を行い、実物資産はそれが現実に利用される時動くという仕組みであることが多いかと思います。
現状の課題
ここまで見てきたように、すでに様々な送金ネットワークが存在し、送金に対する手間やコストが徐々に下がってきています。SWIFTやRipple、各種Payサービスの出現は、その出現前までの送金の様々な不都合を解消するために生まれてきた仕組みでもあります。しかし自由で手軽な送金を実現するにはそれでもまだ課題は多いと考えています。
主には以下のような課題が挙げられます。
1. コストが高い
現状、口座間の送金には手数料がかかり、特に銀行を介した送金の手数料が高いことが挙げられます。
2. 手数料が不明瞭
これは1のコストが高いと関連しますが、特に国際間送金の場合は、複数の金融機関を介して送金されるので、介在した金融機関の数や料率によって、手数料が複雑化しています。（Rippleはそこを解消する強力なソリューションでもあります。）
3. 送金がネットワーク内に限定されている
冒頭で述べた通り、ネットワークが異なると送金ができない、もしくは手動のオペレーション（取引所での換金など）を通じないと送金ができないことによりまだ現金が介在してしまうことがあります。
4. 良くも悪くも中央集権的
銀行を中心とした従来型の金融機関やFintechサービスを展開している事業者とで提供形態は異なるものの限られた数の機関・事業者が展開していることもあり、競争の原理が働きづらいことも挙げられます。（私もFintechサービス提供者側なので同じ括りになるのですが、私たちKyashを始めほとんどのFintechサービス提供者は送金無料としていると思われます。）
課題に対するアプローチ
送金は、現在までに発展してきた金融市場の性質、犯罪への対策の経緯など、その実現をより簡便にするために様々な施策が入り乱れている結果として仕組みが複雑であると考えられます。これまで取り上げたネットワークの形態も、少しでも利便性の高い送金を目指して作られてきています。銀の弾丸的な完璧な解決方法を瞬時に世の中に提供するのは難しいものの、ここでは飛躍気味ではありますが、アプローチを考えてみたいと思います。
ここではより柔軟性の高い送金ネットワークを考える上で以下のことを検討をしてみることにします。
1. 部分的に非中央集権化したネットワーク
1つの金融機関、事業者が全てをコントロールするのではなく、共同でネットワークを運営する方式にすることで独占的状態を作らないようにする。このようにすることで利用の高コスト化を防ぐ。（コンソーシアム型）
2. 1を達成する手段としてブロックチェーンを用いてみる
部分的な非中央集権ネットワークを実現するためにブロックチェーン技術の利用を検討することにします。すでに世の中にはブロックチェーン利用のメリット（及びデメリット）の情報は広く浸透してきているかと思いますが、非中央主権的なシステム構築が可能・非改竄性などは良く知られているところではあります。それに加え現在ブロックチェーンの標準化が進められていて、その実装が進むとブロックチェーンプラットフォームに相互に乗り入れることができる状態の**Interoperability（インターオペラビリティ）**が実現され、閉じられたネットワーク同士の送金の実現可能性をあげることができると考えています。
これからのブロックチェーンの特徴として期待されるインターオペラビリティ
ブロックチェーンの詳しい特徴は専門の書籍やサイトに譲るとし、今後普及が期待されるブロックチェーンネットワーク同士の相互乗り入れ**Interoperability（インターオペラビリティ）**に関して記載したいと思います。
従来異なるプラットフォーム同士が相互接続して情報のやりとりを行うには、お互いが提供しているAPIに対して相互にアクセスしあう必要があります。ただし、大抵の場合お互いのAPIを各トランザクション処理ごとに綺麗にハマるように整理、調整が必要となります。
このずれを修正するのに作業が発生し、少なくとも時間もかかります。これをインターオペラビリティを利用することで、開発なしでブロックチェーン同士が相互に接続されるような状態を作り出すことができます。
ただし、現状実運用されているインターオペラビリティを備えたブロックチェーンはあまりなく、存在はするものの、例えばイーサリアムとビットコイン間での相互乗り入れなど真の意味で実現できているものはまだ世の中には登場していません。
インターオペラビリティの実現を目指すCosmos
ブロックチェーン規格標準化は世界で進められていますが、今回はそのうちの一つCosmosを取り上げてみたいと思います。Cosmosはこのインターオペラビリティの実現を目指すブロックチェーンで、以下の図のようにHub（Hubもまたブロックチェーン）を中心に各ブロックチェーン（Zone）を繋いでゆくことができるようです。このHubはCosmos Hubと呼ばれています。
画像引用：A Deep Look Into Cosmos — the Internet of Blockchains
Cosmosの特徴
CosmosのWebサイト上ではブロックチェーンを扱う上で以下の3つの課題があるとされ、Cosmosはそれらを解決する手段を提供しています。
1. Scalability：拡張性
既存のブロックチェーンの合意形成手法であるProof-of-Workだと非常に時間がかかる上に拡張性が乏しい課題。
2. Usability：利便性
ブロックチェーンを利用したアプリケーションは複雑で、理解して開発を行うには難易度が高いという課題。
3. Interoperability：相互運用性
前述の通り、ブロックチェーンネットワークをまたがって価値の移転を行うことができない課題。
この３点をCosmosは彼らの独自のソリューションで解決しようとしています。Cosmosでは開発するアプリケーション固有のブロックチェーンを比較的用意に開発することができるよう独自のブロックチェーンフレームワークを提供しています。また合意形成処理にはTendermintを利用し、Proof-of-Stakeを合意形成手段としているため短い時間で処理できるようになっています。これによって作られたブロックチェーンはCosmosのネットワーク内で相互に価値移動が可能になり、これまでは中央の取引所を経由すること以外で異なるブロックチェーン間で価値移動できませんでしたが、Cosmosによってこれが可能になる仕組みになっています。
Cosmosに触れてみる
Cosmosは他のメジャーなブロックチェーンプラットフォーム（イーサリアムやHyperledger Fabricなど）のようにミドルウェア的なものをサーバーにインストールして使うのではなく、Cosmosが用意しているSDK（Cosmos SDK）を自身が開発するアプリケーション内に取り込むことでブロックチェーンの作成やインターオペラビリティなどを実現できるようになっています。
Cosmos SDKとは
アプリケーション固有のブロックチェーンをわずかな工数で作ることができるSDKであり、公式の説明によるとわずか3ステップでブロックチェーンの作成から他のCosmos SDKを利用して作られた他のブロックチェーンに接続ができるようになるようです。このSDKを利用して作られたブロックチェーンネットワークやウォレットがすでに多数ローンチしています。ここでは送金という文脈でCosmosを紹介していますが、この他にもビデオストリーミング、ヘルスケア、不動産などのユースケースの紹介も公式Webサイトにはあります。
チュートリアルを試してみる
ここではCosmosを手軽に体験するためにチュートリアル用のアプリケーションを使ってその動作をいくつか確認してみます。
チュートリアルで使うアプリケーションの内容
チュートリアルで利用するサンプルアプリケーションであるhellochainにはすでにCosmos SDKが組み込まれています。簡易な銀行のアプリケーションであり、Cosmosのブロックチェーンを通じて送金を行うことができます。
事前準備
Cosmos SDKを利用するにはGO言語の環境が必要になります。（2019年12月20日時点）
- golang > 1.13.0
アプリケーションファイル構成
チュートリアルで利用するサンプルアプリケーションのファイル構成は以下のようになっています。
./hellochain
├── go.mod
├── Makefile
├── starter
├── app.go
├── cmd
│ ├── hccli
│ │ └── main.go
│ └── hcd
│ └── main.go
└── x
└── greeter
├── client
│ ├── cli
│ │ ├── query.go
│ │ └── tx.go
├── internal
├── types
| ├── msgs.go
| └── types.go
├─ keeper
└── querier.go
├── keeper.go
├── alias.go
├── module.go
├── handler.go
starterがCosmos SDKの主要なモジュールであるbank、auth、param、supply、genaccountなどのファンクションをラッピングしており、このstarterがほとんどのブロックチェーンにまつわる処理を引き受けている構成になっています。
ベースのデーモンを動かす
cmd/hcd/main.goを実行しデーモンとして動作させます。
$ go run main.go
hellochain AppDaemonと出たらデーモン動作が完了したことになります。
Makefileの準備とインストール
サンプルアプリケーションを操作させるために必要なモジュールのインストールをします。以下のMakefileを用意します。
VERSION := $(shell echo $(shell git describe --tags) | sed 's/^v//')
COMMIT := $(shell git log -1 --format='%H')
ldflags = -X github.com/cosmos/cosmos-sdk/version.Name=HelloChain \
-X github.com/cosmos/cosmos-sdk/version.ServerName=hcd \
-X github.com/cosmos/cosmos-sdk/version.ClientName=hccli \
-X github.com/cosmos/cosmos-sdk/version.Version=$(VERSION) \
-X github.com/cosmos/cosmos-sdk/version.Commit=$(COMMIT)
BUILD_FLAGS := -ldflags '$(ldflags)'
all: install
install: go.sum
go install $(BUILD_FLAGS) ./cmd/hcd
go.sum: go.mod
@echo "--> Ensure dependencies have not been modified"
go mod verify
Makefileの準備が終わったらインストールを行います。
$ make install
$ go mod verify
all modules verified
$ go install -tags "" ./cmd/hcd
動きを試してみる
コマンド動作確認
必要モジュールのインストールが終わりましたら、ブロックチェーンノードとデータ操作をする以下の2つのコマンドが動作できるようになっているか確認します。
$ hcd
$ hccli
コマンドをうってUsageが表示されれば動作していることになります。
ブロックチェーンノードの初期化
ブロックチェーンノードの初期化を行います。ここではノード名をhellochainとします。
$ hcd init hellochain
{"app_message":{"accounts":[],"auth":{"params":{"max_memo_characters":"256","sig_verify_cost_ed25519":"590","sig_verify_cost_secp256k1":"1000","tx_sig_limit":"7","tx_size_cost_per_byte":"10"}},"bank":{"send_enabled":true},"params":null,"supply":{"supply":[]}},"chain_id":"test-chain-PFEP40","gentxs_dir":"","moniker":"hellochain","node_id":"b41ea20aeb9d46ff83df9376a35daf75e09f4d80"}
Genesisブロックを作る
一般的にブロックチェーンの最初のブロックのことをGenesisブロックと呼び、本サンプルアプリケーションのブロックチェーンのGenesisブロックを作ります。ここではaliceとbobのアカウント作成とそれぞれに残高を付与します。
最初にアカウント作成を行います。
$ hccli keys add alice
# パスフレーズ入力を促すダイアログが表示されます
# パスフレーズを８文字以上で設定
# 仮に"12345678"を設定
- name: alice
type: local
address: cosmos1hg79murl2wwfr5lw642kapcdje4njfc0mnrdrp
pubkey: cosmospub1addwnpepqwdykxwhlvk7tpmy38eer5rzr6gva30fm2k4hnsr89ljdcm74838ue72rjv
mnemonic: ""
threshold: 0
pubkeys: []
$ hccli keys add bob
# パスフレーズ入力を促すダイアログが表示されます
# パスフレーズを８文字以上で設定
# 仮に87654321を設定
- name: bob
type: local
address: cosmos1tm4qyxvyfnrxnlnl7lgespvajlfmcyyw5efy4n
pubkey: cosmospub1addwnpepqd2cezar5nxmdcfksd5yqvmk9pwv2h28tjpvf3s7wc5dyqfdnfvz6xhmkxc
mnemonic: ""
threshold: 0
pubkeys: []
aliceとbobのアカウントが生成されました。aliceのアドレスはcosmos1hg79murl2wwfr5lw642kapcdje4njfc0mnrdrp、bobのアドレスはcosmos1tm4qyxvyfnrxnlnl7lgespvajlfmcyyw5efy4nとなりました。残高付与や送金はこのアドレスに対して行われます。
続いて生成されたアカウントに対して最初の残高を付与します。ここでは2つの暗号資産stakeとhelloをそれぞれ付与しています。以降のサンプルではhello資産を使って送金デモを行います。
# aliceに残高を付与する
$ hcd add-genesis-account $(hccli keys show alice -a) 100000000000stake,100hello
# bobに残高を付与する
$ hcd add-genesis-account $(hccli keys show bob -a) 100000000000stake,1000hello
aliceに100helloとbobに1000helloを付与しました。
ブロックチェーンノードのスタート
次にブロックチェーンのノードをスタートします
$ hcd start
# 動き出すと以下のトランザクションログが表示されます。
I[2019-12-21|12:04:46.817] starting ABCI with Tendermint module=main
I[2019-12-21|12:04:52.201] Executed block module=state height=1 validTxs=0 invalidTxs=0
I[2019-12-21|12:04:52.217] Committed state module=state height=1 txs=0 appHash=560DEE5BE6355A9E56789B8F3104CEB61DCE2A80FA4D60A137EFB33B8BDC0839
I[2019-12-21|12:04:57.279] Executed block module=state height=2 validTxs=0 invalidTxs=0
I[2019-12-21|12:04:57.293] Committed state module=state height=2 txs=0 appHash=560DEE5BE6355A9E56789B8F3104CEB61DCE2A80FA4D60A137EFB33B8BDC0839
I[2019-12-21|12:05:02.349] Executed block module=state height=3 validTxs=0 invalidTxs=0
I[2019-12-21|12:05:02.365] Committed state module=state height=3 txs=0 appHash=560DEE5BE6355A9E56789B8F3104CEB61DCE2A80FA4D60A137EFB33B8BDC0839
I[2019-12-21|12:05:07.418] Executed block module=state height=4 validTxs=0 invalidTxs=0
I[2019-12-21|12:05:07.433] Committed state module=state height=4 txs=0 appHash=560DEE5BE6355A9E56789B8F3104CEB61DCE2A80FA4D60A137EFB33B8BDC0839
別のウィンドウでステイタスを確認してみます。
$ hccli status
{"node_info":{"protocol_version":{"p2p":"7","block":"10","app":"0"},"id":"b41ea20aeb9d46ff83df9376a35daf75e09f4d80","listen_addr":"tcp://0.0.0.0:26656","network":"test-chain-PFEP40","version":"0.32.6","channels":"4020212223303800","moniker":"hellochain","other":{"tx_index":"on","rpc_address":"tcp://127.0.0.1:26657"}},"sync_info":{"latest_block_hash":"927E274BFFCF83D4CE851176C9891243C4A6E0BE958DF072261EEE9C7904D05E","latest_app_hash":"560DEE5BE6355A9E56789B8F3104CEB61DCE2A80FA4D60A137EFB33B8BDC0839","latest_block_height":"196","latest_block_time":"2019-12-21T03:22:34.303096Z","catching_up":false},"validator_info":{"address":"F98F075D6A43F88403639B1CCE90E8DF7CFCAE92","pub_key":{"type":"tendermint/PubKeyEd25519","value":"Ihk/e+pA0h3/mmF/NHRHxEPoGJu4+DxmxtRqD6cAByg="},"voting_power":"100"}}
ノードIDがb41ea20aeb9d46ff83df9376a35daf75e09f4d80、チェーンIDがtest-chain-PFEP40で動作していることが分かります。※trust-nodeがfalseで動作している場合はチェーンIDを指定して以降の操作を行います。デフォルトではfalseになっているものと思われます。
次に先ほど登録した残高を確認してみます。
# aliceの残高
$ hccli query --chain-id=test-chain-PFEP40 account $(hccli keys show alice -a)
address: cosmos1hg79murl2wwfr5lw642kapcdje4njfc0mnrdrp
coins:
- denom: hello
amount: "100"
- denom: stake
amount: "100000000000"
pubkey: ""
accountnumber: 0
sequence: 0
# bobの残高
$ hccli query --chain-id=test-chain-PFEP40 account $(hccli keys show bob -a)
address: cosmos1tm4qyxvyfnrxnlnl7lgespvajlfmcyyw5efy4n
coins:
- denom: hello
amount: "1000"
- denom: stake
amount: "100000000000"
pubkey: ""
accountnumber: 1
sequence: 0
先ほど登録したaliceの残高100helloとbobの残高1000helloが表示されます。ちなみに処理対象のアカウントを指定する場合、アドレスを指定する必要があります。このサンプルでは$()でアカウントのアドレスを指定しています。
送金を試してみる
次にaliceからbobに50helloを送金してみます。
$ hccli tx --chain-id=test-chain-PFEP40 send $(hccli keys show alice -a) $(hccli keys show bob -a) 50hello
# 確定予定のトランザクションが表示されます。（この段階では確定していません。）
{"chain_id":"test-chain-PFEP40","account_number":"0","sequence":"0","fee":{"amount":[],"gas":"200000"},"msgs":[{"type":"cosmos-sdk/MsgSend","value":{"from_address":"cosmos1hg79murl2wwfr5lw642kapcdje4njfc0mnrdrp","to_address":"cosmos1tm4qyxvyfnrxnlnl7lgespvajlfmcyyw5efy4n","amount":[{"denom":"hello","amount":"50"}]}}],"memo":""}
# 確定するには送信元であるaliceのパスフレーズを入力します
confirm transaction before signing and broadcasting [y/N]: y
Password to sign with 'alice':※aliceのパスフレーズ
# 確定すると以下のようなログが表示されます
height: 0
txhash: CD6BBCA5B4B8E7C7B646FD7F7CED6369B92761431FE19C074809A5E9236956E5
code: 0
data: ""
rawlog: '[{"msg_index":0,"success":true,"log":"","events":[{"type":"message","attributes":[{"key":"action","value":"send"}]}]}]'
logs:
- msgindex: 0
success: true
log: ""
events:
- type: message
attributes:
- key: action
value: send
info: ""
gaswanted: 0
gasused: 0
codespace: ""
tx: null
timestamp: ""
events: []
successがtrueとなっているので送金が成功したことになります。
最後にaliceのhello残高が50、bobのhello残高が1050になっているのを確認します。
# aliceの残高
$ hccli query --chain-id=test-chain-PFEP40 account $(hccli keys show alice -a)
coins:
- denom: hello
amount: "50"
# bobの残高
hccli query --chain-id=test-chain-PFEP40 account $(hccli keys show bob -a)
coins:
- denom: hello
amount: "1050"
alice、bob共に正しい数字になっていることが確認できました。
サンプルアプリケーションを通じてCosmosに触れてみての感想
2019年12月時点においてまだインターネット上に情報が多く出回っておらず、正常に動作するのか多少不安はありましたが、無事動作確認することができました。今回はサンプルアプリケーションを軽く触ってみた程度なので、まだCosmosの真髄に触れられたわけではないのですが、自分で開発しているアプリケーションに組み込むのは非常に簡単であろうことは理解できました。
Cosmos SDKを利用したブロックチェーンネットワーク同士をつなぐCosmos Hubは今後様々なブロックチェーンネットワークと接続が可能になってゆくものだと思います。現在のCosmos Hubは最初の1つ目のHubとして存在しており、これからビットコインやイーサリアムなどの接続をも可能にする新しいHubが誕生することも期待ができます。
実態としての送金処理の課題
システム間の実態としての送金
Cosmosのようなインターオペラビリティを備えたブロックチェーンを利用することで、ユーザーの視点からは送金がシームレスにできるようになるであろうということは分かってきました。ただし、実際の送金はこの仕組みだけでは行うことができません。前述の様々ある送金ネットワークで３種類ほどネットワークフローの説明をしました。その中でシステム間を行き来しているのは、送金を表す電子信号のメッセージです。この電子信号メッセージを信頼することでシステム間の送金は成立しています。そしてその信頼がベースとしているのは送金元と送金先の間で実際の資金が確実に移動する（送金元と送金先が口座を持つ全銀ネットに接続された金融機関間で資金移動が行われる）ことにあります。
日本国内において実際の資金移動を伴うシステム間の送金を行うには全銀ネットに接続されている必要があり、それを実現できているのは銀行などの限られた金融機関のみとなります。では、ブロックチェーンなど直接全銀ネットにつながっていないネットワークではどうすれば良いかということになります。
課題解決するには
ここまで書いておきながらなのですが、現状を鑑みると、新たなネットワークに銀行などの金融機関の参加が必要だったり、あるいは代理で各金融機関へ振り込み処理を行うなど中央にプールしたりする仕組みが必要だったりします。なのでネットワークを構築する技術だけが最新化されても、裏側の実態としての資金の移動処理は変わることはありません。
- 銀行などの金融機関がネットワークに参加する場合
- 中央に資金プールをする場合
課題は残しつつも、ユーザー視点で考えるとブロックチェーンのインターオペラビリティを通じてネットワークをまたがって送金できる世界が実現できると様々なライフシーンで利便性が劇的に上がるものと思われます。
最後に
ここまで書かれた内容はまだ知識習得中のものもあり、ロジックとして完成されたものではありません。チャレンジとして今の送金の仕組みをもっと便利にできたらという思いもあり新しい送金ネットワークの考察を行いました。今回はネットワーク構築のテクノロジーとしてインターオペラビリティの性質を有するブロックチェーンを検討してみました。ブロックチェーンはまだまだこれから発達してゆく技術であり、インターオペラビリティを実現する上での標準化策定活動も活発になっています。
今年の夏はFacebookが主導する**リブラ(Libra)が世間から大きく注目されました。背後にFacebookというグローバルな巨大企業の存在があることに対し各国の金融施策を統制する機関が猛反発した（現在もしている）のは記憶に新しいことではあります。実際はFacebookとは切り離してリブラ協会(Libra Association)**として推進することで企業色を薄めようとしたものの実態としては変わらないという指摘もあり、現時点で今後どのように推移してゆくのかはまだ未知数です。
Libraは様々な指摘を受けて、推進が鈍化しているように見えますが、このような新しい金融のネットワークは今後現実的に立ち上がってくるものと思います。冒頭の方でも述べた通り、ここまでに誕生してきた様々な金融にまつわるネットワークはそれまでの課題を解消するために時代と共に進化してきました。Libraが今後どのように進んでゆくのかも注目していますが、今後期待したいのは、国や企業の色がない（もしくはほぼない）White Label（ホワイトレーベル）なインフラ・ネットワークの誕生です。理想論ではありますが、ネットワークに参加している人や団体が平等にその参加利益を享受できるネットワークが作られたら良いと思っています。ブロックチェーンと将来期待されるインターオペラビリティは囲い込まない、もしくは囲い込まれたところも繋がることができる世界を実現するために生まれてきていると考えています。これからもこの界隈の動向へのキャッチアップを続け、機会があれば別記事をまた書いてみようと思います。
さらに最後に
弊社Kyashの開発ノウハウをWEB+DB PRESS Vol.114で取り上げていただきました。なかなか目に触れることがないカード決済を処理するシステム・ネットワークの話が満載ですので、ご興味ある方はぜひこの機会に！
