A cross-chain transaction-oriented smart contract collaboration method

Abstract

The application discloses a kind of cross-chain transaction-oriented intelligent contract coordination method, belong to cross-chain contract coordination technical field, specifically include: in each cross-chain transaction intelligent contract node deployment log collection component, real-time record log information;Based on cross-chain coordination typical risk scene, multiple risks are converted into quantifiable detection rules, and risk rule model reads node log stream in real time;When risk rule model detects exception, form complete cross-chain call atlas according to transaction association mark in node log;Extract the operation characteristics of node in cross-chain call atlas, compare with normal node characteristic library, and filter out suspected fault node of operation characteristic deviation threshold;Integrate suspected fault node abnormal data, atlas fragment and log information, generate unique responsibility identification abstract, and form tamper-proof voucher with complete material storage into shared storage network;After voucher generation, call accountability intelligent contract, according to fault node identification and responsibility clause, execute cross-chain accountability operation.

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 solutions 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, which solves the problems in the background art:

[0005] The purpose of the present application can be achieved by the following technical solutions:

[0006] A smart contract collaboration method for cross-chain transactions, comprising the following steps:

[0007] S1: Deploy a log collection component on each cross-chain transaction smart contract node to record log information in real time;

[0008] S2: Based on the typical risk scenarios of cross-chain cooperation, various risks are converted into quantifiable detection rules. The risk rule model reads the node log stream in real time, and detects cross-chain cooperation compliance step by step;

[0009] S3: When the risk rule model detects an anomaly, a complete cross-chain call graph is formed according to the transaction association identifier in the node log, and the call sequence, interaction node and timestamp are labeled;

[0010] S4: Extract the operation characteristics of the nodes in the cross-chain call graph, compare them with the normal node characteristic library, and select the suspected faulty nodes whose operation characteristics deviate from the threshold;

[0011] S5: Integrate the abnormal data, graph fragments and log information of the suspected faulty nodes to generate a unique responsibility identification summary, and store it in the shared storage network to form an unalterable certificate;

[0012] S6: After the certificate is generated, the accountability smart contract is called, and cross-chain accountability operations are performed according to the fault node identifier and the responsibility clause.

[0013] 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.

[0014] 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:

[0015] Combining cross-chain business process to sort out typical risk scenarios to establish a scenario library, disassembling the business interaction nodes and resource flow links of each scenario, and extracting business attribute key elements;

[0016] According to the business attribute, a mapping relationship is established for the key elements of each risk scenario, the transaction compliance is corresponding to the permission verification dimension, and the data consistency is corresponding to the contract interaction dimension;

[0017] A business rule association model is constructed, each mapping dimension is combined by using a business rule connector to form a scenario-based detection rule set, and the business verification priority of each dimension is determined;

[0018] Access 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 rule adaptation.

[0019] 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 and detecting cross-chain cooperation compliance step by step includes:

[0020] The log collection components deployed at each node push log information in a unified field structure to a risk rule model input channel in real time;

[0021] The cross-chain collaborative process is divided into business link chains, and corresponding compliance rules are preset for each link, including permission verification, data consistency verification, and process timing constraints;

[0022] 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 it as an abnormal event when it detects that the log record does not conform to the rules;

[0023] The 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. If there is a missing link or incorrect order, an abnormal record is automatically triggered.

[0024] As a further scheme of the present 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 order, interaction node and timestamp includes:

[0025] 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;

[0026] Taking the timestamp of the aggregated log as the axis, the cross-chain business calling timing, the node identifier as the node, and the interaction data as the edge are used to construct an initial cross-chain calling graph;

[0027] In the initial cross-chain calling graph, the calling order number is marked for the node, and the interaction node identifier and corresponding timestamp are marked for the edge, forming a complete cross-chain calling graph.

[0028] As a further scheme of the present 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 filter out suspected faulty nodes with operation characteristics deviating from the threshold is:

[0029] Extract the calling response time, data interaction integrity, and instruction execution completion degree of each node from the cross-chain calling graph and structure them;

[0030] Determine the node type according to the node identifier, and call the characteristic benchmark data of the corresponding type of node in the normal node characteristic library;

[0031] Calculate the characteristic deviation rate of each node operation characteristic and the corresponding benchmark data, and use a unified algorithm to obtain a single node comprehensive deviation value;

