Atomicized collaborative transaction-based pre-deposit system, server and computer readable storage medium

Abstract

The embodiment of the application discloses a pre-deposit system based on atomized collaborative transactions, a server and a computer readable storage medium. The transaction suspension engine is used to intercept the to-be-delivered content output by the artificial intelligence model, the encryption engine is used to perform encryption processing on the to-be-delivered content, the deposit anchoring module is used to send the first deposit transaction to the block chain for deposit, and the consensus oracle module is used to transmit the deposit success reply to the transaction suspension engine. The transaction suspension engine is also configured to encapsulate the execution processes of the fingerprint extraction module, the encryption engine and the deposit anchoring module as an atomic transaction, and restore the target thread that is suspended to deliver the to-be-delivered content to the client. The embodiment of the application encapsulates the three processes of target semantic fingerprint extraction, encryption and deposit anchoring as an atomic transaction, ensures that the three processes cannot be split, avoids the risk of bypassing deposit to directly deliver content and tampering with the deposit process, and improves the security and compliance of the AIGC content generation process.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a pre-existing evidence storage system, server, and computer-readable storage medium based on atomic collaborative transactions. Background Technology

[0002] With the commercialization and widespread application of AIGC (Artificial Intelligence Generated Content) technology, the demand for copyright ownership, source tracing, evidence collection, and compliance auditing of AIGC content is becoming increasingly urgent. The generation of AIGC content involves multiple stages. However, related technologies treat content generation, fingerprint extraction, encrypted storage, and on-chain evidence preservation as independent stages, lacking coordination mechanisms and atomicity guarantees between them. Failure or bypassing of any single stage can lead to the breakage of the entire evidence chain; therefore, the security of the pre-existing evidence preservation system of related technologies is not high. Summary of the Invention

[0003] One objective of this application is to provide a pre-existing evidence storage system, server, and computer-readable storage medium based on atomic collaborative transactions, thereby improving the low security of pre-existing evidence storage systems in related technologies.

[0004] In a first aspect, embodiments of this application provide a pre-existing evidence storage system based on atomic collaborative transactions, applied to a server. The pre-existing evidence storage system includes a transaction suspension engine, a fingerprint extraction module, an encryption engine, an evidence storage anchoring module, and a consensus oracle module. The transaction suspension engine is deployed at the output end of the model inference pipeline of the artificial intelligence model. It is used to truncate the content to be delivered by the artificial intelligence model after it generates the content to be delivered and before delivery to the client, and suspend the target thread, locking the content to be delivered in the encrypted memory of a trusted execution environment. The fingerprint extraction module runs within the trusted execution environment and works in conjunction with the transaction suspension engine. It is used to intercept the target intermediate state tensor generated by the hidden layer of the artificial intelligence model during the inference process about the content to be delivered while the target thread is suspended, and generate a target semantic fingerprint based on the target prompt word input by the user and the target intermediate state tensor. The encryption engine runs within the trusted execution environment and works in conjunction with the transaction suspension engine, used to... While the target thread is suspended, the content to be delivered is encrypted to obtain an encrypted data packet. The evidence storage and anchoring module runs in a trusted execution environment and works in conjunction with the transaction suspension engine. It stores the encrypted data packet in the storage network while the target thread is suspended, packages the target semantic fingerprint and the content storage address of the encrypted data packet into a first evidence storage transaction, and sends the first evidence storage transaction to the blockchain for evidence storage. The consensus oracle module continuously monitors the blockchain, obtains the evidence storage success receipt of the first evidence storage transaction, and transmits the evidence storage success receipt to the transaction suspension engine. The transaction suspension engine is configured to encapsulate the execution process of the fingerprint extraction module, the encryption engine, and the evidence storage and anchoring module into an atomic transaction. After receiving the evidence storage success receipt transmitted by the consensus oracle module, it resumes the suspended target thread to deliver the content to be delivered to the client. If no evidence storage success receipt is received within a preset time, a circuit breaker operation is triggered to destroy the content to be delivered in encrypted memory.

[0005] Optionally, the storage network is a distributed storage network, and the evidence anchoring module is configured to: upload encrypted data packets to the distributed storage network so that the distributed storage network performs hash calculation on the encrypted data packets to obtain a hash value; obtain the hash value returned by the distributed storage network and set the hash value as the content storage address.

[0006] Optionally, the transaction suspension engine is also configured to: after suspending the target thread, generate a transaction identifier for the content to be delivered, and maintain a local transaction record containing the transaction identifier, session identifier, model configuration summary, and suspension status locally; the evidence anchoring module is also configured to: package the transaction identifier, the hash value of the target semantic fingerprint, the content storage address, the ciphertext hash of the encrypted data packet, the model identifier, the model version, the preset hidden layer identifier, and the generated parameter summary into a second evidence transaction, and send the second evidence transaction to the blockchain for evidence storage.

[0007] Optionally, the consensus oracle module is configured to: obtain a successful notarization receipt returned by the blockchain, the successful notarization receipt containing the number of block confirmations and target identifier information; verify whether the target identifier information contained in the successful notarization receipt is consistent with the identifier information of the local transaction record, and whether the number of block confirmations has reached a preset security threshold; if the target identifier information contained in the successful notarization receipt is consistent with the identifier information of the local transaction record, and the number of block confirmations has reached the preset security threshold, transmit the successful notarization receipt to the transaction suspension engine; if the target identifier information contained in the successful notarization receipt is inconsistent with the identifier information of the local transaction record, or if the number of block confirmations has not reached the preset security threshold within a preset time, transmit a timeout signal to the transaction suspension engine to trigger a circuit breaker.

[0008] Optionally, the transaction suspension engine is configured to maintain a long-lived, inactive connection during the suspension period to occupy session resources, thereby ensuring communication between the transaction suspension engine and the client. The transaction suspension engine is also configured to control the target thread to send a delivery status code and the content to be delivered to the client when resuming delivery of the content to be delivered; and to control the target thread to return a circuit breaker status code and an error message indicating failure to prove the evidence to the client when a circuit breaker operation is triggered.

[0009] Optionally, the transaction suspension engine, fingerprint extraction module, encryption engine, evidence storage and anchoring module, and consensus oracle module are all deployed in the server's trusted execution environment. The trusted execution environment provides encrypted memory to protect the content to be delivered during the suspension period. The trusted execution environment is configured to generate remote proof reports, which at least include trusted execution environment metrics, module code hashes, and transaction identifiers to prove that atomic transactions are executed by the expected trusted code.

[0010] Optionally, the transaction suspension engine is configured to trigger a circuit breaker operation to destroy the deliverable content in encrypted memory, including: instructing the memory controller of the trusted execution environment to mark the memory pages storing the deliverable content and the target intermediate tensor as invalid and perform an eviction operation by modifying the page table entries of the encrypted memory, so that the cache of the encrypted memory is physically erased to destroy the deliverable content and the target intermediate tensor.

[0011] Optionally, the evidence anchoring module is configured to send the first evidence storage transaction to the blockchain for evidence storage, including sending the first evidence storage transaction to N blockchains for evidence storage, so that each blockchain returns an evidence storage record based on the first evidence storage transaction; the system also includes a monitoring module, which is configured to obtain the evidence storage records returned by each of the N blockchains and save the evidence storage records returned by each of the N blockchains in a preset on-chain record table.

[0012] Optionally, the monitoring module is also configured to: periodically traverse the on-chain record table, perform batch queries on each blockchain to verify whether each evidence storage record in the on-chain record table is in an accessible and consistent state on the corresponding blockchain; in response to the evidence storage record of an abnormal blockchain not being in an accessible and consistent state, obtain the complete data corresponding to the evidence storage record from the normal blockchain, and send an evidence storage completion request to the abnormal blockchain based on the complete data corresponding to the evidence storage record, so that the abnormal blockchain can complete the evidence storage record based on the complete data.

[0013] In a second aspect, embodiments of this application provide a server, including a processor and a memory, deployed on the server and containing a trusted execution environment, wherein the memory stores program instructions, and the processor calls the program instructions to implement the aforementioned pre-existing evidence storage system based on atomic collaborative transactions.

[0014] In a third aspect, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the aforementioned pre-existing evidence storage system based on atomic cooperative transactions.

[0015] This application's embodiments achieve the following technical effects: First, this application's embodiments encapsulate the three major processes of target semantic fingerprint extraction, encryption, and evidence storage anchoring into atomic transactions, ensuring that the three are inseparable. This avoids the risks of bypassing evidence storage for direct content delivery and tampering with the evidence storage process, improving the security and compliance of the AIGC content generation process. Second, this application's embodiments, through a transaction suspension engine, promptly suspend the target thread and truncate the output data stream after the artificial intelligence model infers and generates the content to be delivered, creating a secure processing window before the content to be delivered to the client, preventing the direct leakage of un-certified content. Third, relying on the hardware isolation protection of a trusted execution environment and encrypted memory, this application's embodiments deploy the target semantic fingerprint extraction, encryption, evidence storage, and oracle verification processes on an internal network, providing hardware-level isolation and encryption protection for the content to be delivered and the target intermediate tensor, preventing plaintext theft. Finally, this application's embodiments obtain the target semantic fingerprint through the fingerprint extraction module, providing reliable feature evidence for subsequent content tracing, infringement verification, and judicial confirmation. Attached Figure Description

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

