特許 7304963 プログラム、データ認証方法、およびコンピュータ装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-06-29

(45)【発行日】2023-07-07

(54)【発明の名称】プログラム、データ認証方法、およびコンピュータ装置

(51)【国際特許分類】

   H04L 9/32 20060101AFI20230630BHJP

   G06F 21/64 20130101ALI20230630BHJP

【ＦＩ】

H04L9/32 200B

G06F21/64

【請求項の数】 9

(21)【出願番号】P 2021555454

(86)(22)【出願日】2019-03-15

(65)【公表番号】

(43)【公表日】2022-07-22

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

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

(87)【国際公開日】2020-09-24

【審査請求日】2022-03-14

(73)【特許権者】

【識別番号】516014409

【氏名又は名称】ライン プラス コーポレーション

【氏名又は名称原語表記】ＬＩＮＥ Ｐｌｕｓ Ｃｏｒｐｏｒａｔｉｏｎ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ソ，ホンソプ

【審査官】中里 裕正

(56)【参考文献】

【文献】特開２０００－１２４８８７（ＪＰ，Ａ）

【文献】特表２０１８－５３０１７５（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０３５３３０９（ＵＳ，Ａ１）

【文献】国際公開第２０１８／１８９６５８（ＷＯ，Ａ１）

【文献】国際公開第２０１９／０４５５８９（ＷＯ，Ａ１）

【文献】中国特許出願公開第１０８７１２２５７（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／６４

(57)【特許請求の範囲】

【請求項1】

ブロックチェーンネットワークに参加するコンピュータ装置によって実現されるノードのデータ認証方法をコンピュータ装置に実行させるためのプログラムであって、
前記データ認証方法は、
前記コンピュータ装置が含む少なくとも１つのプロセッサにより、前記ブロックチェーンネットワークのチェーンを代表するプライベートキーを前記ブロックチェーンネットワークに参加する少なくとも１つの他のノードと共有する段階、
前記少なくとも１つのプロセッサにより、前記プライベートキーを利用して前記ブロックチェーンネットワークのパブリックアドレスを生成する段階、
前記少なくとも１つのプロセッサにより、前記ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、前記ブロックチェーンネットワークに設置されたコントラクトによって前記プライベートキーで署名する段階、および前記少なくとも１つのプロセッサにより、前記署名されたデータを、前記コントラクトを経て他のブロックチェーンネットワークに伝達する段階
を含み、
前記署名されたデータと前記パブリックアドレスとの比較により、前記署名されたデータが前記ブロックチェーンネットワークから発送されたものであることが検証されることを特徴とする、プログラム。

【請求項2】

前記ブロックチェーンネットワークは、複数のリーフチェーン間のデータ送信を管理するルートチェーンを含み、
前記データ認証方法は、
前記少なくとも１つのプロセッサにより、前記生成されたパブリックアドレスを前記複数のリーフチェーンそれぞれのジェネシスブロックに記録する段階
をさらに含むことを特徴とする、請求項１に記載のプログラム。

【請求項3】

前記署名されたデータが送信されたリーフチェーンで前記署名されたデータと前記リーフチェーンのジェネシスブロックに記録されたパブリックアドレスとを比較し、前記署名されたデータが前記ルートチェーンから発送されたものであることを検証することを特徴とする、請求項２に記載のプログラム。

【請求項4】

前記ブロックチェーンネットワークは、ルートチェーンによってデータ送信が管理される複数のリーフチェーンのうちの第１リーフチェーンを含み、
前記データ認証方法は、
前記少なくとも１つのプロセッサにより、前記生成されたパブリックアドレスを、前記ルートチェーンに前記第１リーフチェーンと関連して設置されたリーフチェーンコントラクトに登録する段階
をさらに含むことを特徴とする、請求項１～３のいずれか一項に記載のプログラム。

【請求項5】

前記ルートチェーンで前記署名されたデータと前記リーフチェーンコントラクトに登録されたパブリックアドレスとを比較し、前記署名されたデータが前記第１リーフチェーンから発送されたものであることを検証することを特徴とする、請求項４に記載のプログラム。

【請求項6】

前記ノードは、前記ブロックチェーンネットワークでの合意をなすように予め設定された複数のノードのうちの１つであることを特徴とする、請求項１～５のいずれか一項に記載のプログラム。

【請求項7】

前記署名されたデータが記録されたブロックが前記ブロックチェーンネットワークのチェーンに追加されることを特徴とする、請求項１～６のいずれか一項に記載のプログラム。

【請求項8】

ブロックチェーンネットワークに参加するコンピュータ装置によって実現されるノードのデータ認証方法であって、
前記コンピュータ装置が含む少なくとも１つのプロセッサにより、前記ブロックチェーンネットワークのチェーンを代表するプライベートキーを前記ブロックチェーンネットワークに参加する少なくとも１つの他のノードと共有する段階、
前記少なくとも１つのプロセッサにより、前記プライベートキーを利用して前記ブロックチェーンネットワークのパブリックアドレスを生成する段階、
前記少なくとも１つのプロセッサにより、前記ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、前記ブロックチェーンネットワークに設置されたコントラクトによって前記プライベートキーで署名する段階、および前記少なくとも１つのプロセッサにより、前記署名されたデータを、前記コントラクトを経て他のブロックチェーンネットワークに伝達する段階
を含み、
前記署名されたデータと前記パブリックアドレスとの比較により、前記署名されたデータが前記ブロックチェーンネットワークから発送されたものであることが検証されることを特徴とする、データ認証方法。

【請求項9】

ブロックチェーンネットワークのノードを実現するコンピュータ装置であって、
前記コンピュータ装置で読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサ
を含み、
前記少なくとも１つのプロセッサにより、
前記ブロックチェーンネットワークのチェーンを代表するプライベートキーを前記ブロックチェーンネットワークに参加する少なくとも１つの他のノードと共有し、
前記プライベートキーを利用して前記ブロックチェーンネットワークのパブリックアドレスを生成し、
前記ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、前記ブロックチェーンネットワークに設置されたコントラクトによって前記プライベートキーに署名し、
前記署名されたデータを前記コントラクトによって他のブロックチェーンネットワークに伝達し、
前記署名されたデータと前記パブリックアドレスとの比較により、前記署名されたデータが前記ブロックチェーンネットワークから発送されたものであることが検証されることを特徴とする、コンピュータ装置。

【発明の詳細な説明】

【技術分野】

【0001】

以下の説明は、ブロックチェーンで生成されたデータを認証する方法およびシステムに関する。

【背景技術】

【0002】

ブロックチェーンとは、電子台帳であって、トランザクションのためのブロックで構成されたコンピュータ基盤の分散型、Ｐ２Ｐ（ｐｅｅｒ－ｔｏ－ｐｅｅｒ）のシステムによって実現される。各トランザクション（Ｔｒａｎｓａｃｔｉｏｎ：Ｔｘ）は、ブロックチェーンシステム内の参加者にデジタル資産の制御送信をエンコードするデータ構造であり、少なくとも１つの入力と少なくとも１つの出力を含む。各ブロックは１つ前のブロックのハッシュを含み、該当のブロックは連結されており、最初からブロックチェーンに記録されたすべてのトランザクションの永久的な、変えることのできない記録を生成する。例えば、韓国公開特許第１０－２０１８－０１１３１４３号公報は、ブロックチェーンに基づくユーザ定義の貨幣取引システムおよびその動作方法について開示している。このようなブロックチェーン自体は、スケールアウトができない。例えば、ブロックチェーンネットワークでブロックを生成するためのノードを追加しても、ブロック生成のための合意費用が増加するだけで、トランザクションに対するブロックの生成速度は増加しない。

【発明の概要】

【発明が解決しようとする課題】

【0003】

ルートチェーンに基づいてリーフチェーンを追加する方式により、スケールアウトが可能なブロックチェーンで生成されるデータを認証するデータ認証方法およびシステムを提供する。

【課題を解決するための手段】

【0004】

ブロックチェーンネットワークに参加するコンピュータ装置によって実現されるノードのデータ認証方法であって、前記コンピュータ装置が含む少なくとも１つのプロセッサにより、前記ブロックチェーンネットワークのチェーンを代表するプライベートキーを前記ブロックチェーンネットワークに参加する少なくとも１つの他のノードと共有する段階、前記少なくとも１つのプロセッサにより、前記プライベートキーを利用して前記ブロックチェーンネットワークのパブリックアドレスを生成する段階、前記少なくとも１つのプロセッサにより、前記ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、前記ブロックチェーンネットワークに設置されたコントラクトによって前記プライベートキーで署名する段階、および前記少なくとも１つのプロセッサにより、前記署名されたデータを前記コントラクトによって他のブロックチェーンネットワークに伝達する段階を含み、前記署名されたデータと前記パブリックアドレスとの比較により、前記署名されたデータが前記ブロックチェーンネットワークから発送されたものであることが検証されることを特徴とする、データ認証方法を提供する。

【0005】

一側によると、前記ブロックチェーンネットワークは、複数のリーフチェーン間のデータ送信を管理するルートチェーンを含み、前記データ認証方法は、前記少なくとも１つのプロセッサにより、前記生成されたパブリックアドレスを前記複数のリーフチェーンそれぞれのジェネシスブロックに記録する段階をさらに含むことを特徴としてよい。

