Cross-chain smart contract execution tracking system and method based on identity binding

Abstract

The invention discloses a cross-chain smart contract execution tracking system and method based on identity binding, relates to the technical field of block chain cross-chain, and aims to solve the verification black box problem of opaque execution process and difficult auditing in the existing cross-chain system. The method comprises the steps of obtaining an identity label and a contract parameter of a calling request; collecting stage data in each predefined cross-chain logic stage, and constructing a process state sequence in sequence; performing causal logic verification on the sequence to ensure that time and state logic are consistent; after the verification is passed, generating a unique track data unit in combination with the identity and parameters; the units are sequentially Hash-linked and stored as an execution track chain which cannot be tampered; and rapid retrieval and audit output based on identities or contract addresses are supported.

Description

Technical Field

[0001] This invention relates to the field of blockchain cross-chain technology, specifically to a cross-chain smart contract execution tracking system and method based on identity binding. Background Technology

[0002] Existing mainstream cross-chain technologies, such as solutions based on relay chains, sidechains, or light nodes for verification, are based on the core logic of verifying the authenticity of specific states of the source chain (such as transaction hashes and block headers) and triggering the preset contract logic on the target chain after successful verification.

[0003] However, such solutions prioritize the security and efficiency of cross-chain transactions in their design, and their technical architecture has an inherent limitation: there is an irreconcilable technical contradiction between the data integrity of cross-chain operations and the efficiency of on-chain verification. Specifically, existing systems generally adopt the state digest verification paradigm to reduce the computational and storage overhead of on-chain verification and improve throughput. This paradigm only submits and verifies a very simple proof of the source chain state on the target chain, such as a final result signed by multiple relays or a zero-knowledge proof. The complete process path of cross-chain calls, including the initial relay node of the request, the forwarding path of multiple relays, the identity signature sequence of each participating node, and the intermediate states in the verification process, are regarded as off-chain implementation details and are discarded.

[0004] This leads to a technical flaw: the execution process of cross-chain smart contracts lacks a complete, time-series record on the chain, forming a "verification black box"; auditors can only observe two discrete, outcome-based events, "state verified" and "contract executed," and cannot trace the complete technical path and decision-making chain connecting these two events.

[0005] For example, the auditing experience with existing technology is similar to being able to only check the "sent" and "delivered" status of an international package, but not knowing its specific logistics route, transit warehouse, handling personnel, and transportation time; when the package is lost or damaged, it is extremely difficult to locate the problem.

[0006] Therefore, when facing security incident analysis, compliance review, or operational failure diagnosis, existing cross-chain systems require auditors to rely on off-chain logs with questionable credibility and manually correlate and piece together information from scattered records across multiple heterogeneous chains. This process is cumbersome, inefficient, and the conclusions are difficult to verify.

[0007] How to generate a globally unified, tamper-proof, and efficiently searchable full-process execution trajectory for each cross-chain smart contract call without sacrificing cross-chain execution performance has become an urgent technical problem to be solved.

[0008] To address the above issues, this invention proposes a cross-chain smart contract execution tracking system and method based on identity binding. Summary of the Invention

[0009] The purpose of this invention is to provide a cross-chain smart contract execution tracking system and method based on identity binding, so as to solve the problems raised in the prior art.

[0010] To achieve the above objectives, the present invention provides the following technical solution: The method for tracking the execution of cross-chain smart contracts based on identity binding includes the following steps: S1. Obtain the identity of the initiator of the cross-chain smart contract call request and the contract call parameters; S2. During the execution of the call request, in multiple predefined cross-chain logic stages, the stage identifier, timestamp, associated identity set and state hash set corresponding to each stage are collected, and a process state sequence is constructed in chronological order. S3. Perform causal logic verification on the process state sequence; the verification includes checking the timestamp order of adjacent stages in the sequence and checking whether there is a hash value in the state hash of the next stage that is logically related to the state hash of the previous stage. S4. Once the process state sequence is verified, a unique trajectory data unit is generated by combining the initiator's identity identifier with the contract call parameters. S5. Link and store the trajectory data units with historical trajectories according to the generation time sequence to form an execution trajectory chain; S6. In response to the audit request, based on the input initiator identity and the contract address in the contract call parameters, retrieve and output the corresponding trajectory data in the execution trajectory chain.

[0011] S1 further includes the following: In response to a cross-chain smart contract call request, obtain the initiator's identity identifier bound to the cross-chain smart contract call request; Extract the contract parameters defined in the cross-chain smart contract call request.

