A method of NFT resource transfer and a blockchain node

Abstract

An NFT resource transfer method and a blockchain node, the method comprising: receiving a first transaction, the first transaction being used to transfer an NFT resource of a first account to a second account, the first account corresponding account information stored in a blockchain comprising a resource identifier of the NFT resource; according to the first transaction, deleting the resource identifier of the NFT resource in the first account corresponding account information, and adding the resource identifier of the NFT resource in the second account corresponding account information stored in the blockchain.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to an NFT resource transfer method and a blockchain node. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application.

[0003] In blockchain, digital resources can be generated based on non-fungible tokens (NFTs). These digital resources typically possess characteristics such as non-fungibility, limited quantity, and indivisibility. Different blockchains can use different NFT protocol standards to generate digital resources. Currently, mainstream protocol standards include ERC721, ERC1155, and ERC998. 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 interchangeable. In the above protocol standards, the ownership account of the NFT resource is usually recorded in the contract state. Summary of the Invention

[0004] The purpose of this invention is to provide a solution for transferring NFT resources, thereby improving the efficiency of NFT resource transfer.

[0005] The first aspect of this specification provides an NFT resource transfer method executed by a blockchain node, including:

[0006] The first transaction is received, which is used to transfer NFT resources of the first account to the second account. The account information corresponding to the first account stored in the blockchain includes the resource identifier of the NFT resources.

[0007] Based on the first transaction, the resource identifier of the NFT resource is deleted from the account information corresponding to the first account, and the resource identifier of the NFT resource is added to the account information corresponding to the second account stored in the blockchain.

[0008] In one implementation, the account information corresponding to the first account includes the account address of the 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: 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.

[0009] In one embodiment, the account information corresponding to the second account includes the account address of the 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.

[0010] In one embodiment, the method further includes: receiving a signature of the first transaction generated based on the private key of the first account, and verifying the signature based on the public key of the first account.

[0011] In one embodiment, the method further includes: obtaining the state root hash value of the state tree corresponding to the block to which the first transaction belongs, and 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, respectively.

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

[0013] Receive a second transaction, which is sent by the first account, for minting the NFT resource;

[0014] Based on the second transaction, a resource identifier for the NFT resource is generated, and the resource identifier for the NFT resource is added to the account information corresponding to the first account.

[0015] In one embodiment, the method further includes:

[0016] Receive a third transaction, which is used to query the NFT resources owned by the first account;

[0017] Based on the third transaction, the resource identifier of the NFT resources owned by the first account is obtained from the account information corresponding to the first account, and the query result is returned based on the resource identifier of the NFT resources owned by the first account.

[0018] The second aspect of this specification provides a blockchain node, including:

[0019] A receiving unit is used to receive a first transaction, which is used to transfer NFT resources of a first account to a second account. The account information corresponding to the first account stored in the blockchain includes the resource identifier of the NFT resources.

[0020] The transfer unit is configured to, based on the first transaction, delete the resource identifier of the NFT resource in the account information corresponding to the first account, and add the resource identifier of the NFT resource in the account information corresponding to the second account stored in the blockchain.

[0021] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0022] A fourth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0023] In the embodiments of this specification, a new account model is proposed, in which the external account contains NFT resource information, thereby enabling the direct transfer of NFT resources between external accounts. This effectively reduces the interaction between contracts, lowers transaction costs, and improves the efficiency of querying NFT resources. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A blockchain architecture diagram in one embodiment is shown;

[0026] Figure 2 This is a flowchart of the NFT resource transfer method in the embodiments of this specification;

[0027] Figure 3 This is a schematic diagram of account information for the accounts used in the embodiments of this specification;

[0028] Figure 4 This is a flowchart of the method for querying NFT resources corresponding to an account in the embodiments of this specification;

[0029] Figure 5 This is an architecture diagram of a blockchain node in one of the embodiments of this specification. Detailed Implementation

