Blockchain-based cross-domain device anonymous identity auditing and tracking method and electronic device

Abstract

The application provides a cross-domain device anonymous identity auditing and tracking method based on a blockchain and an electronic device. The method comprises the following steps: sending a certificate issuing request to an access domain manager, receiving a blind signature returned by the access domain manager, and processing the blind signature to obtain an anonymous certificate; generating an access request based on a current access event, an access domain identifier corresponding to the access event, the anonymous certificate, and a revocation state corresponding to the access domain identifier obtained from the blockchain, and sending the access request to a verifier; binding an event access threshold to the access event and the access domain identifier through an event polynomial commitment; sending the access request to the verifier to enable the verifier to count the number of valid accesses under the same access event; and enabling the verifier to generate tracking trigger evidence and submit the tracking trigger evidence to the blockchain when detecting that the number of valid accesses exceeds the event access threshold. The application can solve the problems of difficulty in accurately detecting over-limit access in an anonymous state and difficulty in balancing anonymous protection and illegal identity tracking.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain-based method and electronic device for cross-domain anonymous identity auditing and tracking. Background Technology

[0002] With the development of the Internet of Things (IoT), the Industrial Internet, and cross-domain data flow technologies, a large number of smart devices need to authenticate, access resources, and interact with data between different management domains. Due to the differences in identity management mechanisms, access policies, and trust systems adopted by each access domain, devices typically need to submit identity identifiers, authentication credentials, or attribute information to the target access domain to prove their access qualifications.

[0003] Existing cross-domain authentication methods mostly rely on fixed identities, public key certificates, or centralized identity services. Access domains and verification authorities may use these to identify users' real identities and link their behavior across domains, leading to risks of identity information leakage and cross-domain behavioral association. While anonymous authentication can protect privacy, completely unlinkable anonymous access makes it difficult for the verifier to determine whether multiple anonymous requests originate from the same entity. This allows malicious users to bypass access policies by repeatedly submitting anonymous requests, causing resource abuse and denial-of-service attacks. Furthermore, publicly disclosing fixed identities or long-term identifiers to count accesses undermines anonymity. Existing traceable anonymous authentication schemes typically grant administrators the ability to directly open anonymous identities, but tracking conditions often rely on the administrator's subjective judgment or a single entity simultaneously holding access verification and identity recognition rights, easily leading to abuse of tracking permissions. In addition, some threshold-based tracking schemes trigger tracking solely based on the number of access records, lacking verification of the validity of access records and event consistency. Existing revocation methods typically use certificate revocation lists or lists of legitimate members, increasing storage, communication, and query overhead and exposing the list of legitimate members; reusing the same revocation identifier across different access domains creates cross-domain association tags, reducing unlinkability. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a blockchain-based method and electronic device for cross-domain anonymous identity auditing and tracking, in order to eliminate or improve one or more defects existing in the prior art.

[0005] One aspect of the present invention provides a blockchain-based method for auditing and tracking the anonymous identity of cross-domain devices, the method comprising: Send a credential issuance request to the access domain administrator, receive a blind signature generated and returned by the access domain administrator based on the credential issuance request, and process the blind signature to obtain the anonymous credential corresponding to the credential issuance request. An access request is generated and sent to the validator based on the current access event, the access domain identifier corresponding to the access event, the anonymous credential, and the revocation status corresponding to the access domain identifier obtained from the blockchain; wherein, the access request includes an event identifier, access coordinates, an event polynomial commitment and a non-revocation proof, and the event polynomial commitment binds a preset event access threshold to the access event and the access domain identifier; The access request is sent to the verifier, so that the verifier verifies the access request based on the revocation status, counts the number of valid accesses under the same access event according to the event identifier and the access coordinates, and generates tracking trigger evidence and submits it to the blockchain when the verifier detects that the number of valid accesses exceeds the event access threshold.

[0006] In some embodiments of the present invention, the access domain administrator is configured to perform the following: Based on the aforementioned trace trigger evidence, collect multiple valid access records under the same access event; By using the tracking private key to decrypt the encrypted access shares in each valid access record, the hidden access share can be obtained; Based on the access coordinates corresponding to each valid access record and the hidden access share, the constant term of the event polynomial is recovered by exponential field interpolation to obtain the user equipment's identity public key; Submit the identity public key to the blockchain.

[0007] In some embodiments of the present invention, the access domain administrator is also configured to perform the following: When revokes a user device, the domain-specific revocation index of the user device to be revoked is added to the revocation set; Update the undo accumulator state; wherein the undo accumulator state is dynamically updated based on the undo set; If the user equipment has not been revoked, the updated revocation status is used to generate a non-member witness; wherein, the non-member witness is used to generate the non-revocation proof in subsequent access requests; The access domain identifier, the updated revocation accumulator status, and the revocation status of the revocation set are uploaded to the blockchain.

[0008] In some embodiments of the present invention, before sending the credential issuance request to the access domain administrator, the method further includes: A user identity private key and a user identity public key are generated based on public system parameters obtained from the blockchain; a first knowledge proof is generated based on the identity private key and sent to the registration domain administrator so that the registration domain administrator can verify the first knowledge proof and write the identity public key into the blockchain; The system receives the domain revocation indexes corresponding to each access domain assigned by the access domain administrator; wherein the domain revocation indexes are encrypted and transmitted by the access domain administrator using the identity public key. A credential message vector is constructed based on the revocation index within each of the domains and the user's private key. The credential message vector is blinded to generate a blinded commitment and a second knowledge proof to obtain a credential issuance request; the credential issuance request includes the user's public key, access domain identifier, blinded commitment, and second knowledge proof.

[0009] In some embodiments of the present invention, the step of generating an access request based on the current access event, the access domain identifier corresponding to the access event, the anonymous credential, and the revocation status corresponding to the access domain obtained from the blockchain, and sending it to the verifier, includes: For each access event, an event identifier and access coordinates are generated, and an event polynomial with the identity private key as a constant term is constructed, and a commitment to the event polynomial is generated. Obtain the revocation status corresponding to the access domain identifier from the blockchain. If it has not been revoked, generate a non-member witness and a revocation index commitment based on the revocation status, generate an unrevocable proof based on the non-member witness and the revocation index commitment, and generate a randomized certificate based on the anonymous certificate. An access proof is generated based on the event polynomial commitment, the access coordinates, the randomized credential, the revocation index commitment, and the non-revocation proof. An access request is generated based on a combination of the event identifier, the access coordinates, the event polynomial commitment, the randomized credential, the access proof, and the non-revocable proof.

[0010] In some embodiments of the present invention, the verifier is used to perform the following: The validity of the access request is verified based on the revocation status obtained from the blockchain; If the event identifier, access coordinates, or revocation status check in the access request fails, access is denied; if the verification passes, the randomized credential and access proof in the access request are verified, and if any verification fails, access is denied. The event bucket is located based on the event identifier. It is checked whether the access request meets the preset access conditions. If it does, the access coordinates are added to the event bucket and the number of valid accesses under the same access event is counted.

[0011] In some embodiments of the present invention, the access conditions include: The event identifier in the access request is consistent with the event identifier in the event bucket; The event polynomial commitment in the access request is consistent with the event polynomial commitment in the event bucket; The access coordinates were not recorded in the event bucket.

[0012] In some embodiments of the present invention, the verifier is also used to perform the following: If the number of valid accesses does not exceed the event access threshold, the access is accepted and an access summary corresponding to the access request is generated; The access summary is uploaded to the blockchain.

