A tamper-proofing method, system and device for cross-chain interaction of encrypted financial data

Abstract

The application provides a tamper-proofing method, system and equipment for cross-chain interaction of encrypted financial data, belongs to the technical field of data security, collects and cleans financial data, analyzes fields and identifies sensitive fields for encryption, and encapsulates into financial field units. Obtain the transmission path between the initial chain and the target chain, perform structure division and encryption processing to generate an encrypted transmission path. Send the financial field unit to the target chain node through the path for security check. If the check fails, data backtracking is performed based on the encrypted path to obtain a repair field unit and store it. Evaluate the effect of the transmission process, and based on the evaluation result, design an optimization strategy and feed it back to the initial chain. The application builds a double protection system through field-level encryption and path encryption, improves data transmission security and privacy. Dynamic evaluation and optimization are adopted to make the transmission path adaptive to network state changes, improve transmission efficiency and reliability.

Description

Technical Field

[0001] This invention belongs to the field of data security technology, and more specifically relates to an encryption-driven method, system and device for preventing tampering of cross-chain interaction of financial data. Background Technology

[0002] Cross-chain interaction of financial data has become a key business requirement. With the widespread application of blockchain technology in the financial sector, corporate financial data needs to be securely transmitted between different blockchain platforms to support business scenarios such as tax filing, cross-border payments, and supply chain finance.

[0003] In related technologies, the encryption of financial data adopts full encryption, which wastes computing resources due to excessive encryption and lacks accurate identification of field security levels, making it impossible to achieve hierarchical protection.

[0004] The data transmission path structure of related technologies records node IPs and sequences. Attackers can infer the node topology by listening to or analyzing path information, and then launch targeted man-in-the-middle attacks, node hijacking, etc., threatening data transmission security. The verification of received data is based on hash checksums, lacking checks on access permissions and structural consistency, making it difficult to intercept unauthorized access or data tampering. If transmitted data is tampered with or corrupted, these technologies typically discard or report errors, failing to utilize cached copies of path nodes for backtracking and repair, leading to data loss or transmission failure. This results in weak fault tolerance, making them particularly unsuitable for scenarios involving financial data that cannot be lost. Summary of the Invention

[0005] This invention provides an encryption-driven method for preventing tampering of cross-chain financial data interaction. Based on the evaluation results, the method designs and optimizes the cross-chain transmission strategy and sends it to the initial blockchain, thereby improving the security of cross-chain data transmission.

[0006] The methods include:

[0007] S101: Collect financial data from the economic data platform;

[0008] S102: Parse the fields of the financial data, identify the security level of each field and filter out sensitive fields; encrypt the sensitive fields, and encapsulate the encrypted sensitive fields and other non-sensitive fields into sensitive field sub-units and ordinary field sub-units respectively to generate financial field units;

[0009] S103: Obtain a candidate set of transmission paths between the initial blockchain and the target blockchain, score the transmission performance of the candidate paths based on the operating parameters of each relay node, and select the path that meets the preset performance score threshold as the target transmission path.

[0010] S104: Perform structural partitioning and encryption processing on the target transmission path to generate an encrypted transmission path;

[0011] S105: The financial field unit is sent to the target blockchain node through the encrypted transmission path, and the target blockchain node performs a security check on the received financial field unit.

[0012] S106: If the security check result does not meet the expected target, the received financial field unit is backtracked based on the encrypted transmission path to obtain the repaired financial field unit and store it.

[0013] S107: Evaluate the transmission process of the financial field unit and obtain the transmission effect evaluation results;

[0014] S108: Design and optimize the cross-chain transmission strategy based on the transmission effect evaluation results, and send the optimized cross-chain transmission strategy to the initial blockchain.

[0015] According to another embodiment of this application, a cryptographically driven cross-chain interaction anti-tampering system for financial data is provided.

[0016] The system includes:

[0017] The data acquisition module is used to collect financial data from the economic data platform;

[0018] The field parsing and encapsulation module is used to parse the fields of the financial data, identify the security level of each field and filter out sensitive fields; encrypt the sensitive fields, and encapsulate the encrypted sensitive fields and other non-sensitive fields into sensitive field sub-units and ordinary field sub-units respectively to generate financial field units;

[0019] The transmission path filtering module is used to obtain a candidate set of transmission paths between the initial blockchain and the target blockchain, score the transmission performance of the candidate paths based on the operating parameters of each relay node, and filter out the paths that meet the preset performance score threshold as the target transmission path.

[0020] The path encryption module is used to perform structural partitioning and encryption processing on the target transmission path to generate an encrypted transmission path.

[0021] The transmission verification module is used to send the financial field unit to the target blockchain node through the encrypted transmission path, and the target blockchain node performs a security verification on the received financial field unit.

[0022] The backtracking and repair module is used to backtrack the received financial field unit based on the encrypted transmission path if the security verification result does not meet the expected goal, so as to obtain and store the repaired financial field unit.

[0023] The transmission effect evaluation module is used to evaluate the transmission process of financial field units and obtain the transmission effect evaluation results.

[0024] The optimization and update module designs and optimizes the cross-chain transmission strategy based on the transmission effect evaluation results, and sends the optimized cross-chain transmission strategy to the initial blockchain.

[0025] According to another embodiment of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the cryptographically driven cross-chain interaction anti-tampering method for financial data.

[0026] As can be seen from the above technical solutions, the present invention has the following advantages:

[0027] This invention provides an encryption-driven cross-chain interaction anti-tampering method for financial data. Through data cleaning, it eliminates noise, errors, and inconsistencies in the original data, ensuring the accuracy of the input data. By identifying the security level of fields and encrypting them accordingly, it prevents the leakage of sensitive information. Based on quantitative scoring of parameters such as node response latency and load rate, it selects efficient and stable transmission paths, reducing transmission delays and failure probabilities, and improving cross-chain efficiency. By inserting pseudo-nodes, shuffling node order, and encrypting the path structure, it hides the true transmission topology, preventing attackers from inferring the path and intercepting or tampering with it. Based on integrity hash verification, permission matching, and structural consistency verification, it can intercept tampered, unauthorized access, or abnormally formatted data, preventing insecure data from entering the target blockchain. By decrypting the path, comparing cached copies, and reconstructing fields, it can accurately locate and repair tampered data, improving system fault tolerance and ensuring the accuracy of data stored on the target chain. This invention also improves data recovery capabilities and repair accuracy in abnormal transmission scenarios by tracing back tampered data; it enhances the adaptability and performance of data transmission through feedback optimization; and the overall method improves the integrity of cross-chain data transmission and strengthens transmission protection capabilities, significantly enhancing data security in cross-chain scenarios for financial data. Attached Figure Description

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

