Digital identity authentication and tracing method based on block chain

Abstract

The invention belongs to the technical field of block chains, and discloses a block chain-based digital identity authentication and traceability method, which comprises the following steps: acquiring user biological characteristic data, generating a characteristic root value, splitting key shares, and generating a key share set through block chain evidence storage; each distributed node generates an identity private key and an on-chain identity template, and associates the on-chain identity template with a chain identifier to form a multi-chain identity key pool and an on-chain identity template library; dividing a core chain and an edge chain, generating a zero-knowledge proof, generating a cross-chain certificate after verification of the core chain, sending an encryption result to the edge chain, and generating a temporary authority token; writing traceability information into the edge chain, aggregating multi-chain information through cross-chain traceability, and generating a traceability information chain and a cross-chain traceability validity proof; and recording a key use track and identifying a risk behavior, triggering a key limiting mechanism, dynamically updating an identity template permission on the chain, reversely optimizing key related parameters, and forming a closed-loop iterative identity and traceability management link.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and more specifically, to a blockchain-based digital identity authentication and traceability method. Background Art

[0002] With the rapid development of the digital economy, the demand for cross-industry and cross-scenario identity authentication and data traceability is increasing. However, there are many pain points in current practice: identity authentication relies on centralized institutions, which can easily lead to data monopoly and single point failures, and direct storage of sensitive information such as biometrics poses a risk of leakage; the identity trust basis is not unified in cross-chain scenarios, resulting in difficulties in identity interoperability between different blockchains; the data and operating entities in the traceability system are loosely bound, information is fragmented and easily tampered with, and it is difficult to form a complete and reliable traceability chain. At the same time, the balance between privacy protection and information verification has never been effectively resolved. These shortcomings have seriously restricted the security and cross-scenario applicability of the digital identity system.

[0003] Existing solutions have some limitations: although centralized identity solutions achieve unified management, they are easy to become targets of attacks; distributed identity solutions lack a root trust mechanism based on biometrics, and cross-chain identity associations rely on third-party intermediaries; traceability systems are mostly limited to data records within a single chain, and information associations are chaotic during cross-chain traceability, and user privacy (such as biometrics and attribute information) is easily exposed during the verification process; encryption technology is inefficient in cross-chain interactions, and privacy protection methods such as zero-knowledge proofs lack dynamic adaptation capabilities; risk prevention and control rely on static rules, and respond slowly to abnormal behaviors such as remote operations and overreaching of permissions, and lack key emergency management and parameter self-optimization mechanisms, making it difficult to cope with security challenges in complex scenarios. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art and to achieve the above-mentioned objectives, the present invention provides the following technical solution: a blockchain-based digital identity authentication and traceability method, comprising: S1: Obtain user biometric data, perform irreversible conversion on the user terminal to generate characteristic root values ​​and split key shares. After collaborative verification by distributed nodes, generate a key share set through blockchain evidence storage; S2: Based on the key share set, each distributed node generates the identity private key of the corresponding blockchain and the on-chain identity template containing the biometric hash, associates the on-chain identity template with the chain identifier, and forms a multi-chain identity key pool and on-chain identity template library; S3: Based on the multi-chain identity key pool and on-chain identity template library, the core chain and edge chain are divided, and zero-knowledge proof is generated through the user terminal. After verification by the core chain, a cross-chain credential is generated and the encrypted result is sent to the edge chain to generate a temporary permission token; S4: Based on the cross-chain verification certificate and temporary authority token, traceability information is written to the edge chain and the user's real-time biometric hash and user terminal device identification are attached. Cross-chain traceability aggregates multi-chain information to generate a traceability information chain and a cross-chain traceability validity certificate. S5: Based on the traceability information chain and cross-chain traceability validity proof, record the key usage trajectory and identify risky behaviors, trigger the key restriction mechanism, dynamically update the on-chain identity template permissions, reversely optimize key-related parameters, and form a closed-loop iterative identity and traceability management chain.

[0005] Furthermore, the method of generating characteristic root values ​​and splitting key shares includes: Collect the required user's original biometric data through the user terminal, and complete the standardization and noise reduction processing locally; Serialize the processed biometric data into a byte stream, perform an irreversible hash operation on the byte stream, and generate a fixed-length hash value as the feature root value; Distributed nodes are preset, and the characteristic root value is split into multiple key shares according to the number of distributed nodes. The user terminal distributes the key shares to other distributed nodes through an encrypted channel.

[0006] Furthermore, the key share set is generated in the following manner: After receiving the key share, the distributed node verifies the authenticity and validity of the key share and records the corresponding verification timestamp and verification log; If the verification fails, the key share of the corresponding distributed node is deemed invalid and requires redistribution; For all distributed nodes that have passed key share verification, each distributed node uploads the hash value of its own key share, verification timestamp, and its own node digital signature to the blockchain to form structured data; Generate a root hash based on structured data and write it into the blockchain block for evidence storage, and then integrate the evidence root hash and verification log on the blockchain as a key share set.

[0007] Furthermore, the method of generating the identity private key corresponding to the blockchain and the on-chain identity template containing the biometric hash includes: Distributed nodes obtain their own stored key shares and verification logs from the key share set; For each preset blockchain, each distributed node collaboratively generates the identity private key of the corresponding blockchain based on the key share set; At the same time, the user terminal extracts the hash summary of the feature root value as the biometric hash based on the biometric data, extracts and integrates the user's basic attributes and initial permission range to form template basic data; The template base data is encrypted and associated with the identity private key to form the final on-chain identity template.

[0008] Furthermore, the multi-chain identity key pool and the on-chain identity template library are formed in the following ways: Call the preset chain identification list, bind the unique chain ID of each blockchain to the corresponding on-chain identity template and perform hash mapping to establish a unique association; Aggregate the public keys of the corresponding chain identity private keys generated by each distributed node by chain identifier, and build a multi-chain identity key pool with the chain identifier and user identity unique identifier as index; The on-chain identity template is stored in the distributed storage area through the user terminal to form an on-chain identity template library; Aggregate unique association information, index information of the multi-chain identity key pool, and the storage address of the on-chain template library to generate an association relationship, and store the root hash of the association relationship on-chain; The consistency verification mechanism is triggered synchronously to verify the association relationship. After the verification passes, the multi-chain identity key pool and the on-chain identity template library are determined to be effective.

[0009] Furthermore, the generation method of the zero-knowledge proof includes: Based on the multi-chain identity key pool and on-chain identity template library, the user terminal loads the identity private key and on-chain identity template associated with the current business scenario; Based on preset scenario rules, the blockchain network is divided into core chains and edge chains according to their functions. The core chain is used for global verification, and the edge chain is used for business processing. Generate the private input and public input of the zero-knowledge proof through the user terminal based on the loaded identity private key and the on-chain identity template; Then, a proof circuit is constructed based on the logical association between private input and public input to generate a zero-knowledge proof file.

