資金決済WG(クロスチェーンRTGS分科会)中間報告について

2023年10月2日 08:14

※本記事は2022.10.28に公開されたものをNoteへ移行しています。

1. はじめに

こんにちは、デジタルアセット共創コンソーシアム（DCC）運営事務局です。

前回の記事では、2022年9月29日に発表したプレスリリース「「資金決済WG」における中間報告書の公表と「Progmat Coin」のクロスチェーン技術検証開始について」の内容の中でも、「Progmat内RTGS分科会」にフォーカスをあて、中間報告までの検討結果について解説しました。

今回の記事では、本WGのもう一方の分科会である「クロスチェーンRTGS分科会」における検討結果について解説します。

それでは、早速みていきましょう。

2. クロスチェーンRTGS分科会における検討結果(中間報告)

はじめに、中間報告の全体像をご理解いただくために、「クロスチェーンRTGS分科会」における中間報告発表時点までに協議した論点と、その検討結果についてまとめます。

まずは必要な技術検証内容の策定に向けて、机上検証によりクロスチェーン実装方式の主案を定め、合意形成を行いました（下記、(1)および(2)の論点）。

次に、机上検証に際しては、商用利用を前提としたセキュリティ面・性能面に加え、将来的な拡張性を最大限考慮して比較検討を行い、「プロキシ型（TEE上）IBC」が望ましいとの見解を得ました（下記、(3)の論点）。

最後に、前述の主案を前提に、「Progmat Coin」（on Corda）のユースケースにおける実装方法を具体化し、3ステップアプローチによる検証計画を定めました（下記、(4)の論点）。

(1)チェーン間の接続/認証方式
論点：異なるチェーン間でのトランザクション（以下、「Tx」）の処理状況を把握し、相互の処理を連動させるための仕組みとして、どのような方式が望ましいか検討する
【方式】API方式、相互認証方式（TTP方式、HTLC方式、Relay方式）

結果：新たなトラストポイントが生じ、拡張性を制約し得る「API方式」や「TTP方式」は採用しない。また、一定のユースケースにおいて、「HTCL方式」は取りはぐれのリスクがあるため、最も優位な「Relay方式」を主案とする

(2)クロスチェーンのアーキテクチャ
論点：(1)で確定した方式を実現する際のアーキテクチャとして、どのような方式が望ましいか確定する
【方式】直接検証型、プロキシ型（BC上）、プロキシ型（TEE上）

結果：前提として、本ユースケースでは「IBC」プロトコルと「Cross Framework」活用が望ましい（「Polkadot」との対比）。よって、「IBC」のネットワーク構成として、将来の拡張性とセキュリティ・性能面を考慮し、「プロキシ型（TEE上）IBC」を主案とする

(3)Cordaにおける実装
論点：「Progmat Coin」のように、Corda上に構築した基盤において、(2)の検討で主案としたアーキテクチャをどのように実装するかを確定する。また、Cordaを用いたユースケースの具体的なクロスチェーンのフローを検討する

結果：CordaにおいてもTxの正当性を担保するためのValidatorsを導入し、Proofの条件とする。また、Corda側のロック/アンロックを行いアトミックな処理を実現すべく、Encumbrance機構（消費条件の任意追加）を活用する

(4)検証計画
論点：前述の検討結果を踏まえ、クロスチェーン検証の実現可能な進め方・方針を整理する。また実機検証のスコープ・検証項目を策定し、スケジュールを明定する。

結果：①疑似環境でのQuorum-Corda間クロスチェーン検証、②各ST基盤-Progmat Coin間の機能検証、③実際のSTセカンダリ取引を想定した実証検証、の3ステップを行う。ステップ1の検証は、2022年10月~2023年2月で実施し、6つの検証シナリオにより技術課題を抽出する
次章以降では、各論点と検討結果の詳細について解説します。

3. チェーン間の接続/認証方式

まず、異なるブロックチェーンを跨いだDvPを実現するにあたっては2パターンあり、①APIによる処理状況を連携する方式、②ブロックチェーン間で直接処理状況を連携して整合性を担保する相互認証方式、に大きく分けられます。

API方式は、ブロックチェーン間の整合性担保に工夫を要し、かつAPI管理者に対する規制/要件が国によって異なる点から、拡張性に制約が生じるといった課題があります。一方、相互認証方式は、ブロックチェーン間の直接接続により整合性担保が容易であり、様々なユースケースを想定した場合には拡張性の観点で優位であると評価できます。

続いて、相互認証方式には、「TTP方式」（Trusted Third Party）、「HTLC方式」（Hashed Time Locked Contract）、「Relay方式」の3パターンがあります。3パターンの中でも、「TTP方式」には、「信頼可能な第三者エンティティ」により整合性を担保するという特徴があり、その結果、「信頼可能な第三者エンティティ」が新たなトラストポイントを生むことから、前述の「API管理者に対する規制/要件が国によって異なる」問題と同様の課題があげられるため、「HTLC方式」又は「Relay方式」が望ましいと言えます。