[0013] A second aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the blockchain-based cross-domain device anonymous identity auditing and tracking method described above.

[0014] A third aspect of this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the described blockchain-based cross-domain device anonymous identity auditing and tracking method.

[0015] The fourth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the blockchain-based cross-domain device anonymous identity auditing and tracking method.

[0016] This application provides a blockchain-based method for auditing and tracking the anonymous identity of cross-domain devices. The method includes: sending a credential issuance request to an access domain administrator; receiving a blind signature generated and returned by the access domain administrator based on the credential issuance request; processing the blind signature to obtain an anonymous credential corresponding to the credential issuance request; generating an access request based on a current access event, an access domain identifier corresponding to the access event, the anonymous credential, and a revocation status corresponding to the access domain identifier obtained from the blockchain, and sending it to a verifier; wherein the access request includes an event identifier, access coordinates, an event multinomial commitment, and a non-revocation proof, the event multinomial commitment binding a preset event access threshold to the access event and the access domain identifier; sending the access request to a verifier, so that the verifier verifies the access request based on the revocation status, counts the number of valid accesses under the same access event according to the event identifier and the access coordinates; and causing the verifier to generate tracking trigger evidence and submit it to the blockchain when it detects that the number of valid accesses exceeds the event access threshold. By determining whether the number of valid accesses by the same user device in the same access event exceeds a preset threshold using verifiable technical conditions, a cross-domain device identity auditing and tracking mechanism is formed. This mechanism features anonymous aggregation within the event, unrecoverable identity within the threshold, and identity tracking after exceeding the limit. Reasonable access limit not only maintains the fair allocation of limited resources and reduces the security risks caused by malicious repeated accesses, but also provides objective evidence for anomaly detection, accountability auditing, and conditional tracking. This establishes a verifiable technical boundary between privacy protection and access accountability. While ensuring user device identity privacy and cross-domain non-linkability, it achieves accountability and revocation management for cross-domain device access. Furthermore, by using a dynamic accumulator that only represents the set of revoked devices and not disclosing the revocation index to verifiers, the legitimate accesses of anonymous users are not directly associated with the disclosure of the revocation index, thus ensuring user revocation privacy.

[0017] Additional advantages, objectives, and features of this application will be set forth in part in the description which follows, and will in part become apparent to those skilled in the art upon review of the following description, or may be learned by practice of the application. The objectives and other advantages of this application can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0018] Those skilled in the art will understand that the purposes and advantages that can be achieved with this application are not limited to those specifically described above, and that the above and other purposes that this application can achieve will be more clearly understood from the following detailed description. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. The components in the drawings are not drawn to scale but are merely for illustrating the principles of this application. For ease of illustration and description of certain parts of this application, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to this application. In the drawings: Figure 1 This is a flowchart illustrating a blockchain-based cross-domain device anonymous identity auditing and tracking method according to one embodiment of this application.

[0020] Figure 2 This is a flowchart illustrating a blockchain-based cross-domain device anonymous identity auditing and tracking method in an application example of this application.

[0021] Figure 3 This is a timing diagram illustrating a blockchain-based cross-domain device anonymous identity auditing and tracking method in an application example of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit it.

[0023] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the structures and / or processing steps closely related to the solution according to this application are shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0024] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0025] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0026] In the following description, embodiments of the present application will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0027] With the development of the Internet of Things (IoT), the Industrial Internet, and cross-domain data flow technologies, a large number of smart devices need to authenticate, access resources, and interact with data across different management domains. Due to differences in identity management mechanisms, access policies, and trust systems adopted by each access domain, devices typically need to submit identity identifiers, authentication credentials, or attribute information to the target access domain to prove their access eligibility. However, existing cross-domain authentication methods largely rely on fixed identities, public key certificates, or centralized identity services. Access domains and verification authorities may use these to identify the user's true identity and correlate their behavior across different times and access domains, easily leading to identity information leakage and cross-domain behavioral correlation. Therefore, how to verify device access eligibility while avoiding exposing its true identity and complete attributes to the access domain and verification authority has become a crucial issue in cross-domain data access security research.

[0028] In cross-domain data access, IoT services, and distributed resource sharing scenarios, anonymous authentication can hide the true identity of users or devices, reducing the risks of identity leakage, behavioral correlation, and cross-domain tracking. However, completely unlinkable anonymous access can also weaken the system's ability to constrain access behavior. Verifiers may find it difficult to determine whether multiple anonymous requests originate from the same entity, and malicious users could bypass access policies by repeatedly submitting anonymous requests, leading to resource abuse, API breaches, excessive data acquisition, or even denial-of-service attacks. On the other hand, publicly disclosing fixed identities or long-term identifiers to count accesses undermines anonymity, allowing the activity patterns of legitimate users to be continuously correlated. Therefore, how to reliably count the number of times a single user accesses a specific domain, access event, or time period without exposing their true identity is a key issue in anonymous access control.

[0029] Existing traceable anonymity authentication schemes typically grant group administrators, verifiers, or tracking agencies the ability to directly unlock anonymous identities, allowing for identity restoration in the event of disputes or violations. While this approach offers some accountability, tracking conditions often rely on the administrator's subjective judgment, or a single entity may simultaneously hold access verification and identity verification rights, potentially leading to abuse of tracking permissions and exposing legitimate users to the risk of being identified even without any violations. Furthermore, some threshold-based tracking schemes trigger identity restoration solely based on the number of access records, lacking verification of the validity of access records, event consistency, and the uniqueness of access points, making it difficult to prove that multiple records triggering tracking indeed belong to the same user and the same access event. Therefore, a mechanism is needed that is triggered by objective exceedance conditions and separates access detection rights from identity tracking rights, enabling verifiers to detect unauthorized behavior without directly knowing the user's identity.

[0030] Furthermore, cross-domain devices are characterized by their large number, frequent state changes, and dynamic addition from multiple domains. User credentials or access rights may need to be revoked promptly due to device failure, unauthorized operations, or key leaks. Existing revocation methods typically employ certificate revocation lists, legitimate member lists, or online state query mechanisms, which not only increase storage, communication, and query overhead but may also expose the membership relationships of legitimate users. If different access domains reuse the same revocation identifier, it can also create stable cross-domain association tags, reducing the unlinkability of user behavior. Meanwhile, centralized revocation services also suffer from issues such as state asynchrony, single points of failure, and tampering with revocation records. While blockchain can provide immutable state storage and multi-party sharing capabilities, combining on-chain revocation states with anonymous credentials, non-revocation proofs, and cross-domain independent identifiers remains a key challenge for achieving dynamic, reliable, and privacy-preserving revocation management.

[0031] Therefore, to address the challenges of accurately detecting unauthorized access under anonymous conditions and the difficulty in balancing anonymity protection with accountability for violations, this application provides a blockchain-based method for auditing and tracking anonymous identities of cross-domain devices, an electronic device, a computer-readable storage medium, and a computer program product. These methods ensure user device privacy and cross-domain unlinkability while enabling accountability and revocation management for cross-domain device access.

[0032] The following examples will provide a detailed description.

[0033] Based on this, embodiments of this application provide a blockchain-based method for cross-domain device anonymous identity auditing and tracking, which can be executed by a user device. See [link to relevant documentation]. Figure 1 The method specifically includes the following: Step 100: Send a credential issuance request to the access domain administrator, receive the blind signature generated and returned by the access domain administrator based on the credential issuance request, and process the blind signature to obtain the anonymous credential corresponding to the credential issuance request.

