Method and apparatus for minting non-fungible token onto block chain

Abstract

To provide a technology that can mint a non-fungible token for a product.SOLUTION: A method includes a step of a processor connected to a computer network including a block chain network receiving a transaction requesting minting of a non-fungible token corresponding to a product from a first terminal that has received a unique number for the product, and a step of the processor executing a smart contract in response to the reception of the transaction.SELECTED DRAWING: Figure 4A

Description

[Technical field]

[0001] The subject matter disclosed herein relates to techniques for uploading non-fungible tokens to a blockchain. [Background technology]

[0002] The emergence of blockchain technology, particularly the Ethereum blockchain, has given rise to the concept of digital ownership based on non-fungible tokens, which have gained popularity in the digital marketplace as they represent verifiable ownership of specific items.

[0003] Various platforms and systems have been developed to facilitate the creation and sale of non-fungible tokens. Such platforms generally use smart contracts, which are agreements that can be executed with terms written hard into the code.

[0004] The process of issuing non-fungible tokens involves generating unique tokens on the blockchain and recording ownership information. As ownership information is recorded while issuing non-fungible tokens, there may be an increased demand for verifiable ownership by receiving non-fungible tokens for real goods. Summary of the Invention [Problem to be solved by the invention]

[0005] At least some of the subject matter disclosed herein provides technology that allows for minting of non-fungible tokens for goods.

[0006] At least a portion of the disclosure herein provides a minting technique that does not expose the unique number of an item on the blockchain network.

[0007] At least some of the subject matter disclosed herein provides minting techniques that provide enhanced security in the absence of an intermediary to transmit transactions.

[0008] At least some of the subject matter disclosed herein provides techniques that may align ownership of a commodity with ownership of a non-fungible token for the commodity.

[0009] At least a portion of the disclosure herein provides technology that allows for the recovery of ownership of non-fungible tokens even if the digital asset wallet that holds the non-fungible tokens is lost.

[0010] The technical problems of the contents disclosed in this specification are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by a person of ordinary skill in the art of the contents disclosed in this specification from the following description. [Means for solving the problem]

[0011] A method according to one embodiment of the contents disclosed in this document includes a step of a processor connected to a computer network including a blockchain network receiving a transaction requesting minting of a non-fungible token corresponding to the product from a first terminal that has received a unique number for the product, and a step of the processor executing a smart contract in response to the receipt of the transaction, wherein the step of executing the smart contract may include a step of verifying a transaction including a zero-knowledge proof value of the unique number corresponding to the unique number for the product, a step of verifying the zero-knowledge proof value of the unique number, and a step of distributing the non-fungible token to the blockchain network based on a verification result of the zero-knowledge proof value of the unique number.

[0012] In one embodiment, the unique number for the item may be received by at least one of a message, a Near Field Communication (NFC), or a Quick Response (QR) code.

[0013] In one embodiment, the zero-knowledge proof value of the unique number is generated based on at least one of the unique number, a hash value of the unique number, or a proving key, and the proving key may be generated in a pair with a verifying key based on the hash value of the unique number.

[0014] In one embodiment, the transaction further includes a hash value of the unique number, and the step of verifying the zero-knowledge proof value of the unique number may include, if the transaction is successfully verified, performing a verification algorithm based on at least one of the zero-knowledge proof value of the unique number, the hash value of the unique number, or a verification key.

[0015] In one embodiment, the transaction may further include a hash value of the unique number, and may further include invalidating the hash value of the unique number prior to distributing the non-fungible token to the blockchain network to prevent duplicate issuance of the non-fungible token for the unique number.

[0016] In one embodiment, the transaction further includes a recipient address, and distributing the non-fungible token onto the blockchain network may include minting the non-fungible token to the recipient address upon successful verification of the zero-knowledge proof value of the unique number.

[0017] In one embodiment, the smart contract may include a first Merkle root of a first Merkle tree obtained by hashing a number of unique numbers generated by a second terminal of a company selling a product.

[0018] In one embodiment, the transaction may further include a hash value of the unique number, and verifying the transaction may include verifying the hash value of the unique number based on the first Merkle proof value included in the smart contract.

[0019] In one embodiment, the smart contract may include a public key that is symmetrical to a private key stored in a third terminal that transmits a unique number for the item to the first terminal via at least one of NFC or a QR code.

[0020] In one embodiment, the unique number is a random value generated by the third terminal, and the transaction may further include a hash value of the unique number and signature data in which the hash value of the unique number is signed with a private key.

[0021] In one embodiment, validating the transaction may include verifying the signature data with a public key stored in the transaction.

[0022] In one embodiment, the smart contract may further include a second Merkle root of a second Merkle tree obtained by hashing the user identity information of the first terminal, and the transaction may further include a hash value of the unique number, signature data obtained by signing the hash value of the unique number with a private key, and a second Merkle proof value based on the second Merkle tree.

[0023] In one embodiment, verifying the transaction may include verifying the signature data with a public key stored in the transaction, and verifying the user identity based on the second Merkle root and a proof for the user identity of the first terminal.

[0024] In one embodiment, when the smart contract includes a first smart contract that receives a transaction and a second smart contract that verifies the transaction and verifies the zero-knowledge proof value of the unique number, the step of executing the smart contract may include a step of a processor requesting the second smart contract to verify the transaction by executing the first smart contract, and a step of the processor executing the second smart contract in response to the request to verify the transaction, and the step of executing the second smart contract may include a step of verifying the transaction, and a step of verifying the zero-knowledge proof value of the unique number based on a result of the transaction verification.

[0025] In one embodiment, distributing the non-fungible token to the blockchain network may include distributing the non-fungible token to the blockchain network based on a verification result of the zero-knowledge proof value of the unique number by executing a first smart contract by a processor.

[0026] In one embodiment, when the smart contract includes a first smart contract for receiving a transaction, a second smart contract for verifying the transaction, and a third smart contract for verifying the zero-knowledge proof value of the unique number, the step of executing the smart contract may include the steps of: a processor executing the first smart contract to request the second smart contract to verify the transaction; a processor executing the second smart contract to verify the transaction and, based on a result of the transaction verification, requesting the third smart contract to verify the zero-knowledge proof value of the unique number; and a processor executing the third smart contract to verify the zero-knowledge proof value of the unique number and sending the verification result to the second smart contract.

[0027] In one embodiment, distributing the non-fungible token to the blockchain network may include distributing the non-fungible token to the blockchain network based on a verification result of the zero-knowledge proof value of the unique number by executing a first smart contract by a processor.

[0028] In one embodiment, when the smart contract includes a first smart contract for receiving a transaction, a second smart contract for verifying the transaction, a third smart contract for verifying the zero-knowledge proof value of the unique number, and a fourth smart contract for verifying the user identity of the first terminal, the step of executing the smart contract may include the steps of: a processor executing the first smart contract to request the second smart contract to verify the transaction; a processor executing the second smart contract to verify the transaction, and based on a transaction verification result, requesting the third smart contract to verify the zero-knowledge proof value of the unique number, and requesting the fourth smart contract to verify the user identity; a processor executing the third smart contract to verify a hash value of the unique number and sending the verification result to the second smart contract; and a processor executing the fourth smart contract to verify the user identity based on the second Merkle root included in the fourth smart contract and evidence for the user identity of the first terminal.

[0029] In one embodiment, the step of distributing the non-fungible token to the blockchain network may include a step of distributing the non-fungible token to the blockchain network based on a verification result of the zero-knowledge proof value of the unique number and a verification result of the user identification information by executing a first smart contract by a processor.

[0030] A method according to another embodiment of the contents disclosed in this document may include a step in which a processor included in a user terminal connected to a computer network including a blockchain network generates a zero-knowledge proof value of a unique number corresponding to the unique number for the product in response to receiving a unique number for the product; a step in which a transaction including at least one of a hash value of the unique number, a recipient address, or the zero-knowledge proof value of the unique number is sent to a smart contract; and a step in which the processor receives a minting result of the non-fungible token based on a verification result of the zero-knowledge proof value of the unique number obtained by executing the smart contract that received the transaction.

[0031] In one embodiment, the smart contract may return the minting result of the non-fungible token by verifying the zero-knowledge proof value of the unique number based on at least one of the zero-knowledge proof value of the unique number, a hash value of the unique number, or a proof key stored in the smart contract.

[0032] A method according to another embodiment of the contents disclosed in this document includes a step of a processor connected to a computer network including a blockchain network receiving a transaction requesting minting of a non-fungible token for the product from a first terminal that has received signature data for the product through a device attached to the product, and a step of the processor executing a smart contract corresponding to the received transaction, wherein the step of executing the smart contract may include a step of verifying a transaction including at least one of the signature data, a first hash value obtained by hashing a value including a block hash value corresponding to the first block number and a unique number, a hash value of the unique number, the first block number, a recipient address, or a zero-knowledge proof value of the unique number, and a step of verifying the zero-knowledge proof value of the unique number based on a result of verifying the signature data and a result of comparing the first block number with the second block number.

[0033] In one embodiment, the signature data is data obtained by signing the first hash value and the unique number with a private key, and the step of verifying the transaction may include a step of verifying the signature data based on a public key corresponding to the private key, and a step of determining whether a difference between the second block number and the first block number is less than or equal to a reference value.

[0034] In one embodiment, the step of verifying the zero-knowledge proof value of the unique number may include a step of receiving a block hash value corresponding to the block number from a computer network including a blockchain network, and a step of verifying the zero-knowledge proof value of the unique number based on the block hash value, the recipient address, the hash value of the unique number, and the zero-knowledge proof value of the unique number.

[0035] In one embodiment, the method may further include invalidating the second hash value to prevent duplicate issuance of the non-fungible token for the product, and distributing the non-fungible token on a blockchain network.

[0036] In one embodiment, the smart contract may include a private key and a corresponding public key that are stored on a device attached to the product.

[0037] A method according to another embodiment of the contents disclosed in this document may include a step in which a processor included in a first terminal requests a block number and a block hash value from a computer network including a blockchain network and receives a first block number and a block hash value corresponding to the first block number, a step in which a unique number that is an arbitrary value is generated, a step in which the processor transmits the block hash value and the unique number to a device attached to the product, a step in which the processor receives signature data in which a first hash value obtained by hashing a value including the block hash value and the unique number is signed with a private key, a step in which the processor generates a zero-knowledge proof value of the unique number based on the first hash value, and a step in which the processor transmits a transaction requesting uploading of a non-fungible token for the product to the computer network including the blockchain network. Effect of the Invention

[0038] In accordance with at least one embodiment disclosed herein, an owner of a commodity can prove ownership of a non-fungible token for the commodity.

[0039] According to at least one embodiment disclosed in this specification, a zero-knowledge proof value of the product's unique number is used, eliminating the need to disclose the product's unique number to the blockchain network.

[0040] According to at least one embodiment disclosed in this specification, the duplicate issuance of non-fungible tokens for one unique number can be prevented by invalidating the hash value of the unique number.

[0041] According to at least one embodiment disclosed in this specification, the zero-knowledge proof value of the unique number is made dependent on the recipient address, thereby preventing a third party from performing a front-running attack by changing the recipient address.

[0042] According to at least one embodiment disclosed in the present specification, by creating multiple smart contracts and dividing up a series of operations related to minting, smart contracts can be used flexibly according to changes in minting allowable conditions.

[0043] According to at least one embodiment disclosed herein, user identification information may be further used to determine whether minting is permitted, thereby preventing a single user from owning multiple non-fungible tokens using multiple digital asset wallets.

[0044] The effects of the technical ideas disclosed in this specification are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those of ordinary skill in the art from the description of the specification. [Brief description of the drawings]

[0045] [Figure 1] 1 illustrates an environment in which an apparatus according to one embodiment of the subject matter disclosed herein may be applied. [Diagram 2] 1 illustrates a computing device capable of implementing any one of the devices according to an embodiment of the subject matter disclosed herein. [Diagram 3] FIG. 1 illustrates a method for minting non-fungible tokens for physical goods according to one embodiment of the subject matter disclosed herein. [Figure 4A] 1 is a flow chart illustrating a method for minting non-fungible tokens for physical goods according to various embodiments of the subject matter disclosed herein. [Figure 4B] 1 is a flow chart illustrating a method for minting non-fungible tokens for physical goods according to various embodiments of the subject matter disclosed herein. [Figure 4C] 1 is a flow chart illustrating a method for minting non-fungible tokens for physical goods according to various embodiments of the subject matter disclosed herein. [Figure 4D] 1 is a flow chart illustrating a method for minting non-fungible tokens for physical goods according to various embodiments of the subject matter disclosed herein. [Figure 4E] 1 is a flow chart illustrating a method for minting non-fungible tokens for physical goods according to various embodiments of the subject matter disclosed herein. [Figure 4F] 1 is a flow chart illustrating a method for minting non-fungible tokens for physical goods according to various embodiments of the subject matter disclosed herein. [Diagram 5] FIG. 1 illustrates a method of minting non-fungible tokens via a third terminal according to one embodiment of the subject matter disclosed herein. [Figure 6A] 1 is a flow chart illustrating a method of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein. [Figure 6B] 1 is a flow chart illustrating a method of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein. [Figure 6C]1 is a flow chart illustrating a method of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein. [Figure 6D] 1 is a flow chart illustrating a method of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein. [Figure 6E] 1 is a flow chart illustrating a method of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein. [Figure 6F] 1 is a flow chart illustrating a method of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein. [Figure 6G] 1 is a flow chart illustrating a method of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein. [Figure 6H] 1 is a flow chart illustrating a method of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein. [Figure 7] FIG. 1 illustrates a method of minting non-fungible tokens via a device attached to a product according to one embodiment of the subject matter disclosed herein. [Figure 8A] 1 is a flow chart illustrating a method of minting non-fungible tokens via a device attached to a merchandise according to various embodiments of the subject matter disclosed herein. [Figure 8B] 1 is a flow chart illustrating a method of minting non-fungible tokens via a device attached to a merchandise according to various embodiments of the subject matter disclosed herein. [Figure 9] 1 is a flow chart illustrating a method for minting non-fungible tokens according to one embodiment of the subject matter disclosed herein. [Figure 10] 4 is a flow chart illustrating the operation of a user terminal according to one embodiment of the subject matter disclosed herein. [Figure 11] 11 is a flowchart illustrating the operation of a user terminal according to another embodiment of the subject matter disclosed herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0046] The various embodiments disclosed in this document are exemplified for the purpose of clearly explaining the technical idea of ​​this document, and are not intended to limit the technical idea to a specific embodiment. The technical idea of ​​this document includes various modifications, equivalents, alternatives, and embodiments selectively combined from all or part of each embodiment disclosed in this document. In addition, the scope of the technical idea of ​​this document is not limited to the various embodiments presented below or the specific description thereof.

