特表 2024-536705 ブロックチェーンのコンセンサス方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-10-08

(54)【発明の名称】ブロックチェーンのコンセンサス方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20241001BHJP

【ＦＩ】

H04L9/32 200Z

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024513320

(86)(22)【出願日】2021-08-26

(85)【翻訳文提出日】2024-02-22

(86)【国際出願番号】 EP2021073692

(87)【国際公開番号】W WO2023025394

(87)【国際公開日】2023-03-02

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡ

(71)【出願人】

【識別番号】524069938

【氏名又は名称】テラドクサ ソシエテ パ アクシオンス シンプリフィエ

(74)【代理人】

【識別番号】110002848

【氏名又は名称】弁理士法人ＮＩＰ＆ＳＢＰＪ国際特許事務所

(72)【発明者】

【氏名】ペセンティ，エマニュエル

(72)【発明者】

【氏名】ジャクジュド，アブデスラム

(57)【要約】

複数のノードを有する分散ネットワークを含むブロックチェーンにおけるコンセンサスのための方法であって、複数のノードは、１つの管理ノード「ＡＮ」と、１つの選出ノード「ＥＮ」と、複数のレギュラーノード「ＲＮ」とを含み、ＡＮ、ＥＮ、及びＲＮの各々は、仮想マシン「ＶＭ」と、ＶＭ上で実行されるチェッカサービスと、チェッカサービス上で読み取り及び／又は実行権を有する他のノードに利用可能なチェッカアカウントとを有し、ブロックチェーンにトランザクションを提供するプロバイダノード「ＰＮ」を更に含み、本方法は、（ｉ）ＡＮによって、複数のＲＮの中からＥＮを選出する工程と、（ｉｉ）ＥＮによって、ＰＮからトランザクションを受信する工程と、（ｉｉｉ）各受信されたトランザクションについて、ＥＮのチェッカアカウントを通じてＥＮのチェッカサービスの実行する工程と、（ｉｖ）ＥＮによって、チェックされたトランザクションを含むブロックを生成する工程と、（ｖ）ＥＮによって、生成されたブロックを複数のＲＮに送信する工程と、（ｖｉ）生成されたブロックを認証するために、生成されたブロックのチェッカアカウントを通じてＥＮのチェッカサービスの実行する工程とを含む。

【特許請求の範囲】

【請求項1】

複数のノードを有する分散ネットワークを含むブロックチェーンにおけるコンセンサスのための方法であって、
前記複数のノードは、１つの管理ノード「ＡＮ」と、１つの選出ノード「ＥＮ」と、複数のレギュラーノード「ＲＮ」とを含み、前記ＡＮ、前記ＥＮ、前記ＲＮの各々が、仮想マシン「ＶＭ」、前記ＶＭ上で実行されるチェッカサービスと、前記チェッカサービス上で読み取り及び／又は実行権を有する他のノードに利用可能なチェッカアカウントとを有し、
前記ブロックチェーンにトランザクションを提供するプロバイダノード「ＰＮ」を更に含み、
前記方法が、
前記ＡＮによって、前記複数のＲＮの中から前記ＥＮを選出する工程と、
前記ＥＮによって、ＰＮからトランザクションを受信する工程と、
各受信されたトランザクションについて、前記ＥＮの前記チェッカサービスを前記ＥＮのチェッカアカウントを通じて実行する工程と、
前記ＥＮによって、前記チェックされたトランザクションを含むブロックを生成する工程と、
前記ＥＮによって、前記生成されたブロックを前記複数のＲＮに送信する工程と、
前記生成されたブロックを認証するために、前記ＥＮの前記チェッカサービスを、前記生成されたブロックについて、前記ＥＮのチェッカアカウントを通じて実行する工程とを含む、コンセンサスのための方法。

【請求項2】

各受信されたトランザクションに対する前記チェッカサービスの前記実行する工程は、前記複数のＲＮのうちの少なくとも１つのＲＮ又は任意の外部ノード「ＥｘＮ」によって実行され、前記生成されたブロックに対する前記チェッカサービスの前記実行する工程は、前記複数のＲＮによって実行される、請求項１に記載のブロックチェーンにおけるコンセンサスのための方法。

【請求項3】

方法であって、各前記ＡＮノード、前記ＥＮノード、前記ＲＮノードは、前記チェッカサービス及び少なくとも１つの工程チェックサービスを含む所定のサービスを更に有し、すべての所定のサービスは前記ＶＭ上で実行され、前記チェッカサービスを実行する工程は、
前記ＥＮの前記工程チェッカサービスを実行して、前記ＥＮのＶＭ上で実行中のサービスのリストを取り出す工程と、
前記実行中のサービスのリストと前記所定のサービスのリストとが一致したときに、前記実行中のサービスを検証する工程とを含む、請求項１又は２に記載のコンセンサスのための方法。

【請求項4】

方法であって、各前記ＡＮノード、前記ＥＮノード、前記ＲＮノードは、ハッシュサービスを更に含む前記所定のサービスの１つ以上のローカル実行可能ファイルを有し、前記チェッカサービスを実行する工程は、
信頼できるブロックチェーンリポジトリに記憶された前記所定のサービスの信頼できるソースコードをダウンロードする工程と、
信頼できるソースコードをコンパイルして、１つ以上の信頼できる実行可能ファイルを取得する工程と、
前記ハッシュサービスによって、前記１つ以上の信頼できる実行可能ファイルをハッシュして、少なくとも１つの信頼できるハッシュ値を取得する工程と、
前記ハッシュサービスによって、前記１つ以上のローカル実行可能ファイルをハッシュして、少なくとも１つのローカルハッシュ値を取得する工程と、
前記１つ以上のローカルハッシュ値と前記１つ以上の信頼できるハッシュ値とが一致するとき、前記１つ以上のローカル実行可能ファイルを検証する工程と、又は
前記１つ以上のローカルハッシュ値と前記１つ以上の信頼できるハッシュ値とが一致しないとき、前記ＡＮに、危険にさらされたＥＮ（「ＥＮＣ」）信号を送信する工程とを更に含む、請求項３に記載のコンセンサスのための方法。

