Data processing method and device, electronic equipment, computer readable storage medium and computer program product

Abstract

The application provides a data processing method and device, electronic equipment, computer program product and computer readable storage medium. The method comprises: acquiring a plurality of transaction data, each transaction data corresponding to at least two virtual resources; for each transaction data, determining the unit price of each virtual resource corresponding to the transaction data; based on each unit price corresponding to each transaction data, determining a target transaction data from the plurality of transaction data; performing encapsulation processing on the target transaction data to obtain a transaction block; verifying the transaction block, and when the transaction block is verified, executing a transaction task based on the transaction block. Through the application, the accuracy and efficiency of transaction execution can be improved.

Description

Technical Field

[0001] This application relates to computer technology, and more particularly to a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] In related technologies, blockchain systems typically merge the storage, computing, and bandwidth resources of nodes into a single virtual resource, uniformly calculating the overall consumption of all resources. Simultaneously, they assess the overall unit price of all resources based on network congestion levels. Then, the transaction fee is obtained by multiplying the overall resource consumption by the overall unit price. However, because different resources are measured using a uniform unit price, the calculated transaction fees can easily become inaccurate. Summary of the Invention

[0003] This application provides a data processing method, apparatus, computer-readable storage medium, and computer program product that can improve the accuracy and efficiency of transaction execution.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a data processing method, the method comprising:

[0006] Acquire multiple transaction data, each of which corresponds to at least two virtual resources;

[0007] For each of the aforementioned transaction data, determine the unit price of each of the aforementioned virtual resources corresponding to the transaction data;

[0008] Based on each unit price corresponding to each of the aforementioned transaction data, the target transaction data is determined from the plurality of transaction data;

[0009] The target transaction data is encapsulated to obtain a transaction block;

[0010] The transaction block is verified, and when the transaction block is verified, the transaction task is executed based on the transaction block.

[0011] This application provides a data processing apparatus, including:

[0012] A model is used to acquire multiple transaction data, each of which corresponds to at least two virtual resources.

[0013] The determining module is configured to, for each of the transaction data, determine the unit price of each of the virtual resources corresponding to the transaction data; and, based on each of the unit prices corresponding to each of the transaction data, determine the target transaction data from the plurality of transaction data.

[0014] The encapsulation processing module is used to encapsulate the target transaction data to obtain a transaction block;

[0015] The verification execution module is used to verify the transaction block and execute the transaction task based on the transaction block when the transaction block is verified.

[0016] This application provides an electronic device, the electronic device comprising:

[0017] Memory is used to store executable instructions or computer programs.

[0018] The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the data processing method provided in the embodiments of this application.

[0019] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the data processing method provided in this application when executed by a processor.

[0020] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the data processing method provided in this application.

[0021] The embodiments of this application have the following beneficial effects:

[0022] In this embodiment, multiple transaction data are acquired, each corresponding to at least two virtual resources. A unit price for each virtual resource is determined for each transaction data. Since the unit price for each virtual resource is independent, it better reflects the current supply and demand relationship, enabling more accurate and reasonable charging for each virtual resource during transaction execution, thus improving the accuracy of transaction execution. Furthermore, when determining the target transaction data from multiple transaction data based on the unit price, an accurate unit price ensures the identification of the ideal quantity of target transaction data, thereby increasing the capacity of the transaction block and improving transaction execution efficiency. In addition, by verifying the transaction block and executing the transaction task based on the block upon successful verification, the security and reliability of transaction execution can be further improved. Therefore, this embodiment can improve the accuracy, security, and efficiency of transaction execution. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the architecture of the data processing system 100 provided in an embodiment of this application;

[0024] Figure 2This is a schematic diagram of the structure of the blockchain network 200 provided in the embodiments of this application;

[0025] Figure 3A This is a flowchart illustrating the data processing method provided in an embodiment of this application;

[0026] Figure 3B This is a schematic diagram of the process for determining the unit price provided in an embodiment of this application;

[0027] Figure 3C This is a flowchart illustrating the process of determining target transaction data provided in an embodiment of this application;

[0028] Figure 3D This is a schematic diagram of the process for determining transaction fees provided in an embodiment of this application;

[0029] Figure 3E This is a schematic diagram of the process for verifying transaction blocks provided in an embodiment of this application;

[0030] Figure 3F This is a schematic diagram of the process for executing transaction tasks provided in an embodiment of this application;

[0031] Figure 4 This is another schematic diagram of the data processing method provided in the embodiments of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0034] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0035] In this application embodiment, 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.

[0036] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0037] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0038] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0039] 1) Blockchain: A distributed database technology consisting of a series of blocks, each containing a set of transaction data and linked to the previous blockchain by a hash pointer, forming a chain structure.

[0040] 2) Packaging Node: The node responsible for collecting transaction data in the network and packaging it into a new block. It verifies the validity of the transaction data, organizes the transaction data into a block, and then adds the block to the blockchain through the consensus mechanism.

[0041] 3) Verification Nodes: Nodes that participate in the network consensus process, verify transactions, and package legitimate transactions into blocks, ensuring the legitimacy of transactions and the security of the network.

[0042] 4) Smart Contract: A self-executing contract that runs on a blockchain, whose terms are pre-defined in code. Once the pre-defined conditions are met, the smart contract will automatically execute the corresponding operation, such as asset transfer or data recording.

[0043] 5) Ethereum Virtual Machine (EVM): A virtual machine that runs on the Ethereum network to execute smart contracts, providing an isolated and deterministic environment for the execution of smart contracts.

[0044] 6) Transaction fee: also known as transaction cost. In the blockchain, when a client node needs to initiate a transaction and call the on-chain contract, it needs to pay a transaction fee to cover the costs incurred by the node in executing the transaction, including the consumption of node storage, computing power, and bandwidth.

[0045] 7) Gas Mechanism: A built-in economic model used to control and limit the computing resources required to perform operations on the blockchain (such as transactions, smart contract function calls, etc.). Each transaction, when executed, is actually translated into various instructions to be executed in the Ethereum Virtual Machine (EVM), including storage instructions and computation instructions. Each instruction is defined as consuming a certain amount of gas. The total gas consumed by all instructions is calculated, and then the unit gas price (GasPrice) is evaluated based on the current network congestion level. Gas multiplied by GasPrice gives the total gas amount, which is the transaction fee to be charged.