[0017] Figure 1A schematic diagram of the system architecture of a pre-existing evidence storage system based on atomic collaborative transactions is provided for embodiments of this application; Figure 2 A schematic diagram illustrating the communication between the pre-existing evidence storage system, the artificial intelligence model, the client, and the target thread provided in the embodiments of this application; Figure 3 A schematic diagram of the architecture of an artificial intelligence model provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the communication between the pre-existing evidence storage system, artificial intelligence model, client, target thread, storage network, and blockchain provided in the embodiments of this application; Figure 5 A schematic diagram of the system architecture of a pre-existing evidence storage system based on atomic collaborative transactions is provided for another embodiment of this application; Figure 6 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0019] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the device or the order in the flowchart. Moreover, the terms "first," "second," and "third" used in this application do not limit the data or execution order, but only distinguish identical or similar items with essentially the same function and effect.

[0020] With the commercialization and widespread application of AIGC technology, the demand for copyright ownership, source tracing, evidence collection, and compliance auditing of AIGC content is becoming increasingly urgent. An ideal AIGC evidence storage system should meet the following three core requirements: First, the necessity of timing: the timestamp of the content's notarization must be earlier than or equal to the time when the user receives the content, to ensure that the notarization record cannot be forged or backdated afterward.

[0021] Second, robustness of evidence: the evidence fingerprint must have sufficient tolerance for minor modifications to the content (such as cropping, filtering, and word order adjustment) while accurately distinguishing content from different semantic sources.

[0022] Third, procedural justice: the retrieval and decryption of evidence data must be triggered by legitimate judicial events, and each operation must leave an unalterable audit record.

[0023] However, the relevant technologies each have their own shortcomings in meeting the above three requirements: 1. Asynchronous post-event evidence preservation mode leads to timing discrepancies.

[0024] Traditional blockchain-based evidence storage solutions typically employ an asynchronous model: content is generated first, then delivered, and finally stored. An AI model generates content and immediately sends it to the user, while an asynchronous background thread then hashes and uploads the content to the blockchain. There is a significant time window between content delivery and evidence storage completion. During this period, service providers or intermediaries may tamper with the generated records, leading to inconsistencies between the user's content and the on-chain evidence; system failures may also cause the evidence storage operation to be silently discarded. This architecture cannot guarantee the inevitability of evidence storage at the technical level, significantly diminishing its evidentiary value.

[0025] 2. Fingerprint technology based on the appearance of the result has weak anti-tampering ability.

[0026] Fingerprinting techniques typically rely on calculations based on the final output after generation. This approach only captures superficial features of the content and is highly sensitive to minor modifications such as cropping, filtering, recoloring, scaling, word order adjustments, and synonym replacement; even slight alterations can render the fingerprint invalid. Furthermore, this approach fails to address the generation logic of AIGC content. The AI ​​model's understanding of prompts and the content generation process result in insufficient source tracing accuracy, making it unable to distinguish between content that appears similar but has different semantics, or content with the same semantics but different appearances.

[0027] 3. General-purpose distributed encryption schemes lack dynamic auditing mechanisms.

[0028] The collaborative encryption schemes of related technologies employ a key structure held by multiple parties, but their access activation is static. Anyone holding the key can decrypt, and there is no mandatory causal relationship between the decryption act and judicial proceedings. Regulatory agencies or service providers may still attempt decryption privately within the system without leaving any auditable records. This practice fails to meet the stringent procedural justice requirements of judicial evidence collection from a technical perspective.

[0029] 4. The various technical components lack overall coordination and atomicity guarantees.

[0030] The existing technologies treat content generation, fingerprint extraction, encrypted storage, and on-chain evidence preservation as independent processes, lacking coordination mechanisms and atomicity guarantees between them. Failure or bypassing of any single process will break the entire chain of evidence. AIGC compliant evidence preservation requires not a loose set of tools, but a holistic system architecture that encapsulates all the above processes into indivisible atomic transactions.

[0031] In summary, the field of AIGC compliant evidence preservation urgently needs a brand-new system-level technical solution: it must organically integrate the real-time interception after content generation, the extraction of target semantic fingerprints based on generation logic, the nested encryption based on power checks and balances, the distributed on-chain anchoring, and the synchronous receipt verification of evidence preservation status, and encapsulate the above five links into an atomic collaborative transaction. If any link fails, the whole process will be rolled back and the content will not be delivered.

[0032] This application's embodiments are applicable to AIGC content service platforms with high compliance requirements, providing verifiable and non-repudiable evidence records for each piece of AI-generated content. Application scenarios include, but are not limited to: copyright registration of AI paintings, originality proof of AI-generated text, source tracing of AI audio content, and judicial evidence collection involving AIGC content disputes.

[0033] This application embodiment constructs a multi-module collaborative system protected by a trusted execution environment at the output end of the AI ​​model's model inference pipeline. It encapsulates target semantic fingerprint extraction, double nested encryption, distributed storage anchoring, and on-chain evidence storage into an indivisible atomic transaction, and realizes the receipt verification and delivery decision of the evidence storage status through a consensus oracle, thereby achieving the consistency guarantee of "no delivery without evidence storage".

[0034] The following embodiments of this application provide a pre-existing evidence storage system based on atomic collaborative transactions. Please refer to them together. Figure 1 and Figure 2 The pre-existing evidence storage system 100 based on atomic collaborative transactions includes a transaction suspension engine 200, a fingerprint extraction module 300, an encryption engine 400, an evidence storage anchoring module 500, and a consensus oracle module 600.

[0035] The transaction suspension engine 200 is deployed at the output of the model inference pipeline of the artificial intelligence (AI) model 701. It is used to truncate the content to be delivered by the AI ​​model after it generates the content to be delivered and before it is delivered to the client 702, and to suspend the target thread 703, locking the content to be delivered in the encrypted memory 705 of the trusted execution environment 704.

[0036] The model inference pipeline is an end-to-end workflow that processes user input through multiple stages, transforming it into a computable tensor for the model, performing forward inference, and finally converting the original output into a usable result. The model inference pipeline includes input processing, model forward inference computation, and output decoding. The AI ​​model 701 can be a large language model or a multimodal large model, etc.

[0037] The deliverable content is the final output data generated by the AI ​​model 701 after completing inference calculations, but not yet sent to the client 702. The deliverable content can be text, images, audio, or video, etc. The client 702 can be a mobile app or a computer application, etc.

[0038] The transaction suspension engine 200 truncates the deliverable content output by the artificial intelligence model, reserving execution time for target semantic fingerprint extraction, encryption processing, distributed storage and blockchain notarization. It also ensures that successful notarization is a prerequisite for content delivery, guarantees that the notarization time must be earlier than the content delivery time, ensures that atomic transactions are not bypassed, avoids content leakage before notarization is completed, and ensures the legality of the notarization sequence and the closed loop of the evidence chain.

[0039] The target thread is the API response thread, which is the carrier for AI model interface calls. After truncating the deliverable content output by the AI ​​model, the transaction suspension engine 200 suspends the execution of the target thread, causing it to enter a blocked waiting state and no longer execute the "return response" logic. This achieves the purpose of suspending the target thread 703, thus preventing the deliverable content from being delivered to the client 702, and allowing the transaction suspension engine 200 to occupy the request for this content generation, while the client 702 remains in a waiting state.

[0040] During the period when the target thread is suspended, the transaction suspension engine 200 locks the content to be delivered in the encrypted memory of the Trusted Execution Environment (TEE) 704.

[0041] A Trusted Execution Environment (TEE) is a secure computing area isolated within the host processor. It provides independent code execution and data storage space, and can resist attacks and tampering from the host operating system, privileged users, and external software, ensuring the confidentiality and integrity of the internal operating logic and data.

[0042] Encrypted memory is a hardware-encrypted storage area provided within the Trusted Execution Environment (TEE). Data is stored with end-to-end encryption and is inaccessible from the outside. It is used to securely store sensitive data such as content to be delivered, intermediate tensors, and target semantic fingerprints. The encrypted memory of the TEE is invisible to the host operating system and any external processes.

[0043] The transaction suspension engine 200 is also configured to: after suspending the target thread, generate a transaction identifier for the content to be delivered, and maintain a local transaction record containing the transaction identifier, session identifier, model configuration summary, and suspension status.

[0044] The transaction identifier is a globally unique identifier for the content to be delivered. When the content to be delivered is suspended, the transaction suspension engine generates a transaction identifier. The transaction identifier, the evidence storage record, and the on-chain transaction are mutually bound. The transaction identifier serves as the unique ID for the entire atomic transaction, persisting throughout the entire process of interception, fingerprinting, encryption, on-chain recording, and receipt, thus ensuring transaction traceability. The session identifier identifies the current session between the target thread and the client (702). The model configuration summary is a collection of configuration parameters for the AI ​​model during this AIGC process, including model version, parameters, inference configuration, etc. The suspended state indicates that the target thread is in a suspended state awaiting evidence storage.

[0045] The local transaction record contains the transaction identifier, session identifier, model configuration summary, and suspended state, and is stored in the encrypted memory of the trusted execution environment, providing a trusted local basis for subsequent receipt verification.

[0046] The Transaction Suspension Engine 200 establishes a traceable, verifiable, and tamper-proof local transaction record for each AIGC generation and evidence storage behavior. This record is used to uniquely identify the atomic transaction, bind the user session, solidify the model generation environment, manage the transaction execution status, and provide a local trusted basis for the consistency verification of subsequent blockchain evidence storage receipts, ensuring that the generation behavior is traceable, verifiable, and tamper-proof.

[0047] In some embodiments, the transaction suspending engine 200 is configured to maintain a persistent, inactive connection to occupy session resources during the suspension period, thereby ensuring communication between the transaction suspending engine and the client. For example, the transaction suspending engine 200 occupies session resources during the suspension period by maintaining a persistent, inactive HTTP / TCP connection. Therefore, the transaction suspending engine 200 maintains a connection with the client 702 but does not return data or release the session; it only keeps the underlying link alive, preventing the client 702 from timing out due to prolonged lack of data and preventing the client 702 from automatically retrying. This allows asynchronous blockchain notarization to be embedded within a synchronous HTTP request process.

[0048] In some embodiments, the transaction suspension engine 200 is further configured to: upon resuming delivery of content to be delivered, control the target thread 703 to send a delivery status code and the content to be delivered to the client 702. For example, upon resuming delivery, the transaction suspension engine 200 controls the target thread to send an HTTP 200 status code and the content to be delivered to the client 702, wherein the HTTP 200 status code is a delivery status code.

[0049] In some embodiments, the transaction suspension engine 200 is further configured to: upon triggering a circuit breaker operation, control the target thread 703 to return a circuit breaker status code and an error message indicating failure in evidence storage to the client 702. For example, upon triggering a circuit breaker operation, the transaction suspension engine 200 controls the target thread 703 to return an HTTP 5xx status code and an error message indicating failure in evidence storage to the client, wherein the HTTP 5xx status code is the circuit breaker status code.

[0050] In this embodiment, a delivery status code and a circuit breaker status code are returned respectively when the evidence is successfully stored or when the evidence is not stored. This allows the client 702 to normally perceive the request result, while ensuring that the content to be delivered can only be submitted when the evidence is successfully stored. If the evidence is not stored, the circuit breaker will prevent the submission of the content to be delivered. This improves the system stability, compatibility and security of the evidence chain.

[0051] The fingerprint extraction module 300 runs within the trusted execution environment 704 and works in conjunction with the transaction suspension engine 200. It is used to intercept the target intermediate state tensor generated by the hidden layer of the artificial intelligence model 701 during the reasoning process about the content to be delivered while the target thread 703 is suspended, and generate the target semantic fingerprint based on the target prompt words input by the user and the target intermediate state tensor.

[0052] The fingerprint extraction module 300 runs within a trusted execution environment 704. The host operating system, administrator, and external programs are unaware of the fingerprint extraction module 300, providing a secure and trusted environment for the extraction of the target semantic fingerprint. This ensures that the target semantic fingerprint cannot be tampered with or forged, thereby improving the credibility of the evidence chain and the acceptance by judicial institutions.

[0053] The target intermediate state tensor is the feature map or feature vector output by the hidden layer of the AI ​​model 701 during forward propagation. The fingerprint extraction module 300 acquires the target prompt words input by the user and inputs them into the AI ​​model 701, enabling the AI ​​model 701 to perform inference operations based on the prompt words and obtain the content to be delivered. During the inference process, the hidden layer of the AI ​​model 701 can generate the target intermediate state tensor.

[0054] For example, the target cue word is "a Shiba Inu in a spacesuit walking on the moon." AI model 701 performs inference operations based on this cue word, thereby outputting a target image whose content and style are "a Shiba Inu in a spacesuit walking on the moon." During the inference process, AI model 701 generates a target intermediate state tensor for this target image, which is the content to be delivered.

[0055] Please see Figure 3The artificial intelligence model 701 includes a modal encoder 701a, a connector 701b, a large model backbone 701c, and an output layer 701d. The modal encoder 701a is responsible for converting the raw data of the content to be delivered (such as target prompts, images, or audio) into feature vectors. The connector 701b maps the features output by the encoder to the word embedding space of the artificial intelligence model. The large model backbone 701c is the main body of the large model, used to receive multimodal mixed sequences and utilize a self-attention mechanism for deep cross-modal reasoning and semantic understanding. The output layer 701d outputs the content to be delivered.

[0056] like Figure 3 As shown, the large model backbone 701c includes multiple hidden layers. For example, the large model backbone 701c includes an embedding layer 7011 and multiple Transformer layers 7012. The embedding layer 7011 or the Transformer layer 7012 can both be regarded as hidden layers.

[0057] The embedding layer 7011 maps the input Token ID to a dense vector and superimposes positional encoding, outputting an initial intermediate state tensor. It is understood that in some embodiments, the initial intermediate state tensor can be set as the target intermediate state tensor.

[0058] Transformer layer 7012 is used to perform global inference operations based on the initial intermediate state tensor. It is understood that each Transformer layer 7012 can output an intermediate state tensor, and in some embodiments, the intermediate state tensor output by a specified Transformer layer 7012 can be set as the target intermediate state tensor.

[0059] In some embodiments, after the transaction suspension engine 200 suspends the target thread 703, the AI ​​model 701 performs inference operations based on the original data and outputs the content to be delivered. Simultaneously, the intermediate tensors involved in the inference process of the AI ​​model 701 are stored in a cache. The transaction suspension engine 200 can extract the intermediate tensors from the cache and set them as the target intermediate tensor. This embodiment uses a non-intrusive acquisition method to obtain the target intermediate tensor, without intruding on the core inference process of the model or interfering with normal model calculation. It maintains the consistency of the AI ​​model's native inference performance and output, while also possessing strong compatibility, system stability, and security. It can adapt to various models and inference frameworks, achieving a low-coupling, pluggable architecture between the evidence storage system and the AI ​​inference pipeline.

[0060] In other embodiments, the large model backbone 701c includes multiple hidden layers. The artificial intelligence model 701 is configured with an authorized output interface. The transaction suspension engine 200 calls this authorized output interface, causing the artificial intelligence model 701 to select a specified hidden layer to output the target intermediate tensor. This embodiment employs a non-intrusive acquisition method to obtain the target intermediate tensor, without intruding on the core inference process of the model or interfering with normal model computation. The target intermediate tensor is output through an internal dedicated secure channel, thus ensuring at the hardware level that the data is not stored locally and is not spied on by the host operating system, thereby improving the security of the target intermediate tensor output.

[0061] The target semantic fingerprint is generated by the target prompt words input by the user and the target intermediate state tensor. It is used to reflect the generation process of the content to be delivered and represents the thought process of the artificial intelligence model under the prompt words, rather than the appearance features of the content to be delivered (such as image pixels or text arrangement).

[0062] Traditional fingerprint generation methods typically involve hashing the deliverable content to obtain a hash value, which is then set as the target semantic fingerprint. However, to obtain deliverable content with the same or similar main visual elements, imitators can slightly adjust the target cue words (e.g., adding filters without changing the main visual elements) to achieve the same deliverable content. However, the imitator's main creative process and main visual parameter configuration information remain identical to the copyright holder's. If a hash-based method is used to generate the target semantic fingerprint, the hash value of the imitator's deliverable content, due to the added filters, will not match the hash value of the copyright holder's deliverable content. This allows the imitator to circumvent the copyright holder's legal rights in the chain of evidence.

[0063] For example, the copyright holder uses the cue word M1 to generate image K1 through an artificial intelligence model. The imitator adjusts the cue word M1, causing the AI-generated image K2 to be cropped, color-corrected, filtered, or have its text adjusted. Image K2 and image K1 are visually almost identical, but the imitator's main creative process and the parameter configuration information of the main visual elements are consistent with the copyright holder's. Using traditional fingerprint generation methods, the hash value of image K2 is not the same as the hash value of image K1. That is, the imitator's target semantic fingerprint is inconsistent with the copyright holder's target semantic fingerprint. Therefore, in the chain of evidence, the copyright holder cannot use the target semantic fingerprint as effective evidence of infringement to sue the imitator.

[0064] In this embodiment, the target semantic fingerprint is generated jointly by the target prompt word and the target intermediate state tensor. The target intermediate state tensor reflects the essential characteristics of the content to be delivered. Regardless of any form or appearance of change made by the imitator, the imitator's content to be delivered cannot deviate from the target intermediate state variable; that is, the target intermediate state variable firmly locks into the essential characteristics of the content to be delivered. As long as the imitator outputs a work that is visually identical to the copyright holder's, the copyright holder can capture the imitator's infringement traces through the target semantic fingerprint obtained from the target intermediate state tensor, thus gaining the initiative in the chain of evidence.

[0065] Therefore, the target semantic fingerprint provided in this application can characterize the semantic source and generation logic of the content, rather than the superficial features of the content, and has the characteristics of being resistant to secondary editing, traceable, and unforgeable. In addition, the target prompt word and the target intermediate state tensor are fused to generate a target semantic fingerprint that can uniquely identify the generation behavior, so that the target semantic fingerprint is simultaneously bound to the user's intent and the model reasoning process, improving the accuracy of source tracing and the credibility of judicial acceptance.

[0066] In some embodiments, the fingerprint extraction module 300 is configured to generate a target semantic fingerprint based on the target prompt word input by the user and the target intermediate state tensor, including: intercepting the intermediate state tensor of the hidden layer of the artificial intelligence model, obtaining the embedding vector of the target prompt word input by the user, fusing the embedding vector with the intermediate state tensor to generate a fused tensor, and performing semantic feature aggregation and dimensionality reduction mapping processing on the fused tensor to generate the target semantic fingerprint.

[0067] The encryption engine 400 runs within the Trusted Execution Environment 704 and works in conjunction with the Transaction Suspension Engine 200. Because the encryption engine 400 runs within the Trusted Execution Environment 704, the entire encryption operation is performed within the TEE hardware-isolated secure zone, thus ensuring that the encryption process is secure, trustworthy, tamper-proof, and tamper-proof.

[0068] Encryption engine 400 is used to perform encryption processing on the content to be delivered while the target thread is suspended, resulting in encrypted data packets.

[0069] In some embodiments, the encryption engine 400 is a one-time encryption engine that performs one-time encryption processing on the content to be delivered while the target thread is suspended, to obtain an encrypted data packet.

[0070] In other embodiments, encryption engine 400 is an encryption engine that performs double nested encryption on the content to be delivered while the target thread is suspended, generating double encrypted data packets. Encryption engine 400 is configured to build a hierarchical encryption structure containing two independent public keys to ensure that no single key holder can independently obtain plaintext data.

[0071] The encryption engine 400 performs ciphertext conversion on the content to be delivered before delivery, ensuring that the content to be delivered will not be leaked or stolen before it is stored on the ground. At the same time, relying on the hardware security capabilities of the trusted execution environment, it guarantees the confidentiality and integrity of the encryption process and the encrypted data, achieving dual protection of privacy and judicial security for AIGC content notarization.

[0072] In some embodiments, the encryption engine 400 is configured to: generate a random session key, and use the random session key to perform inner-layer encryption on the content to be delivered to obtain content ciphertext; encrypt the random session key using the first public key of the judicial authority to obtain inner-layer key ciphertext; and use the second public key of the service provider platform to perform outer-layer encryption on the inner data packet containing the content ciphertext and the inner-layer key ciphertext to obtain encrypted data packet.

[0073] The encryption engine 400 generates random session keys based on a random confidentiality algorithm. The first public key is an asymmetric encryption public key issued and publicly disclosed by a judicial authority. The second public key is an asymmetric encryption public key issued and publicly disclosed by the service provider platform.

[0074] The encryption engine 400 employs a hybrid encryption architecture, balancing encryption efficiency with access control security. It generates a unique random session key for each delivery, performing inner-layer encryption to enhance content confidentiality. Secondly, it uses a first public key from a judicial institution to lock access to the random session key, meeting the requirements for judicial tracing and evidence collection. Thirdly, it uses a second public key from the service provider platform for outer-layer encapsulation, adapting to the platform's storage and transfer management. Therefore, this embodiment effectively prevents data theft and tampering while simultaneously addressing the dual requirements of encryption performance, privacy protection, and judicial verification.

[0075] The evidence storage anchoring module 500 runs within a trusted execution environment. Because the evidence storage anchoring module 500 runs within a trusted execution environment, all logic related to evidence storage, uploading, and blockchain upload is executed within this environment. The host operating system, administrators, and external programs cannot interfere with or forge this process, ensuring the trustworthiness of the evidence storage process and the authenticity of the stored data.

[0076] The evidence storage anchoring module 500 works in conjunction with the transaction suspension engine 200, thus forming an atomic and indivisible process of suspension → encryption → evidence storage → on-chain → receipt, which strongly binds evidence storage and generation behavior, ensuring a complete and unbroken chain of evidence.

[0077] Please see Figure 4 The evidence anchoring module 500 is used to store encrypted data packets to the storage network 41 while the target thread is suspended, package the target semantic fingerprint and the content storage address of the encrypted data packets into a first evidence storage transaction, and send the first evidence storage transaction to the blockchain 42 for evidence storage.

[0078] The content storage address is the address where the encrypted data packets are stored. Storage network 41 is a distributed storage network. Distributed storage networks have the characteristics of decentralization, multiple copies, and high reliability, which can ensure the long-term secure retention of encrypted data packets and form a complete, credible, and judicially auditable chain of evidence in conjunction with blockchain evidence storage.

[0079] The evidence storage anchoring module 500 uploads encrypted data packets to the distributed storage network, whereby the network performs hash calculations on the packets to obtain a hash value. The module then retrieves the hash value returned by the network and sets it as the content storage address. When the content of the encrypted data packet changes, the content storage address also changes; conversely, if the content remains unchanged, the address does not. By strongly binding the encrypted data packet to the content storage address, the module 500 automatically verifies data integrity during download. Therefore, the content storage address obtained in this way possesses self-verification, tamper-proof, and unique characteristics.

[0080] In some embodiments, the evidence anchoring module 500 is further configured to: package the transaction identifier, the hash value of the target semantic fingerprint, the content storage address, the ciphertext hash of the encrypted data packet, the model identifier, the model version, the preset hidden layer identifier, and the generated parameter digest into a second evidence storage transaction, and send the second evidence storage transaction to the blockchain for evidence storage.

[0081] The target semantic fingerprint hash is the hash value obtained by performing a hash operation on the target semantic fingerprint. The encrypted data packet ciphertext hash is the hash value obtained by performing a hash operation on the encrypted data packet. The model identifier is the identity code of the artificial intelligence model. The model version is the version number of the artificial intelligence model. The preset hidden layer identifier is the identifier of the hidden layer that outputs the target intermediate state tensor. The generated parameter digest is the hash value of the hyperparameters and configuration parameters used by the artificial intelligence model to infer and generate the deliverable content.

[0082] The evidence anchoring module 500 packages the aforementioned multi-dimensional data into a second evidence transaction for on-chain storage, fully solidifying key information across all dimensions, including transaction identity, content semantics, encrypted storage, model source, version environment, fingerprint extraction rules, and generation configuration. Adopting an architecture of storing certificates on-chain and encrypted data off-chain, it saves on-chain resources while achieving dual verification of data integrity and semantics. Simultaneously, it locks the generation environment and inference conditions, ensuring that AIGC generation behavior is fully traceable, reproducible, tamper-proof, and non-repudiable, significantly improving the integrity, rigor, and judicial acceptability of the evidence.

[0083] The consensus oracle module 600 is used to continuously monitor the blockchain, obtain the successful notarization receipt of the first notarization transaction, and transmit the successful notarization receipt to the transaction suspension engine 200.

[0084] The consensus oracle module 600 serves as an intermediary monitoring module between the front-end evidence storage system 100 and the blockchain. It is specifically responsible for connecting to the blockchain, reading the on-chain state, and sending the on-chain results back to the transaction suspension engine 200. Specifically, the consensus oracle module 600 continuously monitors the blockchain, polling the blockchain nodes in real-time to check whether the first evidence storage transaction has been uploaded to the blockchain and whether the first evidence storage transaction has completed block consensus. If the first evidence storage transaction has been packaged, uploaded to the blockchain, and confirmed by the entire network consensus before being written into the block, the blockchain generates a successful evidence storage receipt. The successful evidence storage receipt indicates that the evidence storage transaction has been successfully written into the blockchain block.

[0085] After the first notarization transaction completes the network consensus and is successfully uploaded to the chain, the consensus oracle module 600 obtains the corresponding notarization success receipt and pushes the notarization success receipt to the transaction suspension engine 200. This provides the transaction suspension engine 200 with a credible on-chain basis to allow the target thread to release the content to be delivered, thus realizing the orderly linkage between the asynchronous consensus process of the blockchain and the local synchronous notarization delivery process.

[0086] In some embodiments, the consensus oracle module 600 is configured to: obtain a successful proof receipt returned by the blockchain; verify whether the target identification information contained in the successful proof receipt is consistent with the identification information of the local transaction record, and whether the number of block confirmations has reached a preset security threshold; if the target identification information contained in the successful proof receipt is consistent with the identification information of the local transaction record, and the number of block confirmations has reached the preset security threshold, transmit the successful proof receipt to the transaction suspension engine; if the target identification information contained in the successful proof receipt is inconsistent with the identification information of the local transaction record, or if the number of block confirmations has not reached the preset security threshold within a preset time, transmit a timeout signal to the transaction suspension engine to trigger a circuit breaker operation.

[0087] The successful evidence storage receipt includes the transaction hash, contract address, block height, number of block confirmations, and target identifier information. The target identifier information includes the transaction identifier, content storage address, and target semantic fingerprint hash.

[0088] The transaction hash is a unique digest identifier for a single notarized transaction on the blockchain. The contract address is a unique on-chain address where the notarized smart contract is deployed. The block height is the on-chain number of the first notarized transaction in the block. The block confirmation count is the number of subsequent blocks appended to the current block.

