Zero-knowledge privacy verification method and system based on parameterized circuit

Abstract

The application discloses a zero-knowledge privacy verification method and system based on a parameterized circuit, after receiving hierarchical business rule definitions and original request data, the method and system flatten the hierarchical business rule definitions and the original request data into a rule parameter vector and a private data vector through depth-first traversal and path encoding; according to the number of fields of the rule parameter vector, a target verification circuit is adaptively selected from a multi-specification general circuit resource pool; the rule parameter vector is loaded as a public input and the private data vector is loaded as a private input into the target verification circuit, dynamic checking is performed, and a zero-knowledge proof is generated; and the zero-knowledge proof and the rule parameter vector are submitted to an on-chain verification contract for verification. Through the parameterized circuit and the adaptive selection mechanism, the application realizes decoupling of business rules and verification circuits, effectively solves the problems of poor scalability, high operation and maintenance cost and the inability to flexibly adapt to dynamic changes of business existing in the prior art static special circuit scheme, and significantly improves the flexibility and resource utilization efficiency of the system.

Description

Technical Field

[0001] This invention relates to the field of data privacy protection technology, and in particular to a zero-knowledge privacy verification method and system based on parameterized circuits. Background Technology

[0002] Zero-knowledge proofs, as a cryptographic protocol that enables the prover to confirm the truth of a statement to the verifier without revealing any private information, have been widely applied in fields such as blockchain, privacy computing, and data compliance verification. Their core lies in constructing an arithmetic circuit to transform the business logic to be verified into a set of polynomial constraints. In trusted data exchange and on-chain verification applications, the industry commonly adopts zero-knowledge proof schemes based on static dedicated circuits, such as frameworks like Gnark or Circom. Figure 1 As shown, in this scheme, for each specific business data model, developers need to manually write a dedicated set of arithmetic circuit code. The number of input / output ports, signal names, and internal constraint logic of this circuit are completely fixed at compile time and correspond one-to-one with an on-chain verification contract. When a new business model emerges or the rules of the existing model change, the entire process of circuit development, compilation, trust setup, and contract deployment must be completely repeated.

[0003] However, this static, dedicated "one circuit per task" model has significant drawbacks in practical applications. First, the system's scalability is extremely poor; maintenance costs increase linearly or even exponentially with the number of business models, as each different data model requires an independent set of circuits and contracts. Second, this solution cannot adapt to the dynamic nature of business operations. Any minor change in business rules, such as adjusting the numerical range of a field or adding an optional field, is equivalent to a change in the circuit logic, requiring the entire circuit to be modified, compiled, and deployed again, leading to system rigidity and slow response. Finally, resource utilization is low. Because circuit resource allocation is fixed, even a simple model requiring verification of only a few fields must occupy the resources of a complete circuit, resulting in wasted storage and computing resources. Conversely, a complex model with a large number of fields may be limited by the preset capacity of a single circuit and cannot be processed, or may need to be split, increasing the complexity of proofs and verification costs. The root of these problems lies in the fact that existing technologies tightly couple business logic with the circuit structure, making the circuit itself lack versatility and flexibility, and unable to meet the verification needs of large-scale, dynamically changing business operations. Summary of the Invention

[0004] In view of this, the purpose of this invention is to propose a zero-knowledge privacy verification method and system based on parameterized circuits. By parameterizing business rules and decoupling them from general verification circuits, a single circuit can adapt to various dynamically changing verification tasks, solving the problems of poor scalability, high maintenance costs, and inability to flexibly respond to business changes in existing static dedicated circuit solutions.

[0005] To achieve the aforementioned technical objectives, in a first aspect, this application provides a zero-knowledge privacy verification method based on parameterized circuits, comprising:

[0006] Receive the hierarchical business rule definitions to be verified and the original request data to be verified;

[0007] The hierarchical business rule definition is subjected to depth-first traversal and path encoding operations, and is flattened into a rule parameter vector consisting of multiple field rule units arranged in sequence. Each field rule unit defines the constraint conditions of the corresponding field.

[0008] At the same time, depth-first traversal and path encoding operations are performed on the original request data to generate a private data vector that is aligned one by one with the field rule units in the rule parameter vector;

[0009] Based on the number of field rule units contained in the rule parameter vector, the target verification circuit is adaptively selected from the pre-built multi-specification general circuit resource pool, which contains various parameterized verification circuit instances with different input capacities.

[0010] The rule parameter vector is used as public input and the private data vector is used as private input. The target verification circuit is loaded into the target verification circuit. The target verification circuit executes the constraints defined by the field rule unit, performs dynamic verification logic on the corresponding data values ​​in the private data vector, and generates zero-knowledge proof.

[0011] The zero-knowledge proof and the rule parameter vector are submitted to the on-chain verification contract for verification. The on-chain verification contract selects the corresponding verification key according to the length of the rule parameter vector, executes the verification algorithm, and outputs the verification result.

[0012] In some embodiments, a depth-first traversal and path encoding operation is performed on the hierarchical business rule definition to flatten it into a rule parameter vector consisting of multiple field rule units arranged sequentially, including:

[0013] A depth-first traversal is performed on the hierarchical business rule definition to generate an access sequence containing all leaf nodes;

[0014] For each leaf node in the access sequence, a unique path identifier is generated based on its access path defined in the hierarchical business rules.

[0015] Based on the constraint information declared by each leaf node in the hierarchical business rule definition, construct the corresponding field rule unit. The field rule unit shall at least contain a path identifier and a parameterized constraint description that represents the constraint type of the leaf node.

[0016] All constructed field rule units are arranged in the order of the access sequence to form a rule parameter vector.

[0017] In some embodiments, depth-first traversal and path encoding operations are performed on the original request data to generate a private data vector that is aligned one-to-one with the field rule units in the rule parameter vector, including:

[0018] Perform a depth-first traversal on the original request data to generate a data access sequence containing all data leaf nodes;

[0019] For each data leaf node in the data access sequence, generate a corresponding data path identifier based on its access path in the original request data;

[0020] The data value of each data leaf node is converted into a format that can be processed by the zero-knowledge proof circuit, and combined with the corresponding data path identifier to form a private data unit.

[0021] All the private data units formed are arranged in the order of the data access sequence to generate a private data vector. The data path identifier of each private data unit in the private data vector is matched with the path identifier of the field rule unit in the same order position in the rule parameter vector, thereby achieving one-to-one alignment.

[0022] In some embodiments, a target verification circuit is adaptively selected from a pre-built multi-specification general-purpose circuit resource pool based on the number of field rule units contained in the rule parameter vector. This multi-specification general-purpose circuit resource pool contains various parameterized verification circuit instances with different input capacities, including:

[0023] Obtain the effective length of the rule parameter vector, which is equal to the number of field rule units it contains;

[0024] The effective length is compared with multiple predefined standard capacity specifications in the multi-specification general-purpose circuit resource pool;

[0025] If a standard capacity specification that perfectly matches the effective length exists, then the parameterized verification circuit instance corresponding to that standard capacity specification is selected as the target verification circuit.

[0026] If no perfectly matching standard capacity specification exists, then select the parameterized verification circuit instance corresponding to the smallest standard capacity specification with a capacity greater than the effective length from the multi-specification general circuit resource pool as the target verification circuit.

[0027] In some embodiments, if no perfectly matching standard capacity specification exists, a parameterized verification circuit instance corresponding to the smallest standard capacity specification with a capacity greater than the effective length is selected from the multi-specification general circuit resource pool as the target verification circuit, including:

[0028] Calculate the resource waste rate between the effective length and each standard capacity specification in the multi-specification general-purpose circuit resource pool that is larger than the effective length;

[0029] Based on the calculated resource waste rate and the request frequency characteristics defined by the hierarchical business rules, an adaptive selection decision is executed, including:

[0030] If the resource waste rate is lower than the preset waste threshold, or if the request frequency characteristics indicate that it is a low-frequency request, then the parameterized verification circuit instance corresponding to the minimum standard capacity specification is directly selected as the target verification circuit.

