CN115271689A

CN115271689A - Method and related equipment for retrieving digital assets

Info

Publication number: CN115271689A
Application number: CN202210853445.9A
Authority: CN
Inventors: 韩少庆; 顾费勇
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2022-07-08
Filing date: 2022-07-08
Publication date: 2022-11-01

Abstract

The application provides a method for retrieving digital assets and related equipment. The method comprises the following steps: issuing a digital asset trusted voucher in response to an asset acquisition event; receiving a verifiable description of the backup account signature in response to the asset recovery request; the verifiable description comprises encrypted first plaintext information; verifying whether the verifiable description is correct; if the verifiable description is correct, decrypting the first plaintext information, and verifying whether the first plaintext information is correct or not; and if the first plaintext information is correct, sending the digital asset of the user to the standby account according to the first plaintext information. According to the embodiment of the application, the digital assets of the original account are finally sent to the standby account through verifying the verifiable description and the plaintext information, so that all the digital assets in the original account can be retrieved under the condition that the private key of the original account is lost.

Description

Method and related equipment for retrieving digital assets

Technical Field

The application relates to the technical field of block chain finance, in particular to a method for retrieving digital assets and related equipment.

Background

When a current user creates a digital asset, possession of the user private key is equivalent to possession of ownership, including authorization, transfer, etc., of a Non-homogeneous token NFT digital asset. However, under the current NFT ownership, once the private key of the user is lost, the control right of the NFT digital asset is lost, and the corresponding digital asset cannot be retrieved.

Disclosure of Invention

In view of the above, the present application aims to provide a method for recovering a digital asset and a related device.

In view of the above, the present application provides a method for recovering digital assets, comprising:

issuing a digital asset trusted voucher in response to an asset acquisition event;

receiving a verifiable description of the backup account signature in response to the asset recovery request; the verifiable description comprises encrypted first plaintext information;

verifying whether the verifiable description is correct;

if the verifiable description is correct, decrypting the first plaintext information, and verifying whether the first plaintext information is correct;

and if the first plaintext information is correct, sending the digital assets of the primary account to the standby account according to the first plaintext information.

In one possible implementation, before issuing the digital asset trusted voucher in response to the asset acquisition event, the method further includes:

deploying a backup distributed identity contract, a credential theme contract, a recovery token contract, and a trusted credential non-homogenous token contract.

In one possible implementation, the method further includes:

and in response to receiving a standby account registration application, registering the standby account according to the standby distributed identity contract.

In one possible implementation, the issuing a digital asset trusted voucher in response to an asset acquisition event further comprises:

in response to an asset acquisition event, issuing the digital asset trusted voucher in accordance with the voucher subject contract and the trusted voucher non-homogenous token contract.

In one possible implementation, the plaintext information includes an asset recovery token; the verifiable description, comprising: a digital asset trusted voucher certification; wherein the plaintext information is encrypted by an issuer public key and the encrypted plaintext information is located in a digital asset trusted credential attestation;

the method further comprises the following steps:

configuring the asset recovery token according to the recovery token contract.

In one possible implementation, the method further includes:

in response to the asset retrieval request, encrypted plaintext information uploaded by the standby account is received through the block link;

in response to receiving the encrypted first plaintext information via a blockchain, verifying whether the backup account number is correct using the blockchain;

in response to the backup account number being correct, locking the digital asset through a blockchain to place the state of the digital asset in a locked state; wherein the state of the digital asset is recorded in the trusted voucher non-homogenous token contract.

In a possible implementation manner, the verifying whether the verifiable description is correct further includes:

decrypting the verifiable description to obtain a verification public key;

determining whether the check public key is the same as the user public key;

and if the check public key is the same as the user public key, determining that the verifiable description is correct.

In a possible implementation manner, the decrypting the first plaintext information and verifying whether the first plaintext information is correct further includes:

decrypting the first plaintext information using an issuer private key to determine second plaintext information;

