A cross-chain transaction process tracking method and device

Abstract

The application provides a cross-chain transaction process tracking method and device. The method comprehensively considers the relay chain, cross-chain gateway and general protocol of the BitXHub platform. Specifically, identity information and logs of each cross-chain gateway between the source chain and the destination chain are obtained, the calling relationship between each cross-chain gateway, the source chain, the destination chain and the relay chain is determined based on the logs of each cross-chain gateway, the general protocol data between each cross-chain gateway and the relay chain is obtained, the general protocol data is analyzed, cross-chain transaction information is obtained, the calling relationship topology network between each cross-chain gateway, the source chain, the destination chain and the relay chain is determined based on the calling relationship and the cross-chain transaction information, the calling relationship network is visually displayed, the cross-chain transaction process is tracked, and the cross-chain transaction process of the Bitxhub platform is restored in a visual form.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method and apparatus for tracking cross-chain transaction processes. Background Technology

[0002] As blockchain applications expand into various scenarios, the need for integration between these scenarios is becoming increasingly apparent. However, different heterogeneous blockchains differ in their technical frameworks, communication protocols, consensus mechanisms, and storage structures, resulting in isolated value islands where on-chain asset data is difficult to interconnect, thus hindering the promotion and use of blockchain.

[0003] Cross-chain technology (such as cross-chain platforms developed based on sidechain / relay chain technology) is the key to solving the problem of how blockchains can interconnect and is the core of promoting the secure and reliable transmission of value information between chains. Cross-chain technology enables necessary information conversion between different blockchain systems and completes cross-chain transactions to utilize the value data between different blockchains.

[0004] However, there is currently a lack of methods to track the transaction process of cross-chain platforms developed based on sidechain / relay chain technology, which affects the regulation of cross-chain platforms. Summary of the Invention

[0005] This application provides the following technical solution:

[0006] This application provides a method for tracking cross-chain transactions based on the BitXHub platform, which includes a source chain, a destination chain, a cross-chain gateway, and a relay chain. The method includes:

[0007] Obtain the identity information and logs of each cross-chain gateway between the source chain and the destination chain;

[0008] Based on the identity information and logs of each cross-chain gateway, the calling relationship between each cross-chain gateway, the source chain, the destination chain, and the relay chain is determined.

[0009] Obtain common protocol data between each of the cross-chain gateways and the relay chain, parse the common protocol data, and obtain cross-chain transaction information;

[0010] Based on the call relationships and the cross-chain transaction information, a call relationship topology network is constructed between each of the cross-chain gateways, the source chain, the destination chain, and the relay chain;

[0011] The aforementioned call relationship network is visualized.

[0012] Optional, logs from each cross-chain gateway, including: logs of type INTERCHAIN ​​and logs of type RECEIPT_SUCCESS;

[0013] Based on the identity information and logs of each cross-chain gateway, the call relationships between each cross-chain gateway, the source chain, the destination chain, and the relay chain are determined, including:

[0014] Based on the identity information of each cross-chain gateway, the cross-chain gateway that generated the log is determined to be the cross-chain gateway between the destination chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain.

[0015] Parse the logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain and the call relationship between the destination chain and the relay chain;

[0016] The logs of type RECEIPT_SUCCESS are parsed to obtain the call relationship between the cross-chain gateway between the source chain and the relay chain and between the source chain and the relay chain.

[0017] Optionally, parsing logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain, and the call relationship between the destination chain and the relay chain, includes:

[0018] Parse the logs of type INTERCHAIN ​​to obtain the log portion of type INTERCHAIN ​​containing the keyword Apply tx and the log portion of type INTERCHAIN ​​containing the keyword Handle ibtp success;

[0019] The call relationship between the cross-chain gateway and the target chain, determined from the log section of type INTERCHAIN ​​containing the keyword Apply tx, is that the cross-chain gateway submitted a cross-chain transaction request to the target chain.

[0020] The call relationship between the cross-chain gateway and the relay chain is determined from the log section of type INTERCHAIN ​​containing the keyword Handle ibtp success. This relationship is as follows: the cross-chain gateway between the target chain and the relay chain receives a transaction receipt returned by the target chain in response to the cross-chain transaction request. The call relationship between the cross-chain gateway between the target chain and the relay chain is as follows: the cross-chain gateway between the target chain and the relay chain sends a routing forwarding request corresponding to the transaction receipt to the relay chain.

[0021] Optionally, parsing logs of type RECEIPT_SUCCESS to obtain the call relationship between the cross-chain gateway between the source chain and the relay chain and between the source chain and the relay chain includes:

[0022] Parse the logs of type RECEIPT_SUCCESS to obtain the log portion of type RECEIPT_SUCCESS containing the keyword Apply tx and the log portion of type RECEIPT_SUCCESS containing the keyword Handle ibtpreceipt success;

[0023] From the log section of type RECEIPT_SUCCESS containing the keyword Apply tx, it is determined that the call relationship between the cross-chain gateway between the source chain and the relay chain and the source chain and the relay chain is that the relay chain sent a routing forwarding request corresponding to the transaction receipt to the cross-chain gateway between the source chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain sent the transaction receipt to the source chain;