【0006】

他の側面によると、前記署名されたデータが送信されたリーフチェーンで前記署名されたデータと前記リーフチェーンのジェネシスブロックに記録されたパブリックアドレスとを比較することで、前記署名されたデータが前記ルートチェーンから発送されたものであることを検証することを特徴としてよい。

【0007】

また他の側面によると、前記ブロックチェーンネットワークは、ルートチェーンによってデータ送信が管理される複数のリーフチェーンのうちの第１リーフチェーンを含み、前記データ認証方法は、前記少なくとも１つのプロセッサにより、前記生成されたパブリックアドレスを前記ルートチェーンに前記第１リーフチェーンと関連して設置されたリーフチェーンコントラクトに登録する段階をさらに含むことを特徴としてよい。

【0008】

また他の側面によると、前記ルートチェーンで前記署名されたデータと前記リーフチェーンコントラクトに登録されたパブリックアドレスとを比較することで、前記署名されたデータが前記第１リーフチェーンから発送されたものであることを検証することを特徴としてよい。

【0009】

また他の側面によると、前記ノードは、前記ブロックチェーンネットワークでの合意をなすように予め設定された複数のノードのうちの１つであることを特徴としてよい。

【0010】

さらに他の側面によると、前記署名されたデータが記録されたブロックが前記ブロックチェーンネットワークのチェーンに追加されることを特徴としてよい。

【0011】

ブロックチェーンネットワークに参加するコンピュータ装置で実現されるノードのデータ認証方法であって、前記コンピュータ装置が含む少なくとも１つのプロセッサにより、前記ノードのプライベートキーを利用して前記ノードのパブリックアドレスを生成する段階、前記少なくとも１つのプロセッサにより、前記ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、前記ノードのプライベートキーを利用して署名する段階、および前記少なくとも１つのプロセッサにより、前記署名されたデータを前記他のブロックチェーンネットワークに伝達する段階を含み、前記パブリックアドレスを利用して前記署名されたデータが前記ブロックチェーンネットワークから発送されたものであることが検証されることを特徴とする、データ認証方法を提供する。

【0012】

コンピュータ装置と結合して前記方法をコンピュータ装置に実行させるためにコンピュータ読み取り可能な記録媒体に記録された、コンピュータプログラムを提供する。

【0013】

前記方法をコンピュータ装置に実行させるためのコンピュータプログラムが記録されていることを特徴とする、コンピュータ読み取り可能な記録媒体を提供する。

【0014】

ブロックチェーンネットワークのノードを実現するコンピュータ装置であって、前記コンピュータ装置で読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサにより、前記ブロックチェーンネットワークのチェーンを代表するプライベートキーを前記ブロックチェーンネットワークに参加する少なくとも１つの他のノードと共有し、前記プライベートキーを利用して前記ブロックチェーンネットワークのパブリックアドレスを生成し、前記ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、前記ブロックチェーンネットワークに設置されたコントラクトによって前記プライベートキーで署名し、前記署名されたデータを前記コントラクトから他のブロックチェーンネットワークに伝達し、前記署名されたデータと前記パブリックアドレスとの比較により、前記署名されたデータが前記ブロックチェーンネットワークから発送されたものであることが検証されることを特徴とする、コンピュータ装置を提供する。

【0015】

ブロックチェーンネットワークのノードを実現するコンピュータ装置であって、前記コンピュータ装置で読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサにより、前記ノードのプライベートキーを利用して前記ノードのパブリックアドレスを生成し、前記ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、前記ノードのプライベートキーを利用して署名し、前記署名されたデータを前記他のブロックチェーンネットワークに伝達し、前記パブリックアドレスを利用して前記署名されたデータが前記ブロックチェーンネットワークから発送されたものであることが検証されることを特徴とする、コンピュータ装置を提供する。

【発明の効果】

【0016】

ルートチェーンに基づいてリーフチェーンを追加する方式により、スケールアウトが可能なブロックチェーンで生成されるデータを認証するデータ認証方法およびシステムを提供することができる。

【図面の簡単な説明】

【0017】

【図1】本発明の一実施形態における、ネットワーク環境の例を示した図である。

【図2】本発明の一実施形態における、コンピュータ装置の例を示したブロック図である。

【図3】本発明の一実施形態における、拡張が可能なブロックチェーンネットワークの概括的な構成の例を示した図である。

【図4】本発明の一実施形態における、トランザクション処理システムの詳しい構成の例を示した図である。

【図5】本発明の一実施形態における、新たなリーフチェーンを追加する過程の例を示したフローチャートである。

【図6】本発明の一実施形態における、新たなサービスを追加する過程の例を示したフローチャートである。

【図7】本発明の一実施形態における、サービスにコインを発行する過程の例を示したフローチャートである。

【図8】本発明の一実施形態における、コイン交換過程の例を示したフローチャートである。

【図9】本発明の一実施形態における、各チェーン間のスマートコントラクトによるコイン交換データの流れを示した図である。

【図10】本発明の一実施形態における、署名可能コントラクトの設置過程の例を示した図である。

【図11】本発明の一実施形態における、データを署名する過程の例を示した図である。

【図12】本発明の一実施形態における、署名可能コントラクトの設置過程の他の例を示した図である。

【図13】本発明の一実施形態における、データを署名する過程の他の例を示した図である。

【図14】本発明の一実施形態における、コイン交換過程の他の例を示した図である。

【図15】本発明の一実施形態における、データ認証方法の第１例を示したフローチャートである。

【図16】本発明の一実施形態における、データ認証方法の第２例を示したフローチャートである。

【図17】本発明の一実施形態における、データ認証方法の第３例を示したフローチャートである。

【図18】本発明の一実施形態における、データ認証方法の第４例を示したフローチャートである。

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

【0018】

以下、実施形態について、添付の図面を参照しながら詳しく説明する。

【0019】

本発明の実施形態に係るデータ認証システムは、少なくとも１つのコンピュータ装置によって実現されてよい。コンピュータ装置においては、本発明の一実施形態に係るコンピュータプログラムがインストールされて実行されてよく、コンピュータ装置は、実行されたコンピュータプログラムの制御にしたがって本発明の一実施形態に係るデータ認証方法を実行してよい。上述したコンピュータプログラムは、コンピュータ装置と結合してデータ認証方法をコンピュータ装置に実行させるためにコンピュータ読み取り可能な記録媒体に記録されてよい。ここで説明したコンピュータプログラムは、独立する１つのプログラムパッケージの形態であってもよいし、独立する１つのプログラムパッケージの形態がコンピュータ装置に予めインストールされてオペレーティングシステムや他のプログラムパッケージと連係する形態であってもよい。

【0020】

図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。また、図１のネットワーク環境は、本実施形態に適用可能な環境のうちの一例を説明したものに過ぎず、本実施形態に適用可能な環境が図１のネットワーク環境に限定されることはない。

【0021】

複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定端末や移動端末であってよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン、携帯電話、ナビゲーション、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、ノート型ＰＣ、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ）、タブレットなどがある。一例として、図１では、電子機器１（１１０）の例としてスマートフォンを示しているが、本発明の実施形態において、電子機器１（１１０）は、実質的に無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信することのできる多様な物理的なコンピュータ装置のうちの１つを意味してよい。

【0022】

通信方式が限定されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を利用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ ａｒｅａ ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター－バスネットワーク、ツリーまたは階層的ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これらに限定されることはない。

【0023】

サーバ１５０、１６０それぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供する１つ以上のコンピュータ装置によって実現されてよい。例えば、サーバ１５０は、ネットワーク１７０を介して接続した複数の電子機器１１０、１２０、１３０、１４０にサービス（一例として、ビデオ通話サービス、金融サービス、決済サービス、ソーシャルネットワークサービス、メッセージングサービス、検索サービス、メールサービス、コンテンツ提供サービス、および／または質疑応答サービスなど）を提供するシステムであってよい。

【0024】

図２は、本発明の一実施形態における、コンピュータ装置の例を示したブロック図である。上述した複数の電子機器１１０、１２０、１３０、１４０それぞれやサーバ１５０、１６０それぞれは、図２に示したコンピュータ装置２００によって実現されてよく、本発明の実施形態に係る方法は、このようなコンピュータ装置２００によって実現されてよい。

【0025】

このとき、図２に示すように、コンピュータ装置２００は、メモリ２１０、プロセッサ２２０、通信インタフェース２３０、および入力／出力インタフェース２４０を含んでよい。メモリ２１０は、コンピュータ読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ディスクドライブのような永続的大容量記録装置を含んでよい。ここで、ＲＯＭやディスクドライブのような永続的大容量記録装置は、メモリ２１０とは区分される別の永続的記録装置としてコンピュータ装置２００に含まれてもよい。また、メモリ２１０には、オペレーティングシステムと、少なくとも１つのプログラムコードが記録されてよい。このようなソフトウェア構成要素は、メモリ２１０とは別のコンピュータ読み取り可能な記録媒体からメモリ２１０にロードされてよい。このような別のコンピュータ読み取り可能な記録媒体は、フロッピー（登録商標）ドライブ、ディスク、テープ、ＤＶＤ／ＣＤ－ＲＯＭドライブ、メモリカードなどのコンピュータ読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータ読み取り可能な記録媒体ではない通信インタフェース２３０を通じてメモリ２１０にロードされてもよい。例えば、ソフトウェア構成要素は、ネットワーク１７０を介して受信されるファイルによってインストールされるコンピュータプログラムに基づいてコンピュータ装置２００のメモリ２１０にロードされてよい。

