Account recovery method and apparatus based on zero-knowledge proof

Abstract

This application provides an account recovery method and apparatus based on zero-knowledge proofs. The method includes: receiving an account recovery request sent by a target object; determining the contract address information of the on-chain account to be recovered in the blockchain network based on parameter information; generating zero-knowledge proof data based on object characteristics; generating account recovery intent data based on the zero-knowledge proof data and the contract address information; sending the account recovery intent data to the on-chain account to be recovered based on the contract address information, so that the on-chain account to be recovered verifies the zero-knowledge proof data if it determines that the account recovery intent data is valid; and determining that the target object has ownership of the on-chain account to be recovered when the verification of the zero-knowledge proof data is successful. This application can recover the account on-chain through verification of zero-knowledge proof data, without relying on additional off-chain services, reducing the difficulty of account recovery and the consumption of system resources.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to an account recovery method and apparatus based on zero-knowledge proof. Background Technology

[0002] In current intent systems, account recovery relies on off-chain services, such as email or other social recovery solutions. Taking email as an example, users can recover their accounts by verifying email ownership, but this method has the following drawbacks: First, email verification makes the account recovery process lengthy, increasing complexity and system resource consumption; second, if the email is stolen, it may result in the loss of account resources; third, if the email service ceases operation, the account resources may be permanently locked on the blockchain.

[0003] It is evident that relying on additional services under the blockchain to recover accounts not only lengthens the recovery process, increases complexity and system resource consumption, but also carries the risk of resource loss or permanent loss. Therefore, providing an account recovery method that allows users to directly recover their blockchain accounts without relying on blockchain-based services when using the system is of paramount importance. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides an account recovery method and apparatus based on zero-knowledge proofs.

[0005] On the one hand, this application proposes an account recovery method based on zero-knowledge proof, the method comprising:

[0006] Receive an account recovery request sent by the target object; the account recovery request carries the object characteristics of the target object and parameter information of the account on the chain to be recovered;

[0007] Based on the parameter information, determine the contract address information of the on-chain account to be recovered in the blockchain network, and generate zero-knowledge proof data based on the object characteristics;

[0008] Account recovery intent data is generated based on the zero-knowledge proof data and the contract address information;

[0009] Based on the contract address information, the account recovery intent data is sent to the on-chain account to be recovered in the blockchain network, so that the on-chain account to be recovered verifies the zero-knowledge proof data in the account recovery intent data if it is determined to be valid; and so that the on-chain account to be recovered determines that the target object has ownership of the on-chain account to be recovered if the zero-knowledge proof data is verified successfully, and restores the control object of the on-chain account to the target object.

[0010] On the other hand, this application proposes another account recovery method based on zero-knowledge proof, the method comprising:

[0011] The system receives account recovery intent data sent by the intent system based on contract address information; the account recovery intent data is generated by the intent system based on zero-knowledge proof data and the contract address information; the zero-knowledge proof data is generated by the intent system based on the object characteristics of the target object; the contract address information is the address information of the on-chain account to be recovered in the blockchain network, and the contract address information is determined based on the parameter information of the on-chain account to be recovered; the parameter information and the object characteristics are the information carried in the account recovery request, and the account recovery request is sent to the intent system by the target object;

[0012] If the account recovery intent data is determined to be legitimate, the zero-knowledge proof data in the account recovery intent data is verified.

[0013] If the zero-knowledge proof data verification is successful, it is determined that the target object has ownership of the on-chain account to be recovered, and the control object of the on-chain account to be recovered is restored to the target object.

[0014] On the other hand, this application proposes an account recovery device based on zero-knowledge proof, the device comprising:

[0015] An account recovery request receiving module is used to receive an account recovery request sent by a target object; the account recovery request carries the object characteristics of the target object and parameter information of the account on the chain to be recovered;

[0016] The zero-knowledge proof data generation module is used to determine the contract address information of the on-chain account to be recovered in the blockchain network based on the parameter information, and to generate zero-knowledge proof data based on the object characteristics;

[0017] The intent data generation module is used to generate account recovery intent data based on the zero-knowledge proof data and the contract address information;

[0018] The account recovery module is used to send the account recovery intent data to the on-chain account to be recovered in the blockchain network based on the contract address information, so that the on-chain account to be recovered can verify the zero-knowledge proof data in the account recovery intent data if it determines that the account recovery intent data is valid; and so that the on-chain account to be recovered can determine that the target object has ownership of the on-chain account to be recovered if it determines that the zero-knowledge proof data verification is successful, and restore the control object of the on-chain account to the target object.

[0019] On the other hand, this application proposes another account recovery device based on zero-knowledge proof, the device comprising:

[0020] An intent data receiving module is used to receive account recovery intent data sent by an intent system based on contract address information. The account recovery intent data is generated by the intent system based on zero-knowledge proof data and the contract address information. The zero-knowledge proof data is generated by the intent system based on the object characteristics of the target object. The contract address information is the address information of the on-chain account to be recovered in the blockchain network, and the contract address information is determined based on the parameter information of the on-chain account to be recovered. The parameter information and the object characteristics are information carried in the account recovery request, which is sent to the intent system by the target object.

[0021] The verification module is used to verify the zero-knowledge proof data in the account recovery intent data if the account recovery intent data is determined to be legitimate.

[0022] The ownership determination module is used to determine that the target object has ownership of the on-chain account to be recovered if the zero-knowledge proof data verification is successful, and to restore the control object of the on-chain account to be recovered to the target object.

[0023] On the other hand, this application proposes an electronic device including a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by the processor to implement the zero-knowledge proof-based account recovery method as described above.

[0024] On the other hand, this application proposes a computer-readable storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement the zero-knowledge proof-based account recovery method as described above.

[0025] On the other hand, this application proposes a computer program product, including a computer program that, when executed by a processor, implements the zero-knowledge proof-based account recovery method as described above.

[0026] This application provides an account recovery method and apparatus based on zero-knowledge proofs. The method first involves an intent system generating zero-knowledge proof data off-chain based on the object characteristics of the target object carried in the received account recovery request. Then, the intent system generates account recovery intent data based on the zero-knowledge proof data and contract address information, and sends it to the blockchain network. Upon receiving the account recovery intent data from the intent system and determining its validity, the zero-knowledge proof data in the contract can be verified. If the zero-knowledge proof data verification is successful, it is determined that the target object owns the on-chain account to be recovered, and the control object of the on-chain account to be recovered is replaced with the target object to recover the on-chain account. Therefore, on the one hand, by generating zero-knowledge proof data off-chain and verifying it on-chain, accounts can be restored, reducing the account restoration path, the difficulty of account restoration, and the consumption of system resources. On the other hand, the changes to the current business process are minimal; only an additional zero-knowledge proof system needs to be added to restore on-chain accounts, further reducing the difficulty of account restoration and the consumption of system resources. Thirdly, during the account restoration process, there is no need to rely on off-chain services, reducing the risk of resource loss or permanent loss of resources. Attached Figure Description

