WO2023231345A1 - 对多个交易进行分组的方法和区块链节点 - Google Patents

对多个交易进行分组的方法和区块链节点 Download PDF

Info

Publication number
WO2023231345A1
WO2023231345A1 PCT/CN2022/135664 CN2022135664W WO2023231345A1 WO 2023231345 A1 WO2023231345 A1 WO 2023231345A1 CN 2022135664 W CN2022135664 W CN 2022135664W WO 2023231345 A1 WO2023231345 A1 WO 2023231345A1
Authority
WO
WIPO (PCT)
Prior art keywords
transactions
multiple transactions
execution
transaction
read
Prior art date
Application number
PCT/CN2022/135664
Other languages
English (en)
French (fr)
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 WO2023231345A1 publication Critical patent/WO2023231345A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and particularly relate to a method of grouping multiple transactions and a blockchain node.
  • 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.
  • the purpose of the present invention is to provide a method for grouping multiple transactions to improve the efficiency of parallel execution of transactions.
  • the first aspect of this specification provides a method of grouping multiple transactions, executed by a blockchain node, including:
  • An algorithm for grouping the plurality of transactions is determined based on the information. .
  • the second aspect of this specification provides a blockchain node, including:
  • An acquisition unit configured to acquire pre-execution read and write sets of multiple transactions; acquire information on variables and/or accounts in the blockchain accessed by the multiple transactions based on the pre-execution read and write sets of the multiple transactions;
  • a determining unit configured to determine an algorithm for grouping the multiple transactions based on the information.
  • a third 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 first aspect.
  • a fourth aspect of this specification provides a blockchain node, including a memory and a processor.
  • the memory stores executable code.
  • the processor executes the executable code, the method described in the first aspect is implemented.
  • the solution provided by the embodiments of this specification improves the efficiency of parallel execution of transactions by adaptively determining an algorithm for grouping multiple transactions based on their correlation.
  • Figure 1 shows a blockchain architecture diagram applied in the embodiment of this specification
  • Figure 2 is a schematic diagram of a DAG diagram of multiple transactions in an embodiment
  • Figure 3 is a flow chart of a method for grouping transactions in an embodiment of this specification
  • Figure 4 is a flow chart of a method for grouping transactions in another embodiment of this specification.
  • Figure 5 is an architectural diagram of a blockchain node in the embodiment of this specification.
  • Figure 6 is a flow chart of a method for executing transactions in the blockchain in the embodiment of this specification.
  • Figure 7 is a flow chart of a method for executing transactions in the blockchain in the embodiment of this specification.
  • Figure 8 is an architectural diagram of a blockchain node in an embodiment of this specification.
  • Figure 1 shows a blockchain architecture diagram applied 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 the Information such as the order of multiple transactions. After the nodes in the blockchain successfully reach consensus on the consensus proposal, each node can execute the multiple transactions according to the 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).
  • Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include sending fields (From), receiving fields (To) and data fields (Data). Transactions in the blockchain can include platform transactions and contract transactions. Platform transactions mainly revolve around platform account operations, including creating accounts, transferring funds, freezing accounts, unfreezing accounts, issuing assets, depositing certificates, etc. Contract transactions mainly revolve around contract execution operations, including deploying contracts, calling contracts, upgrading contracts, etc.
  • the From field represents the account address that initiated the transaction (that is, initiated a transfer task to another account)
  • the To field represents the account address that received the transaction (that is, received the transfer)
  • the Data field Include transfer amount.
  • the From field indicates the account address that initiated the transaction
  • the To field indicates the account address of the contract called by the exchange
  • the Data field includes the function name in the calling contract and the data passed to the function. Enter data such as parameters to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.
  • accounts in the blockchain can usually be divided into two types:
  • Contract account stores the executed smart contract code and the value of the state in the smart contract code. It can usually only be activated through external account calls;
  • Blockchain user Externally owned account: Blockchain user’s account.
  • Smart contracts in the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in the blockchain is to initiate a transaction pointing to the smart contract address, allowing each node in the blockchain to run the smart contract code in a distributed manner. It should be noted that in addition to smart contracts that can be created by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a creation contract. Generally, some blockchain data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator rights can create system-level contracts or modify system-level contracts (referred to as system contracts). Among them, the system contract can be used to add data structures for different business data in the blockchain.
  • Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to the blockchain as shown in Figure 1.
  • the data field of the transaction includes the code of the contract to be created (such as bytecode or machine code), the to field of the transaction is empty to indicate that the transaction is used to deploy the contract.
  • the contract address "0x6f8ae93" of the contract is determined.
  • Each node adds the contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, and stores The contract code is saved in the state storage of the contract, so the contract is created successfully.
  • each node in the blockchain can execute the transaction respectively, thereby executing the contract respectively, and update the status database based on the execution of the contract.
  • the first node in the blockchain can pre-execute multiple transactions, obtain the pre-execution read and write sets of each transaction, and communicate with other nodes through
  • the pre-execution read-write set is sent to other nodes in the blockchain (such as the slave node in Figure 1) through the consensus process between nodes.
  • the pre-execution read and write set of a transaction includes, for example, a pre-execution read set and a pre-execution write set.
  • the pre-execution read set includes key-value pairs of variables read in pre-execution of the transaction.
  • the pre-execution write set includes the transaction. Key-value pairs for variables written in pre-execution.
  • the variables include, for example, external accounts in the blockchain, or variables defined in contract accounts.
  • Other nodes in the blockchain can group multiple transactions based on their pre-execution read and write sets, so that multiple transactions can be executed in parallel based on the grouping results.
  • Multiple transactions can be grouped by different algorithms.
  • multiple transactions can be grouped through a Directed Acyclic Graph (DAG) algorithm.
  • DAG Directed Acyclic Graph
  • transaction Tx1 can be drawn to point to transaction Tx2.
  • transaction Tx1 and transaction Tx2 can be considered as conflict transactions and need to be executed serially, that is, transaction Tx2 is executed after transaction Tx1 is executed.
  • Figure 2 is a schematic diagram of a DAG graph of multiple transactions in an embodiment.
  • the circles in the figure represent nodes in the DAG graph, the numbers in the circles represent transaction numbers, and the arrows between nodes represent directed connecting edges between nodes.
  • the multiple transactions can be grouped according to the DAG graph, so that the transactions in each two transaction groups are separate nodes in the DAG graph, that is, any transaction in one transaction group is related to another transaction. There are no connecting edges between each transaction in a transaction group.
  • transactions Tx1 to Tx8 are conflict transactions and need to be divided into a transaction group.
  • transactions Tx3 and Tx5 are executed serially, and transactions Tx1, Tx2, and Tx4 need to be executed serially.
  • Transaction Tx6 needs to wait for transaction Tx4 and transaction Tx5 to be executed before it can be executed.
  • Transaction Tx7 and transaction Tx8 need to wait for transaction Tx5 and transaction Tx6 to be executed in parallel before they can be executed in parallel.
  • transaction Tx5 and transaction Tx6 connect more than three nodes, which can also be called bifurcation points.
  • bifurcation points When there are many bifurcation points in the DAG graph, subsequent transactions will have a longer waiting time for the bifurcation point.
  • the DAG algorithm requires more state space. Therefore, when there are many conflicting transactions between multiple transactions, the efficiency of using the DAG grouping algorithm decreases.
  • multiple transactions may be grouped by a union-find algorithm.
  • Union-find is a tree-type data structure used to handle the merging and querying of disjoint sets. Union search usually includes two operations: Find, used to query whether two elements are in the same set; Union, used to merge two disjoint sets into one set.
  • Find used to query whether two elements are in the same set
  • Union used to merge two disjoint sets into one set.
  • the union-find algorithm does not consider whether the transaction accesses the Key by reading or writing, as long as two transactions access the same Key, the two transactions will be grouped into a group, so it is possible to read the same key. Both transactions are grouped into the same group. Therefore, compared with the grouping results obtained by the DAG algorithm, the degree of parallelism of multiple transaction groups grouped by the union-find algorithm is lower.
  • the embodiment of this specification provides a method based on The correlation degree of multiple transactions adaptively determines the grouping algorithm to group transactions, thereby improving the efficiency when transactions are executed in parallel.
  • Figure 3 is a flow chart of a method of grouping transactions in an embodiment of this specification. The method can be performed by the master node and the slave node in Figure 1, with the master node 1 and the slave node 2 shown in Figure 3 as an example.
  • step S301 the master node 1 pre-executes multiple transactions and obtains pre-execution read-write sets and pre-execution sequences of multiple transactions.
  • the master node 1 may continuously receive transactions from the user device and store the received transaction sequence into the transaction queue. After receiving the transaction, master node 1 can broadcast the transaction to the blockchain, so that each slave node can also receive the transaction and store the transaction. Master node 1 can regularly obtain multiple transactions from the transaction queue and perform pre-execution serially. It can be understood that multiple transactions can also be pre-executed in parallel in the master node 1, and there is no limit to this.
  • master node 1 can obtain the pre-execution read and write set of the transaction.
  • the pre-execution read and write set includes the pre-execution read set and pre-execution write set of the transaction.
  • the master node 1 can store the identification sequence of the transaction in the transaction queue to indicate the pre-execution sequence of the transaction.
  • the pre-execution read set may include a read set of external accounts and a read set of contract variables.
  • the contract variables are variables defined in the contract, and the pre-execution write set may include a write set of external accounts and contracts. Write set of variables, so that the states in the state tree and the contract state tree can be updated respectively.
  • the contract state tree is tree-like data composed of the states of variables in the contract.
  • step S303 the master node 1 generates a consensus proposal, which includes pre-execution read-write sets and pre-execution sequences of multiple transactions.
  • the master node 1 can generate a consensus proposal based on the pre-execution read-write sets and pre-execution sequences of multiple transactions to initiate consensus.
  • the consensus proposal includes, for example, the pre-execution read-write sets of multiple transactions and the pre-execution sequences of the multiple transactions. , where each transaction in the consensus proposal uses, for example, the hash value of the transaction as the transaction identifier. It can be understood that in the embodiment of this specification, the consensus proposal is not limited to the pre-execution read-write set and pre-execution sequence of multiple transactions. For example, in the case where the slave node executes multiple transactions according to the pre-execution sequence, in Consensus proposals can include only pre-execution read-write sets of multiple transactions.
  • step S305 the master node 1 sends the consensus proposal to the slave node to reach consensus on the consensus proposal.
  • slave node 2 obtains information about variables and/or accounts in the blockchain accessed by multiple transactions based on the pre-execution read and write sets of multiple transactions.
  • Slave node 2 can determine the correlation between multiple transactions based on the variables and/or account information in the blockchain accessed by multiple transactions, and thereby determine the method to use to group multiple transactions based on the size of the correlation. .
  • the relevance of multiple transactions may be determined based on the number of conflicting transactions of each of the multiple transactions. For example, if the number of conflicting transactions for a certain transaction exceeds a predetermined threshold, the correlation of multiple transactions may be considered to exceed the threshold. Or if the sum of the number of conflicting transactions of the multiple transactions exceeds a predetermined threshold, it may be considered that the correlation of the multiple transactions exceeds the threshold.
  • the relevance of multiple transactions can be determined based on the number of transactions that access each key in multiple transactions. For example, if the number of transactions accessing a certain key exceeds a predetermined threshold, the correlation of multiple transactions can be considered to exceed the threshold. Or if the sum of the number of transactions accessing each key exceeds a predetermined threshold, it can be considered that the correlation of multiple transactions exceeds the threshold.
  • the correlation degree of multiple transactions can be determined based on the ratio of the number of transactions that access each key in multiple transactions to the number of transactions in multiple transactions. For example, if the ratio of the number of transactions accessing a certain key to the number of transactions of multiple transactions exceeds a predetermined threshold, the correlation of the multiple transactions can be considered to exceed the threshold.
  • the relevance of multiple transactions may be determined based on the number of contracts and/or external accounts accessed in the multiple transactions. For example, if the number of contracts and/or external accounts accessed in multiple transactions exceeds a preset threshold, the correlation of multiple transactions may be considered to exceed the threshold.
  • the embodiments of this specification are not limited to determining the correlation between multiple transactions through the above-mentioned implementations.
  • the correlation between multiple transactions can also be determined by combining any two or more of the above-mentioned implementations.
  • step S309 the slave node 2 determines the grouping algorithm according to the information of variables and/or accounts.
  • slave node 2 When slave node 2 determines that the correlation of multiple transactions exceeds the threshold as described above, it can use the union-find algorithm to group the multiple transactions, thereby avoiding the intersection points in the DAG graph during the parallel execution of transactions in the DAG algorithm. Waiting for transactions improves the efficiency of parallel execution.
  • the DAG algorithm can be used to group multiple transactions to improve the degree of parallel execution of multiple transactions compared to the union-find algorithm. It can be understood that the embodiments of this specification are not limited to selecting a grouping algorithm from a set including a DAG algorithm and a union-find algorithm.
  • the grouping algorithm set may also include any other grouping algorithm known to those skilled in the art.
  • the slave node 2 can similarly determine whether to use the other grouping algorithm based on the applicable scenarios of the other grouping algorithm and based on the variables and/or account information.
  • step S311 slave node 2 groups multiple transactions using the determined algorithm.
  • the slave node 2 After the slave node 2 determines the grouping algorithm, it applies the grouping algorithm to group multiple transactions to obtain multiple transaction groups.
  • the grouping algorithm For multiple transaction groups obtained by grouping through the DAG algorithm, multiple transactions in one transaction group and multiple transactions in another transaction group are separated in the DAG graph, that is, there is no connecting edge, so that Individual transaction groups can be processed in parallel. Transactions in a single transaction group can be executed serially or in parallel based on their DAG relationships, such as shown in Figure 2.
  • every two transaction groups in the multiple transaction groups do not conflict with each other, that is, any transaction in one transaction group does not conflict with any transaction in another transaction group. Access the same variables or accounts, so multiple trading groups can be executed in parallel. Multiple transactions in a single transaction group are arranged according to their pre-execution order to execute serially in their pre-execution order.
  • slave node 2 executes multiple transactions in parallel according to the grouping results, and obtains the execution read-write set of each transaction.
  • multiple transactions proposed in the consensus proposal can be obtained from the received transactions based on the hash value of each transaction in the consensus proposal.
  • Multiple threads or processes can be used to execute multiple transactions in parallel based on the grouping results. transactions, and obtain the execution read and write sets of multiple transactions.
  • the execution read-write set includes an execution read set and an execution write set. Similar to pre-execution, the execution read set includes key-value pairs of variables read by the transaction during execution, and the execution write set includes key-value pairs of variables written by the transaction during execution.
  • step S315 slave node 2 compares whether the pre-execution read-write set and the execution read-write set of the transaction are consistent.
  • slave node 2 can compare whether the pre-execution read-write set and the execution read-write set of the transaction are consistent. In the case where it is determined that the pre-execution read-write set of the transaction is consistent with the execution read-write set, slave node 2 can update the world state of the variable in the execution write-set in the memory based on the execution write set of the transaction, so that the variable is subsequently involved. The world state of this variable can be read from memory when the transaction is executed.
  • slave node 2 can confirm that master node 1 has not done anything evil, and the pre-execution read-write set of multiple transactions is correct. Therefore, based on the pre-execution The grouping of the read-write set is also correct, so the transaction execution results obtained by executing multiple transactions in parallel under this grouping are also correct. Slave node 2 can thus update the world state based on the execution write sets of multiple transactions, generate and store blocks.
  • the slave node 2 determines that the pre-execution read-write set and the execution read-write set of the transaction are inconsistent, it can determine that the master node 1 has committed evil acts, so it can terminate the execution of the multiple transactions and exchange them with other slave nodes. Operations of the master node.
  • Figure 4 is a flow chart of a method of grouping transactions in another embodiment of this specification. The method can be performed by the master node and the slave node in Figure 1, with the master node 1 and the slave node 2 shown in Figure 4 as an example.
  • step S401 shown in Figure 4 reference may be made to the above description of step S301, which will not be described again here.
  • the method shown in Figure 4 is different from the method shown in Figure 3 in that the master node 1 executes steps S403 to S407 instead of the slave node 2 executing steps S307 to S311, so that the master node 1 reads and writes based on the pre-execution of multiple transactions.
  • Collect information about variables and/or accounts in the blockchain accessed by multiple transactions determine a grouping algorithm based on the information about the variables and/or accounts, and use the grouping algorithm to group multiple transactions. In this way, the calculation amount of multiple slave nodes is reduced and the computing resources of the slave nodes are saved.
  • step S409 the master node 1 generates a consensus proposal, which includes a pre-execution read-write set, a pre-execution sequence and a grouping result.
  • each slave node can use the signature of the master node in the consensus proposal to verify the consensus proposal, thereby ensuring that the grouping result has not been tampered with.
  • steps S411 to S415 reference may be made to the above description of steps S305, S313 and step S315, which will not be described again here.
  • FIG. 5 is an architectural diagram of a blockchain node in the embodiment of this specification. As shown in Figure 5, multiple processes can be run in the master node 1 and each slave node (such as the slave node 2 shown in Figure 5) in the blockchain shown in Figure 1 to provide a variety of services.
  • the master node 1 may include a cache process 12 for providing cache services, a pre-execution process 111 and a pre-execution process 112 for providing pre-execution services, a consensus process 13 for providing consensus services, The block management process 14 of the block management service, etc.
  • the pre-execution process 111 and the pre-execution process 112 are used to pre-execute the transactions received by the master node in parallel.
  • the master node 1 is not limited to including two pre-execution processes, but may include one pre-execution process or more than three pre-execution processes.
  • the master node 1 may also include an access process for providing access services, a network process for providing network services, a storage process for providing storage services, etc., which are not shown in Figure 5 .
  • the slave node 2 may include a cache process 21 for providing cache services, a consensus process 22 for providing consensus services, a block management process 23 for providing block management services, and a computing process 241 for providing transaction execution services. and calculation process 242, etc.
  • the calculation process 241 and the calculation process 242 are used to execute transactions in the consensus proposal in parallel. It can be understood that in the embodiment of this specification, the slave node 2 is not limited to including two computing processes, but may include one computing process or more than three computing processes.
  • a process is a running activity of a program with certain independent functions in an application on a data set. That is, a process is a process in a computer that is carried out by the CPU sequentially executing instructions in the application program. Each process is assigned its own memory address space when it is created, and this memory address space can only be accessed by the process itself. For example, pre-execution process 111 is allocated memory 113, pre-execution process 112 is allocated memory 114, cache process 12 is allocated memory 120, cache process 21 is allocated memory 210, calculation process 241 is allocated memory 243, calculation Process 242 is allocated memory 244.
  • the multiple processes in the master node 1 may be multiple processes in multiple computing devices (or virtual computing nodes), or may be multiple processes in a single computing device.
  • the multiple processes in each slave node may be multiple processes in multiple computing devices (or virtual computing nodes), or may be multiple processes in a single computing device.
  • the solutions provided by the embodiments of this specification are not limited to the master-slave architecture blockchain system.
  • Figure 6 is a flow chart of a method for executing transactions in a blockchain in an embodiment of this specification. This method can be executed by master node 1 in Figure 2.
  • step S601 the cache process 12 in the master node 1 sends multiple transactions to the pre-execution process 111.
  • the master node 1 may also include an access process, which can receive transactions from the user device and send the received transactions to the cache process 12. Therefore, the cache process 12 stores the transactions received from the access process into the memory 120 of the cache process 12 in a certain order.
  • the cache process 12 may store transactions in the order in which they are received, such as by storing the received transactions in order in a transaction queue stored in the memory 120 .
  • the master node 1 may also include a network process (not shown in Figure 2). After receiving multiple transactions, the cache process 12 may send the multiple transactions to the network process, so that the network process broadcasts the multiple transactions to other nodes in the blockchain.
  • the cache process 12 can regularly send a preset number of transactions in the transaction queue to the pre-execution process, so that each pre-execution process Parallel pre-execution of transactions in the transaction queue.
  • the caching process 12 can also send the order of the batch of transactions in the transaction queue to the pre-execution process, so that the pre-execution process can serially execute the batch of transactions according to the order of the batch of transactions in the transaction queue.
  • step S603 the pre-execution process 111 pre-executes multiple transactions and obtains pre-execution read and write sets for each transaction.
  • the pre-execution process 111 may first verify the signatures of each transaction, and after passing the verification, perform pre-execution of the multiple transactions.
  • the pre-execution process 111 serially executes multiple received transactions. For example, the pre-execution process 111 may serially execute multiple transactions in the order in which the multiple received transactions are arranged.
  • the memory 113 may store a state set of some variables in the blockchain, and the partial variables include variables defined in the blockchain account or contract.
  • the pre-execution process 111 may update the locally cached state set when reading or writing variables during the pre-execution transaction.
  • the pre-execution process 111 After pre-executing multiple transactions, the pre-execution process 111 obtains respective pre-execution read and write sets of the multiple transactions and the pre-execution sequences of the multiple transactions.
  • the memory 120 of the cache process 12 stores a state set of some variables in the blockchain. For updates of this state set, refer to the description of subsequent steps in FIG. 6 .
  • each pre-execution process reads a variable during the pre-execution transaction, it first determines whether the value of the variable is included in the state set stored locally in the pre-execution process. If not, it is then determined whether the variable is included in the state set in the memory of the cache process. If there is still no value, the value of the variable is read from the state database, and the value of the read variable is stored in the local state set of the pre-execution process.
  • the multiple transactions include, for example, transaction Tx3.
  • transaction Tx3 includes a read operation on variable a and a write operation on variable b.
  • the pre-execution process 111 executes the read operation on variable a in transaction Tx3, it first determines the memory 113 of the pre-execution process 111 Whether the value of variable a is stored, in the case where the value of variable a is stored in the memory 113, the pre-execution of transaction Tx3 can be completed based on the value of variable a, and a pre-execution read-write set of transaction Tx3 can be generated, for example, transaction Tx3
  • the pre-execution read set includes the key-value pair of variable a
  • the pre-execution write set includes the key-value pair of variable b.
  • the pre-execution process 111 updates the state set in the memory 113 based on the write set of the transaction Tx3, and stores the value of the variable b written by the transaction Tx3 in the pre-execution in the state set.
  • the pre-execution process 111 may request the cache process 12 to read the value of variable a. After receiving the request, the cache process 12 determines whether the state set in the memory 120 includes the value of variable a, and if so, sends the value of variable a to the pre-execution process 111 . After receiving the value of variable a, the pre-execution process 111 can store the value of variable a into the state set in the memory 113, so that it can be used to execute other subsequent transactions that read variable a.
  • the cache process 12 notifies the pre-execution process 111, and the pre-execution process 111 reads the current value of the variable a from the state database, wherein the state database stores the executed The world state corresponding to the completed block.
  • the master node 1 also includes a storage process.
  • the pre-execution process 11 can, for example, send a request to read the variable a to the storage process. After receiving the request, the storage process reads the value of the variable a in the state database and saves the variable. The value of a is returned to the pre-execution process 111.
  • the pre-execution process 111 After receiving the value of variable a from the storage process, the pre-execution process 111 similarly stores the value of variable a into the first state set.
  • the pre-execution process 111 stores the value of the variable a read from the outside of the memory 113 into the memory 113, so that when the pre-execution process 111 reads the variable a in the next execution transaction, it can directly read the variable from the local memory. The value of a, thereby increasing the speed of transaction execution.
  • the pre-execution process 111 After each transaction is executed, the pre-execution process 111 also generates a transaction receipt for each transaction.
  • step S605 the pre-execution process 111 sends the pre-execution read-write sets and pre-execution sequences of multiple transactions to the cache process 12.
  • the pre-execution process 111 After completing the pre-execution of multiple transactions as described above, the pre-execution process 111 sends the obtained pre-execution read-write sets and pre-execution sequences of the multiple transactions to the cache process 12 together. In addition, the pre-execution process 111 also sends the transaction receipt of each transaction to the cache process 12 for storage in the memory 120 .
  • step S607 the cache process 12 updates the local state based on the pre-execution read and write sets of multiple transactions.
  • the cache process 12 After the cache process 12 receives the pre-execution read-write sets and pre-execution sequences of multiple transactions, in the case where there is only one pre-execution process in the master node, since the pre-execution process reads a variable for the first time from the storage process Receive variable values for pre-execution of transactions, pre-execute multiple transactions in series, update the local status set of the pre-execution process with the pre-execution of each transaction, and then update the memory through the pre-execution read and write sets of multiple transactions 120 Therefore, when the transaction sequence in the execution phase is set to be the same as the pre-execution sequence, the pre-execution read-write set of each transaction will be consistent with the execution read-write set.
  • the state set in the updated memory 113 is also the latest world state in the master node 1.
  • Cache process 12 may trust the pre-execution read-write set of the plurality of transactions and may directly update the state set in memory 120 based on the pre-execution read-write set. After the update, the state set in memory 120 also becomes the latest world state in master node 1.
  • the two pre-execution processes may simultaneously execute the same variable during the process of parallel pre-execution transactions.
  • Performing a read or write operation may result in the pre-execution result of one of the transactions not being obtained based on the current latest world state in master node 1, resulting in inconsistency between the pre-execution read-write set of the transaction and the execution read-write set of the transaction.
  • the cache process 12 may sequentially detect the pre-execution read-write sets of each transaction. Specifically, for example, for transaction Tx3, the cache process 12 first determines whether the state set in the memory 120 includes variable a in the pre-execution read set of transaction Tx3. If not, it is similarly determined whether other variables in the pre-execution read set of transaction Tx3 are included in the second state set.
  • the transaction can be determined
  • the pre-execution read set of Tx3 does not conflict with the state set in memory 120.
  • the cache process 12 determines whether the value of the variable a in the pre-execution read set is consistent with the value of the variable a in the state set in the memory 120. If they are consistent, the transaction Tx3 The value of variable a read is the latest status of variable a during pre-execution. After the cache process 12 determines that the value read for each variable in the pre-execution read set of transaction Tx3 is the latest state in the pre-execution process, it can be determined that the pre-execution read set of transaction Tx3 is not consistent with the state set in memory 120 . There is a conflict. In the case where it is determined sequentially that there is no conflict between the pre-execution read sets of multiple transactions and the state set in the memory 120, the state set in the memory 120 can be updated based on the pre-execution read and write sets of the multiple transactions.
  • the cache process 12 determines that the value of variable a in the pre-execution read set of transaction Tx3 is inconsistent with the value of variable a in the state set in memory 120, it means that the value of variable a read by transaction Tx3 is not the latest state in the pre-execution process. , therefore, it can be determined that the pre-execution read set of transaction Tx3 conflicts with the second state set. In the event that a conflict is determined to exist, the cache process 12 may instruct the pre-execution process 111 to re-pre-execute the transaction Tx3 and other transactions pre-executed after the transaction Tx3.
  • the cache process 12 can store the pre-execution read-write sets of the multiple transactions in the memory 120, and process the multiple transactions in the transaction queue according to the pre-execution read-write sets.
  • the pre-execution sequence stores the identifiers of the multiple transactions to indicate the pre-execution sequence of the multiple transactions.
  • step S609 the cache process 12 sends the pre-execution read-write sets and pre-execution sequences of multiple transactions to the consensus process 13.
  • the consensus process 13 regularly calls the interface provided by the cache process 12 to request the cache process 12 to obtain a batch of transactions to be agreed upon for consensus.
  • the cache process 12 sends the pre-execution read and write sets of multiple transactions and the arrangement order of the multiple transactions to the consensus process 13.
  • the arrangement order is the pre-execution order of the multiple transactions.
  • the cache process 12 may send the pre-execution read-write set of each transaction in association with the hash value of each transaction.
  • the cache process 12 may also send multiple transaction data to the consensus process when the pre-execution read-write set of transactions stored in the memory 120 reaches a certain amount of data, or when the pre-execution read-write set of transactions stored in the memory 120 reaches a certain amount. Pre-execution read and write sets and their pre-execution order.
  • step S611 the consensus process 13 generates a consensus proposal and performs consensus with other nodes.
  • blockchain nodes can implement a block-granular consensus mechanism. For example, after a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, the records of other nodes will be the same. block. For another example, a transaction-granularity consensus mechanism can be implemented between blockchain nodes.
  • the consensus mechanism is a mechanism for blockchain nodes to reach a consensus across the entire network on block information (or block data), which can ensure that the latest blocks are accurately added to the blockchain.
  • the current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, etc.
  • the consensus success of the consensus proposal is usually determined after a preset number of nodes reach an agreement on the consensus data (ie, consensus proposal).
  • consensus proposal a preset number of nodes reach an agreement on the consensus data
  • f malicious nodes can be tolerated. That is to say, when 2f + 1 nodes among the N consensus nodes reach an agreement, the consensus can be determined to be successful.
  • the consensus process 13 can generate a consensus proposal, which includes pre-execution read and write sets of multiple transactions and their pre-execution sequences, where each transaction in the consensus proposal can be identified by the hash value of the transaction. .
  • the consensus process 13 may execute steps S403 to S409 in the method shown in Figure 4 to generate a consensus proposal.
  • step S613 the consensus process 13 sends the consensus proposal to the block management process 14.
  • the consensus process 13 may send the consensus proposal to the block management process 14.
  • step S615 the block management process 14 generates and submits blocks.
  • the master node Since the master node trusts its own pre-execution and does not do evil, and the pre-execution of transactions in the master node is based on the correct world state, if the master node re-executes the multiple transactions based on the world state in the state database, the obtained The execution read-write sets of the multiple transactions must be consistent with the pre-execution read-write sets of the multiple transactions. Therefore, the block management process 14 can directly regard the pre-execution read and write sets of the multiple transactions as the execution read and write sets to update the world state in the state database without re-executing the multiple transactions.
  • the block management process 14 can sequentially update the status of each account and each contract variable in the world state according to the write set and pre-execution sequence of the pre-execution read-write set of multiple transactions in the consensus proposal, and update the state tree according to the updated world state.
  • the value of each node in including the state root ((that is, the hash value of the root node of the state tree)).
  • the block management process 14 can also obtain the transaction bodies and transaction receipts of the multiple transactions from the cache process 13, and generate the transaction roots of the transaction trees of the multiple transactions (that is, the hash value of the root node of the transaction tree) and receipts respectively.
  • the receipt root of the tree that is, the hash value of the root node of the receipt tree).
  • the block management process 14 may generate a block (for example, block B1) including the plurality of transactions.
  • the block B1 may include a block body and a block header, where the block header may include a block number, transaction Root, status root, receipt root and other information, the block body can include the transaction body set and receipt set of each transaction.
  • the block management process 14 can submit the block to be stored in the block database of the master node 1 in Figure 2 .
  • block management process 14 may send the block to the storage process so that the storage process stores the block in a block database.
  • the block management process 14 can update the world state and generate and submit blocks immediately after receiving the consensus proposal from the consensus process 13. It can be understood that the block management process 14 can also update the world state and generate and submit blocks after receiving the consensus success information from the consensus process 13 .
  • Figure 7 is a flow chart of a method for executing transactions in a blockchain in an embodiment of this specification. This method can be executed by slave node 2 in Figure 2.
  • step S701 the consensus process 22 in slave node 2 reaches consensus with other nodes in the blockchain.
  • slave node 2 can also include a receiving process and a network process (not shown in Figure 2).
  • Slave node 2 can receive transactions from user devices through the receiving process, and can receive transactions from other nodes through the network process. Transaction sent. After receiving the transaction, the receiving process and the network process send the transaction to the cache process 21, so that the cache process 21 can store the received transaction in the memory 210 in the form of a transaction queue. Similar to the master node 1, the cache process 21 can also send transactions in the transaction queue to the network process to broadcast to other nodes in the blockchain.
  • the network process in master node 1 sends the consensus proposal and the signature of master node 1 to the network processes of other nodes, so that the network process in slave node 2 can receive the consensus proposal and the signature of master node 1, and transfer the consensus
  • the proposal and the signature of master node 1 are sent to consensus process 22. After receiving the consensus proposal and its signature, the consensus process 22 starts the consensus process.
  • step S703 the consensus process 22 sends the consensus proposal to the block management process 23.
  • the consensus process 22 can send the consensus proposal to the block management process 23.
  • step S705 the block management process 23 groups multiple transactions according to the consensus proposal, and allocates the multiple groups to multiple computing processes.
  • the block management process 23 may determine a grouping algorithm for grouping multiple transactions through the method shown in FIG. 3 .
  • the block management process 23 can use a determined grouping algorithm to group the multiple transactions according to the pre-execution read and write set in the consensus proposal, so that all transactions in each two groups do not access the same variables, so that each Groups can be executed in parallel, with multiple transactions in each group arranged in their pre-execution order.
  • the block management process 23 may evenly distribute the multiple groups obtained by grouping to multiple computing processes. For example, in the case where the slave node 2 only includes the calculation process 241 and the calculation process 242, half of the number of components in the plurality of groups can be assigned to the calculation process 241, and the other half of the number of components can be assigned to the calculation process 242.
  • the embodiment of this specification is not limited to the grouping of multiple transactions by the block management process 23.
  • the consensus process 22 can also group multiple transactions according to the pre-execution read and write sets of multiple transactions. And send the consensus proposal and grouping results to the block management process 23.
  • step S707 the block management process 23 sends the group assigned to each process and the pre-execution read-write set of each transaction in the group to each process.
  • step S709 the calculation process executes the transaction and updates the status database.
  • the block management process 23 can assign one or more groups to the calculation process 241 .
  • the block management process 23 allocates multiple groups to the computing process 241
  • the computing process 241 can process multiple groups concurrently through multiple threads.
  • the calculation process 241 serially executes multiple transactions in a group according to the pre-execution order of the multiple transactions in the group.
  • the calculation process 241 includes a memory 243. Before starting to execute multiple groups of transactions, the calculation process 241 can determine all variables that need to be read based on the read sets of all transactions in multiple groups. And read all variables in batches (for example, all at once) from the state database. After reading the states of all variables (ie, world state), process 241 can convert the values of all variables into key-value pairs. The form is stored into a state set in memory 243. Computing process 241 may then execute transactions in each group based on the set of states in memory 243 .
  • the execution read-write set includes an execution read set and an execution write set.
  • the execution read set includes, for example, the key-value pairs of variables read during the transaction execution process
  • the execution write set includes, for example, the key-value pairs of variables written during the transaction execution process.
  • the calculation process 241 stores the parameters that need to be read from the state database into the local memory 243 in advance, so that the calculation process 241 can directly read the state from the memory during the execution of the transaction without the need for Reading state from storage greatly speeds up transaction execution.
  • the calculation process 241 can immediately update the state database according to the execution write set of each transaction of the group. world state without affecting the transaction execution of other groups. At the same time, the transaction execution speed is improved.
  • step S711 the block management process 23 generates and submits blocks.
  • the block management process 23 updates the values of each node in the state tree according to the updated world state, including the state root (i.e. the root of the state tree The hash value of the node)).
  • the block management process 23 can also obtain the transaction bodies and transaction receipts of multiple transactions from the cache process 21, and generate the transaction roots of the transaction trees of the multiple transactions (that is, the hash value of the root node of the transaction tree) and the receipt tree respectively.
  • the receipt root that is, the hash value of the root node of the receipt tree).
  • the block management process 23 may generate a block (for example, block B1) including the plurality of transactions.
  • the block B1 may include a block body and a block header, where the block header may include a block number, transaction Root, status root, receipt root and other information, the block body can include the transaction body set and receipt set of each transaction.
  • the block management process 23 can submit the block to be stored in the block database of the slave node 2 in FIG. 2 .
  • the advantages of the multi-process architecture can be used to further speed up the execution of transactions and improve the efficiency of the blockchain. system efficiency.
  • Figure 8 is an architectural diagram of a blockchain node in an embodiment of this specification, including:
  • the acquisition unit 81 is used to obtain the pre-execution read and write sets of multiple transactions; obtain the information of variables and/or accounts in the blockchain accessed by the multiple transactions according to the pre-execution read and write sets of the multiple transactions. ;
  • the determining unit 82 is configured to determine an algorithm for grouping the multiple transactions according to the information.
  • the determining unit 82 is specifically configured to: determine the degree of correlation between the multiple transactions based on the information, and when it is determined that the degree of correlation is higher than a preset threshold, determine to use and retrieve the The algorithm groups the multiple transactions, and when it is determined that the degree of correlation is lower than a preset threshold, it is determined to use the DAG algorithm to group the multiple transactions.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • HDL High-Speed Integrated Circuit Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal Joint CHDL
  • JHDL Java Hardware Description Language
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • Verilog Verilog
  • 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 the 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.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • 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)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种对多个交易进行分组的方法和区块链节点，所述方法由区块链节点执行，包括：获取多个交易的预执行读写集；根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息；根据所述信息确定对所述多个交易进行分组的算法。

