Block chain fragmentation-dynamic aggregation multi-node cross-border payment settlement method

Abstract

The invention relates to the technical field of block chain fragmentation, in particular to a block chain fragmentation-dynamic aggregation multi-node cross-border payment settlement method. The method comprises the following steps: receiving a cross-border transaction request of a user, and carrying out legality verification and encryption packaging on transaction elements in the cross-border transaction request to generate transaction data; fragmenting the transaction data by using consistent hash, and distributing the fragmented transaction data to different block chain sub-network nodes; each block chain sub-network node executes an intelligent contract rule on the received fragmented transaction data, updates a local account book on a fragment chain and generates a block, and forms a fragment account book state at the same time; and uploading the fragmented account book state to an aggregation layer through a cross-fragmented communication protocol to generate an aggregated global transaction record. According to the method, a dynamic entropy weight Hash ring mechanism based on a business heat entropy value and a node dynamic capacity weight is introduced on the basis of traditional consistent Hash.

Description

Technical Field

[0001] This invention relates to the field of blockchain sharding technology, and more specifically, to a multi-node cross-border payment clearing method based on blockchain sharding and dynamic aggregation. Background Technology

[0002] Traditional cross-border payment and clearing systems primarily rely on centralized financial networks like SWIFT, with funds transferred through multiple intermediary banks or clearing institutions. This model suffers from cumbersome processes, long processing times (typically several hours to days), high fees, insufficient transparency, and complex reconciliation. Furthermore, its highly centralized architecture is prone to single points of failure and systemic risks, failing to meet the urgent demands of the global digital economy for efficient, low-cost, and real-time clearing. To address these issues, blockchain technology, with its decentralized, immutable, transparent, and traceable characteristics, is considered a crucial technological path for reconstructing the cross-border payment system. However, traditional blockchain systems are limited by consensus mechanism performance, generally exhibiting bottlenecks such as low transaction throughput (insufficient TPS), high confirmation latency, and poor scalability, making it difficult to support high-frequency, large-scale cross-border payment scenarios. While sharding technology improves system concurrency by dividing the network into multiple parallel-processing subchains, existing sharding schemes mostly employ static hash mapping, lacking the ability to perceive spatiotemporal dynamic characteristics such as transaction volume, geographical distribution, and currency flows. This leads to concentrated hot transactions causing local node overload and prominent load imbalance issues. Meanwhile, maintaining state synchronization and global consistency across sharded transactions still faces challenges such as high communication overhead, high latency, and weak fault tolerance. Especially in intercontinental, multi-path wide-area network environments, data transmission is susceptible to high latency and high packet loss rates. Traditional TCP protocols may also cause head-of-line blocking, further reducing system reliability and real-time performance. Therefore, this paper proposes a blockchain sharding-dynamic aggregation multi-node cross-border payment clearing method. Summary of the Invention

[0003] The purpose of this invention is to provide a multi-node cross-border payment and settlement method based on blockchain sharding and dynamic aggregation, in order to solve the problems of low efficiency, unbalanced load, high cross-shard communication latency, and poor reliability in traditional cross-border payment and settlement systems and existing blockchain sharding technologies mentioned in the background.

[0004] To achieve the above objectives, the present invention aims to provide a multi-node cross-border payment clearing method based on blockchain sharding and dynamic aggregation, comprising the following steps: S1. Receive the user's cross-border transaction request and perform legality verification and encryption encapsulation on the transaction elements in the cross-border transaction request to generate transaction data; S2. Use consistent hashing to shard the transaction data and distribute the sharded transaction data to different blockchain subnet nodes; In the sharding process, a time-space-aware dynamic entropy weight hash ring is introduced to map the sharding key of the transaction request to the dynamic entropy weight hash ring to generate the hash value of the transaction data. S3. Each blockchain subnet node executes the smart contract rules on the received sharded transaction data, updates the local ledger on the sharded chain and generates blocks, thus forming the sharded ledger state. S4. Upload the sharded ledger status to the aggregation layer through the cross-sharding communication protocol to generate the aggregated global transaction record; S5. Write the aggregated global transaction records into the main chain global ledger to generate an immutable payment and settlement certificate, and generate a settlement result summary based on the aggregated global transaction records.

[0005] As a further improvement to this technical solution, in S1, the specific steps involved in generating transaction data are as follows: receiving cross-border transaction requests submitted by users, verifying the integrity and format of the transaction elements in the transaction request; verifying user identity and permissions; encapsulating the verified transaction elements into a unified transaction data structure, generating a globally unique transaction ID and an initial state field, encrypting and digitally signing the transaction data, and generating the final transaction data. The transaction elements of a transaction request must include at least the payer, payee, amount, currency, and timestamp.

[0006] As a further improvement to this technical solution, in step S2, consistent hashing is used to shard the transaction data, and the sharded transaction data is distributed to different blockchain subnet nodes, including the following steps: S2.1 Select sharding keys based on the region, currency, and clearing path of transaction data; S2.2 Based on the spatiotemporally aware dynamic entropy weighted hash ring, the sharding key is mapped to the hash ring to generate the hash value of the transaction data; S2.3 Determine the target virtual node and its corresponding physical subnet node based on the hash value; S2.4 Combine the transaction data with the hash value, fragmentation key and actual subnet node information to form fragmented data packets. The fragmented data packets shall include at least the transaction ID, transaction elements, encrypted information, digital signature and fragmentation identifier. S2.5. Send the fragmented data packets to the target blockchain subnet node via a peer-to-peer network.

[0007] As a further improvement to this technical solution, in step S2.2, based on a spatiotemporally aware dynamic entropy weighted hash ring, the sharding key is mapped onto the hash ring to generate the hash value of the transaction data, including the following steps: S2.21. Continuously collect historical transaction data and calculate the business heat entropy value using the shard key dimension combination as the unit; S2.22. Monitor the dynamic available capacity of each physical subnet node in real time and calculate the dynamic capacity weight of the physical subnet node. S2.23. Combining the business heat entropy value and the node dynamic capacity weight, the distribution of virtual nodes on the hash ring is dynamically adjusted to construct a dynamic entropy weight hash ring.

