Transaction processing method in a blockchain and blockchain node

Abstract

A transaction processing method and a blockchain node are disclosed, wherein the method is executed by a first node, which is currently a slave node, and the method includes: obtaining first information and a first transaction, wherein the first information is used to indicate the closure of a pre-execution function; verifying the first transaction based on the first information; and storing the first transaction if the verification passes.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a transaction processing method and a blockchain node in a blockchain. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a transaction processing method in a blockchain to improve the efficiency of transaction processing in a blockchain.

[0004] This specification provides a transaction processing method in a blockchain, executed by a first node, which is currently a slave node. The method includes:

[0005] Obtain the first transaction and the first information stored locally, the first information being used to instruct the pre-execution function to be disabled;

[0006] Based on the first information, the first transaction is verified;

[0007] If the verification passes, the first transaction is stored.

[0008] A second aspect of this specification provides a blockchain node, which is currently a slave node, comprising:

[0009] The acquisition unit is used to acquire the first transaction and the first information stored locally, wherein the first information is used to indicate the shutdown of the pre-execution function;

[0010] A verification unit is used to verify the first transaction based on the first information;

[0011] A storage unit is used to store the first transaction if the verification is successful.

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

[0013] A fourth aspect of this specification provides a blockchain node, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0014] In the solution provided in the embodiments of this 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. This allows the slave node to retrieve the verified transaction from the verified transaction queue for pre-execution when it is converted from a slave node to a master node, without the loss of transactions. This avoids the need for the client to resend the transaction and improves the transaction processing efficiency in the blockchain. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a diagram of a blockchain architecture in one embodiment;

[0017] Figure 2 This is a flowchart of a transaction processing method in a blockchain according to an embodiment of this specification;

[0018] Figure 3 This is a flowchart of a transaction processing method in a blockchain as described in the embodiments of this specification;

[0019] Figure 4 This is a flowchart of a transaction processing method in a blockchain according to another embodiment of this specification;

[0020] Figure 5 This is a flowchart of a transaction processing method in a blockchain according to another embodiment of this specification;

[0021] Figure 6 This is an architecture diagram of a blockchain node in one of the embodiments of this specification. Detailed Implementation

[0022] 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 with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0023] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 The blockchain architecture diagram shown indicates that the blockchain includes N nodes. Figure 1 The diagram illustrates nodes 1 through 8. The lines connecting the nodes schematically represent P2P (Peer-to-Peer) connections, such as TCP connections, used for data transfer between nodes. These nodes can store the entire ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain can produce the same state by executing the same transactions, and each node can store the same state database.

[0024] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0025] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed through transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction that points to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner.

[0026] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1 In the blockchain shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, they determine the contract address "0x6f8ae93…". Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the contract's state storage, thus the contract is successfully created.

[0027] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field is the aforementioned "0x6f8ae93…", which is the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0028] One of the decentralized characteristics that distinguishes blockchain technology from traditional technologies is its distributed ledger system, where records are kept on multiple nodes, rather than a centralized system. For a blockchain system to become a robust, publicly accessible, and tamper-proof decentralized system of honest and trustworthy data records, it needs to ensure the security, clarity, and irreversibility of distributed data records in the shortest possible time. In different types of blockchain networks, consensus algorithms are typically used to maintain consistency across the nodes recording the ledger—the consensus mechanisms mentioned earlier. For example, blockchain nodes can implement block-level consensus mechanisms. After a node (e.g., a unique node) generates a block, if this block is recognized by other nodes, those nodes record the same block. As another example, blockchain nodes can implement transaction-level consensus mechanisms. After a node (e.g., a unique node) acquires a blockchain transaction, if this transaction is recognized by other nodes, each node that recognized the transaction can add it to its own latest maintained block, ultimately ensuring that all nodes produce the same latest block. A consensus mechanism is a mechanism by which blockchain nodes reach a unified consensus on block information (or block data), ensuring that the latest block is accurately added to the blockchain. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), and Practical Byzantine Fault Tolerance (PBFT). In various consensus algorithms, consensus on a proposal is typically determined after a predetermined number of nodes reach agreement on the data to be agreed upon. Specifically, in the PBFT algorithm, for 3(f+1)+1>N≥3f+1 consensus nodes, f malicious nodes can be tolerated. That is, consensus is considered successful when at least 2f+1 of the N consensus nodes reach agreement.

