Bidirectional state mapping type block chain data verification method and system

Abstract

The invention discloses a bidirectional state mapping type block chain data verification method and system, and belongs to the technical field of block chains. The method comprises the following steps: capturing a source end state change request, distributing a timestamp identifier and a conflict weight value, receiving an external reserve voucher, and extracting a time sequence hash identifier and a reserve value; extracting an access mode feature vector and determining a verification step length strategy; judging a mapping path according to the access mode feature vector, splitting into a parallel processing link when a hot spot region conflict exists, and retrieving a change set in an incremental buffer area; generating an intermediate state mapping data structure, and constructing a virtual state snapshot through reverse replay; executing timestamp alignment and numerical value comparison, and outputting a verification result vector; and executing closed-loop feedback compensation according to a verification result. According to the method, real-time verification of request driving can be realized, historical state reconstruction is supported, bidirectional cross validation is adopted, adaptive parallel processing capability is realized, and closed-loop feedback optimization is formed.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a two-way state mapping-based blockchain data verification method and system. Background Technology

[0002] Blockchain technology, as a distributed ledger technology, has been widely applied in fields such as digital asset management, supply chain finance, and cross-border payments. In scenarios where blockchain interacts with off-chain systems, ensuring the consistency between on-chain data and off-chain credentials is a key technical aspect of guaranteeing system trustworthiness. For example, in applications such as digitizing warehouse receipts in supply chain finance, tokenizing real-world assets, and cross-chain bridge asset transfers, it is necessary to continuously verify the correspondence between on-chain digital credentials and off-chain physical asset credentials.

[0003] Currently, the mainstream blockchain data verification schemes mainly include the following categories: The first category is the periodic audit scheme based on proof-of-reserve, which compares the on-chain state with off-chain credentials by periodically taking snapshots; the second category is the transaction inclusion verification scheme based on Merkle trees, which verifies whether a specific transaction is included in a block; and the third category is the data integrity verification scheme based on hash chains, which verifies that the data has not been tampered with by comparing the block hash value.

[0004] However, the above-mentioned existing technical solutions have the following technical defects: First, regarding the timing of verification, existing solutions mostly employ a periodic auditing model, which can only detect data inconsistencies after the audit period has ended. The technical drawback of this model is that changes in data state occurring during the audit interval cannot be detected in a timely manner. From a technical perspective, this is because existing solutions lack a request-driven real-time state monitoring mechanism, failing to trigger the verification process immediately when state changes occur.

[0005] Secondly, regarding state acquisition, existing solutions typically directly read the current blockchain state and compare it with the credential. The technical flaw in this approach is that when the time point corresponding to the credential differs from the time point of the current state snapshot, it can lead to misjudgments in the verification results. From a technical perspective, this is because existing solutions lack the technical means to accurately reconstruct the state at the target time point based on the credential's time sequence, making it impossible to trace back to the historical state corresponding to the credential's timestamp for verification.

[0006] Third, regarding verification dimensions, existing solutions mostly employ a one-way verification mode, meaning they only compare data in one direction: from on-chain to off-chain or from off-chain to on-chain. The technical drawback of this mode is that one-way verification is susceptible to interference from timing discrepancies and cannot effectively identify false inconsistency alarms caused by system clock deviations. From a technical principle perspective, this is because existing solutions lack a two-way cross-verification mechanism that combines timestamp alignment verification with numerical comparison verification.

[0007] Fourth, in terms of processing architecture, existing solutions mostly adopt a fixed serial processing flow. The technical drawback of this model is that when the system faces high-concurrency state change requests, access conflicts in hot address areas can cause the verification process to block, reducing the overall system throughput. From a technical perspective, this is because existing solutions lack an adaptive mechanism to dynamically adjust the processing architecture based on access patterns and cannot automatically split processing paths according to load characteristics.

[0008] Fifth, regarding the feedback mechanism, existing solutions typically only output a simple pass or fail flag after verification, lacking a closed-loop mechanism to feed the verification results back to the preceding processing stages. The technical drawback of this approach is that subsequent verifications cannot automatically optimize parameter configurations based on historical verification results. From a technical principle perspective, this is because existing solutions lack a multi-point feedback closed-loop control architecture, and the verification results cannot be used as adjustment inputs to pass to preceding steps such as state capture and buffer management.

[0009] In summary, a blockchain data verification technology solution is needed that can achieve request-driven real-time verification, support accurate reconstruction of historical states, adopt bidirectional cross-validation, have adaptive parallel processing capabilities, and form a closed-loop feedback optimization. Summary of the Invention

[0010] The technical problem to be solved by this invention is that existing blockchain data verification schemes have technical defects such as insufficient real-time verification, inability to reconstruct historical state, susceptibility to timing deviation interference in one-way verification, concurrency performance bottlenecks in fixed processing procedures, and lack of closed-loop feedback optimization mechanisms.

[0011] To address the aforementioned technical problems, this invention provides a bidirectional state-mapping blockchain data verification method, comprising the following steps: S1. State Change and Credential Receipt Steps: Capture the original state change request initiated by the source end, assign a timestamp identifier and a conflict weight value calculated based on the data access frequency to the state change request; receive external reserve credentials, and extract the time-series hash identifier and reserve value of the credentials.

[0012] S2. Runtime Feature Acquisition and Verification Strategy Determination Steps: Scan the system runtime state and extract access mode feature vectors, which reflect the access density distribution of the mapped address space; monitor the system runtime instruction sequence and determine the current verification step size strategy.

[0013] S3. Mapping path determination and change set retrieval steps: Determine the mapping path based on the access pattern feature vector. When the feature vector indicates that there is a hotspot area conflict in the mapping address space with an access density exceeding a preset threshold, split the current mapping path into parallel processing links. Retrieve the change set of the target block height in the incremental buffer based on the time-series hash identifier.

[0014] S4. Intermediate state pre-mapping and virtual state snapshot construction steps: Use the intermediate state buffer to temporarily store the pre-mapping data on each parallel processing link to generate the intermediate state mapping data structure; Apply the change set to reverse replay the current ledger state and construct the virtual state snapshot data structure corresponding to the voucher time sequence in memory.

[0015] S5. Two-way comparison and verification step: Obtain the execution confirmation signal from the destination through the feedback link, and align the confirmation signal with the intermediate state mapping data structure with the timestamp; compare the asset issuance volume in the virtual state snapshot data structure with the reserve value in the certificate, and output the verification result vector.

[0016] S6. Closed-loop feedback compensation step: Based on the verification result vector and timestamp alignment result, if the alignment difference exceeds the preset deviation window or the verification result indication is inconsistent, then perform state rollback; adjust the retention window length of the incremental buffer according to the access mode feature vector; output the compensated state mapping result.

[0017] As a preferred embodiment, the S1 state change and credential reception step further includes: capturing the original state change request through an asynchronous state reconstruction interface; calculating the conflict weight value based on the data coverage frequency of the state change request; and using the timestamp identifier as an anchor point for cross-system time alignment.

[0018] As a preferred embodiment, in the S2 runtime feature acquisition and verification strategy determination step: the runtime stack inside the system is continuously scanned by the runtime monitoring thread; the access mode feature vector is passed to the S3 mapping path determination and change set retrieval step through the cross-system coordination interface, and is used to adjust the retention window length of the incremental buffer.

[0019] As a preferred embodiment, in the S3 mapping path determination and change set retrieval step: the incremental buffer uses a differential storage mechanism to store the state difference mapping table between blocks; the S2 runtime feature acquisition and verification strategy determination step adjusts the retention window length of the incremental buffer according to the rate of change of the virtual machine program counter.

[0020] As a preferred embodiment, in the S5 bidirectional comparison and verification step: the timestamp alignment includes: logically matching the verification token carried by the destination execution confirmation signal with the time anchor field of the intermediate state mapping data structure; the logical comparison includes: reading the asset issuance quantity field in the virtual state snapshot data structure and comparing it with the reserve value of the certificate.

[0021] As a preferred embodiment, in the S6 closed-loop feedback compensation step: the state deviation is corrected through feedback compensation operation; the execution of state rollback includes: rolling back the state to a preset consistency checkpoint; the execution result of the closed-loop feedback compensation step is fed back to the S1 state change and credential reception step and the S3 mapping path determination and change set retrieval step through the closed-loop feedback channel, for adjusting the parameter configuration of the next round of processing.

[0022] As a preferred embodiment, the verification result vector includes: a verification Boolean value, used to indicate whether the verification passed; a logical deviation value, used to indicate the degree of numerical difference between the virtual state snapshot and the credential; and a reconstruction confidence score, used to indicate the credibility of the reconstruction of the virtual state snapshot.

[0023] This invention also provides a two-way state-mapping blockchain data verification system, comprising: The status change and credential receiving module is used to capture the original status change request initiated by the source end, assign a timestamp identifier and a conflict weight value calculated based on the data access frequency to the status change request; receive external reserve credentials, and extract the time-series hash identifier and reserve value of the credentials; The runtime feature acquisition and verification strategy determination module is used to scan the system runtime state, extract access pattern feature vectors, which reflect the access density distribution of the mapped address space; monitor the system runtime instruction sequence, and determine the current verification step size strategy. The mapping path determination and change set retrieval module is used to determine the mapping path based on the access pattern feature vector. When the feature vector indicates that there is a hotspot area conflict in the mapping address space with an access density exceeding a preset threshold, the current mapping path is split into parallel processing links. Based on the time-series hash identifier, the change set of the target block height is retrieved in the incremental buffer. The intermediate state pre-mapping and virtual state snapshot construction module is used to temporarily store pre-mapping data in the intermediate state buffer on each parallel processing link and generate an intermediate state mapping data structure; the change set is applied to reverse replay the current ledger state and construct a virtual state snapshot data structure in memory corresponding to the voucher time sequence; The bidirectional comparison and verification module is used to obtain the execution confirmation signal from the destination through the feedback link, align the confirmation signal with the intermediate state mapping data structure by timestamp; compare the asset issuance volume in the virtual state snapshot data structure with the reserve value in the certificate, and output the verification result vector. The closed-loop feedback compensation module is used to perform state rollback if the alignment difference exceeds a preset deviation window or the verification result indication is inconsistent, based on the verification result vector and the timestamp alignment result; adjust the retention window length of the incremental buffer according to the access mode feature vector; and output the compensated state mapping result.