[0030] 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. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0031] Figure 1 A blockchain architecture diagram from one embodiment is shown. Figure 1 The blockchain architecture diagram shown depicts, for example, six nodes: nodes 1 through 6. The lines connecting the nodes schematically represent P2P (Peer-to-Peer) connections. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain can produce the same state by executing the same transaction, and each node can store the same state database. This can be understood as... Figure 1 Although the example shows a blockchain with 6 nodes, this specification's embodiments are not limited to this and may include other numbers of nodes. Specifically, the nodes in the blockchain can satisfy the Byzantine Fault Tolerance (BFT) requirement. The Byzantine Fault Tolerance requirement can be understood as the existence of Byzantine nodes within the blockchain, while the blockchain does not exhibit Byzantine behavior externally. Generally, some Byzantine Fault Tolerance algorithms require a number of nodes greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm.

[0032] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract on the blockchain, the From field represents the account address initiating the transaction, the To field represents the account address of the contract called by the transaction, and the Data field includes the function name in the called contract and the parameters passed to that function, which is used to retrieve and execute the function's code from the blockchain during transaction execution.

[0033] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner. It should be noted that besides users creating smart contracts, the system can also set smart contracts in the genesis block. These contracts are generally called genesis contracts. Typically, genesis contracts can set some blockchain data structures, parameters, attributes, and methods. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts). These system contracts can be used to add data structures for different business operations to the blockchain.

[0034] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to a server such as... Figure 1 In the blockchain shown, the `data` field of the transaction includes the code (such as bytecode or machine code) of the contract to be created, and the `to` field of the transaction is empty, indicating that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93…" is determined. Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates state storage corresponding to the contract account, and saves the contract code in the contract's state storage, thus the contract is successfully created.

[0035] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field "0x6f8ae93…" represents the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract.

[0036] Smart contracts deployed in a blockchain can include NFT smart contracts, which are essentially code on the blockchain that implements NFT functionality. For example, NFT functionality can include minting, transfer, and querying capabilities. Here, minting can be used to create NFT resources on the blockchain; specifically, the resource identifier and attributes of the NFT resource are recorded in the contract state of the NFT smart contract on the blockchain. Transfer functionality can be used to transfer NFT resources from their current owner to another user. Querying functionality can be used to query the attribute information of NFT resources.

[0037] In related technologies, NFT resources are processed based on the ERC1155 protocol. The ERC1155 protocol supports multiple types of tokens, and NFT contracts based on the ERC1155 protocol can transfer multiple resources in a single call. In this related technology, the ownership account of the NFT resources is stored in the contract state of the NFT contract. When other accounts want to query whether a specific account owns the NFT resources, they need to call the NFT contract to query whether the ownership account of the NFT resources belongs to that specific account. When the ownership account wants to transfer the NFT resources to other accounts, it needs to call the NFT contract to transfer the NFT resources. This query or transfer method is inefficient and reduces the transaction execution efficiency of the blockchain system.

[0038] This specification provides an NFT resource transfer scheme. By including information about the NFT resources owned by the external account in the account information corresponding to the external account, it is possible to determine whether the external account owns NFT resources by querying the information corresponding to the external account, and NFT resources can be transferred directly between external accounts, effectively improving the processing efficiency of NFT resources.

[0039] Figure 2 This is a flowchart of an NFT resource transfer method in an embodiment of this specification. The method can be executed by any node in the blockchain and includes the following steps S201 and S203.

[0040] First, in step S201, the blockchain node receives transaction Tx1, which is used to transfer the NFT resources of account Account1 to account Account2.

[0041] Assuming Account1 is user A's account, user A can mint NFT resources by sending a transaction to the blockchain that invokes a smart contract. The sending account for this transaction is Account1. After receiving the transaction, the nodes in the blockchain execute the transaction, generating a resource identifier (e.g., tokenID1) for the newly minted NFT resource. Based on the account model in the embodiments of this specification, the resource identifier of the newly minted NFT resource is added to the account information corresponding to account1 to indicate that account1 owns the NFT resource.

