CN110717825B

CN110717825B - Distributed data transaction accounting system based on block chain

Info

Publication number: CN110717825B
Application number: CN201810682292.XA
Authority: CN
Inventors: 吕智慧; 吴杰; 杨健; 柴铭
Original assignee: Fudan University
Current assignee: Fudan University
Priority date: 2018-06-27
Filing date: 2018-06-27
Publication date: 2023-04-07
Anticipated expiration: 2038-06-27
Also published as: CN110717825A

Abstract

The invention belongs to the field of cloud computing resource management, relates to distributed data storage, point-to-point transmission and consensus mechanism technologies, and particularly relates to a distributed data transaction accounting system based on a block chain. The invention includes: using the front-end processor container as a communication tool to send and receive transactions between the physical machines; building a union chain by using the open-source Hyperhedger Fabric; writing the transaction information into the block chain by compiling a Monitor by using java; using a couchdb database to perform rich queries; and displaying the block generation information visually by using the open source tool fabric-explorer. The invention solves the problems of over-centralization and lack of trust of the traditional data storage, possible modification of data in the transmission process and the like, and realizes the consistence, the tamper resistance, the automation and the high-efficiency bill record, the preservation of an account book and the intelligent clearing.

Description

Distributed data transaction accounting system based on block chain

Technical Field

The invention belongs to the field of cloud computing resource management, relates to distributed data storage, point-to-point transmission and consensus mechanism technologies, and particularly relates to a distributed data transaction accounting system based on a block chain.

Background

It is shown that after being considered as power and internet, the blockchain technology has another subversive core technology. As an underlying technology for constructing a value internet, a blockchain change is a value transfer mode, and the occurrence of the blockchain solves a very important problem of how to acquire unknown trust.

The block chain technology is based on a decentralized peer-to-peer network, and open source software is used for combining a cryptography principle, time sequence data and a consensus mechanism, so that consistency and continuity of all nodes in a distributed database are guaranteed, information can be verified and traced immediately, but the information is difficult to tamper and cannot be shielded, and a private, efficient and safe shared value system is created.

The traditional database uses a CS (client-server) network structure, in which a user can modify data, and the control right of the database is also at a central organization, such as a company or an organization, which provides access right to the database after verifying the identity of the client; the central organization (company or organization, etc.) is responsible for management of databases, etc., and is a clear subject, if hackers are interested in the data, once the organization is attacked and the security is threatened, the data can be changed or even deleted; in addition, the risk of a manager with authority within the organization also exists.

Traditional databases have obvious centralized service traces; the block chain databases are different and are composed of a plurality of distributed decentralized nodes, all the nodes participate in data management, any data is added in the account book database and confirmed by the nodes, the account books are public and transparent to all the nodes, transaction data is added in the account book like a bit currency, consensus must be obtained, the nodes can enter the block after confirmation, and the consensus algorithm ensures the safety of the network and can not be tampered; the consensus mechanism is that besides competitive POW, the mechanism is also authorization certification POS and entrusting authorization certification DPOS.

In a traditional database, data can be created, read, modified and deleted; the block chain design is more simplified, the data modification and deletion operations are removed, a user can only add data on the blocks, and the confirmation data of all the entering blocks cannot be changed, namely, the block chain design only has the following operations of reading and writing: data can be inquired and retrieved from the block chain, more data can be added to the block chain in a writing mode, and modification and deletion operations on the data cannot be carried out.

The blockchain allows for the validation and writing of transactions, a transaction being an operation that changes the state of data on the blockchain, old records remaining unchanged and new records changing the state of data in the past. If 100 btc's are purchased with the legal instrument, these are permanently recorded in the blockchain, and on a certain day, a car is purchased with 10 bitcoins, the data for this transaction is recorded in the blockchain, and the user's bitcoin wallet balance remains 90 btc; however, the blockchain database maintains all records, and the user's previous 100 btc history is also permanently maintained, whereas the conventional database is typically upgraded to the final data state.

The traditional database is generally private, but the blockchain data is publicly verifiable, so that completeness and transparency are guaranteed, a user can confirm that the blockchain data retrieved and consulted by the user is complete and is not tampered, and the traditional database is difficult to guarantee.

