JP7016389B1 - システム及びプログラム - Google Patents

Abstract

【課題】分散型台帳技術において、取引要求に対する処理の高速化又は複数のノード間において整合性を確保するシステム及びプログラムを提供する。【解決手段】分散型台帳システム１０において、台帳を分散して記録する複数のノード１００～１０３のうち１つの第１ノードは、複数のノードのうち第１ノードとは異なる複数の第２ノードに、クライアント端末から受信した複数のトランザクションに基づく複数のログの合計を送信する。第１ノードは、複数の第２ノードに対して、複数のログを送信せずに複数のログの合計を送信してもよい。【選択図】図２

Description

本発明は、分散型台帳技術に関するシステム及びプログラムに関する。

ブロックチェーンを用いた分散型台帳技術が、ビットコイン等の暗号資産（仮想通貨）を管理する方法として用いられている。近年では、これらの技術は、このような暗号資産だけではなく、様々な資産を管理したり移動したりする方法として用いることも検討されている（例えば、特許文献１）。

特開２０１８－１９６１５０号公報

特許文献１に示した分散型台帳技術では、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）によって接続された複数のノード（１つのリーダノード及びその他の複数のフォロワノード）によって分散台帳ネットワークが形成され、当該分散台帳ネットワークにおける複数のノードによって台帳が分散して記録される。

上記のような従来の分散型台帳技術においては、クライアント端末からの取引要求に対する処理の高速化及び複数のノード間における整合性の確保は重要な課題である。

本発明の目的の一つは、分散型台帳技術において、取引要求に対する処理の高速化又は複数のノード間において整合性を確保することである。

本発明の一実施形態に係るシステムは、台帳を分散して記録する複数のノードのうち１つの第１ノードが、前記複数のノードのうち前記第１ノードとは異なる複数の第２ノードに、クライアント端末から受信した複数のトランザクションに基づく複数のログの合計を送信する。

前記第１ノードは前記複数の第２ノードに対して、前記複数のログを送信せずに前記複数のログの合計を送信させてもよい。

前記第１ノードは、前記クライアント端末から前記複数のトランザクションを含むブロック単位で前記複数のトランザクションを受信し、前記ブロックに含まれる前記複数のトランザクションに基づいて前記複数のログを生成し、前記複数の第２ノードに対して複数の前記ブロックに含まれる前記複数のログを合計した結果を送信してもよい。

前記第１ノードは前記複数のログを記憶してもよい。

本発明の一実施形態に係るプログラムは、台帳を分散して記録する複数のノードのうち１つの第１ノードに対して、前記複数のノードのうち前記第１ノードとは異なる複数の第２ノードに、クライアント端末から受信した複数のトランザクションに基づく複数のログの合計を送信することを実行させる。

前記第１ノードに対して、前記複数の第２ノードへ前記複数のログを送信させずに前記複数のログの合計を送信させてもよい。

前記第１ノードに、前記クライアント端末から前記複数のトランザクションを含むブロック単位で前記複数のトランザクションを受信させ、前記ブロックに含まれる前記複数のトランザクションに基づいて前記複数のログを生成させ、前記複数の第２ノードに対して複数の前記ブロックに含まれる前記複数のログを合計した結果を送信させてもよい。

前記第１ノードに前記複数のログを記憶させてもよい。

本発明の一実施形態によれば、分散型台帳技術において、取引要求に対する処理の高速化又は複数のノード間において整合性を確保することができる。

本発明の一実施形態に係る分散型台帳システムの概要を示す図である。 本発明の一実施形態に係る分散型台帳システムの概要を示す図である。 本発明の一実施形態に係る分散型台帳システムの概要を示す図である。 本発明の一実施形態に係る分散型台帳システムに用いられるリーダノードの機能構成を示すブロック図である。 本発明の一実施形態に係る分散型台帳システムにおけるトランザクション及びログの具体例を示す図である。 本発明の一実施形態に係る分散型台帳システムにおけるログの断面及びログの最終断面の具体例を示す図である。 本発明の一実施形態に係る分散型台帳システムに用いられるクライアント端末の機能構成を示すブロック図である。 本発明の一実施形態に係る分散型台帳システムに用いられるフォロワノードの機能構成を示すブロック図である。 本発明の一実施形態に係る分散型台帳システムの動作を示すシーケンスを示す図である。 本発明の一実施形態に係る分散型台帳システムの動作を示すフローチャートを示す図である。 本発明の一実施形態に係る分散型台帳システムに用いられるリーダノードの機能構成を示すブロック図である。 本発明の一実施形態に係る分散型台帳システムに用いられるクライアント端末の機能構成を示すブロック図である。 本発明の一実施形態に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。 本発明の一実施形態の変形例に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。 本発明の一実施形態の変形例に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。 本発明の一実施形態に係る分散型台帳システムにおけるデータ同期アルゴリズムの動作を示すフローチャートを示す図である。

以下、本発明の一実施形態について、図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこの実施形態に限定して解釈されるものではない。すなわち、以下に説明する複数の実施形態に公知の技術を適用して変形をして、様々な態様で実施をすることが可能である。なお、本実施の形態で参照する図面において、同一部分又は同様な機能を有する部分には同一の符号又は同一の符号の後にアルファベットを付し、その繰り返しの説明は省略する。

以下の説明において、トランザクション（ＴＸ）は、クライアント端末（ＣｌｉｅｎｔＭａｃｈｉｎｅ；ＣＭ）が要求する取引の内容を含む情報である。トランザクションは、互いに関連又は依存する複数の処理によって構成され、当該複数の処理は一体不可分の処理単位として扱われる。具体的には、当該複数の処理の全てが成功した場合には当該トランザクションに関連する取引が成立したと判断され、当該複数の処理の一部が失敗した場合には当該トランザクションに関連する取引が失敗したと判断される。換言すると、トランザクションを構成する複数の処理は、「すべて成功」又は「すべて失敗」のいずれかの結果になることが保証される。例えば、コンピュータ間で入出金処理が行われる場合、入金処理及び出金処理は「どちらも成功」又は「どちらも失敗」であることが要求される。

ログ（又はトランザクションログ）は、複数のトランザクションが整列された情報である。具体的には、ログは、複数のトランザクションに基づいてデータベースの更新が行われる順番を記録したものである。ログは、トランザクションによって規定されたデータの追加、更新、削除などの更新内容を時系列に記録する。システム障害などで処理が中断又は取り消されると、分散型台帳システムは、ログの記録を参照して更新済みのデータを元に戻し、トランザクション開始前の状態に戻す。

以下の実施形態では、分散型台帳システムに含まれるリーダノード（ＬｅａｄｅｒＮｏｄｅ；ＬＮ）及びフォロワノード（ＦｏｌｌｏｗｅｒＮｏｄｅ；ＦＮ）として、例えばサーバのような固定された情報処理装置が用いられた構成を例示するが、この構成に限定されない。また、特に技術的な矛盾が生じない限り、異なる実施形態間の技術を組み合わせることができる。

〈第１実施形態〉
［１－１．システムの概要］
図１～図１０を用いて、本発明の第１実施形態に係る分散型台帳システム１０、分散型台帳システム１０を構成する情報処理装置（ノード１００）、及びノード１００に接続されるクライアント端末４００、並びに、これらを動作させるためのプログラムについて説明する。図１～図３は、本発明の一実施形態に係る分散型台帳システムの概要を示す図である。

