An on-chain and off-chain data consistency verification method for RWA asset transactions

Abstract

The application provides a kind of on-chain and off-chain data consistency verification method of RWA asset transaction, comprising: (1) deploying smart contract in blockchain network;(2) obtain chain transfer record and off-chain transaction order;(3) generate standardized data unit DU;(4) calculate off-chain root hash;(5) calculate on-chain root hash;(6) compare off-chain root hash with on-chain root hash;(7) if inconsistent, generate random sampling index set;(8) locate Merkle path proof;(9) verify Merkle path proof;(10) generate structured difference report.The application provides an efficient, automated, dynamically updated, privacy-protected and compliant consistency verification solution without introducing centralized risk, ultimately improving the data credibility and reconciliation efficiency of RWA asset transaction, reducing business risk and operation cost, and adapting to the actual needs of high-frequency and large-scale RWA transaction scenarios.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method for verifying the consistency of on-chain and off-chain data in RWA asset transactions. Background Technology

[0002] Blockchain technology, with its decentralized, immutable, and traceable characteristics, provides a trusted foundation for the digital transactions of RWA, typically through tokenization to achieve on-chain mapping and transfer of asset certificates and transaction records. However, RWA transactions need to connect with complex off-chain legal compliance processes and traditional IT systems (such as stock exchanges and settlement systems), leading to challenges in on-chain and off-chain data coordination.

[0003] Existing consistency verification schemes have significant drawbacks: First, they rely on intermediaries such as oracles or manual queries, introducing centralized risks, which contradicts the decentralized concept of blockchain; second, they adopt a full data comparison model, which requires traversing all blocks, resulting in low efficiency and high costs, and cannot meet the real-time requirements of high-frequency transactions; third, they lack dynamic update capabilities, making it difficult to adapt to scenarios with real-time data changes, and their flexibility in retrospective verification of historical data is insufficient, failing to efficiently support auditing needs. Summary of the Invention

[0004] This invention provides a method for verifying the consistency of on-chain and off-chain data in RWA asset transactions. The aim is to solve the inconsistency problem caused by system heterogeneity and processing delays in existing RWA transaction data. Without introducing centralized risks, this invention provides an efficient, automated, dynamically updatable consistency verification scheme that combines privacy protection and compliance. Ultimately, it improves the data credibility and reconciliation efficiency of RWA asset transactions, reduces business risks and operational costs, and adapts to the actual needs of high-frequency, large-scale RWA transaction scenarios.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A method for verifying on-chain and off-chain data consistency in RWA asset transactions includes the following steps: (1) Deploy smart contracts on a blockchain network, wherein the smart contracts have Merkle root storage, verifiable random function (VRF) random number generation and Merkle path proof verification functions; (2) Obtain the RWA asset on-chain transfer records recorded by the blockchain network and the RWA asset off-chain transaction orders processed by the off-chain transaction system, and extract the transaction identifier, timestamp, asset identifier, transaction amount, and transaction status core fields from the on-chain transfer records and off-chain transaction orders respectively; (3) Perform encrypted hashing on each core field separately, combine the hashing results of each core field in a preset order and perform encrypted hashing again to generate a standardized data unit DU; (4) Based on all data units (DU) corresponding to the same batch of off-chain transaction orders, construct a dynamic Merkle tree and calculate the off-chain root hash of the dynamic Merkle tree; (5) Based on all data units (DU) corresponding to the same batch of on-chain transfer records, construct a dynamic Merkle tree and calculate the on-chain root hash of the dynamic Merkle tree; (6) Compare the off-chain root hash obtained in step (4) with the on-chain root hash obtained in step (5); (7) If the off-chain root hash is inconsistent with the on-chain root hash, a random sampling index set is generated through the VRF function of the smart contract; (8) Locate the corresponding off-chain data unit DU and on-chain data unit DU according to the random sampling index set, and generate the Merkle path proof of each located data unit DU in the corresponding dynamic Merkle tree; (9) Use the off-chain root hash of step (4) to verify the Merkle path proof of the off-chain data unit DU, and use the on-chain root hash of step (5) to verify the Merkle path proof of the on-chain data unit DU. (10) Based on the verification results of step (9), identify the inconsistency types of on-chain and off-chain data and generate a structured difference report.

[0006] In this specification, the dynamic Merkle tree constructed in steps (4) and (5) supports incremental updates. When there is a new off-chain transaction order or on-chain transfer record of RWA asset, only the leaf node path of the standardized data unit DU corresponding to the new record is located in the dynamic Merkle tree, and all hash values ​​from the leaf node to the root node on the path are reconstructed without reconstructing the entire dynamic Merkle tree.

[0007] In this specification, when generating a random sampling index set through the VRF function of the smart contract in step (7), the input random sources of the VRF include the block hash of the current blockchain network, the off-chain trusted timestamp, and the VRF output result of the previous block. The above random sources are hashed and used as input parameters of the VRF to enhance the unpredictability of random sampling.

[0008] In this specification, the sampling quantity of the random sampling index set mentioned in step (7) is dynamically determined based on the total number of data to be verified on the same batch of internal and external chains, the preset verification confidence level, and the acceptable sampling error, so as to minimize the computational overhead while ensuring the verification confidence level.

[0009] This specification also includes an arbitration assistance step: when step (10) identifies data inconsistency, a zero-knowledge proof is generated. The zero-knowledge proof can prove to the arbitrator that there is a difference between on-chain and off-chain data that meets a preset threshold, without disclosing sensitive business data such as transaction amount and user identity.

[0010] In this specification, the inconsistency types mentioned in step (10) include omission, duplication, and amount error, wherein: omission refers to the existence of the standardized data unit DU corresponding to the off-chain transaction order in the off-chain dynamic Merkle tree, but no standardized data unit DU with the same transaction identifier is found on the chain within the preset time window; duplication refers to the existence of multiple standardized data units DU with the same transaction identifier on the chain, but only one standardized data unit DU corresponding to the transaction order exists off-chain, and the timestamp of the transfer record corresponding to the extra standardized data unit DU on the chain exceeds the reasonable network latency range; amount error refers to the matching of on-chain and off-chain transaction identifiers, but the corresponding standardized data units DU are different, and the relative difference between the transaction amounts of the two exceeds the preset tolerance threshold.

[0011] This manual also includes a historical batch backtracking verification step: according to the specified time range, obtain the historical on-chain transfer records of the blockchain network and the historical transaction orders of the off-chain transaction system within the time range, generate the corresponding standardized data unit DU according to steps (2)-(3), reconstruct the off-chain dynamic Merkle tree and the on-chain dynamic Merkle tree corresponding to the time range according to steps (4)-(5) and calculate the root hash, and complete the consistency verification of historical data according to steps (6)-(10).

[0012] In this specification, the comparison between the off-chain root hash and the on-chain root hash in step (6) is triggered by either a preset time interval or a preset number of transaction batches. The preset time interval and the preset number of transaction batches can be configured and adjusted as needed.

[0013] In this specification, when performing encrypted hashing on the core fields in step (3), the SHA-256 hash function is used. By hashing each core field separately and then combining the hashes, it is ensured that even a slight change in any core field will cause the corresponding standardized data unit DU to change.

[0014] This specification also includes the closed-loop interactive steps of Dynamic Weighted Bayesian Belief Network (DW-BBN), Dynamic Merkle Tree, Verifiable Random Function (VRF), and Zero-Knowledge Proof (ZKP), as detailed below: Initialize a dynamic weighted Bayesian belief network, which includes consistent confidence nodes, five core field anomaly nodes, a preset initial node weight set and a conditional probability table, and the five core field anomaly nodes correspond to the transaction identifier, timestamp, asset identifier, transaction amount and transaction status fields, respectively. When constructing the dynamic Merkle tree in steps (4) and (5), the dynamic Merkle tree calculates the update frequency of the corresponding branches for each field in real time, calculates the on-chain and off-chain root hash difference, and inputs the update frequency and root hash difference into the dynamic weighted Bayesian belief network. The dynamic weighted Bayesian belief network updates the node weight set based on the input data, outputs the node weights and consistency confidence of each field, and the dynamic Merkle tree calculates the branch update priority according to the node weights of the fields, and prioritizes the reconstruction of high-priority branches. When generating the random sampling index set in step (7), the VRF receives the consistency confidence and field node weights output by the dynamic weighted Bayesian belief network, adjusts the sampling amount according to the consistency confidence, and adjusts the sampling probability of each field according to the field node weights to generate a random sampling index set adapted to the current risk scenario; after completing the verification in step (9), the VRF calculates the sampling difference rate and feeds it back to the dynamic weighted Bayesian belief network, and the dynamic weighted Bayesian belief network updates the conditional probability table based on the sampling difference rate; After verifying the inconsistency in step (9), ZKP receives the abnormal field set, sampling index set, and sampling difference rate output by VRF, and generates proof parameters including a dynamic difference threshold. The dynamic difference threshold is dynamically adjusted according to the sampling difference rate and the corresponding field node weight. ZKP generates a zero-knowledge proof and submits it for verification, and feeds back the verification results to VRF and the dynamic weight Bayesian belief network respectively. VRF adjusts the next sampling priority of the corresponding field according to the verification results, and the dynamic weight Bayesian belief network updates the abnormal field node weights according to the verification results. The Dynamic Weighted Bayesian Belief Network outputs the updated consistency confidence node weights to ZKP. ZKP calculates the proof compression ratio based on the weights, adjusts the encryption complexity according to the compression ratio, and balances the strength of privacy protection with the efficiency of proof generation, forming a closed-loop interaction of the four algorithms.

