Zero-knowledge proof compression method and system suitable for resource-constrained equipment

Abstract

The invention discloses a zero-knowledge proof compression method and system suitable for resource-constrained equipment, and relates to the technical field of zero-knowledge proof compression, and the method comprises the steps: obtaining a to-be-verified target task, and converting the to-be-verified target task into a Boolean gate circuit; obtaining an original private input and splitting the original private input into a plurality of input shares; performing local calculation based on the input share and a Boolean gate circuit to obtain a corresponding local view and a common output value; performing hash calculation based on local views to obtain a view hash commitment set; obtaining public content based on the view hash commitment set and the public output value; based on each round of random challenge, the public content, the public output value and the view Hash commitment set, forming a compression proof of the round; and obtaining a complete compressed zero-knowledge proof structure based on the compression proof of all rounds, and performing integrity verification to obtain an effective compressed zero-knowledge proof structure. On the premise of ensuring verifiability, the data transmission quantity is obviously reduced, and the construction of a high-compression-ratio proof structure is realized.

Description

Technical Field

[0001] This invention relates to the field of zero-knowledge proof compression technology, and more specifically to a zero-knowledge proof compression method and system suitable for resource-constrained devices. Background Technology

[0002] Zero-Knowledge Proof (ZKP) is a cryptographic tool that proves a statement to a verifier as true without revealing private data. In recent years, to address the threat of quantum computing and deploy trusted verification functions, MPC-in-the-Head (MPCitH) type zero-knowledge proof schemes have been widely researched and applied. Existing zero-knowledge proof protocols based on the MPC-in-the-Head (MPCitH) structure (such as ZKBoo and Ligero), while possessing strong quantum resistance and versatility and performing well in academic research and theoretical analysis, still face the following prominent problems in practical deployment on resource-constrained devices:

[0003] 1. Traditional MPCitH protocols require the submission of complete views from multiple participants in each round, including input shares, gate-level intermediate values, and communication information, resulting in lengthy view content. As the number of challenge rounds increases, the overall proof size grows linearly or even superlinearly, making it difficult to meet the needs of devices with limited bandwidth or storage space. 2. Verifiers need to perform hash verification, protocol consistency reconstruction, and Boolean circuit replay on multiple complete views. This process involves extensive logic gate-level simulation and comparison, leading to significant verification latency and high computational overhead, making it difficult to run efficiently on lightweight platforms. 3. Existing solutions often employ fixed-structure challenge strategies (such as always opening two views or exposing all fields), making it impossible to select specific fields for verification as needed. They also do not support dynamically adjusting the view structure or compression parameters based on different platform capabilities, making it difficult to achieve the optimal balance between performance and security in diverse hardware environments. 4. Current solutions generally lack a joint control mechanism for the challenge ratio (such as the field-level verification ratio) and the number of challenge rounds. Developers find it difficult to flexibly configure acceptable sanity error levels according to actual application scenarios, limiting their ability to be implemented in distributed environments, on-chain blockchain verification, and other scenarios.

[0004] Therefore, how to significantly reduce the amount of data transmission while ensuring verifiability and construct a proof structure with a high compression ratio is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, the present invention provides a zero-knowledge proof compression method and system suitable for resource-constrained devices, which significantly reduces the amount of data transmission while ensuring verifiability, and realizes the construction of a proof structure with a high compression ratio.

[0006] In order to achieve the above object, the present invention adopts the following technical solutions:

[0007] A zero-knowledge proof compression method suitable for resource-constrained devices includes:

[0008] Obtain the target task to be verified and convert it into a Boolean gate circuit;

[0009] Obtain the original private input and split it into multiple input shares;

[0010] Based on the corresponding input shares and the Boolean gate circuit, local calculations are performed to obtain the corresponding local view and common output value;

[0011] A hash calculation is performed on each of the local views to obtain a set of view hash commitments.

[0012] A random challenge is obtained based on the view hash commitment set and the public output value;

[0013] The publicly available content is derived based on the aforementioned random challenge;

[0014] The compacted proof for this round is composed of the random challenge generated in each round of computation, the public content, the public output value, and the set of view hash commitments.

[0015] Based on the current round of compressed proofs from all computation rounds, a complete compressed zero-knowledge proof structure is obtained;

[0016] Integrity verification is performed based on the compressed zero-knowledge proof structure to obtain an effective compressed zero-knowledge proof structure.

[0017] Preferably, the Boolean gate circuit is obtained by:

[0018] Based on the target task, it is converted into a formal, verifiable statement;

[0019] Based on the verifiable statement, it is converted into an equivalent Boolean gate circuit;

[0020] The Boolean gate circuit consists of basic logic gates and defines the complete logical flow of function execution.

[0021] Preferably, the corresponding local view is obtained, specifically including:

[0022] Based on each input share and protocol requirement, perform local computation corresponding to the circuit logic of the Boolean gate circuit to generate a computation record;

[0023] When the local computation process requires multiple participants to exchange partial data or apply other participants' preprocessed values ​​to complete the local computation, information interaction is performed with the participants, and the corresponding sent and / or received messages are recorded as communication information.

