Cross-chain data verification and reconciliation processing method for financial-grade distributed transactions

Abstract

The application discloses a cross-chain data verification and reconciliation processing method for financial-level distributed transactions, relates to the technical field of blockchain cross-chain and financial reconciliation, and comprises the following steps: generating reconciliation metadata by taking a single cross-chain distributed transaction as a minimum reconciliation unit, constructing a transaction causal dependence mapping and generating verification metadata, completing real-time reconciliation verification through a smart contract with embedded financial difference rolling rules after consensus adaptation and risk parameter adjustment, automatically backtracking and locating differences and generating an evidence package when the reconciliation is inconsistent, and the application can realize real-time discovery of multi-chain state inconsistency by sinking the reconciliation granularity to the transaction level and combining causal dependence verification. Through the embedded financial rules and the automatic tracing mechanism, the reconciliation result can match the clearing yardstick, and the cost of manual troubleshooting can be reduced.

Description

Technical Field

[0001] This invention relates to the field of blockchain cross-chain and financial reconciliation technology, specifically to a cross-chain data verification and reconciliation processing method for financial-grade distributed transactions. Background Technology

[0002] As consortium blockchain technology is increasingly applied in financial services such as payment clearing and fund transfer, multi-chain heterogeneous deployment architectures are commonly adopted in multi-institutional collaboration scenarios. Different participating entities build independent blockchain systems based on their own compliance requirements and technology choices. Cross-chain distributed transactions require state synchronization and fund transfers across multiple chains. Reconciliation, as a core link in ensuring fund security, directly affects the operational reliability of cross-chain transactions due to its accuracy and timeliness. Currently, the cross-chain technology system continues to evolve around message passing, atomic commits, and lightweight client verification, and reconciliation-related implementations are gradually adapting to the storage and verification characteristics of on-chain data.

[0003] Existing cross-chain reconciliation solutions mostly adopt a periodic batch processing model, using account balances or batch transactions as the reconciliation unit. This fails to identify inconsistencies in real time during transaction execution, resulting in a long exposure window for financial risks. At the verification logic level, most solutions only independently verify the signature and hash value of a single transaction, neglecting the causal dependencies and execution order constraints between financial transactions. This makes them susceptible to reconciliation discrepancies caused by out-of-order cross-chain messages and abnormal execution of dependent transactions. Furthermore, existing reconciliation contracts often focus on general data consistency comparisons, failing to integrate financial business rules such as netting and fee accrual into the verification logic. Reconciliation results require manual secondary calculation to match settlement standards, resulting in a lengthy processing chain and susceptibility to human error. Moreover, when inconsistencies arise, existing solutions can only output anomaly conclusions, failing to automatically pinpoint the specific location and cause of the discrepancy. Troubleshooting relies on manual verification of each transaction, which is ill-suited to the efficient operational requirements of financial businesses. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a cross-chain data verification and reconciliation processing method for financial-grade distributed transactions. This method addresses the problems of lagging batch processing of cross-chain reconciliation, lack of consideration for transaction causal dependencies, lack of embedded financial business rules, and inability to automatically locate discrepancies. It adopts transaction-level reconciliation granularity, combined with causal dependency mapping, heterogeneous consensus adaptation, and dynamic risk parameter tuning mechanisms. It natively embeds financial netting rules into the reconciliation smart contract, simultaneously realizing real-time verification of the entire transaction lifecycle and automatic traceability of reconciliation discrepancies. It can identify state anomalies during transaction execution, ensure that reconciliation results meet the requirements of clearing business, reduce manual processing steps, and adapt to the reconciliation needs of multi-chain heterogeneous financial scenarios.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: a cross-chain data verification and reconciliation processing method for financial-grade distributed transactions, comprising the following steps:

[0006] S1: Construct a transaction-level reconciliation benchmark, taking a single cross-chain distributed transaction as the smallest reconciliation unit, and generating reconciliation metadata for each transaction, including transaction identifier, stage status, fund change fields, and participant signature information; each participating chain synchronously updates the corresponding reconciliation metadata after each execution stage of the transaction is completed, and the update action is bound to the transaction block consensus confirmation action. The reconciliation metadata is stored on the chain in a layered evidence storage mode, and idempotent verification logic based on the transaction identifier is configured.

