A data verification method and a blockchain node

Abstract

A data verification method and a blockchain node. A first smart contract is deployed on the blockchain. The method includes: receiving a first transaction that invokes the first smart contract, where the first transaction includes second data. The second data includes the storage location information of first data and is used to verify the first data. The first data is stored in an off-chain server; by executing the first smart contract invoked by the first transaction, instructing a trusted device to verify the first data based on the second data.

Description

Technical Field

[0001] The embodiments of this specification belong to the technical field of blockchain, and in particular, relate to a data verification method and a blockchain node. Background Art

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. In a blockchain system, data blocks are combined into a chain-like data structure in a sequential connection manner according to the time sequence, and a distributed ledger that is tamper-proof and non-forgeable is guaranteed by cryptographic means. Due to the characteristics of decentralization, information immutability, and autonomy of the blockchain, the blockchain has received more and more attention and applications.

[0003] In the blockchain, digital resources can be generated based on the Non-Fungible Tokens (NFT) technology. The digital resources usually have characteristics such as non-replaceability and limited quantity, and are indivisible. Different blockchains can use different NFT protocol standards to generate digital resources. The current mainstream protocol standards include ERC721, ERC1155, and ERC998, etc. Among them, ERC721 is the most commonly used NFT protocol standard. 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 identifier corresponds not to one resource, but to a class of resources. Different classes of resources are not replaceable, while different resources within a class have no difference, can be replaced with each other, and the quantity of resource classes is limited. In the ERC998 standard, the digital resources generated based on the NFT technology can be bound or combined with the digital resources generated based on the Fungible Tokens (FT) technology (such as ETH coins). Summary of the Invention

[0004] The purpose of the present invention is to provide a method for verifying data stored in a metadata service, which ensures the integrity of the escrow data.

[0005] The first aspect of this specification provides a data verification method, which is executed by a node of the blockchain. The blockchain is deployed with a first smart contract. The method includes:

[0006] Receiving a first transaction, the first transaction invoking the first smart contract. The first transaction includes second data, the second data including the storage location information of the first data and being used to verify the first data. The first data is stored in an off-chain server;

[0007] The first smart contract invoked by executing the first transaction instructs the trusted device to verify the first data based on the second data.

[0008] In one implementation, when the off-chain server is a service provider server, the contract state of the first smart contract includes the balance of a first account, the first account corresponds to the service provider, and the account balance of the first account includes a frozen amount corresponding to the first data. The method further includes: in the case where the verification fails, deducting the frozen amount from the account balance of the first account.

[0009] In one implementation, the method further includes:

[0010] Receiving a second transaction before receiving the first transaction, the sending account of the second transaction is a second account of the service provider, and the second transaction invokes the first smart contract and includes the public key of the first account and a first amount;

[0011] By executing the first smart contract invoked by the second transaction, creating the first account corresponding to the public key in the contract state of the first smart contract, and transferring the first amount of the second account to the first account.

[0012] In one implementation, the method further includes:

[0013] By executing the first smart contract invoked by the second transaction, creating a frozen account corresponding to the public key in the contract state of the first smart contract;

[0014] Receiving a third transaction after executing the second transaction, the third transaction invokes the first smart contract, the third transaction includes the identifier of the first data and the public key, the sending account of the third transaction is the second account, and is issued by the service provider server in response to a service request of the user device, and the service request includes the identifier of the first data;

[0015] By executing the first smart contract invoked by the third transaction, increasing the frozen amount corresponding to the first data in the balance of the frozen account, and storing the public key in association with the identifier of the first data in the contract state of the first smart contract.

[0016] In one implementation, the first transaction further includes the identifier of the first data and the signature of the second account on the second data. The method further includes, before instructing the trusted device to verify the first data based on the second data, obtaining the public key based on the identifier of the first data, and verifying the signature using the public key.

[0017] In one implementation, the first data is the metadata of the resource data of the on-chain resource. The first data includes the storage location information of the resource data and the hash value of the resource data. Verifying the first data includes: verifying the resource data according to the storage location information of the resource data and the hash value of the resource data.

[0018] In one implementation, the service provider server further stores fourth data. The fourth data includes the mode information of the first data. The second data further includes fifth data for verifying the fourth data. Verifying the first data further includes: instructing a trusted device to verify the fourth data based on the fifth data by executing the first smart contract called by the first transaction, and verifying whether the first data conforms to the mode indicated in the fourth data.

[0019] In one implementation, a second smart contract corresponding to the on-chain resource is deployed in the blockchain. The identifier of the first data is the account address of the second smart contract. The method further includes:

[0020] Receiving a fourth transaction that calls the second smart contract. The fourth transaction includes the second data and the signature of the second account on the second data;

[0021] By executing the second smart contract called by the fourth transaction, storing the second data and the signature of the second account on the second data in the contract state of the second smart contract.

[0022] In one implementation, the third transaction further includes sixth data for verifying the fourth data. The sixth data is obtained by the service provider server from the blockchain node. The method further includes: by executing the first smart contract called by the third transaction, storing the sixth data in the contract state of the first smart contract in association with the identifier of the first data.

[0023] In one implementation, the method further includes, before instructing the trusted device to verify the first data based on the second data, obtaining the sixth data based on the identifier of the first data and using the sixth data to verify the fifth data.

[0024] The second aspect of this specification provides a blockchain node. The blockchain deploys a first smart contract. The blockchain node includes:

[0025] a receiving unit, configured to receive a first transaction, the first transaction invoking the first smart contract, the first transaction including second data, the second data including storage location information of the first data, and to verify the first data, the first data being stored in an off-chain server;

[0026] An execution unit is configured 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.

[0027] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.