[0034] Specifically, this refers to accessing the domain administrator. Send credential issuance request ,in This represents the user's public key. Indicates the access domain identifier. Indicating a commitment to blinding, This means that if the second knowledge proof passes the on-chain identity check, the domain registration check, and the zero-knowledge proof verification, then... Generate blind signature elements respectively and blind signature elements The system then returns the information to the user equipment. Upon receiving the two blind signatures, the user equipment performs deblinding to obtain the access domain. Anonymous access credentials .

[0035] Step 200: Generate an access request based on the current access event, the access domain identifier corresponding to the access event, the anonymous credential, and the revocation status corresponding to the access domain identifier obtained from the blockchain, and send it to the validator; wherein, the access request includes an event identifier, access coordinates, an event polynomial commitment, and a non-revocable proof, and the event polynomial commitment binds a preset event access threshold to the access event and the access domain identifier.

[0036] It is understandable that the user equipment generates an access request based on the access event, access domain identifier, anonymous credentials, revocation accumulator state, and revocation set. The formal definition of the access request generation algorithm is as follows: in, Indicates an access event. Indicates the domain identifier to which the event belongs. Indicates the access domain The currently publicly available undo accumulator status. Indicates the access domain The currently publicly available set of revocations, This indicates an access request generated by the user device.

[0037] Step 300: Send the access request to the verifier so that the verifier verifies the access request based on the revocation status, counts the number of valid accesses under the same access event according to the event identifier and the access coordinates, and generates tracking trigger evidence and submits it to the blockchain when the verifier detects that the number of valid accesses exceeds the event access threshold.

[0038] It should be noted that the verifier executes the access request verification algorithm to verify the anonymous credentials, event multinomial commitment, irrevocable proof, and access coordinates in the user device access request, and maintains access records under the same event. The formal definition of the access verification algorithm is as follows: in, Represents the global public key. This indicates the verification result. This indicates that access is denied. Indicates that access has been granted. This indicates that identity tracking has been triggered. This represents an on-chain summary of the evidence being tracked. This indicates the tracking trigger evidence generated when access exceeds the limit. The verifier counts the number of valid accesses under the same access event. When the number of valid accesses exceeds the access threshold for the event, the verifier outputs... Generate tracking trigger evidence And track the trigger summary, and submit the track trigger summary to the blockchain.

[0039] As described above, the blockchain-based cross-domain device anonymous identity auditing and tracking method provided in this application establishes a cross-domain device identity auditing and tracking mechanism based on the verifiable technical condition of whether the number of valid accesses by the same user device in the same access event exceeds a preset threshold. This mechanism features anonymous aggregation within the event, unrecoverable identity within the threshold, and identity tracking after exceeding the threshold. Reasonable access limit not only maintains the fair allocation of limited resources and reduces the security risks caused by malicious repeated accesses, but also provides objective evidence for anomaly detection, accountability auditing, and conditional tracking. This establishes a verifiable technical boundary between privacy protection and access accountability, ensuring user device identity privacy and cross-domain unlinkability while achieving traceability and revocation management of cross-domain device access. Furthermore, by employing a dynamic accumulator that only represents the set of revoked devices and not disclosing the revocation index to the verifier, the legitimate access of anonymous users is not directly associated with the disclosure of the revocation index, thus guaranteeing user revocation privacy.

[0040] To further ensure user device identity privacy and cross-domain unlinkability while achieving traceability and revocation management of cross-domain device access, in a blockchain-based method for anonymous identity auditing and tracking of cross-domain devices provided in this application embodiment, the access domain administrator is used to perform the following: Based on the aforementioned trace trigger evidence, collect multiple valid access records under the same access event; By using the tracking private key to decrypt the encrypted access shares in each valid access record, the hidden access share can be obtained; Based on the access coordinates corresponding to each valid access record and the hidden access share, the constant term of the event polynomial is recovered by exponential field interpolation to obtain the user equipment's identity public key; Submit the identity public key to the blockchain.

[0041] Specifically, when the first occurrence appears in the same event bucket When there are multiple valid access coordinates (i.e., exceeding the event access threshold), the access domain administrator executes a tracking algorithm to recover the user device's public key based on the tracking trigger evidence. The formal definition of the user over-limit tracking algorithm is as follows: in, This represents the trace trigger summary recorded on the chain. This represents the recovered user device identity public key. Access domain administrator. Received tracking trigger evidence Then, firstly based on the records on the chain... Check that the evidence triggering the investigation is complete and has not been tampered with. Then, right Each access request included in the process undergoes a re-execution of the access verification process to confirm that all access requests are valid. For those that meet the tracing criteria... Valid access records, Use tracking private key For ciphertext components and Decrypt and recover each access coordinate. Hidden access share Subsequently, based on Perform Lagrange interpolation on each different access coordinate and its corresponding share to recover the public key corresponding to the constant term of the event polynomial. .at last, The recovered user device identity public key and tracking results will be submitted to the blockchain as the basis for subsequent liability determination and user device revocation.

[0042] To further ensure user device identity privacy and cross-domain unlinkability, while achieving traceability and revocation management of cross-domain device access, in the blockchain-based cross-domain device anonymous identity auditing and tracking method provided in this application embodiment, the access domain administrator is also used to perform the following: When revokes a user device, the domain-specific revocation index of the user device to be revoked is added to the revocation set; Update the undo accumulator state; wherein the undo accumulator state is dynamically updated based on the undo set; If the user equipment has not been revoked, the updated revocation status is used to generate a non-member witness; wherein, the non-member witness is used to generate the non-revocation proof in subsequent access requests; The access domain identifier, the updated revocation accumulator status, and the revocation status of the revocation set are uploaded to the blockchain.

[0043] Specifically, the access domain administrator executes the user device revocation algorithm, updates the domain-specific revocation index of the revoked user device, and synchronizes the new revocation status to the blockchain. The formal definition of the user update revocation algorithm is as follows: in, This indicates the addition and cancellation of a set. This indicates the updated undo accumulator state. When accessing the domain... When it is necessary to revoke a user device, Generate a new undo accumulator state And will add a new undo index. The corresponding user device status is updated to revoked. Subsequently, Access domain identifier Updated undo accumulator And the newly added undo set Uploaded to the blockchain. If the user device has not been revoked, a new non-member witness is generated and used to generate the non-revocable proof in subsequent access requests.

[0044] To further ensure user device identity privacy and cross-domain unlinkability while achieving traceability and revocation management of cross-domain device access, in a blockchain-based method for anonymous identity auditing and tracking of cross-domain devices provided in this application embodiment, before step 100, before sending the credential issuance request to the access domain administrator, the method further includes: A user identity private key and a user identity public key are generated based on public system parameters obtained from the blockchain; a first knowledge proof is generated based on the identity private key and sent to the registration domain administrator so that the registration domain administrator can verify the first knowledge proof and write the identity public key into the blockchain; The system receives the domain revocation indexes corresponding to each access domain assigned by the access domain administrator; wherein the domain revocation indexes are encrypted and transmitted by the access domain administrator using the identity public key. A credential message vector is constructed based on the revocation index within each of the domains and the user's private key. The credential message vector is blinded to generate a blinded commitment and a second knowledge proof to obtain a credential issuance request; the credential issuance request includes the user's public key, access domain identifier, blinded commitment, and second knowledge proof.

