Multi-mode aggregation payment security liquidation method and system based on block chain smart contract

Abstract

The invention belongs to the technical field of payment security, and discloses a multi-modal aggregation payment security liquidation method and system based on a block chain smart contract, and the method comprises the steps: 1, obtaining transaction data, and generating an on-chain payment graph based on the transaction data; step 2, respectively calculating a commitment value for each edge in the on-chain payment graph, and respectively generating a zero-knowledge proof for each path formed by a plurality of edges; 3, verifying the zero-knowledge proof, and performing atomic clearing execution on the path corresponding to the zero-knowledge proof passing the verification; and 4, calculating a synchronization priority index of the path subjected to atomic clearing execution, and pushing the path to an account book synchronization module based on the synchronization priority index. According to the invention, a complete framework including data modeling, privacy protection, automatic triggering, atomic liquidation and cross-system synchronization is constructed through the mechanism, and the security, automation degree and actual feasibility of multi-modal payment liquidation are effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of payment security, in particular to a multi-modal aggregated payment security clearing method and system based on a blockchain smart contract. BACKGROUND

[0002] With the continuous enrichment of digital payment means and the gradual popularity of multi-modal payment scenarios, bank cards, digital currencies, third-party electronic wallets, two-dimensional code payments, NFC payments and other methods have been widely used in daily transactions. These means provide more convenience in terms of user experience, but there are significant heterogeneities in payment processes, interface standards and clearing rules, making the efficiency, security and traceability of fund clearing between different payment channels face greater challenges. Existing multi-modal payment aggregation platforms usually rely on centralized gateways for payment path selection and clearing operations. This model certainly has some effect on compatibility, but it also brings problems such as single point of failure, vulnerability to attack, lack of transparency, etc. In addition, due to differences in clearing cycles, regulatory requirements and currency units of different payment channels, existing systems often rely on manual review or heterogeneous logic judgment off-chain, making it difficult to achieve automated and atomic clearing. Even some existing solutions attempt to introduce blockchain and smart contracts into the fund custody and settlement process, but they often lack the ability to model cross-channel fund dependency relationships uniformly, cannot directly express the dependency logic of multiple payments on-chain, and lack pre-validation mechanisms for the credibility of participant behavior and data privacy, so there are still problems such as inconsistent fund status, difficulty in ensuring timely arrival, and vulnerability to unauthorized operations. Therefore, the current multi-modal aggregated payment clearing still faces many technical bottlenecks, including how to express the dependency relationship between multiple payment paths in a unified structured way, how to protect data privacy while ensuring the credibility of contract triggering, how to ensure the atomicity and security of clearing on-chain, and how to quickly and reliably interface the on-chain results with off-chain clearing systems such as banks and meet the T+0 timeliness. SUMMARY

[0003] The present application aims to provide a multi-modal aggregated payment security clearing method and system based on a blockchain smart contract to solve the problems raised in the background.

[0004] The present application provides a multi-modal aggregated payment security clearing method based on a blockchain smart contract, comprising:

[0005] Step one, obtaining transaction data, generating an on-chain payment graph based on the transaction data;

[0006] Step two, calculating a commitment value for each edge in the on-chain payment graph, and generating a zero-knowledge proof for each path composed of multiple edges;

[0007] Step three, verifying the zero-knowledge proof, and performing atomic clearing for the path corresponding to the verified zero-knowledge proof;

[0008] Step four, calculating the synchronization priority index of the path executed by the atomic clearing, and pushing the path to the ledger synchronization module based on the synchronization priority index.

[0009] Preferably, the transaction data is obtained, including:

[0010] The transaction data is obtained through the aggregation gateway.

[0011] Preferably, the transaction data includes messages, transaction information and merchant order data.

[0012] Preferably, the aggregation gateway includes a bank card payment collection module, a digital currency collection module and an electronic wallet payment collection module; the bank card payment collection module is used to receive messages through a communication channel with a bank clearing center;

