CN115099815A

CN115099815A - Data verification method and block link point

Info

Publication number: CN115099815A
Application number: CN202210669105.0A
Authority: CN
Inventors: 曹圣皎
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-06-14
Filing date: 2022-06-14
Publication date: 2022-09-23

Abstract

A data verification method and a blockchain node, wherein a blockchain is deployed with a first intelligent contract, and the method comprises the following steps: receiving a first transaction, wherein the first transaction calls a first intelligent contract, the first transaction comprises second data, the second data comprises storage position information of the first data and is used for verifying the first data, and the first data is stored in an off-link server; the trusted device is instructed to verify the first data based on the second data by executing the first smart contract invoked by the first transaction.

Description

Data verification method and block link point

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a data verification method and a block chain node.

Background

The Blockchain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the block chain has the characteristics of decentralization, information non-tampering, autonomy and the like, the block chain is also paid more and more attention and is applied by people.

Digital resources, which are generally characterized by irreplaceability, limitation, and the like and are not divisible, can be generated in a block chain based on Non-homogeneous Tokens (NFT) technology. Different block chains may use different NFT protocol standards to generate the digital resource. The current mainstream protocol standards include ERC721, ERC1155, ERC998, and the like. The ERC721 is the most common NFT protocol standard, and under the ERC721 standard, each generated digital resource has a unique identifier, and different digital resources are not replaceable with each other. Under the ERC1155 standard, the resource identification does not correspond to one resource but corresponds to one type of resource, the resources in different types cannot be replaced, different resources in one type of resource are not different and can be replaced mutually, and the quantity of the types of the resources is finite. In the ERC998 standard, digital resources generated based on NFT technology may be bundled or combined with digital resources generated based on the homogenization certification (FT) technology (e.g., ETH currency).

Disclosure of Invention

The invention aims to provide a method for verifying data stored by a metadata service, which ensures the integrity of managed data.

A first aspect of the present specification provides a data verification method, performed by a node of a blockchain, the blockchain being deployed with a first intelligent contract, the method including:

receiving a first transaction, wherein the first transaction calls the first intelligent contract, the first transaction comprises second data, the second data comprises storage position information of the first data and is used for verifying the first data, and the first data is stored in an off-chain server;

instructing a trusted device to verify the first data based on the second data by executing the first smart contract invoked by the first transaction.

In one embodiment, the off-link server is a server of a service party, the contract status of the first intelligent contract includes a balance of a first account, the first account corresponds to the service party, and the account balance of the first account includes a frozen quota corresponding to the first data, and the method further includes: in the case that the verification fails, deducting the frozen amount from the account balance of the first account.

In one embodiment, the method further comprises:

receiving a second transaction before receiving the first transaction, wherein a sending account of the second transaction is a second account of the service party, and the first intelligent contract, the public key comprising the first account and the first quota are called in the second transaction;

and creating the first account corresponding to the public key in the contract state of the first intelligent contract by executing the first intelligent contract called by the second transaction, and transferring the first quota of the second account into the first account.

In one embodiment, the method further comprises:

creating, by executing the first intelligent contract invoked by the second transaction, a frozen account corresponding to the public key in a contract state of the first intelligent contract;

receiving a third transaction after the second transaction is executed, wherein the third transaction invokes the first smart contract, the third transaction comprises the identifier of the first data and the public key, a sending account of the third transaction is the second account, and the third transaction is sent by the server in response to a service request of user equipment, and the service request comprises the identifier of the first data;

adding a frozen credit corresponding to the first data in the balance of the frozen account by executing the first intelligent contract called by the third transaction, the public key being stored in association with the identity of the first data in the contract state of the first intelligent contract.

In one embodiment, the first transaction further includes an identification of the first data and a signature of the second data by the second account, and the method further includes, before instructing a trusted device to verify the first data based on the second data, obtaining the public key based on the identification of the first data, and verifying the signature using the public key.

In one embodiment, the first data is metadata of resource data of a resource on a chain, the first data includes storage location information of the resource data and a hash value of the resource data, and the verifying the first data includes: and checking the resource data according to the storage position information of the resource data and the hash value of the resource data.

In one embodiment, the server further stores fourth data, where the fourth data includes mode information of the first data, the second data further includes fifth data for verifying the fourth data, and the verifying the first data further includes: instructing a trusted device to verify the fourth data based on the fifth data and verifying whether the first data conforms to a pattern indicated in the fourth data by executing the first smart contract invoked by the first transaction.

In one embodiment, a second intelligent contract corresponding to a resource on the chain is deployed in the blockchain, and the identifier of the first data is an account address of the second intelligent contract, the method further comprising:

receiving a fourth transaction invoking the second smart contract, the fourth transaction including the second data and a signature of the second account on the second data;

storing, in a contract state of the second intelligent contract, the second data and the signature of the second account on the second data by executing the second intelligent contract invoked by the fourth transaction.

In one embodiment, the third transaction further comprises sixth data for verifying the fourth data, the sixth data being obtained by the server from the blockchain node, the method further comprising: storing the sixth data in association with the identification of the first data in a contract state of the first intelligent contract by executing the first intelligent contract invoked by the third transaction.

In one embodiment, the method further comprises, before instructing the trusted device to verify the first data based on the second data, obtaining sixth data based on the identity of the first data, and verifying the fifth data using the sixth data.

A second aspect of the present specification provides a blockchain node, the blockchain being deployed with a first intelligent contract, the blockchain node comprising:

