Intelligent financial auditing system based on blockchain cross-validation

Abstract

The application belongs to the technical field of block chain, and provides an intelligent financial auditing system based on cross-validation of block chain, which comprises: a space-time anchoring calibration module, a cross-chain calibration node is deployed, a cross-chain unified time reference is output through a consensus algorithm and is synchronized to chain A and chain B; a multi-dimensional state proof module, chain A generates a space-time anchoring hash and a signature list, chain B confirms the asset locking state through triple verification of hash consistency, signature validity and time validity; a dynamic time window adjustment module, a historical delay library is built to calculate the initial time lock of chain A, and the time lock of chain B is dynamically adjusted; a cross-chain consensus detection module, the chain B verification node judges the asset state between chains based on RAFT consensus, and when an exception occurs, asset freezing, original route return and attacker blacklist marking are triggered; time synchronization error can be eliminated, repeated transfer attacks can be prevented, and the security, accuracy and real-time performance of cross-chain financial auditing can be improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of blockchains, and in particular to an intelligent financial audit system based on cross-verification of blockchains. BACKGROUND

[0002] In cross-chain asset transfer between the Ethereum chain and a heterogeneous target chain, nodes of both parties are distributed in different time zones and need to cooperate to complete asset locking, state synchronization and unlocking to ensure operation compliance and safety. However, the existing technology has significant defects, specifically as follows:

[0003] Cross-time zone + network delay amplifies time synchronization error: the local clock of the cross-time zone node initially has a time zone deviation, the existing cross-chain time synchronization only relies on simple timestamp transmission, and no reference calibration is designed for cross-time zones; superimposed on the cross-regional network round-trip delay, further aggravating the time synchronization error, forming a double time difference of time zone deviation + network delay.

[0004] Attackers use errors to fake states to implement repeated transfers: cross-chain asset transfer requires that the Ethereum chain asset has been locked as a prerequisite, but the above time error causes the target chain to have a lag in the Ethereum chain state. Attackers can tamper with the Ethereum chain asset locking timestamp and fake an unlocked state, causing the target chain to misjudge that the asset is not locked, thereby achieving cross-chain repeated transfer of the same asset.

[0005] Existing audit mechanisms cannot defend against such attacks: current cross-chain audits only focus on data hash verification or single-chain state verification, there is no unified cross-chain time reference, and no dynamic error compensation mechanism is designed, which cannot distinguish between legitimate synchronization delay and fake time difference, and it is difficult to identify repeated transfer attacks.

[0006] The lack of node time control exacerbates the risk: the time control of the Ethereum chain and the target chain nodes is independent, there is no cross-chain time consistency supervision, and some nodes may amplify errors due to clock tampering or configuration errors, causing fake states to be successfully synchronized to the target chain.

[0007] Therefore, the present application provides an intelligent financial audit system based on cross-verification of blockchains. SUMMARY

[0008] In order to make up for the deficiencies of the existing technology and solve at least one of the technical problems raised in the background art.

[0009] The technical solution adopted by the present application to solve its technical problems is:

[0010] On the one hand, the present application provides an intelligent financial audit system based on cross-verification of blockchains, comprising:

[0011] The space-time anchoring calibration module deploys cross-chain calibration nodes, outputs a cross-chain unified time reference through a consensus algorithm, and synchronizes the cross-chain unified time reference to smart contracts of chain A and chain B.

[0012] The multi-dimensional state proof module: when the smart contract of chain A is locked, a space-time anchoring hash is generated, and a signature list is generated through the cross-chain calibration node; when the smart contract of chain B is unlocked and receives a cross-chain message, chain B needs to perform consistency verification of the space-time anchoring hash, validity verification of the signature list, and time validity verification to confirm the locking state.

[0013] The dynamic time window adjustment module: a historical delay database is constructed to calculate the initial time lock of chain A, and the unlocking time lock of chain B is adjusted according to real-time delay monitoring.

[0014] The cross-chain consensus detection module: a verification node of chain B is constructed to intercept cross-chain asset repeated transfer attacks in real time; the verification node obtains the space-time anchoring hash synchronized by chain A, the hash original image generation time, and the operation signature list through the cross-chain oracle, and makes a cross-chain asset state consistency judgment based on the RAFT consensus algorithm; if no less than two-thirds of the verification nodes confirm that the asset states of chain A and chain B are inconsistent, the defense mechanism of asset freezing, asset original route return, and attacker address black list marking is triggered.

[0015] In the present application, the specific process of deploying cross-chain calibration nodes is as follows:

[0016] The cross-chain calibration nodes are deployed using a geographical distributed architecture, and are distributed in different time zones and different geographical locations. Each cross-chain calibration node is integrated and includes a physical time source unit, an on-chain timestamp reading unit, and a cross-chain round-trip delay RTT measurement unit.

[0017] In the present application, the specific process of outputting the cross-chain unified time reference is as follows:

[0018] The consensus leader node collects the physical time of all cross-chain calibration nodes, the on-chain timestamps of chain A and chain B, and the cross-chain round-trip delay RTT data, and performs calculation and processing on the physical time of the cross-chain calibration nodes, the on-chain timestamps of chain A and chain B, and the cross-chain round-trip delay RTT data to obtain the cross-chain unified time reference.

[0019] In the present application, the specific process of obtaining the cross-chain unified time reference includes:

[0020] The physical time of the cross-chain calibration node is weighted by the physical time weight of the GPS clock device, which is 0.9, and the physical time weight of the time source, which is 0.1, to obtain a weighted average physical time reference.

[0021] The deviation value of the original on-chain time stamp of chain A and chain B from the weighted average physical time reference is calculated to obtain a chain A time drift amount and a chain B time drift amount; the original on-chain time stamp of chain A and chain B is respectively subtracted by the chain A time drift amount and the chain B time drift amount to obtain a chain A alignment time and a chain B alignment time;

[0022] The arithmetic mean of the cross-chain round-trip delay RTT data after removing one maximum value and one minimum value is obtained to obtain effective cross-chain round-trip delay RTT data; the one-way delay = effective cross-chain round-trip delay RTT data ÷ 2 + effective cross-chain round-trip delay RTT data × 10%, wherein effective cross-chain round-trip delay RTT data × 10% is a delay fluctuation compensation value; the chain B delay compensation time is obtained by superimposing the one-way delay on the basis of the chain A alignment time, and the arithmetic mean of the chain B delay compensation time and the chain B alignment time is taken to output the cross-chain unified time reference.