[0024] The corresponding local view is formed based on the corresponding input share, the calculation record, and the communication information.

[0025] Preferably, a random challenge is obtained, specifically including:

[0026] The pseudo-random seed is obtained by inputting the view hash commitment set and the public output value into the cryptographic hash function.

[0027] The random challenge is generated based on the pseudo-random seed, which includes a set of view indexes and mask parameters.

[0028] Preferably, the method for obtaining the view index set is as follows:

[0029] A preset ratio of the local views is randomly selected as the verification view based on all the local views;

[0030] The view index set is composed of the view numbers corresponding to all the verification views.

[0031] Preferably, the mask parameter includes four fields arranged in sequence:

[0032] The first field indicates whether the input share is made public;

[0033] The second field indicates whether the randomness of the protocol is publicly disclosed;

[0034] The third field indicates whether the message is publicly disclosed;

[0035] The fourth field indicates whether the received message is made public;

[0036] When the information is made public, the corresponding bit value of the field is set to 1; when the information is not made public, the corresponding bit value of the field is set to 0.

[0037] Preferably, obtaining the disclosed content specifically includes:

[0038] The corresponding verification view is obtained based on the view index set.

[0039] Based on the bit values ​​of each bit of the mask parameter, the corresponding public field content is extracted from the verification view as the public content.

[0040] Preferably, it further includes: setting a security control lower limit based on the compressed zero-knowledge proof structure:

[0041] The total number of challenge rounds is based on all the calculated rounds.

[0042] The four bits in the mask parameter are mapped to values ​​between 0 and 1, which serve as valid verification coverage parameters.

[0043] The total probability of successful forgery of the compressed zero-knowledge proof structure is obtained based on the total number of challenge rounds, the effective verification coverage parameter, and the preset ratio as security parameters.

[0044] Based on the total probability of successful forgery, determine whether it is less than or equal to the security threshold;

[0045] If so, then the lower limit of safety control is met;

[0046] Otherwise, adjust the safety parameters and repeat the above judgment process until the safety control lower limit is met.

[0047] Preferably, the integrity verification specifically includes:

[0048] Based on the compressed zero-knowledge proof structure, the random challenge, the set of hash commitment values, the input share, the communication information, and the common output value for all computation rounds are extracted;

[0049] Based on the random challenge, the local view is reconstructed and hashed to obtain the verification hash value;

[0050] Determine whether the verification hash value is consistent with the corresponding hash commitment value in the hash commitment value set;

[0051] If not, the verification fails;

[0052] If so, then based on the input share and the communication information, perform local circuit calculations in the Boolean gate circuit to obtain the calculation result;

[0053] Determine whether the calculation result is consistent with the common output value;

[0054] If not, the verification fails;

[0055] If so, determine whether the random challenge is complete;

[0056] If not, the verification fails;

[0057] If so, then the verification proves that the compressed zero-knowledge proof structure is complete and valid.

[0058] A zero-knowledge proof compression system suitable for resource-constrained devices includes: a task acquisition and allocation module, a task calculation module, a public content acquisition module, a proof structure output module, and a complete verification module;

[0059] The task acquisition and allocation module is used to acquire the target task to be verified and convert it into a Boolean gate circuit; acquire the original private input and split it into multiple input shares;

[0060] The task calculation module is used to perform local calculations based on the corresponding input shares and the Boolean gate circuits to obtain the corresponding local view and common output value.

[0061] The public content acquisition module is used to perform hash calculations on all the local views to obtain a view hash commitment set; to obtain a random challenge based on the view hash commitment set and the public output value; and to obtain public content based on the random challenge.

[0062] The proof structure output module is used to assemble the compressed proof for this round based on the random challenge generated in each round of computation, the public content, the public output value, and the set of view hash commitments; and to obtain the complete compressed zero-knowledge proof structure based on the compressed proof for this round of computation across all rounds.

[0063] The complete verification module is used to perform integrity verification based on the compressed zero-knowledge proof structure to obtain an effective compressed zero-knowledge proof structure.

[0064] As can be seen from the above technical solution, compared with the prior art, the present invention discloses a zero-knowledge proof compression method and system suitable for resource-constrained devices, which has the following beneficial effects:

[0065] 1. This invention introduces mask parameters in each round of challenges, marks and selects key fields in the view for verification (such as input shares, communication segments, partial gate outputs, etc.), significantly reduces the amount of data transmission while ensuring verifiability, and achieves a high compression ratio proof structure.

[0066] 2. This invention proposes a method based on S≈(1-δ·γ). λ The security estimation model allows users to flexibly configure the preset ratio δ and the total number of challenge rounds λ according to actual security needs and computing resource constraints, thereby achieving a controllable and refined trade-off between proof security and generation and verification performance.

[0067] 3. Even if only some fields are disclosed, this invention still retains the complete set of hash commitments for the view and achieves authenticity and consistency guarantees under the compressed view structure by randomly challenging the correspondence verification of the specified fields, thereby ensuring that the compressed zero-knowledge proof has complete verifiability.

