Block chain transaction processing method, related device and medium

Abstract

The invention provides a block chain transaction processing method, a related device and a medium. The method is applied to a first consensus node in a block chain network, and comprises the steps of obtaining a transaction processing request; executing the target transaction, and according to a first execution sequence of the target transaction, cascading the first resource state information of each resource pool after the target transaction is executed into first resource state dependency sequence information; sending the plurality of target transactions and the first resource state dependency sequence information to a second consensus node, so that the second consensus node executes the target transactions, and cascading second resource state information of each resource pool into second resource state dependency sequence information after the target transactions are executed according to a second execution sequence of the target transactions, and when the first resource state dependency sequence information is consistent with the second resource state dependency sequence information, the multiple target transactions are consensus-linked. The security of transaction processing can be improved. The method and the device can be applied to various scenes such as block chains, artificial intelligence and cloud technologies.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to a blockchain transaction processing method, related apparatus and medium. Background Technology

[0002] Currently, when blockchain networks package transactions for on-chain processing, the consensus nodes typically package the transactions into blocks first, and then all consensus nodes reach a consensus on the block before the transactions are added to the blockchain. However, this method allows consensus nodes to manipulate the packaging order of transactions, which often affects the state of the resource pools associated with each transaction. If the packaging order is randomly modified, the state of the resource pools associated with each transaction changes accordingly. This can easily lead to situations where some transactions cannot be processed normally, resulting in reduced security in transaction processing. Summary of the Invention

[0003] This disclosure provides a blockchain transaction processing method, related apparatus, and medium that can improve the security of transaction processing.

[0004] According to one aspect of this disclosure, a blockchain transaction processing method is provided, applied to a first consensus node in a blockchain network, the blockchain network including the first consensus node and a second consensus node, the method comprising:

[0005] Obtain a transaction processing request, wherein the transaction processing request is used to package multiple target transactions and upload them to the blockchain;

[0006] Execute the target transaction, and according to the first execution order of the target transaction, concatenate the first resource status information of each resource pool after the execution of the target transaction into first resource status dependency order information;

[0007] The multiple target transactions and the first resource state dependency order information are sent to the second consensus node so that the second consensus node executes the target transactions and, according to the second execution order of the target transactions, concatenates the second resource state information of each resource pool after the execution of the target transactions into second resource state dependency order information. When the first resource state dependency order information is consistent with the second resource state dependency order information, the consensus of the multiple target transactions is put on the chain.

[0008] According to one aspect of this disclosure, a blockchain transaction processing apparatus is provided, applied to a first consensus node in a blockchain network, the blockchain network including the first consensus node and a second consensus node, the apparatus comprising:

[0009] The acquisition unit is used to acquire a transaction processing request, wherein the transaction processing request is used to package multiple target transactions and upload them to the blockchain.

[0010] The first processing unit is used to execute the target transaction and, according to the first execution order of the target transaction, concatenate the first resource status information of each resource pool after the execution of the target transaction into first resource status dependency order information.

[0011] The second processing unit is used to send the multiple target transactions and the first resource state dependency order information to the second consensus node, so that the second consensus node executes the target transactions, and according to the second execution order of the target transactions, concatenates the second resource state information of each resource pool after the execution of the target transactions into second resource state dependency order information, and uploads the consensus of multiple target transactions to the chain when the first resource state dependency order information is consistent with the second resource state dependency order information.

[0012] Optionally, the first processing unit includes:

[0013] The acquisition module is used to acquire the first resource status information of each resource pool after the target transaction is executed;

[0014] The first filling module is used to fill the first resource status information into the first space if the first resource status information is consistent with the reference resource status information;

[0015] The first cascading module is used to cascade the various first resource status information filled into the first space into first resource status dependency order information according to the first execution order of the target transaction.

[0016] Optionally, the acquisition module is used for:

[0017] For the target transaction, obtain the current resource status of the resource pool associated with the target transaction;

[0018] Based on the current resource status and the transaction content of the target transaction, determine the changed resource status of the resource pool;

[0019] A digest operation is performed on the changed resource status and the resource pool address to obtain the first resource status information.

[0020] Optionally, the cascade module is used for:

[0021] The first resource status information filled into the first space is concatenated into a resource status concatenation result according to the first execution order of the target transaction.

[0022] A summary operation is performed on the concatenated resource states to obtain the dependency order information of the first resource states.

[0023] Optionally, the second processing unit is used to:

[0024] Obtain the second resource status information of each resource pool after the target transaction is executed;

[0025] If the second resource status information is consistent with the reference resource status information, the second resource status information is filled into the second space;

[0026] The second resource state information that is filled into the second space is concatenated into the second resource state dependency order information according to the second execution order of the target transaction.

[0027] Optionally, the reference resource status information is obtained by the first consensus node in the following way:

[0028] Obtain the construction request of the target object for the target transaction, wherein the construction request includes the transaction content of the target transaction and the resource pool associated with the target transaction;

[0029] Based on the current resource status of the resource pool and the transaction content, the expected resource status of the resource pool is determined, and the expected resource status is returned to the target object so that the target object can generate the signature result of the target transaction according to the expected resource status and the transaction content.

[0030] In response to the on-chain request for the target transaction, the signature result is obtained, and the signature result is designed using the target public key of the target object to obtain the reference resource status information.

[0031] Optionally, the target object generates the signature result of the target transaction based on the expected resource state and the transaction content, including:

[0032] Perform a summary operation on the expected resource status to obtain the resource status summary result;

[0033] The resource status summary result and the transaction content are integrated to obtain the transaction integration result;

[0034] The transaction integration result is encrypted based on the target object's private key to obtain the signature result.

[0035] Optionally, the second processing unit is used to:

[0036] Package the multiple target transactions and the first resource state dependency order information into a target block;

[0037] Send the target block to the second consensus node;

[0038] The step of putting multiple target transactions on the blockchain includes: recording the target blocks on the blockchain maintained by the second consensus node.

[0039] Optionally, the blockchain transaction processing device further includes a verification unit, the verification unit comprising:

[0040] The receiving module is used to receive the target block sent by the first consensus node and obtain the block header information of the target block;

[0041] The verification module is used to perform a first verification on the target block based on the block header information;

[0042] The processing module is configured to, if it is determined that the first verification is successful, sequentially obtain the second resource status information of each resource pool after the execution of the target transaction based on the second execution order;

[0043] The second filling module is used to fill the second resource status information into the second space if the second resource status information is consistent with the reference resource status information.

[0044] The second cascading module is used to cascade the various second resource status information filled into the second space into second resource status dependency order information according to the second execution order.

[0045] Optionally, the block header information includes the target block height of the target block;

[0046] The verification module is used for:

[0047] Get the current block height of the blockchain;

[0048] Determine the height difference between the target block height and the current block height;

[0049] If the height difference is determined to be 1, then the first verification is deemed successful.

[0050] Optionally, the block header information includes the target block digest of the target block;

[0051] The verification module is used for:

[0052] Obtain the transaction summary of each target transaction in the target block;

[0053] The transaction summaries of multiple target transactions are integrated to obtain the target summary result;

[0054] If the target digest result is determined to be consistent with the target block digest, then the first verification is deemed successful.

[0055] Optionally, the plurality of target transactions are determined in the following manner:

[0056] For each candidate transaction in the transaction pool of the first consensus node, determine the transaction timestamp of the candidate transaction;

[0057] The target transaction is selected from multiple candidate transactions based on the time of the transaction timestamp.

[0058] Optionally, the plurality of target transactions are determined in the following manner:

[0059] For each candidate transaction in the transaction pool of the first consensus node, determine the on-chain resource overhead of the candidate transaction;

[0060] Based on the on-chain resource overhead, the target transaction is selected from multiple candidate transactions.

[0061] Optionally, determining the on-chain resource overhead of the candidate transaction includes:

[0062] Obtain the overhead rate of the blockchain network and the transaction size of the candidate transactions;

[0063] Based on the transaction size and the overhead rate, calculate the on-chain resource overhead of the candidate transaction.

[0064] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the blockchain transaction processing method as described above.

[0065] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the blockchain transaction processing method as described above.

[0066] According to one aspect of this disclosure, a computer program product is provided, comprising a computer program that is read and executed by a processor of an electronic device, causing the electronic device to perform the blockchain transaction processing method as described above.

[0067] In this embodiment, the vulnerability of consensus nodes in related technologies to arbitrarily modify the packaging order of transactions when packaging them into blocks, leading to low security in transaction processing, is addressed. Verification of resource states after the sequential execution of target transactions is incorporated into the transaction packaging and block consensus stages. Specifically, when it is the first consensus node in the blockchain network's turn to package transactions, it obtains a transaction processing request, which is used to package multiple target transactions onto the chain. Next, the first consensus node executes the target transactions sequentially according to a first execution order, and concatenates the first resource state information of each resource pool after the target transactions are executed into a first resource state dependency order information, according to the first execution order of the target transactions. This allows the first consensus node to easily determine the changes in resource states resulting from the sequential execution of each target transaction. Furthermore, the first consensus node sends the multiple target transactions and the first resource state dependency order information to the second consensus node. Based on this, the second consensus node executes the target transactions sequentially according to the second execution order. Following this second execution order, it concatenates the second resource state information of each resource pool after the target transactions are executed into second resource state dependency order information, thus re-determining the resource state changes of each target transaction's sequential execution. Finally, the second consensus node compares the first resource state dependency order information generated during transaction packaging with the second resource state dependency order information generated during transaction verification. Only when the first and second resource state dependency order information are consistent is the consensus of multiple target transactions uploaded to the blockchain. This method verifies the transaction packaging order based on the resource state information after each target transaction's execution, thereby reducing the risk of transactions being randomly shuffled during packaging and improving the security of transaction processing.

[0068] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0069] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0070] Figure 1 This is a system architecture diagram of a blockchain transaction processing method applied according to an embodiment of the present disclosure;

[0071] Figures 2A-2F A schematic diagram is shown illustrating the application of the blockchain transaction on-chain method according to an embodiment of the present disclosure in a transaction on-chain scenario;

[0072] Figure 3 This is a flowchart of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0073] Figure 4 This is a flowchart of determining a target transaction according to an embodiment of the present disclosure;

[0074] Figure 5 This is a flowchart of determining a target transaction according to another embodiment of the present disclosure;

