JP6794527B2

JP6794527B2 - 安全な台帳分散の方法及び安全な分散型台帳技術を用いたコンピューターシステム

Info

Publication number: JP6794527B2
Application number: JP2019502643A
Authority: JP
Inventors: ガッサンカラメ; ウェンティンリー; アレッサンドロスフォルツィン
Original assignee: エヌイーシーラボラトリーズヨーロッパゲーエムベーハー
Priority date: 2016-07-22
Filing date: 2017-07-06
Publication date: 2020-12-02
Anticipated expiration: 2037-07-06
Also published as: JP2019521450A; US20200294158A1; US11250518B2; WO2018015177A1; US10713731B2; US20180025435A1; EP4009260A1; EP3488404A1

Description

本発明は分散型台帳技術に関し、特に、分散型台帳技術を用いて銀行間取引の安全なリアルタイム決済を提供する方法及びコンピューターシステムに関する。

現在、銀行間の送金はそのプロセスに関わる非常に多くの中間確認手順のせいで最大数日かかる場合がある。従来の銀行間取引は、各銀行へ又は各銀行から預金を移すことにより、若しくは中央銀行を使うことにより実現される。中央銀行を使うことによりシステムを簡略化し決済解決を迅速化できる場合がある。しかしながら、既知のシステムに従って中央銀行を経るいずれの取引も、計算資源を消費し複雑な確認及びセキュリティのシステムを必要とする非常に多くの処理及び確認の手順が必要であり、その結果取引コストが高くなる。また、決済解決を行うために大量の金融情報を保管するバンキングシステムは、詳細に作られたハック、マルウェア、及びデータ破壊の標的にされてきた。

近年、分散型台帳技術は学界と産業界の両方から大きな関心を引き寄せてきた。従来のデータベース技術とは異なり、分散型台帳は中央管理者も中央データストアも必要としない。その代わりに、ブロックチェーン、より詳細には、取引履歴と呼ばれる場合がある台帳がシステム内のノード間に複製され、コンセンサスアルゴリズムにより各ノードの台帳のコピーは他の各ノードのコピーと同一になる。

一実施形態において、本発明は銀行間決済のために安全な台帳分散を提供する方法を提供する。前記方法は、中央銀行の中央コンピューターシステムとそれぞれ前記中央銀行に口座を有する少なくとも第１の送り手銀行及び第１の受け手銀行のコンピューターシステムとの間に第１のプライベートサイドチェーンを確立し、前記中央コンピューターシステムが前記第１の送り手銀行のコンピューターシステムから第１の取引を第１の支払依頼として受信し、前記中央コンピューターシステムが前記第１の取引が有効かどうかを判断し、前記第１のプライベートサイドチェーン内でコンセンサスに達し、前記中央コンピューターシステムが前記第１の受け手銀行のコンピューターシステムに前記第１の取引を第１のファイナリティプルーフとともに転送し、前記第１の送り手銀行及び前記第１の受け手銀行の口座を更新し前記第１のプライベートサイドチェーン内でのみアクセス可能な第１の秘匿台帳に前記第１の取引を加える、ことを含む。

本発明を典型図に基づいて以下に更に詳細に説明する。しかしながら、本発明は典型的な実施形態に限定されない。ここに記載された及び／又は図示された全ての特徴は、本発明の実施形態において単独で用いられてもよく、様々に組み合わせてもよい。本発明の様々な実施形態の特徴及び効果は、次の添付の図面を参照して以下の詳細な説明を読むことにより明らかになろう。

図１は、本発明の一実施形態による方法を実行するコンピューターシステムを概略的に示す。図２は、本発明の一実施形態による取引を受け取り小さな秘匿台帳を作成又は更新する方法を示すフローチャートである。

一実施形態において、本発明は、政府や金融機関にリアルタイムで安全な決済を達成する能力を提供し同時に官僚的間接費を削減する、分散型台帳技術を用いた決済解決方法を提供する。

発明者らは、公開共有台帳に基づく既知の決済解決法は金融機関に対してリスクを引き起こし各金融機関のユーザの個人情報を危険にさらすいくつものプライバシー問題を露呈することを認識した。一方では、Gregory Maxwell "Confidential Transactions: Preserve security while simultaneously obscuring transaction values"（2016年7月11日に<<https://www.elementsproject.org/elements/confidential-transactions/>>から取得）に記載されているように、受取人だけが取引の詳細を取得できるように（ビットコインのような公開台帳で）機密取引を用いることはできるが、情報はネットワーク内で高度に複製されるため、完全な取引履歴のコピーを保存するという様々な参加者の誘因を低下させてしまう。他方では、閉じたコンソーシアム内の秘匿台帳の場合、１つの秘匿台帳から別の秘匿台帳へ取引を送ることができず、機関の間での取引の柔軟性は低い。また、金融アプリケーションは全ての銀行間取引に対する規制チェックを求める。本発明の一実施形態では、参加銀行間の全ての取引を規制するために中央銀行を利用できるという利点がある。中央銀行を通じた各取引はコストと手数料を伴うため、本発明の一実施形態は、それらのコストや手数料を削減するため、支払を実行する際中央銀行において必要な取引や送金の量を最小化することを目的とする。その結果として作られる本発明の一実施形態によるシステムは、デプロイの半分散モード及びこれまで分散型台帳技術とともに使われることがなかった新しいモデルを提供する。

