A method for generating, verifying and replaying a locally verifiable AI transaction receipt chain

Abstract

The application discloses a kind of local verifiable AI transaction receipt chain generation, verification and playback method, belongs to artificial intelligence application technical field, the method collects key event data in the execution process of AI transaction and encapsulates as initial receipt block, key event data;Through the chained association of the hash value of prequel and the hash value of current block, chain receipt block is generated and is additionally stored to local receipt chain;In response to playback request, extract relevant receipt block according to transaction unique identification, reconstruct time sequence link according to storage order and transaction semantic phase identification and generate readable playback report.The application realizes the binding of receipt chain and AI transaction semantic phase by transaction semantic phase identification, supports transaction-level time sequence reconstruction and readable playback, with the characteristics of local verifiable, tamper-resistant and traceable.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence application technology, and in particular to a method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain. Background Technology

[0002] With the rapid development of artificial intelligence technology, AI systems have evolved from a simple "information question and answer" stage to a "task execution" stage. AI systems based on large language models and multi-agent architectures can understand users' natural language commands, autonomously decompose task steps, and invoke various tools and interfaces to execute specific operations. In this process, the AI ​​system goes through multiple semantic stages, including candidate generation, user confirmation, gating and adjudication, side effect execution, and state changes, ultimately completing the full transaction corresponding to the user's command. Because AI transactions involve side effects with real impact, such as memory writes, external message sending, and system operation calls, auditing and tracing the entire process of AI transactions has become a core requirement for AI security governance—that is, it is necessary to be able to verify whether every action of the AI ​​system is executed according to the established process, whether it has been confirmed by the user, whether the execution result meets expectations, and to provide verifiable evidence in case of disputes.

[0003] Currently, the industry mainly offers the following technical solutions for auditing and tracing the execution process of AI transactions: The first type is a blockchain-based log storage solution. This solution anchors key data from AI transactions to the blockchain network in the form of hash digests, leveraging the blockchain's immutability to ensure log integrity. However, this type of solution relies on an external blockchain network and suffers from high deployment costs, risks associated with storing private data on the blockchain, and strong network dependence.

[0004] The second type is the general hash chain auditing solution. This solution organizes AI behavioral events into a sequence of hash links and uses digital signatures for source authentication to form a verifiable audit chain, such as open-source solutions like Agent Receipts Protocol. While this type of solution can achieve basic behavioral verifiability, it has the following drawbacks: the receipt data is only a general "behavioral record," lacking a structured binding with specific semantic stages of AI transactions (candidate generation, sovereignty confirmation, gating decision, side effect execution, state change). Auditors can only see a string of encrypted hash links and cannot intuitively understand the semantic role and business meaning of each receipt in the AI ​​transaction processing flow; it lacks the ability to reconstruct and replay the temporal chain at the transaction granularity, only supporting viewing in chain order, and cannot fully trace the complete process of a single transaction from its inception to its end; it does not support causal tracing across transactions and cannot associate causal relationships between preceding and subsequent transactions. Furthermore, the receipt chain lacks an effective storage management mechanism. With the continuous growth of AI transactions, local storage space faces the problem of unlimited expansion, and it also lacks the ability to self-check and recover when partial damage to receipt data occurs. Summary of the Invention

[0005] The purpose of this invention is to provide a method for generating, verifying, and replaying locally verifiable AI transaction receipt chains. This addresses the technical problem in existing AI transaction auditing and tracing schemes where receipt data lacks binding to the semantic stages of AI transactions and the ability to reconstruct the temporal sequence and provide readable replay at the transaction granularity, resulting in the inability to intuitively and completely trace the entire chain of a single transaction. Simultaneously, it also solves the significant shortcomings of existing solutions in cross-transaction causal tracing, long-term storage space growth control, and data corruption self-check and recovery.

[0006] Specifically, the present invention provides a method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain, comprising the following steps: S1. Collect key event data during the execution of AI transactions, encapsulate the key event data in a structured manner, and generate an initial receipt block; the key event data includes at least one or more of the following: candidate generation events, sovereignty confirmation events, gating decision events, side effect execution events, and state change events; the initial receipt block includes at least a unique transaction identifier, event type, transaction semantic stage identifier, timestamp, action summary, and event data hash value; S2. Read the hash value of the previous receipt block from the local receipt chain storage area as the preceding hash value. If the local receipt chain is empty, set the preceding hash value to a zero hash. Perform cryptographic hash calculation on the content of the initial receipt block to obtain the hash value of the current block. Write the preceding hash value and the current block hash value into the initial receipt block to generate a chained receipt block. S3. The chained receipt block is appended and stored to the local receipt chain to form a transaction receipt chain with a hash chain structure; S4. In response to the replay request, extract all receipt blocks associated with the unique identifier of the target transaction, and reconstruct the complete execution timeline of the transaction from candidate generation to state change according to the storage order of each receipt block in the local receipt chain and the transaction semantic stage identifier, and generate a readable replay report containing the event timeline, key decision nodes and state change records.

[0007] A system for generating, verifying, and replaying locally verifiable AI transaction receipt chains, comprising: The key event acquisition and encapsulation module is used to collect key event data during the execution of AI transactions, encapsulate the key event data in a structured manner, and generate an initial receipt block. The key event data includes at least one or more of the following: candidate generation events, sovereignty confirmation events, gating decision events, side effect execution events, and state change events. The initial receipt block includes at least a unique transaction identifier, event type, transaction semantic stage identifier, timestamp, action summary, and event data hash value. The hash chain receipt block generation module is used to read the hash value of the previous receipt block from the local receipt chain storage area as the preceding hash value. If the local receipt chain is empty, the preceding hash value is set to a zero-value hash. The module performs cryptographic hash calculation on the content of the initial receipt block to obtain the hash value of the current block. The module writes the preceding hash value and the current block hash value into the initial receipt block to generate a chain receipt block. The receipt chain append storage module is used to append the chained receipt blocks to the local receipt chain to form a transaction receipt chain with a hash chain structure. The transaction replay module is used to respond to a replay request, extract all receipt blocks associated with the unique identifier of the target transaction, reconstruct the complete execution timeline of the transaction from candidate generation to state change according to the storage order of each receipt block in the local receipt chain and the transaction semantic stage identifier, and generate a readable replay report containing an event timeline, key decision nodes and state change records.

[0008] The beneficial effects provided by this invention are: First, a deep binding between the receipt chain and the semantic stages of AI transactions is achieved through a transaction semantic stage identifier (PhaseID). Each receipt block establishes a one-to-one correspondence with a specific semantic stage of the AI ​​transaction (candidate generation, sovereignty confirmation, gating decision, side effect execution, state change) through the PhaseID field. This makes the receipt chain not only a cryptographic audit trail chain but also a temporal record chain of the semantic stages of AI transactions. This design allows auditors to not only verify the integrity of data when tracing transactions but also clearly understand the semantic role of each receipt block in the AI ​​transaction processing flow.

[0009] Secondly, a hash chain structure is used to achieve local verifiability and tamper-proof protection of receipt data. Each receipt block is cryptographically bound to all historical blocks through its preceding hash value. Any modification to historical receipt data will cause a change in the hash value of the modified block and all subsequent blocks, thus making it detectable. Unlike solutions that rely on blockchain networks or trusted third-party institutions, this invention achieves the generation, storage, and verification of the receipt chain entirely locally, without relying on any external networks or trusted third-party institutions, offering advantages such as low deployment costs and strong privacy.

[0010] Third, a complete readable replay is achieved through transaction-level time-series reconstruction. The method extracts all associated receipt blocks by unique transaction identifiers, sorts them according to both storage order and transaction semantic stage identifiers, and reconstructs the complete execution time-series of the transaction from candidate generation to state change, generating a readable replay report containing an event timeline, key decision nodes, and state change records. This functionality allows users to intuitively view the complete lifecycle of AI transactions, providing strong support for auditing, tracing, and dispute resolution.

[0011] Fourth, the method visualizes the relationships between transactions through cross-transaction causal tracing. It supports recursive tracing across transactions using the ParentTxID and ParentBlockHash fields, enabling it to trace back from the current transaction to its predecessor transactions, forming a complete causal tracing chain. The replay report then displays key events from the preceding transactions. This design allows auditors to understand the triggering and dependency relationships between transactions.

[0012] Fifth, the fault tolerance of the receipt chain is achieved through a self-checking and recovery mechanism. When verification fails, the method can automatically locate the recovery baseline, find the backup copy and perform replacement recovery, or make the anomaly auditable (generating an anomaly report and appending it to the end of the receipt chain). This mechanism ensures that the receipt chain maintains audit continuity even when it suffers partial damage.

[0013] Sixth, a verifiable compressed archiving mechanism addresses the long-term growth issue of local storage. This method ensures the integrity of archived data can be independently verified in the future by aggregating hash values, while maintaining the cryptographic continuity of the main receipt chain through archived marker blocks. This design effectively controls the growth of local storage space while guaranteeing data integrity.

[0014] Seventh, fast location of receipts is achieved through multi-level query indexes. The method supports O(1) time complexity hash lookup through a first-level index table with a unique transaction identifier as the primary key, which significantly improves the response speed of replay requests and enables the method to maintain good performance in large-scale receipt data scenarios. Attached Figure Description

[0015] Figure 1 This is a simplified flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0017] Before formally describing the present invention, a general description of the solution of the present invention will be given first to facilitate understanding.

[0018] Example 1 Please refer to Figure 1 The present invention provides a method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain, comprising the following steps: S1. Collect key event data during the execution of AI transactions, encapsulate the key event data in a structured manner, and generate an initial receipt block; the key event data includes at least one or more of the following: candidate generation events, sovereignty confirmation events, gating decision events, side effect execution events, and state change events; the initial receipt block includes at least a unique transaction identifier, event type, transaction semantic stage identifier, timestamp, action summary, and event data hash value; As one embodiment, in step S1 of this invention, the "AI transaction" refers to the complete process that an AI system undergoes from receiving a user instruction or autonomously initiating a task to completing that task. During the execution of an AI transaction, the system generates a series of key events with different semantic meanings, which together constitute the complete lifecycle of the AI ​​transaction. This invention divides the lifecycle of an AI transaction into five semantic stages, each stage corresponding to a type of key event: (1) Candidate Generation Event: This refers to the moment and content at which the AI ​​system generates candidate actions based on user instructions or autonomous reasoning. For example, based on the user's natural language instruction "Send me an email to client Mr. Zhang explaining the project delay," the AI ​​system generates a candidate action containing information such as the email draft, recipient, and sending time. This candidate action is encapsulated as a candidate object and stored in the candidate temporary storage area. The candidate generation event records the specific content of this moment and the candidate action.

[0019] (2) Sovereign Confirmation Event: This refers to the moment and method by which a user confirms or rejects a candidate action. For example, after receiving a confirmation request from the AI ​​system, a user makes a decision on a candidate action by clicking the "Confirm" button, entering a dynamic verification code, or submitting approval comments. The Sovereign Confirmation Event records the moment the user makes a decision, the decision result (pass or reject), and the confirmation method (one-click confirmation, secondary confirmation, or manual review).

[0020] (3) Gating Decision Event: This refers to the moment and result of the unified governance core's multi-dimensional gating decision on a candidate. Based on the combination of values ​​for each flag in the candidate boundary flag matrix, the unified governance core reviews the candidate from three dimensions: risk level, permission flag, and sovereignty confirmation, ultimately making a decision to allow or block access. The gating decision event records the moment of the decision, the review results for each dimension, and the final decision result.

[0021] (4) Side Effect Execution Event: This refers to the moment and result of the side effect operation after the candidate object is converted into a formal action. The side effect operation includes, but is not limited to: writing information to the long-term memory (memory write), sending a message to the outside (external send), and calling the executor to perform business operations (executor call). The side effect execution event records the type, execution time, and execution result (success or failure) of the side effect operation.

[0022] (5) State Change Event: This refers to the moment when the transaction state changes and the state values ​​before and after the change. The state of an AI transaction can include "candidate state", "pending confirmation state", "in execution state", "completed state", "blocked state", etc. The state change event records the moment when the state changes, the state value before the change, and the state value after the change.

[0023] The "structured encapsulation" refers to formatting the collected key event data according to a preset data structure template, converting the unstructured raw data into a structured receipt block. Specifically, the system first standardizes the key event data, extracting fields such as transaction unique identifier (TxID), event type (EventType), transaction semantic phase identifier (PhaseID), timestamp (Timestamp), event source (SourceID), action summary (ActionSummary), event payload (Payload), and event payload hash (PayloadHash). Then, these fields are assembled according to a preset receipt data format to generate the initial receipt block (ReceiptBlock0).

[0024] The "Transaction Unique Identifier (TxID)" is a globally unique identifier assigned by the system to each AI transaction, used to uniquely identify the transaction throughout its entire lifecycle. The TxID can be a Universally Unique Identifier (UUID) or a unique string generated based on a timestamp and a random number.

[0025] The “EventType” is used to identify the type of critical event, and its value corresponds to the five critical event types mentioned above.

[0026] The "Transaction Semantic Phase Identifier (PhaseID)" is one of the core data fields of this invention. Its value is any value from the preset phase set {CANDIDATE, CONFIRMATION, GATING, EXECUTION, STATECHANGE}, corresponding to the candidate generation phase, sovereignty confirmation phase, gated decision phase, side effect execution phase, and state change phase, respectively. The PhaseID field binds each receipt block to a specific semantic phase of the AI ​​transaction, thus making the receipt chain not only a cryptographic audit trail chain but also a temporal record chain of the AI ​​transaction's semantic phases.

[0027] The "timestamp" records the precise moment when a key event occurs, with an accuracy down to the millisecond level, and is used for subsequent time sequence reconstruction and time order verification.

[0028] The “Event Source ID” is used to identify the system component or agent that generated the key event, such as “GPT-4 model”, “task planning agent”, “scenario process engine”, “user terminal”, etc.

[0029] The "ActionSummary" is a brief description of the key event content, such as "Sent an email to Mr. Zhang with the content of the project delay explanation".

[0030] The “event payload” is the complete data content of a critical event, such as the complete text of an email draft or a complete report of a gated decision.

[0031] The "event payload hash" is a fixed-length hash digest obtained by performing a cryptographic hash calculation on the event payload, which is used to provide a basis for integrity verification when storing complete data off-chain.

[0032] For example, suppose the owner of a renovation company says to the AI ​​system via voice input: "Send me an email to my client, Mr. Zhang, explaining that the water and electricity acceptance needs to be postponed for three days because the materials have not arrived." After the AI ​​system performs intent recognition and structured parsing on the voice input, it generates a candidate action of "send email". At this point, the system collects the candidate generation event and generates an initial receipt block, ReceiptBlock0, with the following content: TxID = "TXN_20260115_001", EventType = "CANDIDATE_GENERATION", PhaseID = "CANDIDATE", Timestamp = "2026-01-15 09:30:15.234", SourceID = "LLM_GPT4_202511", ActionSummary = "Generate a candidate action to send an email to Mr. Zhang", Payload = "{recipient: 'Mr. Zhang', subject: 'Project Delay Notice', body: 'Dear Mr. Wang, Hello! Regarding the water and electricity acceptance of the mansion project, due to the materials not arriving, a three-day delay is required...'}", PayloadHash = SHA-256(Payload). This initial receipt block is stored in memory, awaiting subsequent hash chain processing.

[0033] S2. Read the hash value of the previous receipt block from the local receipt chain storage area as the preceding hash value. If the local receipt chain is empty, set the preceding hash value to a zero hash. Perform cryptographic hash calculation on the content of the initial receipt block to obtain the hash value of the current block. Write the preceding hash value and the current block hash value into the initial receipt block to generate a chained receipt block. As one embodiment, in step S2 of the present invention, the system adds the initial receipt block generated in step S1 to the hash chain structure. The "local receipt chain storage area" is a storage area in the local storage medium (such as a hard disk or solid-state drive) specifically used to store the receipt chain. The receipt chain is stored in an append-only manner, with each newly generated chained receipt block appended to the end of the existing receipt chain.