[0007] S2: Establish a transaction causal dependency mapping, extract the pre-dependencies between transactions based on the business flow logic of cross-chain transactions, construct the corresponding directed acyclic graph and encode the dependencies into verification metadata. The verification metadata and reconciliation metadata are associated and bound with the same transaction identifier and broadcast synchronously to each participating chain along with the reconciliation metadata.

[0008] S3: Match the corresponding verification strategies of each participating chain through the consensus adaptation mechanism, dynamically adjust the verification parameters according to the transaction risk level, and execute real-time reconciliation verification based on embedded financial rules; through the reconciliation smart contract deployed on each participating chain, synchronously pull the reconciliation metadata and dependent verification metadata of each chain throughout the entire transaction lifecycle, complete the net transaction amount calculation and state consistency verification based on the preset financial netting rules, and verify the execution order and result consistency of dependent transactions, and output the preliminary reconciliation conclusion; the reconciliation process generates reconciliation baseline snapshots at preset block height intervals, and performs reconciliation verification incrementally between adjacent snapshots;

[0009] S4: Automatic source tracing and location of reconciliation discrepancies. When the initial reconciliation conclusion is inconsistent, the field values, signature sequences and timestamps of the reconciliation metadata of each chain are compared back stage by stage along the transaction execution path to locate the specific chain, transaction stage and data field where the discrepancy occurred, and generate the corresponding discrepancy evidence package and classification results.

[0010] Furthermore, the process of constructing the transaction causal dependency mapping in step S2 is as follows:

[0011] The system analyzes the business flow logic of cross-chain transactions, identifies all preconditions and subsequent triggering transactions for transaction execution, and classifies dependencies into three categories: funding adequacy dependency, timing dependency, and authorization dependency. These three types of dependencies correspond to three business rules: funding constraints, timing constraints, and permission constraints, respectively, covering common dependency scenarios in financial transactions. A directed acyclic graph (DAG) is constructed with individual transactions as nodes and dependency relationships as directed edges. Each dependency edge is labeled with its corresponding dependency type and execution order constraint. The adjacency list encoding information of the DAG is written into the verification metadata of the corresponding transaction and simultaneously uploaded to the blockchain for evidence storage along with the transaction initiation.

[0012] Furthermore, the consensus adaptation mechanism in step S3 is executed according to the following rules:

[0013] For finality consensus chains, a block height finality verification strategy is adopted to confirm that the transaction has reached an irreversible final consensus in the block;

[0014] For probabilistic consensus chains, a confirmation depth threshold verification strategy is adopted. When the number of subsequent confirmed blocks of a transaction reaches a preset confirmation depth threshold, the on-chain state of the transaction is accepted.

[0015] For consortium blockchains that adopt an endorsement strategy, the set of endorsement nodes is analyzed to verify that the proportion of valid endorsement signatures meets the preset signature threshold.

[0016] The adaptation process is completed through an independent adaptation layer, without requiring modification to the native consensus logic of each chain, and is compatible with participating chains of different architectures.

[0017] Furthermore, the process of adjusting the transaction risk level in step S3 is as follows:

[0018] Before reconciliation and verification, the current transaction is first risk-rated to obtain a risk score. Based on the risk score, the three types of verification parameters, namely the number of verification nodes, the signature threshold, and the number of confirmation blocks, are dynamically adjusted. The higher the risk score, the larger the corresponding value of the verification parameter, so as to achieve dynamic matching between the verification strength and the degree of transaction risk and avoid low-risk transactions occupying too many verification resources.

[0019] Furthermore, the risk rating is calculated using the following score formula:

[0020]

[0021] in, This is the transaction risk score, ranging from 0 to 100. The normalized value of the transaction amount is obtained by linear normalization based on a preset large amount threshold. The normalized value of the historical anomaly rate of the participants is calculated based on the proportion of reconciliation anomalies within a preset statistical period. For the sensitivity score of fund flow, a preset high value is used for cross-border corporate fund flows, and a preset low value is used for internal transfers within the same institution. , , The weight coefficients are for the amount dimension, the abnormality rate dimension, and the flow direction dimension, respectively, satisfying... ;