[0075] Figure 6 This is a flowchart illustrating the generation of first resource state dependency order information according to an embodiment of the present disclosure;

[0076] Figure 7 This is a flowchart illustrating the acquisition of reference resource status information according to an embodiment of the present disclosure;

[0077] Figure 8 This is a flowchart illustrating the generation of first resource state information according to an embodiment of the present disclosure;

[0078] Figure 9 This is a flowchart illustrating the generation of first resource state dependency order information according to an embodiment of the present disclosure;

[0079] Figure 10 This is a schematic diagram illustrating the implementation process of generating first resource state dependency order information according to an embodiment of the present disclosure;

[0080] Figure 11 This is a schematic diagram illustrating the overall implementation process of packaging target transactions according to an embodiment of the present disclosure;

[0081] Figure 12 This is a flowchart illustrating the generation of second resource state dependency order information according to an embodiment of the present disclosure;

[0082] Figure 13 This is a flowchart of generating second resource state dependency order information according to another embodiment of the present disclosure;

[0083] Figure 14 This is a flowchart of a first verification of a target block according to an embodiment of the present disclosure;

[0084] Figure 15 This is a schematic diagram illustrating the implementation process of performing a first verification on a target block according to an embodiment of the present disclosure;

[0085] Figure 16 This is a flowchart of a first verification of a target block according to another embodiment of the present disclosure;

[0086] Figure 17This is a schematic diagram illustrating the implementation process of performing a first verification on a target block according to another embodiment of the present disclosure;

[0087] Figure 18 This is a schematic diagram illustrating the implementation process of generating second resource state dependency order information according to an embodiment of the present disclosure;

[0088] Figure 19 This is a schematic diagram illustrating the overall implementation process of verifying a target transaction according to an embodiment of the present disclosure;

[0089] Figure 20 This is a schematic diagram illustrating the implementation details of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0090] Figure 21 This is a block diagram of a blockchain transaction processing apparatus according to an embodiment of the present disclosure;

[0091] Figure 22 This is a terminal structure diagram of a blockchain transaction processing method according to an embodiment of the present disclosure;

[0092] Figure 23 This is a server architecture diagram of a blockchain transaction processing method according to an embodiment of the present disclosure. Detailed Implementation

[0093] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0094] The system architecture and scenarios in which this disclosure is applied are described below.

[0095] Figure 1 This is a system architecture diagram of the blockchain transaction processing method applied according to embodiments of the present disclosure. It includes an object terminal 140, an Internet 130, a gateway 120, a blockchain network server 110, etc.

[0096] The object terminal 140 includes various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. The object terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data. The object terminal 140 includes a transaction processing platform, which is used by each object to obtain the expected resource status of each resource pool associated with the transaction to be uploaded to the blockchain after execution, and submits the transaction to the blockchain network for on-chain processing.

[0097] See Figure 1 The blockchain network server 110 shown includes a consensus network. A consensus network is a network that reaches a consensus on transactions before adding them to the blockchain; it consists of multiple consensus nodes. A consensus node is also known as a blockchain node. A consensus node or blockchain node can be a server within the blockchain server or an object terminal connected to the blockchain server; the specific form of the consensus node or blockchain node is not limited here.

[0098] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from object terminal 140 to blockchain network server 110 are forwarded to the corresponding blockchain network server 110 via gateway 120. Messages sent from blockchain network server 110 to object terminal 140 are also forwarded to the corresponding object terminal 140 via gateway 120.

[0099] The embodiments disclosed herein can be applied in various scenarios, such as Figures 2A-2F The scenarios shown include on-chain transactions.

[0100] like Figure 2A As shown, when an object wants to record a transaction on the blockchain, it logs into the transaction processing platform through its terminal and enters the transaction on-chain process. At this time, the transaction processing platform displays a prompt field: "Please provide the basic transaction information of the target transaction to be constructed, and select the blockchain node to pre-execute the transaction." It also provides editing areas for inputting the basic transaction information and for selecting the blockchain node to pre-execute the target transaction. Based on this, the object enters "Transaction associated objects: A, B; Transaction content: Object A interacts with object B for 50 resources" in the editing area for inputting the basic transaction information, selects "Node 3" in the editing area for selecting the blockchain node to pre-execute the target transaction, and clicks the "Confirm" button. This confirms that Node 3 will pre-execute the target transaction, and provides feedback on how the execution of the target transaction will cause resource changes in the resource pool.

[0101] like Figure 2BAs shown, after the object clicks the "Confirm" button, a prompt window will appear on the page. The prompt window contains the prompt field "After executing the target transaction, the resource pool of object A is expected to have 50 resources remaining, and the resource pool of object B is expected to have 100 resources remaining. Please confirm...", to provide feedback to the object on the specific situation of the pre-execution of the target transaction in node 3. At this time, the object clicks the "Confirm" button to confirm how the execution of the target transaction will cause resource changes in the resource pool.

[0102] like Figure 2C As shown, after the object clicks the "Confirm" button, a prompt field will appear on the page: "The complete transaction information of the target transaction is as follows. Please confirm whether to submit the target transaction to the blockchain network for on-chain processing." The complete transaction information of the target transaction will be displayed as: "Transaction associated objects: A, B; Transaction content: Object A interacts with object B with 50 resources; Expected resource status information: A's resource pool has 50 remaining resources, and B's resource pool has 100 remaining resources." At this point, the complete transaction information of the target transaction includes the transaction associated objects, the transaction content, and the expected resource status information obtained through pre-executing the target transaction. Based on this, the object clicks the "Confirm" button to confirm that the complete transaction information of the target transaction will be submitted to the blockchain network for on-chain processing.

[0103] like Figure 2D As shown, after the object clicks the "Confirm" button, a prompt window will be displayed on the page. The prompt window contains the prompt field "The target transaction has been submitted to blockchain network node 10. Node 10 is executing the target transaction and verifying whether the status of each resource pool after execution is consistent with the expected resource status information. Please wait patiently...", so as to verify the actual resource changes caused by the execution of the transaction on the blockchain.

[0104] like Figure 2E As shown, after node 10 completes the target transaction and verifies the actual resource changes, a prompt window will be displayed on the page. The prompt window contains the prompt field "After verification, the status of each resource pool after the execution of the target transaction is consistent with the expected resource status information. Node 10 has packaged the target transaction into the target block. The blockchain network is currently reaching consensus on the target block. Please wait patiently..." This confirms that the target transaction will be packaged and uploaded to the blockchain when the resource changes caused by the actual execution of the target transaction meet expectations.

[0105] like Figure 2F As shown, once the blockchain network completes consensus on the target block, a notification window will be displayed on the page. The notification window contains the message "Target block consensus successful, the target transaction has been recorded on the blockchain," to provide feedback to the user regarding the on-chain result of the target transaction.

[0106] The embodiments of this disclosure are described in general below.

[0107] According to one embodiment of this disclosure, a blockchain transaction processing method is provided.

[0108] This blockchain transaction processing method is generally applied in business scenarios where the order of transaction packaging is prone to become disordered during blockchain transaction processing, for example... Figures 2A-2F The scenario shown illustrates a transaction on-chain operation. This disclosure provides a scheme for verifying the resource status of a resource pool after the execution of a target transaction during transaction processing, thereby improving the security of transaction processing.

[0109] like Figure 3 As shown, a blockchain transaction processing method according to an embodiment of this disclosure is applied to a first consensus node in a blockchain network. The blockchain network includes a first consensus node and a second consensus node. The blockchain transaction processing method may include:

[0110] Step 310: Obtain the transaction processing request;

[0111] Step 320: Execute the target transaction, and according to the first execution order of the target transaction, concatenate the first resource status information of each resource pool after the execution of the target transaction into the first resource status dependency order information;

[0112] Step 330: Send multiple target transactions and the first resource state dependency order information to the second consensus node so that the second consensus node can execute the target transactions and, according to the second execution order of the target transactions, concatenate the second resource state information of each resource pool after the target transactions are executed into the second resource state dependency order information. When the first resource state dependency order information is consistent with the second resource state dependency order information, put the consensus of multiple target transactions on the chain.

[0113] Steps 310-330 are described in detail below.

[0114] In step 310, a transaction processing request is obtained.

[0115] Transaction processing requests are used to package multiple target transactions onto the blockchain.

[0116] The target transaction refers to information that is to be added to the blockchain and is used to describe a resource interaction process or an information verification process.

[0117] In the specific implementation of this embodiment, according to the block production order of the blockchain network, when it is the turn of the first consensus node to produce a block, the first consensus node will receive a transaction processing request sent by the blockchain network server, instructing the first consensus node to package and put on the blockchain the target transaction determined from multiple transactions to be put on the blockchain in the transaction pool.

[0118] In step 320, the target transaction is executed, and the first resource status information of each resource pool after the target transaction is executed is concatenated into the first resource status dependency order information according to the first execution order of the target transaction.

[0119] The first execution order is used to indicate the order in which the first consensus nodes execute the target transactions, and also to indicate the order in which each target transaction is packaged.

[0120] Each resource pool refers to the resource pool related to the execution of the target transaction.

[0121] The first resource status information is used to indicate the specific resource status of the resource pool related to the execution of the target transaction after the first consensus node executes the target transaction.

[0122] The first resource state dependency order information is used to indicate the order of resource states of each resource pool after the first consensus node executes each target transaction in the first execution order.

[0123] To save space, the specific implementation process of concatenating the first resource state information of each resource pool after the execution of the target transaction into first resource state dependency order information according to the first execution order of the target transaction in this embodiment will be described in detail below. It will not be repeated here.

[0124] In step 330, multiple target transactions and the first resource state dependency order information are sent to the second consensus node so that the second consensus node can execute the target transactions and, according to the second execution order of the target transactions, concatenate the second resource state information of each resource pool after the target transactions are executed into the second resource state dependency order information. When the first resource state dependency order information and the second resource state dependency order information are consistent, the consensus of multiple target transactions is put on the chain.

[0125] The second execution order is used to indicate the order in which the second consensus nodes execute the target transaction.

[0126] The second resource status information is used to indicate the specific resource status of the resource pool related to the execution of the target transaction after the second consensus node executes the target transaction.

[0127] The second resource state dependency order information is used to indicate the order of resource states of each resource pool after the second consensus node executes each target transaction in the first execution order.