[0027] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a system architecture diagram illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment.

[0029] Figure 2 This is a flowchart illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment. Figure One .

[0030] Figure 3 This is a schematic diagram illustrating a process for generating zero-knowledge proof data according to an exemplary embodiment.

[0031] Figure 4This is a flowchart illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment. Figure Two .

[0032] Figure 5 This is a schematic diagram illustrating a process for verifying the legitimacy of account recovery intent data according to an exemplary embodiment.

[0033] Figure 6 This is a flowchart illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment. Figure Three .

[0034] Figure 7 This is a flowchart illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment. Figure Four .

[0035] Figure 8 This is a block diagram illustrating an account recovery device based on zero-knowledge proof according to an exemplary embodiment.

[0036] Figure 9 This is a block diagram illustrating another zero-knowledge proof-based account recovery device according to an exemplary embodiment.

[0037] Figure 10 This is a hardware structure block diagram of a server provided according to an exemplary embodiment. Detailed Implementation

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

[0039] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the present application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0040] It should be noted that, in the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program with a predetermined function, which works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0041] In related technologies, assuming a user wants to switch from Intent Operator 1 to Intent Operator 2, the user needs to undergo verification via a pre-set email address on Intent Operator 2. After successful verification, the user's on-chain account is restored in the Intent Operator 2's intent system, where they can view their on-chain resources. However, this process requires email verification. On one hand, it's crucial to ensure the email service is functioning correctly and won't cause verification failure; on the other hand, it's also essential to guarantee the email address itself isn't compromised, as this would put the on-chain resources at risk. Here, Intent Operator can refer to a node providing consensus services within the blockchain network.

[0042] However, relying on additional services off-chain to recover accounts not only lengthens the recovery path, increases complexity and system resource consumption, but also carries the risk of resource loss or permanent loss. Therefore, to enable users to directly recover their on-chain accounts without relying on off-chain services when using the intent system, thereby reducing the recovery path, difficulty, and system resource consumption, and minimizing the risk of resource loss or permanent loss, this application provides an account recovery method and system based on zero-knowledge proofs.

[0043] Figure 1 This is a system architecture diagram illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment, which may include at least a client 01, an intent system 02, and a blockchain network 03. The client 01 and the intent system 02 may be directly or indirectly connected via wired or wireless communication, and this embodiment of the application does not impose any limitations.

[0044] Specifically, client 01 can be used to send account recovery requests. Client 01 can be, but is not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc.

[0045] Specifically, the intent system 02 can be used to receive account recovery requests sent by a target object, generate zero-knowledge proof data, and send account recovery intent data to the blockchain network. It should be noted that each intent operator has its own intent system. For example, if intent operators include intent operator 1 and intent operator 2, then intent operator 1 and intent operator 2 each have their own intent systems. Each intent operator's intent system is equipped with a zero-knowledge proof generation module. The intent system may also include an intent pool, which is used to store account recovery intent data.

[0046] Optionally, the intent system 02 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0047] Specifically, the blockchain network 03 includes an intent settlement contract and multiple on-chain accounts. Each on-chain account is a smart contract, and each smart contract is equipped with a zero-knowledge proof verification module to verify the received zero-knowledge proof data, thereby determining the ownership of the on-chain account by the target object.

[0048] It should be noted that in the specific implementation of this application, user information is involved, such as object characteristics, parameter information of the on-chain account to be recovered, and other related data. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with relevant laws, regulations and standards.

[0049] Figure 2 This is a flowchart illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment. Figure One This method can be used for Figure 1 In the system architecture described in this specification, the method operation steps are as described in the embodiments or flowcharts. However, based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual system or server products, the method can be executed sequentially according to the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown in the figures... Figure 2 As shown, the method may include:

[0050] S101. The system intends to receive an account recovery request sent by the target object; the account recovery request carries the object characteristics of the target object and the parameter information of the account on the chain to be recovered.

[0051] In this embodiment of the application, the target object is the object that logs into the client 01. When the target object switches from one intent operator to another intent operator, if it wants to restore the on-chain account to be restored in the blockchain of the other intent operator, the client 01 can send the account restoration request to the intent system of the other intent operator. The account restoration request can carry the object characteristics of the target object and the parameter information of the on-chain account to be restored.

[0052] Optionally, the object feature can be considered as the target object's private information, which can be a question that is pre-set by the target object and whose answer is known only to the target object.

[0053] Optionally, the on-chain account to be recovered may be pre-constructed based on some parameter information, which may include the object characteristics of the target object, that is, the object characteristics of the target object may be used as part of the parameter information of the on-chain account to be recovered.

[0054] S103. The intent system determines the contract address information of the on-chain account to be recovered in the blockchain network based on parameter information, and generates zero-knowledge proof data based on object characteristics.

[0055] In this application, since the object characteristics are part of the parameter information for constructing the account to be recovered, the object characteristics of the target object can be used to query the blockchain network, query the address including the object characteristics, and obtain the contract address information of the on-chain account to be recovered in the blockchain network.

[0056] In this embodiment, when a target object initiates an account recovery request, the intent system needs to generate zero-knowledge proof data off-chain using a zero-knowledge proof generation module based on the object's characteristic data. This zero-knowledge proof data refers to a method for verifying the validity of a statement without disclosing the statement itself. Through this method, one party (the prover) can prove to another party (the verifier) ​​that something is true, without revealing any information other than the specific statement. In this application, the prover can be the target object, and the verifier can be the on-chain account to be recovered. The target object proves to the on-chain account to be recovered that it owns the on-chain account to be recovered.

[0057] S105. The intent system generates account recovery intent data based on zero-knowledge proof data and contract address information.

[0058] In this embodiment, when the intent system generates zero-knowledge proof data, the intent system can construct account recovery intent data (Intent). This account recovery intent data refers to the intention of a target object to recover its account in the blockchain network. It is an abstraction of on-chain behavior, allowing the target object to outsource transaction creation to a third party without relinquishing complete control to the transacting party, and providing greater flexibility. This account recovery intent data needs to include zero-knowledge proof data verifying ownership and the contract address information of the on-chain account to be recovered in the blockchain network.

[0059] It should be noted that, in addition to zero-knowledge proof data to verify ownership and the contract address information of the on-chain account to be restored in the blockchain network, the account recovery intent data may also include other information, such as the on-chain contract being invoked.

[0060] S107. The intent system sends account recovery intent data to the on-chain account to be recovered in the blockchain network based on the contract address information.