[0045] Specifically, the trusted center in the blockchain network generates initialization parameters for the public system, anonymous credentials, event access thresholds, and reversal accumulators. The formal definition of the initialization algorithm is as follows: in, Indicates safety parameters, This indicates the maximum number of anonymous accesses allowed under the same access event. This indicates the maximum number of registered user devices. Represents the global public key. The order is chosen to be a prime number. Type-3 bilinear group ,in and Indicates order as The two source cyclic groups, Indicates order as The target cyclic group, Represents a non-degenerate and efficiently computable bilinear mapping. Defines mutually independent generators. and generator And select a public hash function. , as well as and publicly available group element tuples And further generate and publish a global public key: in, For trapdoor generated Publicly expose the power parameter to support a maximum power of Multinomial commitments for events; To and corresponding Verification parameters are used to verify the relationship with event multinomial commitments via bilinear mapping. For independent trapdoor The generated undo accumulator has its parameters exposed. (Trapdoor) and Once the parameters are generated, they are not disclosed to any protocol entity.

[0046] User devices, their respective registration domain administrators, and access domain administrators execute the user device-level identity registration algorithm to complete real-name verification, on-chain identity registration, and revocation of index allocation within the access domain. The formal definition of the user device-level identity registration algorithm is as follows: in, Indicates the true identity of the user device. This indicates the access domain that the user device is to register. This represents the user device's public key identity. Indicates the access domain The domain-specific revocation index is assigned to the user equipment. The user equipment first generates an identity private key. and identity public key and generate information about Knowledge proof Domain administrator registration Verify the knowledge proof submitted by the user equipment and generate a global identity identifier. ,Will Write the identity registry entry to the blockchain. Then, the user device requests access from the domain administrator. Submit identity public key and corresponding knowledge proof, After successful verification, generate an in-domain revocation index for the user equipment. It is then encrypted and sent to the user device. The user device decrypts and obtains... Local secret storage afterwards The user equipment (UE) and the access domain administrator execute the UE's blinded credential issuance algorithm to obtain anonymous credentials within the access domain without directly exposing the identity private key or revoking the index. The formal definition of the UE's blinded credential issuance algorithm is as follows: .

[0047] in, This represents the user device's public key identity. Indicates the access domain Revoke the intra-domain index allocated to the user equipment. This indicates the access domain that the user device is to register. Represents a set of user device attributes. Indicates the access domain Anonymous credentials issued to the user equipment. The user equipment constructs the credential message vector. , Indicates the domain identifier, Represents m user equipment attributes. Select a blinding factor to generate a blinding commitment. and zero-knowledge proof It then sends a credential issuance request to the access domain administrator.

[0048] To further ensure user device identity privacy and cross-domain unlinkability while achieving traceability and revocation management of cross-domain device access, in a blockchain-based method for cross-domain device anonymous identity auditing and tracking provided in this application embodiment, step 200, which involves generating an access request based on the current access event, the access domain identifier corresponding to the access event, the anonymous credential, and the revocation status corresponding to the access domain obtained from the blockchain, and sending it to the verifier, includes: For each access event, an event identifier and access coordinates are generated, and an event polynomial with the identity private key as a constant term is constructed, and a commitment to the event polynomial is generated. Obtain the revocation status corresponding to the access domain identifier from the blockchain. If it has not been revoked, generate a non-member witness and a revocation index commitment based on the revocation status, generate an unrevocable proof based on the non-member witness and the revocation index commitment, and generate a randomized certificate based on the anonymous certificate. An access proof is generated based on the event polynomial commitment, the access coordinates, the randomized credential, the revocation index commitment, and the non-revocation proof. An access request is generated based on a combination of the event identifier, the access coordinates, the event polynomial commitment, the randomized credential, the access proof, and the non-revocable proof.

[0049] Specifically, the user equipment based on access events Generate event identifiers Incident pseudonyms Access coordinates and event polynomial And further generate event polynomial commitments. Access point share and ciphertext components and .in, Used for commitment event polynomials and Used to encrypt and hide access shares. User equipment also generates blind witnesses. and . Used to prove the access shares and event polynomial commitments hidden in the ciphertext at the access coordinates The opening is consistent at each location. This is used to prove that the constant term of the event polynomial matches the identity secret in the credential. The user device obtains the access domain from the blockchain. Current publicly disclosed revocation status If the user equipment has not been revoked, a non-member witness is generated. Revoke index commitment Randomized vouchers and access certificate and output the above access request information. .

[0050] To further ensure user device identity privacy and cross-domain non-linkability while achieving traceability and revocation management of cross-domain device access, in a blockchain-based method for anonymous identity auditing and tracking of cross-domain devices provided in this application embodiment, in step 300, the verifier performs the following: Step 310: Verify the validity of the access request based on the revocation status obtained from the blockchain.

[0051] Step 320: If the event identifier, access coordinates, or revocation status check in the access request fails, access is denied; if the verification passes, the randomized credential and access proof in the access request are verified. If any verification fails, access is denied.

[0052] Step 330: Locate the event bucket based on the event identifier, check whether the access request meets the preset access conditions, and if it does, add the access coordinates to the event bucket and count the number of valid accesses under the same access event.

[0053] Specifically, the verifier obtains the access domain from the blockchain. The latest revocation status is checked against the revocation accumulator status in the user equipment declaration. If the event number, access coordinates, or revocation status check fails, the following is output: After the above checks are passed, the verifier checks the validity of the randomized credential and verifies the access certificate. If any proof fails to verify, output the following: Then, the verifier uses the event bucket identifier. Locate the event bucket corresponding to the current access request. If the event bucket does not exist, initialize it; if the event bucket already exists, verify that the current request matches the locked events and polynomial commitments in the event bucket, as well as the access coordinates. Check for duplicates. If any validation fails, output the following: .

[0054] To further ensure user device identity privacy and cross-domain unlinkability while achieving traceability and revocation management of cross-domain device access, in a blockchain-based cross-domain device anonymous identity auditing and tracking method provided in this application embodiment, the access conditions in step 330 include: The event identifier in the access request is consistent with the event identifier in the event bucket; The event polynomial commitment in the access request is consistent with the event polynomial commitment in the event bucket; The access coordinates were not recorded in the event bucket.

[0055] To further ensure user device identity privacy and cross-domain unlinkability while achieving traceability and revocation management of cross-domain device access, in a blockchain-based method for anonymous identity auditing and tracking of cross-domain devices provided in this application embodiment, in step 300, the verifier is further configured to perform the following: If the number of valid accesses does not exceed the event access threshold, the access is accepted and an access summary corresponding to the access request is generated; The access summary is uploaded to the blockchain.

[0056] Specifically, when the number of valid accesses in the event bucket At that time, the verifier outputs Accept the access request.

[0057] To further illustrate the above embodiments, this application also provides a specific application example of a blockchain-based cross-domain device anonymous identity auditing and tracking method.

[0058] The technical problems that need to be solved in the application examples of this application are as follows: 1. Addressing the challenge of accurately detecting excessive access in anonymized environments. While traditional anonymity mechanisms can hide user device identities, they also weaken the verifier's ability to track the number of accesses from the same user device, making it vulnerable to malicious devices bypassing access limits through repeated anonymous requests. Using fixed device identifiers or long-term pseudo-identities for counts allows verifiers to correlate long-term user device behavior across events and access domains, weakening the privacy protection of anonymity authentication. This application example generates stable event pseudonyms for the same user device for the same access event, while generating different event pseudonyms for different access events. This achieves anonymous access counting that is aggregated within the event scope and isolated between different events without knowing the true identity or identity secrets.