[0024] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described bidirectional state-mapping blockchain data verification method.

[0025] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described bidirectional state-mapping blockchain data verification method.

[0026] Compared with the prior art, the beneficial effects of the present invention are as follows: First, this invention achieves a request-driven real-time verification triggering mechanism by capturing the original state change request initiated by the source and assigning a timestamp identifier. Compared with existing periodic auditing schemes, this invention can immediately start the verification process when a state change occurs, reducing the time delay of inconsistency detection from the audit cycle level to the request response level, which is beneficial to improving the real-time performance of verification.

[0027] Second, this invention constructs a virtual state snapshot data structure in memory corresponding to the voucher time sequence by applying a change set to the current ledger state for reverse replay. This reverse replay mechanism can accurately reconstruct the state at the target time point without completely replaying the block history from the genesis block, solving the technical problem of existing technologies being unable to efficiently trace back historical states for verification.

[0028] Third, this invention employs a two-way cross-validation process, simultaneously performing verification on two dimensions: timestamp alignment and numerical comparison. Timestamp alignment ensures that the data being compared belongs to the same logical point in time, while numerical comparison verifies the consistency of asset quantities. This two-way cross-validation mechanism generates a synergistic effect, effectively eliminating misjudgments caused by timing discrepancies in one-way verification.

[0029] Fourth, this invention achieves dynamic load balancing based on access density distribution by extracting access pattern feature vectors and splitting the mapping path into parallel processing links when hotspot conflicts are identified. Compared with existing fixed serial processing schemes, this invention can adaptively adjust the processing architecture according to runtime load characteristics, which is beneficial for improving system throughput in high-concurrency scenarios.

[0030] Fifth, this invention feeds back the verification results and execution status to the status change and credential reception steps and the mapping path determination and change set retrieval steps through a closed-loop feedback compensation step, forming a multi-point feedback closed-loop control architecture. This mechanism enables subsequent verifications to automatically adjust parameter configurations based on historical verification results, achieving adaptive optimization of the system.

[0031] Sixth, the present invention outputs a multi-dimensional verification result vector containing verification Boolean values, logic deviation values, and reconstruction confidence scores. Compared with the simple pass or fail output of the prior art, it provides richer verification diagnostic information, which facilitates subsequent processing and problem localization. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the overall process of the bidirectional state-mapping blockchain data verification method provided in the embodiments of the present invention; Figure 2 This is a schematic diagram of the module architecture of the bidirectional state-mapping blockchain data verification system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the process for constructing a virtual state snapshot through reverse replay provided in an embodiment of the present invention; Figure 4 This is an interactive schematic diagram of bidirectional comparison verification and closed-loop feedback compensation provided in an embodiment of the present invention.

[0033] Figure labeling: S1 to S6 represent the six steps of the method; 10 - State change and voucher reception module; 20 - Runtime feature acquisition and verification strategy determination module; 30 - Mapping path determination and change set retrieval module; 40 - Intermediate state pre-mapping and virtual state snapshot construction module; 50 - Bidirectional comparison and verification module; 60 - Closed-loop feedback compensation module; 31 - Incremental buffer; 41 - Intermediate state buffer; 42 - Change set; 43 - Current ledger state; 44 - Virtual state snapshot; 51 - Verification result vector; 61 - Feedback channel. Detailed Implementation

[0034] To enable those skilled in the art to better understand the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0035] This embodiment can be implemented on a server or terminal device configured with a general-purpose processor. The device includes: a processing unit, which may be a central processing unit, a graphics processing unit, or a dedicated neural network processor, for executing the steps of the method of the present invention; a storage unit, including non-volatile memory for storing program instructions and volatile memory for runtime data, wherein the capacity of the volatile memory should be no less than 16GB to meet the memory construction requirements of virtual state snapshots; and a communication unit, supporting a network interface with a TCP / IP protocol stack, for data interaction with blockchain nodes and external credential sources.

[0036] In terms of software environment, this method can run on mainstream operating systems such as Linux and Windows, and can be implemented using programming languages ​​such as Java, Go, Rust, and Python. It can also interact with the blockchain network using existing blockchain client SDKs. During implementation, embedded key-value databases such as LevelDB and RocksDB can be selected as the underlying storage engine for the incremental buffer. Example 1

[0037] like Figure 1 As shown, this embodiment uses the digital verification of warehouse receipts in supply chain finance as an application scenario to detail the complete implementation process of the two-way state-mapping blockchain data verification method. This scenario requires continuous verification of whether the digital warehouse receipt certificate on the blockchain is consistent with the physical warehousing information registered in the offline warehouse management system.

[0038] In step S1, status change and credential receipt, as follows: Figure 2 As shown, the status change and credential receiving module 10 performs two parts of processing: status change request capture and credential receiving.

