CN110717825A - Distributed data transaction accounting system based on block chain - Google Patents

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 in particular relates to a distributed data transaction accounting system based on blockchain. The invention includes: using the front-end container as a communication tool to send and receive transactions between physical machines; using open source Hyperledger Fabric to build a consortium chain; using java to write a Monitor to write transaction information into the blockchain; using couchdb database for rich query ; Use the open source tool fabric‑explorer to visualize the block generation information. The invention solves the problems of over-centralization and lack of trust in traditional data storage, and data may be modified during transmission, and realizes consistent, tamper-proof, automatic and efficient billing records, account book preservation, and intelligent settlement.

Description

A distributed data transaction accounting system based on blockchain

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 in particular relates to a distributed data transaction accounting system based on blockchain.

Background technique

According to data, blockchain technology is considered to be another disruptive core technology after electricity and the Internet. As an underlying technology for building the Internet of Value, the blockchain will change the way of value transmission. The emergence of the blockchain will solve a very important problem - how to obtain unknown trust.

Blockchain technology is based on a decentralized peer-to-peer network. It uses open source software to combine cryptographic principles, time series data and consensus mechanisms to ensure the coherence and continuity of each node in the distributed database, so that information can be verified and traceable in real time. , but it is difficult to tamper with and cannot be shielded, thus creating a private, efficient and secure shared value system.

The traditional database uses the CS (client-server) network structure, in which the user can modify the data, and at the same time, the control of the database is also in a central organization, such as a company or organization, after they authenticate the client, they will provide access to the database. Access rights; this central institution (company or organization, etc.) is responsible for the management of databases, etc., and is a clear subject. If hackers are interested in data, once the institution is attacked and security is threatened, the data may be changed or even deleted; in addition , the risk of managers with authority within the organization also exists.

The traditional database has obvious traces of centralized services; the blockchain database is different. It consists of multiple distributed and decentralized nodes. All nodes participate in data management. Any data added to the ledger database will be confirmed by the nodes. These ledgers are open and transparent to all nodes, just like Bitcoin’s ledger to add transaction data, a consensus must be obtained, and the block can only be entered after the nodes have confirmed it. This consensus algorithm ensures the security of the network and also allows It cannot be tampered with; in addition to the POW of computing power competition, the consensus mechanism is the authorization certificate POS and the delegation authorization certificate DPOS.

In the traditional database, data can be created, read, modified and deleted; the blockchain design is more simplified, and the data modification and deletion operations are removed. Users can only add data to the block, and all enter the block. The confirmation data will not be changed, that is, it has only read and write operations: data can be queried and retrieved from the blockchain, more data can be written to the blockchain, and data cannot be modified or deleted. .

The blockchain allows the confirmation and writing of transactions. A transaction is an operation that changes the state of data on the blockchain. The old record remains unchanged, and the new record changes the past data state. If 100 btc are purchased with fiat currency, these will be permanently recorded on the blockchain. One day, a car is purchased with 10 bitcoins, the data of this transaction will be recorded on the blockchain, and the user bitcoin The wallet balance is left with 90 btc; however, the blockchain database will save all records, and the user's previous 100 btc history will also be permanently retained, while traditional databases are generally upgraded to the final data state.

Traditional databases are generally private, but blockchain data is open and verifiable to ensure completeness and transparency. Users can confirm that the blockchain data retrieved and consulted by themselves is complete and has not been tampered with, while traditional databases are very Hard to guarantee.

Hyperledger (Chinese name Hyperledger) is an open source project launched by the Linux Foundation in 2015 to promote blockchain digital technology and transaction verification. The goal of Hyperledger is to allow members to cooperate and build an open platform to meet the needs of multiple The needs of various users in the industry, while greatly simplifying business processes; Hyperledger's founding members include IBM, Intel, Cisco and other large companies.

Hyperledger is an innovation to the traditional blockchain model. Hyperledger provides a model that allows the creation of authorized and non-authorized blockchains to a certain extent. In addition, Hyperledger provides an A secure and robust model for auditing and privacy makes it possible to shorten computing cycles, increase efficiency at scale, and respond to application needs across industries.