uploading the second plaintext information to the recovery token contract;

determining whether the second plaintext information is the same as the first plaintext information through a block chain according to the recovery token contract;

and if the second plaintext information is determined to be the same as the first plaintext information, determining that the first plaintext information is correct.

In a possible implementation manner, before the verifying whether the first plaintext information is correct, the method further includes:

accessing a trusted credential non-homogeneous token contract through a blockchain to read whether a state of the digital asset is a locked state;

responding to the condition that the digital asset is in a locked state, acquiring a standby account address in the information of the primary account by using a block chain, and determining whether the standby account address is the same as a sending address corresponding to the verifiable description by using the block chain;

and if the address of the standby account is the same as the sending address corresponding to the verifiable description, determining that the standby account is correct.

In a possible implementation manner, after the sending the digital asset to the standby account according to the plaintext information if the plaintext information is correct, the method further includes:

detecting whether all the digital assets of the primary account are sent to the standby account;

clearing the primary account in response to detecting that all of the digital assets are sent to the backup account.

Based on the same inventive concept, one or more embodiments of the present specification further provide an apparatus for recovering digital assets, comprising:

an issuance module configured to issue a digital asset trusted credential to the user in response to an asset acquisition event;

a receiving module configured to receive a verifiable description of a backup account signature in response to an asset recovery request; the verifiable description comprises encrypted plaintext information;

a verification module configured to verify whether the verifiable description is correct;

a verification module configured to decrypt the first plaintext information if the verifiable description is correct, and verify whether the first plaintext information is correct;

and the sending module is configured to send the digital assets of the primary account to the standby account according to the first plaintext information if the first plaintext information is correct.

Based on the same inventive concept, one or more embodiments of the present specification further provide an electronic device, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the method for retrieving the digital asset.

Based on the same inventive concept, one or more embodiments of the present specification also provide a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform any one of the above-described methods for digital asset recovery.

From the above description, the method and the related device for retrieving the digital asset provided by the application issue a trusted certificate of the digital asset in response to an asset acquisition event; receiving a verifiable description of the backup account signature in response to the asset recovery request; the verifiable description comprises encrypted first plaintext information; verifying whether the verifiable description is correct; if the verifiable description is correct, decrypting the first plaintext information, and verifying whether the first plaintext information is correct; and if the first plaintext information is correct, sending the digital assets of the primary account to the standby account according to the first plaintext information. For the issuer, the digital assets are retrieved by acquiring and verifying the verifiable description and the plaintext information in time and sending the digital assets in the original account to the standby account. For a user, under the condition that the private key of the user is lost, the identity of the user is proved by sending plaintext information and verifiable description to the blockchain and the issuer, and the original account asset is transferred to the standby account by the issuer, so that the digital asset is recovered.

Drawings

In order to more clearly illustrate the technical solutions in the present application or the related art, the drawings needed to be used in the description of the embodiments or the related art will be briefly introduced below, and it is obvious that the drawings in the following description are only embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.

Fig. 1 is a schematic application scenario diagram of a digital asset recovery method according to an embodiment of the present application.

Fig. 2 is a flowchart of a method for recovering a digital asset according to an embodiment of the present application.

Fig. 3 is a schematic diagram of a format of a DID identifier according to an embodiment of the present application.

FIG. 4 is a flowchart illustrating verification of the verifiable description according to an embodiment of the present application.

Fig. 5 is a flowchart of decrypting and verifying the first plaintext information according to an embodiment of the application.

Fig. 6 is a flowchart of the first clear text information verification according to the embodiment of the present application.

Fig. 7 is a schematic structural diagram of an apparatus for recovering digital assets according to an embodiment of the present application.

Fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is further described in detail below with reference to specific embodiments and the accompanying drawings.

