An integral auditable evidence storage and tracing system and method based on evidence storage cycle closed verification

Abstract

The application discloses an integral auditable evidence and tracing system and method based on a closed verification of an evidence period, and aims at solving the problems of performance bottleneck, privacy leakage and non-active member state which cannot be verified by cryptography caused by the coupling of integral balance and transaction evidence. A commitment-state separation architecture is adopted, a high-performance balance library is maintained in a business layer to guarantee millisecond-level response, and an evidence layer does not store integral balance. A member is taken as a unit, a change transaction sequence is chained and hashed, and a member-level transaction sequence commitment hash is generated. A global anchoring module adopts an inert reading and incremental snapshot strategy to construct a cryptographic accumulator, and completes the closure of the evidence period. A transaction sequence forced distribution mechanism is integrated to ensure that the clear data is independently acquired without depending on a business party. Through a cryptographic negative verification method, it is proved that no transaction occurs for the non-active member within a specific period. The application completely decouples the evidence cost and the member scale, and provides a cryptographic independent verification of integral security commitment for all merchants.

Description

Technical Field

[0001] This invention belongs to the field of blockchain and cryptography technology, specifically relating to an integral auditable evidence storage system and method based on a closed-loop verification mechanism for evidence storage period and integrating zero-knowledge proof privacy verification function. Background Technology

[0002] In traditional enterprise-level points systems, points data is stored in centralized databases, posing a significant risk of unilateral tampering by internal personnel or external attackers. Members cannot effectively verify the authenticity and integrity of their points assets. This problem presents a polarized dilemma for merchants of different sizes: large enterprises, while capable of deploying complex security solutions, face performance and cost challenges due to their massive membership base; while small and micro-sized merchants, lacking technical capabilities and credit backing, have points systems that are virtually devoid of credibility.

[0003] Existing blockchain-based evidence storage solutions are mainly divided into two categories. The first category is to directly submit each points transaction to the chain. Although it can achieve single-transaction-level evidence storage, it is limited by the extremely low throughput and high cost of public chains, as well as the data expansion pressure of consortium chains, and cannot support the daily points transaction scenarios of millions of members and high concurrency. The second category is to adopt the "daily balance snapshot on-chain" mode, which only performs a snapshot of the daily points balance for evidence storage. Although this solution has extremely low cost, it has fatal flaws: (1) It cannot trace and verify the details and order of a specific points transaction during the day; (2) The balance plaintext is directly stored on the chain or in the evidence storage path, which may leak member privacy; (3) The system can only prove the hash of the daily state, and cannot prove that the state is legally derived from a series of real, complete, and tamper-proof original transaction sequences.

[0004] Moreover, existing solutions, when employing performance optimization strategies such as lazy reading, generally suffer from a technical flaw that has been overlooked in the field for a long time: when the system skips reading inactive member data for the sake of performance, the independent verifier will not be able to cryptographically prove that the member has not actually made any transactions within a specific time period, thus creating a logical break in the verification path.

[0005] It should be noted that although techniques such as non-membership proofs and zero-knowledge proofs have been publicly disclosed as fundamental protocols in the field of cryptography, they are generally considered as independent cryptographic primitives. Prior to the system architecture proposed in this invention, those skilled in the art had neither the motivation nor the technical inspiration to introduce non-membership proofs into a large-scale, high-performance, lazy-read optimized evidence storage system to solve the specific technical problem of "inactive state cryptographic verification logic breakage" caused by system performance optimization. This invention is not a simple application of known cryptographic tools, but rather a creative integration of them into a specific system framework and workflow, thereby synergistically generating a novel, cryptographically complete, auditable data state capability. Summary of the Invention

[0006] The technical problem to be solved by the present invention The purpose of this invention is to provide an auditable, verifiable, and traceable system and method for points-based evidence storage, in order to solve the following technical problems: (1) How to provide a tamper-proof mechanism for massive points transaction data that is cost-constant, independent of the integrity of the centralized party, and cryptographically verifiable, while ensuring the millisecond-level high-concurrency response performance of the points business? (2) How to fill the logical break in the cryptographic verification path caused by the lazy read optimization strategy, which is that "inactive states cannot be independently proven", so that the verification of integral balance at any historical point in time has cryptographic completeness? (3) How to provide independently verifiable historical audit capabilities while protecting the privacy of members' transaction details? Technical solution

[0007] The core of this invention is the innovative proposal of a "commitment-state separation architecture" and a "proof-of-existence period closed verification" mechanism. The design philosophy of this architecture lies in "separating concerns"—completely decoupling the frequently changing business state from the low-frequency anchored cryptographic commitment, making the proof-of-existence cost a fixed constant that is only related to the proof-of-existence period, rather than a variable related to the number of transactions or members.

[0008] The system is composed of the following modules working together: The online points service module, acting as a "speed layer" for members, is responsible for handling high-concurrency points consumption and queries, and internally maintains a high-performance real-time balance status database. After each points change operation is completed, the module immediately returns the operation result to the caller, ensuring millisecond-level business response.

[0009] The points transaction cryptographic evidence storage module, serving as the system's "security layer," adheres to the core principle of never accessing or storing any points balance. Whenever a points change record (containing only metadata such as the change amount, timestamp, and unique voucher number) is received asynchronously from the business layer, a new commitment hash is calculated using a chained cryptographic hash function, starting from the commitment hash of the member's previous transaction. There is no synchronous waiting relationship between the push notification and the return of the points consumption operation result, decoupling business response latency from cryptographic computation latency.

[0010] The process of generating the member-level transaction sequence commitment hash is as follows: Obtain the member's initial state commitment hash H0 at the beginning of this notarization period; when the nth change transaction Tx is generated... n When calculating the hash H of the nth commitment. n = Hash(H n ₋1 ∥Tx n .delta ∥ Tx n .timestamp ∥ Tx n .nonce); the final H n This is the commitment hash of the member-level transaction sequence.

[0011] The asynchronous update consistency monitoring module, integrated within the online points service module, maintains a pending confirmation push queue and listens for update confirmations returned by the points transaction cryptographic notarization module. It detects and records any abnormal events where the commitment hash update fails to complete successfully. When an update failure is detected, a retry is performed according to a preset retry strategy (such as exponential backoff). If the retry still fails, an exception ticket is generated, and a manual compensation process is triggered to ensure that the business status and the notarization status are eventually consistent.

[0012] Transaction Sequence Mandatory Distribution Module: This is a crucial module ensuring the availability of independent verification data. Before the notarization period closes, this module encrypts the complete sequence of point changes and the corresponding cryptographic proof path, storing it in a decentralized storage network or sending it to the member's client. This mechanism ensures that independent verifiers can obtain the complete data required for verification without relying on the online points service module (i.e., the points issuer), fundamentally solving the problem of data withholding that hinders verification.

[0013] Global anchoring module and blockchain storage adaptation layer: at the end of the preset storage period, all members who have occurred transaction changes and their member level transaction sequence commitment hash are taken as data leaves to construct a Merkle Patricia tree, and a global storage root hash is calculated. The leaf nodes of the Merkle tree only contain member identification and commitment hash, and do not contain any plaintext or ciphertext information of integral balance. The blockchain storage adaptation layer constructs the global storage root hash into a standard storage transaction and submits it to the storage network to obtain blockchain consensus confirmation and complete the storage period closure.

[0014] To cope with the continuous growth of the member scale, the system supports dynamic adjustment of the number of shards. The system continuously monitors the number of members and the computing load of each computing shard. When the member scale of a single shard exceeds the preset threshold, a shard splitting operation is automatically triggered to split the shard into multiple sub-shards, and each sub-shard independently assumes part of the member data of the original shard. When the member scale is reduced, resulting in multiple shard loads continuously below the lower threshold, the system automatically performs a shard merging operation to combine adjacent shards to reduce resource occupation. By introducing the virtual node mechanism of the consistent hashing algorithm, the change in the number of shards only affects local data distribution, avoiding the large-scale migration overhead caused by full data resharding, and ensuring that the system continuously maintains the load balancing of each shard without interrupting service.

[0015] To cope with the performance challenges of the billion-member scale, the global anchoring module uses incremental snapshots and lazy reading strategies when constructing the Merkle tree: for active members who have occurred transactions in the current period, read their latest commitment hash and participate in tree construction; for inactive members, directly reuse the subtree root hash value of the last period. Through this strategy, the computational complexity of the end-of-day tree construction is reduced from O(total number of members) to O(active number of members).

[0016] Cryptographic negation verification path of inactive members: this is the key technical means of the invention to solve the verification logic break introduced by the lazy reading strategy. When verifying the integral balance of an inactive member at a specific historical point in time, the verifier first verifies the integral balance of the member at the time of the last transaction, then obtains the global storage root hash of all storage periods between the end of the storage period of the last transaction of the member and the specific historical point in time, and inputs the member identification to verify that the member does not exist in the corresponding non-empty leaf node in the Merkle Patricia tree of all these storage periods, thereby proving that the member did not occur any transaction during the period.