[0089] If the target identifier information in the successful evidence storage receipt is consistent with the identifier information in the local transaction record, it means that the first evidence storage transaction corresponding to the successful evidence storage receipt matches the deliverable content obtained from this AIGC generation behavior. The consensus oracle module 600 can effectively prevent forged receipts, replay attacks and transaction serial number risks by verifying the consistency between the multi-dimensional fields of the successful evidence storage receipt and the local transaction record.

[0090] If the target identifier information in the successful notarization receipt matches the identifier information in the local transaction record, and the number of block confirmations reaches a preset safety threshold, the consensus oracle module 600 can determine that the current on-chain transactions are relatively stable. This avoids the problem of notarization failure caused by block forks and rollbacks. At the same time, the consensus oracle module 600 has a preset timeout mechanism. If the timeout is not met, a circuit breaker operation is triggered. This ensures that the notarization result is authentic, reliable, and irreversible, while also preventing requests from being suspended for a long time and consuming resources, thus improving the system's security verification and fault tolerance capabilities.

[0091] The transaction suspension engine 200 is configured to encapsulate the execution process of the fingerprint extraction module 300, the encryption engine 400, and the evidence storage anchoring module 500 into an atomic transaction. After receiving the evidence storage success receipt transmitted by the consensus oracle module 600, it resumes the suspended target thread 703 to deliver the content to be delivered to the client 702. If the evidence storage success receipt is not received within a preset time, a circuit breaker operation is triggered to destroy the content to be delivered in the encrypted memory.

[0092] An atomic transaction refers to the execution process of the fingerprint extraction module 300, encryption engine 400, and evidence storage and anchoring module 500 as an integral and indivisible process that cannot be skipped or executed independently. The transaction suspension engine 200 encapsulates the execution process of the fingerprint extraction module 300, encryption engine 400, and evidence storage and anchoring module 500 into an atomic transaction, preventing bypassing evidence storage and directly outputting content. It forces a fixed sequence of target semantic fingerprint → encryption → evidence storage, ensuring a closed loop throughout the entire process.

[0093] After receiving the successful evidence storage receipt transmitted by the consensus oracle module 600, the transaction suspension engine 200 indicates that the first evidence storage transaction has been consensus-uploaded to the chain and added to the block. It then resumes the suspended target thread 703 to deliver the content to be delivered to the client 702.

[0094] The circuit breaker operation refers to the transaction suspension engine 200 not resuming the suspended target thread 703 and destroying the content to be delivered in encrypted memory. If the transaction suspension engine 200 does not receive a successful notarization receipt within a preset time, it needs to cancel the output of the content to be delivered to avoid the target thread 703 suspending and occupying resources for an extended period. To prevent leakage of the content to be delivered, the transaction suspension engine 200 also needs to destroy the content to be delivered in encrypted memory. This achieves atomic security control, ensuring that delivery is only possible upon successful notarization and that content is automatically destroyed in case of notarization failure, thus guaranteeing that AIGC content is not leaked before legal notarization is completed.

[0095] The transaction suspension engine 200, fingerprint extraction module 300, encryption engine 400, evidence storage and anchoring module 500, and consensus oracle module 600 are all deployed in the trusted execution environment of the server. The trusted execution environment provides encrypted memory to protect the content to be delivered during the suspension period.

[0096] In this embodiment, the transaction suspension engine 200, fingerprint extraction module 300, encryption engine 400, evidence storage and anchoring module 500, and consensus oracle module 600 are deployed as a whole within a trusted execution environment. Relying on hardware isolation capabilities, external systems and privileged users are isolated from interference and tampering. Furthermore, hardware-level security protection is provided for the content to be delivered during the suspension period through encrypted memory, preventing plaintext data leakage and unauthorized reading.

[0097] The Trusted Execution Environment is configured to generate remote proof reports, which include at least a Trusted Execution Environment metric, a module code hash, and a transaction identifier, to prove that the atomic transaction was executed by the expected trusted code.

[0098] The Trusted Execution Environment (TEX) metric is an integrity measure of the TEX's firmware, hardware environment, and system baseline. It is used to prove that the TEX's environment is clean and has not been compromised or tampered with.

[0099] The module code hash is the hash value of the program code of the transaction suspension engine 200, fingerprint extraction module 300, encryption engine 400, evidence storage and anchoring module 500 and consensus oracle module 600 in the trusted execution environment. It is used to prove that the module code has not been replaced or that no malicious programs have been injected.

[0100] The trusted execution environment provided in this application generates a remote proof report containing environment metrics, module code hashes, and transaction identifiers. This report can provide a credible endorsement of the integrity of the operating environment, the legality of the business module code, and the uniqueness of the transaction, further enhancing the credibility, verifiability, and judicial acceptability of the entire AIGC evidence storage process.

[0101] In some embodiments, the transaction suspension engine 200 is configured to trigger a circuit breaker operation to destroy the content to be delivered in encrypted memory, including: instructing the memory controller of the trusted execution environment to mark the memory pages storing the content to be delivered and the target intermediate tensor as invalid and perform an eviction operation by modifying the page table entries of the encrypted memory, so that the cache of the encrypted memory is physically erased to destroy the content to be delivered and the target intermediate tensor.

[0102] In scenarios such as evidence storage timeout, verification failure, or on-chain anomalies, the transaction suspension engine 200 activates the circuit breaker mechanism to specifically clear sensitive data (such as content to be delivered and target intermediate tensors) in the encrypted memory of the trusted execution environment, thus preventing the leakage of sensitive data.

[0103] Specifically, the transaction suspension engine 200 sends a cleanup command to the memory controller of the trusted execution environment. The memory controller then modifies the page table entries of the encrypted memory according to the cleanup command. These page table entries are configuration entries used to record memory page addresses, permissions, and valid states. Once the page table entries of the encrypted memory are modified, the memory pages corresponding to those entries will not be recognized or accessed by the system and are logically invalidated. Therefore, the memory pages storing the content to be delivered and the target intermediate tensor enter an invalid state.

[0104] An eviction operation refers to the forced removal of data from a memory page, preventing it from residing in encrypted memory. When a memory page storing the content to be delivered and the target intermediate tensor becomes invalid, the transaction suspension engine 200 executes an eviction operation, causing the encrypted memory cache to be physically erased and destroying the content to be delivered and the target intermediate tensor.

[0105] This application embodiment intervenes in the destruction process through the memory controller of the trusted execution environment. By modifying page table entries, invalidating memory pages, and performing eviction operations, it blocks the data access path at the memory management level. Then, it completely destroys the content to be delivered and the target intermediate tensor through the physical erasure of the encrypted memory cache. Unlike the deletion method of ordinary software logic, this application embodiment can completely clear sensitive data without memory residue or irreversibility. It effectively prevents data from being stolen, traced back, or maliciously scraped in the event of a circuit breaker, and strengthens the information security protection capability of AIGC content in abnormal scenarios.

[0106] In some embodiments, the evidence anchoring module 500 is configured to send the first evidence transaction to the blockchain for evidence storage, including the following steps: sending the first evidence transaction to N blockchains for evidence storage, so that each blockchain returns an evidence record based on the first evidence transaction.

[0107] N blockchains are multiple independent blockchains that are not technically or managerially interdependent. For example, N blockchains could be a judicial consortium blockchain A, a public blockchain B, another judicial consortium blockchain C, etc. N is a natural number greater than 1. A notarization record is an immutable record generated on each blockchain's distributed ledger after successfully receiving and confirming the first notarization transaction. The notarization record includes on-chain credentials such as the transaction hash, the block height, and a timestamp.

[0108] This application adopts a data redundancy backup method. Even if N-1 of the blockchains have problems, as long as the evidence storage records on at least one blockchain remain accessible and consistent, the core evidence storage credentials will not be lost. This significantly improves the ability of the entire front-end evidence storage system to resist external blockchain infrastructure risks and ensures the high availability of evidence storage services.

[0109] Please see Figure 5The pre-existing evidence storage system 100 based on atomic collaborative transactions also includes a monitoring module 700. The monitoring module 700 is configured to obtain the evidence storage records returned by each of the N blockchains and save the evidence storage records returned by each of the N blockchains in a preset on-chain record table.

[0110] The on-chain record table is a local database table maintained by the monitoring module. Each record in the on-chain record table is associated with an AIGC-generated transaction and records the status and detailed information of the evidence of the AIGC-generated transaction on each blockchain.

[0111] The evidence storage anchoring module 500 simultaneously submits the same first evidence storage transaction to multiple different blockchains, initiating cross-chain evidence storage requests. Each blockchain independently completes transaction consensus and block packaging based on the evidence storage request, generating and returning its own evidence storage record. A dedicated monitoring module 700 collects the evidence storage records returned by multiple blockchains and centrally stores them in a pre-defined on-chain record table.

[0112] This application adopts a multi-chain synchronous evidence storage architecture, which distributes the same evidence storage transaction to multiple blockchains to complete consensus and retention. Relying on the redundancy and backup characteristics of multi-chain, it effectively resists single-chain anomalies, data loss and malicious tampering. The monitoring module 700 uniformly collects and archives the evidence storage records of each chain, realizes the retention of multiple copies of evidence certificates and cross-verification, and further enhances the reliability of evidence storage data and judicial evidentiary effect.