Description

对多个交易进行分组的方法和区块链节点
本申请要求于2022年05月30日提交中国国家知识产权局、申请号为202210602791.X、申请名称为“对多个交易进行分组的方法和区块链节点”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本说明书实施例属于区块链技术领域，尤其涉及一种对多个交易进行分组的方法和区块链节点。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也受到人们越来越多的重视和应用。
发明内容
本发明的目的在于提供一种对多个交易进行分组的方法，以提高交易并行执行的效率。
本说明书第一方面提供一种对多个交易进行分组的方法，由区块链节点执行，包括：
获取多个交易的预执行读写集；
根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息；
根据所述信息确定对所述多个交易进行分组的算法。。
本说明书第二方面提供一种区块链节点，包括：
获取单元，用于获取多个交易的预执行读写集；根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息；
确定单元，用于根据所述信息确定对所述多个交易进行分组的算法。
本说明书第三方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面所述的方法。
本说明书第四方面提供一种区块链节点，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面所述的方法。
本说明书实施例提供的方案通过根据多个交易的关联度适应性地确定对多个交易进行分组的算法，提高了并行执行交易的效率。
附图说明
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使 用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1示出本说明书实施例所应用的区块链架构图；
图2为一实施例中多个交易的DAG图的示意图；
图3为本说明书一实施例中的对交易进行分组的方法流程图；
图4为本说明书另一实施例中的对交易进行分组的方法流程图；
图5为本说明书实施例中的区块链节点的架构图；
图6为本说明书实施例中的在区块链中执行交易的方法流程图；
图7为本说明书实施例中的在区块链中执行交易的方法流程图；
图8为本说明书实施例中的一种区块链节点的架构图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
图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)。
区块链领域中的交易可以指在区块链中执行并记录在区块链中的任务单元。交易中通常包括发送字段(From)、接收字段(To)和数据字段(Data)。区块链中的交易可包括平台交易和合约交易。平台交易主要围绕着平台账号操作，包括创建账号、转账、冻结账号、解冻账号、发行资产、存证等。合约交易主要围绕着合约执行操作， 包括部署合约、调用合约、升级合约等。
例如，在交易为转账交易的情况中，From字段表示发起该交易(即发起对另一个账户的转账任务)的账户地址，To字段表示接收该交易(即接收转账)的账户地址，Data字段中包括转账金额。在交易为调用合约的交易的情况中，From字段表示发起该交易的账户地址，To字段表示交易所调用的合约的账户地址，Data字段中包括调用合约中的函数名、及对该函数的传入参数等数据，以用于在交易执行时从区块链中获取该函数的代码并执行该函数的代码。
其中，区块链中的账户通常可以分为两种类型：
合约账户(contract account)：存储执行的智能合约代码以及智能合约代码中状态的值，通常只能通过外部账户调用激活；
外部账户(Externally owned account)：区块链用户的账户。
区块链中的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。在区块链中调用智能合约，是发起一笔指向智能合约地址的交易，使得区块链中每个节点分布式地运行智能合约代码。需要说明的是，除了可以由用户创建智能合约，也可以在创世块中由系统设置智能合约。这类合约一般称为创世合约。一般的，创世合约中可以设置一些区块链的数据结构、参数、属性和方法。此外，具有系统管理员权限的账户可以创建系统级的合约，或者修改系统级的合约(简称为系统合约)。其中，所述系统合约可用于在区块链中增加不同业务的数据的数据结构。
在部署合约的场景中，例如，Bob将一个包含创建智能合约信息(即部署合约)的交易发送到如图1所示的区块链中，该交易的data字段包括待创建的合约的代码(如字节码或者机器码)，交易的to字段为空，以表示该交易用于部署合约。节点间通过共识机制达成一致后，确定合约的合约地址“0x6f8ae93…”，各个节点在状态数据库中添加与该智能合约的合约地址对应的合约账户，分配与该合约账户对应的状态存储，并将合约代码保存在该合约的状态存储中，从而合约创建成功。
在调用合约的场景中，例如，Bob将一个用于调用智能合约的交易发送到如图1所示的区块链中，该交易的from字段是交易发起方(即Bob)的账户的地址，to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址，交易的data字段包括调用智能合约的方法和参数。在区块链中对该交易进行共识之后，区块链中的各个节点可分别执行该交易，从而分别执行该合约，基于该合约的执行更新状态数据库。
在相关技术中，为了提高区块链中的每秒执行交易(TPS)指标，需要加快交易的执行速度。为此，区块链节点中可通过并行执行交易来加快交易的执行速度。通常，对于转账交易，区块链节点首先根据交易访问的账户将多个交易划分为多个交易组，各个交易组之间不访问相同的账户，从而可并行执行各个交易组。然而，当交易中调用智能合约时，在执行该交易之前不能预知该交易中访问的变量，从而无法对多个交易进行有效的分组，也就无法并行执行交易。在一种实施方式中，可由区块链中的第一节点(例如图1中的主节点1)对多个交易进行预执行，得到各个交易的预执行读写集，并通过与其他节点之间的共识过程将该预执行读写集发送给区块链中的其他节点(例如图1中的从节点)。交易的预执行读写集中例如包括预执行读集和预执行写集， 所述预执行读集包括该交易在预执行中读取的变量的键值对，所述预执行写集包括该交易在预执行中写入的变量的键值对。所述变量例如包括区块链中的外部账户、或者为合约账户中定义的变量。区块链中的其他节点可根据多个交易的预执行读写集对多个交易进行分组，从而可根据分组结果并行执行该多个交易。
可通过不同的算法对多个交易进行分组。在一种实施方式中，可通过有向无环图(Directed Acyclic Graph，DAG)算法对多个交易进行分组。具体是，首先根据交易之间的依赖关系绘制多个交易之间的DAG图。例如，假设从节点根据主节点预执行多个交易的顺序来执行该多个交易，因此，可根据多个交易的预执行读写集和预执行顺序来确定交易之间的依赖关系。其中，如果一个交易的预执行读集与另一个交易的预执行写集中包括相同的Key，或者一个交易的写集和另一个交易的写集中包括相同的Key，那么该两个交易中的在后预执行的交易(例如交易Tx2)需要依赖在前预执行的交易(例如交易Tx1)，因此，在DAG图中可绘制交易Tx1指向交易Tx2，在交易Tx2依赖交易Tx1的执行的情况中，可认为交易Tx1和交易Tx2为冲突交易，需要串行执行，即在执行交易Tx1之后执行交易Tx2。
图2为一实施例中多个交易的DAG图的示意图，图中圆圈表示DAG图中的节点，圆圈中的数字表示交易编号，节点之间的箭头表示节点之间的有向连接边。在得到多个交易的DAG图之后，可根据DAG图对多个交易进行分组，使得每两个交易组中的交易在DAG图中为分离的节点，即一个交易组中的任一交易与另一个交易组中的每个交易之间没有连接边。
如图2中所示，通过箭头连接的多个交易(即交易Tx1～Tx8)为冲突交易，需要分到一个交易组中。在执行交易Tx1～Tx8时，可首先并行执行交易(Tx3、Tx5)和(Tx1、Tx2、Tx4)，其中，交易Tx3、Tx5串行执行，交易Tx1、Tx2、Tx4需要串行执行。交易Tx6需要等待交易Tx4和交易Tx5都执行完成之后再执行，交易Tx7和交易Tx8需要等待交易Tx5和交易Tx6都执行完成之后才能并行执行。其中，交易Tx5和交易Tx6连接三个以上节点，又可以称为分叉点，当DAG图中的分叉点较多的情况中，造成后续交易对该分叉点的等待时间较长。同时，DAG算法需要的状态空间较多。因此，多个交易之间的冲突交易较多的情况中，使用DAG分组算法的效率降低。
在另一种实施方式中，可通过并查集算法对多个交易进行分组。并查集是一种树型的数据结构，用于处理一些不相交集合(disjoint sets)的合并及查询问题。并查集通常包含两种操作：查找(Find)，用于查询两个元素是否在同一个集合中；合并(Union)，用于把两个不相交的集合合并为一个集合。通过该算法，当两个交易的预执行读写集中包括相同的Key时，就可以将该两个交易合并到同一个集合中，从而获得多个集合，每两个集合中的交易不会访问相同的Key，从而可以并行处理多个集合。然而，由于并查集算法不考虑交易对Key的访问是读还是写，只要两个交易访问了相同的Key，就将该两个交易分到一个组中，因此有可能将读取相同key的两个交易分到同一个组中。因此，相比于DAG算法得到的分组结果，通过并查集算法进行分组得到的多个交易组的并行度较低。
在实际业务中，多个交易中的冲突交易的数目是不确定的，单独使用DAG算法或者并查集算法进行交易分组的效果可能不是最优的，为此，本说明书实施例提供一种根 据多个交易的关联程度适应性地确定分组算法来对交易进行分组，从而提高了交易并行执行时的效率。
图3为本说明书一实施例中的对交易进行分组的方法流程图。该方法可由图1中的主节点和从节点执行，图3中示出主节点1和从节点2作为示例。
如图3所示，首先，在步骤S301，主节点1预执行多个交易，得到多个交易的预执行读写集和预执行顺序。
主节点1例如可不断从用户设备接收交易，并将接收的交易顺序存储到交易队列中。主节点1在接收到交易之后，可将该交易广播到区块链中，从而使得各个从节点也可以接收到该交易，并存储该交易。主节点1可定时从交易队列中获取多个交易串行地进行预执行。可以理解，主节点1中也可以并行地预执行多个交易，对此不作限制。
主节点1在预执行任一交易之后，可得到该交易的预执行读写集，该预执行读写集中包括交易的预执行读集和预执行写集。主节点1在完成对每个交易的预执行之后，可将该交易的标识顺序存储到交易队列中，以用于指示该交易的预执行顺序。在一种实施方式中，预执行读集中可包括外部账户的读集和合约变量的读集，所述合约变量为在合约中定义的变量，预执行写集中可包括外部账户的写集和合约变量的写集，从而可以分别对状态树和合约状态树中的状态进行更新，其中合约状态树为由合约中的变量的状态构成的树状数据。
在步骤S303，主节点1生成共识提议，该共识提议中包括多个交易的预执行读写集和预执行顺序。
主节点1可基于多个交易的预执行读写集和预执行顺序生成共识提议以发起共识，该共识提议中例如包括多个交易各自的预执行读写集和该多个交易的预执行顺序，其中，共识提议中的各个交易例如以该交易的哈希值作为交易标识。可以理解，在本说明书实施例中，共识提议中不限于包括多个交易的预执行读写集和预执行顺序，例如，在不限定从节点根据预执行顺序执行多个交易的情况中，在共识提议中可以仅包括多个交易的预执行读写集。
在步骤S305，主节点1将共识提议发送给从节点，以进行对共识提议的共识。
在步骤S307,从节点2根据多个交易的预执行读写集，获取多个交易访问的区块链中的变量和/或账户的信息。
从节点2可根据多个交易访问的区块链中的变量和/或账户的信息来确定多个交易之间的关联度，从而根据关联度的大小来确定采用什么方法对多个交易进行分组。
在一种实施方式中，可根据多个交易中的各个交易的冲突交易的数量来确定多个交易的关联度。例如，如果某个交易的冲突交易的数目超过预定阈值，则可认为多个交易的关联度超过阈值。或者如果所述多个交易的冲突交易的数目的总和超过预定阈值时，可认为多个交易的关联度超过阈值。
在另一种实施方式中，可根据多个交易中访问各个key的交易数目来确定多个交易的关联度。例如，如果访问某个key的交易数目超过预定阈值，则可认为多个交易的关联度超过阈值。或者如果访问各个key的交易数目的总和超过预定阈值时，可认为多个交易的关联度超过阈值。
在另一种实施方式中，可根据多个交易中访问各个key的交易数目与多个交易的交 易数的比例来确定多个交易的关联度。例如，如果访问某个key的交易数目与多个交易的交易数的比例超过预定阈值，则可认为多个交易的关联度超过阈值。
在另一种实施方式中，可根据多个交易中访问的合约和/或外部账户的数目来确定多个交易的关联度。例如，如果多个交易中访问的合约和/或外部账户的数目超过预设阈值，则可认为多个交易的关联度超过阈值。
可以理解，本说明书实施例中不限于通过上述几种实施方式来确定多个交易之间的关联度，例如还可以结合上述任意两个以上的上述实施方式，来确定多个交易的关联度
在步骤S309，从节点2根据变量和/或账户的信息确定分组算法。
从节点2在如上所述确定多个交易的关联度超过阈值时，可使用并查集算法对该多个交易进行分组，从而避免DAG算法中在并行执行交易过程中对DAG图中位于交叉点的交易的等待，提高并行执行效率，反之可使用DAG算法对多个交易进行分组，以相比于并查集算法提高多个交易的并行执行的程度。可以理解，本说明书实施例不限于在包括DAG算法和并查集算法的集合中选择分组算法，该分组算法集合还可以包括本领域技术人员知道的任意其他分组算法。从节点2类似地可根据该其他分组算法的适用场景，根据所述变量和/或账户的信息确定是否采用该其他分组算法。
在步骤S311，从节点2使用确定的算法对多个交易进行分组。
从节点2在确定出分组算法之后，适用该分组算法对多个交易进行分组，得到多个交易组。其中，对于通过DAG算法分组得到多个交易组，使得其中一个交易组中的多个交易与另一个交易组中的多个交易在DAG图中是分离的，即没有任一连接边，从而使得可以并行处理各个交易组。单个交易组中的交易可根据其DAG关系串行或并行执行，例如如图2所示。
对于通过并查集算法分组得到的多个交易组，该多个交易组中的每两个交易组中互不冲突，即一个交易组中任一交易不与另一个交易组中的任一交易访问相同的变量或账户，因此，该多个交易组可并行执行。单个交易组中的多个交易根据其预执行顺序排列，以按照其预执行顺序串行执行。
在步骤S313，从节点2根据分组结果并行执行多个交易，得到各个交易的执行读写集。
从节点2中在得到分组结果之后，可根据共识提议中各个交易的哈希值从所接收的交易中获取共识提议中提议的多个交易，可使用多个线程或进程根据分组结果并行执行多个交易，得到多个交易的执行读写集。该执行读写集中包括执行读集和执行写集。与预执行类似地，所述执行读集包括该交易在执行中读取的变量的键值对，执行写集包括交易在执行中写入的变量的键值对。
在步骤S315，从节点2比较交易的预执行读写集与执行读写集是否一致。
从节点2在每执行完成一个交易之后都可以比较该交易的预执行读写集与执行读写集是否一致。在确定该交易的预执行读写集与执行读写集一致的情况中，从节点2可基于该交易的执行写集在内存中更新执行写集中的变量的世界状态，以使得后续涉及该变量的交易在执行时可从内存中读取该变量的世界状态。
在确定多个交易的预执行读写集与执行读写集都一致时，从节点2可确认主节点 1没有作恶，多个交易的预执行读写集是正确的，因此，基于该预执行读写集的分组也是正确的，因此，在该分组下并行执行多个交易得到的交易执行结果也是正确的。从节点2从而可以根据多个交易的执行写集更新世界状态，生成并存储区块。
从节点2在确定该交易的预执行读写集与执行读写集不一致时，可确定主节点1存在作恶的行为，因此可终止对该多个交易的执行，与其他从节点进行用于更换主节点的操作。
图4为本说明书另一实施例中的对交易进行分组的方法流程图。该方法可由图1中的主节点和从节点执行，图4中示出主节点1和从节点2作为示例。
图4所示的步骤S401可参考上文对步骤S301的描述，在此不再赘述。
图4所示方法与图3所示方法不同在于，由主节点1执行步骤S403～步骤S407,代替由从节点2执行步骤S307～S311,从而由主节点1根据多个交易的预执行读写集获取多个交易访问的区块链中的变量和/或账户的信息，根据所述变量和/或账户的信息确定分组算法，并使用该分组算法对多个交易进行分组。通过这样，减少了多个从节点的计算量，节省了从节点的计算资源。
在步骤S409，主节点1生成共识提议，共识提议中包括预执行读写集、预执行顺序和分组结果。
通过在共识提议中包括分组结果，使得各个从节点可使用共识提议中主节点的签名对该共识提议进行验证，从而确保分组结果未经篡改。
步骤S411～S415可参考上文对步骤S305、S313和步骤S315的描述，在此不再赘述。
图5为本说明书实施例中的区块链节点的架构图。如图5所示，图1所示区块链中的主节点1和各个从节点(例如图5中示出的从节点2)中均可运行多个进程以提供多种服务。具体是，主节点1中可包括用于提供缓存服务的缓存进程12、用于提供预执行服务的预执行进程111和预执行进程112、用于提供共识服务的共识进程13、用于提供区块管理服务的区块管理进程14等。所述预执行进程111和预执行进程112用于并行进行对主节点接收的交易的预执行。可以理解，本说明书实施例中，主节点1中不限于包括两个预执行进程，而是可包括一个预执行进程或者三个以上的预执行进程。此外，主节点1中还可以包括用于提供接入服务的接入进程、用于提供网络服务的网络进程、用于提供存储服务的存储进程等，图5中未示出。
从节点2中可包括用于提供缓存服务的缓存进程21、用于提供共识服务的共识进程22、用于提供区块管理服务的区块管理进程23、用于提供交易执行服务的计算进程241和计算进程242等。所述计算进程241和计算进程242用于并行进行对共识提议中的交易的执行。可以理解，本说明书实施例中，从节点2中不限于包括两个计算进程，而是可包括一个计算进程或者三个以上的计算进程。
其中进程是应用中具有一定独立功能的程序关于一个数据集合的一次运行活动，即进程是计算机中通过由CPU顺序执行应用程序中的指令而进行的一个过程。每个进程在创建时被分配自己的内存地址空间，该内存地址空间只能被进程自身访问。例如，预执行进程111被分配了内存113，预执行进程112被分配了内存114，缓存进程12被分配了内存120，缓存进程21被分配了内存210，计算进程241被分配了内存243，计算进程242被分配了内存244。
其中，主节点1中的多个进程可以为多个计算设备(或虚拟计算节点)中的多个进程，也可以为单个计算设备中的多个进程。类似地，各个从节点中的多个进程可以为多个计算设备(或虚拟计算节点)中的多个进程，也可以为单个计算设备中的多个进程。此外需要说明的是本说明书实施例提供的方案并不局限于主从架构的区块链系统。
图6为本说明书实施例中的在区块链中执行交易的方法流程图。该方法可由图2中的主节点1执行。
如图6所示，首先，在步骤S601，主节点1中的缓存进程12向预执行进程111发送多个交易。
如上文所示，主节点1中除了包括图2中所示的各个进程以外，还可以包括接入进程，该接入进程可从用户设备接收交易，并将接收的交易发送给缓存进程12，从而缓存进程12将从接入进程接收的交易按一定的顺序存储到缓存进程12的内存120中。例如，缓存进程12可按照接收交易的时间顺序存储交易，例如将接收的交易顺序存储到内存120中存储的交易队列中。
主节点1中还可以包括网络进程(图2中未示出)，缓存进程12在接收到多个交易之后，可将该多个交易发送给网络进程，从而网络进程将该多个交易广播给区块链中的其他节点。
同时，对于每个预执行进程(包括预执行进程111和预执行进程112)，缓存进程12可定期将交易队列中的预设数目的一批交易发送给该预执行进程，以使得各个预执行并行预执行交易队列中的交易。其中，缓存进程12可以将该批交易在交易队列中的排列顺序也发送给预执行进程，从而预执行进程可根据该交易队列中的排列顺序串行执行该批交易。
在步骤S603，预执行进程111预执行多个交易，得到各个交易的预执行读写集。
预执行进程111在从缓存进程12接收到多个交易之后，可首先对各个交易的签名进行验证，在验证通过之后，进行对所述多个交易的预执行。预执行进程111串行执行接收到的多个交易，例如，预执行进程111可按照接收到的多个交易的排列顺序串行执行多个交易。
在本说明书实施例中，内存113中可存储区块链中的部分变量的状态集，该部分变量包括区块链账户或者合约中定义的变量。预执行进程111在预执行交易的过程中读取或写入变量时，可更新本地缓存的状态集。
预执行进程111在预执行多个交易之后，得到多个交易各自的预执行读写集和多个交易的预执行顺序。
缓存进程12的内存120中存储有区块链中的部分变量的状态集，该状态集的更新可参考图6中后续步骤的描述。各个预执行进程在预执行交易的过程中读取变量时，首先确定预执行进程本地存储的状态集中是否包括该变量的值，如果没有，再确定缓存进程的内存中的状态集中是否包括该变量的值，如果还是没有，则从状态数据库读取该变量的值，并将该读取的变量的值存储到预执行进程本地的状态集中。
具体是，该多个交易中例如包括交易Tx3。假设交易Tx3中包括对变量a的读取操作，对变量b的写入操作，预执行进程111在执行交易Tx3中的对变量a的读取操作时，首先确定预执行进程111的内存113中是否存储了变量a的值，在内存113中存储变量a的值的 情况中，可以基于该变量a的值完成对交易Tx3的预执行，生成交易Tx3的预执行读写集，例如，交易Tx3的预执行读集中包括变量a的键值对，预执行写集中包括变量b的键值对。在生成交易Tx3的预执行读写集中，预执行进程111基于交易Tx3的写集更新内存113中的状态集，在该状态集中存储交易Tx3在预执行中写入的变量b的值。
在另一种情况中，预执行进程111在确定内存113中的状态集中不包括变量a的值的情况中，可向缓存进程12请求读取变量a的值。缓存进程12在接收到该请求之后，确定内存120中的状态集中是否包括变量a的值，如果包括，则将该变量a的值发送给预执行进程111。预执行进程111可在接收到变量a的值之后，将该变量a的值存储到内存113中的状态集中，从而可用于执行后续的读取变量a的其他交易。如果内存120中的状态集中不包括变量a的值，则缓存进程12通知预执行进程111，预执行进程111从而从状态数据库中读取当前变量a的值，其中，状态数据库中存储有已执行完成的区块对应的世界状态。主节点1中例如还包括存储进程，预执行进程11例如可向存储进程发送读取变量a的请求，存储进程在接收到该请求之后，在状态数据库中读取变量a的值，并将变量a的值返回给预执行进程111。预执行进程111在从存储进程接收到变量a的值之后，类似地，将变量a的值存储到第一状态集中。预执行进程111通过将从内存113的外部读取的变量a的值存储到内存113中，使得预执行进程111在下次执行交易中读取变量a时，可直接从本地内存中读取到变量a的值，从而提高了交易执行速度。
预执行进程111在执行完成每个交易之后，还生成各个交易的交易收据。
在步骤S605，预执行进程111将多个交易的预执行读写集和预执行顺序发送给缓存进程12。
预执行进程111在如上所述完成对多个交易的预执行之后，将得到的多个交易的预执行读写集和预执行顺序一起发送给缓存进程12。另外，预执行进程111还将各个交易的交易收据发送给缓存进程12，以存储到内存120中。
在步骤S607，缓存进程12基于多个交易的预执行读写集更新本地状态。
缓存进程12在接收到多个交易的预执行读写集和预执行顺序之后，在主节点中只有一个预执行进程的情况中，由于预执行进程在首次读取一个变量时都是从存储进程接收变量值进行交易的预执行，并串行预执行多个交易，并随着各个交易的预执行更新预执行进程本地的状态集，再通过多个交易的预执行读写集来更新内存120中的状态集，因此，在将执行阶段的交易排列顺序设定为与该预执行顺序相同时，将使得各个交易的预执行读写集与执行读写集一致，因此，基于预执行读写集更新的内存113中的状态集也即为主节点1中的最新世界状态。缓存进程12可信任该多个交易的预执行读写集，并可直接基于该预执行读写集更新内存120中的状态集。在更新之后，内存120中的状态集也成为主节点1中的最新世界状态。
在主节点中有多个预执行进程(例如图2中的预执行进程111和预执行进程112)的情况中，两个预执行进程在并行预执行交易的过程中有可能同时对相同的变量进行读或写操作，从而可能导致其中一个交易的预执行结果不是基于主节点1中当前最新世界状态得到的，从而导致交易的预执行读写集与交易的执行读写集的不一致。
为此，缓存进程12在从预执行进程111接收到多个交易的预执行读写集之后，可顺序对每个交易的预执行读写集进行检测。具体是，例如对于交易Tx3，缓存进程12 首先确定内存120中的状态集中是否包括交易Tx3的预执行读集中的变量a。如果没有，再类似地确定第二状态集中是否包括交易Tx3的预执行读集中的其他变量。如果内存120中的状态集中不包括交易Tx3的预执行读集中的全部变量，也就是说，之前提交到缓存进程12的交易还未对该交易Tx3读取的变量进行读写，则可确定交易Tx3的预执行读集与内存120中的状态集没有冲突。
如果缓存进程12确定内存120中的状态集中包括变量a的值，则确定预执行读集中的变量a的值与内存120中的状态集中的变量a的值是否一致，如果一致，说明该交易Tx3读取的变量a的值为预执行过程中变量a的最新状态。当缓存进程12对于交易Tx3预执行读集中的每个变量都确定所读取的值为预执行过程中的最新状态之后，可确定该交易Tx3的预执行读集与内存120中的状态集不存在冲突。在顺序确定多个交易的预执行读集与内存120中的状态集都不存在冲突的情况中，可基于该多个交易的预执行读写集更新内存120中的状态集。
如果缓存进程12确定交易Tx3的预执行读集中的变量a的值与内存120中的状态集中的变量a的值不一致，说明该交易Tx3读取的变量a的值不是预执行过程中的最新状态，因此，可确定交易Tx3的预执行读集与第二状态集存在冲突。在确定存在冲突的情况中，缓存进程12可指示预执行进程111对交易Tx3及在交易Tx3之后预执行的其他交易重新进行预执行。
另外，缓存进程12在接收到多个交易的预执行读写集和预执行顺序之后，可在内存120中存储该多个交易的预执行读写集，并在交易队列中按照该多个交易的预执行顺序存储该多个交易的标识，以指示该多个交易的预执行顺序。
在步骤S609，缓存进程12向共识进程13发送多个交易的预执行读写集和预执行顺序。
共识进程13定期调用缓存进程12提供的接口向缓存进程12请求获取待共识的一批交易进行共识。缓存进程12响应于该请求向共识进程13发送多个交易的预执行读写集及该多个交易的排列顺序，该排列顺序即为该多个交易的预执行顺序。其中，缓存进程12可与各个交易的哈希值关联地发送各个交易的预执行读写集。缓存进程12也可以在内存120中存储的交易的预执行读写集达到一定数据量时、或者在内存120中存储的交易的预执行读写集达到一定数量时向共识进程发送多个交易的预执行读写集及其预执行顺序。
在步骤S611，共识进程13生成共识提议，进行与其他节点的共识。
不同类型的区块链网络中，为了在各个记录账本的节点中保持账本的一致，通常采用共识算法来保证，即共识机制。例如，区块链节点之间可以实现区块粒度的共识机制，比如在节点(例如某个独特的节点)产生一个区块后，如果产生的这个区块得到其它节点的认可，其它节点记录相同的区块。再例如，区块链节点之间可以实现交易粒度的共识机制，比如在节点(例如某个独特的节点)获取一笔区块链交易后，如果这笔区块链交易得到其他节点的认可，认可该区块链交易的各个节点可以分别将该区块链交易添加至自身维护的最新区块中，并且最终能够确保各个节点产生相同的最新区块。共识机制是区块链节点就区块信息(或称区块数据)达成全网一致共识的机制，可以保证最新区块被准确添加至区块链。当前主流的共识机制包括：工作量证明 (Proof of Work，POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)算法等。其中，在各种共识算法中，通常在预设数目的节点对待共识的数据(即共识提议)达成一致之后，从而确定对该共识提议的共识成功。具体是，在PBFT算法中，对于N≥3f+1个共识节点，可容忍f个恶意节点，也就是说，当N个共识节点中2f+1个节点达成一致时，可确定共识成功。
具体是，共识进程13可生成共识提议，该共识提议中包括多个交易的预执行读写集及其预执行顺序，其中，该共识提议中的各个交易可以以该交易的哈希值进行标识。
在一种实施方式中，共识进程13可执行如图4所示的方法中的步骤S403～S409，以生成共识提议。
在步骤S613，共识进程13将共识提议发送给区块管理进程14。
共识进程13在生成共识提议之后，可将共识提议发送给区块管理进程14。
在步骤S615，区块管理进程14生成并提交区块。
由于主节点信任自身的预执行没有作恶，并且主节点中对交易的预执行是根据正确的世界状态进行的，如果主节点再次依据状态数据库中的世界状态重新执行该多个交易，所得到的该多个交易的执行读写集与该多个交易的预执行读写集必然是一致的。因此，区块管理进程14可以直接将该多个交易的预执行读写集视为执行读写集，用来更新状态数据库中的世界状态，而不需要重新执行一次该多个交易。
从而，区块管理进程14可根据共识提议中多个交易的预执行读写集中的写集和预执行顺序顺序更新世界状态中各个账户和各个合约变量的状态，根据更新的世界状态更新状态树中各个节点的值，包括状态根((即状态树的根节点的哈希值))。区块管理进程14还可以从缓存进程13获取该多个交易各自的交易体和交易收据，并分别生成多个交易的交易树的交易根(即交易树的根节点的哈希值)和收据树的收据根(即收据树的根节点的哈希值)。
然后，区块管理进程14可生成包括所述多个交易的区块(例如区块B1)，该区块B1可包括区块体和区块头，其中，区块头中可以包括区块号、交易根、状态根、收据根等信息，区块体可以包括各个交易的交易体集合和收据集合。区块管理进程14在生成区块之后，可提交该区块，以存储到图2中主节点1的区块数据库。例如，区块管理进程14可将该区块发送给存储进程，以使得存储进程在区块数据库中存储该区块。
其中，由于主节点信任自身的预执行读写集，因此，区块管理进程14可以在从共识进程13接收到共识提议之后立即进行对世界状态的更新和对区块的生成、提交操作。可以理解，区块管理进程14也可以在从共识进程13接收到共识成功的信息之后进行对世界状态的更新和对区块的生成、提交操作。
图7为本说明书实施例中的在区块链中执行交易的方法流程图。该方法可由图2中的从节点2执行。
如图7所示，首先，在步骤S701，从节点2中的共识进程22与区块链中的其他节点进行共识。
与主节点1类似的，从节点2中也可以包括接收进程和网络进程(图2中未示出)，从节点2可通过接收进程从用户设备接收到交易，可通过网络进程接收到其他节点发送 的交易。接收进程和网络进程在接收到交易之后将交易发送给缓存进程21，从而缓存进程21可在内存210以交易队列的形式存储接收的交易。与主节点1类似的，缓存进程21也可以将交易队列中的交易发送给网络进程，以广播给区块链中的其他节点。
主节点1中的网络进程将共识提议及主节点1的签名发送给其他各个节点的网络进程，从而从节点2中的网络进程可接收到该共识提议及主节点1的签名，并将该共识提议及主节点1的签名发送给共识进程22。共识进程22在接收到共识提议及其签名之后，开始进行共识过程。
在步骤S703，共识进程22将共识提议发送给区块管理进程23。
共识进程22在接收到共识提议之后，在对主节点的签名验证通过之后，就可以将该共识提议发送给区块管理进程23。
在步骤S705，区块管理进程23根据共识提议对多个交易进行分组，将多个组分配给多个计算进程。
区块管理进程23可通过图3所示方法确定对多个交易进行分组的分组算法。
之后，区块管理进程23可使用确定的分组算法根据共识提议中的预执行读写集对该多个交易进行分组，使得每两个分组中的全部交易不会访问相同的变量，从而使得各个分组可以并行执行，每个组中的多个交易按照其预执行顺序进行排列。
在完成分组之后，区块管理进程23可将分组得到的多个组均匀分给多个计算进程。例如在从节点2中仅包括计算进程241和计算进程242的情况中，可以将多个组中的一半数量的组分给计算进程241，将另一半数量的组分给计算进程242。
可以理解，本说明书实施例中不限于由区块管理进程23进行对多个交易的分组，例如，也可以由共识进程22根据多个交易的预执行读写集对对多个交易进行分组，并将共识提议和分组结果发送给区块管理进程23。
在步骤S707，区块管理进程23将分配给各个进程的组和组内各个交易的预执行读写集发送给各个进程。
在步骤S709，计算进程执行交易，更新状态数据库。
以计算进程241为例，区块管理进程23可以对计算进程241分配一个或多个组。在区块管理进程23对计算进程241分配多个组的情况中，计算进程241中可通过多个线程并发处理多个组。同时，计算进程241按照一个组中多个交易的预执行顺序串行执行一个组中的多个交易。
另外，如图2所示，计算进程241中包括内存243，计算进程241在开始执行多个组的交易之前，可根据多个组中的全部交易的读集，确定需要读取的全部变量，并从状态数据库进行对该全部变量的批量地(例如一次性地)读取，在读取到全部变量的状态(即世界状态)之后，进程241可以将该全部变量的值以键值对的形式存储到内存243中的状态集中。然后，计算进程241可基于内存243中的状态集执行各个组中的交易。计算进程241在根据交易执行读取变量的操作时，从内存243中的状态集中读取变量的值，在根据交易执行写入变量的操作时，将内存243中的状态集中该变量的值更新为此次写入的值，并据此生成交易的执行读写集。与预执行读写集类似地，执行读写集中包括执行读集和执行写集。执行读集中例如包括交易在执行过程中读取的变量的键值对，执行写集中例如包括交易在执行过程中写入的变量的键值对。通过批量预读的方 式，计算进程241预先将需要从状态数据库读取的参数存储到本地的内存243中，从而计算进程241在执行交易的过程中可直接从内存中读取状态，而不需要从存储中读取状态，大大加快了交易执行速度。
由于各个组彼此不访问相同的变量，即不存在冲突交易，因此，计算进程241在完成对一个组中的全部交易的执行之后，可立即根据该组的各个交易的执行写集更新状态数据库中的世界状态，而不会影响其他组的交易执行。同时提高了交易执行速度。
在步骤S711，区块管理进程23生成并提交区块。
区块管理进程23在确定各个计算进程都完成对分配给其的组的交易执行和状态更新之后，根据更新的世界状态更新状态树中各个节点的值，包括状态根((即状态树的根节点的哈希值))。区块管理进程23还可以从缓存进程21获取多个交易各自的交易体和交易收据，并分别生成多个交易的交易树的交易根(即交易树的根节点的哈希值)和收据树的收据根(即收据树的根节点的哈希值)。
然后，区块管理进程23可生成包括所述多个交易的区块(例如区块B1)，该区块B1可包括区块体和区块头，其中，区块头中可以包括区块号、交易根、状态根、收据根等信息，区块体可以包括各个交易的交易体集合和收据集合。区块管理进程23在生成区块之后，可提交该区块，以存储到图2中从节点2的区块数据库。
通过上述过程，在实现了区块链中各个节点的存储一致性的同时，利用区块链节点中多进程的架构，可使用多进程架构的优势进一步加快交易的执行速度，提高了区块链的系统效率。
图8为本说明书实施例中的一种区块链节点的架构图，包括：
获取单元81，用于获取多个交易的预执行读写集；根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息；
确定单元82，用于根据所述信息确定对所述多个交易进行分组的算法。
在一种实施方式中，所述确定单元82具体用于：根据所述信息确定所述多个交易之间的关联程度，在确定所述关联程度高于预设阈值时，确定使用并查集算法对所述多个交易进行分组，在确定所述关联程度低于预设阈值时，确定使用DAG算法对所述多个交易进行分组。
在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 (12)

  1. 一种对多个交易进行分组的方法，由区块链节点执行，包括：
    获取多个交易的预执行读写集；
    根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息；
    根据所述信息确定对所述多个交易进行分组的算法。
  2. 根据权利要求1所述的方法，所述根据所述信息确定对所述多个交易进行分组的算法包括：根据所述信息确定所述多个交易之间的关联程度，在确定所述关联程度高于预设阈值时，确定使用并查集算法对所述多个交易进行分组，在确定所述关联程度低于预设阈值时，确定使用DAG算法对所述多个交易进行分组。
  3. 根据权利要求1或2所述的方法，所述信息包括以下至少一项信息：
    所述多个交易中各个交易的冲突交易的数目；
    所述多个交易中访问相同变量或账户的第一交易的第一数目；
    所述多个交易访问的外部账户的数目；
    所述多个交易访问的合约的数目；
    所述第一数目与所述多个交易的交易数的比值。
  4. 根据权利要求1或2所述的方法，所述方法由区块链中的主节点执行，所述方法还包括，根据所述确定的算法对所述多个交易进行分组，生成共识提议，所述共识提议中包括所述多个交易的预执行读写集、预执行顺序和分组结果。
  5. 根据权利要求4所述的方法，所述主节点中包括预执行进程、缓存进程和第一共识进程，所述获取多个交易的预执行读写集包括：所述预执行进程预执行接收的多个交易，得到多个交易的预执行读写集，将所述多个交易的预执行读写集发送给所述缓存进程，
    所述根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息，根据所述信息确定对所述多个交易进行分组的算法包括：所述第一共识进程从所述缓存进程接收多个交易的预执行读写集，根据所述多个交易的预执行读写集获取所述多个交易访问的区块链中的变量和/或账户的信息，根据所述信息确定对所述多个交易进行分组的算法。
  6. 根据权利要求1或2所述的方法，所述方法由区块链中的从节点执行，所述获取多个交易的预执行读写集包括，从所述区块链中的主节点接收共识提议，所述共识提议包括所述多个交易的预执行读写集，
    所述方法还包括，根据所述确定的算法对所述多个交易进行分组，根据所述多个交易的分组结果并行执行所述多个交易，得到所述多个交易的执行读写集。
  7. 根据权利要求6所述的方法，所述从节点包括第二共识进程、区块管理进程和多个计算进程，所述从所述区块链中的主节点接收共识提议包括：第二共识进程从所述区块链的主节点接收共识提议，以进行对共识提议的共识；
    根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息；根据所述信息确定对所述多个交易进行分组的算法，根据所述确定的算法对所述多个交易进行分组包括：所述区块管理进程从所述第二共识进程接收所述 多个交易的预执行读写集，根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息；根据所述信息确定对所述多个交易进行分组的算法，根据所述确定的算法对所述多个交易进行分组；
    根据所述多个交易的分组结果并行执行所述多个交易包括：所述计算进程从所述区块管理进程接收所述多个交易的分组结果，根据所述多个交易的分组结果并行执行所述多个交易。
  8. 根据权利要求6所述的方法，所述预执行读写集基于在预执行交易时的世界状态生成，所述共识提议还包括所述多个交易的预执行顺序，所述根据所述多个交易的分组结果并行执行所述多个交易包括：根据所述多个交易的分组结果和预执行顺序并行执行所述多个交易；
    所述方法还包括，对于每个交易比较所述交易的预执行读写集与所述执行读写集，在确定所述多个交易中各个交易的预执行读写集与所述执行读写集都一致的情况中，确定所述主节点未作恶。
  9. 一种区块链节点，包括：
    获取单元，用于获取多个交易的预执行读写集；根据所述多个交易的预执行读写集，获取所述多个交易访问的区块链中的变量和/或账户的信息；
    确定单元，用于根据所述信息确定对所述多个交易进行分组的算法。
  10. 根据权利要求9所述的区块链节点，所述确定单元具体用于：根据所述信息确定所述多个交易之间的关联程度，在确定所述关联程度高于预设阈值时，确定使用并查集算法对所述多个交易进行分组，在确定所述关联程度低于预设阈值时，确定使用DAG算法对所述多个交易进行分组。
  11. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1-8中任一项的所述的方法。
  12. 一种区块链节点，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-8中任一项所述的方法。