a receiving unit, configured to receive a first transaction, where the first transaction invokes the first intelligent contract, the first transaction includes second data, the second data includes storage location information of the first data, and is used to check the first data, and the first data is stored in an off-link server;

an execution unit to instruct a trusted device to verify the first data based on the second data by executing the first smart contract invoked by the first transaction.

A third aspect of the present specification provides a computer readable storage medium having stored thereon a computer program which, when executed on a computer, causes the computer to perform the method of the first aspect.

A fourth aspect of the present specification provides a blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method of the first aspect.

In an embodiment of the present specification, a data hosting service provided by the MSP is recorded by a verification contract, and the MSP is punished by the verification contract when there is a problem with the service provided by the MSP to ensure the correctness and integrity of the hosted data stored in the MSP server. With the solution provided by the embodiments of the present specification, NFT players can be more confident that their collections have not been tampered with. NFT administrators can enjoy careless services provided by MSPs. The MSP can gain revenue by providing such services, enhancing the supervision of the MSP by recording its reputation through blockchains. NFT players do not need to trust either party to maintain the integrity and correctness of the metadata.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without any creative effort.

FIG. 1 illustrates a system architecture diagram in one embodiment;

FIG. 2 is a flow diagram of a method of casting NFT resources in one embodiment of the present description;

FIG. 3 is a flow chart of a data verification method in one embodiment of the present disclosure;

fig. 4 is an architecture diagram of a block link point in one embodiment of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

FIG. 1 shows a system architecture diagram in one embodiment. As shown in fig. 1, the system includes a block chain 100, and the block chain 100 includes, for example, 6 nodes. The lines between the nodes schematically represent P2P (Peer-to-Peer) connections. The nodes may have a full ledger stored on them, i.e. the status of all blocks and all accounts. Wherein each node in the blockchain generates the same state in the blockchain by performing the same transaction, each node in the blockchain storing the same state database. It is to be appreciated that although fig. 1 illustrates 6 nodes included in the blockchain, embodiments of the present specification are not limited thereto and may include other numbers of nodes. Specifically, the nodes included in the block chain can meet the Byzantine Fault Tolerance (BFT) requirement. The byzantine fault tolerance requirement can be understood as that byzantine nodes can exist in a block chain, and the block chain does not show the byzantine behavior to the outside. Generally, some Byzantine Fault-tolerant algorithms require the number of nodes to be greater than 3f +1, where f is the number of Byzantine nodes, such as the practical Byzantine Fault-tolerant algorithm pbft (practical Byzantine Fault tolerance).

Also included in the system are an administrator device 10, a Metadata Service Provider (MSP) server 20, and a user device 30. An administrator (admin or Miner) is configured to propose an NFT resource (that is, a digital resource based on an NFT technology), and is responsible for designing or deploying a Metadata Schema (MS) corresponding to the NFT resource, a smart contract, an NFT application, casting (or generating) the NFT resource in a block chain, and the like. Among other things, NFT resources are used in many applications to represent, track, and provide access to off-chain resources, including in-game digital goods, digital artwork, NBA best-picture (Topshot), etc. data in mobile applications, which in the embodiments of this specification are represented as resource data of NFT resources.

A Metadata Service Provider (MSP) is used to provide services to host (or store) metadata (metadata) of NFT resources under the chain and to guarantee the integrity and correctness of the metadata. The user, which may be, for example, the Owner of the NFT resource (Owner) or a Player (Player) participating in the NFT application, may collect the NFT resource and verify the hosting operation of the MSP.

It is to be appreciated that although only one administrator device 10, one MSP server 20, and one user device 30 are shown in fig. 1 as examples, in practice, multiple administrator devices for casting different NFT resources, multiple MSP servers for providing metadata servers, and multiple user devices 30 may be included in the system, and the description is not limited thereto.

In a related approach, the administrator device 10 may first generate resource data of an NFT resource and partial information in metadata corresponding to the NFT resource. The metadata is, for example, in the form of a JSON file, and the partial information of the metadata includes, for example, information such as a unique identifier (i.e., TokenID) and description information of the NFT resource. Thereafter, the administrator device 10 may store the resource data of the NFT resource to a selected MSP server out of the chain, such as the MSP server 20, so that the file storage location FileURI of the resource data of the NFT resource may be obtained. The administrator device 10 may then supplement the FileURI to the metadata and store the metadata also in the MSP server so that the URI of the metadata may be taken as the TokenURI of the NFT resource, i.e., the TokenURI points to the metadata of the NFT resource.