[0031] If the resource waste rate is higher than the preset waste threshold and the request frequency characteristics indicate that it is a high-frequency request, then the asynchronous dynamic compilation process is triggered to generate a parameterized verification circuit instance that is exactly matched for the effective length. The parameterized verification circuit instance is stored in the hot spot cache area of ​​the multi-specification general circuit resource pool for subsequent use. At the same time, the parameterized verification circuit instance corresponding to the minimum standard capacity specification is still used as the target verification circuit.

[0032] In some embodiments, the rule parameter vector is used as public input and the private data vector is used as private input, and both are loaded into the target verification circuit. The target verification circuit internally executes the constraints defined by the field rule unit, performs dynamic verification logic on the corresponding data values ​​in the private data vector, and generates zero-knowledge proofs, including:

[0033] Pair each field rule unit in the rule parameter vector with a private data unit in the same order position in the private data vector;

[0034] For each pair of field rule units and private data units, within the target verification circuit, a consistency check is performed based on the path identifier in the field rule unit and the data path identifier in the private data unit.

[0035] After the consistency check passes, the corresponding constraint checks are performed on the data values ​​in the private data unit according to the parameterized constraint description in the field rule unit.

[0036] When all paired field rule units and private data units pass consistency checks and constraint checks, the target verification circuit generates a zero-knowledge proof based on a non-interactive zero-knowledge proof protocol.

[0037] In some embodiments, according to the parameterized constraint description in the field rule unit, the data values ​​in the private data unit are subjected to corresponding constraint checks, including:

[0038] Parse the parameterized constraint descriptions in the field rule unit to determine one or more constraint check types that need to be performed on the current field;

[0039] Based on the constraint check type, the corresponding constraint check logic module is dynamically invoked from multiple pre-built constraint check logic modules within the target verification circuit to check the data values ​​in the private data unit, including:

[0040] If the constraint check type includes a numerical range check, then the range check module is called to verify whether the data value is within the closed interval formed by the minimum and maximum values ​​declared in the parameterized constraint description.

[0041] If the constraint check type includes enumeration value check, then the enumeration check module is called to verify whether the cryptographic hash value of the data value exists in the set of valid enumeration value hashes declared in the parameterized constraint description;

[0042] If the constraint check type includes a mandatory check, then the existence check module is called to verify whether the data value is a valid value that is non-zero or non-empty.

[0043] When a data value passes the verification of all invoked constraint checking logic modules, the private data unit is determined to have passed the constraint check.

[0044] In some embodiments, the zero-knowledge proof and the rule parameter vector are submitted to an on-chain verification contract for verification. The on-chain verification contract selects the corresponding verification key based on the length of the rule parameter vector, executes the verification algorithm, and outputs the verification result, including:

[0045] The on-chain verification contract receives zero-knowledge proofs and rule parameter vectors.

[0046] The on-chain verification contract retrieves and loads the corresponding target verification key from multiple verification keys based on the length of the rule parameter vector;

[0047] The on-chain verification contract uses the target verification key and the rule parameter vector to execute the zero-knowledge proof verification algorithm on the zero-knowledge proof.

[0048] Based on the execution result of the zero-knowledge proof verification algorithm, a verification result is generated and output. The verification result is used to indicate whether the original request data meets all the constraints defined by the hierarchical business rules.

[0049] In some embodiments, the on-chain verification contract retrieves and loads the corresponding target verification key from multiple verification keys based on the length of the rule parameter vector, including:

[0050] The on-chain verification contract parses the rule parameter vector to determine the number of field rule units it contains;

[0051] Based on the number of field rule units, a query is performed in the verification key mapping table maintained inside the on-chain verification contract. The verification key mapping table stores the association between the number of different field rule units and the corresponding verification keys.

[0052] If the query is successful, the verification key that exactly matches the number of field rule units is extracted from the verification key mapping table and loaded as the target verification key;

[0053] If the query fails, the on-chain verification contract returns a verification failure result and indicates that verification of the rule parameter vector for the number of field rule units is not currently supported.

[0054] In a second aspect, the present invention also provides a zero-knowledge privacy verification system based on parameterized circuits, applicable to the zero-knowledge privacy verification method described in the first aspect. The system includes a data preprocessing module, a circuit resource management module, a proof generation module, and an on-chain verification module. The data preprocessing module receives the hierarchical business rule definition to be verified and the original request data to be verified, and performs depth-first traversal and path encoding operations on the hierarchical business rule definition to generate a rule parameter vector. At the same time, it performs the same depth-first traversal and path encoding operations on the original request data to generate a private data vector that is aligned one-to-one with the field rule units in the rule parameter vector. The circuit resource management module maintains pre-built multi-specification general-purpose circuit resources. The pool, a multi-specification general-purpose circuit resource pool, contains various parameterized verification circuit instances with different input capacities. It adaptively selects the target verification circuit from the pool based on the number of field rule units contained in the rule parameter vector. The proof generation module loads the rule parameter vector as public input and the private data vector as private input into the target verification circuit, driving it to execute dynamic verification logic based on the constraints defined by the field rule units and generating a zero-knowledge proof. The on-chain verification module, deployed on the blockchain network, receives the zero-knowledge proof and the rule parameter vector, selects the corresponding verification key based on the length of the rule parameter vector, executes the zero-knowledge proof verification algorithm, and outputs the verification result.

[0055] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art: The present invention provides a zero-knowledge privacy verification method and system based on parameterized circuits. After receiving hierarchical business rule definitions and original request data, it flattens them into rule parameter vectors and private data vectors through depth-first traversal and path encoding; according to the number of fields in the rule parameter vectors, it adaptively selects a target verification circuit from a multi-specification general-purpose circuit resource pool; it loads the rule parameter vectors as public inputs and the private data vectors as private inputs into the target verification circuit, performs dynamic verification, and generates zero-knowledge proofs; it submits the zero-knowledge proofs and rule parameter vectors to the on-chain verification contract for verification. The present invention, through parameterized circuits and an adaptive selection mechanism, achieves decoupling between business rules and verification circuits, effectively solving the problems of poor scalability, high operation and maintenance costs, and inability to flexibly adapt to dynamic changes in business that exist in existing static dedicated circuit solutions, significantly improving the system's flexibility and resource utilization efficiency. Attached Figure Description

[0056] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 This is a schematic diagram of the zero-knowledge proof scheme based on static dedicated circuits described in the background art;

[0058] Figure 2 This is a schematic diagram of steps S101 to S105 of the zero-knowledge privacy verification method described in the specific implementation.

[0059] Figure 3 This is a schematic diagram of the zero-knowledge privacy verification system described in the specific implementation.

[0060] The reference numerals for the above figures are as follows:

[0061] 1. Preprocessing module;

[0062] 2. Circuit Resource Management Module;

[0063] 3. Proof generation module;

[0064] 4. On-chain verification module. Detailed Implementation

[0065] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0066] Please see Figure 2 In a first aspect, this embodiment provides a zero-knowledge privacy verification method based on parameterized circuits, including:

[0067] S101. Receive the hierarchical business rule definition to be verified and the original request data to be verified;

[0068] S102. Perform depth-first traversal and path encoding operations on the hierarchical business rule definition to flatten it into a rule parameter vector composed of multiple field rule units arranged in sequence. Each field rule unit defines the constraint conditions of the corresponding field.

[0069] At the same time, depth-first traversal and path encoding operations are performed on the original request data to generate a private data vector that is aligned one by one with the field rule units in the rule parameter vector;

[0070] S103. Based on the number of field rule units contained in the rule parameter vector, adaptively select the target verification circuit from the pre-built multi-specification general circuit resource pool. The multi-specification general circuit resource pool contains various parameterized verification circuit instances with different input capacities.

[0071] S104. The rule parameter vector is used as public input and the private data vector is used as private input. The target verification circuit is loaded into the target verification circuit. The target verification circuit executes the constraint conditions defined by the field rule unit, performs dynamic verification logic on the corresponding data values ​​in the private data vector, and generates zero-knowledge proof.

[0072] S105. Submit the zero-knowledge proof and the rule parameter vector to the on-chain verification contract for verification. The on-chain verification contract selects the corresponding verification key according to the length of the rule parameter vector, executes the verification algorithm, and outputs the verification result.

[0073] In step S101, the hierarchical business rule definition is a business constraint specification with a nested hierarchical structure described in a structured data format such as JSON Schema. Its content defines the name, type, value range, and whether each field in the data to be verified is required. The original request data is the actual business data whose compliance needs to be verified, and its structure corresponds to the hierarchical business rule definition. This step provides the foundation for subsequently decoupling variable business logic from fixed verification circuits.

[0074] In step S102, a depth-first traversal recursively and deterministically visits all leaf nodes in the hierarchical structure, ensuring the uniqueness of the access order. The path encoding operation generates a unique path identifier for each visited node, preferably achieved by cryptographically hashing the complete access path of the node within the structure. Field rule units are the basic elements constituting the rule parameter vector; they encapsulate the path identifier and the constraint parameters of that field, such as whether it is enabled, its numerical range, or its set of enumerated values. Through this process, the originally nested business rules are flattened into a one-dimensional rule parameter vector composed of multiple field rule units arranged sequentially.

[0075] The original request data undergoes the exact same traversal and encoding operations to generate a private data vector, ensuring that each private data unit is strictly aligned with the field rule units in the rule parameter vector in terms of order and path identifier. This one-to-one alignment mechanism enables subsequent general verification circuits to perform verification efficiently in a linear scan manner, without the need for complex dynamic addressing within the circuit.

[0076] In step S103, the number of field rule units contained in the rule parameter vector, i.e., its effective length, determines the scale of the current verification task. The multi-specification general-purpose circuit resource pool is a pre-built and maintained collection of parameterized verification circuit instances, containing various circuit specifications with different input capacities. Adaptive selection refers to intelligently selecting the most suitable circuit instance from the resource pool based on the effective length; for example, prioritizing circuits whose capacity perfectly matches the effective length; if none exists, then selecting the smallest specification circuit with a capacity greater than the effective length. This step, through a finite, pre-set set of general-purpose circuits, flexibly matches verification tasks of different scales, and is key to improving system scalability and resource utilization.

[0077] In step S104, the rule parameter vector serves as public input, defining the parameters of the verification logic; the private data vector serves as private input, and its value needs to be kept secret. The target verification circuit is a parameterized general verification circuit. Its internal logic is designed to parse the field rule units in the public input and, based on the parameterized constraint descriptions defined therein, executes corresponding dynamic verification logic on the data values ​​at the corresponding positions in the private data vector. For example, it checks whether the value is within a specified range or verifies whether its hash value belongs to a valid enumeration set. All constraint checks are implemented through the gate constraints of the arithmetic circuit. After successful verification, the circuit generates a zero-knowledge proof based on a non-interactive zero-knowledge proof protocol. This step achieves a complete separation between business rules and the circuit's hard-coded logic, enabling the same set of circuit logic to verify an infinite number of combinations of business rules through different public inputs.

[0078] In step S105, the on-chain verification contract is a smart contract deployed on the blockchain. Based on the length of the received rule parameter vector, it selects the corresponding target verification key from multiple verification keys stored internally. The verification key is a cryptographic parameter generated during the circuit compilation and trusted setup phase, paired with a circuit of a specific capacity. The contract uses the selected verification key and the publicly available rule parameter vector to execute a zero-knowledge proof verification algorithm on the submitted zero-knowledge proof. The output of the verification algorithm is the verification result, which reliably proves to all participants on the chain that the original request data conforms to all constraints defined by the hierarchical business rules, while the plaintext information of the original request data is never leaked during this process.

[0079] This embodiment transforms hierarchical business rules and request data into linear and strictly aligned vectors through deterministic depth-first traversal and path encoding, achieving a parameterized expression of business logic. Based on the size of the parameter vector, a verification circuit is adaptively selected from a pre-configured multi-specification general-purpose circuit resource pool, achieving flexible matching between verification resources and task requirements. Subsequently, the parameterized rules are used as public input and private data as private input, loaded into the general-purpose circuit for dynamic verification and proof generation, enabling the same circuit to adapt to changing business rules. Finally, a trusted verification is completed by selecting the corresponding verification key based on the length of the rule parameter vector through an on-chain verification contract. This embodiment uses a limited general-purpose circuit resource pool to serve a large number of different business models, effectively solving the problems of poor scalability, high maintenance costs, inflexible adaptation to dynamic business changes, and low resource utilization inherent in existing static dedicated circuit solutions.

[0080] In some embodiments, a depth-first traversal and path encoding operation is performed on the hierarchical business rule definition to flatten it into a rule parameter vector consisting of multiple field rule units arranged sequentially, including:

[0081] A depth-first traversal is performed on the hierarchical business rule definition to generate an access sequence containing all leaf nodes;

[0082] For each leaf node in the access sequence, a unique path identifier is generated based on its access path defined in the hierarchical business rules.

[0083] Based on the constraint information declared by each leaf node in the hierarchical business rule definition, construct the corresponding field rule unit. The field rule unit shall at least contain a path identifier and a parameterized constraint description that represents the constraint type of the leaf node.

[0084] All constructed field rule units are arranged in the order of the access sequence to form a rule parameter vector.

[0085] In this embodiment, depth-first traversal refers to starting from the root node defined by the hierarchical business rules, recursively visiting the deepest child node of each branch first, until all terminal leaf nodes have been visited, and recording the visiting order. This traversal order is deterministic, ensuring that for the same structure definition, the generated access sequence containing all leaf nodes is exactly the same each time.

[0086] Each leaf node in the access sequence corresponds to a specific field in the business rule. To generate a unique path identifier, the complete access path from the root node to the leaf node itself needs to be obtained. For nested objects, the path consists of the field names along the way connected by separators; for array elements, the path must include their index information. A preferred method is to perform a cryptographic hash operation on the complete path string, for example, using the Poseidon hash function, which is friendly to zero-knowledge proof circuits, to map the variable-length path string to a fixed-length field element. This path identifier cryptographically uniquely represents the position of the field in the structure.

[0087] The construction of field rule units is based on the constraint information declared in each leaf node. Constraint information includes whether the field is enabled, required, data type, numerical range, or set of enumerated values. Parameterized constraint descriptions encode these constraints into a parameter form that can be directly processed by the zero-knowledge proof circuit. For example, a Boolean "required" flag is encoded as 1 or 0 in the circuit domain; the numerical range is encoded as two integers: minimum and maximum value; for string enumerations, the hash value of each valid string must be pre-calculated, and their set used as a parameter. A field rule unit must at least contain the aforementioned path identifier and these parameterized constraint descriptions to fully define the validation logic for a field.

[0088] Finally, all the constructed field rule units are arranged strictly according to the access sequence generated by the depth-first traversal, forming a rule parameter vector. The rule parameter vector is a one-dimensional data structure with a length equal to the total number of leaf nodes, where each element is a structured field rule unit. Through this process, the originally complex nested business rules are transformed into a linear parameter list with a fixed element order. This flattening and parameterization is the foundation for the subsequent general-purpose verification circuit to dynamically parse and execute verifications. It allows specific business constraint logic to no longer be hard-coded inside the circuit, but rather to serve as variable, public inputs, thus fundamentally decoupling the business rules from the fixed circuit implementation.

[0089] This embodiment transforms hierarchical business rule definitions into rule parameter vectors. A unique access sequence is generated through deterministic depth-first traversal. A path identifier based on cryptographic hashing is generated for each field, and all declared constraint information is encoded into circuit-processable parameters. Finally, these parameters are arranged in access order to form a linear vector. This process standardizes the flexible and varied business rules into fixed-format, element-aligned circuit inputs, providing a precise and consistent parameterized description for subsequent adaptive selection of general circuits and dynamic verification. It is a crucial data preprocessing step for realizing a general verification paradigm of one circuit with multiple models.