Hyperledger Fabric is the core project of Hyperledger. Even in some occasions, when Hyperledger is mentioned, it is generally considered to refer to Fabric. This is actually a misunderstanding, but it also reflects the position of Hyperledger Fabric in Hyperledger from the side. Hyperledger Fabric is essentially a distributed shared ledger. The goal of Hyperledger Fabric is to become the basis for developing applications and solutions. In design, it adopts a modular architecture. The advantage of the modular architecture is that components can be flexibly configured as needed, which can be achieved Plug and play; Hyperledger Fabric was originally developed by IBM and is currently maintained by the entire Linux Foundation.

Hyperledger Explorer is a tool for configuration management, block and transaction data query, and node management of the blockchain. Through Hyperledger Explorer, you can view the internal information of the blockchain, such as: the number of ledgers, the number of blocks, the number of transactions, etc. At the same time, Hyperledger Explorer can also manage the blockchain, such as performing common operations such as deploying smart contracts and updating smart contracts; the vision of Hyperledger Explorer is to support all blockchain products under Hyperledger. Currently, Hyperledger Explorer only supports Fabric, and in the future More blockchain implementations will be gradually supported.

Based on the current state of the art, the inventor of the present application intends to provide a distributed data transaction accounting system based on blockchain. In the present invention, Hyperledger Fabric is used to build a distributed data transaction platform, and Hyperledger Explorer is used to visually display various kind of parameters.

SUMMARY OF THE INVENTION

The purpose of the present invention is to provide a blockchain-based distributed data transaction accounting system based on the current state of the art. In the present invention, Hyperledger Fabric is used to build a distributed data transaction platform, and Hyperledger Explorer is used to visually display various parameter.

The present invention relates to distributed data storage, point-to-point transmission, and consensus mechanism technologies. The blockchain-based distributed data transaction accounting system of the present invention includes: using a front-end container as a communication tool to send and receive transactions between physical machines ; Use the open source Hyperledger Fabric to build a consortium chain; use java to write Monitor to write transaction information into the blockchain; use the couchdb database for rich queries; use the open source tool fabric-explorer to visualize the block generation information.

Specifically, the blockchain-based distributed data transaction accounting system of the present invention is a blockchain-based data transaction accounting platform. On this platform, the front-end container is used as an intermediary to send requests between supply and demand parties. ; The platform built by the blockchain-based Hyperledger Fabric can store transaction logs between supply and demand parties in a distributed manner, and can visualize the generation rate of blocks and the rate at which transaction information is written to the blockchain in real time. It includes:

(1) Front-end sending and receiving transactions:

Both the supply-side and demand-side front-end computers have senders. After the supplier transmits the data to the buyer, the sender of the supplier writes the transaction information into the log file and sends it to the server of the trading center. After the buyer receives the data, the sender of the buyer writes the transaction information to the log file. into the log file and send it to the server of the trading center;

The trading center will calculate and analyze the daily logs, and generate bills. If the demander's log and the supplier's log are different in the same order, the trading center will take the demander's log as the standard;

Since the local logs of the supplier and the demander may be tampered with, if the tampered logs are used for consensus, the result may be inaccurate; for the trading center, the most trustworthy way is to send the sender The log is directly written to the blockchain;

(2) Data transaction prototype system supporting blockchain

The present invention uses the 1.0 version of Hyperledger fabric to build a blockchain system for the data trading platform, the trading center, the supplier and the demander need to solve the problem of automatically saving a non-spoofed, consistent distributed ledger through the chaincode of the blockchain, and Mutual distrust of the participants in the system; .

In the present invention, the smart contract technology of the blockchain is used in the payment transaction record for distributed processing and distributed storage, which is the most priority given by the transaction center in the blockchain field recently; The same complete transaction information is stored on the server to ensure fair dispute resolution, streamlining processes and saving resources.

In the present invention, smart contracts and consensus strategies are used to check the logs of the data supplier and the data demander to reach an agreement. It can make up for the defect that the current trading center system only uses the logs of the demander, and the (consensus, semi-centralized) trading center The blockchain nodes use smart contracts to check the data supplier's log and the data demander's log, then transmit it to the transaction center, and then write the public part to the blockchain to test whether the processing performance after adding consensus meets business requirements .