[0046] 8) State Root: The root node hash of the Merkle Patricia Trie represents a unique identifier for the state of all accounts on the blockchain and is used to store Ethereum's state data. Each account's stored data, balance, contract code, and contract-stored state variables are stored in the Merkle Patricia Trie as key-value pairs.

[0047] 9) Consensus mechanism: A set of protocols or rules used to reach an agreement among multiple participants in a blockchain network to determine which transactions will be added to the blockchain and to maintain the consistency of the network state.

[0048] In related technologies, mainstream blockchain systems, such as Ethereum and Binance Smart Chain, all use a Gas mechanism to charge transaction fees to client nodes. Gas is used to uniformly calculate the storage, computation, and bandwidth consumption of a node during transaction execution. Simultaneously, the unit price of each Gas, i.e., GasPrice, is evaluated based on network congestion levels. Finally, Gas multiplied by GasPrice yields the total Gas supply, which is the transaction fee to be charged. However, the current Gas mechanism merges storage, computation, and bandwidth into a single virtual resource, and the unit price of different resources is uniformly measured according to GasPrice, which presents the following problems:

[0049] 1. Inaccurate billing and metering: Network congestion is often caused by a surge in demand for a certain type of resource (such as computing) at different times. However, the current gas mechanism leads to a uniform increase in gas price, resulting in inflated charges for the other two types of resources (storage and bandwidth). Therefore, in related technologies, a surge in demand for one resource can lead to inaccurate metering and billing for the other two types of resources.

[0050] 2. Transaction blocks cannot accommodate the ideal number of transactions: A block has a limited capacity for consuming a certain type of Gas. The current fee collection mechanism is prone to causing a surge in demand for a particular resource, leading to an increase in the unit price of all resources. This results in an inflated total Gas value (Gas multiplied by GasPrice), causing the actual number of transactions packaged in a transaction block to be lower than the ideal number. This is because if the unit prices of the other two resource types remain unchanged due to the impact of the other resource's price, the calculated total Gas value will be smaller, allowing more transactions to be packaged in the transaction block.

[0051] This application provides a data processing method, apparatus, device, computer-readable storage medium, and computer program product, which can improve the accuracy and efficiency of transaction execution. The following describes exemplary applications of the electronic devices provided in this application. These devices can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and in-vehicle terminals, or as servers. Exemplary applications when the device is implemented as a server will be described below.

[0052] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the data processing system 100 provided in this application embodiment, including a blockchain network 200 (including packaging node 210-1 and verification node 210-2), a blockchain management platform 300 and a client node 400, which will be described below.

[0053] Client node 400 acquires multiple transaction data sets and determines the unit price of each virtual resource corresponding to each transaction data set. Then, it sends the transaction data and unit price to blockchain network 200 through blockchain management platform 300. Blockchain network 200 receives multiple transaction data sets and unit prices, and through packaging node 210-1, it determines the target transaction data from the multiple transaction data sets based on the unit price corresponding to each transaction data set. Then, packaging node 210-1 encapsulates the target transaction data to obtain a transaction block and propagates the transaction block to verification node 210-2. Verification node 210-2 verifies the transaction block, and then, when the transaction block is verified, the transaction task is executed based on the transaction block.

[0054] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the blockchain network 200 provided in the embodiments of this application. Figure 2 The illustrated blockchain network 200 includes at least one processor 210, a memory 230, and at least one network interface 220. The various components in server 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to implement communication between these components. In addition to a data bus, the bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 240.

[0055] The processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0056] The memory 230 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 230 may optionally include one or more storage devices physically located away from the processor 210.

[0057] The memory 230 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 230 described in this application embodiment is intended to include any suitable type of memory.

[0058] In some embodiments, memory 230 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0059] Operating system 231 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0060] The network communication module 232 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 including Bluetooth, WiFi, and Universal Serial Bus (USB).

[0061] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A data processing device 233 stored in memory 230 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: an acquisition module 2331, a determination module 2332, a packaging processing module 2333, and a verification execution module 2334. These modules are logically ordered and can therefore be arbitrarily combined or further divided according to the functions they implement. The functions of each module will be described below.

[0062] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the data processing method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0063] The data processing method provided in this application will be described in conjunction with exemplary applications and implementations of the server provided in the embodiments of this application.

[0064] The data processing method provided in the embodiments of this application will be described below. As mentioned above, the electronic device implementing the data processing method of the embodiments of this application can be a terminal, a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0065] It should be noted that the data processing examples below are based on transaction data. Those skilled in the art can apply the data processing methods provided in the embodiments of this application to the processing of other types of data based on their understanding of the following text.

[0066] See Figure 3A , Figure 3A This is a flowchart illustrating the data processing method provided in the embodiments of this application, which will be combined with... Figure 3A The steps shown are explained.

[0067] In step 101, multiple transaction data are acquired.

[0068] Here, transaction data refers to the data created and sent by client nodes to the blockchain network for transaction execution. Transaction data may include information such as transaction type (e.g., sending cryptocurrency, executing smart contracts, or other types of transactions), sender address, receiver address, and transaction amount. Taking the execution of a smart contract as an example, transaction data may include the client node's wallet address, the target smart contract address, the target smart contract's function call, and the specific values ​​of its function parameters. Each piece of transaction data corresponds to at least two types of virtual resources: computing resources, storage resources, and bandwidth resources. Computing resources refer to the processing power required to execute transactions and smart contract code within the network; storage resources refer to the space within the blockchain network used to store smart contract states and transaction data; and bandwidth resources refer to the network capacity required to transmit data within the blockchain network.

[0069] In step 102, for each transaction data, the unit price of each virtual resource corresponding to the transaction data is determined.

[0070] Here, unit price refers to the cost that a client node needs to pay for each unit of resource used, such as a unit of computing resource, a unit of storage resource, or a unit of bandwidth resource. Unit price is affected by factors such as the scarcity of virtual resources in the network, market supply and demand, technical costs, and the complexity of the service. In this embodiment, for each transaction data, the unit price corresponding to each virtual resource in the transaction data is set separately; therefore, the unit price of each virtual resource may be the same or different.