[0128] To save space, the specific implementation process of concatenating the second resource state information of each resource pool after the execution of the target transaction into second resource state dependency order information according to the second execution order of the target transaction in this embodiment will be described in detail below. It will not be repeated here.

[0129] Through steps 310-330 above, this embodiment of the disclosure addresses the deficiency in related technologies where consensus nodes can arbitrarily modify the packaging order of transactions when packaging them into blocks, leading to low security in transaction processing. It considers setting up verification of the resource status after the sequential execution of target transactions during the transaction packaging and block consensus stages. Specifically, when it is the first consensus node in the blockchain network to package transactions, the first consensus node obtains a transaction processing request, which is used to package multiple target transactions onto the chain. Then, the first consensus node executes the target transactions sequentially according to a first execution order, and according to the first execution order of the target transactions, concatenates the first resource status information of each resource pool after the execution of the target transactions into first resource status dependency order information. In this way, the first consensus node can more easily determine how the resource status changes are after the sequential execution of each target transaction. Furthermore, the first consensus node sends multiple target transactions and the first resource status dependency order information to the second consensus node. Based on this, the second consensus node executes the target transactions sequentially according to the second execution order. Following this second execution order, it concatenates the second resource state information of each resource pool after the target transactions are executed into second resource state dependency order information, thus re-determining the resource state changes of each target transaction's sequential execution. Finally, the second consensus node compares the first resource state dependency order information generated during transaction packaging with the second resource state dependency order information generated during transaction verification. Only when the first and second resource state dependency order information are consistent is the consensus of multiple target transactions uploaded to the blockchain. This method verifies the transaction packaging order based on the resource state information after each target transaction's execution, thereby reducing the risk of transactions being randomly shuffled during packaging and improving the security of transaction processing.

[0130] The above is a general description of steps 310-330. The specific implementations of steps 310, 320, and 330 will be described in detail below.

[0131] Step 310 will be described in detail below.

[0132] In step 310, a transaction processing request is obtained, wherein the transaction processing request is used to package multiple target transactions and put them on the blockchain.

[0133] Please refer to Figure 4 In one embodiment, the process of determining multiple target transactions includes, but is not limited to, the following steps 410-420:

[0134] Step 410: For each candidate transaction in the transaction pool of the first consensus node, determine the transaction timestamp of the candidate transaction;

[0135] Step 420: Based on the time of the transaction timestamp, select the target transaction from multiple candidate transactions.

[0136] Steps 410-420 are described in detail below.

[0137] In step 410, for each candidate transaction in the transaction pool of the first consensus node, the transaction timestamp of the candidate transaction is determined.

[0138] The transaction pool refers to the data space used by the first consensus node to store transactions that are to be uploaded to the chain.

[0139] Candidate transactions refer to transactions that are stored by the first consensus node and are yet to be added to the chain.

[0140] Transaction timestamps are used to indicate the point in time when each candidate transaction is sent to the blockchain network.

[0141] In this specific implementation, since the transaction timestamps of each candidate transaction are carried when each candidate transaction is submitted to the blockchain network, and the blockchain network's server backend also records the time when the candidate transactions are received, the transaction information of each candidate transaction can be extracted with authorization to obtain the transaction timestamps of each candidate transaction. Alternatively, the time when each candidate transaction is received can be extracted from the server backend's log information to obtain the transaction timestamps of each candidate transaction.

[0142] In step 420, the target transaction is selected from multiple candidate transactions based on the time of the transaction timestamp.

[0143] In the specific implementation of this embodiment, firstly, based on the time of the transaction timestamps, multiple candidate transactions are sorted in ascending order of their timestamps, with the earlier a candidate transaction is sent to the blockchain network, the higher its position in the ranking. Next, a predetermined number of candidate transactions at the top of the ranking are selected as the target transactions.

[0144] It should be noted that the pre-ordered number can be determined based on the packaging speed of the first consensus node and the current network state of the blockchain network. The faster the packaging speed of the first consensus node and the lower the network latency in the current network state, the larger the pre-ordered number can be.

[0145] The advantage of this embodiment is that it takes into account the different timestamps of each candidate transaction and prioritizes the candidate transaction with the earlier timestamp as the target transaction for on-chain, which can improve the efficiency and orderliness of transaction on-chain in the blockchain network.

[0146] Please refer to Figure 5In another embodiment, the process of determining multiple target transactions includes, but is not limited to, the following steps 510-520:

[0147] Step 510: For each candidate transaction in the transaction pool of the first consensus node, determine the on-chain resource overhead of the candidate transaction.

[0148] Step 520: Based on the on-chain resource overhead, select the target transaction from multiple candidate transactions.

[0149] Steps 510-520 are described in detail below.

[0150] In step 510, the on-chain resource overhead of each candidate transaction in the transaction pool of the first consensus node is determined.

[0151] On-chain resource overhead indicates the resources required to record candidate transactions on the blockchain.

[0152] In the specific implementation of this embodiment, the process of determining the on-chain resource overhead of each candidate transaction includes, but is not limited to, the following steps:

[0153] Obtain the overhead rate of the blockchain network and the transaction size of candidate transactions;

[0154] Calculate the on-chain resource overhead of candidate transactions based on transaction size and overhead rate.

[0155] The overhead rate indicates the amount of resources required to record a unit size of transaction data onto the blockchain. The transaction size indicates the amount of data in all transaction data (transaction associated objects, transaction content, and reference resource status information, etc.) of the target transaction. The transaction size of a candidate transaction can be quantified as the number of bytes of all transaction data in the target transaction, while the overhead rate indicates the amount of resources required to record a unit byte of data onto the blockchain.

[0156] Specifically, firstly, a request to obtain the overhead rate can be sent to a publicly trusted platform or a blockchain consensus network, and the overhead rate provided by the publicly trusted platform's blockchain consensus network can be received. Next, data volume statistics are performed on the transaction-related objects, transaction content, and reference resource status information of the target transaction to obtain the total data volume of the target transaction, which is then used as the transaction size of the target transaction. Further, the transaction size is multiplied by the overhead rate to obtain the on-chain resource overhead of the candidate transaction.

[0157] In step 520, the target transaction is selected from multiple candidate transactions based on the on-chain resource overhead.

[0158] In the specific implementation of this embodiment, firstly, based on the size of the on-chain resource overhead, multiple candidate transactions are sorted in descending order of on-chain resource overhead, with candidate transactions having higher on-chain resource overhead ranking higher. Next, a predetermined number of candidate transactions at the top of the ranking are selected as the target transactions.

[0159] The advantage of this embodiment is that it takes into account the different transaction sizes of each candidate transaction, calculates the on-chain cost for each candidate transaction, and obtains the on-chain resource cost for each candidate transaction. This makes it easier to determine the resource benefits that the blockchain network can obtain by on-chaining each candidate transaction. Furthermore, based on the different on-chain resource costs, it prioritizes candidate transactions with larger on-chain resource costs as target transactions, which can improve the rationality of transaction on-chaining.

[0160] Step 320 will be described in detail below.

[0161] In step 320, the target transaction is executed, and the first resource status information of each resource pool after the target transaction is executed is concatenated into the first resource status dependency order information according to the first execution order of the target transaction.

[0162] When the first consensus node fills multiple target transactions into the first space, its transaction pool may contain some erroneous transactions that do not meet user expectations and should not be recorded on the blockchain. Recording such transactions on the blockchain would lead to data chaos and reduced security. Therefore, this disclosure provides a transaction packaging scheme based on resource status verification of each target transaction. This scheme can accurately filter erroneous transactions and improve the security of the target transactions filled into the first space.

[0163] In this embodiment of the disclosure, the target transaction has reference resource status information, which is used to indicate the expected resource status of each resource pool after the target transaction is executed.

[0164] Please refer to Figure 6 In one embodiment, step 320 specifically includes, but is not limited to, the following steps 610-630:

[0165] Step 610: Obtain the first resource status information of each resource pool after the target transaction is executed;

[0166] Step 620: If the first resource status information is consistent with the reference resource status information, fill the first resource status information into the first space;

[0167] Step 630: Concatenate the first resource state information that has been filled into the first space into first resource state dependency order information according to the first execution order of the target transaction.

[0168] Steps 610-630 are described in detail below.

[0169] In step 610, the first resource status information of each resource pool after the target transaction is executed is obtained.

[0170] In the specific implementation of this embodiment, since the execution of each target transaction will cause resource changes in all resource pools associated with the blockchain network, for each target transaction, the target transaction is executed, and after the execution of the target transaction, the resource changes of the resource pools associated with the target transaction (the resource pools of the transaction-associated objects) are analyzed, and the resource status of the resource pools associated with the target transaction after execution is integrated into the first resource status information.

[0171] For example, the target transaction involves resource interaction between object A and object B, with object A transferring 20 resources to object B. The first consensus node can retrieve information prior to the target transaction, showing that object A's resource pool had 100 resources and object B's resource pool had 80 resources. Therefore, after executing the target transaction, the first consensus node will update object A's resource pool to 80 resources and object B's resource pool to 100 resources. At this point, the first resource status information will indicate that object A's resource pool has 80 resources and object B's resource pool has 100 resources.

[0172] It should be noted that, in addition to recording the resource quantity (balance) of each resource pool, the first resource status information also records a lot of other resource pool information, such as the number of transaction processing (nonce) of the resource pool, the Merkle root hash (storageRoot) of the resource pool storage status, code hash (codeHash), etc.

[0173] In step 620, if the first resource status information is consistent with the reference resource status information, the first resource status information is filled into the first space.

[0174] The first space refers to the data space used by the first consensus node to store the target transaction whose first resource state information is consistent with the reference resource state information.

[0175] In the specific implementation of this embodiment, for each target transaction, firstly, the first resource state information is compared with the reference resource state information carried by the target transaction when it is sent to the blockchain network to determine whether the resource state change of the resource pool caused by the actual execution of the target transaction meets expectations. Next, if the first resource state information matches the reference resource state information, it indicates that the resource state change of the resource pool caused by the actual execution of the target transaction meets expectations, and the target transaction can be packaged and uploaded to the chain. Therefore, the first resource state information of the target transaction is filled into the first space. When filling the first resource state information of the target transaction into the first space, the target transaction can be packaged into a block, with all target transactions containing both the first resource state information and the reference resource state information packaged into the same block, which is considered the first space.

