Transaction resource consumption determination method, block chain system, medium, device and product

Abstract

The invention discloses a transaction resource consumption determination method, a block chain system, a medium, equipment and a product, and relates to the technical field of block chains, and the method comprises the steps that a first node executes a current transaction based on a target contract container corresponding to the current transaction, and obtains a transaction execution result; the first node obtains resource occupation data of the current transaction, wherein the resource occupation data is used for indicating the node resource quantity actually occupied by the target contract container for executing the current transaction; consumption calculation is carried out according to a node consumption coefficient of the first node and the resource occupation data of the current transaction, resource overhead index data of the current transaction is obtained, the node consumption coefficient is used for indicating a consumption calculation weight of the node, and the resource overhead index data is used for indicating energy consumed by execution operation of the current transaction; according to the method, the intelligent contract written by any programming language can be held, so that the flexibility and the expandability of the block chain platform are improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to methods for determining the consumption of transaction resources, blockchain systems, media, devices, and products. Background Technology

[0002] All transactions on a blockchain node are directly submitted to the blockchain for execution, and transaction fees are calculated based on the energy consumed by the transaction operation. The amount of the fee is closely related to the complexity of the transaction. Existing transaction consumption computation schemes typically embed computation instructions into code instructions, determining transaction costs based on preset opcode costs. This approach is only suitable for contracts on specific virtual machines, such as smart contract languages ​​designed for blockchains. It is not compatible with many commonly used languages, such as native Go and Java, reducing the versatility of the blockchain platform and its compatibility with existing enterprise applications. Furthermore, this method suffers from poor computational accuracy and low computational efficiency. Summary of the Invention

[0003] This application provides a method for determining the consumption of transaction resources, a blockchain system, a medium, equipment, and a product. The technical solution is as follows:

[0004] On the one hand, this application provides a method for determining the consumption of transaction resources, applied to a blockchain system, the method comprising:

[0005] The first node executes the current transaction based on the target contract container corresponding to the current transaction, and obtains the transaction execution result;

[0006] The first node obtains the resource usage data of the current transaction, and the resource usage data is used to indicate the amount of node resources actually used by the target contract container to execute the current transaction;

[0007] Consumption is calculated based on the node consumption coefficient of the first node and the resource usage data of the current transaction to obtain the resource expenditure index data of the current transaction. The node consumption coefficient is used to indicate the consumption calculation weight of the node, and the resource expenditure index data is used to indicate the energy consumed by the execution operation of the current transaction.

[0008] On the other hand, this application provides a blockchain system, which includes a first node.

[0009] The first node is used to execute the current transaction based on the target contract container corresponding to the current transaction, and obtain the transaction execution result; obtain the resource usage data of the current transaction, the resource usage data is used to indicate the amount of node resources actually used by the target contract container to execute the current transaction; and perform consumption calculation based on the node consumption coefficient of the first node and the resource usage data of the current transaction to obtain the resource expenditure index data of the current transaction, the node consumption coefficient is used to indicate the consumption calculation weight of the node, and the resource expenditure index data is used to indicate the energy consumed by the execution operation of the current transaction.

[0010] On the other hand, this application provides a computer-readable storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement the transaction resource consumption determination method as described above.

[0011] On the other hand, this application provides a computer device including a processor and a memory, wherein the memory stores at least one instruction or at least one program, the at least one instruction or at least one program being loaded and executed by the processor to implement the transaction resource consumption determination method as described above. The computer device includes a server and / or a terminal.

[0012] On the other hand, this application provides a computer program product, which includes computer instructions that, when executed by a processor, implement the transaction resource consumption determination method as described above.

[0013] The method, blockchain system, medium, equipment, and product for determining the consumption of transaction resources provided in this application have the following technical effects:

[0014] In the technical solution of this application, the blockchain node executes the current transaction through the target contract container and detects its resource consumption data during the execution of the current transaction. This data is used to indicate the amount of node resources occupied by the target contract container in executing the current transaction. It does not rely on a specific virtual machine and can support smart contracts written in any programming language, thereby improving the flexibility and scalability of the blockchain platform. Then, resource consumption index data is calculated based on the node consumption coefficient of the transaction execution node and the actual detected resource consumption data. Compared with the traditional fixed consumption calculation method that embeds calculation instructions, this application can combine the actual resource consumption of contract execution for consumption calculation, and the calculation results are real-time, accurate and efficient.

[0015] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram of a blockchain system provided in an embodiment of this application;

[0018] Figure 2 This is a schematic diagram of a block structure provided in an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of a system framework for a blockchain node provided in an embodiment of this application;

[0020] Figure 4 This is a flowchart illustrating a method for determining the consumption of transaction resources provided in an embodiment of this application;

[0021] Figure 5 This is a flowchart illustrating another method for determining the consumption of transaction resources provided in an embodiment of this application;

[0022] Figure 6 This is a flowchart illustrating another method for determining the consumption of transaction resources provided in an embodiment of this application;

[0023] Figure 7 This is a schematic diagram illustrating the calculation principle of resource usage data provided in an embodiment of this application;

[0024] Figure 8 This is a schematic diagram of a block data structure provided in an embodiment of this application;

[0025] Figure 9 This is a flowchart illustrating the process of determining resource consumption index data and transaction billing value according to an embodiment of this application;

[0026] Figure 10 This is a blockchain node network topology diagram based on a trusted execution environment provided in the embodiments of this application;

[0027] Figure 11 This is a schematic diagram of a node increment ratio calculation method for random transaction verification provided in an embodiment of this application;

[0028] Figure 12 This is an example diagram of a node cost coefficient correction based on the node increment ratio provided in an embodiment of this application;

[0029] Figure 13This is a schematic flowchart of a random transaction verification method provided in an embodiment of this application;

[0030] Figure 14 This is a schematic diagram of a periodic adjustment process for node cost coefficients based on node increment ratio provided in an embodiment of this application;

[0031] Figure 15 This is a schematic diagram of the hardware structure of a device for implementing a method for determining the consumption of transaction resources, provided in an embodiment of this application. Detailed Implementation

[0032] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises 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 devices.

[0034] To facilitate understanding of the technical solutions and their effects described in the embodiments of this application, the relevant technical terms are explained in the embodiments of this application:

[0035] Blockchain: A distributed ledger technology in the field of information technology. It generally consists of consensus, transaction blocks and state data storage, cryptographic identity security and other components. Because the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of being immutable, traceable and jointly maintained.

[0036] Smart contracts: A smart contract is a computer protocol designed to transmit, verify, or execute contracts in an informational manner. Smart contracts allow for trusted transactions without the need for a third party; these transactions are traceable, detectable, and irreversible.

[0037] Block Ledger: The block ledger is the core data structure in a blockchain system, used to store and manage all confirmed blocks. Organized in a chain-like structure, each block contains a set of transactions, a block header (including metadata such as the hash value and timestamp of the previous block), and other information. The block ledger provides a public, immutable history of transactions for the blockchain system, ensuring transparency and consistency.

[0038] State data: State data is a data structure used in a blockchain system to represent the current state of the system. State data includes the balances of all accounts, the state of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a given point in time. In blockchain systems, state data is typically stored in the form of a Merkle tree or other cryptographic data structures to ensure its integrity and security.

[0039] Transaction Pool: A transaction pool (also known as a mempool, memory pool, or transaction pool) is a data structure in a blockchain network used to store transactions that have not yet been packaged into blocks. When a user submits a new transaction to the blockchain network, the transaction first enters the transaction pool. When blockchain nodes are preparing to generate a new block, they select a certain number of transactions from the transaction pool to package. The transaction pool helps improve the processing capacity of the blockchain network and can also be used as a strategy to prioritize packaging transactions with higher transaction fees, thereby increasing the profitability of relevant entities.

[0040] It is understood that, in the specific embodiments of this application, the resource usage data, transaction-related request data, transaction-related status data, etc., involved need to obtain user permission or consent when the embodiments of this application are applied to specific products or technologies, and the collection, use and processing of related data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0041] The blockchain involved in this invention can be a distributed system formed by connecting clients and multiple nodes (any form of computing device in the network, such as servers and user terminals) through network communication.