【請求項5】

方法であって、前記所定のサービスは、エクストラクタサービスを更に含み、前記ＡＮがＥＮＣ信号を受信するとき、前記実行する工程は、
前記ＡＮによって、前記ＥＮＣ信号を確認するために前記ＥＮの前記チェッカサービスを使用する工程と、確認されたＥＮＣ信号の場合、
前記ＡＮによって、前記危険にさらされたＥＮの前記エクストラクタサービスを使用して、チェックされたトランザクションを取り出す工程と、
危険にさらされたＥＮを分散ネットワークから切断する工程と、
新しい選出する工程を開始する工程とを更に含む、請求項４に記載のコンセンサスのための方法。

【請求項6】

方法であって、前記ブロックを生成する工程は、所定の条件の検出時に実行され、前記所定の条件は、
所定数のトランザクションがチェックされたとき、又は
前記選出する工程から所定の時間間隔が経過したときである、請求項１から５のいずれか一項に記載のコンセンサスのための方法。

【請求項7】

前記生成されたブロックの認証の後に、前記方法は、
新しい選出する工程にループする前に、前記ＥＮを前記新しいＡＮとして指定する工程を更に含む、請求項１から６のいずれか一項に記載のコンセンサスのための方法。

【請求項8】

前記チェッカサービスを実行する工程は、規則的な時間間隔で更に実行される、請求項１から７のいずれか一項に記載のブロックチェーンにおけるコンセンサスのための方法。

【請求項9】

前記ＥＮが破損していないことをチェックするために、前記チェッカサービスを実行する工程が、前記ＡＮによる前記選出する工程の直後に更に実行される、請求項１から８のいずれか一項に記載のブロックチェーンにおけるコンセンサスのための方法。

【請求項10】

前記ＥＮが前記分散ネットワークにおいてもはや利用可能でないときはいつでも、前記ＡＮが新しい選出する工程を処理する、請求項１から９のいずれか一項に記載のブロックチェーンにおけるコンセンサスのための方法。

【請求項11】

方法であって、前記選出する工程は、
前記ＡＮによって、前記複数のＲＮから選出情報を要求する工程と、
前記ＡＮによって、前記要求された選出情報に基づいて、前記複数のＲＮの中から前記ＥＮを選出する工程とを含む、請求項１から１０のいずれか一項に記載のコンセンサスのための方法。

【請求項12】

前記選出情報は、ＲＮが既に選出された回数に対応する選出発生回数「ＥＯＮ」を少なくとも含む、請求項１１に記載のブロックチェーンにおけるコンセンサスのための方法。

【請求項13】

前記選出する工程は、前記ＥＮを決定するために少なくとも１つの乱数を使用する非決定論的選出アルゴリズムに基づく、請求項１２に記載のブロックチェーンにおけるコンセンサスのための方法。

【請求項14】

方法であって、各前記ＡＮノード、前記ＥＮノード、前記ＲＮノードは、一意の識別番号「ＵＩＮ」、そのＥＯＮ、及び公開／秘密鍵のセットによって識別され、前記選出する工程は、
各前記ＲＮによって、そのＵＩＮ、そのＥＯＮ、及びその公開鍵を前記ＡＮに提供する工程と、
前記ＡＮによって、前記ＲＮをそれらのＥＯＮによってランク付けし、各前記ＲＮを前記ＥＯＮに応じた間隔に関連付ける工程と、
前記ＡＮによって、前記前のＡＮから乱数を受信する工程と、
前記ＡＮによって、前記ＵＩＮ及び前記ＥＯＮの関数を計算し、前記計算された関数結果をハッシュし、前記ＡＮ秘密鍵を用いて前記ハッシュされた関数結果を暗号化し、前記暗号化された関数結果及び前記提供された乱数の関数を計算して最終的な数を得る工程と、
前記最終的な数で前記ＲＮ間隔をトラバースし、前記ＥＮになる１つのＲＮだけが残るまで、遭遇する前記対応するＲＮを漸進的に削除する工程からなる工程とを少なくとも含む、請求項１３に記載のコンセンサスのための方法。

【請求項15】

前記ブロックチェーンコンセンサスは、トランザクションと呼ばれる共有データを含む分散型台帳技術「ＤＬＴ」であり、共有データは特定のＩＤタイプのデータであり、前記方法は、
要求に応じて、信頼できる第三者によってスマートコントラクトを介して前記特定のＩＤタイプデータを認証する工程を更に含む、請求項１から１４のいずれか一項に記載のコンセンサスのための方法。

【請求項16】

複数のノードを有するブロックチェーン分散ネットワークであって、前記複数のノードが、
１つの管理ノード「ＡＮ」と、１つの選出ノード「ＥＮ」と、複数のレギュラーノード「ＲＮ」とを含み、前記ＡＮ、前記ＥＮ、前記ＲＮの各々が、仮想マシン「ＶＭ」と、前記ＶＭ上で実行されるチェッカサービスと、前記チェッカサービス上で読み取り及び／又は実行権を有する他のノードに利用可能なチェッカアカウントとを有し、前記ブロックチェーン分散ネットワークにトランザクションを提供するプロバイダノード「ＰＮ」を更に含み、
請求項１から１５のいずれか一項に記載のブロックチェーンコンセンサス方法が前記ブロックチェーン分散ネットワークに適用される、ブロックチェーン分散ネットワーク。

【請求項17】

プロセッサ及びメモリを備える電子デバイスであって、前記メモリは、前記所定のサービスの前記ソースコードを記憶するために使用され、前記プロセッサは、請求項１から１５のいずれか一項に記載の方法を実行するために、前記メモリに記憶された前記ソースコードを呼び出す前記仮想マシンをホストするように構成される、電子デバイス。

【請求項18】

コンピュータ可読記憶媒体であって、命令が前記コンピュータ可読記憶媒体に記憶され、前記命令がコンピュータ上で実行されるときに、前記コンピュータが請求項１から１５に記載の方法を実行する、コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ブロックチェーン技術の分野に関し、特にブロックチェーンコンセンサス方法に関する。