[0176] Furthermore, if the first resource status information is inconsistent with the reference resource status information, it indicates that the resource status change of the resource pool caused by the actual execution of the target transaction does not meet expectations. Uploading the target transaction to the blockchain will cause data chaos. Therefore, the target transaction is discarded, the target transaction is not uploaded to the blockchain, and an error message is sent to the target object that sent the upload request for the target transaction, and the upload request for the target transaction is rejected.

[0177] In step 630, the first resource state information that is filled into the first space is concatenated into first resource state dependency order information according to the first execution order of the target transaction.

[0178] In the specific implementation of this embodiment, firstly, according to the first execution order of the target transaction, the various first resource state information items filled in the first space are concatenated, connecting multiple scattered first resource state information items into a complete resource state information. Next, the concatenated or chained complete resource state information is encrypted to obtain the first resource state dependency order information.

[0179] The advantage of this embodiment is that the first consensus node executes each target transaction of the target block sequentially according to the first execution order, and obtains the first resource status information of each resource pool after the target transaction is executed. This first resource status information is compared with reference resource status information, which can better identify target transactions that do not meet user expectations. Transactions that do not meet user expectations are discarded as erroneous transactions, while target transactions that meet user expectations are filled into the first space, improving the rationality of the target transactions filled into the first space. Furthermore, the first consensus node also concatenates the first resource status information of each target transaction based on the first execution order, generating complete resource status information. This complete resource status information is used to limit the order of each target transaction, which helps improve the packaging order of target transactions and prevents target transactions from being arbitrarily disrupted. Simultaneously, the complete resource status information is encrypted, which improves the confidentiality and security of the generated first resource status dependency order information.

[0180] Please refer to Figure 7 In one embodiment, the reference resource state information of the target transaction is obtained by the first consensus node in the following way:

[0181] Step 710: Obtain the construction request of the target object for the target transaction;

[0182] Step 720: Based on the current resource status of the resource pool and the transaction content, determine the expected resource status of the resource pool and return the expected resource status to the target object so that the target object can generate the signature result of the target transaction according to the expected resource status and the transaction content.

[0183] Step 730: In response to the on-chain request for the target transaction, obtain the signature result, and design the signature result using the target public key of the target object to obtain the reference resource status information.

[0184] Steps 710-730 are described in detail below.

[0185] In step 710, the construction request of the target object for the target transaction is obtained.

[0186] A construction request is a request initiated by a target object to put the target transaction on the blockchain based on the resource changes it acknowledges or expects after the execution of the target transaction. The purpose of the construction request is to obtain the resource changes it acknowledges or expects after the execution of the target transaction.

[0187] The construction request includes the transaction content of the target transaction and the resource pool associated with the target transaction. The transaction content is used to indicate the specific details of the target transaction.

[0188] For example, when the target transaction is a resource interaction transaction, the transaction content will indicate information such as the time of the resource interaction and the amount of resources interacted; when the target transaction is an information verification transaction, the transaction content will indicate information such as the specific verification process and the verification result. The resource pool indicates the resource pool address of the resource pool owned by the object associated with the target transaction. The resource pool is used to store the resources owned by the object associated with the target transaction.

[0189] In this specific implementation, when a target object wants to record a target transaction on the blockchain, it first sends a construction request to any consensus node (either the first or second consensus node) on the blockchain network. This request invokes the pre-execution module of that consensus node, allowing it to pre-execute the target transaction and obtain the resource status of each resource pool as the expected resource status after the pre-execution. Based on this, the consensus node receives the target object's construction request for the target transaction and, according to the request, parses out the transaction content and the specific resource pool address associated with it.

[0190] In step 720, based on the current resource status of the resource pool and the transaction content, the expected resource status of the resource pool is determined, and the expected resource status is returned to the target object so that the target object can generate the signature result of the target transaction according to the expected resource status and the transaction content.

[0191] The current resource status of the resource pool is used to indicate information such as the amount of resources in the resource pool owned by the objects associated with the target transaction before the target transaction is executed.

[0192] The signature result is used to indicate the signature status corresponding to the target transaction, and the signature result can reflect the encrypted transaction information of the target transaction.

[0193] In this specific implementation, firstly, resource change data for the resource pool is determined based on the transaction content and the current resource status. Next, the current resource status is updated based on the resource change data to obtain the expected resource status of the resource pool. Finally, the consensus node returns the expected resource status to the target object, thus informing the target object of the changes that will occur in each resource pool after the target transaction is actually executed. These changes include, but are not limited to, the addition or removal of resources, and changes to resource pool parameters.

[0194] Furthermore, in this embodiment, the specific process by which the target object generates the signature result of the target transaction based on the expected resource status and transaction content includes, but is not limited to, the following steps:

[0195] Perform a summary operation on the expected resource status to obtain the resource status summary result;

[0196] The resource status summary results and transaction content are integrated to obtain the transaction integration result;

[0197] The transaction integration result is encrypted using the target object's private key to obtain the signature result.

[0198] The resource status summary result is a fixed-length random number used to indicate the expected resource status. The transaction integration result is a string of information concatenated with the resource status summary result and the transaction content.

[0199] A target private key is a key privately held by the target object, used to encrypt various information or data. This private key is not publicly disclosed; only the target object can know and use it. In addition, the target private key often has a paired target public key, which is publicly available. Other objects can use the target public key to decrypt content encrypted with the target private key.

[0200] Specifically, first, the target object performs a digest operation on the expected resource state using a predefined digest algorithm, and uses the resulting digest value as the resource state digest result. Next, the target object concatenates the resource state digest result with the transaction content to form a complete string of information, obtaining the transaction integration result. Further, the target object uses its private key to encrypt the transaction integration result, converting the plaintext transaction integration result into ciphertext information, thus obtaining the signature result.

[0201] In step 730, in response to the on-chain request for the target transaction, the signature result is obtained, and the signature result is designed using the target public key of the target object to obtain the reference resource status information.

[0202] In this specific implementation, after the target object constructs the signature result of the target transaction, it requests the blockchain network server to record the signature result of the target transaction on the blockchain. At this time, the target object sends an on-chain request for the target transaction to the blockchain network server. Based on this, the blockchain network server first responds to the on-chain request for the target transaction and obtains the signature result from the on-chain request. Then, it obtains the target object's target public key from the target object or a public platform, and uses the target public key to design the signature result to obtain reference resource status information. The reference resource status information is basically consistent with the specific content of the resource status digest result.

[0203] It should be noted that, in addition to recording the expected resource status of each resource pool after the execution of the target transaction, the reference resource status information in this embodiment can also record the latest resource status of each resource pool before the execution of the target transaction (the current resource status of each resource pool / the world state of each resource pool). In this case, the reference resource status information is obtained by performing a digest operation on the current resource status, the expected resource status, and the resource pool address.

[0204] The advantage of this embodiment is that, when constructing complete transaction information for a target transaction, it provides a transaction pre-execution channel based on the pre-execution module of a consensus node in a blockchain network. This allows the target object to pre-execute the target transaction through the pre-execution module of any consensus node before submitting the complete transaction information to the blockchain network for on-chain processing. This facilitates obtaining the resource status of the resource pool after the actual execution of the target transaction before formal execution. Based on the obtained resource status, expected resource status information is added to the target transaction, and this expected resource status information is merged with other transaction information to construct the complete transaction information. This improves the comprehensiveness of the transaction information and allows consensus nodes in the blockchain network to use the expected resource status information in the complete transaction information as a reference when packaging the target transaction. This effectively reduces the possibility of consensus nodes arbitrarily modifying the packaging order of the target transaction, increases the success rate of the target transaction execution, and ensures that the target transaction is uploaded to the blockchain as normally as possible.

[0205] Please refer to Figure 8 In one embodiment, step 610 specifically includes, but is not limited to, the following steps 810-830:

[0206] Step 810: For the target transaction, obtain the current resource status of the resource pool associated with the target transaction;

[0207] Step 820: Based on the current resource status and the transaction content of the target transaction, determine the changed resource status of the resource pool;

[0208] Step 830: Perform a digest operation on the changed resource status and the resource pool address to obtain the first resource status information.

[0209] Steps 810-830 are described in detail below.

[0210] In step 810, for the target transaction, the current resource status of the resource pool associated with the target transaction is obtained.

[0211] The current resource status is used to indicate the specific status of each resource pool associated with the target transaction, which is maintained by the blockchain network before the target transaction is executed.

[0212] In the specific implementation of this embodiment, with authorization, the resource pool address associated with the target transaction is first determined. Then, based on the resource pool address, the current resource status of the resource pool associated with the target transaction is found in the current resource status records of each resource pool in the background log of the blockchain network server.

[0213] In step 820, the changed resource status of the resource pool is determined based on the current resource status and the transaction content of the target transaction.

[0214] The changed resource status of a resource pool is used to indicate the resource status that occurs after the execution of the target transaction and changes have occurred in the various resource pools associated with the target transaction. The changed resource status is equivalent to the new resource status of the resource pool after the execution of the target transaction.

[0215] In the specific implementation of this embodiment, firstly, the target transaction is executed, and based on the transaction content and the current resource status, the state change that the resource pool will undergo is determined. Then, based on this state change, each state parameter in the current resource status is updated to obtain the changed resource status of the resource pool.

[0216] In step 830, a digest operation is performed on the changed resource status and the resource pool address to obtain the first resource status information.

[0217] The resource pool address is used to indicate the ownership information of the resource pool and to distinguish the resource pools of different objects. Each resource pool has a unique resource pool address.

[0218] In this specific implementation, firstly, the changed resource status and the resource pool address are concatenated to form concatenated data. Then, a predetermined digest algorithm is used to perform a digest operation on the concatenated data to obtain the first resource status information.

[0219] It should be noted that the aforementioned predefined hash algorithms include, but are not limited to, hash algorithms, message digest algorithms (such as MD5 hash algorithm), secure hash digest algorithms (such as SHA-1 hash algorithm), etc.

[0220] It should be noted that, in addition to recording the actual resource status (changed resource status) of each resource pool after the execution of the target transaction, the first resource status information in this embodiment can also record the latest resource status of each resource pool before the execution of the target transaction. In this case, the first resource status information is obtained by performing a digest operation on the current resource status, the changed resource status, and the resource pool address.