[0029] Figure 1 Flowchart of a method for preventing tampering of encrypted cross-chain financial data interaction;

[0030] Figure 2 This is a schematic diagram of an electronic device. Detailed Implementation

[0031] The encrypted-driven cross-chain interaction anti-tampering method for financial data provided by this invention collects financial data from an economic data platform; filters sensitive fields; encrypts the sensitive fields and encapsulates them into financial field units; obtains the transmission path between the initial blockchain and the target blockchain, and encrypts the transmission path to obtain an encrypted transmission path; sends the financial field units to the target blockchain, where the target blockchain node performs a security check on the received financial field units. If the check result meets the expected target, the data is directly stored; otherwise, the received financial field units are backtracked based on the encrypted transmission path to obtain and repair the financial field units, which are then stored; the transmission process of the financial field units is evaluated, and based on the evaluation results, a cross-chain transmission strategy is designed and optimized and sent to the initial blockchain; thus improving the security of cross-chain data transmission.

[0032] The following describes in detail the cryptographically driven cross-chain interaction anti-tampering method for financial data involved in this application. Specific details, such as particular system architectures and technologies, are presented for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0033] It should be understood that, when used in this specification, terms include indicating the presence of a described feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms include, encompass, have, and variations thereof mean including but not limited to, unless otherwise specifically emphasized.

[0034] The statements such as "one embodiment" or "some embodiments" described in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the statements such as "in one embodiment," "in some embodiments," "in other embodiments," and "in still other embodiments" in this application do not necessarily refer to the same embodiment, but rather mean one or more, but not all, embodiments, unless otherwise specifically emphasized.

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

[0036] Please see Figure 1 The diagram shows a flowchart of a cryptographically driven cross-chain interaction anti-tampering method for financial data in a specific embodiment. The method includes:

[0037] S101: Collect financial data from the economic data platform. The financial data is data related to the daily operation of the enterprise after data cleaning. The data related to the daily operation of the enterprise includes accounting data, enterprise transaction data, expense reimbursement data, and employee salary details, etc.

[0038] In some embodiments, the economic data platform includes an enterprise's internal ERP system, financial software, bank transaction system, etc.; specific data cleaning operations include: removing duplicate records, completing missing fields, standardizing data formats, and validating data logic using the Python Pandas library. Based on the obtained raw financial data, cleaning eliminates noise, errors, and inconsistencies to ensure the accuracy and standardization of the input data.

[0039] S102: Parse the fields of the financial data, identify the security level of each field and filter out sensitive fields; encrypt the sensitive fields, and encapsulate the encrypted sensitive fields and other non-sensitive fields into sensitive field sub-units and ordinary field sub-units respectively to generate financial field units.

[0040] In this embodiment, field parsing extracts field names, strings, and structural attributes using Natural Language Processing (NLP).

[0041] This embodiment calculates the security level by integrating key field weights, information entropy, and frequency of occurrence. The weighted sum is then compared with a threshold to filter sensitive fields. In this way, the security level is quantified by analyzing field features, allowing for targeted selection of encryption strength.

[0042] In some specific embodiments, S102 specifically includes the following steps:

[0043] Step S1021: Parse the financial data field by field, extract the field content, field data type and field structure attributes of each field, and generate a field semantic vector through feature encoding.

[0044] In some embodiments, field content is processed using word embedding or hash encoding. Field data types are mapped to discrete enumerated values; field structural attributes are also encoded as part of a vector. These features are concatenated or fused into a comprehensive field semantic vector. This achieves a unified digital representation of the multidimensional information of the field, enabling computers to understand the characteristics of the field.

[0045] Step S1022: Construct a key field dictionary, match the field semantic vector with the key field dictionary, and if a field is identified as a key field, assign a key field weight to that field.

[0046] In some embodiments, the key field dictionary is a predefined list containing highly sensitive terms such as user ID numbers, bank account numbers, transaction passwords, and salary information, or their hash values. The matching process may be exact matching or fuzzy matching based on semantic similarity. Upon successful matching, a key field weight is assigned based on the predefined sensitivity of the field in the dictionary. This allows for the rapid and accurate capture of recognized sensitive information, improving the recall rate of the filtering process.

[0047] Step S1023: Calculate the information entropy of the semantic vector of the field and compare the information entropy with a preset entropy threshold; when the information entropy is lower than the entropy threshold, use the information entropy value as the information weight of the field.

[0048] In some embodiments, this is used to discover fields that, although not in the key field dictionary, possess potential sensitivity due to their strong uniqueness. If a field's values ​​are highly concentrated, its information entropy will be low. Conversely, fields like phone numbers, which are different in almost every record, will have high information entropy. This embodiment focuses on fields with low information entropy, whose values ​​are highly deterministic and easier to bind to specific entities, thus exhibiting greater identifiability and potential sensitivity. Therefore, when the information entropy is below an empirical entropy threshold, its entropy value is used as the information weight; the lower the entropy, the higher the weight, indicating greater sensitivity.

[0049] Step S1024: Obtain the semantic purpose type of the field and count the frequency of occurrence of the semantic purpose type in historical financial data; calculate the security level of the field by weighting and summing the key field weight, information weight and frequency of occurrence.

[0050] In some embodiments, the formula for calculating the security level S can be expressed as:

[0051]

[0052] Where: K is the key field weight. I is the information weight based on information entropy. F is the frequency of occurrence.

[0053] These are the weight coefficients assigned to these three dimensions, and .

[0054] This embodiment integrates financial data from different dimensions. Key field weights K provide direct evidence, information weights I provide indirect inferences, and frequency of occurrence F serves as a moderating factor. A comprehensive security score is obtained through weighted summation.

[0055] Step S1025: Compare the security level with the preset security level threshold, filter out fields with a security level higher than the security level threshold, and determine them as sensitive fields.

[0056] In some embodiments, a preset security level threshold is set based on data security policies, compliance requirements, or historical analysis experience. The security level S of all fields is compared with this threshold to complete a binary classification decision.

[0057] S103: Obtain a candidate set of transmission paths between the initial blockchain and the target blockchain. The candidate set includes reachable paths from available relay nodes. Based on the operating parameters of each relay node, score the transmission performance of the candidate paths and select paths that meet a preset performance score threshold as the target transmission path. Operating parameters include node response latency, load rate, historical failure count, and compatibility.

