ブロックチェーンのインサイト(ド)

https://www.bot.or.th/English/FinancialMarkets/ProjectInthanon/Documents/20210308_CBDC.pdf

• BOT（タイ中銀）、SCG（サイアム・セメント・グループ）、DV（デジタル・ベンチャーズ）が実施したCBDC実証実験プロジェクト
• 法人向けビジネスアプリ（B2P）と組み合わせてCBDCを使うことで、どのようなメリットがあるかを検証。
• BOTが元々やっていたProject Inthanonでは銀行間決済にフォーカスしていた。今回は、企業向けの支払に視点を向ける
• プロトタイプはHyperledger Besuを使用、ConsenSysが開発をサポート
• 求められた4つの機能要件
  1. CBDCライフサイクルマネジメント…発行、償還、配信、支払
  2. B2Pの統合
  3. インボイスのトークン化
  4. プログラマブル・マネー
• 6つの非機能要件
  1. ファイナリティー
  2. インターオペラビリティー
  3. プライバシー
  4. レジリエンシー
  5. スケーラビリティー
  6. セキュリティー

• アーキテクチャーは2階層システム
  • 1階層目はCBDCシステムで、中央銀行の役割。発行、口座管理、トランザクション検証等
  • 2階層目は仲介者向け。CBDCの配信、顧客接点業務（KYC等）
  • 企業はCBDCウォレットを持つ

• コアレイヤーは二つの階層からなる
  1. ブロックチェーンレイヤーとスマートコントラクトレイヤー
• その他、APIレイヤーとアプリケーションレイヤーがある

• CBDCアプリケーション
  • 現状、企業間決済は、銀行を通じてバッチで実行される。そのため次の課題がある
    • 企業は銀行にカットオフタイムまでに支払指示を投げる必要がある。これは実際の決済日よりも数営業日前である。
    • トランザクションの追跡性が低い。仕向、非仕向共にトランザクションのステータスを把握することが出来ず、日次のキャッシュマネジメントが困難
    • 企業は通常、複数の銀行との付き合いがあり、業務が煩雑。複数の異なる銀行のフォーマットに合わせて、支払指示をしなければならない
  • CBDCでピア・ツー・ピア、リアルタイムにやり取りすることで解決
  • ただし、企業はCBDCウォレットを持つ必要があり、その結果、預金として持った場合の金利収入を諦めなければならない。
  • CBDCは既存の銀行預金や支払サービスと並んで新たな決済手段となる。

• サプライチェーンファイナンスとインボイスのトークン化
  • B2Pプラットフォーム上で、サプライヤーはインボイスを担保に資金貸し手にファイナンス依頼ができる。
  • ただし一つ制約があり、現状B2Pでは限られた貸し手にしかオープンにしていない。その結果、サプライヤーは最安レートでのファンディングにアクセスできていない
  • 今回のアプリだと、サプライヤーのインボイス情報は公開されてしまう
    • どの貸し手もインボイス情報を参照することができる
  • 貸し手はインボイスの全金額を買うこともできるし、その一部でも良い。
  • インボイスのトークン化は、様々な資金の貸し手にとって魅力的である

• プログラマブル・マネー
  • 企業にとって、支店での資金管理は、面倒な内部手続きが必要となるので、長年課題となっている。
  • 通常、マニュアル作業でのキャッシュの受取、支払、残高が求められる
  • CBDCのプログラマブル・マネーを使うことで次のことが可能
    1. 企業がCBDCを誰に送受信できるかをロジック化できる
    2. 送金時の閾値を決められる
    3. 特定期間内で使用するように制限できる
  • このように事前条件を定めておくことで、キャッシュマネジメントを効率化できる。

• 非機能要件から特筆すべき事項
  • プライバシー
    • トランザクション情報は実名ではなく仮名と紐づいている。
    • しかし、この仮名による匿名化機能は、銀行間決済のような参加者間で完全に秘匿したい取引には相応しくない。
    • 同様に、法人向けにおいても、トランザクションの匿名性が求められる
    • 一方、規制当局は追跡性を求めており、誰が誰に送金したかを正確に知りたい、その必要性が出てきた時に。
    • ゼロ・ナレッジ・プルーフが秘匿性を向上させるが、これは送金に関わった参加者だけがトークンの残高の前後を参照できる仕組み
    • プロトタイプでは、BOTが規制当局としてあらゆるタイプのトランザクションをモニターした。トランザクションは当事者とBOTだけが参照できるように匿名化した
    • しかし、高い秘匿性により、全体的なシステムのパフォーマンスが犠牲となった
  • セキュリティー
    • ネットワークセキュリティーとしてアクセス制限をしている。すなわち、承認されたノードだけがネットワークで特定のアクションを実施できるようになっている。
    • ブロックチェーンでは、口座へのアクセス、トランザクションの署名のために、秘密鍵の管理が必要となる
    • Hyperledger Besuでは鍵管理をサポートしておらず、署名するための鍵は外部で保管される
  • スケーラビリティー
    • スケーラビリティーとはネットワークサイズ（参加者数）とトランザクション量（トランザクション数）のことを指している
    • ノードは、ネットワークユーザーとネットワーク管理者に分かれる。
      • ネットワークユーザーはノンバリデーティングノードを管理するだけで、ブロックチェーンのコンセンサス・メカニズムには関わらない。
      • ネットワーク管理者はバリデーティングノードを管理し、コンセンサスに参加する
    • 推奨されるバリデーティングノードの数は、技術的制約もあり、最大20まで。
    • このプロトタイプでは、ロールアップを使用した。これによりスケーラビリティーとパフォーマンスが向上する
      • ロールアップ・プロトコルは、既存のブロックチェーン上で動き、トランザクションをオフチェーンで処理する仕組み
      • トランザクションはバッチでグルーピングされる。各バッチが証明としてオンチェーンで記録される
      • このメカニズムはオフチェーンで処理されるため、オンチェーンのスマートコントラクトが直接オフチェーンのトークンとやり取りすることが出来ない
      • 確かにロールアップはＴＰＳを向上させる
      • しかし、バッチに関しては懸念がある。
      • バッチはトランザクションが一杯になった時に初めて処理されるから。すなわち、トランザクション量が少ない時、待ち時間が発生する
  • レジリエンシー
    • IBFT2.0では、バリデーティングノードはバリデーターであり、トランザクションとブロックを検証する
    • バリデーターは次のブロックを順番で作成する
    • ブロックをチェーンに挿入する前に、バリデーターの大多数（66%以上）が最初にブロックに署名する
    • IBFT2.0では少なくとも4人のバリデーターがないと、ビザンチン耐性を得られない
    • プロトタイプでは5人のバリデーターをデプロイした。例え1人のバリデータが無反応になっても、コンセンサスは適切に機能した。
    • しかし、2人以上のノードがダウンした際、コンセンサスは得られず、全ネットワークをレストアする必要があった。これは大変時間が掛かる。

• その他考慮事項
  • バリデーターになる事のメリットを考えなければならない
    • 一つのインセンティブは、データへのアクセス権である。今日データから得られる洞察は決定的に重要であるから。
    • もしくはバリデーターの参加者に金銭的インセンティブを与える