CN111724258B - Method for realizing alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control - Google Patents
Method for realizing alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control Download PDFInfo
- Publication number
- CN111724258B CN111724258B CN202010468431.6A CN202010468431A CN111724258B CN 111724258 B CN111724258 B CN 111724258B CN 202010468431 A CN202010468431 A CN 202010468431A CN 111724258 B CN111724258 B CN 111724258B
- Authority
- CN
- China
- Prior art keywords
- transaction
- node
- message
- nodes
- dependency graph
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 35
- 238000012545 processing Methods 0.000 claims abstract description 14
- 238000012163 sequencing technique Methods 0.000 claims description 24
- 238000012795 verification Methods 0.000 claims description 8
- 238000002474 experimental method Methods 0.000 claims description 7
- 238000010276 construction Methods 0.000 claims description 4
- 230000000694 effects Effects 0.000 claims description 4
- 238000011156 evaluation Methods 0.000 claims description 4
- 238000004806 packaging method and process Methods 0.000 claims description 2
- 238000012546 transfer Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 2
- KDYFGRWQOYBRFD-UHFFFAOYSA-N succinic acid Chemical compound OC(=O)CCC(O)=O KDYFGRWQOYBRFD-UHFFFAOYSA-N 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000000052 comparative effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Development Economics (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to a realization method of a alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control, which can solve the problem of low performance of an alliance chain transaction processing mode in a more conflict environment, reduce the complexity of a consensus process, enable an alliance chain system to execute transactions in parallel in different conflict environments and generate deterministic results while maintaining better performance.
Description
Technical Field
The invention belongs to the fields of databases and cryptography, relates to techniques of blockchain, intelligent contract, transaction parallelism, concurrency control and the like, and particularly relates to a realization method of a alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control.
Background
A blockchain, i.e., a series of blocks, each containing all transaction data over a period of time, and a hash value of the previous block, similar to a conventional public ledger, is a distributed database that records transaction data maintained by many nodes in the absence of a central node. Blockchains can be categorized into public chains, federated chains, and private chains by different applications.
The federation chain is "partially decentralised" in that the joining of nodes requires authorization from a particular authority, such as TENDERMINT, but the nodes in the federation chain are not fully trusted. Applications deployed on the federation chain require high performance in terms of throughput and latency, such as financial applications that need to process tens of thousands of requests per second and require very low latency.
Smart contracts are based on these trusted, non-tamperable data that can be automated to execute some predefined rules and terms. The intelligent contract is used as a code deployed on the blockchain, and is signed and released by both transaction parties together, and once the conditions are met, the intelligent contract can be automatically executed, so that the fairness of transaction execution is ensured. Intelligent contracts have transactional requirements at the time of execution, that is, execution of the contract needs to satisfy four characteristics of atomicity, isolation, consistency, and durability.
Concurrency control is used in databases to ensure that data results are not inconsistent when multiple transactions operate on the same data item at the same time. The multi-version concurrency control allows the system to record multiple versions of a single data so that a transaction can read data that already existed before it was read, without affecting the transaction even if the data was modified by another transaction during his reading.
The practical byesting fault-tolerant algorithm (PRACTICAL BYZANTINE FAULT TOLERANCE, PBFT) is used for constructing a high-availability system tolerant to byesting faults, the byesting fault-tolerant (Byzantine Fault Tolerance, BFT) problem is a core problem to be solved in block chain consensus, and the consensus algorithms such as Proof Of Work (POW), proof Of equity (POS), proof Of trust (DELEGATED PROOF OF STAKE, DPOS) and the like solve BFT in the case Of numerous nodes, while PBFT is suitable for consensus in the case Of fewer nodes such as a coalition chain.
Disclosure of Invention
The invention aims to overcome the defects of the prior art, and provides a realization method of a alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control, which solves the problem of low performance of an alliance chain transaction processing mode under the environment of more conflicts, reduces the complexity of a consensus process, enables an alliance chain system to execute transactions in parallel under different conflict environments, generates deterministic results and maintains better performance.
The invention solves the technical problems by the following technical proposal:
a realization method of a alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control is characterized by comprising the following steps: the method comprises the following steps:
S1, sending a transaction request, enabling a sequencing node to agree on transaction sequences of different application programs by adopting a Bayesian-preemption fault-tolerant consensus protocol based on ring topology, packaging the transactions into blocks, and constructing a dependency graph among the transactions according to the transactions in the blocks;
S2, after receiving the blocks and the dependency graphs sent by the sequencing nodes, the execution nodes broadcast the blocks to all the execution nodes, and the dependency graphs are generated and broadcast to all the execution nodes;
S3, the executing node with the intra-block transaction executing authority performs concurrent execution of the transaction according to the dependency graph;
s4, after broadcasting the execution result, all the execution nodes verify the transaction and update the state of the block chain;
s5, evaluating and verifying the effect of the alliance chain transaction concurrency scheme through experiments.
Moreover, the specific operation of the step S1 is as follows: checking whether a request sent by a client is legal or not, sequencing the legal request, constructing a block, and adopting a Bayesian fault-tolerant consensus protocol based on ring topology to reach consensus by nodes in a alliance chain system; the RTBFT protocol enables the message to carry an array of f+1 messages signed by a private key of a sending node, the address of the sending node and the addresses of f+1 nodes after the sending node in the message transmission process; when the message arrives at the exit node, the exit node sends an ACK message, the node receiving the ACK message can mark the transaction in the list maintained locally as stable, if the transaction has the minimum number at this time, the node adds the transaction into the block and the dependency graph, and the process ensures the consistency of the transaction sequence in the block generated by all the nodes.
Moreover, the specific operation of the step S2 is as follows: generating and transmitting transaction dependency graphs in the blocks in parallel when the ordering nodes transmit the transaction blocks containing the time sequence according to the agreed transaction sequence in the blocks, maintaining a thread pool locally, and dividing the generation of the blocks and the construction of the dependency graphs by processing the generation of different blocks and the construction of the dependency graphs in parallel through multithreading so that the ordering nodes can generate the next block while constructing the dependency graphs.
Moreover, the specific operation of the step S3 is as follows: after receiving legal information of the specified number of blocks and the dependency graphs thereof, the executing node enters an executing stage; in the stage, the executing node carries out concurrent execution of the transaction according to the received dependency graph, after the executing node receives the new block message sent by the ordering node and the message of the dependency graph of the block, the executing node verifies the signature and hash value of the message, and if the message is legal, the executing node records the message to the local; meanwhile, the executing node also detects the set A of application programs related to the transaction in the block, and judges whether the transaction needing to be executed by the executing node in the new block. The execution node enters the execution verification phase after receiving the message of f+1 new blocks.
Moreover, the specific operation of the step S4 is as follows: the execution node updates the state of the block chain after receiving the submitted information of a certain number of execution nodes; if an executing node finds itself as not an agent of any transaction in the block after receiving the block, it only needs to wait for other executing nodes to submit their execution results and record the number of times the corresponding transaction is submitted, and after the node receives a certain number of commit messages of other nodes for the transaction, it can be considered that the transaction passes the verification of all nodes on the network, and the node can update its local blockchain state accordingly.
Moreover, the specific operation of the step S5 is as follows: the transaction number processed by the block chain system per second is used as an evaluation index, and the average result after 20 nodes run for many times is used as a final experimental result to eliminate experimental errors, wherein the experimental result comprises 10 sequencing nodes and 10 executing nodes.
The invention has the advantages and beneficial effects that:
1. The trade concurrency scheme applicable to the conflict-oriented environment of the alliance chain is a trade concurrency scheme based on ring topology, dependency graph and multi-version control, adopts a trade processing mode of firstly sequencing and then concurrency execution, comprises two stages of sequencing and execution, in the sequencing stage, a Bayesian-tolerant consensus protocol based on ring topology is adopted by a sequencing node to determine the trade sequence in a block so as to reduce the complexity of the consensus process, the dependency graph is built according to a read-write set of the trade, a multi-version concurrency control technology is adopted, only a conflict relation of first writing and then reading among the trade is reserved, finer granularity concurrency is realized, and meanwhile, the sequencing node adopts a parallel mode to transmit the block and the dependency graph thereof, so that the communication cost of the transmission process is reduced; in the execution stage, the execution node performs concurrent execution and verification of the intra-block transaction according to different versions of the locally maintained intra-block data item write operation and the dependency graph, and the correctness of an execution result is ensured.
2. Experiments prove that the alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control can have better transaction processing speed in conflict environments of different degrees.
3. The alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control can solve the problem of low performance of an alliance chain transaction processing mode in the environment with more conflicts, and simultaneously reduce the complexity of a consensus process, so that the alliance chain system can execute transactions in parallel in different conflict environments and generate deterministic results while maintaining better performance.
Drawings
FIG. 1 is a flow diagram of transaction concurrency scheme transaction processing based on ring topology, dependency graph, and multi-version control;
FIG. 2 is a table of experimental evaluation indicators for different collision rates.
Detailed Description
The invention is further illustrated by the following examples, which are intended to be illustrative only and not limiting in any way.
A realization method of a alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control is shown in fig. 1, and is characterized in that: the method comprises the following steps:
Step S0101: the client c sends a transaction request to any ordering node i and signs the request message msg, namely < REQUES T; an op; a, A is as follows; ts C;c;i;Hc＞σc for sending a request for operation op of application a to node i on behalf of client c. The message is also accompanied by an array H c, each item in the array is composed of the addresses of f+1 nodes in sequence including the node i selected by the client, the own address and the signature of the transmitted request by using the private key, as shown in formula (1):
Step S0102: the node i (entry node) receiving the client request firstly judges the validity of the request, if the request is legal, the receiver in the attached array H c is processed as own data, the array is updated as H pi, and the message is less than REQ after signature; msg; id; i; h pi＞σpi is transmitted along the torus network to the following nodes, where id is the number of the request, remains-1 until the sequenced node is encountered, is numbered by the sequenced node after it reaches the sequenced node, and i is the node number of the ingress node. Typically, the sequencing node is p 0.
Step S0103: after each node in the network receives the message, firstly verifying whether the message is sent by the own preamble node or not, if so, traversing the array attached to the message, finding out f+1 pieces of data of which the receiving side is the own, confirming that the message is not tampered, deleting the f+1 pieces of data, adding the data to the sender as the own after, signing the data of f+1 nodes of which the receiving side is the own after, and forwarding the message along a ring. If the message is already numbered at this time, the node places the message in the correct location of the locally maintained message list according to the number.
Step S0104: if the node that receives the message is a sequencing node, the sequencing node continuously numbers the message according to the sequence in which the message is received, i.e. modifies the id data field in the message. The sequencing node maintains a counter locally, which is incremented by 1 each time a new message is received. The prescribed number id starts from 1. Counters maintained locally by other nodes are used to count the number of messages currently processed.
Step S0201: in the scheme proposed by the present invention, the conflict dependency between two transactions exists only in the case of read-before-write, given a transaction set T in one block, the dependency graph of that block can be represented as g= (T, E), where T＝{T1,T2,T3...Tn},E＝{(Ti,Tj)|Tj＞Ti,Tj∈T}.
Step S0202, in the process of constructing the dependency graph, each data item has a corresponding operation support set ψ (k) and a latest write operation set L (k), wherein k is a data item related to a transaction, and the specific definition is as shown in a formula (2) and a formula (3):
The support set ψ (k) only comprises the last transaction to write the data item k, i.e. no other transaction to write the data item k after the transaction or a series of transactions to read only the data item k after the last write operation. So by maintaining the support set ψ (k), including L (k), it is only necessary to analyze the relevant elements in ψ (k) at the time of inserting the transaction T j to determine how to insert T j into the dependency graph G.
Step S0203: the time sequence of transactions is:
ts(T5)＜ts(T1)＜ts(T6)＜ts(T2)＜ts(T8)＜ts(T3)＜ts(T4)＜ts(T7)
The order of transactions within the block after each ordering node achieves consensus is:
Thereafter, the ordering node constructs a dependency graph between transactions according to the agreed intra-block transaction order.
Step S0204: data item A is contained in T 4, and read and write operations are performed on A. As can be seen by examining both ψ (A) and L (A), the now saved transaction in ψ (A) is T 3 and T 3 is a read operation for data item A, so a new edge from L (A) (T 5) pointing from T 5 to T 4 is needed, and then ψ (A) is updated to contain only the transaction T 4 of the most recent write operation, and at the same time L (A) is updated to T 4, until the transaction T 4 is processed.
Step S0205: the processing transaction T 7,T7 then contains two data items B and C. For data item B, T 2 is the most recent write operation within ψ (B), and transaction T 7 is a read operation on B, it is necessary to add an edge from T 2 to T 7 representing the dependency between them, and update ψ (B) to contain only transaction T 7.
Step S0206: for data item C, ψ (C) contains transaction T 3 and T 3 is the most recent write operation of data item C, transaction T 7 is also a read operation on C, so it is also necessary to add an edge from T 3 to T 7 representing the collision dependency between them. Thus, the construction of the dependency graph between the intra-block transactions is completed.
Step S0301: after receiving legal messages of the specified number of blocks and the dependency graphs thereof, the executing node enters an executing stage, and executes concurrent execution of the transaction according to the received dependency graphs, wherein pre (T i) is used for representing all the preceding nodes of the transaction T i, and succ (T i) is used for representing all the following nodes of the transaction T i. Formalized definition is shown in formula (4):
Given a dependency graph
Step S0302: for each data item involved in transaction T i, one all the different versions up to now are maintained for processing from the current block. And then, if the read operation is met, only a proper version is searched from the state locally maintained by the user for reading.
Step S0303: adding the read data item (x) and its version (x, version) to the result set resultSet of the corresponding transaction; if a write operation is encountered, then the executing node will need to add a record (x, newValue, version) to a different version of the data maintained locally, indicating that transaction T i changed the data item to newValue, and then add the record to the result set resultSet of transaction T i as well.
Step S0304: after the transaction T i is processed, the transaction number and the transaction processing result (T i, resultSet) are added to the executed transaction set ExcuteSet EN of the execution node EN.
Step S0401: when node EN performs intra-block transaction processing, it first detects that the transaction it needs to perform is T 5,T1,T6,T3,T7, so EN adds these 5 transactions to its set of transactions to be performed, waitSet EN＝{T5,T1,T6,T3,T7.
Step S0402: the set of transactions to be executed is examined and two transactions T 5 and T 1 are found to be executable at this time, so node EN uses two threads to execute transactions T 5 and T 1 in parallel.
Step S0403: EN detectsSo after EN process T 5.T5 ends, node EN tests the subsequent node set succ of T 5 (T 5)＝{T2,T3,T4), finds that transactions T 2 and T 4 that are not allowed to be executed by itself are present in its subsequent nodes, and if node EN has already executed transactions T 1 and T 6 at this time, he needs to broadcast a COMMIT message containing the execution results of T 5,T1 and T 6 to all other executing nodes, then waits for a COMMIT message containing the execution results of T 2(T4) broadcast by other nodes, when node EN receives a message specifying the same execution result of transaction T 2(T4) from a number of other nodes, the blockchain state is updated while transaction T 2(T4) is added to committed set CommitSet EN. EN will continue to look at the set of transactions WaitSet EN＝{T3,T7 to be executed at this time after broadcasting out the message containing the execution results of transactions T 5、T1 and T 6, and find that T 3 can be executed, so EN processes transaction T 3. Now only T 7 remains in the transaction set to be executed, node EN detects that the preamble node set pre of T 7 (T 7)＝{T2,T3) has been executed at this time T 3, so T 3 is at ExcuteSet EN, if at this time node EN has received a specified number of valid messages containing T 2, then at this time T 2 is at CommitSet EN, node EN can execute the transaction T 7. Otherwise, EN needs to wait for messages broadcast by other nodes until T 2 can be added CommitSet EN. After the execution of T 7 ends, now ExcuteSet EN has only T 7, so node EN broadcasts the execution of T 7
Step S0404: when the node EN finds that all transactions in the current block are in the submitted set CommitSet EN, the node EN completes execution verification and state update of the current block, achieves the purpose of consistent state with the blockchain maintained by other nodes, and can enter the execution verification and state update process of the next block.
Step S0501: the effect of the scheme of the invention is evaluated and verified by calculating the number of transactions processed per second by the blockchain system.
The scheme RDMC of the invention is oriented to a alliance chain system and adopts a transaction processing mode of firstly sequencing and then concurrently executing verification, and the scheme is mainly compared with two existing transaction processing modes of Seria and BTEC when the overall performance of the system is evaluated.
The experiment simulates a plurality of clients sending transaction requests to the ordering node, and the transaction size is set to a fixed value. Four schemes of RDMC, RDMC-A, BTEC and Serial were compared in terms of overall performance.
The invention adopts the transaction number processed by a block chain system per second as an evaluation index of a scheme, and a calculation formula is shown as a formula (5):
Where Num (tx) is the number of transactions effectively processed and time is the time it takes to process a transaction.
The experimental effect of the comparative experiment is shown in fig. 2, with the abscissa being the block size and the ordinate being the system throughput. Two simple Token contracts deployed on different applications are used in the present invention: smartContractA, and SmartContractB to simulate a client's transaction requests for applications deployed on different execution nodes. Basic functions such as transfer and balance inquiry can be performed in both contracts, and the difference is that a plurality of transfers can be performed in SmartContratA and only one transfer can be performed in SmartContractB. In the experiment, the transfer operation of different transactions on the same account represents the conflict relation between the transactions, and the conflict rate of the transactions in the block is the proportion of the conflict transactions to all the transactions in the block. In the experimental process, 10 repeated experiments are run each time, and then the average value is calculated as a final result, so that experimental errors are eliminated as much as possible.
Except for the case of 100% conflict rate, RDMC has TPS values higher than other schemes. At a collision rate of 100%, the throughput of RDMC and RDMC-A will be lower than that of Serial, because at a collision rate of 100%, the transactions in RDMC and RDMC-A are performed serially as in Serial, but the dependency graph and multi-version concurrency control techniques introduced in RDMC and RDMC-A to ensure the correctness of the parallel results have a certain time consumption. Experimental results prove that the performance optimization scheme RDMC provided herein can maintain good performance under conflicting environments of different degrees.
Figure 2 compares the knowledge of the number of transactions processed per second by the system at different conflict rates for four different schemes, with the concurrency of transactions scheme based on ring topology, dependency graph, and multi-version control being the best for the federated chain system.
Although the embodiments of the present invention and the accompanying drawings have been disclosed for illustrative purposes, those skilled in the art will appreciate that: various substitutions, changes and modifications are possible without departing from the spirit and scope of the invention and the appended claims, and therefore the scope of the invention is not limited to the embodiments and the disclosure of the drawings.
Claims (5)
1. A realization method of a alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control is characterized by comprising the following steps: the method comprises the following steps:
s1, sending a transaction request, enabling a sequencing node to agree on transaction sequences of different application programs by adopting a Bayesian-preemption fault-tolerant consensus protocol based on ring topology, packaging the transactions into blocks, and constructing a dependency graph among the transactions according to the transactions in the blocks; the step S1 specifically comprises the following steps:
S0101: the client c sends a transaction request to any ordering node i and signs the request message msg, namely < REQUES T; an op; a, A is as follows; ts C;c;i;Hc＞σc for sending a request for operation op of application a to node i on behalf of client c; the message is also accompanied by an array H c, each item in the array is composed of the addresses of f+1 nodes in sequence including the node i selected by the client, the own address and the signature of the transmitted request by using the private key, as shown in formula (1):
Step S0102: the entry node i receiving the client request firstly judges the validity of the request, if the request is legal, the data of the receiver in the attached array H c is processed and the array is updated to H pi, and after signature, the message is less than REQ; msg; id; i; h pi＞σpi is transmitted to subsequent nodes along the ring network, wherein id is the number of the request, the id is kept to be-1 before encountering a sequencing node, the sequencing node is numbered after the id reaches the sequencing node, i is the node number of an entry node, and the sequencing node is p 0 in general;
Step S0103: after each node in the network receives the message, firstly verifying whether the message is sent by the own preamble node or not, if so, traversing the array attached to the message, finding out f+1 pieces of data of which the receiver is own, confirming that the message is not tampered, deleting the f+1 pieces of data, adding the sender as the receiver after that, signing the data of f+1 nodes of which the receiver is own, and forwarding the message along a ring; if the message is already numbered at this time, the node puts the message in the correct position of the message list maintained locally according to the number;
step S0104: if the node receiving the message is a sequencing node, the sequencing node continuously numbers the message according to the sequence of the message, namely, modifies the id data field in the message, the sequencing node locally maintains a counter, and the counter is increased by 1 when a new message is received; providing that the number id starts from 1, and counting the number of the messages which are processed currently by using a counter which is maintained locally by other nodes;
step S0201: the conflicting dependencies between two transactions only exist in the read-before-write case, given a set of transactions T in a block, the dependency graph for that block can be represented as g= (T, E), where T＝{T1,T2,T3...Tn},E＝{(Ti,Tj)|Tj＞Ti,Tj∈T};
Step S0202: in the process of constructing the dependency graph, each data item has a corresponding operation support set ψ (k) and a latest write operation set L (k), wherein k is the data item involved in the transaction, the dominant set ψ (k) only comprises the latest transaction for writing the data item k, namely, no other transaction is performed on the data item k after writing the transaction or a series of transactions for reading the data item k after the latest write operation, so that by maintaining the support set ψ (k) comprising L (k), how to insert T j into the dependency graph G can be determined by only analyzing relevant elements in ψ (k) when inserting the transaction T j;
step S0203: the time sequence of transactions is:
ts(T5)＜ts(T1)＜ts(T6)＜ts(T2)＜ts(T8)＜ts(T3)＜ts(T4)＜ts(T7)
The order of transactions within the block after each ordering node achieves consensus is:
After that, the ordering node constructs a dependency graph between transactions according to the agreed intra-block transaction sequence;
step S0204: t 4 contains a data item A, and performs read operation and write operation on the A; as can be seen by examining both ψ (A) and L (A), the now saved transaction in ψ (A) is T 3 and T 3 is a read operation for data item A, so a new edge from L (A) (T 5) pointing from T 5 to T 4 is needed to be added, and then ψ (A) is updated to contain only the transaction T 4 of the latest write operation, and meanwhile L (A) is updated to T 4, so far the transaction T 4 is processed;
Step S0205: processing transaction T 7,T7 then includes two data items B and C, for which item B, ψ (B) is T 2 and is the most recent write operation, and transaction T 7 is a read operation on B, so it is necessary to add an edge from T 2 to T 7 representing the dependency between them, and update ψ (B) to include only transaction T 7;
Step S0206: for data item C, ψ (C) contains transaction T 3 and T 3 is the most recent write operation of data item C, transaction T 7 is also a read operation on C, so it is also necessary to add an edge from T 3 to T 7 to represent the conflict dependency between them, so far, the dependency graph construction between intra-block transactions is completed;
S2, after receiving the blocks and the dependency graphs sent by the sequencing nodes, the execution nodes broadcast the blocks to all the execution nodes, and the dependency graphs are generated and broadcast to all the execution nodes;
S3, the executing node with the intra-block transaction executing authority performs concurrent execution of the transaction according to the dependency graph;
s4, after broadcasting the execution result, all the execution nodes verify the transaction and update the state of the block chain;
s5, evaluating and verifying the effect of the alliance chain transaction concurrency scheme through experiments.
2. The method for implementing the alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control according to claim 1, wherein the method comprises the following steps: the step S1 further includes that when the message arrives at the egress node, the egress node sends an ACK message, the node that receives the ACK message may mark the transaction in the locally maintained list as stable, if the transaction has the smallest number at this time, the node adds the transaction to the block and the dependency graph, and the process ensures consistency of the transaction sequence in the blocks generated by all the nodes.
3. The method for implementing the alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control according to claim 1, wherein the method comprises the following steps: the specific operation of the step S3 is as follows: after receiving legal information of the specified number of blocks and the dependency graphs thereof, the executing node enters an executing stage; in the stage, the executing node carries out concurrent execution of the transaction according to the received dependency graph, after the executing node receives the new block message sent by the ordering node and the message of the dependency graph of the block, the executing node verifies the signature and hash value of the message, and if the message is legal, the executing node records the message to the local; meanwhile, the executing node also detects the set A of application programs related to the transaction in the block, judges whether the transaction needing to be executed by the executing node is in the new block, and enters an executing verification stage after the executing node receives the message of f+1 new blocks.
4. The method for implementing the alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control according to claim 1, wherein the method comprises the following steps: the specific operation of the step S4 is as follows: the execution node updates the state of the block chain after receiving the submitted information of a certain number of execution nodes; if an executing node finds itself as not an agent of any transaction in the block after receiving the block, it only needs to wait for other executing nodes to submit their execution results and record the number of times the corresponding transaction is submitted, and after the node receives a certain number of commit messages of other nodes for the transaction, it can be considered that the transaction passes the verification of all nodes on the network, and the node can update its local blockchain state accordingly.
5. The method for implementing the alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control according to claim 1, wherein the method comprises the following steps: the specific operation of the step S5 is as follows: the transaction number TPS processed by the block chain system per second is used as an evaluation index, and the average result after 20 nodes run for many times is used as a final experimental result to eliminate experimental errors, wherein the experimental result comprises 10 sequencing nodes and 10 executing nodes.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010468431.6A CN111724258B (en) | 2020-05-28 | 2020-05-28 | Method for realizing alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010468431.6A CN111724258B (en) | 2020-05-28 | 2020-05-28 | Method for realizing alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111724258A CN111724258A (en) | 2020-09-29 |
| CN111724258B true CN111724258B (en) | 2024-05-31 |
Family
ID=72565388
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010468431.6A Active CN111724258B (en) | 2020-05-28 | 2020-05-28 | Method for realizing alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111724258B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112508573B (en) * | 2021-01-29 | 2021-04-30 | 腾讯科技（深圳）有限公司 | Transaction data processing method and device and computer equipment |
| CN114338711B (en) * | 2021-12-27 | 2024-03-26 | 上海简苏网络科技有限公司 | Quick consensus method, system, electronic equipment and readable storage medium based on distributed network |
| CN114328133A (en) * | 2022-03-16 | 2022-04-12 | 北京微芯感知科技有限公司 | Single-mechanism distributed conflict detection method and system and deposit separation framework |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108111604A (en) * | 2017-12-21 | 2018-06-01 | 广州广电运通金融电子股份有限公司 | Block chain common recognition methods, devices and systems, identification information treating method and apparatus |
| CN108537543A (en) * | 2018-03-30 | 2018-09-14 | 百度在线网络技术（北京）有限公司 | Method for parallel processing, device, equipment and the storage medium of block chain data |
| CN108564470A (en) * | 2018-04-17 | 2018-09-21 | 北京天德科技有限公司 | The transaction distribution method of block is built in a kind of block chain parallel |
| CN109377232A (en) * | 2018-12-20 | 2019-02-22 | 众安信息技术服务有限公司 | The transaction method for sequencing and equipment of block chain based on DAG |
| CN109784916A (en) * | 2018-12-12 | 2019-05-21 | 广东工业大学 | A method of ether mill common recognition mechanism that improving PBFT is applied to alliance's chain |
| CN110648125A (en) * | 2019-09-10 | 2020-01-03 | 杭州秘猿科技有限公司 | Packaging transaction method and device and electronic equipment |
| CN111179071A (en) * | 2018-11-09 | 2020-05-19 | 北京天德科技有限公司 | Block chain transaction dependence analysis method based on topological sorting |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10764031B2 (en) * | 2017-12-07 | 2020-09-01 | International Business Machines Corporation | Blockchain system for pattern recognition |
-
2020
- 2020-05-28 CN CN202010468431.6A patent/CN111724258B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108111604A (en) * | 2017-12-21 | 2018-06-01 | 广州广电运通金融电子股份有限公司 | Block chain common recognition methods, devices and systems, identification information treating method and apparatus |
| CN108537543A (en) * | 2018-03-30 | 2018-09-14 | 百度在线网络技术（北京）有限公司 | Method for parallel processing, device, equipment and the storage medium of block chain data |
| CN108564470A (en) * | 2018-04-17 | 2018-09-21 | 北京天德科技有限公司 | The transaction distribution method of block is built in a kind of block chain parallel |
| CN111179071A (en) * | 2018-11-09 | 2020-05-19 | 北京天德科技有限公司 | Block chain transaction dependence analysis method based on topological sorting |
| CN109784916A (en) * | 2018-12-12 | 2019-05-21 | 广东工业大学 | A method of ether mill common recognition mechanism that improving PBFT is applied to alliance's chain |
| CN109377232A (en) * | 2018-12-20 | 2019-02-22 | 众安信息技术服务有限公司 | The transaction method for sequencing and equipment of block chain based on DAG |
| CN110648125A (en) * | 2019-09-10 | 2020-01-03 | 杭州秘猿科技有限公司 | Packaging transaction method and device and electronic equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111724258A (en) | 2020-09-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Amiri et al. | Parblockchain: Leveraging transaction parallelism in permissioned blockchain systems | |
| CN111724258B (en) | Method for realizing alliance chain transaction concurrency scheme based on ring topology, dependency graph and multi-version control | |
| Ruan et al. | A transactional perspective on execute-order-validate blockchains | |
| US12073400B2 (en) | Method and system for an efficient consensus mechanism for permissioned blockchains using audit guarantees | |
| EP4224780B1 (en) | Method and system for desynchronization recovery for permissioned blockchains using bloom filters | |
| JP2023546249A (en) | Transaction processing methods, devices, computer equipment and computer programs | |
| WO2021233167A1 (en) | Transaction processing method and apparatus, computer device, and storage medium | |
| CN111736964B (en) | Transaction processing method and device, computer equipment and storage medium | |
| CN111932257B (en) | Block chain parallelization processing method and device | |
| US11632293B2 (en) | Tamper-evidence processing by comparing updated objects or by comparing summaries thereof | |
| CN111444027B (en) | Transaction processing method and device, computer equipment and storage medium | |
| CN114157550B (en) | Alliance block chain system based on conflict-free transaction merging | |
| CN115098228B (en) | Transaction processing method and device, computer equipment and storage medium | |
| Kokociński et al. | On mixing eventual and strong consistency: Acute cloud types | |
| Monteiro et al. | A mechanism for replicated data consistency in mobile computing environments | |
| Mukherjee et al. | Data mining-based hierarchical transaction model for multi-level consistency management in large-scale replicated databases | |
| US20220121643A1 (en) | System with tamper-evidence | |
| Klianev | Different perspectives on FLP impossibility | |
| Monteiro et al. | Using transaction isolation levels for ensuring replicated database consistency in mobile computing environments | |
| CN112561695B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| Korchiev et al. | Taming the Beast of User-Programmed Transactions on Blockchains: A Declarative Transaction Approach | |
| Zhao et al. | Efficient Partial Order Based Transaction Processing for Permissioned Blockchains | |
| Ma et al. | Key-Based Transaction Reordering: An Optimized Approach for Concurrency Control in Hyperledger Fabric | |
| Chen et al. | A Comprehensive Survey of Blockchain Scalability: Shaping Inner-Chain and Inter-Chain Perspectives | |
| CN116846916A (en) | Data synchronization method, device, electronic equipment and computer readable storage medium |
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 |