[0061] In this embodiment of the application, after the intent system generates account recovery intent data, the account recovery intent data can be submitted to the blockchain network. The account recovery intent data will be processed by the intent settlement contract and then forwarded to the corresponding on-chain account to be recovered based on the contract address information.

[0062] The on-chain account to be restored can be considered a smart contract.

[0063] S109. If the on-chain account to be restored is found to be legitimate, the zero-knowledge proof data in the account restoration intent data shall be verified.

[0064] S1011. If the zero-knowledge proof data verification is successful, the on-chain account to be recovered determines that the target object has ownership of the on-chain account to be recovered, and restores the control object of the on-chain account to be recovered to the target object.

[0065] In this embodiment of the application, after the smart contract receives the recovery intention data of the on-chain account to be recovered, it needs to verify the legality of the recovery intention data. If the recovery intention data is verified to be legal, the zero-knowledge proof data is verified. If the zero-knowledge proof data verification is successful, it is determined that the target object has ownership of the on-chain account to be recovered, and the control object of the on-chain account to be recovered is replaced by the target object in order to recover the on-chain account to be recovered.

[0066] Therefore, on the one hand, by generating zero-knowledge proof data off-chain and verifying it on-chain, accounts can be restored, reducing the account restoration path, the difficulty of account restoration, and the consumption of system resources. On the other hand, the changes to the current business process are minimal; only an additional zero-knowledge proof system needs to be added to restore on-chain accounts, further reducing the difficulty of account restoration and the consumption of system resources. Thirdly, during the account restoration process, there is no need to rely on off-chain services, reducing the risk of resource loss or permanent loss of resources.

[0067] Figure 3 This is a schematic diagram illustrating a process for generating zero-knowledge proof data according to an exemplary embodiment, such as... Figure 3 As shown, in an optional embodiment, in step S103 above, the intent system generating zero-knowledge proof data based on object features may include:

[0068] S1031. The intent system determines whether the object's features are complete.

[0069] S1033. The intent system determines the validity of zero-knowledge proof data when it judges that the object features are complete.

[0070] S1035. The intent system determines whether the contract address information exists in the blockchain network, provided that the zero-knowledge proof data is valid.

[0071] S1037. The intent system, upon determining that the contract address information exists in the blockchain network, constructs a zero-knowledge proof generation circuit based on the verification process of object characteristics.

[0072] S1039. The intention system inputs object features into the zero-knowledge proof generation circuit to generate zero-knowledge proof data for proving the object features.

[0073] In this embodiment, before the intent system generates zero-knowledge proof data, two verifications are required: first, verifying the validity of the zero-knowledge proof data; and second, if the zero-knowledge proof data is valid, verifying whether the on-chain account to be restored exists in the blockchain. Only after both verifications are successful does the intent system generate a zero-knowledge proof circuit based on object characteristics.

[0074] To verify the validity of zero-knowledge proofs: the intent system can determine whether the parameters that generate the zero-knowledge proof data, i.e., the object features, are complete. If so, the zero-knowledge proof data is verified as valid; otherwise, the zero-knowledge proof data is verified as invalid.

[0075] Regarding the verification of whether the on-chain account to be recovered exists in the blockchain: the intent system can search the blockchain network to see if the contract address information exists in the blockchain network. If it does, then the on-chain account to be recovered exists on the chain; otherwise, the on-chain account to be recovered does not exist on the chain.

[0076] Regarding the generation of zero-knowledge proof data: When verifying the existence of the on-chain account to be recovered in the blockchain, the intent system obtains a zero-knowledge proof generation algorithm. Based on this algorithm, a zero-knowledge proof generation circuit is constructed using the object feature verification process. When the object features are input into the zero-knowledge proof generation circuit, zero-knowledge proof data for proving the object features can be generated.

[0077] For example, the zero-knowledge proof generation algorithm can employ either Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (ZK-SNARK) or Zero-Knowledge Scalable Transparent Argument of Knowledge (ZK-STARK). Furthermore, since the proofs generated by ZK-SNARK are relatively small and have low verification costs, to further reduce memory usage in the blockchain and improve the efficiency of proof verification, Zero-Knowledge Succinct Non-Interactive Argument of Knowledge can be used to generate zero-knowledge proof data.

[0078] In this embodiment, if the object characteristics carried in the account recovery request are incomplete, the accuracy of the generated zero-knowledge proof data is low, and it cannot accurately verify whether the target object owns the on-chain account to be recovered. If the on-chain account to be recovered does not exist on the chain, continuing to generate zero-knowledge proof data will waste system resources. Therefore, when the intent system receives an account recovery request, it does not directly generate zero-knowledge proof data based on the object characteristics. Instead, it first performs a dual judgment on the validity of the zero-knowledge proof data and the existence of the contract address information in the blockchain network. Only when the dual judgment passes will the zero-knowledge proof circuit be generated. This improves the generation accuracy of the zero-knowledge proof and avoids wasting system resources. Furthermore, the zero-knowledge proof generation circuit constructed based on the object characteristic verification process generates zero-knowledge proof data, enabling the zero-knowledge proof data to accurately verify the target object, thereby accurately verifying whether the target object owns the on-chain account to be recovered.

[0079] In an optional embodiment, in step S105 above, the intent system generates account recovery intent data based on zero-knowledge proof data and contract address information, which may include:

[0080] The intent system uses zero-knowledge proof data and contract address information as intent parameters.

[0081] The intent system generates account recovery intent data based on the intent number parameter.

[0082] In this embodiment of the application, after the zero-knowledge proof data is generated, it is necessary to construct account recovery intent data. During construction, the zero-knowledge proof data and contract address information can be used as intent parameters, and the account recovery intent data can be obtained by fusing these intent parameters with other information such as the on-chain contract being invoked.

[0083] This application embodiment uses zero-knowledge proof data and contract address information as intent parameters to generate account recovery intent data. On the one hand, the contract address information can accurately locate the address of the on-chain account to be recovered in the blockchain network, so that the account recovery intent data can be accurately sent to the on-chain account to be recovered in the blockchain. On the other hand, the zero-knowledge proof data can serve as the basis for subsequent on-chain verification of whether the target object has ownership of the on-chain account to be recovered. This means that only an additional zero-knowledge proof system is needed to recover the on-chain account, further reducing the difficulty of account recovery and the consumption of system resources.

[0084] In an optional embodiment, the above method may further include:

[0085] The intention is for the system to obtain random numbers.

[0086] The intent system uses random numbers, zero-knowledge proof data from account recovery intent data, and contract address information as parameters for the hash function.

[0087] The intent system determines the hash value based on the parameters of the hash function.

[0088] In this embodiment of the application, in order to prevent the misuse of zero-knowledge proofs and to prevent the zero-knowledge proof data from being tampered with, a random number (nonce) can be used to ensure that the zero-knowledge proof submitted by the user when restoring the account can only be used once. Each time the account is restored, a new zero-knowledge proof needs to be generated.