図１に示すように、分散型台帳システム１０は日本全国各地に台帳（データベース；ＤＢ）が配置されており、これらの台帳は互いに同期している。つまり、各クライアントは日本全国のどの台帳からでも分散型台帳システム１０にアクセスして取引を要求することができ、取引によって更新されたデータは各台帳で同期して格納される。例えば、北海道に配置された台帳３１（この例におけるリーダノード）に対してクライアント端末４１から「再配達の費用請求」の取引要求（トランザクション）があった場合、台帳３１によって当該取引の順序を示す情報（ログ）が生成され、当該ログは他の台帳３２～３８（この例におけるフォロワノード）に送信され、当該ログに応じたデータ更新が各台帳３１～３８で行われる。このようにして、台帳３１に対して要求された取引に基づいて日本全国各地に配置された台帳３１～３８の同期処理が行われる。

図１に示すように、分散型台帳システム１０は、従来の仮想通貨や資産管理のように人が主体となって取引要求を行うシステムに適用することができる。例えば、分散型台帳システム１０が、上記のクライアント端末４１を用いた「再配達の費用請求」やクライアント端末４２を用いた「部屋の貸し出し」などのシステムに適用されてもよい。また、分散型台帳システム１０は、例えばＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ；モノのインターネット）のように端末が主体となって取引要求を行うシステムに適用することもできる。例えば、分散型台帳システム１０が、コンテンツの視聴に係る自動課金（例えば、クライアント端末４３による時間課金）、電子書籍の通読に係る自動課金（例えば、クライアント端末４４によるページ課金）、及びクライアント端末４５による臨時の充電により発生する自動課金など、１円単位又は１円未満の費用請求（マイクロペイメント）が発生しうるサービスに適用されてもよい。また、分散型台帳システム１０は、複数の独立した機能を組み合わせることで実現されるマイクロサービスに適用されてもよい。

図２に示すように、クライアント端末４００とノード１００とは、ネットワーク５００を介して通信可能に接続されている。また、各ノード１００は、専用ネットワーク６００を介して通信可能に接続されている。各ノード１００は、台帳（データベース）を分散して記録するノードである。なお、本実施形態では、３つのノード１０１、１０２、１０３を特に区別する必要がない場合、単にノード１００という。また、３つのクライアント端末４０１、４０２、４０３を特に区別する必要がない場合、単にクライアント端末４００という。

ノード１０１、１０２、１０３は、それぞれサーバ１１１、１１２、１１３及びデータベース１２１、１２２、１２３を含む。これらのサーバ及びデータベースを特に区別する必要がない場合、単にサーバ１１０及びデータベース１２０という。サーバ１１０はデータベース１２０に対してデータの記録処理及び読み出し処理（データ更新）を実行する。サーバ１１０は、中央演算処理装置（ＣＰＵ）及び記憶装置（メモリ）を有しており、これらが協働することで、以下に説明する各種機能を実現する。具体的には、記憶装置に格納されたプログラムをＣＰＵが実行することで、サーバ１１０の各種機能が実現される。記憶装置は一時的な記憶を行う揮発性の記憶装置であってもよく、不揮発性の記憶装置であってもよく、これらの記憶装置を組み合わせたものであってもよい。

各クライアント端末４００から送信されたトランザクションは、ネットワーク５００を介して、例えばサーバ１１１によって受信される。サーバ１１１において、受信したトランザクションに応じてログの生成が行われる。生成されたログはサーバ１１１に接続されたデータベース１２１に格納される。

サーバ１１１は、専用ネットワーク６００を介して、上記ログをサーバ１１２、１１３に送信する。ログを受信したサーバ１１２、１１３は、当該ログをそれぞれのサーバ１１２、１１３に接続されたデータベース１２２、１２３に格納すると、ログを適正に受信し格納したことを示す応答をサーバ１１１に送信する。この動作を「合意」又は「合意形成」という。サーバ１１１は、サーバ１１２、１１３からの合意形成が確認されると、ログの複製が正常に行われたと判断する。ログの複製が正常に行われると、当該ログに基づいて各サーバ１１１、１１２、１１３に接続されたデータベース１２１、１２２、１２３の更新が行われる。このようにして、クライアント端末４００から１つのノード１０１に送信されたトランザクションに基づくデータ更新が各ノードで同期して行われる。

なお、データベース１２１に格納されたログは、後の工程でデータの不整合が発生した場合に、誤ったデータが格納されたデータベースを修正するために用いられる。

ネットワーク５００は、一般的なＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）のようなインターネット、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、又は社内ＬＡＮなどのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。

専用ネットワーク６００は、ネットワーク５００とは異なり、分散型台帳システム１０の専用のネットワークである。つまり、専用ネットワーク６００は、クライアント端末４００がアクセスすることができないネットワークである。

図１及び図２では説明を省略したが、図２に示す各ノード１００は、図３に示すように、１つのリーダノード２００と複数のフォロワノード３００として機能する。リーダ選出によって複数のノード１００から選出された１つのノード１００がリーダノード２００として機能し、その他のノード１００はフォロワノード３００として機能する。リーダノード２００としての機能は、定期的に又はイベント発生をトリガとして次のノード１００に引き継がれる。ただし、リーダノード２００は固定されていてもよい。なお、図３のリーダノード２００及びフォロワノード３００は、それぞれサーバ及びデータベースを有しており、図２のノード１００のように動作する。

図３に示すように、リーダノード２００には複数のクライアント端末４００が接続されている。複数のクライアント端末４００の各々は、例えば、サービス提供事業者の通信端末であり、例えば、携帯通信端末サービス、自動車サービス、ＩｏＴサービスなどのサービスを提供する事業者が有する情報処理装置（ハードウェア）である。各クライアント端末４００において、複数のクライアントプロセス（ＣｌｉｅｎｔＰｒｏｃｅｓｓ）４１０（ソフトウェア）が起動している。例えば、一般的に、情報処理装置として使用されるコンピュータには複数のＣＰＵコアが搭載されているため、処理の並列度を向上させるためにＣＰＵコアの数だけ以下のクライアントプロセス４１０を起動してもよい。ただし、上記のサービス提供事業者は単なる一例であり、上記以外の様々なサービス提供事業者に適用することができる。また、複数のクライアントプロセス４１０は単一のＣＰＵによって実現されてもよい。

クライアントプロセス４１１－１、４１１－２、・・・、４１１－ｎは、クライアント端末４０１上で動作する。クライアントプロセス４１２－１、４１２－２、・・・、４１２－ｎは、クライアント端末４０２上で動作する。クライアントプロセス４１３－１、４１３－２、・・・、４１３－ｎは、クライアント端末４０３上で動作する。クライアントプロセス４１４－１、４１４－２、・・・、４１４－ｎは、クライアント端末４０４上で動作する。上記の複数のクライアントプロセスを特に区別する必要がない場合、単にクライアントプロセス４１０という。

