Intelligent contract collaboration method for cross-chain transaction

Abstract

The invention discloses a cross-chain transaction-oriented smart contract collaboration method, and belongs to the technical field of cross-chain contract collaboration, and the method specifically comprises the steps: deploying a log collection assembly at each cross-chain transaction smart contract node, and recording log information in real time; based on a cross-chain collaborative typical risk scene, various risks are converted into quantifiable detection rules, and a risk rule model reads node log streams in real time; when the risk rule model detects an exception, forming a complete cross-chain calling graph according to the transaction association identifier in the node log; extracting operation features of nodes in the cross-chain calling atlas, comparing the operation features with a normal node feature library, and screening out suspected fault nodes of which the operation features deviate from a threshold value; the suspected fault node abnormal data, the graph fragments and the log information are integrated, a unique responsibility affirmation abstract is generated, and the unique responsibility affirmation abstract and complete materials are stored in a shared evidence storage network to form a non-tampering certificate; and after the voucher is generated, calling a responsibility investigation intelligent contract, and executing cross-chain responsibility investigation operation according to the fault node identifier and the responsibility terms.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cross-chain contract collaboration, and in particular to a smart contract collaboration method for cross-chain transactions. BACKGROUND

[0002] With the development of blockchain technology, single blockchain networks gradually show limitations in business coverage, performance expansion and asset interconnection, and cross-chain transaction technology emerges as the times require to realize data and asset interaction between different blockchains. Existing cross-chain technologies mainly include notary mechanisms, sidechains and relays, hash locking, distributed private key control, etc. These technologies establish trusted channels or protocol conversion mechanisms between different chains to realize cross-chain asset transfer, contract calling and data synchronization. At the same time, in order to ensure the safety and reliability of cross-chain transactions, related research and practice introduce cross-chain smart contract collaboration methods, so that smart contracts on multiple chains can call and collaborate with each other according to the preset logic, thereby completing complex cross-chain business processes. However, existing monitoring and auditing schemes are mostly limited to single-chain internal, and lack unified risk perception and anomaly detection capabilities for the whole process of cross-chain transactions, making it difficult to cover every link of cross-chain calling.

[0003] Although existing technologies have made some progress in cross-chain data transmission and contract interaction, there are still obvious deficiencies in building a full-process risk monitoring and abnormal accountability mechanism for cross-chain smart contract collaboration. First, since cross-chain transactions involve multiple independent blockchain systems, the log formats, execution mechanisms and permission management of each chain differ, making it difficult to achieve unified log collection and analysis, resulting in risk detection that cannot cover the entire collaboration process. Second, when cross-chain transactions occur abnormally, existing solutions can only locate abnormal events on a certain chain, but cannot trace back to the specific collaboration link or fault node that caused the abnormality, making it difficult to accurately define responsibilities. In addition, the lack of standardized responsibility identification and accountability processes makes it difficult to divide responsibilities and execute compensation among multiple chain participants, resulting in unreliable evidence, opaque processes, and low execution efficiency. Therefore, there is an urgent need for a risk monitoring and abnormal accountability method that can cover the entire process of cross-chain smart contract collaboration, to realize real-time detection of the collaboration process, accurate positioning of fault nodes, and traceable responsibility definition. SUMMARY

[0004] The purpose of the present application is to provide a smart contract collaboration method for cross-chain transactions to solve the problems in the background art: The purpose of the present application can be achieved by the following technical solutions: A smart contract collaboration method for cross-chain transactions, comprising the following steps: S1: Deploy a log collection component on each cross-chain transaction smart contract node to record log information in real time; S2: Based on the typical risk scenarios of cross-chain cooperation, various risks are converted into quantifiable detection rules, and the risk rule model reads the node log stream in real time to detect cross-chain cooperation compliance step by step; S3: When the risk rule model detects an anomaly, a complete cross-chain calling graph is formed according to the transaction association identifier in the node log, and the calling sequence, interaction node and timestamp are labeled; S4: Extract the operation characteristics of the nodes in the cross-chain calling graph, compare them with the normal node characteristic library, and select the suspected fault nodes whose operation characteristics deviate from the threshold; S5: Integrate the abnormal data, graph fragments and log information of the suspected fault nodes to generate a unique responsibility identification summary, and store it in the shared storage network to form an unalterable certificate; S6: After the certificate is generated, the accountability smart contract is called, and the cross-chain accountability operation is executed according to the fault node identifier and the responsibility clause.