[0023] In the application, the specific process of synchronizing the cross-chain unified time reference to the smart contract of chain A and chain B is as follows:

[0024] The consensus leader node synchronizes the cross-chain unified time reference to the smart contract of chain A and chain B through the smart contract calling interface;

[0025] After receiving the cross-chain unified time reference, the smart contract of chain A and chain B takes the cross-chain unified time reference as the unified time reference for cross-chain financial operation.

[0026] In the application, the specific process of generating the space-time anchor hash when the chain A locking smart contract locks assets is as follows:

[0027] When the user initiates a financial asset locking operation on chain A, the cross-chain unified time reference, the locking block height, the node geographic location hash and the hash original image generation time are obtained, and the cross-chain unified time reference, the locking block height, the node geographic location hash and the hash original image generation time are spliced in a fixed order to obtain the space-time anchor hash through the SHA-256 algorithm.

[0028] In the application, the specific process of verifying and confirming the locking state is as follows:

[0029] Space-time anchor hash consistency verification: send a verification request containing chain A original parameters to the calibration node cluster of the space-time anchor calibration module, if no less than two-thirds of the calibration nodes return hash verification value = hash locking value, it is confirmed to be consistent, otherwise the unlocking is terminated;

[0030] Signature list validity verification: extract the signature node public key, check whether it is in the authorized calibration node list, and use the public key to verify the signature to confirm that the space-time anchor hash corresponding to the signature is not tampered with, and the unlocking is terminated if any signature is invalid or the node is not authorized;

[0031] Time validity verification: calculate the relative time of chain B = current time of chain B - cross-chain unified time reference; obtain the dynamic delay threshold of chain A and chain B; if the hash image generation time + dynamic delay threshold >= relative time, it means that the hash image generation time is within a reasonable delay range; otherwise, terminate the unlocking process;

[0032] If the spatio-temporal anchor hash consistency verification, time validity verification, and signature list validity verification are passed, the unlocking operation of the corresponding asset is performed; if any verification fails, the cross-chain message is marked as abnormal, triggering asset freezing and sending a warning to the audit system.

[0033] In the present application, the specific process of calculating the initial time lock of chain A is:

[0034] Build a historical delay database: send a delay probe packet with a timestamp to chain A and chain B every 5 minutes, record the cross-chain round-trip delay RTT data between chain A and chain B, and store all cross-chain round-trip delay RTT data in the past 24 hours in the format of timestamp + cross-chain round-trip delay RTT data;

[0035] Extract time lock parameters: arrange all cross-chain round-trip delay RTT data values in the past 24 hours in ascending order, and take the middle value and the value at the 95th position;

[0036] Calculate the initial time lock of chain A: set the base time lock based on the type of financial asset, and the adjustment coefficient k based on network stability; read the value at the 95th position of the historical delay database every 10 minutes, and calculate the initial time lock of chain A according to the formula chain A initial time lock = base time lock + k x value at the 95th position.

[0037] In the present application, the specific process of real-time interception of cross-chain asset repeated transfer attacks is:

[0038] The verification nodes are screened from the cross-chain calibration nodes of the spatio-temporal anchor calibration module, and need to meet the following conditions: the number of nodes is odd, and the geographical distribution is consistent with the cross-chain calibration nodes;

[0039] Node operation authority is controlled through chain B smart contract, only authorized verification nodes can participate in asset state consistency judgment, and the voting results of unauthorized verification nodes are automatically invalidated.

[0040] In the present application, the specific process of achieving cross-chain asset state consistency judgment based on RAFT consensus algorithm is:

[0041] A cross-chain oracle is deployed between chain A and chain B, and every 3 seconds, the latest spatiotemporal anchor hash set of chain A, the corresponding hash image generation time and the cross-chain calibration node signature list are synchronized from the chain A lock smart contract, and the synchronization is accompanied by an oracle signature and a timestamp; after receiving the data, the chain B verification node verifies the validity of the oracle signature, converts the chain A block height and the hash image generation time into the chain B time context, and indexes according to the asset ID;

[0042] The chain B verification node elects a consensus leader every 5 minutes through the RAFT algorithm, and the leader is responsible for initiating the state judgment task; when the chain B unlocking smart contract receives a cross-chain asset transfer request, it sends a judgment request to the leader, the leader broadcasts the task, each node independently executes hash matching verification, signature and time verification, chain B state verification based on local chain A data and chain B state, and submits the results; if no less than two-thirds of the nodes determine that the state is consistent, the unlocking is allowed, and if no less than two-thirds of the nodes determine that the state is inconsistent, an abnormal conclusion is generated;

[0043] If the consensus conclusion is abnormal, the chain B unlocking smart contract automatically freezes the target asset and records the freezing information, sends a return request containing abnormal evidence to chain A through the cross-chain oracle, and after verification, returns the asset to the original user account; at the same time, chain B extracts the attacker address and writes it into the on-chain blacklist, and periodically broadcasts the blacklist for cooperative defense.

[0044] On the other hand, the present application provides a smart financial auditing method based on cross-validation of blockchains, comprising:

[0045] S10: Deploy a cross-chain calibration node, output a cross-chain unified time reference through a consensus algorithm, and synchronize the cross-chain unified time reference to the smart contracts of chain A and chain B;

[0046] S20: When the chain A lock smart contract is locked, a spatiotemporal anchor hash is generated, and a signature list is generated through the cross-chain calibration node; when the chain B unlocking smart contract receives a cross-chain message, chain B needs to perform spatiotemporal anchor hash consistency verification, signature list validity verification, and time validity verification to confirm the locking state;

[0047] S30: Construct a historical delay database for calculating the initial time lock of chain A, and adjust the unlocking time lock of chain B according to real-time delay monitoring;