[0039] In the state change request capture section, the original state change request initiated by the source end is captured through an asynchronous state reconstruction interface. In this embodiment, the asynchronous state reconstruction interface is implemented by subscribing to the event logs of blockchain nodes. When a warehouse receipt creation, warehouse receipt cancellation, or warehouse receipt transfer transaction occurs on the blockchain, the event listener captures the transaction immediately. After capturing the state change request, the state change and certificate receiving module 10 assigns a timestamp identifier to the request. This timestamp is generated using a hybrid logical clock algorithm, where the physical time part is taken from the local system clock, and the logical counter part is used to process the sorting of multiple events within the same physical moment. This timestamp identifier serves as an anchor point for cross-system time alignment. Then, based on the target address involved in the request, the data coverage frequency of that address within the most recent statistical window is queried, and the conflict weight value is calculated based on the following formula: the conflict weight value is equal to the number of times the address is accessed within the statistical window divided by the total number of times all addresses within the statistical window are accessed. The technical basis of this formula is that addresses with higher access frequencies are more likely to experience concurrent conflicts and need to be assigned higher processing priorities.

[0040] In the document receiving section, the status change and document receiving module 10 receives external reserve documents through a standardized API interface. In this embodiment, the document is periodically generated and signed by the warehouse management system, containing warehouse inventory information at a specific point in time, specifically covering fields such as goods category, quantity, batch number, and storage location. The status change and document receiving module 10 first verifies the digital signature of the document to confirm the authenticity of the document's source, then extracts the document's time-series hash identifier, which is obtained by applying the SHA-256 hash algorithm to the document content and concatenating it with the document's timestamp. Finally, it extracts the reserve value field recorded in the document.

[0041] In step S2, the feature acquisition and verification strategy determination step, such as Figure 2 As shown, the runtime feature acquisition and verification strategy determination module 20 performs two parts of processing: feature acquisition and verification strategy determination.

[0042] In the feature acquisition section, the runtime feature acquisition and verification strategy determination module 20 continuously scans the runtime stack inside the system through the runtime monitoring thread to extract access pattern feature vectors. The specific processing is as follows: First, the mapped address space is divided into 256 partitions of equal size, each partition corresponding to one dimension of the feature vector; then, within the statistical window (set to the last 60 seconds in this embodiment), the number of times each partition is accessed is counted; next, the access count of each partition is normalized, and the normalization formula is: the normalized density value of a partition is equal to the access count of that partition divided by the maximum value of the access count of all partitions; finally, partitions with normalized density values ​​exceeding the hotspot threshold (set to 0.8 in this embodiment) are marked as hotspots. The selection of this hotspot threshold is based on the fact that when the access density of a partition reaches more than 80% of the peak, continued accumulation of access will lead to significant processing delays, at which point path splitting should be triggered to distribute the load. The access pattern feature vector is passed to the mapping path determination and change set retrieval step S3 through the cross-system coordination interface to adjust the retention window length of the incremental buffer.

[0043] In the verification strategy determination section, the runtime feature acquisition and verification strategy determination module 20 monitors the system runtime instruction sequence to determine the current verification step size strategy. In this embodiment, the system load status is evaluated by monitoring the rate of change of the virtual machine program counter. The specific processing is as follows: First, the change in the virtual machine program counter within a fixed time interval is sampled; then, the rate of change is calculated, i.e., the number of instructions executed per unit time; next, the verification step size is determined based on the rate of change: when the rate of change is below the low load threshold, a fine-grained verification step size is used to improve verification accuracy; when the rate of change is above the high load threshold, a coarse-grained verification step size is used to reduce system overhead; and when the rate of change is in the middle range, a standard verification step size is used. Simultaneously, the program counter rate of change is also used to dynamically adjust the retention window length of the incremental buffer: a higher rate of change indicates more frequent state changes, requiring a longer retention window to cover more historical change sets.

[0044] In step S3, mapping path determination and change set retrieval, such as Figure 2 As shown, the mapping path determination and changeset retrieval module 30 performs two parts of processing: mapping path determination and changeset retrieval.

[0045] In the mapping path determination section, the mapping path determination and change set retrieval module 30 determines the mapping path based on the access pattern feature vector extracted in step S2. The specific determination logic is as follows: First, scan the hotspot marker array in the access pattern feature vector; then, count the number of partitions marked as hotspots; next, determine whether the number of hotspot partitions exceeds a preset threshold (set to 3 in this embodiment). If the number of hotspot partitions is greater than 3, it is determined that there is a conflict in hotspot areas that need to be processed separately, and path splitting is performed; otherwise, a single mapping path is maintained. The specific implementation of path splitting is as follows: Based on the address space distribution of hotspot partitions, the mapping path is split into multiple parallel processing links. Each link is responsible for processing one or more adjacent hotspot partitions. The number of links is equal to the smaller value between the number of hotspot partitions and the number of available parallel processing units. The splitting strategy adopts the address space continuity principle, that is, adjacent address partitions are assigned to the same link as much as possible to reduce the data interaction overhead during subsequent merging.

