Conclave ユースケースと実装サンプルの紹介

今日は、R3が開発した新技術Conclaveのご紹介をします。

Conclaveとは、秘匿計算ソリューションの一つで、その概要については弊社の別記事（秘匿計算ソリューションConclave ～秘匿計算技術の比較～）をご覧ください。この記事では、R3で想定している具体的なユースケースとその実装サンプルをご紹介します。

目次

ユースケース①法人の収入保障保険
ユースケース②ダークブール
ユースケース③株式エクスポージャーの計算
実装コードの紹介
最後に（イベントでのDemoのご案内）

ユースケースの紹介

秘匿計算ソリューションであるConclaveを用いる場面を理解する為に、３つのユースケースをご紹介します。

①法人の収入保障保険

コロナ禍では、多くの企業が予期せぬ減収に見舞われました。政府補償等である程度補填されているものの、存続の危機に見舞われている企業も少なくありません。

そこで、（今後もあり得る）予期せぬ危機に対して保険会社が保険を提供しようとする動きがあります。

このような保険を作る際には、保険を確保したい企業は、保険会社に対して、例えば「過去３年間の収入額の平均値」といった情報を提供する必要があります。

Conclave無しの業務プロセス

そして、保険会社は、この金額に基づいた保険料の見積もりを提示することになります。従来、この「過去３年間の収入額の平均値」を正しく証明する為に、企業は（銀行が提供する）入出金明細などの情報を保険会社に提供していました。

これは、多数の機微情報が含まれる情報が「裸で」やりとりされてきたことを意味します。非効率的であるばかりか、（特にそれが中小企業の場合）プライバシー上の課題も抱えることになります。

秘匿計算ソリューションであるConclaveを用いれば、この非効率でプライバシーリークの危険性を持った業務を変革することが可能です。下の図をご覧ください。

企業（Policy Holder)が保険料試算を依頼
保険会社（Insurer）が企業に対して「過去３年間の収入額の平均値」を提供するよう依頼
企業が銀行（Bank）に対して「入出金明細をConclaveに提供するよう依頼」
銀行がConclaveに入出金明細を提示
Conclaveが入出金明細から「過去３年間の収入額の平均値」を計算
Conclave「過去３年間の収入額の平均値」を保険会社に提示

このプロセスでは機微情報である入出金明細は保険会社に渡りません。しかし、必要な平均収入額は、「正しいデータをもとに正しく計算された」という証明付きで保険会社に提供されることになります。

以上が最初のユースケースのご紹介でした。

このソリューションはZKP等他のソリューションでも提供可能かもしれません。しかし、このソリューションを社会実装する上で重要なのはソリューション構築と運用のコストです。

秘匿計算のコアハードウェアであるIntel SGXは既に皆さんのPCの中に存在しています。（あなたがM1 Macの使用者でなければ！）そして、Conclaveを用いた秘匿計算実装はJavaで行うことができます。

つまり社会実装に向けたハードルは非常に低いのです。

②ダークブール

ダークプールとは、実行されるまでクライアントの注文を非開示にする取引所です。注文が公開されている場合、その注文情報を元に注文を入れるシステムトレーダー等によって、価格が不安定化することが知られています。

注文情報を非開示にすることで、（少なくとも理論的には）価格の安定性を確保することができます。

一方で問題は、システムを制御する取引所が注文を「漏らし」たり、インサイダー情報を悪用したりする可能性があることです。こうした懸念があることから、証券取引所等の公的な性質を持つ機関では利用されてきませんでした。

公開型の板と、ダークプールの対比

この問題の解決策は、Conclaveを使用して注文書と注文データを保護することです。下の図をご覧ください。

青いところがEnclave(Intel SGXで作られた安全な領域）です。この中にConclaveで作られたアプリケーションが（誰からも読み取れない形で）実装されます。

Dark Poolのワークフロー

顧客のアカウントをEnclave内に作成
買い注文をEnclaveへ送信
売り注文をEnclaveへ送信
Enclave内のConclaveアプリが注文のマッチングを実行
マッチング結果を顧客へ通知し、注文を執行（この部分はブロックチェーン基盤Cordaで実行したいですね！）

このようにして、リークの心配がなく、かつ「ずる」のできる可能性のない安全で安定した取引所を実現することができます。このソリューションでは、内部に簡易DBを持ちます。

一定規模まではオンメモリで、さらに大規模化する場合は外部のパーシステントへ暗号化して情報を持たせることが可能です。

③株式エクスポージャーの計算

最後の例は、この春マーケットを賑わせたヘッジファンドArchegosの破綻問題に関するソリューションです。（以下は筆者の憶測であり、事実と異なる可能性が高いことをお含みおきください）

Archegos問題では、多くの金融機関がArchegosに対して株式ポジションを提供していました。そして、破綻懸念が出た時に、ポジションを手仕舞うよう求めました。

しかし、アルケゴスが特定の株式に対して（金融機関ごとに構築しているポジションは小さいものの）全体として非常に大きなポジションをとっていたことが判明し、破綻を回避するための手仕舞い自体が株式市場を混乱に陥れてしまいました。

Archegosの破綻は、集団的なリスクエクスポージャーに対処するため、金融機関の間で協力する必要性を浮き彫りにしました。しかし、取引情報の公開は金融機関のビジネスの根幹を揺るがしかねない行動です。

金融機関間の連携では、参加者が情報を抽象化しつつ、セキュリティ、整合性、プライバシー等を確保する必要があります。

こうした問題に対するソリューションをConclaveは提供可能です。上の図をご覧ください。

各金融機関は、日時の取引情報をConclaveアプリケーションへ送信します。
Conclaveアプリケーションは、各金融機関の取引情報をもとに、特定の顧客のエクスポージャーを計算し、各金融機関でのポジションがそのうち何％を占めているかを各銀行に示します。

このソリューションでは、個別金融機関の取引情報は（誰一人触ることができない）Conclaveの中でしか開示されません。結果としてそのデータのプライバシーは保たれます。

一方で結果を集計して得られる特定株に対するトータルエクスポージャーを確認することはできます。

実装の紹介

簡単にではありますが、３つ目のユースケースのソースコードを一部抜粋してご紹介します。



class AnalyticsEnclave : Enclave() {

   private val database = Database()

    @Synchronized
    override fun receiveMail(id: Long, mail: EnclaveMail, routingHint: String?) {

        val message = serializer.decodeFromByteArray(Message.serializer(), mail.bodyAsBytes)

        when (message) {
            is Request -> processRequest(message, mail.authenticatedSender)
            is Response -> processResponse()
            else -> {
            } // If we do not know the type of message, we ignore it.
        }
    }