An execution token based trusted data space off-chain controlled computation and auditing system

Abstract

The embodiment of the specification provides a trusted data space off-chain controlled computing and auditing system based on an execution token, wherein the trusted data space off-chain controlled computing and auditing system based on the execution token comprises: an execution arrangement module receiving a data application request submitted by a data requester, calling a policy management contract on a block chain to verify a request parameter corresponding to the data application request; then the policy management contract issues an execution token, and sends the execution token and task information corresponding to the data application request to an off-chain execution agent module; the off-chain execution agent module determines that a current execution environment meets a security condition according to the task information and the execution token, calls a data connector to locally read target data of a data provider under control, processes the target data according to the execution token, obtains a data processing result and an execution receipt information, and sends the data processing result to the data requester under the condition that the execution receipt information meets a verification condition.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of data security technology, and in particular to a trusted data space off-chain controlled computing and auditing system based on execution tokens. Background Technology

[0002] With the deepening of market-based allocation of data elements, technologies such as trusted data spaces and privacy computing have become key infrastructures supporting cross-entity data circulation. In existing data sharing or collaborative computing scenarios, to balance the release of data value with security and compliance requirements, the industry has generally adopted technical solutions based on access control lists, attribute-based encryption, or smart contract authorization. These solutions typically protect data files by registering data asset metadata, defining usage policy rules, using electronic contracts to stipulate the scope of data use, and combining methods such as encrypted file transmission, key distribution, and runtime environment detection. Their core logic lies in verifying the legitimacy and validity of the requester's identity and permissions, allowing the requester to obtain a copy of the data or decrypt the data in a designated environment after meeting preset conditions, and forming an audit trail by recording operation logs to ensure basic data security during circulation. However, in existing technologies, current data management mechanisms mainly focus on solving the static permission problem of who can access data, making it difficult to further achieve dynamic execution control over how data must be used, by which algorithm, in which execution environment, and what granularity of the output results. Once data is delivered to the requesting party or decrypted locally, the data provider often loses the ability to constrain the subsequent use of the data. They lack fine-grained control over individual computational tasks and struggle to generate irrefutable, verifiable audit evidence strongly tied to specific actions, leading to a risk of data usage spiraling out of control. Therefore, an effective solution is urgently needed to address these issues. Summary of the Invention

[0003] In view of this, embodiments of this specification provide a trusted data space off-chain controlled computation and auditing system based on execution tokens. One or more embodiments of this specification also relate to a trusted data space off-chain controlled computation and auditing method based on execution tokens, a trusted data space off-chain controlled computation and auditing device based on execution tokens, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a trusted data space off-chain controlled computation and auditing system based on execution tokens is provided, including an execution orchestration module and an off-chain execution agent module, comprising: The execution orchestration module is used to receive data request requests submitted by data requesters, call the strategy management contract on the blockchain to verify the request parameters corresponding to the data request; if the verification is successful, the strategy management contract issues an execution token and sends the execution token and the task information corresponding to the data request to the off-chain execution agent module. The off-chain execution proxy module is used to, based on the task information and the execution token, determine that the current execution environment meets the security conditions, call the data connector to read the target data locally in a controlled manner from the data provider; process the target data according to the execution token to obtain data processing results and execution receipt information; and, if the execution receipt information meets the verification conditions, send the data processing results to the data requester.

[0005] According to a second aspect of the embodiments of this specification, a method for off-chain controlled computation and auditing of a trusted data space based on execution tokens is provided, comprising: Receive a data request submitted by a data requester, and invoke the strategy management contract on the blockchain to verify the request parameters corresponding to the data request; If the verification passes, the strategy management contract issues an execution token and determines the task information corresponding to the data request. If the current execution environment meets the security conditions based on the task information and the execution token, the data connector is invoked to read the target data locally in a controlled manner from the data provider. The target data is processed according to the execution token to obtain data processing results and execution receipt information; If the execution receipt information meets the verification conditions, the data processing result will be sent to the data requester.

[0006] According to a third aspect of the embodiments of this specification, a trusted data space off-chain controlled computing and auditing device based on an execution token is provided, comprising: The receiving module is configured to receive data request requests submitted by the data requester and call the strategy management contract on the blockchain to verify the request parameters corresponding to the data request request. The determination module is configured to, upon successful verification, issue an execution token by the strategy management contract and determine the task information corresponding to the data request; The calling module is configured to, based on the task information and the execution token, determine that the current execution environment meets the security conditions, and then call the data connector to read the target data locally in a controlled manner from the data provider. The processing module is configured to process the target data according to the execution token to obtain data processing results and execution receipt information; The sending module is configured to send the data processing result to the data requester if the execution receipt information meets the verification conditions.

[0007] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, they implement the steps of the above-described trusted data space off-chain controlled computation and auditing method based on execution tokens.

[0008] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the above-described method for controlled off-chain computation and auditing of a trusted data space based on an execution token.

[0009] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method for controlled computation and auditing of a trusted data space based on execution tokens.

[0010] The off-chain controlled computation and auditing system for trusted data space based on execution tokens provided in this embodiment receives data request requests through the execution orchestration module and drives the on-chain strategy management contract to complete multi-dimensional parameter verification. After the verification is passed, an execution token containing specific constraint information is issued, and then the token and task information are sent to the off-chain execution agent module. The off-chain execution agent module calls the environment verification unit to measure and verify the current execution environment based on the execution environment proof requirement information in the execution token. Only when the environment measurement result matches the requirements and is confirmed as a safe environment, the data connector is triggered to read the target data locally in a controlled manner according to the data registration information and send it into the trusted execution area. Subsequently, the system strictly calls the target algorithm to process the target data according to the algorithm digest information and strategy version information bound to the execution token. During this process, the system automatically collects the input digest, output digest, execution log digest, and environment proof information to generate structured execution receipt information, and submits the receipt to the blockchain for the audit contract to verify its binding relationship with the execution token, parameter consistency, and token validity. Finally, after the verification is passed, only the data processing results that meet the preset output granularity and usage restrictions are returned to the data requester. The close integration of these technical features upgrades data usage control from static file access permissions to dynamic task-level execution permissions. The dual binding of algorithmic hashing and environmental metrics ensures the immutability of computational logic and the operating environment. The local controlled read mechanism prevents the original data from leaving the domain, and the automated verification of execution receipts through on-chain audit contracts builds a complete and trustworthy chain of evidence. This effectively solves the problems of existing technologies in achieving fine-grained usage control, untrustworthy execution processes, and unverifiable auditability of behavior during data circulation. It significantly improves data security, process transparency, and compliance capabilities in cross-entity data collaboration scenarios. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the structure of a trusted data space off-chain controlled computing and auditing system based on execution tokens, provided in one embodiment of this specification. Figure 2 This is a flowchart of a trusted data space off-chain controlled computing and auditing system based on execution tokens, provided in one embodiment of this specification. Figure 3 This is a flowchart illustrating an embodiment of a trusted data space off-chain controlled computation and auditing method based on execution tokens provided in this specification; Figure 4 This is a schematic diagram of the structure of a trusted data space off-chain controlled computing and auditing device based on an execution token, provided in one embodiment of this specification; Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0012] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0013] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0014] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0015] This specification provides a token-based off-chain controlled computation and auditing system for trusted data spaces. One or more embodiments of this specification also relate to a token-based off-chain controlled computation and auditing method, a token-based off-chain controlled computation and auditing device, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0016] With the development of data element circulation, privacy computing, and trusted data space technologies, data collaboration application scenarios among different entities are increasing. However, in actual business, data providers are often unwilling to directly deliver raw data to requesting parties due to considerations such as data compliance, protection of trade secrets, protection of personal privacy, and confirmation and accountability of data assets. Existing data sharing or circulation solutions mostly focus on addressing access control issues, such as restricting data access through file encryption, key distribution, or permission management. However, these solutions struggle to further constrain how data must be used, by which algorithm, in which execution environment, at what granularity the output should be, and how to create a non-repudiable usage record. Once data access is authorized, data providers often lose control over subsequent data usage, posing risks of unauthorized use, reverse engineering through unauthorized algorithms, or leakage in untrusted environments. Furthermore, existing technologies are weak in trusted verification of execution environments, lacking rigorous proof mechanisms to ensure that computation necessarily occurs in an approved trusted environment, and failing to fully meet the strict requirement of keeping raw data within its domain.

[0017] In view of this, the off-chain controlled computation and auditing system for trusted data space based on execution tokens provided in this embodiment receives data application requests through the execution orchestration module and drives the on-chain policy management contract to complete multi-dimensional parameter verification. After the verification is passed, an execution token containing specific constraint information is issued, and then the token and task information are sent to the off-chain execution agent module. The off-chain execution agent module calls the environment verification unit to measure and verify the current execution environment based on the execution environment proof requirement information in the execution token. Only when the environment measurement result matches the requirements and is confirmed as a safe environment, the data connector is triggered to read the target data locally in a controlled manner according to the data registration information and send it into the trusted execution area. Subsequently, the system strictly calls the target algorithm to process the target data according to the algorithm digest information and policy version information bound to the execution token. During this process, the system automatically collects the input digest, output digest, execution log digest, and environment proof information to generate structured execution receipt information, and submits the receipt to the blockchain for the audit contract to verify its binding relationship with the execution token, parameter consistency, and token validity. Finally, after the verification is passed, only the data processing results that meet the preset output granularity and usage restrictions are returned to the data requester. The close integration of these technical features upgrades data usage control from static file access permissions to dynamic task-level execution permissions. The dual binding of algorithmic hashing and environmental metrics ensures the immutability of computational logic and the operating environment. The local controlled read mechanism prevents the original data from leaving the domain, and the automated verification of execution receipts through on-chain audit contracts builds a complete and trustworthy chain of evidence. This effectively solves the problems of existing technologies in achieving fine-grained usage control, untrustworthy execution processes, and unverifiable auditability of behavior during data circulation. It significantly improves data security, process transparency, and compliance capabilities in cross-entity data collaboration scenarios.

[0018] See Figure 1 , Figure 1 This is a schematic diagram of the structure of a token-based trusted data space off-chain controlled computation and auditing system according to one embodiment of this specification. The token-based trusted data space off-chain controlled computation and auditing system 100 includes an execution orchestration module 110 and an off-chain execution proxy module 120, comprising: The execution orchestration module 110 is used to receive data application requests submitted by data requesters, call the strategy management contract on the blockchain to verify the request parameters corresponding to the data application request; if the verification is successful, the strategy management contract issues an execution token and sends the execution token and the task information corresponding to the data application request to the off-chain execution agent module. The off-chain execution proxy module 120 is used to, based on the task information and the execution token, determine that the current execution environment meets the security conditions, call the data connector to read the target data locally in a controlled manner from the data provider; process the target data according to the execution token to obtain data processing results and execution receipt information; and, if the execution receipt information meets the verification conditions, send the data processing results to the data requester.

[0019] Specifically, the execution orchestration module can refer to a service node or gateway device deployed in a trusted data space network. It acts as an interaction bridge between the data requester and the blockchain smart contract, responsible for coordinating the initiation and scheduling of data usage tasks. The main function of the execution orchestration module is to receive data usage intentions from external sources and transform them into on-chain identifiable verification requests. In its implementation, the execution orchestration module can establish a connection with the blockchain network and submit request parameters (such as requester identity, target data identifier, intended algorithm identifier, and usage description) included in the data application request to the chain for automated comparison by calling a pre-deployed policy management contract interface. When the policy management contract determines that the request parameters conform to the preset data usage policy, the execution orchestration module receives an execution token automatically issued by the contract. This execution token is not a traditional data access key, but a one-time computation execution permission with strict constraints. After obtaining the execution token, the execution orchestration module packages it with specific task context information (i.e., task information) and sends it to the off-chain execution agent module through a secure communication channel, thereby triggering the subsequent off-chain controlled computation process. The execution orchestration module can be configured in its deployment form according to the actual situation. For example, it can be an independent microservice component or integrated into the operation management platform of the data space. This application embodiment does not make any special limitations on this.

[0020] Correspondingly, the off-chain execution proxy module can refer to a software entity or runtime container running in an environment with trusted execution capabilities, such as an agent program, a trusted sandbox, or a remotely verified isolated computing instance running within a Trusted Execution Environment (TEE). The function of the off-chain execution proxy module is to carry the actual data processing logic and ensure that the entire computation process is performed under security constraints. After receiving the execution token and task information issued by the execution orchestration module, the module first initiates an internal security verification mechanism. It uses the environment constraint information carried in the execution token (such as the execution environment hash value, metric requirements, etc.) to self-verify or accept remote verification of the current running environment to confirm whether the current execution environment meets the security conditions. Only after the environment verification passes will the off-chain execution proxy module activate the data reading and computation process. This design ensures that data processing can only occur within a certified trusted boundary, preventing abnormal risks. The specific implementation of the off-chain execution proxy module can be an enclave environment built based on a hardware root of trust, or an isolated virtual machine built based on virtualization technology; this application embodiment does not impose any special limitations on this.

[0021] Correspondingly, a data connector can refer to a data access interface component deployed within the local domain of the data provider or tightly coupled with the data storage space. Its function is to read target data on demand and transmit it to the controlled area where the off-chain execution agent module is located, without moving the original data copy. The working mechanism of the data connector is to locate and read the target data in the local storage system of the data provider based on the data index or identifier specified in the task information. The key is that the data stream read by the data connector is directly injected into the off-chain execution agent module (such as inside the TEE) that has passed security verification, rather than being sent to the data requester or exposed to the public network. A controlled data channel is established between the data connector and the off-chain execution agent module to ensure that the data is available but not visible. The specific form of the data connector can vary depending on the data storage architecture. For example, it can be a database middleware plugin, a file system filter driver, or an object storage gateway, as long as it can achieve index-based controlled reading and restrict the data flow to the trusted execution environment. This application does not impose any special limitations on this.

[0022] Correspondingly, an execution token can refer to a digital credential generated by a policy management contract on the blockchain after successful verification. Essentially, it is an authorization for a specific computational task. The execution token is bound to multi-dimensional constraint information, which together constitute the rule set for this data use. The content of the execution token may include, but is not limited to: the identifier of the entity permitted to execute, the unique identifier of the target data object, the applicable policy version, the approved algorithm digest (such as a hash value) and version, the specific purpose of data use, the token's validity period window, the proof requirements for the execution environment, and random numbers used to prevent replay. The execution token's linkage within the system is as follows: it is the link between on-chain policies and off-chain execution. The off-chain execution proxy module must parse the various constraints in the execution token and implement them one by one (such as matching the algorithm version and verifying environment metrics). Only when all constraints are satisfied can the data processing flow continue. The execution token can be generated by a smart contract dynamically constructing and signing it based on input parameters. Its format can be a structured data object (such as a JSON object) or an encoded binary string; this embodiment does not impose any special limitations on this.

[0023] Correspondingly, execution receipt information refers to a structured proof file generated after the off-chain execution proxy module completes the data processing task. It records key metadata and integrity evidence of the execution. The content of the execution receipt information may include a digest of the input data (such as a hash value), a digest of the output result, an identifier or digest of the actual executed algorithm, environmental proof information during execution (such as a remote proof report), a digest of the execution log, and an execution timestamp. The function of execution receipt information in the system is to serve as the basis for on-chain auditing, proving that the data was indeed processed in a trusted environment according to the conditions specified by the execution token. After generating the execution receipt information, the off-chain execution proxy module submits it to the verification stage (which can be an on-chain audit contract or a local verification module). Only when the execution receipt information passes verification (i.e., meets the verification conditions, such as valid signature, digest matching, and compliant environmental proof), will the off-chain execution proxy module send the final data processing result to the data requester. This mechanism implements a control logic of audit verification before result release, ensuring the credibility of the result.

[0024] Based on this, an on-chain and off-chain collaborative control system is established, driven by execution tokens. This system no longer relies solely on static access permission lists, but refines the granularity of data usage control to each specific computation task. By binding multi-dimensional constraints such as algorithm version, execution environment metrics, and usage purpose to the execution token, it forces the off-chain execution agent module to use specified algorithms to compute specified data in a strictly matched and controlled environment. This achieves a paradigm shift in control from who can read data to how data is used.

[0025] In other words, the data requester first submits a data request to the execution orchestration module; the execution orchestration module then transmits the parameters of the request to the strategy management contract on the blockchain for automated verification; if the verification passes, the strategy management contract issues an execution token containing multi-dimensional constraints and returns it to the execution orchestration module; the execution orchestration module then distributes the execution token and task information to the off-chain execution agent module; the off-chain execution agent module first uses the environment requirements in the token to perform a security verification of the current operating environment to confirm its trustworthiness; subsequently, the off-chain execution agent module instructs the data connector to read the target data locally in a controlled manner from the data provider and transmit it to the trusted environment; next, the off-chain execution agent module calls the corresponding algorithm to process the data according to the algorithm constraints in the token, generating the processing result and execution receipt information containing execution evidence; finally, the system verifies the execution receipt information, and only after the verification passes and the execution process is confirmed to be compliant will the data processing result be returned to the data requester, thus forming a complete controlled computation closed loop.

[0026] For example, in a trusted data space scenario, a financial institution (data requester) wants to use user profile data from a telecom operator (data provider) for joint risk control modeling, but does not want to directly obtain the raw user data. The financial institution submits an application to the execution orchestration module, specifying that it needs to use a specific version of the logistic regression algorithm to train a designated dataset. The execution orchestration module calls the on-chain policy management contract to verify whether the financial institution is on the whitelist, whether the purpose is compliant, and whether the algorithm version is allowed. After the verification is passed, the contract issues an execution token, which is bound to the financial institution's ID, dataset ID, the hash value of the logistic regression algorithm, the TEE environment metric requirements, and the validity period of this task. The execution orchestration module issues this token to the off-chain execution agent module running in the TEE. The agent program in the TEE first compares whether the current hardware environment metric is consistent with the token requirements; if they are consistent, the process is passed. Subsequently, the agent program calls the data connector deployed locally on the operator's machine, reads the encrypted user data by index, decrypts it, and loads it into the TEE memory. The TEE loads the logistic regression algorithm code that matches the token hash and trains the data. After the computation is complete, the TEE generates an execution receipt containing the input data hash, model parameter hash, algorithm hash, and a TEE remote proof report. This receipt is submitted to the on-chain audit contract for verification. Once the audit contract confirms that the algorithm hash in the receipt matches the token, the environment proof is valid, and the token has not expired, the task is marked as complete. At this point, the off-chain execution agent module sends the trained model parameters (not the original data) to the financial institution, completing this controlled computation.

[0027] In practice, when issuing a token, the execution token generation module can respond to the task request initiated by the data requester, verify the request parameters according to the policy registered on the chain, and issue the execution token after passing the verification. The execution token is not a data access credential, but a controlled execution permission. The token includes at least the following information: permitted subject identifier, target data identifier, policy version, algorithm digest, purpose of use, validity period, execution environment proof requirements, random number, etc.

[0028] In summary, by introducing an execution token bound with multi-dimensional constraint information as a computational license, data usage control is upgraded from coarse-grained access control to fine-grained task-level execution control, thus effectively preventing data from being used beyond its scope or processed by unauthorized algorithms. Because the off-chain execution agent module forcibly verifies the security conditions of the execution environment before execution and achieves controlled reading and inflow of data locally on the provider's premises through a data connector, it ensures that the original data never leaves the data provider's controlled domain, meeting the compliance requirement of data usability without visibility. Furthermore, by generating execution receipt information containing complete execution evidence and deciding whether to release the computational results based on the verification results, an immutable and traceable audit loop is formed, solving the technical problems of untrustworthy execution processes and unauditable behavior in existing technologies.

[0029] In one or more embodiments of this example, the execution orchestration module is further configured to parse the data request to obtain the requester's identity identifier, target data object, purpose information, target algorithm identifier, algorithm version information, and output result requirement information; and call the strategy management contract on the blockchain to verify the requester's identity identifier, the target data object, the purpose information, the target algorithm identifier, the algorithm version information, and the output result requirement information.

[0030] Specifically, parsing data request messages refers to the process by which the orchestration module, upon receiving a data usage request from the requester, extracts key semantic fields from the request message or message body according to a preset data structure or protocol format. This parsing process aims to transform unstructured or semi-structured request information into a set of structured parameters that the system can recognize and verify. The parsed requester identity identifier can be a digital certificate serial number, Distributed Identity Detector (DID), or account address used to uniquely identify the data requester, confirming the legitimacy of the entity initiating the data usage task. The target data object can be an identifier of the specific data asset the data requester wishes to access, such as the data_id generated during data registration, used to clearly identify the object of the task. The purpose information can be a description of the data usage intent declared by the data requester, such as model training, risk assessment, or statistical analysis, used to prevent data from being used for unauthorized purposes. The target algorithm identifier can be a unique code or name of an algorithm pre-registered in the strategy management contract, used to identify the specific algorithm logic used in this calculation. The algorithm version information can be the specific version number or hash digest of the target algorithm, used to ensure the consistency of the calculation logic and prevent result deviations due to algorithm upgrades or tampering. The output result requirement information can be limitations on the format, precision, statistical granularity, or anonymization level of the final returned data, such as returning only the aggregated average or returning an encrypted feature vector. These parameters collectively constitute the verification basis before the execution token is issued, ensuring the transparency and controllability of the data usage intent.

[0031] Correspondingly, the requester's identity, target data object, purpose information, target algorithm identifier, algorithm version information, and output result requirements can be passed as input parameters to the execution function of the on-chain smart contract when interacting with the strategy management contract. The strategy management contract internally stores the usage policies pre-registered by the data provider. This verification process involves comparing each of the six parsed parameters with the on-chain policy rules. For example, it verifies whether the requester's identity is within the whitelist of permitted users; whether the target data object matches the target data identifier bound to the policy; whether the purpose information falls within the permitted use set; whether the target algorithm identifier and its version information are completely consistent with the algorithm whitelist and specified version in the policy; and whether the output result requirements meet the output granularity or export restrictions specified by the policy. Only when all parameters pass the automated verification by the on-chain logic and are determined to comply with the preset policy will the strategy management contract trigger the subsequent token issuance process. This multi-dimensional parameter verification mechanism refines the originally static access control into dynamic, task-oriented execution control, ensuring that even if the subject is legitimate, it cannot obtain execution permission if its specified algorithm, purpose, or output requirements do not conform to the data provider's policy constraints.

[0032] Based on this, the execution orchestration module, acting as a bridge connecting on-chain policies and off-chain execution, first assumes the function of a parser, transforming the natural language or standard format requests from data requesters into machine-readable structured parameters. These parameters are then packaged and sent to the policy management contract deployed on the blockchain. Leveraging its immutability and automatic execution, the policy management contract acts as a trusted adjudicator, rigorously reviewing each parameter according to the pre-defined policy rules of the data provider. In particular, regarding the verification of target algorithm identifiers and algorithm version information, the system mandates that requesters use specific algorithm versions approved by the data provider, thereby eliminating the risk of reverse engineering or out-of-scope calculations using unauthorized algorithms from the outset. Simultaneously, the pre-verification of output results ensures that the compliance boundaries of subsequent calculations are determined before generation. The entire verification process is completed on-chain, guaranteeing the transparency of the verification logic and the non-repudiation of the verification results, laying a solid foundation for the subsequent issuance of legally and technically binding execution tokens.