[0010] Furthermore, the temporary authorization token is generated by: Submit the zero-knowledge proof file to the core chain through the user terminal for integrity and validity verification. If the verification fails, the zero-knowledge proof file regeneration mechanism is triggered; If the zero-knowledge proof document is verified, a cross-chain verification certificate is generated and stored on the chain; The verification result is then transmitted to the edge chain through an encrypted channel. The edge chain verifies the validity of the verification result. If the verification fails, the core chain re-verification mechanism is triggered. If the verification passes, a temporary permission token is generated based on the permission range in the verification result and the current timestamp.

[0011] Furthermore, the method of writing traceability information to the edge chain includes: The user terminal initiates a traceability information writing request to the edge chain based on the cross-chain verification certificate and temporary permission token. At the same time, the user's real-time biometric hash and user terminal device identification are collected and attached to the request to generate a request package. After receiving the request package, the edge chain verifies the validity of the temporary permission token and the cross-chain verification credential, and then verifies the consistency of the real-time biometric hash with the on-chain identity template and the compliance of the traceability information; If the verification passes, the traceability information is allowed to be written. If the verification fails, an error reminder is returned to the user terminal and the core chain re-verification mechanism is triggered.

[0012] Furthermore, the generation method of the traceability information chain and cross-chain traceability validity proof includes: After the traceability information is written into the edge chain, a cross-chain traceability request is initiated to the core chain through the user terminal. After the core chain receives the cross-chain traceability request as a coordination node, it sends a query request with cross-chain verification credentials to the relevant edge chain; It then aggregates local traceability information fragments received from each edge link, including real-time biometric hashes and timestamps, and verifies identification consistency and temporal logic; When the local traceability information fragment is verified, a traceability information chain with identity binding is generated in series by time, and a cross-chain traceability validity certificate that records the aggregation process and verification results is generated simultaneously and transmitted back to the user terminal; If the verification fails, the verification failure result is recorded and sent to the user terminal.

[0013] Furthermore, the methods of recording key usage trajectories and identifying risks, triggering key restriction mechanisms, dynamically updating on-chain identity template permissions, and reversely optimizing key-related parameters include: Based on the traceability information chain, cross-chain traceability validity proof and key share set, key usage data is extracted in real time through the core chain to record the key usage trajectory; Obtain historical baseline data, compare it with key usage traces, and identify risky behaviors; Evaluate risky behaviors and classify them into risk levels. Based on the risk level, trigger the key restriction mechanism and perform corresponding temporary restrictions or key freezing operations. Obtain all verification data in the traceability process through the core chain and compile statistics into traceability audit results; Dynamically adjust the permission attributes of the on-chain identity template based on the traceability audit results, and reversely optimize the key share splitting parameters and the identity private key generation parameters based on risk behavior data.

[0014] The technical effects and advantages of the blockchain-based digital identity authentication and traceability method of the present invention are as follows: This invention generates a characteristic root value through irreversible conversion of biometrics, combines it with threshold secret sharing to split the key shares, and then distributes verification and evidence. This not only avoids the privacy risks of directly storing the original biometrics, but also uses the characteristic root value as the global identity root trust, solving the problem of inconsistent cross-chain identity trust foundation. Distributed verification and evidence storage ensure the security and traceability of the key shares. Secondly, a cross-chain identity private key and encrypted identity template are generated to build a multi-chain key pool. At the same time, an encrypted identity template containing biometric hash and attribute information is generated, which realizes the dynamic binding of identity private key and chain identifier, solving the problem of cross-chain identity interoperability. Template encryption and permission association protect user attribute privacy. Then, by dividing the core chain (global verification) and the edge chain (business processing), functional division of labor is achieved, improving the efficiency of cross-chain interaction. At the same time, zero-knowledge proof is generated based on identity information, completing identity and permission verification while avoiding privacy data leakage. This solves the problem of balancing privacy and security in traditional verification, and provides a safe and efficient trust transfer mechanism for cross-chain operations. Next, when writing traceability information, real-time biometric hashes and device identification are added to ensure that traceability operations are strongly bound to identities. During cross-chain traceability, multi-chain information fragments are aggregated and logically verified to form a complete traceability information chain with identity binding, solving the problems of traceability data fragmentation and the inability to trace subject responsibility. Cross-chain validity proof further enhances the credibility of traceability results. Finally, based on traceability information and key trajectory records, machine learning is used to identify risky behaviors and dynamically trigger the key management mechanism. At the same time, identity permissions are updated and key parameters are optimized based on audit results, achieving real-time response to risks and self-iteration of the system. This solves the problems of lagging risk prevention and control and insufficient adaptability of traditional solutions, forming a full-link closed loop of "identity generation-cross-chain verification-traceability management-risk optimization", which significantly improves the system's security, privacy protection and scenario adaptability. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 Schematic diagram of the process of digital identity authentication and traceability method based on blockchain of the present invention; Figure 2 This is a flowchart of the core chain verifying zero-knowledge proof in the blockchain-based digital identity authentication and traceability method of the present invention; Figure 3 Schematic diagram of the blockchain-based digital identity authentication and traceability system of the present invention. DETAILED DESCRIPTION

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

[0017] See also Figure 1 and Figure 2 As shown, the blockchain-based digital identity authentication and traceability method described in this embodiment includes: S1: Obtain user biometric data, perform irreversible conversion on the user terminal to generate characteristic root values ​​and split key shares. After collaborative verification by distributed nodes, generate a key share set through blockchain evidence storage; S2: Based on the key share set, each distributed node generates the identity private key of the corresponding blockchain and the on-chain identity template containing the biometric hash, associates the on-chain identity template with the chain identifier, and forms a multi-chain identity key pool and on-chain identity template library; S3: Based on the multi-chain identity key pool and on-chain identity template library, the core chain and edge chain are divided, and zero-knowledge proof is generated through the user terminal. After verification by the core chain, a cross-chain credential is generated and the encrypted result is sent to the edge chain to generate a temporary permission token; S4: Based on the cross-chain verification certificate and temporary authority token, traceability information is written to the edge chain and the user's real-time biometric hash and user terminal device identification are attached. Cross-chain traceability aggregates multi-chain information to generate a traceability information chain and a cross-chain traceability validity certificate. S5: Based on the traceability information chain and cross-chain traceability validity proof, record the key usage trajectory and identify risky behaviors, trigger the key restriction mechanism, dynamically update the on-chain identity template permissions, reversely optimize key-related parameters, and form a closed-loop iterative identity and traceability management chain.