【0002】

本発明は、より詳細には、分散型台帳技術を介したアイデンティティ管理へのそのようなブロックチェーンコンセンサス方法の適用に関する。

【背景技術】

【0003】

分散型台帳技術とも呼ばれるブロックチェーン技術は、いくつかのコンピューティングデバイスが、完全な分散データベースを共同で維持するために「台帳」を保持することに参加する新興技術である。ブロックチェーン技術は、分散化、開放性、及び透明性によって特徴付けられ、また、ブロックチェーン技術では、各コンピューティングデバイスがデータベース記録に参加することができ、コンピューティングデバイス間でデータを迅速に同期させることができる。したがって、ブロックチェーン技術は、多くの分野に広く適用されている。

【0004】

「Ａｎａｌｙｓｉｓ ｏｆ ｔｈｅ ｍａｉｎ ｃｏｎｓｅｎｓｕｓ ｐｒｏｔｏｃｏｌｓ ｏｆ ｂｌｏｃｋｃｈａｉｎ」は、２０１９年８月１２日にオンラインで入手可能なＳｈｉｊｉｅ Ｚｈａｎｇらの論文に示されている。この論文では、計算能力に基づくＰｏＷ（Ｐｒｏｏｆ ｏｆ Ｗｏｒｋ）及び持ち込まれた保有されたステークに基づくＰｏＳ（Ｐｒｏｏｆ ｏｆ Ｓｔａｋｅ）などの最も一般的なコンセンサスが提示されている。

【0005】

既存の各コンセンサスは、いくつかの制限を提示する。ＰｏＷは、最も多くの計算能力と、１秒当たりのトランザクションスループットとを消費し、これは、ＰｏＷのアプリケーション見込みを大きく制限する。ＰｏＳは、計算能力の消費を大幅に低減することができるが、その一方で、その検証と引き換えに計算作業を必要としないので、ＰｏＷと同じレベルのセキュリティを構造的に提供することができないという同様の欠点を有する。

【0006】

更に、ＰｏＳプロトコルは、ｎｏｔｈｉｎｇ－ａｔ－ｓｔａｋｅ問題に悩まされる可能性があり、この場合、検証者ノードは、そうするためのコストが最小限であり、謝ったチェーン上のブロックを検証することによって報酬を失う機会の可能性が低いので、ブロックチェーンの競合するコピーを検証する。

【0007】

本開示は、従来技術に対して状況を改善する。特に、本開示の目的は、分散ブロックに記録されたトランザクションの高いセキュリティ及び認証を保証する一方で、通常のブロックチェーンシステムが行うように、システムによって消費される高いエネルギーを有することなく、かつｎｏｔｈｉｎｇ－ａｔ－ｓｔａｋｅ問題を回避して、すべてのノードが同じコンテンツを保有することを保証することである。

【発明の概要】

【0008】

本開示の第１の態様は、複数のノードを有する分散ネットワークを含むブロックチェーンにおけるコンセンサスのための方法であって、複数のノードは、１つの管理ノード「ＡＮ」と、１つの選出ノード「ＥＮ」と、複数のレギュラーノード「ＲＮ」とを含み、ＡＮ、ＥＮ、及びＲＮの各々は、仮想マシン「ＶＭ」と、ＶＭ上で実行されるチェッカサービスと、チェッカサービスに対する権限を読み出し及び／又は実行する他のノードに利用可能なチェッカアカウントとを有し、ブロックチェーンにトランザクションを提供するプロバイダノード「ＰＮ」を更に含み、本方法は、
ＡＮによって、複数のＲＮの中からＥＮを選出する工程と、
ＥＮによって、ＰＮからトランザクションを受信する工程と、
各受信されたトランザクションについて、ＥＮのチェッカサービスをＥＮのチェッカアカウントを通じて実行する工程と、
ＥＮによって、チェックされたトランザクションを含むブロックを生成する工程と、
ＥＮによって、生成されたブロックを複数のＲＮに送信する工程と、
生成されたブロックを認証するために、ＥＮのチェッカサービスを、生成されたブロックについて、ＥＮのチェッカアカウントを通じて実行する工程とを含む、方法に関する。

【0009】

そのようなコンセンサス方法は、一度に新しいブロックを構築する１つのノード、すなわちＥＮのみが存在するので、非常に少ない電力消費を要求し、一方で、チェッカサービス及びチェッカアカウントのおかげで高レベルのセキュリティを保証し、任意の他のノードによって構築しながらＥＮの直接的かつ永続的な可用性を可能にする。各トランザクションは、生成されたときにブロックと同様にチェックされる。

【0010】

有利には、各受信されたトランザクションについてチェッカサービスを実行する工程は、複数のＲＮのうちの少なくとも１つのＲＮ又は任意の外部ノードのいずれかによって実行され、生成されたブロックに対するチェッカサービスを実行する工程は、複数のＲＮによって実行される。

【0011】

任意のノードによって各新しいトランザクションをチェックすることは、柔軟性を与え、同時に、複数のＲＮによって生成されたブロックをチェックする間のセキュリティは、ブロックチェーン内の新しいブロックを解放する前に、より高いセキュリティレベルを提供する。

【0012】

有利には、各ＡＮノード、ＥＮノード、ＲＮノードは、チェッカサービス及び少なくとも１つの工程チェックサービスを含む所定のサービスを更に有し、すべての所定のサービスはＶＭ上で実行され、チェッカサービスを実行する工程は、
工程チェッカサービスを実行して、ＶＭ上で実行中のサービスのリストを取り出す工程と、
実行中のサービスのリストと所定のサービスのリストとが一致したときに、実行中のサービスを検証する工程とを含む。

【0013】

そのような工程チェッカサービスは、ＶＭ上のすべての実行中のサービスが所定のサービスのみであることを保証し、したがって未知のサービスがＶＭ上で実行されることを防止することによって、実行する工程を強化する。

【0014】

