事件认证方法和装置与流程

本发明涉及通信的技术领域，尤其涉及一种事件认证方法和装置。

背景技术：

随着通信技术的快速发展，有形的物品、无形的事件信息等会被抽象为数字信息。数字化信息极大方便了信息的传播和处理，但信息是否合法、是否完整一直困扰着人们。目前，人们主要是通过第三方的机构对事件信息进行认证。然而，第三方的机构的服务器相对集中，故容易受到网络的攻击而导致网络瘫痪。另外，第三方的机构由于自身能力的局限性，会存在认证偏差、认证程序繁琐和认证时间长，甚至会出现第三方的机构擅自篡改数据等问题。

技术实现要素：

鉴于以上所述的一个或多个问题，本发明提供了一种事件认证方法和装置。

第一方面，本发明实施例提出了一种事件认证方法，该方法包括：

采集待认证事件的相关信息；

在所述相关信息满足所述待认证事件的触发条件时，产生对所述待认证事件进行认证的请求；

响应于所产生的请求，从区块链中检索与所请求的认证事件相关联的历史记录；

基于所述历史记录，对所述认证事件进行认证。

第二方面，本发明实施例提出了一种事件认证方法，该方法包括：

接收对认证结果的进行校验的请求，认证结果是对待认证事件进行认证所生成的结果；

响应于所接收的校验请求，从区块链中检索与待认证事件相关联的历史记录；

基于历史记录，对认证结果进行校验。

第三方面，本发明实施例提出了一种事件认证装置，该装置包括：

信息采集单元，用于采集待认证事件的相关信息；

请求生成单元，用于在相关信息满足待认证事件的触发条件时，产生对待认证事件进行认证的请求；

记录检索单元，响应于所产生的请求，从区块链中检索与所请求的认证事件相关联的历史记录；

事件认证单元，基于历史记录，对认证事件进行认证。

第四方面，本发明实施例提出了一种事件认证装置，该装置包括：

请求接收单元，用于接收对认证结果的进行校验的请求，认证结果是对待认证事件进行认证所生成的结果；

记录检索单元，响应于所接收的校验请求，从区块链中检索与待认证事件相关联的历史记录；

结果校验单元，基于历史记录，对认证结果进行校验。

由此，本实施例可以通过将所采集的事件信息与预设的事件信息相比较，自动触发事件认证的流程，解决了现有的认证程序繁琐、认证时间长、认证不客观的问题。之后，根据区块链中的历史记录，对认证信息进行认证。因为区块链中的数据需要网络共识才可以写入，且一旦数据写入就无法更改，因此，利用区块链中的历史记录，对认证信息进行认证，解决了现有的认证安全级别低和可靠性低等问题。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例的事件认证方法的流程示意图。

图2是图1中的区块链与节点通信的示意图。

图3是本发明另一实施例的事件认证方法的流程示意图。

图4是本发明一实施例的事件认证装置的结构示意图。

图5是本发明另一实施例的事件认证装置的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合，各实施例中的内容可以相互参考和引用。下面将参考附图并结合实施例来详细说明本申请。

图1是本发明一实施例的事件认证方法的流程示意图。

如图1所示，该认证方法包括以下步骤：S110，采集待认证事件的相关信息；S120，在相关信息满足待认证事件的触发条件时，产生对待认证事件进行认证的请求；S130，响应于所产生的请求，从区块链中检索与所请求的认证事件相关联的历史记录；S140，基于历史记录，对认证事件进行认证。

在S110中，待认证的事件例如可以是被抽象为数字信息的事件。该事件可以与现实中的事件相对应。数据信息可以包括时间参数和地点参数等。采集相关信息的方式可以通过被动接收热点推送的方式获取，也可以通过在互联网中主动查询的方式获取。此方面内容不做限制。

在S120中，相关信息满足待认证事件的触发条件可以通过将所采集的相关信息与预设的事件信息相比较来实现。例如，比较二者的时间参数和地点参数等。当二者一致时，满足触发条件，产生对待认证事件进行认证的请求。当二者不一致时，不满足触发条件，此时不产生对待认证事件进行认证的请求。上述触发过程可以自动完成。

在一些实施例中，相关信息为自动采集的可靠信息。在另一些实施例中，相关信息为用户节点提交的信息。