[0113] In some embodiments, the monitoring module 700 is further configured to: periodically traverse the on-chain record table, perform batch queries on each blockchain to verify whether each evidence record in the on-chain record table is in an accessible and consistent state on the corresponding blockchain; in response to the evidence record of an abnormal blockchain not being in an accessible and consistent state, obtain complete data corresponding to the evidence record from the normal blockchain; and based on the complete data corresponding to the evidence record, send an evidence completion request to the abnormal blockchain so that the abnormal blockchain completes the evidence record based on the complete data.

[0114] The monitoring module automatically scans the on-chain record table according to a preset time period (e.g., daily, weekly). During a single traversal, it initiates centralized query requests for multiple evidence records across multiple blockchains. This verifies whether the evidence record can be found in the corresponding blockchain through a public node interface or browser, and whether the evidence record queried from the corresponding blockchain is consistent with the evidence record stored in the on-chain record table. In other words, it verifies whether each evidence record in the on-chain record table is in an accessible and consistent state on the corresponding blockchain. If accessible and consistent, it determines that each evidence record in the on-chain record table is in an accessible and consistent state on the corresponding blockchain. If inaccessible or inconsistent, it identifies the normal blockchain and the abnormal blockchain. It obtains the complete data corresponding to the evidence record from the normal blockchain and, based on the complete data, sends an evidence completion request to the abnormal blockchain to complete the evidence record based on the complete data.

[0115] An anomalous blockchain is one whose evidence storage records are found to be inaccessible or inconsistent during periodic traversal verification. A normal blockchain is one whose evidence storage records are verified to be accessible and consistent during this verification. Complete data refers to the original evidence storage data contained in the first evidence storage transaction that needs to be supplemented to the anomalous blockchain, namely the binding information of the target semantic fingerprint and the content storage address of the encrypted data packet.

[0116] The evidence preservation completion request is used to request the monitoring module to construct a new blockchain transaction whose content is the same as or logically equivalent to the original first evidence preservation transaction. This is used to recreate a correct copy of the lost or erroneous evidence preservation record on the abnormal blockchain.

[0117] This application's embodiments significantly enhance the long-term reliability and evidentiary validity of the multi-chain evidence storage architecture by introducing an automated and proactive monitoring and repair mechanism. Specifically, the monitoring module can periodically and proactively conduct health checks on evidence records stored on multiple blockchains, verifying their accessibility and data consistency across each chain, thereby achieving full lifecycle monitoring of the evidence storage status. When evidence records on an abnormal blockchain are lost, damaged, or inconsistent with the original data, this mechanism can automatically and intelligently obtain the correct and complete original evidence storage data from other blockchains in normal condition and initiate an evidence storage completion request to the abnormal blockchain, thereby automatically repairing the invalid copies. This ensures that the entire system not only establishes redundant copies but also guarantees that these redundant copies remain valid and consistent throughout their long lifespan, providing a highly robust and sustainable underlying technical guarantee for the judicial evidence storage of AIGC content.

[0118] The core working mechanism of this application embodiment is atomic collaborative transactions. The execution processes of the fingerprint extraction module 300, encryption engine 400, evidence storage and anchoring module 500, and consensus oracle module 600 are encapsulated into an indivisible atomic transaction through the transaction suspension engine 200. This atomic transaction has the following characteristics: 1) Atomicity: All operations in an atomic transaction have only two states: either all operations are successfully completed, or all operations are not executed. If the target semantic fingerprint extraction fails, the encryption operation is abnormal, the storage upload is interrupted, or the blockchain consensus is not reached within the preset time, the entire atomic transaction is judged as a failure. The system will roll back and destroy the content to be delivered in the encrypted memory, and will not deliver any data to the client.

[0119] 2) Consistency: The standard for successful transaction submission is that the consensus oracle module 600 confirms that the first evidence-based transaction has reached finality on the blockchain. This means that any content successfully delivered to the client must have its evidence-based record irreversibly anchored on the blockchain. The evidence-based time must be earlier than the delivery time, forming a complete and closed evidence chain.

[0120] 3) Isolation: During the execution (suspension) of an atomic transaction, the content to be delivered is locked in the encrypted memory of the trusted execution environment, isolated from external systems. The host operating system, database administrator, and any privileged process cannot access or interfere with this content to be delivered.

[0121] 4) Durability: Once the atomic transaction is successfully committed (acknowledgment confirmation), the first evidence-based transaction is written to the blockchain and confirmed by multiple blocks, thus becoming immutable. Simultaneously, the double-encrypted data packets are redundantly stored in the distributed storage network, ensuring long-term availability.

[0122] To demonstrate the technical effects of the embodiments of this application, the embodiments of this application are compared with related technology A "traditional asynchronous post-event evidence preservation", related technology B "fingerprint technology based on result appearance", and related technology C "general weighted encryption scheme", and the following analysis is made: First level: Holistic innovation in system architecture → From loose toolsets to atomic transaction systems.

[0123] Related technologies treat content generation, fingerprint extraction, encrypted storage, and on-chain evidence preservation as independent processes, lacking coordination mechanisms and atomicity guarantees between them. This application, for the first time, integrates these processes into a collaborative working system uniformly scheduled by a transaction suspension engine and running within a trusted execution environment, encapsulating the entire execution process as an atomic transaction with ACID properties.

[0124] The second level: a complete reshaping of temporal relationships → from post-hoc evidence preservation to the release of preconditions.

[0125] The evidence storage in related technology A occurs after content delivery, resulting in an inherent time-series disconnect. This application's embodiment transforms evidence storage from an "asynchronous background task after delivery" to a "synchronous pre-delivery checkpoint" through the truncation-suspend-conditional release mechanism of the transaction suspension engine. Successful evidence storage is a necessary condition for content delivery, not an optional post-processing step. This reshaping of the time sequence involves not only simple adjustments to the process order but also requires the introduction of a series of supporting mechanisms at the system architecture level, such as state machine management, session persistence, and timeout circuit breakers.

[0126] The third level: dimensional upgrade of fingerprint technology → from the appearance of the result to the generation process.

[0127] Related technology B's fingerprinting technology is based on the generated content appearance (pixel distribution, character arrangement), which is easily destroyed by secondary editing. The fingerprint extraction module of this application's embodiment delves into the inference process of the AI ​​model, intercepting the intermediate state tensor reflecting the model's semantic understanding of the prompt words, and combining it with the embedding vector of the prompt words to generate the target semantic fingerprint. This target semantic fingerprint locks into the "genetic genes" of the content to be delivered within the model, rather than the "physical appearance" of the content to be delivered, fundamentally solving the problem of weak anti-tampering capability of traditional fingerprinting technology.

[0128] Fourth level: Power balance design of cryptographic architecture → from static ownership to hierarchical mutual control.

[0129] While related technology C's distributed encryption introduces multiple keys, permission activation is static and lacks dynamic coupling with judicial procedures. The encryption engine in this application constructs a hierarchical encryption structure that prevents judicial institutions from independently decrypting and prevents platforms from accessing the content. In the subsequent compliant decryption process, this structure is further hard-locked with judicial retrieval events and audit log uploads on the blockchain, ensuring that each decryption is triggered by a legitimate judicial event and leaves an immutable audit record.

[0130] The following describes the implementation details of the embodiments of this application in detail with specific application examples. The embodiments of this application take the scenario of a user requesting an AI model to generate an image through an API as an example, and fully cover the entire process from request initiation to content delivery (or circuit breaker rejection).

[0131] I. System Deployment The hardware environment of this embodiment is a server equipped with an Intel Xeon processor (supporting SGX), or an equivalent domestic processor platform that supports a trusted execution environment. The operating system is Linux, and the artificial intelligence model is the StableDiffusion model.

[0132] Within the trusted execution environment of this server, all five modules provided in this application embodiment are deployed, as shown in Table 1: Table 1

[0133] The preset parameters are as follows: 1) Preset duration: 60 seconds. The preset duration is greater than the target blockchain's average block time of 15 seconds × 3 confirmations for security margin.

[0134] 2) Number of confirmed blocks: 3 blocks.

[0135] 3) Dimensions of the target semantic fingerprint: 64 dimensions.

[0136] 4) Distributed storage network: IPFS network.

[0137] 5) Inner layer encryption algorithm: SM2 elliptic curve public key encryption.

[0138] 6) Outer encryption algorithm: SM2 elliptic curve public key encryption.

[0139] 7) Content encryption algorithm: AES-256-GCM.

[0140] II. Success Path: The evidence is successfully stored, and the content is delivered normally.

[0141] Step 1: The user initiates a request.

[0142] Users send HTTP POST requests (i.e., content generation requests) through the API gateway. The request body of the HTTP POST request includes a target prompt: "A Shiba Inu in a spacesuit is walking on the moon, digital art style, high resolution." The API gateway forwards the HTTP POST request to the Stable Diffusion model.

[0143] Step 2: The artificial intelligence model performs inference.