[0032] Compare the node comprehensive deviation value with the preset threshold, and mark the node as a suspected faulty node if the comprehensive deviation value exceeds the threshold.

[0033] As a further scheme of the application: in the step S5, the process of integrating the suspected fault node abnormal data, the atlas fragment and the log information to generate a unique responsibility identification summary, and storing the complete material in the alliance blockchain to form an unalterable certificate is:

[0034] According to the fixed fields of the fault node identifier, the abnormal characteristic data, the atlas fragment and the corresponding log information, the responsibility identification data packet is integrated and formed;

[0035] The responsibility identification data packet and the transaction association identifier are jointly calculated by using a hash algorithm to generate a unique responsibility identification summary;

[0036] The responsibility identification summary and the complete data packet are uploaded to the designated block on the chain by calling the alliance blockchain storage interface, and the storage block height is recorded;

[0037] Based on the on-chain storage information, an unalterable responsibility identification certificate containing the storage block height and the responsibility identification summary is generated.

[0038] As a further scheme of the application: in the step S6, the process of calling the accountability smart contract after the certificate is generated, and executing cross-chain accountability operation according to the fault node identifier and the responsibility clause is:

[0039] After the certificate is generated, the alliance blockchain interface is called to verify the consistency of the storage summary of the responsibility identification certificate and the complete data packet;

[0040] After the verification is passed, the fault node identifier and the abnormal type are input into the accountability smart contract, and the built-in responsibility clause mapping table is called to match the corresponding accountability measures;

[0041] The smart contract automatically executes the cross-chain permission suspension of the node, initiates the loss compensation calculation and executes the cross-chain accountability operation according to the matched accountability measures.

[0042] The application has the following beneficial effects:

[0043] The present application realizes the standardized real-time recording of log information of different blockchains by deploying a log collection component on each cross-chain transaction smart contract node, breaking the fragmented state of multi-chain logs; combined with the quantifiable detection rules constructed based on typical risk scenarios of cross-chain collaboration, the risk rule model reads the node log stream in real time and detects compliance link by link, ensuring that risk monitoring covers the whole process from initiation to execution of cross-chain collaboration, avoiding the problem that traditional solutions can only monitor a single chain and have monitoring blind spots. At the same time, when an anomaly is detected, a complete cross-chain call graph is constructed by 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 faulty nodes, accurately locating the collaboration link and faulty node causing the anomaly, solving the defects that the traditional scheme is difficult to trace the root cause of the anomaly and the responsibility definition is ambiguous, and significantly improving the security and reliability of cross-chain smart contract collaboration.

[0044] The present application integrates the abnormal data, graph fragments and log information of suspected faulty nodes, generates a unique responsibility identification summary and stores it in a shared evidence network with complete materials, uses the non-tamperable characteristics of the shared evidence 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, and 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, the accountability smart contract is called, and cross-chain accountability operations are automatically performed according to the fault node identifier and the preset responsibility clauses, replacing the accountability mode in the traditional scheme which relies on manual consultation and complicated process, realizing the standardization and automation of the accountability process, greatly improving the accountability execution efficiency, at the same time ensuring the transparency of the accountability process, maintaining the legal rights and interests of the cross-chain transaction participants, and providing strong support for the stable development of the cross-chain transaction ecology. BRIEF DESCRIPTION OF DRAWINGS

[0045] The present application will be further described below in conjunction with the drawings.

[0046] Figure 1 It is a process schematic diagram of a smart contract collaboration method for cross-chain transactions. DETAILED DESCRIPTION

[0047] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of the present application.

[0048] Please refer to Figure 1 The present application is a smart contract collaboration method for cross-chain transactions, including the following steps:

[0049] S1: Deploy a log collection component on each cross-chain transaction smart contract node to record log information in real time;

[0050] S2: Based on typical cross-chain collaboration risk scenarios, convert various risks into quantifiable detection rules. The risk rule model reads node log streams in real time and detects cross-chain collaboration compliance step by step;

[0051] S3: When the risk rule model detects an anomaly, form a complete cross-chain call graph based on the transaction association identifier in the node log, and label the call order, interaction nodes, and timestamps;

[0052] S4: Extract the operation characteristics of the nodes in the cross-chain call graph and compare them with the normal node characteristic library to filter out suspected faulty nodes whose operation characteristics deviate from the threshold;