[0059] 2. Addressing the challenge of balancing anonymity protection with accountability for unauthorized access. Existing threshold tracking schemes typically set the threshold as the number of credential issuers. Once a specified number of trackers are reached, tracking can be initiated for designated anonymous credentials or display tokens. This type of mechanism primarily addresses the issue of abuse of power by a single tracker, but the identity recovery condition does not depend on whether the user's device has exceeded the allowed number of accesses. This application example transforms the identity recovery condition from "whether the tracker is willing to track" to "whether a valid access share has been formed (k+1)", thus establishing a verifiable technical boundary between anonymity for normal access and accountability for exceeding limits.

[0060] 3. Addressing the issue of dynamic revocation easily exposing legitimate user devices and creating revocation associations. Existing accumulator-based revocation mechanisms often expose all legitimate member identifiers or require users to submit stable revocation identifiers, which can easily lead to the leakage of legitimate user device membership relationships and multiple access associations. This application example uses a dynamic accumulator that only maintains the set of revoked user devices. User devices demonstrate that they have not been revoked through non-member zero-knowledge proofs. At the same time, independent revocation indexes are assigned to different access domains, thereby achieving privacy-preserving dynamic revocation and preventing cross-domain revocation from being linked.

[0061] The blockchain-based cross-domain device anonymous identity auditing and tracking method provided in this application example specifically includes the following: This application example designs a blockchain-based method for anonymous identity auditing and tracking of cross-domain devices, addressing the challenge of coordinating anonymous authentication, access count constraints, conditional identity tracking, and dynamic user revocation during cross-domain device access. This application example ensures that identity recoverability is no longer dependent on the number of participants in threshold-based identity tracking methods, but rather determined by a verifiable technical condition: whether the number of valid accesses by the same user device in the same access event exceeds a preset threshold. Furthermore, unlike the original revocation method based on a dynamic accumulator, this application example's user revocation mechanism uses a dynamic accumulator that only represents the set of revoked devices.

[0062] This application example considers five types of entities, namely, domain administrators. Data user equipment, access domain administrator Verifiers and the blockchain. Data user devices generate identity private keys and identity public keys. After the registration domain administrator completes the real-name verification, the user device's identity public key is written into the blockchain. The access domain administrator assigns a domain revocation index to the user device and sends it to the user device, establishing an identity registration foundation for the subsequent steps where the real identity is traceable and the access process is anonymous.

[0063] During the credential issuance phase, the data user equipment applies for an anonymous credential. After the access domain administrator verifies the on-chain registration status, the domain registration status, and the blinding proof, it issues a blind signature. After the user equipment is deblinded, it obtains an anonymous access credential. This enables the access domain administrator to confirm that the user equipment meets the access policy but cannot directly know its identity secret or revoke the index.

[0064] During the access phase, the data user equipment generates an event identifier, access coordinates, event multinomial commitment, credential holding proof, and indeterminate proof for each specific access event and submits them to the verifier. The event commitment binds the access limit to a specific access domain and access event, which is the core of this solution. The core of the sub-anonymous traceable access model is that the validator, without knowing the user device's true identity, obtains the latest revocation status from the blockchain and verifies the user device's anonymous credentials, access share consistency, and non-revocation status. If the number of valid accesses for the same event does not exceed a threshold... If the access is accepted, the access digest will be uploaded to the chain. If the first access is detected... The next access generates trace trigger evidence and its summary on the blockchain, thereby achieving the separation of permissions so that "verifiers can detect unauthorized access but cannot directly identify user devices".

[0065] During the tracing phase, the access domain administrator uses the tracing private key to decrypt the same event. A valid encrypted share is used, and the identity public key, which is secretly bound to the user device's identity, is recovered through exponential field interpolation, achieving "anonymity within the threshold and traceability after exceeding the threshold." During the revocation phase, the access domain administrator updates the revocation set and revocation accumulator based on the domain revocation index of the violating or invalid user device, and publishes the latest revocation status to the blockchain; non-revoked user devices update their non-member witnesses accordingly, while revoked user devices are denied access because they cannot generate valid non-revocation proofs, thereby achieving dynamic and cross-domain non-linkable user device revocation management.

[0066] The application examples in this application mainly include the following five categories: registered domain administrator, data user device, access domain administrator, validator, and blockchain, as shown in the flowchart. Figure 2As shown, the process includes: ① access request verification; ② if the number of accesses is less than the threshold, providing cross-domain services; ③ if the number of accesses is greater than or equal to the threshold, triggering an audit trail. Specific details are as follows: Registration Domain Administrator: The registration domain administrator is primarily responsible for the initial identity registration and real-name verification of user devices. When a user device joins the system for the first time, it submits its public key and corresponding zero-knowledge proof to the registration domain administrator, proving that it indeed possesses the corresponding private key. After completing the real identity verification, the registration domain administrator generates or confirms a global identity identifier for the user device and writes the user device's public key and related registration information into the on-chain identity registry. The role of this administrator is to establish a trusted binding relationship between the user device's real identity and its anonymous on-chain identity, but it does not directly participate in each access verification during subsequent accesses, thereby reducing the risk of the user device's real identity being exposed during the access phase.

[0067] Data User Equipment (DUE): A DUE is a cross-domain data access device and the generator of anonymous credentials and access requests. During registration, the DUE generates a private key and a public key for its identity, and obtains domain revocation indexes and anonymous access credentials in different access domains. During access, the DUE generates event pseudonyms, access coordinates, event multinomial commitments, access share ciphertext, and a unified access certificate based on access events, anonymous credentials, revocation accumulator states, and its own secret information, and submits the access request to the verifier. Its goal is to achieve anonymous access within a threshold range, provided that access permissions are satisfied and access has not been revoked.

[0068] Access Domain Administrator: The access domain administrator is responsible for issuing anonymous credentials for user devices within the access domain, revoking user devices, and tracking their identities after exceeding the limits. When a user device enters an access domain, the access domain administrator assigns it a revocation index within the domain and issues anonymous access credentials based on the user device attributes and access domain information. After a user device violates regulations, becomes invalid, or is held accountable, the access domain administrator updates the revocation set and revocation accumulator, and publishes the updated revocation status to the blockchain. When a validator detects the same user device appearing under the same event for the first time... When there are multiple valid access points, after obtaining evidence of the tracking trigger, the access domain administrator uses the tracking private key to recover the user device's identity public key, thereby initiating the subsequent responsibility determination and revocation process.

[0069] Validator: The validator is responsible for verifying and counting anonymous access requests submitted by data user devices. Without knowing the true identity of the user device, the validator checks the validity of the event identifier, access coordinates, and access proof in the access request, and maintains an event bucket based on the event identifier and event pseudonym. If the number of valid accesses within the same event bucket does not exceed the threshold, the validator accepts the access request and generates an on-chain access digest; if the threshold is exceeded, the validator generates a tracing trigger evidence and uploads its digest to the blockchain.

[0070] Blockchain: As a decentralized and trusted infrastructure, blockchain primarily serves the functions of state disclosure, data notarization, and process auditing. Blockchain stores key data such as user device on-chain registration records, access domain revocation accumulator states, revocation set update information, and tracking trigger digests. Through blockchain, all participants can obtain a consistent, verifiable, and tamper-proof system state, preventing verifiers or administrators from using expired revocation states, forging access records, or tampering with tracking evidence. Simultaneously, blockchain does not directly store access content, protecting user device privacy while providing audit credibility.

[0071] A timeline diagram of a blockchain-based cross-domain device anonymity auditing and tracking method is shown below. Figure 3 As shown, the specific steps and procedures are as follows.

