WO2024244342A1 - Transaction processing method in blockchain, and blockchain node - Google Patents

Abstract

A transaction processing method in a blockchain, and a blockchain node. The method is executed by a first node, the first node is currently a slave node, and the method comprises: acquiring first information and a first transaction, the first information being used for instructing to disable a pre-execution function; verifying the first transaction according to the first information; and, if the verification is passed, storing the first transaction.

Description

Transaction processing method and blockchain node in blockchain

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on May 31, 2023, with application number 202310640782.4 and application name “Transaction Processing Method and Blockchain Node in Blockchain”, the entire contents of which are incorporated by reference in this application.

Technical Field

The embodiments of this specification belong to the field of blockchain technology, and more particularly to a transaction processing method and blockchain node in a blockchain.

Background Art

Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time sequence, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application.

Summary of the invention

The purpose of the present invention is to provide a transaction processing method in a blockchain to improve the transaction processing efficiency in the blockchain.

In a first aspect, the present specification provides a transaction processing method in a blockchain, which is executed by a first node, where the first node is currently a slave node, and the method includes:

Acquire a first transaction and first information stored locally, where the first information is used to indicate that a pre-execution function is disabled;

verifying the first transaction according to the first information;

If the verification is successful, the first transaction is stored.

A second aspect of the present specification provides a blockchain node, wherein the blockchain node is currently a slave node, including:

an acquisition unit, configured to acquire a first transaction and first information stored locally, wherein the first information is used to indicate that a pre-execution function is turned off;

a verification unit, configured to verify the first transaction according to the first information;

The storage unit is used to store the first transaction when the verification is passed.

A third aspect of the present specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described in the first aspect.

A fourth aspect of the present specification provides a blockchain node, including a memory and a processor, wherein the memory stores an executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

In the solution provided in the embodiments of the present specification, the slave node stores the transaction in the transaction queue after the transaction is verified according to the instruction information stored in the slave node, so that when the slave node is converted from a slave node to a master node, it can obtain the verified transaction from the verified transaction queue for pre-execution without the loss of the transaction, avoiding the need for the client to resend the transaction, and improving the transaction processing efficiency in the blockchain.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

FIG1 is a diagram of a blockchain architecture in one embodiment;

FIG2 is a flow chart of a transaction processing method in a blockchain according to an embodiment of the present specification;

FIG3 is a flow chart of a transaction processing method in a blockchain according to an embodiment of this specification;

FIG4 is a flow chart of a transaction processing method in a blockchain in another embodiment of the present specification;

FIG5 is a flow chart of a transaction processing method in a blockchain in another embodiment of this specification;

FIG6 is an architecture diagram of a blockchain node in an embodiment of this specification.

DETAILED DESCRIPTION

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

FIG. 1 shows a diagram of a blockchain architecture in one embodiment. In the diagram of the blockchain architecture shown in FIG. 1 , the blockchain includes N nodes, and FIG. 1 schematically shows nodes 1 to 8. The lines between the nodes schematically represent P2P (Peer to Peer) connections, and the connection may be, for example, a TCP connection, etc., for transmitting data between nodes. These nodes can store a full amount of ledgers, that is, store the status of all blocks and all accounts. Among them, each node in the blockchain can generate the same state in the blockchain by executing the same transaction, and each node in the blockchain can store the same state database.

Transactions in the blockchain field can refer to task units executed and recorded in the blockchain. Transactions usually include a send field (From), a receive field (To), and a data field (Data). Among them, in the case of a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount.

The blockchain can provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in the blockchain is to initiate a transaction pointing to the smart contract address, so that each node in the blockchain can run the smart contract code in a distributed manner.

In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying a contract) to the blockchain shown in Figure 1. The data field of the transaction includes the code of the contract to be created (such as bytecode or machine code), and the to field of the transaction is empty to indicate that the transaction is used to deploy a contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined. Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates the state storage corresponding to the contract account, and stores the contract code. The hash value of the contract code is saved in the state storage of the contract, so that the contract is successfully created.