[0042] Taking blockchain as an example of a distributed system, Figure 1This is an optional structural diagram of the distributed system 100 provided in this embodiment of the invention applied to a blockchain system. It consists of multiple nodes 200 (any form of computing device connected to the network, such as servers or user terminals) and clients 300. The nodes form a peer-to-peer (P2P) network, and the P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0043] See Figure 1 The functions of each node in the blockchain system shown include:

[0044] 1) Routing: A basic function of nodes used to support communication between nodes.

[0045] 2) Applications are deployed in the blockchain to implement specific business needs. They record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0046] For example, the business logic implemented by the application includes:

[0047] 2.1) A wallet is used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system; after other nodes successfully verify the transaction, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0048] 2.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain system. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0049] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's electronic money to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0050] 3) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks contain the data submitted by the nodes in the blockchain system.

[0051] User terminals include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, in-vehicle terminals, game consoles, e-book readers, multimedia playback devices, wearable devices, and other electronic devices. Application clients can be installed on user terminals.

[0052] In the embodiments of this application, the aforementioned applications include, but are not limited to, browser programs, financial applications, news applications, social applications, interactive entertainment applications, shopping applications, content sharing applications, virtual reality (VR) applications, augmented reality (AR) applications, etc., and the embodiments of this application do not limit them.

[0053] A server provides background services to clients of applications running on user terminals. For example, a server can be the backend server for the aforementioned applications. A server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Optionally, a server can simultaneously provide background services to applications running on multiple user terminals.

[0054] Optionally, the user terminal and the server can be connected directly or indirectly via wired or wireless communication, and this application does not impose any restrictions on this.

[0055] See Figure 2 , Figure 2This is an optional schematic diagram of the block structure provided in this embodiment of the invention. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through their hash values ​​to form a blockchain. Additionally, the block may include information such as a timestamp when it was generated. A blockchain is essentially a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0056] In some business scenarios, blockchain needs to charge users transaction fees, such as gas fees, when executing transactions. This involves transaction billing, and related technologies typically embed computational instructions into code instructions, determining transaction costs based on preset opcode costs. However, this approach has the following drawbacks: 1. Limited programming language support and environment adaptability: Traditional transaction billing schemes are often tightly coupled with specific blockchain virtual machines (such as Ethereum's EVM), primarily supporting specific smart contract languages ​​designed for blockchains (such as Solidity). This limits developers' language choices, making it difficult to directly deploy and execute smart contracts written in general programming languages ​​(such as Go and Java), thus limiting the versatility of the blockchain platform and its compatibility with existing enterprise applications; 2. Poor accuracy and low efficiency of gas billing: In traditional schemes, transaction billing is usually calculated based on preset opcode costs, which cannot accurately reflect actual resource consumption. For example, an operation may have different performance characteristics in different contexts or on different hardware. Furthermore, fixed pre-set code overhead costs fail to incentivize users to optimize their smart contract code, leading to inefficient resource utilization, network congestion, and unnecessary high fees. 3. Challenges to network security and performance consistency: Traditional transaction billing schemes collect fees directly after node billing, potentially causing inconsistencies in node execution or malicious behavior (such as double-spending attacks). Additionally, the standardized billing calculation code for each node in traditional schemes cannot be adapted to the actual performance of the nodes, nor can it create performance optimization incentives, thus affecting the consistency of node performance in the blockchain system.

[0057] To address at least one of the aforementioned problems, this application provides a scheme for determining the consumption of traded resources. The following is combined with... Figure 3 This application introduces a blockchain node of a blockchain system according to one embodiment. Figure 3 The system architecture of a blockchain node in a blockchain system is shown, including a network module, a verification module, a transaction pool module, a trusted execution environment, a consensus module, and a storage module.

[0058] The network module is responsible for communication between blockchains, including data transmission, transaction broadcasting, new block propagation, and block synchronization operations such as information exchange during the consensus process. It handles receiving and sending business requests (such as transaction requests), block data, and consensus information, ensuring effective communication and data synchronization between nodes. The verification submodule is responsible for verifying transactions and blocks, acting as a security defense for blockchain nodes. It ensures transactions comply with blockchain rules and constraints and includes a certificate verification submodule and an authorization verification submodule. The certificate verification submodule verifies the digital signatures of transactions and blocks, ensuring they originate from legitimate participants and have not been tampered with during transmission. The authorization verification submodule checks whether the transaction initiator has the authority to execute the transaction and whether the block producer has the authority to produce a block; for example, some transactions may only be initiated by accounts with specific roles.

[0059] Transaction pool module: Manages all transactions that have not yet been included in a block. When a user initiates a transaction, it is first placed in the transaction pool, waiting to be selected by nodes and included in a new block.

[0060] The scheduling module is responsible for managing transaction execution and block generation. It includes the following sub-modules:

[0061] Block generator: responsible for selecting transactions from the transaction pool, creating new blocks, and submitting them to the consensus module for verification and confirmation;

[0062] Trusted Execution Environment (TEE): Provides a secure environment for executing smart contracts and verifying transactions, ensuring the execution process is unaffected by external attacks and system vulnerabilities. For example, it can be built upon a TEE, a secure zone typically located within the main processor to protect the integrity and confidentiality of code and data. The TEE provides an isolated execution environment, preventing external attacks and software defects. In blockchain applications, TEEs can be used to securely execute smart contracts, ensuring transaction processing is unaffected by malware and that transaction data is not leaked. TEEs can also be used to protect critical blockchain operations, such as key management and signing processes, thereby enhancing the overall security of the system.

[0063] The trusted execution environment runs a container metric detection module, a transaction and container scheduling module, a contract engine, and a random transaction verification module. The container metric detection module monitors the resource usage of containerized smart contracts in real time, such as CPU, memory, and I / O. The transaction and container scheduling module allocates transactions to corresponding contract containers for execution. The resource usage calculation module calculates resource usage data during transaction execution based on data provided by the container metric detection module, which is used for subsequent resource cost metric calculations. The contract engine is the execution environment for smart contracts and can contain multiple contract containers. For example, contract containers are bound to smart contracts, and each contract container runs an independent smart contract instance. The random transaction verification module performs random transaction verification to ensure that the execution results of the master node are correct and consistent.

[0064] Consensus module: Responsible for reaching consensus among nodes in the network, verifying and confirming newly generated blocks. It uses specific consensus algorithms (such as PoW, PoS, PBFT, etc.) to ensure the security and decentralization of the blockchain.

[0065] The storage module is responsible for persistently storing blockchain data, including: a resource increase data table, which records the resource increase index data obtained by nodes after verifying and executing transactions. This resource increase index data can be used to dynamically adjust the node consumption coefficient; a state database, which stores the current state of the blockchain, including account balances, smart contract states, etc.; and a block ledger, which stores blocks that have been confirmed by the network, forming the historical record of the blockchain.

[0066] All of the above modules work together in a complete blockchain node, capable of processing transactions, executing smart contracts, and maintaining the state and security of the blockchain.

[0067] It should be noted that, Figure 3 The blockchain system shown is only one embodiment of this application. Blockchain nodes may include more or fewer modules to perform more or fewer data processing functions, and are not intended to... Figure 3 And the above description is limited.

[0068] The following describes a method for determining the consumption of transaction resources provided in this application, which is applied to a blockchain system. Figure 4This is a flowchart illustrating a method for determining the consumption of transaction resources according to an embodiment of this application. This application provides method operation steps as shown in the embodiments or flowcharts, but based on conventional or non-inventive methods, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or server product execution, the method can be executed sequentially according to the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Please refer to... Figure 4 The method for determining the consumption of transaction resources provided in this application embodiment may include the following steps S201-S205:

[0069] S201: The first node executes the current transaction based on the target contract container corresponding to the current transaction and obtains the transaction execution result.

[0070] Specifically, a blockchain system includes a first node, which is the master node that executes the current transaction. The blockchain system also includes multiple second nodes, which are slave nodes that participate in block consensus with the first node. Understandably, the master node of the blockchain is subject to rotation. During the execution of other transactions, the second node designated by the transaction or the one that completes the transaction first can take over as the master node, and the current first node becomes a slave node.

[0071] Specifically, the transaction pool of the first node stores pending transactions that have not yet been packaged into a block. When the first node is preparing to generate a new block, it will select a certain number of transactions from the transaction pool to package. The current transaction is the pending transaction that the first node in the transaction pool is currently scheduling and sending to the contract engine to trigger transaction execution.

[0072] Specifically, each node in the blockchain deploys multiple contract containers. A contract container is a standardized and encapsulated software container that provides an isolated environment for executing and storing transactions related to a smart contract. Contract containers are bound to smart contracts, and each container runs an independent smart contract instance. By configuring contract containers, the running status of the containers can be detected in real time, thereby determining the resource consumption data generated by transaction execution. This facilitates the determination of corresponding transaction consumption without embedding consumption calculation code into computer instructions, accurately measuring consumption while remaining compatible with different languages ​​and environments.

[0073] In some embodiments, S201 may include S2011-S2012:

[0074] S2011: Determine the target contract container corresponding to the smart contract of the current transaction based on the preset correspondence;

[0075] S2012: Execute the current transaction in the target contract container and obtain the transaction execution result.

[0076] Specifically, the pre-defined mapping relationships include mappings between multiple smart contracts and multiple contract containers. Each node in the blockchain stores these pre-defined mapping relationships so that, when a block is packaged, it can retrieve the smart contract of the current transaction and send the current transaction to the target contract container corresponding to its smart contract. The transaction is then executed within the isolated environment of the target contract container based on the smart contract instance, yielding the transaction execution result, which is then stored in the block to be packaged. In this way, by executing transactions through contract containers bound to contracts, isolated execution of transactions from different smart contracts is achieved, avoiding data interference and facilitating data consensus and ensuring the accuracy of subsequent verification of transaction resource consumption.

[0077] S203: The first node obtains the resource usage data of the current transaction.

[0078] Specifically, resource usage data is used to indicate the amount of node resources actually used by the target contract container to execute the current transaction, that is, to measure the system resources consumed during the execution of a smart contract transaction. Resource usage data may include sub-usage data corresponding to at least one computing resource. The at least one computing resource may include, but is not limited to, CPU time, memory resources, and I / O (input / output) operation resources, and correspondingly, the at least one sub-usage data may include, but is not limited to, CPU usage data, memory usage data, and I / O usage data.

[0079] In some embodiments, S203 may include S2031-S2032:

[0080] S2031: Based on the container indicator detection process, monitor the dynamic resource consumption of the target contract container during the execution period of the current transaction;

[0081] S2032: Perform resource cost statistics on the dynamic resource usage corresponding to the execution period to obtain the resource usage data of the current transaction.

[0082] Specifically, the container metric detection process is the functional process corresponding to the container metric detection module. The execution period of the current transaction refers to the period from when the current transaction is sent to the target contract container to when the transaction execution is completed. The dynamic resource usage of the target contract container includes the amount of runtime resources detected by the container metric detection process at each data collection moment during this execution period. The numerical representation of this runtime resource usage can be set based on actual needs, such as a resource utilization rate. For example, refer to... Figure 7The system records the start timestamp from when the current transaction is sent to contract container 2 until the end timestamp is recorded when the transaction is completed. The time period between the start timestamp and the end timestamp is the execution period. The system detects the dynamic resource usage data during this execution period, specifically including the CPU usage, memory usage, and I / O usage corresponding to each data collection moment.

[0083] Specifically, the resource consumption statistics for dynamic resource usage refer to the statistical analysis of the actual operating resources consumed by the current transaction at each data collection time, obtaining a summary of the resource consumption at each data collection time, and thus obtaining the resource consumption data for the current transaction. This data characterizes the amount of resources occupied by the target contract container during the execution of the current transaction. In some embodiments, the resource consumption statistics can be calculated using an integral operation, specifically the integral of the actual consumed operating resources over time. Correspondingly, the resource consumption data is equivalent to the resource consumption integral, which is a quantitative indicator used to measure the system resources consumed during the execution of a smart contract. The integral value reflects the actual system resource consumption of the contract execution. In this way, by using the container indicator detection process to detect the dynamic resource consumption in real time during the transaction execution process and performing resource consumption statistics for actual resource consumption, the accuracy of the actual resource consumption statistics is ensured, thereby improving the accuracy of subsequent resource consumption indicator data.

[0084] When the detected operating resources include multiple items, the dynamic resource usage includes the actual operating resource consumption of each of the multiple operating resources currently being used by the exchange. Resource consumption statistics are performed for each operating resource, and the operating resource quantity during the execution period is accumulated to obtain the corresponding sub-usage data. For example, the dynamic resource usage includes CPU utilization, memory utilization, and I / O utilization. Each item is integrated over time, and the resulting resource usage data includes CPU sub-usage data, memory sub-usage data, and I / O sub-usage data.

[0085] Resource usage data can be used to calculate resource consumption metrics for transactions in blockchain systems, thereby enabling transaction billing based on actual resource consumption rather than on estimates or fixed rates. This ensures that users pay accurate fees for the resources consumed in their transactions and helps create a fairer and more transparent billing model.

[0086] Understandably, the detected dynamic resource usage includes both the resources consumed by running the target contract container itself and the resources consumed by executing the current exchange. To accurately calculate resource usage data, in some embodiments, S2032 may include:

[0087] 1) Integrate the dynamic resource usage corresponding to the execution period to obtain the total resource usage data;