[0048] S40: Construct a verification node of chain B for real-time interception of cross-chain asset repeated transfer attacks; the verification node obtains the spatiotemporal anchor hash, hash image generation time and operation signature list of chain A through the cross-chain oracle, and reaches a cross-chain asset state consistency judgment based on the RAFT consensus algorithm; if no less than two-thirds of the verification nodes confirm that the asset states of chain A and chain B are inconsistent, the defense mechanism of asset freezing, asset return and attacker address blacklist marking is triggered.

[0049] The beneficial effects of the present application are as follows:

[0050] 1. Precise elimination of cross-time zone cross-chain time synchronization error, guaranteeing the uniformity of the audit time reference The design of the time and space anchoring calibration module in the embodiment combines the physical time of the GPS clock and the local high-precision clock collected by the geographically distributed cross-chain calibration nodes to obtain a high-authority reference through weighted averaging; then reduces the time deviation of chain A and chain B through on-chain time drift correction and RTT one-way delay compensation; this design completely solves the problem of double time error of time zone deviation + network delay of cross-time zone nodes, provides a unified and precise time reference for cross-chain financial audit, and avoids misjudgment of the audit caused by different time synchronization; multi-dimensional cross-validation improves the credibility of asset status, and resists parameter tampering attacks In the multi-dimensional state proof module, chain A generates a SHA-256 time and space anchoring hash based on four types of parameters such as cross-chain unified time reference and locked block height, which is signed and endorsed by the cross-chain calibration node; after receiving the message, chain B confirms the state through three verification confirmations of hash consistency, signature validity, and time validity. This mechanism forms a cross-defense of parameter hashing + multi-node signature + inter-chain verification, effectively resisting the risk of attackers forging asset status and tampering with timestamps, and ensuring the authenticity and tamper resistance of the audit data.

[0051] 2. Dynamic time window adaptation to network delay fluctuations, balancing audit security and real-time performance The dynamic time window adjustment module extracts the median and 95th percentile of RTT from the 24-hour historical delay library, sets the basic time lock according to the type of financial assets, and dynamically adjusts the unlocking time window of chain B according to the real-time deviation rate to avoid timeout failure of legal operations; when the delay decreases, the time window is shortened to improve the efficiency of the audit. This design solves the problem of overstrictness and overlooseness of fixed time window, and balances security and real-time performance; distributed consensus + three-level defense mechanism, efficiently intercepts cross-chain repeated transfer attacks The cross-chain consensus detection module uses an odd number of verification nodes, elects a high-reputation leader every 5 minutes based on RAFT consensus, and performs three checks of hash matching + signature time + chain B state on cross-chain asset status. If it is determined to be abnormal, trigger the three defenses of asset freezing, return to the original route, and blacklist marking. In combination with the embodiment scenario, the forged unlocked state of the attacker using time error can be identified in real time, and the whole process from consensus judgment to defense response is automated, effectively avoiding financial losses caused by repeated transfer of the same asset. BRIEF DESCRIPTION OF DRAWINGS

[0052] The present application will be further described below with reference to the accompanying drawings.

[0053] Figure 1 is the step flow chart of the intelligent financial audit system based on block chain cross-validation of the present application;

[0054] Figure 2 is the system module diagram of the present application. Detailed Implementation

[0055] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0056] Example 1

[0057] like Figure 1 As shown in the embodiment of the present invention, a method for annotating audio and video recorder recording files includes:

[0058] Spatiotemporal anchoring calibration module: Deploys cross-chain calibration nodes, outputs a unified cross-chain time base through a consensus algorithm, and synchronizes the unified cross-chain time base to the smart contracts of chain A and chain B;

[0059] In the spatiotemporal anchoring module, the specific process of deploying cross-chain calibration nodes is as follows:

[0060] Cross-chain calibration nodes are deployed using a geographically distributed architecture, with nodes located in different time zones and geographical locations to ensure comprehensive awareness and coverage of network latency for Chain A and Chain B. Each cross-chain calibration node is an independent server device with stable network connectivity and data processing capabilities.

[0061] Each cross-chain calibration node integrates three core functional units, including:

[0062] Physical time source unit: Equipped with a GPS clock device, it directly acquires high-precision physical time as a basic reference for time calibration;

[0063] On-chain timestamp reading unit: Through blockchain API interfaces (such as Ethereum web3 interface), it reads the block timestamps of chain A and chain B in real time, records the on-chain timestamp information of chain A and chain B, and uses it to analyze the consistency and deviation of on-chain time;

[0064] Cross-chain round-trip time (RTT) measurement unit: Sends timestamp requests to chain A and chain B respectively and records the response time, calculates the round-trip time of data transmission between chain A and chain B, and quantifies the specific value of network latency;

[0065] In the spatiotemporal anchoring module, the specific process of outputting a unified cross-chain time base through a consensus algorithm is as follows:

[0066] Cross-chain calibration nodes elect a consensus leader node through a consensus algorithm. The consensus leader node is responsible for collecting the physical time of all cross-chain calibration nodes, the on-chain timestamps of chain A and chain B, and the cross-chain round-trip time (RTT) data. It then processes the physical time of the cross-chain calibration nodes, the on-chain timestamps of chain A and chain B, and the cross-chain RTT data to obtain a unified cross-chain time base. The specific process is as follows:

[0067] The physical time of the cross-chain calibration node is weighted and fused to obtain a weighted average physical time reference, and the specific process is as follows:

[0068] The collected physical time of each cross-chain calibration node is weighted and averaged: the physical time collected by the GPS clock device is set to a weight coefficient of 0.9, and the physical time collected by other types of time sources (such as node local high-precision hardware clock) is set to a weight coefficient of 0.1;

[0069] The weighted fusion of physical time is completed by calculating the sum of the physical time of each node multiplied by the corresponding weight coefficient divided by the sum of all weight coefficients to obtain the weighted average physical time reference;

[0070] Based on the weighted average physical time reference, the time drift correction is performed on the real-time on-chain block timestamp of chain A and chain B respectively, and the chain A alignment time and the chain B alignment time are obtained respectively, and the specific process is as follows:

[0071] The deviation value of the original on-chain timestamp of chain A and the weighted average physical time reference is calculated, which is denoted as the chain A time drift amount, and the deviation value of the original on-chain timestamp of chain B and the weighted average physical time reference is calculated, which is denoted as the chain B time drift amount;

