エンタープライズ向けBC（プライベート/コンソーシアム型）の特徴と代表基盤比較

1. はじめに

こんにちは、ST研究コンソーシアム（以下、SRC）運営事務局です。

前回の記事では、一般的に有望なSTO対象として語られる不動産を裏付資産としたセキュリティトークン（以下、不動産ST）について、Progmatスキームを活用する場合の税制について検討しました。

Progmatスキームによる不動産STは、上場株式等と概ね同様のものであり、課税制度が選択可能である柔軟さと、源泉徴収のみで確定申告を不要とすることが可能である手軽さを兼ね備えていることから、高い利便性を有していることを説明しました。

また、税率については一律20.315％(所得税および復興特別所得税15.315％と住民税5％の合計)であり、所得分類が雑所得となるクラウドファンディングの税率と比較し、課税される所得金額が330万円以上であれば、Progmatスキームの不動産STの方が有利であることを示し、余資運用を行う個人投資家の多くのケースで有利な税率となることが想定されることについて触れました。

2020年12月からの3回に亘り、ユースケースとしての不動産STに焦点を当て、「Progmatスキーム」の特徴に関する記事をお送りしてきましたが、今回の記事では、プラットフォームである「Progmat」システムの根幹となるブロックチェーン(以下、BC)基盤について、その類型、代表的なもの、「Progmat」で採用している基盤とその選定理由等について説明します。採用するBC基盤の性質は、当該基盤を利用して構築されるプラットフォームの特徴として影響し、最終的にはプラットフォーム上で提供されるサービスの特徴を一部表象するものです。この記事により、「Progmat」と「Progmatを用いて発行されるセキュリティトークン」とが備える性質等について、皆さまにお示しできれば幸いです。

2. BCの共通技術要素

BCには、ネットワーク参加に許可が必要か、どのタイミングで取引が確定するか、どのようなデータモデルを採用しているか等の違いにより、異なる性質を持った多くの種類があります。今回の記事ではBC基盤の比較を行いますが、まずは、その相違点を把握するために必要な、共通する要素技術についてまとめます。

(1)ハッシュ関数

ハッシュ関数は、任意の長さの入力データから、長さが固定されたハッシュ値と呼ばれる出力値を計算する関数のことです。この関数には、一方向性・無相関性・衝突耐性等の性質があり、後述のデジタル署名やハッシュチェーン等、BCのセキュリティや効率的な処理を構成する主要な技術となっています。

一方向性とは、出力値から入力データを求めることができないことであり、無相関性とは、入力データの変化によって出力値の変化を予想できないことです。衝突耐性とは出力値が同じになる複数の入力データを見つけることが困難であることを指しています。

ハッシュ関数は単体で使えば、入力データから意味のない文字列を表示させるだけのものですが、上記の性質により、「ハッシュ値が変わっていなければ、入力データも変更(改竄)されていない(可能性が高い)」と言えることから、後述の技術を構成する上で重要な要素となっています。

(2)ハッシュチェーン

ハッシュチェーンは、ハッシュ関数を活用した技術であり、順序のある複数のデータを関連付けてつなぎ、データに改竄耐性を持たせるものです。

まず、初期ハッシュ値を用意し、履歴として追加されるデータは、前のデータのハッシュ値を含む構成とします。前のデータのハッシュ値と、追加されたデータそのものをハッシュ関数の入力データとして新たにハッシュ値を算出し、これをさらに次に履歴に追加されるデータに関連付けることで、複数のデータを順序付けてつなぎます。

これにより、履歴を構成するデータは全て直前のデータのハッシュ値を持ちながらハッシュ化されているため、どれか1つデータが変更された場合、後続のデータに記録されたハッシュ値と相違することになることから容易に改竄を検出できる仕組みとなっています。

(3)マークルツリー

マークルツリーとは、ハッシュ関数を利用して複数のデータを１つにまとめ、改竄検知・探知の性能を持たせたデータ構造であり、考案者のRalph Merkleの名前からこの名がつけられています。

マークルツリーを生成する手順は以下の通りです。

①複数のデータについて、それぞれハッシュ値をとる。
②各ハッシュ値を2つ１組にし、その2つのハッシュ値を入力値として、
　新たにハッシュ値をとる。
③ハッシュ値が1つになるまで②を繰り返す。