有利には、各ＡＮノード、ＥＮノード、ＲＮノードは、ハッシュサービスを更に含む所定のサービスの１つ以上のローカル実行可能ファイルを有し、チェッカサービスを実行する工程は、
信頼できるブロックチェーンリポジトリに記憶された所定のサービスの信頼できるソースコードをダウンロードする工程、
信頼できるソースコードをコンパイルして、１つ以上の信頼できる実行可能ファイルを取得する工程、
ハッシュサービスによって、１つ以上の信頼できる実行可能ファイルをハッシュして、少なくとも１つの信頼できるハッシュ値を取得する工程、
ハッシュサービスによって、１つ以上のローカル実行可能ファイルをハッシュして、少なくとも１つのローカルハッシュ値を取得する工程、
１つ以上のローカルハッシュ値と１つ以上の信頼できるハッシュ値とが一致するとき、１つ以上のローカル実行可能ファイルを検証する工程、又は
１つ以上のローカルハッシュ値と１つ以上の信頼できるハッシュ値とが一致しないとき、ＡＮに、危険にさらされたＥＮ（「ＥＮＣ」）信号を送信する工程を更に含む。

【0015】

そのようなハッシュサービスは、ＶＭ上のすべての実行中のサービスが各所定のサービスのためのソースコードの最新の利用可能なバージョンを使用することを保証することによって、実行する工程のセキュリティを更に強化し、その結果、それは破損したコードを含まない。

【0016】

有利には、所定のサービスは、エクストラクタサービスを更に含み、ＡＮがＥＮＣ信号を受信するとき、実行する工程は、
ＡＮによって、ＥＮＣ信号を確認するためにＥＮのチェッカサービスを使用する工程と、確認されたＥＮＣ信号の場合、
ＡＮによって、危険にさらされたＥＮのエクストラクタサービスを使用して、チェックされたトランザクションを取り出す工程と、
危険にさらされたＥＮを分散ネットワークから切断する工程と、
新しい選出する工程を開始する工程とを更に含む。

【0017】

このようなエクストラクタサービスは、危険にさらされたノードを分離し、危険にさらされる前にトランザクションを取り出すことによって、実行する工程のセキュリティを更に強化する。

【0018】

有利には、生成する工程の所定の条件の検出は、
所定数のトランザクションがチェックされたとき、又は
選出する工程から所定の時間間隔が経過したときに行われる。

【0019】

そのような所定の条件は、生成されたブロックに含まれるトランザクションの数、又は２つの連続するブロックの生成間の時間のいずれかに関して、生成する工程が長く続くことを防止し、したがって、ＥＮを攻撃するためのフレームを低減する。

【0020】

有利には、生成されたブロックの認証の後、本方法は、新しい選出する工程にループする前に、ＥＮを新しいＡＮとして指定する工程を更に含む。

【0021】

ＥＮを次のブロック生成のための新しいＡＮとして指定することは、ＥＮが連続して２回選出されることを防止し、したがって、ＥＮの外部制御のリスクを更に低減する。

【0022】

有利には、チェッカサービスを実行する工程は、規則的な時間間隔で更に実行される。

【0023】

チェッカサービスの定期的なチェックを導入することは、ＥＮに対する攻撃のためのフレームを更に狭める。

【0024】

有利なことに、チェッカサービスを実行する工程は、ＥＮが破損していないことをチェックするために、ＡＮによる選出する工程の直後に更に実行される。

【0025】

選出直後のチェッカサービスのそのような初期チェックは、ＥＮが実行する工程の開始から安全であることを保証する。

【0026】

有利なことに、ＡＮは、ＥＮが分散ネットワークにおいてもはや利用可能でないときはいつでも、新しい選出する工程を処理する。

【0027】

ＥＮが分散ネットワークから消失した場合（例えば、接続の欠如）、ＡＮは、新しい選出を処理して、切断されたＥＮが突然再び現れてブロック生成を実行することを防止する。

【0028】

有利には、選出する工程は、ＡＮによって、複数のＲＮから選出情報を要求する工程と、ＡＮによって、要求された選出情報に基づいて複数のＲＮの中からＥＮを選出する工程とを含む。より好ましくは、選出情報は、ＲＮが既に選出された回数に対応する選出発生回数「ＥＯＮ」を少なくとも含む。

【0029】

選出工程における基準を有するＥＯＮを使用することは、しばしば選出されたＲＮが、より低いＥＯＮを有する別のＲＮに対して、次のＥＮになる可能性が低くなることを保証する。過去のブロック生成を考慮したＲＮの信頼性、その位置、ノードのより大きなグループへの依存性、実行されるトランザクションの量など、他の基準を使用することができる。

【0030】

有利には、選出する工程は、ＥＮを決定するために少なくとも１つの乱数を使用する非決定論的選出アルゴリズムに基づく。より好ましくは、各ＡＮノード、ＥＮノード、ＲＮノードは、一意の識別番号「ＵＩＮ」、そのＥＯＮ、及び公開／秘密鍵のセットによって識別され、選出する工程は、
各ＲＮによって、そのＵＩＮ、そのＥＯＮ、及びその公開鍵をＡＮに提供する工程、
ＡＮによって、ＲＮをそれらのＥＯＮによってランク付けし、各ＲＮをＥＯＮに応じた間隔に関連付ける工程、
ＡＮによって、前のＡＮから乱数を受信する工程、
ＡＮによって、ＵＩＮ及びＥＯＮの関数を計算し、計算された関数結果をハッシュし、ＡＮ秘密鍵を用いてハッシュされた関数結果を暗号化し、暗号化された関数結果及び提供された乱数の関数を計算して最終的な数を得る工程、
この最終的な数でＲＮ間隔をトラバースし、ＥＮになる１つのＲＮだけが残るまで、遭遇する対応するＲＮを漸進的に削除する工程からなる工程を少なくとも含む。

【0031】

そのような選出工程は、アカウントのステークが公開されており、各ノードが、どのアカウントがブロックチェーン内の追加のブロックを構築する権限を獲得するかを合理的な精度で予測することができる公式を使用するいくつかの暗号通貨とは異なり、次のＥＮを事前に知ることができないことを保証するために使用される。