複数のクライアントプロセス４１０の各々は、各ユーザによって使用されるユーザ端末から取引要求を受け付け、当該取引要求に対応するトランザクションを生成してリーダノード２００に送信する。本実施形態では、クライアントプロセス４１０は、ユーザ端末からの取引要求毎にトランザクションをリーダノード２００に送信するが、ユーザ端末からの複数の取引要求に対応する複数のトランザクションを蓄積してから、これら複数のトランザクションを１回の通信でまとめてリーダノード２００に送信してもよい。詳細は後述するが、複数のトランザクションを１回の通信でまとめて送信する場合、リーダノード２００にまとめて送信される複数のトランザクションはブロック単位で扱われる。

図３の例では、クライアント端末４０１のクライアントプロセス４１１－１は、トランザクションＴＸ１～ＴＸ１４９をリーダノード２００に送信する。クライアント端末４０１のクライアントプロセス４１１－２は、トランザクションＴＸ１５０～ＴＸ５００をリーダノード２００に送信する。クライアント端末４０２のクライアントプロセス４１２－１は、トランザクションＴＸ５０１～ＴＸ１０００をリーダノード２００に送信する。上記の各トランザクションは、クライアントプロセス４１０とリーダノード２００との間の各々の通信で、クライアントプロセス４１０からリーダノード２００に送信される。

リーダノード２００は、例えば、各クライアント端末４００から受信した複数のトランザクションＴＸ１～ＴＸ１０００を順に整列させる。つまり、データ更新を行う処理順を決定する。このように複数のトランザクションＴＸ１～ＴＸ１０００及びそれらが整列した順序に基づいて、それぞれログが生成される。ログは各トランザクションＴＸに対応して生成される。つまり、トランザクションＴＸ１に対してログ１が生成される。また、上記と同様に、複数のトランザクションＴＸ１～ＴＸ１０００に基づいて、複数のログ１～ログ１０００が生成される。

リーダノード２００は、上記のようにして生成されたログ１～１０００の各々のログを個別に各フォロワノード３０１、３０２、３０３、３０４に送信するのではなく、これらのログに基づいて、各ログに対する計算を行い、当該計算の結果に基づくログの合計を各フォロワノード３０１、３０２、３０３、３０４に送信する。ここで、上記の複数のフォロワノードを特に区別する必要がない場合、単にフォロワノード３００という。各ログに対する計算結果を「ログの断面」という場合、ログ１～１０００の全てのログに対する計算結果（ログの合計）を「ログの最終断面」ということができる。この場合、リーダノード２００はフォロワノード３００に、ログ１～１０００の最終断面のみを送付する、ということができる。

フォロワノード３００は、リーダノード２００から上記のログの最終断面を受信して格納すると、合意形成したことをリーダノード２００に返信する。リーダノード２００は、フォロワノード３００からの合意形成を確認すると、フォロワノード３００によってログの最終断面の複製が正常に行われたと判断する。なお、ログの最終断面の正常な複製を判断する具体的な手法については、後述する。

リーダノード２００がログの最終断面の正常な受信が行われたと判断すると、リーダノード２００は、当該ログの最終断面に基づいて、リーダノード２００のデータ更新を行う。そして、フォロワノード３００は、リーダノード２００と同様に上記ログの最終断面に基づいてデータの更新を行う。リーダノード２００がデータ更新を行うタイミングとフォロワノード３００がデータ更新を行うタイミングは同じでなくてもよい。例えば、リーダノード２００がデータ更新を行った後に、次のサイクルでリーダノード２００からフォロワノード３００にログを送信するタイミングで、フォロワノード３００がリーダノード２００の状態を参照してリーダノード２００と同様のデータ更新を行ってもよい。

このデータ更新の後に、各フォロワノード３００において更新されたデータ間の整合性の評価が行われる。各フォロワノード３００間で更新後のデータに不整合があった場合は、当該不整合を修正するための修正処理が行われる。このような処理によって、各フォロワノード３００間の同期が取られる。

従来の仮想通貨や資産管理の取引では、個々の取引の処理速度が重要であり、各トランザクションに応じたログ毎に処理が行われていた。つまり、リーダノード２００からフォロワノード３００に送信される個々のログに対する処理速度を向上させることを目的としていた。一方、第１実施形態に係る分散型台帳システム１０では、個々のログに対する処理速度を向上させるのではなく、複数のログを合計して処理を行うことで、総合的な処理速度を向上させることを目的としている。

［１－２．リーダノード２００の機能］
図４を用いて、本実施形態に係る分散型台帳システム１０のリーダノード２００の機能を説明する。図４は、本発明の一実施形態に係る分散型台帳システムに用いられるリーダノードの機能構成を示すブロック図である。図４に示すように、リーダノード２００は、ＣＭ通信部２１０、ＴＸ受信部２２０、整列処理部２３０、ログ生成部２４０、最終断面計算部２４５、分散処理部２５０、及びデータ更新部２６０を有する。これらの機能部は通信バス２９０によって互いに通信可能に接続されている。これらの機能部の機能は、リーダノード２００に備えられた記憶装置に格納されたプログラムをＣＰＵが実行することで実現される。

ＣＭ通信部２１０は、各クライアント端末４００から通信確立要求を受信すると、クライアント端末４００とリーダノード２００との通信を確立する機能を有する。なお、当該通信の確立及び終了のプロトコルとして、例えばＴＣＰを利用することができる。

ＴＸ受信部２２０は、ＣＭ通信部２１０によって上記の通信が確立されると、クライアント端末４００から各トランザクション（例えば、ＴＸ１～ＴＸ１０００）を受信する。

整列処理部２３０は、ＴＸ受信部２２０が受信した複数のトランザクションに対して順に整列する処理を行う。整列処理部２３０は、ＴＸ受信部２２０が受信した順にトランザクションを整列してもよく、ある特定の規則に従ってトランザクションを整列してもよい。

ログ生成部２４０は、整列処理部２３０によって整列された複数のトランザクションの処理内容及び順序を記録したログを生成する。なお、リーダノード２００のログ生成部２４０によって生成されたログ（マスターログ）は、リーダノード２００の記憶装置に格納される。マスターログがリーダノード２００に格納されていることで、リーダノード２００とフォロワノード３００との間、又は複数のフォロワノード３００間で不整合が発生した場合に、マスターログを用いてログの最終断面を計算し直すことができる。

最終断面計算部２４５は、ログ生成部２４０によって生成された各ログの断面に基づいて、ログの最終断面を計算する。具体的には、最終断面計算部２４５は、データ更新を行う更新対象（例えば、口座番号）毎にデータ更新内容（例えば、振込金額）に基づく計算を行うことで、各更新対象における最終的な更新内容の合計を算出する。最終断面計算部２４５は、所定の期間に生成されたログに対して最終断面を計算してもよく、生成されたログの数がしきい値に達した場合に、しきい値に達するまでの間に生成されたログに対して最終断面を計算してもよい。

分散処理部２５０は、最終断面計算部２４５によって生成されたログの最終断面を複数のフォロワノード３００に送信（分散処理）する。例えば、分散処理部２５０は、［ＡｐｐｅｎｄＥｎｔｒｉｅｓ ＰＲＣ］を使って、生成された全てのログの最終断面を複数のフォロワノード３００に送信する。分散処理部２５０は、フォロワノード３００からログの最終断面を正常に格納したことを確認すると、ログの最終断面の複製が正常に行われたと判断する。