[0005] As a further scheme of the application: in step S1, the log information includes transaction initiation time, data transmission content, contract execution instruction, state change result and node identifier.

[0006] As a further scheme of the application: in step S2, the specific content of converting various risks into quantifiable detection rules based on typical risk scenarios of cross-chain cooperation includes: Combining the typical risk scenarios of cross-chain business processes to establish a scenario library, disassembling the business interaction nodes and resource flow links of each scenario, and extracting the key elements of business attributes; According to the business attributes, a mapping relationship is established for the key elements of each risk scenario, the transaction compliance corresponds to the permission verification dimension, and the data consistency corresponds to the contract interaction dimension; A business rule association model is constructed, each mapping dimension is combined using a business rule connector to form a scenario-based detection rule set, and the business verification priority of each dimension is determined; Access the cross-chain business operation data, verify the rule association model through business scenario instances, optimize the association logic of the detection dimension according to the verification result, and complete the rule adaptation.

[0007] As a further scheme of the application: in step S2, the specific content of the risk rule model reading the node log stream in real time to detect cross-chain cooperation compliance step by step includes: The log collection components deployed at each node push the log information to the risk rule model input channel in real time according to the unified field structure; The cross-chain cooperation process is divided into a business link chain, and the corresponding compliance rules are preset for each link, including permission verification, data consistency verification and process time sequence constraints; The risk rule model subscribes to the node log stream, performs rule matching and judgment in the order of the link chain, and immediately marks an abnormal event when detecting that the log record is inconsistent with the rule; A business link dependency graph is introduced, and the timing and dependency relationship between the previous and subsequent links are verified synchronously during the detection process.

[0008] As a further scheme of the application, in step S3, the complete cross-chain calling graph is formed according to the transaction association identifier in the node log, and the specific content of the calling sequence, the interaction node and the timestamp includes: After the exception is triggered, the risk rule model extracts the transaction association identifier of the abnormal event, calls the transaction association identifier index pool, and aggregates the logs containing the identifier of each node; Taking the timestamp of the aggregated log as the axis, the node identifier as the node and the interaction data as the edge, an initial cross-chain calling graph is constructed according to the cross-chain business calling timing; In the initial cross-chain calling graph, the calling sequence number is marked for the node, and the interaction node identifier and the corresponding timestamp are marked for the edge, to form a complete cross-chain calling graph.

[0009] As a further scheme of the application, in step S4, the process of extracting the operation characteristics of the nodes in the cross-chain calling graph and comparing them with the normal node characteristic library to screen out suspected fault nodes whose operation characteristics deviate from the threshold value includes: Three types of operation characteristics of each node, including calling response time, data interaction integrity and instruction execution completion degree, are extracted from the cross-chain calling graph and structured; The node type is determined according to the node identifier, and the characteristic reference data of the corresponding type of node in the normal node characteristic library is called; The characteristic deviation rate of each node operation characteristic and the corresponding reference data is calculated, and a unified algorithm is used to obtain a single node comprehensive deviation value; The node comprehensive deviation value is compared with the preset threshold value, and the node whose comprehensive deviation value exceeds the threshold value is marked as a suspected fault node.

[0010] As a further scheme of the application, in step S5, the process of integrating the abnormal data of the suspected fault node, the graph segment and the log information to generate a unique responsibility identification summary and storing the complete material in the alliance chain to form an unalterable certificate includes: According to the fixed fields of the fault node identifier, the abnormal characteristic data, the graph segment and the corresponding log information, the responsibility identification data package is integrated; A unique responsibility identification summary is generated by jointly calculating the responsibility identification data package and the transaction association identifier using a hash algorithm; The responsibility identification summary and the complete data package are uploaded to the designated block on the chain by calling the alliance chain storage interface, and the storage block height is recorded. Based on the on-chain storage information, an unalterable responsibility identification voucher containing the storage block height and responsibility identification digest is generated.

[0011] As a further scheme of the application: in the step S6, after the voucher is generated, a liability smart contract is called to execute the cross-chain liability operation process according to the fault node identifier and the liability clause. After the voucher is generated, a consortium block link is called to verify the consistency of the storage digest of the responsibility identification voucher and the complete data package. After the verification is passed, the fault node identifier and the exception type are input into the liability smart contract, and the built-in liability clause mapping table is called to match the corresponding liability measure. The smart contract automatically executes the cross-chain permission suspension of the node, initiates the loss compensation calculation and executes the cross-chain liability operation according to the matched liability measure.

[0012] The application has the following beneficial effects: The application realizes the standardized real-time recording of log information of different blockchain systems by deploying a log collection component on each cross-chain transaction smart contract node, breaking the fragmented state of multi-chain logs; in combination with the quantifiable detection rules constructed based on typical cross-chain collaboration risk scenarios, the risk rule model reads the node log stream in real time and detects compliance link by link, ensuring that the risk monitoring covers the whole process from initiation to execution of cross-chain collaboration, avoiding the problem that the traditional scheme can only monitor a single chain and has a monitoring blind area. At the same time, when an exception is detected, a complete cross-chain call graph is constructed by using the transaction association identifier and key information is labeled, and then the node operation features are extracted and compared with the normal feature library to screen suspected fault nodes, accurately positioning the collaboration link and fault node causing the exception, solving the defects that the traditional scheme is difficult to trace the root cause of the exception and the responsibility is ambiguous, and significantly improving the security and reliability of cross-chain smart contract collaboration.

[0013] The application integrates the abnormal data, graph fragments and log information of the suspected fault node, generates a unique responsibility identification digest and stores it into a shared storage network with complete materials, uses the unalterable feature of the shared storage network to ensure the authenticity and traceability of the responsibility identification evidence, provides a unified and reliable basis for responsibility identification for multi-chain participants, avoids the situation that the evidence is easily tampered with and each participant disputes the responsibility identification in the traditional scheme. In addition, after the voucher is generated, a liability smart contract is called to automatically execute the cross-chain liability operation according to the fault node identifier and the preset liability clause, replacing the liability mode in the traditional scheme which relies on manual consultation and has a complicated process, realizing the standardization and automation of the liability process, greatly improving the liability execution efficiency, at the same time ensuring the transparency of the liability process and maintaining the legal rights and interests of the cross-chain transaction participants, providing a strong support for the stable development of the cross-chain transaction ecology. BRIEF DESCRIPTION OF DRAWINGS

[0014] The application will be further described below with reference to the drawings.

[0015] Figure 1 is a flowchart of a smart contract collaboration method for cross-chain transactions. DETAILED DESCRIPTION

[0016] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the application.

[0017] Please refer to Figure 1 The application is a smart contract collaboration method for cross-chain transactions, comprising the following steps: S1: deploying a log collection component on each cross-chain transaction smart contract node to record log information in real time; S2: based on typical risk scenarios of cross-chain collaboration, converting various risks into quantifiable detection rules, and a risk rule model reading node log streams in real time to detect cross-chain collaboration compliance step by step; S3: when the risk rule model detects an anomaly, forming a complete cross-chain calling graph according to transaction association identifiers in the node logs, and marking calling sequences, interaction nodes and time stamps; S4: extracting operation features of nodes in the cross-chain calling graph, comparing with normal node feature libraries, and screening out suspected fault nodes with operation features deviating from a threshold; S5: integrating abnormal data of suspected fault nodes, graph fragments and log information, generating a unique responsibility identification summary, and storing the summary and complete materials in a consortium blockchain to form an unalterable voucher; S6: after the voucher is generated, calling a responsibility smart contract, and executing cross-chain responsibility operations according to fault node identifiers and responsibility clauses.

[0018] In the step S1, the log information comprises transaction initiation time, data transmission content, contract execution instruction, state change result and node identifier; Specifically, a log collection component in a unified format is deployed on each smart contract node participating in cross-chain transactions, which records transaction initiation time, data transmission content, contract execution instruction, state change result and node identifier in the collaboration process of the node in real time, and log data is stored in a local distributed database in a structured format.

[0019] In the step S2, the specific content of converting various risks into quantifiable detection rules based on typical risk scenarios of cross-chain collaboration comprises: A scene library is established by combining cross-chain business process with typical risk scenarios, the business interaction nodes and resource flow links of each scenario are disassembled, and the business attribute key elements are extracted: first, the cross-chain business is disassembled into specific processes according to actual operation, such as the links of “initiating transfer-asset locking-cross-chain verification-target chain credit” of digital asset cross-chain, and then the risks that have occurred or are potential are analyzed for each link, such as “no permission when initiating transfer” and “data not synchronized after cross-chain verification”, and these risks are sorted into typical risk scenarios and aggregated into a scene library; then each scenario is disassembled, such as the “data not synchronized after cross-chain verification” scenario, the business interaction nodes (initiating chain verification node, relay node, target chain receiving node) and resource flow links (verification result transmission from initiating chain to relay and then to target chain) involved are found out. The reason why the business attribute key elements can be extracted through such disassembly is that risks are inevitably attached to specific business nodes and resource flow, and business attribute key elements such as “verification result transmission path” and “node interaction timing” that can represent risks can be extracted from these carriers.

[0020] According to the mapping relationship between the business attribute key elements of each risk scenario, the transaction compliance corresponds to the permission verification dimension, and the data consistency corresponds to the contract interaction dimension: first, the business attribute nature of each risk scenario key element is determined, such as the core of “transaction compliance” risk is whether the operation conforms to the permission agreement of the participants, and its business attribute is directly related to “who has the qualification to perform the operation”, and the permission verification dimension is the core direction to judge the qualification of the participants, so the two are mapped; the core of “data consistency” risk is whether the data before and after cross-chain matching, and data transmission is mainly completed through the interaction of different chain contracts, so the contract interaction dimension can directly reflect the transmission result of data between contracts, so it corresponds to the contract interaction dimension. The principle of establishing such a mapping is that the core characteristics of the risk and the detection dimension have an inherent business correlation, and the specific dimension that can detect the risk can be accurately found through the business attribute.

[0021] A business rule association model is constructed, each mapped dimension is combined using business rule connectors to form a set of scenario-based detection rules, and the business verification priority of each dimension is determined: for the mapped dimensions of each scenario, “and” and “or” business rule connectors are used to combine according to business logic, such as the mapped dimensions of “transaction violation” scenario are “participant permission level” and “operation permission range”, which are combined into the rule “trigger risk when participant permission level does not meet operation requirements and operation exceeds permission range”; during the combination process, the verification priority is determined according to the key degree of business process, such as verifying “participant permission” first and then verifying “data format”, because permission is the prerequisite for transaction initiation, and subsequent verification is meaningless if the permission is not met. The principle of such combination and sorting is that the business rule connector can restore the logical conditions under which the risk occurs, and the priority is sorted according to the logic and importance of business operation, ensuring that the rules can detect risks in a reasonable order.

[0022] Access cross-chain business operation data, verify rule association model through business scenario instances, optimize detection dimension association logic according to verification results, and complete rule adaptation: first, access the operation data in the actual cross-chain business, which contains a large number of real business scenario instances, such as "insufficient permissions leading to transaction failure" and "contract interaction delay leading to data inconsistency" in history; put these instances into the rule association model to see if the model can accurately identify the corresponding risks, such as verifying the "transaction violation" rule with the "insufficient permissions leading to transaction failure" instance. If the model does not identify it, analyze the reasons. It may be that the "temporary permission expiration" dimension association is missing in the association logic. The reason why the model can be optimized through instance verification is that the instances in the operation data are the embodiment of real business risks, which can test whether the rules fit the actual business situation. Adjust the association logic of the detection dimension according to the deviations found in the verification, and the rule can adapt to the actual business risk characteristics.

[0023] In step S2, the risk rule model reads the node log stream in real time, and the specific content of cross-chain collaborative compliance detection includes: On each node involved in cross-chain transactions, there is a log collection component that records relevant log information when the node performs operations. These log information covers key processes of transactions, such as who initiates the transaction, which verification is passed, how data is transmitted, etc. In order for the risk rule model to understand and process this information, all node log collection components record and push logs according to a unified structure agreed in advance. In this way, no matter which node the log comes from, the organization of its content is consistent. These logs are transmitted in real time to the risk rule model through a dedicated channel as input data for detection. The reason for unified structure and real-time pushing is that the original log format of different nodes may be different, if not unified, the model will not be able to accurately compare and analyze; real-time pushing can ensure that the model can discover problems in time during cross-chain process, rather than waiting until the transaction is completed.

[0024] Cross-chain collaboration is a process composed of multiple consecutive steps, such as asset locking, cross-chain verification, asset unlocking, etc. To facilitate detection, we split the entire process into a series of business links, forming a business link chain in order. Each link has clear start and end conditions, as well as participating nodes and operation content. For each link, we preset corresponding compliance rules, which cover three aspects: permission verification (checking whether the node executing the operation has the right), data consistency verification (checking whether the data passed in the link is consistent with the expected), and process timing constraints (checking whether the link is executed in the expected order and time interval). The reason for doing this is that cross-chain risks often arise in specific business links. By splitting links and presetting rules, detection can be more targeted and it is easier to locate the problem.