Hyperridge (Chinese name is super account book) is an open source project for promoting block chain digital technology and transaction verification and verification initiated by Linux foundation in 2015, and aims to enable members to cooperate and jointly establish an open platform to meet the requirements of various users from multiple different industries and greatly simplify the business process; the founder members of Hyperledger are IBM, intel, cisco, etc.

Hyperridge is an innovation of a traditional block chain model, and provides a model which allows the creation of authorized and unauthorized block chains to some extent, and in addition, hyperridge provides a safe and robust model aiming at identity recognition, auditability and privacy, so that the calculation period is shortened, the scale efficiency is improved, and the application requirements of various industries are met.

Hyperledger Fabric is the core item of Hyperledger, and even in some cases when reference is made to Hyperledger, it is generally considered to be Fabric, which is actually misunderstanding, but also reflects the position occupied by Hyperledger Fabric in Hyperledger from the side. The HyperLegend Fabric is essentially a distributed shared account book, the HyperLegend Fabric aims to become the basis of developing application and solution, and adopts a modular architecture in design, and the modular architecture has the advantages that components can be flexibly configured according to needs and can be inserted for use; hyperledger Fabric was originally developed by IBM and is currently being maintained by the entire Linux Foundation.

The hyper-hedgehog Explorer is a tool for performing configuration management, block and transaction data query, and node management on a block chain, and information inside the block chain can be viewed through the hyper-hedgehog Explorer, such as: data such as account number, block number, transaction number and the like; meanwhile, the HyperLegger Explorer can also manage the block chain, such as executing common operations of deploying intelligent contracts, updating intelligent contracts and the like; the vision of HyperLEdger Explorer is to support all blockchain products below HyperLEdger, currently HyperLEdger Explorer supports only Fabric, and will gradually support more blockchain implementations in the future.

Based on the current situation of the prior art, the inventor of the application intends to provide a block chain-based distributed data transaction accounting system.

Disclosure of Invention

The invention aims to provide a block chain-based distributed data transaction accounting system based on the current situation of the prior art.

The invention relates to distributed data storage, point-to-point transmission and consensus mechanism technology, and the distributed data transaction accounting system based on a block chain comprises: using the front-end processor container as a communication tool to send and receive transactions between the physical machines; constructing a alliance chain by using the open-source HyperLegger Fabric; writing the transaction information into the block chain by compiling Monitor by java; using a couchdb database to perform rich queries; and displaying the block generation information in a visual way by using the open source tool fabric-explorer.

Specifically, the distributed data transaction accounting system based on the block chain is a data transaction accounting platform based on the block chain, and on the platform, a front-end processor container is used as a medium to send a request between a supply and demand party; the platform built by HyperLegger Fabric based on the block chain can store transaction logs between supply and demand parties in a distributed manner, and can visually show the block generation rate and the rate of writing transaction information into the block chain in real time. It comprises the following steps:

(1) The front-end processor receives and transmits the transaction:

the front-end processor of the supplier and the demander is provided with a sender. After the supplier transmits the data to the demander, the sender of the supplier writes the transaction information into a log file and sends the log file to a server of the transaction center, and after the demander receives the data, the sender of the demander writes the transaction information into the log file and sends the log file to the server of the transaction center;

the transaction center calculates and analyzes daily logs and generates a bill, and if the log of the acquirer and the log of the supplier are different on the same order, the transaction center takes the log of the acquirer as the standard;

since the local logs of the supplier and the demander may be tampered, the obtained result may be inaccurate if the tampered logs are used for consensus; for a transaction center, the most valuable trust mode is to directly write the log sent by the sender into a block chain;

(2) Data transaction prototype system supporting block chain

The invention uses 1.0 version of Hyperhedge fabric to construct a block chain system for a data transaction platform, a transaction center, a supplier and an demander need to solve the problem that a consistent distributed account book without cheating is automatically stored through the chaincode of the block chain, and participants in the system are not trusted with each other; .

In the invention, the distributed processing and the distributed storage are carried out by using the intelligent contract technology of the block chain in the payment transaction record, which is the problem that the transaction center is most preferably considered in the block chain field recently; this allows parties to store the same complete transaction information in their own servers to ensure a fair resolution of disputes, simplify flows and save resources.

