A product service supervision and evidence storage method and system based on a public chain and zero-knowledge proof

Abstract

The application discloses a product service supervision and evidence storage method and system based on a public chain and zero-knowledge proof and belongs to the field of service supervision. First, the original data of multiple services are stored under the public chain, and service calling requests are generated according to the demands of service calling parties. Then, the compliance verification is carried out in the logical contract module: identity authentication and permission verification are carried out first; then the request is converted into zk-SNARKs proof by combining the k-SNARKs algorithm, and the compliance verification is carried out; after the verification, the corresponding service data is called from the off-chain according to the request, the data digest of the calling event is stored on the chain as a supervision log, and the called service data is re-encrypted and uploaded to the off-chain storage; meanwhile, the DAO mechanism is used to update the logical contract module. The system does not need to depend on any centralized authority and has self-evolution ability.

Description

Technical Field

[0001] This invention belongs to the field of service supervision, specifically relating to a product service supervision and evidence storage method and system based on public blockchain and zero-knowledge proof. Background Technology

[0002] With the booming development of the digital economy, online transactions and interactions of various products and services are becoming increasingly frequent. In the traditional centralized regulatory model, all data is stored on servers or databases controlled by a single entity. The central agency possesses absolute power, which can legally manage data but may also tamper with records due to malicious acts, internal errors, or external attacks, thereby completely undermining the credibility of the system. This vulnerability exists not only in the financial sector but also poses significant risks in multiple scenarios such as healthcare, supply chain management, and even government services.

[0003] To overcome these drawbacks, blockchain technology, as a distributed ledger technology, emerged. Its core value lies in its construction of a trust network that achieves global consensus without relying on any single central node, based on three pillars: cryptography, decentralization, and consensus mechanisms. While it can achieve a certain degree of data sharing and process automation, it is essentially still a semi-centralized architecture. Its security and reliability still depend on the integrity and technical capabilities of a few operators, failing to fundamentally solve the inherent risks of centralization.

[0004] In contrast, public blockchains provide a completely open network environment where anyone can freely join and participate in verification. Under this architecture, data is distributed and stored across hundreds or thousands of nodes in the network, and no participant can modify historical records unilaterally.

[0005] However, public blockchains can only guarantee the permanence and immutability of data, which is far from sufficient for complex regulatory tasks. Therefore, second-generation blockchain technology introduces the concept of smart contracts, which encode pre-defined business rules into code. When the triggering conditions are met, the contract will automatically execute the corresponding operation without any human intervention or third-party intermediaries, making automated supervision possible.

[0006] While public blockchains and smart contracts lay a solid foundation for building a trustworthy regulatory system, a complete solution still needs to consider its own governance and evolution. To address this, Decentralized Autonomous Organizations (DAOs) have emerged. A DAO is a virtual organization operating on blockchain and smart contracts. Its members gain voting rights by holding governance tokens, and all decisions, including the use of funds, rule changes, and even the direction of project development, are collectively decided through on-chain voting. This model ensures that the system can continue to develop healthily based on market demand and community consensus, without being hijacked by the interests of a few individuals or groups.

[0007] However, existing technologies still have the following drawbacks: (1) Low transparency in service invocation and data exchange processes, and lack of credible evidence for post-event audits: In existing centralized or semi-centralized systems, the process of service invocation and related data are usually recorded in private databases or log files. In complex business processes involving multiple parties, it is difficult for each party to verify whether the other party's behavior is compliant. Once a dispute arises or a post-event audit is required, traditional forms of evidence, such as paper contracts, email correspondence, or database backups, are at risk of being forged, deleted, or tampered with, resulting in audit results lacking sufficient persuasiveness.

[0008] (2) Centralized regulation has the risk of single point of failure and data tampering: Whether it is a regulatory system built by an enterprise or a centralized platform led by the government, its core data is stored on a few servers, which constitutes a natural single point of failure. Once these servers are attacked by hackers, damaged by hardware, or abused by internal personnel, the data integrity of the entire system will be threatened, and may even lead to the paralysis of the entire regulatory system.

