Transaction processing method and device, equipment, storage medium and product

Abstract

The invention discloses a transaction processing method and device, equipment, a storage medium and a product. The method comprises the following steps: if at least one to-be-executed message exists in a to-be-processed message queue in a current message execution period, determining a smart contract which needs to be called and corresponds to each to-be-executed message; for any to-be-executed message, judging whether the smart contract corresponding to the to-be-executed message is in an execution occupation state or not; if not, selecting a target transaction executor from at least one candidate transaction executor in the current message execution period; and generating a message execution request according to the contract address of the smart contract of the corresponding to-be-executed message, sending the message execution request to the target transaction executor, calling the corresponding smart contract to process the message by the target transaction executor based on the message execution request, and obtaining and feeding back a message execution result. According to the technical scheme of the embodiment, the utilization rate of the multi-core CPU is improved, so that the transaction processing efficiency based on the block chain is further improved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a transaction processing method, device, equipment, storage medium and product. Background Art

[0002] In the blockchain-based transaction process, in order to ensure the transactional nature of the transaction, the transaction is usually carried out in series. Specifically, the transactions are sorted first, and then the smart contract is executed with a single thread to avoid transaction confusion and data conflicts caused by out-of-order execution. Even if there is a multi-core CPU (Central Processing Unit) in a server, the operating system supports multi-threading and multi-process, and there are multiple nodes and multiple servers in the network, all transactions are also methodically and strictly calculated on a single core on each computer according to a single thread, while other cores in the multi-core CPU that are not executing tasks are completely idle. Therefore, how to improve the utilization of multi-core CPUs, thereby further improving the efficiency of transaction processing, has become a problem that needs to be solved urgently. Summary of the invention

[0003] The present invention provides a transaction processing method, device, equipment, storage medium and product to improve the utilization rate of multi-core CPU, thereby further improving the efficiency of transaction processing based on blockchain.

[0004] According to one aspect of the present invention, a transaction processing method is provided, the method comprising:

[0005] If there is at least one message to be executed in the pending message queue in the current message execution cycle, determine the smart contracts to be called corresponding to each of the pending messages;

[0006] For any pending message, determine whether the smart contract corresponding to the pending message is in the execution occupied state;

[0007] If not, selecting a target transaction executor from at least one candidate transaction executor in the current message execution cycle;

[0008] According to the contract address of the smart contract of the corresponding message to be executed, a message execution request is generated, and the message execution request is sent to the target transaction executor. The target transaction executor calls the corresponding smart contract to process the message based on the message execution request, and obtains and feeds back the message execution result.

[0009] According to another aspect of the present invention, there is provided a transaction processing device, the device comprising:

[0010] A smart contract determination module, used to determine the smart contracts to be called corresponding to each of the to-be-executed messages if there is at least one to-be-executed message in the to-be-processed message queue in the current message execution cycle;

[0011] A status judgment module is used to judge whether the smart contract corresponding to any pending message is in the execution occupied state;

[0012] An executor selection module, configured to select a target transaction executor from at least one candidate transaction executor in the current message execution cycle if the smart contract corresponding to the message to be executed is not in an execution occupied state;

[0013] The execution request generation module is used to generate a message execution request according to the contract address of the smart contract of the corresponding message to be executed, and send the message execution request to the target transaction executor. The target transaction executor calls the corresponding smart contract to process the message based on the message execution request, and obtains and feeds back the message execution result.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0015] at least one processor; and

[0016] a memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the transaction processing method described in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the transaction processing method described in any embodiment of the present invention when executed.

[0019] According to another aspect of the present invention, a computer program product is provided, comprising a computer program, wherein when the computer program is executed by a processor, the transaction processing method according to any embodiment of the present invention is implemented.