[0008] As a further improvement to this technical solution, in S2.3, the specific steps involved in determining the target virtual node and its corresponding physical subnet node are as follows: calculating the hash value using a hash function based on the sharding key corresponding to the transaction, locating the hash value to the dynamic entropy weight hash ring, searching for the first virtual node clockwise on the dynamic entropy weight hash ring, and mapping the virtual node to the corresponding physical subnet node.

[0009] As a further improvement to this technical solution, in step S3, local ledger updates and block generation are performed on the sharded chain, simultaneously forming a sharded ledger state, including the following steps: S3.1 Receive fragmented data packets based on a point-to-point network and perform integrity verification on the fragmented data packets, including at least verifying the correctness of the transaction ID, digital signature, and fragment identifier; S3.2 Verify the identities of the payer and payee in the transaction data; S3.3, Query the balance of the payer's account on the shard chain; S3.4 Conduct compliance review based on transaction currency, amount, and cross-border rules; S3.5 Write transactions that have passed verification, balance and compliance review to the local shard ledger, update account status and generate new blocks; S3.6 Summarize the latest ledger status on the current shard chain and generate the shard ledger status, which includes at least the transaction block height, account status, and transaction index.

[0010] As a further improvement to this technical solution, in step S4, the fragmented ledger status is uploaded to the aggregation layer to generate aggregated global transaction records via a cross-shard communication protocol, including the following steps: S4.1 Organize the local sharded ledger state into a standard data structure. The standard data structure shall include at least a transaction digest, a block hash, an account state digest, a block height, and a shard identifier, and digitally sign the sharded ledger state. S4.2, The asynchronous streaming state transfer protocol based on network coding uploads the digitally signed fragmented ledger state to the aggregation layer; S4.3 Utilize the aggregation layer node to receive the fragmented ledger status from different physical subnet nodes, perform integrity verification and digital signature verification on each fragmented status, and perform consistency verification on the received fragmented ledger status. S4.4 Merge the ledger states of each shard after consistency verification according to the rules to generate an aggregated global transaction record. The global transaction record shall include at least the following: transaction ID, payer, payee, amount, currency, timestamp, transaction status, block height and corresponding shard information.

[0011] As a further improvement to this technical solution, in step S4.2, the asynchronous streaming state transmission protocol based on network coding uploads the digitally signed fragmented ledger state to the aggregation layer, including the following steps: S4.21. Divide the digitally signed fragmented ledger state into n data blocks, encode the data blocks using random linear network coding, generate an encoding packet, and generate a parallel lightweight verification information stream for the encoding packet of each batch of fragmented ledger states. S4.22. Establish a multi-path asynchronous data stream and dynamically adjust the sending rate of each path based on real-time monitored network latency and packet loss rate; S4.23. The received encoded packets are received and decoded using the aggregation layer node. The original state data is recovered using Gaussian elimination. The existence of missing linear independent encoded packets is determined by monitoring the rank of the decoding matrix. Lightweight verification information flow verification is then performed.

[0012] As a further improvement to this technical solution, in S4.21, a parallel lightweight verification information stream is generated for each batch of sharded ledger state coded packets. The specific steps involved are: calculating the content hash value, timestamp, and transmission path identifier of each coded packet to form a hash commitment vector, binding the hash commitment vector with the corresponding coded packet identifier to form a lightweight verification information stream, and writing it to the blockchain evidence storage layer in real time through a predefined sidechain channel to generate an immutable on-chain record.

[0013] As a further improvement to this technical solution, in step S5, an immutable payment clearing voucher is generated, and a clearing result summary is generated based on the aggregated global transaction records, including the following steps: S5.1. Perform structuring and encapsulation processing on the global transaction records generated by the aggregation layer; S5.2. Call the underlying consensus mechanism to perform consensus verification on the structured and encapsulated global transaction records, generate consensus signature information, and write the structured and encapsulated global transaction records into the main chain global ledger. S5.3 Generate a payment clearing certificate based on the hash root value, timestamp, and consensus signature information of the global transaction record, and store the payment clearing certificate on the blockchain for evidence. S5.4 Generate a settlement result summary based on the core fields of the global transaction record. The core fields include at least the transaction amount, fund flow, settlement time window, and status label. The settlement result summary includes at least the transaction amount, fund flow, settlement time window, and status label.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention relates to a blockchain sharding-dynamic aggregation multi-node cross-border payment clearing method. Based on traditional consistent hashing, it introduces a dynamic entropy-weighted hash ring mechanism based on business popularity entropy values ​​and node dynamic capacity weights. This mechanism can perceive the distribution characteristics of transaction requests in time and space dimensions (such as popularity fluctuations based on region, currency, and path combination) in real time. Combined with the actual load capacity of each subnet node (CPU, TPS, bandwidth, etc.), it dynamically adjusts the distribution of virtual nodes, making the hash value distribution of high-volume transactions more dispersed and avoiding overload of single nodes. Compared to static hashing or ordinary consistent hashing, this mechanism effectively alleviates local congestion problems in cross-border payments caused by regional time differences, holiday peaks, and surges in specific currency transactions. It achieves fine-grained, adaptive load balancing, significantly improving the overall throughput of the system and the low latency of transaction processing (block time ≤ 5 seconds), ensuring the efficiency and stability of cross-border payment clearing.

[0015] 2. This invention relates to a blockchain sharding-dynamic aggregation multi-node cross-border payment and settlement method. Based on a multi-path asynchronous transmission protocol using Random Linear Network Coding (RLNC), the sharded ledger state is split into coded packets and transmitted in parallel via multiple paths such as submarine optical cables and satellite links. Combined with lightweight verification information streams and sidechain notarization, fault tolerance recovery and authenticity verification during transmission are achieved. The aggregation layer supports "receiving and decoding simultaneously," using Gaussian elimination to reconstruct the original data in real time and monitoring integrity through the rank of the decoding matrix, significantly reducing the waiting latency of cross-shard communication. Furthermore, the aggregation layer performs digital signature verification, conflict detection, and consistency checks on each shard state, merging them by block height and transaction ID to generate a unique and continuous global transaction record. This mechanism not only improves the reliability and anti-interference capability of state synchronization in a wide area network environment but also ensures data consistency before main chain writing, thereby achieving fast, secure, and traceable global ledger aggregation in high-concurrency cross-border scenarios, laying a solid foundation for generating tamper-proof payment and settlement vouchers. Attached Figure Description