データ更新部２６０は、分散処理部２５０によってログの最終断面の複製が正常に行われたと判断されると、リーダノード２００のデータベースに対してログの最終断面に応じたデータ更新を実行する。そして、データ更新が完了したことをクライアントプロセス４１０に応答する。なお、この段階では、フォロワノード３００のデータベースに対してデータ更新が実行されていないが、リーダノード２００のデータ更新と共にフォロワノード３００のデータ更新が行われてもよい。

［１－３．トランザクション及びログの具体例］
図５は、本発明の一実施形態に係る分散型台帳システムにおけるトランザクション及びログの具体例を示す図である。図５に示すように、トランザクションＴＸ１は、口座番号ＡＡＡから口座番号ＢＢＢに１０万円移動する、という取引要求に基づくトランザクションである。トランザクションＴＸ２は、口座番号ＢＢＢから口座番号ＣＣＣに２０万円移動する、という取引要求に基づくトランザクションである。

複数のトランザクションＴＸ１、ＴＸ２は、同一のクライアントプロセス４１１－１から送信される。そのため、図５のように、複数のトランザクションＴＸ１、ＴＸ２の両方が同一の更新対象である口座番号ＢＢＢに対する更新処理の要求を含む場合がある。したがって、これらのトランザクション間で不整合が起きないように、ＴＸ１、ＴＸ２の順で整列させる。そして、ＴＸ１、ＴＸ２の順で、それぞれのトランザクションに応じたログ１、ログ２が生成される。なお、図５では、複数のトランザクションが同一の更新対象に対する更新処理を要求する場合を含む構成が例示されているが、複数のトランザクションが同一の更新対象に対する更新処理を要求してなくてもよい。

なお、ＴＸ１は、具体的には以下（１）～（６）の処理を含む。
（１）口座番号ＡＡＡの残高を取得する（口座番号ＡＡＡの残高は１００万円）。
（２）口座番号ＢＢＢの残高を取得する（口座番号ＢＢＢの残高は１０００万円）。
（３）口座番号ＡＡＡから１０万円引いた場合の金額を計算する（９０万円）。
（４）口座番号ＢＢＢに１０万円足した場合の金額を計算する（１０１０万円）。
（５）口座番号ＡＡＡに９０万円と書き込む。
（６）口座番号ＢＢＢに１０１０万円と書き込む。

ＴＸ１の（１）～（６）の処理は一体不可分として扱われる。つまり、（１）～（６）の処理が全て成功した場合にＴＸ１が成立したと判断され、（１）～（６）の少なくともいずれか一つの処理が失敗した場合はＴＸ１が失敗したと判断される。ＴＸ２に関してもＴＸ１の場合と同様に扱われる。

［１－４．ログの最終断面の具体例］
「ログの断面」及び「ログの最終断面」について、具体的な例を用いて説明する。図６は、本発明の一実施形態に係る分散型台帳システムにおけるログの断面及びログの最終断面の具体例を示す図である。図６では、ログ１～１０００のうち、ログ１、ログ１５０、及びログ１０００の処理内容が示されている。

ログ１の断面には、口座ＡＡＡに１０万円と書き込む処理（例えば、残高が０円の口座ＡＡＡに１０万円を振り込む処理）、及び口座ＢＢＢに１００万円と書き込む処理（例えば、残高が０円の口座ＢＢＢに１００万円を振り込む処理）が記録されている。ログ１５０の断面には、口座ＡＡＡに２０万円と書き込む処理（例えば、残高が１０万円の口座ＡＡＡに１０万円を振り込む処理）、及び口座ＢＢＢに１００万円と書き込む処理（例えば、残高が０円の口座ＣＣＣに１００万円を振り込む処理）が記録されている。ログ１０００の断面には、口座ＡＡＡに３０万円と書き込む処理（例えば、残高が２０万円の口座ＡＡＡに１０万円を振り込む処理）、及び口座ＢＢＢに５０万円と書き込む処理（例えば、残高が１００万円の口座ＢＢＢから他の口座に５０万円を振り込む処理）が記録されている。

従来は各ログがリーダノード２００からフォロワノード３００に送信されていたが、本実施形態では、リーダノード２００においてログ１～１０００の各断面が合計され、最終的な、口座ＡＡＡに３０万円と書き込み、口座ＢＢＢに５０万円と書き込み、口座ＣＣＣに１００万円と書き込むという、ログ１～１０００の最終断面が計算される。そして、当該最終断面だけがリーダノード２００からフォロワノード３００に送信される。つまり、リーダノード２００は、複数のログの代わりに、複数のログの最終断面をフォロワノード３００に送信する。

［１－５．クライアント端末４００の機能］
図７を用いて、本実施形態に係る分散型台帳システム１０のクライアント端末４００の機能を説明する。図７は、本発明の一実施形態に係る分散型台帳システムに用いられるクライアント端末の機能構成を示すブロック図である。図７に示すように、クライアント端末４００は、取引要求受信部４２０、ＴＸ生成部４３０、ＬＮ通信部４５０、及びＴＸ送信部４６０を有する。これらの機能部は通信バス４９０によって互いに通信可能に接続されている。これらの機能部の機能は、クライアント端末４００に備えられた記憶装置に格納されたプログラムをＣＰＵが実行することで実現される。なお、上記の各機能部は、クライアント端末４００の各クライアントプロセス４１０によって実行される。

取引要求受信部４２０は、クライアントプロセス４１０に接続されるユーザ端末から取引要求を受信する。取引要求受信部４２０は、同一のユーザ端末から取引要求を受信してもよく、異なるユーザ端末から取引要求を受信してもよい。

ＴＸ生成部４３０は、取引要求受信部４２０が受信した取引要求の内容に応じたトランザクションＴＸを生成する。トランザクションＴＸは、取引要求毎に生成される。

ＬＮ通信部４５０は、リーダノード２００のＣＭ通信部２１０に通信確立要求を送信する。ＬＮ通信部４５０は、ＴＸ生成部４３０によってトランザクションＴＸが生成される度に通信確立要求をＣＭ通信部２１０に送信する。

ＴＸ送信部４６０は、ＬＮ通信部４５０によって通信が確立されると、ＴＸ生成部４３０によって生成されたトランザクションＴＸをリーダノード２００のＴＸ受信部２２０に送信する。

［１－６．フォロワノード３００の機能］
図８を用いて、本実施形態に係る分散型台帳システム１０のフォロワノード３００の機能を説明する。図８は、本発明の一実施形態に係る分散型台帳システムに用いられるフォロワノードの機能構成を示すブロック図である。図８に示すように、フォロワノード３００は、断面受信部３１０、断面格納部３２０、合意形成部３３０、及びデータ更新部３４０を有する。これらの機能部は通信バス３９０によって互いに通信可能に接続されている。これらの機能部の機能は、フォロワノード３００に備えられた記憶装置に格納されたプログラムをＣＰＵが実行することで実現される。

断面受信部３１０は、分散処理部２５０によって送信されたログの最終断面を受信する。断面格納部３２０は、断面受信部３１０によって受信されたログの最終断面をフォロワノード３００に備えられた記憶装置又はデータベースに格納する。合意形成部３３０は、断面格納部３２０によってログの最終断面の格納が正常に行われた場合に、合意形成したことをリーダノード２００に返信する。データ更新部３４０は、断面受信部３１０がログの最終断面を受信する際にリーダノード２００のデータを確認し、リーダノード２００のデータに応じてフォロワノード３００のデータベースに対してログの最終断面に応じたデータ更新を実行する。