[0046] In the change set retrieval section, such as Figure 2 and Figure 3 As shown, the mapping path determination and change set retrieval module 30 retrieves the change set of the target block height in the incremental buffer based on the time-series hash identifier extracted in step S1. The incremental buffer uses a differential storage mechanism to store the state difference mapping table between blocks. Specifically, the incremental buffer uses LevelDB as the storage engine, storing the block height as the key and the change set serialization data of that block as the value. The change set only stores the incremental changes in state (value before and after the change), rather than a full state snapshot, which helps to reduce storage overhead. The retrieval process is as follows: First, the target block height is parsed based on the time-series hash identifier. This parsing is completed by querying the mapping index between the block hash and the block height. Then, the change set corresponding to the block height is queried in the incremental buffer by key. Next, the change set chain is traversed forward to collect all change sets from the target block to the current block, forming a change set sequence. The retention window length of the incremental buffer determines the historical depth that can be traced back. In this embodiment, the default reserved window is the change set of the most recent 1000 blocks, and the length of this window is dynamically adjusted according to the access mode feature vector and the program counter change rate in step S2.

[0047] In step S4, intermediate state pre-mapping and virtual state snapshot construction, as follows: Figure 2 and Figure 3 As shown, the intermediate state pre-mapping and virtual state snapshot construction module 40 performs two parts of processing: intermediate state pre-mapping and virtual state snapshot construction.

[0048] In the intermediate state pre-mapping section, the intermediate state pre-mapping and virtual state snapshot construction module 40 temporarily stores pre-mapping data in the intermediate state buffer on each parallel processing link, generating an intermediate state mapping data structure. For each parallel processing link split in step S3, the intermediate state pre-mapping and virtual state snapshot construction module 40 performs the following processing: First, it allocates an independent intermediate state buffer space for the link; then, based on the address space range that the link is responsible for, it filters out change records involving that range from the change set; next, it pre-maps the filtered change records to the intermediate state buffer, generating the intermediate state mapping data structure for the link, where the timing anchor field records the current mixed logic clock value, which is used for subsequent timestamp alignment with the destination acknowledgment signal.

[0049] In the virtual state snapshot construction section, such as Figure 3 As shown, the intermediate state pre-mapping and virtual state snapshot construction module 40 uses the change set retrieved in step S3 to reverse replay the current ledger state, constructing a virtual state snapshot data structure in memory corresponding to the voucher time sequence. The detailed processing logic of the reverse replay algorithm is as follows: First, the current ledger state is obtained as the starting point for reverse replay, which is read from the state database of the blockchain node; then, the change set sequence is traversed in descending order of block height. For each change record in each change set, a reverse operation is performed. If the original operation type is "add", then a "decrease" operation is performed, subtracting the difference between the changed value and the original value from the state value; if the original operation type is "decrease", then an "add" operation is performed, adding the original value to the state value. The difference between the original value and the changed value is used to directly restore the state value to the value before the change if the original operation type was "Set". Then, when traversing to the target block height, the reverse replay process stops. Finally, a reconstruction confidence score is calculated based on anomalies encountered during the reverse replay process. The initial value is 1.0; if an incomplete change record is encountered, 0.1 is deducted; if the original value does not match expectations, 0.2 is deducted; if the block height is discontinuous, 0.3 is deducted. The final score ranges from 0.0 to 1.0. After the replay is complete, the result is encapsulated into a virtual state snapshot data structure, where the asset issuance field is obtained by summing all account balances. The technical advantage of this reverse replay mechanism is that it eliminates the need to completely replay all block history from the genesis block; any historical state can be reconstructed simply by applying the differences from the current state. The time complexity is reduced from being proportional to the total number of blocks to being proportional to the number of backtracked blocks.

[0050] In step S5, the two-way comparison and verification step, such as Figure 4As shown, the bidirectional comparison and verification module 50 performs a bidirectional verification process. The first verification dimension is timestamp alignment. The bidirectional comparison and verification module 50 obtains the execution confirmation signal from the destination through the feedback link. This confirmation signal carries a verification token. The specific process of timestamp alignment is as follows: extract the timestamp carried by the verification token in the confirmation signal, extract the time anchor field in the intermediate state mapping data structure generated in step S4, compare the difference between the two timestamps, and if the difference is within the allowable clock deviation range (set to ±5 seconds in this embodiment), the timestamp alignment is determined to be successful; otherwise, the alignment deviation value is recorded. The second verification dimension is numerical comparison. The bidirectional comparison and verification module 50 reads the asset issuance volume field in the virtual state snapshot data structure constructed in step S4, compares it with the certificate reserve value extracted in step S1, and calculates the difference between the two as the logical deviation value. Finally, the verification results are encapsulated into a verification result vector output, including: a verification Boolean value (true when timestamp alignment is successful and the logical deviation is zero, otherwise false), a logical deviation value (on-chain warehouse receipt quantity minus off-chain inventory quantity), a reconstruction confidence score (inherited from step S4), and a timestamp alignment deviation value. The technical advantages of this two-way comparison verification mechanism are: timestamp alignment ensures that the on-chain data and off-chain vouchers participating in the comparison belong to the same logical point in time, eliminating misjudgments caused by asynchronous timing; numerical comparison verifies the consistency of specific values, and the two work together to form cross-validation, which helps improve the accuracy of the verification.