[0058] In some embodiments, available relay nodes can be identified through the node health detection protocol of the blockchain network. Operating parameters can be obtained by measuring node response latency using the ping command, obtaining CPU utilization through the node API, querying the historical failure count from the node_fault_log contract in the blockchain ledger, and matching compatibility through a list of supported cryptographic algorithms, such as whether SM4 is supported. The transmission performance scoring formula is: Score = (1 - Latency / Maximum Latency) × 0.3 + (1 - Load Rate) × 0.2 + (1 - Failure Count / Total Transmissions) × 0.3 + Compatibility Matching Score × 0.2. Paths with a score ≥ 0.7 are selected as target paths.

[0059] In this way, based on the real-time performance and historical performance of the nodes, the optimal transmission path is selected from the candidate paths through quantitative scoring, ensuring the stability and efficiency of the path.

[0060] S104: Perform structural division and encryption processing on the target transmission path to generate an encrypted transmission path.

[0061] Optionally, the structure partitioning includes a path header, path node segments, and a path tail. Encryption can be achieved by inserting pseudo-nodes, shuffling the node order, constructing an index mapping table, and then encrypting it.

[0062] In some embodiments, the storage format of the standard path information is divided by structural partitioning, and the topology of the real transmission path is hidden by inserting pseudo-nodes, shuffling the order and encrypting, so as to prevent attackers from inferring the path and intercepting it.

[0063] In some specific embodiments, the methods for encrypting the target transmission path include:

[0064] The transmission path is divided into a path header, path node segments, and a path tail. The transmission path is structurally divided according to functional partitions. The path header stores transmission path attribute information, the path node segments store the structural information of each relay node, and the path tail stores integrity verification data. The path header stores transmission path attribute information, which includes path number, starting chain identifier, target chain identifier, path generation timestamp, and path version number.

[0065] A node identifier is constructed to uniquely mark all path nodes in the path node segment. In this embodiment, node identifiers are used to mark path nodes so that they can be uniquely identified and their structure can be verified. The node identifier includes node ID, key information, and function type information. The function type refers to information describing the role of the node, such as a routing node or a cache node. Marking the node provides a node index for subsequent operations. Preset integrity verification data is embedded in the end of the path, and the path header, path node segment, and path end are combined to form a complete path structure. The integrity verification data includes information such as hash value, path structure digest signature, scrambling code digest identifier, and path structure lifespan field.

[0066] The path hash value of the complete path structure is calculated and embedded into the complete path structure. In this embodiment, a hash function is used to perform structure hash value calculation on the complete path structure to generate a path hash value for a unique path. This value is used as the fingerprint of the complete path structure for integrity verification at the receiving end, and can also be used for subsequent backtracking operations. Several pseudo-nodes are constructed and inserted into the complete path structure and the node type is marked to obtain a hybrid node path structure. The pseudo-nodes are inserted into the complete path structure and a label is constructed for each node to mark whether it is a real node or a pseudo node. Only the receiving end decryption module with decryption authority can identify pseudo-nodes based on the label.

[0067] The sequence of all nodes in the hybrid node path structure is reconstructed to generate a shuffled node structure. By inserting pseudo-nodes into the complete path structure and shuffling their order, the undiscriminability of the path structure is improved, and the path's anti-interference ability is enhanced. An index mapping table is constructed, and based on the index mapping table, the index relationship between all nodes in the shuffled node structure and the original nodes is established. The index mapping table records the original index of the current node before the shuffling order. For example, if the original path is... After being shuffled The index mapping table records are The index mapping table is appended to the end of the path with scrambled node structure, the scrambled node structure is encapsulated and encrypted using an algorithm to generate an encrypted transmission path. The index mapping table is encapsulated as a separate mapping area at the end of the path, and the scrambled node structure is encapsulated in a unified format and encrypted using a suitable encryption algorithm to obtain the encrypted transmission path. The receiving end can obtain the index mapping table by decryption, which can be used for path reconstruction.

[0068] S105: The financial field unit is sent to the target blockchain node through the encrypted transmission path, and the target blockchain node performs a security check on the received financial field unit.

[0069] Optionally, security checks include field parsing, security level analysis, integrity hash verification, access permission matching, and structural consistency verification.

[0070] In some embodiments, during transmission, the financial field unit is forwarded hop-by-hop according to the node order of the encrypted transmission path, with each hop node adding a forwarding timestamp and node signature to the end of the field unit. The target node verification process can first verify the header CRC32 checksum, then separate sensitive and ordinary sub-units using the boundary identifier 0xAA55; security level analysis maps the 1-byte tag of the sensitive field to permission requirements and compares it with the node's own permissions. Integrity verification calculates the SHA-256 hash of the decrypted field and compares it with the preset hash value before transmission; structural consistency checks whether sensitive fields contain RSA+AES identifiers (0x01) and whether ordinary fields contain required fields such as transaction IDs. Through multi-dimensional verification, the security and legality of the received data are verified.

[0071] S106: If the security check result does not meet the expected target, the received financial field unit is backtracked based on the encrypted transmission path to obtain the repaired financial field unit and store it.

[0072] Alternatively, data backtracking can be achieved by decrypting the path, detecting node status, comparing cached copies, calculating credibility, and reconstructing fields.

[0073] In some embodiments, during backtracking, the encrypted transmission path is decrypted using a shared key, the original node order is restored using an index mapping table, and false nodes are eliminated. A field status request is sent to each node to obtain a cached copy. The copy is compared with the node status; nodes with more than one difference are marked as potentially tampered nodes. The actual tampered node is confirmed using hash fragments of sensitive fields. A copy is obtained from a trusted upstream node of the tampered node, and its credibility is calculated.

[0074] Optionally, the reliability calculation method can be based on hash consistency × 0.4 + time difference coefficient × 0.3 + node success rate × 0.3. The field is reconstructed using the highest reliability replica, embedded in the backtracking record, and then stored; fields that pass the verification are directly associated with the transmitted metadata storage.

[0075] S107: Evaluate the transmission process of the financial field unit to obtain the transmission effect evaluation result.

[0076] In some embodiments, the collected transmission feedback data includes: forwarding timestamps of each node, hash consistency, error type, and number of repairs; and path behavior trajectories are transmitted in sequence according to the node order.

[0077] This embodiment extracts average latency, latency variance, hash consistency rate, error rate, and repair frequency. It then compares these metrics with historical data, calculates cosine similarity and deviation, and generates a report with an excellent / qualified / unqualified evaluation rating and the cause of the anomaly.

[0078] S108: Based on the transmission effect evaluation results, design and optimize the cross-chain transmission strategy, and send the optimized cross-chain transmission strategy to the initial blockchain.