さらに、「HTLC方式」は、ST⇔SCの交換取引において、ST受け側（SC渡し側）が鍵を用いてSTをアンロックすると、ST渡し側（SC受け側）は当該鍵を用いてSCをアンロック可能になる仕組みであり、例えば、ST側に譲渡数制限がある等の一定のユースケースにおいては、SC側のみ移転が成立し、ST側が不成立となる「取りはぐれ」が生じるという懸念があります。

したがって、チェーン間の接続/認証方式としては、相互認証方式の内、新たなトラストポイントが生じず、かつ、「取りはぐれ」のリスクもない、「Relay方式」を主案として結論づけました。

4. クロスチェーンのアーキテクチャ

前章で主案とした「Relay方式」の選択肢としては、「IBC」（Inter Blockchain Communication）と呼ばれるプロトコル（通信規格）を用いる方法か、「Polkadot」を利用する方法が考えられますが、「実績」「プライバシー」「その他制約（不透明）」の観点で、「IBC」を採用することとしました。

「IBC」は、「ICS」（Interchain Standards）として仕様を公開しており、異なるBC間でのやり取り（転送、認証、順序付け）が可能であり、また、BC（A）の情報をクエリしてBC（B）にTxを送る通信仲介役の「Relayer」と、各BC上で受領データの正当性を検証する「クライアント」に特徴があります。

「IBC」のトラストレスな性質を可能にしているのが、改ざん検知が可能で信頼不要な「Relayer」と、リレーされてきた相手方BCデータの正当性を検証する「ライトクライアント」（簡易ノード、以下LC）であり、両方のBCが相手方BCのLCを立ち上げることで相互認証を行うという仕組みです。

LCは主にブロックヘッダー（ブロックのハッシュ値）のみを用いて検証するため、すべてのデータを保存するために大きなリソースが必要なフルノードよりも軽量となります。

※Cordaはブロック（=ブロックヘッダー）の概念がない等、台帳ごとの特性を考慮したProofを用意する

また、各BC上でスマートコントラクトとして組み込む「IBC-module」に加え、App-moduleとして組込可能な「実行制御機能」「ロック機能」を「Cross Framework」としてDatachain社が提供しており、「Progmat Coin」によるDvP/PvPで活用することを想定しています。

前述の「IBC」では、各BC上にそれぞれ相手方のBCのLCを持ち合うこと（直接検証型）となりますが、「Progmat Coin」のように接続先BCが増加していく将来像を踏まえると、ネットワーク構成全体として複雑化/非効率化していくことが想定されます。より効率的なネットワーク構成として、各BC上のLCを持つ「ハブシステム」（プロキシ）と各BC上のLCとで相互認証を行う「ハブ＆スポーク型ネットワーク構成」（プロキシ型）が考えられます。

「IBC」のネットワーク構成として「プロキシ型」を採用することにより、以下記載のメリットによって拡張性が担保しやすくなると考えられます。
①新規に参画するBCは、ハブシステム（プロキシ）のみに繋げば、ハブシステム（プロキシ）の先の各接続済BCと容易に接続可能
②接続先BCは新規増加する際、ハブシステム（プロキシ）に当該新規BCのLCを追加すればよく、各接続済BC側で新たなLCの追加は不要
③「直接検証型」の場合、異なるBCの組み合わせによっては相手方BCのLCを実装することが困難なケースもあり得るが、「プロキシ型」では実装が可能

前述の「（直接検証型）IBC」アーキテクチャを、「プロキシ型IBCアーキテクチャ」に昇華させた概念図は下記の通りです。改ざん検知可能で信頼不要なBC間仲介役の「Relayer」の存在は不変ですが、BC（A）の情報をクエリしてTxを送る先はBC（B）ではなく、ハブシステム（プロキシ）となり、ハブシステム（プロキシ）において検証した結果をBC（B）に提出し、BC（B）はハブシステム（プロキシ）の検証結果を検証します。上記のプロセスによって、各BC（A/B）はハブシステム（プロキシ）のLCを実装することで足り、その先の各BC（B/A）のLCをそれぞれ実装する必要がなくなります。

※Cordaはブロック（=ブロックヘッダー）の概念がない等、台帳ごとの特性を考慮したProofを用意する

最後に、「プロキシ型IBC」におけるハブシステムの実装方式として、①ブロックチェーン（Tendermint等）上実装、②TEE（Trusted Execution Environment）上実装の2パターンが考えられます。（TEE=OSとは独立したCPU上の隔離実行環境。SGX=インテルの「Software Guard Extensions」の略）
①は、Tendermintでの開発実績はあるものの、新たに導入するBCにおけるセキュリティ対策コストや性能面での懸念が想定されます。一方、②は、①と比較して技術的に黎明期ながら、①におけるセキュリティや性能面の懸念を軽減でき、単一障害点とならない設計も可能なため、主案とすることとしました。

５．Cordaにおける実装

「Progmat Coin」を含む「Progmat」基盤は、金融ユースケースにおけるプライバシーと性能面の観点から、先ずはCorda上で実装しています。Cordaは、Ethereum等と異なる仕組みを有しているため、EthereumやQuorum、HyperLedger等の基盤との接続には工夫が必要となります。