[0017] Off-chain independent verification module: provides fully decentralized verification capability. After the evidence storage period is closed, anyone can obtain the total change sequence and Merkle proof path of a member through the transaction sequence forced distribution module or other legal means, and then independently recalculate the total change amount on a lightweight device, obtain the balance at any point in time, recalculate the final commitment, recalculate the Merkle root, and compare it with the root publicly available on the chain, all with zero trust. Advantages

[0018] (1) Security properties based on cryptographic primitives with clear security boundaries: The tamper-proofing guarantee of the system is based on the collision resistance of the hash function and the tamper-proofing of the blockchain, two cryptographic primitives. Its security properties can be decomposed into several independently verifiable cryptographic propositions.

[0019] (2) Cryptographically complete inactive state verification: The cryptographic negative proof method complements the lazy reading strategy, and the logical break in the verification path makes the integral balance verification at any historical point in time complete in cryptography.

[0020] (3) Engineering optimization of business performance and security: The response delay of integral consumption is completely dependent on the database performance (milliseconds), and is completely decoupled from the cryptographic computation and blockchain confirmation delay.

[0021] (4) Constant evidence storage cost and scale decoupling: Only a single transaction is stored on the chain each day, and the cost is constant, completely decoupled from the member size and transaction volume.

[0022] (5) Independent verification data can be forced to obtain: Through the transaction sequence forced distribution module, the verifier can obtain the complete data required for verification without relying on the cooperation of the integral issuer, ensuring the implementability of independent verification from the architectural level.

[0023] (6) Engineering feasibility of privacy protection verification: The incremental proof generation mechanism reduces the computational complexity of zero-knowledge proof from O(n) to O(k), making millisecond-level verification on lightweight terminals an explicit goal that can be achieved in engineering.

[0024] (7) Architecture universality of technology equalization: The architecture of the present application enables small and micro merchants to provide their members with cryptographic verification of integral security commitments at a negligible cost, which is equivalent to large enterprises in terms of cryptographic verification, and fundamentally solves the industry pain point of lack of public credibility in their integral system.

[0025] It should be noted that although the present application provides public chain adapters and consortium chain adapters through the blockchain evidence storage adaptation layer, it can be compatible with multiple heterogeneous distributed ledger networks, but from the perspective of maximizing the beneficial effects of the present application, the selection of the evidence storage network has the following considerations: One of the core innovations of the present application is that any third party can complete the cryptographic verification of the balance of points without relying on the point issuing party through an off-chain independent verification module. The realization of this capability relies on the public availability and non-tamperability of the global storage root hash on the storage network.

[0026] In the public chain (non-permissioned chain) scenario, the storage network is maintained by thousands of independent nodes distributed globally, and the consensus mechanism based on cryptography economics ensures the non-tamperability of the historical record, and anyone can query the on-chain data without authorization. This is most consistent with the design philosophy of the present application "decentralized independent verification", which can provide the highest strength of storage security protection that is not controlled by a single organization for small and micro merchants and end users.

[0027] In the consortium chain scenario, the nodes of the storage network are maintained by specific consortium members, and the query interface may need to be authorized. Therefore, when selecting a consortium chain as the storage network, in order to ensure that the beneficial effects of the present application are fully realized, it should be ensured that the consortium chain has a sufficient number of consensus nodes managed independently to avoid a single party controlling the majority of nodes; it provides a public, non-authorized query interface to support off-chain independent verification by any third party.

[0028] The specific embodiments of the present application are described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 : System overall module diagram of the present application "separation of commitment-state architecture" (including transaction sequence forced distribution module).

[0030] Figure 2 : Chain generation process diagram of member-level transaction sequence commitment hash.

[0031] Figure 3 : Storage cycle closure and global anchoring flowchart.

[0032] Figure 4 : Schematic diagram of the cryptographic negative verification path of non-active members.

[0033] Figure 5 : Privacy protection verification flowchart based on incremental proof generation.

[0034] Figure 6 : Architecture diagram of billion-scale hierarchical aggregation Merkle tree construction and sharding parallel processing DETAILED DESCRIPTION

[0035] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be noted that the following embodiments are only for explaining the invention and are not intended to limit the scope of protection of the invention.

