Blockchain-based digital identity authentication and traceability method

Abstract

The present application belongs to the technical field of block chain, and discloses a digital identity authentication and traceability method based on block chain, which comprises the following steps: acquiring user biological characteristic data, generating eigenvalue and splitting key shares, and generating a key share set through block chain storage; each distributed node generates an identity private key and an on-chain identity template, associates the on-chain identity template with a chain identifier, forms a multi-chain identity key pool and an on-chain identity template library; a core chain and an edge chain are divided, a zero-knowledge proof is generated, the core chain verifies the cross-chain credential and sends the encrypted result to the edge chain, and a temporary permission token is generated; the traceability information is written to the edge chain, the cross-chain traceability aggregates multi-chain information, the traceability information chain and the cross-chain traceability validity proof are generated; the key usage track is recorded and the risk behavior is identified, the key restriction mechanism is triggered, the on-chain identity template permission is dynamically updated, the key related parameters are reversely optimized, and the closed-loop iterative identity and traceability management link is formed.

Description

Technical Field

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

[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 relying on centralized institutions can easily lead to data monopolies and single points of failure; direct storage of sensitive information such as biometrics poses a risk of leakage; in cross-chain scenarios, the foundation of identity trust is not unified, making it difficult for identities to be interoperable between different blockchains; in traceability systems, data and operating entities are loosely bound, information is fragmented and easily tampered with, making it difficult to form a complete and trustworthy traceability chain; at the same time, the balance between privacy protection and information verification has not been effectively resolved. These shortcomings seriously restrict the security and cross-scenario applicability of the digital identity system.

[0003] Existing solutions have several limitations: centralized identity schemes, while achieving unified management, are vulnerable to attacks; distributed identity schemes lack a root trust mechanism based on biometrics, and cross-chain identity association relies on third-party intermediaries; traceability systems are mostly limited to data records within a single chain, resulting in chaotic information associations during cross-chain traceability and easy exposure of user privacy (such as biometrics and attribute information) during verification; encryption technology is inefficient in cross-chain interactions, and privacy protection methods such as zero-knowledge proofs lack dynamic adaptability; risk control relies on static rules, resulting in delayed responses to abnormal behaviors such as remote operations and permission overreach, and lacks emergency key management and parameter self-optimization mechanisms, making it difficult to cope with security challenges in complex scenarios. Summary of the Invention

[0004] To overcome the aforementioned shortcomings of existing technologies and achieve the above objectives, this invention provides the following technical solution: a blockchain-based digital identity authentication and traceability method, comprising:

[0005] S1: Obtain user biometric data, perform irreversible transformation through user terminal to generate feature root values ​​and split key shares, after collaborative verification by distributed nodes, generate key share set through blockchain notarization;

[0006] S2: Based on the key share set, each distributed node generates the corresponding blockchain identity private key and on-chain identity template containing biometric hash, and associates the on-chain identity template with the chain identifier to form a multi-chain identity key pool and on-chain identity template library;

[0007] S3: Based on a multi-chain identity key pool and on-chain identity template library, the core chain and edge chain are divided. Zero-knowledge proofs are generated through user terminals. After verification by the core chain, cross-chain credentials are generated and encrypted results are sent to the edge chain to generate temporary permission tokens.

[0008] S4: Based on cross-chain verification credentials and temporary permission tokens, write traceability information to the edge chain and attach the user's real-time biometric hash and user terminal device identifier. Cross-chain traceability aggregates multi-chain information to generate a traceability information chain and cross-chain traceability validity proof.

[0009] S5: 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 on-chain identity template permissions, and reversely optimizes key-related parameters to form a closed-loop iterative identity and traceability management link.

[0010] Furthermore, the method for generating eigenvalues ​​and splitting key shares includes:

[0011] The required raw biometric data of users is collected through user terminals, and standardized and noise-reducing processing is completed locally.

[0012] The processed biometric data is serialized into a byte stream, and an irreversible hash operation is performed on the byte stream to generate a fixed-length hash value as the feature root value.

[0013] The system pre-defines distributed nodes and splits the feature root value into multiple key shares based on the number of distributed nodes. The user terminal then distributes these key shares to other distributed nodes via an encrypted channel.

[0014] Furthermore, the generation method of the key share set includes:

[0015] After receiving the key share, the distributed node verifies the authenticity and validity of the key share's source and records the corresponding verification timestamp and verification log.

[0016] If the verification fails, the key share of the corresponding distributed node is deemed invalid and redistribution is required.

[0017] For all distributed nodes whose key shares have been verified, each distributed node uploads its own key share hash value, verification timestamp, and its own node digital signature to the blockchain to form structured data.

[0018] The root hash is generated based on the structured data, written into the blockchain block for notarization, and then integrated with the notarized root hash and verification log on the blockchain as a key share set.

[0019] Furthermore, the method for generating the corresponding blockchain's private key and the on-chain identity template containing biometric hashes includes:

[0020] Distributed nodes obtain their own stored key shares and verification logs from the key share set;

[0021] For each pre-defined blockchain, each distributed node collaboratively generates the corresponding blockchain's identity private key based on a key share set.

[0022] Meanwhile, based on biometric data, the user terminal extracts the hash digest of the feature root value as the biometric hash, extracts and integrates the user's basic attributes and initial permission range to form template basic data;

[0023] The template's basic data is encrypted and associated with the identity's private key to form the final on-chain identity template.

[0024] Furthermore, the formation methods of the multi-chain identity key pool and on-chain identity template library include:

[0025] Call the preset list of chain identifiers, bind the unique chain ID of each blockchain with the corresponding on-chain identity template and perform hash mapping to establish a unique association;

[0026] The public keys of the corresponding chain identity private keys generated by each distributed node are aggregated according to the chain identifier, and a multi-chain identity key pool is constructed using the chain identifier and the user's unique identity identifier as indexes.

[0027] User terminals store on-chain identity templates into a distributed storage area to form an on-chain identity template library.

[0028] Summarize the unique association information, the index information of the multi-chain identity key pool, and the storage address of the on-chain template library to generate the association relationship, and put the root hash of the association relationship on the chain for evidence storage;

[0029] The consistency verification mechanism is triggered synchronously to verify the association relationship. After the verification is passed, the multi-chain identity key pool and on-chain identity template library are deemed to be effective.

[0030] Furthermore, the generation method of the zero-knowledge proof includes:

[0031] Based on a multi-chain identity key pool and on-chain identity template library, the user terminal loads the private key of the identity associated with the current business scenario and the on-chain identity template.

[0032] Based on preset scenario rules, the blockchain network is divided into a core chain and an edge chain according to function; the core chain is used for global verification, and the edge chain is used for business processing.

[0033] Based on the loaded private key and on-chain identity template, the user terminal generates private and public inputs for zero-knowledge proofs.

[0034] Then, a proof circuit is constructed based on the logical connection between private and public inputs to generate a zero-knowledge proof document.

[0035] Furthermore, the temporary permission token is generated in the following ways:

[0036] The user terminal submits the zero-knowledge proof file to the core chain for integrity and validity verification. If the verification fails, the zero-knowledge proof file regeneration mechanism is triggered.

[0037] If the zero-knowledge proof document passes verification, a cross-chain verification credential is generated and stored on the blockchain.

[0038] The verification result is then transmitted to the edge chain via 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 scope in the verification result and the current timestamp.

[0039] Furthermore, the method of writing traceability information to the edge chain includes:

[0040] The user terminal initiates a request to write traceability information to the edge chain based on cross-chain verification credentials and temporary permission tokens. At the same time, it collects the user's real-time biometric hash and user terminal device identifier, and attaches them to the request to generate a request packet.

[0041] After receiving the request packet, the edge link verifies the validity of the temporary permission token and the cross-chain verification certificate, and then verifies the consistency between the real-time biometric hash and the on-chain identity template, as well as the compliance of the traceability information.

[0042] If the verification passes, the traceability information is allowed to be written; if the verification fails, an error message is returned to the user terminal, and the core chain re-verification mechanism is triggered.

[0043] Furthermore, the generation methods for the traceability information chain and cross-chain traceability validity proof include:

[0044] Once the traceability information is written to 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 coordinating node, it sends a query request with cross-chain verification credentials to the relevant edge chain.

[0045] Then, it aggregates local traceability information fragments containing real-time biometric hashes and timestamps collected from various edge links, and verifies the consistency of the identifiers and the temporal logic.

[0046] Once the local traceability information fragment is verified, a traceability information chain with identity binding is generated and linked by time. Simultaneously, a cross-chain traceability validity certificate recording the aggregation process and verification results is generated and sent back to the user terminal.

[0047] If the verification fails, the verification failure result is recorded and sent to the user's terminal.

[0048] Furthermore, the methods for recording key usage patterns and identifying risks, triggering key restriction mechanisms, dynamically updating on-chain identity template permissions, and reverse-optimizing key-related parameters include:

[0049] Based on the traceability information chain, cross-chain traceability validity proof, and key share set, key data on key usage is extracted in real time through the core chain, and the key usage trajectory is recorded.

[0050] Historical baseline data is obtained and compared with the key usage trajectory to identify risky behaviors;

[0051] Assess risky behaviors and classify them into risk levels. Trigger the key restriction mechanism based on the risk level and execute corresponding temporary restrictions or key freezing operations.

[0052] All verification data during the traceability process is obtained through the core chain and compiled into traceability audit results.

[0053] The permission attributes of the on-chain identity template are dynamically adjusted based on the source audit results, and the key share splitting parameters and identity private key generation parameters are optimized in reverse based on risk behavior data.

[0054] The technical effects and advantages of the blockchain-based digital identity authentication and traceability method of this invention are as follows:

[0055] This invention generates feature root values ​​through irreversible transformation of biometric features, and combines threshold secret sharing to split key shares and distributed verification and storage. This avoids the privacy risks of directly storing original biometric features, and uses feature root values ​​as global identity root trust, solving the problem of inconsistent cross-chain identity trust foundation. Distributed verification and storage ensure the security and traceability of key shares.

[0056] Secondly, it generates cross-chain identity private keys and encrypted identity templates, builds a multi-chain key pool, and generates encrypted identity templates containing biometric hashes and attribute information. This enables dynamic binding of identity private keys and chain identifiers, solving the problem of cross-chain identity interoperability. Template encryption and permission association protect user attribute privacy.

[0057] Then, by dividing the core chain (global verification) and the edge chain (business processing), functional division is achieved, improving the efficiency of cross-chain interaction. At the same time, zero-knowledge proofs are generated based on identity information, which avoids privacy data leakage while completing identity and permission verification. This solves the problem of privacy and security being difficult to balance in traditional verification and provides a secure and efficient trust transfer mechanism for cross-chain operations.

[0058] Next, when writing traceability information, real-time biometric hashes and device identifiers are attached to ensure that traceability operations are strongly bound to identities. During cross-chain traceability, a complete traceability information chain with identity binding is formed through the aggregation of multi-chain information fragments and logical verification, which solves the problems of fragmented traceability data and untraceable subject responsibility. Cross-chain validity proof further enhances the credibility of traceability results.

[0059] Finally, based on traceability information and key trajectory records, risky behaviors are identified through machine learning and key control mechanisms are dynamically triggered. At the same time, identity permissions are updated and key parameters are optimized according to audit results, realizing real-time risk response and system self-iteration. This solves the problems of lagging risk prevention and control and insufficient adaptability of traditional solutions, forming a closed-loop system of "identity generation - cross-chain verification - traceability management - risk optimization", which significantly improves the system's security, privacy protection and scenario adaptability. Attached Figure Description

[0060] Figure 1 This is a flowchart illustrating the blockchain-based digital identity authentication and traceability method of the present invention.

[0061] Figure 2 This is a schematic diagram of the core chain verification zero-knowledge proof process in the blockchain-based digital identity authentication and traceability method of the present invention;

[0062] Figure 3 This is a schematic diagram of the blockchain-based digital identity authentication and traceability system of the present invention. Detailed Implementation

[0063] 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. Example 1

[0064] Please see Figure 1 and Figure 2 As shown in this embodiment, the blockchain-based digital identity authentication and traceability method includes:

[0065] S1: Obtain user biometric data, perform irreversible transformation through user terminal to generate feature root values ​​and split key shares, after collaborative verification by distributed nodes, generate key share set through blockchain notarization;

[0066] S2: Based on the key share set, each distributed node generates the corresponding blockchain identity private key and on-chain identity template containing biometric hash, and associates the on-chain identity template with the chain identifier to form a multi-chain identity key pool and on-chain identity template library;

[0067] S3: Based on a multi-chain identity key pool and on-chain identity template library, the core chain and edge chain are divided. Zero-knowledge proofs are generated through user terminals. After verification by the core chain, cross-chain credentials are generated and encrypted results are sent to the edge chain to generate temporary permission tokens.

[0068] S4: Based on cross-chain verification credentials and temporary permission tokens, write traceability information to the edge chain and attach the user's real-time biometric hash and user terminal device identifier. Cross-chain traceability aggregates multi-chain information to generate a traceability information chain and cross-chain traceability validity proof.

[0069] S5: 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 on-chain identity template permissions, and reversely optimizes key-related parameters to form a closed-loop iterative identity and traceability management link.

[0070] This solution is applicable to fields 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.

[0071] Methods for generating eigenvalues ​​and splitting key shares include:

[0072] Users initiate the identity authentication process through user terminals (such as mobile phones and self-service terminals), which collects the necessary original biometric data of users (such as fingerprints, irises, and faces).

[0073] The user terminal preprocesses the raw biometric data, including standardization and noise reduction.

[0074] It should be noted that there are well-established preprocessing methods for various types of biometric data, which will not be listed here, but only two examples will be given:

[0075] Fingerprint biometric data: 128 minutiae feature points (including endpoints, bifurcation points, and isolated points) were extracted from the fingerprint image using a Gabor filter. The coordinates, orientation angle, and type label of each feature point were recorded. Duplicate or noisy feature points were removed using the Delaunay triangulation algorithm.

[0076] Iris biometric data: A level 2 Daubechies-4 wavelet transform was performed on the iris ROI region to extract a 64×64 dimension texture feature vector. The feature values ​​were then mapped to the [-1,1] interval through Z-score normalization to remove feature fluctuations caused by differences in illumination intensity.

[0077] It should be noted that the standardization and noise reduction of the original biometric data are performed locally on the user terminal. The original biometric data never leaves the device. The generation and transmission of feature root values ​​and key shares are protected by hardware-level encryption to ensure that they cannot be reverse-engineered or stolen.

[0078] The user terminal calls the SHA-512 / 256 truncated hash algorithm to convert the preprocessed biometric data into a 128-bit fixed-length hash value, which is used as the feature root value.

[0079] 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).

