JP2021012658A - システムおよび処理方法 - Google Patents

Abstract

【課題】分散型台帳技術を用いた場合でも、多くのトランザクションを効率よく処理すること【解決手段】本発明の一実施形態に係るシステムは、台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスを生成する生成部と、トランザクションの指示を受け付け、前記複数のプロセスのいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と、を備える。このシステムは、処理方法としても実現可能である。【選択図】図１

Description

本発明は、トランザクションをブロックチェーンネットワークにリクエストするための技術に関する。

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

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

分散型台帳技術では、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）によって接続された複数のノードによってネットワークが形成され、そのネットワークにおける複数のノードによって台帳が分散して記録される。分散型台帳技術においては、ほとんどの場合、ブロックチェーンが台帳に記録され、台帳に直接記録されない場合でも何らかの形態で用いられる。以下の説明では、台帳を分散して記録する複数のノードによって形成されるネットワークであって、ブロックチェーンを扱うネットワークを、ブロックチェーンネットワークという。なお、本明細書でいうブロックチェーンネットワークは、必ずしもビザンチン耐性を備えた構成であることを必須としないが、ビザンチン耐性を備えた構成であってもよい。

ブロックチェーンネットワークを構成する各ノードによれば、互いが保持するデータの正当性を高めるために、所定のアルゴリズムによって合意形成が行われる。これによって、データの改ざんが難しくなり、取引の信頼性が保たれる。一方、一般的には合意形成の処理には多くの時間を要すると考えられているため、大量のトランザクションが発生するような処理に適用することは難しいと考えられている。

本発明の目的の一つは、分散型台帳技術を用いた場合でも、多くのトランザクションを効率よく処理することにある。

本発明の一実施形態によれば、台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスを生成する生成部と、トランザクションの指示を受け付け、前記複数のプロセスのいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と、を備えるシステムが提供される。

前記複数のプロセスは、第１プロセスおよび第２プロセスを含み、前記第１プロセスが前記リクエストを送信するノードは、前記第２プロセスが前記リクエストを送信するノードと同一であってもよい。

前記割当部は、ラウンドロビン方式により前記トランザクションのリクエスト送信を割り当ててもよい。

前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットとプロセス多重度との関係において、プロセス多重度の増加に対する平均スループットの増加の割合が、プロセス多重度が第１値のときに第１割合であり、当該第１値より大きい第２値以上であるときに前記第１割合より小さい第２割合であり、前記複数のプロセスの数は、前記第２値よりも小さい数で設定されてもよい。

前記複数のノードで形成されるネットワークは、コンソーシアム型であってもよい。

本発明の一実施形態によれば、トランザクションの指示を受け付け、台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスのいずれかに、前記指示に基づくトランザクションのリクエスト送信を割り当てる、処理方法が提供される。

前記複数のプロセスは、第１プロセスおよび第２プロセスを含み、前記第１プロセスが前記リクエストを送信するノードは、前記第２プロセスが前記リクエストを送信するノードと同一であってもよい。

前記トランザクションのリクエスト送信を割り当てるときには、ラウンドロビン方式を用いてもよい。

前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットとプロセス多重度との関係において、プロセス多重度の増加に対する平均スループットの増加の割合が、プロセス多重度が第１値のときに第１割合であり、当該第１値より大きい第２値以上であるときに前記第１割合より小さい第２割合であり、前記複数のプロセスの数は、前記第２値よりも小さい数で設定されてもよい。

前記複数のノードで形成されるネットワークは、コンソーシアム型であってもよい。

本発明の一実施形態によれば、分散型台帳技術を用いた場合でも、多くのトランザクションを効率よく処理することができる。

本発明の一実施形態におけるリクエスト制御システムの構成を示すブロック図である。 本発明の一実施形態におけるリクエスト制御システムが実行する割当処理を示すフローチャートである。 本発明の一実施形態におけるプロセスが実行する送信処理を示すフローチャートである。 本発明の一実施形態におけるリクエスト制御システムが事前設定をする場合の構成を示すブロック図である。 本発明の一実施形態におけるリクエスト制御システムが実行する設定処理を示すフローチャートである。 本発明の一実施形態におけるプロセス多重度と平均スループットとの関係を説明する図である。

以下、本発明の一実施形態について、図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこの実施形態に限定して解釈されるものではない。すなわち、以下に説明する複数の実施形態に公知の技術を適用して変形をして、様々な態様で実施をすることが可能である。