[0022] The scores for each dimension have been normalized to ensure that the indicators of different dimensions are weighted, and the weight coefficients can be dynamically adjusted through on-chain configuration.

[0023] Furthermore, the preset financial netting rules in step S3 include the logic for calculating multilateral net netting, which uses the following formula:

[0024]

[0025] in, For the first The net balance of the reconciliation cycle for each participating chain is calculated as follows: a positive value represents net receivables, and a negative value represents net payables. The total number of blockchains participating in the reconciliation; For the first time during the reconciliation period chain to the first The sum of funds from all reconciliation transactions initiated by the chain; For the first time during the reconciliation period chain to the first The sum of funds from all reconciliation transactions initiated by the chain; For the first time during the reconciliation period The total amount of transaction fees that should be accrued according to the business rules corresponding to the chain;

[0026] During the reconciliation and verification process, the contract first calculates the net amount of each chain according to the above formula, and then performs a net amount consistency comparison. The calculation process is completed in a closed loop within the on-chain contract, and the whole process is traceable and auditable, avoiding operational errors caused by manual netting.

[0027] Furthermore, in step S3, when verifying the consistency of the execution order and result of dependent transactions, each preceding dependency is verified one by one using the dependency validity determination formula, which is:

[0028]

[0029] in, For the current cross-chain transaction that is yet to be verified; For the current transaction One preceding dependent transaction; For preceding dependent transactions The execution status indicator takes a value of 1 when execution is successful and a value of 0 when execution fails or is not executed. For preceding dependent transactions The timestamp of the completed block on the corresponding participating chain; For current affairs The timestamp of the initiating block on the initiating chain;

[0030] When the equation result of all the preceding dependencies is 1, the dependency relationship is determined to meet the verification requirements. The verification adopts short-circuit logic. If a non-satisfied item is encountered, the process is terminated immediately and an exception is marked, reducing unnecessary computational overhead.

[0031] Furthermore, the reconciliation benchmark snapshot in step S3 includes three aggregated indicators: cumulative reconciliation root hash, cumulative net amount, and total number of transactions. Between two adjacent benchmark snapshots, reconciliation verification is performed only on cross-chain transactions newly added within the interval. After verification, the continuity and correctness of the cumulative indicators are verified by incremental hash proof. The snapshot generation process does not interrupt normal reconciliation business, thus achieving smooth execution of periodic reconciliation.

[0032] Furthermore, the specific execution process of difference tracing in step S4 is as follows:

[0033] Starting from the final state of the transaction, the process traces backward in reverse order of the execution stages: transaction completion, confirmation, and pre-commit. The reconciliation metadata of each participating chain at each stage is compared sequentially. When a field value inconsistency occurs at a certain stage, that stage is marked as the starting point of the discrepancy. Simultaneously, the transaction execution log, node signature set, and corresponding block height information for that stage are extracted. Based on the discrepancy field type and state deviation characteristics, a pre-defined classification rule is matched to output the discrepancy classification results. These categories include consensus delay, contract execution anomaly, missing signature, and data tampering. All related data is packaged into a discrepancy evidence package containing the discrepancy location, deviation value, and supporting logs. The classification results can be directly integrated into the operation and maintenance handling process, shortening the anomaly response time.

[0034] Furthermore, the layered evidence storage mode in step S1 is executed according to the following rules:

[0035] The summary layer data includes the hash value, transaction identifier, and stage status of reconciliation metadata, which are stored on the blockchain in real time.

[0036] The detailed layer data contains complete transaction details and fund field details, which are encrypted and stored in an off-chain distributed storage system. The detailed layer data is hashed and anchored to the on-chain digest layer.

[0037] The idempotent verification logic is as follows: when a duplicate reconciliation request for the same transaction arrives, the existing reconciliation record is retrieved based on the transaction identifier. If a valid record exists, the corresponding result is returned directly without repeating the verification logic. This controls the on-chain storage volume while ensuring that the data is verifiable, and avoids confusion in reconciliation results caused by duplicate requests.