In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to the blockchain shown in Figure 1. The from field of the transaction is the address of the account of the transaction initiator (i.e. Bob), and the to field is the above "0x6f8ae93..." is the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After the transaction is agreed upon in the blockchain, each node in the blockchain can execute the transaction separately, thereby executing the contract separately, and updating the status database based on the execution of the contract.

One of the decentralized features that distinguishes blockchain technology from traditional technologies is that it records accounts on each node, or distributed accounting, rather than traditional centralized accounting. In order for a blockchain system to become a decentralized, honest and trustworthy system that is difficult to break, public, and cannot be tampered with, it is necessary to make distributed data records secure, clear, and irreversible in the shortest possible time. In different types of blockchain networks, in order to maintain the consistency of the ledgers in each node that records the ledger, a consensus algorithm is usually used to ensure that it is the consensus mechanism mentioned above. For example, a consensus mechanism of block granularity can be implemented between blockchain nodes. For example, after a node (such as a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a consensus mechanism of transaction granularity can be implemented between blockchain nodes. For example, after a node (such as a unique node) obtains a blockchain transaction, if the blockchain transaction is recognized by other nodes, each node that recognizes the blockchain transaction can add the blockchain transaction to the latest block maintained by itself, and ultimately ensure that each node generates the same latest block. The consensus mechanism is a mechanism for blockchain nodes to reach a consensus on block information (or block data) across the entire network, which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, etc. Among them, in various consensus algorithms, usually after a preset number of nodes reach an agreement on the consensus data (i.e., consensus proposal), the consensus on the consensus proposal is determined to be successful. Specifically, in the PBFT algorithm, for 3(f+1)+1>N≥3f+1 consensus nodes, f malicious nodes can be tolerated, that is, when at least 2f+1 nodes among N consensus nodes reach an agreement, the consensus can be determined to be successful.

The blockchain shown in FIG1 may include a master node and a slave node. In the scenario of executing transactions in parallel, the master node may pre-execute multiple transactions and obtain pre-execution read-write sets of multiple transactions, so that a consensus proposal including the multiple transactions and their pre-execution read-write sets may be sent to each slave node. After the consensus proposal is passed, each slave node may group the multiple transactions according to the pre-execution read-write sets of the multiple transactions, and execute the multiple transactions in parallel according to the grouping results. In this scenario, usually, after receiving the transaction from the client, the slave node forwards the received transaction to the master node so that the master node performs pre-execution of the transaction. However, when the master node fails and needs to be replaced, the slave node does not store a batch of transactions that have been received from the client, resulting in the loss of the batch of transactions, and the client needs to resend the batch of transactions to the blockchain, affecting business efficiency.

The embodiments of the present specification provide a method for processing transactions in a blockchain, wherein after receiving a transaction, a slave node verifies the received transaction based on its role-related information without pre-executing the transaction, and stores the transaction after the verification is passed, so that when a master node fails, the slave node can directly obtain the verified transaction locally for consensus on the transaction, thereby improving the transaction processing efficiency in the blockchain.

Figure 2 is a flow chart of a transaction processing method in a blockchain in an embodiment of this specification. The method can be executed by, for example, node 1 in the blockchain, where node 1 is currently a slave node.

As shown in Figure 2, first, in step S210, node 1 obtains information m1 and transaction Tx1, wherein information m1 is stored after node 1 is set as a slave node, and is used to indicate turning off the pre-execution function, that is, instructing node 1 to verify the transaction after receiving it and not perform pre-execution.

After node 1 determines that it has switched from a master node to a slave node, or when node 1 determines that When its own identity is a slave node, the information m1 can be stored in a local preset location to instruct node 1 to verify the transaction after receiving it without pre-execution.

Node 1 may receive transaction Tx1 from the client. Different nodes in the blockchain may receive different transactions from multiple clients. After receiving transaction Tx1, node 1 may read information related to transaction preprocessing from the local computer. If information m1 is stored locally, the information m1 may be read locally.

In step S220, after reading the information m1, node 1 verifies the transaction Tx1 according to the instructions of the information m1.

The verification of the transaction includes, for example, verification of the transaction signature, verification of the GAS balance of the transaction sending account, verification of the legality of the transaction, etc. According to the information m1, node 1 only verifies the transaction Tx1 without pre-execution.

In step S230, node 1 stores transaction Tx1 if verification is successful.

When the transaction Tx1 is verified, node 1 can store the transaction Tx1 in, for example, a verified transaction queue. While storing the transaction Tx1, node 1 also sends the transaction Tx1 to the current master node so that the master node can pre-execute the transaction Tx1.

In the case where node 1 is converted from a master node to a slave node, node 1 also includes a pre-execution transaction queue stored when it is a master node. The pre-execution transaction queue stores verified and pre-executed transactions. Node 1 can send the transactions in the pre-execution transaction queue to the current master node so that the master node can re-pre-execute these transactions and reach consensus on these transactions.

FIG3 is a flow chart of a transaction processing method in a blockchain in an embodiment of the present specification, which corresponds to the method shown in FIG2 , and the method may be, for example, a consensus service, a cache service, and a pre-execution service in node 1. Each service includes multiple executable bodies (such as processes) for implementing the preset functions of the service, and the multiple processes included in each service may be executed in parallel.

As shown in FIG. 3 , in step S301 , the consensus service determines that node 1 is a slave node.

After being enabled, node 1 can negotiate with other consensus nodes to determine that it is a slave node. Alternatively, if node 1 fails as a master node and is determined by other consensus nodes to be converted to a slave node, node 1 can obtain information about its conversion to a slave node from other consensus nodes after the failure is recovered. After determining that it is a slave node, node 1 can provide this information to the consensus service.

In step S303, the cache service caches the transaction received from the user device.

Node 1 may be connected to a user device to receive a transaction (such as the transaction Tx1 described above) from a client of the user device, and the cache service may cache the transaction Tx1. Specifically, the cache service may store the transaction Tx1 in an unverified transaction queue.

In step S305, the consensus service calls the disable interface provided by the cache service.

The disable interface is used to set indication information, and the indication information is used to indicate to turn off the pre-execution function, that is, only verify the received transaction without pre-execution.

In step S307, in response to the call to the disable interface, the cache service sets the value of the variable flag to a preset value for indicating that the pre-execution function is disabled.

In response to the consensus service's call to the disable interface, the cache service executes the disable interface and sets the variable flag in the cache service to a preset value (e.g., 1) for indicating that the pre-execution function is turned off, where the value of the variable flag before the setting is, for example, the default value, or when node 1 is transformed from a master node to a slave node, the value of the variable flag before the setting is a preset value (e.g., 0) for indicating that the pre-execution function is turned on.

In step S309, the pre-execution service requests a transaction from the cache service.

The pre-execution service may request the cache service for the newly received transaction to pre-process the transaction.

In step S311, the cache service sends a transaction Tx1 and a preset value of the variable flag for indicating closing the pre-execution operation to the pre-execution service.

In response to the request of the pre-execution service, the cache service obtains several transactions from the cached transactions and sends the several transactions and "flag=1" to the pre-execution service. The several transactions include, for example, transaction Tx1. The following steps are described by taking transaction Tx1 as an example.

In step S313, after receiving the transaction Tx1 and "flag=1", the pre-execution service verifies the received transaction Tx1 according to "flag=1" without performing pre-execution.

In step S315, when the pre-execution service verifies the transaction Tx1 successfully, it may send the verification result to the cache service.

In step S317, if the cache service determines that the verification is successful based on the received verification result, the transaction Tx1 is placed in the verified transaction queue.

In one embodiment, when slave node 1 determines that it has been converted from a master node to a slave node, since the pre-execution service in the slave node turns off the pre-execution function and only retains the verification function, the number of pre-execution service instances (such as the number of processes) can be reduced, thereby achieving a dynamic scaling effect.

The slave node pre-processes the received transaction as shown in FIG2 or 3, and stores the transaction in the transaction queue according to the flag value after the transaction is verified, so that when the slave node is converted from a slave node to a master node, it can obtain the verified transaction from the verified transaction queue for pre-execution without transaction loss, avoiding the need for the client to resend the transaction, and improving the transaction processing efficiency in the blockchain.

Figure 4 is a flow chart of a transaction processing method in a blockchain in an embodiment of this specification. The method can be executed by, for example, node 2 in the blockchain, where node 2 is currently the master node.

As shown in Figure 4, first, in step S410, node 2 obtains information m2 and transaction Tx2, wherein information m2 is stored after node 2 is set as the master node, and is used to indicate to turn on the pre-execution function, that is, to verify the transaction after receiving it, and pre-execute the transaction after the verification is passed.

After node 2 determines that its identity has been converted from a slave node to a master node, or when node 2 determines that its identity is a master node during initial startup, it can store information m2 in a local preset location to instruct node 2 to enable the pre-execution function, that is, to verify and pre-execute the transaction after receiving the transaction.

Node 2 may receive transaction Tx2 from a client or other consensus node. Different nodes in the blockchain may receive different transactions from multiple clients. After receiving transaction Tx2, node 2 may read information related to transaction preprocessing from the local computer. If information m2 is stored locally, information m2 may be read locally.

In step S420, after reading the information m2, node 2 verifies the transaction Tx2 according to the instructions of the information m2, and pre-executes the transaction Tx2 if the verification passes.

As described above, the verification of the transaction includes, for example: verification of the transaction signature, verification of the GAS balance of the transaction sending account, verification of the legality of the transaction, etc. After node 2 verifies transaction Tx2, it pre-executes transaction Tx2. Specifically, node 2 can execute transaction Tx2 based on the state value read from the state database to obtain a pre-execution read-write set of transaction Tx2. The pre-execution read-write set includes a pre-execution read set and a pre-execution write set. The pre-execution read set includes the variable key or key-value pair read by node 2 during the pre-execution of transaction Tx2, and the pre-execution write set includes the variable key or key-value pair updated by node 2 during the pre-execution of transaction Tx2.

In step S430, node 2 stores transaction Tx2 and its pre-execution read-write set.

After completing the pre-execution of transaction Tx2, node 2 can store transaction Tx2 and its pre-execution read-write set in the pre-execution transaction queue. Subsequently, node 2 can obtain a batch of transactions and their read-write sets from the pre-execution transaction queue and generate a consensus proposal, which can include the batch of transactions and their read-write sets. Node 2 can send the consensus proposal to each slave node to reach a consensus on the consensus proposal.

In the case where node 2 is converted from a slave node to a master node, node 2 also includes a verified transaction queue stored when it was a slave node, in which verified but non-pre-executed transactions are stored. Node 2 can re-pre-execute transactions in the verified transaction queue and store these transactions and their pre-executed read-write sets in the pre-executed transaction queue.

FIG5 is a flow chart of a transaction processing method in a blockchain in an embodiment of this specification, which corresponds to the method shown in FIG4 and can be implemented by, for example, a consensus service, a cache service, and a pre-execution service in node 2. Each service includes multiple executable bodies (such as processes) for implementing the preset functions of the service, and the multiple processes included in each service can be executed in parallel.

As shown in FIG. 5 , in step S501 , the consensus service determines node 2 as the master node.

After being enabled, Node 2 can negotiate with other consensus nodes to determine itself as the master node. Alternatively, Node 2 is determined by multiple consensus nodes to be the new master node after the previous master node fails. After Node 2 determines itself as the master node, it can provide this information to the consensus service.

In step S503, the cache service caches the received transaction.

Node 2 can be connected to a user device to receive a transaction (such as the above transaction Tx2) from a client of the user device, and the cache service can cache the transaction Tx2. Node 2, as a master node, can also receive transactions received by each slave node from the client and cache the transaction.

In step S505, the consensus service calls the start interface (reset interface) provided by the cache service.

The reset interface is used to set indication information, and the indication information is used to instruct node 2 to enable the pre-execution function, that is, to verify the received transaction and pre-execute it after the verification passes.

In step S507, in response to the call to the reset interface, the cache service sets the value of the variable flag to a preset value for indicating that the pre-execution function is enabled.

In response to the consensus service's call to the reset interface, the cache service executes the reset interface and sets the variable flag in the cache service to a preset value (e.g., 0) for indicating that the pre-execution function is turned on, where the value of the variable flag before the setting is, for example, the default value, or in the case where node 2 is transformed from a slave node to a master node, the value of the variable flag before the setting is a preset value (e.g., 1) for indicating that the pre-execution function is turned off.

In step S509, the pre-execution service requests a transaction from the cache service.

The pre-execution service may request the cache service for the newly received transaction to pre-process the transaction.

In step S511, the cache service sends the transaction Tx2 and a preset value of the variable flag to the pre-execution service for indicating the start of the pre-execution operation.

In response to the request of the pre-execution service, the cache service obtains several transactions from the cached transactions and sends the several transactions and "flag=0" to the pre-execution service. The several transactions include, for example, transaction Tx2. The following steps are described by taking transaction Tx2 as an example.

In step S513, after receiving transaction Tx2 and "flag=0", the pre-execution service verifies the received transaction Tx2 according to "flag=0", and pre-executes transaction Tx2 after the verification passes, to obtain the pre-execution read-write set of transaction Tx2.

In step S515, the pre-execution service sends the pre-execution read-write set of transaction Tx2 to the cache service.

In step S517, the cache service puts the transaction Tx2 and its pre-execution read-write set into the pre-execution transaction queue.

When node 2 is converted from a slave node to a master node, node 2 also includes a verified transaction queue stored when it is a slave node, in which verified but not pre-executed transactions are stored. The cache service in node 2 can send the transactions in the verified transaction queue together with "flag=0" to the pre-execution service, so that the pre-execution service can pre-execute these transactions, and send the pre-execution read-write sets of these transactions to the cache service, so that the cache service can store these transactions and their pre-execution read-write sets in the pre-execution transaction queue.

In one embodiment, when slave node 2 determines that it is converted from a slave node to a master node, since the pre-execution function is enabled in the pre-execution service in the slave node, the computing task is increased, and therefore the number of pre-execution service instances (e.g., the number of processes) can be increased, thereby achieving the effect of dynamic capacity.

The master node pre-processes the received transaction as shown in FIG4 or FIG5. When the master node is converted from a slave node to a master node, the verified transaction can be obtained from the verified transaction queue for pre-execution according to the value of the variable flag without losing the transaction, thus avoiding the need for the client to resend the transaction and improving the transaction processing efficiency in the blockchain.

FIG6 is an architecture diagram of a blockchain node in an embodiment of this specification, wherein the blockchain node is currently a slave node, and is used to execute the method shown in FIG2, FIG3, FIG4 or FIG5, including:

An acquisition unit 61 is used to acquire a first transaction and first information stored locally, where the first information is used to indicate to close the pre-execution function;

a verification unit 62, configured to verify the first transaction according to the first information;

The storage unit 63 is used to store the first transaction when the verification is successful.

The embodiments of this specification also provide a computer-readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method shown in FIG. 2 , FIG. 3 , FIG. 4 , or FIG. 5 .

The embodiments of this specification also provide a blockchain node, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method shown in FIG. 2, FIG. 3, FIG. 4 or FIG. 5 is implemented.

In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs. The original code before compilation must also be written in a specific programming language, which is called Hardware Description Language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby) The most commonly used languages are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should be clear to those skilled in the art that the method flow can be easily obtained by programming the method flow in the above-mentioned hardware description languages and programming it into the integrated circuit.