[0020] The technical solution of the embodiment of the present invention determines the smart contracts that need to be called corresponding to each message to be executed, and for any message to be executed, determines whether the smart contract corresponding to the message to be executed is in an execution occupied state. If not, selects a target transaction executor from at least one candidate transaction executor in the current message execution cycle, generates a message execution request according to the contract address of the smart contract of the corresponding message to be executed, and sends the message execution request to the target transaction executor. The target transaction executor calls the corresponding smart contract for message processing based on the message execution request, obtains and feeds back the message execution result, thereby realizing parallel execution of transactions of multiple smart contracts based on multi-core CPUs, improving the utilization rate of multi-core CPUs, and further improving transaction processing efficiency.

[0021] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0023] Figure 1 is a flow chart of a transaction processing method provided according to Embodiment 1 of the present invention;

[0024] Figure 2 is a flow chart of a transaction processing method provided according to Embodiment 2 of the present invention;

[0025] Figure 3 is a schematic diagram of the execution process of a transaction processing method provided according to Embodiment 3 of the present invention;

[0026] Figure 4 is a structural diagram of a transaction processing device provided according to a fourth embodiment of the present invention;

[0027] Figure 5 It is a schematic diagram of the structure of an electronic device for implementing the transaction processing method of an embodiment of the present invention. DETAILED DESCRIPTION

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

[0029] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0030] Embodiment 1

[0031] Figure 1 This is a flow chart of a transaction processing method provided in Embodiment 1 of the present invention. This embodiment is applicable to the case where blockchain transactions are executed in parallel in a multi-core CPU computing environment. The method can be executed by a transaction processing device, which can be implemented in the form of hardware and / or software. The transaction processing device can be configured in an electronic device, for example, the electronic device can be a scheduler.

[0032] The transaction processing scheme of this embodiment calls the smart contract of the blockchain to process the transaction, and there is no shared data between the smart contracts of the blockchain. Each smart contract has its own independent storage space. For any smart contract, other smart contracts except itself cannot perform read and write operations. The technical solution of this embodiment can be executed by a pre-configured scheduler, which can schedule multiple transactions of different contracts to be executed in parallel.

[0033] It should be noted that when there is a transaction task in the blockchain, the scheduler obtains the transaction block and performs block parsing on the currently obtained transaction block to obtain at least one transaction to be executed. The scheduler sorts all transactions to be executed and generates a transaction list. In the transaction list, there are transactions to be executed in a determined order. The scheduler can sort the transactions based on the parsing time of the corresponding transactions to be executed, or can sort them based on the transaction type, which is not limited in this embodiment.

[0034] Since this embodiment uses a method of parallel transaction processing of multiple smart contracts, this embodiment involves at least one message execution cycle, and at least one pending transaction is processed in each message execution cycle. This embodiment splits the different smart contract code blocks required to be called for all pending transactions into multiple code segments, and the code blocks of multiple different smart contracts are executed alternately, and the boundaries of the split are cross-contract calls and mutually exclusive resource access.

[0035] In a specific implementation, the scheduler parses the transaction block to obtain seven pending transactions, namely, transaction a, transaction b, transaction c, transaction d, transaction e, transaction f, and transaction g, and they correspond to the same or different smart contracts that need to be called. Among them, transaction a, transaction b, and transaction c correspond to contract A; transaction d and transaction e correspond to contract B; transaction f corresponds to contract C; transaction g corresponds to contract D. In the first message execution cycle, contract A can be called to execute transaction a, contract B can be called to execute transaction d, contract C can be called to execute transaction f, and contract D can be called to execute transaction g. In the second message execution cycle, contract A can be called to execute transaction b, and contract B can be called to execute transaction e. In the third message execution cycle, contract A can be called to execute transaction c. After the transactions in the third message execution cycle are executed, the transaction tasks of the current transaction block are executed.

[0036] This embodiment describes the execution process of the message to be executed and the process of the scheduler scheduling the transaction executor in any message execution cycle. Figure 1 As shown, the method specifically comprises the following steps:

[0037] S110: If there is at least one message to be executed in the pending message queue in the current message execution cycle, determine the smart contracts to be called corresponding to each pending message.

[0038] The pending message queue stores the pending messages that were not executed in the previous message execution cycle. If the pending message queue is empty, it can be determined that all transactions of the current transaction task have been executed.

