Cross-chain data consistency verification method and cross-chain data consistency verification device

Abstract

The invention relates to a cross-chain data consistency verification method and a cross-chain data consistency verification device.The cross-chain data consistency verification method comprises the steps that to-be-verified data is acquired; performing multi-level modeling of a block chain system structure on the to-be-verified data to obtain a global cause and effect graph for each event in the cross-chain data; the global causal graph takes events as nodes and causal relationships among the events as edges; and based on the global causal graph, performing causal consistency verification, time sequence verification and state consistency verification on the cross-chain data to obtain a verification result. According to the method, more comprehensive and reliable consistency verification can be realized by combining causal consistency verification, time sequence verification and state consistency verification based on the construction of a global causal graph.

Description

Technical Field

[0001] This application relates to the field of data verification for blockchain transactions, and in particular to cross-chain data consistency verification methods and devices. Background Technology

[0002] With the rapid development and widespread application of blockchain technology, cross-chain interoperability has become a key requirement for achieving multi-chain collaboration and value transfer. Cross-chain testing for blockchain systems is a systematic process specifically designed to verify and evaluate the interoperability between different blockchain networks. Cross-chain testing ensures that assets, data, or smart contract instructions can be transferred and interacted securely, reliably, and consistently across heterogeneous and independent blockchains as expected.

[0003] Currently, cross-chain testing solutions in related technologies typically focus on verifying a single node, a single protocol layer, or a single function. For example, existing technologies usually only test localized aspects such as cross-chain message format, signature verification, or single-chain state consistency, failing to build a systematic verification framework. Furthermore, related technologies often treat cross-chain operations as isolated transaction events for verification, limiting themselves to checking the state of a single chain or a portion of the chain.

[0004] Therefore, the aforementioned limitations in current technologies make it difficult for current cross-chain testing to fully guarantee the reliability and security of cross-chain systems in real-world deployment environments.

[0005] There is currently no effective solution to the problem of insufficient comprehensiveness and reliability of cross-chain testing in related technologies. Summary of the Invention

[0006] This embodiment provides a cross-chain data consistency verification method and a cross-chain data consistency verification device to solve the problem of insufficient comprehensiveness and reliability of cross-chain testing in related technologies.

[0007] Firstly, this embodiment provides a cross-chain data consistency verification method for a blockchain system, the method comprising:

[0008] Retrieve the data to be verified;

[0009] The blockchain system structure is modeled in a multi-level manner for the data to be verified, resulting in a global causal graph for each event in the cross-chain data; the global causal graph uses the events as nodes and the causal relationships between the events as edges.

[0010] Based on the global causal graph, the cross-chain data is subjected to causal consistency verification, temporal sequence verification, and state consistency verification to obtain the verification results.

[0011] In some embodiments, multi-level modeling of the blockchain system architecture is performed on the data to be verified to obtain a global causal graph for each event in the cross-chain data, including:

[0012] The transaction dependency model, block-level causal relationship model, chain state view model, and cross-chain message causal relationship model are respectively performed on the data to be verified to obtain a global causal graph for each event in the cross-chain data.

[0013] In some embodiments, transaction dependency modeling is performed on the data to be verified, including:

[0014] Based on the original transaction data, smart contract call event logs, and transaction input and output information in the data to be verified, input and output dependency analysis and smart contract state tracking are performed to obtain a transaction dependency graph that represents the transaction dependency relationship.

[0015] In some embodiments, block-level causal modeling is performed on the data to be verified, including:

[0016] Based on the block header data, transaction data contained in the block, and transaction dependency modeling results in the data to be verified, the packaging order of transactions within the block is verified, and causal relationships between blocks and transactions, and between blocks themselves are established to obtain a block-level causal graph.

[0017] In some of these embodiments, chain state view modeling is performed on the data to be verified, including:

[0018] Based on the continuous sequence of blocks and the latest state root of the nodes in the data to be verified, state evolution tracking, final determination state verification of blocks, and reorganization risk detection of blocks are performed to obtain a chain state view with finality verification label and reorganization risk verification label.

[0019] In some embodiments, causal relationship modeling of the data to be verified across chains is performed, including:

[0020] Based on the source chain's sending events, the target chain's receiving events, and cross-chain transmission information in the data to be verified, message pair matching, causal proof generation of cross-chain events, and atomicity verification of cross-chain operations are performed on the source chain and the target chain to obtain the cross-chain modeling results.

[0021] In some embodiments, causal consistency verification of the cross-chain data is performed based on the global causal graph, including:

[0022] Using preset verification rules and based on the global causal graph, local causal maintenance verification is performed on the causal dependencies of events on each chain in the blockchain system; and,

[0023] Based on the aforementioned global causal graph, the causal transitivity of cross-chain events is verified; and,

[0024] Calculate the transitive closure matrix of the global causal graph to perform closure logic verification on the global causal graph.

[0025] In some embodiments, the cross-chain data is time-order verified based on the global causal graph, including:

[0026] Based on a preset time window, anomalies are identified in the delay time between two events belonging to the same message pair in the global causal graph; and...

[0027] Based on the causal relationships of each event in the global causal graph, the relative time sequence of the timestamps of each event is verified.

[0028] In some embodiments, state consistency verification of the cross-chain data is performed based on the global causal graph, including:

[0029] Based on the global causal graph, the consistency of the cross-chain data in the source chain and the target chain is verified; the consistency of the intermediate state of the cross-chain data is verified; and the consistency of the final state of the cross-chain data is verified.

[0030] Secondly, this embodiment provides a cross-chain data consistency verification device, including: an acquisition module, a multi-level modeling module, and a consistency verification module; wherein:

[0031] The acquisition module is used to acquire the data to be verified;

[0032] The multi-level modeling module is used to perform multi-level modeling of the blockchain system structure on the data to be verified, and obtain a global causal graph for each event in the cross-chain data; the global causal graph uses the event as a node and the causal relationship between the event as an edge;

[0033] The consistency verification module is used to perform causal consistency verification, time sequence verification, and state consistency verification on the cross-chain data based on the global causal graph, and obtain the verification results.

[0034] Compared with related technologies, this embodiment provides a cross-chain data consistency verification method and a cross-chain data consistency verification device. The cross-chain data consistency verification method acquires the data to be verified; performs multi-level modeling of the blockchain system structure on the data to be verified, obtaining a global causal graph for each event in the cross-chain data; the global causal graph uses events as nodes and causal relationships between events as edges; based on the global causal graph, causal consistency verification, temporal sequence verification, and state consistency verification are performed on the cross-chain data to obtain the verification results. It can achieve a more comprehensive and reliable consistency verification by combining causal consistency verification, temporal sequence verification, and state consistency verification based on the construction of the global causal graph.

[0035] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0036] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0037] Figure 1 This is a hardware structure block diagram of the terminal of the cross-chain data consistency verification method according to an embodiment of this application;