[0051] In step S6, the closed-loop feedback compensation step, such as Figure 4 As shown, the closed-loop feedback compensation module 60 performs closed-loop feedback compensation based on the verification result vector output in step S5. First, it determines whether state rollback is needed: if the timestamp alignment deviation exceeds the preset deviation window (set to 10 seconds in this embodiment), or the verification boolean value is false, then state rollback is performed. The selection of this deviation window threshold is based on the fact that a time deviation exceeding 10 seconds may cause state changes across multiple blocks, at which point the comparison result is no longer of reference value. The specific operation of state rollback is to roll back the state to a preset consistency checkpoint, which is the system state recorded when the last verification passed. Then, the retention window length of the incremental buffer is adjusted according to the access mode feature vector: if the feature vector shows an increase in the number of hot partitions, the retention window is extended to cover more historical changes; if the number of hot partitions decreases, the retention window is shortened to release storage resources. Finally, the adjustment signals are fed back to the state change and credential receiving module 10 and the mapping path determination and change set retrieval module 30 via the feedback channel: the signal fed back to the state change and credential receiving module 10 is used to adjust the calculation baseline of the conflict weights for the next round; the signal fed back to the mapping path determination and change set retrieval module 30 is directly used to adjust the parameter configuration of the incremental buffer. The compensated state mapping result is output as the final output of this round of verification.

[0052] In this embodiment, the recommended configurations for key parameters are as follows: feature vector dimension is 256, hotspot threshold is 0.8, hotspot partition number threshold is 3, statistical window duration is 60 seconds, default retention window length is 1000 blocks, timestamp alignment allowable deviation is 5 seconds, and state rollback deviation window is 10 seconds. These parameter values ​​are determined based on the typical operating characteristics of the blockchain system and can be adjusted according to actual application scenarios.

[0053] In this embodiment, the following handling methods are adopted for possible abnormal situations: when credential signature verification fails, the credential is discarded and an alarm log is recorded; when the change set does not exist, the current state is used as a snapshot and the confidence score is set to 0; when reverse replay fails, the failure position is recorded and a partial snapshot is calculated, while the confidence score is reduced; when timestamp alignment times out, local timestamps are used to continue processing and a warning is recorded; when memory is insufficient, incremental build mode is triggered for batch processing; when network connection is interrupted, a backup node is switched and pending requests are cached.

[0054] Those skilled in the art generally believe that obtaining the historical state of a blockchain should be done by replaying it forward from the genesis block, as this aligns with the natural execution order of the blockchain. However, this embodiment discovers that using a reverse replay approach can produce unexpected technical effects: by applying the inverse operation of the changeset from the current state, the state at any historical point in time can be reconstructed without traversing the entire block history, reducing the time complexity of state reconstruction from being proportional to the total number of blocks to being proportional to the number of backtracked blocks.

[0055] The combination of timestamp alignment and numerical comparison in step S5 is not a simple superposition, but rather produces a synergistic effect: timestamp alignment ensures that the on-chain virtual snapshots and off-chain reserve certificates participating in the comparison have been calibrated to the same logical point in time before numerical comparison is performed, eliminating the "false inconsistency" problem caused by time synchronization; numerical comparison verifies the specific values ​​based on time calibration, ensuring that the "real inconsistency" problem is not overlooked.

[0056] This embodiment effectively solves the five technical problems mentioned in the background technology: the problem of insufficient real-time performance of periodic audits is solved by a request-driven real-time capture mechanism; the problem of the inability to reconstruct historical states is solved by constructing virtual snapshots through reverse replay; the problem of one-way verification being interfered with by timing deviations is solved by a collaborative mechanism of two-way comparison verification; the problem of performance bottlenecks in fixed process concurrency is solved by parallel processing of dynamic path splitting; and the problem of lack of closed-loop feedback optimization is solved by a multi-point feedback compensation mechanism. Example 2

[0057] like Figures 1 to 4As shown, this embodiment uses the digital verification of carbon emission rights as an application scenario to explain in detail the implementation process of the two-way state-mapping blockchain data verification method. This scenario requires continuous verification of whether the carbon emission allowances registered on the blockchain are consistent with the certified emission reduction certificates issued by offline carbon emission verification agencies.

[0058] In step S1, the state change and certificate receiving module 10 captures the original state change request initiated by the source end through the asynchronous state reconstruction interface. In this embodiment, when a carbon quota registration, carbon quota cancellation, or carbon quota transfer transaction occurs on the blockchain, the event listener immediately captures the transaction. The state change and certificate receiving module 10 assigns a timestamp identifier and a conflict weight value to the request. Simultaneously, it receives external reserve certificates, which are periodically generated and signed by carbon emission certification authorities and contain certified emission reduction information at a specific point in time, specifically covering fields such as project number, emission reduction tonnage, certification period, and certification authority identifier. After verifying the digital signature of the certificate, the time-series hash identifier and reserve value field are extracted.

[0059] In step S2, the runtime feature acquisition and verification strategy determination module 20 uses an exponential moving average algorithm to extract the access pattern feature vector. Unlike Example 1, this example applies a time decay factor to the number of accesses, giving more weight to recent accesses. The specific calculation formula is: the current density value of a partition is equal to 0.7 multiplied by the density value of the partition in the previous period plus 0.3 multiplied by the number of new accesses to the partition in the current period. The choice of the decay factor 0.7 is based on the fact that the access patterns in the carbon trading market exhibit periodic fluctuations, and using an exponential moving average can more accurately reflect the current access intensity. Simultaneously, the system runtime instruction sequence is monitored to determine the current verification step size strategy, employing the same processing logic as in Example 1.