在S130中，历史记录可以包括：与认证信息相关联的节点(例如认证对象节点)的注册信息、用于认证该认证事件的认证规则。其中，认证规则可以是当认证的事件满足预定条件时，通过认证。

在S140中，基于历史记录，对认证信息进行认证可以是比较认证的过程，例如，基于认证规则进行认证，当只有符合认证规则时才通过认证。又例如，认证对象是否有不良记录，当认证对象有不良记录时，取消认证资格等。

本实施例是从平台节点侧的认证角度进行撰写，上述各步骤的实施主体可以是平台节点(即认证节点)。可以理解，在其它的实施例中，还可以从其他节点的角度进行撰写。

由此，本实施例可以通过将所采集的事件信息与预设的事件信息相比较，自动触发事件认证的流程，解决了现有的认证程序繁琐、认证时间长、认证不客观等问题。另外，基于区块链中的无法篡改的可靠性较高的历史记录进行认证，认证结果可靠性高、安全节点高。

图2是图1中的区块链与节点通信的示意图。

如图2所示，节点200可以是与认证事件相关联的节点，具体可以是用户节点(可以是认证对象节点)、平台节点(认证节点)、监管机构节点等，此方面内容不做限制。节点200可以与区块链100进行数据交互。具体的，数据交互的内容可以是对事件进行认证的相关内容。具体交互的数据可以分别按时间顺序记录至区块链100中。例如，原始记录、补充记录、认证记录等，这些记录可以构成动态增加的历史记录。这些历史记录可以分别按时间顺序记录至区块链的不同存储区块内。该区块还可以记录了当前区块的HASH(哈希)值、前一区块的HASH值和时间戳等信息。其中HASH值是HASH算法将任意长度的二进制值映射为固定长度的较小二进制值。

由此，本实施例可以通过将所采集的事件信息与预设的事件信息相比较，自动触发事件认证的流程，解决了现有的认证程序繁琐、认证时间长、认证不客观的问题。之后，根据区块链中的历史记录，对认证信息进行认证。因为区块链中的数据需要网络共识才可以写入，且一旦数据写入就无法更改，因此，利用区块链中的历史记录，对认证信息进行认证，解决了现有的认证安全级别低和可靠性低等问题。

因为本实施例事件认证的安全级别非常高，因此本实施例可以应用于相互保险的场景中。其中，相互保险是当今世界保险市场上最主要的形式之一，它是指由一些对同一危险有某种保障要求的人所组成的组织，以互相帮助为目的，实行“共享收益，共摊风险”。成员交纳保费形成基金，发生灾害损失时用这笔基金来弥补灾害损失。目前，相互保险体系存在的如下问题：一是相互保险组织会员之间的信任问题尚未彻底解决；二是投保人会员与相互保险运营机构之间的存在信任问题；三是交易的确认、保单的确权、投票的公开透明、履约信用的评级和公开透明存在问题。

下面以航空保险为例，具体说明本实施例的事件认证方法的实现方式。

步骤1，用户节点可以通过保险平台节点创建智能航班延误险合约，该合约可以规定当航班延误时，就可以获取预定数额的保险赔偿。保险平台节点与互联网相连，可以获取航班的公开数据。

步骤2，通过获取的航班的公开数据与预定的航班数据相比较。

步骤3，当确定航班延误时，智能合约即被触发，即触发保险理赔的流程。

步骤4，响应于保险理赔的请求，从区块链中检索：智能航班延误险合约、投保人节点的注册信息、理赔条件等历史记录。

步骤5，根据历史记录对认证信息进行认证，自动完成支付理赔。

由此，本实施例可以自动和及时的保单处理，既实现了高效的理赔，也减少了理赔处理的成本，同时，增加了客户和保险公司双方的满意度。

另外，本实施例还可以应用于智能车险合约。保险平台可以通过网络与车相连，通过区块链技术储存车辆状态数据，一旦汽车发生事故，触发智能车险合约，开始进入理赔阶段。在智能合约里，还可以指定车主修车地点，避开投保人自行选择昂贵的维修厂，进而控制理赔费用的支出。

本实施例将区块链技术应用于相互保险服务，一方面，可以通过区块链记录会员信息、保险记录、保险凭证等信息，提升会员之间、会员与运营机构之间的信任度。另一方面，可以通过区块链共识过程，实现交易确认、保单确权、投票确认、信用评级等关键环节，保证这些环节的透明性。此外，基于区块链的相互保险服务可以降低保险参与成本，增强保险经营的灵活性。