[0029] Figure 1The blockchain shown may include master nodes and slave nodes. In a scenario where transactions are executed in parallel, the master node can pre-execute multiple transactions, obtaining a pre-execution read-write set for each transaction. This master node can then send a consensus proposal, including these transactions and their pre-execution read-write sets, to each slave node. After the consensus proposal is passed, each slave node can group the multiple transactions according to their pre-execution read-write sets and execute them in parallel based on the grouping results. In this scenario, typically, after receiving a transaction from a client, a slave node forwards the received transaction to the master node, allowing the master node to pre-execute the transaction. However, if the master node fails and needs to be replaced, the slave nodes may not have stored a batch of transactions already received from the client, resulting in the loss of this batch of transactions. The client then needs to resend these transactions to the blockchain, impacting business efficiency.

[0030] This specification provides a method for processing transactions in a blockchain. After receiving a transaction, a slave node verifies the received transaction based on its role-related information without pre-executing it. The transaction is stored after successful verification, which allows the slave node to directly obtain the verified transaction locally for consensus purposes in the event of a failure of the master node, thereby improving the transaction processing efficiency in the blockchain.

[0031] Figure 2 This is a flowchart illustrating a transaction processing method in a blockchain according to 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.

[0032] like Figure 2 As shown, firstly, in step S210, node 1 obtains information m1 and transaction Tx1. Information m1 is stored after node 1 is set as a slave node and is used to indicate that the pre-execution function is turned off, that is, to instruct node 1 to verify the transaction after receiving it and not to pre-execute it.

[0033] After Node 1 determines that its identity has changed from a master node to a slave node, or when Node 1 determines that its identity is a slave node during initial startup, it can store information m1 in a preset local location to instruct Node 1 to verify the transaction after receiving it, instead of pre-executing it.

[0034] Node 1 can receive transaction Tx1 from the client. Different nodes in the blockchain can receive different transactions from multiple clients. After receiving transaction Tx1, Node 1 can read information related to transaction preprocessing from its local storage. If information m1 is stored locally, it can read information m1 from its local storage.

[0035] In step S220, after reading information m1, node 1 verifies transaction Tx1 according to the instructions in information m1.

[0036] The verification of transactions includes, for example, verification of the transaction signature, verification of the GAS balance of the account sending the transaction, and verification of the legality of the transaction. Based on information m1, node 1 only verifies transaction Tx1 and does not pre-execute it.

[0037] In step S230, if the verification is successful, node 1 stores transaction Tx1.

[0038] If transaction Tx1 passes verification, node 1 can store it in, for example, a queue of verified transactions. Simultaneously, node 1 sends transaction Tx1 to the current master node so that the master node can pre-execute it.

[0039] When node 1 is converted from a master node to a slave node, node 1 also includes a pre-executed transaction queue stored when it was a master node. This pre-executed transaction queue stores verified and pre-executed transactions. Node 1 can send the transactions in the pre-executed transaction queue to the current master node so that the master node can re-pre-execute these transactions and reach consensus on them.

[0040] Figure 3 This is a flowchart illustrating a transaction processing method in a blockchain as described in an embodiment of this specification. The method is related to... Figure 2 The method described can be executed by, for example, the consensus service, caching service, and pre-execution service in node 1. Each service includes multiple executors (e.g., processes) to implement the preset functions of that service, and the multiple processes included in each service can be executed in parallel.

[0041] like Figure 3 As shown, in step S301, the consensus service determines that node 1 is a slave node.

[0042] After being activated, Node 1 can negotiate with other consensus nodes to determine whether it is a slave node. Alternatively, if Node 1 fails while acting as the master node and is determined by other consensus nodes to be converted to a slave node, Node 1 can obtain the information about its conversion from the other consensus nodes after the failure is resolved. After determining that it is a slave node, Node 1 can provide this information to the consensus service.