[0012] S2 further includes the following: Based on the cross-chain smart contract call request, determine the multiple predefined logical stages that this call must go through during the cross-chain execution process; The logical phases include the source chain phase, the cross-chain relay phase, and the target chain execution phase. During the execution of the cross-chain smart contract call request, when each logical stage is completed, the stage identifier and completion timestamp of that stage are collected. In each logical stage, the identity identifiers of the entities participating in the operation and verification in that stage are collected, forming the associated identity set for that stage; In each logical stage, the cryptographic hash value of the state data representing the operation result of that stage is collected to form the state hash set of that stage; According to the order of the completion timestamps, the stage identifier, completion timestamp, associated identity set and state hash set corresponding to each logical stage are combined and sorted to construct the process state sequence.

[0013] S3 further includes the following: Perform causal logic verification on the process state sequence; the causal logic verification includes timestamp order verification and state hash association verification; The timestamp order verification involves traversing each pair of adjacent stages in the process state sequence and checking whether the timestamp of the later stage is greater than the timestamp of the earlier stage. If all adjacent stages meet this condition, the timestamp order verification passes. The state hash association verification, for each pair of adjacent stages in the process state sequence, is denoted as stage A and stage B, where stage A is the previous stage and stage B is the next stage. Check whether there is at least one target hash value H in the state hash set of the check phase B, such that the target hash value H satisfies the preset hash derivation relationship; The preset hash derivation relationship is defined as follows: H = Hash(HA||HB||IDBstr); Wherein, HA is a source hash value in the state hash set of stage A; HB is the stage identifier for stage B; IDBstr is a string obtained by sorting and concatenating all identity identifiers in the associated identity set of stage B according to a predetermined rule; || represents the string concatenation operation; Hash represents a predefined cryptographic hash function; If both the timestamp order verification and the state hash association verification pass, then the process state sequence is determined to have passed the causal logic verification.

[0014] S4 further includes the following: The initiator's identity is converted into a string and then encoded into a byte sequence BSu using character encoding. The contract parameters are converted into strings and then encoded into byte sequences BSc using character encoding. The verified process state sequence is converted into a string and then encoded into a byte sequence BSp using character encoding. The byte sequences BSu, BSc, and BSP are concatenated in a preset order to obtain the concatenated byte sequence BSconcat. The cryptographic hash value Hcontent of the concatenated byte sequence BSconcat is calculated using the following formula: Hcontent = Hash(BSconcat); Where Hash represents a predefined cryptographic hash function; The cryptographic hash value Hcontent, the byte sequence BSu, BSc, and BSP are encapsulated together to generate the trajectory data unit.

[0015] S5 further includes the following: Get the chain hash value corresponding to the last successfully stored trajectory data unit, and denot it as the previous chain hash value Hprev; The content hash value of the trajectory data unit is denoted as the current content hash value Hcontent; The hash value Hprev of the preceding chain is concatenated with the hash value Hcontent of the current content to obtain the concatenation string Sconcat. Calculate the cryptographic hash value of the connection string Sconcat to obtain the chain hash value Hcurr stored this time. The calculation formula is as follows: Hcurr = Hash(Sconcat); Where Hash represents a predefined cryptographic hash function; The trajectory data unit is stored together with the chain hash value Hcurr, and the chain hash value Hcurr is updated to the preceding chain hash value used in the next storage, forming the execution trajectory chain linked in chronological order.

[0016] S6 further includes the following: Receive audit query requests and parse the query parameters in the audit query requests; Determine the type of the query parameters; If the query parameter is an identity identifier, then each stored trajectory data unit is traversed in the execution trajectory chain; For each trajectory data unit traversed, the byte sequence BSu contained therein is parsed to extract the initiator's identity identifier; The extracted initiator's identity identifier is compared with the query parameters; If the two match, the trajectory data unit is determined to be a match. If the query parameter is a contract address, then each stored trajectory data unit is traversed in the execution trajectory chain. For each trajectory data unit traversed, the byte sequence BSc contained therein is parsed, and the contract parameters are extracted from it; Extract the contract address from the contract parameters; The extracted contract address is compared with the query parameters; If the two match, the trajectory data unit is determined to be a match. All matching trajectory data units are used as the set of search results; For each trajectory data unit in the retrieval result set, the byte sequence BSP contained therein is parsed to obtain the process state sequence, and the byte sequence BSc contained therein is parsed to obtain the contract parameters; The obtained process state sequence is combined with the contract parameters to form the audit result for the audit query request and then output.

[0017] The cross-chain smart contract execution tracking system based on identity binding includes an identity identification acquisition module, a process data collection module, a causal logic verification module, a trajectory data generation module, a trajectory chain storage module, and a trajectory retrieval and auditing module. The identity acquisition module is responsible for receiving and parsing cross-chain smart contract call requests, extracting the initiator's identity and contract call parameters, and providing identity binding and execution context information for subsequent process tracking. During the execution of the cross-chain smart contract, the process data acquisition module is responsible for collecting stage identifiers, timestamps, participant identity sets, and state hash sets in real time at each predefined logical stage, and constructing a process state sequence in chronological order. The causal logic verification module performs logical consistency verification on the collected process state sequence, including timestamp order verification and state hash association verification. The trajectory data generation module is used to perform structured encoding and hash calculation on the initiator's identity identifier, contract parameters, and the verified process state sequence to generate a unique trajectory data unit. The trajectory chain storage module is used to store trajectory data units in a chain according to their generation time sequence, and form an immutable execution trajectory chain through hash linking. The trajectory retrieval and auditing module is used to respond to external audit requests, retrieve matching trajectory data in the execution trajectory chain according to query conditions, and output complete execution process information, supporting visual auditing and analysis.

[0018] Compared with the prior art, the beneficial effects of the present invention are: 1. By collecting stage identifiers, timestamps, participant identities, and state hashes at each logical stage, a complete process state sequence is constructed, solving the "verification black box" problem of missing information and difficulty in auditing the cross-chain execution process in existing technologies; 2. By storing trajectory data units sequentially as an execution trajectory chain through hash linking, the integrity and tamper-proof nature of trajectory data are guaranteed, while also supporting fast retrieval based on identity identifiers or contract addresses, greatly improving audit efficiency and credibility. Attached Figure Description

[0019] Figure 1 This is a flowchart of the cross-chain smart contract execution tracking method based on identity binding according to the present invention. Detailed Implementation

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

[0021] Example: Figure 1 As shown, the present invention provides a technical solution. The method for tracking the execution of cross-chain smart contracts based on identity binding includes the following steps: S1. Obtain the identity of the initiator of the cross-chain smart contract call request and the contract call parameters; S2. During the execution of the call request, in multiple predefined cross-chain logic stages, the stage identifier, timestamp, associated identity set and state hash set corresponding to each stage are collected, and a process state sequence is constructed in chronological order. S3. Perform causal logic verification on the process state sequence; the verification includes checking the timestamp order of adjacent stages in the sequence and checking whether there is a hash value in the state hash of the next stage that is logically related to the state hash of the previous stage. S4. Once the process state sequence is verified, a unique trajectory data unit is generated by combining the initiator's identity identifier with the contract call parameters. S5. Link and store the trajectory data units with historical trajectories according to the generation time sequence to form an execution trajectory chain; S6. In response to the audit request, based on the input initiator identity and the contract address in the contract call parameters, retrieve and output the corresponding trajectory data in the execution trajectory chain.

[0022] S1 further includes the following: In response to a cross-chain smart contract call request, obtain the initiator's identity identifier bound to the cross-chain smart contract call request; Extract the contract parameters defined in the cross-chain smart contract call request.

[0023] S2 further includes the following: Based on the cross-chain smart contract call request, determine the multiple predefined logical stages that this call must go through during the cross-chain execution process; The logical phases include the source chain phase, the cross-chain relay phase, and the target chain execution phase. During the execution of the cross-chain smart contract call request, when each logical stage is completed, the stage identifier and completion timestamp of that stage are collected. In each logical stage, the identity identifiers of the entities participating in the operation and verification in that stage are collected, forming the associated identity set for that stage; In each logical stage, the cryptographic hash value of the state data representing the operation result of that stage is collected to form the state hash set of that stage; According to the order of the completion timestamps, the stage identifier, completion timestamp, associated identity set and state hash set corresponding to each logical stage are combined and sorted to construct the process state sequence.

[0024] S3 further includes the following: Perform causal logic verification on the process state sequence; the causal logic verification includes timestamp order verification and state hash association verification; The timestamp order verification involves traversing each pair of adjacent stages in the process state sequence and checking whether the timestamp of the later stage is greater than the timestamp of the earlier stage. If all adjacent stages meet this condition, the timestamp order verification passes. The state hash association verification, for each pair of adjacent stages in the process state sequence, is denoted as stage A and stage B, where stage A is the previous stage and stage B is the next stage. Check whether there is at least one target hash value H in the state hash set of the check phase B, such that the target hash value H satisfies the preset hash derivation relationship; The preset hash derivation relationship is defined as follows: H = Hash(HA||HB||IDBstr); Wherein, HA is a source hash value in the state hash set of stage A; HB is the stage identifier for stage B; IDBstr is a string obtained by sorting and concatenating all identity identifiers in the associated identity set of stage B according to a predetermined rule; || represents the string concatenation operation; Hash represents a predefined cryptographic hash function; If both the timestamp order verification and the state hash association verification pass, then the process state sequence is determined to have passed the causal logic verification.