[0025] The risk rule model continuously receives log streams from various nodes and, according to the order of the business link chain, performs rule matching and judgment on the logs of each link. For example, in the asset locking link, the model will check whether there are records in the logs that meet the permission verification rules. If it finds that an operation was initiated by a node without the right, it will determine that it is inconsistent with the rules. When such inconsistencies are detected, the model will immediately mark the event as an abnormal event and record the relevant context information. The reason why we can detect abnormalities in real time through log streams is that logs record the actual operations of nodes, while rules define the correct operation method. By comparing the two, we can promptly detect behaviors that deviate from the rules.

[0026] The business link dependency graph is a graph that describes the dependency relationships and execution order between various business links. For example, the asset locking link must be completed before the cross-chain verification link, and the cross-chain verification link depends on the results of the asset locking link. During detection, the risk rule model not only checks whether individual links meet the rules, but also verifies, according to the business link dependency graph, whether the execution order of the preceding and following links is correct and whether there are missing links. If it finds that a link is skipped or the order is reversed, the model will automatically trigger an exception record. The reason for introducing the dependency graph for synchronous verification is that some risks are not caused by errors in a single link, but by the fact that the relationship between links does not conform to business logic. Such problems can only be discovered from the perspective of the overall process.

[0027] In step S3, the complete cross-chain call graph is formed according to the transaction association identifier in the node log, and the specific content of marking the call order, interaction nodes and timestamps includes: When the risk rule model detects an abnormal event during the detection process, it extracts the corresponding transaction association identifier from the record of the abnormal event. This identifier is a unique identity information carried by cross-chain transactions when they are transmitted between nodes, and is used to associate logs of the same transaction on different nodes. Subsequently, the model calls the transaction association identifier index pool, which records in advance the logs corresponding to each transaction association identifier on which nodes and storage locations exist. Through the index pool, the model can quickly find and collect all logs containing the identifier, regardless of whether these logs are distributed on source chain nodes, relay nodes, or target chain nodes. The reason why logs can be aggregated through transaction association identifiers is that all operations of the same cross-chain transaction will carry the same identifier, which is generated when the transaction is initiated and remains unchanged throughout the cross-chain process, so it can be used as a unique clue to link the logs of different nodes.

[0028] After obtaining all logs containing the same transaction association identifier, the model arranges these logs in chronological order according to their timestamps. Since timestamps record the time of each operation, they can reflect the actual execution order of cross-chain calls. Then, according to the call sequence of cross-chain business, such as from the source chain initiation node, through the relay node, to the target chain receiving node, the model identifies each participating node as a node in the graph and the interaction data transmitted between nodes as edges connecting these nodes, thereby constructing an initial cross-chain call graph. The reason for using timestamps as the axis is that they provide a natural order basis and can accurately reflect the call sequence. The reason for using node identifiers as nodes and interaction data as edges is that the nodes of the graph represent participants and the edges represent data exchange between them. This representation method conforms to the basic idea of graph theory and can intuitively show the path and data flow of cross-chain calls.

[0029] On the basis of the initial cross-chain call graph, in order to more clearly show the call sequence, the model labels each node with a call sequence number. This number is assigned in chronological order from start to end according to the transaction execution, for example, the initiation node is 1, the relay node is 2, and the receiving node is 3. At the same time, each edge is labeled with the corresponding interaction node identifier, i.e., the identity information of the two nodes connected by the edge, and the timestamp of the interaction. In this way, the graph can not only show the connection relationship between nodes, but also clearly show the execution order and specific time of each step. The reason for labeling this information is that the call sequence number allows analysts to quickly locate a specific step, and the edge labeling allows each data interaction link to be traceable, making it easier to analyze the specific location and reason for the occurrence of abnormalities, thereby forming a complete and clear cross-chain call graph.

[0030] The process of extracting the operation characteristics of the nodes in the cross-chain calling graph in step S4 and comparing them with the normal node characteristic library to screen out suspected fault nodes with operation characteristics deviating from the threshold is as follows: In the cross-chain calling graph, each node has clear interaction records, from which we can extract three key operation characteristics. The calling response time length refers to the time taken by a node to return a result after receiving a request, which reflects the speed of the node in processing requests. The data interaction integrity refers to whether the data sent or received by the node during the interaction process is complete, without missing or tampering. The instruction execution completion degree refers to whether the node has completed all instructions as required by the request, rather than interrupting in the middle or only completing part of the task. These characteristics will be organized in a structured form for easy comparison with the normal node characteristic library. The reason for choosing these three characteristics is that they reflect the running state of the node from the speed, quality, and reliability dimensions, and can comprehensively measure whether the node is abnormal.

[0031] Each node has a unique identifier, which can determine the type of the node, such as a source chain node, a relay node, or a target chain node. Different types of nodes have different roles and functions in the cross-chain process, so their normal operation characteristics will also differ. For example, a relay node is mainly responsible for forwarding data, so its response time is usually short, while a target chain node may need to execute complex smart contract logic, so its response time will be relatively long. Therefore, when comparing, the characteristic benchmark data of the corresponding type of node in the normal node characteristic library should be called, so as to ensure the fairness and accuracy of the comparison.

[0032] For each node, the three types of operation characteristics are compared with the benchmark data of the corresponding type of node in the normal node characteristic library, and the deviation rate of each is calculated. For example, if the actual response time of a relay node is much longer than the benchmark data, its deviation rate in response time will be high. Similarly, if the data interaction integrity or instruction execution completion degree is lower than the benchmark, the corresponding deviation rate will also be generated. Then, a unified algorithm is used to combine the deviation rates of the three characteristics to obtain a comprehensive deviation value that reflects the degree of deviation of the node from the normal state. The reason for considering multiple characteristics is that the abnormality of a single characteristic may not be enough to indicate that the node is faulty, while the simultaneous abnormality of multiple characteristics can more accurately reflect the problem.

[0033] After obtaining the comprehensive deviation value of each node, it is compared with a preset threshold. If the comprehensive deviation value of a certain node exceeds the threshold, it means that the running state of the node is significantly different from the normal situation, and there may be a fault or abnormal behavior. At this time, the node will be marked as a suspected fault node for further analysis and processing. The purpose of setting the threshold is to distinguish between normal running fluctuations and real abnormalities, ensuring that only when the node behavior deviates significantly from the normal range will it be marked, thereby reducing the possibility of false positives.

[0034] In step S5, the suspected fault node abnormal data, graph fragments and log information are integrated to generate a unique responsibility identification summary, and the process of storing the complete material in the alliance blockchain to form an unalterable certificate is: After determining the suspected fault node, various key information related to the node will be collected, including the fault node identifier that can uniquely identify the node, the abnormal feature data (such as response delay, data transmission error, etc.) exhibited by the node at the time of the anomaly, the graph fragment related to the anomaly intercepted from the cross-chain call graph, and the detailed log information generated by the node during the abnormal period. These information will be sorted and integrated according to the fixed field defined in advance to form a complete responsibility identification data package. The reason for integrating according to the fixed field is that this can ensure the uniformity of the data package structure, facilitating subsequent hash calculation and storage operations; at the same time, all related information is concentrated together, which can provide comprehensive and complete basis for subsequent responsibility identification.

[0035] After generating the responsibility identification data package, a hash algorithm is used to jointly calculate the data package and the corresponding transaction association identifier. The transaction association identifier is the unique identity information of the cross-chain transaction, and its hash calculation together with the data package can ensure that the summary is not only related to the data package content, but also bound to a specific transaction instance. The characteristic of the hash algorithm is that any slight change in the input will result in a completely different hash value, so it can be guaranteed that as long as the data package or the transaction association identifier is changed, the generated summary will be different. The responsibility identification summary generated in this way has uniqueness and unalterability, and can be used as the digital fingerprint of the responsibility identification data for subsequent verification and storage.

[0036] After generating the responsibility identification summary, the storage interface of the alliance blockchain is called to upload the responsibility identification summary and the complete responsibility identification data package to the designated block in the blockchain network. The distributed storage feature of the blockchain ensures that the data is recorded and saved by multiple nodes once it is uploaded to the chain, making it difficult to be tampered with unilaterally. At the same time, the block height of the data storage, i.e., the specific location of the data in the blockchain, is recorded. The purpose of recording the block height is to quickly locate and retrieve the storage information in the future, because each block in the blockchain has a unique height identifier, and the corresponding block and its contained data can be accurately found through the block height.

[0037] After the responsibility identification summary and data package are successfully uploaded to the chain, a formal responsibility identification certificate is generated based on the storage information on the chain. This certificate contains two key pieces of information: the storage block height and the responsibility identification summary. The storage block height is used to indicate the storage location of the certificate in the blockchain, while the responsibility identification summary is the unique digital fingerprint of the certificate content. Due to the tamper-proof nature of the blockchain, once the certificate is generated, its content cannot be tampered with, and any modification to the certificate will result in a mismatched summary. In this way, the responsibility identification certificate becomes a legally binding and verifiable evidence document that can be used in subsequent responsibility identification, auditing, and accountability processes.

