Blockchain-based transaction processing method, controller, storage medium, and device

Abstract

The application discloses a kind of based on blockchain transaction processing method, controller, storage medium and equipment, belong to blockchain technical field.The method includes: transaction pool module stores transaction in the form of key-value pair to transaction area, value includes transaction label and transaction data, transaction label is set to first content, indicates that transaction is not confirmed;Select a plurality of transactions that are not confirmed to form candidate block;Chain module synchronizes candidate block to proposal area, and synchronizes one confirmation block selected from the candidate block of proposal area to confirmation;Transaction pool module sets the transaction label of transaction in confirmation block to second content, indicates that transaction has been confirmed, deletes the candidate block of proposal area except confirmation block;Data in transaction area, proposal area and confirmation are synchronized by synchronization module based on CRDT.This application can decouple the coupling between synchronization module and verification module, transaction pool module and chain module, reduce the design complexity of synchronization module.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain-based transaction processing method, controller, storage medium, and device. Background Technology

[0002] The blockchain microservice architecture comprises six microservices: Crypto, Controller, Executor, Storage, Consensus, and Network. The interactions between these microservices are as follows: Figure 1 As shown in the diagram. The controller occupies a central position in the entire blockchain, receiving and processing transaction data sent by users. This processing includes persistence, synchronization, and verification of the transaction's legitimacy.

[0003] The controller comprises four modules: authentication (auth), transaction pool, chain, and synchronization. The interactions between these modules are as follows: Figure 2 As shown. The verification module checks the legality of transactions; the transaction pool module maintains unconfirmed transactions; the chain maintains confirmed and unconfirmed blocks; and the synchronization module synchronizes information between the node and other nodes. The synchronization process can include the following three types:

[0004] (1) The synchronization module sends the transactions synchronized from other nodes to the verification module. After the verification module confirms that the transaction is valid, it adds the transaction to the transaction pool. In addition, the synchronization module will synchronize the transactions received by this node to other nodes.

[0005] (2) The synchronization module sends the candidate blocks synchronized from other nodes to the chain module. The chain module adds the candidate blocks to the candidate block pool of its own node. The synchronization module then synchronizes the candidate blocks generated by its own node to other nodes.

[0006] (3) The synchronization module sends the blocks synchronized from other nodes to the chain module. The chain module resets the state of its own node based on the block so that the progress of its own node is the same as that of other nodes. In addition, the synchronization module synchronizes the blocks confirmed by its own node to other nodes.

[0007] As can be seen from the above synchronization process, the synchronization module not only needs to receive data synchronized from other nodes and synchronize the data generated by this node to other nodes, but also needs to receive data generated by the previous module of this node and send the data to the next module of this node. This results in the synchronization module being very tightly coupled with other modules, and also makes the structure of the synchronization module very complex. Summary of the Invention

[0008] This application provides a blockchain-based transaction processing method, controller, storage medium, and device to address the problem of highly complex synchronization module structures caused by tight coupling between the synchronization module and other modules within a node. The technical solution is as follows:

[0009] On the one hand, a blockchain-based transaction processing method is provided for use in a controller within a blockchain node. The controller includes a verification module, a transaction pool module, a chain module, and a synchronization module implemented based on CRDT. The method includes:

[0010] The transaction pool module stores the transactions sent by the verification module in the transaction area in the form of key-value pairs. The key is the transaction hash of the transaction, and the value includes the transaction tag and transaction data. The transaction tag is set to the first content to indicate that the transaction is an unconfirmed transaction.

[0011] The transaction pool module selects multiple unconfirmed transactions from the transaction area to form a candidate block, and sends the candidate block to the chain module.

[0012] The chain module synchronizes the candidate blocks to the proposal area, selects a confirmation block from the candidate blocks in the proposal area and synchronizes it to the confirmation area, and sends the confirmation block to the transaction pool module;

[0013] The transaction pool module sets the transaction tag of the transaction in the confirmed block to the second content to indicate that the transaction has been confirmed, and deletes all candidate blocks in the proposal area except the confirmed block;

[0014] The data in the transaction area, proposal area, and confirmation area of ​​each blockchain node are synchronized by the synchronization module based on the CRDT.

[0015] In one possible implementation, the method further includes:

[0016] The synchronization module obtains transactions sent by other blockchain nodes based on the CRDT and sends the transactions to the verification module;