[0038] Compared with existing technologies, this cross-chain data verification and reconciliation processing method for financial-grade distributed transactions has the following advantages:

[0039] I. This invention moves the reconciliation unit down from the account batch level to a single distributed transaction, and combines transaction causal dependency mapping with full lifecycle synchronous verification to replace the traditional periodic batch reconciliation mode. It can synchronously identify multi-chain state inconsistencies at each stage of transaction execution, shorten the exposure time of financial risks, and at the same time, by verifying the execution status and sequence of the preceding dependent transactions, it avoids reconciliation misjudgments caused by cross-chain message disorder or dependent transaction anomalies, thereby improving the accuracy of reconciliation results.

[0040] Second, this invention embeds financial netting rules natively into reconciliation smart contracts, and with the automatic traceability mechanism for transaction-level differences, the net amount results output by reconciliation directly match the clearing business caliber, eliminating the need for subsequent manual netting and conversion. At the same time, when inconsistencies occur in reconciliation, it can automatically locate the chain segment, execution stage and specific field where the difference occurs, and generate a verifiable difference evidence package, reducing the workload of manual item-by-item investigation and adapting to the rigor and efficiency requirements of reconciliation in financial scenarios.

[0041] Third, this invention can adapt to participating chain environments with different consensus types through a heterogeneous consensus adaptation mechanism and a risk level dynamic parameter adjustment strategy. It can flexibly adjust the verification strength according to the degree of transaction risk, control the verification overhead while ensuring financial-grade credibility, and reduce the amount of repetitive calculations in periodic reconciliation by adopting incremental snapshot reconciliation and layered evidence storage mode, thus balancing data traceability and on-chain storage efficiency.

[0042] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

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

[0044] Figure 1 This is a schematic diagram of the overall process of the cross-chain data verification and reconciliation method for financial-grade distributed transactions of the present invention.

[0045] Figure 2 This is a schematic diagram of the transaction causal dependency mapping construction and verification process of the present invention;

[0046] Figure 3 This is a schematic diagram of the automatic traceability process for reconciliation discrepancies in this invention. Detailed Implementation

[0047] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0048] This embodiment uses an interbank payment clearing scenario as an example to detail the complete execution process of cross-chain data verification and reconciliation processing methods for financial-grade distributed transactions. For example... Figure 1 As shown, the method is executed sequentially through four core stages: transaction-level reconciliation benchmark construction, causal dependency mapping establishment, real-time reconciliation verification, and discrepancy tracing. This embodiment runs on a business network composed of three heterogeneous consortium chains: the account opening bank chain, the counterparty bank chain, and the clearing center chain. Within the network, reconciliation smart contracts, consensus adaptation modules, risk rating modules, and discrepancy tracing modules are deployed. A single cross-chain transfer transaction is used as the smallest reconciliation unit to complete reconciliation verification throughout the entire transaction lifecycle.

[0049] During the transaction initiation phase, the first step is to construct the transaction-level reconciliation baseline. The system uses a single cross-chain transfer transaction as the smallest reconciliation unit. Upon transaction initiation, the opening bank's chain generates a globally unique transaction identifier according to preset encoding rules and simultaneously initializes the reconciliation metadata. The reconciliation metadata includes four core categories: transaction identifier, stage status, fund change field, and participant signature information. The stage status is dynamically updated as the transaction progresses. The fund change field records the transfer amount, currency, paying account, and receiving account information. The participant signature information records the confirmation signatures of each chain node for the current transaction status. Each time a transaction completes one of the pre-commit, confirmation, or completion stages, the three participating chains synchronously update their locally stored reconciliation metadata, completing the state writing and signature attachment for the corresponding stage. The reconciliation metadata is stored using a layered notarization model. The digest layer data contains the hash value of the reconciliation metadata, the transaction identifier, and the stage status, and is written to the corresponding participating chain's block in real time for notarization. The detailed layer data contains complete transaction details and fund field details. After symmetric encryption, it is stored in an off-chain distributed storage system. The hash value of the detailed layer data is anchored to the on-chain digest layer, ensuring that the detailed data is immutable and verifiable. Access to the detailed layer data requires permission verification, and only authorized nodes can retrieve the corresponding detailed content. The reconciliation process is configured with idempotent verification logic based on transaction identifiers. When a duplicate reconciliation request for the same transaction arrives, the system first retrieves the stored reconciliation record using the transaction identifier. If a valid reconciliation result already exists, the corresponding content is returned directly without repeating subsequent verification logic, thus avoiding duplicate calculations and result conflicts.

