CN110717825A - Distributed data transaction accounting system based on block chain - Google Patents
Distributed data transaction accounting system based on block chain Download PDFInfo
- Publication number
- CN110717825A CN110717825A CN201810682292.XA CN201810682292A CN110717825A CN 110717825 A CN110717825 A CN 110717825A CN 201810682292 A CN201810682292 A CN 201810682292A CN 110717825 A CN110717825 A CN 110717825A
- Authority
- CN
- China
- Prior art keywords
- transaction
- log
- supplier
- block chain
- demander
- 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.)
- Granted
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
- 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/12—Accounting
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
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 comprises the following steps: 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 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
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, besides competitive POW, also proof of authority POS and proof of delegation DPOS, etc.
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.
Blockchains allow for the validation and writing of transactions, a transaction being an operation that changes the state of data on the blockchain, old records always 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 prior 100 btc history is also permanently preserved, 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 (named super account book in Chinese) 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 together and 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 only supports 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 visually 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 includes:
(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 bills, and if the logs of the demander and the logs of the supplier are different on the same order, the transaction center takes the logs of the demander 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 that disputes are resolved fairly, simplifying the process and saving 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 log and the demander log, the supplier log and the demander log in the redis are read and then compared, the same log is written into a block chain, and the log which fails in comparison is added into a fail array;
the information of success and failure of the comparison is output in the nohup.
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, distributed processing and distributed storage are carried out by using an intelligent contract technology of a block chain in the payment transaction record, so that all parties can store the same and complete transaction information in the server of the parties, thereby ensuring that disputes are solved fairly, simplifying the flow and saving resources; 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.
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 (upgrading function) according to a fixed time interval (temporarily set as 1s), 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 a demander one by one through a 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 if the number of merges (10,50,1000,10000, etc.) would affect 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 a 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 addressers need 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 needed log does not exist in the subsequent steps (but is not in practical application) in an experimental environment, deleting the read content and simplifying read-write information during reading, wherein in a written file, even if a plurality of sender processes are running, writing directories according to different memids are different, so that writing conflict does not need to be considered;
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 supplier and demand parties 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 and realizing functional requirements:
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 is as follows: when the process starts, setting a delay parameter: delay1, which is used to keep 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 the 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 time stamp of the output 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 daily based on the date, 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, setting a delay parameter: delay2 to keep track of the creation of threads for log files 24 o 'clock per day and then create a trace thread every 24 hours, if a satisfactory log file is found, update the parameters rafsucc and raferr (statistical thread listens to objects), a problem of data loss may occur when changing listening objects, in the above strategy, it should be noted that the statistical thread must be created in one minute, and the object of the statistical thread created 24 o' clock (note thread a) should still be the original object, so the trace thread only needs to complete the replacement of the monitored object before the next statistical thread is created, so the delay parameter can be increased by a few seconds (e.g. set to 30 seconds), but since thread a in the statistical process occupies parameter rafsucc, if running the trace thread before the statistics is completed, will cause data loss, in addition to increasing the delay parameter, in order to effectively avoid the data loss problem, the performance of the statistical thread needs to be improved, and the transaction is avoided as much as possible;
extracting necessary data: because of the traffic limitations 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 chaining strategy, sets a group parameter (batchNum), tentatively 50, i.e., each group contains 50 exids, the grouping being 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, defualt is 50), configuration file named logmonitor.
(7) Chaincode invocation and query
The linking code call and the 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
Input aggregated transaction information including time, acquirer ID, supplier ID, job ID, count and exid arrays
Output is no
Exid array ← input parameter
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
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 from these 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 of the first Stage, and is improved on the basis of the first Stage, mainly by:
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 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 due to the fact that a plurality of suppliers may request the same exid data, the exid and 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 including Time, DemanderID, SupplierID, task id, Count and exid arrays from java sdk, the function initializes two arrays, success _ array and fail _ array, stores query success exids and failure exid, then, the function applies a redis connection pool, and when querying a redis database, a connection needs to be obtained from the connection pool, then, the exid in the exid array is traversed, the exid and task are integrated into a value, when the value exists in the database, the result is put into the success array or stored in the failure array, and when the traversal is completed, the 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 (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.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810682292.XA CN110717825B (en) | 2018-06-27 | 2018-06-27 | Distributed data transaction accounting system based on block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810682292.XA CN110717825B (en) | 2018-06-27 | 2018-06-27 | Distributed data transaction accounting system based on block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110717825A true CN110717825A (en) | 2020-01-21 |
| CN110717825B CN110717825B (en) | 2023-04-07 |
Family
ID=69208890
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810682292.XA Active CN110717825B (en) | 2018-06-27 | 2018-06-27 | Distributed data transaction accounting system based on block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110717825B (en) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111652615A (en) * | 2020-06-24 | 2020-09-11 | 杨刘琴 | Safety identification method based on block chain big data and artificial intelligence cloud service platform |
| CN111783133A (en) * | 2020-06-02 | 2020-10-16 | 广东科学技术职业学院 | Network resource management method based on block chain technology |
| CN112015796A (en) * | 2020-08-25 | 2020-12-01 | 广东广宇科技发展有限公司 | Block chain-based engineering inspection method, device, system, medium and equipment |
| CN112132680A (en) * | 2020-06-15 | 2020-12-25 | 合肥维天运通信息科技股份有限公司 | Logistics bill-receivable option DEFI trading market method and system based on block chain |
| CN112232937A (en) * | 2020-09-29 | 2021-01-15 | 辽宁便利电科技有限公司 | Intelligent processing system and method based on distributed accounting |
| CN112463265A (en) * | 2020-12-10 | 2021-03-09 | 南京知麦信息科技有限公司 | Agricultural product Internet of things information chaining method based on alliance chain |
| CN112508708A (en) * | 2020-12-13 | 2021-03-16 | 李力 | Block chain technology-based securitized cash flow tracking method and system |
| CN112835985A (en) * | 2021-03-12 | 2021-05-25 | 湖北星地智链科技有限公司 | Spatial data sharing system and method based on distributed account book |
| CN113987439A (en) * | 2021-10-28 | 2022-01-28 | 杭州迪普科技股份有限公司 | System and method for keeping command line authority consistent with page authority |
| CN114385488A (en) * | 2021-12-17 | 2022-04-22 | 杭州趣链科技有限公司 | Block chain testing method, device, equipment and storage medium |
| WO2022100063A1 (en) * | 2020-11-16 | 2022-05-19 | 平安科技（深圳）有限公司 | Method and apparatus for generating and storing logs of smart contract, device, and storage medium |
| CN114780968A (en) * | 2022-06-23 | 2022-07-22 | 国网区块链科技(北京)有限公司 | Intelligent contract upgrading method and device |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080097805A1 (en) * | 2006-10-23 | 2008-04-24 | Wells R Scott | Transaction processing method |
| CN105956923A (en) * | 2016-04-20 | 2016-09-21 | 上海如鸽投资有限公司 | Asset transaction platform and digital certification and transaction method for assets |
| CN106530088A (en) * | 2016-12-19 | 2017-03-22 | 杜伯仁 | Method for trading stock product based on block chain security nodes |
| CN107194798A (en) * | 2017-04-28 | 2017-09-22 | 广东网金控股股份有限公司 | A kind of bank clearing method based on block chain alliance chain |
| CN107423959A (en) * | 2017-08-07 | 2017-12-01 | 浙江宇安消防装备有限公司 | A kind of sending and receiving list and payment services expense operation system paid without fixed order |
| CN107786642A (en) * | 2017-09-30 | 2018-03-09 | 上海数据交易中心有限公司 | Block chain building method and device, storage medium, server for data circulation |
-
2018
- 2018-06-27 CN CN201810682292.XA patent/CN110717825B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080097805A1 (en) * | 2006-10-23 | 2008-04-24 | Wells R Scott | Transaction processing method |
| CN105956923A (en) * | 2016-04-20 | 2016-09-21 | 上海如鸽投资有限公司 | Asset transaction platform and digital certification and transaction method for assets |
| CN106530088A (en) * | 2016-12-19 | 2017-03-22 | 杜伯仁 | Method for trading stock product based on block chain security nodes |
| CN107194798A (en) * | 2017-04-28 | 2017-09-22 | 广东网金控股股份有限公司 | A kind of bank clearing method based on block chain alliance chain |
| CN107423959A (en) * | 2017-08-07 | 2017-12-01 | 浙江宇安消防装备有限公司 | A kind of sending and receiving list and payment services expense operation system paid without fixed order |
| CN107786642A (en) * | 2017-09-30 | 2018-03-09 | 上海数据交易中心有限公司 | Block chain building method and device, storage medium, server for data circulation |
Non-Patent Citations (1)
| Title |
|---|
| 张汉宁;朱秀文;: "敏捷供应链中供方收益研究" * |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111783133A (en) * | 2020-06-02 | 2020-10-16 | 广东科学技术职业学院 | Network resource management method based on block chain technology |
| CN112132680A (en) * | 2020-06-15 | 2020-12-25 | 合肥维天运通信息科技股份有限公司 | Logistics bill-receivable option DEFI trading market method and system based on block chain |
| CN111652615B (en) * | 2020-06-24 | 2021-01-29 | 广西新农商供应链科技有限公司 | Safety identification method based on block chain big data and artificial intelligence cloud service platform |
| CN111652615A (en) * | 2020-06-24 | 2020-09-11 | 杨刘琴 | Safety identification method based on block chain big data and artificial intelligence cloud service platform |
| CN112015796A (en) * | 2020-08-25 | 2020-12-01 | 广东广宇科技发展有限公司 | Block chain-based engineering inspection method, device, system, medium and equipment |
| CN112232937A (en) * | 2020-09-29 | 2021-01-15 | 辽宁便利电科技有限公司 | Intelligent processing system and method based on distributed accounting |
| WO2022100063A1 (en) * | 2020-11-16 | 2022-05-19 | 平安科技（深圳）有限公司 | Method and apparatus for generating and storing logs of smart contract, device, and storage medium |
| CN112463265A (en) * | 2020-12-10 | 2021-03-09 | 南京知麦信息科技有限公司 | Agricultural product Internet of things information chaining method based on alliance chain |
| CN112463265B (en) * | 2020-12-10 | 2023-11-14 | 南京知麦信息科技有限公司 | Agricultural product Internet of things information uplink method based on alliance chain |
| CN112508708A (en) * | 2020-12-13 | 2021-03-16 | 李力 | Block chain technology-based securitized cash flow tracking method and system |
| CN112835985A (en) * | 2021-03-12 | 2021-05-25 | 湖北星地智链科技有限公司 | Spatial data sharing system and method based on distributed account book |
| CN113987439A (en) * | 2021-10-28 | 2022-01-28 | 杭州迪普科技股份有限公司 | System and method for keeping command line authority consistent with page authority |
| CN114385488A (en) * | 2021-12-17 | 2022-04-22 | 杭州趣链科技有限公司 | Block chain testing method, device, equipment and storage medium |
| CN114780968A (en) * | 2022-06-23 | 2022-07-22 | 国网区块链科技(北京)有限公司 | Intelligent contract upgrading method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110717825B (en) | 2023-04-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110717825B (en) | Distributed data transaction accounting system based on block chain | |
| US11599555B2 (en) | Data manifest as a blockchain service | |
| Zheng et al. | Nutbaas: A blockchain-as-a-service platform | |
| US11341121B2 (en) | Peer partitioning | |
| US11449478B2 (en) | Blockchain implemented data migration audit trail | |
| US20190081793A1 (en) | Parallel-chain architecture for blockchain systems | |
| US20190333030A1 (en) | Blockchain-based digital token utilization | |
| EP3864817B1 (en) | Blockchain timestamp agreement | |
| US11706106B2 (en) | Resource lifecycle automation | |
| US10693646B2 (en) | Event execution using a blockchain approach | |
| US9020949B2 (en) | Method and system for centralized issue tracking | |
| US11720545B2 (en) | Optimization of chaincode statements | |
| WO2016070111A1 (en) | Cross-platform data synchronization | |
| US11816069B2 (en) | Data deduplication in blockchain platforms | |
| US20200169125A1 (en) | Wireless energy transfer | |
| Sukhwani | Performance modeling & analysis of hyperledger fabric (permissioned blockchain network) | |
| US11943360B2 (en) | Generative cryptogram for blockchain data management | |
| Li et al. | Cost-effective data feeds to blockchains via workload-adaptive data replication | |
| CN108460068A (en) | Method, apparatus, storage medium and the terminal that report imports and exports | |
| CN111429250A (en) | Data management method and device in escort scene | |
| Kirkman et al. | Using smart contracts and blockchains to support consumer trust across distributed clouds | |
| US12095924B2 (en) | System and method for generating blockchain token support from a set of declarations | |
| WO2022200891A1 (en) | Reducing transaction aborts in execute-order-validate blockchain models | |
| Nystrøm | Network Performance in Hyperledger Fabric-Investigating the network resource consumption of transactions in a Distributed Ledger Technology system | |
| Jaiswal | Parsec: A state channel for the internet of value |
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 |