CN113287113A - 具有篡改检测性的系统 - Google Patents

Abstract

在各节点系统中，请求执行部针对每个状态更新请求执行更新客体的状态更新处理，该客体表示由该请求指定的对象的状态，并且不执行篡改检测处理地响应请求的完成。篡改检测执行部针对一个或多个更新完成请求中的一个以上的共同完成请求执行篡改检测处理，该篡改检测处理通过比较两个以上的节点系统的更新后客体或其概要，来检测有无篡改。更新完成请求是状态更新处理的执行已完成的状态更新请求。共同完成请求是多个节点系统中的两个以上节点系统共同的更新完成请求。

Description

具有篡改检测性的系统

技术领域

本发明总体上涉及一种篡改检测技术。

背景技术

作为具有篡改检测性的系统的一例，已知有应用了分布式账本技术的系统，作为分布式账本技术的一例，已知有区块链(例如非专利文献1)。

现有技术文献

非专利文献

非专利文献1:https://bitcoin.org/bitcoin.pdf

发明内容

发明要解决的课题

在以下的说明中，“对象”是指任意的有形物或无形物。例如，可以采用账户作为“对象”，采用余额作为对象的状态。

另外，在以下的说明中，“状态更新请求”是指状态更新处理的请求。“状态更新处理”是指更新对象的状态的处理。“篡改检测处理”是检测客体有无篡改的处理。“节点系统”是服务器系统的构成要素，是具备一个以上的计算机的系统。

已知有许多BFT(Byzantine Fault Tolerance：拜占庭容错)共识算法和与其类似的区块链等的结构(例如，HyperLedger fabric的endorsement)。根据这种结构，服务器系统中的多个节点系统中的每一个针对每个对象来管理客体(表示对象的状态的数据)。每当服务器系统从客户端系统接收到状态更新请求时，各节点系统都执行检测客体有无篡改的篡改检测处理。在各节点系统中，“篡改检测处理”包括以下两个处理中的至少一个：检测当前(在执行状态更新处理之前)的客体有无篡改；以及检测通过状态更新处理执行到中途而获得的更新后的客体有无篡改。在多个节点系统中执行同样的篡改检测处理。如果所有节点系统的篡改检测处理的执行没有完成，则任何节点系统都不能执行状态更新处理。另外，即使某个节点系统先完成了状态更新处理的执行，如果在所有节点系统中该状态更新处理的执行没有完成，则对于与该状态更新请求相关联的下一个状态更新请求，任何节点系统都不能执行状态更新处理。因为并非所有节点系统都有更新后的客体，因此对于该下一个状态更新请求，所有节点系统的篡改检测处理的执行都没有完成。

因此，希望多个节点系统的处理速度相同。若多个节点系统的处理速度不同，则需要等待处理速度相对较低的节点系统的处理结果，系统整体的利用效率降低。

因此，服务器系统的构成的灵活性较低。例如，当追加或更换节点系统的情况下，希望追加或更换的节点系统是具有与服务器系统中存在的其他节点系统相同的处理速度的节点系统。

这样的问题使服务器系统的规模变得困难，因此，引起难以确保可扩展性的问题。

这种问题不限于应用了BFT共识算法或与其类似的区块链等结构的数据管理系统，对于通过比较多个节点系统之间的处理结果来确保篡改检测性的所有数据管理系统也可能发生。

解决问题的技术手段

根据数据管理系统的应用的必要条件，在每次接收到状态更新请求时不必立即执行篡改检测处理，和/或不必对所有状态更新请求执行篡改检测处理。例如，在对象为帐户且对象的状态为余额的应用中，余额在存款和取款的任意一种情况下都会发生变化，但根据该应用的必要条件，可能在存款中不需要执行余额的篡改检测处理，而对于取款执行余额的篡改检测处理即可。

因此，本发明将状态更新处理的执行与对两个以上的节点系统的客体的篡改检测处理的执行分开。

具体而言，数据管理系统包括一个或多个篡改检测执行部和多个请求执行部。在与一个或多个第一计算机系统通信的第二计算机系统中的多个节点系统中具备多个请求执行部。

第一计算机系统所具备的请求发布部发布指定了对象的状态更新请求。在各节点系统中，请求执行部针对每个状态更新请求执行更新客体的状态更新处理，该客体是表示由该状态更新请求指定的对象的状态的数据，并且不执行篡改检测处理地对状态更新请求的完成进行响应。篡改检测执行部针对一个或多个更新完成请求中的共同完成请求执行篡改检测处理，该篡改检测处理通过比较多个节点系统中的两个以上节点系统的更新后客体或其概要，来检测有无篡改。更新完成请求是状态更新处理的执行已完成的状态更新请求。共同完成请求是多个节点系统中的两个以上节点系统共同的更新完成请求。

篡改检测执行部可以是请求发布部中包括的功能，或者可以是不包括在请求发布部中的功能。篡改检测执行部可以包括在第一计算机系统、第二计算机系统以及除这些系统之外的系统中。

发明的效果

由于状态更新处理的执行和篡改检测处理的执行是分开的，因此，在各节点系统中，对于每个状态更新请求，不执行篡改检测处理地完成状态更新处理的执行。因此，不需要由处理速度相同的多个节点系统构成第二计算机系统。因此，能够提高第二计算机系统的构成的灵活性，结果，能够高效率地提高可扩展性。

另外，由于状态更新处理的执行和篡改检测处理的执行是分开的，所以在各节点系统中独立地执行状态更新处理。如果从至少一个节点系统返回状态更新处理的完成响应，则第一计算机系统(例如，客户端系统)可以发送相关联的下一个状态更新请求。对于该下一个状态更新请求，在每个节点系统中独立地执行状态更新处理。因此，对于第一计算机系统来说，状态更新处理的执行中的延迟较低。

另外，由于状态更新处理的执行和篡改检测处理的执行是分开的，所以可以灵活地确定篡改检测处理的执行定时，和/或可以灵活地选择作为篡改检测处理的执行对象的共同完成请求。例如，在对象是帐户、对象的状态是余额的应用中，可以进行如下设定：在存款时不进行余额的篡改检测处理，而在取款时进行余额的篡改检测处理。

附图说明

图1表示实施例1的系统整体的构成的一例。

图2表示客户端系统、节点系统以及中间系统的构成的一例。

图3表示服务器管理数据的一例。

图4表示资产集的一例。

图5表示状态更新请求的构成的概要。

图6表示实施例1的概要。

图7是表示从状态更新请求的生成到执行完成为止的实施例1中的流程的流程图。

图8表示实施例2的概要。

图9是表示从状态更新请求的生成到执行完成为止的实施例2中的流程的流程图。

图10表示实施例3的系统整体的构成的一例。

图11表示实施例3的概要的一例。

图12是表示从状态更新请求的生成到执行完成为止的实施例3中的流程的流程图。

图13是篡改检测处理的执行的流程图。

图14是实施例4的篡改检测处理的执行的流程图。

具体实施方式

在以下的说明中，“接口装置”包括一个以上的接口。一个以上的接口可以是一个以上的同种类的通信接口设备(例如，一个以上的NIC(Network Interface Card：网络接口卡))，也可以是两个以上的不同种类的通信接口设备(例如，NIC和HBA(Host Bus Adapter：主机总线适配器))。

另外，在以下的说明中，“存储装置”包括一个以上的存储器。关于存储装置，至少一个存储器可以是易失性存储器。存储装置主要在处理器进行处理时使用。除了存储器之外，存储装置还可以包括一个以上的非易失性存储设备(例如，HDD(Hard Disk Drive：硬盘驱动器)或SSD(Solid State Drive：固态驱动器))。

另外，在以下的说明中，“处理器”包括一个以上的处理器。至少一个处理器典型的是CPU(Central Processing Unit：中央处理单元)那样的微处理器。一个以上的处理器分别可以是单核，也可以是多核。处理器可以包括进行处理的一部分或全部的硬件电路。

另外，在以下的说明中，有时将“程序”作为主语来说明处理，但程序通过处理器来执行，由此，适当使用存储装置(例如存储器)和/或接口装置(例如通信端口)等并进行所定的处理，因此处理的主语也可以是处理器。以程序为主语说明的处理也可以是处理器或具有该处理器的装置进行的处理。另外，处理器也可以包括进行处理的一部分或全部的硬件电路(例如，FPGA(Field-Programmable Gate Array：现场可编程门阵列)或ASIC(Application Specific Integrated Circuit：专用集成电路))。程序可以从程序源安装到计算机那样的装置中。程序源例如可以是程序分发服务器或计算机可读的记录介质(例如，非临时记录介质)。另外，在以下的说明中，可以将两个以上的程序作为一个程序来实现，也可以将一个程序作为两个以上的程序来实现。

