企業向けブロックチェーンの業界では、アセットだけではなくライアビリティのトークン化が世界中で始まりつつあります。中央銀行が発行するCBDC、市中銀行が発行するStable Coin、そしてBISが提唱したUnified Ledger。これらは全て決済に必要ないわゆる”おかね”のユースケースに対する新しいソリューションです。 このようなユースケースに対する新しいCordaの実装であるTransaction Privacy Enhancementsを紹介します。
- (前説)“おかね”のトークン化
- Transaction Privacy Enhancements
- バックチェーン検証 (Backchain Verification)
- バックチェーン検証に関するプライバシーの課題
- Backchain Privacy Enhancementとは？
- 発行体による毎回の署名＋バックチェーン検証スキップ
- 全てのTransactionを発行体に検証させる→Notaryに検証させる
- Transaction Privacy Enhancementsの長所と短所
- 長所
- 短所
- （現在未実装だが）実現可能な特徴
- Transaction Privacy Enhancementsの実装方法
- ①NodeのCPIの再構築
- ②専用のNotary CPIの構築
- ③ネットワークに専用Notaryであることを登録
- まとめ
(前説)“おかね”のトークン化
ブロックチェーン技術はBitcoinによって日の目を見ました。そして、最初のユースケースであるBitcoinは、なんらかの価値をインターネット上で主張することにありました。さて、「価値あるもの」とはなんでしょうか？例えば自動車には価値があります。自動車業界が扱っている価値は自動車ですということができるでしょう。同じように、金融の世界には、大きく分けて二つの「価値あるもの」があります。一つは株や債券といった”資産”で、もう一つが今回取り扱う”お金”になります。
お金は、通常「銀行の負債」である場合が多いです。皆さんが持っている1万円札は「日本銀行の負債」ですし、私の個人の銀行貯金は、「銀行の負債」です。こうした”おかね”をトークン化するプロジェクトが世界中で始まっています。おそらくその最初の動きはFacebook（現Meta）が始めたLibraだと思いますが、こちらは規制当局から明確にNoを突きつけられて頓挫しました。しかし、その後も動きは続き、規制当局が許す範囲で商業銀行が発行するStable Coin（先進国の取り組みが多いです）、中央銀行が発行するCBDC（新興国の取り組みが多いです）に関する検討が進み、そしてこうした取り組みを包含するより大きな枠組みとしてBIS（国際決済銀行）が発表したUnified Ledgerという考え方が生まれています。
さて、この記事では、”おかね”のトークン化の為にR3社が新たに開発した技術であるBackchain Privacy Enhancementについてご紹介します。
Transaction Privacy Enhancements
CordaはUTXOモデルをデータモデルとして採用しています。分散環境において、UTXOモデルは、より高いレベルでのプライバシーの実現や、より高い同時実行能力を実現可能です。しかし、”おかね”のトークン化する際には、ビジネス側から、従来以上に高いレベルのプライバシー要求が出されています。その要求に応える形で今回（Corda5.2で）実装されたのがBackchain Privacy Enhancement機能になります。
バックチェーン検証 (Backchain Verification)
Backchain Privacy Enhancementのお話をする前に、まずは既存のCordaのアーキテクチャについて確認しましょう。
そもそも、高いプライバシー機能を実現しているCordaでは、取引の内容は取引当事者にしか明かされません。
例えば以下の例は、１ドル百円で200万ドルと２億円の交換を行う取引を表現しています。この時、トークンである
２億円や200万ドルという情報は取引当事者しか知らないという事になります。
しかし、この時、取引当事者たちは不安になります。
「この200万ドルは本物なんだろうか？」「この２億円は本物なんだろうか？」
いくらブロックチェーンに改竄体制があるとはいえ、このデータだけで200万ドルが本物なのか、２億円が本物なのかは判別できません。例えばこの２億円のトークンは、ネットワークの誰かから受け取ったトークンでしょうし、さらに遡っていくと「発行者」が発行したトークンであることを確認できなければいけません。
この確認のことをバックチェーン検証（Backchain Verification）といいます。下の図を使って説明しましょう。
今回ターゲットとする取引はこの図の赤く塗られた取引です。ここで使う２億円に関する取引を遡っていることを示しています。２億円は１３億円の振込でできたお釣りのようですし、さらにその振込は・・・というふうに遡ることができます。また、遡っていくと、どこかで”お金”の発行がなされているということもわかります。この例で言えば、CBDCを想定している図なので、発行体は中央銀行です。
遡ると、二つの発行トランザクション（１０億円のものと５億円のもの）が見つかり、そこに発行体（中央銀行）の電子署名があることを取引当事者は確認し、この確認を持って２億円が本当にその価値があると理解する事になります。１０億円の発行から２億円の外為決済取引に至る、その途中の取引については、スマートコントラクトの内容を検証することで、”お金”の価値が毀損していないことを確認するという事になります。（※ここでは２重支払い問題については言及しません） 従来から、CordaのNodeはデフォルトでこのようなバックチェーン検証機能を備えていました。Cordaは、過去の取引についての検証を実行しますし、そのために必要な情報のやり取りをNode間で自動で行うような機能を持っています。
バックチェーン検証に関するプライバシーの課題
このバックチェーン検証にはプライバシー上の課題（より正確には匿名性に関する課題）があります。”おかね”のユースケースの場合、途中の取引の内容について、知る必要が基本的にはありません。しかし、最初の取引に遡っていく過程で、取引情報について知ってしまう事になります。取引情報は、匿名性をある程度確保することが可能（公開鍵情報だけが含まれ、公開鍵の所有者に関わる情報は含める必要がない為）ですが、少なくとも取引の金額については確認できる必要があります。また他の取引における公開鍵情報を突き合わせることで、公開鍵の所有者を類推・特定できる可能性も否定できません。
一方で、”おかね”は、歴史的経緯から一定程度匿名性があることを前提とした使用がこれまでなされており、（デジタル化によってその重要度は相対的に減じたものの）匿名性に対するニーズが顕在化することが多いと考えています。例えば、過去の取引（上の図にある１０億円の振込や１３億円の振込）について情報を隠したいというニーズは、一般的なものとしてあり得るという事になります。コンビニでお釣りとして受け取った千円札が、発行されたばかりの新札なのか、もう世の中でたくさん使われてボロボロなのか、知りたい人はほとんどいないでしょう。また、千円札についた指紋を調べて、この千円札実はすごい有名人が触ったことのある千円札だ！ということを知りたい人も、正直いないのではないでしょうか？（ここでの匿名性はこのようなレベルのお話です）
Backchain Privacy Enhancementとは？
さて、このような過去の取引に関する匿名性が確保できない理由はなんでしょうか？それは、発行体である中央銀行の署名がないと、”おかね”を安心して受け取れないからでした。そのために全ての取引について、過去をさかのぼりたい。でも、プライバシー要件に対応しているCordaの場合であっても、この遡りによって匿名性はたもちづらい。というお話になります。
で、あれば発行体の署名を毎回つければいいのではないか・・・？というのがBackchain Privacy Enhancementの技術的アイディアになります。
発行体による毎回の署名＋バックチェーン検証スキップ
下の図をご覧ください。Backchain Privacy Enhancementでは、すべての取引に発行体である中央銀行の署名が入る仕組みになっています。この署名があることを前提にできるのであれば、取引当事者が確認したいのは、「一つ前の取引に発行体の署名が入っていること」だけになります。より詳細に考えると、確認したいのは「一つ前の取引に２億円が含まれていること」と「一つ前の取引に発行体の署名が入っていること」だけだという事になります。それ以外の内容は検証不要であり、隠蔽されていても良いという事になります。
Cordaは一つの取引情報をMerkle Treeに収納して構築します。そのため、一つの取引から、任意の情報を隠蔽した形でデータを送る事が可能です。（この機能のことをTransaction Tear Off／Filtered Transactionと呼びます。）Backchain Privacy Enhancementではこの機能を積極的に活用します。
全てのTransactionを発行体に検証させる→Notaryに検証させる
全てのTrsansactionに発行体の署名をつけるにあたって、やり方は二つあります。一つは明示的に発行体の情報をスマートコントラクトに明記し、RequiredSignerにその名前を入れておく方法です。しかしこの方法を取ると、Cordapp開発者に対して追加の制約がかかること。それから、既存のコードの活用ができなくなるという問題があります。その為、R3はもう一つの方法である、Notaryに検証をさせるという方法を取りました。この方法を用いると、Notaryの設定を変えるだけで、（正確にはNotaryの設定が変わっていることをアプリケーションネットワークで共有するだけで）Transaction Privacy Enhancements機能を実現できる事になります。
なお、このとき、Notaryが全ての情報を蓄積していくことは、プライバシーの観点でも、匿名性の観点でも問題があります。その為、Notaryは届けられた取引について、検証し署名した時点で破棄します。（少なくともR3が提供する実装上、NotaryノードにTransactionを保持するDBを持たせないようにしています。）
以上が、Transaction Privacy Enhancementsの概要説明になります。
Transaction Privacy Enhancementsの長所と短所
次に、簡単にTransaction Privacy Enhancementsの長所と短所について述べます。
長所
- 参加者間のプライバシーの強化
- パフォーマンスの向上と持続性強化
- バックチェーンの状況に関わらず「一定時間」で検証可能
- トランザクション検証作業の負荷分散
- 必要なストレージ量の削減
- より簡単なアーカイブ
- Denial of Stateアタックの回避
- アプリケーションコードの変更不要
短所
- Notary運用者への依存（信用と責任範囲の拡大）
- Notaryに対する追加のネットワークトラフィック
- Notary構築時の追加作業
（現在未実装だが）実現可能な特徴
また、Transaction Privacy Enhancementsを活用すると以下のような特徴を実現できると考えております。
- 高度なアーカイブ機能の提供
- ビジネス規模に対して一定量のストレージ使用量で運用
- Notaryに対するIdentityの隠蔽（Notaryに対する匿名性の強化）
- Corda4のConfidential Identities活用
- MGMを用いたIdentityの隠蔽
Transaction Privacy Enhancementsの実装方法
最後に、読者の皆様がBackchain Privacy Enhancement機能を試す方法を簡単に紹介します。以下の３ステップからなります。
①NodeのCPIの再構築
CPKを構築する2つのbuild.gradleファイル（:workflows配下及び:contracts配下）の以下の１行を変更して、CPIを再構築します
dependencies {
〜省略〜
// CorDapps that use the UTXO ledger must include at least one notary client plugin
// cordapp "com.r3.corda.notary.plugin.nonvalidating:notary-plugin-non-validating-client:$cordaNotaryPluginsVersion" ← もともとの記述
cordapp "com.r3.corda.notary.plugin.contractverifying:notary-plugin-contract-verifying-client:$cordaNotaryPluginsVersion" ← Notaryの種類を指定
②専用のNotary CPIの構築
※こちらの詳しい手順は
R3 Documentation Notary CorDapps - Corda 5.2 をごらんください。
②-1 CPI構築用に新しくフォルダ（Intellijの場合Module）を用意します。
②-2 当該Moduleに以下のようなbuild.gradleを用意して、Notary用のCPIを構築します
plugins {
id 'org.jetbrains.kotlin.jvm'
id 'net.corda.plugins.cordapp-cpb2'
}
cordapp {
targetPlatformVersion 50200
minimumPlatformVersion 50200
workflow {
name "Utxo demo verifying notary"
versionId 1
vendor "R3"
}
}
dependencies {
cordaProvided platform("net.corda:corda-api:$cordaApiVersion")
cordaProvided 'org.jetbrains.kotlin:kotlin-osgi-bundle'
cordaProvided 'net.corda:corda-ledger-utxo'
cordapp project(‘:contracts‘) ← 検証対象となるスマートコントラクトの指定
cordapp “com.r3.corda.notary.plugin.contractverifying:notary-plugin-contract-verifying-server:$cordaNotaryPluginsVersion” ← R3が用意した専用CPKのパッケージを指定
}③ネットワークに専用Notaryであることを登録
Notary登録時のRegistration_Contextを以下のように指定します。
export REGISTRATION_CONTEXT=' {
"corda.key.scheme": "CORDA.ECDSA.SECP256R1",
"corda.roles.0": "notary",
"corda.notary.service.name": <An X.500 name for the notary service>,
"corda.notary.service.flow.protocol.name": "com.r3.corda.notary.plugin.contractverifying",
"corda.notary.service.flow.protocol.version.0": "1",
“corda.notary.service.backchain.required”: “false” ← ネットワークの設定として、バックチェーン検証不要なNotaryであることを指定
} '以上２StepでTransaction Privacy Enhancements機能を試すことが可能です。ぜひ一度手元のクラスタでお試しいただけたらと思います。
まとめ
Corda5.2の新機能Transaction Privacy Enhancementsについて紹介しました。
今回の技術は、従来技術を組み合わせて、新しいビジネス要求に応えた例です。
この点を一歩引いてみると、ブロックチェーン技術はビジネス要求に応えられるだけ成熟してきたと言えると思っています。また、実装方法もエンジニアにとっては非常に簡単なものです。その辺りもぜひ手元で試していただけたらと思います。
一方で、既存技術の組み合わせとはいえ、弊社（R3J）でこの動作を検証するにあたっては、「メモリ上でしか検証しないスマートコントラクトが、本当に検証されているかどうかを確認したい」等の要求に対して、少し工夫が必要だったりもしました。より詳しいお話に興味があれば、ぜひ弊社営業までご連絡いただければと思います。