[0039] It is understandable that the smart contracts required to execute different transactions may be the same or different. Therefore, the smart contracts that need to be called corresponding to each message to be executed can be determined.

[0040] S120. For any pending message, determine whether the smart contract corresponding to the pending message is in an execution occupied state.

[0041] In order to improve the convenience and efficiency of judging the status of smart contracts, a hash value that can represent uniqueness can be generated, and the current execution status of the smart contract can be judged based on the hash value.

[0042] In an optional embodiment, for any message to be executed, it is determined whether the smart contract corresponding to the message to be executed is in an execution occupied state, including: for any message to be executed, based on the contract address of the smart contract corresponding to the message to be executed, generating an address hash value corresponding to the message to be executed; determining whether the address hash value of the message to be executed is stored in a pre-constructed hash list to obtain a determination result; wherein the hash list stores the address hash values ​​of the smart contracts that are in the execution occupied state in the current message execution cycle; and determining whether the smart contract corresponding to the message to be executed is in the execution occupied state based on the determination result.

[0043] Since the contract addresses of different smart contracts are different, the address hash values ​​generated based on the contract addresses are different, which can uniquely represent the message to be executed.

[0044] Among them, the pre-built hash list stores the address hash values ​​of the smart contracts in the execution occupied state in the current message execution cycle. That is, when the smart contract is called to execute a task, the address hash value of the smart contract is stored in the hash list.

[0045] Exemplarily, it is determined whether the address hash value of the message to be executed is stored in a pre-built hash list. If so, it indicates that the smart contract corresponding to the message to be executed is in an execution occupied state; if not, it indicates that the smart contract corresponding to the message to be executed is in an unoccupied state.

[0046] S130: If not, select a target transaction executor from at least one candidate transaction executor in the current message execution cycle.

[0047] If the smart contract corresponding to the pending message is not in the execution occupied state, the target transaction executor is selected from at least one candidate transaction executor in the current message execution cycle. At the same time, the address hash value of the smart contract corresponding to the pending message is stored in the hash list.

[0048] The target transaction executor may be selected by randomly selecting from at least one candidate transaction executor. Alternatively, since the performance of CPUs to which different transaction executors belong is different, in order to further improve the accuracy of selecting the target transaction executor and improve the efficiency of transaction task execution, the target transaction executor may be selected in a targeted manner based on the performance differences of the CPUs to which the candidate transaction executors belong.

[0049] In an optional embodiment, a target transaction executor is selected from at least one candidate transaction executor in the current message execution cycle, including: selecting a reference transaction executor that is currently in an idle state from at least one candidate transaction executor; and determining the target transaction executor based on CPU-related information of the CPU to which each reference transaction executor belongs.

[0050] The CPU related information may include at least one of the number of supported threads, cache volume, bandwidth, and performance benchmark test.

[0051] The target transaction executor is selected based on the CPU related information of the CPU to which the reference transaction executor belongs. For example, a transaction executor that supports more threads, has a larger cache, or has a higher performance score in a performance benchmark test may be selected as the target transaction executor.

[0052] S140. Generate a message execution request according to the contract address of the smart contract of the corresponding message to be executed, and send the message execution request to the target transaction executor. The target transaction executor calls the corresponding smart contract to process the message based on the message execution request, and obtains and feeds back the message execution result.

[0053] Specifically, the target transaction executor parses the message execution request, obtains the contract address, and calls the corresponding smart contract to process the message according to the contract address, obtains the message execution result, and feeds the message execution result back to the scheduler. After receiving the message execution result, the scheduler removes the corresponding address hash value from the hash list and removes the executed message from the queue of pending messages in the current message execution cycle.

[0054] The technical solution of the embodiment of the present invention determines the smart contracts that need to be called corresponding to each message to be executed, and for any message to be executed, determines whether the smart contract corresponding to the message to be executed is in an execution occupied state. If not, selects a target transaction executor from at least one candidate transaction executor in the current message execution cycle, generates a message execution request according to the contract address of the smart contract of the corresponding message to be executed, and sends the message execution request to the target transaction executor. The target transaction executor calls the corresponding smart contract for message processing based on the message execution request, obtains and feeds back the message execution result, thereby realizing parallel execution of transactions of multiple smart contracts based on multi-core CPUs, improving the utilization rate of multi-core CPUs, and further improving transaction processing efficiency.