[0028] A fourth aspect of this specification provides a blockchain node, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0029] In the embodiments of this specification, the data hosting service provided by the MSP is recorded through a verification contract, and the MSP is punished by the verification contract when there is a problem with the service provided by the MSP, so as to ensure the correctness and integrity of the hosting data stored in the MSP server. Through the solution provided in the embodiments of this specification, NFT players can be more confident that their collections have not been tampered with. NFT administrators can enjoy the worry-free service provided by the MSP. The MSP can earn revenue by providing such services, and the reputation of the MSP is recorded through the blockchain, thereby strengthening the supervision of the MSP. NFT players do not need to trust any party to maintain the integrity and correctness of the metadata. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0031] Figure 1 A system architecture diagram in one embodiment is shown;

[0032] Figure 2 This is a flow chart of a method for minting NFT resources in one embodiment of this specification;

[0033] Figure 3 This is a flow chart of a data verification method according to an embodiment of the present specification;

[0034] Figure 4It is an architecture diagram of a blockchain node in an embodiment of this specification. Detailed implementation manners

[0035] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of this specification.

[0036] Figure 1 Shows the system architecture diagram in an embodiment. As Figure 1 shown, the system includes a blockchain 100, and the blockchain 100 includes, for example, 6 nodes. The connections between the nodes schematically represent P2P (Peer to Peer) connections. The full ledger can be stored on these nodes, that is, the states of all blocks and all accounts are stored. Among them, each node in the blockchain generates the same state in the blockchain by executing the same transactions, and each node in the blockchain stores the same state database. It can be understood that Figure 1 although 6 nodes are shown in the blockchain, the embodiments of this specification are not limited thereto, but may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the requirements of Byzantine Fault Tolerance (BFT). The so-called Byzantine Fault Tolerance requirements can be understood as that Byzantine nodes can exist inside the blockchain, while the blockchain does not show Byzantine behavior externally. Generally, some Byzantine Fault Tolerance 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 Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).

[0037] The system also includes an administrator device 10, a Metadata Service Provider (MSP) server 20, and a user device 30. Among them, the administrator (admin or Miner) is used to propose NFT resources (i.e., digital resources based on NFT technology), and is responsible for designing or deploying the metadata schema (MS), smart contract, NFT application corresponding to the NFT resource, minting (or generating) NFT resources in the blockchain, etc. In the embodiments of this specification, the terminal device used by the administrator is referred to as the administrator device. Among them, NFT resources are used in many applications to represent, track, and provide access to off-chain resources, and these off-chain resources include in-game digital items, digital artworks, NBA Topshot and other data in mobile applications. In the embodiments of this specification, the off-chain resources are represented as the resource data of the NFT resource.

[0038] The Metadata Service Provider (MSP) is used to provide services to host (or store) the metadata of the NFT resource off-chain and ensure the integrity and correctness of the metadata. The user can be, for example, the owner of the NFT resource or a player participating in the NFT application. The user can collect the NFT resource and verify the hosting operation of the MSP.

[0039] It can be understood that although Figure 1 only one administrator device 10, one MSP server 20, and one user device 30 are shown as examples, in practice, the system may include multiple administrator devices for minting different NFT resources, multiple MSP servers for providing metadata servers, and multiple user devices 30. This specification does not limit this.

[0040] In the related solution, the administrator device 10 may first generate the resource data of the NFT resource and some information in the metadata corresponding to the NFT resource. The metadata has, for example, the form of a JSON file, and some information in the metadata includes, for example, the unique identifier (i.e., TokenID), description information, and other information of the NFT resource. After that, the administrator device 10 may store the resource data of the NFT resource in the server of the selected MSP off-chain, for example, store it in the MSP server 20, so as to obtain the file storage location FileURI of the resource data of the NFT resource. Then, the administrator device 10 may supplement the FileURI to the metadata and also store the metadata in the MSP server, so as to use the URI of the metadata as the TokenURI of the NFT resource, that is, the TokenURI points to the metadata of the NFT resource.

[0041] The administrator device 10 can deploy an NFT contract corresponding to the NFT resource in the blockchain 100, that is, such that the NFT contract is deployed in each blockchain node. This NFT contract is used to manage the life cycle of the NFT resource. It can be understood that multiple different NFT contracts corresponding to multiple NFT resources can be deployed in the blockchain 100. Figure 1 Only one NFT contract is shown as an example. After the administrator device 10 deploys the NFT contract, when each blockchain node executes a transaction that invokes the NFT contract, it can perform operations related to the NFT resource. For example, after deploying the NFT contract, the administrator device 10 can send a transaction that invokes the NFT contract to the blockchain 100 to mint the NFT resource. When the blockchain node executes the transaction to mint the NFT resource, it can mint the NFT resource by executing the NFT contract. Specifically, the administrator device 10 can store the key data of the NFT resource (such as TokenID, TokenURI, owner Owner) on the blockchain by executing the NFT contract, specifically, in the contract state of the NFT contract. After the above minting, the user device 30 (such as the device of the Owner) can retrieve the metadata of the NFT resource from the MSP server 20 using the TokenURI.

[0042] However, the above solution cannot guarantee the content correctness or integrity of the escrow data (including resource data and its metadata) of the NFT resources stored in the MSP server 20. In the application of digital NFT resources, there is a high demand for the correctness of the escrow data of the NFT resources. For example, artworks, game devices, and photos should not be tampered with. Therefore, in the embodiments of this specification, a solution for ensuring the data integrity of NFT resources is proposed. As Figure 1 shown, in this solution, a verification contract is also deployed in the blockchain 100 to verify the resource data and its metadata of the NFT resources stored in the MSP server 20 to ensure data integrity.

[0043] Figure 2 It is a flowchart of a method for minting an NFT resource in an embodiment of this specification. This method can be executed by Figure 1 the administrator device 10, the MSP server 20, and the blockchain nodes in the blockchain 100. The blockchain node can be any node in the blockchain 100. Among them, steps S201 - step S219 are preparation operations before minting the NFT resource. Each step shown below will be described in detail. Figure 2 shown.

