CN113743921A

Movatterモバイル変換

Info

Publication number: CN113743921A
Application number: CN202111056495.6A
Authority: CN
Inventors: 胡志鹏; 王挺; 顾费勇; 曹崇瑞; 李刚锐; 胡志敏
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2021-09-09
Filing date: 2021-09-09
Publication date: 2021-12-03
Anticipated expiration: 2041-09-09
Also published as: CN113743921B

Abstract

The application provides a method, a device, equipment and a storage medium for processing digital assets, and relates to the technical field of block chains. The method comprises the following steps: receiving an asset creating request sent by an asset issuer; judging whether the asset issuer has the authority of issuing the target certificate corresponding to the target certificate type or not according to the identity of the asset issuer and the certificate type information corresponding to the asset issuer; if so, creating a target digital asset for the asset holder according to the identity of the asset holder and the digital asset metadata; the method further includes sending information of the target digital asset to the asset issuer to cause the asset issuer to generate a verifiable statement of the target digital asset based on the information of the target digital asset and sending the verifiable statement of the target digital asset to the asset owner. Compared with the prior art, the problem that the issuer has no authentication mechanism, thereby causing the NFT to be abused or misissued is avoided.

Description

Digital asset processing method, device, equipment and storage medium

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a method, an apparatus, a device, and a storage medium for processing a digital asset.

Background

Non-homogeneous tokens (NFTs) are heterogeneous digital assets and can be applied to scenes such as tickets, cards, virtual objects, and the like.

In the existing scenario, an NFT asset system generally includes several participants, namely, a publisher and a holder, where the publisher may distribute digital assets by issuing a Verifiable statement (VC) to each holder, and then the holder may use its own digital assets by using its own VC, and the publisher may also revoke the VC.

But the issuer reliability of NFT assets in the prior art is not sufficient: any issuer can issue NFT at will, and there is no authentication mechanism for the issuer, which results in NFT being possibly abused or misissued.

Disclosure of Invention

The present application aims to provide a method, an apparatus, a device, and a storage medium for processing a digital asset, so as to solve the problem that an issuer in the prior art does not have an authentication mechanism, so that NFT may be abused or misissued.

In order to achieve the above purpose, the technical solutions adopted in the embodiments of the present application are as follows:

in a first aspect, an embodiment of the present application provides a method for processing a digital asset, which is applied to a blockchain platform, and the method includes:

receiving an asset creation request sent by an asset issuer, the asset creation request comprising: target credential type, identity of asset holder, digital asset metadata;

judging whether the asset issuer has the authority of issuing the target certificate corresponding to the target certificate type or not according to the identity of the asset issuer and the certificate type information corresponding to the asset issuer;

if so, creating a target digital asset for the asset holder according to the identity of the asset holder and the digital asset metadata;

transmitting information of the target digital asset to the asset issuer to cause the asset issuer to generate a verifiable statement of the target digital asset based on the information of the target digital asset and to transmit the verifiable statement of the target digital asset to the asset owner.

Optionally, the determining whether the asset issuer has the right to issue the target credential corresponding to the target credential type includes:

and adopting an asset issuer contract to judge whether the asset issuer has the authority of issuing the target certificate corresponding to the target certificate type.

Optionally, the creating a target digital asset for the asset holder according to the identity of the asset holder and the digital asset metadata comprises:

creating a target digital asset for the asset holder in a non-homogeneous token contract based on the asset holder's identity and the digital asset metadata.

Optionally, after determining whether the asset issuer has the right to issue the target credential corresponding to the target credential type according to the identity of the asset issuer and the credential type information corresponding to the asset issuer, the method further includes:

if not, an asset creation failure indication is returned to the asset issuer.

Optionally, the determining, according to the identity of the asset issuer and the credential type information corresponding to the asset issuer, whether the asset issuer has a right to issue a target credential corresponding to the target credential type includes:

and calling an interface of a preset asset issuer contract to verify whether the identity of the asset issuer is a registered issuer or not by adopting the asset issuer contract and whether the asset issuer has the authority of issuing the target certificate or not.

and judging whether the asset issuer has the authority of issuing the target certificate or not according to the identity of the asset issuer and the certificate type information corresponding to the asset issuer.

creating the target digital asset for the asset holder based on the asset issuer's identification, the target credential type, and the digital asset metadata;

associating the target digital asset to the asset issuer.

Optionally, the method further comprises:

and storing the target digital assets into a preset digital asset array.

Optionally, the method further comprises:

receiving a query request sent by a client of the asset holder, wherein the query request comprises: a verifiable statement of the target digital asset;

querying, via the asset issuer contract, whether the owning user of the target digital asset comprises the asset owner.

Optionally, the method further comprises:

receiving an asset transfer request sent by a client of the asset holder, wherein the asset transfer request comprises address information of a target user and the number of the target digital asset; the number of the target digital asset is the number of the client side sent by the asset issuer to the asset holder;

modifying the information of the holding user of the target digital asset into the information of the target user so as to transfer the target digital asset from the asset holder to the target user.

Optionally, the method further comprises:

receiving an asset use request of the asset holder; the asset use request comprises a verifiable expression corresponding to the asset holder; the verifiable expression is information obtained by a client of the asset holder adopting a private key of the asset holder to sign the verifiable statement;

sending a verifiable representation of the asset holder to the asset validator;

receiving a first authentication request sent by an asset authenticator, the first authentication request comprising: an identification of the asset holder; the first verification request is a request sent by the asset verification party when the verifiable expression corresponding to the asset holding party is obtained;

acquiring a public key of the asset holder according to the first verification request;