The invention can make up the defect that the current trading center system only uses the log of the demand party, and the block chain link point of the (consensus, semi-centralization) trading center uses the intelligent contract to check the log of the data supplier and the log of the data demand party, then transmits the logs to the trading center, then writes the public part into the block chain, and tests whether the processing performance after adding the consensus meets the business requirement.

More specifically, the distributed data transaction accounting system based on the block chain is characterized in that the system is a data transaction accounting platform based on the block chain, in the platform, a front-end processor container is used as a communication medium to send requests between supply and demand parties, wherein transaction logs between the supply and demand parties are stored in a distributed mode, and the generation rate of the block and the rate of writing transaction information into the block chain can be visually displayed in real time; it includes:

(1) Relationship among transaction center, supplier and demander

The front-end processor of the supplier and the demander is provided with a sender; after the supplier transmits the data to the demander, the sender of the supplier writes the transaction information into a log file and sends the log file to a server of a transaction center; after the demander receives the data, the sender of the demander writes the transaction information into a log file and sends the log file to a server of a transaction center;

the transaction Center (SDEC) calculates and analyzes daily logs and generates bills, based on the log of the acquirer if the log of the acquirer and the log of the supplier are different on the same order.

(2) Supplier monitor processing transaction

The front-end processor of the supplier and the demander is provided with a specific script to send all transaction logs to a catalog corresponding to the transaction center;

a redis reads a log sent by an acquirer on a transaction center server, and the redis is called an acquirer;

a supplier monitor which is written by java and called as a leader is also arranged on the trading center server;

(3) Fabric-explorer visual display

While carrying out data transaction, the platform starts a fabric-explorer, namely a web page, for each channel, wherein each web page can visually display the number of generated blocks, the exid of the transaction and the generation rate of the exid;

(4) Data transaction prototype system supporting block chain

Constructing a block chain system for the data transaction platform by using the 1.0 version of the HyperLegendr fabric; the transaction center, the supplier and the demander jointly form the distributed data transaction system.

In the invention, the supplier monitorr is responsible for comparing the supplier logs and the demander logs in the redis, then compares the supplier logs and the demander logs, writes the same logs into a block chain, and adds the failed logs into a fail array;

and outputting the information of success and failure of comparison in a nohop.

In the invention, the transaction center, the supplier and the demander form a distributed data transaction system, a double-supplier and three-demander mode is adopted, the transaction center is added into each channel, and meanwhile, the transaction center is also used as an orderer node to be responsible for packaging transactions and generate blocks;

in the invention, the intelligent contract technology of the block chain is used for distributed processing and distributed storage in the payment transaction record, so that all parties can store the same and complete transaction information in the own server to ensure that disputes are solved fairly, the process is simplified and resources are saved; the block chain link point of the trading center checks the data supplier log and the data demander log by using an intelligent contract, then transmits the logs to the trading center, and writes the common part into the block chain.

In the invention, the transaction is sent to the SDEC from the front-end processor of the supplier and demander by adopting a 'push' strategy, and the transaction is sent once every 0.5 second by compiling a shell script, namely, a log file in a preposed concentrator/dep/go/log/busilog is sent to a record of a home/ubuntu/sender/busilog in the SDEC, the format of the log file is busi.

In the invention, the intelligent contract (chaincode) in the system supports a plurality of transaction data query modes, including querying transactions according to transaction numbers exid and querying according to time periods, namely querying logs in a certain time period; range query is also supported, namely all logs in a certain transaction number range are queried; and also supports rich query, namely querying a transaction log according to other transaction parameters, wherein the storage format of the transaction has the following fields: date, time, sublierID, demanderID, taskID, and exiD, a rich query may query the transaction log through one of the fields.

In the invention, the establishment of a channel and the writing of a transaction log in the system into an account book are respectively written in two functions, namely a channel _ fat.jar and a ridge _ fat.jar, which comprise: after starting each node container, establishing a channel by running java-jar channel _ fat.jar, after the establishment is successful, respectively starting a supplier monitor and a demander (namely redis), starting working when a log is sent, wherein the demander monitor is responsible for leading the demander log into the redis, the supplier monitor is responsible for comparing the logs in the supplier and the redis, and finally writing the successfully compared log into a block chain.