Administrator device 10 may deploy NFT contracts corresponding to NFT resources in blockchain 100, i.e., such that each blockchain node has NFT contracts deployed therein. The NFT contract is used to manage the life cycle of NFT resources. It is to be appreciated that a plurality of different NFT contracts corresponding to a plurality of NFT resources, respectively, may be deployed in blockchain 100, and only one NFT contract is shown in fig. 1 as an example. After the administrator device 10 deploys the NFT contract, each blockchain node may perform operations related to the NFT resource when performing a transaction that invokes the NFT contract. For example, after deploying an NFT contract, administrator device 10 may send a transaction to blockchain 100 that invokes the NFT contract to cast NFT resources. When the block link point performs the transaction of the cast NFT resource, the NFT resource may be cast by executing the NFT contract. Specifically, the administrator apparatus 10 may store key data (e.g., TokenID, TokenURI, Owner) of the NFT resource on the block chain, specifically, in a contract state of the NFT contract, by executing the NFT contract. After the casting described above, a user device 30 (e.g., an Owner's device) may retrieve metadata for the NFT resource from the MSP server 20 using a TokenURI.

However, the above scheme does not guarantee the content correctness or integrity of the hosting data of the NFT resource (including the resource data and its metadata) stored in MSP server 20. In the application of digital NFT resources, there is a high demand for correctness of the hosted data of the NFT resources. For example, artwork, gaming devices, and photographs should not be tampered with. Therefore, in the embodiment of the present specification, a scheme for ensuring data integrity of the NFT resource is proposed, as shown in fig. 1, in which a check contract is also deployed in the blockchain 100 for checking the resource data of the NFT resource stored by the MSP server 20 and the metadata thereof to ensure data integrity.

Fig. 2 is a flowchart of a method for casting NFT resources in an embodiment of the present disclosure. The method may be performed by administrator device 10, MSP server 20, and block chain link points in block chain 100 in fig. 1. The block link point may be any node in the block chain 100. Wherein, steps S201 to S219 are preparatory operations before the NFT resource is cast. The respective steps shown in fig. 2 will be described in detail below.

First, the MSP server 20 sends a registration request to the block chain node requesting registration of the MSP by a verification contract at step S201.

The verification contract, for example, provides a registration interface (e.g., Register ()) for registering the MSP by calling a registration function. The registration interface is embodied, for example, as Register (PK) _M Deposit), wherein, PK _M The MSP's public key, the subscription is the registration deposit value. The MSP server may send the registration request by sending a transaction Tx1 to any blockchain node in the blockchain, where the sending Account for transaction Tx1 is the blockchain Account for the MSP (e.g., Account) _M ) The transaction Tx1 calls the registration function in the verification contract through the registration interface and uses the MSP's public key PK _M And presetting a deposit value as an incoming parameter of the registration function. It is understood that other required parameters may be introduced in transaction Tx1 when the registration function is called, which is not limited in this respect.

In step S203, the block link points register the MSP by performing a verification contract.

Any blockchain node in the blockchain, upon receiving the transaction Tx1, broadcasts the transaction Tx1 to other nodes in the blockchain, such that each node in the blockchain executes the transaction Tx1 to perform operations to register the MSP, respectively.

Block chain node executes transaction Tx1 with PK _M And destination performs the registration function in the verification contract for the incoming parameter. Specifically, first, the blockchain node creates a deposit account Account [ PK ] in the contract state of the check contract _M ]As a deposit account for the MSP, the deposit account is PK _M The mapped account. Thereafter, the blockchain node may Account with the send Account Account according to transaction Tx1 _M And default, Account Account _M The amount of the default credit in (1) is transferred to the variable Account [ PK _M ]In (c) as deposit, i.e. Account [ PK ] _M ]Deposint. In addition, the blockchain node also creates a frozen deposit account frozen [ PK ] in the contract state of the check contract _M ]And causes the frozen deposit account to be frozen [ PK _M ]0. Said Account [ PK _M ]Public key PK in (1) _M May serve as an identification of the MSP indicating that the MSP has registered. It will be appreciated that other identifications of the MSP (e.g., accounts) may also be associated with the deposit account herein for indicating that the MSP has been registered.

Wherein, in the registration function Register (PK) _M Deposit) it may also be provided that the Accounts PK is first checked before setting the balance of the deposit account _M ]If it already exists, aborts execution if it already exists, and returns "PK _M Already registered ". In addition, in the registration function Register (PK) _M Deposint) can also be set to judge whether the deposint is smaller than a preset minimum value Min-deposint, if so, the execution is stopped, and the 'need is greater than or equal to Min-deposint' is returned.

In step S205, the administrator apparatus 10 transmits a deployment request to the block link point for requesting the deployment of the NFT contract.

Specifically, the administrator device 10 may first develop an NFT contract in which one of the protocol standards of the NFT resource is set by code for performing a plurality of operations related to the NFT resource. Thereafter, the administrator device 10 may send a transaction Tx2 To any blockchain node in the blockchain, the receive (To) field of the transaction Tx2 being null for indicating that the transaction is a transaction for deploying a contract, the Data (Data) field of the transaction Tx2 being the contract content of the NFT contract To be deployed for deploying the NFT contract in the blockchain.

In one embodiment, the administrator device 10 may generate a Metadata Schema file (MS) of the NFT resource before deploying the NFT contract. The MS file is used to define the schema (or format) of the metadata. The MS file includes, for example, a plurality of fields, a definition of locations of the plurality of fields, a definition of contents of the plurality of fields, and the like.

In one example, assuming that the resource data of the NFT resource is image data, the MS file of the MFT resource includes the following codes:

in the above code, the order includes fields of "name", "description", "imageURI", etc. of the NFT resource and descriptive definitions of these fields, wherein the order defines the positions of these fields in the metadata.

In another example, the MS file includes, for example, the following codes:

compared with the MS file in the previous example, the MS file is added with an 'imageHash' field, namely, the hash value of the image data is limited in the metadata of the NFT resource, so that the image data can be verified according to the image hash value in the metadata, and the integrity of the image data is ensured.

The administrator device 10 may generate the transaction Tx2 after generating the MS file and include a hash value (MSH) of the MS file in a data field of the transaction Tx2 so that after deploying the NFT contract, the NFT contract is initialized by the MSH, i.e., the MSH is stored in a contract state of the NFT contract.

While deploying the NFT contract, the administrator device 10 may also deploy, in the server, an NFT Application (APP) for managing an interactive operation between an owner of the NFT resource and the NFT contract, for example, invoking an interface provided by the NFT contract or the like.