＜実施形態＞
［１．システムの概要］
図１は、本発明の一実施形態におけるリクエスト制御システムの構成を示すブロック図である。リクエスト制御システム１は、ユーザ端末８０からネットワークＮＷを介して電文を受信し、その電文に対応したトランザクションのリクエストをブロックチェーンネットワーク５に送信する。このリクエストは、ブロックチェーンネットワーク５における分散型台帳にそのトランザクションを記録させるための指示である。

一般的には、ブロックチェーンネットワーク５において分散型台帳への記録は、多くの時間を要する。したがって処理のボトルネックはブロックチェーンネットワーク５における演算処理能力に存在すると考えられていた。ビザンチン耐性を備える構成である場合には、より多くの時間を要するため、このような傾向が顕著に現れる。一方、ビザンチン耐性を備えていない構成であっても、ビザンチン耐性を備える構成よりも処理時間を要しないものの、分散型台帳への記録という観点では、同様な傾向を有している。

発明者は、様々な検証により、ブロックチェーンネットワーク５における演算処理能力にボトルネックが存在する状況は、極めて多くの処理が集中した場合であって、実際には、その前の段階、すなわちトランザクションのリクエストを送信する側においてボトルネックが存在する場合が多いことの知見を得た。この知見に基づき、本発明の一実施形態におけるリクエスト制御システム１では、ブロックチェーンネットワーク５における演算処理能力にボトルネックが存在する段階までリクエストを送信するためのプロセスを多重化することで、処理量を向上させることができることがわかった。このようにして処理量を向上させるための構成および処理方法について、順に説明する。

［２．ユーザ端末］
ユーザ端末８０は、一般ユーザが利用するスマートフォン、パーソナルコンピュータなどの端末である。この例では、ユーザ端末８０において金融機関が提供するアプリケーションプログラムが起動されると、ユーザの指示によって自身の口座から他の口座への振込処理等の手続が可能になっている。ユーザによって手続の指示がされると、ユーザ端末８０は、その手続に応じたトランザクションの指示内容を含む電文を送信する。

［３．ブロックチェーンネットワーク］
ブロックチェーンネットワーク５は、Ｐ２Ｐ接続ＰＰによって複数のノードが接続されている。図１においては、４つのノード５１０−１、５１０−２、５１０−３、５１０−４によってブロックチェーンネットワーク５が構成されているが、ノードの数は４つより少なくても多くてもよい。以下の説明において、それぞれのノードを区別せずに説明する場合には、単にノード５１０という。

ノード５１０−１は、コンピュータ５１−１と台帳５３−１とを含む。台帳５３−１は、各ノード５１０に分散される台帳のデータが記録される記録媒体である。コンピュータ５１−１では、分散型台帳技術を実現するためのプログラムがＣＰＵによって実行される。コンピュータ５１−１は、台帳５３−１へのデータの記録処理および読み出し処理を実行し、また、他のノード５１０−２、５１０−３、５１０−４において台帳のデータを分散して記録するための処理を実行する。この処理には、分散したデータの正当性を高めるための合意形成処理も含まれる。ここでは、ノード５１０−１を例として、その構成を説明したが、他のノード５１０−２、５１０−３、５１０−４においても、それぞれの構成は同様である。すなわち、いずれかのノード５１０に対してトランザクションのリクエストがされると、そのトランザクションの内容が各ノード５１０における台帳にも記録される。

ブロックチェーンネットワーク５においては、上述のように台帳を分散して各ノード５１０で記録する方式が用いられているが、その過程における具体的な処理は、仕様（基盤ソフトウェア：上述したＣＰＵによって実行されるプログラムに対応）によって様々であって、公知の処理が適用されればよい。したがって、ブロックチェーンネットワーク５における各ノード５１０の処理の詳細は説明を省略する。この例では、ブロックチェーンネットワークは、管理主体が存在するコンソーシアム型（例えば、Ｑｕｏｒｕｍ、Ｈｙｐｅｒｌｅｄｇｅｒ Ｆａｂｒｉｃ等）を想定しているが、管理主体が存在しないパブリック型（例えば、Ｅｔｈｅｒｅｕｍ等）であっても適用可能である。

［４．リクエスト制御システム］
リクエスト制御システム１は、プロセス生成装置１１（生成部）、負荷分散装置１５（割当部）および通信装置１８を含む。これらの装置は、いずれもＣＰＵによってプログラムを実行することによって、以下に説明する機能をそれぞれ実現している。これらの装置のうち、一部または全部は一体の装置として実現されてもよい。