[0018] This solution is suitable for areas requiring information confidentiality, such as financial transactions, e-government, network communications, and industrial production, and can be expanded according to specific needs in different application scenarios; Methods for generating characteristic root values ​​and splitting key shares include: The user initiates the identity authentication process through a user terminal (such as a mobile phone or self-service terminal) and collects the required original biometric data (such as fingerprint, iris, and face). The user terminal pre-processes the raw biometric data, including standardization and noise reduction; It should be noted that there are mature pre-processing methods for various types of biometric data. I will not list them all here, but only give two examples: Fingerprint biometric data: A Gabor filter is used to extract 128 minutiae feature points (including endpoints, bifurcation points, and isolated points) from the fingerprint image. The coordinates, orientation angle, and type label of each feature point are recorded. Duplicate or noisy feature points are removed using the Delaunay triangulation algorithm. Iris biometric data: A two-level Daubechies-4 wavelet transform is performed on the iris ROI to extract a 64×64 texture feature vector. The feature values ​​are then mapped to the [-1, 1] interval using Z-score normalization to remove feature fluctuations caused by differences in light intensity. It should be noted that the standardization and noise reduction processing of raw biometric data are all performed locally on the user terminal. The raw biometric data does not leave the device at all. The generation and transmission of characteristic root values ​​and key shares are protected by hardware-level encryption to ensure that they cannot be reversed or stolen. The user terminal calls the SHA-512 / 256 truncated hash algorithm to convert the pre-processed biometric data into a 128-bit fixed-length hash value as the characteristic root value; The specific process is as follows: The processed biometric data is serialized into a byte stream (for example, fingerprint feature points are arranged in ascending order of coordinates, each feature point occupies 8 bytes, and iris vectors are arranged in dimensional order, totaling 256 bytes); An irreversible hash operation is performed on the byte stream using the SHA-512 algorithm, and the first 128 bits of a fixed-length hash value are taken as the irreversible characteristic root value. After the operation is completed, only the characteristic root value is retained, and the original characteristic data is immediately cleared. The characteristic root value generation process is completed locally on the user terminal, and the original biometric data is not stored or uploaded. Only the hash operation result is retained as the unique seed for subsequent key generation. Distributed nodes are preset, and Shamir threshold secret sharing scheme is used to split the eigenvalue into key shares according to the number of distributed nodes; Specifically, preset distributed nodes (usually set to no less than 5, for example: user terminal, local authority node, core chain node A, core chain node B, backup node) and threshold parameters (set according to the number of distributed nodes, the threshold parameter needs to be greater than half of the distributed nodes, for example, if the number of distributed nodes is 5, the threshold parameter is 3); Then, the Shamir threshold secret sharing scheme is used to split the eigenvalue according to the number of distributed nodes and the threshold parameter, and the key shares corresponding to the number of distributed nodes are obtained; After the key share is generated, the user terminal distributes the key share to other distributed nodes through an encrypted channel using the TLS 1.3 protocol. The user terminal itself only retains the corresponding key share, which is stored in a non-exportable area of ​​the user terminal security chip and bound to the device hardware (biometric features must be collected again when the device is replaced).

[0019] The key share set is generated in the following ways: After receiving the key share, the distributed node calls the corresponding local verification module to verify the authenticity and validity of the key share, and records the corresponding verification timestamp and verification log; Specifically, the source authenticity verification is as follows: after the preset distributed nodes receive their respective key shares through the encrypted channel, they start the local verification module. Each distributed node calls the preset verification algorithm to first verify the legality of the format of the key share (such as whether the node ID (the unique identifier of the distributed node) matches the preset UUID (universally unique identifier) ​​and whether the share value complies with the 256-bit numerical specification). Then, the authenticity of the source of the key share is verified through the digital signature of the user terminal itself that receives the key share synchronously, and shares with invalid signatures or abnormal formats are rejected. The validity check is performed using the Verifiable Secret Sharing (VSS) protocol. Specifically, each distributed node exchanges key share verification information through P2P encrypted communication using the Noise protocol. Each distributed node generates an elliptic curve commitment for its own key share based on the NIST P-256 curve algorithm (the commitment value in the elliptic curve commitment is a combination of the key share value and a random number) and broadcasts the commitment to other nodes. The receiving node verifies whether the commitments of all distributed nodes satisfy the quadratic polynomial relationship preset in the Shamir threshold secret sharing scheme based on the polynomial consistency rule (if the threshold parameter is set to 3, the commitment values ​​of at least any three distributed nodes must satisfy this relationship). If any distributed node commitment deviates from the polynomial, the distributed node's key share is deemed invalid and requires redistribution. If the verification fails, the key share of the corresponding distributed node is deemed invalid and requires redistribution; For distributed nodes that have passed the key share verification, each distributed node uploads the hash value of its own key share, verification timestamp and its own digital signature to the blockchain designated smart contract for evidence storage. The contract aggregates the evidence information of all distributed nodes and generates structured data containing each key share hash, evidence storage address and a list of verified nodes. Generate a root hash based on the structured data using the Merkle tree algorithm, write it into the blockchain block for evidence storage, and then integrate the evidence root hash and verification log on the blockchain as a key share set, and add the index information of the key share of each distributed node to the key share set; After generating the key share set, an integrity check is automatically performed: Randomly extract the key shares of the number of distributed nodes corresponding to the threshold parameter, and try to restore the hash of the eigenvalue through secure multi-party computation (MPC) (only verifying the hash consistency, not restoring the original value); If the restored hash matches the generated characteristic root value hash, the share set is confirmed to be valid. Otherwise, the re-verification process is triggered to ensure that the final generated key share set is traceable and restorable.

[0020] Methods for generating the corresponding blockchain identity private key and on-chain identity template containing biometric hash include: Distributed nodes obtain their own stored key shares and verification logs from the key share set through the blockchain smart contract interface, and match the stored hash value with the node ID (unique identifier) ​​to confirm the validity of the key share; Distributed nodes establish a temporary session through a preset secure communication protocol (such as an encrypted channel based on the Noise protocol) to synchronize the chain identification of the target blockchain network (including the blockchain's chain ID (i.e., the blockchain's unique identifier), encryption algorithm type) and key generation parameters (such as secp256k1 elliptic curve); For each preset blockchain, each distributed node calls the MPC protocol (i.e., secure multi-party computing protocol) to collaboratively generate the identity private key of the corresponding blockchain based on the key share set; The specific method is as follows: each distributed node inputs a local key share and performs a secret-shared addition operation on the same platform. Without revealing their own key shares, they jointly calculate the original key corresponding to the eigenvalue. The original key is hashed using the chain ID (i.e., the chain ID and the original key are hashed using the SHA-256 hash algorithm) to generate an identity private key (256 bits) bound to the blockchain, ensuring the uniqueness of the identity private keys across different chains. Based on the biometric data, the user terminal extracts the hash digest of the characteristic root value (the hash digest is obtained by hashing the characteristic root value using the SHA-256 hash algorithm) as the biometric hash, extracts and integrates the user's basic attributes (such as the name hash and the ID type hash, all of which have been irreversibly converted) and the initial permission scope (such as "only traceability information query is allowed") to form the template basic data; The template basic data is encrypted using the attribute-based encryption (CP-ABE) algorithm, and the encryption key is associated with the user's identity private key to form the final on-chain identity template, ensuring that only distributed nodes holding the corresponding private key and permission attributes can decrypt it; Verify the association between the on-chain identity template and the private key: The user terminal generates a digital signature of the identity private key, appends it to the encrypted on-chain identity template, and then sends it to the core chain node. The core chain node verifies the consistency of the signature and the identity private key, confirming the binding relationship between the template and the private key; After re-verification, the user terminal will temporarily store the encrypted on-chain identity template locally.

