Event Existence Anchoring and Chain Iteration Method

Abstract

This invention discloses an event existence anchoring and chain-based iteration method, belonging to the field of distributed systems and digital infrastructure technology. Addressing the problems of existing technologies where event timing anchoring can only be fixed at a single point, intermediate steps are at risk of being skipped, and causal chains are easily broken, the technical solution of this invention is as follows: The processor of the base node generates a globally unique root event anchor and stores it in local memory; the processor of each subsequent execution node obtains the valid event anchor identifier of the preceding node from the network interface, combines it with the current timing value, the event element hash value, and the node's private key, and generates the current node's event anchor using the SM3 hash algorithm and the SM2 digital signature algorithm, and writes it to local memory; if the preceding event anchor identifier does not exist or verification fails, the processor does not execute the current node's event anchor generation step, and the process does not proceed to subsequent steps. Throughout the process, the network interfaces of each node only transmit semantically neutral identifiers in a preset format.

Description

Technical Field

[0001] This invention belongs to the field of distributed systems and digital infrastructure technology, and relates to a method for event existence anchoring and chain iteration in cross-system and cross-subject scenarios. Background Technology

[0002] With the development of the digital economy, cross-system and cross-institutional event collaboration is becoming increasingly frequent, making reliable anchoring of event timing a core requirement. Existing technical solutions suffer from the following problems: Traditional trusted timestamp technology, in cross-organizational collaboration scenarios, can only solidify the existence time of a single event, and cannot anchor each intermediate link in the event execution process node by node. There is a problem that intermediate links may be skipped or modified without being detected.

[0003] Blockchain-based evidence storage technology uses a batch consensus mechanism, which makes it impossible to anchor each node in the event execution process step by step, and there are technical difficulties in unifying the timing across systems.

[0004] In existing distributed event anchoring schemes, the generation of subsequent node event anchors does not require the preceding node event anchors to be used as one of the inputs, which may lead to intermediate steps being skipped during execution.

[0005] The following terms have the following meanings in this specification: Event Anchor: A semantically non-semantic data structure used to uniquely identify the existence, timing, source, and chain relationship of an event. It serves as a common reference benchmark for cross-system event collaboration. Its core fields include AnchorID, TemporalIndex, OriginFingerprint, SequenceToken, ChainProof, and DigitalSignature.

[0006] Chain iteration: The rules are dynamically generated by taking the event anchor of the previous node as one of the inputs and combining the current node's time sequence value with the hash value of the event element.

[0007] Time and frequency reference source: An external system used to provide timing values, selected from one or more of the following groups: ground-based timing system, global satellite navigation system timing module, and atomic clock.

[0008] Event element data: The minimum necessary set of information to describe the occurrence of an event. Its hash value is used as one of the inputs to the event anchor. The raw data is not transmitted to other nodes through the network interface.

[0009] TemporalIndex: A globally unique, monotonically increasing value generated based on a time-frequency reference source, used to identify the relative order of events.

[0010] FactID: A globally unique hash identifier for the event fact benchmark unit, which can be used as one of the inputs to AnchorID, or a two-way mapping relationship can be established through the adaptation layer.

[0011] ExtensionHeader: Domain extension information appended to the base six-tuple structure. In one implementation, it is a fixed length of 8 bytes and includes an extension type identifier, extension version number, critical flags, and payload length. Summary of the Invention

[0012] Because existing technologies for event timing anchoring can only solidify at a single point, the causal chain is prone to breakage, and there is a risk of intermediate links being skipped, making it impossible to achieve reliable anchoring for each node in the entire chain, the present invention proposes an event existence anchoring and chain iteration method, which can at least solve one of the technical problems in the background technology.

[0013] To achieve the above objectives, the present invention adopts the following technical solution: An event existence anchoring and chained iteration method includes generating subsequent node event anchors by using the valid event anchor identifier of the preceding node as one of the inputs. If the preceding event anchor identifier does not exist or fails to be verified, the processor does not execute the current node event anchor generation step, and the process does not proceed to subsequent stages. Specifically, the following steps are executed through computer equipment. S1. Root Event Anchor Initialization: Based on the timing value generated by the time-frequency reference source, the hash value of the reference node certificate public key, and the random salt value, the processor of the reference node generates a globally unique root event anchor identifier using the SM3 hash algorithm, and digitally signs the root event anchor identifier and its associated fields using the reference node private key using the SM2 algorithm, and writes the generated root event anchor into the local memory of the reference node. S2. Generation of the first node event anchor: The processor of the first execution node obtains the root event anchor identifier from the reference node through the network interface, obtains the current time series value from the time-frequency reference source, calculates the SM3 hash value for the event element data of this node, concatenates the root event anchor identifier, the current time series value and the event element hash value, generates a chained check digest through the SM3 algorithm, and digitally signs the above fields with the private key of this node through the SM2 algorithm, and writes the generated first node event anchor into the local memory of this node; when the root event anchor identifier does not exist in the local memory of this node or the signature verification fails, the processor does not execute the generation step of the first node event anchor, and the process does not proceed to the subsequent steps; S3. Subsequent Node Event Anchor Chain Iteration: The processor of the nth execution node obtains the preceding event anchor identifier from the (n-1)th node through the network interface, where n is an integer not less than 2. It obtains the current time series value from the time-frequency reference source, calculates the SM3 hash value for the event element data of this node, concatenates the preceding event anchor identifier, the current time series value, and the event element hash value, and generates a chain check digest using the SM3 algorithm. It then digitally signs the above fields using the SM2 algorithm with the private key of this node and writes the generated current node event anchor into the local memory of this node. If the preceding event anchor identifier does not exist or the signature verification fails, the processor does not execute the current node event anchor generation step, and the process does not proceed to the subsequent steps. S4. Construction of the full-link event anchor sequence: The processors of each execution node write the identifiers of the root event anchor, the first node event anchor, and all subsequent node event anchors into the local memory of each node in the execution order from S1 to S3, forming a chain-like iterative sequence, which is stored in the local memory of the participating nodes. S5. Event Anchor Chain Verification and Tracing: The processor of the verification node obtains the target event anchor identifier through the network interface, reads the event anchor sequence from the local memory of each node in sequence, verifies the integrity of the chained verification digest and the monotonically increasing nature of the time sequence value, and outputs the verification result.

[0014] In summary, this invention discloses an event existence anchoring and chain-based iteration method, belonging to the field of distributed systems and digital infrastructure technology. Addressing the problems of existing technologies where event timing anchoring can only be fixed at a single point, intermediate steps are at risk of being skipped, and causal chains are easily broken, the technical solution of this invention is as follows: The processor of the base node generates a globally unique root event anchor and stores it in local memory; the processor of each subsequent execution node obtains the valid event anchor identifier of the preceding node from the network interface, combines it with the current timing value, the event element hash value, and the node's private key, and generates the current node's event anchor using the SM3 hash algorithm and the SM2 digital signature algorithm, and writes it to local memory; if the preceding event anchor identifier does not exist or verification fails, the processor does not execute the current node's event anchor generation step, and the process does not proceed to subsequent steps. Throughout the process, the network interfaces of each node only transmit semantically neutral identifiers in a preset format.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: 1) Core security effectiveness 1. End-to-end node anchoring to prevent intermediate links from being skipped. Existing technologies can only timestamp a single event, failing to ensure that all intermediate steps during event execution are accurately recorded. This invention employs a chain-like iterative mechanism—the generation of each subsequent node's event anchor must use the valid event anchor identifier of the preceding node as one of its inputs, forming an interlocking anchor chain. The absence, alteration, or skipping of any intermediate node will cause the verification of all subsequent node event anchors to fail, fundamentally eliminating the risk of "intermediate steps being secretly skipped."

[0016] 2. Hard constraints of pre-dependent processes If the current event anchor identifier does not exist in local memory, or if signature verification fails, the processor will not execute the step of generating the current node's event anchor, and the process will not proceed to subsequent stages. This is not a soft hint or logging, but a hard process interruption, ensuring the integrity and unbypassability of the entire event chain.

[0017] 3. Semantic isolation to protect business privacy Throughout the process, each node's network interface only transmits semantically neutral identifiers in a pre-defined format (such as AnchorID, hash value, and signature value), without transmitting original business data. This achieves cross-system event collaboration and verification while avoiding the exposure of sensitive business information on the network, thus balancing collaboration transparency and data privacy.

[0018] (ii) Technical credibility effect 1. Reliable timing, preventing replay and tampering. The TemporalIndex field of all event anchors is generated based on time and frequency reference sources (ground-based time service systems, global navigation satellite system time service modules, atomic clocks, etc.), ensuring the monotonically increasing and uniqueness of the global time sequence. Combining the SM3 hash algorithm and the SM2 digital signature algorithm, any tampering with historical event anchors will result in a chain checksum mismatch, and the tampering can be detected immediately.

[0019] 2. Compliant with national cryptographic algorithms, meeting domestic compliance requirements. It adopts the SM3 hash algorithm and SM2 digital signature algorithm instead of internationally used algorithms (such as SHA-256 and ECDSA), which directly adapts to my country's cryptography management regulations and financial industry security compliance standards, financial industry security norms and cryptography management regulations, reducing the compliance transformation costs when implemented in sensitive areas such as public governance and finance.

[0020] 3. Private key security protection The node private key is generated by the processor through a Hardware Security Module (HSM) or Trusted Execution Environment (TEE), stored in a protected area, and is not written to local memory in plaintext or transmitted over a network interface. Even if the node's memory is physically extracted, the private key cannot be obtained, thus fundamentally ensuring the security of the signature system.

[0021] III) Compliance and Regulatory Adaptation Effect 1. Electronic data integrity can be cryptographically verified. The event anchor chain iterative sequence can serve as electronic data conforming to cryptographic integrity standards, allowing verification nodes to perform ChainProof consistency verification. The SM2 digital signature, monotonically increasing time sequence value, and chain checksum in the chain structure together constitute a complete chain of evidence, satisfying the requirements of "authenticity, integrity, and non-repudiation" of electronic data.

[0022] 2. Supports multi-copy synchronization and regulatory penetration. The chained iterative sequence involves multiple participating nodes storing copies, which are then synchronized to the local storage of the regulatory and evidence storage nodes. Each copy can verify consistency through a verification interface, achieving the governance goal of "transparent business execution and real-time regulatory penetration."

[0023] IV) Scalability and Scene Adaptability 1. Supports cause-effect tree structure, adapting to complex business processes. It supports not only linear chain structures but also causal tree structures with a root event anchor as the root node and different execution paths as branches. The event anchor of each branch node is generated with the event anchor identifier of its parent node as input, which can flexibly adapt to complex business scenarios with parallel branches, such as securities matching, cross-border payments, and industrial control.

[0024] 2. Extend header fields to support domain customization By extending the header field (ExtensionHeader) mechanism, domain-specific information can be extended based on a unified infrastructure across different fields such as finance, public governance, and multi-agent systems, without altering the underlying six-tuple structure. A key flag field ensures that "processors that cannot recognize this extension type must refuse to process it," guaranteeing backward compatibility of the extension.

[0025] 3. Cross-validation improves performance in large-scale scenarios. Verification nodes can verify the causal order of any two event anchors in O(1) time complexity through recursive chain hash calculation, skip list verification path, and verification point cache batch verification, without having to traverse all intermediate anchors node by node, which significantly improves the verification efficiency in large-scale, long chain scenarios.

[0026] V) Results of AI Governance Project 1. Traceability and cascading revocation of AI agents For AI agent scenarios, this invention innovatively embeds the deployer's fingerprint permanently into the AI ​​agent's identity fingerprint. Verifiers can confirm the deployment owner solely based on the agent's fingerprint without needing to query external data. When the deployer's license is revoked due to violations, all associated AI agent identity verifications are simultaneously marked as invalid, achieving "one-click cascading revocation" and solving the governance challenges of "who deploys, who is responsible, and how to hold accountable" for AI agents.

[0027] 2. Condition control for AI agent generation The deployer needs to pre-register a generation condition record that includes a whitelist of trigger event types, conditional predicates, and a maximum generation limit, and sign it with a private key. The generation of AI agents is subject to strict pre-constraints; if any condition is not met, the processor will not execute the generation step to prevent the AI ​​agents from being overproduced and out of control. Attached Figure Description

[0028] Figure 1 This is the overall flowchart of the event anchor chain iterative method of the present invention; Figure 2 This is a flowchart of the single-node event anchor generation process of the present invention; Figure 3 This is a flowchart illustrating the process for handling anchor point verification failures in this invention. Figure 4 This is a schematic diagram of the full-link event anchor sequence structure of the present invention; Figure 5 This is a schematic diagram of the causal tree structure of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0030] Terminology Standardization: In this specification, the symbol ∥ indicates a byte string concatenation operation. Local memory is selected from one of the following groups: RAM, Flash memory, and database storage media.

[0031] like Figure 1 As shown, an event existence anchoring and chain iteration method according to an embodiment of the present invention includes the following steps: S1 Root Event Anchor Initialization: Based on the timing value generated by the time-frequency reference source, the hash value of the reference node certificate public key, and the random salt value, the processor of the reference node generates a globally unique root event anchor identifier using the SM3 hash algorithm, and digitally signs the root event anchor identifier and its associated fields using the reference node private key using the SM2 algorithm, and writes the generated root event anchor into the local memory of the reference node. S2 First Node Event Anchor Generation: The processor of the first execution node obtains the root event anchor identifier from the reference node through the network interface, obtains the current time series value from the time-frequency reference source, calculates the SM3 hash value for the event element data of this node, concatenates the root event anchor identifier, the current time series value and the event element hash value, generates a chained check digest through the SM3 algorithm, and digitally signs the above fields with the private key of this node through the SM2 algorithm, and writes the generated first node event anchor into the local memory of this node; when the root event anchor identifier does not exist in the local memory of this node or the signature verification fails, the processor does not execute the first node event anchor generation step, and the process does not proceed to the subsequent steps; S3 Subsequent Node Event Anchor Chain Iteration: The processor of the nth execution node obtains the preceding event anchor identifier from the (n-1)th node through the network interface, where n is an integer not less than 2. It obtains the current time series value from the time-frequency reference source, calculates the SM3 hash value for the event element data of this node, concatenates the preceding event anchor identifier, the current time series value, and the event element hash value, and generates a chain check digest using the SM3 algorithm. It then digitally signs the above fields using the SM2 algorithm with the private key of this node and writes the generated current node event anchor into the local memory of this node. If the preceding event anchor identifier does not exist or the signature verification fails, the processor does not execute the current node event anchor generation step, and the process does not proceed to the subsequent stages. S4 Full-link event anchor sequence construction: The processors of each execution node write the identifiers of the root event anchor, the first node event anchor, and all subsequent node event anchors into the local memory of each node in the execution order from S1 to S3, forming a chain-like iterative sequence, which is stored in the local memory of the participating nodes. S5 Event Anchor Chain Verification and Traceability: The processor of the verification node obtains the target event anchor identifier through the network interface, reads the event anchor sequence from the local memory of each node in sequence, verifies the integrity of the chained verification digest and the monotonically increasing nature of the time sequence value, and outputs the verification result.