［４−１．プロセス生成装置］
プロセス生成装置１１は、複数（この例では、予め設定されたｎ個）のプロセス１１０−１、１１０−２、・・・、１１０−ｎを生成する。以下の説明において、それぞれのプロセスを区別せずに説明する場合には、単にプロセス１１０という。各プロセス１１０は、負荷分散装置１５からトランザクションのリクエスト送信を割り当てられると、そのトランザクションについてのリクエストをノード５１０−１に対して送信する。この例では、いずれのプロセス１１０においても、リクエストの送信先は同一のノード（この例ではノード５１０−１）として決められている。なお、上述したように、ブロックチェーンネットワーク５において使用される仕様によって、リクエストの送信先として、複数のノード５１０が指定されてもよいし、プロセス１１０によって異なるノード５１０が指定されてもよいし、リクエスト毎に異なるノード５１０が指定されてもよい。

プロセス１１０は、リクエストの送信の結果、ブロックチェーンネットワーク５においてトランザクションが分散型台帳に記録されたことを検出すると、キューに入っている次に処理すべきトランザクションのリクエストを送信する。キューは、各プロセス１１０に割り当てられている。プロセス１１０は、分散型台帳に記録されたことを、ブロックチェーンネットワーク５からの通知により検出してもよいし、ブロックチェーンネットワーク５にアクセスすることによって検出してもよい。

［４−２．通信装置］
通信装置１８は、ネットワークＮＷを介してユーザ端末８０から電文を受信し、この電文に含まれるトランザクションの指示内容を負荷分散装置１５へ送信する。

［４−３．負荷分散装置］
負荷分散装置１５は、通信装置１８からトランザクションの指示内容を受信すると、複数のプロセス１１０のいずれかに、そのトランザクションのリクエスト送信を割り当てる。負荷分散装置１５は、割り当てたプロセス１１０のキューに、トランザクションの指示内容を登録する。上述したように、キューに登録されたトランザクションは、そのキューに対応したプロセス１１０からブロックチェーンネットワーク５に対して、リクエストとして送信される。この例では、ｎ個のプロセス１１０が生成されているため、プロセス多重度はｎ個となる。ｎ個の具体的な値は、事前の設定処理によって予め設定される。設定処理については、後述する。

［４−４．システムの動作］
続いて、リクエスト制御システム１の動作について説明する。リクエスト制御システム１の動作としては、主として、複数のプロセス１１０のいずれかにトランザクションを割り当てるための割当処理、および割り当てられたトランザクションのリクエストを送信するための送信処理を含む。

［４−４−１．割当処理］
図２は、本発明の一実施形態におけるリクエスト制御システムが実行する割当処理を示すフローチャートである。システムの管理者等によりリクエスト制御システム１における処理を開始する指示が入力されると、以下に説明する割当処理が実行される。プロセス生成装置１１は、予め設定された数のプロセス１１０を起動（生成）する（ステップＳ１０１）。通信装置１８による電文の受信を待機する（ステップＳ１０３；Ｎｏ）。通信装置１８により電文が受信される（ステップＳ１０３；Ｙｅｓ）と、負荷分散装置１５は、電文に含まれるトランザクションの指示内容を受け付ける（ステップＳ１０５）。負荷分散装置１５は、複数のプロセス１１０から割り当ての対象となるプロセス１１０を特定し（ステップＳ１０７）、そのプロセス１１０にトランザクションのリクエストをする指示をする（ステップＳ１０９）。この指示は、例えば、トランザクションの内容等を含む指示信号によって実現される。ここで、負荷分散装置１５は、例えば、ラウンドロビン方式により、複数のプロセス１１０から割り当ての対象となるプロセス１１０を特定する。なお、この方式はラウンドロビン方式に限らず、別のアルゴリズムを用いた方式であってもよい。

システムの管理者等によりリクエスト制御システム１の処理を終了する指示がなければ（ステップＳ１１１；Ｎｏ）、再びステップＳ１０３に戻って処理を続ける。一方、この処理を終了する指示があれば（ステップＳ１１１；Ｙｅｓ）、プロセス生成装置１１がプロセス１１０を終了させ（ステップＳ１１３）、割当処理が終了される。

［４−４−２．送信処理］
図３は、本発明の一実施形態におけるプロセスが実行する送信処理を示すフローチャートである。プロセス生成装置１１によりプロセス１１０が起動されると、それぞれのプロセス１１０において、図３に示す送信処理が実行される。まず、プロセス１１０は、プロセス生成装置１１によるプロセス終了の指示、または負荷分散装置１５からトランザクションのリクエストを送信する指示を待機する（ステップＳ２０１；Ｎｏ，ステップＳ２０３；Ｎｏ）。プロセス終了の指示があった場合（ステップＳ２０１；Ｙｅｓ）には、送信処理が終了される。