[0221] The advantage of this embodiment is that, for a given target transaction, by executing the target transaction, the changes in the resource status of the resource pool caused by the execution of the target transaction can be determined, clearly revealing the impact of the execution of each target transaction on the resources of all resource pools maintained by the blockchain network. Furthermore, concatenating and digesting the changed resource status and the resource pool address can merge multiple data into a whole. At the same time, the digest operation can also improve the storage security of resource status change information.

[0222] Please refer to Figure 9 In one embodiment, step 630 specifically includes, but is not limited to, the following steps 910-920:

[0223] Step 910: Concatenate the first resource status information filled into the first space into a resource status concatenation result according to the first execution order of the target transaction;

[0224] Step 920: Perform a summary operation on the concatenation result of resource states to obtain the first resource state dependency order information.

[0225] Steps 910-920 are described in detail below.

[0226] In step 910, the first resource status information filled into the first space is concatenated into a resource status concatenation result according to the first execution order of the target transaction.

[0227] The resource status concatenation result is used to indicate a string of information formed by concatenating multiple first resource status information according to the first execution order.

[0228] In the specific implementation of this embodiment, for the first resource status information of each target transaction in the first space, multiple first resource status information are concatenated into a string information according to the order of the target transactions in the first execution order, so as to realize the sequential concatenation of multiple first resource status information and obtain the resource status concatenation result.

[0229] In step 920, a summary operation is performed on the resource state concatenation result to obtain the first resource state dependency order information.

[0230] In the specific implementation of this embodiment, the first consensus node uses a predetermined digest algorithm to perform a digest operation on the resource status concatenation result, converts the resource status concatenation result into a random string of fixed length, and determines the generated random string as the first resource status information.

[0231] like Figure 10The diagram illustrates a simplified implementation process for generating the first resource state dependency order information. Specifically, the transaction pool of the first consensus node contains six transactions awaiting on-chain processing. These six transactions are, in order: Transaction 1, with a transaction digest of xxx and an expected resource state (reference resource state information) of relyroothash1; ...; Transaction 5, with a transaction digest of xx and an expected resource state of relyroothash5; and Transaction 6, with a transaction digest of xx and an expected resource state of relyroothash6. The target transactions selected from these six transactions are Transaction 1, Transaction 2, Transaction 3, Transaction 4, and Transaction 5. Based on this, firstly, the five target transactions are executed sequentially according to the first execution order, and the resource states (first resource state information) of the resource pools associated with each of the five target transactions after execution are obtained. Specifically, the resource state of Transaction 1 is roothash1, ..., and the resource state of Transaction 5 is roothash5. Next, for each target transaction, the resource state of each target transaction is compared with the expected resource state, and the target transactions whose resource states match the expected resource states are selected and filled into the first space. At this point, the first space includes transaction information for transactions 1, 2, 3, 4, and 5, indicating that the resource states of the five target transactions are consistent with their expected resource states. Based on this, the expected resource states of transactions 1, 2, 3, 4, and 5 are concatenated and summarized to generate the first resource state dependency order information.

[0232] The advantage of this embodiment is that by concatenating the first resource state information of each target transaction according to the first execution order, the packaging order of each target transaction can be limited by the generated resource state concatenation result, reducing the risk caused by random shuffling of target transactions. Simultaneously, a digest algorithm is introduced to perform a digest operation on the resource state concatenation result, converting it into ciphertext, which effectively improves the security and confidentiality of the first resource state dependency order information.

[0233] like Figure 11The diagram illustrates the overall process of the first consensus node processing the target transaction. Specifically, the first consensus node is a randomly determined packaging node in the blockchain network. First, the target object constructs a basic transaction related to resource interaction. This basic transaction refers to the target transaction containing only basic transaction information. The basic transaction can be represented as TX =<From,To,Value,Data,RelyHashRoot> TX refers to the base transaction (target transaction), which is a 5-tuple consisting of five fields. The From and To fields record the resource pool address associated with the target transaction, the Value field records the amount of resources involved in the resource interaction of the target transaction, the Data field records the parameters to be called when executing the target transaction, and the RelyHashRoot field records the resource state that the target object expects the resource pool associated with the target transaction to have after executing the target transaction (refer to resource state information).

[0234] In the basic transaction information described above, the From, To, Value, and Data fields all contain specific content. However, the RelyHashRoot field is currently empty and needs to be obtained by pre-executing the target transaction through the consensus nodes of the blockchain network. Based on this, the target object sends the basic transaction information to any consensus node in the blockchain network (e.g., the first consensus node), calls the first consensus node's pre-execution module, and the first consensus node uses this module to pre-execute the target transaction, obtaining the resource status of each resource pool after execution, and returning the obtained resource status to the target object. Next, the target object uses the resource status returned by the first consensus node as the expected resource status of each resource pool after the target transaction execution, performs a digest operation on the specific content of the expected resource status, and fills it into the RelyHashRoot field of the five-tuple of the basic transaction to generate reference resource status information, thereby converting the basic transaction information into complete transaction information. At this point, a target transaction with complete transaction information can be constructed, ensuring that each field in the five-tuple of the target transaction has a value. The expected resource state can be represented as RelyState = [(Address, nonce, balance, storageRoot, codeHash)]. Here, the Address field records the resource pool address associated with each resource pool in the target transaction; the nonce field records the number of transactions involved in each associated resource pool; the balance field records the resource quantity of each resource pool; the storageRoot field records the Merkle root hash of the resource pool's storage state; and the codeHash field records the code hash of each resource pool. It should be noted that the expected resource state will at least include the resource state of the resource pools pointed to by the From and To fields.

[0235] Furthermore, the target object constructs complete transaction information for the target transaction and submits the target transaction to the first consensus node for on-chain processing. At this time, the first consensus node stores the target transaction in the transaction pool. When the first consensus node receives a transaction processing request, it executes each target transaction sequentially according to a preset first execution order and generates the first resource state information RelyHashRoot′ for the target transaction.

[0236] Next, for each target transaction, the reference resource state information RelyHashRoot and the first resource state information RelyHashRoot′ are compared. If the reference resource state information RelyHashRoot and the first resource state information RelyHashRoot′ are consistent, the first consensus node will use the packaging module to package the target transaction into the initial block; if the reference resource state information RelyHashRoot and the first resource state information RelyHashRoot′ are inconsistent, it indicates that the execution of the target transaction does not meet the expectations of the target object, and the target transaction is discarded. Next, the first consensus node will concatenate and digest the first resource state information of each target transaction in the initial block to form the first resource state dependency order information. The first resource state dependency order information BlockRelayRoot can be represented as BlockRelayRoot = Hash(RelyHashRoot1, RelyHashRoot2, ..., RelyHashRootN); RelyHashRoot1 is the first resource state information of the first target transaction, RelyHashRoot2 is the first resource state information of the second target transaction, and RelyHashRootN is the first resource state information of the Nth target transaction, where N is a positive integer greater than 2.

[0237] Finally, the target transactions and the first resource state dependency order information of the initial block are used to construct a complete block, resulting in the target block. This target block is then broadcast to all second consensus nodes in the blockchain network. The target block can be represented as Block = (Block... header Block body ), where Block header Used to record the block header information of the target block. body The block header information of the target block is used to record the block body information. In addition to common fields such as block height, the block header information of the target block also records the first resource state dependency order information, BlockRelayRoot.

[0238] The advantage of this embodiment is that when a user submits a target transaction, they can define the expected resource status of each resource pool that the target transaction depends on during execution. This ensures that the first consensus node only packages the target transaction into a block for broadcast after the actual resource status of each resource pool meets the user's expectations. This effectively reduces the possibility of transaction execution failure due to changes in the resource status of the dependent resource pools, thereby improving transaction execution security, transaction success rate, and user resource security.

[0239] Step 330 will be described in detail below.

[0240] In step 330, multiple target transactions and the first resource state dependency order information are sent to the second consensus node so that the second consensus node can execute the target transactions and, according to the second execution order of the target transactions, concatenate the second resource state information of each resource pool after the target transactions are executed into the second resource state dependency order information. When the first resource state dependency order information and the second resource state dependency order information are consistent, the consensus of multiple target transactions is put on the chain.

[0241] In one embodiment, when sending multiple target transactions and first resource state dependency order information to the second consensus node, the multiple target transactions and first resource state dependency order information are first packaged into a target block. The multiple target transactions are recorded in the block body of the target block, and the first resource state dependency order information is recorded in the block header of the target block. Further, the first consensus node broadcasts the target block in the blockchain network, sending it to each second consensus node in the blockchain network. This causes the second consensus nodes to execute the target transactions and, according to the second execution order of the target transactions, concatenate the second resource state information of each resource pool after the target transactions are executed into second resource state dependency order information. When the first resource state dependency order information matches the second resource state dependency order information, the second consensus node records the target block on the blockchain maintained by the second consensus node.

[0242] The advantage of this embodiment is that when packaging target transactions into a block, the first resource state dependency order information formed by the first resource state information of multiple target transactions is added to the block header information of the target block. The packaging order of each target transaction in the target block can be limited by the first resource state dependency order information, which can effectively reduce the risk of target transactions in the target block being out of order, thereby improving the security of transaction processing.

[0243] Please refer to Figure 12 In one embodiment, step 330 specifically includes, but is not limited to, the following steps 1210-1230:

[0244] Step 1210: Obtain the second resource status information of each resource pool after the target transaction is executed;

[0245] Step 1220: If the second resource status information is consistent with the reference resource status information, fill the second resource status information into the second space;

[0246] Step 1230: Concatenate the various second resource state information that are filled into the second space into second resource state dependency order information according to the second execution order of the target transaction.

[0247] Steps 1210-1230 are described in detail below.

[0248] The second space refers to the data space used by the second consensus node to store the target transaction whose second resource state information is consistent with the reference resource state information.

[0249] In this specific implementation, steps 1210-1230 are essentially the same as steps 610-630 described above. The difference lies in that steps 610-630 are executed by the first consensus node, occurring before the target transaction is packaged into a block; while steps 1210-1230 are executed by the second consensus node, occurring after the first consensus node packages the target transaction into the target block and broadcasts the target block. The executing entities and execution times differ. For brevity, these will not be elaborated further here.