【0026】

プロセッサ２２０は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１０または通信インタフェース２３０によって、プロセッサ２２０に提供されてよい。例えば、プロセッサ２２０は、メモリ２１０のような記録装置に記録されたプログラムコードにしたがって受信される命令を実行するように構成されてよい。

【0027】

通信モジュール２３０は、ネットワーク１７０を介してコンピュータ装置２００が他の電子機器（一例として、上述した記録装置）と互いに通信するための機能を提供してよい。一例として、コンピュータ装置２００のプロセッサ２２０がメモリ２１０のような記録装置に記録されたプログラムコードにしたがって生成した要求や命令、データ、ファイルなどが、通信インタフェース２３０の制御にしたがってネットワーク１７０を介して他の装置に伝達されてよい。これとは逆に、他の装置からの信号や命令、データ、ファイルなどが、ネットワーク１７０を経てコンピュータ装置２００の通信インタフェース２３０を通じてコンピュータ装置２００に受信されてよい。通信インタフェース２３０を通じて受信された信号や命令、データなどは、プロセッサ２２０やメモリ２１０に伝達されてよく、ファイルなどは、コンピュータ装置２００がさらに含むことのできる記録媒体（上述した永続的記録装置）に記録されてよい。

【0028】

入力／出力インタフェース２４０は、入力／出力装置２５０とのインタフェースのための手段であってよい。例えば、入力装置は、マイク、キーボード、カメラ、またはマウスなどの装置を、出力装置は、ディスプレイ、スピーカのような装置を含んでよい。他の例として、入力／出力インタフェース２４０は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。入力／出力装置２５０は、コンピュータ装置２００と１つの装置で構成されてもよい。

【0029】

また、他の実施形態において、コンピュータ装置２００は、図２の構成要素よりも少ないか多くの構成要素を含んでもよい。しかし、大部分の従来技術的構成要素を明確に図に示す必要はない。例えば、コンピュータ装置２００は、上述した入力／出力装置２５０のうちの少なくとも一部を含むように実現されてもよいし、トランシーバやデータベースなどのような他の構成要素をさらに含んでもよい。

【0030】

図３は、本発明の一実施形態における、拡張が可能なブロックチェーンネットワークの概括的な構成の例を示した図である。図３は、ルートチェーン（Ｒｏｏｔ Ｃｈａｉｎ）３１０、リーフチェーンＡ（Ｌｅａｆ Ｃｈａｉｎ Ａ）３２０、リーフチェーンＢ（Ｌｅａｆ Ｃｈａｉｎ Ｂ）３３０、およびリレイヤ（Ｒｅｌａｙｅｒ）３４０を含むブロックチェーンネットワーク３００の例を示している。ルートチェーン３１０とリーフチェーン３２０および３３０は、複数のコンピュータ装置が連結するネットワークを形成してよく、リレイヤ３４０は、少なくとも１つのコンピュータ装置によって実現されてよい。

【0031】

ブロックチェーンネットワーク３００において、ルートチェーン３１０は、絶対信頼システムとして見なされてよく、それぞれのリーフチェーン３２０および３３０は、ルートチェーン３１０に自身が信頼システムであるということを証明しなければならない。このとき、それぞれのリーフチェーン３２０および３３０は、個別のサービスと連係してよく、新たなサービスが追加されるときには新たなリーフチェーンが追加されてもよい。言い換えれば、図３の実施形態では、２つのリーフチェーン３２０および３３０を示しているが、３つ以上のリーフチェーンを含んでもよく、これは、ブロックチェーンの拡張が可能であることを意味してよい。ここで、「サービス」とは、同一または互いに異なる主体がネットワークを介して自身のユーザに提供するオンラインサービスを含んでよい。一例として、互いに異なる複数の銀行が提供するインターネットバンキングサービスそれぞれに対応する複数のリーフチェーンが構成されてよい。または、互いに異なる複数のソーシャルネットワークサービスそれぞれに対応する複数のリーフチェーンが構成されてもよい。それぞれのリーフチェーン３２０および３３０は、ルートチェーン３１０にブロックのハッシュを記録することによって信頼が承認されなければならない。一例として、マークルツリールートハッシュ（ｍｅｒｋｌｅ ｔｒｅｅ ｒｏｏｔ ｈａｓｈ）が活用されてよい。

【0032】

ルートチェーン３１０ではユーザ間のコイン交換は行わず、コイン交換は、それぞれのリーフチェーン３２０および３３０の内部でなされるか、および／またはリーフチェーン３２０および３３０間でなされてよい。このとき、リーフチェーン３２０および３３０間のコイン交換は、リレイヤ３４０を介してルートチェーン３１０が仲裁および管理してよい。それぞれのリーフチェーン３２０および３３０には、少なくとも１つのＤＡｐｐ（Ｄｅｃｅｎｔｒａｌｉｚｅｄ Ａｐｐｌｉｃａｔｉｏｎ）が含まれてよい。ここで、ＤＡｐｐ（Ｄｅｃｅｎｔｒａｌｉｚｅｄ Ａｐｐｌｉｃａｔｉｏｎ）とは、バックエンドコードが分散されたＰ２Ｐ（ｐｅｅｒ－ｔｏ－ｐｅｅｒ）ネットワーク上で実行し（あるいは、データの呼び出しや登録をブロックチェーンデータベースに行い）、これをフロントエンドでインタフェースとして提供するアプリケーションを意味する。このとき、それぞれのリーフチェーン３２０および３３０では、ＤＡｐｐの必要により、チェーンまたはコイン交換とは関係のないスマートコントラクトを設置してよく、これをルートチェーン３１０では関与しない。それぞれのリーフチェーン３２０および３３０でチェーン間のコイン交換のためのプロトコルを有するスマートコントラクトを設置しようとする場合には、ルートチェーン３１０からスマートコントラクトを設置するための許可を得なければならない。ルートチェーン３１０から許可が得られなかったスマートコントラクトを利用したチェーン間では、コイン交換がなされないように制限されてよい。

【0033】

それぞれのリーフチェーン３２０および３３０の内部でのコイン交換は、ルートチェーン３１０を経る必要がなくそれぞれのリーフチェーン３２０および３３０で処理されてよく、処理された内容が含まれたすべてのブロックの要約情報（一例として、上述したマークルツリールートハッシュ）をルートチェーン３１０に記録してよい。この反面、リーフチェーン３２０および３３０間のコイン交換はルートチェーン３１０を介さなければならず、それぞれのリーフチェーン３２０および３３０のブロックとルートチェーン３１０のブロックにはコイン交換の処理に関する内容が記録されなければならない。このとき、リーフチェーン３２０および３３０間のコイン交換は、リレイヤ３４０を経てなされてよい。

【0034】

図４は、本発明の一実施形態における、ブロックチェーンネットワークの詳しい構成の例を示した図である。ブロックチェーンネットワーク３００は、図４に示すように、１つのルートチェーン３１０と複数のリーフチェーン３２０および３３０、さらにリレイヤ３４０で構成されてよい。

【0035】

ルートチェーン３１０は、ルートチェーン３１０のためのスマートコントラクトであるルートチェーンマネージャコントラクト（Ｒｏｏｔ Ｃｈａｉｎ Ｍａｎａｇｅｒ Ｃｏｎｔｒａｃｔ）４１１を含んでよく、ブロックチェーンネットワーク３００が含む複数のリーフチェーン３２０および３３０それぞれのためのスマートコントラクトを含んでよい。図４の実施形態では、ルートチェーン３１０がリーフチェーンＡ（Ｌｅａｆ Ｃｈａｉｎ Ａ）３２０のためのスマートコントラクトであるリーフチェーンＡコントラクト（Ｌｅａｆ Ｃｈａｉｎ Ａ Ｃｏｎｔｒａｃｔ）４１２と、リーフチェーンＢ（Ｌｅａｆ Ｃｈａｉｎ Ｂ）３３０のためのスマートコントラクトであるリーフチェーンＢコントラクト（Ｌｅａｆ Ｃｈａｉｎ Ｂ Ｃｏｎｔｒａｃｔ）４１３を含む例を示している。

【0036】

また、リーフチェーン３２０および３３０それぞれは、ＤＡｐｐのためのスマートコントラクトを含んでよい。図４の実施形態では、リーフチェーンＡ３２０がＤＡｐｐコントラクト（ＤＡｐｐ Ｃｏｎｔｒａｃｔ）４２１を含み、リーフチェーンＢ３３０がＤＡｐｐコントラクト４３１を含む例を示している。また、リーフチェーンＡ３２０は、リーフチェーンＡ３２０のためのスマートコントラクトであるリーフチェーンマネージャコントラクト（Ｌｅａｆ Ｃｈａｉｎ Ｍａｎａｇｅｒ Ｃｏｎｔｒａｃｔ）４２２を含んでよく、リーフチェーンＢ３３０は、リーフチェーンＢ３３０のためのスマートコントラクトであるリーフチェーンマネージャコントラクト４３２をさらに含んでよい。