[0047] Terms used in this document, including technical or scientific terms, may have the meaning commonly understood by one of ordinary skill in the art to which the subject matter disclosed in this document belongs, unless otherwise defined.

[0048] As used in this document, terms such as "including," "may include," "include," "can comprise," "have," "may have," and the like, mean that the feature in question (e.g., a function, operation, or component) may be present, but do not exclude the presence of additional features, i.e., such terms should be understood as open-ended terms that include the possibility of including other embodiments.

[0049] As used in this document, singular terms may also include plural meanings unless the context requires otherwise, and this also applies to singular terms recited in the claims.

[0050] As used in this document, unless otherwise indicated in the context, the terms "first", "second", "first", "second" and the like, when referring to multiple similar objects, are used to distinguish one object from the other and do not limit the order or importance of the objects among themselves.

[0051] As used in this document, phrases such as "A, B and C," "A, B or C," "at least one of A, B and C," or "at least one of A, B, or C" can refer to each listed item or to all possible combinations of the listed items. For example, "at least one of A or B" can refer to (1) at least one A, (2) at least one B, or (3) both at least one A and at least one B.

[0052] As used in this document, the phrase "based on" is used to describe one or more factors that influenced the decision, act of judgment, or behavior described in the phrase or sentence in which it appears, and does not exclude additional factors that influenced that decision, act of judgment, or behavior.

[0053] As used in this document, the expression "coupled" or "connected" to one component (e.g., a first component) to another component (e.g., a second component) can mean that the one component is directly coupled or connected to the other component, or that the one component is further coupled or connected through another component (e.g., a third component).

[0054] As used in this document, the expression "configured to" may have the meanings of "set to," "capable of," "modified to," "made to," "capable of," etc., depending on the context. This expression is not limited to the meaning of "specifically designed in hardware." For example, a processor configured to perform a specific operation can mean a generic purpose processor that can perform the specific operation by executing software, or a special purpose computer that is structured by programming to perform the specific operation.

[0055] The term "Non-Fungible Token (NFT)" as used in this document may refer to a collection of electronic information that gives a unique recognition value to a digital asset based on blockchain technology. Specifically, a non-fungible token may be generated by a smart contract created with reference to certain rules (e.g., ERC-721 or ERC-1155, etc.). The integrity of this non-fungible token may be maintained by being recorded in a blockchain, which is a distributed storage, and the existence of a specific type of data can be guaranteed by generating this non-fungible token to include the specific type of data.

[0056] Specifically, a non-fungible token may be a collection of information including various pieces of information. In one embodiment, a non-fungible token may include at least one of information for accessing a digital asset linked to the token (e.g., a digital asset Uniform Resource Identifier (URI)) or information for accessing metadata of the token (e.g., a metadata URI). In another embodiment, a non-fungible token may further include metadata of the token. The digital asset URI linked to a non-fungible token may be an address of a centralized server or a cloud server on which the digital asset is stored. Alternatively, the digital asset URI may be a hash value (e.g., "ipfs.io / ipfs / 12345678") of a digital asset stored on an InterPlanetary File System (IPFS) that distributes and stores files across multiple devices. The metadata URI of a non-fungible token may be an address of a centralized server or a cloud server on which metadata of the token is stored. Alternatively, it may be a hash value of metadata stored on IPFS.

[0057] In one embodiment, the metadata of a non-fungible token may refer to a collection of information including various information related to the token. The metadata may include, for example, at least one of the contract address of the token, the identification information of the token (hereinafter also referred to as "ID" or "token identifier"), the type of blockchain in which the token is recorded, the time of the token's creation, or the token's ownership change history. Hereinafter, expressions such as "information included in a non-fungible token" in this document may be understood to mean "information included (or recorded) in the metadata of a non-fungible token."

[0058] As used herein, the term "smart contract" may refer to a program or application that runs on a virtual machine executed by one or more nodes included in a blockchain network. A smart contract may be created to comply with a certain rule (or protocol). For example, a smart contract may be created by referring to ERC-20, ERC-721, or ERC-1155, etc., such that one or more functions corresponding to each protocol are included in the smart contract. However, various smart contracts may be created by including other functions not included in the illustrated protocols in the smart contract.

[0059] The term "blockchain network" as used herein may include one or more nodes that manage a blockchain. A block may refer to a specific type of data. A blockchain may also refer to a data structure in which one or more blocks are linked in the form of a chain. One or more blocks included in a blockchain may be stored independently in multiple nodes included in the blockchain network, or may be distributed across multiple nodes. Each of the one or more blocks may include a block hash value, a block header, or a block body. The block hash value is unique information that can identify a block, and may be, for example, a character string represented in 256 bits. The block header may include, for example, at least one of software or protocol version information, a hash value of a previous block according to the order of blocks linked on the blockchain, a merkle root, time information indicating the time when the block was generated, bits indicating the difficulty of calculation, or a nonce, which is a value required in a mining operation to add a new block to the blockchain. The block body may include at least one transaction. A transaction is a collection of data having a specific material structure and may be a unit of information stored in a block body. A transaction may include information regarding the creation or trading of tokens.

[0060] The term "digital asset" as used in this document may refer to any information that is expressed in binary form and can be used as an asset. A digital asset may be, for example, a character, a two-dimensional image, a three-dimensional image, a video, or a polygon graphic. More specifically, a digital asset may be a character, a two-dimensional image, a three-dimensional image, a video, or a polygon graphic for clothing, a bag, an accessory, furniture, a vehicle, a building, real estate, a game item, or a digital card, etc. The authenticity of such a digital asset may be guaranteed by a non-fungible token corresponding to the digital asset.

[0061] The term "unique number" as used in this document may generally refer to a number that corresponds to one entity and is not shared with multiple other entities. A unique number for a product may be a number that corresponds to one product and is distinguishable from other products. For example, the unique number may be a secret code assigned by a product seller to each product. As another example, the unique number may be a random value that is newly generated at the time of a request to generate a random value.

[0062] The term "platform" as used in this document may refer to an environment that is the basis for user use by integrating and managing services for the same or similar purpose. This environment may be provided to a user by software (e.g., a computer program or application) running on hardware (e.g., a server, a client, an input device, an output device, or a network device). Although there may be differences in the detailed meaning, the platform may be used interchangeably with "software," "application," or "solution." In one embodiment, a space platform may be an environment that integrates various services related to space. For example, the space platform may provide a community service, a game service, an electronic commerce service, a video conferencing service, a music listening service, or an advertising service to a user. In another embodiment, a non-fungible token platform may be an environment that integrates various services related to a non-fungible token. For example, the non-fungible token platform may provide a service related to trading of a non-fungible token, or a community service based on a non-fungible token to a user.

[0063] The term "minting" used in this document may refer to the minting of non-fungible tokens. The minting of non-fungible tokens is a process of generating unique digital assets in a blockchain network. In the following, an embodiment of a process of trading a non-fungible token that is issued by a user requesting minting of assets will be described. First, (1) a blockchain platform that supports the minting of non-fungible tokens is required. For example, Ethereum may be a platform that supports the minting of non-fungible tokens. (2) Then, a digital asset wallet compatible with the blockchain platform may be required. The digital asset wallet can be used to store and manage non-fungible tokens. (3) Next, an asset (e.g., a real asset or a digital asset) to be converted into a non-fungible token is required. For example, the asset may be a real product, a work of art, a digital form of music, a video, a collectible, a virtual real estate, etc. (4) The user can select a marketplace (e.g., OpenSea, Rarible, SuperRare) to sell the non-fungible token. (5) When a marketplace is selected, the non-fungible token sold in the corresponding marketplace can be received in the digital asset wallet. In one embodiment, when a user purchases a non-fungible token from a marketplace, the non-fungible token can be received in the user's digital asset wallet. In another embodiment, when a user purchases a non-fungible token from a marketplace, the non-fungible token is sent to a first digital asset wallet generated and managed by the marketplace, and the non-fungible token can be later received from the first digital asset wallet in the user's second digital asset wallet. (6) The process of minting the non-fungible token may need to follow specific guidelines provided by the selected marketplace. For example, the specific guidelines may provide detailed information such as a description, name, image, or metadata of the asset. Thus, the user terminal can request the blockchain network to mint the non-fungible token in compliance with the specific guidelines.(7) A gas fee may be incurred in the process of requesting minting. Computing resources of the blockchain network are used to execute a transaction corresponding to the minting request. Therefore, the user may have to pay a gas fee as a cost for using the computing resources. The gas fee may be determined based on the congestion of the blockchain network and the complexity of the transaction. (8) When the transaction is confirmed on the blockchain network, a non-fungible token corresponding to the asset may be issued. (9) After minting, the user may sell the non-fungible token on the marketplace. The user may set a desired value or select an auction. Potential buyers may bid on the auction of the non-fungible token using cryptocurrency or purchase it. (10) When another user purchases the non-fungible token and the transaction is completed, the ownership of the non-fungible token is transferred to the other user, and the non-fungible token is sent to the digital asset wallet of the other user. The transaction details including the value of the non-fungible token may be permanently stored in the blockchain network. The above process is merely an example, and the present invention is not limited thereto.

[0064] The term "recipient address" used in this document may refer to the digital asset wallet address of a user terminal that has requested minting to a smart contract. Thus, when a user terminal requests minting of a non-fungible token corresponding to a product and the minting is successful, the ownership of the non-fungible token may belong to the recipient address (or digital asset wallet address) of the user terminal. A digital asset wallet may be a tool for safely storing and managing personal digital assets in electronic form. A digital asset wallet may store and manage information related to cryptocurrency and digital assets. Digital asset wallets may be classified into hot wallets and cold wallets. A hot wallet is a wallet connected to the Internet and is a form that allows access to cryptocurrency in an online environment. In general, a hot wallet may be provided as a software wallet or an online service. A hot wallet provides convenient and rapid access to send cryptocurrency and quickly processes transactions. A cold wallet may be a wallet that stores personal keys in an offline environment that is not connected to the Internet. Cold wallets may generally be provided as hardware wallets or paper wallets. Cold wallets provide a high level of security against hacking and malicious software attacks because they securely protect private keys and are stored offline.

[0065] The term "Zero-Knowledge Proof (ZKP)" used in this document refers to a prover proving the fact that he or she knows knowledge without disclosing the knowledge and information that he or she knows. It is a proof procedure that does not reveal anything other than the truth / falsehood of a certain proposition when proving to the other party that the proposition is true. Specifically, a zero-knowledge proof is a protocol in which a prover proves to a verifier that he or she knows secret information (witness) that he or she knows without disclosing the secret information that he or she knows. The prover generates a proof that proves the relationship between the proposition and the secret information by communicating with the verifier based on the proposition to be proven and the secret information (witness) that corresponds to the evidence. The verifier receives the proposition as input at the start of communication, and in the final stage of the protocol, checks whether the relationship between the proposition and the secret information matches from the prover's proof value.

[0066] In this document, “submitting a transaction to the blockchain” may include (1) uploading certain data to the blockchain, (2) modifying or deleting data already uploaded to the blockchain, or (3) executing a smart contract that has been distributed to the blockchain.

[0067] As used in this document, a "transaction" is a logical unit of work performed on a blockchain. As used in this document, a transaction may include transactions recorded on the blockchain and / or transactions not recorded on the blockchain. For example, a transaction on the Ethereum blockchain may include (1) a transaction recorded on the blockchain, including a transaction hash value, and (2) a message (Internal Transaction) generated when executing a transaction on the Ethereum Virtual Machine (EVM).

[0068] The term "merkle proof" used in this document uses a merkle tree. The leaf nodes of a merkle tree are composed of the hash value of data, and all nodes other than the leaf nodes have the hash values ​​of two child nodes. If even one of the data values ​​of a leaf node is changed, the result value of the hash function changes in a chain for each layer, so the hash value of the root node changes completely. By storing only the root hash value, which is the hash value of this root node, in the blockchain (e.g., Ethereum onchain), it is possible to verify whether or not specific data is included in the merkle tree.

[0069] The term "nullifier" as used herein is a unique identifier used to cancel a previously committed transaction in a blockchain. For example, a nullifier may be any value. Specifically, when a user initiates a transaction in a blockchain, the transaction may include a recipient address, the amount of digital assets (e.g., coins) to be sent, and a nullifier. The nullifier may serve to prove that the user approved the transaction. Once a transaction is processed and added to the blockchain, the nullifier may be stored in the blockchain along with details of the transaction. If a user later attempts to cancel a transaction, the nullifier associated with the transaction may be provided and verification may be performed against the nullifier stored in the blockchain. If the verification is successful, the transaction is invalidated and the transmitted digital assets are returned to the user account. Using nullifiers in a blockchain can prevent double spending. Additionally, a user may be able to cancel a transaction if necessary. This may enhance security of the transaction and privacy protection. Nullifier also makes it possible to create smart contracts that can perform complex calculations while keeping transaction details private.

[0070] As used herein, the terms "private key" and "public key" are terms used in a private-public key algorithm. A private-public key algorithm is asymmetric cryptography, an encryption system that uses two different but mathematically related keys, a private key and a public key. The private key may be a randomly generated number. The private key is kept secret and not revealed to other users. The public key may be derived from the private key using a mathematical algorithm. The public key may be distributed to other users.