[0013] The digital currency collection module is used to obtain transaction information through a data channel established with a blockchain node;

[0014] The electronic wallet collection module is used to obtain merchant order data through an application interface.

[0015] Preferably, the on-chain payment graph is generated based on the transaction data, including:

[0016] The initiator, the receiver and the metadata in the transaction data are obtained;

[0017] A triple is generated based on the initiator, the receiver and the metadata;

[0018] The transaction amount contained in the metadata is normalized to obtain a normalized amount;

[0019] The initiator and the receiver in the triple are taken as nodes, and the normalized amount is taken as the weight of the edge to generate the on-chain payment graph. Preferably, the commitment value is calculated, including:

[0020] The metadata digest is calculated based on the metadata;

[0021] The commitment value of the edge is calculated based on the metadata digest.

[0022] Preferably, the zero-knowledge proof is verified, including:

[0023] The trigger metric index of the zero-knowledge proof corresponding to each path is calculated respectively;

[0024] It is judged whether the trigger metric index is greater than the set threshold, and if so, it means that the zero-knowledge proof passes the verification.

[0025] Preferably, the paths are pushed to the ledger synchronization module based on the synchronization priority index, including:

[0026] The synchronization priority index is sorted, and the first N paths with the largest synchronization priority index are pushed to the ledger synchronization module. Preferably, all off-chain receiving systems return a response hash and a timestamp after successful synchronization as the basis for on-chain state updating. The present application also provides a multi-modal aggregated payment security clearing system based on a blockchain smart contract, including a graph generation module, a proof generation module, a clearing execution module, and a synchronization module;

[0027] The graph generation module is used to obtain transaction data and generate an on-chain payment graph based on the transaction data;

[0028] The proof generation module is used to calculate a commitment value for each edge in the on-chain payment graph and generate a zero-knowledge proof for each path composed of multiple edges;

[0029] The clearing execution module is used to verify the zero-knowledge proof and perform atomic clearing on the paths corresponding to the verified zero-knowledge proof;

[0030] The synchronization module is used to calculate the synchronization priority index of the paths that have undergone atomic clearing and push the paths to the ledger synchronization module based on the synchronization priority index.

[0031] Advantages:

[0032] The present application aims at the problems existing in the current multi-modal payment clearing, such as path dependence complexity, lack of unified modeling, insufficient privacy protection, non-transparent clearing trigger condition, and different synchronization between on-chain and off-chain, etc., and proposes a multi-modal aggregated payment security clearing method and system based on a blockchain smart contract. The method first unifies and abstracts multi-modal payment requests such as bank cards, digital currencies, and electronic wallets through a standardized modeling mechanism, and constructs a payment graph on the chain, thereby solving the problem of incompatible heterogeneous interfaces of different channels. Then, the payment path is desensitized and compliance verified using zero-knowledge proof, ensuring that the path meets the amount, time, and continuity constraints while not leaking user plaintext data, and generating a verifiable proof on the chain. The system further dynamically judges and prioritizes the candidate clearing paths based on the preset clearing rules and path verification results, combined with a trigger metric model, and when the conditions are met, the smart contract performs full-path fund settlement in an atomic manner, effectively avoiding inconsistent funds caused by partial success or failure. Finally, the clearing result is synchronized to the bank clearing system and the third-party ledger through the cross-chain oracle, ensuring that the on-chain and off-chain ledger states remain consistent within the T+0 period, and using the FIDO hardware key binding mechanism to ensure the physical credibility of the contract call source. The present application builds a complete framework covering data modeling, privacy protection, automatic triggering, atomic clearing, and cross-system synchronization through the above mechanisms, effectively improving the security, automation, and practicality of multi-modal payment clearing. BRIEF DESCRIPTION OF DRAWINGS

[0033] Figure 1 FIG. 1 is a schematic diagram of the multi-modal aggregated payment security clearing method based on a blockchain smart contract of the present application.