[0144] The Stable Diffusion model receives the target prompt word "Prompt" and completes image generation through steps such as text encoding, U-Net diffusion denoising, and VAE decoding. At the output end, the Stable Diffusion model generates the raw pixel tensor data to be delivered (i.e., the content to be delivered), with dimensions [1, 3, 1024, 1024].

[0145] Step 3: Transaction suspension engine's truncation and suspension.

[0146] Just as the raw pixel tensor data is about to enter the image post-processing pipeline, the transaction suspension engine truncates the raw pixel tensor data, locks the raw pixel tensor data in the encrypted memory of the trusted execution environment, and switches the corresponding target thread state from active to suspended.

[0147] Meanwhile, the fingerprint extraction module, which works in conjunction with the transaction suspension engine, intercepts the target intermediate state tensor output from the penultimate layer of U-Net through the authorized output interface during the inference process of the Stable Diffusion model. When the process is suspended in step 3, the target intermediate state tensor and the content to be delivered are locked in encrypted memory for subsequent processing.

[0148] During the suspension period, the target thread occupies session resources by maintaining an inactive HTTP / TCP long-lived connection. The TCP connection remains in the ESTABLISHED state, but the application layer does not send any data packets. Instead, it periodically sends zero-window probe packets through the TCP Keep-Alive mechanism to ensure that intermediate network devices do not tear down the connection due to timeout.

[0149] Step 4: The transaction suspension engine triggers an atomic transaction.

[0150] The transaction suspension engine sends coordinated trigger signals to the fingerprint extraction module, encryption engine, and evidence storage anchoring module, encapsulating their execution processes into an atomic transaction. During the execution of this atomic transaction, if any module returns a failure status (such as fingerprint extraction error, encryption operation failure, or storage upload interruption), the transaction suspension engine determines that the atomic transaction has failed and executes the circuit breaker process without waiting for the preset timeout to expire.

[0151] Step 5: The fingerprint extraction module generates the target semantic fingerprint.

[0152] The fingerprint extraction module performs the following operations in encrypted memory: 5.1) Capture the target intermediate state tensor of the penultimate layer output of U-Net saved in step 3, with dimensions [1, 1280, 64, 64].

[0153] 5.2) Obtain the embedding vector of the target prompt word “A Shiba Inu in a spacesuit walks on the moon, digital art style, high resolution” from the text encoder, with dimensions [1, 768].

[0154] 5.3) Cross-attention weighted fusion is performed on the embedding vector of the target prompt word "Prompt" and the target intermediate state tensor. Using the embedding vector as the query condition, the spatial positions of the target intermediate state tensor are weighted and aggregated to generate a fused tensor. In the fused tensor, visual features strongly related to core semantics such as "spacesuit", "Shiba Inu", and "moon" are enhanced, while irrelevant background noise is suppressed.

[0155] 5.4) Global average pooling is performed on the fused tensor, compressing it along the spatial dimension to obtain a one-dimensional semantic vector. This step removes the superficial information such as the object's specific position and pose, which is easily affected by secondary editing such as cropping and rotation.

[0156] 5.5) The one-dimensional semantic vector is reduced in dimensionality by using the PCA algorithm. Principal components with a cumulative variance contribution rate of 95% are selected and compressed to 64 dimensions to generate semantic feature vectors.

[0157] 5.6) Perform SHA-256 hash operation on the 64-dimensional semantic feature vector, truncate the first 64 bits, and generate the final target semantic fingerprint FP_semantic.

[0158] Step 6: The encryption engine performs double encryption.

[0159] The encryption engine performs the following operations in the TEE encrypted memory: 6.1) Obtain the raw pixel tensor data D_raw of the content to be delivered.

[0160] 6.2) Generate a random session key K_sym, encrypt D_raw using the AES-256-GCM symmetric encryption algorithm to generate the content ciphertext C_data; call the first public key PK_court preset by the judicial authority to perform SM2 asymmetric encryption on K_sym to generate the inner key ciphertext C_key_inner = Enc(PK_court, K_sym); combine C_data and C_key_inner to form the inner data packet P_inner.

[0161] 6.3) Call the service provider's platform's second public key PK_platform to perform SM2 encryption on the inner data packet P_inner, and obtain the encrypted data packet C_double.

[0162] Step 7: The evidence storage and uploading module performs storage and on-chain processing.

[0163] The evidence storage anchoring module performs the following operations in encrypted memory: 7.1) The encrypted data packet C_double is uploaded to the distributed storage network IPFS through an external proxy process. The distributed storage network IPFS performs a hash operation on the encrypted data packet C_double to obtain the content storage address, and returns the content storage address CID = QmXyZabc123….

[0164] 7.2) Package the SHA-256 hash value H(FP_semantic) of the target semantic fingerprint FP_semantic with the content storage address CID into the first evidence storage transaction Tx_storage. The data structure of the first evidence storage transaction is as follows: text { "cid": "QmXyZabc123…", "fingerprint_hash": "0x7a9f3f6d…", "timestamp": "2025-01-15T14:30:00Z", "model_id": "SDXL-20250101", "model_version": "V2.0" } 7.3) Send the first notarized transaction Tx_storage to the blockchain and obtain the transaction hash TxID_storage = 0xabcd….

[0165] Step 8: Consensus oracle module listening and verification.

[0166] While the consensus oracle module initiates the transaction in step 7.3, the external listening agent begins to continuously listen for block production events on the blockchain; the core verification logic waits for the successful evidence storage receipt pushed by the external listening agent within the trusted execution environment.

[0167] 8.1) Track the transaction hash TxID_storage to confirm that the first stored transaction has been packaged into block #N.

[0168] 8.2) Continue to wait for the generation of subsequent blocks and track the block confirmation number of the blocks following Block#N.

[0169] 8.3) When the block confirmation count is 3, the external listening agent pushes the successful evidence storage receipt to the trusted execution environment. The consensus oracle module verifies the signature validity of the successful evidence storage receipt and the fact that the block confirmation count has reached the preset security threshold within the trusted execution environment. It determines that the first evidence storage transaction has reached finality and transmits the successful evidence storage receipt to the transaction suspension engine.

[0170] Step 9: Transaction suspension engine resumes delivery.

[0171] Upon receiving the successful verification signal, the transaction suspension engine determines that the atomic transaction has been successfully committed. The engine then switches the API response thread from suspended to active status and performs the following operations: 9.1) Output the original pixel tensor data from encrypted memory to the regular memory area, and hand it over to the GPU rendering pipeline to perform image post-processing (color correction, format conversion) to generate the final PNG format image file.

[0172] 9.2) Send an HTTP 200 status code to the client, with the response body containing the generated image file.

[0173] At this point, the target semantic fingerprint FP_semantic and the content storage address CID of the encrypted data packet in the image file received by the client have been irreversibly confirmed on the blockchain. The evidence storage timestamp (recorded in the block header of Block#N) is earlier than the time when the client received the content to be delivered, completing the evidence chain.

[0174] III. Failure Path: Evidence storage timeout, circuit breaker destruction.

[0175] Suppose that during the execution of this embodiment, the blockchain encounters a large-scale transaction congestion, and the first evidence storage transaction TxID_storage fails to obtain the required number of block confirmations within a preset time (60 seconds).

[0176] Step 10: Consensus Oracle Timeout Detection.

[0177] If the consensus oracle module fails to verify that the block containing the first notarized transaction TxID_storage has been confirmed by three subsequent blocks after 60 seconds of the suspension period, it transmits a timeout signal to the transaction suspension engine.

[0178] Step 11: The transaction suspension engine triggers a circuit breaker.

[0179] If the transaction suspension engine determines that an atomic transaction has failed, it will execute the circuit breaker process. 1) Immediately switch the target thread state from SUSPENDED to TERMINATED.

[0180] 2) By using the memory controller of the Trusted Execution Environment, the page table entries of the memory pages storing the above data are modified, the memory pages are marked as invalid and an eviction instruction is issued to the CPU cache system, so that the data is physically erased at the hardware level, ensuring that the host operating system or any subsequent physical memory dump cannot recover the data.

[0181] 3) Cut off the communication channel with the external agent process and abandon the ratification of the data that has been sent.

[0182] 4) Send an HTTP 503 Service Unavailable status code to the client, with the response body containing the error message: "Content delivery aborted due to notarization failure. Please try again." During the above process, the client did not receive any AIGC content. The system would rather require the user to retry the complete AIGC generation and evidence preservation process than deliver content with an uncertain evidence preservation status, thus firmly adhering to the ironclad rule of "no evidence-preserved content leaking out".

[0183] IV. Module Internal Exception Handling.

[0184] In addition to the timeout and circuit breaker scenarios mentioned above, atomic transactions may also encounter immediate exceptions within the module during execution. For example: 1) the fingerprint extraction module fails to capture the intermediate state tensor (model inference exception); 2) the encryption engine fails to perform encryption operations (key loading exception); 3) the evidence storage and anchoring module times out of upload time (network connection interruption).

[0185] When any of the above anomalies occur, the corresponding module returns a failure status to the transaction suspension engine. If the transaction suspension engine determines that a certain part of the atomic transaction cannot be completed, it executes the same circuit breaker process as in step 11, without waiting for the preset timeout to expire. This design ensures the atomicity of the transaction, and any partial failure will lead to a complete rollback.