別の実施形態において、本発明は分散型台帳技術の利用方法を実行するコンピューターシステムを提供する。このシステムは、ビザンチン行為（例えば、マルウェアやハック）に対応し送金の実行に必要な手順の量及び送金に関連するコストを最小化しながら多数の金融機関の間でのリアルタイムの決済解決を提供する。

このコンピューターシステムは、取引に対してルールを実行し取引間のコンセンサスを提供する演算プロセッサ、サーバ、及びそのメモリを含む、中央銀行及び非中央銀行（ここでは一般銀行と呼ぶ）のそれぞれのコンピューターシステムからなる。一般銀行は互いに支払取引を発行する。効率的な支払を促進し金融規制を執行するため、中央銀行は関連する全ての取引に関わって銀行間の支払取引を承認及び監査する。全ての一般銀行は対応する中央銀行に口座を維持する。これにより銀行間取引を銀行内取引として決済でき中央銀行内のそれぞれの預金口座に反映させることができる。

中央銀行はシステム内の全ての取引を監督し規制する。銀行間取引は中央銀行内の各銀行の預金口座上で決済されるので、中央銀行は全ての取引に関わる。中央銀行により実行可能な機能には以下のものが含まれる。
・その残高や取引履歴を含む、システム内の一般銀行の預金口座への完全なアクセス。
・取引の承認又は否認。
・いくつかの特定の金融政策の執行。
・不正を働いた銀行に対する処罰（例えば、経済制裁の賦課）。

一般銀行は互いに銀行間取引を発行する。本発明の一実施形態によれば、一般銀行について以下の特性が定義される。
・各一般銀行は、中央銀行に、その残高が当該銀行が発行可能な取引の量に対する上限となり得る口座を有する。
・各一般銀行は当該銀行に関連する取引のみを扱い（受け取り、確認、処理）、当該銀行に関連しないいずれの取引の情報にもアクセスできないことが好ましい。

システム／ビザンチン障害に耐えられるように、中央銀行はその上にコンセンサスネットワークが確立される複数のノードを維持するのが好ましい。コンセンサスネットワークは、装置に障害が発生した際の分散型システムの信頼性を向上させるために使われる。

効率的ビザンチン障害耐性（efficient Byzantine fault tolerance：EBFT）がコンセンサスプロトコルとして用いられるのが好ましい。EBFTは、例えば、本明細書に参照により取り込まれているG. S. Veronese et al., “Efficient Byzantine fault tolerance,” IEEE Transactions on Computers, 62(1), 16-30 (2013)により説明されている。ＥＢＦＴは、ＩＮＴＥＬからのソフトウェアガードエクステンション（ＳＧＸ）プログラムにより提供されるような安全なハードウェアを用いた改定された実用的ビザンチン障害耐性（ＰＢＦＴ）プロトコルである。数が安全なハードウェアにより割り当てられるため障害ノードも一連の依頼メッセージを操作できないという仮定に基づいて、ＥＢＦＴはシステム内のｆ個の障害ノードに耐えるためにＰＢＦＴに比べノードの総数を３ｆ＋１から２ｆ＋１に削減する。ＥＢＦＴは２ラウンドの通信（ＰＲＥＰＡＲＥ及びＣＯＭＭＩＴ）を用いて依頼メッセージを受け入れる。異なるノードにより署名されたｆ＋１個のＣＯＭＭＩＴメッセージを受信するノードは、この依頼メッセージがシステム内で確定されたという確信を有する。

従って、ｎ個のノードを有する、各コンセンサスネットワーク又はサイドチェーン若しくは他のチェーンと対話可能な秘匿台帳を維持するチェーンの場合、システムは最大［（ｎ−１）／２］個の障害ノードｆに耐えることができる。

２つのコンセンサスレイヤー、すなわち、中央銀行内のコンセンサスレイヤー及び参加般銀行と中央銀行との間のコンセンサスレイヤーがシステム内に維持されるのが好ましい。中央銀行はその信頼性を向上させるために複数の装置を保持するのが好ましい。秘匿台帳は、全ての一般銀行の口座残高についてのコンセンサス及び取引依頼を許可／否認するためになされる全ての決定についてのコンセンサスを維持するために用いられる。規制の執行（例えば、信用制限、禁輸国ポリシー、など）は、以下に説明するようなスマートコントラクトにより実現できる。