[0072] The original on-chain timestamp of chain A is subtracted by the chain A time drift amount to obtain the corrected chain A alignment time;

[0073] The original on-chain timestamp of chain B is subtracted by the chain B time drift amount to obtain the corrected chain B alignment time;

[0074] By eliminating the time offset caused by the fluctuation of the block generation interval within the chain, the consistency of the on-chain time and the physical time reference is ensured;

[0075] The collected cross-chain round-trip delay RTT data is preprocessed, and one maximum value and one minimum value in the cross-chain round-trip delay RTT data are removed. The arithmetic mean of the remaining cross-chain round-trip delay RTT data is taken to obtain the effective cross-chain round-trip delay, denoted as the effective cross-chain round-trip delay RTT data;

[0076] Based on the effective cross-chain round-trip delay RTT data, the one-way delay is calculated: one-way delay = effective cross-chain round-trip delay RTT data ÷ 2 + effective cross-chain round-trip delay RTT data × 10%, wherein effective cross-chain round-trip delay RTT data × 10% is a delay fluctuation compensation value for coping with short-term network jitter;

[0077] Taking the chain A alignment time as the reference, the one-way delay is superimposed to obtain the chain B delay compensation time, and the influence of network delay on cross-chain time synchronization is compensated;

[0078] The cross-chain unified time reference is finally output by taking an arithmetic mean of the chain B delay compensation time and the chain B alignment time;

[0079] In the space-time anchoring module, the specific process of synchronizing the cross-chain unified time reference to the smart contracts of chain A and chain B is as follows:

[0080] The consensus leader node synchronizes the cross-chain unified time reference to the smart contracts of chain A and chain B through the smart contract calling interface;

[0081] After receiving the cross-chain unified time reference, the smart contracts of chain A and chain B use it as a unified time reference for cross-chain financial operations (such as asset lock validity period, operation time window, etc. The logic is executed based on the cross-chain unified time reference), ensuring the consistency of operations in the time dimension between chain A and chain B;

[0082] Multi-dimensional state proof module: When the chain A lock smart contract locks assets, it generates a space-time anchoring hash and a signature list through the cross-chain calibration node. When the chain B unlock smart contract receives the cross-chain message, chain B needs to verify the consistency of the space-time anchoring hash, the validity of the signature list, and the time validity to confirm the lock state;

[0083] In the multi-dimensional state proof module, the specific process of generating a space-time anchoring hash by the chain A lock smart contract when locking assets is as follows:

[0084] When a user initiates a financial asset (such as digital currency, digital certificate, etc.) lock operation on chain A, the chain A lock smart contract executes the following process:

[0085] The smart contract automatically obtains four types of key parameters from each module in the system:

[0086] Cross-chain unified time reference: The latest unified time synchronized from the space-time anchoring calibration module (such as cross-chain unified time reference = 2025-11-1210:00:00.000);

[0087] Lock block height: The block number recorded by chain A for the lock operation (such as lock block height = 1000000), used to locate the operation in the history of chain A;

[0088] Node geographic location hash: The result of SHA-256 algorithm hashing of the physical location (such as latitude and longitude) of the chain A node performing the lock operation (such as Hash(physical location) = 0xabc...), avoiding direct exposure of node geographic information;

[0089] Hash image generation time: the time when the above parameter combination is generated (calculated based on the cross-chain unified time reference, such as Hash image generation time = cross-chain unified time reference + 100 ms, i.e. 2025-11-12 10:00:00.100), marking the generation time of the parameter combination;

[0090] Spacetime anchored hash generation:

[0091] The smart contract concatenates the above four types of parameters in a fixed order (such as cross-chain unified time reference + lock block height + node geographic location hash + hash image generation time), and calculates the spacetime anchored hash (such as spacetime anchored hash = Hash(cross-chain unified time reference || lock block height || geographic hash || hash image generation time) = 0xdef...) through the SHA-256 algorithm;

[0092] The spacetime anchored hash uniquely corresponds to the current asset locking operation of chain A, and any parameter tampering will cause the hash value to change, ensuring that the state cannot be forged;

[0093] In the multi-dimensional state proof module, the specific process of generating a signature list by a cross-chain calibration node is as follows:

[0094] The chain A locking smart contract sends a signature request to the cross-chain calibration node cluster of the spacetime anchored calibration module, which includes the spacetime anchored hash and the original parameters (parameters for verifying the legality of the hash);

[0095] After verifying the authenticity of the parameters (such as whether the cross-chain unified time reference is the latest unified time and whether the lock block height is the current valid block height of chain A), the cross-chain calibration node signs the spacetime anchored hash using its own private key;

[0096] The smart contract collects at least 2 / 3 of the cross-chain calibration node signatures to form a signature list (including the signature node public key and the signature value), which serves as multi-node endorsement for the validity of the spacetime anchored hash;

[0097] The chain A locking smart contract writes the spacetime anchored hash, original parameters (cross-chain unified time reference, lock block height, geographic hash, hash image generation time), and signature list into the chain A block, completes the state encapsulation and evidence of asset locking, and triggers a cross-chain message to synchronize the above data to the unlocking smart contract of chain B;

[0098] In the multi-dimensional state proof module, when the chain B unlocking smart contract receives the cross-chain message, chain B needs to perform spacetime anchored hash consistency verification, signature list validity verification, and time validity verification to confirm the locking state, the specific process is as follows:

[0099] When the unlocking smart contract of chain B receives the cross-chain message of chain A synchronization (containing space-time anchor hash, original parameter, signature list), the following verification process is performed to confirm the real lock state of chain A assets:

[0100] Space-time anchor hash consistency verification:

[0101] The chain B smart contract sends a verification request to the calibration node cluster of the space-time anchor calibration module, synchronizing the original parameters (cross-chain unified time reference, space-time anchor hash, geographic hash, hash original image generation time) from chain A;

[0102] The cross-chain calibration node recalculates the hash verification value based on the same rules (fixed order splicing + SHA-256 algorithm);

[0103] If no less than two-thirds of the calibration nodes return hash verification value = hash locking value, it is confirmed that the hash consistency (i.e. the parameters from chain A have not been tampered with) is consistent; otherwise, it is determined as invalid operation, and the unlocking process is terminated;