[0016] Figure 1 This is a flowchart of the overall method of the present invention. Detailed Implementation

[0017] 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 of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0018] Example: Please refer to Figure 1 As shown, this embodiment provides a multi-node cross-border payment clearing method based on blockchain sharding and dynamic aggregation, including the following steps: S1. Receive the user's cross-border transaction request and perform legality verification and encryption encapsulation on the transaction elements in the cross-border transaction request to generate transaction data; In this embodiment, the specific steps involved in generating transaction data are as follows: receiving cross-border transaction requests submitted by users; verifying the completeness and format of the transaction elements in the transaction request to ensure that the amount is positive and meets the currency precision requirements, the timestamp is valid, and the account ID format is correct; and verifying user identity and permissions, including digital certificate or public / private key authentication and cross-border payment permission checks, while conducting preliminary compliance reviews, such as single transaction limits, anti-money laundering checks, and sanctions list checks; encapsulating the verified transaction elements into a unified transaction data structure, generating a globally unique transaction ID and an initial state field, encrypting and digitally signing the transaction data to ensure the security and immutability of data transmission, and generating the final transaction data containing encrypted transaction data, signature, and metadata; The transaction elements of a transaction request must include at least the payer, payee, amount, currency, and timestamp.

[0019] S2. Use consistent hashing to shard the transaction data and distribute the sharded transaction data to different blockchain subnet nodes; In the sharding process, a time-space-aware dynamic entropy weight hash ring is introduced to map the sharding key of the transaction request to the dynamic entropy weight hash ring to generate the hash value of the transaction data. In this embodiment, consistent hashing is used to shard transaction data, and the sharded transaction data is distributed to different blockchain subnet nodes, including the following steps: S2.1. Select sharding keys based on the region, currency, and clearing path of transaction data. The sharding keys are used for consistent hash calculation to ensure that similar transactions are assigned to the same subnet node, thereby improving local consistency and data locality. S2.2 Based on the spatiotemporal-aware dynamic entropy weight hash ring, the sharding key is mapped to the hash ring to generate the hash value of the transaction data (by mapping the sharding key to the dynamic entropy weight hash ring, the shards of the transaction data are distributed on the hash ring, realizing the balanced distribution of transactions in the spatial and temporal dimensions, thereby avoiding overload of a single subnet node, improving the load balance of sharding processing and system throughput, while ensuring that the hash value distribution of hot services is more dispersed, reducing the risk of transaction congestion and delay). Traditional sharding methods cannot effectively handle node overload caused by high-frequency transactions (such as high-frequency transactions in specific regions or currencies), leading to decreased system throughput, increased transaction latency, and congestion risks. By introducing a spatiotemporally aware dynamic entropy-weighted hash ring, this method can analyze the heat entropy value of transaction transactions and node processing capabilities in real time, dynamically adjusting the virtual node distribution of the hash ring to ensure a balanced spatial and temporal distribution of transaction data during sharding. This avoids bottlenecks from single nodes and improves overall system performance. The advantage of the dynamic entropy-weighted hash ring lies in its spatiotemporal awareness and dynamic entropy adjustment mechanism, enabling it to respond in real time to changes in business load and node status. Functionally, it automatically optimizes the virtual node layout of the hash ring by calculating the business heat entropy value (combining transaction frequency, amount, complexity, etc.) and dynamic node capacity weights, making the hash value distribution of high-frequency transactions more dispersed, thereby significantly improving the load balance and system throughput of the sharding layer. This not only reduces transaction congestion and latency risks but also enhances the system's adaptability to dynamic business scenarios, avoiding node overload or resource waste caused by fixed hash mapping in existing technologies, and providing a more efficient and reliable clearing foundation for cross-border payments. Based on a spatiotemporally aware dynamic entropy-weighted hash ring, the sharding key is mapped onto the hash ring to generate the hash value of the transaction data, including the following steps: S2.21. Continuously collect historical transaction data and calculate the business heat entropy value in units of shard key dimension combination. The entropy value takes into account transaction frequency, transaction amount, complexity and time pattern, and reflects the load uncertainty and hot spot risk of the business dimension combination. The specific process for calculating the business popularity entropy value is as follows: Collect historical transaction datasets , , , Each transaction includes: transaction ID, transaction amount, transaction currency, transaction region, settlement path, and timestamp; transactions are grouped according to the shard key dimension, for example... Each combination constitutes a business dimension unit. For each business dimension unit Calculate the following indicators: trading frequency (Number of transactions per unit time), transaction amount characteristics (Total or average transaction amount per unit time), transaction complexity ( Path complexity Currency complexity, where, This represents the weighting coefficient for path complexity. This refers to the weighting coefficient for currency complexity. Path complexity is categorized based on the number of intermediary banks or cross-border regions involved in the payment path. For example, a direct path has a complexity of 1, involving 1-2 intermediary banks has a complexity of 2, and involving 3 or more intermediary banks has a complexity of 3. Currency complexity is also categorized by currency type: mainstream currencies (such as USD and EUR) have a complexity of 1, emerging market currencies have a complexity of 2, and rare currencies have a complexity of 3. and The value range of is [0,1], satisfying Based on business priority settings, if path complexity has a greater impact on system load (e.g., longer paths result in higher processing latency), then... Take the larger value; if currency complexity has a greater impact (such as currency conversion time), then... Take the larger value), time pattern features (The uniformity or peak intensity of the distribution of transactions over a day or week, represented by a probability distribution); regarding transaction frequency Transaction amount characteristics Transaction complexity Time pattern characteristics Construct a normalized probability distribution to ensure the sum is 1; calculate the entropy value of each indicator using the information entropy formula (a higher entropy value indicates greater uncertainty for that indicator, i.e., greater load and risk volatility): ; ; ; ; In the formula, Transaction frequency entropy measures the uncertainty of the distribution of transaction frequencies. Transaction amount entropy measures the uncertainty of the distribution of transaction amounts. Transaction complexity entropy measures the uncertainty of the distribution of complexity (path, currency, etc.). Time pattern entropy measures the uncertainty of the distribution of trading time (such as peak / trough volatility). These are the units (intervals or state numbers) that divide the probability distribution, used to characterize uncertainty in a certain dimension. To determine the probability distribution of transaction frequency, the number of transactions per unit time (e.g., per hour) is divided into three intervals. The interval boundaries are determined based on the percentiles of historical data (e.g., low-frequency interval: 0-25% percentile, mid-frequency interval: 25%-75% percentile, high-frequency interval: 75%-100% percentile). Specifically, if the minimum number of historical transactions is 0 and the maximum is 100, then the low-frequency interval is [0, 25], the mid-frequency interval is (25, 75], and the high-frequency interval is (75, 100]. To determine the probability distribution of transaction amounts, transaction amounts (e.g., USD equivalent) are divided into intervals, such as small amounts (0-1,000 USD), medium amounts (1,000-10,000 USD), and large amounts (10,000+ USD). The interval boundaries can be adjusted according to business needs. The probability distribution of transaction complexity is normalized to the range [0,1] and then divided into low complexity (0-0.3), medium complexity (0.3-0.7), and high complexity (0.7-1.0). To determine the probability distribution of trading time patterns, a day is divided into multiple time periods (e.g., 00:00-06:00 is the early morning, 06:00-12:00 is the morning, 12:00-18:00 is the afternoon, and 18:00-24:00 is the evening). The final business popularity entropy value is obtained by weighted summation of the entropy values ​​of each indicator. ; S2.22. Monitor the dynamic available capacity of each physical subnet node in real time, calculate the dynamic capacity weight of the physical subnet node, and reflect the actual processing capacity of the node at the current moment. The constraints are: CPU utilization ≤70% and TPS ≥500. Specifically: First, determine if the node meets the constraints (CPU utilization ≤ 70%, TPS ≥ 500). If not, multiply its dynamic capacity weight by a decay factor (the decay factor is calculated based on the degree of non-compliance: for CPU utilization: if CPU utilization > 70%, then decay factor 1 = 1 - (CPU utilization - 70%) / 30%; for example, if CPU utilization is 80%, then decay factor 1 = 1 - (80 - 70) / 30 ≈ 0.667; for TPS: if TPS < 500, then decay factor 2 = TPS / 500; for example, if TPS is 400, then decay factor 2 = 0.8. The final decay factor is the minimum of decay factor 1 and decay factor 2, i.e., decay factor = min(decay factor 1, decay factor 2). If the node meets both conditions, the decay factor = 1), reducing its probability of being selected; if it meets the conditions, calculate the capacity weight based on its remaining available resources. ; In the formula, The dynamic capacity weights of the physical subnet nodes. This represents the current CPU utilization rate (%) of the node. This represents the node's current transaction processing capacity (TPS). Theoretically maximum transaction processing capacity, This represents the node's currently available network bandwidth. The maximum theoretical bandwidth of the node. This is a weighting factor for CPU utilization. This is a weighting coefficient for transaction processing capacity. This is a weighting factor for network bandwidth. , , The value range of is [0,1], satisfying Values ​​are determined based on experience; S2.23. Combining the business popularity entropy value and the node dynamic capacity weight, the distribution of virtual nodes on the hash ring is dynamically adjusted to construct a dynamic entropy weight hash ring. By increasing the number of virtual nodes or adjusting the position of virtual nodes, the hash value distribution of hot business keys is made more dispersed. Specifically, the combination of business popularity entropy value and node dynamic capacity weight is as follows: ; In the formula, For business dimension units The dynamic entropy weight adjustment coefficient, To be assigned to business dimension units The capacity weight of the target node; The specific dynamic adjustment logic is as follows: like The larger the value, the more likely the business unit is a high-demand business with limited allocated node capacity, requiring the load to be distributed by increasing the number of virtual nodes or adjusting their locations; conversely, if the node capacity is large, even with high business activity, the adjustment coefficient is relatively small, indicating that the node can handle more transactions and there is no need for excessive distribution. S2.3. Determine the target virtual node and its corresponding physical subnet node based on the hash value (in order to determine the specific processing location of transaction data in the sharding layer, that is, to allocate each transaction to the appropriate subnet node, so as to achieve a balanced distribution of transaction requests in the entire blockchain network, avoid node overload, and ensure that transactions can be correctly routed to the corresponding node for local ledger updates and smart contract execution). The specific steps involved are as follows: When a new transaction arrives, a hash value is first calculated using a hash function based on the sharding key corresponding to the transaction (specifically, the sharding key corresponding to the transaction (e.g., a combination of region, currency, and clearing path) is serialized into a string or byte sequence in a unified format, and then the sequence is input into a predefined hash function (SHA-256). The hash function performs irreversible mathematical mapping operations on the input data to generate a fixed-length hash value). The hash value is located on a dynamic entropy weight hash ring. The first virtual node is found clockwise on the dynamic entropy weight hash ring, and the virtual node is mapped to the corresponding physical subnet node. This physical subnet node is determined as the target node for the transaction data, and the transaction data is allocated to the target node for processing, thereby ensuring a balanced distribution of transaction requests in both spatial and temporal dimensions. S2.4. Combine the transaction data with the hash value, sharding key, and actual subnet node information into a sharded data packet (specifically: structurally encapsulate the generated transaction data with the corresponding sharding key, the hash value calculated through consistent hashing or dynamic entropy weight hash ring, and the determined target physical subnet node information to form a sharded data packet containing transaction ID, transaction elements, encrypted information, digital signature, and sharding identifier). The sharded data packet includes at least the transaction ID, transaction elements, encrypted information, digital signature, and sharding identifier, and is used for subsequent subnet node processing and ledger updates. S2.5. Send the fragmented data packet to the target blockchain subnet node through a peer-to-peer (P2P) network. After sending, confirm to ensure that the fragment is successfully delivered to the node; if it fails, retry or route to the next clockwise virtual node.