[0090] In some embodiments, depth-first traversal and path encoding operations are performed on the original request data to generate a private data vector that is aligned one-to-one with the field rule units in the rule parameter vector, including:

[0091] Perform a depth-first traversal on the original request data to generate a data access sequence containing all data leaf nodes;

[0092] For each data leaf node in the data access sequence, generate a corresponding data path identifier based on its access path in the original request data;

[0093] The data value of each data leaf node is converted into a format that can be processed by the zero-knowledge proof circuit, and combined with the corresponding data path identifier to form a private data unit.

[0094] All the private data units formed are arranged in the order of the data access sequence to generate a private data vector. The data path identifier of each private data unit in the private data vector is matched with the path identifier of the field rule unit in the same order position in the rule parameter vector, thereby achieving one-to-one alignment.

[0095] In this embodiment, a depth-first traversal is performed on the original request data, employing the same recursive algorithm and node access logic as the one used to process the hierarchical business rules. Starting from the root node, the algorithm recursively visits the deepest child node of each branch first, until all terminal nodes containing actual values ​​(i.e., leaf nodes) have been visited, and the access order is recorded to generate a data access sequence. The logic for generating this sequence is strictly consistent with the logic for generating the rule access sequence in the previous embodiment, ensuring that the extraction order of data elements and the generation order of rule parameters are structurally isomorphic.

[0096] For each data leaf node in the data access sequence, a corresponding data path identifier is generated based on its access path in the original request data. The rules for constructing the access path are the same as those for generating the rule path identifier, i.e., concatenating all field names and array indices traversed from the root node to the data leaf node. The generation of the data path identifier also uses the same cryptographic hash function, such as performing a Poseidon hash operation on the constructed complete path string to obtain a fixed field element. This step ensures that for the same logical position in the structure, the rule definition and the request data will calculate exactly the same path identifier, which is the cryptographic basis for subsequent alignment verification.

[0097] The data value of each leaf node is converted into a format that the zero-knowledge proof circuit can process. The conversion operation depends on the original data type and business rule requirements: for integers and booleans, they can be directly mapped to the corresponding values ​​in the circuit's arithmetic domain; for floating-point numbers requiring high precision processing, fixed-point conversion is required according to a preset precision (e.g., converting yuan to fen); for strings or enumerated values, they must first be subjected to the same cryptographic hash operation as the path identifier, and the hash result is used as the circuit input value. The converted data value and its corresponding data path identifier are combined to form a private data unit, which encapsulates the complete information of the data to be verified.

[0098] Finally, all the formed private data units are arranged strictly according to the data access sequence to generate a private data vector. Since the rule parameter vectors are generated from the business rule definitions in the same depth-first traversal order, and the path identifier generation algorithm is consistent, the data path identifier of each private data unit in the private data vector will precisely match the path identifier of the field rule unit in the same sequential position in the rule parameter vector. This identifier matching based on deterministic traversal and consistent hashing constitutes a reliable mechanism for one-to-one alignment between rules and data, allowing the general verification circuit to complete data location simply by comparing identifiers in sequence.

[0099] This embodiment generates a private data vector that is strictly aligned with the rule parameter vector. By employing the same depth-first traversal logic and path identifier generation algorithm as the rule definition on the original request data, it ensures that the two maintain structural isomorphism and positional synchronization after vectorization. By uniformly converting various types of original data values ​​into a circuit-processable domain element format and binding them with path identifiers, a private input that can be directly verified by the circuit is formed. This precise alignment mechanism is the logical prerequisite for subsequent general-purpose verification circuits to correctly perform field-by-field verification without complex dynamic addressing, relying solely on efficient linear scanning, fundamentally guaranteeing the accuracy and execution efficiency of the parameterized verification process.

[0100] In some embodiments, a target verification circuit is adaptively selected from a pre-built multi-specification general-purpose circuit resource pool based on the number of field rule units contained in the rule parameter vector. This multi-specification general-purpose circuit resource pool contains various parameterized verification circuit instances with different input capacities, including:

[0101] Obtain the effective length of the rule parameter vector, which is equal to the number of field rule units it contains;

[0102] The effective length is compared with multiple predefined standard capacity specifications in the multi-specification general-purpose circuit resource pool;

[0103] If a standard capacity specification that perfectly matches the effective length exists, then the parameterized verification circuit instance corresponding to that standard capacity specification is selected as the target verification circuit.

[0104] If no perfectly matching standard capacity specification exists, then select the parameterized verification circuit instance corresponding to the smallest standard capacity specification with a capacity greater than the effective length from the multi-specification general circuit resource pool as the target verification circuit.

[0105] In this embodiment, the effective length of the rule parameter vector refers to the actual number of non-empty or enabled field rule units contained in the vector. The effective length can be obtained by traversing the rule parameter vector and counting the units that define valid constraints. This length directly characterizes the complexity of the current business rule to be verified, i.e., the total number of fields that need to be verified, and is the core basis for selecting appropriate computing resources.

[0106] The multi-specification general-purpose circuit resource pool is a pre-built and maintained resource collection containing parameterized verification circuit instances with various input capacities. Each specification corresponds to a fixed input capacity, such as circuits capable of handling 10, 20, or 30 fields. During system initialization, these circuit instances are compiled and trusted using a zero-knowledge proof framework, generating corresponding proof and verification keys before being loaded into the resource pool. The resource pool can be organized as a mapping table, where the key is the standard capacity specification, and the values ​​are the corresponding circuit instances and their keys.

[0107] Comparing the effective length with multiple predefined standard capacity specifications in the resource pool is a matching process. This process can be implemented using a simple numerical comparison algorithm, such as traversing the list of predefined standard capacity specifications to find a specification that matches the effective length. If a perfectly matching standard capacity specification exists, it indicates that the size of the current verification task exactly matches the capacity of a certain pre-defined circuit. In this case, the system directly selects the parameterized verification circuit instance corresponding to that specification as the target verification circuit by querying the mapping table of the resource pool. This selection achieves optimal resource utilization and avoids capacity waste.

[0108] If no perfectly matching standard capacity specification exists, a suboptimal selection strategy must be executed. This strategy selects the circuit instance corresponding to the smallest standard capacity specification with a capacity greater than the effective length from a pool of multi-specification general-purpose circuit resources. An algorithm to implement this strategy could be: iterate through all standard capacity specifications greater than the effective length, record the minimum value, and then select the circuit corresponding to that minimum value. For example, if the effective length is 23 and the standard specifications are 10, 20, 30, and 40, the algorithm selects a circuit with a capacity of 30. This step ensures that a general-purpose circuit capable of accommodating all fields and with relatively minimal resource waste is allocated to the verification task, representing a balance between verification feasibility and resource efficiency.

[0109] This embodiment adaptively selects the verification circuit based on the scale of the verification task. It achieves intelligent matching of computing resources by comparing the effective length of the rule parameter vector with the preset circuit specifications. When an exact match exists, it is directly selected to achieve optimal efficiency; when no match exists, the smallest specification circuit with a slightly larger capacity is selected to minimize resource redundancy while ensuring functional integrity. This lightweight selection mechanism based on specification comparison allows the system to flexibly cover a large number of business verification scenarios of varying complexity using a limited, pre-compiled set of general-purpose circuits. This fundamentally eliminates the rigid model of customizing dedicated circuits for each business model, and is a key element in achieving high system scalability and low maintenance costs.

[0110] In some embodiments, if no perfectly matching standard capacity specification exists, a parameterized verification circuit instance corresponding to the smallest standard capacity specification with a capacity greater than the effective length is selected from the multi-specification general circuit resource pool as the target verification circuit, including:

[0111] Calculate the resource waste rate between the effective length and each standard capacity specification in the multi-specification general-purpose circuit resource pool that is larger than the effective length;

[0112] Based on the calculated resource waste rate and the request frequency characteristics defined by the hierarchical business rules, an adaptive selection decision is executed, including:

[0113] If the resource waste rate is lower than the preset waste threshold, or if the request frequency characteristics indicate that it is a low-frequency request, then the parameterized verification circuit instance corresponding to the minimum standard capacity specification is directly selected as the target verification circuit.

[0114] If the resource waste rate is higher than the preset waste threshold and the request frequency characteristics indicate that it is a high-frequency request, then the asynchronous dynamic compilation process is triggered to generate a parameterized verification circuit instance that is exactly matched for the effective length. The parameterized verification circuit instance is stored in the hot spot cache area of ​​the multi-specification general circuit resource pool for subsequent use. At the same time, the parameterized verification circuit instance corresponding to the minimum standard capacity specification is still used as the target verification circuit.

[0115] In this embodiment, when no perfectly matching standard capacity specification exists, the system performs a more refined adaptive selection decision. Resource waste rate is a key indicator for measuring the resource utilization efficiency of the selected circuit instance. It is calculated as follows: for each standard capacity specification larger than the effective length, calculate the difference between its capacity and the effective length, and then divide it by the capacity of that specification itself. Resource waste rate quantifies the proportion of resources such as input ports that are not used due to the use of circuits with excessively large capacities.

[0116] The request frequency characteristics defined by hierarchical business rules are another important basis for execution decisions. This can be obtained through a monitoring system, for example, by recording the number of requests for each business rule model (identified by the hash value of its rule parameter vector as a fingerprint) within a unit of time. The system maintains a frequency statistics table and determines whether the current request belongs to a high-frequency or low-frequency pattern based on historical data. Preferably, a threshold for the number of requests within a time window can be set as the judgment criterion.

[0117] Based on the calculated resource waste rate and combined with request frequency characteristics, the system performs an adaptive selection decision. This decision logic can be implemented through a conditional judgment algorithm: if the calculated resource waste rate is lower than a preset waste threshold, it indicates that resource redundancy is within an acceptable range; or, if the request frequency characteristics indicate low-frequency requests, it indicates that the benefit of investing resources in optimizing this model is not high. In either case, the system will directly select the circuit instance corresponding to the minimum standard capacity specification with a capacity greater than the effective length as the target verification circuit, completing the current verification in the simplest process.

[0118] If the resource waste rate exceeds a preset waste threshold and the request frequency characteristics indicate a high-frequency request, an asynchronous dynamic compilation process is triggered. This step can be understood as follows: although the current request still uses the minimum standard capacity circuit to ensure real-time response, the system determines that generating an exact-matching circuit for this high-frequency, resource-wasting model has long-term value. The asynchronous dynamic compilation process executes independently in the background. Its task is to call the zero-knowledge proof compiler based on the current effective length to generate a new parameterized verification circuit instance with an input capacity exactly equal to the effective length. This process includes compiling the arithmetic constraint system and performing a one-time trust setting to generate the corresponding proof key and verification key. The newly generated circuit instance and its key will be stored in the hotspot cache of the multi-specification general-purpose circuit resource pool. Simultaneously, to ensure the real-time performance of the current request, its proof generation process does not wait for compilation to complete and continues to use the previously selected minimum standard capacity circuit instance. Subsequently, for subsequent requests of the same model, the system will prioritize calling the newly generated exact-matching circuit from the hotspot cache, thereby achieving incremental performance optimization.

[0119] This embodiment, building upon the basic selection strategy, introduces resource waste rate and request frequency as joint decision factors, achieving more intelligent circuit resource management. By quantitatively evaluating resource efficiency and business value, it triggers customized compilation in the background for high-frequency, hot-spot business models while ensuring real-time response for individual requests. This mechanism balances immediate service availability with long-term system performance: for the current request, zero-blocking latency is ensured by using a slightly larger standard circuit; for the system as a whole, resource utilization and proof generation efficiency are continuously optimized in high-frequency scenarios by asynchronously generating precisely matched circuits. This reflects a dynamic optimization design that ensures current availability while pursuing future optimality, enabling the system to adapt to business traffic patterns and continuously evolve towards local optimum performance while maintaining high scalability.

[0120] In some embodiments, the rule parameter vector is used as public input and the private data vector is used as private input, and both are loaded into the target verification circuit. The target verification circuit internally executes the constraints defined by the field rule unit, performs dynamic verification logic on the corresponding data values ​​in the private data vector, and generates zero-knowledge proofs, including:

[0121] Pair each field rule unit in the rule parameter vector with a private data unit in the same order position in the private data vector;

[0122] For each pair of field rule units and private data units, within the target verification circuit, a consistency check is performed based on the path identifier in the field rule unit and the data path identifier in the private data unit.

[0123] After the consistency check passes, the corresponding constraint checks are performed on the data values ​​in the private data unit according to the parameterized constraint description in the field rule unit.

[0124] When all paired field rule units and private data units pass consistency checks and constraint checks, the target verification circuit generates a zero-knowledge proof based on a non-interactive zero-knowledge proof protocol.

[0125] In this embodiment, after the rule parameter vector and the private data vector are loaded into the target verification circuit, the circuit logic pairs elements in the same order position in the two vectors. Since the two vectors are generated with strict alignment, the pairing operation within the circuit is manifested as establishing a logical association between each field rule unit in the public input port sequence and the private data unit in the same position in the private input port sequence, according to index order. This sequential pairing mechanism is the basis for subsequent field-by-field verification.

[0126] For each pair of paired field rule units and private data units, the target verification circuit performs a consistency check internally. The purpose of this check is to confirm whether the data item to be verified and the rule item refer to the same field in the structure. Specifically, the circuit reads the path identifier from the field rule unit and the data path identifier from the private data unit; both identifiers are field elements calculated using the same hash algorithm. The circuit verifies whether these two identifiers are equal using an arithmetic equality constraint. If the equality holds, the consistency check passes, proving that the data and rule are correctly aligned; otherwise, the entire circuit constraint system will not be satisfied, leading to proof generation failure. This step ensures the correctness of the verification logic.

[0127] After the consistency check passes, the circuit performs corresponding constraint checks on the data values ​​in the private data units based on the parameterized constraint descriptions in the field rule units. The parameterized constraint descriptions encode various constraint types in the form of parameters that the circuit can process, such as required flags, numerical ranges, or enumeration sets. The circuit internally contains a set of predefined, modular constraint checking logic. For each pair of units, the circuit parses the parameters in its field rule units and dynamically combines and calls the corresponding checking modules. For example, if the parameter indicates a range check, the circuit calls a submodule that verifies whether the data value is greater than or equal to the minimum value and less than or equal to the maximum value using arithmetic inequality constraints; if the parameter indicates an enumeration check, the circuit verifies whether the hash result of the data value matches an item in the predefined set of valid enumeration values ​​using a series of equality judgment constraints. All checks are implemented in the form of arithmetic circuit constraints.

[0128] When all paired field rule units and private data units pass the aforementioned consistency checks and constraint checks, it means that the entire private data vector fully satisfies all business constraints defined by the rule parameter vector. At this point, the target verification circuit generates a zero-knowledge proof based on an integrated non-interactive zero-knowledge proof protocol. This process is driven by the underlying proof system. All the constraints satisfied by the circuit together constitute a satisfiable arithmetic constraint system. The proof system uses this system and the private inputs to generate a short proof string. This proof can demonstrate to the verifier that there exists a set of private input data that satisfies all publicly declared business rules without revealing any private data values.

[0129] This embodiment provides a specific process for a parameterized general verification circuit to perform dynamic verification and generate proofs. It ensures data alignment with rules through sequential pairing, guarantees alignment accuracy through path identifier equality verification, and verifies data compliance by dynamically invoking a pre-defined constraint checking module through parsing the parameterized description. The entire process is driven entirely by publicly available input parameters, and the same circuit hardware logic can adapt to an infinite number of constraint combinations. When all constraint checks pass, the circuit and private inputs together constitute a satisfyable proof statement, which is then output by the underlying zero-knowledge proof protocol. This mechanism enables flexible binding of business rule logic and underlying cryptographic circuits at runtime, and is key to achieving a single circuit serving multiple business models while simultaneously ensuring data privacy and verification credibility.