[0042] Figure 3 This is a schematic diagram illustrating account information for an account (e.g., Account1) in an embodiment of this specification. Figure 3 The account information shown is stored in a state database within each node of the blockchain. This state database includes the account states of each account in the blockchain (including external accounts and contract accounts), and these account states are stored in the form of a state tree. For example... Figure 3 As shown, Account1 is an external account, i.e., the user's account. The status information of Account1 includes NFT resource information.

[0043] In one implementation, Figure 3 The NFT resource information shown includes information related to the NFT resources owned by account Account1, indicated by the dotted line. This includes resource identifiers (e.g., tokenId1) for one or more NFT resources. Corresponding to this implementation, transaction Tx1 can be an NFT resource transfer transaction, where the `from` field of transaction Tx1 is account Account1, the `to` field is account Account2, and the `data` field includes, for example, resource identifiers (e.g., tokenId) for one or more NFT resources to be transferred, used to transfer NFT resources from account Account1 to account Account2. Transaction Tx1 may also include indication information indicating that tokenId is a resource identifier of an NFT resource. Transaction Tx1 can be sent by the user device corresponding to account Account1 to any node in the blockchain, broadcasting the transaction so that all nodes in the blockchain can receive it. The user device will also send a signature of transaction Tx1 to any node in the blockchain, which can be generated by signing the transaction body of transaction Tx1 using the private key of account Account1.

[0044] In another implementation, the NFT resource information is, for example, the account address of the NFT account corresponding to account Account1, such as nft_address1. Simultaneously, a state database stores state data corresponding to address nft_address1, wherein the state data corresponding to address nft_address1 includes, for example, Figure 3 The table information corresponding to the NFT resource information is indicated by dashed lines. Similarly, the account information for account Account2 may include the account address nft_address2 of the NFT account corresponding to account Account2.

[0045] Corresponding to this implementation, the `from` field in transaction Tx1 is account Account1, the `to` field is account Account2, and the `data` field includes, for example, the resource identifier of the NFT resource (e.g., tokenId), to transfer the NFT resource from the NFT account of account Account1 to the NFT account of account Account2. In one implementation, transaction Tx1 may also include the account address `nft_address1` of the NFT account of account Account1 and the account address `nft_address2` of the NFT account of account Account2, to indicate the transfer of the NFT resource from the NFT account `nft_address1` of account Account1 to the NFT account `nft_address2` of account Account2.

[0046] In one implementation, such as Figure 3 As shown, the account information of account1 may also include a state root hash value corresponding to the current state information of account1, which is used to verify the account information corresponding to account1. The account information corresponding to account1 includes table content corresponding to NFT resource information.

[0047] In step S203, the blockchain node deletes the resource identifier of the NFT resource in the account information corresponding to account Account1 and adds the resource identifier of the NFT resource in the account information corresponding to account Account2, based on transaction Tx1.

[0048] After receiving transaction Tx1, each node in the blockchain can verify the signature of transaction Tx1 using the public key of account Account1. Upon successful verification, consensus on transaction Tx1 can be reached. After consensus on transaction Tx1 is reached, the nodes execute transaction Tx1, obtaining the execution result. This execution result instructs the deletion of the NFT resource's resource identifier in the account information corresponding to account Account1, and the addition of the NFT resource's resource identifier in the account information corresponding to account Account2. Subsequently, the blockchain nodes can update the state database based on the execution result of transaction Tx1, i.e., deleting the NFT resource's resource identifier in the account information corresponding to account Account1 and adding the NFT resource's resource identifier in the account information corresponding to account Account2.

[0049] Specifically, if the account information of Account1 includes a list of NFT resource identifiers, assuming the resource identifier of the NFT resource to be transferred is tonkeID1, the blockchain node can directly delete the resource identifier tokenID1 from the NFT resource identifier list of Account1 and add the resource identifier tokenID1 to the NFT resource identifier list of Account2, so as to transfer the NFT resource corresponding to tonkeID1 from Account1 to Account2.