[0060] In step S3, the mapping path determination and change set retrieval module 30 uses a load balancing principle for path splitting in the mapping path determination part. Unlike the address space continuity principle in Embodiment 1, this embodiment splits paths according to the estimated processing load of each hotspot partition. The specific processing procedure is as follows: First, calculate the cumulative access volume of each hotspot partition within the statistical window; then, sort the hotspot partitions from highest to lowest access volume; next, use a greedy algorithm to allocate the hotspot partitions to each parallel processing link, minimizing the total load difference between each link. In the change set retrieval part, a checkpoint optimization strategy is adopted: a state checkpoint is saved every 500 blocks. During reverse replay, the checkpoint closest to the target time point is located first, and backtracking begins from that checkpoint. The selection of this checkpoint interval is based on the fact that 500 blocks roughly correspond to the state change volume of one trading day in the carbon trading system, achieving a balance between storage overhead and backtracking efficiency.

[0061] In step S4, the intermediate state pre-mapping and virtual state snapshot construction module 40 temporarily stores pre-mapping data in the intermediate state buffer on each parallel processing link, generating an intermediate state mapping data structure, and adopting the same processing logic as in Example 1. In the virtual state snapshot construction part, the replay starts from the checkpoint state in reverse, rather than starting from the current ledger state, reducing the number of change sets that need to be processed. After the replay is completed, the total carbon allowance field in the virtual state snapshot is obtained by summing the carbon allowance balances of all accounts.

[0062] In step S5, the two-way comparison and verification module 50 performs the two-way verification process. This embodiment sets the allowed deviation for timestamp alignment to 3 seconds, which is more stringent than in embodiment one. The logical deviation value is calculated as: total on-chain carbon quota minus off-chain certified emission reductions.

[0063] In step S6, the closed-loop feedback compensation module 60 performs closed-loop feedback compensation. In this embodiment, the state rollback deviation window is set to 6 seconds, and the confidence deduction items are increased as follows: 0.15 for incomplete change records, 0.3 for values ​​before change not matching expectations, and 0.4 for discontinuous block heights.

[0064] In this embodiment, the key parameters are configured as follows: the attenuation factor is 0.7, the hotspot threshold is 0.75, the checkpoint interval is 500 blocks, the timestamp alignment allowable deviation is 3 seconds, and the state rollback deviation window is 6 seconds.

[0065] The aforementioned state change and certificate receiving module 10, runtime feature acquisition and verification strategy determination module 20, mapping path determination and change set retrieval module 30, intermediate state pre-mapping and virtual state snapshot construction module 40, bidirectional comparison and verification module 50, and closed-loop feedback compensation module 60 are implemented by computer programs stored in memory and loaded and executed by the processor. In the specific deployment of this embodiment, an FPGA hardware accelerator is used to accelerate the reverse replay step to meet the high throughput requirements of the carbon trading system. Example 3

[0066] This embodiment provides a computer device and a computer-readable storage medium.

[0067] The computer device includes a memory and a processor. The memory stores the computer program and can be a volatile or non-volatile storage medium such as random access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD), or hard disk drive (HDD). The processor can be an electronic component with data processing capabilities such as a central processing unit (CPU), graphics processing unit (GPU), field-programmable gate array (FPGA), or application-specific integrated circuit (ASIC). In this embodiment, the memory stores a computer program implementing the above-described bidirectional state-mapping blockchain data verification method. The processor is communicatively connected to the memory. When the processor executes the computer program, it implements all the steps of the above-described bidirectional state-mapping blockchain data verification method, including: S1 state change and credential reception step, S2 runtime feature acquisition and verification strategy determination step, S3 mapping path determination and change set retrieval step, S4 intermediate state pre-mapping and virtual state snapshot construction step, S5 bidirectional comparison verification step, and S6 closed-loop feedback compensation step.

[0068] The computer-readable storage medium can be a non-transitory computer-readable storage medium, including but not limited to: USB flash drives, portable hard drives, optical discs (CD-ROMs), digital video discs (DVDs), Blu-ray discs, magnetic tapes, floppy disks, solid-state drives (SSDs), hard disk drives (HDDs), flash memory cards, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and any other medium capable of storing computer program code. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements all the steps of the aforementioned bidirectional state-mapping blockchain data verification method.

[0069] In one specific implementation, the computer device may be a server, a personal computer, a workstation, or an embedded device. The server may be a single physical server, or a server cluster or distributed system consisting of multiple physical servers. The computer device may also include a communication interface for data communication with blockchain network nodes and external credential sources, and the communication interface supports communication protocols such as TCP / IP, HTTP / HTTPS, and WebSocket.