本発明の一実施形態によるシステムを概略的に示す図１を参照すると、当該システムは、メインチェーン内に複数の（概略的に図示された実施形態においては３つの）ノードを有する中央銀行ＣＢ、更に一般銀行Ａ、Ｂ、Ｃ、及びＤを含む。一般銀行Ａ及びＢは第１のサイドチェーン１内にあり、一般銀行Ｃ及びＤは第２のサイドチェーン２内にある。実際には、各一般銀行はいくつかの中央銀行ノードとともに、当該銀行が取引する他の全ての一般銀行とサイドチェーンを形成する（別々の秘匿台帳を維持する）のが好ましい。取引履歴が銀行間で一致するように取引履歴、すなわち、秘匿台帳についてコンセンサスが維持される。各銀行は他の銀行と直接ＴＬＳ接続を確立できることが好ましい。また、各銀行は公開鍵インフラストラクチャー（public key infrastructure：PI）や中央銀行ＣＢの台帳などの何らかの信頼されるソースから取得した公開鍵で互いを認証できることが好ましい。上記のように、本開示は概して銀行に言及するが、これは仲介決済を実行するために銀行により使用されるコンピューターシステムを意味するものと理解されたい。

中央銀行ＣＢのメインチェーンは、支払依頼の有効性を確認し承認された取引をＣＢ台帳に加える。メインチェーンはまた、承認された取引のファイナリティプルーフをサイドチェーン内の各ノードに提供し、その後各ノードはそれぞれの台帳についてコンセンサスに達する。図１では、異なるノードが実線の小円によって示され（中央銀行ＣＢについては３つ、一般銀行Ａ、Ｂ、Ｃ、及びＤについてはそれぞれ１つ）、一方各チェーンはダッシュ線で示されている。

図１の例は、銀行Ａから銀行Ｂへの取引の実行に関わる手順を概略的に示す。サイドチェーン１が一度確立されると、銀行Ａは支払依頼などの取引メッセージを用意する。支払依頼には、それぞれの口座ＩＤなどのＡ及びＢについての異なる情報や支払額が含まれる。A→B:amountやC→D:amountは、支払依頼を表す署名済み取引を示す。送り手銀行は、受け手銀行がその正当性を評価できるように新規発行の取引に署名する。完全な取引構造の仕様が更に詳細に以下に示されている。

銀行Ａがサイドチェーン１内で支払依頼取引Tx1を中央銀行ＣＢに送り次第、中央銀行ＣＢはその内部メインチェーンを用いて当該取引の正当性をチェックしその有効性についてコンセンサスに達する。１つの考えられるチェックは、銀行Ａが実際に取引Tx1を行うのに十分な金をその口座に有することを確認することである。中央銀行ＣＢは、例えば、口座残高と取引履歴がメモリに保存され常時更新される状態で中央銀行に保持されている口座の全てにより、参加しているいずれの一般銀行の口座情報も評価できるため、これを確認することができる。

コンセンサスに達した場合、取引Tx1は有効であり、中央銀行はそのＣＢ台帳に取引Tx1を保存しその後取引Tx1を取引Tx1に関わる一般銀行Ａ、Ｂの両方にそのファイナリティプルーフとともに転送する。取引のファイナリティプルーフはコンセンサスプロトコルに依存する。例えば、本明細書にその全体が参照により取り込まれ、ワークオブプルーフに基づいたBack, A. et al., "Enabling blockchain innovations with pegged sidechains,^" （2014）では、ある取引がブロックに含まれ（取引の確定性を示す）当該ブロックを作るために十分な量の作業がなされてきたことを他のサイドチェーンに対して証明するために簡易支払確認（Simplified Payment Verification：SPV）証明が用いられる。本発明の一実施形態において、ＥＢＦＴとＩＮＴＥＬＳＧＸの組み合わせがコンセンサスプロトコルとして用いられる。従って、システムは支払依頼に対するｆ＋１個の署名済みＲＥＰＬＹメッセージを取引ファイナリティプルーフとみなす。また、サイドチェーン１内のノードがファイナリティプルーフ内の１つの署名を確認するだけで済むように、Boneh-Lynn-Shacham（BLS）などのキー準同型暗号化方式を用いてＲＥＰＬＹメッセージ内の署名を組み合わせてもよい。

銀行Ａ及びＢは次に取引Tx1をそれぞれの台帳に保存する。最後に、サイドチェーン１のノードはそれぞれの台帳の内容についてコンセンサスに達して正当性を確保し、取引の全体の順序について合意する。具体的には、銀行Ａ及びＢは共に、サイドチェーン１内で実行される取引Tx1及びTx2についての厳密に同じ情報を保存する秘匿台帳を有する。

このプロセスの間、サイドチェーン２の銀行Ｃ及びＤは、銀行Ａ及びＢと中央銀行ＣＢとの間のサイドチェーン１内で起きる上記の手順のいずれにも気付かない。

