一种多交易模式联盟链
阅读：71发布：2020-05-31
专利汇可以提供一种多交易模式联盟链专利检索，专利查询，专利分析的服务。并且本 发明 公开了一种多交易模式联盟链，包括监管 节点 系统和交易节点系统。前者部署在联盟链网络中 指定 PC上，通过桥接与业务系统实时关联。后者部署在每一个用户节点本地或该用户节点地址对应的 云 端。交易用户可以在PC、移动设备、 自动柜员机 (ATM)上操作。交易过程、数据交互、区 块 存储等采用加密处理。本发明的多交易模式联盟链，将传统的买卖交易泛化为业务系统的事件处理，优化了交易验证、共识判定、区块生成、区块存储、比较验证、 区块链 接等机制，可提供事件是否发生、事件序列关系证明，业务数据异常的实时预警，被篡改业务数据的重建线索等服务，具有“去中心化”、安全、防抵赖、防篡改的技术特点，能低成本、无须积累地获得可信的结果。，下面是一种多交易模式联盟链专利的具体信息内容。
1.一种多交易模式联盟链，其特征在于：
包括买卖交易泛化为业务系统的事件处理，使得业务系统的每次事件处理可以对应一次交易，
多交易模式联盟链与指定业务系统之间通过桥接单元进行联结，桥接单元安装在业务系统数据库端，实时触发各用户(包括DBA)对数据库的新增、删除、修改事件，参照该交易在“交易模型文件”中事先定制的交易结构，摘取当前事件记录中需要的数据项值，构建为交易结构，获取本事件的附件文件，传递给监管节点系统；
交易的用户类型包括PC用户、移动设备用户、ATM用户，
多交易模式联盟链通过授权/许可单元，对业务系统的各类用户(普通PC操作用户、数据管理员(DBA)、ATM用户、移动设备用户)计算地址、公钥、私钥，记录存储特征，申请本地或云端空间，授权/许可程序处理结果追加到用户文件中，用户的私钥、公钥、地址的计算规则同比特币交易系统，其中，计算规则的原始输入分别为：
(1)PC用户、DBA：“用户名”+“密码”；
(2)移动设备用户：“设备码”；
(3)ATM用户：“开户行”+“账号/卡号”+“密码”；
交易生成的区块数据在本地存储或在该用户地址对应的云端存储，存储与事件对应的区块数据，或关联存储与事件相关的、多种格式的附件数据(如图片、图像、音频、视频文件)，
读取用户文件中该用户地址对应记录的用户类型值：
(1)如果值为0、1、2则为本地存储，在系统规定的目录下存储区块数据文件，在系统规定的目录下存储附件文件簇；
(2)如果值为3、4则为云端存储，针对云端存储的情况，在系统为该用户申请的云端指定目录下存储区块数据文件，在系统为该用户申请的云端指定目录下存储附件文件簇。
2.一种多交易模式联盟链，其特征在于：包括以下交易处理步骤：
步骤S0：交易处理开始；
步骤S1：监管节点系统接收桥接程序输出的当前交易数据，对交易数据进行数字签名；
步骤S2：监管节点系统将上述签名后的数据发送给该笔交易相关的用户所在的交易节点系统；
步骤S3：该笔交易相关用户的交易节点系统接收待验证的数据，进行交易验证：
步骤S3-1：自动解密验证，如果自动验证通过，进入步骤S3-2；否则，置验证结果为“假”，进入步骤S4；
步骤S3-2：人工验证，取出并解析交易数据，有相关用户在本地或云端交易节点系统进行人工验证，接收人工验证结果，如果选择“真”，则置验证结果为“真”；如果选择“假”，则置验证结果为“假”；
步骤S4：交易节点系统对自己的交易验证结果进行签名，发送至监管节点系统；
步骤S5：监管节点系统分别接收各自交易节点系统的签名消息，解密验证：
步骤S5-1：如果验证通过，则进入步骤S6；
步骤S5-2：如果验证不通过，则进入步骤S1；
步骤S6：监管节点系统进行共识判定：
步骤S6-1：如果所有交易节点系统发送的验证结果都为“真”，则共识判定为“真”，进入步骤S7；
步骤S6-2：如果所有交易节点系统发送的验证结果不全为“真”，则共识判定为“假”，进入步骤S1；
步骤S7：监管节点系统对共识判定结果签名，并发送给相关交易节点系统；
步骤S8：相关交易节点系统接收该签名消息，解密验证：
步骤S8-1：如果验证通过，进入步骤S9；
步骤S8-2：如果验证不通过，进入步骤S1；
步骤S9：交易节点系统区块生成：
步骤S9-1：交易节点系统向监管节点系统请求时间戳、交易顺序号、链尾指针，并将请求信息签名，发送至监管节点系统；
步骤S9-2：监管节点系统对请求签名进行解密验证：如果验证不通过，置返回结果为“空”；否则，计算、检索出对应值并置于返回结果；
步骤S9-3：对返回结果值进行签名后发送给对应的交易节点系统；
步骤S10：相关交易节点系统接收该签名消息，解密验证：
步骤S10-1：如果验证通过，进入步骤S11；
步骤S10-2：如果验证不通过，进入步骤S1；
步骤S11：按区块结构进行数据项赋值，计算区块头的HASH256值；
步骤S12：交易节点系统进行区块存储：
步骤S12-1：打开用户文件，获取本用户的存储位置；打开交易模型文件，读取本交易的附件属性值；
步骤S12-2：在存储位置的指定子目录下，以区块头的HASH256值为命名存储区块数据；
在存储位置的另一指定子目录下，以区块头的HASH256值为命名存储附件文件；
步骤S12-3：DBA用户对区块数据、附件文件进行签名，并发送至监管节点系统；
zhangwei用户对区块头数据进行签名，并发送至监管节点系统；
步骤S13：监管节点系统分别接收各自交易节点系统发送的签名消息，解密验证：
步骤S13-1：如果解密验证成功，进入步骤S14；
步骤S13-2：如果解密验证失败，进入步骤S1；
步骤S14：监管节点系统进行比较验证：
步骤S14-1：针对区块数据，计算Merkle根，与区块中的Merkle根比较：
步骤S14-1-1：如果相等，进入步骤S14-2；
步骤S14-1-2：如果不等，进入步骤S1；
步骤S14-2：针对区块数据，计算区块头的HASH256值，与区块文件名和附件文件名比较：
步骤S14-2-1：如果相等，进入步骤S14-3；
步骤S14-2-2：如果不等，进入步骤S1；
步骤S14-3：将区块数据中的头部分数据项与其它用户发送的区块头数据项进行逐一比较：
步骤S14-3-1：如果相等，进入步骤S15；
步骤S14-3-2：如果不等，进入步骤S1；
步骤S15：返回比较验证结果为“真”；
步骤S16：监管节点系统进行区块链接：
步骤S16-1：打开用户文件，获取存储位置(HOME目录)，在规定的子目录下以区块头HASH256值作为文件名，存储区块数据；在规定的另一子目录下以区块头HASH256值作为文件名，存储附件数据；
步骤S16-2：打开云端区块链文件，将区块文件名追加到该文件中；
步骤S16-3：打开链尾文件，用区块文件名更新该文件的唯一一条记录；
步骤S17：进入步骤S1。
3.如权利要求1或2所述的一种多交易模式联盟链，其特征在于：还包括审计服务，所述的审计服务包括以下步骤：
步骤N0：审计服务开始；
步骤N1：判断是否有异常数据存储：
步骤N1-1：有，则对异常数据进行解析并实时预警，预警结束进入步骤N1；
步骤N1-2：无，则进入步骤N1；
步骤N2：展现区块链：监管节点打开云端区块链文件，将行数标记H设为1：
步骤N2-1：读取第H行区块链文件名的值，将值赋给P：
步骤N2-2：将P与本发明约定的创世区块值比较：
步骤N2-2-1：如果相等，则进入步骤N1；
步骤N2-2-2：如果不等，则进入N2-3；
步骤N2-3：在监管节点指定目录下查找文件名等于P的区块文件，解析该区块数据，重新计算Merkle树根、区块头HASH256值；
步骤N2-4：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
步骤N2-4-1：如果都相等，则进入步骤N2-5；
步骤N2-4-2：如果不全相等或都不等，则进入步骤N2-7；
步骤N2-5：在监管节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
步骤N2-6：H＝H+1，进入步骤N2-1；
步骤N2-7：按照先DBA用户、后普通交易用户的顺序，分别在其对应目录下查找文件名＝P的区块文件：
步骤N2-7-1：如果都未找到，则进入步骤N1；
步骤N2-7-2：否则，进入步骤N2-8；
步骤N2-8：解析该区块数据，重新计算Merkle树根、区块头HASH256值；
步骤N2-9：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
步骤N2-9-1：如果都相等，则进入步骤N2-10；
步骤N2-9-2：如果不全相等或都不等，则进入步骤N2-7；
步骤N2-10：在该节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
步骤N2-11：H＝H+1，进入步骤N2-1；
步骤N3：证明事件发生。接收输入的事件具体特征值，在已经展现的区块链上，从链尾区块开始检索并解析该区块：
步骤N3-1：将区块中的交易数据与输入的事件具体特征值进行匹配：
步骤N3-1-1：如果匹配，则用红色框标记该区块(表示找到)，进入步骤N3；
步骤N3-1-2：如果不匹配，则读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块；
步骤N3-2：判断该区块是否创世区块：
步骤N3-2-1：如果是，则进入步骤N3；
步骤N3-2-2：如果不是，则解析该区块，进入步骤N3-1；
步骤N4：证明事件序列关系。接收输入的事件通用特征值(比如交易码)，在已经展现的区块链上，从链尾区块开始检索并解析该区块：
步骤N4-1：将区块中的交易数据与输入的事件通用特征值进行匹配：
步骤N4-1-1：如果匹配，则用红色框标记该区块(表示找到)，进入步骤N4-2。
步骤N4-1-2：如果不匹配，进入步骤N4-2；
步骤N4-2：读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块；
步骤N4-3：判断该区块是否创世区块：
步骤N4-3-1：如果是，则进入步骤N4；
步骤N4-3-2：如果不是，则解析该区块，进入步骤N4-1；
步骤N5：区块数据是否被篡改证明，在已经展现的区块链上，从链尾区块开始检索区块：
步骤N5-1：分别读取监管节点、DBA节点、相关用户节点的对应区块；
步骤N5-2：解析对应区块，验证Merkle根、区块头HASH256值；
步骤N5-3：分别与当前区块链上对应区块的Merkle根、区块头HASH256值比较，判断值是否相等：
步骤N5-3-1：如果都相等，则进入步骤N5-4；
步骤N5-3-2：否则，记录“某节点某区块被篡改(删除/修改)”，进入步骤N5-4；
步骤N5-4：读取当前区块链上区块的前一区块指针，检索区块链上下一区块；
步骤N5-5：判断是否是创世区块：
步骤N5-5-1：如果是，则进入步骤N5；
步骤N5-5-2：否则，进入步骤N5-2；
步骤N6：业务数据重建线索：
步骤N6-1：在监管节点可访问的云端指定目录下，打开异常交易数据文件，读取所有交易验证未通过的数据记录；
步骤N6-2：按时间递增顺序排列，解析每一条数据记录，形成数据重建线索列表，列表内容包括：时间、用户地址、交易节点数、交易数据、操作指令。
一种多交易模式联盟链
技术领域
背景技术
[0002] 区块链(Blockchain)技术由中本聪(Satoshi Nakamoto)于2008年发明，具体内容记载于“比特币：一种点对点电子现金交易系统”(Bitcoin:A Peer-to-Peer Electronic Cash System)。主要用来支撑“去中心化”的、非服务器架构的电子货币交易，具有结构巧妙、算法安全、带宽占用小、防抵赖、防篡改的技术特点，其最主要的应用特征是在一个不可信任的环境下低成本、无须积累地获得可信的结果。联盟链(Consortium Blockchain)是区块链中的一种，是一种需要注册许可的区块链，也称许可链(Permissioned Blockchain)。联盟链网络由若干个普通交易节点和唯一一个监管节点组成。目前，联盟链的代表为R3(Corda分布式账本)、Hyperledger。现有区块链核心技术具有以下技术特性：
[0003] 1、单交易型的。在比特币交易系统的区块链技术中，只能适应“买入”、“卖出”交易，并且其所有交易被转换为卖出方对买入方的“转出”交易模式；
[0004] 2、交易验证和区块存储是不能带附件的。无法附加该交易过程或结果的图片、图像、音频、视频等证据资料；
[0005] 3、区块数据是本地存储的。区块数据只能存储在交易节点本地，像移动设备、ATM等节点因为无法本地存储，是不能直接作为交易节点的；
[0006] 4、区块生成速度是受控的。在比特币交易系统中，区块生成是通过“挖矿”机制来实现的，受当前区块的“目标哈希值(Bits)”控制，大约每10分钟生成一个区块。
发明内容
[0008] 本发明的目的是为了解决现有技术中区块链技术只能应用于基于PC端的加密货币买入卖出交易，不能直接应用于其它领域的问题。提供一种多交易模式联盟链。
[0009] 为了实现上述目的，本发明的技术方案如下：一种多交易模式联盟链，其特征在于：
[0010] 包括买卖交易泛化为业务系统的事件处理，使得业务系统的每次事件处理可以对应一次交易，
[0011] 多交易模式联盟链与指定业务系统之间通过桥接单元进行联结，桥接单元安装在业务系统数据库端，实时触发各用户(包括DBA)对数据库的新增、删除、修改事件，参照该交易在“交易模型文件”中事先定制的交易结构，摘取当前事件记录中需要的数据项值，构建为交易结构，获取本事件的附件文件，传递给监管节点系统；
[0012] 交易的用户类型包括PC用户、移动设备用户、ATM用户，
[0013] 多交易模式联盟链通过授权/许可单元，对业务系统的各类用户(普通PC操作用户、数据管理员(DBA)、ATM用户、移动设备用户)计算地址、公钥、私钥，记录存储特征，申请本地或云端空间，授权/许可程序处理结果追加到用户文件中，用户的私钥、公钥、地址的计算规则同比特币交易系统，其中，计算规则的原始输入分别为：
[0014] (1)PC用户、DBA：“用户名”+“密码”；
[0015] (2)移动设备用户：“设备码”；
[0016] (3)ATM用户：“开户行”+“账号/卡号”+“密码”；
[0017] 交易生成的区块数据在本地存储或在该用户地址对应的云端存储，存储与事件对应的区块数据，或关联存储与事件相关的、多种格式的附件数据(如图片、图像、音频、视频文件)，
[0018] 读取用户文件中该用户地址对应记录的用户类型值：
[0019] (1)如果值为0、1、2则为本地存储，在系统规定的目录下存储区块数据文件，在系统规定的目录下存储附件文件簇；
[0020] (2)如果值为3、4则为云端存储，针对云端存储的情况，在系统为该用户申请的云端指定目录下存储区块数据文件，在系统为该用户申请的云端指定目录下存储附件文件簇。
[0021] 一种多交易模式联盟链，还包括以下交易处理步骤：
[0022] 步骤S0：交易处理开始；
[0023] 步骤S1：监管节点系统接收桥接程序输出的当前交易数据，对交易数据进行数字签名；
[0024] 步骤S2：监管节点系统将上述签名后的数据发送给该笔交易相关的用户所在的交易节点系统；
[0025] 步骤S3：该笔交易相关用户的交易节点系统接收待验证的数据，进行交易验证：
[0026] 步骤S3-1：自动解密验证，如果自动验证通过，进入步骤S3-2；否则，置验证结果为“假”，进入步骤S4；
[0027] 步骤S3-2：人工验证，取出并解析交易数据，有相关用户在本地或云端交易节点系统进行人工验证，接收人工验证结果，如果选择“真”，则置验证结果为“真”；如果选择“假”，则置验证结果为“假”；
[0028] 步骤S4：交易节点系统对自己的交易验证结果进行签名，发送至监管节点系统；
[0029] 步骤S5：监管节点系统分别接收各自交易节点系统的签名消息，解密验证：
[0030] 步骤S5-1：如果验证通过，则进入步骤S6；
[0031] 步骤S5-2：如果验证不通过，则进入步骤S1；
[0032] 步骤S6：监管节点系统进行共识判定：
[0033] 步骤S6-1：如果所有交易节点系统发送的验证结果都为“真”，则共识判定为“真”，进入步骤S7；
[0034] 步骤S6-2：如果所有交易节点系统发送的验证结果不全为“真”，则共识判定为“假”，进入步骤S1；
[0035] 步骤S7：监管节点系统对共识判定结果签名，并发送给相关交易节点系统；
[0036] 步骤S8：相关交易节点系统接收该签名消息，解密验证：
[0037] 步骤S8-1：如果验证通过，进入步骤S9；
[0038] 步骤S8-2：如果验证不通过，进入步骤S1；
[0039] 步骤S9：交易节点系统区块生成：
[0041] 步骤S9-2：监管节点系统对请求签名进行解密验证：如果验证不通过，置返回结果为“空”；否则，计算、检索出对应值并置于返回结果；
[0042] 步骤S9-3：对返回结果值进行签名后发送给对应的交易节点系统；
[0043] 步骤S10：相关交易节点系统接收该签名消息，解密验证：
[0044] 步骤S10-1：如果验证通过，进入步骤S11；
[0045] 步骤S10-2：如果验证不通过，进入步骤S1；
[0046] 步骤S11：按区块结构进行数据项赋值，计算区块头的HASH256值；
[0047] 步骤S12：交易节点系统进行区块存储：
[0048] 步骤S12-1：打开用户文件，获取本用户的存储位置；打开交易模型文件，读取本交易的附件属性值；
[0049] 步骤S12-2：在存储位置的指定子目录下，以区块头的HASH256值为命名存储区块数据；在存储位置的另一指定子目录下，以区块头的HASH256值为命名存储附件文件；
[0050] 步骤S12-3：DBA用户对区块数据、附件文件进行签名，并发送至监管节点系统；zhangwei用户对区块头数据进行签名，并发送至监管节点系统；
[0051] 步骤S13：监管节点系统分别接收各自交易节点系统发送的签名消息，解密验证：
[0052] 步骤S13-1：如果解密验证成功，进入步骤S14；
[0053] 步骤S13-2：如果解密验证失败，进入步骤S1；
[0054] 步骤S14：监管节点系统进行比较验证：
[0055] 步骤S14-1：针对区块数据，计算Merkle根，与区块中的Merkle根比较：
[0056] 步骤S14-1-1：如果相等，进入步骤S14-2；
[0057] 步骤S14-1-2：如果不等，进入步骤S1；
[0058] 步骤S14-2：针对区块数据，计算区块头的HASH256值，与区块文件名和附件文件名比较：
[0059] 步骤S14-2-1：如果相等，进入步骤S14-3；
[0060] 步骤S14-2-2：如果不等，进入步骤S1；
[0061] 步骤S14-3：将区块数据中的头部分数据项与其它用户发送的区块头数据项进行逐一比较：
[0062] 步骤S14-3-1：如果相等，进入步骤S15；
[0063] 步骤S14-3-2：如果不等，进入步骤S1；
[0064] 步骤S15：返回比较验证结果为“真”；
[0065] 步骤S16：监管节点系统进行区块链接：
[0066] 步骤S16-1：打开用户文件，获取存储位置(HOME目录)，在规定的子目录下以区块头HASH256值作为文件名，存储区块数据；在规定的另一子目录下以区块头HASH256值作为文件名，存储附件数据；
[0067] 步骤S16-2：打开云端区块链文件，将区块文件名追加到该文件中；
[0068] 步骤S16-3：打开链尾文件，用区块文件名更新该文件的唯一一条记录；
[0069] 步骤S17：进入步骤S1。
[0070] 本发明与现有技术相比，具有以下有益效果：
[0071] 1、交易类型多样化，将传统的买卖交易泛化为业务系统的事件处理，因此，一次数据库操作、一次审批、一次发证、一次就诊、一次责任认定、一次产权判决等各类高价值事件处理都可以作为交易；
[0072] 2、存储内容多样化，不仅可以存储事件对应的区块数据，也可以关联存储与事件相关的、多种格式的附件数据(如图片、图像、音频、视频文件等证据或结果)；
[0073] 3、存储类型多样化，区块数据可以在本地存储，也可以根据用户类型在该用户地址对应的云端存储；
[0074] 4、用户类型多样化，可以是PC用户、移动设备用户、ATM用户；
[0075] 5、区块生成速度由系统处理速度决定，不做人为干涉。
[0076] 具备了上述特性的联盟链，通过“桥接”与指定的业务系统关联，为该业务系统所处理的事件过程或结果提供防篡改、防抵赖、可信的区块链支撑。可用于证明某事件在某时刻确实发生、某些事件之间具有的序列关系，对业务数据异常(非法入侵篡改数据、DBA篡改数据)进行实时预警，为被篡改的业务数据重建提供线索等服务，极大地扩展了区块链技术的应用范围。附图说明
[0077] 图1是多交易模式联盟链系统总体架构图；
[0078] 图2是桥接示意图；
[0079] 图3是授权/许可处理流程图；
[0080] 图4是版本管理流程图；
[0081] 图5是交易模型定制流程图；
[0082] 图6是交易过程业务模型图；
[0083] 图7是数字签名流程图，是图6中数字签名的具体处理过程；
[0084] 图8是交易验证流程图，是图6中交易验证的具体处理过程；
[0085] 图9是共识判定流程图，是图6中共识判定的具体处理过程；
[0086] 图10是区块生成流程图，是图6中区块生成的具体处理过程；
[0087] 图11是区块存储流程图，是图6中区块存储的具体处理过程；
[0088] 图12是比较验证流程图，是图6中比较验证的具体处理过程；
[0089] 图13是区块链接流程图，是图6中区块链接的具体处理过程；
[0090] 图14是审计服务总体流程图；
[0091] 图15是区块链展现的处理流程图，是图14中区块链展现的具体处理过程；
[0092] 图16是事件是否发生证明的处理流程，是图14中事件是否发生证明的具体处理过程；
[0093] 图17是事件顺序关系证明的处理流程，是图14中事件顺序关系证明的具体处理过程；
[0094] 图18是区块数据是否被篡改证明的处理流程，是图14中区块数据是否被篡改证明的具体处理过程；
[0095] 图19是数据重建线索服务的流程，是图14中数据重建线索的具体处理过程；
[0096] 图20是区块链示意图；
[0097] 图21是用户文件存储结构示意图(PC用户)；
[0098] 图22是用户文件存储结构示意图(ATM用户)；
[0099] 图23是用户文件存储结构示意图(移动用户)；
[0100] 图24是交易模型文件存储结构示意图；
[0101] 图25是交易顺序文件存储结构示意图；
[0102] 图26是区块链链尾文件存储结构示意图；
[0103] 图27是云端区块链文件存储结构示意图；
[0104] 图28是异常交易数据文件存储结构示意图。
具体实施方式
[0105] 为使对本发明的结构特征及所达成的功效有更进一步的了解与认识，用以较佳的实施例及附图配合详细的说明，说明如下：
[0106] 参见图1，多交易模式联盟链的技术架构为：通过联盟链网络(可以是局域网、广域网、互联网、移动网及其混合)将与指定业务系统相关的PC用户(普通PC操作用户、数据管理员(DBA)或系统管理员)、ATM用户、移动设备用户联结成联盟链成员。
[0107] 多交易模式联盟链包括监管节点系统、交易节点系统。监管节点系统安装部署在联盟链网络中指定PC或服务器上，交易节点系统安装部署在每一个用户节点本地指定目录下或该节点地址对应的云端指定目录下。
[0108] 监管节点系统与交易节点系统之间通过JSON RPC点对点(Peer to Peer)通信协议实现数据交互。
[0109] 安全加密机制包括：
[0110] (1)用户的私钥、公钥、地址生成：使用SHA256、RIPEMD160加密方法(同比特币交易系统)；
[0111] (2)交易数据的签名与验证：采用secp256k1加密方法(同比特币交易系统)；
[0112] (3)区块头中的Merkle树根：使用SHA256方法迭代计算(同比特币交易系统)；
[0113] (4)区块链接的指针：采用区块头的SHA256值(同比特币交易系统)；
[0114] (5)区块数据的文件命名：采用区块头的SHA256值(同比特币交易系统)。
[0115] 监管节点系统分为：(1)初始化部分；(2)交易过程处理部分；(3)审计服务部分。
[0116] (1)初始化部分。包括：授权/许可程序、监管端版本管理程序、交易模型定制程序、桥接程序。
[0117] 1)桥接程序，见图2。
[0118] 2)授权/许可程序，见图3。
[0119] 3)版本管理程序，见图4。
[0120] 4)交易模型定制程序，见图5。
[0121] (2)交易过程处理部分。包括：共识判定程序、时间戳生成器程序、交易顺序生成器程序、比较验证程序、区块链接程序。
[0122] 1)共识判定程序，见图9。
[0123] 2)时间戳生成程序。接收到某笔交易的相关方交易节点系统发来的时间戳请求时，计算出当前时刻时间戳，返回给相关交易节点。
[0124] 3)交易序号生成程序。接收到某笔交易的相关方交易节点系统发来的交易顺序请求时，计算出当前该交易的顺序号，返回给相关交易节点。
[0125] 4)比较验证程序，见图12。
[0126] 5)区块链接程序，见图13。
[0127] (3)审计服务部分。包括：审计服务程序。
[0128] 1)审计服务程序，见图14。
[0129] 交易节点系统。包括：交易端版本管理程序、交易验证程序、区块生成程序、区块存储程序。
[0130] 1)交易端版本管理程序，见图4。
[0131] 2)交易验证程序，见图8。
[0132] 3)区块生成程序，见图10。
[0133] 4)区块存储程序，见图11。
[0134] 监管节点系统与各交易节点系统之间的业务协作逻辑，见图6。
[0135] 参见图2，多交易模式联盟链与指定业务系统之间通过桥接程序进行联结，桥接程序安装在业务系统数据库端，实时触发各用户(包括DBA)对数据库的新增、删除、修改事件，参照该交易在“交易模型文件”中事先定制的交易结构，摘取当前事件记录中需要的数据项值，构建为交易结构，获取本事件的附件文件，传递给监管节点系统，由监管节点系统加工成数字签名(见图7)格式。参见图3，多交易模式联盟链通过授权/许可程序，对业务系统的各类用户(普通PC操作用户、数据管理员(DBA)、ATM用户、移动设备用户)计算地址、公钥、私钥，记录存储特征，申请本地或云端空间，部署版本管理系统。授权/许可程序处理结果追加到用户文件中。用户的私钥、公钥、地址的计算规则同比特币交易系统。其中，计算规则的原始输入分别为：
[0136] (1)PC用户、DBA：“用户名”+“密码”；(2)移动设备用户：“设备码”；
[0137] (3)ATM用户：“开户行”+“账号/卡号”+“密码”。
[0138] 其中，用户文件存储结构：
[0139] (1)PC操作用户、DBA的用户文件存储结构，见图21。
[0140] (2)ATM用户的用户文件存储结构，见图22。
[0141] (3)移动设备用户的用户文件存储结构，见图23。
[0142] 参见图4，多交易模式联盟链通过监管节点端的版本管理程序和交易节点端的版本管理程序的协作来完成版本的统一与维护。其中，
[0144] 其中，监管节点端的版本管理程序承担两项工作：(1)监管节点系统本身的升级工作；(2)交易节点系统升级的程序、数据文件打包，并置升级信号。参见图5，多交易模式联盟链通过交易模型定制程序，将所面向的业务系统的事件特征抽象为交易结构，并配置该交易的交易码、交易名称、交易结构、附件标志、交易描述。计算该条记录的SHA256值(用于校验)，定制结果追加到交易模型文件。交易模型文件结构见图24。参见图6，多交易模式联盟链通过监管节点系统与某笔交易相关的各交易节点系统之间的协作来完成业务处理逻辑：
[0145] (1)监管节点系统接收桥接程序输出的交易数据(含可能的附件数据)；
[0146] (2)监管节点系统对交易数据进行数字签名(见图7)；
[0147] (3)监管节点系统将签名消息发送给本交易相关的所有交易节点系统；
[0148] (4)各相关的交易节点系统接收该签名数据后，进行交易验证(见图8)；
[0149] (5)各相关的交易节点系统对交易验证结果进行签名，发送至监管节点系统；
[0150] (6)监管节点系统接收该交易的所有签名后的验证结果后，解密验证；
[0151] (7)监管节点系统进行共识判定(见图9)：
[0152] (7-1)如果共识判定的结果为未达成共识，则在云端指定目录下存储该异常交易数据(异常交易数据文件的存储结构见图28)，进入(1)。
[0153] (7-2)如果共识判定的结果为达成共识，进入(8)；
[0154] (8)监管节点系统对共识判定结果进行数字签名，发送给相关的交易节点系统；
[0155] (9)各相关的交易节点系统接收签名消息后进行解密验证；
[0156] (10)各相关的交易节点系统进行区块生成(见图10)；
[0157] (11)各相关的交易节点系统进行区块存储(见图11)；
[0158] (12)DBA用户对生成的区块数据进行数字签名，并发送给监管节点系统；其它交易用户对生成的区块的区块头数据进行数字签名，并发送给监管节点系统；
[0159] (13)监管节点系统接收相关交易节点系统发送的签名消息，进行解密验证；
[0160] (14)监管节点系统进行比较验证(见图12)：
[0161] (14-1)如果比较验证通过，则进行区块链接(见图13)；
[0162] (14-2)如果比较验证不通过，则废弃所接收的区块数据、区块头数据，进入 (1)。
[0163] 参见图7，是图6中所述的数字签名的具体处理流程：输入交易数据集合，计算该交易数据的HASH256值，使用secp256k1算法对交易数据的HASH256值和监管节点的私钥加密成交易签名消息(具体的签名计算过程与比特币交易系统相同)，即待验证的消息。参见图8，是图6中所述的交易验证的具体处理流程：从本节点存储的用户文件中读取监管节点的公钥，对待验证的交易签名消息自动进行验证处理(验证计算过程与比特币交易系统相同)：
[0164] (1)如果自动验证通过，则进入(3)；
[0165] (2)如果自动验证不通过，则进入(5)；
[0166] (3)人工验证处理:在页面上解析并展现本笔交易的交易结构数据和附件文件，供用户人工审核验证：
[0167] (4)如果人工验证通过，则输出1(表示“真”或“通过”)，结束。
[0168] (5)输出0(表示“假”或“不通过”)，结束。
[0169] 参见图9，是图6中所述的共识判定的具体处理流程：接收某笔交易的所有相关用户对应的交易节点系统发送的验证结果，判断其值是否全部为1(1表示验证通过，0表示验证不通过)，是则返回共识判定结果为“真”(值为1)，否则返回共识判定结果为“假”(值为0)。
[0170] 参见图10，是图6中所述的区块生成的具体处理流程：
[0171] (1)获取版本号、交易码、交易数据；
[0172] (2)赋值合约序号(该字段为预留的智能合约号，目前赋值为00000000)；
[0173] (3)对交易数据进行HASH256计算，得到Merkle根；
[0174] (4)置请求标识，并用本用户的私钥签名，发送至监管节点系统；
[0175] (5)监管节点系统接收并验证请求标识：
[0176] (5-1)如果验证通过，进入(6)；
[0177] (5-2)如果验证不通过，结束。
[0178] (6)监管节点系统组织时间戳、交易顺序号、前向区块指针，并用监管节点私钥签名，发送至对应交易节点系统；
[0179] (7)对应交易节点系统接收并验证：
[0180] (7-1)如果验证通过，进入(8)；
[0181] (7-2)如果验证不通过，结束。
[0182] (8)按图20(区块链示意图)和表1(区块结构)、表2(区块头结构)格式组织区块数据；
[0183] (9)计算本区块头的HASH256值，作为本区块数据的文件名；
[0184] (10)检查交易模型文件中，该交易码对应的附件标志的值：
[0185] (10-1)如果该值为0，则结束；
[0186] (10-2)如果值为1，则将该区块文件名也作为附件文件名，如果有多个附件文件则分别依次命名为“区块文件名-1”，“区块文件名-2”，…。结束。
[0187] 参见图11，是图6中所述的区块存储的具体处理流程：读取用户文件中该用户地址对应的用户类型值(用户文件存储结构见图21至图23，其中，用户类型值为0表示监管用户，为1表示DBA用户，为2表示普通PC交易用户，为3表示ATM用户，为4表示移动用户)：
[0188] (1)如果值为0、1、2则为本地存储。在系统规定的目录下存储区块数据文件，在系统规定的目录下存储附件文件簇。结束。
[0189] (2)如果值为3、4则为云端存储。针对云端存储的情况，在系统为该用户申请的指定目录下存储区块数据文件，在系统为该用户申请的指定目录下存储附件文件簇。结束。
[0190] 参见图12，是图6中所述的比较验证的具体处理流程：接收某笔交易相关交易节点系统发送的区块头数据、区块数据：
[0191] (1)重新计算区块数据中交易数据的HASH256值，将该值与区块数据中的 Merkle根比较：
[0192] (2)如果不等则认为区块数据被篡改，返回比较验证结果为0(假)，结束。
[0193] (3)如果相等，则计算区块数据的区块头数据项的HASH256值，将该值与区块数据文件的文件名、附件数据文件的文件名前缀比较：
[0194] (3-1)如果都相等，再将区块数据中区块头的各项数据与其它节点发送的区块头数据项进行逐项比较：
[0195] (3-1-1)如果都相等，则返回比较验证结果为1(真)，结束。
[0196] (3-1-2)否则返回0(假)，结束。
[0197] (3-2)否则返回0(假)，结束。
[0198] 参见图13，是图6中所述的区块链接的具体处理流程：获取比较验证结果：
[0199] (1)如果为真，则将区块数据、可能的附件数据分别存储于监管节点系统指定的目录下，将区块数据的文件名写入到云端区块链文件中(云端区块链文件的存储结构见图27)，结束。
[0200] (2)否则，废弃区块数据和附件数据，结束。
[0201] 参见图14，是审计服务流程，当业务数据出现异常时，监管节点实时预警，另外，在区块链展现的基础上，提供多种服务。其中，区块链展现流程见图15；事件是否真实发生证明的处理流程见图16；事件顺序关系证明的处理流程见图17；区块数据是否被篡改证明的处理流程见图18；业务数据重建线索服务流程见图19。
[0202] 参见图15，是图14中所述的区块链展现的具体处理流程：监管节点打开云端区块链文件(见图27)，将行数标记H设为1：
[0203] (1)读取第H行区块链文件名的值，将值赋给P：
[0204] (2)将P与本发明约定的创世区块值比较：
[0205] (2-1)如果相等，则结束。
[0206] (2-2)如果不等，则进入(3)；
[0207] (3)在监管节点指定目录下查找文件名等于P的区块文件，解析该区块数据，重新计算Merkle树根、区块头HASH256值；
[0208] (4)将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与 P比较：
[0209] (4-1)如果都相等，则进入(5)；
[0210] (4-2)如果不全相等或都不等，则进入(7)；
[0211] (5)在监管节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
[0212] (6)H＝H+1，进入(1)。
[0213] (7)按照先DBA用户、后普通交易用户的顺序，分别在其对应目录下查找文件名＝P的区块文件：
[0214] (7-1)如果都未找到，则结束。
[0215] (7-2)否则，进入(8)；
[0216] (8)解析该区块数据，重新计算Merkle树根、区块头HASH256值；
[0217] (9)将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与 P比较：
[0218] (9-1)如果都相等，则进入(10)；
[0219] (9-2)如果不全相等或都不等，则进入(7)；
[0220] (10)在该节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
[0221] (11)H＝H+1，进入(1)。
[0222] 参见图16，是图14中所述的事件是否真实发生证明的具体处理流程：接收输入的事件具体特征值，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
[0223] (1)将区块中的交易数据与输入的事件具体特征值进行匹配：
[0224] (1-1)如果匹配，则用红色框标记该区块(表示找到)，结束；
[0225] (1-2)如果不匹配，则读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
[0226] (2)判断该区块是否创世区块：
[0227] (2-1)如果是，则结束；
[0228] (2-2)如果不是，则解析该区块，进入(1)。
[0229] 参见图17，是图14中所述的事件顺序关系证明的具体处理流程：接收输入的事件通用特征值(比如交易码)，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
[0230] (1)将区块中的交易数据与输入的事件通用特征值进行匹配：
[0231] (1-1)如果匹配，则用红色框标记该区块(表示找到)，进入(2)；
[0232] (1-2)如果不匹配，进入(2)；
[0233] (2)读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
[0234] (3)判断该区块是否创世区块：
[0235] (3-1)如果是，则结束；
[0236] (3-2)如果不是，则解析该区块，进入(1)。
[0237] 参见图18，是图14中所述的区块数据是否被篡改证明的具体处理流程：在已经展现的区块链上，从链尾区块开始检索区块：
[0238] (1)分别读取监管节点、DBA节点、相关用户节点的对应区块；
[0239] (2)解析对应区块，验证Merkle根、区块头HASH256值；
[0240] (3)分别与当前区块链上对应区块的Merkle根、区块头HASH256值比较，判断值是否相等：
[0241] (3-1)如果都相等，则进入(4)。
[0242] (3-2)否则，记录“某节点某区块被篡改(删除/修改)”，进入(4)。
[0243] (4)读取当前区块链上区块的前一区块指针，检索区块链上下一区块；
[0244] (5)判断是否是创世区块：
[0245] (5-1)如果是，则结束。
[0246] (5-2)否则，进入(2)。
[0247] 参见图19，是图14中所述的业务数据重建线索服务的具体流程：在监管节点可访问的云端指定目录下，打开异常交易数据文件(见图28)，读取所有交易验证未通过的数据记录，按时间递增顺序排列，解析每一条数据记录，形成数据重建线索列表，列表内容包括：时间、交易节点数、用户地址、交易数据、操作指令。
[0248] 参见图20，区块链示意图：每一个区块数据包括区块头和区块体两个部分，区块头字节数为定长(90字节)，其存储结构见表2；区块体包含区块头和交易数据，不定长，其存储结构见表1。每一个区块通过前向区块指针(Prev-Block Pointer)链接到区块链上，前向区块指针的值即为前向区块的区块头HASH256 值，区块链的链首区块称为创世区块。本发明中，用以下值作为创世区块HASH256 值：8D7253181C78C095522AF0098D1E2D8CE84BEADC2C3B141C
[0249] 16A72555F83404A0。
[0250] 监管系统指定目录下存在一个区块链链尾文件(该文件永远仅有一条记录，存储结构见图26)，监管节点系统每链接一个区块到链上，则更新区块链链尾文件中保存的当前区块链链尾的文件名。
[0251] 参见图21～23，用户文件存储结构示意图：描述了业务系统中各类用户的用户类型、自然属性、地址、公钥、访问入口、HOME、加入联盟链日期、前述属性的HASH256值，每个数据项之间用“；”隔离，每个用户作为一行存储，行尾用“#”标注。其中，用户类型定义为：
[0252] 0 监管节点
[0253] 1 DBA用户
[0254] 2 普通PC用户
[0255] 3 ATM用户
[0256] 4 移动设备用户
[0257] 其中，公钥(32个字符)、地址(20个字符)是由该用户私钥(32个字符)经过特定计算而来，但公钥、地址无法推算出私钥。
[0258] 参见图24，交易模型文件存储结构示意图：描述了各业务系统中各事件(事件处理结果即交易)的交易编码、交易名称、交易结构、是否有附件、交易描述和前述属性的HASH256值。
[0259] 其中，交易码为00至99；
[0260] 其中，交易结构是一个集合，是业务系统中某事件的抽象，由业务数据库中的特定数据项组成；
[0261] 其中，附件标志为1表示该事件处理结果有附件，0表示无附件。
[0262] 文件中每个数据项之间用“；”隔离，每个交易作为一行存储，行尾用“#”标注。
[0263] 参见图25，交易顺序文件存储结构示意图：描述了每个交易码名下当前的交易数量，主要由交易码、当前顺序号、前述属性的HASH256值组成。当前顺序号为8位10进制数字。文件中每个数据项之间用“；”隔离，每个交易码对应一行存储，行尾用“#”标注。
[0264] 参见图26，区块链链尾文件存储结构示意图：记录区块链链尾区块的区块头HASH256值(即链尾区块的文件名)，该文件永远仅有一条记录，数据项之间用“；”隔离，文件结束符为“#”。
[0265] 参见图27，云端区块链文件存储结构示意图：在监管节点可访问的云端，用于依次存储所有区块文件名的数据文件，包含区块文件名、该文件名的 HASH256值，文件中每个数据项之间用“；”隔离，每个区块对应一行存储，行尾用“#”标注。初始时，该文件中存储了创世区块的文件名。
[0266] 参见图28，异常交易数据文件存储结构示意图：在监管节点可访问的云端，用于存储异常交易(即交易相关用户验证没有一致通过的交易)数据的文件，包含时间、交易数据集合、交易节点数、该交易相关用户的地址、交易操作指令、前述属性的HASH256值。用于异常数据实时预警和业务数据重建线索服务。文件中每个数据项之间用“；”隔离，每次异常交易对应一行存储，行尾用“#”标注。
[0267] 其中，时间格式为YYYYMMDDhhmmss；
[0268] 其中，交易操作指令是引起业务数据变化的SQL语句，由桥接程序输出。
[0269] 参见表1，区块结构：定义了本发明使用的区块结构，包括区块头、区块体。
[0270] 参见表2，区块头结构：定义了本发明使用的区块头结构。其中，合约序号目前的值为00000000。
[0271] 本发明的多交易模式联盟链，通过桥接实现与业务系统之间进行低耦合的实时的数据关联；通过交易模型定制，将业务系统的事件处理转换为区块链技术中的交易；通过授权/许可，将交易用户的范围扩大到PC用户、移动设备用户、 ATM用户；将现有区块链技术中仅有的本地、区块存储扩展到本地或云端、区块存储及附件存储。
[0272] 功能上，多交易模式联盟链分为监管节点系统和交易节点系统。
[0273] 服务上，多交易模式联盟链可以可视化提供如下服务：1)事件存在证明；2) 事件序列证明；3)交易用户、数据管理员(DBA)、监管节点篡改区块数据的发现； 4)被篡改业务数据重建的线索；5)异常交易的实时预警。
[0274] 性能上，扩展了交易用户范围；扩展了存储类型和存储内容；创新了交易验证机制、共识判定机制、区块生成机制、区块存储机制、比较验证机制、区块链接机制；交易信息仅在相关者与监管节点之间传播；只有交易的相关者生成并存储区块，无关者不会生成与存储；区块生成的效率不再受人为控制，而是由监管节点系统和相关交易节点系统自身的处理速度确定；监管节点系统除审计服务外，无人值守运行；交易节点系统除人工验证环节外，无人值守运行。
[0275] 架构上，采用与比特币交易系统相同的JSON RPC点对点通信机制。
[0276] 安全性上，用户的私钥、公钥、地址的计算采用与比特币交易系统相同的算法；系统依赖的数据文件(如用户文件、交易模型定制文件、交易顺序文件、区块链链尾文件、云端区块链文件、异常交易数据文件)中，每一条数据记录都有 HASH256校验数据项，用于判断该记录数据项是否被篡改；网络广播(监管节点系统与交易节点系统之间通信)采用与比特币交易系统相同的数字签名与验证算法；在交易验证环节，采用比特币交易系统的自动验证处理外，增加了人工验证处理，使得非法交易(外部入侵篡改数据、DBA私自篡改数据等)能够及时被发现并实时预警；采用“一致通过，方为共识”的原则进行交易的共识判定；只有交易相关者生成的区块完全一致，才能将此区块链接到区块链上；每一个区块被链接到区块链上，将同步在云端记录该区块的文件名(即区块头的HASH256值)，使得一旦区块被链接到区块链上，即使监管节点篡改区块数据也能被发现。
[0277] 综上所述，本发明既保留了区块链技术的核心内涵---“去中心化、非服务器架构，结构巧妙、算法安全、带宽占用小、防抵赖、防篡改，在一个不可信任的环境下低成本、无须积累地获得可信的结果”，又能低成本、低耦合地适应高价值数据的安全保护及“原始生产者”证明等方面的应用。
[0278] 实施例1：(知识/实物)产权登记系统
[0279] 一个(知识/实物)产权登记系统，由产权登记员按照规定的业务流程操作，操作结果为：对符合登记条件的申请者进行产权登记，并发放产权登记证书。该系统由DBA统一维护管理业务数据库。
[0280] 假定该系统使用单位：A市产权中心；
[0281] 假定产权登记员甲在该系统中的用户名：zhangwei，密码为：zw7891；
[0282] 假定产权登记员乙在该系统中的用户名：wangfang，密码为：wf3456；
[0283] 假定DBA在该系统中的用户名：admin，密码为：admin123；参见表1和表2[0284]
[0285]
[0286] 表1
[0287]Size(Byte) Item(数据项)
4Byte Version(版本号)
32Byte Prev-Block(前向指针)
32Byte Merkle root(Merkle树根)
4Byte Timestamp(时间戳)
2Byte TransactionID(交易码)
8Byte TransactionNum(交易序号)
8Byte ContractNum(合约序号)
4Byte Version(版本号)
32Byte Prev-Block(前向指针)
32Byte Merkle root(Merkle树根)
4Byte Timestamp(时间戳)
2Byte TransactionID(交易码)
8Byte TransactionNum(交易序号)
8Byte ContractNum(合约序号)
[0288] 表2
[0289] 假定业务数据库中存储产权登记信息的数据表为T1，结构为：参见表3
[0290]
[0291]
[0292] 假定数据库端在E:\FileData目录下存储产权登记证书文件，以登记号作为文件名，JPG格式文件。
[0293] 我们对该业务系统做如下抽象：
[0294] 交易泛化：产权登记事件；
[0295] 交易结构：{产权登记机构，产权登记人，DBA，申请者名称，产权名称，产权登记号，证书文件}
[0296] 附件(交易证据)：产权登记证书
[0297] 交易相关用户：产权登记员、DBA；
[0298] 存储属性：在PC上操作，本地存储。有附件：产权登记证书(图片文件)。
[0299] 步骤S01：初始化(仅执行一次)。
[0300] 步骤S01-01：在该系统网络中指定PC上部署监管节点系统，在产权登记员甲、乙和DBA操作的PC上分别部署交易节点系统，并通过各交易节点的版本管理程序完成联盟链内各节点的版本统一；
[0301] 步骤S01-02：运行监管节点系统的授权/许可程序，分别为监管节点、产权登记员甲、产权登记员乙和DBA建立联盟链用户，计算各自的私钥、公钥、地址，设置其入盟日期，配置其访问入口和HOME目录。如下(地址、公钥、SHA256值省略，以下相同)：
[0302] 0；监管者；地址；公钥；192.168.99.199/8080；E:\TranSys；20180101；SHA256#[0303] 1；DBA；地址；公钥；192.168.99.198/8080；E:\TranSys；20180101；SH2A56#[0304] 2；zhangwei；地址；公钥；192.168.99.190/8080；E:\TranSys；20180101；SHA256#[0305] 2；wangfang；地址；公钥；192.168.99.191/8080；E:\TranSys；20180101；SHA256#[0306] 步骤S01-03：执行监管节点的交易模型定制程序，对该业务系统的交易模型进行配置，如下：
[0307] 00；产权登记；{！A市产权中心,OperName,！admin,RequireName,ResultName, RusultNum,ResultFileName}；1；一次产权登记事件结果的记载；SHA256#
[0308] 其中，！表示紧跟着的是常数。
[0309] 步骤S01-04：在该业务系统的数据库端部署、配置桥接程序，对T1表进行监听，使其能实时、自动捕捉对T1表的所有Insert、Update、Delete操作指令及其操作结果对应的记录数据，按照该交易码的交易模型结构，抽取对应数据，输出给监管节点系统。由于该桥接程序实时自动执行，因此，所有对T1表的所有 Insert、Update、Delete操作指令及操作结果(包括正常的事件处理或DBA利用技术优势直接篡改、伪造数据或黑客入侵数据库篡改、伪造数据)都将自动输出给监管节点系统。比如：
[0310] 交易数据：{A市产权中心,zhangwei,admin,刘大维,房屋产权登记,A1800678, E:\FileData\A1800678.jpg}
[0311] 交易指令：
[0312] INSERTINTOT1(ID,RequireName,RequireThing,ResultName,ResultNum,OperNam e,OperDate,ResultFileName)VALUES(35,“刘大维”,“产权登记”,“房屋产权登记证”,“A1800678”,“zhangwei”,20180101, “E:\FileData\A1800678.jpg”)
[0313] 步骤S02：交易过程(日常运行)。
[0314] 步骤S02-01：监管节点系统对接收的交易数据进行数字签名，如下(r,s是依据私钥和随机数计算出的签名)：
[0315] {A市产权中心,zhangwei,admin,刘大维,房屋产权登记,A1800678, E:\FileData\A1800678.jpg}，r,s.
[0316] 步骤S02-02：监管节点系统将上述签名后的数据发送给该笔交易相关的用户 (zhangwei和admin)所在的交易节点系统。
[0317] 步骤S02-03：该笔交易相关用户(zhangwei和admin)的交易节点系统接收待验证的数据，进行交易验证。
[0318] 步骤S02-03-01：自动解密验证。进行解密(依据对应的公钥计算出v)，如果 v＝r，则自动验证通过，进入步骤S02-03-02；否则，置验证结果为“假”，进入步骤S02-04。
[0319] 步骤S02-03-02：人工验证。取出交易数据，解析为：
[0320] “zhangwei”同志对“刘大伟”申请的“房屋产权登记”进行了操作，证书号为“A1800678”，对应证书文件(点击可展示证书图片)。
[0321] 请对该事件的真实性进行确认：[]真[]假
[0322] 接收人工验证结果，如果选择“真”，则置验证结果为“真”；如果选择“假”，则置验证结果为“假”。
[0323] 步骤S02-04：交易节点系统对自己的交易验证结果进行签名，发送至监管节点系统；
[0324] 步骤S02-05：监管节点系统分别接收各自交易节点系统的签名消息，解密验证。
[0325] 步骤S02-05-01：如果验证通过，则进入步骤S02-06。
[0326] 步骤S02-05-02：如果验证不通过，则进入步骤S02-01。
[0327] 步骤S02-06：监管节点系统进行共识判定。
[0328] 步骤S02-06-01：如果所有交易节点系统发送的验证结果都为“真”，则共识判定为“真”，进入步骤S02-07。
[0329] 步骤S02-06-02：如果所有交易节点系统发送的验证结果不全为“真”，则共识判定为“假”，进入步骤S02-01。
[0330] 步骤S02-07：监管节点系统对共识判定结果签名，并发送给相关交易节点系统。
[0331] 步骤S02-08：相关交易节点系统接收该签名消息，解密验证。
[0332] 步骤S02-08-01：如果验证通过，进入步骤S02-09。
[0333] 步骤S02-08-02：如果验证不通过，进入步骤S02-01。
[0334] 步骤S02-09：交易节点系统区块生成。
[0335] 步骤S02-09-01：交易节点系统向监管节点系统请求时间戳、交易顺序号、链尾指针，并将请求信息签名，发送至监管节点系统；
[0336] 步骤S02-09-02：监管节点系统对请求签名进行解密验证：如果验证不通过，置返回结果为“空”；否则，计算、检索出对应值并置于返回结果。
[0337] 步骤S02-09-03：对返回结果值进行签名后发送给对应的交易节点系统。
[0338] 步骤S02-10：相关交易节点系统接收该签名消息，解密验证。
[0339] 步骤S02-10-01：如果验证通过，进入步骤S02-11。
[0340] 步骤S02-10-02：如果验证不通过，进入步骤S02-01。
[0341] 步骤S02-11：按区块结构进行数据项赋值。计算区块头的HASH256值。
[0342] 步骤S02-12：交易节点系统进行区块存储：
[0343] 步骤S02-12-01：打开用户文件，获取本用户的存储位置；打开交易模型文件，读取本交易的附件属性值；
[0344] 步骤S02-12-02：在存储位置的指定子目录下，以区块头的HASH256值为命名存储区块数据；在存储位置的另一指定子目录下，以区块头的HASH256值为命名存储附件文件。
[0345] 步骤S02-12-03：DBA用户对区块数据、附件文件进行签名，并发送至监管节点系统；zhangwei用户对区块头数据进行签名，并发送至监管节点系统。
[0346] 步骤S02-13：监管节点系统分别接收各自交易节点系统发送的签名消息，解密验证。
[0347] 步骤S02-13-01：如果解密验证成功，进入步骤S02-14。
[0348] 步骤S02-13-02：如果解密验证失败，进入步骤S02-01。
[0349] 步骤S02-14：监管节点系统进行比较验证：
[0350] 步骤S02-14-01：针对区块数据，计算Merkle根，与区块中的Merkle根比较：
[0351] 步骤S02-14-01-01：如果相等，进入步骤S02-14-02。
[0352] 步骤S02-14-01-02：如果不等，进入步骤S02-01。
[0353] 步骤S02-14-02：针对区块数据，计算区块头的HASH256值，与区块文件名和附件文件名比较：
[0354] 步骤S02-14-02-01：如果相等，进入步骤S02-14-03。
[0355] 步骤S02-14-02-02：如果不等，进入步骤S02-01。
[0356] 步骤S02-14-03：将区块数据中的头部分数据项与其它用户发送的区块头数据项进行逐一比较：
[0357] 步骤S02-14-03-01：如果相等，进入步骤S02-15。
[0358] 步骤S02-14-03-02：如果不等，进入步骤S02-01。
[0359] 步骤S02-15：返回比较验证结果为“真”。
[0360] 步骤S02-16：监管节点系统进行区块链接：
[0361] 步骤S02-16-01：打开用户文件，获取存储位置(HOME目录)，在规定的子目录下以区块头HASH256值作为文件名，存储区块数据；在规定的另一子目录下以区块头HASH256值作为文件名，存储附件数据；
[0362] 步骤S02-16-02：打开云端区块链文件，将区块文件名追加到该文件中；
[0363] 步骤S02-16-03：打开链尾文件，用区块文件名更新该文件的唯一一条记录。
[0364] 步骤S02-17：进入步骤S02-01。
[0365] 步骤S03：审计服务(除异常数据实时预警为实时自动执行外，其它服务根据需要随机执行)。
[0366] 步骤S03-01：判断是否有异常数据存储：
[0367] 步骤S03-01-01：有，则对异常数据进行解析并实时预警。预警结束进入步骤S03。
[0368] 步骤S03-01-02：无，则进入步骤S03。
[0369] 步骤S03-02：展现区块链：监管节点打开云端区块链文件，将行数标记H设为1：
[0370] 步骤S03-02-01：读取第H行区块链文件名的值，将值赋给P：
[0371] 步骤S03-02-02：将P与本发明约定的创世区块值比较：
[0372] 步骤S03-02-02-01：如果相等，则进入步骤S03。
[0373] 步骤S03-02-02-02：如果不等，则进入S03-02-03；
[0374] 步骤S03-02-03：在监管节点指定目录下查找文件名等于P的区块文件，解析该区块数据，重新计算Merkle树根、区块头HASH256值；
[0375] 步骤S03-02-04：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
[0376] 步骤S03-02-04-01：如果都相等，则进入步骤S03-02-05；
[0377] 步骤S03-02-04-02：如果不全相等或都不等，则进入步骤S03-02-07；
[0378] 步骤S03-02-05：在监管节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
[0379] 步骤S03-02-06：H＝H+1，进入步骤S03-02-01。
[0380] 步骤S03-02-07：按照先DBA用户、后普通交易用户的顺序，分别在其对应目录下查找文件名＝P的区块文件：
[0381] 步骤S03-02-07-01：如果都未找到，则进入步骤S03。
[0382] 步骤S03-02-07-02：否则，进入步骤S03-02-08；
[0383] 步骤S03-02-08：解析该区块数据，重新计算Merkle树根、区块头HASH256值；
[0384] 步骤S03-02-09：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
[0385] 步骤S03-02-09-01：如果都相等，则进入步骤S03-02-10；
[0386] 步骤S03-02-09-02：如果不全相等或都不等，则进入步骤S03-02-07；
[0387] 步骤S03-02-10：在该节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
[0388] 步骤S03-02-11：H＝H+1，进入步骤S03-02-01。
[0389] 步骤S03-03：证明事件发生。接收输入的事件具体特征值，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
[0390] 步骤S03-03-01：将区块中的交易数据与输入的事件具体特征值进行匹配：
[0391] 步骤S03-03-01-01：如果匹配，则用红色框标记该区块(表示找到)，进入步骤S03-03；
[0392] 步骤S03-03-01-02：如果不匹配，则读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
[0393] 步骤S03-03-02：判断该区块是否创世区块：
[0394] 步骤S03-03-02-01：如果是，则进入步骤S03-03；
[0395] 步骤S03-03-02-02：如果不是，则解析该区块，进入步骤S03-03-01。
[0396] 步骤S03-04：证明事件序列关系。接收输入的事件通用特征值(比如交易码)，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
[0397] 步骤S03-04-01：将区块中的交易数据与输入的事件通用特征值进行匹配：
[0398] 步骤S03-04-01-01：如果匹配，则用红色框标记该区块(表示找到)，进入步骤S03-04-02；
[0399] 步骤S03-04-01-02：如果不匹配，进入步骤S03-04-02；
[0400] 步骤S03-04-02：读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
[0401] 步骤S03-04-03：判断该区块是否创世区块：
[0402] 步骤S03-04-03-01：如果是，则进入步骤S03-04；
[0403] 步骤S03-04-03-02：如果不是，则解析该区块，进入步骤S03-04-01。
[0404] 步骤S03-05：区块数据是否被篡改证明。在已经展现的区块链上，从链尾区块开始检索区块：
[0405] 步骤S03-05-01：分别读取监管节点、DBA节点、相关用户节点的对应区块；
[0406] 步骤S03-05-02：解析对应区块，验证Merkle根、区块头HASH256值；
[0407] 步骤S03-05-03：分别与当前区块链上对应区块的Merkle根、区块头HASH256 值比较，判断值是否相等：
[0408] 步骤S03-05-03-01：如果都相等，则进入步骤S03-05-04。
[0409] 步骤S03-05-03-02：否则，记录“某节点某区块被篡改(删除/修改)”，进入步骤S03-05-04。
[0410] 步骤S03-05-04：读取当前区块链上区块的前一区块指针，检索区块链上下一区块；
[0411] 步骤S03-05-05：判断是否是创世区块：
[0412] 步骤S03-05-05-01：如果是，则进入步骤S03-05。
[0413] 步骤S03-05-05-02：否则，进入步骤S03-05-02。
[0414] 步骤S03-06：业务数据重建线索。
[0415] 步骤S03-06-01：在监管节点可访问的云端指定目录下，打开异常交易数据文件，读取所有交易验证未通过的数据记录。
[0416] 步骤S03-06-02：按时间递增顺序排列，解析每一条数据记录，形成数据重建线索列表，列表内容包括：时间、用户地址、交易节点数、交易数据、操作指令。
[0417] 实施例2：一个银行卡储蓄系统
[0418] 一个银行卡储蓄系统，某市X银行发行了N张银行卡，允许卡主在M个ATM机上存取款，后端由DBA统一维护管理业务数据库。
[0419] DBA在该系统中的用户名：admin，密码为：manage789；
[0420] 业务数据库中客户资料表T1，结构为：参见表4
[0421]
[0422]
[0423] 业务数据库中银行卡存款信息表为T2，结构为：参见表5
[0424]
[0425] 业务数据库中银行卡取款信息表为T3，结构为：参见表6
[0426]
[0427]
[0428] 我们对该业务系统做如下抽象：
[0429] 交易泛化：银行卡主在ATM上存款；银行卡主在ATM上取款。
[0430] 相关用户：银行卡卡主(ATM用户)、DBA。
[0431] 存储属性：ATM节点无法存储区块，需通过云端构建虚拟节点。无附件数据。
[0432] 交易结构：{交易码，卡主，DBA，存款金额，存款ATM号}
[0433] {交易码，卡主，DBA，取款金额，取款ATM号}
[0434] 步骤S01：初始化(仅执行一次)。
[0435] 步骤S01-01：在该系统网络中指定PC上部署监管节点系统，在DBA操作的PC 上部署交易节点系统，对T1表中的所有状态值为1的客户建立云端空间，并分别部署交易节点系统，通过各交易节点的版本管理程序完成联盟链内各节点的版本统一；
[0436] 步骤S01-02：运行监管节点系统的授权/许可程序，分别为监管节点、各卡主和DBA建立联盟链用户，计算各自的私钥、公钥、地址，设置其入盟日期，配置其访问入口和HOME目录。如下：
[0437] 0；监管者；地址；公钥；192.168.99.199/8080；E:\TranSys；20180101；SHA256#[0438] 1；DBA；地址；公钥；192.168.99.100/8080；E:\TranSys；20180101；SHA256#[0439] 3；zhangsan；地址；公钥；135.168.99.190/8080；E:\TranSys；20180101；SHA256#[0440] 3；lisi；地址；公钥；135.168.99.191/8080；E:\TranSys；20180101；SHA256#[0441] ……
[0442] 步骤S01-03：执行监管节点的交易模型定制程序，对该业务系统的交易模型进行配置，如下：
[0443] 01；ATM存款；{CustmerName,！admin,InputValue,InputATMNum}；0；一次银行卡在ATM上存款事件结果的记载；H256#
[0444] 02；ATM取款；{CustmerName,！admin,OutputValue,OutputATMNum}；0；一次银行卡在ATM上取款事件结果的记载；H256#
[0445] 其中，！表示紧跟着的是常数。
[0446] 步骤S01-04：在该业务系统的数据库端部署、配置桥接程序，对T2表、T3表进行监听，使其能实时、自动捕捉对T2表、T3表的所有Insert、Update、Delete 操作指令及其操作结果对应的记录数据，按照该交易码的交易模型结构，抽取对应数据，输出给监管节点系统。由于该桥接程序实时自动执行，因此，所有对T2表、T3表的所有Insert、Update、Delete操作指令及操作结果(包括正常的事件处理或DBA利用技术优势直接篡改、伪造数据或黑客入侵数据库篡改、伪造数据)都将自动输出给监管节点系统。比如：
[0447] 交易数据：{01,zhangsan,admin,808.90,point098}
[0448] {02,lisi,admin,100.50,point048}
[0449] 交易指令：省略。
[0450] 步骤S02：交易过程(日常运行)。
[0451] 步骤S02-01：监管节点系统对接收的交易数据进行数字签名，如下：
[0452] {01,zhangsan,admin,808.90,point098},r,s.
[0453] 步骤S02-02：监管节点系统将上述签名后的数据发送给该笔交易相关的用户 (zhangsan对应在云端、admin在指定PC上)所在的交易节点系统。
[0454] 步骤S02-03：该笔交易相关用户(zhangsan、admin)的交易节点系统接收待验证的数据，进行交易验证。
[0455] 步骤S02-03-01：自动解密验证。进行解密(计算v)，如果v＝r，则自动验证通过，进入步骤S02-03-02；否则，置验证结果为“假”，进入步骤S02-04。
[0456] 步骤S02-03-02：人工验证。zhangsan、admin用户分别执行。其中，向zhangsan 卡主的手机发送短信链接，zhangsan进入云端交易节点系统进行人工验证 (admin用户在PC上)。取出交易数据：
[0457] {01,zhangsan,admin,808.90,point098}
[0458] 解析为：
[0459] “zhangsan”同志在“point098”ATM机上“存款”808.90元。
[0460] 请对该事件的真实性进行确认：[]真[]假
[0461] 接收人工验证结果，如果选择“真”，则置验证结果为“真”；如果选择“假”，则置验证结果为“假”。
[0462] 步骤S02-04：交易节点系统对自己的交易验证结果进行签名，发送至监管节点系统；
[0463] 步骤S02-05：监管节点系统分别接收各自交易节点系统的签名消息，解密验证。
[0464] 步骤S02-05-01：如果验证通过，则进入步骤S02-06。
[0465] 步骤S02-05-02：如果验证不通过，则进入步骤S02-01。
[0466] 步骤S02-06：监管节点系统进行共识判定。
[0467] 步骤S02-06-01：如果所有交易节点系统发送的验证结果都为“真”，则共识判定为“真”，进入步骤S02-07。
[0468] 步骤S02-06-02：如果所有交易节点系统发送的验证结果不全为“真”，则共识判定为“假”，进入步骤S02-01。
[0469] 步骤S02-07：监管节点系统对共识判定结果签名，并发送给相关交易节点系统。
[0470] 步骤S02-08：相关交易节点系统接收该签名消息，解密验证。
[0471] 步骤S02-08-01：如果验证通过，进入步骤S02-09。
[0472] 步骤S02-08-02：如果验证不通过，进入步骤S02-01。
[0473] 步骤S02-09：交易节点系统区块生成。
[0474] 步骤S02-09-01：交易节点系统向监管节点系统请求时间戳、交易顺序号、链尾指针，并将请求信息签名，发送至监管节点系统；
[0475] 步骤S02-09-02：监管节点系统对请求签名进行解密验证：如果验证不通过，置返回结果为“空”；否则，计算、检索出对应值并置于返回结果。
[0476] 步骤S02-09-03：对返回结果值进行签名后发送给对应的交易节点系统。
[0477] 步骤S02-10：相关交易节点系统接收该签名消息，解密验证。
[0478] 步骤S02-10-01：如果验证通过，进入步骤S02-11。
[0479] 步骤S02-10-02：如果验证不通过，进入步骤S02-01。
[0480] 步骤S02-11：按区块结构进行数据项赋值。计算区块头的HASH256值。
[0481] 步骤S02-12：交易节点系统进行区块存储：
[0482] 步骤S02-12-01：打开用户文件，获取本用户的存储位置；打开交易模型文件，读取本交易的附件属性值；
[0483] 步骤S02-12-02：在存储位置的指定子目录下，以区块头的HASH256值为命名存储区块数据。
[0484] 步骤S02-12-03：DBA用户对区块数据、附件文件进行签名，并发送至监管节点系统；zhangwei用户对区块头数据进行签名，并发送至监管节点系统。
[0485] 步骤S02-13：监管节点系统分别接收各自交易节点系统发送的签名消息，解密验证。
[0486] 步骤S02-13-01：如果解密验证成功，进入步骤S02-14。
[0487] 步骤S02-13-02：如果解密验证失败，进入步骤S02-01。
[0488] 步骤S02-14：监管节点系统进行比较验证：
[0489] 步骤S02-14-01：针对区块数据，计算Merkle根，与区块中的Merkle根比较：
[0490] 步骤S02-14-01-01：如果相等，进入步骤S02-14-02。
[0491] 步骤S02-14-01-02：如果不等，进入步骤S02-01。
[0492] 步骤S02-14-02：针对区块数据，计算区块头的HASH256值，与区块文件名和附件文件名比较：
[0493] 步骤S02-14-02-01：如果相等，进入步骤S02-14-03。
[0494] 步骤S02-14-02-02：如果不等，进入步骤S02-01。
[0495] 步骤S02-14-03：将区块数据中的头部分数据项与其它用户发送的区块头数据项进行逐一比较：
[0496] 步骤S02-14-03-01：如果相等，进入步骤S02-15。
[0497] 步骤S02-14-03-02：如果不等，进入步骤S02-01。
[0498] 步骤S02-15：返回比较验证结果为“真”。
[0499] 步骤S02-16：监管节点系统进行区块链接：
[0500] 步骤S02-16-01：打开用户文件，获取存储位置(HOME目录)，在规定的子目录下以区块头HASH256值作为文件名，存储区块数据；
[0501] 步骤S02-16-02：打开云端区块链文件，将区块文件名追加到该文件中；
[0502] 步骤S02-16-03：打开链尾文件，用区块文件名更新该文件的唯一一条记录。
[0503] 步骤S02-17：进入步骤S02-01。
[0504] 步骤S03：审计服务(除异常数据实时预警为实时自动执行外，其它服务根据需要随机执行)。
[0505] 步骤S03-01：判断是否有异常数据存储：
[0506] 步骤S03-01-01：有，则对异常数据进行解析并实时预警。预警结束进入步骤S03。
[0507] 步骤S03-01-02：无，则进入步骤S03。
[0508] 步骤S03-02：展现区块链：监管节点打开云端区块链文件，将行数标记H设为1：
[0509] 步骤S03-02-01：读取第H行区块链文件名的值，将值赋给P：
[0510] 步骤S03-02-02：将P与本发明约定的创世区块值比较：
[0511] 步骤S03-02-02-01：如果相等，则进入步骤S03。
[0512] 步骤S03-02-02-02：如果不等，则进入S03-02-03；
[0513] 步骤S03-02-03：在监管节点指定目录下查找文件名等于P的区块文件，解析该区块数据，重新计算Merkle树根、区块头HASH256值；
[0514] 步骤S03-02-04：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
[0515] 步骤S03-02-04-01：如果都相等，则进入步骤S03-02-05；
[0516] 步骤S03-02-04-02：如果不全相等或都不等，则进入步骤S03-02-07；
[0517] 步骤S03-02-05：在监管节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
[0518] 步骤S03-02-06：H＝H+1，进入步骤S03-02-01。
[0519] 步骤S03-02-07：按照先DBA用户、后普通交易用户的顺序，分别在其对应目录下查找文件名＝P的区块文件：
[0520] 步骤S03-02-07-01：如果都未找到，则进入步骤S03。
[0521] 步骤S03-02-07-02：否则，进入步骤S03-02-08；
[0522] 步骤S03-02-08：解析该区块数据，重新计算Merkle树根、区块头HASH256值；
[0523] 步骤S03-02-09：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
[0524] 步骤S03-02-09-01：如果都相等，则进入步骤S03-02-10；
[0525] 步骤S03-02-09-02：如果不全相等或都不等，则进入步骤S03-02-07；
[0526] 步骤S03-02-10：在该节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
[0527] 步骤S03-02-11：H＝H+1，进入步骤S03-02-01。
[0528] 步骤S03-03：证明事件发生。接收输入的事件具体特征值，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
[0529] 步骤S03-03-01：将区块中的交易数据与输入的事件具体特征值进行匹配：
[0530] 步骤S03-03-01-01：如果匹配，则用红色框标记该区块(表示找到)，进入步骤S03-03；
[0531] 步骤S03-03-01-02：如果不匹配，则读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
[0532] 步骤S03-03-02：判断该区块是否创世区块：
[0533] 步骤S03-03-02-01：如果是，则进入步骤S03-03；
[0534] 步骤S03-03-02-02：如果不是，则解析该区块，进入步骤S03-03-01。
[0535] 步骤S03-04：证明事件序列关系。接收输入的事件通用特征值(比如交易码)，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
[0536] 步骤S03-04-01：将区块中的交易数据与输入的事件通用特征值进行匹配：
[0537] 步骤S03-04-01-01：如果匹配，则用红色框标记该区块(表示找到)，进入步骤S03-04-02；
[0538] 步骤S03-04-01-02：如果不匹配，进入步骤S03-04-02；
[0539] 步骤S03-04-02：读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
[0540] 步骤S03-04-03：判断该区块是否创世区块：
[0541] 步骤S03-04-03-01：如果是，则进入步骤S03-04；
[0542] 步骤S03-04-03-02：如果不是，则解析该区块，进入步骤S03-04-01。
[0543] 步骤S03-05：区块数据是否被篡改证明。在已经展现的区块链上，从链尾区块开始检索区块：
[0544] 步骤S03-05-01：分别读取监管节点、DBA节点、相关用户节点的对应区块；
[0545] 步骤S03-05-02：解析对应区块，验证Merkle根、区块头HASH256值；
[0546] 步骤S03-05-03：分别与当前区块链上对应区块的Merkle根、区块头HASH256 值比较，判断值是否相等：
[0547] 步骤S03-05-03-01：如果都相等，则进入步骤S03-05-04。
[0548] 步骤S03-05-03-02：否则，记录“某节点某区块被篡改(删除/修改)”，进入步骤S03-05-04。
[0549] 步骤S03-05-04：读取当前区块链上区块的前一区块指针，检索区块链上下一区块；
[0550] 步骤S03-05-05：判断是否是创世区块：
[0551] 步骤S03-05-05-01：如果是，则进入步骤S03-05。
[0552] 步骤S03-05-05-02：否则，进入步骤S03-05-02。
[0553] 步骤S03-06：业务数据重建线索。
[0554] 步骤S03-06-01：在监管节点可访问的云端指定目录下，打开异常交易数据文件，读取所有交易验证未通过的数据记录。
[0555] 步骤S03-06-02：按时间递增顺序排列，解析每一条数据记录，形成数据重建线索列表，列表内容包括：时间、用户地址、交易节点数、交易数据、操作指令。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 一种基于区块链技术的物联网隐私保护访问控制方法 | 2020-05-15 | 736 |
| 一种快速建立比特币区块链全节点地址索引的方法 | 2020-05-18 | 218 |
| 使用集中式或分布式分类账来提供信息证明的方法和设备 | 2020-05-22 | 152 |
| 使用区块链实现逻辑门功能 | 2020-05-25 | 1032 |
| 使用分布式散列表和点对点分布式分类账控制合约的履行的方法和系统 | 2020-05-26 | 839 |
| 使用区块链分发数据记录的系统和方法 | 2020-05-14 | 415 |
| 区块链之间的安全转移 | 2020-05-14 | 260 |
| 使用区块链的安全数据记录分发的方法和系统 | 2020-05-14 | 482 |
| 一种基于多重签名的比特币防盗方法 | 2020-05-24 | 711 |
| 一种区块链浏览器及区块链信息浏览方法 | 2020-05-23 | 679 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