[0034] Figure 2 FIG. 2 is a schematic diagram of the multi-modal aggregated payment security clearing system based on a blockchain smart contract of the present application. DETAILED DESCRIPTION

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

[0036] Please refer to Figure 1 The present application provides a technical solution: a multi-modal aggregated payment security clearing method based on a blockchain smart contract, comprising:

[0037] Step one, acquire transaction data, and generate a payment graph on the chain based on the transaction data.

[0038] In a multi-modal payment system, the first problem to be solved is the difference in interface and data format between different payment channels. Bank card transactions generally follow standard message specifications, including card numbers, amounts, transaction times, etc. Digital currency payments are usually obtained through node interfaces, and their data structures include transaction identifiers, transfer accounts, transfer accounts, amounts, and block times. Electronic wallet payments generally provide data through network interfaces, and fields include user identification, payment order number, amount, currency, and timestamp. These data differ significantly in format and semantics, and if directly processed by smart contracts, it will result in complex logic and poor compatibility. Therefore, it must first be uniformly modeled through a standardized interface.

[0039] Preferably, transaction data is obtained, including:

[0040] Transaction data is obtained through an aggregation gateway.

[0041] Preferably, the transaction data includes messages, transaction information, and merchant order data.

[0042] Preferably, the aggregation gateway includes a bank card payment collection module, a digital currency collection module, and an electronic wallet payment collection module; the bank card payment collection module is configured to receive messages through a communication channel with a bank clearing center;

[0043] The digital currency collection module is configured to obtain transaction information through a data channel established with a blockchain node;

[0044] The electronic wallet collection module is configured to obtain merchant order data through an application interface.

[0045] The bank card payment collection module receives messages through a communication channel with a bank clearing center, from which it extracts account numbers, amounts, currencies, times, etc. The digital currency collection module obtains transaction information through a data channel established with a blockchain node, and parses the sender, recipient, amount, and time. The electronic wallet collection module obtains merchant order data through an application interface, extracting the payer identifier, the recipient identifier, the payment amount, the currency, and the timestamp.

[0046] Preferably, an on-chain payment graph is generated based on the transaction data, including:

[0047] The initiator, recipient, and metadata in the transaction data are obtained.

[0048] A triple is generated based on the initiator, recipient, and metadata:

[0049] All collected data is encapsulated as a triple P = (x, y, M), where x represents the account identifier of the payment initiator, y represents the account identifier of the recipient, and M is the metadata, which includes the amount, currency, and transaction time information.

[0050] The transaction amount contained in the metadata is normalized to obtain a normalized amount:

[0051] Since different currency amounts cannot be directly compared, a normalization function is designed in this step to convert all amounts to a unified internal unit. The formula is as follows:

[0052] A * = F(A, c);

[0053] Where A * represents the normalized amount; A represents the original amount from the bank card message field, blockchain transaction data or wallet interface data; c represents the currency type obtained directly from the payment request; F represents the lookup conversion function, which converts different currency amounts to a unified standard amount according to the exchange rate table or price interface maintained by the system.

[0054] The initiator and recipient in the triple are taken as nodes, and the normalized amount is taken as the weight of the edge to generate the on-chain payment graph: all triples are then stored in an on-chain payment graph G(X, E). The set X is the account node set, obtained by removing duplicates of all x and y; the set E is the payment edge set, each edge corresponds to a triple P, and the weight of the edge is the normalized amount A * , with the metadata M.

[0055] For example, if user A transfers 500 yuan to user B through a bank card, and user B then pays 0.01 bitcoin to user C through an electronic wallet, the payment graph G(X, E) will contain the node set {A, B, C}, and two edges: A→B (weight 50000, metadata is bank card payment information) and B→C (weight 2000, metadata is digital currency payment information).

[0056] Step one obtains the on-chain payment graph G(X, E), where all payment requests have been standardized in terms of amount, format, timestamp and account identification. This payment graph serves as the input for subsequent clearing path identification and zero-knowledge verification, ensuring the uniformity and operability of multi-modal data before entering the contract logic.

