Compact merkle tree zero-knowledge circuit judicial authentication method

Abstract

The present application relates to a compact Merkle tree zero-knowledge circuit judicial authentication method, comprising the following specific steps: registering identity attributes and constructing CPMT, authenticating anonymity / multi-factor and loading CPMT witness, generating CPMT-ZK proof and verifying on the block chain, cross-domain authorized access and reading end-cloud chain collaborative data, evidence solidification and generating a judicial verifiable chain link, the present application realizes the minimum disclosure of attribute and path information through zero-knowledge proof, avoids sensitive information leakage, reduces the risk of information abuse, reduces the proof generation and verification overhead through the optimized CPMT-ZK circuit and batch proof mechanism, meets the high-concurrency authentication and mobile terminal deployment requirements, through the quantifiable control of false positive rate, version management and digital evidence chain certificate support full-link traceability, recheckable, meet the requirements of judicial scene on compliance and accountability.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically to a compact Merkle tree zero-knowledge circuit judicial authentication method. Background Technology

[0002] In business environments such as the "identity management and authentication system under multiple systems on the judicial intranet," the "blockchain-based anonymous mobile authentication and cross-domain mutual trust system," and the "end-cloud-chain collaborative data security storage and authorized access system," the following problems exist in identity authentication, cross-domain authorization, and evidence management:

[0003] 1. Inefficient large-scale attribute management: Existing membership proof schemes based on deterministic Merkle trees (including sparse Merkle trees) encode identity and permission attributes in the form of "leaf + path". As the number of judicial entities increases and cross-domain trust relationships overlap, the size and depth of the attribute tree expand rapidly, resulting in huge storage and synchronization overhead. It is difficult to maintain the complete state in the long term. Moreover, each proof requires carrying complete path information, resulting in high communication and computing costs, which is not conducive to real-time use by multiple systems and multiple terminals.

[0004] 2. Privacy protection and minimum disclosure requirements are difficult to meet: Traditional Merkle tree member proofs require exposing the complete path hash of the leaf nodes. The verifier can infer irrelevant structural information such as attribute distribution and location, leading to the leakage of sensitive information such as permission level and status. This conflicts with the selective disclosure goal of "only proving necessary attributes and hiding the rest of the information" in judicial scenarios, increasing the risk of information spread and abuse.

[0005] 3. High cost of zero-knowledge proof integration: In existing deterministic Merkle tree and zk-SNARK integration schemes, the circuit size increases linearly or even superlinearly with the tree depth and the number of attributes. The proof generation time and memory overhead are large, making it difficult to support the actual deployment needs of high-concurrency authentication in judicial private networks and resource-constrained scenarios such as mobile terminals.

[0006] 4. Traditional probabilistic structures lack judicial adaptability: Although probabilistic data structures such as Bloom filters and Cuckoo filters can compress storage and speed up queries, their original design does not consider on-chain verifiability and judicial auditability. They lack proof mechanisms that are bound to blockchain state and judicial entity identity, and cannot be directly used for identity authentication and evidence chain construction.

[0007] 5. Lack of a complete technical framework: Existing systems cannot simultaneously meet the triple requirements of "anonymous authentication, minimal disclosure, and accountability." Identity authentication relies on plaintext DIDs or identifiable identifiers. There is a lack of a unified cryptographically verifiable connection between cross-domain authorization, access control, and evidence uploading, making it difficult to form a complete digital evidence chain of "identity authentication - authorization - evidence collection - evidence solidification." Judicial authorities cannot independently review evidence without exposing all attributes and internal rules.

[0008] To address the aforementioned issues, a compact Merkle tree zero-knowledge circuit judicial authentication method is proposed. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides a compact Merkle tree zero-knowledge circuit judicial authentication method, which has advantages such as privacy, high efficiency, and accountability, and solves the aforementioned problems.

[0010] To achieve the above objectives, the present invention provides the following technical solution: a compact Merkle tree zero-knowledge circuit judicial authentication method, comprising the following specific steps: S1: Register identity attributes and construct CPMT; S1.1: In the identity management and authentication system under the private network multi-system, create identity identifiers (DIDs) for judicial entities, including police officers handling cases, bank data specialists, regulatory personnel, and devices. Enter basic attributes such as name, police number, institution type, role, and device information, and complete blockchain registration. S1.2: The system automatically extracts a set of key attributes (a_i) related to judicial authentication. The set of attributes includes basic identity attributes, permission attributes, status attributes and business attributes. The basic identity attributes include name, police number and organization information. The permission attributes include cross-domain evidence collection permission level and case type authorization scope. The status attributes include on-duty status and device trust level. The business attributes include data ownership identifier and regulatory permission level. S1.3: Dynamically configure the number of hash functions k and the bit width m of the bit array according to the attribute category and sensitivity. For critical attributes, configure a larger k value and a longer bit width m. For non-critical attributes, configure a smaller k value and a shorter bit width m. Bind the (k,m) parameter to the attribute category and write the mapping relationship to the blockchain in read-only configuration form. S1.4: Calculate the fingerprint location set (H_j(a_i)) for each attribute, construct a domain-specific bit array, and divide the bit array into four logical sub-regions according to "identity category / application domain", which correspond to the identity attributes of the case-handling police officer, bank data specialist and owner, regulatory and auditing entity, and device, respectively. Each sub-region is mapped to different leaf node intervals in the sparse Merkle tree. S1.5: The domain bit array is segmented and mapped to sparse Merkle leaf nodes. The leaf nodes and internal nodes are aggregated with member tags. Empty subtrees are represented by default hashes. The aggregated hashes generate the CPMT root hash (Root_CPMT). Together with the (k,m) parameters, identity status (ACTIVE / REVOKED / LOCKED) and effective timestamp, the hashes are uploaded to the chain to form the anonymous verifiable commitment of the identity identifier DID. S1.6: In the anonymous mobile authentication and cross-domain mutual trust system, when performing the operations of "Cross-domain Trust Establishment" and "Permission Delegation Creation", business rules such as case handling permission level, cross-domain access scope, role label, and authorization validity period are abstracted into attribute predicates (φ(a_i)) and bound to the Root_CPMT of the corresponding identity identifier DID and the cross-domain trust entry. S1.7: When an attribute is added or deleted, permission is changed, identity status is updated, or the regulatory side adjusts the attribute set definition, a partial incremental update of CPMT is triggered. Only the fingerprint bits and corresponding subtree path hashes of the affected attributes are rewritten to generate a new version Root_CPMT. The version chain and metadata such as effective start and end time, approval record hash, and responsible person identifier are maintained on the blockchain.

