WO2023231345A1 - Procédé de regroupement d'une pluralité de transactions, et nœud de chaîne de blocs - Google Patents

Procédé de regroupement d'une pluralité de transactions, et nœud de chaîne de blocs 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)
Chinese (zh)
Inventor
林鹏
Original Assignee
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2023231345A1 publication Critical patent/WO2023231345A1/fr

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

Procédé de regroupement d'une pluralité de transactions, et nœud de chaîne de blocs. Le procédé est exécuté par un nœud de chaîne de blocs, et consiste : à acquérir un ensemble lecture-écriture de pré-exécution d'une pluralité de transactions ; en fonction de l'ensemble lecture-écriture de pré-exécution de la pluralité de transactions, à acquérir des informations de variables et/ou de comptes dans une chaîne de blocs auxquelles la pluralité de transactions accède ; et en fonction des informations, à déterminer un algorithme de regroupement de la pluralité de transactions.
PCT/CN2022/135664 2022-05-30 2022-11-30 Procédé de regroupement d'une pluralité de transactions, et nœud de chaîne de blocs WO2023231345A1 (fr)

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 (fr) 2023-12-07

Family

ID=82518905

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135664 WO2023231345A1 (fr) 2022-05-30 2022-11-30 Procédé de regroupement d'une pluralité de transactions, et nœud de chaîne de blocs

Country Status (2)

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

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
CN114827165B (zh) * 2022-05-30 2024-01-23 蚂蚁区块链科技(上海)有限公司 对多个交易进行分组的方法和区块链节点
CN114942847A (zh) * 2022-05-30 2022-08-26 蚂蚁区块链科技(上海)有限公司 执行交易的方法和区块链节点
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的交易处理方法和系统
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN113743940A (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 北京泛融科技有限公司 一种基于随机相关性分析的优化共识方法
US11860822B2 (en) * 2018-11-19 2024-01-02 Luther Systems Us Incorporated 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)
CN113743941A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 一种在区块链中执行交易的方法、区块链和主节点
CN113743940A (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
CN114827165B (zh) 2024-01-23
CN114827165A (zh) 2022-07-29

Similar Documents

Publication Publication Date Title
WO2023231345A1 (fr) Procédé de regroupement d'une pluralité de transactions, et nœud de chaîne de blocs
WO2023231336A1 (fr) Procédé d'exécution de transaction et nœud de chaîne de blocs
US8381230B2 (en) Message passing with queues and channels
WO2024001024A1 (fr) Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs
WO2023160083A1 (fr) Procédé d'exécution de transactions, blockchain, nœud maître et nœud esclave
WO2023160085A1 (fr) Procédé d'exécution de transaction, chaîne de blocs, nœud maître et nœud esclave
CN113743940A (zh) 在区块链中执行交易的方法、区块链、主节点和从节点
WO2023231337A1 (fr) Procédé d'exécution d'une transaction dans une chaîne de blocs, et nœud maître et nœud esclave de chaîne de blocs
WO2023231335A1 (fr) Procédé d'exécution d'une transaction dans une chaîne de blocs, et nœud maître de chaîne de blocs
TW201918878A (zh) 任務執行的方法及裝置
CN114936256A (zh) 在区块链中执行交易的方法和区块链节点
JP2016504696A (ja) 分散コンピューティングアーキテクチャ
US20240265022A1 (en) Data query request processing method, electronic device, and storage medium
CN110569112B (zh) 日志数据写入方法及对象存储守护装置
US20240220334A1 (en) Data processing method in distributed system, and related system
WO2024001025A1 (fr) Procédé de nettoyage de données en mémoire cache de pré-exécution et nœud de chaîne de blocs
WO2024001032A1 (fr) Procédé d'exécution d'une transaction dans un système de chaîne de blocs, et système et nœuds de chaîne de blocs
CN107102898B (zh) 一种基于numa架构的内存管理、构建数据结构的方法及装置
Shrivastava et al. Supporting transaction predictability in replicated DRTDBS
WO2023240933A1 (fr) Procédé et appareil de déploiement d'application distribuée sur la base d'une chaîne de blocs
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
US10776344B2 (en) Index management in a multi-process environment
WO2018188416A1 (fr) Procédé et appareil de recherche de données, et dispositifs associés

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