[0071] In some embodiments, see Figure 3B Step 102 can be implemented through steps 1021 to 1023, including:

[0072] In step 1021, for each virtual resource, the reference price corresponding to the virtual resource is obtained and output.

[0073] Here, the reference price refers to the basic unit price of virtual resources in the current network. It can be determined using a historical average method, that is, by averaging the basic unit price of the most recent few blocks. Alternatively, it can be determined using Ethereum's EIP-1559 algorithm. This involves obtaining the basic cost of the current virtual resource from the most recent block, calculating the network congestion coefficient, and using the congestion coefficient and the basic cost of the previous block to predict the basic cost of the next block. Simultaneously, a network fee (Gas Fee) is set based on the importance of the transaction and the client nodes' needs for transaction execution speed. The predicted basic cost and the set network fee are then added to obtain the reference price corresponding to the virtual resource. Alternatively, different algorithms can be flexibly selected to determine the reference price of virtual resources based on adjustments to network congestion and client node demands, thereby determining the optimal algorithm for each type of virtual resource. After obtaining the reference price of the virtual resource, it can be displayed on the terminal's interface, realizing the output of the reference price.

[0074] In step 1022, price setting information corresponding to the virtual resource is received.

[0075] Here, the price setting information is used to set the unit price corresponding to the virtual resource. When the reference price corresponding to the virtual resource is displayed on the terminal's display interface, the client node can input the price setting information in the terminal based on the reference price of the virtual resource and its own trading needs.

[0076] In step 1023, the unit price corresponding to the virtual resource is determined based on at least one of the price setting information and the reference price.

[0077] Here, the unit price is greater than or equal to the reference price, and the higher the unit price of the virtual resource, the more likely the corresponding transaction is to be executed first. The reference price can be directly set as the unit price of the virtual resource, or the unit price of the virtual resource can be determined solely based on the price setting information, or both the price setting information and the reference price can be used to determine the unit price of the virtual resource.

[0078] In this embodiment, for each virtual resource, a reference price corresponding to the virtual resource is obtained and output, and price setting information corresponding to the virtual resource is received. The unit price corresponding to the virtual resource is determined based on at least one of the price setting information and the reference price. In this way, client nodes can customize the unit price according to their own needs based on the output reference price, thereby flexibly adjusting the fees charged for each type of virtual resource and improving the flexibility and accuracy of transaction fees.

[0079] In some embodiments, when the price setting information is a price setting value, the price setting value is determined as the unit price corresponding to the virtual resource.

[0080] Here, the price setting value corresponds to the specific value of each virtual resource. For example, if the price setting information is "(computing resource) 20, (storage resource) 30", then the unit price corresponding to the computing resource is directly determined to be 20, and the unit price corresponding to the storage resource is 30.

[0081] Alternatively, when the price setting information is a multiplier setting value, the product of the multiplier setting value and the reference price is determined as the unit price corresponding to the virtual resource.

[0082] Here, the multiplier setting value corresponds to a multiple of each virtual resource. This multiplier is relative to the reference price, that is, the ratio between the unit price and the reference price. Since the unit price is greater than or equal to the reference price, the multiplier setting value must be greater than 1. For example, if the reference price is "Computing resource 10, Storage resource 10, Bandwidth resource 20", and the price setting information is "(Computing resource) 2, (Storage resource) 1.5, (Bandwidth resource) 1", then the unit price corresponding to the computing resource is determined to be 10 × 2 = 20, the unit price corresponding to the storage resource is 10 × 1.5 = 15, and the unit price corresponding to the bandwidth resource is 20 × 1 = 20.

[0083] In this way, when the price setting information is a set price value, the set price value is determined as the unit price corresponding to the virtual resource; when the price setting information is a multiplier setting value, the product of the multiplier setting value and the reference price is determined as the unit price corresponding to the virtual resource. Client nodes can flexibly adjust the unit price of each type of virtual resource according to the set price value or the multiplier setting value, enriching the ways to determine the unit price and improving the flexibility and accuracy of setting the unit price.

[0084] In step 103, the target transaction data is determined from multiple transaction data based on the unit price corresponding to each transaction data.

[0085] Here, the target transaction data refers to the multiple transaction data that need to be executed this time. This is because transaction data is usually stored in the local transaction storage, i.e., the transaction pool. The transaction pool contains multiple transaction data to be executed. It is often impossible to execute all the transaction data at once; instead, a batch of transaction data can only be packaged and published to the network each time. When packaging, the transaction data with higher average unit price has higher priority. Therefore, the target transaction data is the batch of transaction data with the higher average unit price among the multiple transaction data.

[0086] In some embodiments, see Figure 3C Step 102 can be implemented through steps 1031 to 1033, including:

[0087] In step 1031, for each transaction data, the average price corresponding to the transaction data is determined based on the price of each unit corresponding to the transaction data.

[0088] Here, based on the price of each unit of transaction data, the average of these unit prices is calculated, and the result is determined as the average price corresponding to the transaction data. For example, if the unit price of computing resources is 20, the unit price of storage resources is 10, and the unit price of bandwidth resources is 30, then the average price is 20 + 10 + 30 / 3 = 20.

[0089] In step 1032, based on the average price corresponding to each transaction data, the multiple transaction data are sorted in descending order to obtain the sorted transaction data.

[0090] Here, all transaction data are sorted according to the average price corresponding to each transaction. Descending order means that the transaction data with the highest average price will be placed at the beginning, and the transaction data with the lowest average price will be placed at the end. After the sorting operation is completed, a new sequence of transaction data will be obtained, namely the sorted transaction data, in which each transaction data is arranged from high to low according to its average price.

[0091] In step 1033, the target transaction data is determined from multiple transaction data based on the sorted transaction data.

[0092] Here, since each transaction in the sorted transaction data is arranged from high to low according to the average price, selecting transaction data sequentially from the sorted transaction data can ensure that the target transaction data is determined from multiple transaction data in order of average value from high to low.