[0053] S5: Integrate the suspected faulty node anomaly data, graph fragments, and log information to generate a unique responsibility identification summary, and store it in the consortium blockchain along with the complete materials to form an unalterable certificate;

[0054] S6: After the certificate is generated, call the accountability smart contract, execute cross-chain accountability operations based on the faulty node identifier and liability clauses.

[0055] In step S1, the log information includes transaction initiation time, data transmission content, contract execution instructions, state change results, and node identifier;

[0056] Specifically, a log collection component of a unified format is deployed on each smart contract node participating in cross-chain transactions. This component records the transaction initiation time, data transmission content, contract execution instructions, state change results, and node identifier in the collaboration process in real time. The log data is stored in a structured format in a local distributed database.

[0057] In step S2, the specific content of converting various risks into quantifiable detection rules based on typical cross-chain collaboration risk scenarios includes:

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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:

[0063] 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 verifications are 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 formats of different nodes may be different, and if not unified, the model will not be able to accurately compare and analyze; real-time pushing can ensure that the model discovers problems in a timely manner during cross-chain processes, rather than waiting until the transaction is completed.

[0064] 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 pre-set 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 pre-setting rules, detection can be more targeted and it is easier to locate the problem.

[0065] 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 is 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 timely detect behaviors that deviate from the rules.

[0066] 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 the detection process, 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 why we introduce 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 the business logic. Such problems can only be discovered from the perspective of the overall process.

[0067] 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 marking the calling order, interaction nodes and time stamps includes:

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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:

[0072] 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 is the time taken by a node to return the result after receiving the 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 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.

[0073] 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.

[0074] 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, it will also produce a corresponding deviation rate. 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.

[0075] 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 this 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.

[0076] 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:

[0077] 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.

[0078] 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.

[0079] 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.

[0080] After the responsibility identification summary and the 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.

[0081] 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.

[0082] When 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 it was stored, and the certificate is trustworthy; 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.

[0083] 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.

[0084] 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.

[0085] 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. The specific content of transforming multiple risks into quantifiable detection rules based on typical cross-chain collaboration risk scenarios is as follows: 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 to extract key elements of business attributes. Based on business attributes, establish mapping relationships for key elements of each risk scenario, mapping transaction compliance to permission verification dimension, and data consistency to contract interaction dimension; Construct a business rule association model, use business rule connectors to combine each mapping dimension to form a scenario-based detection rule set, and determine the business verification priority of each dimension; Access cross-chain business operation data, verify the rule association model through business scenario examples, optimize the association logic of detection dimensions based on the verification results, and complete the rule adaptation; S3: When the risk rule model detects an anomaly, it forms a complete cross-chain call graph based on the transaction association identifiers in the node logs, marking the call order, interaction nodes, and timestamps; specifically including: 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, the node identity identifier is used as the node, and the interaction data passed between the nodes is used as the edge to construct the 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 to form a complete cross-chain call graph; S4: Extract the operation features of nodes in the cross-chain call graph and compare them with the operation features in the normal node feature library to filter out suspected faulty nodes whose operation features deviate from the threshold; specifically including: The operation features of each node are extracted from the cross-chain call graph and structured. The operation features are call response time, data interaction integrity and instruction execution completion degree. 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, and nodes whose overall deviation value exceeds the threshold are marked as suspected faulty nodes. S5: Integrate the abnormal data, graph fragments and log information of suspected faulty nodes, generate a unique responsibility determination summary, and store it with the complete materials in the consortium blockchain 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 identity of the faulty node and the 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 identity identifier.

3. 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 executes rule matching and judgment according to the business process 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.

4. 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, generating a unique responsibility determination summary, and storing it with the complete materials in the consortium blockchain to form an immutable certificate is as follows: Based on fixed fields such as fault node identification, abnormal feature data, graph fragments, and corresponding log information, a responsibility determination data package is formed. 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.

5. 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 faulty node's identity 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 faulty node's identity and anomaly type are input into the accountability smart contract, which then calls the built-in liability clause mapping table to match the corresponding accountability measures. Based on the matching accountability measures, the smart contract automatically executes cross-chain accountability operations to suspend the node's cross-chain rights and initiate loss compensation calculations.

Images