[0068] 4. The proof system structure constructed by this invention can be deployed on resource-constrained devices such as browser plugins, mobile terminals, IoT chips, and embedded modules. It has the characteristics of being lightweight, low-power consumption, and cross-platform, and is widely applicable to various privacy computing scenarios such as edge computing and on-chain verification.

[0069] 5. This invention provides various λ, δ, and θ combination configuration templates (such as security priority, performance priority, and balanced mode), and supports automated optimization based on platform resource conditions (such as CPU performance, memory capacity, and bandwidth conditions), outputting a minimal and acceptable proof structure, further enhancing the system's flexibility and engineering practicality. Attached Figure Description

[0070] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0071] Figure 1 The present invention provides a flowchart of a zero-knowledge proof compression method applicable to resource-constrained devices.

[0072] Figure 2 Flowchart of the method for setting a security control lower limit for the compressed zero-knowledge proof structure provided by this invention.

[0073] Figure 3 This invention provides a schematic diagram of a zero-knowledge proof compression system suitable for resource-constrained devices. Detailed Implementation

[0074] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0075] Example 1

[0076] like Figure 1 As shown, this embodiment of the invention discloses a zero-knowledge proof compression method suitable for resource-constrained devices, comprising:

[0077] Obtain the target task to be verified and convert it into a Boolean gate circuit;

[0078] Obtain the original private input and split it into multiple input shares;

[0079] Local calculations are performed based on the corresponding input shares and Boolean gates to obtain the corresponding local view and common output value.

[0080] A set of view hash commitments is obtained by performing hash calculations on all local views respectively.

[0081] Random challenges are derived based on the view hash commitment set and the public output value;

[0082] Content is made public based on random challenges;

[0083] The compacted proof for each round is composed of the set of random challenges, public content, public output values, and view hash commitments generated in each round of computation;

[0084] Based on the current round of compressed proofs across all computation rounds, a complete compressed zero-knowledge proof structure is obtained;

[0085] Integrity verification is performed based on the compressed zero-knowledge proof structure, resulting in an effective compressed zero-knowledge proof structure.

[0086] Example 2

[0087] This invention discloses a zero-knowledge proof compression method suitable for resource-constrained devices, comprising:

[0088] Obtain the target task to be verified and convert it into a Boolean gate circuit.

[0089] Preferably, the Boolean gate circuit is obtained, specifically including:

[0090] Based on the target task, it is converted into a formal, verifiable statement;

[0091] Based on the conversion of verifiable statements into equivalent Boolean gates;

[0092] Boolean gates consist of basic logic gates and define the complete logical flow of function execution.

[0093] Preferably, in this embodiment, the target task to be verified refers to a proposition or statement that needs to be verified using zero-knowledge proof, such as "a certain number is greater than a certain threshold" or "a person has a certain attribute".

[0094] Verifiable statements are defined as: whether a private input satisfies a set of logical constraints, produces the expected computational output, or follows a predetermined computational path; for example, they can be used to verify whether a set of private inputs meets authentication conditions, meets numerical threshold limits, or correctly executes a specific function computation.

[0095] Preferably, the Boolean gate circuit consists of basic logic gates (such as AND gates and XOR gates), which defines the complete logical flow of function execution and provides a computational path that can be accurately traced for subsequent multi-party simulation execution; its input is the input share of the original private input, and its output is the verifiable computation result.

[0096] Obtain the original private input and split it into multiple input shares.

[0097] Preferably, to protect input privacy, the original private input is split into n input shares based on secret sharing technology (such as XOR sharding).

[0098] Preferably, in this implementation, the prover splits the original private input into n input shares based on secret sharing technology (such as XOR sharding) and distributes them to each virtual participant.

[0099] Preferably, in this embodiment, the original private input refers to the private data itself upon which the proposition or computation task depends; it is the input variable of the task, but the verifier should not know it. For example: Verification task: "User's age is greater than 18"; Original private input: User's real age (e.g., 23); Public output value: True.

[0100] Based on the corresponding input shares and Boolean gates, local calculations are performed to obtain the corresponding local view and common output value.

[0101] Preferably, the corresponding local view is obtained, specifically including:

[0102] Based on each input share and protocol requirements, perform local calculations corresponding to the circuit logic of the Boolean gate circuit, and generate calculation records;

[0103] When multiple participants need to exchange partial data or apply preprocessed values ​​from other participants to complete local computation, information exchange is conducted with the participants, and the corresponding sent and / or received messages are recorded as communication information.

[0104] The corresponding local view is composed of the corresponding input shares, calculation records, and communication information.

[0105] Preferably, in this embodiment, the prover simulates n virtual participants jointly executing the Boolean gate circuit locally. The prover simulates the local computation process of each virtual participant in the Boolean gate circuit in turn. Each virtual participant performs local operations corresponding to the circuit logic of the Boolean gate circuit according to its own input share and protocol requirements. During the entire simulation operation, the prover records the local view of each virtual participant. The local view fully reflects the local visible state of the participant during the protocol execution process. n local views are generated in each round.