另外，在以下的说明中，有时通过“yyy部”的表述来说明功能，但功能可以通过由处理器执行一个以上的计算机程序来实现，也可以通过一个以上的硬件电路(例如FPGA或ASIC)来实现，还可以通过它们的组合来实现。在由处理器执行程序由此来实现功能的情况下，由于适当地使用存储装置和/或接口装置等并进行所定的处理，因此功能可以是处理器的至少一部分。以功能为主语说明的处理可以是处理器或具有该处理器的装置进行的处理。各功能的说明是一个例子，也可以将多个功能汇总为一个功能，或者将一个功能分割为多个功能。

另外，在以下的说明中，在不区别同种类的要素而进行说明的情况下，有时使用参照符号中的共同符号，在区别同种类的要素的情况下，有时使用参照符号。

另外，在以下的说明中，“客体”是指从应用程序那样的程序来看的一个逻辑电子数据的块，具体而言，是表示对象的状态的数据。作为客体的数据例如是记录、键值对或元组。以下，作为客体，以记录为例。

另外，在以下的说明中，“对象”是指任意的有形物或无形物。例如，可以采用账户作为“对象”，采用余额作为对象的状态。

另外，在以下的说明中，“状态更新请求”是指状态更新处理的请求。“状态更新处理”是指更新对象状态的处理。

实施例1

图1表示实施例1的系统整体的构成的一例。

多个客户端系统13A、13B、...和服务器系统15经由通信网络19可通信地连接。服务器系统15由多个节点系统1300A、1300B…构成。多个客户端系统13A、13B、...是一个或多个第一计算机系统的一例。服务器系统15是第二计算机系统的一例。每个节点系统1300的管理主体可以不同，两个以上(例如全部)的节点系统1300的管理主体也可以相同。

客户端系统13执行客户端程序134。也可以存在除了客户端程序134之外还执行用户程序124的客户端系统13(例如，客户端系统13A)，或者可以存在经由通信网络14与执行用户程序124的用户系统12连接的客户端系统13(例如，客户端系统13B)。用户系统12可以是用户的计算机(例如，个人计算机)。用户程序124可以是Web浏览器，也可以是应用程序。通信网络14可以与通信网络19一体化。

数据管理系统10具备由多个客户端系统13A、13B、...执行的多个客户端程序134和由节点系统1300执行的服务器程序154。

中间系统80与通信网络19连接。中间系统80是介于多个客户端系统13A、13B、...和多个节点系统1300A、1300B、…之间的计算机系统。中间系统80具有排序系统。排序系统是由一个或多个分区构成，并确保每个分区的排序性的系统。在本实施例中，排序系统由一个分区构成。

来自多个客户端系统13A、13B、...的多个状态更新请求进入中间系统80并从中间系统80发出。连接多个客户端系统13A、13B、...和中间系统80之间的通信网络与连接中间系统80和多个节点系统1300A、1300B、…之间的通信网络可以相同也可以不同。

图2表示客户端系统13、节点系统1300和中间系统80的构成的一例。

客户端系统13包括一个或多个客户端计算机130。

客户端计算机130具有接口装置131、存储装置132以及与它们连接的处理器133。

接口装置131与通信网络19连接。

存储装置132存储客户端程序134和客户端管理数据135。客户端管理数据135是在客户端计算机130中管理的数据。

处理器133执行客户端程序134。使处理器133执行客户端程序134，由此实现作为请求发布部的一例的功能。该功能的一部分可以通过FPGA或ASIC那样的硬件电路来实现。

节点系统1300包括一个或多个服务器计算机150(节点计算机的一例)。

服务器计算机150具有接口装置151、存储装置152以及与它们连接的处理器153。

接口装置151与通信网络19连接。

存储装置152存储服务器程序154和服务器管理数据155。服务器管理数据155是在服务器计算机150中管理的数据。

处理器153执行服务器程序154。使处理器153执行服务器程序154，由此实现作为请求执行部的一例的功能。该功能的一部分可以通过FPGA或ASIC那样的硬件电路来实现。

中间系统80具备一个以上的中间计算机45(例如冗余化后的计算机)。

中间计算机45具有接口装置451、存储装置452以及与它们连接的处理器453。

接口装置451与通信网络19连接。

存储装置452存储排序程序454和排序管理数据455。排序管理数据455是在中间计算机45中管理的数据。

处理器453执行排序程序454。使处理器453执行排序程序454，由此实现作为排序管理部的一例的功能。该功能的一部分可以通过FPGA或ASIC那样的硬件电路来实现。排序程序454在排序系统中蓄积来自客户端系统13的状态更新请求。

中间系统80的管理主体优选为与任何节点系统1300的管理主体都不同的管理主体，但不限于此。例如，某个节点系统1300中的某个服务器计算机150也可以兼用作中间计算机45。

图3表示服务器管理数据155的一例。

服务器管理数据155是执行管理表33、锁定表44和资产集800。

执行管理表33是表示被执行的状态更新请求的表(例如，被执行的状态更新请求所具有的nonce的列表)。

锁定表44是用于判定能否获取锁定的表，是表示针对哪个状态更新请求以及哪个对象已获取锁定的表。

资产集800是资产的集合。

图4表示资产集800的一例。

资产集800针对每个对象具有资产810。根据对象的key来确定该对象的资产810。对于各对象，资产810可以相当于账本。

对于各对象，资产810是记录的时间序列。资产810中的记录可以称为“资产记录”。资产810至少具有末端资产记录。资产记录具有key701、age702、input703、output704、BL705、Arg706、nonce707、Sig708、Prev-HV709和HV710这样的信息。以下，以一个对象和一个资产记录为例(在图4的说明中为“关注对象”和“关注资产记录”)。

key701是关注对象的ID。age702表示关注对象的状态的世代。每次更新关注对象的状态时，追加具有递增后的age702的末端资产记录。在本实施例中，世代新是指age702大。

input703表示包含关注对象的一个以上的对象各自的上一状态(在应用关注资产记录内的BL705之前的状态)。output704表示关注对象的下一状态(应用关注资产记录内的BL705之后的状态)。例如，在成为追加关注资产记录的状态更新处理是从账户A(关注对象的一例)到账户B的转账的情况下，input703表示账户A和账户B各自的上一余额。output704表示账户A的下一余额。

BL705是用于确定状态更新处理的处理逻辑(例如函数)的逻辑信息。逻辑信息在本实施例中是处理逻辑本身，但也可以取而代之，是处理逻辑的ID。

Arg706是作为在该处理逻辑中使用的一个以上的自变量的自变量信息。

XXX_i是第i个XXX。output_i可以表示为output_i＝BL_i(input_i，Arg_i)。即，output_i是作为使用input_i和Arg_i执行BL_i而得的结果的状态。此外，input703实现对象间(资产810间)的记录连锁(参照图4的单点划线箭头)。

nonce707是与关注对象的最新状态(output704)对应的nonce。具体而言，nonce707是与获得该最新状态的状态更新处理的状态更新请求相关联的nonce。

Sig708是使用发布了获得关注对象的最新状态(output704)的状态更新请求的用户的密钥而生成的电子签名。在本实施例中，根据BL705、Arg706和nonce707来生成Sig708。此外，基于BL705生成的电子签名、基于Arg706生成的电子签名和基于nonce707生成的电子签名可以分别存在。

Prev-HV709是与关注对象的上一状态(上一世代)的资产记录(即，父资产记录)的HV710相同的值。即，Prev-HV709与父资产记录内的HV710之间的链接(参见图4中的实线箭头)实现了与对象对应的资产810内的记录连锁。

HV710是关注对象的资产记录的概要，例如是HV710以外的信息的至少一部分信息(在本实施例中为全部的信息701～709)的散列值(密码学上难以冲突的散列值)。

如上所述，在资产集800中，在同一资产810的资产记录中的Prev-HV709和HV710之间实现了记录连锁(参见实线箭头)。有时在不同资产810的资产记录中的input703之间也实现记录连锁。这样，资产集800形成DAG(Directed Acyclic Graph：有向无环图)结构。在资产集800中，节点是资产记录，并且边缘表示一个以上的状态更新处理中的资产记录之间的关系。

对于各对象，资产810是该对象的状态的更新历史的一例。资产记录的模式没有限定。例如，在资产记录中，一部分的要素(例如，BL705、Sig708)可以不存在。

服务器程序154可以管理最新资产记录集88，来附加至或代替资产集800。最新资产记录集88针对每个对象具有最新资产记录(仅末端资产记录)。即，对于各对象，只要管理最新的状态即可，也可以不管理过去的状态。

图5表示状态更新请求的构成的概要。

状态更新请求由客户端程序134发布。例如，客户端程序134生成包括从用户程序124(例如，应用程序)接收到的信息(例如，包括包含对象key的一个以上的自变量的信息)的状态更新请求，并且发布所生成的状态更新请求。