[0036] Example 1: An independent boutique coffee shop with hundreds of members This embodiment aims to demonstrate that the same system architecture can serve very small-scale merchants without any custom development.

[0037] Simplified Deployment and Periodic Initialization: The café can directly use the SaaS service provided by the system operator, or deploy it lightly on a cloud server with minimal configuration. The system creates accounts for members, with the storage period set to daily. When a new member registers, the system generates a genesis state commitment hash for them.

[0038] Low-concurrency yet equally secure daytime transaction verification: During the day, members purchase coffee and accumulate points via a mini-program. Point changes for each transaction are updated asynchronously and non-blockingly in the background using a chained hash mechanism. For both the coffee shop and members, the transaction experience is identical to a regular points system, with response times remaining in the millisecond range.

[0039] End-of-day anchoring and data distribution: During the daily business off-peak period, the system constructs a Merkle tree from the final commitment hashes of members who made transactions that day, calculates the global proof root hash, and submits it to the blockchain. Simultaneously, the transaction sequence mandatory distribution module encrypts the day's change sequence and proof path, and distributes them to the decentralized storage network.

[0040] Lightweight serverless verification: Members or any third party can independently complete the verification process by obtaining data from the decentralized storage network and using open-source verification tools, without having to trust any centralized database of the coffee shop.

[0041] Example 2: A large frequent flyer program with millions of members System Deployment and Periodic Initialization: Deploy the online business service cluster and the cryptographic evidence storage service cluster. Set daily off-peak periods as the dividing points for regular evidence storage cycles.

[0042] Instantaneous daytime consumption and asynchronous evidence storage: Members redeem airline tickets using points. After the system completes the real-time deduction and returns a success message, it asynchronously pushes the change record to the evidence storage module, recursively updating its commitment hash using the SM3 hash algorithm. When the asynchronous update consistency monitoring module detects a push failure, it retryes according to the exponential backoff strategy; if it still fails after exceeding the maximum number of retries, it generates an exception ticket to notify the operations and maintenance personnel.

[0043] Dual-mode verification after closure: After the evidence storage period is closed, high-frequency members can use the lightweight threshold verification mode to prove that the points balance meets the redemption conditions using Bulletproofs, thus protecting their privacy; the auditing institution can use the full audit verification mode to obtain the complete transaction sequence, recalculate and verify the precise balance at any historical point in time.

[0044] Example 3: A national-level super app points system with hundreds of millions of members This embodiment aims to demonstrate that when facing a membership scale of hundreds of millions, the core architectural logic remains completely unchanged, and the cost of evidence preservation remains constant.

[0045] Scale and Challenges: A certain super app has hundreds of millions of registered users, and the number of transactions involving points changes daily is extremely considerable.

[0046] Sharded Parallel Computation and Lazy Read Anchoring: The cryptographic evidence storage cluster allocates multiple computation shards based on member ID hash values. The number of shards is not fixed but dynamically adjusted according to the actual member scale. When the system detects that the number of members in a shard exceeds a preset limit, it automatically performs shard splitting; when the member scale decreases, resulting in low resource utilization of multiple adjacent shards, it performs shard merging. Through consistent hashing virtual node technology, shard changes only affect the data distribution of adjacent shards, avoiding full data redistribution and ensuring uninterrupted service during elastic scaling. Each shard independently and in parallel computes the transaction sequence commitment hash of members. At the end of the day, the global anchoring module uses incremental snapshots and a lazy read strategy to construct Merkle subtrees only for active members in the current period. For inactive members, the root hash value of the subtree from the previous period is directly reused. Finally, the upper-level Merkle tree is constructed from the subroots of each shard to calculate the global evidence storage root hash.

[0047] Negative verification of inactive members: When a member who has not logged in for a long time needs to verify their historical points, the verifier checks the Merkle Patricia tree of all periods after the most recent transaction one by one according to the cryptographic negative verification path. There are no non-empty leaf nodes of the member, thus completely proving that the member's points balance has not changed during the period.

[0048] Constant-cost on-chain submission: The blockchain adaptation layer submits a unique global root hash to the chain. For a super app with hundreds of millions of members, the daily cost of on-chain verification is almost identical to that of a small coffee shop with a hundred members, remaining a fixed fee for each transaction per day.