[0017] The verification module verifies the transaction, and after successful verification, sends the transaction to the transaction pool module.

[0018] In one possible implementation, the method further includes:

[0019] The verification module receives transactions sent by user nodes;

[0020] The verification module verifies the transaction, and after successful verification, sends the transaction to the transaction pool module;

[0021] The synchronization module synchronizes the transaction to other blockchain nodes based on the CRDT.

[0022] In one possible implementation, the transaction pool module selects multiple unconfirmed transactions from the transaction area to form a candidate block, including:

[0023] The transaction pool module filters multiple transactions from the transaction area whose transaction tag is the first content;

[0024] The transaction pool module assembles the keys of the multiple transactions into a key list, which is used to represent candidate blocks.

[0025] In one possible implementation, deleting each candidate block in the proposal area except for the confirmed block includes:

[0026] The transaction pool module deletes the key list of each candidate block in the proposal area, except for the confirmed block.

[0027] In one possible implementation, the method further includes:

[0028] The synchronization module obtains candidate blocks sent by other blockchain nodes based on the CRDT, and sends the candidate blocks to the chain module; the chain module synchronizes the candidate blocks to the proposal area;

[0029] The synchronization module synchronizes the candidate blocks generated by the local blockchain node to other blockchain nodes based on the CRDT.

[0030] In one possible implementation, the method further includes:

[0031] When the confirmed block is a candidate block generated by a local blockchain node, the synchronization module synchronizes the confirmed block to other blockchain nodes based on the CRDT;

[0032] When the confirmed block is a candidate block generated by other blockchain nodes, the synchronization module receives the confirmed block sent by the other blockchain nodes based on the CRDT and sends the confirmed block to the chain module.

[0033] On the one hand, a controller for a blockchain node is provided, the controller including a verification module, a transaction pool module, a chain module and a synchronization module based on CRDT;

[0034] The transaction pool module is used to store the transactions sent by the verification module in the form of key-value pairs in the transaction area, wherein the key is the transaction hash of the transaction, the value includes the transaction tag and transaction data, and the transaction tag is set to the first content to indicate that the transaction is an unconfirmed transaction;

[0035] The transaction pool module is also used to select multiple unconfirmed transactions from the transaction area to form a candidate block, and send the candidate block to the chain module;

[0036] The chain module is used to synchronize the candidate blocks to the proposal area, synchronize a confirmed block selected from the candidate blocks in the proposal area to the confirmation area, and send the confirmed block to the transaction pool module.

[0037] The transaction pool module is further configured to set the transaction tag of the transaction in the confirmation block to the second content to indicate that the transaction is a confirmed transaction, and delete each candidate block in the proposal area except for the confirmation block;

[0038] The data in the transaction area, proposal area, and confirmation area of ​​each blockchain node are synchronized by the synchronization module based on the CRDT.

[0039] On the one hand, a computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium, the at least one instruction being loaded and executed by a processor to implement the blockchain-based transaction processing method as described above.

[0040] On one hand, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one instruction, the instruction being loaded and executed by the processor to implement the blockchain-based transaction processing method as described above.

[0041] The beneficial effects of the technical solutions provided in this application include at least the following:

[0042] Since the synchronization module in the controller is based on CRDT, which features multi-party collaboration, the coupling between the synchronization module and the verification module, transaction pool module and chain module can be decoupled, reducing the design complexity of the synchronization module and making the implementation of the controller simpler and more reliable. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a diagram illustrating the interaction relationships between various microservices in the microservice architecture of related technologies;

[0045] Figure 2 This is a schematic diagram illustrating the interaction relationships between various modules in the controller of the related technology;

[0046] Figure 3 This is a diagram illustrating operation synchronization in CRDT;

[0047] Figure 4 This is a structural block diagram of a controller in a blockchain node provided in one embodiment of this application;

[0048] Figure 5 This is a flowchart of a blockchain-based transaction processing method provided in one embodiment of this application. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0050] CRDT stands for Conflict-free Replicated Data Type. By restricting the interchangeability of operations, conflicts between different data copies can be automatically resolved, eventually converging to a consistent result. Because CRDT can tolerate network latency and interruptions, it is commonly used in collaborative editing, such as online documents that allow multiple users to edit simultaneously.