[0186] In summary, this application embodiment encapsulates the three major processes of target semantic fingerprint extraction, encryption, and evidence storage anchoring into atomic transactions, ensuring that the three are inseparable. This avoids the risks of bypassing evidence storage to directly deliver content and tampering with the evidence storage process, thereby improving the security and compliance of the AIGC content generation process. Furthermore, this application embodiment uses a transaction suspension engine to suspend the target thread and truncate the output data stream promptly after the AI ​​model infers and generates the content to be delivered. This creates a secure processing window before the content is delivered to the client, preventing the direct leakage of undocumented content. Then, relying on the hardware isolation protection of a trusted execution environment and encrypted memory, this application embodiment deploys the target semantic fingerprint extraction, encryption, evidence storage, and oracle verification processes on an internal network, providing hardware-level isolation and encryption protection for the content to be delivered and the target intermediate tensor to prevent plaintext theft. Finally, this application embodiment obtains the target semantic fingerprint through a fingerprint extraction module, providing reliable feature evidence for subsequent content tracing, infringement verification, and judicial confirmation.

[0187] It should be noted that in the above embodiments, there is no necessarily a certain order between the steps. Those skilled in the art can understand from the description of the embodiments of this application that the above steps may have different execution orders in different embodiments, that is, they may be executed in parallel or in turn, etc.

[0188] See Figure 6 , Figure 6 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 601 includes one or more processors 602 and a memory 603. The memory 603 is connected to one or more processors 602, for example, via a bus.

[0189] Processor 602 is configured to support the server in performing the corresponding functions in the methods described in the above method embodiments. The processor may be a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof. The aforementioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0190] Memory 603 is used to store program code, etc. Memory may include volatile memory (VM), such as random access memory (RAM); memory may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory may also include combinations of the above types of memory.

[0191] The memory 603 can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the pre-existing evidence storage system based on atomic cooperative transactions in the embodiments of this application. The processor executes the non-volatile software programs, instructions, and modules stored in the memory to perform various functional applications and data processing of the pre-existing evidence storage system based on atomic cooperative transactions, thereby realizing the functions of each module or unit of the pre-existing evidence storage system based on atomic cooperative transactions provided in the above method embodiments.

[0192] The memory may include a stored program area and a stored data area. The stored program area may store the operating system and application programs required for at least one function. The stored data area may store data created based on the use of a pre-existing evidence system based on atomic cooperative transactions, etc.

[0193] The one or more modules are stored in the memory. When executed by the one or more processors, they execute the pre-existing evidence storage system based on atomic collaborative transactions in any of the above method embodiments. For example, they execute the method steps described in the above method embodiments to realize the functions of the modules described in the above device embodiments.

[0194] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a server, cause the server to execute the pre-existing evidence storage system based on atomic collaborative transactions as described in the foregoing embodiments.

[0195] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0196] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A pre-existing evidence storage system based on atomic collaborative transactions, applied to a server, characterized in that, include: The transaction suspension engine is deployed at the output end of the model inference pipeline of the artificial intelligence model. It is used to truncate the deliverable content output by the artificial intelligence model and suspend the target thread after the artificial intelligence model generates the deliverable content and before it is delivered to the client, and lock the deliverable content in the encrypted memory of the trusted execution environment. The fingerprint extraction module, running within the trusted execution environment, works in conjunction with the transaction suspension engine to intercept the target intermediate state tensor generated by the hidden layer of the artificial intelligence model during the reasoning process about the content to be delivered while the target thread is suspended, and generates a target semantic fingerprint based on the target prompt words input by the user and the target intermediate state tensor. An encryption engine, running within the trusted execution environment, works in conjunction with the transaction suspension engine to perform encryption processing on the content to be delivered during the suspension of the target thread, thereby obtaining encrypted data packets. The evidence storage anchoring module runs within the trusted execution environment and works in conjunction with the transaction suspension engine. It is used to store the encrypted data packet to the storage network during the period when the target thread is suspended, package the target semantic fingerprint and the content storage address of the encrypted data packet into a first evidence storage transaction, and send the first evidence storage transaction to the blockchain for evidence storage. The consensus oracle module is used to continuously monitor the blockchain, obtain the proof of successful proof of the first proof transaction, and transmit the proof of successful proof to the transaction suspension engine. The transaction suspension engine is configured to encapsulate the execution process of the fingerprint extraction module, the encryption engine, and the evidence storage anchoring module into an atomic transaction. After receiving the evidence storage success receipt transmitted by the consensus oracle module, the suspended target thread is resumed to deliver the content to be delivered to the client. If the successful evidence storage receipt is not received within the preset time period, a circuit breaker operation is triggered to destroy the content to be delivered in the encrypted memory.

2. The system according to claim 1, characterized in that, The storage network is a distributed storage network, and the evidence anchoring module is configured as follows: The encrypted data packet is uploaded to the distributed storage network, so that the distributed storage network performs hash calculation on the encrypted data packet to obtain a hash value; Obtain the hash value returned by the distributed storage network and set the hash value as the content storage address.

3. The system according to claim 1, characterized in that, The transaction suspension engine is also configured to: after suspending the target thread, generate a transaction identifier for the content to be delivered, and maintain a local transaction record containing the transaction identifier, session identifier, model configuration summary and suspension status locally, wherein the session identifier is used to identify the current session between the target thread and the client; The evidence storage anchoring module is further configured to: package the transaction identifier, the hash value of the target semantic fingerprint, the content storage address, the ciphertext hash of the encrypted data packet, the model identifier, the model version, the preset hidden layer identifier, and the generated parameter digest into a second evidence storage transaction, and send the second evidence storage transaction to the blockchain for evidence storage, wherein the generated parameter digest is the hash value of the hyperparameters and configuration parameters used by the artificial intelligence model to infer and generate the content to be delivered.

4. The system according to claim 3, characterized in that, The consensus oracle module is configured as follows: Obtain the proof of evidence storage success receipt returned by the blockchain, which includes the number of block confirmations and target identifier information; Verify whether the target identification information contained in the successful evidence storage receipt is consistent with the identification information of the local transaction record, and whether the number of block confirmations has reached a preset security threshold; If the target identification information contained in the successful evidence storage receipt is consistent with the identification information of the local transaction record, and the number of block confirmations reaches a preset security threshold, the successful evidence storage receipt is transmitted to the transaction suspension engine. If the target identification information contained in the successful evidence receipt is inconsistent with the identification information of the local transaction record, or if the number of block confirmations does not reach the preset security threshold within the preset time period, a timeout signal is transmitted to the transaction suspension engine to trigger the circuit breaker operation.

5. The system according to claim 1, characterized in that, The transaction suspension engine is configured to maintain a long-lived, inactive connection during the suspension period to occupy session resources, thereby enabling the transaction suspension engine to maintain a communication connection with the client. The transaction suspension engine is also configured to: when resuming the delivery of the content to be delivered, control the target thread to send the delivery status code and the content to be delivered to the client; When the circuit breaker operation is triggered, the target thread is controlled to return the circuit breaker status code and the error message indicating that the certificate storage failed to be returned to the client.

6. The system according to claim 3, characterized in that, The transaction suspension engine, fingerprint extraction module, encryption engine, evidence storage and anchoring module, and consensus oracle module are all deployed in the trusted execution environment of the server. The trusted execution environment provides encrypted memory to protect the content to be delivered during the suspension period. The trusted execution environment is configured to generate a remote proof report, which includes at least a trusted execution environment metric, a module code hash, and the transaction identifier, to prove that the atomic transaction was executed by the expected trusted code.

7. The system according to claim 1, characterized in that, The transaction suspension engine is configured to trigger a circuit breaker operation to destroy the content to be delivered in the encrypted memory, including: instructing the memory controller of the trusted execution environment to mark the memory pages storing the content to be delivered and the target intermediate tensor as invalid and perform an eviction operation by modifying the page table entries of the encrypted memory, so that the cache of the encrypted memory destroys the content to be delivered and the target intermediate tensor by physical erasure.

8. The system according to claim 1, characterized in that, The evidence storage anchoring module is configured to send the first evidence storage transaction to the blockchain for evidence storage, including: sending the first evidence storage transaction to N blockchains for evidence storage, so that each blockchain returns an evidence storage record based on the first evidence storage transaction; The system also includes a monitoring module, which is configured to obtain the evidence storage records returned by each of the N blockchains and save the evidence storage records returned by each of the N blockchains in a preset on-chain record table.

9. The system according to claim 8, characterized in that, The monitoring module is also configured to: The on-chain record table is periodically traversed, and batch queries are performed on each blockchain to verify whether each evidence record in the on-chain record table is in an accessible and consistent state on the corresponding blockchain. In response to the fact that the evidence storage record of the abnormal blockchain is not in an accessible and consistent state, complete data corresponding to the evidence storage record is obtained from the normal blockchain. Based on the complete data corresponding to the evidence storage record, an evidence storage completion request is sent to the abnormal blockchain so that the abnormal blockchain can complete the evidence storage record based on the complete data.

Images