The invention provides a distributed data transaction accounting system based on a block chain, which uses an intelligent contract technology of the block chain to perform distributed processing and distributed storage in a payment transaction record, so that all parties can store the same and complete transaction information in own servers to ensure that disputes are solved fairly, the process is simplified and resources are saved; the method can overcome the defect that the current trading center system only uses the log of the demand party.

The invention has the advantages that: the problems that traditional data storage is over-centralized and lack of trust, data can be modified in the transmission process and the like can be solved, and consistent, anti-tampering, automatic and efficient bill recording, account book storage and intelligent clearing are achieved.

The technical solution of the present invention is described in detail below with reference to the accompanying drawings and examples.

Drawings

FIG. 1 is an architectural diagram of a first stage system design.

Figure 2 shows an endorsement strategy.

FIG. 3 shows pseudo code for both supplier and supplier to generate log information.

Fig. 4 is a system architecture diagram of the second stage.

Detailed Description

Example 1

Design of the first stage system, fig. 1 is an architectural diagram of the first stage system design,

(1) Overall architecture

The transaction records from the sender are absolutely tamper-proof, the SDEC hopes to load the log of the demander into the blockchain, and because the demander is the payer and the SDEC charges reasonably according to the actually received data demand, in the first step, the log of the demander can be directly loaded into the blockchain and the performance of the written blockchain is tested, if the performance can meet the demand of the actual service environment, the SDEC improves the laboratory environment into the business environment and realizes the path utilization;

where the log monitor needs to be rewritten,

to merge and process exid, a single data plan before transmission meets two conditions: 1. there are already 10 exids2. Timeout settings, for the second case it may be difficult to set a timer for each individual data and monitor it, and in addition, the transmission time of the processed data may be slightly delayed since the data does not need to be very time sensitive, after which the following strategy is taken:

reading the log file and uniformly processing all logs in the period according to a fixed time interval (tentatively 1 s), when the data with the same taskid contains 10 exid data, creating a new data (a two-dimensional array for storing the data), and when the logs in the period are completely processed, sending the two-dimensional array to an uploading function which sends the data to the demander one by one through java sdk;

in the log format of the shared service log in the first prototype material, only the required fields are written into the blockchain, including date, time, suppplierid, demanderID, taskID, and exID. Except for the exiD, the values of other fields are the same, and the performance of the fabric is met by combining a plurality of items of the exiD into one blockchain transaction record to shorten the storage of the blockchain;

test whether the number of merges (10, 50,1000,10000, etc.) affects the performance of the system:

endorsement strategy (as shown in figure 2):

endorsements are completed in the SDEC server, so that an endorser is always the node of the SDEC organization that joins the channel;

Sender：

the program is mainly used for log transmission between organizations, logs are usually sent to the SDEC or endorsement node by both supply and demand parties, and certain filtering conditions are added according to requirements to ensure the safety of information, so that a statement is necessary, and in actual use, the part of functions are finished by the SDEC party, and the embodiment can only meet the basic function requirements, but not the optimal performance;

this program is stored in the "from" folder, which exists only in the "SDEC" machine, with a path/home/ubuntu/sender, and contains: jar (function implementation), logsender23x.properties (configuration file, including time interval, read file path and other parameters), nohop.out (error output), restart23x.sh (restart sender process), blockchain. pem (key file) and busilog folder (store received logs), shutll.sh (close all senders);

and (3) operating commands: sh restart23x.sh start-up procedure, including implementation details:

using a pull policy: because the current model is relatively simple, the SDEC is used for remotely connecting to the host of a demander, extracting logs and writing the logs into the local, the ssh connection is used, and a key file (block chain. Pem) is used for logging in a login form, the method needs the authority of opening the log file of a target host, is very unsafe, is only used in a test environment, and regardless of the factor, a pull strategy can only deploy a sender on the SDEC instead of a per-demander;

tracking a log file: the log files are stored in the SDEC and are unified in the busilog directory, different memids have different sub-directories, the log file names are the same as the original text, and the log file names of the demanders are changed every day, so that the addresser needs to track the file names to accurately read the required logs;

reading and writing files: because of having the authority to change the log file of the demander, the invention uses a simpler read-write strategy: deleting and additionally writing during reading, determining that a required log does not exist in the subsequent steps (but is not in practical application) in an experimental environment, deleting the read content while reading, and simplifying read-write information;