【0037】

リレイヤ３４０は、ルートチェーン３１０とリーフチェーン３２０および３３０のブロック生成を観察しながら、ルートチェーン３１０とリーフチェーン３２０および３３０に記録されるか、および／または伝達が要求される情報を呼び出してよい。リレイヤ３４０は、プロデューサ（Ｐｒｏｄｕｃｅｒ）４４１、カフカ（Ｋａｆｋａ）４４２、インタチェーンコンシューマ（ＩｎｔｅｒＣｈａｉｎ Ｃｏｎｓｕｍｅｒ）４４３、インタチェーンフェイルオーバー（ＩｎｔｅｒＣｈａｉｎ Ｆａｉｌｏｖｅｒ）４４４、データベース（Ｄａｔａｂａｓｅ）４４５を含んでよい。

【0038】

プロデューサ４４１は、ルートチェーン３１０を含むすべてのチェーンの新たに生成されたブロックの情報を収集してカフカ４４２に入力してよい。カフカ４４２は、一種のキューサーバであって、収集した情報をキューに保存して順に提供してよい。このとき、インタチェーンコンシューマ４４３は、チェーンごとに呼び出しが要求されるイベントをフィルタリングしてよい。イベントによって複数のフィルタリングが要求されてもよい。インタチェーンコンシューマ４４３は、各チェーンに呼び出しをするときに、署名のためにチェーンごとに個別のユーザを生成し、ユーザの権限をスマートコントラクトに記録してよい。

【0039】

インタチェーンコンシューマ４４３は、次の（１）～（７）のようなイベントなどを感知してよい。

【0040】

（１）リーフチェーンでの送金要請イベント
（１－１）インタチェーンコンシューマ４４３は、リーフチェーンでの送金要請イベントを感知し、ルートチェーンに送金要請内容を伝達してよい。

【0041】

（２）ルートチェーンでの送金要請イベント
（２－１）インタチェーンコンシューマ４４３は、ルートチェーンでの送金要請イベントを感知し、送金要請を受信するリーフチェーンに送金要請内容を伝達してよい。

【0042】

（２－２）インタチェーンコンシューマ４４３は、受信するリーフチェーンへの伝達が失敗したときに、送金要請を受信するリーフチェーンの識別情報を含む送金失敗情報をルートチェーンに伝達してよい。

【0043】

（３）ルートチェーンでの送金要請失敗イベント
（３－１）インタチェーンコンシューマ４４３は、送金を要請したリーフチェーンに送金失敗内容を伝達してよい。

【0044】

（４）リーフチェーンでの送金完了イベント
（４－１）インタチェーンコンシューマ４４３は、ルートチェーンに送金完了内容を伝達してよい。

【0045】

（５）ルートチェーンでの送金完了イベント
（５－１）インタチェーンコンシューマ４４３は、送金を要請したリーフチェーンに送金完了内容を伝達してよい。

【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】

（５）リーフチェーンＢ３３０のリーフチェーンマネージャコントラクトＢ９４０は、送金しようとするサービスであるＤＡｐｐ３（９５０）を呼び出し、ＤＡｐｐ３（９５０）のコントラクトからユーザｂに送金がなされるようにしてよい。このとき、ＤＡｐｐ３（９５０）のコントラクトは、リーフチェーンＢ３３０の全体通貨量も増加させてよい。

【0081】

（６）プロデューサ４４１は、（５）で生成された取引を収集してよく、インタチェーンコンシューマ４４３は、ルートチェーン３１０のリーフチェーンＢコントラクト４１３に送金完了を要請してよい。

【0082】

（７）ルートチェーン３１０のリーフチェーンＢコントラクト４１３は、ルートチェーンマネージャコントラクト４１１に該当の送金要請のエスクロー（送金要請記録）情報をインポートして送金完了を処理してよい。送金が成功した場合、リーフチェーンＢコントラクト４１３が管理するＤＡｐｐ３９５０では送金金額分だけリーフチェーンＢ３３０の全体通貨量を増加させててよく、ルートチェーン３１０のルートチェーンマネージャコントラクト４１１から該当の送金要請記録が削除されてよい。送金が失敗した場合、リーフチェーンＡコントラクト４１２に登録された、送金要請したサービスであるＤＡｐｐ１（９２０）では送金金額分だけリーフチェーンＡ３２０の全体通貨量を再び増加させてよく、その後、ルートチェーン３１０のルートチェーンマネージャコントラクト４１１から該当の送金要請記録が削除されてよい。

【0083】

（８）プロデューサ４４１は、（７）で生成された取引を収集してよく、インタチェーンコンシューマ４４３は、送金したリーフチェーンＡ３２０のリーフチェーンマネージャコントラクトＡ９１０に送金完了を要請してよい。

【0084】

（９）リーフチェーンＡ３２０のリーフチェーンマネージャコントラクトＡ９１０は、送金完了情報を受信し、該当の交換取引ハッシュが完了したことを記録し、送金要請記録にある該当の要請を削除してよい。送金が失敗した場合、リーフチェーンマネージャコントラクトＡ９１０は、送金要請記録にある金額をユーザａに再び返還してよく、ＤＡｐｐ１（９２０）の全体通貨量も送金金額分だけ再び増加させた後、送金要請記録から該当の要請を削除してよい。

【0085】

実施形態によって、リレイヤは、チェーンごとに存在してもよい。例えば、図４を参照しながら説明したように、１つのルートチェーン３１０と２つのリーフチェーン３２０および３３０が存在する場合、合計３つのチェーンのための３つのリレイヤが構成されてもよい。この場合、ルートチェーン３１０のリレイヤは、２つのリーフチェーン３２０および３３０との要請、データ、および／またはイベントの伝達を処理してよく、２つのリーフチェーン３２０および３３０それぞれのリレイヤは、ルートチェーン３１０との要請、データ、および／またはイベントの伝達を処理してよい。このとき、リーフチェーンのためのリレイヤの談合を防ぐために、リレイヤそれぞれと連結するチェーンは、予め設定された時間周期（一例として、ブロック時間周期）ごとに動的に変更されてよい。このような実施形態において、ハッシュは、ハッシュ時間ロックコントラクトにより、チェーン間を移動するときにリレイヤによって交換取引が中間に強奪あるいは変調されないようにしてよい。このようなハッシュ時間ロックは、ユーザが交換取引の結果を直接確認することのできる時間を提供するために利用されてよい。また、リレイヤが意図しない重複支払を防ぐための唯一の識別子として個別の交換取引識別子が活用されてよい。このような交換取引識別子は、リーフチェーン間の価値移動がある場合、交換取引を唯一に識別してトラッキングするために活用されてよい。

【0086】

このようなブロックチェーンネットワーク３００でチェーン間にデータを伝達するときに、伝達するシステムで伝達するデータを変調することがある。一例として、リーフチェーンＡ３２０からルートチェーン３１０にデータを伝達するときに、リーフチェーンＡ３２０でデータを変調する可能性が存在する。特に、リーフチェーンをパブリックブロックチェーンの形態に確張するためにリーフチェーンごとにリレイヤが実現される場合、このようなリレイヤに対する依存度を減らし、プロトコル端でデータ認証の問題を解決する必要がある。このために、ブロックチェーンネットワーク３００は、以下のような５つの要求事項を有する。

【0087】

１．ベースコインのチェーン間の送金が可能でなければならない。ここで、ベースコインとは、ブロックチェーンネットワーク３００の固有のコイン体系で使用されるコインを意味してよい。

【0088】

２．ルートチェーンがすべてのチェーンのベースコインを管理しなければならない。このとき、ベースコインの管理は、チェーン間のベースコインの送金を含んでよい。

【0089】

３．リレイヤがデータを変調して伝達できないようにしなければならない。

【0090】

４．リーフチェーンから送金を受けてユーザへの送金は成功したが、失敗メッセージを伝達することによって重複支払が発生しないようにしなければならない。

【0091】

５．送金でベースコインを受信するユーザの確認なく、チェーン間の送金が迅速になされなければならない。

【0092】

このような要求事項のために、ルートチェーンでは、権限をもつユーザによってベースコインの鋳造（ｍｉｎｔ）と焼却（ｂｕｒｎ）が発生するようにしてよい。または、権限をもつユーザがマルチシグウォレットによって確認を受けてベースコインを発行または焼却させることができるようにしてよい。このとき、リーフチェーンでは、ルートチェーンでコイン発行要請を受ける場合に発行を実行してよい。また、リーフチェーンから他のリーフチェーンに送金を行う場合、２つのリーフチェーンではルートチェーンの認証された情報が伝達されたことを確認した後に鋳造と焼却が実行されてよい。例えば、ベースコインを送金するリーフチェーンでは該当のベースコインに対する焼却を実行してよく、ベースコインを受信するリーフチェーンでは該当のベースコインに対する鋳造を実行してよい。

【0093】

一方、リレイヤのデータ変調を防ぐためには、伝達しようとするデータが変調されないようにしなければならない。以下では、データの変調を遮断するための方法について説明する。