[0044] First, in step S201, the MSP server 20 sends a registration request to the blockchain node. This registration request is used to request to register the MSP through the verification contract.

[0045] The verification contract provides a registration interface (e.g. Register()) for registering the MSP by calling the registration function. The registration interface is specifically Register(PK M , deposit), where PK M is the public key of MSP, and deposit is the registration deposit value. The MSP server can send a registration request by sending a transaction Tx1 to any blockchain node in the blockchain, where the sending account of transaction Tx1 is the blockchain account of MSP (e.g. Account M ), in transaction Tx1, the registration function in the verification contract is called through the registration interface, and the public key PK of MSP is used M The default deposit value is the input parameter of the registration function. It is understood that other required parameters can be passed in when calling the registration function in transaction Tx1, and there is no limitation on this.

[0046] In step S203, the blockchain node registers the MSP by executing the verification contract.

[0047] After receiving the above transaction Tx1, any blockchain node in the blockchain broadcasts the transaction Tx1 to other nodes in the blockchain, so that each node in the blockchain executes the transaction Tx1 to perform the MSP registration operation respectively.

[0048] When the blockchain node executes the transaction Tx1, it uses PK M The registration function in the verification contract is executed with deposit as the input parameter. Specifically, first, the blockchain node creates a deposit account Accounts[PK M ], as the deposit account of MSP, the deposit account is M Mapped account. Afterwards, the blockchain node can send the account according to the sending account of transaction Tx1. M and deposit, change the account to Account M The amount of the deposit in the variable Accounts[PK M ] as a deposit, that is, Accounts[PK M ]=deposit. In addition, the blockchain node also creates a frozen deposit account frozen[PK M ], and freeze the deposit account frozen[PK M ]=0. The Accounts[PK M ] in the public key PK MIt can be used as the identifier of the MSP to indicate that the MSP has been registered. It is understandable that other identifiers of the MSP (such as an account) can also be associated with the deposit account here to indicate that the MSP has been registered.

[0049] Among them, in the registration function Register(PK M , deposit), it can also be set that before setting the balance of the deposit account, first detect whether Accounts[PK M already exists. If it already exists, abort the execution and return "PK M has been registered". Additionally, in the registration function Register(PK M , deposit), it can also be set to determine whether deposit is less than the preset minimum value Min-deposit. If it is less, abort the execution and return "It needs to be greater than or equal to Min-deposit".

[0050] In step S205, the administrator device 10 sends a deployment request to the blockchain node to request the deployment of the NFT contract.

[0051] Specifically, the administrator device 10 can first develop the NFT contract to perform multiple operations related to the NFT resources. A protocol standard for the NFT resources is set through the code in this NFT contract. Then, the administrator device 10 can send a transaction Tx2 to any blockchain node in the blockchain. The receiving (To) field of this transaction Tx2 is empty to indicate that this transaction is for deploying the contract. The data (Data) field of this transaction Tx2 is the contract content of the NFT contract to be deployed, so as to deploy the NFT contract in the blockchain.

[0052] In one implementation, before deploying the NFT contract, the administrator device 10 can generate a metadata schema file (Metadata Schema, MS) for the NFT resources. This MS file is used to define the schema (or format) of the metadata. For example, this MS file includes multiple fields, as well as the definition of the positions of these multiple fields and the definition of the content of these multiple fields.

[0053] In an example, assuming that the resource data of the NFT resource is image data, the MS file of this MFT resource includes the following code:

[0054]

[0055] In the above code, the order includes fields such as "name", "description", "imageURI", etc. of the NFT resource, as well as descriptive limitations on these fields. Among them, the order defines the positions of these fields in the metadata.

[0056] In another example, the MS file may include the following code:

[0057]

[0058] This MS file adds an "imageHash" field compared to the MS file in the previous example, that is, it is defined that the metadata of the NFT resource includes the hash value of the image data, so that the image data can be verified according to the image hash value in the metadata to ensure the integrity of the image data.

[0059] After generating the MS file, the administrator device 10 can generate a transaction Tx2 and include the hash value (MSH) of this MS file in the data field of the transaction Tx2, so that after deploying the NFT contract, the NFT contract can be initialized through the MSH, that is, the MSH is stored in the contract state of the NFT contract.

[0060] When deploying the NFT contract, the administrator device 10 can also deploy an NFT application (APP) in the server. This NFT APP is used to manage the interaction operations between the owner of the NFT resource and the NFT contract. For example, it can call interfaces provided by the NFT contract and other interaction operations.

[0061] In step S207, the blockchain node deploys the NFT contract.

[0062] After receiving the transaction Tx2, any blockchain node in the blockchain broadcasts the transaction Tx2 to other nodes in the blockchain, so that each node (or all nodes) in the blockchain will execute the transaction Tx2 to deploy the NFT contract respectively.

[0063] When executing the transaction Tx2, the blockchain node generates the account address of the NFT contract (such as Addr1), and stores the contract content of the NFT contract in the contract state of the NFT contract in the state database according to the account address of the NFT contract, thus completing the deployment of the NFT contract. In the case where the MSH is included in the transaction Tx2, the blockchain node also initializes the NFT contract with the MSH, that is, stores the MSH in the contract state of the NFT contract. After this deployment, when the blockchain node executes a transaction that calls the NFT contract, it can obtain the code of the function included in the NFT contract from the state database according to the account address of the NFT contract and execute the code to perform the operations corresponding to the function.

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

[0065] Specifically, in the blockchain 100, a specific blockchain node (such as the node connected to the administrator device) can be set to return the contract address (such as Addr1) of the NFT contract to the administrator device 10. In one implementation, this address Addr1 is uniquely corresponding to the NFT resource, so it can be used as the identifier of this NFT resource.

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

[0067] The administrator device 10 can select the MSP for providing the metadata service and send a metadata service request to the server of this MSP (such as Figure 1 the MSP server 20 in it) to request the metadata service corresponding to the NFT resource. The metadata service request includes the identifier of the NFT resource, which is used to indicate the NFT resource corresponding to this metadata service. In one implementation, the identifier of this NFT resource can be the contract address Addr1 of the NFT contract. The metadata service request may also include the deposit value corresponding to this NFT resource. In addition, the metadata service request may also include the MS file, which is used to store the MS file in the MSP server. Among them, in the case where the MS file is included in this service request, the MSP server can store the mapping relationship between the MS file and the identifier of the NFT resource, which is used to read the MS file, where the identifier of the NFT resource can be the contract address Addr1 of the NFT contract or the identifier of the administrator device, etc.

[0068] In step S213, the MSP server 20 sends a registration request to the blockchain node, and this registration request is used to request to register the metadata service by verifying the contract.

[0069] After receiving the metadata service request from the administrator device 10, the MSP server 20 can send a transaction Tx3 to the blockchain node. The sending account of this transaction Tx3 is the account Account of the MSP M , and in the transaction Tx3, the registration interface provided by the verification contract (such as the function name recordService() of the registration function) is called to register the metadata service provided by the MSP in the blockchain. The incoming parameter of recordService() in this transaction Tx3 includes the identifier of the NFT resource (such as Addr1), which is used to indicate that this metadata service corresponds to the above NFT resource.

[0070] Specifically, in the case where the MS file is included in the above metadata service request, the MSP server 20 can first send a transaction to the blockchain node to call the interface getMetadataSchemaHash() provided by the NFT contract according to the contract address Addr1, so as to obtain the MSH corresponding to the MS file. After executing the transaction, the blockchain node reads the MSH deposited in the contract state during the above contract initialization from the contract state of the NFT contract and returns the MSH to the MSP server 20. After obtaining the MSH, the MSP server 20 calculates the 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. In the case where the MSP server 20 verifies that the MS file is correct, it stores the MS file locally so that the MS file can be read according to the MSH. That is to say, assuming that the MSP server corresponds to the URI " http: / / msp_server / ", then the URI of the MS file can be " http: / / msp_server / MSH", that is, other devices can read the MS file from the MSP server 20 through " http: / / msp_server / MSH".

[0071] In the case where the above metadata service request further includes a deposit value corresponding to the NFT resource (for example, represented by Deposit N ), when the MSP accepts the deposit value, it sends a transaction Tx3 to the blockchain node through the MSP server 20. The incoming parameter of recordService() in the transaction Tx3 further includes the deposit value Deposit N . In another implementation, a preset deposit value (DEPOSIT_PER_SERVICE) corresponding to each NFT resource can be preset in the verification contract, so that there is no need to include the deposit value in the incoming parameter of recordService().

[0072] In addition, the MSP server 20 can also sign the combination of Addr1 and MSH to obtain sig1, and the incoming parameter of recordService() in the transaction Tx3 further includes MSH and the signature sig1. The signature sig1 is, for example,

[0073] SIGN(PVK M , Addr1||MSH), where the symbol || represents concatenating Addr1 and MSH, and this signature is obtained by encrypting Addr1||MSH with the private key PVK M of the MSP's account.

[0074] In addition, in the blockchain node, through the public key PK MIn the case of identifying the MSP, the MSP server 20 may also include the public key PK of the MSP in the incoming parameters of recordService() in the transaction Tx3. M .

[0075] In step S215, the blockchain node records the metadata service provided by the MSP in the contract state of the verification contract.

[0076] After receiving the transaction Tx3 from the MSP server 20, the blockchain node broadcasts the transaction Tx3 to other nodes in the blockchain, so that each node in the blockchain executes the transaction Tx3.

[0077] When executing the transaction Tx3, the blockchain node first checks whether the metadata service corresponding to the NFT resource has been recorded in the contract state of the verification contract. Specifically, it can check whether the metadata service associated with Addr1 has been recorded. In the case where it is determined that the metadata service corresponding to the NFT resource has not been recorded, the metadata service provided by the MSP corresponding to the NFT resource is recorded in the contract state of the verification contract.

[0078] Specifically, when using the public key PK of the MSP M as the identifier of the MSP, the incoming parameters of recordService() in the transaction Tx3 include Addr1 and PK M , and the blockchain node records PK M and Addr1 in the contract state of the verification contract in an associated manner.

[0079] When the incoming parameters of the transaction Tx3 also include the deposit value Deposit N corresponding to the NFT resource, when executing the transaction Tx3, the blockchain node first checks whether the value of the deposit account Accounts[PK M -frozen[PK M is greater than or equal to the deposit value Deposit N . In the case where the detection result is yes, the blockchain node records PK M and Addr1 in the contract state of the verification contract in an associated manner. After that, the blockchain node increases the balance of frozen[PK M by the frozen amount of Deposit N . The frozen amount equal to Deposit N is used to separately withdraw from Accounts[PK M and frozen[PK M when the blockchain node determines that the escrow data corresponding to the NFT resource stored in the MSP server is incorrect.It is deducted from the account balance of [], so that it can be used to supervise the services provided by the MSP.

[0080] In the case where the incoming parameters of recordService() in transaction Tx3 also include the signature sig1 of MSH and MSP for Addr1||MSH, the blockchain node also uses PK M to verify sig1. After the verification passes, PK, M MSH, and sig1 are recorded in the contract state of the verification contract in association with Addr1.

[0081] In step S217, the administrator device 10 uploads the escrow data of the NFT resource to the MSP server 20.

[0082] After the administrator device 10 determines that the MSP server 20 has registered the metadata service provided by the MSP for the NFT resource on the chain, it can upload the escrow data of the NFT resource to the MSP server 20. The escrow data may include the resource data of the NFT resource and the corresponding metadata. For example, the resource data of the NFT resource may be image data, and the metadata may be a metadata json object.

[0083] The 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:

[0084]

[0085] In step S219, the MSP server 20 generates the TokenURI of the metadata of the NFT resource and stores the metadata.

[0086] After the MSP server 20 receives the resource data (such as an image) and metadata of the NFT resource received by the administrator device, it uses the image hash value (imageHash) in the metadata to verify whether the image is correct. The MSP server 20 can also verify whether the uploaded metadata conforms to the MS corresponding to the NFT resource stored in advance. Specifically, the MSP server 20 can read the MS file stored in advance according to the mapping relationship between the MS file stored in advance and the identifier of the NFT resource, so as to verify the metadata using the MS file.

[0087] In the case of correct verification, the blockchain node stores the uploaded image, generates the URI of the image, and stores the URI of the image in the imageURI field in the metadata, so as to generate the complete metadata as shown below:

[0088]

[0089] After that, the MSP server 20 will generate a URI for storing the metadata (hereinafter referred to as tokenURI), and the tokenURI may have the following form, for example: {baseURI / MSH / MH}. Wherein, 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. By including MSH and MH in the tokenURI, it can be used to verify the integrity of the NFT resource data subsequently.

[0090] It can be understood that in the embodiments of this specification, the TokenURI is not limited to the above description, as long as the TokenURI can uniquely identify the metadata of the NFT resource. For example, in the case where the schema of the metadata does not require compliance with a specific MS, the generated TokenURI may have the following form {baseURI / MH}, or the TokenURI may have the following form

[0091] {baseURI / TokenID}, etc., which are not limited herein. Wherein, in the case where MH is not included in the TokenURI, MH can be stored in the contract state of the contract for verifying the metadata.

[0092] After generating the TokenURI, the MSP can store the metadata generated by the MSP server at the position pointed to by the TokenURI.

[0093] In step S221, the MSP server 20 returns the tokenURI to the administrator device 10.

[0094] After receiving the tokenURI, the administrator device 10 can retrieve the metadata from the MSP server 20 according to the tokenURI and verify whether the content of the metadata is correct. Specifically, the administrator device 10 can first verify whether MSH and MH correspond to the correct MS and metadata, and then verify whether the hash value of the metadata read from the MSP server 20 is equal to MH. The administrator device 10 can also obtain the imageURI from the metadata, read the image from the MSP server 20 according to the imageURI, and verify whether the image is correct. For example, the administrator device 10 can verify whether the hash value of the image is equal to the imageHash in the metadata.

[0095] In addition to returning the TokenURI to the administrator device 10, the MSP server 20 can also use the private key (PVK M ) of the MSP to sign the TokenURI to obtain the signature sig2 = SIGN(PVK M, TokenURI), and also returns the signature sig2 to the administrator device 10. After receiving the signature sig2, the administrator device 10 can use the pre-acquired public key (PK M ) of the MSP to verify the signature sig2. For example, the administrator device 10 can obtain the public key of the MSP by sending a transaction that invokes the interface for querying the MSP public key provided by the verification contract to the blockchain 100. Specifically, when invoking this interface, the administrator device 10 can pass in the parameter Addr1, so as to obtain the PK M associated with Addr1 in the contract state of the verification contract.

[0096] In step S223, the administrator device 10 sends a minting request to the blockchain node to request minting an NFT resource based on the TokenID, Owner, and TokenURI through the NFT contract.

[0097] In the case where all the above verifications pass, the administrator device 10 can call the minting interface provided by the NFT contract to mint the NFT resource. Specifically, the administrator device 10 can send a transaction Tx4 to the blockchain node, and this transaction Tx4 can call the minting interface Mint(TokenID, Owner, TokenURI) provided by the NFT contract with TokenID, Owner, and TokenURI as the input parameters. In one implementation, the input parameters for the minting interface in the transaction Tx4 can further include the above-mentioned signature sig2 of the MSP to ensure the correctness of the TokenURI.

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

[0099] After receiving the transaction Tx4, the blockchain node broadcasts the transaction Tx4 to other nodes in the blockchain, so that each node in the blockchain will execute the transaction Tx4.

[0100] Specifically, when executing the transaction Tx4, the blockchain node executes the function Mint(TokenID, Owner, TokenURI), first determines whether 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, associates and records the TokenID, Owner, and TokenURI in the contract state of the NFT contract, thus completing the minting of the NFT resource.

[0101] In the case where the input parameter of the function Mint also includes sig2, when the blockchain node executes the function Mint, it first executes the public key acquisition interface provided by the verification contract called in the function Mint to obtain the public key (PK M ) of the MSP corresponding to the NFT resource (i.e., Addr1) from the contract state of the verification contract. Specifically, the function Mint calls the public key acquisition interface with the contract address of the NFT contract as the input parameter. Thus, when the blockchain node executes the public key acquisition interface, it can read the public key of the association record associated with the address of the NFT contract from the contract state of the verification contract, and the public key of this association record is the public key (PK M ) of the MSP corresponding to the NFT resource. After the blockchain node obtains the public key PK M , it uses the public key PK M to verify the signature sig2. If the verification passes, TokenID, Owner, TokenURI, and sig2 are associated and recorded in the contract state of the NFT contract.

[0102] It can be understood that in the above embodiment, since MSH and MH are included in TokenURI, there is no need to separately store data such as MSH and MH in the contract state of the NFT contract. The embodiments of this specification are not limited to this. For example, in the case where MSH and MH are not included in TokenURI, MH or both MH and MSH can also be stored in the contract state of the NFT contract by executing transaction Tx4.

[0103] After the minting of the NFT resource is completed as described above, the user of the blockchain (such as the player or owner of the NFT resource) can verify the data of the NFT resource stored in the MSP server through the verification contract, so as to ensure the correctness of the data.

[0104] Figure 3 FIG. is a flowchart of the data verification method in an embodiment of this specification. This method can be executed by the user device 30, the MSP server 20, and the blockchain node.

[0105] As Figure 3 shown, in step S301, the user device 30 reads the URI data and verification data of the NFT resource from the blockchain node.

[0106] The user corresponding to the user device 30 can participate in collecting or transferring (selling) NFT resources. Therefore, the user needs to verify the escrow data of the NFT resources stored in the MSP server 20 to determine that the escrow data is correct. To this end, the user device 30 can first read the URI data and verification data of the NFT resource from any blockchain node in the blockchain 100 according to the tokenID of the NFT resource. Among them, the URI data is used to locate the storage location of the escrow data of the NFT resource stored in the MSP server, and the verification data is used to verify the escrow data. In the embodiments of this specification, the URI data includes, for example, tokenURI, and the metadata of the NFT resource can be read from the MSP server through the tokenURI. After the user device 30 reads the metadata, it can read the imageURI of the resource data (such as an image) of the NFT resource from the metadata, and the image of the NFT resource can be read from the MSP server through the imageURI. The user device 30 can also read the URI corresponding to the MS file from the blockchain node. In the case where the URI of the MS file is {baseURI / MSH}, the user device 30 can read MSH from the blockchain node to obtain the URI corresponding to the MS file.

[0107] The verification data includes, for example, MH for the user to verify the metadata, or may include MH and MSH for verifying the metadata schema, etc. In the embodiments of this specification, since the tokenURI includes MH or includes MH and MSH, the user device 30 only needs to read the tokenURI from the blockchain node. Specifically, the user device 30 can send a transaction Tx5 to the blockchain node. The transaction Tx5 calls the reading interface provided by the NFT contract and passes the tokenID to the reading interface. When executing the transaction Tx5, the blockchain node can obtain the tokenURI according to the tokenID and return the tokenURI of the NFT resource to the user device 30. In addition, the verification data may further include the signature sig2 of the MSP for the tokenURI stored in the contract state of the NFT contract. In this case, when executing the transaction Tx5, the blockchain node can also obtain sig2 according to the tokenID and return sig2 to the user device 30.

[0108] In step S303, the user device 30 reads the escrow data of the NFT resource from the MSP server 20 according to the URI data.

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

[0110] In step S305, the user device 30 verifies the escrow data according to the verification data.

[0111] The user device 30 can use the MH in the verification data to verify the metadata of the NFT resource. Specifically, the user device 30 calculates the hash value of the metadata in the escrow data and compares whether the hash value is equal to MH to verify whether the metadata is correct. If they are equal, the verification passes; if not, the verification fails. The user device 30 can also obtain the hash value of the resource data (such as imageHash) from the metadata and use the imageHash to verify whether the image of the NFT resource is correct.

[0112] In the case where the MS is included in the escrow data, the MSH is also included in the verification data. After the user device 30 passes the verification of the metadata, it can use the MSH to verify whether the MS file is correct and verify whether the mode of the metadata conforms to the settings in the MS file. In the case where the above verification passes, the user device 30 then obtains the hash value of the resource data (such as imageHash) from the metadata and uses the imageHash to verify whether the image of the NFT resource is correct.

[0113] In step S307, in the case where any of the above verifications fails, the user device 30 sends a verification request to the blockchain node to request to verify the escrow data through the verification contract.

[0114] Specifically, the user device 30 can send a transaction Tx6 to the blockchain node. For example, the report interface report(addr1,tokenURI,sig2) provided in the verification contract is called in the transaction Tx6 to request to verify the escrow data corresponding to addr1 through the verification contract.

[0115] In step S309, the blockchain node instructs the trusted device to verify the escrow data by executing the verification contract.

[0116] After receiving the transaction Tx6, the blockchain node broadcasts the transaction Tx6 to other nodes in the blockchain 100, so that each blockchain node will execute the transaction Tx6.

[0117] Specifically, when the blockchain node executes transaction Tx6, it first obtains the public key of the MSP according to addr1 and PK associated and recorded in the verification contract state M , and uses PK M to verify sig2 to verify whether the tokenURI is valid. The blockchain node can also read the MSH associated with Addr1 in the verification contract state and use the MSH to verify whether the MSH in the tokenURI is correct. In the case of successful verification, the blockchain node can call the verification service provided by a trusted device (such as an Oracle) so that the trusted device verifies the escrow data stored in the MSP server according to the tokenURI

[0118] When the trusted device executes this call, it can verify the escrow data in the same way 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 uses the MSH in the tokenURI to verify the MS file, uses the MH in the tokenURI to verify the metadata, and then verifies whether the mode of the metadata conforms to the MS file. After the above verification passes, the resource data (such as an image) of the NFT resource is read from the MSP server 20 through the imageURI in the metadata, and the read image is verified through the imageHash in the metadata. After the trusted device performs the above verification, it returns the verification result to the blockchain node

[0119] In step S311, when the blockchain node includes any item with failed verification in the above returned verification result, it deducts the preset deposit corresponding to the NFT resource from the deposit account of the MSP set in the verification contract

[0120] Specifically, the blockchain node can obtain the deposit value Deposit corresponding to the NFT resource from the contract state of the verification contract N , and deduct Deposit M from Accounts[PK M and frozen[PK N in the contract state of the verification contract respectively

[0121] In the embodiments of this specification, the data hosting service provided by the MSP is recorded by verifying the contract, and the MSP is punished when there are problems with the service provided by the MSP through the verification contract to ensure the correctness and integrity of the hosted data stored in the MSP server. Through the solution provided by the embodiments of this specification, NFT players can be more confident that their collections have not been tampered with. The NFT administrator can enjoy the worry-free service provided by the MSP. The MSP can obtain benefits by providing such services, and the reputation of the MSP is recorded through the blockchain, strengthening the supervision of the MSP. NFT players do not need to trust any party to maintain the integrity and correctness of the metadata.

[0122] Figure 4 A blockchain node in an embodiment of this specification, where the blockchain deploys a first smart contract, and the blockchain node includes:

[0123] A receiving unit 41, configured to receive a first transaction, where the first transaction invokes the first smart contract, and the first transaction includes second data, the second data includes the storage location information of the first data, and is used to verify the first data, and the first data is stored in an off-chain server;

[0124] An execution unit 42, configured to, by executing the first smart contract invoked by the first transaction, instruct a trusted device to verify the first data based on the second data.

[0125] In an implementation manner, the off-chain server is a service provider server, the contract state of the first smart contract includes the balance of a first account, the first account corresponds to the service provider, and the account balance of the first account includes a freezing amount corresponding to the first data. The blockchain node further includes: a deduction unit, configured to, in the case where the verification fails, deduct the freezing amount from the account balance of the first account.

[0126] In an implementation manner, the receiving unit 41 is further configured to receive a second transaction before receiving the first transaction, the sending account of the second transaction is a second account of the service provider, and the second transaction invokes the first smart contract and includes the public key of the first account and a first amount;

[0127] The blockchain node further includes a creation unit, configured to, by executing the first smart contract invoked by the second transaction, create the first account corresponding to the public key in the contract state of the first smart contract, and transfer the first amount of the second account to the first account.

[0128] In one implementation, the execution unit 42 is further configured to create a frozen account corresponding to the public key in the contract state of the first smart contract by executing the first smart contract called by the second transaction;

[0129] After the receiving unit 41 finishes executing the second transaction, it receives a third transaction. The third transaction calls the first smart contract. The third transaction includes the identifier of the first data and the public key. The sending account of the third transaction is the second account, which is sent by the service provider server in response to a service request from the user device. The service request includes the identifier of the first data;

[0130] The execution unit 42 is further configured to: by executing the first smart contract called by the third transaction, increase the frozen amount corresponding to the first data in the balance of the frozen account, and store the public key in association with the identifier of the first data in the contract state of the first smart contract.

[0131] In one implementation, the first transaction further includes the identifier of the first data and the signature of the second account on the second data. 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 the trusted device to verify the first data based on the second data.

[0132] In one implementation, the first data is the metadata of the resource data of the on-chain resource. The first data includes the storage location information of the resource data and the hash value of the resource data. The execution unit 42 is further configured to: verify the resource data according to the storage location information of the resource data and the hash value of the resource data.

[0133] In one implementation, the service provider server further stores fourth data. The fourth data includes the mode information of the first data. The second data further includes fifth data for verifying the fourth data. The execution unit 42 is further configured to: by executing the first smart contract called by the first transaction, instruct the trusted device to verify the fourth data based on the fifth data, and verify whether the first data conforms to the mode indicated in the fourth data.

[0134] In one implementation, a second smart contract corresponding to the on-chain resource is deployed in the blockchain. The identifier of the first data is the account address of the second smart contract.

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

[0136] The execution unit 42 is further configured to store the second data and the signature of the second account on the second data in the contract state of the second smart contract by executing the second smart contract invoked by the fourth transaction.

[0137] In an implementation, the third transaction further includes sixth data for verifying the fourth data. The sixth data is obtained by the service party server from the blockchain node. The execution unit 42 is further configured to: store the sixth data in the contract state of the first smart contract in an associated manner with the identifier of the first data by executing the first smart contract invoked by the third transaction.

[0138] In an implementation, the execution unit 42 is further configured to, before instructing the trusted device to verify the first data based on the second data, obtain the sixth data based on the identifier of the first data and use the sixth data to verify the fifth data.

[0139] An embodiment of this specification further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed on a computer, the computer is made to execute as Figure 2 and Figure 3 shown in the method.

[0140] An embodiment of this specification further provides a blockchain node, including a memory and a processor. An executable code is stored in the memory. When the processor executes the executable code, the method as Figure 2 and Figure 3 shown is implemented.

[0141] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to method flows). However, with the development of technology, many method flow improvements today can be regarded as direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement to a method flow cannot be implemented using a hardware entity module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logical function is determined by the user programming the device. The designer programs it himself to "integrate" a digital system onto a single PLD, without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL), and there is not just one type of HDL, but many types, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones currently are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply making a little logical programming of the method flow using the above-mentioned several hardware description languages and programming it into an integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0142] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as 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 the controller include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same function. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or the structures within the hardware component.

[0143] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the development of future computer technologies, the computers for implementing the functions of the above embodiments can be, for example, personal computers, laptop computers, in-vehicle human-machine interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

[0144] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way among the execution orders of numerous steps and does not represent the only execution order. When the actual device or terminal product is executed, it may be executed in the order of the method shown in the embodiments or the drawings or executed in parallel (such as in an environment of parallel processors or multi-threaded processing, or even in a distributed data processing environment). The terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, product or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, product or device. Without further limitation, it does not exclude the existence of additional identical or equivalent elements in the process, method, product or device including the said elements. For example, if terms such as first and second are used to denote names, they do not denote any particular order.

[0145] For convenience of description, when describing the above device, it is divided into various modules according to functions for separate description. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and / or hardware, or the modules implementing the same function can be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the couplings or direct couplings or communication connections shown or discussed among each other can be through some interfaces. The indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

[0146] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, and the combination of processes and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for realizing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0147] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufacture including an instruction device that implements the function specified in one process Figure 1 or more processes and / or blocks Figure 1 or more blocks specified in the block.

[0148] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are performed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the function specified in one process Figure 1 or more processes and / or blocks Figure 1 or more blocks specified in the block.

[0149] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0150] The memory may include non-permanent memory in the computer-readable medium, in the form of 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.

[0151] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology for information storage. The information can be computer-readable instructions, data structures, program modules, 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 technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0152] Those skilled in the art should understand that one or more embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0153] One or more embodiments of this specification can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification can also be practiced in a distributed computing environment, where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0154] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and reference can be made to the corresponding parts of the method embodiments for the relevant content. In the description of this specification, the description with reference to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0155] The above description is only for the embodiments of one or more embodiments of this specification and is not used to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims.