[0038] Figure 2 This is a flowchart of the cross-chain data consistency verification method according to an embodiment of this application;

[0039] Figure 3 This is a schematic diagram of a four-level causal modeling process for cross-chain operations involving asset transfer, according to an embodiment of this application.

[0040] Figure 4 This is a flowchart of a method for constructing a global cause-effect graph according to some embodiments of this application;

[0041] Figure 5 This is a flowchart of a consistency verification method according to some embodiments of this application;

[0042] Figure 6 This is a schematic diagram of the structure of a cross-chain data consistency verification system provided in an embodiment of this application;

[0043] Figure 7 This is a structural block diagram of the cross-chain data consistency verification device in this embodiment. Detailed Implementation

[0044] To better understand the purpose, technical solution, and advantages of this application, the application is described and explained below in conjunction with the accompanying drawings and embodiments.

[0045] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these” used in this application do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to these processes, methods, products, or devices. Words such as “connected,” “linked,” and “coupled” used in this application are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. Normally, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," "third," etc., used in this application are merely to distinguish similar objects and do not represent a specific order of objects.

[0046] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. For example, it can run on a terminal. Figure 1 This is a hardware structure block diagram of the terminal for the cross-chain data consistency verification method in this embodiment. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 and a memory 104 for storing data are also included. The processor 102 may be, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA). The terminal may also include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that… Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0047] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the cross-chain data consistency verification method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0048] The transmission device 106 is used to receive or send data via a network. This network includes a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 can be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0049] This embodiment provides a cross-chain data consistency verification method. Figure 2 This is a flowchart of the cross-chain data consistency verification method in this embodiment, as follows: Figure 2 As shown, the process includes the following steps:

[0050] Step S210: Obtain the data to be verified. This data may specifically include transaction data, block data, chain state data, and cross-chain message data generated on the blockchain system. Specifically, transaction data may include raw transaction data from blockchain nodes, smart contract call event logs, and input and output information of transactions—all relevant data at the blockchain transaction level. Block data may include block headers and the list of transactions contained within them—all relevant data at the block level. Chain state data may include a continuous sequence of blocks, the state root of blockchain nodes, and other data reflecting the evolution of the blockchain's chain state. Cross-chain message data may include cross-chain message sending and receiving events, as well as messages and proofs transmitted by cross-chain bridges or relays.

[0051] Specifically, non-intrusive collection of data to be verified can be achieved through distributed data collectors. For example, software programs or service modules deployed on each blockchain node can act as lightweight agents, capturing transaction data, block data, chain state data, and cross-chain message data in real time using a non-intrusive data collection method compatible with mainstream blockchain protocols. In cross-chain operation scenarios, a single chain constitutes an independent, autonomous blockchain ecosystem with its own consensus.

[0052] Step S220: Perform multi-level modeling of the blockchain system structure on the data to be verified to obtain a global causal graph for each event in the cross-chain data; the global causal graph uses events as nodes and the causal relationships between events as edges.

[0053] One approach is to abstract the blockchain system structurally to construct a hierarchical structure, and then perform multi-level modeling based on this abstract hierarchy. Specifically, this structural hierarchy can be divided based on the natural hierarchical structure of the blockchain system and the evolution of data determinism (i.e., the process of data evolving from uncertainty to certainty), allowing each level to address uncertainties that the previous level could not handle. Multi-level modeling can model the causal relationships of the data to be verified at each of the defined levels. In particular, in some embodiments, this multi-level hierarchy can include transaction-level, block-level, chain-level, and cross-chain-level models; correspondingly, this multi-level modeling can include transaction-level modeling, block-level modeling, chain-level modeling, and cross-chain-level modeling. Transaction-level modeling focuses on the input-output dependencies between transactions; block-level modeling focuses on the packaging order of transactions and the consistency within blocks of packaged transactions; chain-level modeling tracks the evolution and reorganization risks of the chain state; and cross-chain-level modeling is used to establish mapping relationships and causal associations for cross-chain messages.

[0054] It's important to note that in distributed systems, causal relationships may exist between the events corresponding to cross-chain operations. For example, on chain A, transaction T1 sends a cross-chain message M; if on chain B, transaction T2 receives this cross-chain message M, then a causal relationship exists between transactions T1 and T2. Specifically, transaction T1 is the cause of transaction T2, and T2 is the result of T1 (because without transaction T1 sending the message, there would be no transaction T2 receiving the message). Therefore, transaction T2 must happen after transaction T1.

[0055] In cross-chain scenarios, multiple chains operate in parallel, and message transmission may pass through cross-chain bridges or relays, potentially leading to message delays, out-of-order delivery, or even message loss. To address this, this embodiment verifies, for each pair of causally related cross-chain events (e.g., a sending event and a receiving event), whether the receiving event actually occurs after the sending event; and whether, on the receiving chain, the receiving event maintains the causal history of the sending chain. To achieve this, a global causal graph is constructed in this embodiment.

[0056] The global causal graph represents the causal relationships between events generated by cross-chain operations on a blockchain system. It consists of nodes and edges; nodes represent events, and edges represent causal relationships between events. Edges in the global causal graph can be of two types: local causal edges and cross-chain causal edges. Local causal edges represent the causal relationship between two events on the same chain. For example, on the same chain, event A causes event B (e.g., event B uses the output of event A, where the event could be a transaction). Then, for events e1 and e2, if e1 and e2 are on the same chain, then when e1 causes e2 on a certain chain (represented as "e1→e2"), all chains consider e1 to cause e2. Cross-chain causal edges are edges between a sending event and its corresponding receiving event on different chains (e.g., source chain and target chain). If send is the sending event and recv is the corresponding receiving event, then the causal relationship is send causes recv (represented as "send→recv").

[0057] The process of constructing this global causal graph first requires collecting all relevant event data from the blockchain system, i.e., the data to be verified mentioned above. Next, a unique node is created for each event, which can have attributes such as a unique event identifier (ID), chain ID, timestamp, event type, data payload, and local causal dependencies. Then, local causal edges and cross-chain causal edges are added between nodes. When adding local causal edges, for each event on each chain, the direct cause event needs to be found based on input references and block inclusion relationships between events. Then, a directed edge is added between the cause event and the result event as a local causal edge: "cause event → result event". This local causal edge can be labeled with a type, such as "LOCAL_CAUSAL", to indicate that its type is a local causal edge.

[0058] When adding cross-chain causal edges, the process first identifies all cross-chain message sending events and matches each sending event with a corresponding receiving event. This matching can be done using information such as message hash values ​​and chain IDs. Then, a directed edge is added between the sending event and the matched receiving event as a cross-chain causal edge: "Sending Event → Receiving Event". This cross-chain causal edge can be tagged with a type, such as "CROSS_CHAIN". This completes the construction of a global causal graph. Furthermore, this global causal graph can have data structures including a node set, an edge set, and a list of cross-chain message pairs. The node set stores information about all event nodes; the edge set stores information about all causal relationship edges; and the list of cross-chain message pairs records event pairs consisting of matched sending and receiving events. Specifically, after completing multi-level modeling, the construction of the aforementioned global causal graph can be implemented based on this multi-level modeling.

[0059] Step S230: Based on the global causal graph, perform causal consistency verification, time sequence verification, and state consistency verification on the cross-chain data respectively to obtain the verification results.

[0060] In this step, based on the constructed global causal graph, a more comprehensive consistency verification is performed on cross-chain data across three dimensions: causal consistency, event sequence, and state consistency. Causal consistency verification specifically verifies logical contradictions and data breaks in the causal network within the global causal graph to ensure that the causal relationships are logically accurate and complete globally. Timing verification verifies the reasonableness of the time sequence and time delay of events with causal relationships. State consistency verification verifies the consistency of cross-chain data in state changes, specifically including verifying the consistency of state transitions between the source and target chains during cross-chain operations, verifying the consistency of cross-chain data during processing through cross-chain bridges or relays, and confirming the atomicity and finality of the data. Once the data to be verified passes all three verifications based on the global causal graph, it is considered to have passed the overall consistency verification. Finally, a test report is generated based on the consistency verification results.

[0061] In related technologies, cross-chain testing schemes typically focus on verifying a single node, a single protocol layer, or a single function, treating cross-chain operations as isolated transaction events and limiting their verification to checking the state of a single chain or a portion of the chains. To address this, this embodiment tackles the lack of a systematic, multi-level verification framework and the neglect of causal dependencies in cross-chain operations, thus failing to detect causal consistency issues. It constructs a multi-level model based on the blockchain system structure and builds a global causal graph on this basis, thereby achieving the systematic construction of event correlations that consider causal relationships. Addressing the lack of verification capabilities for global state consistency across multiple chains in related technologies, this embodiment performs causal consistency verification, temporal sequence verification, and state consistency verification based on the global causal graph, thereby achieving comprehensive consistency verification of cross-chain data. This improves the comprehensiveness and reliability of cross-chain testing.

[0062] Overall, this embodiment constructs a complete global causal graph for cross-chain operations through multi-level causal modeling, and performs causal consistency, temporal sequence, and state consistency verification based on this global causal graph. This solves the problems of existing cross-chain testing technologies, such as lack of systematicity, neglect of causal relationships, and inability to comprehensively cover consistency verification, providing a comprehensive, accurate, and more efficient consistency verification solution for cross-chain systems. Furthermore, this embodiment can simulate extreme situations that are difficult to reproduce in a production environment, such as reorganization, network partitioning, and malicious attacks. This allows for consistency verification to be performed in a lower-cost and more controllable testing environment without consuming real gas fees (the fees that users need to pay to network validators when executing transactions or running smart contracts on a blockchain network) or losing real assets.

[0063] Therefore, through steps S210 to S230, the data to be verified is obtained; a multi-level model of the blockchain system structure is performed on the data to be verified to obtain a global causal graph for each event in the cross-chain data; the global causal graph uses events as nodes and the causal relationships between events as edges; based on the global causal graph, causal consistency verification, temporal sequence verification, and state consistency verification are performed on the cross-chain data to obtain the verification results. It can achieve more comprehensive and reliable consistency verification by combining causal consistency verification, temporal sequence verification, and state consistency verification based on the construction of the global causal graph.

[0064] In one embodiment, multi-level modeling of the blockchain system architecture is performed on the data to be verified to obtain a global causal graph for each event in the cross-chain data, which may specifically include:

[0065] By performing transaction dependency modeling, block-level causal relationship modeling, chain state view modeling, and cross-chain message causal relationship modeling on the data to be verified, a global causal graph for each event in the cross-chain data is obtained.

[0066] In this embodiment, based on the inherent uncertainties and causal relationships at different levels within the blockchain system architecture, a multi-level causal relationship modeling is abstracted, encompassing transaction-level, block-level, chain-level, and cross-chain-level causality. This achieves logically rigorous and applicable multi-level modeling suitable for the blockchain field. Specifically, uncertainties that cannot be handled at previous levels can be addressed progressively, from the transaction level to the cross-chain level. Ultimately, while ensuring model completeness, redundancy at each level is avoided, thus constructing a complete cross-chain operation causal graph through these four levels of causal modeling. Therefore, the comprehensiveness and reliability of eventual consistency verification are further improved.

[0067] In one embodiment, modeling transaction dependencies in the data to be verified may include: performing input-output dependency analysis and smart contract state tracking based on the original transaction data, smart contract call event logs, and transaction input and output information in the data to be verified, to obtain a transaction dependency graph representing the transaction dependencies.

[0068] The raw transaction data can be a structured data set created by the transaction initiator (user), which contains complete transaction information and a digital signature but has not been confirmed or packaged by the blockchain network; the raw transaction data is the initial form of the transaction before it is broadcast to the network. The smart contract call event log can be a notification of state changes or a declaration of important facts recorded on the blockchain during the execution of a transaction; this call event log can be generated by the smart contract through specific event functions during transaction execution and can be indexed structured data. The main purpose of the smart contract call event log is to provide external applications (such as front-end websites and monitoring services) with a mechanism to listen to and query specific events occurring in the smart contract. The input information of a transaction can be the user's instructions to the blockchain to perform calculations on the transaction; the output information of a transaction can be the immutable and deterministic result resulting from the blockchain network strictly executing the user's instructions for the transaction. A smart contract is program code stored on the blockchain that can be automatically executed when predetermined conditions are met.

[0069] When modeling transaction dependencies, the input data includes raw transaction data, smart contract call event logs, and transaction input and output information. Then, by finding the transaction input information and the corresponding preceding transaction outputs, corresponding dependency edges are added to different transactions. By parsing the smart contract call event logs, and based on the parsing results, changes to the smart contract's internal state variables are monitored to achieve smart contract state tracking. For example, if transaction T1 modifies state variable S, and transaction T2 reads that state variable S, a dependency edge "T1→T2" is established. Finally, a transaction dependency graph can be output. In this graph, nodes represent transactions, and edges represent the "direct influence" or "dependency" relationship between transactions. Thus, this embodiment can capture explicit and implicit dependencies between individual in-chain transactions, thereby achieving the construction of a transaction-level directed acyclic graph (DAG), and providing a basis for the subsequent construction of a global causal graph.

[0070] Additionally, in one embodiment, block-level causal modeling of the data to be verified may specifically include:

[0071] Based on the block header data, transaction data contained in the block, and transaction dependency modeling results in the data to be verified, the packaging order of transactions within the block is verified, and causal relationships between blocks and transactions, and between blocks themselves are established, resulting in a block-level causal graph.