[0011] S2: Authentication of anonymity / multifactor authentication and loading of CPMT witnesses; S2.1: After the judicial entity completes the real person verification and device binding through multi-factor or rapid identity authentication such as password, SMS verification code, and biometrics, the local security module or trusted execution environment (TEE) loads the CPMT witness data with the identity identifier (DID) as the index. The witness data includes the fingerprint position index, the bit value, and the corresponding Merkel path hash sequence. S2.2: After the judicial entity selects the access scenario and fills in the domain identifier and validity period in the anonymous mobile authentication and cross-domain mutual trust system, the access scenario includes data query, file access, and cross-domain evidence collection. The system automatically matches or recommends the corresponding attribute predicate (φ(a_i)) to prepare to trigger CPMT-ZK proof generation. S2.3: CPMT witness data is processed only in a local or trusted execution environment and is not transmitted over the network in plaintext.

[0012] S3: Generate CPMT-ZK proofs and verify them on the blockchain; S3.1: The CPMT-ZK zero-knowledge proof generation module receives private input and public input. Private input includes CPMT witness data, identity attribute values ​​or their secondary hashes. Public input includes Root_CPMT and its version number, cross-domain scenario identifier, business predicate number, block height or timestamp range constraint. Cross-domain scenario identifier includes the target domain, access type, and case identifier. S3.2: Perform structural layer constraint verification inside the circuit to verify that the fingerprint position after hashing the input attribute is consistent with the witness data, and that the leaf node and path hash aggregation result corresponding to each fingerprint bit match the public Root_CPMT. If any fingerprint bit is 0 or the path calculation is inconsistent, directly output "Predicate not true". S3.3: After the structural layer constraint verification is passed, the semantic layer constraint verification is performed. The attribute predicate (φ(a_i)) logic is embedded in the form of Boolean circuit. The predicate logic includes combination rules such as "on-duty status is 1 + cross-domain permission level ≥ L" and "evidence category matches case category". A single-bit predicate establishment flag is output. S3.4: The Poseidon hash function is used to construct path verification and bit checking constraints. The path calculation is optimized by multi-bit segment aggregation hash. The constraints are compiled into an R1CS constraint system. The Groth16 (BLS12-381) proof system is used to generate a zero-knowledge proof (π). The proof is encapsulated into an anonymous token containing Root_CPMT, scene identifier, and proof (π). S3.5: Supports path sharing and batch proof mechanisms, reuse of public path segment constraints, and batch proofs can be generated for multiple access requests from the same subject within a short period of time, reducing computational overhead; S3.6: When the Anonymous Mobile Authentication and Cross-Domain Trust System initiates a [Cross-Domain Trust Verification] or [Mobile Device Cross-Domain Authentication], it submits the anonymous token to the verification and authorization contract on the blockchain. The contract verifies the legality of the proof, the validity of the Root_CPMT version, and the compliance with the scenario constraints within a constant time.

[0013] S4: Cross-domain authorized access and reading of end-cloud chain collaborative data; S4.1: When a judicial entity initiates a cross-domain access request, the cross-domain access request includes evidence inquiry, file download, and data retrieval. The front end automatically attaches an anonymous token and calls the on-chain verification and authorization contract through the cross-domain mutual trust system. S4.2: After the verification and authorization contract completes the SNARK proof verification, it combines the cross-domain trust table and the permission delegation table to verify the access type, source / target domain identifier, time window and other constraints. If the conditions are met, a one-time access authorization token is generated and the authorization result is recorded on the blockchain. S4.3: When the edge-cloud-chain collaborative data security storage and authorized access system performs operations such as [access authorization management], [authorization verification], [evidence file download], [evidence list query], and [evidence details viewing], it unlocks the corresponding evidence file access permissions based on the on-chain authorization token. Throughout the process, it only records metadata such as Root_CPMT, access type, timestamp, and evidence identifier, and does not read or store the plaintext identity attributes of the judicial entity.

[0014] S5: Solidify evidence and generate a legally verifiable link; S5.1: Judicial entities or data specialists upload key evidence files through the [Evidence File Upload] function of the End-Cloud-Chain Collaboration System. The system automatically calculates the file hash and writes the hash and related metadata into the blockchain through the [File Integrity Verification] and [Evidence Tracing] functions. S5.2: The system adds information related to the CPMT-ZK session to the evidence metadata, including the Root_CPMT used for access and its version number, access type, and authorized contract transaction hash, forming a closed-loop index of anonymous authentication—authorization—evidence collection—evidence on-chain; S5.3: When the investigation and case handling platform performs the "generate case judicial certificate" operation, it automatically aggregates information such as Root_CPMT, zero-knowledge proof verification record, evidence file hash and block height, and cross-domain authorization decision chain under the corresponding case. The authorization decision chain includes multi-level approval and entrustment summary, and generates digital evidence chain certificate. S5.4: Based on digital evidence chain certificates and publicly available blockchain data, judicial organs or regulatory platforms independently review the legality of the evidence collection authority, the completeness of the evidence, and the compliance of the authorization decision of the case-handling entity, so as to achieve full-chain accountability.