[0009] (3) Private / consortium blockchain solutions fail to fundamentally solve the centralization problem: Although existing enterprise-level blockchain solutions have achieved a certain degree of decentralization through permissioned access mechanisms, in essence, trust depends on pre-selected participants rather than technical consensus. This makes them unable to eliminate the risks of single points of failure and centralized manipulation, but only disperses the risks from one central point to a few central points.

[0010] (4) Lack of effective decentralized governance mechanisms: Traditional systems and most existing blockchain solutions lack sustainable self-evolution capabilities. Major decisions such as system upgrades and rule modifications are usually made by the core development team or a small number of operators, rather than by the broad participation of community members. This makes the development direction of the system easily influenced by the will of a few, and difficult to adapt to rapidly changing market demands and regulatory environments.

[0011] (5) Balancing privacy protection and compliance: The complete transparency of public blockchains is a double-edged sword. If sensitive service call details are directly recorded on the blockchain, it may leak trade secrets or user privacy. Existing solutions often fail to effectively balance the contradiction between regulatory transparency and data privacy protection. Summary of the Invention

[0012] This invention addresses two existing technical problems: how to achieve real-time, transparent, and non-repudiable recording of service calls and data exchange processes, and how to construct a regulatory system that does not rely on any centralized authority and has self-evolution capabilities. It proposes a product service supervision and evidence storage method and system based on public blockchain and zero-knowledge proof.

[0013] Firstly, this invention proposes a product service supervision and evidence storage method based on public blockchain and zero-knowledge proof, used to achieve tamper-proof supervision log recording and compliance verification during product service interactions involving multiple parties, characterized by including: S1 encrypts and stores the raw data of multiple services in a distributed storage system under the public blockchain, and obtains the service call requirements of the service caller to further generate a service call request. S2, the service call request is routed through the proxy contract module to the logic contract module for compliance verification: First, the service caller is authenticated and authorized. Second, the zk-SNARKs zero-knowledge proof algorithm is used to verify the compliance of the zk-SNARKs proof generated on the public blockchain for the service call request. If all verifications pass, proceed to S3. If any verification fails, the compliance verification ends and the service call request is rejected. S3, according to the service call request, call the corresponding service data from the distributed storage system, and then re-encrypt the called service data and store it back in the distributed storage system; S4. The call timestamp, hash value, and content identifier of the called service data in the distributed storage system are combined to form summary data, which is then stored on the public blockchain as a regulatory log. The blocks are stored using a Merkle tree structure. The leaf nodes are the hash values ​​of each service call request. The hash value of the parent node is recalculated by concatenating the hash values ​​of the leaf nodes. Finally, the hash value of the root node is stored in the block header.

[0014] Furthermore, in S1, anonymization techniques are used to hide the true identities of the service caller and the callee; the anonymization techniques include ring signatures or stealth addresses.

[0015] Furthermore, in S2, the compliance verification is performed using a pre-compiled elliptic curve pairing operation contract on the public blockchain.

[0016] Furthermore, the update of the logical contract module in S2 is implemented through the proxy contract module, and the update process is as follows: S201: When a governance proposal from an external source is obtained, all historical service callers stored off-chain are members, and the number of tokens is allocated according to each member's contribution. S202, determine whether the governance proposal triggers systemic risk. If it does, call the multi-signature wallet mechanism to terminate voting. If it does not, all members use tokens to vote on the governance proposal until the specified time is reached and the voting results are obtained. S203, if the voting result meets the passing and participation conditions, then the logical address in the proxy contract pointing to the current logical contract module will be updated to point to the new logical contract module corresponding to the governance proposal according to the governance proposal, thereby realizing the update; otherwise, no update will be performed.

[0017] Furthermore, in S202, the multi-signature wallet mechanism is as follows: if the number of member digital signatures obtained by the supervisory user exceeds the threshold, the emergency veto right is exercised to terminate the voting and the veto record is stored on the public chain; if the threshold is not exceeded, the voting process begins.

[0018] Furthermore, in S203, the participation condition is that the number of tokens used for voting accounts for a percentage of the total number of tokens used by all members, which exceeds a threshold.

[0019] Secondly, this invention proposes a product service supervision and evidence storage system based on public blockchain and zero-knowledge proof, which is used to implement the above-mentioned product service supervision and evidence storage method based on public blockchain and zero-knowledge proof.