[0055] Embodiment 2

[0056] Figure 2 This is a flow chart of a transaction processing method provided in Embodiment 2 of the present invention. This embodiment is optimized and improved on the basis of the above-mentioned technical solutions.

[0057] Furthermore, the step of "sending the message execution request to the target transaction executor, and the target transaction executor performing message processing based on the message execution request, obtaining and feeding back the message execution result" is refined into "sending the message execution request to the target transaction executor, and the target transaction executor performing request parsing on the message execution request, obtaining the message to be processed, and performing message processing on the message to be processed; if there is a cross-contract call during the message processing of the message to be processed by the target transaction executor, the execution of the message to be processed is terminated, and the executed message execution context is obtained; the executed message execution context is used as the message execution result and fed back." to improve the way the target transaction executor handles messages.

[0058] It should be noted that for the parts not described in detail in the embodiments of the present invention, reference can be made to the descriptions of other embodiments. Figure 2 As shown, the method comprises the following specific steps:

[0059] S210: If there is at least one message to be executed in the pending message queue in the current message execution cycle, determine the smart contracts to be called corresponding to each pending message.

[0060] S220. For any pending message, determine whether the smart contract corresponding to the pending message is in an execution occupied state.

[0061] S230: If not, select a target transaction executor from at least one candidate transaction executor in the current message execution cycle.

[0062] S240. Generate a message execution request according to the contract address of the smart contract corresponding to the message to be executed.

[0063] S250: Send the message execution request to the target transaction executor, which parses the message execution request to obtain a message to be processed and processes the message to be processed.

[0064] The target transaction executor parses the contract address of the smart contract and calls the corresponding smart contract based on the contract address to process the message to be processed.

[0065] S260. If there is a cross-contract call in the process of the target transaction executor processing the message to be processed, the execution of the message to be processed is terminated, and the executed message execution context is obtained.

[0066] It should be noted that cross-contract calls can be the case where other smart contracts are called to execute tasks during the execution of their own smart contracts. For example, when calling smart contract A to execute a pending message, it is necessary to call smart contract B to process the pending message, and this behavior can be considered a cross-contract call behavior.

[0067] Specifically, when the target transaction executor calls the corresponding smart contract to process the message to be processed and there is a cross-contract call in the process, the smart contract terminates the execution process of the message to be processed and obtains the message execution context that has been executed by its own smart contract.

[0068] S270: The executed message execution context is used as the message execution result and fed back.

[0069] The target transaction executor feeds the executed message execution context back to the scheduler as the message execution result.

[0070] After the scheduler receives the message execution result, it can determine whether there is a message execution context in the message execution result. If so, it means that the task has a cross-contract call and has not been completed.

[0071] In a specific embodiment, the scheduler determines that if the message execution result includes a message execution context, it generates an intermediate execution message based on the message execution context, and determines the cross-contract call information corresponding to the intermediate execution message; the intermediate execution message is associated with its corresponding cross-contract call information and written into the pending message queue to process the intermediate execution message in the next message execution cycle.

[0072] Specifically, the scheduler generates a new to-be-executed message, i.e., an intermediate execution message, based on the message execution context, and determines the cross-contract call information corresponding to the intermediate execution message, i.e., the contract address of the smart contract called across contracts, etc. The intermediate execution message is associated with its corresponding cross-contract call information and written into the to-be-processed message queue, and the intermediate execution message is processed in the next message execution cycle.