[0089] Optionally, a hash value can be calculated from the random number, zero-knowledge proof, and other parameters in the account recovery intent data. This hash value ensures that the zero-knowledge proof data is not modified and remains valid. Specifically, in calculating the hash value, the random number, the zero-knowledge proof data in the account recovery intent data, and the contract address information can be used as parameters of the hash function. A specific algorithm is then used to map these parameters to a finite space to obtain the hash value.

[0090] Accordingly, in step S107 above, the intent system sends account recovery intent data to the on-chain account to be recovered in the blockchain network based on the contract address information, which may include:

[0091] The intent system sends account recovery intent data, including a hash value, to the on-chain account to be recovered, based on the contract address information.

[0092] In this embodiment, after generating a hash value based on zero-knowledge proof data, the account recovery intent data including the hash value can be sent to the on-chain account to be recovered, effectively preventing the misuse of zero-knowledge proofs.

[0093] In an optional embodiment, the above method further includes:

[0094] The intent system submits the account recovery intent data to the intent pool.

[0095] The intent system packages account recovery intent data from the intent pool into transactions.

[0096] Accordingly, in step S107 above, the intent system sends account recovery intent data to the on-chain account to be recovered in the blockchain network based on the contract address information, including:

[0097] The intent system sends transactions to the pending on-chain account in the blockchain network based on the contract address information.

[0098] In this embodiment, after the account recovery intent data is created, it can be submitted to the intent pool. The intent system packages the account recovery intent data in the intent pool into a transaction and submits it to the blockchain. A transaction is a way to submit state modifications to the blockchain. Any modification to the on-chain state needs to be packaged into a transaction. After the transaction is executed, it modifies the on-chain state. The execution of a transaction consumes computational resources (gas).

[0099] Optionally, the intent system can package account recovery intent data into a single transaction in the following ways:

[0100] Declaration of intent: It is necessary to clearly define the target conditions, constraint parameters, privacy policies, etc.

[0101] Intent parsing and path optimization: The solver network competitively parses the intent and generates the optimal execution path.

[0102] Transaction generation: Transforms the optimized path into an executable on-chain transaction.

[0103] On-chain verification and settlement: Transactions must pass on-chain verification logic to ensure compliance with the original intent constraints.

[0104] In this embodiment of the application, by packaging the account recovery intent data into a transaction and submitting it to the blockchain, it is possible to ensure the smooth verification of subsequent zero-knowledge proof data on the chain, thereby improving the accuracy of verifying whether the target object has ownership of the on-chain account to be recovered through zero-knowledge proof data.

[0105] In this embodiment, after the intent system uploads the account recovery intent data to the blockchain, it undergoes intent settlement contract processing and is then forwarded to the corresponding on-chain account to be recovered for processing. The on-chain account to be recovered receives this account recovery intent data and sequentially performs legality verification and zero-knowledge proof data verification. If the account recovery intent data is verified to be legal and the zero-knowledge proof data verification is successful, the on-chain account to be recovered determines that the target object owns the on-chain account to be recovered and replaces the control object of the on-chain account to be recovered with the target object to respond to the on-chain account to be recovered. If the zero-knowledge proof data verification fails, it indicates that the on-chain account to be recovered is not controlled by the target object, and an error result is directly returned, ending the execution.

[0106] In an optional embodiment, the legitimacy of the account recovery intent data can be determined by verifying whether the account recovery intent data can be deserialized and whether the signature therein is valid. Accordingly, the process of determining the legitimacy of the account recovery intent data includes:

[0107] The on-chain account to be recovered verifies whether the account recovery intent data can be deserialized into structured intent data.

[0108] If the account recovery intent data of the account to be recovered on the chain can be deserialized into structured intent data, verify whether the signature of the private key in the account recovery intent data is valid.

[0109] Once the on-chain account to be recovered verifies the validity of the private key signature, the data indicating the intention to recover the account is deemed legitimate.

[0110] In this embodiment, after receiving the account recovery intent data, the on-chain account to be recovered can first confirm whether the account recovery intent data can be deserialized into structured intent data. Deserialization refers to the process of restoring the account recovery intent data (i.e., binary / JSON) stored or transmitted in the blockchain network into machine-readable and executable structured intent data.

[0111] If the account recovery intent data for the account to be recovered on the blockchain cannot be deserialized into structured intent data, the process fails and returns immediately, ending the current process. If the account recovery intent data for the account to be recovered on the blockchain can be deserialized into structured intent data, the process continues to verify the validity of the private key signature within the account recovery intent data. If not, it indicates that the signature verification failed, and the process returns immediately, ending the current process. If yes, the account recovery intent data is deemed valid, and the various data components within the account recovery intent data are extracted.

[0112] Optionally, the signature of the private key in the account recovery intent data refers to the digital signature of the account recovery intent data by the target object using its private key. For example, the account recovery intent data can be assembled into a transaction, the transaction data can be hashed to generate a unique identifier, and the hash value can be encrypted using the target object's private key to generate a signature.

[0113] Optionally, the validity of the signature of the private key in the account recovery intent data can be verified using the public key corresponding to the private key.

[0114] Since the ability to deserialize the account recovery intent data determines whether it can be read and executed on the blockchain, subsequent processes are only executed after it has been confirmed that the account recovery intent data can be deserialized into structured intent data. This ensures that the account recovery intent data is readable and executable on the blockchain, improving the accuracy of account recovery. Furthermore, after confirming that the account recovery intent data can be deserialized into structured intent data, further verification of the validity of the private key signature within the account recovery intent data further verifies the legitimacy of the account recovery intent data, thereby further improving the accuracy of determining the legitimacy of the account recovery intent data.

[0115] In an optional embodiment, in step S109 above, the verification of the zero-knowledge proof data in the account recovery intent data may include:

[0116] The zero-knowledge verification algorithm corresponding to the zero-knowledge proof generation circuit for the on-chain account to be restored.

[0117] The on-chain accounts awaiting recovery undergo zero-knowledge verification of the zero-knowledge proof data using a zero-knowledge verification algorithm.

[0118] In this embodiment, the verification of zero-knowledge proof data can be implemented using a zero-knowledge verification algorithm. As mentioned earlier, in a concise, non-interactive zero-knowledge theory, the prover can use a certain algorithm to calculate zero-knowledge proof data for the object's features. The verifier can then use another algorithm to check whether the prover knows the object's features. Specifically, a zero-knowledge verification algorithm corresponding to the concise, non-interactive zero-knowledge theory can be obtained, such as a non-interactive zero-knowledge proof algorithm, and then the zero-knowledge proof data can be verified using this non-interactive zero-knowledge proof algorithm.