[0051] Please refer to Figure 3 Taking three data copies x1, x2, and x3 as an example, and performing an f operation on x1 and a g operation on x2, CRDT can perform f(x1) and g(x1) operations on x1, g(x2) and f(x2) operations on x2, and g(x3) and f(x3) operations on x3, so that the three data copies are identical after the operation.

[0052] A blockchain consists of several blockchain nodes, each of which uses... Figure 1 The microservice architecture implementation shown. Figure 4 As shown, the controller in the microservice architecture includes a verification module 410, a transaction pool module 420, a chain module 430, and a synchronization module 440 implemented based on CRDT. The storage area in the controller can be divided into a transaction area, a proposal area, and a confirmation area. The transaction area is used to store unconfirmed transactions, the proposal area is used to store candidate blocks composed of unconfirmed transactions awaiting consensus, and the confirmation area is used to store confirmed blocks obtained after consensus on the candidate blocks.

[0053] The synchronization module 440 is used to synchronize data in the transaction, proposal, and confirmation areas across various blockchain nodes using CRDT. Simply put, if the storage area in each controller is considered a data copy, the synchronization module 440 can synchronize multiple data copies based on CRDT.

[0054] The verification module 410 is used to verify the received transaction and send the transaction to the transaction pool module 420 after the verification is successful.

[0055] The transaction pool module 420 is used to store verified transactions in the transaction area, select unconfirmed transactions to generate candidate blocks and synchronize them to the proposal area.

[0056] Chain module 430 is used to synchronize the confirmed blocks selected from the proposal area to the confirmation area.

[0057] In this embodiment, the verification module 410, transaction pool module 420, and chain module 430 only need to focus on the transaction processing flow, without needing to synchronize to other blockchain nodes through the synchronization module after each pair of transactions is processed. All data synchronization operations are completed by the synchronization module 440 based on CRDT. The verification module 410, transaction pool module 420, and chain module 430 do not need to care about data synchronization, thereby decoupling the synchronization module 440 from the verification module 410, transaction pool module 420, and chain module 430 and reducing the design complexity of the synchronization module 440.

[0058] When designing a synchronization module using CRDT, to ensure that modifications from various blockchain nodes can be merged without conflict, the data structures and corresponding operations need to be redesigned to adapt to CRDT. When designing the data structure, traditional data needs to be converted into data structures defined in JSON CRDT. JSON CRDT only contains simple data structures such as ORMap, and operations between multiple data structures must guarantee atomicity; otherwise, data inconsistency can easily occur.

[0059] Based on the above requirements, we designed a key-value pair format to store transactions in the ORMap structure. The key is the transaction hash (txhash), and the value includes the transaction label (label) and transaction data (txdata). The transaction label is used to indicate whether the transaction has been confirmed.

[0060] Please refer to Figure 5 It illustrates a flowchart of a blockchain-based transaction processing method according to an embodiment of this application, which can be applied to [various applications including...]. Figure 1 The controller shown. This blockchain-based transaction processing method may include:

[0061] Step 501: The transaction pool module stores the transactions sent by the verification module in the transaction area in the form of key-value pairs. The key is the transaction hash of the transaction, and the value includes the transaction tag and transaction data. The transaction tag is set to the first content to indicate that the transaction is an unconfirmed transaction.

[0062] In this embodiment, the verification module can obtain transactions through two methods. The first method is that the verification module receives transactions sent by user nodes; the second method is that the synchronization module obtains transactions sent by other blockchain nodes based on CRDT, sends the transactions to the verification module, and the verification module receives the transactions sent by the synchronization module.

[0063] After receiving a transaction, the verification module verifies it. If the verification passes, the transaction is sent to the transaction pool module; otherwise, it is not sent to the transaction pool module. The verification module can use various methods to verify transactions, which are not specifically limited in this embodiment.

[0064] It should be noted that after the verification module sends the transaction to the transaction pool module, the synchronization module needs to synchronize the transaction to other blockchain nodes based on CRDT. The synchronization module can automatically synchronize the transaction to other blockchain nodes when certain conditions are met; the specific synchronization timing can be determined by the synchronization module itself. Since the verification module only needs to send the transaction to the transaction pool module after successful verification, and does not need to send the transaction to the synchronization module for synchronization to other blockchain nodes, the transaction synchronization is implemented by the synchronization module based on CRDT, thus achieving decoupling between the verification module and the synchronization module.

[0065] The transaction pool module receives transactions sent by the verification module and stores the transactions in key-value pairs using an ORMap structure. The ORMap structure can be defined as: ORMap{txhash->(label,txdata)}.