[0038] In step S6, after the certificate is generated, the accountability smart contract is called to execute the cross-chain accountability operation process based on the faulty node identifier and the responsibility clause, which is: After the responsibility identification certificate is generated and stored in the alliance blockchain, the authenticity and integrity of the certificate and its corresponding data need to be confirmed before the accountability is executed. For this purpose, the interface of the alliance blockchain is called to obtain the responsibility identification summary and the complete data package stored on the chain. Then, a new summary is generated by rehashing the complete data package, and the newly generated summary is compared with the responsibility identification summary stored on the chain. If they are consistent, it means that the data package has not been modified since storage, and the certificate is authentic; if they are not consistent, it means that the data may have been tampered with, and the certificate is invalid. The reason for such verification is that the characteristics of the hash algorithm determine that any minor data modification will result in a significant change in the summary, so the integrity and authenticity of the data can be efficiently and reliably verified by comparing the summaries.

[0039] After verification, the unique identifier of the faulty node and the exception type are passed as input parameters to the accountability smart contract. The accountability smart contract maintains a mapping table of responsibility clauses inside, which defines specific accountability measures corresponding to different exception types. For example, if the exception type is permission verification failure, the corresponding measure may be to suspend the cross-chain permission of the node; if the exception type is data consistency problem, the corresponding measure may be to start the compensation process. The smart contract will find the matching accountability measure according to the input exception type by looking up the mapping table. The reason for needing such a mapping table is that different types of exceptions involve different responsibilities and handling methods. Through the mapping relationship defined in advance, the accuracy and consistency of the accountability measures can be ensured, and the subjectivity and delay of human judgment can be avoided.

[0040] Once the accountability smart contract determines the matching accountability measure, it will automatically execute the corresponding operation. For example, if the measure is to suspend the cross-chain permission of the node, the contract will update the permission status of the node on the chain to limit its ability to initiate or participate in cross-chain transactions; if the measure is loss compensation, the contract will calculate the amount of compensation or the number of assets according to the pre-set compensation rules and the impact range of the exception event, and trigger the corresponding transfer or asset unlocking operation. Since these operations are automatically executed by the smart contract on the blockchain, they have traceability and non-tamperability, ensuring the transparency and fairness of the accountability process. The reason for using the smart contract to automatically execute is that it can quickly respond to exception events without human intervention, and at the same time, it can use the characteristics of the blockchain to ensure the credibility and consistency of the execution results.

[0041] The above describes one embodiment of the present application in detail, but the content described is only the preferred embodiment of the present application, and cannot be considered as limiting the scope of the present application. Any equivalent changes and improvements made within the scope of the present application should still belong to the patent coverage of the present application.

Claims

1. A smart contract collaboration method for cross-chain transactions, characterized in that, Includes the following steps: S1: Deploy log collection components on each cross-chain transaction smart contract node to record log information in real time; S2: Based on typical risk scenarios of cross-chain collaboration, multiple risks are transformed into quantifiable detection rules. The risk rule model reads the node log stream in real time and detects the compliance of cross-chain collaboration step by step. S3: When the risk rule model detects an anomaly, it forms a complete cross-chain call graph based on the transaction association identifier in the node log, marking the call order, interaction nodes and timestamps; S4: Extract the operation features of nodes in the cross-chain call graph, compare them with the feature library of normal nodes, and filter out suspected faulty nodes whose operation features deviate from the threshold. S5: Integrate abnormal data, graph fragments and log information of suspected fault nodes to generate a unique responsibility determination summary, and store it with the complete materials in the shared evidence storage network to form an immutable certificate; S6: After the certificate is generated, the accountability smart contract is invoked to perform cross-chain accountability operations based on the fault node identifier and liability terms.

2. The smart contract collaboration method for cross-chain transactions according to claim 1, characterized in that, In step S1, the log information includes the transaction initiation time, data transmission content, contract execution instructions, status change results, and node identifier.