一方、リクエストを送信する指示を受信した場合（ステップＳ２０３；Ｙｅｓ）、プロセス１１０は、送信するリクエストに電子署名の付加等の認証処理を行い（ステップＳ２１１）、認証処理が施されたリクエストをブロックチェーンネットワーク５に送信する（ステップＳ２１３）。その後、プロセス１１０は、リクエストの送信の結果、ブロックチェーンネットワーク５においてトランザクションが分散型台帳に記録されたことを検出することによって、処理の完了を確認するまで待機し（ステップＳ２１５；Ｎｏ）、処理の完了を確認すると（ステップＳ２１５；Ｙｅｓ）、ステップＳ２０１に戻って処理を続ける。

以上のように、リクエスト制御システム１が動作することによって、プロセス１１０の数に対応したリクエスト処理の多重化が実現される。後述のようにプロセス１１０の数が設定されているため、ブロックチェーンネットワーク５における演算処理能力がボトルネックになる前にリクエストの送信が制限され、効率的な分散型台帳の運用が可能となる。仮に、不安定要因により、ブロックチェーンネットワーク５における演算処理能力がボトルネックになる状態に移行したとしても、大きな影響を生じないようにすることもできる。

［５．設定処理］
続いて、プロセス生成装置１１において生成されるプロセス１１０の数（プロセス多重度）を設定する処理について説明する。

図４は、本発明の一実施形態におけるリクエスト制御システムが事前設定をする場合の構成を示すブロック図である。設定処理を行う場合におけるリクエスト制御システム１Ａとしては、リクエスト制御システム１に対して、プロセス生成装置１１Ａ、指示生成装置３８および設定装置３９を含み、通信装置１８を含まない構成が例示される。ここでは、プロセス生成装置１１Ａ、指示生成装置３８および設定装置３９について説明し、他の構成については、その説明を省略する。

プロセス生成装置１１Ａは、設定装置３９から指定された数のプロセス１１０を起動するとともに、各プロセス１１０においてトランザクションのリクエストを送信してから、ブロックチェーンネットワーク５においてトランザクションが分散型台帳に記録されたことを検出するまでの時間（以下、スループットという）を測定する。この測定したスループットを設定装置３９に送信する。

指示生成装置３８は、設定装置３９からの制御に基づいて、所定のトランザクションの指示を生成して、指示の内容を負荷分散装置１５に送信する。この指示の内容は、通信装置１８を介して受信する電文に基づくトランザクションの指示内容の代わりとなるものである。

設定装置３９は、プロセス生成装置１１Ａおよび指示生成装置３８を制御して、プロセス多重度（プロセス１１０の数：ｍ個）を変更しつつ、１プロセス当たりの平均スループットを測定する。これによって、設定装置３９は、プロセス多重度と平均スループットとの関係を取得する。設定装置３９は、この関係を用いて、利用するブロックチェーンネットワーク５における最適なプロセス１１０の数を算出する。この数は、上述したｎ個に相当するものとして、リクエスト制御システム１におけるプロセス生成装置１１に設定される。

図５は、本発明の一実施形態におけるリクエスト制御システムが実行する設定処理を示すフローチャートである。最初にブロックチェーンネットワーク５に接続する場合、ブロックチェーンネットワーク５における設定の変更（ソフトウェアのバージョンアップ等）があった場合等において、管理者等の指示により設定処理が実行される。まず、リクエスト制御システム１Ａは、設定装置３９の制御により、プロセス多重度を変化させながら（例えば徐々に増加させながら）、平均スループットを測定する（ステップＳ５０１）。

図６は、本発明の一実施形態におけるプロセス多重度と平均スループットとの関係を説明する図である。プロセス多重度および平均スループットの絶対値については様々であるものの、多くのブロックチェーンネットワーク５において、このような結果が得られることは、発明者による検証から得られた知見である。すなわち、プロセス多重度が低い場合、プロセス多重度の増加に伴い平均スループットは増加していく。一方、プロセス多重度が大きくなると、プロセス多重度が増加しても、平均スループットは増加しなくなっていく。すなわち、プロセス多重度が大きい値Ｎ２である場合の平均スループットの増加の割合は、プロセス多重度が小さい値Ｎ１（第１値）である場合の平均スループットの増加の割合（第１割合）よりも小さい。特定のプロセス多重度における平均スループットの増加の割合は、図６に示すグラフにおいて、そのプロセス多重度における傾き（微分値）に相当する。この増加の割合を、以下、増加率という。プロセス多重度の増加に対して、増加率が大きく減少し始めるとき（第２割合）のプロセス多重度が、図６に示す閾値Ｔｈｎ（第２値）に対応する。