[0072] This involves using block header information, the list of transactions contained in a block, and the aforementioned transaction dependency graph as data inputs to model block-level causal relationships. The block header information is the metadata portion of a block, containing all the summary information needed to identify, verify, and link the block to the blockchain. When constructing the block-level causal graph, the order of transactions within a block can be checked to ensure consistency with the causal dependencies in the transaction dependency graph, thus verifying the transaction order. For example, if transaction T2 depends on the output of transaction T1, then transaction T1 should be packaged before transaction T2. ​​Furthermore, a Merkle inclusion proof can be generated for each transaction within a block based on the list of transactions contained in the block, proving that the transaction is indeed included in the corresponding block, thereby establishing a strong causal relationship between the block and the transaction. In addition, since the blockchain itself is a chain structure linked by block hashes, a causal sequence naturally forms between blocks; for example, a causal sequence from block_N to block_N+1. The relationships between blocks can be confirmed based on the data in the block header to establish the causal sequence of that block. Therefore, this embodiment can generate a block-level causal graph with enhanced causal relationships based on transaction order verification, the causal relationship between transaction and block inclusion proofs, and the causal sequence between blocks. This graph includes not only transaction dependencies but also block inclusion and chain relationships. Thus, this embodiment can achieve block-level causal relationship construction, providing block-level data support for subsequent global causal modeling.

[0073] Furthermore, in one embodiment, chain state view modeling of the data to be verified may specifically include:

[0074] Based on the continuous sequence of blocks and the latest state root of nodes in the data to be verified, state evolution tracking, final determination state verification of blocks, and reorganization risk detection of blocks are performed to obtain a chain state view with finality verification label and reorganization risk verification label.

[0075] The blockchain's backbone is a continuous sequence of blocks linked sequentially and inextricably by cryptographic hash pointers. A node's latest state root serves as a unique and concise digital fingerprint of that node's current state within the entire blockchain world. This latest state root represents a global summary of all account balances, smart contract code, and stored data up to the latest confirmed block by that node. Specifically, the state root hash corresponding to each block can be recorded, forming a state evolution chain: "State_N→State_N+1". Here, State_N can be the state root hash corresponding to the Nth block, and State_N+1 can be the state root hash corresponding to the (N+1)th block. The state root hash is the hash value corresponding to the latest state root. Furthermore, the finalized state of blocks can be verified based on the blockchain's consensus mechanism. In the blockchain, the finalized state refers to an irreversible, unchangeable, and irrevocable state, indicating that the block has been formally accepted by network consensus, eliminating the risk of reorganization at the consensus level. Therefore, only blocks in the finalized state are considered secure and free from reorganization risk.

[0076] In addition, it can monitor forks in the network to detect reorganization risks. Specifically, it can calculate the confirmation depth of the current block and set a safety threshold. When the confirmation depth of a block exceeds this threshold, the events in that block are considered causally stable. Causally stable means that the block and the events it contains are considered permanently valid, and all causal relationships rooted in it are trusted. For example, in a cross-chain context, the cross-chain bridge will only trigger the corresponding minting operation on chain B after confirming that a block on chain A is "causally stable".

[0077] Thus, by constructing a state evolution chain, verifying the final determination state of blocks, and detecting reorganization risks, a chain state view is ultimately output, containing a finality verification label for the final determination state and a security confirmation depth label (reorganization risk verification label). The chain state view constructed in this embodiment can achieve causal relationship modeling at the chain level, thereby providing safe time window suggestions for cross-chain operations and providing a chain-level data foundation for forming a global causal graph.

[0078] Furthermore, in one embodiment, causal relationship modeling of cross-chain messages for the data to be verified may specifically include:

[0079] Based on the sending events of the source chain, the receiving events of the target chain, and the cross-chain transmission information in the data to be verified, message pair matching, causal proof generation of cross-chain events, and atomicity verification of cross-chain operations are performed on the source chain and the target chain to obtain the cross-chain modeling results.

[0080] The cross-chain information transmission can specifically be messages and proofs transmitted by cross-chain bridges or relays. In this embodiment, events on different chains can be connected to establish a causal bridge between the sending and receiving events of cross-chain messages. Specifically, the sending event of the source chain and the receiving event of the target chain can be accurately matched based on the unique message hash, transaction ID, source chain ID, and target chain ID. Here, the source chain is the blockchain where the asset or data originally resides, and it is the starting point of the cross-chain operation. The target chain is the blockchain to which the asset or data is expected to go, and it is the endpoint of the cross-chain operation. For example, the cross-chain message generated by the source chain can have the following key fields:

[0081] Table 1

[0082]

[0083] In Table 1, "..." indicates the omitted portion of the example string.

[0084] The received message generated by the target chain can have the following key fields:

[0085] Table 2

[0086]

[0087] In Table 2, "..." indicates the omitted part of the example string, and the "needs to match" column means that the corresponding field needs to be consistent with the value of the corresponding field in the cross-chain message generated by the source chain.

[0088] Causal proofs can also be generated for sending events and matching receiving events to demonstrate that the validity of a receiving event depends on the corresponding sending event, as well as the inclusion proof and finality proof of the sending event on the source chain. Additionally, the atomicity of cross-chain operations needs to be verified. Specifically, it is determined whether both sending and receiving events succeed or both fail to avoid a dangling state where one party is locked while the other is not minted. Therefore, in this embodiment, the causal relationship of cross-chain events is ultimately output using the sending events of the source chain (e.g., locking assets, sending messages), the receiving events of the target chain (e.g., minting assets, receiving messages), and the messages and proofs transmitted by the cross-chain bridge or relay as input data.

[0089] Finally, by integrating the transaction-level modeling results, block-level modeling results, chain-level modeling results, and cross-chain-level modeling results, and through the processes of creating unique nodes for events, adding local causal edges and cross-chain causal edges, and labeling types, a global causal graph is obtained. This graph is stored in a data structure consisting of node sets, edge combinations, and cross-chain messages. This global causal graph contains events from different chains and is connected by cross-chain edges. For example, based on the transaction dependency graph in the transaction-level modeling results, the causal relationships between blocks and transactions and between blocks in the block-level modeling results, and the chain state view in the chain-level modeling results, local causal edges can be established for nodes belonging to the same chain event in the global causal graph. Then, based on the causal bridge between the sending and receiving events of cross-chain messages in the cross-chain-level modeling results, cross-chain causal edges can be established for the matching sending and receiving events in the cross-chain messages in the global causal graph.

[0090] In one embodiment, causal consistency verification of cross-chain data is performed based on a global causal graph, including:

[0091] Using pre-defined verification rules, based on a global causal graph, the system performs local causal maintenance verification on the causal dependencies of events on each chain in the blockchain system; and verifies the causal transitivity of cross-chain events based on the global causal graph; and calculates the transitive closure matrix of the global causal graph to perform closure logic verification on the global causal graph.

