CN114331440A - Conflict detection and performance optimization method and device - Google Patents
Conflict detection and performance optimization method and device Download PDFInfo
- Publication number
- CN114331440A CN114331440A CN202111681067.2A CN202111681067A CN114331440A CN 114331440 A CN114331440 A CN 114331440A CN 202111681067 A CN202111681067 A CN 202111681067A CN 114331440 A CN114331440 A CN 114331440A
- Authority
- CN
- China
- Prior art keywords
- transaction
- conflict
- write
- verification
- endorsement
- 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.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention provides a method and a device for conflict detection and performance optimization. The invention provides a three-stage transaction conflict detection mechanism based on a block chain and a conflict early termination mechanism, and effectively solves the problems that the existing block chain framework has conflicts in the transactions of reading and writing the same data within a certain time period, the validity verification of the transactions is too late, the overall performance loss is large, and the like. The invention optimizes the transaction conflict detection mechanism based on HyperLegendric Fabric, and can effectively reduce the server performance loss of the Fabric system, reduce the average delay of system transaction and increase the maximum throughput of the system.
Description
Technical Field
The application relates to the technical field of alliance chain transaction conflict detection, in particular to a conflict detection and performance optimization method and device.
Background
The alliance chain is a decentralized network formed by distributed nodes, the positions of all the nodes in the chain network are equal, and user transactions can be processed and the accounts in the blockchain system can be updated. Therefore, in a federation chain network, it often happens that different nodes rewrite the same copy of data at the same time, which can cause transactions to collide with each other and can reduce the data processing capacity of the federation chain. Among many alliance chain frameworks, Hyperledger Fabric is currently the most widely used alliance chain framework with the most floor projects. However, the existing architecture design of the HyperLegend Fabric system mainly has the following two problems:
(1) when a transaction conflict occurs, the transaction may be rendered invalid. In the Fabric transaction process, the endorsement operation is firstly completed at the endorsement node, namely the endorsement operation is performed according to the chain code, the operation of the chain code and the parameters specified in the transaction proposal, and the simulation execution transaction operation is performed based on the current state database in the peer node. Because it is only a simulation, this process does not write changes to the ledger, does not change the state of the current state database, but only generates a read set and a write set. The read set records the key and the version number thereof required to be read during transaction simulation execution, and the write set records the information such as the modified key and the corresponding value thereof during transaction simulation execution. If one transaction completes the operation of simulation execution on the endorsement node but does not complete the final transaction verification process, the second transaction is sent to the endorsement node for simulation execution under the condition of large concurrency, and the read-write data is the same as the first transaction, then the keys contained in the read sets of the two transactions are the same, the versions of the keys are the same, and the keys contained in the write sets are also the same. At this point, no problem has arisen with the execution of both transactions. However, when the first transaction is finally sent to the verification node to complete the verification operation, and after the confirmation is valid transaction and is written into the account book, the second transaction is also sent to the verification node to perform the verification operation, it cannot pass the read-write set conflict check. After the verification operation is completed, the key-value pair in the write set of the first transaction is updated into the state database, and when the read-write set conflict check is performed on the second transaction, the version number corresponding to the key in the read set of the second transaction is found to be inconsistent with that in the state database, so that the second transaction cannot be verified through the MVCC, and is marked as an invalid transaction. Therefore, if two continuous transactions are performed under the condition of high concurrency, the same data is easy to read and write, so that conflict is generated, and finally, the transaction submitted later is judged to be invalid;
(2) HyperLegger Fabric transaction verification has some hysteresis, and transaction verification hysteresis can have an effect on the overall performance of the system. According to the blockchain transaction mechanism, the blockchain system is different from a completely trusted database system, and the access to the system data cannot be directly written into the ledger, so that a verification process is necessary. In the HyperLegend framework, the system integrates the transaction verification function into the verification nodes, so that the transaction verification is completed in the verification stage, but the problem of transaction verification hysteresis is also caused. As can be seen from the Fabric system transaction running process, the verification process of the transaction is in the last step of the process, but the verification operation for partial transactions, such as the verification of conflict transactions, does not need to be completed in the last step, which can be completed as early as possible. If the verification operations can be completed in the endorsement stage or the sorting stage, invalid transactions are processed in advance according to the verification result, and the 2/3 operation flow of the invalid transactions can be reduced theoretically, so that the system performance loss of 2/3 is reduced, and the delay of the transactions close to 2/3 is further reduced. Thus, the hysteresis of transaction verification can also be seen as a loss of system performance by partially invalidating transactions.
During the period that one transaction completes the endorsement process but does not complete the verification process, if another transaction is sent to the network and the read-write data is the same as the first transaction, the two transactions are conflicted, so that the first transaction may be in one of a plurality of intermediate processes, for example, a communication process from the endorsement node to the client, a process that the client collects the endorsement result, a communication process from the client to the sequencing node, a process that the sequencing node is sequenced and packaged to form a block, a communication process from the sequencing node to the verification node, and the like. Overall, these intermediate processes fall into two main categories: communication processes between nodes and processing processes on nodes. The communication process between the nodes is mainly influenced by the performance of a system underlying network, including the bandwidth and the network delay of network communication; the processing process on the node is mainly influenced by the performance of the node, including the performance of hardware facilities such as a node CPU, a memory, a storage and the like. Therefore, the more concurrency a transaction is sent at a certain rate, and the greater the number of transactions that collide with the transaction at a certain collision rate, the greater the loss of performance of the system, which is mainly caused by the hysteresis of the transaction verification process. The defects are all technical problems which need to be solved urgently.
Disclosure of Invention
In order to solve the above technical problem, the present invention provides a method for verifying the correctness of a block state transition without synchronizing block data and a global state. The invention is mainly used for solving the performance problem caused by transaction conflict in the alliance chain system. The three-stage transaction conflict detection and early termination mechanism provided by the invention can effectively reduce the resource loss in the alliance chain system and increase the throughput of the alliance chain system, thereby improving the transaction performance of the whole alliance chain. The technical scheme adopted by the invention is as follows:
a conflict detection and performance optimization method comprises the following steps: step 1, simulating and executing transaction at an endorsement node to obtain a read-write set, detecting transaction conflict according to write set write-set cache established by the read-write set, returning an endorsement result of effective transaction to a client if the transaction conflict is not detected, and sending the formed transaction to a sequencing node; step 2, the sequencing node establishes a write set cache for the read-write set of the transaction in the same block, detects the transaction conflict in the block and informs the client of the detection result; if the transactions in the block have passed the conflict detection, generating the block and broadcasting the generated block to the verification node; and 3, the verification node performs endorsement policy verification and read-write set conflict check on the transactions in the block one by one and notifies the verification result to the client.
Further, before the endorsement node simulates to execute the transaction in the step 1, the method further comprises the step 0: the client sends the transaction proposal to the designated endorsement node.
Further, step 1 further comprises: if the transaction conflict is detected, the conflict information is returned to the client, and the client starts a corresponding transaction processing mechanism to deal with the transaction conflict.
Further, the write set write-set cache established from the read-write set to detect transaction conflicts in step 1 comprises the following sub-steps: step 101, creating a cache of key in a write set for the transaction which is sent to the same endorsement node for simulation execution; and 102, after the simulation execution of each transaction is finished, matching keys in the data read set of the transaction with keys in the cache of the write set, and judging transaction conflict according to the matching result.
Further, the determining of the transaction conflict according to the matching result in step 102 includes: if a key already exists in the write set cache, indicating that there is a transaction to read and write the same data, the currently completed transaction to be simulated may conflict with the previous transaction.
Further, the detecting the transaction conflict in the block in step 2 includes: and judging whether intersection exists between the read-set cache and the write-set cache of the transaction in the later sequence, if so, determining that the transaction conflict occurs, and regarding the transaction as an invalid transaction.
Further, the step 2 of notifying the client of the detection result includes: and informing the client that the conflict exists in the corresponding transaction, and emptying the corresponding data in the write-set cache of the endorsement node for the invalid transaction detected in the sorting stage so as to completely end the transaction flow.
Further, step 2 further comprises: after the block is generated, the write set write-set cache is emptied, and is reestablished when the next block is created.
Further, the step of notifying the client of the verification result in step 3 includes: if the transaction passes the verification, returning the transaction which is successful; if the transaction is not verified, returning the transaction which fails; the endorsement policy verification in the step 3 comprises: after the transaction is verified on the verification node with endorsement node functionality, the data in the write set cache is purged.
A collision detection and performance optimization apparatus, the apparatus comprising a memory and a processor, wherein: the memory stores one or more programs; the one or more programs, when executed by the processor, cause the processor to implement the above-described method.
Through the embodiment of the application, the following technical effects can be obtained: the invention provides a three-stage transaction conflict detection mechanism based on a block chain and a conflict early termination mechanism, and effectively solves the problems that the existing block chain framework has conflicts in the transactions of reading and writing the same data within a certain time period, the validity verification of the transactions is too late, the overall performance loss is large, and the like. The invention optimizes the transaction conflict detection mechanism based on HyperLegendr Fabric, and can effectively reduce the server performance loss of the Fabric system, reduce the average delay of system transaction and increase the maximum throughput of the system.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and those skilled in the art can also obtain other drawings according to the drawings without inventive labor.
FIG. 1 is a block chain architecture diagram of the prior art;
FIG. 2 is a schematic diagram of a HyperLegger Fabric architecture;
FIG. 3 is a schematic diagram of the overall transaction flow of Hyperhedger Fabric.
FIG. 4 is a schematic diagram of a detection process of three stages, namely, an endorsement stage, a sorting stage and a verification submission stage;
FIG. 5 is a schematic diagram illustrating the interaction flow in the HyperLegger Fabric framework;
FIG. 6 is a schematic diagram of a collision detection process for a sequencing node;
fig. 7 is a schematic diagram illustrating an interaction flow of the authentication node module.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
FIG. 1 is a block chain architecture diagram of the prior art. The current block chain architecture is basically divided into five levels, which are: a data layer, a network layer, a consensus layer, a contract layer, and an application layer. Fig. 2 is a schematic diagram of a Hyperhedger Fabric architecture, and for the problem of system performance degradation caused by transaction verification hysteresis in the conventional Hyperhedger Fabric system architecture, especially the problem of transaction conflict, the core principle of the technical scheme of the present invention is as follows:
(1) the method comprises the steps of advancing a partial verification process of a HyperLegger Fabric system on a transaction, performing read-write set conflict check on the transaction as early as possible, and finding conflict transaction in advance;
(2) through three-stage transaction conflict detection, transaction conflicts are sensed in advance, and then conflict transactions are terminated and the client side is notified.
The transaction operation flow of the HyperLegger Fabric comprises a plurality of stages which are generally divided into three stages: endorsement phase, sorting phase, verification submission. For the conflict of the transaction, the solution idea of the invention is to advance the verification operation of the transaction to the endorsement stage and the execution stage, thereby adding the operation of transaction conflict detection in each stage and realizing a three-stage transaction conflict detection mechanism.
Fig. 3 is a schematic diagram of the overall transaction flow of the hyper folder Fabric, and fig. 4 is a schematic diagram of the detection flow of the endorsement stage, the sorting stage, and the verification submission stage, which will be described separately below.
before the endorsement node simulates to execute the transaction, the method further comprises the following steps: the client sends a transaction proposal to a designated endorsement node;
the method also comprises the following steps in the step 1: if the transaction conflict is detected, the conflict information is returned to the client, and the client starts a corresponding transaction processing mechanism to deal with the transaction conflict;
in the HyperLegend Fabric transaction process, all transactions need to be sent to endorsement nodes for sorting and packaging to form blocks, so that the conflict of the transactions is detected in the sorting stage, and the performance of a block chain system can be effectively improved.
Detecting a transaction conflict according to a write set write-set cache established by the read-write set, specifically comprising:
step 101, creating a cache of key in a write set for the transaction which is sent to the same endorsement node for simulation execution;
102, after the simulation execution of each transaction is completed, matching keys in a data reading set of the transaction with keys in a cache of a writing set, and judging transaction conflict according to a matching result;
the determining of the transaction conflict according to the matching result specifically includes: if the key exists in the write set cache, the transaction of reading and writing the same data exists, and the currently completed transaction of the simulation execution conflicts with the previous transaction;
transaction conflict detection in the endorsement stage can only detect transactions sent to the same endorsement node to be executed in a simulated manner. The selection of the endorsement node for simulating the transaction is related to the setting of the endorsement strategy of the chain code, and the transaction may require the endorsement of all the endorsement nodes or only part of the endorsement nodes. When the transaction requires endorsement by all endorsement nodes, all endorsement nodes can perform simulation execution on the transaction, so all conflicts of the transaction due to reading and writing the same data can be detected. However, if the transaction only needs to be endorsed by a partial endorsement node, different transactions may be sent to different endorsement nodes for endorsement, because the write set caches between the nodes are isolated, the cross-node conflicts cannot be detected, and the conflicts will be detected at a later stage.
The operation performed on the endorsement node is simulation execution, and the result of the simulation execution of the transaction is not necessarily written into the ledger, so the transaction proposal is called.
The contents carried in the transaction proposal are as follows: the name of the chain code, the version of the chain code, the execution parameter of the chain code and the like, and the endorsement node calls the corresponding chain code according to the information, wherein the chain code is deployed in an independent docker container and is isolated from the endorsement node. The results obtained after the simulation of the transaction proposal are executed include the read-write set of the transaction, including read-set and write-set. The conflict detection module is realized based on a read-write set, establishes a write set cache according to the write set, searches in the write set cache according to a key in the transaction read set when detecting a transaction conflict, and if the key exists in the write set cache, indicates that the transaction conflicts with a transaction being executed in the current process; if none of the keys in the transaction write set are present in the write set cache, it means that the transaction must not conflict with previously submitted transactions.
When the conflict of the transaction is detected, the transaction is terminated in advance, the endorsement result is not returned, and the transaction with invalid transaction content is sent to the client. And after the verification process of the transaction in the endorsement stage, adding the write set of the transaction into a write set cache to finish the updating operation.
detecting a transaction conflict in the block, specifically comprising: judging whether intersection exists between read-set cache and write-set cache of the transaction in the later sequence, if so, determining that the transaction conflicts appear, and regarding the transaction as invalid;
notifying the client of the detection result specifically includes: informing the client that the corresponding transaction has conflict, and emptying corresponding data in the write-set cache of the endorsement node for the invalid transaction detected in the sorting stage so as to completely end the transaction flow;
after notifying the client of the detection result, the method further includes: if the transactions in the block pass the conflict detection, generating the block, emptying the write set write-set cache, reestablishing the write set write-set cache when the next block is created, and broadcasting the generated block to the verification node;
the conflict detection in the sorting stage mainly aims at conflicts which are not detected in the endorsement stage, namely conflicts among the cross endorsement nodes. The method specifically comprises the steps of establishing a read-set cache and a write-set cache respectively aiming at read-set and write-set read-set of transactions in the same block, and judging whether intersection exists between the read-set cache and the write-set cache of the transactions added into the block later. In fact, multiple transactions in the same block are all in the ordering stage, that is, the intermediate process between the endorsement stage and the verification stage, and these transactions may be executed based on the same state simulation of the ledger or may be executed based on different states of the ledger, but in any case, as long as there is an intersection between the read set and the write set cache of the transaction in the later order, that is, there is the same data read and written by the transaction, the transaction in the earlier order in the block in the verification stage will inevitably modify the current state of the ledger of the transaction in the later order, so that the transaction in the later order cannot be verified by MVCC. Transaction conflicts can therefore be detected in the ordering phase according to the write-set cache implementation.
FIG. 5 is a schematic diagram illustrating an interaction flow in the HyperLegger Fabric framework. It should be noted that the invalid transaction detected at this stage needs to clear the corresponding data of the transaction in the write set cache of the endorsement node, so as to ensure that the transaction completely ends the transaction flow in the system. Finally, after all transactions in a block pass conflict detection and create a block, the write-set cache needs to be emptied and re-established at the creation of the next block.
Step 3, the verification node performs endorsement policy verification and read-write set conflict check on the transactions in the block one by one, and notifies the verification result to the client;
notifying the client of the verification result specifically includes: if the transaction passes the verification, returning the transaction which is successful; if the transaction is not verified, a transaction that failed the transaction is returned.
The performing endorsement policy validation further comprises: after the transaction is verified on the verification node with endorsement node functionality, the data in the write set cache is purged.
In the HyperLegendr Fabric transaction process, the last step of transaction verification in the verification stage is that if the transaction passes the verification in the verification stage, the transaction is valid and can be normally written into the blockchain ledger. Transaction verification in the verification stage includes endorsement policy verification and read-write set conflict detection.
In the three-stage conflict detection scheme proposed by the system, the functions of the part are kept unchanged, but the function matched with the conflict detection in the endorsement stage needs to be added. Since transaction conflicts within the endorsement node are achieved by using a write set write-set cache on the endorsement node during the endorsement phase, until now, a cache has been added to the write set write-set cache, so that the more transactions, the larger the cache is, and the higher the probability that subsequent transactions will conflict with data in the write set write-set cache, which is unreasonable, so that a point in time must be determined to delete data buffered in the write set cache for a transaction. The time point is that after the transaction is finished and the verification operation is finished, whether the transaction is valid or not, the data recorded in the write set cache of the transaction needs to be emptied according to the write set of the transaction. Since all endorsement nodes are also verification nodes, the above write-set cache update operation can be completed when the transaction is verified on the endorsement node.
After the verification node receives the block, the transaction needs to be analyzed from the block, and the two verification processes of endorsement policy verification and read-write set conflict check are performed on the transaction one by one, and meanwhile, the key value cached in the write set cache of the transaction is cleared. And finally, returning the result event of the transaction execution to the client. Fig. 6 is a schematic diagram of a conflict detection flow of a sequencing node, and fig. 7 is a schematic diagram of an interaction flow of a verification node module.
The three-phase transaction conflict detection and early termination mechanism realizes optimization improvement based on the existing HyperLegger Fabric system. Therefore, recompilation implementation of the components of the Fabric system is required to integrate the transaction conflict detection mechanism with the Fabric system. Therefore, there is a need to install Go language, Docker container, Docker-composition tool, and other necessary environmental dependencies. And then, placing the Fabric source code integrated with the conflict detection mechanism under an src folder of a Go language root directory, and compiling according to a Make file in the Fabric source code. The components that are mainly needed to compile Fabric are: and the peer and orderer executable files respectively generate Docker container mirror images according to the executable files. The execute make peer command compiles the peer executable. The make orderer command is executed to compile an orderer executable file. Executing a make peer-docker command and a make order-docker command to respectively generate a peer mirror image and an order mirror image, calling a docker images command to check a docker container mirror image in the system, and verifying whether related system files are normally compiled.
Through the collision detection of the three stages, the invention realizes the function of a three-stage transaction collision detection mechanism. The conflict can be sensed in the endorsement stage or the sorting stage, and then the conflict transaction can be processed in advance, so that the loss of the invalid transaction to the system performance is greatly reduced, the performance burden to the sorting node and the verification node, the network communication bandwidth burden and the like are reduced, and the concurrent load capacity of the block chain system is improved. In addition, the response time of invalid transactions can be shortened by terminating the transactions in advance, so that the client can sense the invalid transactions as soon as possible and take corresponding processing measures as soon as possible, and unnecessary loss is reduced. After the HyperLegger Fabric system integrated transaction conflict detection mechanism is completed, the performance is obviously improved by comparing the three aspects of the server resource usage amount, the transaction delay and the throughput with the Fabric system before optimization.
(1) Server resource usage comparison
In the case of no conflict, the optimized Fabric system integrates a transaction conflict detection mechanism, which may bring some extra overhead to the system. However, when the collision rate increases to 20% and 40%, the total resource usage of the Fabric network is optimized, and the optimized gain ratio is 9.56% and 14.14%, respectively. Therefore, the transaction conflict detection mechanism of the system can effectively reduce the system performance loss under the scene of higher transaction conflict rate. The specific comparison results are shown in the following table:
(2) transaction latency comparison
Under the condition of conflict-free transaction of the system, the delay of the optimized HyperLegend Fabric system is increased by 1.88%, and when the transaction conflict in the system reaches 20% and 40%, the optimized Fabric system can respectively reduce the average transaction delay of the system by 8.88% and 21.22%, because the three-stage transaction conflict detection and early termination mechanism can carry out conflict detection in multiple stages of transaction execution, can terminate conflict transaction in advance, and inform the client, so that the conflict transaction can obtain results more quickly, and the average transaction delay of the system is reduced.
(3) Throughput comparison
Under the condition of low transaction sending rate, the throughputs of HyperLegend Fabric systems before and after optimization are not greatly different, but when the transaction sending rate is gradually increased to the maximum transaction processing capacity of the system, the throughput of the Fabric system after optimization is larger than that of the system before optimization. When the collision rate is 20% and 40%, the maximum throughput of the optimized system can be improved by 7.1% and 12.8%. Therefore, under the scene of transaction conflict, the three-stage transaction conflict detection and early termination mechanism can effectively reduce the performance loss of the system and can effectively increase the maximum throughput of the Hyperhedger Fabric system.
Through the comparison, the transaction conflict detection mechanism is optimized based on HyperLegger Fabric, the server performance loss of the Fabric system can be effectively reduced, the average delay of system transaction is reduced, and the maximum throughput of the system is increased.
In some embodiments, part or all of the computer program may be loaded and/or installed onto the device via ROM. When being loaded and executed, may carry out one or more of the steps of the method described above.
The functions described above in this application may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a load programmable logic device (CPLD), and the like.
Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
Further, while operations are depicted in a particular order, this should be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Claims (10)
1. A method for collision detection and performance optimization, the method comprising the steps of:
step 1, simulating and executing transaction at an endorsement node to obtain a read-write set, detecting transaction conflict according to write set write-set cache established by the read-write set, returning an endorsement result of the transaction to a client if the transaction conflict is not detected, and sending the formed transaction to a sequencing node by the client;
step 2, the sequencing node establishes a write set cache for the read-write set of the transaction in the same block, detects the transaction conflict in the block and informs the client of the detection result; if the transactions in the block have passed the conflict detection, generating the block and broadcasting the generated block to the verification node;
and 3, the verification node performs endorsement policy verification and read-write set conflict check on the transactions in the block one by one, and notifies the verification result and the check result to the client.
2. The method of claim 1, wherein before the endorsement node simulates the execution of a transaction in step 1, further comprising the step 0 of: the client sends the transaction proposal to the designated endorsement node.
3. The method according to claim 1, further comprising, in step 1: if the transaction conflict is detected, the conflict information is returned to the client, and the client starts a corresponding transaction processing mechanism to deal with the transaction conflict.
4. The method of claim 1 wherein the step 1 of detecting a transaction conflict from a write set write-set cache established for the read-write set comprises the sub-steps of:
step 101, creating a cache of key in a write set for the transaction which is sent to the same endorsement node for simulation execution;
and 102, after the simulation execution of each transaction is finished, matching keys in the data read set of the transaction with keys in the cache of the write set, and judging transaction conflict according to the matching result.
5. The method of claim 4, wherein said determining a transaction conflict according to the matching result in step 102 comprises;
if the key in the data read set already exists in the write set cache, indicating that there is a transaction to read and write the same data, the currently completed transaction to be executed in simulation may conflict with the previous transaction.
6. The method of claim 1, wherein detecting a transaction conflict within the block in step 2 comprises:
and judging whether intersection exists between the read-set cache and the write-set cache of the transaction in the later sequence, if so, determining that the transaction conflict occurs, and regarding the transaction as an invalid transaction.
7. The method of claim 1, wherein the notifying the client of the detection result in step 2 comprises:
and informing the client that the conflict exists in the corresponding transaction, and emptying the corresponding data in the write-set cache of the endorsement node for the invalid transaction detected in the sorting stage so as to completely end the transaction flow.
8. The method of claim 1, wherein step 2 further comprises: after the block is generated, the write set write-set cache is emptied, and is reestablished when the next block is created.
9. The method of claim 1, wherein the notifying the client of the verification result in step 3 comprises: if the transaction passes the verification, returning the transaction which is successful; if the transaction is not verified, returning the transaction which fails;
the endorsement policy verification in the step 3 comprises: after the transaction is verified on the verification node with endorsement node functionality, the data in the write set cache is purged.
10. A collision detection and performance optimization apparatus, the apparatus comprising a memory and a processor, wherein: the memory stores one or more programs; the one or more programs, when executed by the processor, cause the processor to implement the method of any of claims 1-9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111681067.2A CN114331440A (en) | 2021-12-31 | 2021-12-31 | Conflict detection and performance optimization method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111681067.2A CN114331440A (en) | 2021-12-31 | 2021-12-31 | Conflict detection and performance optimization method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114331440A true CN114331440A (en) | 2022-04-12 |
Family
ID=81023782
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111681067.2A Pending CN114331440A (en) | 2021-12-31 | 2021-12-31 | Conflict detection and performance optimization method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114331440A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115794853A (en) * | 2023-02-03 | 2023-03-14 | 天翼云科技有限公司 | Method and device for updating government affair data resource catalog, electronic equipment and medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111563093A (en) * | 2020-05-15 | 2020-08-21 | 电子科技大学 | Detection and avoidance system and method for union block chain conflict transaction |
| CN112837153A (en) * | 2021-02-10 | 2021-05-25 | 北京航空航天大学 | Intelligent contract conflict detection method based on directed acyclic graph |
| CN112865979A (en) * | 2021-01-22 | 2021-05-28 | 广州大学 | Resource conflict detection method of resource public key infrastructure based on block chain |
| CN113220745A (en) * | 2021-05-19 | 2021-08-06 | 中国科学技术大学 | Transaction processing method and device based on block chain and electronic equipment |
| CN113568981A (en) * | 2021-09-24 | 2021-10-29 | 腾讯科技（深圳）有限公司 | Transaction data processing method, device, equipment and medium |
| WO2021217928A1 (en) * | 2020-04-28 | 2021-11-04 | 深圳壹账通智能科技有限公司 | Blockchain network-based resource request transaction verification method and apparatus, electronic device and computer readable storage medium |
-
2021
- 2021-12-31 CN CN202111681067.2A patent/CN114331440A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021217928A1 (en) * | 2020-04-28 | 2021-11-04 | 深圳壹账通智能科技有限公司 | Blockchain network-based resource request transaction verification method and apparatus, electronic device and computer readable storage medium |
| CN111563093A (en) * | 2020-05-15 | 2020-08-21 | 电子科技大学 | Detection and avoidance system and method for union block chain conflict transaction |
| CN112865979A (en) * | 2021-01-22 | 2021-05-28 | 广州大学 | Resource conflict detection method of resource public key infrastructure based on block chain |
| CN112837153A (en) * | 2021-02-10 | 2021-05-25 | 北京航空航天大学 | Intelligent contract conflict detection method based on directed acyclic graph |
| CN113220745A (en) * | 2021-05-19 | 2021-08-06 | 中国科学技术大学 | Transaction processing method and device based on block chain and electronic equipment |
| CN113568981A (en) * | 2021-09-24 | 2021-10-29 | 腾讯科技（深圳）有限公司 | Transaction data processing method, device, equipment and medium |
Non-Patent Citations (2)
| Title |
|---|
| 曹恢龙: "跨数据中心联盟区块链的性能测试与冲突优化研究", 《中国优秀博硕士学位论文全文数据库(硕士) 信息科技辑》 * |
| 曹恢龙: "跨数据中心联盟区块链的性能测试与冲突优化研究", 《中国优秀博硕士学位论文全文数据库(硕士) 信息科技辑》, 15 July 2020 (2020-07-15), pages 52 - 75 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115794853A (en) * | 2023-02-03 | 2023-03-14 | 天翼云科技有限公司 | Method and device for updating government affair data resource catalog, electronic equipment and medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2020192063A1 (en) | Caching-based method and system for sales locking | |
| CN110675255B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN113127212B (en) | Method and device for processing transaction in blockchain | |
| CN110648124B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN110599341A (en) | Transaction calling method and system | |
| CN111984421B (en) | Data processing method, device and storage medium | |
| CN114331440A (en) | Conflict detection and performance optimization method and device | |
| JPH08328933A (en) | File access control system for parallel processing system | |
| CN110689344B (en) | Method and apparatus for concurrently executing transactions in a blockchain | |
| CN112035222B (en) | Transaction operation merging execution method and device based on log analysis synchronization | |
| CN112559496A (en) | Distributed database transaction atomicity realization method and device | |
| US20160085782A1 (en) | Update method and updating device | |
| Sun et al. | GBCL: reduce concurrency conflicts in hyperledger fabric | |
| JP2939414B2 (en) | Database Equivalent Processor for Dual Computer | |
| CN114461336A (en) | GPU real-time migration method and device and electronic equipment | |
| US20090064141A1 (en) | Efficient utilization of transactions in computing tasks | |
| CN113835847A (en) | Distributed account book platform transaction processing optimization method based on snapshot | |
| US20230069165A1 (en) | Byzantine fault tolerant pre-preprocessing for state machine replication | |
| CN110865874B (en) | Transaction commit method and device | |
| WO2023155863A1 (en) | Methods and devices for compiler function fusion | |
| WO2024007690A1 (en) | Blockchain-based transaction processing method, apparatus and device, and computer-readable storage medium and computer program product | |
| CN112069067B (en) | Data testing method and device based on block chain and computer readable storage medium | |
| JP3492207B2 (en) | Dynamic analysis method of embedded software | |
| CN112487096A (en) | Block transaction execution method and device | |
| CN115470196A (en) | Data reading and writing method and device and electronic equipment |
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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220412 |
|
| RJ01 | Rejection of invention patent application after publication |