[0050] In cases where account information for account1 includes the account address nft_address1 of its associated NFT account, and account information for account2 includes the account address nft_address2 of its associated NFT account, a blockchain node can read the list of NFT resource identifiers corresponding to address nft_address1, delete the NFT resource identifier tokenID1 from the list, and read the list of NFT resource identifiers corresponding to address nft_address2, add the NFT resource identifier tokenID1 to the list, thereby transferring the NFT resource corresponding to tokenID1 from account1 to account2.

[0051] In the embodiments of this specification, a new account model is proposed, in which the external account contains NFT resource information, thereby enabling the direct transfer of NFT resources between external accounts, effectively reducing the interaction between contracts and lowering transaction costs.

[0052] Figure 4 This is a flowchart illustrating the method for querying NFT resources corresponding to an account in the embodiments of this specification. This method is executed by any node in the blockchain.

[0053] like Figure 4 As shown, in step S401, the blockchain node first receives transaction Tx2, which is used to query the NFT resources owned by account Account1.

[0054] Assuming Account1 belongs to user A and Account2 belongs to user B, before purchasing an NFT owned by user A, user B can first check whether user B owns that NFT. User B can send transaction Tx2 to any node in the blockchain (e.g., node 1). The sending account for transaction Tx2 is account2, and the receiving account can be the account corresponding to node 1.

[0055] In one implementation, transaction Tx2 may include account Account1 and instruction information for instructing the query of all NFT resources owned by account Account1.

[0056] In another implementation, transaction Tx2 may include account Account1 and the resource identifier (e.g., tokenID1) of the NFT resource to be queried, for querying whether account Account1 owns a specific NFT resource (tokenID1).

[0057] In step S405, the blockchain node retrieves the identifier of the NFT resources owned by account Account1 from the account information corresponding to account Account1 based on transaction Tx2, and returns the query result based on the identifier of the NFT resources owned by account Account1.

[0058] After receiving transaction Tx2, Node 1, upon determining that Tx2 is a query transaction, can directly retrieve the query result and return it to user B's device without broadcasting Tx2 to the blockchain. Specifically, Node 1 can query the account information corresponding to account Account1 from the state database. This account information is, for example, as follows: Figure 3 The diagram shows a resource list including NFT resources owned by Account1. In the case of transaction Tx2 querying all NFT resources owned by Account1, node 1 can return the resource list of NFT resources owned by Account1 to user B's device. In the case of transaction Tx2 querying whether Account1 owns NFT resources corresponding to tokenID1, node 1 can determine whether the resource list of NFT resources owned by Account1 includes tokenID1. If it does, node 1 returns the NFT resources corresponding to tokenID1 owned by Account1 to user B's device; otherwise, it returns the NFT resources corresponding to tokenID1 that Account1 does not own to user B's device.

[0059] In this embodiment of the specification, when other accounts wish to query information about NFT resources owned by a specific account, they can directly obtain the account information corresponding to that specific account based on the specific account's address, and then obtain the information about the NFT resources owned by that specific account from that account information, without needing to call the NFT contract to query the account to which the NFT resources belong, thus improving the query efficiency of NFT resources.

[0060] Figure 5 This is an architecture diagram of a blockchain node according to an embodiment of this specification. The blockchain node is used to perform actions such as... Figure 2 or Figure 4 The method shown, wherein the blockchain node includes:

[0061] The receiving unit 51 is used to receive a first transaction, which is used to transfer NFT resources of a first account to a second account. The account information corresponding to the first account stored in the blockchain includes the resource identifier of the NFT resources.

[0062] The transfer unit 52 is used to delete the resource identifier of the NFT resource in the account information corresponding to the first account according to the first transaction, and add the resource identifier of the NFT resource in the account information corresponding to the second account stored in the blockchain.

[0063] In one embodiment, the account information corresponding to the first account includes the account address of the first NFT account associated with the first account, and the transfer unit 52 is specifically used to: delete 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.