[0072] Step 1 Initialization: The initialization algorithm is as follows Let the safety parameter be... The event access threshold is The maximum number of registered user devices is Choose a prime number as the order. Type-3 bilinear group ,in .set up for The generator, let for The generator is then used, along with a hash function. , as well as Then select a random number. , The modulus represents the prime number. finite field, This represents a trusted setup trapdoor in the event multinomial commitment module, which is destroyed after the trusted setup is completed and is unknown to any entity. , publicly based generated Group public power parameter tuple as well as group element tuple Pre-computed mapping group group tuples on , and This is used for pairing verification of subsequent polynomial commitments and their opening relationships. The revocation module uses random numbers. , calculation and corresponding Group validation parameter tuple .in, Once the trusted setup is complete, the information should be destroyed and should not be known to any single participant. Domain access The undo set accumulator is defined as , Indicates the cancellation of a set polynomial In secret parameters The value at that location. The undo set is defined as... , Indicates user equipment In the domain The undo index, where Index for users and , This indicates the maximum number of registered users supported by the system. (If the user device...) If it is not revoked, then there is If the user equipment If it has been revoked, then there is For the domain Cancel set Define the polynomial for the undo set as , Indicates the cancellation of a set polynomial The independent variable of the polynomial is the access domain. The revoked user equipment. The initial revocation set is empty, i.e. , The initial undo set accumulator is When accessing the domain China cancels user equipment At that time, GM reads the user device Intra-domain index revocation Undo set update Undo set polynomial update to The corresponding undo set accumulator is And made public .

[0073] Step 2: User registration: The user registration algorithm is defined as follows: ,in, Indicates user equipment His true identity This indicates the access domain that the user device is to register. Indicates user equipment The identity public key, Indicates the access domain The domain-specific undo indexes assigned to user equipment are independent of each other across different domains for the same user equipment. , usually have .

[0074] User Equipment Selection and calculate User equipment sends signals to the domain it resides in. submit and proof of knowledge . After completing zero-knowledge verification, real-name authentication is performed, and a global identity identifier is calculated. Verify if there is a tuple on the chain. ,like If the tuple already exists, the registration request for the user device will be rejected. If the GM checks the chain and finds no tuple... Then upload the domain registry. Up to the chain.

[0075] Registered access domain in access domain D Validating knowledge proofs If the verification passes, choose and using the user equipment public key right Perform elliptic curve integrated encrypted distribution and establish a domain registry. . Select random number Calculate key components and ,Then Derived key Calculate ciphertext The user equipment received Afterwards, using their own calculate Therefore, the user equipment derives a key. Finally, the user equipment decrypts the domain-wide index to remove it. Undo index within user equipment storage domain During the access request process, non-member witnesses are computed locally based on the publicly available revocation set. Furthermore, Select random number Calculate and publish Used as a tracking public key.

[0076] Step 3: Issuance of Attribute Certificates Select private key Calculate the public key tuple , , , , , , , and Public domain public key ,in, For the signature master private key index, , , and These are respectively related to user identity secrets Intra-domain index cancellation Access domain encoding Passing the exam Attributes The corresponding signature private key index; To and corresponding Public key element, , , and The above message components are respectively in The corresponding public key element for verification, and , , and For the same private key index in The corresponding public group element. This indicates the number of attributes contained in the credential. The user device attribute credential issuance algorithm is defined as follows: ,in, This represents the user device's public key identity. Indicates that the user equipment is in the access domain Intra-domain index cancellation Indicates the access domain identifier. Represents a set of user device attributes. Indicates the access domain Anonymous credentials issued for user equipment.

[0077] The user equipment first calculates the public message code: domain identifier. and attribute encoding Message vector The hidden message is Public information is Domain identifier With attribute encoding This information is entered into the credential issuance relationship as public information to ensure that credentials can only be displayed under the corresponding domain and attribute policy. The user device selects a blinding factor. And calculate blinded commitments ,in, This represents a blinded commitment generated by the user during the credential application stage; group Public generators; This represents the blinding factor randomly selected by the user. , , and These respectively represent the user's identity secret, domain-related secret, access domain code, and the first... The public signature base corresponding to each attribute; This indicates the user's identity as a secret; Indicates user In the access domain Domain-related secret values; Indicates the access domain The encoding; Indicates user number The encoded value of each attribute; This indicates the number of attributes contained in the credential. Additionally, the user equipment generates zero-knowledge proofs: User equipment accesses domain D Send credential issuance request . First, check the blockchain before issuing. Does it already exist? If it does not exist Refusal to issue. Then, Retrieve the domain-level undo index from the local table ,verify If the check fails, the issuance will be rejected. If the above verification passes, Select a random number for the signature. And calculate the signature tuple. and The user equipment received the blind signature. Then, the anonymous credential tuples are calculated to remove blinding. and Obtain anonymous access credentials User equipment can be accessed via equations Verify the validity of the credentials; if verification fails, the user device rejects the credentials.

[0078] Step 4: Access Request Generation: The access request generation algorithm is defined as follows: in, Indicates an access event. Indicates the domain identifier to which the event belongs. Indicates the access domain. Indicates that the user equipment is in the access domain The anonymous credentials obtained below Indicates the access domain The currently publicly available undo accumulator status. Indicates the access domain The currently publicly available set of revocations, This indicates the final generated access request.

[0079] User equipment selects random number Calculate event identifier Group elements and the pseudonym of the event Subsequently, the user equipment calculates the access coordinates. .like Then select again. .

[0080] User equipment for Construct polynomial ,in User equipment selection of hidden factors And calculate the event polynomial commitment. ,in For event polynomials point The value at that location. (When accessing coordinates) At this point, the user equipment calculates the access point share. and User equipment selects encrypted random number. And calculate the ciphertext component: , User equipment generates access point witnesses. and User equipment selects blinded random numbers. and calculate commitments and ,in, Used to prove the ciphertext Hidden access share and Access coordinates The KZG at that location is consistent. Used to prove the constant term of the event polynomial With the identity secret in the certificate Consistent.

[0081] User equipment obtains the current domain from the blockchain. Cancellation status User equipment first checks Is this condition met? If met, the user equipment has been revoked and cannot continue to generate access requests. Otherwise, the user equipment calculates the revocation set polynomial based on the publicly available revocation set. If the user equipment is not revoked, there are Users can calculate witness values. and polynomial Therefore, we have the equation. Established, user equipment calculates witness value Define a non-member witness tuple as Finally, the user equipment selects a random number. And calculate the revocation of index commitment. .

[0082] User equipment selects random number Calculate randomized vouchers: and The public statement regarding the access request is as follows: ,in, This is the system's global master public key. and These represent the access event and its event identifier, respectively. A one-time random number generated for the user. This is the evaluation point of the event polynomial corresponding to the current access request; Anonymous tags for the event, For event-multiple commitments; Share of encrypted events Conditional tracking ciphertext, and The event polynomials are respectively in and The hidden unlocking proof is located at [location]. The randomized PS anonymous credential; Revoke indexes related to the domain The promise For access domain The current undo accumulator; , and They are respectively Group elements Non-revoked witnessing as well as Group elements Vector commitment; Encoding for access domains, For user attribute vectors. Define a unified context. All proofs are bound to the same User equipment generates master federation proof. The mapping group The group elements are calculated as follows: , , , , ,"in and They represent , and The pairing results; express With trusted settings parameters The pairing results; Indicates tracking public key and The inverse of the pairing result is used to process the randomization term in the conditional trace ciphertext; Indicates the value from the evaluation point The constructed polynomial enables the validation group element, used to validate the event polynomial in... Consistency in evaluation at each location.