[0130] In some embodiments, according to the parameterized constraint description in the field rule unit, the data values ​​in the private data unit are subjected to corresponding constraint checks, including:

[0131] Parse the parameterized constraint descriptions in the field rule unit to determine one or more constraint check types that need to be performed on the current field;

[0132] Based on the constraint check type, the corresponding constraint check logic module is dynamically invoked from multiple pre-built constraint check logic modules within the target verification circuit to check the data values ​​in the private data unit, including:

[0133] If the constraint check type includes a numerical range check, then the range check module is called to verify whether the data value is within the closed interval formed by the minimum and maximum values ​​declared in the parameterized constraint description.

[0134] If the constraint check type includes enumeration value check, then the enumeration check module is called to verify whether the cryptographic hash value of the data value exists in the set of valid enumeration value hashes declared in the parameterized constraint description;

[0135] If the constraint check type includes a mandatory check, then the existence check module is called to verify whether the data value is a valid value that is non-zero or non-empty.

[0136] When a data value passes the verification of all invoked constraint checking logic modules, the private data unit is determined to have passed the constraint check.

[0137] In this embodiment, parsing the parameterized constraint description in the field rule unit is the first step in performing dynamic validation. The parameterized constraint description is stored in the field rule unit in a structured data format, containing, for example, multiple flag bits and parameter fields. The parsing process is implemented internally by logic gates, specifically by reading specific flag bits in the description to determine which constraint checks need to be activated for the current field. For example, one flag bit might indicate whether range checking is enabled, and another flag bit might indicate whether enumeration checking is enabled. By parsing these predefined flag bit combinations, the circuit can determine one or more constraint check types that need to be performed on the current field.

[0138] Based on the determined constraint check type, the target verification circuit dynamically calls the corresponding module from its internally pre-built constraint check logic modules to check the data value. These modules are pre-coded, reusable sub-circuit units during circuit design. The calling process is not a function jump in the software sense, but rather, at the circuit routing level, based on the parsed flag bits, selectively activates the input / output connections of the corresponding module, allowing data to flow through the constraint logic of that module. For example, if a range check is required, the circuit activates the input of the range check module, connecting the data value in the private data unit, as well as the minimum and maximum values ​​declared in the parameterized constraint description, to the range check module. The range check module internally implements verification through two arithmetic inequalities: the data value must be greater than or equal to the minimum value, and the data value must be less than or equal to the maximum value. Only when both inequalities are true simultaneously does the module output a pass signal.

[0139] If the constraint check type includes enumeration value checking, the circuit invokes the enumeration check module. The input to the enumeration check module includes the cryptographic hash of the data value and the set of valid enumeration value hashes declared in the parameterized constraint description. This set is stored as a list in the public input. The enumeration check module performs verification through a series of equality comparison constraints, requiring that the hash of the data value must be equal to at least one hash value in the valid set. The circuit combines the results of all equality comparisons using logic OR gates; if any one comparison result is true, the operation passes.

[0140] If the constraint check type includes a mandatory field check, the circuit invokes the existence check module. The existence check module verifies whether a data value is a valid non-zero or non-empty value. For numeric types, this is typically achieved by verifying that the data value is not equal to zero; for hashed string types, it verifies that the hash result is not equal to a specific field element representing an empty value. This module ensures that when a rule requires a field to be mandatory, the corresponding data cannot be a default empty value.

[0141] Once the data value in the private data unit has passed the verification of all invoked constraint check logic modules in sequence, the circuit generates a comprehensive pass signal. This signal is the logical AND result of the output signals of all activated check modules. Only when all required checks pass is the private data unit considered to have passed the constraint check.

[0142] In this embodiment, the specific mechanism for dynamically executing diverse constraint checks based on parameterized descriptions within the general verification circuit involves pre-implementing different business constraint types as independent, modular circuit units. During runtime, the circuit dynamically selects and combines these modules by parsing flag bits in the public input to perform precise verification of private data. This allows the same set of fixed circuit hardware to be flexibly configured with almost an unlimited number of verification logic combinations through external parameters, eliminating the need to redesign the circuit for every change in business rules. Through modular constraint implementation and dynamic invocation mechanisms, this embodiment achieves high flexibility and scalability of business verification logic on the rigid carrier of cryptographic circuits, representing a key technical detail supporting the parameterized verification paradigm.

[0143] In some embodiments, the zero-knowledge proof and the rule parameter vector are submitted to an on-chain verification contract for verification. The on-chain verification contract selects the corresponding verification key based on the length of the rule parameter vector, executes the verification algorithm, and outputs the verification result, including:

[0144] The on-chain verification contract receives zero-knowledge proofs and rule parameter vectors.

[0145] The on-chain verification contract retrieves and loads the corresponding target verification key from multiple verification keys based on the length of the rule parameter vector;

[0146] The on-chain verification contract uses the target verification key and the rule parameter vector to execute the zero-knowledge proof verification algorithm on the zero-knowledge proof.

[0147] Based on the execution result of the zero-knowledge proof verification algorithm, a verification result is generated and output. The verification result is used to indicate whether the original request data meets all the constraints defined by the hierarchical business rules.

[0148] In this embodiment, the on-chain verification contract receives a zero-knowledge proof and a rule parameter vector submitted by the proof generator. This step is implemented by calling a specific verification function of the smart contract through a blockchain transaction, with the zero-knowledge proof and rule parameter vector passed as call parameters to this function. The contract obtains these inputs in the on-chain environment, providing a data foundation for subsequent verification operations.

[0149] The on-chain verification contract retrieves and loads the corresponding target verification key from multiple verification keys based on the length of the rule parameter vector. The length of the rule parameter vector is the number of field rule units it contains, which can be directly obtained from the vector data structure. Internally, the contract maintains a storage structure, such as a mapping table, where the keys are different length values ​​and the values ​​are the corresponding verification keys. The retrieval process involves querying this mapping table using the current length as the key to obtain the corresponding verification key data. If the query is successful, the key data is loaded into memory as the target verification key; if the query fails, it indicates that the current system does not support verification of that length, and the contract can immediately return an error. The verification key is a cryptographic parameter paired with a specific capacity circuit and generated during the trusted setup phase; its correct selection is a prerequisite for the execution of the verification algorithm.

[0150] The on-chain verification contract uses the retrieved target verification key and the received rule parameter vector to execute a zero-knowledge proof verification algorithm on the zero-knowledge proof. This algorithm is a standard verification function provided by the underlying zero-knowledge proof system, such as the Groth16 verification algorithm. The contract calls this function, passing the target verification key, rule parameter vector, and zero-knowledge proof as input parameters. The verification algorithm runs in an on-chain virtual environment, internally performing a series of cryptographic operations such as elliptic curve pairing to mathematically verify the validity of the proof. The entire computation process relies entirely on the publicly available verification key and rule parameters, requiring no private data.

[0151] Based on the execution result of the zero-knowledge proof verification algorithm, the contract generates and outputs the final verification result. The verification algorithm typically returns a boolean value indicating whether the proof is valid. The contract outputs this boolean value, or explicit state information derived from this boolean value, as the return value of this function call. This verification result is permanently recorded on the blockchain and made public to all participants. The result clearly indicates whether the party submitting the proof possesses the original request data that meets all constraints of the declared rule parameter vector, and that the assertion has been cryptographically verified, possessing immutability and non-repudiation.

[0152] This embodiment describes the complete process of an on-chain verification contract completing trusted verification. The contract, acting as an autonomous agent on the blockchain, intelligently selects the corresponding cryptographic verification key based on the publicly available rule parameter vector length, and uses this key to execute standard verification algorithms on zero-knowledge proofs. This process transforms complex off-chain business data compliance verification into a simple, deterministic, and publicly auditable on-chain cryptographic verification operation. By relying on pre-deployed verification keys paired with general-purpose circuits, the contract can complete verification without knowing specific business details, thus generalizing the verification logic. The final verification result forms a trusted record on the blockchain, providing a transparent, neutral, and efficient technical solution for cross-institutional data privacy compliance verification.