決済プロセスの最後に、メインチェーンは有効支払取引を実行する。有効支払取引は仮想のものであり、（全て台帳に記録される支払依頼と異なり）台帳に痕跡を残さない。むしろ、有効支払取引は中央銀行ＣＢが口座の残高を正確に更新するためにどのような操作を行うかを単に示すことができる。例えば、考えられる支払依頼順A→B→C→D:10の場合、有効支払取引（仮想）A→D:10がＡの残高を１０減らしＤの残高を１０増やすことにより実行される。

リアルタイム決済を用いた単純な手法を考える場合、第１の単純な手法を用いて各取引後に中央銀行ＣＢに保存された口座残高を更新してもよい。そのような口座残高の更新は連続的かつ自動的なものである。例えば、中央銀行が以下の取引の組を処理するとする。
E→A：15
A→B：5
A→D：10
C→D：2

これら４つの取引結果を口座残高に反映させるために、中央銀行は以下の更新を実行する必要があろう。
Ｅの残高を１５減らしＡの残高を１５増やす、
Ａの残高を５減らしＡの残高を５増やす、
Ａの残高を１０減らしＡの残高を１０増やす、
Ｃの残高を２減らしＡの残高を２増やす。

この手法を用いた場合、取引は直接的に口座残高の更新に変換され、支払はリアルタイムに決済される。また、有効支払取引は厳密に支払依頼取引に対応する。しかしながら、中央銀行ＣＢは各取引を組み合わせるために又は取引を最適に実行する方法を決定するために各プロセスの最後に多少の時間バッファが必要になる。また、この手法は各銀行が取引の決済時間を遅らせることができるほど柔軟ではない。決済解決時間の柔軟性は有用である：トークンをストックオプションとして想像されたい；出資者はそれらが所望の高価に達したときは常に売却することを望むものである。

本発明の実施形態による方法及びシステムは有利なことに、トークンを未決済支払取引とする手法を用いる。トークンは決済期限が来るまでに支払手段として１つの銀行から別の銀行へ転送できる。この手法では、口座残高は２つの部分、すなわち、通貨形態での金額である通貨残高とトークン形態での金額であるトークン残高に分割される。

流通しているトークンは、例えば、流通しているビットコインと同様、未使用取引の形態をとる。このようなトークンは、新しい取引の入力として設定することにより支払に用いることができる。これらの新しい取引はその後受益者により所有されるトークンになる。

トークンの１つの目的は、いかなる任意の時点でも口座残高の更新額を減らすことである。以下の例は、必要な口座残高更新額を減らすためにトークンをどのように有利に利用できるかを簡単に示している。この例では、個人が銀行に対応しており、実際には銀行が取引を実行する。

例１：
目標
１）アンジェラはボブに１０ドル渡さなくてはならない。
２）ボブはカールに１０ドル渡さなくてはならない。
手順：
１）アンジェラが彼女の財布から１０ドル取り出しボブに渡す。
２）ボブはアンジェラの１０ドルを彼の財布に入れる代わりに（それにより財布残高を修正して）その１０ドルを直接カールに渡す。
３）その後カールはその１０ドルを彼の財布に入れて彼の財布残高を増やす。

上記の例で、ボブはカールに彼の財布の１０ドル紙幣ではなくアンジェラから受け取った１０ドル紙幣を渡した。ボブは彼の財布を開けることさえなかった。本発明の実施形態におけるトークンはこのプロセスを仮想化する。銀行Ｂ（ボブ）は銀行Ａ（アンジェラ）から受け取った金でその残高を更新することはせず、むしろ銀行Ａの取引（１０ドル紙幣）を銀行Ｃ（カール）に払うトークンとして用いる。銀行Ｃがこのトークンを現金化すると（すなわち、カールが１０ドルを彼の財布に入れると）、中央銀行ＣＢはこのトークンは銀行Ａから発した取引を表していることを認識するため１０ドルを銀行Ａから銀行Ｃに直接送金して銀行Ｂの残高を手つかずにしておく。このように、上記の単純化された例において、トークンの使用は、銀行Ｂが銀行Ａからの１０ドルを銀行Ｃに渡すことと実質的に同等である。

銀行によって発行される支払依頼は既存のトークンをてこ入れしうるものである、又は受益者により将来のトークンとして利用されうるものである。従って、支払依頼について２種類の取引、トークン化取引及びトークン取引を用いることが好ましい。これらの取引は同じデータ構造を持つが、一部の値は以下に述べるように同じ意味を持たない。

トークン化取引：この種類の取引は銀行がトークンを所有しない場合に発行される。この場合、銀行が送金したい金額が取引の入力として用いられる。言い換えれば、銀行は支払依頼を作成するために自身の通貨残高の金をトークン化する。これは、当該取引がその後のトークン取引を実行するために受け手銀行により利用されうる新規作成のトークンになるからである。ＣＢサイドチェーンは、送り手銀行の通貨残高からトークン入力フィールドに示された金額を減らす。テーブル１はトークン化取引の基本構造を示す。上記例の手順１）において、銀行Ａ（アンジェラ）はトークン化取引T₁=<10, Sig_A,10,PubKey_B>を発行する。
表１：トークン化取引の取引メッセージ（トークン）形式