[0015] Another technical problem solved by the present invention is to provide a privacy protection device for judicial authentication of compact Merkle tree zero-knowledge circuits as described in any of the above claims, including a CPMT construction and management module, an attribute predicate configuration and binding module, a CPMT witness management module, a CPMT-ZK zero-knowledge proof generation module, a blockchain verification and authorization contract module, an end-to-end cloud-chain collaborative access control module, and an evidence solidification and judicial certificate generation module. The CPMT construction and management module is deployed in the identity management and authentication system under the private network multi-system. It is used to extract the set of key judicial attributes (a_i), calculate the fingerprint position, construct the domain bit array and CPMT, generate the Root_CPMT and maintain the version chain, perform local incremental updates, and verify the consistency of cross-domain trust entries. It supports Poseidon and pluggable hash algorithms and provides storage and encoding libraries implemented in Rust / Go. The attribute predicate configuration and binding module is deployed in the anonymous mobile authentication and cross-domain mutual trust system. It is used to abstract judicial business rules into attribute predicates (φ(a_i)) and bind them with the Root_CPMT of DID and cross-domain trust entries to form programmable permission rules. The CPMT witness management module is deployed on the terminal's local security module or trusted execution environment (TEE) to store, load, and decrypt CPMT witness data, ensuring that the data is only used in a secure environment and is not transmitted in plaintext. The CPMT-ZK zero-knowledge proof generation module is deployed in the backend or client SDK of the anonymous mobile authentication and cross-domain mutual trust system. It is used to receive input data, perform phased circuit constraint verification, and generate SNARK proofs and anonymous tokens using Poseidon hashing and Groth16 (BLS12-381). It supports path sharing, batch proofs and flexible deployment. The blockchain verification and authorization contract module is deployed in the blockchain smart contract layer. It is used to receive anonymous tokens, verify the legality of proofs and the validity of Root_CPMT, verify cross-domain trust constraints, generate one-time access authorization tokens, and record authorization results and metadata on the chain. The edge-cloud-chain collaborative access control module is deployed in the edge-cloud-chain collaborative data security storage and authorized access system. It is used to control the unlocking and transmission of evidence files based on the on-chain authorization token, record access metadata, and does not read plaintext identity attributes. The evidence solidification and judicial certificate generation module is deployed on the edge-cloud-chain collaborative system and the investigation and case-handling platform. It is used to calculate the hash of evidence files and put them on the chain, build a closed-loop index, aggregate on-chain records to generate digital evidence chain certificates for independent review by judicial authorities.

[0016] Furthermore, the CPMT construction and management module supports the configuration of attribute extraction rules. The rules are stored in the form of policy files, which can be adjusted by authorized administrators under permission control. The adjustment records are written to the audit log and hashed on the blockchain.

[0017] Furthermore, the CPMT-ZK zero-knowledge proof generation module reduces the number of circuit multiplication gates and redundant constraints through hash function parameter optimization and path sharing technology, thereby reducing the circuit size and the overhead of proof generation and verification.

[0018] Furthermore, the hardware deployment of the device includes a general-purpose server / cloud instance, and an optional hardware security module HSM for hosting proof / verification keys; the software components also include a contract module and an SDK, the contract module includes root and parameter governance, proof verification interface, events and logs, and the SDK includes SSI / VC adapter, predicate DSL, and mobile lightweight validator.

[0019] Compared with the prior art, the technical solution of this application has the following beneficial effects: 1. This invention achieves O(logn) sublinear storage through CPMT, significantly reducing the storage pressure on judicial private networks and blockchains, and supporting large-scale attribute graph management.

[0020] 2. This invention achieves minimal disclosure of attribute and path information through zero-knowledge proof, avoiding the leakage of sensitive information and reducing the risk of information misuse.

[0021] 3. This invention reduces the overhead of proof generation and verification by using an optimized CPMT-ZK circuit and a batch proof mechanism, thereby meeting the requirements of high-concurrency authentication and mobile terminal deployment.

[0022] 4. This invention enables quantitative control of the false alarm rate, and its version management and digital evidence chain certificate support full-chain traceability and verifiability, meeting the requirements of judicial scenarios for compliance and accountability.

[0023] 5. This invention seamlessly integrates with existing SSI models and judicial private network systems, supports flexible adjustments to attributes and business rules, and adapts to the needs of different judicial business scenarios. Attached Figure Description