[0066] A transaction tag can be set to either a first content or a second content. When the transaction tag is set to the first content, it indicates that the transaction is unconfirmed; when the transaction tag is set to the second content, it indicates that the transaction is confirmed. The content of the transaction tag can take various forms. For example, if the transaction tag content is a numerical value, then the first and second content will be two different numerical values; or if the transaction tag content is a symbol, then the second and second content will be two different symbols, and so on.

[0067] Step 502: The transaction pool module selects multiple unconfirmed transactions from the transaction area to form a candidate block and sends the candidate block to the chain module.

[0068] In related technologies, once a transaction in the transaction pool is confirmed, it needs to be deleted from the pool. Therefore, the transaction pool stores only unconfirmed transactions. However, in this embodiment, to avoid conflicts caused by deleting transactions, when a transaction in the transaction area is confirmed, the transaction pool module does not delete it. Instead, it modifies the transaction tag from the first content to the second content, indicating that the transaction has changed from unconfirmed to confirmed. Therefore, the transaction area stores both unconfirmed and confirmed transactions. When filtering transactions, the transaction pool module needs to filter multiple transactions with the first content tag from the transaction area. The module then uses the keys of these multiple transactions to form a key list, which represents a candidate block. For example, with key 'k', the transaction pool module can obtain the 'k' values ​​of the filtered transactions and form a 'k_list', which represents a candidate block.

[0069] In this embodiment, after the transaction pool module generates candidate blocks, the synchronization module also needs to synchronize the candidate blocks generated by the local blockchain node to other blockchain nodes based on CRDT. The synchronization module can automatically synchronize candidate blocks to other blockchain nodes when certain conditions are met, and the specific synchronization timing can be determined by the synchronization module itself. Since the transaction pool module only needs to send the generated candidate blocks to the chain module, and does not need to send the candidate blocks to the synchronization module for synchronization to other blockchain nodes, the synchronization of candidate blocks is implemented by the synchronization module based on CRDT, which can achieve decoupling between the transaction pool module and the synchronization module.

[0070] Step 503: The chain module synchronizes the candidate blocks to the proposal area, selects a confirmed block from the candidate blocks in the proposal area and synchronizes it to the confirmation area, and sends the confirmed block to the transaction pool module.

[0071] In this embodiment, the chain module can obtain candidate blocks through two methods. The first method is that the chain module receives candidate blocks sent by the transaction pool module; the second method is that the synchronization module obtains candidate blocks sent by other blockchain nodes based on CRDT, and the chain module receives the candidate blocks sent by the synchronization module. After receiving the candidate blocks, the chain module synchronizes them to the proposal area.

[0072] The proposal area includes at least one candidate block, from which a consensus algorithm selects a candidate block as the confirmation block. The confirmation block can be a candidate block generated by a local blockchain node or a candidate block generated by other blockchain nodes.

[0073] When the confirmed block is a candidate block generated by a local blockchain node, the synchronization module synchronizes the confirmed block to other blockchain nodes based on CRDT. In this embodiment, the synchronization module can automatically synchronize the confirmed block to other blockchain nodes when certain conditions are met; the specific synchronization timing can be determined by the synchronization module itself. Since the chain module only needs to synchronize the confirmed block to the confirmation area and does not need to send the confirmed block to the synchronization module for synchronization to other blockchain nodes, the synchronization of the confirmed block is implemented by the synchronization module based on CRDT, thus achieving decoupling between the chain module and the synchronization module.

[0074] When the confirmed block is a candidate block generated by other blockchain nodes, the synchronization module receives the confirmed block sent by other blockchain nodes based on CRDT and sends the confirmed block to the chain module.

[0075] After the confirmation block is determined, the chain module can synchronize the confirmation block to the confirmation area, that is, store the confirmation block on the chain, and send the confirmation block to the transaction pool module.

[0076] Step 504: The transaction pool module sets the transaction tag of the transaction in the confirmation block to the second content to indicate that the transaction has been confirmed, and deletes all candidate blocks in the proposal area except for the confirmation block; wherein, the data in the transaction area, proposal area and confirmation area of ​​each blockchain node are synchronized by the synchronization module based on CRDT.

[0077] The transaction pool module needs to "remove" transactions from the confirmation block. Specifically, the transaction pool module sets the transaction tag of transactions in the confirmation block to the second content to indicate that the transaction has been confirmed.