[0021] The multi-chain identity key pool and on-chain identity template library are formed in the following ways: Through the core chain's smart contract, the preset chain identification list (including the unique chain ID of each blockchain, the functional type (such as financial chain, logistics chain)) is called, and the on-chain identity template of each blockchain is used. Bind the unique chain ID of each blockchain to the corresponding on-chain identity template and perform hash mapping. That is, the on-chain identity template is hashed using the SHA-256 hash algorithm, and the hash value is then bound to the chain ID to establish a one-to-one unique association. The association information includes the chain ID, the on-chain identity template hash, and the public key digest of the corresponding identity private key, which is stored in the mapping table of the smart contract to ensure the unique binding of chain identifier, on-chain identity template, and identity private key; Each distributed node uploads the generated public key (not the private key itself) of the corresponding chain identity private key to the core chain. The core chain's smart contract aggregates public key information by chain identifier to form a multi-chain identity key pool. The multi-chain identity key pool adopts a hierarchical index structure: the first-level index is the chain identifier, and the second-level index is the user identity unique identifier (generated based on the hash of the characteristic root value). The index can quickly locate a user's identity public key on a specific chain, thereby supporting efficient retrieval when querying cross-chain identities. Upload the on-chain identity template to the distributed storage area designated by the core chain (such as IPFS (InterPlanetary File System)) through the user terminal, and write the IPFS hash and access control policy of the on-chain identity template into the smart contract to form an on-chain identity template library; The access control policy is set so that only distributed nodes that hold the corresponding identity private key or have audit permissions (such as authoritative agency nodes) can access the on-chain identity template content through the decryption key (associated with the identity private key). Ordinary distributed nodes can only obtain the hash summary of the on-chain identity template for verification; The smart contract aggregates the unique association information between the chain identifier and the on-chain identity template, the index information of the multi-chain identity key pool, and the storage address of the on-chain template library, generates a Merkle tree of the association relationship, and obtains the root hash of the association relationship. The root hash of the association relationship is then written into the blockchain block to complete the on-chain evidence storage; The consistency verification mechanism is triggered synchronously to verify the association relationship. After the verification passes, the multi-chain identity key pool and the on-chain identity template library are determined to be effective, thereby realizing the systematic management of multi-chain identities and the foundation of cross-chain association; The consistency check mechanism is as follows: randomly extract the associated information of the number of blockchains corresponding to the threshold parameter (3 pieces), and verify whether the chain identifier, the on-chain identity template hash, and the public key of the multi-chain identity key pool match the preset binding rules (the binding rules are set based on expert experience and actual conditions, such as whether the public key is generated by the corresponding private key).

[0022] Zero-knowledge proofs can be generated in the following ways: Based on the multi-chain identity key pool and on-chain identity template library, the user terminal locally parses and loads the chain identifier associated with the current business scenario (such as the "transportation service chain" for airport customs clearance), the identity private key (extracted from the multi-chain identity key pool) and the on-chain identity template; Based on preset scenario rules, the blockchain network is divided into core chains and edge chains according to their functions. The core chain is used for global verification, and the edge chain is used for business processing. Specifically, the basis for dividing the core chain and the edge chain is defined as follows: the core chain undertakes core security functions such as global identity anchoring, cross-chain permission arbitration, zero-knowledge proof verification, and abnormal behavior auditing, and must meet high consensus strength and high data immutability, and is suitable for processing core logic such as cross-chain identity authentication and permission template updates; the edge chain is responsible for data processing for specific business scenarios (such as airport customs clearance and product traceability information entry), and must meet low latency and lightweight deployment requirements, retaining only the permission sets related to the scenario (such as "only allow writing of traceability data"); Then, a chain function tag library is predefined in the smart contract. It contains three types of tags, including function type tags (including the function type of each chain), security level tags (the core chain has the highest security level (such as level 3), and the edge chain has a security level below the highest level that can be set as needed (such as level 1 or level 2)), and interaction frequency threshold (i.e., the interaction frequency threshold between the core chain and the edge chain, such as ≤100 times / minute, to prevent high-frequency interactions from affecting the performance of the core chain). The user terminal calls the on-chain identity template library to obtain the required tags of the current business scenario (such as global verification and product traceability). Then, the user terminal queries the chain function tag library through the smart contract interface and matches the chain identifier corresponding to the tag. If the function type tag in the chain identifier contains core security functions (such as global verification), it is automatically mapped to the core chain. If it contains specific scenario tags (such as product traceability), it is automatically mapped to the edge chain. After the matching results are verified locally on the user terminal (checking the historical binding records of the chain identifier and the business scenario), a "core chain-edge chain" correspondence table is generated and stored in the secure area of ​​the user terminal; Generate the private input and public input of the zero-knowledge proof through the user terminal based on the loaded identity private key and the on-chain identity template; Specifically, private inputs include the identity private key, the full biometric hash in the on-chain identity template, and permission attributes; Public input includes the target blockchain's chain ID, the preset business scenario code (such as "Customs Clearance-202408"), and a timestamp; The proof generation algorithm is called by the user terminal, and a proof circuit is constructed based on the logical association between private input and public input to generate a zero-knowledge proof file; It should be noted that the core purpose of this process is to transform the logic of identity validity into a verifiable mathematical circuit; The logical association of the proof circuit is defined as the design of a zero-knowledge proof circuit using the circom language. The proof circuit needs to strictly define the logical association between private input and public input. The core logical associations include: Logic 1: The identity private key in the private input matches the biometric hash (i.e., the public key corresponding to the identity private key can correctly decrypt the encrypted information of the biometric hash); Logic 2: The permission attribute in the private input contains the business scenario code in the public input; Logic 3: The timestamp in the public input is within the valid range (e.g., current time ±5 minutes) to prevent proof reuse; The proof circuit solidifies these logics through the corresponding constraint equations (for example, logic 1 is implemented through elliptic curve signature verification constraints, and logic 2 is implemented through string matching constraints), and finally generates a circom circuit file; The private and public inputs are handled as follows during the construction of the proof circuit: The identity private key is encrypted in the terminal TEE environment and only participates in circuit calculations in ciphertext form. The biometric hash is decrypted from the on-chain identity template library and bound to the identity private key for verification. The permission attributes are extracted from the on-chain identity template and converted into a binary array for logical matching. The chain identifier of the target blockchain is input as a string and converted into a hash value for the proof circuit constraint. Business scenario encoding: The preset scenario ID is included in the verification of the permission attributes. The timestamp is a Unix timestamp generated locally on the user terminal and matches the time range constraint in the proof circuit. Then, a zero-knowledge proof file (including the proof data of the circuit file and the public input hash) is generated based on the circuit file using zero-knowledge proof technology. Specifically, the following steps are involved: Step 1: Circuit compilation: Use the circom compiler to compile the circom circuit file into an R1CS constraint system (rank 1 constraint system) and a WASM file (for generating witnesses). At the same time, a verification key and a proof key are generated as a key pair and pre-deployed in the core chain smart contract. Step 2: Witness generation, the user terminal calls the WASM file, inputs private and public inputs, calculates the witness (i.e. the solution that satisfies the proof circuit logic) that satisfies the R1CS constraints. The witness is only generated locally on the terminal and is not transmitted externally. Step 3: Proof calculation, the user terminal uses the proof key and the witness to generate an unverified zero-knowledge proof file (containing proof data and public input hash) using the Groth16 algorithm. Step 4: Local verification, the user terminal calls the verification key to perform pre-verification on the generated unverified zero-knowledge proof file (checking the consistency of the proof format and the public input), and then encapsulates it as a zero-knowledge proof file that can be used for cross-chain verification requests.