[0064] In one embodiment, the account information corresponding to the second account includes the account address of the 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.

[0065] In one embodiment, the receiving unit 51 is further configured to: receive a signature of the first transaction generated based on the private key of the first account, and verify the signature based on the public key of the first account.

[0066] In one embodiment, the blockchain node further includes: an acquisition unit, configured to acquire the state root hash value of the state tree corresponding to the block to which the first transaction belongs, and update 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, respectively.

[0067] In one embodiment, the receiving unit 51 is further configured to: receive a second transaction, the second transaction being sent by the first account, for minting the NFT resource;

[0068] The blockchain node further includes a generation unit, configured to generate a resource identifier for the NFT resource based on the second transaction, and add the resource identifier of the NFT resource to the account information corresponding to the first account.

[0069] In one implementation, the receiving unit is further configured to receive a third transaction, the third transaction being used to query the NFT resources owned by the first account;

[0070] The acquisition unit is further configured to, based on the third transaction, obtain the resource identifier of the NFT resources owned by the first account from the account information corresponding to the first account, and return the query result based on the resource identifier of the NFT resources owned by the first account.

[0071] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 2 and Figure 4 The method shown.

[0072] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 2 and Figure 4 The method shown.

[0073] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0074] The controller can be implemented in any suitable manner. For example, it can take the form of 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 (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0075] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0076] While one or more embodiments of this specification provide the operational steps of the methods 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 listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0077] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0078] This 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 block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can 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, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0079] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. 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, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0080] In a typical configuration, a computing device includes one or more processors, input / output interfaces, a network interface, and memory. Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0081] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0082] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may 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.) containing computer-usable program code.

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

[0084] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0085] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. An NFT resource transfer method, executed by a blockchain node, comprising: The first transaction is received, which is used to transfer NFT resources of the first account to the second account. The account information corresponding to the first account stored in the blockchain includes the resource identifier of the NFT resources. According to the first transaction, the resource identifier of the NFT resource is deleted from the account information corresponding to the first account, and the resource identifier of the NFT resource is added to the account information corresponding to the second account stored in the blockchain. The first account and the second account are external accounts, and the account information corresponding to the external accounts is stored in the state database of each node in the blockchain.

2. The method according to claim 1, wherein the account information corresponding to the first account includes the account address of the 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: Based on the account address of the first NFT account, delete the resource identifier of the NFT resource from the account information of the first NFT account.

3. The method according to claim 2, wherein, The account information corresponding to the second account includes the account address of the 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 according to claim 1 or 2, further comprising: Obtain the state root hash value of the state tree corresponding to the block to which the first transaction belongs, and update 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, respectively.

5. The method according to claim 1 or 2, further comprising: Receive a second transaction, which is sent by the first account, for minting the NFT resource; Based on the second transaction, a resource identifier for the NFT resource is generated, and the resource identifier for the NFT resource is added to the account information corresponding to the first account.

6. The method according to claim 1 or 2, further comprising: Receive a third transaction, which is used to query the NFT resources owned by the first account; Based on the third transaction, the resource identifier of the NFT resources owned by the first account is obtained from the account information corresponding to the first account, and the query result is returned based on the resource identifier of the NFT resources owned by the first account.

7. A blockchain node, comprising: A receiving unit is used to receive a first transaction, which is used to transfer NFT resources of a first account to a second account. The account information corresponding to the first account stored in the blockchain includes the resource identifier of the NFT resources. A transfer unit is configured to, based on the first transaction, delete the resource identifier of the NFT resource in the account information corresponding to the first account, and add the resource identifier of the NFT resource in the account information corresponding to the second account stored in the blockchain; The first account and the second account are external accounts, and the account information corresponding to the external accounts is stored in the state database of each node in the blockchain.

8. The blockchain node according to claim 7, wherein the account information corresponding to the first account includes the account address of the first NFT account associated with the first account, and the transfer unit is specifically used to: delete 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 a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-6.

10. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-6.

Images