[0106] Preferably, when the computation of certain gates during local computation cannot be completed independently by a single participant in the MPC protocol, communication is required. For example, in most shared MPC protocols, XOR gates can be computed locally, but AND gates typically require multiple participants to exchange partial data or use preprocessed values ​​to complete. In this case, information exchange with the participants will occur, and the corresponding sent and / or received messages will be recorded as communication information.

[0107] Preferably, in this embodiment, the protocol requirements refer to the MPC-in-the-Head protocol's specifications for the execution process and behavior, such as how to handle input shares, when to send or receive messages, and how to use randomness. The protocol requirements are derived from specific protocol specifications (such as ZKBoo, ZKB++, etc.) and are used to ensure that the simulated execution process is consistent with the real MPC protocol.

[0108] Preferably, the locally visible state refers to all the information that a virtual participant can "see" or "know" during the simulation execution, namely, its input share, its self-generated random numbers, messages sent to other participants, and messages received from other participants. This information constitutes a local perspective of the party's protocol execution, which is the core principle in simulating real multi-party computation that "each party can only see its own part".

[0109] Preferably, the calculation record includes: intermediate results generated during the calculation and random values ​​used.

[0110] Preferably, each local view includes the following information:

[0111] The corresponding input share;

[0112] Randomness generated internally by the protocol (such as random bits, mask values);

[0113] All messages sent to other virtual participants;

[0114] All messages received from other virtual participants.

[0115] Preferably, once all virtual participants have completed all simulation steps from input distribution and logic gate computation to communication interaction, a complete set of virtual multi-party execution transcripts is formed. This transcript consists of n local views and will serve as the basic data source for hash commitment generation, challenge selection, and view compression in the subsequent proof structure.

[0116] A set of view hash commitments is obtained by performing hash calculations on all local views respectively.

[0117] Preferably, the prover has a local view (i.e., view1, view2, ..., view) for each virtual participant. n Perform hash operations on each view to generate corresponding view hash commitments: H(view1), H(view2), ..., H(view... n ); where H represents hash calculation.

[0118] Preferably, in this embodiment, the hash calculation can employ a standard cryptographic hash algorithm (such as SHA-256) to ensure the immutability and concealment of the content of the local view in subsequent processes. Each view hash commitment is bound to a specific local view as an unforgeable structure digest for that round of simulation execution.

[0119] Preferably, all view hash commitment values ​​will be uniformly recorded and used as public input for subsequent challenge generation, thereby supporting the challenge consistency and security of the entire non-interactive zero-knowledge proof structure.

[0120] A random challenge is obtained based on the view hash commitment set and the public output value.

[0121] Preferably, a random challenge is obtained, specifically including:

[0122] The pseudo-random seed is obtained by inputting the view hash commitment set and the public output value into the cryptographic hash function;

[0123] A random challenge based on pseudo-random seed generation includes a set of view indexes and mask parameters.

[0124] Preferably, the present invention employs the Fiat–Shamir conversion mechanism, combined with preset challenge parameters, to automatically generate multiple rounds of non-interactive random challenges, which drive subsequent view selection and field validation.

[0125] Preferably, the method for obtaining the view index set is as follows:

[0126] A local view with a preset ratio is randomly selected from all local views as the verification view;

[0127] A view index set is formed based on the view numbers corresponding to all the validation views.

[0128] Preferably, in this embodiment, the preset ratio δ∈(0,1] is used to control the proportion of the verified view in each round, and can be flexibly set according to different security and performance requirements.

[0129] Preferably, the mask parameter includes four fields arranged in sequence:

[0130] The first field indicates whether the input share is public;

[0131] The second field indicates whether the randomness of the protocol is publicly disclosed;

[0132] The third field indicates whether the message is sent publicly;

[0133] The fourth field indicates whether to publicly receive messages;

[0134] When the information is made public, the corresponding bit value of the field is set to 1; when the information is not made public, the corresponding bit value of the field is set to 0.

[0135] Preferably, for each selected public verification view, the field exposure strategy in the verification view is controlled based on the mask parameter θ, where θ∈{0,1}. 4 For example, if θ = 1111, it means that full field validation is performed on the exposed view; if θ = 1010, only the input share and the sent message are exposed. This mask parameter θ can be statically set to a fixed strategy, or it can be dynamically generated based on a seed to achieve more flexible security-performance tuning and support fine-grained control over each view field.

[0136] Content is made public based on random challenges.

[0137] Preferably, the disclosed content includes:

[0138] Based on the view index set index, obtain the corresponding δ·n verification views;

[0139] Based on the bit values ​​of each bit of the mask parameter δ, the corresponding public field content is extracted from the verification view as public content.

[0140] The compacted proof for each round is composed of a set of random challenges, public content, public output values, and view hash commitments generated in each round of computation.

[0141] The complete compressed zero-knowledge proof structure is obtained based on the current-round compressed proofs from all computation rounds.

