WO2024001024A1 - Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs - Google Patents

Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs Download PDF

Info

Publication number
WO2024001024A1
WO2024001024A1 PCT/CN2022/135304 CN2022135304W WO2024001024A1 WO 2024001024 A1 WO2024001024 A1 WO 2024001024A1 CN 2022135304 W CN2022135304 W CN 2022135304W WO 2024001024 A1 WO2024001024 A1 WO 2024001024A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
execution
read
write
transactions
Prior art date
Application number
PCT/CN2022/135304
Other languages
English (en)
Chinese (zh)
Inventor
王江
Original Assignee
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2024001024A1 publication Critical patent/WO2024001024A1/fr

Links

Images

Classifications

    • 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
    • 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
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and in particular relate to a method of executing transactions in a blockchain system, a blockchain system, and nodes.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.
  • a blockchain node executes multiple transactions in a block, it can speed up transaction execution by executing transactions in parallel.
  • the purpose of the present invention is to provide a solution for executing transactions in the blockchain, which can effectively verify whether the master node is doing evil.
  • the first aspect of this specification provides a method for executing transactions in a blockchain, where the blockchain includes a master node and a slave node, and the method includes:
  • the master node pre-executes multiple transactions to obtain pre-execution read and write sets of each transaction; groups multiple transactions according to the pre-execution read and write sets of multiple transactions to obtain multiple transaction groups and generates pre-execution of each transaction group. Read and write sets; send the grouping results and the pre-execution read and write sets of each transaction group to the slave node;
  • the slave node verifies the grouping results according to the pre-execution read and write sets of the multiple transaction groups; if the verification passes, the multiple transactions are executed in parallel according to the grouping results to obtain the execution of the transactions included in each transaction group.
  • Read-write set, the pre-execution read-write set of each transaction group is verified based on the execution read-write set of the transactions included in the transaction group.
  • a second aspect of this specification provides a method for executing transactions in a blockchain.
  • the blockchain includes a master node and a slave node.
  • the method is executed by the slave node and includes:
  • a grouping result obtained by grouping multiple transactions and a pre-execution read-write set of each transaction group are received from the master node, wherein the pre-execution read-write set of the transaction group is based on the data of each transaction included in the transaction group.
  • Pre-execution read and write set generation
  • the pre-execution read-write set of each transaction group is verified based on the execution read-write set of the transactions included in the transaction group.
  • the third aspect of this specification provides a blockchain slave node, including:
  • a receiving unit configured to receive, from the master node of the blockchain, a grouping result obtained by grouping multiple transactions and a pre-execution read-write set of each transaction group, wherein the pre-execution read-write set of the transaction group is based on the Generate pre-execution read and write sets for each transaction included in the transaction group;
  • a verification unit configured to verify the grouping results according to the pre-execution read and write sets of the multiple transaction groups
  • An execution unit configured to execute the multiple transactions in parallel according to the grouping results when the verification is passed, and obtain an execution read-write set of transactions included in each transaction group;
  • the verification unit is also configured to verify the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group.
  • the fourth aspect of this specification provides a blockchain, including a master node and a slave node,
  • the master node is used to: pre-execute multiple transactions and obtain pre-execution read and write sets of each transaction; group multiple transactions according to the pre-execution read and write sets of multiple transactions to obtain multiple transaction groups and generate each transaction group.
  • the pre-execution read-write set sends the grouping results and the pre-execution read-write set of each transaction group to the slave node;
  • the slave node is used to: verify the grouping results according to the pre-execution read and write sets of the multiple transaction groups; in the case of passing the verification, execute the multiple transactions in parallel according to the grouping results to obtain the results included in each transaction group.
  • the execution read-write set of the transaction, and the pre-execution read-write set of each transaction group is verified based on the execution read-write set of the transactions included in the transaction group.
  • a fifth aspect of this specification provides a computer-readable storage medium on which a computer program is stored.
  • the computer program is executed in a computer, the computer is caused to execute the method described in the second aspect.
  • a sixth aspect of this specification provides a computing device, including a memory and a processor.
  • the memory stores executable code.
  • the processor executes the executable code, the method described in the second aspect is implemented.
  • the slave node can quickly verify whether the master node has done evil, and optimize the existing time-consuming steps as much as possible, and ensure that even if the master node does evil, the correctness of the blockchain data can still be maintained. and consistency.
  • Figure 1 is a block chain architecture diagram in the embodiment of this specification.
  • Figure 2 shows the blockchain structure diagram in the embodiment of this specification
  • Figure 3 is a flow chart of a method for executing transactions in the embodiment of this specification
  • Figure 4 is an architectural diagram of a slave node of a blockchain in an embodiment of this specification.
  • Figure 1 shows the blockchain architecture diagram in the embodiment of this specification.
  • the blockchain includes, for example, a total of 6 nodes including master node 1, slave node 2 to slave node 5.
  • the connections between nodes schematically represent P2P (Peer to Peer, point-to-point) connections.
  • P2P Peer to Peer, point-to-point
  • These nodes store the entire ledger, which stores the status of all blocks and all accounts.
  • each node in the blockchain generates the same state in the blockchain by executing the same transaction, and each node in the blockchain stores the same state database.
  • the master node 1 can be responsible for receiving transactions from the client and initiating a consensus proposal to each slave node.
  • the consensus proposal includes, for example, multiple transactions in the block to be formed (such as block B1) and each Transaction submission order and other information. After the nodes in the blockchain successfully reach consensus on the consensus proposal, each node can execute the multiple transactions according to the submission order in the consensus proposal, thereby generating block B1.
  • FIG. 1 shows that the blockchain includes 6 nodes
  • the embodiments of this specification are not limited to this, and may include other numbers of nodes.
  • the nodes included in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements.
  • BFT Byzantine Fault Tolerance
  • the mentioned Byzantine fault tolerance requirements can be understood as meaning that Byzantine nodes can exist within the blockchain, but the blockchain does not reflect Byzantine behavior externally.
  • some Byzantine fault-tolerant algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).
  • the blockchain node can execute transactions in parallel through multiple processes in a single machine.
  • the blockchain node can be deployed in a server cluster and execute transactions in parallel through multiple servers.
  • the blockchain node first divides multiple transactions into multiple transaction groups according to the accounts accessed by the transactions. Each transaction group does not access the same account, so that each transaction group can be executed in parallel.
  • a smart contract is called in a transaction, the variables accessed in the transaction cannot be predicted before the transaction is executed, so multiple transactions cannot be effectively grouped, and transactions cannot be executed in parallel.
  • multiple transactions can be pre-executed by the master node to obtain respective pre-execution read and write sets of the multiple transactions, and based on the pre-execution read and write sets Write sets divide multiple transactions into multiple groups so that each slave node can execute multiple transactions in parallel according to multiple groups.
  • the master node intentionally does evil, such as providing wrong packets to the slave nodes.
  • the embodiment of this specification provides a solution for executing transactions in parallel in the blockchain shown in Figure 1.
  • the slave node can effectively check whether the master node has done evil, thereby improving the system efficiency of the blockchain.
  • FIG. 2 shows a structural diagram of the master node 1 and slave nodes (for example, slave node 2) of the blockchain provided by the embodiment of this specification.
  • the master node 1 includes a pre-execution module 11, a conflict detection module 12 and a consensus module 13, and the slave node 2 includes a consensus module 22 and a calculation module 23.
  • Masternode 1 can for example be connected to a client so that multiple transactions can be received from the client.
  • the pre-execution module 11 pre-executes the transaction and obtains the pre-execution read and write set of the transaction.
  • the pre-execution read and write set includes a pre-execution read set and a pre-execution write set.
  • the pre-execution read set can specifically be the key-value pairs of read variables generated during the pre-execution transaction.
  • the pre-execution write set can specifically be Key-value pairs of written variables generated during the pre-execution transaction.
  • the master node 1 can maintain a pre-execution status set, and the pre-execution module 11 can read the status values of variables from the pre-execution status set or the status database when pre-executing a transaction. After pre-executing the transaction, the pre-execution module 11 can update the pre-execution status set according to the pre-execution read and write set of the transaction.
  • the pre-execution module 11 may include multiple pre-execution sub-modules, such as the pre-execution sub-module 111 and the pre-execution sub-module 112. These two pre-execution sub-modules can pre-execute transactions in parallel.
  • the conflict detection module 12 includes a pre-execution status set and a pre-execution transaction set, wherein the master node 1 stores the pre-execution status set and the pre-execution transaction set in the memory for use by the conflict detection module 12 .
  • the conflict detection module 12 performs pre-execution conflict detection on each transaction serially.
  • the conflict detection module 12 detects whether there is a conflict between the pre-execution read set of the transaction and the write set of the transaction that has been pre-executed. If the value of a certain variable in the pre-execution read set of the transaction is inconsistent with the variable in the pre-execution status set If the values are different, it can be determined that there is a conflict. If it is determined that there is no conflict, the conflict detection module 12 updates the status in the pre-execution write set of the transaction to the pre-execution status set, and arranges the transaction sequence into the pre-execution transaction set.
  • the consensus module 13 obtains multiple previously recorded sequential transactions from the pre-execution transaction set.
  • the consensus module 13 includes a grouping sub-module 131.
  • the grouping sub-module 131 groups the multiple transactions based on their respective pre-execution read and write sets. Transactions are grouped to obtain multiple transaction groups, and there are no conflicting transactions between each transaction group.
  • the situation where there are conflicting transactions between two transaction groups usually includes the following situations: the transaction in the first transaction group reads the first variable (that is, the first transaction group reads the first variable), and the second transaction group writes The first variable; the first trading group writes the first variable, the second trading group writes the first variable; the first trading group reads the first variable and writes the first variable, and the second trading group writes the first variable; The first transaction group reads the first variable and writes the first variable, and the second transaction group reads the first variable and writes the first variable.
  • the grouping sub-module 131 can group multiple transactions according to the requirement that the same variables are not accessed between each transaction group.
  • the consensus module 13 also generates pre-execution read-write sets for each transaction group based on the pre-execution read-write sets of the multiple transactions.
  • the master node 1 initiates a consensus proposal to the consensus module (for example, the consensus module 22) of each slave node, where the consensus proposal includes the multiple transactions and the arrangement of the multiple transactions in the pre-execution transaction set. The order, the grouping results of the multiple transactions, and the pre-execution read and write sets of each transaction group. It can be understood that the master node can also broadcast the multiple transactions to the slave nodes, so that the multiple transactions may not be included in the consensus proposal.
  • the group verification sub-module 221 in the consensus module 22 can verify whether there is a conflict between each group according to the group read and write set of each group, that is, verify whether there is access between each group. The same variable or account.
  • the computing module 23 in the slave node can execute the multiple transactions in parallel starting from the group.
  • the computing module 23 of the slave node 2 includes multiple execution sub-modules (the figure schematically shows the execution sub-module 232, the execution sub-module 233 and the execution sub-module 234).
  • each execution sub-module can verify the correctness of the grouping based on the obtained execution read-write set of the transaction.
  • the master node 1 sends the pre-execution read and write sets of each transaction group to each slave node.
  • the slave node can effectively verify whether the master node has done evil, which improves system efficiency.
  • step S301 the master node 1 pre-executes multiple transactions and obtains the pre-execution read and write sets of each transaction.
  • Master node 1 can pre-execute the transaction immediately after receiving a transaction.
  • the master node 1 may execute multiple received transactions serially.
  • master node 1 When master node 1 is pre-executing a transaction, when the value of any variable is read from the pre-execution state set or the state database in Figure 2, the key of the read variable is recorded in the read cache of the transaction set in the memory. Value pairs, when writing the value of any variable, record the key-value pair of the written variable in the write cache of the transaction, and after the pre-execution is completed, the transaction can be obtained based on the read cache and write cache of the transaction pre-execution read-write set.
  • master node 1 when master node 1 reads a variable (such as variable A) during the pre-execution of the transaction, master node 1 first determines whether the value of variable A is stored in the write cache of the transaction. If the value of variable A is stored, , the value of variable A can be read directly from the write cache. In the case where it is determined that the value of variable A is not stored in the write cache, it is determined whether the value of variable A is stored in the read cache of the transaction. If the value of variable A is stored, the value of variable A can be read from the read cache. . When it is determined that the value of variable A is not stored in the read cache, it is determined whether the value of variable A is stored in the pre-execution state set.
  • a variable such as variable A
  • the value of variable A can be read from the pre-execution state set. .
  • the value of variable A may be read from the state database. That is to say, during the process of pre-execution of the transaction, the priority of the master node 1 to read the variables is: transaction write cache > transaction read cache > pre-execution status set > status database. This can ensure that the reads during the pre-execution process are The value of the variable taken is the latest value of the variable.
  • the master node 1 After pre-executing each transaction as described above, the master node 1 obtains the pre-execution read and write set of each transaction.
  • the pre-execution read-write set includes a read set and a write set, wherein the read set includes key-value pairs (key-values) of variables read when pre-executing the transaction, and the write set includes pre-execute the The key-value pair of the variable written during the transaction.
  • the read set of the pre-execution read and write set may include the version number of the variable read when pre-executing the transaction
  • the write set may include the version number of the variable written, wherein, in the state database For example, each written value of a variable and the version number corresponding to each written value are stored, so that the value read and written by the transaction can be determined by including the version number of the variable in the read and write set.
  • the blockchain node may write to different variables based on the values of the variables read during the execution of the contract called by the transaction. For example, when the value of the read variable is 1, write 10 to variable a, when the value of the read variable is 2, write 20 to variable b, and so on. Therefore, for a transaction that calls a contract, the blockchain node must execute the transaction to determine the variables read and written by the transaction, thereby obtaining the read and write set of the transaction. To this end, the master node 1 obtains the pre-execution read and write set of each transaction by pre-executing each of the multiple transactions. The pre-execution process is basically the same as the process of executing the transaction.
  • the difference is that the pre-execution of the pair of transactions is Execution is the execution process that takes place before consensus, and the execution of transactions is the execution process that takes place after consensus. And the pre-execution result of the pre-execution transaction is only used to update the pre-execution state set, not to update the world state, while the execution result of the execution transaction is used to update the world state.
  • the master node 1 can pre-execute multiple transactions received at the same time in parallel through multiple pre-execution sub-modules.
  • the master node 1 performs pre-execution conflict detection on each transaction serially after pre-executing each transaction.
  • master node 1 when master node 1 performs pre-execution conflict detection on transaction Tx1 among the multiple transactions, it first determines whether the pre-execution state set includes a variable (for example, variable A) in the pre-execution read set of transaction Tx1. If not, it is similarly determined whether other variables in the pre-execution read set of transaction Tx1 are included in the pre-execution state set.
  • a variable for example, variable A
  • the pre-execution status set does not include all the variables in the pre-execution read set of transaction Tx1, that is, the previous transaction that has passed pre-execution conflict detection has not read or written the variables accessed by this transaction, then the pre-execution of transaction Tx1 can be determined There is no conflict between the read set and the pre-execution status set, that is, it is determined that the pre-execution of the transaction Tx1 does not conflict with the previous transactions that have undergone pre-execution conflict detection.
  • master node 1 determines whether the value of variable A in the pre-execution read set is consistent with the value of variable A in the pre-execution status set. If they are consistent, it indicates that the variable A read by the transaction The value of is the latest status of variable A during pre-execution.
  • master node 1 determines that the value read for each variable in the pre-execution read set of transaction Tx1 is the latest state in the pre-execution process, it can be determined that there is no conflict between the pre-execution read set and the pre-execution status set of transaction Tx1.
  • master node 1 determines that the value of variable A in the pre-execution read set of transaction Tx1 is inconsistent with the value of variable A in the pre-execution state set, it means that the value of variable A read by transaction Tx1 is not the latest state in the pre-execution process, so , it can be determined that there is a conflict between the pre-execution read set and the pre-execution status set of transaction Tx1. In the event that a conflict is determined, the master node 1 can re-pre-execute the transaction Tx1.
  • the master node 1 determines that there is no conflict between the pre-execution read set and the pre-execution status set of the transaction, it updates the pre-execution status set and the pre-execution transaction set based on the pre-execution read and write set of the transaction.
  • the master node 1 determines that there is no conflict between the pre-execution read set and the pre-execution status set of the transaction Tx2 in the multiple transactions, and the master node 1 reads or writes the pre-execution read and write set of the transaction Tx2 in a centralized manner.
  • the values of the variables are updated to the pre-execution status set, so that the pre-execution status set records the latest status of each variable during the pre-execution process.
  • the master node 1 records the transaction sequence into the pre-execution transaction set, for example, records the transaction at the end position (ie, the last position) of the pre-execution transaction set.
  • the order of the transactions recorded in the pre-execution transaction set reflects the order of conflict detection of each transaction, and there is no conflict between each recorded transaction and the previously recorded transaction.
  • the pre-execution transaction set is, for example, in the form of a sequence table or a queue.
  • step S303 the master node 1 groups multiple transactions according to the pre-execution read and write sets of the multiple transactions.
  • the grouping sub-module 131 can be used to group multiple transactions based on the read variable key and the written variable key included in the pre-execution read and write set of each transaction. As mentioned above, this grouping can prevent transactions in different transaction groups from accessing the same variables. This access includes read operations and write operations. When the grouping conditions are met, there will be no conflicting transactions between various transaction groups. Therefore, individual trading groups can be executed in parallel.
  • step S305 the master node 1 generates a pre-execution read and write set of each transaction group.
  • the grouping sub-module 131 may also generate the pre-execution read-write set of each transaction group based on the pre-execution read-write set of each transaction included in each transaction group. Specifically, the grouping sub-module 131 can generate a pre-execution read set of a transaction group based on the pre-execution read set of each transaction, where the pre-execution read set includes the keys of variables read by all transactions in the transaction group. For example, a transaction group includes transaction Tx1, transaction Tx2, and transaction Tx3.
  • the pre-execution read set of transaction Tx1 includes the key-value pair of variable a and variable b
  • the pre-execution read set of transaction Tx2 includes the key-value pair of variable c and variable b.
  • Key-value pair the pre-execution read set of transaction Tx3 includes the key-value pair of variable a and variable c
  • the pre-execution read set of this transaction group is ⁇ a, b, c ⁇ .
  • the grouping sub-module 131 can generate a pre-execution write set of the transaction group based on the pre-execution write set of each transaction. Similar to the above-mentioned generation of the pre-execution read set of the transaction group, the pre-execution write set includes variables written by all transactions in the transaction group. key.
  • the master node 1 After the master node 1 completes the pre-execution of multiple transactions, as mentioned above, the above consensus process makes the pre-execution read-write set of the transaction consistent with the execution read-write set. Therefore, the master node 1 can directly The pre-execution result is used as the execution result for the transaction.
  • the state database is updated according to the pre-execution read and write sets of the multiple transactions, and blocks are generated.
  • the block includes a block header and a block body.
  • the block body includes, for example, transaction bodies, receipts and other data of each of the multiple transactions.
  • the block header can include data such as status root, receipt root, and transaction root.
  • step S307 the master node 1 sends the grouping results of multiple transactions, the pre-execution read and write sets of each transaction group, and the order of the multiple transactions in the pre-execution transaction set to the slave nodes (including the slave node 2).
  • the master node 1 can generate a consensus proposal, which can include the grouping results of multiple transactions, the pre-execution read and write sets of each transaction group, the order of the multiple transactions in the pre-execution transaction set, and
  • the consensus proposal is sent to each slave node, thereby reaching a consensus with each slave node, that is, the multiple transactions are regarded as multiple transactions in the block to be generated, and the multiple transactions are based on the multiple transactions in the pre-execution transaction
  • the sort order within the set is performed.
  • the slave node may additionally receive the multiple transactions from the master node or the client, or may also include the multiple transactions in the consensus proposal.
  • the master node 1 eliminates conflicts between transactions when performing pre-execution, and each node executes each transaction in the order in the pre-execution transaction set when executing the transaction, so that the transaction can be executed without the master node doing evil.
  • the obtained read-write set must be consistent with the pre-execution read-write set of the transaction.
  • step S309 the slave node verifies the grouping results according to the pre-execution read-write set of each transaction group.
  • slave node 2 can determine whether each group accesses the same variable based on the pre-execution read and write set of each transaction group. If at least two groups among multiple groups access the same variable, it means that the at least two groups should be divided into two groups. into a transaction group, so it can be determined that the grouping result is wrong, and it can be determined that the master node has done something evil, that is, it provided the wrong grouping, so the verification failed, and the slave node 2 can execute step S315, according to the consensus proposal Multiple transactions are executed serially in the order, that is, each slave node no longer trusts the grouping results of the master node, but achieves consistent execution results by executing multiple transactions in series.
  • step S319 the slave node 2 executes step S311, and during the execution of each transaction, the pre-execution read-write set of the verification group is verified based on the execution read-write set of the transaction.
  • each execution sub-module can receive one or more transaction groups from the consensus module 22 , to execute multiple transactions in each transaction group serially.
  • the execution sub-module generates the execution read set and execution write set of the transaction during the execution of each transaction.
  • the execution read set includes the key-value pairs of the variables read during the execution of the transaction, and the execution write set Contains key-value pairs for variables written during execution of this transaction.
  • the execution sub-module can determine whether the variable is included in the pre-execution read set of the transaction group to which the transaction belongs, so as to evaluate the transaction group's pre-execution read set. Pre-execution read set for verification. If the variable is not included in the pre-execution read set of the transaction group, it means that the master node provides an incorrect pre-execution read set. Therefore, the grouping result obtained by grouping based on the pre-execution read set is an incorrect result. Therefore, in step S311 If the verification fails, slave node 2 can similarly perform step S315. On the other hand, if all variables written by a transaction during execution appear in the pre-execution write set of the transaction group, execution of other transactions in the group can continue.
  • the execution sub-module can also verify the pre-execution write set of the transaction group during the execution of the transaction. Similarly, it can verify whether the variables written during the execution of the transaction appear in the pre-execution write set of the transaction group. , if it does not appear, the verification in step S311 fails, and the slave node can execute step S315. On the other hand, if all variables written by a transaction during execution appear in the pre-execution write set of the transaction group, execution of other transactions in the group can continue.
  • the slave node may continue to execute step S313 in FIG. 3 .
  • step S313 the slave node verifies the execution read-write set of the transaction group according to the execution read-write set of the transaction group.
  • slave node 2 After slave node 2 completes multiple transactions in parallel execution, it can generate the execution read-write set of each transaction group based on the execution read-write set of the transactions included in each group. This process can refer to the pre-execution read-write of the generated transaction group above. The description of the set will not be repeated here.
  • slave node 2 can verify whether the execution read and write set of each transaction group is consistent with the pre-execution read and write set of the transaction group. Specifically, verify whether the execution read set of each transaction group is consistent with the pre-execution read and write set of the transaction group. The execution write set of each transaction group is consistent with the pre-execution write set of the transaction group. If they are consistent, the verification passes, and slave node 2 can update the world state and generate a block based on the execution results of the multiple transactions. If the execution read-write set of each transaction group is inconsistent with the pre-execution read-write set of the transaction group, the slave node 2 may execute step S315.
  • each slave node After each slave node completes step S315 if the verification fails, it can trigger the re-election of the master node, thereby preventing the current master node from doing evil again.
  • Figure 4 is an architectural diagram of a slave node of a blockchain in the embodiment of this specification, including:
  • the receiving unit 41 is configured to receive the grouping results obtained by grouping multiple transactions and the pre-execution read-write set of each transaction group from the master node of the blockchain, wherein the pre-execution read-write set of the transaction group is based on Generating pre-execution read and write sets for each transaction included in the transaction group;
  • Verification unit 42 configured to verify the grouping results according to the pre-execution read and write sets of the multiple transaction groups
  • the execution unit 43 is configured to execute the multiple transactions in parallel according to the grouping results when the verification is passed, and obtain the execution read-write set of the transactions included in each transaction group;
  • the verification unit 42 is also configured to verify the pre-execution read-write set of the transaction group based on the execution read-write set of the transactions included in each transaction group.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • the controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers.
  • controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing methods.
  • the systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions.
  • a typical implementation device is a server system.
  • the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.
  • the functions are divided into various modules and described separately.
  • the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. .
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions
  • the device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device.
  • Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
  • Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information.
  • Information may be computer-readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • Magnetic tape magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé d'exécution d'une transaction dans un système de chaîne de blocs, et un système de chaîne de blocs et des nœuds. Le système de chaîne de blocs comprend un nœud maître et un nœud esclave. Le procédé comprend les étapes suivantes : un nœud maître pré-exécute une pluralité de transactions pour obtenir des ensembles de lecture-écriture de pré-exécution des transactions respectives ; regroupe la pluralité de transactions selon les ensembles de lecture-écriture de pré-exécution de la pluralité de transactions, de façon à obtenir une pluralité de groupes de transactions, et génère des ensembles de lecture-écriture de pré-exécution des groupes de transactions respectifs ; envoie un résultat de regroupement et les ensembles de lecture-écriture de pré-exécution des groupes de transactions respectifs à un nœud esclave ; le nœud esclave vérifie le résultat de regroupement selon les ensembles de lecture-écriture de pré-exécution de la pluralité de groupes de transactions ; et lorsque la vérification est réussie, exécute la pluralité de transactions en parallèle selon le résultat de regroupement, de façon à obtenir des ensembles de transactions de lecture-écriture d'exécution, qui sont compris dans chaque groupe de transactions, et vérifie l'ensemble de lecture-écriture de pré-exécution du groupe de transactions sur la base des ensembles de lecture-écriture d'exécution des transactions, qui sont compris dans le groupe de transactions.