[0088] 2) Obtain the basic usage data corresponding to the current transaction;

[0089] 3) The difference between the total resource usage data and the resource usage data is determined as the resource usage data for the current transaction.

[0090] Specifically, the total resource usage data indicates the total amount of node resources occupied by the target contract container during the execution period of the current transaction, including the resource usage data required to run the contract container and the resource usage data consumed to execute the current transaction. As mentioned above, the dynamic resource usage includes the resource usage of the contract container itself and the resource usage of executing the transaction. Accordingly, the dynamic resource usage is integrated over time to obtain the total resource usage data, and then the basic usage data is removed to obtain the resource usage data of the current transaction. The basic usage data indicates the amount of node resources occupied by the target contract container in an idle state during the corresponding duration of the execution period, i.e., the amount of node resources consumed to run the target contract container itself. For example, refer to... Figure 7 In the curve segment corresponding to the execution period of the current transaction in the graph, the filled part is the basic resource usage data, and the blank part is the resource usage data. The sum of the two is the total resource usage data. In this way, by detecting the changes in the indicators of each running resource after the target contract container executes the current transaction, the dynamic resource usage is obtained, and the increment of the usage data compared with the container's idle state is calculated to obtain accurate transaction resource usage data.

[0091] S205: Calculate the consumption based on the node consumption coefficient of the first node and the resource usage data of the current transaction to obtain the resource consumption index data of the current transaction.

[0092] Specifically, the node consumption coefficient indicates the computational weight of a node; a higher computational weight results in a larger node consumption coefficient, and vice versa. The resource cost index indicates the energy consumed in executing the current transaction; a larger resource cost index indicates higher energy consumption, and vice versa. Resource cost index data can be used for transaction billing calculations to obtain the transaction billing value.

[0093] Specifically, there is a positive correlation between the node consumption coefficient and the resource consumption index data, and a positive correlation between the resource usage data and the node consumption coefficient. That is, the higher the node consumption coefficient and the resource usage data, the higher the resource consumption index data, which indicates that the current transaction consumes more resources and the transaction billing value is larger. Conversely, the lower the resource consumption index data, the lower the transaction billing value.

[0094] In some embodiments, resource consumption metrics can characterize the total Gas cost of a transaction. Gas is a unit of energy measurement in the smart contract platform of a blockchain system, used to measure the energy required to execute an operation or a series of operations (such as the execution of a smart contract transaction), representing the computational workload required. In one example, an addition operation consumes 3 Gas, while a storage operation consumes 200 Gas; the total Gas cost is the amount of Gas consumed to execute the transaction. In some scenarios, users or nodes specify a Gas limit and a Gas price when sending a transaction. The Gas limit is the maximum Gas a user is willing to pay to execute the transaction, while the Gas price is the fee a user is willing to pay per unit of Gas. The total transaction billing value is the total Gas cost multiplied by the Gas price. The Gas mechanism helps prevent network abuse and provides incentives for relevant parties to execute transactions.