【0032】

有利には、ブロックチェーンコンセンサスは、トランザクションと呼ばれる共有データを含む分散型台帳技術「ＤＬＴ」である。より好ましくは、共有データは特定のＩＤタイプのデータである。

【0033】

このようなＤＬＴは、多くの異なる分野に適用することができる。１つの興味深いアプリケーションは、ＩＤタイプデータがＤＬＴに安全に記憶され、許可されると容易にアクセスされ得るアイデンティティ管理である。

【0034】

有利なことに、特定のＩＤタイプデータは、スマートコントラクトを介して信頼できる第三者による要求に応じて認証される。

【0035】

本開示の別の態様は、複数のノードを有するブロックチェーン分散ネットワークであって、複数のノードは、１つの管理ノード「ＡＮ」と、１つの選出ノード「ＥＮ」と、複数のレギュラーノード「ＲＮ」とを含み、ＡＮ、ＥＮ、ＲＮの各々は、仮想マシン「ＶＭ」と、ＶＭ上で実行されるチェッカサービスと、チェッカサービス上で読み取り及び／又は実行権を有する他のノードに利用可能なチェッカアカウントとを有し、分散ネットワークのブロックチェーンにトランザクションを提供するプロバイダノード「ＰＮ」を更に含み、第１の態様によるブロックチェーンコンセンサス方法は、ブロックチェーン分散ネットワークに適用される、ブロックチェーン分散ネットワークに関する。

【0036】

本開示の別の態様は、プロセッサとメモリとを備える電子デバイスに関し、メモリは、所定のサービスのソースコードを記憶するために使用され、プロセッサは、第１の態様による方法を実行するために、メモリに記憶されたソースコードを呼び出す仮想マシンをホストするように構成される。

【0037】

コンピュータ可読記憶媒体であって、命令がコンピュータ可読記憶媒体に記憶され、命令がコンピュータ上で実行されるとき、コンピュータが第１の態様による方法を実行する、コンピュータ可読記憶媒体。

【図面の簡単な説明】

【0038】

本開示の他の特徴、目的、及び利点は、添付の図面を参照してなされた非限定的な実施形態の詳細な記述を読むことによってより明確になるであろう。

【0039】

【図1】本開示によるノードのピアツーピアネットワークのネットワークの一例を示す。

【0040】

【図2A】本開示によるブロックチェーンノードのアーキテクチャの一例を示す。

【0041】

【図2B】本開示によるブロックチェーンノードのチェッカアカウントの一例を示す。

【0042】

【図3】本開示の一実施形態によるコンセンサス方法の図を示す。

【0043】

【図4】本開示の別の実施形態によるコンセンサス方法の図を示す。

【0044】

【図5】コンセンサス方法中に発信される破損通知の場合の図を示す。

【0045】

【図6】本開示による選出工程の例示的な図を示す。

【発明を実施するための形態】

【0046】

分散型台帳技術、「ＤＬＴ」又はデータベースは、ピアツーピアネットワーク上のいくつかのノード（デバイス）にわたって分散され、各々は、台帳の同一のコピーを複製及び保存し、それ自体を独立して更新する。主な利点は、中央権限が欠如していることである。

【0047】

コンセンサスメカニズムは、そのような分散コンピュータ、すなわち、ピアツーピアネットワークにわたって合意、信頼、及びセキュリティを達成するために使用される任意の数の方法論を指す。

【0048】

本開示は、ブロックを構築するときのエネルギー消費を制限するためのブロックチェーンのノードへの役割帰属工程と、分散データの認証及びセキュリティを保証するための特定のソフトウェア工程とを有する、「アイデンティティ」タイプのトランザクションを扱うブロックチェーンアイデンティティ管理システムを説明する。当然ながら、このブロックチェーン管理システム及び特定のソフトウェア工程では、他のタイプのトランザクションも可能である。

【0049】

図１は、本開示によるノードのピアツーピアネットワークの一例を示す。アイデンティティ管理システムを構成するネットワークは、３種類のノード、すなわち、１つの管理ノード「ＡＮ」と、１つの選出ノード「ＥＮ」と、複数のレギュラーノード「ＲＮ」とを含む。各種類のノードは、以下に簡単に要約されるそれ自体の役割を有する。

【0050】

ＡＮ（ネットワーク内の唯一のノード）は、特定の選出工程を介して、それらのうちの１つが（唯一の）ＥＮであるように選出するために、ＲＮからの情報を必要とする。

【0051】

ＥＮは、選出されると、プロバイダ又はプロバイダノード「ＰＮ」から新しいトランザクションを受信する。各受信されたトランザクションを検証するために、ＥＮ上でチェッカ工程が行われる。次に、ＥＮは、受信されたトランザクションを構築中の新しいブロックに追加する。そうすることによって、ＥＮは、例えば、受信されたトランザクションの数によって定義される新しいブロックの完了まで、又はその選出から所定の時間が経過するまで、着信トランザクションを収集する。例えば、可変時間間隔は、ネットワーク上のトラフィック量に応じて１５分から６０分の間に設定される。１５分は、より高いトラフィックに対して選択され、６０分は、より低いトラフィックに対して選択される。新しいブロックが完了すると、ＥＮは、認証の目的で、生成されたブロックを他のすべてのＲＮに送信する。ＥＮは、新しいブロックを生成した後にＡＮになり、新しいＡＮとして次の選出を編成し始める。

【0052】

ＲＮは、ＡＮでもＥＮでもないピアツーピアネットワークのすべてのノード部分である。それらのすべては、それらが選出された場合にＥＮになり、次いで、それらがブロック生成を完了した後にＡＮになることができる。ネットワーク内に存在する各ＲＮは、潜在的に選出されるように、選出工程の前に選出情報をＡＮに提供する。これらのＲＮはまた、新たに生成されたブロックを認証するためだけでなく、各新しいトランザクションをチェックするためにも使用される。

【0053】