[0080] The byte stream is subjected to an irreversible hash operation using the SHA-512 algorithm. The first 128 bits of the hash value are taken as the irreversible feature root value. After the operation is completed, only the feature root value is retained and the original feature data is immediately cleared. The feature root value generation process is completed locally on the user terminal. The original biometric data is not stored or uploaded. Only the hash operation result is retained as the unique seed for subsequent key generation.

[0081] Pre-set distributed nodes and use the Shamir threshold secret sharing scheme to split the feature root value into key shares according to the number of distributed nodes;

[0082] Specifically, preset distributed nodes (usually set to no less than 5, such as: user terminal, local authoritative 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, then the threshold parameter is 3).

[0083] Then, the Shamir threshold secret sharing scheme is used to split the feature root value according to the preset number of distributed nodes and threshold parameters to obtain the key share corresponding to the number of distributed nodes.

[0084] 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 the non-exportable area of ​​the user terminal's security chip and is bound to the device hardware (biometric features need to be re-collected when the device is replaced).

[0085] The methods for generating key share sets include:

[0086] 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.

[0087] Specifically, the source authenticity verification is as follows: After the preset distributed nodes receive their respective key shares through an encrypted channel, they start the local verification module. Each distributed node calls the preset verification algorithm to first verify 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 conforms to the 256-bit numerical specification). Then, it verifies the authenticity of the key share source through the digital signature of the user terminal that is received synchronously, and rejects shares with invalid signatures or abnormal formats.

