WO2024001024A1 - 在区块链系统中执行交易的方法、区块链系统和节点 - Google Patents

在区块链系统中执行交易的方法、区块链系统和节点 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
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.)
Ceased
Application number
PCT/CN2022/135304
Other languages
English (en)
French (fr)
Inventor
王江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ant Blockchain Technology Shanghai Co Ltd
Original Assignee
Ant Blockchain Technology Shanghai Co Ltd
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 Ant Blockchain Technology Shanghai Co Ltd filed Critical Ant Blockchain Technology Shanghai Co Ltd
Publication of WO2024001024A1 publication Critical patent/WO2024001024A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (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

一种在区块链中执行交易的方法、区块链系统和节点，所述区块链系统包括主节点和从节点，所述方法包括：所述主节点预执行多个交易，得到各个交易的预执行读写集；根据多个交易的预执行读写集对多个交易进行分组，得到多个交易组，生成各个交易组的预执行读写集；将分组结果和各个交易组的预执行读写集发送给从节点；所述从节点根据所述多个交易组的预执行读写集对分组结果进行验证；在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集，基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。

Description

在区块链系统中执行交易的方法、区块链系统和节点
本申请要求于2022年6月29日提交中国国家知识产权局、申请号为202210750970.8、申请名称为“在区块链系统中执行交易的方法、区块链系统和节点”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本说明书实施例属于区块链技术领域，尤其涉及一种在区块链系统中执行交易的方法、区块链系统和节点。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也受到人们越来越多的重视和应用。区块链节点在执行区块中的多个交易时，可通过并行执行交易加快交易执行速度。
发明内容
本发明的目的在于提供一种在区块链中执行交易的方案，可以有效验证主节点是否作恶。
本说明书第一方面提供一种在区块链中执行交易的方法，所述区块链包括主节点和从节点，所述方法包括：
所述主节点预执行多个交易，得到各个交易的预执行读写集；根据多个交易的预执行读写集对多个交易进行分组，得到多个交易组，生成各个交易组的预执行读写集；将分组结果和各个交易组的预执行读写集发送给从节点；
所述从节点根据所述多个交易组的预执行读写集对分组结果进行验证；在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集，基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
本说明书第二方面提供一种在区块链中执行交易的方法，所述区块链包括主节点和从节点，所述方法由所述从节点执行，包括：
从所述主节点接收对多个交易进行分组得到的分组结果和各个交易组的预执行读写集，其中，所述交易组的预执行读写集基于所述交易组中包括的各个交易的预执行读写集生成；
根据所述多个交易组的预执行读写集对分组结果进行验证；
在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集；
基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
本说明书第三方面提供一种区块链的从节点，包括：
接收单元，用于从所述区块链的主节点接收对多个交易进行分组得到的分组结果和各个交易组的预执行读写集，其中，所述交易组的预执行读写集基于所述交易组中包括的各个交易的预执行读写集生成；
验证单元，用于根据所述多个交易组的预执行读写集对分组结果进行验证；
执行单元，用于在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集；
所述验证单元还用于，基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
本说明书第四方面提供一种区块链，包括主节点和从节点，
所述主节点用于：预执行多个交易，得到各个交易的预执行读写集；根据多个交易的预执行读写集对多个交易进行分组，得到多个交易组，生成各个交易组的预执行读写集；将分组结果和各个交易组的预执行读写集发送给从节点；
所述从节点用于：根据所述多个交易组的预执行读写集对分组结果进行验证；在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集，基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
本说明书第五方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第二方面所述的方法。
本说明书第六方面提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第二方面所述的方法。
通过本说明书实施例提供的方案，从节点可以快速验证主节点是否作恶，并尽可能优化存在的耗时步骤，并确保即使存在主节点作恶的情况中，仍能维持区块链数据的正确性和一致性。
附图说明
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本说明书实施例中的区块链架构图；
图2示出了本说明书实施例中的区块链结构图；
图3为本说明书实施例中的执行交易的方法流程图；
图4为本说明书实施例中的一种区块链的从节点的架构图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
图1示出本说明书实施例中的区块链架构图。如图1中，区块链中例如包含主节点1、从节点2～从节点5共6个节点。节点之间的连线示意性的表示P2P(Peer to Peer，点对点)连接。这些节点上都存储全量的账本，即存储全部区块和全部账户的状态。其中，区块链中的每个节点通过执行相同的交易而产生区块链中的相同的状态，区块链中的每个节点存储相同的状态数据库。所不同的是，主节点1可负责从客户端接收交易，并向各个从节点发起共识提议，该共识提议中例如包括将要成块的区块(例如区块B1)中的多个交易及各个交易的提交顺序等信息。在区块链中的节点对共识提议共识成功之后，各个节点可根据共识提议中的提交顺序执行该多个交易，从而生成区块B1。
可以理解，图1所示的区块链仅仅是示例性的，本说明书实施例不限于应用于图 1所示的区块链，例如还可以应用于包括分片的区块链系统中。
另外，图1中虽然示出了区块链中包括6个节点，本说明书实施例不限于此，而是可以包括其他数目的节点。具体是，区块链中包含的节点可以满足拜占庭容错(Byzantine Fault Tolerance，BFT)要求。所述的拜占庭容错要求可以理解为在区块链内部可以存在拜占庭节点，而区块链对外不体现拜占庭行为。一般的，一些拜占庭容错算法中要求节点个数大于3f+1，f为拜占庭节点个数，例如实用拜占庭容错算法PBFT(Practical Byzantine Fault Tolerance)。
在相关技术中，为了提高区块链中的每秒执行交易(TPS)指标，需要加快交易的执行速度。为此，区块链节点中可通过并行执行交易来加快交易的执行速度。在一种实施方式中，区块链节点可通过单机中的多个进程并行执行交易，在另一种实施方式中，区块链节点可部署在服务器集群中，通过多台服务器并行执行交易。通常，对于转账交易，区块链节点首先根据交易访问的账户将多个交易划分为多个交易组，各个交易组之间不访问相同的账户，从而可并行执行各个交易组。然而，当交易中调用智能合约时，在执行该交易之前不能预知该交易中访问的变量，从而无法对多个交易进行有效的分组，也就无法对并行执行交易。
在一种相关技术中，在包括主节点和多个从节点的区块链中，可以由主节点预执行多个交易，得到多个交易各自的预执行读写集，并根据该预执行读写集将多个交易分为多个组，从而各个从节点可按照多个组并行执行多个交易。然而，在该方案中，可能存在主节点故意作恶的情况，比如向从节点提供错误的分组。
本说明书实施例提供了一种在图1所示区块链中并行执行交易的方案，可由从节点有效地检查主节点是否作恶，从而提高了区块链的系统效率。
图2示出了本说明书实施例提供的区块链的主节点1和从节点(例如从节点2)的结构图。如图2所示，主节点1中包括预执行模块11、冲突检测模块12和共识模块13，从节点2中包括共识模块22和计算模块23。主节点1例如可以与客户端连接，从而可以从客户端接收到多个交易。主节点1在接收到每个交易之后，预执行模块11预执行该交易，得到该交易的预执行读写集。其中，预执行读写集包括预执行读集和预执行写集，预执行读集具体可以为在预执行交易的过程中生成的读取的变量的键值对，预执行写集具体可以为在预执行交易的过程中生成的写入的变量的键值对。主节点1中可维护预执行状态集，预执行模块11在预执行交易时，可从预执行状态集或者状态数据库中读取变量的状态值。预执行模块11在预执行交易之后，可根据交易的预 执行读写集更新预执行状态集。
如图2中所示，预执行模块11中可包括多个预执行子模块，例如预执行子模块111和预执行子模块112，这两个预执行子模块可并行预执行交易。冲突检测模块12中包括预执行状态集和预执行交易集合，其中，主节点1例如在内存中存储所述预执行状态集和预执行交易集合，以供冲突检测模块12使用。冲突检测模块12串行地对各个交易进行预执行冲突检测。具体是，冲突检测模块12检测该交易的预执行读集与已经预执行的交易的写集是否存在冲突，如果该交易的预执行读集中的某个变量的值与预执行状态集中的该变量的值不同，则可确定存在冲突。如果确定不存在冲突，冲突检测模块12将该交易的预执行写集中的状态更新到预执行状态集中，并将该交易顺序排列到预执行交易集合中。
共识模块13从预执行交易集合中获取在先记录的顺序排列的多个交易，共识模块13中包括分组子模块131，分组子模块131根据该多个交易各自的预执行读写集对该多个交易进行分组，得到多个交易组，各个交易组之间不存在冲突交易。其中，两个交易组之间存在冲突交易的情况通常包括如下种情况：第一交易组中的交易读取第一变量(即第一交易组读取第一变量)，第二交易组写入第一变量；第一交易组写入第一变量，第二交易组写入第一变量；第一交易组读取第一变量且写入第一变量，第二交易组写入第一变量；第一交易组读取第一变量且写入第一变量，第二交易组读取第一变量且写入第一变量。其中，如果两个交易组读取相同的变量也可以认为是不存在冲突交易。通常，为了简化方案，分组子模块131可按照各个交易组之间不访问相同的变量的要求来对多个交易进行分组。
另外，共识模块13还根据所述多个交易的预执行读写集生成各个交易组的预执行读写集。之后，主节点1向各个从节点的共识模块(例如共识模块22)发起共识提议，其中，该共识提议中包括所述多个交易、所述多个交易在所述预执行交易集合中的排列顺序、所述多个交易的分组结果、以及各个交易组的预执行读写集。可以理解，主节点也可以向从节点广播所述多个交易，从而在共识提议中可以不包括所述多个交易。
在区块链中的多个共识节点共识成功之后，共识模块22中的分组验证子模块221可以根据各个组的组读写集验证各个组之间是否存在冲突，即验证各个组之间是否访问相同的变量或账户。
在分组验证子模块221的验证通过的情况中，从节点中的计算模块23可以按照分组开始并行执行所述多个交易。其中，从节点2的计算模块23中包括多个执行子模块 (图中示意示出执行子模块232、执行子模块233和执行子模块234)。每个执行子模块在执行交易的过程中可以根据得到的交易的执行读写集来验证分组的正确性。
通过如上所述的过程，主节点1通过将各个交易组的预执行读写集发送给各个从节点，从节点可以有效验证主节点是否作恶，提高了系统效率。
下文将参考图3所示的执行交易的方法流程图详细描述上述过程。在图3中仅示出了主节点1和从节点2执行的流程，可以理解，区块链中的其他从节点与从节点2执行相同的流程。
参考图3，首先，在步骤S301，主节点1预执行多个交易，得到各个交易的预执行读写集。
主节点1可以在每接收到一个交易之后，就立即对该交易进行预执行。
在一种实施方式中，主节点1可串行执行接收的多个交易。主节点1在预执行交易时，当从图2中的预执行状态集或者状态数据库中读取任意变量的值时，在内存中设置的该交易的读缓存中记录该读取的变量的键值对，在写入任意变量的值时，在该交易的写缓存中记录该写入的变量的键值对，并在预执行结束之后，可基于该交易的读缓存和写缓存获取该交易的预执行读写集。
具体是，主节点1在预执行该交易的过程中读取变量(例如变量A)时，主节点1首先确定该交易的写缓存中是否存储有变量A的值，如果存储了变量A的值，可直接从写缓存中读取变量A的值。在确定所述写缓存中未存储变量A的值情况中，确定该交易的读缓存中是否存储有变量A的值，如果存储了变量A的值，可从读缓存中读取变量A的值。在确定所述读缓存中未存储变量A的值情况中，确定所述预执行状态集中是否存储变量A的值，如果存储了变量A的值，可从预执行状态集中读取变量A的值。在确定预执行状态集中未存储变量A的值的情况中，可从状态数据库读取变量A的值。也就是说，主节点1在预执行交易的过程中，读取变量的优先度为：交易的写缓存＞交易的读缓存＞预执行状态集＞状态数据库，通过如此可保证预执行过程中读取的变量的值为该变量最新的值。
主节点1在如上所述预执行每个交易之后，得到各个交易的预执行读写集。在一种实施方式中，该预执行读写集中包括读集和写集，其中，读集包括预执行该交易时读取的变量的键值对(key-value)，写集包括预执行该交易时写入的变量的键值对。在另一种实施方式中，该预执行读写集的读集中可包括预执行该交易时读取的变量的版本号，写集中可包括写入的变量的版本号，其中，在状态数据库中例如存储了变量 的各个写入值及各个写入值对应的版本号，从而通过在读写集中包括变量的版本号即可以确定交易读取和写入的值。
在交易中调用合约的情况中，区块链节点在执行该交易调用的合约的过程中，有可能根据读取的变量的值来对不同的变量进行写入。例如，当读取的变量的值为1时，对变量a写入10，当读取的变量的值为2时，对变量b写入20等等。因此，对于调用合约的交易，区块链节点必须通过执行该交易，才能确定该交易读取的变量和写入的变量，从而得到该交易的读写集。为此，主节点1通过预执行多个交易中的每个交易，得到每个交易的预执行读写集，该预执行的过程与执行交易的过程基本相同，不同在于，该对交易的预执行是在共识之前进行的执行过程，而对交易的执行是在共识之后进行的执行过程。并且预执行交易的预执行结果仅用于更新预执行状态集，而不用于更新世界状态，而执行交易的执行结果用于更新世界状态。
在一种实施方式中，参考图2，主节点1可通过多个预执行子模块对同时接收的多个交易并行进行预执行。为了防止多个预执行子模块并行更新预执行状态集导致冲突，主节点1在预执行各个交易之后，串行地对各个交易进行预执行冲突检测。
具体是，主节点1在对所述多个交易中的交易Tx1预执行冲突检测时，首先确定预执行状态集中是否包括交易Tx1的预执行读集中的变量(例如变量A)。如果没有，再类似地确定预执行状态集中是否包括交易Tx1的预执行读集中的其他变量。如果预执行状态集中不包括交易Tx1的预执行读集中的全部变量，也就是说，之前经过预执行冲突检测的交易还未对该交易访问的变量进行读写，则可确定交易Tx1的预执行读集与预执行状态集没有冲突，也即确定该交易Tx1的预执行与之前经过预执行冲突检测的交易不存在冲突。
如果主节点1确定预执行状态集中包括变量A的值，则确定预执行读集中的变量A的值与预执行状态集中的变量A的值是否一致，如果一致，说明该交易读取的变量A的值为预执行过程中变量A的最新状态。当主节点1对于交易Tx1预执行读集中的每个变量都确定所读取的值为预执行过程中的最新状态之后，可确定该交易Tx1的预执行读集与预执行状态集不存在冲突。
如果主节点1确定交易Tx1的预执行读集中的变量A的值与预执行状态集中的变量A的值不一致，说明该交易Tx1读取的变量A的值不是预执行过程中的最新状态，因此，可确定交易Tx1的预执行读集与预执行状态集存在冲突。在确定存在冲突的情况中，主节点1可对该交易Tx1重新进行预执行。
主节点1在确定交易的预执行读集与预执行状态集不存在冲突的情况中，基于该交易的预执行读写集更新预执行状态集和预执行交易集合。
具体是，例如，主节点1确定所述多个交易中的交易Tx2的预执行读集与预执行状态集不存在冲突，主节点1将交易Tx2的预执行读写集中读取或者写入的变量的值更新到预执行状态集中，从而使得该预执行状态集中记录各个变量在预执行过程中的最新状态。同时，主节点1将该交易顺序记录到预执行交易集合中，例如将该交易记录到预执行交易集合的末尾位置(即最后一个位置)。也就是说，预执行交易集合中记录的交易的顺序体现了各个交易的冲突检测的顺序，并且所记录的各个交易与之前记录的交易不存在冲突。其中，所述预执行交易集合例如为顺序表的形式，或者为队列的形式。
在步骤S303，主节点1根据多个交易的预执行读写集对多个交易进行分组。
主节点1中可通过分组子模块131基于各个交易的预执行读写集中包括的读取的变量的键(key)和写入的变量key，对多个交易进行分组。如上文所述，该分组可使得不同交易组中的交易不访问相同的变量，该访问包括读操作和写操作，在达到该分组条件的情况下，各个交易组之间不会存在冲突交易，因此，各个交易组可以并行执行。
在步骤S305，主节点1生成各个交易组的预执行读写集。
分组子模块131还可以基于各个交易组中包括的各个交易的预执行读写集生成各个交易组的预执行读写集。具体是，分组子模块131可基于各个交易的预执行读集生成交易组的预执行读集，该预执行读集包括该交易组中的全部交易读取的变量的键(key)。例如，一个交易组中包括交易Tx1、交易Tx2、交易Tx3，其中，交易Tx1的预执行读集中包括变量a和变量b的键值对，交易Tx2的预执行读集中包括变量c和变量b的键值对，交易Tx3的预执行读集中包括变量a和变量c的键值对，则该交易组的预执行读集为{a，b，c}。
分组子模块131可基于各个交易的预执行写集生成交易组的预执行写集，与上述生成交易组的预执行读集类似的，该预执行写集中包括交易组中全部交易写入的变量的key。
主节点1在完成对多个交易的预执行之后，由于如上文所述，上述共识过程使得交易的预执行读写集与执行读写集一致，因此，主节点1可以直接将多个交易的预执行结果用作为该交易的执行结果。根据该多个交易的预执行读写集更新状态数据库，并生成区块。该区块包括区块头和区块体。其中，区块体中例如包括所述多个交易各自的 交易体、收据等数据。区块头中可以包括状态根、收据根、交易根等数据。
在步骤S307，主节点1将多个交易的分组结果、各个交易组的预执行读写集、所述多个交易在预执行交易集合中的排列顺序发送给从节点(包括从节点2)。
具体是，主节点1可生成共识提议，该共识提议中可包括多个交易的分组结果、各个交易组的预执行读写集、所述多个交易在预执行交易集合中的排列顺序，并将该共识提议发送给各个从节点，从而与各个从节点达成共识，即将该多个交易作为即将生成的区块中的多个交易，并且该多个交易基于所述多个交易在预执行交易集合中的排列顺序执行。其中，从节点可另外从主节点或者客户端接收到所述多个交易，或者，在共识提议中还可以包括该多个交易。
通过如此，主节点1在进行预执行时排除了交易之间的冲突，并且各个节点在执行交易时按照预执行交易集合中的排列顺序执行各个交易，使得在主节点不作恶的情况中执行交易得到的读写集与该交易的预执行读写集必然是一致的。
在步骤S309，从节点根据各个交易组的预执行读写集验证分组结果。
具体是，从节点2可根据各个交易组的预执行读写集确定各个分组是否访问相同的变量，如果多个分组中至少两个分组之间访问相同的变量，说明该至少两个分组应分到一个交易组中，因此可确定分组结果是错误的，从而可确定主节点存在作恶的行为，即提供了错误的分组，因此该验证未通过，从节点2可执行步骤S315，按照共识提议中的顺序串行执行多个交易，即各个从节点不再信任主节点的分组结果，而是通过串行执行多个交易达到一致的执行结果。
当在步骤S309中的验证通过的情况中，从节点2执行步骤S311，在每个交易的执行过程中，根据交易的执行读写集验证组的预执行读写集。
从节点2在对分组结果的验证通过之后，可通过图2中示出的多个执行子模块并行执行多个交易，例如，每个执行子模块可从共识模块22接收一个或多个交易组，以串行执行每个交易组中的多个交易。其中，执行子模块在执行每个交易的过程中，生成该交易的执行读集和执行写集，其中，执行读集中包括该交易在执行过程中读取的变量的键值对，执行写集包括该交易在执行过程中写入的变量的键值对。
执行子模块在执行交易的中间，即未结束对交易的执行时，在每次读取一个变量时，可确定该交易所属的交易组的预执行读集中是否包括该变量，以对交易组的预执行读集进行验证。如果交易组的预执行读集中不包括该变量，说明主节点提供了错误的预执行读集，因此基于该预执行读集进行分组得到的分组结果也就是错误的结果， 因此，步骤S311中的验证未通过，从节点2可类似地执行步骤S315。反之，如果交易在执行过程中写入的全部变量都出现在交易组的预执行写集中，则可以继续进行对该组中其他交易的执行。
类似地，执行子模块在执行交易的过程中，还可以对交易组的预执行写集进行验证，类似地，可验证交易在执行过程中写入的变量是否出现在交易组的预执行写集中，如果未出现，则步骤S311中的验证未通过，从节点可执行步骤S315。反之，如果交易在执行过程中写入的全部变量都出现在交易组的预执行写集中，则可以继续进行对该组中其他交易的执行。
在步骤S311中的验证通过时，从节点可继续执行图3中的步骤S313。
在步骤S313，从节点根据交易组的执行读写集验证组的执行读写集。
从节点2在并行执行完成多个交易之后，可根据各个组中包括的交易的执行读写集生成各个交易组的执行读写集，该过程可参考上文中对生成交易组的预执行读写集的描述，在此不再赘述。
然后，从节点2可验证每个交易组的执行读写集是否与该交易组的预执行读写集一致，具体是，验证每个交易组的执行读集是否与该交易组的预执行读集一致，以及验证每个交易组的执行写集是否与该交易组的预执行写集一致。如果一致，则验证通过，从节点2可基于该多个交易的执行结果更新世界状态，生成区块。如果每个交易组的执行读写集与该交易组的预执行读写集不一致，则从节点2可执行步骤S315。
各个从节点在验证不通过的情况下完成步骤S315之后，可触发重新选举主节点，从而避免当前的主节点再次作恶。
图4为本说明书实施例中的一种区块链的从节点的架构图，包括：
接收单元41，用于从所述区块链的主节点接收对多个交易进行分组得到的分组结果和各个交易组的预执行读写集，其中，所述交易组的预执行读写集基于所述交易组中包括的各个交易的预执行读写集生成；
验证单元42，用于根据所述多个交易组的预执行读写集对分组结果进行验证；
执行单元43，用于在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集；
所述验证单元42还用于，基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例 如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device，PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以 是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据 处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下 文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (16)

  1. 一种在区块链系统中执行交易的方法，所述区块链系统包括主节点和从节点，所述方法包括：
    所述主节点预执行多个交易，得到各个交易的预执行读写集；根据多个交易的预执行读写集对多个交易进行分组，得到多个交易组，生成各个交易组的预执行读写集；将分组结果和各个交易组的预执行读写集发送给从节点；
    所述从节点根据所述多个交易组的预执行读写集对分组结果进行验证；在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集，基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
  2. 根据权利要求1所述的方法，所述基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证包括：在执行每个交易的过程中，使用交易的执行读集对该交易所属的交易组的预执行读集进行验证。
  3. 根据权利要求1或2所述的方法，所述基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证包括：在完成对所述多个交易的并行执行之后，根据各个交易组中包括的交易的执行读写集生成各个交易组的执行读写集，基于各个交易组的执行读写集对各个交易组的预执行读写集进行验证。
  4. 根据权利要求1-3任一项所述的方法，所述从节点根据所述多个交易组的预执行读写集对分组结果进行验证包括：所述从节点根据所述多个交易组的预执行读写集验证所述多个交易组中的交易组之间是否访问相同变量。
  5. 根据权利要求1-3任一项所述的方法，所述主节点预执行多个交易包括：所述主节点基于预执行状态集预执行所述多个交易，所述方法还包括：所述主节点在预执行完每个交易之后，串行地对每个交易进行如下处理：确定所述交易的预执行读集是否与所述预执行状态集存在冲突，其中，在对于预执行完的第一交易确定不存在冲突的情况中，基于所述第一交易的预执行读写集更新所述预执行状态集，将所述第一交易顺序记录到预执行交易集合中；其中，各个交易组中的交易排列顺序基于各个交易组中的交易在所述预执行交易集合中的排列顺序确定。
  6. 根据权利要求5所述的方法，还包括：所述主节点将所述多个交易在所述预执行交易集合中的排列顺序发送给所述从节点，所述从节点在验证不通过的情况中，根据所述多个交易在所述预执行交易集合中的排列顺序串行执行所述多个交易。
  7. 根据权利要求5或6所述的方法，其中，所述主节点基于预执行状态集预执行所述多个交易包括，所述主节点在预执行任一交易中读取第一变量时，确定所述预执行状态集中是否存储有所述第一变量的值，在确定所述预执行状态集中未存储所述第一变量的值的情况中，从状态数据库读取所述第一变量的值。
  8. 根据权利要求5或6所述的方法，其中，所述确定所述交易的预执行读集是否与所述预执行状态集存在冲突包括，确定所述预执行状态集中是否包括所述交易的预执行读集中的第二变量，在确定所述预执行状态集中包括所述第二变量的情况中，确定所述预执行状态集中的第二变量的值与所述预执行读集中的第二变量的值是否一致，如果不一致，则确定所述交易的预执行读集与所述预执行状态集存在冲突。
  9. 一种在区块链系统中执行交易的方法，所述区块链系统包括主节点和从节点，所述方法由所述从节点执行，包括：
    从所述主节点接收对多个交易进行分组得到的分组结果和各个交易组的预执行读写集，其中，所述交易组的预执行读写集基于所述交易组中包括的各个交易的预执行读写集生成；
    根据所述多个交易组的预执行读写集对分组结果进行验证；
    在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集；
    基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
  10. 根据权利要求9所述的方法，所述基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证包括：在执行每个交易的过程中，使用交易的执行读集对该交易所属的交易组的预执行读集进行验证。
  11. 根据权利要求10所述的方法，所述基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证还包括：在完成对所述多个交易的并行执行之后，根据各个交易组中包括的交易的执行读写集得到各个交易组的执行写集，基于各个交易组的执行写集对各个交易组的预执行写集进行验证。
  12. 根据权利要求9-11任一项所述的方法，所述根据所述多个交易组的预执行读写集对分组结果进行验证包括：根据所述多个交易组的预执行读写集验证所述多个交易组中的交易组之间是否访问相同变量。
  13. 一种区块链系统的从节点，包括：
    接收单元，用于从所述区块链系统的主节点接收对多个交易进行分组得到的分组 结果和各个交易组的预执行读写集，其中，所述交易组的预执行读写集基于所述交易组中包括的各个交易的预执行读写集生成；
    验证单元，用于根据所述多个交易组的预执行读写集对分组结果进行验证；
    执行单元，用于在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集；
    所述验证单元还用于，基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
  14. 一种区块链系统，包括主节点和从节点，
    所述主节点用于：预执行多个交易，得到各个交易的预执行读写集；根据多个交易的预执行读写集对多个交易进行分组，得到多个交易组，生成各个交易组的预执行读写集；将分组结果和各个交易组的预执行读写集发送给从节点；
    所述从节点用于：根据所述多个交易组的预执行读写集对分组结果进行验证；在验证通过的情况中根据分组结果并行执行所述多个交易，得到每个交易组包括的交易的执行读写集，基于每个交易组包括的交易的执行读写集对所述交易组的预执行读写集进行验证。
  15. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求9-12中任一项的所述的方法。
  16. 一种区块链节点，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求9-12中任一项所述的方法。
PCT/CN2022/135304 2022-06-29 2022-11-30 在区块链系统中执行交易的方法、区块链系统和节点 Ceased WO2024001024A1 (zh)

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=83295906

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135304 Ceased WO2024001024A1 (zh) 2022-06-29 2022-11-30 在区块链系统中执行交易的方法、区块链系统和节点

Country Status (2)

Country Link
CN (1) CN115098594B (zh)
WO (1) WO2024001024A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115098594B (zh) * 2022-06-29 2026-04-17 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点
CN115658806A (zh) * 2022-09-30 2023-01-31 蚂蚁区块链科技(上海)有限公司 区块链系统中的交易执行方法和节点
CN115658808A (zh) * 2022-09-30 2023-01-31 蚂蚁区块链科技(上海)有限公司 一种共识节点类型的转换方法和共识节点
CN115714652B (zh) * 2022-10-31 2025-10-10 蚂蚁区块链科技(上海)有限公司 交易执行方法和区块链节点
CN116305311A (zh) * 2022-12-29 2023-06-23 蚂蚁区块链科技(上海)有限公司 区块链系统中验证读写集的方法和装置
CN116561740A (zh) * 2023-04-28 2023-08-08 蚂蚁区块链科技(上海)有限公司 区块链中的交易执行方法、节点和系统

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
CN113743949A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743950A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链节点和区块链
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN115098594A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 在区块链系统中执行交易的方法、区块链系统和节点

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11070360B2 (en) * 2018-08-13 2021-07-20 International Business Machines Corporation Parallel transaction validation and block generation in a blockchain
CN113743943B (zh) * 2021-11-04 2022-07-08 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743940B (zh) * 2021-11-04 2022-08-12 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743942B (zh) * 2021-11-04 2023-06-02 支付宝(杭州)信息技术有限公司 交易执行方法、区块链、主节点和主存储设备

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
CN113743949A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743950A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链节点和区块链
CN113743941A (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
CN115098594B (zh) 2026-04-17

Similar Documents

Publication Publication Date Title
CN113743940B (zh) 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743941B (zh) 一种在区块链中执行交易的方法、区块链和主节点
CN114942847B (zh) 执行交易的方法和区块链节点
CN114827165B (zh) 对多个交易进行分组的方法和区块链节点
CN113743950B (zh) 在区块链系统中执行交易的方法、节点和区块链系统
CN115098594B (zh) 在区块链系统中执行交易的方法、区块链系统和节点
CN114936256B (zh) 在区块链中执行交易的方法和区块链节点
WO2023231337A1 (zh) 在区块链中执行交易的方法、区块链的主节点和从节点
CN113744063B (zh) 区块链中执行交易的方法及装置
CN113743942B (zh) 交易执行方法、区块链、主节点和主存储设备
CN114547203B (zh) 执行交易的方法、区块链、主节点和从节点
WO2024001032A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
WO2024001025A1 (zh) 一种预执行缓存数据清理方法和区块链节点
CN115714652A (zh) 交易执行方法和区块链节点
WO2023160083A1 (zh) 执行交易的方法、区块链、主节点和从节点
CN116431312B (zh) 区块链系统中的交易执行方法和区块链节点
CN116881361A (zh) 交易的执行方法、节点和区块链系统
CN113744062B (zh) 在区块链中执行交易的方法、区块链节点和区块链
WO2023231335A1 (zh) 在区块链中执行交易的方法及区块链的主节点
CN116707891A (zh) 重放攻击检查方法和区块链节点
CN113744061B (zh) 在区块链系统中执行交易的方法、区块链系统、和从节点
CN107102898A (zh) 一种基于numa架构的内存管理、构建数据结构的方法及装置
CN116668001A (zh) 区块链中的交易处理方法和区块链节点
CN116049310A (zh) 区块链系统中的交易执行方法、存储服务和区块链节点
CN116244373A (zh) 交易执行方法、区块链系统、主节点和从存储设备

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

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22949104

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 24.06.2025)

122 Ep: pct application non-entry in european phase

Ref document number: 22949104

Country of ref document: EP

Kind code of ref document: A1