[0092] In causal consistency verification, it is necessary to ensure that the causal relationship network in the global causal graph itself is free from logical contradictions and data breaks. Specifically, causal consistency verification can include local causal preservation verification, causal transitivity verification of cross-chain events, and closure logic verification of the global causal graph.

[0093] Local causality preservation verification verifies whether causal dependencies within a single chain are preserved in the global causal graph without being broken or reversed. Specifically, this is achieved by traversing all local causal edges marked "LOCAL_CAUSAL" in the global causal graph. For each edge, such as "TxA→TxB" (meaning transaction A causes transaction B), three verification rules are applied: time order rule, state dependency rule, and same-chain constraint rule. In the time order rule, the cause must precede the effect; in the state dependency rule, the effect must consume the output of the cause; and in the same-chain constraint rule, the cause and effect must be on the same chain. If these three verification rules are satisfied, the global causal graph is confirmed to possess local causality preservation.

[0094] Verifying the causal transitivity of cross-chain events requires ensuring that the causality of cross-chain messages can be correctly and without loss transmitted to the target chain and can continue to propagate. This involves identifying all cross-chain message pairs and, for each pair, checking whether all transactions on the target chain that depend on the receiving event also indirectly depend on the sending event. Specifically, this can be determined based on the calculation of transitive closures or by using reachability analysis: if a transaction C that depends on a certain receiving event exists on the target chain, then there must be a path in the global causal graph that indirectly indicates that the sending event caused transaction C. For example, if the target chain has the dependency "Recv_Event→Tx_C" (indicating that the receiving event Recv_Event caused transaction C), then the global causal graph must contain a path "Send_Event→...→Tx_C" (indicating that the sending event Send_Event matching the receiving event Recv_Event indirectly caused transaction C). This ensures that the causal chain is not broken after inter-chain transmission.

[0095] To verify the logic of global causal closure, it is necessary to ensure that the entire global causal graph is closed, without any missing links, and that all implicit causal relationships can be explicitly expressed. Specifically, the transitive closure matrix of the global causal graph can be calculated based on the Floyd-Warshall algorithm or the Warshall algorithm, and other graph transitive closure calculation methods. The transitive closure matrix is ​​then checked for logical contradictions. For example, if the transitive closure matrix shows that transaction A leads to B, and transaction B leads to transaction C, and transaction C leads to transaction A, then a causal loop is found, thus presenting a logical contradiction. Alternatively, the transitive closure matrix may show missing transits: if direct causal edges suggest that transaction A should lead to transaction C, but there is no direct or indirect path between transaction A and transaction C in the global causal graph, then the intermediate link between transaction A and transaction C may be missing, thus confirming that the closure between transaction A and transaction C is incomplete. Therefore, this embodiment can achieve accurate and logically rigorous causal consistency verification for the causal relationships of cross-chain events.

[0096] In one embodiment, time-sequence verification of cross-chain data based on a global causal graph may specifically include:

[0097] Based on a preset time window, anomalies are identified in the delay time between two events belonging to the same message pair in the global causal graph; and, based on the causal relationship of each event in the global causal graph, the relative time order of the timestamps of each event is verified.

[0098] In this embodiment, time order verification is not based on absolute clocks, but rather on relative time and logical clocks. A reasonable, dynamically adjustable maximum expected delay can be defined for message transmission between different chains. Specifically, this can be achieved by continuously measuring the actual delay of all paired send and receive events in historical data: ΔT = Recv.timestamp - Send.timestamp; then, the moving average (μ) and standard deviation (σ) of these actual delays are calculated. The current safe time window is dynamically defined as: ValidWindow = μ + n × σ; where n is a preset value, for example, a value of 3 can cover 99.7% of delay cases. When the actual delay exceeds this time window, this delay is marked as abnormal, thereby achieving abnormal identification of the delay time between two events of the same message pair.

[0099] Furthermore, the relative order of events can be verified based on the causal relationship of logical clocks. Specifically, if transaction A leads to transaction B, then the timestamp of transaction A must be less than the timestamp of transaction B. Therefore, each edge in the global causal graph can be traversed, and verification can be performed according to the aforementioned time order rules. For example, for a cross-chain causal edge "Send→Recv", even if the absolute timestamp of the receiving event Recv may be less than that of the sending event Send due to clock skew, logically, the sending event Send must occur before the receiving event Recv. Therefore, it is necessary to be able to detect and report this "time reversal" anomaly.

[0100] In addition, maximum latency constraints can be checked to ensure that cross-chain operations are completed within a commercially acceptable timeframe. Specifically, different latency thresholds can be set for different types of cross-chain operations; for example, asset transfer operations need to be limited to completion within 10 minutes. For each cross-chain message pair, the corresponding actual latency is calculated and compared with a preset latency threshold. Cross-chain operations exceeding this threshold are marked as timeouts, and even if the operation ultimately succeeds, it needs to be recorded as a performance issue.

[0101] This embodiment verifies the cross-chain operation in the time dimension based on delay anomalies and relative event order, thereby verifying the rationality of the cross-chain operation in the time dimension.

[0102] In another embodiment, state consistency verification of cross-chain data based on a global causal graph may specifically include:

[0103] Based on a global causal graph, the consistency of cross-chain data states in the source and target chains is verified; the consistency of intermediate states of cross-chain data is verified; and the consistency of final states of cross-chain data is verified.

[0104] In this embodiment, state consistency verification is used as the final and most substantial verification to ensure that the correctness of causal relationships and temporal order can ultimately be accurately reflected in the world state of the blockchain. Specifically, state consistency verification can include consistency verification of state changes between the source chain and the target chain, intermediate state consistency verification, and final state consistency verification.

[0105] The source chain and target chain state consistency verification is used to verify whether the state changes of the source chain and target chain are matched and conserved after a cross-chain operation. Specifically, asset conservation checks can be performed. For asset transfers, the following conditions must be met: source chain locked amount = target chain minted amount + cross-chain transaction fee; and it is necessary to verify whether the asset attributes minted on the target chain are correctly mapped (i.e., consistent) with the corresponding asset attributes on the source chain; these asset attributes can include token name, symbol, and precision, etc. This verification can be completed by querying and comparing the final states of the source chain and target chain.

[0106] Intermediate state consistency verification verifies whether the cross-chain bridge or relay has tampered with or mishandled data during the intermediate stages. Specifically, it checks the state proof or storage proof issued by the cross-chain bridge. For example, it verifies that the balance of a certain account is indeed locked at a certain block height in the source chain. Additionally, it verifies whether the message content forwarded by the relay, such as the amount or receiving address, is completely consistent with the corresponding content of the event sent by the source chain, and whether it has been maliciously modified or repeatedly sent.