[0088] The validity verification is performed through 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 pre-defined quadratic polynomial relationship in the Shamir threshold secret sharing scheme according to the polynomial consensus rule (if the threshold parameter is set to 3, then the commitment values ​​of at least 3 distributed nodes must satisfy the polynomial). If any distributed node's commitment deviates from the polynomial, the key share of that distributed node is deemed invalid and redistribution is required.

[0089] If the verification fails, the key share of the corresponding distributed node is deemed invalid and redistribution is required.

[0090] For distributed nodes whose key shares have been verified, each distributed node uploads its own key share hash value, verification timestamp, and its own digital signature to a designated smart contract on the blockchain for notarization. The contract aggregates the notarization information of all distributed nodes and generates structured data containing the hash of each key share, notarization address, and a list of verified nodes.

[0091] The root hash is generated from the structured data using the Merkle tree algorithm, written into the blockchain block for notarization, and then integrated with the notarized root hash and verification log on the blockchain as a key share set. The index information of the key share of each distributed node is added to the key share set.

[0092] After generating the key share set, an integrity check is automatically performed:

[0093] Randomly select the key share of a number of distributed nodes corresponding to the threshold parameter, and attempt to restore the hash of the eigenvalue through secure multi-party computation (MPC) (only verify hash consistency, do not restore the original value).

[0094] If the restored hash matches the generated characteristic root value hash, the share set is confirmed to be valid; otherwise, a re-verification process is triggered to ensure that the final generated key share set is traceable and reversible.

[0095] Methods for generating the corresponding blockchain identity private key and on-chain identity template containing biometric hashes include:

[0096] Distributed nodes obtain their stored key shares and verification logs from the key share set through the blockchain smart contract interface, and match the hash value of the stored evidence with the node ID (unique identifier) ​​to confirm the validity of the key share.

[0097] Distributed nodes establish temporary sessions through a pre-defined secure communication protocol (such as an encrypted channel based on the Noise protocol) to synchronize the chain identifier (including the blockchain's chain ID (i.e., the blockchain's unique identifier) ​​and encryption algorithm type) and key generation parameters (such as secp256k1 elliptic curve) of the target blockchain network.

[0098] For each pre-defined blockchain, each distributed node invokes the MPC protocol (i.e., secure multi-party computation protocol) to collaboratively generate the corresponding blockchain's identity private key based on the key share set;

[0099] The specific method is as follows: each distributed node inputs its local key share, and through secret shared addition, they jointly calculate the original key corresponding to the feature root value without revealing their respective key shares; after processing the original key through chain identifier hash (i.e., combining the chain ID and the original key, and performing hash processing through the SHA-256 hash algorithm), an identity private key (256 bits) bound to the blockchain is generated to ensure the uniqueness of identity private keys across different chains;