[0250] The advantage of this embodiment is that after the first consensus node broadcasts the target block, each second consensus node also executes the target transactions of the target block and obtains the second resource status information of each resource pool after the target transactions are executed. This second resource status information is compared with the reference resource status information, which can better identify abnormal transactions that the first consensus node failed to detect during the packaging process. It also reduces the risk of the first consensus node maliciously packaging erroneous transactions that should not be uploaded to the chain. Furthermore, the second consensus nodes fill the second space with the target transactions based on the second resource status information and the reference resource status information, and sequentially concatenate the second resource status information of the target transactions that meet the requirements in the second space. This allows for the sequential verification of the target transactions in the target block based on the generated second resource status dependency order information, which helps improve the orderliness of the target transactions in the target block and the security of the second resource status dependency order information.

[0251] Please refer to Figure 13 In another embodiment, step 330 specifically includes, but is not limited to, the following steps 1310-1350:

[0252] Step 1310: Receive the target block sent by the first consensus node and obtain the block header information of the target block;

[0253] Step 1320: Perform the first verification of the target block based on the block header information;

[0254] Step 1330: If the first verification is successful, based on the second execution order, sequentially obtain the second resource status information of each resource pool after the target transaction is executed;

[0255] Step 1340: If the second resource status information is consistent with the reference resource status information, fill the second resource status information into the second space;

[0256] Step 1350: Concatenate the various second resource state information that are filled into the second space into second resource state dependency order information according to the second execution order.

[0257] Steps 1310-1350 are described in detail below.

[0258] In step 1310, the target block sent by the first consensus node is received, and the block header information of the target block is obtained.

[0259] Block header information refers to the information stored in the target block that can be used to identify and verify the target block. The block header information includes the target block height and the target block digest.

[0260] The target block height is used to indicate the specific position of the target block on the entire blockchain, representing the height of the target block relative to the genesis block.

[0261] The target block digest is used to indicate the integrated result of the transaction digests of all target transactions in the target block. The target block digest can also be called the hash value of the target block. It can be calculated from the transaction digests of each target transaction in the target block and the digest value of the previous block. The target block digest can be used to verify the integrity and security of the target block.

[0262] In this specific implementation, after the first consensus node broadcasts the target block in the blockchain network, the second consensus node receives the target block sent by the first consensus node. At this time, the second consensus node extracts the block information from the target block, obtaining the block header information and block body information. The block header information mainly includes the target block height, target block digest, and first resource state dependency order information mentioned above. The block body information mainly includes a transaction list formed by each target transaction, which stores the transaction content, transaction digest, and reference resource state information of each target transaction.

[0263] In step 1320, the target block is first verified based on the block header information.

[0264] The first verification is used to indicate the specific methods and procedures for verifying whether there are errors in the block header information of the target block.

[0265] To save space, the specific process of performing the first verification of the target block based on the block header information in this embodiment will be described in detail below, and will not be repeated here.

[0266] Furthermore, the specific processes of steps 1330-1350 are similar to those of steps 1210-1230 described above. To save space, they will not be repeated here.

[0267] It should be noted that, in addition to recording the actual resource status of each resource pool after the second consensus node executes the target transaction, the second resource status information in this embodiment can also record the latest resource status of each resource pool before the execution of the target transaction (the current resource status of each resource pool / the world state of each resource pool). In this case, the second resource status information is obtained by performing a digest operation on the current resource status, the actual resource status of each resource pool after the second consensus node executes the target transaction, and the resource pool address.

[0268] The advantage of this embodiment is that after receiving the target block, the second consensus node verifies various information in the block header (e.g., block height, block digest, etc.). Simultaneously, the second consensus node generates second resource state information and second resource state dependency order information in the same way as the first consensus node. This enables the individual verification of each target transaction within the target block using the differences between the second resource state information and the reference resource state information. Together with the first consensus node, this achieves dual verification of target transactions, reducing the risk of abnormal transactions being uploaded to the chain. Furthermore, it allows for the comparison of the differences between the second and first resource state dependency order information to determine whether there are order differences between the target transactions during packaging and after receipt, reducing the risk of transaction order disruption and thus improving transaction processing security.

[0269] Please refer to Figure 14 In one embodiment, step 1320 specifically includes, but is not limited to, the following steps 1410-1430:

[0270] Step 1410: Obtain the current block height of the blockchain;

[0271] Step 1420: Determine the height difference between the target block height and the current block height;

[0272] Step 1430: If the height difference is determined to be 1, then the first verification is confirmed to be successful.

[0273] Steps 1410-1430 are described in detail below.

[0274] In step 1410, since each block in the blockchain has a block height, the block height of the last block in the blockchain can reflect information such as the number of blocks in the blockchain at the current moment. Based on this, with authorization, the last block is found on the blockchain, and the block height of the last block is determined as the current block height of the blockchain.

[0275] In step 1420, the difference between the target block height and the current block height is calculated, and the target block height is subtracted from the current block height to obtain the height difference between the target block height and the current block height.

[0276] In step 1430, if the height difference is determined to be 1, it indicates that the target block is the latest block that should be recorded on the blockchain, so the first verification is confirmed to be successful. If the height difference is determined to be non-1, it indicates that the target block is not the latest block that should be recorded on the blockchain, so the first verification is confirmed to be unsuccessful, and the second consensus node will not record the target block on its own blockchain.

[0277] like Figure 15 The diagram illustrates the specific process of the first verification of the target block's block height. Specifically, at the current moment, the latest block on the blockchain is block 40, so the current block height is 40. The target block's header information records its height as 41. Based on this, since 41-40=1, the height difference between the target block height and the current block height is 1, indicating that the target block is the latest block that should be recorded on the blockchain. Therefore, the first verification is successful.

[0278] The advantage of this embodiment is that by verifying the on-chain position of the target block based on the height difference between the current height of the blockchain and the target block height, it is possible to determine whether the target block meets the on-chain requirements in terms of position, thereby improving the security and accuracy of block on-chaining.

[0279] Please refer to Figure 14 In one embodiment, step 1320 specifically includes, but is not limited to, the following steps 1610-1630:

[0280] Step 1610: Obtain the transaction summary of each target transaction in the target block;

[0281] Step 1620: Integrate the transaction summaries of multiple target transactions to obtain the target summary result;

[0282] Step 1630: If the target digest result is found to be consistent with the target block digest, then the first verification is considered successful.

[0283] Steps 1610-1630 are described in detail below.

[0284] In step 1610, after receiving the target block, the second consensus node extracts the block information of the target block to obtain the block header information and block body information of the target block. Based on this, the second consensus node can obtain the transaction digest of each target transaction from the block body information and obtain the digest value of the previous block of the target block from the block header information.

[0285] In step 1620, firstly, for each target transaction in the block header information of the target block, the transaction digest of each target transaction is used as the leaf node of the lowest level of the Merkle tree. A digest operation is performed on each pair of adjacent transaction digests (leaf nodes) to obtain the leaf nodes of the next higher level. Next, for each leaf node of the next higher level, a digest operation is performed on each pair of adjacent leaf nodes to obtain the leaf nodes of the next higher level, and so on, until the root node digest of the Merkle tree is obtained. Further, the root node digest of the Merkle tree and the digest value of the previous block of the target block are concatenated and digested to obtain the target digest result.

[0286] In step 1630, firstly, the target digest result is compared with the target block digest. Next, if the target digest result and the target block digest are found to be consistent, it indicates that the target transaction recorded in the target block is complete, and therefore the first verification is successful. Conversely, if the target digest result and the target block digest are found to be inconsistent, it indicates that the target transaction recorded in the target block is incomplete, and therefore the first verification is unsuccessful.

[0287] like Figure 17 The diagram illustrates the specific process of performing the first verification of the target block digest of the target block. Specifically, the block body information of the target block stores transaction information for five transactions, and the block header information stores the Merkle root (target block digest) of multiple transactions as rqdn8791. The digest value of the previous block is xadqf8q5. Based on this, firstly, the transaction digests of transaction 1 and transaction 2 are concatenated and digested to obtain the first concatenated digest result; the transaction digests of transaction 3 and transaction 4 are concatenated and digested to obtain the second concatenated digest result. Next, the first and second concatenated digest results are concatenated and digested to obtain the third concatenated digest result; the third concatenated digest result is concatenated and digested with the transaction digest of transaction 5 to obtain the preliminary Merkle root of multiple target transactions of the target transaction. Then, the preliminary Merkle root is concatenated and digested with the digest value of the previous block to obtain the concatenated digest result of multiple transaction digests (the target digest result). Finally, the concatenated digest result is compared with the Merkle root (target block digest) of multiple transactions to form a block header digest. If the concatenated digest result matches the Merkle root of multiple transactions, it indicates that the target transaction recorded in the target block is complete, and therefore the first verification is passed.

[0288] The advantage of this embodiment is that it integrates the transaction digests of multiple transactions in the target block and the digest value of the previous block into a target digest result. By comparing the target digest result with the target block digest recorded in the block header information of the target block, the integrity and security of the target block can be verified. Only after the first verification is passed will the on-chain operation of the target block be performed. This can improve the integrity and security of the target block and the security of the target transaction processing, and reduce the adverse effects caused by recording non-compliant blocks or transactions on the blockchain.

[0289] like Figure 18 The diagram illustrates a simplified implementation process for generating the second resource state dependency order information. Specifically, the target block consists of a block header and a block body. The block header records the target block height as 41, the digest value of the previous block as xadqf8q5, the Merkle root of multiple transactions in the block body as rqdn8791, and the first resource state dependency order information as hash(roothash1, ..., roothash5). The block body records the transaction content, transaction digest, and expected resource state of transactions 1, 2, 3, 4, and 5. Based on this, the second consensus node first executes these five target transactions sequentially according to the transaction information of each target transaction (transaction 1, 2, 3, 4, and 5) in the block body information, and obtains the resource state after the pre-execution of each target transaction, resulting in the second resource state of transaction 1 as xxhash1, ..., and the second resource state of transaction 5 as xxhash5. Next, the second resource state of each target transaction is compared with its expected resource state. Target transactions whose second resource states match their expected resource states are then populated into the second space. Based on this, the second space contains transactions 1, 3, and 5. Further, the second resource states of transactions 1, 3, and 5 are concatenated and summarized to obtain the second resource state dependency order information. This second resource state dependency order information is then compared with the first resource state dependency order information in the block header of the target block to determine if the target block's resource dependency order meets the requirements. Only when the second resource state dependency order information matches the first resource state dependency order information is the target block recorded on the blockchain; otherwise, the target block consensus is deemed to have failed, and the target block is not added to the blockchain.