It should be noted that technical terms or scientific terms used in the embodiments of the present application should have a general meaning as understood by those having ordinary skill in the art to which the present application belongs, unless otherwise defined. The use of "first," "second," and similar terms in the embodiments of the present application do not denote any order, quantity, or importance, but rather the terms are used to distinguish one element from another. The word "comprising" or "comprises", and the like, means that the element or item preceding the word comprises the element or item listed after the word and its equivalent, but does not exclude other elements or items. The terms "connected" or "coupled" and the like are not restricted to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "upper", "lower", "left", "right", and the like are used only to indicate relative positional relationships, and when the absolute position of the object being described is changed, the relative positional relationships may also be changed accordingly.

As described in the background section, in the prior art, no one can modify the ownership record of a digital asset or copy and paste a new copy from an existing digital asset, and therefore, when the user's private key is lost, it will not be possible to retrieve all of the digital assets in the user's account.

In summary, the embodiments of the present application provide a method for retrieving a digital asset, where verifiable descriptions and plaintext information uploaded by a user are obtained and verified, and when the verification passes, all digital assets in an original account are sent to a standby account, so that the user can also retrieve digital assets owned by the user when the private key of the user is lost, thereby effectively preventing the loss of the assets of the user.

Reference is made to fig. 1, which is a schematic application scenario diagram of a method for recovering a digital asset provided in an embodiment of the present application. The application scenario includes a terminal device 101, a server 102, and a data storage system 103. The terminal device 101, the server 102, and the data storage system 103 may be connected through a wired or wireless communication network. The terminal device 101 includes, but is not limited to, a desktop computer, a mobile phone, a mobile computer, a tablet computer, a media player, a smart wearable device, a Personal Digital Assistant (PDA), or other electronic devices capable of implementing the above functions. The server 102 and the data storage system 103 may be independent physical servers, may also be a server cluster or distributed system formed by a plurality of physical servers, and may also be cloud servers providing 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, CDNs, and big data and artificial intelligence platforms.

The server 102 is used for providing digital asset retrieving service for a user of the terminal device 101, a client communicated with the server 102 is installed in the terminal device 101, the user can input verifiable description through the client, the client sends the verifiable description to the server 102 after clicking a detection button, the server 102 verifies the verifiable description, after the verification is passed, first plaintext information contained in the verifiable description is decrypted and whether the first plaintext information is correct or not is verified, if the first plaintext information is correct, the corresponding digital asset is sent to the client, and the client displays the digital asset to the user through a spare account so as to help the user to retrieve the digital asset.

The data storage system 103 stores a large amount of user data, and the server 102 can verify whether the verifiable description and the first plaintext information are correct by obtaining the user data in the data storage system 103, and the source of the user data includes but is not limited to an existing database, data crawled from the internet, or data uploaded when the user uses a client.

The method for retrieving digital assets according to the exemplary embodiment of the present application is described below with reference to the application scenario of fig. 1. It should be noted that the above application scenarios are only shown for the convenience of understanding the spirit and principle of the present application, and the embodiments of the present application are not limited in this respect. Rather, embodiments of the present application may be applied to any scenario where applicable.

Hereinafter, the technical means of the embodiments of the present application will be described in detail by specific examples.

Referring to fig. 2, the method for recovering a digital asset of the embodiment of the present application includes the following steps:

step S201, responding to an asset acquisition event, and issuing a digital asset trusted certificate to the user;

step S202, responding to the asset retrieval request, and receiving verifiable description of the backup account signature sent by the user; the verifiable description comprises encrypted first plaintext information;

step S203, verifying whether the verifiable description is correct;

step S204, in response to the verifiable description being correct, decrypting the first plaintext information, and verifying whether the first plaintext information is correct;

step S205, in response to that the first plaintext information is correct, sending the digital asset of the user to the standby account according to the first plaintext information.

For step S201, the asset acquisition event may be a digging event that the issuer monitors the user digging the digital asset, and when monitoring the user digging the digital asset, the issuer generally monitors the transaction on the chain through related components such as a Software Development Kit (SDK).