[0093] In this embodiment, for each transaction data point, an average price is determined based on the unit price of that transaction data. Multiple transaction data points are then sorted in descending order based on their average prices to obtain sorted transaction data. Finally, the target transaction data is determined from among the multiple transaction data points based on the sorted transaction data. This descending sorting of the transaction data facilitates the identification of the target transaction data from multiple transaction data points according to their average value from highest to lowest, increasing the processing priority of transaction data with high average values ​​and thus improving the rationality of the transaction execution order.

[0094] In some embodiments, step 1033 may be implemented by the following process, including:

[0095] First, obtain the i-th transaction data and its transaction balance from the sorted transaction data, and determine the transaction fee for the i-th transaction data.

[0096] Here, i = 1, 2, ..., N, where N is the total number of transaction data. The transaction balance is the remaining funds of the client node corresponding to the transaction data, which is used to pay transaction fees. The transaction fee is the actual transaction fee required to execute this transaction data.

[0097] Then, when the i-th transaction data satisfies the transaction condition "the transaction balance is greater than the transaction fee, and the difference between the total transaction fee and the target fee is less than or equal to the first value", the i-th transaction data is determined as the target transaction data.

[0098] Here, a transaction balance greater than the transaction fee indicates that the client node's transaction balance can cover the transaction fee for this transaction, and the transaction can be executed normally. The total transaction fee is the sum of the current transaction fee and the transaction fee of the i-th transaction data. The current transaction fee is the sum of the transaction fees of the identified target transaction data. Since the target transaction data needs to be packaged into a block, and there is an upper limit to the number of target transaction data that a block can package, a target fee is set for the block. The target fee represents the maximum transaction fee that the block can bear. If the total transaction fee of the target transaction data included in the block exceeds the target fee, then the transactions in the block will not be executed normally. The first value can be 0, or it can be pre-set according to the size of the target fee, such as setting the first value to 100, 150, etc. If the difference between the total transaction fee and the target fee is less than or equal to the first value, it means that the total transaction fee has not yet exceeded the target fee, the block can accommodate this transaction data, and therefore this transaction data is identified as the target transaction data. When the difference between the total transaction fee and the target fee is greater than the first value, it means that the total transaction fee exceeds the target fee, and the block cannot accommodate this transaction data. Therefore, this transaction data cannot be identified as the target transaction data.

[0099] In this embodiment, the i-th transaction data and its transaction balance are obtained from the sorted transaction data, and the transaction fee of the i-th transaction data is determined. When the i-th transaction data meets the transaction condition that "the transaction balance is greater than the transaction fee, and the difference between the total transaction fee and the target fee is less than or equal to a first value", the i-th transaction data is determined as the target transaction data. This achieves the following: transaction data is retrieved in descending order of average price; when the transaction balance of a transaction data is sufficient to pay the transaction fee, the transaction data is determined as the target transaction data and packaged into a block; and when the sum of the transaction fees of all target transaction data approaches the target fee, and the block cannot accommodate more transaction data, all target transaction data required for this packaging is determined.

[0100] In some embodiments, see Figure 3D The transaction fee for the i-th transaction can be determined through steps 201 to 203, including:

[0101] In step 201, the consumption of each virtual resource corresponding to the i-th transaction data is determined.

[0102] Here, virtual resource consumption refers to the usage of virtual resources in a virtualized environment during transaction execution. For example, computing resource consumption refers to the amount of computing resources occupied and used in a computer system or network; storage resource consumption refers to the usage of storage resources and related resource consumption; bandwidth resource consumption refers to the amount of data transmitted through a network link per unit time during network transmission, usually measured in bits per second (bps) or bytes per second (Bps).

[0103] In some embodiments, virtual resources include computing resources, storage resources, and bandwidth resources. Therefore, determining the consumption of each virtual resource corresponding to the i-th transaction data includes the following process:

[0104] By executing the transaction task corresponding to the i-th transaction data in the virtual machine, the consumption of computing resources and storage resources is determined; the byte length and byte consumption of the i-th transaction data are determined, and the bandwidth resource consumption is determined based on the byte length and byte consumption.

[0105] Here, the virtual machine refers to the Ethereum Virtual Machine (EVM). The EVM simulates the execution of the transaction task corresponding to the i-th transaction data, thus predicting the computational and storage resource consumption required to execute this task. When determining the byte length, the length of each component of the transaction data is determined by parsing it, and then the lengths of each component are summed to form the total byte length of the transaction data. The byte consumption is pre-set, representing the bandwidth resource required for each byte. The bandwidth resource consumption is obtained by multiplying the byte length of the transaction data by the byte consumption. For example, if the byte length of the transaction data is 44 and the byte consumption is 2, then the bandwidth resource consumption is 44 × 2 = 88.

[0106] In this way, by executing the transaction task corresponding to the i-th transaction data through the virtual machine, the consumption of computing resources and storage resources is determined, the byte length and byte consumption of the i-th transaction data are determined, and the bandwidth resource consumption is determined based on the byte length and byte consumption, thereby improving the accuracy of determining the consumption of each virtual resource.

[0107] In step 202, for each virtual resource, the resource cost corresponding to the virtual resource is determined based on the consumption of the virtual resource and the unit price of the virtual resource.

[0108] Here, the resource cost is calculated by multiplying the consumption of each virtual resource by its unit price. For example, if the consumption of a computing resource is 40 and its unit price is 25, then the resource cost is 40 × 25 = 1000.

[0109] In step 203, the transaction fee is determined based on the cost of each resource.

[0110] Here, the costs of each resource are added together to obtain the transaction cost. For example, if the resource costs include 1200 for computing resources, 4000 for bandwidth resources, and 3300 for storage resources, then the transaction cost would be 1200 + 4000 + 3300 = 8500.

[0111] In this embodiment, the consumption of each virtual resource corresponding to the i-th transaction data is determined. For each virtual resource, the resource cost corresponding to the virtual resource is determined based on the consumption and unit price of the virtual resource. Based on the resource cost, the transaction cost is determined. In this way, determining the resource cost separately for different virtual resources avoids mutual interference between the resource costs of different virtual resources, improves the accuracy of determining the resource cost of each virtual resource, and thus improves the accuracy of determining the transaction cost.

[0112] In step 104, the target transaction data is encapsulated to obtain a transaction block.