[0107] Final state consistency verification serves as the ultimate safety net, ensuring that the entire blockchain system reaches a new, consistent, and stable global state after the cross-chain operation is fully completed. Specifically, it verifies whether the cross-chain operation is atomic. For example, it checks for "half-successful" cross-chain operations (such as locking on the source chain but not minting on the target chain). If an atomicity anomaly is found, it needs to be flagged. Furthermore, it requires waiting for all involved blockchains to reach finality on the relevant blocks. Only after block finality is achieved is the result of the cross-chain operation considered irreversible, thus completing the consistency verification. Therefore, in this embodiment, verification can be completed based on three metrics: atomicity, consistency, and durability. Atomicity means that the asset transfer either succeeds completely or fails completely; consistency requires that the source and target chains maintain consistent states; and durability requires that once confirmed, the transfer result is irreversible.

[0108] The following example illustrates the application scenario of consistency verification in a cross-chain asset transfer operation. In this scenario, assume user A transfers 100 yuan of currency U from the source chain Chain A to the target chain Chain B. The cross-chain bridge is a smart contract-based protocol. First, the asset transfer and data collection are performed on the blockchain. Then, the four-level causal modeling described above is completed, referring to the previous embodiment.

[0109] Figure 3 This is a schematic diagram of a four-level causal modeling process for cross-chain operations involving asset transfers in this embodiment, as shown below. Figure 3 As shown, the first step is to input cross-chain transaction data. During the four-level causal modeling process, for transaction-level modeling, in the source chain ChainA, the input and output of transaction Tx_Lock are analyzed to determine if it is a locking transaction: its input is user A's balance of 100, and its output is the bridge contract's locking address. Therefore, it is concluded that this is a valid locking transaction. In the target chain ChainB, the input and output of transaction Tx_Mint are analyzed to determine if it is a minting transaction: its input is a call to the bridge contract's minting function (Mint function). Therefore, it is concluded that this is a valid minting transaction. Thus, two independent transaction-dependent chains are output during the transaction-level modeling stage. The modeling process determines whether a transaction is valid; if so, block-level modeling is performed; otherwise, modeling fails and the modeling process ends.

[0110] In block-level modeling, for the source chain, it's necessary to verify whether the locking transaction is included in block Bk_S and generate the corresponding Merkle inclusion proof (Proof_Merkle_S). For the target chain, it's necessary to verify whether the minting transaction is included in block Bk_T and generate the corresponding Merkle inclusion proof (Proof_Merkle_T). Finally, the block-level modeling stage outputs that the transaction has been confirmed by the network. If the transaction has been confirmed by the network, chain-level modeling proceeds; otherwise, the confirmation modeling fails.

[0111] In chain-level modeling, for the source chain, its state needs to be monitored to confirm that block Bk_S has reached finality (e.g., after waiting for sufficient subsequent block confirmations to ensure there is no reorganization risk). For the target chain, its state needs to be monitored to confirm that block Bk_T has reached finality. Finally, during the chain-level modeling phase, blocks Bk_S and Bk_T are marked as "safe," completing the reorganization risk assessment. Cross-chain level modeling proceeds only after block finality is confirmed; otherwise, modeling is considered a failure.

[0112] In cross-chain level modeling, it is necessary to match the send event (Send event) and receive event (Recv event) of the same message. It is also necessary to verify the consistency of the message hashes in the send and receive events, establishing a cross-chain causal edge "Send_Event→Recv_Event". Therefore, the cross-chain level modeling stage outputs the causal edges of successfully matched cross-chain message pairs, forming a complete global causal graph. Specifically, when the send event and receive event successfully match, a global causal graph is generated, confirming the completion of level four modeling. Otherwise, modeling failure is confirmed.

[0113] After completing the consistency verification process, causal consistency verification, temporal sequence verification, and state consistency verification are required. Specifically, in causal consistency verification, local causal preservation is first verified. If the verification finds that transaction Tx_Lock is the cause of the Send_Event, the verification passes; if the verification finds that the Recv_Event is the cause of transaction Tx_Mint, the verification passes. Cross-chain causal transitivity is then verified. Specifically, if the path "Tx_Lock→Send_Event→Recv_Event→Tx_Mint" exists, the verification is confirmed to pass. A global causal closure is then calculated. Specifically, the transitive closure is computed to confirm that transaction Tx_Lock can reach transaction Tx_Mint without circular dependencies, thus confirming the verification passes.

[0114] Next, time sequence verification is performed. This may include dynamic time window calibration, relative time sequence verification, and maximum delay constraint checking. Specifically, in dynamic time window calibration, a reasonable delay time window of [2, 120] seconds is calculated based on historical data. Then, it is checked whether the delay between all paired send and receive events is within this delay time window. In relative time sequence verification, it is necessary to verify whether the timestamp of transaction Tx_Lock (Tx_Lock.timestamp) is less than the timestamp of the send event (Send_Event.timestamp), and whether Send_Event.timestamp is less than the timestamp of the receive event (Recv_Event.timestamp), and whether Recv_Event.timestamp is less than the timestamp of transaction Tx_Mint (Tx_Mint.timestamp). If Tx_Lock.timestamp is 1000 seconds, Send_Event.timestamp is 1001 seconds, Recv_Event.timestamp is 1020 seconds, and Tx_Mint.timestamp is 1021 seconds, then the verification is confirmed to be successful. In the maximum delay constraint check, if:

[0115] If Recv_Event.timestamp - Send_Event.timestamp = 1020 seconds - 1001 seconds = 19 seconds, which is within a reasonable time window, then the verification is confirmed to be successful.

[0116] In the state consistency verification, the consistency of the source chain and the target chain is first checked. It is confirmed that the final state of the source chain is: User A's balance decreased by 100, and the bridge contract locked address's balance increased by 100. The final state of the target chain is: User A's corresponding balance increased by 100, and the bridge contract minting address's balance decreased by 100. Therefore, the conclusion is that state change is conserved (100 = 100), and the verification passes.

[0117] In intermediate state consistency verification, if the relay proof provided by the cross-chain bridge (such as Merkle Proof) is valid and matches the source chain state, the verification is confirmed to be successful.

[0118] In the final state consistency confirmation, it waits for the relevant blocks on both the source and target chains to reach finality (irreversible), confirming that no reorganization has occurred and affected the transaction. Therefore, the conclusion is: the operation is atomic, the final state is consistent, and the verification passes. Finally, the output test result is "Test case passed."

[0119] The following section will focus on verifying whether the asset lock in the source chain can be correctly rolled back when the target chain fails to forge, thus ensuring the atomicity of the operation.

[0120] In this application scenario, two test chains are launched, including the source chain ChainA and the target chain ChainB.

[0121] Deploy BridgeA on ChainA to handle locking; deploy BridgeB on ChainB to handle casting. At this point, a bug can be intentionally introduced to cause casting to fail under specific conditions.