At step S207, the NFT contract is deployed at block link points.

Any blockchain node in the blockchain, upon receiving the transaction Tx2, broadcasts the transaction Tx2 to the other nodes in the blockchain, so that each node (or the full-volume node) in the blockchain will execute the transaction Tx2 to deploy the NFT contract separately.

When executing the transaction Tx2, the blockchain node generates an account address (e.g., Addr1) of the NFT contract, and stores the contract content of the NFT contract into the contract state of the NFT contract in the state database according to the account address of the NFT contract, thereby completing the deployment of the NFT contract. In the case where MSH is included in transaction Tx2, the blockchain node also initializes the NFT contract using the MSH, i.e., stores the MSH in the contract state of the NFT contract. After the deployment, when the blockchain node executes a transaction for calling the NFT contract, the blockchain node may obtain a code of a function included in the NFT contract from the state database according to the account address of the NFT contract, and may execute the code to execute an operation corresponding to the function.

In step S209, the blockchain node returns the contract address of the NFT contract to the administrator device 10.

Specifically, a specific blockchain node (e.g., a node connected to the administrator device) may be set in the blockchain 100 to return a contract address (e.g., Addr1) of the NFT contract to the administrator device 10. In one embodiment, the address Addr1 is uniquely associated with the NFT resource and therefore can serve as an identifier of the NFT resource.

In step S211, the administrator device 10 requests a metadata service corresponding to the NFT resource from the MSP server 20.

The administrator device 10 may select an MSP for providing metadata services and send a metadata service request to a server of the MSP (e.g., MSP server 20 in fig. 1) for requesting metadata services corresponding to NFT resources. The metadata service request includes an identifier of the NFT resource, which is used to indicate the NFT resource corresponding to the metadata service. In one embodiment, the identification of the NFT resource may be the contract address Addr1 of the NFT contract. The metadata service request may also include a deposit value corresponding to the NFT resource. In addition, the metadata service request may further include an MS file for storing the MS file in the MSP server. In a case that the MS file is included in the service request, the MSP server may store a mapping relationship between the MS file and an identifier of the NFT resource for reading the MS file, where the identifier of the NFT resource may be a contract address Addr1 of an NFT contract or an identifier of an administrator device.

In step S213, the MSP server 20 transmits a registration request for requesting registration of the metadata service by the verification contract to the block chain node.

MSP server 20, upon receiving the metadata service request from administrator device 10, may transmit transaction Tx3 to the blockchain node, the transmitted Account for transaction Tx3 being the Account Account for the MSP _M The registration interface provided by the verification contract (e.g., the function name recordService () of the registration function) is called in transaction Tx3 to register the metadata services provided by the MSP to the administrator in the blockchain. The incoming parameter to recordService () in this transaction Tx3 includes an identification of the NFT resource (e.g., Addr1) to indicate that the metadata service corresponds to the NFT resource described above.

Specifically, in the case that the metadata service request includes an MS file, the MSP server 20 may first send, to the block chain node, a transaction for invoking an interface getmetadataschemamh () provided by the NFT contract according to the contract address Addr1, so as to obtain an MSH corresponding to the MS file. After performing the transaction, the blockchain node reads the MSH saved to the contract state at the time of the above-mentioned contract initialization from the contract state of the NFT contract and returns the MSH to the MSP server 20. After acquiring the MSH, the MSP server 20 calculates a hash value of the MS file, and compares whether the hash value is equal to the MSH to verify whether the MS file is correct. MSP server 20 stores the MS file locally in case it is verified that it is correct, so that it can be read from the MSH. That is, assume that the MSP server corresponds to a URI "http://msp_server/", the URI of the MS file may be"http://msp_server/MSH ", i.e. other devices can pass"http://msp_server/MSH "reads the MS file from MSP server 20.

The metadata service request also includes a Deposit value corresponding to the NFT resource (e.g., in a Deposit order) _N Indicated), the MSP sends a transaction Tx3 to the blockchain node through MSP server 20 upon accepting the deposit value. The Deposit value Deposit is also included in the incoming parameter to recordService () in the transaction Tx3 _N . In another embodiment, the preset DEPOSIT value (depost _ PER _ SERVICE) corresponding to each NFT resource may be preset in the check contract, so that the DEPOSIT value need not be included in the incoming parameter of recordService ().

In addition, the MSP server 20 may also sign the combination of Addr1 and MSH to obtain sig1, and further include MSH and the signature sig1 in the incoming parameters to recordService () in the transaction Tx 3. The signature sig1 is for example

SIGN(PVK _M Addr1| | MSH), where the symbol | | represents splicing Addr1 and MSH together, the signature being the account private key PVK through MSP _M Addr1| | | MSH is obtained by encrypting.

In addition, the public key PK is passed in the block chain node _M Where the MSP is identified, the MSP server 20 may also include the MSP's public key PK in the incoming parameters to recordService () in transaction Tx3 _M 。

In step S215, the blockchain node records the metadata service provided by the MSP in the contract state of the check contract.

Blockchain nodes upon receiving transaction Tx3 from MSP server 20, broadcast transaction Tx3 to other nodes in the blockchain, causing each node in the blockchain to execute the transaction Tx 3.

When executing the transaction Tx3, the blockchain node first detects whether the metadata service corresponding to the NFT resource is already recorded in the contract status of the check contract, and specifically, whether the metadata service associated with Addr1 is already recorded. In a case where it is determined that the metadata service corresponding to the NFT resource is not recorded, the metadata service corresponding to the NFT resource provided by the MSP is recorded in a contracted state of the check contract.