[0025] This method uses timestamp sequence verification and state hash association verification to check the temporal continuity and state derivation relationship between each stage, thereby identifying and eliminating abnormal or tampered execution paths. This analytical method enables automated verification of the inherent logical integrity of cross-chain call processes, providing reliable quality assurance for subsequent trajectory data generation and storage, and enhancing the credibility and authority of end-to-end audit results.

[0026] S4 further includes the following: The initiator's identity is converted into a string and then encoded into a byte sequence BSu using character encoding. The contract parameters are converted into strings and then encoded into byte sequences BSc using character encoding. The verified process state sequence is converted into a string and then encoded into a byte sequence BSp using character encoding. The byte sequences BSu, BSc, and BSP are concatenated in a preset order to obtain the concatenated byte sequence BSconcat. The cryptographic hash value Hcontent of the concatenated byte sequence BSconcat is calculated using the following formula: Hcontent = Hash(BSconcat); Where Hash represents a predefined cryptographic hash function; The cryptographic hash value Hcontent, the byte sequence BSu, BSc, and BSP are encapsulated together to generate the trajectory data unit.

[0027] This method integrates heterogeneous execution process information from multiple sources into indivisible data units by structurally encoding and hashing the initiator's identity, contract parameters, and verified process state sequences. Through this analysis method, standardized encapsulation and trusted digest generation of cross-chain call process information are achieved, ensuring that each cross-chain transaction can be uniquely identified and its content is tamper-proof, providing a reliable data foundation for subsequent chain-based storage and audit traceability.

[0028] S5 further includes the following: Get the chain hash value corresponding to the last successfully stored trajectory data unit, and denot it as the previous chain hash value Hprev; The content hash value of the trajectory data unit is denoted as the current content hash value Hcontent; The hash value Hprev of the preceding chain is concatenated with the hash value Hcontent of the current content to obtain the concatenation string Sconcat. Calculate the cryptographic hash value of the connection string Sconcat to obtain the chain hash value Hcurr stored this time. The calculation formula is as follows: Hcurr = Hash(Sconcat); Where Hash represents a predefined cryptographic hash function; The trajectory data unit is stored together with the chain hash value Hcurr, and the chain hash value Hcurr is updated to the preceding chain hash value used in the next storage, forming the execution trajectory chain linked in chronological order.

[0029] This method iteratively hashes the chain hash value of the previous trajectory data unit with the content hash value of the current trajectory data unit, forming a cryptographic association between the units according to their generation sequence. Through this analysis method, strict order and logical coherence of the trajectory data in the time dimension are achieved, ensuring the integrity and consistency of the entire chain of data and forming a globally verifiable and tamper-proof execution trajectory record chain.

[0030] S6 further includes the following: Receive audit query requests and parse the query parameters in the audit query requests; Determine the type of the query parameters; If the query parameter is an identity identifier, then each stored trajectory data unit is traversed in the execution trajectory chain; For each trajectory data unit traversed, the byte sequence BSu contained therein is parsed to extract the initiator's identity identifier; The extracted initiator's identity identifier is compared with the query parameters; If the two match, the trajectory data unit is determined to be a match. If the query parameter is a contract address, then each stored trajectory data unit is traversed in the execution trajectory chain. For each trajectory data unit traversed, the byte sequence BSc contained therein is parsed, and the contract parameters are extracted from it; Extract the contract address from the contract parameters; The extracted contract address is compared with the query parameters; If the two match, the trajectory data unit is determined to be a match. All matching trajectory data units are used as the set of search results; For each trajectory data unit in the retrieval result set, the byte sequence BSP contained therein is parsed to obtain the process state sequence, and the byte sequence BSc contained therein is parsed to obtain the contract parameters; The obtained process state sequence is combined with the contract parameters to form the audit result for the audit query request and then output.