[0020] S3. Each blockchain subnet node executes smart contract rules (including identity verification, fund balance verification, and compliance review) on the received sharded transaction data, updates the local ledger on the sharded chain, generates blocks, and forms the sharded ledger state. In this embodiment, local ledger updates and block generation are performed on the sharded chain, simultaneously establishing a sharded ledger state, including the following steps: S3.1 Receive fragmented data packets via a peer-to-peer (P2P) network and perform integrity verification on the fragmented data packets, including verifying the correctness of the transaction ID, digital signature, and fragment identifier. Specifically, when a fragmented data packet arrives at a subnet node, key fields such as the transaction ID, fragment identifier, and digital signature are extracted and the data packet is verified. The system uses a public key or pre-shared key to verify the digital signature, ensuring that the transaction data has not been tampered with, and simultaneously checks the correctness and consistency of the fragment identifier and transaction ID. If the verification passes, the data packet is confirmed to be complete and valid, and can proceed to the next step; if the verification fails, the transaction is rejected and an error message is returned, ensuring that the sharded chain ledger only accepts complete and trusted data. S3.2 Verify the identities of the payer and payee in the transaction data. Specifically, first, extract the account information of the payer and payee in the transaction. Then, verify the validity and legality of the account by accessing the account registration information, digital certificate, public-private key pair or third-party identity authentication service. This includes confirming whether the account exists, whether it has cross-border payment authority, and whether it is on the compliance blacklist or sanctions list. Only when the identity verification is passed will the system allow the transaction to continue. Otherwise, the transaction will be rejected and the abnormal status will be recorded to ensure the authenticity and legality of the identities of both parties in the transaction. S3.3. Query the payer's account balance or available credit on the sharded chain, and calculate based on the transaction amount and possible transaction fees to determine whether the account has the ability to pay. If the balance is insufficient, reject the transaction and return an abnormal status; if the balance is sufficient, proceed to the next step, namely: check whether the payer's account balance is ≥ transaction amount + transaction fee (transaction fee not less than 0.1%). If it is insufficient, reject the transaction. S3.4. Conduct compliance review based on the transaction currency, amount, and cross-border rules, including anti-money laundering, sanctions list, and counter-terrorism financing checks. If the check is passed, proceed to the next step; otherwise, reject the transaction and record the review results. Single transaction ≤ 50,000 USD, daily cumulative ≤ 1,000,000 USD. If a risk is triggered, proceed to KYC enhanced review, with a delay of no more than 2 seconds. S3.5 Write transactions that have passed verification, balance and compliance review to the local shard ledger, update the account status and generate a new block. The block time is ≤5 seconds, the block size is ≤2MB, and each block contains ≥200 transactions. S3.6 Summarize the latest ledger status on the current shard chain and generate a shard ledger status that can be used for cross-shard aggregation, including at least the transaction block height, account status, and transaction index (which may include summary information, Merkle root, block hash, etc.).

