CN108389130B - 一种生成多交易模式联盟链的方法 - Google Patents

一种生成多交易模式联盟链的方法 Download PDF

Info

Publication number
CN108389130B
CN108389130B CN201810173747.5A CN201810173747A CN108389130B CN 108389130 B CN108389130 B CN 108389130B CN 201810173747 A CN201810173747 A CN 201810173747A CN 108389130 B CN108389130 B CN 108389130B
Authority
CN
China
Prior art keywords
block
transaction
data
file
verification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810173747.5A
Other languages
English (en)
Other versions
CN108389130A (zh
Inventor
张家锐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hefei College
Original Assignee
Hefei College
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hefei College filed Critical Hefei College
Priority to CN201810173747.5A priority Critical patent/CN108389130B/zh
Publication of CN108389130A publication Critical patent/CN108389130A/zh
Application granted granted Critical
Publication of CN108389130B publication Critical patent/CN108389130B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Software Systems (AREA)
  • Finance (AREA)
  • Computer Hardware Design (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computing Systems (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Power Engineering (AREA)
  • Technology Law (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种生成多交易模式联盟链的方法，包括监管节点***和交易节点***。前者部署在联盟链网络中指定PC上，通过桥接与业务***实时关联。后者部署在每一个用户节点本地或该用户节点地址对应的云端。交易用户可以在PC、移动设备、自动柜员机上操作。交易过程、数据交互、区块存储等采用加密处理。本发明方法，将传统的买卖交易泛化为业务***的事件处理，优化了交易验证、共识判定、区块生成、区块存储、比较验证、区块链接等机制，可提供事件是否发生、事件序列关系证明，业务数据异常的实时预警，被篡改业务数据的重建线索等服务，具有“去中心化”、安全、防抵赖、防篡改的技术特点，能低成本、无须积累地获得可信的结果。

Description

一种生成多交易模式联盟链的方法
技术领域
本发明涉及交易数据处理的技术领域，具体涉及一种生成多交易模式联盟链的方法。
背景技术
区块链(Blockchain)技术由中本聪(Satoshi Nakamoto)于2008年发明，具体内容记载于“比特币：一种点对点电子现金交易***”(Bitcoin:A Peer-to-Peer ElectronicCash System)。主要用来支撑“去中心化”的、非服务器架构的电子货币交易，具有结构巧妙、算法安全、带宽占用小、防抵赖、防篡改的技术特点，其最主要的应用特征是在一个不可信任的环境下低成本、无须积累地获得可信的结果。联盟链(Consortium Blockchain)是区块链中的一种，是一种需要注册许可的区块链，也称许可链(Permissioned Blockchain)。联盟链网络由若干个普通交易节点和唯一一个监管节点组成。目前，联盟链的代表为R3(Corda分布式账本)、Hyperledger。现有区块链核心技术具有以下技术特性：
1、单交易型的。在比特币交易***的区块链技术中，只能适应“买入”、“卖出”交易，并且其所有交易被转换为卖出方对买入方的“转出”交易模式；
2、交易验证和区块存储是不能带附件的。无法附加该交易过程或结果的图片、图像、音频、视频等证据资料；
3、区块数据是本地存储的。区块数据只能存储在交易节点本地，像移动设备、ATM等节点因为无法本地存储，是不能直接作为交易节点的；
4、区块生成速度是受控的。在比特币交易***中，区块生成是通过“挖矿”机制来实现的，受当前区块的“目标哈希值(Bits)”控制，大约每10分钟生成一个区块。
上述四个技术特性使得区块链技术只能应用于基于PC端的加密货币买入卖出交易，几乎不能直接应用于其它领域。
发明内容
本发明的目的是为了解决现有技术中区块链技术只能应用于基于PC端的加密货币买入卖出交易，不能直接应用于其它领域的问题。提供一种生成多交易模式联盟链的方法。
为了实现上述目的，本发明的技术方案如下：
一种生成多交易模式联盟链的方法，包括买卖交易泛化为业务***的事件处理，使得业务***的每次事件处理可以对应一次交易，
多交易模式联盟链与指定业务***之间通过桥接单元进行联结，桥接单元安装在业务***数据库端，实时触发各用户(包括DBA)对数据库的新增、删除、修改事件，参照该交易在“交易模型文件”中事先定制的交易结构，摘取当前事件记录中需要的数据项值，构建为交易结构，获取本事件的附件文件，传递给监管节点***；
交易的用户类型包括PC用户、移动设备用户、ATM用户，
多交易模式联盟链通过授权/许可单元，对业务***的各类用户(普通PC操作用户、数据管理员(DBA)、ATM用户、移动设备用户)计算地址、公钥、私钥，记录存储特征，申请本地或云端空间，授权/许可程序处理结果追加到用户文件中，用户的私钥、公钥、地址的计算规则同比特币交易***，其中，计算规则的原始输入分别为：
(1)PC用户、DBA：“用户名”+“密码”；
(2)移动设备用户：“设备码”；
(3)ATM用户：“开户行”+“账号/***”+“密码”；
交易生成的区块数据在本地存储或在该用户地址对应的云端存储，存储与事件对应的区块数据，或关联存储与事件相关的、多种格式的附件数据(如图片、图像、音频、视频文件)，
读取用户文件中该用户地址对应记录的用户类型值：
(1)如果值为0、1、2则为本地存储，在***规定的目录下存储区块数据文件，在***规定的目录下存储附件文件簇；
(2)如果值为3、4则为云端存储，针对云端存储的情况，在***为该用户申请的云端指定目录下存储区块数据文件，在***为该用户申请的云端指定目录下存储附件文件簇。
一种生成多交易模式联盟链的方法，还包括以下交易处理步骤：
步骤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。
本发明与现有技术相比，具有以下有益效果：
1、交易类型多样化，将传统的买卖交易泛化为业务***的事件处理，因此，一次数据库操作、一次审批、一次发证、一次就诊、一次责任认定、一次产权判决等各类高价值事件处理都可以作为交易；
2、存储内容多样化，不仅可以存储事件对应的区块数据，也可以关联存储与事件相关的、多种格式的附件数据(如图片、图像、音频、视频文件等证据或结果)；
3、存储类型多样化，区块数据可以在本地存储，也可以根据用户类型在该用户地址对应的云端存储；
4、用户类型多样化，可以是PC用户、移动设备用户、ATM用户；
5、区块生成速度由***处理速度决定，不做人为干涉。
具备了上述特性的联盟链，通过“桥接”与指定的业务***关联，为该业务***所处理的事件过程或结果提供防篡改、防抵赖、可信的区块链支撑。可用于证明某事件在某时刻确实发生、某些事件之间具有的序列关系，对业务数据异常(非法入侵篡改数据、DBA篡改数据)进行实时预警，为被篡改的业务数据重建提供线索等服务，极大地扩展了区块链技术的应用范围。
附图说明
图1是多交易模式联盟链***总体架构图；
图2是桥接示意图；
图3是授权/许可处理流程图；
图4是版本管理流程图；
图5是交易模型定制流程图；
图6是交易过程业务模型图；
图7是数字签名流程图，是图6中数字签名的具体处理过程；
图8是交易验证流程图，是图6中交易验证的具体处理过程；
图9是共识判定流程图，是图6中共识判定的具体处理过程；
图10是区块生成流程图，是图6中区块生成的具体处理过程；
图11是区块存储流程图，是图6中区块存储的具体处理过程；
图12是比较验证流程图，是图6中比较验证的具体处理过程；
图13是区块链接流程图，是图6中区块链接的具体处理过程；
图14是审计服务总体流程图；
图15是区块链展现的处理流程图，是图14中区块链展现的具体处理过程；
图16是事件是否发生证明的处理流程，是图14中事件是否发生证明的具体处理过程；
图17是事件顺序关系证明的处理流程，是图14中事件顺序关系证明的具体处理过程；
图18是区块数据是否被篡改证明的处理流程，是图14中区块数据是否被篡改证明的具体处理过程；
图19是数据重建线索服务的流程，是图14中数据重建线索的具体处理过程；
图20是区块链示意图；
图21是用户文件存储结构示意图(PC用户)；
图22是用户文件存储结构示意图(ATM用户)；
图23是用户文件存储结构示意图(移动用户)；
图24是交易模型文件存储结构示意图；
图25是交易顺序文件存储结构示意图；
图26是区块链链尾文件存储结构示意图；
图27是云端区块链文件存储结构示意图；
图28是异常交易数据文件存储结构示意图；
表1是区块结构；
表2是区块头结构。
具体实施方式
为使对本发明的结构特征及所达成的功效有更进一步的了解与认识，用以较佳的实施例及附图配合详细的说明，说明如下：
参见图1，多交易模式联盟链的技术架构为：通过联盟链网络(可以是局域网、广域网、互联网、移动网及其混合)将与指定业务***相关的PC用户(普通PC操作用户、数据管理员(DBA)或***管理员)、ATM用户、移动设备用户联结成联盟链成员。
多交易模式联盟链包括监管节点***、交易节点***。监管节点***安装部署在联盟链网络中指定PC或服务器上，交易节点***安装部署在每一个用户节点本地指定目录下或该节点地址对应的云端指定目录下。
监管节点***与交易节点***之间通过JSON RPC点对点(Peer to Peer)通信协议实现数据交互。
安全加密机制包括：
(1)用户的私钥、公钥、地址生成：使用SHA256、RIPEMD160加密方法(同比特币交易***)；
(2)交易数据的签名与验证：采用secp256k1加密方法(同比特币交易***)；
(3)区块头中的Merkle树根：使用SHA256方法迭代计算(同比特币交易***)；
(4)区块链接的指针：采用区块头的SHA256值(同比特币交易***)；
(5)区块数据的文件命名：采用区块头的SHA256值(同比特币交易***)。
监管节点***分为：(1)初始化部分；(2)交易过程处理部分；(3)审计服务部分。
(1)初始化部分。包括：授权/许可程序、监管端版本管理程序、交易模型定制程序、桥接程序。
1)桥接程序，见图2。
2)授权/许可程序，见图3。
3)版本管理程序，见图4。
4)交易模型定制程序，见图5。
(2)交易过程处理部分。包括：共识判定程序、时间戳生成器程序、交易顺序生成器程序、比较验证程序、区块链接程序。
1)共识判定程序，见图9。
2)时间戳生成程序。接收到某笔交易的相关方交易节点***发来的时间戳请求时，计算出当前时刻时间戳，返回给相关交易节点。
3)交易序号生成程序。接收到某笔交易的相关方交易节点***发来的交易顺序请求时，计算出当前该交易的顺序号，返回给相关交易节点。
4)比较验证程序，见图12。
5)区块链接程序，见图13。
(3)审计服务部分。包括：审计服务程序。
1)审计服务程序，见图14。
交易节点***。包括：交易端版本管理程序、交易验证程序、区块生成程序、区块存储程序。
1)交易端版本管理程序，见图4。
2)交易验证程序，见图8。
3)区块生成程序，见图10。
4)区块存储程序，见图11。
监管节点***与各交易节点***之间的业务协作逻辑，见图6。
参见图2，多交易模式联盟链与指定业务***之间通过桥接程序进行联结，桥接程序安装在业务***数据库端，实时触发各用户(包括DBA)对数据库的新增、删除、修改事件，参照该交易在“交易模型文件”中事先定制的交易结构，摘取当前事件记录中需要的数据项值，构建为交易结构，获取本事件的附件文件，传递给监管节点***，由监管节点***加工成数字签名(见图7)格式。参见图3，多交易模式联盟链通过授权/许可程序，对业务***的各类用户(普通PC操作用户、数据管理员(DBA)、ATM用户、移动设备用户)计算地址、公钥、私钥，记录存储特征，申请本地或云端空间，部署版本管理***。授权/许可程序处理结果追加到用户文件中。用户的私钥、公钥、地址的计算规则同比特币交易***。其中，计算规则的原始输入分别为：
(1)PC用户、DBA：“用户名”+“密码”；(2)移动设备用户：“设备码”；
(3)ATM用户：“开户行”+“账号/***”+“密码”。
其中，用户文件存储结构：
(1)PC操作用户、DBA的用户文件存储结构，见图21。
(2)ATM用户的用户文件存储结构，见图22。
(3)移动设备用户的用户文件存储结构，见图23。
参见图4，多交易模式联盟链通过监管节点端的版本管理程序和交易节点端的版本管理程序的协作来完成版本的统一与维护。其中，
交易节点端的版本管理程序一旦巡查到监管节点端的版本升级信号，则到监管节点指定目录下下载升级包(包括升级的程序和可能的数据文件)，更新升级本交易节点***。
其中，监管节点端的版本管理程序承担两项工作：(1)监管节点***本身的升级工作；(2)交易节点***升级的程序、数据文件打包，并置升级信号。参见图5，多交易模式联盟链通过交易模型定制程序，将所面向的业务***的事件特征抽象为交易结构，并配置该交易的交易码、交易名称、交易结构、附件标志、交易描述。计算该条记录的SHA256值(用于校验)，定制结果追加到交易模型文件。交易模型文件结构见图24。参见图6，多交易模式联盟链通过监管节点***与某笔交易相关的各交易节点***之间的协作来完成业务处理逻辑：
(1)监管节点***接收桥接程序输出的交易数据(含可能的附件数据)；
(2)监管节点***对交易数据进行数字签名(见图7)；
(3)监管节点***将签名消息发送给本交易相关的所有交易节点***；
(4)各相关的交易节点***接收该签名数据后，进行交易验证(见图8)；
(5)各相关的交易节点***对交易验证结果进行签名，发送至监管节点***；
(6)监管节点***接收该交易的所有签名后的验证结果后，解密验证；
(7)监管节点***进行共识判定(见图9)：
(7-1)如果共识判定的结果为未达成共识，则在云端指定目录下存储该异常交易数据(异常交易数据文件的存储结构见图28)，进入(1)。
(7-2)如果共识判定的结果为达成共识，进入(8)；
(8)监管节点***对共识判定结果进行数字签名，发送给相关的交易节点***；
(9)各相关的交易节点***接收签名消息后进行解密验证；
(10)各相关的交易节点***进行区块生成(见图10)；
(11)各相关的交易节点***进行区块存储(见图11)；
(12)DBA用户对生成的区块数据进行数字签名，并发送给监管节点***；其它交易用户对生成的区块的区块头数据进行数字签名，并发送给监管节点***；
(13)监管节点***接收相关交易节点***发送的签名消息，进行解密验证；
(14)监管节点***进行比较验证(见图12)：
(14-1)如果比较验证通过，则进行区块链接(见图13)；
(14-2)如果比较验证不通过，则废弃所接收的区块数据、区块头数据，进入 (1)。
参见图7，是图6中所述的数字签名的具体处理流程：输入交易数据集合，计算该交易数据的HASH256值，使用secp256k1算法对交易数据的HASH256值和监管节点的私钥加密成交易签名消息(具体的签名计算过程与比特币交易***相同)，即待验证的消息。参见图8，是图6中所述的交易验证的具体处理流程：从本节点存储的用户文件中读取监管节点的公钥，对待验证的交易签名消息自动进行验证处理(验证计算过程与比特币交易***相同)：
(1)如果自动验证通过，则进入(3)；
(2)如果自动验证不通过，则进入(5)；
(3)人工验证处理:在页面上解析并展现本笔交易的交易结构数据和附件文件，供用户人工审核验证：
(4)如果人工验证通过，则输出1(表示“真”或“通过”)，结束。
(5)输出0(表示“假”或“不通过”)，结束。
参见图9，是图6中所述的共识判定的具体处理流程：接收某笔交易的所有相关用户对应的交易节点***发送的验证结果，判断其值是否全部为1(1表示验证通过，0表示验证不通过)，是则返回共识判定结果为“真”(值为1)，否则返回共识判定结果为“假”(值为0)。
参见图10，是图6中所述的区块生成的具体处理流程：
(1)获取版本号、交易码、交易数据；
(2)赋值合约序号(该字段为预留的智能合约号，目前赋值为00000000)；
(3)对交易数据进行HASH256计算，得到Merkle根；
(4)置请求标识，并用本用户的私钥签名，发送至监管节点***；
(5)监管节点***接收并验证请求标识：
(5-1)如果验证通过，进入(6)；
(5-2)如果验证不通过，结束。
(6)监管节点***组织时间戳、交易顺序号、前向区块指针，并用监管节点私钥签名，发送至对应交易节点***；
(7)对应交易节点***接收并验证：
(7-1)如果验证通过，进入(8)；
(7-2)如果验证不通过，结束。
(8)按图20(区块链示意图)和表1(区块结构)、表2(区块头结构)格式组织区块数据；
(9)计算本区块头的HASH256值，作为本区块数据的文件名；
(10)检查交易模型文件中，该交易码对应的附件标志的值：
(10-1)如果该值为0，则结束；
(10-2)如果值为1，则将该区块文件名也作为附件文件名，如果有多个附件文件则分别依次命名为“区块文件名-1”，“区块文件名-2”，…。结束。
参见图11，是图6中所述的区块存储的具体处理流程：读取用户文件中该用户地址对应的用户类型值(用户文件存储结构见图21至图23，其中，用户类型值为0表示监管用户，为1表示DBA用户，为2表示普通PC交易用户，为3表示ATM用户，为4表示移动用户)：
(1)如果值为0、1、2则为本地存储。在***规定的目录下存储区块数据文件，在***规定的目录下存储附件文件簇。结束。
(2)如果值为3、4则为云端存储。针对云端存储的情况，在***为该用户申请的指定目录下存储区块数据文件，在***为该用户申请的指定目录下存储附件文件簇。结束。
参见图12，是图6中所述的比较验证的具体处理流程：接收某笔交易相关交易节点***发送的区块头数据、区块数据：
(1)重新计算区块数据中交易数据的HASH256值，将该值与区块数据中的 Merkle根比较：
(2)如果不等则认为区块数据被篡改，返回比较验证结果为0(假)，结束。
(3)如果相等，则计算区块数据的区块头数据项的HASH256值，将该值与区块数据文件的文件名、附件数据文件的文件名前缀比较：
(3-1)如果都相等，再将区块数据中区块头的各项数据与其它节点发送的区块头数据项进行逐项比较：
(3-1-1)如果都相等，则返回比较验证结果为1(真)，结束。
(3-1-2)否则返回0(假)，结束。
(3-2)否则返回0(假)，结束。
参见图13，是图6中所述的区块链接的具体处理流程：获取比较验证结果：
(1)如果为真，则将区块数据、可能的附件数据分别存储于监管节点***指定的目录下，将区块数据的文件名写入到云端区块链文件中(云端区块链文件的存储结构见图27)，结束。
(2)否则，废弃区块数据和附件数据，结束。
参见图14，是审计服务流程，当业务数据出现异常时，监管节点实时预警，另外，在区块链展现的基础上，提供多种服务。其中，区块链展现流程见图15；事件是否真实发生证明的处理流程见图16；事件顺序关系证明的处理流程见图 17；区块数据是否被篡改证明的处理流程见图18；业务数据重建线索服务流程见图19。
参见图15，是图14中所述的区块链展现的具体处理流程：监管节点打开云端区块链文件(见图27)，将行数标记H设为1：
(1)读取第H行区块链文件名的值，将值赋给P：
(2)将P与本发明约定的创世区块值比较：
(2-1)如果相等，则结束。
(2-2)如果不等，则进入(3)；
(3)在监管节点指定目录下查找文件名等于P的区块文件，解析该区块数据，重新计算Merkle树根、区块头HASH256值；
(4)将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与 P比较：
(4-1)如果都相等，则进入(5)；
(4-2)如果不全相等或都不等，则进入(7)；
(5)在监管节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
(6)H＝H+1，进入(1)。
(7)按照先DBA用户、后普通交易用户的顺序，分别在其对应目录下查找文件名＝P的区块文件：
(7-1)如果都未找到，则结束。
(7-2)否则，进入(8)；
(8)解析该区块数据，重新计算Merkle树根、区块头HASH256值；
(9)将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与 P比较：
(9-1)如果都相等，则进入(10)；
(9-2)如果不全相等或都不等，则进入(7)；
(10)在该节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
(11)H＝H+1，进入(1)。
参见图16，是图14中所述的事件是否真实发生证明的具体处理流程：接收输入的事件具体特征值，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
(1)将区块中的交易数据与输入的事件具体特征值进行匹配：
(1-1)如果匹配，则用红色框标记该区块(表示找到)，结束；
(1-2)如果不匹配，则读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
(2)判断该区块是否创世区块：
(2-1)如果是，则结束；
(2-2)如果不是，则解析该区块，进入(1)。
参见图17，是图14中所述的事件顺序关系证明的具体处理流程：接收输入的事件通用特征值(比如交易码)，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
(1)将区块中的交易数据与输入的事件通用特征值进行匹配：
(1-1)如果匹配，则用红色框标记该区块(表示找到)，进入(2)；
(1-2)如果不匹配，进入(2)；
(2)读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
(3)判断该区块是否创世区块：
(3-1)如果是，则结束；
(3-2)如果不是，则解析该区块，进入(1)。
参见图18，是图14中所述的区块数据是否被篡改证明的具体处理流程：在已经展现的区块链上，从链尾区块开始检索区块：
(1)分别读取监管节点、DBA节点、相关用户节点的对应区块；
(2)解析对应区块，验证Merkle根、区块头HASH256值；
(3)分别与当前区块链上对应区块的Merkle根、区块头HASH256值比较，判断值是否相等：
(3-1)如果都相等，则进入(4)。
(3-2)否则，记录“某节点某区块被篡改(删除/修改)”，进入(4)。
(4)读取当前区块链上区块的前一区块指针，检索区块链上下一区块；
(5)判断是否是创世区块：
(5-1)如果是，则结束。
(5-2)否则，进入(2)。
参见图19，是图14中所述的业务数据重建线索服务的具体流程：在监管节点可访问的云端指定目录下，打开异常交易数据文件(见图28)，读取所有交易验证未通过的数据记录，按时间递增顺序排列，解析每一条数据记录，形成数据重建线索列表，列表内容包括：时间、交易节点数、用户地址、交易数据、操作指令。
参见图20，区块链示意图：每一个区块数据包括区块头和区块体两个部分，区块头字节数为定长(90字节)，其存储结构见表2；区块体包含区块头和交易数据，不定长，其存储结构见表1。每一个区块通过前向区块指针(Prev-Block Pointer)链接到区块链上，前向区块指针的值即为前向区块的区块头HASH256 值，区块链的链首区块称为创世区块。本发明中，用以下值作为创世区块HASH256 值：8D7253181C78C095522AF0098D1E2D8CE84BEADC2C3B141C
16A72555F83404A0。
监管***指定目录下存在一个区块链链尾文件(该文件永远仅有一条记录，存储结构见图26)，监管节点***每链接一个区块到链上，则更新区块链链尾文件中保存的当前区块链链尾的文件名。
参见图21～23，用户文件存储结构示意图：描述了业务***中各类用户的用户类型、自然属性、地址、公钥、访问入口、HOME、加入联盟链日期、前述属性的HASH256值，每个数据项之间用“；”隔离，每个用户作为一行存储，行尾用“#”标注。其中，用户类型定义为：
0监管节点
1 DBA用户
2普通PC用户
3 ATM用户
4移动设备用户
其中，公钥(32个字符)、地址(20个字符)是由该用户私钥(32个字符)经过特定计算而来，但公钥、地址无法推算出私钥。
参见图24，交易模型文件存储结构示意图：描述了各业务***中各事件(事件处理结果即交易)的交易编码、交易名称、交易结构、是否有附件、交易描述和前述属性的HASH256值。
其中，交易码为00至99；
其中，交易结构是一个集合，是业务***中某事件的抽象，由业务数据库中的特定数据项组成；
其中，附件标志为1表示该事件处理结果有附件，0表示无附件。
文件中每个数据项之间用“；”隔离，每个交易作为一行存储，行尾用“#”标注。
参见图25，交易顺序文件存储结构示意图：描述了每个交易码名下当前的交易数量，主要由交易码、当前顺序号、前述属性的HASH256值组成。当前顺序号为8位10进制数字。文件中每个数据项之间用“；”隔离，每个交易码对应一行存储，行尾用“#”标注。
参见图26，区块链链尾文件存储结构示意图：记录区块链链尾区块的区块头HASH256值(即链尾区块的文件名)，该文件永远仅有一条记录，数据项之间用“；”隔离，文件结束符为“#”。
参见图27，云端区块链文件存储结构示意图：在监管节点可访问的云端，用于依次存储所有区块文件名的数据文件，包含区块文件名、该文件名的 HASH256值，文件中每个数据项之间用“；”隔离，每个区块对应一行存储，行尾用“#”标注。初始时，该文件中存储了创世区块的文件名。
参见图28，异常交易数据文件存储结构示意图：在监管节点可访问的云端，用于存储异常交易(即交易相关用户验证没有一致通过的交易)数据的文件，包含时间、交易数据集合、交易节点数、该交易相关用户的地址、交易操作指令、前述属性的HASH256值。用于异常数据实时预警和业务数据重建线索服务。文件中每个数据项之间用“；”隔离，每次异常交易对应一行存储，行尾用“#”标注。
其中，时间格式为YYYYMMDDhhmmss；
其中，交易操作指令是引起业务数据变化的SQL语句，由桥接程序输出。
参见表1，区块结构：定义了本发明使用的区块结构，包括区块头、区块体。
参见表2，区块头结构：定义了本发明使用的区块头结构。其中，合约序号目前的值为00000000。
本发明的多交易模式联盟链，通过桥接实现与业务***之间进行低耦合的实时的数据关联；通过交易模型定制，将业务***的事件处理转换为区块链技术中的交易；通过授权/许可，将交易用户的范围扩大到PC用户、移动设备用户、 ATM用户；将现有区块链技术中仅有的本地、区块存储扩展到本地或云端、区块存储及附件存储。
功能上，多交易模式联盟链分为监管节点***和交易节点***。
服务上，多交易模式联盟链可以可视化提供如下服务：1)事件存在证明；2) 事件序列证明；3)交易用户、数据管理员(DBA)、监管节点篡改区块数据的发现； 4)被篡改业务数据重建的线索；5)异常交易的实时预警。
性能上，扩展了交易用户范围；扩展了存储类型和存储内容；创新了交易验证机制、共识判定机制、区块生成机制、区块存储机制、比较验证机制、区块链接机制；交易信息仅在相关者与监管节点之间传播；只有交易的相关者生成并存储区块，无关者不会生成与存储；区块生成的效率不再受人为控制，而是由监管节点***和相关交易节点***自身的处理速度确定；监管节点***除审计服务外，无人值守运行；交易节点***除人工验证环节外，无人值守运行。
架构上，采用与比特币交易***相同的JSON RPC点对点通信机制。
安全性上，用户的私钥、公钥、地址的计算采用与比特币交易***相同的算法；***依赖的数据文件(如用户文件、交易模型定制文件、交易顺序文件、区块链链尾文件、云端区块链文件、异常交易数据文件)中，每一条数据记录都有 HASH256校验数据项，用于判断该记录数据项是否被篡改；网络广播(监管节点***与交易节点***之间通信)采用与比特币交易***相同的数字签名与验证算法；在交易验证环节，采用比特币交易***的自动验证处理外，增加了人工验证处理，使得非法交易(外部入侵篡改数据、DBA私自篡改数据等)能够及时被发现并实时预警；采用“一致通过，方为共识”的原则进行交易的共识判定；只有交易相关者生成的区块完全一致，才能将此区块链接到区块链上；每一个区块被链接到区块链上，将同步在云端记录该区块的文件名(即区块头的 HASH256值)，使得一旦区块被链接到区块链上，即使监管节点篡改区块数据也能被发现。
综上所述，本发明既保留了区块链技术的核心内涵---“去中心化、非服务器架构，结构巧妙、算法安全、带宽占用小、防抵赖、防篡改，在一个不可信任的环境下低成本、无须积累地获得可信的结果”，又能低成本、低耦合地适应高价值数据的安全保护及“原始生产者”证明等方面的应用。
实施例1：(知识/实物)产权登记***
一个(知识/实物)产权登记***，由产权登记员按照规定的业务流程操作，操作结果为：对符合登记条件的申请者进行产权登记，并发放产权登记证书。该***由DBA统一维护管理业务数据库。
假定该***使用单位：A市产权中心；
假定产权登记员甲在该***中的用户名：zhangwei，密码为：zw7891；
假定产权登记员乙在该***中的用户名：wangfang，密码为：wf3456；
假定DBA在该***中的用户名：admin，密码为：admin123；
假定业务数据库中存储产权登记信息的数据表为T1，结构为：参见表3
假定数据库端在E:\FileData目录下存储产权登记证书文件，以登记号作为文件名，JPG格式文件。
我们对该业务***做如下抽象：
交易泛化：产权登记事件；
交易结构：{产权登记机构，产权登记人，DBA，申请者名称，产权名称，产权登记号，证书文件}
附件(交易证据)：产权登记证书
交易相关用户：产权登记员、DBA；
存储属性：在PC上操作，本地存储。有附件：产权登记证书(图片文件)。
步骤S01：初始化(仅执行一次)。
步骤S01-01：在该***网络中指定PC上部署监管节点***，在产权登记员甲、乙和DBA操作的PC上分别部署交易节点***，并通过各交易节点的版本管理程序完成联盟链内各节点的版本统一；
步骤S01-02：运行监管节点***的授权/许可程序，分别为监管节点、产权登记员甲、产权登记员乙和DBA建立联盟链用户，计算各自的私钥、公钥、地址，设置其入盟日期，配置其访问入口和HOME目录。如下(地址、公钥、SHA256值省略，以下相同)：
0；监管者；地址；公钥；192.168.99.199/8080；E:\TranSys；20180101；SHA256#
1；DBA；地址；公钥；192.168.99.198/8080；E:\TranSys；20180101；SH2A56#
2；zhangwei；地址；公钥；192.168.99.190/8080；E:\TranSys；20180101；SHA256#
2；wangfang；地址；公钥；192.168.99.191/8080；E:\TranSys；20180101；SHA256#
步骤S01-03：执行监管节点的交易模型定制程序，对该业务***的交易模型进行配置，如下：
00；产权登记；{！A市产权中心,OperName,！admin,RequireName,ResultName,RusultNum,ResultFileName}；1；一次产权登记事件结果的记载；SHA256#
其中，！表示紧跟着的是常数。
步骤S01-04：在该业务***的数据库端部署、配置桥接程序，对T1表进行监听，使其能实时、自动捕捉对T1表的所有Insert、Update、Delete操作指令及其操作结果对应的记录数据，按照该交易码的交易模型结构，抽取对应数据，输出给监管节点***。由于该桥接程序实时自动执行，因此，所有对T1表的所有 Insert、Update、Delete操作指令及操作结果(包括正常的事件处理或DBA利用技术优势直接篡改、伪造数据或黑客入侵数据库篡改、伪造数据)都将自动输出给监管节点***。比如：
交易数据：{A市产权中心,zhangwei,admin,刘大维,房屋产权登记,A1800678,E:\FileData\A1800678.jpg}
交易指令：
INSERTINTOT1(ID,RequireName,RequireThing,ResultName,ResultNum,OperName,OperDate,ResultFileName)VALUES(35,“刘大维”,“产权登记”,“房屋产权登记证”,“A1800678”,“zhangwei”,20180101, “E:\FileData\A1800678.jpg”)
步骤S02：交易过程(日常运行)。
步骤S02-01：监管节点***对接收的交易数据进行数字签名，如下(r,s是依据私钥和随机数计算出的签名)：
{A市产权中心,zhangwei,admin,刘大维,房屋产权登记,A1800678, E:\FileData\A1800678.jpg}，r,s.
步骤S02-02：监管节点***将上述签名后的数据发送给该笔交易相关的用户(zhangwei和admin)所在的交易节点***。
步骤S02-03：该笔交易相关用户(zhangwei和admin)的交易节点***接收待验证的数据，进行交易验证。
步骤S02-03-01：自动解密验证。进行解密(依据对应的公钥计算出v)，如果 v＝r，则自动验证通过，进入步骤S02-03-02；否则，置验证结果为“假”，进入步骤S02-04。
步骤S02-03-02：人工验证。取出交易数据，解析为：
“zhangwei”同志对“刘大伟”申请的“房屋产权登记”进行了操作，证书号为“A1800678”，对应证书文件(点击可展示证书图片)。
请对该事件的真实性进行确认：[]真[]假
接收人工验证结果，如果选择“真”，则置验证结果为“真”；如果选择“假”，则置验证结果为“假”。
步骤S02-04：交易节点***对自己的交易验证结果进行签名，发送至监管节点***；
步骤S02-05：监管节点***分别接收各自交易节点***的签名消息，解密验证。
步骤S02-05-01：如果验证通过，则进入步骤S02-06。
步骤S02-05-02：如果验证不通过，则进入步骤S02-01。
步骤S02-06：监管节点***进行共识判定。
步骤S02-06-01：如果所有交易节点***发送的验证结果都为“真”，则共识判定为“真”，进入步骤S02-07。
步骤S02-06-02：如果所有交易节点***发送的验证结果不全为“真”，则共识判定为“假”，进入步骤S02-01。
步骤S02-07：监管节点***对共识判定结果签名，并发送给相关交易节点***。
步骤S02-08：相关交易节点***接收该签名消息，解密验证。
步骤S02-08-01：如果验证通过，进入步骤S02-09。
步骤S02-08-02：如果验证不通过，进入步骤S02-01。
步骤S02-09：交易节点***区块生成。
步骤S02-09-01：交易节点***向监管节点***请求时间戳、交易顺序号、链尾指针，并将请求信息签名，发送至监管节点***；
步骤S02-09-02：监管节点***对请求签名进行解密验证：如果验证不通过，置返回结果为“空”；否则，计算、检索出对应值并置于返回结果。
步骤S02-09-03：对返回结果值进行签名后发送给对应的交易节点***。
步骤S02-10：相关交易节点***接收该签名消息，解密验证。
步骤S02-10-01：如果验证通过，进入步骤S02-11。
步骤S02-10-02：如果验证不通过，进入步骤S02-01。
步骤S02-11：按区块结构进行数据项赋值。计算区块头的HASH256值。
步骤S02-12：交易节点***进行区块存储：
步骤S02-12-01：打开用户文件，获取本用户的存储位置；打开交易模型文件，读取本交易的附件属性值；
步骤S02-12-02：在存储位置的指定子目录下，以区块头的HASH256值为命名存储区块数据；在存储位置的另一指定子目录下，以区块头的HASH256值为命名存储附件文件。
步骤S02-12-03：DBA用户对区块数据、附件文件进行签名，并发送至监管节点***；zhangwei用户对区块头数据进行签名，并发送至监管节点***。
步骤S02-13：监管节点***分别接收各自交易节点***发送的签名消息，解密验证。
步骤S02-13-01：如果解密验证成功，进入步骤S02-14。
步骤S02-13-02：如果解密验证失败，进入步骤S02-01。
步骤S02-14：监管节点***进行比较验证：
步骤S02-14-01：针对区块数据，计算Merkle根，与区块中的Merkle根比较：
步骤S02-14-01-01：如果相等，进入步骤S02-14-02。
步骤S02-14-01-02：如果不等，进入步骤S02-01。
步骤S02-14-02：针对区块数据，计算区块头的HASH256值，与区块文件名和附件文件名比较：
步骤S02-14-02-01：如果相等，进入步骤S02-14-03。
步骤S02-14-02-02：如果不等，进入步骤S02-01。
步骤S02-14-03：将区块数据中的头部分数据项与其它用户发送的区块头数据项进行逐一比较：
步骤S02-14-03-01：如果相等，进入步骤S02-15。
步骤S02-14-03-02：如果不等，进入步骤S02-01。
步骤S02-15：返回比较验证结果为“真”。
步骤S02-16：监管节点***进行区块链接：
步骤S02-16-01：打开用户文件，获取存储位置(HOME目录)，在规定的子目录下以区块头HASH256值作为文件名，存储区块数据；在规定的另一子目录下以区块头HASH256值作为文件名，存储附件数据；
步骤S02-16-02：打开云端区块链文件，将区块文件名追加到该文件中；
步骤S02-16-03：打开链尾文件，用区块文件名更新该文件的唯一一条记录。
步骤S02-17：进入步骤S02-01。
步骤S03：审计服务(除异常数据实时预警为实时自动执行外，其它服务根据需要随机执行)。
步骤S03-01：判断是否有异常数据存储：
步骤S03-01-01：有，则对异常数据进行解析并实时预警。预警结束进入步骤S03。
步骤S03-01-02：无，则进入步骤S03。
步骤S03-02：展现区块链：监管节点打开云端区块链文件，将行数标记H设为1：
步骤S03-02-01：读取第H行区块链文件名的值，将值赋给P：
步骤S03-02-02：将P与本发明约定的创世区块值比较：
步骤S03-02-02-01：如果相等，则进入步骤S03。
步骤S03-02-02-02：如果不等，则进入S03-02-03；
步骤S03-02-03：在监管节点指定目录下查找文件名等于P的区块文件，解析该区块数据，重新计算Merkle树根、区块头HASH256值；
步骤S03-02-04：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
步骤S03-02-04-01：如果都相等，则进入步骤S03-02-05；
步骤S03-02-04-02：如果不全相等或都不等，则进入步骤S03-02-07；
步骤S03-02-05：在监管节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
步骤S03-02-06：H＝H+1，进入步骤S03-02-01。
步骤S03-02-07：按照先DBA用户、后普通交易用户的顺序，分别在其对应目录下查找文件名＝P的区块文件：
步骤S03-02-07-01：如果都未找到，则进入步骤S03。
步骤S03-02-07-02：否则，进入步骤S03-02-08；
步骤S03-02-08：解析该区块数据，重新计算Merkle树根、区块头HASH256值；
步骤S03-02-09：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
步骤S03-02-09-01：如果都相等，则进入步骤S03-02-10；
步骤S03-02-09-02：如果不全相等或都不等，则进入步骤S03-02-07；
步骤S03-02-10：在该节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
步骤S03-02-11：H＝H+1，进入步骤S03-02-01。
步骤S03-03：证明事件发生。接收输入的事件具体特征值，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
步骤S03-03-01：将区块中的交易数据与输入的事件具体特征值进行匹配：
步骤S03-03-01-01：如果匹配，则用红色框标记该区块(表示找到)，进入步骤S03-03；
步骤S03-03-01-02：如果不匹配，则读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
步骤S03-03-02：判断该区块是否创世区块：
步骤S03-03-02-01：如果是，则进入步骤S03-03；
步骤S03-03-02-02：如果不是，则解析该区块，进入步骤S03-03-01。
步骤S03-04：证明事件序列关系。接收输入的事件通用特征值(比如交易码)，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
步骤S03-04-01：将区块中的交易数据与输入的事件通用特征值进行匹配：
步骤S03-04-01-01：如果匹配，则用红色框标记该区块(表示找到)，进入步骤S03-04-02；
步骤S03-04-01-02：如果不匹配，进入步骤S03-04-02；
步骤S03-04-02：读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
步骤S03-04-03：判断该区块是否创世区块：
步骤S03-04-03-01：如果是，则进入步骤S03-04；
步骤S03-04-03-02：如果不是，则解析该区块，进入步骤S03-04-01。
步骤S03-05：区块数据是否被篡改证明。在已经展现的区块链上，从链尾区块开始检索区块：
步骤S03-05-01：分别读取监管节点、DBA节点、相关用户节点的对应区块；
步骤S03-05-02：解析对应区块，验证Merkle根、区块头HASH256值；
步骤S03-05-03：分别与当前区块链上对应区块的Merkle根、区块头HASH256 值比较，判断值是否相等：
步骤S03-05-03-01：如果都相等，则进入步骤S03-05-04。
步骤S03-05-03-02：否则，记录“某节点某区块被篡改(删除/修改)”，进入步骤S03-05-04。
步骤S03-05-04：读取当前区块链上区块的前一区块指针，检索区块链上下一区块；
步骤S03-05-05：判断是否是创世区块：
步骤S03-05-05-01：如果是，则进入步骤S03-05。
步骤S03-05-05-02：否则，进入步骤S03-05-02。
步骤S03-06：业务数据重建线索。
步骤S03-06-01：在监管节点可访问的云端指定目录下，打开异常交易数据文件，读取所有交易验证未通过的数据记录。
步骤S03-06-02：按时间递增顺序排列，解析每一条数据记录，形成数据重建线索列表，列表内容包括：时间、用户地址、交易节点数、交易数据、操作指令。
实施例2：一个银行卡储蓄***
一个银行卡储蓄***，某市X银行发行了N张银行卡，允许卡主在M个ATM机上存取款，后端由DBA统一维护管理业务数据库。
DBA在该***中的用户名：admin，密码为：manage789；
业务数据库中客户资料表T1，结构为：参见表4
业务数据库中银行卡存款信息表为T2，结构为：参见表5
业务数据库中银行卡取款信息表为T3，结构为：参见表6
我们对该业务***做如下抽象：
交易泛化：银行卡主在ATM上存款；银行卡主在ATM上取款。
相关用户：银行卡卡主(ATM用户)、DBA。
存储属性：ATM节点无法存储区块，需通过云端构建虚拟节点。无附件数据。
交易结构：{交易码，卡主，DBA，存款金额，存款ATM号}
{交易码，卡主，DBA，取款金额，取款ATM号}
步骤S01：初始化(仅执行一次)。
步骤S01-01：在该***网络中指定PC上部署监管节点***，在DBA操作的PC 上部署交易节点***，对T1表中的所有状态值为1的客户建立云端空间，并分别部署交易节点***，通过各交易节点的版本管理程序完成联盟链内各节点的版本统一；
步骤S01-02：运行监管节点***的授权/许可程序，分别为监管节点、各卡主和DBA建立联盟链用户，计算各自的私钥、公钥、地址，设置其入盟日期，配置其访问入口和HOME目录。如下：
0；监管者；地址；公钥；192.168.99.199/8080；E:\TranSys；20180101；SHA256#
1；DBA；地址；公钥；192.168.99.100/8080；E:\TranSys；20180101；SHA256#
3；zhangsan；地址；公钥；135.168.99.190/8080；E:\TranSys；20180101；SHA256#
3；lisi；地址；公钥；135.168.99.191/8080；E:\TranSys；20180101；SHA256#
……
步骤S01-03：执行监管节点的交易模型定制程序，对该业务***的交易模型进行配置，如下：
01；ATM存款；{CustmerName,！admin,InputValue,InputATMNum}；0；一次银行卡在ATM上存款事件结果的记载；H256#
02；ATM取款；{CustmerName,！admin,OutputValue,OutputATMNum}；0；一次银行卡在ATM上取款事件结果的记载；H256#
其中，！表示紧跟着的是常数。
步骤S01-04：在该业务***的数据库端部署、配置桥接程序，对T2表、T3表进行监听，使其能实时、自动捕捉对T2表、T3表的所有Insert、Update、Delete 操作指令及其操作结果对应的记录数据，按照该交易码的交易模型结构，抽取对应数据，输出给监管节点***。由于该桥接程序实时自动执行，因此，所有对T2表、T3表的所有Insert、Update、Delete操作指令及操作结果(包括正常的事件处理或DBA利用技术优势直接篡改、伪造数据或黑客入侵数据库篡改、伪造数据)都将自动输出给监管节点***。比如：
交易数据：{01,zhangsan,admin,808.90,point098}
{02,lisi,admin,100.50,point048}
交易指令：省略。
步骤S02：交易过程(日常运行)。
步骤S02-01：监管节点***对接收的交易数据进行数字签名，如下：
{01,zhangsan,admin,808.90,point098},r,s.
步骤S02-02：监管节点***将上述签名后的数据发送给该笔交易相关的用户(zhangsan对应在云端、admin在指定PC上)所在的交易节点***。
步骤S02-03：该笔交易相关用户(zhangsan、admin)的交易节点***接收待验证的数据，进行交易验证。
步骤S02-03-01：自动解密验证。进行解密(计算v)，如果v＝r，则自动验证通过，进入步骤S02-03-02；否则，置验证结果为“假”，进入步骤S02-04。
步骤S02-03-02：人工验证。zhangsan、admin用户分别执行。其中，向zhangsan 卡主的手机发送短信链接，zhangsan进入云端交易节点***进行人工验证 (admin用户在PC上)。取出交易数据：
{01,zhangsan,admin,808.90,point098}
解析为：
“zhangsan”同志在“point098”ATM机上“存款”808.90元。
请对该事件的真实性进行确认：[]真[]假
接收人工验证结果，如果选择“真”，则置验证结果为“真”；如果选择“假”，则置验证结果为“假”。
步骤S02-04：交易节点***对自己的交易验证结果进行签名，发送至监管节点***；
步骤S02-05：监管节点***分别接收各自交易节点***的签名消息，解密验证。
步骤S02-05-01：如果验证通过，则进入步骤S02-06。
步骤S02-05-02：如果验证不通过，则进入步骤S02-01。
步骤S02-06：监管节点***进行共识判定。
步骤S02-06-01：如果所有交易节点***发送的验证结果都为“真”，则共识判定为“真”，进入步骤S02-07。
步骤S02-06-02：如果所有交易节点***发送的验证结果不全为“真”，则共识判定为“假”，进入步骤S02-01。
步骤S02-07：监管节点***对共识判定结果签名，并发送给相关交易节点***。
步骤S02-08：相关交易节点***接收该签名消息，解密验证。
步骤S02-08-01：如果验证通过，进入步骤S02-09。
步骤S02-08-02：如果验证不通过，进入步骤S02-01。
步骤S02-09：交易节点***区块生成。
步骤S02-09-01：交易节点***向监管节点***请求时间戳、交易顺序号、链尾指针，并将请求信息签名，发送至监管节点***；
步骤S02-09-02：监管节点***对请求签名进行解密验证：如果验证不通过，置返回结果为“空”；否则，计算、检索出对应值并置于返回结果。
步骤S02-09-03：对返回结果值进行签名后发送给对应的交易节点***。
步骤S02-10：相关交易节点***接收该签名消息，解密验证。
步骤S02-10-01：如果验证通过，进入步骤S02-11。
步骤S02-10-02：如果验证不通过，进入步骤S02-01。
步骤S02-11：按区块结构进行数据项赋值。计算区块头的HASH256值。
步骤S02-12：交易节点***进行区块存储：
步骤S02-12-01：打开用户文件，获取本用户的存储位置；打开交易模型文件，读取本交易的附件属性值；
步骤S02-12-02：在存储位置的指定子目录下，以区块头的HASH256值为命名存储区块数据。
步骤S02-12-03：DBA用户对区块数据、附件文件进行签名，并发送至监管节点***；zhangwei用户对区块头数据进行签名，并发送至监管节点***。
步骤S02-13：监管节点***分别接收各自交易节点***发送的签名消息，解密验证。
步骤S02-13-01：如果解密验证成功，进入步骤S02-14。
步骤S02-13-02：如果解密验证失败，进入步骤S02-01。
步骤S02-14：监管节点***进行比较验证：
步骤S02-14-01：针对区块数据，计算Merkle根，与区块中的Merkle根比较：
步骤S02-14-01-01：如果相等，进入步骤S02-14-02。
步骤S02-14-01-02：如果不等，进入步骤S02-01。
步骤S02-14-02：针对区块数据，计算区块头的HASH256值，与区块文件名和附件文件名比较：
步骤S02-14-02-01：如果相等，进入步骤S02-14-03。
步骤S02-14-02-02：如果不等，进入步骤S02-01。
步骤S02-14-03：将区块数据中的头部分数据项与其它用户发送的区块头数据项进行逐一比较：
步骤S02-14-03-01：如果相等，进入步骤S02-15。
步骤S02-14-03-02：如果不等，进入步骤S02-01。
步骤S02-15：返回比较验证结果为“真”。
步骤S02-16：监管节点***进行区块链接：
步骤S02-16-01：打开用户文件，获取存储位置(HOME目录)，在规定的子目录下以区块头HASH256值作为文件名，存储区块数据；
步骤S02-16-02：打开云端区块链文件，将区块文件名追加到该文件中；
步骤S02-16-03：打开链尾文件，用区块文件名更新该文件的唯一一条记录。
步骤S02-17：进入步骤S02-01。
步骤S03：审计服务(除异常数据实时预警为实时自动执行外，其它服务根据需要随机执行)。
步骤S03-01：判断是否有异常数据存储：
步骤S03-01-01：有，则对异常数据进行解析并实时预警。预警结束进入步骤S03。
步骤S03-01-02：无，则进入步骤S03。
步骤S03-02：展现区块链：监管节点打开云端区块链文件，将行数标记H设为1：
步骤S03-02-01：读取第H行区块链文件名的值，将值赋给P：
步骤S03-02-02：将P与本发明约定的创世区块值比较：
步骤S03-02-02-01：如果相等，则进入步骤S03。
步骤S03-02-02-02：如果不等，则进入S03-02-03；
步骤S03-02-03：在监管节点指定目录下查找文件名等于P的区块文件，解析该区块数据，重新计算Merkle树根、区块头HASH256值；
步骤S03-02-04：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
步骤S03-02-04-01：如果都相等，则进入步骤S03-02-05；
步骤S03-02-04-02：如果不全相等或都不等，则进入步骤S03-02-07；
步骤S03-02-05：在监管节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
步骤S03-02-06：H＝H+1，进入步骤S03-02-01。
步骤S03-02-07：按照先DBA用户、后普通交易用户的顺序，分别在其对应目录下查找文件名＝P的区块文件：
步骤S03-02-07-01：如果都未找到，则进入步骤S03。
步骤S03-02-07-02：否则，进入步骤S03-02-08；
步骤S03-02-08：解析该区块数据，重新计算Merkle树根、区块头HASH256值；
步骤S03-02-09：将计算出的Merkle树根与区块的Merkle树根比较，将区块头HASH256值与P比较：
步骤S03-02-09-01：如果都相等，则进入步骤S03-02-10；
步骤S03-02-09-02：如果不全相等或都不等，则进入步骤S03-02-07；
步骤S03-02-10：在该节点指定目录下查找文件名前缀＝P的所有附件文件，显示该区块和所有附件文件；
步骤S03-02-11：H＝H+1，进入步骤S03-02-01。
步骤S03-03：证明事件发生。接收输入的事件具体特征值，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
步骤S03-03-01：将区块中的交易数据与输入的事件具体特征值进行匹配：
步骤S03-03-01-01：如果匹配，则用红色框标记该区块(表示找到)，进入步骤S03-03；
步骤S03-03-01-02：如果不匹配，则读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
步骤S03-03-02：判断该区块是否创世区块：
步骤S03-03-02-01：如果是，则进入步骤S03-03；
步骤S03-03-02-02：如果不是，则解析该区块，进入步骤S03-03-01。
步骤S03-04：证明事件序列关系。接收输入的事件通用特征值(比如交易码)，在已经展现的区块链上，从链尾区块开始检索并解析该区块。
步骤S03-04-01：将区块中的交易数据与输入的事件通用特征值进行匹配：
步骤S03-04-01-01：如果匹配，则用红色框标记该区块(表示找到)，进入步骤S03-04-02；
步骤S03-04-01-02：如果不匹配，进入步骤S03-04-02；
步骤S03-04-02：读取当前区块的前一区块指针，依据该前一区块指针检索到对应区块。
步骤S03-04-03：判断该区块是否创世区块：
步骤S03-04-03-01：如果是，则进入步骤S03-04；
步骤S03-04-03-02：如果不是，则解析该区块，进入步骤S03-04-01。
步骤S03-05：区块数据是否被篡改证明。在已经展现的区块链上，从链尾区块开始检索区块：
步骤S03-05-01：分别读取监管节点、DBA节点、相关用户节点的对应区块；
步骤S03-05-02：解析对应区块，验证Merkle根、区块头HASH256值；
步骤S03-05-03：分别与当前区块链上对应区块的Merkle根、区块头HASH256 值比较，判断值是否相等：
步骤S03-05-03-01：如果都相等，则进入步骤S03-05-04。
步骤S03-05-03-02：否则，记录“某节点某区块被篡改(删除/修改)”，进入步骤S03-05-04。
步骤S03-05-04：读取当前区块链上区块的前一区块指针，检索区块链上下一区块；
步骤S03-05-05：判断是否是创世区块：
步骤S03-05-05-01：如果是，则进入步骤S03-05。
步骤S03-05-05-02：否则，进入步骤S03-05-02。
步骤S03-06：业务数据重建线索。
步骤S03-06-01：在监管节点可访问的云端指定目录下，打开异常交易数据文件，读取所有交易验证未通过的数据记录。
步骤S03-06-02：按时间递增顺序排列，解析每一条数据记录，形成数据重建线索列表，列表内容包括：时间、用户地址、交易节点数、交易数据、操作指令。
以上显示和描述了本发明的基本原理、主要特征和本发明 的优点。本行业的技术人员应该了解，本发明 不受上述实施例的限制，上述实施例和说明书中描述的只是本发明的原理，在不脱离本发明 精神和范围的前提下本发明 还会有各种变化和改进，这些变化和改进都落入要求保护的本发明 的范围内。本发明 要求的保护范围由所附的权利要求书及其等同物界定。

Claims (2)

1.一种生成多交易模式联盟链的方法，其特征在于：包括买卖交易泛化为业务***的事件处理，使得业务***的每次事件处理可以对应一次交易；
多交易模式联盟链与指定业务***之间通过桥接单元进行联结，桥接单元安装在业务***数据库端，实时触发各用户对数据库的新增、删除、修改事件，参照该交易在“交易模型文件”中事先定制的交易结构，摘取当前事件记录中需要的数据项值，构建为交易结构，获取本事件的附件文件，传递给监管节点***；
交易的用户类型包括PC用户、移动设备用户、ATM用户；
多交易模式联盟链通过授权/许可单元，对业务***的各类用户计算地址、公钥、私钥，记录存储特征，所述各类用户包括普通PC操作用户、数据管理员DBA、ATM用户、移动设备用户；申请本地或云端空间，授权/许可程序处理结果追加到用户文件中，用户的私钥、公钥、地址的计算规则同比特币交易***，其中，计算规则的原始输入分别为：
(1)PC用户、DBA：“用户名”+“密码”；
(2)移动设备用户：“设备码”；
(3)ATM用户：“开户行”+“账号/***”+“密码”；
交易生成的区块数据在本地存储或在该用户地址对应的云端存储，存储与事件对应的区块数据，或关联存储与事件相关的、多种格式的附件数据；
读取用户文件中该用户地址对应记录的用户类型值：
(1)如果值为0、1、2则为本地存储，在***规定的目录下存储区块数据文件，在***规定的目录下存储附件文件簇；
(2)如果值为3、4则为云端存储，针对云端存储的情况，在***为该用户申请的云端指定目录下存储区块数据文件，在***为该用户申请的云端指定目录下存储附件文件簇；
所述多交易模式联盟链还包括以下交易处理步骤：
步骤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用户对区块数据、附件文件进行签名，并发送至监管节点***；普通用户对区块头数据进行签名，并发送至监管节点***；
步骤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。
2.如权利要求1所述的生成多交易模式联盟链的方法，其特征在于：还包括审计服务，所述的审计服务包括以下步骤：
步骤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：按时间递增顺序排列，解析每一条数据记录，形成数据重建线索列表，列表内容包括：时间、用户地址、交易节点数、交易数据、操作指令。
CN201810173747.5A 2018-03-02 2018-03-02 一种生成多交易模式联盟链的方法 Active CN108389130B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810173747.5A CN108389130B (zh) 2018-03-02 2018-03-02 一种生成多交易模式联盟链的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810173747.5A CN108389130B (zh) 2018-03-02 2018-03-02 一种生成多交易模式联盟链的方法

Publications (2)

Publication Number Publication Date
CN108389130A CN108389130A (zh) 2018-08-10
CN108389130B true CN108389130B (zh) 2020-02-14

Family

ID=63070160

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810173747.5A Active CN108389130B (zh) 2018-03-02 2018-03-02 一种生成多交易模式联盟链的方法

Country Status (1)

Country Link
CN (1) CN108389130B (zh)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109410049A (zh) * 2018-09-18 2019-03-01 深圳周百通科技有限公司 区块链记账方法、装置、计算机设备和存储介质
CN109410084A (zh) * 2018-10-17 2019-03-01 郑称德 基于电子商务的农贸***的移动支付控制方法及农贸***
CN109493221B (zh) * 2018-10-26 2021-01-12 全链通有限公司 区块链中交易记录保密方法、设备、网络及存储介质
CN109409855B (zh) * 2018-10-29 2022-03-22 合肥学院 一种元区块及其生成、识别、过滤方法
CN109615474B (zh) * 2018-12-11 2022-04-22 南京大学 基于区块链的中小企业竞争情报共享平台构建方法
CN109815657B (zh) * 2018-12-14 2022-10-28 深圳壹账通智能科技有限公司 基于联盟链的身份认证方法、装置、计算机可读存储介质及终端设备
CN109767190A (zh) * 2018-12-29 2019-05-17 中国工商银行股份有限公司 基于区块链的跨机构工作流处理方法、平台及***
CN109919764A (zh) * 2019-01-31 2019-06-21 中国互联网络信息中心 基于区块链的域名交易监管方法及装置
CN109903058B (zh) * 2019-02-21 2021-05-18 中国联合网络通信集团有限公司 一种基于区块链的养卡识别方法和装置
CN110245942B (zh) * 2019-05-20 2021-05-04 创新先进技术有限公司 结合用户类型和判断条件的收据存储方法和节点
CN110245944B (zh) * 2019-05-20 2021-04-27 创新先进技术有限公司 基于用户类型的收据存储方法和节点
CN110197085B (zh) * 2019-06-14 2022-12-09 福州大学 一种基于fabric联盟链的文档防篡改方法
CN112488701A (zh) * 2019-08-20 2021-03-12 厦门本能管家科技有限公司 一种基于区块链的中介交易方法及***
CN111161059B (zh) * 2019-11-29 2023-10-31 合肥学院 一种将事务处理泛化成交易的方法
CN111259001B (zh) * 2019-12-11 2023-04-07 合肥学院 基于区块链的数据新鲜度度量方法
CN111309739B (zh) * 2019-12-11 2023-03-31 合肥学院 基于区块链的数据游走轨迹跟踪方法
CN111259453B (zh) * 2019-12-11 2023-04-07 合肥学院 基于区块链的数据冲突发现方法
CN111080299B (zh) * 2019-12-27 2020-12-15 广州骏伯网络科技有限公司 一种交易信息的防抵赖方法及客户端、服务器
CN111667254B (zh) * 2020-05-31 2023-07-25 四川亨通网智科技有限公司 一种***支付网关
CN112152797B (zh) * 2020-08-26 2021-09-17 西安电子科技大学 区块链远程数据审计监管方法、***、计算机设备及终端
CN114760325A (zh) * 2020-12-25 2022-07-15 中移动信息技术有限公司 业务数据处理方法、设备、存储介质及共享平台
CN113657972A (zh) * 2021-08-31 2021-11-16 卓尔智联(武汉)研究院有限公司 基于区块链的物品交易方法、计算机装置及存储介质
CN113949709B (zh) * 2021-10-13 2024-05-10 甘肃同兴智能科技发展有限责任公司 一种提高区块链网络安全性的共识方法及***
CN113962810B (zh) * 2021-10-26 2022-05-10 北京市科学技术情报研究所 一种基于区块链的数据资产配置交易方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017204943A1 (en) * 2016-05-24 2017-11-30 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using audit guarantees
CN107507001A (zh) * 2017-08-11 2017-12-22 杭州秘猿科技有限公司 一种基于许可链的数据订正方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017204943A1 (en) * 2016-05-24 2017-11-30 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using audit guarantees
CN107507001A (zh) * 2017-08-11 2017-12-22 杭州秘猿科技有限公司 一种基于许可链的数据订正方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"区块链技术：应用及问题";翟社平等;《西安邮电大学学报》;20180110;全文 *
"支持协同机制的数据交换规则设计";张家锐，章义刚;《合肥学院学报》;20131115;全文 *

Also Published As

Publication number Publication date
CN108389130A (zh) 2018-08-10

Similar Documents

Publication Publication Date Title
CN108389130B (zh) 一种生成多交易模式联盟链的方法
US20220366019A1 (en) Method and system for verifying ownership of a digital asset using a distributed hash table and a peer-to-peer distributed ledger
JP6877448B2 (ja) 分散ハッシュテーブル及びブロックチェーンを用いてコンピュータソフトウェアを保証する方法及びシステム
CN108550037B (zh) 基于区块链的文件处理方法和装置
CN112235323B (zh) 基于区块链的取证方法及装置、电子设备和可读存储介质
CN111259439B (zh) 一种基于区块链的无形资产管理服务平台及其实现方法
JP4201556B2 (ja) センタ・システムにおける情報処理方法及びアクセス権限管理方法
US20090055935A1 (en) Data delivery system, issuance apparatus, terminal apparatus, and intermediate node
CN112804252B (zh) 一种用户管理***
CN118118178A (zh) 基于区块链的数字资源处理方法、装置和计算机设备
CN117456072A (zh) 基于区块链的数据处理方法、装置、设备及可读存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant