Data space digital contract compliance detection method based on block chain

Abstract

The invention relates to the field of block chains, and discloses a data space digital contract compliance detection method based on a block chain, and the method comprises the steps: firstly constructing a structural model containing basic contract information and contract strategy information, and generating a contract draft through automatic filling; calling a compliance scoring algorithm based on a weighted score and risk factor product, performing quantitative evaluation on contract integrity, fineness and subject consistency, and performing fusing interception on high-risk items; pulse data in the contract signing and performance process is uploaded to the block chain platform in real time for full-life-cycle evidence storage, and when a dispute occurs, a space-time integral compliance comparison model is used for backtracking and auditing the on-chain evidence storage data; according to the method, second-level automatic verification, whole-process tamper-proof monitoring and non-repudiation afterward account checking of the digital contract are realized, and the compliance and treatment efficiency of data transaction in a data space are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain, specifically to a method for detecting the compliance of digital contracts in a data space based on blockchain. Background Technology

[0002] With the deepening of global digital transformation, the trusted data space has become a key infrastructure for achieving the secure, controllable, and compliant circulation of data elements. Within the data space, digital contracts, as digital carriers that constrain the rights and obligations of data providers, demanders, and service providers, define the boundaries of data use, behavioral constraints, and delivery methods through structured strategies. They are the core protocols for protecting the value of data assets and ensuring privacy and security.

[0003] However, several specific technical problems remain to be solved in the current process of digital contract generation and execution. First, the construction process of digital contracts lacks refined guidance and quantitative evaluation mechanisms. When drafting contracts, the requesting party often focuses only on basic data acquisition needs, ignoring the stringent constraints required in complex scenarios (such as high-value medical or financial data). This results in overly vague contract terms that are difficult for computer programs to accurately parse and enforce. Second, contract compliance verification mainly relies on manual review. Faced with massive and high-frequency data transaction demands, this not only leads to long verification cycles and low efficiency but also makes it difficult to detect hidden logical conflicts or deep-seated risks such as identity forgery. Third, the static description of the contract and the dynamic performance process are often disconnected, lacking a reliable recording mechanism that spans the entire contract lifecycle. Once the contract is signed, if one party privately modifies a local copy of the contract or disputes arise regarding performance data (such as the number of calls or encryption strength), existing technologies struggle to provide strong evidentiary support for retrospective reconciliation. Finally, due to the lack of standardized structured protocols, digital contracts across different platforms are difficult to be compatible and mutually recognized, limiting the collaborative sharing capabilities of data elements in cross-domain and cross-platform scenarios. Therefore, how to build a digital contract management system that can automatically verify, quantitatively evaluate, and achieve tamper-proof evidence storage throughout the entire process has become a key challenge to improving the effectiveness of data space governance. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based method for detecting the compliance of digital contracts in the data space, in order to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, this invention provides a blockchain-based method for verifying the compliance of digital contracts in the data space, comprising the following steps:

[0006] S1, construct a structured model of digital contracts, and break down digital contracts into a basic contract information structure and a contract strategy structure;

[0007] S2, Obtain data product metadata and automatically populate the basic contract information structure, obtain the demand side's operation behavior attributes and constraint attributes through the data space interface and populate them into the contract strategy structure;

[0008] S3 calls the compliance scoring algorithm model to calculate the contract's basic information score. Contract strategy granularity score It also verifies the built-in high-risk item identification factors in real time. ;

[0009] S4, according to the formula; Calculate the final compliance score of the digital contract and determine the contract quality level based on the score threshold;

[0010] S5 uses a blockchain platform to store the draft, signing process, and performance pulse data of digital contracts throughout their entire lifecycle, and generates a contract state machine trajectory.

[0011] S6 invokes the spatiotemporal integral compliance comparison model during the dispute stage, and uses blockchain-stored evidence data to retrospectively audit the actual performance of the contract.

[0012] Furthermore, the contract strategy structure includes an operation behavior submodule and a constraint condition submodule; the operation behavior submodule defines one or more action attributes among preview, download, analysis, statistics and calculation; the constraint condition submodule defines one or more constraint attributes among call limit, encryption algorithm standard, delivery gateway identifier and destruction declaration.

[0013] Furthermore, the calculation in S3 The logic is as follows: Check the configuration status of the contract identifier, signing entity, validity period, digital signature, and timestamp in the basic contract information structure. If all required fields are configured, then... It is recorded as a perfect score.

[0014] Furthermore, the calculation in S3 The logic is as follows: count the number of attribute entries in the statistical operation behavior submodule. The number of attribute rows in the constraint submodule The strategy module score is obtained by accumulating the scores according to preset weights.

[0015] Furthermore, the high-risk item identification factor The verification dimensions include the consistency between the signing entity and the original order identity, the consistency between the contract subject matter and the subscription product identifier, and the legality of the digital signature and the national cryptographic certificate; if any dimension fails verification, The value is 1.

[0016] Furthermore, in S4, when the final compliance score is... When the value equals 0, the system executes the circuit breaker logic, terminates the current circulation state of the digital contract, and uploads the trigger risk feature code and contract summary to the blockchain violation evidence ledger.

[0017] Furthermore, during the contract signing phase, the blockchain platform records the digital signature Signature_A generated by the requester's private key and the digital signature Signature_B generated by the provider's private key, and associates the signature result, public key certificate fingerprint, and block height at the signing time on the blockchain.

[0018] Furthermore, in S5, after the contract takes effect, the complete contract structure, the signature sets of both parties, and the compliance score are packaged to generate a final hash (Final_Hash) and written into the global contract ledger of the blockchain. At the same time, a policy mask containing constraints is generated.

[0019] Furthermore, the performance pulse data storage includes a transaction identifier, a data packet hash value, a delivery gateway identifier, and a consensus timestamp; multiple performance pulse data are encapsulated at a preset time frequency and then attached to the storage tree node corresponding to the original digital contract in the blockchain.

[0020] Furthermore, the spatiotemporal integral compliance comparison model calculates the performance compliance assessment value using the following formula; in, A timestamp for blockchain-based contract fulfillment verification. For impulse functions, and The time interval for audit statistics.

[0021] Compared with the prior art, the beneficial effects of the present invention are:

[0022] 1. By building based on The weighted scoring model and DCSP structured protocol enable quantitative measurement and automated guidance of contract compliance. This solution transforms ambiguous contract terms into calculable behavioral and constraint attributes. The system provides intuitive scores and improvement suggestions based on the granularity of the configuration. This mechanism not only shortens the original days of manual expert verification to seconds, significantly improving approval efficiency, but also, through a scoring incentive mechanism, encourages requesters to configure more comprehensive security constraints (such as SM4 encryption and designated gateways), thereby improving contract quality and data flow security from the source.

[0023] 2. By introducing risk factors The "one-vote veto" interception mechanism significantly enhances the inherent security of data transactions. This solution deeply couples contract scoring with real-time identity verification and target consistency detection. When hard violations such as misaligned signing entity DID, unauthorized contract target, or abnormal signature are detected, the algorithm immediately resets the score to zero and triggers a circuit breaker. This risk control model based on logical multiplication ensures that any contract with underlying compliance flaws cannot enter the signing process, effectively preventing data theft and fraudulent transactions.

[0024] 3. By utilizing blockchain's full lifecycle evidence preservation and SACM auditing model, the solution provides non-repudiable post-event traceability and accurate reconciliation capabilities. This approach uses blockchain to record every state transition of a contract from draft to execution, and uploads performance pulse data to the blockchain in real-time as hash fingerprints. When disputes arise, the system automatically compares the on-chain evidence with the contract's constraint boundaries using a spatiotemporal integration algorithm, generating an audit report with cryptographic evidence validity. This completely solves the problems of easily tampered data and difficult-to-define responsibilities in traditional reconciliation, significantly reducing the cost of rights protection and collaboration risks. Attached Figure Description

[0025] Figure 1 This is a schematic diagram illustrating the principle of digital contract creation and compliance testing in this invention.

[0026] Figure 2 This is a schematic diagram illustrating the multi-party collaborative signing and state machine transition principle of the present invention.

[0027] Figure 3 This is a schematic diagram illustrating the construction principle of the digital contract structured model of this invention.

[0028] Figure 4 This is a schematic diagram illustrating the principle of automated compliance verification and decision-making for this invention.

[0029] Figure 5 This is a schematic diagram illustrating the principle of blockchain full lifecycle evidence storage and traceability in this invention. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] Please see Figures 1-5 This invention provides a method for detecting the compliance of data space digital contracts based on blockchain;

[0032] Example 1

[0033] This embodiment deeply decomposes and classifies the attribute information of digital contracts, and constructs it as a whole into two core message structures: a basic contract information structure and a contract strategy structure. This structured design is the cornerstone for realizing automated scoring and detection.

[0034] Basic Contract Information Structure: This structure is mainly responsible for defining the "identity" and "temporal and spatial boundaries" of the contract. It includes the contract identifier code, contract name, current status, legal entity information of both parties to the contract, a brief description of the purpose, the start and end dates of the contract, and reserved extended fields. To ensure security, this structure also reserves digital signature bits and signature timestamps for both parties to the contract. In the draft stage, more than 60% of the content in these fields is automatically filled by the system based on the metadata of the underlying product.

[0035] Contract Strategy Structure: This structure describes the dynamic constraints on data usage, specifically divided into two sub-modules: Operation Behavior and Constraints. The Operation Behavior module defines the specific actions that the research institute is allowed to perform on meteorological data, such as "online preview," "batch download," or "offline analysis." The Constraints module refines the boundaries of the behavior, including but not limited to the number of calls (e.g., no more than 5,000 times), encryption method requirements (e.g., must use the national cryptographic standard SM4 encryption), data delivery protocol (e.g., HTTPS-TLS 1.3), and a declaration of destruction after use. In this embodiment, the research institute only simply set the "download" operation and the "contract validity period" constraint in the initial draft.

[0036] The automated compliance scoring model and algorithmic logic contract quality scoring mechanism are one of the core innovations of this invention. It provides both parties in a transaction within the data space with digital guidance to quickly identify low-quality and high-risk contracts. The scoring system uses a quantitative scale of 0 to 10 points, where 0.0 to 5.9 points are low quality, 6.0 to 7.9 points are medium quality, and 8.0 to 10 points are high quality.

[0037] The scoring model primarily follows two calculation criteria. The first is a contract information integrity score, with a total score of [score missing]. It is scored based on basic information. And strategy module score composition;

[0038] Calculation: The required fields for basic contract information are checked. If all required fields such as identifier, name, status, entity, and validity period are configured, that field receives a full score of 4 points. In this embodiment, since the system automatically filled in most of the information, and the research institute supplemented the validity period, therefore... ;

[0039] Calculation: Scoring is performed on the granularity of the contract strategy module, and operational behavior. Each newly added attribute earns 0.2 points, with a maximum of 1 point; constraints ( Each newly added attribute earns 0.1 points, with a maximum of 5 points. In this embodiment, the research institute only entered one "download" operation. ) and a "validity period" constraint ( ),therefore Final score point.

[0040] Secondly, the system verifies the consistency and authenticity of key information. It has a built-in high-risk item identification strategy, which identifies the signing entity and product ownership, contract subject matter and order information, and the legality of digital signatures in real time. If it detects that the contract subject matter (meteorological dataset) does not match the ID in the original subscription order, or that the certificate of the signing institution has expired, the system will determine that there is a high risk and directly set the score to 0, thereby forcibly blocking the circulation of the illegal contract. In this scenario, the basic information verification passed, so the initial evaluation result of 4.3 points was maintained.

[0041] The scoring feedback and compliance improvement guidance: When the research institute clicks "Save Draft" or "Submit for Testing", the system provides a low score warning of 4.3. Under the rules of the Trusted Data Space, contracts with a score below 6.0 are marked as "not recommended for signing". This scoring feedback is not a simple numerical display. It is accompanied by specific "compliance improvement guidance". The system interface will prompt the research institute: "The current contract strategy is too simple and lacks necessary security measures. It is recommended to add constraints such as data encryption protocol, call frequency limit and data usage audit.

[0042] Following this guidance, the research institute's R&D personnel realized that for products containing sensitive historical meteorological data, simply specifying "download" behavior and "validity period" constraints was far from sufficient. To pass the meteorological bureau's security audit, the research institute revised the contract draft. They added "online analysis (0.2 points)" to the operational behavior and "limited number of calls (0.1 points)," "SM4 encrypted transmission requirement (0.1 points)," "data export restriction (0.1 points)," and "third-party audit access (0.1 points)" to the constraints. After this round of optimization, The score rose from 0.3 to 0.9. Although it is still at a low level, this mechanism has encouraged demanders to develop higher-quality and more compliant digital contracts, thereby reducing the auditing pressure on data providers and improving the transaction security of the entire data space.

[0043] To ensure the immutability and traceability of digital contracts, this invention deeply integrates all lifecycle operations of the contract with a trusted blockchain platform. When the research institute saves the draft contract of the meteorological dataset, the system automatically extracts the hash digest of the full contract text and uploads it to the blockchain along with the contract identifier and the research institute's digital certificate fingerprint. The blockchain, as a distributed ledger, records every status change of the contract from the "draft stage" to "signed by our side".

[0044] When the research institute confirms the final version of the contract and signs it online, the system calls its digital certificate for electronic signature. The signature information and signing timestamp are simultaneously uploaded to the blockchain. Subsequently, the contract is transferred to the meteorological bureau (the provider). When the meteorological bureau receives the request to be signed, it can not only see the contract score (such as 5.2 points after improvement, which can reach more than 8 points if further constraints are added), but also verify through the blockchain whether the contract has been tampered with during the transfer process. This blockchain-based evidence storage mechanism provides a solid evidentiary basis for any potential disputes. If the two parties disagree on the number of data calls afterward, they can directly access the blockchain platform to view the full text of the digital contract signed at that time and the performance record, effectively reducing the risk of default and the cost of repudiation. Through this automated, quantitative, and evidence-based method, the trusted data space has achieved a leap from "human control" to "data control" in compliance management.

[0045] In summary, this embodiment demonstrates how to use 32-bit true random number identification, automated attribute filling, and based on... and By employing a weighted scoring logic and blockchain-based evidence storage technology, a closed-loop digital contract compliance testing system is constructed. This not only improves the efficiency of research institutes in creating contracts, but also guides them to establish high-quality contract schemes through the scoring mechanism, ensuring that meteorological data assets can play their maximum value in a safe and compliant environment.

[0046] Example 2

[0047] In this embodiment, we will delve into a high-risk item interception technology based on a "one-vote veto" mechanism. This technology is a key defense line in the compliance detection method of this invention to ensure the underlying security of data transactions. In the complex environment of trusted data space, digital contracts are not only text carriers of transactions, but also logic scripts that are automatically executed. Once the key attributes of the contract (such as the signing entity, data object, and delivery path) are maliciously tampered with or there is a risk of identity theft, even if the other terms of the contract (such as encryption algorithm and call frequency) are written in great detail and have a high score, it is essentially an illegal and dangerous agreement. Therefore, this embodiment achieves closed-loop control from "quantitative scoring" to "risk blocking" by constructing a rigorous "built-in high-risk item identification strategy", ensuring that any contract with compliance flaws cannot enter the subsequent signing and performance stages.

[0048] In-depth analysis and threat modeling of high-risk interception scenarios: In actual data circulation scenarios, malicious tampering often occurs in the "intermediate zone" between the generation of the contract draft and the final signing. Consider a typical medical image data sharing scenario: A top-tier hospital (data provider) publishes a "lung nodule desensitized image dataset" through a data space. An AI medical R&D company (data requester) initiates a purchase application. Under normal circumstances, the system will generate a digital contract draft that maps to the application. However, if an attacker attempts to modify the "requester ID" in the contract to another unverified shell company by hijacking network requests or exploiting platform vulnerabilities, or points the "data product identifier" associated with the contract to another higher-value and unauthorized gene sequence database, such tampering will directly threaten the security of data assets. Traditional compliance testing often focuses on the completeness of the terms, while ignoring the authenticity alignment of the underlying information.

[0049] The core task of the "one-vote veto" interception mechanism designed in this embodiment is to detect this "information misalignment" in real time. It requires the system not only to see "what is written in the contract", but also to verify "who signed the contract" and "what was signed". This detection is based on the "global root of trust" in the data space. That is, every core metadata item in the contract must be strongly consistent with the original order pre-stored on the blockchain and the record in the identity registration center.

[0050] The technical implementation path of the built-in high-risk item identification strategy relies on the method proposed in this invention. This algorithm model, in which... It represents A separate high-risk monitoring dimension

[0051] In this embodiment, the system focuses on monitoring the following three key risk factors:

[0052] 1. Signatory Identity Consistency Detection: During the detection phase, the system traces back to the associated transaction order using the contract identifier code. The algorithm automatically extracts the demand-side public key and institution ID from the contract structure and calls the identity management service within the data space. If it detects that the institution DID (Distributed Identity Identifier) ​​currently initiating the signing does not match the demand-side DID in the original order, or if the institution's credit rating on the platform is blacklisted, the system will determine... This means that even if the contract scores full marks in basic information and strategy description; According to the multiplication effect, the total score... Also because The existence of this item instantly resets it to zero, and this logic ensures that "impersonation" is completely blocked at the algorithm level.

[0053] 2. Contract Target Consistency and Overstepping Authority Detection: The contract target refers to the data product itself. In a trusted data space, each data product has a unique digital fingerprint. In this embodiment, the system compares the hash value of the dataset declared in the contract draft with the metadata directory stored on the blockchain. If it is found that the requesting party attempts to "privately" add unauthorized data fields to the contract, or if there is a slight discrepancy between the product ID pointed to by the contract and the product ID of the order application (such as the version number being tampered with), a risk factor is determined. This detection effectively prevents attackers from stealing data assets for which they have not paid for by forging contract content.

[0054] 3. Digital Signature and Timestamp Anti-counterfeiting Detection: During contract transfer, each party's signature generates a digital signature based on a national cryptographic algorithm (such as SM2). This strategy utilizes a public key store on the blockchain to verify the signature in real time. If the signature cannot be decrypted, or the timestamp of the signature is earlier than the contract creation time (logical contradiction), it is determined that there is a risk of forgery, and a counterfeiting mechanism is set. This technology leverages the non-repudiation of blockchain, fundamentally preventing the possibility of contract text being altered afterward.

[0055] The algorithm's "zero-tolerance" handling mechanism applies once any of the above risk factors are triggered (i.e., a certain risk factor exists). The algorithm will directly output In the system logic, a score of 0 is not just a low score, but an instruction that triggers the "circuit breaker mechanism." At this point, the system will not simply provide a score result, but will immediately execute a series of automated defensive actions: The system will forcibly terminate the circulation of the digital contract, marking it as "invalid," preventing it from entering the other party's pending signature list; secondly, the system will upload the detected anomaly (e.g., detected entity ID tampering) to the blockchain platform as a "compliance risk record." This record includes the tampered contract fragment, the feature code that triggered the risk, and the timestamp at the time of detection. Due to the openness and transparency of the blockchain, this violation attempt will be permanently recorded as a direct basis for downgrading the institution's credit score; finally, the system will send a high-risk alert to the data provider's security administrator, prompting them to detect potential transaction fraud risks. This "one-vote veto" mechanism shifts the risk control point from "post-event accountability" to "in-event interception," greatly reducing the security management cost within the data space.

[0056] Detailed Explanation and Calculation Demonstration of Example Data To more intuitively demonstrate the effect of this example, we introduce a specific set of test data. Assume that the transaction order number of the "Equipment Operation Log Dataset" on a certain industrial internet platform is ORDER-2025-001, and the legitimate demand party ID bound to this order is ORG-RESEARCH-007.

[0057] Scenario A: Compliant contract. In the contract submitted by the requester, the subject ID is ORG-RESEARCH-007, the subject ID matches the order, and the signature is valid. Upon inspection... ,at this time If the basic information of the contract is complete and the strategy is detailed The final score is... The contract was deemed a "high-quality contract";

[0058] Scenario B: High-risk contract tampering. Suppose an attacker changes the main ID in the contract to ORG-HACKER-999. During the detection phase, the algorithm calls the comparison logic: Calculations show that The calculation formula then becomes: Even though the contract contains 100 extremely strict security constraints (which should have earned it a high score according to the rules), its final score is forcibly locked at 0 due to the falsity of the core entity's identity. This algorithm design reflects the absolute priority of security in this invention: the compliance score is not just a simple accumulation of the number of clauses, but is based on the solid foundation of "credible identity and credible subject matter".

[0059] A Deep Dive into the Algorithm's Origins and Model Meaning: The "risk factor multiplication model" used in this embodiment originates from the "defense-in-depth" theory in security engineering and the "multi-factor authentication" logic in cryptography. Mathematically, the additive model (such as...) This represents a linear increase in "performance and completeness," allowing a high score in one area to compensate for a deficiency in another. However, in the security field, this complementary logic is fatal. For example, no matter how perfectly a firewall rule is configured, if the administrator password is weak, the security of the entire system remains zero. Therefore, this invention introduces a multiplicative term based on risk factors. This model implies that security is a "vulnerable link" in a system; the strength of the entire system depends on its weakest link, when all risk factors... When all values ​​are 0 (representing no risk), the multiplication factor is 1, and the contract score reverts to its own quality attribute score; however, if any risk element (such as the subject, object, or signature) breaks down... If the security of the entire system collapses to zero, the model is designed to use computer algorithms to replace tedious manual verification in massive, high-frequency data transactions, and to accurately intercept those "well-disguised" but logically flawed black market contracts. It not only protects the interests of data providers, but also, through the recording mechanism of blockchain, urges all participants to strictly abide by the transaction norms of the data space, thereby establishing an "algorithm-based automatic contract spirit" in the entire ecosystem.

[0060] In risk auditing, after triggering a "veto," this embodiment also involves a crucial follow-up step: source tracing auditing. Since all detection processes and interception records are asynchronously recorded in the blockchain's distributed ledger, when the involved institution objects to being "judged to 0 points" or "rejected by the system," the audit committee can invoke the "compliance detection log contract" on the blockchain. This contract can restore the detection snapshot at that time, clearly showing which one... The ability to record the triggering of factors, the original order hash value at the time, and the location of the corresponding conflicting fields in the contract text throughout the entire process ensures that "veto power" is no longer a "black box operation" of the system, but a legally valid and explainable security regulatory behavior.

[0061] As can be seen from the description of this embodiment, high-risk item interception is not just a technical switch, but a comprehensive security system that integrates identity verification, target comparison, mathematical modeling, and blockchain evidence storage. It successfully solves the "authenticity" problem of digital contract compliance detection in the data space, and provides solid technical support for building a trustworthy, secure, and efficient data element circulation environment. This "zero tolerance" approach to high-risk items is the core feature that distinguishes this invention from traditional contract management systems, and it is also the source of its confidence in adapting to large-scale, highly automated data product transactions in the future. If you need to develop specific algorithm pseudocode or database table structure design for this embodiment, please refer to the relevant documentation.

[0062] Example 3

[0063] In this embodiment, we will delve into how to achieve automated generation and compliance assessment of high-quality digital contracts through "complex strategy configuration" in the context of sharing medical big data involving extremely high commercial value and privacy sensitivity. Medical data, especially composite datasets containing gene sequences, multi-center clinical images, and biobank information, is not only subject to strict constraints under the Data Security Law and the Personal Information Protection Law, but also requires the transacting parties to reach an extremely refined consensus on execution at the technical level. This embodiment demonstrates how the system guides the demand side (such as an international cancer research laboratory) to transform a vague transaction intention into a logically rigorous, high-quality digital contract with full marks by configuring multi-dimensional and in-depth strategy terms, and then achieves "second-level" automated approval and processing through algorithmic trust.

[0064] In this embodiment, the data target is defined as a "Multicenter Rare Disease Genome and Clinical Imaging Fusion Dynamic Database" (No.: MED-GENOME-2025-X1). The complexity of this dataset lies in its high degree of unstructured nature and extreme privacy sensitivity. It contains over 50,000 patients' DICOM format high-resolution medical images, VCF format whole-exome sequencing data, and follow-up medical records spanning up to ten years. For such high-value assets, the traditional "download and use offline" model is almost unacceptable. A refined governance model of "data usable but invisible, usage controllable and measurable" is necessary. To support this scenario, the digital contract defined in this invention is no longer a simple text display, but a "strategy collection" composed of highly structured parameters, including basic information (…). At the system level, the cryptographic service generates a unique 32-bit contract identifier. It also automatically associates the laboratory's distributed identity (DID) with the medical center's data resource identifier.

[0065] During the strategy configuration phase, the system mandates that requesters must define the terms in depth from two dimensions: "operational behavior" and "constraints," rather than using default templates. This mandatory and detailed requirement is the cornerstone of building high-quality contracts because it eliminates semantic ambiguity through technical means and provides precise calculation parameters for subsequent automated compliance checks.

[0066] The diverse definitions and scoring logic of operational behaviors determine the "dynamic boundaries" of data in the demand-side environment. In this embodiment, in order to obtain high-quality scores and meet the compliance requirements of the medical center, the demand-side laboratory is configured with five core operational behaviors: Online preview: only allows viewing of image data on the controlled end through low-resolution slicing; Aggregation statistics: allows calling statistical algorithms to calculate macro indicators such as population incidence rate and median survival; Privacy computing analysis: specifies that the data must be trained in a hardware-isolated Trusted Execution Environment (TEE) and the data is not stored in plaintext.

[0067] Federated Learning Participation: Supports participation as a node in federated learning for gradient updates, rather than directly extracting features. Anonymized Export: Only results processed with differential privacy are allowed for export, and must meet certain requirements. -Anonymous model requirements, scoring model analysis: The algorithm proposed in this invention is based on the deterministic assessment of information entropy, that is, the more clearly and diverse the operational behavior is defined, the higher the enforceability of the contract and the lower the risk of disputes caused by ambiguity, according to the formula; Because the client entered the above 5 specific actions, this module received a perfect score of 1.0. This score indicates that the completeness of the contract in the "data usage description" dimension has reached the industry's best standard, enabling the provider's system to clearly identify the specific technical path that the data will be used for.

[0068] The systematic construction of stringent constraints and the source of scoring algorithms: If operational behavior defines "what can be done", then constraints define "how must be done". For high-value medical data, the depth of constraints directly determines the risk control capability of the contract. In this embodiment, the laboratory has configured up to 50 detailed constraint clauses in the system, covering all aspects from physical links to logical security. These constraints are not simple textual descriptions, but key-value pairs that can be parsed by algorithms.

[0069] Temporal and spatial constraints include "access time window restriction (access is prohibited from 20:00 to 06:00)" and "limited IP range (only fixed public IP addresses on the research network are allowed)".

[0070] Frequency and scale constraints: The daily maximum number of calls is set to 100, and the number of records returned by a single API call is not allowed to exceed 50.

[0071] Security hardening constraints: This is the core technology of this embodiment. The client explicitly requires that "the transport layer must use the national standard SM4-GCM encryption algorithm" and "the storage layer must be encrypted with secondary envelopes based on the national standard SM2".

[0072] Delivery and Environmental Constraints: A “Data Delivery Gateway (ID: GW-MED-SEC-01)” is specified, requiring the environment to pass the Level 3 Information Security Protection Assessment and to have real-time video monitoring and full log retention.

[0073] Performance-based destruction constraint: Upon contract expiration, the system must automatically trigger a zero-copy erasure mechanism and submit a "data destruction proof hash" generated by the trusted environment to the blockchain.

[0074] In-depth analysis of the scoring model: The constraint scoring formula used in this invention; The underlying algorithmic logic originates from the "security depth compensation model." Each additional effective constraint mathematically reduces the likelihood of compliance failure. At that time, the module received a perfect score of 5.0. This logic of linearly accumulating to the upper limit is designed to encourage the demand side to disclose its technical safeguards in as much detail as possible. In the medical scenario, a constraint score of 5.0 means that the contract has covered all compliance requirements such as identity authentication, data encryption, boundary protection, and audit backtracking.

[0075] Through the above refined configuration, the system begins to run the core scoring algorithm for high-quality contracts, first calculating the basic information score. Since the fields such as identifier, subject, validity period, and digital signature are complete, it scores 4.0 points. Next, the strategy information score is calculated. In the end, the digital contract's total score was [score missing]. point.

[0076] The specific meaning and origin of the model: The score of 10.0 here is not just a number; in the trusted data space model, it represents "zero risk deviation." This model references the traditional bank credit rating system but transforms it into a quantification of "contractual certainty." When a contract reaches a score of 10, the system determines that the contract's terms have reached the highest standard of "self-interpretation, self-execution, and self-audit." In this embodiment, due to the risk factors anchored to the contract on the blockchain... All scores are 1 (representing no identity fraud, no conflict of interest, or other high-risk items), resulting in a perfect score.

[0077] Business value of automated approval: In the traditional model, the approval of contracts involving such sensitive medical data requires legal, security and technical experts from meteorological bureaus, medical centers or data platforms to conduct a 3-5 day joint signing and verification process. However, under the method of this invention, a high-quality (10 points) contract triggers the "trust automation" process. The provider's risk control system recognizes that the contract has reached the full score, which means that all security measures (such as SM4 encryption, limited gateway, and destruction proof) have been solidified in the contract in a structured form. Therefore, the system directly skips manual review, automatically adds the provider's digital signature to the contract, and synchronizes the final signing result to the blockchain for evidence storage. This shortens the signing cycle from several days to seconds, greatly improving the efficiency of rare disease research.

[0078] The anchoring role of blockchain in the circulation of high-quality contracts: In the generation and signing of high-quality contracts, the blockchain is no longer just a simple storage medium, but a "consensus verification machine." When a 10.0-point contract is generated, the system extracts a complete logical summary of the 5 operational behaviors and 50 constraints contained in the contract, generates a globally unique MerkleTree root hash value, and uploads it to the blockchain. This means that even if the contract content is extremely complex, its fingerprint on the chain is concise and irreversible. In the subsequent performance stage, the "designated delivery gateway" in this embodiment automatically downloads the constraint fingerprint of the high-quality contract from the blockchain whenever the contract is fulfilled. When the laboratory performs a "privacy computation analysis," the gateway verifies in real time whether the behavior falls within the five Actions defined in the contract, and whether the current encryption method is indeed the SM4 agreed in the contract. Since the contract itself has received a high-quality rating of 10 points, each constraint it defines becomes hard code that the gateway enforces. Once the requesting party attempts to violate the constraints (such as attempting to make excessive calls or changing to a non-designated gateway), the gateway will instantly block access and record the violation as a "contract deviation event" on the blockchain. This model of "high-quality contracts guiding high-quality performance" constitutes the closed-loop data space compliance ecosystem based on blockchain in this invention.

[0079] Technical Results Summary and Industry Applications: This embodiment demonstrates that the "strategy-weighted scoring model" designed for complex medical data scenarios possesses strong industry applicability. It addresses the pain point of "difficulty in quantifying trust" in data transactions. and Through detailed disassembly, we discovered:

[0080] 1. Refinement equals security: The increase in operational behaviors and constraints may seem to increase configuration complexity, but in reality, it reduces compliance costs by eliminating ambiguity.

[0081] 2. Quantification equals efficiency: Compliance is converted into a calculable score, providing a basis for decision-making in automated approval;

[0082] 3. On-chain confirmation of rights: The on-chain storage of high-quality contracts ensures that extremely complex and sophisticated strategies are not compromised during execution, providing a unique source of facts for judicial evidence collection and liability determination.

[0083] This method can also be extended to highly sensitive scenarios such as joint modeling in the financial field and cross-domain sharing of government data. In this embodiment, it is precisely because the system successfully identified and rewarded the "rigorous and detailed" strategy configuration submitted by the laboratory that the originally fraught medical data flow became smooth, transparent and secure.

[0084] Example 4

[0085] In this embodiment, we will delve into the core technical aspect of "blockchain-based evidence storage throughout the entire lifecycle of digital contracts." This is not only the technical foundation of the compliance testing method of this invention but also crucial for ensuring a "trust loop" in the data space. In the complex game-theoretic environment of a trusted data space, the lifecycle of a digital contract encompasses the entire process from the initial draft of intent, compliance self-checking, multi-party collaborative signing, to the final execution state change. Traditional electronic contract systems often focus on result evidence storage, while the blockchain evidence storage scheme presented in this embodiment constructs a mathematically deterministic and tamper-proof chain of evidence by anchoring each "state transition point" of the contract on the blockchain in real time. This end-to-end evidence storage mechanism solves the underlying trust problem of "who, when, based on what rules, and what content was signed" in data circulation, providing absolutely objective technical factual support for post-event auditing and breach of contract determination.

[0086] Initial evidence preservation and "identity anchoring" mechanism in the contract draft stage;

[0087] The lifecycle of a digital contract begins with a "subscription request" initiated by the demand side (such as a fintech company) on a data space management platform. In this embodiment, the demand side creates a contract draft for "personal credit risk assessment model data".

[0088] At this point, the system triggers its first core technical action:

[0089] The distributed cryptographic service component is invoked to generate a globally unique 32-bit true random number as the contract identifier, for example, 8e4f2b1c9a0d7e6f5b4a3c2d1e0f9b8a.

[0090] The moment the draft is saved, the system does not simply store it in the local database, but immediately executes the "initial anchoring" algorithm. This algorithm stores the basic information structure of the contract ( After normalization and removal of redundant formatting, the full text is calculated. Hash value.

[0091] The system will The data is packaged into a single notarized transaction packet and sent to the blockchain consensus node. The data fields involved here are highly granular: Creator_DID uses a distributed identity identifier, ensuring the initiator's identity is verifiable and unique on the chain; the Timestamp is derived from the blockchain's network-wide consensus timestamp, not the local server clock, preventing the possibility of time backfilling. The significance of this notarization stage lies in establishing an "initial gene" for the contract. Even if any character is maliciously modified during the subsequent transfer of the contract, its hash value will fluctuate drastically, thus being immediately identified by the verification engine. This "draft-to-chain" strategy eliminates the "verbal agreement without proof" phenomenon during the negotiation process, placing all changes in intent under the algorithm's monitoring. During this process, the system also automatically records... The initial assessment result (basic information score) is linked to the hash, serving as a quantitative endorsement of the initial compliance of the contract and providing a decision-making reference for subsequent provider review.

[0092] Multi-party digital signatures and the construction of cryptographic evidence chains in the signing process;

[0093] Once the draft contract passes the initial compliance check (e.g., a score greater than 6.0), it enters the formal signing stage. This stage is the most crucial trust-building step in the lifecycle. This embodiment employs a scheme combining the national cryptographic SM2 algorithm and the SM3 digest algorithm. First, the requesting party digitally signs the entire contract text. The signing process is not a simple image overlay, but rather uses the requesting party's private key to perform asymmetric encryption on the contract hash value, generating the signature string Signature_A. The system uploads Signature_A, the requesting party's public key certificate fingerprint, and the on-chain height (BlockHeight) at the time of signing to the blockchain in real time. In the underlying storage logic of the blockchain, this is defined as a "state transition event," where the contract state changes from DRAFT to PARTIALLY_SIGNED.

[0094] Subsequently, the contract is transferred to the data provider. Before the provider signs, the system automatically calls the "on-chain comparison algorithm" to retrieve the Hash_Draft from the blockchain and perform a real-time collision comparison with the hash of the currently received contract text. If they match, it means the contract has not been tampered with during transmission; if the consistency check passes and the compliance score meets expectations, the provider performs a secondary signature, Signature_B. At this point, the blockchain records not only two signature results, but a "signature sequence" with a strict logical order. The model here means that each party's signature is a confirmation and lock of the previous state. Based on the risk factor proposed in this invention... The detection logic is as follows: if the signatory's DID does not match the entity declared in the contract, or if the signature certificate is on the Revocation List (CRL), the blockchain smart contract will directly reject the notarization transaction and return a score of 0. This "mandatory compliance interception" based on smart contracts ensures that every record notarized on the chain is legal and valid. At this point, the contract forms a complete "two-way confirmation evidence" on the blockchain, and any subsequent attempt by either party to deny the signing will face cryptographic incontestability.

[0095] Final state change and full lifecycle "logical locking" algorithm;

[0096] The digital contract officially takes effect after both parties have signed it and the compliance score has been finalized. This embodiment introduces a mechanism called "final state logic locking." The system will lock the complete structure of the final contract (containing all 50 constraints). and 5 operational behaviors The signature sets of both parties and the final compliance score (e.g., 9.2) are packaged together to generate a "Final Hash". This hash value is written into the blockchain's "global contract ledger" and the contract state is set to SIGNED_COMPLETED. At this moment, the system executes a crucial algorithmic action: [The remaining text appears to be incomplete and requires further context.] The score is hard-coded with contract execution authority. For example, only when the blockchain state shows SIGNED_COMPLETED and... The data delivery gateway will only issue the decryption key at that time.

[0097] The data involved in this stage is detailed as follows: The evidence data package contains a "policy mask," which compresses the 50 complex constraints in the contract into a 512-bit feature vector. This vector is publicly available on the blockchain, but its specific meaning can only be deduced through the corresponding parsing protocol. This design protects trade secrets while achieving public auditing of compliance. Furthermore, this embodiment also records the contract's "expiration warning time point." Once the expiration date is reached, the smart contract on the blockchain will automatically trigger a state change function, setting the contract to EXPIRED, thereby revoking its data access permissions across the entire network. This blockchain-based state automaton model completely solves the problems of "overdue use" or "unauthorized access" caused by information asymmetry during the execution of traditional contracts. In this way, the digital contract transforms from a static file into a living, self-regulating smart object on the blockchain.

[0098] Anti-tampering consistency verification and algorithm source analysis;

[0099] To verify the effectiveness of the aforementioned evidence storage system, this embodiment simulates a malicious "man-in-the-middle" attack. Assume that an attacker (or a dishonest party) attempts to modify the "maximum number of calls" constraint in the database after the contract is signed, increasing it from 5000 to 50000. When the data requester initiates another access request, the data space gateway triggers a "compliance backtracking verification" algorithm. This algorithm is derived from the Merkle tree proof mechanism. The gateway does not need to download the entire blockchain ledger; instead, it requests the Merkle path corresponding to the current contract ID from the blockchain node and calculates the hash value of the locally modified contract. Due to the collision-resistant property of the hash function (SHA-256), even if only one number is modified, the generated Local_Hash will completely deviate from the Final_Hash anchored on the blockchain.

[0100] In this scenario, Result returns False. Based on the system's preset logic, it recognizes that the contract integrity has been violated, immediately forces a reset of the compliance score to 0, and triggers... Risk Factors. This "chain-based" consistency verification, at its core, entrusts the "right to define facts" to a distributed consensus algorithm, rather than any party's local database. This not only prevents unauthorized modification of terms but also ensures, through the logic of "evidence-driven execution," that every step of data flow strictly adheres to the initially signed rules. The HashChain technology upon which this method relies can be traced back to the Haber and Stornetta timestamp service model. By deeply coupling it with the digital contract structure of the data space in this invention, it achieves mathematical guarantees of contract honesty.

[0101] Implementation of collaborative evidence storage for traceability, reconciliation, and performance records;

[0102] The lifecycle of a contract doesn't end with signing; subsequent performance records are also a crucial component of evidence preservation. In real-world scenarios involving financial credit data retrieval, each successful delivery of data, each settlement of fees, and each triggering of a compliance audit generates corresponding "performance pulse data." This embodiment requires the system to batch encapsulate this performance data hourly and attach its hash value to the "evidence tree" of the original digital contract. This forms a tree-like data structure with the contract as the root and performance records as the leaves.

[0103] Detailed Data Description: Each performance record includes a TransactionID, Call_Type, Result_Status, and Compliance_Reference (pointing to the specific constraint ID of the original contract). When a dispute arises regarding call frequency six months later, the auditor only needs to retrieve all related records on the blockchain using the contract identifier. Because these records are uploaded to the blockchain in real-time and have clock-based consensus, they constitute an irrefutable sequence of evidence. The audit algorithm automatically traverses these leaf nodes, calculating the deviation from the max_call_count constraint in the original contract. If the actual number of calls exceeds the constraint value of the on-chain contract, the system will automatically generate a violation report and trigger the preset penalty settlement logic. This method of unifying the anchoring of "static contracts" and "dynamic performance" on the blockchain significantly reduces the reconciliation costs and legal recourse difficulties for both parties. This full-lifecycle evidence storage logic essentially utilizes the blockchain to construct a "digital rule-of-law space," allowing every participant to clearly perceive that any breach of contract is transparent and indelible on the timeline.

[0104] Summary of Technical Effects and Interpretation of Model Meaning: Through the in-depth analysis of this embodiment, we can clearly see how blockchain-based full lifecycle notarization injects a "trust soul" into digital contracts. The technical effects of this solution are reflected in:

[0105] First, it achieves "full trace retention", making every step from draft to obsolescence traceable;

[0106] Second, it achieves "high-strength anti-tampering", using hash anchoring technology to make any unauthorized modifications impossible to hide;

[0107] Third, it achieves "automated supervision" by enabling contract rules to execute themselves through smart contract state machines.

[0108] Fourth, from the perspective of model interpretation, the scoring model and the blockchain evidence storage model proposed in this invention complement each other. and While providing a "quantitative measure" of compliance, blockchain-based notarization provides "persistent trust" in the results of these measures. Mathematically, blockchain ensures the value of the notarized evidence. Completeness, while the scoring algorithm ensures the integrity of the contract content. Standardization. The combination of these two factors fundamentally changes the current situation where digital contracts in the data space can only rely on manual review and reactive accountability afterward. In the meteorological, medical, and financial scenarios demonstrated in this embodiment, this system supports massive, high-frequency automated contract signing, relying on this rigorous, blockchain-based, full-lifecycle evidence storage logic. This technical architecture is not only a barrier to secure exchange in a trusted data space, but also the technological cornerstone for building a fair, just, and transparent trading order in the future market-based allocation of data elements.

[0109] Example 5

[0110] In this embodiment, we will delve into the crucial aspect of "post-event evidence collection and reconciliation based on blockchain-based evidence storage." In the closed-loop operation of a trusted data space, digital contracts are not only the criteria for transactions but also the ultimate evidence for resolving legal disputes and technical denials. During the circulation cycle of data products (such as "real-time enterprise credit monitoring APIs"), disputes often arise between data requesters (such as a commercial bank) and data providers (such as a large credit reporting agency) after six months or even longer of contract fulfillment, concerning issues such as whether the frequency of data calls exceeds the limit, whether the delivery agreement is compliant, and whether the encryption algorithm is executed as agreed. This embodiment demonstrates how to utilize the blockchain full lifecycle evidence storage technology proposed in this invention to access the full text of the on-chain anchored digital contract, the signing logic fingerprint, and the associated real-time performance records. By using automated auditing algorithms, "non-repudiable" post-event evidence collection and accurate reconciliation can be achieved, providing a closed-loop technical evidence chain for judicial rulings or platform arbitration.

[0111] Dispute Scenario Description and Audit Data Modeling: This embodiment is set against the backdrop of a commercial bank (the demand side) subscribing to a credit reporting agency's (the provider) "High-Value Small and Micro Enterprise Operational Risk Assessment" data product. The two parties signed a digital contract six months prior, specifying the contract identifier as CON-2025-FIN-001. The contract clearly states... The core constraints in the policy were: a daily call limit of 1,000 times, and data delivery must be encrypted using the national cryptographic SM4 algorithm and transmitted through a designated security gateway. However, during the quarterly reconciliation six months later, the provider discovered that its backend records showed that the client had made excessive calls (up to 1,500 times / day) during certain peak periods, and some data packets appeared to have bypassed the security gateway. The client denied this, claiming that its internal records fully complied with the 1,000-call limit and that the provider's billing system had errors.

[0112] To resolve this dispute, the system initiated a "blockchain-based automated audit and reconciliation process." The data foundation for this process consists of the "digital contract full-text hash" uploaded to the blockchain during the contract signing phase and the "performance pulse record" uploaded to the blockchain in real time during the performance process. In this invention, the performance record is defined as a triplet structure. Every data exchange generates a tiny fingerprint on the blockchain. Although these fingerprints do not contain plaintext data (to protect privacy), they record the time of the data exchange and the identity of the data packet. By calling these massive amounts of on-chain evidence with clock consensus, the auditing system constructs an immutable "performance spatiotemporal map" as the sole source of fact for reconciliation.

[0113] Core Audit Algorithm: Spatiotemporal Integral Compliance Comparison Model (SACM) To achieve automated evidence collection, this embodiment introduces the "Spatiotemporal Integral Compliance Comparison Model". The algorithm is derived from the concept of integration in physics and the "event sequence" theory in distributed systems. Its core meaning is that the compliance of a contract is not a static numerical value, but the degree of overlap between the cumulative value of the performance behavior on the time axis and the contract constraint boundary.

[0114] Interpretation of audit algorithm formulas and their meanings; "Compliance Assessment Value" calculated by the audit system. The formula is as follows: in: Represents the number recorded on the blockchain The timestamp of the written contract performance record It is the Dirac function, representing the... A data call pulse that occurs at any given time. and These represent the start and end times of the dispute, respectively. The formula means: This formula, by accumulating and statistically analyzing on-chain timestamps, reconstructs the actual call frequency of the requester within any given time period. Because... The data originates from the blockchain consensus clock, rather than from any party's local server, thus ensuring the statistical results are "immutable" and "legally transparent."

[0115] Constraint boundary matching algorithm application scenarios in obtaining Then, the audit engine will compare it with the constraints of the digital contracts signed and uploaded to the blockchain six months later. For the "call frequency" dispute in this embodiment, the algorithm automatically extracts the parameter max_call_count=1000 from the contract. The comparison logic is as follows: if in any... Inside the window, If a violation occurs, a "compliance deviation alarm" will be triggered. In the case of a dispute over "delivery method", the algorithm will extract the Gateway_ID field from the performance certificate and perform a hash collision with the "designated delivery gateway" in the contract. If the hash values ​​do not match, it will be judged as an illegal delivery. The advanced nature of this algorithm is that it transforms the complex and time-sensitive data flow behavior into a computable mathematical verification, completely eliminating the ambiguity of "each side has its own reasons".

[0116] The first step in the detailed evidence collection process and the blockchain evidence storage and traceability audit process is "contract baseline restoration". The auditor enters the disputed contract ID CON-2025-FIN-001. The system first extracts the final state summary Final_Hash of the contract when it was signed from the blockchain's "contract registry". Through hash comparison, it ensures that the contract text retrieved at this time (including the 50 constraints) is completely consistent with the contract signed six months ago, preventing any party from modifying the local contract copy afterward. This step is the basis for evidence collection and ensures the "legal consistency" of the audit.

[0117] The second step is "performance chain extraction". The system uses the contract identifier code as an index and the blockchain's "on-chain indexing service" to search for all related performance pulses in the massive ledger data. In this embodiment, the system extracted a total of 31,500 call records with clock fingerprints during October 2025, when the dispute occurred. These records form an "evidence tree" on the chain, and each leaf node contains a unique identifier for the data exchange and the encrypted signature of the participating party.

[0118] The third step is "automated comparison and evidence generation." The audit engine runs the SACM algorithm mentioned above and finds that on October 15, 2025, the total number of call pulses recorded on the blockchain is 1,520. Further analysis reveals that the delivery path hash values ​​of 520 of these calls do not match the "security gateway" agreed upon in the contract. At this point, the system, based on the risk factor model proposed by the present invention, determines that the compliance score for that date is 0 points and lists the block height and timestamp of each illegal call in detail. This process is fully automated and does not require human intervention, thus ensuring the impartiality of the audit results. Finally, the system generates an encrypted "Digital Contract Compliance Audit Report," which is also hashed and uploaded to the blockchain to ensure that the report content is not tampered with.

[0119] The detailed description of the data and model analysis involved are as follows: In the evidence collection process, the accuracy of the data is directly related to the effectiveness of the audit. The data fields involved in this embodiment include: Contract side data: Contract_ID (32-bit random number), S_cons.call_limit (integer 1000), S_cons.encrypt_standard (string "SM4"), On-chain evidence storage data: Each Block contains approximately 2000 performance evidence storage records, each record occupies approximately 256 bytes, including the transaction hash generated by the SM3 algorithm and the digital signature generated by the requester's private key.

[0120] Explanation of the model's specific meaning: The "contract-performance dual-anchoring model" adopted in this invention has a profound connotation of compliance. It believes that compliance is not only a static "score" but also a dynamic "trajectory." In the model, and This determines the "theoretical security" of the contract, while the audit phase... This represents the "practical compliance" of the contract, when and When a deviation occurs, it is quantified as a "credit score deduction." This model can be traced back to the "transaction reconciliation" of the banking system and the "billing audit" of the telecommunications system. However, in this invention, with the support of blockchain technology, this model has evolved from "passive reconciliation after the fact" to "active evidence storage throughout the entire process." In traditional systems, if the billing database is damaged or deleted, the reconciliation will fall into a dead loop. In this embodiment, even if the provider's server goes down, as long as the blockchain node is still running, all performance facts can be 100% restored. This "decentralized source of facts" design is the core advantage of this invention in terms of technical feasibility and legal effect.

[0121] In specific scenarios, the "one-vote veto" application of the algorithm in the auditing process involves triggering a "broken chain of evidence" protection logic if the digital signature of a performance record fails to pass verification using the requester's public key. This is equivalent to a "one-vote veto" at the auditing level. In this scenario, the system does not calculate a specific score but directly determines all performance data at that stage as "invalid / suspicious." For example, in 1520 calls on October 15th, if it is found that the hash value of 100 records cannot be found in the requester's local logs, and the on-chain signature verification fails, this... This indicates that there may be a third party impersonating the client to illegally obtain data, or that the provider's system has forged false evidence. In this case, the audit algorithm will use the non-repudiation of the blockchain to determine that these 100 records are "fraudulent evidence" and remove them from the valid account statements. This automatic filtering capability against "false facts" protects the interests of honest parties and prevents malicious volume manipulation or billing fraud that may occur in the data space. The meaning of this mechanism is that the blockchain not only records the truth, but also excludes falsehoods through algorithmic logic, thereby maintaining the authority of digital contracts as a "technological code".

[0122] Summary of Technical Effects and Beneficial Effects: As can be seen from this embodiment, the blockchain-based post-event evidence collection and reconciliation method achieves the following significant beneficial effects: Unchallenged Evidence: Utilizing SM2 signatures and the blockchain consensus clock ensures that every piece of performance data is legally irrefutable, solving the persistent problems of easy deletion and alteration of traditional electronic records and difficulty in determining liability. Zero Human Intervention in the Reconciliation Process: The SACM algorithm automatically parses contract constraints and matches performance pulses, reducing the manual verification process, which originally required weeks, to minutes, greatly reducing administrative and financial costs. Transparent Dispute Resolution: Audit results are presented in a structured report format, clearly showing the specific time, location (gateway), and content (hash) of each violation, providing arbitration institutions with extremely detailed decision-making basis. Reverse Constraint on Performance Behavior: Since both the requester and the provider know that all operations will be recorded on the blockchain in real time and used for subsequent auditing, this "technological deterrence" in turn prompts both parties to more strictly adhere to the contract during the performance process. The various constraints in the system reduce the frequency of disputes at the source.

[0123] In summary, this embodiment not only demonstrates the application of blockchain in data notarization, but also shows how to transform notarization into operable legal facts through complex auditing algorithms. This model of "promoting compliance through notarization and resolving disputes through auditing" constitutes the core competitiveness of this invention in the trusted data space governance system. Whether in high-frequency financial transactions, sensitive medical collaborations, or complex cross-border trade, this method can provide the most solid technical support for the compliant transfer of data assets.

[0124] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0125] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for compliance detection of data space digital contracts based on blockchain, characterized in that, Includes the following steps: S1, construct a structured model of digital contracts, and break down digital contracts into a basic contract information structure and a contract strategy structure; S2, Obtain data product metadata and automatically populate the basic contract information structure, obtain the demand side's operation behavior attributes and constraint attributes through the data space interface and populate them into the contract strategy structure; S3 calls the compliance scoring algorithm model to calculate the contract's basic information score. Contract strategy granularity score It also verifies the built-in high-risk item identification factors in real time. ; S4, according to the formula; Calculate the final compliance score of the digital contract and determine the contract quality level based on the score threshold; S5 uses a blockchain platform to store the draft, signing process, and performance pulse data of digital contracts throughout their entire lifecycle, and generates a contract state machine trajectory. S6 invokes the spatiotemporal integral compliance comparison model during the dispute stage, and uses blockchain-stored evidence data to retrospectively audit the actual performance of the contract.

2. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: The contract strategy structure includes an operation behavior submodule and a constraint condition submodule; the operation behavior submodule defines one or more action attributes among preview, download, analysis, statistics and calculation; the constraint condition submodule defines one or more constraint attributes among call limit, encryption algorithm standard, delivery gateway identifier and destruction declaration.

3. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: The calculation in S3 The logic is as follows: Check the configuration status of the contract identifier, signing entity, validity period, digital signature, and timestamp in the basic contract information structure. If all required fields are configured, then... It is recorded as a perfect score.

4. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: The calculation in S3 The logic is as follows: count the number of attribute entries in the statistical operation behavior submodule. The number of attribute rows in the constraint submodule The strategy module score is obtained by accumulating the scores according to preset weights.

5. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: The high-risk item identification factor The verification dimensions include the consistency between the signing entity and the original order identity, the consistency between the contract subject and the subscription product identifier, and the legality of the digital signature and the national cryptographic certificate; When any dimension fails the verification The value is 1.

6. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: In S4, when the final compliance score is... When the value equals 0, the system executes the circuit breaker logic, terminates the current circulation state of the digital contract, and uploads the trigger risk feature code and contract summary to the blockchain violation evidence ledger.

7. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: The blockchain platform records the digital signature Signature_A generated by the requester's private key and the digital signature Signature_B generated by the provider's private key during the contract signing stage, and associates the signature result, public key certificate fingerprint, and block height at the signing time on the blockchain.

8. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: In S5, after the contract takes effect, the complete contract structure, the signature sets of both parties, and the compliance score are packaged to generate a final hash (Final_Hash) and written into the global contract ledger of the blockchain. At the same time, a policy mask containing constraints is generated.

9. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: The performance pulse data storage includes transaction identifier, data packet hash value, delivery gateway identifier, and consensus timestamp; Multiple performance pulse data are encapsulated at a preset time frequency and then attached to the evidence storage tree node corresponding to the original digital contract in the blockchain.

10. The method for compliance detection of blockchain-based data space digital contracts according to claim 1, characterized in that: The spatiotemporal integral compliance comparison model calculates the performance compliance assessment value using the following formula; in, A timestamp for blockchain-based contract fulfillment verification. For impulse functions, and The time interval for audit statistics.

Images