状态更新请求包括nonce61、自变量组62和处理内容63。

自变量组62包含一个以上的自变量。自变量组62中的各自变量与自变量key(例如“account.from”、“account.to”和“money”)相关联。根据图5的例子，自变量key是自变量的标签，在自变量组62中明示地表示，但是自变量key也可以隐含地表示。例如，自变量key可以是从自变量组62的开头起的偏移。

处理内容63是表示使用了该自变量组62的状态更新处理的内容的记述即处理记述(或者向该处理记述的链接)。在处理记述中，关于状态更新处理中使用自变量的处理，定义了该自变量的自变量key。在状态更新处理的执行中，使用与自变量key对应的自变量。

自变量组62中包含表示被指定的对象的自变量。在本实施例中，如果由执行前的状态更新请求指定的对象key与由执行中的状态更新请求指定的对象key竞争，则这些状态更新请求竞争。在各节点系统1300中，如果并行执行竞争的两个以上的状态更新请求，并且节点系统1300中的两个以上的状态更新请求的执行顺序不同，则同一对象的最新资产记录在节点系统1300间有可能会变得不相同。因此，竞争的两个以上的状态更新请求必须在各节点系统1300中以决定性的顺序执行。作为用于此目的的一种方法，存在判定由状态更新请求指定的对象key是否与由执行中的状态更新请求指定的对象key竞争的方法。

但是，在自变量组62中没有表示哪个自变量key是对象key。因此，如果不尝试执行状态更新请求，则无法确定哪个自变量key是对象key。

因此，在本实施例中，对状态更新请求附加上下文70。上下文70是用于竞争判定的信息，是用于确定一个以上的对象key的记述。具体而言，例如，上下文70是对一个以上的对象key的直接或间接的参照。根据图5所示的例子，上下文70是对一个以上的对象key的间接的参照。具体而言，上下文70是用于通过自变量组62来确定一个以上的对象key的记述，更具体而言，是表示与自变量组62中的哪个自变量key对应的自变量是对象key的信息。从图5所示的上下文70可知，“account.from”和“account.to”是与对象key对应的自变量key，从自变量组62可知，与自变量key“account.from”对应的自变量“k1”和与自变量key“account.to”对应的自变量“k2”分别是对象key。可以进行判定从状态更新请求以这种方式确定的对象key是否与由执行中的状态更新请求指定的对象key竞争的竞争判定。

此外，如上所述，上下文70也可以是对一个以上的对象key的直接的参照。例如，上下文70可以是直接表示“k1”和“k2”分别是对象key的记述(例如，“key＝[k1，k2]”这样的记述)。根据这样的记述，不参照上下文70以外的记述(例如自变量组62)，就能够确定一个以上的对象key。

图6表示实施例1的概要。此外，在图6中，“Rx”(x是自然数)中的“R”表示状态更新请求，“x”表示状态更新请求的编号(例如，相当于nonce)。另外，在图6中，“ky”(y是自然数)表示基于对象key确定的值是y(y是自然数)的对象key。

排序程序454从客户端系统13(客户端程序134)接收状态更新请求，并将接收到的状态更新请求放入到排序系统4211中。每当接收到状态更新请求时，可以将该状态更新请求放入到排序系统4211中，也可以每当经过一定时间或接收到一定数量的状态更新请求时，按照遵循规定的规则的顺序将接收到的一个以上的状态更新请求放入到排序系统4211中。

存在作为接受从排序系统4211发出的状态更新请求的功能的请求接收部、以及作为对请求接收部接受到的状态更新请求是否与执行中的状态更新请求竞争进行判定的功能的竞争判定部。至少一个计算机系统具备请求接收部和竞争判定部。在本实施例中，请求接收部和竞争判定部都设置在各节点系统1300中，但请求接收部和竞争判定部的至少一个也可以设置在节点系统1300以外的计算机系统中。例如，在介于中间系统80和服务器系统15之间的计算机系统(未图示)中，可以具备一个或多个请求接收部(例如，每个节点系统1300的一个以上的请求接收部)，也可以具备一个或多个竞争判定部(例如，每个节点系统1300的一个以上的竞争判定部)。

在各节点系统1300中，执行获取线程30。获取线程30从排序系统4211获取状态更新请求，并针对该状态更新请求执行上述的竞争判定。在本实施例中，获取线程30相当于请求接收部以及竞争判定部。在本实施例中，在各节点系统1300中，预先准备一个获取线程30。但是，在各节点系统1300中，也可以预先准备两个以上的获取线程30，也可以动态地生成获取线程30。请求接收部和竞争判定部也可以通过不同的线程来实现。请求接收部以及竞争判定部也可以是进程来代替线程，也可以是节点系统1300内的服务器计算机150，还可以是节点系统1300以外的系统中的要素(例如线程、进程或计算机)。

在各节点系统1300中，获取线程30接受从排序系统4211出去的状态更新请求。状态更新请求通过获取线程30的拉取(pull)和排序程序454的推送(push)中的某一个而从排序系统4211到达获取线程30。在本实施例中，采用拉取。即，获取线程30从排序系统4211获取状态更新请求。此外，从排序系统4211到节点系统1300的状态更新请求的发送可以是at-least-once递送的发送。对于进入排序系统中的一个状态更新请求，“at-least-once递送的发送”是指该一个状态更新请求至少被取出一次。

在各节点系统1300中，获取线程30判定获取到的状态更新请求是否与在节点系统1300中执行中的状态更新请求竞争。具体而言，获取线程30从获取到的状态更新请求的上下文70中确定一个以上的对象key，并且以决定性的顺序锁定确定出的一个以上的对象key。由此，能够避免对象key的死锁。此外，在本实施例中，锁定对象key是指将状态更新请求的编号(例如nonce)和由该状态更新请求指定的对象key登记在锁定表44中(对象key是密钥)。“决定性的顺序”是指在所有节点系统1300中共同的规定的顺序，例如可以是对象key的开头符号从小到大的顺序。

如果至少一个对象key未被锁定(例如，如果至少一个对象key已被登记在锁定表44中)，则意味着存在与执行中的状态更新请求的竞争。在该情况下，获取线程30等待被锁定的对象key解锁(例如，对象key从锁定表44删除)。

如果全部的对象key都被锁定，则没有与执行中的状态更新请求的竞争。在该情况下，获取线程30生成其他线程(以下称为委托线程)。获取线程30不等待该委托线程的处理而获取下一个状态更新请求。生成的委托线程对服务器程序154委托状态更新请求的执行。服务器程序154构成为能够并行执行多个状态更新请求。服务器程序154在接收到状态更新请求的执行委托的情况下，与执行中的状态更新请求的有无无关(换言之，即使有执行中的一个以上的状态更新请求)地执行被委托执行的状态更新请求。在状态更新请求的执行完成了的情况下，服务器程序154将完成响应(表示状态更新请求的执行完成的响应)返回到执行完成的状态更新请求的发布源。委托线程将在该完成的状态更新请求中锁定的所有对象key解锁。

在执行状态更新请求时，服务器程序154针对每个指定的对象key将资产记录追加到资产810中。在代替资产集800而采用最新资产记录集88(参照图4)的情况下，服务器程序154针对每个指定的对象key，更新与该对象key对应的资产记录。

在中间系统80中，排序管理数据455包括排序表44。在排序表44中，针对每个节点系统1300登记提交偏移。

对于各节点系统1300，提交偏移表示在该节点系统1300中执行完成了的状态更新请求的位置。在该节点系统1300中状态更新请求的执行完成了的情况下，排序程序454从该节点系统1300接受该状态更新请求的获取完成。在接收到该获取完成的情况下，对于该节点系统1300，排序程序454将表示提交偏移的信息登记在排序表144中。

在中间系统80具有多个中间计算机450的情况下，中间系统80具有一个逻辑排序系统(配置于多个中间计算机450中的每一个中的排序系统的复制)，该逻辑排序系统具有顺序一致性以上的一致性。在任一中间计算机450的排序系统的状态被更新的情况下，状态更新后的排序系统被反映到其他的全部排序系统，作为结果，多个排序系统的状态变得相同。

以下，参照图7说明在实施例1中进行的处理的详细情况。此外，在参照图7的说明中，以节点系统1300A为例。另外，在以下的说明中，上下文70通过客户端程序134进行附加。

图7是表示从状态更新请求的生成到执行完成为止的实施例1中的流程的流程图。

在S701中，客户端程序134从用户程序124接受一个以上的对象key，并生成状态更新请求。所生成的状态更新请求包括由客户端程序134附加的上下文70。上下文70包括用于确定由用户程序124指定的对象key的记述。

在S702中，客户端程序134发布该状态更新请求。