and returning the public key of the asset holder to the asset verifier so that the asset verifier adopts the public key of the asset holder to carry out signature verification on the verifiable expression.

Optionally, after returning the public key of the asset holder to the asset verifier so that the asset verifier adopts the public key of the asset holder to sign and verify the verifiable representation, the method further includes:

after the signature verification passes, acquiring a verification result of the asset issuer to the asset holder; wherein the verification result is a result of the asset issuer determining whether a holding user of an asset includes the asset holder through a non-homogeneous token contract.

Optionally, after obtaining the verification result of the asset issuer to the asset holder after the signature verification passes, the method further includes:

if the verification result is passed, determining that the verifiable expression corresponding to the asset issuer is verified successfully;

receiving a second authentication request sent by an asset authenticator, the second authentication request comprising: a verifiable statement corresponding to the asset holder; the second verification request is a request sent by the asset verification party when the verifiable expression corresponding to the asset holding party is verified;

acquiring a public key of the asset issuer according to the second verification request;

and returning the public key of the asset issuer to the asset verifier so that the asset verifier adopts the public key of the asset issuer to carry out signature verification on the verifiable statement.

Optionally, the obtaining the public key of the asset holder according to the first authentication request includes:

according to the identifier of the asset holder, adopting a preset query contract to query an identifier document of the asset holder, wherein the identifier document comprises: the asset holder's public key.

Optionally, the verifiable statement includes: an identity of the asset issuer; the obtaining the public key of the asset issuer according to the second verification request includes:

according to the identity of the asset issuer, querying an identification document of the asset issuer by adopting a preset query contract, wherein the identification document of the asset issuer comprises: the public key of the asset issuer.

Optionally, the verifiable statement corresponding to the asset holder includes: an identity of the asset issuer; after receiving a second authentication request sent by an asset authenticator, the method further comprises:

inquiring an issuing certificate list of the asset issuer through a preset asset issuer contract according to the identity of the asset issuer;

returning the issue credential list to the asset verifier such that the asset verifier verifies that the issue credential list verifies that the asset issuer is registered and has issue rights for the target credential type;

and if so, determining that the issuing authority passes the verification.

Optionally, the method further comprises:

if any verification result indicates that the verification fails, determining that the asset use request of the asset holder fails.

In a second aspect, another embodiment of the present application provides an apparatus for processing a digital asset, which is applied to a blockchain platform, and the apparatus includes: the device comprises a receiving module, a judging module, a creating module and a sending module, wherein:

the receiving module is used for receiving an asset creating request sent by an asset issuer, and the asset creating request comprises: target credential type, identity of asset holder, digital asset metadata;

the judging module is used for judging whether the asset issuer has the authority of issuing the target certificate corresponding to the target certificate type according to the identity of the asset issuer and the certificate type information corresponding to the asset issuer;

the creating module is used for creating a target digital asset for the asset holder according to the identity of the asset holder and the digital asset metadata if the target digital asset is owned by the asset holder;

the sending module is used for sending the information of the target digital asset to the asset issuer so that the asset issuer can generate a verifiable statement of the target digital asset according to the information of the target digital asset and send the verifiable statement of the target digital asset to the asset owner.

Optionally, the determining module is specifically configured to determine, by using an asset issuer contract, whether the asset issuer has an authority to issue a target credential corresponding to the target credential type.

Optionally, the creating module is specifically configured to create a target digital asset for the asset holder in a non-homogeneous token contract based on the identity of the asset holder and the digital asset metadata.

Optionally, the sending module is specifically configured to return an asset creation failure indication to the asset issuer if the asset creation failure indication is not received.

Optionally, the determining module is specifically configured to invoke an interface of a preset asset issuer contract, so as to verify whether the identity of the asset issuer is a registered issuer by using the asset issuer contract, and whether the asset issuer has a right to issue the target credential.

Optionally, the determining module is specifically configured to determine whether the asset issuer has the authority to issue the target credential according to the identity of the asset issuer and the credential type information corresponding to the asset issuer.

Optionally, the apparatus further comprises: an association module, wherein:

the creating module is specifically configured to create the target digital asset for the asset holder according to the identification of the asset issuer, the target credential type, and the digital asset metadata;

the association module is to associate the target digital asset to the asset issuer.

Optionally, the apparatus further comprises: and the storage module is used for storing the target digital assets into a preset digital asset array.

Optionally, the apparatus further comprises: a query module, wherein:

the receiving module is specifically configured to receive an inquiry request sent by a client of the asset holder, where the inquiry request includes: a verifiable statement of the target digital asset;

the query module is used for querying whether the holding user of the target digital asset comprises the asset holding party through the asset issuer contract.

Optionally, the apparatus further comprises: a transfer module, wherein:

the receiving module is specifically used for receiving an asset transfer request sent by a client of the asset holder, wherein the asset transfer request comprises address information of a target user and the number of the target digital asset; the number of the target digital asset is the number of the client side sent by the asset issuer to the asset holder;

the transfer module is used for modifying the information of the holding user of the target digital asset into the information of the target user so as to transfer the target digital asset from the asset holding party to the target user.

Optionally, the apparatus further comprises an obtaining module, wherein:

the receiving module is specifically used for receiving an asset use request of the asset holder; the asset use request comprises a verifiable expression corresponding to the asset holder; the verifiable expression is information obtained by a client of the asset holder adopting a private key of the asset holder to sign the verifiable statement;

the sending module is specifically used for sending the verifiable representation of the asset holder to the asset verifier;

the receiving module is specifically configured to receive a first verification request sent by an asset verifier, where the first verification request includes: an identification of the asset holder; the first verification request is a request sent by the asset verification party when the verifiable expression corresponding to the asset holding party is obtained;