[0057] Step two, calculate the commitment value for each edge in the on-chain payment graph, and generate zero-knowledge proof for each path composed of multiple edges.

[0058] This step aims to perform privacy desensitization and verifiability construction on the on-chain payment graph G(X, E) output by step one, with the goal of enabling the subsequent clearing contract to effectively verify that "this payment (or this path) exists and meets the format, amount and timing constraints" without disclosing account identification and amount details. G(X, E) already contains the account node set X, the payment edge set E, and the normalized amount A* and metadata M (containing time information and currency identification, etc.). This step generates commitments for each edge and zero-knowledge proofs for candidate clearing paths composed of multiple edges, so that the clearing contract only relies on the proofs to determine whether to trigger atomic settlement, without accessing the plaintext data.

[0059] The input is the payment graph G (X, E) output by step one. The account node set X provides the account identification domain, and the payment edge set E provides the directed payment relationship. The weight on the edge is the normalized amount A * , and the metadata M provides the necessary context such as time.

[0060] The following processing uses the full amount of X, E, A * , M: Commitment is performed on each edge in E; proof is performed on candidate paths composed of multiple edges in E and nodes from X; the proof explicitly restricts the legal range of A * and the time window of M.

[0061] Preferably, the commitment value is calculated, including:

[0062] The metadata digest is calculated based on the metadata:

[0063] For metadata M, the metadata digest is represented as τ (M), which is obtained by taking the hash of the normalized encoding of the time and currency identification in M, ensuring that the commitment is bound to a specific payment context. Through this formula, account identity, amount, and time are simultaneously bound into irreversible commitments, avoiding the leakage of plaintext.

[0064] The commitment value of the edge is calculated based on the metadata digest:

[0065] For each payment edge e = (x, y, A * , M) ∈ E, a commitment is constructed for on-chain reference without exposing the plaintext. The commitment uses a commitment function based on a collision-resistant hash to bind the blinded account pair, normalized amount, and metadata digest together, defined as follows:

[0066] C e = H (Ξ (x, y; r e ) || A * || τ (M) ) ;

[0067] Where C e is the commitment value of the edge e, used as an on-chain reference identifier; H (·) is the commitment function, implemented based on a collision-resistant hash, provided by the backend cryptographic library; Ξ (x, y; r e ) is the blind mapping of the account pair, with the input being the initiator x, the recipient y, and the random salt r e , and the output being an irreversible blinded identifier. The specific implementation is to take the hash of (x, y) and r eMultiple hashing and concatenation followed by hashing again; r e is a random salt generated by a true random number generator and corresponds to e one-to-one; A * is the normalized amount obtained in step one. Then, on the candidate clearing path level, the path C k = (e1, e2, …, e m ) generates zero-knowledge proof, the core of which is that "the path is indeed composed of edges in the graph, the nodes are continuously matched, the amount is legal, and the timing is limited." For this purpose, a path constraint expression is constructed, and it is required that this expression is always true in the proof circuit:

[0068]

[0069] wherein, is the compliance indicator of the path C k , which is forced to be 1 in the circuit; I(·) is an indicator function (implemented as a Boolean constraint in the circuit); e i ∈E ensures that the path edges come from the payment edge set in step one; is the normalized amount of edge e i , which is required to be greater than zero; is the continuity constraint, which ensures that the receiver of the previous edge is consistent with the initiator of the next edge; is the time field extracted from the metadata M; Θ is the upper bound of the clearing timing window, which is used to limit the maximum allowed time interval between two adjacent payments in the path. m represents the total number of edges.

[0070] The above constraints are implemented in the zero-knowledge circuit as range constraints, equality constraints, and timing window constraints:

[0071] (1) Range constraints make legal interval judgments on to avoid meaningless or abnormal amounts;

[0072] (2) The equality constraint realizes the continuity judgment of "receive, send" by comparing the blinded account fragments of adjacent edges, without revealing x, y plaintext;