[0021] S4. Upload the sharded ledger status to the aggregation layer through the cross-sharding communication protocol to generate the aggregated global transaction record; In this embodiment, the sharded ledger status is uploaded to the aggregation layer to generate aggregated global transaction records via a cross-sharding communication protocol, including the following steps: S4.1 Each blockchain subnet node organizes its local shard ledger status into a standard data structure (used for cross-shard communication, aggregating global transaction records, and ensuring data integrity and traceability). The standard data structure includes at least a transaction digest, block hash, account status digest, block height, and shard identifier. The shard ledger status is digitally signed to ensure integrity and immutability. S4.2, The asynchronous streaming state transfer protocol based on network coding uploads the digitally signed fragmented ledger state to the aggregation layer; Among them, the asynchronous streaming state transmission protocol based on network coding mainly addresses the transmission bottleneck problem faced in blockchain sharded cross-border payment scenarios when efficiently and reliably aggregating multiple sharded ledger states to the aggregation layer across networks (especially unstable intercontinental networks). Traditional synchronous or simple retransmission mechanisms are prone to increased overall aggregation latency due to network delays, packet loss, or single-path congestion during cross-shard communication, and may even cause system bottlenecks due to waiting for data from a particular shard, failing to meet the requirements of high real-time performance and eventual determinism in cross-border payments. The core advantage of this protocol lies in combining the fault tolerance of Random Linear Network Coding (RLNC) with asynchronous streaming processing. Its function is to encode data packets, allowing the aggregation layer to receive and decode them simultaneously without needing to wait for all original data packets in order, and combined with multi-path dynamic rate adjustment, greatly improving the robustness and efficiency of transmission. This not only significantly reduces the impact of network fluctuations and single-point failures on global aggregation, achieving near real-time streaming state updates, but also ensures the traceability and verifiability of the transmission process through lightweight verification information streams, providing a fast and accurate data foundation for subsequent global clearing. The asynchronous streaming state transfer protocol based on network coding uploads the digitally signed fragmented ledger state to the aggregation layer, including the following steps: S4.21. The digitally signed fragmented ledger state is split into n data blocks, and the data blocks are encoded using random linear network coding (RLNC) to generate encoded packets. The receiving end only needs to receive any K linear independent encoded packets to recover the original data. A parallel lightweight verification information stream is generated for each batch of fragmented ledger state encoded packets, including the hash value, timestamp, and transmission path identifier of each encoded packet. This stream is used to verify the integrity of the packets and the reliability of the path in real time during transmission. In this way, the system not only ensures the fault tolerance and fast recovery capability of the fragmented ledger state under asynchronous, multi-path transmission, but also realizes the authenticity verification and anomaly detection during transmission. Furthermore, a parallel lightweight verification information stream is generated for each batch of coded packets in the ledger state. The specific steps involved are as follows: calculate the content hash value, timestamp, and transmission path identifier for each coded packet to form a hash commitment vector, and bind the hash commitment vector with the corresponding coded packet identifier to form a lightweight verification information stream. This stream is then written to the blockchain storage layer in real time through a predefined sidechain channel to generate an immutable on-chain record, thereby enabling the verification of the authenticity of the coded packets during transmission, path traceability, and the basis for subsequent anomaly detection. Specifically, for each encoded packet, the aggregation layer node first extracts the original content of the encoded packet (i.e., the linearly combined data blocks and their coefficients) and serializes it into a byte sequence in a unified format. Then, it uses a predefined cryptographic hash function (SHA-256) to calculate the hash value of the sequence, which is used to uniquely identify the integrity of the encoded packet's content. Next, it records the sending or receiving timestamp of the encoded packet and the transmission path identifier (e.g., submarine fiber optic cable, satellite link, or backup channel number) that the packet traversed. The hash value, timestamp, and path identifier are combined to form a hash commitment vector. This vector is then bound to the corresponding encoded packet and can be written to the blockchain in real time through a predefined sidechain channel (the predefined sidechain channel is used to store lightweight verification information links, including node configuration, smart contract interface, consensus mechanism, and data field definition) to achieve verification of the authenticity of the encoded packet, path traceability, and anomaly detection. The hash commitment vector of each encoded packet is bound to the unique identifier of the encoded packet (encoded packet ID) to form a structured verification record. Then, these verification records are sequentially arranged to form a lightweight verification information stream used to track the integrity and transmission path of each encoded packet. To ensure immutability and traceability, verification information is written to the blockchain's evidence storage layer in real time through predefined sidechain channels: each verification record generates a block or transaction on the sidechain and is confirmed through a consensus mechanism, thus forming an immutable record on the chain; when the receiving end decodes or verifies the encoded packet, it can verify the matching between the hash commitment in the lightweight information stream and the actual encoded packet content to ensure the authenticity of the data, while also tracing the transmission path of the encoded packet to promptly detect packet loss or anomalies, ensuring the integrity and real-time performance of the aggregation process; S4.22. During transmission, a multi-path asynchronous data stream is established (when transmitting the fragmented ledger state after digital signature, the same batch of encoded packets is sent simultaneously through multiple network paths, such as submarine optical cables, satellite links, or different data center network links; each path transmits data independently and asynchronously to ensure that the fragmented ledger state reaches the aggregation layer in a faster and more reliable manner, thereby supporting subsequent real-time streaming aggregation processing). Encoded packets can be transmitted simultaneously through multiple paths such as submarine optical cables and satellite links. The transmission protocol adopts a custom protocol based on UDP to avoid TCP head-of-line blocking, and the transmission rate of each path is dynamically adjusted according to the real-time monitored network latency and packet loss rate (firstly, the key network data of each transmission path is continuously collected). The system uses network metrics, including average latency, packet loss rate, and bandwidth utilization, to calculate the available transmission capacity weight for each path: paths with low latency and low packet loss rate have higher weights, while paths with high latency or high packet loss rate have lower weights. Based on these weights, encoded packets are proportionally allocated to each path, and the transmission rate of each path is dynamically adjusted to ensure that high-quality paths handle more data flow, while low-quality paths have reduced load or are used only as redundant channels. The system also monitors transmission results in real time. If an increase in packet loss rate or latency is detected on a path, the transmission rate of that path is immediately adjusted, and retransmission or switching to a backup path is triggered if necessary, thereby ensuring continuous and reliable transmission of encoded packets and optimizing overall throughput and latency performance. S4.23. The aggregation layer nodes receive and decode the received encoded packets (when receiving encoded packets from multiple paths, it is not necessary to wait for all packets to arrive; decoding is performed simultaneously). Gaussian elimination is used to gradually recover the original state data. The rank of the decoding matrix is ​​monitored to determine if there are any missing linearly independent encoded packets (each encoded packet contains random linear combination coefficients of the original data blocks; the nodes fill these coefficients and encoded data into the decoding matrix; as new encoded packets arrive, Gaussian elimination is used to progressively process the matrix, transforming it into an upper triangular or echelon form to gradually eliminate linearly correlated redundant information, thereby recovering the original data blocks; simultaneously, the nodes monitor the rank of the decoding matrix in real time; when the rank equals the number of original data blocks, it indicates that enough linearly independent encoded packets have been collected). The packet (the original data block is the data block split in step S4.21) can completely restore the original state data; if the rank is less than the number of original data blocks, it means that there are still missing linear independent encoded packets. The node will continue to wait or supplement the missing encoded packets by requesting an alternative path. In this way, asynchronous and incremental decoding and missing detection are realized, ensuring the integrity and continuity of the fragmented ledger state, while improving real-time performance and fault tolerance. Lightweight verification information flow verification is also performed, that is: during the decoding process, the aggregation layer compares the received encoded packet with the hash commitment in the lightweight verification information flow; if it finds that the encoded packet corresponding to the commitment has not arrived within the specified time delay, it determines that the path is abnormal and requests the encoded packet through an alternative path or other trusted nodes, thereby ensuring the integrity and real-time performance of the aggregation process. S4.3. The aggregation layer node receives fragmented ledger states from different physical subnet nodes, performing integrity and digital signature verification on each fragmented state. (Upon receiving the fragmented ledger states from each subnet node, the aggregation layer node first extracts the digital signature and key fields (such as transaction digest, block hash, account status digest, block height, and fragment identifier), and then uses the subnet node's public key to verify the digital signature to confirm that the data has not been tampered with during transmission. Subsequently, the system performs integrity verification on the transaction digest, block hash, and account status digest to ensure that the fragmented ledger state is consistent with the original data. Only when both signature verification and integrity verification pass is the fragmented state considered valid and allowed to proceed.) The next step is aggregation processing (otherwise, an exception handling mechanism is triggered), and consistency verification is performed on the received shard ledger states. (After receiving shard ledger states from different subnets, the aggregation layer nodes first check for transaction conflicts or duplications, such as the same transaction ID appearing in multiple shards or inconsistent transaction states; secondly, they verify the continuity of block heights and previous block hashes in each shard to ensure the integrity of the chain order; finally, they handle exceptions according to preset conflict resolution rules (such as prioritizing the first arriving valid transaction or using the consensus result of a majority of nodes). Through these steps, consistency verification ensures that the states of each shard are logically consistent globally, providing a reliable data foundation for generating the aggregated global transaction record.) S4.4 Merge the ledger states of each shard after consistency verification according to the rules (specifically, the aggregation layer first ensures that only one record is kept for the same transaction ID to avoid duplication, and arranges transactions in the order of block height and previous block hash to ensure chain continuity; retains the shard identifier of each transaction to trace its source, and determines the final state according to preset priority or majority node consensus when transaction state conflicts occur; in addition, updates the account balance of transactions involving the same account in sequence to ensure that the global transaction record is unique, continuous, traceable and account state is consistent, providing reliable data for subsequent settlement, auditing and backtracking), generating an aggregated global transaction record, which includes at least: transaction ID, payer, payee, amount, currency, timestamp, transaction state, block height and corresponding shard information. The aggregated global transaction record and its summary are cached in the aggregation layer and can be distributed to the main chain or each subnet node for subsequent settlement, auditing or backtracking, while recording the generation time and participating shard node information to ensure the traceability and transparency of transactions.

[0022] S5. Write the aggregated global transaction records into the main chain global ledger to generate an immutable payment and settlement certificate, and generate a settlement result summary based on the aggregated global transaction records; In this embodiment, an immutable payment clearing voucher is generated, and a clearing result summary is generated based on the aggregated global transaction records, including the following steps: S5.1. The global transaction records generated by the aggregation layer are structured and encapsulated, that is, the transaction index, participant identity identifier, cross-shard association information and digital signature are formatted and encapsulated to form a data structure that conforms to the main chain ledger writing standard. S5.2. The underlying consensus mechanism (based on the Byzantine fault tolerance algorithm) is invoked to verify the structured and encapsulated global transaction records. (Each consensus node will vote on the records in multiple rounds to confirm the consistency of transaction format, signature, shard source, and account status, ultimately reaching a consensus of at least 2 / 3 or a preset proportion of nodes). Consensus signature information is generated (after verification, each consensus node generates its own digital signature, forming consensus signature information to prove that the record has been recognized by a majority of nodes). The structured, encapsulated, and consensus-verified global transaction records are then written into the main chain global ledger (the main chain global ledger is the entire multi-node sharded... The core ledger in the state aggregation system is used to record the aggregated global transaction records. It is an immutable, globally shared ledger that ensures the consistency and traceability of all transactions within the system. It calls the underlying consensus mechanism (based on the Byzantine fault tolerance algorithm) to verify the structured and encapsulated global transaction records. The nodes participating in the consensus verify the legality of the transaction records and generate their own digital signatures. When the number of signatures reaches the preset majority node ratio (e.g., ≥2 / 3), the system confirms that the global transaction record has been recognized by the majority of network nodes, and then writes it into the main chain global ledger to achieve immutable global state updates. S5.3 After the global ledger is written, a payment clearing certificate is automatically generated based on the hash root value, timestamp, and consensus signature information of the global transaction record. This certificate encapsulates the hash root value, timestamp, and consensus signature information of the global transaction record into a standardized data structure, including at least: transaction summary, participant identification, clearing time, global transaction record hash, consensus signature list, and verification method. This payment clearing certificate is then stored on the blockchain. Specifically, the payment clearing certificate is serialized into a standardized data structure (such as JSON or a structure supported by smart contracts). Then, the blockchain or sidechain's write interface is called to submit the certificate as transaction or block data to the chain. After submission, nodes participating in the consensus process verify the certificate (including the certificate format, digital signature, and hash value of the associated global transaction record). Once the consensus mechanism confirms its accuracy, the certificate is officially written to the blockchain, generating an immutable on-chain record. After storage, the certificate can be verified for authenticity and integrity by financial institutions, regulatory agencies, or payment participants through the on-chain query interface, achieving the function of immutable, traceable, and verifiable clearing certificate storage. S5.4 Generates a structured settlement result summary based on the core fields of the global transaction record. The core fields include at least the transaction amount, fund flow, settlement time window, and status label. The settlement result summary includes at least the transaction amount, fund flow, settlement time window (T+0 or T+1), and status label (success / rejection / pending review). It provides a concise expression of the fund flow path and status during the settlement process. The settlement result summary is fed back to relevant financial institutions, regulatory agencies, and payment participants through a secure communication channel. At the same time, it provides all parties with a verifiable query interface based on Merkle proof to achieve traceable verification and compliance review of settlement records.

[0023] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A multi-node cross-border payment clearing method based on blockchain sharding and dynamic aggregation, characterized in that: Includes the following steps: S1. Receive the user's cross-border transaction request and perform legality verification and encryption encapsulation on the transaction elements in the cross-border transaction request to generate transaction data; S2. Use consistent hashing to shard the transaction data and distribute the sharded transaction data to different blockchain subnet nodes; In the sharding process, a time-space-aware dynamic entropy weight hash ring is introduced to map the sharding key of the transaction request to the dynamic entropy weight hash ring to generate the hash value of the transaction data. S3. Each blockchain subnet node executes the smart contract rules on the received sharded transaction data, updates the local ledger on the sharded chain and generates blocks, thus forming the sharded ledger state. S4. Upload the sharded ledger status to the aggregation layer through the cross-sharding communication protocol to generate the aggregated global transaction record; S5. Write the aggregated global transaction records into the main chain global ledger to generate an immutable payment and settlement certificate, and generate a settlement result summary based on the aggregated global transaction records.

2. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 1, characterized in that: In step S1, generating transaction data involves the following specific steps: receiving cross-border transaction requests submitted by users, verifying the integrity and format of the transaction elements in the transaction requests; verifying user identity and permissions; encapsulating the verified transaction elements into a unified transaction data structure, generating a globally unique transaction ID and an initial state field, encrypting and digitally signing the transaction data, and generating the final transaction data. The transaction elements of a transaction request must include at least the payer, payee, amount, currency, and timestamp.

3. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 1, characterized in that: In step S2, the transaction data is sharded using consistent hashing, and the sharded transaction data is distributed to different blockchain subnet nodes, including the following steps: S2.1 Select sharding keys based on the region, currency, and clearing path of transaction data; S2.2 Based on the spatiotemporally aware dynamic entropy weighted hash ring, the sharding key is mapped to the hash ring to generate the hash value of the transaction data; S2.3 Determine the target virtual node and its corresponding physical subnet node based on the hash value; S2.4 Combine the transaction data with the hash value, fragmentation key and actual subnet node information to form fragmented data packets. The fragmented data packets shall include at least the transaction ID, transaction elements, encrypted information, digital signature and fragmentation identifier. S2.

5. Send the fragmented data packets to the target blockchain subnet node via a peer-to-peer network.

4. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 3, characterized in that: In step S2.2, based on the spatiotemporally aware dynamic entropy weight hash ring, the sharding key is mapped onto the hash ring to generate the hash value of the transaction data, including the following steps: S2.

21. Continuously collect historical transaction data and calculate the business heat entropy value using the shard key dimension combination as the unit; S2.

22. Monitor the dynamic available capacity of each physical subnet node in real time and calculate the dynamic capacity weight of the physical subnet node. S2.

23. Combining the business heat entropy value and the node dynamic capacity weight, the distribution of virtual nodes on the hash ring is dynamically adjusted to construct a dynamic entropy weight hash ring.

5. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 3, characterized in that: In step S2.3, determining the target virtual node and its corresponding physical subnet node involves the following steps: calculating the hash value using a hash function based on the sharding key corresponding to the transaction, locating the hash value to the dynamic entropy weight hash ring, searching for the first virtual node clockwise on the dynamic entropy weight hash ring, and mapping the virtual node to the corresponding physical subnet node.

6. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 1, characterized in that: In step S3, local ledger updates and block generation are performed on the sharded chain, simultaneously establishing the sharded ledger state, including the following steps: S3.1 Receive fragmented data packets based on a point-to-point network and perform integrity verification on the fragmented data packets, including at least verifying the correctness of the transaction ID, digital signature, and fragment identifier; S3.2 Verify the identities of the payer and payee in the transaction data; S3.3, Query the balance of the payer's account on the shard chain; S3.4 Conduct compliance review based on transaction currency, amount, and cross-border rules; S3.5 Write transactions that have passed verification, balance and compliance review to the local shard ledger, update account status and generate new blocks; S3.6 Summarize the latest ledger status on the current shard chain and generate the shard ledger status, which includes at least the transaction block height, account status, and transaction index.

7. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 1, characterized in that: In step S4, the sharded ledger status is uploaded to the aggregation layer to generate aggregated global transaction records via a cross-sharding communication protocol, including the following steps: S4.1 Organize the local sharded ledger state into a standard data structure. The standard data structure shall include at least a transaction digest, a block hash, an account state digest, a block height, and a shard identifier, and digitally sign the sharded ledger state. S4.2, The asynchronous streaming state transfer protocol based on network coding uploads the digitally signed fragmented ledger state to the aggregation layer; S4.3 Utilize the aggregation layer node to receive the fragmented ledger status from different physical subnet nodes, perform integrity verification and digital signature verification on each fragmented status, and perform consistency verification on the received fragmented ledger status. S4.4 Merge the ledger states of each shard after consistency verification according to the rules to generate an aggregated global transaction record. The global transaction record shall include at least the following: transaction ID, payer, payee, amount, currency, timestamp, transaction status, block height and corresponding shard information.

8. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 7, characterized in that: In step S4.2, the asynchronous streaming state transmission protocol based on network coding uploads the digitally signed fragmented ledger state to the aggregation layer, including the following steps: S4.

21. Divide the digitally signed fragmented ledger state into n data blocks, encode the data blocks using random linear network coding, generate an encoding packet, and generate a parallel lightweight verification information stream for the encoding packet of each batch of fragmented ledger states. S4.

22. Establish a multi-path asynchronous data stream and dynamically adjust the sending rate of each path based on real-time monitored network latency and packet loss rate; S4.

23. The aggregation layer node receives and decodes the received encoded packets, uses Gaussian elimination to recover the original state data, and determines whether there are missing linear independent encoded packets by monitoring the rank of the decoding matrix, and performs lightweight verification of the information flow.

9. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 8, characterized in that: In S4.21, a parallel lightweight verification information stream is generated for each batch of sharded ledger state coded packets. The specific steps involved are: calculating the content hash value, timestamp, and transmission path identifier of each coded packet to form a hash commitment vector, binding the hash commitment vector with the corresponding coded packet identifier to form a lightweight verification information stream, and writing it to the blockchain storage layer in real time through a predefined sidechain channel to generate an immutable on-chain record.

10. The multi-node cross-border payment clearing method of blockchain sharding-dynamic aggregation according to claim 1, characterized in that: In step S5, an immutable payment clearing voucher is generated, and a clearing result summary is generated based on the aggregated global transaction records, including the following steps: S5.

1. Perform structuring and encapsulation processing on the global transaction records generated by the aggregation layer; S5.

2. Call the underlying consensus mechanism to perform consensus verification on the structured and encapsulated global transaction records, generate consensus signature information, and write the structured, encapsulated, and consensus-verified global transaction records into the main chain global ledger. S5.3 Generate a payment clearing certificate based on the hash root value, timestamp, and consensus signature information of the global transaction record, and store the payment clearing certificate on the blockchain for evidence. S5.4 Generate a settlement result summary based on the core fields of the global transaction record. The core fields include at least the transaction amount, fund flow, settlement time window, and status label. The settlement result summary includes at least the transaction amount, fund flow, settlement time window, and status label.

Images