[0100] Based on biometric data, the user terminal extracts the hash digest of the feature root value (the hash digest is obtained by hashing the feature root value through the SHA-256 hash algorithm) as the biometric hash. It also extracts and integrates the user's basic attributes (such as name hash, document type hash, etc., all of which have undergone irreversible conversion processing) and the initial permission scope (such as "only allowed to query traceability information") to form the template basic data.

[0101] The attribute-based encryption (CP-ABE) algorithm is used to encrypt the basic data of the template, 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;

[0102] 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, attaches it to the encrypted on-chain identity template, and then sends it to the core chain node. The core chain node verifies the consistency between the signature and the identity private key, and confirms the binding relationship between the template and the private key.

[0103] After successful verification, the user terminal will temporarily store the encrypted on-chain identity template locally.

[0104] The formation methods of multi-chain identity key pools and on-chain identity template libraries include:

[0105] The core chain's smart contract invokes a pre-defined list of chain identifiers (containing each blockchain's unique chain ID and functional type (e.g., financial chain, logistics chain)) to generate an on-chain identity template for each blockchain.

[0106] Each blockchain's unique chain ID is bound to its corresponding on-chain identity template and hashed. Specifically, the on-chain identity template is hashed using the SHA-256 hash algorithm, and the hash value is then bound to the chain ID, thus establishing a unique one-to-one 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, thereby ensuring the unique binding of chain identifier - on-chain identity template - identity private key.

[0107] Each distributed node uploads the public key (not the private key itself) of the corresponding chain identity private key to the core chain. The smart contract of the core chain aggregates the public key information according to the 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's unique identity identifier (generated based on the feature root value hash). The index can quickly locate a user's identity public key on a specific chain, thereby supporting efficient retrieval when querying cross-chain identity.

[0108] User terminals upload on-chain identity templates to a distributed storage area (such as IPFS (InterPlanetary File System)) designated by the core chain, and write the IPFS hash and access control policy of the on-chain identity templates into a smart contract to form an on-chain identity template library.

[0109] The access control policy is set so that only distributed nodes that hold the corresponding identity private key or have auditing permissions (such as authoritative institution nodes) can access the on-chain identity template content through the decryption key (associated with the identity private key), while ordinary distributed nodes can only obtain the hash digest of the on-chain identity template for verification.

[0110] 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 to generate a Merkle tree of association, obtain the root hash of the association, and then write the root hash of the association into the blockchain block to complete the on-chain evidence storage.

[0111] The consistency verification mechanism is triggered synchronously to verify the association relationship. After the verification is passed, the multi-chain identity key pool and on-chain identity template library are determined to be effective, thereby realizing the systematic management of multi-chain identities and the foundation for cross-chain association.

[0112] The consistency verification mechanism is as follows: randomly select the association information of the blockchain corresponding to the threshold parameter (3 records) and verify whether the chain identifier, on-chain identity template hash, and multi-chain identity key pool public key match the preset binding rules (the binding rules are set by experts based on the actual situation, such as whether the public key is generated by the corresponding private key).

[0113] Methods for generating zero-knowledge proofs include:

[0114] Based on the multi-chain identity key pool and on-chain identity template library, the user terminal parses and loads the chain identifier (such as "transportation service chain" corresponding to the current business scenario), identity private key (extracted from the multi-chain identity key pool), and on-chain identity template locally.

[0115] Based on preset scenario rules, the blockchain network is divided into a core chain and an edge chain according to function; the core chain is used for global verification, and the edge chain is used for business processing.

[0116] Specifically, the distinction between 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. It must meet the requirements of high consensus strength and high data immutability, and is suitable for handling core logic such as cross-chain identity verification and permission template updates. The edge chain undertakes data processing for specific business scenarios (such as airport customs clearance verification and commodity traceability information entry). It must meet the requirements of low latency and lightweight deployment, and retain only the permission set related to the scenario (such as "only allow writing traceability data").

[0117] Then, a chain function tag library is predefined in the smart contract, which includes three types of tags: function type tags (containing the function type that each chain is responsible for), security level tags (the core chain has the highest security level (e.g., level three), and the edge chain is set as needed below the highest level (e.g., level one or level two)), and interaction frequency threshold (i.e., the interaction frequency threshold between the core chain and the edge chain, such as ≤100 times / minute, to avoid high-frequency interactions from affecting the performance of the core chain).

[0118] The user terminal calls the on-chain identity template library to obtain the requirement tags for 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.

[0119] After the matching results are verified locally on the user terminal (verifying the historical binding records of the verification 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.

[0120] Based on the loaded private key and on-chain identity template, the user terminal generates private and public inputs for zero-knowledge proofs.

[0121] Specifically, private inputs include the identity private key, the complete biometric hash in the on-chain identity template, and permission attributes;

[0122] Public inputs include the chain identifier of the target blockchain, the preset business scenario code (such as "clearance-202408"), and the timestamp;

[0123] The proof generation algorithm is invoked through the user terminal, and a proof circuit is constructed based on the logical connection between private and public inputs to generate a zero-knowledge proof file.

[0124] It should be noted that the core purpose of this process is to transform the logic of identity validity into a verifiable mathematical circuit.

[0125] The logical association of the proof circuit is defined as follows: The zero-knowledge proof circuit is designed using the Circom language. The proof circuit needs to strictly define the logical association between private inputs and public inputs. The core logical associations include:

[0126] 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).

[0127] Logic 2: The permission attributes in private inputs contain the business scenario code in public inputs;

[0128] Logic 3: The timestamp in the public input is within a valid range (e.g., current time ± 5 minutes) to prevent proof reuse;

[0129] The proof circuit solidifies these logics through corresponding constraint equations (e.g., logic 1 is implemented through elliptic curve signature verification constraints, and logic 2 is implemented through string matching constraints), ultimately generating a circom circuit file;

[0130] The handling of private and public inputs during the circuit construction process is as follows:

[0131] The identity private key is encrypted in the terminal TEE environment and participates in circuit calculations only in ciphertext form; the biometric hash is obtained by decryption from the on-chain identity template library and is bound to the identity private key for verification; the permission attributes are extracted from the on-chain identity templates and converted into binary arrays for logical matching; the chain identifier of the target blockchain is input as a string and converted into a hash value for proof circuit constraints; the business scenario code is a preset scenario ID, which is used for inclusion verification with the permission attributes; the timestamp is a Unix timestamp generated locally on the user terminal and matches the time range constraints in the proof circuit.