[0073] (3) The timing window constraint compares the encoded value of t(M) and compares it with Θ, controls the upper limit of the delay in the path, and adapts to the subsequent T+0 target.

[0074] Combined with the aforementioned commitment value C e of each edge, the path proof will also reference The on-chain verifier only needs to check that the proof is valid and the commitment exists, and can be sure that the path meets the format, amount and timing conditions without touching any plaintext account or amount. For example, if there are two consecutive edges in the graph obtained in step one, "A→B→C", and the normalized amounts are 50000 and 2000 respectively, the circuit only involves commitments and blinded identifiers in the constraints: the receiving blind of the previous transaction is equal to the sending blind of the next transaction, both amounts are positive, and the time difference between the two transactions does not exceed Θ. The final output is the path-level proof element without disclosing any plaintext field.

[0075] This step obtains: (1) a set of edge commitments {C e ∣e∈E} for on-chain indexing; (2) a set of path-level zero-knowledge proofs {Z k} where each Z k corresponds to a candidate clearing path C k and binds the involved edge commitments and constraint expressions in the circuit. The proof is generated off-chain and only the validity is verified on-chain.

[0076] Step three: verify the zero-knowledge proof and perform atomic clearing on the path corresponding to the zero-knowledge proof that passes the verification. This step is based on the path-level zero-knowledge proof set {Z k} and the payment edge commitment set {C e} output in step two, and automatically triggers clearing execution through smart contract. The goal of this step is to build a "structurally verifiable + behaviorally trusted + state atomically consistent" clearing logic for multi-modal aggregated payment scenarios. In the path involving bank cards, digital currencies, electronic wallets and other channels, traditional systems cannot achieve atomic clearing in a regularized manner. This solution maps path-level security to a verifiable structure, and then uses smart contracts to make judgments and executions according to clearing rules, finally achieving atomic transfer of funds. The innovation not only uses path-level verification as the clearing trigger signal, but also dynamically weights the transaction structure in the path, giving the clearing decision a "path scheduling priority", significantly improving the efficiency of on-chain resource utilization and business response capability.

[0077] The data used includes: (1) the path-level zero-knowledge proof set {Z k} generated in step two, each element Z k represents a candidate clearing path, and the proof has been verified off-chain for structural coherence, amount legality, account continuity and time window consistency; (2) the payment edge commitment set {C e}, whose elements are irreversible hash binding structures of each payment request, the chain does not contain account or amount plaintext, and is only used as a smart contract matching index. The above two sets are the total input of clearing decision and execution, which meets the privacy protection and decentralization needs.

[0078] The platform defines a set of clearing rules before deploying the smart contract including structural requirements (such as path closed loop or strong dependency), time window limit, maximum clearable amount upper limit, and number of non-repeated accounts in the path. When actually triggered, the contract will calculate the clearing degree of each path C k corresponding to the proof Z k , and perform dynamic execution scheduling in combination with the clearing priority model.

[0079] Preferably, the zero-knowledge proof is verified, including:

[0080] The triggering metric indicators of the zero-knowledge proof corresponding to each path are calculated respectively:

[0081] In order to improve the use efficiency of on-chain computing resources under multi-channel path, the present application proposes an innovative clearing triggering degree model T k The function not only judges whether the path meets the contract triggering condition, but also evaluates the structural tightness, amount activity and scheduling weight of the path in the current global clearing pool. The specific definition is as follows:

[0082]

[0083] Wherein, T k represents the triggering metric indicators of path C k ; Γ(Z k ) represents the verification function of path-level proof Z k , which takes the value of 1 if the verification is passed, otherwise 0, which controls the path legality; Δ k represents the time interval between the largest adjacent transactions in the path, which is extracted from the time field in M, representing the time compactness of the path; Θ is the maximum allowed clearing delay window set by the system, which is used to normalize the time compactness; Φ k represents the activity factor of path C k , which is estimated by the frequency of all accounts corresponding to the edges in the path appearing in the entire payment network in the past 24 hours; η is the scheduling factor, which weighs the priority weight between structural compactness and account activity, usually set to 0.3 to 0.5.