[0142] A preferred, complete compressed zero-knowledge proof structure includes: random challenges for all rounds, public content for all rounds, public output values ​​for all rounds, and a set of view hash commitments for all rounds; the set of view hash commitments is used to bind the view content to prevent tampering.

[0143] Preferably, the final generated complete compressed zero-knowledge proof structure π is compact and verifiable, and can be independently verified by the verifier without touching the complete input, ensuring the correctness of the calculation and the confidentiality of the input. The whole process does not require interaction and meets the requirements of non-interactive zero-knowledge proof (NIZK).

[0144] Preferred, such as Figure 2 As shown, it also includes: setting a lower bound for security controls based on a compressed zero-knowledge proof structure:

[0145] The total number of challenge rounds is based on all calculated rounds.

[0146] The four bits in the mask parameter are mapped to values ​​between 0 and 1, which serve as the effective verification coverage parameter.

[0147] The total probability of successful forgery of the compressed zero-knowledge proof structure is obtained by using the total number of challenge rounds, effective verification coverage parameter, and preset ratio as security parameters.

[0148] Determine whether the total probability of successful forgery is less than or equal to the security threshold;

[0149] If so, then the lower limit of safety control is met;

[0150] Otherwise, adjust the safety parameters and repeat the above judgment process until the lower safety control limit is met.

[0151] Preferably, the effective verification coverage parameter γ is specifically:

[0152] γ = weight(θ) / 4;

[0153] Here, weight(θ) represents the number of bits in θ that are 1.

[0154] Preferably, the effective validation coverage parameter γ is used to characterize the proportion of validateable fields in each challenged view, for example:

[0155] (Validation of all fields);

[0156] (Verify input share and send message);

[0157] (Only input shares are verified.)

[0158] Preferably, the purpose of defining the effective verification coverage parameter γ is to map the four-bit field mask parameter θ to a value between 0 and 1, used to quantify the proportion of actually exposed, verifiable fields in each challenged view. Compared to directly using a bit combination such as θ = 1010, γ provides a unified metric.

[0159] Preferably, the total probability S of successful forgery is as follows:

[0160] S≈(1-δ·γ) λ ;

[0161] Where λ represents the total number of challenge rounds, γ represents the effective verification coverage parameter, and δ represents the preset ratio.

[0162] Preferably, the developer presets λ, δ, and θ based on platform capabilities and security levels; or automatically selects the optimal λ-δ-θ combination based on current device resources (such as CPU, memory, and network bandwidth), ensuring that the total probability of successful forgery is less than or equal to the security threshold. In this implementation, the security threshold is set to 2. -40 That is, satisfying S≤2 -40 .

[0163] Preferably, by reasonably setting the combination of λ, δ, and θ, the total probability of successful forgery S can be ensured to reach a negligible level, as shown in Table 1:

[0164] Table 1. Total probability of successful forgery S corresponding to different combinations of λ, δ, and θ

[0165] λ δ θ γ S 80 2 / 3 1111 1.00 <![CDATA[≈2 -46 ]]> 100 1 / 2 1010 0.50 <![CDATA[≈2 -25 ]]> 140 1 / 4 1000 0.25 <![CDATA[≈2 -10 ]]>

[0166] Preferably, the present invention provides an adjustable security control strategy for flexibly adjusting the generation and verification structure of zero-knowledge proofs according to resource conditions (such as communication bandwidth, computing power, and security level) in different application scenarios. This strategy is based on three core security parameters: λ, δ, and θ; by adjusting the combination of λ, δ, and θ, a clear and controllable trade-off can be achieved between security and performance (communication and computing overhead).

[0167] Preferably, λ represents the total number of rounds of simulated execution in the MPC-in-the-Head protocol; in each round, some view fields are selected from multiple views for verification based on random challenges generated by Fiat-Shamir; the more rounds there are, the lower the probability of an attacker successfully forging, but the proof generation time and overall size also increase.

[0168] Preferably, δ represents the proportion of the number of local views that need to be verified in each round to all virtual participants. For example, δ = 2 / 3 means that 2 / 3n views are selected from n local views for verification in each round. The larger δ is, the more complete the verification information obtained by the verifier and the higher the security, but the larger the proof size after compression.

[0169] Preferably, θ represents the field bitmask that needs to be exposed in each verified view, in the form of a 4-bit parameter. θ can be set uniformly (e.g., fully exposed θ = 1111) or dynamically generated to achieve more flexible field-level security control. A smaller θ means that each view exposes less information, thereby reducing the risk of leakage and proof volume, but it may be necessary to increase λ or δ to maintain sufficient verification coverage.

[0170] Integrity verification is performed based on the compressed zero-knowledge proof structure, resulting in an effective compressed zero-knowledge proof structure.

[0171] Preferred integrity verification specifically includes:

[0172] Based on the compressed zero-knowledge proof structure, the random challenge, hash commitment value set, input share, communication information, and common output value of all computation rounds are extracted;