[0132] Then, zero-knowledge proof technology is used to generate a zero-knowledge proof file (containing the proof data of the circuit file and the public input hash) based on the circuit file. Specifically, this involves the following steps:

[0133] 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, generate a verification key and a proof key as a key pair, which are pre-deployed in the core chain smart contract.

[0134] Step 2: Witness generation. The user terminal calls the WASM file, inputs private and public inputs, and calculates the witness (i.e., the solution that satisfies the proof circuit logic) that satisfies the R1CS constraint. The witness is generated only locally on the terminal and is not transmitted externally.

[0135] Step 3: Proof computation. The user terminal uses the proof key and witness to generate an unverified zero-knowledge proof file (containing proof data and public input hash) through the Groth16 algorithm.

[0136] Step 4: Local verification. The user terminal calls the verification key to perform pre-verification on the generated unverified zero-knowledge proof file (verifying the consistency between the proof format and the public input). After passing the verification, it is packaged into a zero-knowledge proof file that can be used for cross-chain verification requests.

[0137] Temporary permission tokens can be generated in the following ways:

[0138] When a user submits a zero-knowledge proof file from the cryptographic API to the core chain smart contract via a user terminal, the core chain verification module is triggered to perform integrity and validity verification.

[0139] First, the format integrity of the zero-knowledge proof file is verified, that is, the length of the proof data is checked to see if it conforms to the output specification (such as the Groth16 algorithm output specification, which is fixed at 3 256-bit elliptic curve points, totaling 768 bytes), the format of the public input hash is verified, and the public input fields are parsed to see if they are complete.