［１－７．分散型台帳システム１０の動作］
図９は、本発明の一実施形態に係る分散型台帳システムの動作を示すシーケンスを示す図である。まず、クライアント端末４００においてユーザ端末からの取引要求に応じたトランザクションＴＸが生成される（ステップＳ７０１）。生成されたトランザクションＴＸはリーダノード２００に送信される（ステップＳ７０２）。

リーダノード２００において、トランザクションＴＸが受信されると（ステップＳ７１１）、受信されたトランザクションＴＸは、例えば受信された順に整列される（ステップＳ７１２）。そして、整列されたトランザクションＴＸの処理内容及び順序に基づいてログが生成される（ステップＳ７１３）。生成されたログの数がしきい値に到達すると（ステップＳ７１４）、しきい値に達するまでの間に生成されたログに対してログの最終断面の計算が行われる（ステップＳ７１５）。計算されたログの最終断面はリーダノード２００から複数のフォロワノード３０１、３０２に送信される（ステップＳ７１６）。

フォロワノード３０１、３０２において、リーダノード２００から送信されたログの最終断面が受信されると、各々のフォロワノードにログの最終断面を格納する処理が行われる（ステップＳ７２１、Ｓ７３１）。ログの最終断面の格納が正常に行われると、合意形成したことをリーダノード２００に返信する（ステップＳ７２２、Ｓ７３２）。リーダノード２００は、合意形成を確認することで、フォロワノード３０１、３０２においてログの最終断面が正常に複製されたと判断し、データ更新を行う（ステップＳ７１７）。そして、リーダノード２００はデータ更新が正常に行われたことをクライアント端末４００に通知する（ステップＳ７１８、Ｓ７０３）。

なお、図９では、フォロワノード３０１、３０２において、ログの最終断面に基づくデータ更新が行われていないが、次のサイクルでログの最終断面がリーダノード２００からフォロワノード３０１、３０２に送信されるタイミングで、フォロワノード３０１、３０２がリーダノード２００の状態を参照してリーダノード２００と同様に前のサイクルで受信したログの最終断面に基づいてデータ更新を行う。ただし、フォロワノード３０１、３０２のログの最終断面に基づくデータ更新は、リーダノード２００のデータ更新と同じタイミングで行われてもよい。

図１０は、本発明の一実施形態に係る分散型台帳システムの動作を示すフローチャートを示す図である。図１０のフローチャートにおいて、図９のシーケンスと同様のステップには図９と同じ符号を付した。動作フローが開始し、トランザクションＴＸが発生（ステップＳ７０１）してからログの生成（ステップＳ７１３）が行われるまでのフローは図９と同じなので、説明を省略する。

Ｓ７１３のログ生成の後に、ログの最終断面を計算する条件が整っているかどうかの判定が行われる（ステップＳ８０２）。Ｓ８０２において、ログの最終断面を計算する条件が整っていないと判定された場合（ステップＳ８０２の「Ｎｏ」）、Ｓ７０１まで戻り、次のトランザクションＴＸの発生を待つ。一方、Ｓ８０２において、ログの最終断面を計算する条件が整っていると判定された場合（ステップＳ８０２の「Ｙｅｓ」）、ログの最終断面の計算が行われる（ステップＳ７１５）。Ｓ８０２において、例えば生成されたログの数がしきい値に到達しているか否かを判定する。この場合、生成されたログの数がしきい値に到達している場合、ログの最終断面を計算する条件が整っていると判定する。そして、Ｓ７１５で計算されたログの最終断面はリーダノード２００からフォロワノード３００に送信される（ステップＳ７１６）。

Ｓ７１６の後に、リーダノード２００によって合意形成の確認が行われる（ステップＳ８０３）。Ｓ８０３において、全てのフォロワノード３００から合意形成の確認が取れない場合（ステップＳ８０３の「Ｎｏ」）、Ｓ７１６→Ｓ８０３のステップを繰り返す。一方、全てのフォロワノード３００から合意形成が確認されると（ステップＳ８０３の「Ｙｅｓ」）、リーダノード２００においてデータ更新（ステップＳ７１７）及び完了通知（ステップＳ７１８）が行われる。続いて、フォロワノード３００においてＳ７１７と同様のデータ更新が行われる（ステップＳ８０４）。

従来の分散型台帳技術では、クライアント端末によって要求される個々の取引を迅速に処理することが要求されていた。そのため、当該取引に関連するトランザクションに基づいてログが生成される度に、個々のログがリーダノードからフォロワノードに送信されていた。しかし、ログの送信を行う度にリーダノードとフォロワノードとの通信を確立する必要があるため、複数のログを送信するための時間が長くなってしまい、スループットが低下してしまうという問題があった。

しかし、本実施形態に係る分散型台帳システム１０によると、リーダノード２００とフォロワノード３００との１回の通信の確立において、複数のログが合計されたログの最終断面をリーダノード２００からフォロワノード３００に送信することができる。したがって、分散台帳ネットワークにおけるノード間の同期処理におけるスループットを向上させることができる。

〈第２実施形態〉
図１１～図１６を用いて、本発明の第２実施形態に係る分散型台帳システム１０Ａについて説明する。以下の説明において、分散型台帳システム１０Ａの構成のうち、第１実施形態に係る分散型台帳システム１０と同様の特徴を有する構成には、分散型台帳システム１０と同様の符号の後にアルファベット「Ａ」を付して、詳細な説明を省略する場合がある。なお、第１実施形態の図面等を参照しながら第２実施形態に係る分散型台帳システム１０Ａを説明する場合、図１～図１０に記載された符号に対してアルファベット「Ａ」を付して説明する。以下の分散型台帳システム１０Ａの説明において、主に分散型台帳システム１０と異なる点について説明する。

［２－１．システムの概要］
第２実施形態に係る分散型台帳システム１０Ａの概要は第１実施形態に係る分散型台帳システム１０とほぼ同様なので、説明を省略する。分散型台帳システム１０Ａでは、クライアントプロセス４１０Ａからリーダノード２００Ａに送信されるトランザクションがブロック単位でまとめて送信される点、複数のトランザクションが排他制御によって整列される点、及びログの最終断面がデータ同期アルゴリズムによってリーダノード２００Ａからフォロワノード３００Ａに送信される点において、第１実施形態に係る分散型台帳システム１０と相違する。

図３を参照して説明すると、分散型台帳システム１０Ａでは、クライアントプロセス４１０Ａは、ユーザ端末からの取引要求毎にトランザクションをリーダノード２００Ａに送信するのではなく、ユーザ端末からの複数の取引要求に対応する複数のトランザクションを蓄積してから、これら複数のトランザクションを１回の通信でまとめてリーダノード２００Ａに送信する。リーダノード２００Ａにまとめて送信される複数のトランザクションはブロック単位で扱われる。

トランザクションはクライアントプロセス４１０Ａ毎にまとめられる。つまり、クライアントプロセス４１１Ａ－１は、例えばトランザクションＴＸ１～ＴＸ１４９を１回の通信でまとめてリーダノード２００Ａに送信する。同様に、クライアントプロセス４１１Ａ－２は例えばトランザクションＴＸ１５０～ＴＸ５００を、クライアントプロセス４１２Ａ－１は例えばトランザクションＴＸ５０１～ＴＸ１０００を、それぞれ１回の通信でまとめてリーダノード２００Ａに送信する。また、トランザクションＴＸ１～ＴＸ１０００に基づいて生成されるログ１～ログ１０００もブロック単位で生成される。つまり、ログ１～ログ１４９、ログ１５０～ログ５００、及びログ５０１～ログ１０００の各々がブロック単位で生成される。