[0043] In step S303, the caching service caches the transactions received from the user equipment.

[0044] Node 1 can connect to a user device to receive transactions (such as transaction Tx1 mentioned above) from the user device's client. The caching service can cache transaction Tx1. Specifically, the caching service can store transaction Tx1 in the unverified transaction queue.

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

[0046] The disable interface is used to set an indication message that indicates the pre-execution function is disabled, meaning that only verification is performed on the received transactions, and no pre-execution is performed.

[0047] In step S307, in response to the call to the disable interface, the caching service sets the value of the variable flag to a preset value used to indicate that the pre-execution function is disabled.

[0048] In response to the consensus service's call to the disable interface, the caching service executes the disable interface and sets the variable flag in the caching service to a preset value (e.g., 1) used to indicate that the pre-execution function is disabled. The value of the variable flag before this setting is, for example, the default value, or, if node 1 is changed from a master node to a slave node, the value of the variable flag before this setting is a preset value (e.g., 0) used to indicate that the pre-execution function is enabled.

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

[0050] The pre-execution service can request newly received transactions from the caching service to preprocess those transactions.

[0051] In step S311, the caching service sends transaction Tx1 and the variable flag with a preset value to the pre-execution service to indicate the shutdown of the pre-execution operation.

[0052] In response to a request from the pre-execution service, the caching service retrieves several transactions from the cached transactions and sends these transactions along with "flag=1" to the pre-execution service. These transactions may include, for example, transaction Tx1. The following steps are described using transaction Tx1 as an example.

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

[0054] In step S315, if the pre-execution service verifies the transaction Tx1 and the verification result passes, it can send the verification result to the cache service.

[0055] In step S317, if the caching service determines that the verification is successful based on the received verification result, it will place transaction Tx1 into the verified transaction queue.

[0056] In one implementation, when slave node 1 determines that it has been converted from master node to slave node, since the pre-execution service in the slave node has turned off the pre-execution function and only retained the verification function, the number of pre-execution service instances (e.g., the number of processes) can be reduced, thereby achieving the effect of dynamic scaling down.

[0057] From the node, through, as Figure 2 or Figure 3 The received transaction is preprocessed. After the transaction is verified according to the flag value, it is stored in the transaction queue. This allows the slave node to retrieve verified transactions from the verified transaction queue for pre-execution when it is converted from a slave node to a master node, without the loss of transactions. This avoids the need for the client to resend transactions and improves the transaction processing efficiency in the blockchain.

[0058] Figure 4 This is a flowchart illustrating a transaction processing method in a blockchain according to 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.

[0059] like Figure 4 As shown, firstly, in step S410, node 2 obtains information m2 and transaction Tx2. Information m2 is stored after node 2 is set as the master node and is used to indicate the start of the pre-execution function, that is, to verify the transaction after receiving it and pre-execute the transaction after the verification is successful.

[0060] After Node 2 determines its identity from a slave node to a master node, or when Node 2 determines its identity as a master node during initial startup, it can store information m2 in a preset local location to instruct Node 2 to enable the pre-execution function, that is, to verify and pre-execute transactions after receiving them.

[0061] Node 2 can receive transaction Tx2 from a client or other consensus nodes. Different nodes in the blockchain can receive different transactions from multiple clients. After receiving transaction Tx2, Node 2 can read information related to transaction preprocessing locally; specifically, if information m2 is stored locally, it can read information m2 from its local storage.

[0062] In step S420, after reading information m2, node 2 verifies transaction Tx2 according to the instructions in information m2. If the verification is successful, transaction Tx2 is pre-executed.