在S711中，排序程序454接收该发布的状态更新请求。在S712中，排序程序454将该接收到的状态更新请求放入排序系统4211中。

在S720中，节点系统1300A中的获取线程30A从排序系统4211获取状态更新请求。具体而言，获取线程30A将获取请求发送到中间系统80。排序程序454响应于来自获取线程30A的获取请求，将排序系统4211中的输出对象的状态更新请求(处于与节点系统1300A对应的提交偏移所表示的位置的下一位置的状态更新请求)输出到该获取线程30A。

在S721中，获取线程30A参照执行管理表33，判定获取到的状态更新请求是否已执行。如果在执行管理表33中未登记与获取到的状态更新请求内的nonce相同的nonce，则该状态更新请求未执行。

在S721的判定结果是假的情况下(S721：否)，在S722中，获取线程30A根据获取到的状态更新请求的上下文70确定被指定的一个以上的对象key，将一个以上的对象key按决定性的顺序排列，按该顺序锁定对象key。

在S723中，获取线程30A判定是否锁定了全部的对象key。在至少一个对象key未被锁定的情况下(S723：否)，获取线程30A等待未锁定的对象key的解锁，并且当该对象key被解锁时，锁定被解锁的对象key(S722)。

在全部的对象key被锁定的情况下(S723：是)，在S724中，获取线程30A生成委托线程。之后，获取线程30A成为能够获取状态更新请求的状态。此外，也可以预先准备多个委托线程。

在S731中，所生成的委托线程向服务器程序154A委托锁定了全部对象key的状态更新请求的执行。服务器程序154A响应于该委托来执行状态更新请求。在执行该状态更新请求时，服务器程序154A原子地进行针对每个锁定的对象key的资产810的更新(例如，资产记录的追加)，以及将该状态更新请求的编号(例如，nonce)例如作为主密钥写入执行管理表33的操作。在状态更新请求的执行完成了的情况下，服务器程序154A将该状态更新请求的完成响应返回给该状态更新请求的发布源。

在S732中，委托线程解锁在S722中锁定的全部的对象key。

在S733中，委托线程进行提交，具体而言，对中间系统80通知该状态更新请求的完成。排序程序454接收该通知，针对节点系统1300A更新排序表44。具体而言，排序程序454将表示该状态更新请求的位置的偏移作为提交偏移。

根据实施例1，对状态更新请求附加用于确定一个以上的对象key的记述即上下文70。在各节点系统1300中，获取线程30根据上下文70确定由状态更新请求指定的对象key，并且判定确定出的对象key是否与由执行中的状态更新请求指定的对象key竞争。如果没有竞争，则获取线程30生成委托线程，成为能够获取状态更新请求的状态。即，每当获取线程30获取状态更新请求并且针对该状态更新请求判定为没有竞争时，生成委托线程。所生成的委托线程对服务器程序154委托状态更新请求的执行。服务器程序154在接收到该委托的情况下，即使有执行中的状态更新请求，也执行被委托执行的状态更新请求。这样，在各节点系统1300中能够并行执行没有竞争的两个以上的状态更新请求，作为结果，能够确保在多个节点系统1300中得到相同的资产记录，并且能够提高各节点系统1300的利用效率。

实施例2

说明实施例2。此时，主要说明与实施例1的不同点，对与实施例1的共同点简述或省略说明。

图8表示实施例2的概要。

排序系统4211由多个分区4311构成。在排序表44中，例如针对每个分区4311登记有分区ID和分区位置。另外，在排序表44中，针对每个分区4311登记提交偏移。此外，尽管针对每个分区4311确保了全序性(トータルオーダ性)，但是不确保多个分区4311之间的全序性。例如，即使第一状态更新请求被放入分区4311-1中，然后第二状态更新请求被放入分区4311-2中，第一状态更新请求也不一定在第二状态更新请求之前离开分区4311-1。

以下，为了方便，将根据对象key确定的值称为“key值”，将key值为N(N是自然数)的对象key表示为“keyN”。一个分区4311对应于一个对象key。对象key与分区4311可以1：1对应，连续的key值的范围(例如，N＝1～10、N＝11～20)与分区可以1：1对应，离散的key值的范围(例如，N＝奇数、N＝偶数)与分区也可以1：1对应。例如，可以根据使用key值计算出的值(例如，通过将key值除以分区4311的数目而获得的余数)来唯一地确定分区4311。根据图8的例子，将key值除以3(分区数)时的余数为1的对象key(k1、k4、k7、…)对应于分区4311-1，将key值除以3时的余数为2的对象key(k2、k5、k8、…)与分区4311-2对应，将key值除以3时的余数为0的对象key(k3、k6、k9、…)对应于分区4311-3。在由状态更新请求指定了多个对象key的情况下，该状态更新请求有时被放入在一个分区4311中，有时也被放入在多个分区4311中。在由状态更新请求指定了多个对象key的情况下，排序程序454针对每个对象key复制该状态更新请求，并将复制后的状态更新请求放入与该对象key对应的分区4311中。但是，在两个以上的对象key对应于同一分区4311的情况下，排序程序454将一个状态更新请求放入与该两个以上的对象key对应的一个分区4311中。具体而言，例如在由状态更新请求指定的对象key是k1和k4的情况下，k1和k4都与分区4311-1对应，因此该状态更新请求的输入目的地是一个分区4311-1。另外，例如在由状态更新请求指定的对象key是k1和k2的情况下，k1对应于分区4311-1，k2对应于分区4311-2，因此，该状态更新请求的输入目的地是两个分区4311-1和4311-2。

在由状态更新请求指定了多个对象key的情况下，排序程序454以决定性的顺序锁定该多个对象key，然后将该状态更新请求放入与该多个对象key对应的一个以上的分区4311中。例如，排序程序454以决定性的顺序锁定k1和k2，然后将指定了k1和k2的状态更新请求放入分区4311-1和4311-2中。通过这样的处理，可以避免具有竞争的两个以上的状态更新请求(例如，R1和R3)的顺序在分区4311之间不同，换言之，可以将具有竞争的两个以上的状态更新请求的顺序保持为决定性的顺序。此外，在本实施例中，锁定对象key是指在排序管理数据455内的锁定表46中登记状态更新请求的编号(例如nonce)和对象key(对象key是密钥)。

在各节点系统1300中，获取线程30从一部分的分区4311(一个以上的分区4311)获取状态更新请求。根据图8的例子，对于各节点系统1300，分区4311和获取线程301：1对应。具体而言，获取线程30-1对应于分区4311-1，获取线程30-2对应于分区4311-2，获取线程30-3对应于分区4311-3。各获取线程30从与该获取线程30对应的分区4311获取状态更新请求。在各获取线程30根据获取到的状态更新请求获取了两个以上的对象key，并且该两个以上的对象key对应于两个以上的分区4311的情况下，在锁定该两个以上的对象key之后执行该状态更新请求。与两个以上的分区4311对应的两个以上的对象key可以由与该两个以上的分区4311对应的两个以上的获取线程30锁定，也可以由该两个以上的获取线程30中的任一个的获取线程30以决定性的顺序锁定。前者的一例为下述(X)，后者的一例为下述(Y)。在本实施例中采用(X)。

(X)获取线程30锁定两个以上的对象key中的与对应于获取线程30的分区4311对应的一个以上的对象key。获取线程30在由状态更新请求指定的两个以上的对象key全部被锁定的情况下，对服务器程序154委托该状态更新请求的执行。例如，在获取线程30-1A从分区4311-1获取到R1(k1，k2)的情况下，锁定与分区4311-1对应的k1。但是，由于k2尚未被锁定，所以获取线程30-1A不对服务器程序154委托R1(k1，k2)的执行。之后，在获取线程30-2A从分区4311-2获取了R1(k1，k2)的情况下，锁定与分区4311-2对应的k2。作为结果，k1和k2全部被锁定，因此获取线程30-2A对服务器程序154A委托R1(k1，k2)的执行。在R1(k1，k2)的执行完成了的情况下，获取线程30-1A和30-2A中的至少一个将k1和k2解锁。

(Y)获取线程30以决定性的顺序锁定由获取到的状态更新请求指定的两个以上的对象key。获取线程30在锁定了该两个以上的对象key的全部的情况下，对服务器程序154委托该状态更新请求的执行。例如，在获取线程30-1A从分区4311-1获取了R1(k1，k2)的情况下，以决定性的顺序锁定k1和k2，并对服务器程序154A委托R1(k1，k2)的执行。之后，在获取线程30-2A从分区4311-2获取了R1(k1，k2)的情况下，虽然要锁定k1和k2，但由于k1和k2已锁定，所以变成等待。在R1(k1，k2)的执行完成了的情况下，获取线程30-1A解锁k1和k2。因此，获取线程30-2A以决定性的顺序锁定k1和k2，并对服务器程序154A委托R1(k1，k2)的执行，但是服务器程序154A根据执行管理表33确定R1(k1，k2)的执行已完成，因此跳过R1(k1，k2)的执行。