[0104] Signature list validity verification:

[0105] The chain B smart contract extracts the signature node public key in the signature list, checks whether it is in the preset authorized calibration node list (excluding malicious signatures of unauthorized nodes); at the same time, the public key is used to verify the signature value, confirming that each signature corresponds to the space-time anchor hash and has not been tampered with; if any signature is invalid or the node is unauthorized, the unlocking process is terminated;

[0106] Time validity verification (dynamic threshold check of hash original image generation time):

[0107] The chain B smart contract verifies the validity of the hash original image generation time in combination with the real-time data of the dynamic time window adjustment module:

[0108] Calculate chain B relative time = chain B current time - cross-chain unified time reference (based on cross-chain unified time reference, eliminate chain B local time deviation);

[0109] Get the current dynamic delay threshold of chain A and chain B from the dynamic time window adjustment module (such as , calculated based on historical 95th percentile effective cross-chain round-trip delay cross-chain round-trip delay RTT data);

[0110] If the hash original image generation time + dynamic delay threshold ≥ relative time, it means that the hash original image generation time is within a reasonable delay range (i.e. the locking operation of chain A does not cause chain B to receive timeout failure due to network delay); otherwise, the time is invalid, and the unlocking process is terminated;

[0111] Lock state confirmation and unlocking execution:

[0112] When all three verifications (spatial-time anchor hash consistency verification, signature list validity verification, and time validity verification) pass, the Chain B unlock smart contract confirms that the assets of Chain A have been truly locked and that the cross-chain message has not been tampered with or delayed beyond the time limit. Then, it executes the corresponding asset unlocking operation (such as generating an equivalent mapped asset on Chain B).

[0113] If any verification fails, the cross-chain message is marked as abnormal, triggering asset freezing and sending an alert to the audit system;

[0114] Dynamic time window adjustment module: Constructs a historical latency database to calculate the initial time lock of chain A and adjusts the unlocking time lock of chain B based on real-time latency monitoring;

[0115] In the dynamic time window adjustment module, the specific process of constructing a historical delay database to calculate the initial time lock for chain A is as follows:

[0116] Every 5 minutes, a delay probe packet (including timestamp) is sent to both Chain A and Chain B to record the round-trip time (RTT data) of data transmission from Chain A to Chain B and back to Chain A, and to collect all cross-chain RTT data to build a historical delay database.

[0117] The historical delay database stores all cross-chain round-trip delay (RTT) data for the past 24 hours in the format of timestamp + cross-chain round-trip delay (RTT) data (rolling over, only retaining data from the most recent 24 hours).

[0118] All cross-chain round-trip time (RTT) data values ​​within 24 hours are sorted in ascending order, and the median value is taken (or the average of the two median values ​​if there is an even number of data points) to reflect the general level of network latency.

[0119] All cross-chain round-trip time (RTT) data values ​​within 24 hours are sorted in ascending order, and the value at the 95th position (i.e., 95% of the cross-chain round-trip time (RTT) data values ​​are less than this value) is taken to reflect extreme network latency situations (such as latency during sudden congestion).

[0120] These two indicators are synchronized in real time to the calculation unit of the dynamic time window adjustment module as time lock parameters;

[0121] The initial time lock on chain A is used to limit the maximum valid time from when the asset is locked until chain B receives and verifies the message, in order to prevent the state from becoming invalid due to excessive delay. The specific calculation logic is as follows:

[0122] Set the basic time lock:

[0123] Preset fixed values ​​based on the type of financial asset (such as high-frequency small-amount payments and low-frequency large-amount settlements), for example, 30 seconds for high-frequency scenarios and 5 minutes for low-frequency scenarios (which can be adjusted through on-chain governance proposals).

[0124] Set the adjustment coefficient k: dynamically set based on network stability, the default value is 1.5 (it can be reduced to 1.2 when the network fluctuation is small, and it can be increased to 2.0 when the fluctuation is severe), which is used to amplify the impact weight of extreme delay and reserve redundant time;

[0125] The calculation formula executes a dynamic time window adjustment module every 10 minutes to read the value of the 95th percentile of the historical delay database, and substitutes it into the formula to calculate the initial time lock of chain A:

[0126] The initial time lock of chain A = the base time lock + k x the value of the 95th percentile;

[0127] For example: the base time lock = 30 seconds, k = 1.5, and the value of the 95th percentile = 20 seconds. Then the initial time lock of chain A = 30 + 1.5 x 20 = 60 seconds. That is, after the asset lock of chain A, it needs to be received and verified by chain B within 60 seconds, otherwise it is considered as timeout.

[0128] The initial time lock of chain A is synchronized to the lock smart contract of chain A through the smart contract interface, serving as the effective upper limit of the asset locking operation;

[0129] It should be noted that when the chain A lock smart contract generates the space anchor hash, it will automatically write the initial time lock of chain A into the parameter, clearly specifying the effective duration of the initial time lock state of chain A.

[0130] In the dynamic time window adjustment module, the specific process of adjusting the unlock time lock of chain B according to real-time delay monitoring is as follows:

[0131] The unlock time lock of chain B is used to adapt to real-time network delay, ensuring that the unlocking verification is completed within the effective period of the initial time lock of chain A. The specific adjustment logic is as follows:

[0132] The real-time delay monitoring dynamic time window adjustment module collects the current cross-chain round-trip delay RTT data of chain A and chain B in real time through the calibration node (updated every 2 seconds), and calculates the deviation rate of the real-time 95th percentile value from the historical 95th percentile value (deviation rate = (real-time 95th percentile value - historical 95th percentile value) / historical 95th percentile value).

[0133] The unlock time lock of chain B is consistent with the initial time lock of chain A (for example, if the initial time lock of chain A = 60 seconds, then the unlock time lock of chain B = 60 seconds).

[0134] If the real-time deviation rate > 20% (i.e. the real-time delay is higher than the historical extreme value), then the unlock time lock of chain B is extended by the same percentage as the deviation rate (for example, if the deviation rate = 30%, then the unlock time lock of chain B = 60 x (1 + 30%) = 78 seconds).