Claims

1. A data verification method, executed by a node of a blockchain. The blockchain deploys a first smart contract, and the contract state of the first smart contract includes the balance of a first account. The first account corresponds to a service provider, and the account balance of the first account includes a frozen amount corresponding to first data. The method includes: Receiving a first transaction that invokes the first smart contract. The first transaction includes second data, which includes storage location information of the first data and is used to verify the first data. The first data is stored in an off-chain server and is escrow data. By executing the first smart contract invoked by the first transaction, instructing a trusted device to verify the first data based on the second data. In the case where the verification fails, deducting the frozen amount from the account balance of the first account. Receiving a second transaction before receiving the first transaction. The sending account of the second transaction is a second account of the service provider. The second transaction invokes the first smart contract and includes the public key of the first account and a first amount. By executing the first smart contract invoked by the second transaction, creating the first account corresponding to the public key in the contract state of the first smart contract, and transferring the first amount of the second account to the first account. By executing the first smart contract invoked by the second transaction, creating a frozen account corresponding to the public key in the contract state of the first smart contract. Receiving a third transaction after the second transaction is executed. The third transaction invokes the first smart contract. The third transaction includes the identifier of the first data and the public key, and the sending account of the third transaction is the second account, which is sent by the service provider's server in response to a service request from a user device. The service request includes the identifier of the first data. By executing the first smart contract invoked by the third transaction, increasing the frozen amount corresponding to the first data in the balance of the frozen account, and storing the public key in association with the identifier of the first data in the contract state of the first smart contract.