[0024] The call relationship between the cross-chain gateway between the source chain and the relay chain is determined from the log section of type RECEIPT_SUCCESS containing the keyword Handle ibtp receipt success. This relationship is as follows: the cross-chain gateway between the source chain and the relay chain receives the response information returned by the source chain for the transaction receipt, and then forwards the response information to the relay chain.

[0025] Optionally, the cross-chain transaction information includes at least:

[0026] The source chain ID, the destination chain ID, the contract ID, the contract parameters, and the result set.

[0027] This application, in another aspect, provides a cross-chain transaction tracking device based on the BitXHub platform, which includes: a source chain, a destination chain, a cross-chain gateway, and a relay chain. The device includes:

[0028] The first acquisition module is used to acquire the identity information and logs of each cross-chain gateway between the source chain and the destination chain;

[0029] The determination module is used to determine the calling relationship between each cross-chain gateway, the source chain, the destination chain, and the relay chain based on the identity information and logs of each cross-chain gateway;

[0030] The second acquisition module is used to acquire the common protocol data between each of the cross-chain gateways and the relay chain, parse the common protocol data, and acquire cross-chain transaction information.

[0031] The construction module is used to construct a topology network of call relationships between each of the cross-chain gateways, the source chain, the destination chain, and the relay chain based on the call relationships and the cross-chain transaction information.

[0032] The display module is used to visualize the call relationship network.

[0033] Optional, logs from each cross-chain gateway, including: logs of type INTERCHAIN ​​and logs of type RECEIPT_SUCCESS;

[0034] The module is specifically used for:

[0035] Based on the identity information and logs of each cross-chain gateway, the call relationships between each cross-chain gateway, the source chain, the destination chain, and the relay chain are determined, including:

[0036] Based on the identity information of each cross-chain gateway, the cross-chain gateway that generated the log is determined to be the cross-chain gateway between the destination chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain.

[0037] Parse the logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain and the call relationship between the destination chain and the relay chain;

[0038] The logs of type RECEIPT_SUCCESS are parsed to obtain the call relationship between the cross-chain gateway between the source chain and the relay chain and between the source chain and the relay chain.

[0039] Optionally, the process by which the determining module parses logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain, and the call relationship between the destination chain and the relay chain, specifically includes:

[0040] Parse the logs of type INTERCHAIN ​​to obtain the log portion of type INTERCHAIN ​​containing the keyword Apply tx and the log portion of type INTERCHAIN ​​containing the keyword Handle ibtp success;

[0041] The call relationship between the cross-chain gateway and the target chain, determined from the log section of type INTERCHAIN ​​containing the keyword Apply tx, is that the cross-chain gateway submitted a cross-chain transaction request to the target chain.

[0042] The call relationship between the cross-chain gateway and the relay chain is determined from the log section of type INTERCHAIN ​​containing the keyword Handle ibtp success. This relationship is as follows: the cross-chain gateway between the target chain and the relay chain receives a transaction receipt returned by the target chain in response to the cross-chain transaction request. The call relationship between the cross-chain gateway between the target chain and the relay chain is as follows: the cross-chain gateway between the target chain and the relay chain sends a routing forwarding request corresponding to the transaction receipt to the relay chain.

[0043] Optionally, the process by which the determining module parses logs of type RECEIPT_SUCCESS to obtain the cross-chain gateway between the source chain and the relay chain and the call relationship between the source chain and the relay chain specifically includes:

[0044] Parse the logs of type RECEIPT_SUCCESS to obtain the log portion of type RECEIPT_SUCCESS containing the keyword Apply tx and the log portion of type RECEIPT_SUCCESS containing the keyword Handle ibtpreceipt success;

[0045] From the log section of type RECEIPT_SUCCESS containing the keyword Apply tx, it is determined that the call relationship between the cross-chain gateway between the source chain and the relay chain and the source chain and the relay chain is that the relay chain sent a routing forwarding request corresponding to the transaction receipt to the cross-chain gateway between the source chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain sent the transaction receipt to the source chain;

[0046] The call relationship between the cross-chain gateway between the source chain and the relay chain is determined from the log section of type RECEIPT_SUCCESS containing the keyword Handle ibtp receipt success. This relationship is as follows: the cross-chain gateway between the source chain and the relay chain receives the response information returned by the source chain for the transaction receipt, and then forwards the response information to the relay chain.

[0047] Optionally, the cross-chain transaction information includes at least:

[0048] The source chain ID, the destination chain ID, the contract ID, the contract parameters, and the result set.

[0049] Compared with the prior art, the beneficial effects of this application are as follows:

[0050] This application comprehensively considers the relay chain, cross-chain gateways, and general protocol of the BitXHub platform. Specifically, it obtains the identity information and logs of each cross-chain gateway between the source chain and the destination chain, and determines the call relationships between each cross-chain gateway, source chain, destination chain, and relay chain based on the logs of each cross-chain gateway. It also obtains the general protocol data between each cross-chain gateway and the relay chain, parses the general protocol data to obtain cross-chain transaction information, and determines the topology network of call relationships between each cross-chain gateway, source chain, destination chain, and relay chain based on the call relationships and cross-chain transaction information. The application also visualizes the call relationship network to track the cross-chain transaction process and reconstruct the cross-chain transaction process of the BitXHub platform in a visual form. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1This is a schematic diagram of a cross-chain transaction process provided in this application;

[0053] Figure 2 This is a flowchart illustrating a cross-chain transaction tracking method provided in Embodiment 1 of this application;

[0054] Figure 3 This is a schematic diagram of the structure of a cross-chain transaction tracking device provided in this application. Detailed Implementation

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

[0056] To address the aforementioned issues, this application provides a method for tracing cross-chain transaction processes, which will be described below.

[0057] The cross-chain transaction tracking method provided in this application is based on the BitXHub platform. The BitXHub platform supports cross-chain transactions between homogeneous and heterogeneous blockchains, and is compatible with asset swaps and identity verification between heterogeneous chains. It is one of the more mature open-source cross-chain platforms currently available in China. The BitXHub platform typically consists of three parts: a relay chain, a cross-chain gateway, and an application chain. The application chain can be further divided into a source chain and a destination chain based on the transaction process.

[0058] In this application, "App-chain" refers to a blockchain that is part of the BitXHub platform and is responsible for the contract logic of specific business scenarios. Typical examples include Ethereum, Hyperledger Fabric, and other blockchains that BitXHub supports accessing.

[0059] In this application, "Relay-chain" specifically refers to a core component of the BitXHub platform. It is a special set of blockchains primarily responsible for managing application chains, verifying cross-chain information, and routing cross-chain transactions, thereby ensuring the consistency of cross-chain transactions. It should be noted that the relay-chain discussed here does not represent general relay-chain cross-chain technology, but is merely one component of the BitXHub platform. When explaining relay-chain cross-chain technology, the word "technology" will be specifically used.

[0060] In this application, "Cross-chain gateway (Pier)" refers to one of the components of the BitXHub platform. It is a bridge between the relay chain and the application chain, responsible for collecting cross-chain transaction information sent by the application chain and converting the event data format thrown by the application chain into IBTP universal protocol data that can be recognized by the BitXHub platform.

[0061] In this application, the "plugin mechanism" refers to the BitXHub platform's plug-in approach to better support the integration of different heterogeneous application chains. When the Pier cross-chain gateway is running, it dynamically loads different plugins to flexibly adapt to different application chains, thereby improving the interactivity between Pier and different application chains. When a specific application chain needs to be integrated, the plugin's interaction interface only needs to be implemented according to the characteristics of the different application chains to complete the plugin integration. The plugin interface to be implemented must cover at least three functions: first, listening for cross-chain events on the application chain and passing them to the core module for processing; second, executing cross-chain requests from the cross-chain gateway; and third, actively querying the status of received and executed cross-chain requests on the application chain.

[0062] In this application, "cross-chain contract" refers to a contract designed for cross-chain transactions. Cross-chain contracts are deployed on the application chain. Unlike general business contracts, cross-chain contracts include the throwing of events, which are subscribed to by the Pier plugin of the corresponding application chain, thereby realizing the exchange of information.

[0063] In this application, "ProtoBuf" refers to protocol buffers launched by Google, which is a language-independent, platform-independent, and scalable method for serializing structured data. It can be used for communication protocols, data storage, etc. The BitXHub source code provides a variety of files with the .pb extension. Based on files such as .pb, the transmitted data can be decrypted to a certain extent.

[0064] All parts of the BitXHub platform can transmit cross-chain transaction messages through IBTP (Inter Blockchain Transfer Protocol, a universal cross-chain transmission protocol provided by the BitXHub platform), enabling blockchain messages from different heterogeneous entities to be forwarded and routed on the BitXHub platform with the help of the unified IBTP protocol.

[0065] The BitXHub platform includes: a source chain, a destination chain, a cross-chain gateway, and a relay chain. Among them, such as... Figure 1 As shown, the basic flow of cross-chain transactions between various modules in the BitXHub platform is as follows:

[0066] Decentralized application A initiates a cross-chain business contract to application chain A (i.e., the source chain) through SDK or other means. The parameters include the chain ID of the application chain B to be called (i.e., the destination chain), the contract method, etc.

[0067] When application chain A receives a request initiated by application A, it enters the specified cross-chain contract method, executes the contract, and finally throws a cross-chain event TA to cross-chain gateway A (i.e., the cross-chain gateway between the source chain and the relay chain).

[0068] When the application chain plugin of cross-chain gateway A detects that application chain A has initiated a cross-chain event TA, it converts the cross-chain data into the relay chain's common IBTP structure and encapsulates the IBTP into a transaction type that the relay chain can recognize.

[0069] Cross-chain gateway A submits cross-chain data of IBTP transaction type to the relay chain (one or more relay chain nodes).

[0070] The relay chain verifies cross-chain data of IBTP transaction types, such as the legality of the transaction. After verification, consensus is reached, a block is generated, and submitted to the execution module. The execution module verifies the validity of the destination address of the transaction. If the address is valid, it is handed over to the routing module.

[0071] The relay chain encapsulates the cross-chain transaction again through the routing module and forwards the cross-chain transaction to the corresponding cross-chain gateway B.

[0072] After receiving a cross-chain transaction, the cross-chain gateway B (i.e., the cross-chain gateway between the relay chain and the destination chain) verifies it. If the verification is correct, it parses the IBTP structure into a transaction structure that the application chain B can recognize and submits it to the application chain B.

[0073] Based on the transmitted transaction structure, application chain B identifies and executes the specified contract method, and returns the response to application chain B.