[0031] The cross-chain smart contract execution tracking system based on identity binding includes an identity identification acquisition module, a process data collection module, a causal logic verification module, a trajectory data generation module, a trajectory chain storage module, and a trajectory retrieval and auditing module. The identity acquisition module is responsible for receiving and parsing cross-chain smart contract call requests, extracting the initiator's identity and contract call parameters, and providing identity binding and execution context information for subsequent process tracking. During the execution of the cross-chain smart contract, the process data acquisition module is responsible for collecting stage identifiers, timestamps, participant identity sets, and state hash sets in real time at each predefined logical stage, and constructing a process state sequence in chronological order. The causal logic verification module performs logical consistency verification on the collected process state sequence, including timestamp order verification and state hash association verification. The trajectory data generation module is used to perform structured encoding and hash calculation on the initiator's identity identifier, contract parameters, and the verified process state sequence to generate a unique trajectory data unit. The trajectory chain storage module is used to store trajectory data units in a chain according to their generation time sequence, and form an immutable execution trajectory chain through hash linking. The trajectory retrieval and auditing module is used to respond to external audit requests, retrieve matching trajectory data in the execution trajectory chain according to query conditions, and output complete execution process information, supporting visual auditing and analysis.

[0032] The identity-based cross-chain smart contract execution tracking system and method aim to address the verification black box problem caused by the lack of process information in the current cross-chain environment. This system collects and structures execution process data at each key logic stage, constructing a verifiable and tamper-proof end-to-end trajectory record, thereby supporting efficient and reliable auditing and traceability. The following specific implementation example will illustrate in detail the operation mechanism and implementation process of this system and method.

[0033] Example 1:

[0034] The core idea of ​​identity-based cross-chain smart contract execution tracking technology lies in the full-process, verifiable data solidification and traceability of the execution process involving multiple stages and multiple participants. This concept is not only applicable to blockchain cross-chain scenarios, but can also effectively solve the problems of information opacity and traceability in traditional enterprise processes, especially in the complex audit scenarios of large groups. The following will use the annual comprehensive expense reimbursement audit of a large group as an example to illustrate in detail the application and implementation process of this technology system.

[0035] In large groups, annual comprehensive expense reimbursement audits involve massive amounts of documents, multiple levels of approval departments, and complex financial rules. Traditional auditing methods rely on manual verification of scattered system logs and paper vouchers, which is inefficient and easily creates an "audit black box." After implementing this system, the entire reimbursement process has been restructured into a traceable digital execution chain. When employee Zhang San initiates a travel expense reimbursement, the system's identity acquisition module first captures the request and extracts the unique identity bound to it—the employee ID "EMP1001." At the same time, it parses the reimbursement application parameters, including the reimbursement type "travel expense," the amount "5000 yuan," and the attached list of electronic invoice IDs.

[0036] Subsequently, the process data acquisition module begins operation. Based on the pre-defined reimbursement process logic stages, the system divides this reimbursement into: submission stage, departmental review stage, financial review stage, and payment execution stage. In the submission stage, when Zhang San completes the submission in the OA system, the module collects the stage identifier "SUBMIT", the timestamp "2023-11-01 10:00:00", the associated identity set (submitter "EMP1001"), and the status hash set for this stage. This set contains the hash of the submitted form and the hash values ​​of all uploaded electronic invoices, denoted as "HashSet_Submit". When the process enters the departmental review stage, after manager Li Si completes the approval, the module collects the identifier "DEPT_APPROVE", the timestamp "2023-11-01 14:30:00", the associated identity set (approver "EMP2001"), and the status hash set "HashSet_Dept" containing the approval comments and results. The financial review and payment stages also collect corresponding data accordingly. Ultimately, all the data is combined in chronological order to form a sequence of the process statuses for this reimbursement application.

[0037] To ensure the compliance and logical consistency of the process, the causal logic verification module automatically verifies the above sequence. The timestamp sequence verification first confirms that the departmental review time is later than the submission time, the financial review time is later than the departmental review time, and the payment time is the latest, ensuring the reasonableness of the process progression on the timeline. Next, a crucial state hash association verification is performed. Taking the "submission stage" (stage A) and the "departmental review stage" (stage B) as examples, the system selects a source hash value HA (e.g., representing the hash of the submitted form) from HashSet_Submit, combines it with the stage B identifier "DEPT_APPROVE" and its associated identity set concatenation string "EMP2001", and calculates a target hash value H according to the preset formula H=Hash(HA||"DEPT_APPROVE"||"EMP2001"). If this H value exists in HashSet_Dept, it proves that the departmental review behavior is based on the specific form content submitted by Zhang San, and there is an immutable logical causal relationship between the two stages. Only after all adjacent stages pass this type of verification is the reimbursement process sequence deemed logically credible.