作为图1实施例的第一个变形实施例，可以在图1实施例的基础上增加以下步骤：基于对认证事件进行认证的情况，生成认证结果；向节点集群群体发送对认证结果进行校验的请求，节点集群包括多个用户节点。

由此，本实施例可以在认证的基础上，群发校验请求，使得认证经过群体校验，进一步增加了认证的可靠性和准确性。

作为图1实施例的第二个变形实施例，可以在图1的第一个变形实施例的基础上增加以下步骤：接收来自节点集群中的至少一个节点的校验反馈，校验反馈包括：认证结果正确或者错误的反馈；根据校验反馈判定认证结果是否通过校验。

由此，本实施例可以在认证的基础上，再经过认证校验，获取校验反馈，进一步增加了认证的可靠性和准确性。

作为图1实施例的第三个变形实施例，可以在图1的基础上增加以下步骤：当相关信息为自动采集的可靠信息时，基于可靠信息对所请求的认证事件进行认证，并生成第一认证结果；将可靠信息和第一认证结果记录在区块链中。

作为图1实施例的第四个变形实施例，可以在图1的基础上增加以下步骤：当相关信息为用户节点提交的信息时，基于提交的信息对认证事件进行认证，并生成第二认证结果；将用户节点提交的信息和第二认证结果记录在区块链中。

在一些实施例中，事件认证方法在上述各实施例的基础上还可以包括以下步骤：基于校验反馈，生成认证事件的第一补充记录；将第一补充记录存储在区块链中。

由此，本实施例可以通过将校验反馈作为补充记录，将补充记录与历史信息相关联地储至区块链中，可以丰富检索的信息，进而可以为后期的事件认证或者信息校验提供了足够的依据，并且随着数据量的增加，后期的认证精度或者校验精度会随之提高。

在一些实施例中，事件认证方法在上述各实施例的基础上还可以包括以下步骤：根据预设的关键字在区块链中进行信息检索，获取与关键字相关联的至少两条关键信息；对比至少两条关键信息，并筛选出相互冲突的关键信息；向节点集群群体发送验证所筛选出的相互冲突的关键信息的验证请求。

本实施例主要描述了对区块链中记录的信息进行校验的机制。该校验机制可以定期执行。一旦发现问题，将在区块链发布证据信息，并向所有区块链用户发布用户虚假警告信息，该虚假用户会被全网用户发现并受到惩罚。具体的，定期校验机制的工作原理可以如下：

首先，设置平台节点校验参数。

具体的，参数可以是校验频率(一天一次)、校验范围(全网用户或注册某时间段的用户)、校验方式(平台独立校验还是平台用户联合校验)等。比如，一天进行一次全网用户节点的信息校验。

其次，平台节点独立校验过程。

平台节点会借助第三方数据库等方式校验用户信息数据，然后将校验结果和校验凭证(结果判断依据)上传至区块链，并获得全网用户节点共识，以此完成用户信息校验过程；普通用户节点也可以进行用户信息校验，普通用户节点通过查询区块链历史数据，获取感兴趣的用户节点的信息进行校验，并将校验结果和校验凭证(结果判断依据)上传至区块链，并获得全网用户共识，以此完成用户信息校验过程。

由此，本实施例可以通过信息校验的机制，查出区块链中的不实数据，进一步提升了区块链中用于认证的原始数据的真实性。在原始数据真实可靠的基础上，通过该数据进行认证，可以确保认证的准确性和可靠性。

在一些实施例中，事件认证方法在上述各实施例的基础上还可以包括以下步骤：向节点集群群体发送对认证事件的认证对象节点的信用进行评定的请求。

由此，本实施例可以通过对节点的信用进行评定，可以保证节点的信用，进而，可以保证该节点在区块链中的通信数据信息的真实性。

在一些实施例中，事件认证方法在上述各实施例的基础上还可以包括以下步骤：接收来自节点集群中的至少一个节点的评定反馈；根据评定反馈，生成认证事件的第二补充记录；将第二补充记录存储至区块链中。

由此，本实施例可以通过将评定反馈作为补充记录，将补充记录与历史信息相关联地储至区块链中，可以丰富检索的信息，进而可以为后期的事件认证或者信息校验提供了足够的依据，并且随着数据量的增加，后期的认证精度或者校验精度会随之提高。