[0074] In addition, application chain B will send a cross-chain transaction receipt to cross-chain gateway B, and forward it to application chain A through the relay chain and cross-chain gateway A. Application chain A will identify whether the receipt is successful. If successful, it will submit the transaction. If it fails or the content shows that the cross-chain transaction has timed out, it will execute a rollback to roll back the transaction.

[0075] As can be seen from the nine steps above, a cross-chain transaction does not involve just one component, but rather is an organic combination of multiple modules. Tracking the cross-chain process helps regulators to comprehensively control the effective status of cross-chain transactions, identify anomaly points, and determine deeper operational issues such as event handling logic. To track the flow of a cross-chain transaction on the BitXHub platform, it is crucial to identify the processing of cross-chain data by the cross-chain gateway and relay chain. Data transmission between the cross-chain gateway and relay chain uses the IBTP protocol, and its field format is shown in Table 1. The two fields From and To represent the source chain ID and destination chain ID, respectively. These IDs are generated during application chain registration and can be used to identify the two parties involved in the cross-chain transaction.

[0076] Table 1

[0077]

[0078] However, the IBTP protocol only provides basic data on cross-chain transactions, leaving the details of how these transactions are processed unavailable. Further analysis of the cross-chain gateway and relay chain's handling of cross-chain transactions is needed. The logs of the cross-chain gateway and relay chain contain a wealth of information, which, combined with the rich API interfaces provided by the BitXHub platform's relay chain, can enrich the data on the cross-chain transaction process.

[0079] Reference Figure 2 This is a flowchart illustrating a cross-chain transaction tracking method provided in Embodiment 1 of this application. Figure 2 As shown, the method may include, but is not limited to, the following steps:

[0080] Step S11: Obtain the identity information and logs of each cross-chain gateway between the source chain and the destination chain.

[0081] The identity information of each cross-chain gateway can be used to distinguish which cross-chain gateway generated the log information. The identity information of a cross-chain gateway may include, but is not limited to: the host address where the cross-chain gateway is deployed, the host domain name, and the path of the pier application plugin, etc.

[0082] The logs of each cross-chain gateway contain a wealth of information that can be used to track the cross-chain transaction process.

[0083] Step S12: Based on the identity information and logs of each cross-chain gateway, determine the calling relationship between each cross-chain gateway, the source chain, the destination chain, and the relay chain.

[0084] It is understood that the logs of the cross-chain gateway at least record the data transmission direction during the transaction process. Based on the data transmission direction, the calling relationship between each cross-chain gateway, source chain, destination chain, and relay chain can be determined.

[0085] Step S13: Obtain the common protocol data between each of the cross-chain gateways and the relay chain, parse the common protocol data, and obtain cross-chain transaction information.

[0086] Since cross-chain gateways and relay chains are used to forward transaction data between the source chain and the destination chain, they specifically encapsulate the transaction data between the source chain and the destination chain into general protocol data. Therefore, cross-chain transaction information can be obtained by parsing the general protocol data.

[0087] In this embodiment, cross-chain transaction information may include, but is not limited to: the source chain ID, the destination chain ID, the contract ID, contract parameters, and the result set.

[0088] Obtaining common protocol data between each of the cross-chain gateways and the relay chain may include, but is not limited to:

[0089] Utilize the multi-language SDKs provided by the BitXHub platform's relay chain to obtain detailed transaction information. Refer to the official Java-based relay chain SDK (https: / / github.com / meshplus / java-bitxhub-client) and the PIR plugin source code, such as the Fabric plugin (https: / / github.com / meshplus / pier-client-fabric), to obtain basic information about cross-chain transactions.

[0090] And / or,

[0091] Based on the IBTP-ID contained in the logs of the cross-chain gateway (which contains the source chain ID, destination chain ID, and version number, and the ID is unique), more detailed data, including basic transaction information such as the call parameters and contract name, can be obtained by using the unpackIBTP() method for unpacking the IBTP protocol provided in the client.go of the plugin (meshplus / pier-client-fabric / client.go).

[0092] And / or,

[0093] Ethereum plugins can also be used to process IBTP protocol data, and the appropriate method can be selected for protocol parsing based on the type of application chain being connected.

[0094] The general protocol data between each of the cross-chain gateways and the relay chain may include, but is not limited to, IBTP (Inter Blockchain Transfer Protocol, a general cross-chain transfer protocol provided by the BitXHub platform) data between each of the cross-chain gateways and the relay chain.

[0095] Step S14: Based on the call relationship and the cross-chain transaction information, construct a call relationship topology network between each of the cross-chain gateways, the source chain, the destination chain, and the relay chain.

[0096] In this embodiment, each of the cross-chain gateways, the source chain, the destination chain, and the relay chain are treated as different nodes. Based on the calling relationship, the association between each node is constructed to obtain the calling relationship topology network between each of the cross-chain gateways, the source chain, the destination chain, and the relay chain. The cross-chain transaction information is used as supplementary information between nodes.

[0097] Step S15: Visualize the call relationship network.

[0098] The call relationship network can be visualized using a visualization component that displays the relationships between points and edges. This visualization component can include, but is not limited to, Ant Financial's open-source Graphin component or Echarts relationship component.

[0099] This application comprehensively considers the relay chain, cross-chain gateways, and general protocol of the BitXHub platform. Specifically, it obtains the identity information and logs of each cross-chain gateway between the source chain and the destination chain, and determines the call relationships between each cross-chain gateway, source chain, destination chain, and relay chain based on the logs of each cross-chain gateway. It also obtains the general protocol data between each cross-chain gateway and the relay chain, parses the general protocol data to obtain cross-chain transaction information, and determines the topology network of call relationships between each cross-chain gateway, source chain, destination chain, and relay chain based on the call relationships and cross-chain transaction information. The application also visualizes the call relationship network to track the cross-chain transaction process and reconstruct the cross-chain transaction process of the BitXHub platform in a visual form.

[0100] As another optional embodiment of this application, this embodiment 2 is mainly a refinement of step S12 in embodiment 1 above. The logs of each cross-chain gateway may include: logs of type INTERCHAIN ​​and logs of type RECEIPT_SUCCESS.

[0101] Logs of type INTERCHAIN ​​can be collected in the following ways:

[0102] The open-source cross-chain gateway Pier only provides a local deployment option. Log files are specified in the pier.toml configuration file, and there are multiple ways to collect local log files, not limited to using components like Filebeat. The presence of the keyword "type=INTERCHAIN" in the Info logs indicates object data that needs to be collected, as logs of type INTERCHAIN ​​are the processing type used by the cross-chain gateway for routing and forwarding cross-chain transaction requests.

[0103] Logs of type RECEIPT_SUCCESS can be collected in the following ways:

[0104] The appearance of the keyword "type=RECEIPT_SUCCESS" in the Info log indicates that the log is collected object data, because logs of type RECEIPT_SUCCESS are the processing type of cross-chain gateways for routing and forwarding cross-chain transaction receipts.

[0105] Based on this, step S12 may include, but is not limited to, the following steps:

[0106] S121. Based on the identity information of each of the cross-chain gateways, determine that the cross-chain gateway that generated the log is the cross-chain gateway between the destination chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain.

[0107] S122. Parse the logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain and the call relationship between the destination chain and the relay chain.

[0108] S123. Parse the logs of type RECEIPT_SUCCESS to obtain the call relationship between the cross-chain gateway between the source chain and the relay chain and between the source chain and the relay chain.

[0109] In this embodiment, step S122 may include, but is not limited to:

[0110] S1221. Parse the logs of type INTERCHAIN ​​to obtain the log portion of type INTERCHAIN ​​containing the keyword Apply tx and the log portion of type INTERCHAIN ​​containing the keyword Handle ibtp success.

[0111] There are two main types of INTERCHAIN ​​logs. One is a log for submitted transactions, a simple example being: "INFO [timestamp] Apply tx from=source chain ID id=source chain ID-destination chain ID-version number index=1 module=executor status=true type=INTERCHAIN". This requires parsing INTERCHAIN ​​type logs with the fixed keyword "Applytx". It represents a cross-chain request log forwarded from the relay chain by the cross-chain gateway, indicating the source and destination chains. The IBTP protocol data needs to be converted into a data format recognizable by the destination chain. This log allows identification of the process by which the cross-chain gateway forwards cross-chain requests to the destination chain.

[0112] Another scenario corresponding to the INTERCHAIN ​​log type is the IBTP-encapsulated receipt log. A simple example is as follows: "INFO[timestamp] Handle ibtp success id=source chain ID-destination chain ID-version number module=exchangeer type=INTERCHAIN". Parsing the INTERCHAIN ​​type log with the fixed keyword "Handle ibtp success" indicates that the destination chain has successfully received the cross-chain transaction and sent a response receipt to the cross-chain gateway. The cross-chain gateway re-encapsulates this message into an IBTP type transaction and forwards it to the relay chain. The logs reveal the process of the cross-chain gateway receiving the destination chain's response and forwarding the destination chain's cross-chain receipt to the relay chain.

[0113] S1222. Determine the call relationship between the cross-chain gateway and the target chain from the log section of type INTERCHAIN ​​containing the keyword Apply tx. The cross-chain gateway submits a cross-chain transaction request to the target chain.

[0114] The call relationship between the cross-chain gateway and the target chain can be represented as <cross-chain gateway, target chain>, indicating that the cross-chain gateway submits a cross-chain transaction request to the target chain.

[0115] S1223. From the log section of type INTERCHAIN ​​containing the keyword Handle ibtp success, determine the call relationship between the cross-chain gateway between the destination chain and the relay chain and the destination chain: the cross-chain gateway between the destination chain and the relay chain receives a transaction receipt returned by the destination chain in response to the cross-chain transaction request; and the call relationship between the cross-chain gateway between the destination chain and the relay chain and the relay chain is that the cross-chain gateway between the destination chain and the relay chain sends a routing forwarding request corresponding to the transaction receipt to the relay chain.

[0116] The call relationship between the cross-chain gateway between the destination chain and the relay chain and the destination chain can be represented as <destination chain, cross-chain gateway>, indicating that the cross-chain gateway between the destination chain and the relay chain receives a transaction receipt returned by the destination chain in response to the cross-chain transaction request.

