CN116226277A

CN116226277A - NFT resource transfer method and block chain link point

Info

Publication number: CN116226277A
Application number: CN202211738659.8A
Authority: CN
Inventors: 王莹
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-12-30
Filing date: 2022-12-30
Publication date: 2023-06-06

Abstract

An NFT resource transfer method and blockchain node, the method comprising: receiving a first transaction, wherein the first transaction is used for transferring the NFT resources of a first account to a second account, and account information corresponding to the first account stored in a blockchain comprises resource identifiers of the NFT resources; and deleting the resource identifier of the NFT resource in the account information corresponding to the first account according to the first transaction, and adding the resource identifier of the NFT resource in the account information corresponding to the second account stored in the blockchain.

Description

NFT resource transfer method and block chain link point

Technical Field

The embodiment of the specification belongs to the technical field of blockchain, and particularly relates to an NFT resource transfer method and a blockchain node.

Background

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. In the block chain system, the data blocks are combined into a chain data structure in a sequential connection mode according to the time sequence, and the distributed account book which is not tamperable and counterfeit and is ensured in a cryptographic mode is formed. Because the blockchain has the characteristics of decentralization, non-tamperability of information, autonomy and the like, the blockchain is also receiving more and more attention and application.

Digital resources, which are typically characterized as Non-replaceable, limitable, indivisible, etc., can be generated in a blockchain based on Non-homogeneous token (NFT) technology. Different blockchains may use different NFT protocol standards to generate digital resources. The currently prevailing protocol standards include ERC721, ERC1155, ERC998, and the like. Wherein 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. In the above protocol standard, the home account of the NFT resource is typically recorded in a contract state.

Disclosure of Invention

The invention aims to provide a scheme for NFT resource transfer, which improves the transfer efficiency of NFT resources.

A first aspect of the present disclosure provides a NFT resource transfer method performed by a block link point, including:

receiving a first transaction, wherein the first transaction is used for transferring an NFT resource of a first account to a second account, and account information corresponding to the first account stored in the blockchain comprises a resource identifier of the NFT resource;

and deleting the resource identifier of the NFT resource in the account information corresponding to the first account according to the first transaction, and adding the resource identifier of the NFT resource in the account information corresponding to the second account stored in the blockchain.

In one embodiment, the account information corresponding to the first account includes an account address of a first NFT account associated with the first account, and deleting the resource identifier of the NFT resource in the account information corresponding to the first account includes: and deleting the resource identifier of the NFT resource in the account information of the first NFT account according to the account address of the first NFT account.

In one embodiment, the account information corresponding to the second account includes an account address of a second NFT account associated with the second account, and the first transaction includes the account address of the first NFT account and the account address of the second NFT account.

In one embodiment, the method further comprises: a signature of the first transaction generated based on a private key of the first account is received, the signature being verified based on a public key of the first account.

In one embodiment, the method further comprises: and acquiring a state root hash value of a state tree corresponding to the block to which the first transaction belongs, and respectively updating the state root hash value of the state tree in the account information corresponding to the first account and the account information corresponding to the second account.

In one embodiment, the method further comprises:

receiving a second transaction, the second transaction sent by the first account for casting the NFT resource;

and generating a resource identifier of the NFT resource according to the second transaction, and adding the resource identifier of the NFT resource in the account information corresponding to the first account.

In one embodiment, the method further comprises:

receiving a third transaction, wherein the third transaction is used for querying NFT resources owned by the first account;

and according to the third transaction, acquiring the resource identification of the NFT resource owned by the first account from the account information corresponding to the first account, and returning a query result according to the resource identification of the NFT resource owned by the first account.

A second aspect of the present specification provides a blockchain node comprising:

the system comprises a receiving unit, a processing unit and a processing unit, wherein the receiving unit is used for receiving a first transaction, the first transaction is used for transferring NFT resources of a first account to a second account, and account information corresponding to the first account stored in the blockchain comprises resource identifiers of the NFT resources;

and the transferring unit is used for deleting the resource identifier of the NFT resource in the account information corresponding to the first account according to the first transaction, and adding the resource identifier of the NFT resource in the account information corresponding to the second account stored in the blockchain.

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

A fourth aspect of the present specification provides a computing device comprising a memory having executable code stored therein and a processor which when executing the executable code implements the method of the first aspect.