異なるブロック間には境界が定義される。具体的には、トランザクションＴＸ１～ＴＸ１４９には、各トランザクションが例えば第１ブロックに属していることを示すブロック識別子が付与される。同様に、トランザクションＴＸ１５０～ＴＸ５００には、各トランザクションが第２ブロックに属していることを示すブロック識別子が付与される。同様に、トランザクションＴＸ５０１～ＴＸ１０００には、各トランザクションが第３ブロックに属していることを示すブロック識別子が付与される。これらのブロック識別子はリーダノード２００Ａによって付される。ただし、ブロック識別子がクライアントプロセス４１０Ａによって付されてもよい。なお、上記のようにトランザクションにブロック識別子を付す以外に、個々のトランザクションＴＸと各トランザクションＴＸが属するブロックとを管理するテーブルが設けられていてもよい。

［２－２．リーダノード２００Ａの機能］
図１１を用いて、本実施形態に係る分散型台帳システム１０Ａのリーダノード２００Ａの機能を説明する。図１１は、本発明の一実施形態に係る分散型台帳システムに用いられるリーダノードの機能構成を示すブロック図である。図１１に示すリーダノード２００Ａの各機能部は、図４のリーダノード２００の各機能部に類似しているが、整列処理部２３０Ａ及び分散処理部２５０Ａの構成が図４の整列処理部２３０及び分散処理部２５０と相違する。また、ＴＸ受信部２２０Ａの機能が図４のＴＸ受信部２２０の機能と相違する。

まず、ＴＸ受信部２２０Ａは、ＣＭ通信部２１０Ａによって確立された１回の通信の間に、クライアント端末４００Ａから複数のトランザクションを受信する。当該通信の確立及び終了のプロトコルとして、例えばＴＣＰを利用することができる。なお、ＴＣＰのデータ部には、ブロック識別子、当該ブロック識別子に関連付けられたトランザクション数（ブロックに含まれるトランザクションの数）、及びトランザクションの内容（データ更新対象のキー及びデータ更新の値を含む）が含まれる。なお、ＴＸ受信部２２０Ａは、上記のように複数のトランザクションをブロック単位で受信する。ＴＸ受信部２２０Ａは、トランザクションと共に、ブロックを定義する情報を受信する。つまり、ＴＸ受信部２２０Ａは、異なるブロックの境界を定義する情報を受信する。

また、図１１に示すように、整列処理部２３０Ａは排他制御機能２３１Ａを有している。排他制御機能２３１Ａは、データ更新の衝突を防ぐため、直列に整列された各トランザクションに対して順にデータ更新を行う制御（排他制御）をログに追加する機能を有している。排他制御機能２３１Ａとして、例えばストリクトツーフェーズロック（Ｓ２ＰＬ）プロトコルを採用することができる。最終断面計算部２４５Ａは、このように排他制御の機能が追加されたログを用いてログの最終断面を計算する。

分散処理部２５０Ａはデータ同期アルゴリズム機能２５１Ａを有している。データ同期アルゴリズム機能２５１Ａは、リーダノード２００Ａから複数のフォロワノード３００Ａにログの最終断面を送付するアルゴリズムであり、後から複数のフォロワノード３００Ａ間で不整合が起きないように複数のフォロワノード３００Ａ間で同期を取るアルゴリズムである。データ同期アルゴリズム機能２５１Ａは、分散合意アルゴリズム（Ｒａｆｔ）であってもよく、その一部の機能であってもよい。

ログをブロック単位で生成する場合、整列処理部２３０Ａは、各ブロックの中だけでトランザクションの整列処理を行い、異なるブロック間でトランザクションの入れ替えは行わない。一方、ログをブロック単位で生成しない（つまり、ブロックの境界を解除した）場合、整列処理部２３０Ａは、ブロック間に跨がるトランザクションの整列処理を行う。つまり、この場合、整列処理部２３０Ａは、異なるブロックのトランザクションを入れ替えることができる。ログをブロック単位で生成する場合は、ブロックの境界を定義した情報をログにも引き継ぐ。一方、ログをブロック単位で生成しない場合、ブロックの境界を定義した情報は削除される又は無効化される。

分散処理部２５０Ａは、過半数のフォロワノード３００Ａにおいてログの最終断面の複製が正常に行われたことを確認した場合に、ログの最終断面の複製が完了したと見なす。一方、ログの最終断面の複製が正常に行われたことを示すフォロワノード３００Ａの数が半数以下の場合、その数が過半数に達するまで分散処理をリトライする、又は待機する。

［２－３．クライアント端末４００Ａの機能］
図１２を用いて、本実施形態に係る分散型台帳システム１０Ａのクライアント端末４００Ａの機能を説明する。図１２は、本発明の一実施形態に係る分散型台帳システムに用いられるクライアント端末の機能構成を示すブロック図である。図１２に示すクライアント端末４００Ａの各機能部は、図７のクライアント端末４００の各機能部に類似しているが、ＴＸバッファリング部４４０Ａが設けられている点において、クライアント端末４００の各機能部とは相違する。

ＴＸバッファリング部４４０Ａは、ＴＸ生成部４３０Ａによって生成されたトランザクションＴＸをバッファリングする。つまり、ＴＸバッファリング部４４０Ａは一時的な記憶装置を有しており、当該記憶装置にトランザクションＴＸを一時的に格納する。ＴＸバッファリング部４４０Ａには、バッファリングするトランザクションＴＸの数に対するしきい値が設定されている。ＴＸバッファリング部４４０Ａは、バッファリングするトランザクションＴＸの数がしきい値に達した場合に、トリガ信号を生成する。例えば、ＴＸバッファリング部４４０Ａは、バッファリングするトランザクションＴＸの数が１００個に達したらトリガ信号を生成する。又は、ＴＸバッファリング部４４０Ａは、上記しきい値の設定の代わりに、所定の期間を計測する機能が備えられていてもよい。この場合、ＴＸバッファリング部４４０Ａは、所定の期間が経過する度にトリガ信号を生成する。例えば、ＴＸバッファリング部４４０Ａは、０．１秒毎にトリガ信号を生成する。ただし、上記の数値はあくまで一例であり、上記の値に限定されない。

なお、ＬＮ通信部４５０Ａは、ＴＸバッファリング部４４０Ａによって生成されたトリガ信号に基づいて通信確立要求をＣＭ通信部２１０Ａに送信する。

ＴＸ送信部４６０Ａは、ＬＮ通信部４５０Ａによって確立された１回の通信の間に、リーダノード２００ＡのＴＸ受信部２２０Ａに対して、前のサイクルでトランザクションをリーダノード２００Ａに送信してから現在のサイクルでトリガ信号が生成されるまでの間に生成された複数のトランザクションを１ブロックにまとめて送信する。ＴＸ送信部４６０Ａがトリガ信号に応じて複数のトランザクションを送信すると、ＴＸバッファリング部４４０Ａに一時的に格納されていたトランザクションＴＸは削除され、次のサイクルのトランザクションＴＸのバッファリングを開始する。