[0083] The Groth-Sahai commitment parameters are defined as follows. Middle group elements Define Groth-Sahai commitment .right Middle group elements Define Groth-Sahai commitment group elements Group elements Furthermore, the corresponding discrete logarithmic relationship is unknown. The user equipment calculates the undisclosed group elements. and Select random number And generate three Groth-Sahai commitments. , and ,in, Indicates to Groth-Sahai commitment for middle group elements Indicates to Groth-Sahai commitments for elements in the middle group. User equipment is able to generate proofs. , among which group elements Group Element And group tuple .

[0084] To prevent witness splicing attacks between different proofs, the user equipment generates two bridging proofs. and Proof of commitment Commitment with Groth-Sahai Using the same random value .prove Represented as in, This indicates the removal of the zero-knowledge proof from the index bridging. Indicates the current proof context; Indicates user In the access domain Domain-related revocation indexes in the database; Indicates the construction of commitment The random blinding factor used at that time; Represents construction The Groth-Sahai randomization vector used at that time; Indicates the cancellation of the index. Pedersen type commitment; Represents group elements The Groth-Sahai promise; and They represent the public generators in the corresponding source group, This indicates that the Groth-Sahai commitment system is in The public commitment basis in [the document]. This proof is used to demonstrate [the following]. and The hidden element is the same undo index. And its specific value is not disclosed.

[0085] Proof of commitment The hidden group elements are indeed The user equipment first generates a one-time scalar commitment. ,in ,and Unknown. Further proof generation required. : .

[0086] in, Indicates the current proof context; Indicates user In the access domain The secret value related to non-member witnesses; Indicates the construction of commitment The random blinding factor used at that time; Represents construction The Groth-Sahai randomization vector used at that time; Indicates the secret value Pedersen type commitment, in which and For the purpose of public commitment; Represents group elements The Groth-Sahai promise; Indicates the access domain The current undo accumulator, This indicates that the Groth-Sahai commitment system is in The public commitment basis in [the document]. This proof is used to demonstrate [the following]. and The same secret value is used. And without revealing its specific value. Define the bridging access proof. The final access proof is The user equipment ultimately generates the following access request: .

[0087] Step 5: Access Request Verification: The access request verification algorithm is defined as follows: in, Represents the global public key. This indicates an access request submitted by the user device. This indicates the verification result. This represents the on-chain digest of a normal access request. This indicates traceable evidence that triggered the access violation. The verifier received the access request. Then, perform the following verification.

[0088] The validator recalculates the event number based on publicly available data. ,examine Is it true? Then calculate. , .examine and Whether it is valid. The validator obtains the domain from the chain. Current cancellation status, check Is this the latest revocation status? If not, the access request is rejected, and the verifier recalculates. Verifier verification If the verification passes, the verifier calculates the group elements. , , , and According to public attributes Access strategy calculates element value The verifier calculates the origin consistency term. Simultaneously calculate the access coordinate consistency item. and calculate , Verifier verification If verification fails, the access request is rejected. This step ensures that the user equipment holds valid credentials; this proof also ensures that the credentials held by the user equipment match the event pseudonym. Contains the same identity secret ; Revoke index commitment The same revocation index is contained in the certificate. ; The constant term is ; Ciphertext and Access coordinates KZG at the location is consistent; and and Use the same encrypted random number .

[0089] Verifier verification Is the verification valid? If verification fails, the access request is rejected. Then, the verifier verifies... and If any authentication fails, the access request is denied. Proof is provided below: and The same one is used ; The hidden group elements are indeed .

[0090] After completing the access proof verification, the verifier uses the event bucket. Locate the event corresponding to the current access request. If the corresponding event bucket has not yet been created, the verifier initializes the event bucket and records it. and At the same time, initialize the set of used access coordinates and the set of valid access records, i.e. and If the event bucket already exists, the verifier will verify it. and Does the condition simultaneously hold true? If any of the above conditions are not true, it means that the request attempts to mix different events or different event multinomial commitments into the same event bucket, and the verifier rejects the access request. Subsequently, the verifier checks the current access coordinates. Has it already appeared in the used coordinates set of this event bucket? If so, the verifier rejects the request. When the verifier adds the coordinates to the used set and adds the current access request to the valid access record set, the process is updated. At this point, the valid access count in the event bucket is defined as .like This indicates that the current user device has not exceeded the limit for anonymous access attempts under this event. The validator then accesses the service within domain D. The validator calculates the on-chain digest of this access request. and will Submit to the blockchain. If This indicates that the user equipment generated [something] under the same event. Each valid access coordinate is different. The validator no longer provides actual services but instead generates traceable trigger evidence. ,in, This represents a unique identifier for the event generated by the access event and the target access domain; Indicates the current access event; Indicates the user in the event Anonymous tags for events; Indicates user's response to the event Constructed event polynomial commitment; Indicates the first The polynomial evaluation point corresponding to each valid access request; and They represent the first The first and second components of the conditional trace ciphertext generated during the second access; Indicates user The first submission under the current event One valid access request; Indicates collection An index of 1,000 different valid access requests, of which This represents the maximum number of anonymous accesses allowed for the event.

[0091] Subsequently, the validator calculates the trace trigger summary. And upload the summary to the blockchain.

[0092] Step 6 User Exceedance Tracking: The formal definition of user excessance tracking is: in, This represents the trace trigger summary recorded on the chain. This represents the recovered user device identity public key. The specific steps of the algorithm are as follows: receive Afterwards, check Then each of them was re-verified. And check if all access records have the same , , GM check ,in For each valid record, the GM uses the tracking private key. Decryption calculation yields the decrypted value GM calculates the Lagrange coefficients. ,recover . Search on the chain for the satisfied Record the user equipment and output the user equipment public key. Up to the chain.

[0093] Step 7: User Update Revocation: The formal definition of the user update revocation algorithm is as follows: .in, This indicates the addition and cancellation of a set. Indicates the access domain The current undo accumulator value. This represents the new undo accumulator value generated after adding the user's undo index. If a new undo is added to field D... , Recalculate the new accumulator , and upload Set table values .like This indicates that the user equipment has been revoked. If The new cancellation polynomial is The user equipment calculates the new update witness as The new polynomial satisfies User equipment computation update witness If the user equipment is not revoked, then the update witness satisfies the equation. The verifier can verify Established.

[0094] The beneficial effects of this application example lie in its ability to collaboratively achieve anonymous authentication, in-event access counting, over-limit behavior detection, conditional identity recovery, and dynamic revocation in cross-domain device access scenarios. This application example uses anonymous credentials to verify user device access eligibility, enabling the verifier to confirm that the user device meets the access policy without knowing its true identity; it binds user device access behavior to specific access domains, access events, and access thresholds through event commitment, ensuring that legitimate and unrevoked user devices remain anonymous when the number of accesses does not exceed the threshold; and it embeds the user device identity secret into the event polynomial constant term through a conditional tracking mechanism based on exponential domain interpolation, ensuring that the verifier can only complete access verification and over-limit detection, but cannot directly restore the user device identity, only restoring it when the first instance of an event occurs under the same event. After obtaining different valid access coordinates, the domain administrator holding the tracking private key can recover the user device's identity public key based on the valid ciphertext share. This forms a behavior count condition tracking mechanism that is different from the tracking permission threshold, achieving normal anonymity and traceable unauthorized access. At the same time, the application example of this application implements dynamic revocation based on the revocation set accumulator instead of the traditional legitimate user accumulator. It only maintains the set of revoked user devices and verifies that the user device has not been revoked through non-member zero-knowledge proof, avoiding the public disclosure of the legitimate user device set. Moreover, the revocation indexes of each access domain are independent of each other, reducing the risk of cross-domain association.