[0079] In some embodiments, path replacement is applied to unqualified paths based on the evaluation report. Load balancing is used for excessive latency, and encryption upgrades are implemented for low hash consistency. The policy is verified through simulation, inputting historical data to check whether the optimized metrics meet the standards. The data is encapsulated as structured data containing the policy ID, effective time, and parameters, signed with the target chain's private key, and sent to the initial chain. The initial chain verifies the signature and then activates the policy. This dynamically adapts to network changes, continuously improving transmission efficiency and security, while the signature and standardized protocol ensure the reliability of policy transmission.

[0080] In one embodiment of the present invention, based on step S103, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. S103 specifically includes the following steps:

[0081] S1031: Preset the scope of the blockchain network used for cross-chain transmission of financial data, and determine the initial blockchain and target blockchain within the network; initiate operation status detection for all relay nodes in the network, and the detection parameters include node connectivity, CPU load rate, and memory load rate. Relay nodes with normal connectivity and CPU load rate ≤ preset CPU threshold and memory load rate ≤ preset memory threshold are marked as available relay nodes.

[0082] In some embodiments, the initial blockchain can be the data source, and the target blockchain can be the data receiver. Defining the network boundaries for cross-chain transmission, clarifying the positions of the initial and target chains, and then filtering available relay nodes based on hardware resource load and communication status to exclude nodes that cannot stably participate in transmission provides an effective node foundation for subsequent path construction.

[0083] S1032: Using the initial blockchain as the starting point of the path and the target blockchain as the ending point of the path, and using available relay nodes as intermediate nodes of the path, an undirected graph model is constructed; the breadth-first search algorithm (BFS) is used to traverse the undirected graph, searching for all paths from the starting point to the ending point, forming a candidate set of transmission paths.

[0084] In some embodiments, a graph model is used to abstract the nodes and communication relationships in the blockchain network into a mathematical structure, and a mature path search algorithm is used to traverse all possible transmission paths to ensure that all potentially available paths are covered.

[0085] S1033: Collect the operating parameters of the relay nodes in each path in the candidate transmission path set, including node response delay, node load rate, number of historical node failures, and node compatibility; perform standardization processing on each operating parameter to eliminate the difference in dimensions between parameters and obtain standardized parameter values.

[0086] In some embodiments, when collecting raw parameters, the node response latency is the average of the data transmission times of five consecutive inter-node data transfers. Node load rate is the average of CPU load rate and memory load rate; the number of historical node failures is the number of times the node interrupted transmission due to a failure within a preset time; node compatibility is the protocol matching degree between the node and the initial chain and the target chain. The minimum and maximum values ​​of the i-th type of operating parameter among all available relay nodes can be determined by collecting the i-th type of parameter data of all available relay nodes within a preset time. If the value of a certain parameter is the same for all nodes, the standardized value of the parameter is uniformly set to 0.5.

[0087] S1034: Set the weight coefficients for each operating parameter, and the sum of the weight coefficients is 1; calculate the average value of the standardized parameters corresponding to all relay nodes in each path, multiply the average value of each parameter by the corresponding weight coefficient, and sum them to obtain the transmission performance score of each path.

[0088] In some embodiments, the weighting coefficients involve node response latency weight, node load rate weight, node historical failure count weight, and node compatibility weight. When calculating the average standardized response latency of all relay nodes in the k-th path, the number of relay nodes *m* in the k-th path is first counted, then the standardized parameter value of the j-th relay node under the i-th type of operating parameters for that path is calculated, and finally divided by *m* to obtain the average value. If a path contains only two nodes, the operating parameters of the initial chain and the target chain are directly substituted into the formula to calculate the score. Operating parameters may include response latency (inter-chain direct communication latency), load rate (average current load rate of the two chains), historical failure count (average failure count of the two chains within a preset time period), and compatibility (protocol matching degree between the two chains).

[0089] In this way, by integrating the performance of similar parameters of all relay nodes in a single path by means of average value, and then converting the average performance of multi-dimensional parameters into a single score according to preset weights, a quantitative evaluation of the overall transmission performance of the path can be achieved.

[0090] S1035: Preset transmission performance score threshold, select paths with transmission performance scores ≥ threshold from the candidate transmission path set as optional paths; obtain the number of bytes of current financial data and the average response time of the target blockchain node, select the path from the optional paths that meets the requirements of field structure size matching path bandwidth and has the lowest path load rate when the target chain network is congested, and use it as the target transmission path between the initial blockchain and the target blockchain.

[0091] In some embodiments, when setting a preset transmission performance score threshold, it is based on the 70th percentile of all path scores over a preset time period. When obtaining the field structure size, the total number of bytes in the financial field unit is counted to match the path bandwidth. When obtaining the congestion level of the target blockchain network, the average response time of the current node of the target chain is collected. In the case of moderate congestion, the optional paths with a relay node load rate ≤50% are prioritized. Finally, from the optional paths that meet the conditions, the path with the highest transmission performance score is selected as the target transmission path. This ensures that the selected target transmission path not only meets the basic performance requirements but also adapts to the needs of actual transmission scenarios, improving the reliability and efficiency of cross-chain transmission.

[0092] In one embodiment of the present invention, based on step S105, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. S105 specifically includes the following steps:

[0093] S1051: Add transmission metadata to the header of the financial field unit, including the sending node ID, transmission timestamp, total length of the field unit, and checksum; forward the financial field unit hop by hop according to the path node sequence through the node communication interface of the encrypted transmission path, and record the forwarding timestamp and update the forwarding status flag of the path node segment at each hop node.

[0094] In some embodiments, the sending node ID is a unique identifier for the initial blockchain node, generated by hashing the node's public key; the transmission timestamp uses UTC format, and the difference between the transmission timestamp and the target link's received timestamp is used for subsequent latency analysis; the total length of the field unit includes the number of bytes for all sub-units and boundary identifiers; the CRC32 checksum is calculated using the polynomial 0xEDB88320. During hop-by-hop forwarding, each relay node adds 1 byte of forwarding status to the path node segment and writes the forwarding timestamp to the end of the node information.

[0095] S1052: After receiving the financial field unit, the target blockchain node extracts the header transmission metadata and verifies the consistency between the CRC32 checksum and the actual content of the field unit; it parses the structure of the financial field unit, identifies the field boundary markers between sensitive field sub-units and ordinary field sub-units, and separates the two sub-units; it extracts the security level label of the sensitive field sub-unit header and the field type list of the ordinary field sub-unit.

[0096] In some embodiments, during CRC32 checksum verification, the target node recalculates the CRC32 value of the received field unit and compares it with the checksum in the header metadata; if they do not match, the value is discarded. The field boundary identifier uses an 8-byte fixed sequence 0xAA55AA55AA55AA55, which is located within the field unit using a sliding window algorithm to separate sensitive and ordinary sub-units. The security level label for sensitive fields is stored in bytes 3-4 of the sub-unit header, using binary encoding. The list of ordinary field types is a 16-byte bitmap in the sub-unit header, with each bit indicating the presence or absence of a field.

[0097] S1053: The target blockchain node calls the local permission management module to obtain its own node's permission level; converts the security level label of the sensitive field sub-unit into the corresponding permission requirement level; if the node's permission level is greater than or equal to the permission requirement level, it is marked as permission matching passed; otherwise, it is marked as permission matching failed, and subsequent verification is terminated.

[0098] In some embodiments, node permission levels are stored in the target chain node's local configuration file, based on node role presets. The mapping relationship between security level labels and permission requirements is maintained through a configuration table and can be adjusted according to business needs. When permission matching fails, the node records the reason for the failure and generates a denial log.

[0099] S1054: Extract the pre-set hash value from the end of the sensitive field sub-unit; recalculate the SHA-256 hash value of the decrypted sensitive field content and compare it with the extracted hash value at the byte level; at the same time, perform the same hash verification process on the ordinary field sub-units; if the hash values ​​of all sub-units match, mark it as integrity verification passed; otherwise, mark it as verification failed.

[0100] In some embodiments, sensitive field decryption is performed only after authorization is successful. The symmetric key in the hybrid encryption algorithm is decrypted using the private key of the target chain node, and then the field content is decrypted. The hash value before transmission is stored at a fixed offset at the end of the sensitive field sub-unit. The hash value of ordinary field sub-units is stored at its end, and the calculation scope includes all field content and the list of field types. A byte-by-byte equality check is performed during comparison; any bit mismatch results in a verification failure. Utilizing the collision resistance of hash functions, the field content is determined to have been tampered with by comparing the hash values ​​before and after transmission, ensuring data integrity.

[0101] S1055: Check whether the encryption format of sensitive field sub-units conforms to the preset standard, and whether ordinary field sub-units contain required fields; verify whether the boundary markers between sensitive fields and ordinary fields are complete and have not been tampered with; count the number of missing structural segments in the field structure. If the number of missing segments is 0, mark it as structural consistency verification passed; otherwise, mark it as verification failed.

[0102] In some embodiments, by checking field formats, required fields, and boundary markers, the data structure is verified to conform to preset specifications, preventing parsing errors caused by malicious tampering with the field structure.

[0103] In one embodiment of the present invention, based on step S106, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. S106 specifically includes the following steps:

[0104] S1061: Obtain the encrypted transmission path bound to the financial field unit, derive the AES-256-GCM decryption key using the shared key of the initial blockchain and the target blockchain based on the hash-based key derivation function; input the authentication tag in the encrypted transmission path, decrypt the ciphertext of the encrypted transmission path, and extract the index mapping table; according to the correspondence between the scrambled node identifiers in the index mapping table and the original index, adjust the order of nodes in the hybrid node path structure, remove pseudo nodes with type tag 0x00, and restore the original transmission path.

[0105] In some embodiments, the shared key is a 256-bit key pre-negotiated between the initial chain and the target chain; the path generation timestamp is extracted from the decrypted path header; when restoring the index mapping table, the nodes are first sorted in ascending order according to the shuffled node index, and then the node order is adjusted according to the original index. For example, if the shuffled node order is [C,A,B] and the index mapping table is [C→2,A→0,B→1], then the original order is [A,B,C]; when removing pseudo nodes, the type labels of all nodes are traversed, and only the real nodes with the label 0x01 are retained; after restoration, the SHA-256 hash value of the original transmission path needs to be calculated and compared with the path hash value stored at the end of the path. If they match, the path restoration is confirmed to be correct.

[0106] S1062: Based on the node order of the original transmission path, send a field status verification request to each relay node. The request packet contains the unique identifier of the financial field unit. Receive the field status data returned by each relay node, including cache flag, integrity verification result, and unpacking status. For nodes that return a cache flag of 0x01, send a copy read request with node permission signature to obtain the field cache copy stored by that node.

[0107] In some embodiments, a standardized request protocol is used to retrieve field status and cached copies from nodes in the original path in batches, thereby clarifying whether the nodes store valid data and the data processing status.

[0108] S1063: Compare the field cache replicas of each relay node with the field status returned by that node field by field, and count the structural differences. It should be noted that if the status shows that the integrity verification has passed but the replica hash value does not match, count one difference; if the status shows that the unpacking has been completed but the replica sub-unit has not been split, count one difference.

[0109] Set a structural difference threshold. If the number of structural difference items in a node exceeds the threshold, it is marked as a potential tampering node. Extract the encrypted hash fragments of sensitive field sub-units from the cached replicas of potential tampering nodes and compare them with the hash fragments of sensitive field sub-units in the financial field units received by the target blockchain. Nodes with inconsistent hash fragments are confirmed as real tampering nodes.

[0110] In some embodiments, when calculating structural differences, cache markers, integrity verification results, and unpacking status are verified one by one. The structural difference threshold is set according to the sensitivity of the financial data; for example, a threshold of 0 is set for highly sensitive data such as salary details, and a threshold of 1 is set for ordinary expense data. The encrypted hash fragment is a 32-byte SHA-256 complete hash value embedded at the end of the sensitive field subunit before transmission. During comparison, a byte-by-byte equality check is performed; any byte inconsistency is considered tampering.

[0111] S1064: Collect field cache replicas of all relay nodes upstream of the real tampered node whose cache is marked as 0x01, forming a field cache replica set; calculate the credibility of each replica: set the hash consistency percentage weight to 0.5, the time difference coefficient weight to 0.3, and the node's historical transmission success rate weight to 0.2, credibility = hash consistency percentage × 0.5 + time difference coefficient × 0.3 + node's historical transmission success rate × 0.2; sort the replica set in descending order of credibility, and select the replica with the highest credibility as the backtracking template.

[0112] In some embodiments, the credibility of each cached replica is quantified by weighted summation based on three dimensions: hash consistency, time difference, and historical success rate. The best replica is selected as the backtracking template after being sorted by credibility, ensuring the high quality of backtracking data.

[0113] S1065: Based on the backtracking template, reconstruct the financial field unit at the actual tampering node: restore the original encrypted structure of sensitive field sub-units and ordinary field sub-units in the template, rewrite the field header transmission metadata, replicate the field number of the original financial field unit, and embed the path hash value of the original transmission path as the path fingerprint; construct a data backtracking record, the record content includes the original transmission path node list, the IP address and node ID of the actual tampering node, the field cache copy ID, and the repair method; embed the data backtracking record into the tail of the reconstructed field unit to obtain the repaired financial field unit, and store it in the target blockchain storage structure; if the security verification result of the financial field unit meets the expected target, then directly store the financial field unit in the target blockchain storage structure.

[0114] In some embodiments, during field reconstruction, sensitive field sub-units must maintain the same encrypted structure as the original template. When transmitting metadata is updated, only the timestamp is modified, while the sending node ID and the total length of the field unit are retained; the path fingerprint is the SHA-256 hash value of the original transmission path, embedded in the path fingerprint area at the end of the reconstructed field unit. Data backtracking records are in JSON format, converted into binary streams and embedded at the end of the field unit. The records must be signed with the private key of the target chain node to ensure that the records are tamper-proof; during storage, both the repaired financial field unit and the directly stored normal units must be associated with the transmitted metadata and backtracking records.

[0115] The reconstruction in this embodiment preserves the original encryption structure to ensure security, backtracking records enable audit traceability, and differentiated processing of normal and repair units balances security and efficiency, ensuring the accuracy and auditability of the data stored in the target chain.

[0116] In one embodiment of the present invention, based on step S107, the following is a possible embodiment and its specific implementation will be described in a non-limiting manner. S107 specifically includes the following steps:

[0117] Step S1071: Collect in real time the transmission feedback data generated when the financial field unit is transmitted on the encrypted transmission path; the transmission feedback data includes field forwarding timestamp, hash consistency status, path error occurrence identifier, node repair count, and response delay.

[0118] In some embodiments, during the cross-chain transmission of financial field units via an encrypted transmission path, the system deploys data probes at key nodes. These probes continuously monitor and record predefined performance and security metrics: field forwarding timestamps are used to analyze transmission timing and latency; hash consistency status verifies data integrity by comparing the hash values ​​at both ends; path error occurrence identifiers record abnormal events such as routing failures and timeouts; node repair counts the number of times nodes recover after failures in the path; and response latency measures the time it takes for nodes to process requests. All of this data is collected in real time and tagged with a unified transaction ID to form a complete transmission profile.

[0119] Step S1072: Arrange the transmission feedback data into a time-series event sequence according to the node order of the encrypted transmission path to form a path behavior trajectory; extract the state feature vector from the path behavior trajectory to construct path evolution mode data.

[0120] In some embodiments, the discrete transmission feedback data collected in step S1071 is sorted and reassembled according to the order in which the data packets actually passed through the nodes on the encrypted transmission path to form a path behavior trajectory. The path behavior trajectory describes the complete behavioral sequence of this transmission in the spatiotemporal dimension. Features that can characterize its overall state are extracted from the path behavior trajectory to construct a feature information that includes statistical features such as average transmission delay, total number of errors, hash verification success rate sequence, and node repair frequency.

[0121] Step S1073: Calculate the evolutionary similarity between the path evolution pattern data and the historical path evolution pattern data corresponding to historical path events.

[0122] In some embodiments, the evaluation assesses the degree to which the behavior pattern of the current transmission path matches the behavior patterns of historically successful transmission paths. Cosine similarity measures the similarity of two feature vectors by calculating the difference in direction; its value range is [-1, 1], with values ​​closer to 1 indicating greater similarity between the two patterns. The system selects one or more transmission records from the historical database that performed well under similar network conditions and compares their feature information.

[0123] Step S1074: Calculate the deviation between the path evolution pattern data and the historical path evolution pattern data.

[0124] In some embodiments, self-comparison of the same transmission path at different points in time is used to detect a decline trend in path performance or stability. The system retrieves feature information formed by the same encrypted transmission path in past transmissions, and then calculates the degree of deviation of the current feature information from this historical benchmark.

[0125] Step S1075: Compare the evolutionary similarity and the deviation with a preset similarity threshold and deviation threshold respectively; generate a transmission effect evaluation result based on the comparison results.

[0126] In some embodiments, an evolutionary similarity threshold Ts and a deviation threshold Td are preset. The calculated evolutionary similarity is compared with Ts, and the deviation is compared with Td. The evaluation logic is: if the evolutionary similarity < Ts or the deviation > Td, it is determined that the effect of the current transmission path does not meet the standard or needs to be optimized; otherwise, it is determined to be good. This binary or multi - valued determination conclusion, together with the specific similarity and deviation values, jointly constitutes the final transmission effect evaluation result.

[0127] In an embodiment of the present invention, based on step S108, a possible embodiment will be given below to non - restrictively elaborate on its specific implementation scheme. S108 specifically includes the following steps:

[0128] Step S1081: Analyze the transmission effect evaluation result. When the evolutionary similarity is lower than the preset similarity threshold or the deviation is higher than the preset deviation threshold, trigger the cross - chain transmission strategy optimization process.

[0129] In some embodiments, on - demand triggering of transmission strategy optimization is achieved, ensuring that the system will not be unnecessarily disturbed during stable operation, while being able to respond promptly to performance degradation.

[0130] Step S1082: Screen out all candidate encrypted transmission paths that match the current business scenario from a pre - established trusted path library.

[0131] In some embodiments, the system maintains a trusted path library, which stores various types of encrypted transmission paths and their metadata that have been historically verified. When the optimization process is triggered, the system uses the characteristics of the current transmission task as screening conditions to retrieve all paths applicable to the current business scenario from the path library. For example, for large - volume financial data transmission, high - bandwidth paths are screened out; for highly sensitive data, paths with a high security rating are screened out. This ensures that the candidate path set is highly relevant to the requirements of the current transmission task, improving the efficiency and pertinence of the optimization process.

[0132] Step S1083: Calculate the evolutionary similarity between the path evolutionary pattern data of each candidate encrypted transmission path and the current transmission path evolutionary pattern data, and the deviation between each candidate encrypted transmission path and its own historical path version respectively.

[0133] In some embodiments, for each selected candidate path, its latest path evolution pattern data is obtained, and its similarity to the current problematic path pattern is calculated, reflecting the substitutability of the behavioral pattern. Simultaneously, the deviation of the candidate path itself is calculated, reflecting its current stability. This process generates an evaluation metric for each candidate path.

[0134] Step S1084: For each candidate encrypted transmission path, a comprehensive score is calculated based on its evolutionary similarity and deviation; the comprehensive score adopts a weighted summation model, in which evolutionary similarity is given a positive weight and deviation is given a negative weight.