PCT/CN2022/135664 2022-05-30 2022-11-30 对多个交易进行分组的方法和区块链节点 WO2023231345A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210602791.XA CN114827165B (zh) 2022-05-30 2022-05-30 对多个交易进行分组的方法和区块链节点
CN202210602791.X 2022-05-30

Publications (1)

Publication Number Publication Date
WO2023231345A1 true WO2023231345A1 (zh) 2023-12-07

Family

ID=82518905

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135664 WO2023231345A1 (zh) 2022-05-30 2022-11-30 对多个交易进行分组的方法和区块链节点

Country Status (2)

Country Link
CN (1) CN114827165B (zh)
WO (1) WO2023231345A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112292704A (zh) * 2018-04-19 2021-01-29 唯链基金会有限公司 交易处理
CN117422468A (zh) * 2023-12-18 2024-01-19 安徽中科晶格技术有限公司 基于dag模型的合约链合约并行化方法、设备及存储介质

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114942847A (zh) * 2022-05-30 2022-08-26 蚂蚁区块链科技(上海)有限公司 执行交易的方法和区块链节点
CN114827165B (zh) * 2022-05-30 2024-01-23 蚂蚁区块链科技(上海)有限公司 对多个交易进行分组的方法和区块链节点
CN117893314A (zh) * 2023-02-08 2024-04-16 苏州双福智能科技有限公司 一种采用区块链交易执行方法及分析系统
CN118093613B (zh) * 2024-03-21 2024-08-30 杭州高新区(滨江)区块链与数据安全研究院 数据交互处理方法、区块构建节点、终端设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200250747A1 (en) * 2019-01-31 2020-08-06 Salesforce.Com, Inc. Systems, methods, and apparatuses for dynamically assigning nodes to a group within blockchains based on transaction type and node intelligence using distributed ledger technology (dlt)
CN112602076A (zh) * 2018-08-24 2021-04-02 甲骨文国际公司 分布式分类账中基于dag的交易处理方法和系统
CN113743940A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN114827165A (zh) * 2022-05-30 2022-07-29 蚂蚁区块链科技(上海)有限公司 对多个交易进行分组的方法和区块链节点

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104536804A (zh) * 2014-12-23 2015-04-22 西安电子科技大学 面向关联任务请求的虚拟资源调度系统及调度和分配方法
US10380185B2 (en) * 2016-02-05 2019-08-13 Sas Institute Inc. Generation of job flow objects in federated areas from data structure
US10726501B1 (en) * 2017-04-25 2020-07-28 Intuit Inc. Method to use transaction, account, and company similarity clusters derived from the historic transaction data to match new transactions to accounts
CN107423961B (zh) * 2017-07-11 2024-06-14 北京泛融科技有限公司 一种基于随机相关性分析的优化共识方法
GB2583993B (en) * 2018-11-19 2023-08-02 Luther Systems Ltd Immutable ledger with efficient and secure data destruction, system and method
CN110727712B (zh) * 2019-10-15 2021-06-04 腾讯科技（深圳）有限公司 基于区块链网络的数据处理方法、装置、电子设备及存储介质
CN111124695B (zh) * 2019-11-25 2023-05-16 支付宝(杭州)信息技术有限公司 一种动效管理方法、系统及设备
US11416867B2 (en) * 2020-05-06 2022-08-16 Accenture Global Solutions Limited Machine learning system for transaction reconciliation
CN114071582A (zh) * 2021-10-14 2022-02-18 北京邮电大学 面向云边协同物联网的服务链部署方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112602076A (zh) * 2018-08-24 2021-04-02 甲骨文国际公司 分布式分类账中基于dag的交易处理方法和系统
US20200250747A1 (en) * 2019-01-31 2020-08-06 Salesforce.Com, Inc. Systems, methods, and apparatuses for dynamically assigning nodes to a group within blockchains based on transaction type and node intelligence using distributed ledger technology (dlt)
CN113743940A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN114827165A (zh) * 2022-05-30 2022-07-29 蚂蚁区块链科技(上海)有限公司 对多个交易进行分组的方法和区块链节点

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112292704A (zh) * 2018-04-19 2021-01-29 唯链基金会有限公司 交易处理
CN112292704B (zh) * 2018-04-19 2024-02-27 唯链基金会有限公司 交易处理
CN117422468A (zh) * 2023-12-18 2024-01-19 安徽中科晶格技术有限公司 基于dag模型的合约链合约并行化方法、设备及存储介质
CN117422468B (zh) * 2023-12-18 2024-03-29 安徽中科晶格技术有限公司 基于dag模型的合约链合约并行化方法、设备及存储介质