[0140] If the format validation fails (e.g., length mismatch, missing field), it is determined that the validation is unsuccessful and the zero-knowledge proof file regeneration mechanism is triggered. This includes immediately returning an error reminder to the user terminal and recording a failure log (including the user terminal device identifier hash (i.e., the user terminal's MAC address hash) and the failure time). After receiving the log, the user terminal will prompt the user to perform the zero-knowledge proof file regeneration operation.

[0141] After the format verification passes, the core chain calls the Groth16 algorithm to verify the logical consistency between the proof data and the public input. That is, it verifies whether the logic of the proof data and the public input satisfies the logic defined in the logical association. If any logical constraint is not satisfied, it is determined that the verification fails, triggering the zero-knowledge proof file regeneration mechanism. This includes immediately returning an error message to the user terminal and writing the reason for the failure to the on-chain log (only recording the error type, without disclosing private information). After receiving the message, the user terminal will prompt the user with the specific problem based on the error message (such as "Insufficient permissions, unable to perform this operation" or "Proof has expired, please re-verify") and prompt the user to perform the zero-knowledge proof file regeneration operation.

[0142] If the zero-knowledge proof document passes verification, the core chain smart contract confirms the validity of the zero-knowledge proof, generates a cross-chain verification credential based on the public input (including the user's unique identity identifier, target chain identifier, business scenario code, validity period, and contract signature), and stores the credential hash on the chain.

[0143] If all verifications pass, the verification results (including the hash value of the cross-chain verification credential, the user's unique identifier digest, and the scope of business scenario permissions) are transmitted to the edge chain via an encrypted channel (such as IBC, a cross-chain messaging protocol). The edge chain verifies the authenticity and timeliness of the verification results to ensure that business operations are only performed based on legitimate authorization.

[0144] Among them, the authenticity verification is to use 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).

[0145] If signature verification fails, the core chain re-verification mechanism is triggered, the edge chain returns an error message to the user terminal and rejects subsequent business requests, and the user terminal sends a message to the user that the verification result source is untrusted and the operation is rejected.

[0146] The timeliness verification involves the edge chain querying the storage status of the cross-chain verification certificate hash through the core link interface to confirm that the cross-chain verification certificate hash has been stored in the core chain block (located by block height + transaction index), and verifying whether the validity period of the cross-chain verification certificate has expired (if the validity period is set to 30 minutes, the current time must be within 30 minutes after the cross-chain verification certificate was generated; if the difference between the current time and the generation time is greater than 30 minutes, it has expired).

[0147] If the cross-chain verification credential hash is not stored or has expired, it is determined that the core chain re-verification mechanism has been triggered. The edge chain returns an error reminder to the user terminal and records the invalid credential access log. The user terminal sends a prompt to the user that the cross-chain verification has expired or is not effective and asks them to re-initiate the verification.

[0148] If all verifications pass, the edge chain generates a temporary permission token based on the permission scope in the zero-knowledge proof file verification result and the current timestamp. The token includes the user terminal device identifier hash, the list of operation permissions (such as allowing writing traceability information), the valid timestamp, and the edge chain signature.

[0149] The temporary permission token is stored in the local cache of the edge chain (with a timed expiration and automatic cleanup mechanism set, such as automatic cleanup after 5 minutes), and the temporary permission token is sent to the user terminal. The user terminal can use the temporary permission token to perform subsequent traceability information writing and other operations.

[0150] The ways to write traceability information to the edge chain include:

[0151] The user terminal initiates a traceability information writing request to the edge chain based on cross-chain verification credentials and temporary permission tokens. The request contains the traceability information to be written (the traceability information varies depending on the business scenario, such as traceability information data after JSON serialization, such as product generation batch, logistics node, operation type, etc.).

[0152] Simultaneously, real-time biometric data of users is collected through user terminals, real-time biometric hashes are generated through local hash algorithms, and user terminal device identifiers are extracted and appended to the write request. The write information, real-time biometric hashes, and user terminal device identifiers are integrated to generate a request packet.

[0153] After receiving the request packet, 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 should not exceed the expected value, for example, 5 minutes; that is, the timestamp must be within ±5 minutes of the current time. If it exceeds this value, the token expires and is deemed invalid), the user terminal device identifier hash (it is valid if it matches the user terminal device identifier submitted by the user terminal; if they do not match, the device identifier does not match and is deemed invalid), and the operation permission list (it must include the permission to write traceability information; if there is no permission to write traceability information, the permission is insufficient and is deemed invalid). At the same time, it queries the storage status of the cross-chain verification credential ID through the core link interface (the storage status must not be revoked and must be within the validity period; otherwise, it is deemed invalid).

[0154] If the verification fails, the reason is identified. If it is due to an expired token, mismatched device identifier, or insufficient permissions, the edge chain returns the corresponding error message to the user terminal, and the user terminal prompts the user to obtain a temporary permission token again. If the credential has been revoked or is not within its validity period, the edge chain returns the corresponding error message to the user terminal, and the user terminal triggers the core chain re-verification mechanism.

[0155] After the temporary permission token and cross-chain verification credential pass the validity check, the consistency between the biometric hash and the on-chain identity template, as well as the compliance of the traceability information, are then verified, including:

[0156] The edge chain calls the on-chain identity template library to obtain the biometric hash (from the on-chain identity template) that is bound to the user's unique identity identifier, and uses it as the biometric base hash;

[0157] The real-time biometric hash submitted by the user terminal is compared with the biometric baseline hash. That is, the two hash values ​​are directly matched. If the hash values ​​do not match, it is determined that the user and the authenticated identity are inconsistent. The edge chain returns an error reminder to the user terminal, records the abnormal operation log, and the user terminal sends a prompt to the user that the biometric verification failed and write operation is prohibited.

[0158] Once the biometric verification is successful, the edge chain performs compliance verification on the traceability information, which involves format validation, including: checking the completeness of fields (such as whether the required fields "product ID" and "operation time" are missing) and the legality of data types (such as whether the timestamp format conforms to the standard time format "YYYY-MM-DD HH:MM:SS"). At the same time, it verifies the compliance of the information based on a preset business rule library (set according to actual needs based on business scenarios, such as setting business rules such as "food traceability must include quarantine certificate number").

[0159] If the format is incorrect or non-compliant, the verification will fail and an error message will be returned to the user terminal. The user terminal will then send a corresponding prompt to the user (e.g., the traceability information is in the wrong format or a required field is missing. Please correct it and try again).

[0160] After all verifications pass, the edge chain generates a write permission instruction, which associates the traceability information with the user's real-time biometric hash, user terminal device identifier, and temporary permission token hash to form a structured traceability data unit, which is then written into the edge chain block.

[0161] The methods for generating traceability information chains and cross-chain traceability validity proofs include:

[0162] Once the traceability information is written to the edge chain, the user terminal initiates a cross-chain traceability request to the core chain, and the cross-chain traceability request includes a cross-chain verification credential.

[0163] After the core chain receives the cross-chain traceability request as the coordinating 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 (to confirm whether it has expired or been revoked; if expired or revoked, it is deemed invalid), and verifying whether the user permissions in the cross-chain verification certificate include cross-chain traceability query permissions (if not, it is deemed insufficient permissions).

[0164] If the cross-chain verification credentials are invalid or the permissions are insufficient, the core chain returns an error message to the user terminal, and the user terminal sends an error message to the user (such as a message indicating that there are no cross-chain traceability permissions, please complete the identity verification again).

[0165] After the cross-chain verification credential is passed, the core chain matches the pre-set 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 (such as the unique identifier of the product) in the request, and determines the list of relevant edge chains that need to be queried.

[0166] The core chain sends query requests to the relevant edge chains, including: cross-chain verification credential hash (used for edge chain verification), unique identifier of the traceability object (such as a product unique identifier, which needs to be encrypted by hashing to prevent leakage of traceability object information; therefore, the unique identifier of the traceability object can be understood as the traceability object ID hash, such as a product ID hash), and query time range (default is the full period, and the specific query time range can be adjusted according to the actual situation). The query request is transmitted through the cross-chain message protocol and is accompanied by a core chain digital signature to ensure authenticity.

[0167] After receiving a query request, each edge link retrieves the traceability information fragments stored locally, including the user's real-time biometric hash, the timestamp of the operation, the operation content (such as "production completed" or "outbound scan"), and the edge chain block hash (used to locate the original data).

[0168] The edge chain performs SHA-256 hashing on the local traceability information fragment, encrypts the hash value and the original traceability information fragment together, and returns it to the core chain (the encryption key is a preset key shared by the core chain and the edge chain).

[0169] After the core link receives local traceability information fragments from all edge chains, it aggregates these fragments using a segmented zero-knowledge proof mechanism and verifies the consistency of identifiers and temporal logic. Specifically:

[0170] Local traceability information fragments are grouped according to the hash value of the unique identifier of the traceability object, and all local traceability information fragments are associated with the same object (local traceability information fragments with inconsistent hash values ​​are directly removed).

[0171] For each local traceability information segment, 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 segment (e.g., "production" must be earlier than "warehousing", and "warehousing" must be earlier than "transportation").

[0172] By aggregating the segmented logic through zero-knowledge proofs, a global zero-knowledge proof is generated (the private input is the details of each segment, and the public input is the object identifier hash and the time sequence relationship), ensuring that the aggregation process does not leak sensitive information and is logically consistent.

[0173] If there is a contradiction in the timing logic or a mismatch in the unique identifier of the traceable object, the core chain returns an error reminder to the user terminal, and the user terminal sends an error message to the user (such as a contradiction in the traceable information fragments, making it impossible to generate a complete chain).

[0174] After the identity consistency and temporal logic verification are passed, the core chain concatenates the local traceability information fragments in timestamp order, associates the real-time biometric hashes of users in each local traceability information fragment with the on-chain identity template library, generates a traceability information chain with identity binding concatenated in time, and simultaneously generates a cross-chain traceability validity proof that records the aggregation process and verification results, including the hashes of local traceability information fragments of each edge chain, global zero-knowledge proof digests, core chain digital signatures and generation timestamps; then, after the cross-chain traceability validity proof is stored on the chain, it is sent back to the user terminal.

[0175] The methods for recording key usage and identifying risks, triggering key restriction mechanisms, dynamically updating on-chain identity template permissions, and reverse-optimizing key-related parameters include:

[0176] By integrating data from the traceability information chain, cross-chain traceability validity proof, and key share sets through smart contracts on the core chain, the system collects and records key usage trajectories in real time. Specifically, this includes basic information and associated verification data.

[0177] The basic information includes the user terminal device identifier hash (i.e., MAC address hash), timestamp, chain identifier involved (core chain / edge chain ID), and operation type (authentication / source tracing / cross-chain query, etc.) for each operation.

[0178] Related verification data: the matching results of cross-chain verification credential ID, temporary permission token hash, user biometric hash and on-chain identity template;

[0179] All data is indexed using a unique user identifier and timestamp structure, which serves as the key for tracking. The data is stored in a chain-like distributed ledger on the core chain (each track node is associated with the hash of the previous node to ensure immutability), and a unique ID (user identity hash + random number) is generated for each track record for traceability.

[0180] Historical baseline data is acquired and compared with key usage patterns to identify risky behaviors. Specifically, this is achieved through real-time analysis of the pattern data using machine learning models (such as the Isolation Forest algorithm) deployed on core chain nodes.

[0181] The input data includes real-time trajectory information (including device, time, and operation frequency) and historical baseline data (including a list of commonly used devices, average daily number of operations, and typical time periods).

[0182] The rule engine presets exception detection rules, specifically:

[0183] Spatial anomaly: The matching degree between the user terminal device identifier and historically frequently used devices does not meet expectations (e.g., <30%, judged as operation of unfamiliar devices in a different location).

[0184] Time anomaly: The number of cross-chain operations exceeds expectations within a certain period of time (e.g., 1 hour) (e.g., more than 5 times the historical average, which is judged as high-frequency suspicious operation).

[0185] Permission error: The operation type does not match the on-chain identity template permission (e.g., if a write request is initiated without write permission, it is judged as permission out of bounds).

[0186] The preset anomaly judgment rules are used as the scoring basis and are synchronously input into the machine learning model. The machine learning model outputs a risk value of 0-100 (≥70 points triggers the response mechanism) and generates an anomaly behavior log (including the judgment basis).

[0187] It should be noted that there are many publicly available and mature models that can be used to obtain this risk score. This embodiment uses the Isolation Forest algorithm, which does not require training, as the model by default. The specific deployment and training can be carried out according to the actual situation, which will not be elaborated here.

[0188] Risky behaviors are assessed and classified into risk levels. Based on the risk level, a key restriction mechanism is triggered to execute corresponding temporary restrictions or key freezing operations. Specifically, the risk levels are divided into three levels:

[0189] Low risk (e.g., ≤69 points): Only generate warning logs and push notifications to user terminals (e.g., "Uncommon device operation detected, it is recommended to verify identity"), without affecting key usage;

[0190] Medium risk (e.g., 70-89 points): Temporary restrictions are triggered, prohibiting sensitive operations such as cross-chain writing (query permissions are retained). The user terminal needs to re-collect biometric data and verify it by matching the feature root value. The restriction will be automatically lifted after the verification is successful.

[0191] 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 this key return a "permission frozen" error to the user terminal. Recovery requires collaborative verification by at least 3 distributed nodes (including the user terminal, the authoritative institution node, and the core chain node). The distributed nodes resubmit the key share, and after verifying consistency through the VSS protocol, the contract is unfrozen.

[0192] All verification data obtained during the traceability process through the core chain (i.e., all verification information that appears in the previous process of obtaining traceability information, such as the consistency between real-time biometric hash and on-chain identity template and the compliance verification of traceability information, the validity verification of cross-chain verification credentials, and the user permission verification in cross-chain verification credentials, etc.) are statistically compiled into traceability audit results.

[0193] Based on the results of source tracing audits and risk behavior assessments, the permission attributes of on-chain identity templates are dynamically adjusted. Specifically:

[0194] If a user fails verification multiple times (e.g., 3 times) but does not reach a high risk level, the user's permission scope will be narrowed (e.g., the "cross-chain write" permission will be removed).

[0195] If a user's operations are compliant over a long period (e.g., no abnormalities for 6 months), their permissions can be expanded (e.g., adding "batch query" permission).

[0196] Write permission update records to the on-chain identity template library and notify user terminals synchronously to ensure that permission changes are traceable.

[0197] Based on risk behavior data, the parameters for key share splitting and the parameters for generating identity private keys are optimized in reverse.

[0198] Specifically, the core chain's smart contracts periodically (e.g., quarterly) collect risk event data (such as the number of freezes and the distribution of anomaly types) triggered by risky behavior in the key restriction mechanism, and then use this data to optimize the key system parameters in reverse:

[0199] If the percentage of anomalies in 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, requiring more node verification to recover the key).

[0200] If the consistency check fails more than three times when the MPC generates the identity private key, increase the number of iterations of the secure multi-party computation (e.g., from 5 rounds to 8 rounds to improve the stability of private key generation).

[0201] The optimized parameters need to be signed and confirmed by an authoritative node before they can take effect, and the updated records must be uploaded to the blockchain for evidence storage.

[0202] 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

[0203] Please see Figure 3 As shown, parts not described in detail in this embodiment are described in Embodiment 1. A blockchain-based digital identity authentication and traceability system is provided, including:

[0204] Key share generation and storage module: acquires user biometric data, performs irreversible conversion through user terminal to generate feature root values ​​and splits key shares, after collaborative verification by distributed nodes, generates key share set through blockchain storage;

[0205] Multi-chain identity system construction unit: Based on the key share set, each distributed node generates the corresponding blockchain identity private key and on-chain identity template containing biometric hash, and associates the on-chain identity template with the chain identifier to form a multi-chain identity key pool and on-chain identity template library;

[0206] Cross-chain identity verification unit: Based on the multi-chain identity key pool and on-chain identity template library, the core chain and edge chain are divided. Zero-knowledge proof is generated through the user terminal. After verification by the core chain, a cross-chain certificate is generated and the encrypted result is sent to the edge chain to generate a temporary permission token.

[0207] Traceability Information Management Module: Based on cross-chain verification credentials and temporary permission tokens, traceability information is written to the edge chain and attached with the user's real-time biometric hash and user terminal device identifier. Cross-chain traceability aggregates information from multiple chains to generate a traceability information chain and a cross-chain traceability validity proof.

[0208] Risk control 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 on-chain identity template permissions, and reverse optimizes key-related parameters to form a closed-loop iterative identity and traceability management link. Example 3

[0209] 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, it implements the operation mode of the blockchain-based digital identity authentication and traceability system described above.

[0210] Since the electronic device described in this embodiment is the one used to implement the blockchain-based digital identity authentication and traceability method in this application embodiment, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the blockchain-based digital identity authentication and traceability method described in this application embodiment. Therefore, how the electronic device implements the method in this application embodiment will not be described in detail here. Any electronic device used by those skilled in the art to implement the blockchain-based digital identity authentication and traceability method in this application embodiment falls within the scope of protection of this application.

[0211] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0212] The above description is merely a preferred embodiment of the present invention, and the scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for users of ordinary technical skills, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A blockchain-based digital identity authentication and traceability method, characterized in that, include: S1: Obtain user biometric data, perform irreversible transformation through user terminal to generate feature root values ​​and split key shares, after collaborative verification by distributed nodes, generate key share set through blockchain notarization; S2: Based on the key share set, each distributed node generates the corresponding blockchain identity private key and on-chain identity template containing biometric hash, and associates the on-chain identity template with the chain identifier to form a multi-chain identity key pool and on-chain identity template library; S3: Based on a multi-chain identity key pool and on-chain identity template library, the core chain and edge chain are divided. Zero-knowledge proofs are generated through user terminals. After verification by the core chain, cross-chain credentials are generated and encrypted results are sent to the edge chain to generate temporary permission tokens. S4: Based on cross-chain verification credentials and temporary permission tokens, write traceability information to the edge chain and attach the user's real-time biometric hash and user terminal device identifier. Cross-chain traceability aggregates multi-chain information to generate a traceability information chain and cross-chain traceability validity proof. S5: 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 on-chain identity template permissions, and reversely optimizes key-related parameters to form a closed-loop iterative identity and traceability management link.