[0117] Meanwhile, the call relationship between the cross-chain gateway between the destination chain and the relay chain and the relay chain can be represented as <cross-chain gateway, relay chain>, indicating that the cross-chain gateway between the destination chain and the relay chain sends the routing forwarding request corresponding to the transaction receipt to the relay chain.

[0118] In this embodiment, step S123 may include, but is not limited to:

[0119] S1231. Parse the logs of type RECEIPT_SUCCESS to obtain the log portion of type RECEIPT_SUCCESS containing the keyword Apply tx and the log portion of type RECEIPT_SUCCESS containing the keyword Handle ibtp receipt success.

[0120] There are two main types of RECEIPT_SUCCESS logs. One is a log for submitting transaction receipts, a simple example being: "INFO [timestamp] Apply tx from=source chain ID id=source chain ID-destination chain ID-version number index=1 module=executor status=true type=RECEIPT_SUCCESS". Parsing RECEIPT_SUCCESS logs with the fixed keyword "Apply tx" indicates that the cross-chain gateway has received a cross-chain transaction receipt log forwarded from the relay chain, specifying both the source and destination chains. The IBTP protocol data needs to be converted into a data format recognizable by the source chain. This log reveals the process of the cross-chain gateway forwarding the cross-chain transaction receipt to the source chain.

[0121] Another scenario corresponding to the RECEIPT_SUCCESS log type is the IBTP-encapsulated receipt processing log. A simple example is as follows: "INFO[timestamp] Handle ibtp receipt success id=source chain ID-destination chain ID-version number module=exchangeer type=RECEIPT_SUCCESS". The RECEIPT_SUCCESS type log, with the fixed keyword "Handleibtp receipt success", needs to be parsed. This indicates that the source chain has successfully received the cross-chain transaction receipt and responded to the cross-chain gateway with the receipt processing result. The cross-chain gateway re-encapsulates this message into an IBTP-type transaction and forwards the transaction to the relay chain. The logs can be used to identify the process of the cross-chain gateway receiving the transaction receipt response from the source chain and forwarding the cross-chain receipt result from the source chain to the relay chain.

[0122] S1232. From the log section of type RECEIPT_SUCCESS containing the keyword Apply tx, it is determined that the call relationship between the cross-chain gateway between the source chain and the relay chain and the source chain and the relay chain is that the relay chain sent a routing forwarding request corresponding to the transaction receipt to the cross-chain gateway between the source chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain sent the transaction receipt to the source chain.

[0123] The call relationship between the cross-chain gateway between the source chain and the relay chain and the relay chain can be represented as <relay chain, cross-chain gateway>, indicating that the relay chain sent a routing forwarding request corresponding to the transaction receipt to the cross-chain gateway between the source chain and the relay chain.

[0124] The call relationship between the cross-chain gateway between the source chain and the relay chain and the source chain can be represented as <cross-chain gateway, source chain>, indicating that the cross-chain gateway between the source chain and the relay chain sends the transaction receipt to the source chain.

[0125] S1233. From the log section of type RECEIPT_SUCCESS containing the keyword Handle ibtp receiptsuccess, determine the call relationship between the cross-chain gateway between the source chain and the relay chain and the source chain and the relay chain. The cross-chain gateway between the source chain and the relay chain receives the response information returned by the source chain for the transaction receipt, and the cross-chain gateway between the source chain and the relay chain forwards the response information to the relay chain.

[0126] The calling relationship between the cross-chain gateway between the source chain and the relay chain and the source chain can be represented as <source chain, cross-chain gateway>, indicating that the cross-chain gateway between the source chain and the relay chain receives the response information returned by the source chain for the transaction receipt.

[0127] The call relationship between the cross-chain gateway between the source chain and the relay chain and the relay chain can be represented as <cross-chain gateway, relay chain>, whereby the cross-chain gateway between the source chain and the relay chain forwards the response information to the relay chain.

[0128] The cross-chain transaction tracking device provided in this application will be described below. The cross-chain transaction tracking device described below can be referred to in correspondence with the cross-chain transaction tracking method described above.

[0129] Please see Figure 3 The cross-chain transaction tracking device includes: a first acquisition module 100, a determination module 200, a second acquisition module 300, a construction module 400, and a display module 500.

[0130] The first acquisition module 100 is used to acquire the identity information and logs of each cross-chain gateway between the source chain and the destination chain;

[0131] The determination module 200 is used to determine the calling relationship between each cross-chain gateway, the source chain, the destination chain, and the relay chain based on the identity information and logs of each cross-chain gateway.

[0132] The second acquisition module 300 is used to acquire the common protocol data between each of the cross-chain gateways and the relay chain, parse the common protocol data, and acquire cross-chain transaction information.

[0133] Module 400 is used to construct a topology network of call relationships between each of the cross-chain gateways, the source chain, the destination chain, and the relay chain based on the call relationships and the cross-chain transaction information.

[0134] The display module 500 is used to visualize the call relationship network.

[0135] Logs from each cross-chain gateway, including: logs of type INTERCHAIN ​​and logs of type RECEIPT_SUCCESS;

[0136] Module 200 can be specifically used for:

[0137] Based on the identity information and logs of each cross-chain gateway, the call relationships between each cross-chain gateway, the source chain, the destination chain, and the relay chain are determined, including:

[0138] Based on the identity information of each cross-chain gateway, the cross-chain gateway that generated the log is determined to be the cross-chain gateway between the destination chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain.