the acquisition module is used for acquiring the public key of the asset holder according to the first verification request;

the sending module is specifically configured to return the public key of the asset holder to the asset verifier, so that the asset verifier performs signature verification on the verifiable expression by using the public key of the asset holder.

Optionally, the obtaining module is specifically configured to obtain a verification result of the asset issuer to the asset holder after the signature verification passes; wherein the verification result is a result of the asset issuer determining whether a holding user of an asset includes the asset holder through a non-homogeneous token contract.

Optionally, the apparatus further comprises: the determining module is used for determining that the verifiable expression corresponding to the asset issuer is verified successfully if the verification result is passed;

the receiving module is specifically configured to receive a second verification request sent by an asset verifier, where the second verification request includes: a verifiable statement corresponding to the asset holder; the second verification request is a request sent by the asset verification party when the verifiable expression corresponding to the asset holding party is verified;

the obtaining module is specifically configured to obtain the public key of the asset issuer according to the second verification request;

the sending module is specifically configured to return the public key of the asset issuer to the asset verifier, so that the asset verifier performs signature verification on the verifiable statement by using the public key of the asset issuer.

Optionally, the query module is specifically configured to query, according to the identifier of the asset holder, an identifier document of the asset holder in a preset query contract, where the identifier document includes: the asset holder's public key.

Optionally, the query module is specifically configured to query, according to the identity of the asset issuer, an identification document of the asset issuer by using a preset query contract, where the identification document of the asset issuer includes: the public key of the asset issuer.

Optionally, the query module is specifically configured to query, according to the identity of the asset issuer, an issuance certificate list of the asset issuer through a preset asset issuer contract;

the sending module is specifically configured to return the issue credential list to the asset verifier, so that the asset verifier verifies whether the issue credential list verifies that the asset issuer is registered and has an issue right of the target credential type;

the determining module is specifically configured to determine that the issuing authority passes verification if the issuing authority passes verification.

Optionally, the determining module is specifically configured to determine that the asset use request of the asset holder fails if any of the verification results indicates a verification failure.

In a third aspect, another embodiment of the present application provides a device for processing a digital asset, including: a processor, a storage medium and a bus, the storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium communicating via the bus when a processing device of a digital asset is operating, the processor executing the machine-readable instructions to perform the steps of the method according to any one of the first aspect.

In a fourth aspect, another embodiment of the present application provides a storage medium having a computer program stored thereon, where the computer program is executed by a processor to perform the steps of the method according to any one of the above first aspects.

The beneficial effect of this application is: by adopting the method for processing the digital assets, the asset issuer needs to verify whether the asset issuer has the authority of issuing the target certificate before creating the target digital assets, namely, whether the certificate type information corresponding to the asset issuer comprises the target certificate type is determined, if yes, the current asset issuer is determined to have the authority of issuing the target certificate, the target digital assets are created for the asset holder according to the identity of the asset holder and the digital asset metadata, the target digital asset information of the creation number is sent to the asset issuer, so that the asset issuer generates the verifiable statement of the target digital assets according to the information of the target digital assets, and the verifiable statement of the target digital assets is sent to the client of the asset holder, thereby ensuring that the asset issuer needs to be fully authenticated and judged before issuing, and the digital resource can be issued after the digital resource is confirmed to have the issuing authority, thereby preventing the digital resource from being abused or wrongly issued due to insufficient authentication mechanism and ensuring the issuing safety of the digital resource.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.

FIG. 1 is a schematic flow chart diagram illustrating a method for processing digital assets according to an embodiment of the present application;

FIG. 2 is a schematic flow chart diagram illustrating a method for processing digital assets according to another embodiment of the present application;

FIG. 3 is a schematic flow chart diagram illustrating a method for processing digital assets according to another embodiment of the present application;

FIG. 4 is a schematic flow chart diagram illustrating a method for processing digital assets according to another embodiment of the present application;

FIG. 5 is a schematic flow chart diagram illustrating a method for processing digital assets according to another embodiment of the present application;

FIG. 6 is a schematic diagram of a digital asset processing device according to an embodiment of the present application;

FIG. 7 is a schematic block diagram of a digital asset processing device according to another embodiment of the present application;

fig. 8 is a schematic structural diagram of a digital asset processing device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments.

The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.

Additionally, the flowcharts used in this application illustrate operations implemented according to some embodiments of the present application. It should be understood that the operations of the flow diagrams may be performed out of order, and steps without logical context may be performed in reverse order or simultaneously. One skilled in the art, under the guidance of this application, may add one or more other operations to, or remove one or more operations from, the flowchart.

For the purpose of facilitating an understanding of the embodiments of the present application, the following partial terms related to the present application are explained:

distributed digital identity: distributed identities are more than people, including organizations, and even items in the future. These people, organizations, and items simply do not rely on an original centralized authority, cannot be removed or deleted, and are life-long identities.

Distributed Identities (DID): the digital identifier is a decentralized verifiable digital identifier and has the characteristics of distribution, autonomous controllability, cross-chain multiplexing and the like. The entity can autonomously complete the registration, parsing, updating or revocation operations of the DID. The DID is specifically resolved into a DID Document that includes the unique id of the DID, a list of public keys and detailed information of the public keys (holder, encryption algorithm, key status, etc.), and other attribute descriptions of the DID holder.