[0063] As mentioned above, the verification of transactions includes, for example, verification of the transaction signature, verification of the GAS balance of the account sending the transaction, and verification of the transaction's legality. After Node 2 successfully verifies transaction Tx2, it pre-executes transaction Tx2. Specifically, Node 2 can execute transaction Tx2 based on the state values ​​read from the state database, obtaining a pre-execution read / write set for transaction Tx2. This pre-execution read / write set includes a pre-execution read set and a pre-execution write set. The pre-execution read set includes variable keys or key-value pairs read by Node 2 during the pre-execution of transaction Tx2, and the pre-execution write set includes variable keys or key-value pairs updated by Node 2 during the pre-execution of transaction Tx2.

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

[0065] 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 retrieve a batch of transactions and their read-write sets from the pre-execution transaction queue, generate a consensus proposal, which may include the batch of transactions and their read-write sets. Node 2 can then send the consensus proposal to each slave node to reach a consensus on the proposal.

[0066] When node 2 is converted from a slave node to a master node, node 2 also includes a queue of verified transactions stored when it was a slave node. This queue contains verified but unexecuted transactions. Node 2 can re-execute the transactions in the verified transaction queue and store these transactions and their pre-executed read / write sets into the pre-executed transaction queue.

[0067] Figure 5 This is a flowchart illustrating a transaction processing method in a blockchain as described in an embodiment of this specification. The method is related to... Figure 4 The method shown can be executed by, for example, the consensus service, caching service, and pre-execution service in node 2. Each service includes multiple executors (e.g., processes) to implement the preset functions of that service, and the multiple processes included in each service can be executed in parallel.

[0068] like Figure 5 As shown, in step S501, the consensus service determines node 2 as the master node.

[0069] After being activated, Node 2 can negotiate with other consensus nodes to determine itself as the master node. Alternatively, Node 2 may be determined as the new master node by multiple consensus nodes after the previous master node fails. Once determined as the master node, Node 2 can provide this information to the consensus service.

[0070] In step S503, the caching service caches the received transactions.

[0071] Node 2 can connect to the user equipment to receive transactions (such as transaction Tx2 mentioned above) from the user equipment's client, and the caching service can cache transaction Tx2. As the master node, Node 2 can also receive transactions received from clients by each slave node and cache those transactions.

[0072] In step S505, the consensus service calls the reset interface provided by the cache service.

[0073] The reset interface is used to set indication information, which instructs node 2 to enable the pre-execution function, that is, to verify the received transactions and pre-execute them after the verification is successful.

[0074] In step S507, in response to the call to the reset interface, the caching service sets the value of the variable flag to a preset value used to indicate that the pre-execution function is enabled.

[0075] In response to the consensus service's call to the reset interface, the caching service executes the reset interface and sets the variable flag in the caching service to a preset value (e.g., 0) used to indicate that the pre-execution function is enabled. The value of the variable flag before this setting is, for example, the default value, or, if node 2 is transformed from a slave node to a master node, the value of the variable flag before this setting is a preset value (e.g., 1) used to indicate that the pre-execution function is disabled.

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

[0077] The pre-execution service can request newly received transactions from the caching service to preprocess those transactions.

[0078] In step S511, the caching service sends transaction Tx2 and the variable flag with a preset value to the pre-execution service to indicate the start of the pre-execution operation.

[0079] In response to a request from the pre-execution service, the caching service retrieves several transactions from the cached transactions and sends these transactions along with "flag=0" to the pre-execution service. These transactions may include, for example, transaction Tx2. The following steps are described using transaction Tx2 as an example.

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

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

[0082] In step S517, the caching service puts transaction Tx2 and its pre-execution read / write set into the pre-execution transaction queue.

[0083] When Node 2 is converted from a slave node to a master node, Node 2 also includes the verified transaction queue stored when it was a slave node. This transaction queue stores verified but not pre-executed transactions. The caching service in Node 2 can send the transactions in the verified transaction queue along 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 set of these transactions to the caching service, so that the caching service can store these transactions and their pre-execution read-write set into the pre-execution transaction queue.

[0084] In one implementation, when node 2 determines that it has been converted from a slave node to a master node, since the pre-execution service in the slave node has enabled the pre-execution function, the computation task is increased. Therefore, the number of pre-execution service instances (e.g., the number of processes) can be increased to achieve the effect of dynamic expansion.