[0139] Parse the logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain and the call relationship between the destination chain and the relay chain;

[0140] The logs of type RECEIPT_SUCCESS are parsed to obtain the call relationship between the cross-chain gateway between the source chain and the relay chain and between the source chain and the relay chain.

[0141] The process by which the determining module 200 parses logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain, and the call relationship between the destination chain and the relay chain, may specifically include:

[0142] Parse the logs of type INTERCHAIN ​​to obtain the log portion of type INTERCHAIN ​​containing the keyword Apply tx and the log portion of type INTERCHAIN ​​containing the keyword Handle ibtp success;

[0143] The call relationship between the cross-chain gateway and the target chain, determined from the log section of type INTERCHAIN ​​containing the keyword Apply tx, is that the cross-chain gateway submitted a cross-chain transaction request to the target chain.

[0144] The call relationship between the cross-chain gateway and the relay chain is determined from the log section of type INTERCHAIN ​​containing the keyword Handle ibtp success. This relationship is as follows: the cross-chain gateway between the target chain and the relay chain receives a transaction receipt returned by the target chain in response to the cross-chain transaction request. The call relationship between the cross-chain gateway between the target chain and the relay chain is as follows: the cross-chain gateway between the target chain and the relay chain sends a routing forwarding request corresponding to the transaction receipt to the relay chain.

[0145] The process by which the determining module 200 parses logs of type RECEIPT_SUCCESS to obtain the cross-chain gateway between the source chain and the relay chain and the call relationship between the source chain and the relay chain can specifically include:

[0146] Parse the logs of type RECEIPT_SUCCESS to obtain the log portion of type RECEIPT_SUCCESS containing the keyword Apply tx and the log portion of type RECEIPT_SUCCESS containing the keyword Handle ibtpreceipt success;

[0147] From the log section of type RECEIPT_SUCCESS containing the keyword Apply tx, it is determined that the call relationship between the cross-chain gateway between the source chain and the relay chain and the source chain and the relay chain is that the relay chain sent a routing forwarding request corresponding to the transaction receipt to the cross-chain gateway between the source chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain sent the transaction receipt to the source chain;

[0148] The call relationship between the cross-chain gateway between the source chain and the relay chain is determined from the log section of type RECEIPT_SUCCESS containing the keyword Handle ibtp receipt success. This relationship is as follows: the cross-chain gateway between the source chain and the relay chain receives the response information returned by the source chain for the transaction receipt, and then forwards the response information to the relay chain.

[0149] The cross-chain transaction information may include at least:

[0150] The source chain ID, the destination chain ID, the contract ID, the contract parameters, and the result set.

[0151] It should be noted that each embodiment focuses on describing the differences from other embodiments, and the same or similar parts between the embodiments can be referred to accordingly. For the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.

[0152] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0153] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0154] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0155] The foregoing has provided a detailed description of the cross-chain transaction tracking method and apparatus provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for tracing cross-chain transactions, characterized in that, Based on the BitXHub platform, which includes a source chain, a destination chain, a cross-chain gateway, and a relay chain, the method includes: Obtain the identity information and logs of each cross-chain gateway between the source chain and the destination chain; Based on the identity information and logs of each cross-chain gateway, the calling relationship between each cross-chain gateway, the source chain, the destination chain, and the relay chain is determined. Obtain common protocol data between each of the cross-chain gateways and the relay chain, parse the common protocol data, and obtain cross-chain transaction information; the cross-chain transaction information includes at least: the source chain ID, the destination chain ID, the contract ID, the contract parameters, and the result set; Based on the call relationships and the cross-chain transaction information, a call relationship topology network is constructed between each of the cross-chain gateways, the source chain, the destination chain, and the relay chain; The topology of the call relationship is visualized. Logs from each cross-chain gateway, including: logs of type INTERCHAIN ​​and logs of type RECEIPT_SUCCESS; Based on the identity information and logs of each cross-chain gateway, the call relationships between each cross-chain gateway, the source chain, the destination chain, and the relay chain are determined, including: Based on the identity information of each cross-chain gateway, the cross-chain gateway that generated the log is determined to be the cross-chain gateway between the destination chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain. Parse the logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain and the call relationship between the destination chain and the relay chain; The logs of type RECEIPT_SUCCESS are parsed to obtain the call relationship between the cross-chain gateway between the source chain and the relay chain and between the source chain and the relay chain.

2. The method according to claim 1, characterized in that, The process of parsing logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain, and the call relationship between the destination chain and the relay chain, includes: Parse the logs of type INTERCHAIN ​​to obtain the log portion of type INTERCHAIN ​​containing the keyword Apply tx and the log portion of type INTERCHAIN ​​containing the keyword Handle ibtp success; The call relationship between the cross-chain gateway and the target chain, determined from the log section of type INTERCHAIN ​​containing the keyword Apply tx, is that the cross-chain gateway submitted a cross-chain transaction request to the target chain. The call relationship between the cross-chain gateway and the relay chain is determined from the log section of type INTERCHAIN ​​containing the keyword Handle ibtp success. This relationship is as follows: the cross-chain gateway between the target chain and the relay chain receives a transaction receipt returned by the target chain in response to the cross-chain transaction request. The call relationship between the cross-chain gateway between the target chain and the relay chain is as follows: the cross-chain gateway between the target chain and the relay chain sends a routing forwarding request corresponding to the transaction receipt to the relay chain.