[0033] For example, a data requester submits a data usage request to the execution orchestration module via a client. The request includes the requester's DID, the target data ID (DATA_2023_001), the purpose (credit scoring model inference), the target algorithm ID (ALG_CREDIT_V2), the algorithm version (v2.1.0), and the output requirement of only returning rating levels (A / B / C / D). The execution orchestration module parses the request and extracts the six fields mentioned above. Then, the execution orchestration module calls the `validateRequest` interface of the policy management contract, passing in these six parameters. The policy management contract reads the policy record associated with this data ID and finds that the policy allows the following entities: this DID; the allowed purpose: credit scoring; the allowed algorithm list includes ALG_CREDIT_V2 with the specified version being v2.1.0; and the allowed output format is a rating result. After comparing each parameter and confirming that all parameters match, the contract returns a verification pass signal. If the requester changes the algorithm version to v2.0.0 or the purpose to user profile building in the application, the policy management contract will detect the mismatch and return a verification failure, terminating the process and thus preventing the execution of the violation task.

[0034] In summary, this approach enables refined pre-emptive control over data request requests. Because the execution orchestration module can deeply analyze data request requests and extract multi-dimensional key parameters, and then automatically verify these parameters through an on-chain strategy management contract, it ensures that each data usage task strictly complies with the subject, purpose, algorithm, and output constraints set by the data provider before initiation. In particular, by including algorithm identifiers and version information in the mandatory verification scope, it effectively solves the technical problem of preventing requesters from using unauthorized algorithms to process data in existing technologies, thereby achieving the technical effect of improving data circulation security and control granularity.

[0035] In one or more embodiments of this example, the strategy management contract manages multiple candidate execution tokens, wherein any candidate execution token includes at least one of the following information: permitted subject identification information, target data identification information, strategy version information, algorithm digest information, purpose of use information, validity period information, execution environment proof requirement information, and random number.

[0036] Specifically, the authorized entity identifier information can refer to the unique identity of the data requester or execution agent authorized to perform this data processing task. This information is used to verify, during the off-chain execution phase, whether the entity initiating the computation request is consistent with the on-chain issued permission, preventing unauthorized third parties from impersonating tokens to steal data or abusing computing resources. In specific implementations, the authorized entity identifier information can be the data requester's digital certificate fingerprint, distributed identity identifier (DID), public key hash, or a specific account address; this application embodiment does not impose any special limitations on this. This authorized entity identifier information, together with the subsequent target data identifier information, constitutes the basic access boundary of the execution token, ensuring that only specific entities can initiate controlled computation for specific data.

[0037] Correspondingly, the target data identifier can refer to the unique index or digest identifier registered in the data registration contract for the data object to be processed. This information is used to strongly bind the execution token to the specific data asset, ensuring that the token can only be used to access its specified data object and preventing the token from being generalized to access other unauthorized data. In specific applications, the target data identifier can be the hash value of the data content, a globally unique ID (Data_ID) generated during data registration, or a cryptographic reference pointer to the data storage location. By linking this information with the policy version information, the system can precisely control which data can be processed by which algorithm under which policy, achieving fine-grained control over the data dimension.

[0038] Correspondingly, the policy version information can refer to the version number or version hash of the data usage policy upon which the execution token was issued. Since data providers may update their data usage policies over time (e.g., adjusting the permitted scope of use or changing the algorithm whitelist), introducing policy version information ensures that the constraints carried by the execution token are strictly consistent with the policy state at the time of issuance, avoiding execution ambiguity caused by dynamic policy changes. This information can be an integer version number, a timestamp, or a Merkle root hash of the policy content. During execution, the off-chain execution proxy module or audit contract can compare the policy version information in the token with the currently effective on-chain policy version to confirm whether the execution is based on the latest valid rules, or whether it is based on a legal rule from a specific historical point in time.

[0039] Correspondingly, algorithm digest information can refer to the digital fingerprint of specific algorithm code or its binary file authorized for processing target data. This information is a key feature for achieving strong algorithm binding, preventing data requesters or execution environments from arbitrarily replacing algorithm logic to circumvent policy restrictions or make malicious inferences. Algorithm digest information can be the output of SHA-256 hash values, SM3 hash values, or other cryptographically secure digest algorithms, and the corresponding algorithms can be machine learning models, statistical analysis scripts, or privacy-preserving computation operators. When the off-chain execution agent module receives a task, it first calculates the digest of the locally loaded algorithm and compares it with the algorithm digest information in the token. Only when the two match completely is the algorithm allowed to be loaded and executed, thus ensuring that data is processed only under approved algorithm logic.

[0040] Correspondingly, the purpose of use information can refer to the business purpose or application scenario description declared by the data requester when applying for data use. This information is used to constrain the output scope of the data processing results and subsequent usage behavior, preventing the data from being used for scenarios other than the purpose declared at the time of application (e.g., using data intended only for scientific research statistics for commercial marketing). The purpose of use information can be a predefined purpose classification code, a text field describing it in natural language, or a semantically encoded structured label. When generating execution receipts or conducting on-chain audits, this purpose of use information can serve as one of the verification criteria, ensuring that the entire calculation process complies with the usage restrictions set by the data provider.

[0041] Correspondingly, the validity period information can refer to the time window or expiration time when the execution token is valid. This information is used to control the timeliness of the execution token, preventing it from being reused or abused at unexpected times after being held for a long period, thus reducing the security risks caused by token leakage. The validity period information can be a specific start and end timestamp, a relative validity period (such as valid for 24 hours after issuance), or a validity range based on the blockchain block height. Once the current time exceeds the range defined by the validity period information, the policy management contract or off-chain execution agent module will reject the token verification request and forcibly terminate the relevant computation tasks, thereby achieving access control in the time dimension.

[0042] Correspondingly, the execution environment proof requirement information can refer to specific requirements for the security metrics or trust metric values ​​of the off-chain execution environment running the computation task. This information is used to ensure that data processing tasks can only run in trusted execution environments (such as TEEs or trusted sandboxes) that meet specific security levels, preventing data leakage caused by execution in insecure general environments. The execution environment proof requirement information can be the metric register value of the Trusted Platform Module (TPM), the expected hash of the remote proof, the requirement of a specific hardware firmware version, or an identifier of the secure startup state. Before task execution, the environment proof unit in the off-chain execution agent module collects the current environment's metric value and matches it with the execution environment proof requirement information in the token. Only when the environment trustworthiness meets the requirements is it allowed to read the target data and perform computation.

[0043] Correspondingly, a random number can refer to an unpredictable random value generated when issuing an execution token, typically used to prevent replay attacks. This information ensures that each execution token is globally unique; even if all other fields (such as subject, data, algorithm, etc.) are identical, different random numbers can distinguish between two independent authorization actions. The random number can be a cryptographically compliant random string or a unique identifier generated by combining blockchain block hashes and timestamps. During the auditing phase, by checking whether the random number has been used, the system can effectively identify and block duplicate submission requests for the same authorized content, ensuring the uniqueness and immutability of execution records.

[0044] Based on this, the aforementioned information items collectively constitute a multi-dimensional constraint system for candidate execution tokens. When managing these candidate execution tokens, the strategy management contract does not store the information in isolation, but rather issues and maintains its state as a holistic data structure. When a data requester initiates a request, the strategy management contract dynamically assembles at least one of the aforementioned information items to generate a unique execution token according to the current policy rules. This token, after being issued to the off-chain execution agent module, becomes the core credential driving the entire controlled computation process. The off-chain execution agent module loads the specified algorithm based on the algorithm digest information in the token, verifies the local environment based on the execution environment proof requirements, calls the data connector to obtain data based on the target data identifier information, and generates an execution receipt containing the aforementioned key information digest after computation is completed. This mechanism ensures that the execution token is not merely a simple access pass, but a digital contract carrying a complete execution context, security constraints, and audit basis, guaranteeing that every step of the data flow process is under strict policy control.

[0045] For example, the data provider first registers a usage policy for sensitive medical data on the blockchain. This policy stipulates that only specific research institutions (allowed entity identification information) are allowed to use designated disease prediction models (algorithm summary information) for analysis, and it must run in a trusted execution environment that has passed high-level security certification (execution environment proof requirement information). The data can only be used for epidemiological research (use purpose information), and the authorization is valid for 7 days (validity information). When a research institution initiates a data usage request, the policy management contract verifies its identity and request parameters. After confirming that it complies with the above policy, it generates an execution token containing all the above fields and a newly generated random number. This token is sent to the off-chain execution agent module deployed in a trusted sandbox within the hospital. The sandbox first verifies whether its own environment metrics match the execution environment proof requirement information in the token. If the match is successful, it uses the target data identification information in the token to call the data connector to read the encrypted medical data and loads a disease prediction model with a hash value consistent with the algorithm summary information in the token for calculation. After the calculation is completed, the system generates an execution receipt, which records the random number used in this execution and the policy version information, and submits it to the blockchain for auditing. Once the information in the audit contract verification receipt matches the token and the random number has not been reused, the execution is confirmed to be legal, and the anonymized statistical results are allowed to be returned to the research institution.

[0046] In summary, a high-security execution token management mechanism based on multi-dimensional information binding is proposed. Because the execution token integrates multiple constraint elements such as the permitted subject, target data, policy version, algorithm digest, purpose of use, validity period, environment proof requirements, and random number, each data usage authorization becomes an independent, complete, and tamper-proof task-level contract. This design solves the problems of single-dimensional token constraints and difficulty in preventing algorithm replacement and environment forgery in existing technologies. It achieves fine-grained, end-to-end control over the data usage process, significantly improving the security and compliance of data circulation in a trusted data space.

[0047] In one or more embodiments of this example, the off-chain execution proxy module is further configured to, upon receiving the execution token and the task information, call the environment verification unit to verify the current execution environment; if the verification result determines that the environment measurement result of the current execution environment matches the execution environment verification requirement information in the execution token, determine that the current execution environment meets the security conditions, and execute the step of calling the data connector to read the target data locally in a controlled manner from the data provider.

[0048] Specifically, verifying the current execution environment by invoking the environment proof unit refers to the process by which the off-chain execution agent module measures and verifies the trusted state of the current runtime environment using a built-in or associated environment proof unit before initiating a specific computation task. This environment proof unit can be a remote proof component within a Trusted Execution Environment (TEE), or a measurement module within a standalone security coprocessor or sandbox environment. Its function is to obtain the runtime state fingerprint of the current hardware, firmware, operating system, and applications—that is, the environment measurement result—and compare this result with the expected standards carried in the execution token. In this technical solution, the environment proof unit works closely with the off-chain execution agent module. Only when the measurement value output by the environment proof unit indicates that the current environment has not been tampered with and meets the preset security baseline will the off-chain execution agent module be authorized to continue subsequent data reading operations, thus constructing the first line of security defense for the execution environment at the system level.

[0049] Accordingly, matching the environment metric result of the current execution environment with the execution environment proof requirement information in the execution token based on the verification result can refer to the operation of comparing the real-time metric value generated by the environment proof unit with the execution environment proof requirement information pre-bound in the execution token. The execution environment proof requirement information in the execution token can refer to the trusted environment characteristic value specified by the data provider or policy management contract when issuing the token, such as the PCR (Platform Configuration Register) value set of a specific version of TEE, a specific firmware hash value, or a specific secure boot chain evidence. The environment metric result can be the actual hash digest of the current running environment. The matching process can adopt field-by-field comparison or overall hash comparison. If they match, the current environment is determined to meet the security conditions, and the process is allowed to proceed; if they do not match, the environment is determined to be untrustworthy, and task execution is terminated. This mechanism ensures that the computing task can only run in a specific environment that has been strictly certified, preventing the task from switching to ordinary or insecure computing nodes for execution.

[0050] Correspondingly, determining that the current execution environment meets security conditions refers to the logical judgment state made by the system based on the above comparison results. This state signifies that the runtime space where the current off-chain execution agent module resides possesses the trustworthy attributes required to process sensitive data. Meeting security conditions means that the current environment is not only physically isolated, but also that the integrity of the software stack has been cryptographically proven. In this state, the off-chain execution agent module is unlocked to access the data connector. This judgment result is the logical hub connecting the two key steps of environment verification and data reading. Its effect is that subsequent data loading instructions are triggered only when the environment is confirmed to be secure; otherwise, the system will enter an exception handling process or deny service, thereby blocking the risk of data leakage in an untrusted environment from the source.

[0051] Accordingly, the step of executing the call to the data connector to read the target data locally and in a controlled manner on the data provider's premises can refer to, after confirming environmental security, the off-chain execution agent module issuing an instruction to the data connector, instructing it to retrieve and load the target data into the current trusted execution environment from the storage domain controlled by the data provider. As a bridge connecting the data storage area and the trusted computing area, the data connector's actions are strictly constrained by the aforementioned security condition determinations. In this step, the data connector locates the data in the data provider's local database based on the data identifier in the task information and transmits the data to the memory space of the off-chain execution agent module through a controlled channel. This process achieves a controlled transfer of data from static storage to dynamic computation, and because the preceding steps have ensured that the receiving environment is trusted, this data reading behavior is considered secure and controllable, meeting the technical requirements that the original data does not leave the domain and is processed in a trusted environment.

[0052] Based on this, the off-chain execution agent module first receives the execution token and task information issued by the execution orchestration module. Then, the module activates the environment verification unit to measure the current hardware and software environment and generate an environment measurement result including the platform configuration register value. Next, the module extracts the execution environment verification requirement information carried in the execution token and compares this requirement information with the real-time generated environment measurement result. If the comparison result shows that the two match, it is determined that the current execution environment meets the security conditions, and then the data connector interface is triggered, instructing the data connector to read the target data in a controlled manner according to the data index on the local machine of the data provider, and load the read data into the current trusted execution environment to wait for algorithm processing. If the comparison result does not match, the process is directly interrupted and no data reading operation is performed.

[0053] For example, suppose a data requester requests to train a financial risk control model. The execution token issued by the strategy management contract specifies that execution must be performed within an Intel SGX v2.18 enclave, and the specific hash value of the PCR register group is Hash_A. The off-chain execution agent module is deployed on a server with SGX capabilities. Upon receiving the token, it calls its local generation mechanism (i.e., the environment proof unit) to obtain the current enclave's metric report. The system compares the MRENCLAVE and MRSIGNER field values ​​in the report with Hash_A in the token. If they match perfectly, the system determines the environment is secure and immediately notifies the data connector located at the front end of the data provider's database to decrypt the encrypted training dataset and stream it to the enclave's internal memory for subsequent algorithm module calls. If the server is maliciously replaced or the firmware version is incompatible, causing the metric value to become Hash_B, the comparison fails, the data connector does not receive a read instruction, and the data remains static, thus avoiding the risk of data being read in plaintext in an unauthorized environment.

[0054] In summary, by making the trusted verification of the execution environment a prerequisite for data reading, and by introducing a mandatory matching mechanism between the environment measurement results and the preset requirements in the execution token, the technical problem that traditional solutions cannot ensure that the computation necessarily occurs in a specified trusted environment is solved. This achieves the technical effect of preventing data from being illegally accessed or leaked in an insecure environment and ensuring that the entire computation process has verifiable environmental evidence.

[0055] In one or more embodiments of this example, the data connector is used to determine the data index information corresponding to the data identifier according to the data registration information pre-registered by the data provider; based on the data index information, the target data is read locally and controlled by the data provider, and the target data is written into the off-chain execution agent module.

[0056] Specifically, a data connector can refer to a data access interface component deployed within the data provider's domain or tightly coupled to its network boundary. Its function is to act as a controlled transmission channel between the original data storage system and the off-chain execution environment. This data connector does not directly expose the underlying storage structure; instead, it operates based on data registration information pre-registered and stored on-chain by the data registration module. Specifically, the data registration information includes a mapping relationship between a data identifier (Data ID) and its physical storage location or logical storage path, i.e., data index information. Upon receiving a task instruction containing the target data identifier, the data connector first queries its local cache or calls the on-chain data registration contract to obtain the data index information corresponding to that data identifier. This data index information can be set according to actual conditions; for example, it can be a primary key index in a database, a file handle in a distributed file system, a resource unique identifier (URI) in object storage, or a memory address pointer, etc. This application embodiment does not impose any special limitations on this.

[0057] Accordingly, based on the acquired data index information, the data connector reads the target data locally and in a controlled manner within the data provider's network. This locally controlled reading means that the data reading operation occurs within the network security boundary managed by the data provider; the data flow does not cross this boundary into the public network or flow directly to the data requester. During the reading process, the data connector can establish a dedicated data transmission channel pointing to the trusted execution environment (such as a TEE or security sandbox) where the off-chain execution agent module resides. This channel can be an internal bus connection based on an encrypted protocol, an inter-process communication (IPC) channel, or a direct LAN link with authentication. In this way, after the target data is read from the storage medium, it is directly written into the memory space of the off-chain execution agent module via this dedicated channel, thereby ensuring that the original data remains under control throughout the transmission and loading process, avoiding the risk of data interception, copying, or plaintext leakage in the intermediate stages.

[0058] Therefore, a close system linkage exists between the data connector, data registration information, and the off-chain execution agent module. The data registration information provides the data connector with addressing information, enabling it to accurately locate specific data objects without traversing the entire database; the off-chain execution agent module provides the data connector with a unique and legitimate data receiving endpoint. When the execution orchestration module issues a task, the data connector, based on the constraints in the token, only allows data to be written to the off-chain execution agent module instance that has passed the environment verification. If the environment metric result of the off-chain execution agent module does not meet the security conditions, the data connector will refuse to establish a write connection or interrupt data transmission. This collaborative mechanism ensures that data is only released into the computation process after confirming the trustworthiness of the computing environment, achieving the dual control objectives of data availability without visibility and the computing environment verifiability.

[0059] For example, in a trusted data space application scenario, the data provider has registered the medical image data to be shared on the blockchain, generating corresponding data hash values ​​and storage indexes. When the data requester initiates an analysis request and obtains an execution token, the execution orchestration module distributes the task to the off-chain execution agent (TEE) module located in the data provider's data center. At this time, the data connector deployed in the same data center parses the target data identifier in the task and queries the local metadata service to obtain the specific sector address or file path of the medical image data in the storage array. Subsequently, the data connector initiates an encrypted memory mapping channel with the security sandbox, directly reading the data stream of the specified sector and injecting it into the isolated memory area of ​​the sandbox. During this process, the data never leaves the data provider's physical server cluster, nor is it written to a temporary disk in the form of a file. Instead, it is directly used as input parameters of the algorithm model and processed within the sandbox. After processing, only the anonymized diagnostic report is output.

[0060] In summary, the data connector effectively locates and transmits target data in a controlled manner based on the pre-registered index. Because the data connector strictly relies on the on-chain registered data index information for addressing, it avoids the maintenance difficulties and security vulnerabilities caused by hard-coded storage paths. Since the data reading and writing processes are restricted to the data provider's local machine and directly connected to the trusted execution environment, it effectively blocks the leakage of raw data during network transmission, ensuring that the data remains within the provider's control throughout its entire lifecycle and meeting the compliance requirement of keeping highly sensitive data within its domain.

[0061] In one or more embodiments of this example, the off-chain execution proxy module is further configured to determine algorithm digest information and policy version information based on the execution token, call the target algorithm to process the target data according to the algorithm digest information and the policy version information, and obtain data processing results; collect input digest information, output digest information, execution log digest information and environment proof information corresponding to the target data processing process, and generate execution receipt information based on the input digest information, the output digest information, the execution log digest information and the environment proof information.

[0062] Specifically, determining the algorithm digest and policy version information based on the execution token refers to the off-chain execution agent module parsing the token payload after receiving the execution token from the execution orchestration module, extracting the bound algorithm digest information (e.g., the hash value of the algorithm code) and policy version information. The algorithm digest information can be a unique identifier for a specific algorithm version pre-approved by the data provider or policy manager, ensuring that subsequent computational logic is consistent with the authorized scope. The policy version information can be the version number of the policy used for the current data, ensuring that the data processing follows the latest valid constraint rules. This technical feature works closely with the execution token, which, as the authorization carrier, carries the aforementioned key constraint parameters. By parsing these parameters, the off-chain execution agent module establishes the whitelist boundaries of the current computation task. Its function is to translate on-chain policy constraints into specific configuration instructions for the off-chain execution environment, thereby ensuring that subsequent computational behavior does not deviate from the preset permitted scope.

[0063] Correspondingly, the target algorithm is invoked to process the target data according to the algorithm summary information and policy version information. The data processing result can refer to the off-chain execution agent module retrieving the locally stored algorithm library based on the extracted algorithm summary information within a trusted execution environment (such as a TEE or security sandbox), loading a specific version of the target algorithm that matches the summary, and performing computational operations on the target data read through the data connector in combination with the running parameters limited by the policy version information. The specific form of the target algorithm can be set according to the actual situation, such as a statistical analysis algorithm, a machine learning inference model, a privacy intersection protocol, or a federated learning local training program, etc. This application embodiment does not make any special limitations on this. There is a clear linkage between this technical feature and the data connector and the target data: after the data connector sends the data into the trusted environment, the off-chain execution agent module immediately locks the specified target algorithm for consumption. This data + specific algorithm binding execution mechanism ensures that the original data can only be processed by authorized logic, preventing the requester from arbitrarily replacing the algorithm for out-of-scope mining or reverse analysis. Its working result is to generate intermediate or final data processing results that meet the policy requirements.

[0064] Correspondingly, the input summary information, output summary information, execution log summary information, and environment proof information collected during the target data processing process can refer to the multi-dimensional state snapshots automatically captured and calculated by the off-chain execution agent module at key nodes during or after the target algorithm has been executed. Input summary information can be the hash value or Merkle root of the target data to be processed, used to prove that the actual data source involved in the computation is consistent with the authorized data; output summary information can be the hash value of the data processing result, used to solidify the computational output; execution log summary information can be the hash value of a log file recording the sequence of operations such as algorithm execution steps, resource consumption, and anomaly capture; environment proof information can be a remote proof report generated by a trusted execution environment, including environmental metrics and a signature. The specific format and collection frequency of these information can be set according to actual audit requirements, for example, it can be real-time streaming collection or batch collection after the task is completed. This application embodiment does not impose any special limitations on this. This technical feature forms a causal relationship with the aforementioned data processing steps, that is, it automatically generates an immutable digital fingerprint at every key link in data flow and computation. Its function is to build a full-link evidence chain to ensure the transparency and traceability of the execution process.