[0078] The transaction pool module also needs to remove all candidate blocks from the proposal area, excluding the confirmed blocks. Specifically, the transaction pool module removes the key list of each candidate block from the proposal area, excluding the confirmed blocks. That is, the transaction pool module deletes the k_list of candidate blocks.

[0079] In summary, the blockchain-based transaction processing method provided in this application embodiment, since the synchronization module in the controller is implemented based on CRDT, and CRDT has the characteristic of multi-party collaboration, can decouple the synchronization module from the verification module, transaction pool module and chain module, reduce the design complexity of the synchronization module, and make the implementation of the controller simpler and more reliable.

[0080] Please refer to Figure 4 It shows a structural block diagram of a controller in a blockchain node provided in one embodiment of this application. The controller may include a verification module 410, a transaction pool module 420, a chain module 430, and a synchronization module 440 based on CRDT.

[0081] The transaction pool module 420 is used to store the transactions sent by the verification module 410 in the transaction area in the form of key-value pairs. The key is the transaction hash of the transaction, and the value includes the transaction tag and transaction data of the transaction. The transaction tag is set to the first content to indicate that the transaction is an unconfirmed transaction.

[0082] The transaction pool module 420 is also used to select multiple unconfirmed transactions from the transaction area to form a candidate block and send the candidate block to the chain module 430.

[0083] Chain module 430 is used to synchronize candidate blocks to the proposal area, synchronize a confirmed block selected from the candidate blocks in the proposal area to the confirmation area, and send the confirmed block to transaction pool module 420.

[0084] The transaction pool module 420 is also used to set the transaction tag of the transaction in the confirmed block to the second content to indicate that the transaction has been confirmed, and to delete each candidate block in the proposal area except for the confirmed block;

[0085] The data in the transaction area, proposal area, and confirmation area of ​​each blockchain node are synchronized by the synchronization module 440 based on CRDT.

[0086] In an optional embodiment, the synchronization module 440 is further configured to obtain transactions sent by other blockchain nodes based on CRDT and send the transactions to the verification module 410.

[0087] The verification module 410 is used to verify transactions and sends them to the transaction pool module 420 after successful verification.

[0088] In an optional embodiment, the verification module 410 is used to receive transactions sent by user nodes; verify the transactions; and send the transactions to the transaction pool module 420 after successful verification.

[0089] The synchronization module 440 is also used to synchronize transactions to other blockchain nodes based on CRDT.

[0090] In an optional embodiment, the transaction pool module 420 is further configured to:

[0091] Filter multiple transactions in the trading area whose primary tag is "Transaction Content";

[0092] The keys of multiple transactions are combined into a key list, which is used to represent candidate blocks.

[0093] In an optional embodiment, the transaction pool module 420 is further configured to delete the key list of each candidate block in the proposal area, excluding the confirmed block.

[0094] In an optional embodiment, the synchronization module 440 is further configured to obtain candidate blocks sent by other blockchain nodes based on CRDT and send the candidate blocks to the chain module 430; the chain module 430 is further configured to synchronize the candidate blocks to the proposal area.

[0095] The synchronization module 440 is also used to synchronize candidate blocks generated by the local blockchain node to other blockchain nodes based on CRDT.

[0096] In an optional embodiment, when the confirmed block is a candidate block generated by a local blockchain node, the synchronization module 440 is further configured to synchronize the confirmed block to other blockchain nodes based on CRDT.

[0097] When the confirmed block is a candidate block generated by other blockchain nodes, the synchronization module 440 is also used to receive the confirmed block sent by other blockchain nodes based on CRDT and send the confirmed block to the chain module 430.

[0098] In summary, the controller in the blockchain node provided in this application embodiment, since the synchronization module in the controller is implemented based on CRDT, and CRDT has the characteristic of multi-party collaboration, can decouple the synchronization module from the verification module, transaction pool module and chain module, reduce the design complexity of the synchronization module, and make the implementation of the controller simpler and more reliable.

[0099] One embodiment of this application provides a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to implement the blockchain-based transaction processing method described above.

[0100] One embodiment of this application provides a computer device including a processor and a memory, wherein the memory stores at least one instruction, which is loaded and executed by the processor to implement the blockchain-based transaction processing method described above.