[0038] The trajectory data generation module then encodes the verified reimbursement process status sequence, along with the initiating employee's identification "EMP1001" and reimbursement parameters (type, amount, etc.), into byte sequences BSp, BSu, and BSc, respectively. These byte sequences are then concatenated, their cryptographic hash value Hcontent is calculated, and a unique trajectory data unit is generated. This unit acts as a "digital portfolio" for this reimbursement, fully encapsulating snapshots of all key processes from initiation and approval to execution, and possesses uniqueness and tamper-proof properties due to its hash fingerprint.

[0039] The trajectory chain storage module is responsible for storing this "file folder" into the group's audit trajectory chain. The system obtains the chain hash value Hprev (let's say "a1b2c3...") of the previous stored item on the chain, concatenates it with the content hash Hcontent of the current unit, and calculates the new chain hash value Hcurr=Hash("a1b2c3..."||Hcontent). The current trajectory data unit is stored together with Hcurr, and Hcurr becomes a pointer to the next unit. In this way, all expense reimbursement transactions in the entire group are hashed and linked into a continuous "ledger-style" execution trajectory chain in chronological order of occurrence. Any attempt to tamper with intermediate records will cause all subsequent chain hashes to become invalid, thus ensuring the integrity and reliability of the global historical record.

[0040] The trajectory retrieval and audit module plays a crucial role during annual comprehensive audits or special audits. Auditors can input query criteria, such as employee ID "EMP1001" or reimbursement type "travel expenses." The module traverses the execution trajectory chain, quickly locating all matching trajectory data units. For example, after retrieving Zhang San's travel expense reimbursement unit, the system parses out the complete process status sequence, clearly displaying it in a visual timeline format: when it was submitted, which manager approved it, the financial review result, the final payment time, and the corresponding electronic voucher hash for each step. This allows auditors to instantly penetrate the departmental and system silos of traditional audits, directly tracing the complete lifecycle of any reimbursement and all responsible parties involved, greatly improving audit efficiency, accuracy, and credibility.

[0041] In summary, by applying this tracking system to the expense reimbursement audit scenario of a large group, the originally loose and opaque multi-stage approval process has been transformed into a rigorous, interconnected, and globally verifiable digital trajectory chain. This is not merely a simple application of technical tools, but a revolution in process governance paradigms. Without altering existing approval authority and efficiency, it brings unprecedented process transparency, audit credibility, and risk control capabilities to the group, effectively solving the supervision and traceability dilemmas in the complex processes of large organizations.

[0042] Example 2:

[0043] We will now consider the following scenarios to verify the adaptability of the present invention; When employee Zhang San initiates a travel expense reimbursement, the system's identity acquisition module captures his employee ID "EMP1001" and reimbursement parameters. The process data acquisition module then collects data in four preset logical stages (submission, departmental review, financial review, and payment).

[0044] Under normal circumstances, the original timestamps collected should be: submission time T1 (November 1, 10:00 AM), department review time T2 (November 1, 2:30 PM), financial review time T3 (November 2, 9:15 AM), and payment time T4 (November 3, 4:00 PM). The associated identity set and state hash set are also generated synchronously.

[0045] Scenario 1: Timestamp sequence verification fails Suppose an anomaly occurs during data collection or transmission, causing the system to incorrectly record the "financial review timestamp T3'" as "November 1st, 09:00," earlier than the "department review time T2 (14:30)." When the causal logic verification module verifies the timestamp order of the sequence, it will find that T3' (09:00) is less than T2 (14:30) when checking the adjacent stages of "department review stage" and "financial review stage," violating the basic causal law that "the later time must be greater than the earlier time." The verification module will immediately determine that this process state sequence has failed the timestamp order verification. The system will mark the reimbursement as "time sequence abnormal," preventing it from entering the subsequent trajectory generation and storage stages, and automatically trigger an alarm to notify auditors to intervene and verify whether it is a system error or an unauthorized advance approval.

[0046] Scenario 2: State hash association verification fails Assuming the timestamp order is correct, someone attempts to tamper with the process data. For example, after department manager Li Si (employee ID EMP2001) approves the application, someone maliciously modifies Zhang San's initial reimbursement amount, attempting to change 5000 yuan to 8000 yuan, and recalculates the hash value of the submitted form. Therefore, the original state hash set HashSet_Submit (containing the hash corresponding to the amount of 5000 yuan) collected during the "submission phase" is inconsistent with the baseline data transmitted to the "department review phase."

[0047] When the verification module performs state hash association verification, for the "Submission Stage" (A) and the "Department Review Stage" (B), it retrieves the source hash value HA representing the original submission content from HashSet_Submit, concatenates it with the stage B identifier "DEPT_APPROVE" and the approver's identity "EMP2001", and calculates the target hash H = Hash(HA||"DEPT_APPROVE"||"EMP2001"). Since the state hash set HashSet_Dept recorded in the department review stage is generated based on the tampered submission data (8000 yuan), the calculated H value cannot be found in HashSet_Dept. The association verification fails. The system determines that this process sequence has a "broken logical chain," indicating suspected data tampering, and therefore refuses to generate a reliable trace for it, recording and reporting this event as a high-risk audit clue.