[0020] The beneficial effects of this invention are: (1) Fundamental improvement in security and trust: This invention is based on a public blockchain, whose decentralized nature means that no node can dominate other nodes. Any malicious behavior requires control of more than half of the computing power or equity in the network to succeed, which is extremely uneconomical for large public blockchains. Therefore, this invention provides a truly censorship-resistant, attack-resistant, and trustworthy environment that anyone can rely on.

[0021] (2) It resolves the contradiction between transparency and privacy: Existing solutions often make trade-offs between transparent auditing and data privacy. This invention, through zero-knowledge proof technology, is the first to technically achieve verifiable compliance auditing without disclosing any sensitive original data, which is something that traditional log systems and simple hash-based blockchain solutions cannot achieve.

[0022] (3) Long-term guarantee of governance and sustainability: This invention, by introducing a DAO, endows the system with the ability to self-evolve. Through on-chain voting, the community can democratically decide whether to adopt a new feature, fix a security vulnerability, or modify a core rule. This decentralized governance model ensures that the development direction of the system is always consistent with the common interests of the community, avoiding the risk of project stagnation or even split due to the departure of core developers or ideological differences. Attached Figure Description

[0023] Figure 1 This is an overall framework diagram of the present invention.

[0024] Figure 2 A detailed flowchart for DAO governance.

[0025] Figure 3 This is a schematic diagram illustrating the complete process of service invocation and regulatory evidence storage in the order query scenario.

[0026] Figure 4 This is a schematic diagram of the electronic device terminal structure of the present invention. Detailed Implementation

[0027] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be practiced in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below. Technical features in the various embodiments of the present invention can be combined accordingly without mutual conflict.

[0028] First, for ease of explanation, some of the terms used in this invention will be explained.

[0029] Block: The basic data structure unit in a blockchain, consisting of a block header and a block body. The block body records all transactions that occurred on the network within a certain period; the block header stores the block's metadata.

[0030] Block header: The metadata portion of a block, typically containing the version number, the hash of the previous block, a timestamp, the Merkle root hash, the difficulty target, and a random number (or PoS-related fields). The Merkle root hash is used to quickly verify the integrity of transactions within the block body.

[0031] Public blockchain: A completely open blockchain network that anyone can freely join and participate in verification. It maintains the ledger through distributed nodes and features decentralization, immutability, and transparency.

[0032] On-chain: Data is sent to the blockchain network in the form of transactions. After being verified by nodes, packaged into blocks, and consensus is reached, it is permanently stored in the distributed ledger of the blockchain.

[0033] Off-chain: All data, computations, or operations not stored on the blockchain, including local databases, distributed storage systems (such as IPFS), and user-local computations.

[0034] Arithmetic circuit: In this invention, it is used to represent the computational model of the polynomial constraint system and is responsible for converting the verification rules into a set of equivalent mathematical polynomial equations.

[0035] Smart Contract: A self-executing program that runs on the blockchain. It encodes pre-defined business rules into code and automatically executes the corresponding operation without human intervention when the triggering conditions are met.

[0036] DAO (Decentralized Autonomous Organization): A form of virtual organization that operates based on blockchain and smart contracts. Members gain voting rights by holding governance tokens, and all decisions are made collectively through on-chain voting.

[0037] Zero-Knowledge Proof (ZKP): A cryptographic technique that allows a prover to demonstrate to a verifier that a statement is true without revealing any additional information beyond the statement itself.

[0038] Merkle Tree: A binary tree data structure used to efficiently and securely verify the integrity of large datasets by recursively hashing the data hash values ​​to ultimately generate a single root hash value.

[0039] zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge): A specific implementation scheme of zero-knowledge proofs, allowing provers to efficiently prove the correctness of a computation to verifiers without revealing the original data. Its "succinctness" refers to the small proof size and fast verification speed, making it suitable for resource-constrained on-chain environments.

[0040] Elliptic curve pairing operation: a cryptographic bilinear mapping that maps two points in different elliptic curve groups to an element in another target group. In zero-knowledge proof verification, the verifier checks whether the following equation holds true using elliptic curve pairing operation; if the equation holds, the verification is successful: in, The proof provided by the party to be proven. and A component of the verification key held by the verifier. This is an elliptic curve pairing operation (bilinear mapping).