[0085] In the master node, through such Figure 4 or Figure 5 The received transactions are preprocessed as shown. When the master node is converted from a slave node to a master node, the verified transactions can be retrieved from the verified transaction queue according to the value of the variable flag and pre-executed, so that the transaction will not be lost and the client will not need to resend the transaction, thus improving the transaction processing efficiency in the blockchain.

[0086] Figure 6 This is an architecture diagram of a blockchain node in one embodiment of this specification. The blockchain node is currently a slave node, used to perform actions such as... Figure 2 , Figure 3 , Figure 4 or Figure 5 The method shown includes:

[0087] Acquisition unit 61 is used to acquire the first transaction and the first information stored locally, wherein the first information is used to indicate the shutdown of the pre-execution function;

[0088] Verification unit 62 is used to verify the first transaction based on the first information;

[0089] Storage unit 63 is used to store the first transaction if the verification is successful.

[0090] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 2 , Figure 3 , Figure 4 or Figure 5 The method shown.

[0091] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 2 , Figure 3 , Figure 4 or Figure 5 The method shown.

[0092] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0093] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0095] While one or more embodiments of this specification provide the operational steps of the methods 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 listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0096] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0097] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can 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, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0098] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0099] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0101] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0102] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0103] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this 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.

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

[0105] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0106] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A transaction processing method in a blockchain, executed by a first node, which is currently a slave node, the method comprising: Obtain the first transaction and the first information stored locally, the first information being used to instruct the pre-execution function to be disabled; Based on the first information, the first transaction is verified; If the verification passes, the first transaction is stored.

2. The method according to claim 1, further comprising: Send the first transaction to the current master node.

3. The method according to claim 1, further comprising: After determining that the first node is set as a slave node, the value of the first variable is set to a first preset value, which is used to indicate that the pre-execution function is turned off; The acquisition of the first information includes: Read the first preset value of the first variable and use it as the first information.

4. The method according to claim 3, wherein the first node includes a pre-execution service, and the step of obtaining the first information stored locally includes: The pre-execution service reads the first preset value of the first variable.

5. The method according to claim 4, wherein the first node includes a caching service and a consensus service, and the step of setting the value of the first variable to a first preset value after determining that the first node is set as a slave node includes: After determining that the first node is set as a slave node, the consensus service calls the first interface of the caching service, and the caching service sets the value of the first variable to the first preset value according to the call to the first interface.

6. The method according to claim 4, further comprising: After determining that the first node is set as a slave node, the number of instances of the pre-execution service is reduced.

7. 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, the second information is stored to indicate that the pre-execution function is enabled.

8. The method according to claim 7, further comprising: Obtain the second information and the second transaction; Based on the second information, the second transaction is verified, and after the verification is successful, the second transaction is pre-executed to obtain the pre-execution read-write set of the second transaction; Store the second transaction and the pre-execution read / write set of the second transaction.

9. The method according to claim 8, further comprising: After determining that the first node has been converted from a slave node to a master node, retrieve the verified third transaction from local storage; The third transaction is pre-executed to obtain a pre-execution read / write set of the third transaction; the third transaction and the pre-execution read / write set of the third transaction are stored.

10. 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, the value of the first variable is set to a second preset value, which is used to indicate that the pre-execution function is enabled; The acquisition of the second information includes: The second preset value of the first variable is read as the second information.

11. The method according to claim 10, wherein setting the value of the first variable to a second preset value comprises: The consensus service calls the second interface of the caching service, and the caching service sets the value of the first variable to the second preset value according to the call to the second interface.

12. The method of claim 7, further comprising: After determining that the first node is set to be converted from a slave node to a master node, the number of instances of the pre-execution service is increased.

13. A blockchain node, wherein the blockchain node is currently a slave node, comprising: The acquisition unit is used to acquire first information and a first transaction, wherein the first information is used to instruct the pre-execution function to be closed; The verification unit is used to verify the first transaction based on the first information; A storage unit is used to store the first transaction if the verification is successful.

14. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-12.

Images