[0113] Here, encapsulation refers to organizing all target transaction data into a single block, known as a transaction block, through packaging nodes. Transaction blocks can be added to the blockchain via a consensus mechanism, and each transaction block contains relevant data for all target transaction data.

[0114] In step 105, the transaction block is verified, and if the transaction block is verified, the transaction task is executed based on the transaction block.

[0115] Here, the transaction block is broadcast to the validating nodes through the nodes. The validating nodes verify the transaction block, such as verifying the block header, unit price, transaction validity, and block validity. If the verification passes, it means that the transaction block is legitimate and secure, and the transaction task can be executed through the transaction block.

[0116] In some embodiments, see Figure 3EThe "verification of transaction blocks" in step 105 can be achieved through steps 1051 to 1053, including:

[0117] In step 1051, the block height of the transaction block is determined.

[0118] Here, block height refers to the number of consecutive blocks on the blockchain, starting from the genesis block (the first block). Specifically, block height is a number representing the order of blocks on the blockchain. Starting with the genesis block, each block added to the blockchain is assigned an incrementing number, which is the block height. For example, if the block height of transaction blocks is 10578, it means that 10578 transaction blocks have been added to the main chain since the genesis block.

[0119] In step 1052, when the difference between the block height of the transaction block and the highest historical block height is a second value, for each target transaction data in the transaction block, the price of each unit corresponding to the target transaction data is obtained.

[0120] Here, the highest historical block height refers to the block height of the block preceding this transaction block, and the second value is set to 1. This is because block heights are continuous, and the difference between the block height of a newly added transaction block and the previous block is usually 1. Therefore, if the difference between the block height of a transaction block and the highest historical block height is 1, it indicates that the transaction block is valid. At this point, for each target transaction data in the transaction block, the unit price of each virtual resource corresponding to the target transaction data is obtained.

[0121] In step 1053, the transaction block is determined to be verified when the price of each unit is greater than or equal to the corresponding reference price.

[0122] Here, because client nodes may overlook and set unreasonable unit prices for each virtual resource, when verifying target transaction data, it is necessary to confirm the relationship between the unit price set for each virtual resource and its reference value. If the unit price for each virtual resource is greater than or equal to the corresponding reference price, the transaction block is considered verified; otherwise, the transaction block cannot be executed normally and will be skipped.

[0123] In this embodiment, the block height of the transaction block is determined. When the difference between the block height of the transaction block and the historical highest block height is a second value, for each target transaction data in the transaction block, the unit price corresponding to the target transaction data is obtained. If each unit price is greater than or equal to the corresponding reference price, the transaction block is deemed to have passed verification. Thus, by verifying the block height and unit price of the transaction block, normal transaction execution can be guaranteed, and the accuracy of determining transaction fees can be further improved.

[0124] In some embodiments, see Figure 3F The "execute transaction task based on transaction block" in step 105 can be achieved through steps 1151 and 1152, including:

[0125] In step 1151, for each target transaction data in the transaction block, the transaction balance corresponding to the target transaction data is updated based on the transaction fee corresponding to the target transaction data to obtain the updated transaction balance.

[0126] Here, for each target transaction data point, the corresponding transaction fee needs to be deducted from the transaction balance to update the transaction balance. For example, if the transaction balance of a target transaction data point is 50,000 and the corresponding transaction fee is 2,400, then the updated transaction balance is 50,000 - 2,400 = 47,600.

[0127] In step 1152, the account information in the world state of the blockchain is updated based on each updated transaction balance to obtain the updated world state.

[0128] Here, the world state of the blockchain is a collection of the current balances and states of all client node accounts in the blockchain network. It is a distributed database stored on every node in the network, reflecting the real-time state of all accounts and smart contracts on the blockchain. The account information in the world state includes the current transaction balances of all client nodes. Based on each updated transaction balance, the transaction balance of the corresponding client node in the account information is adjusted to the updated transaction balance, thus obtaining the updated world state.

[0129] In this embodiment of the application, for each target transaction data in the transaction block, the transaction balance corresponding to the target transaction data is updated based on the transaction fee corresponding to the target transaction data to obtain the updated transaction balance. Based on each updated transaction balance, the account information in the world state of the blockchain is updated to obtain the updated world state. This realizes the real-time updating of the transaction balance and the world state, ensuring the timeliness of the transaction balance and the world state.

[0130] In some embodiments, after a transaction is executed based on a transaction block, a first state root corresponding to the world state and a second state root corresponding to the transaction block can be determined. If the first state root and the second state root are different, the updated world state is modified to the world state before the update.

[0131] Here, the first state root is a hash value, representing a unique fingerprint of the state of all accounts on the blockchain at a specific moment (i.e., the world state). Whenever the state on the blockchain changes, such as after a series of transactions, a new first state root is generated. The second state root corresponding to a transaction block is usually stored in the header of the transaction block, recording the new state of the transaction block after the transaction is executed. Normally, the first state root corresponding to the world state and the second state root corresponding to the transaction block are the same. If the first and second state roots are different, it indicates that the transaction block may not have been executed according to the expected rules, or that the data in the transaction block has been corrupted during propagation. In this case, the world state needs to be rolled back to the previous block height, that is, the updated world state needs to be changed back to the world state before the update.

[0132] In this embodiment, after executing a transaction based on a transaction block, a first state root corresponding to the world state and a second state root corresponding to the transaction block are determined. If the first state root and the second state root are different, the updated world state is modified back to the world state before the update. In this way, the transaction block is further verified through the world state, improving the security and stability of transaction execution.

[0133] In this embodiment, multiple transaction data are acquired, each corresponding to at least two virtual resources. A unit price for each virtual resource is determined for each transaction data. Since the unit price for each virtual resource is independent, it better reflects the current supply and demand relationship of the virtual resource. This allows for more accurate and reasonable charging for each virtual resource during transaction execution, improving the accuracy of transaction execution. Furthermore, when determining the target transaction data from multiple transaction data based on the unit price, an accurate unit price ensures the identification of an ideal quantity of target transaction data, increasing the capacity of the transaction block and thus improving transaction execution efficiency. In addition, by verifying the transaction block and executing the transaction task based on the block upon successful verification, the security and reliability of transaction execution can be further improved. Therefore, this embodiment improves the accuracy, security, and efficiency of transaction execution.