In the embodiment of the specification, a new account mode is provided, and the external account contains the NFT resource information, so that the transfer of the NFT resource can be directly carried out between the external accounts, the interaction between contracts is effectively reduced, the transaction cost is also reduced, and the query efficiency of the NFT resource is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 illustrates a block chain architecture diagram in one embodiment;

FIG. 2 is a flow chart of a NFT resource transfer method in an embodiment of the present disclosure;

FIG. 3 is a schematic diagram of account information for an account in an embodiment of the present disclosure;

fig. 4 is a flowchart of a method for querying NFT resources corresponding to an account in an embodiment of the present disclosure;

FIG. 5 is a block chain node architecture diagram in an embodiment of the present disclosure.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, 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 some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

FIG. 1 illustrates a block chain architecture diagram in one embodiment. In the blockchain architecture diagram shown in fig. 1, the blockchain includes, for example, 6 nodes from node 1 to node 6. The connections between nodes are schematically represented as P2P (Peer to Peer) connections. The nodes may store a full amount of ledgers, i.e., the state of all blocks and all accounts. Wherein each node in the blockchain may generate the same state in the blockchain by performing the same transaction, each node in the blockchain may store the same state database. It will be appreciated that while 6 nodes are shown in FIG. 1 as being included in a blockchain, embodiments of the present description are not so limited, but may include other numbers of nodes. Specifically, the nodes included in the blockchain may meet the bayer fault tolerance (Byzantine Fault Tolerance, BFT) requirements. The bayer fault tolerance requirement is understood to be that the bin node may exist inside the blockchain, and the blockchain does not show the bin behavior. In general, some bayer fault-tolerant algorithms require a node number greater than 3f+1, where f is the number of bayer nodes, e.g., the practical bayer fault-tolerant algorithm PBFT (Practical Byzantine Fault Tolerance).

Transactions in the blockchain domain may refer to task units that execute in the blockchain and are recorded in the blockchain. The transaction typically includes a send field (From), a receive field (To), and a Data field (Data). Where the transaction is a transfer transaction, the From field indicates an account address From which the transaction was initiated (i.e., a transfer task To another account was initiated), the To field indicates an account address From which the transaction was received (i.e., a transfer was received), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract in a blockchain, the From field represents the account address From which the transaction originated, the To field represents the account address of the contract that the transaction called, and the Data field includes Data, such as the name of the function in the calling contract, and the incoming parameters To the function, for retrieving the code of the function From the blockchain and executing the code of the function when the transaction is executed.

The functionality of the smart contract may be provided in the blockchain. Intelligent contracts on blockchains are contracts on blockchain systems that can be executed by transaction triggers. The smart contracts may be defined in the form of codes. Invoking the smart contract in the blockchain initiates a transaction directed to the smart contract address such that each node in the blockchain runs the smart contract code in a distributed manner. It should be noted that, in addition to the smart contracts that can be created by the user, the smart contracts can also be set by the system in the creation block. Such contracts are commonly referred to as an opening contract. In general, some blockchain data structures, parameters, properties, and methods may be set in the creating contract. In addition, an account with system administrator rights may create a system level contract, or modify a system level contract (simply referred to as a system contract). Wherein the system contracts can be used to add data structures for data of different services in the blockchain.

In the scenario of deploying contracts, for example, bob sends a transaction containing information to create an intelligent contract (i.e., deploying a contract) into a blockchain as shown in fig. 1, the data field of the transaction includes the code (e.g., bytecode or machine code) of the contract to be created, and the to field of the transaction is empty to indicate that the transaction is for deploying the contract. After agreement is reached between nodes through a consensus mechanism, determining a contract address '0 x6f8ae93 …' of the contract, adding a contract account corresponding to the contract address of the intelligent contract in a state database by each node, distributing a state storage corresponding to the contract account, and storing a contract code in the state storage of the contract, so that the contract is successfully created.

In the scenario of invoking a contract, for example, bob sends a transaction for invoking a smart contract into a blockchain as shown in fig. 1, the from field of the transaction is the address of the account of the transaction initiator (i.e., bob), the "0x6f8ae93 …" in the to field represents the address of the invoked smart contract, and the data field of the transaction includes the method and parameters for invoking the smart contract. After the transaction is consensus in the blockchain, each node in the blockchain may execute the transaction separately, thereby executing the contract separately, updating the status database based on execution of the contract.

The intelligent contracts deployed in the blockchain may include NFT intelligent contracts, which may be code on the blockchain that enables NFT functionality. For example, NFT functions may include coin functions, transfer functions, query functions, and so forth. Here, the coinage function may be used to create NFT resources in the blockchain, and specifically, to document the resource identification and attributes of NFT resources in the contract state of NFT smart contracts in the blockchain. The transfer function may be used to transfer NFT resources from a current owner to another user. The query function may be used to query attribute information of NFT resources.