トークン取引：この種類の取引はある銀行が自身の所有するトークンの所有権を支払依頼として譲渡する際発行される。この場合、過去の未使用トークンが取引の入力として用いられる。テーブル２はトークン取引の基本構造を示す。上記例の手順２）において、銀行Ｂ（ボブ）はトークン取引T₂=<T₁, Sig_B, 10, PubKey_c>を発行する。
表２：トークン取引の取引メッセージ（トークン）形式

取引T₁及びT₂（支払依頼）は、その有効性の確認のために中央銀行ＣＢのメインチェーンに送られる。具体的には、トークン化取引を用いて、ＣＢのメインチェーンは送り手銀行Ａの通貨残高の利用可能な貸方金額をチェックする。また、トークン取引を用いて、ＣＢのメインチェーンは入力トークン（群）がＣＢの台帳上にあり、使用されていない又は現金化されていない（すなわち、通貨残高に変換されていない）ことを確認する。

全ての支払依頼はまずＣＢのサイドチェーンに送られるので、中央銀行ＣＢはシステム内の全取引を概観しており従って確認を行うのに適格である。従って、ＣＢのサイドチェーンからの有効な承認決定は全ての銀行により信用されうる。

トークンを現金化するために、現金化取引が生成され専用のアドレスに送られる。CBのサイドチェーンはこの現金化取引を確認し現金化されたトークンを所有する銀行の通貨残高に当該取引の出力金額を加える。

トークンの所有者は随時現金化取引を開始することができる。上記の例の手順３）において、銀行Ｃ（カール）は現金化取引T₃=<T₂, PubKey_C,10,Address_redeem>を発行する。トークンの所有者が現金化プロセスをＣＢのサイドチェーンに任せることを望む場合、その旨をトークンのscriptPubKeyフィールドの決済解決方式（例えば、支払期限）に示すことができる。例えば、scriptPubKey = <PubKey_A V （dueTime Λ ThresholdPubKey_CB>を有するトークンは、当該トークンが、現金化取引を持つ銀行Ａにより、又は決済支払期限に達しサイドチェーン内のノードのしきい値署名が提供されたときに現金化が可能であることを意味する。

中央銀行ＣＢはスマートコントラクトを用いて全ての一般銀行の口座情報を保持し最も多くの規制的機能を実行することが好ましい。コントラクトの構造を以下のように示すことができる。
表３：スマートコントラクトの構造

銀行が取引の送信を望む場合、常にスマートコントラクトのsendTransaction()メソッドを呼び出す。コントラクトはその後当該取引に対し一連のチェックを行い、送り手銀行の口座の現在の状態に基づいて真か偽を返す。当該取引がそれらのテストを通過した場合、コントラクトはfowardTransaction()メソッドを呼び出すことにより当該取引を当該取引の意図する受益者に送る。スマートコントラクトは全参加銀行のコンピューターシステムによって利用可能なプロトコルである。従って、本発明の一実施形態によるＣＢのメインチェーンは仮想のメインチェーンである場合がある。各銀行は自身のコントラクトを実行することができる。

中央銀行はまた、システム内の一般銀行がそこから公開鍵を取得可能なグローバルアドレスリストスマートコントラクト、及び他の銀行の接続情報を保持する。ある銀行が別の銀行とのプライベート接続の確立を望む場合、スマートコントラクトにそのアドレスを要求することができる。コントラクトの構造は以下のように示すことができる。
表４：グローバルアドレスリストスマートコントラクト構造

本発明の一実施形態は既知のシステムに対する以下の利点と進歩を提供する。
・異なるコンセンサスレイヤーとアクセス範囲を用いてプライバシーを向上させネットワーク内及び台帳内の取引数を減らし、
・小型かつ高速で相互接続された秘匿台帳を用いて大きな参加者の組を作り相互接続させ、
・トークン又は未使用取引の利用とスマートコントラクト口座モデルとを組み合わせて有効支払取引の数を減らし銀行間支払を実行して１つの秘匿台帳から別の秘匿台帳への資産の譲渡を可能にし、
・ＥＢＦＴコンセンサスプロトコルからのｆ＋１個の組み合わせ署名を持つＲＥＰＬＹメッセージを取引のファイナリティプルーフとして用い、
・信頼される計算アンカーと連結されたビザンチン障害耐性システムに依拠して通信ラウンドを減らしそれによりシステム性能を向上させ、
・分散型台帳を持つバンキングシステムの堅牢性を向上させ、
・例えば、ＥＢＦＴコンセンサスプロトコルにより、個々に有効に扱われうる小型だが相互接続された秘匿台帳を生成することによりビザンチン障害耐性コンセンサスプロトコルのスケーラビリティを向上させ（そうでない場合、例えば、一台帳に対して１０〜２０前後のノードに限定される場合がある）、
・秘匿台帳を用いてシステム内の取引メッセージの負荷を減らし台帳間取引を容易にし、
・中央銀行ＣＢが柔軟なやり方で全ての銀行間取引に対し金融的規制を公示／執行できるようにし、及び／又は
・決済の解決に必要な取引数を減らして取引手数料を削減する。