Verifiable declaration (VC): a specification is provided to describe certain attributes that an entity has to enable evidence-based trust. The DID holder, through a verifiable claim, can prove to other entities (individuals, organizations, things, etc.) that certain attributes of himself are trustworthy. Meanwhile, by combining the cryptographic technologies such as digital signature and zero knowledge proof, the statement can be safer and more credible, and the privacy of the user can be further guaranteed against being invaded.

Verifiable Presentation (VP): is a tamper-resistant description that comes from one or more verifiable credentials and is cryptographically signed by the principal disclosing the credentials. The DID identity is presented in VP, whether directly using the verifiable credential or constructing the identity from data obtained from the verifiable credential.

Non-homogeneous tokens (Non-fungal Token, NFT): the token is generally a digital asset issued by a developer on an ethernet workshop platform according to ERC721 standard/protocol, and has the characteristics of inseparability, irreplaceability and uniqueness, in short, the token issued by using the ERC721 standard/protocol is called NFT, and can be applied to scenes such as tickets, cards, virtual articles and the like.

The following explains a method for processing a digital asset provided by the embodiments of the present application with reference to a plurality of specific application examples. The digital assets targeted by the embodiments of the present application may be NFT assets, for example, and may also be referred to as digital tokens and the like. Fig. 1 is a schematic flowchart of a processing method for a digital asset, which is provided in an embodiment of the present application and is applied to a blockchain platform, as shown in fig. 1, the method includes:

s101: an asset creation request sent by an asset issuer is received.

The asset creation request includes: target credential type, identity of the asset holder, digital asset metadata. The asset creation request may be, for example, a transaction request to create a digital asset, where the target credential type, the identification information of the asset holder, and the digital asset metadata are input parameters of the transaction request.

In some possible embodiments, the asset issuer is a physical device having user data and capable of issuing VC, such as a server or a client of an organization or a university, a bank, a company, and the like, and the device type and the device form of a specific asset issuer can be flexibly adjusted according to the user needs, and are not limited to the above embodiments.

S102: and judging whether the asset issuer has the authority of issuing the target certificate corresponding to the target certificate type or not according to the identity of the asset issuer and the certificate type information corresponding to the asset issuer.

Each asset issuer corresponds to one or more issuing authorities of the voucher types, whether the current asset issuer has the authority of issuing the target voucher of the target voucher type or not needs to be verified before issuing, if yes, the subsequent issuing steps are continuously executed, and if not, an asset creating failure indication of the asset issuer is returned.

In one embodiment of the present application, the manner of determining whether the asset issuer has the right may be, for example: and judging whether the asset issuer has the authority of issuing the target voucher corresponding to the target voucher type by adopting the asset issuer contract.

S103: if so, a target digital asset is created for the asset holder based on the asset holder's identification and the digital asset metadata.

For example, in some possible embodiments, the Identity of the asset holder may be, for example, the block chain address information of the asset holder, such as DID information, or the Identity Document (ID) information of the asset holder, etc., and it should be understood that the above embodiments are only exemplary, and the content included in the Identity of a specific asset holder may be flexibly adjusted according to the user's needs, and is not limited to the content provided in the above embodiments.

In one embodiment of the present application, the manner in which a target digital asset is created for an asset holder may be, for example: a target digital asset is created for the asset holder in the non-homogenous token contract based on the asset holder's identity and the digital asset metadata.

S104: information of the target digital asset is sent to the asset issuer.

After receiving the information of the target digital asset, the asset issuer enables the asset issuer to generate a verifiable statement (VC) of the target digital asset according to the information of the target digital asset and sends the verifiable statement (VC) of the target digital asset to the asset holder, for example, sends the VC of the target digital asset to the client of the asset holder, so as to complete the issuance of the VC, that is, complete the issuance of the digital asset.

Each asset holder may or may not own one or more VCs, which is determined according to the actual situation of each asset holder, and the present application is not limited thereto.

By adopting the method for processing the digital assets provided by the application, before the asset issuer creates the target digital assets, whether the asset issuer has the authority of issuing the target certificates is verified, namely whether the certificate type information corresponding to the asset issuer comprises the target certificate type is determined, if yes, the current asset issuer is determined to have the authority of issuing the target certificates, the target digital assets are created for the asset holder according to the identity of the asset holder and the digital asset metadata, the created information of the target digital assets is sent to the asset issuer, so that the asset issuer generates the verifiable statement of the target digital assets according to the information of the target digital assets and sends the verifiable statement of the target digital assets to the asset holder, thereby ensuring that the asset issuer needs to be fully authenticated and judged before issuing, and the digital resource can be issued after the digital resource is confirmed to have the issuing authority, thereby preventing the digital resource from being abused or mistakenly issued due to insufficient authentication mechanism and ensuring the issuing safety of the digital resource.

In one embodiment of the present application, prior to S101, the system first needs to deploy relevant contracts of the DID environment on the blockchain, which may include, for example, Issuer contracts issue, credential topic contracts credentialesubject and DID contracts, etc., which are used to store DID verifiable data. It is the basic condition of DID verifiable credentials, and the functions of contracts include the functions of DID registration and query, issuer registration and query, and credential subject registration and query, etc., it should be understood that the above functions are only exemplary descriptions, and the functions of specific contracts can be flexibly adjusted according to the needs of users, and are not limited to the above embodiments.

For example, in some possible embodiments, before S101, the asset issuer needs to register as an issuer in advance in a trusted DID organization, and after the DID approves the credential body that can issue NET assets of a certain credential type, and determines that it is the asset issuer having the authority to issue the credential type, obtain the DID unique number and the DID document corresponding to the asset issuer; it should be understood that only asset issuers having the right to issue the voucher type can issue and create digital assets of the voucher type.