In the related art, processing is performed on NFT resources based on an ERC1155 protocol, the ERC1155 protocol supports multiple types of certificates, multiple resources can be transferred in one call by the NFT contract based on the ERC1155 protocol, home accounts of the NFT resources are stored in contract states of the NFT contract, when other accounts wish to inquire whether a specific account owns the NFT resources, whether the home account of the NFT resources is the specific account needs to be inquired by calling the NFT contract, and when the angel accounts wish to transfer the NFT resources to other accounts, transfer of the NFT resources needs to be performed by calling the NFT contract, so that the inquiring or transferring mode is low in efficiency, and transaction execution efficiency of a blockchain system is reduced.

According to the NFT resource transfer scheme, the information of the NFT resource owned by the external account is included in the account information corresponding to the external account, so that whether the external account owns the NFT resource or not can be determined by inquiring the information corresponding to the external account, and NFT resource transfer can be directly carried out between the external accounts, and the processing efficiency of the NFT resource is effectively improved.

Fig. 2 is a flowchart of an NFT resource transfer method in an embodiment of the present specification, which may be performed by any node in a blockchain, including the following steps S201 and S203.

First, in step S201, the block link point receives a transaction Tx1, where the transaction Tx1 is used to transfer the NFT resource of Account1 to Account2.

Assuming Account Account1 is the Account of user A, user A may cast NFT resources by sending a transaction to the blockchain invoking the smart contract, the sending Account of the transaction being Account1. The node in the blockchain executes the transaction after receiving the transaction, generates a resource identifier (for example, token id 1) of the newly cast NFT resource, and adds the resource identifier of the newly cast NFT resource to Account information corresponding to the Account1 based on the Account mode in the embodiment of the present specification, so as to indicate that the Account1 owns the NFT resource.

Fig. 3 is a schematic diagram of Account information of an Account (e.g., account 1) in the embodiment of the present specification. The account information shown in fig. 3 is stored in a state database stored in each node in the blockchain, wherein the state database comprises account states of various accounts (including external accounts and contract accounts) in the blockchain, and the account states of the accounts are stored in a form of a state tree. As shown in fig. 3, account1 is an external Account, i.e., the user's Account. NFT resource information is included in the state information of Account1.

In one embodiment, the NFT resource information shown in fig. 3 includes information about NFT resources owned by Account1 indicated by a dashed line, such as a resource identification (e.g., tokenId1, etc.) including one or more NFT resources. Corresponding to this embodiment, transaction Tx1 may be an NFT resource transfer transaction, where the from field in transaction Tx1 is Account1, the to field is Account2, and the data field includes, for example, a resource identification (e.g., tokenId) of one or more NFT resources to be transferred for transferring NFT resources from Account1 to Account2. The transaction Tx1 may further include indication information for indicating that the tokenId is a resource identifier of the NFT resource. The transaction Tx1 may be transmitted, for example, by a user device corresponding to Account1 to any node in the blockchain such that the transaction Tx1 is broadcast at the blockchain such that each node in the blockchain may receive the transaction, while the user device also transmits a signature of the transaction Tx1 to any node in the blockchain, which may be generated by signing the transaction body of the transaction Tx1 using the private key of Account1.

In another embodiment, the NFT resource information is, for example, an Account address of an NFT Account corresponding to the Account1, for example, nft_address1. Meanwhile, state data corresponding to the address nft_address1 is stored in the state database, wherein the state data corresponding to the address nft_address1 includes table information corresponding to NFT resource information indicated by a dotted line in fig. 3, for example. Similarly, the Account information of the Account Account2 may include an Account address nfft_address2 of the NFT Account corresponding to the Account Account2.

Corresponding to this embodiment, the from field in transaction Tx1 is Account Account1, the to field is Account Account2, and the data field includes, for example, a resource identification (e.g., a tokenId) of the NFT resource for transferring the NFT resource from the NFT Account of Account Account1 to the NFT Account of Account Account2. In one embodiment, the transaction Tx1 may further include an Account address nft_address1 of the NFT Account of Account1 and an Account address nft_address2 of the NFT Account of Account2 to indicate that the NFT resource is transferred from the NFT Account nft_address1 of Account1 to the NFT Account nft_address2 of Account2.