Also Published As

Publication number Publication date
CN114827165A (zh) 2022-07-29
CN114827165B (zh) 2024-01-23

Similar Documents

Publication Publication Date Title
WO2023231345A1 (zh) 对多个交易进行分组的方法和区块链节点
WO2023231336A1 (zh) 执行交易的方法和区块链节点
US8381230B2 (en) Message passing with queues and channels
WO2024001024A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
WO2023160083A1 (zh) 执行交易的方法、区块链、主节点和从节点
WO2023160085A1 (zh) 执行交易的方法、区块链、主节点和从节点
WO2019085601A1 (zh) 一种任务执行的方法及装置
CN113743940A (zh) 在区块链中执行交易的方法、区块链、主节点和从节点
WO2023231337A1 (zh) 在区块链中执行交易的方法、区块链的主节点和从节点
WO2023231335A1 (zh) 在区块链中执行交易的方法及区块链的主节点
CN114936256A (zh) 在区块链中执行交易的方法和区块链节点
JP2016504696A (ja) 分散コンピューティングアーキテクチャ
CN110569112B (zh) 日志数据写入方法及对象存储守护装置
US20240220334A1 (en) Data processing method in distributed system, and related system
WO2024001025A1 (zh) 一种预执行缓存数据清理方法和区块链节点
WO2024001032A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
CN107102898B (zh) 一种基于numa架构的内存管理、构建数据结构的方法及装置
EP4421653A1 (en) Data query request processing method and apparatus, device and storage medium
Shrivastava et al. Supporting transaction predictability in replicated DRTDBS
Smolinski Impact of storage space configuration on transaction processing performance for relational database in PostgreSQL
CN116707891A (zh) 重放攻击检查方法和区块链节点
Cicotti et al. Data movement in data-intensive high performance computing
WO2018188416A1 (zh) 一种数据搜索的方法、装置和相关设备
US10310889B1 (en) Data statistics service
US20240231937A1 (en) Shared memory fabric workload performance system

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: 22944646

Country of ref document: EP

Kind code of ref document: A1