ＰＮは、ピアツーピアネットワークの直接の一部ではない。それらは、ＥＮに新しいトランザクションを提供するだけである。（１つ又は複数の）外部ノード「ＥｘＮ」は、レギュラーノードではないが、ＥＮのチェッカサービスを実行する工程をいつでも、特に各新たに受信されたトランザクションについて実行するために使用することができるノードである。

【0054】

図２Ａは、本開示によるブロックチェーンノード（ＡＮ、ＥＮ、又はＲＮのいずれか）のアーキテクチャの一例を示す。ネットワークの各ノード、ＡＮ、ＥＮ又はＲＮは、専用ソフトウェアインストール工程を有する。

【0055】

この工程は、仮想マシン「ＶＭ」と、ＶＭ上で実行される制限された数のサービスとのインストールを必要とする。これらのサービスは、少なくとも、許可されたサービスのみがＶＭ上で実行されていることを保証する「チェッカサービス」と、ＡＮ及びＲＮ並びに外部ノード及びＰＮに利用可能な「チェッカアカウント」とを含み、インストールされたサービスのパックに対する読み取り／実行権を与えるチェッカ工程を含む。このようにして、任意の外部ノードは、ノードが破損していないことを自由にチェックすることができる。各受信されたトランザクションについて、少なくとも１つのＲＮは、ＥＮのチェッカアカウントを通じてＥＮのチェッカサービスを実行して、トランザクションの有効性をチェックする。当然ながら、いくつかのＲＮがＥＮのチェッカサービスを実行してもよい。新しい生成されたブロックに対して、複数のＲＮは、ブロックを認証するためにそのチェッカアカウントを通じてＥＮのチェッカサービスを実行する。

【0056】

サブレイヤアーキテクチャの場合、一例として、各ノードは、ブロックチェーンノードのＪａｖａアプリケーションが実行可能なｊａｒモードで展開され、アプリケーションのｊａｒが、好ましくはチェッカサービス、工程チェックサービス、ハッシュサービス、及びエクストラクタサービスを含む４つの、決定されたシェルスクリプトの所定のパックとともにディレクトリに記憶されるように、Ｊａｖａ ＶＭを含む。ノードは更にソフトウェアユーティリティＣＲＯＮを含み、これは時間ベースのジョブスケジューラであり、チェッカ工程を実行するために使用される。Ｌｉｎｕｘ（登録商標）などのＵＮＩＸ（登録商標）のようなオペレーティングシステム「ＯＳ」、及びＯＳ上で実行される工程管理が、サブレイヤアーキテクチャを完成させる。

【0057】

図２Ｂは、チェッカ工程を実行するときの、図２Ａに提示されたブロックチェーンノードのチェッカアカウントの好ましい実施形態を示す。各ノード（ＡＮ、ＥＮ、ＲＮ）は、４つのサービス、すなわち、チェッカサービス（すなわち、ｃｈｅｃｋｅｒ．ｓｈスクリプト）、工程チェックサービス（すなわち、ｐｒｏｃｅｓｓ＿ｃｈｅｃｋ．ｓｈスクリプト）、ハッシュサービス（すなわち、ｈａｓｈ．ｓｈスクリプト）、エクストラクタサービス（すなわち、ｅｘｔｒａｃｔｏｒ．ｓｈスクリプト）を含む実行可能ファイルの形式で所定のサービスのパックを有する。チェッカアカウントは、デフォルトで、（１つ又は複数の）実行可能ファイル（例えば、（１つ又は複数の）ｊａｒファイル）及びスクリプトが配置されているフォルダに作成される。
チェッカアカウントは、すべてのファイルに対して「読み取り」権限を有し、抽出スクリプトを除くすべてのスクリプトに対して「実行」権限を有し、「書き込み」権限を有さない。チェッカアカウントはパスワードを有さず、インターネットアクセスを有する任意の人又はノード（例えば、ＲＮ、ＰＮ、又はＥｘＮ）は、ＥＮのチェッカアカウントを介してブロックチェーンにアクセスし、その準拠性をテストすることができ、したがって、ブロック生成を引き継ぐノードの真正性を自動的に保証する。スクリプトはルートユーザに属し、どのユーザも、ＶＭにおいて管理モード（ｓｕｄｏｅｒｓ）で実行する権限を有さない。スクリプトの作成者はルートであるので、誰もそれらを修正することはできないが、チェッカユーザはそれらを読み取って実行する権限を有する。更に、それらは管理者レベルのクリアランスへのアクセスを与えるｓｕｄｏ特権を有していない。

【0058】

工程チェッカサービスは、ＶＭ上で実行中のサービスのリストを取り出し、実行中のサービスのリストが所定のサービスのパックのリストに対応することを検証することによって、所定のパックのサービスのみが実行中であることを保証するために使用される。

【0059】

ハッシュサービスは、ｊａｒアプリケーションの内容をハッシュし、結果を表示する命令を含む。

【0060】

チェッカサービスは、周期的に、又はノード（ＣＲＯＮタスク）からの要求に応じて実行され、（ｉ）ＥＮの工程チェッカサービスを実行して、ＥＮのＶＭ上で実行中のサービスのリストを取り出す工程と、（ｉｉ）実行中のサービスのリストと所定のサービスのリストとが一致したときに実行中のサービスを検証する工程とを保証する。より具体的には、チェッカサービスは、（ｉ）信頼できるブロックチェーンリポジトリに記憶された所定のサービスの信頼できるソースコードをダウンロードする工程と、（ｉｉ）信頼できるソースコードをコンパイルして、１つ以上の信頼できる実行可能ファイルを取得する工程と、（ｉｉｉ）ハッシュサービスによって、１つ以上の信頼できる実行可能ファイルをハッシュして、少なくとも１つの信頼できるハッシュ値を取得し、１つ以上のローカル実行可能ファイルをハッシュして、少なくとも１つのローカルハッシュ値を取得する工程と、（ｉｖ）１つ以上のローカルハッシュ値と１つ以上の信頼できるハッシュ値とが一致するとき、１つ以上のローカル実行可能ファイルを検証するか、又は１つ以上のローカルハッシュ値と１つ以上の信頼できるハッシュ値とが一致しないとき、危険にさらされたＥＮ「ＥＮＣ」信号をＡＮに送信する工程とを実行する。