【0094】

１つ目の方法では、伝達しようとする原本データを署名してよい。データを送信する主体（ｆｒｏｍ ｕｓｅｒ）がデータを受信しようとするチェーンにおいて既知のユーザである場合は、署名された原本データに基づいて原本データの変調状態を確認してよい。このために、コントラクトは、コントラクト自身のプライベートキーをもつ状態で生成されてよく、プライベートキーに対応するパブリックキーを公開してよい。このとき、コントラクトから他のチェーンに伝達が必要な情報を署名してイベントとして記録してよく、したがって、原本データが該当のコントラクトから処理されたということを証明することができる。例えば、コントラクトは、原本データと自身のコントラクトアドレスをコントラクトのプライベートキーによって署名してよい。この場合、任意のユーザは、コントラクトのプライベートキーに対応するパブリックキーを利用して署名された原本データを検証してよく、すべてのチェーンで唯一に生成される該当のコントラクトのコントラクトアドレスにより、該当のコントラクトによってデータが伝達されたことが証明されてよい。しかし、１つ目の方法では、コントラクトのプライベートキーはコントラクトのデータベースに保存されなければならず、ブロックチェーンネットワークでデータベースは共有およびオープンされるため、チェーンのすべてのノードにプライベートキーが共有され、したがって、これ以上プライベートキーではなくなる。

【0095】

２つ目の方法では、プライベートキーをコントラクトに保存するのではなく、１つのチェーンを代表するプライベートキーを、同じチェーン内で合意をなすノードであるＣノードと共有し、チェーン認証が要求されるときに使用できるようにしてよい。一例として、各チェーンは、合意のためのｎ（一例として、ｎは４～８）個のＣノードがプライベートキーを共有して維持してよい。ユーザや他のコントラクトは、該当のチェーンのためのシステム（一例として、該当のチェーンに設置されたシステムコントラクト）にデータの署名を要求してよく、システムは、要求されたデータに署名し、署名されたデータを提供してよい。このとき、該当のチェーンのコントラクトは、データの署名と伝達に対するイベントを記録してよく、リレイヤを経て他のチェーンに署名されたデータを伝達してよい。例えば、ルートチェーンでルートチェーンのプライベートキーと対をなすパブリックキーによって生成される識別値であるパブリックアドレスは、リーフチェーンのジェネシスブロックに記録されることにより、リーフチェーンで変調することができなくなる。ルートチェーンによってプライベートキーで署名されたデータは、リーフチェーンでジェネシスブロックに記録されたパブリックアドレスと比較することにより、署名されたデータがルートチェーンから発送されたものであることを検証することができる。これと同じように、リーフチェーンも、リーフチェーンのプライベートキーによって生成されるパブリックアドレスを、ルートチェーンに該当のリーフチェーンと関連して設置されたリーフチェーンコントラクトに登録してよい。この場合、ルートチェーンは、リーフチェーンによってリーフチェーンのプライベートキーで署名されたデータと該当のリーフチェーンコントラクトに登録されたパブリックアドレスとを比較することにより、署名されたデータが該当のリーフチェーンから発送されたものであることを検証してよい。ただし、２つ目の方法は、合意のためのＣノードでプライベートキーを共有することのできるプライベートブロックチェーンでは使用可能であるが、外部サービスの提供のために公開されるパブリックブロックチェーン（パブリックリーフチェーン）では使用が不可能である。

【0096】

３つ目の方法は、ルートチェーンのすべてのＣノードそれぞれが合意のために有している固有のプライベートキーを活用する方法である。一例として、ルートチェーンが８つのＣノードを含む場合は、８つのプライベートキーが存在してよい。この場合、該当のプライベートキーによって生成されるルートチェーンのすべてのＣノードそれぞれのパブリックアドレスが、すべてのリーフチェーンそれぞれに保存されてよい。このとき、ルートチェーンで生成されたものであることを確認する必要のあるデータは、ルートチェーンのリーダーノードが自身のプライベートキーで署名してブロックに記録してよく、該当のデータがリーフチェーンに伝達されるようにしてよい。ここで、リーダーノードは、Ｃノードのうちから任意に選定されたノードであってよく、必要によっては、他のＣノードのうちの１つに変更されてよい。この場合、リーフチェーンは、署名されたデータとリーフチェーンに保存されたパブリックアドレスとを比較することにより、署名されたデータがルートチェーンから発送されたものであることを検証することができる。上述したように、リーフチェーンは、ルートチェーンのすべてのＣノードのパブリックアドレスが分かっているため、署名されたデータを検証するときに得られるパブリックアドレスが既知のルートチェーンのＣノードのパブリックアドレスのうちの１つであるかを検証することにより、署名されたデータを検証してよい。ただし、ルートチェーンが含むＣノードの数が公開され、Ｃノードをルートチェーンに追加または削除などの変更が発生する場合は、すべてのリーフチェーンそれぞれに記録された情報は更新しなければならない。特に、外部サービスのために割り当てられたパブリックブロックチェーン（パブリックリーフチェーン）に記録された情報は直接更新することができないため、該当のパブリックブロックチェーンで記録された情報を更新するように情報を提供（パブリックアドレスの更新を可能にするための情報を公知）しなければならない。これと同じように、リーフチェーンのＣノードも、合意のために固有のプライベートキーを有してよく、このようなプライベートキーが活用されてよい。この場合、Ｃノードそれぞれのパブリックアドレスは、ルートチェーンに該当のリーフチェーンと関連して設置されたリーフチェーンコントラクトに登録されてよく、ルートチェーンは、署名されたデータと該当のリーフチェーンコントラクトに登録されたパブリックアドレスとを比較することにより、署名されたデータが該当のリーフチェーンから発送されたものであることを検証してよい。

【0097】

４つ目の方法は、ルートチェーンのすべてのＣノードで生成されるパブリックアドレスの組み合わせによって生成される代表パブリックアドレス（Ｃｏｍｍｏｎ Ｐｕｂｌｉｃ Ａｄｄｒｅｓｓ）をすべてのリーフチェーンそれぞれに共有する方法である。この場合にも、ルートチェーンでＣノードを追加または削除するなどの変更が発生する場合は、すべてのリーフチェーンそれぞれに記録された情報を更新しなければならないが、リーフチェーンそれぞれで共有しなければならないパブリックアドレスを代表パブリックアドレス１つに減らすことができ、ルートチェーンが含むＣノードの数は公開されないという長所がある。ただし、代表パブリックアドレスが変更されるため、変更時には保安に注意しなければならない。４つ目の方法では、ルートチェーンのすべてのＣノードのパブリックアドレスそれぞれをすべてのＣノードそれぞれがすべて分かっていなければならない。また、４つ目の方法では、プライベートキーが複数あったとしても１つのパブリックアドレス（代表パブリックアドレス）を生成することができ、プライベートキーが１つ以上のコンファームによって暗号を解除することができるように、署名のためのアルゴリズムとこれを検証するアルゴリズムを修正したモジュールが要求される。

【0098】

５つ目の方法では、１つ目の方法を活用可能にするために、ブロックチェーンに次のような機能を追加する。５つ目の方法では、コントラクトがパブリックキーによってコントラクトアドレスを生成し、プライベートキーを暗号化してコントラクトが保存するようにしてよい。プライベートキーが分かっており、プライベートキーによってパブリックキーを得ることができ、パブリックキーによってコントラクトアドレスを生成することができる。このとき、署名のためのコントラクト（以下、署名可能コントラクト）は、１つのチェーンに１つだけが存在しても問題ない。例えば、署名可能コントラクトを設置するときに、暗号化されたプライベートキーとプライベートキーによって生成されるパブリックキーがパラメータとなって署名可能コントラクトに伝達されてよい。署名可能コントラクトは、受信したパブリックキーによってコントラクトアドレスを生成してよい。このとき、同じコントラクトアドレスがあれば、コントラクトアドレスの生成は失敗となる。暗号化されたプライベートキーは、以下で説明するパスワードによって復号されてよく、署名可能コントラクトによってデータベースに保存されてよい。このとき、任意のコントラクトがデータを署名しようとする場合、署名しようとするデータと署名可能コントラクトに保存された暗号化されたプライベートキーを復号することのできるパスワードをパラメータとして署名可能コントラクトに伝達してよい。このとき、ブロックチェーンですべての要請（一例として、ＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）を利用した要請）による情報はブロックやログに記録される反面、パスワードはどこにも保存／記録されてはならない。したがって、５つ目の方法では、パスワードパラメータをブロックやログなどのどこにも保存／記録されないタイプ（以下、「シーキュアタイプ」）として定義してよい。このようなパスワードパラメータは、該当のブロックチェーンで支援されてよい。この場合、署名可能コントラクトは、パスワードによって暗号化されたプライベートキーを復元した後、復元されたプライベートキーを利用して入力されたデータを署名してよく、署名した結果（署名されたデータ）を署名要請したコントラクトに返還してよい。署名可能コントラクトのコントラクトアドレスは、各リーフチェーンのジェネシスブロックに記録されてよい。ただし、５つ目の方法では、システム上でシーキュアタイプを個別に定義して活用しなければならず、暗号化されたプライベートキーとパブリックキーがシステム外部で生成されて提供されなければならず、プライベートキーが暗号化されて伝達されるため、プライベートキーが正常に生成されて伝達されるかどうかを確認することができない。ルートチェーンから送信されるデータであることをリーフチェーンが立証するために、リーフチェーンでは、該当のデータを署名した署名可能コントラクトがルートチェーンに設置されたコントラクトであるかをルートチェーンに照会して直ぐに把握してよく、該当の署名コントラクトがルートチェーンにコントラクトに存在するコントラクトであるということが立証されれば、署名されたデータがルートチェーンで生成または処理されたデータであるということが立証されるようになる。