これにより、最終的に1つになったハッシュ値を起点に見ると、枝分かれする木のような構造となり、これがマークルツリーと呼ばれる理由です。同様の考え方で、最終的に1つになったハッシュ値をマークルルート(根っこ)と呼びます。構造上、マークルルートはすべてのデータのハッシュ値が関与して算出されたものであるため、どれか１つのデータが改竄されればマークルルートも変わるため、改竄を検知することができます。

また、仮に改竄されたデータが１つだけだとしたら、マークルルートを出力するのに入力値とした２つのハッシュ値のどちらかが変わっていることになります。変更されたハッシュ値にも元となるハッシュ値が２つあり、ここでもどちらか一方が変更されていることになります。このようにマークルツリーを降りていくことで、素早く改竄されたデータそのものを特定することができます。

(4)デジタル署名

デジタル署名とは、公開鍵暗号の仕組みを利用してメッセージの作成者とメッセージそのものが改竄されていないことを検証可能にする技術です。

公開鍵と秘密鍵の対になった２種類の異なる鍵を使います。署名者が秘密裡に保持する秘密鍵で署名を行い、メッセージの受け手は誰でも知ることができる公開鍵で検証を行います。署名者は検証者に対して検証のための鍵を送る必要がなく、安全にメッセージが改竄されていないことを検証することができます。

3. 「パブリック型BC」と「プライベート／コンソーシアム型BC」

はじめに、「パブリック型BC」と「プライベート/コンソーシアム型BC」の区別の基準については必ずしも定説があるわけではなく、識者によっても見解の分かれるところではありますので、パート3～5までの解説は一般論としてご参照ください。

一般的に、参加者が不特定である「パブリック型BC」と参加者が特定されている「プライベート／コンソーシアム型BC」に大別されています。金融分野のエンタープライズ向けのユースケースでは、多くの場合「プライベート／コンソーシアム型BC」が採用される傾向にあり、後述のとおり「Progmat」においても同様の選択をしています。

(1)パブリック型BC

一般的に、「パブリック型BC」はネットワークへのアクセスに許可がいらず、誰でもノードとして参加が可能なBCであるとされ、BitcoinやEthereumを例として挙げることができます。多くの場合、全ての参加者がBC上の全情報を参照することができ、誰でもトランザクション(価値データを移転する記録。以下、Tx)を作成することができ、また誰でもTxの検証・承認が可能です。

中央集権的な管理者を置かずにP2Pの取引を実現するという意味で、2008年に発表されたサトシ・ナカモトのBitcoin論文の理念を色濃く反映させたものと言えます。「パブリック型BC」は非中央集権性を備えていますが、誰でも自由にノードを保有してネットワークにアクセスでき、かつBC上のアドレスと氏名等の属性情報が必ずしも紐づけられていないため、Tx作成者の特定が困難という性質を有しています。

(2)プライベート／コンソーシアム型BC

一般的に、「プライベート／コンソーシアム型BC」は、単独または許可された特定の参加者のみがノードとしてネットワークに参加できるものです。「パブリック型BC」では不特定多数の主体がネットワークにアクセスすることが可能ですが、「プライベート／コンソーシアム型BC」においては、多くの場合「ドアマン」と呼ばれるネットワークへの参加の許可を行う主体を置くことで、アクセス範囲の限定が可能です。また、Txを作成することができるノードを限定し、特定の者を選択することも可能です。

また、前述の通り、「パブリック型BC」ではTx作成者の特定が困難ですが、「プライベート／コンソーシアム型BC」ではBCに取り込まれるTxを作成できるノードの保有者を限定し、且つ当該ノード保有者を予め氏名等の属性情報と紐づけておくことも可能なため、誰がいつ書き込んだかを全て追跡することが可能です。

「Progmat」は有価証券としてのSTを取り扱うプラットフォームであり、顧客資産の流出を未然に防止するため、セキュリティ確保の蓋然性が高いものを選択することが肝要と考えています。斯かる観点から、プラットフォームとして適合している基盤は「プライベート／コンソーシアム型BC」であると評価し、採用するに至りました。

4. プライベート／コンソーシアム型BC比較の評価軸