一般論として、NVN（Non-Validating Notary）による二重消費検証を行っているCordaのビジネスネットワークの場合、Txの中身を検証するValidatorが必ずしも存在しないため、Txの正当性を異なるBC間で担保するための仕組みが必要となります。

Cordaにおいて、SCの移転Tx（=Cash Contractと呼ぶ）のOwnerが各取引参加者のままの場合、前述の「IBC-module」「Cross Framework」によるフローにおいて、相手先BCからのデータを受けてアンロックする際、再度Ownerの署名が必要となり、アトミック性が損なわれます。

したがって、Contractの消費条件を任意に追加できるEncumbrance機構を活用することで、EncumbranceによるCashのロックを行う際にOwnerを公知の秘密鍵に変更したうえで、相手先BCからのデータを受けてEncumbranceのアンロックと公知の公開鍵署名とを一つのフローで実行可能とします。

前述の「プロキシ型IBC」は、ハブシステム（プロキシ）を「LCP Node」（Light Client Proxy Node）と定義し、当該Node上の「LCP Enclave」内に（Relayer、App経由で得た）Cordaを含むBCからのデータを検証する「ELC」（Enclave Light Client）と、（Relayer、App経由で）各BCに返すデータに署名する際に用いるEnclave Keyを生成・管理する「EM」（Enclave Manager）を保持する構成です。さらに、「Attestation Service」によって、「LCP Enclave」の完全性を各BC上の「LCP Client」が検証可能になります。

前述したCordaを含む「プロキシ型IBC」のフローをご参考までに以下の図表の通り図示します。

6．検証計画

最後に、検証計画として、検証フェーズ・ステップの大枠をまとめます。

FY2022下期時点では、「Progmat Coin」のSC移転プログラム群は開発前であること等から、実施可能なスコープから段階的に検証する方針としました。
Step1では、Quorum-Corda間の「IBC」を用いたクロスチェーン検証を疑似環境下で実行し、技術課題の抽出を行います。Step2では、ST基盤側は「ibet」「Securitize」（Quorum）、SC基盤側は「Progmat Coin」（Corda）の検証環境下で実行し、各システム固有の課題の抽出を行ったうえで、Step3において実際のSTセカンダリ取引におけるプロセス（PTSからの出来TxをインプットとしたSTP化）を踏まえた検証を行います。

ここからはStep1の検証について、より詳細に解説します。Step1での検証目的は、前述の机上検証により主案とした”Cordaを含む「プロキシ型IBC」構成“を前提に、構成要素である「IBC」「LCP」「Cross Framework」の活用によって、「拡張性の高いトラストレスなブロックチェーン間相互接続」と「異なる基盤上のSTとSCの同時移転（クロスチェーンアトミックスワップ）」を実装し、技術課題を抽出することです。

さらに、ST基盤側をQuorum、SC基盤側をCordaと想定し、Quorum-Corda間のIBCを用いたクロスチェーン検証をスコープとします。主要な正常系/異常系ケースにおける技術課題を抽出するため、下表のとおり、6つの検証シナリオを実行します。

また、各検証シナリオにおける検証項目は下表のとおりです。

前述の通り、検証環境は、“Cordaを含む「プロキシ型IBC」構成”を前提に用意します。Step1では、「Progmat Coin」のSC移転プログラム群は開発前であることに加え、ST基盤側も「ibet」「Securitize」と個別に検証を実施する場合は重複部分を含めてスコープ拡大することから、「Corda-Quorumの疑似環境」を本検証用に別途構築することとします。

最後に、検証スケジュールについてです。2023年2月末時点で検証結果を分科会として取りまとめることを念頭にスケジュールを策定しています。2023年1月末までに前述の検証環境構築を完了し、2023年2月前半で各検証シナリオをPoCとして実行する想定です。

7. まとめ

今回の記事では、前回の記事の続編として、本WGのうち「クロスチェーンRTGS分科会」の中間報告時点での検討結果について解説しました。前述したように、「Progmat Coin」と他の基盤との連携方法についての検討も、SCを用いた資金決済を実装するためには欠かすことのできない大事な要素であり、引き続きWG内で検討を深めていきたいと考えています。

次回以降も、よりタイムリーに皆様にとって価値のある情報発信ができる記事を掲載して参ります。今後もST発行実績に基づく成果や、各種WGを通じて得られる成果についての情報還元を継続し、皆さまのご検討の一助となればと考えています。個別のご質問やご相談事項がございましたら、共同検討をはじめとしたさまざまな枠組みがありますので、DCC事務局までお問合せください。

引き続き、DCCおよびProgmatをよろしくお願い致します。

ご留意事項

本稿に掲載の情報は執筆時点のものです。また、本稿は各種の信頼できると考えられる情報源から作成しておりますが、その正確性・完全性について三菱UFJ信託銀行が保証するものではありません。
本稿に掲載の情報を利用したことにより発生するいかなる費用または損害等について、三菱UFJ信託銀行は一切責任を負いません。

Digital Asset Co-Creation Consortium | Co-creation network for establishing STO