图9是表示从状态更新请求的生成到执行完成为止的实施例2中的流程的流程图。此外，在参照图9的说明中，作为节点系统1300，以节点系统1300A为例。

S901与S701相同。S902与S702相同。S911与S711相同。

在S912中，排序程序454判定是否满足条件A。条件A是由状态更新请求指定的对象key是一个，或者由该状态更新请求指定的两个以上的key全部对应于同一分区。此外，从该状态更新请求的上下文70确定由状态更新请求指定的对象key。在S912的判定结果是真的情况下(S912：是)，由于不需要锁定对象key，所以跳过S913～S915，。

在S912的判定结果是假的情况下(S912：否)，在S913中，排序程序454将由状态更新请求指定的两个以上的key排序为决定性的顺序。在S914中，排序程序454以对象key的排列顺序(即，决定性的顺序)锁定该两个以上的对象key。在S915中，排序程序454判定是否锁定了该两个以上的对象key的全部。

在S912的判定结果是真的情况下(S912：是)，或者在S915的判定结果是真(S915：是)的情况下，在S916中，排序程序454针对由状态更新请求指定的一个以上的对象key的每一个，确定与该对象key对应的分区4311。例如，排序程序454针对每个对象key，根据将对象key的key值除以分区数而获得的余数来确定分区4311。由此，针对一个以上的对象key确定一个以上的分区4311。

在S917中，排序程序454将状态更新请求放入各个确定出的一个以上的分区4311中。

如果针对该状态更新请求存在被锁定的两个以上的对象key，则在S918中，排序程序454解锁该两个以上的对象key。

在S920中，获取线程30-1A从分区4311-1获取状态更新请求。具体而言，获取线程30-1A向中间系统80发送指定了分区4311-1的分区ID的获取请求。排序程序454将与由来自获取线程30-1A的获取请求指定的分区ID对应的分区4311-1中的输出对象的状态更新请求输出到获取线程30-1A。

在S921中，服务器程序154A(或获取线程30-1A)参照执行管理表33，判定获取到的状态更新请求是否已执行。

在S921的判定结果是假的情况下(S921：否)，在S922中，获取线程30-1A判定是否满足条件B。条件B是由状态更新请求指定的对象key是一个，或者由该状态更新请求指定的两个以上的key全部对应于同一分区。此外，从该状态更新请求的上下文70确定由状态更新请求指定的对象key。在S922的判定结果是真的情况下(S922：是)，由于不需要锁定对象key，所以跳过S923和S924。

在S923中，获取线程30-1A锁定由状态更新请求指定的两个以上的对象key中的与分区4311-1对应的一个以上的对象key。在S924中，获取线程30-1A参照锁定表40A，判定是否锁定了全部的对象key。

在锁定了全部的对象key的情况下(S923：是)，在S925中，获取线程30-1A对服务器程序154A委托状态更新请求的执行，并且服务器程序154A执行该状态更新请求。在针对所执行的状态更新请求锁定了两个以上的对象key的情况下，在S927中，获取线程30-1A解锁该两个以上的对象key。

在有未被锁定的对象key的情况下(S923：否)，在S926中，获取线程30-1A等待全部的对象key被锁定并且执行状态更新请求。换言之，除非执行该状态更新请求，否则获取线程30-1A不从分区4311-1获取下一个状态更新请求。在此情况下，在从一个以上的其他分区4311读取相同的状态更新请求并且锁定全部的对象key的情况下，执行状态更新请求。例如，假设获取线程30-2A进行S921～S923并且全部的对象key被锁定(S924：是)。因此，获取线程30-2A对服务器程序154A委托状态更新请求的执行。在针对所执行的状态更新请求锁定了两个以上的对象key的情况下，在S927中，获取线程30-2A解锁该两个以上的对象key。获取线程30-1A检测到在S923中锁定的对象key的解锁，结束等待。在S928中，获取线程30-2A向中间系统80通知该状态更新请求的完成。排序程序454接收该通知，针对节点系统1300A更新排序表44(具体而言，排序程序454将表示该状态更新请求的位置的偏移作为提交偏移)。

根据实施例2，排序系统4211被分割为多个分区4311，并且多个状态更新请求被分发到多个分区4311。而且，在各节点系统1300中，从多个分区4311通过不同的多个获取线程30并行地获取多个状态更新请求，该多个状态更新请求由服务器程序154并行执行。因此，在各节点系统1300中，能够实现比实施例1高的并行度，因此，节点系统1300的利用效率相比于实施例1提高。

此外，在实施例2中，根据图9的例子，排序程序454在S912的判定结果为假的情况下，在锁定对象key之后确定与该对象key对应的分区4311，但也可以在确定与对象key对应的分区4311之后锁定对象key。即，如果在将状态更新请求放入分区4311之前锁定对象key，则分区4311的确定和对象key的锁定哪一个先进行都可以。

另外，在实施例2中，获取线程30也可以代替进行图9的S925、S927以及S928，而如实施例1那样，在每当获取状态更新请求并针对该状态更新请求判定为没有竞争时，生成委托线程。委托线程也可以进行图9的S925、S927以及S928。

另外，在实施例1和实施例2中，“状态更新请求的执行”可以包括状态更新处理的执行和篡改检测处理的执行，也可以包括状态更新处理的执行而不包括篡改检测处理的执行(即，如实施例3和实施例4中所述，状态更新处理的执行和篡改检测处理的执行可以分开)。这里提到的“篡改检测处理”可以包括针对相同的状态更新请求判定两个以上的节点系统1300之间的资产记录(例如，最新资产记录(末端资产记录))或其HV是否相同的处理。另外，“篡改检测处理”例如可以包括服务器程序154A使用比该资产记录更早的资产记录来验证与由状态更新请求指定的对象key对应的资产记录(例如，最新资产记录)的HV的处理。

另外，在实施例1和实施例2的至少一个中，也可以代替中间系统80而由各客户端系统13的客户端程序134具有排序程序454的功能。

另外，在实施例1和实施例2的至少一个中，也可以代替能够并行执行多个状态更新请求的服务器程序154，而存在多个用于执行状态更新请求的线程(以下称为执行线程)，多个执行线程并行执行多个状态更新请求。多个执行线程可以预先准备，也可以动态地生成。

另外，在实施例1和实施例2中，上下文附加部包含在客户端程序134(请求发布部的一例)中。由于客户端程序134从用户程序124接收一个以上的对象key的指定，所以可以在不临时执行状态更新请求的情况下将上下文70附加到状态更新请求中。在实施例1和实施例2的至少一个中，上下文附加部可以是不包含在客户端程序134中的功能。在这种情况下，上下文附加部可以通过状态更新请求的临时执行，来确定由该状态更新请求指定的一个以上的对象key，生成用于确定所确定的一个以上的对象key的记述即上下文70，将所生成的上下文70附加到该状态更新请求中。上下文附加部可以设置在客户端系统13(第一计算机系统的一例)、中间系统80、服务器系统15(第二计算机系统的一例)以及这些系统13、80和15以外的系统中。即，在实施例1和实施例2中，可以在执行状态更新请求前的任何阶段附加上下文70。具体而言，在实施例1中，对状态更新请求附加上下文70可以在该状态更新请求进入队列之前或该状态更新请求离开队列之后进行。在实施例2中，对状态更新请求附加上下文70在该状态更新请求进入分区之前进行即可。作为附加上下文70的方法，可以采用下述方法中的任一个。

·在实施例1和实施例2的至少一个中，客户端程序134可以从用户程序124接收一个以上的对象key的指定，将上下文70附加在客户端程序134发送的状态更新请求中。

·在实施例1和实施例2的至少一个中，排序程序454可以在状态更新请求进入排序系统4211时，或者在状态更新请求离开排序系统4211时，通过临时执行该状态更新请求来确定一个以上的对象key，在状态更新请求中附加用于确定所确定的一个以上的对象key的记述即上下文70。

·在实施例1中，获取线程30可以通过临时执行从排序系统4211发出的状态更新请求来确定一个以上的对象key，在状态更新请求中附加用于确定所确定的一个以上的对象key的记述即上下文70，将附加了上下文70的状态更新请求传送给服务器程序154。

·在实施例1和实施例2的至少一个中，节点系统1300(例如，获取线程30)可以通过临时执行来自客户端程序134的状态更新请求来确定一个以上的对象key，在状态更新请求中附加用于确定所确定的一个以上的对象key的记述即上下文70，并向客户端程序134发送附加了上下文70的状态更新请求。客户端程序134可以将该状态更新请求发送到排序程序454。