［２－４．排他制御機能］
排他制御の具体的なシーケンスを図１３に示す。図１３は、本発明の一実施形態に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。図１３に示すように、リーダノード２００Ａが複数のトランザクションを含むブロックを受信する（ステップＳ８１０Ａ）と、整列処理部２３０Ａによって、トランザクションＴＸ１、ＴＸ２の順で整列される。排他制御機能２３１Ａは、トランザクションＴＸ１の処理（ステップＳ８１２Ａ）が行われる前に各ノードのデータ更新に対してロックをかける処理を追加する（ステップＳ８１１Ａ）。Ｓ８１１Ａ及びＳ８１２Ａの後に、各ノードにおいて更新されたデータを永続化する（ステップＳ８１３Ａ）。具体的には、Ｓ８１３Ａでは、Ｓ８１２Ａによって規定された内容で各ノードのデータ更新（データベースの書き換え）を行う。Ｓ８１３Ａの後にＳ８１１Ａでかけたロックを解除する（ステップＳ８１４Ａ）。ロックの解除後は、トランザクションＴＸ２に対する処理（ステップＳ８１５Ａ～Ｓ８１８Ａ）が行われる。なお、トランザクションＴＸ２の処理内容はトランザクションＴＸ１の処理内容と同じなので、詳細な説明は省略する。なお、この場合、トランザクションＴＸ１とＴＸ２とは順序が逆になってもよい。

上記の構成を換言すると、上記の排他制御は、複数のトランザクションのうちの１つの対象トランザクション（例えば、ＴＸ１）に対して、当該対象トランザクションの処理の前に各ノード（台帳）に対する更新処理をロックし、各ノード（台帳）に対して、当該対象トランザクションに応じた更新処理を行い、当該更新処理の後にロックを解除する制御である。

図１４は、本発明の一実施形態の変形例に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。図１４に示す例は、複数のブロックを受信した場合に、ブロック単位で排他制御を行う場合の一例である。図１４では、２つのブロックを受信した場合について例示するが、受信するブロックの数は３つ以上であってもよい。図１４では、ブロックＢＬ１がトランザクションＴＸ１～ＴＸ１４９を含み、ブロックＢＬ２がトランザクションＴＸ１５０～ＴＸ５００を含む。図１４では、ブロックＢＬ１は整列処理部２３０Ａによって、トランザクションＴＸ１～ＴＸ１４９の順で整列される。同様に、ブロックＢＬ２はトランザクションＴＸ１５０～ＴＸ５００の順で整列される。図示しないが、もちろんこれらの処理の後にトランザクションＴＸ５０１～１０００が順に整列されてもよい。

排他制御機能２３１Ａは、ブロックＢＬ１、ＢＬ２を受信する（ステップＳ８２０Ａ－１～Ｓ８２０Ａ－２）と、トランザクションＴＸ１～ＴＸ１４９の処理（ステップＳ８２２Ａ～Ｓ８２３Ａ）が行われる前に各ノードのデータ更新に対してロックをかける処理を追加する（ステップＳ８２１Ａ）。Ｓ８２２Ａ～Ｓ８２３Ａの後に、各ノードにおいて更新されたデータを永続化する（ステップＳ８２４Ａ）。具体的には、Ｓ８２４Ａでは、Ｓ８２２Ａ～Ｓ８２３Ａによって規定された内容で各ノードのデータ更新を行う。Ｓ８２２Ａ～Ｓ８２３Ａの後にＳ８２１Ａでかけたロックを解除する（ステップＳ８２５Ａ）。ロックの解除後は、ブロックＢＬ２のトランザクションＴＸ１５０～ＴＸ５００に対する処理（ステップＳ８２６Ａ～Ｓ８３０Ａ）が行われる。なお、トランザクションＴＸ１５０～ＴＸ５００の処理内容はトランザクションＴＸ１～ＴＸ１４９の処理内容と同じなので、詳細な説明は省略する。なお、この場合、ブロックＢＬ１内のトランザクションＴＸ１～ＴＸ１４９の処理順、ブロックＢＬ２内のトランザクションＴＸ１５０～ＴＸ５００の処理順の入れ替えはできないが、ブロックＢＬ１とＢＬ２とは順序が逆になってもよい。

図１５は、本発明の一実施形態の変形例に係る分散型台帳システムにおける排他制御の動作を示すシーケンスを示す図である。図１５に示す例は、複数のブロックを受信した場合に、ブロック間の境界を解消したうえで各ブロックに含まれる複数のトランザクションに対して排他制御を行う場合の一例である。図１５では、２つのブロック（ＢＬ１、ＢＬ２）を受信した場合について例示するが、受信するブロックの数は３つ以上であってもよい。図１５では、ブロックＢＬ１がトランザクションＴＸ１～ＴＸ１４９を含み、ブロックＢＬ２がトランザクションＴＸ１５０～ＴＸ５００を含む。図１５の例では、ＴＸ受信部２２０ＡがブロックＢＬ１、ＢＬ２を受信するとそれぞれのブロックの境界を解消し、これらのブロックに含まれていた各トランザクションは独立に扱われる。そして、図１５に示すように、各ブロック間に跨がるように、整列処理部２３０ＡによってＴＸ１、ＴＸ５００、ＴＸ１４９、ＴＸ１５０の順で整列される。

具体的には、図１５に示すように、排他制御機能２３１Ａは、ブロックＢＬ１、ＢＬ２を受信する（ステップＳ８４０Ａ－１～Ｓ８４０Ａ－２）と、各ブロック間に跨がるように、トランザクションＴＸ１（ステップＳ８４１Ａ～Ｓ８４４Ａ）、ＴＸ５００（ステップＳ８４５Ａ～Ｓ８４８Ａ）、ＴＸ１４９（ステップＳ８４９Ａ～Ｓ８５２Ａ）、ＴＸ１５０（ステップＳ８５３Ａ～Ｓ８５６Ａ）の順で図１３と同様の処理を行う。

図１４及び図１５の場合において、リーダノード２００Ａは、ブロックＢＬ１及びブロックＢＬ２に含まれるトランザクションＴＸ１～ＴＸ５００に基づいて複数のログ１～ログ５００を生成し、フォロワノード３００Ａに対して、生成された複数のログ１～ログ５００を合計した結果（最終断面）を送信する。

［２－５．データ同期アルゴリズム機能］
データ同期アルゴリズムの具体的なシーケンスを図１６に示す。図１６は、本発明の一実施形態に係る分散型台帳システムにおけるデータ同期アルゴリズムの動作を示すフローチャートを示す図である。図１６のフローチャートは、図１０のフローチャートと類似しているが、図１６のフローチャートは、トランザクションＴＸの数がしきい値に到達した場合に通信確立が行われる点、フォロワノード３００Ａの合意形成を確認する際、全てのフォロワノード３００Ａのうち過半数の合意が確認された場合にログの最終断面の複製が完了したと見なす点、及びフォロワノード３００Ａのデータの整合性確認を行う点において、図１０のフローチャートと相違する。以下の説明において、図１０と同様の構成については説明を省略し、主に図１０の構成と異なる点について説明する。