More specifically, the blockchain-based distributed data transaction accounting system of the present invention is characterized in that the system is a blockchain-based data transaction accounting platform, in which the front-end container is used as a communication intermediary, A request is sent between the supply and demand sides, wherein the transaction logs between the supply and demand sides are distributed and stored, which can visualize the generation rate of blocks and the rate at which transaction information is written into the blockchain in real time; it includes:

(1) The relationship between the trading center, the supplier and the demander

The front-end machines of the supplier and the buyer have senders; after the supplier transmits the data to the buyer, the sender of the supplier writes the transaction information to the log file and sends it to the server of the trading center; After the data is received, the sender of the buyer writes the transaction information into the log file and sends it to the server of the transaction center;

The trading center (System Data Exchange Center, SDEC) calculates and analyzes the daily logs, and generates bills. If the log of the demander and the log of the supplier appear different in the same order, the trading center shall take the log of the demander as the standard.

(2) Supply and demand side monitors process transactions

There is a specific script in the front-end machine of the supply and demand sides to send all transaction logs to the corresponding directory of the trading center;

There is redis on the transaction center server to read the logs sent by the demander, and the redis is called the demander Monitor;

There is also a supplier monitor called ledger written in java on the trading center server;

(3) fabric-explorer visual display

While conducting data transactions, the platform starts a fabric-explorer for each channel, that is, a web page, each web page can visually display the number of blocks generated, the exid of the transaction and its generation rate;

(4) Data transaction prototype system supporting blockchain

Use the 1.0 version of Hyperledger fabric to build a blockchain system for the data trading platform; the trading center, the supplier and the demander together constitute the described distributed data trading system.

In the present invention, the supply side monitorr is responsible for comparing the supply and demand side logs, reads the supply side logs and the demand side logs in redis and then compares them, writes the same logs into the blockchain, and the comparison fails The log is added to the fail array;

The information on the success and failure of the comparison is output in the nohup.out file.

In the present invention, the distributed data trading system composed of the trading center, the supplier and the demander adopts the mode of two suppliers and three demanders. The trading center joins each channel, and the trading center is also responsible for packaging transactions as an orderer node. and generate blocks;

In the present invention, the smart contract technology of blockchain is used for distributed processing and distributed storage in payment transaction records, so that all parties can store the same complete transaction information in their own servers to ensure a fair resolution of disputes, Simplifies the process and saves resources; the blockchain nodes of the trading center use smart contracts to check the logs of data suppliers and data demanders, and then transmit them to the trading center to write the public part to the blockchain.

In the present invention, the transaction is sent from the front-end machine on the supply and demand side to the SDEC using the "push" strategy, and the transaction is sent every 0.5 seconds by writing a shell script, that is, the log file in the front-end centralized /dep/go/log/busilog is sent to the SDEC In the /home/ubuntu/sender/busilog directory, the log file format is busi.log.succ.xxxxxx, and the log file is generated once a day.

In the present invention, the smart contract (chaincode) in the system supports a variety of transaction data query methods, including querying transactions according to the transaction number exid, and querying according to time periods, that is, querying logs within a certain time period; Query, that is, query all logs within a certain range of transaction numbers; it also supports rich query, that is, query transaction logs according to other transaction parameters, the transaction storage format has fields: date, time, supplierID, demanderID, taskID and exID, rich query The transaction log can be queried through one of the fields.

In the present invention, the channel built in the system and the transaction log written into the ledger are written in two functions, namely channel_fat.jar and ledger_fat.jar, which include: after starting each node container, by running java-jar channel_fat. The jar establishes a channel. After the establishment is successful, the supplier monitor and the demander monitor (ie redis) are started respectively, and the work starts when the log is sent. The demander monitor is responsible for importing the demander log into redis, and the supplier monitor is responsible for comparing Logs in the supplier and redis, and finally write the successful log to the blockchain.

The present invention provides a blockchain-based distributed data transaction accounting system. In payment transaction records, the smart contract technology of the blockchain is used for distributed processing and distributed storage, so that all parties can use their own servers to perform distributed processing and storage. Store the same complete transaction information to ensure fair dispute resolution, simplify the process and save resources; use smart contracts and consensus strategies to check the logs of the data supplier and data demander to reach an agreement. Can make up for the current transaction center system only Defects in using demand-side logs.

The advantages of the invention are as follows: it can solve the problems of over-centralization and lack of trust in traditional data storage, and the data may be modified during the transmission process, and realize consistent, tamper-proof, automatic and efficient billing records, account book preservation, and intelligent settlement.