[0173] The local view is reconstructed based on a random challenge, and a hash calculation is performed to obtain a verification hash value.

[0174] Determine whether the verification hash value matches the corresponding hash commitment value in the hash commitment value set;

[0175] If not, the verification fails;

[0176] If so, then perform local circuit calculations in the Boolean gate circuit based on the input share and communication information to obtain the calculation result;

[0177] Determine whether the calculation result is consistent with the common output value;

[0178] If not, the verification fails;

[0179] If so, then determine whether the random challenge is complete;

[0180] If not, the verification fails;

[0181] If so, then the verification proves that the compressed zero-knowledge proof structure is complete and valid.

[0182] Preferably, after receiving the compressed zero-knowledge proof structure π, the verifier can independently complete the entire verification process based on the challenge content and publicly available fields contained therein without interacting with the prover.

[0183] Preferably, the challenge structure is parsed: λ sets of random challenges contained in the compressed zero-knowledge proof structure π are read round by round; each random challenge explicitly specifies: the view index set, mask parameter θ, and corresponding common output value y for this round. Based on the parsed compressed zero-knowledge proof structure, the following are performed sequentially: view hash commitment consistency verification, local replay calculation result verification, and random challenge integrity and binding verification.

[0184] Preferably, the view hash commitment consistency verification is as follows: For each round of challenges, the verifier extracts the field data of the exposed view (such as input share, protocol randomness, communication message, etc.) from π; according to the field bits set in θ, the exposed part of each view is reassembled; the reassembled data is hashed to determine whether the verification hash value is consistent with the hash commitment value provided in π; if the hash is inconsistent, it is proven to be invalid and the verification fails.

[0185] Preferably, the local replay calculation result verification is performed as follows: For the local view that is exposed in each round, the verifier replays the circuit logic locally based on the input share and communication information to verify whether the local execution trajectory corresponding to these views correctly derives the common output value y declared in π; if the calculation result is inconsistent with y, it is proven to be invalid.

[0186] Preferably, the random challenge integrity and binding verification is performed as follows: check whether all λ rounds of random challenges satisfy independence and structural integrity; ensure that all random challenges, hash commitments, and public field data are mutually bound and cannot be tampered with; if any random challenge is found to have structural duplication or illegal combination (such as duplicate view indexes or illegal θ bits), the proof is rejected.

[0187] Preferably, if all three steps of the above λ rounds pass the verification, the proof is accepted and the original statement is considered true; otherwise, the proof is rejected and the original statement is considered unreliable.

[0188] Example 3

[0189] like Figure 3 As shown, a zero-knowledge proof compression system suitable for resource-constrained devices includes: a task acquisition and allocation module, a task calculation module, a public content acquisition module, a proof structure output module, and a complete verification module;

[0190] The task acquisition and allocation module is used to acquire the target task to be verified and convert it into a Boolean gate circuit; acquire the original private input and split it into multiple input shares;

[0191] The task calculation module is used to perform local calculations based on the corresponding input shares and Boolean gates to obtain the corresponding local view and common output value.

[0192] The public content acquisition module is used to perform hash calculations on all local views to obtain a set of view hash commitments; obtain a random challenge based on the set of view hash commitments and the public output value; and obtain public content based on the random challenge.

[0193] The proof structure output module is used to assemble the compressed proof for this round based on the random challenge, public content, public output value, and view hash commitment set generated in each round of computation; the complete compressed zero-knowledge proof structure is obtained based on the compressed proof for this round of computation across all rounds.

[0194] The complete verification module is used to perform integrity verification based on the compressed zero-knowledge proof structure, resulting in an effective compressed zero-knowledge proof structure.

[0195] Preferably, the functions of each module in this embodiment correspond one-to-one with the above-described method, and will not be described in detail here.

[0196] Preferably, the five functional modules of the aforementioned zero-knowledge proof compression system suitable for resource-constrained devices can be integrated into the device, browser plugin, or mobile application via software. Alternatively, they can be deployed as a lightweight server via edge computing nodes, combining with blockchain smart contracts or external validators for joint verification. The system supports parameter configuration interfaces, allowing users to set challenge ratios, security levels, and verification depths as needed in different application scenarios, achieving the goals of lightweight, adjustable, and practical ZKP systems.

[0197] Preferably, the zero-knowledge proof compression system proposed in this invention, suitable for resource-constrained devices, features lightweight structure, high compression ratio, adjustable security parameters, and strong platform adaptability. It can be widely applied in various real-world scenarios with high requirements for privacy protection and verifiability but limited resource capabilities. Several typical application examples and system deployment modes are listed below.

[0198] 1. Device verification and reliable data reporting at the IoT chip level

[0199] In Internet of Things (IoT) scenarios, edge devices (such as sensor nodes, smart meters, and gateway controllers) typically have limited computing power, making it difficult to run large-scale encryption protocols. This invention can deploy a proof module within the terminal device, enabling the device to perform this operation without exposing plaintext data.

[0200] The circuit is constructed locally, and the ZKP is simulated and generated.