このように、閾値Ｔｈｎよりもプロセス多重度が小さい領域Ａ１においては、ブロックチェーンネットワーク５における演算処理能力にボトルネックがあるのではなく、リクエストを送信する側の処理にボトルネックがある。一方、閾値Ｔｈｎよりもプロセス多重度が大きい量器Ａ２においては、プロセス多重度を増加させても、平均スループットがほとんど増加しないことから、ブロックチェーンネットワーク５における演算処理能力にボトルネックがあることがわかる。

図５に戻って説明をつづける。リクエスト制御システム１Ａ（設定装置３９）は、プロセス多重度に対する平均スループットを測定した後に、各プロセス多重度における平均スループットの増加率を算出する（ステップＳ５０３）。この増加率は、図６に示すグラフにおいて、各プロセス多重度における傾きに相当する。そして、さらに、増加率の変化に基づく所定の演算式によって、閾値Ｔｈｎが特定される（ステップＳ５０５）。設定装置３９は、この閾値Ｔｈｎよりも小さいプロセス多重度をプロセス１１０の数としてプロセス生成装置１１に設定する。このようにプロセス１１０の数を設定することにより、ブロックチェーンネットワーク５における演算処理能力にボトルネックを発生させずに、リクエストの送信側においてボトルネックを発生させることできる。したがって、プロセス生成装置１１において不要なプロセス１１０を生成しないようにして、リクエスト制御システム１のリソースを効率的に用いることができる。

１，１Ａ…リクエスト制御システム、５…ブロックチェーンネットワーク、１１，１１Ａ…プロセス生成装置、１５…負荷分散装置、１８…通信装置、３８…指示生成装置、３９…設定装置、５１…コンピュータ、５３…台帳、８０…ユーザ端末、１１０…プロセス、５１０…ノード

プロセス生成装置１１Ａは、設定装置３９から指定された数のプロセス１１０を起動するとともに、各プロセス１１０においてトランザクションのリクエストを送信してから、ブロックチェーンネットワーク５においてトランザクションが分散型台帳に記録されたことを検出するまでの時間を測定する。この測定した時間に基づいて得られる単位時間当たりの処理量（以下、スループットという）を設定装置３９に送信する。

Claims (10)

1. 台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスを生成する生成部と、
   トランザクションの指示を受け付け、前記複数のプロセスのいずれかに当該トランザクションのリクエスト送信を割り当てる割当部と、を備えるシステム。
2. 前記複数のプロセスは、第１プロセスおよび第２プロセスを含み、
   前記第１プロセスが前記リクエストを送信するノードは、前記第２プロセスが前記リクエストを送信するノードと同一である、請求項１に記載のシステム。
3. 前記割当部は、ラウンドロビン方式により前記トランザクションのリクエスト送信を割り当てる、請求項１または請求項２に記載のシステム。
4. 前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットとプロセス多重度との関係において、プロセス多重度の増加に対する平均スループットの増加の割合が、プロセス多重度が第１値のときに第１割合であり、当該第１値より大きい第２値以上であるときに前記第１割合より小さい第２割合であり、
   前記複数のプロセスの数は、前記第２値よりも小さい数で設定される、請求項１から請求項３のいずれかに記載のシステム。
5. 前記複数のノードで形成されるネットワークは、コンソーシアム型である、請求項１から請求項４のいずれかに記載のシステム。
6. トランザクションの指示を受け付け、
   台帳を分散して記録する複数のノードの少なくとも１つに対し、トランザクションのリクエストを送信する複数のプロセスのいずれかに、前記指示に基づくトランザクションのリクエスト送信を割り当てる、処理方法。
7. 前記複数のプロセスは、第１プロセスおよび第２プロセスを含み、
   前記第１プロセスが前記リクエストを送信するノードは、前記第２プロセスが前記リクエストを送信するノードと同一である、請求項６に記載の処理方法。
8. 前記トランザクションのリクエスト送信を割り当てるときには、ラウンドロビン方式を用いる、請求項６または請求項７に記載の処理方法。
9. 前記複数のノードで形成されるネットワークにおける所定のトランザクションのリクエストに対する平均スループットとプロセス多重度との関係において、プロセス多重度の増加に対する平均スループットの増加の割合が、プロセス多重度が第１値のときに第１割合であり、当該第１値より大きい第２値以上であるときに前記第１割合より小さい第２割合であり、
   前記複数のプロセスの数は、前記第２値よりも小さい数で設定される、請求項６から請求項８のいずれかに記載の処理方法。
10. 前記複数のノードで形成されるネットワークは、コンソーシアム型である、請求項６から請求項９のいずれかに記載の処理方法。

Images