[0015] In this specification, the RWA assets include bonds, real estate rental income rights, and new energy power plant income rights. By extracting the core fields of transaction identifier, timestamp, asset identifier, transaction amount, and transaction status corresponding to different types of RWA asset transactions, a standardized data unit (DU) is generated to adapt to on-chain and off-chain data consistency verification scenarios for multiple types of RWA assets.

[0016] In summary, this invention offers at least the following advantages: It achieves automated verification, significantly reducing manual intervention and upgrading the reconciliation process from a traditional manual or inefficient comparison model to a fully automated process, thus significantly improving reconciliation efficiency. Based on cryptographic mechanisms (hash functions, VRF, zero-knowledge proofs, etc.), it ensures the credibility and transparency of the verification process, avoiding the risks introduced by centralized trust nodes and enhancing the credibility of RWA transaction data. It reduces business risks caused by data inconsistency, reduces reconciliation-related operational costs, and lowers computing resource and on-chain storage overhead through a lightweight design. It possesses dynamic update and flexible expansion capabilities, adapting to high-frequency, large-scale RWA transaction scenarios, and supports batch backtracking verification of historical data, meeting auditing requirements. While ensuring the validity of verification, it protects the privacy of commercially sensitive data (such as transaction amounts and user identities), complying with financial compliance requirements. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the on-chain and off-chain data consistency verification method for RWA asset transactions in this invention.

[0018] Figure 2 This is a schematic diagram of the dynamic Merkle tree construction and update process in this invention.

[0019] Figure 3 This is a schematic diagram of the collaborative process of VRF sampling and Merkle proof in this invention.

[0020] Figure 4 This is a schematic diagram illustrating the architecture between the off-chain transaction system, the verification engine, and the blockchain network.

[0021] Figure 5 This is a schematic diagram of the flow of the two-level hybrid verification algorithm (TLHVA) in this invention.

[0022] Figure 6 This is a schematic diagram illustrating the dynamic Merkle tree construction and VRF sampling verification in this invention. Detailed Implementation

[0023] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0024] like Figure 1 As shown, this embodiment provides a method for verifying the consistency of on-chain and off-chain data in RWA asset transactions, including the following steps: (1) Deploy smart contracts on a blockchain network, wherein the smart contracts have Merkle root storage, verifiable random function (VRF) random number generation and Merkle path proof verification functions; (2) Obtain the RWA asset on-chain transfer records recorded by the blockchain network and the RWA asset off-chain transaction orders processed by the off-chain transaction system, and extract the transaction identifier, timestamp, asset identifier, transaction amount, and transaction status core fields from the on-chain transfer records and off-chain transaction orders respectively; (3) Perform encrypted hashing on each core field separately, combine the hashing results of each core field in a preset order and perform encrypted hashing again to generate a standardized data unit DU; (4) Based on all data units (DU) corresponding to the same batch of off-chain transaction orders, construct a dynamic Merkle tree and calculate the off-chain root hash of the dynamic Merkle tree; (5) Based on all data units (DU) corresponding to the same batch of on-chain transfer records, construct a dynamic Merkle tree and calculate the on-chain root hash of the dynamic Merkle tree; (6) Compare the off-chain root hash obtained in step (4) with the on-chain root hash obtained in step (5); (7) If the off-chain root hash is inconsistent with the on-chain root hash, a random sampling index set is generated through the VRF function of the smart contract; (8) Locate the corresponding off-chain data unit DU and on-chain data unit DU according to the random sampling index set, and generate the Merkle path proof of each located data unit DU in the corresponding dynamic Merkle tree; (9) Use the off-chain root hash of step (4) to verify the Merkle path proof of the off-chain data unit DU, and use the on-chain root hash of step (5) to verify the Merkle path proof of the on-chain data unit DU. (10) Based on the verification results of step (9), identify the inconsistency types of on-chain and off-chain data and generate a structured difference report.

[0025] The technical concept of this invention is as follows: The core of this invention is to build an automated, configurable verification engine that serves as a bridge between the on-chain blockchain network and the off-chain transaction system. It executes a two-level hybrid verification algorithm (TLHVA) through collaboration between on-chain smart contracts and off-chain lightweight verification clients.

[0026] The algorithm consists of three core modules: First, a data preprocessing layer, which standardizes heterogeneous on-chain and off-chain transaction data into unified and comparable data units (DUs) through hash encryption, balancing privacy protection and data uniqueness; second, a real-time verification layer, which constructs a hash tree based on a dynamic Merkle tree and performs preliminary screening of batch data consistency through rapid comparison of on-chain and off-chain Merkle roots, supporting incremental updates to reduce overhead; and third, a precise verification layer, which generates a verification index through VRF multi-source random sampling when anomalies occur during real-time verification, and completes precise verification by combining Merkle path proofs, while introducing zero-knowledge proofs for privacy protection in arbitration scenarios. Furthermore, the solution supports time-based or batch-based verification triggering, enabling real-time incremental verification and historical data batch backtracking verification, automatically identifying difference types and generating structured reports.

[0027] I. Core Ideas and System Architecture The core idea of ​​this invention is to design an automated, configurable verification engine as a bridge connecting the blockchain network and off-chain transaction systems. This engine deploys verification logic on-chain via smart contracts and a lightweight verification client off-chain, working together to complete consistency verification. The main participants in the system include: RWA asset issuers: responsible for asset mapping on-chain; trading platforms (off-chain): handling traditional order transactions; and the blockchain network (on-chain): recording the transfer of tokenized assets. The verification engine is the core of this invention, executing a two-level hybrid verification algorithm.

[0028] II. Innovative Algorithm: Detailed Construction of a Two-Level Hybrid Verification Algorithm The greatest innovation of this invention lies in proposing a two-layer hybrid verification algorithm (TLHVA).

[0029] 1. Data Preprocessing Layer: Data Unit Standardization Model; The core task of the data preprocessing layer is to transform heterogeneous on-chain and off-chain data into a standardized format that can be uniformly compared. Data units are defined as a standard format.

[0030] Data unit standardization formula: For a transaction record (whether it is an off-chain order or not) On-chain transfer ), convert it into a standardized data unit DU: Formula Explanation: H is a cryptographic hash function (such as SHA-256), and || represents the string concatenation operation. Timestamp Amount and Status are the core fields of the transaction.

[0031] Objective: By hashing each field individually and then combining the hashes, the privacy of the original data is protected while ensuring the uniqueness and comparability of the unique data unit (DU). Even a slight change to any field will result in a completely different DU.

[0032] 2. Real-time Verification Layer: Construction and Application of Dynamic Merkle Tree (Algorithm A); The real-time verification layer aims to achieve rapid initial screening of data consistency through a dynamic Merkle tree. Its construction and update process is as follows: Figure 2 The process also demonstrates the initial interaction points between Algorithm A (Dynamic Merkle Tree), Algorithm B (VRF Sampling), and Algorithm C (ZKP).