For example, in some possible embodiments, one of the collaborators a in the music section host in the city a, applying for the ticket NFT issuer of the music section, needs to register the issuer of the music section in the DID organization in advance, if the registration is successful, the asset issuer corresponding to the collaborator a may serve as the ticket NFT issuer of the music section, and the collaborator a may create the NFT ticket of the music section for the user and issue the VC to each user.

In other possible embodiments, the asset issuer may be, for example, a multi-level issuing architecture, which is exemplified by a three-level issuing architecture, under which a root asset issuer may be authorized and registered as a primary asset issuer, and a primary asset issuer may be authorized and registered as a common asset issuer, which is an NFT asset issuer. The primary asset issuer may register as a common asset issuer (NFT asset issuer) and issue a specified credential topic after agreement is reached between the primary asset issuers through a variety of signature schemes, such as group signature, ring signature, multiple signatures, and the like. Eventually, information about the generic asset issuer, which may include, for example, issuer blockchain address issuerAddr information, and issuable credential type vcType information, is saved to the issuer contract.

In an embodiment of the present application, the method for verifying whether the asset Issuer has the authority to issue the target credential may be, for example, invoking an interface of a preset asset Issuer contract to verify whether the identifier of the asset Issuer is a registered Issuer by using the asset Issuer contract, and whether the asset Issuer has the authority to issue the target credential.

In an embodiment of the present application, the identity of the asset holder may be, for example, a DID identifier of the asset holder, that is, the blockchain address information of the asset holder, and before the asset holder creates the target digital asset, the identity of the asset holder needs to be verified, that is, whether the blockchain address information of the asset holder is valid is obtained and verified.

In some possible embodiments, the identity of the asset holder cannot be null, and the way to determine whether the asset issuer has the right to issue the target credential may be, for example: if the identity of the asset holder is not null, judging whether the asset issuer has the authority of issuing the target certificate or not according to the identity of the asset issuer and the certificate type information corresponding to the asset issuer; if the identity of the asset holder is null, it is not necessary to determine whether the asset issuer has the right to issue the target credential, and a creation failure indication is directly returned to the asset issuer, or a prompt for supplementing the identity of the asset holder may be returned to the asset issuer, so that the asset issuer supplements the identity of the asset holder.

Optionally, on the basis of the foregoing embodiments, the present application may further provide a method for processing a digital asset, and an implementation process of creating a target digital asset for the asset holder in the foregoing method is described as follows with reference to the accompanying drawings. Fig. 2 is a schematic flowchart of a method for processing a digital asset according to another embodiment of the present application, and as shown in fig. 2, S103 may include:

s105: a target digital asset is created for the asset holder based on the identity of the asset issuer, the target voucher type, and the digital asset metadata.

In one embodiment of the present application, the manner in which a target digital asset is created for an asset holder may be, for example: newly establishing a unique NFT label, namely newTokenId, in the NFT contract, and setting digital asset data such as NFT data, wherein the NFT data can comprise a token number, information of an asset issuer, a voucher type (vcType), an issuing time (issurance date) of a target digital asset and NFT metaData (metaData), for example; the created target digital assets can also be stored into a preset digital asset Array such as an nft Array; wherein all created digital assets are stored in the preset digital asset array.

S106: the target digital asset is associated with an asset issuer.

After the NFT is successfully created, the asset issuer can take all the information of the current NFT and perform VC distribution, thus completing the distribution of the target digital asset.

In other possible embodiments, after the target digital asset is successfully created, the target digital asset is further required to be saved in a preset digital asset array, wherein all NFT information is saved in the preset digital asset array.

In addition, in one embodiment of the present application, after the target digital asset is created, the contract address of the asset issuer is initialized and saved into a digital asset contract, such as an NFT contract, for verifying issuer information of the target digital asset, i.e., asset issuer information, and creating an event that the asset transfer is successful when the target digital asset is used or operated.

For example, in some possible embodiments, the method may further include, for example: receiving a query request sent by a client of an asset holder, wherein the query request comprises: a verifiable statement of the target digital asset; querying, via an asset issuer contract, whether a holding user of a target digital asset includes an asset holder; that is, the asset holder holds the VC, that is, in order to hold the target digital asset, the asset holder may determine whether the holding user of the current target digital asset includes himself by looking up the VC and looking up owner information, that is, holding user information, of the target digital asset.

Optionally, on the basis of the foregoing embodiments, the embodiments of the present application may further provide a method for processing a digital asset, and an implementation process of the method is described as follows with reference to the accompanying drawings. Fig. 3 is a schematic flowchart of a method for processing a digital asset according to another embodiment of the present application, where as shown in fig. 3, the method may further include:

s107: an asset transfer request sent by a client of an asset holder is received.

The asset transfer request comprises address information of a target user and the number of a target digital asset; the asset transfer request is that the target digital asset of the asset holder is transferred to the target user from the asset holder, the target user is the user to receive the transferred asset, and the number of the target digital asset is the number sent to the client of the asset holder by the asset issuer, namely the NFT number.

S108: and modifying the information of the holding user of the target digital asset into the information of the target user so as to transfer the target digital asset from the asset holding party to the target user.

In the embodiment of the application, whether the token of the current target digital asset is held by the asset holder which initiates the asset transfer request currently needs To be judged, if not, the transaction is directly returned To fail, if yes, S108 is executed, the change of the Owner of the target digital asset is completed, namely, the token Id To Owner is modified, and the token holder with the asset holder is changed into the target user; this completes the token transfer from the asset holder to the target user.