In one embodiment, as shown in fig. 3, the Account information of the Account1 may further include a state root hash value corresponding to the current state information of the Account1, so as to be used for verifying the Account information corresponding to the Account1, where the Account information corresponding to the Account1 includes table contents corresponding to the NFT resource information.

In step S203, the block link point deletes the resource identifier of the NFT resource from the Account information corresponding to the Account1 according to the transaction Tx1, and adds the resource identifier of the NFT resource to the Account information corresponding to the Account2.

Each node in the blockchain, upon receipt of transaction Tx1, may verify the signature of transaction Tx1 using the public key of Account Account1, and after verification passes, may make a consensus of transaction Tx 1. Each node in the blockchain executes the transaction Tx1 after the consensus for the transaction Tx1 passes, resulting in the execution of the transaction Tx 1. The execution result of the transaction Tx1 is used to instruct deleting the resource identifier of the NFT resource in the Account information corresponding to the Account1, and adding the resource identifier of the NFT resource in the Account information corresponding to the Account2. Then, the blockchain node may update the status database according to the execution result of the transaction Tx1, that is, delete the resource identifier of the NFT resource in the Account information corresponding to the Account1, and add the resource identifier of the NFT resource in the Account information corresponding to the Account2.

Specifically, in the case that the Account information of the Account Account1 includes an NFT resource identifier list, assuming that a resource identifier of an NFT resource to be transferred is tonkeID1, the blockchain node may delete the resource identifier tokenID1 in the NFT resource identifier list of the Account Account1 directly, and add the resource identifier tokenID1 in the NFT resource identifier list of the Account Account2, so as to transfer the NFT resource corresponding to the tonkeID1 from the Account Account1 to the Account Account2.

In the case that Account information of the Account Account1 includes an Account address nft_address1 of the associated NFT Account and Account information of the Account Account2 includes an Account address nft_address2 of the associated NFT Account, the blockchain node may read an NFT resource identification list corresponding to the address through the address nft_address1, delete an NFT resource identification token ID1 in the NFT resource identification list, read an NFT resource identification list corresponding to the address through the address nft_address2, and add the NFT resource identification token ID1 in the NFT resource identification list to realize transferring an NFT resource corresponding to the tonk D1 from the Account Account1 to the Account Account2.

In the embodiment of the specification, a new account mode is provided, and the external account contains the NFT resource information, so that the transfer of the NFT resource can be directly carried out between the external accounts, the interaction between contracts is effectively reduced, and the transaction cost is also reduced.

Fig. 4 is a flowchart of a method for querying NFT resources corresponding to an account in an embodiment of the present disclosure. The method is performed by any node in the blockchain.

As shown in fig. 4, first, in step S401, the block link point receives a transaction Tx2, where the transaction Tx2 is used to query the NFT resource owned by Account1.

Assuming Account Account1 is the Account of user A and Account Account2 is the Account of user B, user B may first query whether user B owns the NFT resource before purchasing the NFT resource owned by user A. User B may send transaction Tx2 to any node in the blockchain (e.g., node 1), where the sending Account of transaction Tx2 is Account2 and the receiving Account may be the Account corresponding to node 1.

In one embodiment, transaction Tx2 may include Account Account1 and indication information indicating that all NFT resources owned by Account Account1 are queried.

In another embodiment, transaction Tx2 may include Account Account1, a resource identification (e.g., tokeniD 1) of the NFT resource to be queried, for querying whether Account Account1 owns the particular NFT resource (tokeniD 1).

In step S405, the block link point obtains the identifier of the NFT resource owned by the Account1 from the Account information corresponding to the Account1 according to the transaction Tx2, and returns the query result according to the identifier of the NFT resource owned by the Account1.

After receiving transaction Tx2, node 1 may directly obtain the query result back to user B's device after determining that transaction Tx2 is the query transaction, without broadcasting transaction Tx2 into the blockchain. Specifically, the node 1 may query the state database for Account information corresponding to the Account1, where the Account information includes, for example, a resource list of NFT resources owned by the Account1 as shown in fig. 3. In the case where transaction Tx2 is used to query all NFT resources owned by Account1, node 1 may return the resource list of NFT resources owned by Account1 to user B's device. Under the condition that the transaction Tx2 is used for inquiring whether the NFT resource corresponding to the token id1 owned by the Account1 is owned by the Account1, the node 1 can determine whether the tokenID1 is included in the resource list according to the resource list of the NFT resource owned by the Account1, if so, the NFT resource corresponding to the token id1 owned by the Account1 is returned to the device of the user B, otherwise, the NFT resource corresponding to the token id1 not owned by the Account1 is returned to the device of the user B.