[0048] Comprehensive Scenario: Normal Process After Verification The process is only considered trustworthy when the time sequence and hash association are all verified. For example, if all timestamps are logically correct and the state hashes at each stage strictly follow the derivation relationship (i.e., the hash for departmental review is based on the original submission, and the hash for financial review is based on the result of departmental review), the verification module will output a pass signal.

[0049] Subsequently, the trajectory data generation module packages this verified "clean" sequence with the identity and parameters to generate a unique trajectory data unit. The trajectory chain storage module links it to the preceding hash value on the chain, forming an immutable and permanent record. When auditors retrieve all expense reimbursements for "EMP1001," the system can quickly and reliably provide its complete and credible process trajectory. For those abnormal records that fail verification, the system provides a separate "abnormal event database" for auditors to investigate in depth.

[0050] As can be seen from the above examples, including both positive and negative cases, this system does not passively record all data, but proactively uses cryptography and logical rules to audit the integrity of processes in real time. It transforms the traditional "post-event audit" into "in-process verification" that runs parallel to business processes. While ensuring that the actual process is reliably recorded, it also accurately identifies various anomalies such as time sequence errors and data tampering, thus building an intelligent audit infrastructure for large groups that combines transparency, credibility, and proactive risk control capabilities.

[0051] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for tracking the execution of cross-chain smart contracts based on identity binding, characterized in that: Includes the following steps: S1. Obtain the identity identifier of the initiator of the cross-chain smart contract call request and the contract call parameters; S2. During the execution of the call request, in multiple predefined cross-chain logic stages, the stage identifier, timestamp, associated identity set and state hash set corresponding to each stage are collected, and a process state sequence is constructed in chronological order. S3. Perform causal logic verification on the process state sequence; the verification includes checking the timestamp order of adjacent stages in the sequence and checking whether there is a hash value in the state hash of the next stage that is logically related to the state hash of the previous stage. S4. Once the process state sequence is verified, a unique trajectory data unit is generated by combining the initiator's identity identifier with the contract call parameters. S5. Link and store the trajectory data units with historical trajectories according to their generation time sequence to form an execution trajectory chain; S6. In response to the audit request, based on the input initiator identity and the contract address in the contract call parameters, retrieve and output the corresponding trajectory data in the execution trajectory chain.

2. The cross-chain smart contract execution tracking method based on identity binding according to claim 1, characterized in that: S1 further includes the following: In response to a cross-chain smart contract call request, obtain the initiator's identity identifier bound to the cross-chain smart contract call request; Extract the contract parameters defined in the cross-chain smart contract call request.

3. The cross-chain smart contract execution tracking method based on identity binding according to claim 1, characterized in that: S2 further includes the following: Based on the cross-chain smart contract call request, determine the multiple predefined logical stages that this call must go through during the cross-chain execution process; The logical phases include the source chain phase, the cross-chain relay phase, and the target chain execution phase. During the execution of the cross-chain smart contract call request, when each logical stage is completed, the stage identifier and completion timestamp of that stage are collected; In each logical stage, the identity identifiers of the entities participating in the operation and verification in that stage are collected, forming the associated identity set for that stage; In each logical stage, the cryptographic hash value of the state data representing the operation result of that stage is collected to form the state hash set of that stage; According to the order of the completion timestamps, the stage identifier, completion timestamp, associated identity set and state hash set corresponding to each logical stage are combined and sorted to construct the process state sequence.

4. The cross-chain smart contract execution tracking method based on identity binding according to claim 1, characterized in that: S3 further includes the following: Perform causal logic verification on the process state sequence; the causal logic verification includes timestamp order verification and state hash association verification; The timestamp order verification involves traversing each pair of adjacent stages in the process state sequence and checking whether the timestamp of the later stage is greater than the timestamp of the earlier stage. If all adjacent stages meet this condition, the timestamp order verification passes. The state hash association verification, for each pair of adjacent stages in the process state sequence, is denoted as stage A and stage B, where stage A is the previous stage and stage B is the next stage. Check whether there is at least one target hash value H in the state hash set of the check phase B, such that the target hash value H satisfies the preset hash derivation relationship; The preset hash derivation relationship is defined as follows: H = Hash(HA||HB||IDBstr); Wherein, HA is a source hash value in the state hash set of stage A; HB is the stage identifier for stage B; IDBstr is a string obtained by sorting and concatenating all identity identifiers in the associated identity set of stage B according to a predetermined rule; || represents the string concatenation operation; Hash represents a predefined cryptographic hash function; If both the timestamp order verification and the state hash association verification pass, then the process state sequence is determined to have passed the causal logic verification.