For example, the Ethernet workshop full node is accessed by web3j, transaction events are monitored through contract addresses, and transaction records are obtained. Web3j refers to the Java version of the Etherhouse JSON-RPC interface protocol encapsulation implementation. JSON-RPC is a stateless and lightweight remote procedure call transfer protocol, and the transfer content of the JSON-RPC is mainly transmitted through JSON. Compared with the common remote server calling through the website, the JSON-RPC directly defines the name of the function to be called in the content.

For digital asset trusted certificates (VCs), the VC provides a specification to describe certain attributes that an entity has, enabling evidence-based trust. Distributed identity Identifiers (DID) holders can prove to other entities (individuals, organizations, things, etc.) that certain attributes of themselves are authentic through the VC. Meanwhile, by combining the cryptography technologies such as digital signature and zero knowledge proof, the declaration is safer and more credible, and the privacy of the user is further ensured not to be invaded.

In a VC system, there are several participants: an issuer, a holder, a verifier, and an identifier registration authority.

The issuer is the entity, such as government, bank, university, etc., that owns the user data and can offer the VC.

The holder, i.e., the user, presents the digital asset trust credential to the verifier when the user requests, receives, or otherwise holds the VC from the issuer. The VC opened may be self-stored for later reuse, e.g. in a wallet.

The verifier receives and verifies the VC and can thereby provide the owner presenting the VC with some type of service.

The identifier registry maintains a database of distributed digital identities, such as a blockchain or a distributed ledger.

The roles and information flows in the VC system are as follows:

the issuer discovers a VC holder, the act of issuing always occurs before any other operations involving credentials;

a holder may own one or more VCs, and the holder may transfer the one or more VCs to others;

the holder can present one or more VCs to the verifier and can optionally present a Verifiable description (VP);

verifying the authenticity of the VC and the VP presented by the holder by the verifier, and checking the suspension and cancellation state of the VC;

the issuer can revoke VC;

the holder may delete the VC.

Before step S201, the method further includes: deploying a backup distributed identity contract, a credential theme contract, a recovery token contract, and a trusted credential non-homogenous token contract.

Of course, in addition to the above-described contracts, issuers also deploy contracts that have been deployed in the prior art, such as distributed identity contracts and issuer contracts.

For a Distributed Identity (DID) identifier, the DID identifier is a character string with a specific format, and is used to represent a digital Identity of an entity, where the entity may be a person, a machine, or an object.

As shown in fig. 3, the format of the DID flag includes a prefix "DID", a middle portion "example", and an end portion "123456789abcdefghijk".

The prefix did is fixed, indicating that this string is a did identification string.

The middle "example" is called the DID method, i.e. the method used to identify which set of schemes (methods) this DID identifier is defined and operated on. This DID method can be customized and registered to the W3C website.

The last part is an identification string, which is unique.

In addition, each DID id corresponds to a DID document, which is a Object Notation (JSON) string, and the inside of the document generally contains the following information: DID document content, DID topic, public key, authentication, authorization, service endpoint, and timestamp.

The DID topic is the DID identifier itself, that is, the DID described by the DID document. There can be only one DID in the DID document due to the globally unique characteristics of the DID.

Public keys are used for digital signatures and other cryptographic operations that are the basis for authentication and establishing secure communications with service endpoints. If the public key does not exist in the DID document, it must be assumed that the key has been revoked or invalidated, and revocation information (e.g., a revocation list) of the key must be contained or referenced.

The process of identity verification is the process of the DID subjects cryptographically certifying that they are associated with the DID.

Authorization means that others perform operations on behalf of the DID topic.

In addition to publishing authentication and authorization mechanisms, another primary purpose of DID documents is to discover service endpoints for topics. A service endpoint may represent any type of service that a subject wishes to advertise, including decentralized identity management services for further discovery, authentication, authorization, or interaction.

The time stamp includes a document creation time and an update time.

It should be noted that the information types involved in the above-mentioned DID documents are not necessarily included, and can be purposefully selected, but it is generally suggested to include all information types.