Optionally, on the basis of the foregoing embodiments, the embodiments of the present application may further provide a method for processing a digital asset, and an implementation process of the method is described as follows with reference to the accompanying drawings. Fig. 4 is a schematic flowchart of a method for processing a digital asset according to another embodiment of the present application, where as shown in fig. 4, the method further includes:

s109: an asset use request of an asset holder is received.

Wherein, the asset use request comprises a verifiable expression corresponding to the asset holder; a client expressed as an asset holder can verify information obtained by signing a verifiable statement with the asset holder's private key.

S110: sending a verifiable representation of the asset holder to an asset validator.

After receiving the asset use request of the asset holder, the blockchain platform forwards the verifiable expression of the asset holder in the asset use request to the asset verifier.

S111: a first authentication request sent by an asset authenticator is received.

The first authentication request includes: an identity of the asset holder; the first verification request is a request sent by the asset verification party under the condition that the verifiable expression corresponding to the asset holder is obtained, and the verifiable expression is information obtained by the client of the asset holder signing the verifiable statement by using the private key of the asset holder.

In one embodiment of the present application, the VC is signed by a private key, for example, by using a Secp256k1 elliptic curve signature algorithm to generate proof information.

Wherein, the proof information includes: self-signed data (signatureValue) of the property holder, and identity of the property holder: and did information (verificationMethod).

S112: and acquiring the public key of the asset holder according to the first verification request.

In an embodiment of the present application, for example, a preset query contract may be adopted to query an identification document of an asset holder according to an identity of the asset holder, where the identification document may include, for example: the public key of the property holder, wherein the identification document of the property holder may be, for example, a DID document of the property holder, and the preset query contract may be, for example, a block chain DID contract.

S113: the asset holder's public key is returned to the asset verifier.

Such that the asset verifier signature verifies the verifiable representation using the public key of the asset holder.

The asset verifying party acquires the asset owner self-signature data in the VP to verify, and inquires whether the asset owner corresponding to the current self-signature data is correct or not.

In an embodiment of the present application, after the asset verifier verifies the verifiable representation, the asset verifier needs to obtain the verification result of the asset issuer on the asset holder to determine whether the asset holder corresponding to the current self-signature data is the holder of the current nft. Wherein the verification result is a result that the asset issuer determines whether the holding user of the asset includes the asset holder through the NFT contract.

For example, the asset issuer may verify the asset holder by: and after the asset holder corresponding to the current self-signature data passes verification, inquiring the information of the current NFT holder in the NFT contract through the did information of the asset holder, and determining whether the current asset holder self-signature data is the current NFT holder.

In some possible embodiments, the way to verify whether the owner of the asset corresponding to the current self-signed data is the owner of the current nft may be, for example: inquiring address information of a current NFT holder in an NFT contract, comparing a block chain address corresponding to the did information of the current self-signed user according to the did information of the asset holder, judging whether the address is the same as the address of the current NFT holder, if so, determining that the verification is passed, continuing to perform the next VC verification, and otherwise, returning VP verification failure.

The method for verifying the self-signature of the asset holder avoids the risk of embezzlement and abuse of NFT by others, and overcomes the defect that the asset holder is lack of verification in the prior art by adding a certification mechanism of the asset holder.

Optionally, on the basis of the foregoing embodiments, the embodiments of the present application may further provide a method for processing a digital asset, and an implementation process of the method is described as follows with reference to the accompanying drawings. Fig. 5 is a schematic flowchart of a method for processing a digital asset according to another embodiment of the present application, and as shown in fig. 5, after S113, the method further includes:

s114: and if the verification result is passed, determining that the verifiable expression corresponding to the asset issuer is verified successfully.

And if the verification result of the asset issuer to the asset holder is verification pass, determining that the VP of the asset issuer passes the verification.

S115: a second authentication request sent by the asset authenticator is received.

Wherein the second authentication request comprises: a verifiable statement corresponding to the asset-holder; and the second verification request is a request sent by the asset verification party when the verifiable expression obtained by the asset verification party and corresponding to the asset holder passes verification.

S116: and acquiring the public key of the asset issuer according to the second verification request.

In some possible embodiments, the specific way to obtain the public key of the asset issuer may be, for example: the identity of the asset issuer may be obtained from a verifiable claim corresponding to the asset holder.

And then, according to the identity of the asset issuer, querying an identification document of the asset issuer by adopting a preset query contract, wherein the identification document of the asset issuer comprises the following steps: the public key of the asset issuer.

In one possible embodiment of the present application, the identity of the asset issuer may be, for example, DID information of the asset issuer, the identification document of the asset issuer may be, for example, a DID document of the asset issuer, and the preset query contract may be, for example, a blockchain DID contract.

S117: the public key of the asset issuer is returned to the asset verifier.

And if the asset issuer is indeed the nft asset issuer, and has the authority to issue the current certificate and the signature of the asset issuer is verified successfully, all verification of vp is determined to pass, and the asset verifier can execute the next business operation.

In the embodiment of the application, after the asset verifying party verifies that the public key of the asset issuer passes verification, the asset verifying party continues to query the issue certificate list of the asset issuer through a preset asset issuer contract according to the identity of the asset issuer; and returning the issue certificate list to the asset verifier so that the asset verifier verifies whether the asset issuer is registered and has an issue right of the target certificate type according to the issue certificate list.

If yes, the issuing verification is confirmed to be passed, after the verification is passed, the asset verifying party continuously verifies the VC and verifies the validity of the signature of the asset issuing party, and if the asset issuing party is registered, has the issuing authority of the target certificate type and successfully verifies the signature of the asset verifying party, all verification is confirmed to be passed.