[0073] In a specific embodiment, the scheduler determines that if there is an intermediate execution message in the queue of pending messages in the current message execution cycle, the intermediate smart contract corresponding to the intermediate execution message is determined based on the cross-contract call information of the intermediate execution message; if the intermediate smart contract of the intermediate execution message is in an unoccupied state, any transaction executor is selected from at least one unoccupied transaction executor, and the transaction executor calls the intermediate smart contract to perform message processing based on the message execution context of the intermediate execution message to obtain the executed message execution context; the executed message context is used as the message execution result and fed back.

[0074] Specifically, if the intermediate smart contract of the intermediate execution message is not in an occupied state, any transaction executor is selected from at least one unoccupied transaction executor, and the transaction executor calls the corresponding smart contract based on the contract address in the cross-contract call message, and performs message processing based on the message execution context of the intermediate execution message to obtain the executed message execution context. The transaction executor feeds the executed message context back to the scheduler as the message execution result.

[0075] According to the above message execution results, the scheduler generates a new message to be executed and writes it into the message queue. The original smart contract continues to process the message based on the message execution context to obtain the message processing result.

[0076] The technical solution of this embodiment sends a message execution request to the target transaction executor, which parses the message execution request to obtain a pending message and processes the pending message; if there is a cross-contract call during the message processing of the pending message by the target transaction executor, the execution of the pending message is terminated to obtain the executed message execution context; the executed message execution context is used as the message execution result and fed back. The technical solution of this embodiment realizes the parallel execution of transactions of multiple smart contracts in the case of cross-contract calls, and solves the problem of parallel execution transaction conflicts in the case of cross-contract calls.

[0077] Embodiment 3

[0078] Figure 3 This is a schematic diagram of the execution process of a transaction processing method provided in Embodiment 3 of the present invention. This embodiment provides a preferred example based on the above embodiments.

[0079] The scheduler parses the acquired transaction blocks to obtain all pending transactions, sorts the pending transactions, and stores the transaction list in a certain order in the pending message queue. The scheduler converts all pending transactions into messages, which contain all transaction information, such as transaction content, contract and contract address to be called by the transaction, and transaction address of the transaction sender. Figure 3 The execution process diagram of the transaction processing method shown in the figure shows that in this example, the scheduler parses and obtains six transactions to be executed, namely transaction a, transaction b, transaction c, transaction d, transaction e and transaction f, and different transactions correspond to the same or different smart contracts. Among them, the smart contract that needs to be called for transactions a, transaction b and transaction c is smart contract A; the smart contract that needs to be called for transaction d is smart contract B; the smart contract that needs to be called for transaction e is smart contract C; and the smart contract that needs to be called for transaction f is smart contract D.

[0080] The scheduler sorts transactions a, b, c, d, e, and f and performs message conversion, and stores the converted pending messages in the pending message queue. The scheduler pre-builds a hash list. The hash list stores the address hash values ​​of the smart contracts in the occupied state.

[0081] In the first message execution cycle, message a, message d, message e and message f can be asynchronously executed in sequence. The reason is that the smart contracts required by messages a, message d, message e and message f are different. Specifically, the scheduler can determine the contract addresses of the smart contracts of messages a, message d, message e and message f in sequence, and generate corresponding address hash values ​​based on the contract addresses, and determine whether the address hash values ​​corresponding to each message are stored in the hash list. If so, it means that the smart contract is in an occupied state, and if not, it means that the smart contract is in an available state. Call the corresponding transaction executor, and each transaction executor calls the corresponding smart contract to process messages a, message d, message e and message f respectively to obtain the message processing results.

[0082] Specifically, in the first message execution cycle, transaction executor 001 calls smart contract A to process message a, obtain and feedback the message execution result; transaction executor 002 calls smart contract B to process message d, obtain and feedback the message execution result; transaction executor 003 calls smart contract C to process message e, obtain and feedback the message execution result; transaction executor 004 calls smart contract D to process message f, obtain and feedback the message execution result. It should be noted that during the execution of tasks by smart contracts A, B, C and D, the address hash values ​​of their contract addresses are stored in the hash list, and other messages cannot call smart contracts whose address hash values ​​are in the list, such as messages b and c in the first message execution cycle cannot call smart contract A for processing. Transaction executor 001, transaction executor 002, transaction executor 003 and transaction executor 004 can asynchronously and concurrently execute transaction task processing.