[0084] The calculation method of Φ k does not depend on the modeling of off-chain behavior, but counts the number of account activities through on-chain transaction index cache, which completes dynamic scoring without violating privacy. For example: if path C kThe path includes edges e1=(x1, y1) and e2=(x2, y2), and the activity of the path is obtained by dividing the sum of the frequencies of occurrence of x1, y1, x2, and y2 in the near n settled paths by n. Through this mechanism, the system preferentially processes high-activity and short-time aggregation paths, and considers efficiency and economy.

[0085] The judgment trigger metric is greater than the set threshold value, if yes, it means that the zero-knowledge proof passes the verification:

[0086] The judgment T k is greater than the set threshold value τ min , if yes, it means that the zero-knowledge proof passes the verification.

[0087] After verifying that T k is greater than the threshold value τ min , the contract performs atomic settlement of the path.

[0088] The execution process includes: (1) locking the fund state of all accounts associated with the edges in the path to prevent concurrent operations; (2) traversing the edge set , performing amount transfer for each payment instruction; (3) uniformly submitting after all the transfers are successful; (4) if any edge fails, triggering the full-path rollback to restore the original state.

[0089] This design ensures the atomicity, indivisibility and on-chain state consistency of the settlement operation.

[0090] For example, if the path C k includes three payments (A→B→C), the amounts are 50000, 40000, and 2000 (normalized), the time intervals are 2 minutes and 1 minute, the account activity Φ k = 0.6, the system sets Θ = 10 minutes and η = 0.4, and Z k passes the verification, the settlement trigger is:

[0091]

[0092] If τ min = 0.9, the path C k can be triggered for settlement. The path will be preferentially put into the scheduling queue for atomic execution.

[0093] This step obtains: (1) settlement success path execution record R k , recording the hash identifier, normalized total amount, and settlement time of each completed settlement path; (2) payment edge index set {e i} for connecting with the step four state synchronization module, driving the ledger update and the oracle linkage. All output data are index type information, not containing user plaintext identification and plaintext amount, ensuring privacy protection.

[0094] Step four, calculating the synchronization priority index of the path executed by the atomic clearing, and pushing the path to the ledger synchronization module based on the synchronization priority index.

[0095] This step is the last link of the whole patent process, which connects the clearing record R k and the payment edge index set {e i} The core purpose is to solve the actual landing difficulty of "how the operation result of the on-chain contract is perceived and accepted by the real bank system and the multi-source ledger". Traditional block chain clearing system often only focuses on the completion state in the chain, but in the multi-modal aggregated payment scene focused on by this patent, clearing involves multiple heterogeneous financial systems (such as bank general ledger system, digital currency ledger, third-party wallet platform, etc.), which requires that the on-chain operation can be equivalently identified off-chain, so as to realize T+0 clearing synchronization. At the same time, as a trusted automatic clearing mechanism, it must also prevent unauthorized devices or nodes from forging clearing operations, so a FIDO hardware key binding mechanism is introduced in the permission control layer to realize the binding of the physical device identity of the calling party, ensuring that "on-chain operation = authorized terminal behavior", forming a system-level security closed loop. This step directly connects the block chain and the core ledger of the financial institution, and is the final embodiment of the "atomic, secure, and synchronous" characteristics of this patent.

[0096] This step strictly connects the data obtained in step three, which are: (1) clearing path execution record R k , which contains path identifier, whether the execution is successful, clearing time t k , path normalized amount W k , account hash information {χ i}; (2) edge index set {e i} of completed clearing, which is used to extract channel type, currency category, and account ownership relationship from the original payment graph, to assist in determining the clearing impact range and off-chain mapping path. These two inputs will be used for oracle synchronization scheduling judgment and contract execution authorization binding.