[0119] In this embodiment, zero-knowledge proof data verification is only performed after the on-chain account to be recovered has determined that the account recovery intention data is legitimate. This avoids the consumption of system resources caused by verifying zero-knowledge proofs under illegitimate circumstances. Furthermore, using a zero-knowledge verification algorithm corresponding to the zero-knowledge proof generation circuit improves verification accuracy, thereby enhancing the accuracy of verifying whether the target object has ownership of the on-chain account to be recovered through zero-knowledge proof data.

[0120] In an optional embodiment, the above method further includes:

[0121] In the event of a zero-knowledge proof data verification failure, the on-chain account to be recovered determines that the target object does not own the on-chain account to be recovered and returns an error message to the intent system; the error message is used to indicate that the target object does not own the on-chain account to be recovered.

[0122] In this embodiment of the application, if the zero-knowledge proof fails, it means that the on-chain account to be recovered is not controlled by the target object. In this case, the on-chain account to be recovered, i.e., the smart contract, directly returns an error message to the intent system. The error message is used to indicate that the target object does not have ownership of the on-chain account to be recovered and to terminate execution.

[0123] Therefore, by using zero-knowledge proofs for verification on the blockchain and providing error messages in case of verification failure, the user experience for account recovery is improved, indicating that the target object does not have ownership of the on-chain account to be recovered.

[0124] In an optional embodiment, the above method may further include:

[0125] The on-chain account to be recovered sends its account data to the intent system so that the target object can view the account data through the intent system.

[0126] In this embodiment, after the target object regains ownership of the on-chain account to be restored, it can recover its data at the intent operator and then continue using the intent system. Specifically, on the one hand, after regaining control of the on-chain account, the on-chain account data can be synchronized to the off-chain intent system. The target object can view the account data through the intent system, thereby seeing its own resources and data information, reducing the path for the target object to view account data and lowering the consumption of system resources by the target object viewing the account. On the other hand, after synchronization is complete, the intent system can be used normally to submit new intents and then execute on-chain operations. In this way, the target object is not bound to a single intent operator, improving the convenience and user experience of the target object submitting intents.

[0127] The following is a general explanation of the account recovery method based on zero-knowledge proof:

[0128] 1) Figure 4 This is a flowchart illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment. Figure Two ,like Figure 4 As shown, when a target wants to recover its on-chain account, it first needs to generate zero-knowledge proof data off-chain through the zero-knowledge proof generation module of the current operator's intent system. Before generating the zero-knowledge proof data, the following two aspects need to be verified:

[0129] a) Determine if the zero-knowledge proof data is valid: The validity of the zero-knowledge proof data is determined based on whether the object characteristics contained in the data are complete. If the object characteristics are complete, it is valid; otherwise, it is invalid. If the zero-knowledge proof data is invalid, the current process ends.

[0130] b) If the zero-knowledge proof data is valid, determine whether the contract address information exists in the blockchain network.

[0131] If the intent system determines that the zero-knowledge proof data is valid and the contract address information exists in the blockchain network, a zero-knowledge proof generation circuit is constructed based on the verification process of object characteristics. The object characteristics are then input into the zero-knowledge proof generation circuit to generate zero-knowledge proof data for proving the object characteristics.

[0132] If the contract address information does not exist in the blockchain network, a prompt message will be returned indicating that the on-chain account to be restored for the target object does not exist, and the current process will end.

[0133] 2) After the zero-knowledge proof data is generated, account recovery intent data needs to be constructed. This account recovery intent data needs to include zero-knowledge proof data to verify ownership and the contract address information of the on-chain account to be recovered in the block.

[0134] To prevent the misuse of zero-knowledge proofs and to prevent the zero-knowledge proof data from being tampered with, a nonce can be used to ensure that the zero-knowledge proof submitted by a user when restoring their account can only be used once. Each time an account is restored, a new zero-knowledge proof needs to be generated.

[0135] Optionally, a hash value can be calculated from the random number, zero-knowledge proof, and other parameters in the account recovery intent data. This hash value ensures that the zero-knowledge proof data is not modified and remains valid. Specifically, in calculating the hash value, the random number, the zero-knowledge proof data in the account recovery intent data, and the contract address information can be used as parameters of the hash function. A specific algorithm is then used to map these parameters to a finite space to obtain the hash value.

[0136] 3) After the account recovery intent data is created, the intent system can submit it to the intent pool, and the intent system will package the account recovery intent data in the intent pool into a transaction.

[0137] Next, it is determined whether the intent was successfully packaged. If so, the packaged transaction is submitted to the blockchain; otherwise, the current process ends.

[0138] 4) After the intent system packages the account recovery intent data into a transaction and submits it to the chain, it will be processed by the intent settlement contract and then forwarded to the corresponding on-chain account to be recovered for processing. Upon receiving the account recovery intent data, the on-chain account to be recovered first needs to perform the following validity checks on the account recovery intent data:

[0139] a) Figure 5 This is a schematic diagram illustrating a process for verifying the legitimacy of account recovery intent data according to an exemplary embodiment, such as... Figure 5 As shown, verify whether the account recovery intent data can be deserialized into structured intent data. If yes, continue to the next step; otherwise, fail and return directly.

[0140] b) If the account recovery intent data can be deserialized into structured intent data, verify whether the signature of the private key in the account recovery intent data is valid. If yes, continue to the next step; otherwise, fail and return directly.

[0141] c) Extract the data from each part of the account recovery intent data.

[0142] 5) Perform zero-knowledge verification on the zero-knowledge proof data based on the zero-knowledge verification algorithm, and determine whether the target object has ownership of the on-chain account to be recovered based on the verification results.

[0143] a) If the zero-knowledge proof data verification is successful, the target object is determined to have ownership of the on-chain account to be recovered, and the control object of the on-chain account to be recovered is replaced by the target object in order to recover the on-chain account to be recovered.

[0144] b) If the zero-knowledge proof data verification fails, it means that the on-chain account to be recovered is not controlled by the target object. Return the error result directly and end the execution.

[0145] 6) Once the target object regains ownership of the on-chain account to be recovered, the user can restore their data at the intent operator and then continue using the intent system.

[0146] a) After regaining control of the on-chain account, the account data of the on-chain account can be synchronized to the off-chain intent system. The target object can view the account data through the intent system, thereby seeing its own resources and data information. This reduces the path for the target object to view the account data and reduces the consumption of system resources by the target object to view the account.

[0147] b) After synchronization is complete, the intent system can be used normally to submit new intents and then perform on-chain operations. This way, the target object is not bound to a single intent operator, which improves the convenience and user experience of the target object submitting intents.

[0148] The following explanation uses the execution entity as the intent system and the execution entity to illustrate the aforementioned account recovery method based on zero-knowledge proof:

[0149] Figure 6 This is a flowchart illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment. Figure Three ,like Figure 6 As shown, this zero-knowledge proof-based account recovery method includes:

[0150] S201. Receive an account recovery request sent by the target object; the account recovery request carries the object characteristics of the target object and the parameter information of the account on the chain to be recovered.

[0151] S203. Determine the contract address information of the on-chain account to be recovered in the blockchain network based on parameter information, and generate zero-knowledge proof data based on object characteristics.

[0152] S205. Generate account recovery intent data based on zero-knowledge proof data and contract address information.

[0153] S207. Based on the contract address information, send account recovery intent data to the on-chain account to be recovered in the blockchain network, so that the on-chain account to be recovered can verify the zero-knowledge proof data in the account recovery intent data if it is determined to be legal; and so that the on-chain account to be recovered can determine that the target object has ownership of the on-chain account to be recovered if it is determined that the zero-knowledge proof data verification is successful, and restore the control object of the on-chain account to the target object.

[0154] In an optional embodiment, generating zero-knowledge proof data based on object features includes:

[0155] Determine if the object's features are complete;

[0156] If the characteristics of the object are complete, the zero-knowledge proof data is deemed valid.

[0157] Determine if the contract address information exists on the blockchain network;

[0158] Given that the contract address information exists in the blockchain network, a zero-knowledge proof generation circuit is constructed based on the verification process of object characteristics;

[0159] The object features are input into the zero-knowledge proof generation circuit to generate zero-knowledge proof data for proving the object features.

[0160] In an optional embodiment, account recovery intent data is generated based on zero-knowledge proof data and contract address information, including:

[0161] Use zero-knowledge proof data and contract address information as intent parameters;

[0162] Generate account recovery intent data based on the intent number parameter.

[0163] In an optional embodiment, the method further includes:

[0164] Get random numbers;

[0165] The random number, zero-knowledge proof data from the account recovery intent data, and contract address information are used as parameters of the hash function;

[0166] The hash value is determined based on the parameters of the hash function;

[0167] Based on the contract address information, account recovery intent data is sent to the on-chain account to be recovered in the blockchain network, including:

[0168] Based on the contract address information, send account recovery intent data, including the hash value, to the on-chain account to be recovered.

[0169] In an optional embodiment, the method further includes:

[0170] Submit the account recovery intent data to the intent pool;

[0171] Package the account recovery intent data in the intent pool into a transaction;

[0172] Based on the contract address information, account recovery intent data is sent to the on-chain account to be recovered in the blockchain network, including:

[0173] The transaction is sent to the pending on-chain account in the blockchain network based on the contract address information.

[0174] In an optional embodiment, the above method further includes:

[0175] Receive error messages from on-chain accounts awaiting recovery if the zero-knowledge proof data verification fails.

[0176] The error message indicates that the target object does not have ownership of the on-chain account to be recovered.

[0177] In an optional embodiment, the above method further includes:

[0178] After the control object of the on-chain account to be recovered is replaced by the target object, the account data of the on-chain account to be recovered is received from the on-chain account to be recovered, so that the target object can view the account data.

[0179] Figure 7 This is a flowchart illustrating an account recovery method based on zero-knowledge proof according to an exemplary embodiment. Figure Four ,like Figure 7 As shown, this zero-knowledge proof-based account recovery method includes:

[0180] S301. Receive account recovery intent data sent by the intent system based on contract address information; the account recovery intent data is generated by the intent system based on zero-knowledge proof data and contract address information; the zero-knowledge proof data is generated by the intent system based on the object characteristics of the target object; the contract address information is the address information of the on-chain account to be recovered in the blockchain network, and the contract address information is determined based on the parameter information of the on-chain account to be recovered; the parameter information and object characteristics are the information carried in the account recovery request, and the account recovery request is sent to the intent system by the target object.

[0181] S303. If the account recovery intent data is determined to be legitimate, the zero-knowledge proof data in the account recovery intent data shall be verified.

[0182] S305. If the zero-knowledge proof data verification is successful, determine that the target object has ownership of the on-chain account to be recovered, and restore the control object of the on-chain account to be recovered to the target object.

[0183] In an optional embodiment, receiving account recovery intent data sent by the intent system based on contract address information includes:

[0184] The system receives transactions sent based on contract address information.

[0185] Among them, the transaction is obtained by the intent system after submitting the account recovery intent data to the intent pool, and then packaging the account recovery intent data in the intent pool.

[0186] In an optional embodiment, the process of determining the legitimacy of account recovery intent data includes:

[0187] Verify whether account recovery intent data can be deserialized into structured intent data;

[0188] If the account recovery intent data can be deserialized into structured intent data, verify whether the signature of the private key in the account recovery intent data is valid;

[0189] If the signature of the private key is verified to be valid, the data indicating the intention to recover the account is deemed legitimate.

[0190] In an optional embodiment, the zero-knowledge proof data in the account recovery intent data is validated, including:

[0191] Obtain the zero-knowledge verification algorithm corresponding to the zero-knowledge proof generation circuit;

[0192] Zero-knowledge verification is performed on zero-knowledge proof data based on the zero-knowledge verification algorithm.

[0193] In an optional embodiment, the above method further includes:

[0194] In the event that zero-knowledge proof data verification fails, an error message is returned to the intent system;

[0195] The error message indicates that the target object does not have ownership of the on-chain account to be recovered.

[0196] In an optional embodiment, the above method further includes:

[0197] Send the account data of the on-chain account to be recovered to the intent system so that the target object can view the account data through the intent system.

[0198] Figure 8 This is a block diagram illustrating an account recovery device based on zero-knowledge proof according to an exemplary embodiment, such as... Figure 8 As shown, the zero-knowledge proof-based account recovery device includes:

[0199] The account recovery request receiving module 401 is used to receive an account recovery request sent by the target object; the account recovery request carries the object characteristics of the target object and the parameter information of the account on the chain to be recovered;

[0200] The zero-knowledge proof data generation module 403 is used to determine the contract address information of the on-chain account to be recovered in the blockchain network based on the parameter information, and to generate zero-knowledge proof data based on the object characteristics;

[0201] Intent data generation module 405 is used to generate account recovery intent data based on the zero-knowledge proof data and the contract address information;

[0202] The account recovery module 407 is used to send the account recovery intent data to the on-chain account to be recovered in the blockchain network based on the contract address information, so that the on-chain account to be recovered can verify the zero-knowledge proof data in the account recovery intent data if it is determined to be valid; and so that the on-chain account to be recovered can determine that the target object has ownership of the on-chain account to be recovered if the zero-knowledge proof data is verified successfully, and restore the control object of the on-chain account to be recovered to the target object.

[0203] In an optional embodiment, the zero-knowledge proof data generation module includes:

[0204] The first judgment unit is used to determine whether the object features are complete;

[0205] The second judgment unit is used to determine the validity of the zero-knowledge proof data if the object features are complete.