[0095] In summary, the technical solution of this application involves a blockchain node executing the current transaction through a target contract container and detecting its resource consumption data during the execution of the current transaction. This data is used to indicate the amount of node resources occupied by the target contract container in executing the current transaction. This solution does not rely on a specific virtual machine and can support smart contracts written in any programming language, thereby improving the flexibility and scalability of the blockchain platform. Then, resource consumption index data is calculated based on the node consumption coefficient of the transaction execution node and the actual detected resource consumption data. Compared with the traditional fixed consumption calculation method that embeds calculation instructions, this application can combine the actual resource consumption of contract execution for consumption calculation, resulting in real-time, accurate, and highly efficient calculation results.

[0096] Based on some or all of the above implementation methods, the resource occupancy data includes sub-occupancy data corresponding to at least one computing resource, which may include the aforementioned CPU, I / O operations, or memory, etc. Accordingly, in some embodiments, the resource occupancy data is calculated based on the amount of running resources corresponding to a computing resource, such as by integrating the CPU occupancy rate.

[0097] In other embodiments, the resource usage data includes sub-usage data corresponding to two or more computing resources. For example, at least one computing resource may include, but is not limited to, CPU time, memory resources, and I / O operation resources. Correspondingly, at least one sub-usage data may include, but is not limited to, CPU usage data, memory usage data, and I / O usage data. S205 may include S2051-S2052:

[0098] S2051: If the resource occupancy data includes two or more sub-occupancy data, the sub-occupancy data shall be weighted and merged to obtain the basic expenditure index data.

[0099] S2052: Based on the node consumption coefficient of the first node, the basic overhead index data is corrected to obtain the resource overhead index data corresponding to the current transaction.

[0100] Specifically, weighted fusion can refer to, but is not limited to, weighted summation, weighted averaging, or weighted mean square calculation, to accumulate and fuse various sub-occupancy data according to the weights corresponding to each operating resource, thereby obtaining basic overhead index data. Each node can set the same weighted fusion weight coefficient for each computing resource, meaning that for the same set of resource occupancy data, the basic overhead index data calculated by each node is consistent. For example, the basic overhead index data can be the basic Gas value, where CPU occupancy data, memory occupancy data, and I / O occupancy data are the CPU occupancy integral, memory occupancy integral, and I / O occupancy integral calculated based on the occupancy rate, respectively. The basic Gas value = CPU coefficient * CPU occupancy integral + Memory coefficient * Memory occupancy integral + I / O coefficient * I / O occupancy integral; where the CPU coefficient, memory coefficient, and I / O coefficient are the weighted fusion weights of CPU time, memory resources, and I / O operation resources, respectively.

[0101] Specifically, the consumption coefficients of different nodes can be the same or different, and these coefficients can be adjusted according to the transaction execution status. The node consumption coefficient is positively correlated with resource consumption metrics, and the basic cost metrics are also positively correlated with resource consumption metrics. In one embodiment, the resource cost metrics are the product of the node consumption coefficient and the basic cost metrics. The node consumption coefficient is related to the node's system performance.

[0102] In this way, by detecting and weighting the consumption of multiple runtime resources, the information expression dimension and accuracy of resource consumption indicators are improved. Then, resource consumption is corrected and nodes are adapted through the consumption coefficients corresponding to the nodes themselves. This allows billing to be adjusted according to the actual performance of the nodes, which helps to incentivize nodes to optimize performance and maintain the overall stability of the network.

[0103] In some embodiments, after S205, the method further includes storing the transaction execution results, resource usage data, and resource cost index data of each executed transaction into a block. Further, basic cost index data, etc., can also be stored into the block. Understandably, the block structure can also store other relevant transaction data. For example, refer to... Figure 8 A block can include structural information such as block height, block hash information, previous block hash information, block timestamp, block producer signature, and total resource consumption data of the block. It can also include a list of block transactions, including but not limited to the trusted execution environment signature, as well as the contract name, contract method, transaction parameters, transaction execution result, CPU usage points, memory usage points, I / O usage points, and resource consumption data of each transaction.

[0104] In some embodiments, the contract container, the container metric detection process corresponding to the contract container, and the resource consumption metric data calculation process all run in an isolated and encrypted trusted execution environment. That is, transaction execution, resource consumption data detection and calculation, and resource consumption metric data calculation are all executed in isolation in this trusted execution environment, which protects the integrity and confidentiality of transaction data, improves the data security and reliability of dynamic resource consumption detection, and thus improves the efficiency and fairness of the entire transaction billing process.

[0105] In one specific embodiment, the Trusted Execution Environment (TEE) is built upon a TEE, a secure zone typically located within the main processor to protect the integrity and confidentiality of code and data. The TEE provides an isolated execution environment, preventing external attacks and software defects. In blockchain system applications, the TEE can securely execute smart contracts, ensuring transaction processing is unaffected by malware and that transaction data is not leaked. It can also be used to protect critical blockchain operations, such as key management and signing processes, thereby enhancing the overall system security.

[0106] In one embodiment, reference Figure 9 The process of determining resource cost metrics and transaction billing values ​​may include S1-S26:

[0107] S1. Begin;

[0108] S2. The user packages and encapsulates information such as the contract name, function name, parameters, and normal transaction identifier to be called;

[0109] S3. The user signs the packaged contents of S1;

[0110] S4. The user sends the packaged content of S1 and the request generated corresponding to the signature to the blockchain node;

[0111] S5. The network module of the blockchain master node receives the request from S4;

[0112] S6. The certificate verification submodule of the blockchain master node verifies the certificate and signature of the request from S4. Does the verification pass? If yes, proceed to S8; otherwise, proceed to S7.

[0113] S7. Return the result that the signature verification failed, and go to S26;

[0114] S8. The authentication submodule verifies the permissions of the request from S4. Does the verification pass? If yes, proceed to S10; otherwise, proceed to S9.

[0115] S9. Return the result of permission verification failure and proceed to S26;

[0116] S10. The block generator of the scheduling module obtains transactions from the transaction pool, triggers transaction execution, and packages them into a new block;

[0117] S11. The scheduling module sends the new block to the TEE trusted execution environment for transaction scheduling and execution;

[0118] S12.TEE Trusted Execution Environment's transaction and container scheduling module schedules transactions in new blocks and matches them with target contract containers in the contract engine;

[0119] S13. The transaction and container scheduling module traverses the transactions of the new block and sends the transactions to the contract processes of the corresponding target contract containers for execution in turn;

[0120] S14. When the current transaction is sent to the target contract container, the resource usage calculation module records the timestamp of the sending.

[0121] S15. The target contract container in the contract engine begins executing the transaction;

[0122] S16. The container indicator detection module detects the status of the container throughout the entire transaction execution process, and obtains the CPU utilization, memory utilization, and I / O utilization.

[0123] S17. After the contract engine completes the transaction, it sends the transaction execution result back to the transaction and container scheduling module;

[0124] S18. The resource usage calculation module stops recording the timestamp of this transaction;

[0125] S19. The resource usage calculation module calculates the total CPU usage, total memory usage, and total I / O usage during the execution period of the transaction;

[0126] S20. The resource usage calculation module subtracts the base usage points from each of the above total usage points to obtain the actual CPU usage points, memory usage points, and I / O usage points of the transaction.

[0127] S21. The resource consumption calculation module calculates the basic gas value of the transaction and, in combination with the node consumption coefficient, calculates the total gas amount and the transaction gas billing value.

[0128] S22. Have all transactions in the new block been executed? If yes, proceed to S23; otherwise, proceed to S13.

[0129] After S23.TEE has completed the execution of all transactions in the new block, it signs the transaction and returns it to the scheduling module.

[0130] S24. The block generator of the scheduling module collects all transaction execution results and signatures and assembles them into blocks;

[0131] S25. The consensus module sends the new block to the blockchain slave nodes for consensus.

[0132] S26. End.