[0071] Hereinafter, various embodiments described in this specification will be described with reference to the accompanying drawings. In the accompanying drawings and the description of the drawings, the same or substantially equivalent components may be given the same reference numerals. In addition, in the following description of various embodiments, duplicated descriptions of the same or corresponding components may be omitted, but this does not mean that the components are not included in the embodiment.

[0072] 1 shows an environment in which an apparatus according to an embodiment of the present disclosure may be applied. The environment may include a server 110, a means for transmitting a unique number for a product 120, a blockchain network 130 including one or more nodes 131, or a user terminal 140. Although FIG. 1 shows an example in which one user terminal 140 and eight nodes 131 are connected to the server 110 through a network, this is merely for convenience of understanding, and the number of user terminals 140 may be changed.

[0073] The server 110 may be a server that implements a platform based on a non-fungible token. The server 110 may perform various processes on the non-fungible token. For example, the server 110 may manage a digital asset wallet address in which a user's token is stored. As another example, the server 110 may transmit a minting request to the blockchain network 130 in response to a minting request for a non-fungible token. In one embodiment, the user terminal 140 may transmit a minting request to the server 110, and the server 110 may transmit the received minting request to the blockchain network 130. Then, the minting request may be processed in the blockchain network 130. In another embodiment, the user terminal 140 may transmit a minting request directly to the blockchain network 130 without going through the server 110, in which case, the minting request may be processed in the blockchain network 130. As another example, the server 110 may reflect ownership information that has been changed based on the processing of the minting request. In one embodiment, the server 110 may store and / or manage ownership information of the non-fungible token. In another embodiment, the server 110 may transmit a transaction to the blockchain network 130 to store and / or manage ownership information of a non-fungible token. In this case, for example, the user terminal 140 may transmit a transaction to the server 110 to store and / or manage ownership information, and the server 110 may transmit the received transaction to the blockchain network 130. As another example, the user terminal 140 may transmit a transaction to store and / or manage ownership information directly to the blockchain network 130 without passing through the server 110. In addition to the above examples, the server 110 may perform various operations (e.g., communication between users, etc.) that are generally required in a platform. The server 110 may also be involved in token registration and trading by interacting with the node 131 included in the blockchain network 130.

[0074] The server 110 may be implemented by one or more computing devices. For example, all functions of the server 110 may be implemented in a single computing device. As another example, a first function of the server 110 may be implemented in a first computing device, and a second function of the server 110 may be implemented in a second computing device. Here, the computing device may be, but is not limited to, a desktop computer, a laptop computer, an application server, a proxy server, a cloud server, etc., and may be various devices having computing functions.

[0075] The means 120 for transmitting the unique number of the product may be a means for transmitting the unique number of the product to the user terminal 140. For example, the means 120 for transmitting the unique number of the product may include a near field communication (NFC) 121, a quick response (QR) code 122, a message 123, a chip 124, etc. In one embodiment, the user terminal 140 may receive the unique number of the product using the NFC 121. For example, the user terminal 140 may receive the unique number of the product by contactless communication with an NFC tag attached to the product. In another embodiment, the user terminal 140 may receive the unique number of the product using the QR code 122. The user terminal 140 may receive the unique number of the product by the QR code 122 read by a camera included in the user terminal 140. As yet another example, the user terminal 140 may obtain the unique number of the product by a message including the unique number of the product. For example, the user terminal 140 may receive a message from another electronic device, and the message may include the unique number of the product. As yet another example, the user terminal 140 may receive the unique number of the product through the chip 124. The chip 124 may be a type of electronic device, for example, an IC (Integrated Circuit) chip. The chip 124 may transmit the unique number of the product to the user terminal 140 by communicating with the user terminal 140. The chip 124 may be attached to a product or a card. The user terminal 140 may receive the unique number of the product by communicating with the chip 124 attached to the product or card. The above-mentioned means are merely examples, and the present invention is not limited thereto.

[0076] The node 131 may refer to any one of the devices of the individual participants participating in the blockchain network 130. The node 131 may be one of the components of the blockchain network 130. The node 131 may perform calculations to maintain the blockchain of the blockchain network 130. For example, any one node of the blockchain network 130 may generate a new block of the blockchain, and the new block may be shared among other nodes of the blockchain network through a distributed consensus process and linked to the next block of the blockchain. That is, the node 131 may perform operations such as generating, verifying, or propagating a transaction and a block in which the transaction is recorded. The node 131 may be a full node, a light node, a master node, a mining node, a random node, a baking node, or a super node depending on the operation performed by the node. The node 131 may generate tokens by interacting with the server 110. Node 131 may also interact with server 110 to register the token.

[0077] The node 131 may be embodied by a computing device. For example, the computing device may be, but is not limited to, a desktop computer, a laptop computer, or the like, and may be various devices having computing capabilities.

[0078] Each of the at least one node 131 included in the blockchain network 130 may be referred to as a "participant" of the blockchain network 130. The at least one node included in the blockchain network 130 may operate according to a hierarchical structure. The hierarchical structure may include, for example, at least one of a data hierarchy that defines the structure of data handled by the blockchain network 130 and manages the data, a consensus hierarchy that verifies the validity of blocks, performs mining to generate blocks, and is responsible for processing fees paid to miners in the mining process, a common hierarchy that implements or manages a P2P network protocol, a hash function, a digital signature, encoding, and a common repository, or an application hierarchy in which various applications are created or processed.

[0079] At least one node included in the blockchain network 130 may share or store transactions recorded on the blockchain. In addition, at least one node included in the blockchain network 130 may perform a verification operation on a transaction sent to the blockchain network 130 according to a blockchain consensus algorithm, and when the verification is completed, may have a function of recording the verified transaction in one block on the blockchain. The consensus algorithm performed by the blockchain network 130 may include at least one of a Proof of Work (PoW) algorithm, a Proof of Stake (PoS) algorithm, a Delegated Proof of Stage (DPoS) algorithm, a Practical Byzantine Fault Tolerance (PBFT) algorithm, a Delegated Byzantine Fault Tolerance (DBFT) algorithm, a Redundant Byzantine Fault Tolerance (RBFT) algorithm, a Sieve algorithm, a Tendermint algorithm, a Paxos algorithm, a Raft algorithm, a Proof of Authority (PoA) algorithm, or a Proof of Elapsed Time (PoET) algorithm.

[0080] At least one node included in the blockchain network 130 may each store a smart contract. Thus, at least one node included in the blockchain network 130 may share the same smart contract. The smart contract may be recorded in one block on the blockchain managed by the blockchain network 130. The smart contract may be a document or script written in a programming language such as Solidity, and may be a program or application that runs on a virtual machine executed by at least one node included in the blockchain network 130. The smart contract may be created so that a specific operation is performed when a specific condition is satisfied. In this case, the specific condition may be, for example, a condition that a specific type of token is input or a file in a specific format is input. The specific operation may be, for example, an operation to transmit a specific type of token to any node in the blockchain network 130.

[0081] The user terminal 140 may be a terminal of a user who uses the non-fungible token-based platform. Here, the user can use various functions provided by the platform through the user terminal 140. For example, the user can request token registration, check a dashboard that visualizes the current status of registration, or communicate with other users through the user terminal 140. In order for each user to use the platform, a web browser or a dedicated application may be installed in the user terminal 140. The user terminal 140 may be, for example, any one of devices such as a desktop computer, a workstation, a laptop computer, a tablet computer, an audio player, a wearable device, or a smartphone, but is not limited to this example and may be various computing devices equipped with computing functions.

[0082] The server 110, the node 131, and the user terminal 140 can communicate with each other through a network. The network may be implemented by any type of wired or wireless network, such as a local area network (LAN), a wide area network (WAN), a mobile radio communication network, or a wireless broadband internet (Wibro).

[0083] Meanwhile, the server 110, the node 131, and the user terminal 140 may represent functionally separate elements. That is, two or more components may be embodied in an integrated form in an actual physical environment. For example, the server 110 and the node 131 included in the blockchain network 130 may be embodied in the form of different logics within the same computing device. That is, the server 110 may be embodied to operate as the node 131 of the blockchain network 130.

[0084] FIG. 2 illustrates a computing device 200 that may embody any one of the devices according to an embodiment of the present disclosure. In the present disclosure, the computing device 200 may be expressed as an electronic device, and the terms computing device 200 and electronic device may be used interchangeably. The server 110, the node 131, and the user terminal 140 described above may be embodied by the computing device. The computing device 200 may include one or more processors 210 or one or more memories 220. In an embodiment, some components of the computing device 200 may be omitted, or other components (e.g., a display, etc.) may be added to the computing device 200. Additionally, or alternatively, some components may be integrated or embodied by one or more individual components. In the present disclosure, one or more processors 210 may be expressed as a processor 210. The term processor 210 may refer to a collection of one or more processors, unless otherwise specified in the context. Additionally, in the present disclosure, one or more memories 220 may be referred to as memories 220. Such a reference to memory 220 may refer to a collection of one or more memories, unless the context indicates otherwise.

[0085] At least some of the components in the computing device 200 are connected to each other via a bus, a general purpose input / output (GPIO), a serial peripheral interface (SPI), a mobile industry processor interface (MIPI), or the like, and can exchange data or signals.

[0086] The processor 210 can perform calculations or data processing related to control or communication of each component of the computing device 200. Specifically, the processor 210 can drive software (e.g., instructions, programs, etc.) received from other components and control at least one component of the computing device 200 connected to the processor 210. As an example, the processor 210 can load instructions or data into the memory 220, process the instructions or data stored in the memory 220, and store the result of the processing in the memory 220. The processor 210 can also be operatively connected to the components of the computing device 200 and perform various calculations, processing, data generation, processing, and other operations related to the contents disclosed herein.

[0087] The memory 220 may store various data. The data stored in the memory 220 may include software (e.g., instructions, programs, etc.) that may be acquired, processed, or used by at least one component of the computing device 200. As an example, the memory 220 may store instructions for operation of the processor 210 as a computer program. Here, the computer program may include one or more instructions that, when loaded into the memory 220, cause the processor 210 to perform operations according to various embodiments of the subject matter disclosed herein. That is, the processor 210 may perform operations according to various embodiments of the subject matter disclosed herein by executing one or more of the instructions. In addition, the memory 220 may include volatile or non-volatile memory. In one embodiment, the instructions or programs are software stored in the memory 220 and may include an operating system for controlling resources of the computing device 200, applications, or middleware that provides various functions to applications so that the applications can utilize the resources of the computing device 200.

[0088] In one embodiment, the computing device 200 may further include a communication interface 230. The communication interface 230 may establish a wired or wireless communication channel with an external device (e.g., the node 131 or the user terminal 140) and transmit and receive various data to and from the external device. In one embodiment, the communication interface 230 may include at least one port for connecting to an external device via a wired cable in order to communicate with the external device via a wire. In this case, the communication interface 230 may communicate with the external device connected via a wired cable through the at least one port. In one embodiment, the communication interface 230 may include a cellular communication module and be configured to be connected to a cellular network (e.g., 3G, LTE, 5G, Wibro, or Wimax). In one embodiment, the communication interface 230 may include a short-range communication module and may transmit and receive data to and from the external device using short-range communication (e.g., Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), UWB). In one embodiment, the communication interface 230 may include a contactless communication module for contactless communication. Here, the contactless communication may include at least one contactless proximity communication technology such as NFC communication, Radio Frequency Identification (RFID) communication, or Magnetic Secure Transmission (MST) communication. In addition to the various examples described above, the computing device 200 may be embodied in various known methods for communicating with an external device, and the scope of the present disclosure is not limited to the above examples.

[0089] In an embodiment, the computing device 200 may further include a display. Here, the display may display various screens under the control of the processor 210. For example, the display may display a dashboard visualizing the current status of the registration of platform users under the control of the processor 210. In this case, for example, a web browser or a dedicated application may be installed in the computing device 200 to display the dashboard on the display. In an embodiment, the web browser or the dedicated application may be implemented to provide a user with a registration request function or a communication function with other users through a user interface. In addition, the display is configured to be able to interact with a user, and may display various screens and receive user input from the user under the control of the processor 210. Such a display may be implemented in the form of a touch sensor panel (TSP) that can recognize contact or approach of various external objects (e.g., a finger, a stylus, etc.). Here, the touch sensor panel may have various structures and types, and the contents disclosed in the present specification are applicable to all of them regardless of the structure and type of the touch sensor panel.

[0090] In one embodiment, computing device 200 may further include an input device (e.g., a mouse, a keyboard, etc.) that can receive data from outside computing device 200 (e.g., a user) for use by components of computing device 200 (e.g., processor 210).

[0091] FIG. 3 is a diagram illustrating a method for minting non-fungible tokens for physical goods according to one embodiment of the subject matter disclosed herein.

[0092] The product A 310 in FIG. 3 may be a real product. For example, the product A 310 may include a performance ticket, a viewing ticket, a ticket for a sporting event, a bag, clothing, shoes, precious metals, food, and the like. The product A 310 may include a device for contactless communication. For example, if the product A 310 is a performance ticket, a device having an NFC function may be attached to the performance ticket. A user can issue a non-fungible token for a ticket he or she has purchased and prove ownership of the ticket. In addition, a user can safely trade tickets with other users in the marketplace by being issued a non-fungible token for the ticket. The reason that a real ticket can be safely traded is that there is no risk of losing the real ticket that occurs when trading a real ticket directly between parties, and ownership of the ticket is guaranteed. Therefore, by issuing a ticket as a non-fungible token and proving ownership, a user can attend a performance or exhibition even if he or she loses the real ticket, or sell the ticket to another user. A method for minting a non-fungible token for a real product will be described below.

[0093] According to an embodiment, an electronic device may be attached to the product A 310. For example, the electronic device may include a contactless communication module. For example, the electronic device may exchange data with the user terminal 140 through contactless communication such as NFC communication, RFID communication, or MST communication. For example, a performance planning company may assign a unique number to each ticket while selling performance tickets to a user, and store the unique number in an electronic device attached to the ticket. Then, according to an embodiment, the user terminal 140 may receive the unique number for the product from the electronic device attached to the product. For example, the user terminal 140 may receive the unique number for the product A 310 from the electronic device attached to the product A 310. The user terminal 140 may receive the unique number and transmit a minting request 320 for the ticket to the blockchain network 130. A detailed description of the minting request 320 will be given with reference to FIG. 4A to FIG. 4F.

[0094] 4A and 4B are flow charts illustrating methods of minting non-fungible tokens for physical goods according to various embodiments of the subject matter disclosed herein.

[0095] According to one embodiment, the product seller terminal 410 may generate a unique number for a product (S411). The product seller terminal 410 may be a terminal of an organization or individual that sells a product. In another embodiment, the product seller terminal 410 may be replaced by a product manufacturer terminal. The product manufacturer terminal may be a terminal of an organization or individual that produces a product.

[0096] For example, if the product seller is a performance planning company, the performance planning company can issue multiple performance tickets related to a particular performance. The performance planning company's terminal 410 can generate a unique number corresponding to each of the multiple performance tickets issued. The performance planning company can attach an electronic device storing the ticket unique number to each performance ticket and deliver the performance tickets to the purchaser who purchased the performance tickets.

[0097] According to an embodiment, the product seller terminal 410 may generate a hash value of the unique number and a Merkle tree for the hash value of the unique number (S412). The hash value of the unique number may be a value obtained by hashing the unique number using a specific hash function. The product seller terminal 410 may generate a Merkle tree in which each hash value of a plurality of unique numbers is at least one leaf node. For example, a second terminal (e.g., the product seller terminal 410) of a company that sells products may generate a Merkle tree (e.g., a first Merkle tree) based on a hash value obtained by hashing the unique numbers of a plurality of products generated by the second terminal. When the Merkle tree is generated, the product seller terminal 410 may transmit a Merkle root (e.g., a first Merkle root) based on the Merkle tree (e.g., a first Merkle tree) to the smart contract 450 (S413). By including the Merkle root in the smart contract 450, the Merkle root may be made public on the blockchain network. For example, the smart contract 450 may include a first Merkle root of a first Merkle tree obtained by hashing multiple unique numbers generated by a second terminal (e.g., the product seller terminal 410) of a company selling goods.

[0098] According to an embodiment, the product seller terminal 410 may store the unique number and a Merkle proof value (e.g., a first Merkle proof value) in an electronic device attached to the product (S414). The Merkle proof value may be a set including at least some of the nodes included in the Merkle tree. For example, the Merkle proof value may include only a minimum number of nodes required to reconstruct the Merkle root. For example, the product seller terminal 410 may store the unique number and the first Merkle proof value of the first Merkle tree in the electronic device.

[0099] According to an embodiment, the product seller terminal 410 may sell a product having an electronic device attached thereto to a user (S415). The operation of selling the product to the user may be performed online and / or offline. For example, the product seller terminal 410 may sell a product having an electronic device including an NFC function attached thereto. A buyer may receive the product and perform NFC tagging on his / her terminal. By NFC tagging, the user terminal 430 may receive a unique number and / or a Merkle certificate value of the product from the electronic device attached to the product. Alternatively, the user terminal may receive the unique number through a message, RFID communication, QR code, etc., and the present invention is not limited thereto.

[0100] According to an embodiment, the user terminal 430 may generate a zero-knowledge proof value of the unique number (S431). The user terminal 430 may generate the zero-knowledge proof value of the unique number based on at least one of the unique number, the hash value of the unique number, or the proof key. The user terminal 430 may generate the zero-knowledge proof value of the unique number using a proof algorithm with at least one of the unique number, the hash value of the unique number, or the proof key as a parameter. The proof key may be generated in a pair with the verification key based on the hash value of the unique number. The (proof key, verification key) pair may be generated from a key generator with the hash value of the unique number and an arbitrary value as a parameter. The key generator may be a key generator that generates an arbitrary key value based on a parameter.

[0101] In another embodiment, the user terminal 430 may generate a zero-knowledge proof value of the unique number based on at least one of the unique number, the hash value of the unique number, the recipient address, or the proof key. The user terminal 430 may obtain a zero-knowledge proof value of the unique number that has a dependency on the recipient address by generating a zero-knowledge proof value of the unique number using the recipient address. This allows the zero-knowledge proof value of the unique number to be changed when the recipient address is changed, thereby preventing a front-running attack by a third party. A front-running attack may be an attack using a process in which a transaction is registered in a blockchain. A third party can gain by imitating a pending transaction in real time, paying a high gas fee, and having the imitated transaction stored in a block first. However, if the dependency of the recipient address is added to the zero-knowledge proof value of the unique number, the third party cannot imitate the zero-knowledge proof value of the unique number because the recipient address of the imitated transaction by the third party is changed to the wallet address of the third party. This allows a front-running attack by a third party to be prevented.

[0102] According to an embodiment, the user terminal 430 may generate a transaction including at least one of a hash value of the unique number, a recipient address, or a zero-knowledge proof value of the unique number (S432). The transaction may further include a first Merkle proof value generated by a first Merkle tree. The user terminal 430 may transmit the generated transaction to the smart contract 450 (S433). The generated transaction may be a transaction requesting minting of a non-fungible token corresponding to the product. Since the unique number is not included in the transaction, the unique number for the product is not disclosed on the blockchain network. Therefore, it is possible to prevent a third party from maliciously intercepting the unique number for the product disclosed on the blockchain and attributing ownership to a third party. The unique number for the product is not disclosed on the blockchain, and the process of verifying whether the user terminal 430 knows the unique number allows the owner of the product to safely receive a non-fungible token for the product.

[0103] When a transaction according to an embodiment is sent to a blockchain network, a computing resource of the blockchain network is used to execute the transaction, and therefore a fee may be incurred as a fee for using the computing resource. Therefore, when the user terminal 430 requests minting while sending a transaction, the user of the user terminal 430 may have to pay the fee. This may be a factor that reduces user participation in the minting platform. Therefore, the platform operator can reduce the fee burden of the user by using a relay device that pays the fee for sending the transaction. The relay device can request the fee from the product seller terminal. This can increase user participation in the platform. Since the unique number is not included in the transaction in the present invention, even if the relay device receives the transaction and sends it to a node in the blockchain network, there is no risk of the unique number being exposed. Furthermore, since the zero-knowledge proof value of the unique number is dependent on the recipient address, even if the recipient address is received by the relay device, if the recipient address is changed, the zero-knowledge proof value of the unique number changes, and therefore a third party cannot imitate the transaction that passes through the relay device. Therefore, even if there is a relay device that pays the fee for sending the transaction, security can be maintained.

[0104] In this specification, the operations of smart contract 450 may be understood as operations of a processor coupled to a computer network, including a blockchain network, and may be operations performed by the processor executing the smart contract.

[0105] The processor according to an embodiment may execute the smart contract 450 and verify the transaction (S451). The processor according to an embodiment may verify the transaction including the zero-knowledge proof value of the unique number corresponding to the unique number. The processor may verify the hash value of the unique number included in the transaction to verify the transaction. The processor may obtain a Merkle root based on the hash value of the unique number and a Merkle proof value (e.g., a first Merkle proof value). The processor may then determine whether the Merkle root obtained based on the hash value of the unique number and the Merkle proof value (hereinafter, Merkle root A) matches the Merkle root stored in the smart contract 450 (hereinafter, Merkle root B). If the obtained Merkle root (Merckle root A) matches the Merkle root stored in the smart contract 450 (Merckle root B), the processor may determine that the transaction verification has been successful (S453). Conversely, if the acquired Merkle root (Merkle root A) does not match the Merkle root (Merkle root B) stored in the smart contract 450, the processor may determine that the transaction verification has failed (S452). In operation (S452), the processor may send a transaction verification failure result message to the user terminal 430. The method of verifying a transaction using a Merkle tree is merely an example, and transaction verification may be performed by other verification methods, and the present invention is not limited thereto.

[0106] In one embodiment, the processor may verify the unique number zero-knowledge proof value (S454) when the transaction verification is successful (S453). The processor may perform a verification algorithm based on at least one of the unique number zero-knowledge proof value, the unique number hash value, or the verification key. As described above, the unique number zero-knowledge proof value is a value obtained using a verification algorithm that uses at least one of the unique number, the unique number hash value, or the verification key as a parameter. The verification key is a symmetric key with the verification key. If the result of the verification algorithm is true, the processor may determine that the prover's user terminal 430 knows the unique number. In this case, the unique number zero-knowledge proof value verification may be successful (S456). Conversely, if the result of the verification algorithm is false, the processor may determine that the prover's user terminal 430 does not know the unique number. In this case, the unique number zero-knowledge proof value verification may be unsuccessful (S455). In the operation (S455), the processor may transmit a result message of the unique number zero-knowledge proof value verification failure to the user terminal 430. A prover may be a terminal that wishes to prove that it knows a unique number that has not been published in the blockchain network.

[0107] When the zero-knowledge proof value of the unique number according to one embodiment is successfully verified (S456), the processor may invalidate the hash value of the unique number (S457). For example, the operation of invalidating the hash value of the unique number may be an operation of nullifying the hash value of the unique number. As another example, the operation of invalidating the hash value of the unique number may be an operation of invalidating the transaction. Thus, the processor may prevent double payment by the transaction of operation (S433).

[0108] According to an embodiment, the processor may mint a non-fungible token for the commodity to the recipient address (S458). The recipient address may be a digital asset wallet address of the user terminal 410 that requested the minting. The transaction may further include the recipient address. Further, the processor may mint a non-fungible token for the commodity to the recipient address. In this way, ownership of the non-fungible token for the commodity belongs to the user terminal 430 that sent the transaction, and the user of the user terminal 430 can prove ownership of the commodity.

[0109] The processor according to an embodiment may distribute the non-fungible token of the product to the blockchain network (S459). The operation of distributing the non-fungible token to the blockchain network may be expressed as an operation of dropping the non-fungible token. The non-fungible token being distributed to the blockchain network may mean that the non-fungible token is registered in the marketplace. Thus, the user can sell the non-fungible token registered in the marketplace to other users. This allows the user to attribute the non-fungible token of the product to his / her own digital asset wallet, easily perform ownership proof, and further allows the user to safely trade the product with other users in the marketplace using the non-fungible token of the product.

[0110] 4C and 4F illustrate an embodiment in which the smart contract 450 is divided into a plurality of smart contracts. The smart contract may be divided into a plurality of smart contracts according to function. For example, the smart contract may implement operations related to the minting of a non-fungible token in one smart contract or in different smart contracts. For example, the operation of receiving a minting request may be implemented in the first smart contract 460, and the operation of verifying a transaction may be implemented in the second smart contract 470. As a result, it is not necessary to amend the entire smart contract every time the conditions for whether or not the minting of a non-fungible token is permitted change, and only the smart contract (e.g., the second smart contract 470) that implements the operation of determining whether or not the minting of a non-fungible token is permitted can be amended and the smart contract can be used. For example, the conditions for whether or not minting is permitted may differ for each product seller. Therefore, instead of modifying the entire smart contract that embodies a series of operations related to minting to suit each product seller, it is only necessary to modify a smart contract that embodies an operation that determines whether minting is permitted, which is a part of the series of operations related to minting, separately, which can dramatically reduce the cost and time required to implement a series of operations related to minting of non-fungible tokens. In other words, it is only necessary to modify a smart contract (e.g., the second smart contract 470) that determines the conditions for whether minting is permitted, which is a part of the minting-related operations, separately from the entire smart contract, and modify only the smart contract (e.g., the second smart contract 470) to suit the conditions for whether minting is permitted, which are set differently for each product seller, thereby reducing the cost and time required to create a smart contract that embodies a series of operations related to minting.

[0111] 4C and 4D may be examples in which smart contract 450 is divided into a first smart contract 460 and a second smart contract 470.

[0112] Operations (S411), (S412), (S414), (S415), (S431), (S432) and (S433) have been described in detail above in FIG. 4A and FIG. 4B, and therefore detailed description thereof will be omitted in this figure.

[0113] The operation of the first smart contract 460 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The operation of the second smart contract 470 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. A computing device including a processor that executes the first smart contract 460 and a computing device including a processor that executes the second smart contract 470 may be the same or different from each other.

[0114] In one embodiment, the product seller terminal 410 may send (S413) a Merkle root (e.g., a first Merkle root) based on the generated Merkle tree to the second smart contract 470. In another embodiment, the product seller terminal 410 may send a Merkle root based on the generated Merkle tree to the first smart contract 460. The first smart contract 460 may then send the Merkle root to the second smart contract 470. The second smart contract 470 may store the Merkle root.

[0115] According to an embodiment, the first smart contract 460 may receive a transaction from a terminal. The second smart contract 470 may verify the transaction and verify the zero-knowledge proof value of the unique number. The first smart contract 460 may mint a non-fungible token based on the verification result.

[0116] In one embodiment, the processor may execute the first smart contract 460 to request verification from the second smart contract 470 in response to a transaction transmission from the user terminal 430 (S461). In operation (S461), the verification may refer to transaction verification and / or verification of a zero-knowledge proof value of the unique number. The processor may execute the second smart contract 470 in response to the verification request. In operation (S461), the verification request may include an operation of sending at least one of a hash value of the unique number, a recipient address, a verification key, or a zero-knowledge proof value of the unique number to the second smart contract 470.

[0117] The processor according to an embodiment may verify the transaction (S471) by executing the second smart contract 470. In the transaction verification, a Merkle proof value included in the second smart contract 470 may be used. The transaction verification has been specifically described above in the operation (S451) of FIG. 4A and FIG. 4B, and therefore a detailed description with reference to the same figures will be omitted. If the transaction verification fails (S472), the processor may send a result message of the transaction verification failure to the first smart contract 460 and / or the user terminal 430.

[0118] If the transaction verification according to an embodiment is successful (S473), the processor may verify the zero-knowledge proof value of the unique number (S474). The zero-knowledge proof value verification of the unique number has been specifically described above in the operation (S454) of FIG. 4A and FIG. 4B, and therefore a detailed description with reference to the same figure will be omitted. If the verification of the zero-knowledge proof value of the unique number fails (S475), the processor may send a result message of the failure of the verification of the zero-knowledge proof value of the unique number to the first smart contract 460 and / or the user terminal 430. If the verification of the zero-knowledge proof value of the unique number is successful (S476), the processor may send the verification result to the first smart contract 460 (S477). The verification result sent in the operation (S477) may include the transaction verification success and the zero-knowledge proof value verification success of the unique number.

[0119] The first smart contract 460 according to an embodiment may receive the verification result and perform an operation (S467). Based on the verification result, the processor may invalidate (S467) the hash value of the unique number. By invalidating the operation (S467), the transaction of the operation (S433) is invalidated, and double payment of the non-fungible token may be prevented. The processor according to an embodiment may mint (S468) the non-fungible token of the commodity to the recipient address by executing the first smart contract 460. In addition, the processor may perform an operation (S469) by executing the first smart contract 460. The operations (S467), (S468), and (S469) have been specifically described above in the operations (S457), (S458), and (S459) of FIG. 4A and FIG. 4B, and therefore a detailed description with reference to the same figures will be omitted. In other embodiments, at least some of operations (S467), (S468), and (S469) may be performed by the second smart contract 460, and the present invention is not limited in this respect.

[0120] 4E and 4F may be examples in which smart contract 450 is divided into a first smart contract 460, a second smart contract 470, and a third smart contract 480.

[0121] Operations (S411), (S412), (S414), (S415), (S431), (S432), and (S433) have been described in detail above with reference to Figures 4A and 4B, and therefore detailed description with reference to the same figures will be omitted.

[0122] The operation of the first smart contract 460 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The operation of the second smart contract 470 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The operation of the third smart contract 480 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The computing device including a processor that executes the first smart contract 460, the computing device including a processor that executes the second smart contract 470, and the computing device including a processor that executes the third smart contract 480 may be the same or different from each other.

[0123] In one embodiment, the product seller terminal 410 can send a Merkle root (e.g., a first Merkle root) based on the generated Merkle tree to the second smart contract 470. In another embodiment, the product seller terminal 410 can send a Merkle root based on the generated Merkle tree to the first smart contract 460. The first smart contract 460 can then send the Merkle root to the second smart contract 470. The second smart contract 470 can store the Merkle root.

[0124] According to an embodiment, the first smart contract 460 may receive a transaction from a terminal. The first smart contract 460 may also mint a non-fungible token based on the verification result. The second smart contract 470 may verify the transaction. The third smart contract 480 may verify the zero-knowledge proof value of the unique number. Since the conditions for transaction verification may differ for each product, the cost and time required to implement a smart contract for a minting method for each product may be reduced by separately implementing only the second smart contract 470. For example, transaction verification of a performance planning company that sells performance tickets may be implemented using a Merkle tree, and transaction verification of an exhibition planning company that sells exhibition tickets may be implemented by public key-private key verification. Therefore, the second smart contract 470 may be implemented differently depending on the verification method, and therefore there is a practical benefit in separating the second smart contract 470 from the first smart contract 460 and the third smart contract 480. This allows organizations or individuals who create smart contracts at the request of their customers to respond to various companies' requirements for transaction verification methods to create smart contracts that implement a series of operations related to minting with little time and cost.

[0125] In one embodiment, the processor may execute the first smart contract 460 to request verification from the second smart contract 470 (S461). In operation (S461), the verification may refer to transaction verification. The processor may execute the second smart contract 470 in response to the verification request. In operation (S461), the verification request may include an operation of sending a hash value of the unique number, a recipient address, and a zero-knowledge proof value of the unique number to the second smart contract 470.

[0126] The processor according to an embodiment may verify the transaction (S471) by executing the second smart contract 470. In the transaction verification, the Merkle proof value included in the second smart contract 470 may be used. The transaction verification is the same as the operation (S451) of FIG. 4A and FIG. 4B, and detailed description with reference to the figures will be omitted. If the transaction verification fails (S472), the processor may send a transaction verification failure result message to the first smart contract 460 and / or the user terminal 430. If the transaction verification is successful (S473), the processor may make a request to the third smart contract 480 to verify the zero-knowledge proof value of the unique number (S474). The operation (S474) may include an operation of sending at least one of the zero-knowledge proof value of the unique number, the hash value of the unique number, or the verification key to the third smart contract 480.

[0127] The processor according to an embodiment may verify the zero-knowledge proof value of the unique number by executing the third smart contract 480 (S481). The verification of the zero-knowledge proof value of the unique number is the same as the operation (S454) of FIG. 4A and FIG. 4B, and a detailed description with reference to the figures will be omitted. If the verification of the zero-knowledge proof value of the unique number fails (S482), the processor may transmit a result message of the failure of the verification of the zero-knowledge proof value of the unique number to the first smart contract 460, the second smart contract 470, and / or the user terminal 430. If the verification of the zero-knowledge proof value of the unique number is successful (S483), the processor may transmit the verification result to the second smart contract 470 (S484). The verification result transmitted in the operation (S484) may include the successful verification of the zero-knowledge proof value of the unique number. The processor according to an embodiment may transmit the verification result to the first smart contract 460 (S474). The verification result sent in operation (S474) may include successful transaction verification and successful zero-knowledge proof value verification of the unique number.

[0128] The first smart contract 460 according to an embodiment may receive the verification result and perform an operation (S467). Based on the verification result, the processor may invalidate (S467) the hash value of the unique number. By invalidating the operation (S467), the transaction of the operation (S433) is invalidated, and double payment of the non-fungible token may be prevented. The processor according to an embodiment may mint (S468) the non-fungible token of the product to the recipient address by executing the first smart contract 460. In addition, the processor may perform an operation (S469) by executing the first smart contract 460. The operations (S467), (S468), and (S469) have been specifically described above in the operations (S457), (S458), and (S459) of FIG. 4A and FIG. 4B, and therefore a detailed description with reference to the figures will be omitted. In other embodiments, at least some of operations (S467), (S468) and (S469) may be performed by the second smart contract 460 or the third smart contract 470, and the present invention is not limited in this respect.

[0129] FIG. 5 is a diagram illustrating a method for minting non-fungible tokens via a third terminal according to one embodiment of the subject matter disclosed herein.

[0130] According to an embodiment, a user can receive data required for minting from an electronic device using a user terminal 140 (e.g., a first terminal). An electronic device (e.g., a third terminal 510) that transmits data required for minting to the user terminal 140 may generate a unique number and store a personal key for signing. For example, the above-mentioned electronic device (e.g., a third terminal 510) may be a device provided by a product seller. A product seller terminal 610 (e.g., a second terminal) can generate a personal key and transmit the generated personal key to an electronic device (e.g., a third terminal 510). The personal key can be used to sign a unique number generated by the electronic device (e.g., a third terminal 510). The above-mentioned electronic device (e.g., a third terminal 510) may include, for example, a kiosk, an IC card, an electronic device in which an application for generating a unique number is installed, and the like.

[0131] In one embodiment, when the third terminal 510 is a terminal 511 having an NFC function 121, the user can perform NFC tagging using the user terminal 140. In this case, the user terminal 140 can receive the unique number of the product and a personal key from the terminal 511.

[0132] In another embodiment, when the third terminal 510 is a terminal 512 having the QR function 122, a QR code may be displayed on the screen of the terminal 512. The QR code displayed on the screen may be generated and displayed on the screen every time a QR code generation request is made, and after a certain period of time, the QR code may disappear from the screen or a new QR code may be generated. This prevents non-fungible tokens from being double-distributed by another user requesting minting of a non-fungible token to one QR code, and prevents ownership of a product from being attributable to an unauthorized person. The user may scan the QR code of the terminal 512 using the user terminal 140. In this case, the user terminal 140 may receive the unique number and personal key of the product from the terminal 512.

[0133] The above-described operation of the user terminal 140 receiving the unique number and the personal key is merely an example, and the unique number and the personal key may be received by other communication methods, and the present invention is not limited thereto.

[0134] According to an embodiment, the third terminal 510 may generate a unique number for a product. The unique number generated by the third terminal 510 may be any value. The third terminal 510 may generate the unique number when there is a request to generate a unique number. For example, the request to generate a unique number may be received from the user terminal 140. For example, the third terminal 510 may receive the request to generate a unique number through NFC communication between the user terminal 140 and the third terminal 510. As another example, the third terminal 510 may generate a unique number when generating a QR code and include the unique number in the QR code.

[0135] In one embodiment, a production company may sell tickets to a user for a performance. The tickets may be sold at an electronic device (e.g., a kiosk) located at a particular location. The user may NFC tag each ticket to the electronic device (e.g., the kiosk) located at the particular location and request minting of a non-fungible token for the ticket.

[0136] According to an embodiment, the user terminal 140 may receive a unique number and a personal key for a product from an electronic device (e.g., the third terminal 510). For example, the user terminal 140 may receive a unique number and a personal key for a product from the third terminal 510. The user terminal 140 may transmit a minting request 520 for the ticket to the block chain network 130. A detailed description of the minting request 520 will be provided with reference to FIGS. 6A to 6H.

[0137] 6A and 6B are flow charts illustrating methods of minting non-fungible tokens via a third terminal according to various embodiments of the subject matter disclosed herein.

[0138] According to one embodiment, the product seller terminal 610 can transmit the personal key to the third terminal 620 (S611). The product seller terminal 610 may be a terminal of an organization or individual that sells a product. In another embodiment, the product seller terminal 610 may be replaced by a product producer terminal. The product producer terminal may be a terminal of an organization or individual that produces a product.

[0139] According to an embodiment, the product seller terminal 610 may transmit a public key corresponding to the private key to the smart contract 650 (S612). The processor may execute the smart contract 650 and verify the signature data signed with the private key using the public key included in the smart contract 650. Verification using the public key will be described in detail later as an operation (S651).

[0140] As an example, if the product seller is a performance planning company, the performance planning company may issue a number of performance tickets related to a particular performance. Then, the performance planning company's terminal 410 may sell the issued number of performance tickets at a kiosk located in a particular location (e.g., a performance venue, a subway station). The performance planning company may store a private key for signing the unique number in the kiosk. Then, a public key corresponding to the private key may be stored in the blockchain network. Thus, a private key-public key algorithm may be used to verify a transaction requesting minting. A user may purchase a ticket using a kiosk and user terminal 630 located in a particular location. When a user purchases a ticket at a kiosk, the user terminal 630 may receive the unique number and the private key from the kiosk by NFC tagging. As another example, the user terminal 630 may scan a QR code displayed on the kiosk and receive the unique number and the private key from the kiosk.

[0141] According to an embodiment, the user terminal 630 may request data related to minting of a non-fungible token of a product (S631). The operation (S631) may be performed by the user terminal 630 communicating with the third terminal 620 in a contactless manner or by the user terminal 630 scanning a QR code displayed on the screen of the third terminal 620.

[0142] According to an embodiment, the third terminal 620 may generate a unique number and a hash value of the unique number (S621). The unique number may be a value generated arbitrarily. The third terminal 620 may generate the unique number when receiving a request in the operation (S631). The hash value of the unique number is a value obtained by hashing the unique number with a specific hash function.

[0143] According to an embodiment, the third terminal 620 may generate signature data by signing the hash value of the unique number with a private key (S622). The private key may be the key received from the product seller terminal 610 in operation (S611).

[0144] According to an embodiment, the third terminal 620 may transmit the unique number and the signature data to the user terminal 630 (S623).

[0145] In one embodiment, when the third terminal 620 and the user terminal 630 exchange data through contactless communication, the generated unique number may be transmitted to the user terminal 630. In another embodiment, when the third terminal 620 and the user terminal 630 exchange data using a QR code, the QR code displayed on the screen of the third terminal 620 may be invalidated after a certain period of time has elapsed. Therefore, if the user terminal 630 does not scan the QR code displayed on the screen of the third terminal 620 within a certain period of time, the user terminal 630 cannot obtain the unique number and the personal key.

[0146] According to an embodiment, the user terminal 630 may generate a zero-knowledge proof value of the unique number (S632). The user terminal 430 may generate the zero-knowledge proof value of the unique number based on at least one of the unique number, the hash value of the unique number, or the proof key. In an embodiment, the user terminal 430 may generate the zero-knowledge proof value of the unique number using a proof algorithm with at least one of the unique number, the hash value of the unique number, or the proof key as a parameter. In another embodiment, the user terminal 430 may generate the zero-knowledge proof value of the unique number based on at least one of the unique number, the hash value of the unique number, the recipient address, or the proof key. The operation of generating the zero-knowledge proof value of the unique number has been specifically described above with reference to FIG. 4A and FIG. 4B, and therefore a detailed description with reference to the same figures will be omitted.

[0147] According to an embodiment, the user terminal 630 may generate a transaction including at least one of a hash value of the unique number, a recipient address, signature data, or a zero-knowledge proof value of the unique number (S633). The signature data is data obtained by signing the hash value of the unique number with a private key. The user terminal 630 may send the generated transaction to the smart contract 650 (S634). The generated transaction may be a transaction requesting minting of a non-fungible token corresponding to the product. Since the unique number is not included in the transaction, the unique number for the product does not need to be disclosed on the blockchain network. This can prevent malicious acts using the unique number for the product disclosed on the blockchain network.

[0148] In this specification, the operations of smart contract 650 may be understood as operations of a processor coupled to a computer network including a blockchain network, and the operations of smart contract 650 may be operations performed by the processor executing the smart contract.

