A Distributed AI Computing Power Resource Trading, Settlement, and Arbitration Method and System Based on OPC UA Smart Agent Consortium Chain

Abstract

The application relates to a distributed AI computing resource transaction, settlement and arbitration method and system based on an OPC UA intelligent body alliance chain, which takes an OPC UA variable NodeID as a unique state anchor point of a computing resource token, fuses and deploys an OPC UA server and an alliance chain consensus node, and takes an OPC UA intelligent body as a chain agent entity. AI computing resources are assetized into computing resource tokens which are uniquely bound with OPC UA variables. An OPC UA server certificate private key is used for application layer signature of a computing state, a timestamp and SLA evidence, and an arbitration contract verifies an industrial standard identity, a timestamp sequence and SLA evidence by using a certificate directory contract public key, so that automatic transaction, settlement and arbitration are realized. The application distinguishes computing resource tokens from computing settlement vouchers, reduces state synchronization delay, and improves arbitration credibility.

Description

Technical Field

[0001] This invention relates to the field of industrial internet and blockchain technology, specifically to a cross-plant distributed AI computing power resource trading, settlement and arbitration scheme based on OPC UA communication standard and consortium blockchain technology. Background Technology

[0002] Existing cross-plant computing power trading solutions typically rely on centralized platforms, independent gateways, or general-purpose blockchain trading platforms. If industrial system data is forwarded to the blockchain solely through a gateway, it introduces risks such as protocol conversion delays, state mapping errors, and single points of tampering. Furthermore, it is difficult to guarantee the consistency between the on-chain computing power resource status and the OPC UA variable status in the industrial field.

[0003] The main limitations of existing solutions include the following: Centralized computing power trading platforms rely on platform logs as arbitration evidence, which can be tampered with by the platform, resulting in low credibility in dispute resolution. Gateway-forwarded blockchain on-chain solutions map OPC UA variables to on-chain data via a gateway, leading to inconsistent state sources and high protocol conversion latency. General consortium blockchain computing power trading solutions do not bind to industrial field variables, and the on-chain asset status cannot reflect the field load in real time. Ordinary OPC UA data storage solutions only store historical data, lacking transaction custody and arbitration, and cannot support automated computing power trading and default handling. Cross-chain oracle computing power trading solutions rely on oracles to collect off-chain computing power status, and the oracles themselves may become a trust bottleneck and a source of latency.

[0004] Existing technical document CN116797364A discloses an edge computing cross-chain computing power trading method based on oracles, focusing on consortium chains and cross-chain computing power trading, but does not disclose the native binding mechanism between computing power resources and industrial site OPC UA variables.

[0005] Existing technical document US10819722 discloses a scheme for storing private blockchains in the OPC UA address space, but it mainly implements industrial data notarization and does not involve computing power resource tokens, dynamic anchoring and automatic arbitration.

[0006] Other existing solutions connect OPC variables to the blockchain via relay services and issue tokens for control permissions or data storage, but do not directly anchor the computing power resource token status to the OPC UA variable node, nor do they use the timestamp of the OPC UA server certificate signature as SLA arbitration evidence. Summary of the Invention

[0007] This invention addresses the technical problems of incompatibility between existing cross-plant computing power transactions and the OPC standard, high latency in computing power status synchronization, low credibility of arbitration evidence, and insecure cross-domain communication. Specifically, this invention aims to solve the following technical problems: the on-chain computing power asset status cannot natively correspond to industrial site OPC UA variables; gateway forwarding leads to incorrect state mapping and protocol conversion delays; centralized platform logs are easily tampered with as arbitration evidence; cross-plant computing power transactions lack an automatic verification mechanism based on industrial standard identities; frequent updates to computing power resource status lead to excessive on-chain transaction overhead; and there is a lack of enforceable on-chain protection rules in situations such as abnormal clocks, expired certificates, and replay attacks.

[0008] The technical solution adopted by this invention to solve its technical problem is:

[0009] This paper proposes a distributed AI computing power resource trading, settlement, and arbitration method and system based on OPC UA intelligent agent consortium blockchain.

[0010] By integrating OPC UA servers with consortium blockchain nodes, the computing resource variables in the OPC UA address space become the source of the on-chain computing resource token's corresponding state. After reading the on-chain variables, if the change exceeds a threshold, the OPC UA smart agent submits the new state, the timestamp generated by the OPC UA server clock, and the signature data signed by the server certificate's private key to the smart contract. The demand side locks the computing power settlement certificate through the smart contract, and the supply side uploads SLA evidence after executing the AI ​​task. The arbitration smart contract uses the corresponding public key in the certificate directory contract to verify the industrial timestamp signature and the SLA evidence signature, and automatically executes transaction release or default processing based on the SLA terms.

[0011] The core inventive concept of this invention is organized around the following technical chain:

[0012] OPC UA variables in the industrial field are natively bound to computing power resource tokens via NodeID, and then enter the local reading and signing process of the fusion node to achieve dynamic on-chain token anchoring. Subsequently, the execution of AI tasks by the supplier is triggered through cross-factory task requests and settlement voucher custody. After the task is completed, SLA evidence is generated and signed on the chain. The arbitration contract verifies the industrial timestamp and SLA logic, and finally completes the automatic release or default handling.

[0013] In this technology chain, the NodeID, a variable node in the OPC UA address space, serves as the unique state anchor for on-chain industrial computing power resources. The OPC UA server and consortium blockchain consensus nodes are deployed in the same trusted equipment, edge gateway, or container within the same industrial plant, enabling on-site variable states to directly drive on-chain token state updates via local communication mechanisms. The OPC UA server certificate private key performs application-layer signing of the computing power state, industrial timestamps, and SLA evidence. The consortium blockchain smart contract uses the corresponding public key in the certificate directory contract to verify the industrial standard identity, timestamp order, and SLA evidence integrity, thereby completing computing power transaction custody and automatic arbitration.

[0014] In terms of system implementation, this invention can employ a consortium blockchain platform that supports smart contracts, such as Hyperledger Fabric, FISCO BCOS, Hyperledger Besu, Ethereum Enterprise Edition, or other permissioned blockchain platforms. The consensus mechanism can employ Practical Byzantine Fault Tolerance (PBFT), IBFT, Raft, or other consensus algorithms suitable for industrial consortium blockchains. Smart contracts can be executed using chaincode, Solidity contracts, WASM contracts, or other contract execution methods. The OPC UA smart agent can interact with consortium blockchain nodes through the blockchain node SDK, JSON-RPC, gRPC, local message bus, or same-machine process call interfaces.

[0015] OPC UA server certificates, cross-domain communication certificates, and corresponding private keys can be stored in hardware security modules (HSM), trusted execution environments (TEE), PKCS#11 keystores, or key containers protected by the operating system to ensure the feasibility of implementing industrial key security requirements.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0017] The synchronization latency of computing power status has been reduced from hours to no more than 10 seconds; the success rate of cross-factory computing power transaction authentication has increased from 80% to 100% under test conditions; the transaction settlement cycle has been shortened from several days to 8 minutes, and the arbitration cycle has been shortened from several weeks to 10 minutes; the removal rate of illegal timestamp evidence in the test sample has reached 100%; the solution is compatible with the requirements of OPC UA specification Part 3, Part 4, and Part 6, which can reduce the dependence on the modification of existing industrial site OPC UA device protocol stacks and data models. Through native NodeID binding, the risk of asset anchor point disorder caused by variable renaming, namespace adjustment, or gateway mapping table errors can be reduced; through OPC UA server certificate signature timestamps, the arbitration trust root can be transferred from the central platform log to the industry standard certificate system; through dynamic anchoring thresholds and anti-replay fields, a balance can be achieved between real-time status and on-chain transaction overhead. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be further described below in conjunction with the accompanying drawings and embodiments. The drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort:

[0019] Figure 1 This is a schematic diagram of the fusion architecture of consortium blockchain nodes and OPC UA smart agents according to an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram illustrating the binding relationship between computing power resource tokens and OPC UA variables in an embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of the smart contract transaction process according to an embodiment of the present invention;

[0022] Figure 4 This is a schematic diagram of the automatic arbitration process according to an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, a clear and complete description will be provided below in conjunction with the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the protection scope of the present invention.

[0024] Terminology Explanation:

[0025] In this invention, "OPC" refers to the industry standard OPC UA, which is short for OPC Unified Architecture, and has nothing to do with the meaning of "One Person Company".

[0026] In this invention, the “OPC UA intelligent agent” or “OPC UA on-chain agent module” refers to an on-chain agent entity deployed on the OPC UA server side, in the OPC UA server process, or in a container deployed on the same machine. It is not equivalent to an artificial intelligence dialogue entity, nor is it equivalent to a natural person entity.

[0027] In this invention, "intelligent agent" refers to an industrial software agent module or an on-chain agent entity, which is not the same as an artificial intelligence chatbot or a natural person.

[0028] This invention distinguishes between two types of on-chain objects. The first type is a computing power resource token, which is uniquely bound to a specific OPC UA variable node NodeID, representing the available AI computing power resources and their real-time status for a particular factory area, device, or computing power type. The second type is a computing power settlement certificate, a general settlement token used in the consortium blockchain for the custody, pricing, and release of computing power transactions. In this embodiment, "AIC" is used as an example of the settlement certificate unit. The computing power settlement certificate is distinct from the computing power resource token and does not represent a direct binding relationship to a specific OPC UA variable.

[0029] The terms "computing power trading" and "computing power token" in this invention are further subdivided into computing power resource token binding, computing power settlement certificate custody and release in specific implementations.

[0030] The network address, TokenID, threshold, price formula, and test data in the following embodiments are specific implementation examples given for ease of understanding and should not be regarded as the sole interpretation of the technical features of the present invention.

[0031] 1. System Overall Architecture Implementation Example

[0032] refer to Figures 1-4 This embodiment takes two industrial plants as examples, namely the East China plant and the North China plant. Each plant deploys a converged node, which includes an OPC UA server, a consortium blockchain node, AI computing resources such as GPU / CPU / memory, a local certificate repository, an OPC UA agent, and a certificate management module.

[0033] The OPC UA server exposes on-site computing resource variables. Consortium blockchain nodes serve as blockchain consensus nodes and smart contract execution environments. A local certificate repository stores OPC UA server certificates, cross-domain communication certificates, and trusted CA root certificates. The OPC UA agent, also known as the OPC UA on-chain proxy module, runs on the device where the OPC UA server resides or in a container deployed on the same machine. The certificate management module verifies the certificate chain, manages the certificate lifecycle, and writes the OPC UA server certificate public key or certificate ID to the consortium blockchain certificate directory contract.

[0034] The OPC UA server and consortium blockchain nodes are deployed in trusted devices, edge gateways, or trusted containers within the same industrial plant. They interact via local inter-process communication, Unix Domain Sockets, shared memory, or local high-speed buses, avoiding the use of cross-network gateways to forward industrial variables. In this way, the state of field variables can be read, signed, and submitted to the consortium blockchain within the same trusted boundary, reducing latency and mapping errors caused by cross-network protocol conversions.

[0035] 2. Data Model for Computing Power Resource Tokens and Computing Power Settlement Certificates

[0036] refer to Figures 1-4 This invention distinguishes between two types of on-chain objects.

[0037] The first category is computing resource tokens. Computing resource tokens are recorded in the consortium blockchain with the following field structure: TokenID (string type) represents the unique identifier of the computing resource token. Owner (string type) represents the identifier of the computing resource holder's factory or fusion node. ComputeType (enum type) represents the computing power type, including GPU, CPU, and MEM. Performance (float64 type) represents the performance benchmark, such as TFLOPS, TOPS, or memory bandwidth. OpcuNodeID (string type) represents the bound OPC UA variable NodeID. LastUpdateTime (string type) represents the time of the most recent valid state update. Status (float64 type) represents the current computing power utilization, load, or availability percentage, ranging from 0 to 100. StatusSource (string type) represents the state source description, pointing to the corresponding OPC UA variable node.

[0038] The second category is computing power settlement vouchers. Computing power settlement vouchers are general-purpose settlement tokens used for transaction custody, pricing, and release. In this example, "AIC" is used as the settlement voucher unit. Its fields include SettlementToken, Balance, EscrowStatus, and PriceUnit. SettlementToken is a string type representing the settlement voucher symbol, such as AIC. Balance is a float64 type representing the balance of settlement vouchers held by the facility or agent. EscrowStatus is an enum type representing the custody status, including idle, locked, released, and returned. PriceUnit is a string type representing the pricing unit, such as AIC / h.

[0039] The computing resource token and the OPC UA variable node are bound one-to-one: one computing resource token corresponds to one variable node representing the real-time status of that type of computing resource; one variable node can be mapped to different dimensions of the same physical computing resource, but different dimensions generate different computing resource tokens. For example, if the utilization rate, available video memory, and task queue length of the same GPU are treated as independent variable nodes, they can correspond to different computing resource tokens, but each token is bound to a specific on-site variable through its own NodeID.

[0040] 3. OPC UA variable binding and dynamic anchoring

[0041] The East China plant's fusion node address is opc.tcp: / / 192.168.2.10:4840, and it also serves as a consortium blockchain node peer0.east.auto.com. The North China plant's fusion node address is opc.tcp: / / 192.168.3.10:4840, and it also serves as a consortium blockchain node peer0.north.auto.com.

[0042] The East China plant has assetized the T4 GPU server, generating a computing resource token CRT-2024-EAST-T4-01. Its extended attribute record has an OPC UA variable NodeID of ns=3; s=GPU.T4.Usage. This variable node represents the real-time utilization rate of the T4 GPU, with a data type of Float, a value range of 0 to 100, and a unit of percentage.

[0043] The OPC UA agent can read the value of the variable node every 10 seconds, or monitor the variable through the OPC UA subscription mechanism. When the change exceeds the subscription dead zone, a read and anchoring judgment is triggered. The OPC UA server clock should be synchronized through NTP, PTP, or a trusted time source within the factory area to ensure that the timestamps have a verifiable time order during the arbitration phase.

[0044] When GPU utilization changes from 20% to 30%, a change of 10 percentage points, it reaches the GPU type dynamic anchoring threshold. At this time, the OPC UA agent constructs a state update message, which includes tokenID, nodeID, status, timestamp, and nonce. An example message is as follows:

[0045] {"tokenID": "CRT-2024-EAST-T4-01","nodeID": "ns=3;s=GPU.T4.Usage","status": 30,"timestamp": "2024-05-02T10:00:00.123456789+08:00","nonce": "a1b2c3d4"}

[0046] The OPC UA server certificate private key can be used for OPC UA secure channel authentication. In this invention, the OPC UA server or its on-chain proxy module deployed on the same machine uses the same key material or bound key material to perform application-layer cryptographic signing on a normalized data unit containing tokenID, nodeID, status, timestamp, and nonce. This signature is used to prove to the consortium blockchain smart contract that the state data was generated by the OPC UA server, and is not equivalent to an OPC UA session-layer message signature.

[0047] The signature algorithm can be ECDSA-SHA256, RSA-SHA256, or the Chinese national cryptographic standard SM2. Upon receiving the UpdateTokenAttribute call, the smart contract verifies the signature using the pre-configured OPC UA server certificate public key, and checks the timestamp format, time order, and the difference between it and LastUpdateTime. It also verifies that the nonce has not been reused. If the state change is less than a threshold, for example, from 20% to 21%, the OPC UA agent may not trigger an on-chain update to reduce the number of blockchain transactions. If the state change reaches the threshold, the on-chain Status and LastUpdateTime are updated, and a TokenUpdated event is published.

[0048] The GPU, CPU, and memory thresholds mentioned above are only preferred configurations. Actual systems can be configured with different thresholds according to computing power type, business level, or SLA requirements.

[0049] 4. Cross-plant authentication and task requests

[0050] Before cross-plant communication, the OPC UA agents in the East China and North China plants perform OPC UA cross-domain authentication. The group's trusted CA issues X.509 certificates to each plant. The certificate's Subject or extended fields contain the plant ID and the OPC UA agent ID. The certificate is valid for 1 to 2 years. After exchanging certificates, the communicating parties verify the following: whether the certificate was issued by the group's trusted CA; whether the certificate chain is complete; whether the certificate is valid; whether the plant ID and agent ID in the certificate are consistent with the requester's declaration; and whether the OPC UA security policy meets the preset level, such as Basic256 or Sha256.

[0051] After authentication, the North China plant, acting as the demand side, sends an AI inference task request to the East China plant. The task request can be based on OPC UA client / server communication or by calling OPC UA method nodes. Simultaneously, the North China plant initiates a purchase request via a smart contract.

[0052] The purchase request includes the computing power resource token identifier, computing power type, estimated duration or task amount, SLA terms identifier, and the number of computing power settlement vouchers. In this embodiment, the dynamic unit price is calculated as 12.4 AIC / h. The North China plant locks 118 AIC to the smart contract escrow account based on the estimated task duration of approximately 9.5 hours or an equivalent task amount. These 118 AIC represent the number of settlement vouchers and do not represent the splitting or duplication of the CRT-2024-EAST-T4-01 resource token itself.

[0053] 5. SLA Evidence Upload and Arbitration

[0054] After executing the AI ​​inference task, the East China plant generates SLA evidence. The SLA evidence structure includes TaskID, BuyerID, SellerID, NodeID, StartTime, EndTime, ResourceCurveSummary, ResultHash, AccuracyProof, and Signature.

[0055] TaskID represents the task identifier. BuyerID represents the buyer's factory or agent ID. SellerID represents the seller's factory or agent ID. NodeID represents the OPC UA variable NodeID that executes the task. StartTime is the task start time, verified by the OPC UA server's signed timestamp. EndTime is the task end time, verified by the OPC UA server's signed timestamp. ResourceCurveSummary is a summary of the computing power utilization curve, including average utilization, peak utilization, duration of utilization below the SLA threshold, and curve hash. ResultHash is the hash of the AI ​​task result. AccuracyProof is proof of result accuracy, which can be generated by TEE remote verification, third-party verification node signed report, or seller's summarized detection results, with buyer's signature confirmation as supplementary evidence. Signature is the signature of the aforementioned fields signed by the seller's OPC UA server certificate private key.

[0056] The arbitration smart contract incorporates an OPC UA timestamp verification module, performing the following checks: First, it verifies the Signature using the seller's OPC UA server certificate public key. Second, it verifies whether StartTime and EndTime conform to the DateTime encoding format of OPC UA Part 6, with an accuracy of at least milliseconds. Third, it verifies that EndTime is later than StartTime. Fourth, it verifies that the time difference between EndTime and the LastUpdateTime (the most recent valid state update time of the corresponding computing resource token before the task started) does not exceed the preset tolerance, and the difference between EndTime and StartTime is not greater than the SLA's preset task completion time window, which defaults to no more than 1 hour. Fifth, it verifies that the ResourceCurveSummary hash matches the signature overlay content and determines whether the digest satisfies the computing power utilization or task execution constraints in the SLA. Sixth, verify whether the AccuracyProof meets the SLA accuracy threshold. Accuracy metrics may include top-1 accuracy, mAP, IoU, F1, or business metrics agreed upon by both parties. If the buyer does not submit valid rebuttal evidence within the preset confirmation window, and the seller has submitted valid SLA evidence that meets the SLA threshold, the accuracy evidence is considered valid, and the seller is not simply deemed to be in breach of contract. Seventh, if all verifications pass, the AIC in the escrow account will be released to the seller. Eighth, if the timestamp is invalid, evidence is missing, or accuracy is insufficient, invalid evidence will be discarded and the matter will be handled according to the breach of contract rules.

[0057] Examples of arbitration liability determinations are as follows: If the buyer fails to lock the computing power settlement voucher on time, the buyer is deemed to be in breach of contract, and the action is to cancel the order and record a default credit event. If the seller fails to submit valid SLA evidence within the SLA window, the seller is deemed to be in breach of contract, and the action is to return the escrow computing power settlement voucher to the buyer and transfer the defaulted computing power settlement voucher according to a preset ratio. If the seller submits valid accuracy evidence, and the buyer fails to confirm or refute it without justifiable reason, the accuracy evidence is considered valid, and the seller is not simply deemed to be in breach of contract; the case is considered in conjunction with valid SLA evidence to release the case or continue arbitration. If the buyer submits valid rebuttal evidence and the accuracy rate is lower than the SLA threshold, the seller is deemed to be in breach of contract, and the action is to return the escrow computing power settlement voucher to the buyer and execute breach of contract compensation. If the timestamp signature is invalid or the time sequence is abnormal, the evidence is discarded and considered as not having submitted valid evidence, and is handled according to the rules for not submitting evidence. If the evidence is valid and meets the SLA, the transaction is completed, and the escrow computing power settlement voucher is released to the seller.

[0058] 6. Example of a dynamic pricing mechanism

[0059] In this embodiment, the base price P0 is 10 AIC / h, k is 1.2, and U_avg is 0.7, indicating that the average utilization rate of similar GPU computing power within the consortium blockchain is 70%. According to the formula:

[0060] P = P0 × (1 + k × (U_avg - 0.5))

[0061] The calculation yields:

[0062] P = 10 × (1 + 1.2 × (0.7 - 0.5)) = 10 × (1 + 0.24) = 12.4 AIC / h

[0063] When computing power utilization decreases, for example, when U_avg is 0.3:

[0064] P = 10 × (1 + 1.2 × (0.3 - 0.5)) = 10 × (1 - 0.24) = 7.6 AIC / h

[0065] In this embodiment, the computing power resource tokens participating in the U_avg calculation are of the same type, have been legally updated recently, and are not in a "state of unavailable" or "state of suspended trading" to avoid offline nodes or expired states affecting pricing. The above formulas and parameter ranges are preferred examples and do not constitute essential technical feature limitations of this invention.

[0066] 7. Fault, Anomaly, and Replay Protection

[0067] If a GPU failure at the East China plant causes task interruption, resulting in an empty ResultHash in the execution log or an AccuracyProof failing to meet the SLA threshold, the arbitration smart contract will determine that the seller is in default. The escrow computing power settlement voucher will be fully refunded to the buyer, and the defaulted computing power settlement voucher will be transferred from the seller's account according to a preset ratio.

[0068] If the OPC UA server clock malfunctions, causing the timestamp to be later than the current time of the arbitration contract, or earlier than the LastUpdateTime of the most recent valid state update before the task started, exceeding the preset tolerance, the verification module will directly remove the evidence.

[0069] If duplicate SLA evidence appears for the same TaskID, the contract will arbitrate based on the first valid evidence or the buyer's confirmed evidence to prevent replay attacks.

[0070] If the OPC UA server certificate expires, is revoked, or the merged node goes offline, the corresponding computing power resource token enters a "state unavailable" or "transaction suspended" state, and the arbitration contract prohibits the use of the expired certificate public key to verify new evidence. After the certificate is updated, the certificate management module must write the new certificate public key or certificate ID into the consortium blockchain certificate directory contract before the smart contract can use the new public key to verify subsequent signatures.

[0071] 8. Certificate Management Module and Certificate Catalog Contract

[0072] During the initialization of each merge node, the certificate management module registers the public key or certificate ID of the local OPC UA server certificate to the consortium blockchain certificate directory contract. Before initiating a cross-region task, the arbitration contract or transaction contract can query the corresponding public key through the certificate ID.

[0073] The certificate directory contract must record at least the following fields: CertID (certificate identifier), FactoryID (factory identifier), AgentID (OPC UA agent identifier), PublicKey (OPC UA server certificate public key), IssuerCA (issuing CA identifier), ValidFrom (certificate effective date), ValidTo (certificate expiration date), and Status (certificate status, including valid, expired, and revoked).

[0074] This mechanism provides a clear implementation path for the certificate management module and avoids hardcoding all certificate public keys in the arbitration contract. When a certificate is updated, revoked, or restored, the certificate management module writes the new status accordingly, ensuring that subsequent verifications automatically use the latest trusted certificate information.

[0075] 9. Smart Contract Interface Example

[0076] The smart contract must provide at least the following interfaces: The `UpdateTokenAttribute` interface takes `tokenID`, `newStatus`, `timestamp`, `signature`, `certID`, and `nonce` as inputs, and is used to update the status of the computing power resource token. The `PurchaseCompute` interface takes `tokenID`, `amount`, `buyerID`, `sellerID`, and `slaID` as inputs, and is used to lock the computing power settlement certificate and initiate a purchase. The `SubmitSLAEvidence` interface takes `taskID`, `startTime`, `endTime`, `resourceCurveSummary`, `resultHash`, `accuracyProof`, and `signature` as inputs, and is used to upload the SLA for storage. The `Arbitrate` interface takes `taskID` as input, and is used to trigger automatic arbitration. The `RegisterCert` interface takes `certID`, `factoryID`, `agentID`, `publicKey`, `validFrom`, and `validTo` as inputs, and is used to write to the certificate directory contract. The `QueryCertPublicKey` interface takes `certID` as input, and is used to query the OPC UA server certificate public key.

[0077] 10. Testing and Verification Environment

[0078] The test environment includes two factory-wide converged nodes, a test chain consisting of four consortium blockchain consensus nodes, a cross-factory industrial private network, and a group-wide trusted CA. OPC UA sessions employ certificate authentication and secure channel signature encryption, and smart contracts are deployed within consortium blockchain node containers.

[0079] In the test environment of this invention embodiment, the tester conducted comparative tests in consortium blockchain and cross-factory private network environments according to GB / T 37733-2019 "Industrial Internet Platform Test Specification". The indicators and test results are as follows: Regarding computing power status synchronization latency, the existing control scheme is 2 hours, while this invention is no more than 10 seconds, with a test sample size of 7 consecutive days of monitoring. Regarding transaction settlement cycle, the existing control scheme is 3 days, while this invention is 8 minutes, with a test sample size of 100 transactions. Regarding arbitration cycle, the existing control scheme is 2 weeks, while this invention is 10 minutes, with a test sample size of 20 disputes. Regarding illegal timestamp removal rate, the existing control scheme is 0%, while this invention is 100%, with a test sample size of 50 test pieces of evidence. Regarding cross-domain authentication success rate, the existing control scheme is 80%, while this invention is 100%, with a test sample size of 100 handshakes. In terms of deployment and modification, the existing comparative solutions require modification of the OPC UA device protocol stack or data model. The main logic of this invention is implemented by the fusion node, which has low intrusion into the on-site OPC UA devices. The test scope is deployment in 2 plant areas.

[0080] The above test data are used to illustrate the technical effects of the present invention in the context of the embodiments, and do not constitute a limitation on the scope of protection of the claims.

[0081] 11. Example of using native NodeID binding to prevent variable remapping errors

[0082] A factory has two T4 GPU servers with OPC UA variables ns=3;s=GPU.T4.ServerA.Usage and ns=3;s=GPU.T4.ServerB.Usage, respectively.

[0083] In gateway forwarding schemes, on-chain assets are typically bound to blockchain assets via variable names, tag names, or manually configured mapping tables. If field engineers modify the OPC UA address space, adjust the namespace index, or reconstruct variable names, the gateway mapping table may point to the wrong device, resulting in a discrepancy between the on-chain computing power asset status and the actual utilization rate of the on-site GPUs.

[0084] In this invention, the extended attributes of the computing power resource token CRT-2024-EAST-T4-A directly record OpcuNodeID=ns=3;s=GPU.T4.ServerA.Usage and NamespaceURI=urn:factory-east:gpu:t4. The OPC UA agent reads the state through the NodeID and, when the namespace index may change due to server reconstruction, resolves the current index by combining the NamespaceArray or the namespace URI. Since the on-chain token is always bound to variable nodes rather than volatile tag names, on-site variable reconstruction will not cause asset anchor point confusion. This embodiment illustrates that by establishing industrial asset anchor points through the OPC UA standard NodeID mechanism, the state of the on-chain computing power resource token can always correspond to a defined on-site variable.

[0085] 12. Example of eliminating gateway mapping latency through converged deployment

[0086] refer to Figures 1-4 In traditional solutions, the OPC UA server exposes variables to the gateway, which then converts them into MQTT, HTTP, or REST data before forwarding them to the blockchain adaptation layer, which then calls the smart contract. Tests show that this path often results in hour-level delays in state synchronization across inter-factory private networks due to batch processing, protocol conversion, and queuing on the central platform.

[0087] In this invention, the OPC UA server and the consortium blockchain node are deployed together on the same industrial edge device. After the OPC UA agent reads ns=3;s=GPU.T4.Usage, it constructs a signed message through local inter-process communication or shared memory and directly calls the smart contract on the consortium blockchain node. In the example environment, when the GPU utilization changes from 20% to 30% and reaches the GPU dynamic anchoring threshold, the state update from the change of the field variable to the completion of the on-chain Status update does not exceed 10 seconds. This example illustrates that the integrated deployment is used to reduce protocol conversion latency and state mapping errors caused by cross-network gateway forwarding.

[0088] 13. Comparison of Centralized Platform Log Tampering and OPC UA Server Signature Evidence: An Example

[0089] In existing centralized computing power trading platforms, after a transaction is completed, the platform generates an SLA log, including the start time, end time, accuracy result, and settlement conclusion. If platform insiders or malicious nodes tamper with the log, causing a task that should have met the SLA to be recorded as a default, it is difficult for either the buyer or the seller to prove their innocence.

[0090] In this invention, the task start and end times are generated by the OPC UA server clock and signed by the OPC UA server certificate private key. After the SLA evidence is uploaded to the consortium blockchain, the arbitration smart contract uses the certificate public key recorded in the certificate directory contract to verify: whether the timestamp signature is generated by the corresponding factory OPC UA server certificate; whether StartTime and EndTime conform to the OPC UA Part 6 DateTime format; whether EndTime is later than StartTime; whether the time difference between EndTime and LastUpdateTime before the task starts is within the tolerance and SLA window; and whether the overall signature of the SLA evidence passes verification. If an attacker forges platform logs but cannot generate a valid OPC UA server certificate signature, the arbitration contract directly removes the evidence. This embodiment illustrates that arbitration trust comes from an industry-standard certificate system, rather than centralized platform logs.

[0091] 14. Example of reducing on-chain transaction overhead through dynamic anchoring thresholds

[0092] If a GPU's utilization fluctuates by 1 percentage point per second during task execution, and each state change is recorded on the blockchain, hundreds of smart contract calls may be generated per hour, causing blockchain transaction congestion and confirmation delays.

[0093] This invention configures a dynamic anchoring threshold of 10 percentage points for GPU types. OPC UA agents only submit the UpdateTokenAttribute when the utilization rate reaches 10 percentage points relative to the most recent on-chain state change. For example: the on-chain state is 20%; a change to 30% triggers an on-chain event; subsequent fluctuations between 30% and 39% do not trigger an on-chain event; and an on-chain event is triggered again when the utilization rate changes to 40% or falls back to 20%. This mechanism reduces invalid on-chain transactions while maintaining the state granularity required for SLA time window verification. This embodiment illustrates how the dynamic anchoring threshold balances state real-time performance with blockchain transaction overhead.

[0094] 15. Example of a closed-loop evidence system for accuracy when the buyer has not confirmed the transaction.

[0095] After a certain inference task is completed, the seller uploads the TEE remote proof, result hash, and accuracy summary. The buyer, due to a dispute resolution strategy, intentionally fails to confirm within the confirmation window, attempting to prevent the release of the settlement document.

[0096] In this invention, accuracy evidence includes TEE remote proof or a third-party verification node signature report; the buyer's OPC UA agent signature confirmation serves only as supplementary evidence. The arbitration smart contract detects that: the SLA evidence signature is valid; the StartTime, EndTime, and time window are valid; the ResourceCurveSummary satisfies the SLA; the TEE remote proof in AccuracyProof meets the top-1 accuracy threshold; and the buyer has not submitted valid rebuttal evidence. At this point, the arbitration smart contract considers the accuracy evidence valid and releases the escrow computing power settlement certificate to the seller. This embodiment illustrates that SLA arbitration does not rely on the buyer's subjective confirmation, and transaction settlement can be completed when valid seller evidence exists.

[0097] 16. Example of Repeated SLA Evidence and Clock Rollback Protection

[0098] SLA evidence for the same TaskID was submitted repeatedly by a malicious node. The first piece of evidence contained a random number, nonce1, and the second replay contained the same nonce1. The arbitration smart contract verifies that the random number or sequence number has not been reused while verifying the signature. Therefore, the second piece of evidence was considered a replay attack and was discarded.

[0099] In another scenario, the OPC UA server clock experiences a rollback due to a malfunction, causing EndTime to occur earlier than the most recent valid state update time LastUpdateTime before the task started, exceeding the preset tolerance. The arbitration smart contract does not rely on this abnormal clock as proof of valid completion; instead, it discards the evidence and treats it as unsubmitted valid evidence. This embodiment illustrates that the present invention constructs a complete arbitration evidence verification path through anti-replay fields, clock tolerance, and certificate status verification.

[0100] 17. Comparative Examples with Existing Solutions

[0101] The comparison dimensions are as follows. Regarding state anchors, the gateway-forwarding OPC UA on-chain solution uses variable names or gateway mapping tables, centralized computing power trading platforms use their internal asset models, and this invention uses the OPC UA variable NodeID to natively bind computing power resource tokens. Regarding state synchronization paths, the gateway-forwarding solution involves OPC UA, gateway, MQ / HTTP, and a chain adaptation layer, while centralized platforms collect data and write it to the chain. This invention integrates the OPC UA server with consortium chain nodes for deployment and local communication. Regarding the root of trust for arbitration, the gateway-forwarding solution relies on gateway or platform logs, centralized platforms rely on the platform database, and this invention relies on the signature timestamp and SLA evidence verified by the OPC UA server certificate public key. Regarding tamper resistance, both the gateway mapping table and platform logs can be tampered with; this invention removes evidence when there is no valid OPC UA server certificate signature. Regarding transaction closed-loop, existing solutions require centralized platform hosting and manual arbitration or platform-controlled settlement; this invention uses smart contracts for automatic hosting, release, refund, and default handling. In terms of technical effectiveness, existing solutions suffer from hour-level delays and long arbitration cycles. This invention achieves synchronization in no more than 10 seconds, settlement in 8 minutes, arbitration in 10 minutes, and a 100% removal rate of illegal timestamps.

[0102] This comparative example illustrates that the present invention forms a verifiable, low-latency, and tamper-resistant arbitration technology path for industrial computing power transactions through native NodeID binding, integrated deployment, and industrial certificate signing timestamps.

[0103] 18. Implementation Example of Multi-Factory Consortium Blockchain Expansion and Integration Node Offline Protection

[0104] refer to Figure 2 This embodiment adds a South China factory area to the existing East China and North China factory areas, forming a consortium blockchain composed of nodes from three industrial factory areas. Each consortium node simultaneously serves as an OPC UA server and a consortium blockchain consensus node. The factory areas establish secure channels through the OPC UA cross-domain authentication mechanism and synchronize the status of computing power resource tokens and certificate directory contracts through the consortium blockchain consensus protocol.

[0105] During a certain period, the fusion node in the South China plant area temporarily went offline due to a power outage at the edge gateway. The system marked the computing resource tokens bound to the OPCUA variable under this plant area as "suspended trading" or "unavailable." Other plants within the consortium blockchain can still continue to perform state anchoring, purchase requests, SLA evidence uploads, and arbitration based on their local fusion nodes. While the arbitration smart contract is offline in the South China plant area, it is prohibited to use new server certificate signature evidence other than the most recent state of its expired or unreachable node. If evidence is received claiming to originate from the South China plant area but cannot be verified using the current certificate directory contract public key, or if the LastUpdateTime is significantly later than other legitimate nodes, it will be treated as abnormal evidence.

[0106] After the South China plant regains power and reconnects to the consortium blockchain, the OPC UA agent rereads the local variables such as ns=3; s=GPU.T4.Usage, constructs an update message containing the latest state, server clock timestamp, nonce, and signature. After the certificate directory contract confirms that the certificate is still valid, the corresponding computing power resource token is restored to a tradable state. This embodiment illustrates that in a multi-plant consortium blockchain, the offline status of a single fusion node should not cause a global transaction interruption, and the offline node's status must be updated with a valid signature after restoration before it can re-participate in settlement and arbitration.

[0107] 19. Example of OPC UA Server Certificate Renewal and Isolation of Old and New Certificates

[0108] This embodiment further illustrates the collaborative mechanism between the certificate management module and the certificate directory contract during the certificate lifecycle. The original OPC UA server certificate Cert-A in the East China plant was valid from May 1, 2023 to May 1, 2024. On April 25, 2024, the certificate management module generated a new certificate Cert-B and submitted an issuance request to the group's trusted CA. After the new certificate was issued, the certificate management module called the RegisterCert interface to write CertID, FactoryID, AgentID, PublicKey, IssuerCA, ValidFrom, and ValidTo of Cert-B into the consortium blockchain certificate directory contract, and simultaneously updated the status of Cert-A from "valid" to "expired" or "pending replacement".

[0109] After May 1, 2024, if the seller continues to execute AI tasks and uploads SLA evidence, they must sign the StartTime, EndTime, ResourceCurveSummary, ResultHash, and AccuracyProof fields using the corresponding Cert-B private key. When the arbitration smart contract queries the certificate directory contract, it only uses the Cert-B public key to verify new evidence. If an attacker intercepts old evidence generated on April 30, 2024, and attempts to tamper with the EndTime to May 2, 2024, and then replays it, the signature verification will fail because the tampered data has not been signed with the original certificate private key, and the evidence will be discarded.

[0110] If legitimate historical evidence generated within the validity period of the old certificate needs to be used in dispute reconciliation, the system can make a judgment by combining the original timestamp of the evidence and the validity period of the old certificate; however, any newly submitted evidence with a timestamp within the validity period of the new certificate must be verified by the public key of the new certificate. This example illustrates that certificate updates are not simply replacing local keys, but rather achieving state isolation between old and new certificates, switching of verification paths, and updating of the arbitration trust root through an on-chain certificate directory contract.

[0111] 20. Implementation Example of Memory-Type Computing Resource Tokens and 20 Percentage Point Dynamic Anchoring

[0112] The aforementioned embodiments primarily use GPU utilization as an example to illustrate NodeID binding and dynamic anchoring. This embodiment supplements the binding and threshold configuration of memory-type computing resource tokens.

[0113] The available video memory of the T4 GPU server in the East China plant is exposed through the OPC UA variable ns=4;s=MEM.T4.VRAM.Usage, which is of data type Float and has a value range of 0 to 100, representing the current percentage of available video memory. The system generates a computing resource token CRT-2024-EAST-MEM-01, whose extended attribute record OpcuNodeID = ns=4;s=MEM.T4.VRAM.Usage, and LastUpdateTime is initialized to the first valid read time.

[0114] The threshold is dynamically anchored based on memory type. The OPC UA agent only submits the UpdateTokenAttribute when the percentage of available video memory changes by 20 percentage points relative to the most recent on-chain state. For example, if the on-chain state is 60%, and the current state changes to 80% (a 20 percentage point change), an on-chain event is triggered. Subsequently, if it fluctuates between 80% and 85%, no on-chain event is triggered. When the current state falls back to 65%, a 15 percentage point change relative to the most recent on-chain state of 80%, an on-chain event is still not triggered. When it changes to 60% or lower, a 20 percentage point change relative to 80% triggers an on-chain event again.

[0115] This mechanism also applies to CPU load, network bandwidth, storage I / O, or other industrial computing power metrics that can be expressed by OPC UA variables. For memory resources, the status meaning can be a percentage of available resources rather than a percentage of utilization; however, as long as the variable node deterministically represents a certain computing power resource dimension, and the NodeID is uniquely bound to the token, it falls within the scope of protection of this invention. This embodiment illustrates that the dynamic anchoring threshold can be configured according to the computing power type, and different resource dimensions can be assetized in parallel within the same fusion node without causing meaningless on-chain transaction inflation due to frequent fluctuations.

[0116] 21. Example of Third-Party Verification Node Issuance Accuracy Evidence

[0117] This embodiment illustrates a specific implementation of a "verification report signed by a third-party verification node". In addition to the merged nodes of the buyer's and seller's factory areas, the system also includes an independent third-party verification node. This node is jointly trusted by the members of the consortium blockchain, and its certificate is also registered in the certificate directory contract or the independent verification node directory contract.

[0118] After completing the AI ​​inference task, the seller's North China plant sends the ResultHash, test dataset hash, inference output packet hash, and SLA term identifier to the third-party verification node. The third-party verification node independently runs the evaluation script based on the test dataset, calculating metrics such as top-1 accuracy, mAP, or IoU, and generates a ValidationReport. The ValidationReport includes at least the TaskID, ResultHash, DatasetHash, MetricType, AccuracyValue, VerifierID, Timestamp, and Signature. This Signature is signed with the third-party verification node's certificate private key.

[0119] When the seller uploads the SLA evidence to the consortium blockchain, the AccuracyProof field references the third-party ValidationReport and its signature. The arbitration smart contract first verifies the seller's OPC UA server certificate signature on the task time window and computing power utilization curve digest. Then, it queries the third-party verification node certificate public key, verifies the ValidationReport signature, and determines whether the AccuracyValue meets the accuracy threshold in the SLA terms. For example, if the SLA requires a top-1 accuracy of no less than 95%, and the third-party verification result is 96.2%, the arbitration contract releases the escrow AIC, provided the time and evidence are valid. If the third-party verification result is 93.0%, it is determined that the SLA is not met, and a refund and breach of contract processing are executed.

[0120] This example illustrates that accuracy evidence does not necessarily rely on seller self-certification or buyer subjective confirmation. Independent third-party verification reports can serve as one of the technical pieces of evidence automatically accepted by arbitration contracts, thereby improving the verifiability of the quality of cross-plant AI computing power transaction results.

[0121] 22. Example of determining seller's breach of contract due to buyer's submission of valid rebuttal evidence

[0122] The foregoing embodiments illustrate situations where accurate evidence can be valid even without buyer confirmation. This embodiment supplements the details of the process where the buyer submits valid rebuttal evidence within a preset confirmation window, leading to a reversal of the arbitration outcome.

[0123] In an image recognition task, the seller uploads a TEE (Telegraphic Exchange Equipment) remote proof and an accuracy summary, claiming a top-1 accuracy of 95.4%, meeting the SLA threshold of 95%. The buyer, within the confirmation window, does not accept this result and extracts 200 disputed samples from the task result set. These samples are then submitted to an independent review node or the buyer's own detection system for re-labeling and comparison, forming a RebuttalEvidence. The RebuttalEvidence includes the TaskID, a list of disputed sample IDs, a hash of the review result, the review accuracy, the RebuttalTimestamp, and the signature of the buyer or the independent review node.

[0124] During the Arbitrate phase, the arbitration smart contract simultaneously loads the AccuracyProof and RebuttalEvidence from the SLA evidence. If the contract verification finds the RebuttalEvidence signature to be valid, and the review results of the disputed sample show that the actual top-1 accuracy rate is 92.8%, which is lower than the SLA threshold, then it is determined that the combination of AccuracyProof and rebuttal evidence is insufficient to prove that the seller meets the SLA. In this case, the arbitration contract rules that the seller is in breach of contract, refunds the full amount of AIC in the escrow account to the buyer, and transfers the default AIC from the seller's account according to the default compensation ratio stipulated in the SLA terms.

[0125] This embodiment illustrates that the accuracy loop in this invention is not a unilateral evidence loop. If the buyer can submit valid rebuttal evidence that is cryptographically verifiable and traceable within the confirmation window, the arbitration contract should comprehensively assess the true service quality based on the evidence from both parties, thereby preventing the seller from obtaining improper settlement documents through incomplete self-certification reports.

[0126] It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A distributed AI computing power resource trading, settlement, and arbitration method based on OPC UA intelligent agent consortium blockchain, characterized in that, Initialize the merged node: Deploy the OPC UA server and the consortium blockchain consensus node in the same industrial plant trusted device, edge gateway or container, and register the OPC UA server certificate public key or certificate ID to the consortium blockchain certificate directory contract through local inter-process communication, shared memory, Unix domain socket or local high-speed bus interaction. S1, construct a consortium blockchain composed of multiple industrial plant integration nodes. Each integration node serves as both an OPC UA server and a consortium blockchain consensus node. Cross-plant OPC UA intelligent agent communication adopts the OPC UA cross-domain authentication mechanism. S2, convert AI computing power resources into computing power resource tokens. The computing power resource tokens are uniquely bound to OPC UA variable nodes and serve as the source of the current state corresponding to the state of the computing power resource tokens. The computing power resource tokens record the NodeID of the corresponding OPC UA variable node and the last update time LastUpdateTime. S3, the OPC UA smart agent periodically reads or monitors the computing power status of the corresponding OPC UA variable node through the OPC UA subscription mechanism. When the status change exceeds the threshold of the corresponding computing power type, a normalized data unit containing the new state, the timestamp generated by the OPC UA server clock and the anti-replay field is constructed. It is signed by the private key of the OPC UA server certificate and the smart contract update interface is called to submit the new state, timestamp, signature data, certificate ID and anti-replay field, so that the on-chain computing power resource token status is dynamically anchored to the on-site variable node. S4, the OPC UA agent of the demand side's factory area generates a computing power purchase request. The purchase request includes the computing power resource token identifier, computing power type, estimated duration or task amount, SLA term identifier and the number of computing power settlement vouchers. The smart contract locks the corresponding number of computing power settlement vouchers of the demand side to the escrow account and sends a task request based on OPC UA client / server communication or OPC UA method node to the OPC UA agent of the supply side's factory area. S5, after the supplier OPC UA agent executes the AI ​​task, it generates and uploads SLA evidence. The SLA evidence includes at least the task start time, end time, computing power utilization curve summary, result hash, accuracy evidence, and a signature signed by the private key of the OPC UA server certificate. S6, the arbitration smart contract uses the public key of the OPC UA server certificate recorded in the certificate directory contract to verify the timestamp signature and evidence signature in the SLA evidence, and verifies the timestamp format, time order, LastUpdateTime consistency and SLA time window; if the evidence is legal and complies with the SLA terms, the computing power settlement certificate in the escrow account is released to the supplier; if the evidence is illegal or does not comply with the SLA terms, a refund or breach of contract processing is executed. S7: If a dispute arises between the two parties to the transaction, the arbitration smart contract retrieves the legally valid SLA evidence and preset SLA terms stored on the chain, automatically determines the responsible party, and executes the transfer of computing power settlement vouchers and handling of breach of contract.

2. The method according to claim 1, characterized in that, The OPC UA cross-domain authentication mechanism mentioned in step S1 includes: The cross-domain OPC UA communication certificate is issued by the group's trusted CA. The certificate contains the plant ID and the OPC UA agent ID and is valid for 1 to 2 years. Cross-domain authentication certificates and OPC UA server timestamp signature certificates both belong to the group's trusted CA system; The two communicating parties exchange certificates, verify the certificate chain, signature and validity period, and then negotiate security policies and establish a secure channel.

3. The method according to claim 1, characterized in that, In step S2, the binding method between the computing power resource token and the OPC UA variable node is as follows: The extended attributes of the computing power resource token include the NodeID of the corresponding OPC UA variable; the NodeID is a combination of namespace index and string identifier that conforms to the OPC UA specification Part 3. The OPC UA agent reads the real-time status of computing resources through the NodeID and uses the status of the on-site variables corresponding to the NodeID as the unique source of the on-chain computing resource token status.

4. The method according to claim 1, characterized in that, In step S3, the threshold configuration of the dynamic anchoring mechanism is as follows: the state change threshold corresponding to the GPU type is 10 percentage points; the state change threshold corresponding to the CPU type is 15 percentage points. The state change threshold corresponding to the memory type is 20 percentage points; the state change threshold is calculated as the absolute value change of computing resource utilization rate or available percentage.

5. The method according to claim 1, characterized in that, Step S4 also includes a dynamic pricing mechanism based on supply and demand: the price of the computing power settlement voucher fluctuates with the real-time computing power utilization rate within the consortium blockchain, and the price calculation formula is as follows: P = P0 × (1 + k × (U_avg - 0.5)); Wherein, P0 is the base price, and the unit is the computing power settlement voucher unit per hour; U_avg is the arithmetic mean of the computing power utilization rate represented by the OPC UA variable node corresponding to the same type of computing power resource token in the consortium chain, divided by 100, and the value ranges from 0 to 1; k is the supply and demand elasticity coefficient, which is obtained by fitting based on historical computing power transaction data through linear regression or machine learning regression algorithm, and the value ranges from 0.8 to 1.

5.

6. The method according to claim 1, characterized in that, In step S6, the verification rules of the OPC UA timestamp verification module include: The timestamp signature is generated by the private key of the OPC UA server certificate issued by a trusted CA and verified using the corresponding certificate's public key; The timestamp conforms to the DateTime encoding format defined in Part 6 of the OPC UA specification, with a precision of no less than milliseconds; the task end time is later than the start time. The time difference between the end time and the latest legal status update time (LastUpdateTime) of the corresponding computing power resource token before the task starts shall not exceed the preset tolerance. The preset tolerance is determined by the SLA terms or the fusion node configuration parameters, and the difference between the end time and the start time shall not be greater than the SLA preset task completion time window. The preset time window is determined based on the task completion time threshold in the SLA terms, or by default is no more than 1 hour; wherein, the verification also includes verifying the overall signature of the SLA evidence using the certificate public key.

7. The method according to claim 1, characterized in that, In steps S5 and S6, the SLA terms are pre-written into the smart contract, including the task completion time threshold, the result accuracy threshold, and the default compensation ratio; the SLA evidence also includes a summary of the computing power utilization curve, which includes the average utilization rate, the peak utilization rate, the duration of utilization rate below the SLA threshold, and the curve hash. After verifying the SLA evidence signature, the arbitration smart contract also checks whether the hash of the computing power utilization curve digest matches the content covered by the signature, and determines whether the digest meets the computing power utilization or task execution constraints in the SLA. The accuracy evidence includes remote proofs generated by a trusted execution environment, verification reports issued by third-party verification nodes, or proof of detection results summarized by the seller's OPC UA agent; The buyer's OPC UA agent signature confirmation serves only as supplementary evidence. If the buyer fails to submit valid rebuttal evidence within the preset confirmation window, and the seller has submitted valid SLA evidence and meets the SLA threshold, the arbitration smart contract will consider the accuracy evidence to be valid. If the buyer submits valid rebuttal evidence within the preset confirmation window, and the accuracy of the results, combined with the AccuracyProof and the rebuttal evidence, is lower than the SLA threshold, the seller is deemed to be in breach of contract. The default handling includes returning the managed computing power settlement voucher and transferring the defaulted computing power settlement voucher according to a preset ratio.

8. The method according to claim 1, characterized in that, Step S6 also includes anomaly protection rules: if the OPC UA server clock is abnormal, causing the timestamp to be later than the current time of the arbitration contract, or earlier than the last valid state update time LastUpdateTime before the task started, exceeding the preset tolerance, then the evidence will be removed. If the OPC UA server certificate expires, is revoked, or the fusion node goes offline, the corresponding computing power resource token will enter an unavailable or suspended trading state, and the arbitration contract will prohibit the use of the expired certificate public key to verify new evidence. After the certificate is updated, the certificate management module writes the new certificate public key or certificate ID into the consortium blockchain certificate directory contract, and the smart contract can use the new public key to verify subsequent signatures.

9. The method according to claim 1, characterized in that, The anti-replay field mentioned in step S3 includes a random number or a serial number; The arbitration smart contract verifies that the random number or serial number has not been reused when verifying the signature; if duplicate SLA evidence appears for the same TaskID, the arbitration smart contract will arbitrate based on the first valid evidence or the buyer's confirmation evidence.

10. A distributed AI computing power resource trading, settlement, and arbitration system based on OPC UA intelligent agent consortium blockchain, characterized in that, It includes multiple converged nodes, each of which includes an OPC UA server, a consortium blockchain consensus node, an OPC UA smart agent, and a certificate management module; The OPC UA server and the consortium blockchain consensus node are deployed together in the same industrial plant trusted device, edge gateway, or container; the system is configured to execute the method of any one of claims 1 to 9; Among them, the settlement transaction module and the arbitration contract module are deployed in the form of smart contracts in the consortium blockchain node environment of the fusion node, and are used to perform the custody, release, dynamic pricing and updating of computing power settlement certificate and computing power resource token attributes. The certificate management module stores OPC UA server certificates, cross-domain communication certificates, and trusted CA root certificates, and registers the public key or certificate ID of the OPC UA server certificate to the consortium blockchain certificate directory contract; The certificate directory contract records at least the certificate identifier, factory area identifier, agent identifier, public key, issuing CA, effective time, expiration time, and certificate status.

Images