[0065] Accordingly, generating execution receipt information based on input summary information, output summary information, execution log summary information, and environment proof information can refer to the off-chain execution agent module structurally encapsulating the aforementioned multi-dimensional information to form a complete execution receipt. This execution receipt information can be a data packet or digital certificate containing all summary fields, timestamps, execution entity identifiers, and environment signatures. The specific data structure of the execution receipt information can be set according to the interface requirements of the blockchain audit contract, for example, it can be a collection of key-value pairs in JSON format or a serialized object with binary encoding; this application embodiment does not impose any special limitations on this. This technical feature, as the endpoint of the entire off-chain execution process, forms an upstream-downstream cooperative relationship with the on-chain audit module: off-chain generates receipts, and on-chain verifies receipts. By aggregating scattered execution evidence into a single execution receipt, this technical feature realizes the transformation from black-box execution to white-box evidence presentation, and its result is the production of a standardized audit certificate that can be directly verified by a third party or smart contract.

[0066] Based on this, the off-chain execution proxy module first parses the execution token to obtain the fingerprint information of the algorithm and strategy, which serves as the index key for calling the local algorithm library, ensuring that only the approved code version can be loaded and run. Subsequently, while data flows into the trusted environment and is processed by the algorithm, the system simultaneously initiates an evidence collection mechanism to perform real-time hash calculations and signature authentication on the input data, output results, execution trajectory, and running environment. Finally, these discrete evidence fragments are assembled into a structured execution receipt. This process utilizes the collision resistance of cryptographic digests and the isolation of the trusted execution environment, ensuring that any tampering with the algorithm, data substitution, or environment forgery will result in a mismatch between the generated receipt information and the token information recorded on the chain, thus guaranteeing the compliance and authenticity of the data processing process.

[0067] For example, suppose a data requester requests disease risk scoring on a medical dataset. The execution token is bound to a specific risk scoring algorithm hash value H_algo and strategy version V1. After receiving the token in the TEE environment, the off-chain execution agent module first searches its local algorithm repository for an algorithm package with the hash value H_algo. If not found or the hash does not match, execution terminates; if a match is found, the algorithm is loaded. Next, the data connector decrypts the encrypted medical data and sends it to the TEE, where the algorithm begins running. During this process, the monitoring component within the TEE calculates the hash H_in of the input data and the hash H_out of the output result after the algorithm outputs the scoring result. Simultaneously, it records an execution log containing information such as algorithm start time, memory usage, and no abnormal exits, and calculates its hash H_log. Finally, it calls TEE hardware instructions to generate a proof report containing current environment metrics. Ultimately, the off-chain execution agent module packages and signs {H_in, H_out, H_log, proof report, timestamp, token ID} to generate an execution receipt, ready to be submitted to the blockchain for auditing.

[0068] In summary, by embedding algorithm summaries and policy versions into the execution process and enforcing verification, the risk of illegal algorithms or unauthorized versions being invoked is eliminated. Furthermore, by automatically collecting multi-dimensional summaries of inputs, outputs, logs, and the environment during processing and generating execution receipts, a complete and irrefutable chain of execution evidence is constructed. This allows the on-chain auditing module to accurately verify whether data has been processed in accordance with the agreed-upon method, thus solving the technical problems of difficulty in controlling data usage and the inability to verify execution behavior in existing technologies.

[0069] In one or more embodiments of this example, the off-chain execution proxy module is further configured to submit the execution receipt information to the blockchain, where an audit contract on the blockchain verifies the execution receipt information. If the verification result determines that the execution receipt information meets the verification conditions, the module executes the step of sending the data processing result to the data requester.

[0070] Specifically, submitting execution receipt information to the blockchain can refer to the off-chain execution agent module, after completing local controlled computation and generating structured execution receipt information, initiating an on-chain call using this execution receipt information as transaction payload through a pre-built blockchain client interface or gateway. This execution receipt information can be a digital credential containing key fields such as input digest, output digest, algorithm identifier, strategy version, and environment proof. In trusted data space application scenarios, this step functions to transform off-chain physical execution behavior into traceable and tamper-proof digital records on the blockchain, thereby establishing a trust bridge between off-chain execution and on-chain auditing. This step works closely with the subsequent verification step by the audit contract, forming a logical premise of submission before verification, ensuring that all computation results to be released are reviewed by the on-chain consensus mechanism. Specifically, the submission process can adopt asynchronous broadcasting or synchronous waiting for confirmation, which can be set according to the throughput and real-time requirements of the actual system; this application embodiment does not impose special limitations on this.

[0071] Correspondingly, the verification of execution receipt information by an audit contract on the blockchain refers to the process by which smart contract code deployed in the blockchain network automatically receives and submits execution receipt information, and automatically verifies it according to preset verification logic. This audit contract can be a piece of program logic embedded in the blockchain virtual machine, its core role being to act as a decentralized arbitrator, replacing the auditing function of traditional centralized servers. In system linkage, the audit contract needs to call the strategy management contract state, token state, and data registration information stored on the chain, comparing the fields in the execution receipt with the original authorization information recorded on the chain. For example, the audit contract checks whether the execution token hash carried in the receipt matches the token issued on the chain, whether the environment proof in the receipt meets the security requirements bound to the token, and the token's validity period and replay status. Only when all the above verification items pass will the audit contract determine that the verification is successful. This cooperative relationship ensures the transparency and non-repudiation of the verification process; any attempt to forge receipts or bypass verification will be blocked because it cannot pass the contract logic verification.

[0072] Accordingly, if the verification result determines that the execution receipt information meets the verification conditions, it means that after the audit contract completes the above comparison logic, it outputs a clear Boolean verification result or status code. This result indicates whether the current execution process fully complies with the data provider's preset usage strategy and security constraints. Situations where the verification conditions are met can include: the execution token is legal and valid, the algorithm fingerprint matches, the execution environment metrics are compliant, and data usage is within the permitted scope and not repeated. If the verification result is true (i.e., the conditions are met), the subsequent result release process is triggered; if the verification result is false, an exception handling process is triggered, such as refusing to send the result, recording the violation event, or freezing relevant permissions. This technical feature acts as a security gate in the overall solution. Its working result is the generation of a release instruction endorsed by on-chain consensus, which is the only legitimate basis for the external transmission of data processing results.

[0073] Accordingly, the step of sending the data processing result to the data requester can refer to the process where, after receiving the verification pass instruction from the audit contract, the off-chain execution agent module or the result distribution unit communicating with it transmits the data processing result previously generated in the trusted execution environment to the data requester through a network channel. The sent data processing result can be the final computational product after de-identification, aggregation, or encryption, rather than the original plaintext data. This step has a strict causal dependency with the preceding verification step; that is, the sending action is only allowed after the on-chain audit contract confirms the verification pass. This linkage mechanism realizes the control logic of separation of audit and issuance and audit before issuance, ensuring the legitimacy of the result obtained by the data requester. Regarding the specific sending method, it can be direct point-to-point transmission, delivery through an intermediate message queue, or push to the storage address specified by the requester through an encrypted channel; this application embodiment does not impose any special limitations on this.

[0074] Based on this, after the off-chain execution agent module completes data computation in a trusted environment and generates an execution receipt containing complete proof information, it does not immediately return the result to the data requester. Instead, it first submits the receipt to the blockchain network. The audit contract on the blockchain is triggered to execute, automatically reading the benchmark data related to the task stored on the chain, such as the execution token, policy version, and environment requirements, and comparing the actual execution information in the receipt with the benchmark data item by item. If any inconsistency is found (such as algorithm tampering, insecure environment, or expired token), the audit contract will determine that the verification has failed and block the result sending process; if all comparison items are consistent, the audit contract determines that the verification has passed and sends a confirmation signal to the off-chain execution agent module. Only after receiving the confirmation signal does the off-chain execution agent module release the lock on the data processing result and formally send it to the data requester.

[0075] For example, suppose a data requester requests credit score calculation for certain financial risk control data. The off-chain execution proxy module performs the calculation using a specified algorithm within the TEE environment, generating a score result and an execution receipt containing the algorithm hash, TEE remote proof, and input data hash. Subsequently, the proxy module calls the blockchain transaction interface to submit the receipt to the audit contract. The audit contract runs automatically, first verifying whether the token ID in the receipt exists in the list of valid tokens on the chain, then comparing whether the algorithm hash in the receipt matches the whitelist algorithm hash bound to the token, and then verifying whether the signature of the TEE remote proof was issued by a trusted certification authority and whether the metric meets the policy requirements. After all verifications pass, the audit contract updates the token status to "executed" and triggers a verification pass event. The off-chain execution proxy module listens for this event, and once captured, immediately sends the credit score result to the data requester through an encrypted channel. If, during this process, someone attempts to replace the algorithm, causing a hash mismatch, the audit contract will directly determine failure, and the score result will be permanently intercepted within the system and will not be leaked to the requester.

[0076] In summary, by introducing an audit contract on the blockchain as an independent third-party verification node to automatically and immutably verify off-chain execution receipts, a mandatory control mechanism of auditing before release is established. Since only receipts verified by the on-chain contract can trigger the result sending action, the risk of the off-chain execution proxy module being maliciously tampered with or bypassing policy restrictions to privately output illegal results is effectively prevented. This ensures the compliance of the data usage process and the credibility of the results, solving the technical problem of lacking credible verification and closed-loop control of execution behavior in existing technologies.

[0077] In one or more embodiments of this example, the audit contract is used to verify whether the binding relationship between the execution receipt information and the execution token is correct, whether the input information, algorithm information and policy version information in the execution receipt information are the same as the execution token, whether the execution environment proof information corresponding to the current execution environment meets the security conditions, and whether the execution token is within its validity period and has not been reused.

[0078] Specifically, verifying the binding relationship between execution receipt information and execution tokens can involve the audit contract using cryptographic means or logical verification mechanisms to confirm whether the execution receipt information submitted to the blockchain was indeed generated by an execution task triggered by the specific execution token issued. The function of this technical feature is to establish a unique correspondence between execution results and execution authorization, preventing the creation of forged audit records through misattribution. In its implementation, the execution token may contain a random number or a specific session identifier, while the execution receipt information must carry the hash value or plaintext reference of that random number or session identifier. During verification, the audit contract compares the identifier information in the execution receipt with the issued but not expired execution token information stored on the blockchain. If they match, the binding relationship is deemed correct. This cooperative relationship ensures that every off-chain computation can be traced back to a unique on-chain authorization source, resulting in only legally bound execution receipts being allowed to enter the subsequent audit approval process.

[0079] Correspondingly, verifying whether the input information, algorithm information, and strategy version information in the execution receipt are identical to the execution token can refer to the audit contract checking the consistency of key elements during execution. Here, input information can refer to the summary information of the target data (such as a hash value), algorithm information can refer to the code summary or version number of the called algorithm, and strategy version information can refer to the version identifier of the data policy used during execution. The role of this technical feature in the overall technical solution is to prevent data tampering, algorithm replacement, or strategy bypassing. For example, the input summary generated by the data connector after reading the data is compared with the summary corresponding to the target data identifier specified in the execution token; the algorithm summary called by the off-chain execution proxy module must be completely consistent with the algorithm summaries allowed in the whitelist of the execution token; and the strategy version loaded during execution must also match the strategy version at the time of token issuance. Through the above coordination, the audit contract can confirm that the actual off-chain computation strictly follows the constraints of on-chain authorization, and the resulting work will result in verification failure for any deviation from the data, algorithm, or strategy, thereby blocking the output of illegal results.

[0080] Correspondingly, verifying whether the execution environment proof information corresponding to the current execution environment meets the security conditions can refer to the audit contract verifying the remote attestation report or environment metric provided by the off-chain execution proxy module. This technical feature is named based on its function of confirming the trustworthiness of the computing environment. During the execution token issuance phase, the metric benchmarks that the execution environment must meet (such as specific TEE types, firmware version hashes, etc.) may have already been specified. When the off-chain execution proxy module completes the task and submits a receipt, it must also attach environment proof information signed by the hardware root of trust. The audit contract uses a pre-built public key or a referenced verification contract to verify the signature validity and content integrity of this proof information, and determines whether its metric falls within the security range specified by the execution token. This technical feature, in conjunction with the execution environment proof requirement information in the execution token, ensures that computing tasks only run in recognized trusted execution environments (such as TEE sandboxes), thus eliminating the possibility of executing tasks in untrusted or tampered environments.

[0081] Correspondingly, verifying whether an execution token is within its validity period and has not been reused can refer to the audit contract checking the timestamp status and historical usage records of the execution token. This technical feature is used to solve the problems of token validity control and prevention of replay attacks. The validity period information can be a time window recorded in the execution token. The audit contract compares the current block time or transaction time with the token's validity period. If it exceeds the range, it is determined to be invalid. Preventing reuse can be achieved by querying the on-chain state machine. For example, each execution token is in an unused state when it is issued. Once a valid execution receipt is verified and uploaded to the chain, the token's state is updated to used or cancelled. If another execution receipt based on the same token is received, and the audit contract detects that its state is no longer unused, it is determined to be reused. This technical feature, combined with the immutability of the blockchain, results in the complete blocking of expired tokens or maliciously replayed old tokens from passing through the audit, ensuring the uniqueness and freshness of each data usage behavior.

[0082] Based on this, upon receiving the execution receipt information and associated execution token identifier submitted by the off-chain execution proxy module, the audit contract first extracts the binding identifier (such as a random number) from the receipt, retrieves the corresponding execution token record in the on-chain ledger, and confirms that the attribution relationship between the two is correct. Subsequently, it compares in parallel or sequentially whether the data hash, algorithm hash, and strategy version carried in the receipt are completely consistent with the parameters locked in the token. Next, it calls the verification logic to parse the hardware environment proof attached to the receipt, confirming that its signature is valid and its metric meets the security baseline set by the token. Finally, it checks the token's validity period field and queries its current status flag, confirming that it has not expired and has not been marked as executed. Only when all four verifications pass does the audit contract determine that the execution is compliant, write the audit results to the blockchain, and update the token status.

[0083] For example, suppose a data requester initiates a data analysis task. The execution orchestration module issues an execution token containing a random number Nonce_123, an allowed algorithm Hash_Algo_A, a policy version V1.0, and an expiration time T_end. After completing the task in the TEE environment, the off-chain execution proxy module generates an execution receipt containing the input data hash Hash_Data_X, the actual running algorithm hash Hash_Algo_A, the policy version V1.0, the TEE remote proof, and the random number Nonce_123. When this receipt is submitted to the audit contract on the blockchain, the contract first verifies whether the Nonce_123 in the receipt matches the execution token in the unused state on the chain with the above parameters; secondly, it compares whether Hash_Data_X, Hash_Algo_A, and V1.0 are consistent with the token record; thirdly, it verifies whether the remote proof was issued by the trusted hardware root and whether the internal metric meets the token requirements; finally, it confirms that the current time is less than T_end and the token has not yet been marked as audited. If any step is mismatched (e.g., the algorithm hash is tampered with to Hash_Algo_B, or Nonce_123 has been marked as used), the audit contract will directly reject the receipt and will not generate any on-chain audit pass record, thereby preventing the data processing result from being sent to the data requester.

[0084] In summary, because the audit contract cross-validates the binding relationship between execution receipts and execution tokens, the consistency of key parameters, the credibility of the execution environment, and the timeliness and uniqueness of tokens from multiple dimensions, a highly robust automated audit mechanism is constructed. This mechanism can effectively identify and intercept violations such as forged receipts, tampering with the calculation process, execution in untrusted environments, and replay attacks, ensuring the traceability and non-repudiation of data usage within the trusted data space.

[0085] In one or more embodiments of this example, the off-chain execution proxy module is further configured to update the data processing result according to preset output granularity information and usage restriction information, obtain the target data processing result, and send the target data processing result to the data requester.

[0086] Specifically, output granularity information can refer to constraints on the data processing results in terms of data dimension, precision level, or statistical aggregation degree. In this application, the output granularity information is associated with the strategy version information or data usage strategy in the aforementioned execution token, and is used to limit the final data format delivered to the data requester. For example, when the original data processing result contains detailed transaction records, the output granularity information can specify that only the total transaction amount calculated daily is output, or only the risk score value after anonymization is output, without exposing specific counterparty information. The specific content of this output granularity information can be set according to the security level requirements of the actual business scenario. For example, it can be field-level filtering (keeping only specific columns), row-level aggregation (calculating statistics such as mean and variance), truncation of numerical precision (keeping two decimal places), or noise addition (differential privacy processing). This application embodiment does not impose any special limitations on this. By setting the output granularity information, the off-chain execution agent module can perform secondary processing on the original calculation results before the data leaves the trusted execution environment, ensuring that the data delivered to the data requester meets the minimum necessity principle and preventing the leakage of sensitive information due to overly detailed results.

[0087] Correspondingly, usage restriction information can refer to the constraint description on the subsequent use, application scenarios, or circulation scope of the data processing results. In this application, the usage restriction information corresponds to the purpose declared by the data requester during the application stage and the permitted uses verified by the strategy management contract. For example, if the purpose declared in the data application request is to build a credit assessment model, the usage restriction information can mark that the target data processing result is limited to model training or inference use and is prohibited from being used for direct marketing, user profile building, or resale to third parties. This usage restriction information can be embedded in the target data processing result in the form of metadata tags, digital watermarks, or access control lists, or sent as a separate policy file along with the result. When generating the target data processing result, the off-chain execution agent module will encapsulate or mark the result according to the usage restriction information, so that after receiving it, the data requester's local system or subsequent processing flow can identify and enforce the corresponding usage constraints. This mechanism realizes the extension from data access control to data usage control, ensuring that even after the data flows out of the controlled environment, its usage behavior is still constrained by the preset policy.

[0088] Correspondingly, the process by which the off-chain execution agent module updates the data processing results can refer to performing pruning, aggregation, desensitization, tagging, or encapsulation operations on the initially calculated data processing results based on output granularity information and usage restriction information. In specific implementations, the off-chain execution agent module resides within a trusted execution environment (such as a TEE or security sandbox). After completing the core algorithm calculation and obtaining the initial data processing results, it does not directly output the results but first reads the policy parameters bound to the current execution task. Subsequently, the output control unit within the module calls the corresponding data processing functions (such as aggregation functions, mask generators, noise adders, etc.) to transform the initial results based on the output granularity information; simultaneously, based on the usage restriction information, it generates corresponding usage constraint metadata and binds it to the transformed results. The complete data packet obtained after the above processing is the target data processing result. This process ensures that any data details not permitted by the policy cannot escape the trusted execution environment, and the output data carries an immutable usage constraint identifier.

[0089] Based on this, after the off-chain execution proxy module receives the execution token and completes the controlled computation of the target data, it obtains the preliminary data processing result. At this point, the module immediately triggers the output compliance verification process, extracting the preset output granularity information and usage restriction information from the execution token or the locally cached policy context. The module first parses the output granularity information to determine what granularity of transformation operation needs to be performed on the preliminary result, such as converting detailed data into statistical reports or converting high-precision values ​​into low-precision range values; then it parses the usage restriction information to generate the corresponding usage constraint description. Subsequently, the module performs a data update operation within the trusted execution environment, transforming the preliminary result into the target data processing result that conforms to the above constraints. Finally, the module sends the target data processing result to the data requester through a secure channel. Throughout the entire process, the original data and intermediate computation details remain within the trusted execution environment; only the target result, after policy filtering and constraint encapsulation, is released, thus ensuring the flow of data value while strictly adhering to the bottom line of data security and privacy protection.

[0090] For example, suppose a data requester requests to use a bank's transaction data for anti-fraud model training. The execution token issued by the strategy management contract specifies that the output granularity is to return only a fraud probability score (a floating-point number between 0 and 1, rounded to two decimal places), and the usage is restricted to model training only, prohibiting its use for customer marketing. The off-chain execution agent module calls the anti-fraud algorithm in a trusted execution environment to process the transaction data, obtaining a detailed result set containing the user ID, transaction feature vector, and original fraud score. Subsequently, based on the output granularity information, the module discards the user ID and transaction feature vector, retaining only the fraud score field, and rounds the score value to two decimal places. Simultaneously, based on the usage restriction information, it writes a digital watermark or usage license label for model training only to the output file. The final generated target data processing result is only a series of anonymous fraud score values, which are sent to the data requester. The data requester cannot reconstruct the original transaction data, nor can it use the score result for marketing scenarios, thus achieving data usability without visibility and controllable usage.

[0091] In summary, because the off-chain execution agent module introduces a result update mechanism based on output granularity information and usage restriction information, the system implements strict policy filtering at the final stage of data computation. This effectively prevents the leakage of sensitive information and unauthorized use due to overly detailed output results or uncontrolled usage, achieving the technical effect of maximizing the reduction of privacy and compliance risks while ensuring the value of data circulation.

[0092] In one or more embodiments of this example, the system further includes a data registration module; The data registration module is used to receive data identification information submitted by the data provider, generate data hash value, version information and data index information according to the data identification information, construct data registration information based on the data hash value, version information and data index information, and write the data registration information into the data registration contract on the blockchain.

[0093] Specifically, a data registration module can refer to a logical unit or physical device deployed within a trusted data space, specifically responsible for managing data asset metadata and storing it on-chain. The primary function of this module is to act as a trust anchor for data circulation, establishing a unique digital identity for each piece of data to be shared or circulated without uploading the original data content. The data registration module interacts directly with data providers, receiving their basic registration requests and communicating with the data registration contract on the blockchain. It then solidifies the generated registration information in the distributed ledger, ensuring that all subsequent access control, policy verification, and audit traceability for this data are traceable. When registering data assets and generating or recording identification information related to data objects, the data registration module may include data object identifiers, data content summaries, data version numbers, data storage location references, and data provider representations. This ensures that only data identification and location information is registered on-chain or in a referenceable on-chain location, without uploading the original data content.

[0094] Correspondingly, data identification information can refer to a character sequence, code, or name specified by the data provider to distinguish different data objects at the business level. The specific form of this data identification information can be set according to the actual situation; for example, it can be an internal data asset number, a globally unique identifier (UUID), or a combination of data generation time and source. The purpose of data identification information is to provide a clear target for subsequent policy binding and execution token issuance, enabling the system to accurately identify which data asset the current operation is targeting.

[0095] Correspondingly, a data hash value can refer to a fixed-length digest string obtained by calculating the original data content using cryptographic hash algorithms (such as SHA-256, SM3, etc.). The generation of data hash values ​​is typically performed locally by the data registration module after receiving the original data or data file submitted by the data provider, or pre-calculated and submitted by the data provider. The core role of the data hash value in the current scheme is to uniquely identify the integrity and authenticity of the data content: any minor alteration to the original data will cause a drastic change in the hash value. Therefore, once the data hash value is written into the data registration contract, it becomes the benchmark for verifying whether the data used in subsequent off-chain execution has been tampered with, achieving content ownership confirmation under the premise that the data is usable but not visible.

[0096] Correspondingly, version information can refer to an identifier used to record the history of changes or state iterations of a data object. The specific form of version information can be an integer sequence (such as v1.0, v2.0), a timestamp, or a hash pointer; this application embodiment does not impose any special limitations on this. The use of version information in conjunction with data hash values ​​enables dynamic management of data assets: when data content is updated, a new data hash value is generated and the version information is incremented, reconstructing the data registration information and putting it on the chain, while the old version record remains on the chain for traceability. This mechanism ensures that when executing token issuance, a specific version of the data can be accurately locked, avoiding policy execution deviations caused by data updates.