[0134] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0135] The data processing method provided in this application is mainly applied to the scenario of determining transaction fees when executing transactions in a blockchain system. A blockchain system typically involves key components such as client nodes, packaging nodes, validating nodes, and smart contract virtual machines. The client node holds a pair of public and private keys and a corresponding Externally Owned Account (EOA) wallet address. The client node sends transaction data to nodes in the blockchain through signing, thereby invoking on-chain contracts and interacting with the blockchain. The packaging node is randomly selected at each block height to package transaction data and publish the transaction block; it is a full node, meaning a computer running in the blockchain network that stores a complete copy of the blockchain data. The validating node is selected at each block height to verify the transaction block and the legality of the transaction; it is also a full node. The smart contract virtual machine is the execution environment for transactions. During transaction execution, it can convert the high-level language code in the smart contract into instructions that the virtual machine can understand and execute. These instructions can be divided into two categories: computation instructions (e.g., ADD instructions) and storage instructions (e.g., SSTORE instructions). The following will combine... Figure 4 This explains the specific process of executing transactions in a blockchain system.

[0136] I. Transaction Packaging Technology Based on Multi-Dimensional Resource Pricing

[0137] 1. Client node 401 constructs and sends transaction data:

[0138] Client node 401 constructs the transaction data as shown in formula (1) and sends it to any node in the entire network:

[0139] TX =

[0140] (From,to,Calldata,GasLimit,GasPrice compute GasPrice storage GasPrice bandwidth ) (1);

[0142] Where From is the wallet address of client node 401, containing the transaction balance of client node 401, to is the target contract address, and Calldata is the target contract call function and the specific values ​​of the function parameters.

[0143] GasLimit is the maximum amount of Gas that a transaction can consume, i.e., the target fee.

[0144] The GasLimit needs to be estimated using the following method: The node is invoked, and transaction data is simulated and executed in the node's smart contract virtual machine (404) to obtain the Gas consumption corresponding to the computing and storage resources. compute+storage Next, the length (Length(TX)) of the transaction data (TX) is calculated locally. Assuming the blockchain system sets the bandwidth consumption per byte to Kgas / bytes, the bandwidth resource consumption (Gas) is then calculated as Gas. bandwidth = Length(TX)*K; Then, according to formula (2), GasLimit is obtained:

[0145] GasLimit>=Gas compute+storage +Gas bandwidth (2);

[0146] In addition, client node 401 needs to call the node to obtain the basic unit price (i.e., reference price) of the three types of resources, namely the reference unit price: BaseGasPrice. compute BaseGasPrice storage BaseGasPrice bandwidth .

[0147] The basic unit price can be obtained by averaging the most recent K historical blocks, or by referring to the current Ethereum EIP-1559 algorithm. Alternatively, the unit price for each resource type can be adjusted according to network congestion and client node 401 requirements. The algorithm can be flexible, thereby increasing the flexibility of price adjustments and finding the optimal basic unit price algorithm for each resource type.

[0148] Then, client node 401 selects the gas unit price (GasPrice) for each of the three resources based on its urgency level. compute GasPrice storage GasPrice bandwidth .

[0149] Finally, client node 401 uses its private key to sign and send the transaction data TX to a node, thereby broadcasting it to the network.

[0150] 2. Packaged transaction data:

[0151] At a certain block height H, a node will be randomly selected by the consensus protocol to be a packaging node 402. Packaging node 402 is responsible for packaging the transaction data in the mempool into a block and publishing the block to the network.

[0152] Packaging node 402 retrieves the average price of the three types of resources in the transaction from its local transaction storage, i.e., GasPrice. compute+GasPrice storage +GasPrice bandwidth ) / 3, retrieve transaction data from high to low, and ensure the balance Amount of the transaction From is 3. From (Transaction balance) can be used to pay transaction fees (transaction costs), as shown in formula (3):

[0153] Amount From >