PCT/CN2022/135304 2022-06-29 2022-11-30 Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs WO2024001024A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210750970.8A CN115098594A (zh) 2022-06-29 2022-06-29 在区块链系统中执行交易的方法、区块链系统和节点
CN202210750970.8 2022-06-29

Publications (1)

Publication Number Publication Date
WO2024001024A1 true WO2024001024A1 (fr) 2024-01-04

Family

ID=83295906

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135304 WO2024001024A1 (fr) 2022-06-29 2022-11-30 Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs

Country Status (2)

Country Link
CN (1) CN115098594A (fr)
WO (1) WO2024001024A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115098594A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点
CN115658808A (zh) * 2022-09-30 2023-01-31 蚂蚁区块链科技(上海)有限公司 一种共识节点类型的转换方法和共识节点
CN115658806A (zh) * 2022-09-30 2023-01-31 蚂蚁区块链科技(上海)有限公司 区块链系统中的交易执行方法和节点
CN115714652A (zh) * 2022-10-31 2023-02-24 蚂蚁区块链科技(上海)有限公司 交易执行方法和区块链节点

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190190719A1 (en) * 2017-12-18 2019-06-20 Koninklijke Kpn N.V. Primary and secondary blockchain device
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN113743950A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链节点和区块链
CN113743949A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN115098594A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190190719A1 (en) * 2017-12-18 2019-06-20 Koninklijke Kpn N.V. Primary and secondary blockchain device
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN113743950A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链节点和区块链
CN113743949A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN115098594A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点