「プライベート／コンソーシアム型BC」はエンタープライズ向けの実用例が近年増加傾向ですが、特定のユースケースに特化したものや「パブリック型BC」から派生したもの等、多くの種類が存在し、それぞれ異なる性質を持っています。一般的に「エンタープライズ向けのプライベート/コンソーシアム型BC」と称される基盤を横断的に評価するため、まずは評価軸を検討します。

(1)プライバシー

多くの「パブリック型BC」では参加者全員が等しく全てを知ることができる構造ですが、特に金融領域のエンタープライズ向けBCであれば、プライバシーの確保は必須要件であるということが言えます。各基盤のプライバシー確保の仕組みをまとめ、評価します。

(2)スケーラビリティ

事業化を想定する以上、どの程度のスケーラビリティ(拡張性)が見込めるかは重要な評価要素となります。取引処理速度や、ノード数の増加による変化等を考慮し、評価します。

(3)スマートコントラクトの表現力

ユースケース次第では、複雑な状態遷移の実現や、ノード毎に個別のシステムに応じた独自の動作を定義することが必要になる可能性があります。エンタープライズ向けBCとして、そのような必要が生じた際に、柔軟に対応できる基盤か否かを評価します。

(4)アップグレーダビリティ

実際のビジネスにおいて、システムリリース後にアップグレードや要件の変更が行われる可能性が大いに考えられます。このような事態への対応難易度について、それぞれの基盤を評価します。

5. 「Corda」・「Hyperleger Fabric」・「Quorum」の比較

代表的な「エンタープライズ向けのプライベート／コンソーシアム型BC」として、「Corda」「Hyperleger Fabric(以下、HLF)」「Quorum」の3つを、下表のとおり比較・評価します。各基盤は日進月歩でそれぞれ進化しておりますので、あくまで評価時点での考察であり、下表において青色でハイライトしている項目は三菱UFJ信託銀行がSTプラットフォームにおける基盤として望ましいと評価しているに過ぎない点、ご留意ください。

(1)Corda

「Corda」は世界の主要な金融機関が出資して設立された「R3 LLC」が開発する「プライベート／コンソーシアム型BC」の基盤であり、取引者の間でのみデータが共有されるよう設計されています。各評価について、文章量の関係から記載を省略している事項もあるため、詳細についてはSBI R3 Japanのウェブサイト（https://sbir3japan.co.jp/corda/）をご参照ください。

まず、プライバシーの観点で評価します。データモデルの特徴として、他の2つの基盤が「アカウント型」であるのに対し、Cordaは「UTXO(Unspent Transaction Output)型」となっています。「アカウント型」のデータモデルは主語が参加者であり、参加者毎に価値データを管理していますが、「UTXO型」は主語が価値データであり、その価値データについて、所有者が誰かを指し示すものになっています。このため、価値データの移転に際し、取引当事者間で残高情報を共有する必要がなく、「アカウント型」と比較しより高い水準でプライバシーを確保することが可能と言えます。また、Txのフローでは知る必要のある範囲内でTx情報を共有することが可能であり、関係のないノードにはTxの存在自体を知られないという特徴もあります。プライバシーに関して、評価時点では“強固な基盤”であると言えます。
次に、スケーラビリティを評価します。「Corda」は他の2つの基盤と異なり、複数のTxをブロックにまとめるということはせず、1つのTx毎にフローが完了するモデルとなっているため、複数のTxを並列して処理することが可能であり、取引処理速度の改善・高速化を期待することができます。

続いて、スマートコントラクトの表現力を評価します。「Corda」で利用可能なプログラミング言語はJava(またはKotlin)であり、既に開発環境が比較的整備されているという利点があります。また、「Corda」における状態遷移ロジックの実装において、特筆すべき制約はありません。

最後に、アップグレーダビリティの評価です。「Corda」では基本機能としてContract(Cordaのスマートコントラクト相当要素)のアップデートが可能であり、更新は容易と言えます。アップグレードの内容は各ノードに伝達され、通常のTxのフローと同様にアップグレードをするためのフローが実行されることでアップデートが完了します。

(2)HLF

「HLF」は、BCのオープンソースソフトウェアを開発する業界横断の取り組みである「Hyperleger」の中で最大の取組であり、日本銀行と欧州中央銀行によるブロックチェーン技術に関する共同調査プロジェクト「プロジェクト・ステラ」で利用されていた基盤としても知られています。