图3是本发明另一实施例的事件认证方法的流程示意图。

如图3所示，事件认证方法可以包括以下步骤：S310，接收对认证结果的进行校验的请求；S320，响应于所接收的校验请求，从区块链中检索与待认证事件相关联的历史记录；S330，基于历史记录，对认证结果进行校验。

在S310中，认证结果可以是对待认证事件进行认证所生成的结果。

在S320中，历史记录可以包括：与认证信息相关联的节点(例如认证对象节点)的注册信息、用于认证该认证事件的认证规则。其中，认证规则可以是当认证的事件满足预定条件时，通过认证。

在S330中，基于历史记录，对认证结果进行校验。

基于历史记录，对认证信息进行校验可以是比较认证的过程，例如，基于认证规则进行认证校验，当只有符合认证规则时才通过校验。又例如，认证对象是否有不良记录，当认证对象有不良记录时，取消校验资格等。

本实施例是从用户节点或者监管节点侧的认证角度进行撰写，上述各步骤的实施主体可以是用户节点或者监管节点。可以理解，在其它的实施例中，还可以从其他节点的角度进行撰写。

由此，通过在认证的基础上进行校验，增加了认证的可靠性。

作为图3实施例的第一个变形实施例，可以在图3实施例的基础上增加以下步骤：基于对认证结果进行校验的情况，生成校验反馈；发送校验反馈，校验反馈包括：认证结果正确或者错误的反馈。

作为图3实施例的第二个变形实施例，可以在图3实施例的基础上增加以下步骤：采集待认证事件的相关信息；基于所采集的相关信息，生成待认证事件的补充记录；将补充记录和校验反馈储至区块链中。

下面以对相互保险数据进行理赔为例，详细说明事件认证的实现方式。

步骤1，对具有同质风险保障需求的个人或企业用户节点所提交个人或企业用户信息等进行资质审核。

首先，具有同质风险保障需求的个人或企业用户节点，向基于区块链的相互保险平台节点(该平台节点可以设置有一套基于区块链的相互保险平台软件，由保险平台运营机构运营，运营机构可以为相互保险公司等。保险平台节点可以生成并更新保险数据区块链。)提交个人或企业信息，申请注册为平台正式用户节点。提交的个人或企业信息可以包括用户(姓名或企业)名称、有效证件号码、地址、其他信息(如身体状况、企业运营状况、信用评级等)。提交的信息可以与用户保险需求和保单内容相关，不同用户提交信息可以不同。

接着，平台节点查询保险数据区块链，包括用户(姓名或企业)名称、有效证件号码、地址、其他信息(如身体状况、企业运营状况、信用评级等)，查询区块链中是否已经存在上述信息。如果存在上述信息，则需要判断提交信息是否与区块链数据一致，不一致则认定提交信息错误，拒绝注册；如果不存在上述信息，则生成一条区块链数据，并经由全网用户节点共识认证。经过共识认证意味着通过信息审核，可能获取保险平台分配的全网唯一用户ID。其中，需要说明的是，对于部分用户节点提交的信息，绝大多数用户节点无法判断其真假时，保险平台运营机构将辅助进行信息审核判断。比如，企业节点提交了经营报告，如果部分普通用户节点无法审核其真实性时，可以有两种方法解决。一是，部分普通用户节点会自发通过其他途径查询该用户经营报告的真实性，给出判断，并在区块链共识过程中体现判断结果；二是，平台节点运营机构通过其他途径查询该用户经营报告的真实性，给出判断，并在区块链发布经营报告判断结果，供其他用户节点查询。

然后，用户信息上传至保险平台区块链后就无法更改。

步骤2，订立初步保单。具体的，保单可以记载如下信息：保险记录ID(标识)、保险者ID、被保险者ID、保险标的、保险金额、保险费、保险期限、赔偿或给付的责任范围、赔偿的规则条件及其他事项、授权访问用户列表、授权访问联合签名等。其中，保险标的是指保险利益的载体，比如人的身体等。授权访问用户列表指的是能够访问保单内容的用户列表，只有授权的用户才能够看到保单内容。

步骤3，接收个人或企业用户节点进行会费缴纳或补缴会费(会费包含保险费，以及平台会费)。