[0041] Oracles are middleware that connects blockchains to external data sources, providing trusted off-chain information for smart contracts. Oracles prevent single points of failure and ensure the reliability of data input through multi-signature or decentralized network designs.

[0042] IPFS (InterPlanetary File System): A distributed file storage protocol that enables decentralized storage and retrieval of data through content addressing.

[0043] Proxy Contract: A smart contract design pattern that separates contract logic from state storage. User interactions are routed to upgradeable logic contracts through the proxy contract, enabling seamless upgrades while preserving historical state.

[0044] Logical address: A logical address is an address generated by the CPU or referenced by a program in a computer system. It does not directly correspond to the actual storage location in physical memory and needs to be mapped to a physical address through an address translation mechanism before the memory hardware can be accessed. In this invention, the logical address refers to the smart contract address stored in the proxy contract that points to the currently effective logical contract.

[0045] Multisig Wallet: A blockchain account management mechanism that requires a preset number of private key signatures to execute transactions.

[0046] Based on the above background, the purpose of this invention is to construct a systematic solution that can completely solve the core problems of supervision and evidence preservation. It must simultaneously possess the following characteristics: (1) immutability, that is, once all key event records are generated, they cannot be modified or deleted; (2) transparency and auditability, that is, all operation processes are fully visible to relevant parties and can be independently verified; (3) automated execution, that is, regulatory rules can be automatically and objectively applied to every service call; (4) decentralized governance, that is, the direction of system evolution is jointly determined by a wide range of community members, rather than a few centralized entities; (5) privacy protection, that is, while ensuring the effectiveness of supervision, sensitive business information and personal privacy are protected; (6) universal and scalable, that is, it can adapt to different industries and service scenarios of different scales, and support continuous functional expansion.

[0047] Therefore, this invention proposes a trusted product service supervision and evidence storage system based on public blockchain. Its core idea is to utilize the inherent characteristics of public blockchain to build a complete ledger that anyone can trust, that cannot be unilaterally tampered with, and that is completely transparent in its process, and to deeply integrate regulatory logic and governance structure into it.

[0048] The technical solution of this invention consists of three tightly coupled layers: the underlying public blockchain network and storage facilities, the middleware smart contract layer, and the upper-layer application and DAO governance layer. The overall framework is as follows: Figure 1 As shown.

[0049] I. Underlying Public Blockchain Network and Storage Facilities The decentralized nature of public blockchains means that no single authority can control or modify the ledger; data is distributed and stored on every node in the network, fundamentally eliminating the risk of single points of failure. Its built-in consensus mechanism ensures that all nodes in the network agree on the validity of transactions, and any attempt to forge or tamper with historical records will fail because it cannot gain a majority vote. More importantly, the transparency of public blockchains means that every transaction occurring on the network is publicly visible, providing a natural, trustless source for post-transaction auditing.

[0050] Therefore, this invention chooses a public blockchain to store the key events of all service calls. Specific technical details include: 1. Consensus Mechanism Selection and Optimization: To support high-frequency service call notarization and reduce energy consumption, this system prioritizes the PoS consensus mechanism; to further improve throughput to adapt to large-scale applications, sharding technology that is compatible with the notarization contract data structure and verification requirements can be integrated.