このように、本発明の実施形態は中央銀行ＣＢ及び参加する一般銀行のコンピューターシステムの機能に対しいくつもの改善を加えている。中央銀行ＣＢのメインチェーンを介して小型だが相互に接続された秘匿台帳の新しい構造を用いることにより、生成され扱われる情報は非常に少なくなり、一方、中央銀行ＣＢで確認を集中管理し取引の特定のサイドチェーンの一部ではない銀行からの情報を保護することによりセキュリティが向上する。また、変更・保存される情報が少なくなり、それによりリアルタイムでより多くの取引を扱えるように処理能力は増大し保存装置の空間は小さくなる。

図２は、システム内の官僚的手順を最小化しながらリアルタイム決済解決を提供する本発明の一実施形態による方法のフローチャートを示す。第１のステップＳ１において、送り手銀行は安全な通信ネットワークを介して中央銀行ＣＢ及び受け手銀行に接続要求を送る。この要求の目的は、３つの銀行間に新しいプライベートサイドチェーンを確立することである。この接続は安全なトランスポートレイヤーセキュリティ（ＴＬＳ）チャネル上に確立することができる。ステップＳ２において、送り手銀行はスマートコントラクトプロトコルのsendTransactionメソッドを用いて取引を中央銀行ＣＢの内部メインチェーンに送る。ステップＳ３において、中央銀行ＣＢのメインチェーンはスマートコントラクトプロトコルのvalidateTransactionメソッドを用いて当該取引の有効性をチェックする。例えば、ＣＢのメインチェーンにアップロードされたチューリング完全のプログラムは、当該取引のデータに対し必要な全てのチェック（例えば、送り手銀行が当該取引を実行するのに十分な残高を有することを確認）を自動的に実行できる。当該取引が有効でない場合、ステップＳ４でエラーメッセージが送り手銀行に送られる。発行手数料、又は、必要な場合、その後の取引の保留などの懲戒処分を含む他の措置や対抗措置も採ることができる。ステップＳ５で当該取引が有効である場合、中央銀行ＣＢのメインチェーンは該当するサイドチェーン内でコンセンサスに達するためにＥＢＦＴコンセンサスプロトコルを採用し、コンセンサスに達し次第、ステップS6でスマートコントラクトプロトコルのforwardTransactionメソッドを用いて当該取引を受け手銀行に転送する。この場合、受け手銀行は、中央銀行は当該取引を承認した、換言すれば、中央銀行ＣＢのメインチェーンが当該取引の有効性について該当するサイドチェーン内でコンセンサスに達したというｆ＋１個の署名済みＲＥＰＬＹメッセージの暗号証明を受信することができる。この証明はｆ＋１個のノードのアグリゲート署名からなる場合があり、又は単純に同一のメッセージに対するｆ＋１個の別個の署名からなる場合がある。コンセンサスに達しない場合、ハックやマルウェアなどの障害が特定され、コントロールがステップＳ４に進む場合があり、そこで、通知又はエラーメッセージが生成され適切な管轄官庁に送られる場合があり、例えば、取引を要求している銀行に対し制裁が科される場合がある。

ステップＳ７において、中央銀行ＣＢはスマートコントラクトプロトコルを用いて自身のコンピューターシステムのメモリにおけるサイドチェーン内の各参加銀行について正確な残高口座を維持・更新する。ステップＳ８において、送り手銀行、受け手銀行、及び中央銀行ＣＢはそれぞれの台帳に当該取引を加えそれぞれの台帳の内容についてのコンセンサスを維持し続けて取引履歴の正当性を確保する。ステップＳ９において、当該取引の確定とともにプライベート接続を終了することができる。システムはその後又は随時、別の参加者と新しいプライベートサイドチェーンを開始することができる。

上記のように、ＣＢのメインチェーンにより実行されるその後のステップは、好ましくはトークンを用いて、サイドチェーン間で資産を譲渡することである。特に、上記の小型だが相互接続された秘匿台帳のシステムを有利に用いることにより、このようなサイドチェーン間の資産の譲渡はより少ない取引と向上したプライバシーで実行することができる。

本発明を図面及び上記記述において詳細に図示及び説明したが、それらの図示や説明は一例又は典型例であり限定するものではないと解釈すべきである。以下の請求の範囲内で当業者により変更及び修正が可能であることは理解されよう。特に、本発明は上記及び下記の様々な実施形態の特徴の任意の組み合わせを有する更なる実施形態を含む。また、本発明を特徴づける本明細書の記述は本発明の一実施形態を意味するものであり、必ずしも全ての実施形態を意味するものではない。