[0133] In summary, the process of determining the aforementioned resource consumption metrics and transaction billing values ​​provides a blockchain Gas billing model based on dynamic resource consumption points using containerized contracts. This model standardizes and encapsulates the smart contract execution environment within a container, enabling the monitoring of metrics such as CPU, memory, and IO during smart contract execution. These metrics are then converted into dynamic resource consumption points, which measure the system resources used by the transaction based on changes in these points during the transaction execution period. This allows for the accurate calculation of the base Gas value, the corresponding total Gas amount, and the transaction Gas billing value. The model offers cross-language compatibility and precise measurement of resource usage, thereby improving the transparency and fairness of Gas consumption calculation. Furthermore, execution via a TEE container prevents node transaction and billing fraud.

[0134] Based on some or all of the above embodiments, in the embodiments of this application, reference is made to Figure 5 Following S201, the method also includes S301-S311:

[0135] S301: In response to the block consensus event triggered by the first node, each second node in the blockchain system receives the block to be consensused.

[0136] Specifically, the block awaiting consensus includes the transaction execution results and resource usage data of multiple transactions executed by the first node, including the current transaction. The block consensus event is triggered after the first node executes transactions in batches and generates a new block. The first node then initiates the consensus process for the block awaiting consensus to the other second nodes (slave nodes).

[0137] S303: Each second node randomly selects at least one target transaction from the block to be reached for consensus, and executes the target transaction again to obtain the reference execution result for each target transaction.

[0138] Specifically, after receiving the block awaiting consensus, at least some of the second nodes randomly select one or more transactions as target transactions, and then execute the target transactions again for random transaction verification. The execution result is the result obtained during the re-execution of the random transaction verification. Before consensus is reached on the block awaiting consensus, the random transaction verification operation is performed on it. Understandably, the process and method of the second node re-executing the target transaction are similar to the method and process of the first node executing the current transaction, as detailed in S201 above.

[0139] S305: If the reference execution result matches the corresponding transaction execution result in the block to be reached for consensus, the second node obtains the reference occupancy data corresponding to the target transaction.

[0140] Specifically, if the reference execution result does not match the corresponding transaction execution result in the block awaiting consensus, the verification is deemed to have failed, and the first node is prompted that there is an error in executing the target transaction. If they match, the reference resource usage data of the target transaction is obtained. This reference resource usage data is used to indicate the amount of node resources actually used by the contract container corresponding to the target transaction in the second node that executes the target transaction again. That is, the resource usage data generated by executing the target transaction again. The method of obtaining this reference resource usage data is the same as that of obtaining the resource usage data of the current transaction mentioned above, and will not be elaborated here.

[0141] Random transaction verification is a security mechanism established in this application to check whether nodes in the blockchain network have correctly executed transactions. In this process, nodes randomly select some transactions executed by other nodes and re-execute the transactions of the block awaiting consensus on different nodes. Then, by comparing the results of the two executions and the resource consumption, it is ensured that the node has executed the transaction correctly and without any fraudulent consumption. If a node's transaction execution result is found to be inconsistent with the expected reference result, the system can take appropriate measures against that node, such as lowering its reputation or reducing its rewards.

[0142] In one embodiment, the new block generated by the blockchain master node includes a TEE (Trusted Execution Environment) signature. Other slave nodes verify this TEE signature to trigger subsequent random transaction verification, thereby verifying the execution result and resource consumption. For example, refer to... Figure 10 The master node sends the block to be agreed upon to slave nodes 1-3 so that each slave node can perform trusted execution environment signature verification and random transaction verification.

[0143] S307: Each second node determines the resource increase indicator data based on the reference occupancy data and the resource occupancy data of the target transaction.

[0144] Specifically, the resource increase index data is used to indicate the increase in resource consumption of the second node executing the target transaction again relative to the resource consumption generated by the first node executing the target transaction. In some embodiments, the resource increase index data specifically indicates the increase in the basic overhead index data corresponding to the reference occupied data and the basic overhead index data corresponding to the resource occupied data. The basic overhead index data corresponding to the reference occupied data is obtained in the same way as the basic overhead index data in S2051 above, and will not be repeated here. Understandably, this increase can be positive or negative. The resource increase index data is a metric used to measure the difference in baseline performance between the two nodes when executing the transaction. It is calculated by comparing the resource consumption (such as the basic Gas value) of the nodes executing the same transaction. In other words, the resource increase index data is a metric used to measure the difference in baseline performance between the two nodes when executing the transaction. It is calculated by comparing the resource consumption (such as the basic Gas value) of the nodes executing the same transaction. In some cases, the resource increase index data is represented by a transaction increase ratio, which is the percentage increase in the basic overhead index data corresponding to the reference occupied data relative to the basic overhead index data corresponding to the resource occupied data.

[0145] In other embodiments, the resource increase index data specifically indicates the increase in the basic cost index data corresponding to the reference occupancy data and the average cost index data. The average cost index data is a preset value determined based on the performance of standard nodes, which can be the median performance standard of nodes. When the transaction increase ratio is used as the representation, the transaction increase ratio refers to the percentage increase in the basic cost index data corresponding to the reference occupancy data relative to the average cost index data, relative to the average cost index data.

[0146] S309: Each second node stores the extracted resource increase index data of each target transaction to the local resource increase data table.

[0147] Specifically, each node sets up a resource increase data table to store the resource increase index data of each target transaction that the node re-executes based on random transaction verification. These target transactions come from multiple other nodes outside the current node and are randomly selected from the consensus blocks sent by other nodes. This resource increase data table includes the correspondence between transactions, the node identifier that initially executed the transaction, and the resource increase index data. The node that initially executed the transaction refers to the node that initiated the consensus process for the consensus block containing that transaction. Based on this table, the corresponding transaction identifier information and resource increase index data for the same node can be found. In some cases, the resource increase data table stores the transaction increase ratio of the target transaction. If the basic resource index data obtained from transaction verification is higher than the original basic resource index data, the transaction increase ratio is positive; otherwise, it is negative.

[0148] S311: Each second node generates a node increase data table based on its own resource increase data table.

[0149] Specifically, the node growth data table includes node growth index data for multiple other nodes. This node growth index data indicates the increase in resource consumption of the current node relative to other nodes. Each node generates its own node growth data table based on its locally stored resource growth data table. The growth index data for each other node in the node growth data table is calculated by averaging the resource growth index data for each target transaction corresponding to that other node in the local resource growth data table. This data represents the increase in resource consumption of the current node relative to that other node when performing the same transaction, or it represents the increase in resource consumption of the current node relative to a standard node when performing the same transaction. The node growth index data can be a node growth ratio.

[0150] In this way, nodes randomly select transactions from blocks and verify the transactions in blocks awaiting consensus through a random transaction verification mechanism. By comparing the execution results of the same transaction on different nodes, malicious behavior of nodes is detected, ensuring that nodes execute transactions correctly and without cheating. The increase in resource consumption for verified transactions is calculated to obtain the node's resource increase index data. Finally, the node's increase index data is calculated by combining all resource increase index data within a period to detect whether there are any performance problems with the nodes and to obtain a node increase data table. This serves as the data basis for users to select nodes or as the basis for influencing node block production rewards, playing a role in incentivizing node performance, promoting the optimization and consistency of node performance in the system, and enhancing the overall stability of the network.

[0151] Based on the settings of the node growth data table, in some embodiments, the method further includes S401-S405:

[0152] S401: In response to a periodically triggered increase data sharing event, each node in the blockchain system shares its own node increase data table. Each node in the blockchain system includes the first node and each second node.

[0153] S403: Each node in each node updates its node coefficients based on the shared node increase data table, resulting in an updated node coefficient table.

[0154] S405: Each node reaches a consensus on the updated node coefficient table and stores the updated node coefficient table that has passed the consensus.

[0155] Specifically, the system periodically triggers an increase data sharing event. This period can be determined based on the number of proposed blocks, such as triggering an increase data sharing event after consensus on n blocks, where n could be, for example, 10 blocks. Each node shares its node increase data table with other nodes, allowing each node to merge the data from its various node increase data tables to generate a target data table. Then, based on the target data table, the node coefficients are updated to obtain an updated node coefficient table. The node coefficient table includes each node's individual node consumption coefficients, and the updated node coefficient table refers to the coefficient table obtained after updating the previous version of the node data table according to the target data table. Under normal circumstances, each node receives a node coefficient table, and the data in the updated node coefficient tables obtained by each node should be consistent. That is, during the consensus process, the updated table data can be compared. If all nodes check for consistency, the consensus passes, and the subsequent calculation of resource consumption indicators must be based on the updated node cost coefficients. If inconsistent table data is found, the consensus fails, and the previous version of the node coefficient table is retained. In existing solutions, the cost calculation parameters for nodes are fixed and lack a dynamic adjustment mechanism. This makes it impossible to adjust the cost coefficient based on the actual performance of the nodes, which may lead to inconsistent network performance and affect system stability and user experience. In contrast, the above solution dynamically adjusts the cost coefficient of each node based on the node growth data table. This allows for adjustments to the cost calculation and billing based on the actual performance of the nodes, ensuring the fairness and reasonableness of transaction billing in the network. This helps incentivize nodes to optimize performance and maintain the overall stability of the network, thereby enhancing the security and anti-attack capabilities of the blockchain network.

[0156] In some embodiments, reference is made to Figure 6 S403 includes S4031-S4034:

[0157] S4031: Based on the shared node growth data table, calculate the node growth index data for each node in each node.

[0158] S4032: Determine the average value of node growth rate data based on the node growth rate index data corresponding to each node;

[0159] S4033: If the average value of node growth data exceeds the preset threshold range, adjust the node consumption coefficient of the corresponding node based on the average value of node growth data to obtain an updated node coefficient table.

[0160] S4034: If the average value of node growth data does not exceed the preset threshold range, maintain the node consumption coefficient of the corresponding node.

[0161] Specifically, after obtaining the target data table, the node growth rate index data calculated for each node and its corresponding other nodes can be determined. Then, the average of the node growth rate index data for each node is calculated to obtain the average node growth rate data for each node. This average is compared with a preset threshold range. If it exceeds the threshold, the consumption coefficient of that node needs to be adjusted; otherwise, no adjustment is made, and the original value is retained. The average node growth rate data is negatively correlated with the updated node consumption coefficient. In other words, if the node growth rate data is negative, the node cost coefficient is increased; if it is positive, the node cost coefficient is decreased. Furthermore, the larger the absolute value of the average node growth rate data, the greater the decrease or increase in the updated node cost coefficient compared to the original node consumption coefficient; conversely, the smaller the absolute value, the smaller the decrease or increase in the updated node cost coefficient compared to the original node consumption coefficient. For example, the node growth rate index data is the node growth ratio, which is calculated by averaging the transaction growth ratios of each target transaction for that node. The preset threshold range can be, for example, ±10%. Thus, adjusting the node consumption coefficient based on the average node growth rate data further improves the rationality and performance adaptability of dynamic coefficient adjustment, thereby enhancing the accuracy of expense and billing calculations. The relationship between the adjusted node cost coefficient and the average node growth rate data can be set based on actual needs, such as proportional increases or decreases or weighted proportional increases or decreases.

[0162] In one example, refer to Figure 11 In node 2, transaction 1 of block 5 is randomly selected and verified by node 1. The resulting base Gas value (1200) and the base Gas value (1000) of transaction 1 in block 5 are used to calculate a transaction growth rate of 20%, which is recorded in node 1's resource growth data table. As shown in the figure, this resource growth data table displays multiple transaction growth rates for node 2, node 3, and node 4. The transaction identifier includes the block number and transaction number. Based on the average of the data in each column, the node growth rates for nodes 2-4 are calculated to be 12%, -1%, and 20%, respectively, to generate node 1's local node growth data table.

[0163] In another example, refer to Figure 12 The proposal block cycle is n blocks. When the proposal blocks n-1, 2n-1 and 3n-1 are reached, the increase data sharing event is triggered, and the node increase data table is submitted for sharing. As shown in the right half of the figure, nodes 1-3 share their respective node increase data tables. It is determined that the average node increase ratio of node 2 (33%) exceeds the preset threshold range of ±10%, and the node cost coefficient of node 2 is reduced.

[0164] In summary, this application achieves cross-language compatibility and efficient resource consumption data billing through containerized smart contracts and trusted execution environment technologies, improving the accuracy of resource consumption and transaction billing. Random transaction verification and dynamic coefficient adjustment strategies enhance network security and performance consistency, providing a fairer and more transparent billing model for blockchain applications, reducing costs, optimizing user experience, and encouraging smart contract performance optimization.

[0165] In one embodiment, reference Figure 13 The random transaction verification process can include S30-S55:

[0166] S30. Begin;

[0167] S31. The blockchain receives blocks awaiting consensus from the master node from the nodes;

[0168] S32. The blockchain node certificate verification submodule verifies the certificate and signature of the consensus block. If the verification passes, proceed to S33; otherwise, proceed to S34.

[0169] S33. Return the result that the signature verification failed, and proceed to S55;

[0170] S34. The blockchain's authentication submodule verifies the permissions of the block consensus request. If the verification is successful, proceed to S36; otherwise, proceed to S35.

[0171] S35. Returns the result of permission verification failure, proceeds to S55;

[0172] S36. The blockchain's node scheduling module sends the consensus block to the TEE trusted execution environment for verification;

[0173] S37. Trusted Execution Environment (TEE) verifies if the TEE signature in the block transaction list is correct. If yes, proceed to S39; otherwise, proceed to S38.

[0174] S38. Returns an error indicating TEE signature verification failure, proceed to S55;

[0175] S39. The Trusted Execution Environment (TEE) randomly selects a target transaction for transaction verification;

[0176] The S40.TEE trusted execution environment sends the target transaction to the transaction and container scheduling module;

[0177] S41. The transaction and container scheduling module schedules the target transaction to the corresponding contract container for execution;

[0178] S42. When the target transaction is sent to the contract container, the resource consumption calculation module starts recording the timestamp of the sending;

[0179] S43. The container indicator detection module detects the status of the container throughout the entire process of the target transaction execution, and obtains the CPU utilization, memory utilization and I / O utilization.

[0180] S44. After the contract engine completes the transaction, it will send the reference execution result back to the transaction and container scheduling module;

[0181] S45. The resource usage calculation module stops recording the timestamp of this transaction;

[0182] S46. The resource usage calculation module calculates the total CPU usage, total memory usage, and total I / O usage during the execution period of the target transaction;

[0183] S47. The resource usage calculation module subtracts the base usage points from each of the above total usage points to obtain the actual CPU usage points, memory usage points, and I / O usage points of the target transaction.

[0184] S48. The resource consumption calculation module calculates the basic Gas value of the target transaction;

[0185] S49. Does the transaction and container scheduling module verify whether the reference execution result is consistent with the transaction execution result of the master node? If yes, proceed to S51; otherwise, proceed to S50.

[0186] S50. Returns an error indicating transaction verification failure, proceeds to S55;

[0187] S51. Verify the difference between the base Gas values ​​from the node's random transaction verification module, and calculate the transaction growth rate and node growth rate of the target transaction;

[0188] S52.TEE Trusted Execution Environment returns the verification results to the consensus module;

[0189] S53. The consensus module continues to reach consensus on subsequent blocks;

[0190] S54. The storage module stores the newly added node increment ratio in the node increment ratio table;

[0191] S55. End.

[0192] In summary, all nodes will also check the performance consistency through random transaction checks. If there is a mismatch, the node fee coefficient will be adjusted. This method ensures that gas calculations can be performed in any language, improves computing performance, ensures the rationality of gas calculations, and avoids nodes reducing the internal performance of TEE by preempting external resources.

[0193] Furthermore, in one embodiment, reference is made to... Figure 14The periodic adjustment process for node cost coefficients based on node growth rate can include S30-S55:

[0194] S60. Begin;

[0195] S61. The blockchain system continuously produces blocks;

[0196] S62. Has the current block reached the cycle for the proposed block? If yes, proceed to S63; otherwise, proceed to S61.

[0197] S63. All nodes share the node growth rate table of other nodes in the local statistics;

[0198] S64. Does the average node growth rate exceed the preset threshold? If yes, proceed to S65; otherwise, proceed to S70.

[0199] S65. Calculate the updated node cost coefficient for all nodes based on the average node growth rate, and obtain the updated node coefficient table;

[0200] S66. All nodes will package the updated node coefficient table into a block for consensus.

[0201] S67. Has the consensus been reached? If yes, proceed to S68; otherwise, proceed to S70.

[0202] S68. All nodes update and store the latest node cost coefficients in the status database;

[0203] S69. All nodes shall calculate resource cost metrics and transaction fees in subsequent blocks according to the latest node fee coefficient;

[0204] S70. End.

[0205] In summary, this paper presents a method based on a trusted execution environment, random transaction verification, and a dynamic coefficient adjustment strategy. Through the security guarantee of the trusted execution environment, resource consumption data generated by nodes during smart contract execution is reliably recorded and verified. Simultaneously, by randomly selecting transactions and executing them on different nodes, comparing their resource consumption, the node fee coefficients between nodes can be detected and adjusted, ensuring performance consistency among nodes in the network. This not only improves the accuracy of gas billing but also enhances the overall stability, tamper resistance, and security of the network through the dynamic adjustment mechanism.

[0206] Specifically, the application scenarios of this application may include the following scenarios:

[0207] 1. Cross-Language Smart Contract Development Platform: This application supports smart contracts written in any programming language, enabling the creation of a cross-language smart contract development platform. This platform can attract a broader developer community, without restricting developers to using specific blockchain programming languages. Enterprises and developers can use their familiar languages ​​(such as Java, Python, Go, etc.) to write and deploy smart contracts, significantly reducing the learning curve and entry barrier of blockchain technology.

[0208] 2. High-Performance Blockchain-as-a-Service (BaaS) Solution: This application's solution provides an efficient gas billing model through TEE and resource consumption data proof-of-use mechanisms, making it ideal as the foundation for Blockchain-as-a-Service (BaaS). BaaS providers can leverage this solution to offer customers more efficient and secure smart contract execution services. Because gas fees are calculated more accurately, customers can anticipate a more reasonable cost structure, while ensuring both high performance and security of the service.

[0209] 3. Distributed Application (DApp) Marketplace: In the distributed application (DApp) market, developers and users have a high demand for fairness and transparency in gas fees. This application can provide a fairer and more predictable gas billing model for the DApp market, enabling users to pay based on actual resource consumption, thus encouraging developers to optimize application performance while providing users with lower transaction costs.

[0210] 4. Enterprise-Grade Blockchain Solutions: Enterprise applications typically handle large volumes of transactions and complex business logic, thus placing stringent demands on blockchain performance and cost-efficiency. This application provides a scalable and secure Gas billing mechanism through dynamic resource consumption points and TEE verification, suitable for enterprise-grade blockchain solutions. Enterprises can leverage this solution to ensure their blockchain infrastructure is both efficient and cost-effective.

[0211] 5. Blockchain Games and Resource Trading Platforms: Blockchain games and resource trading platforms need to process a large number of micro-transactions, and the gas fees for these transactions can significantly impact user experience. This solution can provide these platforms with a more economical gas billing method, calculating fees based on actual resource consumption, enabling games and trading platforms to offer lower transaction fees and attract more users.

[0212] This application embodiment also provides a blockchain system, which may include a first node. The first node is used to execute the current transaction based on the target contract container corresponding to the current transaction and obtain the transaction execution result; obtain the resource consumption data of the current transaction, the resource consumption data being used to indicate the amount of node resources actually occupied by the target contract container in executing the current transaction; and perform consumption calculation based on the node consumption coefficient of the first node and the resource consumption data of the current transaction to obtain the resource expenditure index data of the current transaction, the node consumption coefficient being used to indicate the consumption calculation weight of the node, and the resource expenditure index data being used to indicate the energy consumed by the execution operation of the current transaction.

[0213] In some embodiments, the blockchain system also includes multiple second nodes.

[0214] Each second node is used to: after the first node executes the current transaction based on the target contract container corresponding to the current transaction and obtains the transaction execution result, respond to the block consensus event triggered by the first node, receive the block to be consensused, the block to be consensused includes the transaction execution results and resource usage data of multiple transactions executed by the first node, and the multiple transactions include the current transaction;

[0215] Each second node is also used to: randomly select at least one target transaction from the block to be reached for consensus, and execute the target transaction again to obtain the reference execution result of each target transaction;

[0216] If the reference execution result matches the corresponding transaction execution result in the block awaiting consensus, obtain the reference occupancy data corresponding to the target transaction. The reference occupancy data is used to indicate the actual amount of node resources occupied by the contract container corresponding to the target transaction in the second node that executes the target transaction again.

[0217] Based on the reference occupancy data and the resource occupancy data of the target transaction, the resource increase index data is determined. The resource increase index data is used to indicate the increase in resource consumption of the second node executing the target transaction again relative to the resource consumption generated by the first node executing the target transaction.

[0218] The extracted resource increase index data for each target transaction is stored in a local resource increase data table on the node. This table includes the transaction, the node identifier of the first transaction execution, and the correspondence between the resource increase index data; and...

[0219] Each node growth data table is generated based on its own resource growth data table. The node growth data table includes node growth index data of multiple other nodes. The node growth index data is used to indicate the increase in resource consumption of the current node relative to other nodes.

[0220] In some embodiments, the nodes of the blockchain system are also used for:

[0221] In response to periodically triggered data sharing events, each node shares its own node growth data table. Each node in the blockchain system includes the first node and each second node.

[0222] The node coefficients are updated based on the shared node growth data table to obtain the updated node coefficient table, which includes the node consumption coefficient of each node.

[0223] A consensus is reached on the updated node coefficient table, and the updated node coefficient table that has passed the consensus is stored.

[0224] In some embodiments, the nodes of the blockchain system are specifically used for:

[0225] Based on the shared data table of growth rates for each node, the growth rate index data for each node in each node is statistically analyzed.

[0226] The average value of node growth rate is determined based on the node growth rate index data corresponding to each node.

[0227] If the average growth rate of node data exceeds the preset threshold range, the node consumption coefficient of the corresponding node is adjusted based on the average growth rate of node data to obtain an updated node coefficient table. The average growth rate of node data is negatively correlated with the updated node consumption coefficient.

[0228] In some embodiments, each node in the blockchain system is also specifically used to: maintain the node consumption coefficient of the corresponding node if the average value of the node growth data does not exceed a preset threshold range.

[0229] In some embodiments, the nodes of the blockchain system are also specifically used for:

[0230] The target contract container corresponding to the smart contract of the current transaction is determined based on a preset correspondence. The preset correspondence includes the mapping relationship between multiple smart contracts and multiple contract containers.

[0231] Execute the current transaction in the target contract container to obtain the transaction execution result.

[0232] In some embodiments, the first node is specifically used for:

[0233] The container indicator detection process monitors the dynamic resource consumption of the target contract container during the execution period of the current transaction.

[0234] Resource consumption statistics are performed on the dynamic resource usage corresponding to the execution period to obtain the resource usage data of the current transaction.

[0235] In some embodiments, the first node is further specifically used for:

[0236] The dynamic resource usage corresponding to the execution period is integrated to obtain the total resource usage data. The total resource usage data is used to indicate the total amount of node resources occupied by the target contract container during the execution period of the current transaction.

[0237] Obtain the basic resource usage data corresponding to the current transaction. The basic resource usage data is used to indicate the amount of node resources occupied by the target contract container in the idle state during the execution period.

[0238] The difference between the total resource usage data and the resource usage data is determined as the resource usage data for the current transaction.

[0239] In some embodiments, the resource occupancy data includes sub-occupancy data corresponding to at least one computing resource; the first node is further specifically used for:

[0240] If the resource usage data includes two or more sub-usage data, the sub-usage data are weighted and merged to obtain the basic expenditure index data;

[0241] Based on the node consumption coefficient of the first node, the basic cost index data is corrected to obtain the resource cost index data corresponding to the current transaction.

[0242] In some embodiments, the contract container, the container metric detection process corresponding to the contract container, and the resource overhead metric data processing process all run in an isolated and encrypted trusted execution environment.

[0243] The system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0244] This application provides a computer device including a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement a transaction resource consumption determination method as provided in the above method embodiments.

[0245] Figure 15 A schematic diagram of the hardware structure of an apparatus for implementing a method for determining the consumption of transaction resources provided in an embodiment of this application is shown. The apparatus may constitute or include the device or system provided in the embodiment of this application. Figure 15As shown, device 10 may include one or more processors 1002 (shown as 1002a, 1002b, ..., 1002n in the figure) 1002 (processor 1002 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 1004 for storing data, and a transmission device 1006 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 15 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, device 10 may also include a... Figure 15 The more or fewer components shown, or having the same Figure 15 The different configurations shown.

[0246] It should be noted that the aforementioned one or more processors 1002 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be wholly or partially integrated into any other element within device 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0247] The memory 1004 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method in this embodiment. The processor 1002 executes various functional applications and data processing by running the software programs and modules stored in the memory 1004, thereby realizing the above-described method for determining the consumption of transaction resources. The memory 1004 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1004 may further include memory remotely located relative to the processor 1002, and these remote memories can be connected to the device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0248] The transmission device 1006 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of device 10. In one example, the transmission device 1006 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 1006 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0249] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows a user to interact with the user interface of device 10 (or a mobile device).

[0250] This application embodiment also provides a computer-readable storage medium, which can be disposed in a server to store at least one instruction or at least one program related to implementing a transaction resource consumption determination method in the method embodiment. The at least one instruction or the at least one program is loaded and executed by the processor to implement the transaction resource consumption determination method provided in the above method embodiment.

[0251] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0252] This invention also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform a transaction resource consumption determination method provided in the various optional embodiments described above.

[0253] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0254] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device, equipment, and storage medium embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0255] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0256] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for determining the consumption of traded resources, characterized in that, The method includes: The first node executes the current transaction based on the target contract container corresponding to the current transaction, and obtains the transaction execution result; The first node obtains the resource usage data of the current transaction, and the resource usage data is used to indicate the amount of node resources actually used by the target contract container to execute the current transaction; Consumption is calculated based on the node consumption coefficient of the first node and the resource usage data of the current transaction to obtain the resource expenditure index data of the current transaction. The node consumption coefficient is used to indicate the consumption calculation weight of the node, and the resource expenditure index data is used to indicate the energy consumed by the execution operation of the current transaction.

2. The method according to claim 1, characterized in that, After the first node executes the current transaction based on the target contract container corresponding to the current transaction and obtains the transaction execution result, the method further includes: In response to the block consensus event triggered by the first node, each second node of the blockchain system receives a block to be consensused. The block to be consensused includes the transaction execution results and resource usage data of multiple transactions executed by the first node, and the multiple transactions include the current transaction. Each second node randomly selects at least one target transaction from the block to be consensused, and executes the target transaction again to obtain the reference execution result of each target transaction. If the reference execution result matches the corresponding transaction execution result in the block to be reached for consensus, the second node obtains the reference occupancy data corresponding to the target transaction. The reference occupancy data is used to indicate the actual amount of node resources occupied by the contract container corresponding to the target transaction in the second node that executes the target transaction again. Each second node determines resource increase index data based on the reference occupancy data and the resource occupancy data of the target transaction. The resource increase index data is used to indicate the increase in resource consumption of the second node when executing the target transaction again relative to the resource consumption generated by the first node when executing the target transaction. Each of the second nodes stores the extracted resource increase index data of each target transaction to a local resource increase data table. The resource increase data table includes the transaction, the node identifier that first executed the transaction, and the correspondence between the resource increase index data. Each of the second nodes generates a node increase data table based on its own resource increase data table. The node increase data table includes node increase index data of multiple other nodes. The node increase index data is used to indicate the increase in resource consumption of the current node relative to other nodes.

3. The method according to claim 2, characterized in that, The method further includes: In response to periodically triggered data sharing events, each node in the blockchain system shares its own node growth data table, wherein each node in the blockchain system includes the first node and each of the second nodes; Each node in the above nodes updates its node coefficients according to the shared node growth data table to obtain an updated node coefficient table, which includes the node consumption coefficient of each node. Each node reaches a consensus on the updated node coefficient table and stores the updated node coefficient table that has passed the consensus.

4. The method according to claim 3, characterized in that, Each node in the aforementioned nodes updates its node coefficients based on the shared node increase data table, resulting in an updated node coefficient table including: Based on the shared node growth data tables, the node growth index data corresponding to each node is statistically analyzed. The average value of node growth rate is determined based on the node growth rate index data corresponding to each node. If the average value of the node growth data exceeds a preset threshold range, the node consumption coefficient of the corresponding node is adjusted based on the average value of the node growth data to obtain the updated node coefficient table. The average value of the node growth data is negatively correlated with the updated node consumption coefficient.

5. The method according to claim 4, characterized in that, The method further includes: If the average value of the node growth data does not exceed the preset threshold range, the node consumption coefficient of the corresponding node is maintained.

6. The method according to any one of claims 1-5, characterized in that, The execution of the current transaction based on the target contract container corresponding to the current transaction, and the resulting transaction execution result, include: The target contract container corresponding to the smart contract of the current transaction is determined based on a preset correspondence, wherein the preset correspondence includes a mapping relationship between multiple smart contracts and multiple contract containers; The current transaction is executed in the target contract container to obtain the transaction execution result.

7. The method according to any one of claims 1-5, characterized in that, The process of obtaining the resource usage data for the current transaction includes: The container metric detection process monitors the dynamic resource consumption of the target contract container during the execution period of the current transaction. Resource consumption statistics are performed on the dynamic resource consumption corresponding to the execution period to obtain the resource consumption data of the current transaction.

8. The method according to claim 7, characterized in that, The step of performing resource cost statistics on the dynamic resource usage corresponding to the execution period to obtain the resource usage data of the current transaction includes: The dynamic resource usage corresponding to the execution period is integrated to obtain total resource usage data, which is used to indicate the total amount of node resources occupied by the target contract container during the execution period of the current transaction. Obtain the basic resource usage data corresponding to the current transaction. The basic resource usage data is used to indicate the amount of node resources occupied by the target contract container in the idle state during the duration corresponding to the execution period. The difference between the total resource usage data and the resource usage data is determined as the resource usage data of the current transaction.

9. The method according to any one of claims 1-5, characterized in that, The resource usage data includes sub-usage data corresponding to at least one computing resource; the step of calculating the consumption based on the node consumption coefficient of the first node and the resource usage data of the current transaction to obtain the resource expenditure index data of the current transaction includes: If the resource occupancy data includes two or more sub-occupancy data, the sub-occupancy data are weighted and merged to obtain the basic cost index data. Based on the node consumption coefficient of the first node, the basic cost index data is corrected to obtain the resource cost index data corresponding to the current transaction.

10. The method according to any one of claims 1-5, characterized in that, The contract container, the container metric detection process corresponding to the contract container, and the resource overhead metric data calculation process all run in an isolated and encrypted trusted execution environment.

11. A blockchain system, the blockchain system comprising a first node, characterized in that, The first node is used to execute the current transaction based on the target contract container corresponding to the current transaction, and obtain the transaction execution result; and to obtain the resource usage data of the current transaction, wherein the resource usage data is used to indicate the amount of node resources actually used by the target contract container to execute the current transaction; Furthermore, the consumption amount is calculated based on the node consumption coefficient of the first node and the resource usage data of the current transaction to obtain the resource expenditure index data of the current transaction. The node consumption coefficient is used to indicate the consumption calculation weight of the node, and the resource expenditure index data is used to indicate the energy consumed by the execution operation of the current transaction.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement the transaction resource consumption determination method as described in any one of claims 1 to 10.

13. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or at least one program being loaded and executed by the processor to implement the transaction resource consumption determination method as described in any one of claims 1 to 10.

14. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the method for determining the consumption of transaction resources as described in any one of claims 1 to 10.

Images