[0051] 2. Data on-chain and storage structure: Key events of service calls (such as call timestamp, caller's public key address, callee identifier, input parameter hash, and output result hash) are encapsulated as transactions, broadcast through chain nodes, and packaged into blocks.

[0052] All transactions within each block are organized using a Merkle tree structure, where leaf nodes are the hash values ​​of each key event. The hash values ​​of two adjacent leaf nodes are concatenated and recalculated to become the hash value of the parent node. This process is repeated until only one node remains, which is the root node. The root hash corresponding to the root node is stored in the block header to ensure data integrity.

[0053] While adhering to the standard blockchain data structure, in order to reduce on-chain storage load, the system adopts the principle of minimizing on-chain data. That is, only the data digest of key events (including call timestamp, hash value of key events and CID of the called service in IPFS) is recorded on the chain. The original sensitive data related to the service is re-encrypted and stored in the off-chain environment of distributed storage systems such as IPFS after each call, and associated with the on-chain record through CID content addressing link.

[0054] Before the initial call, the original data of the relevant service is already stored in IPFS.

[0055] 3. Privacy Protection Technologies: To balance transparency and privacy, the system incorporates anonymization techniques, such as using ring signatures or stealth addresses to conceal the true identities of both parties in a transaction. Simultaneously, it allows regulators to verify compliance through zero-knowledge proofs at the middleware smart contract layer. Furthermore, off-chain data is protected using symmetric or asymmetric encryption, with keys distributed through secure channels or managed using identity-based encryption.

[0056] This invention leverages the immutability of public blockchains to record key events of each service call as transactions on the chain, forming a permanent and tamper-proof audit log. To balance transparency and privacy protection, this system adopts a principle of minimizing on-chain data, ensuring data integrity and verifiability while effectively protecting trade secrets and personal privacy.

[0057] II. Middleware Smart Contract Layer The middleware smart contract layer consists of a series of collaborative smart contract modules deployed on the public blockchain. The core design of this invention lies in encoding complex regulatory rules into a series of fully functional smart contracts. These contracts are not merely passive data recorders, but active regulators.

[0058] When a service call request arrives, the relevant smart contract automatically executes a series of pre-defined compliance checks. All checks are completed on-chain in real time, and the results are immediately reflected in the blockchain's state changes, generating a new, non-repudiable record. This invention also introduces zero-knowledge proof technology, enabling regulators to verify compliance without obtaining the original sensitive data.

[0059] Furthermore, to address rule changes, the contracts in the middleware smart contract layer support an upgradeable model, implemented through the separation of proxy contracts and logic contracts. Upgrades require approval through a DAO vote between the upper-layer application and the DAO governance layer; contracts also integrate security features such as reentrancy attack protection and integer overflow checks, and use formal verification tools for code auditing.

[0060] The middleware smart contract layer consists of six modules: identity management contract, permission check contract, compliance verification contract, evidence storage contract, proxy contract, and logic contract. Among them, the identity management contract, permission check contract, compliance verification contract, and evidence storage contract are in a progressive relationship.

[0061] 1.1 Identity Management Contract: Responsible for registering and verifying the identities of service callers. Each service caller is identified by a public key address. The identity management contract maintains an identity mapping table, associating addresses with off-chain digital identity credentials. Identity verification is achieved through digital signatures; the caller must sign the transaction, and the identity management contract verifies the validity of the signature.

[0062] 1.2 Permission Check Contract: The system's supervisor predefines access control and contract storage permission rules based on the service caller's role, and checks the current service caller's permissions according to the access control and permission rules when a service is called.

[0063] 1.3 Compliance Verification Contract: The compliance verification contract contains a verification function and a verification key. Upon receiving a zk-SNARK proof from the service caller, it invokes the on-chain pre-compiled elliptic curve pairing operation contract for verification, and determines compliance based on the return value. To handle complex rules, the contract can integrate oracles to obtain off-chain data such as exchange rates and regulatory blacklists.

[0064] To achieve compliance verification while protecting privacy, the system integrates zk-SNARKs zero-knowledge proof technology into the compliance verification contract. The specific process is as follows: 1.3.1 Proof Generation: The service caller generates proof off-chain using the zk-SNARKs algorithm to demonstrate that its behavior complies with specific regulatory rules without disclosing specific data. The system compiles the pre-set compliance conditions in the compliance verification contract (such as a single transaction amount not exceeding 10,000 yuan) into an arithmetic circuit to further obtain the constraint system. The service caller substitutes the service data to be invoked (such as input parameters, output results, caller address, callee identifier, etc.) into the constraint system off-chain and uses the zk-SNARKs algorithm to obtain the proof.

[0065] 1.3.2 On-chain Verification: The compliance verification contract contains a verification function that takes zk-SNARKs proofs and verification keys as inputs and calls the on-chain pre-compiled elliptic curve pairing operation contract for verification. If the equation holds true, the verification is considered successful, the compliance verification contract is updated to the "verification successful" state and the compliance result is recorded, and the transaction proceeds to the notarization contract; otherwise, the transaction is rejected.

[0066] 1.4 Evidence Storage Contract: Responsible for recording service call events. Event data is stored in the form of a structure, including fields such as timestamp, participants, input / output hashes, etc., and triggers event logs for external applications to listen to.

[0067] 1.5 Proxy Contract: The proxy contract is a forwarding layer that maintains a state variable pointing to the address of the current logical contract. When a user interacts with the system, all requests are first sent to the proxy contract. The proxy contract will then forward the request to the logical contract for execution, while maintaining the state variable as context within the proxy contract.

[0068] The proxy contract itself does not contain business logic; it is only responsible for routing and storing state. When a contract needs to be upgraded, after the DAO votes in favor, the proxy contract updates the address of the logical contract it points to, thus achieving a seamless upgrade without the need to migrate existing data.

[0069] 1.6 Logic Contracts: Logic contracts do not refer to a single specific smart contract, but rather to a collective term for four contract modules that carry specific business logic: identity management contract, permission check contract, compliance verification contract, and evidence storage contract. These logic contracts implement the system's core monitoring and evidence storage functions, and their code can be upgraded through DAO voting. Proxy contracts dynamically point to the currently active logic contract address, forwarding user requests to the corresponding logic contract for execution, thereby achieving seamless updates to business logic without migrating already stored state data.

[0070] III. Upper-layer applications and DAO governance layer This invention introduces a Decentralized Autonomous Organization (DAO) as the top-level governance framework for the system. The DAO entrusts all decision-making power regarding system upgrades, rule revisions, dispute arbitration, and future development direction to all service callers recorded on the public blockchain. Each service caller's governance token represents their voting weight within the DAO. When the contract layer needs updating or modification, all service callers jointly determine the system's evolution path through on-chain voting.

[0071] The upper-layer application and DAO governance layer of this invention together comprise two parts: the DAO governance module and the upper-layer application interface.

[0072] The DAO governance module is used to perform DAO governance on the system, such as... Figure 2 As shown, DAO governance includes: 1. Governance Token Allocation: The system issues native governance tokens. Token allocation is based on contributions from service callers, such as service call volume or staking amount, and supports dynamic adjustments. Token holders have voting rights, with voting weight proportional to the number of tokens held.

[0073] 2. Voting Mechanism: On-chain voting is employed to manage the lifecycle of current proposals (including submission, voting period, and execution). Voting modes include simple majority voting, weighted voting, or double voting to prevent oligopolistic practices. To address emergencies, the system further integrates a multi-signature wallet mechanism, allowing manual or predefined regulatory bodies to exercise emergency veto power after obtaining a majority of signatures.

[0074] 3. Vault Management: The DAO uses a vault to store system fees. The use of tokens in the system fees requires approval through a proposal vote, and the required tokens are automatically allocated to the approved proposal.

[0075] When a community member proposes to modify a regulatory rule in the compliance verification contract (such as the maximum amount per transaction), the DAO layer is invoked. The specific process is as follows: Figure 2 As shown: S1, Proposal Submission. Any member who meets the governance threshold (e.g., holds at least 1000 governance tokens) creates a governance proposal through the upper-layer application interface, including the new address (or code hash) of the target logic contract, a description of the reason for the modification, and the expected execution time, and signs and sends it to the DAO governance module for voting.

[0076] S2, Voting Period Begins. The voting contract automatically initiates a voting period (e.g., 7 days) on the public blockchain. All governance token holders can vote with their tokens for "For," "Against," or "Abstain." During the voting period, it is simultaneously determined whether the governance proposal will trigger systemic risks. If it will, voting stops and the system enters a multi-signature wallet mechanism.

[0077] S3, Voting Statistics. After the voting period ends, any node can call the voting contract's statistics function. The contract automatically calculates the percentage of votes in favor and the percentage of total voting tokens in the total number of tokens issued.

[0078] If the approval votes meet the criteria (e.g., more than 50% of the votes are in favor) and the percentage of total voting tokens is higher than the minimum participation threshold, the proposal will pass.

[0079] S4, Execution. After the proposal is approved, the DAO contract automatically calls the upgrade function in the proxy contract to update the logical address of the target logic contract to the new address and update the pointer of the proxy contract. At the same time, the event log is triggered to record the hash of this upgrade, the voting results, and the execution time.

[0080] S5, Vault Rewards (Optional). If the proposal is successfully executed, the proposer can receive a small, pre-set token reward from the vault, which will be automatically transferred by the vault contract.

[0081] To enable non-technical users to easily use this system, the upper-layer application interface of this invention is used to encapsulate complex blockchain interaction logic, providing users with a user-friendly operating experience.

[0082] The application provides the following functional modules: 1. Dashboard: Visualizes service call records, compliance status, and governance proposals.

[0083] 2. Query tool: Allows users to retrieve evidence data by transaction hash or address and verify the consistency between on-chain records and off-chain data.

[0084] 3. Proposal Submission Interface: Users can create governance proposals and sign and submit them to the DAO contract.

[0085] The DAO governance model of this invention is specifically designed for regulatory systems. Its governance rules, voting weights, treasury management, and dispute resolution mechanisms are all optimized around the core objective of "how to better regulate and maintain the entire system." All DAO governance activities, including proposal content, voting processes, and final results, are permanently recorded on the public blockchain, allowing anyone to audit them at any time, forming a closed-loop, completely transparent governance ecosystem.

[0086] Based on the above system architecture, taking the order query scenario as an example, a complete service call and regulatory evidence storage process is as follows: Figure 3 As shown, the details are as follows: S1, Request Initiation: The user initiates a service call request through the upper-layer application interface (e.g., querying the details of order ID "ORD123").

[0087] S2, Permission Verification: The application backend calls the identity management contract and permission check contract in the middle layer smart contract to verify the user's permissions based on the digital signature provided by the user. If the verification fails, the process terminates; if the verification passes, it proceeds to S3.

[0088] S3, Off-chain Proof Generation: The user generates a zk-SNARK proof off-chain based on the specific data and compliance rules of this call (e.g., it can only be queried if the user is the buyer or seller of the order). .

[0089] S4, Compliance Verification: The application backend will prove... The necessary metadata (such as order CID) is sent to the compliance verification contract for on-chain verification.

[0090] S5, Evidence Storage: If the verification is successful, the system calls the corresponding service data (obtains order details from IPFS and returns them to the user) and records the call timestamp, hash value, and CID of the key events of this service call on the blockchain through the evidence storage contract; otherwise, the process is terminated.

[0091] S6, Off-chain storage: Simultaneously, the original data from this call is re-encrypted and uploaded to a distributed storage system such as IPFS.

[0092] It should also be noted that the product service supervision and evidence storage method based on public blockchain and zero-knowledge proof in the above embodiments can essentially be executed by a computer program. Therefore, similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer electronic device corresponding to the method provided in the above embodiments, which includes a memory and a processor; The memory is used to store computer programs; The processor is configured to implement, when executing the computer program, a product service supervision and evidence storage method based on public blockchain and zero-knowledge proof as described in the above embodiments.

[0093] From a hardware perspective, such as Figure 4 The diagram shown is a hardware structure diagram provided in this embodiment. In addition to the processor, memory, network interface and non-volatile memory shown in the diagram, any device with data processing capabilities in the embodiment may also include other hardware depending on the actual function of the device with data processing capabilities, which will not be described in detail here.

[0094] When the logical instructions in the aforementioned memory can be implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium.

[0095] Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer-readable storage medium corresponding to the method provided in the above embodiments. The storage medium stores a computer program, which, when executed by a processor, can realize a product service supervision and evidence storage method based on public blockchain and zero-knowledge proof in the above embodiments.

[0096] It is understood that the computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device of any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of any data processing device. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0097] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.