Specifically, when in the contract state, the public key PK of MSP is used _M As an identification of the MSP, the incoming parameters to recordService () in the transaction Tx3 include Addr1 and PK _M The block chain node records PK in association in the contract state of the check contract _M And Addr 1.

When the incoming parameters of the transaction Tx3 also include the Deposit value Deposit corresponding to the NFT resource _N In the case of block chain node, when executing transaction Tx3, the block chain node first detects deposit account Account [ PK [ ] _M ]-frozen[PK _M ]Whether the value of (A) is greater than or equal to the Deposit value Deposit _N In the case that the detection result is yes, the blockchain node records the PK in association in the contract state of the check contract _M And Addr 1. Thereafter, the block link point pair frozen [ PK _M ]Increased balance of _N The frozen amount of money. This is equal to Deposit _N The frozen amounts of (a) are used to determine whether managed data corresponding to NFT resources stored in the MSP server is faulty from Accounts [ PK ] respectively when block link points (b) determine that managed data corresponding to NFT resources stored in the MSP server are faulty _M ]And frozen [ PK _M ]Can be used to supervise the services provided by the MSP.

In the case where MSH and the signature sig1 of MSP pair Addr1| | | MSH are also included in the incoming parameters to recordService () in transaction Tx3, the blockchain node also uses PK _M Validating sig1, after validation passes, recording PK in association with Addr1 in the contract State of the validation contract _M MSH and sig 1.

At step S217, administrator device 10 uploads the hosting data of the NFT resource to MSP server 20.

Upon determining that MSP server 20 has registered the metadata services provided by the MSP for the NFT resource in the chain, administrator device 10 may upload hosting data for the NFT resource, which may include resource data and corresponding metadata for the NFT resource, to MSP server 20. For example, the resource data of the NFT resource may be image data, and the metadata may be a metadata json object.

This metadata may have the metadata schema described above, for example, in the case where the resource data of the NFT resource is image data, the metadata uploaded by the administrator device may be as follows:

in step S219, MSP server 20 generates a TokenURI of the metadata of the NFT resource, and stores the metadata.

After receiving the resource data (e.g., image) and the metadata of the NFT resource received by the administrator device, the MSP server 20 verifies whether the image is correct using the image hash value (imageHash) in the metadata. MSP server 20 may also verify that the uploaded metadata conforms to a pre-stored MS corresponding to the NFT resource. Specifically, the MSP server 20 may read the prestored MS file according to the mapping relationship between the prestored MS file and the identifier of the NFT resource, so as to check the metadata by using the MS file.

The blockchain node stores the uploaded image in case of verification of correctness, generates the URI of the image, and stores the URI of the image into the imageURI field in the metadata, thereby generating the complete metadata as shown below:

MSP server 20 will then generate a URI (hereinafter token URI) for storing the metadata, for example of the form: { baseURI/MSH/MH }. Wherein the baseURI represents the address of the MSP server, such as http:// MSP _ server, MSH is the hash value of the metadata schema, and MH is the hash value of the metadata. The token uri includes MSH and MH, and thus can be used for checking the integrity of NFT resource data subsequently.

It is to be understood that, in the present specification embodiment, the TokenURI is not limited to the above, as long as the TokenURI can uniquely identify the metadata of the NFT resource. For example, in the case where the pattern of metadata is not required to conform to a particular MS, the generated TokenURI may have the form { baseURI/MH }, or the TokenURI may have the form

{ baseURI/TokenID }, etc., in which the MH is not included in the tokenir, the MH may be stored in the contract state of the contract for use in verifying the metadata.

After generating the TokenURI, the MSP may store the metadata generated by the MSP server at the location pointed to by the TokenURI.

MSP server 20 returns a tokenURI to administrator device 10 at step S221.

After receiving the token uri, the administrator device 10 may read (retrieve) the metadata from the MSP server 20 according to the token uri, and check whether the content of the metadata is correct. Specifically, administrator device 10 may first verify that MSH and MH correspond to the correct MS and metadata, and then verify that the hash value of the metadata read from MSP server 20 is equal to MH. The administrator device 10 may also retrieve imageuris from the metadata, read the image from the MSP server 20 according to the imageuris, and verify that the image is correct. For example, the administrator device 10 may verify whether the hash value of the image is equal to the imageHash in the metadata.

In addition to returning a TokenURI to administrator device 10, MSP server 20 may use the MSP private key (PVK) _M ) Signing the token URI to obtain signature sig2 ═ SIGN (PVK) _M TokenURI) and also returns the signature sig2 to the administrator device 10. Administrator device 10, upon receiving the signature sig2, may use a pre-acquired Public Key (PK) of the MSP _M ) The signature sig2 is verified. For example, the administrator device 10 may obtain the MSP public key by sending a transaction to the blockchain 100 that invokes an interface provided by the verification contract that queries the MSP public key. In particular, administrator device 10 may import parameter Addr1 when invoking the interface, and may retrieve the PK recorded in the contract state of the verification contract in association with Addr1 _M 。

In step S223, the administrator apparatus 10 sends a casting request to the block link point to request the NFT resource to be cast based on the TokenID, Owner, and TokenURI by the NFT contract.