[0024] Figure 1 This is a diagram showing the integrated architecture of the CPMT-ZK of the present invention within the SSI framework; Figure 2 This is a comparison diagram of CPMT and DMT / BF space under different n values ​​according to the present invention; Figure 3 This is a graph showing the false alarm rate of the present invention as a function of k and n; Figure 4 This is a three-layer structure diagram of the present invention: credential layer—business / authentication layer—blockchain layer. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] Please see Figure 1-4 The compact Merkle tree zero-knowledge circuit judicial authentication method in this embodiment includes the following specific steps: S1: Register identity attributes and construct CPMT; S1.1: In the identity management and authentication system under the private network multi-system, create identity identifiers (DIDs) for judicial entities, including police officers handling cases, bank data specialists, regulatory personnel, and devices. Enter basic attributes such as name, police number, institution type, role, and device information, and complete blockchain registration. S1.2: The system automatically extracts a set of key attributes (a_i) related to judicial authentication. The set of attributes includes basic identity attributes, permission attributes, status attributes and business attributes. Basic identity attributes include name, police number and organization information. Permission attributes include cross-domain evidence collection permission level and case type authorization scope. Status attributes include on-duty status and device trust level. Business attributes include data ownership identifier and regulatory permission level. S1.3: Dynamically configure the number of hash functions k and the bit width m of the bit array according to the attribute category and sensitivity. For critical attributes, configure a larger k value and a longer bit width m. For non-critical attributes, configure a smaller k value and a shorter bit width m. Bind the (k,m) parameter to the attribute category and write the mapping relationship to the blockchain in read-only configuration form. S1.4: Calculate the fingerprint location set (H_j(a_i)) for each attribute, construct a domain-specific bit array, and divide the bit array into four logical sub-regions according to "identity category / application domain", which correspond to the identity attributes of the case-handling police officer, bank data specialist and owner, regulatory and auditing entity, and device, respectively. Each sub-region is mapped to different leaf node intervals in the sparse Merkle tree. S1.5: The segmented bit array is mapped to sparse Merkle leaf nodes. Member tags are aggregated between leaf nodes and internal nodes. Empty subtrees are represented by default hashes. The aggregated hashes generate the CPMT root hash (Root_CPMT), which, along with the (k,m) parameter, identity status (ACTIVE / REVOKED / LOCKED), and effective timestamp, is uploaded to the blockchain to constitute the anonymous verifiable commitment of the identity identifier (DID). The false alarm rate of CPMT is quantitatively constrained by the (k,m) parameter, based on the acceptable false alarm limit for judicial authorities (≥10). -9 The parameter combination is solved, and the theoretical false alarm rate is explicitly stated on the chain. When k=4, the false alarm rate ε<0.1% and when k=5, ε<0.01%, which meets the requirements of the judicial scenario. S1.6: In the anonymous mobile authentication and cross-domain mutual trust system, when performing the operations of "Cross-domain Trust Establishment" and "Permission Delegation Creation", business rules such as case handling permission level, cross-domain access scope, role label, and authorization validity period are abstracted into attribute predicates (φ(a_i)) and bound to the Root_CPMT of the corresponding identity identifier DID and the cross-domain trust entry. S1.7: When an attribute is added or deleted, permission is changed, identity status is updated, or the regulatory side adjusts the attribute set definition, a partial incremental update of CPMT is triggered. Only the fingerprint bits and corresponding subtree path hashes of the affected attributes are rewritten to generate a new version Root_CPMT. The version chain and metadata such as effective start and end time, approval record hash, and responsible person identifier are maintained on the blockchain.

[0027] S2: Authentication of anonymity / multifactor authentication and loading of CPMT witnesses; S2.1: After the judicial entity completes the real person verification and device binding through multi-factor or rapid identity authentication such as password, SMS verification code, and biometrics, the local security module or trusted execution environment (TEE) loads the CPMT witness data with the identity identifier (DID) as the index. The witness data includes the fingerprint position index, bit value and corresponding Merkel path hash sequence. S2.2: After the judicial entity selects the access scenario and fills in the domain identifier and validity period in the anonymous mobile authentication and cross-domain mutual trust system, the access scenario includes data query, file access, and cross-domain evidence collection. The system automatically matches or recommends the corresponding attribute predicate (φ(a_i)) to prepare to trigger CPMT-ZK proof generation. S2.3: CPMT witness data is processed only in a local or trusted execution environment and is not transmitted over the network in plaintext.

[0028] S3: Generate CPMT-ZK proofs and verify them on the blockchain; S3.1: The CPMT-ZK zero-knowledge proof generation module receives private and public inputs. Private inputs include CPMT witness data, identity attribute values ​​or their secondary hashes, and public inputs include Root_CPMT and its version number, cross-domain scenario identifier, business predicate number, block height or timestamp range constraints. Cross-domain scenario identifiers include the target domain, access type, and case identifier. The CPMT-ZK zero-knowledge proof generation module supports flexible deployment modes. When the terminal has sufficient computing power, the proof is generated directly by the mobile terminal's local SDK. When the terminal resources are limited, the proof is generated by the anonymous authentication service within the private network. The terminal only encrypts and transmits private inputs. Both modes ensure that the witness data does not leave the private network or trusted execution environment. S3.2: Perform structural layer constraint verification inside the circuit to verify that the fingerprint position after hashing the input attribute is consistent with the witness data, and that the leaf node and path hash aggregation result corresponding to each fingerprint bit match the public Root_CPMT. If any fingerprint bit is 0 or the path calculation is inconsistent, directly output "Predicate not true". S3.3: After the structural layer constraint verification is passed, the semantic layer constraint verification is performed. The attribute predicate (φ(a_i)) logic is embedded in the form of Boolean circuit. The predicate logic includes combination rules such as "on-duty status is 1 + cross-domain permission level ≥ L" and "evidence category matches case category". A single-bit predicate establishment flag is output. S3.4: The Poseidon hash function is used to construct path verification and bit checking constraints. The path calculation is optimized by multi-bit segment aggregation hash. The constraints are compiled into an R1CS constraint system. The Groth16 (BLS12-381) proof system is used to generate a zero-knowledge proof (π). The proof is encapsulated into an anonymous token containing Root_CPMT, scene identifier, and proof (π). S3.5: Supports path sharing and batch proof mechanisms, reuse of public path segment constraints, and batch proofs can be generated for multiple access requests from the same subject within a short period of time, reducing computational overhead; S3.6: When the Anonymous Mobile Authentication and Cross-Domain Trust System initiates a [Cross-Domain Trust Verification] or [Mobile Device Cross-Domain Authentication], it submits the anonymous token to the verification and authorization contract on the blockchain. The contract verifies the legality of the proof, the validity of the Root_CPMT version, and the compliance with the scenario constraints within a constant time.