The technical solutions of the present invention will be described in detail below with reference to the accompanying drawings and embodiments.

Description of drawings

Figure 1 is the architecture diagram of the first stage system design.

Figure 2 shows the endorsement strategy.

Figure 3 shows the pseudocode for the generation of log messages between the supply and demand sides.

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

Detailed ways

Example 1

The design of the first stage system, Figure 1 is the architecture diagram of the first stage system design,

(1) Overall structure

The transaction record from the sender is absolutely tamper-proof. SDEC hopes to load the log of the demander into the blockchain. Since the demander is the payer, it is reasonable for SDEC to charge according to the actual received data demand, so in the first In one step, the user's log can be directly loaded into the blockchain, and the performance of writing to the blockchain can be tested. If the performance can meet the needs of the actual business environment, SDEC will improve from a laboratory environment to a business environment, and realize path utilization;

The log monitor program needs to be rewritten here,

In order to merge and process exids, a single data plan before sending meets two conditions: 1. There are already 10 exids 2. A timeout is set, for the second case it may be difficult to set a timer for each individual data and run it Monitoring, in addition, since the data does not need strong timeliness, the transmission time of the processed data can be slightly delayed. After that, the following strategies are adopted:

According to a fixed time interval (tentatively set to 1s), read the log file and process all logs during this period uniformly (upgrade function), when the data with the same taskid contains 10 exid data, it will create a new data (one A two-dimensional array for saving data), when the logs of this period are completely processed, the two-dimensional array is sent to the upload function, which will send these data to the requester one by one through the java sdk;

In the log format of the business log shared in the materials of the first prototype, only the required fields are written to the blockchain, including date, time, supplierID, demanderID, taskID and exID. Except for exID, the values of other fields are the same. By merging multiple items of exID into one blockchain transaction record, the storage of the blockchain is shortened to meet the performance of the fabric;

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

Endorsement strategy (as shown in Figure 2):

The endorsement is done in the SDEC server, so the endorser is always the node of the SDEC organization joining the channel;

Sender:

This program is mainly used for log transmission between organizations. Logs are usually sent to SDEC or endorsement nodes by both supply and demand parties, and certain filtering conditions are added according to requirements to ensure the security of information. It is necessary to declare that in actual use, this part of the function It will be completed by the SDEC side, and in this embodiment, only basic functional requirements can be achieved, not optimal performance;

The program is stored in the "sender" folder, only exists in the "SDEC" machine, the path is /home/ubuntu/sender, the folder contains: FileReaders.jar (function implementation), LogSender23X.properties (configuration file , including time interval, read file path and other parameters), nohup.out (error output), restart23X.sh (restart sender process), blockchain. pem (key file) and busilog folder (stores received logs), shutdown.sh (closes all senders);

Run the command: sh retart23X.sh to start the process, which includes the implementation details:

Use pull strategy: Since the current model is relatively simple, use SDEC to remotely connect to the demander's host, extract logs and write locally, use ssh to connect, use the key file (blockchain.pem) to log in to the login form, this method requires opening the target host Permissions on the log file, which is very insecure, it is only used in test environments, regardless of this factor, the pull policy can deploy the sender only on SDEC and not per-demander;

Tracking log files: The log files are stored in SDEC and are unified in the busilog directory. Different memids will have different subdirectories. The log file name is the same as the original one. Since the log file name of the requester changes every day, it is sent One needs to keep track of filenames to read exactly the logs needed;

Read and write files: Due to the authority to change the log file of the demander, the present invention uses a simpler read and write strategy: delete when reading, and write additionally. In the experimental environment, it is determined that the required log does not exist in the subsequent steps ( But not in practical applications), so while reading, delete the read content, and simplify the read and write information, in the write file, even if there are multiple sender processes running, according to the different memid write directory will also be different, so there is no need to consider write conflicts;

Parameter configuration: The parameter configuration will be different for different sender processes. At the same time, in order to facilitate subsequent changes, the number of possible changes in the parameters is extracted and written into the attribute configuration file;

(5) Demander log monitor:

This program mainly monitors the logs, processes them according to some keywords, and outputs the pseudo data to the javaSDK program in real time. During the data query process, if the front end of the demander database does not have a corresponding cache, it will request and obtain the front end of the supplier opportunity. Data, both the supply and demand sides will generate log information. In the current environment, the present invention needs to upload the exid in the successful log to the blockchain, and the pseudocode is shown in Figure 3;

The program is stored in the monitor folder, the supplier path is: /home/e_dep/monitor, and the demander 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 the monitoring process);

(6) Functional requirements analysis and its realization:

Real-time output: The statistical results of the trading platform of the present invention require real-time output, and the default time interval is 1 minute. The program uses pseudo-real-time output to simplify the program and improve performance; implementation: when the process starts, set the delay parameter: delay1, which is used for a Keep the thread creation time within minutes, and then create a statistics thread every 1 minute (configurable, but must be a divisor of 60), extract all log information in the previous minute for statistics, due to the different number of logs generated per minute, Therefore, the time cost in each statistic is different, but the timestamp of the output statistic result will be based on the thread creation time;

Log reading: log file generated when data transfer is stored in busilog folder and two files generated daily based on date, for example: busi.log.succ.20170810 and busi.log.err.20170810, (in today's use case, it does not need to monitor and find out failure files); when the process starts, set the delay parameter: delay2 to keep the creation of the thread that traces the log file 24 o'clock every day, and then creates a trace thread every 24 hours, if found Satisfied log file, update parameters rafsucc and raferr (statistical thread monitoring object), data loss may occur when changing the listening object, in the above strategy, it should be noted that the statistical thread must be created within one minute, and 24 o'clock The object created by the statistics thread (note thread A) should still be the original object, so the tracking thread only needs to finish replacing the monitoring object before creating the next statistics thread, so the delay parameter can be increased by a few seconds (e.g. set to 30 seconds), but Since thread A in the statistics process occupies the parameter rafsucc, if the tracking thread is run before the statistics are completed, it will cause data loss. Therefore, in addition to increasing the delay parameter, in order to effectively avoid the problem of data loss, it is necessary to improve the performance of the statistics thread, and try to avoid the transaction at that time;

Extract the necessary data: Due to the limitation of the flow loaded into the chain, a single load chain with a large number of exids cannot be tolerated, the present invention brings the team into the chain strategy, and sets a group parameter (batchNum), tentatively set to 50, that is, each group Contains 50 exids, grouped based on taskid. When processing the log, compare its taskid and exid with the current group, if the taskid matches, the exid is less than 50, and then join the exid; or create a new group, save the demanderID, supplierID, taskid, exid and other information, so a single team enters A chain store, equivalent to 50 people entering a chain store, is 50 times more efficient; in addition, the program also needs some fault tolerance, considering that there may be some log reads that are incomplete, for example, because the statistics thread is created every minute, and the obtained at this time The length may not be a divisor of the log length, and the "last" log may not be complete. In fact, in practice, it often occurs that the last log after each transaction is not always complete. In general, the present invention saves the log to the next statistical thread to be read, which means that the pointer will come back. In addition, if the log is written incorrectly, there should be appropriate measures to discard the invalid log and continue to read the subsequent ones. valid log;

Parameters can be configured: In fact, due to different operating environments, the parameters of the program need to be appropriately modified. Considering different operating environments, the present invention sets the following parameters as configurable, including: time interval (which can be a divisor of 60), The log directory path, the size of the two-dimensional string array str (the default value is 100), the group parameters (batchNum, default is 50), and the configuration file is named LogMonitor.properties;

(7) Chaincode call and query

The following will introduce the relevant functions of the link code call and query stage 1,

The process of calling chaincode and completing these functions is as follows: First, the program calls java sdk to pass parameters to chaincode, all parameters will be passed to a function named Invoke, then this Invoke function will call other functions according to the parameters to complete the corresponding function, and this chaincode provides different query methods,

The following table lists the function names and their functions:

The specific implementation procedures are as follows:

load data

Function 1. Chaincode load data function

Input: Aggregated transaction information including time, buyer ID, supplier ID, job ID, count and exid array

output: none

/* Step 1: Read exid array from input */

Exid array ← input parameter

/* Step 2: Write the exid array and necessary data to the blockchain */

storeExidArrayToBlockchain(time, demander ID, supplier ID, job ID, count, exid array)

return None

The function of loadData is to store the exid array into the blockchain. First, loadData function receives parameters from java sdk, which includes time, demander ID, supplier ID, job ID, number of transactions and an array of exid. Then, call the function storeExidArrayToBlockchain to store all the necessary information into the blockchain.

Query data

Function 2. Chaincode query data function

Input: The exid array contains all the exids that the user wants to check if written to the blockchain

Output: Aggregated transaction information including time, buyer ID, supplier ID, job ID, count and exid array

The function of queryData is to query whether the exid exists in the blockchain. At first, this function receives an array of exids that the java sdk wants to query. Then, traverse the array, construct a query string based on exid, send the query string and get the query result. The query result includes an array of time, demanderid, supplierid, taskked, count and exid. Finally, all query results are aggregated and returned.

c. Range query data

The function of queryDataByRange is to query all exid information in the blockchain in the time period and return the total number of exid. The function receives three parameters, start time, end time and taskid. Then, a query string is constructed based on these three parameters and queried in the blockchain. Then, iterate through the query results, get the count parameter from the query string and add all counts. Finally, return the total number of exids.

2. System design of the second stage

(1) Overall structure

The chaincode container of the endorsing node will traverse the exID array,

For each exID, chaincode will search if it exists in nosql, since the performance of searching the requester's log file is poor, the present invention uses a key value database to improve performance, if the exID exists, chaincode will add it to the success array, If the exID does not exist, the chaincode will check again later, if the exID still does not exist, the chaincode will add it to the failure array, and finally, the chaincode will write the transaction containing the success array to the blockchain and return the failure array To the supplier monitor; Figure 4 is the system architecture diagram of the second stage;

(2) Endorsement strategy

The endorsement is done in the SDEC server, so the endorser is always the node of the SDEC organization that joins the channel, and the endorsement policy file of Chaincode is the same as that of the first stage (as shown in Figure 2);

(3) Sender and log monitors

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

The supply-side monitor of Stage 2 is the same as the demand-side monitor of the first stage, and it is improved on the basis of the first stage, which is mainly reflected in:

a. Handling invalid logs

Based on the fact that in the debugging process, it is found that most of the invalid logs are caused by dividing a single log into two lines, which causes the program to judge them as invalid. The present invention improves the invalid log processing process: splicing two invalid logs that may be caused by the above reasons , revert to a valid log and record it;

b.updateStr function changes

In order to cooperate to realize the function of processing invalid logs, the present invention modifies the conditions for judging invalid; the time of each uploaded record is changed from the original system time to the log time of the first record of each line

c.uploadStr function changes

Adjust some parameters in the uploaded string;

(4) Demander log monitor

The function of the demander's log monitor is to store the demander's log information in the redis database, which shows the process of writing a single file into the redis database; in the system of the present invention, there are multiple demanders, and the log files of all demanders are All are stored in the same folder, start multiple processes to read the log file, and then write to the redis database. Since multiple suppliers may request the same exid data, the present invention stores the exid and taskid as the values in the redis database ;

(5) Chaincode call and query

The described link code calls and queries the related functions of phase 1. The basic program and function types are the same as those of phase 1. Compared with the system of phase 1, only the loadData() function is very different. In this phase, the exid and Before the relevant information is stored in the blockchain, the loadData() function needs to check whether there is an exid in the database, and the functions of other functions are the same as the first stage system;

load data

The loadData function is to store the exid existing in the demand log and supplier log into the blockchain. First, the loadData function receives parameters from the java sdk, including Time, DemanderID, SupplierID, TaskID, Count and exid arrays, the function initializes two Arrays, success_array and fail_array, store the query success exids and failure exids, then, this function applies the redis connection pool, each time, when querying the redis database, you need to get a connection from the connection pool, and then traverse the exid in the exid array, Integrate exid and task as a value, when the value exists in the database, put it in the success array, or store it in the failure array, when this traversal is complete, start the second pass; after the process, if the value is not in either In the redis database, it is regarded as the exid of the final failure, and finally, the success array is stored in the blockchain and the exid of the failure is returned;

When this traversal is completed, start the second pass, after this process, if the value is not in the redis database either, treat it as the final failed exid, and finally, store the success array to the blockchain and return the failed exids;

Query data

c. Range query data

Claims (7)

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

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;

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

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.

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, a 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.

Images