2. The method according to claim 1, wherein, The first transaction further includes the identifier of the first data and the signature of the second account on the second data. The method further includes, before instructing the trusted device to verify the first data based on the second data, obtaining the public key based on the identifier of the first data, and using the public key to verify the signature.

3. According to the method described in claim 2, the first data is the metadata of the resource data of the on-chain resource, and the first data includes the storage location information of the resource data and the hash value of the resource data. The verification of the first data includes: Verifying the resource data according to the storage location information of the resource data and the hash value of the resource data.

4. According to the method described in claim 1, fourth data is further stored in the service provider server, the fourth data includes the mode information of the first data, the second data further includes fifth data for verifying the fourth data, and the verification of the first data further includes: By executing the first smart contract invoked by the first transaction, instructing a trusted device to verify the fourth data based on the fifth data, and verifying whether the first data conforms to the pattern indicated in the fourth data.

5. The method according to claim 4, wherein a second smart contract corresponding to an on-chain resource is deployed in the blockchain, and the identifier of the first data is the account address of the second smart contract. The method further includes: Receive a fourth transaction that invokes the second smart contract, where the fourth transaction includes the second data and the signature of the second account for the second data; By executing the second smart contract invoked by the fourth transaction, store the second data and the signature of the second account for the second data in the contract state of the second smart contract.

