VISAがCBDC向けオフライン決済プロトコルを発表
TL;DR
VISAが公表したCBDCのテクニカルペーパー
中央銀行がルートCAを担い、許可されたエンティティが中間CAとなる
TEEでオフライン決済をサポート
本文
ペーパーではCBDCの位置付けを「送金中のマネーが信頼できる発行者の責任であり続ける必要がある」とし、責任の所在を国および中央銀行に定めている。その上でCBDCが満たすべき要件として、「金融政策によって適切に発行されること」と「価値が維持されること（二重支払いや偽造ができないこと）」を挙げている。
プロトコルの前提となるアーキテクチャとして、Tier1とTier2の2階層型を採用している。Tier 1は「証明書インフラ」としての機能を実現し、中央銀行からデジタル証明書の管理を許可されたエンティティへアウトソースする。公開鍵インフラストラクチャ（PKI）のアナロジーでいえば、中央銀行をルートCAとして、許可されたエンティティは中間CAのようなの役割を果たすイメージだ。中間CAは、規制遵守に基づくwallet providerを審査し、審査済みのwallet providerにデジタル証明書を発行する。一般ユーザへの決済機能はwallet providerが提供し、CBDC決済を安全に促進するため、デジタル証明書が利用される。このようにTier1で証明書インフラを切り出すことで、Tier 2はCBDCの「決済」に注力できるアーキテクチャとなっている。
ここからは、本題のオフライン決済について紹介する。オフライン決済は地下など決済ネットワークへのアクセスが困難な状況下でも送金者〜受金者間のみの通信で決済を完了させるものだ。ペーパー中では、オフライン決済の実現によって、実質無限のスループットを実現するとしている。さらにプライバシー保護の観点から不要な支払情報を、中間の許可されたエンティティに共有しないことも言及されている。
本ペーパーで提案されているオフライン決済プロトコルは、送金者と受金者の両ユーザがオフラインであっても決済できるよう設計されている。また決済中にユーザは決済ネットワーク上の中間CAサーバと通信しない。セキュアハードウェアとしてTEEを用いており、送金者はTEEが必須である。受金者は必ずしも必要ではないが、転々流通する場合は、受金者もTEEが必須な設計だ。厳密にはオフライン決済の送金トランザクションを生成するためにTEEの機能を利用しているため、オフラインでの送金を行うユーザにはTEEが必須となっている。なお、TEEはGlobal Platform仕様に準拠したモデルを採用している。
本オフライン決済プロトコルには、「オンライン残高」と「オフライン残高」という2種類の残高が存在する。オンライン残高は中間CAサーバ上に記録され、オフライン残高はユーザのセキュアハードウェア上に記録される。両者を行き来するためにDepositとWithdraw関数が用意されており、オフライン決済が想定されるユーザは事前にオンライン残高からオフライン残高へDepositしておく必要がある。
さらにオフライン決済に用いるユーザのデバイスは初期セットアップとして、中間CAサーバへ登録する必要がある。セキュアハードウェア内で公開鍵ペアを生成し、鍵ペアのうち公開鍵を中間CAサーバへ送信する。セキュアハードウェアには製造時に焼き付けられた鍵が存在し、中間CAサーバは製造元へattestationを行う。これによって正規のセキュアハードウェアが利用されていることを保証でき、中間CAサーバはユーザの公開鍵に署名を付与したレスポンスを返す。この署名は中央銀行のルートCAからチェーン上に検証が可能になっている。オフライン決済トランザクションを受け取った受金者は、オフライン下であっても正当なCBDCであることが検証可能だ。
オフライン決済トランザクションは、受金者のリクエストから開始される。受金者は自身のアドレスと送金額を記した支払いリクエストを送金者へ送る。支払いリクエストを受け取った送金者は、自身のオフライン残高を減額し、送金トランザクションを生成し、受金者へ送信する。受金者は送金トランザクションが正当であること（前述の中間CAサーバの署名付き公開鍵によって検証が可能）、受金者アドレスが自分自身であること、既に受け取り済みの送金トランザクションでないことを確認し、自身のログに保存する。受金者がTEEを利用していれば、送金トランザクションをオフライン残高に反映し、転々流通を続けることができる。TEEを利用していない場合は、再度オンラインになった際に送金トランザクションを中間CAサーバに提出し、オンライン残高に反映することができる。
本ペーパーは、以上のプロトコルでオフライン決済を実現する内容となっている。一つずつ紐解いていけば非常にシンプルな構成となっているので、時間を取って読んでみてほしい。より厳密なプロトコルの流れについては、Appendixにも記載している（文責・恩田）
Appendix
具体的なプロトコル
本文を読んだ上で、Deposit、Withdraw、Offline Paymentを読むと全体像が把握できる
https://gyazo.com/dfb6c63a7c9cbe8d1a3a660eee45ecb6
https://gyazo.com/07162f5dcf10e13475eeeca1a8ad8868
deviceの登録
https://gyazo.com/9f1fbd48be8f0e2e4c1bcf4af267368f
Initしないと他のメソッドが有効にならないことをTEEで保証
https://gyazo.com/08591c63eae5f4268ea031b20b105e13
TAの登録
製造時の鍵を使ってRemote Attestation
cipepser.icon remoteでTAをprovisioningする文脈で、信頼できる主体としてTrustonicが挙げられている
https://gyazo.com/f1c6f91582aff8f9b47c803a6e4b07b7
https://gyazo.com/a39336d8ee213a4b53158543eca9117e
https://gyazo.com/e5b0dbc60ef65d5dfb27497695ff4ab1
cipepser.icon 受け取り手が先に請求をかけるのがポイント
https://gyazo.com/5ea08cd7a074a76fc06e71fd893f128a
Allenらによると、オフライン決済を実現するために使用におけるセキュアハードウェアについて3つの課題が挙げられている。「①偽造を目的とし、ユーザ自身がハードウェアを破壊する強いインセンティブがあること」「②1つのデバイスを破壊するとと無限に資金を使えてしまうこと」「③デバイスの紛失、故障によってユーザ資金が完全に失われること」だ。なお、③については、現状の現金を含むあらゆる形態の決済で同じため、本ペーパーではハードウェアが破壊されない前提で議論を進めている。