[0201] Compress a portion of the view using mask parameters;

[0202] Lightweight zero-knowledge proofs are reported to the server or on-chain validator along with the data;

[0203] It supports dynamic configuration of λ-δ-θ to achieve a balance between communication bandwidth and security.

[0204] This mode is suitable for high-security data scenarios such as smart grids, industrial IoT, and smart buildings.

[0205] 2. User privacy proof in browser plugins or WebAssembly environments

[0206] This invention can be integrated into front-end systems (such as browser plugins, web applications, and mobile H5 pages), using JavaScript or WebAssembly to implement a lightweight ZKP generator for the following scenarios:

[0207] Users can generate zero-knowledge proofs locally for privacy data such as identity, attributes, and behavior.

[0208] The proof structure is compressed and uploaded via API for verification by the server or on-chain contract;

[0209] It does not rely on a Trusted Execution Environment (TEE) or hardware protection, and is easy to deploy and cross-platform.

[0210] It is applied to fields such as anonymous login, privacy voting, Web3 authentication, and browser plugin wallets.

[0211] For example, a wallet plugin can locally prove that "the user's balance is greater than the transfer amount" before initiating a transaction without revealing the balance value. The proof used is only a few KB, and the verification latency is extremely low.

[0212] 3. Biometric verification and local authentication in wearable devices

[0213] Wearable devices (such as smartwatches and fitness trackers) have some local computing power but limited communication capabilities. This invention can be used for:

[0214] Biometric features (such as heart rate patterns, gait characteristics, location information, etc.) are used to construct verification statements;

[0215] Generate a structurally compressed ZKP on the device side to ensure that the data comes from the device itself;

[0216] To achieve remote trusted authentication or service authorization without uploading the original data.

[0217] This type of ZKP can be used in applications such as medical insurance terminals, sports performance reporting, and behavioral identity binding.

[0218] 4. On-chain verification in blockchain contracts

[0219] Combined with blockchain applications, the compressed zero-knowledge proof structure constructed in this invention can be directly verified on the smart contract chain, and is suitable for:

[0220] On-chain asset proof (e.g., "someone owns a certain NFT type but does not disclose its ID");

[0221] Anonymous voting system (users submit their votes ZKP on-chain, and the contract verifies vote ∈ choice set);

[0222] Multi-party collaborative decision-making platform (different nodes generate ZKP proofs for the validity of local computation);

[0223] In structures such as Layer2, Rollup, and ZK-bridge, the cost of on-chain verification is reduced.

[0224] Compared to traditional SNARKs, MPCitH structure verification does not require pairing or large number field operations, making it suitable for direct execution of EVM and WASM contracts.

[0225] 5. Recommendations for a unified deployment architecture

[0226] This invention can be integrated according to the following architecture pattern based on actual system deployment requirements:

[0227] Standalone local mode: All modules are deployed on the same terminal device (such as chip, mobile phone, browser);

[0228] Client-server model: The prover module is deployed on the terminal, and the validator is deployed on the cloud platform or on-chain contract;

[0229] Embedded lightweight SDK mode: The providing / verifying module is encapsulated as an SDK for third-party integration;

[0230] Hybrid off-chain and on-chain mode: Proof generation is completed off-chain, while structural verification is executed on-chain, enabling trusted delivery of privacy computation results.

[0231] In summary, this invention possesses excellent portability, compressibility, and verifiability, effectively solving the problem of difficult deployment of existing MPC-in-the-Head solutions on real devices. It is suitable for use in various security-sensitive and resource-constrained environments and has broad prospects for industrialization.

[0232] Example 4

[0233] Based on the same inventive concept, the present invention also provides a computer device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0234] Memory, used to store computer programs;

[0235] When the processor executes a program stored in memory, it is able to implement a zero-knowledge proof compression method suitable for resource-constrained devices, as described in Embodiment 1 or 2.

[0236] The electronic device may include a processor, a communications interface, memory, and a communication bus, wherein the processor, communications interface, and memory communicate with each other via the communication bus. The processor can invoke logical instructions in the memory to execute a zero-knowledge proof compression method suitable for resource-constrained devices, as described in Embodiment 1 or 2.

[0237] Furthermore, 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, essentially, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0238] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0239] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A zero-knowledge proof compression method suitable for resource-constrained devices, characterized in that, include: Obtain the target task to be verified and convert it into a Boolean gate circuit; Obtain the original private input and split it into multiple input shares; Based on the corresponding input shares and the Boolean gate circuit, local calculations are performed to obtain the corresponding local view and common output value; A hash calculation is performed on each of the local views to obtain a set of view hash commitments. A random challenge is obtained based on the view hash commitment set and the public output value; The publicly available content is derived based on the aforementioned random challenge; The compacted proof for this round is composed of the random challenge generated in each round of computation, the public content, the public output value, and the set of view hash commitments. Based on the current round of compressed proofs from all computation rounds, a complete compressed zero-knowledge proof structure is obtained; Integrity verification is performed based on the compressed zero-knowledge proof structure to obtain an effective compressed zero-knowledge proof structure.