[0135] If the real-time deviation rate is less than -20% (i.e., the real-time latency is lower than the historical extreme value), the unlocking time lock of chain B will be shortened proportionally according to the deviation rate, but the shortest time lock will not be less than the base time lock (e.g., if the base time lock is 30 seconds, even if the deviation rate is -50%, the unlocking time lock of chain B will not be less than 30 seconds).

[0136] In some embodiments, the unlocking time lock of Chain B after the Chain B contract is synchronized to the unlocking smart contract of Chain B in real time, serving as a dynamic delay threshold for time validity verification (i.e., relative time in the multi-dimensional state proof module).

[0137] Cross-chain consensus detection module: Constructs verification nodes for chain B to intercept cross-chain asset duplication attacks in real time; the verification nodes obtain the spatiotemporal anchor hash, hash preimage generation time and operation signature list synchronized with chain A through the cross-chain oracle, and achieve cross-chain asset state consistency judgment based on the RAFT consensus algorithm; if no less than two-thirds of the verification nodes confirm that the asset state of chain A and chain B is inconsistent, the defense mechanism of asset freezing, asset return to the original path and blacklisting of attacker addresses is triggered.

[0138] In the cross-chain consensus detection module, the specific process of building a Chain B verification node to intercept cross-chain asset duplication attacks in real time is as follows:

[0139] The network of validator nodes for Chain B employs a trusted node cluster architecture to ensure that nodes participating in consensus possess authority and are resistant to attacks.

[0140] Chain B Validator Node Selection and Distribution:

[0141] Chain B verification nodes are selected from the cross-chain calibration nodes of the spatiotemporal anchoring calibration module and must meet the following conditions:

[0142] Set the number of validator nodes for Chain B to an odd number (such as 7 or 9) to avoid a tie during voting;

[0143] The geographical distribution of Chain B verification nodes is consistent with that of cross-chain calibration nodes (covering multiple time zones), ensuring comprehensive awareness of cross-chain latency.

[0144] Chain B Validator Node Permission Management:

[0145] The operational permissions of Chain B verification nodes are controlled through Chain B smart contracts: only authorized Chain B verification nodes can participate in asset status consistency judgment, and the voting results of unauthorized Chain B verification nodes are automatically invalidated;

[0146] In the cross-chain consensus detection module, the verification node obtains the spatiotemporal anchor hash, hash preimage generation time, and operation signature list synchronized with chain A through the cross-chain oracle. The specific process of achieving cross-chain asset state consistency judgment based on the RAFT consensus algorithm is as follows:

[0147] The verification node obtains the asset state data of chain A in real time through the cross-chain oracle, ensuring that the data source is reliable and has not been tampered with:

[0148] A cross-chain oracle (such as a customized Chainlink oracle) is deployed between chain A and chain B, and three types of core data are synchronized from the locking smart contract of chain A every 3 seconds:

[0149] The latest spatiotemporal anchor hash set of chain A (including the spatiotemporal anchor hashes of all unlocked assets); the hash image generation time corresponding to the hash; the operation signature list of the hash by the cross-chain calibration node;

[0150] When the cross-chain oracle synchronizes data, it needs to attach its own signature and timestamp for the verification node to verify the integrity of the data transmission process;

[0151] After the chain B verification node receives the cross-chain oracle data, it first performs preprocessing:

[0152] Verify the validity of the cross-chain oracle signature (ensure that the data comes from an authorized cross-chain oracle); convert the block height of chain A and the hash image generation time parameter into the time context of chain B (based on the cross-chain unified time reference); index by asset ID (such as storing asset ID-spatiotemporal anchor hash-hash image generation time), which facilitates quick queries of the chain A state of a certain asset;

[0153] In the cross-chain consensus detection module, the specific process of asset state consistency judgment based on the RAFT consensus algorithm is as follows:

[0154] The chain B verification node uses the RAFT consensus algorithm to make a distributed judgment of the asset state of chain A and chain B, ensuring that the result is objective and reliable:

[0155] The verification node elects a consensus leader every 5 minutes through the RAFT algorithm: the consensus leader is responsible for initiating state judgment tasks, collecting node results, and calculating the final conclusion;

[0156] During the election, chain B verification nodes with high historical credit scores (no false judgment records) and low network delays are preferred to improve consensus efficiency;

[0157] State judgment task trigger: when the unlocking smart contract of chain B receives a cross-chain asset transfer request (such as a user applying to unlock a certain asset), it sends a state judgment request to the consensus leader, who immediately broadcasts the task to all chain B verification nodes and starts the consistency judgment;

[0158] Local independent verification: each chain B verification node independently performs three checks based on the locally stored chain A data (from the cross-chain oracle) and the current state of chain B:

[0159] Hash matching check: check if the spatiotemporal anchor hash received by chain B exists in the hash set synchronized by chain A (if not, it means that chain A has not locked the asset, which may be a repeated transfer);

[0160] Signature and time check: verify if the signature list received by chain B is consistent with the signature synchronized by chain A, and if the hash image generation time is within the valid range calculated by the dynamic time window adjustment module (exclude cases of timeout or forged signatures);

[0161] Chain B state check: query the asset record of chain B to confirm whether the asset has been unlocked (if it has been unlocked, the repeated transfer is requested again);

[0162] After the check is completed, the node submits the judgment result (such as consistent state, inconsistent state, or abnormal state) to the consensus leader, and attaches the check basis (such as unmatched hash value, timeout hash image generation time, etc.);

[0163] Consensus result generation: after the consensus leader collects all the judgment results of the nodes, it counts according to the principle of majority over minority:

[0164] If not less than two-thirds of the nodes determine that the state is inconsistent (such as chain A showing that the asset has been locked, but the spatiotemporal anchor hash received by chain B does not match, or chain B has unlocked the asset), an abnormal consensus conclusion is generated;

[0165] If not less than two-thirds of the nodes determine that the state is consistent, a normal consensus conclusion is generated, allowing chain B to perform the unlocking operation;

[0166] If the judgment results are scattered (no more than two-thirds of the nodes agree), a second check is triggered (vote again after re-synchronizing chain A data), to avoid misjudgment caused by network fluctuations;