[0029] S4: Cross-domain authorized access and reading of end-cloud chain collaborative data; S4.1: When a judicial entity initiates a cross-domain access request, the cross-domain access request includes evidence inquiry, file download, and data retrieval. The front end automatically attaches an anonymous token and calls the on-chain verification and authorization contract through the cross-domain mutual trust system. S4.2: After the verification and authorization contract completes the SNARK proof verification, it combines the cross-domain trust table and the permission delegation table to verify constraints such as access type, source / target domain identifier, and time window. If the conditions are met, a one-time access authorization token is generated and the authorization result is recorded on the blockchain. The cross-domain trust table and the permission delegation table are equipped with a consistency verification mechanism: if the attribute predicate (φ(a_i)) referenced by the cross-domain trust entry is not included in the attribute set of the latest version of CPMT, it is automatically marked as "pending review"; when adding or modifying entries, the existing attribute categories defined in CPMT must be referenced, otherwise it will be rejected from being written to the chain. S4.3: When the edge-cloud-chain collaborative data security storage and authorized access system performs operations such as [access authorization management], [authorization verification], [evidence file download], [evidence list query], and [evidence details viewing], it unlocks the corresponding evidence file access permissions based on the on-chain authorization token. Throughout the process, it only records metadata such as Root_CPMT, access type, timestamp, and evidence identifier, and does not read or store the plaintext identity attributes of the judicial entity.

[0030] S5: Solidify evidence and generate a legally verifiable link; S5.1: Judicial entities or data specialists upload key evidence files through the [Evidence File Upload] function of the End-Cloud-Chain Collaboration System. The system automatically calculates the file hash and writes the hash and related metadata into the blockchain through the [File Integrity Verification] and [Evidence Tracing] functions. S5.2: The system adds information related to the CPMT-ZK session to the evidence metadata, including the Root_CPMT used for access and its version number, access type, and authorized contract transaction hash, forming a closed-loop index of anonymous authentication—authorization—evidence collection—evidence on-chain; S5.3: When the investigation and case handling platform performs the "generate case judicial certificate" operation, it automatically aggregates information such as Root_CPMT, zero-knowledge proof verification record, evidence file hash and block height, and cross-domain authorization decision chain under the corresponding case. The authorization decision chain includes multi-level approval and entrustment summary, and generates digital evidence chain certificate. S5.4: Based on digital evidence chain certificates and publicly available blockchain data, judicial organs or regulatory platforms independently review the legality of the evidence collection authority, the completeness of evidence, and the compliance of authorization decisions of the case-handling entities, achieving full-chain traceability. The entire chain adopts a national cryptographic priority strategy, and the blockchain layer is adapted to FISCO BCOS. Only Root_CPMT, verification keys, parameter mapping relationships, authorization results, and metadata are stored on the chain. Incremental batch updates and segmented storage reduce the recalculation cost of Root_CPMT, and the interface and audit are traceable.

[0031] Another technical problem solved by this invention is to provide a privacy protection device for judicial authentication of compact Merkle tree zero-knowledge circuits, including a credential layer, a business / authentication layer and a blockchain layer; The credential layer operates within the judicial intranet and is mainly composed of various business systems used to support specific case-handling and data access scenarios, including but not limited to: Identity Management System: Responsible for the real-name DID registration, status management, and basic credential generation of judicial entities and case-handling personnel; The investigation and case handling platform is responsible for business operations such as case claiming, initiating evidence collection requests, and generating case-level judicial documents. Police-bank transportation system and other cross-domain business systems: handle operations such as cross-domain access initiation and anonymous authentication triggering on the police side; End-to-end cloud-chain collaborative data security storage and authorized access system: responsible for the secure storage of evidence files, access authorization management, integrity verification and traceability; The credential layer calls the CPMT construction, anonymous authentication, and authorization verification services provided by the business / authentication layer through standard interfaces, and consumes the authorization results and evidence chain information output by the blockchain layer in the case handling process.

[0032] The business / authentication layer is deployed as an intermediate layer in the judicial private network. It mainly carries the CPMT and CPMT-ZK related capabilities introduced in this invention, and provides unified identity attribute fingerprinting, anonymous authentication and zero-knowledge proof services, including CPMT construction and management module, attribute predicate configuration and binding module, CPMT witness management module and CPMT-ZK zero-knowledge proof generation module. This layer provides API interfaces to the investigation and case handling platform, identity management system, anonymous mobile authentication and cross-domain mutual trust system at the top, and interacts with the verification and authorization contract module on the blockchain through the blockchain interface at the bottom, realizing the reading and writing of Root_CPMT, proof (pi) and authorization results.

[0033] The blockchain layer operates on blockchain nodes within the judicial private network. It maintains identity commitments, cross-domain trust entries, authorization records, and evidence chain information through smart contracts, including blockchain verification and authorization contract modules, state storage and log records, and read-only access interfaces for connecting to the regulatory platform.