Also Published As

Publication number Publication date
CN115098594A (zh) 2022-09-23

Similar Documents

Publication Publication Date Title
WO2024001024A1 (fr) Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs
TWI743458B (zh) 一種並行化執行區塊鏈交易的方法、裝置及系統
CN113743941B (zh) 一种在区块链中执行交易的方法、区块链和主节点
CN113743940B (zh) 在区块链中执行交易的方法、区块链、主节点和从节点
WO2023231336A1 (fr) Procédé d'exécution de transaction et nœud de chaîne de blocs
WO2023231345A1 (fr) Procédé de regroupement d'une pluralité de transactions, et nœud de chaîne de blocs
CN113743950B (zh) 在区块链系统中执行交易的方法、节点和区块链系统
CN113743942B (zh) 交易执行方法、区块链、主节点和主存储设备
WO2023160083A1 (fr) Procédé d'exécution de transactions, blockchain, nœud maître et nœud esclave
WO2023160085A1 (fr) Procédé d'exécution de transaction, chaîne de blocs, nœud maître et nœud esclave
CN110704438B (zh) 一种区块链中布隆过滤器的生成方法及装置
WO2023231335A1 (fr) Procédé d'exécution d'une transaction dans une chaîne de blocs, et nœud maître de chaîne de blocs
WO2023231337A1 (fr) Procédé d'exécution d'une transaction dans une chaîne de blocs, et nœud maître et nœud esclave de chaîne de blocs
CN113744063B (zh) 区块链中执行交易的方法及装置
CN113744061B (zh) 在区块链系统中执行交易的方法、区块链系统、和从节点
CN113744062A (zh) 在区块链中执行交易的方法、区块链节点和区块链
WO2024001025A1 (fr) Procédé de nettoyage de données en mémoire cache de pré-exécution et nœud de chaîne de blocs
WO2024001032A1 (fr) Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs
CN116707891A (zh) 重放攻击检查方法和区块链节点
WO2024092932A1 (fr) Procédé d'exécution de transaction et nœud de chaîne de blocs
CN115033350A (zh) 一种分布式事务的执行方法及装置
WO2018188416A1 (fr) Procédé et appareil de recherche de données, et dispositifs associés
US20150067053A1 (en) Managing message distribution in a networked environment
CN114697344B (zh) 区块链系统中共识节点的确定方法、区块链系统、节点、存储介质及计算设备
US12061583B1 (en) Systems for processing data using stages

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22949104

Country of ref document: EP

Kind code of ref document: A1