【0099】

図１０は、本発明の一実施形態における、署名可能コントラクトの設置過程の例を示した図である。図１０は、署名可能コントラクト１０１０が暗号化されたプライベートキー１０２０とパブリックキー１０３０をパラメータとして受信し、受信されたパブリックキー１０３０を利用してパブリックアドレスを生成してデータベース１０４０に保存する例を示している。言い換えれば、データベース１０４０には、暗号化されたプライベートキー１０２０とパブリックキー１０３０、さらにパブリックキー１０３０を利用して生成されたパブリックアドレスが保存されてよい。

【0100】

図１１は、本発明の一実施形態における、データを署名する過程の例を示した図である。図１１は、署名可能コントラクト１０１０がユーザや他のコントラクト１１１０からの署名要請を受信する例を示している。このとき、署名要請は、署名するためのデータと、図１０で説明した、暗号化されたプライベートキー１０２０を復号するためのパスワードを含んでよい。この場合、署名可能コントラクト１０１０は、パスワードを利用して暗号化されたプライベートキー１０２０を復号してプライベートキーを得てよく、復号されたプライベートキーを利用してパラメータとして伝達されたデータを署名してよい。この後、署名可能コントラクト１０１０は、署名されたデータを結果として、ユーザや他のコントラクト１１１０に返還してよい。ここで、ユーザは、該当のブロックチェーンのノードに対応してよい。

【0101】

６つ目の方法では、５つ目の方法の署名可能コントラクトがブロックチェーンのシステムコントラクトによって自動設置されるようにしてよい。言い換えれば、ブロックチェーンのシステムコントラクトが設置されるときに、署名可能コントラクトもともに設置されるようにしてよい。例えば、リーダーノードのようにシステムコントラクトを最初に生成するノードが、プライベートキーを生成して署名可能コントラクトを設置してよい。生成されたプライベートキーは、署名可能コントラクトによって暗号化されてデータベースに保存されてよく、暗号化されたプライベートキーを復号するためのパスワードは、該当のノードのパブリックキーによって暗号化して該当のノードのローカルに保存されてよい。他のノードは、トランザクションをコピーし、最新のパスワードが分かるノードを検索してよい。このとき、他のノードは、検索されるノードに自身のパブリックキーを伝達してパブリックキーによって暗号化されたパスワードを受信し、該当の他のノードのローカルに保存してよい。各ノードは、署名を要請するときに、自身のパブリックキーによって自身のローカルに保存された暗号化されたパスワードを復号してパスワードを得てよく、得られたパスワードを署名要請関数のパラメータとして署名可能コントラクトに伝達してよい。要請は、ブロックチェーンで提供する署名ＡＰＩまたは関数を利用して処理されてよい。署名可能コントラクトのパブリックアドレスは、各リーフチェーンのジェネシスブロックに記録されてよい。ルートチェーンから送信されるデータであることを立証するためには、署名可能コントラクトを活用してよい。

【0102】

図１２は、本発明の一実施形態における、署名可能コントラクトの設置過程の他の例を示した図である。図１２は、ノードが生成したプライベートキーを署名可能コントラクト１２１０がノードのパブリックキー１２２０によって暗号化してデータベース１２３０に保存する例を示している。このとき、署名可能コントラクト１２１０は、暗号化されたプライベートキーを復号するためのパスワードをノードのパブリックキーによって暗号化して該当のノードに返還してよい。返還された暗号化されたパスワードは、ノードのローカルに保存されてよい。

【0103】

図１３は、本発明の一実施形態における、データを署名する過程の他の例を示した図である。図１３は、ノード１３１０が暗号化されたパスワードをノード１３１０のプライベートキーによって復号してパスワードを取得した後、取得したパスワードをパラメータとしてシステム１３２０に伝達してデータの署名を要請する例を示している。ここで、システム１３２０は、ブロックチェーンシステムに対応してよい。このとき、署名しようとするデータも、パラメータとしてともにシステム１３２０に伝達してよい。この場合、システム１３２０は、パスワードを利用して署名可能コントラクト１２１０にデータの署名を要請してよい。この場合、署名可能コントラクト１２１０は、パスワードによって暗号化されたプライベートキーを復号してよく、復号されたプライベートキーを利用してデータを署名した後、署名されたデータを返還してよい。システム１３２０は、返還された署名されたデータをノード１３１０に伝達してよい。

【0104】

一方、リーフチェーンでは、内部で処理した内容と伝達する内容とが異ならないようにしなければならない。このために、送金を処理したトランザクションのマークルツリーの証明ハッシュリストを、処理結果とともにイベントとして伝達するようにしなければならない。監視子が存在するのであれば、マークルツリーの証明情報まで伝達するかを決定する必要がある。伝達するイベント情報をコントラクトのプライベートキーによって署名してイベントに記録してよく、この場合、該当のトランザクションが処理されたということは分かるが、処理内容を変調したかどうかは把握することができないため、監視子が必要となることもある。このとき、監視子は、該当のブロックが存在するかどうかと、該当のトランザクションがイベントとして伝達したデータとともに、送金が成功したか失敗したかを確認してよい。監視子によって不正が発見されれば、該当のリーフチェーンには不利益が提供されてよい。ここで、監視子は、上述した機能を実行するノードの形態で実現されてよい。

【0105】

図１４は、本発明の一実施形態における、コイン交換方法の他の例を示した図である。同一するチェーンの同一するサービスにおけるコイン交換や、同一するチェーンの異なるサービス間のコイン交換については、図８の実施形態を参照しながら説明したとおりである。図１４は、図８の実施形態とは異なる実施形態であって、ルートチェーン１４１０、リーフチェーン１（１４２０）、およびリーフチェーン２（１４３０）を示しており、リーフチェーン１（１４２０）のユーザ１がリーフチェーン２（１４３０）のユーザ２に送金を要請した場合を仮定する。

【0106】

過程１は、リーフチェーン１（１４２０）で送金要請が正常な要請であるかを確認した後、問題がない場合には、送金要請に関する情報をルートチェーン１４１０に伝達する過程の例である。

【0107】

過程２は、ルートチェーン１４１０で送金要請が正常な要請であるかを確認した後、問題がない場合には、リーフチェーン２（１４３０）に送金が可能であるかに関する確認要請を送信する過程の例である。

【0108】

過程３は、リーフチェーン２（１４３０）で送金要請が受信可能な要請であるかを確認した後、問題がない場合には、ルートチェーン１４１０に受信が可能であるという応答を送信する過程の例である。

【0109】

過程４は、ルートチェーン１４１０がリーフチェーン１（１４２０）およびリーフチェーン２（１４３０）それぞれに、送金金額を差し引いたり増額したりする領収証を発行する過程の例である。過程４．１は、ルートチェーン１４１０がリーフチェーン１（１４２０）に送金金額を差し引くための領収証を発行する過程の例であり、過程４．２は、ルートチェーン１４１０がリーフチェーン２（１４３０）に送金金額を増額するための領収証を発行する過程の例である。各チェーンでは重複差引や重複増額が発生しないように管理されてよい。

【0110】

以下では、スマートコントラクトの構成について説明する。

【0111】

スマートコントラクトは、ルートチェーンの場合には、図４を参照しながら説明したように、ルートチェーンマネージャコントラクトを含んでよく、各リーフチェーンそれぞれのためのコントラクトを含んでよい。一方、リーフチェーンは、サービスＤＡｐｐが存在する場合にはリーフチェーンマネージャコントラクトとＤＡｐｐコントラクトを含んでよく、サービスＤＡｐｐが存在しない場合にはリーフチェーンマネージャコントラクトを含んでよい。ルートチェーンマネージャコントラクトとリーフチェーンマネージャコントラクトは、システムコントラクトであって、ブロックチェーンが設置されるときに自動で設置されてよい。リレイヤは、イベントログをフィルタリングしてそれぞれのチェーンに伝達してよい。各チェーンは、リレイヤがデータを変調できないように管理してよい。上述したように、ルートチェーンは、各リーフチェーンのプライベートキーによって生成されたパブリックアドレスを保存してよく、リーフチェーンは、ルートチェーンの固有のプライベートキーによって生成されるパブリックアドレスを、ジェネシスブロックを生成するときに記録してよい。リレイヤが伝達する情報をすべてルートチェーンの固有のプライベートキーによって署名した情報もともに伝達されるようにしてよい。

【0112】

また、リーフチェーンにサービスＤＡｐｐが存在する場合、ユーザは、ＤＡｐｐの「ｅｘｃｈａｎｇｅ」を定義した関数を呼び出してよい。このとき、ＤＡｐｐでは、ｉｃｘに定義された「ｅｘｃｈａｎｇｅ」を呼び出してよく、これにより、ｉｃｘクラスで「ｅｘｃｈａｎｇｅ」機能が実現される必要がある。