[0050] Next, we construct the transaction causal dependency mapping. For example... Figure 2As shown, the system parses the business flow logic of the current cross-chain transfer transaction, identifying that the precondition transaction is the intraday fund collection transaction of the payment account, with no subsequent triggering transactions, and the corresponding dependency type is fund adequacy dependency. The system constructs a directed dependency edge with the fund collection transaction as the precondition node and the current transfer transaction as the subsequent node, labeling the dependency type as fund adequacy dependency and the execution order constraint as the current transaction can only be started after the precondition transaction is successful. The system serializes and encodes the adjacency list containing node and edge information and writes it into the verification metadata of the current transfer transaction. The verification metadata, along with the reconciliation metadata, is broadcast to the counterparty chain and clearing center chain via the cross-chain message channel. Each participating chain receives and stores it in its local metadata database, binding it with the corresponding transaction identifier.

[0051] Before reconciliation verification is executed, the verification strategy corresponding to each participating chain is matched through a consensus adaptation mechanism. The consensus adaptation module obtains consensus type information by reading the on-chain configuration parameters of each chain and executes differentiated verification logic for different consensus mechanisms. In this embodiment, the account opening bank chain and the counterparty bank chain adopt a finality consensus mechanism, and the system adopts a block height finality verification strategy accordingly. After confirming that the block in which the transaction is located has been fully confirmed by the consensus nodes and has reached an irreversible final consensus state, the on-chain data of the transaction is then accepted. The clearing center chain adopts a consortium chain mechanism with an endorsement strategy. The system first parses the set of endorsement nodes corresponding to the transaction, counts the number of valid endorsement signatures, and confirms that the transaction status conforms to the on-chain rules after verifying that the proportion of valid endorsement signatures meets the preset signature threshold. If the business scenario includes a probabilistic consensus chain, the system adopts a confirmation depth threshold verification strategy, which counts the number of consecutive confirmed blocks after the block in which the transaction is located in real time. When the number of confirmed blocks reaches the preset confirmation depth threshold, the transaction status is determined to have sufficient credibility, and the corresponding on-chain data is accepted.

[0052] After consensus adaptation is completed, the system performs a risk rating on the current transaction and dynamically adjusts the verification parameters based on the risk level. The risk rating uses a scoring formula to calculate the transaction risk score:

[0053]

[0054] in, This is the transaction risk score, ranging from 0 to 100. The normalized value of the transaction amount is obtained by linear normalization based on a preset large amount threshold. The normalized value of the historical anomaly rate of the participants is calculated based on the proportion of reconciliation anomalies within a preset statistical period. For the sensitivity score of fund flow, a preset high value is used for cross-border corporate fund flows, and a preset low value is used for internal transfers within the same institution. , , The weight coefficients are for the amount dimension, the abnormality rate dimension, and the flow direction dimension, respectively, satisfying... The weighting coefficients can be adjusted via on-chain configuration contracts to adapt to security strategies at different stages. In this embodiment, the transfer is an internal allocation within the same institution, so the fund flow sensitivity score is set to a preset low value. The risk score calculated by combining the transaction amount and the participant's historical anomaly rate is in the low range. The system accordingly lowers the values ​​of the number of verification nodes, the signature threshold, and the number of confirmed blocks to control unnecessary computational overhead. The risk score is positively correlated with the values ​​of the three types of verification parameters; the higher the score, the stronger the verification.