[0167] In the cross-chain consensus detection module, the specific process of triggering the defense mechanisms of asset freezing, asset original route return, and attacker address blacklisting is as follows:

[0168] When the consensus conclusion is state abnormal (determining that there is a risk of repeated transfer), the cross-chain consensus detection module immediately triggers a three-level response mechanism:

[0169] Asset freezing: the unlocking smart contract of chain B automatically freezes the target asset (prohibits any transfer or unlocking operation) according to the consensus conclusion, and records the freezing reason (such as chain A state inconsistency, suspected repeated transfer), freezing time, and involved asset ID in the chain B block, ensuring that the asset state cannot be tampered with;

[0170] Assets are returned to their original source: After freezing, the Chain B smart contract sends a return request to the Chain A locking smart contract through a cross-chain oracle. The request includes the consensus conclusion, abnormal evidence (such as mismatched hash values, signature lists) and the hash of the Chain B freeze record.

[0171] After Chain A verifies the legitimacy of the request, it unlocks the original asset and returns the asset to the original user account (not the attacker's address), ensuring that the ownership of the asset remains unchanged.

[0172] Attacker Address Blacklisting: The Chain B smart contract extracts the initiating address (attacker address) from abnormal requests and writes it into the on-chain blacklist (an immutable list of addresses); the blacklist is synchronized to Chain A, the spatiotemporal anchoring calibration module, and the dynamic time window adjustment module: Chain A and Chain B reject any cross-chain operation requests from this address; the cross-chain calibration node rigorously verifies the time data related to this address (e.g., shortens the time window threshold); the blacklist is updated periodically (e.g., daily) and broadcast to the entire network, forming a cross-chain collaborative defense.

[0173] Example 2

[0174] like Figure 2 As shown in the specific embodiment, the present invention provides an intelligent financial auditing method based on blockchain cross-validation, comprising:

[0175] S10: Deploy cross-chain calibration nodes, output a unified cross-chain time base through a consensus algorithm, and synchronize the unified cross-chain time base to the smart contracts of chain A and chain B;

[0176] S20: When the assets are locked, the smart contract of Chain A generates a spatiotemporal anchor hash and generates a signature list through the cross-chain calibration node. When the smart contract of Chain B receives the cross-chain message, Chain B needs to perform spatiotemporal anchor hash consistency verification, signature list validity verification, and time validity verification to confirm the locked status.

[0177] S30: Build a historical delay database to calculate the initial time lock of chain A and adjust the unlocking time lock of chain B based on real-time delay monitoring;

[0178] S40: Construct verification nodes for chain B to intercept cross-chain asset duplication attacks in real time; the verification nodes obtain the spatiotemporal anchor hash, hash preimage generation time and operation signature list synchronized with chain A through the cross-chain oracle, and achieve cross-chain asset state consistency judgment based on the RAFT consensus algorithm; if no less than two-thirds of the verification nodes confirm that the asset state of chain A and chain B is inconsistent, the defense mechanism of asset freezing, asset return to the original path and blacklisting of attacker addresses is triggered.

[0179] The above shows and describes the basic principles, main features and advantages of the present application. Those skilled in the art should understand that the present application is not limited to the above-mentioned embodiments, and the above-mentioned embodiments and descriptions in the specification are only to illustrate the principles of the present application. Without departing from the spirit and scope of the present application, various changes and improvements can be made to the present application, and these changes and improvements all fall within the scope of the claimed present application. The scope of protection of the present application is defined by the appended claims and their equivalents.

Claims

1. An intelligent financial auditing system based on blockchain cross-validation, characterized in that: include: Spatiotemporal anchoring calibration module: Deploys cross-chain calibration nodes, outputs a unified cross-chain time base through a consensus algorithm, and synchronizes the unified cross-chain time base to the smart contracts of chain A and chain B; Multi-dimensional state proof module: When the assets are locked, the smart contract of Chain A generates a spatiotemporal anchor hash and generates a signature list through the cross-chain calibration node. When the smart contract of Chain B receives the cross-chain message, Chain B needs to perform spatiotemporal anchor hash consistency verification, signature list validity verification, and time validity verification to confirm the locked state. Dynamic time window adjustment module: Constructs a historical delay database to calculate the initial time lock of chain A and adjusts the unlocking time lock of chain B based on real-time delay monitoring; Cross-chain consensus detection module: Constructs verification nodes for chain B to intercept cross-chain asset duplication attacks in real time; the verification nodes obtain the spatiotemporal anchor hash, hash preimage generation time and operation signature list synchronized with chain A through the cross-chain oracle, and achieve cross-chain asset state consistency judgment based on the RAFT consensus algorithm; if no less than two-thirds of the verification nodes confirm that the asset state of chain A and chain B is inconsistent, the defense mechanism of asset freezing, asset return to the original path and blacklisting of attacker addresses is triggered.

2. The intelligent financial audit system based on blockchain cross-validation according to claim 1, characterized in that: The specific process for deploying the cross-chain calibration node is as follows: Cross-chain calibration nodes are deployed using a geographically distributed architecture, with nodes located in different time zones and geographical locations. Each cross-chain calibration node integrates a physical time source unit, an on-chain timestamp reading unit, and a cross-chain round-trip time (RTT) measurement unit.

3. The intelligent financial audit system based on blockchain cross-validation according to claim 1, characterized in that: The specific process of outputting a unified cross-chain time base is as follows: The consensus leader node collects the physical time of all cross-chain calibration nodes, the on-chain timestamps of chain A and chain B, and the cross-chain round-trip time (RTT) data. It then performs calculations on the physical time of the cross-chain calibration nodes, the on-chain timestamps of chain A and chain B, and the cross-chain RTT data to obtain a unified cross-chain time base.

4. The intelligent financial audit system based on blockchain cross-validation according to claim 3, characterized in that: The specific process for obtaining a cross-chain unified time base includes: The physical time of the cross-chain calibration node is weighted by 0.9 based on the physical time collected by the GPS clock device, and by 0.1 based on the physical time of its time source, to obtain the weighted average physical time reference. Calculate the deviation between the original timestamps on chains A and B and the weighted average physical time base to obtain the time drift of chain A and the time drift of chain B; subtract the time drift of chain A and the time drift of chain B from the original timestamps on chains A and B respectively to obtain the alignment time of chain A and the alignment time of chain B. The arithmetic mean of the cross-chain round-trip time (RTT) data after removing one maximum and one minimum value is taken to obtain the effective cross-chain RTT data. One-way delay = effective cross-chain RTT data ÷ 2 + effective cross-chain RTT data × 10%, where effective cross-chain RTT data × 10% is the delay fluctuation compensation value. Based on the alignment time of chain A, the one-way delay is superimposed to obtain the delay compensation time of chain B. The arithmetic mean of the delay compensation time of chain B and the alignment time of chain B is taken to output the unified cross-chain time benchmark.

5. The intelligent financial audit system based on blockchain cross-validation according to claim 1, characterized in that: The specific process of synchronizing a cross-chain unified time base to the smart contracts of chain A and chain B is as follows: The consensus leader node synchronizes the cross-chain unified time base to the smart contracts of chain A and chain B by calling the interface through the smart contract; After receiving the cross-chain unified time base, the smart contracts of Chain A and Chain B will use the cross-chain unified time base as the unified time reference for cross-chain financial operations.

6. The intelligent financial audit system based on blockchain cross-validation according to claim 1, characterized in that: The specific process by which the Chain A locking smart contract generates a spatiotemporal anchor hash when assets are locked is as follows: When a user initiates a financial asset locking operation on Chain A, the system obtains the cross-chain unified time base, the locked block height, the node's geographical location hash, and the hash preimage generation time. The system then concatenates the cross-chain unified time base, the locked block height, the node's geographical location hash, and the hash preimage generation time in a fixed order and calculates the spatiotemporal anchor hash using the SHA-256 algorithm.

7. The intelligent financial audit system based on blockchain cross-validation according to claim 1, characterized in that: The specific process for verifying and confirming the locked status is as follows: Spatiotemporal anchoring hash consistency verification: Send a verification request containing the original parameters of chain A to the calibration node cluster of the spatiotemporal anchoring calibration module. If no less than two-thirds of the calibration nodes return a hash verification value equal to the hash lock value, then consistency is confirmed; otherwise, the unlocking process is terminated. Signature list validity verification: Extract the public key of the signing node, check whether it is in the authorized calibration node list, and use the public key to verify that the signature corresponds to the spatiotemporal anchor hash and has not been tampered with. If any signature is invalid or the node is not authorized, the unlocking will be terminated. Time validity verification: Calculate the relative time of chain B = current time of chain B - cross-chain unified time base; obtain the dynamic delay threshold between chain A and chain B; If the hash preimage generation time plus the dynamic delay threshold is greater than or equal to the relative time, it means that the hash preimage generation time is within a reasonable delay range; otherwise, the unlocking process is terminated. If the spatiotemporal anchor hash consistency verification, time validity verification, and signature list validity verification all pass, the corresponding asset unlocking operation will be executed; if any verification fails, the cross-chain message will be marked as abnormal, triggering asset freezing and sending an alert to the audit system.

8. The intelligent financial audit system based on blockchain cross-validation according to claim 1, characterized in that: The specific process of initial time locking for computation chain A is as follows: Build a historical latency database: Send a latency probe packet with timestamp to Chain A and Chain B every 5 minutes to record the cross-chain round-trip latency (RTT) data of data transmission between Chain A and Chain B, and store all cross-chain round-trip latency (RTT) data of the past 24 hours in the format of timestamp + cross-chain round-trip latency (RTT). Extract time lock parameters: Sort all cross-chain round-trip time (RTT) data values ​​within 24 hours in ascending order, and take the middle value and the value at the 95th position; Calculate the initial time lock for chain A: Set a base time lock based on the type of financial asset, and an adjustment coefficient k based on network stability; read the value at the 95th position of the historical latency database every 10 minutes, and calculate the initial time lock for chain A according to the formula: Initial time lock for chain A = Base time lock + k × Value at the 95th position.

9. The intelligent financial audit system based on blockchain cross-validation according to claim 1, characterized in that: The specific process of real-time interception of cross-chain asset duplication attacks is as follows: Verification nodes are selected from the cross-chain calibration nodes of the spatiotemporal anchoring calibration module, and must meet the following requirements: the number of nodes is set to an odd number, and the geographical distribution is consistent with that of the cross-chain calibration nodes. Node operation permissions are controlled through the Chain B smart contract. Only authorized verification nodes can participate in the asset status consistency judgment, and the voting results of unauthorized verification nodes are automatically invalidated.

10. The intelligent financial audit system based on blockchain cross-validation according to claim 1, characterized in that: The specific process for achieving cross-chain asset state consistency judgment based on the RAFT consensus algorithm is as follows: A cross-chain oracle is deployed between Chain A and Chain B. Every 3 seconds, it locks the smart contract on Chain A and synchronizes the latest spatiotemporal anchor hash set, the corresponding hash preimage generation time, and the cross-chain calibration node signature list of Chain A. During synchronization, the oracle signature and timestamp are attached. After receiving the data, the Chain B verification node verifies the validity of the oracle signature, converts the Chain A block height and hash preimage generation time into the Chain B time context, and creates an index by asset ID. Every 5 minutes, the chain B verification nodes elect a consensus leader using the RAFT algorithm. The leader is responsible for initiating state judgment tasks. When the chain B unlocks the smart contract and receives a cross-chain asset transfer request, it sends a judgment request to the leader. After the leader broadcasts the task, each node independently performs hash matching verification, signature and time verification, and chain B state verification based on the local chain A data and chain B state, and submits the results. If at least two-thirds of the nodes determine that the state is consistent, unlocking is allowed; if at least two-thirds of the nodes determine that the state is inconsistent, an abnormal conclusion is generated. If the consensus conclusion is abnormal, Chain B unlocks the smart contract to automatically freeze the target asset and records the freeze information. It then sends a return request containing evidence of the abnormality to Chain A through a cross-chain oracle. After verification, Chain A returns the asset to the original user account. At the same time, Chain B extracts the attacker's address and writes it into the on-chain blacklist, and periodically broadcasts the blacklist for collaborative defense.

Images