[0149] In one embodiment, the processor can execute the smart contract 650 and verify the transaction (S651). In operation (S651), the processor can verify the signature data. The processor can determine whether the public key of the signature data matches the public key stored in the smart contract 650. If the public key of the signature data is different from the public key stored in the smart contract 650, the processor can determine that the transaction verification has failed. The processor can then execute operation (S652). In operation (S652), the processor can send a result message of the transaction verification failure to the user terminal 630.

[0150] In one embodiment, the processor can verify the zero-knowledge proof value of the unique number (S654) when the transaction verification is successful (S653). The processor can perform a verification algorithm based on at least one of the zero-knowledge proof value of the unique number, the hash value of the unique number, or the verification key. If the result of the verification algorithm is true, the processor can determine that the user terminal 630 of the prover knows the unique number. In this case, the unique number zero-knowledge proof value verification may be successful (S656). Conversely, if the result of the verification algorithm is false, the processor can determine that the user terminal 630 of the prover does not know the unique number. In the operation (S655), the processor can transmit a result message of failure of the zero-knowledge proof value verification of the unique number to the user terminal 630.

[0151] In one embodiment, when the verification of the zero-knowledge proof value of the unique number is successful (S656), the processor can invalidate the hash value of the unique number (S657). In one embodiment, the operation of invalidating the hash value of the unique number may be an operation of invalidating the transaction. In another embodiment, the operation of invalidating the hash value of the unique number may include an operation of changing the hash value of the unique number to a used state. The hash value of the unique number that has been changed to a used state cannot be reused. This makes it possible to prevent the hash value of the unique number from being reused and causing double payment. In the case where the nullifier verification is successful, the processor can invalidate the transaction of the operation (S633). Thus, the processor can prevent double payment by the transaction of the operation (S633).

[0152] Operations S658 and S659 have been specifically described above as operations S458 and S459 in FIG. 4A and FIG. 4B, and therefore a description thereof with reference to those figures will be omitted.

[0153] 6C-6H illustrate an embodiment in which smart contract 650 is split into multiple smart contracts.

[0154] A smart contract may be divided into a plurality of smart contracts according to function. For example, a smart contract may implement operations related to minting of a non-fungible token in one smart contract or in different smart contracts. By dividing a smart contract into a plurality of smart contracts according to function, an organization or individual providing a non-fungible token-related service can separate only the functions that require customization for each content provider (e.g., a performance planning company, etc.) and configure them as separate smart contracts. In addition, when a smart contract is divided into a plurality of smart contracts according to function, a smart contract corresponding to a function for which it is important to ensure reliability and a smart contract corresponding to other less important functions can be separately configured. In this way, when a change (update) of the service content is required later, the smart contract corresponding to the important function can be maintained and the smart contract corresponding to the less important function can be redistributed to the blockchain network to reflect the change in the service content. Therefore, by dividing a smart contract into a plurality of smart contracts according to function, unnecessary redistribution of smart contracts can be minimized. In addition, since the gas fee can increase as the content included in a smart contract increases, gas fees and computing resources can be saved by dividing a smart contract by function and minimizing the redistribution of smart contracts. 6C and 6D may be examples in which smart contract 650 is embodied by dividing it into a first smart contract 660 and a second smart contract 670.

[0155] Operations (S611), (S612), (S631), (S621), (S622), (S623), (S632) and (S633) have been described in detail above with reference to Figures 6A and 6B, and therefore detailed description with reference to the same will be omitted.

[0156] The operation of the first smart contract 660 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The operation of the second smart contract 670 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The computing device including a processor that executes the first smart contract 660 and the computing device including a processor that executes the second smart contract 670 may be the same or different from each other.

[0157] In one embodiment, the product seller terminal 610 can send a public key corresponding to the private key to the second smart contract 670. In another embodiment, the product seller terminal 610 can send the public key to the first smart contract 660. The first smart contract 660 can then send the public key to the second smart contract 670. The second smart contract 670 can store the public key.

[0158] In one embodiment, the first smart contract 660 may receive a transaction from a terminal. The second smart contract 670 may verify the transaction and verify the zero-knowledge proof value of the unique number. The first smart contract 660 may mint a non-fungible token based on the verification result received from the second smart contract 670.

[0159] In one embodiment, the processor may execute the first smart contract 660 to request verification from the second smart contract 670 in response to a transaction transmission from the user terminal 630 (S661). In operation (S661), the verification may refer to transaction verification and / or verification of a zero-knowledge proof value of the unique number. The processor may execute the second smart contract 670 in response to the verification request. In operation (S661), the verification request may include an operation of sending at least one of a hash value of the unique number, a recipient address, signature data, a verification key, or a zero-knowledge proof value of the unique number to the second smart contract 670.

[0160] The processor according to an embodiment may verify the transaction (S671) by executing the second smart contract 670. In operation (S671), the processor may verify the signature data. Operation (S671) was previously described as operation (S651) in FIG. 6A and FIG. 6B, and therefore a detailed description with reference to the figures will be omitted. If the transaction verification fails (S672), the processor may send a transaction verification failure result message to the first smart contract 660 and / or the user terminal 630.

[0161] In one embodiment, if the transaction verification is successful (S673), the processor may verify the zero-knowledge proof value of the unique number (S674). The operation (S674) has been described above in the operation (S654) of FIG. 6A and FIG. 6B, so a detailed description with reference to the figures will be omitted. If the verification of the zero-knowledge proof value of the unique number fails, the processor may send a result message of failure to verify the zero-knowledge proof value of the unique number to the first smart contract 660 and / or the user terminal 630 (S675).

[0162] If the zero-knowledge proof value verification of the unique number is successful (S676), the processor may transmit (S677) the verification result to the first smart contract 660 and / or the user terminal 630. The verification result transmitted in operation (S677) may include successful transaction verification and successful zero-knowledge proof value verification of the unique number.

[0163] According to an embodiment, the first smart contract 660 may receive the verification result and perform an operation (S667). Based on the verification result, the processor may invalidate the hash value of the unique number (S667). According to an embodiment, the processor may execute the first smart contract 660 to mint a non-fungible token of the commodity to the recipient address (S668). The processor may also execute the first smart contract 660 to perform an operation (S669). The operations (S667), (S668), and (S669) have been specifically described above as operations (S657), (S658), and (S659) in FIG. 6A and FIG. 6B, and therefore a detailed description with reference to the same figures will be omitted. In another embodiment, at least a portion of the operations (S667), (S668), and (S669) may be executed by the second smart contract 670, and the present invention is not limited thereto.

[0164] 6E and 6F may be examples in which smart contract 650 is divided into a first smart contract 660, a second smart contract 670, and a third smart contract 680.

[0165] Operations (S611), (S612), (S631), (S621), (S622), (S623), (S632) and (S633) have been described in detail above with reference to Figures 6A and 6B, and therefore detailed description with reference to the same will be omitted.

[0166] The operation of the first smart contract 660 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The operation of the second smart contract 670 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The operation of the third smart contract 680 according to an embodiment may be understood as the operation of a processor coupled to a computer network including a blockchain network. The computing device including a processor that executes the first smart contract 660, the computing device including a processor that executes the second smart contract 670, and the computing device including a processor that executes the third smart contract 680 may be the same or different from each other.

[0167] According to an embodiment, the product seller terminal 610 may transmit (S612) a public key corresponding to the private key to the second smart contract 670. The operation (S612) has been described in detail above with reference to Figures 6C and 6D, and therefore a detailed description with reference to the figures will be omitted.

[0168] According to an embodiment, the first smart contract 660 may receive a transaction from a terminal. The second smart contract 670 may verify the transaction. The third smart contract 680 may verify the zero-knowledge proof value of the unique number. The first smart contract 660 may also mint a non-fungible token based on the verification result.

[0169] The processor according to an embodiment may request verification from the second smart contract 670 (S661) by executing the first smart contract 660. The operation (S661) has been described in detail above with reference to Figures 6C and 6D, and therefore a detailed description thereof will be omitted.

[0170] According to an embodiment, the processor may verify (S671) the transaction by executing the second smart contract 670. If the transaction verification is successful (S673), the processor may make a request (S674) to verify the zero-knowledge proof value of the unique number to the third smart contract 680. The operation (S674) may include an operation of sending at least one of the zero-knowledge proof value of the unique number, a hash value of the unique number, or a verification key to the third smart contract 680.

[0171] The processor according to an embodiment may verify the zero-knowledge proof value of the unique number by executing the third smart contract 680 (S681). The verification of the zero-knowledge proof value of the unique number is the same as the operation (S654) of FIG. 6A and FIG. 6B, and a detailed description with reference to the figures will be omitted. If the verification of the zero-knowledge proof value of the unique number fails (S682), the processor may transmit a result message of the failure of the verification of the zero-knowledge proof value of the unique number to the first smart contract 660, the second smart contract 670, and / or the user terminal 630. If the verification of the zero-knowledge proof value of the unique number is successful (S683), the processor may transmit the verification result to the second smart contract 670 (S684). The verification result transmitted in the operation (S684) may include the successful verification of the zero-knowledge proof value of the unique number. The processor according to an embodiment may transmit the verification result to the first smart contract 660 (S675). The verification result sent in operation (S675) may include successful transaction verification and successful zero-knowledge proof value verification of the unique number.

[0172] Since operations (S667), (S668), and (S669) have been specifically described above as operations (S657), (S658), and (S659) in Figures 6A and 6B, detailed description with reference to the figures will be omitted. In other embodiments, at least a portion of operations (S667), (S668), and (S669) may be performed in the second smart contract 670 and / or the third smart contract 680, and the present invention is not limited thereto.

[0173] 6G and 6H may be embodiments in which smart contract 650 is divided into a first smart contract 660, a second smart contract 670, a third smart contract 680, and a fourth smart contract 690.

[0174] Operations S611, S612, S631, S621, S622, and S623 have been described in detail above with reference to Figures 6A and 6B, and therefore detailed description thereof will be omitted.

[0175] When the same user tags NFC multiple times from a third terminal or requests QR code generation multiple times, generating multiple unique numbers of arbitrary values, a problem may occur in which multiple non-fungible tokens are provided to one user. This is because one user can generate multiple digital asset wallets and use multiple unique numbers to mint non-fungible tokens for each digital asset wallet.

[0176] According to an embodiment, the first smart contract 660, the second smart contract 670, the third smart contract 680, and the fourth smart contract 690 may be embodied as one smart contract or at least two smart contracts. Figures 6G and 6H are merely examples, and the present disclosure is not limited thereto.

[0177] Therefore, in order to provide one non-fungible token to one user, the processor may mint a non-fungible token to one user by further using the user identification information. A method for minting a non-fungible token by further using the user identification information will be described in detail below.

[0178] According to one embodiment, the user terminal 630 may generate a zero-knowledge proof value of the unique number (S632). In another embodiment, the user terminal 630 may generate a zero-knowledge proof value of the unique number based on at least one of the unique number, a hash value of the unique number, a recipient address, or a proof key. In yet another example, the user terminal 630 may generate a zero-knowledge proof value of the unique number based on at least one of the unique number, a hash value of the unique number, a recipient address, user identification information, or a proof key. A detailed description of the operation (S632) has been given above in detail with reference to FIGS. 6A and 6B, and therefore a detailed description with reference to the same figures will be omitted.

[0179] The user terminal 630 according to an embodiment may generate a second Merkle root based on the user identification information (S633). The user identification information may include information for identifying one user from other users. The user identification information may be information that has passed an authentication procedure (e.g., KYC (Know Your Customer) authentication). User identification information that has not passed the authentication procedure cannot be used in minting non-fungible tokens. The user identification information may be user identification information authenticated by a government agency, a financial institution, etc. The user identification information may include, for example, a user name, a resident registration number, an address, a nationality, a contact, and, if the user is an organization, an organization's business type. As another example, the user identification information may include a user's digital asset wallet address. As yet another example, the user identification information may be a unique number (or a serial number) of the user terminal. The user terminal 630 may generate a second Merkle tree based on a value obtained by hashing the user identification information. For example, the user terminal 630 may generate a second Merkle tree based on a value obtained by hashing a plurality of user identification information. The user terminal 630 may obtain a second Merkle root from the second Merkle tree. The user terminal 630 can send the second Merkle root of the second Merkle tree to a smart contract (e.g., one of the first smart contract 660, the second smart contract 670, the third smart contract 680, or the fourth smart contract 690). When the second Merkle root is included in the smart contract, the second Merkle root is published on the blockchain network.

[0180] In one embodiment, when the user identification information is a digital asset wallet address of the user, the processor can generate a second Merkle tree for the digital asset wallet address, which may be a wallet address that has passed an authentication procedure of a specific institution, and the processor can obtain a second Merkle root and a second Merkle proof value based on the second Merkle tree.

[0181] According to an embodiment, the user terminal 630 may generate (S634) a transaction including at least one of a hash value of the unique number, a recipient address, signature data, a second Merkle proof value, or a zero-knowledge proof value of the unique number. The second Merkle proof value may be generated based on a second Merkle root. The second Merkle proof value may include at least a portion of nodes of the second Merkle tree. The second Merkle proof value may include only a minimum number of nodes required to reconstruct the second Merkle root.

[0182] Since the operations S635 and S661 have been described in detail above with reference to FIGS. 6E and 6F, detailed description thereof will be omitted.

[0183] The processor according to an embodiment may verify the transaction (S681) by executing the second smart contract 670. The transaction verification has been described in detail above with reference to Figures 6A and 6B, and therefore a detailed description with reference to the figures will be omitted.