Claims

1. A product service supervision and evidence storage method based on public blockchain and zero-knowledge proof, used to achieve tamper-proof supervision log recording and compliance verification during product service interactions involving multiple parties, characterized in that... include: S1 encrypts and stores the raw data of multiple services in a distributed storage system under the public blockchain, and obtains the service call requirements of the service caller to further generate a service call request. S2, the service call request is routed through the proxy contract module to the logic contract module for compliance verification: First, the service caller is authenticated and authorized. Second, the zk-SNARKs zero-knowledge proof algorithm is used to verify the compliance of the zk-SNARKs proof generated on the public blockchain for the service call request. If all verifications pass, proceed to S3. If any verification fails, the compliance verification ends and the service call request is rejected. S3, based on the service call request, retrieve the corresponding service data from the distributed storage system, and then re-encrypt and store the retrieved service data back into the distributed storage system; S4. The call timestamp, hash value, and content identifier of the called service data in the distributed storage system are combined to form summary data, which is then stored on the public blockchain as a regulatory log. The blocks are stored using a Merkle tree structure. The leaf nodes are the hash values ​​of each service call request. The hash value of the parent node is recalculated by concatenating the hash values ​​of the leaf nodes. Finally, the hash value of the root node is stored in the block header.

2. The product service supervision and evidence storage method based on public blockchain and zero-knowledge proof according to claim 1, characterized in that, In S1, anonymization techniques are also used to hide the true identities of the service caller and the callee; the anonymization techniques include ring signatures or stealth addresses.