[0122] User A transfers 100 yuan of cryptocurrency U from the source chain Chain A to the target chain Chain B. A test is performed, specifically by executing a script through a testing framework to demonstrate the cross-chain asset transfer. Assume that a bug in Bridge B causes minting to fail, and that Bridge A's rollback mechanism also has issues, resulting in the lock not being revoked.

[0123] Perform four - level modeling on the collected data. Among them, in the transaction - level modeling, the existence of transaction Tx_Lock (locked transaction) and transaction Tx_Mint_Fail (failed minting transaction) was successfully recorded. In the block - level modeling, it was successfully verified that both transaction Tx_Lock and transaction Tx_Mint_Fail were packed into their respective blocks, and a Merkle proof was generated. In the chain - level modeling, it was confirmed that both of these blocks reached finality and the network did not reorganize. In the cross - chain - level modeling, the send event (Send_Event) and the receive event (Recv_Event) were successfully matched, although the processing result of the receive event was a failure. Therefore, the four - level modeling stage was successfully completed, and this stage output an accurate global causal graph, which clearly showed a path: "Tx_Lock→Send_Even→Recv_Event→Tx_Mint_Fail".

[0124] Next, perform consistency verification. In the causal consistency verification, check the logical rationality of the causal graph. The corresponding verification process is to check whether the path "Tx_Lock→Send_Even→Recv_Event→Tx_Mint_Fail" exists and is acyclic. The causal consistency verification passed. Logically, "locking" causes "sending", "sending" causes "receiving", and the failure of "receiving" processing causes the result of "minting failure", which is reasonable in the logical chain. Causal consistency verification does not care about the right or wrong of business results, but only about the coherence of the causal chain.

[0125] After that, perform chronological order verification, which requires checking whether the timestamp order of all events is reasonable. The corresponding verification process is to check whether T_lock < T_send < T_recv < T_mint_fail is satisfied. Among them, T_lock is the timestamp of transaction Tx_Lock; T_send is the timestamp of the send event; T_recv is the timestamp of the receive event; T_mint_fail is the timestamp of transaction Tx_Mint_Fail. Assuming T_lock is 1000, T_send is 1001, T_recv is 1002, and T_mint_fail is 1003, then it is confirmed that the chronological order is correct and the chronological order verification passed.

[0126] In the state consistency verification, it is necessary to check whether the world state before and after the cross - chain operation is conserved and correct. The corresponding core rule is: the amount reduced on the source chain = the amount increased on the target chain + the handling fee. The corresponding verification process is: query the final state of the source chain (ChainA): balance = - 100, balance of the bridge contract locked address = + 100. Here, the two balance currencies are the same.

[0127] Query the final state of the target chain (ChainB): Balance = +0, Bridge Contract Minting Address Balance = +0. The currencies for both balances are the same.

[0128] Therefore, the assertion is executed: 100 == 0 + 0 (assuming the transaction fee is 0);

[0129] At this point, constructing the cause-effect graph and running the verification confirms that the state consistency verification failed because 100!=0.

[0130] Therefore, the test case failed. The generated test report will clearly state: "Inconsistency in state detected. State conservation was expected, but the source chain decreased by 100, and the target chain increased by 0. Atomicity guarantee failed."

[0131] Figure 4 This is a flowchart of a method for constructing a global cause-effect graph in some embodiments, such as Figure 4 As shown, the method for constructing this global cause-effect graph includes the following steps:

[0132] Step S401: Collect the data to be verified through the data acquisition layer; the specific acquisition process can be referred to the above embodiment.

[0133] Step S402 involves performing transaction-level modeling; this may specifically include transaction dependency analysis, atomic operation tracing, and state transition recording.

[0134] Step S403 involves performing block-level modeling; this may specifically include transaction packaging verification, Merkel proof generation, and block confirmation relationships.

[0135] Step S404 involves chain-level modeling, which may include state evolution tracking, finality verification, and reorganization risk detection.

[0136] Step S405 involves cross-chain level modeling; this may specifically include message mapping establishment, causal proof signing, and atomicity verification.

[0137] Step S406: Construction of the global causal graph; specifically, the outputs of steps S402 to S405 are integrated to obtain the global causal graph. The construction process also involves cross-chain message pair tagging and dependency analysis.

[0138] Step S407: Perform consistency verification based on the global cause-effect graph to obtain the verification result.

[0139] The steps S401 to S407 described above achieve four distinct and logically rigorous levels of modeling: transaction-level modeling, block-level modeling, chain-level modeling, and cross-chain-level modeling, thereby generating an accurate and comprehensive global causal graph.

[0140] Figure 5This is a flowchart of one of the consistency verification methods in some embodiments, such as Figure 5 As shown, the consistency verification method includes the following steps:

[0141] Step S501, input the global cause-effect graph;

[0142] Step S502, Causal consistency verification; which may include verification of local causal maintenance, cross-chain causal transitivity, and global causal closure;

[0143] Step S503, time sequence verification; which may include dynamic time window calibration, relative time sequence verification, and maximum delay constraint check;

[0144] Step S504, state consistency verification; which may include state consistency verification between the source chain and the target chain, intermediate state consistency verification, and final state consistency verification.

[0145] Step S505: Generate a consistency assertion;

[0146] Step S506: Determine whether all assertions pass; if yes, confirm successful verification; otherwise, confirm failed verification.

[0147] The steps S501 to S506 above perform causal consistency verification, temporal sequence verification, and state consistency verification based on the global causal graph, which can achieve comprehensive, accurate, more efficient, and more reliable cross-chain consistency verification.

[0148] Figure 6 This is a schematic diagram of the structure of a cross-chain data consistency verification system 60 provided in this embodiment, as shown below. Figure 6 As shown, the cross-chain data consistency verification system 60 may include: a data acquisition layer 62, a modeling layer 64, a verification layer 66, and an output layer 68. The data acquisition layer 62 includes a blockchain node agent, a cross-chain bridge monitor, and a data caching and preprocessing module; the modeling layer 64 may include a transaction-level modeling module, a block-level modeling module, a chain-level modeling module, and a cross-chain-level modeling module; the verification layer 66 may include a causal consistency verifier, a time-series verifier, and a state consistency verifier; and the output layer 68 may include a verification report generation module, a visualization dashboard, and an application programming interface (API). All of the above-mentioned data acquisition layer 62, modeling layer 64, verification layer 66, and output layer 68 can be implemented using software. The cross-chain data consistency verification system 60 is connected to a test management platform. The data acquisition layer 62 is connected to the blockchain cross-chain network environment.

[0149] This embodiment also provides a cross-chain data consistency verification device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. The terms "module," "unit," "subunit," etc., used below can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0150] Figure 7 This is a structural block diagram of the cross-chain data consistency verification device 70 in this embodiment, as shown below. Figure 7 As shown, the cross-chain data consistency verification device 70 includes: an acquisition module 72, a multi-level modeling module 74, and a consistency verification module 76; wherein:

[0151] The acquisition module 72 is used to acquire the data to be verified; the multi-level modeling module 74 is used to perform multi-level modeling of the blockchain system structure on the data to be verified, and obtain a global causal graph for each event in the cross-chain data; the global causal graph uses events as nodes and the causal relationships between events as edges; the consistency verification module 76 is used to perform causal consistency verification, time sequence verification and state consistency verification on the cross-chain data based on the global causal graph, and obtain the verification results.

[0152] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0153] In one embodiment, the multi-level modeling module 74 is used to perform transaction dependency modeling, block-level causal relationship modeling, chain state view modeling, and cross-chain message causal relationship modeling on the data to be verified, respectively, to obtain a global causal graph for each event in the cross-chain data.

[0154] In one embodiment, the multi-level modeling module 74 is used to perform input-output dependency analysis and smart contract state tracking based on the original transaction data, smart contract call event logs, and transaction input and output information in the data to be verified, so as to obtain a transaction dependency graph that represents the transaction dependency relationship.

[0155] In one embodiment, the multi-level modeling module 74 is used to verify the packaging order of transactions within a block based on the block header data in the data to be verified, the transaction data contained in the block, and the transaction dependency modeling results, and to establish causal relationships between blocks and transactions, and between blocks, to obtain a block-level causal graph.

[0156] In one embodiment, the multi-level modeling module 74 is used to perform state evolution tracking, block final determination state verification, and block reorganization risk detection based on the block continuous sequence and the latest state root of the node in the data to be verified, so as to obtain a chain state view with a finality verification label and a reorganization risk verification label.

[0157] In one embodiment, the multi-level modeling module 74 is used to perform message pair matching, causal proof generation of cross-chain events, and atomicity verification of cross-chain operations on the source chain and target chain based on the source chain's sending events, the target chain's receiving events, and cross-chain transmission information in the data to be verified, so as to obtain the cross-chain modeling result.

[0158] In one embodiment, the consistency verification module 76 is used to perform local causal maintenance verification on the causal dependency relationship of events on the same chain in the blockchain system based on the global causal graph using preset verification rules; and to verify the causal transitivity of cross-chain events based on the global causal graph; and to calculate the transitive closure matrix of the global causal graph to perform closure logic verification on the global causal graph.

[0159] In one embodiment, the consistency verification module 76 is used to identify anomalies in the delay time between two events belonging to the same message pair in the global causal graph based on a preset time window; and to verify the relative time order of the timestamps of each event according to the causal relationship of each event in the global causal graph.

[0160] In one embodiment, the consistency verification module 76 is used to verify the consistency of the state of cross-chain data in the source chain and the target chain based on a global causal graph; and to verify the consistency of the intermediate state of cross-chain data; and to verify the consistency of the final state of cross-chain data.

[0161] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0162] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0163] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0164] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0165] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0166] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A cross-chain data consistency verification method, characterized in that, For use in a blockchain system, the method includes: Retrieve the data to be verified; The blockchain system structure is modeled in a multi-level manner for the data to be verified, resulting in a global causal graph for each event in the cross-chain data; the global causal graph uses the events as nodes and the causal relationships between the events as edges. Based on the global causal graph, the cross-chain data is subjected to causal consistency verification, temporal sequence verification, and state consistency verification to obtain the verification results.

2. The cross-chain data consistency verification method according to claim 1, characterized in that, Multi-level modeling of the blockchain system structure is performed on the data to be verified to obtain a global causal graph for each event in the cross-chain data, including: The transaction dependency model, block-level causal relationship model, chain state view model, and cross-chain message causal relationship model are respectively performed on the data to be verified to obtain a global causal graph for each event in the cross-chain data.

3. The cross-chain data consistency verification method according to claim 2, characterized in that, Modeling transaction dependencies for the data to be verified includes: Based on the original transaction data, smart contract call event logs, and transaction input and output information in the data to be verified, input and output dependency analysis and smart contract state tracking are performed to obtain a transaction dependency graph that represents the transaction dependency relationship.

4. The cross-chain data consistency verification method according to claim 2, characterized in that, Block-level causal relationship modeling is performed on the data to be verified, including: Based on the block header data, transaction data contained in the block, and transaction dependency modeling results in the data to be verified, the packaging order of transactions within the block is verified, and causal relationships between blocks and transactions, and between blocks themselves are established to obtain a block-level causal graph.

5. The cross-chain data consistency verification method according to claim 2, characterized in that, Modeling the chain state view of the data to be verified includes: Based on the continuous sequence of blocks and the latest state root of the nodes in the data to be verified, state evolution tracking, final determination state verification of blocks, and reorganization risk detection of blocks are performed to obtain a chain state view with finality verification label and reorganization risk verification label.

6. The cross-chain data consistency verification method according to claim 2, characterized in that, Modeling the causal relationships of cross-chain messages for the data to be verified includes: Based on the source chain's sending events, the target chain's receiving events, and cross-chain transmission information in the data to be verified, message pair matching, causal proof generation of cross-chain events, and atomicity verification of cross-chain operations are performed on the source chain and the target chain to obtain the cross-chain modeling results.

7. The cross-chain data consistency verification method according to any one of claims 1 to 6, characterized in that, Based on the global causal graph, causal consistency verification is performed on the cross-chain data, including: Using preset verification rules and based on the global causal graph, local causal maintenance verification is performed on the causal dependencies of events on each chain in the blockchain system; and, Based on the aforementioned global causal graph, the causal transitivity of cross-chain events is verified; and, Calculate the transitive closure matrix of the global causal graph to perform closure logic verification on the global causal graph.

8. The cross-chain data consistency verification method according to any one of claims 1 to 6, characterized in that, Based on the global causal graph, the cross-chain data is verified for its temporal order, including: Based on a preset time window, anomalies are identified in the delay time between two events belonging to the same message pair in the global causal graph; and... Based on the causal relationships of each event in the global causal graph, the relative time sequence of the timestamps of each event is verified.

9. The cross-chain data consistency verification method according to any one of claims 1 to 6, characterized in that, Based on the global causal graph, state consistency verification is performed on the cross-chain data, including: Based on the global causal graph, the consistency of the cross-chain data in the source chain and the target chain is verified; the consistency of the intermediate state of the cross-chain data is verified; and the consistency of the final state of the cross-chain data is verified.

10. A cross-chain data consistency verification device, characterized in that, include: The module includes an acquisition module, a multi-level modeling module, and a consistency verification module; among which: The acquisition module is used to acquire the data to be verified; The multi-level modeling module is used to perform multi-level modeling of the blockchain system structure on the data to be verified, and obtain a global causal graph for each event in the cross-chain data; the global causal graph uses the event as a node and the causal relationship between the event as an edge; The consistency verification module is used to perform causal consistency verification, time sequence verification, and state consistency verification on the cross-chain data based on the global causal graph, and obtain the verification results.

Images