3. The smart contract collaboration method for cross-chain transactions according to claim 1, characterized in that, In step S2, the specific content of transforming multiple risks into quantifiable detection rules based on typical cross-chain collaboration risk scenarios includes: By combining cross-chain business processes, typical risk scenarios are identified and a scenario library is established. The business interaction nodes and resource transfer links of each scenario are broken down, and key elements of business attributes are extracted. Based on business attributes, establish mapping relationships for key elements of each risk scenario, and map transaction compliance to the permission verification dimension and data consistency to the contract interaction dimension. Construct a business rule association model, use business rule connectors to combine various mapping dimensions to form a scenario-based detection rule set, and determine the business verification priority of each dimension; By accessing cross-chain business operation data, verifying the rule association model through business scenario examples, and optimizing the association logic of detection dimensions based on the verification results, rule adaptation is completed.

4. The smart contract collaboration method for cross-chain transactions according to claim 1, characterized in that, In step S2, the risk rule model reads the node log stream in real time and checks the specific content of cross-chain collaboration compliance step by step, including: The log collection components deployed at each node push log information to the risk rule model input channel in real time according to a unified field structure; The cross-chain collaboration process is broken down into business process chains, and corresponding compliance rules are preset for each process, including permission verification, data consistency verification and process sequence constraints. The risk rule model subscribes to the node log stream and performs rule matching and judgment in the order of the link chain. When a log record is detected to be inconsistent with the rule, it is immediately marked as an abnormal event. By introducing a business process dependency graph, the timing and dependency relationships of the preceding and following processes are verified synchronously during the detection process. If a process is missing or the order is incorrect, an exception record is automatically triggered.

5. The smart contract collaboration method for cross-chain transactions according to claim 1, characterized in that, In step S3, the specific details of forming a complete cross-chain call graph based on the transaction association identifiers in the node logs, including the call order, interaction nodes, and timestamps, include: After an anomaly is triggered, the risk rule model extracts the transaction association identifier of the anomaly event, calls the transaction association identifier index pool, and aggregates the logs from each node that contain the identifier. Using the timestamp of the aggregated log as the axis, and following the cross-chain business call sequence, node identifiers are used as nodes and interaction data is used as edges to construct an initial cross-chain call graph; In the initial cross-chain call graph, nodes are labeled with call sequence numbers, and edges are labeled with interaction node identifiers and corresponding timestamps, forming a complete cross-chain call graph.

6. The smart contract collaboration method for cross-chain transactions according to claim 1, characterized in that, In step S4, the process of extracting the operational features of nodes in the cross-chain call graph, comparing them with the feature library of normal nodes, and filtering out suspected faulty nodes whose operational features deviate from the threshold is as follows: Extract and structure three types of operational features from the cross-chain call graph: call response time, data interaction integrity, and instruction execution completion rate of each node. The node type is determined based on the node identifier, and the feature baseline data of the corresponding type of node is called from the normal node feature library; Calculate the feature deviation rate between the operational characteristics of each node and the corresponding benchmark data, and use a unified algorithm to obtain the comprehensive deviation value of a single node. The node's overall deviation value is compared with a preset threshold. Nodes whose overall deviation value exceeds the threshold are marked as suspected faulty nodes.

7. The smart contract collaboration method for cross-chain transactions according to claim 1, characterized in that, In step S5, the process of integrating the abnormal data, graph fragments, and log information of suspected faulty nodes to generate a unique responsibility determination summary, and storing it along with the complete materials in the consortium blockchain to form an immutable certificate, is as follows: The responsibility determination data package is formed by integrating fixed fields such as fault node identifier, abnormal feature data, graph fragments, and corresponding log information; A hash algorithm is used to jointly calculate the liability determination data packet and the transaction association identifier to generate a unique liability determination digest. Call the consortium blockchain notarization interface to upload the responsibility determination summary and the complete data package to the designated block on the chain and record the notarization block height; Based on the on-chain evidence information, an immutable liability determination certificate containing the evidence block height and liability determination summary is generated.

8. The smart contract collaboration method for cross-chain transactions according to claim 1, characterized in that, In step S6, after the certificate is generated, the process of calling the accountability smart contract and performing cross-chain accountability operation according to the fault node identifier and liability terms is as follows: After the certificate is generated, the consortium blockchain interface is called to verify the consistency between the stored summary of the liability determination certificate and the complete data packet. After verification, the fault node identifier and anomaly type are input into the accountability smart contract, and the built-in liability clause mapping table is called to match the corresponding accountability measures. Based on the matching accountability measures, the smart contract automatically executes actions such as suspending the node's cross-chain permissions and initiating cross-chain accountability operations to calculate loss compensation.

Images