具体的，缴费形式可以多样，比如缴纳至同一银行或基金公共保险账户、或均缴纳给保险机构公共保险账户等。会费缴纳完成后，用户节点利用缴费凭证更新保险记录。

步骤4，接收投保者节点在保险数据区块链发布的参与用户信息、保险记录信息(含必要扫描文件)。投保者节点可以为任一用户节点，并接受所有用户节点进行共识验证。经共识验证的信息被记录至区块链中。区块链中的保单信息生效并不可篡改。

步骤5，用户在保险数据区块链发布理赔申请，包含理赔数据信息、证明文件信息(含必要扫描件)等，所有用户节点进行共识验证。

具体的，理赔申请可以包括如下内容：理赔记录ID、对应的保险记录ID、理赔内容、理赔金额、理赔依据凭证(可以为扫描文件等)、理赔者签名和理赔时间等。理赔数据和证明文件信息将作为区块数据，由用户发布至区块链中。全网用户节点根据区块数据，判断理赔依据是否充足、理赔申请是否合理，从而给出理赔判断。只有通过全网用户节点的理赔判断(全网用户节点并非指全部用户节点，也可以设定为占用户总数一定比例的用户节点)，理赔数据记录才能在区块链写入发布并生效。理赔判断过程中，用户节点通过查询区块链理赔数据和证明文件信息，结合个人知识和保单约定做出判断，并将判断结果上传至区块链中全网共识。

步骤6，接收用户节点在保险数据区块链发布保单或用户信息变更申请(包含理必要证明文件扫描件等)，所有用户节点针对该变更申请进行共识验证。

具体的，信息变更申请可以包括如下内容：信息变更记录ID、对应的保险记录ID、对应的用户信息记录ID、变更内容、变更依据(可以为扫描文件等)、申请者签名和申请变更时间等。变更申请数据和证明文件信息将作为区块数据，由用户发布至区块链中。全网用户节点根据区块数据，判断变更依据是否充足、变更申请是否合理，从而给出理赔判断，只有通过全网用户节点的判断，信息变更记录才能在区块链写入发布并生效。

步骤7，通过公共保险账户向用户节点返还理赔资产等，如存在会费不足等情况，需要会员节点补缴会费。

具体的，会员节点只需缴纳补缴会费至约定的银行或基金公共保险账户、或均缴纳给保险机构公共保险账户等。会费缴纳完成后，生成会费缴纳凭证数据记录，并在区块链发布，由银行或保险机构平台参与进行共识验证，通过共识验证，则会费缴纳成功。

步骤8，第三方机构可以查询保险区块链数据信息，进行保险监管、纠纷处理等。由于区块链数据的真实、透明、不可篡改，天然就支持第三方机构的监管。

步骤9，会费拥有机构(比如银行或保险平台经营机构)可以发起保费理财方案等执行合约，经由全网共识验证。

具体的，首先，会费拥有机构通过基于区块链的保险平台发布一个会费理财脚本，其包含了会费用途、预期收益、利益分配比例、使用时间等。接着，会费理财记录在区块链发布并进行全网共识验证，一旦验证通过，会费将根据脚本约定用于理财。然后，约定时间到达后，会费拥有机构将按照脚本约定进行会费发放，并生成会费发放记录至区块链，由全网用户共识验证。上述脚本执行过程，也在第三方监管范围，一旦出现履责问题，将进行处罚。需要说明的是，合约的类型可以多种多样，可以包括上面所述的航空保险、车险等。

步骤10，保险服务提供者(例如银行、金融机构、保险平台运营机构等)，向区块链发布服务承诺记录，包括保单理赔计划、会费盈利目标、承诺盈利时间等信息，由全网共识验证。保单理赔计划等承诺将是用户选择保险平台运营机构的重要参考，一旦无法完成承诺，用户可以申请第三方仲裁处罚。

图4是本发明一实施例的事件认证装置的结构示意图。

如图4所示，事件认证装置400可以包括：信息采集单元410、请求生成单元420和记录检索单元430。其中，信息采集单元410可以用于采集待认证事件的相关信息；请求生成单元420可以用于在相关信息满足待认证事件的触发条件时，产生对待认证事件进行认证的请求；记录检索单元430可以响应于所产生的请求，从区块链中检索与所请求的认证事件相关联的历史记录；事件认证单元440可以基于历史记录，对认证事件进行认证。