In addition, in the registration process, the information of the primary account needs to include the address of the backup account, so that whether the primary account corresponding to the backup address is the primary account of the digital asset to be retrieved can be verified in the subsequent verification process.

In addition, when the issuer monitors that the user excavates the digital asset, a digging event of the user is recorded by using the credibility evidence heterogeneous token contract, wherein the issuer needs to issue the credibility evidence of the digital asset to the user, before the issuing action occurs, the evidence theme contract automatically detects whether the issuer is qualified to issue the credibility evidence of the digital asset, and issues the credibility evidence of the digital asset to the user in response to the issuer being qualified to issue the credibility evidence of the digital asset.

For step S202, the plaintext information includes an asset recovery token and a random number, the asset recovery token being configured according to a recovery token contract. The asset retrieval token is automatically generated on line and can be acquired off line when the digital assets of the user are lost, the random number can be generated through a random algorithm, and in the embodiment of the application, the time of the time stamp is encrypted through a Hash algorithm to obtain the random number. The asset retrieval token and the random number together constitute clear text information. When the digital asset of the user is lost, the user can initiate an asset retrieval request, further, the plaintext information is encrypted by using the public key of the issuer, the encrypted plaintext information is added into the digital asset trusted certificate in the verifiable description, the verifiable description is signed by the private key of the standby account, and the digital asset trusted certificate is sent to the issuer by using the standby account.

Meanwhile, the user encrypts the plaintext information by using another general algorithm to obtain encrypted first plaintext information, and the encrypted first plaintext information is uploaded to the block chain through the standby account, so that comparison by an issuer is facilitated.

When the block link receives the encrypted first plaintext information uploaded by the user, the block link firstly verifies whether the backup address for sending the encrypted first plaintext information is correct, namely whether the backup address is the first plaintext information sent by the backup account address corresponding to the corresponding original account, specifically, the backup address of the backup account in the original account information is obtained from the block link, whether the address of the backup account in the block link is the same as the sending address of the user is determined, if the address of the backup account in the block link is the same as the sending address of the user, the backup account for sending the encrypted first plaintext information is correct, and if the address of the backup account in the block link is not the same as the sending address of the user, the subsequent operation is stopped. The process of verifying the backup account is accomplished through a backup distributed identity contract.

The purpose of verifying whether the standby account is correct is to prevent other people from stealing the digital assets of the user after acquiring the plaintext information, namely, the subsequent retrieving step can be continued only by using the correct standby account to send the encrypted first plaintext information.

In one possible implementation manner, the state of the digital asset comprises a locked state and an unlocked state, and when the standby account is verified to be correct, the digital asset is locked through a block chain so as to set the state of the digital asset to be the locked state; wherein a state of the digital asset is recorded in the trusted voucher non-homogeneous token contract.

With reference to fig. 4, the step S203 is performed to verify whether the verifiable description is correct, which includes the following steps:

step S401, decrypting the verifiable description to obtain a verification public key;

step S402, determining whether the check public key is the same as the user public key;

step S403, if the verification public key is the same as the user public key, determining that the verifiable description is correct.

With respect to step S401, the verifiable description is encrypted by a user using a private key of the backup account, and after receiving the verifiable description, the issuer uses a corresponding algorithm to solve the verification public key from the signature.

In step S402, the private key of the spare account of the user has a public key matched with the private key, and the issuer knows the public key corresponding to the private key of the spare account, and determines whether the check public key solved in step S401 is the same as the public key corresponding to the private key of the spare account.

In step S403, if the resolved verification public key is the same as the public key corresponding to the private key of the backup account, it indicates that the verification public key is actually encrypted by using the private key of the backup account of the user, and the correctness of the verifiable description is ensured.

Referring to step S204 and fig. 5, the decrypting the first plaintext information and verifying whether the first plaintext information is correct in the embodiment of the present application includes the following steps:

step S501, decrypting the first plaintext information by using an issuer private key to determine second plaintext information;

step S502, uploading the second plaintext information to the recovery token contract;

step S503, determining whether the second plaintext information is the same as the first plaintext information through a block chain according to the recovery token contract;

in step S504, if it is determined that the second plaintext information is identical to the first plaintext information, it is determined that the first plaintext information is correct.

In step S501, the first plaintext information is encrypted by the user using a public key of the issuer, where the public key is known, so that the user may encrypt the information using the public key, and the issuer decrypts the information using a private key corresponding to the public key to obtain second plaintext information, where the second plaintext information is the unencrypted asset recovery token and the random number.

In step S502, the issuer needs to verify whether the first plaintext information is correct after solving the second plaintext information, so as to determine that the first plaintext information is actually an asset retrieval application issued by a real user. The issuer needs to upload the second plaintext information into the recovery token contract in the blockchain.

In step S503, the asset recovery token and the random number are encrypted by the user using a known algorithm to obtain first plaintext information, the specific asset recovery token and the random number that are solved from the verifiable description sent by the issuer from the user are second plaintext information, the recovery token contract automatically encrypts the specific asset recovery token and the random number uploaded by the issuer using the same known algorithm, and then determines whether the specific asset recovery token and the random number are the same as the first plaintext information, if the specific asset recovery token and the random number are the same as the first plaintext information, the first plaintext information is verified to be correct, that is, the second plaintext information is also correct, and the specific asset recovery token and the random number are verified to be an asset recovery application sent by a correct user.

Referring to fig. 6, before step S503, the following steps are further included:

step S601, accessing a trusted voucher non-homogeneous token contract through a block chain to read whether the state of the digital asset is a locked state;

step S602, in response to the fact that the digital asset is in a locked state, a block chain is used for obtaining a standby account address in the information of the original account, and whether the standby account address is the same as a sending address corresponding to the verifiable description is determined by the block chain;

step S603, if the address of the backup account is the same as the sending address corresponding to the verifiable description, determining that the backup account is correct.

Referring to step S601, in step S202, after the backup account is verified correctly, the digital asset is locked through the blockchain to set the state of the digital asset to the locked state, and in this step, it is necessary to read whether the state of the digital asset is the locked state, so as to determine whether the user sends the first plaintext information to the blockchain.

In step S602, when the status of reading the digital asset from the trusted voucher non-homogeneous token contract is the locked status, it indicates that the user has uploaded the first plaintext information to the block chain, which is equivalent to that the user initiated an application for retrieving the digital asset, that is, whether the user has a need to retrieve the digital asset and whether the application for retrieving the digital asset is initiated are obtained by obtaining whether the status of the digital asset is the locked status. When the digital asset is in a locked state, whether the address of the standby account is the same as the sending address corresponding to the verifiable description or not needs to be determined through the block chain, and then whether the address sending the verifiable description is the address of the standby account or not can be determined, so that the authenticity of the address sending the verifiable description is determined, the digital asset is prevented from being transferred to the account of other people after the verifiable description of the real user is obtained, and the reliability in the digital asset retrieving process is effectively enhanced.

With respect to step S205, after the first plaintext information is verified to be correct through the above steps, the corresponding digital asset in the primary account corresponding to the address of the backup account, which is described by sending the verifiable description, is sent to the backup account. It should be noted that when the private key of the primary account of the user is lost, the user loses control over all the digital assets in the primary account, and therefore, the corresponding first plaintext information and verifiable description need to be issued for each digital asset owned by the user, and each digital asset also only corresponds to a single first plaintext information and a single verifiable description. Therefore, the user needs to initiate multiple applications to transfer all the digital assets in his primary account to the backup account.

Therefore, after each transfer of the digital assets, one detection is carried out, namely whether all the digital assets of the primary account are sent to the standby account is detected, and after all the digital assets are sent to the standby account, the issuer clears the primary account to prevent other people from carrying out illegal operation after obtaining the private key of the primary account, so that the private assets of the user are lost.