In the embodiment of the specification, when other accounts wish to query the information of the NFT resource owned by the specific account, the account information corresponding to the specific account can be obtained directly based on the address of the specific account, and the information of the NFT resource owned by the specific account can be obtained from the account information, so that the home account of the NFT resource is not required to be queried by calling the NFT contract, and the query efficiency of the NFT resource is improved.

FIG. 5 is an architecture diagram of a blockchain node for performing the method of FIG. 2 or FIG. 4 in an embodiment of the present disclosure, the blockchain node comprising:

a receiving unit 51, configured to receive a first transaction, where the first transaction is used to transfer an NFT resource of a first account to a second account, and account information corresponding to the first account stored in the blockchain includes a resource identifier of the NFT resource;

and a transferring unit 52, configured to delete, according to the first transaction, the resource identifier of the NFT resource in account information corresponding to the first account, and add, in account information corresponding to the second account stored in the blockchain, the resource identifier of the NFT resource.

In one embodiment, the account information corresponding to the first account includes an account address of a first NFT account associated with the first account, and the transferring unit 52 is specifically configured to: and deleting the resource identifier of the NFT resource in the account information of the first NFT account according to the account address of the first NFT account.

In one embodiment, the receiving unit 51 is further configured to: a signature of the first transaction generated based on a private key of the first account is received, the signature being verified based on a public key of the first account.

In one embodiment, the blockchain node further includes: the acquiring unit is configured to acquire a state root hash value of a state tree corresponding to the block to which the first transaction belongs, and update the state root hash value of the state tree in account information corresponding to the first account and account information corresponding to the second account respectively.

In one embodiment, the receiving unit 51 is further configured to: receiving a second transaction, the second transaction sent by the first account for casting the NFT resource;

the blockchain node further includes: a generating unit, configured to generate, according to the second transaction, a resource identifier of the NFT resource, and add the resource identifier of the NFT resource to account information corresponding to the first account.

In one embodiment, the receiving unit is further configured to receive a third transaction, where the third transaction is used to query NFT resources owned by the first account;

the obtaining unit is further configured to obtain, according to the third transaction, a resource identifier of the NFT resource owned by the first account from account information corresponding to the first account, and return a query result according to the resource identifier of the NFT resource owned by the first account.

The present description also provides a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method as shown in fig. 2 and 4.

Embodiments of the present disclosure also provide a blockchain node including a memory having executable code stored therein and a processor that when executing the executable code implements the methods shown in fig. 2 and 4.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, 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., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of 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, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, 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 in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation device is a server system. Of course, the present application does not exclude that as future computer technology evolves, the computer implementing the functions of the above-described embodiments may be, for example, a personal computer, a laptop computer, a car-mounted human-computer 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 of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by 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, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. For example, if first, second, etc. words are used to indicate a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present invention is 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 flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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 one typical configuration, a computing device includes one or more processors, input/output interfaces, network interfaces, and memory. The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage, graphene storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize 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. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification 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 description may 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.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," 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 present specification. In this specification, schematic representations of the above terms are not necessarily directed 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, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. An NFT resource transfer method performed by a block link point, comprising:

2. The method of claim 1, the account information corresponding to the first account comprising an account address of a first NFT account associated with the first account, the deleting the resource identification of the NFT resource in the account information corresponding to the first account comprising: and deleting the resource identifier of the NFT resource in the account information of the first NFT account according to the account address of the first NFT account.

3. The method of claim 2, wherein the account information corresponding to the second account includes an account address of a second NFT account associated with the second account, and the first transaction includes the account address of the first NFT account and the account address of the second NFT account.

4. The method of claim 1 or 2, further comprising: and acquiring a state root hash value of a state tree corresponding to the block to which the first transaction belongs, and respectively updating the state root hash value of the state tree in the account information corresponding to the first account and the account information corresponding to the second account.

5. The method of claim 1 or 2, further comprising:

6. The method of claim 1 or 2, further comprising:

7. A blockchain node comprising:

8. The blockchain node of claim 7, the account information corresponding to the first account comprising an account address of a first NFT account associated with the first account, the transfer unit being specifically configured to: and deleting the resource identifier of the NFT resource in the account information of the first NFT account according to the account address of the first NFT account.

9. A computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of any of claims 1-6.

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