在一些实施例中，可以在图4实施例的基础上增加：结果生成单元和第一发送单元。其中，结果生成单元可以基于对认证事件进行认证的情况，生成认证结果；第一发送单元可以用于向节点集群群体发送对认证结果进行校验的请求，节点集群包括多个用户节点。

在一些实施例中，可以在上述实施例的基础上增加：第一接收单元和结果判定单元。其中，第一接收单元可以用于接收来自节点集群中的至少一个节点的校验反馈，校验反馈包括：认证结果正确或者错误的反馈；结果判定单元可以用于根据校验反馈判定认证结果是否通过校验。

在一些实施例中，可以在上述实施例的基础上增加：事件认证单元。事件认证单元可以还用于当相关信息为自动采集的可靠信息时，基于可靠信息对所请求的认证事件进行认证，并生成第一认证结果，将可靠信息和第一认证结果记录在区块链中。

在一些实施例中，可以在上述实施例的基础上增加：事件认证单元。其中，事件认证单元，还用于当相关信息为用户节点提交的信息时，基于提交的信息对认证事件进行认证，并生成第二认证结果，将用户节点提交的信息和第二认证结果记录在区块链中。

在一些实施例中，可以在上述实施例的基础上增加：记录生成单元。其中，记录生成单元可以基于校验反馈，生成认证事件的第一补充记录，将第一补充记录存储在区块链中。

在一些实施例中，可以在上述实施例的基础上增加：信息检索单元、信息筛选单元和第二发送单元。其中，信息检索单元可以用于根据预设的关键字在区块链中进行信息检索，获取与关键字相关联的至少两条关键信息；信息筛选单元可以用于对比至少两条关键信息，并筛选出相互冲突的关键信息；第二发送单元可以用于向节点集群群体发送验证所筛选出的相互冲突的关键信息的验证请求。

在一些实施例中，可以在上述实施例的基础上增加：第三发送单元。其中，第三发送单元可以用于向节点集群群体发送对认证事件的认证对象节点的信用进行评定的请求。

在一些实施例中，可以在上述实施例的基础上增加：第二接收单元和第二生成单元。其中，第二接收单元可以用于接收来自节点集群中的至少一个节点的评定反馈；第二生成单元可以用于根据评定反馈，生成认证事件的第二补充记录，将第二补充记录与历史信息相关联地储至区块链中。

本领域技术人员应能理解，术语“第一”、“第二”、“第三”用于标示名称而非用于表示任何特定的顺序。

图5是本发明另一实施例的事件认证装置的结构示意图。

如图5所示，事件认证装置500可以包括：请求接收单元510、记录检索单元520和结果校验单元530。

其中，请求接收单元510可以用于接收对认证结果的进行校验的请求，认证结果是对待认证事件进行认证所生成的结果；记录检索单元520可以响应于所接收的校验请求，从区块链中检索与待认证事件相关联的历史记录；结果校验单元530可以基于历史记录，对认证结果进行校验。

作为图5实施例的第一个变形实施例，可以在图5实施例的基础上增加：反馈生成单元和反馈发送单元。

其中，反馈生成单元可以基于对认证结果进行校验的情况，生成校验反馈。反馈发送单元可以用于发送校验反馈，校验反馈包括：认证结果正确或者错误的反馈。

作为图5实施例的第二个变形实施例，可以在图5实施例的第一个变形实施例的基础上增加：信息采集单元、记录生成单元和记录存储单元。

其中，信息采集单元可以用于采集待认证事件的相关信息；记录生成单元可以用于基于所采集的相关信息，生成待认证事件的补充记录；记录存储单元可以用于将补充记录和校验反馈储至区块链中。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

需要说明的是，上述各实施例的装置可作为上述各实施例的方法中的执行主体，可以实现各个方法中的相应流程，上述各个实施例中的内容可以互相参考使用，为了简洁，此方面内容不再赘述。

本发明可以以其他的具体形式实现，而不脱离其精神和本质特征。例如，特定实施例中所描述的算法可以被修改，而系统体系结构并不脱离本发明的基本精神。因此，当前的实施例在所有方面都被看作是示例性的而非限定性的，本发明的范围由所附权利要求而非上述描述定义，并且，落入权利要求的含义和等同物的范围内的全部改变从而都被包括在本发明的范围之中。