[0290] like Figure 19The diagram illustrates the overall process of a second consensus node processing a target transaction within a target block. Specifically, a second consensus node is any verification node in the blockchain network. First, the first consensus node broadcasts the target block to synchronize it to the block synchronization modules of all second consensus nodes. Next, the second consensus nodes perform a first verification on the synchronized target block. This first verification process includes verifying the block header information, the target block height, and the block digest. If the first verification fails, the second consensus node rejects the target block and does not upload the target transaction within it to the blockchain. If the first verification passes, the second consensus node invokes its own pre-execution module to pre-execute each target transaction within the target block and generates second resource state information based on the post-execution resource pool state associated with the target transaction.

[0291] Furthermore, for each target transaction, the second consensus node verifies the second resource status information based on the reference resource status information, comparing the second resource status information of the target transaction with the reference resource status information. If the second resource status information and the reference resource status information are consistent, the second consensus node populates the target transaction into the second space, where the second space can be an initially empty list of transactions.

[0292] Based on this, after all transactions in the target block have undergone comparison of the second resource state information and the reference resource state information, the second consensus node will concatenate and summarize the second resource state information of each target transaction in the second space to obtain the second resource state dependency order information. The second resource state dependency order information BlockRelayRoot' can be represented as BlockRelayRoot' = Hash(RelyHashRoot1, RelyHashRoot2, ..., RelyHashRootN).

[0293] Furthermore, the block synchronization module of the second consensus node verifies the first resource state dependency order information by comparing the second resource state dependency order information `BlockRelayRoot'` with the first resource state dependency order information `BlockRelayRoot`. If the second resource state dependency order information `BlockRelayRoot'` and the first resource state dependency order information `BlockRelayRoot` are consistent, it indicates that the target block verification has passed, and the second consensus node will accept the target block and record it on its maintained blockchain. If the second resource state dependency order information `BlockRelayRoot'` and the first resource state dependency order information `BlockRelayRoot` are inconsistent, it indicates that the target block verification has failed, and the second consensus node will refuse to record the target block on the blockchain. The first consensus node has engaged in malicious operation during the transaction packaging process, and can be penalized according to the consensus protocol.

[0294] The advantage of this embodiment is that when the second consensus node (verification node) verifies each target transaction of the target block, it first verifies whether the resource status of the resource pools on which the target transaction depends before execution meets the user's expected requirements. Then, it executes the target transaction and determines whether the resource status of each resource pool after execution meets the user's expected requirements. Based on the consistency check of the reference resource status information and the second resource status information, the first consensus node can accurately package the target transactions into the target block according to the user's expectations. Furthermore, the second consensus node compares the second resource status dependency order information generated by each target transaction in the target block with the first resource status dependency order information generated by the first consensus node during packaging to determine that the transaction order of each target transaction in the target block has not changed before and after packaging. In addition, the above embodiment also introduces a penalty mechanism to reduce the risk of the first consensus node engaging in malicious operations during transaction packaging. This ensures that the target transactions submitted by the user are executed and packaged as expected, preventing user resources from being lost due to the first consensus node modifying the transaction execution order during transaction packaging. This improves the security of transaction processing in both the transaction packaging and block verification stages.

[0295] The following describes the implementation details of a blockchain transaction processing method according to an embodiment of this disclosure.

[0296] The following reference Figure 20 This document details a specific implementation process of the blockchain transaction processing method according to embodiments of the present disclosure.

[0297] Step 2001: The target object sends a request to construct the target transaction to the first consensus node;

[0298] Step 2002: The first consensus node pre-executes the target transaction and obtains the expected state of each resource pool after the target transaction is pre-executed;

[0299] Step 2003: The first consensus node feeds back to the target object the expected status of each resource pool after the pre-execution of the target transaction;

[0300] Step 2004: The target object sends a request to the first consensus node to put the target transaction on the chain;

[0301] Step 2005: The first consensus node executes the target transaction and obtains the first resource status information of each resource pool after the target transaction is executed;

[0302] Step 2006: If the first resource status information is consistent with the reference resource status information, the first consensus node will fill the first resource status information into the first space;

[0303] Step 2007: The first consensus node will fill the first resource state information in the first space and concatenate it into the first resource state dependency order information according to the first execution order of the target transaction.

[0304] Step 2008: The first consensus node packages multiple target transactions and the first resource state dependency order information into a target block;

[0305] Step 2009: The first consensus node sends the target block to the second consensus node;

[0306] Step 2010: The second consensus node performs the first verification of the target block based on the block header information;

[0307] Step 2011: If the first verification is successful, the second consensus node, based on the second execution order, sequentially obtains the second resource status information of each resource pool after the execution of the target transaction;

[0308] Step 2012: If the second resource status information is consistent with the reference resource status information, the second consensus node will fill the second resource status information into the second space;

[0309] Step 2013: The second consensus node will fill in the various second resource state information in the second space and concatenate them into second resource state dependency order information according to the second execution order.

[0310] Step 2014: When the first resource state dependency order information is consistent with the second resource state dependency order information, the second consensus node determines that the target block consensus is successful.

[0311] Step 2015: The second consensus node records the target transaction to the blockchain.

[0312] The specific implementation process of steps 2001-2003 is similar to that of steps 710-730. The specific implementation process of steps 2004-2007 is similar to that of steps 610-630. The specific implementation process of steps 2008-2009 is similar to that of step 330. The specific implementation process of step 2010 is similar to that of steps 1410-1430 and 1610-1630. The specific implementation process of steps 2011-2015 is similar to that of steps 1330-1350. To save space, these will not be elaborated further.

[0313] The apparatus and device according to embodiments of this disclosure will now be described.

[0314] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0315] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0316] Figure 21 This is a schematic diagram of the structure of a blockchain transaction processing device 2100 provided in an embodiment of this disclosure. The blockchain transaction processing device 2100 is applied to a first consensus node in a blockchain network, which includes a first consensus node and a second consensus node. The blockchain transaction processing device 2100 includes:

[0317] The acquisition unit 2110 is used to acquire transaction processing requests, wherein the transaction processing requests are used to package multiple target transactions and put them on the blockchain.

[0318] The first processing unit 2120 is used to execute the target transaction and, according to the first execution order of the target transaction, concatenate the first resource status information of each resource pool after the execution of the target transaction into first resource status dependency order information.

[0319] The second processing unit 2130 is used to send multiple target transactions and first resource state dependency order information to the second consensus node so that the second consensus node can execute the target transactions and, according to the second execution order of the target transactions, concatenate the second resource state information of each resource pool after the target transactions are executed into second resource state dependency order information. When the first resource state dependency order information is consistent with the second resource state dependency order information, the consensus of multiple target transactions is put on the chain.

[0320] Optionally, the first processing unit 2120 includes:

[0321] The acquisition module (not shown) is used to acquire the first resource status information of each resource pool after the target transaction is executed;

[0322] A first filling module (not shown) is used to fill the first resource status information into the first space if the first resource status information is consistent with the reference resource status information.

[0323] The first cascading module (not shown) is used to cascade the various first resource state information filled into the first space into first resource state dependency order information according to the first execution order of the target transaction.

[0324] Optionally, the acquisition module (not shown) is used for:

[0325] For the target transaction, obtain the current resource status of the resource pool associated with the target transaction;

[0326] Based on the current resource status and the transaction content of the target transaction, determine the changed resource status of the resource pool;

[0327] A digest operation is performed on the changed resource status and the resource pool address to obtain the first resource status information.

[0328] Optionally, the cascade module (not shown) is used for:

[0329] The first resource status information filled into the first space is concatenated into a resource status concatenation result according to the first execution order of the target transaction;

[0330] A summary operation is performed on the concatenated resource states to obtain the dependency order information of the first resource state.

[0331] Optionally, the second processing unit 2130 is used for:

[0332] Obtain the second resource status information of each resource pool after the target transaction is executed;

[0333] If the second resource status information is consistent with the reference resource status information, the second resource status information will be filled into the second space;

[0334] The various second resource state information that are filled into the second space are concatenated into second resource state dependency order information according to the second execution order of the target transaction.

[0335] Optionally, the reference resource status information is obtained by the first consensus node in the following ways:

[0336] Obtain the construction request of the target object for the target transaction, wherein the construction request includes the transaction content of the target transaction and the resource pool associated with the target transaction;

[0337] Based on the current resource status of the resource pool and the transaction content, the expected resource status of the resource pool is determined, and the expected resource status is returned to the target object so that the target object can generate the signature result of the target transaction according to the expected resource status and the transaction content.

[0338] In response to an on-chain request for the target transaction, the signature result is obtained, and the signature result is designed using the target object's target public key to obtain reference resource status information.

[0339] Optionally, the target object generates a signature result for the target transaction based on the expected resource status and transaction content, including:

[0340] Perform a summary operation on the expected resource status to obtain the resource status summary result;

[0341] The resource status summary results and transaction content are integrated to obtain the transaction integration result;

[0342] The transaction integration result is encrypted using the target object's private key to obtain the signature result.

[0343] Optionally, the second processing unit 2130 is used for:

[0344] Package multiple target transactions and first resource state dependency order information into a target block;

[0345] Send the target block to the second consensus node;

[0346] Multiple target transactions are agreed upon and recorded on the blockchain, including: recording the target block on the blockchain maintained by the second consensus node.

[0347] Optionally, the blockchain transaction processing device 2100 further includes a verification unit (not shown), which includes:

[0348] A receiving module (not shown) is used to receive the target block sent by the first consensus node and obtain the block header information of the target block;

[0349] A verification module (not shown) is used to perform the first verification of the target block based on the block header information;

[0350] A processing module (not shown) is used to, if the first verification is determined to be successful, sequentially obtain the second resource status information of each resource pool after the target transaction is executed, based on the second execution order.

[0351] The second filling module (not shown) is used to fill the second resource status information into the second space if the second resource status information is consistent with the reference resource status information.

[0352] The second cascading module (not shown) is used to cascade the various second resource state information filled into the second space into second resource state dependency order information according to the second execution order.

[0353] Optionally, the block header information includes the target block height;

[0354] The verification module (not shown) is used for:

[0355] Get the current block height of the blockchain;

[0356] Determine the height difference between the target block height and the current block height;