[0097] Preferably, the synchronization priority index of the path executed by the atomic clearing is calculated, including:

[0098] In order to realize the timely response of the off-chain clearing system to the on-chain state, this step introduces a synchronization scheduling mechanism, which needs to evaluate the balance between the "synchronization cost" of the off-chain system and the "urgency of the on-chain path". For this purpose, an improved synchronization priority index S k is defined, and the specific calculation method is as follows:

[0099]

[0100] wherein S k represents the synchronization priority of path C k , which is a floating point number between 0 and +∞, used to sort multiple paths to be synchronized; W k is the total normalized amount of path C k , indicating the importance of clearing; Ω k is the "contract response urgency" of the path, defined as:

[0101]

[0102] wherein T d is the system ledger reconciliation deadline, t k is the actual clearing completion time of the path; Θ is the clearing response time limit constant. This term is designed as a decreasing exponential function, when the clearing time t k approaches the reconciliation deadline T d , Ω k → 1, indicating the urgency of response; if the distance is far, Ω k decays, reducing the priority.

[0103] Returning to the denominator part of S k , ρ k represents the number of off-chain systems involved in path C k (such as banks, wallets, and digital currency multi-channel for 3), used to measure the synchronization cost of the path; γ k represents the ledger consistency risk factor of path C k , which is derived from the cross-system duplication of accounts involved in the edge set {e i}. For example, if multiple accounts appear repeatedly in different ledgers, it may cause consistency synchronization conflicts and higher risks; λ and μ are cost adjustment coefficients, and the set values are optimized according to historical synchronization performance data. This design not only considers the time urgency, but also considers the cross-system synchronization complexity, truly reflecting the actuality of scheduling in the multi-modal clearing scenario.

[0104] Preferably, the paths are pushed to the ledger synchronization module based on the synchronization priority index, including:

[0105] The synchronization priority index is sorted, and the first N paths {C k ′} with the largest synchronization priority index are pushed to the ledger synchronization module.

[0106] N is a set value.

[0107] Each C k ′ is mapped to a structured synchronization event, which contains account identification hash {χ i}、normalized amount W k 、clearing completion time t k and path ID.

[0108] The bank account receiving end listens to the event through an open interface, parses and writes into the clearing pool of the account system; for the digital currency platform, it generates equivalent asset custody transfer instructions; for the electronic wallet system, it triggers the balance adjustment function of the account layer. Preferably, all off-chain receiving systems return a response hash and timestamp after successful synchronization as the basis for on-chain state updates. In terms of contract authority control, to prevent malicious terminals or intermediaries from triggering clearing operations of high-priority paths, a device binding mechanism based on the FIDO2 protocol is introduced. Each contract trigger instruction must be accompanied by a signature Σ tx containing path ID, timestamp, contract version number, operation action summary, etc. The contract embeds a hardware public key κ pub , and verifies the following relationship:

[0109] V(Σ tx ,κ pub )=1;

[0110] This mechanism ensures that each clearing synchronization action comes from an operator holding a legal device, and the system performs identity verification through the TPM module or USB binding device, rejecting all unauthorized node calls, thereby fundamentally eliminating key leakage and identity impersonation. Please refer to Figure 2 The application also provides a multi-modal aggregated payment security clearing system based on a blockchain smart contract, comprising a graph generation module, a proof generation module, a clearing execution module, and a synchronization module.

[0111] The graph generation module is used to obtain transaction data and generate an on-chain payment graph based on the transaction data.

[0112] The proof generation module is used to calculate a commitment value for each edge in the on-chain payment graph and generate a zero-knowledge proof for each path composed of multiple edges.

[0113] The clearing execution module is used to verify the zero-knowledge proof and perform atomic clearing on the paths corresponding to the verified zero-knowledge proofs.

[0114] The synchronization module is used to calculate a synchronization priority index of the paths that have undergone atomic clearing and push the paths to the account synchronization module based on the synchronization priority index.