3. The method according to claim 2, characterized in that, The step of parsing logs of type RECEIPT_SUCCESS to obtain the cross-chain gateway between the source chain and the relay chain, and the call relationship between the source chain and the relay chain, includes: Parse the logs of type RECEIPT_SUCCESS to obtain the log portion of type RECEIPT_SUCCESS containing the keyword Apply tx and the log portion of type RECEIPT_SUCCESS containing the keyword Handle ibtpreceipt success; From the log section of type RECEIPT_SUCCESS containing the keyword Apply tx, it is determined that the call relationship between the cross-chain gateway between the source chain and the relay chain and the source chain and the relay chain is that the relay chain sent a routing forwarding request corresponding to the transaction receipt to the cross-chain gateway between the source chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain sent the transaction receipt to the source chain; The call relationship between the cross-chain gateway between the source chain and the relay chain is determined from the log section of type RECEIPT_SUCCESS containing the keyword Handle ibtp receipt success. This relationship is as follows: the cross-chain gateway between the source chain and the relay chain receives the response information returned by the source chain for the transaction receipt, and then forwards the response information to the relay chain.

4. A cross-chain transaction tracking device, characterized in that, Based on the BitXHub platform, which includes a source chain, a destination chain, a cross-chain gateway, and a relay chain, the device includes: The first acquisition module is used to acquire the identity information and logs of each cross-chain gateway between the source chain and the destination chain; The determination module is used to determine the calling relationship between each cross-chain gateway, the source chain, the destination chain, and the relay chain based on the identity information and logs of each cross-chain gateway; The second acquisition module is used to acquire common protocol data between each of the cross-chain gateways and the relay chain, parse the common protocol data, and acquire cross-chain transaction information; the cross-chain transaction information includes at least: the source chain ID, the destination chain ID, the contract ID, the contract parameters, and the result set; The construction module is used to construct a topology network of call relationships between each of the cross-chain gateways, the source chain, the destination chain, and the relay chain based on the call relationships and the cross-chain transaction information. The display module is used to visually represent the topology network of the call relationship; Logs from each cross-chain gateway, including: logs of type INTERCHAIN ​​and logs of type RECEIPT_SUCCESS; The module is specifically used for: Based on the identity information and logs of each cross-chain gateway, the call relationships between each cross-chain gateway, the source chain, the destination chain, and the relay chain are determined, including: Based on the identity information of each cross-chain gateway, the cross-chain gateway that generated the log is determined to be the cross-chain gateway between the destination chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain. Parse the logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain and the call relationship between the destination chain and the relay chain; The logs of type RECEIPT_SUCCESS are parsed to obtain the call relationship between the cross-chain gateway between the source chain and the relay chain and between the source chain and the relay chain.

5. The apparatus according to claim 4, characterized in that, The process by which the determining module parses logs of type INTERCHAIN ​​to obtain the cross-chain gateway between the destination chain and the relay chain, and the call relationship between the destination chain and the relay chain, specifically includes: Parse the logs of type INTERCHAIN ​​to obtain the log portion of type INTERCHAIN ​​containing the keyword Apply tx and the log portion of type INTERCHAIN ​​containing the keyword Handle ibtp success; The call relationship between the cross-chain gateway and the target chain, determined from the log section of type INTERCHAIN ​​containing the keyword Apply tx, is that the cross-chain gateway submitted a cross-chain transaction request to the target chain. The call relationship between the cross-chain gateway and the relay chain is determined from the log section of type INTERCHAIN ​​containing the keyword Handle ibtp success. This relationship is as follows: the cross-chain gateway between the target chain and the relay chain receives a transaction receipt returned by the target chain in response to the cross-chain transaction request. The call relationship between the cross-chain gateway between the target chain and the relay chain is as follows: the cross-chain gateway between the target chain and the relay chain sends a routing forwarding request corresponding to the transaction receipt to the relay chain.

6. The apparatus according to claim 4, characterized in that, The process by which the determining module parses logs of type RECEIPT_SUCCESS to obtain the cross-chain gateway between the source chain and the relay chain, and the call relationship between the source chain and the relay chain, specifically includes: Parse the logs of type RECEIPT_SUCCESS to obtain the log portion of type RECEIPT_SUCCESS containing the keyword Apply tx and the log portion of type RECEIPT_SUCCESS containing the keyword Handle ibtpreceipt success; From the log section of type RECEIPT_SUCCESS containing the keyword Apply tx, it is determined that the call relationship between the cross-chain gateway between the source chain and the relay chain and the source chain and the relay chain is that the relay chain sent a routing forwarding request corresponding to the transaction receipt to the cross-chain gateway between the source chain and the relay chain, and the cross-chain gateway between the source chain and the relay chain sent the transaction receipt to the source chain; The call relationship between the cross-chain gateway between the source chain and the relay chain is determined from the log section of type RECEIPT_SUCCESS containing the keyword Handle ibtp receipt success. This relationship is as follows: the cross-chain gateway between the source chain and the relay chain receives the response information returned by the source chain for the transaction receipt, and then forwards the response information to the relay chain.

Images