プライバシーの観点では、データモデルは「アカウント型」であり、Txの都度、取引当事者に残高情報を共有する必要があるという点で「Corda」と異なりますが、プライバシーを確保するための「チャネル」という仕組みを持っています。チャネルは1つのBCを共有する範囲であり、これを設定することでチャネル外の参加者に対してはプライバシーを確保することが可能です。ただし、チャネル内の情報について同一のチャネルの参加者に対して一切秘匿することができず、またチャネル構成は動的に変化するものではないという点に留意する必要があります。

スケーラビリティの観点では、チャネル設定することはできるものの、チャネル内の全ノードには全てのTxが共有されるため、チャネル内のノード数に反比例して処理速度が低下する傾向があります。

スマートコントラクトの表現力の観点では、Go、JavaScript、Javaといったプログラミング言語で開発することができ、既に開発環境が比較的整備されているという利点があります。また、Cordaと同様、状態遷移ロジックの実装において、特筆すべき制約はありません。

アップグレーダビリティの観点では、「HLF」も「Corda」同様、基本機能としてChaincode(HLFのスマートコントラクト相当要素)のアップデートが可能であり、更新は容易と言えます。

(3)Quorum

「Quorum」は、エンタープライズ向けイーサリアムの標準化団体であるEEA(Enterprise Ethereum Alliance)によって設計され、JP Morganが開発し、昨年ConsenSysに譲渡された、「パブリック型BC」から派生した「プライベート／コンソーシアム型BC」の基盤です。

プライバシーの観点では、「HLF」同様、データモデルは「アカウント型」であり、Txの都度、取引当事者に残高情報を共有する必要があります。また、評価時点では「Corda」や「HLF」のようなプライバシー確保のための特別な仕組みは完備されておらず、基本的には全てのTxの情報が全参加者に共有されることになるため、別途何らかの秘匿化技術を用いた措置を講じない限り、プライバシー確保の水準は高いとはいえません。

スケーラビリティの観点でも、「Corda」のような共有先の個別設定や、「HLF」のようなチャネルの設定による共有先の制限ができないことから、全てのTxが参加ノード全体に送信されるため、ノード数に反比例して取引処理速度が低下します。また、Tx数が増加した場合でも、Validator(Quorumのコンセンサスノード)は分散処理不可であるため、円滑なスケールアップは見込めないと考えられます。

スマートコントラクトの表現力の観点では、「Quorum」で使用できるプログラミング言語はSolidityやVyper等であり、これらはEVM(Ethereum Virtual Machine、イーサリアムでのプログラム実行環境)を利用するBCのスマートコントラクトを表現することに特化した言語です。三菱UFJ信託銀行はこの点において、開発環境はあるものの、「Corda」や「HLF」に比べるとプログラム実装スキルの習熟に時間を要すると評価しました(もちろん、この点は評価者の開発体制・要員構成に依ります)。また、EVMにより実行されるスマートコントラクトで扱える処理が「Corda」や「HLF」に比べ制限され、アプリケーションとの連携が必要になるケースが多くなる可能性が懸念されました。
アップグレーダビリティの観点では、「Quorum」はスマートコントラクトのロジックのアップデートを行う基本機能はなく、特殊な設計が必要となります。このため、スマートコントラクトの更新は比較的困難であり、段階的な機能拡張が必要なケースでは適合しづらいと言えるでしょう。

6. 「Progmat」における基盤選定理由

三菱UFJ信託銀行では「Progmat」の本番開発にあたり、2019年に「エンタープライズ向けのプライベート/コンソーシアム型BC」の基盤比較検証(PoC)を実施し、同年９月時点で先ずは「Corda」を基盤として採用することを決定しています。「Corda」は、先行する既存のBCの問題点を洗い出す金融機関を中心としたコンソーシアムが開発の起点となっており、STをはじめとした金融のユースケースに必要な様々な技術的な要素を備えていることが特徴と言えます。上述の基盤評価内容と重複する部分もありますが、三菱UFJ信託銀行が「Progmat」における基盤として「Corda」を選定した理由として、2019年に実施した基盤比較検証から大きく4つのポイントをご紹介します。

(1)取引情報のプライバシー確保が容易