[0055] Subsequently, real-time reconciliation verification based on embedded financial rules is executed. The reconciliation smart contract is deployed on the clearing center chain. Each time a transaction completes an execution phase and its state is uploaded to the chain, a reconciliation verification is automatically triggered. During the verification process, the contract simultaneously pulls reconciliation metadata and dependency verification metadata from the three participating chains, sequentially completing financial netting calculation, state consistency verification, and dependency legality verification. The financial netting rule uses a multilateral netting calculation formula to calculate the netting amount for each chain. The formula is:

[0056]

[0057] in, For the first The net balance of the reconciliation cycle for each participating chain is calculated as follows: a positive value represents net receivables, and a negative value represents net payables. The total number of blockchains participating in the reconciliation; For the first time during the reconciliation period chain to the first The sum of funds from all reconciliation transactions initiated by the chain; For the first time during the reconciliation period chain to the first The sum of funds from all reconciliation transactions initiated by the chain; For the first time during the reconciliation period The total amount of transaction fees to be accrued according to the business rules of each chain. The reconciliation period can be configured as a single transaction dimension or a fixed time window dimension according to business needs. Under the single transaction dimension, only the net amount corresponding to the current transaction is calculated. Under the fixed time window dimension, the net amount of all transactions within the calculation period is accumulated. The contract first calculates the net amount of each participating chain according to the above formula, and then compares the consistency of the calculation results of each chain to confirm that the netting results match.

[0058] After the state consistency check is completed, the contract checks the execution order and result consistency of dependent transactions, using a dependency validity determination formula to check each preceding dependency item one by one. The formula is as follows:

[0059]

[0060] in, For the current cross-chain transaction that is yet to be verified; For the current transaction One preceding dependent transaction; For preceding dependent transactions The execution status indicator takes a value of 1 when execution is successful and a value of 0 when execution fails or is not executed. For preceding dependent transactions The timestamp of the completed block on the corresponding participating chain; For current affairs The timestamp of the initiation block on the initiating chain. The contract iterates through all the preceding dependencies of the current transaction, calculating the equation result one by one. If any dependency fails to meet the condition, the verification terminates directly and an anomaly is marked, without needing to traverse all dependencies. When the equation result of all preceding dependencies is 1, the dependency relationship is determined to meet the verification requirements. If both the netting consistency check and the dependency legality check pass, a preliminary conclusion of reconciliation consistency is output; if either check fails, a preliminary conclusion of reconciliation inconsistency is output.

[0061] The reconciliation process generates reconciliation baseline snapshots at preset block height intervals. These snapshots are automatically triggered by the reconciliation smart contract when the block height reaches a preset interval threshold. Each snapshot includes three aggregated metrics: cumulative reconciliation root hash, cumulative net balance, and total number of transactions. Between two adjacent baseline snapshots, the system only performs reconciliation verification on newly added cross-chain transactions within the interval, eliminating the need to repeatedly process all historical transactions. After verification, the system generates an incremental hash proof. This incremental hash proof is calculated based on the root hash of the previous snapshot and the root hash of the new transaction. It is used to verify the legality of the derivation process of the cumulative value, and to verify the continuity and correctness of the cumulative metrics, ensuring error-free data connection between snapshots and reducing the computational overhead of periodic reconciliation.

[0062] When the initial reconciliation conclusion indicates inconsistency, the automatic source tracing process for reconciliation discrepancies is initiated. For example... Figure 3As shown, the system traces back along the transaction execution path, comparing the reconciliation metadata fields of each chain in the three stages of completion, confirmation, and pre-commitment. When a discrepancy is found in a field value at a certain stage, that stage is marked as the starting point of the difference, and the corresponding transaction execution log, node signature set, and corresponding block height information are extracted. Based on the difference field type and state deviation characteristics, the system matches the preset classification rules and outputs the difference classification results. The difference classification includes consensus delay, contract execution anomaly, missing signature, and data tampering. Among them, consensus delay corresponds to the case where the transaction state has been written but the block confirmation progress is lagging behind; contract execution anomaly corresponds to the case where the calculation result of the funds field does not match the preset rules; missing signature corresponds to the case where the number of valid signatures has not reached the preset threshold; and data tampering corresponds to the case where the data hash verification fails. After classification, the system packages all related data such as difference location, deviation value, and supporting logs into a difference evidence package. All data in the evidence package is accompanied by the corresponding block height identifier and signature information. The digest hash of the evidence package is stored on the chain, and the detailed data is encrypted and stored in an off-chain distributed storage system.