The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer readable medium storing a computer readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that in addition to implementing the controller in a purely computer readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the means for implementing various functions included therein may also be considered as a structure within the hardware component. Or even, the means for implementing various functions may be considered as both a software module for implementing the method and a structure within the hardware component.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and/or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The present invention is a flowchart of a method, apparatus (system), and computer program product according to an embodiment of the present invention. The flowchart and/or block diagram are described in detail. It should be understood that each process and/or block in the flowchart and/or block diagram, as well as the combination of the processes and/or blocks in the flowchart and/or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate a device for implementing the functions specified in one or more processes in the flowchart and/or one or more blocks in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

In a typical configuration, a computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined in this article, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments are mutually exclusive. Just refer to each other, each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts refer to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, in the absence of contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples.

The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims.

Claims (14)

A transaction processing method in a blockchain, executed by a first node, where the first node is currently a slave node, the method comprising: Acquire a first transaction and first information stored locally, where the first information is used to indicate that a pre-execution function is disabled; verifying the first transaction according to the first information; If the verification is successful, the first transaction is stored. The method according to claim 1 further includes: sending the first transaction to a current master node. The method according to claim 1, further comprising: After determining that the first node is set as a slave node, setting the value of the first variable to a first preset value, where the first preset value is used to indicate turning off the pre-execution function; The obtaining of the first information comprises: The first preset value of the first variable is read as the first information. According to the method of claim 3, the first node includes a pre-execution service, and the obtaining of the first information stored locally includes: the pre-execution service reading the first preset value of the first variable. According to the method of claim 4, the first node includes a cache service and a consensus service, and after determining that the first node is set as a slave node, setting the value of the first variable to a first preset value includes: After determining that the first node is set as a slave node, the consensus service calls the first interface of the cache service, and the cache service sets the value of the first variable to the first preset value according to the call to the first interface. The method according to claim 4 further comprises: after determining that the first node is set as a slave node, reducing the number of instances of the pre-execution service. The method according to claim 5, further comprising: After determining that the first node is set to be converted from a slave node to a master node, second information is stored, where the second information is used to indicate starting a pre-execution function. The method according to claim 7, further comprising: obtaining the second information and the second transaction; Verifying the second transaction according to the second information, and pre-executing the second transaction after the verification is passed, to obtain a pre-execution read-write set of the second transaction; The second transaction and a pre-execution read-write set of the second transaction are stored. The method according to claim 8 further includes: after determining that the first node is set to be converted from a slave node to a master node, obtaining a locally stored verified third transaction; pre-executing the third transaction to obtain a pre-execution read-write set of the third transaction; and storing the third transaction and the pre-execution read-write set of the third transaction. The method according to claim 8, wherein storing the second information comprises: After determining that the first node is set to be converted from a slave node to a master node, setting the value of the first variable to a second preset value, where the second preset value is used to indicate starting a pre-execution function; The obtaining of the second information comprises: The second preset value of the first variable is read as the second information. According to the method of claim 10, setting the value of the first variable to a second preset value comprises: The consensus service calls the second interface of the cache service, and the cache service sets the value of the first variable to the second preset value according to the call to the second interface. The method according to claim 7 further includes: after determining that the first node is set to be converted from a slave node to a master node, increasing the number of instances of the pre-execution service. A blockchain node, which is currently a slave node, includes: an acquisition unit, configured to acquire first information and a first transaction, wherein the first information is used to indicate closing of a pre-execution function; a verification unit, configured to verify the first transaction according to the first information; The storage unit is used to store the first transaction when the verification is passed. A blockchain node comprises a memory and a processor, wherein the memory stores an executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 12 is implemented.