CN117408703A - Transaction execution method, device and blockchain system - Google Patents
Transaction execution method, device and blockchain system Download PDFInfo
- Publication number
- CN117408703A CN117408703A CN202311437396.1A CN202311437396A CN117408703A CN 117408703 A CN117408703 A CN 117408703A CN 202311437396 A CN202311437396 A CN 202311437396A CN 117408703 A CN117408703 A CN 117408703A
- Authority
- CN
- China
- Prior art keywords
- transactions
- batch
- transaction
- node
- consensus
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 133
- 230000000977 initiatory effect Effects 0.000 claims abstract description 26
- 238000004364 calculation method Methods 0.000 claims description 16
- 238000003860 storage Methods 0.000 claims description 15
- 102100025682 Dystroglycan 1 Human genes 0.000 claims description 13
- 101000855983 Homo sapiens Dystroglycan 1 Proteins 0.000 claims description 13
- 125000002015 acyclic group Chemical group 0.000 claims description 3
- 230000008569 process Effects 0.000 description 74
- 238000012545 processing Methods 0.000 description 18
- 238000010586 diagram Methods 0.000 description 17
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 8
- 238000004590 computer program Methods 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 238000004422 calculation algorithm Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 238000009826 distribution Methods 0.000 description 4
- 102100030685 Alpha-sarcoglycan Human genes 0.000 description 3
- 101100224343 Arabidopsis thaliana DOF2.5 gene Proteins 0.000 description 3
- 101150019520 SGCA gene Proteins 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000001419 dependent effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 239000003999 initiator Substances 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 241000282345 Meles Species 0.000 description 1
- 241000282344 Mellivora capensis Species 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000007795 chemical reaction product Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Abstract
A transaction execution method, device and blockchain system. The transaction execution method is applied to a blockchain system comprising a first node and a second node, and comprises the following steps: the first node determines grouping result information of the first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and provides the first batch of transactions and the grouping result information to the second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node; before the second node completes the consensus, determining M transaction groups according to grouping result information and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
Description
Technical Field
The embodiment of the specification belongs to the technical field of blockchain, and particularly relates to a transaction execution method, a transaction execution device and a blockchain system.
Background
Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode is formed. Users can participate in realizing related transactions of the blockchain through the blockchain link points, for example, a plurality of blockchain nodes corresponding to different users in a blockchain system respectively can perform Secure multiparty computation (SMPC) on private data of a certain node based on privacy technologies such as homomorphic encryption, zero knowledge proof and the like. As another example, transfers may be effected between different user accounts based on a blockchain network; for another example, NFT (Non-homogeneous Token) corresponding to digital collections such as digital drawings, digital titles, GIFs, etc. may also be issued based on a blockchain network so that ownership of the digital collections carried by the NFT can be circulated among users of the blockchain network, thereby yielding a value corresponding to the digital collections.
At present, a common recognition proposal is usually initiated by any node (such as a master node in a master-slave architecture) in a blockchain system for a plurality of transactions in a certain block, and the node and other nodes (such as slave nodes) participate in common and then execute the transactions respectively. In order to increase the overall execution speed of the block (i.e. reduce the overall execution time of all transactions in the block), each node groups the transactions respectively to obtain a plurality of transaction groups, and dispatches, distributes and executes the transactions in units of the transaction groups. In order to reduce the workload of the slave nodes, which occupies most of the workload, and to shorten the overall time consumption of the transaction execution after the slave node consensus, related technologies propose a scheme of grouping the transactions in front, that is, the master node groups the transactions, and the master node and the slave nodes participate in the consensus for the grouping result together, so that the slave nodes can execute a plurality of transactions in groups according to the grouping result directly after the consensus passes without each slave node performing grouping processing separately and repeatedly.
However, in the foregoing scheme of grouping preamble, each slave node needs to execute a plurality of transactions per group after completion of consensus, and submit execution results after completion of execution. Since the consensus process requiring participation of multiple nodes is often time-consuming, the slave node still needs to spend a long time waiting for the consensus to complete before executing the transaction, and the overall transaction processing efficiency still needs to be further improved.
Disclosure of Invention
The present disclosure is directed to a transaction execution method, apparatus, and blockchain system.
According to a first aspect of one or more embodiments of the present specification, there is provided a transaction execution method applied to a blockchain system including a first node and a second node, the method comprising:
the method comprises the steps that a first node determines grouping result information of a first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and provides the first batch of transactions and the grouping result information to a second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node;
Before the second node completes the consensus, determining M transaction groups according to the grouping result information and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
According to a second aspect of one or more embodiments of the present specification, there is provided a transaction execution method applied to a second node in a blockchain system, the blockchain system further including a first node, the method comprising:
receiving first batch transaction and grouping result information sent by a first node, and acquiring a first consensus proposal initiated by the first node for a second batch transaction, and participating in consensus with the first node; the grouping result information is determined by the first node based on respective pre-execution read-write sets of first batch transactions to be executed, and is used for indicating M transaction groups obtained by grouping the first batch transactions, wherein M is a positive integer;
before the consensus is completed, determining M transaction groups according to the grouping result information and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
According to a third aspect of one or more embodiments of the present specification, there is provided a blockchain system including a first node and a second node, wherein:
the first node is used for determining grouping result information of the first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and providing the first batch of transactions and the grouping result information to the second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node;
the first node is used for determining M transaction groups according to the grouping result information before the consensus is completed and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
According to a fourth aspect of one or more embodiments of the present specification, there is provided a transaction execution device for use in a blockchain system including a first node and a second node, the device comprising:
The providing and initiating unit is used for enabling the first node to determine grouping result information of the first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and providing the first batch of transactions and the grouping result information to the second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node;
the execution and updating unit is used for enabling the second node to determine M transaction groups according to the grouping result information before the consensus is completed and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
According to a fifth aspect of one or more embodiments of the present specification, there is provided another transaction execution device for use with a second node in a blockchain system, the blockchain system further including a first node, the device comprising:
the receiving and acquiring unit is used for receiving the first batch of transaction and grouping result information sent by the first node, acquiring a first consensus proposal initiated by the first node for the second batch of transaction, and participating in consensus with the first node; the grouping result information is determined by the first node based on respective pre-execution read-write sets of first batch transactions to be executed, and is used for indicating M transaction groups obtained by grouping the first batch transactions, wherein M is a positive integer;
The executing and updating unit is used for determining M transaction groups according to the grouping result information before the consensus is completed and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
According to a sixth aspect of one or more embodiments of the present specification, there is provided an electronic device comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any of the first or second aspects by executing the executable instructions.
According to a seventh aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method as in any of the first or second aspects.
It may be appreciated that, in addition to initiating the first consensus proposal for the first batch of transactions, the first node in the present solution may provide the first batch of transactions and the information to the second node after determining the grouping result information of the first batch of transactions, so that the second node may execute the first batch of transactions in advance according to the grouping result information during the period of waiting for the completion of the first consensus proposal, so that if the first consensus proposal completes and passes, it may check whether the first batch of transactions executed in advance is the same as the second batch of transactions executed in advance, and if so, it indicates that the second batch of transactions executed in advance are the first batch of transactions, and at this time, the execution result of each executed transaction in the first batch of transactions may be used as the final execution result of the portion of transactions to update the corresponding status data. Therefore, the second node can execute the first agreed transaction in advance in the period of waiting for the completion of the consensus, and does not need to execute the first transaction after the completion of the consensus of the first transaction, thereby realizing the pre-processing of the execution time of the transaction, effectively utilizing the time of the consensus process and effectively improving the overall transaction processing efficiency of the first transaction. In addition, in the case that the first consensus proposal is completed and passed, by checking whether the first batch of transactions executed in advance and the second batch of transactions passed by the consensus are the same and updating the state data only when the first batch of transactions and the second batch of transactions passed by the consensus are the same, the state confusion possibly caused by updating the state data when the consensus is not passed due to abnormal reasons (such as data errors, network delay, node disuse and the like) can be effectively avoided.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic diagram of a transaction execution flow in a blockchain node according to the related art.
FIG. 2 is a flow diagram of transaction execution in a blockchain node in accordance with an exemplary embodiment.
Fig. 3 is a flow chart of a transaction execution method provided in an exemplary embodiment.
FIG. 4 is a schematic diagram of a first node and a second node in a blockchain system in accordance with an exemplary embodiment.
Fig. 5 is a schematic diagram of a DAG provided by an exemplary embodiment.
FIG. 6 is a flow chart of a transaction distribution and execution process provided by an exemplary embodiment.
Fig. 7 is a flow chart of another transaction execution method provided by an exemplary embodiment.
Fig. 8 is a schematic diagram of an apparatus according to an exemplary embodiment.
Fig. 9 is a schematic diagram of a transaction execution device according to an exemplary embodiment.
Fig. 10 is a schematic diagram of another transaction execution device provided in an exemplary embodiment.
Detailed Description
In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.
The blockchain system described in the specification is a distributed network established by a plurality of nodes (nodes), and any two nodes included in the blockchain system can realize communication connection at an application layer through a Peer-to-Peer (P2P) network. The blockchain system uses the decentralized (or called multicentric) distributed ledger constructed by the chain type blockchain structure to be stored on each node (or on a large number of nodes, such as a common node) in the distributed blockchain system, so that the blockchain system needs to solve the problem of consistency and correctness of the data of the respective ledger on a plurality of nodes which are decentralized (or multicentric). In view of this, each node of the blockchain system is running a blockchain program, and under the design of a certain fault tolerance requirement, all the loyalty nodes are guaranteed to have the same transaction through a consensus (consensus) mechanism, so that the consistency of the execution results of all the loyalty nodes on the same transaction is guaranteed, the transactions are packed into blocks, and the world state is updated based on the execution results of the same transaction. The consensus mechanism employed may include, but is not limited to: proof of Work (POW), proof of stock (POS), practical bezels fault tolerance (Practical Byzantine Fault Tolerance, PBFT) algorithms, meles bezels fault tolerance (honeybadger bft) algorithms, and the like.
For each block with passing (or successful) consensus, the blockchain nodes in the blockchain network sequentially execute the blockchain transactions in each block according to the order of the block heights, and after the transactions in any block are executed, the corresponding execution results are submitted according to the order of the block heights so as to complete the uplink memory of the block. In order to increase the overall execution speed of the block (i.e. reduce the overall execution time of all transactions in the block), each node groups the transactions to obtain a plurality of transaction groups, and performs scheduling, distributing and executing in units of transaction groups. In order to reduce the workload of the slave nodes, which occupies most of the workload, and to shorten the overall time consumption of the transaction execution after the slave node consensus, related technologies propose a scheme of grouping the transactions in front, that is, the master node groups the transactions, and the master node and the slave nodes participate in the consensus for the grouping result together, so that the slave nodes can execute a plurality of transactions in groups according to the grouping result directly after the consensus passes without each slave node performing grouping processing separately and repeatedly.
Multiple pipelines may run in any node in the blockchain system. As shown in FIG. 1, the slave node is processing block N, block N+1, and block N+2 in sequence in a pipelined fashion. In addition to the common recognition of the block N through the common recognition pipeline, the master node may determine grouping result information of each transaction in the block N and initiate a common recognition proposal containing the information (the proposal may be a proposal for the block N, that is, the proposal may contain each transaction in the block N), and accordingly, the slave node may also participate in the common recognition process for the proposal through the common recognition pipeline, and determine grouping results according to the grouping result information after the common recognition passes, and then execute each transaction in the block N by the execution pipeline according to the grouping result information and update relevant state data in the cache according to the execution result, and then participate in a proving process for the execution result by the verification pipeline after the update is completed.
However, in the foregoing scheme of grouping preamble, each slave node needs to execute a plurality of transactions per group after completion of consensus, and submit execution results after completion of execution. Since the consensus process requiring participation of multiple nodes is often time-consuming, the slave node still needs to spend a long time waiting for the consensus to complete before executing the transaction, and the overall transaction processing efficiency still needs to be further improved. As shown in fig. 1, the execution pipeline in the slave node needs to execute each transaction after the block N consensus is completed, that is, the start time of the parallel execution N is not earlier than the end time of the block consensus N, and the execution pipeline waits for the consensus process to be completed in a time period corresponding to the block consensus N. Block n+1 and block n+2 are similar to each other and will not be described again.
In order to solve the above-mentioned problems in the related art, the present disclosure proposes a transaction execution method, in which a first node sends a transaction to be executed (i.e., the first batch of transactions) and grouping result information thereof in advance, so that a second node can execute the transaction in groups according to the grouping result information in advance in a period waiting for the completion of the consensus for the transaction, thereby effectively improving the utilization rate of the period. The transaction execution scheme of the present specification will be described in detail with reference to the accompanying drawings.
In one embodiment, the present specification proposes a blockchain system comprising a first node and a second node, wherein:
the first node is used for determining grouping result information of the first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and providing the first batch of transactions and the grouping result information to the second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node;
the first node is used for determining M transaction groups according to the grouping result information before the consensus is completed and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
Fig. 2 is a schematic diagram of a pipeline within a second node (e.g., slave node) according to the present scheme. As can be seen from comparing fig. 1 and fig. 2, compared with the related art, the execution pipeline managed by the second node in this embodiment can start to acquire and (advance) execute the transaction in the block N before the block N consensus starts; it is also possible to start acquiring and executing the transaction in block n+1 after the start of the consensus for block n+1 (and block n+2), whether before or after the start of the consensus, before the completion of the consensus, so that there is a high probability that at least part of the transactions can be executed in the corresponding block (i.e. called executed block).
Fig. 3 is a flow chart of a transaction execution method provided in an exemplary embodiment. The method is applied to a blockchain system that includes a first node and a second node. The first node may be any blockchain node in the blockchain system, and only the node may initiate a first consensus proposal for a first batch of transactions to be executed in the blockchain system. For example, where the blockchain system is a master-slave architecture, the first node may be the master node in the system for initiating the first consensus proposal. Of course, the scheme provided by the embodiments of the present disclosure is not limited to a block chain system of a master-slave architecture; in other words, the first node may be any blockchain node in the blockchain system that may initiate a consensus proposal, and the second node may be any blockchain node in the blockchain system that may participate in a consensus and perform a transaction. Each node in the blockchain system may be implemented as any apparatus, platform, device, or cluster of devices having computing/processing capabilities. As shown in fig. 3, the method is applied to a blockchain system that includes a first node and a second node, the method including the following steps 302-304.
Step 302, a first node determines grouping result information of a first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and provides the first batch of transactions and the grouping result information to a second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in a consensus with the second node.
In an embodiment, the first batch of transactions to be executed may belong to the same block, and in this case, the overall execution efficiency of all the transactions in the same block may be improved. Of course, the first batch of transactions to be executed may also belong to different blocks, which will not be described again. The first batch of transactions may be acquired by the first node in a to-be-executed transaction pool (or to-be-executed transaction set) maintained by the first node, for example, sequentially acquired according to a sequence of transaction submission moments, or randomly selected, etc.
In addition, it should be noted that any of the first, second and third transactions described in the embodiments of the present disclosure includes a plurality of transactions, which are all transactions to be executed that have not yet formed a block. Wherein, the first batch of transactions is different from the second batch of transactions in the processing mode: the first set of transactions is a plurality of transactions to be performed provided by the first node to the second node, the second set of transactions is a plurality of transactions to be performed for which a first node initiates a consensus proposal (i.e., the first consensus proposal) at a pertinence, and the third set of transactions is a plurality of transactions to be performed for which other nodes (distinct from the first node) initiate a consensus proposal (i.e., the second consensus proposal) at a pertinence. In addition, the second and third sets of transactions are two sets of transactions to be performed that are not identical, and both may be the same set of transactions to be performed as the first set of transactions. The details of these three transactions may be found in the examples below, which are not described in detail herein. It should be appreciated that if the first node is not a disliked node, the first node should initiate a first consensus proposal for a first batch of transactions, but not for other batches of transactions to be performed, i.e. the first batch of transactions corresponding to the first consensus proposal should be the same batch of transactions, which is the fact that whether the subsequent second node has the same as the result of updating the corresponding status data according to the execution of the executed transactions in the first batch of transactions.
Before determining the grouping result information of the first batch of transactions, the first node needs to acquire the respective pre-execution read-write sets of the first batch of transactions, and the acquisition process of the pre-execution read-write sets is described below. A plurality of functional components (or functional modules, functional units, etc.) may be respectively executed in the first node and the second node to provide multiple services, where any functional component may be a Process (Process) or a Thread (Thread), and the following description will take each functional component as a corresponding Process as an example, and reference is made to fig. 4.
As shown in fig. 4, node n1 and node n2 are the first node and the second node, respectively, in the blockchain system. The two nodes respectively run a plurality of processes to provide a plurality of services, such as an access process for providing an access service (such as an access process 1 running in a node n1 and an access process 2 running in a node n2, and the process numbers are similar to the same and are not repeated), a caching process for providing a caching service, a pre-execution process for providing a pre-execution service, a network process for providing a network service, a consensus process for providing a consensus service, a storage process for providing a storage service, a control process for providing a block management service, a calculation process for providing a calculation service (such as executing a transaction), and the like.
In this specification, a process refers to a running activity of a program with a certain independent function in an application with respect to a data set, that is, the process is a process in a computer by sequentially executing instructions in the application program by a CPU, and each process is allocated its own memory address space when created. The plurality of processes in any node may be a plurality of processes running in a plurality of computing devices or virtual computing nodes.
It should be noted that the functional components in any node may be discrete concepts, and these components logically belong to the node. Taking the first node as an example, a node program (for implementing control logic of the node) of the first node may be deployed in any physical device, and any functional component in the node may be deployed in the physical device or may be deployed in another physical device different from the physical device (for example, each component may be deployed in a cluster form in a different cloud server). Regardless of the deployment mode, the different components can be regarded as remote, and information and data interaction can be realized between the different components through corresponding communication technologies. Taking the control process and the computing process in the node n1 as an example, interaction between the control process 1 and the computing process 11 may be implemented by an RPC (Remote Procedure Ca shortest dependency group, remote procedure call) technique, PIPE (PIPE) technique, message Queue (Message Queue) technique, or the like, which is not limited in this specification.
It is assumed that the node n2 and the node n1 are a master node and a slave node in the blockchain system, respectively. The access process in any node can be used for receiving the transaction from the user equipment and calling the caching process to add the received transaction to the pending transaction queue for caching.
The pre-execution process 2 of node n2 may invoke the caching process 2 to effect reading of its cached transactions in order from the pending transaction queue and verification of the transaction, e.g. verification of the signature of the transaction by the user device, and return of the verified transaction to the caching process 2. In addition, node n2 may also broadcast the validated transaction stored in its cache process 2 to the network processes of the remaining nodes via its network process 2; thus, a transaction received by node n1 through its network process 1 from node n2 may be cached by its caching process 1 for inclusion in a pending transaction queue. The pending transaction queue thus cached by the caching process 1 of node n1 through its memory includes not only transactions received through its access process 1, but also transactions received through its network process 1 from other nodes, such as node n 2.
The pre-execution process 2 of node n2 may also invoke the caching process 2 to sequentially read its cached transactions from the pending transaction queue and to at least verify transactions from the user device connected to node n 2. The pre-execution process 2 of the node n2 may also pre-execute transactions that it receives in sequence from the caching process 2 to obtain a pre-execution read-write set of the transactions. Wherein the pre-execution read-write sets specifically comprise a pre-execution read set (corresponding to a data read operation involved in the execution of a transaction) and a pre-execution write set (corresponding to a data write operation involved in the execution of a transaction). In addition, the pre-execution may also obtain pre-execution related information such as transaction time consumption (used for representing the time consumed by pre-executing the transaction, which may be regarded as the time required for actually executing the transaction), resource consumption information (used for representing the number of digital resources/computing resources consumed for executing the transaction), and the like. Based on this, the pre-execution process 2 of the node n2 may return, after each time it completes pre-execution of a batch of transactions, the pre-execution read-write set of the batch of transactions to the caching process 2 to be cached in the transaction queue to be commonly known. Of course, the first node may also receive the pre-execution read-write set of the first batch of transactions from other nodes and cache the pre-execution read-write set locally, which is not described herein.
Based on this, the first node may obtain the pre-execution read-write sets of the first batch of transactions from the locally cached data, which may be obtained by the first node or any other node in the blockchain system pre-executing the first batch of transactions. Further, the first node may determine grouping result information of the first batch of transactions based on the obtained pre-execution read-write sets. Thereafter, the first node may determine packet outcome information for the first batch of transactions based on the obtained pre-execution read-write set.
In one embodiment, the first node may group the first plurality of transactions based on their respective pre-execution read-write sets to obtain M transaction groups. For example, the dependency relationship between the first batch of transactions may be determined according to the pre-execution read-write set, and then the first batch of transactions may be grouped based on the dependency relationship. Wherein, M transaction groups obtained by grouping respectively comprise at least one transaction; in the case where any transaction group contains a first set of transactions, there is a continuous dependency relationship between the first set of transactions; no dependency exists between each transaction contained in any two transaction groups. For the M transaction groups obtained by the grouping processing, the first node may determine a transaction identifier set corresponding to each transaction group according to a transaction identifier (such as a transaction hash or a globally unique transaction number in a blockchain system) of each transaction included in each transaction group, and use the transaction identifier set corresponding to each transaction group as grouping result information of the first batch of transactions, where the transaction identifier set corresponding to any transaction group is formed by transaction identifiers of each transaction in the transaction group. In this way, the first node may complete grouping of the first batch of transactions to obtain M transaction groups, and determine a transaction identifier set corresponding to each transaction group respectively based on a grouping result.
As shown in fig. 5 (a), there is a continuous dependency relationship between transactions Tx1 to Tx 7; as shown in fig. 5 (b), there is a continuous dependency relationship between transactions Tx8 to Tx11, and there is no dependency relationship between any of Tx1 to Tx7 and any of Tx8 to Tx 11. Based on this, transactions Tx 1-Tx 7 may be divided into the same transaction Group (hereinafter Group 1), and transactions Tx 8-Tx 11 may be divided into another transaction Group (hereinafter Group 2). It should be noted that, the "continuous dependency relationship" should be understood that the dependency relationship between the first transactions is continuously transferred, such that Tx2 in (a) depends on Tx1 and Tx4 depends on Tx2, and it may be considered that Tx4 depends indirectly on Tx1, i.e., there is a continuous dependency relationship between Tx1, tx2 and Tx 4. For the transaction Group, the first node may determine a transaction identifier set wei c_txid 1= { Tx1, tx2, tx3, tx4, tx5, tx6, tx7}, and a transaction identifier set c_txid 2= { Tx8, tx9, tx10, tx11}, corresponding to Group 1.
In another embodiment, the first node may also determine a dependency relationship between each transaction in the first batch of transactions based on the respective pre-execution read-write sets of the first batch of transactions, and generate M DAGs (Directed Acyclic Graph, directed acyclic graphs) according to the dependency relationship, and then use the M DAGs as grouping result information of the first batch of transactions. Wherein, each vertex in M DAGs corresponds to each transaction in the first batch of transactions one by one, and the directed edge connecting any two vertices in any DAG is used for representing the dependency relationship between the transactions corresponding to the two vertices respectively. Any of the vertices may be a transaction identifier for a corresponding transaction. Because vertices in the DAG corresponding to any transaction group may be used to characterize which transactions are included in the transaction group, where directed edges between vertices may be used to characterize dependencies between the transactions, the DAG may be used as grouping result information corresponding to the transaction group (i.e., grouping result information for each transaction within the transaction group). In this way, the first node only needs to generate M DAGs according to the dependency relationship between transactions, and can use the DAGs as grouping result information of the first batch of transactions to be executed, without generating a transaction identifier set corresponding to each transaction group. In addition, it should be noted that the M DAGs generated according to the dependency relationship between transactions actually correspond to the M transaction groups one by one, so the subsequent second node may determine the corresponding M transaction groups according to the M DAGs, where the transaction groups also include at least one transaction respectively; in the case where any transaction group contains a first set of transactions, there is a continuous dependency relationship between the first set of transactions; no dependency exists between each transaction contained in any two transaction groups.
Still taking fig. 5 as an example, (a) is DAG1 corresponding to Group1, and (b) is DAG2 corresponding to Group 2. Wherein 7 vertices contained in DAG1 correspond to Tx1 to Tx7 one by one; the 4 vertices included in DAG2 correspond to Tx8 to Tx11 one by one. The directed edges from Tx1 to Tx2 are used to characterize transaction Tx2 as dependent on Tx1, the directed edges from Tx4 to Tx6 are used to characterize transaction Tx6 as dependent on Tx4, the directed edges from Tx8 to Tx11 are used to characterize transaction Tx11 as dependent on Tx8, and the like, and will not be repeated.
In one embodiment, the first node may provide the first batch of transactions and the grouping result information to the second node in a number of ways. For example, the first batch of transactions and the packet result information may be sent to the second node prior to initiating the first consensus proposal, such as by including the first batch of transactions and the packet result information in the same message. In this way, the second node may start executing the first batch of transactions before participating in the consensus, so that as many transactions as possible of the first batch of transactions may be executed before the consensus (proposed for the second consensus) is completed. In addition, because the first batch of transactions has been provided to the second node in this manner before the first consensus proposal was initiated for the second batch of transactions, the first node should subsequently initiate the first consensus proposal for the first batch of transactions under normal conditions (e.g., the first node is not a disqualifying node), in other words, the first batch of transactions and the second batch of transactions should be the same batch of transactions at this time. Thus, the subsequently initiated first consensus proposal may include only the transaction identification (e.g., transaction hash or globally unique transaction number within the blockchain system, etc.) of each transaction in the second batch of transactions, which is used to specify to the second node which transactions the second batch of transactions specifically includes, without necessarily including the transaction content of each transaction. As shown in fig. 2, the start time of "pre-fetch and execute N" is located before the start time of "consensus block N" (i.e., the time when the first consensus proposal for block N is received from the node), indicating that the second node has received each transaction and corresponding grouping result information for block N provided by the first node before the first consensus proposal was received.
For another example, the first batch of transactions and the grouping result information may also be included in a first consensus proposal to provide the first batch of transactions and the grouping result information to the second node by initiating the first consensus proposal. The first batch of transactions submitted by the first node can be respectively acquired by each node (including the second node) participating in consensus in the blockchain system. It can be seen that the first node provides the first batch of transactions and their grouping result information to the second node in a consensus proposal by initiating the first consensus proposal within the blockchain system; based on this, whether the first consensus proposal consensus passes or not, it may be determined directly that the first and second transactions are the same batch of transactions. Any transaction in the first batch of transactions contained in the first consensus proposal is the transaction content of the transaction.
As shown in fig. 2, the starting time of "pre-fetching and executing n+1" is the same as the starting time of "consensus block n+1" (i.e. the time when the second node receives the first consensus proposal initiated for block n+1), which indicates that each transaction and corresponding grouping result information of block n+1 are included in the first consensus proposal received by the second node. Similarly, the start time of "pre-fetching and executing n+2" is the same as the start time of "consensus block n+2" (i.e., the time when the second node receives the first consensus proposal initiated for block n+2), indicating that each transaction and corresponding grouping result information for block n+2 is included in the first consensus proposal received by the second node.
In addition, the first node may initiate a first proposal for the second batch of transactions to be performed and participate in a consensus with the second node, i.e. in a consensus process for the proposal. In practice, the number of the second nodes is plural, for example, all the consensus nodes except the first node in the blockchain system (the consensus nodes are blockchain nodes that can participate in the consensus), and the following embodiments only take any transaction group as an example. For example, where the first node is a master node of the blockchain system, the second node may be each slave node. The first node and the second node participate in a common algorithm and a specific process, which can be referred to the description in the related art, and are not described herein.
Step 304, before the second node completes the consensus, determining the M transaction groups according to the grouping result information and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the first consensus proposal indicates that the second batch of transactions and the first batch of transactions are the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
The second node executes the first batch of transactions according to groups, namely, executes each transaction respectively contained in the M transaction groups according to groups. It will be appreciated that the second node performs the first batch of transactions in groups prior to completion of the consensus proposed for the first consensus, in effect being "pre-performed (or pre-performed)" in the nature of a speculative: because the second set of transactions may not pass (or fail) the consensus, the second set of transactions that pass the consensus may not be the same set of transactions as the first set of transactions. Of course, the actual production environment is an error-free scene most of the time, that is, the first node is not a disliked node in most cases, so that the first consensus proposal initiated by the first node can pass through the consensus in most cases. Therefore, the first transactions performed by the aforementioned "early execution" mechanism are considered valid in most cases, i.e. the execution result thereof will be used to update the corresponding state data.
In addition, the execution result of any executed transaction may include the execution read-write set of the transaction (i.e., the read-set and the write-set generated by executing the transaction in advance according to the pre-execution mechanism described above). And the corresponding state data updated by the second node is part of the world state maintained by the second node itself.
It may be appreciated that, in addition to initiating the first consensus proposal for the first batch of transactions, the first node in the present solution may provide the first batch of transactions and the information to the second node after determining the grouping result information of the first batch of transactions, so that the second node may execute the first batch of transactions in advance according to the grouping result information during the period of waiting for the completion of the first consensus proposal, so that if the first consensus proposal completes and passes, it may check whether the first batch of transactions executed in advance is the same as the second batch of transactions executed in advance, and if so, it indicates that the second batch of transactions executed in advance are the first batch of transactions, and at this time, the execution result of each executed transaction in the first batch of transactions may be used as the final execution result of the portion of transactions to update the corresponding status data. Therefore, the second node can execute the first agreed transaction in advance in the period of waiting for the completion of the consensus, and does not need to execute the first transaction after the completion of the consensus of the first transaction, thereby realizing the pre-processing of the execution time of the transaction, effectively utilizing the time of the consensus process and effectively improving the overall transaction processing efficiency of the first transaction. In addition, in the case that the first consensus proposal is completed and passed, by checking whether the first batch of transactions executed in advance and the second batch of transactions passed by the consensus are the same and updating the state data only when the first batch of transactions and the second batch of transactions passed by the consensus are the same, the state confusion possibly caused by updating the state data when the consensus is not passed due to abnormal reasons (such as data errors, network delay, node disuse and the like) can be effectively avoided.
As mentioned above, the first node may send the first batch of transactions and the corresponding packet result information to the second node, and in fact, the first node may also send the first Hash (Hash) of the first batch of transactions to the second node, for example, the first batch of transactions, the packet result information and the first Ha Xifa of the first batch of transactions may be sent to the second node together. Based thereon, the second node may calculate a second hash of the second batch of transactions to which the first consensus proposal corresponds; and if the first hash is equal to the second hash, determining that the second batch of transactions and the first batch of transactions are the same batch of transactions. In this way, the second node may directly compare the hashes of the transactions to determine if the two batches of transactions are identical. According to the calculation mode and the data property of the hash, compared with the transaction content of each transaction, the method can remarkably improve the comparison efficiency, so that the second node can determine whether the first batch of transactions and the second batch of transactions are the same batch of transactions or not as soon as possible.
As described above, after receiving the first batch of transactions and the corresponding grouping result information provided by the first node, the second node may determine M groups of transactions obtained by grouping (i.e., determine grouping results of the first batch of transactions) according to the grouping result information, and execute the first batch of transactions in groups based on the groups. For simplicity of description, each transaction in any transaction group will hereinafter be referred to as executing the transaction group, and is thus described.
In an embodiment, the second node may determine the M transaction groups in a corresponding manner based on different forms of the grouping result information. For example, in the case that the grouping result information is the transaction identifier sets, the transaction groups corresponding to the transaction identifier sets may be determined according to the transaction identifiers respectively included in the M transaction identifier sets. With the foregoing embodiment, it is possible to determine that the transaction Group corresponding to the transaction identifier set is Group1 formed by Tx1 to Tx7 based on c_txid1, and determine that the transaction Group corresponding to the transaction identifier set is Group2 formed by Tx8 to Tx11 based on c_txid 2. For another example, when the grouping result information is the M DAGs, the transaction groups corresponding to the DAGs may be determined according to vertices included in the DAGs. For example, the Group1 formed by the transaction groups Tx1 to Tx7 corresponding to the transaction identifier set is determined according to each vertex included in the DAG1, the Group1 formed by the transaction groups Tx1 to Tx7 corresponding to the transaction identifier set is determined according to each vertex included in the DAG2, and the like, which are not described herein.
In one embodiment, the second node may comprise a control component and N computing components, where N is an integer greater than 1 (i.e., the second node comprises a plurality of computing components), any of which may be a process or thread created within the node. At this time, the process of executing the first batch of transactions by the second node in groups may be completed by the control component in cooperation with the N computing components.
For example, the control component may distribute the M transaction groups to respective computing components of the N computing components, respectively, i.e., the control component actively distributes the transaction groups. In the case where M.ltoreq.N, the control component may distribute the M transaction groups one by one to different computing components. If M is less than N, M computing components in N computing components respectively receive one transaction group, and N-M computing components do not receive any transaction group; if m=n, then N control components each receive a transaction group. In this scenario, each control component that receives (and only receives one) transaction group executes its own received transaction group, respectively, thereby implementing parallel execution of each transaction group. And under the condition that M is greater than N, the control component can distribute the M transaction groups to the N calculation components as uniformly as possible according to a preset rule, so that each calculation component can execute the received transaction groups respectively. The preset rule may include that the total amount of execution tasks is close, the total execution duration is close, and the like, so that when different transaction groups are executed in parallel, the total amount of execution tasks of each calculation assembly is close or the total execution duration is close, and it is ensured that each calculation assembly finishes execution as simultaneously as possible, so that the total time consumption of executing the M transaction groups by the second node is reduced. Illustratively, the node n2 shown in FIG. 4 includes three computing processes (i.e., computing processes 11-13), where the transaction groups Group1 and Group2 described above may be distributed to computing processes 11 and 12, respectively (or to computing processes 11 and 13, respectively); alternatively, if node n2 contains only computing processes 12 and 13, group1 and Group2 may be distributed one-to-one to both computing processes; still alternatively, if node n2 contains only computing process 12, both Group1 and Group2 may be distributed to that computing process.
For another example, each of the N computing components may preempt a corresponding transaction group from the M transaction groups, i.e., the control process passively distributes the transaction groups. Each computing component can flexibly preempt the transaction group according to the workload of the computing component, for example, any computing component can initiate a preemption request to a control process when the computing component is in an idle state (the computing task received before the current moment is all completed) or can initiate the preemption request to the control process when the computing component predicts that the computing component is about to be in the idle state (such as 500ms before the idle state); accordingly, the control process may distribute at least one transaction group to the initiator (i.e., control component) of the request in response to any preemption request received, such as sending the transaction group specified in the request to the initiator, etc. In this manner, each computing component may proactively preempt a corresponding transaction group and execute (each transaction contained therein).
In an embodiment, where the second node includes a control component and N computing components (N is an integer greater than 1), the second node may perform each transaction in any transaction group according to a dependency relationship between the transactions in the transaction group. For example, the control component may first divide each transaction in any one of the transaction groups into at least one shortest dependency group according to the dependency relationship between each transaction in the any one of the transaction groups; wherein, any shortest dependency group contains at least one transaction, and a unidirectional dependency relationship exists between the first batch of transactions in any shortest dependency group containing the first batch of transactions, and the dependency relationship may exist or may not exist between the transactions contained in different shortest dependency groups respectively. In addition, the dependency relationship between each transaction in any transaction group may be determined by the second node according to the corresponding pre-execution read-write set, or may also be determined according to the DAG included in the first common identification proposal, which is not limited in the embodiment of the present disclosure.
As shown in fig. 5, there is a one-way dependency between Tx1 and Tx2 and a one-way dependency between Tx6 and Tx7 in Group1, and each transaction in Group1 may be divided into the following 5 shortest dependency groups: g1 (including Tx1 and Tx 2), g2 (including Tx 3), g3 (including Tx 4), g4 (including Tx 5), g5 (including Tx6 and Tx 7). As can be seen from the dependency relationship, there is no dependency relationship between transactions contained in g1 and g2 (hereinafter referred to as no dependency relationship between g1 and g2, the same applies to the following), and similarly, there is no dependency relationship between g4 and g 5; there is a dependency between g1 and g3 (g 3 depends on g1, in particular Tx4 in g3 depends on Tx2 in g 1), between g2 and g3 (g 3 depends on g2, in particular Tx4 in g3 depends on Tx3 in g 2), between g3 and g4 (g 4 depends on g3, in particular Tx5 in g4 depends on Tx4 in g 3), between g3 and g5 (g 5 depends on g3, in particular Tx6 in g5 depends on Tx4 in g 3). Similarly, each transaction in Group2 may be divided into the following 4 shortest dependency groups: g6 (including Tx 8), g7 (including Tx 9), g8 (including Tx 10), and g9 (including Tx 11). As can be seen from the dependency relationship, no dependency relationship exists between transactions contained in g7 and g8 respectively; g7 depends on g6 (specifically, tx9 in g7 depends on Tx8 in g6, the same applies below), g8 depends on g6, g9 depends on g7 and g8.
Based on the division result of the shortest dependency groups, the control component can distribute the at least one shortest dependency group to corresponding computing components in the N computing components, namely, the control component actively distributes the shortest dependency group; alternatively, each of the N computing components may preempt a corresponding shortest dependency group from the at least one shortest dependency group, i.e., the control component may be passively distributed. The specific implementation process of the two distribution manners may refer to the embodiments of the active and passive distribution transaction groups of the control component, which are not described herein. By the above manner, at least some computing components in the N computing components may acquire the shortest dependency groups, and at this time, each computing component acquiring the shortest dependency group may execute each transaction in the shortest dependency group acquired by itself, that is, execute each transaction included in each shortest dependency group.
In the case that each transaction in any transaction group of any first node is divided into only one shortest dependency group, the control component may distribute the shortest dependency group to any one computing component for execution, so as to reduce cross-component data transmission (such as cross-process transmission or cross-line Cheng Chuanshu) possibly generated in the execution process of each component in the shortest dependency group, thereby improving the overall execution efficiency of the transactions. And in the case that each transaction in any transaction group is divided into a plurality of shortest dependency groups, if the N computing components are N threads, for at least two shortest dependency groups of the plurality of shortest dependency groups that are depended on by a last transaction in the same shortest dependency group or depended on a first transaction in the same shortest dependency group, the control component may distribute the at least two shortest dependency groups to different threads belonging to the same process, so that the shortest dependency groups are executed in parallel by different threads in the same process, thereby reducing cross-process data transmission as much as possible while executing each shortest dependency group in parallel, and further improving execution efficiency.
In an embodiment, the control component may distribute the at least one shortest dependency group to a corresponding one of the N computing components according to a dependency relationship between the shortest dependency groups. For example, if there is no dependency relationship between the transactions respectively contained in any two shortest dependency groups, the any two shortest dependency groups may be distributed to different computing components, so that each transaction respectively contained in any two shortest dependency groups is executed in parallel by the different computing components. If there is a dependency relationship between the transactions contained in the two shortest dependency groups, the two shortest dependency groups may be distributed to the same or different computing components, so that each transaction contained in the two shortest dependency groups is executed in series by the same or different computing components according to the dependency relationship.
For the foregoing embodiment corresponding to Group1 in fig. 5, the distribution and execution process of the shortest dependency Group obtained by dividing each transaction in the transaction Group in the first node may be referred to as fig. 6. The second node may determine a dependency relationship between each transaction in the any transaction group according to the DAG, and divide the transaction group into five shortest dependency groups based on the dependency relationship, that is, the foregoing g1 to g5. Each shortest dependency group may then be sent to a corresponding computing thread, respectively, by way of active dispatch or preemption as previously described. As shown in fig. 6, threads Thread1.0 and Thread1.1 in Process1 acquire g1 and g2, respectively, thread2 in Process2 acquires g3, and threads Thread3.0 and Thread3.1 in Process3 acquire g4 and g5, respectively. In the execution process, according to the foregoing dependency relationship of g 1-g 5, thread1.0 and Thread1.1 execute g1 and g2 (transaction in the middle, the same applies below) respectively (i.e. in parallel), and provide the execution result to Thread2, so that Thread2 executes g3 according to the execution results of g1 and g 2; thereafter, thread2 supplies the execution result of g3 to Thread3.0 and Thread3.1, respectively, to execute g4 and g5, respectively, by the latter based on the execution result of g 3.
In an embodiment, any computing component may execute each transaction included in any shortest dependency group acquired by itself according to an execution order corresponding to a dependency relationship between shortest dependency groups. For example, in a case where a first transaction in the any shortest dependency group depends on a last transaction in at least one other shortest dependency group, the any computing component may obtain an execution result of the last transaction of the at least one other shortest dependency group, and execute the first transaction included in the any shortest dependency group based on the obtained execution result. As shown in fig. 6, since the first transaction (also the only transaction in the group) Tx4 in g3 depends on both the last transaction Tx2 in g1 and the last transaction (also the only transaction in the group) Tx3 in g2, thread2 needs to acquire the execution results of Tx2 and Tx3, respectively, and after acquiring the execution results of the two transactions, execute Tx4 based on the two execution results. Similarly, because the first transaction Tx6 in g5 depends on the last transaction Tx4 in g3 (which is also the only transaction in the group), thread3.1 needs to obtain the execution result of Tx4 and execute Tx6 based on the execution result. By the method, the plurality of calculation threads can ensure that all transactions are executed strictly according to the dependency relationship sequence among all transactions in the transaction group in the same first node, and the execution error of the transactions is effectively avoided.
The consensus proposed for the first consensus may or may not pass. If the second transaction passes, most of all nodes participating in the consensus (the specific number is determined by a consensus algorithm) are confirmed by the nodes; otherwise, if not, it is indicated that most of all nodes participating in the consensus do not agree on the second batch of transactions. Wherein the failure to pass the consensus may be due to a pre-execution error of the first node or a falsification of the packet result information (e.g. the first node is a rogue node), etc.
In one embodiment, the first node also needs to perform the first batch of transactions as part of a blockchain system. In view of the fact that the first node has acquired the respective pre-execution read-write sets of the plurality of transactions (e.g., the first node has pre-executed the plurality of transactions), if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions in the case that the common recognition proposed for the first common recognition is completed and passed, the first node may update the corresponding state data according to the pre-execution result of the first batch of transactions, where the pre-execution result includes the pre-execution read-write set. It will be appreciated that because the grouping result information is determined from the pre-execution read-write set resulting from the pre-execution, the consensus proposal containing the grouping result information proposes that the first consensus proposal further indicates approval of the pre-execution result of the plurality of transactions by the consensus, i.e. indicating approval of the grouping result information by the consensus node. The first node may therefore treat the pre-execution result as its execution result without having to repeatedly execute the plurality of transactions. It should be noted that, the "pre-execution" in this embodiment is that the first node performs pre-execution on each transaction in the first batch of transactions before determining the packet result information, and is different from the first batch of transactions provided by the first node that is "pre-executed" by the second node in the above embodiment. Of course, for the same transaction, if the execution process is not wrong, the first node performs the transaction in advance with the second node, and the read-write sets obtained respectively should be the same.
In one embodiment, the second node may cache the execution results of each executed transaction in the first batch of transactions in the event that the consensus proposed for the first consensus is completed and failed. Thereafter, other nodes in the blockchain system that are distinct from the first node (e.g., either the second node or any other node that is distinct from the second node, etc.) may initiate a second consensus proposal for the third batch of transactions, and the nodes in the blockchain system may be consensus, e.g., both the second node and the third node may participate in the consensus for the proposal. In view of the first node possibly being a rogue node, the third node may specify in the second consensus proposal: the first node is not allowed to participate in the consensus to avoid errors in the consensus result. Wherein, in view of the fact that the first consensus proposal for the second batch of transactions does not pass, another batch of transactions different from the second batch of transactions may be selected as a third batch of transactions, i.e. the third batch of transactions is not identical to the second batch of transactions. In addition, the number of second consensus proposals may be multiple, i.e. in case one second consensus proposal does not pass, a new second consensus proposal for another third batch of transactions may be reinitiated by other nodes in the blockchain system until a certain second consensus proposal passes and the third batch of transactions is identical to the first batch of transactions. In the at least one proposed consensus process, the second node may execute the first set of transactions until each transaction is completed or stopped by the consensus passing. If the third batch of transactions and the first batch of transactions are determined to be the same batch of transactions under the condition that the consensus proposed for the second consensus is completed and passed, corresponding state data can be updated according to the cached execution result.
Corresponding to the previous embodiments, the present embodiments also propose another transaction execution method, which is applied to a second node in a blockchain system, which further includes a first node. As shown in fig. 7, the method includes steps 702-704.
Step 702, receiving first batch of transaction and grouping result information sent by a first node, and acquiring a first consensus proposal initiated by the first node for a second batch of transaction, and participating in consensus with the first node; the grouping result information is determined by the first node based on respective pre-execution read-write sets of the first batch of transactions to be executed, and is used for indicating M transaction groups obtained by grouping the first batch of transactions, wherein M is a positive integer.
Step 704, before the consensus is completed, determining the M transaction groups according to the grouping result information and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
Fig. 8 is a schematic block diagram of an apparatus according to an exemplary embodiment. Referring to fig. 8, at the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile storage 810, although other hardware required for other functions may be included. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 802 reading a corresponding computer program from the non-volatile memory 810 into the memory 808 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but may also be hardware or a logic device.
As shown in fig. 9, fig. 9 is a block diagram of a transaction execution device according to an exemplary embodiment of the present specification, which may be applied to the apparatus shown in fig. 8 to implement the technical solution of the present specification. The apparatus is applied to a blockchain system including a first node and a second node, the apparatus comprising:
a providing and initiating unit 901, configured to enable a first node to determine grouping result information of a first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and provide the first batch of transactions and the grouping result information to a second node, where the grouping result information is used to indicate M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node;
an execution and updating unit 902, configured to enable a second node to determine the M transaction groups according to the grouping result information and execute a first batch of transactions according to the groups before the consensus is completed; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
Optionally, the providing and initiating unit 901 is specifically configured to:
transmitting the first batch of transactions and the grouping result information to a second node prior to initiating a first consensus proposal; or,
the first batch of transactions and the grouping result information are included in a first consensus proposal to provide the first batch of transactions and the grouping result information to a second node by initiating the first consensus proposal.
Alternatively to this, the method may comprise,
the providing and initiating unit 901 is specifically configured to: transmitting the first batch of transactions, the grouping result information and the first hash of the first batch of transactions to a second node;
the execution and update unit 902 is specifically configured to: calculating a second hash of the second batch of transactions corresponding to the first consensus proposal; and if the first hash is equal to the second hash, determining that the second batch of transactions and the first batch of transactions are the same batch of transactions.
Optionally, the providing and initiating unit 901 is specifically configured to:
grouping the first batch of transactions based on the respective pre-execution read-write sets of the first batch of transactions to obtain M transaction groups, and taking the transaction identifier sets respectively corresponding to the transaction groups as grouping result information of the first batch of transactions, wherein the transaction identifier set corresponding to any transaction group comprises transaction identifiers of all transactions in the transaction group; or,
And determining the dependency relationship between all transactions in the first batch of transactions based on the respective pre-execution read-write sets of the first batch of transactions, and taking M directed acyclic graphs DAGs generated according to the dependency relationship as grouping result information of the first batch of transactions, wherein all vertexes in the M DAGs are in one-to-one correspondence with all transactions in the first batch of transactions, and directed edges connected with any two vertexes in any DAG are used for representing the dependency relationship between the transactions respectively corresponding to the two vertexes.
Optionally, the second node includes a control component and N computing components, where N is an integer greater than 1, and the execution and update unit 902 is specifically configured to:
the control component distributes the M transaction groups to corresponding calculation components in the N calculation components respectively, or each calculation component in the N calculation components preemptively occupies the corresponding transaction group from the M transaction groups;
each computing component in the N computing components respectively executes the transactions contained in the transaction group acquired by the computing components.
Optionally, the second node includes a control component and N computing components, where N is an integer greater than 1, and the execution and update unit 902 is specifically configured to:
the control component divides each transaction in any transaction group into at least one shortest dependency group according to the dependency relationship between each transaction in any transaction group; wherein any shortest dependency group comprises at least one transaction, and a unidirectional dependency relationship exists between the first batch of transactions in any shortest dependency group comprising the first batch of transactions;
The control component distributes the at least one shortest dependency group to a corresponding computing component of the N computing components, or each computing component of the N computing components preempts a corresponding shortest dependency group from the at least one shortest dependency group;
and each computing component of the N computing components, which acquires the shortest dependency group, respectively executes the transaction contained in the shortest dependency group acquired by the computing components.
Optionally, the executing and updating unit 902 is specifically configured to:
if no dependency relationship exists between the transactions contained in any two shortest dependency groups respectively, distributing the any two shortest dependency groups to different computing components so that the different computing components execute all the transactions contained in any two shortest dependency groups respectively in parallel;
if a dependency relationship exists between the transactions contained in any two shortest dependency groups, distributing the any two shortest dependency groups to the same or different computing components, so that each transaction contained in any two shortest dependency groups is executed in series by the same or different computing components according to the dependency relationship.
Optionally, the executing and updating unit 902 is specifically configured to:
And in the case that the first transaction in any one of the shortest dependency groups depends on the last transaction in at least one other shortest dependency group, acquiring an execution result of the last transaction of the at least one other shortest dependency group, and executing the first transaction contained in any one of the shortest dependency groups based on the acquired execution result.
Optionally, the method further comprises:
the state updating unit 903 is configured to update corresponding state data according to a pre-execution result of the first batch of transactions if it is determined that the second batch of transactions and the first batch of transactions are the same batch of transactions when the consensus is completed and the consensus is passed, where the pre-execution result includes the pre-execution read-write set.
Optionally, the method further comprises:
a caching and updating unit 904, configured to cache, by the second node, execution results of each executed transaction in the first batch of transactions if the consensus is completed and the consensus is not passed; and under the condition that the second consensus proposal initiated by other nodes different from the first node in the blockchain system aiming at the third batch of transactions is completed and passed, if the third batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the cached execution result.
Fig. 10 is a block diagram of another transaction execution device according to an exemplary embodiment of the present disclosure, which may be applied to the apparatus shown in fig. 8 to implement the technical solution of the present disclosure. The apparatus is applied to a second node in a blockchain system, the blockchain system further including a first node, the apparatus including:
a receiving and acquiring unit 1001, configured to receive first batch of transaction and grouping result information sent by a first node, and acquire a first consensus proposal initiated by the first node for a second batch of transaction, and participate in consensus with the first node; the grouping result information is determined by the first node based on respective pre-execution read-write sets of first batch transactions to be executed, and is used for indicating M transaction groups obtained by grouping the first batch transactions, wherein M is a positive integer;
an execution and updating unit 1002, configured to determine the M transaction groups according to the grouping result information and execute a first batch of transactions by group before the consensus is completed; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.
The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
One skilled in the relevant art will recognize that 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 combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product 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.
One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.
Claims (16)
1. A transaction execution method applied to a blockchain system, the blockchain system including a first node and a second node, the method comprising:
the method comprises the steps that a first node determines grouping result information of a first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and provides the first batch of transactions and the grouping result information to a second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node;
before the second node completes the consensus, determining M transaction groups according to the grouping result information and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
2. The method of claim 1, the first node providing the first batch of transactions and the grouping result information to the second node, comprising:
transmitting the first batch of transactions and the grouping result information to a second node prior to initiating a first consensus proposal; or,
the first batch of transactions and the grouping result information are included in a first consensus proposal to provide the first batch of transactions and the grouping result information to a second node by initiating the first consensus proposal.
3. The method according to claim 2,
said transmitting the first batch of transactions and said grouping result information to the second node, comprising: transmitting the first batch of transactions, the grouping result information and the first hash of the first batch of transactions to a second node;
the determining that the second batch of transactions and the first batch of transactions are the same batch of transactions includes: calculating a second hash of the second batch of transactions corresponding to the first consensus proposal; and if the first hash is equal to the second hash, determining that the second batch of transactions and the first batch of transactions are the same batch of transactions.
4. The method of claim 1, the first node determining packet outcome information for the first plurality of transactions based on respective pre-execution read-write sets of the first plurality of transactions to be executed, comprising:
Grouping the first batch of transactions based on the respective pre-execution read-write sets of the first batch of transactions to obtain M transaction groups, and taking the transaction identifier sets respectively corresponding to the transaction groups as grouping result information of the first batch of transactions, wherein the transaction identifier set corresponding to any transaction group comprises transaction identifiers of all transactions in the transaction group; or,
and determining the dependency relationship between all transactions in the first batch of transactions based on the respective pre-execution read-write sets of the first batch of transactions, and taking M directed acyclic graphs DAGs generated according to the dependency relationship as grouping result information of the first batch of transactions, wherein all vertexes in the M DAGs are in one-to-one correspondence with all transactions in the first batch of transactions, and directed edges connected with any two vertexes in any DAG are used for representing the dependency relationship between the transactions respectively corresponding to the two vertexes.
5. The method of claim 1, the second node comprising a control component and N computing components, N being an integer greater than 1, the second node performing a first batch of transactions in groups, comprising:
the control component distributes the M transaction groups to corresponding calculation components in the N calculation components respectively, or each calculation component in the N calculation components preemptively occupies the corresponding transaction group from the M transaction groups;
Each computing component in the N computing components respectively executes the transactions contained in the transaction group acquired by the computing components.
6. The method of claim 1, the second node comprising a control component and N computing components, N being an integer greater than 1, the second node performing each transaction in any transaction group, comprising:
the control component divides each transaction in any transaction group into at least one shortest dependency group according to the dependency relationship between each transaction in any transaction group; wherein any shortest dependency group comprises at least one transaction, and a unidirectional dependency relationship exists between the first batch of transactions in any shortest dependency group comprising the first batch of transactions;
the control component distributes the at least one shortest dependency group to a corresponding computing component of the N computing components, or each computing component of the N computing components preempts a corresponding shortest dependency group from the at least one shortest dependency group;
and each computing component of the N computing components, which acquires the shortest dependency group, respectively executes the transaction contained in the shortest dependency group acquired by the computing components.
7. The method of claim 6, the control component distributing the at least one shortest dependency component to a respective one of the N computing components, comprising:
If no dependency relationship exists between the transactions contained in any two shortest dependency groups respectively, distributing the any two shortest dependency groups to different computing components so that the different computing components execute all the transactions contained in any two shortest dependency groups respectively in parallel;
if a dependency relationship exists between the transactions contained in any two shortest dependency groups, distributing the any two shortest dependency groups to the same or different computing components, so that each transaction contained in any two shortest dependency groups is executed in series by the same or different computing components according to the dependency relationship.
8. The method of claim 6, wherein any computing component performs transactions contained in any shortest dependency group acquired by itself, comprising:
and in the case that the first transaction in any one of the shortest dependency groups depends on the last transaction in at least one other shortest dependency group, acquiring an execution result of the last transaction of the at least one other shortest dependency group, and executing the first transaction contained in any one of the shortest dependency groups based on the acquired execution result.
9. The method of claim 1, further comprising:
And under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, the first node updates corresponding state data according to the pre-execution result of the first batch of transactions, wherein the pre-execution result comprises the pre-execution read-write set.
10. The method of claim 1, further comprising:
under the condition that the consensus is completed and the consensus is not passed, the second node caches the execution results of all executed transactions in the first batch of transactions; and under the condition that the second consensus proposal initiated by other nodes different from the first node in the blockchain system aiming at the third batch of transactions is completed and passed, if the third batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the cached execution result.
11. A transaction execution method applied to a second node in a blockchain system, the blockchain system further including a first node, the method comprising:
receiving first batch transaction and grouping result information sent by a first node, and acquiring a first consensus proposal initiated by the first node for a second batch transaction, and participating in consensus with the first node; the grouping result information is determined by the first node based on respective pre-execution read-write sets of first batch transactions to be executed, and is used for indicating M transaction groups obtained by grouping the first batch transactions, wherein M is a positive integer;
Before the consensus is completed, determining M transaction groups according to the grouping result information and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
12. A blockchain system, the blockchain system comprising a first node and a second node, wherein:
the first node is used for determining grouping result information of the first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and providing the first batch of transactions and the grouping result information to the second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node;
the first node is used for determining M transaction groups according to the grouping result information before the consensus is completed and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
13. A transaction execution device for use in a blockchain system, the blockchain system including a first node and a second node, the device comprising:
the providing and initiating unit is used for enabling the first node to determine grouping result information of the first batch of transactions based on respective pre-execution read-write sets of the first batch of transactions to be executed, and providing the first batch of transactions and the grouping result information to the second node, wherein the grouping result information is used for indicating M transaction groups obtained by grouping the first batch of transactions, and M is a positive integer; and initiating a first consensus proposal for the second batch of transactions and participating in consensus with the second node;
the execution and updating unit is used for enabling the second node to determine M transaction groups according to the grouping result information before the consensus is completed and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
14. A transaction execution device for use with a second node in a blockchain system, the blockchain system further including a first node, the device comprising:
The receiving and acquiring unit is used for receiving the first batch of transaction and grouping result information sent by the first node, acquiring a first consensus proposal initiated by the first node for the second batch of transaction, and participating in consensus with the first node; the grouping result information is determined by the first node based on respective pre-execution read-write sets of first batch transactions to be executed, and is used for indicating M transaction groups obtained by grouping the first batch transactions, wherein M is a positive integer;
the executing and updating unit is used for determining M transaction groups according to the grouping result information before the consensus is completed and executing a first batch of transactions according to the groups; and under the condition that the consensus is completed and passed, if the second batch of transactions and the first batch of transactions are determined to be the same batch of transactions, updating corresponding state data according to the execution result of each executed transaction in the first batch of transactions.
15. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor is configured to implement the method of any of claims 1-11 by executing the executable instructions.
16. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-11.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311437396.1A CN117408703A (en) | 2023-10-31 | 2023-10-31 | Transaction execution method, device and blockchain system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311437396.1A CN117408703A (en) | 2023-10-31 | 2023-10-31 | Transaction execution method, device and blockchain system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117408703A true CN117408703A (en) | 2024-01-16 |
Family
ID=89490559
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311437396.1A Pending CN117408703A (en) | 2023-10-31 | 2023-10-31 | Transaction execution method, device and blockchain system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117408703A (en) |
-
2023
- 2023-10-31 CN CN202311437396.1A patent/CN117408703A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7114629B2 (en) | System and method for parallel verification of blockchain transactions | |
| US11258725B2 (en) | Distributed stream-based database triggers | |
| US20210256016A1 (en) | Blockchain system and method | |
| US9703610B2 (en) | Extensible centralized dynamic resource distribution in a clustered data grid | |
| CN103593242B (en) | Resource sharing control system based on Yarn frameworks | |
| CN110262901B (en) | Data processing method and data processing system | |
| CN111932257B (en) | Block chain parallelization processing method and device | |
| CN112154462A (en) | High performance pipeline parallel deep neural network training | |
| CN115237580B (en) | Intelligent calculation-oriented flow parallel training self-adaptive adjustment system and method | |
| CN114936093A (en) | Transaction execution method in blockchain system, node and blockchain system | |
| US11487736B2 (en) | Blockchain transaction processing systems and methods | |
| CN112805683A (en) | Flow allocation using flow borrowing | |
| CN116308772B (en) | Transaction distribution method, node and blockchain system | |
| CN108111630B (en) | Zookeeper cluster system and connection method and system thereof | |
| CN111597035B (en) | Simulation engine time propulsion method and system based on multithreading | |
| CN117408703A (en) | Transaction execution method, device and blockchain system | |
| CN117474552A (en) | Transaction execution method, device and blockchain system | |
| WO2018188958A1 (en) | A method and a host for managing events in a network that adopts event-driven programming framework | |
| WO2014171810A2 (en) | A system and method of fault tolerant for distributed applications in a virtualized environment | |
| CN114546631A (en) | Task scheduling method, control method, core, electronic device and readable medium | |
| CN116703580A (en) | Transaction distribution method, node and blockchain system | |
| CN116579851A (en) | Transaction distribution method, node and blockchain system | |
| CN116662293A (en) | Receipt data storage method, node and blockchain system | |
| CN115208900B (en) | Multi-cloud architecture cloud service resource scheduling method based on blockchain and game model | |
| Cheng et al. | A malicious-resilient protocol for consistent scheduling problem in the cloud computing environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |