Computing power processing method, electronic device, and computer readable medium

Abstract

The application discloses a computing power processing method, electronic equipment and a computer readable medium, and relates to the technical field of computing power processing, and comprises the following steps: in response to a computing power task request, generating an initial pledge token number corresponding to a requester of the computing power task request, and locking the corresponding token number in the account of the requester on a chain based on the initial pledge token number; calling a computing power node to execute the computing power task request; in the process of executing the computing power task request by the computing power node, acquiring a trusted token output certificate corresponding to a current time slice; based on the computing power measurement value in the trusted token output certificate, determining the current consumed token; based on the current consumed token, deducting the corresponding token from the account of the requester until the computing power node terminates the execution of the computing power task request, and in the case that the computing power node terminates the execution of the computing power task request, performing a deduction and release operation on the locked initial pledge token number. The application can avoid tampering with the computing power measurement data.

Description

Technical Field

[0001] This invention relates to the field of computing power processing technology, and more specifically to computing power processing methods, electronic devices, and computer-readable media. Background Technology

[0002] With the rapid development of large-scale AI model training and inference, elastic computing power scheduling, and distributed high-performance computing, decentralized computing power trading scenarios have placed higher demands on the reliability of computing power measurement, the flexibility of staking risk control, and the consistency of settlement.

[0003] However, currently, when settling computing power accounts after completing computing power tasks, there is a problem that computing power measurement data is easily tampered with, which leads to a high risk of financial loss for computing power providers. Summary of the Invention

[0004] This invention aims to address, to a certain extent, one of the technical problems in related technologies. To this end, this invention provides a computing power processing method, an electronic device, and a computer-readable medium, which have the advantage of preventing the tampering of computing power measurement data.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A computing power processing method, comprising: In response to a computing power task request, an initial number of staked tokens corresponding to the requester of the computing power task request is generated, and the corresponding number of tokens in the requester's account is locked on-chain based on the initial number of staked tokens. Invoke the computing power node to execute the computing power task request; During the execution of the computing power task request by the computing power node, a trusted word element production certificate corresponding to the current time slice is obtained; wherein, the trusted word element production certificate is a structured trusted certificate containing computing power measurement value generated by the hardware trust root within the computing power node. Based on the computing power measurement value in the trusted word element production certificate, the currently consumed word element is determined; Based on the currently consumed tokens, the corresponding tokens are deducted from the requester's account until the computing power node terminates the execution of the computing power task request. If the computing power node terminates the execution of the computing power task request, the locked initial staked tokens are deducted and released.

[0006] Optionally, the trusted lexical generation certificate includes a GPU utilization time-series value and a task output hash verification result. The task output hash verification result is a comparison between the hash value of the output data actually generated by the execution of the computing power task request within the current time slice and a preset expected output hash value corresponding to the current time slice, pre-loaded in the hardware trust root isolated storage area. After obtaining the trusted lexical generation certificate corresponding to the current time slice, the process further includes: Based on the GPU utilization time series value and the task output hash verification result, the current health of the computing node is determined. Get the current network congestion index; The current staking coefficient is determined using the current health status, the current network congestion index, and a preset coefficient corresponding to the computing power task request; Calculate the new number of pledged terms using the current pledge coefficient; If the new number of staked tokens is greater than the initial number of staked tokens, an on-chain request is sent to the requester so that the requester can complete the replenishment of the excess tokens within a preset time period. If the requesting party fails to complete the excess token locking within the preset time period, a level 3 circuit breaker is triggered, and the computing power node is controlled to terminate the execution of the computing power task request.

[0007] Optionally, the step of determining the current health of the computing node based on the GPU utilization time-series value and the task output hash verification result includes: The abnormal jitter coefficient is determined based on the GPU utilization timing value; The failure penalty factor is determined based on the hash verification result of the task output. Based on the abnormal jitter coefficient, the failure penalty factor and its corresponding weight, the negative health impact value of the current time slice is determined; The current health of the computing power node is obtained by using the negative health impact value to perform an exponentially weighted smooth update of the node health in the previous time slice.

[0008] Optionally, the formula for calculating the current staking coefficient is as follows:

[0009] A preset coefficient corresponding to the computing power task request. Current health status The current network congestion index, This represents the risk weight coefficient obtained by fitting historical data.

[0010] Optionally, the step of calculating the new number of staking terms using the current staking coefficient includes: Determine the initial base number of staked terms corresponding to the computing power task request; The product of the initial base number of staked terms and the current staked coefficient is used as the new number of staked terms.

[0011] Optionally, after obtaining the trusted lexical generation certificate corresponding to the current time slice, the method further includes: If, after the current time slice, the GPU utilization rate in the trusted token production credentials of multiple consecutive time slices is lower than a preset threshold, a first-level circuit breaker is triggered and an alarm is output. If, after the current time slice, no trusted word element production certificate corresponding to a consecutive preset number of time slices is obtained, or if the task output hash verification result in the trusted word element production certificate corresponding to the time slice fails, a second-level circuit breaker is triggered, and the metering and billing of the computing power node are suspended. The computing power task request is then migrated to a standby computing power node so that the standby computing power node can execute the computing power task request. If, after the current time slice, the task output hash verification result in the trusted token production certificate corresponding to a consecutive preset number of time slices fails, a level 3 circuit breaker is triggered, and the computing power node is controlled to terminate the execution of the computing power task request, and a preset number of tokens are deducted from the initial number of pledged tokens.

[0012] Optionally, the step of deducting and releasing the locked initial staking terminology when the computing power node terminates the execution of the computing power task request includes: If the computing power node terminates the execution of the computing power task request, the total number of words to be deducted shall be determined based on the computing power measurement value in the trusted word production certificate corresponding to each time slice. Determine the total number of deducted tokens in real time for the computing power request task; If the total number of deductible words is greater than the total number of words deducted in real time, the difference in deductible words is determined. Based on the deducted token difference, a corresponding number of tokens are deducted from the locked initial staked token count, and the remaining initial staked tokens are decompressed and returned to the requester.

[0013] Optionally, the step of invoking the computing power node to execute the computing power task request includes: The computing power task request is parsed to obtain the GPU model, minimum video memory capacity, and minimum node health threshold corresponding to the computing power task request. Select the computing power nodes in the computing power node pool whose current number of tasks is less than the maximum concurrency and whose hardware trust root is normal as candidate nodes; The candidate nodes are filtered based on the GPU model, the minimum video memory capacity, and the minimum node health threshold to obtain new candidate nodes; Obtain the current health, historical fulfillment rate, historical network latency rate, and current load of the new candidate node; A node score is determined based on the current health status, the historical fulfillment rate, the historical network latency rate, and the current load and its corresponding weight. The new candidate node with the highest node score is selected as the target computing power node. The target computing node is invoked to execute the computing task request.

[0014] In a second aspect, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the computing power processing method described in any of the above claims.

[0015] Thirdly, the present invention also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the computing power processing method described in any of the preceding claims.

[0016] In this invention, initial staked tokens are generated and locked on-chain in response to computing power task requests, ensuring that the requester has performance guarantees. During task execution, computing power nodes are invoked to execute computing power task requests, and the hardware root of trust within the node generates a trusted token production certificate containing computing power measurement values ​​in each time slice. This certificate is tamper-proof and forgery-proof due to hardware signature, thus fundamentally preventing software-level tampering or false reporting of computing power consumption data. Based on the computing power measurement values ​​in the certificate, the currently consumed tokens are determined in real time and deducted from the requester's account, achieving continuous and accurate deductions that are strictly bound to actual computing power consumption, avoiding fee disputes caused by data distortion. When the task terminates, the locked initial staked tokens are deducted and released, ensuring the final consistency between funds and computing power consumption. The entire process relies solely on the same source trusted token generated by the hardware trust root, without depending on any external oracles or software logs. This completely solves the trust crisis and inconsistency issues caused by the easy tampering of computing power data and the different sources of staking and settlement data in existing technologies. It significantly improves the credibility and automation level of decentralized computing power transactions, thereby avoiding financial losses for computing power providers.

[0017] These features and advantages of the present invention will be disclosed in detail in the following specific embodiments and accompanying drawings. The preferred embodiments or means of the present invention will be shown in detail in conjunction with the accompanying drawings, but are not intended to limit the technical solutions of the present invention. In addition, each of these features, elements and components appearing in the following text and drawings is a plurality of, and different symbols or numbers are used for convenience of representation, but all represent parts with the same or similar construction or function. Attached Figure Description

[0018] The present invention will be further described below with reference to the accompanying drawings: Figure 1 A flowchart illustrating one embodiment of the computing power processing method provided by the present invention; Figure 2 This is a flowchart illustrating the process of determining the computing node that executes the computing task request provided by the present invention. Figure 3 This is a schematic diagram of the process for deducting and releasing initial pledged terms provided by the present invention; Figure 4 A flowchart illustrating the process of determining and dynamically adjusting the number of pledged terms provided by this invention; Figure 5 This is a schematic diagram illustrating the process of determining the current health of a computing node based on GPU utilization time-series values ​​and the hash verification results of the task output, as provided in this invention. Figure 6 This is a schematic diagram of the tiered circuit breaker triggering process provided by the present invention; Figure 7 A schematic diagram of the electronic device provided by the present invention; Figure 8 This is a schematic diagram of a computer-readable medium provided by the present invention.

[0019] Explanation of reference numerals in the attached figures: 101. Processor; 102. Memory; 103. I / O interface; 104. Bus. Detailed Implementation

[0020] Embodiments of the present invention are described in detail below, examples of which are illustrated 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. The embodiments described are intended to explain the present invention and should not be construed as limiting the invention.

[0021] The terms "an embodiment," "example," or "trademark" used in this specification refer to a particular feature, structure, or characteristic described in connection with the embodiment itself that may be included in at least one embodiment disclosed in this invention. The phrase "in an embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment.

[0022] With the rapid popularization of large-scale AI model training and inference, real-time elastic computing power expansion, autonomous AI agent collaboration, and distributed high-performance computing, the decentralized computing power market is gradually becoming the next-generation digital economy infrastructure. However, the following problems exist in the process of building a trustworthy, efficient, and automated computing power value network: 1. If a trustworthy measurement is desired, it is necessary to rely on a hardware root of trust (such as TEE / HSM) to achieve tamper-proof monitoring. However, traditional TEE (Trusted Execution Environment) is only used for data privacy protection and is not deeply bound to computing power consumption and value generation. It cannot generate tradable value certificates, and the measurement results cannot be used as the basis for computing power settlement. 2. If a reliable measurement is desired, the collateral needs to be dynamically adjusted based on the real-time status. However, current dynamic collateral adjustments generally rely on off-chain centralized data or software logs. Off-chain centralized data or software logs are subject to tampering, so the authenticity of the data cannot be guaranteed. This makes dynamically adjusted collateral vulnerable to data forgery attacks, leading to the failure of risk control. 3. If the goal is to achieve fully automated atomic settlement, then smart contracts are needed to execute the liquidation process. However, the triggering conditions of smart contracts depend on the input of external oracles, and the input of external oracles is subject to problems such as data tampering, latency inconsistency, and centralized dependence, making it impossible to achieve atomic consistency.

[0023] Therefore, when settling computing power accounts after completing computing power tasks, there is a problem that computing power measurement data is easily tampered with, which leads to a high risk of financial loss for computing power providers.

[0024] In view of this, a computing power processing method is provided, such as Figure 1 As shown, the method includes: In step S110, in response to a computing power task request, an initial number of staked tokens corresponding to the requester of the computing power task request is generated, and the corresponding number of tokens in the requester's account is locked on-chain based on the initial number of staked tokens.

[0025] In this embodiment, the computing power task request may include information such as computing power task content, computing power task type, GPU specifications, estimated duration, priority, minimum video memory capacity, and minimum node health threshold. The method described in this embodiment is executed by an AI computing power value internet settlement system running on an electronic device, which may be a distributed computing power scheduling and trusted settlement platform.

[0026] Specifically, upon receiving a computing power task request submitted by a user or AI agent, the identity of the requester and the legality of the task can be verified. If the verification passes, the maximum computing power consumption and a preset coefficient corresponding to the task type of the computing power task request can be estimated based on the task type. The network congestion index is obtained from the on-chain consensus layer, and the initial staking coefficient is calculated using formula (1). The product of the initial staking coefficient and the estimated maximum computing power consumption is used as the initial staking terminology, or the product of the initial staking coefficient and the initial baseline staking terminology corresponding to the computing power task request can be used as the initial staking terminology. When calculating the initial staking coefficient, the node health is the default health or the average health of the requester's historically used computing power nodes.

[0027] After calculating the initial number of staked tokens, a smart contract can be invoked to change the corresponding number of tokens in the requester's account from an available state to an on-chain locked state. This means locking the corresponding number of tokens in the requester's account on-chain based on the initial number of staked tokens. The smart contract can be automated program code running within the AI ​​computing power value internet settlement system. Internally, it defines the business logic for staking lock-up, real-time fee deduction, supplementary staking, circuit breaker handling, and atomic settlement. The smart contract only accepts invocation requests initiated by the AI ​​computing power value internet settlement system based on trusted token generation certificates, and automatically executes token locking, deduction, return, and penalty deduction operations according to preset conditions. All execution results are stored as on-chain transactions, possessing the characteristics of immutability and public auditability.

[0028] In step S120, the computing power node is invoked to execute the computing power task request.

[0029] When a smart contract is invoked to change the corresponding number of tokens in the requester's account from an available state to an on-chain locked state, the smart contract returns a transaction receipt indicating successful locking if the locking is successful. Upon receiving the successful locking transaction receipt, a computing power node can be invoked to execute the computing power task request. However, in a decentralized computing power network, computing power nodes are heterogeneous, and each computing power task request has specific requirements for hardware resources and stability. Therefore, to avoid slow execution speeds or execution failures, further, as an optional real-time method, refer to... Figure 2 As shown, Figure 2 A flowchart illustrating the process of determining the computing node to execute a computing task request is provided. Step S120 specifically includes: In step S210, the computing power task request is parsed to obtain the GPU model, minimum video memory capacity, and minimum node health threshold corresponding to the computing power task request.

[0030] In step S220, computing nodes in the computing node pool whose current number of tasks is less than the maximum concurrency and whose hardware trust root is normal are selected as candidate nodes.

[0031] In step S230, the candidate nodes are filtered based on the GPU model, the minimum video memory capacity, and the minimum node health threshold to obtain new candidate nodes.

[0032] In step S240, the current health, historical fulfillment rate, historical network latency rate, and current load of the new candidate node are obtained.

[0033] In step S250, a node score is determined based on the current health status, the historical fulfillment rate, the historical network latency rate, and the current load and its corresponding weight.

[0034] In step S260, the new candidate node with the highest node score is selected as the target computing power node.

[0035] In step S270, the target computing node is invoked to execute the computing task request.

[0036] Specifically, upon receiving a computing task request from the requester, the request is parsed to obtain the corresponding GPU model, minimum video memory capacity, and minimum node health threshold. Then, all computing nodes in the node pool are traversed, and nodes with a current task count less than the maximum concurrency and a normal hardware root of trust are selected as candidate nodes. That is, the number of tasks currently being executed by a computing node is less than the maximum number of concurrent tasks it supports. If a computing node does not support concurrency, its maximum number of concurrent tasks is 1, meaning the node must not be executing any computing tasks. Simultaneously, the TEE status within the computing node must be normal, the recent heartbeat time must not exceed the threshold, and the hardware signature function must be available. Computing nodes that meet both of these conditions are selected as candidate nodes.

[0037] After obtaining candidate nodes, if the number of candidate nodes is 0, a failure to allocate computing power nodes is returned, triggering staking decompression and informing the requester. If the number of candidate nodes is not 0, candidate nodes are filtered using GPU model, minimum memory capacity, and minimum node health threshold to obtain new candidate nodes. Specifically, the candidate node's GPU model must match the GPU model requested by the computing power task, the node's memory capacity must not be less than the minimum memory capacity requested by the computing power task, and the node's historical average health must not be less than the minimum node health threshold. Candidate nodes that meet all of the above conditions are selected as new candidate nodes. Conversely, if no candidate node meets all of the above conditions, a failure to allocate computing power nodes is returned, triggering staking decompression and informing the requester.

[0038] After obtaining new candidate nodes, the current health and number of tasks currently being executed for each new candidate node can be read from the node registry. The ratio of the number of tasks currently being executed to the maximum concurrency is used as the current load. The historical fulfillment rate is obtained by querying the ratio of the number of successfully completed tasks to the total number of accepted tasks for each new candidate node from the on-chain evidence storage layer. The average network latency from each new candidate node to the scheduling platform is obtained from the network monitoring module and normalized to obtain the historical network latency rate. Subsequently, the node score for each new candidate node is calculated by combining the current health, the historical fulfillment rate, the historical network latency rate, and the current load and its corresponding weights. (2), Indicates node score, Indicates current health status. Indicates the historical contract fulfillment rate. Indicates historical network latency. This means that lower latency equates to higher scores. Indicates the current load. This means that a higher score is awarded for a lower load, in order to encourage the selection of more idle computing nodes and achieve load balancing. , , , This indicates the corresponding weight, which can be adaptively set according to actual needs. This embodiment does not impose any special restrictions on this.

[0039] Correspondingly, if the new candidate node mode is exclusive, meaning that the node does not accept any other tasks during the execution of a single task, then the node score of the new candidate node is calculated by combining the current health, the historical fulfillment rate, the historical network latency rate, and their corresponding weights. (3).

[0040] After obtaining the node scores of each new candidate node, sort all the node scores of the new candidate nodes from highest to lowest to obtain a sorted list. Select the first computing power node in the sorted list as the target computing power node and call the target computing power node to execute the computing power task request.

[0041] It's worth noting that when selecting the first computing node in the sorted list as the target computing node and calling it to execute a computing task request, to prevent concurrent allocation conflicts (i.e., multiple tasks simultaneously selecting the same computing node), atomic pre-locking must be performed on that computing node. This involves creating a node lock flag in the distributed cache, uniquely identified by the computing node's ID, and binding the computing task request ID to the node lock flag. The validity period of this node lock flag is set to 10 seconds; if the node lock flag is not actively released within 10 seconds, it is automatically deleted to avoid deadlocks caused by abnormal crashes. If a successful lock is received, it means that the computing node was not previously locked and a lock has been successfully set this time. In this case, it is selected as the target computing node, and the computing task request is executed on that node. Correspondingly, if a locking failure is received, it means that the computing power node has been locked, that is, it has been requested and preempted by other computing power tasks, and the computing power node is temporarily unavailable. At this time, the next node is taken from the sorting list, and the above operation is repeated until a computing power node is successfully locked and that computing power node is used as the target computing power node, or all computing power nodes cannot be locked. At this time, an allocation failure signal is output, and failure handling procedures such as unlocking staking and returning error information are triggered.

[0042] In this embodiment, by parsing the computing power task requests to obtain the GPU model, minimum memory capacity, and minimum node health threshold, and selecting nodes in the computing power node pool whose current number of tasks is less than the maximum concurrency and whose hardware root of trust is normal as candidate nodes, it is ensured from the source that only nodes with sufficient hardware resources, a trusted execution environment, and available capacity enter the subsequent screening, avoiding the risk of execution failure caused by assigning tasks to nodes with insufficient resources or untrustworthy nodes. On this basis, a second screening is performed based on GPU model matching, sufficient memory capacity, and health not lower than the threshold, further eliminating nodes with incompatible hardware or historically low health, thereby significantly improving the matching accuracy between tasks and nodes. By obtaining the current health, historical fulfillment rate, historical network latency rate, and current load of candidate nodes, and performing a comprehensive score based on their respective weights, the real-time reliability, long-term credit, communication efficiency, and resource consumption of nodes can be reflected. The node with the highest score is selected as the target computing power node, achieving optimal scheduling under multi-objective constraints. That is, high health and high fulfillment rate ensure the stability and success rate of task execution, low network latency reduces interaction latency, and low load avoids performance degradation caused by node overload. Therefore, through the allocation operation in this embodiment, the reliability, credit, communication efficiency and load of nodes can be dynamically balanced while ensuring the trustworthiness of the hardware root of trust. This effectively reduces the probability of abnormal circuit breakers and the frequency of supplementary staking triggers during task execution, thereby reducing the capital occupation and transaction disputes of the demand side and improving the resource utilization efficiency and automated scheduling level of the entire computing power network.

[0043] In step S130, during the process of the computing power node executing the computing power task request, a trusted word generation certificate corresponding to the current time slice is obtained.

[0044] The trusted term generation certificate is a structured trusted certificate containing computing power measurement values, generated by the hardware trust root within the computing power node.

[0045] In step S140, the currently consumed lexicon is determined based on the computing power measurement value in the trusted lexicon production certificate.

[0046] In step S150, the corresponding tokens are deducted from the requester's account based on the currently consumed tokens until the computing power node terminates the execution of the computing power task request. If the computing power node terminates the execution of the computing power task request, the locked initial staked tokens are deducted and released.

[0047] In this embodiment, a trusted token can be the smallest unit of measurement for AI computing power, representing standardized computing power consumption measured by hardware trust. It serves as a digital carrier of computing power value and is used in the computing power trading phase. The hardware root of trust can be a trusted hardware module deployed within a computing node, possessing independent computing and storage capabilities. Based on physical isolation and cryptographic mechanisms, it directly and intrinsically collects computing power consumption data during task execution without relying on the node's operating system or upper-layer applications. It then performs hardware-level digital signatures on the collected data to generate an immutable trusted token production certificate. The hardware root of trust includes, but is not limited to, a TEE trusted execution environment or an HSM hardware security module.

[0048] Specifically, during the execution of computing task requests, the hardware root of trust creates an isolated execution environment within the computing node. This environment is completely isolated from the node's operating system and other processes to ensure that subsequent data collection and computation operations are not interfered with or tampered with by any software on the computing node. The hardware root of trust then directly reads the performance counters at the computing node's hardware layer, collecting the following four types of data: 1. GPU utilization time series value: The percentage of GPU core usage is sampled multiple times within a time slice and its sequence is recorded, such as 10 equally spaced sampling points; 2. Calculate the number of instructions executed: Read the number of floating-point or tensor instructions executed by the GPU; 3. Effective memory usage period: Measure the duration during which HBM / video memory is effectively used within the time slice, i.e., the proportion of video memory read and write activity. 4. Task output hash verification structure: Calculate the hash value of the actual output data of the task in this time slice, compare it with the expected output hash value, and obtain a boolean value, that is, pass or fail.

[0049] For GPU utilization time series values, count the number of sampling points where the utilization exceeds the preset threshold, multiply by the sampling interval to obtain the effective computing time of the GPU. For example, if 8 sampling points in a time slice exceed 20% and the sampling interval is 10ms, the effective computing time is 8×10ms=80ms.

[0050] Subsequently, the effective GPU computation time, the number of computation instructions executed, and the effective memory usage period are weighted and summed according to preset weights to obtain the raw hardware measurement value. After obtaining the raw hardware measurement value, the product of the raw hardware measurement value, the task type coefficient, and the node trust coefficient is used as the actual computing power consumption value, i.e., the computing power measurement value. That is, the actual computing power consumption value = (GPU effective computation time × weight 1 + number of computation instructions executed × weight 2 + effective memory usage period × weight 3) × task type coefficient × node trust coefficient. Among them, the task type coefficient is determined according to the task type of the computing power task request, i.e., the preset coefficient corresponding to the computing power task request, which is used to reflect the difference in resource consumption density of different types of tasks. The node trust coefficient can be dynamically adjusted according to the historical fulfillment rate and health of the computing power node, and is used to penalize the computing power node.

[0051] After obtaining the computing power measurement value, the hardware root of trust can assemble data such as computing power task request identifier, time slice sequence number, computing power measurement value, computing power node identifier, task output hash verification result, timestamp, and hardware signature value into a structured data packet, and use the hardware private key to sign the data, thereby obtaining a trusted token production certificate, and uploading the trusted token production certificate.

[0052] After obtaining the trusted word element production certificate, the hardware signature of the trusted word element production certificate is first verified. If the hardware signature is successful, the computing power measurement value is extracted from the trusted word element production certificate, and the product of the computing power calculation value and the preset word element exchange rate is used as the current consumed word element.

[0053] After obtaining the currently consumed tokens, the real-time deduction interface of the smart contract can be called, passing in the identifier of the computing power task request and the currently consumed tokens. Based on the identifier of the computing power task request, the smart contract determines the corresponding requester and deducts the corresponding number of tokens from the requester's available balance, i.e. the unstaking portion of tokens, based on the currently consumed tokens. The total amount deducted is accumulated, i.e. the total number of tokens deducted in real time, to facilitate subsequent staking adjustments and final settlement, and to generate a real-time deduction record, including the current time slice number, the amount deducted, and the remaining available balance.

[0054] Repeat the aforementioned steps until the computing power node terminates the execution of the computing power task request. If the computing power task request terminates, the locked initial staked tokens can be deducted and released. It is understood that when deducting fees based on the currently consumed tokens, the deduction is made from the available balance in the requester's account. Deductions may fail due to the following reasons: the requester fails to top up in time, resulting in insufficient available balance; the on-chain deduction transaction fails due to network congestion; or the smart contract malfunctions due to insufficient gas. In this case, to ensure the consistency of fund settlement and to ensure that the computing power provider receives all the tokens it is entitled to, further, as an optional real-time method, refer to... Figure 3 As shown, Figure 3 This is a flowchart illustrating the deduction and release operation for the initial pledged tokens. Step S150 specifically includes: In step S310, if the computing node terminates the execution of the computing task request, the total number of tokens to be deducted is determined based on the computing power measurement value in the trusted token production certificate corresponding to each time slice.

[0055] In step S320, the total number of real-time deducted tokens for the computing power request task is determined; In step S330, if the total number of deductible tokens is greater than the total number of tokens to be deducted in real time, the deductible token difference is determined.

[0056] In step S340, based on the deducted token difference, a corresponding number of tokens are deducted from the locked initial pledged token count, and the remaining initial pledged tokens are decompressed and returned to the requester.

[0057] Specifically, in the event that the computing power task requests termination, all the obtained trusted word element production vouchers can be traversed to extract the computing power measurement value corresponding to each trusted word element production voucher. All computing power measurement values ​​are accumulated to obtain the total computing power measurement value. The product of the total computing power measurement value and the preset word element exchange rate is used as the total number of words elements to be deducted.

[0058] After obtaining the total number of tokens to be deducted, the real-time deduction records for this computing power task request in the smart contract can be queried to obtain the total number of tokens deducted in real time. The difference between the total number of tokens to be deducted and the total number of tokens deducted in real time is then calculated, which is the deduction token difference. If the difference is greater than 0, it indicates insufficient deduction. In this case, the corresponding number of tokens can be deducted from the locked initial staked tokens, the deducted tokens are transferred to the computing power provider, and the status of the remaining staked tokens is changed from locked to available and returned to the requester. If the difference is equal to 0, it indicates that the total number of tokens to be deducted is the same as the total number of tokens deducted in real time, and no additional deduction or return operation is required. In this case, the status of the initial staked tokens is directly changed from locked to available and returned to the requester. If the difference is less than 0, it indicates that the real-time deduction exceeds the limit. In this case, the excess portion needs to be returned, and the status of the initial staked tokens is changed from locked to available and returned to the requester.

[0059] It's worth noting that the termination of a computing power task request can be triggered by the following three events: the computing power task request reaches the predetermined termination condition, the requester initiates task cancellation, or the task output hash verification result fails consecutively, indicating malicious occupation or use of computing power by a computing power node, triggering an abnormal circuit breaker. If the computing power task request is terminated normally or due to user termination, when deducting and releasing the locked initial staked tokens, only the difference between the total number of tokens to be deducted and the total number of tokens deducted in real time needs to be deducted for supplementary deduction and return. If the operation is caused by an abnormal circuit breaker, after the aforementioned supplementary deduction operation, the corresponding penalty must also be deducted from the initial staked tokens, i.e., remaining staked tokens = initial staked tokens - difference - penalty.

[0060] Finally, after completing the above operations, the total number of deductible tokens, the total amount of real-time deductions, the difference in deducted tokens, the difference in returned tokens, the penalty for breach of contract, the termination time of the computing power task request, and the reason for termination can be packaged and stored on the blockchain to generate an immutable settlement certificate for future auditing.

[0061] In this embodiment, when the computing power node terminates the execution of the computing power task request, the computing power measurement value in the trusted token production certificate of each time slice can be aggregated to objectively and immutably calculate the total number of tokens to be deducted throughout the entire task lifecycle. This data originates from the signature certificate of the hardware root of trust, eliminating the possibility of software forgery or human intervention. At the same time, the total number of tokens deducted in real time during task execution is determined and compared with the total number of tokens to be deducted. If the total number of tokens to be deducted is greater than the total number of tokens deducted in real time, the difference is automatically calculated and the corresponding number of tokens is deducted from the initial staked tokens locked on the chain. This ensures that the requester pays in full according to the actual computing power consumption and avoids the loss of fees caused by insufficient real-time deduction, such as temporary shortage of account balance or deduction failure caused by network delay. Finally, the remaining initial staked tokens are unstaking and returned to the requester, which not only protects the receivable rights of the computing power provider but also prevents the improper use of funds by the requester. This series of operations uses the trusted token output certificate as the sole basis, and automatically completes the difference deduction and excess return when the task ends. It realizes the accurate settlement between the pledged funds and the actual consumption, completely solves the transaction disputes caused by incomplete real-time deduction or inconsistent accounts in the existing technology, and significantly improves the automation level of decentralized computing power transactions and the fairness of fund settlement.

[0062] It should be noted that the actual operating status of computing nodes and the network environment change dynamically during task execution. The initial staking tokens are based solely on pre-task estimates and cannot reflect subsequent risks such as node performance degradation, abnormal output, or on-chain congestion. If the staking coefficient is not adjusted in a timely manner, it will be impossible to identify increased risks due to abnormal node fluctuations or malicious occupation, nor will it be possible to promptly detect the negative impact of network congestion on settlement timeliness. This leads to a disconnect between the staking amount and the actual risk level; insufficient staking when risk increases will leave potential financial losses, while excessive staking when risk decreases will reduce capital utilization efficiency. Therefore, to avoid transaction losses due to insufficient staking, node anomalies, or network risks, and to ensure the security, stability, and risk control of the entire computing power transaction process, further, as an optional implementation method, refer to... Figure 4 As shown, Figure 4 The flowchart illustrates the dynamic adjustment of the number of pledged terms. After step S130, the following steps are also included: In step S410, the current health of the computing node is determined based on the GPU utilization time series value and the task output hash verification result.

[0063] In step S420, the current network congestion index is obtained.

[0064] In step S430, the current staking coefficient is determined using the current health status, the current network congestion index, and the preset coefficient corresponding to the computing power task request.

[0065] In this embodiment, the trusted token output certificate includes GPU utilization time series value and task output hash verification result. The task output hash verification result is the comparison result between the hash value of the output data actually generated by the actual execution of the computing power task request in the current time slice and the preset expected output hash value corresponding to the current time slice, which is pre-loaded in the hardware trust root isolated storage area.

[0066] Specifically, after obtaining the trusted token output certificate for the current time slice, the trusted token output certificate can be parsed through the aforementioned operations to obtain the GPU utilization time-series value and the task output hash verification result. Furthermore, during the execution of computing power task requests by computing power nodes, their actual operating status may undergo unpredictable changes. For example, GPU utilization may experience abnormal fluctuations, such as significant short-term volatility. Alternatively, the task output hash may deviate from expectations due to computing power node calculation errors, task tampering, or malicious occupation. These abnormal behaviors significantly increase the risk of task failure or default. Therefore, to ensure that the update of computing power node health is both sensitive and smooth, and to provide accurate basis for subsequent dynamic staking adjustments and circuit breakers, further, as an optional implementation method, refer to... Figure 5 As shown, Figure 5 This is a flowchart illustrating the process of determining the current health of a computing node based on GPU utilization time-series values ​​and the hash verification results of the task output. Step S410 specifically includes: In step S510, the abnormal jitter coefficient is determined based on the GPU utilization timing value.

[0067] In step S520, a failure penalty factor is determined based on the task output hash verification result.

[0068] In step S530, the negative health impact value of the current time slice is determined based on the abnormal jitter coefficient, the failure penalty factor and its corresponding weight.

[0069] In step S540, the node health of the previous time slice is updated by exponential weighted smoothing using the negative health impact value to obtain the current health of the computing power node.

[0070] After obtaining the GPU utilization time series values, the variance or maximum rate of change of the time series data can be calculated. For example, with ten sampling points, the absolute value of the difference between the GPU utilization of two adjacent sampling points can be calculated sequentially, and the maximum value of these differences can be taken. Alternatively, the root mean square error of all sampling points can be calculated and used as the jitter level value. The calculated jitter level value is then mapped to a value between 0 and 1 to obtain the abnormal jitter coefficient. Here, 0 represents complete stability, and 1 represents extreme jitter.

[0071] For each computing node executing a computing task request, a consecutive output hash verification failure counter is maintained corresponding to that computing node. If the task output hash verification result for the current time slice fails, the counter is incremented by one. If the result passes, the counter is reset to zero. Subsequently, a failure penalty factor is calculated based on the number of consecutive failures, such as dividing the number of consecutive failures by a preset failure threshold to obtain the failure penalty factor.

[0072] After obtaining the abnormal jitter coefficient and failure penalty factor, the jitter coefficient can be multiplied by its corresponding weight to obtain the jitter contribution value, and the failure penalty factor can be multiplied by its corresponding weight to obtain the failure contribution value. The sum of the jitter contribution value and the failure contribution value is used as the negative health impact value. Finally, using the node health of the computing node in the previous time slice, the negative health impact value in the current time slice, and the preset smoothing factor, the current health of the computing node is calculated. That is, the difference between 1 and the negative health impact value is used as the instantaneous health of the computing node in the current time slice. Then, the current health is calculated using the exponential weighted moving average formula, that is, current health = node health of the computing node in the previous time slice × (1 - smoothing factor) + instantaneous health × smoothing factor.

[0073] In this embodiment, by obtaining the GPU utilization time-series value and task output hash verification result from the trusted lexical generation certificate, and calculating the abnormal jitter coefficient and failure penalty factor respectively, the real-time operating status of the computing power node can be comprehensively captured from two independent dimensions: resource utilization stability and task execution correctness. The abnormal jitter coefficient reflects whether the computing power node experiences drastic fluctuations in utilization caused by non-task factors, a typical sign of computing power node failure, computing power fraud, or resource preemption. The failure penalty factor directly measures whether the computing power node outputs the correct result as agreed; consecutive failures indicate that the computing power node may be maliciously occupying resources or has algorithmic errors. The two are weighted and fused to obtain a negative health impact value, and an exponentially weighted smoothing method is used to update the health status. This ensures that the health status remains sensitive to sudden anomalies while avoiding misjudgments caused by occasional noise through the smoothing effect of historical states, thus achieving accurate tracking of the health trend of the computing power node. The current health level, thus determined, serves as the core basis for dynamic staking updates. This allows the staking coefficient to adjust in real-time according to the actual performance of the computing power nodes. Specifically, when the health level decreases, the staking coefficient automatically increases, requiring more token locks to cover the increased risk; conversely, when the health level recovers, the staking coefficient decreases accordingly, releasing excess funds to improve utilization efficiency. This mechanism completely eliminates reliance on software logs or manual reports, relying entirely on immutable data signed by hardware trust roots. This ensures the objectivity and credibility of the health level assessment, providing a solid and reliable risk quantification foundation for subsequent dynamic staking, supplementary staking triggers, and circuit breaker decisions. This significantly enhances the risk adaptability and fund security of the decentralized computing power trading system.

[0074] In step S440, a new number of pledged terms is calculated using the current pledge coefficient.

[0075] In step S450, if the new number of staked tokens is greater than the initial number of staked tokens, an on-chain request is sent to the requester so that the requester can complete the replenishment of the excess tokens within a preset time period.

[0076] In step S460, if the requester fails to complete the excess term locking within the preset time period, a level 3 circuit breaker is triggered, and the computing power node is controlled to terminate the execution of the computing power task request.

[0077] After obtaining the current health status of the computing power nodes, the current network congestion index can be read from the on-chain consensus layer. Then, the current staking coefficient can be calculated using the current health status, the current network congestion index, the preset coefficient corresponding to the computing power task request, and formula (1), that is:

[0078] A preset coefficient corresponding to the computing power task request. Current health status The current network congestion index, This represents the risk weight coefficient obtained by fitting historical data.

[0079] Formula (1) is a general linear weighted model in the field of risk pricing and credit risk control. It conforms to the well-known engineering principle that risk and pledge amount are positively correlated and can be obtained by fitting and training through historical transaction data.

[0080] When calculating and determining the number of staking terms using the current staking coefficient, the corresponding initial baseline number of staking terms can be determined based on the task specifications of the computing power task request. The product of the initial baseline number of staking terms and the current staking coefficient is used as the new number of staking terms, that is, the initial baseline number of staking terms corresponding to the computing power task request is determined; the product of the initial baseline number of staking terms and the current staking coefficient is used as the new number of staking terms.

[0081] After obtaining the new number of staked tokens, if the current time slice is the first time slice, the difference between the new number of staked tokens and the initial number of staked tokens is determined. If this difference is greater than 0, the smart contract is invoked to initiate an on-chain supplementary staking request to the requesting account, requiring it to lock additional tokens within a preset time period. Conversely, if the current time slice is not the first time slice, and in actual practice, token supplementation operations have already been performed for the initial number of staked tokens, then the new number of staked tokens is compared with the total amount of staking currently locked on-chain. If the new number of staked tokens is greater than the total amount of staking currently locked on-chain, the difference between the new number of staked tokens and the total amount of staking currently locked on-chain is determined, and the smart contract is invoked to initiate an on-chain supplementary staking request to the requesting account, requiring it to lock additional tokens within a preset time period.

[0082] After sending an on-chain request to the requester, if a valid token supplement and lock are received from the requester before the timeout, the total amount of staked tokens currently locked on-chain is updated, and the computing power node is invoked to continue executing the computing power task request. If no valid token supplement and lock are received from the requester before the timeout, a level 3 circuit breaker is triggered, and the computing power node is controlled to terminate the execution of the computing power task request. After the level 3 circuit breaker is triggered, the smart contract can be invoked to deduct a predetermined percentage of the default penalty from the total amount of staked tokens according to the preset default penalty, and the remaining total amount of staked tokens is unpressurized and returned to the requester. At the same time, an on-chain default certificate is generated, and the requester's credit score is updated.

[0083] For example, the AI ​​agent automatically initiates a short-term GPU inference task, submitting the task specifications and computing power requirements. The submitted GPU inference task is analyzed to determine the task specifications, and the dynamic staking amount is calculated based on the preset health level and network congestion index to complete the on-chain locking of the token. Subsequently, a high-availability computing power node is allocated to the GPU inference task, TEE hardware intrinsic monitoring is started, and trusted token production certificates are generated and uploaded in real time. During the execution of the GPU inference task by the computing power node, the TEE probe detects abnormal fluctuations in the GPU utilization time series curve, and the node health score drops from 95 points to 72 points in real time. Based on formula (1), the staking coefficient is adjusted from 1.2 to 1.45, and a timely warning for supplementing the staking amount is initiated through the smart contract. The agent automatically responds and completes the supplementary staking within 3 seconds, and the task resumes normal operation without interruption. When the trusted token production certificate for each current time slice is received, the computing power measurement value in the trusted token production certificate is converted into token consumption, and millisecond-level continuous deduction is performed. When the GPU inference task is completed ahead of schedule, the smart contract is invoked to automatically trigger the settlement process, completing token liquidation, staking and unstaking, and balance return. Finally, all data from the entire process is uploaded to the blockchain for notarization, computing resources are automatically released, and the process loop ends.

[0084] In this embodiment, after obtaining a trusted token output certificate, the current health of the computing node is determined by using the GPU utilization time-series value and task output hash verification result, and the current network congestion index is obtained. This allows for real-time capture of the deterioration trend of node execution status and the congestion level of the on-chain environment. Then, the current staking coefficient is calculated using the current health, network congestion index, and preset coefficients to obtain a new number of staked tokens. This achieves dynamic matching between the staking amount and the actual risk level, avoiding excessive capital occupation or insufficient risk coverage caused by static staking. When the new number of staked tokens exceeds the currently locked amount, an on-chain supplementary staking request is automatically sent to the requester, requiring them to complete the excess token locking within a preset time period. This mechanism proactively guarantees future risks, ensuring that the total amount of staked tokens at any time is not less than the token amount required based on the latest risk assessment. If the requester fails to complete the supplementary locking within the specified time, a three-level circuit breaker is immediately triggered, and the task is forcibly terminated, thereby stopping losses in a timely manner when the requester's performance capacity is insufficient, preventing further risk escalation. Therefore, this embodiment significantly reduces the risk of financial loss due to declining computing power node health or network congestion through a closed-loop design of continuous risk monitoring, dynamic collateral adjustment, and timeout circuit breaker. It improves the robustness and financial security of the computing power trading system, while also prompting requesters to maintain good performance behavior, thus achieving an organic unity of risk control and financial efficiency in the decentralized computing power market.

[0085] It should be noted that during the execution of computing power task requests, computing power nodes may malfunction for various reasons. For example, they may falsely report computing power or have idle tasks leading to low resource utilization; network failures or crashes may cause node disconnection; tasks may be tampered with or executed incorrectly, resulting in failed hash verification of task outputs; or even maliciously occupying computing power to perform non-standard computations. If these are handled uniformly without differentiation, normal fluctuations may be inadvertently affected, or responses to serious anomalies may be delayed. Therefore, to ensure the interests of the requester and the correct execution of computing power task requests, further, as an optional implementation method, refer to... Figure 6 As shown, Figure 6 This is a flowchart illustrating the tiered circuit breaker triggering process. After step S130, it also includes: In step S610, if the GPU utilization rate in the trusted token production credentials of multiple consecutive time slices after the current time slice is lower than a preset threshold, a first-level circuit breaker is triggered and an alarm is output.

[0086] In step S620, if no trusted word element production certificate corresponding to a consecutive preset number of time slices is obtained after the current time slice, or if the task output hash verification result in the trusted word element production certificate corresponding to the time slice fails, a second-level circuit breaker is triggered, and the metering and billing of the computing power node are suspended. The computing power task request is then migrated to a standby computing power node so that the standby computing power node can execute the computing power task request.

[0087] In step S630, if the task output hash verification result in the trusted token production certificate corresponding to a consecutive preset number of time slices fails after the current time slice, a three-level circuit breaker is triggered, and the computing power node is controlled to terminate the execution of the computing power task request, and a preset number of tokens are deducted from the initial number of pledged tokens.

[0088] Specifically, if a reliable token output certificate is received within the time slice window following the current time slice, the count of consecutive unreceived reliable token output certificates will be reset to zero; if no reliable token output certificate is received, the count of consecutive unreceived reliable token output certificates will be incremented by one.

[0089] Upon receiving a trusted token output certificate, the task output hash verification result and GPU utilization time series value are read from the trusted token output certificate, and the average GPU utilization is calculated. If the task output hash verification result is successful, the consecutive task output hash verification failure count is reset to zero; if the task output hash verification result is unsuccessful, the consecutive task output hash verification failure count is incremented by one. If the average GPU utilization is less than the corresponding preset threshold, the consecutive low utilization count is incremented by one; if the average GPU utilization is not less than the corresponding preset threshold, the consecutive low utilization count is reset to zero.

[0090] If the number of consecutive unreceived trusted meta output certificates is less than the preset threshold, and the task output hash verification result in the trusted meta output certificate corresponding to the time slice is passed, but the consecutive low utilization count is greater than the corresponding preset threshold, then a level one circuit breaker will be triggered, and an alarm will be output, but the task execution will not be interrupted, nor will the metering and billing be suspended.

[0091] If the count of continuously unreceived trusted token output certificates exceeds a preset threshold, or if the task output hash verification result in the trusted token output certificate corresponding to any time slice fails, a level two circuit breaker is triggered. In this case, token deduction for subsequent time slices of the computing power node is stopped, the computing power node is marked as abnormal, and a healthy backup computing power node is selected from the computing power node pool according to the aforementioned computing power node allocation process. The execution progress, intermediate data, and remaining input data of the computing power task request are packaged and sent to the backup computing power node through a trusted channel. The hardware trust root of the backup computing power node establishes a new encrypted channel and continues execution from the current progress. At the same time, the computing power node identifier associated with the computing power task request is updated to the backup computing power node, and metering and billing are restored.

[0092] If the hash verification failure count of consecutive tasks exceeds a preset threshold, a forced termination command is sent to the computing power node. The node's hardware root of trust stops monitoring and releases resources. The smart contract is invoked to deduct a predetermined percentage of the total staked amount as a penalty, such as 20% or a fixed number of tokens, from the total staked amount for that computing power task request. This penalty is transferred to the computing power provider as compensation. If there are any remaining staked tokens after deducting the penalty, they are released and returned to the requesting party. Simultaneously, the computing power task request status is set to "Terminated Due to Default," and no further migration or recovery is permitted.

[0093] If neither the consecutive receipt count nor the consecutive hash failure count reaches the corresponding preset threshold, the task continues to execute normally and enters the voucher generation and deduction process for the next time slice.

[0094] To facilitate a better understanding of this embodiment, a specific example is provided below: For Level 1 and Level 2 circuit breakers: Enterprises submit applications for 4-hour live streaming GPU elastic computing power, specifying computing power specifications and required protection levels. Based on highly reliable computing nodes, low-risk staking coefficients are generated, and staking token locking is completed. During task execution, the TEE monitors computing power utilization in real time. If the utilization rate consistently falls below the threshold, a Level 1 circuit breaker alarm is triggered. If the abnormal situation persists without improvement, a Level 2 circuit breaker is automatically triggered, suspending metering and billing for the current period and seamlessly switching the task to a backup computing node. After the task is successfully completed, the smart contract automatically completes settlement, staking and unstaking, and fee clearing, all without human intervention or transaction disputes.

[0095] For Level 3 circuit breakers: A user leases a designated computing node but executes a high-load computing program without authorization. TEE hardware monitoring detects that the task output does not match the agreed requirements, and output verification fails repeatedly, indicating malicious misuse. At this point, a level-three circuit breaker is immediately triggered, forcibly terminating the task, cutting off the computing power supply, and invoking the smart contract to automatically deduct 20% of the fully pledged amount as a penalty, completing the settlement. Simultaneously, the breach and its resolution are fully recorded on the blockchain for evidence storage, and the user's performance record is updated synchronously, completing the closed-loop process.

[0096] In this embodiment, by triggering a level 1 circuit breaker and outputting an alarm when the GPU utilization rate of multiple consecutive time slices after the current time slice is lower than a preset threshold, it is possible to promptly detect insufficient computing power node performance or wasted computing power without interrupting the task, providing early warning information to operation and maintenance personnel and preventing small problems from escalating into major failures. When no trusted token output certificate is received for a consecutive preset number of time slices or the task output hash verification result in the trusted token output certificate fails, a level 2 circuit breaker is triggered and the metering and deduction of the original computing power node are immediately suspended. At the same time, the task is migrated to a backup computing power node. This not only prevents continued payment for invalid or erroneous calculations but also ensures the continuity of the task and the correctness of the output results, significantly reducing the task failure rate caused by computing power node disconnection or output errors. Furthermore, when the task output hash verification results of multiple consecutive time slices all fail, a level 3 circuit breaker is triggered and the task is forcibly terminated. At the same time, a preset number of tokens are deducted from the initial pledged tokens as a penalty for breach of contract. This not only punishes malicious occupation of computing power or false execution but also suppresses the motivation for breach of contract through an economic penalty mechanism, protecting the legitimate rights and interests of the computing power provider. Through a three-tiered circuit breaker design, this embodiment achieves accurate identification and differentiated handling of anomalies of different degrees. While ensuring reliable task execution, it minimizes unnecessary task interruptions and financial losses, significantly improving the robustness, security, and automated risk management capabilities of the decentralized computing power trading system.

[0097] The following is a test example provided in this embodiment: Testing under tens of thousands of concurrent and mixed failure scenarios: 1. Basic testing environment: Deploy 500 heterogeneous GPU computing nodes to simulate 10,000 concurrent elastic leasing tasks being launched at the same time, fully simulating the typical pressure and security challenges faced by a medium-sized public cloud platform; 2. Extreme scaling test: Further simulate 100,000 concurrent tasks on the basic scenario to verify the system's extreme carrying capacity; 3. Stress test: The system completes the dynamic staking calculation and on-chain locking of all tasks within 5 minutes. The peak TPS in the basic scenario reaches 2000, and the TPS in the extreme scenario is stable at 3000+. The system runs without any lag or delay. 4. Hybrid Fault Injection: a. Randomly assign 10% of the computing power nodes to forge high GPU utilization data through the software layer to simulate a computing power fraud attack. Result: All forged data was directly rejected by the TEE hardware signature verification process, the corresponding computing power contribution was recorded as 0, no related staking was required, and the attack was completely ineffective.

[0098] b. Simulate a 30-second momentary network outage affecting 5% of the computing power nodes to simulate network fluctuations and failures. Result: The system automatically triggers a level 2 circuit breaker, suspends billing for the outage period, seamlessly switches tasks to backup computing power nodes, and after the out-of-connection computing power nodes recover, the invalid load is not included in the token consumption.

[0099] c. Simulate 1% of tasks maliciously consuming computing power and performing non-conventional calculations. Result: TEE output verification fails continuously, triggering a level 3 circuit breaker within 2 minutes, and the smart contract automatically deducts the corresponding penalty.

[0100] 5. Test Results: The entire process was conducted without human intervention, achieving 100% settlement accuracy. Fund and resource status remained globally consistent, and the dispute rate was 0, demonstrating that the architecture of this embodiment fully possesses the core technical capabilities to support a commercial computing power leasing platform. Compared to traditional solutions employing static staking, software monitoring, and oracle settlement, the method proposed in this embodiment, under the same test scenario, reduces staking capital occupation by 65%, increases risk control accuracy to 99.9%, and achieves a settlement dispute rate of 0%.

[0101] The following is a description of the traditional solution: Comparative Example A (Removing dynamic pledging and adopting static pledging): Using a fixed pledging amount increases the capital utilization rate by more than 40%, and the default risk cannot be dynamically managed, making it impossible to achieve large-scale commercial implementation.

[0102] Comparative Example B (removing TEE hardware credibility measurement and adopting software monitoring): computing power consumption data is easily forged by software, the dynamic risk model input is distorted, the staking risk control is completely ineffective, and the settlement results have no credibility.

[0103] Comparative Example C (no atomic settlement, using traditional step-by-step settlement): In high-concurrency scenarios, inconsistencies arise such as computing power being consumed but word units not being deducted, and pledges being deducted but computing power not being delivered, leading to chaotic accounts and a surge in transaction dispute rates.

[0104] Comparative example D (only TEE trusted measurement, no dynamic staking + atomic settlement): It only realizes trusted monitoring of computing power, but cannot complete risk control and automated settlement. The value of computing power cannot be circulated and has no practical industrial application value.

[0105] Comparative example E (dynamic staking only, no TEE trusted measurement + atomic settlement): the staking data has no trusted source, the risk control is completely ineffective, there is no unified settlement basis, it is extremely vulnerable to attacks, and it cannot operate stably.

[0106] Comparative example F (only atomic settlement, no TEE credibility measurement + dynamic staking): Settlement data lacks credibility support, there is no dynamic risk management, the transaction default rate is extremely high, and it is impossible to build a complete computing power trading system.

[0107] In this example, based on the test results of tens of thousands of concurrent and mixed failure scenarios and the comparative analysis of comparative examples A to F, this embodiment deploys 500 heterogeneous GPU computing power nodes and simulates 10,000 concurrent elastic leasing tasks. It completes the dynamic staking calculation and on-chain locking of all tasks within 5 minutes. The peak TPS in the basic scenario reaches 2,000, and the TPS in the extreme scenario is stable at 3,000+ with no lag or delay. This proves that the system has the high concurrency processing capability required to support a commercial computing power leasing platform. In the hybrid fault injection test, when 10% of nodes were randomly assigned to forge high GPU utilization data through the software layer, all forged data was directly rejected by the TEE hardware signature verification process. The corresponding computing power contribution was recorded as zero and the relevant staking did not need to be replenished, indicating that the trusted token production certificate mechanism with the hardware trust root as the sole data source can 100% intercept computing power forgery attacks. When 5% of the computing power nodes experienced a momentary network disconnection for 30 seconds, a level 2 circuit breaker was automatically triggered, suspending billing for the disconnection period and seamlessly switching tasks to backup computing power nodes. After the disconnected computing power nodes recovered, the invalid load was not included in the token consumption, indicating that the circuit breaker and migration mechanism based on trusted certificates can effectively cope with network fluctuation faults and ensure billing accuracy and task continuity. When 1% of the tasks maliciously occupied computing power to perform non-contractual calculations, the TEE output verification failed continuously and triggered a level 3 circuit breaker within 2 minutes. The smart contract automatically deducted the corresponding penalty, proving that the output hash verification and level 3 circuit breaker mechanism can promptly identify and punish malicious behavior. As can be seen from Comparisons A through F, removing dynamic staking (Comparison A) leads to a more than 40% increase in capital occupancy and uncontrolled default risk; removing TEE hardware trust measurement (Comparison B) renders staking risk control completely ineffective; removing atomic settlement (Comparison C) causes account chaos and a surge in dispute rates; and retaining only a single dimension (Comparisons D, E, and F) cannot form a complete and trustworthy transaction system. This embodiment, however, couples trust measurement, dynamic staking, and atomic settlement in a closed loop based on the same source of trusted data. Under the same test scenario, it achieves a 65% reduction in staking capital occupancy, a 99.9% increase in risk control accuracy, and a 0% settlement dispute rate—a quantitative improvement in technology. This demonstrates that this embodiment uses the trusted token output certificate generated by the hardware trust root as the sole data source, driving seamless collaboration between dynamic staking and atomic settlement. It fundamentally solves the technical challenge of balancing trust, efficiency, and automation in the decentralized computing power market, significantly improving the security, fairness, and system scalability of computing power transactions, and providing a reliable technical foundation for building a large-scale commercial computing power value network.

[0108] Meanwhile, this embodiment also provides an electronic device, referring to Figure 7 As shown, Figure 7 This is a schematic diagram of the structure of an electronic device, which includes: One or more processors; A memory having stored one or more computer programs that, when executed by one or more processors, cause the one or more processors to implement the computing power processing method according to the first aspect of the invention.

[0109] The electronic device may also include one or more I / O interfaces connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0110] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the first memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, enabling information exchange between the processor and the memory, including but not limited to the data bus (Bus).

[0111] In some embodiments, the processor, memory, and I / O interfaces are interconnected via a bus, and thus connected to other components of the computing device.

[0112] As a third aspect of the present invention, a computer-readable medium is provided, with reference to Figure 8 As shown, Figure 8 This is a schematic diagram of a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the computing power processing method provided in the first aspect of this disclosure.

[0113] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. Accordingly, the computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can implement the methods of any of the above embodiments. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0114] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that the present invention includes, but is not limited to, the contents described in the accompanying drawings and the specific embodiments above. Any modifications that do not depart from the functional and structural principles of the present invention will be included within the scope of the claims.

Claims

1. A computing power processing method, characterized in that, include: In response to a computing power task request, an initial number of staked tokens corresponding to the requester of the computing power task request is generated, and the corresponding number of tokens in the requester's account is locked on-chain based on the initial number of staked tokens. Invoke the computing power node to execute the computing power task request; During the execution of the computing power task request by the computing power node, a trusted word element production certificate corresponding to the current time slice is obtained; wherein, the trusted word element production certificate is a structured trusted certificate containing computing power measurement value generated by the hardware trust root within the computing power node. Based on the computing power measurement value in the trusted word element production certificate, the currently consumed word element is determined; Based on the currently consumed tokens, the corresponding tokens are deducted from the requester's account until the computing power node terminates the execution of the computing power task request. In the case that the computing power node terminates the execution of the computing power task request, the locked initial staked tokens are deducted and released. The trusted token output certificate includes GPU utilization time series value and task output hash verification result. The task output hash verification result is the comparison result between the hash value of the output data actually generated by the actual execution of the computing power task request in the current time slice and the preset expected output hash value corresponding to the current time slice, which is pre-loaded in the hardware trust root isolated storage area. After obtaining the trusted word token output certificate corresponding to the current time slice, the method further includes: Based on the GPU utilization time series value and the task output hash verification result, the current health of the computing node is determined. Get the current network congestion index; The current staking coefficient is determined using the current health status, the current network congestion index, and a preset coefficient corresponding to the computing power task request; Calculate the new number of pledged terms using the current pledge coefficient; If the new number of staked tokens is greater than the initial number of staked tokens, an on-chain request is sent to the requester so that the requester can complete the replenishment of the excess tokens within a preset time period. If the requesting party fails to complete the excess token locking within the preset time period, a level 3 circuit breaker is triggered, and the computing power node is controlled to terminate the execution of the computing power task request.

2. The method according to claim 1, characterized in that, The step of determining the current health of the computing node based on the GPU utilization time-series value and the task output hash verification result includes: The abnormal jitter coefficient is determined based on the GPU utilization timing value; The failure penalty factor is determined based on the hash verification result of the task output. Based on the abnormal jitter coefficient, the failure penalty factor and its corresponding weight, the negative health impact value of the current time slice is determined; The current health of the computing power node is obtained by using the negative health impact value to perform an exponentially weighted smooth update of the node health in the previous time slice.

3. The method according to claim 1, characterized in that, The formula for calculating the current staking coefficient is as follows: （1）， This represents the current pledge coefficient. This represents a preset coefficient corresponding to the computing power task request. Indicates the current health status, This indicates the current network congestion index. , This represents the risk weight coefficient obtained by fitting historical data.

4. The method according to claim 1, characterized in that, The step of calculating the new number of pledged terms using the current pledge coefficient includes: Determine the initial base number of staked terms corresponding to the computing power task request; The product of the initial base number of staked terms and the current staked coefficient is used as the new number of staked terms.

5. The method according to claim 1, characterized in that, After obtaining the trusted word token output certificate corresponding to the current time slice, the method further includes: If, after the current time slice, the GPU utilization rate in the trusted token production credentials of multiple consecutive time slices is lower than a preset threshold, a first-level circuit breaker is triggered and an alarm is output. If, after the current time slice, no trusted word element production certificate corresponding to a consecutive preset number of time slices is obtained, or if the task output hash verification result in the trusted word element production certificate corresponding to the time slice fails, a second-level circuit breaker is triggered, and the metering and billing of the computing power node are suspended. The computing power task request is then migrated to a standby computing power node so that the standby computing power node can execute the computing power task request. If, after the current time slice, the task output hash verification result in the trusted token production certificate corresponding to a consecutive preset number of time slices fails, a level 3 circuit breaker is triggered, and the computing power node is controlled to terminate the execution of the computing power task request, and a preset number of tokens are deducted from the initial number of pledged tokens.

6. The method according to claim 1, characterized in that, The step of deducting and releasing the locked initial staking terminology when the computing power node terminates the execution of the computing power task request includes: If the computing power node terminates the execution of the computing power task request, the total number of words to be deducted shall be determined based on the computing power measurement value in the trusted word production certificate corresponding to each time slice. Determine the total number of deducted tokens in real time for the computing power request task; If the total number of deductible words is greater than the total number of words deducted in real time, the difference in deductible words is determined. Based on the deducted token difference, a corresponding number of tokens are deducted from the locked initial staked token count, and the remaining initial staked tokens are decompressed and returned to the requester.

7. The method according to claim 1, characterized in that, The step of invoking the computing power node to execute the computing power task request includes: The computing power task request is parsed to obtain the GPU model, minimum video memory capacity, and minimum node health threshold corresponding to the computing power task request. Select the computing power nodes in the computing power node pool whose current number of tasks is less than the maximum concurrency and whose hardware trust root is normal as candidate nodes; The candidate nodes are filtered based on the GPU model, the minimum video memory capacity, and the minimum node health threshold to obtain new candidate nodes; Obtain the current health, historical fulfillment rate, historical network latency rate, and current load of the new candidate node; A node score is determined based on the current health status, the historical fulfillment rate, the historical network latency rate, and the current load and its corresponding weight. The new candidate node with the highest node score is selected as the target computing power node. The target computing node is invoked to execute the computing task request.

8. An electronic device, characterized in that, include: One or more processors; A memory having stored one or more computer programs thereon, which, when executed by the one or more processors, cause the one or more processors to implement the computing power processing method according to any one of claims 1 to 7.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the computing power processing method according to any one of claims 1 to 7.

Images