实施例1和实施例2例如可以总结如下。

数据管理系统具备一个或多个上下文附加部和一个或多个竞争判定部。在一个或多个第一计算机系统中具备一个或多个请求发布部。在与一个或多个第一计算机系统通信的第二计算机系统中的多个节点系统中，具备多个请求执行部。第一计算机系统中的请求发布部发布状态更新请求。该状态更新请求被放入到排序系统中。状态更新请求包括：包含一个以上的自变量的自变量组；以及表示使用该自变量组的状态更新处理的内容的记述或向该记述的链接即处理内容。状态更新处理是针对一个以上的对象的每一个，更新表示该对象的状态的数据即客体的处理。排序系统是由一个或多个分区构成，并确保每个分区的全序性的系统。上下文附加部对状态更新请求附加用于确定一个以上的对象的记述即上下文。关于每个节点系统，每当从所述排序系统发出状态更新请求时，竞争判定部从该状态更新请求的上下文确定一个以上的对象，进行该确定出的一个以上的对象是否与由在该节点系统中执行中的一个以上的状态更新请求指定的一个以上的对象竞争的竞争判定。在该竞争判定的结果是没有竞争这一结果的情况下，该节点系统中的请求执行部执行该状态更新请求。

对于从所述排序系统发出的状态更新请求，竞争判定部可以锁定从状态更新请求的上下文确定出的一个以上的对象。在该一个以上的对象全部被锁定的情况下，所述竞争判定的结果可以是没有竞争这一结果。

在所述排序系统由所述多个分区构成的情况下(以下，是多分区的情形)，各状态更新请求可以被放入与从该状态更新请求的上下文确定出的一个以上的对象相对应的一个以上的分区中。各竞争判定部可以根据从与该竞争判定部对应的分区发出的状态更新请求的上下文，确定一个以上的对象。

在多分区的情形中，对于从分区发出的状态更新请求，在所确定的对象为两个以上、且该两个以上的对象与包含该分区的两个以上的分区对应的情况下，与该分区对应的竞争判定部可以锁定该两个以上的对象中的至少与该分区对应的对象。在该两个以上的对象全部被锁定的情况下，所述竞争判定的结果可以是没有竞争这一结果。

在多分区的情形中，对于从分区发出的状态更新请求，在所确定的对象是一个、或者所确定的两个以上的对象全部对应于一个分区的情况下，可以不对该状态更新请求进行所述竞争判定地执行该状态更新请求。

在多分区的情形中，所述一个或多个请求发布部的每一个或者具有所述排序系统的计算机系统所具备的排序管理部可以进行如下动作。

·从状态更新请求的上下文确定一个以上的对象。

·在确定出的对象有两个以上，且该两个以上的对象对应于两个以上的分区的情况下，以决定性的顺序锁定该两个以上的对象。

·在该两个以上的对象全部被锁定的情况下，将该状态更新请求分别放入该两个以上的分区。

·将该两个以上的对象全部解锁。

在多分区的情形中，所述一个或多个请求发布部的每一个或者具有所述排序系统的计算机系统所具备的排序管理部可以进行如下动作。

·从状态更新请求的上下文确定一个以上的对象。

·在确定出的对象是一个，或者确定出的两个以上的对象全部对应于一个分区的情况下，不锁定确定出的一个以上的对象地将该状态更新请求放入该分区中。

所述一个或多个请求发布部可以包括所述一个或多个上下文附加部。

所述上下文附加部可以通过状态更新请求的临时执行，来确定由该状态更新请求指定的一个以上的对象。所述上下文附加部可以生成用于确定所确定的一个以上的对象的记述即上下文，并将该生成的上下文附加到该状态更新请求中。

实施例3

以下说明实施例3。此时，主要说明与实施例1和实施例2的不同点，对与实施例1和实施例2的共同点简述或省略说明。

图10表示实施例3的系统整体的构成的一例。

在服务器系统15中，节点系统1300的处理速度(例如，构成和性能)可以不同。例如，节点系统1300A由与通信网络1400A连接的四个服务器计算机150Aa、150Ab、150Ac和150Ad构成。节点系统1300B由与通信网络1400B连接的两个服务器计算机150Ba和150Bb构成。在图10中例示的所有服务器计算机150的处理速度相同的情况下，节点系统1300B的处理速度比节点系统1300A的处理速度低。这样，多个节点系统1300的处理速度可以不同。此外，在图10的例子中，各通信网络1400与通信网络19连接，但至少一个通信网络1400也可以与通信网络19一体化。

这样，各个节点系统1300可以不考虑与该节点系统1300不同的节点系统1300的处理速度而构成。

根据应用了BFT(Byzantine Fault Tolerance：拜占庭容错)共识算法或与其类似的区块链等结构的一般的数据管理系统，服务器系统中的多个节点系统分别针对每个对象管理客体(表示对象的状态的数据)。每当服务器系统从客户端系统接收到状态更新请求时，各节点系统执行检测客体的篡改的有无的篡改检测处理。在各节点系统中，“篡改检测处理”包括以下两个处理中的至少一个：检测当前(在执行状态更新处理之前)的客体的篡改的有无的处理；以及检测通过状态更新处理执行到中途而获得的更新后的客体的篡改的有无的处理。在多个节点系统中执行同样的篡改检测处理。如果全部的节点系统的篡改检测处理的执行没有完成，则任何节点系统都不能执行状态更新处理。另外，即使某个节点系统先完成了状态更新处理的执行，如果在所有节点系统中该状态更新处理的执行没有完成，则对于与该状态更新请求相关联的下一个状态更新请求，任何节点系统都不能执行状态更新处理。因为并非所有节点系统都有更新后的客体，因此对于该下一个的状态更新请求，所有节点系统的篡改检测处理的执行都没有完成。因此，希望多个节点系统的处理速度相同。因为如果多个节点系统的处理速度不同，则需要等待处理速度相对较低的节点系统的处理结果，系统整体的利用效率降低。

另一方面，在实施例3中，如后面详细叙述的那样，状态更新处理的执行与比较两个以上的节点系统1300的资产记录或其概要的篡改检测处理的执行分离。具体而言，数据管理系统除了多个节点系统1300所具备的多个请求执行部之外，还具备一个或多个篡改检测执行部。篡改检测执行部执行篡改检测处理。在各节点系统1300中，请求执行部针对每个状态更新请求执行状态更新处理，并且在不执行篡改检测处理的情况下响应该状态更新请求的完成。因此，服务器系统15中的所有节点系统1300的处理速度不必相同。因此，可以提高服务器系统15的构成的灵活性，作为结果，可以高效率地提高可扩展性。

另外，由于状态更新处理的执行和篡改检测处理的执行是分开的，所以在各节点系统1300中独立地进行状态更新处理。如果从至少一个节点系统1300返回状态更新处理的完成响应，则客户端系统13可以发送相关联的下一个状态更新请求。针对该下一个状态更新请求，在各节点系统1300中独立地进行状态更新处理。因此，客户端系统13的状态更新请求的延迟时间很快。

在本实施例中，篡改检测执行部包含在客户端程序134中，但篡改检测执行部也可以是通过在客户端系统13中执行与客户端程序134不同的程序而实现的功能，也可以设置在客户端系统13以外的系统例如监察系统(承担监察任务的计算机系统)中。一部分客户端系统13、一部分节点系统1300或中间系统80中的至少一个可以兼用作监察系统。

图11表示实施例3的概要的一例。此外，在图11中，“Rx”(x是自然数)表示状态更新请求。

从客户端程序154发布的状态更新请求进入排序系统4211，并从排序系统4211发送到多个节点系统1300中的每一个。在各节点系统1300中，服务器程序154执行状态更新处理作为状态更新请求的执行(例如，将末端资产记录追加到被指定的对象的资产中)，并且在不执行篡改检测处理的情况下向客户端程序134响应该状态更新请求的完成。发布了状态更新请求的客户端程序154如果从至少一个节点系统1300接收到针对该请求的完成响应，则识别为状态的更新已完成。

如上所述，在本实施例中，状态更新请求的执行完成不需要执行比较两个以上的节点系统1300中的资产记录或其概要的篡改检测处理。因此，虽然状态更新请求被发送到所有的节点系统1300中，但更新完成请求(状态更新处理的执行完成了的状态更新请求)的数量在节点系统1300之间未必相同。在图11的例子中，在进入排序系统4211的R1～R5中，节点系统1300A中的更新完成请求是R1～R4，但节点系统1300B中的更新完成请求仅是R1和R2。

客户端程序134对一个或多个更新完成请求中的共同完成请求执行篡改检测处理。共同完成请求是多个节点系统1300中的两个以上的节点系统1300共同的更新完成请求。在图11的例子中，节点系统1300A和1300B中的共同完成请求是R1和R2。客户端程序134对至少一个共同完成请求执行篡改检测处理。