[0115] The above embodiments are only for illustrating the technical concept and characteristics of the application, and the purpose is to enable those skilled in the art to understand the content of the application and implement it, and cannot limit the protection scope of the application. Any equivalent changes or modifications made in accordance with the spirit and essence of the application should be covered within the protection scope of the application.

Claims

1. A secure clearing method for multimodal aggregated payment based on blockchain smart contracts, characterized in that: include: Step 1: Obtain transaction data and generate an on-chain payment graph based on the transaction data; Step two: Calculate the commitment value for each edge in the on-chain payment graph, and generate a zero-knowledge proof for each path consisting of multiple edges; Step 3: Verify the zero-knowledge proof and perform atomic liquidation on the path corresponding to the verified zero-knowledge proof. Step 4: Calculate the synchronization priority index of the path executed by atomic liquidation, and push the path to the ledger synchronization module based on the synchronization priority index.

2. The multimodal aggregated payment secure clearing method based on blockchain smart contracts according to claim 1, characterized in that, Obtain transaction data, including: Transaction data is obtained through an aggregation gateway.

3. The multimodal aggregated payment secure clearing method based on blockchain smart contracts according to claim 2, characterized in that, Transaction data includes messages, transaction information, and merchant order data.

4. The multimodal aggregated payment secure clearing method based on blockchain smart contracts according to claim 3, characterized in that, The aggregation gateway includes a bank card payment collection module, a digital currency collection module, and an e-wallet payment collection module; The bank card payment acquisition module is used to receive messages through a communication channel with the bank clearing center; The digital currency acquisition module is used to obtain transaction information through a data channel established with blockchain nodes; The e-wallet data acquisition module is used to obtain merchant order data through the application interface.

5. The multimodal aggregated payment secure clearing method based on blockchain smart contracts according to claim 4, characterized in that, Generate an on-chain payment graph based on transaction data, including: Retrieve the initiator, recipient, and metadata from the transaction data; Generate triples based on the initiator, receiver, and metadata; The transaction amounts contained in the metadata are normalized to obtain normalized amounts; By treating the initiator and receiver in the triple as nodes and the normalized amount as the edge weight, an on-chain payment graph is generated.

6. The multimodal aggregated payment secure clearing method based on blockchain smart contracts according to claim 1, characterized in that, Calculating the commitment value includes: Calculate metadata digests based on metadata; The commitment value of an edge is calculated based on the metadata digest.

7. The multimodal aggregated payment secure clearing method based on blockchain smart contracts according to claim 1, characterized in that, Verification of zero-knowledge proofs includes: Calculate the trigger metric for zero-knowledge proof for each path; Determine if the trigger metric is greater than the set threshold; if so, the zero-knowledge proof has passed verification.

8. The multimodal aggregated payment secure clearing method based on blockchain smart contracts according to claim 1, characterized in that, The path is pushed to the ledger synchronization module based on the synchronization priority index, including: The synchronization priority indicators are sorted, and the top N paths with the highest synchronization priority indicators are pushed to the ledger synchronization module.

9. The multimodal aggregated payment secure clearing method based on blockchain smart contracts according to claim 1, characterized in that, After successful synchronization, all off-chain receiving systems return a response hash and timestamp, which serve as the basis for updating the on-chain state.

10. A multimodal aggregated payment and secure clearing system based on blockchain smart contracts, characterized in that: It includes a graph generation module, a proof generation module, a liquidation execution module, and a synchronization module; The graph generation module is used to acquire transaction data and generate an on-chain payment graph based on the transaction data. The proof generation module is used to calculate the commitment value for each edge in the on-chain payment graph and generate zero-knowledge proofs for each path consisting of multiple edges. The liquidation execution module is used to verify zero-knowledge proofs and perform atomic liquidation execution on the paths corresponding to the verified zero-knowledge proofs. The synchronization module is used to calculate the synchronization priority index of the path executed by atomic liquidation, and push the path to the ledger synchronization module based on the synchronization priority index.

Images