[0095] Therefore, this application example, while ensuring user device identity privacy and cross-domain non-linkability, achieves traceability and revocation management for cross-domain device access. Compared to existing solutions that only implement anonymous authentication, tracer number thresholds, or attribute multinomial authentication, this application example substantially changes the triggering conditions for identity tracking, the generation method of access requests, the verification and maintenance method of user revocation status, and the identity recovery algorithm, realizing an event-level conditional tracking mechanism where the device's excessive access behavior itself controls identity recoverability.

[0096] This application also provides an electronic device, which may include a processor, a memory, a receiver, and a transmitter. The processor is used to execute the blockchain-based cross-domain device anonymous identity auditing and tracking method mentioned in the above embodiments. The processor and memory can be connected via a bus or other means, taking a bus connection as an example. The receiver can be connected to the processor and memory via wired or wireless means.

[0097] The processor can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0098] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the blockchain-based cross-domain device anonymous identity auditing and tracking method in the embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the blockchain-based cross-domain device anonymous identity auditing and tracking method in the above method embodiments.

[0099] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0100] The one or more modules are stored in the memory, and when executed by the processor, the blockchain-based cross-domain device anonymous identity auditing and tracking method in the embodiment is executed.

[0101] In some embodiments of this application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected via a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0102] As one implementation method, the functions of the receiver and transmitter in this application can be implemented by transceiver circuits or dedicated transceiver chips, and the processor can be implemented by dedicated processing chips, processing circuits or general-purpose chips.

[0103] As another implementation approach, the server provided in this application embodiment can be implemented using a general-purpose computer. That is, the program code implementing the processor, receiver, and transmitter functions is stored in memory, and the general-purpose processor implements the processor, receiver, and transmitter functions by executing the code in memory.

[0104] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned blockchain-based cross-domain device anonymous identity auditing and tracking method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0105] This application also provides a computer program product, specifically including a computer program that, when executed by a processor, implements the steps of the blockchain-based cross-domain device anonymous identity auditing and tracking method mentioned in the foregoing embodiments.

[0106] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave.

[0107] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0108] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0109] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to the embodiments of this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A blockchain-based method for auditing and tracking the anonymous identity of cross-domain devices, characterized in that, The method includes: Send a credential issuance request to the access domain administrator, receive a blind signature generated and returned by the access domain administrator based on the credential issuance request, and process the blind signature to obtain the anonymous credential corresponding to the credential issuance request. An access request is generated and sent to the validator based on the current access event, the access domain identifier corresponding to the access event, the anonymous credential, and the revocation status corresponding to the access domain identifier obtained from the blockchain; wherein, the access request includes an event identifier, access coordinates, an event polynomial commitment and a non-revocation proof, and the event polynomial commitment binds a preset event access threshold to the access event and the access domain identifier; The access request is sent to the verifier, so that the verifier verifies the access request based on the revocation status, counts the number of valid accesses under the same access event according to the event identifier and the access coordinates, and generates tracking trigger evidence and submits it to the blockchain when the verifier detects that the number of valid accesses exceeds the event access threshold.

2. The blockchain-based cross-domain device anonymous identity auditing and tracking method according to claim 1, characterized in that, The access domain administrator is used to perform the following: Based on the aforementioned trace trigger evidence, collect multiple valid access records under the same access event; By using the tracking private key to decrypt the encrypted access shares in each valid access record, the hidden access share can be obtained; Based on the access coordinates corresponding to each valid access record and the hidden access share, the constant term of the event polynomial is recovered by exponential field interpolation to obtain the user equipment's identity public key; Submit the identity public key to the blockchain.

3. The blockchain-based cross-domain device anonymous identity auditing and tracking method according to claim 2, characterized in that, The access domain administrator is also used to perform the following: When revokes a user device, the domain-specific revocation index of the user device to be revoked is added to the revocation set; Update the undo accumulator state; wherein the undo accumulator state is dynamically updated based on the undo set; If the user equipment has not been revoked, the updated revocation status is used to generate a non-member witness; wherein, the non-member witness is used to generate the non-revocation proof in subsequent access requests; The access domain identifier, the updated revocation accumulator status, and the revocation status of the revocation set are uploaded to the blockchain.

4. The blockchain-based cross-domain device anonymous identity auditing and tracking method according to claim 1, characterized in that, Before sending the credential issuance request to the access domain administrator, the method also includes: A user identity private key and a user identity public key are generated based on public system parameters obtained from the blockchain; a first knowledge proof is generated based on the identity private key and sent to the registration domain administrator so that the registration domain administrator can verify the first knowledge proof and write the identity public key into the blockchain; The system receives the domain revocation indexes corresponding to each access domain assigned by the access domain administrator; wherein the domain revocation indexes are encrypted and transmitted by the access domain administrator using the identity public key. A credential message vector is constructed based on the revocation index within each of the domains and the user's private key. The credential message vector is blinded to generate a blinded commitment and a second knowledge proof to obtain a credential issuance request; the credential issuance request includes the user's public key, access domain identifier, blinded commitment, and second knowledge proof.

5. The blockchain-based cross-domain device anonymous identity auditing and tracking method according to claim 1, characterized in that, The step of generating an access request based on the current access event, the access domain identifier corresponding to the access event, the anonymous credential, and the revocation status corresponding to the access domain obtained from the blockchain, and sending it to the validator, includes: For each access event, an event identifier and access coordinates are generated, and an event polynomial with the identity private key as a constant term is constructed, and a commitment to the event polynomial is generated. Obtain the revocation status corresponding to the access domain identifier from the blockchain. If it has not been revoked, generate a non-member witness and a revocation index commitment based on the revocation status, generate an unrevocable proof based on the non-member witness and the revocation index commitment, and generate a randomized certificate based on the anonymous certificate. An access proof is generated based on the event polynomial commitment, the access coordinates, the randomized credential, the revocation index commitment, and the non-revocation proof. An access request is generated based on a combination of the event identifier, the access coordinates, the event polynomial commitment, the randomized credential, the access proof, and the non-revocable proof.

6. The blockchain-based cross-domain device anonymous identity auditing and tracking method according to claim 1, characterized in that, The verifier is used to perform the following: The validity of the access request is verified based on the revocation status obtained from the blockchain; If the event identifier, access coordinates, or revocation status check in the access request fails, access is denied. If the verification passes, the randomized credential and access proof in the access request are verified. If either verification fails, access is denied. The event bucket is located based on the event identifier. It is checked whether the access request meets the preset access conditions. If it does, the access coordinates are added to the event bucket and the number of valid accesses under the same access event is counted.

7. The blockchain-based cross-domain device anonymous identity auditing and tracking method according to claim 6, characterized in that, The access conditions include: The event identifier in the access request is consistent with the event identifier in the event bucket; The event polynomial commitment in the access request is consistent with the event polynomial commitment in the event bucket; The access coordinates were not recorded in the event bucket.

8. The blockchain-based cross-domain device anonymous identity auditing and tracking method according to claim 1, characterized in that, The verifier is also used to perform the following: If the number of valid accesses does not exceed the event access threshold, the access is accepted and an access summary corresponding to the access request is generated; The access summary is uploaded to the blockchain.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the blockchain-based cross-domain device anonymous identity auditing and tracking method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the blockchain-based cross-domain device anonymous identity auditing and tracking method as described in any one of claims 1 to 8.

Images