It can be seen from the foregoing embodiments that, in the method for recovering a digital asset according to an embodiment of the present application, a trusted certificate of the digital asset is issued to the user in response to an asset retrieving event, a verifiable description of a backup account signature is received in response to an asset retrieving request, where the verifiable description includes encrypted first plaintext information, whether the verifiable description is correct is verified, and if the verifiable description is correct, the first plaintext information is decrypted, whether the first plaintext information is correct is verified, and if the first plaintext information is correct, the digital asset of the user is sent to the backup account according to the first plaintext information. For an issuer, the digital assets of the user can be found back after the private key of the account is lost by timely acquiring and verifying the verifiable description and the plaintext information sent by the user on the basis of protecting the safety of the digital assets of the user, and the embodiment of the application can help the user to directly send the digital assets in the original account to the standby account, and clear the original account after all the digital assets in the original account are sent to the standby account, thereby effectively preventing the risk that other people continue to use the original account after acquiring the private key of the original account.

It should be noted that the method of the embodiment of the present application may be executed by a single device, such as a computer or a server. The method of the embodiment can also be applied to a distributed scene and is completed by the mutual cooperation of a plurality of devices. In such a distributed scenario, one of the multiple devices may only perform one or more steps of the method of the embodiment, and the multiple devices interact with each other to complete the method.

It should be noted that the foregoing describes some embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments described above and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Based on the same inventive concept, corresponding to the method of any embodiment, the application also provides a device for retrieving the digital assets.

Referring to fig. 7, the apparatus for digital asset recovery comprises:

an issuance module 71 configured to issue a digital asset trusted voucher in response to an asset acquisition event;

a receiving module 72 configured to receive a verifiable description of the backup account signature in response to the asset recovery request; the verifiable description comprises encrypted first plaintext information;

a verification module 73 configured to verify whether the verifiable description is correct;

a verification module 73 configured to decrypt the plaintext information if the verifiable description is correct, and verify whether the plaintext information is correct;

a sending module 74 configured to send the digital asset of the user to the standby account according to the plaintext information if the plaintext information is correct.

In one possible implementation manner, the apparatus further includes: a deployment module;

the deployment module is further configured to:

In a possible implementation manner, the apparatus further includes: a registration module;

the registration module is further configured to:

In one possible implementation, the issuing module 71 is further configured to:

issuing the digital asset trusted voucher in accordance with the voucher subject contract and the trusted voucher heterogeneous token contract in response to an asset acquisition event.

In one possible implementation, the plaintext information includes an asset recovery token; the verifiable description, comprising: a digital asset trusted credential attestation; wherein the plaintext information is encrypted by an issuer public key, and the encrypted plaintext information is located in a digital asset trusted voucher certificate;

the device, still include: configuring an asset retrieval token module;

the configured asset recovery token module is further configured to:

and configuring the asset recovery token according to the recovery token contract.

In one possible implementation manner, the apparatus further includes: a locking module;

the locking module is further configured to:

In one possible implementation, the verification module 73 is further configured to:

decrypting the verifiable description to obtain a verification public key;

determining whether the check public key is the same as the user public key;

uploading the second plaintext information to the recovery token contract;

In one possible implementation manner, the apparatus further includes: a determining module;

the determination module is further configured to:

in response to that the digital asset is in a locked state, acquiring a standby account address in the information of the original account by using a blockchain, and determining whether the standby account address is the same as a sending address corresponding to the verifiable description by using the blockchain;

In one possible implementation manner, the apparatus further includes: a clearing module;

the purge module is further configured to:

For convenience of description, the above devices are described as being divided into various modules by functions, which are described separately. Of course, the functionality of the various modules may be implemented in the same one or more software and/or hardware implementations as the present application.

The apparatus in the foregoing embodiment is used to implement the method for retrieving a corresponding digital asset in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiment, which are not described herein again.