2. The zero-knowledge proof compression method for resource-constrained devices according to claim 1, characterized in that, The Boolean gate circuit is obtained by means of: Based on the target task, it is converted into a formal, verifiable statement; Based on the verifiable statement, it is converted into an equivalent Boolean gate circuit; The Boolean gate circuit consists of basic logic gates and defines the complete logical flow of function execution.

3. The zero-knowledge proof compression method for resource-constrained devices according to claim 1, characterized in that, Obtain the corresponding local view, specifically including: Based on each input share and protocol requirement, perform local computation corresponding to the circuit logic of the Boolean gate circuit to generate a computation record; When the local computation process requires multiple participants to exchange partial data or apply other participants' preprocessed values ​​to complete the local computation, information interaction is performed with the participants, and the corresponding sent and / or received messages are recorded as communication information. The corresponding local view is formed based on the corresponding input share, the calculation record, and the communication information.

4. The zero-knowledge proof compression method for resource-constrained devices according to claim 3, characterized in that, You will receive random challenges, including: The pseudo-random seed is obtained by inputting the view hash commitment set and the public output value into the cryptographic hash function. The random challenge is generated based on the pseudo-random seed, which includes a set of view indexes and mask parameters.

5. A zero-knowledge proof compression method for resource-constrained devices according to claim 4, characterized in that, The method for obtaining the view index set is as follows: A preset ratio of the local views is randomly selected as the verification view based on all the local views; The view index set is composed of the view numbers corresponding to all the verification views.

6. The zero-knowledge proof compression method for resource-constrained devices according to claim 5, characterized in that, The mask parameter includes four fields arranged in sequence: The first field indicates whether the input share is made public; The second field indicates whether the randomness of the protocol is publicly disclosed; The third field indicates whether the message is publicly disclosed; The fourth field indicates whether the received message is made public; When the information is made public, the corresponding bit value of the field is set to 1; when the information is not made public, the corresponding bit value of the field is set to 0.

7. A zero-knowledge proof compression method for resource-constrained devices according to claim 6, characterized in that, The disclosed content includes, in particular: The corresponding verification view is obtained based on the view index set. Based on the bit values ​​of each bit of the mask parameter, the corresponding public field content is extracted from the verification view as the public content.

8. A zero-knowledge proof compression method for resource-constrained devices according to claim 6, characterized in that, Also includes: Based on the aforementioned compressed zero-knowledge proof structure, a lower bound for security control is set: The total number of challenge rounds is based on all the calculated rounds. The four bits in the mask parameter are mapped to values ​​between 0 and 1, which serve as valid verification coverage parameters. The total probability of successful forgery of the compressed zero-knowledge proof structure is obtained based on the total number of challenge rounds, the effective verification coverage parameter, and the preset ratio as security parameters. Based on the total probability of successful forgery, determine whether it is less than or equal to the security threshold; If so, then the lower limit of safety control is met; Otherwise, adjust the safety parameters and repeat the above judgment process until the safety control lower limit is met.

9. A zero-knowledge proof compression method for resource-constrained devices according to claim 6, characterized in that, The integrity verification specifically includes: Based on the compressed zero-knowledge proof structure, the random challenge, the set of hash commitment values, the input share, the communication information, and the common output value for all computation rounds are extracted; Based on the random challenge, the local view is reconstructed and hashed to obtain the verification hash value; Determine whether the verification hash value is consistent with the corresponding hash commitment value in the hash commitment value set; If not, the verification fails; If so, then based on the input share and the communication information, perform local circuit calculations in the Boolean gate circuit to obtain the calculation result; Determine whether the calculation result is consistent with the common output value; If not, the verification fails; If so, determine whether the random challenge is complete; If not, the verification fails; If so, then the verification proves that the compressed zero-knowledge proof structure is complete and valid.

10. A zero-knowledge proof compression system for resource-constrained devices, used to execute a zero-knowledge proof compression method for resource-constrained devices as described in any one of claims 1-9, characterized in that, include: The module includes a task acquisition and allocation module, a task calculation module, a public content acquisition module, a proof structure output module, and a complete verification module. The task acquisition and allocation module is used to acquire the target task to be verified and convert it into a Boolean gate circuit; acquire the original private input and split it into multiple input shares; The task calculation module is used to perform local calculations based on the corresponding input shares and the Boolean gate circuits to obtain the corresponding local view and common output value. The public content acquisition module is used to perform hash calculations on all the local views to obtain a view hash commitment set; and to obtain a random challenge based on the view hash commitment set and the public output value. The publicly available content is derived based on the aforementioned random challenge; The proof structure output module is used to assemble the compressed proof for this round based on the random challenge generated in each round, the public content, the public output value, and the set of view hash commitments. Based on the current round of compressed proofs from all computation rounds, a complete compressed zero-knowledge proof structure is obtained; The complete verification module is used to perform integrity verification based on the compressed zero-knowledge proof structure to obtain an effective compressed zero-knowledge proof structure.

Images