[0153] In some embodiments, the on-chain verification contract retrieves and loads the corresponding target verification key from multiple verification keys based on the length of the rule parameter vector, including:

[0154] The on-chain verification contract parses the rule parameter vector to determine the number of field rule units it contains;

[0155] Based on the number of field rule units, a query is performed in the verification key mapping table maintained inside the on-chain verification contract. The verification key mapping table stores the association between the number of different field rule units and the corresponding verification keys.

[0156] If the query is successful, the verification key that exactly matches the number of field rule units is extracted from the verification key mapping table and loaded as the target verification key;

[0157] If the query fails, the on-chain verification contract returns a verification failure result and indicates that verification of the rule parameter vector for the number of field rule units is not currently supported.

[0158] In this embodiment, the process of parsing the rule parameter vector of the on-chain verification contract is accomplished by reading the length attribute of the vector or by traversing and counting its valid elements. Since the rule parameter vector is constructed with its elements arranged in order, obtaining its length is a deterministic and efficient operation. This number is the sole basis for selecting the correct verification key.

[0159] Based on the determined number of field rule units, the contract queries its internally maintained verification key mapping table. The verification key mapping table is a data structure stored in the contract's state variables, typically implemented as a key-value pair mapping, where the key is the number of different field rule units and the value is the corresponding verification key bytecode. The query operation accesses this mapping table using the current number as the key. This mapping table is pre-populated during contract deployment or initialization, and its contents correspond to the verification keys of compiled circuits in the multi-specification general-purpose circuit resource pool.

[0160] If the query is successful, it indicates that the system has pre-configured circuit resources to support the current verification scale. The contract extracts verification key data that precisely matches the number of field rule units from the verification key mapping table and loads it into memory or directly passes it to the verification function as the target verification key. This key is a cryptographic parameter uniquely paired with a parameterized verification circuit of a specific input capacity, ensuring that subsequent verification algorithms are mathematically compatible with the circuit that generates the proof.

[0161] If the query fails, it indicates that the verification scale of the current request exceeds the system's default support range. In this case, the contract does not execute a complex verification algorithm but directly returns a verification failure result. Simultaneously, the contract can return a clear error indication stating that verification of the rule parameter vector for the number of rule units in that field is currently not supported. This constitutes a fast failure mechanism, avoiding unnecessary and potentially erroneous calculations when resources are insufficient, while also providing clear feedback to the caller.

[0162] This embodiment details the specific steps of how an on-chain verification contract accurately retrieves verification keys based on rule size. Utilizing a pre-defined mapping table, the size of the business rule is quantified into a simple integer key, and the corresponding cryptographic resource is directly located through efficient key-value lookups. This makes the contract's verification logic extremely concise and deterministic, completely eliminating dependence on the specific content of the business rules; the correctness of cryptographic verification is guaranteed solely through size matching. A fast return mechanism for failed queries enhances the system's robustness and predictability. By transforming complex circuit compatibility issues into queries of the mapping table state, this embodiment achieves a general-purpose verification contract that maintains high security while possessing good maintainability and scalability.

[0163] Please see Figure 3 In a second aspect, this embodiment also provides a zero-knowledge privacy verification system based on parameterized circuits, applicable to the zero-knowledge privacy verification method described in the first aspect. The system includes a data preprocessing module 1, a circuit resource management module 2, a proof generation module 3, and an on-chain verification module 4. The data preprocessing module 1 receives the hierarchical business rule definition to be verified and the original request data to be verified, and performs depth-first traversal and path encoding operations on the hierarchical business rule definition to generate a rule parameter vector. At the same time, it performs the same depth-first traversal and path encoding operations on the original request data to generate a private data vector that is aligned one-to-one with the field rule units in the rule parameter vector. The circuit resource management module 2 is used to maintain pre-built multi-specification general-purpose circuits. The circuit resource pool contains multiple parameterized verification circuit instances with different input capacities. Based on the number of field rule units contained in the rule parameter vector, the target verification circuit is adaptively selected from the pool. The proof generation module 3 loads the rule parameter vector as public input and the private data vector as private input into the target verification circuit, driving it to execute dynamic verification logic based on the constraints defined by the field rule units, and generating a zero-knowledge proof. The on-chain verification module 4, deployed on the blockchain network, receives the zero-knowledge proof and the rule parameter vector, selects the corresponding verification key based on the length of the rule parameter vector, executes the zero-knowledge proof verification algorithm, and outputs the verification result.

[0164] In this embodiment, the zero-knowledge privacy verification system fully implements a parameterized zero-knowledge privacy verification process through modular division of labor. Data preprocessing module 1 transforms business rules and data into aligned vectors; circuit resource management module 2 intelligently matches verification resources; proof generation module 3 performs dynamic verification using general-purpose circuits; and on-chain verification module 4 completes the final trusted verification. This system decouples business rules from dedicated circuits, serving diverse business models through a limited pool of general-purpose circuit resources, effectively solving the problems of poor scalability, high maintenance costs, and low resource utilization caused by static dedicated circuits in existing technologies.

[0165] By adopting the above technical solutions, this invention differs from existing technologies and possesses the following beneficial effects: By flattening the hierarchical business rule definitions and original request data into rule parameter vectors and private data vectors respectively, it achieves parameterized expression of business logic and strict alignment of data. Based on the length of the rule parameter vector, the target verification circuit is adaptively selected from a pre-built multi-specification general-purpose circuit resource pool, enabling a limited set of general-purpose circuits to flexibly adapt to verification tasks of different scales, thereby fundamentally changing the rigid pattern that a business model must correspond to a dedicated circuit; the target verification circuit dynamically executes verification logic and generates zero-knowledge proofs based on the rule parameter vector as public input, achieving complete decoupling between business rules and circuit hard-coding, allowing the same circuit to verify an infinite number of business rule combinations; finally, the on-chain verification contract selects the corresponding verification key based on the length of the rule parameter vector to complete the verification, ensuring the credibility and auditability of the entire process. This invention effectively solves the technical problems of poor scalability, high operation and maintenance costs, inability to flexibly adapt to dynamic business changes, and low resource utilization in existing static dedicated zero-knowledge proof schemes, significantly improving the system's flexibility, scalability, and resource efficiency while ensuring data privacy.

[0166] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0167] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or 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.) or processor to execute all or part of the steps of the methods of various embodiments of this 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.

[0168] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A zero-knowledge privacy verification method based on parameterized circuits, characterized in that, include: Receive the hierarchical business rule definitions to be verified and the original request data to be verified; The hierarchical business rule definition is subjected to depth-first traversal and path encoding operations, and is flattened into a rule parameter vector consisting of multiple field rule units arranged in sequence. Each field rule unit defines the constraint conditions of the corresponding field. Simultaneously, a depth-first traversal and path encoding operation is performed on the original request data to generate a private data vector that is aligned one-to-one with the field rule units in the rule parameter vector; Based on the number of field rule units contained in the rule parameter vector, a target verification circuit is adaptively selected from a pre-built multi-specification general circuit resource pool, which contains various parameterized verification circuit instances with different input capacities. The rule parameter vector is used as public input and the private data vector is used as private input. The target verification circuit is loaded into the target verification circuit. The target verification circuit executes the dynamic verification logic on the data value corresponding to the private data vector based on the constraints defined by the field rule unit, and generates zero-knowledge proof. The zero-knowledge proof and the rule parameter vector are submitted to the on-chain verification contract for verification. The on-chain verification contract selects the corresponding verification key according to the length of the rule parameter vector, executes the verification algorithm, and outputs the verification result. The hierarchical business rule definition is subjected to depth-first traversal and path encoding operations, flattening it into a rule parameter vector composed of multiple field rule units arranged sequentially, including: A depth-first traversal is performed on the hierarchical business rule definition to generate an access sequence containing all leaf nodes; For each leaf node in the access sequence, a unique path identifier is generated based on its access path in the hierarchical business rule definition; Based on the constraint information declared by each leaf node in the hierarchical business rule definition, a corresponding field rule unit is constructed. The field rule unit includes at least the path identifier and a parameterized constraint description that characterizes the constraint type of the leaf node. All constructed field rule units are arranged in the order of the access sequence to form the rule parameter vector; Perform depth-first traversal and path encoding operations on the original request data to generate a private data vector that is aligned one-to-one with the field rule units in the rule parameter vector, including: Perform a depth-first traversal on the original request data to generate a data access sequence containing all data leaf nodes; For each data leaf node in the data access sequence, a corresponding data path identifier is generated based on its access path in the original request data; The data value of each data leaf node is converted into a format that can be processed by the zero-knowledge proof circuit, and combined with the corresponding data path identifier to form a private data unit. All the private data units formed are arranged in the order of the data access sequence to generate the private data vector. The data path identifier of each private data unit in the private data vector matches the path identifier of the field rule unit in the same order position in the rule parameter vector, thereby achieving the one-to-one alignment.