根据数据管理系统的应用的必要条件，在每当接收到状态更新请求时不必立即执行篡改检测处理，和/或不必对全部的状态更新请求执行篡改检测处理。例如，在对象为账户且对象的状态为余额的应用中，余额在存款和取款的任意一种情况下都发生变化，但根据该应用的必要条件，认为对于存款不需要执行余额的篡改检测处理，对于取款执行余额的篡改检测处理即可。在本实施例中，状态更新处理的执行和篡改检测处理的执行是分开的，因此，可以灵活地确定篡改检测处理的执行定时，和/或可以灵活地选择作为篡改检测处理的执行对象的共同完成请求。例如，篡改检测处理的执行频率可以低于状态更新请求的发布频率，或者对于每个对象，需要执行篡改检测处理的共同完成请求可以缩减为一个以上的共同完成请求中的一部分共同完成请求(例如，最新的共同完成请求)。

此外，篡改检测处理可以针对N个节点系统1300(N是2以上的整数，是构成服务器系统15的节点系统1300的数量)中的M个节点系统1300(M是2以上N以下的整数)来执行。即，也可以未必是M＝N。在以下的说明中，为了简化说明，设M＝N。

另外，在本实施例中，对于各对象，采用资产810(参见图4)作为基于执行指定了该对象的状态更新请求的状态历史的一例。

以下，参照图12～图13详细说明在实施例3中进行的处理。此外，以下，在实施例3的说明中，为了简化说明，构成服务器系统15的N个节点系统1300是节点系统1300A以及1300B。

图12是表示从状态更新请求的生成到执行完成为止的实施例3中的流程的流程图。

在S1201中，客户端程序134生成状态更新请求。该状态更新请求例如包括key、Sig、nonce等。可以向状态更新请求附加上下文70。在S1202中，客户端程序134发布该状态更新请求。

在S1211中，排序程序454接收该状态更新请求。在S1212中，排序程序454将该接收到的状态更新请求放入排序系统4211中。

以节点系统1300A为例，说明S1221以及S1222。在S1221A中，服务器程序154A从排序系统4211获取状态更新请求。在S1222A中，服务器程序154A执行该状态更新请求。具体而言，在S1222A中，服务器程序154A执行状态更新处理，但不执行篡改检测处理。S1222A也可以是实施例1的S721～S724以及S731～S733(参照图7)。另外，S1222A也可以是实施例2的S921～S928(参照图9)。

对于各节点系统1300A和1300B，每当状态更新请求完成时，针对状态更新请求的响应(例如，完成响应)被返回到客户端程序134。预先确定节点系统1300A和1300B中的哪一个是主节点系统，并且只有主节点系统可以将针对状态更新请求的响应返回给客户端程序134(主节点系统以外的节点系统即使在状态更新请求完成时，也不将针对状态更新请求的响应返回给客户端程序134)。以下，在图12的说明中，以一个状态更新请求为例(在图12的说明中是“关注状态更新请求”)。

在S1231中，客户端程序134接收该客户端程序134发布的关注状态更新请求的响应。

在S1232中，客户端程序134针对接收到的响应执行某些处理。例如，如果该接收到的响应是针对关注状态更新请求而首次接收到的响应，则客户端程序134根据该响应解释关注状态更新请求的结果。另一方面，如果该响应是在已经针对关注状态更新请求接收到响应之后而接收到的响应，则客户端程序134丢弃该接收到的响应。即，对于关注状态更新请求，最初接收到的响应被设为有效。此外，客户端程序134也可以不丢弃该接收到的响应，例如保存一定期间，并与来自其他节点系统1300的响应进行比较。

图13是篡改检测处理的执行的流程图。

在S1301中，客户端程序134生成age查询。在age查询中，指定至少一个对象key。以下，为了简化说明，假设在一个age查询中指定一个对象key(在图13的说明中为“关注key”)。age查询是关注key的最大age的查询。在S1302中，客户端程序134发送该age查询。age查询通过或不通过中间系统80而被发送到各节点系统1300A和1300B。

以节点系统1300A为例，说明S1311以及S1312。在S1311A中，节点系统1300A中的服务器程序154A接收age查询。在S1312A中，服务器程序154A例如可线性化地获取在该age查询中指定的关注key的最大age(关注key的末端资产记录内的age)，并且向age查询的发送源回答该最大age。此外，在S1312A之前，服务器程序154A也可以进行构成与关注key对应的资产810的各资产记录的篡改检测处理。

在S1321中，客户端程序134接收最大age。在S1322中，客户端程序134判定是否从各节点系统1300A和1300B接收到最大age。在S1322的判定结果为假的情况下(S1322：否)，客户端程序134等待从所有节点系统1300A和1300B接收最大age。

在S1322的判定结果为真的情况下(S1322：是)，在S1323中，客户端程序134确定接受到的最大age中最大的共同age(换言之，接受到的最大age的最小值)。例如，在来自节点系统1300A的最新age是“8”并且来自节点系统1300B的最新age是“6”的情况下，最大共同age是“6”。在S1324中，客户端程序134生成指定了上述关注key和在S1322中确定的最大共同age的记录查询。在S1325中，客户端程序134发送该记录查询。记录查询通过或不通过中间系统80而发送到各节点系统1300A和1300B。

以节点系统1300A为例，说明S1331～S1333。在S1331A中，节点系统1300A中的服务器程序154A接收记录查询。在S1332A中，服务器程序154A例如可线性化地获取具有在该记录查询中指定了的关注key和最大共同age的资产记录或其概要(例如，HV)。在S1333A中，服务器程序154A向记录查询的发送源回答该资产记录或其概要。

在S1341中，客户端程序134接收具有关注key和最大共同age的资产记录或其概要。在S1342中，客户端程序134判定是否从全部的节点系统1300A和1300B接收到具有关注key和最大共同age的资产记录或其概要。在S1342的判定结果为假的情况下(S1342：否)，客户端程序134等待从全部的节点系统1300A和1300B接收资产记录或其概要。

在S1342的判定结果为真的情况下(S1342：是)，在S1343中，客户端程序134判定接收到的全部的资产记录或其概要是否一致。在S1343的判定结果为真的情况下(S1343：是)，在S1344中，客户端程序134判定为没有篡改。在S1343的判定结果为假的情况下(S1343：否)，在S1345中，客户端程序134判定为有篡改。

以上是篡改检测处理的执行的说明。

在篡改检测处理的执行中，age查询的生成和发送的定时可以根据应用的必要条件或其他而灵活地设定。

另外，在篡改检测处理的执行中，检测篡改的有无的共同age也可以根据应用的必要条件或其他而灵活地设定。例如，检测有无篡改的一个以上的共同age可以仅是最大共同age，也可以是最大共同age和比最大共同age小(旧)的所有共同age，还可以是最大共同age和比最大共同age小的共同age中的任意一个以上的共同age。

实施例4

以下说明实施例4。此时，主要说明与实施例3的不同点，对与实施例3的共同点简述或省略说明。

在实施例3中，客户端程序134向各节点系统1300发送age查询，从各节点系统1300接受最大age的回答，并确定最大共同age。此后，客户端程序134向各节点系统1300发送指定了所确定的最大共同age的记录查询，并且从各节点系统1300接收最大共同age的资产记录或其概要。即，在客户端程序134与各节点系统1300之间进行2阶段的对话(やり取り)。

在实施例4中，客户端程序134与各节点系统1300之间的对话为1阶段。

图14是实施例4的篡改检测处理的执行的流程图。

在S1401中，客户端程序134生成记录查询。在由S1401生成的记录查询中，指定至少一个对象key。以下，为了简化说明，假设在一个记录查询中指定一个对象key(在图14的说明中为“关注key”)。在S1401中生成的记录查询是关注key的全部资产记录的查询。在S1402中，客户端程序134发送该记录查询。记录查询通过或不通过中间系统80而发送到各节点系统1300A和1300B。

以节点系统1300A为例，说明S1411以及S1412。在S1411A中，节点系统1300A中的服务器程序154A接收记录查询。在S1412A中，服务器程序154A例如可线性化地获取在该记录查询中指定的关注key的所有资产记录(资产810)，并向记录查询的发送源回答该所有资产记录(或与所有资产记录分别对应的所有资产记录代码和所有age(所有资产记录的age))。此外，在S1412A之前，服务器程序154A也可以进行构成与关注key对应的资产810的各资产记录的篡改检测处理。

在S1421中，客户端程序134从至少一个节点系统1300接收所有资产记录(或所有资产记录概要和所有age)。在S1422中，客户端程序134判定是否从节点系统1300A和1300B的全部接收到所有资产记录(或所有资产记录概要和所有age)。在S1422的判定结果为假的情况下(S1422：否)，客户端程序134等待从节点系统1300A和1300B的全部接收所有资产记录(或所有资产记录概要和所有age)。