[0083] Among them, it should be noted that in the process of calling smart contract D to process message f by transaction executor 004 in the first message execution cycle, there is a cross-contract call. Specifically, when there is a call to other smart contracts in the process of calling smart contract D to process message f (in this embodiment, there is a call to smart contract E), the processing process of message f by smart contract D is terminated, and the message execution context is obtained. A message g containing the message execution context is generated and written into the queue of pending messages. Therefore, in the second message execution cycle, there are messages b, c and g to be executed. Among them, message g contains the message execution context and cross-contract call information, that is, the contract address of smart contract E, etc.

[0084] In the second message execution cycle, since both message b and message c need to call smart contract A, the transaction executor is first selected to call smart contract A to process message b, and the transaction executor is selected to call smart contract E to process message g. In the process of processing message g, the message execution context of message g is read, and message g is processed based on the message execution context of message g to generate the message execution context of message g. According to the message execution context of message g, a new message f is generated and put into the queue of pending messages, so that smart contract D can continue to be called to process message f in the next message execution cycle.

[0085] In the third message execution cycle, the transaction executor is selected to call smart contract A to process message c, obtain and feedback the message execution result; and the transaction executor is selected to call smart contract D to load the message execution context of message f to continue processing message f, obtain and feedback the message execution result.

[0086] During the above cross-contract call process, when the transaction executor is executing the message, if the smart contract corresponding to the message makes a cross-contract call, the transaction executor will terminate the execution of the current message, save the context of the message execution, and generate a new cross-contract call message. The new message contains the currently saved context. The transaction executor sends the new cross-contract call information to the scheduler, which becomes a new message to be executed. After the transaction executor executes the cross-contract call message, it is found that the message contains the context, which is equivalent to the return of the cross-contract call. The transaction executor will restore the context according to the context in the message, generate a new message, and put the result of the current message execution as the return value of the cross-contract call in the parameter of the new message, and send the new message to the scheduler, which becomes a new message to be executed, and continue to execute the process that was terminated by the transaction executor due to the cross-contract call.

[0087] Embodiment 4

[0088] Figure 4 A schematic diagram of the structure of a transaction processing device provided in Embodiment 4 of the present invention. A transaction processing device provided in an embodiment of the present invention can be applied to the case where blockchain transactions are executed in parallel in a computing environment of a multi-core CPU. The transaction processing device can be implemented in the form of hardware and / or software, such as Figure 4 As shown, the device specifically includes: a smart contract determination module 401, a state judgment module 402, an executor selection module 403 and an execution request generation module 404.

[0089] in,

[0090] The smart contract determination module 401 is used to determine the smart contracts to be called corresponding to each of the to-be-executed messages if there is at least one to-be-executed message in the to-be-executed message queue in the current message execution cycle;

[0091] The state determination module 402 is used to determine, for any pending message, whether the smart contract corresponding to the pending message is in an execution occupied state;

[0092] An executor selection module 403 is used to select a target transaction executor from at least one candidate transaction executor in the current message execution cycle if the smart contract corresponding to the message to be executed is not in the execution occupied state;

[0093] The execution request generation module 404 is used to generate a message execution request according to the contract address of the smart contract of the corresponding message to be executed, and send the message execution request to the target transaction executor. The target transaction executor calls the corresponding smart contract to process the message based on the message execution request, and obtains and feeds back the message execution result.

[0094] The technical solution of the embodiment of the present invention determines the smart contracts that need to be called corresponding to each message to be executed, and for any message to be executed, determines whether the smart contract corresponding to the message to be executed is in an execution occupied state. If not, selects a target transaction executor from at least one candidate transaction executor in the current message execution cycle, generates a message execution request according to the contract address of the smart contract of the corresponding message to be executed, and sends the message execution request to the target transaction executor. The target transaction executor calls the corresponding smart contract for message processing based on the message execution request, obtains and feeds back the message execution result, thereby realizing parallel execution of transactions of multiple smart contracts based on multi-core CPUs, improving the utilization rate of multi-core CPUs, and further improving transaction processing efficiency.