6. The method according to claim 5, wherein the third transaction further includes sixth data for verifying the fourth data, the sixth data is obtained by the service provider server from the blockchain node, and the method further includes: By executing the first smart contract invoked by the third transaction, store the sixth data in the contract state of the first smart contract in association with the identifier of the first data.

7. The method according to claim 6, the method further includes, before instructing a trusted device to verify the first data based on the second data, obtaining the sixth data based on the identifier of the first data, and using the sixth data to verify the fifth data.

8. A blockchain node, where a first smart contract is deployed on the blockchain, an off-chain server is a service provider server, the contract state of the first smart contract includes the balance of a first account, the first account corresponds to the service provider, and the account balance of the first account includes a frozen amount corresponding to the first data. The blockchain node includes: A receiving unit, configured to receive a first transaction that invokes the first smart contract, where the first transaction includes second data, the second data includes storage location information of the first data and is used to verify the first data, the first data is stored in the off-chain server, and the first data is escrow data; An execution unit, configured 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 deduction unit, configured to deduct the frozen amount from the account balance of the first account in case the verification fails; The execution unit is further configured to receive a second transaction before receiving the first transaction, where the sending account of the second transaction is a second account of the service provider, the second transaction invokes the first smart contract and includes the public key of the first account and a first amount; A creation unit, configured to create the first account corresponding to the public key in the contract state of the first smart contract by executing the first smart contract invoked by the second transaction, and transfer the first amount of the second account to the first account; The execution unit is further configured to create a frozen account corresponding to the public key in the contract state of the first smart contract by executing the first smart contract invoked by the second transaction; The receiving unit is further configured to receive a third transaction after the execution of 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, the sending account of the third transaction is the second account, and is sent by the service provider server in response to a service request of a user device, and the service request includes the identifier of the first data; The execution unit is further configured to: by executing the first smart contract called by the third transaction, increase the frozen amount corresponding to the first data in the balance of the frozen account, and store the public key in association with the identifier of the first data in the contract state of the first smart contract.

9. A computer-readable storage medium, on which a computer program is stored. When the computer program is executed on a computer, the computer is made to execute the method according to any one of claims 1-7.

10. A blockchain node, comprising a memory and a processor. An executable code is stored in the memory. When the processor executes the executable code, the method according to any one of claims 1-7 is implemented.

Images