[0154] GasLimit*Max(GasPrice compute GasPrice storage GasPrice bandwidth (3);

[0155] In addition, it will obtain the basic unit price of the three types of resources in the current block to ensure: GasPrice compute Greater than or equal to BaseGasPrice compute GasPrice storage Greater than BaseGasPrice storage ;

[0156] GasPrice bandwudth Greater than or equal to BaseGasPrice bandwidth .

[0157] 3. Determine the consumption of computing resources and storage resources:

[0158] The transaction data TX is placed into the smart contract virtual machine 404 for simulated execution. Essentially, the transaction data is broken down into multiple instructions that run within the smart contract virtual machine 404. These instructions primarily include computation instructions (e.g., ADD) and storage instructions (e.g., SSTORE). During execution, the smart contract virtual machine 404 can track the GasStoreage consumption of the storage instructions. used (Instructions involving reading and writing EVM virtual machine memory and EVM world state are considered storage instructions), and the consumption of these instructions is calculated using GasCompute. used (i.e., instructions that do not involve reading or writing status).

[0159] 4. Determine the bandwidth resource consumption:

[0160] The node calculates the length of the transaction data TX in bytes, Length(TX). Assuming that the transaction bandwidth consumption is calculated as K Gas per byte when the system starts, the Gas consumption of the transaction bandwidth is as shown in formula (4):

[0161] GasBandWidthused =Length(TX)*K(4).

[0162] 5. Calculate transaction fees for transaction data:

[0163] As shown in formula (5), the transaction fee (i.e., transaction cost) for a transaction can be calculated:

[0164] Tx fee =GasPrice compute *GasCompute used +GasPrice storage *

[0165] GasStoreage used +GasPrice bandwidth *GasBandWidth used (5);

[0166] Then, the transaction fee Tx is deducted from the transaction balance of the From address account on client node 401. fee The transaction is packaged into a transaction block. The transaction fee Tx for all target transaction data... fee When the accumulated amount approaches the block's GasLimit limit (i.e., the target fee), it means that the current transaction block cannot accommodate more target transaction data. At this point, the packaging node 402 can complete the packaging of the transaction data and publish the transaction block to the network for verification by the validator node 403.

[0167] II. Transaction Verification Technology Based on Multi-Dimensional Resource Pricing

[0168] In this embodiment of the application, in addition to performing routine verification of transaction blocks and transaction data, verification node 403 also needs to verify the correctness of the transaction fees charged. The specific verification process is as follows:

[0169] 1. Verifying node 403 accepts the transaction block and verifies the block header:

[0170] When verifier node 403 receives a new transaction block from the network, it checks whether the block height H is the latest local block height (i.e., the highest historical block height) plus one. If so, it includes the transaction block in the network and performs routine checks, such as data structure verification and transaction validity verification, and further verifies the unit price of virtual resources. If not, it rejects or skips the transaction block.

[0171] 2. Verify the unit price of virtual resources:

[0172] For each transaction in the transaction block, obtain the unit price of the three types of virtual resources set by client node 401: GasPrice. compute GasPrice storage GasPrice bandwidth Next, obtain the base price of the three resource types: BaseGasPrice. compute BaseGasPrice storage BaseGasPrice bandeidth Ensure: GasPrice compute Greater than or equal to BaseGasPrice compute GasPrice storage Greater than or equal to BaseGasPrice storage GasPrice bandwidth Greater than or equal to Ba eGasPrice bandwidth If any of the above three conditions is not met, the transaction data execution will fail and the transaction data will be skipped.

[0173] 3. Execution Transaction Data:

[0174] Verification node 403 places the transaction data into the smart contract virtual machine 404 for execution. After calculating the Gas consumed by the transaction data in terms of computing and storage resources, it calculates the byte length of the transaction data, calculates the Gas consumed by the transaction data in terms of bandwidth resources, and finally calculates the transaction fee of the transaction data. The transaction fee is deducted from the transaction balance, thereby updating the account's transaction balance and updating the world state.

[0175] After each transaction in the transaction block has been executed through the above steps, the first state root of the local world state tree is calculated and compared with the second state root in the block header. If they match, the current transaction block verification passes; if they do not match, the current transaction block verification fails, and the world state changed by the execution of the current transaction block needs to be rolled back to the previous block height.

[0176] This application proposes a transaction packaging technology based on multi-dimensional resource pricing. It changes the transaction fee collection mechanism from a single-resource unified pricing to multi-resource separate pricing, where the unit price of each resource can be adjusted independently. This allows the fee for each resource to better align with the current network supply and demand, resulting in more accurate transaction fee collection from client nodes and enabling transaction blocks to accommodate an ideal amount of transaction data. This application also proposes a transaction verification technology based on multi-dimensional resource pricing, enabling verification nodes across the network to reach a consensus on the collection of transaction fees under multi-resource pricing. This ensures that packaging nodes collect more accurate transaction fees from client nodes according to the expected multi-resource pricing rules, preventing packaging nodes from manipulating resource unit prices in fee collection.

[0177] The following description continues to illustrate the exemplary structure of the data processing device 233 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the data processing device 233 of the memory 230 may include:

[0178] Model 2331 is used to acquire multiple transaction data, each of which corresponds to at least two virtual resources.

[0179] The determining module 2332 is used to determine, for each of the transaction data, the unit price of each of the virtual resources corresponding to the transaction data; and to determine the target transaction data from the plurality of transaction data based on the unit price corresponding to each of the transaction data.

[0180] The encapsulation processing module 2333 is used to encapsulate the target transaction data to obtain a transaction block;

[0181] The verification execution module 2334 is used to verify the transaction block and execute the transaction task based on the transaction block when the transaction block is verified.

[0182] In some embodiments, the determining module 2332 is further configured to: acquire and output a reference price corresponding to each virtual resource; receive price setting information corresponding to the virtual resource; and determine a unit price corresponding to the virtual resource based on at least one of the price setting information and the reference price, wherein the unit price is greater than or equal to the reference price.

[0183] In some embodiments, the determining module 2332 is further configured to: when the price setting information is a price setting value, determine the price setting value as the unit price corresponding to the virtual resource; when the price setting information is a multiplier setting value, determine the product of the multiplier setting value and the reference price as the unit price corresponding to the virtual resource.

[0184] In some embodiments, the determining module 2332 is further configured to, for each transaction data, determine the average price corresponding to the transaction data based on each unit price corresponding to the transaction data; sort the plurality of transaction data in descending order based on the average price corresponding to each transaction data to obtain sorted transaction data; and determine the target transaction data from the plurality of transaction data based on the sorted transaction data.

[0185] In some embodiments, the determining module 2332 is further configured to obtain the i-th transaction data and the transaction balance of the i-th transaction data from the sorted transaction data, and determine the transaction fee of the i-th transaction data; wherein i = 1, 2, ..., N, and N is the total number of transaction data; when the i-th transaction data meets the following transaction conditions, the i-th transaction data is determined as the target transaction data: the transaction balance is greater than the transaction fee, and the difference between the total transaction fee and the target fee is less than or equal to a first value; wherein the total transaction fee is the sum of the current transaction fee and the transaction fee of the i-th transaction data, and the current transaction fee is the sum of the transaction fees of the determined target transaction data.

[0186] In some embodiments, the determining module 2332 is further configured to determine the consumption of each virtual resource corresponding to the i-th transaction data; for each virtual resource, determine the resource cost corresponding to the virtual resource based on the consumption of the virtual resource and the unit price of the virtual resource; and determine the transaction cost based on the resource cost of each virtual resource.

[0187] In some embodiments, the determining module 2332 is further configured to execute the transaction task corresponding to the i-th transaction data through a virtual machine, determine the consumption of the computing resources and the consumption of the storage resources; determine the byte length and byte consumption of the i-th transaction data, and determine the consumption of the bandwidth resources based on the byte length and the byte consumption.

[0188] In some embodiments, the verification execution module 2334 is further configured to determine the block height of the transaction block; when the difference between the block height of the transaction block and the historical highest block height is a second value, for each target transaction data in the transaction block, obtain each unit price corresponding to the target transaction data; when each unit price is greater than or equal to the corresponding reference price, determine that the transaction block has passed verification.

[0189] In some embodiments, the verification execution module 2334 is configured to, for each target transaction data in the transaction block, update the transaction balance corresponding to the target transaction data based on the transaction fee corresponding to the target transaction data to obtain an updated transaction balance; and update the account information in the world state of the blockchain based on each updated transaction balance to obtain an updated world state.

[0190] In some embodiments, the verification execution module 2334 is used to determine the first state root corresponding to the world state and the second state root corresponding to the transaction block; when the first state root and the second state root are different, the updated world state is modified to the world state before the update.

[0191] This application provides a computer program product, which includes a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the data processing method described in this application.

[0192] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the data processing method provided in this application. For example, ... Figure 3A The data processing method is shown.

[0193] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0194] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0195] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored in a portion of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0196] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0197] In summary, this application embodiment obtains multiple transaction data sets, each corresponding to at least two virtual resources, and determines a unit price for each virtual resource for each transaction data set. Since the unit price for each virtual resource is independent, it better reflects the current supply and demand relationship of the virtual resources, enabling more accurate and reasonable charging for each virtual resource during transaction execution, thus improving the accuracy of transaction execution. Furthermore, when determining the target transaction data from multiple transaction data sets based on the unit price, an accurate unit price ensures the determination of an ideal quantity of target transaction data, thereby increasing the capacity of the transaction block and improving the efficiency of transaction execution. In addition, by verifying the transaction block and executing the transaction task based on the transaction block upon successful verification, the security and reliability of transaction execution can be further improved. Therefore, this application embodiment can improve the accuracy, security, and efficiency of transaction execution.