[0095] Optionally, the state determination module 402 is specifically configured to:

[0096] For any pending message, generate the address hash value corresponding to the pending message according to the contract address of the smart contract corresponding to the pending message;

[0097] Determine whether the address hash value of the message to be executed is stored in a pre-built hash list, and obtain a determination result; the hash list stores the address hash values ​​of the smart contracts in the execution occupied state in the current message execution cycle;

[0098] According to the judgment result, it is determined whether the smart contract corresponding to the to-be-executed message is in an execution occupied state.

[0099] Optionally, the execution request generation module 401 includes:

[0100] A message sending unit, configured to send the message execution request to the target transaction executor, and the target transaction executor performs request parsing on the message execution request to obtain a message to be processed, and performs message processing on the message to be processed;

[0101] An execution context generating unit, configured to terminate the execution of the message to be processed and obtain the executed message execution context if there is a cross-contract call in the process of the target transaction executor processing the message to be processed;

[0102] The result feedback unit is used to feed back the executed message execution context as the message execution result.

[0103] Optionally, the device further comprises:

[0104] An intermediate message generation module, configured to generate an intermediate execution message according to the message execution context if the message execution result includes a message execution context, and determine the cross-contract call information corresponding to the intermediate execution message;

[0105] The intermediate message writing module is used to associate the intermediate execution message with its corresponding cross-contract call information and write it into the pending message queue so as to process the intermediate execution message in the next message execution cycle.

[0106] Optionally, the device further comprises:

[0107] An intermediate contract determination module, for determining the intermediate smart contract corresponding to the intermediate execution message according to the cross-contract call information of the intermediate execution message if there is an intermediate execution message in the pending message queue under the current message execution cycle;

[0108] an executor selection module, configured to select any transaction executor from at least one unoccupied transaction executor if the intermediate smart contract of the intermediate execution message is in an unoccupied state, and the transaction executor calls the intermediate smart contract to process the message based on the message execution context of the intermediate execution message to obtain the executed message execution context;

[0109] The message feedback module is used to feed back the executed message context as the message execution result.

[0110] Optionally, the actuator selection module 403 includes:

[0111] A reference executor selection unit, configured to select a reference transaction executor that is currently in an idle state from at least one candidate transaction executor;

[0112] The target executor determining unit is used to determine the target transaction executor according to the CPU related information of the central processing unit CPU to which each of the reference transaction executors belongs.

[0113] The transaction processing device provided in the embodiment of the present invention can execute the transaction processing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0114] Embodiment 5

[0115] Figure 5 A schematic diagram of an electronic device 50 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0116] like Figure 5 As shown, the electronic device 50 includes at least one processor 51, and a memory connected to the at least one processor 51 in communication, such as a read-only memory (ROM) 52, a random access memory (RAM) 53, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 51 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 52 or the computer program loaded from the storage unit 58 to the random access memory (RAM) 53. In the RAM 53, various programs and data required for the operation of the electronic device 50 can also be stored. The processor 51, the ROM 52, and the RAM 53 are connected to each other via a bus 54. An input / output (I / O) interface 55 is also connected to the bus 54.

[0117] A number of components in the electronic device 50 are connected to the I / O interface 55, including: an input unit 56, such as a keyboard, a mouse, etc.; an output unit 57, such as various types of displays, speakers, etc.; a storage unit 58, such as a disk, an optical disk, etc.; and a communication unit 59, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 59 allows the electronic device 50 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0118] The processor 51 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 51 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 51 executes the various methods and processes described above, such as a transaction processing method.

[0119] In some embodiments, the transaction processing method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 58. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 50 via the ROM 52 and / or the communication unit 59. When the computer program is loaded into the RAM 53 and executed by the processor 51, one or more steps of the transaction processing method described above may be performed. Alternatively, in other embodiments, the processor 51 may be configured to execute the transaction processing method in any other appropriate manner (e.g., by means of firmware).