parameter configuration: different sender processes have different parameter configurations, and meanwhile, the change times possibly occurring in the parameters are extracted and written into the attribute configuration file for the convenience of subsequent change;

(5) The acquirer log monitor:

the program mainly monitors logs, processes the logs according to some keywords, and outputs pseudo data to a java SDK program in real time, in the data query process, if the front end of a demander database does not have a corresponding cache, the program can request and acquire data from the front end of a supplier machine, both the supplier and the demand can generate log information, under the current environment, the method needs to upload the exid in the successful logs to a block chain, wherein the pseudo codes are shown in FIG. 3;

the program is stored in the monitor folder, and the supplier paths are: the/home/e _ dep/monitor, the requester path is: /opt/project/monitor; the folder contains four files: logmonitor. Jar (function implementation), logmonitor. Properties (configuration file, including time interval, input path and other parameters), nohup.out (error output), restart.sh (restart monitoring process);

(6) Analyzing functional requirements and realizing the same:

and (3) outputting in real time: the statistical result of the transaction platform needs to be output in real time, the default time interval is 1 minute, and the program uses a pseudo real-time output simplified program and improves the performance; the realization method comprises the following steps: when the process starts, setting a delay parameter: delay1, which is used to maintain the thread creation time in one minute, then create a statistical thread every 1 minute (configurable but necessary to be a divisor of 60), extract all log information in the previous minute for statistics, because the number of logs generated in each minute is different, the time cost in each statistics is different, but the timestamp outputting the statistical result will be based on the thread creation time;