[0101] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0102] The above description is not intended to limit the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A blockchain-based transaction processing method, characterized in that, In a controller used in a blockchain node, the controller includes a verification module, a transaction pool module, a chain module, and a synchronization module based on CRDT. The method includes: The transaction pool module stores the transactions sent by the verification module in the transaction area in the form of key-value pairs. The key is the transaction hash of the transaction, and the value includes the transaction tag and transaction data. The transaction tag is set to the first content to indicate that the transaction is an unconfirmed transaction. The transaction pool module selects multiple unconfirmed transactions from the transaction area to form a candidate block, and sends the candidate block to the chain module. The chain module synchronizes the candidate blocks to the proposal area, selects a confirmation block from the candidate blocks in the proposal area and synchronizes it to the confirmation area, and sends the confirmation block to the transaction pool module; The transaction pool module sets the transaction tag of the transaction in the confirmed block to the second content to indicate that the transaction has been confirmed, and deletes all candidate blocks in the proposal area except the confirmed block; The data in the transaction area, proposal area, and confirmation area of ​​each blockchain node are synchronized by the synchronization module based on the CRDT.

2. The blockchain-based transaction processing method according to claim 1, characterized in that, The method further includes: The synchronization module obtains transactions sent by other blockchain nodes based on the CRDT and sends the transactions to the verification module; The verification module verifies the transaction, and after successful verification, sends the transaction to the transaction pool module.

3. The blockchain-based transaction processing method according to claim 2, characterized in that, The method further includes: The verification module receives transactions sent by user nodes; The verification module verifies the transaction, and after successful verification, sends the transaction to the transaction pool module; The synchronization module synchronizes the transaction to other blockchain nodes based on the CRDT.

4. The blockchain-based transaction processing method according to claim 1, characterized in that, The transaction pool module selects multiple unconfirmed transactions from the transaction area to form a candidate block, including: The transaction pool module filters multiple transactions from the transaction area whose transaction tag is the first content; The transaction pool module assembles the keys of the multiple transactions into a key list, which is used to represent candidate blocks.

5. The blockchain-based transaction processing method according to claim 4, characterized in that, The deletion of all candidate blocks in the proposal area except for the confirmed block includes: The transaction pool module deletes the key list of each candidate block in the proposal area, except for the confirmed block.

6. The blockchain-based transaction processing method according to claim 1, characterized in that, The method further includes: The synchronization module obtains candidate blocks sent by other blockchain nodes based on the CRDT, and sends the candidate blocks to the chain module; the chain module synchronizes the candidate blocks to the proposal area; The synchronization module synchronizes the candidate blocks generated by the local blockchain node to other blockchain nodes based on the CRDT.

7. The blockchain-based transaction processing method according to claim 1, characterized in that, The method further includes: When the confirmed block is a candidate block generated by a local blockchain node, the synchronization module synchronizes the confirmed block to other blockchain nodes based on the CRDT; When the confirmed block is a candidate block generated by other blockchain nodes, the synchronization module receives the confirmed block sent by the other blockchain nodes based on the CRDT and sends the confirmed block to the chain module.

8. A controller in a blockchain node, characterized in that, The controller includes a verification module, a transaction pool module, a chain module, and a synchronization module based on CRDT. The transaction pool module is used to store the transactions sent by the verification module in the form of key-value pairs in the transaction area, wherein the key is the transaction hash of the transaction, and the value includes the transaction tag and transaction data of the transaction, and the transaction tag is set to the first content to indicate that the transaction is an unconfirmed transaction; The transaction pool module is also used to select multiple unconfirmed transactions from the transaction area to form a candidate block, and send the candidate block to the chain module; The chain module is used to synchronize the candidate blocks to the proposal area, synchronize a confirmed block selected from the candidate blocks in the proposal area to the confirmation area, and send the confirmed block to the transaction pool module. The transaction pool module is further configured to set the transaction tag of the transaction in the confirmation block to the second content to indicate that the transaction is a confirmed transaction, and delete each candidate block in the proposal area except for the confirmation block; The data in the transaction area, proposal area, and confirmation area of ​​each blockchain node are synchronized by the synchronization module based on the CRDT.

9. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, which is loaded and executed by a processor to implement the blockchain-based transaction processing method as described in any one of claims 1 to 7.

10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one instruction, which is loaded and executed by the processor to implement the blockchain-based transaction processing method as described in any one of claims 1 to 7.

Images