[0034] First, the system reads the hash value of the previous receipt block from the local receipt chain storage area as the pre-order hash value (PrevHash). If the current local receipt chain is empty (i.e., the current receipt is the first receipt), then the pre-order hash value is set to a zero-value hash (i.e., a hash value consisting entirely of 0s, such as "0 ...

[0035] Secondly, the system performs cryptographic hash calculations on the content of the initial receipt block to obtain the current block hash value (CurrentHash). The specific process of hash calculation is as follows: all content in the initial receipt block except for the current block hash value field is serialized according to deterministic serialization rules, converting the structured receipt data into a continuous byte sequence; then, the SHA-256 hash algorithm is applied to this byte sequence to obtain a fixed-length (256 bits, i.e., 32 bytes) hash digest as the current block hash value. SHA-256 is a cryptographic hash algorithm designed by the National Security Agency and released by the National Institute of Standards and Technology (NIST). It can convert input data of arbitrary length into fixed-length output and has collision resistance (i.e., it is difficult to find two different inputs that produce the same output) and one-wayness (i.e., it is impossible to deduce the original input from the hash value). These characteristics of the SHA-256 algorithm ensure that the hash value of the receipt block uniquely represents the content of the block, and any modification to the block content will cause unpredictable changes in the hash value.

[0036] Finally, the system writes the previous hash value and the current block hash value into the corresponding fields of the initial receipt block, generating a linked receipt block. The current block hash value of the linked receipt block satisfies the following relationship: CurrentHash = SHA-256(serialized (all content in ReceiptBlock0 except for the CurrentHash field)) Furthermore, PrevHash is either the CurrentHash or the zero-value hash of the previous receipt block.

[0037] The term "serialization" refers to the process of converting a data structure or object state into a byte sequence that can be stored or transmitted. In this invention, serialization refers to sequentially concatenating the various fields (such as TxID, EventType, PhaseID, Timestamp, SourceID, ActionSummary, PayloadHash, etc.) in the receipt block into a continuous byte array according to a defined field order and encoding rules. The serialization rules are deterministic—the same input data, when serialized at different times and on different devices, will always produce the exact same byte sequence, thus ensuring the reproducibility of the hash calculation results.

[0038] For example, continuing from step S1, the current local receipt chain is empty, and the system sets the preceding hash value to a zero-value hash. The system serializes all content in ReceiptBlock0 except for the CurrentHash field (i.e., fields such as TxID, EventType, PhaseID, Timestamp, SourceID, ActionSummary, Payload, PayloadHash, etc.) according to deterministic serialization rules to obtain a byte sequence. Then, it performs SHA-256 hash calculation on this byte sequence to obtain CurrentHash = "a7f3e9d1c5b8a4e2f6d9c3b7e1a5f8d2c4b6e9a1f3d7c5b8e2a4f6d9c1b3e5f7". The system writes PrevHash = zero-value hash and CurrentHash = "a7f3e9..." into ReceiptBlock0, generating a chained receipt block LinkedReceiptBlock1. The chained receipt block now contains the previous hash value and the current block hash value, and can be appended to the local receipt chain.

[0039] S3. The chained receipt block is appended and stored to the local receipt chain to form a transaction receipt chain with a hash chain structure; As one embodiment, in step S3 of the present invention, the system writes the chained receipt block generated in step S2 to the local receipt chain storage area in an append-only manner. The "append-only manner" means that new data is always added to the end of existing data without modifying or deleting existing data. This writing method ensures the append-only characteristic of the receipt chain—once a receipt is written, it cannot be modified or deleted.

[0040] The system simultaneously updates the metadata of the local receipt chain, which includes at least the current chain length (i.e., the total number of receipt blocks), the hash value of the last block (i.e., the tail hash value), and the last update timestamp. This metadata update ensures that the system can quickly obtain the current state of the receipt chain without traversing the entire chain.

[0041] After processing in steps S2 and S3, each newly added receipt block is cryptographically bound to all historical blocks through its preceding hash value—the hash value of each block depends on the hash value of its predecessor, which in turn depends on the hash value of the block before that, and so on. This chain structure ensures that any modification to historical receipt data will cause a change in the hash value of the modified block and all subsequent blocks, making it detectable. The local receipt chain storage area can be implemented using a local file system, an embedded database (such as SQLite), or a key-value store (such as LevelDB). All receipt data is stored locally and not uploaded to the cloud, ensuring the privacy and sovereignty of user data.

[0042] For example, following the example in step S2, the system appends LinkedReceiptBlock1 to the receipt file in the local receipt chain storage area. At this time, the length of the local receipt chain becomes 1, the hash value of the last block is "a7f3e9...", and the last update timestamp is "2026-01-15 09:30:15.234". Subsequently, when the AI ​​transaction enters the sovereign confirmation stage, the system generates a second receipt block, LinkedReceiptBlock2, with a preceding hash value of "a7f3e9..." and a current block hash value of "b8c4d2...". After appending, the length of the receipt chain becomes 2. In this way, each newly appended block is connected to the previous blockchain through the preceding hash value, forming a complete hash chain structure.

[0043] S4. In response to the replay request, extract all receipt blocks associated with the unique identifier of the target transaction, and reconstruct the complete execution timeline of the transaction from candidate generation to state change according to the storage order of each receipt block in the local receipt chain and the transaction semantic stage identifier, and generate a readable replay report containing the event timeline, key decision nodes and state change records.

[0044] As one embodiment, in step S4 of the present invention, the system provides a replay function, allowing users or auditors to trace the complete execution process by transaction. The "replay request" is a query request initiated by the user or auditor through the system interface, and the request contains at least a unique identifier (TargetTxID) of the target transaction.

[0045] After receiving a replay request, the system queries using TargetTxID as the key to extract all receipt blocks associated with the unique identifier of the transaction. The query can be performed in two ways: if the system has established a first-level index table (see the embodiment of claim 8), the system will prioritize the use of the index table for fast location with O(1) time complexity; if no index has been established or no corresponding entry exists in the index, the system will traverse all receipt blocks in the local receipt chain to search.

[0046] After finding all associated receipt blocks, the system sorts the receipt blocks according to two dimensions: the first dimension is the storage order of each receipt block in the local receipt chain (i.e., the append order of the blocks), and the second dimension is the transaction semantic phase identifier (PhaseID). Through this dual sorting, the system can accurately reconstruct the complete time-series link of the transaction from candidate generation to state change.

[0047] Subsequently, the system converts the structured data of each receipt block in the time-series link into human-readable event descriptions. The conversion process includes: converting the enumerated value of PhaseID (such as "CANDIDATE") into the corresponding Chinese phase name (such as "candidate generation phase"), converting the timestamp into a readable date and time format, and organizing information such as the event source and event result into a natural language description.

[0048] Finally, the system arranges all the converted event descriptions chronologically, generating a readable replay report containing an event timeline, key decision nodes, and state change records, and outputs it to the user terminal (such as a web interface, mobile app, or PDF file). The replay report allows users to intuitively view the complete process of an AI transaction from its inception to completion, including what happened at each step, when it happened, who (or which system component) performed it, and what the result was.

[0049] Continuing the previous example, one day a user needs to audit the complete process of the transaction "TXN_20260115_001", so they initiate a replay request through the system interface. The system uses "TXN_20260115_001" as the key and extracts all five receipt blocks of the transaction from the local receipt chain (corresponding to the five stages: candidate generation, sovereignty confirmation, gating decision, side effect execution, and state change). The system sorts these five blocks according to their storage order and PhaseID, then converts the structured data of each block into a human-readable event description, ultimately generating a replay report.

[0050] Example 2 It should be noted that the transaction semantic stage identifier is any value in the preset stage set {CANDIDATE, CONFIRMATION, GATING, EXECUTION, STTECHANGE}; where CANDIDATE corresponds to the candidate generation stage, CONFIRMATION corresponds to the sovereignty confirmation stage, GATING corresponds to the gating adjudication stage, EXECUTION corresponds to the side effect execution stage, and STTECHANGE corresponds to the state change stage.

[0051] As one embodiment, in step S1 of this invention, the transaction semantic phase identifier (PhaseID) is a key field binding the receipt block to the AI ​​transaction semantic phase. The value of this field is strictly limited to a preset set of five values, each corresponding to a specific semantic phase in the AI ​​transaction lifecycle, as shown in Table 1 below: Table 1. Meaning of Semantic Phase Identifiers for Transactions

[0052] By embedding the PhaseID field in the receipt blocks, each receipt block is bound to a specific semantic stage of the AI ​​transaction. This binding relationship makes the receipt chain not only a cryptographic audit trail chain—each block is associated with preceding and following blocks through hash values ​​to form a tamper-proof chain structure—but also a temporal record chain of the semantic stages of the AI ​​transaction—each block is identified by the PhaseID field as its semantic stage in the AI ​​transaction lifecycle. This dual attribute allows auditors to not only verify data integrity when tracing transactions, but also clearly understand the semantic role of each receipt block in the AI ​​transaction processing flow.

[0053] For example, continuing from steps S1 to S4 in Embodiment 1, when generating the five receipt blocks for the "send email" transaction, the system sets a corresponding PhaseID value for each block: PhaseID for the candidate generation event = "CANDIDATE", PhaseID for the sovereignty confirmation event = "CONFIRMATION", PhaseID for the gated decision event = "GATING", PhaseID for the side effect execution event = "EXECUTION", and PhaseID for the state change event = "STATECHANGE". In the playback report, the system categorizes and displays the event descriptions according to the PhaseID values, allowing users to clearly see which semantic stages the transaction went through and the order of those stages.

[0054] It should be noted that in step S1, key event data during the AI ​​transaction execution process is collected, and the key event data is structured and encapsulated to generate an initial receipt block, specifically including: S11. Monitor the event flow during the execution of AI transactions and collect key event data; the candidate generation event records the time and content when the AI ​​system generates candidate actions; the sovereignty confirmation event records the time and method when the user confirms or rejects a candidate action; the gating adjudication event records the time and result when the unified governance core performs multi-dimensional gating adjudication on the candidate object; the side effect execution event records the time and result when the side effect operation is executed after the candidate object is converted into a formal action; the state change event records the time when the transaction state changes and the state values ​​before and after the change. S12. Standardize the key event data to generate structured event records; the structured event records include at least: transaction unique identifier TxID, event type EventType, transaction semantic phase identifier PhaseID, timestamp Timestamp, event source SourceID, action summary ActionSummary, event payload Payload, and event payload hash value PayloadHash; S13. The structured event record is encapsulated according to a preset receipt data format to generate an initial receipt block ReceiptBlock0. The initial receipt block contains at least the transaction unique identifier TxID, the event type EventType, the transaction semantic phase identifier PhaseID, the timestamp Timestamp, the event source SourceID, the action summary ActionSummary, and the event data hash value PayloadHash.

[0055] As one embodiment, steps S11 to S13 of the present invention describe in detail the specific implementation of "collecting key event data" and "structured encapsulation" in step S1.

[0056] In step S11, the system continuously monitors the event flow during the AI ​​transaction execution process through an event listening mechanism. This "event listening mechanism" can be implemented using the observer pattern or a publish-subscribe pattern—the system registers event listeners at various key execution nodes (such as the candidate generation module, sovereignty confirmation module, gating adjudication module, side effect execution module, and state management module). When these modules perform key operations, events are automatically triggered and event data is sent to the listeners. The specific meanings of the five key events are as follows: Candidate Generation Event: Triggered when an AI system (such as a large language model, task planning agent, or scene flow engine) generates a new candidate action. This event records the time of the candidate action's generation, the complete content of the candidate action (including action type, target object, execution parameters, etc.), and the identifier of the AI ​​system or agent that generated the candidate action.

[0057] Sovereignty Confirmation Event: Triggered when a user makes a decision to confirm or reject a candidate action. This event records the time the user makes the decision, the decision result (pass or reject), and the confirmation method. There are three confirmation methods: one-click confirmation (G1, the user clicks the confirmation button once), two-step confirmation (G2, the user needs to enter a dynamic verification code or perform biometric verification), and manual review (G3, the user needs to enter detailed approval comments and the approver's identity information).

[0058] Gating Decision Event: Triggered when the Unified Governance Core completes a multi-dimensional gating decision on a candidate. This event records the moment of the decision, the review results of each dimension (risk level review, permission mark review, sovereignty confirmation review), and the final decision result (allow or block).

[0059] Side effect execution event: Triggered when a candidate object is converted into a formal action and a side effect operation is executed. These side effect operations include memory write operations (writing information to long-term memory), external send operations (sending emails, WeChat messages, SMS messages, etc.), and executor call operations (calling operating system commands, business process engines, third-party tool APIs, etc.). This event records the type, execution time, and execution result of the side effect operation.

[0060] State Change Event: Triggered when the state of an AI transaction changes. AI transaction states include, but are not limited to: Candidate, PendingConfirmation, Executing, Completed, and Blocked. This event records the time of the state change, the state value before the change, and the state value after the change.

[0061] In step S12, the system performs standardization processing on the collected key event data. "Standardization processing" refers to converting event data from different sources and in different formats into a standardized structured format. Specifically, the system extracts the following eight fields from the original event data: Transaction Unique Identifier (TxID), Event Type (EventType), Transaction Semantic Phase Identifier (PhaseID), Timestamp, Event Source (SourceID), Action Summary (ActionSummary), Event Payload (Payload), and the hash value of the event payload (PayloadHash). The PayloadHash is a hash digest obtained by performing SHA-256 hash calculation on the content of the Payload field, used to provide integrity verification when storing complete data off-chain.

[0062] In step S13, the system encapsulates the structured event record generated in step S12 according to a preset receipt data format. The "preset receipt data format" is a standardized data serialization format, which can use JSON (JavaScript Object Notation), Protocol Buffers, or a custom binary format. The encapsulated data is the initial receipt block ReceiptBlock0, which contains at least seven fields: TxID, EventType, PhaseID, Timestamp, SourceID, ActionSummary, and PayloadHash.

[0063] Continuing with the previous example, in the candidate generation phase of the "send email" transaction, the system's event listener captures the candidate generation event. In step S11, the system records the time of this event as "2026-01-15 09:30:15.234", and the candidate content is the complete text of the email draft. In step S12, the system extracts the following: TxID = "TXN_20260115_001", EventType = "CANDIDATE_GENERATION", PhaseID = "CANDIDATE", Timestamp = "2026-01-15 09:30:15.234", SourceID = "LLM_GPT4_202511", ActionSummary = "Generate candidate action to send email to Mr. Zhang", Payload = the complete JSON data of the email draft, and PayloadHash = SHA-256(Payload). In step S13, the system encapsulates these eight fields into ReceiptBlock0 in JSON format.

[0064] It should be noted that in step S2, the cryptographic hash calculation is performed on the content of the initial receipt block to obtain the hash value of the current block, specifically including: S21. Serialize all contents of the initial receipt block except for the current block hash value field according to the deterministic serialization rules to obtain a byte sequence; S22. Perform cryptographic hash calculation on the byte sequence using the SHA-256 hash algorithm to obtain a fixed-length hash digest as the current block hash value CurrentHash; S23. Write the preceding hash value PrevHash and the current block hash value CurrentHash into the corresponding fields of the initial receipt block to form a chained receipt block; the current block hash value of the chained receipt block satisfies: CurrentHash = SHA-256 (serialized (all content in ReceiptBlock0 except for the CurrentHash field)), and PrevHash is the CurrentHash of the previous receipt block or a zero-value hash.

[0065] As one embodiment, steps S21 to S23 of the present invention describe in detail the specific implementation of the hash calculation in step S2.

[0066] In step S21, the system serializes all content in the initial receipt block except for the current block hash value field. The serialized object does not include the current block hash value field itself, because the current block hash value is generated only after the hash calculation is completed and does not exist at the time of calculation. The "deterministic serialization rule" refers to a set of fixed and reproducible serialization rules that ensure that the same input data will always produce the exact same byte sequence when serialized at different times and on different devices. The deterministic serialization rule includes at least the following elements: (1) the concatenation order of each field is fixed; (2) the encoding method of each field is fixed (e.g., strings use UTF-8 encoding, and integers use big-endian or little-endian byte order); (3) the separation method between each field is fixed. In a preferred embodiment of the present invention, the serialization rule concatenates the byte representation of each field in the order of TxID, EventType, PhaseID, Timestamp, SourceID, ActionSummary, Payload, and PayloadHash, without adding any additional separators between the fields.

[0067] In step S22, the system performs cryptographic hash calculation on the byte sequence obtained in step S21 using the SHA-256 hash algorithm. The SHA-256 algorithm takes a byte sequence of arbitrary length as input, performs a series of bitwise and logical operations (including message padding, block processing, 64 rounds of iterative compression, etc.), and outputs a hash digest of a fixed length of 256 bits (32 bytes). The SHA-256 algorithm has the following important characteristics: (1) determinism - the same input always produces the same output; (2) collision resistance - it is difficult to find two different inputs that produce the same output; (3) one-wayness - it is impossible to deduce the original input from the hash value; (4) avalanche effect - any small change in the input will cause a significant change in the output. These characteristics ensure that the current block hash value can uniquely represent the content of the initial receipt block, and any modification to the block content will cause unpredictable changes in the hash value.

[0068] In step S23, the system writes the previous hash value PrevHash and the current block hash value CurrentHash into the corresponding fields of the initial receipt block. The PrevHash field stores the CurrentHash of the previous receipt block; if the current receipt chain is empty, it stores a zero-value hash. The CurrentHash field stores the hash digest calculated in step S22. After writing, the initial receipt block is transformed into a chained receipt block. The current block hash value of the chained receipt block satisfies the following mathematical relationship: CurrentHash = SHA-256(serialized (all content in ReceiptBlock0 except for the CurrentHash field)) Furthermore, PrevHash is either the CurrentHash or the zero-value hash of the previous receipt block.

[0069] This mathematical relationship ensures that the hash value of each block depends on the entire content of that block (except for the hash value field itself), while the existence of the PrevHash field makes the hash value of each block indirectly dependent on the content of all preceding blocks. Therefore, any modification to the historical receipt data will cause a change in the hash value of the modified block, which in turn will cause a change in the hash values ​​of all subsequent blocks, thus being detected by the verification process.

[0070] As one embodiment, continuing the previous example, in step S21, the system serializes all content in ReceiptBlock0 except for the CurrentHash field (i.e., the eight fields TxID, EventType, PhaseID, Timestamp, SourceID, ActionSummary, Payload, and PayloadHash) according to deterministic serialization rules, obtaining a byte sequence of length 2048 bytes. In step S22, the system performs SHA-256 hash calculation on the 2048-byte sequence to obtain a 32-byte hash digest. "a7f3e9d1c5b8a4e2f6d9c3b7e1a5f8d2c4b6e9a1f3d7c5b8e2a4f6d9c1b3e5f7" As CurrentHash. In step S23, the system writes PrevHash (zero-value hash) and CurrentHash into ReceiptBlock0 to generate a chained receipt block. At this time, the CurrentHash of the chained receipt block satisfies the formula: CurrentHash = SHA-256 (serialization of all content in ReceiptBlock0 except for the CurrentHash field)).

[0071] It should be noted that in step S2, the AI ​​system or the user's private key is also used to digitally sign the current block hash value, generating a digital signature value, and the digital signature value is written into the digital signature field of the chained receipt block; during subsequent verification, the public key corresponding to the private key is used to verify the digital signature value to confirm that the receipt block was indeed created by the claimed generator; the digital signature algorithm is the RSA algorithm or the ECDSA algorithm, and the private key is pre-stored in a local trusted execution environment or a secure key store.

[0072] As one embodiment, in step S2 of the present invention, in addition to generating chained receipt blocks, a digital signature mechanism is added to provide the source authentication capability of the receipt blocks.

[0073] The "digital signature" is an authentication technology based on asymmetric cryptography. The system pre-generates a pair of keys for each AI system or user: a private key and a public key. The private key is kept secret by the generator and is not disclosed to the outside world; the public key can be publicly distributed. When generating a chain of receipt blocks, the system uses the private key to perform signature calculation on the hash value of the current block to generate a digital signature value. The digital signature has the following characteristics: (1) authenticity - only the generator holding the private key can generate a valid signature; (2) integrity - the signature is bound to the message content, and any modification to the message will cause the signature verification to fail; (3) non-repudiation - the generator cannot deny the message it signed.

[0074] In a preferred embodiment of the present invention, the digital signature algorithm may employ either the RSA algorithm or ECDSA (Elliptic Curve Digital Signature Algorithm). The RSA algorithm is based on the mathematical problem of factoring large integers, requiring a key length of 2048 bits or more; the ECDSA algorithm is based on the elliptic curve discrete logarithm problem, offering a shorter key length and faster computation speed for the same security level. The private key is pre-stored in a local trusted execution environment (such as an Intel SGX enclave) or a secure keystore (such as a key management service provided by the operating system) to ensure that the private key is not accessed or disclosed without authorization.

[0075] In subsequent verification, the verifier uses the public key corresponding to the private key to verify the digital signature value. The verification process includes: (1) using the public key to decrypt or verify the signature value to obtain the recovered hash value; (2) comparing the recovered hash value with the hash value of the current block stored in the receipt block; (3) if the two are consistent, it is confirmed that the receipt block was indeed created by the claimed generator and that the content has not been tampered with.

[0076] As one embodiment, after generating the chained receipt block in step S2, the system uses the AI ​​system's private key (stored in the local trusted execution environment) to perform ECDSA signature calculation on the current block hash value "a7f3e9...", generating a digital signature value "sig_abc123...". The system writes this digital signature value into the digital signature field of the chained receipt block. During subsequent verification, the verifier uses the AI ​​system's public key to verify "sig_abc123...", confirming that the receipt block was indeed generated by the AI ​​system and that the current block hash value has not been tampered with.

[0077] It should be noted that after completing step S3, in response to the verification request, step S5 involves retrieving the target receipt block to be verified from the local receipt chain and performing hash chain integrity verification on the target receipt block. Step S5 and S4 are parallel, not sequential. Specifically, step S5 is as follows: S51. Obtain the current block hash value StoredHash, the previous hash value PrevHash, and the block content data stored in the target receipt block; S52. After serializing all content in the block content data except for the current block hash value field, perform SHA-256 hash calculation to obtain the verification hash value VerifiedHash. S53. Compare the VerifiedHash value with the StoredHash value of the current block: if they match, it is determined that the content of the target receipt block is complete and has not been tampered with, and the block is marked as verified; if they do not match, it is determined that the target receipt block has been tampered with, and the block is marked as verified as failed. S54. Obtain the previous receipt block of the target receipt block, and repeat steps S51 to S53 on the previous receipt block until the genesis block of the local receipt chain is traced back to form a complete verification chain from the target block to the genesis block. S55. Each time a chained receipt block is appended to the local receipt chain, a copy of the chained receipt block is stored in the local cache or temporary storage area, and the mapping relationship between the copy and the original block is recorded. S56. When verification fails, starting from the currently failed abnormal block, trace back along the preceding hash value to locate the last complete block that passed full verification as the recovery base point; query whether there is a backup copy of the abnormal block in the local cache or temporary storage area. If a backup copy exists and the hash value recalculated on the backup copy matches the preceding hash value stored in the abnormal block, then replace the abnormal block with the backup copy and re-execute the verification steps S51 to S53; if no valid backup copy exists, generate an auditable abnormal report containing the abnormal block identifier, detection timestamp, and failure reason code, and append the abnormal report as a special receipt block to the end of the local receipt chain.

[0078] As one embodiment, steps S51 to S56 of the present invention describe in detail the integrity verification and self-check recovery mechanism of the receipt chain.

[0079] In steps S51 to S53, the system performs integrity verification on a single target receipt block. The core principle of the verification is: since the current block hash value is obtained by hashing the block content (excluding the hash value field) when the block is generated, the same hash calculation is performed on the block content again during verification, and the calculation result is compared with the stored hash value to determine whether the block content has been tampered with. Specifically, the system obtains the current block hash value StoredHash and the block content data stored in the target receipt block, then serializes all content in the block content data except for the current block hash value field and performs SHA-256 hash calculation to obtain the verification hash value VerifiedHash. If VerifiedHash matches StoredHash, it means that the block content has not been modified since its generation; if they do not match, it means that the block content has been tampered with.

[0080] In step S54, the system expands the verification scope from a single block to the entire receipt chain. Starting with the target receipt block, the system sequentially retrieves its preceding receipt block and repeats the verification process until it traces back to the genesis block (i.e., the first block) of the local receipt chain. This process forms a complete verification chain from the target block to the genesis block. Since the hash value of each block depends on the hash value of its preceding block, verifying the entire chain ensures that no blocks have been tampered with.

[0081] In step S55, each time a storage chain receipt block is appended, the system simultaneously stores a copy of that block in the local cache or temporary storage area and records the mapping relationship between the copy and the original block. This step provides the data foundation for subsequent self-check recovery—when the original block is tampered with, the system can attempt to recover the untampered copy from the cache or temporary storage area.

[0082] In step S56, the system provides a self-checking recovery mechanism. When verification fails (i.e., an abnormal block is found), the system performs the following operations: (1) Starting from the abnormal block, trace back along the preceding hash value to locate the last complete block that passed full verification and use it as the recovery base point; (2) Query whether there is a backup copy of the abnormal block in the local cache or temporary storage area; (3) If there is a backup copy, and the hash value recalculated on the backup copy matches the preceding hash value stored in the abnormal block (i.e., the backup copy is in the correct position in the chain), then replace the abnormal block with the backup copy and re-execute the verification; (4) If there is no valid backup copy, generate an auditable abnormal report containing the abnormal block identifier, detection timestamp, and failure reason code, and append the abnormal report as a special receipt block to the end of the local receipt chain. The special receipt block uses the hash value of the recovery base point as its preceding hash value to ensure that the audit continuity of the receipt chain is maintained after the anomaly occurs.

[0083] For example, suppose a user needs to verify the third receipt block of the transaction "TXN_20260115_001". In step S51, the system obtains the StoredHash = "c9d5e3..." and the block content data stored in the block. In step S52, the system serializes all content data in the block content data except for the CurrentHash field and performs SHA-256 hash calculation to obtain VerifiedHash = "c9d5e3...". In step S53, the system compares and finds that VerifiedHash matches StoredHash, determining that the block verification is successful. In step S54, the system continues to verify the previous block of this block, tracing back to the genesis block. After all verifications are successful, the entire receipt chain is confirmed to be complete and valid. Suppose that during a verification process, the system discovers that the VerifiedHash and StoredHash of a certain block are inconsistent (indicating that the block has been tampered with). In step S56, the system traces backward from the abnormal block, locating the last fully verified block as the recovery base point, and then queries the local cache to see if a backup copy of the abnormal block exists. If it exists and the hash matches, the abnormal block is replaced with the backup copy and re-verified; if it does not exist, an auditable exception report is generated and appended to the end of the receipt chain.

[0084] It should be noted that the method further includes step S6: compressing and archiving the local receipt chain according to a preset period. Step S6, the compression and archiving step, is executed independently of the playback request in step S4 and the verification request in step S5, and specifically includes: S61. Obtain the total storage space occupied by the current local receipt chain. When the total storage space occupied exceeds a preset storage threshold, start the compression process. S62. Mark historical receipt blocks in the local receipt chain whose timestamps are earlier than the current time minus the preset retention period as blocks to be archived. S63. Calculate the aggregate hash value of the block set to be archived, wherein the aggregate hash value is the hash digest obtained by serializing and concatenating all the block contents of the block set to be archived in the storage order and then performing SHA-256 cryptographic hash calculation. S64. Remove the set of blocks to be archived from the main receipt chain storage area and store it in the archive storage area, and retain an archive marker block in the main receipt chain. The archive marker block contains the aggregate hash value, the archive timestamp, and the number of archive blocks. S65. The current block hash value of the archived tag block is used as the new preceding hash value for subsequent newly added receipt blocks to ensure that the compressed main receipt chain still maintains complete cryptographic continuity.

[0085] As one embodiment, steps S61 to S65 of the present invention describe in detail the compression and archiving mechanism of the receipt chain.

[0086] As AI transactions continue to be generated, the number of receipt blocks in the local receipt chain will continue to grow, leading to a continuous increase in storage space consumption. To address this issue, this invention provides a compression and archiving mechanism, which is executed as a background maintenance task independently of replay requests and verification requests.

[0087] In step S61, the system checks the total storage space usage of the local receipt chain at a preset period (e.g., daily or weekly). When the total storage space usage exceeds a preset storage threshold, the compression process is initiated. The default value of the preset storage threshold is 1GB, which is set based on the following considerations: on a typical personal computer or edge device, 1GB of storage space usage will not have a significant impact on system performance, while this threshold is also large enough to accommodate several months or even a year of receipt data, avoiding overly frequent compression operations.

[0088] In step S62, the system filters blocks to be archived based on timestamps. Specifically, the system marks historical receipt blocks in the local receipt chain whose timestamps are earlier than "the current time minus the preset retention period" as blocks to be archived. The default value for the preset retention period is 180 days (approximately 6 months). This value is set based on the following considerations: In most business scenarios, receipt data within 6 months has a high query and audit frequency, while the query frequency of historical data older than 6 months decreases significantly. The 180-day retention period strikes a balance between ensuring fast access to recent data and reducing storage costs.

[0089] In step S63, the system calculates the aggregate hash value of the set of blocks to be archived. The calculation method for the aggregate hash value is as follows: all block contents of the set of blocks to be archived are serialized and concatenated according to their storage order in the receipt chain to obtain a continuous byte sequence. Then, SHA-256 hash calculation is performed on this byte sequence to obtain a fixed-length hash digest as the aggregate hash value. The purpose of the aggregate hash value is that if it is necessary to verify the integrity of the archived data in the future, the aggregate hash value of all block contents in the archive storage area can be recalculated and compared with the aggregate hash value stored in the archived marker block to confirm whether the archived data has been tampered with.

[0090] In step S64, the system performs the actual compression operation: the set of blocks to be archived is removed from the main receipt chain storage area and transferred to the archive storage area (such as a separate archive file or archive database), while retaining an archive marker block in the main receipt chain. The archive marker block is a special receipt block whose content contains at least three fields: aggregate hash value (used for future verification of the integrity of archived data), archive timestamp (recording the time of the archive operation), and number of archived blocks (recording the total number of blocks archived this time).

[0091] In step S65, the system uses the current block hash value of the archived tag block as the new preceding hash value for subsequent newly appended receipt blocks to reference. This operation ensures that the compressed main receipt chain maintains complete cryptographic continuity—the preceding hash value of the new receipt block points to the hash value of the archived tag block, and the hash value of the archived tag block is cryptographically bound to the archived historical data through the aggregate hash value in its content. Therefore, even if historical data has been removed from the main receipt chain, it still remains associated with the main receipt chain through the aggregate hash value, and any tampering with the archived data will result in a mismatch in the aggregate hash value and be detected.

[0092] For example, assuming the system has been running for 200 days, the local receipt chain stores 10,000 receipt blocks, and the total storage space occupied reaches 1.2GB, exceeding the preset storage threshold of 1GB. The system initiates a compression process, marking historical receipt blocks (let's say the first 6,000 blocks) with timestamps earlier than "current time minus 180 days" as blocks to be archived. The system concatenates all the contents of these 6,000 blocks sequentially and calculates their SHA-256 hashes, obtaining the aggregate hash value "agg_hash_123...". The system removes these 6,000 blocks from the main receipt chain storage area and stores them in the archive file in the archive storage area, while retaining one archive marker block in the main receipt chain. This block contains the aggregate hash value "agg_hash_123...", the archive timestamp "2026-07-15 00:00:00", and the number of archive blocks "6000". The system uses the current block hash value of the archived tag block as the new preceding hash value, and the preceding hash value of the 10001st appended receipt block points to the hash value of that archived tag block. After compression, the length of the main receipt chain is reduced from 10000 to 4001 (4000 unarchived blocks + 1 archived tag block), and the storage space usage is reduced to approximately 500MB.

[0093] It should be noted that step S4 specifically includes: S41. Receive a replay request containing the unique identifier of the target transaction, TargetTxID; S42. Query the first-level index table. The first-level index table is a key-value pair index structure with the transaction unique identifier as the primary key and the storage location pointer of the receipt block as the value. It supports hash lookup with O(1) time complexity. If a match is found, the corresponding receipt block is located directly according to the storage location pointer. If a match is not found, all receipt blocks in the local receipt chain are traversed to search, and the search results are updated to the first-level index table. S43. Extract the unique identifier of the preceding transaction ParentTxID stored in the target receipt block. If the ParentTxID is not empty, recursively query the receipt block corresponding to the ParentTxID until it is traced back to the beginning and end of the creation without preceding transactions, forming a complete transaction causal tracing chain. S44. Sort all receipt blocks associated with the TargetTxID according to the storage order of each receipt block in the local receipt chain and the transaction semantic phase identifier PhaseID, and reconstruct the complete time-series link of the transaction from the candidate generation event to the state change event. S45. Convert the structured data of each receipt block in the time-series link into a human-readable event description, wherein the event description includes at least the event occurrence time, event type, transaction semantic stage, event source, and event result; S46. Arrange all the converted event descriptions in chronological order, generate a replay report containing the event timeline, key decision nodes, status change records and previous transaction relationships, and output the replay report.

[0094] As one embodiment, steps S41 to S46 of the present invention describe in detail the specific implementation of the playback request processing in step S4.

[0095] In step S41, the system receives a replay request initiated by a user or auditor. The replay request is submitted through a system interface (such as a web interface, mobile app, or command-line tool) and must contain at least the unique identifier of the target transaction, TargetTxID.

[0096] In step S42, the system performs a fast query using a first-level index table. The "first-level index table" is a key-value index structure with the transaction unique identifier as the primary key and the execution block storage location pointer as the value. The underlying implementation of the index table can be a hash table, supporting an average search performance of O(1) time complexity. The storage location pointer can be a file offset, database primary key, or other form of reference pointing to the storage location of the execution block in the local execution chain storage area. The system first queries the first-level index table using TargetTxID as the key: if a match is found, the corresponding execution block is located directly based on the storage location pointer, without traversing the entire execution chain; if a match is not found, all execution blocks in the local execution chain are traversed for a search, and the search result (i.e., the mapping relationship between TargetTxID and the execution block storage location) is updated to the first-level index table so that subsequent queries can quickly find the match.

[0097] In step S43, the system extracts the unique identifier of the preceding transaction, ParentTxID, stored in the target receipt block to achieve causal tracing across transactions. The ParentTxID field is written when the receipt block is generated and is used to record the preceding transactions of the current transaction. If ParentTxID is not empty, it means that the current transaction was triggered by or depends on the execution result of the preceding transaction. The system recursively queries the receipt block corresponding to ParentTxID until it traces back to the originating end without a preceding transaction (i.e., the transaction with an empty ParentTxID), forming a complete transaction causal tracing chain.

[0098] In step S44, the system sorts all receipt blocks associated with TargetTxID. The sorting is based on two dimensions: the first dimension is the storage order of each receipt block in the local receipt chain (i.e., the append order of the blocks), and the second dimension is the transaction semantic phase identifier PhaseID. Through this dual sorting, the system can accurately reconstruct the complete time-series link of the transaction from candidate generation to state change.

[0099] In step S45, the system converts the structured data of each receipt block in the time-series link into a human-readable event description. The conversion process includes, but is not limited to: converting the enumerated value of PhaseID into the corresponding Chinese phase name (e.g., "CANDIDATE" is converted into "candidate generation phase"), converting the timestamp into a date and time string in the format "YYYY-MM-DD HH:MM:SS.sss", and organizing information such as the event source and event result into a natural language description.

[0100] In step S46, the system arranges all the converted event descriptions chronologically, generates a playback report containing an event timeline, key decision nodes, state change records, and relationships with preceding transactions, and outputs it to the user terminal. The playback report can be in plain text, HTML, PDF, or JSON format, and the specific format can be flexibly selected according to the application scenario.

[0101] For example, a user initiates a replay request with TargetTxID = "TXN_20260115_001". The system uses this ID as the key to query the first-level index table, directly locating the storage location of the corresponding 5 receipt blocks. The system extracts these 5 receipt blocks and finds that one of the blocks has ParentTxID = "TXN_20260114_005" (meaning this transaction was triggered by another transaction from the previous day). Therefore, it recursively queries the receipt block corresponding to "TXN_20260114_005", forming a complete transaction causal tracing chain. The system sorts all receipt blocks according to storage order and PhaseID, reconstructs the complete timeline, and then converts each block into a human-readable event description. Finally, it generates and outputs a replay report containing an event timeline, key decision nodes, state change records, and preceding transaction relationships.

[0102] Example 3 Please see Figure 2 , Figure 2 This is a schematic diagram of the system structure of the present invention.

[0103] A system for generating, verifying, and replaying locally verifiable AI transaction receipt chains, comprising: The key event acquisition and encapsulation module is used to collect key event data during the execution of AI transactions, encapsulate the key event data in a structured manner, and generate an initial receipt block. The key event data includes at least one or more of the following: candidate generation events, sovereignty confirmation events, gating decision events, side effect execution events, and state change events. The initial receipt block includes at least a unique transaction identifier, event type, transaction semantic stage identifier, timestamp, action summary, and event data hash value. The hash chain receipt block generation module is used to read the hash value of the previous receipt block from the local receipt chain storage area as the preceding hash value. If the local receipt chain is empty, the preceding hash value is set to a zero-value hash. The module performs cryptographic hash calculation on the content of the initial receipt block to obtain the hash value of the current block. The module writes the preceding hash value and the current block hash value into the initial receipt block to generate a chain receipt block. The receipt chain append storage module is used to append the chained receipt blocks to the local receipt chain to form a transaction receipt chain with a hash chain structure. The transaction replay module is used to respond to a replay request, extract all receipt blocks associated with the unique identifier of the target transaction, reconstruct the complete execution timeline of the transaction from candidate generation to state change according to the storage order of each receipt block in the local receipt chain and the transaction semantic stage identifier, and generate a readable replay report containing an event timeline, key decision nodes and state change records.

[0104] As one embodiment, the system and method provided in this invention correspond one-to-one. The system is deployed on the user's local computing device (such as a personal computer, local server, or edge computing device), and all data is stored locally without being uploaded to the cloud, fully embodying the "Local-First" design principle of this invention. The correspondence between the functions of each module of the system and the steps of the method is as follows: The critical event acquisition and encapsulation module corresponds to method step S1 and is responsible for collecting critical event data during the AI ​​transaction execution process and encapsulating it in a structured manner. This module continuously monitors the event flow during AI transaction execution through an event listening mechanism. Event listeners are registered at each critical execution node of the AI ​​system (such as the candidate generation module, sovereignty confirmation module, gating and adjudication module, side effect execution module, and state management module). When these modules perform critical operations, event data is automatically captured. After being standardized, the captured event data is encapsulated into an initial receipt block according to a preset receipt data format.

[0105] The hash chain receipt block generation module corresponds to step S2 and is responsible for converting the initial receipt block into a chain receipt block. This module reads the hash value of the previous receipt block from the local receipt chain storage area as the preceding hash value, performs SHA-256 hash calculation on the content of the initial receipt block to obtain the current block hash value, and then writes the preceding hash value and the current block hash value into the initial receipt block to generate a chain receipt block. This module may also optionally include a digital signature submodule, used to digitally sign the current block hash value using the AI ​​system or the user's private key, and write the signature value into the receipt block.

[0106] The receipt chain append storage module corresponds to method step S3. It is responsible for writing the chained receipt blocks to the local receipt chain storage area in append mode and updating the receipt chain's metadata (current chain length, tail hash value, last update timestamp). This module ensures the append-only nature of the receipt chain—once a receipt is written, it cannot be modified or deleted.

[0107] The transaction replay module corresponds to step S4 in the method. It is responsible for responding to replay requests and generating readable replay reports. This module receives replay requests (containing the unique identifier of the target transaction) initiated by users or auditors, extracts all receipt blocks associated with the transaction from the local receipt chain, reconstructs the complete time-series chain according to the storage order and transaction semantic stage identifiers, converts structured data into human-readable event descriptions, and finally generates and outputs a replay report containing an event timeline, key decision nodes, and state change records.

[0108] For example, the owner of a decoration company deployed the above system on his local server. When the AI ​​system generates a candidate action of "sending an email to Mr. Zhang", the key event acquisition and encapsulation module captures the candidate generation event and generates an initial receipt block. The hash chain receipt block generation module reads the preceding hash value (or zero hash if it is the first one), calculates the current block hash value, and generates a chain receipt block. The receipt chain append storage module appends this block to the local receipt chain. When the user needs to audit the transaction "TXN_20260115_001", they initiate a replay request through the system interface. The transaction replay module extracts all related receipt blocks, reconstructs the timeline according to the storage order and transaction semantic stage identifiers (CANDIDATE→CONFIRMATION→GATING→EXECUTION→STATECHANGE), and generates a readable replay report containing the event timeline, key decision nodes, and state change records. Throughout the process, all receipt data is stored on the local server, and the user has complete control over their data.

[0109] The various modules of the system work together to achieve a complete governance closed loop, from the collection of key AI transaction events, the generation of receipt blocks, the hash chain storage to transaction replay.

[0110] The system can also be expanded as needed to include a verification module (corresponding to step S5 of the method), a compression and archiving module (corresponding to step S6 of the method), and an index query module (corresponding to step S4 of the method). These modules can be plugged into the system as optional components, and their specific implementation is consistent with the corresponding method implementation, so they will not be described again here.

[0111] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain, characterized in that: Includes the following steps: S1. Collect key event data during the AI ​​transaction execution process, encapsulate the key event data in a structured manner, and generate an initial receipt block; the key event data includes at least one or more of the following: candidate generation event, sovereignty confirmation event, gating decision event, side effect execution event, and state change event; The initial receipt block contains at least a unique transaction identifier, event type, transaction semantic stage identifier, timestamp, action summary, and event data hash value; S2. Read the hash value of the previous receipt block from the local receipt chain storage area as the preceding hash value. If the local receipt chain is empty, set the preceding hash value to a zero hash. Perform cryptographic hash calculation on the content of the initial receipt block to obtain the hash value of the current block. Write the preceding hash value and the current block hash value into the initial receipt block to generate a chain of receipt blocks; S3. The chained receipt block is appended and stored to the local receipt chain to form a transaction receipt chain with a hash chain structure; S4. In response to the replay request, extract all receipt blocks associated with the unique identifier of the target transaction, and reconstruct the complete execution timeline of the transaction from candidate generation to state change according to the storage order of each receipt block in the local receipt chain and the transaction semantic stage identifier, and generate a readable replay report containing the event timeline, key decision nodes and state change records.

2. The method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain as described in claim 1, characterized in that: The transaction semantic stage identifier is any value in the preset stage set {CANDIDATE, CONFIRMATION, GATING, EXECUTION, STTECHANGE}; where CANDIDATE corresponds to the candidate generation stage, CONFIRMATION corresponds to the sovereignty confirmation stage, GATING corresponds to the gating decision stage, EXECUTION corresponds to the side effect execution stage, and STTECHANGE corresponds to the state change stage.

3. The method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain as described in claim 1, characterized in that: Step S1 specifically includes: S11. Monitor the event flow during the execution of AI transactions and collect key event data; the candidate generation event records the time and content when the AI ​​system generates candidate actions; the sovereignty confirmation event records the time and method when the user confirms or rejects a candidate action; the gating adjudication event records the time and result when the unified governance core performs multi-dimensional gating adjudication on the candidate object; the side effect execution event records the time and result when the side effect operation is executed after the candidate object is converted into a formal action; the state change event records the time when the transaction state changes and the state values ​​before and after the change. S12. Standardize the key event data to generate structured event records; the structured event records include at least: transaction unique identifier TxID, event type EventType, transaction semantic phase identifier PhaseID, timestamp Timestamp, event source SourceID, action summary ActionSummary, event payload Payload, and event payload hash value PayloadHash; S13. The structured event record is encapsulated according to a preset receipt data format to generate an initial receipt block ReceiptBlock0. The initial receipt block contains at least the transaction unique identifier TxID, the event type EventType, the transaction semantic phase identifier PhaseID, the timestamp Timestamp, the event source SourceID, the action summary ActionSummary, and the event data hash value PayloadHash.

4. The method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain as described in claim 1, characterized in that: In step S2, a cryptographic hash calculation is performed on the content of the initial receipt block to obtain the hash value of the current block, specifically including: S21. Serialize all contents of the initial receipt block except for the current block hash value field according to the deterministic serialization rules to obtain a byte sequence; S22. Perform cryptographic hash calculation on the byte sequence using the SHA-256 hash algorithm to obtain a fixed-length hash digest as the current block hash value CurrentHash; S23. Write the preceding hash value PrevHash and the current block hash value CurrentHash into the corresponding fields of the initial receipt block to form a chained receipt block LinkedReceiptBlock; the data structure of the chained receipt block satisfies: CurrentHash = SHA-256(Serialize(all content in ReceiptBlock0 except for the CurrentHash field)), and PrevHash is the CurrentHash of the previous receipt block or a zero-value hash; where Serialize is a serialization function.

5. The method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain as described in claim 1, characterized in that, In step S2, the current block hash value is digitally signed using the private key of the AI ​​system or the user to generate a digital signature value, which is then written into the digital signature field of the chained receipt block. During subsequent verification, the digital signature value is verified using the public key corresponding to the private key to confirm that the receipt block was indeed created by the claimed generator. The digital signature algorithm is either RSA or ECDSA, and the private key is pre-stored in a local trusted execution environment or a secure keystore.

6. The method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain as described in claim 1, characterized in that: The method further includes: after completing step S3, in response to the verification request, obtaining the target receipt block to be verified from the local receipt chain, and performing hash chain integrity verification on the target receipt block in step S5. Step S5 and S4 are parallel, not sequential. Step S5 specifically involves: S51. Obtain the current block hash value StoredHash, the previous hash value PrevHash, and the block content data stored in the target receipt block; S52. After serializing all content in the block content data except for the current block hash value field, perform SHA-256 hash calculation to obtain the verification hash value VerifiedHash. S53. Compare the VerifiedHash value with the StoredHash value of the current block: if they match, it is determined that the content of the target receipt block is complete and has not been tampered with, and the block is marked as verified; if they do not match, it is determined that the target receipt block has been tampered with, and the block is marked as verified as failed. S54. Obtain the previous receipt block of the target receipt block, and repeat steps S51 to S53 on the previous receipt block until the genesis block of the local receipt chain is traced back to form a complete verification chain from the target block to the genesis block. S55. Each time a chained receipt block is appended to the local receipt chain, a copy of the chained receipt block is stored in the local cache or temporary storage area, and the mapping relationship between the copy and the original block is recorded. S56. When verification fails, starting from the currently failed abnormal block, trace back along the preceding hash value to locate the last complete block that passed full verification as the recovery base point; query whether there is a backup copy of the abnormal block in the local cache or temporary storage area. If a backup copy exists and the hash value recalculated on the backup copy matches the preceding hash value stored in the abnormal block, then replace the abnormal block with the backup copy and re-execute the verification steps S51 to S53; if no valid backup copy exists, generate an auditable abnormal report containing the abnormal block identifier, detection timestamp, and failure reason code, and append the abnormal report as a special receipt block to the end of the local receipt chain.

7. The method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain as described in claim 1, characterized in that: The method further includes step S6: compressing and archiving the local receipt chain according to a preset period. Step S6, the compression and archiving step, is executed independently of the playback request in step S4 and the verification request in step S5, specifically including: S61. Obtain the total storage space occupied by the current local receipt chain. When the total storage space occupied exceeds a preset storage threshold, start the compression process. S62. Mark historical receipt blocks in the local receipt chain whose timestamps are earlier than the current time minus the preset retention period as blocks to be archived. S63. Calculate the aggregate hash value of the block set to be archived, wherein the aggregate hash value is the hash digest obtained by serializing and concatenating all the block contents of the block set to be archived in the storage order and then performing SHA-256 cryptographic hash calculation. S64. Remove the set of blocks to be archived from the main receipt chain storage area and store it in the archive storage area, and retain an archive marker block in the main receipt chain. The archive marker block contains the aggregate hash value, the archive timestamp, and the number of archive blocks. S65. The current block hash value of the archived tag block is used as the new preceding hash value for subsequent newly added receipt blocks to ensure that the compressed main receipt chain still maintains complete cryptographic continuity.

8. The method for generating, verifying, and replaying a locally verifiable AI transaction receipt chain as described in claim 1, characterized in that: Step S4 specifically includes: S41. Receive a replay request containing the unique identifier of the target transaction, TargetTxID; S42. Query the first-level index table. The first-level index table is a key-value pair index structure with the transaction unique identifier as the primary key and the storage location pointer of the receipt block as the value. It supports hash lookup with O(1) time complexity. If a match is found, the corresponding receipt block is located directly according to the storage location pointer. If a match is not found, all receipt blocks in the local receipt chain are traversed to search, and the search results are updated to the first-level index table. S43. Extract the unique identifier of the preceding transaction ParentTxID stored in the target receipt block. If the ParentTxID is not empty, recursively query the receipt block corresponding to the ParentTxID until it is traced back to the beginning and end of the creation without preceding transactions, forming a complete transaction causal tracing chain. S44. Sort all receipt blocks associated with the TargetTxID according to the storage order of each receipt block in the local receipt chain and the transaction semantic phase identifier PhaseID, and reconstruct the complete time-series link of the transaction from the candidate generation event to the state change event. S45. Convert the structured data of each receipt block in the time-series link into a human-readable event description, wherein the event description includes at least the event occurrence time, event type, transaction semantic stage, event source, and event result; S46. Arrange all the converted event descriptions in chronological order, generate a replay report containing the event timeline, key decision nodes, status change records and previous transaction relationships, and output the replay report.

9. A system for generating, verifying, and replaying locally verifiable AI transaction receipt chains, characterized in that: include: The key event acquisition and encapsulation module is used to collect key event data during the execution of AI transactions, encapsulate the key event data in a structured manner, and generate an initial receipt block. The key event data includes at least one or more of the following: candidate generation events, sovereignty confirmation events, gating decision events, side effect execution events, and state change events; The initial receipt block contains at least a unique transaction identifier, event type, transaction semantic stage identifier, timestamp, action summary, and event data hash value; The hash chain-style receipt block generation module is used to read the hash value of the previous receipt block from the local receipt chain storage area as the preceding hash value. If the local receipt chain is empty, the preceding hash value is set to a zero-value hash. The module performs cryptographic hash calculation on the content of the initial receipt block to obtain the hash value of the current block. Write the preceding hash value and the current block hash value into the initial receipt block to generate a chain of receipt blocks; The receipt chain append storage module is used to append the chained receipt blocks to the local receipt chain to form a transaction receipt chain with a hash chain structure. The transaction replay module is used to respond to a replay request, extract all receipt blocks associated with the unique identifier of the target transaction, reconstruct the complete execution timeline of the transaction from candidate generation to state change according to the storage order of each receipt block in the local receipt chain and the transaction semantic stage identifier, and generate a readable replay report containing an event timeline, key decision nodes and state change records.

Images