[0135] In some embodiments, two indicators with different dimensions and meanings are unified into a comprehensive scoring system. This is achieved by assigning positive weights to evolutionary similarity and negative weights to deviation, followed by a weighted summation. A higher-scoring candidate path indicates that it is both highly similar to the desired behavioral pattern and highly stable.

[0136] Step S1085: Select the candidate encrypted transmission path with the highest comprehensive score as the optimized cross-chain transmission strategy; update the priority of the paths in the trusted path library, and send the optimized cross-chain transmission strategy to the network routing module of the initial blockchain.

[0137] In some embodiments, the comprehensive scores of all candidate paths are ranked, and the path with the highest score is selected as the final optimized cross-chain transmission strategy. Subsequently, the system updates the trusted path library, for example, by increasing the priority or weight of the selected path so that it can be considered more quickly in future screenings. Simultaneously, performance issues of currently replaced paths are recorded, and their priority may be reduced. Finally, the selected optimized path strategy is encapsulated into a control command and sent to the network routing module of the initial blockchain.

[0138] This embodiment enables dynamic and adaptive switching of transmission paths, continuously ensuring the quality of service for cross-chain transmission. Optimizing the decision feedback to the initial blockchain enhances the adaptability and robustness of the entire cross-chain system.

[0139] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0140] The following are embodiments of the encrypted-driven cross-chain interaction anti-tampering system for financial data provided in this disclosure. This system and the encrypted-driven cross-chain interaction anti-tampering method for financial data in the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the encrypted-driven cross-chain interaction anti-tampering system for financial data, please refer to the embodiments of the encrypted-driven cross-chain interaction anti-tampering method for financial data described above.

[0141] The system includes:

[0142] The data acquisition module is used to collect financial data from the economic data platform;

[0143] The field parsing and encapsulation module is used to parse the fields of the financial data, identify the security level of each field and filter out sensitive fields; encrypt the sensitive fields, and encapsulate the encrypted sensitive fields and other non-sensitive fields into sensitive field sub-units and ordinary field sub-units respectively to generate financial field units;

[0144] The transmission path filtering module is used to obtain a candidate set of transmission paths between the initial blockchain and the target blockchain, score the transmission performance of the candidate paths based on the operating parameters of each relay node, and filter out the paths that meet the preset performance score threshold as the target transmission path.

[0145] The path encryption module is used to perform structural partitioning and encryption processing on the target transmission path to generate an encrypted transmission path.

[0146] The transmission verification module is used to send the financial field unit to the target blockchain node through the encrypted transmission path, and the target blockchain node performs a security verification on the received financial field unit.

[0147] The backtracking and repair module is used to backtrack the received financial field unit based on the encrypted transmission path if the security verification result does not meet the expected goal, so as to obtain and store the repaired financial field unit.

[0148] The transmission effect evaluation module is used to evaluate the transmission process of financial field units and obtain the transmission effect evaluation results.

[0149] The optimization and update module designs and optimizes the cross-chain transmission strategy based on the transmission effect evaluation results, and sends the optimized cross-chain transmission strategy to the initial blockchain.

[0150] like Figure 2 As shown, this application also provides an electronic device, including a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of an encrypted-driven cross-chain interaction anti-tampering method for financial data.

[0151] In embodiments of the present invention, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0152] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0153] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0154] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0155] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A cryptographically driven method for preventing tampering in cross-chain interaction of financial data, characterized in that, The methods include: S101: Collect financial data from the economic data platform; S102: Parse the fields of the financial data, identify the security level of each field, and filter out sensitive fields; The sensitive fields are encrypted, and the encrypted sensitive fields are encapsulated with other non-sensitive fields into sensitive field sub-units and ordinary field sub-units, respectively, to generate financial field units; S103: Obtain a candidate set of transmission paths between the initial blockchain and the target blockchain, score the transmission performance of the candidate paths based on the operating parameters of each relay node, and select the path that meets the preset performance score threshold as the target transmission path. S104: Perform structural partitioning and encryption processing on the target transmission path to generate an encrypted transmission path; S105: The financial field unit is sent to the target blockchain node through the encrypted transmission path, and the target blockchain node performs a security check on the received financial field unit. S105 specifically includes the following steps: S1051: Add transmission metadata to the header of the financial field unit, and forward the financial field unit hop by hop according to the path node order through the node communication interface of the encrypted transmission path. S1052: After receiving the financial field unit, the target blockchain node verifies the header checksum and parses its structure to separate the sensitive field sub-units from the ordinary field sub-units. S1053: The target blockchain node obtains its own permission level and compares it with the permission level required by the security level label of the sensitive field sub-unit to complete the access permission matching; S1054: Calculate the hash value for the sensitive field sub-unit and the ordinary field sub-unit respectively, and compare it with the hash value preset before transmission to complete the integrity verification; S1055: Check the integrity of the encryption format, required fields, and field boundary markers of the financial field cells to complete the field content structure consistency check; S106: If the security check result does not meet the expected target, the received financial field unit is backtracked based on the encrypted transmission path to obtain the repaired financial field unit and store it. S107: Evaluate the transmission process of the financial field unit and obtain the transmission effect evaluation results; S108: Design and optimize the cross-chain transmission strategy based on the transmission effect evaluation results, and send the optimized cross-chain transmission strategy to the initial blockchain.

2. The encryption-driven cross-chain interaction anti-tampering method for financial data according to claim 1, characterized in that, S102 specifically includes the following steps: The financial data is parsed field by field, extracting the field content, data type, and structural attributes of each field, and generating a field semantic vector through feature encoding; Construct a key field dictionary, match the field semantic vectors with the key field dictionary, and if a field is identified as a key field, assign a key field weight to the key field. Calculate the information entropy of the semantic vector of the field and compare the information entropy with a preset entropy threshold; when the information entropy is lower than the entropy threshold, the information entropy value is used as the information weight of the field. Obtain the semantic usage type of the field and count the frequency of occurrence of the semantic usage type in historical financial data; calculate the security level of the field by weighting and summing the key field weight, information weight, and frequency of occurrence. The security level is compared with the preset security level threshold, and fields with a security level higher than the security level threshold are selected and identified as sensitive fields.