【0113】

一方、チェーン間の送金のために必要な情報は、以下のとおりとなる。

【0114】

・ｆｒｏｍ ｕｓｅｒ：送金をするユーザ
・ｏｒｉｇｉｎ：送金要請をしたサービスまたはリーフチェーン
・ｔｏ ｕｓｅｒ：送金を受けるユーザ
・ｄｅｓｔｉｎａｔｉｏｎ：送金を受けるサービスまたはリーフチェーン
・ｖａｌｕｅ：送金金額（ベースコイン）
・ｅＴｘＨａｓｈ：送金トランザクションハッシュ
・ｍｅｓｓａｇｅ：送金メッセージ
・ｅＳｉｇｎａｔｕｒｅ：データの伝達を要請したリーフチェーンの署名
ここで、リーフチェーンの署名は、ｆｒｏｍ ｕｓｅｒ、ｏｒｉｇｉｎ、ｔｏ ｕｓｅｒ、ｄｅｓｔｉｎａｔｉｏｎ、ｖａｌｕｅ、ｅＴｘＨａｓｈ、ｍｅｓｓａｇｅを組み合わせて署名した値を含んでよい。

【0115】

図１５は、本発明の一実施形態における、データ認証方法の第１例を示したフローチャートである。本実施形態に係るデータ認証方法は、ブロックチェーンネットワークのノードを実現するコンピュータ装置２００によって実行されてよい。例えば、コンピュータ装置２００のプロセッサ２２０は、メモリ２１０が含むオペレーティングシステムのコードと、少なくとも１つのプログラムのコードとによる制御命令を実行するように実現されてよい。ここで、プロセッサ２２０は、コンピュータ装置２００に記録されたコードが提供する制御命令にしたがってコンピュータ装置２００が図１５の方法に含まれる段階１５１０～１５４０を実行するようにコンピュータ装置２００を制御してよい。

【0116】

段階１５１０で、コンピュータ装置２００は、ブロックチェーンネットワークのチェーンを代表するプライベートキーを、ブロックチェーンネットワークでの合意に参加する少なくとも１つの他のノードと共有してよい。このとき、ノードは、ブロックチェーンネットワークでの合意をなすように予め設定された複数のノードのうちの１つであってよく、少なくとも１つの他のノードも、ブロックチェーンネットワークでの合意をなすように予め設定された複数のノードに含まれてよい。

【0117】

本実施形態に係るデータ認証方法は、上述した２つ目の方法で、チェーンを代表する１つのプライベートキーを該当のチェーンのＣノードが共有し、これをチェーン認証に活用する過程を説明する。言い換えれば、１つのノードを実現するコンピュータ装置２００はコンピュータ装置２００によって実現されるノードが参加するブロックチェーンネットワークのチェーンを代表するプライベートキーを少なくとも１つの他のノードと共有してよい。

【0118】

段階１５２０で、コンピュータ装置２００は、プライベートキーを利用して生成されるパブリックキーを利用してブロックチェーンネットワークのパブリックアドレスを生成してよい。上述したように、パブリックアドレスは、プライベートキーによって署名されたデータが該当のブロックチェーンネットワークから発送されたものであることを検証するために提供されてよい。

【0119】

一実施形態として、ブロックチェーンネットワークは、複数のリーフチェーン間のデータ送信を管理するルートチェーンを含んでよい。この場合、コンピュータ装置２００は、生成されたパブリックアドレスを複数のリーフチェーンそれぞれのジェネシスブロックに記録してよい。このとき、署名されたデータが送信されたリーフチェーンで署名されたデータとリーフチェーンのジェネシスブロックに記録されたパブリックアドレスとを比較することで、署名されたデータがルートチェーンから発送されたものであることを検証してよい。

【0120】

他の実施形態として、ブロックチェーンネットワークは、ルートチェーンによってデータ送信が管理される複数のリーフチェーンのうちの第１リーフチェーンを含んでよい。この場合、コンピュータ装置２００は、生成されたパブリックアドレスを、ルートチェーンに第１リーフチェーンと関連して設置されたリーフチェーンコントラクトに登録してよい。このとき、ルートチェーンで署名されたデータと該当のリーフチェーンコントラクトに登録されたパブリックアドレスをと比較することで、署名されたデータが第１リーフチェーンから発送されたものであることを検証してよい。

【0121】

段階１５３０で、コンピュータ装置２００は、ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、ブロックチェーンネットワークに設置されたコントラクトによってプライベートキーで署名してよい。このとき、署名されたデータが記録されたブロックがブロックチェーンネットワークのチェーンに追加されてよい。

【0122】

段階１５４０で、コンピュータ装置２００は、署名されたデータをコントラクトによって他のブロックチェーンネットワークに伝達してよい。このとき、署名されたデータとパブリックアドレスとの比較により、署名されたデータがブロックチェーンネットワークから発送されたものであることが検証されてよい。

【0123】

図１６は、本発明の一実施形態における、データ認証方法の第２例を示したフローチャートである。本実施形態に係るデータ認証方法は、ブロックチェーンネットワークのノードを実現するコンピュータ装置２００によって実行されてよい。例えば、コンピュータ装置２００のプロセッサ２２０は、メモリ２１０が含むオペレーティングシステムのコードと、少なくとも１つのプログラムのコードとによる制御命令を実行するように実現されてよい。ここで、プロセッサ２２０は、コンピュータ装置２００に記録されたコードが提供する制御命令にしたがってコンピュータ装置２００が図１６の方法に含まれる段階１６１０～１６３０を実行するようにコンピュータ装置２００を制御してよい。

【0124】

段階１６１０で、コンピュータ装置２００は、ノードのプライベートキーを利用してノードのパブリックアドレスを生成してよい。ノードのプライベートキーは、ノードがブロックチェーンネットワークで合意のために有している固有のプライベートキーであってよい。

【0125】

段階１６２０で、コンピュータ装置２００は、ブロックチェーンネットワークから他のブロックチェーンネットワークに伝達しようとするデータを、ノードのプライベートキーを利用して署名してよい。このとき、署名されたデータが記録されたブロックがブロックチェーンネットワークのチェーンに追加されてよい。

【0126】

段階１６３０で、コンピュータ装置２００は、署名されたデータを他のブロックチェーンネットワークに伝達してよい。このとき、前記パブリックアドレスを利用することで、前記署名されたデータが前記ブロックチェーンネットワークから発送されたものであることが検証されてよい。

【0127】

一実施形態において、ブロックチェーンネットワークは、複数のリーフチェーン間のデータ送信を管理するルートチェーンを含んでよい。このとき、ブロックチェーンネットワークで合意をなすように予め設定された複数のノード（本実施形態に係るコンピュータ装置２００が実現するノードを含む複数のノード）それぞれで生成されたパブリックアドレスが複数のリーフチェーンそれぞれに保存されてよい。この場合、署名されたデータが送信された第１リーフチェーンで署名されたデータと第１リーフチェーンに保存された複数のノードそれぞれのパブリックアドレスとを比較することで、署名されたデータがルートチェーンから発送されたものであることを検証してよい。

【0128】

他の実施形態において、ブロックチェーンネットワークは、ルートチェーンによってデータ送信が管理される複数のリーフチェーンのうちの第１リーフチェーンを含んでよい。このとき、ブロックチェーンネットワークで合意をなすように予め設定された複数のノード（本実施形態に係るコンピュータ装置２００が実現するノードを含む複数のノード）それぞれで生成されたパブリックアドレスが、ルートチェーンに第１リーフチェーンと関連して設置されたリーフチェーンコントラクトに登録されてよい。この場合、ルートチェーンで署名されたデータとリーフチェーンコントラクトに登録されたパブリックアドレスとを比較することで、署名されたデータが第１リーフチェーンから発送されたものであることを検証してよい。

【0129】

また他の実施形態において、ブロックチェーンネットワークは、複数のリーフチェーン間のデータ送信を管理するルートチェーンを含んでよい。このとき、ブロックチェーンネットワークで合意をなすように予め設定された複数のノード（本実施形態に係るコンピュータ装置２００が実現するノードを含む複数のノード）それぞれで生成されたパブリックアドレスの組み合わせによって生成される代表パブリックアドレスが、複数のリーフチェーンそれぞれに保存されてよい。この場合、署名されたデータが送信された第１リーフチェーンで署名されたデータと第１リーフチェーンに保存された代表パブリックアドレスとを比較することで、署名されたデータがルートチェーンから発送されたものであることを検証してよい。

【0130】

また他の実施形態において、ブロックチェーンネットワークは、ルートチェーンによってデータ送信が管理される複数のリーフチェーンのうちの第１リーフチェーンを含んでよい。このとき、ブロックチェーンネットワークで合意をなすように予め設定された複数のノード（本実施形態に係るコンピュータ装置２００が実現するノードを含む複数のノード）それぞれで生成されたパブリックアドレスの組み合わせによって生成される代表パブリックアドレスが、ルートチェーンに第１リーフチェーンと関連して設置されたリーフチェーンコントラクトに登録されてよい。この場合、ルートチェーンで署名されたデータとリーフチェーンコントラクトに登録された代表パブリックアドレスとを比較することで、署名されたデータが第１リーフチェーンから発送されたものであることを検証してよい。

