前書き
今回Reference state(以下Ref.state)に関する可能性を追求する調査を行いました。この調査により複数のユースケースで生じていた問題を解決することができます。本記事はCorda tech meetup 冬の陣(2023年2月22日開催)における発表の中で割愛した実際のテストコードを用いた結果の提示や詳しい説明の補足部分などを行う目的で作成されました。内容は、本記事のユースケース紹介編と課題解決編の２部編成でお届けしたいと思います。
Corda tech meetup 冬の陣のイベントレポートはこちらになります。
自己紹介
SBI R3 Japan株式会社にインターンでお邪魔している大学３年の井本翔太と申します。大学進学以来ブロックチェーンに興味を持ち始め、その仕組みや活用方法を学ぶ過程でCordaと出会いました。現在は、Cordaの機能調査やデモアプリケーション修正といったエンジニア業務やプレゼン資料作成といったビジネスサイドの仕事までありがたいことに様々な業務を経験させていただいております。
１章：3つのユースケース紹介と共通課題の整理
はじめに3つのユースケースをご紹介し、それぞれに共通する課題について理解していただこうと思います。
1. Verifiable Credentials(VC)の失効確認
Verifiable Credentials(VC)とは分散型のIDであるDIDに紐づく検証可能な資格情報になります。
前提としてALice、VC発行会社、企業という3つのエンティティが存在します。
はじめにAliceはVC発行会社の管理するVCをテストを受講することで下図のtxを発行しました(TOIECを受けてIIBCがスコア証明書を発行するイメージで大丈夫です。)。このVCのtxを企業での就職活動時にスコア証明として提出するケースを想定します。
ここで、Aliceがテスト受講の際に不正を働いていたことが発覚したため、VC発行会社は下図の失効txを発行しました。※チェーンで繋がっているのは先ほどのVC発行txの続きであることを意味します。
しかしながら、Aliceは下図のように失効前のtx(赤枠に示すtx)を企業に渡すことが技術的に可能になります。この時、企業はVCの発行や失効に関するtxの当事者ではないため、渡されたtxの有効性について一切把握することができません。 つまり、企業は渡されたtxを元に700点のVCが有効であると判断せざるを得ません。
そこで、企業がAliceから渡されたtxのVC stateが有効なのか失効なのか確認する方法は存在しないのでしょうか？企業がVC stateをNotaryに投げ、検証した結果が未消費であれば、更新されていないためVC stateをInputStateとして消費した失効txは発行されていない=有効と判断できます。一方、消費済みであれば、更新されたためVC stateをInputStateとする失効txが発行された=無効と判断できます。したがって、VC stateの消費状況が判明すれば有効性を把握することができます。
2. トークン取引の第三者がその存在を確認する方法
続いてのユースケースはトークン取引の際に生じる問題に焦点を当てています。今回はトークンとして日本酒を指定しました。
前提として、Party A、Party B、Party Cの３つのエンティティが存在します。
はじめに下図の左のtxようにParty Aが所持している日本酒を下図の右のtxでParty Bに移転します。
その後、Party CはParty Aに対して日本酒を購入したい意向を示します。Party Cは取引前にParty Aにて日本酒所持の事実を確認したいため、事前確認としてParty Aの日本酒所持を示すtxの送信をParty Aに要求します。しなしながら、現在Party Aに日本酒は存在せずParty Bに移転されています。
ここでイレギュラーの発生として、移転したにも関わらずParty Aは誤って事前確認として日本酒の所持を示す赤枠のtxをParty Cに渡してしまいました。この時、Party Cは日本酒移転に関するtxの当事者ではないため、渡されたtxを元にParty Aに日本酒があると判断せざるを得ません。
Party CがParty Aから事前確認として渡された日本酒所持に関するtxを信じるのではなく検証する方法は存在しないのでしょうか？Party Cが日本酒stateをNotaryに投げ、検証した結果が、未消費であれば、更新されていないため日本酒stateをInputStateとする移転txは発行されていない=Party Aは日本酒を所持と判断できます。一方、消費済みであれば、更新されたため日本酒stateをInputStateとする移転xは発行された=Party Aは日本酒を所持していないと判断できます。したがって、日本酒stateの消費状況が判明すれば日本酒の所有状況を把握することができます。
3. Nodeに関する障害発生によって失われたstate情報の確認
最後のユースケースはNodeに関する障害が発生した際に生じる問題に焦点を当てています。
前提としてNode-Notary間で通信中に障害が発生し、Nodeは時点スナップショットを用いたロールバックで自身の情報の復元を試みます。下図にて通常のNode-Notary間での通信中にNodeで障害が発生する具合を示しています。
その後、時点スナップショットを用いたロールバックにてNodeは自身の情報を復元しますが、下図に示すように時点スナップショット以降の情報は失われてしまいます。したがって、復旧したNodeは障害発生時に処理していたtxを再度流そうとしても障害によって失われた期間にtxのInputStateをNotaryが消費済みとしたのか未消費のままなのか把握できないといった問題が生じます。
そこでNodeがInputStateの消費状況を検証する方法は存在するのでしょうか？NodeがInputStateをNotaryに投げ、検証結果が未消費であれば、NotaryはInputStateを処理していないと判断できます。一方、消費済みであれば、NotaryはInputStateを処理したと判断できます。したがって、InputStateの消費状況が判明すれば再びtxにて使用できるか把握することができます。
共通する課題の整理
先ほどの3つのユースケースに共通する課題として、あるtxの中のstateの消費状況を知りたいという問題が存在していました。
- VCのケース：企業がParty Aから渡されたtxのVC stateの消費状況を検証したい
- 日本酒トークン：Party CがParty Aから渡されたtxの日本酒 stateの消費状況を検証したい
- Node障害のケース：Nodeが障害によって失われた期間にtxのInputStateが消費されたかどうかを検証したい
消費状況を確認したいのであれば下図のように目的のstateをInputStateとしてtxに含めてNotaryに問い合わせてはどうでしょうか？
しかしながら、この手法では消費状況を確認したいstateが未消費だった場合も消費済みになってしまいます。 つまり、消費状況を確認するためにNotaryに問い合わせを行った結果、強制的に消費済みになってしまう大きな問題点が存在します。またCordaは二重消費をNotaryが検知するため、そのstateは二度とtxで使うことができません。
以上から、消費状況を確認したいstateを問い合わせの際に消費することなく検証する必要があります。
2章：検証により実現可能な要件
この検証を実現することで、従来手法では難しいと考えられていた要件を達成することができます。それは、目的のstateをInputStateとして消費したtxの存在を検知できるという点です。目的のInputStateしたtxとは、VCのユースケースでは失効tx、日本酒トークンのユースケースでは移転txになります。
従来手法では達成不可能な理由としては、Cordaのプライバシー性の高さにあります。Cordaではプライバシー性の高さによりtxの当事者以外(第三者)がその概要を確認することはできません。そのため、txの存在確認のため関連するtx(AliceのVC発行tx、Party Aが日本酒所持を示すtx)を受け取った第三者が、その中に含まれるstate(700点のVC state、日本酒state)をNotaryに問い合わせても強制的に消費済みとなります。したがって、目的のstateが使用されたtxの存在を検知できませんでした。しかしながら、消費状況が変わることなく問い合わせが可能になれば、関連するtxとチェーンで繋がるtxの存在を検知できます。ここで強調したいのは、データは完全に閲覧不可能であるため、Cordaが提供するプライバシー性は崩壊する事がないという点です。
終わりに
以上がユースケース紹介編になります。さて、消費状況を変えることなく問い合わせを実現する手法はどのようにして実現するのでしょうか？お察しの良い皆様なら、タイトルのキーワードである 「Reference state」 が出てきていないことにお気付きだと思います。閑話はここまでにしまして、解決方法に興味を持たれた方はぜひ課題解決編をご覧ください。
Cordaにご興味のある方はSBI R3 Japan株式会社へ直接ご連絡いただければ幸いです。ご一読ありがとうございました。