[0063] This embodiment uses an interbank payment clearing scenario as an example to fully present the execution logic of the entire process of transaction-level cross-chain reconciliation. This method is applicable to multi-chain collaborative financial business scenarios such as interbank payment clearing, multilateral fund transfers, supply chain finance reconciliation, and cross-border settlement, and can also be extended to other business scenarios that require highly reliable cross-chain data consistency verification.

[0064] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for cross-chain data verification and reconciliation processing for financial-grade distributed transactions, characterized in that, The method includes the following steps: S1: Construct a transaction-level reconciliation benchmark, taking a single cross-chain distributed transaction as the smallest reconciliation unit, and generating reconciliation metadata for each transaction, including transaction identifier, stage status, fund change fields, and participant signature information; each participating chain synchronously updates the corresponding reconciliation metadata after each execution stage of the transaction is completed, and the reconciliation metadata is stored on the chain in a layered evidence storage mode, and configured with idempotent verification logic based on the transaction identifier. S2: Establish a transaction causal dependency mapping, extract the pre-dependencies between transactions based on the business flow logic of cross-chain transactions, construct the corresponding directed acyclic graph and encode the dependencies into verification metadata, and broadcast them to each participating chain synchronously along with the reconciliation metadata; S3: Match the corresponding verification strategies of each participating chain through the consensus adaptation mechanism, dynamically adjust the verification parameters according to the transaction risk level, and execute real-time reconciliation verification based on embedded financial rules; through the reconciliation smart contract deployed on the participating chains, synchronously pull the reconciliation metadata and dependent verification metadata of each chain throughout the entire transaction lifecycle, complete the net transaction amount calculation and state consistency verification based on the preset financial netting rules, and verify the execution order and result consistency of dependent transactions, and output the preliminary reconciliation conclusion; the reconciliation process generates reconciliation baseline snapshots at preset block height intervals, and performs reconciliation verification incrementally between adjacent snapshots; S4: Automatic source tracing and location of reconciliation discrepancies. When the initial reconciliation conclusion is inconsistent, the field values, signature sequences and timestamps of the reconciliation metadata of each chain are compared back stage by stage along the transaction execution path to locate the specific chain, transaction stage and data field where the discrepancy occurred, and generate the corresponding discrepancy evidence package and classification results.

2. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 1, characterized in that, The specific process of constructing the transaction causal dependency mapping in step S2 is as follows: Analyze the business flow logic of cross-chain transactions, identify all preconditions and subsequent triggering transactions for transaction execution, and classify dependency types into three categories: funding adequacy dependency, timing dependency, and authorization dependency. Construct a directed acyclic graph with individual transactions as nodes and dependencies as directed edges, and label each dependency edge with the corresponding dependency type and execution order constraints; The adjacency list encoding information of the directed acyclic graph is written into the verification metadata of the corresponding transaction and stored on the blockchain synchronously with the transaction initiation.

3. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 1, characterized in that, The consensus adaptation mechanism in step S3 is executed according to the following rules: For finality consensus chains, a block height finality verification strategy is adopted to confirm that the transaction has reached an irreversible final consensus in the block; For probabilistic consensus chains, a confirmation depth threshold verification strategy is adopted. When the number of subsequent confirmed blocks of a transaction reaches a preset confirmation depth threshold, the on-chain state of the transaction is accepted. For consortium blockchains that adopt an endorsement strategy, the set of endorsement nodes is analyzed to verify that the proportion of valid endorsement signatures meets the preset signature threshold.

4. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 1, characterized in that, The process of adjusting the transaction risk level in step S3 is as follows: Before reconciliation and verification, the current transaction is first risk-rated to obtain a risk score. Based on the risk score, the three types of verification parameters, namely the number of verification nodes, the signature threshold, and the number of confirmation blocks, are dynamically adjusted. The higher the risk score, the larger the corresponding value of the verification parameter.

5. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 4, characterized in that, The risk rating is calculated using the following score formula: in, This is the transaction risk score, ranging from 0 to 100. The normalized value of the transaction amount is obtained by linear normalization based on a preset large amount threshold. The normalized value of the historical anomaly rate of the participants is calculated based on the proportion of reconciliation anomalies within a preset statistical period. For the sensitivity score of fund flow, a preset high value is used for cross-border corporate fund flows, and a preset low value is used for internal transfers within the same institution. , , The weight coefficients are for the amount dimension, the abnormality rate dimension, and the flow direction dimension, respectively, satisfying... .

6. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 1, characterized in that, The preset financial netting rules in step S3 include the logic for calculating the multilateral net netting amount, which is calculated using the following formula: in, For the first The net balance of the reconciliation cycle for each participating chain is calculated as follows: a positive value represents net receivables, and a negative value represents net payables. The total number of blockchains participating in the reconciliation; For the first time during the reconciliation period chain to the first The sum of funds from all reconciliation transactions initiated by the chain; For the first time during the reconciliation period chain to the first The sum of funds from all reconciliation transactions initiated by the chain; For the first time during the reconciliation period The total amount of transaction fees that should be accrued according to the business rules corresponding to the chain; During the reconciliation and verification process, the contract first calculates the net amount of each chain according to the above formula, and then performs a net amount consistency comparison.

7. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 1, characterized in that, In step S3, when verifying the consistency of the execution order and result of dependent transactions, the dependency validity determination formula is used to verify each preceding dependency item one by one. The dependency validity determination formula is as follows: in, For the current cross-chain transaction that is yet to be verified; For the current transaction One preceding dependent transaction; For preceding dependent transactions The execution status indicator takes a value of 1 when execution is successful and a value of 0 when execution fails or is not executed. For preceding dependent transactions The timestamp of the completed block on the corresponding participating chain; For current affairs The timestamp of the initiating block on the initiating chain; The verification uses short-circuit logic. If any prerequisite dependency is not satisfied, the verification is terminated immediately and an exception is marked. When the equation result of all prerequisite dependencies is 1, the dependency relationship is determined to meet the verification requirements.

8. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 1, characterized in that, The reconciliation benchmark snapshot in step S3 includes three aggregated indicators: cumulative reconciliation root hash, cumulative net amount, and total number of transactions. Between two adjacent benchmark snapshots, only cross-chain transactions newly added within the interval are reconciled and verified. After verification, the continuity and correctness of the cumulative indicators are verified by incremental hash proof.

9. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 1, characterized in that, The specific execution process of difference tracing in step S4 is as follows: Starting from the final state of the transaction, backtracking is performed in reverse order of the execution stages of transaction completion, confirmation, and pre-commit. The reconciliation metadata of each participating chain at each stage is compared sequentially. When a field value is inconsistent in a certain stage, that stage is marked as the starting point of the difference. At the same time, the transaction execution log, node signature set, and corresponding block height information of that stage are extracted. Based on the matching of difference field types and state deviation features with preset classification rules, the difference classification results are output. The difference classification includes consensus delay, contract execution anomaly, missing signature, and data tampering. All related data are packaged into a difference evidence package containing difference location, deviation value, and supporting logs.

10. The cross-chain data verification and reconciliation processing method for financial-grade distributed transactions according to claim 1, characterized in that, The layered evidence storage mode in step S1 is executed according to the following rules: The summary layer data includes the hash value, transaction identifier, and stage status of reconciliation metadata, which are stored on the blockchain in real time. The detailed layer data contains complete transaction details and fund field details, which are encrypted and stored in an off-chain distributed storage system. The detailed layer data is hashed and anchored to the on-chain digest layer. The idempotency verification logic is as follows: when a duplicate reconciliation request for the same transaction arrives, the existing reconciliation record is retrieved based on the transaction identifier. If a valid record exists, the corresponding result is returned directly without repeating the verification logic.

Images