By adopting the processing method of the digital assets provided by the application, when the asset issuer issues the target digital assets, the asset issuer is verified, when it is determined that the current asset issuer can issue the target digital assets, the subsequent issuing steps are executed, when the asset holder uses or transfers the target digital assets, the ownership right of the asset holder is also verified, when it is determined that the asset user or transferor is consistent with the asset holder of the target digital assets to be used or transferred currently, the subsequent transferring or using steps are executed, so that the risk of excessive distribution or misdistribution or embezzlement of NFT is prevented through the setting of the verification mechanism at each step, and the safety of the NFT in the using process is ensured.

The following explains a digital asset processing apparatus provided in the present application with reference to the drawings, where the digital asset processing apparatus can execute any one of the digital asset processing methods shown in fig. 1 to 5, and specific implementation and beneficial effects of the digital asset processing apparatus refer to the above descriptions, and are not described again below.

Fig. 6 is a schematic structural diagram of a digital asset processing apparatus according to an embodiment of the present application, as shown in fig. 6, applied to a blockchain platform, where the apparatus includes: a receivingmodule 201, a judgingmodule 202, a creatingmodule 203 and a sendingmodule 204, wherein:

areceiving module 201, configured to receive an asset creating request sent by an asset issuer, where the asset creating request includes: target credential type, identity of the asset holder, digital asset metadata.

The judgingmodule 202 is configured to judge whether the asset issuer has the authority to issue the target credential corresponding to the target credential type according to the identity of the asset issuer and the credential type information corresponding to the asset issuer.

And a creatingmodule 203 for creating the target digital asset for the asset holder according to the identification of the asset holder and the digital asset metadata if the target digital asset is present.

A sendingmodule 204, configured to send the information of the target digital asset to the asset issuer, so that the asset issuer generates a verifiable statement of the target digital asset according to the information of the target digital asset, and sends the verifiable statement of the target digital asset to the asset owner.

Optionally, the determiningmodule 202 is specifically configured to determine, by using an asset issuer contract, whether the asset issuer has an authority to issue a target credential corresponding to the target credential type.

Optionally, the creatingmodule 203 is specifically configured to create a target digital asset for the asset holder in the non-homogeneous token contract based on the identity of the asset holder and the digital asset metadata.

Optionally, the sendingmodule 204 is specifically configured to, if not, return an asset creation failure indication to the asset issuer.

Optionally, the determiningmodule 202 is specifically configured to invoke an interface of a preset asset issuer contract, so as to verify whether the identity of the asset issuer is the registered issuing subject and whether the asset issuer has the authority to issue the target credential.

Optionally, the determiningmodule 202 is specifically configured to determine whether the asset issuer has the authority to issue the target credential according to the identity of the asset issuer and the credential type information corresponding to the asset issuer.

Optionally, on the basis of the above embodiments, the present application may further provide a device for processing a digital asset, and the implementation process of the device shown in fig. 6 is described as follows with reference to the accompanying drawings. Fig. 7 is a schematic structural diagram of a digital asset processing apparatus according to another embodiment of the present application, and as shown in fig. 7, the apparatus further includes: an association module 205, wherein:

the creatingmodule 203 is specifically configured to create a target digital asset for the asset holder according to the identification of the asset issuer, the target voucher type, and the digital asset metadata.

An association module 205 for associating the target digital asset to an asset issuer.

As shown in fig. 7, the apparatus further includes: a saving module 206, configured to save the target digital asset to a preset digital asset array.

As shown in fig. 7, the apparatus further includes: aquery module 207, wherein:

the receivingmodule 201 is specifically configured to receive an inquiry request sent by a client of an asset holder, where the inquiry request includes: a verifiable declaration of a target digital asset.

Aquery module 207 for querying whether the holding users of the target digital assets include asset holders via asset issuer contracts.

As shown in fig. 7, the apparatus further includes: a transfer module 208, wherein:

the receivingmodule 201 is specifically configured to receive an asset transfer request sent by a client of an asset holder, where the asset transfer request includes address information of a target user and a number of a target digital asset; the number of the target digital asset is the number that the asset issuer sends to the asset holder's client.

A transfer module 208 for modifying the information of the holding user of the target digital asset to the information of the target user to transfer the target digital asset from the asset holder to the target user.

As shown in fig. 7, the apparatus further includes: anacquisition module 209, wherein:

areceiving module 201, specifically configured to receive an asset use request of an asset holder; the asset use request comprises a verifiable expression corresponding to the asset holder; a client expressed as an asset holder can verify information obtained by signing a verifiable statement with the asset holder's private key.

The sendingmodule 204 is specifically configured to send the verifiable representation of the asset holder to the asset verifier.

The receivingmodule 201 is specifically configured to receive a first verification request sent by an asset verifier, where the first verification request includes: an identification of the asset holder; the first verification request is a request sent by the asset verification party when the verifiable expression corresponding to the asset holder is obtained.

An obtainingmodule 209 is configured to obtain the public key of the asset holder according to the first authentication request.

The sendingmodule 204 is specifically configured to return the public key of the asset holder to the asset verifier, so that the asset verifier performs signature verification on the verifiable representation by using the public key of the asset holder.

Optionally, the obtainingmodule 209 is specifically configured to obtain a verification result of the asset issuer to the asset holder after the signature verification passes; wherein the verification result is a result of the asset issuer determining whether the holding user of the asset includes the asset holder through the non-homogeneous token contract.

As shown in fig. 7, the apparatus further includes: and the determiningmodule 210 is configured to determine that the verifiable representation corresponding to the asset issuer is verified successfully if the verification result is passed.