【0061】

チェッカサービスが周期的に実行されるという事実に加えて、チェッカサービスは、ブロックに到着する選出及びすべてのトランザクションの後にも実行される。これは、偽のノードにハンドが与えられないことを保証する。

【0062】

好ましくは、チェッカサービスは、現在のサービスのソースのハッシュがそのようなサービスの最新の利用可能なバージョンのハッシュと同一であることをチェックするために、数行のコードの非常に単純なプログラムとしてコーディングされる。

【0063】

チェッカサービスコードの例
＃！／ｂｉｎ／ｂａｓｈ
ｅｘｐｏｒｔ ｓｉｇｎａｔｕｒｅ＝｀ｍｄ５ｓｕｍ ｔｄｘｂｃ／ｋｎｉｇｈｔ．ｊａｒ｀
ｅｘｐｏｒｔ ＬＯＣＡＬ＿ＳＩＧ＝＄｛ｓｉｇｎａｔｕｒｅ％％ ^＊｝
ｍｋｄｉｒ ｔｅｍｐ＿ｓｒｃ
ｃｄ ｔｅｍｐ＿ｓｒｃ
ｇｉｔ ｃｌｏｎｅ＜ｒｅｐｏｓｉｔｏｒｙ＿ｕｒｌ＿ｈｅｒｅ＞
ｃｄ＜ｒｅｐｏｓｉｔｏｒｙ＿ｎａｍｅ＞
ｍｖｎ ｃｌｅａｎ ｉｎｓｔａｌｌ
ｅｘｐｏｒｔ ｓｉｇｎａｔｕｒｅ＝｀ｍｄ５ｓｕｍ
＜ｒｅｐｏｓｉｔｏｒｙ＿ｎａｍｅ＞／ｔａｒｇｅｔ／ｋｎｉｇｈｔ＿１．０．０．ｊａｒ｀
ｅｘｐｏｒｔ ＤＩＳＴ＿ＳＩＧ＝＄｛ｓｉｇｎａｔｕｒｅ％％ ^＊｝
ｉｆ［“＄ＤＩＳＴ＿ＳＩＧ”＝“＄ＬＯＣＡＬ＿ＳＩＧ”］；ｔｈｅｎ
ｅｃｈｏ“０”＃ Ａｌｌ ｉｓ ｇｏｏｄ
ｅｌｓｅ
ｅｃｈｏ“１”＃ Ｓｉｇｎａｔｕｒｅｓ ａｒｅ ｎｏｔ ｅｑｕａｌ
ｅｎｄ

【0064】

エクストラクタサービスは、（１つ又は複数の）実行可能ファイルをバイパスすることによって、このブロックチェーンのすべてのレコードを復元することを可能にする。それは、ノードの埋め込まれたデータベースに接続するために必要なコマンドからなる。その目的は、ノードが危険にさらされていると宣言される前後に、記録が外部から分離され得ることを保証することである。ノードが危険にさらされていることが検出された場合、エクストラクタサービスを使用してブロックの有効部分を取り出し、一方、管理ノードは新しい選出工程を編成し、これらのトランザクションを開始ノードとして送信する。

【0065】

ブロックチェーンにおけるコンセンサスのための方法

【0066】

図３は、ＥＮの観点からの本開示の一実施形態によるコンセンサス方法の図を示す。ブロックチェーンは、複数のノードを有する分散ネットワークを含み、複数のノードは、１つの管理ノード「ＡＮ」と、１つの選出ノード「ＥＮ」と、複数のレギュラーノード「ＲＮ」とを含み、ＡＮ、ＥＮ、ＲＮの各々は、仮想マシン「ＶＭ」と、ＶＭ上で実行されるチェッカサービスと、チェッカサービス上で読み取り及び／又は実行権を有する他のノードに利用可能なチェッカアカウントとを有し、ブロックチェーンにトランザクションを提供するプロバイダノード「ＰＮ」を更に含む。

【0067】

コンセンサス方法は、以下の工程を含む。複数のＲＮの中からＥＮを指定するためにＡＮによって実行される選出する工程（Ｓ１）。ＥＮが異なるＰＮからトランザクションを受信することによって実行される受信工程（Ｓ２）。各受信されたトランザクションについて、チェッカアカウントを通じてＥＮのチェッカサービスを実行する工程（Ｓ３）。チェックされたトランザクションを含むブロックの、ＥＮによって実行される生成する工程（Ｓ４）。この生成する工程は、例えば、すべての受信されチェックされたトランザクションを生成中のブロックに順次追加するなど、いくつかの方法で実行してもよい。ＥＮによって実行される、生成されたブロックを複数のＲＮへ送信する工程（Ｓ５）。生成されたブロックを認証するために、チェッカアカウントを介してＥＮのチェッカサービスを実行する別の工程（Ｓ６）。ブロック生成における連続性を保証するために、本方法は、ＥＮが新しいＡＮとして指定され、次いでＳ１にループする、指定する工程（Ｓ７）を更に含むことが好ましい。

【0068】

各受信されたトランザクションについてチェッカサービスを実行する工程は、複数のＲＮのうちの少なくとも１つのＲＮによって、又はＥＮのチェッカアカウントへのアクセスを有する任意の外部ノードによって実行され得る。生成されたブロックに対するチェッカサービスを実行する工程は、生成されたブロック認証に対する高レベルのセキュリティを保証するために、複数のＲＮによって実行される。

【0069】