[0049] As can be seen from the three extreme examples above, the "commitment-state separation architecture" and "proof-of-existence cycle closed verification" mechanism of this invention truly achieves flexible adaptation across scales. Whether it's a small independent store with hundreds of employees, an aviation giant with millions of users, or a national platform with hundreds of millions of users, all can obtain the same strength of cryptographically verifiable points security at extremely low cost. Its transaction sequence forced distribution mechanism, negative verification path, and dual-mode privacy verification features further ensure the system's comprehensive leadership in data availability, verification completeness, and user experience.

Claims

1. An integrally auditable evidence storage and traceability system based on closed-loop verification of the evidence storage period, characterized by: An online points service module is used to maintain a high-performance business status database (which contains members' current points balances) and process points consumption and balance query requests in real time. After each points change operation is completed, the operation result is immediately returned to the caller. A cryptographic evidence storage module for points transactions is provided. This module does not store any member's points balance and maintains an asynchronous, loosely coupled communication relationship with the online points business service module. The module is configured as follows: within a preset storage period, for each member who has a transaction, starting with the member's initial state commitment hash, the core metadata of all points change transactions generated chronologically within that period is used as input. A chained cryptographic hash function is then used to generate a unique commitment, namely, a member-level transaction sequence commitment hash of the complete change sequence. This core metadata includes at least the change amount, timestamp, and unique transaction voucher number. A global anchoring module is used to construct a cryptographic accumulator and calculate a global evidence root hash at the end of the evidence storage period, using the member-level transaction sequence commitment hash of all members who have undergone transaction changes as data leaves; A blockchain evidence storage adaptation layer is used to construct a standard evidence storage transaction that conforms to the evidence storage network protocol from the global evidence storage root hash, and submit the evidence storage transaction to the evidence storage network to obtain blockchain consensus confirmation. An asynchronous update consistency monitoring module is integrated into the online points business service module. It maintains a pending confirmation push queue and listens for update confirmations returned by the points transaction cryptographic evidence storage module. It detects and records any abnormal events that fail to successfully complete the commitment hash update. A transaction sequence forced distribution module is used to encrypt and store the complete points change transaction sequence and the corresponding cryptographic proof path in a decentralized storage network or send it to the member client before the notarization period closes, so as to ensure that independent verifiers can obtain the data required for verification without relying on the online points business service module. An off-chain independent verification module is used to provide independent verification services that do not rely on the online points business service module after the end of the evidence storage period and after the global evidence storage root hash is confirmed by the blockchain consensus of the evidence storage network. Its characteristic is that it achieves verifiable tamper-proof protection after the evidence storage period is closed through the following structural relationship: The points transaction cryptographic evidence storage module receives change transaction records asynchronously pushed from the online points business service module. There is no synchronous waiting relationship between this push and the return of the points consumption operation result, so that the response delay of points consumption is decoupled from the computation delay of cryptographic commitment. During the notarization period, there is an asynchronous update delay window between a business record of a points change transaction and its corresponding cryptographic commitment hash. The asynchronous update consistency monitoring module detects and records any abnormal events that fail to successfully complete the commitment hash update within this window. The evidence storage period ends when the global evidence root hash is finally confirmed on the evidence storage network. Any alteration to the points transaction records or balance data that occurred before the closure of the evidence storage period will inevitably lead to a cryptographic inconsistency among the following three elements. This inconsistency can be independently detected by any third party that has obtained the complete change sequence and related proof path through the transaction sequence forced distribution module or other legitimate means, using an off-chain independent verification module: (a) Membership-level transaction sequence commitment hash recalculated using tampered data; (b) The global proof root hash is derived based on the commitment hash and the cryptographic accumulator proof path; (c) The global root hash of the evidence has been confirmed by consensus on the evidence storage network and is publicly verifiable.

2. The system according to claim 1, characterized in that, The off-chain independent verification module employs an incremental proof generation mechanism based on transaction sequence stability when performing privacy-preserving verification based on zero-knowledge proofs, in order to adapt to lightweight terminal devices with limited computing resources. Incremental proof generation mechanisms include: When the lightweight terminal device is idle, the off-chain independent verification module selects a historical prefix part of a transaction sequence in the background, whose evidence storage period has been closed and has been confirmed by blockchain consensus, and which will not change. It pre-calculates the chain hash calculation and Merkle path calculation of the prefix part, and generates and caches an intermediate proof state. The intermediate proof state includes: the intermediate value of the chained commitment hash corresponding to the historical prefix part, and the Merkle path proof from the intermediate value to the global proof root hash; When real-time verification is required, it is only necessary to start from the cached intermediate proof state and perform chain hash calculation and proof generation on the incremental part of the new transactions since the last pre-calculation, thereby reducing the computational complexity of a single verification from O(n) to O(k), where n is the total number of all historical transactions of the member, k is the number of new transactions since the last pre-calculation, and k is much smaller than n.

3. The system according to claim 1, characterized in that, The system distinguishes between two verification modes: The lightweight threshold verification mode uses Bulletproofs range proofs, which only prove that the points balance meets the preset threshold conditions without exposing the exact balance, making it suitable for everyday consumption scenarios. The full audit verification mode employs complete Merkle path proof and chained hash recalculation, which can verify the precise point-in-time balance at any historical point in time, making it suitable for compliance audit scenarios.

4. The system according to claim 1, characterized in that it is global. The cryptographic accumulator constructed by the anchoring module is a Merkle Patricia tree, where the key of the leaf node is the member identifier, and the value of the leaf node contains only the member-level transaction sequence commitment hash of that member. The global anchoring module employs an incremental snapshot and lazy read strategy when constructing the Merkle Patricia tree: it maintains a "last update period" marker for each member; at the end of the notarization period, for active members who have made transactions during the period, it reads their latest commitment hash and participates in the construction of the tree; for inactive members who have not made any transactions during the period, it directly reuses the subtree root hash value from the previous period. When it is necessary to verify the points balance of any member at a specific historical point in time, the verification path is as follows: If a specific historical point in time coincides with the member's most recent transaction in the same storage period, the verifier obtains the member's member-level transaction sequence commitment hash, the corresponding Merkle path proof, the global storage root hash corresponding to the storage period, and all the member's point change transaction sequences up to the specific historical point in time within the storage period. Through chain-based hash recalculation, candidate commitment hashes are obtained; combined with Merkle path proof recalculation, candidate global storage root hashes are obtained; after comparing these hashes with the publicly available global storage root hashes on the chain, the change amounts of the change sequences are algebraically summed to obtain the point balance at that specific historical point in time. If a specific historical point in time is later than the member's most recent transaction in the evidence storage period, the verifier first verifies the member's points balance at the time of the most recent transaction according to the above path. Then, it obtains the global evidence root hash of all evidence storage periods from the end of the most recent transaction in the evidence storage period to the specific historical point in time. Using the member's identifier as input, it verifies the member. In the Merkle Patricia tree corresponding to all these evidence storage periods, there is no corresponding non-empty leaf node, thus cryptographically proving that the member did not actually make any transactions during the period.

5. The system according to claim 1, characterized in that, The cryptographic evidence storage module for points transactions uses a chain-based cryptographic hash function, specifically a hash algorithm based on the national cryptographic standard SM3.

6. The system according to claim 1, characterized in that, The blockchain evidence storage adaptation layer uses the CRYSTALS-Dilithium lattice-based quantum-resistant signature algorithm for digital signatures required for interaction with the evidence storage network.

7. A method for auditable evidence storage and traceability of integrals based on the system described in any one of claims 1 to 6, characterized in that, Includes the following steps: Step S1, Evidence storage period initialization: Generate or inherit the initial state commitment hash of each active member; Step S2, Real-time Transaction and Asynchronous Evidence Storage: The online points service module receives and processes points consumption requests, atomically updates the member balance in the business status database, generates a change transaction record, and immediately returns an operation success message; simultaneously, it asynchronously triggers the points transaction cryptographic evidence storage module, which recursively updates the member's member-level transaction sequence commitment hash using a chained cryptographic hash function; the asynchronous update consistency monitoring module checks whether the asynchronous update is successful. If it fails, it performs a retry according to the preset retry strategy. If the retry still fails, it generates an exception work order and triggers the manual compensation process. Step S3, Closure of Evidence Storage Period and Global Anchoring: At the end of the evidence storage period, the global anchoring module constructs a cryptographic accumulator using the member-level transaction sequence commitment hash of all active members who have made transactions as the data leaf and calculates the global evidence storage root hash; the blockchain evidence storage adaptation layer packages the global evidence storage root hash into a single evidence storage transaction, submits it to the evidence storage network and obtains consensus confirmation, thus completing the closure of the evidence storage period. Step S4, independent verification after closure: After the evidence storage period is closed, the off-chain independent verification module obtains the transaction sequence of the member's points change, the corresponding cryptographic proof path, and the publicly available global evidence storage root hash on the chain, and independently recalculates and verifies them to confirm the correctness of the points balance at any historical point in time without relying on the online points business service module.

Images