【0131】

図１７は、本発明の一実施形態における、データ認証方法の第３例を示したフローチャートである。本実施形態に係るデータ認証方法は、ブロックチェーンネットワークのコントラクトによって動作するコンピュータ装置２００によって実行されてよい。例えば、コンピュータ装置２００のプロセッサ２２０は、メモリ２１０が含むオペレーティングシステムのコードと、少なくとも１つのプログラムのコードとによる制御命令を実行するように実現されてよい。ここで、プロセッサ２２０は、コンピュータ装置２００に記録されたコードが提供する制御命令にしたがってコンピュータ装置２００が図１７の方法に含まれる段階１７１０～１７６０を実行するようにコンピュータ装置２００を制御してよい。ここで、少なくとも１つのプログラムコードは、少なくともブロックチェーンネットワークのコントラクトによるコードを含んでよい。

【0132】

段階１７１０で、コンピュータ装置２００は、暗号化されたプライベートキーとプライベートキーで生成されるパブリックキーをパラメータとして受信してよい。

【0133】

段階１７２０で、コンピュータ装置２００は、受信したパブリックキーによってコントラクトアドレスを生成してよい。

【0134】

段階１７３０で、コンピュータ装置２００は、暗号化されたプライベートキーとコントラクトアドレスをデータベースに保存してよい。

【0135】

段階１７４０で、コンピュータ装置２００は、署名するデータと暗号化されたプライベートキーを復号するためのパスワードをパラメータとして含む署名要請を受信してよい。ここで、パスワードは、ブロックチェーンネットワークのブロックや、いずれのログにも保存されないシーキュアタイプが定義されてよい。

【0136】

段階１７５０で、コンピュータ装置２００は、署名要請に応答し、パスワードによって暗号化されたプライベートキーを復号し、復号されたプライベートキーによってデータを署名することで署名されたデータを生成してよい。このとき、署名されたデータが記録されたブロックが前記ブロックチェーンネットワークのチェーンに追加されてよい。

【0137】

段階１７６０で、コンピュータ装置２００は、生成された署名されたデータを返還してよい。このとき、署名されたデータは、データの署名を要請したノードに返還されてよい。

【0138】

一実施形態において、ブロックチェーンネットワークは、複数のリーフチェーン間のデータ送信を管理するルートチェーンを含んでよい。このとき、コンピュータ装置２００は、コントラクトアドレスを複数のリーフチェーンそれぞれのジェネシスブロックに記録してよい。この場合、署名されたデータを受信する第１リーフチェーンで署名されたデータと第１リーフチェーンのジェネシスブロックに記録されたコントラクトアドレスとを比較することで、署名されたデータがルートチェーンから発送されたものであることを検証してよい。

【0139】

他の実施形態において、ブロックチェーンネットワークは、ルートチェーンによってデータ送信が管理される複数のリーフチェーンのうちの第１リーフチェーンを含んでよい。このとき、コンピュータ装置２００は、コントラクトアドレスがルートチェーンのデータベースに保存されるように、コントラクトアドレスをルートチェーンに提供してよい。この場合、ルートチェーンで署名されたデータとルートチェーンのデータベースに保存されたコントラクトアドレスとを比較することで、署名されたデータが第１リーフチェーンから発送されたものであることを検証してよい。

【0140】

図１８は、本発明の一実施形態における、データ認証方法の第４例を示したフローチャートである。本実施形態に係るデータ認証方法は、ブロックチェーンネットワークのノードを実現するコンピュータ装置２００によって実行されてよい。例えば、コンピュータ装置２００のプロセッサ２２０は、メモリ２１０が含むオペレーティングシステムのコードと、少なくとも１つのプログラムのコードとによる制御命令を実行するように実現されてよい。ここで、プロセッサ２２０は、コンピュータ装置２００に記録されたコードが提供する制御命令にしたがってコンピュータ装置２００が図１８の方法に含まれる段階１８１０～１８６０を実行するようにコンピュータ装置２００を制御してよい。

【0141】

段階１８１０で、コンピュータ装置２００は、ブロックチェーンネットワークのノードのプライベートキーを暗号化して保存してよい。ここで、ノードは、ブロックチェーンネットワークで最初に生成されるノードであってよく、このようなノードでブロックチェーンネットワークのシステムコントラクトを設置する過程において署名可能コントラクトを自動設置してよい。この過程において、ノードのプライベートキーが署名可能コントラクトに伝達されてよい。このとき、署名可能コントラクトは、設置過程で伝達されるノードのプライベートキーを暗号化して保存してよい。

【0142】

段階１８２０で、コンピュータ装置２００は、暗号化されたプライベートキーを復号するためのパスワードをノードのパブリックキーによって暗号化して保存してよい。パスワードは、コンピュータ装置２００がプライベートキーを暗号化する過程において暗号化されたプライベートキーを復号できるように生成されてよい。一例として、対称キーによってプライベートキーを暗号化した場合、対称キーや対称キーを得るための値がパスワードによって生成されてよい。

【0143】

段階１８３０で、コンピュータ装置２００は、ノードのパブリックキーによって暗号化されたパスワードをノードに返還してよい。この場合、ノードは、暗号化されたパスワードを得てよい。このとき、暗号化されたパスワードは、ノードのパブリックキーによって暗号化されたため、ノードのプライベートキーによって暗号化されたパスワードを復号してパスワードを得ることができるようになる。一方、ブロックチェーンネットワークの他のノードは、暗号化されたパスワードが返還されたノードを検索して該当のノードに他のノードのパブリックキーを送信し、該当のノードから他のノードのパブリックキーによって暗号化されたパスワードを受信して他のノードに保存してよい。このような過程により、ブロックチェーンネットワークの他のノードも、暗号化されたプライベートキーを復号するためのパスワードを得ることができるようになる。この反面、プライベートキー自体は、暗号化された状態で保存されるため表示されなくてよい。一方、パスワードは、ブロックチェーンネットワークのブロックや、いずれのログにも保存されないシーキュアタイプが定義されてよい。

【0144】

段階１８４０で、コンピュータ装置２００は、ブロックチェーンネットワークの任意のノードから、パスワードおよびプライベートキーによって署名するためのデータをパラメータとして含む署名要請を受信してよい。任意のノードは、コンピュータ装置２００から暗号化されたパスワードが返還されたノードであるか、該当のノードからパスワードが伝達された他のノードであってよい。

【0145】

段階１８５０で、コンピュータ装置２００は、署名要請に応答し、パスワードによって暗号化されたプライベートキーを復号し、復号されたプライベートキーによってデータを署名することで署名されたデータを生成してよい。

【0146】

段階１８６０で、コンピュータ装置２００は、署名されたデータを返還してよい。このとき、署名されたデータは、データの署名を要請したノードに返還されてよい。

【0147】

一実施形態において、ブロックチェーンネットワークは、複数のリーフチェーン間のデータ送信を管理するルートチェーンを含んでよい。このとき、コンピュータ装置２００は、コントラクトアドレスを複数のリーフチェーンそれぞれのジェネシスブロックに記録してよい。この場合、署名されたデータを受信する第１リーフチェーンで署名されたデータと第１リーフチェーンのジェネシスブロックに記録されたコントラクトアドレスとを比較することで、署名されたデータがルートチェーンから発送されたものであることを検証してよい。

【0148】

他の実施形態において、ブロックチェーンネットワークは、ルートチェーンによってデータ送信が管理される複数のリーフチェーンのうちの第１リーフチェーンを含んでよい。このとき、コンピュータ装置２００は、コントラクトアドレスがルートチェーンのデータベースに保存されるようにコントラクトアドレスをルートチェーンに提供してよい。この場合、ルートチェーンで署名されたデータとルートチェーンのデータベースに保存されたコントラクトアドレスとを比較することで、署名されたデータが第１リーフチェーンから発送されたものであることを検証してよい。ルートチェーンは、上述したように、絶対信頼システムとして見なされてよい。

【0149】

以上のように、本発明の実施形態によると、ルートチェーンに基づいてリーフチェーンを追加する方式により、スケールアウトが可能なブロックチェーンで生成されるデータを認証する、データ認証方法およびシステムを提供することができる。

【0150】

上述したシステムまたは装置は、ハードウェア構成要素、ソフトウェア構成要素、またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを記録、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。

【0151】

ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置、コンピュータ記録媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で記録されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読み取り可能な記録媒体に記録されてよい。

【0152】

実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読み取り可能な媒体に記録されてよい。コンピュータ読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独または組み合わせて含んでよい。前記媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであっても、コンピュータソフトウェア当業者に公知な使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体、ＣＤ－ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスクのような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して実行するように特別に構成されたハードウェア装置が含まれる。このような記録媒体は、単一または複数のハードウェアが結合した形態の多様な記録手段または格納手段であってよく、あるコンピュータシステムに直接接続する媒体に限定されてはならず、ネットワーク上で分散して存在するものであってもよい。プログラム命令の例は、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。

【0153】

以上のように、実施形態を、限定された実施形態および図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。

【0154】

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】