DLTネットワーク利用に関する論文の実証実験
検証した内容は以下の通りとなります。
・分散台帳基盤: Hyperledger Fabric™ v2.5.12
・コンテナ基盤: Docker 25.0.8１
・単一のEC2インスタンス上に **3つのHyperledger Fabric™ネットワーク** を構築。
・各ネットワークは、2つの組織から構成され、それぞれにPeerノードとCA（認証局）を持ち、さらにネットワークごとにOrdererノード
が1台存在し、デプロイ済みチェーンコードの実行用コンテナも含まれる。
・ネットワーク間は完全に分離されており、それぞれ独立して動作可能。
構築した環境において以下の処理を実施した
・各国に割り当てられたGDCC-Bの管理（GDCC-Bの発行、総量管理）
※各国国債の担保証明は無し。
・銀行間の送金処理の仕訳を台帳に記録し監査対応としてのログ管理（不可逆な決済履歴の保管）を確認
→ 中央銀行間（GDCC-B）の送金
→ 各国内銀行（中央銀行含む）の送金
| 証券保管振替機構によって実施されている想定業務 | 今回の実証結果 | |
| 業務 | 内容 | |
| デジタル通貨（GDCC-B）の発行 | 共通通貨建て債券をデジタル通貨（GDCC-B）として発行。受け取ったGDCC-Bと同額のW-GDCCBを負債側に発行 | 発行処理後のNorlandiaとVelgraviaのGDCC-Bと W-GDCCBの総量を記録 |
| 送金処理 ・中央銀行間のGDCC-Bの送金 |
①アプリ側で送金処理のログを作成 送金処理のたびに以下の情報をアプリで作成 ・送金元「中央銀行名」 ・GDCC-Bの送金量 ・誰（どの中央銀行）に |
|
| ②アプリ側の送金処理のログと送金元、送金先のGDCC-Bの総量（結果）を台帳に記録 | ①、②を監査対応ログとしてLedgerに記録することで不可逆な決済履歴を保管できることを証明 | |
| 送金処理 ・中央銀行から国内銀行へのW-GDCCの送金 ・国内銀行間のW-GDCCの送金 |
①アプリ側で送金処理のログを作成 送金処理のたびに以下の情報をアプリで作成 ・送金元銀行名 ・W-GDCCの送金量 ・送金先「銀行名」 |
|
| ②アプリ側の送金処理のログと送金元、送金先のW-GDCCの総量（結果）を台帳に記録 | ①、②を監査対応ログとしてLedgerに記録することで不可逆な決済履歴を保管できることを証明 | |
| 証券保管振替機構によって実施されている想定業務 | |
| 業務 | 内容 |
| デジタル通貨（GDCC-B）の発行 | 共通通貨建て債券をデジタル通貨（GDCC-B）として発行。受け取ったGDCC-Bと同額のW-GDCCBを負債側に発行 |
| 今回の実証結果 | |
| 発行処理の結果をLedgerに記録する | |
| 業務 | 内容 |
| 送金処理・中央銀行間のGDCC-Bの送金 | ①アプリ側で送金処理のログを作成 送金処理のたびに以下の情報をアプリで作成 ・送金元「中央銀行名」 ・GDCC-Bの送金量 ・誰（どの中央銀行）に |
| ②アプリ側の送金処理のログと送金元、送金先のGDCC-Bの総量（結果）を台帳に記録 | |
| 今回の実証結果 | |
| ①、②を監査対応ログとしてLedgerに記録することで不可逆な決済履歴を保管できることを証明 | |
| 業務 | 内容 |
| 送金処理 ・中央銀行から国内銀行へのW-GDCCの送金 ・国内銀行間のW-GDCCの送金 |
①アプリ側で送金処理のログを作成 送金処理のたびに以下の情報をアプリで作成 ・送金元銀行名 ・W-GDCCの送金量 ・送金先「銀行名」 |
| ②アプリ側の送金処理のログと送金元、送金先のW-GDCCの総量（結果）を台帳に記録 | |
| 今回の実証結果 | |
| ①、②を監査対応ログとしてLedgerに記録することで不可逆な決済履歴を保管できることを証明 | |
本検証では、技術的な実現可能性の検証を主目的として、1台のEC2インスタンス上に3つのHyperledger Fabric™ネットワークを構築した。これは本来の本番環境における構成とは異なり、可用性や耐障害性の観点では限定的であると考えており、本番環境を想定するのであれば、以下の点も含め検証配慮すべきと考えている。
・構成における課題
実証環境時における課題として以下の事項が挙げられる。
– ハードウェア障害発生時に全ネットワークが同時に停止するリスク
– 通信レイテンシのシミュレーションが困難（複数AZ間など）
– スケールアウト性や実際のクラスタ構成を模擬しづらい
上記の課題に関しては、今後以下の観点から検討が必要と考えている
Hyperledger Fabric™は分散台帳としての可用性や拡張性を重視した設計となっており、本来は複数の物理/仮想マシンにノードを分散配置することで、以下を実現すべきと考えている
– 障害時の切り替え（フェイルオーバー）
– 地理的な分散による耐災害性
– 負荷分散による高スループット対応
本実験ではDockerを用いて、1台のEC2インスタンス上に複数のネットワークを簡潔に再現し、柔軟かつ再現性の高い検証環境を実現した。今後はKubernetes®などによるクラスタ構成の検討も必要考えている。
文末脚注：
“Hyperledger Fabric™” は、米国およびその他の国における The Linux Foundation の商標です。
“Docker” は、米国およびその他の国における Docker, Inc. の登録商標または商標です。
“Amazon Web Services” および “AWS” は、米国およびその他の国における Amazon.com,Inc. またはその関連会社の登録商標または商標です。
“Kubernetes®” は、米国およびその他の国における The Linux Foundation の登録商標です。
お問い合わせフォーム