In the event that the above-described checks all pass, the administrator device 10 may invoke the casting interface provided by the NFT contract to cast the NFT resource. Specifically, the administrator device 10 may send a transaction Tx4 to the blockchain node, and this transaction Tx4 may call a foundry interface Mint (TokenID, Owner, TokenURI) provided by the NFT contract for the incoming parameters with TokenID, Owner, and TokenURI. In one embodiment, the incoming parameters to the foundry interface in the transaction Tx4 may also include the signature sig2 of the MSP described above for ensuring the correctness of the TokenURI.

In step S225, the blockchain node records TokenID, Owner, and TokenURI in the NFT contract state.

The blockchain node, upon receiving the transaction Tx4, broadcasts the transaction Tx4 to the other nodes in the blockchain so that each node in the blockchain will execute the transaction Tx 4.

Specifically, when executing the transaction Tx4, the blockchain node executes the function Mint (TokenID, Owner, TokenURI), first determines whether or not the TokenID has been recorded in the contract state of the NFT contract, and in the case where it is determined that the TokenID has not been recorded, records the TokenID, Owner, and TokenURI in association in the contract state of the NFT contract, thereby completing casting of the NFT resource.

In the case where the incoming parameters of the function Mint further include the sig2, the blockchain node, when executing the function Mint, first executes a public key acquisition interface provided by the verification contract called in the function Mint to acquire the Public Key (PK) of the MSP corresponding to the NFT resource (i.e., Addr1) from the contract state of the verification contract _M ). Specifically, a public key acquisition interface is called in the function Mint by using a contract address of the NFT contract as an incoming parameter, so that when the public key acquisition interface is executed by a block chain node, a public key recorded in association with the address of the NFT contract can be read from a contract state of a verification contract, and the public key recorded in association is a Public Key (PK) of an MSP corresponding to the NFT resource _M ). The block chain node obtains the public key PK _M Thereafter, the public key PK is used _M Verifying signature sig2, and recording TokenID, Owner, TokenURI and in contract state of NFT contract in association if verification is passedsig2。

It is to be understood that, in the above-described embodiment, since the TokenURI includes the MSH and the MH, it is not necessary to separately store the data of the MSH and the MH in the contract state of the NFT contract. The present specification embodiment is not limited to this, and for example, in a case where the MSH and MH are not included in the token uri, the MH or the MH and MSH may also be stored into the contract status of the NFT contract by executing the transaction Tx 4.

After the casting of the NFT resource is completed as described above, a user of the blockchain (e.g., a player or an owner of the NFT resource) can check the data of the NFT resource stored by the MSP server by a check contract, thereby ensuring the correctness of the data.

Fig. 3 is a flow diagram of a data verification method that may be performed by user device 30, MSP server 20, and the block chain node in one embodiment of the present disclosure.

As shown in fig. 3, in step S301, the user equipment 30 reads URI data and authentication data of the NFT resource from the blockchain node.

A user corresponding to user device 30 may participate in the collection or transfer (sale) of the NFT resource, and therefore, the user needs to verify the hosted data of the NFT resource stored in MSP server 20 to determine that the hosted data is correct data. For this, the user equipment 30 may first read URI data and authentication data of the NFT resource from any blockchain node in the blockchain 100 according to the token id of the NFT resource. The URI data is used for positioning the storage position of the hosting data of the NFT resource stored in the MSP server, and the verification data is used for verifying the hosting data. In an embodiment of the present specification, the URI data includes, for example, a tokenURI by which the metadata of the NFT resource can be read from the MSP server. After reading the metadata, the user device 30 may read an imageURI of resource data (e.g., an image) of the NFT resource from the metadata, from which the image of the NFT resource may be read from the MSP server. The user equipment 30 may further read a URI corresponding to the MS file from the blockchain node, and in a case that the URI of the MS file is { baseURI/MSH }, the user equipment 30 may read MSH from the blockchain node, thereby obtaining the URI corresponding to the MS file.

The authentication data includes, for example, an MH where the user authenticates the metadata, or may include an MH and an MSH for authenticating the metadata schema, and the like. In the embodiment of the present specification, since the token uri includes the MH or includes both the MH and the MSH, the user equipment 30 only needs to read the token uri from the chunk link point. Specifically, the user device 30 may send the transaction Tx5 to the blockchain node, call the read interface provided by the NFT contract in the transaction Tx5, and transfer the token id into the read interface. The blockchain node may obtain the token uri according to the token id when executing the transaction Tx5, and return the token uri of the NFT resource to the user equipment 30. The verification data may also include a signature sig2 of the tokenURI by the MSP stored in the contract state of the NFT contract. In this case, the blockchain node may also obtain sig2 from the tokenID when performing the transaction Tx5, and return sig2 to the user equipment 30.

At step S303, user device 30 reads the hosting data of the NFT resource from MSP server 20 according to the URI data.

After reading the URI data from the blockchain node, the user device 30 may read the metadata of the NFT resource from the MSP server 20 according to the tokenURI, and may also read an image of the NFT resource from the MSP server 20 according to the imageURI included in the metadata. The user device 30 may also read the MS file corresponding to the NFT resource from the MSP server 20 according to { baseURI/MSH } in the tokenURI.

In step S305, the user device 30 verifies the hosted data according to the verification data.

The user device 30 may use the MH in the authentication data to verify the metadata of the NFT resource. Specifically, the user device 30 calculates a hash value of the metadata in the hosted data and compares whether the hash value is equal to MH to check whether the metadata is correct. If equal, the check passes, and if not, the check fails. The user device 30 may also obtain a hash value (e.g., imageHash) of the resource data from the metadata, and use the imageHash to verify whether the image of the NFT resource is correct.