[0034] Hardware deployment includes general-purpose servers / cloud instances, with optional hardware security modules (HSM) hosting proof / verification keys. Software components also include contract modules and SDKs. Contract modules include root and parameter governance, proof verification interfaces, events and logs. SDKs include SSI / VC adapters, predicate DSLs, and lightweight mobile validators. The CPMT construction and management module is deployed in the identity management and authentication system under the private network multi-system. It is used to extract the set of key judicial attributes (a_i), calculate the fingerprint position, construct the domain bit array and CPMT, generate the Root_CPMT and maintain the version chain, perform local incremental updates, and verify the consistency of cross-domain trust entries. It supports Poseidon and pluggable hash algorithms and provides storage and encoding libraries implemented in Rust / Go. The attribute predicate configuration and binding module is deployed in the anonymous mobile authentication and cross-domain mutual trust system. It is used to abstract judicial business rules into attribute predicates (φ(a_i)) and bind them with the DID's Root_CPMT and cross-domain trust entries to form programmable permission rules. The CPMT witness management module is deployed on the terminal's local security module or trusted execution environment (TEE) to store, load, and decrypt CPMT witness data, ensuring that the data is only used in a secure environment and is not transmitted in plaintext. It supports the configuration of attribute extraction rules, which are stored in the form of policy files. Authorized administrators can adjust these rules under access control, and the adjustment records are written to the audit log and hashed on the blockchain. The CPMT-ZK zero-knowledge proof generation module is deployed in the backend or client SDK of anonymous mobile authentication and cross-domain mutual trust systems. It is used to receive input data, perform phased circuit constraint verification, and generate SNARK proofs and anonymous tokens using Poseidon hashing and Groth16 (BLS12-381). It supports path sharing, batch proofs and flexible deployment. By optimizing hash function parameters and using path sharing technology, it reduces the number of circuit multiplication gates and redundant constraints, thereby reducing the circuit size and proof generation and verification overhead. The proof generation time is ≤210ms, the verification time is ≤8ms, and the proof size is ≤288B. The blockchain verification and authorization contract module is deployed on the blockchain smart contract layer. It is used to receive anonymous tokens, verify the legality of proofs and the validity of Root_CPMT, verify cross-domain trust constraints, generate one-time access authorization tokens, and record authorization results and metadata on the chain. The edge-cloud-chain collaborative access control module is deployed in the edge-cloud-chain collaborative data security storage and authorized access system. It is used to control the unlocking and transmission of evidence files based on the on-chain authorization token, record access metadata, and does not read plaintext identity attributes. The evidence solidification and judicial certificate generation module is deployed on the edge-cloud-chain collaborative system and the investigation and case-handling platform. It is used to calculate the hash of evidence files and put them on the chain, build a closed-loop index, aggregate on-chain records to generate digital evidence chain certificates for independent review by judicial authorities.

[0035] Example 1 1. Hardware Deployment The core computing nodes are general-purpose servers / cloud instances. The terminal devices must support the Trusted Execution Environment (TEE) and can optionally host the proof / verification key using the Hardware Security Module (HSM) to ensure key security.

[0036] 2. Software Implementation 2.1 The CPMT storage and encoding library is developed using Rust / Go, supports Poseidon and pluggable hash algorithms, and enables the construction of domain bit arrays, incremental updates, and version management. 2.2 The ZK proof service is implemented based on Groth16 (BLS12-381), supports R1CS compilation, path sharing and batch proof generation, and provides client SDK and server deployment package; 2.3 The contract module is developed based on the FISCO BCOS blockchain, including root and parameter governance, proof verification interface, event and log functions, and supports national cryptographic algorithms; 2.4 The SDK provides SSI / VC adaptation, predicate DSL, and lightweight mobile authenticator functions, and supports integration with existing identity management systems, investigation and case handling platforms, and police-bank transportation systems.

[0037] 3. Parameter Configuration Storage: n=10 6 At this scale, CPMT ≈ 48KB vs, traditional DMT ≈ GB level, ZK cost: proof generation ≈ 210ms, verification ≈ 8ms, proof size ≈ 288B, initial configuration k=4, m=20 (false positive rate <0.1%), key attributes can be adjusted k=5, m=24 (false positive rate <0.01%), parameter mapping relationship is written to the blockchain read-only configuration, supporting regulatory side to adjust and audit as needed.

[0038] 4. Testing and Optimization In the judicial intranet test environment, simulating 10 6 The process of constructing, generating, and verifying CPMTs for scale attribute data is optimized, circuit constraints and hash parameters are improved, and storage, computing performance, and false alarm rate are ensured to meet design specifications. Stress tests are conducted for multi-terminal, high-concurrency scenarios to optimize the batch proof mechanism and on-chain contract execution efficiency.

[0039] 5. Deployment and Operation The system will be deployed to the judicial private network production environment in phases, first connecting to non-core business systems to verify stability, and then gradually expanding to core scenarios such as cross-domain evidence collection and evidence solidification. An operation and maintenance monitoring mechanism will be established to monitor Root_CPMT version updates, proof generation and verification success rates, and on-chain contract status in real time to ensure reliable system operation. Attribute extraction rule adjustment records and permission change logs will be audited regularly to ensure compliance.

[0040] The working principle of the above embodiments is as follows: 1. This invention achieves O(logn) sublinear storage through CPMT, significantly reducing the storage pressure on judicial private networks and blockchains, and supporting large-scale attribute graph management.

[0041] 2. This invention achieves minimal disclosure of attribute and path information through zero-knowledge proof, avoiding the leakage of sensitive information and reducing the risk of information misuse.

[0042] 3. This invention reduces the overhead of proof generation and verification by using an optimized CPMT-ZK circuit and a batch proof mechanism, thereby meeting the requirements of high-concurrency authentication and mobile terminal deployment.

[0043] 4. This invention enables quantitative control of the false alarm rate, and its version management and digital evidence chain certificate support full-chain traceability and verifiability, meeting the requirements of judicial scenarios for compliance and accountability.

[0044] 5. This invention seamlessly integrates with existing SSI models and judicial private network systems, supports flexible adjustments to attributes and business rules, and adapts to the needs of different judicial business scenarios.

[0045] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0046] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A compact Merkle tree zero-knowledge circuit judicial authentication method, characterized in that, The specific steps include the following: S1: Register identity attributes and construct CPMT; S2: Authentication of anonymity / multifactor authentication and loading of CPMT witnesses; S3: Generate CPMT-ZK proofs and verify them on the blockchain; S4: Cross-domain authorized access and reading of end-cloud chain collaborative data; S5: Solidify evidence and generate a legally verifiable link.