2. The blockchain-based digital identity authentication and traceability method according to claim 1, characterized in that, The methods for generating eigenvalues ​​and splitting key shares include: The required raw biometric data of users is collected through user terminals, and standardized and noise-reducing processing is completed locally. The processed biometric data is serialized into a byte stream, and an irreversible hash operation is performed on the byte stream to generate a fixed-length hash value as the feature root value. The system pre-defines distributed nodes and splits the feature root value into multiple key shares based on the number of distributed nodes. The user terminal then distributes these key shares to other distributed nodes via 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 ways: After receiving the key share, the distributed node verifies the authenticity and validity of the key share's source 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 redistribution is required. For all distributed nodes whose key shares have been verified, each distributed node uploads its own key share hash value, verification timestamp, and its own node digital signature to the blockchain to form structured data. The root hash is generated based on the structured data, written into the blockchain block for notarization, and then integrated with the notarized 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, characterized in that, The methods for generating the corresponding blockchain identity private key and on-chain identity template containing biometric hashes include: Distributed nodes obtain their own stored key shares and verification logs from the key share set; For each pre-defined blockchain, each distributed node collaboratively generates the corresponding blockchain's identity private key based on a key share set. Meanwhile, based on biometric data, the user terminal extracts the hash digest of the feature root value as the biometric hash, extracts and integrates the user's basic attributes and initial permission range to form template basic data; The template's basic data is encrypted and associated with the identity's private key to form the final on-chain identity template.