まず、クライアント端末４００ＡにおいてトランザクションＴＸが発生すると（Ｓ７０１Ａ）、トランザクションＴＸが発生する度にトランザクションＴＸを送信する条件を満たしているか否かの確認が行われる（ステップＳ８０５Ａ）。Ｓ７０１Ａにおいて、トランザクションＴＸを送信する条件が満たされていると判定された場合（Ｓ７０１Ａの「Ｙｅｓ」）、クライアント端末４００Ａからリーダノード２００Ａへ通信確立要求が送信される（ステップＳ８０１Ａ）。一方、Ｓ７０１Ａにおいて、トランザクションＴＸを送信する条件が満たされていないと判定された場合（Ｓ７０１Ａの「Ｎｏ」）、Ｓ７０１Ａまで戻り、次のトランザクションＴＸの発生を待つ。

また、Ｓ８０３Ａにおいて、全てのフォロワノード３００Ａの過半数（例えば２／３以上）から合意形成の確認が取れない場合（ステップＳ８０３Ａの「Ｎｏ」）、Ｓ７１６Ａ→Ｓ８０３Ａのステップを繰り返す。一方、全てのフォロワノード３００Ａの過半数（例えば２／３以上）から合意形成が確認されると（ステップＳ８０３Ａの「Ｙｅｓ」）、リーダノード２００Ａにおいてデータ更新（ステップＳ７１７Ａ）及び完了通知（ステップＳ７１８Ａ）が行われる。

また、Ｓ８０４Ａのデータ更新の後に、フォロワノード３００Ａ間におけるデータの整合性確認が行われる（ステップＳ８０６Ａ）。Ｓ８０６Ａにおいて、フォロワノード３００Ａの一部にデータの不整合が確認された場合（ステップＳ８０６Ａの「Ｎｏ」）、フォロワノード３００Ａデータの修正が行われる（ステップＳ８０７Ａ）。

ここで、Ｓ８０３Ａで過半数の合意形成が確認されているので、Ｓ８０７Ａにおいて、フォロワノード３００Ａのうち過半数のフォロワノード３００Ａで同一のデータを有している。つまり、同一のデータを有する過半数のフォロワノード３００Ａのデータが正しいデータである蓋然性が高いので、その他のフォロワノード３００Ａのデータを修正する。具体的には、リーダノード２００Ａに格納されていたログの最終断面をその他のフォロワノード３００Ａに再送信し、フォロワノード３００Ａにおいてそのログの最終断面に基づくデータ更新を行う。なお、Ｓ８０７Ａのデータ修正が行われた後に、再度Ｓ８０６Ａの整合性確認が行われる。

本実施形態に係る分散型台帳システム１０Ａによると、リーダノード２００Ａが受信した複数のトランザクションに対して排他制御を行うログを形成し、さらにそのログを用いて生成したログの最終断面を、データ同期アルゴリズムを用いて複数のフォロワノード３００Ａに送信することで、各ノードにおける整合性を確保したまま各ノード間の同期を取ることができる。特に、クライアント端末４００Ａからリーダノード２００Ａに、複数のトランザクションがブロック単位で送信される場合、複数のトランザクションが同一の更新対象に対する更新処理の要求を含む場合が想定されるが、そのような場合であっても、データ更新の衝突を発生させることなく、複数のノード間の不整合を抑制することができる。

以上、本発明の一実施形態について図面を参照しながら説明したが、本発明は上記の実施形態に限られるものではなく、本発明の趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、本実施形態の分散型台帳システムを基にして、当業者が適宜構成要素の追加、削除もしくは設計変更を行ったものも、本発明の要旨を備えている限り、本発明の範囲に含まれる。さらに、上述した各実施形態は、相互に矛盾がない限り適宜組み合わせが可能であり、各実施形態に共通する技術事項については、明示の記載がなくても各実施形態に含まれる。

上述した各実施形態の態様によりもたらされる作用効果とは異なる他の作用効果であっても、本明細書の記載から明らかなもの、又は、当業者において容易に予測し得るものについては、当然に本発明によりもたらされるものと解される。

１０：分散型台帳システム、 ３１～３８：台帳、 ４１～４７：クライアント端末、 １００～１０３：ノード、 １１０～１１３：サーバ、 １２０～１２３：データベース、 ２００：リーダノード、 ２２０：受信部、 ２３０：整列処理部、 ２３１Ａ：排他制御機能、 ２４０：ログ生成部、 ２５０：分散処理部、 ２５１Ａ：データ同期アルゴリズム機能、 ２６０：データ更新部、 ２９０：通信バス、 ３００～３０４：フォロワノード、 ３１０：断面受信部、 ３２０：断面格納部、 ３３０：合意形成部、 ３４０：データ更新部、 ３９０：通信バス、 ４００～４０４：クライアント端末、 ４１０～４１４：クライアントプロセス、 ４２０：取引要求受信部、 ４３０：生成部、 ４４０：バッファリング部、 ４５０：通信部、 ４６０：送信部、 ４９０：通信バス、 ５００：ネットワーク、 ６００：専用ネットワーク

Claims (8)

1. 台帳を分散して記録する複数のノードのうち１つの第１ノードを選出し、前記第１ノードから、前記複数のノードのうち前記第１ノードとは異なる複数の第２ノードに、クライアント端末から受信した複数のトランザクションに基づき所定の閾値で生成された複数のログの合計を送信するシステム。
2. 台帳を分散して記録する複数のノードのうち１つの第１ノードは前記複数のノードのうち前記第１ノードとは異なる複数の第２ノードに対して、クライアント端末から受信した複数のトランザクションに基づき所定の閾値で生成された複数のログを送信せずに前記複数のログの合計を送信するシステム。
3. 前記第１ノードは、
   前記クライアント端末から前記複数のトランザクションを含むブロック単位で前記複数のトランザクションを受信し、
   前記ブロックに含まれる前記複数のトランザクションに基づいて前記複数のログを生成し、
   前記複数の第２ノードに対して複数の前記ブロックに含まれる前記複数のログを合計した結果を送信する、
   請求項１又は２に記載のシステム。
4. 前記第１ノードは前記複数のログを記憶する、請求項１乃至３のいずれか一に記載のシステム。
5. 台帳を分散して記録する複数のノードから選出された１つの第１ノードに対して、前記複数のノードのうち前記第１ノードとは異なる複数の第２ノードに、クライアント端末から受信した複数のトランザクションに基づき所定の閾値で生成された複数のログの合計を送信することを実行させるためのプログラム。
6. 台帳を分散して記録する複数のノードのうち１つの第１ノードに対して、前記複数のノードのうち前記第１ノードとは異なる複数の第２ノードへクライアント端末から受信した複数のトランザクションに基づき所定の閾値で生成された複数のログを送信せずに前記複数のログの合計を送信することを実行させるためのプログラム。
7. 前記第１ノードに、
   前記クライアント端末から前記複数のトランザクションを含むブロック単位で前記複数のトランザクションを受信させ、
   前記ブロックに含まれる前記複数のトランザクションに基づいて前記複数のログを生成させ、
   前記複数の第２ノードに対して複数の前記ブロックに含まれる前記複数のログを合計した結果を送信させる、
   請求項５又は６に記載のプログラム。
8. 前記第１ノードに前記複数のログを記憶させる、請求項５乃至７のいずれか一に記載のプログラム。

Images