2. The compact Merkle tree zero-knowledge circuit judicial authentication method according to claim 1, characterized in that, Step S1, which involves registering identity attributes and constructing the CPMT, includes the following sub-steps: S1.1: In the identity management and authentication system under the private network multi-system, create identity identifiers (DIDs) for judicial entities, including police officers handling cases, bank data specialists, regulatory personnel, and devices. Enter basic attributes such as name, police number, institution type, role, and device information, and complete blockchain registration. S1.2: The system automatically extracts a set of key attributes (a_i) related to judicial authentication. The set of attributes includes basic identity attributes, permission attributes, status attributes and business attributes. The basic identity attributes include name, police number and organization information. The permission attributes include cross-domain evidence collection permission level and case type authorization scope. The status attributes include on-duty status and device trust level. The business attributes include data ownership identifier and regulatory permission level. S1.3: Dynamically configure the number of hash functions k and the bit width m of the bit array according to the attribute category and sensitivity. For critical attributes, configure a larger k value and a longer bit width m. For non-critical attributes, configure a smaller k value and a shorter bit width m. Bind the (k,m) parameter to the attribute category and write the mapping relationship to the blockchain in read-only configuration form. S1.4: Calculate the fingerprint location set (H_j(a_i)) for each attribute, construct a domain-specific bit array, and divide the bit array into four logical sub-regions according to "identity category / application domain", which correspond to the identity attributes of the case-handling police officer class, bank data specialist and owner class, regulatory and auditing entity class, and device class, respectively. Each sub-region is mapped to different leaf node intervals in the sparse Merkle tree. S1.5: The domain bit array is segmented and mapped to sparse Merkle leaf nodes. The leaf nodes and internal nodes are aggregated with member tags. Empty subtrees are represented by default hashes. The aggregated hashes generate the CPMT root hash (Root_CPMT). Together with the (k,m) parameters, identity status (ACTIVE / REVOKED / LOCKED) and effective timestamp, the hashes are uploaded to the chain to form the anonymous verifiable commitment of the identity identifier DID. S1.6: In the anonymous mobile authentication and cross-domain mutual trust system, when performing the operations of "Cross-domain Trust Establishment" and "Permission Delegation Creation", business rules such as case handling permission level, cross-domain access scope, role label, and authorization validity period are abstracted into attribute predicates (φ(a_i)) and bound to the Root_CPMT of the corresponding identity identifier DID and the cross-domain trust entry. S1.7: When an attribute is added or deleted, permission is changed, identity status is updated, or the regulatory side adjusts the attribute set definition, a partial incremental update of CPMT is triggered. Only the fingerprint bits and corresponding subtree path hashes of the affected attributes are rewritten to generate a new version Root_CPMT. The version chain and metadata such as effective start and end time, approval record hash, and responsible person identifier are maintained on the blockchain.

3. The compact Merkle tree zero-knowledge circuit judicial authentication method according to claim 2, characterized in that, Step S2, which involves authenticating anonymity / multi-factor authentication and loading the CPMT witness, includes the following sub-steps: S2.1: After the judicial entity completes the real person verification and device binding through multi-factor or rapid identity authentication such as password, SMS verification code, and biometrics, the local security module or trusted execution environment (TEE) loads the CPMT witness data with the identity identifier (DID) as the index. The witness data includes the fingerprint position index, the bit value, and the corresponding Merkel path hash sequence. S2.2: After the judicial entity selects the access scenario and fills in the domain identifier and validity period in the anonymous mobile authentication and cross-domain mutual trust system, the access scenario includes data query, file access, and cross-domain evidence collection. The system automatically matches or recommends the corresponding attribute predicate (φ(a_i)) to prepare to trigger CPMT-ZK proof generation. S2.3: CPMT witness data is processed only in a local or trusted execution environment and is not transmitted over the network in plaintext.

4. The compact Merkle tree zero-knowledge circuit judicial authentication method according to claim 3, characterized in that, Step S3, which involves generating a CPMT-ZK proof and verifying it on the blockchain, includes the following sub-steps: S3.1: The CPMT-ZK zero-knowledge proof generation module receives private input and public input. Private input includes CPMT witness data, identity attribute values ​​or their secondary hashes. Public input includes Root_CPMT and its version number, cross-domain scenario identifier, business predicate number, block height or timestamp range constraint. Cross-domain scenario identifier includes the target domain, access type, and case identifier. S3.2: Perform structural layer constraint verification inside the circuit to verify that the fingerprint position after hashing the input attribute is consistent with the witness data, and that the leaf node and path hash aggregation result corresponding to each fingerprint bit match the public Root_CPMT. If any fingerprint bit is 0 or the path calculation is inconsistent, directly output "Predicate not true". S3.3: After the structural layer constraint verification is passed, the semantic layer constraint verification is performed. The attribute predicate (φ(a_i)) logic is embedded in the form of Boolean circuit. The predicate logic includes combination rules such as "on-duty status is 1 + cross-domain permission level ≥ L" and "evidence category matches case category". A single-bit predicate establishment flag is output. S3.4: The Poseidon hash function is used to construct path verification and bit checking constraints. The path calculation is optimized by multi-bit segment aggregation hash. The constraints are compiled into an R1CS constraint system. The Groth16 (BLS12-381) proof system is used to generate a zero-knowledge proof (π). The proof is encapsulated into an anonymous token containing Root_CPMT, scene identifier, and proof (π). S3.5: Supports path sharing and batch proof mechanisms, reuse of public path segment constraints, and batch proofs can be generated for multiple access requests from the same subject within a short period of time, reducing computational overhead; S3.6: When the Anonymous Mobile Authentication and Cross-Domain Trust System initiates a [Cross-Domain Trust Verification] or [Mobile Device Cross-Domain Authentication], it submits the anonymous token to the verification and authorization contract on the blockchain. The contract verifies the legality of the proof, the validity of the Root_CPMT version, and the compliance with the scenario constraints within a constant time.