[0097] Correspondingly, data index information can refer to a reference address or path description pointing to the actual storage location of the original data. Since the original data is typically stored in the data provider's local database, file system, or object storage, and is not directly uploaded to the blockchain, the data index information acts as a map for navigation. The specific content of the data index information can be flexibly set according to different storage architectures; for example, it can be a Uniform Resource Locator (URL), an object bucket key, a database primary key ID, or an encrypted storage path. In the current scheme, the data index information is encapsulated in the data registration information for subsequent data connector modules to call, enabling precise location and retrieval of target data in a controlled environment without exposing the data entity itself on the blockchain.

[0098] Correspondingly, data registration information can refer to a structured data set composed of the aforementioned data hash value, version information, and data index information. The process of constructing data registration information is the process of integrating scattered metadata elements into a complete on-chain record. This data registration information may also include other auxiliary information such as data provider identifiers, data category tags, and creation time, as long as the original data content is not disclosed. As an input parameter of the data registration contract, the completeness and accuracy of the data registration information directly determine the effectiveness of subsequent data usage control.

[0099] Correspondingly, a data registration contract can refer to a smart contract code instance deployed on a blockchain network, specifically used to store and manage metadata records of all registered data. Data registration contracts possess the characteristics of being immutable and publicly verifiable (or verifiable within the permissioned blockchain). When the data registration module writes data registration information into the data registration contract, it is actually creating a permanent record on the blockchain ledger. This record not only establishes the legal identity of the data asset but also provides an authoritative verification source for the strategy management contract when issuing execution tokens: the strategy management contract can query the data registration contract to confirm whether the target data requested by the requester exists, whether its hash value matches, and whether the current version is valid.

[0100] Based on this, firstly, the data provider submits the identification information and original data (or pre-calculated hash value) of the data to be registered to the data registration module through a secure channel. Next, the data registration module performs a hash operation on the original data to generate a data hash value, and combines this with the current version number to generate version information. Simultaneously, it extracts or generates data index information pointing to the original data storage location. Subsequently, the data registration module packages the above information to construct data registration information. Finally, the data registration module calls the blockchain interface, triggering the write method of the data registration contract, broadcasting the data registration information to the blockchain network, and storing it on the chain after consensus confirmation. Throughout this process, the original data remains within the data provider's domain; only the metadata is uploaded to the chain, achieving cross-entity trusted verification.

[0101] For example, in a joint financial risk control scenario, Bank A, as the data provider, possesses a batch of anonymized corporate credit records. Bank A wishes to provide data computation services to Insurance Company B through a trusted data space, but does not want to directly deliver the raw data. Bank A first calls the data registration module of this application, submitting the data identifier Credit_Data_2023_Q4. The data registration module locally calculates the SHA-256 hash value of this batch of data as 0xabc...123, marks the version as v1, and generates a data index pointing to Bank A's internal secure storage area internal_db: / / risk_table_09. The data registration module then constructs data registration information containing the above fields and writes it into the data registration contract on the consortium blockchain. Subsequently, when Insurance Company B initiates a computation request, the system can confirm the existence and tamper-proofing of the data by querying the contract, and retrieves the data in a controlled environment based on the index for modeling. Ultimately, only the risk scoring result is returned to Insurance Company B, and the raw data never leaves Bank A's controlled domain throughout the entire process.

[0102] In summary, by introducing an independent data registration module and storing data hash values, version information, and data index information on the blockchain as data registration information, a unique digital identity and an immutable metadata management system for data assets within a trusted data space are established. Because the original data itself is not recorded on the blockchain, but only its index and summary are registered, traceability and verifiability of the entire data flow process are achieved while ensuring data privacy and security, providing a solid foundation of trust for subsequent fine-grained use control based on execution tokens.

[0103] In one or more embodiments of this example, the system further includes a policy management module; The strategy management module is used to receive the data usage strategy submitted by the data provider, determine the strategy identifier and strategy version information corresponding to the data usage strategy, and write the strategy identifier and strategy version information into the strategy management contract on the blockchain; wherein, the data usage strategy includes at least one of the following: user scope information, permitted use information, algorithm whitelist, time window information, call frequency information, output granularity information, and export restriction information, and the data usage strategy is used to verify the data application request and issue the execution token.

[0104] Specifically, the strategy management module refers to a logical functional unit deployed within or connected to the trusted data space. Its core function is to provide data providers with interfaces for strategy definition, version management, and on-chain notarization. This strategy management module interacts with the aforementioned execution orchestration module. Specifically, after the strategy management module writes the confirmed strategy identifier and version information into the strategy management contract on the blockchain, the execution orchestration module, upon receiving a data request, must invoke the strategy management contract to obtain the latest strategy rules, thereby verifying the request parameters and issuing subsequent execution tokens. The strategy management module's functional role in the overall technical solution is to establish the source of rules for data usage, ensuring that all downstream execution behaviors are based on a unified, tamper-proof, and traceable strategy benchmark. Through this collaboration, the system achieves a transformation from static strategy configuration to dynamic execution control, ensuring that the authorization of each data computation task is strictly constrained by the rules preset by the data provider. In essence, the policy management module is mainly used to register and maintain data usage policies. Policies can include information such as the scope of applicable subjects, permitted uses, algorithm whitelist, time window, call frequency, output granularity, whether export is allowed, and whether intermediate results are required to be deleted. After policy registration, a corresponding policy identifier and policy version are generated for subsequent policy verification and token issuance.

[0105] Correspondingly, a data usage policy can refer to a set of one or more rules formulated by the data provider to limit how, by whom, and under what conditions data is used. In this application, the data usage policy is not a simple access permission list, but rather contains multi-dimensional, fine-grained control elements. For example, the scope of the user can be used to limit which specific identifiers (such as organization ID, user public key hash, etc.) are authorized to initiate computation requests for the data; the permitted use information can be used to define the specific business scenarios in which the data is processed, preventing the data from being misused; the algorithm whitelist can be used to limit only specific hash values ​​or specific versions of algorithm programs to operate on the data, thereby preventing malicious algorithms from stealing data characteristics; the time window information can be used to set the start and end times of the policy's effectiveness, achieving timeliness control; the call frequency information can be used to limit the maximum number of requests per unit time, preventing resource abuse; the output granularity information can be used to constrain the level of detail of the computation results returned to the requester, such as returning only statistical values ​​and prohibiting the return of detailed data; and the export restriction information can be used to specify whether the computation results are allowed to be taken out of the current execution environment or whether secondary distribution is allowed. The specific content of these data usage strategies can be flexibly combined and set according to actual business needs, and this application embodiment does not impose any special limitations on this. The cooperation between the data usage strategy and the strategy management module is manifested in that the data provider submits the above-mentioned strategy content through the strategy management module, the strategy management module parses and encodes it and generates a unique strategy identifier and version number, thereby driving the strategy management contract on the blockchain to update its state.

[0106] Based on this, the data provider first submits an initial data usage policy to the policy management module via a client or management terminal. The policy includes at least one of the aforementioned pieces of information, such as the user entity, purpose, and algorithm constraints. Upon receiving the submission, the policy management module performs a preliminary verification of the policy content's format and legality, and generates a corresponding policy ID and policy version information according to preset rules. Subsequently, the policy management module calls the blockchain node interface, sending the generated policy ID, policy version information, and a summary or complete encoded data of the policy content as the transaction payload to the blockchain network. Upon receiving the transaction, the policy management contract on the blockchain executes its contract logic to persistently store the policy information in the on-chain ledger and returns a confirmation message indicating successful on-chain storage. Afterward, when a data requester initiates a data request, the execution orchestration module reads the latest version of the policy information stored in the on-chain policy management contract and uses it as the verification basis. If the request parameters meet the on-chain policy's requirements, the execution token issuance process is triggered; otherwise, the request is rejected. The entire process ensures the transparency, consistency, and non-repudiation of policy execution.

[0107] For example, in a medical research data sharing scenario, a hospital, as the data provider, wants to make its anonymized medical record data available to research institutions for disease model training. However, it requires the use of a certified privacy-preserving algorithm, access only during working hours on weekdays, and the output results must not contain any plaintext information at the individual level. In this case, the hospital's operators submit a data usage policy through the policy management module. This policy explicitly limits: the user scope to certified research institution A; the permitted use is disease prediction model training; the algorithm whitelist is the algorithm hash value Hash_Algo_V1.0; the time window is Monday to Friday 09:00-18:00; and the output granularity is only aggregated statistical results. After receiving the policy, the policy management module generates a policy identifier P_2023_MED_001 and version number V1, and calls a smart contract to write this information to the blockchain. When research institution A initiates a computation request, the system automatically retrieves the relevant strategy from the blockchain for comparison. If the request is made outside of working hours or the algorithm version used in the request is incompatible, the request is directly intercepted and no execution token is issued, thus ensuring the compliance and security of data usage at the source.

[0108] In summary, by transforming diverse and complex data usage rules into executable and verifiable code logic on the blockchain, the policy management module can standardize and store policy information across multiple dimensions, including user, purpose, algorithm, time, and output restrictions, on the blockchain. This ensures that all subsequent data access and computation behaviors operate within the pre-defined rule framework, effectively solving the problems of opaque policy execution, difficulty in dynamic adjustment, and lack of fine-grained control in existing technologies. This improves the automation level and security boundaries of trusted data space governance.

[0109] See Figure 2The diagram shows that the data registration module, policy registration module, execution orchestration module, and off-chain execution agent module (TEE / sandbox) are all deployed in the trusted data space. To ensure data security, data providers can submit data registration information to the data registration module, which registers data_id, data_hash, version information, etc., and uploads them to the data registration contract on the blockchain. Simultaneously, data providers can register usage policies, registering policy_id, policy_version, etc., to the policy registration contract on the blockchain through the policy registration module. Upon receiving a data usage request from a data requester, the execution orchestration module can submit request parameters and request a token. The on-chain policy registration contract verifies and issues the token, returning it to the execution orchestration module. The token and task can then be issued to the environment proof unit in the TEE / sandbox, where a trusted execution environment verification can be performed. If verification is successful, data can be read according to the data index through the data connector, and the program can be executed, calculating the execution receipt. By submitting the receipt to the receipt audit contract on the blockchain for processing, the binding relationship between the receipt and the token can be verified. The execution receipt is simultaneously uploaded to the blockchain, and finally, the processed data results can be fed back to the data requester according to the policy restrictions, ensuring data security for use by the data requester.

[0110] Corresponding to the above system embodiments, this specification also provides embodiments of a trusted data space off-chain controlled computation and auditing method based on execution tokens. Figure 3 This is a flowchart illustrating an embodiment of a trusted data space off-chain controlled computation and auditing method based on execution tokens, as provided in this specification. Figure 3 As shown, the method includes: Step S302: Receive the data request submitted by the data requester, and call the strategy management contract on the blockchain to verify the request parameters corresponding to the data request.

[0111] Step S304: If the verification passes, the strategy management contract issues an execution token and determines the task information corresponding to the data request.

[0112] Step S306: If the current execution environment meets the security conditions based on the task information and the execution token, the data connector is invoked to read the target data locally in a controlled manner from the data provider.

[0113] Step S308: Process the target data according to the execution token to obtain data processing results and execution receipt information.

[0114] Step S310: If the execution receipt information meets the verification conditions, the data processing result is sent to the data requester.

[0115] In one optional embodiment, the data request is parsed to obtain the requester's identity identifier, target data object, purpose information, target algorithm identifier, algorithm version information, and output result requirement information; the strategy management contract on the blockchain is invoked to verify the requester's identity identifier, the target data object, the purpose information, the target algorithm identifier, the algorithm version information, and the output result requirement information.

[0116] In one optional embodiment, the strategy management contract manages multiple candidate execution tokens, wherein any candidate execution token includes at least one of the following information: permitted subject identification information, target data identification information, strategy version information, algorithm digest information, purpose of use information, validity period information, execution environment proof requirement information, and random number.

[0117] In an optional embodiment, upon receiving the execution token and the task information, the environment verification unit is invoked to verify the current execution environment; if the verification result determines that the environment metric result of the current execution environment matches the execution environment verification requirement information in the execution token, the current execution environment is determined to meet the security conditions, and the step of invoking the data connector to read the target data locally in a controlled manner at the data provider is executed.

[0118] In one optional embodiment, data index information corresponding to the data identifier is determined according to the data registration information pre-registered by the data provider; target data is read locally and controlled by the data provider based on the data index information, and the target data is written into the off-chain execution agent module.

[0119] In one optional embodiment, algorithm digest information and policy version information are determined based on the execution token, and the target algorithm is invoked to process the target data according to the algorithm digest information and the policy version information to obtain data processing results; input digest information, output digest information, execution log digest information and environment proof information corresponding to the target data processing process are collected, and execution receipt information is generated based on the input digest information, the output digest information, the execution log digest information and the environment proof information.

[0120] In one optional embodiment, the execution receipt information is submitted to the blockchain, and the audit contract on the blockchain verifies the execution receipt information. If the verification result determines that the execution receipt information meets the verification conditions, the step of sending the data processing result to the data requester is executed.

[0121] In an optional embodiment, the binding relationship between the execution receipt information and the execution token is verified to be correct; the input information, algorithm information and policy version information in the execution receipt information are the same as the execution token; the execution environment proof information corresponding to the current execution environment meets the security conditions; and the execution token is within its validity period and has not been reused.

[0122] In one optional embodiment, the data processing result is updated according to preset output granularity information and usage restriction information to obtain the target data processing result, and the target data processing result is sent to the data requester.

[0123] In one optional embodiment, data identification information submitted by the data provider is received, data hash value, version information and data index information are generated based on the data identification information, data registration information is constructed based on the data hash value, the version information and the data index information, and the data registration information is written into the data registration contract on the blockchain.

[0124] In one optional embodiment, a data usage policy submitted by the data provider is received, a policy identifier and policy version information corresponding to the data usage policy are determined, and the policy identifier and policy version information are written into the policy management contract on the blockchain; wherein, the data usage policy includes at least one of the following: user scope information, permitted use information, algorithm whitelist, time window information, call frequency information, output granularity information, and export restriction information, and the data usage policy is used to verify the data application request and issue the execution token.

[0125] The above is an illustrative scheme of an off-chain controlled computation and auditing method for trusted data spaces based on execution tokens, as described in this embodiment. It should be noted that the technical solution of this off-chain controlled computation and auditing method for trusted data spaces based on execution tokens belongs to the same concept as the technical solution of the aforementioned off-chain controlled computation and auditing system for trusted data spaces based on execution tokens. Details not described in detail in the technical solution of the off-chain controlled computation and auditing method for trusted data spaces based on execution tokens can be found in the description of the technical solution of the aforementioned off-chain controlled computation and auditing system for trusted data spaces based on execution tokens.

[0126] Corresponding to the above method embodiments, this specification also provides an embodiment of a trusted data space off-chain controlled computing and auditing device based on execution tokens. Figure 4 This specification illustrates a schematic diagram of a token-based trusted data space off-chain controlled computing and auditing device according to one embodiment of this specification. Figure 4 As shown, the device includes: The receiving module 402 is configured to receive a data request submitted by a data requester and call the strategy management contract on the blockchain to verify the request parameters corresponding to the data request. The determination module 404 is configured to, upon successful verification, issue an execution token by the strategy management contract and determine the task information corresponding to the data request; The calling module 406 is configured to, based on the task information and the execution token, determine that the current execution environment meets the security conditions, and then call the data connector to read the target data locally in a controlled manner from the data provider. Processing module 408 is configured to process the target data according to the execution token to obtain data processing results and execution receipt information; The sending module 410 is configured to send the data processing result to the data requester if the execution receipt information meets the verification conditions.

[0127] The above is an illustrative scheme of an off-chain controlled computation and auditing device for a trusted data space based on execution tokens, according to this embodiment. It should be noted that the technical solution of this off-chain controlled computation and auditing device for a trusted data space based on execution tokens belongs to the same concept as the technical solution of the aforementioned off-chain controlled computation and auditing method for a trusted data space based on execution tokens. Details not described in detail in the technical solution of the off-chain controlled computation and auditing device for a trusted data space based on execution tokens can be found in the description of the technical solution of the aforementioned off-chain controlled computation and auditing method for a trusted data space based on execution tokens.

[0128] Figure 5 A structural block diagram of a computing device 500 according to one embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0129] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0130] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0131] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 500 can also be a mobile or stationary server.

[0132] The processor 520 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described controlled computation and auditing method for trusted data space based on execution tokens.

[0133] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device belongs to the same concept as the technical solution of the above-mentioned off-chain controlled computing and auditing method based on execution token in trusted data space. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-mentioned off-chain controlled computing and auditing method based on execution token in trusted data space.

[0134] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described method for controlled off-chain computation and auditing of a trusted data space based on execution tokens.

[0135] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the above-described trusted data space off-chain controlled computation and auditing method based on execution tokens. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described trusted data space off-chain controlled computation and auditing method based on execution tokens.

[0136] An embodiment of this specification also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method for controlled off-chain computation and auditing of a trusted data space based on execution tokens.

[0137] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the above-mentioned trusted data space off-chain controlled computation and auditing method based on execution token belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above-mentioned trusted data space off-chain controlled computation and auditing method based on execution token.

[0138] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0139] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0140] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0141] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0142] The preferred embodiments disclosed above are merely illustrative of this specification. Optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described in this specification. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification.

Claims

1. A trusted data space off-chain controlled computation and auditing system based on execution tokens, characterized in that, It includes an execution orchestration module and an off-chain execution agent module, including: The execution orchestration module is used to receive data request requests submitted by data requesters, call the strategy management contract on the blockchain to verify the request parameters corresponding to the data request; if the verification is successful, the strategy management contract issues an execution token and sends the execution token and the task information corresponding to the data request to the off-chain execution agent module. The off-chain execution proxy module is used to, based on the task information and the execution token, determine that the current execution environment meets the security conditions, call the data connector to read the target data locally in a controlled manner from the data provider; process the target data according to the execution token to obtain data processing results and execution receipt information; and, if the execution receipt information meets the verification conditions, send the data processing results to the data requester.

2. The system according to claim 1, characterized in that, The execution orchestration module is also used to parse the data request to obtain the requester's identity, target data object, purpose information, target algorithm identifier, algorithm version information, and output result requirement information; The strategy management contract on the blockchain is invoked to verify the identity of the requester, the target data object, the purpose information, the target algorithm identifier, the algorithm version information, and the output result requirement information.

3. The system according to claim 1, characterized in that, The strategy management contract manages multiple candidate execution tokens, wherein any candidate execution token includes at least one of the following information: permitted subject identification information, target data identification information, strategy version information, algorithm digest information, purpose of use information, validity period information, execution environment proof requirement information, and random number.

4. The system according to claim 1, characterized in that, The off-chain execution proxy module is further configured to, upon receiving the execution token and the task information, invoke the environment verification unit to verify the current execution environment; if the verification result determines that the environment measurement result of the current execution environment matches the execution environment verification requirement information in the execution token, determine that the current execution environment meets the security conditions, and execute the step of invoking the data connector to read the target data locally in a controlled manner from the data provider.

5. The system according to claim 1, characterized in that, The data connector is used to determine the data index information corresponding to the data identifier according to the data registration information pre-registered by the data provider; based on the data index information, the target data is read locally and controlled by the data provider, and the target data is written into the off-chain execution agent module.

6. The system according to claim 1, characterized in that, The off-chain execution proxy module is also used to determine the algorithm digest information and policy version information based on the execution token, and to call the target algorithm to process the target data according to the algorithm digest information and the policy version information to obtain the data processing result; The system collects input summary information, output summary information, execution log summary information, and environment verification information corresponding to the target data processing process, and generates execution receipt information based on the input summary information, output summary information, execution log summary information, and environment verification information.

7. The system according to claim 1, characterized in that, The off-chain execution proxy module is also used to submit the execution receipt information to the blockchain, where the audit contract on the blockchain verifies the execution receipt information. If the verification result determines that the execution receipt information meets the verification conditions, the module executes the step of sending the data processing result to the data requester.

8. The system according to claim 7, characterized in that, The audit contract is used to verify whether the binding relationship between the execution receipt information and the execution token is correct, whether the input information, algorithm information and policy version information in the execution receipt information are the same as the execution token, whether the execution environment proof information corresponding to the current execution environment meets the security conditions, and whether the execution token is within its validity period and has not been reused.

9. The system according to any one of claims 1 to 8, characterized in that, The off-chain execution agent module is also used to update the data processing result according to preset output granularity information and usage restriction information, obtain the target data processing result, and send the target data processing result to the data requester.

10. The system according to claim 5, characterized in that, The system also includes a data registration module; The data registration module is used to receive data identification information submitted by the data provider, generate data hash value, version information and data index information according to the data identification information, construct data registration information based on the data hash value, version information and data index information, and write the data registration information into the data registration contract on the blockchain.

11. The system according to claim 1, characterized in that, The system also includes a policy management module; The strategy management module is used to receive the data usage strategy submitted by the data provider, determine the strategy identifier and strategy version information corresponding to the data usage strategy, and write the strategy identifier and strategy version information into the strategy management contract on the blockchain; wherein, the data usage strategy includes at least one of the following: user scope information, permitted use information, algorithm whitelist, time window information, call frequency information, output granularity information, and export restriction information, and the data usage strategy is used to verify the data application request and issue the execution token.

12. A method for off-chain controlled computation and auditing of trusted data spaces based on execution tokens, characterized in that, include: Receive a data request submitted by a data requester, and invoke the strategy management contract on the blockchain to verify the request parameters corresponding to the data request; If the verification passes, the strategy management contract issues an execution token and determines the task information corresponding to the data request. If the current execution environment meets the security conditions based on the task information and the execution token, the data connector is invoked to read the target data locally in a controlled manner from the data provider. The target data is processed according to the execution token to obtain data processing results and execution receipt information; If the execution receipt information meets the verification conditions, the data processing result will be sent to the data requester.

13. A trusted data space off-chain controlled computing and auditing device based on execution tokens, characterized in that, include: The receiving module is configured to receive data request requests submitted by the data requester and call the strategy management contract on the blockchain to verify the request parameters corresponding to the data request request. The determination module is configured to, upon successful verification, issue an execution token by the strategy management contract and determine the task information corresponding to the data request; The calling module is configured to, based on the task information and the execution token, determine that the current execution environment meets the security conditions, and then call the data connector to read the target data locally in a controlled manner from the data provider. The processing module is configured to process the target data according to the execution token to obtain data processing results and execution receipt information; The sending module is configured to send the data processing result to the data requester if the execution receipt information meets the verification conditions.

14. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the method of claim 12.

15. A computer-readable storage medium, characterized in that, It stores computer-executable instructions that, when executed by a processor, implement the steps of the method of claim 12.

16. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the steps of the method of claim 12.

Images