[0032] Figure 1 In the diagram, the diamond-shaped box represents the decision node; the red path represents the exception handling path, where the process does not proceed to subsequent steps; the green path represents the normal execution path; and the loop on the left represents the cyclic execution of S3 on multiple subsequent nodes.

[0033] The following are detailed explanations: In step S1, the time and frequency reference source is selected from one or more of the following groups: ground-based time service system, global satellite navigation system time service module, and atomic clock.

[0034] In step S1, the root event anchor adopts a six-tuple structure, including: AnchorID field, storing a globally unique hash identifier generated by the SM3 algorithm from metadata and random salt; TemporalIndex field, storing a monotonically increasing time series value generated based on a time-frequency reference source; OriginFingerprint field, storing an irreversible hash fingerprint generated by the node certificate public key using the SM3 algorithm; SequenceToken field, storing a monotonically increasing sequence number within this node; ChainProof field, storing an SM3 chained verification digest generated based on the first four fields and the preceding event anchor identifier; and DigitalSignature field, storing an SM2 digital signature generated by the node processor using the node's private key for the first five fields.

[0035] like Figure 2 As shown, in step S2, the event anchor generation calculation is performed by the execution node processor according to the following formula: T n = SM2_Sign(SM3(T) n-1 ∥ Time n ∥ Data n ), Priv n ) Wherein, the symbol ∥ represents the byte string concatenation operation; T n The output is a combination of the ChainProof and DigitalSignature fields of the current node's event anchor; T n-1 The AnchorID field value is the event anchor of the preceding node, read from the local storage of this node; Time n The TemporalIndex value obtained by the current node from the time-frequency reference source; Data n The SM3 hash value calculated for the event element data of the current node; Priv n The SM2 private key generated and stored by the current node through a hardware security module or a trusted execution environment.