reading a log: a log file generated when the data transfer is stored in the busilog folder, and two files generated on a daily basis based on dates, for example: busi.log. Succ.20170810 and busi.log. Err.20170810, (in today's use cases, it does not need to monitor and find failed files); when the process starts, a delay parameter is set: delay2 to keep track of creation of threads of log files at 24 o 'clock per day, then create a trace thread every 24 hours, if a satisfactory log file is found, update parameters rafsucc and referrer (note thread listening object), change listening object may cause data loss problem, in the above strategy, it should be noted that the statistical thread must be created within one minute, and the object of statistical thread created at 24 o' clock (note thread a) should still be the original object, so the trace thread only needs to finish replacing the monitoring object before creating the next statistical thread, so the delay parameter may be increased by several seconds (e.g. set to 30 seconds), but since thread a in the statistical process occupies parameter rafsucc, if the trace thread is run before statistics is finished, it will cause data loss, besides increasing the delay parameter, in order to effectively avoid data loss problem, it is necessary to improve the performance of statistical thread, and try to avoid trading at that time;

extracting necessary data: because a single load chain with a large number of exids cannot be tolerated due to traffic limitations loaded into the chain, the present invention brings teams into a chaining strategy, sets a group parameter (batchNum), tentatively 50, i.e., each group contains 50 exids, and the grouping is based on taskids. When the log is processed, comparing the taskid and the exid with the current group, if the taskid is matched, the exid is less than 50, and then adding the exid; or a new group is created, and information such as demanderID, supplierID, taskid and exid is stored, so that a single team enters a chain store, namely 50 people enter the chain store, and the efficiency is improved by 50 times; in addition, the program needs some fault-tolerant function, considering that there may be some incomplete log reading, for example, because the statistical thread is created once every minute, and the length obtained at this time may not be a submultiple of the log length, the "last" log may not be complete, and in fact, in actual operation, it often happens that the last log after each transaction is not always complete, for this reason, without loss of generality, the present invention saves the log to the next statistical thread to be read, which means that the pointer will come back, and in addition, if the log is wrongly written, appropriate measures should be taken to discard the invalid log and continue to read the subsequent valid log;

the parameters can be configured as follows: in fact, because of different operating environments, the parameters of the program need to be modified appropriately, and the invention sets the following parameters to be configurable in consideration of different operating environments, including: time interval (which may be a divisor of 60), log directory path, size of two-dimensional string array str (default of 100), group parameter (batchNum, defuel is 50), configuration file named logmonitor.

(7) Chaincode invocation and query

The linking code calls and related functions of the query phase 1 will be described below,

the process of calling the chaincode and completing these functions is as follows: firstly, a program calls java sdk to transfer parameters to chaincode, all the parameters are transferred to a function named Invoke, then the Invoke function calls other functions to complete corresponding functions according to the parameters, the chaincode provides different query modes,

the following table lists the function names and their functions:

the specific implementation procedure is as follows:

loading data

Function 1. Chain code Loading data function

Input aggregated transaction information including time, acquirer ID, supplier ID, job ID, count and exid arrays

Output is no

Step 1: reading an exid array from an input

Exid array ← input parameter

Step 2. Write the exid array and the necessary data into the Block chain +

storeExideArrayToBlockchain (time, acquirer ID, supplier ID, job ID, count, exid array)

return None

The function of loadData is to store the exid array into the block chain. First, the loadData function receives parameters from java sdk, including time, acquirer ID, supplier ID, job ID, transaction number, and exid array. Then, the function storeExideArrayToBlockchain is called to store all necessary information into the blockchain.

Querying data

Function 2. Chain code query data function

The exid array contains all the exids that the user wants to check whether to write to the blockchain

The summarized transaction information includes time, demander ID, supplier ID, job ID, count and exid arrays

The function of queryData is to query whether exid exists in the block chain. Initially, this function receives the exid array that the java sdk wants to query. And then traversing the array, constructing a query character string according to the exid, sending the query character string and obtaining a query result. The query results include time, demanderid, subliered, tasked, count, and exid arrays. And finally, summarizing all query results and returning.

c. Range query data

The function of queryDataByRange is to query all exid information present in the block chain within the epoch and return the total number of exids. The function receives three parameters, start time, end time and taskid. Then, a query string is constructed according to the three parameters and queried in the blockchain. Then, the query result is traversed, the count parameter is obtained from the query string, and all counts are added. Finally, the total number of exids is returned.

2. Second stage system design

(1) Integrated framework

The chainpode container of the endorsement node will traverse the exID array,

for each exiD, the chaincode will search whether it exists in nosql, because the performance of searching for the log file of the demander is very poor, the invention uses the key value database to improve the performance, if exiD exists, the chaincode will add it to the success array, if exiD does not exist, the chaincode will check again later, if exiD still does not exist, the chaincode will add it to the failure array, finally, the chaincode will write the transaction containing the success array into the block chain, and return the failure array to the supplier monitor; FIG. 4 is a diagram of a second stage system architecture;

(2) Endorsement strategy

Endorsements are completed in the SDEC server, so that an endorser is always a node of the SDEC organization joining the channel, and an endorsement policy file of Chaincode is the same as that of the first stage (as shown in FIG. 2);

(3) Sender and log monitors

The sender of the second stage is the same as that of the first stage,

the supplier Monitor of Stage2 is the same as the demander Monitor of the first Stage, and the improvement is carried out on the basis of the first Stage, which is mainly embodied in that:

a. processing invalid logs

Based on the discovery that the vast majority of invalid logs are determined to be invalid by a program as a result of dividing a single log into two lines during debugging, the present invention improves the process of invalid log handling: splicing two invalid logs possibly caused by the reasons, recovering to a valid log and recording the valid log;

update Str function modification

In order to cooperate with the function of processing the invalid log, the invention modifies and judges the invalid condition; the time of each record uploaded is changed from the original system time to the log time of the first record of each row

uploadStr function modification

Adjusting some parameters in the uploaded character string;

(4) Requiring log monitor

The function of the demander log monitor is to store the log information of the demander to the redis database, wherein the process of writing a single file into the redis database is shown; in the system, a plurality of demanders exist, log files of all the demanders are stored in the same folder, a plurality of processes are started to read the log files and then write the log files into a redis database, and because a plurality of suppliers possibly request the same exid data, the exid and the taskid are stored as values in the redis database;

(5) Chain code invocation and querying

The link code calls and inquires the related functions of the stage 1, the basic program and the function types are the same as those of the stage 1, compared with a stage 1 system, only the loadData () function is greatly different, in the stage, before the exid and the related information are stored in a block chain, the loadData () function needs to check whether the exid exists in a database, and the functions of other functions are the same as those of the stage 1 system;

loading data

The loadData function is to store the exid existing in the demand log and the supplier log into a block chain, firstly, a loadData function receives parameters from java sdk, wherein the parameters comprise Time, demanderID, suplierID, taskID, count and exid arrays, the function initializes two arrays, success _ array and fail _ array, and stores query success exids and failure exid, then, the function applies a redis connection pool, each Time when querying a redis database, a connection is required to be obtained from the connection pool, then, the exid in the exid array is traversed, the exid and a task are integrated into a value, when the value exists in the database, the value is put into the success array or stored in the failure array, and when the traversal is completed, a second pass is started; after the process, if the value is not in the redis database, the value is regarded as the final failed exid, and finally, the success array is stored in the block chain and the failed exids are returned;

when the traversal is completed, starting the second pass, after this process, if the value is also not in the redis database, it is treated as the final failed exid, and finally, the success array is stored to the blockchain and the failed exids are returned;

querying data

c. Range query data

/>

Claims

1. A distributed data transaction accounting system based on a block chain is characterized in that the system is a data transaction accounting platform based on the block chain, a front-end processor container is used as a communication medium in the platform, and a request is sent between a supply party and a demand party, wherein transaction logs between the supply party and the demand party are stored in a distributed mode, and the generation rate of a block and the rate of writing transaction information into the block chain can be visually displayed in real time; it includes:

(1) Relationship among transaction center, supplier and demander

a transaction Center (System Data Exchange Center, SDEC) calculates and analyzes daily logs and generates bills, and if the log of the acquirer and the log of the supplier are different on the same order, the transaction Center takes the log of the acquirer as a standard;

(2) Supplier monitor processing transaction

(3) Fabric-explorer visual display

(4) Data transaction prototype system supporting block chain

Constructing a block chain system for the data transaction platform by using the 1.0 version of the Hyperhedger fabric; the transaction center, the supplier and the demander jointly form the distributed data transaction system.

2. The block chain-based distributed data transaction billing system according to claim 1, wherein the supplier monitorr is responsible for comparing the supplier log and the demander log in the redis, reading the supplier log and the demander log, comparing them, writing the same log into the block chain, and adding the log that failed in comparison into the fail array;

the information of success and failure of the comparison is output in the nohup.

3. The block chain-based distributed data transaction billing system according to claim 1, wherein the transaction center, the supplier and the demander form a distributed data transaction system, a dual-supplier and three-demander mode is adopted, the transaction center joins each channel, and the transaction center also serves as an orderer node to perform the packaged transaction and generate the block.

4. The block chain-based distributed data transaction accounting system according to claim 1 or 3, wherein in the system, the intelligent contract technology of the block chain is used for distributed processing and distributed storage in the payment transaction record, so that each party can store the same complete transaction information in the own server to ensure that the disputes are solved fairly, the flow is simplified and the resources are saved; the block chain node of the trading center checks the log of the data supplier and the log of the data demander by using the intelligent contract, then transmits the logs to the trading center, and writes the common part into the block chain.

5. The block chain-based distributed data transaction accounting system of claim 1, wherein the transaction is sent from the supply and demand front-end processor to the SDEC by writing a shell script using a "push" strategy to be sent every 0.5 seconds, that is, the log file in the front-end set/dep/go/log/busiog is sent to the SDEC under the/home/ubuntu/sender/busiog directory, the log file format is busi.

6. The system of claim 1, wherein intelligent contracts (chaincodes) in the system support multiple transaction data query modes, including querying transactions according to transaction numbers exid and querying according to time periods, namely querying logs in a certain time period; range query is also supported, namely all logs in a certain transaction number range are queried; and also supports rich query, namely querying a transaction log according to other transaction parameters, wherein the storage format of the transaction has the following fields: date, time, sublierID, demanderID, taskID, and exID, and the rich query may query the transaction log through one of the fields.

7. The distributed data transaction accounting system based on the blockchain as claimed in claim 1, wherein the channel establishment and the transaction log writing accounts in the system are written in two functions, namely channel _ fat.jar and ridge _ fat.jar, respectively, which includes: after starting each node container, establishing a channel by running java-jar channel _ fat.jar, after the establishment is successful, respectively starting a supplier monitor and a demander (namely redis), starting working when a log is sent, wherein the demander monitor is responsible for leading the demander log into the redis, the supplier monitor is responsible for comparing the logs in the supplier and the redis, and finally writing the successfully compared log into a block chain.