[0184] The processor according to an embodiment may verify the user identity by executing the fourth smart contract 670 (S691). In an embodiment, the processor may obtain a Merkle root based on the hash value of the user identity and the second Merkle proof value. The processor may determine whether the Merkle root obtained based on the hash value of the user identity and the second Merkle proof value (hereinafter, Merkle root C) matches the second Merkle root (hereinafter, Merkle root D) stored in the smart contract (e.g., the fourth smart contract 690). If the obtained Merkle root (Merckle root C) matches the Merkle root (Merckle root D) stored in the smart contract, the processor may determine that the verification of the user identity is successful (S693). If the verification of the user identity is successful (S693), the processor may send the verification result of the user identity to the third smart contract 680 (S694). Conversely, the processor may determine that the verification of the user identity has failed (S692) if the acquired Merkle root (Merkle root C) does not match the Merkle root (Merkle root D) stored in the smart contract. In operation (S692), the processor may send a user identity verification failure result message to at least one of the user terminal 630, the first smart contract 660, the second smart contract 670, or the third smart contract 680. The method of verifying the user identity using a Merkle tree is merely an example, and the user identity may be verified by other verification methods, and the present invention is not limited thereto.

[0185] In another embodiment, the user terminal 630 can generate a zero-knowledge proof value for the user identity. The user terminal 630 can include the zero-knowledge proof value for the user identity in a transaction. In one embodiment, the processor can verify the zero-knowledge proof value for the user identity by executing the fourth smart contract 690. This allows the processor to verify that the prover's user terminal 630 knows the user identity without disclosing the user identity to the blockchain network.

[0186] In one embodiment, if the transaction verification is successful (S673), the processor may send a user identity verification request (S675) to the fourth smart contract 690. In another embodiment, the processor may verify the user identity (S691) regardless of the transaction verification result. In this case, the processor may send the user identity verification request to the fourth smart contract 690 by executing the first smart contract 660. In yet another example, if the unique number zero-knowledge proof value verification (S681) is successful (S683), the processor may send the user identity verification request to the fourth smart contract 690. Therefore, the user identity verification (S691) may be performed based on the transaction verification (S671) result and / or the unique number zero-knowledge proof value verification (S681) result, or may be performed independently regardless of the above results, and the present invention is not limited thereto.

[0187] The functionality of the fourth smart contract 690 according to an embodiment may be included in one of the third smart contract 680, the second smart contract 670, or the first smart contract 660. In this case, the processor may perform the user identity verification (S691) by executing one of the third smart contract 680, the second smart contract 670, or the first smart contract 660. Thus, the user identity verification (S691) may be embodied in the same smart contract as the transaction verification (S671) and / or the zero-knowledge proof value verification of the unique number (S683), or may be embodied in a different smart contract.

[0188] In an embodiment, if the verification of the zero-knowledge proof value of the unique number is successful (S683), the processor may send (S684) the verification result to the second smart contract 670. The verification result sent in operation (S684) may include at least one of successful verification of the zero-knowledge proof value of the unique number or successful verification of the user identity. In an embodiment, the processor may send (S676) the verification result to the first smart contract 660. The verification result sent in operation (S676) may include at least one of successful transaction verification, successful verification of the zero-knowledge proof value of the unique number, or successful verification of the user identity.

[0189] According to an embodiment, a processor may execute the first smart contract 660 to distribute non-fungible tokens to a blockchain network based on a transaction verification result, a verification result of the zero-knowledge proof value of the unique number, and a verification result of the user identification information. If the transaction verification is successful, the verification result of the zero-knowledge proof value of the unique number, and the verification result of the user identification information are successful, the processor may distribute the non-fungible tokens to the blockchain network.

[0190] Since operations (S667), (S668), and (S669) have been specifically described above as operations (S657), (S658), and (S659) in Figures 6A and 6B, detailed description with reference to the figures will be omitted. In other embodiments, at least a portion of operations (S667), (S668), and (S669) may be performed in the second smart contract 670, the third smart contract 680, and / or the fourth smart contract 690, and the present invention is not limited thereto.

[0191] As described above, the processor may issue one non-fungible token to one user by minting the non-fungible token further using the user identification information.

[0192] FIG. 7 is a diagram illustrating a method of minting non-fungible tokens via a device attached to a product according to one embodiment of the subject matter disclosed herein.

[0193] Ownership of a product can be transferred at any time. For example, when user A sells product A to user B, ownership of product A is transferred from user A to user B. When a user mints a non-fungible token for a product, ownership information of the non-fungible token for the product can be stored in the user's digital asset wallet. However, when a user does not mint a non-fungible token for the product, the ownership information of the product and the non-fungible token may be inconsistent. For example, when user A sells product A to user B, the ownership of product A belongs to user B. However, if user A or user B does not mint the non-fungible token associated with the ownership transfer, the ownership information of the non-fungible token may be retained by user A.

[0194] In addition, if a digital asset wallet that stores ownership information of a non-fungible token for a specific product is lost, it is difficult to recover the ownership of the non-fungible token. For example, if user A loses his / her digital asset wallet, user A owns product A, but cannot prove the ownership of the non-fungible token for product A in the blockchain network. Therefore, in this case, the owner of the product and the ownership information of the non-fungible token for the product may not match.

[0195] To match the ownership of an item with the ownership information of a non-fungible token for the item, a seller can attach an electronic device (e.g., an IC chip) to the item and deliver the item to a buyer, or deliver a card with an electronic device attached to it to the buyer along with the item.

[0196] Referring to Fig. 7, an electronic device 711 may be attached to a product B 710. A purchaser who purchases the product B 710 may communicate with the electronic device 711 using a user terminal 140. The user terminal 140 may receive data from the electronic device 711 and request (720) the blockchain network 130 to mint a non-fungible token for the product B 710. The minting method of Fig. 7 will be described in detail with reference to Figs. 8A and 8B.

[0197] 8A and 8B are flow charts illustrating methods of minting non-fungible tokens via a device attached to a merchandise, according to various embodiments of the subject matter disclosed herein.

[0198] According to an embodiment, the product seller terminal 810 can transmit the personal key to the device 820 attached to the product (S811). The device 820 attached to the product can store the personal key. The product seller terminal 810 can be a terminal of an organization or an individual who owns the product.

[0199] According to an embodiment, the product seller terminal 810 may transmit (S812) a public key corresponding to the private key to the second smart contract 870. The processor executes the second smart contract 870 and may verify the signature data signed with the private key using the public key included in the second smart contract 870. The verification using the public key will be described in detail later as an operation (S871).

[0200] In another embodiment, the product seller terminal 810 may send a Merkle root (e.g., a third Merkle root) of multiple public keys to the second smart contract 870 in operation (S812). The third Merkle root may be a root node of a third Merkle tree generated based on a hash value obtained by hashing multiple public keys. When the third Merkle root is included in the second smart contract 870, transaction verification may be performed using the third Merkle proof value in operation (S871). For example, the processor may obtain the Merkle root based on the public key of the signature data and the third Merkle proof value. The processor may determine whether the obtained Merkle root matches the third Merkle root included in the second smart contract 870, and perform transaction verification.

[0201] In one embodiment, operations S811 and S812 may be performed when the product is initially minted, and may be omitted if ownership information of a non-fungible token for the product exists in the blockchain network.

[0202] According to an embodiment, the user terminal 830 may be a terminal of a buyer of a product. The device 820 attached to the product communicates with the user terminal 830, so that the buyer who has purchased the product can include the non-fungible token for the product in the buyer's digital asset wallet at any time. A method for minting a non-fungible token will be described in detail below.

[0203] According to an embodiment, the user terminal 830 may request a first block number from the blockchain node 850 (S831). Then, the blockchain node 850 may transmit the first block number and a block hash value to the user terminal 830 (S851). The block hash value may be a hash value corresponding to the first block number.

[0204] According to an embodiment, the user terminal 830 may generate a unique number (S832). The unique number may be any value. For example, the unique number may be a nullifier.

[0205] According to an embodiment, the user terminal 830 can transmit the block hash value and the unique number to the device 820 attached to the product (S834). In an embodiment, the user terminal 830 can transmit the block hash value and the unique number to the device 820 by contactless communication. For example, the user terminal can transmit an APDU (Application Protocol Data Unit) to the device 820. The APDU may be a data unit used when an IC chip and another electronic device exchange data. The user terminal 830 can transmit the APDU including the block hash value and the unique number to the device 820.

[0206] The device 820 according to one embodiment may generate signature data by signing the block hash value and the unique number with a private key (S821). For example, the device 820 may generate signature data by signing a (block hash value, unique number) value with a private key. The private key may be a key stored in the device 820. The device 820 according to one embodiment may generate a first hash value by hashing a value including the block hash value and the unique number. In another embodiment, the device 820 may generate signature data by signing the first hash value with a private key.

[0207] According to an embodiment, the device 820 may transmit the signature data to the user terminal 830 (S822). Then, the device 820 may transmit the first hash value to the user terminal 830 together with the signature data.

[0208] According to an embodiment, the user terminal 830 may generate a zero-knowledge proof value of the unique number (S834) based on the block hash value and the unique number. The user terminal 830 may receive a first hash value obtained by hashing a value including the block hash value and the unique number from the device 820. In an embodiment, the user terminal 830 may generate a zero-knowledge proof value of the unique number based on at least one of the block hash value, the unique number, the first hash value, or the proof key. In another embodiment, the user terminal 830 may generate a zero-knowledge proof value of the unique number based on at least one of the block hash value, the unique number, the first hash value, the recipient address, or the proof key.

[0209] According to an embodiment, the user terminal 830 may generate a transaction including at least one of a first hash value, a hash value of the unique number, a block number, a recipient address, signature data, or a zero-knowledge proof value of the unique number. The user terminal 830 may send the generated transaction to the first smart contract 860 (S835). The generated transaction may be a transaction requesting minting of a non-fungible token corresponding to a product. Since the unique number is not included in the transaction, the unique number is not made public on the blockchain network.

[0210] The operations of the first smart contract 860, the second smart contract 870, and the third smart contract 880 according to an embodiment may be understood as operations of a processor coupled to a computer network including a blockchain network, and the operations of the smart contracts 860, 870, and 880 may be operations performed by the processor executing the smart contracts.

[0211] According to an embodiment, the first smart contract 860 may transmit a transaction verification request (S861) to the second smart contract 870 in response to receiving the transaction. The processor may verify the transaction (S871) by executing the second smart contract 870. Specifically, the processor may verify the signature data included in the transaction. In an embodiment, if a public key is stored in the second smart contract 870, the processor may determine whether the public key of the signature data matches the public key stored in the second smart contract 870. The verification of the signature data based on the public key has been described in detail above with reference to FIG. 6A and FIG. 6B, and therefore a detailed description thereof is omitted in the figures. In another embodiment, if a third Merkle root is stored in the second smart contract 870, the processor may verify the transaction by comparing whether the Merkle root obtained based on the public key of the signature data and the third Merkle proof value matches the third Merkle root stored in the second smart contract 870. In this case, the transaction may further include a third Merkle proof value.

[0212] The operation (S872) according to one embodiment has been specifically described above as the operation (S672) in FIG. 6E and FIG. 6F, and therefore a detailed description thereof will be omitted in the figures.

[0213] In one embodiment, when the transaction verification is successful (S873), the processor can determine whether the difference between the second block number and the first block number is equal to or less than a reference value (S874). For example, after user A transfers ownership of product B710 to user B, user A may scan a device attached to product B710, and the terminal of user A may obtain information required for minting before the terminal of user B. As a result, although product B710 is transferred to user B, the ownership of the non-fungible token for product B710 may belong to user A. Therefore, the processor can prevent the previous owner from attributing the ownership of the non-fungible token for the product to the previous owner instead of the new owner by determining whether a minting request is made within the valid time after the unique number is generated.

[0214] The processor according to an embodiment may determine the passage of time by determining whether the difference between the second block number and the first block number is equal to or less than a reference value. The processor may obtain the second block number by requesting the block number from the blockchain node 850. The reference value may be a block number calculated based on the passage of time from the first block number. The first block number may be a block number that the user terminal 830 requests and receives from the blockchain node 850. The first block number may represent the time when the user terminal 830 generates a unique number. This is because blocks are continuously generated in a certain time unit, and the block number increases by a certain amount every certain time unit. Therefore, there is a correlation between time and the block number. For example, if 100 blocks are generated every second, and the first block number is 500 and the second block number is 1000, there may be a time interval of 5 seconds between the time when the first block number is generated and the time when the second block number is generated. The reference value may be determined based on the first block number. There is a difference of a certain number of blocks between the reference value and the first block number. For example, if the first block number is 500, the reference value may be 1000. Therefore, if the second block number is 1000 or less, the processor can determine that it is within the minting request validity time. The processor can determine that it is within the minting request validity time when it determines whether the block number is equal to or less than the reference value within a certain time from the time when the user terminal requests the block number (S831). If the certain time has passed, the minting request validity time has passed, so the processor can reject the minting request. This allows the processor to prevent ownership of the non-fungible token from being attributed to the previous owner rather than the new owner. If the difference between the second block number and the first block number is equal to or more than the reference value, the minting request validity time may have passed. In this case, the processor can send a message including a minting request validity time has passed (S875) to the user terminal 830.

[0215] If it is within the minting request validity time according to an embodiment (S876), the processor may request a block hash value corresponding to the second block number from the blockchain node 850 (S877). Then, the blockchain node 850 may send the block hash value corresponding to the second block number to the second smart contract 870 (S852).

[0216] If it is within the minting request validity time according to an embodiment (S876), the processor may send a zero-knowledge proof value verification request for the unique number (S878) to the third smart contract 880. The processor may verify the zero-knowledge proof value of the unique number (S881) by executing the third smart contract 880. The processor may perform a verification algorithm based on at least one of the zero-knowledge proof value of the unique number, the block hash value corresponding to the first block number, the second hash value which is the hash value of the unique number, or the verification key. If the result of the verification algorithm is true, the processor may determine that the user terminal 830 of the prover knows the unique number. In this case, the unique number zero-knowledge proof value verification may be successful (S883). Conversely, if the result of the verification algorithm is false, the processor may determine that the user terminal 830 of the prover does not know the unique number. In an operation (S882), the processor may send a result message of failure to verify the zero-knowledge proof value of the unique number to the user terminal 830.