図４は、ネットワーク全体から見た、本開示の別の実施形態によるコンセンサス方法の図を示す。コンセンサス方法は以下の工程を含む。ＡＮがＲＮから受信された選出情報に基づいて選出工程を実行するＥＮ（図４には図示せず）を選出して、ＲＮのうちの１つをＥＮとして選出する工程（Ｓ１０）と、ＥＮに送信されるＰＮのような任意の外部サービスから来るトランザクションを作成する工程（Ｓ２０）と、外部サービス（ＥｘＮ、ＰＮ又はＲＮ）がＥＮのチェッカサービスを実行して、受信されたトランザクションがＯＫ（すなわち、信頼できる）であるか否かをチェックする工程（Ｓ３０）と、チェッカの結果が「偽」である場合、すなわちトランザクションが破損している場合、コンセンサスはブロックチェーン完全性違反を宣言する工程（Ｓ３１）と、チェッカの結果が「真」である場合、すなわちトランザクションが破損していない場合、ＥＮのハッシュサービスを実行して、ハッシュされたトランザクション、いわゆるエントリを構築中のブロックに追加する工程（Ｓ３２）と、ブロックに新しいエントリを追加した後、構築中のブロックが満杯であるか否か、すなわち、生成されたブロックが完了しているか否かをチェックする工程（Ｓ４０）と、ブロックが満杯でなければ、Ｓ２０に戻る工程（Ｓ４１）と、ブロックが満杯である場合、新しく生成されたブロックがすべてのＲＮに送信される工程（Ｓ５０）と、新しいブロックを受信された各ＲＮは、ＥＮのチェッカサービスを再び実行し、（Ｓ６１）チェッカが「偽」である場合、コンセンサスはブロックチェーン完全性違反を宣言する工程（Ｓ６０）と、チェッカが「真」である場合、ブロックは、すべてのＲＮがチェッカを検証するまで、各ＲＮによって保存される工程（Ｓ６２）と、ＥＮは新しいＡＮになり、工程はＳ１０に戻る工程（Ｓ７０）とを含む。

【0070】

図５は、コンセンサス方法中に発信される破損通知の場合の図を示す。ブロックチェーン完全性違反（Ｓ１００）は、ＡＮに送信される。ＡＮは、ＥＮのチェッカサービスを実行して（Ｓ１０１）、ＥＮが危険にさらされていることを確認する。ＥＮが危険にさらされていない場合、ＡＮによって何も行われない（Ｓ１０２）。ＥＮが危険にさらされている場合、ＡＮは、ＥＮのエクストラクタサービスを実行し、有効なトランザクションを取り出すためにデータベースを抽出する（Ｓ１０３）。次いで、ＡＮは、危険にさらされたＥＮをネットワークから除去し（Ｓ１０４）、除去されたノードなしで新しい選出工程を編成する（Ｓ１０５）。新しいＲＮが新しいＥＮとして選択されると、ＡＮは、取り出された不完全なトランザクションを新しく選出されたＥＮに提供する（Ｓ１０６）。そして、工程Ｓ２又は工程Ｓ２０に戻る。

【0071】

このようなコンセンサス方法は、発生すると思われる「Ｑｕｉｓ ｃｕｓｔｏｄｉｅｔ ｉｐｓｏｓ ｃｕｓｔｏｄｅｓ」問題、すなわち、チェッカサービスは他のサービスをチェックし、どのサービスが「チェッカ」をチェックするかを解決するいくつかの利点を提供する。これは、実際には、すべてのノードが「チェッカ」アカウントを介してアクセスすることができるチェッカサービスの完全な透明性及び最大限の単純さによって解決され、チェッカサービスのいかなる変更も防止する。

【0072】

永続的な「中央ノード」は存在しない。管理ノード又は選出ノードの中心位置は、レギュラーノードによって時間とともに共有される役割を変更している。

【0073】

認証は、システムのノードのうちのいずれか１つによって随意にアクティブ化され得るサービスによって保証され、サービスは、ブロックチェーン漸進的構築の重要な工程中に、特に、新しいトランザクションをブロックに追加するとき、及び新しいブロックをブロックチェーンに追加するときにアクティブ化される。

【0074】

１つのノードのみが、現在のブロック（選出ノード）を構築するために動作しており、したがって、いくつかのノードが同時に「マイニング」することによる、並びに高い難易度レベルによるエネルギーの過剰消費はない。

【0075】

選出工程

【0076】

上記の説明では、選出工程について数回言及してきた。

【0077】

一実施形態によれば、選出工程は、ＡＮによって、複数のＲＮから選出情報を要求する工程と、ＡＮによって、要求された選出情報に基づいて複数のＲＮの中からＥＮを選出する工程とを含む。このような選出情報は、少なくとも、ＲＮが既に選出された回数に対応する選出発生回数「ＥＯＮ」を含む。

【0078】

ブロックチェーンのセキュリティを更に強化するために、選出工程は、好ましくは、少なくとも１つの乱数を使用してＥＮを決定する非決定論的選出アルゴリズムに基づき、他のノード又は外部デバイスが、どのノードがうまく選出されるかを予想することを防止する。

【0079】

図６は、本開示による選出工程の例示的な図を示す。この例では、各ＡＮノード、ＥＮノード、ＲＮノードは、一意の識別番号「ＵＩＮ」、そのＥＯＮ、及び公開／秘密鍵のセットによって識別される。ＡＮの観点からの選出工程は、各ＲＮによって、そのＵＩＮ、そのＥＯＮ、及びその公開鍵をＡＮに提供する工程（Ｓ１００１）と、ＡＮは、ＥＯＮによってＲＮをランク付けし、各ＲＮをＥＯＮに応じた間隔に関連付ける工程（Ｓ１００２）と、ＡＮによって、前のＡＮから乱数を受信する工程（Ｓ１００３）と、ＡＮは、ＵＩＮとＥＯＮとの関数を計算し、計算された関数結果をハッシュし、ＡＮ秘密鍵でハッシュされた関数結果を暗号化し、暗号化された関数結果と提供された乱数との関数を計算して最終的な数を得る工程（Ｓ１００４）と、この最終的な数を有するＲＮ間隔をトラバースし、ＥＮになる１つのＲＮだけが残るまで、遭遇する対応するＲＮを漸進的に削除する工程（Ｓ１００５）とを含む。

【0080】

当然ながら、当業者には、明らかな改善及び／又は修正が実施され得、それでも添付の特許請求の範囲によって定義される本発明の範囲内であることが理解される。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【国際調査報告】