[0206] The third judgment unit is used to determine whether the contract address information exists in the blockchain network if the zero-knowledge proof data is valid.

[0207] A circuit generation unit is used to construct a zero-knowledge proof generation circuit based on the verification process of the object characteristics, provided that the contract address information exists in the blockchain network.

[0208] The proof generation unit is used to input the object features into the zero-knowledge proof generation circuit to generate the zero-knowledge proof data used to prove the object features.

[0209] In an optional embodiment, the intent data generation module includes:

[0210] The parameter determination unit is used to use the zero-knowledge proof data and the contract address information as intent parameters.

[0211] The data generation unit is used to generate the account recovery intent data based on the intent number parameter.

[0212] In an optional embodiment, the above-described apparatus further includes:

[0213] The random number generation module is used to generate random numbers.

[0214] The hash parameter determination module is used to take the random number, the zero-knowledge proof data in the account recovery intent data, and the contract address information as parameters of the hash function;

[0215] A hash value generation module is used to determine the hash value based on the parameters of the hash function;

[0216] Accordingly, the aforementioned account recovery module includes:

[0217] The hash value sending unit is used to send account recovery intent data, including the hash value, to the on-chain account to be recovered, based on the contract address information.

[0218] In an optional embodiment, the above-described apparatus further includes:

[0219] The intent data submission module is used to submit the account recovery intent data to the intent pool;

[0220] The packaging module is used to package the account recovery intent data in the intent pool into a transaction;

[0221] Accordingly, the aforementioned account recovery module includes:

[0222] A transaction sending unit is used to send the transaction to the on-chain account to be recovered in the blockchain network based on the contract address information.

[0223] In an optional embodiment, the above-described apparatus further includes:

[0224] The error message receiving module is used to receive error message sent by the on-chain account to be recovered when it is determined that the zero-knowledge proof data verification has failed;

[0225] The error message indicates that the target object does not own the on-chain account to be recovered.

[0226] In an optional embodiment, the above-described apparatus further includes:

[0227] The account data receiving module is used to receive account data of the account to be recovered sent by the account to be recovered after the control object of the account to be recovered is replaced by the target object, so that the target object can view the account data.

[0228] Figure 9 This is a block diagram illustrating another zero-knowledge proof-based account recovery device according to an exemplary embodiment, such as... Figure 9 As shown, the zero-knowledge proof-based account recovery device includes:

[0229] The intent data receiving module 501 is used to receive account recovery intent data sent by the intent system based on contract address information; the account recovery intent data is generated by the intent system based on zero-knowledge proof data and the contract address information; the zero-knowledge proof data is generated by the intent system based on the object characteristics of the target object; the contract address information is the address information of the on-chain account to be recovered in the blockchain network, and the contract address information is determined based on the parameter information of the on-chain account to be recovered; the parameter information and the object characteristics are the information carried in the account recovery request, and the account recovery request is sent to the intent system by the target object;

[0230] The verification module 503 is used to verify the zero-knowledge proof data in the account recovery intent data when the account recovery intent data is determined to be legitimate.

[0231] The ownership determination module 505 is used to determine that the target object has ownership of the on-chain account to be recovered when the zero-knowledge proof data verification is successful, and to restore the control object of the on-chain account to be recovered to the target object.

[0232] In an optional embodiment, the intent data receiving module includes:

[0233] A transaction receiving unit is used to receive transactions sent by the intent system based on the contract address information;

[0234] The transaction is obtained by the intent system packaging the account recovery intent data in the intent pool after submitting the account recovery intent data to the intent pool.

[0235] In an optional embodiment, the above-described apparatus further includes:

[0236] The first verification module is used to verify whether the account recovery intent data can be deserialized into structured intent data;

[0237] The second verification module is used to verify whether the signature of the private key in the account recovery intent data is valid, provided that the account recovery intent data can be deserialized into structured intent data.

[0238] The legitimacy determination module is used to determine the legitimacy of the account recovery intent data after verifying that the signature of the private key is valid.

[0239] In an optional embodiment, the verification module includes:

[0240] The verification algorithm acquisition unit is used to acquire the zero-knowledge verification algorithm corresponding to the zero-knowledge proof generation circuit.

[0241] The proof verification unit is used to perform zero-knowledge verification on the zero-knowledge proof data based on the zero-knowledge verification algorithm.

[0242] In an optional embodiment, the above-described apparatus further includes:

[0243] The return module is used to return an error message to the intent system in the event that the zero-knowledge proof data verification fails.

[0244] The error message indicates that the target object does not own the on-chain account to be recovered.

[0245] In an optional embodiment, the above-described apparatus further includes:

[0246] The account data sending module is used to send the account data of the account to be recovered on the chain to the intent system, so that the target object can view the account data through the intent system.

[0247] It should be noted that the device embodiments provided in this application are based on the same inventive concept as the method embodiments described above.

[0248] This application also provides an electronic device, which includes a processor and a memory. The memory stores at least one instruction or at least one program. The processor loads and executes the at least one instruction or at least one program to implement the zero-knowledge proof-based account recovery method provided in any of the above embodiments.

[0249] Embodiments of this application also provide a computer-readable storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement the zero-knowledge proof-based account recovery method provided in any of the above embodiments.

[0250] Optionally, in the embodiments of this specification, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0251] The memory described in this specification can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for functions, etc.; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0252] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the identification model generation method or the zero-knowledge proof-based account recovery method provided in the above-described method embodiments.

[0253] The account recovery method based on zero-knowledge proof provided in this application can be executed on a terminal, computer terminal, server, or similar computing device. Taking running on a server as an example... Figure 10 This is a hardware structure block diagram of a server according to an exemplary embodiment. For example... Figure 10As shown, the server 600 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 610 (CPUs 610 may include, but are not limited to, microprocessors (MCUs) or programmable logic devices (FPGAs), a memory 630 for storing data, and one or more storage media 620 (e.g., one or more mass storage devices) for storing application programs 623 or data 622. The memory 630 and storage media 620 may be temporary or persistent storage. The program stored in the storage media 620 may include one or more modules, each module may include a series of instruction operations on the server. Furthermore, the CPU 610 may be configured to communicate with the storage media 620 and execute the series of instruction operations stored in the storage media 620 on the server 600. Server 600 may also include one or more power supplies 660, one or more wired or wireless network interfaces 650, one or more input / output interfaces 640, and / or one or more operating systems 621, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0254] The input / output interface 640 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of server 600. In one example, the input / output interface 640 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 640 may be a radio frequency (RF) module for wireless communication with the Internet.

[0255] Those skilled in the art will understand that Figure 10 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, server 600 may also include... Figure 10 The more or fewer components shown, or having the same Figure 10 The different configurations shown.