2. The zero-knowledge privacy verification method based on parameterized circuits according to claim 1, characterized in that, Based on the number of field rule units contained in the rule parameter vector, a target verification circuit is adaptively selected from a pre-built multi-specification general-purpose circuit resource pool. This multi-specification general-purpose circuit resource pool contains various parameterized verification circuit instances with different input capacities, including: Obtain the effective length of the rule parameter vector, where the effective length is equal to the number of field rule units it contains; The effective length is compared with multiple predefined standard capacity specifications in the multi-specification general circuit resource pool; If a standard capacity specification that perfectly matches the effective length exists, then the parameterized verification circuit instance corresponding to the standard capacity specification is selected as the target verification circuit. If no perfectly matching standard capacity specification exists, then the parameterized verification circuit instance corresponding to the smallest standard capacity specification with a capacity greater than the effective length is selected from the multi-specification general circuit resource pool as the target verification circuit.

3. The zero-knowledge privacy verification method based on parameterized circuits according to claim 2, characterized in that, If no perfectly matching standard capacity specification exists, then a parameterized verification circuit instance corresponding to the smallest standard capacity specification with a capacity greater than the effective length is selected from the multi-specification general circuit resource pool as the target verification circuit, including: Calculate the resource waste rate between the effective length and each standard capacity specification in the multi-specification general-purpose circuit resource pool that is greater than the effective length; Based on the calculated resource waste rate and combined with the request frequency characteristics defined by the hierarchical business rules, an adaptive selection decision is executed, including: If the resource waste rate is lower than the preset waste threshold, or if the request frequency characteristic indicates a low-frequency request, then the parameterized verification circuit instance corresponding to the minimum standard capacity specification is directly selected as the target verification circuit. If the resource waste rate is higher than the preset waste threshold and the request frequency characteristic indicates a high-frequency request, then an asynchronous dynamic compilation process is triggered to generate a precisely matched parameterized verification circuit instance for the effective length, and the parameterized verification circuit instance is stored in the hot spot cache area of ​​the multi-specification general circuit resource pool for subsequent use. At the same time, the parameterized verification circuit instance corresponding to the minimum standard capacity specification is still used as the target verification circuit.

4. The zero-knowledge privacy verification method based on parameterized circuits according to claim 1, characterized in that, The rule parameter vector is used as public input and the private data vector is used as private input. These are loaded into the target verification circuit. The target verification circuit internally executes dynamic verification logic based on the constraints defined by the field rule unit, performs dynamic verification on the corresponding data values ​​in the private data vector, and generates zero-knowledge proofs, including: Pair each field rule unit in the rule parameter vector with a private data unit in the same order position in the private data vector; For each pair of field rule units and private data units, within the target verification circuit, a consistency check is performed based on the path identifier in the field rule unit and the data path identifier in the private data unit. After the consistency check passes, the corresponding constraint condition check is performed on the data values ​​in the private data unit according to the parameterized constraint description in the field rule unit. When all paired field rule units and private data units pass the consistency check and the constraint check, the target verification circuit generates the zero-knowledge proof based on the non-interactive zero-knowledge proof protocol.

5. The zero-knowledge privacy verification method based on parameterized circuits according to claim 4, characterized in that, Based on the parameterized constraint description in the field rule unit, perform corresponding constraint checks on the data values ​​in the private data unit, including: Parse the parameterized constraint description in the field rule unit to determine one or more constraint check types that need to be performed on the current field; Based on the constraint check type, the corresponding constraint check logic module is dynamically invoked from among multiple pre-set constraint check logic modules within the target verification circuit to check the data values ​​in the private data unit, including: If the constraint check type includes a numerical range check, then the range check module is invoked to verify whether the data value is within the closed interval formed by the minimum and maximum values ​​declared in the parameterized constraint description. If the constraint check type includes enumeration value check, then the enumeration check module is invoked to verify whether the cryptographic hash value of the data value exists in the set of valid enumeration value hashes declared by the parameterized constraint description; If the constraint check type includes a mandatory check, then the existence check module is invoked to verify whether the data value is a valid value that is non-zero or non-empty. When the data value passes the verification of all invoked constraint checking logic modules, the private data unit is determined to have passed the constraint condition check.

6. The zero-knowledge privacy verification method based on parameterized circuits according to claim 1, characterized in that, The zero-knowledge proof and the rule parameter vector are submitted to an on-chain verification contract for verification. The on-chain verification contract selects the corresponding verification key based on the length of the rule parameter vector, executes the verification algorithm, and outputs the verification result, including: The on-chain verification contract receives the zero-knowledge proof and the rule parameter vector; The on-chain verification contract retrieves and loads the corresponding target verification key from multiple verification keys according to the length of the rule parameter vector; The on-chain verification contract uses the target verification key and the rule parameter vector to perform a zero-knowledge proof verification algorithm on the zero-knowledge proof. Based on the execution result of the zero-knowledge proof verification algorithm, the verification result is generated and output. The verification result is used to indicate whether the original request data meets all the constraints defined by the hierarchical business rules.

7. The zero-knowledge privacy verification method based on parameterized circuits according to claim 6, characterized in that, The on-chain verification contract retrieves and loads the corresponding target verification key from multiple verification keys based on the length of the rule parameter vector, including: The on-chain verification contract parses the rule parameter vector to determine the number of field rule units it contains; Based on the number of field rule units, a query is performed in the verification key mapping table maintained within the on-chain verification contract. The verification key mapping table stores the association between the number of different field rule units and the corresponding verification keys. If the query is successful, the verification key that exactly matches the number of field rule units is extracted from the verification key mapping table and loaded as the target verification key; If the query fails, the on-chain verification contract returns a verification failure result and indicates that it does not currently support the verification of the rule parameter vector for the number of rule units in the field.

8. A zero-knowledge privacy verification system based on parameterized circuits, characterized in that, The system applicable to the zero-knowledge privacy verification method according to any one of claims 1 to 7, the system comprising: The data preprocessing module is used to receive the hierarchical business rule definition to be verified and the original request data to be verified, and to perform depth-first traversal and path encoding operations on the hierarchical business rule definition to generate a rule parameter vector. At the same time, the same depth-first traversal and path encoding operations are performed on the original request data to generate a private data vector that is aligned one by one with the field rule units in the rule parameter vector. The circuit resource management module is used to maintain a pre-built multi-specification general circuit resource pool. The multi-specification general circuit resource pool contains various parameterized verification circuit instances with different input capacities. Based on the number of field rule units contained in the rule parameter vector, the module adaptively selects the target verification circuit from the multi-specification general circuit resource pool. The proof generation module is used to load the rule parameter vector as public input and the private data vector as private input into the target verification circuit, drive the target verification circuit to execute dynamic verification logic based on the constraints defined by the field rule unit, and generate zero-knowledge proof; The on-chain verification module, deployed on the blockchain network, is used to receive the zero-knowledge proof and the rule parameter vector, select the corresponding verification key according to the length of the rule parameter vector, execute the zero-knowledge proof verification algorithm, and output the verification result.

Images