管理账本系统中的可信点
技术领域
本文涉及管理账本系统中的可信点。
背景技术
账本通常用于记录交易历史,例如组织中的经济和金融活动。已构建了具有类似账本功能的应用,例如在关系数据库中创建的自定义审计表或审计轨迹,以维护应用数据的准确历史记录。然而,构建此类应用是耗时的,并且容易出现人为错误。而且,由于关系数据库不是固有不变的,因此对数据的任何更改都难以追踪和验证。
分布式账本系统(DLS),也可以被称为共识网络和/或区块链网络,使得参与的实体能够安全地并且不可篡改地存储数据。在不引用任何特定用例的情况下,DLS通常被称为区块链网络。区块链网络的类型的示例可以包括公有区块链网络、私有区块链网络和联盟区块链网络。区块链网络执行共识处理来验证每个交易,然后再将交易添加到区块链网络中,这可能是耗时的、效率低并且复杂的。
因此,期望开发一种能够有效且安全地管理交易的账本系统,并提供验证存储在账本系统中的交易的不变性、可靠性、可信性和可追溯性的更有效的方法。
发明内容
所描述的主题的实施例可以单独或组合地包括一个或多个特征。
例如,在一个实施例中,一种计算机实现的方法包括:账本系统中的计算设备获得用以针对存储在账本系统中的一系列纪录中的指定记录建立可信点的请求,该可信点指示一系列记录中可信点之前的记录是可信的;确定指定记录是否是候选可信点;响应于确定指定记录是候选可信点,计算设备确定指定记录是否是包括来自可信时间服务器的可信时间戳信息的时间戳记录,可信时间服务器与可信时间机构相关联并且独立于账本系统;响应于确定指定记录不是时间戳记录,计算设备识别一系列记录中的时间戳记录中与指定记录相邻的时间戳记录;计算设备确定时间戳记录是否能够可信地追溯到指定记录;以及响应于确定时间戳记录能够可信地追溯到指定记录,计算设备将时间戳记录标记为一系列记录中的可信点。
在一些实施例中,可以使用设备、系统、方法或计算机可读介质或者设备、系统、方法和计算机可读介质的任何组合来实现这些一般和特定实施例中的一个或多个。前述和其他描述的实施例可以各自可选地包括一个或多个以下实施例:
在一些实施例中,一系列记录中的每个记录包括对应的交易。
在一些实施例中,一系列记录中的每个记录包括一系列记录中该记录紧前的前一记录的对应哈希值。
在一些实施例中,确定所述时间戳记录能够可信地追溯到所述指定记录包括以下中的至少一个:验证所述时间戳记录包括可追溯到所述指定记录并认证所述指定记录的信息;或者验证所述指定记录包括可追溯到所述时间戳记录并认证所述时间戳记录的信息。
在一些实施例中,确定时间戳记录能够可信地追溯到指定记录包括:验证一系列记录中从时间戳记录到指定记录的每个记录包括该记录紧前的前一记录的对应的哈希值。
在一些实施例中,确定指定记录是候选可信点包括:验证指定记录能够可信地追溯到一系列记录中指定记录之前的先前可信点。
在一些实施例中,验证指定记录能够可信地追溯到指定记录之前的先前可信点包括:验证一系列记录中从指定记录到先前可信点的每个记录包括该记录紧前的前一记录的对应的哈希值。
在一些实施例中,先前可信点是以下中的一个:一系列记录中指定记录紧前的可信点或作为一系列纪录中的可信点源的第一记录。
在一些实施例中,验证指定记录能够可信地追溯到一系列记录中指定记录之前的先前可信点包括以下中的至少一个:从一系列记录中的指定记录向后追溯到所述先前可信点,或从一系列记录中的所述先前可信点向前追溯到指定记录。
在一些实施例中,接收请求以验证一系列记录中指定记录之后的待验证记录;并且通过验证待验证记录能够可信地追溯到时间戳记录来确定待验证记录被验证,而无需验证一系列记录中时间戳记录之前的记录。
在一些实施例中,向可信时间服务器发送时间戳请求;从可信时间服务器接收针对时间戳请求的可信时间戳和关联签名;以及将可信时间戳和关联签名作为记录存储在一系列记录中,其中,存储来自可信时间服务器的可信时间戳和关联签名的所述记录是一系列记录中的新时间戳记录,以及其中,当时间戳请求被发送时,新时间戳记录被存储在一系列记录中存储的最近记录紧后,并且新时间戳记录包括最近记录的哈希值。
在一些实施例中,一系列纪录中的新时间戳记录与新时间戳记录紧前的前一时间戳记录之间的记录被分组在一个单元中,并且新时间戳记录作为最后一个记录被包括在该单元中。
在一些实施例中,时间戳请求包括以下中的至少一个:向可信时间服务器发送的时间戳请求中的时间戳请求的标识、最近记录的标识或哈希值、或单元中的记录的哈希值的哈希摘要。
在一些实施例中,识别所述时间戳记录包括以下中的一个:将包括所述指定记录的单元中的最后一个记录识别为所述时间戳记录,以及将包括所述指定记录的所述单元紧前的前一单元中的最后一个记录识别为所述时间戳记录。
在一些实施例中,所述方法还包括:确定一系列记录中的第二记录是第二候选可信点;确定第二记录是一系列纪录中的时间戳记录;以及将第二记录标记为一系列纪录中的第二可信点。
在一些实施例中,所述方法还包括:针对时间戳请求以预定时间段向可信时间服务器周期性地发送时间戳请求。
在一些实施例中,所述方法还包括:顺序地生成将一系列记录存储在区块链中的区块,每个区块存储一个或多个记录并且在区块链中被链接一起,其中,在区块链中生成区块独立于确定指定记录是可信点而进行并且独立于向可信时间服务器发送时间戳请求而进行。
在一些实施例中,确定存储在账本系统中的一系列记录中的指定记录是候选可信点独立于向可信时间服务器发送时间戳请求而进行。
在一些实施例中,响应于确定指定记录不是包括来自可信时间服务器的可信时间戳信息的时间戳记录,不将指定记录标记为一系列记录中的可信点。
在一些实施例中,一系列记录中的每个记录与对应的记录标识相关联,并且根据对应的记录标识将一系列记录按顺序存储,并且识别一系列记录中的多个时间戳记录中与指定记录相邻的时间戳记录包括:识别一系列记录中与最接近该指定记录的记录标识的记录标识相关联的时间戳记录。
在一些实施例中,新时间戳记录包括该单元中的记录的哈希值的哈希摘要。
应当理解的是,根据本文的方法可包括本文描述的实施例的任何组合。也就是说,根据本文的方法不限于本文具体描述的实施例的组合,还包括所提供的实施例的任何组合。
在附图和以下描述中阐述了本文的一个或多个实施例的细节。根据说明书和附图以及权利要求,本文的其他实施例和优点将显现。
附图说明
图1是示出可用于执行本文实施例的环境的示例的示图。
图2是示出根据本文实施例的架构的示例的示图。
图3是示出根据本文实施例的在账本系统中实现可信时间戳服务的环境的示例的示图。
图4A是示出根据本文实施例的用于在与单个客户端相关联的单个账本服务器中实现可信时间戳服务的账本系统的示例的示图。
图4B是示出根据本文实施例的用于通过联合账本服务器向多个客户端提供可信时间戳服务的账本系统的示例的示图。
图5A是示出根据本文实施例的具有可信点的账本系统的示例的示图。
图5B是示出根据本文实施例的具有存储在交易中的可信时间戳信息的账本系统的示例的示图。
图5C是示出根据本文实施例的管理时间戳交易上的可信点的账本系统的示例的示图。
图6是示出可根据本文实施例执行的处理的示例的流程图。
图7描绘了根据本文实施例的装置的模块的示例。
各附图中的相同附图标记和名称表示相同的元件。
具体实施方式
本文描述了用于管理账本系统中的可信点的技术。这些技术通常涉及采用区块链数据结构和/或类似区块链数据结构的账本系统(例如,基于区块链的中心化账本系统)以利用存储在账本系统中的数据的不可变性、可靠性,可信性、可追溯性和可验证性。账本系统可以将数据存储为一系列数据记录(也称为记录),例如交易或区块。在一些实施例中,一系列记录可以链接或锚定在一起,以防止未经授权更改所存储的数据。例如,记录可以存储记录紧前的前一记录的唯一标识(例如,对应的哈希值),使得前一记录的任何改变将导致唯一标识的改变,从而导致与存储在记录中的唯一标识的不匹配。这种类似区块链的数据结构提供了用于验证存储在账本系统中的记录的可信性的方案。例如,可以通过检查记录之前的所有记录是否都可以向后可信地追溯到原始记录或初始记录(例如,账本系统中的创始交易或区块链中的创始区块)来验证记录的可信性。
如本文所使用的,“A可以可信地追溯到B”包括以下情形:A包括可追溯到B的信息,并且该信息认证B未被改变,或者B包括可追溯到A的信息,并且该信息认证A未被改变。例如,A可以包括B的哈希值。可以例如由验证者独立地计算B的哈希值,然后与存储在A中的哈希值进行比较。如果两个哈希值匹配,则可以确定B被认证。因此,A可以可信地追溯到B。类似地,如果B包括A的哈希值或认证A未被改变的其他可验证信息,则A被认为可以可信地追溯到B。在一些实施例中,A可以可信地追溯到B还包括A和B经由中间数据彼此可以可信地追溯的情形。例如,如果A可信地追溯到C,并且C可以可信地追溯到B,则认为A可以可信地追溯到B。可以推测出其他情形。
账本系统可以在一系列记录之中建立可信点。例如,可信点可以是一系列记录中的一个记录(例如,区块链的区块中的交易或区块链中的区块),其指示该一系列记录中存储在可信点之前的所有记录都是可信的。这样,可以通过可信地追溯到可信点来验证存储在可信点之后的数据的可信性,而无需向后追溯到原始记录或初始记录(例如,账本系统中的创始交易或区块链中的创始区块)或可信点之前的任何数据。因此,可以简化验证处理并且可以提高计算效率。在一些实施例中,账本系统可以从独立于账本系统的可信时间服务器(例如,全球公认的第三方时间机构)获得可信时间戳信息。账本系统可以利用由可信时间服务器提供的时间戳信息上建立的可信点,并将可信时间戳信息集成到账本系统中以用于存储的数据和/或建立的可信点,这可以进一步增强存储的数据的可信度、可信性、可审计性和合法性。
仅出于说明目的,在本公开中,将交易描述为记录的示例。
本文中描述的技术产生若干技术效果。在一些实施例中,账本系统可以是基于区块链的中心化账本系统,该系统可以提供具有时间关键型审计(具有不可否认性和防篡改性)的密码学可验证状态独立数据账本存储。在一些实施例中,账本系统可以基于具有可信度和中立性的中心化背书的云平台提供账本服务。账本系统可以通过利用区块链系统的可信度以及中心化系统的高性能和低延迟来提供高可靠性和高性能的可审计流账本服务,以处理具有审计要求、可追溯性和追踪性的各种类型的数据和日志。
在一些实施例中,账本系统可以包括中央可信机构,该中央可信机构提供存储在区块链数据结构的区块中的透明、不可变且密码学可验证的数据。在一些实施例中,所存储的数据可以是日志格式,例如不仅包括交易日志,还包括其他交易数据和区块数据。由于中央可信机构的存在,账本系统无需执行共识处理即可建立信任,从而可以节省大量时间和成本。在一些实施例中,与典型的基于区块链的分布式或去中心化账本系统相比,账本系统可以更高效。在一些实施例中,账本系统可以提供具有增强的信任、效率和存储性能的基于云的存储服务。
在一些实施例中,账本系统可以增强账本系统中存储的数据的可信度、可审计性和合法性。例如,账本系统可以与可信时间服务器对接,并将可信时间服务器的可信时间戳信息提供给账本系统的客户端。可信时间服务器独立于账本系统。可信时间服务器可以与提供准确时间服务的第三方可信时间机构相关联,并且可以被公众、审计实体(例如公司、机构或组织)和/或法人实体(例如法院或政府)在全球范围内承认或信任。随着可信时间服务器提供的时间戳信息的可信性被承认,将可信时间服务器的时间戳信息集成到账本系统中以用于存储的数据可以进一步增强存储在账本系统中的数据的可信度、可审计性和合法性。
在一些实施例中,账本系统赋予账本系统的当事方或参与者对应的权利。例如,账本系统的客户端可以具有为在账本系统中存储交易数据提供签名的权利,以使得客户端不可否认交易数据。在一些实施例中,账本系统具有为承认交易数据的存储提供签名的权利,使得账本系统不能否认存储了交易数据。在一些实施例中,可信时间服务器具有为用于存储在账本系统上的交易数据的可信时间戳信息提供签名的权利,使得可信时间服务器不能否认可信时间戳信息。在一些实施例中,三个当事方(客户端、账本系统和可信时间服务器)的三种对应的权利彼此独立。这三种权利的集成以及它们对应的不可否认性和防篡改性可以进一步提高存储在账本系统中的交易数据的可信度和可审计性。
在一些实施例中,账本系统可以增强存储在账本系统中的交易数据的有序性和真实性。例如,账本系统可以向可信时间服务器发送针对存储在账本系统中的交易数据的可信时间戳请求,并且可信时间服务器可以提供例如时间戳和关联签名的可信时间戳信息,例如,以认证交易数据的时间或对其背书。账本系统可以将可信时间戳信息例如作为交易存储在账本系统中。
在一些实施例中,存储来自可信时间服务器的可信时间戳信息的交易可以被称为时间戳交易。在一些实施例中,可以通过每个交易存储该交易紧前的前一交易的相应哈希值将一系列交易链接或锚定在一起。时间戳交易还可以存储时间戳交易紧前的前一交易的哈希值。因此,可信时间戳信息可用于验证存储在账本系统中的交易的有序性和真实性,进而可以增强存储在账本系统中的交易的可信度、可审计性和合法性。
在一些实施例中,账本系统可以请求针对一个单元中要在前一时间戳交易紧后添加到账本系统中的两个或更多个交易的可信时间戳信息。账本系统可以发送时间戳请求,该时间戳请求包括交易的信息,例如单元中交易的哈希值的哈希摘要。在接收到针对时间戳请求的可信时间戳信息之后,账本系统可以将可信时间戳信息作为新时间戳交易存储在该单元中,这也是该单元中的最后一个交易。单元中的交易可以被视为具有与新时间戳交易相同的可信时间戳。以这种方式,账本系统可以减少从可信时间服务器请求可信时间戳的整体费用。
在一些实施例中,本文描述的这些技术可以增强存储在账本系统中的数据记录(例如,交易)的不可变性、可靠性、可信性和可追溯性,并提供验证数据记录的这些安全性特征的更有效的方式。在一些实施例中,账本系统可以在存储在账本系统中的一系列交易中建立可信点。可信点表示可信点之前的交易是可信的。当要验证一系列交易中的一个交易时,账本系统可以识别该交易之前的最近的可信点,并可以通过仅验证该交易是否可以可信地追溯到最近的可信点来确定是否可以验证该交易,而无需验证历史交易,例如最近的可信点之前的交易。这可以显著增强一系列交易的交易验证速度、效率和准确性。例如,账本系统可以包括大量交易,例如1000个交易。如果在大量交易中没有建立可信点,要验证最近交易(例如第1000个交易),账本系统必须验证该交易是否可以可信地追溯到初始交易或创始交易(例如,第一个交易),例如,通过验证从最近交易到初始交易的每个交易是否包括其紧前的前一交易的对应哈希值。也就是说,账本系统必须执行约1000次验证。然而,如果账本系统在多个交易中建立多个可信点,例如每10个交易一个可信点,要验证最近交易,账本系统可以识别最近交易之前的最近的可信点,例如,第990个交易。然后,账本系统可以验证最近交易是否可以向后可信地追溯到最近的可信点,例如第990个交易,而无需验证最近的可信点之前的历史交易。也就是说,账本系统仅需要执行约10次验证。因此,可以显著提高验证计算效率。由于计算大量减少,验证精度也可以被提高。
在一些实施例中,所描述的技术可以在时间戳交易上建立可信点,该时间戳交易存储来自可信时间服务器的可信时间戳信息。可信时间戳信息提供了来自可信时间服务器的一层附加信任,该可信时间服务器对存储的数据(例如交易)的时间进行认证,以进一步防止未经授权更改存储的数据。因此,与没有可信时间戳信息的可信点相比,基于来自可信时间服务器的时间戳信息,所建立的可信点可以增强信任或认可。如果确定为可信点的指定交易不是时间戳交易,则账本系统可以在可以可信地追溯到指定交易的与指定交易相邻的时间戳交易上建立可信点。如果确定指定交易是时间戳交易但不是可信点,则账本系统可以识别与该指定交易相邻并且可以可信地追溯到该时间戳交易之前的先前可信点的时间戳交易,并在相邻的时间戳交易上建立新的可信点。
在一些实施例中,时间戳交易可以是包括指定交易的交易单元中的最后一个交易,或者可以是包括指定交易的单元紧前的前一单元中的最后一个交易。以这种方式,定位相邻的时间戳交易以针对指定交易建立可信点可以更容易且更快。结果,验证存储在账本系统中的交易的可信度、可信性和合法性的效率和准确度可以进一步被增强。
在一些实施例中,如果以下条件都被满足,则账本系统可以将指定交易建立为可信点:(1)指定交易可以可信地追溯到一系列交易中的另一可信点,并且(2)指定交易是存储来自可信时间服务器的可信时间戳信息的时间戳交易。在一些实施例中,账本系统可以首先按顺序或并行验证所述两个条件。例如,账本系统可以例如通过验证指定交易可以可信地追溯到另一可信点来验证指定交易是可信点,然后确定指定交易是否是时间戳交易。在一些实施例中,账本系统可以首先确定指定交易是否是时间戳交易,然后确定指定交易是否可以可信地追溯到另一可信点。如果账本系统确定指定交易满足两个条件之一,则账本系统可以确定指定交易是候选可信点。只有账本系统确定两个条件指定交易都满足,则账本系统可以确定指定交易是可信点。
为本文的实施例提供进一步的背景,如上所述,分布式账本系统(DLS),其也可以称为共识网络(例如,由点对点节点组成)和区块链网络,使参与的实体能够安全地且不可篡改地进行交易和存储数据。尽管术语“区块链”通常与特定网络和/或用例相关联,但是在不参考任何特定用例的情况下,本文使用“区块链”来一般地指代DLS。
区块链是以交易不可篡改的方式存储交易的数据结构。因此,区块链上记录的交易是可靠且可信的。区块链包括一个或多个区块。链中的每个区块通过包括链中其紧前的前一区块的哈希值链接到该前一区块。每个区块还包括本地时间戳(例如,由生成该区块的计算设备或管理区块链的计算系统提供),其自身的哈希值以及一个或多个交易。例如,区块可以包括区块头和区块体。区块头可以包括本地时间戳、其自身的哈希值以及前一区块的哈希值。区块体可以包括有效载荷信息,例如一个或多个交易(或交易数据)。已经被区块链网络中的节点验证的交易经哈希处理并编入默克尔(Merkle)树中。Merkle树是一种数据结构,在该树的叶节点处的数据是经哈希处理的,并且在该树的每个分支中的所有哈希值在该分支的根处级联(concatenated)。此过程沿着树持续一直到整个树的根,在整个树的根处存储了代表树中所有数据的哈希值。可通过确定哈希值是否与树的结构一致而可快速验证该哈希值是否为存储在该树中的交易的哈希值。
区块链是用于存储交易的去中心化或至少部分去中心化的数据结构,而区块链网络是通过广播交易、验证交易和确认交易有效性等来管理、更新和维护一个或多个区块链的计算节点的网络。如上所述,区块链网络可作为公有区块链网络、私有区块链网络或联盟区块链网络被提供。
通常,联盟区块链网络在参与实体间是私有的。在联盟区块链网络中,共识处理由可被称为共识节点的授权的节点集控制,一个或多个共识节点由相应的实体(例如,金融机构、保险公司)操作。例如,由10个实体(例如,金融机构、保险公司)组成的联盟可以操作联盟区块链网络,每个实体操作联盟区块链网络中的至少一个节点。在一些示例中,在联盟区块链网络内,全局区块链作为跨所有节点复制的区块链被提供。也就是说,对于全局区块链,所有的共识节点处于完全状态共识。为了实现共识(例如,同意将区块添加到区块链),在联盟区块链网络内实现共识协议。例如,联盟区块链网络可以实现实用拜占庭容错(PBFT)共识,下面将进一步详细描述。
在一些实施例中,中心化账本系统还可以采用区块链的数据结构,以利用存储在区块链上的数据的不可变性、可靠性和可信性。在一些实施例中,这种中心化账本系统可以被称为基于区块链的中心化账本系统或通用可审计账本服务系统。在一些实施例中,基于区块链的中心化账本系统可以包括中央可信机构,该中央可信机构提供存储在区块链数据结构的区块中的透明、不可变且密码学可验证的数据。所存储的数据可以是日志格式,例如不仅包括交易日志,还包括其他交易数据和区块数据。由于中央可信机构的存在,基于区块链的中心化账本系统无需执行共识处理即可建立信任。在一些实施例中,与典型的基于区块链的分布式或去中心化账本系统相比,基于区块链的中心化账本系统可以更高效。在一些实施例中,基于区块链的中心化账本系统可以提供具有增强的信任、效率和存储性能的基于云的存储服务。
在一些实施例中,中心化账本系统可以是区块链网络的节点。例如,中心化账本系统可以是区块链网络中的非共识节点,并且可以为区块链网络中的共识节点或其他非共识节点或区块链网络外部的实体提供高度可靠且高性能的可审计流账本服务。
图1是示出可用于执行本文实施例的环境100的示例的示图。在一些示例中,环境100使得实体能够参与至联盟区块链网络102中。环境100包括计算系统106、108和网络110。在一些示例中,网络120包括局域网(LAN)、广域网(WAN)、因特网或其组合,并且连接网站、用户设备(例如,计算设备)和后端系统。在一些示例中,可以通过有线和/或无线通信链路访问网络120。在一些示例中,网络110使得能够与联盟区块链网络102通信或在联盟区块链网络102内通信。通常,网络110表示一个或多个通信网络。在一些情况下,计算系统106、108可以是云计算系统(未示出)的节点,或者计算系统106、108中的每个可以是单独的云计算系统,其包括通过网络互连并且用作分布式处理系统的多个计算机。
在所描绘的示例中,计算系统106、108可以各自包括能够作为节点参与至联盟区块链网络102中的任何适当的计算设备120。计算设备的示例包括但不限于服务器、台式计算机、膝上型计算机、平板计算设备以及智能电话。在一些示例中,计算系统106、108承载一个或多个由计算机实施的服务,用于与联盟区块链网络102进行交互。例如,计算系统106可以承载第一实体(例如,用户A)的计算机实施的、例如交易管理系统的服务,例如第一实体使用该交易管理系统管理其与一个或多个其他实体(例如,其他用户)的交易。计算系统108可以承载第二实体(例如,用户B)的由计算机实施的、例如交易管理系统的服务,例如,第二实体使用该交易管理系统管理其与一个或多个其他实体(例如,其他用户)的交易。在图1的示例中,联盟区块链网络102被表示为节点的点对点网络(Peer-to-Peer network),并且计算系统106、108分别提供参与联盟区块链网络102的第一实体和第二实体的节点。
图2是示出根据本文的实施例的架构200的示例的示图。示例性概念架构200包括分别对应于参与者A、参与者B和参与者C的参与者系统202、204、206。每个参与者(例如,用户、企业)参与到作为点对点网络提供的区块链网络212中,该点对点网络包括多个节点214,至少一些节点将信息不可篡改地记录在区块链216中。如图中进一步详述,尽管在区块链网络212中示意性地描述了单个区块链216,但是在区块链网络212上提供并维护了区块链216的多个副本。
在所描绘的示例中,每个参与者系统202、204、206分别由参与者A、参与者B和参与者C提供或代表参与者A、参与者B和参与者C,并且在区块链网络中作为各自的节点214发挥作用。如这里所使用的,节点通常是指连接到区块链网络212且使相应的参与者能够参与到区块链网络中的个体系统(例如,计算机、服务器)。在图2的示例中,参与者对应于每个节点214。然而,可以预期,一个参与者可以操作区块链网络212内的多个节点214,和/或多个参与者可以共享一个节点214。在一些示例中,参与者系统202、204、206使用协议(例如,超文本传输协议安全(HTTPS))和/或使用远程过程调用(RPC)与区块链网络212通信或通过区块链网络212进行通信。
节点214可以在区块链网络212内具有不同的参与程度。例如,一些节点214可以参与共识处理(例如,作为将区块添加到区块链216的矿工节点),而其他节点214不参与此共识处理。作为另一示例,一些节点214存储区块链216的完整的副本,而其他节点214仅存储区块链216的一部分的副本。例如,数据访问特权可以限制相应的参与者在其相应系统内存储的区块链数据。在图2的示例中,参与者系统202、204、206存储区块链216的相应的完整副本216'、216”和216”'。
区块链(例如,图2的区块链216)由一系列区块组成,每个区块存储数据。数据的示例包括表示两个或更多个参与者之间的交易的交易数据。交易数据被用作存储在区块链中的数据的示例。交易的示例可以包括但不限于交换有价值的东西(例如,资产、产品、服务、货币)。在一些实施例中,在账本系统中执行的一个或多个操作可以作为交易数据存储在区块链中。例如,交易数据可以包括对存储在区块链中的数据的一种或多种操作或操纵,从外部资源获得的信息(例如,时间戳信息)或任何适当的数据(例如,文档、图片、视频、音频)可以存储在区块链中。交易数据不可篡改地存储在区块链中。也就是说,交易数据不能改变。
在将交易数据存储在区块中之前,对交易数据进行哈希处理。哈希处理是将交易数据(作为字符串数据提供)转换为固定长度的哈希值(也作为字符串数据提供)的处理。不可能对哈希值进行去哈希处理(un-hash)以获取交易数据。哈希处理可确保即使交易数据轻微改变也会导致完全不同的哈希值。此外,如上所述,哈希值具有固定长度。也就是说,无论交易数据的大小如何,哈希值的长度都是固定的。哈希处理包括通过哈希函数处理交易数据以生成哈希值。示例性哈希函数包括但不限于输出256位哈希值的安全哈希算法(SHA)-256。
多个交易的交易数据被哈希处理并存储在区块中。例如,提供两个交易的哈希值,并对它们本身进行哈希处理以提供另一个哈希值。重复此过程,直到针对所有要存储在区块中的交易提供单个哈希值为止。该哈希值被称为Merkle根哈希值,并存储在区块的头中。任何交易中的更改都会导致其哈希值发生变化,并最终导致Merkle根哈希值发生变化。
通过共识协议将区块添加到区块链。区块链网络中的多个节点参与共识协议,并执行将区块添加到区块链中的工作。这样的节点被称为共识节点。上文介绍的PBFT用作共识协议的非限制性示例。共识节点执行共识协议以将交易添加到区块链,并更新区块链网络的整体状态。
更详细地,共识节点生成区块头,对区块中的所有交易进行哈希处理,并将所得的哈希值成对地组合以生成进一步的哈希值,直到为区块中的所有交易提供单个哈希值(Merkle根哈希值)。将此哈希值添加到区块头中。共识节点还确定区块链中最新的区块(即添加到区块链中的最后一个区块)的哈希值。共识节点还向区块头添加随机数(nonce)值和时间戳。
通常,PBFT提供容忍拜占庭错误(例如,故障节点、恶意节点)的实用拜占庭机器状态复制。这通过假设将发生故障(例如,假设存在独立节点故障和/或由共识节点发送的经操纵的消息)在PBFT中实现。在PBFT中,在包括主共识节点和备共识节点的序列中提供共识节点。主共识节点周期性地改变,通过区块链网络内的所有共识节点就区块链网络的全局状态达成一致,将交易添加到区块链中。在该处理中,消息在共识节点之间传输,并且每个共识节点证明消息是从指定的对等节点接收的,并验证在交易期间消息未篡改。
在PBFT中,共识协议是在所有共识节点始于相同的状态的情况下分多个阶段提供的。首先,客户端向主共识节点发送请求以调用服务操作(例如,在区块链网络内执行交易)。响应于接收到该请求,主共识节点将该请求组播到备共识节点。备份共识节点执行请求,并且每个节点都向客户端发送回复。客户端等待直到收到阈值数量的恢复。在一些示例中,客户端等待接收f+1个回复,其中f是区块链网络内可以容忍的错误共识节点的最大数量。最终结果是,足够数量的共识节点就将记录添加到区块链的顺序达成一致,该记录被接受或者被拒绝。
在一些区块链网络中,用密码学来维护交易的隐私。例如,如果两个节点想要保持交易隐私,以使得区块链网络中的其他节点不能看出交易的细节,则这两个节点可以对交易数据进行加密处理。加密处理的示例包括(但不限于)对称加密和非对称加密。对称加密是指使用单个密钥既进行加密(从明文生成密文)又进行解密(从密文生成明文)的加密过程。在对称加密中,同一密钥可用于多个节点,因此每个节点都可以对交易数据进行加密/解密。
非对称加密使用密钥对,每个密钥对包括私钥和公钥,私钥仅对于相应节点是已知的,而公钥对于区块链网络中的任何或所有其他节点是已知的。节点可以使用另一个节点的公钥来加密数据,并且该加密的数据可以使用其他节点的私钥被解密。例如,再次参考图2,参与者A可以使用参与者B的公钥来加密数据,并将加密数据发送给参与者B。参与者B可以使用其私钥来解密该加密数据(密文)并提取原始数据(明文)。使用节点的公钥加密的消息只能使用该节点的私钥解密。
非对称加密用于提供数字签名,这使得交易中的参与者能够确认交易中的其他参与者以及交易的有效性。例如,节点可以对消息进行数字签名,而另一个节点可以根据参与者A的该数字签名来确认该消息是由该节点发送的。数字签名也可以用于确保消息在传输过程中不被篡改。例如,再次参考图2,参与者A将向参与者B发送消息。参与者A生成该消息的哈希值,然后使用其私钥加密该哈希值以提供作为加密哈希值的数字签名。参与者A将该数字签名附加到该消息上,并将该具有数字签名的消息发送给参与者B。参与者B使用参与者A的公钥解密该数字签名,并提取哈希值。参与者B对该消息进行哈希处理并比较哈希值。如果哈希值相同,参与者B可以确认该消息确实来自参与者A,且未被篡改。
图3是示出根据本文的实施例的环境300的示例的示图。环境300在账本系统310中实现可信时间戳服务。仅出于说明目的,将基于区块链的中心化账本系统描述为账本系统310的示例。基于区块链的中心化账本系统310采用区块链的数据结构,以利用存储在区块链上的数据的不可变性、可靠性和可信性。中心化账本系统310还可以集成来自独立于中心化账本系统310的可信时间服务器350的可信时间戳信息,以用于存储在区块链上的数据,这可以显著增强存储的数据的可信度、可审计性和合法性。
在一些实施例中,中心化账本系统310可以是包括通过网络互连的一个或多个计算机的云计算系统。中心化账本系统310可以包括任何适当的计算设备。计算设备的示例包括但不限于服务器、台式计算机、膝上型计算机、平板计算设备以及智能电话。
在一些实施例中,中心化账本系统310包括一个或多个账本服务器320-1至320n(在本文中统称为“320”)。每个账本服务器320可以承载一个或多个计算机实现的服务,用于与例如,客户端1或客户端m的至少一个客户端进行交互。客户端可以是个人、公司、组织、金融机构、保险公司或任何其他类型的实体。在一些情况下,客户端可以与一个或多个账本服务器相关联。在一些情况下,账本服务器可以与一个或多个客户端相关联。
账本服务器320可以承载交易管理系统以向例如客户端1或客户端m的客户端提供账本服务,并且客户端可以使用例如客户端设备340-1或340-m(在本文中统称为“340”)的一个或多个关联设备来访问交易管理系统以使用账本服务。客户端设备340可以包括任何适当的计算设备。
账本服务器320提供的账本服务可以使客户端能够将其数据存储在透明、不可变和密码学可验证的区块链数据结构中,例如区块链中。例如320-1或320-n的每个账本服务器可以维护对应的区块链,例如322-1至322-n(在本文中统称为“322”)。在一些实施例中,每个账本服务器320可以执行与区块链网络中的区块链网络节点(例如,图1的计算系统106或108或者图2的计算系统202、204或206)的功能相似的功能。例如,每个账本服务器320可以生成区块并将这些区块添加到区块链322。在一些实施例中,每个账本服务器320可以充当中央可信机构,并且不需要与其他节点(例如,其他客户端设备或其他账本服务器)执行共识处理即可建立信任。例如,每个账本服务器320可以执行与区块链网络的非共识节点的功能相似的功能。在一些实施例中,每个账本服务器320可以是创建和/或管理区块链322的单个节点。
在一些实施例中,每个客户端可以与对应的区块链相关联。在一些实施例中,一个或多个客户端可以与同一区块链相关联。在一些实施例中,一个区块链可以与一个或多个客户端相关联。
在一些示例中,客户1是个人、公司或组织。与客户端1相关联的客户端设备340-1可以与账本服务器320-1交互以获得中心化账本系统310的账本服务。例如,客户端设备340-1可以通过账本服务器320-1访问区块链322-1以读取和存储与客户端1相关联的交易数据。客户端设备340-1可以包括例如被编码以执行本文所述方法的任何合适的计算机、模块、服务器或计算元件。在一些实施例中,客户端设备340-1可以包括用户设备,例如个人计算机、智能电话、平板电脑或其他手持设备。
在一些示例中,客户端m是具有多个个人用户的保险公司或例如银行的金融机构。与客户端m相关联的客户端设备340-m可以与账本服务器320-m交互,以向客户端m的个人用户提供中心化账本系统310的账本服务。例如,客户端设备340-m可以通过账本服务器320-m访问区块链322-m以读取和存储与客户端m相关联的交易数据。在一些情况下,客户端m的用户可以通过客户端设备340-m请求中心化账本系统310的账本服务。
存储在区块链中的数据可以是日志格式,例如不仅包括交易日志,还包括其他交易数据和区块数据。每个区块链以不可变且不能更改或删除的方式存储数据。使用加密可以使得能够验证没有对存储的数据进行意外修改。因此,记录在区块链上的数据是可靠且可信的。
区块链可以包括一个或多个区块。区块链中的每个区块通过包括链中其紧前的前一区块的哈希值链链接到该前一区块。每个区块还包括本地时间戳、自身的哈希值以及一个或多个交易或者交易数据。例如,区块可以包括区块头和区块体。区块头可以包括本地时间戳、其自身的哈希值以及前一区块的哈希值。区块体可以包括有效载荷信息,例如一个或多个交易或者交易数据。本地时间戳指示区块被生成和/或添加到区块链的时间点或实例。本地时间戳可由账本服务器320、中心化账本系统310或与中心化账本系统310关联的中央可信机构内部提供。
在一些实施例中,账本服务器320顺序地接收与客户端相关联的一系列交易,然后将交易存储在区块链的区块中。在一些实施例中,账本服务器320可以例如从一个或多个客户端设备340接收一个或多个交易。接收到的交易可以被存储在数据缓冲器中。账本服务器320可以生成存储交易的区块,例如,包括受让人和转让人的账户、交易金额或其他类型的交易信息。
在一些实施例中,账本服务器320可以将交易存储在流、阵列或另一数据结构(称为交易存储流)中。例如,可以根据交易的发生时间将交易顺序地存储在交易存储流中。每个交易可以例如根据其发生时间在交易存储流中具有相应的交易标识。账本服务器320可以生成区块以包括多个交易或针对交易的多个哈希值。在一些实施例中,可以根据相应交易的发生时间而不是根据哈希值来存储交易或针对交易的哈希值。在一些实施例中,针对交易的哈希值可以是交易的哈希值或交易的对应交易标识的哈希值。区块可以包括其紧前的前一区块的哈希值,使得区块彼此锚定以形成区块链(或区块存储流)。以这种方式,区块不存储交易的细节。交易的细节可以被存储在账本服务器320中的交易存储流中或中心化账本系统310中的单独的存储库中。
账本服务器320还可以向客户端提供可信时间戳服务。在一些实施例中,账本服务器320可以请求来自可信时间服务器350的可信时间戳,以用于存储在账本服务器320中的数据,这可以增强所存储的数据的可信度、可审计性和合法性。可信时间服务器350独立于中心化账本系统310。可信时间服务器350可以与提供准确(或真实)时间服务的第三方可信时间机构相关联,并且可以例如被公众、审计实体(例如公司、机构或组织)和/或法律实体(例如法院或政府)在全球范围内承认或信任。可信时间服务器350提供的可信时间戳信息可以无需公证和/或司法鉴定即被承认或视为合法。例如,可信时间服务器350可以是提供UTC(世界标准时间)/GMT(格林威治标准时间)时间服务的UTC/GMT服务器。可信时间服务器350还可以是为国家或地区提供标准时间的可信机构的时间服务器。
中心化账本系统310可以通过网络,例如图1的网络110,与可信时间服务器350通信。响应于从例如账本服务器320的客户端接收到时间戳请求,可信时间服务器350可以生成指示接收到时间戳请求时的时间点的时间戳。可信时间服务器350可以生成用于认证时间戳和时间戳请求(例如,时间戳请求的文本或图像副本)的签名。例如,可信时间服务器350可以使用其私钥来签名,从而对时间戳和时间戳请求进行密码学加密。可信时间服务器350可以生成包括时间戳和关联签名的数字时间戳证书,并且向客户发送包括时间戳证书的时间戳信息。可信时间服务器350可以以例如每个时间戳请求$1的费用提供可信时间戳服务。
在一些实施例中,账本服务器320可以向可信时间服务器350发送时间戳请求以认证区块链中的区块的时间。时间戳请求可以包括区块的信息,例如,区块的哈希值。时间服务器350可以生成包括用于区块的时间戳和关联签名或者时间戳和关联签名的哈希值的时间戳信息并发送该时间戳信息。在从可信时间服务器350接收到时间戳信息之后,账本服务器320可以将时间戳信息或时间戳信息的哈希值存储到区块链中区块紧后的后一区块中。在一些实施例中,时间戳信息可以作为交易存储在后续区块中。存储时间戳信息的区块可以被称为带时间戳的区块。带时间戳的区块可以是仅包括时间戳信息的区块,也可以是还包括除了时间戳信息之外的其他交易的区块。区块链中带有时间戳的区块可以在区块链中彼此被锚定或链接。
在一些实施例中,账本服务器320可以以预定触发时间段向可信时间服务器350周期性地发送针对区块链中待加时间戳区块的时间戳请求。例如,账本服务器320可以包括计时器,该计时器对发送第一时间戳请求之后的时间进行计时。当计时器计数到预定触发时间段时,账本服务器320可以被触发以紧接在第一时间戳请求之后发送第二时间戳请求。中心化账本系统310或账本服务器320可以提供具有对应于不同触发时间段的不同费用的时间戳服务。触发时间段可以由与区块链或账本服务器320相关联的客户端(或用户)预先确定。例如,客户端可以选择与对应的费用和对应的触发时间段相对应的时间戳服务。
在一些实施例中,账本服务器320可以不是周期性地向可信时间服务器350发送时间戳请求。例如,账本服务器320可以根据需要或基于由账本服务器320生成的区块的数量来发送时间戳请求。例如,账本服务器320可以在从客户端接收到指令时或者在最近已经将预定数量的区块添加到区块链322时发送区块的时间戳请求。
在一些实施例中,账本服务器320可以以区块生成的预定时间段周期性地生成区块。预定触发时间段可以与区块生成的时间段相同或不同。预定触发时间段可以比区块生成的时间段更长,使得例如由于从可信时间服务器350获得时间戳的费用,并不是每个区块都带有时间戳。在一些实施例中,账本服务器320可以不是周期性地生成区块。例如,账本服务器320可以根据需要或基于账本服务器320接收到的交易的数量来生成区块。例如,账本服务器320可以在接收到预定数量的交易时生成新的区块。
在一些实施例中,账本服务器320可以包括被配置为与可信时间服务器350通信的一个或多个应用编程接口(API)。API可以包括一组子例程定义、通信协议以及用于构建软件的工具,并且可以定义由程序(模块、库)提供的功能,并允许从该功能的确切实施方式中进行抽象。软件组件通过API彼此交互。在一些实施例中,账本服务器320可以包括可以实现以下功能的一个或多个API:接收待加时间戳的区块的哈希值作为时间戳请求的输入,向可信时间服务器350发送时间戳请求,以及接收可信时间服务器350发送的可信时间戳信息,例如,数字时间戳证书或者时间戳和关联签名。
账本服务器320可以包括被配置为和与客户端相关联的客户端设备340通信的一个或多个API。一个或多个API可以实现诸如以下的功能:从客户端设备340接收针对时间戳服务的请求,列出具有不同费用和不同触发时间段的不同时间戳服务,从客户端设备340接收对时间戳服务的选择,以及向客户端设备340发送或显示相应费用以及相应触发时间段。在一些实施例中,一个或多个API还可以实现诸如以下的功能:接收用于验证或审计存储在与客户端相关联的区块链上的交易的请求,并向客户端设备340发送验证或审计结果。如在图4A和图4B中进一步详细讨论的,一个或多个API还可以实现诸如以下的其他功能:从客户端设备340接收交易或交易数据以及客户端签名,并发送账本签名,该账本签名指示承认接收或存储了交易或交易数据和/或客户端签名。
在一些实施例中,中心化账本系统310包括中心化服务器330。中心化服务器330可以与中心化账本系统310中的多个账本服务器320通信。在一些实施例中,账本服务器320通过中心化服务器330与客户端设备340通信。例如,中心化服务器330可以从客户端设备340接收数据,并且将数据发送给对应于(或分配给)客户端设备340的账本服务器320。
在一些实施例中,中心化服务器330可以维护用于中心化账本系统310的标准时间服务器,并且可以向账本服务器320提供内部时间戳(和/或关联签名)。例如,当账本服务器320生成新区块时,账本服务器320可以从中心化服务器330获得内部时间戳(和/或关联签名),并将内部时间戳(和/或关联签名)存储在新区块中。
在一些实施例中,每个账本服务器320通过中心化服务器330与可信时间服务器350通信。例如,账本服务器320可以向中心化服务器330发送原始时间戳请求,并且中心化服务器330可以向可信时间服务器350发送原始时间戳请求或与时间戳请求关联的中心化服务器时间戳请求,例如通过中心化服务器330中的中心化API。中心化服务器330可以向账本服务器320提供从可信时间服务器350获得的可信时间戳信息。在一些其他实施例中,如上所述,每个账本服务器320可以直接与可信时间服务器350通信,而无需中心化服务器330。
图4A是示出根据本文实施例的用于在与单个客户端相关联的单个账本服务器中实现可信时间戳服务的例如基于区块链的中心化账本系统400的账本系统的示例的示图。基于区块链的中心化账本系统400可以包括专用于向与客户端设备410相关联的单个客户端提供账本服务的单个账本服务器420。基于区块链的中心化账本系统400可以是图3的中心化账本系统310的示例。例如,账本服务器420可以是图3的账本服务器320-1的示例。客户端设备410可以是图3的客户端设备340-1的示例。在基于区块链的中心化账本系统400中,客户端使用客户端设备410访问账本服务器420提供的账本服务。账本服务器420还可以通过与可信时间服务器430通信来向客户端提供可信时间戳服务,该可信时间服务器430可以是例如图3的可信时间服务器350。
账本服务器420可以将账本服务和可信时间戳服务唯一地提供给客户端。账本服务器420可以将与客户端相关联的交易数据存储在唯一地用于客户端并且与中心化账本系统400中的其他客户端独立(或分开)的区块链中。账本服务器420可以请求并存储可信时间戳信息,该可信时间戳信息唯一地用于与存储在账本服务器420中的区块链中的客户端相关联的交易数据。客户端可以具有将交易存储在区块链中的管理权限。在一些情况下,客户端可以向第三方提供第二账本权限,该权限允许第三方将交易存储在与客户端相关联的区块链中。
在一些实施例中,当与客户端相关联的交易(或交易数据)被存储在账本服务器420中时,客户端可以使用客户端设备410向账本服务器420发送客户端签名。客户端签名可以指示客户端承认交易已经完成和/或将被存储在账本服务器420中。因此,客户无法否认交易。
在一些实施例中,在接收到交易(或交易数据)和/或将交易(或交易数据)存储在账本服务器420中(例如,在区块链中)之后,账本服务器420可以向客户端设备410发送账本签名。账本签名可以指示账本服务器420承认交易的接收和/或存储。因此,账本服务器420不能否认交易的存储。
在一些实施例中,账本服务器420可以向可信时间服务器430发送针对与客户端相关联并且存储在账本服务器420中的交易的时间戳请求。可信时间服务器430可以将用于交易的时间戳和关联签名提供给账本服务器420。时间戳签名可以包括交易的信息。因此,可信时间服务器430不能否认其对交易时间的背书以及用于交易的时间戳是可信的。
在一些实施例中,三个当事方(客户端、账本服务器和可信时间服务器)的三种对应的权利彼此独立,这可以增强存储在中心化账本系统中的交易数据的可信度和可审计性。
图4B是示出根据本文实施例的用于通过联合账本服务器向多个客户端提供可信时间戳服务的例如基于区块链的中心化账本系统450的账本系统的示例的示图。基于区块链的中心化账本系统450可以包括用于向客户端1至客户端n的多个客户端提供账本服务的单个联合账本服务器470。基于区块链的中心化账本系统450可以是图3的中心化账本系统310的另一示例。例如,联合账本服务器470可以是图3的账本服务器320的示例。客户端1至客户端n中的每个客户端可以与对应的客户端设备460-1至460-n相关联。在一些实施例中,客户端设备460-1至460-n可以是图3的客户端设备340-1或340-m的示例。在基于区块链的中心化账本系统450中,每个客户端可以使用其对应的客户端设备460来访问账本服务器420提供的账本服务。例如,客户端可以包括例如客户银行的多个金融机构。
每个客户端可以使用其关联的客户端设备将交易(或交易数据)存储在与其他客户端共享的联合区块链中。类似于图4A,每个客户端可以向账本服务器470发送对应的客户端签名,并且账本服务器470可以将相应的账本签名返回给客户端。账本服务器470可以向可信时间服务器430发送针对存储在联合区块链中的交易的时间戳请求,并且接收并存储针对联合区块链中的交易的时间戳信息。
图5A至5C是示出根据本文实施例的用于管理可信点的账本系统的示例的示意图。账本系统可以是基于区块链的账本系统,例如图1的联盟区块链网络102或图2的联盟区块链网络212,或图3的基于区块链的中心化账本系统310、图4A的基于区块链的中心化账本系统400或图5B的基于区块链的中心化账本系统450。账本系统也可以是没有区块链的账本系统。账本系统存储一系列记录。每个记录可以包括账本系统中的交易或区块链中的区块。为了说明的目的,将交易描述为记录的示例。
如图5A所示,例如TXi-5至TXi+3的一系列交易(TX)可以被存储在账本系统中,其中i是大于5的整数。每个交易可以具有对应的交易标识,例如,TXi的i,并且可以顺序地被添加(或存储)在账本系统中的一系列交易中。可以根据对应的交易标识将一系列交易按顺序存储在账本系统中。交易可以被链接或锚定在一起。例如,每个交易可以存储交易紧前的前一交易的例如对应的哈希值的信息,例如用于验证前一交易的可信性。
在一些实施例中,每个交易包括交易头和交易体。交易头可以包括本地时间戳、其自身的哈希和/或紧前的交易的哈希值。交易体可以包括交易的有效载荷信息,例如转账参与者、转账金额和/或转账时间或地点。本地时间戳指示交易被生成和/或添加到账本系统的时间点或实例。本地时间戳可由与账本系统相关联的服务器或与账本系统相关联的中央可信机构内部提供。
在一些实施例中,账本系统可以在一系列交易中建立可信点。可信点指示一系列交易中可信点之前的交易是可信的。当要验证一系列交易中的交易时,账本系统可以通过将交易追溯到交易之前的相邻的(例如,最近的)可信点来确定交易是可信的,而无需验证一系列交易中相邻可信点之前的交易。例如,如图5A所示,交易TXi是由账本系统建立的可信点。当账本系统验证交易TXi+3是否可信时,账本系统可能只需要验证交易TXi+3是否可以向后可信地追溯到可信点TXi,而无需验证交易TXi+3是否可以向后可信地追溯到TXi-1、TXi-2、…、TXi-5或一系列交易中甚至更早的交易。
账本系统可以确定一系列交易中的指定交易(例如,正在考虑的交易或感兴趣的交易)是否是可信点,例如,通过验证指定交易是否可以可信地追溯到先前可信点。先前可信点可以是一系列交易中指定交易之前的最近的可信点、指定交易之前的任何其他先前可信点,或者是作为一系列交易中所有可信点源的原始交易。
在一些实施例中,账本系统可以通过验证指定交易包括可追溯到可信点的信息来验证指定交易可以可信地追溯到可信点。可追溯信息可以包括例如紧前的交易的哈希值,紧前的交易的交易标识的哈希值,或可用于验证紧前的交易的真实性的任何其他类型的信息。例如,账本系统可以验证从一系列交易中的指定交易到先前可信点的每个交易,包括该交易紧前的前一交易的对应哈希值。使用图5A中的示例,给定交易TXi+3是指定交易,账本系统可以通过识别最近的可信点,即交易TXi并验证交易TXi+3可以向后可信地追溯到交易TXi+2,交易TXi+2可以向后可信地追溯到交易TXi+1,交易TXi+1可以向后可信地追溯到TXi,来验证交易TXi+3是可信的,而无需验证交易TXi+3是否可以向后可信地追溯到TXi-1、TXi-2、…、TXi-5。所述验证可以向前、向后或双向执行,例如,通过从一系列交易中的指定交易向后追溯到先前可信点或从一系列交易中的先前可信点向前追溯到指定交易。
在一些实施例中,账本系统可以以例如1小时、1天、1周、1个月或1年的时间段来周期性地建立一系列交易中的可信点。该时间段可以根据每一客户的请求或需求确定。例如,账本系统可以提供具有对应于不同时间段的不同费用的可信点服务。该时间段可以由与账本系统相关联的客户端(或用户)预先确定。客户端可以选择具有与对应费用相对应的相应时间段的可信点服务。
在一些实施例中,账本系统可能不会周期性地建立可信点。例如,账本系统可以根据需要或基于账本系统接收到的交易数量来建立可信点。例如,账本系统可以从客户端接收用于确定指定交易是否是可信点和/或在指定交易上或与指定交易相邻的交易上建立可信点的请求。在一些实施例中,账本系统还可以在接收到预定数量的交易时建立新的可信点,使得每隔预定数量的交易都存在一个可信点。
在一些实施例中,账本系统可以从可信时间服务器请求针对存储的交易的可信时间戳信息。可信时间服务器可以独立于账本系统并且与提供准确时间服务的第三方可信时间机构相关联,并且可以例如被公众、审计实体(例如公司、机构或组织)和/或法人实体(例如法院或政府)在全球范围内承认或信任。可信时间服务器可以是例如图3的时间服务器350或图4A至图4B的时间服务器430。随着可信时间服务器提供的时间戳信息的可信性被承认,将可信时间服务器的时间戳信息集成到账本系统中以用于存储的数据可以进一步增强存储在账本系统中的交易的可信度、可审计性和合法性。
账本系统可以向可信时间服务器发送时间戳请求。在一些示例中,时间戳请求包括由账本系统向可信时间服务器发送的多个时间戳请求中的时间戳请求的标识。在一些示例中,时间戳请求包括存储在一系列交易中的最近交易的标识或哈希值。在一些示例中,可以将多个交易视为一个单元或一组,并且账本系统可以请求针对该单元中的交易的可信时间戳信息。时间戳请求可以包括单元中交易的哈希值的哈希摘要。
在从可信时间服务器接收到针对时间戳请求的例如可信时间戳(TS)和关联签名的可信时间戳信息之后,账本系统可以存储可信时间戳信息,例如,作为新交易或添加到一系列交易中的另一交易中。可以通过存储一系列交易中最近交易的哈希值将新交易链接或锚定到一系列交易。可以将存储可信时间戳信息的新交易标注或标记为一系列交易中的新时间戳交易。新时间戳交易在一系列交易中最近交易紧后被存储。
在一些实施例中,账本系统可以将多个交易分组在一个单元中并且将时间戳交易作为最后一个交易包括在该单元中。在一些情况下,时间戳交易可被视为包括用于该单元中所有交易的被承认的可信时间戳信息。
例如,如图5B所示,交易TXi-4、TXi-3和TXi-2被视为一个单元。在一些实施例中,账本系统可以计算单元中三个交易的哈希值,并生成哈希值的哈希摘要。然后,账本系统可以发送时间戳请求,其包括单元中交易的哈希值的哈希摘要。在接收到针对时间戳请求的可信时间戳和关联签名之后,账本系统将可信时间戳和关联签名存储在新交易TXi-1中,该新交易TXi-1在最近交易TXi-2紧后被存储。交易TXi-1是存储来自可信时间服务器的可信时间戳信息的时间戳交易。交易TXi-1作为最后一个交易被包括在单元中,并且通过存储紧前的交易TXi-2的哈希值来链接到交易。在一些实施例中,时间戳交易TXi-1还可以存储单元中的交易(即TXi-4,TXi-3和TXi-2)的哈希值的哈希摘要,并且单元中的交易可以被认为具有与时间戳交易相同的可信戳。
类似地,交易TXi、TXi+1、TXi+2可以被视为一个单元。账本系统可以从可信时间服务器获得针对该单元的可信时间戳信息,并将可信时间戳信息存储在一系列交易中TXi+2紧后的交易TXi+3中。交易TXi+3是新时间戳交易,并且作为最后一个交易被包括在包括交易TXi、TXi+1和TXi+2的单元中。
在一些实施例中,两个相邻的时间戳交易之间的交易被认为具有与两个相邻的时间戳交易中的后一时间戳交易相同的可信时间戳。可以将交易和后一时间戳交易视为一个单元,并将后一时间戳交易视为该单元中的最后一个交易。
在一些实施例中,账本系统可以收集存储在一系列交易中第一时间戳交易之后的交易,并且向可信时间服务器发送包括所收集的交易的信息(例如,所收集的交易的哈希值的哈希摘要)的时间戳请求。在从可信时间服务器接收到可信时间戳和关联签名之后,账本系统将可信时间戳和关联签名存储在作为第二时间戳交易的新交易中。第一时间戳交易之后收集的交易可以被视为具有与第二时间戳交易相同的可信时间戳。所收集的交易和第二时间戳交易可以被视为一个单元。
在一些实施例中,账本系统可以以触发时间段周期性地向可信时间服务器发送时间戳请求。账本系统可以包括计时器,该计时器对发送第一时间戳请求之后的时间进行计数。当计时器计数到触发时间段时,可以触发账本系统向可信时间服务器发送第二时间戳请求。
在一些实施例中,账本系统可以不是周期性地向可信时间服务器发送时间戳请求。例如,账本系统可以在从客户端接收到指令时发送时间戳请求,或者在前一时间戳请求之后最近已经将预定数量的交易添加到一系列交易中时发送时间戳请求。例如,如图5B所示,账本系统可以每隔三个交易(例如TXi-4、TXi-3和TXi-2或者TXi、TXi+1和TXi+2)发送时间戳请求,并每隔三个交易生成时间戳交易,例如交易TXi-5、TXi-1和TXi+3。
图5C示出了根据本文实施例的管理时间戳交易上的可信点的账本系统的示例。在一些实施例中,账本系统可以接收用于针对指定交易建立可信点的请求。指定交易可以是也可以不是可信点。在一些实施例中,如果以下两个条件都满足,则账本系统可以将指定交易建立为可信点:(1)指定交易可以可信地追溯到一系列交易中的另一可信点,并且(2)指定交易是存储来自可信时间服务器的可信时间戳信息的时间戳交易。在一些实施例中,账本系统可以首先按顺序或并行验证所述两个条件。例如,账本系统可以例如通过验证指定交易可以可信地追溯到另一可信点来验证指定交易是可信点,然后确定指定交易是否是时间戳交易。在一些实施例中,账本系统可以首先确定指定交易是否是时间戳交易,然后确定指定交易是否可以可信地追溯到另一可信点。如果账本系统确定指定交易满足两个条件之一,则账本系统可以确定指定交易是候选可信点。只有账本系统确定两个条件指定交易都满足,账本系统才可以确定指定交易是可信点。
在一些实施例中,为了确定指定交易是否是时间戳交易,账本系统存储列出一系列交易中的时间戳交易(例如,通过列出对应的交易标识)的表格或另一适当的数据结构。账本系统可以搜索表格以确定指定交易是否在时间戳交易列表中。在一些实施例中,账本系统可以在表格或另一合适的数据结构中存储单元的信息,例如,每个单元中的交易的交易标识。账本系统可以通过确定指定交易的交易标识是相应单元中的最后一个交易标识来确定指定交易是否为时间戳交易。
如果账本系统确定指定交易是时间戳交易,则账本系统可以将指定交易标记为可信点,并将指定交易建立为可信点。账本系统还可以存储列出一系列交易中的可信点的表格或另一合适的数据结构。
如果账本系统确定指定交易不是时间戳交易,则账本系统可以不将指定交易标记为可信点。账本系统可以识别与指定交易相邻的时间戳交易,并将该时间戳交易标记为针对指定交易的可信点。与指定交易相邻的时间戳交易可以是在指定交易之前或之后的时间戳交易。例如,账本系统可以通过将包括指定交易的单元中的最后一个交易识别为时间戳交易,或者通过将包括指定交易的单元紧前的前一单元中的最后一个交易识别为时间戳交易,来识别相邻的时间戳交易。例如,如图5C所示,在账本系统确定交易TXi是可信点而不是时间戳交易之后,账本系统可以识别与交易TXi同一单元中的相邻的时间戳交易TXi+3或紧前的单元中的相邻的时间戳交易TXi-1。
在一些实施例中,可以将最接近指定交易的时间戳交易识别为针对指定交易的候选可信点。例如,账本系统可以通过识别与最接近于用于指定交易的交易标识的交易标识相关联的时间戳交易来识别一系列交易中的时间戳交易中的相邻的时间戳交易。
在将与指定交易相邻的时间戳交易识别为针对指定交易的候选可信点之后,账本系统例如通过确定时间戳交易是否包括可追溯到指定交易的信息来进一步确定时间戳交易是否可以可信地追溯到指定交易。在一些实施例中,账本系统通过验证一系列交易中从时间戳交易到指定交易的每个交易包括交易紧前的前一交易的相应哈希值,来确定时间戳交易可以可信地追溯到指定交易。例如,如图5C所示,为了确定交易TXi是否可以可信地追溯到时间戳交易TXi-1,账本系统可以确定交易TXi是否包括时间戳交易TXi-1的哈希值,例如,在交易TXi的交易头中。为了确定时间戳交易TXi+3是否可追溯到交易TXi,账本系统可以验证交易TXi+3是否包括交易TXi+2的哈希值,交易TXi+2是否包括交易TXi+1的哈希值以及交易TXi+1是否包括交易TXi的哈希值。在一些实施例中,如果配置了具有多个交易的单元,则账本系统通过验证时间戳交易是在与指定交易同一单元中的最后一个交易,或时间戳交易是紧前的单元中的最后一个交易来确定时间戳交易可以可信地追溯到指定交易。
如果账本系统确定时间戳交易可以可信地追溯到指定交易,则账本系统可以将时间戳交易而非指定交易标记为针对指定交易的可信点,并在时间戳交易上建立可信点。如果账本系统确定时间戳交易不可以可信地追溯到指定交易,则账本系统可以继续搜索另一相邻的时间戳交易并重复上述步骤。
在一些实施例中,账本系统可以将一系列交易存储在区块链中。例如,账本系统可以是图3的账本系统310。账本系统可以包括账本服务器,例如图3的账本服务器320、图4A的账本服务器320或图4B的账本服务器470。作为示例,区块链可以是图3的区块链322。账本系统可以顺序地生成将交易存储在区块链中的区块。每个区块可以存储一个或多个交易。例如,可通过存储区块链中区块紧前的前一区块的哈希值将每个区块链接或锚定在一起。账本系统可以以预定时间段周期性地或非周期性地(例如,根据需要或基于预定数量的交易)在区块链中生成区块。
账本系统生成区块可以独立于在账本系统中建立可信点而进行。账本系统生成区块还可以独立于向可信时间服务器发送时间戳请求和/或生成要存储在账本系统中的时间戳交易而进行。也就是说,区块的生成可以独立于分组为单元以从可信时间服务器获得可信时间戳信息而进行。例如,账本系统可以将交易TXi-4、TXi-3、TXi-2和TXi-1分组为一个单元,而账本系统可以生成存储交易TXi-5、TXi-4和TXi-3的区块。在一些实施例中,区块的生成可以与向可信时间服务器发送时间戳请求并生成时间戳交易相关联。例如,账本系统可以在针对单元中的交易生成时间戳交易之后生成区块,其中,该区块存储单元中的交易和时间戳交易。作为示例,账本系统可以生成存储交易TXi-4、TXi-3、TXi-2和TXi-1的区块。
在一些实施例中,账本系统对可信点的确定(或建立)可以独立于时间戳请求的发送和/或时间戳交易的生成。在一些实施例中,账本系统对可信点的确定可以与时间戳请求的发送和时间戳交易的生成相关联。例如,账本系统可以首先生成时间戳交易,然后确定是否可以将时间戳交易建立为可信点。
图6是示出可根据本文实施例执行的用于实现时间戳服务的处理600的示例的流程图。为方便起见,处理600将被描述为由位于一个或多个位置的、并根据本文被适当地编程的一个或多个计算机的系统执行。例如,账本系统可以执行处理600。账本系统可以是基于区块链的账本系统,例如图1的联盟区块链网络102或图2的联盟区块链网络212,或图3的基于区块链的中心化账本系统310,或者是没有区块链的账本系统。
在601处,例如通过账本系统中的计算设备获得用于针对账本系统中存储的一系列交易中的指定交易建立可信点的请求。指定交易可以是考虑中的或感兴趣的被识别的交易。例如,指定交易可以是一系列交易中的最近交易。可以指定该指定交易,例如,在智能合约中输入指定交易的标识,以调用识别针对指定交易的可信点的函数。
可信点指示一系列交易中可信点之前的交易是可信的。这样,验证一系列交易中待验证交易的真实性可以仅需要验证待验证交易与其最近的先前可信点之间的交易的真实性。
在一些实施例中,一系列交易中的每个交易与对应的交易标识相关联,并且一系列交易根据对应的交易标识按顺序被存储。一系列交易可以通过每个交易链接或锚定在一起,例如,存储一系列交易中交易紧前的前一交易的对应哈希值。
在一些实施例中,用于建立可信点的请求可以是由客户端根据需要生成的显式请求,或者是诸如在经过预定时间段或接收到一定数量的交易之后触发事件时的隐式请求。
在一些实施例中,类似于关于图5C所描述的,用于针对指定交易建立可信点的请求可能需要两个条件:(1)如关于602所述的,指定交易可以可信地追溯到一系列交易中的另一可信点,并且(2)如关于604至610所述的,指定交易可以可信地追溯到存储来自可信时间服务器的可信时间戳信息的时间戳交易。在一些实施例中,可以按顺序或并行地验证所述两个条件。如果账本系统确定指定交易满足两个条件之一,则账本系统可以确定指定交易是候选可信点。只有账本系统确定两个条件指定交易都满足,账本系统才可以确定指定交易是可信点。
在602处,确定指定交易是否可以可信地追溯到另一可信点。换句话说,确定指定交易本身是否是候选可信点。在一些实施例中,账本系统例如通过验证一系列交易中从指定交易到先前可信点的每个交易是否包括该交易紧前的前一交易的对应哈希值来确定指定交易是否是候选可信点。账本系统可以通过从一系列交易中的指定交易向后追溯到先前可信点或从先前可信点追溯到指定交易中的至少一项来验证指定交易是否可以可信地追溯到先前可信点。先前可信点可以是一系列交易中指定交易紧前的可信点,或者是作为一系列交易中的可信点源的第一个交易(或原始交易)。
账本系统可以周期性地在一系列交易中的交易上建立可信点。账本系统还可以根据需要或根据自紧前的可信点之后添加的交易的数量来建立可信点。账本系统还可以根据每个请求验证一系列交易中的交易是否为可信点。
在一些实施例中,账本系统将一系列交易存储在包括多个区块的区块链中。每个区块可以存储一个或多个交易,并通过在区块链中存储紧前的区块的哈希值将它们链接或锚定在一起。生成区块可以独立于建立可信点或将指定交易确定为可信点而进行。
在603处,响应于确定指定交易不是候选可信点,处理600结束。账本系统可以生成指示无法将指定交易建立为可信点的交易。该消息可以被发送回客户端设备或显示在屏幕上。
在604处,响应于确定指定交易是候选可信点,账本系统确定指定交易是否是存储来自可信时间服务器的可信时间戳信息的时间戳交易。可信时间服务器独立于账本系统,并且可以与第三方可信时间机构相关联。
在一些实施例中,账本系统可以向可信时间服务器发送时间戳请求。时间戳请求可以包括向可信时间服务器发送的时间戳请求中的时间戳请求的标识。时间戳请求可以包括交易标识或一系列交易中最近交易的哈希值。时间戳请求还可以包括单元中的交易的哈希值的哈希摘要。该单元收集存储在一系列交易中的自紧前的时间戳交易起的交易。
在从可信时间服务器接收到针对时间戳请求的可信时间戳和关联签名之后,账本系统可以将可信时间戳和关联签名作为交易存储在一系列交易中。可以将存储来自可信时间服务器的可信时间戳和关联签名的交易标记为新时间戳交易。当时间戳请求被发送时,新时间戳交易可以被存储在一系列交易中最近交易紧后。可通过存储最近交易的哈希值将新时间戳交易与一系列交易链接。在一些实施例中,新时间戳交易可以在包括最近交易的单元中存储交易的哈希值的哈希摘要。单元中的交易可以被视为具有与新时间戳交易相同的可信时间戳。新时间戳交易可以作为最后一个交易被包括在该单元中。
在一些实施例中,账本系统可以以预定触发时间段周期性地向可信时间服务器发送时间戳请求。账本系统还可以非周期性地(例如,根据需要或基于紧前的时间戳请求之后收集的预定数量的交易)向可信时间服务器发送时间戳请求。时间戳请求的发送可以独立于区块的生成和/或可信点的建立。
在606处,响应于确定指定交易是时间戳交易,账本系统将指定交易标记为可信点,即,账本系统在指定交易上建立可信点。
在608处,响应于确定指定交易不是时间戳交易,账本系统识别一系列交易中与指定交易相邻的时间戳交易。在一些实施例中,账本系统可以通过将包括指定交易的单元中的最后一个交易识别为时间戳交易,或者通过将包括指定交易的单元紧前的前一单元中的最后一个交易识别为时间戳交易,来识别时间戳交易。在一些实施例中,账本系统存储列出一系列交易中的时间戳交易的交易标识的表格。账本系统可以通过识别与相比于一系列交易中的任何其他时间戳交易相关联的任何其他交易标识更接近指定交易的交易标识的交易标识相关联的时间戳交易,来识别与指定交易相邻的时间戳交易。
在610处,账本系统确定时间戳交易是否可以可信地追溯到指定交易。在一些实施例中,如果时间戳交易在一系列交易中的指定交易之后,则账本系统可以验证时间戳交易是否包括指定交易的信息,或者如果时间戳交易在一系列交易中的指定交易之前,则账本系统可以验证指定交易是否包括时间戳交易的信息。在一些实施例中,账本系统可以验证一系列交易中从时间戳交易到指定交易的每个交易是否包括该交易紧前的前一交易的对应哈希值。如果账本系统验证一系列交易中从时间戳交易到指定交易的每个交易包括该交易紧前的前一交易的对应哈希值,则账本系统可以确定时间戳交易可以可信地追溯到指定交易。如果账本系统不能验证一系列交易中从时间戳交易到指定交易的每个交易包括该交易紧前的前一交易的对应哈希值,则账本系统可以确定时间戳交易不可以可信地追溯到指定交易。
响应于确定时间戳交易不可以可信地追溯到指定交易,处理600返回到步骤608,并且账本系统可以继续识别可以可信地追溯到指定交易的相邻的时间戳交易。
在612处,响应于确定时间戳交易可以可信地追溯到指定交易,账本系统将时间戳交易标记为一系列交易中的可信点。也就是说,账本系统将时间戳交易建立为针对指定交易的可信点。
在614处,账本系统接收用以验证一系列交易中的待验证交易的请求。例如,可以从客户端接收该请求。待验证交易可以是客户端感兴趣的交易。待验证交易可以是存储在一系列交易中指定交易之前或之后的交易。
在616处,账本系统通过验证该交易可以可信地追溯到一系列交易中该交易之前的最近的可信点来确定交易被验证。由于最近的可信点是可信的,因此确定交易被验证无需验证一系列交易中最近的可信点之前的交易。例如,如果待验证交易是一系列交易中的指定交易之后的交易,则账本系统可以通过验证待验证交易是否可以可信地追溯到被标记为可信点的时间戳交易来确定待验证交易被验证,而无需验证一系列交易中时间戳交易之前的交易。
图7描绘了根据本文的实施例的装置700的模块的示例。装置700可以是账本系统的实施例的示例,该账本系统被配置为针对存储在账本系统中的交易数据提供账本服务、可信时间戳服务和可信点服务。装置700可以对应于上述实施例,装置700包括以下:获得模块701,用于由账本系统中的计算设备获得用以针对存储在账本系统中的一系列记录中的指定记录建立可信点的请求,所述可信点指示一系列记录中可信点之前的记录是可信的;第一确定模块702,用于确定存储在账本系统中的一系列记录中的指定记录是否是候选可信点;第二确定模块704,用于由计算设备确定指定记录是否是包括来自可信时间服务器的可信时间戳信息的时间戳记录,所述可信时间服务器与可信时间机构相关联并且独立于账本系统;识别模块706,用于响应于确定指定记录不是时间戳记录,识别一系列记录中的时间戳记录中与指定记录相邻的时间戳记录;第三确定模块708,用于由计算设备确定时间戳记录是否可以可信地追溯到指定记录;以及标记模块,用于响应于确定时间戳记录可以可信地追溯到指定记录,将时间戳记录标记为一系列记录中的可信点。
在一些实施例中,装置700还包括接收模块712,用于接收用以验证该一系列记录中的待验证记录的请求,以及第四确定模块714,用于通过确定待验证记录可以可信地追溯到待验证记录之前的最近的可信点来确定待验证记录被验证,而无需验证一系列记录中的最近的可信点之前的记录。在一些实施例中,第一确定模块702、第二确定模块704、第三确定模块708和第四确定模块714中的一个或多个可以被实现为单个模块。
在一些实施例中,一系列记录中的每个记录包括对应的交易。在一些实施例中,一系列记录中的每个记录包括对应的区块,并且一系列记录形成区块链。
在一些实施例中,一系列记录中的每个记录包括一系列记录中该记录紧前的前一记录的对应哈希值。
在一些实施例中,第三确定模块708被配置为通过以下至少一项确定时间戳记录可以可信地追溯到指定记录:验证时间戳记录包括可追溯到指定记录并认证指定记录的信息,或验证指定记录包括可追溯到时间戳记录并认证时间戳记录的信息。
在一些实施例中,第三确定模块708被配置为:通过验证一系列记录中从时间戳记录到指定记录的每个记录包括该记录紧前的前一记录的对应的哈希值,来确定时间戳记录可以可信地追溯到指定记录。
在一些实施例中,第一确定模块702被配置为:通过验证指定记录可以可信地追溯到一系列记录中指定记录紧前的先前可信点,来确定一系列记录中的指定记录为可信点。
在一些实施例中,装置700包括验证模块,其被配置为通过验证从一系列记录中的指定记录到先前可信点的每个记录包括该记录紧前的前一记录的对应的哈希值,来验证指定记录可以可信地追溯到该指定记录之前的先前可信点。
在一些实施例中,先前可信点是一系列记录中指定记录紧前的可信点和作为一系列记录的可信点源的第一记录中的一个。
在可选实施例中,验证模块被配置为通过以下方式中的至少一个来验证指定记录可以可信地追溯到一系列记录中指定记录之前的先前可信点:从一系列记录中的指定记录向后追溯到先前可信点,或者从一系列记录中的先前可信点向前追溯到指定记录。
在一些实施例中,装置700还包括:发送模块,用于向可信时间服务器发送时间戳请求;第二接收模块,用于从可信时间服务器接收针对时间戳请求的可信时间戳和关联签名;以及存储模块,用于将可信时间戳和关联签名作为记录存储在一系列记录中。存储来自可信时间服务器的可信时间戳和关联签名的所述记录是一系列记录中的新时间戳记录,并且当时间戳请求被发送时,新时间戳记录被存储在一系列记录中存储的最近记录紧后,并且该新时间戳记录包括最近记录的哈希值。
在一些实施例中,一系列记录中的新时间戳记录与新时间戳记录紧前的前一时间戳记录之间的记录被分组在一个单元中,并且新时间戳记录作为最后一个记录被包括在该单元中。
在一些实施例中,时间戳请求包括以下中的至少一个:向可信时间服务器发送的时间戳请求中的时间戳请求的标识,最近记录的标识或哈希值,或单元中的记录的哈希值的哈希摘要。
在一些实施例中,识别模块706被配置为:通过将包括指定记录的单元中的最后一个记录识别为时间戳记录,或者通过将包括指定记录的单元紧前的前一单元中的最后一个记录识别为时间戳记录,来识别时间戳记录。
在一些实施例中,第一确定模块702确定一系列记录中的第二记录是第二可信点,第二确定模块704确定第二记录是一系列记录中的时间戳记录,以及标记模块710将第二记录标记为一系列记录中的第二可信点。
在一些实施例中,新时间戳记录包括该单元中的记录的哈希值的哈希摘要。
在一些实施例中,装置700还包括发送模块,用于针对时间戳请求以预定时间段周期性地向可信时间服务器发送时间戳请求。
在一些实施例中,装置700还包括生成模块,用于顺序地生成将一系列记录存储在区块链中的区块,每个区块存储一个或多个记录并在区块链中链接在一起。生成区块链中的区块独立于确定指定记录是可信点而进行,并且独立于向可信时间服务器发送时间戳请求而进行。
在一些实施例中,一系列记录中的每个记录与对应的记录标识相关联,并且根据对应的记录标识按顺序地存储该一系列记录,并且识别模块706通过识别一系列记录中与最接近该指定记录的记录标识的记录标识相关联的时间戳记录,来识别与一系列记录中的时间戳记录中与指定记录相邻的时间戳记录。
在一些实施例中,确定存储在账本系统中的一系列记录中的指定记录是候选可信点独立于向可信时间服务器发送时间戳请求而进行。
在一些实施例中,响应于确定指定记录不是包括来自可信时间服务器的可信时间戳信息的时间戳记录,不将指定记录标记为一系列记录中的可信点。
前述实施例中示出的系统、装置、模块或单元可以通过使用计算机芯片或实体来实施,或者可以通过使用具有特定功能的产品来实施。典型的实施例设备是计算机,计算机可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能手机、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或这些设备的任意组合。
对于装置中每个模块的功能和作用的实施例处理,可以参考前一方法中相应步骤的实施例处理。为简单起见,这里省略了细节。
由于装置实施基本上对应于方法实施,对于相关部件,可以参考方法实施中的相关描述。前一描述的装置实施仅是示例。被描述为单独部分的模块可以或不是物理上分离的,并且显示为模块的部分可以是或不是物理模块,可以位于一个位置,或者可以分布在多个网络模块上。可以基于实际需求来选择一些或所有模块,以实现本文方案的目标。本领域的普通技术人员无需付出创造性劳动就能理解和实现本申请的实施例。
再次参见图7,它可以被解释为示出了账本实现装置的内部功能模块和结构。账本实现装置是被配置为针对存储在账本系统中的记录(例如,交易数据)提供账本服务、可信时间戳服务以及可信点服务的账本系统的示例。执行主体本质上可以是电子设备,并且该电子设备包括以下:一个或多个处理器;以及被配置为存储一个或多个处理器的可执行指令的一个或多个计算机可读存储器。在一些实施例中,一个或多个计算机可读存储器耦接至一个或多个处理器且其上存储有编程指令,所述编程指令能够由所述一个或多个处理器执行以执行如本文中所述的算法、方法、函数、处理、流程和程序。本文还提供了一个或多个非暂态计算机可读存储介质,其耦接到一个或多个处理器并且具有存储在其上的指令,当由一个或多个处理器执行时,该指令使得一个或多个处理器根据这里提供的方法的实施例执行操作。
本文还提供了用于实现本文提供的方法的系统。该系统包括一个或多个处理器,以及耦接到一个或多个处理器的计算机可读存储介质,其上存储有指令,当由一个或多个处理器执行时,该指令使得一个或多个处理器根据这里提供的方法的实施例执行操作。
本文中描述的主题、动作和操作的实施可以在数字电子电路、有形体现的计算机软件或固件、计算机硬件中实施,包括本文中公开的结构及其结构等同物,或者它们中的一个或多个的组合。本文中描述的主题的实施可以实现为一个或多个计算机程序,例如,编码在计算机程序载体上的一个或多个计算机程序指令模块,用于由数据处理装置执行或控制数据处理装置的操作。例如,计算机程序载体可以包括一个或多个计算机可读存储介质,其上编码或存储有指令。载体可以是有形的非暂态计算机可读介质,诸如磁盘、磁光盘或光盘、固态驱动器、随机存取存储器(RAM)、只读存储器(ROM)或其他类型的介质。可选地或附加地,载体可以是人工生成的传播信号,例如,机器生成的电信号、光信号或电磁信号,其被生成来编码信息用于传输到合适的接收器装置以供数据处理装置执行。计算机存储介质可以是或可以部分是机器可读存储设备、机器可读存储基板、随机或串行访问存储器设备或它们中的一个或多个的组合。计算机存储介质不是传播信号。
计算机程序,也可以被称为或描述为程序、软件、软件应用程序、app、模块、软件模块、引擎、脚本或代码,可以以任何形式的编程语言编写,包括编译或解释性语言、或声明或程序性语言;它可以配置为任何形式,包括作为独立程序,或作为模块、组件、引擎、子程序或适合在计算环境中执行的其他单元,该环境可包括由数据通信网络互连的一个或多个位置上的一个或多个计算机。
计算机程序可以但非必须对应于文件系统中的文件。计算机程序可以存储在:保存其他程序或数据的文件的一部分中,例如,存储在标记语言文档中的一个或多个脚本;专用于所讨论的程序的单个文件中;或者多个协调文件中,例如,存储一个或多个模块、子程序或代码部分的多个文件。
用于执行计算机程序的处理器包括:例如,通用和专用微处理器两者,和任意种类的数字计算机的任意一个或多个处理器。通常,处理器将接收用于执行的计算机程序的指令以及来自耦接至处理器的非暂态计算机可读介质的数据。
术语“数据处理装置”包括用于处理数据的所有种类的装置、设备和机器,例如包括可编程处理器、计算机或多个处理器或计算机。数据处理设备可以包括例如FPGA(现场可编程门阵列),ASIC(专用集成电路)或GPU(图形处理单元)的专用逻辑电路。除了硬件,该装置还可以包括为计算机程序创建执行环境的代码,例如,构成处理器固件、协议栈、数据库管理系统、操作系统或者它们中一个或多个的组合的代码。
本文中描述的处理和逻辑流程可以由执行一个或多个计算机程序的一个或多个计算机或处理器执行,以通过对输入数据进行操作并生成输出来执行操作。处理和逻辑流程也可以由例如FPGA、ASIC或GPU等的专用逻辑电路或专用逻辑电路与一个或多个编程计算机的组合来执行。
适合于执行计算机程序的计算机可以基于通用和/或专用微处理器,或任何其他种类的中央处理单元。通常,中央处理单元将从只读存储器和/或随机存取存储器接收指令和数据。计算机的元件可包括用于执行指令的中央处理单元和用于存储指令和数据的一个或多个存储设备。中央处理单元和存储器可以补充有专用逻辑电路或集成在专用逻辑电路中。
通常,计算机还将包括或可操作地耦接至一个或多个存储设备,以从一个或多个存储设备接收数据或向一个或多个存储设备传送数据。大容量存储设备可以是例如,磁盘、磁光盘或光盘、固态驱动器或任何其他类型的非暂态计算机可读介质。但是,计算机不必需这样的设备。因此,计算机可以耦接到例如一个或多个存储器的本地和/或远程的一个或多个大容量存储设备。例如,计算机可以包括作为计算机的组成部件的一个或多个本地存储器,或者计算机可以耦接到云网络中的一个或多个远程存储器。此外,计算机可以嵌入在另一设备中,例如移动电话、个人数字助理(PDA)、移动音频或视频播放器、游戏控制台、全球定位系统(GPS)接收器或例如通用串行总线(USB)闪存驱动器的便携式存储设备,这里仅举几例。
组件可以通过直接或经由一个或多个中间件例如电连接或光连接地彼此连接通信而彼此“耦接”。如果部件中的一个部件被集成到另一个中,则部件也可以被彼此“耦接”。例如,集成到处理器中的大容量存储组件(例如,L2高速缓存组件)被“耦接到”处理器。
为了提供与用户的交互,本文中描述的主题的实施例可以在计算机上实现或配置为与该计算机通信,该计算机具有:显示设备,例如,LCD(液晶显示器)监视器,用于向用户显示信息;以及输入设备,用户可以通过该输入设备向计算机提供输入,例如键盘和例如鼠标、轨迹球或触摸板等的指针设备。其他类型的设备也可用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的感官反馈,例如视觉反馈、听觉反馈或触觉反馈;并且可以接收来自用户任何形式的输入,包括声音、语音输入或触觉输入。此外,计算机可以通过向用户使用的设备发送文档和从用户使用的设备接收文档来与用户交互;例如,通过向用户设备上的web浏览器发送web页面以响应从web浏览器收到的请求,或者通过与例如智能电话或电子平板电脑等的用户设备上运行的应用程序(app)进行交互。此外,计算机可以通过向个人设备(例如,运行消息收发应用程序的智能手机)轮流发送文本消息或其他形式的消息来并且从用户接收响应消息来与用户交互。
本文使用与系统,装置和计算机程序组件有关的术语“配置为”。对于被配置为执行特定操作或动作的一个或多个计算机的系统,意味着系统已经在其上安装了在运行中促使该系统执行所述操作或动作的软件、固件、硬件或它们的组合。对于被配置为执行特定操作或动作的一个或多个计算机程序,意味着一个或多个程序包括当被数据处理装置执行时促使该装置执行所述操作或动作的指令。对于被配置为执行特定操作或动作的专用逻辑电路,意味着该电路具有执行所述操作或动作的电子逻辑。
虽然本文包含许多具体实施细节,但是这些细节不应被解释为由权利要求本身限定的对要求保护的范围的限制,而是作为对特定实施例的具体特征的描述。在本文中单个实施例的上下文中描述的多个特征也可以在单个实施例中组合实现。相反,在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合在多个实施例中实现。此外,尽管上面的特征可以描述为以某些组合起作用并且甚至最初如此要求保护,但是在一些情况下可以从要求保护的组合中删除该组合的一个或多个特征,并且可以要求保护指向子组合或子组合的变体。
类似地,虽然以特定顺序在附图中描绘了操作并且在权利要求中叙述了操作,但是这不应该被理解为:为了达到期望的结果,要求以所示的特定顺序或依次执行这些操作,或者要求执行所有示出的操作。在某些情况下,多任务和并行处理可能是有利的。此外,上述实施例中的各种系统模块和组件的划分不应被理解为在所有实施例中都要求如此划分,而应当理解,所描述的程序组件和系统通常可以一起集成在单个软件产品中或打包成多个软件产品。
已经描述了主题的特定实施方式。其他实施方式在以下权利要求的范围内。例如,权利要求中记载的动作可以以不同的顺序执行并且仍然实现所期望的结果。作为一个示例,附图中描绘的过程无需要求所示的特定顺序或次序来实现期望的结果。在一些情况下,多任务并行处理可能是有利的。