[0036] Figure 2 The three inputs are obtained by the processor from local memory, network interface, and local computation, respectively, and are independent of each other; the private key Priv is generated and stored by the hardware security module and is not written to local memory or transmitted via the network interface in plaintext; this diagram corresponds to S2(n=1, T n -1 (as the root event anchor) and S3 (n≥2, T n -1 The process involves two steps: anchoring the preceding node event.

[0037] In step S2, the node private key is generated by the node processor through a hardware security module or a trusted execution environment, and stored in the internal memory of the hardware security module or the protected storage area of ​​the trusted execution environment; the private key is not written to the node's local memory in plaintext, and is not transmitted through a network interface.

[0038] In step S3, if the preceding event anchor identifier does not exist in the local memory of this node or the preceding event anchor signature verification fails, the processor executes the following steps: writes the current node identifier, the preceding event anchor identifier, and the current timing value to the exception log area of ​​the local memory of this node; returns a rejection response in a preset format to the network interface of the initiating node; does not execute the current node event anchor generation step, and the process does not proceed to subsequent stages. Figure 3 As shown, the three checks are performed sequentially; if any fails, an error is written to the exception log and the process terminates; execution continues only after all checks pass. Figure 2 The generation steps are shown.

[0039] In step S3, the chained verification digest is generated using one of the following structures: Merkle tree hash chain structure, hash pointer-based linked list structure, and accumulator-based aggregated verification structure.

[0040] In step S4, the chained iterative sequence also supports a causal tree structure: with the root event anchor as the root node and the event anchor sequences of different execution paths as branch nodes, the event anchor of each branch node is generated by the processor using its parent node's event anchor identifier as ChainProof input, forming a tree-like chain structure, which is stored in the local memory of each node. Figure 4 and Figure 5 As shown; like Figure 4 As shown, the root event anchor (dark blue border): generated by the baseline node processor, is the starting point of trust for the entire chain; the execution node event anchor (light blue border): the ChainProof field contains a hash reference to the preceding AnchorlD; the supervisory node replica (orange dashed border): only stores the AnchorlD sequence, not business data notes; H(xIyI2) represents the SM3 hash algorithm performed on the byte string concatenation result; each node event anchor is stored in its own local memory and is independent of each other.

[0041] Figure 5In this tree, the root event anchor is the root node, generated by the baseline node processor, and serves as the trusted starting point for all branches. The ChainProof field of each branch's first node references the AnchorID of the root event anchor, establishing a chained association with the root node. The ChainProof field of each node within a branch references the AnchorID of its predecessor node, forming an intra-branch chained iteration. Different branches are independent of each other, and the event anchors of each branch node are stored in their respective local memory. The Temporalndex value of each branch is strictly monotonically increasing globally (T0). <T1<T2<T3<…): Example of applicable scenarios: A cross-institutional transaction (branch 1: order placement and matching) shares the same event anchor with another parallel transaction (branch 2, branch 3).

[0042] In step S4, the chain-like iterative sequence is stored in copies by multiple participating nodes. Each copy is synchronized to the local storage of the supervisory node and the evidence storage node through the network interface. The consistency of each stored copy is verified through the verification interface in step S5.

[0043] In this embodiment, each node's network interface transmits only pre-formatted, semantically unidentified metadata.

[0044] In step S5, the verification includes the following three items, all of which are executed by the verification node processor: verifying the validity of the DigitalSignature field of each node's event anchor using the SM2 public key; verifying that the TemporalIndex value of each node in the chained iterative sequence is strictly monotonically increasing; and recalculating the ChainProof field and comparing it with the stored value to verify the chain integrity.

[0045] The method is applicable to event anchoring requirements in one of the following scenarios: high-frequency trading matching in securities, electronic evidence storage, cross-border payment clearing, industrial control system event synchronization, and multi-agent collaborative event synchronization. Upon accessing each scenario, a semantically neutral identifier in a preset format is written to the local log storage. In other words, the method is applicable to cross-node event anchoring requirements in one of the following technical fields: financial time-series clearing, data storage and integrity verification, cross-border settlement, industrial control time-series synchronization, and multi-agent task orchestration. Upon accessing each scenario, a semantically neutral identifier in a preset format is written to the local log storage.

[0046] In step S2, the chained checksum is generated by the execution node processor using any of the following modules: The hash chain calculation module generates a digest by chaining hash pointers of the previous event anchor identifier and the current node data. The accumulator aggregation calculation module generates a digest by performing cryptographic accumulator operations on the anchor identifier of the preceding event and the data of the current node. The Merkle tree hash calculation module generates a root hash digest by constructing a Merkle tree containing the anchor identifiers of previous events and the data of the current node. One of the modules is used to generate a chained integrity check summary with prior dependencies, write it to the ChainProof field of the current node's event anchor, and store it in the local memory of this node.

[0047] The calculation of AnchorID also includes a random salt value as input, which is generated by the processor through a cryptographically secure pseudo-random number generator, making the AnchorID generated under the same input conditions unpredictable.

[0048] In step S5, the processor of the verification node also performs a skip verification in the following way: selects an anchor pair consisting of a target anchor and a preset verification anchor in the event anchor sequence, and verifies the causal chain integrity of the target anchor by using a verification structure selected from a group consisting of recursive chain hash calculation, a skip list-based verification path, and a batch verification based on verification point caching, without having to traverse all intermediate anchors node by node.

[0049] The event anchor also includes an event semantic binding field, which stores the AnchorID field value of the current event anchor, the subject identity verification reference identifier associated with the event, and the event business data hash value, a fixed-length hash digest generated by the SM3 algorithm; the input for generating the event semantic binding field is selected from one or more combinations of the subject identity verification reference identifier, content integrity verification reference identifier, authorization verification reference identifier, relationship verification reference identifier, and revenue attribution verification reference identifier; when the event semantic binding field is a sequence of all zero bytes, it indicates that the event anchor is not associated with a specific subject; the verification node processor uses the TemporalIndex field value of the current event anchor as the time base to verify the validity of the referenced subject identity verification at the time of the event.

[0050] The event anchor also supports extended header fields, which are appended to the basic six-tuple structure and do not affect the generation and verification process of the basic six-tuple fields. These extended header fields include: an extension type identifier, which stores a numerical code that identifies the extension type; an extension version number, which stores a monotonically increasing version number starting from 1; a critical flag, which, when set to a preset value, indicates that a processor that cannot recognize the extension type must refuse to process the current event anchor; a payload length, which stores the number of bytes of the extended payload; and an extended payload, which stores domain-specific extension information.

[0051] When the event is initiated by the AI ​​agent, the subject identity fingerprint corresponding to the subject identity proof reference identifier is generated by the processor using the SM3 algorithm with the type prefix byte, the public key byte sequence of the AI ​​agent, and the subject fingerprint byte sequence of the deployer as input. The subject fingerprint of the deployer is permanently embedded in the input of the AI ​​agent subject fingerprint generation, so that any verifier holding the subject fingerprint can confirm the deployment owner of the AI ​​agent without querying external data. When the subject identity proof of the deployer is revoked, the subject identity proofs of all AI agents associated with the deployer are simultaneously marked as invalid.

[0052] The identity verification of the AI ​​agent is triggered by the following conditions: the deployer processor pre-registers a generation condition record containing a whitelist of trigger event types, conditional predicates, and a maximum generation limit, and signs it with the deployer's private key; when a trigger event that meets the registered generation conditions occurs, the processor verifies that the trigger event type is within the whitelist, the conditional predicate is satisfied, and the current generation quantity has not exceeded the limit, and then executes the generation step of the AI ​​agent's identity verification; if any condition is not met, the processor does not execute the generation step, and the process does not proceed to subsequent stages.

[0053] The following are examples: Example 1: High-frequency trading matching scenario in securities A stock exchange deployed the method of this invention, with the time and frequency reference source being a ground-based time service system.

[0054] S1: As Figure 1 As shown, the benchmark node processor takes the current timing value, the benchmark node certificate public key hash value and the random salt value as input, generates a 256-bit AnchorID using the SM3 algorithm, generates a DigitalSignature using the benchmark node private key using the SM2 algorithm, and writes the six-tuple root event anchor into the benchmark node's local memory.

[0055] S2: The investor order node (node ​​A) processor obtains the root event anchor AnchorID from the benchmark node through the network interface, obtains the current TemporalIndex value from the time-frequency benchmark source, calculates the SM3 hash value for the order data of this node, and writes the first node event anchor of the six-tuple into the local memory of node A; if the root event anchor AnchorID does not exist or the SM2 signature verification fails, the processor does not execute the generation step and writes the exception information into the exception log area.

[0056] S3: Matching node (node ​​B), transaction node (node ​​C), clearing node (node ​​D) and so on. Each node processor takes the AnchorID of the preceding node as input, and the TemporalIndex is strictly monotonically increasing.

[0057] S4: Each node forms a chain-like iterative sequence in the order of S1 to S3, and is simultaneously synchronized to the local memory of the monitoring node.

[0058] S5: The supervisory node verifies the validity of the SM2 signature, the monotonically increasing nature of the TemporalIndex, and the consistency of ChainProof.

[0059] In one implementation, the core structure of the event anchor is a six-tuple, and the calculation of AnchorID also includes a random salt value generated by a cryptographically secure pseudo-random number generator as input. In another implementation, the verification node can also verify the causal order of any two event anchors in O(1) time complexity through a cross-checking path of recursive chained hashes.

[0060] Example 2: Supply Chain Traceability Scenario A cross-border logistics company has deployed the method of this invention, using a global navigation satellite system timing module as the time and frequency reference source. From the initial inspection of goods at the factory, customs clearance, and transportation receipt, an immutable chain of anchoring sequences is generated according to steps S1 to S5. Each step only transmits the AnchorID identifier, without transmitting business data such as cargo manifests or trade contracts. When a quality dispute arises, the verifying party verifies the integrity of the entire anchoring chain through step S5 to pinpoint the problematic step.

[0061] Example 3: Multi-agent collaborative event governance scenario A fintech company has deployed a multi-agent trading system, which includes decision-making AI agents, execution AI agents, and risk control AI agents.

[0062] The deployer processor pre-registers the generation condition records, specifying the trigger event type and the maximum generation limit. When an authorization approval event occurs, the processor generates a principal identity fingerprint for each agent: Agent principal fingerprint = SM3(type prefix | agent public key | deployer principal fingerprint), and the deployer principal fingerprint is permanently embedded in the principal fingerprints of all three agents.

[0063] When a deployer's license is revoked due to violations, the identity verification of all AI agents associated with that deployer is simultaneously marked as invalid. Each agent generates an event anchor sequence according to steps S1 to S5, and simultaneously binds the agent's identity to the event semantic binding field. The accountability path can be traced directly back to the deployer from the agent's fingerprint.

[0064] In summary, the advantages of the embodiments of the present invention are as follows: (1) End-to-end node anchoring: Each execution node generates an event anchor that inherits the information of the preceding node. Any modification to an intermediate node will cause the event anchor verification of all subsequent nodes to fail. (2) Precedence dependency process constraints: If the preceding event anchor does not exist or the verification fails, the processor will not execute subsequent steps; (3) Semantic isolation: Each node's network interface only transmits data without semantic identifiers and does not transmit business data; (4) National cryptographic algorithm adaptation: The SM3 hash algorithm and SM2 digital signature algorithm are adopted to adapt to cryptographic management regulations and financial industry security compliance requirements; (5) Compliance and adaptability: The event anchor chain iterative sequence can be used as electronic data that conforms to the cryptographic integrity verification standard, and is used by the verification node to perform ChainProof consistency verification; (6) Extensibility: By extending header fields, it supports the extension of domain-specific fields in different fields such as finance, public governance, and multi-agent systems based on a unified infrastructure; (7) AI agent accountability: Through the embedding of the deployer's main fingerprint and the generation of conditions, the controllable management and cascading revocation of the artificial intelligence agent can be realized.

[0065] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0066] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An event existence anchoring and chain iteration method, characterized in that, Includes the following steps: S1 Root Event Anchor Initialization: Based on the timing value generated by the time-frequency reference source, the hash value of the reference node certificate public key, and the random salt value, the processor of the reference node generates a globally unique root event anchor identifier using the SM3 hash algorithm, and digitally signs the root event anchor identifier and its associated fields using the reference node private key using the SM2 algorithm, and writes the generated root event anchor into the local memory of the reference node. S2 Event Anchor Chain Iteration: The processor of the execution node obtains the valid event anchor identifier of the preceding node through the network interface, obtains the current time series value from the time-frequency reference source, performs SM3 hash calculation on the event element data of this node, concatenates the preceding event anchor identifier, the current time series value and the event element hash value, generates a chain check digest through the SM3 algorithm, and digitally signs the above fields with the private key of this node through the SM2 algorithm, and writes the generated event anchor into the local memory of this node; If the preceding event anchor identifier does not exist or the signature verification fails, the processor will not execute the generation step of the current node's event anchor, and the process will not proceed to subsequent stages; wherein, the preceding node of the first execution node is the reference node; S3 Subsequent node event anchor chain iteration: The processor of the nth execution node obtains the previous event anchor identifier from the (n-1)th node, n≥2, and generates and stores the current node event anchor in the same way as S2; The process terminates when the anchor identifier for the preceding event does not exist or the signature verification fails. S4 Full-Link Event Anchor Sequence Construction: The processors of each execution node write the identifiers of the root event anchor and all execution node event anchors into the local memory of each node in the execution order from S1 to S2, forming a chain-like iterative sequence. S5 Event Anchor Chain Verification and Traceability: The processor of the verification node obtains the target event anchor identifier through the network interface, reads the event anchor sequence from the local memory of each node in sequence, verifies the integrity of the chained verification digest and the monotonically increasing nature of the time sequence value, and outputs the verification result.

2. The method according to claim 1, characterized in that, In step S1, the time and frequency reference source is selected from one or more of the following groups: ground-based time service system, global satellite navigation system time service module, and atomic clock.

3. The method according to claim 1, characterized in that, In step S1, the root event anchor adopts a six-tuple structure, including: AnchorID field, storing a globally unique hash identifier generated by the SM3 algorithm from metadata and random salt; TemporalIndex field, storing a monotonically increasing time series value generated based on a time-frequency reference source; OriginFingerprint field, storing an irreversible hash fingerprint generated by the node certificate public key using the SM3 algorithm; SequenceToken field, storing a monotonically increasing sequence number within this node; ChainProof field, storing an SM3 chained verification digest generated based on the first four fields and the preceding event anchor identifier; and DigitalSignature field, storing an SM2 digital signature generated by the node processor using the node's private key for the first five fields.

4. The method according to claim 1, characterized in that, In steps S2 and S3, the event anchor generation calculation is performed by the execution node processor according to the following formula: T n = SM2_Sign(SM3(T n-1 ∥ Time n ∥ Data n ),Priv n ) Wherein, the symbol ∥ represents the byte string concatenation operation; T n The output is a combination of the ChainProof and DigitalSignature fields of the current node's event anchor; T n-1 The AnchorID field value is the event anchor of the preceding node, read from the local storage of this node; Time n The TemporalIndex value obtained by the current node from the time-frequency reference source; Data n The SM3 hash value calculated for the event element data of the current node; Priv n The SM2 private key generated and stored by the current node through a hardware security module or a trusted execution environment.

5. The method according to claim 1, characterized in that, In steps S2 and S3, the node private key is generated by the node processor through a hardware security module or a trusted execution environment, and stored in the internal memory of the hardware security module or the protected storage area of ​​the trusted execution environment. The private key is not written to the node's local storage in plaintext, nor is it transmitted through the network interface.

6. The method according to claim 1, characterized in that, In step S3, if the current node anchor identifier does not exist in the local memory of this node or the signature verification of the previous event anchor fails, the processor performs the following steps: writes the current node identifier, the previous event anchor identifier, and the current timing value into the exception log area of ​​the local memory of this node; returns a rejection response in a preset format to the network interface of the initiating node; does not execute the current node event anchor generation step, and the process does not proceed to the subsequent steps.

7. The method according to claim 1, characterized in that, In step S3, the chained verification digest is generated using one of the following structures: Merkle tree hash chain structure, hash pointer-based linked list structure, and accumulator-based aggregated verification structure.

8. The method according to claim 1, characterized in that, In step S4, the chain-like iterative sequence also supports a causal tree structure: with the root event anchor as the root node and the event anchor sequences of different execution paths as branch nodes, the event anchor of each branch node is generated by the processor with its parent node event anchor identifier as ChainProof input, forming a tree-like chain structure, which is stored in the local memory of each node.

9. The method according to claim 1, characterized in that, In step S4, the chain-like iterative sequence is stored in copies by multiple participating nodes. Each copy is synchronized to the local storage of the supervisory node and the evidence storage node through the network interface. The consistency of each stored copy is verified through the verification interface in step S5.

10. The method according to claim 1, characterized in that, Throughout the process, the network interfaces of each node only transmit preset format semantic identifiers and metadata.

11. The method according to claim 1, characterized in that, In step S5, the verification includes the following three items, all of which are executed by the verification node processor: verifying the validity of the DigitalSignature field of each node's event anchor using the SM2 public key; verifying that the TemporalIndex value of each node in the chained iterative sequence is strictly monotonically increasing; and recalculating the ChainProof field and comparing it with the stored value to verify the chain integrity.

12. The method according to claim 1, characterized in that, The method is applicable to cross-node event anchoring requirements in one of the following technical fields: financial time-series clearing, data storage and integrity verification, cross-border settlement, industrial control time-series synchronization, and multi-agent task orchestration. When each scenario is accessed, a semantically undefined identifier in a preset format is written to the local log storage.

13. The method according to claim 1, characterized in that, In step S2, the chained checksum is generated by the execution node processor using any of the following modules: The hash chain calculation module generates a digest by chaining hash pointers of the previous event anchor identifier and the current node data. The accumulator aggregation calculation module generates a digest by performing cryptographic accumulator operations on the anchor identifier of the preceding event and the data of the current node. The Merkle tree hash calculation module generates a root hash digest by constructing a Merkle tree containing the anchor identifiers of previous events and the data of the current node. One of the modules is used to generate a chained integrity check summary with prior dependencies, write it to the ChainProof field of the current node's event anchor, and store it in the local memory of this node.

14. The method according to claim 3, characterized in that, The calculation of AnchorID also includes a random salt value as input, which is generated by the processor through a cryptographically secure pseudo-random number generator, making the AnchorID generated under the same input conditions unpredictable.

15. The method according to claim 1, characterized in that, In step S5, the processor of the verification node also performs a skip verification in the following way: selects an anchor pair consisting of a target anchor and a preset verification anchor in the event anchor sequence, and verifies the causal chain integrity of the target anchor by using a verification structure selected from a group consisting of recursive chain hash calculation, a skip list-based verification path, and a batch verification based on verification point caching, without having to traverse all intermediate anchors node by node.

16. The method according to claim 1, characterized in that, The event anchor also includes an event semantic binding field, which stores the AnchorID field value of the current event anchor, the subject identity verification reference identifier associated with the event, and the event business data hash value, a fixed-length hash digest generated by the SM3 algorithm; the input for generating the event semantic binding field is selected from one or more combinations of the subject identity verification reference identifier, content integrity verification reference identifier, authorization verification reference identifier, relationship verification reference identifier, and revenue attribution verification reference identifier; when the event semantic binding field is a sequence of all zero bytes, it indicates that the event anchor is not associated with a specific subject; the verification node processor uses the TemporalIndex field value of the current event anchor as the time base to verify the validity of the referenced subject identity verification at the time of the event.

17. The method according to claim 1, characterized in that, The event anchor also supports extended header fields, which are appended to the basic six-tuple structure and do not affect the generation and verification process of the basic six-tuple fields. These extended header fields include: an extension type identifier, which stores a numerical code that identifies the extension type; an extension version number, which stores a monotonically increasing version number starting from 1; a critical flag, which, when set to a preset value, indicates that a processor that cannot recognize the extension type must refuse to process the current event anchor; a payload length, which stores the number of bytes of the extended payload; and an extended payload, which stores domain-specific extension information.

18. The method according to claim 16, characterized in that, When the event is initiated by the AI ​​agent, the subject identity fingerprint corresponding to the subject identity proof reference identifier is generated by the processor using the SM3 algorithm with the type prefix byte, the public key byte sequence of the AI ​​agent, and the subject fingerprint byte sequence of the deployer as input. The subject fingerprint of the deployer is permanently embedded in the input of the AI ​​agent subject fingerprint generation, so that any verifier holding the subject fingerprint can confirm the deployment owner of the AI ​​agent without querying external data. When the subject identity proof of the deployer is revoked, the subject identity proofs of all AI agents associated with the deployer are simultaneously marked as invalid.

19. The method according to claim 18, characterized in that, The identity verification of the AI ​​agent is triggered by the following conditions: the deployer processor pre-registers a generation condition record containing a whitelist of trigger event types, conditional predicates, and a maximum generation limit, and signs it with the deployer's private key; when a trigger event that meets the registered generation conditions occurs, the processor verifies that the trigger event type is within the whitelist, the conditional predicate is satisfied, and the current generation quantity has not exceeded the limit, and then executes the generation step of the AI ​​agent's identity verification; if any condition is not met, the processor does not execute the generation step, and the process does not proceed to subsequent stages.

Images