5. The cross-chain smart contract execution tracking method based on identity binding according to claim 2, characterized in that: S4 further includes the following: The initiator's identity is converted into a string and then encoded into a byte sequence BSu using character encoding. The contract parameters are converted into strings and then encoded into byte sequences BSc using character encoding. The verified process state sequence is converted into a string and then encoded into a byte sequence BSp using character encoding. The byte sequences BSu, BSc, and BSP are concatenated in a preset order to obtain the concatenated byte sequence BSconcat. The cryptographic hash value Hcontent of the concatenated byte sequence BSconcat is calculated using the following formula: Hcontent = Hash(BSconcat); Where Hash represents a predefined cryptographic hash function; The cryptographic hash value Hcontent, the byte sequence BSu, BSc, and BSP are encapsulated together to generate the trajectory data unit.

6. The cross-chain smart contract execution tracking method based on identity binding according to claim 5, characterized in that: S5 further includes the following: Get the chain hash value corresponding to the last successfully stored trajectory data unit, and denot it as the previous chain hash value Hprev; The content hash value of the trajectory data unit is denoted as the current content hash value Hcontent; The hash value Hprev of the preceding chain is concatenated with the hash value Hcontent of the current content to obtain the concatenation string Sconcat. Calculate the cryptographic hash value of the connection string Sconcat to obtain the chain hash value Hcurr stored this time. The calculation formula is as follows: Hcurr = Hash(Sconcat); Where Hash represents a predefined cryptographic hash function; The trajectory data unit is stored together with the chain hash value Hcurr, and the chain hash value Hcurr is updated to the preceding chain hash value used in the next storage, forming the execution trajectory chain linked in chronological order.

7. The cross-chain smart contract execution tracking method based on identity binding according to claim 5, characterized in that: S6 further includes the following: Receive audit query requests and parse the query parameters in the audit query requests; Determine the type of the query parameters; If the query parameter is an identity identifier, then each stored trajectory data unit is traversed in the execution trajectory chain; For each trajectory data unit traversed, the byte sequence BSu contained therein is parsed to extract the initiator's identity identifier; The extracted initiator's identity identifier is compared with the query parameters; If the two match, the trajectory data unit is determined to be a match. If the query parameter is a contract address, then each stored trajectory data unit is traversed in the execution trajectory chain. For each trajectory data unit traversed, the byte sequence BSc contained therein is parsed, and the contract parameters are extracted from it; Extract the contract address from the contract parameters; The extracted contract address is compared with the query parameters; If the two match, the trajectory data unit is determined to be a match. All matching trajectory data units are used as the set of search results; For each trajectory data unit in the retrieval result set, the byte sequence BSP contained therein is parsed to obtain the process state sequence, and the byte sequence BSc contained therein is parsed to obtain the contract parameters; The obtained process state sequence is combined with the contract parameters to form the audit result for the audit query request and then output.

8. A cross-chain smart contract execution tracing system based on identity binding, applied to the cross-chain smart contract execution tracing method based on identity binding as described in any one of claims 1-7, characterized in that: It includes an identity acquisition module, a process data acquisition module, a causal logic verification module, a trajectory data generation module, a trajectory chain storage module, and a trajectory retrieval and auditing module; The identity acquisition module is responsible for receiving and parsing cross-chain smart contract call requests, extracting the initiator's identity and contract call parameters, and providing identity binding and execution context information for subsequent process tracking. During the execution of the cross-chain smart contract, the process data acquisition module is responsible for collecting stage identifiers, timestamps, participant identity sets, and state hash sets in real time at each predefined logical stage, and constructing a process state sequence in chronological order. The causal logic verification module performs logical consistency verification on the collected process state sequence, including timestamp order verification and state hash association verification. The trajectory data generation module is used to perform structured encoding and hash calculation on the initiator's identity identifier, contract parameters, and the verified process state sequence to generate a unique trajectory data unit. The trajectory chain storage module is used to store trajectory data units in a chain according to their generation time sequence, and form an immutable execution trajectory chain through hash linking. The trajectory retrieval and auditing module is used to respond to external audit requests, retrieve matching trajectory data in the execution trajectory chain according to query conditions, and output complete execution process information, supporting visual auditing and analysis.

Images