The receivingmodule 201 is specifically configured to receive a second verification request sent by an asset verifier, where the second verification request includes: a verifiable statement corresponding to the asset-holder; and the second verification request is a request sent by the asset verification party when the verifiable expression obtained by the asset verification party and corresponding to the asset holder passes verification.

The obtainingmodule 209 is specifically configured to obtain the public key of the asset issuer according to the second verification request.

The sendingmodule 204 is specifically configured to return the public key of the asset issuer to the asset verifier, so that the asset verifier performs signature verification on the verifiable declaration by using the public key of the asset issuer.

Optionally, thequery module 207 is specifically configured to query, in a preset query contract, an identification document of the asset holder according to the identifier of the asset holder, where the identification document includes: the public key of the owner of the asset.

Optionally, thequery module 207 is specifically configured to query, according to the identity of the asset issuer, an identification document of the asset issuer by using a preset query contract, where the identification document of the asset issuer includes: the public key of the asset issuer.

Optionally, thequery module 207 is specifically configured to query the issue credential list of the asset issuer through a preset asset issuer contract according to the identity of the asset issuer.

The sendingmodule 204 is specifically configured to return the issue credential list to the asset verifier, so that the asset verifier verifies whether the issue credential list verifies that the asset verifier has registered and has an issue right of the target credential type.

The determiningmodule 210 is specifically configured to determine that the issuing authority passes the verification if the issuing authority passes the verification.

Optionally, the determiningmodule 210 is specifically configured to determine that the asset use request of the asset holder fails if any of the verification results indicates a verification failure.

The above-mentioned apparatus is used for executing the method provided by the foregoing embodiment, and the implementation principle and technical effect are similar, which are not described herein again.

These above modules may be one or more integrated circuits configured to implement the above methods, such as: one or more Application Specific Integrated Circuits (ASICs), or one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs), etc. For another example, when one of the above modules is implemented in the form of a Processing element scheduler code, the Processing element may be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. For another example, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

Fig. 8 is a schematic structural diagram of a processing device of a digital asset according to an embodiment of the present disclosure, where the processing device of the digital asset may be integrated in a terminal device or a chip of the terminal device.

As shown in fig. 8, the processing apparatus of the digital asset includes: aprocessor 501, astorage medium 502, and abus 503.

Theprocessor 501 is used for storing a program, and theprocessor 501 calls the program stored in thestorage medium 502 to execute the method embodiment corresponding to fig. 1-5. The specific implementation and technical effects are similar, and are not described herein again.

Optionally, the present application also provides a program product, such as a storage medium, on which a computer program is stored, including a program, which, when executed by a processor, performs embodiments corresponding to the above-described method.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is merely a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

The integrated unit implemented in the form of a software functional unit may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to perform some steps of the methods according to the embodiments of the present application. And the aforementioned storage medium includes: a U disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Claims

1. A method for processing digital assets, applied to a blockchain platform, the method comprising:

2. The method of claim 1, wherein said determining whether the asset issuer has authority to issue a target credential corresponding to the target credential type comprises:

3. The method of claim 1, wherein creating a target digital asset for the asset holder based on the asset holder's identity and the digital asset metadata comprises:

4. The method of claim 1, wherein after determining whether the asset issuer has the right to issue the target credential corresponding to the target credential type based on the identity of the asset issuer and the credential type information corresponding to the asset issuer, the method further comprises:

if not, an asset creation failure indication is returned to the asset issuer.

5. The method of claim 1, wherein the determining whether the asset issuer has the authority to issue the target credential corresponding to the target credential type according to the identity of the asset issuer and the credential type information corresponding to the asset issuer comprises:

6. The method of claim 1, wherein the determining whether the asset issuer has the authority to issue the target credential corresponding to the target credential type according to the identity of the asset issuer and the credential type information corresponding to the asset issuer comprises:

7. The method of claim 1, wherein creating a target digital asset for the asset holder based on the asset holder's identity and the digital asset metadata comprises:

associating the target digital asset to the asset issuer.

8. The method of claim 7, wherein the method further comprises:

and storing the target digital assets into a preset digital asset array.

9. The method of claim 1, wherein the method further comprises:

10. The method of claim 1, wherein the method further comprises:

11. The method of claim 1, wherein the method further comprises:

sending a verifiable representation of the asset holder to the asset validator;

12. The method of claim 11, wherein after returning the asset holder's public key to the asset verifier such that the asset verifier signed the verifiable representation with the asset holder's public key, the method further comprises:

13. The method of claim 12, wherein after obtaining the result of the asset issuer's verification of the asset holder after the signature verification passes, the method further comprises:

14. The method of claim 11, wherein said obtaining a public key of the asset holder in accordance with the first authentication request comprises:

15. The method of claim 13, wherein the verifiable assertion comprises: an identity of the asset issuer; the obtaining the public key of the asset issuer according to the second verification request includes:

16. The method of claim 13, wherein the verifiable statement that the property-holder corresponds to comprises: an identity of the asset issuer; after receiving a second authentication request sent by an asset authenticator, the method further comprises:

and if so, determining that the issuing authority passes the verification.

17. The method of any of claims 11-16, wherein the method further comprises:

18. An apparatus for processing digital assets, applied to a blockchain platform, the apparatus comprising: the device comprises a receiving module, a judging module, a creating module and a sending module, wherein:

19. An apparatus for processing digital assets, the apparatus comprising: a processor, a storage medium and a bus, the storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium communicating over the bus when a processing device of the digital asset is operating, the processor executing the machine-readable instructions to perform the method of any of claims 1-14.

20. A storage medium, characterized in that the storage medium has stored thereon a computer program which, when being executed by a processor, performs the method of any of the preceding claims 1-14.