CN113835847B - Transaction processing optimization method of distributed account book platform based on snapshot - Google Patents
Transaction processing optimization method of distributed account book platform based on snapshot Download PDFInfo
- Publication number
- CN113835847B CN113835847B CN202110915260.1A CN202110915260A CN113835847B CN 113835847 B CN113835847 B CN 113835847B CN 202110915260 A CN202110915260 A CN 202110915260A CN 113835847 B CN113835847 B CN 113835847B
- Authority
- CN
- China
- Prior art keywords
- transaction
- write
- concurrent
- transactions
- read
- 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 38
- 238000005457 optimization Methods 0.000 title claims abstract description 17
- 238000012545 processing Methods 0.000 title claims abstract description 9
- 238000001514 detection method Methods 0.000 claims description 16
- 238000012856 packing Methods 0.000 claims description 11
- 230000001419 dependent effect Effects 0.000 claims description 4
- 125000002015 acyclic group Chemical group 0.000 claims description 2
- 230000001960 triggered effect Effects 0.000 claims description 2
- 238000012795 verification Methods 0.000 claims 6
- 239000004744 fabric Substances 0.000 abstract description 13
- 238000002474 experimental method Methods 0.000 abstract description 2
- 230000002159 abnormal effect Effects 0.000 abstract 1
- 230000005856 abnormality Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 206010000210 abortion Diseases 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000000149 penetrating effect Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2255—Hash tables
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Abstract
The invention belongs to the technical field of blockchains, and particularly relates to a snapshot-based distributed ledger platform transaction processing optimization method. The method comprises the following steps: by subdividing the transactions in the EOV framework used by the distributed ledger platform, defining the concurrent transaction types of the blockchain system applicable to the EOV framework; analyzing the dependency relationship among abnormal transactions in the distributed ledger platform, providing a block chain system transaction serializable scheduling strategy based on an EOV framework, and reordering the transactions according to the scheduling strategy; transaction optimization based on snapshot is realized on the distributed ledger platform, and the performance of the distributed ledger platform under various load conditions is improved. Experiments show that the optimized analysis distributed ledger platform is superior to the original Fabric and the existing various optimized Fabric versions in terms of effective transaction throughput and average transaction delay.
Description
Technical Field
The invention belongs to the technical field of blockchains, and particularly relates to a snapshot-based distributed ledger platform (Hyperledger Fabric) transaction processing optimization method, namely a method for optimizing Hyperledger Fabric to improve performance under different conflict loads.
Background
With the development of the blockchain system, in order to meet various actual business requirements, the blockchain system is not developed into a general transaction system only as an encrypted currency circulation platform. Public blockchains, such as ethernet, that support smart contracts, are representative of the 2.0 era of blockchains, which enable users to perform custom operations on top of blockchains, smart contracts are disclosed to run transparently on top of blockchains, which enables applications such as de-centralized finance, cross-border payment and settlement clearing to be developed on top of blockchains, but at this point blockchain technology has not broken loose the tie of cryptocurrency to the financial domain. The advent of the 3.0 era of blockchains, which is no longer limited to the financial field but is widely used in medicine, is now increasingly unsuitable as an infrastructure for many practical applications, and the advent of the federation chain Hyperledger Fabric (distributed ledger platform) has led to the interest in such blockchain systems based on the Execute-Order-valid (EOV) transaction architecture, unlike the Order-Execute framework used by conventional blockchains, which allows transactions to be executed concurrently in the Execute phase.
While the new EOV framework effectively improves the concurrency of transactions, it may result in an excessive abort of a series of conflicting transactions by acting on the MVCC (multi-version concurrency control) check mechanism of the validation phase when the transaction serializable scheduling is completed. Such aborts can reduce the throughput of the transaction because the blockchain itself requires expensive costs in the transaction to complete encryption and consensus. Work such as fabric++ and FabricSharp is followed to reduce excessive aborting of conflicting transactions to improve transaction throughput of HyperledgerFabric. The invention is inspired by an optimistic concurrency control mechanism (optimistic concurrency control, OCC), analyzes a serializable snapshot isolation implementation method in a database, discovers that abnormality still exists in serializable scheduling in FabricSharp, and further analyzes abnormality among concurrent transactions in an EOV framework to complete serializable scheduling of the transactions.
Therefore, the invention provides a hyperspectral fabric transaction processing optimization method based on the FabricSharp, and the dependency graph among transactions is established, and an EOV framework is optimized by using a reordering method so as to reduce the abort rate of the transactions in serializable scheduling.
Disclosure of Invention
The invention aims to provide a snapshot-based distributed ledger platform transaction processing optimization method, which is used for improving the performance of a block chain system based on an EOV framework of the distributed ledger platform under various loads, and improving the effective transaction throughput and average delay by reducing the transaction abort rate.
The invention provides a snapshot-based distributed ledger platform transaction optimization method, which comprises the following steps:
(1) First, transactions in a blockchain system are subdivided:
according to the characteristics of the transactions in the block chain system based on the EOV framework (namely, the transactions have different life cycles in the EOV framework due to different read-write sets), the types, concurrency types and dependency relationships among the transactions are refined, and the transactions in the EOV framework are classified according to the read-write sets of the transactions, for example, the transactions are divided into read-only transactions only acting on an Execute stage and write-only transactions and read-write transactions penetrating through the EOV framework; defining a series of concurrency types of transactions facing the EOV framework, types of the transactions and dependency relations among the transactions for the subdivided transactions, and perfecting concurrency transaction classification of a block chain system suitable for the EOV framework;
specifically, the invention defines concurrent transactions as transactions with the existence time overlapped with a read-write set, and defines c-rw dependence (concurrent read-write dependence), anti-rw dependence (concurrent reverse read-write dependence) and c-ww dependence (concurrent write-write dependence) existing among the concurrent transactions (as shown in figure 2);
(2) Second, a transaction serializable scheduling policy in the blockchain system is determined:
the dependency graph loop-free method proposed by FabricSharp still has the occurrence of read-only transaction abnormality in the blockchain system based on the EOV framework (such as FIG. 1) of hyperledgerFabric, and the root cause is that the read-only transaction is verified only by the peer nodes without the consensus of the ordering nodes; the invention combines the characteristics of the transactions in the HyperledgerFabric, and provides a new serializable scheduling strategy, namely, the serializable scheduling of the transactions in the HyperledgerFabric is ensured by avoiding the occurrence of a ring structure of a dependency graph formed by anti-rw (concurrent reverse read write) dependency relationship among the concurrent transactions of the cross-block and the concurrent transactions in the block; however, when the strategy is implemented, a certain complexity still exists, especially when the loop structure of the dependency graph of the concurrent transaction in the block is detected, so a more strict serializable scheduling strategy is further proposed, namely anti-rw dependency among all concurrent transactions is strictly forbidden, so that although more transactions can be aborted, simplicity and high efficiency exist in implementation, and the rate of the aborting can be further optimized by a reordering method;
(3) Then, the transactions in the blockchain system are reordered:
the transaction in the EOV framework is reordered to achieve serializable scheduling of the transaction, so that the transaction processing efficiency is improved; reordering is to change the original sequence of the transactions in the block when the ordering node packs the block, and the serializable transaction scheduling is completed by strictly prohibiting anti-rw dependence of concurrent transactions in the block, and the abort rate of the transactions in the process is reduced by means of a reordering method; since the reordering method can only act on concurrent transactions in the same block, and the reordering method affects dependency relationships among concurrent transactions in the block (as shown in fig. 3), the reordering method based on different transactions in the EOV framework is further proposed:
for the write-only transaction, the write-only transaction cannot become the composition of rings in the dependency graph due to the characteristic of the write-only set, so that the write-only transaction is not considered in the subsequent reordering link, and the write-only transaction is simply placed at the last position in the block only when the block is packed out finally, and thus the write-only transaction is processed without anti-rw dependency with concurrent transactions in other blocks;
for read-write transactions, if no ring formed by anti-rw dependence and c-rw dependence exists in the concurrent transactions in the block, the anti-rw dependence can be converted into the c-rw dependence through reordering, so that serialization scheduling of the transactions is achieved; if the concurrent transaction in the block has a ring formed by anti-rw dependence and c-rw dependence, discarding the transaction in the ring; when the packing out condition is triggered, reordering the transactions in the block according to the topological ordering, and packing out the block;
(4) Finally, the snapshot-based Hyperledger Fabric transaction described above is implemented on Hyperledger Fabric; the invention can improve the performance of transactions in the blockchain under various loads while ensuring serialization scheduling.
The flow of reordering in the method of the invention (see fig. 4) is further described below:
1. and (3) performing dependency detection analysis: when a new transaction arrives at the ordering node, dividing the new transaction into a write-only transaction and a read-write transaction according to whether the transaction has a read set or not; for a write-only transaction, the write-only transaction is simply put into a write-only transaction queue without anti-rw dependency detection of cross-block concurrent transactions; for a read-write transaction, judging whether the transaction has anti-rw dependence which is concurrent with the transaction in the previous block in a cross-block manner, if so, discarding the transaction, and if not, entering the next flow;
in a specific implementation, for a write-only transaction, directly adding the write-only transaction into a write-only transaction queue, for a read-write transaction, detecting whether anti-rw dependence exists between cross-block concurrent transactions or not, recording write sets in all submitted blocks and block numbers submitted recently by the write sets by using a hash Map, and when the snapshot numbers read by a key of the write set of the current transaction are smaller than the submitted block numbers of corresponding keys in the Map, considering that anti-rw dependence exists between the current transaction and a certain cross-block concurrent transaction, and discarding the anti-rw dependence so as to save system resources; a reordering algorithm that can enter a next stage by relying on the detected transaction;
2. and (3) carrying out reordering feasibility analysis: after the read-write transaction passes the inspection of the step 1, only the c-rw dependence of the transaction and concurrent transactions in other blocks is calculated, because the transaction capable of serialization scheduling can only be submitted in the c-rw dependence, any anti-rw dependence needs to be reordered to be converted into the c-rw dependence; if a c-rw dependent ring appears at this time, it means that the transactions in the ring cannot all complete the commit of the transaction in c-rw dependence, and the transactions in the ring need to be deleted to maintain the acyclic attribute of the dependency graph, where we choose to delete the new transaction; if no ring appears, the transaction can be serialized and scheduled, and then the transaction is added into the transaction set waiting for the block;
the method comprises the steps that whether a read-write transaction can be submitted through reordering is detected by maintaining a c-rw dependency graph G of concurrent transactions in one block, and if the read-write transaction can be submitted through reordering, the read-write transaction is added into a waiting transaction queue to wait for a package to be carried out; the detection relies on a depth-first-based searching method, when a new transaction and the dependency relationship thereof are added into a dependency graph, a round of depth-first searching is carried out by taking the new transaction as a starting point, if other transaction points are present in the traversal process, serializable scheduling can be completed by keeping loop-free in the dependency graph G to ensure that all transactions in the G, because anti-rw dependency is not allowed to exist between concurrent transactions, the anti-rw dependency between any intra-block concurrent transactions is converted into c-rw dependency through reordering; if there is a loop with c-rw dependency in G, it means that there is necessarily a transaction in the ring that cannot be committed with c-rw dependency, and the transaction in the ring needs to be discarded to ensure that the transaction in G can be scheduled in a serializable manner;
3. and (3) block packing: when a block sending condition is touched, carrying out topological ordering on the existing loop-free transaction dependency graph, wherein the topological ordering order is the order of the transactions in the current block, and finally merging with a write-only transaction queue to finish the block operation, cleaning the transaction dependency graph, a waiting transaction queue and the write-only transaction queue, and updating the submitted transaction write set hash Map according to the write set of the transactions in the current waiting transaction queue.
In the transaction processing optimization method, any transaction possibly participating in exception is discarded in advance through dependency detection analysis, the transaction which is not possibly subjected to serialization scheduling is further discarded through reordering feasibility analysis, and finally, the transaction in the block is reordered in the block packing stage to maximize the number of the successfully submitted transactions, so that the transaction abort rate is reduced, and the performance of the HyperledgerFabric under various loads is improved.
Drawings
FIG. 1 is a schematic diagram of the dependency of read-only transaction exceptions. (a) dependency of read-only transaction anomalies in a database cache; (b) dependency of read-only transaction exceptions in FabricSharp.
FIG. 2 is a transaction dependency diagram.
FIG. 3 depicts a schematic diagram of the impact of reordering on concurrent transaction dependencies.
FIG. 4 is a flowchart of a snapshot-based Hyperledger Fabric transaction optimization method.
FIG. 5 is a graph of transaction throughput versus transaction delay for different block sizes for the present invention and other optimization methods.
FIG. 6 is a graph of transaction throughput for the present invention and other optimization methods under different loads.
Detailed Description
The following will describe the specific implementation flow of the snapshot-based Hyperledger Fabric transaction optimization method:
1. assume that the block number of the current block to be output is N (N>3) The existing waiting transaction queue has a transaction T 1 、T 2 Wherein T is 1 And T 2 In the execution stage, the execution is respectively performed on the block numbers N-2 and N-1, T 1 Read A, write B, T 2 Read B, write C, when there is a write set key pair for the committed transaction<A，N-2><B，N-1><C，N-1><D，N-1>Write-only transaction set is empty, T 1 、T 2 Both through dependency detection analysis and reordering feasibility analysis, which constitute dependency graph existence T 2 Pointing to T 1 Is marked as T 2 ->T 1 ；
2. With T 3 Executing on N-2 and allowing read B and write C to reach ordering node, performing dependency detection analysis on the read B and write C to judge the read and write transaction, detecting whether cross-block concurrent anti-rw dependency exists or not, checking read key value B to find write set mark of submitted transaction<B，N-1>Wherein the N-1 block is committed at T 3 After execution of block number N-2, T is considered 3 If an anti-rw dependency exists with a committed transaction, T is determined 3 Discarding, because such transactions may participate in read-only transaction exceptions, they must be discarded to ensure serializable scheduling of transactions, while FabricSharp may commit such transactions causing exceptions to occur;
3. suppose there is T followed by 4 Executing on N-1, reading C and writing A, judging read-write transaction in dependency detection, checking read key value C to find write set mark of committed transaction<C，N-1>Equal to the analog block number, and no any dependence of any-rw between the cross-block concurrent transactions exists, then enter a reordering feasibility analysis stage, and further enter T 4 The relevant c-rw dependency is added to the dependency graph, i.e. T is added 4 ->T 2 And T is 1 ->T 4 Two sides are used for accessibility detection immediately, T is used for 4 A round of depth-first search is performed as a starting point to find the existence of T 4 ->T 2 ->T 1 ->T 4 Is of ring structure T 4 Unable to reorder to serialize scheduling, T will be 4 Discard and clear T from dependency graph 4 Related nodes and edges;
4. suppose there is T followed by 5 Executing on N-1, writing in A, judging that the dependence detection is a write-only transaction, and putting the write-only transaction into a write-only transaction set;
5. suppose there is T followed by 6 Executing on N-1, reading D and writing A, judging read-write transaction in dependency detection, checking read key value D to find write set mark of committed transaction<D，N-1>Equal to the execution block number, and no any dependence of any-re-w among the concurrent transactions of the cross-block exists, then enter a reordering feasibility analysis stage, and further enter T 6 The relevant c-rw dependency is added to the dependency graph, i.e. T is added 1 ->T 6 One side is immediately subjected to accessibility detection by T 6 Performing a round of depth-first search for starting point, without finding any ring structure, and performing T 6 And adding into a waiting queue.
At the moment, triggering the HyperLedgerFabric packing block condition to carry out block packing, firstly carrying out topological ordering on the transactions in the dependency graph, and at the moment, the T exists in the dependency graph 2 ->T 1 ->T 6 Is that there is topological ordering T 2 、T 1 And T is 6 T in the set of write-only transactions will then be written 5 Put at the end, i.e. the commit order of the transactions in the block at this time is T 2 、T 1 、T 6 And T is 5 Simultaneously updating write set key pairs of committed transactions to<A，N><B，N><C，N><D，N-1>And clearing the dependency graph, waiting for the transaction queue and the write-only transaction set, and sending the packaged block to the peer node.
Through the above simulation, for read-write transactions, the present invention discards transactions that are likely to participate in read-only transaction exceptions during the dependency detection phase,such as T 3 Discarding transactions that cannot be serialized in a reorder feasibility analysis, e.g. T 4 Finally, transaction reordering is carried out by means of topology ordering in a block packing stage; for write-only transactions, simple collection is performed and placed at the end of the block during the block packing phase. In experiments with different block sizes and different loads, the present invention also achieves better results, as shown in fig. 5 and 6, wherein Fabric-SSI is the system name of the present invention after being implemented in Hyperledger Fabric.
According to the method, a transaction serializable scheduling strategy and a transaction optimizing method based on snapshot are provided for the HyperLedgerFabric based on the EOV framework, and a reordering method is adopted, so that the dependence of anti-rw among concurrent transactions is strictly forbidden, the transaction aborting rate of the transaction serializable scheduling is reduced as much as possible, and compared with the prior HyperledgerFabric, fabric ++ and FabricSharp, the transaction throughput is improved by more than 10% and the average transaction delay is lower.
Reference to the literature
[1]Nakamoto S. Bitcoin: A Peer-to-Peer Electronic Cash System.2008.
[2]Androulaki E, Barger A, Bortnikov V, et al. Hyperledger fabric: a distributed
operating system for permissioned blockchains. Proceedings of the Thirteenth EuroSys Conference. ACM, 2018: 30:1-30:15.
[3]Sharma A, Schuhknecht F M, Agrawal D, et al. Blurring the Lines between Blockchains and Database Systems: the Case of Hyperledger Fabric.Proceedings of the 2019 International Conference on Management of Data,SIGMOD Conference 2019. ACM, 2019: 105-122.
[4]Ruan P, Loghin D, Ta Q, et al. A Transactional Perspective on Execute-order-validate Blockchains. Proceedings of the 2020 International Conference on Management of Data, SIGMOD Conference 2020. ACM, 2020: 543-557.
[5]Fekete A D, Liarokapis D, O’Neil E J, et al. Making snapshot isolationserializable. ACM Trans. Database Syst.2005, 30(2): 492-528.。
Claims (4)
1. A snapshot-based distributed ledger platform transaction optimization method is characterized by comprising the following steps:
(1) First, transactions in a blockchain system are subdivided:
according to the characteristics of the transactions in the block chain system based on the execution-ordering-verification EOV framework, namely, the transactions have different life cycles in the execution-ordering-verification EOV framework due to different read-write sets, the types, concurrency types and inter-transaction dependency relations of the transactions are refined, and the transactions in the execution-ordering-verification EOV framework are classified according to the read-write sets of the transactions: the method comprises the steps of dividing read-only transactions which only act on an execution stage, and write-only transactions and read-write transactions which penetrate through an execution-sequencing-verification EOV framework; defining a series of concurrent types, types and inter-transaction dependency relations for the subdivided transactions in the execution-sequencing-verification EOV framework, and perfecting the concurrent transaction classification of the blockchain system suitable for the execution-sequencing-verification EOV framework; specifically, defining concurrent transactions as transactions with the existence time overlapped with a read-write set, and defining concurrent read-write c-rw dependence, concurrent anti-read-write anti-rw dependence and concurrent write c-ww dependence existing among the concurrent transactions;
(2) Second, a transaction serializable scheduling policy in the blockchain system is determined:
according to the characteristics of the transactions in the distributed ledger platform, a new serializable scheduling strategy is provided, namely, the serializable scheduling of the transactions in the distributed ledger platform is ensured by avoiding the occurrence of a ring structure of a dependency graph formed by the concurrent anti-read-write anti-rw dependency relationship among the cross-block concurrent transactions and the concurrent transactions in the blocks, and the concurrent anti-read-write anti-rw dependency among all the concurrent transactions is forbidden;
(3) Then, the transactions in the blockchain system are reordered:
reordering is to change the original sequence of transactions in a block when an ordering node packs the block, and the serializable transaction scheduling is completed by strictly prohibiting the concurrent anti-read-write anti-rw dependence of the concurrent transactions in the block, and reducing the abort rate of the transactions in the process by means of reordering:
for the write-only transactions, the write-only transactions are not considered in the subsequent reordering link, and only when the blocks are packed out finally, the write-only transactions are placed at the last position in the block;
for a read-write transaction, if a loop formed by the concurrent anti-read-write anti-rw dependence and the concurrent read-write c-rw dependence does not exist in the concurrent transaction in the block, converting the concurrent anti-read-write anti-rw dependence into the concurrent read-write c-rw dependence through reordering, so that serialization scheduling of the transaction is achieved; if the concurrent transaction in the block has a loop formed by concurrent anti-read-write anti-rw dependence and concurrent read-write c-rw dependence, discarding the transaction in the loop; when the packing out condition is triggered, reordering the transactions in the block according to the topological ordering, and packing out the block;
(4) Finally, the transaction processing of the distributed ledger platform based on the snapshot is realized on the distributed ledger platform.
2. The optimization method of claim 1, wherein in reordering transactions in a blockchain system, dependency detection analysis is performed: when a new transaction arrives at the ordering node, dividing the new transaction into a write-only transaction and a read-write transaction according to whether the transaction has a read set or not; for a write-only transaction, simply putting the write-only transaction into a write-only transaction queue without carrying out concurrent anti-read-write anti-rw dependency detection of a cross-block concurrent transaction; for a read-write transaction, judging whether the transaction has cross-block concurrent anti-read-write anti-rw dependence with the transaction in the previous block, discarding the transaction if the cross-block concurrent anti-read-write anti-rw dependence exists, and entering the next flow if the cross-block concurrent anti-read-write anti-rw dependence does not exist;
and judging whether the transaction is concurrent anti-read-write anti-rw dependent with the transaction in the previous block, wherein the judgment is to record a write set and a latest submitted block number of all submitted blocks by using a hash Map, and when the snapshot number read by a key of the current transaction write set is smaller than the submitted block number of a corresponding key in the Map, considering that the current transaction and a certain cross-block concurrent transaction are concurrent anti-read-write anti-rw dependent.
3. The optimization method of claim 1, wherein in reordering transactions in a blockchain system, a reordering feasibility analysis is performed: after the read-write transaction is checked through the dependency detection analysis, only the concurrent read-write c-rw dependency of the transaction and the concurrent transaction in other blocks is calculated, because the transaction which can be scheduled in a serialization way can only be submitted in the concurrent read-write c-rw dependency, any concurrent anti-read-write anti-rw dependency needs to be reordered to be converted into the concurrent read-write c-rw dependency; if a ring with concurrent read-write c-rw dependence appears, the fact that the transactions in the ring cannot all finish the submission of the transactions with the concurrent read-write c-rw dependence means that the transactions in the ring need to be deleted to maintain the acyclic attribute of the dependency graph; if no concurrent read-write c-rw dependent ring appears, the transaction can be subjected to serialization scheduling, and added into a transaction set waiting for a block;
specifically, whether the read-write transaction can be submitted through reordering is detected by maintaining a concurrent read-write c-rw dependency graph G of a concurrent transaction in one block, and if the read-write transaction can be submitted through reordering, the read-write transaction is added into a waiting transaction queue to wait for packing out the block; the detection relies on a depth-first-based searching method, when a new transaction and a dependency relationship thereof are added into a dependency graph, a round of depth-first searching is carried out by taking the new transaction as a starting point, if other transactions are directed in the traversing process, serializable scheduling can be completed by keeping loop-free in the dependency graph G so as to ensure that all transactions in the graph G, and the concurrent anti-read-write anti-rw dependency is not allowed to exist among the concurrent transactions, so that the concurrent anti-read-write anti-rw dependency among any concurrent transactions in the block is converted into the concurrent read-write c-rw dependency through reordering; if the loop of the concurrent read-write c-rw dependency exists in G, the fact that the transaction cannot be submitted in the concurrent read-write c-rw dependency is inevitable in the loop is meant, and the transaction in the loop is discarded, so that the transaction in G can be scheduled in a serialization mode.
4. The optimization method of claim 1, wherein in reordering transactions in a blockchain system, when a block-out condition is touched, the blocks are packed, i.e., topology ordering is performed on an existing loop-free transaction dependency graph, the order of the topology ordering is the order of the transactions in the current block, and finally the topology ordering is combined with a write-only transaction queue to complete a block-out operation, and the transaction dependency graph, the transaction queue and the write-only transaction queue are cleaned, and a committed transaction write set hash Map is updated according to a write set of transactions in the current transaction queue.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110915260.1A CN113835847B (en) | 2021-08-10 | 2021-08-10 | Transaction processing optimization method of distributed account book platform based on snapshot |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110915260.1A CN113835847B (en) | 2021-08-10 | 2021-08-10 | Transaction processing optimization method of distributed account book platform based on snapshot |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113835847A CN113835847A (en) | 2021-12-24 |
| CN113835847B true CN113835847B (en) | 2023-11-24 |
Family
ID=78963206
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110915260.1A Active CN113835847B (en) | 2021-08-10 | 2021-08-10 | Transaction processing optimization method of distributed account book platform based on snapshot |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113835847B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116501801B (en) * | 2023-05-11 | 2023-10-13 | 天津大学 | High-performance transaction asynchronous concurrent processing method for license-oriented blockchain |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109710695A (en) * | 2018-12-26 | 2019-05-03 | 百度在线网络技术（北京）有限公司 | The identification of transactions requests validity and initiating method, device, equipment and medium |
| WO2020016637A1 (en) * | 2018-07-20 | 2020-01-23 | Valencia Renato | Blockchain-enabled double entry recordkeeping system and method of implementing the same |
| CN112861980A (en) * | 2021-02-21 | 2021-05-28 | 平安科技（深圳）有限公司 | Calendar task table mining method based on big data and computer equipment |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014008495A2 (en) * | 2012-07-06 | 2014-01-09 | Cornell University | Managing dependencies between operations in a distributed system |
-
2021
- 2021-08-10 CN CN202110915260.1A patent/CN113835847B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020016637A1 (en) * | 2018-07-20 | 2020-01-23 | Valencia Renato | Blockchain-enabled double entry recordkeeping system and method of implementing the same |
| CN109710695A (en) * | 2018-12-26 | 2019-05-03 | 百度在线网络技术（北京）有限公司 | The identification of transactions requests validity and initiating method, device, equipment and medium |
| CN112861980A (en) * | 2021-02-21 | 2021-05-28 | 平安科技（深圳）有限公司 | Calendar task table mining method based on big data and computer equipment |
Non-Patent Citations (2)
| Title |
|---|
| 基于区块链技术保护个人数据;刘文杰;刘保汛;刘亚军;;科技资讯(第09期);全文 * |
| 大数据的若干基础研究方向;朱扬勇;熊;;大数据(第02期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113835847A (en) | 2021-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4261609B1 (en) | Database transaction processing system using multi-operation processing with transaction concurrency control | |
| CN106030533B (en) | It is executed by split process and retries affairs automatically | |
| US8352425B2 (en) | Parallel apply processing in data replication with preservation of transaction integrity and source ordering of dependent updates | |
| EP0457473B1 (en) | Method for accessing shared data | |
| US7386577B2 (en) | Dynamic determination of transaction boundaries in workflow systems | |
| US7702741B2 (en) | Configuring or reconfiguring a multi-master information sharing environment | |
| US8560500B2 (en) | Method and system for removing rows from directory tables | |
| US20050192989A1 (en) | Techniques to preserve data constraints and referential integrity in asynchronous transactional replication of relational tables | |
| CN112837153A (en) | Intelligent contract conflict detection method based on directed acyclic graph | |
| CN112559626B (en) | Synchronous method and synchronous system of DDL operation based on log analysis | |
| Romano et al. | On speculative replication of transactional systems | |
| CN113835847B (en) | Transaction processing optimization method of distributed account book platform based on snapshot | |
| Wongkham et al. | Are updatable learned indexes ready? | |
| Chen et al. | PEEP: A parallel execution engine for permissioned blockchain systems | |
| JP5108252B2 (en) | Index updating method and system | |
| CN111949673B (en) | Hbase storage-based distributed pessimistic lock and implementation method thereof | |
| Alistarh et al. | Inherent limitations of hybrid transactional memory | |
| Peri et al. | Efficient means of Achieving Composability using Object based Conflicts on Transactional Memory | |
| Qi et al. | Smart contract parallel execution with fine-grained state accesses | |
| CN106294626B (en) | A kind of method that parallel playback file system is redo log | |
| Peri et al. | An efficient scheduler for closed nested transactions that satisfies all-reads-consistency and non-interference | |
| Ma et al. | Key-Based Transaction Reordering: An Optimized Approach for Concurrency Control in Hyperledger Fabric | |
| Shioi et al. | Read-safe snapshots: An abort/wait-free serializable read method for read-only transactions on mixed OLTP/OLAP workloads | |
| Diegues et al. | Input Acceptance of Time-Warping Transactional Memory | |
| Lam et al. | On consistent reading of entire databases |
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 |