[0217] In one embodiment, if the zero-knowledge proof value of the unique number is successfully verified (S883), the processor may send the verification result to the second smart contract 870. The processor may invalidate the hash value of the unique number (S889). The operation (S889) may also be embodied in the first smart contract 860 or the third smart contract 880, and the present invention is not limited thereto.

[0218] In one embodiment, the processor can send a verification result to the first smart contract 860. This may include successful transaction verification, a result that the difference between the second block number and the first block number is less than or equal to a threshold value, and successful zero-knowledge proof value verification of the unique number.

[0219] In one embodiment, the processor may mint (S868) an NFT of the product to the recipient address in response to the above-mentioned verification result. In one embodiment, when ownership information of the non-fungible token for the product is not stored in an existing blockchain network, new ownership information of the non-fungible token for the product may be generated. In another embodiment, when ownership information of the non-fungible token for the product exists in the blockchain network and ownership is transferred to another user, the ownership information stored in the block may be updated. As yet another example, when ownership is transferred to another user, the existing ownership information stored in the block may be deleted, and ownership information for the non-fungible token may be generated in a new block.

[0220] In one embodiment, the processor may perform operation (S869) when the non-fungible token for the product is not distributed to the blockchain network. Conversely, when the non-fungible token for the product is distributed to the blockchain network, the processor may omit operation (S869).

[0221] FIG. 9 is a flow chart of a method for minting non-fungible tokens according to one embodiment of the subject matter disclosed herein.

[0222] According to an embodiment, the electronic device 200 may receive (910) a transaction requesting minting of a non-fungible token corresponding to the product from a first terminal that has received a unique number for the product.

[0223] In accordance with an embodiment, the electronic device 200 may execute (920) a smart contract in response to receiving the transaction.

[0224] In one embodiment, the electronic device 200 can execute a smart contract to verify a transaction including a zero-knowledge proof value of a unique number corresponding to a unique number for an item.

[0225] In one embodiment, the electronic device 200 can verify the zero-knowledge proof value of the unique number by executing a smart contract.

[0226] In one embodiment, the electronic device 200 can distribute non-fungible tokens to a blockchain network based on the verification result of the zero-knowledge proof value of the unique number by executing a smart contract.

[0227] FIG. 10 is a flow chart illustrating the operation of a user terminal according to one embodiment of the subject matter disclosed herein.

[0228] In response to receiving the unique number for the product, the electronic device 200 according to an embodiment may generate (1010) a zero-knowledge proof value of the unique number corresponding to the unique number for the product.

[0229] According to an embodiment, the electronic device 200 may send (1020) a transaction to the smart contract, the transaction including at least one of a hash value of the unique number, a recipient address, or a zero-knowledge proof value of the unique number. The action of "sending a transaction to a smart contract" may mean that the electronic device 200 sends the transaction to an electronic device that executes the smart contract.

[0230] According to an embodiment, the electronic device 200 may receive (1030) a minting result of the non-fungible token based on the verification result of the zero-knowledge proof value of the unique number obtained when the smart contract that received the transaction is executed.

[0231] The smart contract according to an embodiment may return a minting result of the non-fungible token by verifying the zero-knowledge proof value of the unique number based on at least one of the zero-knowledge proof value of the unique number, the hash value of the unique number, or the proof key stored in the smart contract. The above-mentioned operation of the smart contract may be an operation performed by a processor connected to a computer network including a blockchain network executing the smart contract.

[0232] FIG. 11 is a flow chart illustrating the operation of a user terminal according to another embodiment of the subject matter disclosed herein.

[0233] The electronic device 200 according to one embodiment may request a block number and a block hash value from a computer network including a blockchain network, and may receive (1110) a first block number and a block hash value corresponding to the first block number.

[0234] According to one embodiment, the electronic device 200 may generate 1120 a unique number that may be any value.

[0235] According to an embodiment, the electronic device 200 may transmit (1130) the block hash value and the unique number to a device attached to the product.

[0236] According to an embodiment, the electronic device 200 may receive (1140) signature data obtained by signing a first hash value obtained by hashing a value including the block hash value and the unique number with a private key from the device.

[0237] According to an embodiment, the electronic device 200 may generate (1150) a zero-knowledge proof value of the unique number based on the first hash value.

[0238] In one embodiment, the electronic device 200 may send (1160) a transaction to a computer network, including a blockchain network, requesting minting of a non-fungible token for the commodity.

[0239] In the flow charts according to the disclosure herein, the steps of a method or algorithm are described in a sequential order, but the steps may be performed in any combinable order, in addition to being performed sequentially. The description of a sequence or flow chart herein does not preclude variations or modifications to the method or algorithm, and does not imply that any step is essential or preferred. In an embodiment, at least some steps may be performed in parallel, iteratively, or heuristically. In an embodiment, at least some steps may be omitted and other steps may be added.

[0240] Various embodiments according to the disclosure herein may be embodied as software in a machine-readable storage medium. The software may be software for implementing various embodiments described herein. The software may be deducible from various embodiments described herein by a programmer skilled in the art to which the disclosure herein pertains. For example, the software may be a program including machine-readable instructions (e.g., code or code segments). The device may be a device that can be operated by instructions retrieved from a storage medium, such as a computer. In one embodiment, the device may be a computing device according to various embodiments described herein. In one embodiment, a processor of the device may execute the retrieved instructions and cause components of the device to perform functions corresponding to the instructions. The storage medium may refer to any type of recording medium on which data is stored that is readable by the device. The storage medium may include, for example, a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like. In one embodiment, the storage medium may be embodied in a distributed form in computer systems connected by a network. Software may be stored and executed in a distributed manner in computer systems. The storage medium may be a non-transitory storage medium. A non-transitory storage medium refers to a tangible medium in which data is stored semi-permanently or temporarily, and does not include a signal that is transmitted transitorily.

[0241] Although the technical idea according to the contents disclosed in this specification has been described above by using various embodiments, the technical idea according to the contents disclosed in this specification includes various substitutions, modifications, and changes that can be made within the scope that can be understood by a person having ordinary knowledge in the technical field to which the contents disclosed in this specification belong. In addition, such substitutions, modifications, and changes should be understood to be included in the scope of the attached claims.

Claims

1. A processor connected to a computer network including a blockchain network receives a transaction requesting minting of a non-fungible token corresponding to the product from a first terminal that has received a unique number for the product; and executing a smart contract by the processor in response to receiving the transaction, The step of executing the smart contract comprises: verifying the transaction including a zero-knowledge proof value of a unique number corresponding to the unique number for the item; verifying a zero-knowledge proof value of the unique number; Distributing the non-fungible token to the blockchain network based on a verification result of the zero-knowledge proof value of the unique number. method.

2. The unique number for the product is received by at least one of a message, a Near Field Communication (NFC), or a Quick Response (QR) code; The method of claim 1.

3. The zero-knowledge proof value of the unique number is generated based on at least one of the unique number, a hash value of the unique number, or a proving key; The certification key is generated in pairs with a verifying key based on a hash value of the unique number. The method of claim 1.

4. The transaction further includes a hash value of the unique number; The step of verifying the zero-knowledge proof value of the unique number includes: If the verification of the transaction is successful, performing a verification algorithm based on at least one of a zero-knowledge proof value of the unique number, a hash value of the unique number, or a verification key; The method of claim 1.

5. The transaction further includes a hash value of the unique number; Prior to distributing the non-fungible tokens on a blockchain network, The method further includes invalidating a hash value of the unique number to prevent duplicate issuance of non-fungible tokens for the unique number. The method of claim 1.

6. The transaction further includes a recipient address; Distributing the non-fungible tokens on the blockchain network includes: minting the non-fungible token to the recipient address if the zero-knowledge proof value of the unique number is successfully verified. The method of claim 1.

7. The smart contract: A first Merkle root of a first Merkle tree obtained by hashing a plurality of unique numbers generated by a second terminal of a company selling a product; The method of claim 1.

8. The transaction further includes a hash value of the unique number; Validating the transaction includes: Verifying a hash value of the unique number based on a first Merkle proof value included in the smart contract; The method of claim 1.

9. The smart contract: a third terminal that transmits the unique number of the product to the first terminal by at least one of NFC or QR code, and a public key that is symmetrical to a private key stored in the third terminal; The method of claim 1.

10. The unique number is a random value generated by the third terminal, The transaction is The unique number is further included in the hash value of the unique number, and signature data obtained by signing the unique number with the private key.

10. The method of claim 9.

11. Validating the transaction includes: verifying signature data with a public key stored in said transaction; 10. The method of claim 9.

12. The smart contract: The second Merkle root of the second Merkle tree is obtained by hashing the user identification information of the first terminal, The transaction is The unique number is a hash value, signature data obtained by signing the unique number with the private key, and a second Merkle proof value based on the second Merkle tree.

10. The method of claim 9.

13. The step of validating the transaction comprises: verifying the signature data with a public key stored in the transaction; and verifying the user identity based on a second Merkle root and evidence for the user identity of the first terminal. The method of claim 12.

14. When the smart contract includes a first smart contract that receives the transaction and a second smart contract that verifies the transaction and verifies the zero-knowledge proof value of the unique number, executing the smart contract includes: The processor executes a first smart contract to request validation of the transaction from the second smart contract; and in response to a request to verify the transaction, the processor executes the second smart contract; The step of executing the second smart contract includes: validating the transaction; and verifying a zero-knowledge proof value of the unique number based on a verification result of the transaction. The method of claim 1.

15. Distributing the non-fungible tokens on the blockchain network includes: The processor executes the first smart contract to distribute the non-fungible token to the blockchain network based on a verification result of the zero-knowledge proof value of the unique number. The method of claim 14.

16. When the smart contract includes a first smart contract that receives the transaction, a second smart contract that verifies the transaction, and a third smart contract that verifies a zero-knowledge proof value of the unique number, executing the smart contract includes: The processor executes a first smart contract to request validation of the transaction from the second smart contract; The processor executes the second smart contract to verify the transaction, and requests the third smart contract to verify a zero-knowledge proof value of the unique number based on a result of the transaction verification; The processor executes the third smart contract to verify the zero-knowledge proof value of the unique number and transmits the verification result to a second smart contract. The method of claim 1.

17. Distributing the non-fungible tokens on the blockchain network includes: The processor executes the first smart contract to distribute the non-fungible token to the blockchain network based on a verification result of the zero-knowledge proof value of the unique number.

17. The method of claim 16.

18. When the smart contract includes a first smart contract that receives the transaction, a second smart contract that verifies the transaction, a third smart contract that verifies a zero-knowledge proof value of the unique number, and a fourth smart contract that verifies user identification information of the first terminal, the step of executing the smart contract includes: The processor executes a first smart contract to request validation of the transaction from the second smart contract; The processor verifies the transaction by executing the second smart contract, and requests the third smart contract to verify the zero-knowledge proof value of the unique number based on a result of the transaction verification, and requests the fourth smart contract to verify the user identification information; The processor executes the third smart contract to verify a hash value of the unique number and transmits the verification result to a second smart contract; The processor executes the fourth smart contract to verify the user identity based on a second Merkle root included in the fourth smart contract and a proof for the user identity of the first terminal. The method of claim 1.

19. Distributing the non-fungible tokens on the blockchain network includes: The processor executes the first smart contract to distribute the non-fungible token to the blockchain network based on a verification result of the zero-knowledge proof value of the unique number and a verification result of the user identification information. The method of claim 18

20. A processor included in a user terminal connected to a computer network including a blockchain network, In response to receiving a unique number for a product, generating a zero-knowledge proof value of the unique number corresponding to the unique number for the product; Sending a transaction to a smart contract, the transaction including at least one of a hash value of the unique number, a recipient address, or a zero-knowledge proof value of the unique number; The processor receives a minting result of the non-fungible token based on a verification result of the zero-knowledge proof value of the unique number obtained by executing a smart contract that received the transaction. method.

21. The smart contract returns a minting result of the non-fungible token by verifying the zero-knowledge proof value of the unique number based on at least one of a zero-knowledge proof value of the unique number, a hash value of the unique number, or a proof key stored in the smart contract.

21. The method of claim 20.

22. A processor connected to a computer network including a block chain network receives a transaction requesting minting of a non-fungible token for the product from a first terminal that has received signature data for the product through a device attached to the product; and executing a smart contract in response to the received transaction, the processor comprising: The step of executing the smart contract comprises: verifying the transaction including at least one of the signature data, a first hash value obtained by hashing a value including a block hash value corresponding to a first block number and a unique number, a hash value of the unique number, the first block number, a recipient address, or a zero-knowledge proof value of the unique number; and verifying a zero-knowledge proof value of the unique number based on a result of verifying the signature data and a result of comparing the first block number with the second block number. method.

23. the signature data is data obtained by signing the first hash value and a unique number with a private key, The step of validating the transaction comprises: verifying the signature data based on a public key corresponding to the private key; determining whether a difference between the second block number and the first block number is equal to or less than a reference value; The method of claim 22.

24. The step of verifying the zero-knowledge proof value of the unique number includes: receiving a block hash value corresponding to the block number from the computer network including the blockchain network; and verifying the zero-knowledge proof value of the unique number based on the block hash value, the recipient address, the hash value of the unique number, and the zero-knowledge proof value of the unique number.

23. The method of claim 22.

25. invalidating the second hash value to prevent duplicate issuance of non-fungible tokens for the product; distributing the non-fungible tokens on the blockchain network; 23. The method of claim 22.

26. The smart contract: a public key corresponding to a private key stored on a device attached to the item; 23. The method of claim 22.

27. A processor included in the first terminal, Requesting a block number and a block hash value from a computer network including a blockchain network and receiving a first block number and a block hash value corresponding to the first block number; generating a unique number, which is an arbitrary value; transmitting the block hash value and the unique number to a device attached to the product; receiving, from the device, signature data obtained by hashing a first hash value obtained by hashing a value including the block hash value and the unique number, and signing the first hash value with a private key; generating a zero-knowledge proof value of a unique number based on the first hash value; sending a transaction to the computer network, including the blockchain network, requesting upload of a non-fungible token for the product; method.

Images