在S1422的判定结果为真的情况下(S1422：是)，在S1423中，客户端程序134从节点系统1300A和1300B的所有资产记录(或所有资产记录概要和所有age)中确定最大的共同age，并确定包括所确定的最大共同age的共同资产记录即最新共同资产记录(或作为该共同资产记录的概要的最新共同资产记录概要)。“共同资产记录”是对应于共同完成请求(换言之，共同age)的资产记录(“共同资产记录概要”是共同资产记录的概要)。

在S1424中，客户端程序134判定所确定的最新共同资产记录(或最新共同资产记录概要)在节点系统1300A和1300B之间是否一致。在S1424的判定结果为真的情况下(S1424：是)，在S1425中，客户端程序134判定为没有篡改。对于S1424的判定结果为假(S1424：否)的资产记录，在S1426中，客户端程序134判定为有篡改。

以上是实施例4的篡改检测处理的一例。

此外，在图14的说明中，对于各节点系统1300，与关注key对应的“全部资产记录”未必是作为资产810自身的全部资产记录。例如，在由S1401生成的记录查询中，可以对关注key指定记录条件。“记录条件”例如可以是与资产记录的追加日期时间相关的条件。在这种情况下，“所有资产记录”可以是符合所指定的记录条件的所有资产记录。

另外，在S1423中，也可以代替最新共同资产记录(或最新共同资产记录概要)而确定所有共同资产记录(或所有共同资产记录概要)，也可以确定包括或除去最新共同资产记录的一部分的共同资产记录(或包括或除去最新共同资产记录概要的一部分的共同资产记录概要)。

另外，客户端程序134可以根据客户端系统130的通信状态和/或其他状况，来选择是执行实施例3的篡改检测处理还是执行实施例4的篡改检测处理。

实施例3和实施例4例如可以总结如下。

数据管理系统具备一个或多个篡改检测执行部以及与一个或多个第一计算机系统通信的第二计算机系统中的多个节点系统所具备的多个请求执行部。第一计算机系统所具备的请求发布部发布指定了对象的状态更新请求。在各节点系统中，请求执行部针对每个状态更新请求，执行对表示被指定的对象的状态的数据即客体进行更新的状态更新处理，并且不执行篡改检测处理地对状态更新请求的完成进行响应。篡改检测执行部针对一个或多个更新完成请求中的一个以上的共同完成请求的每一个，执行篡改检测处理，该篡改检测处理通过比较所述多个节点系统的更新后的客体或其概要，来检测该更新后的客体的篡改的有无。更新完成请求是状态更新处理的执行已完成的状态更新请求。共同完成请求是所述多个节点系统中的两个以上的节点系统共同的更新完成请求。

在各节点系统中，表示所述被指定的对象的状态的客体可以包括表示该状态的世代的数据。对于所述被指定的对象，所述篡改检测执行部可以进行以下操作：

·所述篡改检测执行部从所述多个节点系统中分别接收表示该对象的状态的最新世代的最新世代信息。

·所述篡改检测执行部从所述多个节点系统的最新世代信息中确定最新的共同世代。

·所述篡改检测执行部对所述两个以上的节点系统分别指定包括该确定出的最新的共同世代的一个或多个共同世代中的一个以上的共同世代。

·所述篡改检测执行部针对该一个以上的共同世代的每一个，从所述两个以上的节点系统分别接收与该共同世代对应的共同完成请求的更新后客体或其概要。

另外，所述篡改检测执行部可以针对所述被指定的对象执行以下操作。

·所述篡改检测执行部从所述多个节点系统中分别针对该对象接收所有更新后客体或所有更新后客体概要。更新后客体概要是更新后的客体的概要。

·所述篡改检测执行部从所述多个节点系统的所有更新后客体或所有更新后客体概要中，确定所述多个节点系统的至少一个共同更新后客体或至少一个共同更新后客体概要。共同更新后客体是与共同完成请求对应的更新后客体。共同更新后客体概要是共同更新后客体的概要。

·所述篡改检测执行部通过比较所述多个节点系统的共同更新后客体或其概要，来检测该共同更新后客体的篡改的有无。

实施例3和实施例4中的至少一个的数据管理系统可以包括或不包括实施例1和实施例2中的至少一个的数据管理系统所具有的功能(例如，上下文附加部和竞争判定部)。另外，在实施例3和实施例4的至少一个中，排序系统可以由一个分区构成，也可以由多个分区构成。

以上说明了几个实施例，但这些只是用于本发明的说明的例示，并不意味着将本发明的范围仅限定于这些实施例。本发明能够以其他各种方式来执行。

例如，资产集800也可以是UTXO(Unspent Transaction Output：未使用的交易输出)那样的DAG结构的多个交易(各交易包括一个以上的输入和一个以上的输出)。即，成为节点的客体可以是交易，边缘表示的关系可以是交易间的关系。

另外，例如，也可以不针对处理逻辑、Arg和nonce中的至少一个生成使用了用户密钥的电子签名。因此，例如BL、nonce和Sig中的至少一个可以不与从客户端程序134发布的请求相关联。

另外，例如在各节点系统1300中，可以可线性化和/或可串行化地进行资产记录的追加(写入)或获取(读取)。

符号说明

13：客户端系统

15：服务器系统

80：中间系统

1300：节点系统。

Claims (5)

1.一种数据管理系统，其特征在于，具备：

一个或多个篡改检测执行部；以及

与一个或多个第一计算机系统通信的第二计算机系统中的多个节点系统所具备的多个请求执行部，

第一计算机系统所具备的请求发布部发布指定了对象的状态更新请求，

在各节点系统中，请求执行部针对每个状态更新请求，执行对表示由该状态更新请求指定的对象的状态的数据即客体进行更新的状态更新处理，不执行篡改检测处理地响应该状态更新请求的完成，

篡改检测执行部针对一个或多个更新完成请求中的一个以上的共同完成请求的每一个，执行篡改检测处理，该篡改检测处理通过比较所述多个节点系统的更新后的客体或其概要，来检测该更新后客体有无篡改，

更新完成请求是状态更新处理的执行已完成的状态更新请求，

共同完成请求是所述多个节点系统中的两个以上的节点系统共同的更新完成请求。

2.根据权利要求1所述的数据管理系统，其特征在于，

在各节点系统中，表示指定的对象的状态的所述客体包括表示该状态的世代的数据，

所述篡改检测执行部针对指定的所述对象，进行以下动作：

从所述多个节点系统的每一个接收表示该对象的状态的最新世代的最新世代信息，

根据所述多个节点系统的最新世代信息，确定最新的共同世代，

对所述两个以上的节点系统中的每一个指定包括该所确定的最新的共同世代的一个或多个共同世代中的一个以上的共同世代，

对于该一个以上的共同世代中的每一个，从所述两个以上的节点系统中的每一个接收对应于该共同世代的共同完成请求的更新后客体或其概要。

3.根据权利要求1所述的数据管理系统，其特征在于，

所述篡改检测执行部针对指定的所述对象进行以下动作：

针对该对象，从所述多个节点系统中的每一个接收所有更新后客体或所有更新后客体概要，

更新后客体概要是更新后的客体的概要，

从所述多个节点系统的所有更新后客体或所有更新后客体概要中，确定所述多个节点系统的至少一个共同更新后客体或至少一个共同更新后客体概要，

共同更新后客体是对应于共同完成请求的更新后客体，

共同更新后客体概要是共同更新后客体的概要，

通过比较所述多个节点系统的共同更新后客体或其概要，来检测该共同更新后客体有无篡改。

4.根据权利要求3所述的数据管理系统，其特征在于，

在各节点系统中，表示指定的所述对象的状态的客体包括表示该状态的世代的数据，

所述至少一个共同更新后客体是最新的共同世代的共同更新后客体，或者所述至少一个共同更新后客体概要是最新的共同世代的共同更新后客体概要。

5.一种数据管理方法，其特征在于，

在与一个或多个第一计算机系统进行通信的第二计算机系统中的多个节点系统的每一个中，针对指定了对象且从第一计算机系统发布的每个状态更新请求，进行以下动作：

执行更新客体的状态更新处理，该客体是表示由该状态更新请求指定的对象的状态的数据，不执行篡改检测处理地响应状态更新请求的完成，

针对一个或多个更新完成请求中的一个以上的共同完成请求中的每一个，执行篡改检测处理，该篡改检测处理通过比较所述多个节点系统的更新后的客体或其概要，来检测该更新后客体有无篡改，

更新完成请求是状态更新处理的执行已完成的状态更新请求，

共同完成请求是所述多个节点系统中的两个以上的节点系统共同的更新完成请求。

Images