[0357] If the height difference is determined to be 1, then the first verification is considered successful.

[0358] Optionally, the block header information includes the target block digest of the target block;

[0359] The verification module (not shown) is used for:

[0360] Obtain the transaction summary of each target transaction in the target block;

[0361] The transaction summaries of multiple target transactions are integrated to obtain the target summary result;

[0362] If the target digest result is determined to be consistent with the target block digest, then the first verification is considered successful.

[0363] Optionally, multiple target transactions can be determined in the following way:

[0364] For each candidate transaction in the transaction pool of the first consensus node, determine the transaction timestamp of the candidate transaction;

[0365] The target transaction is selected from multiple candidate transactions based on the time of the transaction timestamp.

[0366] Optionally, multiple target transactions can be determined in the following way:

[0367] For each candidate transaction in the transaction pool of the first consensus node, determine the on-chain resource overhead of the candidate transaction;

[0368] Based on the on-chain resource overhead, the target transaction is selected from multiple candidate transactions.

[0369] Optionally, the on-chain resource overhead of candidate transactions is determined, including:

[0370] Obtain the overhead rate of the blockchain network and the transaction size of candidate transactions;

[0371] Calculate the on-chain resource overhead of candidate transactions based on transaction size and overhead rate.

[0372] Reference Figure 22 , Figure 22 To implement the structural block diagram of the terminal portion of the blockchain transaction processing method according to embodiments of this disclosure, the terminal includes: a radio frequency (RF) circuit 2210, a memory 2215, an input unit 2230, a display unit 2240, a sensor 2250, an audio circuit 2260, a wireless fidelity (WiFi) module 2270, a processor 2280, and a power supply 2290, etc. Those skilled in the art will understand that... Figure 22 The terminal structure shown does not constitute a limitation on mobile phones or computers and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0373] The RF circuit 2210 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 2280; in addition, it transmits uplink data to the base station.

[0374] The memory 2215 can be used to store software programs and modules. The processor 2280 executes various functional applications and data processing of the target terminal by running the software programs and modules stored in the memory 2215.

[0375] The input unit 2230 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the target terminal. Specifically, the input unit 2230 may include a touch panel 2231 and other input devices 2232.

[0376] Display unit 2240 can be used to display input or provided information, as well as various menus of the target terminal. Display unit 2240 may include display panel 2241.

[0377] Audio circuitry 2260, speaker 2261, and microphone 2262 provide an audio interface.

[0378] In this embodiment, the processor 2280 included in the terminal can execute the blockchain transaction processing method of the previous embodiment.

[0379] The terminals disclosed in this embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to data security, blockchain, data storage, and information technology.

[0380] Figure 23 This is a partial structural block diagram of a server for implementing the blockchain transaction processing method of this disclosure. The server can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 2322 (e.g., one or more processors) and memory 2332, and one or more storage media 2130 (e.g., one or more mass storage devices) for storing application programs 2342 or data 2344. The memory 2332 and storage media 2330 can be temporary or persistent storage. The program stored in the storage media 2330 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 2322 may be configured to communicate with the storage media 2330 and execute the series of instruction operations in the storage media 2330 on the server.

[0381] The server may also include one or more power supplies 2323, one or more wired or wireless network interfaces 2350, one or more input / output interfaces 2358, and / or one or more operating systems 2341, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0382] The central processing unit 2322 in the server can be used to execute the blockchain transaction processing method of the present disclosure embodiments.

[0383] This disclosure also provides a computer-readable storage medium for storing program code for executing the blockchain transaction processing methods of the foregoing embodiments.

[0384] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the blockchain transaction processing method described above.

[0385] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0386] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0387] It should be understood that in the description of the embodiments of this disclosure, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0388] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and 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 apparatuses or units, and may be electrical, mechanical, or other forms.

[0389] In this disclosure, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0390] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0391] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0392] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0393] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0394] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A blockchain transaction processing method, characterized by, A first consensus node applied to a blockchain network, the blockchain network comprising the first consensus node and a second consensus node, the method comprising: obtaining a transaction processing request, wherein the transaction processing request is used to package a plurality of target transactions for chain; executing the target transactions, and concatenating first resource state information of each resource pool after the target transactions are executed into first resource state dependency order information according to a first execution order of the target transactions; sending the plurality of target transactions and the first resource state dependency order information to the second consensus node, so that the second consensus node executes the target transactions, and concatenates second resource state information of each resource pool after the target transactions are executed into second resource state dependency order information according to a second execution order of the target transactions, and when the first resource state dependency order information and the second resource state dependency order information are consistent, the plurality of target transactions are consensus-chained.

2. The method of claim 1, wherein, The target transaction has reference resource state information, which is used to indicate the expected resource state of each resource pool after the target transaction is executed. The first resource state information of each resource pool after the target transaction is executed is obtained. If the first resource state information is consistent with the reference resource state information, the first resource state information is filled into a first space. Each first resource state information filled into the first space is concatenated into the first resource state dependency order information according to the first execution order of the target transaction. The second resource state information of each resource pool after the target transaction is executed is obtained.

3. The method of claim 2, wherein, If the second resource state information is consistent with the reference resource state information, the second resource state information is filled into a second space. Each second resource state information filled into the second space is concatenated into the second resource state dependency order information according to the second execution order of the target transaction. The first resource state information of each resource pool after the target transaction is executed is obtained. For the target transaction, the current resource state of the resource pool associated with the target transaction is obtained.

4. The method of claim 2, wherein, Based on the current resource state and the transaction content of the target transaction, the changed resource state of the resource pool is determined. The changed resource state and the resource pool address of the resource pool are subjected to a digest operation to obtain the first resource state information. The reference resource state information is obtained by the first consensus node in the following way: obtaining a construction request of a target object for the target transaction, wherein the construction request comprises the transaction content of the target transaction and the resource pool associated with the target transaction; 5. The method of claim 2, wherein, ​ ​ determining an expected resource state of the resource pool based on the current resource state of the resource pool and the transaction content, and returning the expected resource state to the target object, so that the target object generates a signature result of the target transaction according to the expected resource state and the transaction content; in response to a request for on-chain of the target transaction, obtaining the signature result, and using a target public key of the target object to un-sign the signature result, to obtain the reference resource state information.

6. The method of claim 5, wherein, The target object generates a signature result of the target transaction according to the expected resource state and the transaction content, comprising: performing an abstract operation on the expected resource state to obtain a resource state abstract result; integrating the resource state abstract result and the transaction content to obtain a transaction integration result; encrypting the transaction integration result based on a target private key of the target object to obtain the signature result.

7. The method of claim 2, wherein, The first resource state dependency order information is obtained by concatenating each first resource state information filled into the first space according to a first execution order of the target transaction, comprising: concatenating each first resource state information filled into the first space according to a first execution order of the target transaction to obtain a resource state concatenation result; performing an abstract operation on the resource state concatenation result to obtain the first resource state dependency order information.

8. The method of claim 1, wherein, The plurality of target transactions and the first resource state dependency order information are sent to the second consensus node, comprising: packaging the plurality of target transactions and the first resource state dependency order information into a target block; sending the target block to the second consensus node; The plurality of target transactions are consensus on-chain, comprising: recording the target block on a block chain maintained by the second consensus node.

9. The method of claim 7, wherein, The second consensus node executes the target transaction, and concatenates second resource state information of each resource pool after execution of the target transaction according to a second execution order of the target transaction to obtain second resource state dependency order information, comprising: receiving the target block sent by the first consensus node, and obtaining block header information of the target block; performing a first verification on the target block based on the block header information; if it is determined that the first verification is passed, obtaining the second resource state information of each resource pool after execution of the target transaction in sequence based on the second execution order; if the second resource state information is consistent with the reference resource state information, filling the second resource state information into a second space; concatenating each second resource state information filled into the second space according to the second execution order to obtain the second resource state dependency order information.

10. The method of claim 9, wherein, The block header information comprises a target block height of the target block; The first verification on the target block based on the block header information comprises: obtaining a current block height of a block chain; determining a height difference between the target block height and the current block height; if it is determined that the height difference is 1, it is determined that the first verification is passed.

11. The method of claim 9, wherein, The block header information includes a target block digest of the target block; The first verification of the target block based on the block header information includes: Obtaining a transaction digest of each target transaction of the target block; Integrating the transaction digests of the target transactions to obtain a target digest result; If it is determined that the target digest result is consistent with the target block digest, it is determined that the first verification is passed.

12. The method of claim 1, wherein, The target transactions are determined in the following manner: For each candidate transaction in the transaction pool of the first consensus node, determining a transaction timestamp of the candidate transaction; Based on the early or late of the transaction timestamp, filtering the target transactions from the candidate transactions.

13. The method of claim 1, wherein, The target transactions are determined in the following manner: For each candidate transaction in the transaction pool of the first consensus node, determining a resource overhead of the candidate transaction for on-chain; Based on the resource overhead, filtering the target transactions from the candidate transactions.

14. The method of claim 13, wherein, The determination of the resource overhead of the candidate transaction includes: Obtaining an overhead rate of the blockchain network and a transaction size of the candidate transaction; Based on the transaction size and the overhead rate, calculating the resource overhead of the candidate transaction. 15.A blockchain transaction processing apparatus characterized by comprising: A first consensus node applied to a blockchain network, the blockchain network including the first consensus node and a second consensus node, the device including: An obtaining unit configured to obtain a transaction processing request, wherein the transaction processing request is used to package and on-chain a plurality of target transactions; A first processing unit configured to execute the target transactions, and concatenate first resource state information of each resource pool after execution of the target transactions into first resource state dependency order information according to a first execution order of the target transactions; A second processing unit configured to send the plurality of target transactions and the first resource state dependency order information to the second consensus node, so that the second consensus node executes the target transactions, concatenates second resource state information of each resource pool after execution of the target transactions into second resource state dependency order information according to a second execution order of the target transactions, and on-chain the plurality of target transactions when the first resource state dependency order information is consistent with the second resource state dependency order information.

16. An electronic device, comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the blockchain transaction processing method of any one of claims 1 to 14.

17. A computer readable storage medium, the storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the blockchain transaction processing method of any one of claims 1 to 14.

18. A computer program product comprising a computer program, which is read and executed by a processor of an electronic device, so that the electronic device performs the blockchain transaction processing method of any one of claims 1 to 14.

Images