3. The product service supervision and evidence storage method based on public blockchain and zero-knowledge proof according to claim 1, characterized in that, In S2, the compliance verification is performed using a pre-compiled elliptic curve pairing operation contract on the public blockchain.

4. The product service supervision and evidence storage method based on public blockchain and zero-knowledge proof according to claim 1, characterized in that, The update of the logical contract module in S2 is implemented through the proxy contract module. The update process is as follows: S201: When a governance proposal from an external source is obtained, all historical service callers stored off-chain are members, and the number of tokens is allocated according to each member's contribution. S202, determine whether the governance proposal triggers systemic risk. If it does, call the multi-signature wallet mechanism to terminate voting. If it does not, all members use tokens to vote on the governance proposal until the specified time is reached and the voting results are obtained. S203, if the voting result meets the passing and participation conditions, then the logical address in the proxy contract pointing to the current logical contract module will be updated to point to the new logical contract module corresponding to the governance proposal according to the governance proposal, thereby realizing the update; otherwise, no update will be performed.

5. A method for product service supervision and evidence storage based on public blockchain and zero-knowledge proof as described in claim 4, characterized in that, In S202, the multi-signature wallet mechanism is as follows: if the number of member digital signatures obtained by the supervisory user exceeds the threshold, the emergency veto right is exercised to terminate the voting and the veto record is stored on the public chain; if the threshold is not exceeded, the voting process begins.