Based on the same inventive concept, corresponding to the method of any of the above embodiments, the present application further provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and running on the processor, and when the processor executes the computer program, the method for retrieving the digital asset according to any of the above embodiments is implemented.

Fig. 8 is a schematic diagram illustrating a more specific hardware structure of an electronic device according to this embodiment, where the device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.

The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static Memory device, a dynamic Memory device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.

The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, bluetooth and the like).

Bus 1050 includes a path that transfers information between various components of the device, such as processor 1010, memory 1020, input/output interface 1030, and communication interface 1040.

It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only the components necessary to implement the embodiments of the present disclosure, and need not include all of the components shown in the figures.

The electronic device of the foregoing embodiment is used to implement the method for retrieving a corresponding digital asset in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiment, which are not described herein again.

Based on the same inventive concept, corresponding to any of the above-mentioned embodiments, the present application further provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method for digital asset recovery as described in any of the above embodiments.

Computer-readable media of the present embodiments, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device.

The storage medium of the above embodiments stores computer instructions for causing the computer to execute the method for retrieving a digital asset as described in any of the above embodiments, and has the beneficial effects of corresponding method embodiments, which are not described herein again.

Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the context of the present application, features from the above embodiments or from different embodiments may also be combined, steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of brevity.

In addition, well-known power/ground connections to Integrated Circuit (IC) chips and other components may or may not be shown in the provided figures for simplicity of illustration and discussion, and so as not to obscure the embodiments of the application. Furthermore, devices may be shown in block diagram form in order to avoid obscuring embodiments of the application, and this also takes into account the fact that specifics with respect to implementation of such block diagram devices are highly dependent upon the platform within which the embodiments of the application are to be implemented (i.e., specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the application, it should be apparent to one skilled in the art that the embodiments of the application can be practiced without, or with variation of, these specific details. Accordingly, the description is to be regarded as illustrative instead of restrictive.

While the present application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those skilled in the art in light of the foregoing description. For example, other memory architectures, such as Dynamic RAM (DRAM), may use the discussed embodiments.

The present embodiments are intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of the embodiments of the present application are intended to be included within the scope of the present application.

Claims

1. A method for digital asset recovery, comprising:

verifying whether the verifiable description is correct;

2. The method of claim 1, further comprising, prior to said issuing a digital asset trusted voucher in response to an asset acquisition event:

3. The method of claim 2, further comprising:

4. The method of claim 2, wherein issuing a digital asset trusted voucher in response to an asset acquisition event further comprises:

5. The method of claim 2, wherein the plaintext information comprises an asset recovery token; the verifiable description, comprising: a digital asset trusted voucher certification; wherein the plaintext information is encrypted by an issuer public key and the encrypted plaintext information is located in a digital asset trusted credential attestation;

the method further comprises the following steps:

configuring the asset recovery token according to the recovery token contract.

6. The method of claim 2, further comprising:

responding to an asset retrieval request, and receiving the encrypted plaintext information uploaded by the standby account through the block link;

7. The method of claim 1, wherein said verifying whether said verifiable description is correct further comprises:

decrypting the verifiable description to obtain a verification public key;

determining whether the check public key is the same as the user public key;

8. The method according to claim 1, wherein said decrypting said first plaintext information to verify that said first plaintext information is correct, further comprises:

uploading the second plaintext information to the recovery token contract;

9. The method of claim 6, prior to said verifying whether said first plaintext information is correct, further comprising:

10. The method of claim 1, further comprising, after sending the digital asset to the alternate account according to the first plaintext information if the plaintext information is correct:

11. An apparatus for digital asset recovery, comprising:

an issuance module configured to issue a digital asset trusted voucher in response to an asset acquisition event;

the verification module is configured to decrypt the first plaintext information and verify whether the first plaintext information is correct if the verifiable description is correct;

12. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1 to 10 when executing the program.

13. A non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1 to 10.