5. The compact Merkle tree zero-knowledge circuit judicial authentication method according to claim 4, characterized in that, Step S4, which involves cross-domain authorized access and reading of end-cloud chain collaborative data, includes the following sub-steps: S4.1: When a judicial entity initiates a cross-domain access request, the cross-domain access request includes evidence inquiry, file download, and data retrieval. The front end automatically attaches an anonymous token and calls the on-chain verification and authorization contract through the cross-domain mutual trust system. S4.2: After the verification and authorization contract completes the SNARK proof verification, it combines the cross-domain trust table and the permission delegation table to verify the access type, source / target domain identifier, time window and other constraints. If the conditions are met, a one-time access authorization token is generated and the authorization result is recorded on the blockchain. S4.3: When the edge-cloud-chain collaborative data security storage and authorized access system performs operations such as [access authorization management], [authorization verification], [evidence file download], [evidence list query], and [evidence details viewing], it unlocks the corresponding evidence file access permissions based on the on-chain authorization token. Throughout the process, it only records metadata such as Root_CPMT, access type, timestamp, and evidence identifier, and does not read or store the plaintext identity attributes of the judicial entity.

6. The compact Merkle tree zero-knowledge circuit judicial authentication method according to claim 5, characterized in that, Step S5, which involves solidifying evidence and generating a legally verifiable link, includes the following sub-steps: S5.1: Judicial entities or data specialists upload key evidence files through the [Evidence File Upload] function of the End-Cloud-Chain Collaboration System. The system automatically calculates the file hash and writes the hash and related metadata into the blockchain through the [File Integrity Verification] and [Evidence Tracing] functions. S5.2: The system adds information related to the CPMT-ZK session to the evidence metadata, including the Root_CPMT used for access and its version number, access type, and authorized contract transaction hash, forming a closed-loop index of anonymous authentication—authorization—evidence collection—evidence on-chain; S5.3: When the investigation and case handling platform performs the "Generate Case Judicial Evidence" operation, it automatically aggregates information such as Root_CPMT, zero-knowledge proof verification record, evidence file hash and block height, and cross-domain authorization decision chain under the corresponding case. The authorization decision chain includes multi-level approval and entrustment summary, and generates digital evidence chain certificate. S5.4: Based on digital evidence chain certificates and publicly available blockchain data, judicial organs or regulatory platforms independently review the legality of the evidence collection authority, the completeness of the evidence, and the compliance of the authorization decision of the case-handling entity, so as to achieve full-chain accountability.

7. The privacy protection device for judicial authentication of compact Merkle tree zero-knowledge circuits according to any one of claims 1-6, characterized in that, It includes the CPMT construction and management module, attribute predicate configuration and binding module, CPMT witness management module, CPMT-ZK zero-knowledge proof generation module, blockchain verification and authorization contract module, end-to-end cloud-chain collaborative access control module, and evidence solidification and judicial certificate generation module; The CPMT construction and management module is deployed in the identity management and authentication system under the private network multi-system. It is used to extract the set of key judicial attributes (a_i), calculate the fingerprint position, construct the domain bit array and CPMT, generate the Root_CPMT and maintain the version chain, perform local incremental updates, and verify the consistency of cross-domain trust entries. It supports Poseidon and pluggable hash algorithms and provides storage and encoding libraries implemented in Rust / Go. The attribute predicate configuration and binding module is deployed in the anonymous mobile authentication and cross-domain mutual trust system. It is used to abstract judicial business rules into attribute predicates (φ(a_i)) and bind them with the Root_CPMT of DID and cross-domain trust entries to form programmable permission rules. The CPMT witness management module is deployed on the terminal's local security module or trusted execution environment (TEE) to store, load, and decrypt CPMT witness data, ensuring that the data is only used in a secure environment and is not transmitted in plaintext. The CPMT-ZK zero-knowledge proof generation module is deployed in the backend or client SDK of the anonymous mobile authentication and cross-domain mutual trust system. It is used to receive input data, perform phased circuit constraint verification, and generate SNARK proofs and anonymous tokens using Poseidon hashing and Groth16 (BLS12-381). It supports path sharing, batch proofs and flexible deployment. The blockchain verification and authorization contract module is deployed in the blockchain smart contract layer. It is used to receive anonymous tokens, verify the legality of proofs and the validity of Root_CPMT, verify cross-domain trust constraints, generate one-time access authorization tokens, and record authorization results and metadata on the chain. The edge-cloud-chain collaborative access control module is deployed in the edge-cloud-chain collaborative data security storage and authorized access system. It is used to control the unlocking and transmission of evidence files based on the on-chain authorization token, record access metadata, and does not read plaintext identity attributes. The evidence solidification and judicial certificate generation module is deployed on the edge-cloud-chain collaborative system and the investigation and case-handling platform. It is used to calculate the hash of evidence files and put them on the chain, build a closed-loop index, aggregate on-chain records to generate digital evidence chain certificates for independent review by judicial authorities.

8. The privacy protection device for judicial authentication of compact Merkle tree zero-knowledge circuits according to claim 7, characterized in that, The CPMT construction and management module supports the configuration of attribute extraction rules. The rules are stored in the form of policy files, which can be adjusted by authorized administrators under permission control. The adjustment records are written to the audit log and hashed on the blockchain.

9. The privacy protection device for judicial authentication of a compact Merkle tree zero-knowledge circuit according to claim 7, characterized in that, The CPMT-ZK zero-knowledge proof generation module reduces the number of circuit multiplication gates and redundant constraints through hash function parameter optimization and path sharing technology, thereby reducing the circuit size and the overhead of proof generation and verification.

10. The privacy protection device for judicial authentication of compact Merkle tree zero-knowledge circuits according to claim 7, characterized in that, The hardware deployment of the device includes a general-purpose server / cloud instance, and an optional hardware security module HSM for hosting proof / verification keys; the software components also include a contract module and an SDK. The contract module includes root and parameter governance, proof verification interface, events and logs, and the SDK includes SSI / VC adapter, predicate DSL, and mobile lightweight validator.

Images