[0198] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The method includes: Acquire multiple transaction data, each of which corresponds to at least two virtual resources; For each of the aforementioned transaction data, determine the unit price of each of the aforementioned virtual resources corresponding to the transaction data; Based on each unit price corresponding to each of the aforementioned transaction data, the target transaction data is determined from the plurality of transaction data; The target transaction data is encapsulated to obtain a transaction block; The transaction block is verified, and when the transaction block is verified, the transaction task is executed based on the transaction block.

2. The method according to claim 1, characterized in that, Determining the unit price of each virtual resource corresponding to the transaction data includes: For each of the aforementioned virtual resources, obtain and output the reference price corresponding to the virtual resource; Receive price setting information for the virtual resource; Based on at least one of the price setting information and the reference price, the unit price corresponding to the virtual resource is determined, wherein the unit price is greater than or equal to the reference price.

3. The method according to claim 2, characterized in that, Determining the unit price corresponding to the virtual resource based on at least one of the price setting information and the reference price includes: When the price setting information is a price setting value, the price setting value is determined as the unit price corresponding to the virtual resource; When the price setting information is a multiplier setting value, the product of the multiplier setting value and the reference price is determined as the unit price corresponding to the virtual resource.

4. The method according to claim 1, characterized in that, The step of determining the target transaction data from the plurality of transaction data based on each unit price corresponding to each of the transaction data includes: For each of the aforementioned transaction data, an average price corresponding to the transaction data is determined based on each unit price corresponding to the transaction data. Based on the average price corresponding to each of the transaction data, the multiple transaction data are sorted in descending order to obtain the sorted transaction data. Based on the sorted transaction data, the target transaction data is determined from the plurality of transaction data.

5. The method according to claim 4, characterized in that, The step of determining the target transaction data from the plurality of transaction data based on the sorted transaction data includes: Obtain the i-th transaction data and its transaction balance from the sorted transaction data, and determine the transaction fee of the i-th transaction data; where i = 1, 2, ..., N, and N is the total number of transaction data; The i-th transaction data is determined as the target transaction data when it meets the following transaction conditions: The transaction balance is greater than the transaction fee, and the difference between the total transaction fee and the target fee is less than or equal to a first value; wherein, the total transaction fee is the sum of the current transaction fee and the transaction fee of the i-th transaction data, and the current transaction fee is the sum of the transaction fees of the determined target transaction data.

6. The method according to claim 5, characterized in that, Determining the transaction fee corresponding to the i-th transaction data includes: Determine the consumption amount of each virtual resource corresponding to the i-th transaction data; For each virtual resource, the resource cost corresponding to the virtual resource is determined based on the consumption of the virtual resource and the unit price of the virtual resource. The transaction fee is determined based on the cost of each of the aforementioned resources.

7. The method according to claim 6, characterized in that, The virtual resources include: computing resources, storage resources, and bandwidth resources; Determining the consumption of each virtual resource corresponding to the i-th transaction data includes: The transaction task corresponding to the i-th transaction data is executed by a virtual machine to determine the consumption of computing resources and the consumption of storage resources. Determine the byte length and byte consumption corresponding to the i-th transaction data, and determine the bandwidth resource consumption based on the byte length and byte consumption.

8. The method according to any one of claims 1 to 7, characterized in that, The verification of the transaction block includes: Determine the block height of the transaction block; When the difference between the block height of the transaction block and the historical highest block height is a second value, for each target transaction data in the transaction block, obtain each unit price corresponding to the target transaction data; The transaction block is deemed to have passed verification when the unit price is greater than or equal to the corresponding reference price.

9. The method according to claim 1, characterized in that, The execution of transactions based on the transaction block includes: For each target transaction data in the transaction block, the transaction balance corresponding to the target transaction data is updated based on the transaction fee corresponding to the target transaction data to obtain the updated transaction balance; Based on the updated transaction balance for each transaction, the account information in the world state of the blockchain is updated to obtain the updated world state.

10. The method according to claim 9, characterized in that, After executing the transaction based on the transaction block, the method further includes: Determine the first state root corresponding to the world state and the second state root corresponding to the transaction block; When the first state root and the second state root are different, the updated world state is modified to the world state before the update.

11. A data processing apparatus, characterized in that, The device includes: A model is used to acquire multiple transaction data, each of which corresponds to at least two virtual resources. The determining module is configured to, for each of the transaction data, determine the unit price of each of the virtual resources corresponding to the transaction data; and, based on each of the unit prices corresponding to each of the transaction data, determine the target transaction data from the plurality of transaction data. The encapsulation processing module is used to encapsulate the target transaction data to obtain a transaction block; The verification execution module is used to verify the transaction block and execute the transaction task based on the transaction block when the transaction block is verified.

12. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method according to any one of claims 1 to 10.

13. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method described in any one of claims 1 to 10.

14. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, they implement the method according to any one of claims 1 to 10.

Images