[0256] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0257] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0258] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0259] The above are merely preferred embodiments of this application and are not intended to limit this application. 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. An account recovery method based on zero-knowledge proof, characterized in that, The method includes: Receive an account recovery request sent by the target object; the account recovery request carries the object characteristics of the target object and parameter information of the account on the chain to be recovered; Based on the parameter information, determine the contract address information of the on-chain account to be recovered in the blockchain network, and generate zero-knowledge proof data based on the object characteristics; Account recovery intent data is generated based on the zero-knowledge proof data and the contract address information; Based on the contract address information, the account recovery intent data is sent to the on-chain account to be recovered in the blockchain network, so that the on-chain account to be recovered verifies the zero-knowledge proof data in the account recovery intent data if it is determined to be valid; and so that the on-chain account to be recovered determines that the target object has ownership of the on-chain account to be recovered if the zero-knowledge proof data is verified successfully, and restores the control object of the on-chain account to the target object.

2. The method according to claim 1, characterized in that, The generation of zero-knowledge proof data based on the object features includes: Determine whether the object features are complete; If the object features are deemed complete, the zero-knowledge proof data is determined to be valid. Determine whether the contract address information exists in the blockchain network; If it is determined that the contract address information exists in the blockchain network, a zero-knowledge proof generation circuit is constructed based on the verification process of the object characteristics; The object features are input into the zero-knowledge proof generation circuit to generate the zero-knowledge proof data used to prove the object features.

3. The method according to claim 1, characterized in that, The process of generating account recovery intent data based on the zero-knowledge proof data and the contract address information includes: Use the zero-knowledge proof data and the contract address information as intent parameters; The account recovery intent data is generated based on the intent number parameter.

4. The method according to claim 1, characterized in that, The method further includes: Get random numbers; The random number, the zero-knowledge proof data in the account recovery intent data, and the contract address information are used as parameters of the hash function; The hash value is determined based on the parameters of the hash function; The step of sending the account recovery intent data to the on-chain account to be recovered in the blockchain network based on the contract address information includes: Based on the contract address information, account recovery intent data, including the hash value, is sent to the on-chain account to be recovered.

5. The method according to claim 1, characterized in that, The method further includes: Submit the account recovery intent data to the intent pool; Package the account recovery intent data in the intent pool into a transaction; The step of sending the account recovery intent data to the on-chain account to be recovered in the blockchain network based on the contract address information includes: The transaction is sent to the on-chain account to be restored in the blockchain network based on the contract address information.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Receive the error message sent by the on-chain account to be recovered in the event that the zero-knowledge proof data verification has failed; The error message indicates that the target object does not own the on-chain account to be recovered.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: After the control object of the account to be recovered on the chain is replaced by the target object, the account data of the account to be recovered on the chain is received from the account to be recovered on the chain, so that the target object can view the account data.

8. An account recovery method based on zero-knowledge proof, characterized in that, The method includes: The system receives account recovery intent data sent by the intent system based on contract address information; the account recovery intent data is generated by the intent system based on zero-knowledge proof data and the contract address information; the zero-knowledge proof data is generated by the intent system based on the object characteristics of the target object; the contract address information is the address information of the on-chain account to be recovered in the blockchain network, and the contract address information is determined based on the parameter information of the on-chain account to be recovered; the parameter information and the object characteristics are the information carried in the account recovery request, and the account recovery request is sent to the intent system by the target object; If the account recovery intent data is determined to be legitimate, the zero-knowledge proof data in the account recovery intent data is verified. If the zero-knowledge proof data verification is successful, it is determined that the target object has ownership of the on-chain account to be recovered, and the control object of the on-chain account to be recovered is restored to the target object.

9. The method according to claim 8, characterized in that, The account recovery intent data sent by the receiving intent system based on the contract address information includes: Receive the transaction sent by the intent system based on the contract address information; The transaction is obtained by the intent system packaging the account recovery intent data in the intent pool after submitting the account recovery intent data to the intent pool.

10. The method according to claim 8, characterized in that, The process of determining the legitimacy of the account recovery intent data includes: Verify whether the account recovery intent data can be deserialized into structured intent data; If the account recovery intent data can be deserialized into structured intent data, verify whether the signature of the private key in the account recovery intent data is valid; If the signature of the private key is verified to be valid, the account recovery intent data is determined to be legitimate.

11. The method according to claim 8, characterized in that, The verification of the zero-knowledge proof data in the account recovery intent data includes: Obtain the zero-knowledge verification algorithm corresponding to the zero-knowledge proof generation circuit; The zero-knowledge proof data is validated using the zero-knowledge validation algorithm.

12. The method according to any one of claims 8 to 11, characterized in that, The method further includes: If the zero-knowledge proof data verification fails, an error message is returned to the intent system; The error message indicates that the target object does not own the on-chain account to be recovered.

13. The method according to any one of claims 8 to 11, characterized in that, The method further includes: Send the account data of the on-chain account to be recovered to the intent system so that the target object can view the account data through the intent system.

14. An account recovery device based on zero-knowledge proof, characterized in that, The device includes: An account recovery request receiving module is used to receive an account recovery request sent by a target object; the account recovery request carries the object characteristics of the target object and parameter information of the account on the chain to be recovered; The zero-knowledge proof data generation module is used to determine the contract address information of the on-chain account to be recovered in the blockchain network based on the parameter information, and to generate zero-knowledge proof data based on the object characteristics; The intent data generation module is used to generate account recovery intent data based on the zero-knowledge proof data and the contract address information; The account recovery module is used to send the account recovery intent data to the on-chain account to be recovered in the blockchain network based on the contract address information, so that the on-chain account to be recovered can verify the zero-knowledge proof data in the account recovery intent data if it determines that the account recovery intent data is valid; and so that the on-chain account to be recovered can determine that the target object has ownership of the on-chain account to be recovered if it determines that the zero-knowledge proof data verification is successful, and restore the control object of the on-chain account to the target object.

15. An account recovery device based on zero-knowledge proof, characterized in that, The device includes: An intent data receiving module is used to receive account recovery intent data sent by an intent system based on contract address information. The account recovery intent data is generated by the intent system based on zero-knowledge proof data and the contract address information. The zero-knowledge proof data is generated by the intent system based on the object characteristics of the target object. The contract address information is the address information of the on-chain account to be recovered in the blockchain network, and the contract address information is determined based on the parameter information of the on-chain account to be recovered. The parameter information and the object characteristics are information carried in the account recovery request, and the account recovery request is sent to the intent system by the target object. The verification module is used to verify the zero-knowledge proof data in the account recovery intent data if the account recovery intent data is determined to be legitimate. The ownership determination module is used to determine that the target object has ownership of the on-chain account to be recovered if the zero-knowledge proof data verification is successful, and to restore the control object of the on-chain account to be recovered to the target object.

Images