[0023] The generation method of the temporary permission token includes: The user terminal submits the zero-knowledge proof file from the encryption API to the core chain smart contract, triggering the core chain verification module to perform integrity and validity verification. First, the format integrity of the zero-knowledge proof file is checked, i.e. the length of the proof data is checked to see if it meets the output specification (such as the Groth16 algorithm output specification, fixed at 3 256-bit elliptic curve points, totaling 768 bytes), the format of the public input hash is checked, and the completeness of the public input field is parsed. If the format verification fails (such as length inconsistency, missing fields), it is determined that the verification fails, triggering the zero-knowledge proof file regeneration mechanism, including immediately returning an error prompt to the user terminal, and recording failure logs (including user terminal device identification hash (i.e. MAC address hash of the user terminal), failure time), the user terminal receives and prompts the user to perform zero-knowledge proof file regeneration operation; After the format verification passes, the core chain calls the Groth16 algorithm to verify the logical consistency of the proof data and the public input, i.e. to check whether the logical relationship between the proof data and the public input meets the logical relationship defined in the logical relationship. If any logical constraint is not met, it is determined that the verification fails, triggering the zero-knowledge proof file regeneration mechanism, including immediately returning an error prompt to the user terminal, and writing the failure reason to the on-chain log (only recording error type, not leaking private information), the user terminal receives and prompts the user to the specific problem (such as "insufficient permissions to perform this operation", "proof has expired, please re-verify"), and prompts the user to perform zero-knowledge proof file regeneration operation; If the zero-knowledge proof file passes the verification, the core chain smart contract confirms that the zero-knowledge proof is valid, generates a cross-chain verification credential based on the public input (containing user identity unique identifier, target chain identifier, business scenario code, valid time, contract signature), and stores the credential hash on-chain; If all verifications pass, the verification results (including the hash value of the cross-chain verification credential, the user's unique identity summary, and the scope of business scenario permissions) are transmitted to the edge chain through an encrypted channel (such as IBC, cross-chain message protocol). The edge chain verifies the authenticity and timeliness of the verification results to ensure that business operations are performed only based on legal authorization; The authenticity check is that the edge chain uses the pre-stored core chain public key to verify the consistency between the core chain signature and the verification content (to ensure that the content comes from the core chain and has not been tampered with); If the signature verification fails, the core chain re-verification mechanism is triggered, the edge chain returns an error reminder to the user terminal and rejects subsequent business requests. The user terminal sends a prompt to the user that the verification result source is untrusted and the operation is rejected; The timeliness check is that the edge chain queries the storage status of the cross-chain verification certificate hash through the core chain interface, confirms that the cross-chain verification certificate hash has been stored in the core chain block (located by block height + transaction index), and verifies whether the validity period of the cross-chain verification certificate has expired (for example, if the validity period is set to 30 minutes, the current time must be within 30 minutes of the cross-chain verification certificate generation time. If the difference between the current time and the generation time is greater than 30 minutes, it has expired); If the cross-chain verification credential hash is not stored or has expired, it is determined that the core chain re-verification mechanism is triggered. The edge chain returns an error reminder to the user terminal and records the invalid credential access log. The user terminal sends a reminder to the user that the cross-chain verification has expired or is not effective, and please re-initiate verification; If all checks pass, the edge chain generates a temporary permission token based on the permission scope and current timestamp in the zero-knowledge proof file verification result, which includes the user terminal device identification hash, operation permission list (such as permission to write traceability information), valid timestamp and edge chain signature; The temporary permission token is stored in the local cache of the edge chain (with a timed expiration and automatic cleanup mechanism, such as automatic cleanup after 5 minutes), and the temporary permission token is sent to the user terminal. The user terminal uses the temporary permission token to perform subsequent traceability information writing and other operations.

[0024] Ways to write traceability information to the edge chain include: The user terminal initiates a traceability information write request to the edge chain based on the cross-chain verification certificate and temporary permission token. The request contains the traceability information to be written (depending on the business scenario, the traceability information may vary, such as the product production batch, logistics node, operation type, etc., which are traceability information data processed through JSON serialization); At the same time, the user's real-time biometric data is collected through the user terminal, a real-time biometric hash is generated through a local hash algorithm, and the user terminal device identifier is extracted and attached to the write request. The write information, real-time biometric hash and user terminal device identifier are integrated to generate a request packet; After receiving the request package, the edge link first verifies the validity of the temporary permission token and the cross-chain verification credential, including: parsing the timestamp in the temporary permission token (the deviation from the current time cannot be greater than expected, for example, 5 minutes, that is, the timestamp must be within ±5 minutes of the current time. If it exceeds, the token is expired and invalid), the user terminal device identification hash (if it is consistent with the user terminal device identification submitted by the user terminal, it is valid. If it is inconsistent, the device identification does not match and it is invalid), the operation permission list (needs to include the traceability information write permission. If there is no traceability information write permission, it is insufficient permission and is invalid). At the same time, the core link interface is used to query the certificate status of the cross-chain verification credential ID (the certificate status must not be revoked and is within the validity period, otherwise it is invalid). If the verification fails, the reason is identified. If it is due to token expiration, device identification mismatch or insufficient authority, the edge chain returns a corresponding error reminder to the user terminal, and the user terminal prompts the user to obtain a temporary authority token again. If the certificate has been revoked or is not within the validity period, the edge chain returns a corresponding error reminder to the user terminal, and the user terminal triggers the core chain re-verification mechanism; Once the validity of the temporary permission token and the cross-chain verification credential has been verified, the consistency of the biometric hash with the on-chain identity template and the compliance of the traceability information are verified, including: The edge chain calls the on-chain identity template library to obtain the biometric hash bound to the user's unique identity identifier (the biometric hash from the on-chain identity template) as the biometric reference hash; The real-time biometric hash submitted by the user terminal is compared with the biometric reference hash, that is, the hash values ​​of the two are directly matched; if the hash values ​​do not match, the user is judged to be inconsistent with the authenticated identity, and the edge chain returns an error reminder to the user terminal, records the abnormal operation log, and the user terminal issues a prompt to the user that the biometric verification failed and the write operation is prohibited; After the biometric verification is passed, the edge chain verifies the compliance of the traceability information, that is, performs format verification, including checking the integrity of fields (such as whether the required "product ID" and "operation time" are missing), the legitimacy of data types (such as whether the timestamp format conforms to the standard time format "YYYY-MM-DD HH:MM:SS"), and verifies the compliance of information based on the preset business rule library (based on business scenarios and actual needs, such as setting business rules such as "food traceability must include quarantine certificate number"). If the format is incorrect or non-compliant, the verification is deemed to have failed and an error reminder is returned to the user terminal, which then issues a corresponding prompt to the user (for example, the traceability information format is incorrect or a required field is missing; please correct it and try again). After all verifications are passed, the edge chain generates a write permission instruction, associates the traceability information with the user's real-time biometric hash, user terminal device identification, and temporary permission token hash, forms a structured traceability data unit, and writes it into the edge chain block.

[0025] The methods for generating traceability information chains and cross-chain traceability validity certificates include: After the traceability information is written into the edge chain, the user terminal initiates a cross-chain traceability request to the core chain, and the cross-chain traceability request is accompanied by a cross-chain verification certificate; After the core chain receives the cross-chain traceability request as a coordination node, it first verifies the validity of the cross-chain verification certificate, including querying the storage status of the cross-chain verification certificate through the core chain smart contract (confirming whether it is expired or revoked. If expired or revoked, it is judged to be invalid), and verifies whether the user permissions in the cross-chain verification certificate include cross-chain traceability query permissions (if not, it is judged as insufficient permissions); If the cross-chain verification credentials are invalid or the permissions are insufficient, the core chain returns an error reminder to the user terminal, and the user terminal sends an error to the user (such as a prompt indicating that there is no cross-chain traceability permission, please complete identity verification again); After the cross-chain verification certificate is passed, the core chain matches the preset business-edge chain mapping table (which records the edge chains corresponding to each link in the business scenario, for example, in the financial scenario: in the edge chains of each link of the product, the production link corresponds to the "factory chain" and the logistics link corresponds to the "transportation chain") based on the traceability object in the request (such as the unique identifier of the product), and determines the list of related edge chains to be queried; The core chain sends a query request to each related edge chain, including: cross-chain verification certificate hash (for edge chain verification), traceability object unique identifier (such as the product unique identifier. The unique identifier needs to be encrypted through hashing to prevent the leakage of traceability object information. Therefore, the traceability object unique identifier can be understood as the traceability object ID hash, such as the product ID hash), query time range (the default is the full cycle, and the specific query time range can be adjusted according to actual conditions). The query request is transmitted through the cross-chain message protocol and is attached with the core chain digital signature to ensure authenticity. After receiving the query request, each edge chain retrieves the locally stored traceability information fragment: including the user's real-time biometric hash, the timestamp of the operation, the operation content (such as "production completed", "outbound scan"), and the edge chain block hash (used to locate the original data); The edge chain performs SHA-256 hashing on the local traceability information fragment, encrypts the hash value together with the original traceability information fragment and returns it to the core chain (the encryption key is the preset core chain and edge chain shared key); After the core chain receives the local traceability information fragments of all edge chains, it aggregates the local traceability fragments through a segmented zero-knowledge proof mechanism and verifies the identity consistency and timing logic. Specifically: Group local traceability information fragments by the hash value uniquely identifying the traceability object, and ensure that all local traceability information fragments are associated with the same object (local traceability information fragments with inconsistent hash values ​​are directly discarded); For each set of local traceability information fragments, a segmented proof circuit is generated based on the timestamp (consistent with the proof circuit construction operation) to verify the temporal logic of the local traceability information fragments (e.g., "production" must be earlier than "warehousing", and "warehousing" must be earlier than "transportation"); Aggregate the logic of each segment through zero-knowledge proof to generate a global zero-knowledge proof (private input is the details of each segment, and public input is the object identification hash and time sequence relationship), ensuring that the aggregation process does not leak sensitive information and is logically self-consistent; If there is a contradiction in the temporal logic or the unique identifier of the traceability object does not match, the core chain returns an error reminder to the user terminal, and the user terminal sends an error prompt to the user (for example, there is a contradiction in the traceability information fragment and a complete link cannot be generated); After the identity consistency and timing logic verification are passed, the core chain will concatenate the local traceability information fragments in timestamp order, associate the real-time biometric hash of the user in each local traceability information fragment with the on-chain identity template library, and generate a traceability information chain with identity binding that is concatenated in time. It will also simultaneously generate a cross-chain traceability validity certificate that records the aggregation process and verification results, including the hash of the local traceability information fragment of each edge chain, the global zero-knowledge proof summary, the core chain digital signature, and the generation timestamp; then the cross-chain traceability validity certificate will be uploaded to the chain for storage and then transmitted back to the user terminal.

[0026] Ways to record key usage and identify risks, trigger key restriction mechanisms, dynamically update on-chain identity template permissions, and reversely optimize key-related parameters include: The core chain’s smart contract integrates the traceability information chain, cross-chain traceability validity proof, and key share set data to collect and record key usage trajectories in real time. Specifically, it includes basic information and associated verification data: The basic information includes the user terminal device identification hash (i.e., MAC address hash) for each operation, timestamp, involved chain identification (core chain / edge chain ID), and operation type (authentication / traceability write / cross-chain query, etc.). Associated verification data: cross-chain verification credential ID, temporary permission token hash, user biometric hash and matching result with on-chain identity template; All data is indexed by the structure of user identity unique identifier + timestamp, and is used as a key using the track. It is stored in the core chain distributed ledger in a chain structure (each track node is associated with the hash of the previous node to ensure that it cannot be tampered with). At the same time, a unique track record ID (user identity hash + random number) is generated for traceability; Obtain historical baseline data and compare it with key usage trajectories to identify risky behaviors. Specifically, the trajectory data is analyzed in real time using machine learning models (such as the isolation forest algorithm) deployed on core chain nodes: The input data includes real-time trajectory information (including device, time, and operation frequency) and historical baseline data (including a list of users' frequently used devices, average daily operation times, and regular time periods); The exception judgment rules are preset through the rule engine, specifically: Spatial anomaly: The matching degree between the user terminal device identification and the historically commonly used devices does not meet expectations (e.g., <30%, which is considered an unfamiliar device operation in a different location); Time anomaly: The number of cross-chain operations within a certain period of time (e.g., 1 hour) exceeds expectations (e.g., more than 5 times the historical average, which is considered a high-frequency suspicious operation); Permission exception: The operation type does not match the on-chain identity template permissions (for example, a write request is initiated without write permission, which is considered a permission violation); The preset anomaly determination rules are used as the scoring basis and simultaneously input into the machine learning model. The machine learning model outputs a risk value of 0-100 points (a score of ≥70 triggers a response mechanism) and generates an abnormal behavior log (including the determination basis). It should be noted that there are many types of public models that can be used to obtain the risk score, and they are very mature. This embodiment uses the isolation forest algorithm, which does not require training, as the model by default. The specific deployment and training can be based on actual conditions, and will not be elaborated here. Risky behaviors are assessed and classified into risk levels. The key restriction mechanism is triggered based on the risk level, and corresponding temporary restrictions or key freezing operations are performed. Specifically, the risk level is divided into three levels: Low risk (e.g., score ≤ 69): Only a warning log is generated and a prompt (e.g., "Uncommon device operation detected, identity verification recommended") is pushed to the user terminal. Key usage is not affected. Medium risk (e.g., 70-89 points): Temporary restrictions are triggered, prohibiting sensitive operations such as cross-chain writes (query permissions are retained). The user terminal is required to re-collect biometric data and pass feature root value matching verification. Restrictions are automatically lifted after verification is passed. High risk (e.g., ≥90 points): The key is frozen immediately, and the smart contract marks the key share set as "frozen." All operations that rely on the key return a "permission frozen" error to the user terminal. Recovery requires collaborative verification by at least three distributed nodes (including the user terminal, the authority node, and the core chain node). The distributed nodes resubmit the key shares, and after consistency verification through the VSS protocol, the contract unfreezes the state. All verification data in the traceability process is obtained through the core chain (i.e., all verification information that appeared in the previous process of obtaining traceability information, such as the consistency of the real-time biometric hash and the on-chain identity template and the compliance verification of the traceability information, the validity verification of the cross-chain verification certificate, the user authority verification in the cross-chain verification certificate, etc.), and is counted into the traceability audit results; Based on the traceability audit results and the risk behavior assessment results, the permission attributes of the on-chain identity template are dynamically adjusted. Specifically: If a user fails verification multiple times (e.g., 3 times) but does not reach a high risk level, the user's permissions will be reduced (e.g., removing the "cross-chain write" permission); If the user's operations are in compliance for a long time (e.g. no abnormalities for 6 months), the user's permissions will be expanded (e.g. adding "batch query" permissions); Write permission update records into the on-chain identity template library and simultaneously notify the user terminal to ensure that permission changes are traceable; Reversely optimize the key share splitting parameters and identity private key generation parameters based on risk behavior data; Specifically, the core chain’s smart contract regularly (e.g., quarterly) collects statistics on risk events (e.g., freeze times, abnormal type distribution) in the key restriction mechanism triggered by risky behavior data, and reversely optimizes the key system parameters: If the proportion of abnormalities from infrequently used devices is too high (e.g., >40%), increase the threshold parameter in the Shamir threshold secret sharing scheme (e.g., from 3 to 5, but not higher than the number of key shares, so that more nodes need to verify before key recovery). If the consistency check fails more than once (e.g., three times) when MPC generates the identity private key, increase the number of secure multi-party computation iterations (e.g., from 5 to 8 rounds to improve the stability of private key generation). The optimized parameters need to be signed and confirmed by the authoritative node before they can take effect, and the updated records will be stored on the chain; After each risk event is handled, the results are fed back to the parameter optimization process. The optimized parameters affect the next round of key generation and use, thereby continuously improving the security and adaptability of identity and traceability management. Example 2

[0027] See also Figure 3As shown, for the parts not described in detail in this embodiment, please refer to the description of Example 1. A blockchain-based digital identity authentication and traceability system is provided, including: Key share generation and evidence storage module: obtains user biometric data, performs irreversible conversion through the user terminal to generate characteristic root values ​​and split key shares. After collaborative verification by distributed nodes, a key share set is generated through blockchain evidence storage; Multi-chain identity system construction unit: Based on the key share set, each distributed node generates the identity private key of the corresponding blockchain and the on-chain identity template containing the biometric hash, associates the on-chain identity template with the chain identifier, and forms a multi-chain identity key pool and on-chain identity template library; Cross-chain identity authentication unit: Based on the multi-chain identity key pool and on-chain identity template library, the core chain and edge chain are divided, and zero-knowledge proof is generated through the user terminal. After verification by the core chain, a cross-chain credential is generated and the encrypted result is sent to the edge chain to generate a temporary permission token; Traceability information management module: Based on cross-chain verification credentials and temporary permission tokens, traceability information is written to the edge chain and the user's real-time biometric hash and user terminal device identification are attached. Cross-chain traceability aggregates multi-chain information to generate a traceability information chain and cross-chain traceability validity proof; Risk prevention and optimization unit: Based on the traceability information chain and cross-chain traceability validity proof, it records the key usage trajectory and identifies risky behaviors, triggers the key restriction mechanism, dynamically updates the identity template permissions on the chain, reversely optimizes key-related parameters, and forms a closed-loop iterative identity and traceability management chain. Example 3

[0028] This embodiment discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the operation mode of the blockchain-based digital identity authentication and traceability system provided above is implemented.

[0029] Since the electronic device introduced in this embodiment is an electronic device used to implement the blockchain-based digital identity authentication and traceability method in the embodiment of this application, based on the blockchain-based digital identity authentication and traceability method introduced in the embodiment of this application, those skilled in the art can understand the specific implementation of the electronic device of this embodiment and its various variations, so how the electronic device implements the method in the embodiment of this application will not be described in detail here. As long as those skilled in the art implement the electronic device used in the blockchain-based digital identity authentication and traceability method in the embodiment of this application, it falls within the scope of protection of this application.

[0030] The above formulas are all dimensionless and numerical calculations. The formulas are obtained by collecting a large amount of data and performing software simulation to obtain the most recent real situation. The preset parameters and thresholds in the formulas are set by technicians in this field according to actual conditions.

[0031] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiment. All technical solutions based on the principles of the present invention are within the scope of protection of the present invention. It should be noted that for users of ordinary skill in the art, various improvements and modifications that do not depart from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A digital identity authentication and traceability method based on blockchain, characterized in that: include: S1: Obtain user biometric data, perform irreversible conversion on the user terminal to generate characteristic root values ​​and split key shares. After collaborative verification by distributed nodes, generate a key share set through blockchain evidence storage; S2: Based on the key share set, each distributed node generates the identity private key of the corresponding blockchain and the on-chain identity template containing the biometric hash, associates the on-chain identity template with the chain identifier, and forms a multi-chain identity key pool and on-chain identity template library; S3: Based on the multi-chain identity key pool and on-chain identity template library, the core chain and edge chain are divided, and zero-knowledge proof is generated through the user terminal. After verification by the core chain, a cross-chain credential is generated and the encrypted result is sent to the edge chain to generate a temporary permission token; S4: Based on the cross-chain verification certificate and temporary authority token, traceability information is written to the edge chain and the user's real-time biometric hash and user terminal device identification are attached. Cross-chain traceability aggregates multi-chain information to generate a traceability information chain and a cross-chain traceability validity certificate. S5: Based on the traceability information chain and cross-chain traceability validity proof, record the key usage trajectory and identify risky behaviors, trigger the key restriction mechanism, dynamically update the on-chain identity template permissions, reversely optimize key-related parameters, and form a closed-loop iterative identity and traceability management chain.

2. The blockchain-based digital identity authentication and traceability method according to claim 1, characterized in that: The method of generating the characteristic root value and splitting the key shares includes: Collect the required user's original biometric data through the user terminal, and complete the standardization and noise reduction processing locally; Serialize the processed biometric data into a byte stream, perform an irreversible hash operation on the byte stream, and generate a fixed-length hash value as the feature root value; Distributed nodes are preset, and the characteristic root value is split into multiple key shares according to the number of distributed nodes. The user terminal distributes the key shares to other distributed nodes through an encrypted channel.

3. The blockchain-based digital identity authentication and traceability method according to claim 2, characterized in that: The key share set is generated in the following manner: After receiving the key share, the distributed node verifies the authenticity and validity of the key share and records the corresponding verification timestamp and verification log; If the verification fails, the key share of the corresponding distributed node is deemed invalid and requires redistribution; For all distributed nodes that have passed key share verification, each distributed node uploads the hash value of its own key share, verification timestamp, and its own node digital signature to the blockchain to form structured data; Generate a root hash based on structured data and write it into the blockchain block for evidence storage, and then integrate the evidence root hash and verification log on the blockchain as a key share set.

4. The blockchain-based digital identity authentication and traceability method according to claim 3 is characterized in that: The method of generating the identity private key corresponding to the blockchain and the on-chain identity template containing the biometric hash includes: Distributed nodes obtain their own stored key shares and verification logs from the key share set; For each preset blockchain, each distributed node collaboratively generates the identity private key of the corresponding blockchain based on the key share set; At the same time, the user terminal extracts the hash summary of the feature root value as the biometric hash based on the biometric data, extracts and integrates the user's basic attributes and initial permission range to form template basic data; The template base data is encrypted and associated with the identity private key to form the final on-chain identity template.

5. The blockchain-based digital identity authentication and traceability method according to claim 4 is characterized in that: The multi-chain identity key pool and the on-chain identity template library are formed in the following ways: Call the preset chain identification list, bind the unique chain ID of each blockchain to the corresponding on-chain identity template and perform hash mapping to establish a unique association; Aggregate the public keys of the corresponding chain identity private keys generated by each distributed node by chain identifier, and build a multi-chain identity key pool with the chain identifier and user identity unique identifier as index; The on-chain identity template is stored in the distributed storage area through the user terminal to form an on-chain identity template library; Aggregate unique association information, index information of the multi-chain identity key pool, and the storage address of the on-chain template library to generate an association relationship, and store the root hash of the association relationship on-chain; The consistency verification mechanism is triggered synchronously to verify the association relationship. After the verification passes, the multi-chain identity key pool and the on-chain identity template library are determined to be effective.

6. The blockchain-based digital identity authentication and traceability method according to claim 5, characterized in that: The generation method of the zero-knowledge proof includes: Based on the multi-chain identity key pool and on-chain identity template library, the user terminal loads the identity private key and on-chain identity template associated with the current business scenario; Based on preset scenario rules, the blockchain network is divided into core chains and edge chains according to their functions. The core chain is used for global verification, and the edge chain is used for business processing. Generate the private input and public input of the zero-knowledge proof through the user terminal based on the loaded identity private key and the on-chain identity template; Then, a proof circuit is constructed based on the logical association between private input and public input to generate a zero-knowledge proof file.

7. The blockchain-based digital identity authentication and traceability method according to claim 6, characterized in that: The temporary authorization token is generated by: Submit the zero-knowledge proof file to the core chain through the user terminal for integrity and validity verification. If the verification fails, the zero-knowledge proof file regeneration mechanism is triggered; If the zero-knowledge proof document is verified, a cross-chain verification certificate is generated and stored on the chain; The verification result is then transmitted to the edge chain through an encrypted channel. The edge chain verifies the validity of the verification result. If the verification fails, the core chain re-verification mechanism is triggered. If the verification passes, a temporary permission token is generated based on the permission range in the verification result and the current timestamp.

8. The blockchain-based digital identity authentication and traceability method according to claim 7, characterized in that: The method of writing traceability information to the edge chain includes: The user terminal initiates a traceability information writing request to the edge chain based on the cross-chain verification certificate and temporary permission token. At the same time, the user's real-time biometric hash and user terminal device identification are collected and attached to the request to generate a request package. After receiving the request package, the edge chain verifies the validity of the temporary permission token and the cross-chain verification credential, and then verifies the consistency of the real-time biometric hash with the on-chain identity template and the compliance of the traceability information; If the verification passes, the traceability information is allowed to be written. If the verification fails, an error reminder is returned to the user terminal and the core chain re-verification mechanism is triggered.

9. The blockchain-based digital identity authentication and traceability method according to claim 8, characterized in that: The generation methods of the traceability information chain and cross-chain traceability validity proof include: After the traceability information is written into the edge chain, a cross-chain traceability request is initiated to the core chain through the user terminal. After the core chain receives the cross-chain traceability request as a coordination node, it sends a query request with cross-chain verification credentials to the relevant edge chain; It then aggregates local traceability information fragments received from each edge link, including real-time biometric hashes and timestamps, and verifies identification consistency and temporal logic; When the local traceability information fragment is verified, a traceability information chain with identity binding is generated in series by time, and a cross-chain traceability validity certificate that records the aggregation process and verification results is generated simultaneously and transmitted back to the user terminal; If the verification fails, the verification failure result is recorded and sent to the user terminal.

10. The blockchain-based digital identity authentication and traceability method according to claim 9, characterized in that: The methods of recording key usage traces and identifying risks, triggering key restriction mechanisms, dynamically updating on-chain identity template permissions, and reversely optimizing key-related parameters include: Based on the traceability information chain, cross-chain traceability validity proof and key share set, key usage data is extracted in real time through the core chain to record the key usage trajectory; Obtain historical baseline data, compare it with key usage traces, and identify risky behaviors; Evaluate risky behaviors and classify them into risk levels. Based on the risk level, trigger the key restriction mechanism and perform corresponding temporary restrictions or key freezing operations. Obtain all verification data in the traceability process through the core chain and compile statistics into traceability audit results; Dynamically adjust the permission attributes of the on-chain identity template based on the traceability audit results, and reversely optimize the key share splitting parameters and the identity private key generation parameters based on risk behavior data.

Images