3. The encryption-driven cross-chain interaction anti-tampering method for financial data according to claim 1, characterized in that, S103 specifically includes the following steps: S1031: Preset the scope of the blockchain network used for cross-chain transmission of financial data, determine the initial blockchain and target blockchain within the scope of the blockchain network; initiate operation status detection for all relay nodes within the scope of the blockchain network, and mark relay nodes that meet the requirements of normal connectivity and hardware load rate below the preset threshold as available relay nodes. S1032: Using the initial blockchain as the starting point and the target blockchain as the ending point, and using available relay nodes as intermediate nodes, construct an undirected graph model; use a breadth-first search algorithm to traverse the undirected graph, search for all paths from the starting point to the ending point, and form a candidate set of transmission paths; S1033: Collect the operating parameters of the relay nodes contained in each path in the candidate transmission path set, and perform standardization processing on the operating parameters to obtain the standardized parameter values; S1034: Set the weight coefficients for each operating parameter, and the sum of the weight coefficients is 1; Calculate the average value of the standardized parameters corresponding to all relay nodes in each path, multiply the average value of each parameter by the corresponding weight coefficient, and then sum them to obtain the transmission performance score of each path; S1035: Select paths with transmission performance scores not lower than the preset transmission performance score threshold from the candidate transmission path set as optional paths; Based on the current number of bytes of financial data and the network status of the target blockchain, select the path that meets the field structure size requirements and has the lowest path load rate from the available paths as the target transmission path.

4. The encryption-driven cross-chain interaction anti-tampering method for financial data according to claim 1, characterized in that, S104 specifically includes the following steps: The target transmission path is divided into a path header, a path node segment, and a path tail. The path header stores path attribute information, the path node segment stores the structural information of each relay node, and the path tail stores integrity verification data. Calculate the path hash value of the complete path structure and embed it into the structure. Construct several pseudo-nodes to insert into the path node segments and mark the node types to obtain a hybrid node path structure. Reconstruct the order of all nodes in the hybrid node path structure to generate a shuffled node structure, and build an index mapping table that records the original node order. The index mapping table is appended to the end of the path with a shuffled node structure, and the resulting extended path structure is encapsulated in a unified format. The encapsulated extended path structure is encrypted using an encryption algorithm to generate an encrypted transmission path.

5. The encryption-driven cross-chain interaction anti-tampering method for financial data according to claim 1, characterized in that, S106 specifically includes the following steps: S1061: Decrypt the encrypted transmission path bound to the financial field unit, extract the index mapping table, and restore the node order of the original transmission path based on the index mapping table; S1062: In accordance with the original transmission path node order, initiate field status verification requests to each relay node in the path in sequence, and receive the field status information returned by each node. For nodes that return valid cache tags, retrieve cached copies of their stored fields; S1063: Compare the field cache copy of each relay node with the field status returned by the node; if there is a structural difference between the nodes that is greater than the preset difference threshold, the node is identified as a potential tampering node; confirm the final tampering node by performing encrypted hash fragment comparison on the sensitive field parts; S1064: Obtain field cache copies from several trusted nodes upstream of the tampered node to form a field cache copy set; calculate the credibility of each copy in the set and sort them, and determine the copy with the highest credibility as the backtracking template; S1065: Reconstruct the field information at the tampered node based on the backtracking template to obtain the reconstructed field unit; construct the data backtracking record and embed it into the reconstructed field unit, and output the repaired financial field unit.

6. The encryption-driven cross-chain interaction anti-tampering method for financial data according to claim 1, characterized in that, S107 specifically includes the following steps: S1071: Real-time acquisition of transmission feedback data generated by the financial field unit during transmission on the encrypted transmission path; S1072: Arrange the transmission feedback data into a time-series event sequence according to the node order of the encrypted transmission path to form a path behavior trajectory; extract the state feature vector from the path behavior trajectory to construct path evolution pattern data; S1073: Calculate the evolutionary similarity between path evolution pattern data and historical path evolution pattern data corresponding to historical path events; S1074: Calculate the deviation between path evolution model data and historical path evolution model data; S1075: Compare the evolutionary similarity and deviation with the preset similarity threshold and deviation threshold, respectively; The transmission performance evaluation results are generated based on the comparison results.

7. The encryption-driven cross-chain interaction anti-tampering method for financial data according to claim 1, characterized in that, S108 specifically includes the following steps: S1081: Analyze the transmission effect evaluation results. When the evolutionary similarity is lower than the preset similarity threshold or the deviation is higher than the preset deviation threshold, trigger the cross-chain transmission strategy optimization process. S1082: Select all candidate encrypted transmission paths that match the current business scenario from the pre-established trusted path library; S1083: Calculate the evolutionary similarity between the path evolution pattern data of each candidate encrypted transmission path and the current transmission path evolution pattern data, as well as the deviation between each candidate encrypted transmission path and its own historical path version. S1084: For each candidate encrypted transmission path, a comprehensive score is calculated based on its evolutionary similarity and deviation. The comprehensive score adopts a weighted summation model, in which evolutionary similarity is given a positive weight and deviation is given a negative weight. S1085: Select the candidate encrypted transmission path with the highest comprehensive score as the optimized cross-chain transmission strategy; Update the priority of paths in the trusted path library and send the optimized cross-chain transmission strategy to the network routing module of the initial blockchain.

8. A cryptographically driven cross-chain interaction anti-tampering system for financial data, characterized in that, The system is used to implement the encryption-driven cross-chain interaction anti-tampering method for financial data as described in any one of claims 1 to 7; The system includes: The data acquisition module is used to collect financial data from the economic data platform; The field parsing and encapsulation module is used to parse the fields of financial data, identify the security level of each field and filter out sensitive fields; encrypt the sensitive fields, and encapsulate the encrypted sensitive fields and other non-sensitive fields into sensitive field sub-units and ordinary field sub-units respectively to generate financial field units; The transmission path filtering module is used to obtain a candidate set of transmission paths between the initial blockchain and the target blockchain, score the transmission performance of the candidate paths based on the operating parameters of each relay node, and filter out the paths that meet the preset performance score threshold as the target transmission path. The path encryption module is used to perform structural partitioning and encryption processing on the target transmission path to generate an encrypted transmission path. The transmission verification module is used to send the financial field unit to the target blockchain node through the encrypted transmission path, and the target blockchain node performs a security verification on the received financial field unit. The backtracking and repair module is used to backtrack the received financial field unit based on the encrypted transmission path if the security verification result does not meet the expected goal, so as to obtain and store the repaired financial field unit. The transmission effect evaluation module is used to evaluate the transmission process of financial field units and obtain the transmission effect evaluation results. The optimization and update module designs and optimizes the cross-chain transmission strategy based on the transmission effect evaluation results, and sends the optimized cross-chain transmission strategy to the initial blockchain.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the cryptographically driven cross-chain interaction anti-tampering method for financial data as described in any one of claims 1 to 7.

Images