請求項で使われる用語は、上記の記述と一致する最も広い合理的な解釈で解釈されるべきである。例えば、構成要素を導入する際の冠詞「a」又は「the」の使用は複数の構成要素を除外するものと解釈すべきではない。同様に、「又は」の記載は、「Ａ又はＢ」の記載がＡとＢのいずれかのみを意図することが文脈又は前述から明らかでない限り「Ａ及びＢ」を除外しないように、包括的なものと解釈すべきである。また、「Ａ、Ｂ、及びＣのうちの少なくとも１つ」の記載は、Ａ、Ｂ、及びＣがカテゴリーその他として関連しているかどうかにかかわらず、Ａ、Ｂ、及びＣからなる構成要素の群のうちの１つ又は複数と解釈すべきであり、列挙した構成要素Ａ、Ｂ、及びＣのそれぞれの少なくとも１つを必要とすると解釈すべきではない。更に、「Ａ、Ｂ、及び／又はＣ」若しくは「Ａ、Ｂ、又はＣのうちの少なくとも１つ」は、列挙された構成要素のうちの任意の単一の実体、例えば、Ａ、列挙された構成要素のうちの任意のサブセット、例えば、Ａ及びＢ、若しくは列挙された構成要素Ａ、Ｂ、及びＣの全体を含むと解釈すべきである。

Claims