[0070] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing the present invention, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A bidirectional state-mapping blockchain data verification method, characterized in that, Includes the following steps: S1. Status Change and Credential Receipt Steps: Capture the original status change request initiated by the source end, assign a timestamp identifier and a conflict weight value calculated based on the data access frequency to the status change request; receive external reserve credentials, and extract the time-series hash identifier and reserve value of the credentials; S2. Runtime Feature Acquisition and Verification Strategy Determination Steps: Scan the system runtime state, extract access mode feature vectors, the feature vectors reflecting the access density distribution of the mapped address space; monitor the system runtime instruction sequence, and determine the current verification step size strategy; S3. Mapping path determination and change set retrieval steps: Determine the mapping path based on the access pattern feature vector. When the feature vector indicates that there is a hotspot area conflict in the mapping address space with an access density exceeding a preset threshold, split the current mapping path into parallel processing links. Retrieve the change set of the target block height in the incremental buffer based on the time-series hash identifier. S4. Intermediate state pre-mapping and virtual state snapshot construction steps: The intermediate state buffer is used to temporarily store the pre-mapping data on each parallel processing link to generate the intermediate state mapping data structure; The change set is applied to reverse replay the current ledger state to construct the virtual state snapshot data structure corresponding to the voucher time sequence in memory; S5. Two-way comparison and verification step: Obtain the execution confirmation signal from the destination through the feedback link, and align the confirmation signal with the intermediate state mapping data structure with the timestamp; compare the asset issuance volume in the virtual state snapshot data structure with the reserve value in the certificate, and output the verification result vector; S6. Closed-loop feedback compensation step: Based on the verification result vector and timestamp alignment result, if the alignment difference exceeds the preset deviation window or the verification result indication is inconsistent, then perform state rollback; adjust the retention window length of the incremental buffer according to the access mode feature vector; output the compensated state mapping result.

2. The method according to claim 1, characterized in that, The S1 status change and credential reception step also includes: The original state change request is captured through the asynchronous state reconstruction interface; The conflict weight value is calculated based on the data coverage frequency of the state change request; The timestamp identifier serves as an anchor point for cross-system timing alignment.

3. The method according to claim 1, characterized in that, In the S2 runtime feature acquisition and verification strategy determination step: The runtime monitoring thread continuously scans the runtime stack inside the system; The access pattern feature vector is passed to the S3 mapping path determination and change set retrieval step through the cross-system coordination interface, and is used to adjust the retention window length of the incremental buffer.

4. The method according to claim 1, characterized in that, In the S3 mapping path determination and changeset retrieval steps: The incremental buffer uses a differential storage mechanism to store a state difference mapping table between blocks; The S2 runtime feature acquisition and verification strategy determination step adjusts the retention window length of the incremental buffer according to the rate of change of the virtual machine program counter.

5. The method according to claim 1, characterized in that, In the S5 two-way comparison and verification step: The timestamp alignment includes: logically matching the verification token carried by the destination execution confirmation signal with the time anchor field of the intermediate state mapping data structure; The logical comparison includes: reading the asset issuance volume field in the virtual state snapshot data structure and comparing it with the reserve value of the certificate.

6. The method according to claim 1, characterized in that, In the S6 closed-loop feedback compensation step: The state deviation is corrected through feedback compensation operations; The execution state rollback includes: reverting the state to a preset consistency checkpoint; The execution result of the closed-loop feedback compensation step is fed back to the S1 state change and credential reception step and the S3 mapping path determination and change set retrieval step through the closed-loop feedback channel, so as to adjust the parameter configuration for the next round of processing.

7. The method according to claim 1, characterized in that, The verification result vector includes: A validation boolean value used to indicate whether the validation passed; The logical deviation value is used to indicate the degree of numerical difference between the virtual state snapshot and the voucher; The reconstruction confidence score is used to indicate the degree of confidence in the reconstruction of the virtual state snapshot.

8. A two-way state-mapping blockchain data verification system, characterized in that, include: The status change and credential receiving module is used to capture the original status change request initiated by the source end, assign a timestamp identifier and a conflict weight value calculated based on the data access frequency to the status change request; receive external reserve credentials, and extract the time-series hash identifier and reserve value of the credentials; The runtime feature acquisition and verification strategy determination module is used to scan the system runtime state, extract access pattern feature vectors, which reflect the access density distribution of the mapped address space; monitor the system runtime instruction sequence, and determine the current verification step size strategy. The mapping path determination and change set retrieval module is used to determine the mapping path based on the access pattern feature vector. When the feature vector indicates that there is a hotspot area conflict in the mapping address space with an access density exceeding a preset threshold, the current mapping path is split into parallel processing links. Based on the time-series hash identifier, the change set of the target block height is retrieved in the incremental buffer. The intermediate state pre-mapping and virtual state snapshot construction module is used to temporarily store pre-mapping data in the intermediate state buffer on each parallel processing link and generate an intermediate state mapping data structure; the change set is applied to reverse replay the current ledger state and construct a virtual state snapshot data structure in memory corresponding to the voucher time sequence; The bidirectional comparison and verification module is used to obtain the execution confirmation signal from the destination through the feedback link, align the confirmation signal with the intermediate state mapping data structure with the timestamp; compare the asset issuance volume in the virtual state snapshot data structure with the reserve value in the certificate, and output the verification result vector. The closed-loop feedback compensation module is used to perform state rollback if the alignment difference exceeds a preset deviation window or the verification result indication is inconsistent, based on the verification result vector and the timestamp alignment result; adjust the retention window length of the incremental buffer according to the access mode feature vector; and output the compensated state mapping result.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images