In the case where the MS is included in the escrow data, the MSH is also included in the authentication data. After the user equipment 30 has passed the verification of the metadata, it can use MSH to verify that the MS file is correct and that the mode of the metadata conforms to the settings in the MS file. In the case that the verification passes, the user device 30 further obtains the hash value (e.g., imageHash) of the resource data from the metadata, and verifies whether the image of the NFT resource is correct by using the imageHash.

In step S307, in the case that any one of the above-mentioned checkings fails, the user equipment 30 sends a check request to the block link point for requesting to check the escrow data by the check contract.

Specifically, the user equipment 30 may send the transaction Tx6 to the blockchain node, where the transaction Tx6, for example, calls a report interface report (addr1, tokenURI, sig2) provided in the verification contract for requesting verification of the managed data corresponding to addr1 by the verification contract.

In step S309, the block link point instructs the trusted device to check the escrow data by executing a check contract.

Blockchain nodes upon receiving the transaction Tx6, broadcast the transaction Tx6 to the other nodes in the blockchain 100 so that each blockchain node will execute the transaction Tx 6.

Specifically, the blockchain node first associates the recorded addr1 and PK in the contract verification status when executing the transaction Tx6 _M Obtaining MSP public key and using PK _M Sig2 is verified to verify the token uri is valid. The blockchain node may also read the MSH recorded in the check contract state in association with Addr1, and use the MSH to verify whether the MSH in the token uri is correct. In the case of a verification pass, the chunk link point may invoke a verification service provided by a trusted device (e.g., Oracle) to cause the trusted device to verify the hosted data stored in the MSP server according to the tokenURI.

The trusted device, when performing the call, may verify the hosted data as the user device above. Specifically, the trusted device reads the metadata from the MSP server 20 according to the tokenURI, and reads the MS file corresponding to the NFT resource from the MSP server 20 according to { baseURI/MSH }. Then, the trusted device verifies the MS file using the MSH in the token uri, verifies the metadata using the MH in the token uri, and then verifies whether the mode of the metadata conforms to the MS file. After the verification passes, the resource data (e.g., image) of the NFT resource is read from MSP server 20 through imageURI in the metadata, and the read image is verified through imageHash in the metadata. And after the trusted device performs the check, returning a check result to the block chain node.

In step S311, when the returned verification result includes any item that fails to pass the verification, the block link point deducts a preset deposit corresponding to the NFT resource from the deposit account of the MSP set by the verification contract.

Specifically, the blockchain node may obtain a Deposit value Deposit corresponding to the NFT resource from a contract state of the check contract _N Check Account [ PK ] in contract State of contract _M ]And frozen [ PK _M ]Separately subtract Deposit _N 。

In an embodiment of the present specification, a data hosting service provided by the MSP is recorded by a verification contract, and the MSP is punished by the verification contract when there is a problem with the service provided by the MSP to ensure the correctness and integrity of the hosted data stored in the MSP server. With the solution provided by the embodiments of the present specification, NFT players can be more confident that their collections have not been tampered with. NFT administrators can enjoy careless services provided by MSP. The MSP can gain revenue by providing such services, recording the reputation of the MSP through blockchains, enhancing the supervision of the MSP. NFT players do not need to trust either party to maintain the integrity and correctness of the metadata.

Fig. 4 is a blockchain node in an embodiment of the present specification, where the blockchain is deployed with a first intelligent contract, and the blockchain node includes:

a receiving unit 41, configured to receive a first transaction, where the first transaction invokes the first intelligent contract, the first transaction includes second data, the second data includes storage location information of the first data, and is used to check the first data, and the first data is stored in an off-link server;

an execution unit 42 for instructing a trusted device to verify the first data based on the second data by executing the first smart contract invoked by the first transaction.

In one embodiment, the off-chain server is a server, the contract status of the first intelligent contract includes a balance of a first account, the first account corresponds to the server, the account balance of the first account includes a frozen quota corresponding to the first data, and the block chain node further includes: and the deducting unit is used for deducting the frozen quota from the account balance of the first account in the condition that the verification is not passed.

In one embodiment, the receiving unit 41 is further configured to receive a second transaction before receiving the first transaction, where a sending account of the second transaction is a second account of the service party, and the second transaction calls the first smart contract, a public key including the first account, and a first quota;

the block chain node further comprises a creating unit, which is used for creating the first account corresponding to the public key in the contract state of the first intelligent contract by executing the first intelligent contract called by the second transaction, and transferring the first quota of the second account to the first account.

In one embodiment, the execution unit 42 is further configured to create a frozen account corresponding to the public key in a contract state of the first intelligent contract by executing the first intelligent contract invoked by the second transaction;

the receiving unit 41 receives a third transaction after the second transaction is completed, where the third transaction invokes the first smart contract, the third transaction includes the identifier of the first data and the public key, a sending account of the third transaction is the second account, and is issued by the server in response to a service request of a user device, where the service request includes the identifier of the first data;

the execution unit 42 is further configured to: adding a frozen quota corresponding to the first data in the balance of the frozen account by executing the first intelligent contract called by the third transaction, and storing the public key in association with the identifier of the first data in a contract state of the first intelligent contract.

In one embodiment, the first transaction further includes an identifier of the first data and a signature of the second data by the second account, and the blockchain node further includes a verification unit configured to obtain the public key based on the identifier of the first data and verify the signature using the public key before instructing a trusted device to verify the first data based on the second data.

In an embodiment, the first data is metadata of resource data of a resource on a chain, and the first data includes storage location information of the resource data and a hash value of the resource data, and the execution unit 42 is further configured to: and checking the resource data according to the storage position information of the resource data and the hash value of the resource data.