5. The blockchain-based digital identity authentication and traceability method according to claim 4, characterized in that, The formation methods of the multi-chain identity key pool and on-chain identity template library include: Call the preset list of chain identifiers, bind the unique chain ID of each blockchain with the corresponding on-chain identity template and perform hash mapping to establish a unique association; The public keys of the corresponding chain identity private keys generated by each distributed node are aggregated according to the chain identifier, and a multi-chain identity key pool is constructed using the chain identifier and the user's unique identity identifier as indexes. User terminals store on-chain identity templates into a distributed storage area to form an on-chain identity template library. Summarize the unique association information, the index information of the multi-chain identity key pool, and the storage address of the on-chain template library to generate the association relationship, and put the root hash of the association relationship on the chain for evidence storage; The consistency verification mechanism is triggered synchronously to verify the association relationship. After the verification is passed, the multi-chain identity key pool and on-chain identity template library are deemed to be effective.

6. The blockchain-based digital identity authentication and traceability method according to claim 5, characterized in that, The methods for generating zero-knowledge proofs include: Based on a multi-chain identity key pool and on-chain identity template library, the user terminal loads the private key of the identity associated with the current business scenario and the on-chain identity template. Based on preset scenario rules, the blockchain network is divided into a core chain and an edge chain according to function; the core chain is used for global verification, and the edge chain is used for business processing. Based on the loaded private key and on-chain identity template, the user terminal generates private and public inputs for zero-knowledge proofs. Then, a proof circuit is constructed based on the logical connection between private and public inputs to generate a zero-knowledge proof document.

7. The blockchain-based digital identity authentication and traceability method according to claim 6, characterized in that, The temporary permission token is generated in the following ways: The user terminal submits the zero-knowledge proof file to the core chain for integrity and validity verification. If the verification fails, the zero-knowledge proof file regeneration mechanism is triggered. If the zero-knowledge proof document passes verification, a cross-chain verification credential is generated and stored on the blockchain. The verification result is then transmitted to the edge chain via 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 scope 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 methods for writing traceability information to the edge chain include: The user terminal initiates a request to write traceability information to the edge chain based on cross-chain verification credentials and temporary permission tokens. At the same time, it collects the user's real-time biometric hash and user terminal device identifier, and attaches them to the request to generate a request packet. After receiving the request packet, the edge link verifies the validity of the temporary permission token and the cross-chain verification certificate, and then verifies the consistency between the real-time biometric hash and the on-chain identity template, as well as the compliance of the traceability information. If the verification passes, the traceability information is allowed to be written; if the verification fails, an error message 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 methods for generating the traceability information chain and cross-chain traceability validity proof include: Once the traceability information is written to 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 coordinating node, it sends a query request with cross-chain verification credentials to the relevant edge chain. Then, it aggregates local traceability information fragments containing real-time biometric hashes and timestamps collected from various edge links, and verifies the consistency of the identifiers and the temporal logic. Once the local traceability information fragment is verified, a traceability information chain with identity binding is generated and linked by time. Simultaneously, a cross-chain traceability validity certificate recording the aggregation process and verification results is generated and sent back to the user terminal. If the verification fails, the verification failure result is recorded and sent to the user's terminal.

10. The blockchain-based digital identity authentication and traceability method according to claim 9, characterized in that, The methods for recording key usage patterns and identifying risks, triggering key restriction mechanisms, dynamically updating on-chain identity template permissions, and reverse-optimizing key-related parameters include: Based on the traceability information chain, cross-chain traceability validity proof, and key share set, key data on key usage is extracted in real time through the core chain, and the key usage trajectory is recorded. Historical baseline data is acquired and compared with key usage patterns to identify risky behaviors; Assess risky behaviors and classify them into risk levels. Trigger the key restriction mechanism based on the risk level and execute corresponding temporary restrictions or key freezing operations. All verification data during the traceability process is obtained through the core chain and compiled into traceability audit results. The permission attributes of the on-chain identity template are dynamically adjusted based on the source audit results, and the key share splitting parameters and identity private key generation parameters are optimized in reverse based on risk behavior data.

Images