[0033] Model building process: 1. Leaf node generation: Generate all data units in a batch { , ,..., As a leaf node, its hash value 2. Tree construction algorithm: A bottom-up approach is used to construct the binary tree. For each leaf node pair ( ), calculate the hash of its parent node. If the number of nodes is odd, copy the last node for pairing. Recursively process this until a unique root hash is generated. 3. Dynamic update mechanism: When a new node is added... In this case, there is no need to reconstruct the entire tree. The algorithm locates the affected leaf node path and only recalculates all hash values ​​from the new leaf node to the root node along that path. This leverages the structural properties of Merkle trees, reducing the update complexity from O(N) to O(logN).

[0034] Model application process: 1. Root hash synchronization: The off-chain system will calculate the Merkle root. 1. Synchronize to on-chain smart contracts. 2. Fast comparison: On-chain contracts calculate the Merkle root of their own data. and with Comparison. 3. Consistency determination: If == If the data is not equal, the current batch of data is considered to be consistent with a very high probability; if they are not equal, the next level of precise verification is immediately triggered.

[0035] 3. Precise Verification Layer: This layer coordinates VRF sampling and Merkle proof; it is activated when the real-time verification layer detects inconsistencies or performs sampling checks as needed. Its core process is as follows: Figure 3 It clearly demonstrates how algorithm B (VRF sampling) works in conjunction with algorithm A (Merkle tree) and algorithm C (ZKP).

[0036] VRF Sampling Model: 1. Random Source Composition: The input α of VRF includes not only the current block hash It also integrates off-chain trusted timestamps. And the VRF output of the previous block, i.e. This multi-source hybrid model greatly enhances the unpredictability of randomness, preventing manipulation by attackers. 2. Sampling process: Smart contract execution Where β is the random number seed, It is verifiable. The contract uses β to generate a set of random sampling indices. 3. Sampling proportion determination rules: The sampling size k is not fixed, but dynamically adjusted based on the total population data N and the expected confidence level C (e.g., 99.9%). The formula for calculating the sample size for statistical hypothesis testing is as follows: Where Z corresponds to the quantile of confidence level C, p is the expected inconsistency rate (a conservative value of 0.5 can be taken), and E is the acceptable sampling error. Using this formula, the algorithm can minimize computational cost while maintaining high confidence levels.

[0037] Merkle proof verification: 1. The off-chain system finds the corresponding data unit based on the sampled index set S. 2. For each The off-chain system generates a Merkle path proof. This is a sequence of hashes of sibling nodes from the leaf node to the root node. 3. Submitted to the blockchain. 4. On-chain contract utilization. and the known root hash Verify whether it can be reconstructed The hash is used for verification. The formula recursively calculates the hash and finally checks whether the result equals... .

[0038] 4. Difference reporting and arbitration mechanisms; Logical judgment rules for difference classification: 1. Omission: Orders exist off-chain. Its standardized DU exists in the off-chain Merkle tree, but within a preset time window (such as 2 block times), no DU with the same value can be found on the chain. 1. DU. 2. Duplicate: There are two or more DUs in the chain with the same... The system checks the timestamps of these on-chain transfers; those exceeding a reasonable network latency range are considered duplicates. 3. Incorrect Amount: On-chain and Off-chain The data matches, but the calculated DU is different. The system will decrypt the original data and compare the Amount field. A tolerance threshold δ (e.g., 0.01%) is set; if... If so, it is determined that the amount is incorrect.

[0039] Enhancement through the introduction of zero-knowledge proof algorithms: 1. Functional positioning: In arbitration mechanisms, it is used to prove the authenticity of discrepancies to the arbitrator without disclosing sensitive business data (such as precise amounts or user identities). 2. Application process: When a discrepancy is detected, the off-chain system can generate a zero-knowledge proof. This proof demonstrates to the arbitrator that "I know the original data of an order, causing its generated DU to mismatch with the on-chain data, and the amount difference exceeds a threshold δ." The arbitrator only needs to verify... The validity of the data can be verified without having to view the original data, thus resolving the dispute and protecting privacy.

[0040] Algorithm Advantages: 1. Perfect Balance Between Efficiency and Trustworthiness: Through a two-layer structure of "real-time Merkle root comparison" and "VRF sampling verification," the complexity is optimized from O(N) to O(1) (average case), while cryptography ensures the reliability and fairness of the entire process. 2. Dynamism and Scalability: The dynamic Merkle tree supports efficient incremental updates, and the VRF sampling ratio can be dynamically adjusted, enabling the system to adapt to high-frequency, high-volume RWA transaction scenarios. 3. Privacy and Compliance: By introducing a zero-knowledge proof algorithm, the system meets the requirements of commercial data privacy and financial compliance while ensuring the validity of verification.

[0041] III. Work Process and Technical Effects Workflow: 1. Periodic Comparison and Batch Backtracking: The verification engine can be configured to trigger the real-time verification layer by time (e.g., every 5 minutes) or by batch (every 100 transactions). For historical data, simply specify the time range, and the system can batch reconstruct the Merkle tree state at that time and perform backtracking verification. 2. Identify Inconsistencies and Generate Reports: The precise verification layer clearly identifies the type of inconsistency (e.g., "omission" if there is an off-chain order but no on-chain transfer record, and "duplicate" if there is an off-chain order but no on-chain transfer record), and generates a structured discrepancy report (e.g., in JSON format). 3. Reduce Manual Verification: Full-process automation frees humans from heavy reconciliation work, requiring intervention only when handling arbitration or complex anomalies.

[0042] The technical advantages of this invention include: Increased efficiency: The automated verification process reduces reconciliation work from hours to minutes or even seconds. Enhanced credibility: The cryptographic verification mechanism ensures the credibility and transparency of the verification process itself. Reduced costs: Significantly reduces business risks and reconciliation maintenance costs caused by data inconsistency. Improved scalability: The lightweight verification design enables the solution to support large-scale, high-concurrency RWA transaction scenarios.

[0043] The invention will now be described in detail below with reference to the accompanying drawings, using a specific RWA bond trading scenario as an example.

[0044] Figure 4 This diagram illustrates the overall system architecture, showing the data flow and interaction between the off-chain transaction system, the verification engine, and the blockchain network. Core components and data flow descriptions: Data source: The off-chain transaction system (left) and the blockchain network (right) represent the two core systems that need to maintain data consistency. Verification engine: As the "brain" of the system, it is responsible for extracting data from the off-chain system, executing core verification algorithms, and interacting with on-chain smart contracts. Smart contracts: Deployed on the blockchain, they act as trusted executors of verification rules and recorders of the final state. Management interface: Provides operation entry points and displays verification results, and intervenes in arbitration when necessary.

[0045] Figure 5 This is a flowchart of the Two-Level Hybrid Verification (TLHVA) algorithm, detailing the logical judgments and data transfer at each step from data preprocessing to discrepancy report generation. Algorithm Flow Explanation: Data Preprocessing Layer: First, heterogeneous data from different sources is standardized, laying the foundation for subsequent comparisons. Real-Time Verification Layer: By comparing Merkle roots, a fast and lightweight initial screening is achieved. If the roots match, the batch of data is highly likely to be consistent, greatly improving efficiency. Precise Verification Layer: When anomalies are detected or periodic verifications are performed, VRF-based random sampling is initiated. This approach avoids the high cost of putting all data on the blockchain while detecting data inconsistencies with a high probability, achieving a balance between efficiency and reliability.

[0046] Figure 6 This diagram illustrates the construction and VRF sampling verification of a dynamic Merkle tree, visually demonstrating the processes of Merkle root synchronization, random sampling, and Merkle path proof verification. Cryptographic Verification Process Explained: Tree Construction and Root Synchronization: Off-chain, a batch of data units (DUs) is constructed into a Merkle tree. Any small change in the data will result in a significantly different root hash. Synchronizing the root hash onto the chain is equivalent to making an immutable "digital fingerprint" commitment to the entire batch of data. Random Sampling: On-chain smart contracts use VRF to generate unpredictable random indices, requiring the off-chain system to provide "identity proof" for specified data units. Path Proof: For the sampled data unit (e.g., ... Off-chain systems only need to provide from Adjacent hash values ​​on the Merkle root path (i.e. Verification can be completed in one step without exposing all data.

[0047] 1. System Deployment: Deploy a verification smart contract on the blockchain (such as FISCOBCOS). This contract includes functions for Merkle root storage, VRF random number generation, and Merkle proof verification. Deploy a verification client off-chain. This client can interact with the off-chain transaction database via API and has the ability to communicate with on-chain contracts.

[0048] 2. Consistency Verification Process: Data Preprocessing: The verification client reads the most recent batch of 100 bond orders from the transaction database, generating a standard data unit for each order (e.g., ...). The client constructs a Merkle tree using these 100 hash leaf nodes and submits the Merkle root to the on-chain verification contract via a transaction. Real-time verification: The on-chain contract compares the Merkle root submitted by the client with the Merkle roots generated from 100 corresponding transaction records. If they match, the batch verification passes. Precise verification (assuming Merkle roots are inconsistent): The on-chain contract calls the VRF function to randomly select 10 indices from 100 indices (e.g., transactions 3, 15, 78, ...) based on a random source such as the current block hash. The contract requires the client to submit Merkle path proofs for these 10 order data. The client generates the proofs and submits them to the chain. The contract verifies each proof. If 9 out of 10 proofs pass verification and 1 fails, the transaction data at index 78 is determined to be inconsistent and recorded in the discrepancy report.

[0049] 3. Discrepancy Handling: After the report is generated, it can notify operations personnel via message queue or directly trigger the on-chain arbitration process. After confirmation by multiple parties, the erroneous data can be corrected or reversed. Test Data: Set up a typical RWA transaction test scenario: ; Performance comparison of solutions: ; Based on the test data, the advantages are mainly reflected in the following aspects: The leap in efficiency: The core advantage lies in reducing verification time from "hours" or even "days" to "seconds". This is thanks to its design: the real-time layer performs preliminary screening by quickly comparing the Merkle tree root (a fixed-length hash value), and only when the root is inconsistent is the precise verification layer triggered to perform sampling verification. This "two-level" design avoids the huge overhead of traditional solutions that require traversing all the data.

[0050] Significantly reduced costs and resource consumption: The substantial efficiency gains directly translate into savings in computing resources and on-chain gas fees. Since only a tiny Merkle root and sporadic sampled proofs need to be stored on-chain, rather than the full data hash or update log, storage overhead is minimized. This is crucial for high-frequency, large-scale RWA transaction scenarios.

[0051] Balancing scalability and reliability: Traditional solutions often become impractical when processing large-scale data due to excessive time consumption. This solution, however, maintains processing time within minutes even when handling 1 million transactions, demonstrating exceptional scalability. Furthermore, based on cryptographic VRF random sampling and Merkel path proofs, it can detect data inconsistencies with an extremely high probability (>99.99%), achieving a breakthrough in efficiency while ensuring reliability.

[0052] Through the above methods, the present invention effectively achieves consistency verification of on-chain and off-chain data in RWA asset transactions.

[0053] In some embodiments, to further enhance the intelligence, dynamic adaptability, and anomaly detection accuracy of on-chain and off-chain data consistency verification in RWA asset transactions, this embodiment introduces a dynamic weighted Bayesian belief network fusion scheduling algorithm. The core value of this algorithm lies in breaking the unidirectional collaboration limitations of the original dynamic Merkle tree, verifiable random function, and zero-knowledge proof, constructing a closed-loop interaction system. Through deep pairwise associations, it achieves dynamic feedback and parameter optimization between algorithms, significantly improving the balance between verification efficiency, accuracy, and privacy protection.

[0054] I. Dynamic Weighted Bayesian Belief Network Dynamic Weighted Bayesian Belief Network (MWN) is an intelligent scheduling hub based on a Bayesian probability model. Through real-time updates of node dynamic weights and conditional probability tables, it achieves accurate prediction of the consistency state of on-chain and off-chain data and provides adaptive scheduling parameters for other algorithms. Its core definition is... ,in Represents a set of nodes. This represents the set of directed edges between nodes. Represents the dynamic weight set of nodes. A table representing the conditional probability between nodes.

[0055] (I) Model building process 1. Node set definition: Node set It comprises six core nodes, each corresponding to a key dimension of RWA transaction data consistency verification. As a confidence node for on-chain and off-chain data consistency, its output value directly reflects the overall consistency of the current batch of data; For nodes with abnormal transaction identifier fields, This is an abnormal node in the timestamp field. This is an abnormal node in the asset identifier field. This is an abnormal node in the transaction amount field. These are the abnormal nodes for the transaction status field. These five nodes correspond to the five core fields extracted during the data preprocessing stage and are used to characterize the abnormal risk status of each field.

[0056] 2. Definition of edge set: edge set Constructed as a directed edge structure, specifically including , , , , This structure clarifies the direct impact of abnormal states of each field on the overall data consistency confidence level. That is, anomalies in one or more fields will be propagated through the edge set, leading to changes in the overall consistency confidence level.

[0057] 3. Initial weight set setting: Dynamic weight set for nodes The expression at time t is: ,in Represents the node at time t The weight, with a value range of . And the sum of the weights of all nodes satisfies Based on statistical analysis of 100,000 historical transaction data points of three types of RWA assets—bonds, real estate rental income rights, and new energy power plant income rights—an initial weight set was established. Set as The node corresponding to the transaction amount field The weight is slightly higher because this field has the highest anomaly rate in RWA transactions and has the most significant impact on consistency; consistency confidence node The weight is set to 0.2 to ensure that it can output an objective confidence result by comprehensively considering the status of each field.

[0058] 4. Initial Conditional Probability Table Setting: Conditional Probability Table Used to characterize the parent node ( State pair subnet ( The probability of the state's influence. Based on historical anomaly data statistics, an initial conditional probability table. The setting is: when the status of a single field node is normal (i.e., no abnormality), This indicates that the overall data consistency confidence level is 95% at this point; when a single field node is in an abnormal state... This indicates that the overall consistency confidence level has dropped to 90%; when multiple field nodes are simultaneously abnormal, the conditional probability is calculated according to the multiplication rule of independent event probabilities, for example... ( and =0.9 x 0.9 = 0.81.

[0059] (II) Model Training Process 1. Training Dataset Preparation: 100,000 historical transaction records were collected from three types of RWA assets: bonds, real estate rental income rights, and new energy power plant income rights. Each data record was labeled with five fields: transaction identifier, timestamp, asset identifier, transaction amount, and transaction status (normal is marked as 0, abnormal as 1), indicating any abnormalities. The overall data consistency result was also labeled (consistent as 1, inconsistent as 0). This dataset covers different transaction frequencies, transaction amounts, and network latency scenarios to ensure the general applicability of the trained model.

[0060] 2. Iterative training process: The training process consists of 10 iterations. Each iteration optimizes the parameters based on the simulated dynamic Merkle tree update state and VRF sampling results.

[0061] Round 1 Training: Input the outlier states of fields and the overall consistency results from the historical dataset into the model. Adjust node weights using a dynamic weight update formula, and adjust the conditional probability table using a conditional probability update formula. The dynamic weight update formula is as follows: ,in The weight adjustment coefficient is obtained by training with historical verification data and is used to balance the rationality of the initial weights with the dynamism of real-time data. For nodes The corresponding dynamic Merkle tree branch update activity level, The difference between the root hash of the on-chain and off-chain dynamic Merkle tree. For indicator functions, when hour ,otherwise The conditional probability update formula will use the initial settings for now, and will be optimized in subsequent rounds based on the sampling results.

[0062] Training rounds 2-9: In each round of training, the update frequency of each branch of the simulated dynamic Merkle tree is measured. Calculate branch update activity (in Let be the maximum update frequency of all branches at time t. To avoid a denominator of 0), and to simulate the difference between on-chain and off-chain root hashes. (range of values) Simultaneously, the VRF sampling process is simulated, and the sampling variance rate is calculated. These simulated data are combined with historical labeled data, and the dynamic weight update and conditional probability update logic is repeated, with the conditional probability update formula being activated after the third round. ,in For VRF pairs of fields The sampling probability.

[0063] Round 10 training: Based on the results of the first 9 rounds of training, the focus is on optimizing the weight adjustment coefficients. With indicator functions This adaptability ensures that weight updates can quickly respond to feedback data from dynamic Merkle trees and VRFs.

[0064] 3. Convergence criterion: The maximum change in the weights of all nodes after two consecutive training rounds. And the maximum change in all probability values ​​in the conditional probability table At this point, the model training is considered converged. A stable initial weight set is then obtained. With conditional probability table The weighting adjustment coefficient The value was set at 0.7, which allows the model to maintain stability while being sufficiently sensitive to changes in real-time data.

[0065] (III) Model Application Process 1. Real-time input data reception: During the model application phase, two types of input data are received in real time: one type is feedback data from the dynamic Merkle tree, including the update frequency of each branch. Difference between on-chain and off-chain root hash Another type of feedback data comes from VRF and zero-knowledge proofs, including sampling variance rates. Sampling probability of each field Verification results with zero-knowledge proof (Valid verification is marked as 1, invalid verification is marked as 0).

[0066] 2. Weight and Conditional Probability Update: Based on the received input data, real-time iteration is performed using dynamic weight update formulas and conditional probability update formulas. For example, when the branch corresponding to the transaction amount field in the dynamic Merkle tree is updated with activity... (Above average), and root hash difference When there are significant differences, the node weight of the transaction amount field. The significant increase in weight indicates that the model has identified a high risk of anomaly in this field, requiring close attention.

[0067] 3. Consistency Confidence Calculation: Based on the updated weight set and conditional probability table, the consistency confidence is calculated using Bayes' theorem. The specific calculation process is as follows: First, determine the sampling results of each field. The state (0 or 1) is determined, and then the corresponding probability value is extracted from the conditional probability table. This probability value is then weighted and summed based on the node weights to obtain the final consistency confidence score. Its value range is The closer the value is to 1, the higher the consistency of the data in the current batch.

[0068] 4. Scheduling parameter output: The model will update the dynamic weight set. With consistency confidence The output is fed into a dynamic Merkle tree, VRF, and zero-knowledge proof system, providing adaptive scheduling parameters for each algorithm and enabling intelligent collaborative verification.

[0069] II. Integration and Interaction Logic of the Four Major Algorithms The four algorithms are centered on the Dynamic Weighted Bayesian Belief Network, forming a closed-loop interactive system of "Dynamic Merkle Tree ↔ Dynamic Weighted Bayesian Belief Network ↔ VRF ↔ Zero-Knowledge Proof ↔ Dynamic Weighted Bayesian Belief Network".

[0070] Algorithm fusion adaptation training and application (I) Fusion and Adaptation Training and Application of Dynamic Merkle Trees The core objective of fusion-adaptive training for dynamic Merkle trees is to enable their branch update strategy to accurately respond to the dynamic weights and priorities output by DW-BBN, avoiding the disconnect between priority calculation and anomaly detection rate, and ensuring that the update complexity is optimized without reducing anomaly sensitivity.

[0071] 1. Integration and Adaptation Training Process: Training dataset preparation: Based on 100,000 historical RWA transaction data from the same source as the DW-BBN training dataset, the branch update frequency, field anomaly status, and root hash difference of each data point are labeled according to the branch grouping rules of the dynamic Merkle tree (branch 1: transaction identifier + timestamp; branch 2: asset identifier + transaction amount + transaction status) to form an adapted training dataset.

[0072] Iterative optimization process: A total of 8 rounds of iterative training were conducted, and the priority calculation formula for the core optimization branch was used. The adaptability of the branch grouping was verified in rounds 1-3: the correlation coefficient between "priority and anomaly detection rate" under different grouping methods was calculated, and it was finally confirmed that the correlation coefficient of the current group was ≥0.85, which was better than other groups (such as the correlation coefficient of only 0.62 when grouped by amount size); the weight ratio in the formula was optimized in rounds 4-6: by adjusting The coefficient (initially 1.0, ultimately determined to be 1.0 because verification showed this coefficient optimally balances the impact of root hash difference and weight) ensures that branches corresponding to high-weight fields have significantly higher priority than low-weight branches; rounds 7-8 verify the stability of incremental updates: simulating 1000 new data additions to ensure that the complexity of priority-based incremental updates remains stable at [value missing]. And the root hash calculation error ≤ .

[0073] Convergence criterion: When the correlation coefficient between branch priority and anomaly detection rate fluctuates by less than 1 / 2 in two consecutive iterations. When the time cost fluctuation of incremental updates is ≤5%, the training is considered to have converged, and the branch grouping rules and priority calculation formula are determined as the final adapted version.

[0074] 2. Integration and Application Process: Branch initialization: Build branches according to the grouping rules determined by the adaptation training, and associate each branch with the corresponding field node (e.g., branch 2 is associated with...). , , It also stores the mapping relationship between branches and field nodes for easy retrieval. (The sum of the weights of the field nodes corresponding to the branch).

[0075] Dynamic update execution: Real-time reception of DW-BBN output and Calculate the update priority of each branch. Sort by priority from highest to lowest, and prioritize... Incremental updates are performed on branches with a high priority threshold determined through training, reconstructing only the path hashes affected by that branch; For low-priority branches, a "batch delayed update" strategy is adopted (updating once every 3 batches) to further reduce computational overhead.

[0076] Feedback data calibration: After the update is complete, calculate... and When adding a branch priority weight correction factor ( This ensures that the data fed back to DW-BBN accurately reflects the "true activity level of high-priority branches," thereby improving the accuracy of DW-BBN weight updates.

[0077] (II) VRF Fusion Adaptation Training and Application The core objective of VRF fusion and adaptation training is to ensure that its sampling strategy (sampling probability, sample size) accurately matches the consistency confidence of DW-BBN. With field weight This avoids "oversampling (high confidence scenario)" or "undersampling (low confidence scenario)" while optimizing the feedback accuracy of the sampling difference rate.

[0078] 1. Integration and Adaptation Training Process: Training dataset preparation: Collect VRF sampling data of 50,000 historical RWA transactions and label the DW-BBN output corresponding to each data point. , Sampling probability Sampling size The actual abnormal fields and abnormal detection results are used to form a sampling strategy-adapted dataset.

[0079] Iterative optimization process: A total of 10 rounds of iterative training were conducted, focusing on optimizing two key formulas. Rounds 1-5 optimized the sampling probability formula. The exponential coefficient in the model: initially 8, the correlation coefficient between sampling probability and actual outlier rate was iteratively verified under different coefficients. Finally, a coefficient of 10 was determined to achieve a correlation coefficient of 0.92 (the highest), ensuring a significant improvement in sampling probability under high-weight, low-confidence scenarios. The sampling formula was optimized in rounds 6-9. Basic sampling size :initial After verification At that time, In a (medium confidence) scenario, the anomaly detection rate is ≥99.9%, and the sampling cost is controlled within an acceptable range; the 10th round verifies the accuracy of the sampling difference rate calculation: a "weight ratio of anomaly fields" is introduced for correction. ( This ensures that the difference rate fed back to DW-BBN reflects the "impact of high-weight outlier fields".

[0080] Convergence criteria: When the correlation coefficient between the sampling probability and the actual anomaly rate is stable at ≥0.9, the fitting error between the sample size and the anomaly detection rate is ≤2%, and the corrected... Training is considered convergent when the matching degree with the DW-BBN conditional probability update is ≥0.88.

[0081] 2. Integration and Application Process: Sampling parameter initialization: Load the parameters determined during adaptation training (exponential coefficient = 10, ... ),Establish , and , The mapping table facilitates rapid calculation.

[0082] Sampling strategy generation: Real-time reception of DW-BBN output and Quickly calculate the sampling probability of each field using a mapping table. Calculate the total sample size according to the formula. ;like (Minimum effective sample size, determined through training), then it is forcibly set to 3 to avoid abnormal omissions caused by insufficient sample size; if (Maximum reasonable sampling size) is set to 20 to control computational costs.

[0083] Sampling result processing: After completing the sampling comparison, calculate according to the correction formula. Combined with the abnormal field set Synchronize with DW-BBN and the zero-knowledge proof system; simultaneously record the sampling strategy and anomaly detection results as supplementary data for the next round of fusion adaptation training, and continuously optimize sampling accuracy.

[0084] (III) Integration, Adaptation, Training, and Application of Zero-Knowledge Proofs The core objective of the fusion and adaptation training of zero-knowledge proofs is to enable their proof generation strategies (dynamic difference threshold, encryption complexity) to accurately adapt to the sampling results of VRF and the weight output of DW-BBN, balancing "accuracy of anomalous proofs", "strength of privacy protection" and "efficiency of proof generation", and avoiding "over-encryption (low-risk scenarios)" or "invalid proofs (high-risk scenarios)".

[0085] 1. Integration and Adaptation Training Process: Training dataset preparation: Collect variance data of 30,000 historical RWA transactions and label the VRF sampling variance rate corresponding to each data point. Exception Field Set DW-BBN output The actual amount difference, proof validity, and generation time are used to form a proof strategy adaptation dataset.

[0086] Iterative optimization process: A total of 9 rounds of iterative training were conducted, with two key logics optimized at the core. Rounds 1-4 optimized the dynamic difference threshold formula. Threshold coefficient in: initially only according to Adjustment( ), and corrected the weights of abnormal fields after training ( ), ensuring that the difference thresholds for high-weight fields are more stringent (e.g. (At that time, the threshold is increased by 30% compared to the base value); the 5th-7th rounds of optimization prove the compression ratio formula. The coefficient: The initial coefficient was 0.5, which was adjusted after verification. ,make The compression ratio is 0.67, proving that the generation time is ≤0.5 seconds, while the privacy protection strength still meets financial compliance requirements; the validity judgment logic of the verification in rounds 8-9 is to introduce the "weight ratio of difference amount" ( This ensures that the impact of monetary differences on high-weight fields is fully considered.

[0087] Convergence criteria: Training is considered converged when the anomaly recognition accuracy of the dynamic difference threshold is ≥99.5%, the fitting error between the compression ratio and the generation time is ≤3%, and the matching degree between the validity of the proof and the weight update of DW-BBN is ≥0.9.

[0088] 2. Integration and Application Process: Proof of parameter initialization: Load the formulas determined by adaptation training (corrected dynamic difference threshold formula, compression ratio formula), and establish... , , The mapping relationship between the parameters and the proof.

[0089] Proof generation and verification: Real-time reception of VRF output , , With DW-BBN output The dynamic difference threshold is generated according to the modified formula, and the compression ratio is calculated and proven. ;like (For high privacy requirements), zk-SNARKs are used to strengthen the encryption protocol; if It employs a basic encryption protocol, balancing efficiency and privacy; and generates proofs. Then, record the generation time, compression ratio, and verification results. Feedback is sent to VRF and DW-BBN.

[0090] Strategy Iteration and Optimization: Regularly (e.g., weekly), the generated proof data is incorporated into the adaptation training dataset, and the threshold coefficient and compression ratio formula are iteratively optimized to ensure long-term adaptation to changes in different RWA trading scenarios.

[0091] Algorithm Interaction Application (I) First-layer interaction: bidirectional interaction between dynamic Merkle tree and dynamic weighted Bayesian belief network The core objective of this layer's interaction is to optimize the update strategy of the dynamic Merkle tree through the dynamic weights of the dynamic weighted Bayesian belief network, avoiding ineffective reconstruction of low-value branches, and at the same time, to adjust the node weights of the dynamic weighted Bayesian belief network by utilizing the update state feedback of the dynamic Merkle tree, thereby improving the confidence prediction accuracy.

[0092] 1. Pre-interaction preparation: The dynamic Merkle tree is grouped by field to construct a branch structure, specifically divided into two branches: Branch 1 stores the standardized data unit (DU) corresponding to the transaction identifier and timestamp fields, and Branch 2 stores the standardized data unit (DU) corresponding to the asset identifier, transaction amount, and transaction status fields. This grouping method is based on historical data statistics to ensure that the update frequency of fields within the same branch is correlated with the anomaly risk, facilitating subsequent priority scheduling.

[0093] 2. Input process of dynamic Merkle tree to dynamic weighted Bayesian belief network: The dynamic Merkle tree calculates the update frequency of each branch in real time. (Unit: times / minute), for example, the update frequency of branch 2 at time t. Updates / minute indicates that 15 data entries are added or modified per minute on this branch. Branch update activity is calculated based on update frequency. ,in Let be the maximum update frequency of the two branches at time t. If the update frequency of branch 1 is... times / minute, then , At this point, the update activity of branch 2 is... Branch 1 update activity Simultaneously, the dynamic Merkle tree calculates the root hash on the chain. With off-chain root hash Difference If the on-chain root hash is "a1b2c3d4" (hash value mapping is 0.98) and the off-chain root hash is "a1b2c3d5" (hash value mapping is 0.97), then A dynamic Merkle tree updates the activity of all branches. Difference from root hash Synchronize to the dynamic weighted Bayesian belief network.

[0094] 3. The output process of a Dynamic Weighted Bayesian Belief Network to a Dynamic Merkle Tree: After receiving input data, the Dynamic Weighted Bayesian Belief Network adjusts the weights of each node using a dynamic weight update formula, such as the weight of the transaction amount field node. The weights were updated from the initial 0.2 to 0.26. Subsequently, the Dynamic Weight Bayesian Belief Network outputs the weights of each node, and the Dynamic Merkle Tree calculates the branch update priority based on the node weights and branch update activity. ,in This represents the sum of the field node weights corresponding to the branch. For branch 2, its corresponding... , , The three nodes have a total weight of Then the update priority of branch 2 Branch 1 corresponds to , The two nodes have a total weight of Update priority The dynamic Merkle tree prioritizes reconstructing and updating branch 2, which has a higher update priority. Only when branch 2 is updated and the root hash difference has not yet decreased below the threshold is branch 1 reconstructed. This strategy reduces the update complexity of the dynamic Merkle tree from... Further optimization ( For the number of high-priority branches, here This significantly reduces computational overhead.

[0095] The core contribution of this layer's interaction lies in realizing "intelligent trade-offs" in dynamic Merkle tree updates, avoiding the resource waste caused by "equal updates to all branches" in traditional solutions. At the same time, through real-time status feedback of the dynamic Merkle tree, the weight adjustment of the dynamic weighted Bayesian belief network is made more in line with the actual data changes, improving the accuracy of confidence prediction.

[0096] (ii) Second-layer interaction: bidirectional interaction between dynamic weighted Bayesian belief network and VRF The core objective of this layer of interaction is to intelligently adjust the sampling strategy of the VRF through the confidence output of the dynamic weighted Bayesian belief network, avoiding the high overhead of full sampling and the low accuracy of fixed sampling. At the same time, the sampling results of the VRF are used to optimize the conditional probability table of the dynamic weighted Bayesian belief network, forming a closed-loop optimization of strategy and results.

[0097] 1. Output process of Dynamic Weighted Bayesian Belief Network to VRF: The Dynamic Weighted Bayesian Belief Network calculates the consistency confidence score. Then, it is compared with the updated node weight set. Synchronize to VRF. VRF first calculates the sampling probability of each field based on node weights and confidence levels. This formula uses the Sigmoid function to convert weights and confidence levels into sampling probabilities between 0 and 1. The larger the weight and the lower the confidence level, the higher the sampling probability. For example, when... (High consistency) hour, ;when (Moderate consistency) hour, This significantly improves the sampling probability. Subsequently, VRF calculates the dynamic sample size based on the sampling probability. ,in The basic sample size As a confidence level adjustment factor, This is the floor function. If , ,but That is, the sample size is 4; if (Low consistency) ,but The sampling quantity was increased to 8 samples to ensure the anomaly detection rate in high-risk scenarios.

[0098] 2. Feedback process of VRF to Dynamic Weight Bayesian Belief Network: VRF is based on the calculated sampling probability. With sampling size Generate a random sampling index set For example, when the total batch data is 100 records and the sampling size is 4 records, the sampling index set... This corresponds to four randomly selected transaction data points. VRF extracts on-chain and off-chain field data from these transactions for comparison, counts the number of outliers to the total number of samples, and calculates the sampling discrepancy rate. If one of the four sampled data entries has an anomaly in the transaction amount field, then... Meanwhile, the VRF records the sampling probability corresponding to each anomaly field. and the sampling difference rate Sampling probability of field Feedback is fed into the Dynamic Weight Bayesian Belief Network. After receiving the feedback, the Dynamic Weight Bayesian Belief Network updates itself using the conditional probability formula. Update the conditional probability table. For example, the transaction amount field. initial conditional probability , , ,but The conditional probability has increased slightly, indicating that the impact of the anomaly of this field on overall consistency has decreased slightly in the current scenario.

[0099] The core contribution of this layer of interaction lies in realizing the "dynamic adaptation" of the VRF sampling strategy, which solves the problems of excessive overhead in low-risk scenarios and insufficient accuracy in high-risk scenarios by the traditional fixed sampling scheme. At the same time, it optimizes the conditional probability table of the dynamic weight Bayesian belief network through sampling result feedback, so that the confidence prediction is more in line with the actual verification results, forming a closed loop of "strategy-execution-feedback-optimization".

[0100] (III) Third-layer interaction: bidirectional interaction between VRF and zero-knowledge proof The core objective of this layer of interaction is to accurately locate the proof object of zero-knowledge proof by using the sampling anomaly results of VRF, thereby avoiding invalid encryption of the entire data by zero-knowledge proof. At the same time, it optimizes the sampling field priority of VRF by using the verification results of zero-knowledge proof, thereby improving the targeting of subsequent sampling.

[0101] 1. Input process of VRF to zero-knowledge proof: After VRF completes sampling verification, it clearly locates the set of abnormal fields. The set is A subset of the data, for example, if sampling reveals an anomaly in the transaction amount field, then... If both the transaction amount and timestamp fields are found to be abnormal, then At the same time, VRF will sample the index set. Sampling difference rate Synchronize to the zero-knowledge proof system. The zero-knowledge proof system generates proof parameters based on these inputs. ,in Based on the threshold for difference in basic amount, This is a dynamic difference threshold; the higher the sampling difference rate, the stricter the threshold, ensuring that no minute differences are missed in high-risk scenarios. For example, when... At that time, the dynamic difference threshold is If the off-chain transaction amount is $10,000 and the on-chain transfer amount is $9,999.8, the difference is $0.2, and the relative difference is... If the on-chain transfer amount is $9,998, then it is considered a normal fluctuation; if the on-chain transfer amount is $9,998, the relative difference is... If the amount is abnormal, proof must be generated.

[0102] 2. Feedback process from zero-knowledge proof to VRF: The zero-knowledge proof system is based on proof parameters. The encryption complexity is adjusted according to the dynamic compression ratio (the compression ratio is determined later when interacting with the dynamic weighted Bayesian belief network) to generate zero-knowledge proofs. This proof only demonstrates to the arbitrator that "there are differences between on-chain and off-chain data that meet dynamic thresholds," without disclosing sensitive information such as specific transaction amounts or user identities. After verifying the proof, the arbitrator outputs the verification result. The valid token is marked as 1, and the invalid token as 0. The zero-knowledge proof system will verify the results. The feedback is sent to the VRF, which adjusts the sampling priority of the outlier fields for the next time based on the result. For example, the current sampling probability of the transaction amount field. , , ,but The sampling probability of this field will increase significantly in the next sampling, ensuring that high-risk fields are given special attention; if (The proof is invalid, possibly due to sampling error), then The sampling probability remains constant, avoiding misadjustment.

[0103] The core contribution of this layer of interaction lies in achieving "precise focusing" of zero-knowledge proofs, which solves the inefficiency problem caused by the need to encrypt all differential data in traditional solutions. At the same time, it optimizes the sampling field priority of VRF by feedback of verification results, improves the targeting of anomaly detection in subsequent sampling, and ensures that verification resources are concentrated on high-risk fields.

[0104] (iv) Fourth-layer interaction: Bidirectional interaction between zero-knowledge proof and dynamic weighted Bayesian belief network The core objective of this layer of interaction is to optimize the node weights of the dynamic weighted Bayesian belief network through the verification results of zero-knowledge proofs, thereby improving the accuracy of confidence prediction. At the same time, the encryption complexity of zero-knowledge proofs is adjusted through the weight output of the dynamic weighted Bayesian belief network, balancing the strength of privacy protection with the efficiency of proof generation.

[0105] 1. Feedback process of zero-knowledge proof to dynamic weighted Bayesian belief network: The zero-knowledge proof system verifies the results. The results are synchronized to the Dynamic Weight Bayesian Belief Network, which then updates the weights of the outlier field nodes based on this result. Where 0.3 is the verification result adjustment coefficient, used to quantify the degree of influence of the verification result on the weight. For example, the current weight of the transaction amount field node. , (Proof valid, confirm the field is abnormal), then The weights are significantly increased, causing the dynamic weighted Bayesian belief network to place greater emphasis on the state of this field in subsequent confidence calculations; if (If the proof is invalid, exclude the field from being abnormal), then The weights remain unchanged to avoid misadjustment.

[0106] 2. The output process of a dynamically weighted Bayesian belief network towards zero-knowledge proof: The dynamically weighted Bayesian belief network updates the node weights of the consistency confidence level. The output is sent to a zero-knowledge proof system, which calculates the proof compression ratio based on this weight. The compression ratio ranges from 0.5 to 1.0, used to balance the strength of privacy protection with the efficiency of proof generation. (When consistency confidence is low and privacy protection requirements are high) Zero-knowledge proofs employ a strengthened encryption strategy, increasing the number of encryption rounds to ensure sensitive data is not leaked; in this case, the proof generation time is approximately 1.0 second. (When the consistency confidence level is moderate) Using standard encryption strategies, the proof generation time is approximately 0.7 seconds; when (When consistency confidence is high and efficiency requirements take precedence) Using a basic encryption strategy, the proof generation time is approximately 0.5 seconds. The zero-knowledge proof system achieves a calculated compression ratio. The encryption complexity is adjusted to generate zero-knowledge proofs suitable for the current scenario, and the proof generation efficiency is fed back to the dynamic weighted Bayesian belief network as an implicit reference for subsequent weight adjustments. If the proof generation efficiency is too low (>1.5 seconds), the dynamic weighted Bayesian belief network will appropriately increase the weight of the consistency confidence node. This indirectly improves the proof compression ratio, balancing efficiency and privacy.

[0107] The core contribution of this layer of interaction lies in achieving "intelligent adaptation" of the encryption complexity of zero-knowledge proofs, which solves the contradiction between privacy protection and efficiency in traditional solutions. At the same time, it further optimizes the node weights of the dynamic weighted Bayesian belief network through the feedback of verification results, making the decision-making of the entire closed-loop interaction system more accurate and more in line with the needs of actual scenarios.

[0108] III. The Core Role of Fusion Algorithms (I) Core Role and Contribution 1. The Innovative Value of Dynamic Weighted Bayesian Belief Networks: The application of Dynamic Weighted Bayesian Belief Networks in the field of RWA data consistency verification is innovative. Its core contribution lies in constructing an "intelligent hub" for algorithm collaboration, breaking the unidirectional execution limitations of the original three major algorithms, and upgrading the verification process from "mechanical execution" to "intelligent decision-making." Through real-time updates of dynamic weights and conditional probability tables, this network can adapt to the differences in different RWA asset types and transaction scenarios. For example, it automatically increases the weight of the transaction amount field for bond transactions and automatically increases the weight of the timestamp field for real estate rental income rights transactions, significantly improving the versatility and adaptability of the solution.

[0109] 2. Overall improvement through the integration of four major algorithms: Efficiency Improvement: The branch priority update of the dynamic Merkle tree reduces the complexity of incremental updates from... Down to The dynamic sampling size of VRF reduces sampling overhead by 30% to 50%, and the dynamic compression ratio of zero-knowledge proof improves proof generation efficiency by 2 to 3 times, further shortening the overall verification time compared to the original scheme. Improved accuracy: By adjusting the weights of the dynamic weighted Bayesian belief network and the sampling priority of the VRF, the field-level anomaly detection rate was increased from >99.99% to >99.995%, effectively avoiding the omission of anomalies caused by random sampling; Balancing privacy and efficiency: The dynamic compression ratio design of zero-knowledge proof prioritizes privacy protection when consistency confidence is low and prioritizes efficiency improvement when confidence is high, perfectly resolving the contradiction between "inefficient full encryption" and "privacy leakage without encryption" in traditional solutions. Resource optimization: Intelligent scheduling concentrates verification resources on high-risk fields and high-priority branches, significantly reducing computing resources and on-chain storage overhead, making it suitable for large-scale, high-frequency RWA transaction scenarios.

[0110] In the closed-loop interaction system of the four algorithms, the interaction is not an infinite loop, but rather terminates with "verification goal achievement" as the core logic. The specific termination time needs to be determined based on the verification scenario (real-time incremental verification, anomaly repair verification, and historical batch backtracking verification). Each scenario has clear termination trigger conditions and cleanup procedures to ensure that the interaction is closed-loop and the results are implementable. The following details the timing, judgment criteria, and cleanup operations for the end of the interaction according to the scenario: I. Real-time incremental verification scenario: The termination condition is "consistency confidence meets the standard + no unhandled anomalies". The interaction termination logic for real-time incremental verification (triggered at preset time intervals or transaction batches) revolves around "on-chain and off-chain data consistency confirmation," and the specific termination timing and process are as follows: 1. Initial Interaction Progression: The dynamic Merkle tree completes branch updates and root hash calculations, and DW-BBN outputs consistency confidence. VRF performs dynamic sampling, ZKP generates proofs as needed, and each algorithm completes 1-2 rounds of parameter feedback and optimization according to closed-loop interaction logic (usually 1 round of interaction can cover the verification requirements of a single batch).

[0111] 2. Termination Trigger Condition: The interaction is considered to have ended when any of the following sub-conditions are met: Sub-condition 1 (High Confidence Consistency): Consistency confidence of DW-BBN output ( (For a pre-set confidence threshold), and the on-chain root hash of the dynamic Merkle tree. With off-chain root hash exactly the same ( This indicates that the current batch of data is normal and no further verification is needed.

[0112] Sub-condition 2 (low confidence but no sampling anomalies): if However, VRF undergoes two rounds of dynamic sampling (the sample size is calculated according to the formula). After dynamic improvement (the second round of sampling size is 1.5 times that of the first round), the sampling difference rate... (No abnormal fields), and ZKP's proof results for suspected risky fields. (No valid proof of difference). This indicates that the low confidence level is a misjudgment caused by data fluctuations, and there is no actual anomaly.

[0113] 3. Closing Process: After the interaction is complete, the system automatically performs two operations: Recording the verification result: Recording the "Verification Passed" status and consistency confidence level. Data such as sampling size and root hash value are written to the on-chain smart contract and off-chain verification log to form an immutable verification record; the interaction state is reset: the weight set of DW-BBN. With conditional probability table The current iteration result is retained (as the initial parameters for the next batch of verification), the dynamic Merkle tree clears the current batch branch cache, and VRF and ZKP reset temporary data such as the sampling index set and proof parameters to prepare for the next batch of verification.

[0114] II. Anomaly Repair and Verification Scenario: The termination condition is "complete anomaly repair + verification passed". When real-time verification detects anomalies (inconsistent root hashes, differences detected in sampling, or valid ZKP proofs), the interaction enters a "repairing anomalies - secondary verification" loop until the anomalies are completely repaired. The specific termination time and process are as follows: 1. Interactive Progression in the Anomaly Handling Phase: After the initial interaction detects an anomaly, the system generates a structured discrepancy report (clearly identifying the anomaly type: omission, duplication, or amount error; annotating fields and sampling indexes), and triggers a manual or automatic repair process (e.g., supplementing transfer records for on-chain omissions, deleting redundant orders for off-chain duplications). After repair, the system automatically triggers a secondary verification, with four algorithms repeatedly engaging in a closed-loop interaction logic (dynamic Merkle tree updates the repaired data, DW-BBN recalculates confidence, VRF specifically samples anomaly fields, and ZKP verifies the repair effect).

[0115] 2. Termination Trigger Condition: The interaction is considered to have ended if all of the following sub-conditions are met after secondary verification: Subcondition 1: The on-chain root hash and the off-chain root hash of the dynamic Merkle tree are completely identical. ); Subcondition 2: VRF sampling variance rate for outlier fields (The repaired fields are normal); Subcondition 3: Proof results generated by ZKP for the repaired difference fields (No valid proof of difference means the repair is effective); Subcondition 4: Consistency confidence of DW-BBN output (The consistency after repair is extremely high).

[0116] 3. Closing Process: Generate an "Anomaly Repair - Verification Passed" report, which records the original anomaly state, repair operation, and secondary verification result in detail, and synchronizes it to the on-chain contract and operation and maintenance system; DW-BBN updates the conditional probability table (incorporating the repaired data state into training to optimize the accuracy of subsequent anomaly prediction); reset the temporary parameters of all algorithms, and end the interaction related to this anomaly repair.

[0117] 4. Special Termination Rules: If the anomaly is not corrected after the second verification (e.g., the sampling difference rate is still >0), the "repair-verification" loop is repeated for a maximum of 3 iterations. If the anomaly still exists after 3 iterations, the system triggers the highest level alarm, the interaction is terminated, and the abnormal data is locked for manual intervention (the algorithm interaction is no longer executed in the locked state, only the anomaly record is retained).

[0118] III. Historical Batch Backtracking Verification Scenario: The termination condition is "full coverage of the time range + no unverified data". The interaction termination logic for historical batch backtracking verification (triggered by a specified time range) revolves around "full historical data verification completed". The specific termination timing and process are as follows: 1. Retrospective Interactive Advancement: The system processes historical data in time-sliced ​​chunks (e.g., by day, with each day being a sub-batch). Each sub-batch performs a closed-loop interaction consistent with real-time verification (data preprocessing → Merkle tree construction → DW-BBN confidence calculation → VRF sampling → ZKP proof), and records the sub-batch verification results.

[0119] 2. Termination trigger condition: Sub-condition 1: All time-segmented sub-batches have been validated (without any missing historical time periods). Sub-condition 2: The verification results of all sub-batch have been recorded (including pass, anomaly repair pass, and anomaly not repaired locked). Sub-condition 3: The repair operation for historical anomalies (if any) has completed secondary verification and meets the termination condition of anomaly repair verification.

[0120] 3. Closing Process: Generate a historical backtesting verification report, summarizing the verification results, anomaly statistics, and repair status of each sub-batch, and supporting filtering and querying by time, asset type, and anomaly type; DW-BBN integrates feedback data from all historical sub-batches, completes a full weight and conditional probability table optimization (improving long-term prediction accuracy); releases historical data cache, resets temporary parameters of all algorithms, and the interaction officially ends.

[0121] IV. Core Criteria and Guarantee Mechanisms for Determining the End of Interaction 1. Unified Judgment Principle: The completion of all interaction scenarios must satisfy "goal achieved + state stable", that is, the verification task (real-time incremental, anomaly repair, historical backtracking) has been completed, and the core indicators output by the algorithm (root hash difference, consistency confidence, sampling difference rate, proof validity) are in a stable state (no significant change in two consecutive iterations, change amount < This avoids accidental termination due to data fluctuations.

[0122] 2. Abnormal Termination Mechanism: If an unavoidable failure occurs during the interaction (such as on-chain contract failure, off-chain database disconnection, algorithm calculation timeout > 5 minutes), the system triggers the "abnormal termination" process: record the current interaction progress and intermediate results, lock the processed data, and resume the interaction from the breakpoint after the failure is repaired, without having to re-execute the entire process, ensuring the continuity of the interaction and the integrity of the data.

Claims

1. A method for on-chain and off-chain data consistency verification of RWA asset transactions, characterized in that, include: (1) Deploy smart contracts on a blockchain network, wherein the smart contracts have Merkle root storage, verifiable random function random number generation and Merkle path proof verification functions; (2) Obtain the RWA asset on-chain transfer records recorded by the blockchain network and the RWA asset off-chain transaction orders processed by the off-chain transaction system, and extract the transaction identifier, timestamp, asset identifier, transaction amount, and transaction status core fields from the on-chain transfer records and off-chain transaction orders respectively; (3) Perform encrypted hashing on each core field separately, combine the hashing results of each core field in a preset order and perform encrypted hashing again to generate a standardized data unit DU; (4) Based on all data units (DU) corresponding to the same batch of off-chain transaction orders, construct a dynamic Merkle tree and calculate the off-chain root hash of the dynamic Merkle tree; (5) Based on all data units (DU) corresponding to the same batch of on-chain transfer records, construct a dynamic Merkle tree and calculate the on-chain root hash of the dynamic Merkle tree; (6) Compare the off-chain root hash obtained in step (4) with the on-chain root hash obtained in step (5); (7) If the off-chain root hash is inconsistent with the on-chain root hash, a random sampling index set is generated through the VRF function of the smart contract; (8) Locate the corresponding off-chain data unit DU and on-chain data unit DU according to the random sampling index set, and generate the Merkle path proof of each located data unit DU in the corresponding dynamic Merkle tree; (9) Use the off-chain root hash of step (4) to verify the Merkle path proof of the off-chain data unit DU, and use the on-chain root hash of step (5) to verify the Merkle path proof of the on-chain data unit DU, and obtain the verification result. (10) Based on the verification results of step (9), identify the inconsistency types of on-chain and off-chain data and generate a structured difference report.

2. The on-chain and off-chain data consistency verification method of RWA asset transaction according to claim 1, characterized in that, The dynamic Merkle tree constructed in steps (4) and (5) supports incremental updates. When there is a new off-chain transaction order or on-chain transfer record for RWA assets, only the leaf node path of the standardized data unit DU corresponding to the new record is located in the dynamic Merkle tree, and all hash values ​​from the leaf node to the root node on the path are reconstructed without reconstructing the entire dynamic Merkle tree. 3.The method of claim 1, wherein, In step (7), when generating a random sampling index set through the VRF function of the smart contract, the random sources of input to the VRF include the block hash of the current blockchain network, the off-chain trusted timestamp, and the VRF output result of the previous block. The random sources are hashed and then used as input parameters of the VRF to enhance the unpredictability of random sampling.

4. The method of claim 1, wherein, The sampling quantity of the random sampling index set mentioned in step (7) is dynamically determined based on the total number of data to be verified on the same batch of internal and external chains, the preset verification confidence level, and the acceptable sampling error, so as to minimize the computational overhead while ensuring the verification confidence level.

5. The method of claim 1, wherein, It also includes an arbitration support step: when step (10) identifies data inconsistency, a zero-knowledge proof is generated, which can prove to the arbitrator that there is a difference between on-chain and off-chain data that meets a preset threshold, without disclosing sensitive business data.

6. The on-chain and off-chain data consistency verification method for RWA asset transactions according to claim 1, characterized in that, The inconsistency types mentioned in step (10) include omission, duplication, and amount error, where: omission refers to the existence of the standardized data unit DU corresponding to the off-chain transaction order in the off-chain dynamic Merkle tree, but no standardized data unit DU with the same transaction identifier is found on the chain within the preset time window; duplication refers to the existence of multiple standardized data units DU with the same transaction identifier on the chain, but only one standardized data unit DU corresponding to the transaction order exists off-chain, and the timestamp of the transfer record corresponding to the extra standardized data unit DU on the chain exceeds the reasonable network latency range; amount error refers to the matching of transaction identifiers on-chain and off-chain, but the corresponding standardized data units DU are different, and the relative difference between the transaction amounts of the two exceeds the preset tolerance threshold.

7. The on-chain and off-chain data consistency verification method for RWA asset transactions according to claim 1, characterized in that, It also includes a historical batch backtracking verification step: according to the specified time range, obtain the historical on-chain transfer records and historical transaction orders of the blockchain network within the time range, generate the corresponding standardized data unit DU according to steps (2)-(3), reconstruct the on-chain dynamic Merkle tree and on-chain dynamic Merkle tree corresponding to the time range according to steps (4)-(5) and calculate the root hash, and complete the consistency verification of historical data according to steps (6)-(10).

8. The on-chain and off-chain data consistency verification method for RWA asset transactions according to claim 1, characterized in that, In step (6), the comparison between the off-chain root hash and the on-chain root hash is triggered by either a preset time interval or a preset number of transaction batches. The preset time interval and the preset number of transaction batches can be configured and adjusted as needed.

9. The on-chain and off-chain data consistency verification method for RWA asset transactions according to claim 1, characterized in that, In step (3), when performing encrypted hashing on the core fields, the SHA-256 hash function is used. By hashing each core field separately and then combining the hashes, it is ensured that even a slight change in any core field will cause the corresponding standardized data unit (DU) to change.

10. The on-chain and off-chain data consistency verification method for RWA asset transactions according to claim 1, characterized in that, It also includes the Dynamic Weighted Bayesian Belief Network (DW-BBN), Dynamic Merkle Tree, Verifiable Random Function (VRF), and the closed-loop interaction steps of Zero-Knowledge Proof (ZKP), as detailed below: Initialize a dynamic weighted Bayesian belief network, which includes consistent confidence nodes, five core field anomaly nodes, a preset initial node weight set and a conditional probability table, and the five core field anomaly nodes correspond to the transaction identifier, timestamp, asset identifier, transaction amount and transaction status fields, respectively. When constructing the dynamic Merkle tree in steps (4) and (5), the dynamic Merkle tree calculates the update frequency of the corresponding branches for each field in real time, calculates the on-chain and off-chain root hash difference, and inputs the update frequency and root hash difference into the dynamic weighted Bayesian belief network. The dynamic weighted Bayesian belief network updates the node weight set based on the input data, outputs the node weights and consistency confidence of each field, and the dynamic Merkle tree calculates the branch update priority according to the node weights of the fields, and prioritizes the reconstruction of high-priority branches. When generating the random sampling index set in step (7), the VRF receives the consistency confidence and field node weights output by the dynamic weighted Bayesian belief network, adjusts the sampling amount according to the consistency confidence, adjusts the sampling probability of each field according to the field node weights, and generates a random sampling index set that is adapted to the current risk scenario. After the VRF completes the verification in step (9), it calculates the sampling difference rate and feeds it back to the dynamic weighted Bayesian belief network. The dynamic weighted Bayesian belief network updates the conditional probability table based on the sampling difference rate. After verifying the inconsistency in step (9), ZKP receives the abnormal field set, sampling index set, and sampling difference rate output by VRF, and generates proof parameters including a dynamic difference threshold. The dynamic difference threshold is dynamically adjusted according to the sampling difference rate and the corresponding field node weight. ZKP generates a zero-knowledge proof and submits it for verification, and feeds back the verification results to VRF and the dynamic weight Bayesian belief network respectively. VRF adjusts the next sampling priority of the corresponding field according to the verification results, and the dynamic weight Bayesian belief network updates the abnormal field node weights according to the verification results. The Dynamic Weighted Bayesian Belief Network outputs the updated consistency confidence node weights to ZKP. ZKP calculates the proof compression ratio based on the weights, adjusts the encryption complexity according to the compression ratio, and balances the strength of privacy protection with the efficiency of proof generation, forming a closed-loop interaction of the four algorithms.

Images