JP6694204B1 - 改ざん検知性を有するシステム - Google Patents

改ざん検知性を有するシステム Download PDF

Info

Publication number
JP6694204B1
JP6694204B1 JP2020507134A JP2020507134A JP6694204B1 JP 6694204 B1 JP6694204 B1 JP 6694204B1 JP 2020507134 A JP2020507134 A JP 2020507134A JP 2020507134 A JP2020507134 A JP 2020507134A JP 6694204 B1 JP6694204 B1 JP 6694204B1
Authority
JP
Japan
Prior art keywords
request
common
update request
target
status update
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020507134A
Other languages
English (en)
Other versions
JPWO2020153454A1 (ja
Inventor
山田　浩之
浩之 山田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Scalar Inc
Original Assignee
Scalar Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Scalar Inc filed Critical Scalar Inc
Priority claimed from PCT/JP2020/002421 external-priority patent/WO2020153454A1/ja
Application granted granted Critical
Publication of JP6694204B1 publication Critical patent/JP6694204B1/ja
Publication of JPWO2020153454A1 publication Critical patent/JPWO2020153454A1/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/86—Secure or tamper-resistant housings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0695—Management of faults, events, alarms or notifications the faulty arrangement being the maintenance, administration or management system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

各ノードシステムにおいて、要求実行部が、状態更新要求毎に、当該要求で指定されている対象の状態を表すオブジェクトを更新する状態更新処理を実行し、改ざん検知処理の実行無しに、要求の完了を応答する。改ざん検知実行部が、一つ又は複数の更新完了要求のうちの一つ以上の共通完了要求について、二つ以上のノードシステムの更新後オブジェクト又はそのサマリを比較することにより改ざんの有無を検知する改ざん検知処理を実行する。更新完了要求は、状態更新処理の実行が完了している状態更新要求である。共通完了要求は、複数のノードシステムのうちの二つ以上のノードシステムに共通の更新完了要求である。

Description

本発明は、概して、改ざん検知技術に関する。
改ざん検知性を有するシステムの一例として、分散型台帳技術が適用されたシステムが知られており、分散型台帳技術の一例として、ブロックチェーンが知られている（例えば非特許文献１）。
https://bitcoin.org/bitcoin.pdf
以下の説明では、「対象」とは、任意の有体物又は無体物である。例えば、「対象」として、口座を採用し、対象の状態として、残高を採用することができる。
また、以下の説明では、「状態更新要求」とは、状態更新処理の要求である。「状態更新処理」とは、対象の状態を更新する処理である。「改ざん検知処理」とは、オブジェクトの改ざんの有無を検知する処理である。「ノードシステム」とは、サーバシステムの構成要素であり、一つ以上の計算機を備えたシステムである。
多くのＢＦＴ（Byzantine Fault Tolerance）コンセンサスアルゴリズムやそれに類似したブロックチェーン等の仕組み（例えば、HyperLedger fabricのendorsement）が知られている。このような仕組みによれば、サーバシステムにおける複数のノードシステムの各々が、対象毎に、オブジェクト（対象の状態を表すデータ）を管理する。サーバシステムがクライアントシステムから状態更新要求を受信する都度に、各ノードシステムが、オブジェクトの改ざんの有無を検知する改ざん検知処理を実行する。各ノードシステムにおいて、「改ざん検知処理」は、現在（状態更新処理の実行前）のオブジェクトの改ざんの有無を検知することと、状態更新処理を途中まで実行することで得られた更新後のオブジェクトの改ざんの有無を検知することとの少なくとも一つを含む。複数のノードシステムにおいて同様の改ざん検知処理が実行される。全ノードシステムの改ざん検知処理の実行が完了しないと、いずれのノードシステムも、状態更新処理を実行することができない。また、いずれかのノードシステムが先に状態更新処理の実行を完了できたとしても、全ノードシステムにおいて当該状態更新処理の実行が完了しないと、当該状態更新要求に関連する次の状態更新要求について、いずれのノードシステムも状態更新処理を実行することができない。全ノードシステムに更新後オブジェクトがあるとは限らず、故に、当該次の状態更新要求について、全ノードシステムの改ざん検知処理の実行が完了しないためである。
このため、複数のノードシステムの処理速度が同じであることが望ましい。複数のノードシステムの処理速度が異なっていると、処理速度が相対的に低いノードシステムの処理結果を待つ必要が起こり、システム全体の利用効率が低下するからである。
従って、サーバシステムの構成の柔軟性が低い。例えば、ノードシステムを追加又は交換する場合、追加又は交換されるノードシステムは、サーバシステムに存在する他のノードシステムと同等の処理速度を持つノードシステムとすることが望まれる。
このような問題は、サーバシステムのスケールを困難にし、故に、スケーラビリティの確保が難しいという問題を引き起こす。
この種の問題は、ＢＦＴコンセンサスアルゴリズムやそれに類似したブロックチェーン等の仕組みが適用されたデータ管理システムに限らず、複数のノードシステム間の処理結果を比較することにより改ざん検知性を担保しているデータ管理システム全般についても起こり得る。
データ管理システムのアプリケーションの要件によっては、改ざん検知処理が、必ずしも状態更新要求の受信の都度に直ちに実行されなくてもよい、及び／又は、全ての状態更新要求について必ずしも改ざん検知処理の実行が必要とされないと考えられる。例えば、対象が口座であり対象の状態が残高であるアプリケーションにおいて、残高は、入金及び出金のいずれのときにも変わるが、当該アプリケーションの要件によっては、入金においては残高の改ざん検知処理の実行は不要であり出金について残高の改ざん検知処理が実行されればよいかもしれない。
そこで、本発明は、状態更新処理の実行と、二つ以上のノードシステムのオブジェクトについての改ざん検知処理の実行とを分離する。
具体的には、データ管理システムが、一つ又は複数の改ざん検知実行部と、複数の要求実行部とを備える。複数の要求実行部は、一つ又は複数の第１の計算機システムと通信する第２の計算機システムにおける複数のノードシステムに備えられる。
第１の計算機システムに備えられる要求発行部が、対象を指定した状態更新要求を発行する。各ノードシステムにおいて、要求実行部は、状態更新要求毎に、当該状態更新要求で指定されている対象の状態を表すデータであるオブジェクトを更新する状態更新処理を実行し、改ざん検知処理の実行無しに、当該状態更新要求の完了を応答する。改ざん検知実行部が、一つ又は複数の更新完了要求のうちの共通完了要求について、複数のノードシステムのうちの二つ以上のノードシステムの更新後オブジェクト又はそのサマリを比較することにより改ざんの有無を検知する改ざん検知処理を実行する。更新完了要求は、状態更新処理の実行が完了している状態更新要求である。共通完了要求は、複数のノードシステムのうちの二つ以上のノードシステムに共通の更新完了要求である。
なお、改ざん検知実行部は、要求発行部に含まれる機能でもよいし、要求発行部に含まれない機能でもよい。改ざん検知実行部は、第１の計算機システム、第２の計算機システム、及び、それらのシステム以外のシステムに備えられてよい。
状態更新処理の実行と改ざん検知処理の実行とが分離されているので、各ノードシステムでは、状態更新要求毎に、改ざん検知処理の実行無しに、状態更新処理の実行が完了する。このため、第２の計算機システムを処理速度が同じ複数のノードシステムで構成する必要が無い。故に、第２の計算機システムの構成の柔軟性を高めることができ、結果として、高効率にスケーラビリティを高めることができる。
また、状態更新処理の実行と改ざん検知処理の実行とが分離されているので、状態更新処理が各ノードシステムで独立して行われる。第１の計算機システム（例えば、クライアントシステム）は、少なくとも一つのノードシステムから状態更新処理の完了応答が返ってくれば、関連する次の状態更新要求を送信できる。当該次の状態更新要求についても、状態更新処理が各ノードシステムで独立して行われる。このため、第１の計算機システムにとって、状態更新処理の実行におけるレイテンシが低い。
また、状態更新処理の実行と改ざん検知処理の実行とが分離されているので、改ざん検知処理の実行のタイミングを柔軟に決定することができる、及び／又は改ざん検知処理の実行対象とする共通完了要求を柔軟に選択することができる。例えば、対象が口座であり対象の状態が残高であるアプリケーションにおいて、残高の改ざん検知処理を、入金において行わず出金のときに行うといった設定をすることが可能である。
実施例１に係るシステム全体の構成の一例を示す。 クライアントシステム、ノードシステム及び中間システムの構成の一例を示す。 サーバ管理データの一例を示す。 アセットセットの一例を示す。 状態更新要求の構成の概要を示す。 実施例１の概要を示す。 状態更新要求の作成から実行完了までの実施例１での流れを示すフローチャートである。 実施例２の概要を示す。 状態更新要求の作成から実行完了までの実施例２での流れを示すフローチャートである。 実施例３に係るシステム全体の構成の一例を示す。 実施例３の概要の一例を示す。 状態更新要求の作成から実行完了までの実施例３での流れを示すフローチャートである。 改ざん検知処理の実行のフローチャートである。 実施例４に係る改ざん検知処理の実行のフローチャートである。
以下の説明では、「インターフェース装置」は、一つ以上のインターフェースを含む。一つ以上のインターフェースは、一つ以上の同種の通信インターフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。
また、以下の説明では、「記憶装置」は、一つ以上のメモリを含む。記憶装置に関して少なくとも一つのメモリは、揮発性メモリでよい。記憶装置は、主に、プロセッサによる処理の際に使用される。記憶装置は、メモリの他に、一つ以上の不揮発性の記憶デバイス（例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive））を含んでもよい。
また、以下の説明では、「プロセッサ」は、一つ以上のプロセッサを含む。少なくとも一つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。一つ以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサによって実行されることで、定められた処理を、適宜に記憶装置（例えばメモリ）及び／又はインターフェース装置（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。また、以下の説明において、二つ以上のプログラムが一つのプログラムとして実現されてもよいし、一つのプログラムが二つ以上のプログラムとして実現されてもよい。
また、以下の説明では、「ｙｙｙ部」の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよいし、それらの組合せによって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置及び／又はインターフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。各機能の説明は一例であり、複数の機能が一つの機能にまとめられたり、一つの機能が複数の機能に分割されたりしてもよい。
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号を使用し、同種の要素を区別する場合は、参照符号を使用することがある。
また、以下の説明では、「オブジェクト」とは、アプリケーションプログラムのようなプログラムから見た１つの論理的な電子データの塊であり、具体的には、対象の状態を表すデータである。オブジェクトとしてのデータは、例えば、レコード、キーバリューペア又はタプルである。以下、オブジェクトとして、レコードを例に取る。
また、以下の説明では、「対象」とは、任意の有体物又は無体物である。例えば、「対象」として、口座を採用し、対象の状態として、残高を採用することができる。
また、以下の説明では、「状態更新要求」とは、状態更新処理の要求である。「状態更新処理」とは、対象の状態を更新する処理である。
図１は、実施例１に係るシステム全体の構成の一例を示す。
複数のクライアントシステム１３Ａ、１３Ｂ、…と、サーバシステム１５が、通信ネットワーク１９を介して通信可能に接続される。サーバシステム１５が、複数のノードシステム１３００Ａ、１３００Ｂ、…から構成される。複数のクライアントシステム１３Ａ、１３Ｂ、…が、一つ又は複数の第１の計算機システムの一例である。サーバシステム１５が、第２の計算機システムの一例である。ノードシステム１３００毎に管理主体が異なっていてもよいし、二つ以上（例えば全て）のノードシステム１３００の管理主体が同一でもよい。
クライアントシステム１３は、クライアントプログラム１３４を実行する。クライアントプログラム１３４の他にユーザプログラム１２４を実行するクライアントシステム１３があってもよいし（例えばクライアントシステム１３Ａ）、ユーザプログラム１２４を実行するユーザシステム１２に通信ネットワーク１４を介して接続されたクライアントシステム１３（例えばクライアントシステム１３Ｂ）があってもよい。ユーザシステム１２は、ユーザの計算機（例えば、パーソナルコンピュータ）でよい。ユーザプログラム１２４は、Ｗｅｂブラウザでもよいしアプリケーションプログラムでもよい。通信ネットワーク１４は通信ネットワーク１９と一体でもよい。
データ管理システム１０は、複数のクライアントシステム１３Ａ、１３Ｂ、…で実行される複数のクライアントプログラム１３４と、ノードシステム１３００で実行されるサーバプログラム１５４とを備える。
中間システム８０が、通信ネットワーク１９に接続される。中間システム８０は、複数のクライアントシステム１３Ａ、１３Ｂ、…と、複数のノードシステム１３００Ａ、１３００Ｂ、…との間に介在する計算機システムである。中間システム８０は、オーダリングシステムを有する。オーダリングシステムは、一つ又は複数のパーティションで構成され、パーティション毎に、トータルオーダ性を保証するシステムである。本実施例では、オーダリングシステムは、一つのパーティションで構成されている。
複数のクライアントシステム１３Ａ、１３Ｂ、…からの複数の状態更新要求が中間システム８０に入り中間システム８０から出る。複数のクライアントシステム１３Ａ、１３Ｂ、…と中間システム８０間を接続する通信ネットワークと、中間システム８０と複数のノードシステム１３００Ａ、１３００Ｂ、…間を接続する通信ネットワークが、同じであっても異なっていてもよい。
図２は、クライアントシステム１３、ノードシステム１３００及び中間システム８０の構成の一例を示す。
クライアントシステム１３は、一つ又は複数のクライアント計算機１３０を含む。
クライアント計算機１３０は、インターフェース装置１３１、記憶装置１３２及びそれらに接続されたプロセッサ１３３を有する。
インターフェース装置１３１は、通信ネットワーク１９に接続される。
記憶装置１３２は、クライアントプログラム１３４及びクライアント管理データ１３５を記憶する。クライアント管理データ１３５は、クライアント計算機１３０において管理されるデータである。
プロセッサ１３３は、クライアントプログラム１３４を実行する。クライアントプログラム１３４がプロセッサ１３３に実行されることで、要求発行部の一例としての機能が実現される。当該機能の一部は、ＦＰＧＡ又はＡＳＩＣのようなハードウェア回路により実現されてもよい。
ノードシステム１３００は、一つ又は複数のサーバ計算機１５０（ノード計算機の一例）を含む。
サーバ計算機１５０は、インターフェース装置１５１、記憶装置１５２及びそれらに接続されたプロセッサ１５３を有する。
インターフェース装置１５１は、通信ネットワーク１９に接続される。
記憶装置１５２は、サーバプログラム１５４及びサーバ管理データ１５５を記憶する。サーバ管理データ１５５は、サーバ計算機１５０において管理されるデータである。
プロセッサ１５３は、サーバプログラム１５４を実行する。サーバプログラム１５４がプロセッサ１５３に実行されることで、要求実行部の一例としての機能が実現される。当該機能の一部は、ＦＰＧＡ又はＡＳＩＣのようなハードウェア回路により実現されてもよい。
中間システム８０は、一つ以上の中間計算機４５（例えば冗長化された計算機）を備える。
中間計算機４５は、インターフェース装置４５１、記憶装置４５２及びそれらに接続されたプロセッサ４５３を有する。
インターフェース装置４５１は、通信ネットワーク１９に接続される。
記憶装置４５２は、オーダリングプログラム４５４及びオーダリング管理データ４５５を記憶する。オーダリング管理データ４５５は、中間計算機４５において管理されるデータである。
プロセッサ４５３は、オーダリングプログラム４５４を実行する。オーダリングプログラム４５４がプロセッサ４５３に実行されることで、オーダリング管理部の一例としての機能が実現される。当該機能の一部は、ＦＰＧＡ又はＡＳＩＣのようなハードウェア回路により実現されてもよい。オーダリングプログラム４５４は、クライアントシステム１３からの状態更新要求をオーダリングシステムに蓄積する。
中間システム８０の管理主体は、いずれのノードシステム１３００の管理主体とも別の管理主体であることが好ましいが、それに限定されないでもよい。例えば、いずれかのノードシステム１３００におけるいずれかのサーバ計算機１５０が中間計算機４５を兼ねてもよい。
図３は、サーバ管理データ１５５の一例を示す。
サーバ管理データ１５５は、実行管理テーブル３３と、ロックテーブル４４、アセットセット８００である。
実行管理テーブル３３は、実行された状態更新要求を表すテーブル（例えば、実行された状態更新要求が持つnonceのリスト）である。
ロックテーブル４４は、ロックの取得の可否判定に使用されるテーブルであり、いずれの状態更新要求及びいずれの対象についてロックが取得済みであるかを表すテーブルである。
アセットセット８００は、アセットの集合である。
図４は、アセットセット８００の一例を示す。
アセットセット８００は、対象毎にアセット８１０を持つ。対象のkeyから当該対象のアセット８１０が同定される。各対象について、アセット８１０は、台帳に相当してよい。
各対象について、アセット８１０は、レコードの時系列である。アセット８１０におけるレコードを「アセットレコード」と言うことができる。アセット８１０は、少なくとも末端アセットレコードを有する。アセットレコードは、key７０１、age７０２、input７０３、output７０４、BL７０５、Arg７０６、nonce７０７、Sig７０８、Prev-HV７０９及びHV７１０といった情報を持つ。以下、一つの対象及び一つのアセットレコードを例に取る（図４の説明において「注目対象」及び「注目アセットレコード」）。
key７０１は、注目対象のＩＤである。age７０２は、注目対象の状態の世代を表す。注目対象の状態が更新される都度に、インクリメントされたage７０２を持つ末端アセットレコードが追加される。本実施例では、世代が新しいとは、age７０２が大きいことである。
input７０３は、注目対象を含む一つ以上の対象の各々の直前状態（注目アセットレコード内のBL７０５を適用する前の状態）を表す。output７０４は、注目対象の直後状態（注目アセットレコード内のBL７０５を適用した後の状態）を表す。例えば、注目アセットレコードが追加されることになった状態更新処理が口座Ａ（注目対象の一例）から口座Ｂへの振込である場合、input７０３は、口座Ａと口座Ｂの各々の直前の残高を表す。output７０４は、口座Ａの直後の残高を表す。
BL７０５は、状態更新処理の処理ロジック（例えば関数）を特定するためのロジック情報である。ロジック情報は、本実施例では処理ロジックそれ自体であるが、それに代えて、処理ロジックのＩＤでもよい。
Arg７０６は、当該処理ロジックにおいて使用される一つ以上の引数である引数情報である。
XXXiは、i番目のXXXとする。outputiを、outputi＝BLi(inputi, Argi)と表現することができる。すなわち、outputiは、inputiとArgiとを用いてBLiが実行された結果としての状態である。なお、input７０３が、対象間（アセット８１０間）のレコード連鎖を実現する（図４の一点鎖線矢印を参照）。
nonce７０７は、注目対象の最新状態（output７０４）に対応したnonceである。具体的には、nonce７０７は、当該最新状態が得られた状態更新処理の状態更新要求に関連付けられているnonceである。
Sig７０８は、注目対象の最新状態（output７０４）が得られた状態更新要求を発行したユーザの秘密鍵を用いて生成された電子署名である。Sig７０８は、本実施例では、BL７０５、Arg７０６及びnonce７０７を基に生成される。なお、BL７０５を基に生成された電子署名と、Arg７０６を基に生成された電子署名と、nonce７０７を基に生成された電子署名は、別々に存在してもよい。
Prev-HV７０９は、注目対象の直前状態（直前世代）のアセットレコード（つまり親アセットレコード）のHV７１０と同じ値である。つまり、Prev-HV７０９と、親アセットレコード内のHV７１０とのリンク（図４の実線矢印を参照）が、対象に対応したアセット８１０内でのレコード連鎖を実現する。
HV７１０は、注目対象のアセットレコードのサマリ、例えばHV７１０以外の情報の少なくとも一部の情報（本実施例では全ての情報７０１〜７０９）のハッシュ値（暗号学的に衝突が困難なハッシュ値）である。
以上の通り、アセットセット８００において、同一のアセット８１０のアセットレコードにおけるPrev-HV７０９とHV７１０間でレコード連鎖が実現されている（実線矢印参照）。異なるアセット８１０のアセットレコードにおけるinput７０３間でレコード連鎖が実現されることもある。このようにして、アセットセット８００は、ＤＡＧ（Directed Acyclic Graph）構造をなす。アセットセット８００において、ノードは、アセットレコードであり、エッジは、一つ以上の状態更新処理におけるアセットレコード間の関係を表す。
各対象について、アセット８１０は、当該対象の状態の更新の履歴の一例である。アセットレコードのスキーマは限定されない。例えば、アセットレコードにおいて、一部の要素（例えば、BL７０５やSig７０８）は無くてもよい。
サーバプログラム１５４が、アセットセット８００に加えて又は代えて、最新アセットレコードセット８８を管理してもよい。最新アセットレコードセット８８は、対象毎に、最新アセットレコード（末端アセットレコードのみ）を持つ。つまり、各対象について、最新の状態が管理されていればよく、過去の状態は管理されないでもよい。
図５は、状態更新要求の構成の概要を示す。
状態更新要求は、クライアントプログラム１３４から発行される。クライアントプログラム１３４は、例えば、ユーザプログラム１２４（例えばアプリケーションプログラム）から受けた情報（例えば、対象keyを含む一つ以上の引数を含んだ情報）を含む状態更新要求を生成し、生成した状態更新要求を発行する。
状態更新要求は、nonce６１、引数群６２及び処理内容６３を含む。
引数群６２は、一つ以上の引数を含む。引数群６２における各引数には、引数key（例えば、“account.from”、“account.to”及び“money”）が関連付いている。図５の例によれば、引数keyは、引数のラベルであり、引数群６２において、明示的に示されているが、引数keyは、暗黙的に示されていてもよい。例えば、引数keyは、引数群６２の先頭からのオフセットでもよい。
処理内容６３は、当該引数群６２を用いた状態更新処理の内容を表す記述である処理記述（又は当該処理記述へのリンク）である。処理記述では、状態更新処理のうち引数が使用される処理について、当該引数の引数keyが定義されている。状態更新処理の実行において、引数keyに対応した引数が使用される。
引数群６２には、指定された対象を表す引数が含まれている。本実施例では、実行前の状態更新要求で指定されている対象keyが実行中の状態更新要求で指定されている対象keyと競合すると、それらの状態更新要求は競合しているということになる。各ノードシステム１３００において、競合する二つ以上の状態更新要求が並列に実行され、ノードシステム１３００間において当該二つ以上の状態更新要求の実行順序が異なっていると、同一対象の最新アセットレコードがノードシステム１３００間で同じにならない可能性がある。このため、競合する二つ以上の状態更新要求は、各ノードシステム１３００において決定的な順序で実行されなければならない。そのための一つの方法として、状態更新要求で指定されている対象keyが実行中の状態更新要求で指定されている対象keyと競合するか否かを判定する方法がある。
しかし、引数群６２には、いずれの引数keyが対象keyであるかは示されていない。このため、状態更新要求を実行してみないと、いずれの引数keyが対象keyであるかを特定することができない。
そこで、本実施例では、状態更新要求にコンテキスト７０が付加される。コンテキスト７０は、競合判定のための情報であり、一つ以上の対象keyを特定するための記述である。具体的には、例えば、コンテキスト７０は、一つ以上の対象keyへの直接的又は間接的な参照である。図５が示す例によれば、コンテキスト７０は、一つ以上の対象keyへの間接的な参照である。具体的には、コンテキスト７０は、引数群６２を通じて一つ以上の対象keyを特定するための記述、より具体的には、引数群６２のうちのいずれの引数keyに対応した引数が対象keyであるかを表す情報である。図５が示すコンテキスト７０から、“account.from”及び“account.to”が、対象keyに対応した引数keyであることがわかり、引数群６２から、引数key“account.from”に対応した引数“k1”と引数key“account.to”に対応した引数“k2”がそれぞれ対象keyであることがわかる。状態更新要求からこのようにして特定された対象keyが実行中の状態更新要求で指定されている対象keyと競合するか否かを判定する競合判定を行うことが可能である。
なお、コンテキスト７０は、上述したように、一つ以上の対象keyへの直接的な参照でもよい。例えば、コンテキスト７０は、“k1”及び“k2”がそれぞれ対象keyであることを直接的に示す記述（例えば、“key =[k1, k2]”という記述）でもよい。このような記述によれば、コンテキスト７０以外の記述（例えば、引数群６２）を参照すること無しに、一つ以上の対象keyを特定することができる。
図６は、実施例１の概要を示す。なお、図６において、「Rx」（xは自然数）のうちの「R」は、状態更新要求を表し、「x」は、状態更新要求の番号（例えば、nonceに相当）を表す。また、図６において、「ky」（yは自然数）は、対象keyを基に決定される値がy（yは自然数）である対象keyを表す。
オーダリングプログラム４５４は、クライアントシステム１３（クライアントプログラム１３４）から状態更新要求を受信し、受信した状態更新要求をオーダリングシステム４２１１に入れる。状態更新要求が受信される都度に、当該状態更新要求がオーダリングシステム４２１１に入れられてもよいし、一定時間が経過する都度に又は一定数の状態更新要求が受信される都度に、受信された一つ以上の状態更新要求が所定の規則に沿った順序でオーダリングシステム４２１１に入れられてもよい。
オーダリングシステム４２１１から出た状態更新要求を受ける機能である要求受信部と、要求受信部が受けた状態更新要求が実行中の状態更新要求と競合するか否かを判定する機能である競合判定部とがある。要求受信部も競合判定部も少なくとも一つの計算機システムに備えられる。本実施例では、要求受信部も競合判定部も、各ノードシステム１３００に備えられるが、要求受信部及び競合判定部の少なくとも一つは、ノードシステム１３００以外の計算機システムに備えられてもよい。例えば、中間システム８０とサーバシステム１５との間に介在する計算機システム（図示せず）に、一つ又は複数の要求受信部（例えば、ノードシステム１３００毎の一つ以上の要求受信部）が備えられてもよいし、一つ又は複数の競合判定部（例えば、ノードシステム１３００毎の一つ以上の競合判定部）が備えられてもよい。
各ノードシステム１３００において、取得スレッド３０が実行される。取得スレッド３０は、状態更新要求をオーダリングシステム４２１１から取得し、当該状態更新要求について上述の競合判定を行う。本実施例では、取得スレッド３０が、要求受信部及び競合判定部に相当する。本実施例では、各ノードシステム１３００において、一つの取得スレッド３０が予め用意されている。しかし、各ノードシステム１３００において、二つ以上の取得スレッド３０が予め用意されていてもよいし、動的に取得スレッド３０が生成されてもよい。要求受信部と競合判定部が別々のスレッドで実現されてもよい。要求受信部及び競合判定部は、スレッドに代えて、プロセスでもよいし、ノードシステム１３００内のサーバ計算機１５０でもよいし、ノードシステム１３００以外のシステムにおける要素（例えば、スレッド、プロセス又は計算機）でもよい。
各ノードシステム１３００において、取得スレッド３０が、オーダリングシステム４２１１から出た状態更新要求を受ける。状態更新要求は、取得スレッド３０によるプルとオーダリングプログラム４５４によるプッシュとのいずれかによりオーダリングシステム４２１１から取得スレッド３０へ届く。本実施例では、プルが採用される。つまり、取得スレッド３０が、オーダリングシステム４２１１から状態更新要求を取得する。なお、オーダリングシステム４２１１からノードシステム１３００への状態更新要求の送信は、at-least-onceデリバリーの送信でよい。オーダリングシステムに入っている一つの状態更新要求について、「at-least-onceデリバリーの送信」とは、当該一つの状態更新要求が少なくとも一回取り出せることを言う。
各ノードシステム１３００において、取得スレッド３０は、取得された状態更新要求が当該ノードシステム１３００において実行中の状態更新要求と競合するか否かを判定する。具体的には、取得スレッド３０は、取得された状態更新要求のコンテキスト７０から一つ以上の対象keyを特定し、特定された一つ以上の対象keyを決定的な順序でロックする。これにより、対象keyのデッドロックを避けることができる。なお、本実施例では、対象keyをロックするとは、状態更新要求の番号（例えばnonce）と、当該状態更新要求で指定されている対象keyとをロックテーブル４４に登録することである（対象keyがキーである）。「決定的な順序」とは、全ノードシステム１３００において共通の所定の順序であり、例えば、対象keyの先頭符号の若い順でよい。
少なくとも一つの対象keyがロックされなければ（例えば、ロックテーブル４４に少なくとも一つの対象keyが登録済であれば）、実行中の状態更新要求との競合が有るということである。この場合、取得スレッド３０は、ロックされている対象keyがアンロックされること（例えば、対象keyがロックテーブル４４から削除されること）を待つ。
全ての対象keyがロックされれば、実行中の状態更新要求との競合が無いということである。この場合、取得スレッド３０が、別のスレッド（以下、依頼スレッド）を生成する。取得スレッド３０は、当該依頼スレッドの処理を待たずに次の状態更新要求を取得する。生成された依頼スレッドが、状態更新要求の実行をサーバプログラム１５４に依頼する。サーバプログラム１５４は、複数の状態更新要求を並列に実行することができるよう構成されている。サーバプログラム１５４は、状態更新要求の実行依頼を受けた場合、実行中の状態更新要求の有無に関わらず（言い換えれば、実行中の一つ以上の状態更新要求があっても）、実行を依頼された状態更新要求を実行する。状態更新要求の実行が完了した場合、サーバプログラム１５４が、完了応答（状態更新要求の実行完了を表す応答）を、実行が完了した状態更新要求の発行元に返す。依頼スレッドが、当該完了した状態更新要求でロックされていた全ての対象keyをアンロックする。
状態更新要求の実行において、サーバプログラム１５４は、指定されている対象key毎に、アセットレコードをアセット８１０に追加する。アセットセット８００に代えて最新アセットレコードセット８８（図４参照）が採用されている場合、サーバプログラム１５４は、指定されている対象key毎に、当該対象keyに対応するアセットレコードを更新する。
中間システム８０において、オーダリング管理データ４５５が、オーダリングテーブル４４を含む。オーダリングテーブル４４には、ノードシステム１３００毎に、コミットオフセットが登録される。
各ノードシステム１３００について、コミットオフセットは、当該ノードシステム１３００において実行が完了した状態更新要求の位置を表す。当該ノードシステム１３００において状態更新要求の実行が完了した場合、オーダリングプログラム４５４は、当該ノードシステム１３００から、当該状態更新要求の取得完了を受ける。当該取得完了を受けた場合、当該ノードシステム１３００について、オーダリングプログラム４５４は、コミットオフセットを表す情報をオーダリングテーブル１４４に登録する。
中間システム８０が複数の中間計算機４５０を有する場合、中間システム８０が、シーケンシャルコンシステンシー以上の一貫性を持つ一つの論理的なオーダリングシステム（複数の中間計算機４５０の各々に配置されたオーダリングシステムの複製）を持つ。いずれかの中間計算機４５０のオーダリングシステムの状態が更新された場合、状態更新後のオーダリングシステムが他の全てのオーダリングシステムに反映され、結果として、複数のオーダリングシステムの状態が同じになる。
以下、実施例１で行われる処理の詳細を、図７を参照して説明する。なお、図７を参照した説明では、ノードシステム１３００Ａを例に取る。また、以下の説明では、コンテキスト７０はクライアントプログラム１３４により付加されるとする。
図７は、状態更新要求の作成から実行完了までの実施例１での流れを示すフローチャートである。
Ｓ７０１で、クライアントプログラム１３４が、ユーザプログラム１２４から一つ以上の対象keyを受けて、状態更新要求を作成する。作成された状態更新要求には、クライアントプログラム１３４により付加されたコンテキスト７０が含まれる。コンテキスト７０は、ユーザプログラム１２４から指定された対象keyを特定するための記述を含む。
Ｓ７０２で、クライアントプログラム１３４が、当該状態更新要求を発行する。
Ｓ７１１で、オーダリングプログラム４５４が、当該発行された状態更新要求を受信する。Ｓ７１２で、オーダリングプログラム４５４が、当該受信した状態更新要求をオーダリングシステム４２１１に入れる。
Ｓ７２０で、ノードシステム１３００Ａにおける取得スレッド３０Ａが、オーダリングシステム４２１１から状態更新要求を取得する。具体的には、取得スレッド３０Ａが、取得要求を中間システム８０に送信する。オーダリングプログラム４５４が、取得スレッド３０Ａからの取得要求に応答して、オーダリングシステム４２１１のうち、出力対象の状態更新要求（ノードシステム１３００Ａに対応したコミットオフセットが表す位置の次の位置にある状態更新要求）を、当該取得スレッド３０Ａに出力する。
Ｓ７２１で、取得スレッド３０Ａが、実行管理テーブル３３を参照し、取得された状態更新要求が実行済か否かを判定する。取得された状態更新要求内のnonceと同じnonceが実行管理テーブル３３に登録されていなければ、当該状態更新要求は未実行である。
Ｓ７２１の判定結果が偽の場合（Ｓ７２１：Ｎｏ）、Ｓ７２２で、取得スレッド３０Ａが、取得された状態更新要求のコンテキスト７０から、指定されている一つ以上の対象keyを特定し、一つ以上の対象keyを決定的な順序に並べ、その順序で対象keyをロックする。
Ｓ７２３で、取得スレッド３０Ａは、全ての対象keyがロックされたか否かを判定する。少なくとも一つの対象keyがロックされなかった場合（Ｓ７２３：Ｎｏ）、取得スレッド３０Ａは、ロックされなかった対象keyのアンロックを待ち、当該対象keyがアンロックされたときに、アンロックされた対象keyをロックする（Ｓ７２２）。
全ての対象keyがロックされた場合（Ｓ７２３：Ｙｅｓ）、Ｓ７２４で、取得スレッド３０Ａが、依頼スレッドを生成する。その後、取得スレッド３０Ａが、状態更新要求を取得可能な状態となる。なお、複数の依頼スレッドが予め用意されていてもよい。
生成された依頼スレッドが、Ｓ７３１で、全ての対象keyがロックされた状態更新要求の実行をサーバプログラム１５４Ａに依頼する。サーバプログラム１５４Ａは、当該依頼に応答して状態更新要求を実行する。当該状態更新要求の実行において、サーバプログラム１５４Ａが、ロックされている対象key毎のアセット８１０の更新（例えば、アセットレコードの追加）と、当該状態更新要求の番号（例えばnonce）を例えばプライマリキーとして実行管理テーブル３３に書き込むこととをアトミックに行う。状態更新要求の実行が完了した場合、サーバプログラム１５４Ａが、当該状態更新要求の完了応答を、当該状態更新要求の発行元に返す。
Ｓ７３２で、依頼スレッドが、Ｓ７２２でロックされた全ての対象keyをアンロックする。
Ｓ７３３で、依頼スレッドが、コミットを行う、具体的には、当該状態更新要求の完了を中間システム８０に通知する。オーダリングプログラム４５４が、当該通知を受けて、ノードシステム１３００Ａについて、オーダリングテーブル４４を更新する。具体的には、オーダリングプログラム４５４が、当該状態更新要求の位置を表すオフセットをコミットオフセットとする。
実施例１によれば、状態更新要求に、一つ以上の対象keyを特定するための記述であるコンテキスト７０が付加される。各ノードシステム１３００において、取得スレッド３０が、コンテキスト７０から、状態更新要求で指定された対象keyを特定し、特定された対象keyが、実行中の状態更新要求で指定された対象keyと競合しているか否かを判定する。競合が無ければ、取得スレッド３０が、依頼スレッドを生成し、状態更新要求を取得可能な状態となる。つまり、取得スレッド３０が、状態更新要求を取得し当該状態更新要求について競合が無いと判定する都度に、依頼スレッドを生成する。生成された依頼スレッドが、状態更新要求の実行をサーバプログラム１５４に依頼する。サーバプログラム１５４は、当該依頼を受けた場合、実行中の状態更新要求があっても、実行を依頼された状態更新要求を実行する。このようにして、各ノードシステム１３００において競合が無い二つ以上の状態更新要求を並列に実行でき、結果として、複数のノードシステム１３００において同一のアセットレコードが得られることを担保しつつ各ノードシステム１３００の利用効率を向上することができる。
実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を簡略又は省略する。
図８は、実施例２の概要を示す。
オーダリングシステム４２１１が、複数のパーティション４３１１で構成されている。オーダリングテーブル４４には、例えば、パーティション４３１１毎に、パーティションＩＤとパーティション位置とが登録されている。また、オーダリングテーブル４４には、パーティション４３１１毎に、コミットオフセットが登録される。なお、パーティション４３１１毎にトータルオーダ性が保証されるが、複数のパーティション４３１１間でのトータルオーダ性は保証されない。例えば、第１の状態更新要求がパーティション４３１１−１に入れられ、その後に、第２の状態更新要求がパーティション４３１１−２に入れられたとしても、第１の状態更新要求が第２の状態更新要求よりも先にパーティション４３１１−１から出るとは限らない。
以下、対象keyを基に決定される値を、便宜上、「key値」と言い、key値がN（Nは自然数）である対象keyを“keyN”と表現する。一つの対象keyに一つのパーティション４３１１が対応する。対象keyとパーティション４３１１とが１：１に対応してもよいし、連続したkey値の範囲（例えば、N=1〜10、N=11〜20）とパーティションとが１：１に対応してもよいし、離散したkey値の範囲（例えば、N=奇数、N=偶数）とパーティションとが１：１に対応してもよい。例えば、key値を用いて算出される値（例えば、key値をパーティション４３１１の数で除算して得られた余り）からパーティション４３１１が一義的に決まってもよい。図８の例によれば、key値を３（パーティション数）で除算したときの余りが１である対象key（k1、k4、k7、…）は、パーティション４３１１−１に対応し、key値を３で除算したときの余りが２である対象key（k2、k5、k8、…）は、パーティション４３１１−２に対応し、key値を３で除算したときの余りが０である対象key（k3、k6、k9、…）は、パーティション４３１１−３に対応する。状態更新要求で複数の対象keyが指定されている場合、当該状態更新要求は、一つのパーティション４３１１に入れられることもあれば、複数のパーティション４３１１に入れられることもある。状態更新要求で複数の対象keyが指定されている場合、オーダリングプログラム４５４は、対象key毎に、当該状態更新要求をコピーし、コピーされた状態更新要求を、当該対象keyに対応したパーティション４３１１に入れる。ただし、二つ以上の対象keyが同一パーティション４３１１に対応している場合、オーダリングプログラム４５４は、当該二つ以上の対象keyに対応した一つのパーティション４３１１に一つの状態更新要求を入れる。具体的には、例えば、状態更新要求で指定されている対象keyがk1及びk4の場合、k1及びk4のいずれもパーティション４３１１−１に対応するため、当該状態更新要求の入力先は、一つのパーティション４３１１−１である。また、例えば、状態更新要求で指定されている対象keyがk1及びk2の場合、k1はパーティション４３１１−１に対応しk2はパーティション４３１１−２に対応するため、当該状態更新要求の入力先は、二つのパーティション４３１１−１及び４３１１−２である。
状態更新要求で複数の対象keyが指定されている場合、オーダリングプログラム４５４が、当該複数の対象keyを決定的な順序でロックしてから、当該複数の対象keyに対応する一つ以上のパーティション４３１１に当該状態更新要求を入れる。例えば、オーダリングプログラム４５４は、k1及びk2を決定的な順序でロックしてから、k1及びk2が指定された状態更新要求を、パーティション４３１１−１及び４３１１−２に入れる。このような処理により、競合が有る二つ以上の状態更新要求（例えば、R1とR3）の順序がパーティション４３１１間で異なってしまうことを避けること、言い換えれば、競合が有る二つ以上の状態更新要求の順序を決定的な順序に保つことができる。なお、本実施例では、対象keyをロックするとは、オーダリング管理データ４５５内のロックテーブル４６に、状態更新要求の番号（例えばnonce）と、対象keyとを登録することである（対象keyが、キーである）。
各ノードシステム１３００において、取得スレッド３０は、一部のパーティション４３１１（一つ以上のパーティション４３１１）から状態更新要求を取得する。図８の例によれば、各ノードシステム１３００について、パーティション４３１１と取得スレッド３０が１：１に対応する。具体的には、パーティション４３１１−１に取得スレッド３０−１が対応し、パーティション４３１１−２に取得スレッド３０−２が対応し、パーティション４３１１−３に取得スレッド３０−３が対応する。各取得スレッド３０は、当該取得スレッド３０に対応するパーティション４３１１から状態更新要求を取得する。各取得スレッド３０は、取得された状態更新要求で二つ以上の対象keyが取得されていて、当該二つ以上の対象keyが二つ以上のパーティション４３１１に対応している場合、当該二つ以上の対象keyがロックされた後、当該状態更新要求が実行される。二つ以上のパーティション４３１１に対応した二つ以上の対象keyは、当該二つ以上のパーティション４３１１に対応する二つ以上の取得スレッド３０によってロックされてもよいし、当該二つ以上の取得スレッド３０のうちのいずれか一つの取得スレッド３０により決定的な順序でロックされてもよい。前者の一例が下記（Ｘ）であり、後者の一例が下記（Ｙ）である。本実施例では（Ｘ）が採用される。
（Ｘ）取得スレッド３０が、二つ以上の対象keyのうち、当該取得スレッド３０に対応するパーティション４３１１に対応した一つ以上の対象keyをロックする。取得スレッド３０は、状態更新要求で指定されている二つ以上の対象keyの全てがロックされた場合、当該状態更新要求の実行をサーバプログラム１５４に依頼する。例えば、取得スレッド３０−１Ａが、パーティション４３１１−１からR1(k1, k2)を取得した場合、パーティション４３１１−１に対応するk1をロックする。しかし、k2が未だロックされていないので、取得スレッド３０−１Ａは、R1(k1, k2)の実行をサーバプログラム１５４に依頼しない。その後、取得スレッド３０−２Ａが、パーティション４３１１−２からR1(k1, k2)を取得した場合、パーティション４３１１−２に対応するk2をロックする。結果として、k1及びk2の全てがロックされたことになるので、取得スレッド３０−２Ａが、R1(k1, k2)の実行をサーバプログラム１５４Ａに依頼する。R1(k1, k2)の実行が完了した場合、取得スレッド３０−１Ａ及び３０−２Ａの少なくとも一つが、k1及びk2をアンロックする。
（Ｙ）取得スレッド３０が、取得された状態更新要求で指定されている二つ以上の対象keyを決定的な順序でロックする。取得スレッド３０は、当該二つ以上の対象keyの全てをロックした場合、当該状態更新要求の実行をサーバプログラム１５４に依頼する。例えば、取得スレッド３０−１Ａが、パーティション４３１１−１からR1(k1, k2)を取得した場合、k1及びk2を決定的な順序でロックし、R1(k1, k2)の実行をサーバプログラム１５４Ａに依頼する。その後、取得スレッド３０−２Ａが、パーティション４３１１−２からR1(k1, k2)を取得した場合、k1及びk2をロックしようとするが、k1及びk2はロック済みのため待ちとなる。R1(k1, k2)の実行が完了した場合、取得スレッド３０−１Ａがk1及びk2をアンロックする。このため、取得スレッド３０−２Ａが、k1及びk2を決定的な順序でロックしてR1(k1, k2)の実行をサーバプログラム１５４Ａに依頼するが、サーバプログラム１５４Ａは、R1(k1, k2)の実行が完了していることを実行管理テーブル３３から特定するため、R1(k1, k2)の実行をスキップする。
図９は、状態更新要求の作成から実行完了までの実施例２での流れを示すフローチャートである。なお、図９を参照した説明では、ノードシステム１３００として、ノードシステム１３００Ａを例に取る。
Ｓ９０１は、Ｓ７０１と同じである。Ｓ９０２は、Ｓ７０２と同じである。Ｓ９１１は、Ｓ７１１と同じである。
Ｓ９１２で、オーダリングプログラム４５４が、条件Ａが満たされているか否かを判定する。条件Ａは、状態更新要求で指定されている対象keyが一つであるか、又は、当該状態更新要求で指定されている二つ以上のkeyの全てが同一のパーティションに対応していることである。なお、状態更新要求で指定されている対象keyは、当該状態更新要求のコンテキスト７０から特定される。Ｓ９１２の判定結果が真の場合（Ｓ９１２：Ｙｅｓ）、対象keyをロックすることが不要のため、Ｓ９１３〜Ｓ９１５がスキップされる。
Ｓ９１２の判定結果が偽の場合（Ｓ９１２：Ｎｏ）、Ｓ９１３で、オーダリングプログラム４５４が、状態更新要求で指定されている二つ以上のkeyを決定的な順序に並び替える。Ｓ９１４で、オーダリングプログラム４５４が、対象keyの並び順（つまり決定的な順序）で、当該二つ以上の対象keyをロックする。Ｓ９１５で、オーダリングプログラム４５４が、当該二つ以上の対象keyの全てをロックしたか否かを判定する。
Ｓ９１２の判定結果が真の場合（Ｓ９１２：Ｙｅｓ）、又は、Ｓ９１５の判定結果が真の場合（Ｓ９１５：Ｙｅｓ）、Ｓ９１６で、オーダリングプログラム４５４が、状態更新要求で指定されている一つ以上の対象keyの各々について、当該対象keyに対応したパーティション４３１１を決定する。例えば、オーダリングプログラム４５４が、対象key毎に、当該対象keyのkey値をパーティション数で除算することにより得られた余りから、パーティション４３１１を決定する。これにより、一つ以上の対象keyについて一つ以上のパーティション４３１１が決定される。
Ｓ９１７で、オーダリングプログラム４５４が、決定された一つ以上のパーティション４３１１の各々に、状態更新要求を入れる。
当該状態更新要求についてロックされている二つ以上の対象keyがあれば、Ｓ９１８で、オーダリングプログラム４５４が、当該二つ以上の対象keyをアンロックする。
Ｓ９２０で、取得スレッド３０−１Ａが、パーティション４３１１−１から状態更新要求を取得する。具体的には、取得スレッド３０−１Ａが、パーティション４３１１−１のパーティションＩＤを指定した取得要求を中間システム８０に送信する。オーダリングプログラム４５４が、取得スレッド３０−１Ａからの取得要求で指定されているパーティションＩＤに対応したパーティション４３１１−１のうち、出力対象の状態更新要求を、当該取得スレッド３０−１Ａに出力する。
Ｓ９２１で、サーバプログラム１５４Ａ（又は取得スレッド３０−１Ａ）が、実行管理テーブル３３を参照し、取得された状態更新要求が実行済か否かを判定する。
Ｓ９２１の判定結果が偽の場合（Ｓ９２１：Ｎｏ）、Ｓ９２２で、取得スレッド３０−１Ａが、条件Ｂが満たされているか否かを判定する。条件Ｂは、状態更新要求で指定されている対象keyが一つであるか、又は、当該状態更新要求で指定されている二つ以上のkeyの全てが同一のパーティションに対応していることである。なお、状態更新要求で指定されている対象keyは、当該状態更新要求のコンテキスト７０から特定される。Ｓ９２２の判定結果が真の場合（Ｓ９２２：Ｙｅｓ）、対象keyをロックすることが不要のため、Ｓ９２３及びＳ９２４がスキップされる。
Ｓ９２３で、取得スレッド３０−１Ａが、状態更新要求で指定されている二つ以上の対象keyのうち、パーティション４３１１−１に対応した一つ以上の対象keyをロックする。Ｓ９２４で、取得スレッド３０−１Ａは、ロックテーブル４０Ａを参照し、全ての対象keyがロックされたか否かを判定する。
全ての対象keyがロックされた場合（Ｓ９２３：Ｙｅｓ）、Ｓ９２５で、取得スレッド３０−１Ａは、状態更新要求の実行をサーバプログラム１５４Ａに依頼し、サーバプログラム１５４Ａが、当該状態更新要求を実行する。実行された状態更新要求について二つ以上の対象keyがロックされている場合、Ｓ９２７で、取得スレッド３０−１Ａが、当該二つ以上の対象keyをアンロックする。
ロックされていない対象keyがある場合（Ｓ９２３：Ｎｏ）、Ｓ９２６で、取得スレッド３０−１Ａは、全ての対象keyがロックされて状態更新要求が実行されるのを待つ。別の言い方をすれば、取得スレッド３０−１Ａは、当該状態更新要求が実行されない限り、パーティション４３１１−１から次の状態更新要求を取得することをしない。このケースでは、同一の状態更新要求が一つ以上の別のパーティション４３１１から読み出され全ての対象keyがロックされた場合に、状態更新要求が実行されることになる。例えば、取得スレッド３０−２Ａが、Ｓ９２１〜Ｓ９２３を行って、全ての対象keyがロックされたとする（Ｓ９２４：Ｙｅｓ）。このため、取得スレッド３０−２Ａが、状態更新要求の実行をサーバプログラム１５４Ａに依頼する。実行された状態更新要求について二つ以上の対象keyがロックされている場合、Ｓ９２７で、取得スレッド３０−２Ａが、当該二つ以上の対象keyをアンロックする。取得スレッド３０−１Ａが、Ｓ９２３でロックした対象keyのアンロックを検知し、待ちを終了する。Ｓ９２８で、取得スレッド３０−２Ａが、当該状態更新要求の完了を中間システム８０に通知する。オーダリングプログラム４５４が、当該通知を受けて、ノードシステム１３００Ａについて、オーダリングテーブル４４を更新する（具体的には、オーダリングプログラム４５４が、当該状態更新要求の位置を表すオフセットをコミットオフセットとする）。
実施例２によれば、オーダリングシステム４２１１が複数のパーティション４３１１に分割され、複数の状態更新要求が複数のパーティション４３１１に分散する。そして、各ノードシステム１３００において、複数のパーティション４３１１から異なる複数の取得スレッド３０により複数の状態更新要求が並列に取得され、当該複数の状態更新要求がサーバプログラム１５４により並列に実行される。このため、各ノードシステム１３００において、実施例１よりも高い並列度を実現でき、故に、ノードシステム１３００の利用効率が実施例１よりも向上する。
なお、実施例２において、図９の例によれば、オーダリングプログラム４５４は、Ｓ９１２の判定結果が偽の場合、対象keyをロックした後に当該対象keyに対応したパーティション４３１１を決定するが、対象keyに対応したパーティション４３１１を決定した後に、対象keyをロックしてもよい。つまり、状態更新要求をパーティション４３１１に入れる前に対象keyをロックするのであれば、パーティション４３１１の決定と対象keyのロックはどちらが先でもよい。
また、実施例２において、取得スレッド３０が、図９のＳ９２５、Ｓ９２７及びＳ９２８を行うことに代えて、実施例１のように、状態更新要求を取得し当該状態更新要求について競合が無いと判定する都度に、依頼スレッドを生成してもよい。依頼スレッドが、図９のＳ９２５、Ｓ９２７及びＳ９２８を行ってもよい。
また、実施例１及び２において、「状態更新要求の実行」は、状態更新処理の実行と改ざん検知処理の実行とを含んでいてもよいし、状態更新処理の実行を含むが改ざん検知処理の実行を含まないでよい（すなわち、実施例３及び４で述べるように、状態更新処理の実行と改ざん検知処理の実行とが分離されていてもよい）。ここで言う「改ざん検知処理」は、同一の状態更新要求について二つ以上のノードシステム１３００間のアセットレコード（例えば最新アセットレコード（末端アセットレコード））又はそれのHVが同一か否かを判定することを含んでよい。また、「改ざん検知処理」は、例えば、状態更新要求で指定された対象keyに対応したアセットレコード（例えば最新アセットレコード）のHVを、サーバプログラム１５４Ａが、当該アセットレコードよりも過去のアセットレコードを用いて検証することを含んでもよい。
また、実施例１及び２の少なくとも一つにおいて、オーダリングプログラム４５４の機能は、中間システム８０に代えて、各クライアントシステム１３のクライアントプログラム１３４が有していてもよい。
また、実施例１及び２の少なくとも一つにおいて、複数の状態更新要求を並列に実行することができるサーバプログラム１５４に代えて、状態更新要求を実行するためのスレッド（以下、実行スレッド）が、複数存在し、複数の実行スレッドが、複数の状態更新要求を並列に実行してもよい。複数の実行スレッドは、予め用意されていてもよいし、動的に生成されてもよい。
また、実施例１及び２において、コンテキスト付加部は、クライアントプログラム１３４（要求発行部の一例）に含まれる。クライアントプログラム１３４は、ユーザプログラム１２４から一つ以上の対象keyの指定を受けるので、状態更新要求を仮実行すること無しに、状態更新要求にコンテキスト７０を付加できる。実施例１及び２の少なくとも一つにおいて、コンテキスト付加部は、クライアントプログラム１３４に含まれない機能でよい。この場合、コンテキスト付加部は、状態更新要求の仮実行をすることにより、当該状態更新要求で指定された一つ以上の対象keyを特定し、特定された一つ以上の対象keyを特定するための記述であるコンテキスト７０を作成し、作成したコンテキスト７０を当該状態更新要求に付加してよい。コンテキスト付加部は、クライアントシステム１３（第１の計算機システムの一例）、中間システム８０、サーバシステム１５（第２の計算機システムの一例）、及び、それらのシステム１３、８０及び１５以外のシステムに備えられてよい。すなわち、実施例１及び２において、コンテキスト７０は、状態更新要求が実行されるまでのいずれかの段階において付加されればよい。具体的には、実施例１では、状態更新要求にコンテキスト７０が付加されることは、当該状態更新要求がキューに入る前でも当該状態更新要求がキューから出た後のいずれにおいて行われてもよい。実施例２では、状態更新要求にコンテキスト７０が付加されることは、当該状態更新要求がパーティションに入る前に行われればよい。コンテキスト７０の付加方法としては、下記のうちのいずれかが採用されてよい。
・実施例１及び２の少なくとも一つにおいて、クライアントプログラム１３４が、ユーザプログラム１２４から一つ以上の対象keyの指定を受け、コンテキスト７０を、クライアントプログラム１３４が送信する状態更新要求に付加してよい。
・実施例１及び２の少なくとも一つにおいて、オーダリングプログラム４５４が、状態更新要求がオーダリングシステム４２１１に入る際、又は、状態更新要求がオーダリングシステム４２１１から出る際に、当該状態更新要求を仮実行することで一つ以上の対象keyを特定し、特定した一つ以上の対象keyを特定するための記述であるコンテキスト７０を状態更新要求に付加してよい。
・実施例１において、取得スレッド３０が、オーダリングシステム４２１１から出た状態更新要求を仮実行することで一つ以上の対象keyを特定し、特定した一つ以上の対象keyを特定するための記述であるコンテキスト７０を状態更新要求に付加し、コンテキスト７０が付加された状態更新要求を、サーバプログラム１５４に渡してよい。
・実施例１及び２の少なくとも一つにおいて、ノードシステム１３００（例えば、取得スレッド３０）が、クライアントプログラム１３４からの状態更新要求を仮実行することで一つ以上の対象keyを特定し、特定した一つ以上の対象keyを特定するための記述であるコンテキスト７０を状態更新要求に付加し、コンテキスト７０が付加された状態更新要求をクライアントプログラム１３４に送信してよい。クライアントプログラム１３４が、当該状態更新要求をオーダリングプログラム４５４に送信してよい。
実施例１及び２は、例えば下記のように総括されてもよい。
データ管理システムが、一つ又は複数のコンテキスト付加部と、一つ又は複数の競合判定部とを備える。一つ又は複数の第１の計算機システムに、一つ又は複数の要求発行部が備えられる。一つ又は複数の第１の計算機システムと通信する第２の計算機システムにおける複数のノードシステムに、複数の要求実行部が備えられる。第１の計算機システムにおける要求発行部が、状態更新要求を発行する。当該状態更新要求が、オーダリングシステムに入れられる。状態更新要求は、一つ以上の引数を含む引数群と、当該引数群を使用する状態更新処理の内容を表す記述又は当該記述へのリンクである処理内容とを含む。状態更新処理は、一つ以上の対象の各々について、当該対象の状態を表すデータであるオブジェクトを更新する処理である。オーダリングシステムは、一つ又は複数のパーティションで構成され、パーティション毎に、トータルオーダ性を保証するシステムである。コンテキスト付加部が、状態更新要求に、一つ以上の対象を特定するための記述であるコンテキストを付加する。ノードシステム毎に、前記オーダリングシステムから状態更新要求が出される都度に、競合判定部が、当該状態更新要求のコンテキストから一つ以上の対象を特定し、当該特定された一つ以上の対象が当該ノードシステムにおいて実行中の一つ以上の状態更新要求で指定された一つ以上の対象と競合するか否かの競合判定を行う。当該競合判定の結果が、競合が無いとの結果の場合に、当該ノードシステムにおける要求実行部が、当該状態更新要求を実行する。
前記オーダリングシステムから出された状態更新要求について、競合判定部は、当該状態更新要求のコンテキストから特定された一つ以上の対象をロックしてよい。当該一つ以上の対象の全てがロックされた場合、前記競合判定の結果が、競合が無いとの結果でよい。
前記オーダリングシステムが前記複数のパーティションで構成されているケース（以下、マルチパーティションケース）において、各状態更新要求は、当該状態更新要求のコンテキストから特定された一つ以上の対象に対応する一つ以上のパーティションに入れられてよい。各競合判定部は、当該競合判定部に対応したパーティションから出された状態更新要求のコンテキストから、一つ以上の対象を特定してよい。
マルチパーティションケースにおいて、パーティションから出された状態更新要求について、特定された対象が二つ以上であり、且つ、当該二つ以上の対象が、当該パーティションを含む二つ以上のパーティションに対応している場合、当該パーティションに対応した競合判定部が、当該二つ以上の対象のうち、少なくとも当該パーティションに対応した対象をロックしてよい。当該二つ以上の対象の全てがロックされた場合、前記競合判定の結果が、競合が無いとの結果でよい。
マルチパーティションケースにおいて、パーティションから出された状態更新要求について、特定された対象が一つであるか、又は、特定された二つ以上の対象の全てが一つのパーティションに対応している場合、当該状態更新要求について前記競合判定が行われること無しに、当該状態更新要求が実行されてよい。
マルチパーティションケースにおいて、前記一つ又は複数の要求発行部の各々、又は、前記オーダリングシステムを有する計算機システムに備えられるオーダリング管理部が、下記をおこなってよい。
・状態更新要求のコンテキストから一つ以上の対象を特定する。
・特定された対象が二つ以上であり、且つ、当該二つ以上の対象に二つ以上のパーティションに対応している場合、当該二つ以上の対象を決定的な順序でロックする。
・当該二つ以上の対象の全てがロックされた場合に、当該二つ以上のパーティションの各々に、当該状態更新要求を入れる。
・当該二つ以上の対象を全てアンロックする。
マルチパーティションケースにおいて、前記一つ又は複数の要求発行部の各々、又は、前記オーダリングシステムを有する計算機システムに備えられるオーダリング管理部が、下記を行ってよい。
・状態更新要求のコンテキストから一つ以上の対象を特定する。
・特定された対象が一つであるか、又は、特定された二つ以上の対象の全てが一つのパーティションに対応している場合、特定された一つ以上の対象をロックすること無しに、当該状態更新要求を当該パーティションに入れる。
前記一つ又は複数の要求発行部が、前記一つ又は複数のコンテキスト付加部を含んでよい。
前記コンテキスト付加部が、状態更新要求の仮実行をすることにより、当該状態更新要求で指定された一つ以上の対象を特定してよい。前記コンテキスト付加部が、当該特定された一つ以上の対象を特定するための記述であるコンテキストを作成し、当該作成したコンテキストを当該状態更新要求に付加してよい。
以下、実施例３を説明する。その際、実施例１及び２との相違点を主に説明し、実施例１及び２との共通点については説明を簡略又は省略する。
図１０は、実施例３に係るシステム全体の構成の一例を示す。
サーバシステム１５において、ノードシステム１３００の処理速度（例えば、構成及び性能）は、異なっていてよい。例えば、ノードシステム１３００Ａは、通信ネットワーク１４００Ａに接続された四つのサーバ計算機１５０Ａａ、１５０Ａｂ、１５０Ａｃ及び１５０Ａｄで構成されている。ノードシステム１３００Ｂは、通信ネットワーク１４００Ｂに接続された二つのサーバ計算機１５０Ｂａ及び１５０Ｂｂで構成されている。図１０に例示の全てのサーバ計算機１５０の処理速度が同じ場合、ノードシステム１３００Ｂの処理速度はノードシステム１３００Ａの処理速度より低い。このように、複数のノードシステム１３００の処理速度は異なっていてよい。なお、図１０の例では、各通信ネットワーク１４００は通信ネットワーク１９に接続されているが、少なくとも一つの通信ネットワーク１４００は通信ネットワーク１９と一体でもよい。
このように、個々のノードシステム１３００は、当該ノードシステム１３００とは別のノードシステム１３００の処理速度を考慮することなく構成されてよい。
ＢＦＴ（Byzantine Fault Tolerance）コンセンサスアルゴリズムやそれに類似したブロックチェーン等の仕組みが適用された一般的なデータ管理システムによれば、サーバシステムにおける複数のノードシステムの各々が、対象毎に、オブジェクト（対象の状態を表すデータ）を管理する。サーバシステムがクライアントシステムから状態更新要求を受信する都度に、各ノードシステムが、オブジェクトの改ざんの有無を検知する改ざん検知処理を実行する。各ノードシステムにおいて、「改ざん検知処理」は、現在（状態更新処理の実行前）のオブジェクトの改ざんの有無を検知することと、状態更新処理を途中まで実行することで得られた更新後のオブジェクトの改ざんの有無を検知することとの少なくとも一つを含む。複数のノードシステムにおいて同様の改ざん検知処理が実行される。全ノードシステムの改ざん検知処理の実行が完了しないと、いずれのノードシステムも、状態更新処理を実行することができない。また、いずれかのノードシステムが先に状態更新処理の実行を完了できたとしても、全ノードシステムにおいて当該状態更新処理の実行が完了しないと、当該状態更新要求に関連する次の状態更新要求について、いずれのノードシステムも状態更新処理を実行することができない。全ノードシステムに更新後オブジェクトがあるとは限らず、故に、当該次の状態更新要求について、全ノードシステムの改ざん検知処理の実行が完了しないためである。このため、複数のノードシステムの処理速度が同じであることが望ましい。複数のノードシステムの処理速度が異なっていると、処理速度が相対的に低いノードシステムの処理結果を待つ必要が起こり、システム全体の利用効率が低下するからである。
一方、実施例３では、後に詳述するように、状態更新処理の実行と、二つ以上のノードシステム１３００のアセットレコード又はそのサマリを比較する改ざん検知処理の実行とが分離されている。具体的には、データ管理システムが、複数のノードシステム１３００に備えられる複数の要求実行部の他に、一つ又は複数の改ざん検知実行部を備える。改ざん検知実行部は、改ざん検知処理を実行する。各ノードシステム１３００において、要求実行部は、状態更新要求毎に、状態更新処理を実行し、改ざん検知処理の実行無しに、当該状態更新要求の完了を応答する。このため、サーバシステム１５における全てのノードシステム１３００の処理速度が同じである必要が無い。故に、サーバシステム１５の構成の柔軟性を高めることができ、結果として、高効率にスケーラビリティを高めることができる。
また、状態更新処理の実行と改ざん検知処理の実行とが分離されているので、状態更新処理が各ノードシステム１３００で独立して行われる。クライアントシステム１３は、少なくとも一つのノードシステム１３００から状態更新処理の完了応答が返ってくれば、関連する次の状態更新要求を送信できる。当該次の状態更新要求についても、状態更新処理が各ノードシステム１３００で独立して行われる。このため、クライアントシステム１３にとって状態更新要求のレイテンシが速い。
本実施例では、改ざん検知実行部は、クライアントプログラム１３４に含まれるが、改ざん検知実行部は、クライアントシステム１３においてクライアントプログラム１３４とは別のプログラムが実行されることにより実現される機能でもよいし、クライアントシステム１３以外のシステム、例えば、監査システム（監査の役割を担う計算機システム）に備えられてよい。一部のクライアントシステム１３、一部のノードシステム１３００又は中間システム８０の少なくとも一つが監査システムを兼ねてもよい。
図１１は、実施例３の概要の一例を示す。なお、図１１において、「Rx」（xは自然数）は、状態更新要求を表す。
クライアントプログラム１５４から発行された状態更新要求は、オーダリングシステム４２１１に入り、オーダリングシステム４２１１から複数のノードシステム１３００の各々に出るようになっている。各ノードシステム１３００において、サーバプログラム１５４が、状態更新要求の実行として、状態更新処理を実行し（例えば、指定された対象のアセットに末端アセットレコードを追加し）、改ざん検知処理の実行無しに、当該状態更新要求の完了を、クライアントプログラム１３４に応答する。状態更新要求を発行したクライアントプログラム１５４は、少なくとも一つのノードシステム１３００から当該要求に対する完了応答を受ければ、状態の更新が完了したと認識する。
上述したように、本実施例では、状態更新要求の実行の完了に、二つ以上のノードシステム１３００でのアセットレコード又はそのサマリを比較する改ざん検知処理の実行は不要である。このため、状態更新要求は全てのノードシステム１３００に送信されるものの、更新完了要求（状態更新処理の実行が完了した状態更新要求）の数は、ノードシステム１３００間で必ずしも同じにはならない。図１１の例では、オーダリングシステム４２１１に入っているR1〜R5のうち、ノードシステム１３００Ａでの更新完了要求は、R1〜R4であるが、ノードシステム１３００Ｂでの更新完了要求は、R1及びR2のみである。
クライアントプログラム１３４は、一つ又は複数の更新完了要求のうちの共通完了要求について改ざん検知処理を実行する。共通完了要求は、複数のノードシステム１３００のうちの二つ以上のノードシステム１３００に共通の更新完了要求である。図１１の例では、ノードシステム１３００Ａ及び１３００Ｂでの共通完了要求は、R1及びR2である。クライアントプログラム１３４は、少なくとも一つの共通完了要求について改ざん検知処理を実行する。
データ管理システムのアプリケーションの要件によっては、改ざん検知処理が、必ずしも状態更新要求の受信の都度に直ちに実行されなくてもよい、及び／又は、全ての状態更新要求について必ずしも改ざん検知処理の実行が必要とされないと考えられる。例えば、対象が口座であり対象の状態が残高であるアプリケーションにおいて、残高は、入金及び出金のいずれのときにも変わるが、当該アプリケーションの要件によっては、入金については残高の改ざん検知処理の実行は不要であり出金について残高の改ざん検知処理が実行されればよいと考えられる。本実施例では、状態更新処理の実行と改ざん検知処理の実行とが分離されているので、改ざん検知処理の実行のタイミングを柔軟に決定することができる、及び／又は改ざん検知処理の実行対象とする共通完了要求を柔軟に選択することができる。例えば、改ざん検知処理の実行頻度を、状態更新要求の発行頻度より少なくしたり、対象毎に、改ざん検知処理の実行が必要とされる共通完了要求を一つ以上の共通完了要求のうちの一部の共通完了要求（例えば、最新の共通完了要求）に絞ったりすることができる。
なお、改ざん検知処理は、Ｎのノードシステム１３００（Ｎは、２以上の整数であり、サーバシステム１５を構成するノードシステム１３００の数）のうちＭのノードシステム１３００（Ｍは、２以上Ｎ以下の整数）について実行されてよい。つまり、必ずしもＭ＝Ｎでなくてもよい。以下の説明では、説明を簡単にするために、Ｍ＝Ｎとする。
また、本実施例では、各対象について、当該対象を指定した状態更新要求の実行による状態の履歴の一例として、アセット８１０（図４参照）が採用される。
以下、実施例３で行われる処理の詳細を、図１２〜図１３を参照して説明する。なお、以下、実施例３の説明では、説明を簡単にするために、サーバシステム１５を構成するＮのノードシステム１３００は、ノードシステム１３００Ａ及び１３００Ｂであるとする。
図１２は、状態更新要求の作成から実行完了までの実施例３での流れを示すフローチャートである。
Ｓ１２０１で、クライアントプログラム１３４が、状態更新要求を作成する。当該状態更新要求は、例えば、key、Sig、nonce等を含む。状態更新要求にコンテキスト７０が付加されてもよい。Ｓ１２０２で、クライアントプログラム１３４が、当該状態更新要求を発行する。
Ｓ１２１１で、オーダリングプログラム４５４が、当該状態更新要求を受信する。Ｓ１２１２で、オーダリングプログラム４５４が、当該受信した状態更新要求をオーダリングシステム４２１１に入れる。
ノードシステム１３００Ａを例に取り、Ｓ１２２１及びＳ１２２２を説明する。Ｓ１２２１Ａで、サーバプログラム１５４Ａは、オーダリングシステム４２１１から状態更新要求を取得する。Ｓ１２２２Ａで、サーバプログラム１５４Ａは、当該状態更新要求を実行する。具体的には、Ｓ１２２２Ａで、サーバプログラム１５４Ａは、状態更新処理を実行するが、改ざん検知処理を実行しない。Ｓ１２２２Ａは、実施例１のＳ７２１〜Ｓ７２４及びＳ７３１〜Ｓ７３３（図７参照）でもよい。また、Ｓ１２２２Ａは、実施例２のＳ９２１〜Ｓ９２８（図９参照）でもよい。
ノードシステム１３００Ａ及び１３００Ｂの各々について、状態更新要求が完了する都度に、状態更新要求に対する応答（例えば完了応答）がクライアントプログラム１３４に返却される。ノードシステム１３００Ａ及び１３００Ｂのうちのいずれがメインのノードシステムであるかが予め決められていて、メインのノードシステムだけが、状態更新要求に対する応答をクライアントプログラム１３４に返却してもよい（メインのノードシステム以外のノードシステムは、状態更新要求が完了しても、状態更新要求に対する応答をクライアントプログラム１３４に返却しないでよい）。以下、図１２の説明において、一つの状態更新要求を例に取る（図１２の説明において「注目状態更新要求」）。
Ｓ１２３１で、クライアントプログラム１３４は、当該クライアントプログラム１３４が発行した注目状態更新要求の応答を受信する。
Ｓ１２３２で、クライアントプログラム１３４は、受信した応答に関し何らかの処理を実行する。例えば、当該受信した応答が、注目状態更新要求について初めて受信された応答であれば、クライアントプログラム１３４は、当該応答から注目状態更新要求の結果を解釈する。一方、当該応答が、注目状態更新要求について既に応答を受信した後に受信した応答であれば、クライアントプログラム１３４は、当該受信した応答を破棄する。つまり、注目状態更新要求について、最初に受信した応答が有効とされる。なお、クライアントプログラム１３４は、当該受信した応答を破棄せずに例えば一定期間保存しておいて、他のノードシステム１３００からの応答と比較してもよい。
図１３は、改ざん検知処理の実行のフローチャートである。
Ｓ１３０１で、クライアントプログラム１３４が、age問合せを作成する。age問合せでは、少なくとも一つの対象keyが指定される。以下、説明を簡単にするために、一つのage問合せには一つの対象key（図１３の説明において「注目key」）が指定されるとする。age問合せは、注目keyの最大ageの問合せである。Ｓ１３０２で、クライアントプログラム１３４が、当該age問合せを送信する。age問合せは、中間システム８０経由又は非経由で、ノードシステム１３００Ａ及び１３００Ｂの各々に送信される。
ノードシステム１３００Ａを例に取り、Ｓ１３１１及びＳ１３１２を説明する。Ｓ１３１１Ａで、ノードシステム１３００Ａにおけるサーバプログラム１５４Ａは、age問合せを受信する。Ｓ１３１２Ａで、サーバプログラム１５４Ａは、当該age問合せで指定されている注目keyの最大age（注目keyの末端アセットレコード内のage）を例えばリニアライザブルに取得し、当該最大ageを、age問合せの送信元に回答する。なお、Ｓ１３１２Ａの前に、サーバプログラム１５４Ａは、注目keyに対応したアセット８１０を構成する各アセットレコードの改ざん検知処理を行ってもよい。
Ｓ１３２１で、クライアントプログラム１３４は、最大ageを受信する。Ｓ１３２２で、クライアントプログラム１３４は、ノードシステム１３００Ａ及び１３００Ｂの全てから最大ageを受信したか否かを判定する。Ｓ１３２２の判定結果が偽の場合（Ｓ１３２２：Ｎｏ）、クライアントプログラム１３４は、ノードシステム１３００Ａ及び１３００Ｂの全てから最大ageを受信することを待つ。
Ｓ１３２２の判定結果が真の場合（Ｓ１３２２：Ｙｅｓ）、Ｓ１３２３で、クライアントプログラム１３４は、受けた最大ageのうち最大の共通age（言い換えれば、受けた最大ageの最小値）を特定する。例えば、ノードシステム１３００Ａからの最新ageが“8”でノードシステム１３００Ｂからの最新ageが“6”の場合、最大の共通ageは“6”である。Ｓ１３２４で、クライアントプログラム１３４は、上記注目keyとＳ１３２２で特定した最大共通ageとを指定したレコード問合せを作成する。Ｓ１３２５で、クライアントプログラム１３４は、当該レコード問合せを送信する。レコード問合せは、中間システム８０経由又は非経由で、ノードシステム１３００Ａ及び１３００Ｂの各々に送信される。
ノードシステム１３００Ａを例に取り、Ｓ１３３１〜Ｓ１３３３を説明する。Ｓ１３３１Ａで、ノードシステム１３００Ａにおけるサーバプログラム１５４Ａは、レコード問合せを受信する。Ｓ１３３２Ａで、サーバプログラム１５４Ａは、当該レコード問合せで指定されている注目key及び最大共通ageを持つアセットレコード又はそのサマリ（例えば、HV）を例えばリニアライザブルに取得する。Ｓ１３３３Ａで、サーバプログラム１５４Ａは、当該アセットレコード又はそのサマリを、レコード問合せの送信元に回答する。
Ｓ１３４１で、クライアントプログラム１３４は、注目key及び最大共通ageを持つアセットレコード又はそのサマリを受信する。Ｓ１３４２で、クライアントプログラム１３４は、ノードシステム１３００Ａ及び１３００Ｂの全てから注目key及び最大共通ageを持つアセットレコード又はそのサマリを受信したか否かを判定する。Ｓ１３４２の判定結果が偽の場合（Ｓ１３４２：Ｎｏ）、クライアントプログラム１３４は全てのノードシステム１３００Ａ及び１３００Ｂからアセットレコード又はそのサマリを受信することを待つ。
Ｓ１３４２の判定結果が真の場合（Ｓ１３４２：Ｙｅｓ）、Ｓ１３４３で、クライアントプログラム１３４は、受信した全てのアセットレコード又はそのサマリが一致するか否かを判定する。Ｓ１３４３の判定結果が真の場合（Ｓ１３４３：Ｙｅｓ）、Ｓ１３４４で、クライアントプログラム１３４は、改ざん無しと判定する。Ｓ１３４３の判定結果が偽の場合（Ｓ１３４３：Ｎｏ）、Ｓ１３４５で、クライアントプログラム１３４は、改ざん有りと判定する。
以上が、改ざん検知処理の実行の説明である。
改ざん検知処理の実行において、age問合せの作成及び送信のタイミングは、アプリケーションの要件又はその他に応じて柔軟に設定可能である。
また、改ざん検知処理の実行において、改ざんの有無が検知される共通ageも、アプリケーションの要件又はその他に応じて柔軟に設定可能である。例えば、改ざん有無が検知される一つ以上の共通ageは、最大共通ageのみでもよいし、最大共通ageと最大共通ageよりも小さい（古い）全ての共通ageでもよいし、最大共通ageと最大共通ageよりも小さい共通ageとのうちの任意の一つ以上の共通ageでもよい。
以下、実施例４を説明する。その際、実施例３との相違点を主に説明し、実施例３との共通点については説明を簡略又は省略する。
実施例３では、クライアントプログラム１３４が、age問合せを各ノードシステム１３００に送信し、最大ageの回答を各ノードシステム１３００から受け、最大の共通ageを特定する。その後に、クライアントプログラム１３４が、特定した最大の共通ageを指定したレコード問合せを各ノードシステム１３００に送信し、最大の共通ageのアセットレコード又はそれのサマリを各ノードシステム１３００から受ける。つまり、クライアントプログラム１３４と各ノードシステム１３００間で２段階のやり取りが行われる。
実施例４では、クライアントプログラム１３４と各ノードシステム１３００間でのやり取りは１段階である。
図１４は、実施例４に係る改ざん検知処理の実行のフローチャートである。
Ｓ１４０１で、クライアントプログラム１３４が、レコード問合せを作成する。Ｓ１４０１で作成されるレコード問合せでは、少なくとも一つの対象keyが指定される。以下、説明を簡単にするために、一つのレコード問合せには一つの対象key（図１４の説明において「注目key」）が指定されるとする。Ｓ１４０１で作成されるレコード問合せは、注目keyの全アセットレコードの問合せである。Ｓ１４０２で、クライアントプログラム１３４が、当該レコード問合せを送信する。レコード問合せは、中間システム８０経由又は非経由で、ノードシステム１３００Ａ及び１３００Ｂの各々に送信される。
ノードシステム１３００Ａを例に取り、Ｓ１４１１及びＳ１４１２を説明する。Ｓ１４１１Ａで、ノードシステム１３００Ａにおけるサーバプログラム１５４Ａは、レコード問合せを受信する。Ｓ１４１２Ａで、サーバプログラム１５４Ａは、当該レコード問合せで指定されている注目keyの全アセットレコード（アセット８１０）を例えばリニアライザブルに取得し、当該全アセットレコード（又は、全アセットレコードにそれぞれ対応した全アセットレコードサマリと全age（全アセットレコードのage））を、レコード問合せの送信元に回答する。なお、Ｓ１４１２Ａの前に、サーバプログラム１５４Ａは、注目keyに対応したアセット８１０を構成する各アセットレコードの改ざん検知処理を行ってもよい。
Ｓ１４２１で、クライアントプログラム１３４は、少なくとも一つのノードシステム１３００から全アセットレコード（又は、全アセットレコードサマリと全age）を受信する。Ｓ１４２２で、クライアントプログラム１３４は、ノードシステム１３００Ａ及び１３００Ｂの全てから全アセットレコード（又は、全アセットレコードサマリと全age）を受信したか否かを判定する。Ｓ１４２２の判定結果が偽の場合（Ｓ１４２２：Ｎｏ）、クライアントプログラム１３４は、ノードシステム１３００Ａ及び１３００Ｂの全てから全アセットレコード（又は、全アセットレコードサマリと全age）を受信することを待つ。
Ｓ１４２２の判定結果が真の場合（Ｓ１４２２：Ｙｅｓ）、Ｓ１４２３で、クライアントプログラム１３４は、ノードシステム１３００Ａ及び１３００Ｂの全アセットレコード（又は、全アセットレコードサマリと全age）から、最大の共通ageを特定し、特定された最大共通ageを含む共通アセットレコードである最新共通アセットレコード（又は、当該共通アセットレコードのサマリである最新共通アセットレコードサマリ）を特定する。「共通アセットレコード」は、共通完了要求（別の言い方をすれば、共通age）に対応したアセットレコードである（「共通アセットレコードサマリ」は、共通アセットレコードのサマリである）。
Ｓ１４２４で、クライアントプログラム１３４は、特定された最新共通アセットレコード（又は、最新共通アセットレコードサマリ）がノードシステム１３００Ａ及び１３００Ｂ間で一致するか否かを判定する。Ｓ１４２４の判定結果が真の場合（Ｓ１４２４：Ｙｅｓ）、Ｓ１４２５で、クライアントプログラム１３４は、改ざん無しと判定する。Ｓ１４２４の判定結果が偽（Ｓ１４２４：Ｎｏ）となったアセットレコードについては、Ｓ１４２６で、クライアントプログラム１３４は、改ざん有りと判定する。
以上が、実施例４に係る改ざん検知処理の一例である。
なお、図１４の説明において、各ノードシステム１３００について、注目keyに対応した「全アセットレコード」は、必ずしもアセット８１０それ自体としての全アセットレコードでなくてもよい。例えば、Ｓ１４０１で作成されたレコード問合せでは、注目keyについて、レコード条件が指定されてもよい。「レコード条件」は、例えば、アセットレコードの追加日時に関する条件でよい。この場合、「全アセットレコード」とは、指定されたレコード条件に該当する全アセットレコードでよい。
また、Ｓ１４２３では、最新共通アセットレコード（又は、最新共通アセットレコードサマリ）に代えて、全共通アセットレコード（又は、全共通アセットレコードサマリ）が特定されてもよいし、最新共通アセットレコードを含む又は除く一部の共通アセットレコード（又は、最新共通アセットレコードサマリを含む又は除く一部の共通アセットレコードサマリ）が特定されてもよい。
また、クライアントプログラム１３４は、クライアントシステム１３０の通信状況及び／又はその他の状況に応じて、実施例３に係る改ざん検知処理と実施例４に係る改ざん検知処理のいずれを行うかを、選択してもよい。
実施例３及び４は、例えば下記のように総括されてもよい。
データ管理システムが、一つ又は複数の改ざん検知実行部と、一つ又は複数の第１の計算機システムと通信する第２の計算機システムにおける複数のノードシステムに備えられた複数の要求実行部とを備える。第１の計算機システムに備えられる要求発行部が、対象を指定した状態更新要求を発行する。各ノードシステムにおいて、要求実行部は、状態更新要求毎に、指定されている対象の状態を表すデータであるオブジェクトを更新する状態更新処理を実行し、改ざん検知処理の実行無しに、当該状態更新要求の完了を応答する。改ざん検知実行部が、一つ又は複数の更新完了要求のうちの一つ以上の共通完了要求の各々について、前記複数のノードシステムの更新後のオブジェクト又はそのサマリを比較することにより当該更新後オブジェクトの改ざんの有無を検知する改ざん検知処理を実行する。更新完了要求は、状態更新処理の実行が完了している状態更新要求である。共通完了要求は、前記複数のノードシステムのうちの二つ以上のノードシステムに共通の更新完了要求である。
各ノードシステムにおいて、前記指定された対象の状態を表すオブジェクトは、当該状態の世代を表すデータを含んでよい。前記指定された対象について、前記改ざん検知実行部が、下記を行ってよい。
・前記改ざん検知実行部が、前記複数のノードシステムの各々から、当該対象の状態の最新世代を表す最新世代情報を受信する。
・前記改ざん検知実行部が、前記複数のノードシステムの最新世代情報から最新の共通の世代を特定する。
・前記改ざん検知実行部が、当該特定された最新の共通の世代を含む一つ又は複数の共通の世代うちの一つ以上の共通の世代を前記二つ以上のノードシステムの各々に指定する。
・前記改ざん検知実行部が、当該一つ以上の共通の世代の各々について、当該共通の世代に対応した共通完了要求の更新後オブジェクト又はそのサマリを前記二つ以上のノードシステムの各々から受信する。
また、前記指定された対象について、前記改ざん検知実行部が、下記を行ってよい。
・前記改ざん検知実行部が、前記複数のノードシステムの各々から、当該対象について、全ての更新後オブジェクト、又は、全ての更新後オブジェクトサマリを受信する。更新後オブジェクトサマリは、更新後のオブジェクトのサマリである。
・前記改ざん検知実行部が、前記複数のノードシステムの全ての更新後オブジェクト又は全ての更新後オブジェクトサマリから、前記複数のノードシステムの少なくとも一つの共通更新後オブジェクト又は少なくとも一つの共通更新後オブジェクトサマリを特定する。共通更新後オブジェクトは、共通完了要求に対応した更新後オブジェクトである。共通更新後オブジェクトサマリは、共通更新後オブジェクトのサマリである。
・前記改ざん検知実行部が、前記複数のノードシステムの共通更新後オブジェクト又はそのサマリを比較することにより当該共通更新後オブジェクトの改ざんの有無を検知する。
実施例３及び４の少なくとも一つに係るデータ管理システムは、実施例１及び２の少なくとも一つに係るデータ管理システムが有する機能（例えば、コンテキスト付加部及び競合判定部）を含んでいてもいなくてもよい。また、実施例３及び４の少なくとも一つにおいて、オーダリングシステムは、一つのパーティションで構成されていてもよいし、複数のパーティションで構成されていてもよい。
以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。
例えば、アセットセット８００は、ＵＴＸＯ（Unspent Transaction Output）のようなＤＡＧ構造の複数のトランザクションでもよい（各トランザクションは、一つ以上の入力と一つ以上の出力とを含む）。つまり、ノードとなるオブジェクトが、トランザクションでよく、エッジが表す関係が、トランザクション間の関係でよい。
また、例えば、処理ロジック、Arg、nonceのうちの少なくとも一つについてユーザの秘密鍵を用いた電子署名は作成されないでもよい。従って、例えば、クライアントプログラム１３４から発行される要求に、BL、nonce及びSigのうちの少なくとも一つは関連付けられないでもよい。
また、例えば、各ノードシステム１３００において、アセットレコードの追加（書き込み）又は取得（読み込み）は、リニアライザブル及び／又はシリアライザブルに行われてよい。
１３：クライアントシステム
１５：サーバシステム
８０：中間システム
１３００：ノードシステム

Claims (5)

  1. 一つ又は複数の改ざん検知実行部と、
    一つ又は複数の第１の計算機システムと通信する第２の計算機システムにおける複数のノードシステムに備えられた複数の要求実行部と
    を備え、
    第１の計算機システムに備えられる要求発行部が、対象を指定した状態更新要求を発行し、
    各ノードシステムにおいて、要求実行部は、状態更新要求毎に、
    当該状態更新要求で指定されている対象の状態を表すデータであるオブジェクトを更新する状態更新処理を実行し、
    改ざん検知処理の実行無しに、当該状態更新要求の完了を応答し、
    改ざん検知実行部が、一つ又は複数の更新完了要求のうちの一つ以上の共通完了要求の各々について、前記複数のノードシステムの更新後のオブジェクト又はそのサマリを比較することにより当該更新後オブジェクトの改ざんの有無を検知する改ざん検知処理を実行し、
    更新完了要求は、状態更新処理の実行が完了している状態更新要求であり、
    共通完了要求は、前記複数のノードシステムのうちの二つ以上のノードシステムに共通の更新完了要求である、
    データ管理システム。
  2. 各ノードシステムにおいて、前記指定された対象の状態を表すオブジェクトは、当該状態の世代を表すデータを含み、
    前記指定された対象について、前記改ざん検知実行部が、
    前記複数のノードシステムの各々から、当該対象の状態の最新世代を表す最新世代情報を受信し、
    前記複数のノードシステムの最新世代情報から最新の共通の世代を特定し、
    当該特定された最新の共通の世代を含む一つ又は複数の共通の世代のうちの一つ以上の共通の世代を前記二つ以上のノードシステムの各々に指定し、
    当該一つ以上の共通の世代の各々について、当該共通の世代に対応した共通完了要求の更新後オブジェクト又はそのサマリを前記二つ以上のノードシステムの各々から受信する、
    請求項１に記載のデータ管理システム。
  3. 前記指定された対象について、前記改ざん検知実行部が、
    前記複数のノードシステムの各々から、当該対象について、全ての更新後オブジェクト、又は、全ての更新後オブジェクトサマリを受信し、
    更新後オブジェクトサマリは、更新後のオブジェクトのサマリであり、
    前記複数のノードシステムの全ての更新後オブジェクト又は全ての更新後オブジェクトサマリから、前記複数のノードシステムの少なくとも一つの共通更新後オブジェクト又は少なくとも一つの共通更新後オブジェクトサマリを特定し、
    共通更新後オブジェクトは、共通完了要求に対応した更新後オブジェクトであり、
    共通更新後オブジェクトサマリは、共通更新後オブジェクトのサマリであり、
    前記複数のノードシステムの共通更新後オブジェクト又はそのサマリを比較することにより当該共通更新後オブジェクトの改ざんの有無を検知する、
    請求項１に記載のデータ管理システム。
  4. 各ノードシステムにおいて、前記指定された対象の状態を表すオブジェクトは、当該状態の世代を表すデータを含み、
    前記少なくとも一つの共通更新後オブジェクトは、最新の共通の世代の共通更新後オブジェクトである、又は、前記少なくとも一つの共通更新後オブジェクトサマリは、最新の共通の世代の共通更新後オブジェクトサマリである、
    請求項３に記載のデータ管理システム。
  5. 一つ又は複数の第１の計算機システムと通信する第２の計算機システムにおける複数のノードシステムの各々において、対象が指定され第１の計算機システムから発行された状態更新要求毎に、
    当該状態更新要求で指定されている対象の状態を表すデータであるオブジェクトを更新する状態更新処理を実行し、
    改ざん検知処理の実行無しに、当該状態更新要求の完了を応答し、
    一つ又は複数の更新完了要求のうちの一つ以上の共通完了要求の各々について、前記複数のノードシステムの更新後のオブジェクト又はそのサマリを比較することにより当該更新後オブジェクトの改ざんの有無を検知する改ざん検知処理を実行し、
    更新完了要求は、状態更新処理の実行が完了している状態更新要求であり、
    共通完了要求は、前記複数のノードシステムのうちの二つ以上のノードシステムに共通の更新完了要求である、
    データ管理方法。
JP2020507134A 2019-01-23 2020-01-23 改ざん検知性を有するシステム Active JP6694204B1 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
JP2019009589 2019-01-23
JP2019009558 2019-01-23
JP2019009558 2019-01-23
JP2019009589 2019-01-23
JP2019207634 2019-11-18
JP2019207634 2019-11-18
PCT/JP2020/002421 WO2020153454A1 (ja) 2019-01-23 2020-01-23 改ざん検知性を有するシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2020067456A Division JP2021082243A (ja) 2019-01-23 2020-04-03 改ざん検知性を有するシステム

Publications (2)

Publication Number Publication Date
JP6694204B1 true JP6694204B1 (ja) 2020-05-13
JPWO2020153454A1 JPWO2020153454A1 (ja) 2021-02-18

Family

ID=70549854

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020507134A Active JP6694204B1 (ja) 2019-01-23 2020-01-23 改ざん検知性を有するシステム

Country Status (2)

Country Link
US (1) US11632293B2 (ja)
JP (1) JP6694204B1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4362385A1 (en) 2022-10-26 2024-05-01 Toyota Jidosha Kabushiki Kaisha Data management apparatus and data management method
EP4362384A1 (en) 2022-10-26 2024-05-01 Toyota Jidosha Kabushiki Kaisha Data management apparatus and data management method

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023045607A (ja) * 2021-09-22 2023-04-03 トヨタ自動車株式会社 データ管理装置およびデータ管理方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170323392A1 (en) * 2016-05-05 2017-11-09 Lance Kasper Consensus system for manipulation resistant digital record keeping

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09311806A (ja) 1996-05-24 1997-12-02 Hitachi Ltd データ不正更新の検出方法
US8548168B2 (en) * 2007-07-19 2013-10-01 Vixs Systems, Inc. Security module for securing an encrypted signal with system and method for use therewith
US8566596B2 (en) * 2010-08-24 2013-10-22 Cisco Technology, Inc. Pre-association mechanism to provide detailed description of wireless services
JP6053950B2 (ja) * 2013-11-06 2016-12-27 三菱電機株式会社 ソフトウェア更新装置及びソフトウェア更新プログラム
US10475034B2 (en) * 2016-02-12 2019-11-12 Square, Inc. Physical and logical detections for fraud and tampering
US10614456B2 (en) * 2016-08-18 2020-04-07 Visa International Service Association Dynamic cryptocurrency aliasing
CN107862215B (zh) * 2017-09-29 2020-10-16 创新先进技术有限公司 一种数据存储方法、数据查询方法及装置
US11176093B2 (en) * 2018-11-29 2021-11-16 International Business Machines Corporation Defensible disposition of data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170323392A1 (en) * 2016-05-05 2017-11-09 Lance Kasper Consensus system for manipulation resistant digital record keeping

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
沖野 健一: "分散台帳技術のセキュリティ要件", 金融研究 第３７巻 第１号, vol. 第37巻, JPN6020009067, 22 January 2018 (2018-01-22), pages 89 - 108, ISSN: 0004229481 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4362385A1 (en) 2022-10-26 2024-05-01 Toyota Jidosha Kabushiki Kaisha Data management apparatus and data management method
EP4362384A1 (en) 2022-10-26 2024-05-01 Toyota Jidosha Kabushiki Kaisha Data management apparatus and data management method

Also Published As

Publication number Publication date
US20220123991A1 (en) 2022-04-21
JPWO2020153454A1 (ja) 2021-02-18
US11632293B2 (en) 2023-04-18

Similar Documents

Publication Publication Date Title
JP6694204B1 (ja) 改ざん検知性を有するシステム
US11308127B2 (en) Log-based distributed transaction management
US20190034465A1 (en) Blockchain logging of data from multiple systems
CN109815373B (zh) 数据存储的控制方法、装置、服务器及可读存储介质
US10296371B2 (en) Passive two-phase commit system for high-performance distributed transaction execution
US9632955B2 (en) Reorder buffer permitting parallel processing operations with repair on ordering hazard detection within interconnect circuitry
CN103164219A (zh) 去中心化架构中使用多类型副本的分布式事务处理系统
JP6618138B1 (ja) 改ざん検知性を有するデータ管理システム
Sharma et al. How to databasify a blockchain: the case of hyperledger fabric
JP2023541298A (ja) トランザクション処理方法、システム、装置、機器、及びプログラム
CN111724258B (zh) 基于环形拓扑、依赖图及多版本控制的联盟链交易并发方案的实现方法
US9442878B2 (en) Parallel snoop and hazard checking with interconnect circuitry
JP6694203B1 (ja) 改ざん検知性を有するシステム
WO2020153454A1 (ja) 改ざん検知性を有するシステム
US7809874B2 (en) Method for resource sharing in a multiple pipeline environment
KR102386922B1 (ko) 블록 체인 시스템
JP7152828B1 (ja) ビザンチン故障を検知するデータ管理システム及び方法
WO2020152893A1 (ja) 改ざん検知性を有するデータ管理システム
WO2022250047A1 (ja) ビザンチン故障を検知するデータ管理システム及び方法
Tang et al. An efficient deadlock prevention approach for service oriented transaction processing
US9852088B2 (en) Hazard checking control within interconnect circuitry
Lin et al. A MVCC Approach to Parallelizing Interoperability of Consortium Blockchain
Wang et al. Towards highly-concurrent leaderless state machine replication for distributed systems
Bessani et al. Active quorum systems
WO2018193638A1 (ja) 計算機及びトランザクション処理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200207

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20200207

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200218

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20200304

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200310

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200403

R150 Certificate of patent or registration of utility model

Ref document number: 6694204

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250