[0120] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0121] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0122] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0123] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0124] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0125] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0126] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0127] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A transaction processing method, characterized in that: include: If there is at least one message to be executed in the queue of pending messages in the current message execution cycle, determine the smart contracts to be called corresponding to each of the pending messages; For any pending message, determine whether the smart contract corresponding to the pending message is in the execution occupied state; If not, selecting a target transaction executor from at least one candidate transaction executor in the current message execution cycle; According to the contract address of the smart contract of the corresponding message to be executed, a message execution request is generated, and the message execution request is sent to the target transaction executor. The target transaction executor calls the corresponding smart contract to process the message based on the message execution request, and obtains and feeds back the message execution result.

2. The method according to claim 1, characterized in that For any pending message, determining whether the smart contract corresponding to the pending message is in an execution occupied state includes: For any pending message, generate the address hash value corresponding to the pending message according to the contract address of the smart contract corresponding to the pending message; Determine whether the address hash value of the message to be executed is stored in a pre-built hash list, and obtain a determination result; the hash list stores the address hash values ​​of the smart contracts in the execution occupied state in the current message execution cycle; According to the judgment result, it is determined whether the smart contract corresponding to the to-be-executed message is in an execution occupied state.

3. The method according to claim 1, characterized in that The sending of the message execution request to the target transaction executor, wherein the target transaction executor calls the corresponding smart contract to process the message based on the message execution request, and obtains and feeds back the message execution result, including: The message execution request is sent to the target transaction executor, and the target transaction executor performs request parsing on the message execution request to obtain a message to be processed, and performs message processing on the message to be processed; If there is a cross-contract call during the message processing of the to-be-processed message by the target transaction executor, the execution of the to-be-processed message is terminated, and the executed message execution context is obtained; The executed message execution context is used as the message execution result and fed back.

4. The method according to claim 3, characterized in that The method further comprises: If the message execution result includes a message execution context, an intermediate execution message is generated according to the message execution context, and cross-contract call information corresponding to the intermediate execution message is determined; The intermediate execution message is associated with its corresponding cross-contract call information and written into the pending message queue so as to process the intermediate execution message in the next message execution cycle.

5. The method according to claim 4, characterized in that The method further comprises: If there is an intermediate execution message in the pending message queue under the current message execution cycle, determine the intermediate smart contract corresponding to the intermediate execution message according to the cross-contract call information of the intermediate execution message; If the intermediate smart contract of the intermediate execution message is in an unoccupied state, any transaction executor is selected from at least one unoccupied transaction executor, and the transaction executor calls the intermediate smart contract to process the message based on the message execution context of the intermediate execution message to obtain the executed message execution context; The executed message context is used as a message execution result and fed back.

6. The method according to claim 1, characterized in that The selecting a target transaction executor from at least one candidate transaction executor in the current message execution cycle includes: Selecting a reference transaction executor that is currently in an idle state from at least one candidate transaction executor; The target transaction executor is determined according to the CPU related information of the central processing unit CPU to which each of the reference transaction executors belongs.

7. A transaction processing device, characterized in that: include: A smart contract determination module, used to determine the smart contracts to be called corresponding to each of the to-be-executed messages if there is at least one to-be-executed message in the to-be-processed message queue in the current message execution cycle; A status judgment module is used to judge whether the smart contract corresponding to any pending message is in the execution occupied state; An executor selection module, configured to select a target transaction executor from at least one candidate transaction executor in the current message execution cycle if the smart contract corresponding to the message to be executed is not in an execution occupied state; The execution request generation module is used to generate a message execution request according to the contract address of the smart contract of the corresponding message to be executed, and send the message execution request to the target transaction executor. The target transaction executor calls the corresponding smart contract to process the message based on the message execution request, and obtains and feeds back the message execution result.

8. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the transaction processing method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the transaction processing method according to any one of claims 1 to 6 when executed.

10. A computer program product, characterized in that The computer program product comprises a computer program, which, when executed by a processor, implements the transaction processing method according to any one of claims 1 to 6.

Images