In an embodiment, the server further stores fourth data, where the fourth data includes mode information of the first data, the second data further includes fifth data for verifying the fourth data, and the execution unit 42 is further configured to: instructing a trusted device to verify the fourth data based on the fifth data and verifying whether the first data conforms to a pattern indicated in the fourth data by executing the first smart contract invoked by the first transaction.

In one embodiment, a second intelligent contract corresponding to a resource on the chain is deployed in the blockchain, the identification of the first data is an account address of the second intelligent contract,

the receiving unit 41 is further configured to receive a fourth transaction, where the fourth transaction invokes the second smart contract, and the fourth transaction includes the second data and a signature of the second account on the second data;

the execution unit 42 is further configured to store the second data and the signature of the second account on the second data in a contract state of the second intelligent contract by executing the second intelligent contract invoked by the fourth transaction.

In one embodiment, the third transaction further includes sixth data for verifying the fourth data, the sixth data is obtained by the server from the blockchain node, and the execution unit 42 is further configured to: storing the sixth data in association with the identification of the first data in a contract state of the first intelligent contract by executing the first intelligent contract invoked by the third transaction.

In one embodiment, the execution unit 42 is further configured to, before instructing the trusted device to check the first data based on the second data, obtain the sixth data based on the identifier of the first data, and check the fifth data using the sixth data.

Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, which, when executed in a computer, causes the computer to perform the method shown in fig. 2 and 3.

The embodiment of the present specification further provides a blockchain node, which includes a memory and a processor, where the memory stores executable codes, and the processor executes the executable codes to implement the methods shown in fig. 2 and fig. 3.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement of the process flow cannot be realized with hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to the software compiler used in program development and writing, but the original code before compiling is written in a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not just one kind, but many kinds, such as abel (advanced boot Expression Language), ahdl (alternate Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal (Java Hardware Description Language), Lava, Lola, HDL, PALASM, plasm, dl (Hardware Description Language), and vhul, which are currently used commonly by Hardware compiler). It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, this application does not exclude that as future computer technology develops, the computer implementing the functionality of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although one or more embodiments herein provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used, they are used to denote names, but not to denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. It is to be understood that, when one or more of the present descriptions are implemented, functions of the respective modules may be implemented in the same software and/or hardware or a plurality of sub-modules or combinations of sub-units may implement the same functions. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical functional division, and in actual implementation, there may be other divisions, for example, a plurality of units or components may be combined or may be 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.

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the 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 storage, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

One skilled in the art will appreciate that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the present description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

The above description is only one example of one or more embodiments of the present disclosure, and is not intended to limit the one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A data validation method performed by a node of a blockchain, the blockchain having a first intelligent contract deployed therein, the method comprising:

2. The method of claim 1, wherein the off-link server is a server, the contract status of the first intelligent contract includes a balance of a first account, the first account corresponds to the server, the balance of the first account includes a frozen amount corresponding to the first data, and the method further comprises: in the case that the verification fails, deducting the frozen amount from the account balance of the first account.

3. The method of claim 2, further comprising:

4. The method of claim 3, further comprising:

receiving a third transaction after the second transaction is executed, wherein the third transaction calls the first intelligent contract, the third transaction comprises the identification of the first data and the public key, a sending account of the third transaction is the second account, and the third transaction is sent out by the server in response to a service request of user equipment, and the service request comprises the identification of the first data;

adding a frozen quota corresponding to the first data in the balance of the frozen account by executing the first intelligent contract called by the third transaction, and storing the public key in association with the identifier of the first data in a contract state of the first intelligent contract.

5. The method of claim 4, wherein the first transaction further includes an identification of the first data and a signature of the second data by the second account, the method further comprising, prior to instructing a trusted device to verify the first data based on the second data, obtaining the public key based on the identification of the first data, verifying the signature using the public key.

6. The method according to claim 5, wherein the first data is metadata of resource data of a resource on a chain, the first data includes storage location information of the resource data and a hash value of the resource data, and the verifying the first data includes: and checking the resource data according to the storage position information of the resource data and the hash value of the resource data.

7. The method of claim 4, the server having fourth data stored therein, the fourth data including schema information of the first data, the second data further including fifth data for verifying the fourth data, the verifying the first data further comprising: instructing a trusted device to verify the fourth data based on the fifth data and whether the first data conforms to a pattern indicated in the fourth data by executing the first smart contract invoked by the first transaction.

8. The method of claim 7, wherein a second intelligent contract corresponding to a resource on the chain is deployed in the blockchain, and the identification of the first data is an account address of the second intelligent contract, the method further comprising:

receiving a fourth transaction, the fourth transaction invoking the second smart contract, the fourth transaction including the second data and a signature of the second account on the second data;

9. The method of claim 8, the third transaction further comprising sixth data for verifying the fourth data, the sixth data obtained by the server from the blockchain node, the method further comprising: storing the sixth data in association with the identification of the first data in a contract state of the first intelligent contract by executing the first intelligent contract invoked by the third transaction.

10. The method of claim 9, further comprising, prior to instructing a trusted device to verify the first data based on the second data, obtaining the sixth data based on an identity of the first data, verifying the fifth data using the sixth data.

11. A blockchain node, the blockchain deployed with a first intelligent contract, the blockchain node comprising:

12. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-10.

13. A blockchain node comprising a memory having stored therein executable code and a processor that, when executing the executable code, implements the method of any of claims 1-10.