6. The product service supervision and evidence storage method based on public blockchain and zero-knowledge proof according to claim 3, characterized in that, In S203, the participation condition is that the number of tokens used for voting accounts for a percentage of the total number of tokens used by all members that exceeds a threshold.

7. A product service supervision and evidence storage system based on public blockchain and zero-knowledge proof, used to implement the product service supervision and evidence storage method based on public blockchain and zero-knowledge proof as described in claim 1, characterized in that, include: The upper-layer application and DAO governance layer are used to provide a visual application interface and receive the digital signature and service call request from the service caller, and then generate a service call request. The middleware smart contract layer includes a proxy contract module and a logic contract module; The proxy contract module receives service call requests and digital signatures, and assigns them to the logic contract module. The logic contract module includes an identity management contract submodule, an access control contract submodule, a compliance verification contract submodule, and an evidence storage contract submodule. Based on the received service call request and digital signature, it sequentially calls the identity management contract submodule, access control contract submodule, and compliance verification contract submodule to perform identity verification, access control verification, and zero-knowledge proof. If all verifications pass, the evidence storage contract submodule calls the corresponding service data and stores it. If any verification fails, the service call request is rejected. The underlying public blockchain network and storage facilities adopt a public blockchain architecture. Off-chain, the system is responsible for encrypting and storing the original data of each service and generating content identifiers, while on-chain, the system records the data digest of each service call event.

8. A product service supervision and evidence storage system based on public blockchain and zero-knowledge proof as described in claim 7, characterized in that, The upper-layer application and DAO governance layer also include a DAO governance module; when the upper-layer application and DAO governance layer obtain a governance proposal, the DAO governance module votes on the governance proposal according to the DAO mechanism, thereby updating the logic contract module.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements a product service supervision and evidence storage method based on public blockchain and zero-knowledge proof as described in any one of claims 1 to 6.

10. A computer electronic device, characterized in that, Including memory and processor; The memory is used to store computer programs; The processor is configured to, when executing the computer program, implement a product service supervision and evidence storage method based on public blockchain and zero-knowledge proof as described in any one of claims 1 to 6.

Images