銀行間決済のために安全な台帳分散を提供する方法であって、
中央銀行のメインチェーンにおいて、前記中央銀行の中央コンピューターシステムとそれぞれ前記中央銀行に口座を有する少なくとも第１の送り手銀行及び第１の受け手銀行のコンピューターシステムとの間に第１のプライベートサイドチェーンを確立し、
前記中央コンピューターシステムが前記第１の送り手銀行のコンピューターシステムから第１の取引を第１の支払依頼として受信し、
前記中央コンピューターシステムが前記第１の取引が有効かどうかを判断し、
前記中央コンピューターシステムが前記第１の取引の第１のファイナリティプルーフを提供するためのコンセンサスプロトコルを採用し、
前記中央コンピューターシステムが前記第１の受け手銀行のコンピューターシステムに前記第１の取引を前記第１のファイナリティプルーフとともに転送し、
前記メインチェーンにおいて前記第１の送り手銀行及び前記第１の受け手銀行の口座を更新し前記第１のプライベートサイドチェーン内でのみアクセス可能な第１の秘匿台帳に前記第１の取引を加える、ことを含む方法。
前記第１の取引はトークン取引又はトークン化取引であり、
前記第１のプライベートサイドチェーンと少なくとも第２のプライベートサイドチェーンとの間での資産譲渡を容易にするために、生成された又は現金化されたトークン群が用いられる、請求項１に記載の方法。
前記中央銀行の前記メインチェーンにおいて、前記中央コンピューターシステムとそれぞれ前記中央銀行に口座を有する少なくとも第２の送り手銀行及び第２の受け手銀行のコンピューターシステムとの間に第２のプライベートサイドチェーンを確立し、
前記中央コンピューターシステムが前記第２の送り手銀行のコンピューターシステムから第２の取引を第２の支払依頼として受信し、
前記中央コンピューターシステムが前記第２の取引が有効かどうかを判断し、
前記中央コンピューターシステムが前記第２の取引の第２のファイナリティプルーフを提供するためのコンセンサスプロトコルを採用し、
前記中央コンピューターシステムが前記第２の受け手銀行のコンピューターシステムに前記第２の取引を前記第２のファイナリティプルーフとして転送し、
前記メインチェーンにおいて前記第２の送り手銀行及び前記第２の受け手銀行の口座を更新し前記第２のプライベートサイドチェーン内でのみアクセス可能な第２の秘匿台帳に前記第２の取引を加える、ことを更に含み、
前記第１及び第２のプライベートサイドチェーンは互いに異なる参加者を有する、請求項１に記載の方法。
前記第１の取引はトークン化取引であり、前記第２の取引はトークン取引であり、
前記第１のプライベートサイドチェーンと少なくとも前記第２のプライベートサイドチェーンとの間での資産譲渡を容易にするために、生成された又は現金化されたトークン群が用いられる、請求項３に記載の方法。
前記第１の受け手銀行と前記第２の送り手銀行は同じ銀行であり、
前記中央コンピューターシステムが前記トークン化取引から受けとったトークン群を前記トークン取引に適用する、請求項４に記載の方法。
前記中央コンピューターシステムが前記トークン群を現金化するための現金化依頼を前記第２の受け手銀行から受信し前記第２の受け手銀行の口座の残高を更新することを更に含む、請求項５に記載の方法。
前記第１の受け手銀行及び前記第２の送り手銀行である銀行の口座の残高は前記第１及び第２の取引の間は更新されない、請求項６に記載の方法。
銀行間決済のために安全な分散型台帳技術を用いた中央銀行のコンピューターシステムであって、前記コンピューターシステムは１つ又は複数のプロセッサ又はサーバを含み、前記１つ又は複数のプロセッサ又はサーバは単独又は組み合わせて
前記中央銀行のメインチェーンにおいて、前記コンピューターシステム自身とそれぞれ前記中央銀行に口座を有する少なくとも第１の送り手銀行及び第１の受け手銀行のコンピューターシステムとの間に第１のプライベートサイドチェーンを確立し、
前記第１の送り手銀行のコンピューターシステムから第１の取引を第１の支払依頼として受信し、
前記第１の取引が有効かどうかを判断し、
前記第１の取引の第１のファイナリティプルーフを提供するためのコンセンサスプロトコルを採用し、
前記第１の受け手銀行のコンピューターシステムに前記第１の取引を前記第１のファイナリティプルーフとともに転送し、
前記メインチェーンにおいて前記第１の送り手銀行及び前記第１の受け手銀行の口座を更新し前記第１のプライベートサイドチェーン内でのみアクセス可能な第１の秘匿台帳に前記第１の取引を加える、コンピューターシステム。
前記１つ又は複数のプロセッサ又はサーバは更に前記第１の送り手銀行の口座がトークン群を有するかどうかに基づいて前記第１の取引をトークン取引又はトークン化取引として実行し、前記第１のプライベートサイドチェーンと少なくとも第２のプライベートサイドチェーンとの間での資産譲渡を容易にするために、生成された又は現金化されたトークン群を用いる、請求項８に記載のコンピューターシステム。
前記１つ又は複数のプロセッサ又はサーバは更に
前記中央銀行の前記メインチェーンにおいて、前記コンピューターシステム自身とそれぞれ前記中央銀行に口座を有する少なくとも第２の送り手銀行及び第２の受け手銀行のコンピューターシステムとの間に第２のプライベートサイドチェーンを確立し、
前記第２の送り手銀行のコンピューターシステムから第２の取引を第２の支払依頼として受け取り、
前記第２の取引が有効かどうかを判断し、
前記第２の取引の第２のファイナリティプルーフを提供するためのコンセンサスプロトコルを採用し、
前記第２の受け手銀行のコンピューターシステムに前記第２の取引を前記第２のファイナリティプルーフとともに転送し、
前記メインチェーンにおいて前記第２の送り手銀行及び前記第２の受け手銀行の口座を更新し前記第２のプライベートサイドチェーン内でのみアクセス可能な第２の秘匿台帳に前記第２の取引を加え、
前記第１及び第２のプライベートサイドチェーンは互いに異なる参加者を有する、請求項８に記載のコンピューターシステム。
前記１つ又は複数のプロセッサ又はサーバは更に前記第１の支払依頼を実行するのに十分なトークン群を持たない前記第１の送り手銀行の口座に基づいて第１の取引をトークン化取引として実行し、前記第２の支払依頼を実行するのに十分なトークン群を持つ前記第２の送り手銀行の口座に基づいて第２の取引をトークン取引として実行する、請求項１０に記載のコンピューターシステム。
前記第１の受け手銀行と前記第２の送り手銀行は同じ銀行であり、
前記トークン化取引から受けとったトークン群は前記トークン取引に使用される、請求項１１に記載のコンピューターシステム。
前記１つ又は複数のプロセッサ又はサーバは更に前記第２の受け手銀行からの前記トークン群を現金化するための現金化依頼に応じて前記第２の受け手銀行の口座の残高を更新する、請求項１２に記載のコンピューターシステム。
前記中央銀行のコンピューターシステムのメモリ内に保存された、前記第１の受け手銀行及び前記第２の送り手銀行である銀行の口座の残高は前記第１及び第２の取引の間は更新されない、請求項１３に記載のコンピューターシステム。
１つ又は複数のプロセッサ又はサーバを含むコンピューターシステムにより実行され次第以下のステップ群が実行されるのを可能にする命令群をその上に含む有形の非一時的コンピューター読み取り可能媒体であって、前記ステップ群は
中央銀行のメインチェーンにおいて、前記中央銀行の中央コンピューターシステムとそれぞれ前記中央銀行に口座を有する少なくとも送り手銀行及び受け手銀行のコンピューターシステムとの間にプライベートサイドチェーンを確立し、
前記送り手銀行のコンピューターシステムから取引を支払依頼として受け取り、
前記取引が有効かどうかを判断し、
前記取引のファイナリティプルーフを提供するためのコンセンサスプロトコルを採用し、
前記受け手銀行のコンピューターシステムに前記取引を前記ファイナリティプルーフとともに転送し、
前記メインチェーンにおいて前記送り手銀行及び前記受け手銀行の口座を更新し前記プライベートサイドチェーン内でのみアクセス可能な秘匿台帳に前記取引を加える、ことを含む媒体。