「Corda」は前述のとおり、データ構造上、各ノードの残高情報自体を共有する必要がなく、Tx毎に「知る必要のある範囲内」でのみ共有されるように設計されているため、容易にプライバシーを確保することが可能です。特にSTのユースケースである「Progmat」において、証券会社間や投資家間で他の参加者のポジションを容易に把握(推測を含む)されてしまうプラットフォームは受け入れられないと判断し、「プライバシー確保」は重視したポイントの1つです。

(2)スケーラビリティの確保が容易

「Corda」では、全てのノードからその時点で発生した複数のTxを1つのブロックに集約するようなBCとは異なり、個々の取引単位でTxが構成されるため、複数のTxを並列処理することで取引処理速度の改善・高速化を容易に実現でき、かつ、ネットワークに参加するノードの逐次的な追加も容易です。特にSTのユースケースである「Progmat」では、ネットワークに参加するエンティティ（複数の証券会社や、三菱UFJ信託銀行以外の原簿管理者やカストディアン等）の漸次的な拡張を想定する必要があり、また、セカンダリー取引が活発になった場合も既存の証券取引比で処理速度が劣後することがないよう、処理件数の増大に関わらず高いパフォーマンスを発揮し続けることが求められると考えています。

(3)スマートコントラクトの柔軟な実装が可能

「Corda」では、各ノード別に独自の動作を定義できるため、各ノード独自の検証や、各ノード独自のシステムとの連携などを柔軟に実装することが可能です。また、「Corda」ではJava(またはKotlin)での開発が可能であるため、既に開発環境が比較的整備されている点や、Java技術者の確保が容易といった点も利点と評価することができます。これらは、金融システムとして金融機関が責任を以て維持管理していくうえで、システムとしての保守性を左右する要素のため、エコシステムのサステナビリティの観点から重視しています。

(4)スマートコントラクトの追加・修正時の負荷が低い

「Corda」では基本機能としてContract(Cordaのスマートコントラクト相当要素)のアップデートが可能であり、また通常のTxのフローによりアップグレードの承認が可能です。留意点として、Contractのアップグレードに際しては、アップグレード未了のノードと、更新済のノードでは処理の疎通がとれなくなるため、参加ノードは基本的に同タイミングでのノード再起動が必須とする等の運用上工夫しなければならない点はあるものの、スマートコントラクトの追加・修正時の負荷は比較的低いと言えます。証券バリューチェーンのDXとしてSTを捉えた場合、ノードとして参加しているエンティティ（複数の証券会社や、三菱UFJ信託銀行以外の原簿管理者やカストディアン等）の創意工夫を、容易にエンティティを跨いで適用できる点は、BCを基盤として利用することの1つのメリットであると考えています。

7. まとめ

上述の通り、一般的に各種BC基盤は「パブリック型BC」と「プライベート／コンソーシアム型BC」に大別されているとした上で、セキュリティ確保の観点から、「Progmat」のような金融領域のユースケースにおいては、許可された特定の参加者しかネットワークにアクセスできない「プライベート／コンソーシアム型BC」の方がより適合的であると評価しました。

また、代表的な「エンタープライズ向けのプライベート／コンソーシアム型BC」として、「Corda」・「HLF」・「Quorum」の3つを挙げ、一般的な比較・評価に加え三菱UFJ信託銀行として過去に実施した基盤比較検証(PoC)のポイントをご紹介しました。①取引情報のプライバシー確保が容易、②スケーラビリティの確保が容易、③スマートコントラクトの柔軟な実装が可能、④スマートコントラクトの追加・修正時の負荷が低いという4つを主なポイントとし、2019年9月時点で、「Progmat」における基盤として先ずは「Corda」を採用したことを説明しました。

特に、「UTXO型のデータモデルであり残高情報の共有が不要」・「Tx毎に知る必要のある範囲内での情報共有とすることが可能」といった要素から、「Corda」はプライバシーに関して強固な基盤であると評価しています。採用基盤から翻って、このような性質を備えたSTプラットフォームである「Progmat」により、皆さまに対して金融領域のユースケースに適合したBC活用スキームを提供できれば幸いです。

今後も情報の整理、調査を進め、皆さまへの情報還元を継続し、ST関連事業のご検討の一助となれば幸甚です。個別のご質問やご相談事項がございましたら、共同検討をはじめとしたさまざまな枠組みがありますので、SRC事務局までお問合せください。

引き続き、SRC及びProgmatをよろしくお願いいたします。

ご留意事項

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

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