Method and apparatus for minting non-fungible tokens onto a blockchain

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 content disclosed in this specification relates to a technology for uploading non-fungible tokens to a blockchain.

Background Art

[0002] With the emergence of the Ethereum blockchain among blockchain technologies, the concept of digital ownership based on non-fungible tokens has emerged. Non-fungible tokens have gained high popularity in the digital market because they represent verifiable ownership of specific items.

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

[0004] The process of issuing non-fungible tokens includes generating tokens unique to the blockchain and recording ownership information. Since ownership information is also recorded while issuing non-fungible tokens, the demand for receiving the issuance of non-fungible tokens for physical goods and holding verifiable ownership may increase.

Summary of the Invention

Problems to be Solved by the Invention

[0005] At least a part of the content disclosed in this specification provides a technology for minting non-fungible tokens for goods.

[0006] At least a part of the content disclosed in this specification provides a minting technology that does not disclose the unique number of goods in a blockchain network.

[0007] At least a part of the content disclosed in this specification provides a minting technology with enhanced security even in a situation where there is no relayer for transmitting transactions.

[0008] At least a portion of what is disclosed herein provides a technology that can align ownership of goods with ownership of non-fungible tokens for those goods.

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

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

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

[0012] In one embodiment, the unique number for a product may be received by at least one of the following: a message, NFC (Near Field Communication), or a QR (Quick Response) 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, the hash value of the unique number, or a proving key, and the proving key may be generated in pairs 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 of the unique number may include, if the transaction verification is successful, a step of performing a verification algorithm based on at least one of the zero-knowledge proof 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 a step of invalidating the hash value of the unique number in order to prevent double-dipping of the unique number with the unique number, prior to the step of distributing the non-fungible tokens to the blockchain network.

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

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

[0018] In one embodiment, the transaction further includes a hash value of a unique number, and the step of verifying the transaction may include a step of verifying the hash value of the unique number based on a 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 personal key stored in a third terminal that transmits a unique number for the product to a first terminal via at least one of NFC or QR code (registered trademark).

[0020] In one embodiment, the unique number is an arbitrary value (Random Value) generated by the third terminal, and the transaction may further include the hash value of the unique number and signed data obtained by signing the hash value of the unique number with a personal key.

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

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

[0023] In one embodiment, the step of verifying a transaction may include verifying the signature data with the public key stored in the transaction, and verifying the user identification information based on evidence of the second Merkle root and the first terminal's user identification information.

[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 includes: the processor requests the second smart contract to verify the transaction by executing the first smart contract; and the processor executes the second smart contract in response to the verification request for the transaction. The step of executing the second smart contract may include: verifying the transaction; and verifying the zero-knowledge proof value of the unique number based on the verification result of the transaction.

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

[0026] In one embodiment, when the smart contract includes a first smart contract that receives a transaction, a second smart contract that verifies the transaction, and a third smart contract that verifies the zero-knowledge proof value of the unique number, the step of executing the smart contract includes: the processor requests the second smart contract to verify the transaction by executing the first smart contract; the processor executes the second smart contract to verify the transaction and requests the third smart contract to verify the zero-knowledge proof value of the unique number based on the transaction verification result; and the processor executes the third smart contract to verify the zero-knowledge proof value of the unique number and sends the verification result to the second smart contract.

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

[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 a zero-knowledge proof value of a unique number, and a fourth smart contract for verifying user identification information of the first terminal, the step of executing the smart contract includes: the processor requests the second smart contract to verify the transaction by executing the first smart contract; the processor verifies the transaction by executing the second smart contract, requests the third smart contract to verify the zero-knowledge proof value of the unique number based on the transaction verification result, and requests the fourth smart contract to verify the user identification information; the processor verifies the hash value of the unique number by executing the third smart contract and sends the verification result to the second smart contract; and the processor verifies the user identification information based on the second Merkle root included in the fourth smart contract and the evidence for the user identification information of the first terminal by executing the fourth smart contract.

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

[0030] Other embodiments of the contents disclosed herein may include the steps of: 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 of the unique number corresponding to the unique number for the product; sending a transaction including at least one of the hash value of the unique number, a recipient address, or a zero-knowledge proof of the unique number to a smart contract; and the processor receiving the minting result of a non-fungible token based on the verification result of the zero-knowledge proof of the unique number obtained when the smart contract that received the transaction is executed.

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

[0032] Methods relating to other embodiments of the contents disclosed herein include the steps of: a processor connected to a computer network including a blockchain network receiving a transaction requesting the minting of non-fungible tokens for a product from a first terminal that has received signature data for the product via a device attached to the product; and the processor executing a smart contract in response to the received transaction, wherein the step of executing the smart contract includes verifying a transaction that includes at least one of the following: 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, a first block number, a recipient address, or a zero-knowledge proof of the unique number; and verifying the zero-knowledge proof of the unique number based on the verification result of the signature data and the comparison result of the first block number and the second block number.

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

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

[0035] In one embodiment, the method may further include the steps of invalidating a second hash value to prevent the double distribution of non-fungible tokens for a product, and distributing the non-fungible tokens to a blockchain network.

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

[0037] Other embodiments of the contents disclosed herein may include the steps of: a processor included in a 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 signature data from the device, in which the first hash value obtained by hashing a value including the block hash value and the unique number is signed with a personal key; generating a zero-knowledge proof value of the unique number based on the first hash value; and transmitting a transaction requesting the upload of a non-fungible token to the product to the computer network including a blockchain network. [Effects of the Invention]

[0038] According to at least one embodiment disclosed herein, the owner of a product can prove ownership of a non-fungible token in relation to the product.

[0039] According to at least one embodiment disclosed herein, a zero-knowledge proof of the product's unique identification number is used, eliminating the need to expose the product's unique identification number to a blockchain network.

[0040] According to at least one embodiment disclosed herein, the double issuance of non-fungible tokens for a single unique number can be prevented by invalidating the hash value of the unique number.

[0041] According to at least one embodiment disclosed herein, a third-party front-running attack by changing the recipient address can be prevented by making the zero-knowledge proof value of the unique number dependent on the recipient address.

[0042] According to at least one embodiment disclosed herein, by creating multiple smart contracts and dividing a series of operations associated with minting, smart contracts can be used flexibly in accordance with changes in minting tolerance conditions.

[0043] According to at least one embodiment disclosed herein, it is possible to prevent a single user from owning multiple non-fungible tokens using multiple digital asset wallets by further using user identification information to determine whether minting is permissible.

[0044] The effects of the technical ideas disclosed herein are not limited to those mentioned above, and other effects not mentioned will be clearly understood by a person of the ordinary skill from the description of the specification. [Brief explanation of the drawing]

[0045] [Figure 1] This section shows an environment in which an apparatus relating to one embodiment of the contents disclosed herein may be applied. [Figure 2] This specification shows a computing device that can embody any one of the devices relating to one embodiment of the contents disclosed herein. [Figure 3] This figure illustrates a method for minting non-fungible tokens of physical goods according to one embodiment of the contents disclosed herein. [Figure 4A] This flowchart illustrates a method for minting non-fungible tokens of physical goods relating to various embodiments of the contents disclosed herein. [Figure 4B] This flowchart illustrates a method for minting non-fungible tokens of physical goods relating to various embodiments of the contents disclosed herein. [Figure 4C] This flowchart illustrates a method for minting non-fungible tokens of physical goods relating to various embodiments of the contents disclosed herein. [Figure 4D] This flowchart illustrates a method for minting non-fungible tokens of physical goods relating to various embodiments of the contents disclosed herein. [Figure 4E] This flowchart illustrates a method for minting non-fungible tokens of physical goods relating to various embodiments of the contents disclosed herein. [Figure 4F] This flowchart illustrates a method for minting non-fungible tokens of physical goods relating to various embodiments of the contents disclosed herein. [Figure 5] This figure illustrates a method for minting a non-fungible token via a third terminal according to one embodiment of the contents disclosed herein. [Figure 6A] This flowchart illustrates a method for minting non-fungible tokens via a third terminal relating to various embodiments of the contents disclosed herein. [Figure 6B] This flowchart illustrates a method for minting non-fungible tokens via a third terminal relating to various embodiments of the contents disclosed herein. [Figure 6C]This flowchart illustrates a method for minting non-fungible tokens via a third terminal relating to various embodiments of the contents disclosed herein. [Figure 6D] This flowchart illustrates a method for minting non-fungible tokens via a third terminal relating to various embodiments of the contents disclosed herein. [Figure 6E] This flowchart illustrates a method for minting non-fungible tokens via a third terminal relating to various embodiments of the contents disclosed herein. [Figure 6F] This flowchart illustrates a method for minting non-fungible tokens via a third terminal relating to various embodiments of the contents disclosed herein. [Figure 6G] This flowchart illustrates a method for minting non-fungible tokens via a third terminal relating to various embodiments of the contents disclosed herein. [Figure 6H] This flowchart illustrates a method for minting non-fungible tokens via a third terminal relating to various embodiments of the contents disclosed herein. [Figure 7] This figure illustrates a method for minting non-fungible tokens via a device attached to a product according to one embodiment of the contents disclosed herein. [Figure 8A] This flowchart illustrates a method for minting non-fungible tokens via a device attached to a product relating to various embodiments of the contents disclosed herein. [Figure 8B] This flowchart illustrates a method for minting non-fungible tokens via a device attached to a product relating to various embodiments of the contents disclosed herein. [Figure 9] This flowchart shows a method for minting non-fungible tokens according to one embodiment of what is disclosed herein. [Figure 10] This flowchart illustrates the operation of a user terminal according to one embodiment of the contents disclosed herein. [Figure 11] This flowchart illustrates the operation of a user terminal by other embodiments of the content disclosed herein. [Modes for carrying out the invention]

[0046] The various embodiments disclosed herein are provided as examples to clearly illustrate the technical concept of this document and are not intended to limit it to any particular embodiment. The technical concept of this document includes various modifications, equivalents, alternatives, and embodiments selectively combined from all or part of each embodiment disclosed herein. Furthermore, the scope of rights to the technical concept of this document is not limited to the various embodiments or specific descriptions thereof presented below.

[0047] Unless otherwise defined, terms used in this document, including technical or scientific terms, may have meanings that are generally understood by a person with ordinary skill in the art to which the disclosed content pertains.

[0048] Expressions such as "includes," "may include," "equip," "may equip," "possess," and "may possess" used in this document mean that the feature in question (e.g., function, operation, or component) may exist, but do not exclude the existence of other further features. In other words, such expressions should be understood as open-ended terms that imply the possibility of including other embodiments.

[0049] In this document, singular expressions may also have plural meanings unless otherwise specified in the context, and this applies equally to singular expressions in claims.

[0050] In this document, expressions such as "first," "second," or "1st," "2nd," etc., are used to distinguish one object from others when referring to multiple objects of the same kind, unless otherwise specified in the context. They do not limit the order or importance of the objects.

[0051] Expressions used in this document 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 of the listed items or 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) at least one A and at least one B.

[0052] The expression "based on" as used in this document is used to describe one or more factors that influence an act or action of decision, judgment, or action described in the phrase or sentence containing this expression, and this expression does not exclude any further factors that influence such act or action of decision, judgment, or action.

[0053] The expression used in this document that one component (e.g., the first component) is "linked" or "connected" to another component (e.g., the second component) can mean not only that one component is directly linked or connected to another component, but also that it is linked or connected through yet another component (e.g., the third component).

[0054] The expression "configured to" used in this document may mean, depending on the context, "set to do," "capable of doing," "modified to do," "made to do," or "capable of doing." This expression is not limited to meaning "specifically designed in hardware." For example, a processor configured to perform a specific operation can mean a generic-purpose processor that can perform that specific operation by running software, or a special-purpose computer that is programmed to perform that specific operation.

[0055] The term "Non-Fungible Token (NFT)" as used in this document refers to a collection of electronic information that has been assigned a unique identifier to a digital asset based on blockchain technology. Specifically, non-fungible tokens may be generated by smart contracts created by referring to certain conventions (e.g., ERC-721 or ERC-1155). The integrity of these non-fungible tokens may be maintained by being recorded on a blockchain, which is a decentralized storage, and the existence of certain types of data can be guaranteed by generating these non-fungible tokens to contain specific types of data.

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

[0057] In one embodiment, metadata for a non-fungible token can mean a collection of information containing various information about that token. The metadata may include, for example, 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 on which the token is recorded, the time of creation of the token, or the history of changes in the ownership of the token. Hereafter, in this document, expressions such as "information contained in a non-fungible token" should be understood as "information contained in (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 (Virtual Machine) executed by one or more nodes included in a blockchain network. A smart contract may be constructed to conform to certain rules (or protocols). For example, a smart contract may be constructed to include one or more functions corresponding to each protocol, such as ERC-20, ERC-721, or ERC-1155. However, various smart contracts may be constructed by including other functions not included in the exemplified protocols.

[0059] As used in this document, the term "blockchain network" may include one or more nodes that manage the blockchain. A block may refer to a specific type of data. A blockchain may refer to a data structure in which one or more blocks are linked together in a chain. One or more blocks included in a blockchain may be stored independently on multiple nodes included in the blockchain network, or they may be stored in a distributed manner across multiple nodes. Each of the one or more blocks may include a block hash value, a block header, or a block body. A block hash value is unique information that identifies a block and may be, for example, a string represented by 256 bits. A block header may include at least one of the following: software or protocol version information, hash values ​​of previous blocks based on the block linking order on the blockchain, a Merkle root, time information indicating the time the block was generated, bits indicating the difficulty of the calculation, or a nonce, which is a value required in the mining process to add a new block to the blockchain. A block body may include at least one transaction. A transaction is a collection of data having a specific data structure, and may be a unit of information stored in a block body. A transaction may contain information about token creation or trading.

[0060] As used in this document, the term "digital asset" can refer to any information that is represented in binary and usable as an asset. Digital assets may include, for example, text, 2D images, 3D images, videos, or polygon graphics. More specifically, digital assets may include text, 2D images, 3D images, videos, or polygon graphics for items such as clothing, bags, accessories, furniture, vehicles, buildings, real estate, game items, or digital cards. The authenticity of such digital assets may be guaranteed by non-fungible tokens corresponding to the digital assets.

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

[0062] As used in this document, the term "platform" can mean an environment that serves as a user base by integrating and managing services for the same or similar purposes. This environment may be provided to the user by software (e.g., computer programs or applications) running on hardware (e.g., servers, clients, input devices, output devices, or network devices). Although there may be subtle differences in meaning, "platform" may be used interchangeably with "software," "application," or "solution." In one embodiment, a spatial platform may be an environment that integrates various services related to space. For example, a spatial platform may provide users with community services, game services, e-commerce services, video conferencing services, music listening services, or advertising services. In another embodiment, a non-fungible token platform may be an environment that integrates various services related to non-fungible tokens. For example, a non-fungible token platform may provide users with services related to trading non-fungible tokens, or community services based on non-fungible tokens.

[0063] The term "minting" as used in this document may refer to the minting of non-fungible tokens. Minting of non-fungible tokens is the process of generating unique digital assets on a blockchain network. Below is an example of a process in which a user requests minting of an asset and trades in non-fungible tokens that are issued. 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) A digital asset wallet compatible with the blockchain platform may be required. Non-fungible tokens can be stored and managed using a digital asset wallet. (3) Next, an asset (e.g., a physical asset or a digital asset) to be converted into a non-fungible token is required. For example, the asset may be a physical product, a work of art, music or video in digital form, a collectible, virtual real estate, etc. (4) The user can choose a marketplace (e.g., OpenSea, Rare, SuperRare) to sell the non-fungible tokens. (5) Once a marketplace is selected, non-fungible tokens sold on that marketplace can be received in the digital asset wallet. In one embodiment, when a user purchases non-fungible tokens from a marketplace, the non-fungible tokens can be received in the user's digital asset wallet. In another embodiment, when a user purchases non-fungible tokens from a marketplace, the non-fungible tokens are sent to a first digital asset wallet generated and managed by the marketplace, but the non-fungible tokens can later be received from the first digital asset wallet in the user's second digital asset wallet. (6) The non-fungible token minting process may need to follow specific guidelines provided by the selected marketplace. For example, the specific guidelines may provide detailed information such as an asset description, name, image, or metadata. Thus, the user terminal can comply with the specific guidelines and request the blockchain network to mint the non-fungible tokens.(7) Gas fees may be incurred in the process of requesting minting. Computing resources of the blockchain network are used to execute transactions corresponding to minting requests. Therefore, users may have to pay gas fees as a cost for using computing resources. Gas fees may be determined based on the congestion of the blockchain network and the complexity of the transaction. (8) Once the transaction is confirmed on the blockchain network, non-fungible tokens corresponding to the assets may be issued. (9) After minting, users can sell the non-fungible tokens on a marketplace. Users can set a desired price or choose to auction. Potential buyers can bid on the auction of non-fungible tokens using cryptocurrency or purchase them. (10) Once another user purchases the non-fungible tokens and the transaction is completed, ownership of the non-fungible tokens is transferred to the other user, and the non-fungible tokens are sent to the other user's digital asset wallet. Transaction details, including the value of the non-fungible tokens, may be permanently stored on the blockchain network. The processes described above are merely examples, and the present invention is not limited thereto.

[0064] The term "recipient address" as used in this document may refer to the digital asset wallet address of the user terminal that requested minting in the smart contract. Therefore, if a user terminal requests minting of a non-fungible token corresponding to a product and the minting is successful, 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 securely storing and managing an individual's digital assets in electronic form. A digital asset wallet can 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, allowing access to cryptocurrency in an online environment. Generally, hot wallets may be provided as software wallets or online services. Hot wallets offer convenient and rapid access to send cryptocurrency and process transactions quickly. A cold wallet may be a wallet that stores personal keys in an offline environment not connected to the internet. Cold wallets can generally be provided as hardware wallets or paper wallets. Because cold wallets securely protect personal keys and are stored offline, they can provide a high level of security against hacking and malicious software attacks.

[0065] The term "Zero-Knowledge Proof (ZKP)" used in this document refers to a proof where the prover demonstrates their knowledge without disclosing any of their own knowledge or information. It is a proof procedure where, when proving a statement to be true, nothing is revealed other than the truth or falsity of the statement itself. Specifically, a zero-knowledge proof is a protocol in which the prover proves to the verifier that they possess confidential information (witness) without disclosing it. The prover generates a proof value (proof) through communication with the verifier, based on the proposition being proven and the confidential information (witness) corresponding to the evidence. The verifier receives the proposition as input at the start of communication and, at the final stage of the protocol, verifies whether the relationship between the proposition and the confidential information matches, using the prover's proof value.

[0066] In this document, "sending a transaction to the blockchain" may include (1) uploading specific data to the blockchain, (2) modifying or deleting data that has already been uploaded to the blockchain, or (3) executing a smart contract 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 the transaction is executed on the EVM (Ethereum Virtual Machine).

[0068] The term "merkle proof" used in this document refers to a Merkle tree. In a Merkle tree, the leaf nodes are composed of hash values ​​of data, and all nodes other than the leaf nodes have hash values ​​for two child nodes. If even one of the data values ​​of a leaf node is changed, the result of the hash function changes sequentially up the hierarchy, 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, on the blockchain (for example, Ethereum on the chain), it is possible to verify whether or not specific data is included in that Merkle tree.

[0069] The term "nullifier" as used in this document refers to a unique identifier used to undo a previously committed transaction on a blockchain. For example, a nullifier can be any value. Specifically, when a user initiates a transaction on a blockchain, the transaction may include the recipient's address, the amount of digital asset to be sent (e.g., coins), and a nullifier. The nullifier can serve as proof that the user has approved the transaction. Once the transaction is processed and added to the blockchain, the nullifier may be stored on the blockchain along with the transaction details. If a user later wishes to undo a transaction, the nullifier associated with the transaction may be provided, and verification may be performed against the nullifier stored on the blockchain. If verification is successful, the transaction is invalidated, and the sent digital asset is returned to the user's account. Using nullifiers on a blockchain can prevent double-spending. Furthermore, users may be allowed to undo transactions if necessary. This can enhance transaction security and the protection of personal information. Furthermore, nullifiers can be used to generate smart contracts that can perform complex calculations while keeping transaction details private.

[0070] The terms "private key" and "public key" as used herein refer to the terms used in private-public-key algorithms. A private-public-key algorithm is an asymmetric encryption system that uses two keys, a private key and a public key, which are distinct but mathematically related. The private key may be an arbitrarily generated number. The private key is kept secret and is not disclosed 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] Various embodiments described herein will be explained below with reference to the attached drawings. In the attached drawings and descriptions thereof, identical or substantially equivalent components may be denoted by the same reference numerals. Furthermore, in the descriptions of the various embodiments below, redundant descriptions of identical or corresponding components may be omitted, but this does not mean that such components are not included in the embodiments.

[0072] Figure 1 shows an environment to which an apparatus relating to one embodiment of the contents disclosed herein may be applied. This environment may include a server 110, a means for transmitting unique numbers for goods 120, a blockchain network 130 including one or more nodes 131, or a user terminal 140. Figure 1 shows an example in which one user terminal 140 and eight nodes 131 are connected to the server 110 via the network, but this is for the purpose of providing convenience of understanding, and the number of user terminals 140 can be changed.

[0073] Server 110 may be a server that embodies a platform based on non-fungible tokens. Server 110 can perform various operations on non-fungible tokens. For example, Server 110 can manage the digital asset wallet addresses where users' tokens are stored. As another example, Server 110 can respond to minting requests for non-fungible tokens and send minting requests to the blockchain network 130. In one embodiment, a user terminal 140 sends a minting request to Server 110, and Server 110 can send the received minting request to the blockchain network 130. The blockchain network 130 can then perform processing related to the minting request. In another embodiment, the user terminal 140 can send a minting request directly to the blockchain network 130 without going through Server 110, in which case the blockchain network 130 can perform processing related to the minting request. As yet another example, Server 110 can reflect ownership information that has changed based on processing related to the minting request. In one embodiment, Server 110 can store and / or manage ownership information of non-fungible tokens. In other embodiments, the server 110 can send transactions to the blockchain network 130 that store and / or manage ownership information of non-fungible tokens. In this case, for example, a user terminal 140 can send a transaction to the server 110 that stores and / or manages ownership information, and the server 110 can send the received transaction to the blockchain network 130. In another example, the user terminal 140 can send a transaction to the blockchain network 130 that stores and / or manages ownership information directly, without going through the server 110. In addition to the examples described above, the server 110 can perform various operations that are generally required on a platform (e.g., communication between users). Furthermore, the server 110 can participate in token registration and trading by interacting with nodes 131 included in the blockchain network 130.

[0074] Server 110 may be implemented by one or more computing devices. For example, all functions of server 110 may be implemented in a single computing device. As another example, the first function of server 110 may be implemented in the first computing device, and the second function may be implemented in the second computing device. Here, the computing devices mentioned above may be, but are not limited to, desktop computers, laptop computers, application servers, proxy servers, cloud servers, etc., and may be various devices equipped with computing functions.

[0075] The means 120 for transmitting a unique product number may be a means for transmitting a unique product number to a user terminal 140. For example, the means 120 for transmitting a unique product number may include NFC (Near Field Communication) 121, QR (Quick Response) code 122, a message 123, a chip 124, etc. In one embodiment, the user terminal 140 can receive the unique product number using NFC 121. For example, the user terminal 140 can receive the unique product number through contactless communication with an NFC tag attached to the product. In another embodiment, the user terminal 140 can receive the unique product number using a QR code 122. The user terminal 140 can receive the unique product number by reading the QR code 122 with a camera included in the user terminal 140. In yet another example, the user terminal 140 can obtain the unique product number through a message containing the unique product number. For example, the user terminal 140 can receive a message from another electronic device, and the message may contain the unique product number. As yet another example, the user terminal 140 can receive the product's unique identification number via the chip 124. The chip 124 is a type of electronic device, which may be, for example, an IC (Integrated Circuit) chip. The chip 124 can transmit the product's unique identification number to the user terminal 140 through communication with the user terminal 140. The chip 124 may be attached to the product or card. The user terminal 140 can receive the product's unique identification number through communication with the chip 124 attached to the product or card. The means described above are merely illustrative, and the present invention is not limited thereto.

[0076] Node 131 can represent any one of the devices of individual participants in the blockchain network 130. Node 131 may be an element that constitutes the blockchain network 130. Node 131 can perform calculations to maintain the blockchain of the blockchain network 130. For example, any single node in the blockchain network 130 can generate a new block of that blockchain, which may be shared among other nodes in the blockchain network through a distributed consensus process and concatenated to the next block of the blockchain. That is, Node 131 can perform operations such as generating, verifying, or propagating transactions and the blocks in which those transactions are recorded. Depending on the operations performed by the node, Node 131 may be a Full Node, Light Node, Master Node, Mining Node, Random Node, Baking Node, or Super Node. Node 131 can generate tokens by interacting with Server 110. Furthermore, node 131 can register tokens by interacting with server 110.

[0077] Node 131 may be embodied by a computing device. For example, the computing device mentioned above may be a desktop computer, a laptop computer, etc., but is not limited to these, and may be any device equipped with computing functions.

[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. At least one node included in the blockchain network 130 may operate in a hierarchical structure. This hierarchical structure may include, for example, a data hierarchy that defines the structure of the 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 the fees paid to miners during the mining process; a common hierarchy that embodies or manages P2P network protocols, hash functions, digital signatures, encoding, and a common storage; or an application hierarchy where various applications are generated or processed.

[0079] At least one node included in the blockchain network 130 can share or store transactions recorded on the blockchain. Furthermore, at least one node included in the blockchain network 130 can perform verification on transactions sent to the blockchain network 130 by the blockchain's consensus algorithm, and, upon completion of verification, record the verified transaction in a block on the blockchain. The consensus algorithm used by the blockchain network 130 may include at least one of the following: PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stage), PBFT (Practical Byzantine Fault Tolerance), DBFT (Delegated Byzantine Fault Tolerance), RBFT (Redundant Byzantine Fault Tolerance), Sieve, Tendermint, Paxos, Raft, PoA (Proof of Authority), or PoET (Proof of Elapsed Time).

[0080] Each of the at least one nodes included in the blockchain network 130 can store a smart contract. This allows at least one node included in the blockchain network 130 to share the same smart contract. The smart contract may also be recorded in a block on the blockchain managed by the blockchain network 130. The smart contract may be, for example, a document or script written in a programming language such as Solidity, or 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 designed so that a specific action is performed when certain conditions are met. In this case, the specific conditions may be, for example, when a specific type of token is input or when a file of a specific format is input. The specific action may be, for example, when a specific type of token is sent to any node in the blockchain network 130.

[0081] The user terminal 140 may be the terminal of a user utilizing a non-fungible token-based platform. Here, the user can utilize various functions provided by the platform via the user terminal 140. For example, the user can request token registration, view a dashboard visualizing the registration status, or communicate with other users via the user terminal 140. To enable each user to use the platform, the user terminal 140 may be equipped with a web browser or a dedicated application. Such a user terminal 140 may be, but is not limited to, any device such as a desktop computer, workstation, laptop computer, tablet computer, audio player, wearable device, or smartphone, and may be any computing device equipped with computing capabilities.

[0082] Server 110, node 131, and user terminal 140 can communicate with each other via a network. The aforementioned network may be implemented by any type of wired or wireless network, such as a Local Area Network (LAN), Wide Area Network (WAN), mobile radio communication network, or Wibro (Wireless Broadband Internet).

[0083] On the other hand, the server 110, node 131, and user terminal 140 may represent functionally distinct elements. That is, two or more components may be implemented in a form that is integrated in the actual physical environment. For example, the server 110 and node 131 included in the blockchain network 130 may be implemented in different logic forms within the same computing device. That is, the server 110 may be implemented to operate as node 131 of the blockchain network 130.

[0084] Figure 2 shows a computing device 200 that can embody any one of the devices relating to one embodiment of the material disclosed herein. In the material disclosed herein, the computing device 200 may be referred to as an electronic device, and the terms computing device 200 and electronic device may be used interchangeably. The server 110, node 131 and 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 one embodiment, some components of the computing device 200 may be omitted, or other components (e.g., a display) may be added to the computing device 200. Alternatively, some components may be integrated and embodied, or embodied by one or more individuals. In the material disclosed herein, one or more processors 210 may be referred to as processor 210. Such a term, processor 210, can mean one or more processors unless otherwise specified in the context. Furthermore, in the content disclosed herein, one or more memories 220 may be referred to as "memory 220." Unless otherwise specified in the context, such a reference to "memory 220" can mean one or more sets of memories.

[0085] At least some components within the computing device 200 are connected to each other via a bus, GPIO (General Purpose Input / Output), SPI (Serial Peripheral Interface), or MIPI (Mobile Industry Processor Interface), etc., and can exchange data or signals.

[0086] The processor 210 can perform calculations or data processing related to the 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. For example, the processor 210 can load instructions or data into memory 220, process the instructions or data stored in memory 220, and store the resulting data in memory 220. Furthermore, the processor 210 can be operationally connected to the components of the computing device 200 and can perform various operations such as calculations, processing, data generation, and manipulation related to the content disclosed herein.

[0087] Memory 220 can store various types of data. The data stored in memory 220 is data acquired, processed, or used by at least one component of the computing device 200, and may include software (e.g., instructions, programs, etc.). For example, memory 220 can store instructions for the operation of the processor 210 as a computer program. Here, the computer program, when loaded into memory 220, may include one or more instructions that cause the processor 210 to perform operations according to various embodiments of the content disclosed herein. That is, the processor 210 can perform operations according to various embodiments of the content disclosed herein by executing the aforementioned one or more instructions. Memory 220 may also include volatile or non-volatile memory. In one embodiment, the instructions or program are software stored in memory 220 and may include an operational system for controlling the resources of the computing device 200, an application, or middleware that provides various functions to an application so that the application 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 can establish a wired or wireless channel with an external device (e.g., node 131 or user terminal 140) and send and receive various data with the external device. In one embodiment, the communication interface 230 may include at least one port for wired communication with an external device, which is connected to the external device by a wired cable. In this case, the communication interface 230 can communicate with the wired-connected external device via at least one port. In one embodiment, the communication interface 230 may include a cellular communication module and be configured to connect 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 be able to send and receive data with an 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, contactless communication may include at least one contactless proximity communication technology, such as NFC communication, RFID (Radio Frequency Identification) communication, or MST (Magnetic Secure Transmission) communication. In addition to the various examples described above, the computing device 200 may be embodied in various known ways for communicating with external devices, and the scope of what is disclosed herein is not limited by the examples described above.

[0089] In one embodiment, the computing device 200 may further include a display. Here, the display can show various screens based on the control of the processor 210. For example, the display can show a dashboard that visualizes the current status of platform user registration based on the control of the processor 210. In this case, a web browser or a dedicated application may be installed on the computing device 200 to display the dashboard on the display. In one embodiment, the aforementioned web browser or dedicated application may be implemented to provide the user with a registration request function or a communication function with other users via a user interface. The display is also configured to be interactive with the user, and can show various screens based on the control of the processor 210 and receive user input from the user. Such a display may be implemented in the form of a touch sensor panel (TSP) that can recognize the contact or proximity of various external objects (e.g., fingers, stylus, etc.). Here, the touch sensor panel may have various structures and types, and the contents disclosed herein are applicable regardless of the structure and type of the touch sensor panel.

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

[0091] Figure 3 illustrates a method for minting non-fungible tokens of physical goods according to one embodiment of the contents disclosed herein.

[0092] Product A 310 in Figure 3 may be a physical product. For example, product A 310 may include performance tickets, viewing tickets, sports competition tickets, bags, clothing, shoes, precious metals, food, etc. Product A 310 may be equipped with a device for contactless communication. For example, if product A 310 is a performance ticket, a device with NFC functionality may be attached to the performance ticket. Users can issue non-fungible tokens for the tickets they have purchased and prove ownership of those tickets. Users can also securely trade tickets with other users on the marketplace by having non-fungible tokens issued for their tickets. The reason why physical tickets can be traded securely is that there is no risk of losing the physical ticket that occurs when physical tickets are traded directly between parties, and ownership to Tiget is guaranteed. Therefore, by issuing tickets as non-fungible tokens to prove ownership, users can attend performances or exhibitions even if they lose their physical tickets, or sell tickets to other users. The following describes how to mint non-fungible tokens for physical products.

[0093] In one embodiment, an electronic device may be attached to product A 310. For example, the electronic device may include a contactless communication module. For example, the electronic device can exchange data with the user terminal 140 by contactless communication such as NFC communication, RFID communication, or MST communication. For example, a performance planning company can assign a unique number to each ticket while selling performance tickets to users and store the unique number in the electronic device attached to the ticket. The user terminal 140 in one embodiment can then receive the unique number for the product from the electronic device attached to the product. For example, the user terminal 140 can receive the unique number for product A 310 from the electronic device attached to product A 310. The user terminal 140 receives the unique number and can send a minting request 320 for the ticket to the blockchain network 130. A specific explanation of the minting request 320 will be given with reference to Figures 4A to 4F.

[0094] Figures 4A and 4B are flowcharts illustrating methods for minting non-fungible tokens of physical goods according to various embodiments of the contents disclosed herein.

[0095] In one embodiment, the product seller terminal 410 can generate a unique number for the product (S411). The product seller terminal 410 may be a terminal of an organization or individual that sells the product. In other embodiments, the product seller terminal 410 may be replaced by a product producer terminal. The product producer terminal may be a terminal of an organization or individual that produced the 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 specific performance. The performance planning company's terminal 410 can then generate a unique number corresponding to each of the issued performance tickets. The performance planning company can attach an electronic device containing the ticket's unique number to each performance ticket and ship the performance tickets to the purchaser.

[0097] In one embodiment, the product seller terminal 410 can generate a hash value of a unique number and a Merkle tree for the hash value of the unique number (S412). The hash value of the unique number may be the value obtained by hashing the unique number with a specific hash function. The product seller terminal 410 can generate a Merkle tree in which each of the hash values ​​of multiple unique numbers has at least one leaf node. For example, a second terminal of a company selling products (e.g., product seller terminal 410) can generate a Merkle tree (e.g., a first Merkle tree) based on the hash values ​​obtained by hashing the unique numbers of multiple products generated by the second terminal. Once the Merkle tree is generated, the product seller terminal 410 can 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 can be made public to 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 of the company selling the goods (e.g., a goods seller terminal 410).

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

[0099] In one embodiment, the product seller terminal 410 can sell products to a user that have an electronic device attached to them (S415). The operation of selling products to a user may be performed online and / or offline. For example, the product seller terminal 410 can sell products that have an electronic device with NFC functionality attached to them. The buyer can receive the product and perform NFC tagging on their terminal. Through NFC tagging, the user terminal 430 can receive the product's unique number and / or Merkle certification value from the electronic device attached to the product. In addition, the user terminal can receive the unique number via message, RFID communication, QR code, etc., and the present invention is not limited thereto.

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

[0101] In other embodiments, the user terminal 430 can generate a zero-knowledge proof of a unique number based on at least one of a unique number, a hash value of the unique number, a recipient address, or a proof key. By generating a zero-knowledge proof of a unique number using the recipient address, the user terminal 430 can obtain a zero-knowledge proof of a unique number that is dependent on the recipient address. As a result, if the recipient address changes, the zero-knowledge proof of the unique number also changes, thus preventing a third-party front-running attack. A front-running attack may involve an attack using the process by which a transaction is registered on the blockchain. A third party can gain an advantage by mimicking a transaction that has been pending in real time, paying high gas fees, and having the mimicked transaction stored in the block first. However, by adding the dependency of the recipient address to the zero-knowledge proof of the unique number, the recipient address of the transaction mimicked by the third party will be changed to the third party's wallet address, so the third party cannot mimic the zero-knowledge proof of the unique number. This prevents a third-party front-running attack.

[0102] In one embodiment, user terminal 430 can generate a transaction (S432) that includes at least one of the following: a hash value of a unique number, a recipient address, or a zero-knowledge proof of a unique number. The transaction may further include a first Merkle proof generated by a first Merkle tree. User terminal 430 can send the generated transaction to smart contract 450 (S433). The generated transaction may be a transaction requesting the minting of non-fungible tokens corresponding to a product. Because the transaction does not include a unique number, the unique number for the product is not made public on the blockchain network. Therefore, it is possible to prevent a third party from maliciously seizing the unique number for a product that has been made public on the blockchain and attributing ownership to the third party. By not making the unique number for the product public on the blockchain and by verifying whether user terminal 430 knows the unique number, the owner of the product can securely have non-fungible tokens of the product issued.

[0103] When a transaction according to one embodiment is sent to a blockchain network, computing resources of the blockchain network are used to execute the transaction, and therefore a fee may be incurred as payment for the use of computing resources. Consequently, if user terminal 430 requests minting while sending a transaction, the user of user terminal 430 may have to bear the fee. This can be a factor that reduces user participation in the platform where minting is performed. Therefore, platform operators can reduce the burden of fees on users by using a relay device that pays the transaction transmission fee on their behalf. The relay device can then request the fee from the product seller terminal. This can increase user participation in the platform. In this invention, since the transaction does not include a unique number, 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 changes, the zero-knowledge proof value of the unique number changes, so a third party cannot imitate the transaction that passes through the relay device. Consequently, security can be maintained even if a relay device that pays the transaction transmission fee on behalf of the user exists.

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

[0105] The processor according to one embodiment can execute a smart contract 450 and verify the transaction (S451). The processor according to one embodiment can verify a transaction that includes a zero-knowledge proof value of a unique number corresponding to a unique number. In order to verify the transaction, the processor can verify the hash value of the unique number included in the transaction. The processor can obtain a Merkle root based on the hash value of the unique number and a Merkle proof value (for example, the first Merkle proof value). The processor can 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 (Merkle root A) matches the Merkle root (Merkle root B) stored in the smart contract 450, the processor can determine that the transaction verification was successful (S453). Conversely, the processor can determine that transaction verification has failed (S452) if the acquired Merkle root (Merkle root A) does not match the Merkle root (Merkle root B) stored in the smart contract 450. In operation (S452), the processor can 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; the present invention is not limited thereto.

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

[0107] If the verification of the zero-knowledge proof value of the unique number according to one embodiment is successful (S456), the processor can invalidate the hash value of the unique number (S457). For example, the operation to invalidate the hash value of the unique number may be the operation to nullify the hash value of the unique number. As another example, the operation to invalidate the hash value of the unique number may be the operation to invalidate the transaction. Therefore, the processor can prevent the transaction from providing the same value twice as in operation (S433).

[0108] In one embodiment, the processor can mint non-fungible tokens of the goods to the recipient address (S458). The recipient address may be the digital asset wallet address of the user terminal 410 that requested the minting. The transaction may further include the recipient address. Furthermore, the processor can mint non-fungible tokens of the goods to the recipient address. As a result, ownership of the non-fungible tokens of the goods belongs to the user terminal 430 that sent the transaction, and the user of user terminal 430 can prove ownership of the goods.

[0109] A processor according to one embodiment can distribute non-fungible tokens of a product to a blockchain network (S459). The operation of distributing non-fungible tokens to a blockchain network may also be expressed as the operation of dropping non-fungible tokens. The distribution of non-fungible tokens to a blockchain network means that the non-fungible tokens have been registered on the marketplace. Therefore, a user can sell the non-fungible tokens registered on the marketplace to other users. This allows users to assign non-fungible tokens of a product to their digital asset wallet, easily prove ownership, and furthermore, trade products securely with other users on the marketplace using the non-fungible tokens of the product.

[0110] Figures 4C and 4F illustrate an embodiment in which smart contract 450 is divided into multiple smart contracts. Smart contracts may be divided into multiple units based on their function. For example, smart contracts may implement non-fungible token minting-related operations in one smart contract, or they may implement them 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. This allows the smart contract to be used by modifying only the smart contract that implements the operation of determining whether or not non-fungible token minting is permitted (e.g., the second smart contract 470), without having to modify the entire smart contract each time the conditions for whether or not minting of non-fungible tokens is permitted change. For example, the conditions for whether or not minting is permitted may differ for each seller of a product. Therefore, instead of modifying the entire smart contract that embodies the series of actions related to minting to suit each product seller, it is sufficient to modify separately only the smart contract that embodies the action of determining whether or not minting is permissible, which is a part of the series of actions related to minting. This can dramatically reduce the cost and time required to implement the series of actions related to minting of non-fungible tokens. In other words, by separating and implementing the smart contract that determines the conditions for whether or not minting is permissible (e.g., the second smart contract 470), which is a part of the minting-related actions, from the overall smart contract, and by modifying only the smart contract (e.g., the second smart contract 470) to suit the conditions for whether or not minting is permissible, which are set differently for each product seller, the cost and time required to create the smart contract that embodies the series of actions related to minting can be reduced.

[0111] Figures 4C and 4D may represent an embodiment in which the smart contract 450 is divided into a first smart contract 460 and a second smart contract 470.

[0112] Actions (S411), (S412), (S414), (S415), (S431), (S432), and (S433) have been specifically described in Figures 4A and 4B, so a detailed explanation is omitted in this figure.

[0113] The operation of the first smart contract 460 according to one embodiment may be understood as the operation of a processor connected to a computer network including a blockchain network. The operation of the second smart contract 470 according to one embodiment may be understood as the operation of a processor connected to a computer network including a blockchain network. The computing device containing the processor that executes the first smart contract 460 and the computing device containing the 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 can transmit a Merkle route (e.g., a first Merkle route) based on the generated Merkle tree to a second smart contract 470 (S413). In another embodiment, the product seller terminal 410 can transmit a Merkle route based on the generated Merkle tree to a first smart contract 460. The first smart contract 460 can then transmit the Merkle route to a second smart contract 470. The second smart contract 470 can then store the Merkle route.

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

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

[0117] In one embodiment, the processor can verify a transaction by executing the second smart contract 470 (S471). The Merkle proof value included in the second smart contract 470 may be used for transaction verification. Since the transaction verification has been specifically described in the operation of Figures 4A and 4B (S451), a detailed explanation referring to those figures will be omitted. If the transaction verification fails (S472), the processor can send a transaction verification failure result message to the first smart contract 460 and / or the user terminal 430.

[0118] If the transaction verification according to one embodiment is successful (S473), the processor can verify the zero-knowledge proof value of the unique number (S474). The verification of the zero-knowledge proof value of the unique number has been specifically described in the operation of Figures 4A and 4B (S454), so a detailed explanation referring to those figures will be omitted. If the verification of the zero-knowledge proof value of the unique number fails (S475), the processor can send a message indicating the failure of the zero-knowledge proof value verification 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 can send the verification result to the first smart contract 460 (S477). The verification result sent in operation (S477) may include successful transaction verification and successful zero-knowledge proof value verification of the unique number.

[0119] In one embodiment, the first smart contract 460 receives the verification result and can perform the operation (S467). Based on the verification result, the processor can invalidate the hash value of the unique number (S467). By invalidating the operation (S467), the transaction of operation (S433) is invalidated, and the double issuance of non-fungible tokens can be prevented. In one embodiment, the processor can mint the non-fungible token of the product to the recipient address (S468) by executing the first smart contract 460. The processor can also perform the operation (S469) by executing the first smart contract 460. Operations (S467), (S468), and (S469) have been specifically described in operations (S457), (S458), and (S459) in Figures 4A and 4B, respectively, so a detailed explanation referring to those figures is omitted. In other embodiments, at least a portion of operations (S467), (S468), and (S469) may be performed in the second smart contract 460, and the present invention is not limited thereto.

[0120] Figures 4E and 4F may represent an embodiment in which the smart contract 450 is divided into a first smart contract 460, a second smart contract 470, and a third smart contract 480.

[0121] Since operations (S411), (S412), (S414), (S415), (S431), (S432), and (S433) have been specifically described above with reference to Figures 4A and 4B, a detailed explanation with reference to those figures will be omitted.

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

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

[0124] In one embodiment, the first smart contract 460 can receive transactions from a terminal. Furthermore, the first smart contract 460 can mint non-fungible tokens based on verification results. The second smart contract 470 can verify transactions. The third smart contract 480 can verify zero-knowledge proofs of unique numbers. Since the conditions for transaction verification may differ for each product, the cost and time required to implement smart contracts for product-specific minting methods can be reduced by separately implementing only the second smart contract 470. For example, transaction verification for a performance organizer selling performance tickets may be implemented using a Merkle tree, while transaction verification for an exhibition organizer selling exhibition tickets may be implemented using public-key-private-key verification. Therefore, the second smart contract 470 can be implemented differently depending on the verification method, and thus there is a practical benefit to 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 customers to implement smart contracts that embody a series of actions related to minting, in response to the transaction verification method requirements of various companies, with less time and cost.

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

[0126] The processor according to one embodiment can verify a transaction (S471) by executing the second smart contract 470. The Merkle proof value included in the second smart contract 470 may be used for transaction verification. The transaction verification is the same as the operation (S451) in Figures 4A and 4B, and a detailed explanation referring to those figures will be omitted. If the transaction verification fails (S472), the processor can 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 can request a zero-knowledge proof value verification of the unique number from the third smart contract 480 (S474). The operation (S474) may include 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 one embodiment can 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 in Figures 4A and 4B (S454), and a detailed explanation referring to those figures is omitted. If the verification of the zero-knowledge proof value of the unique number fails (S482), the processor can send a message indicating the failure of the zero-knowledge proof value verification 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 can send the verification result to the second smart contract 470 (S484). The verification result sent in operation (S484) may include a successful verification of the zero-knowledge proof value of the unique number. The processor according to one embodiment can send the verification result to the first smart contract 460 (S474). The verification results transmitted 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 one embodiment can receive the verification result and perform the operation (S467). Based on the verification result, the processor can invalidate the hash value of the unique number (S467). By invalidating the operation (S467), the transaction of operation (S433) is invalidated, and the double issuance of non-fungible tokens can be prevented. The processor according to one embodiment can mint the non-fungible token of the product to the recipient address (S468) by executing the first smart contract 460. The processor can also perform the operation (S469) by executing the first smart contract 460. Operations (S467), (S468), and (S469) have been specifically described in operations (S457), (S458), and (S459) in Figures 4A and 4B, respectively, so a detailed explanation referring to those figures is omitted. In other embodiments, at least a portion of operations (S467), (S468), and (S469) may be performed in the second smart contract 460 or the third smart contract 470, and the present invention is not limited thereto.

[0129] Figure 5 illustrates a method for minting non-fungible tokens via a third terminal, according to one embodiment of the contents disclosed herein.

[0130] In one embodiment, a user can receive data necessary for minting from an electronic device using a user terminal 140 (e.g., a first terminal). The electronic device (e.g., a third terminal 510) that transmits the data necessary for minting to the user terminal 140 may generate a unique number and store a personal key for signing. For example, the electronic device (e.g., a third terminal 510) described above may be a device provided by a product seller. The product seller terminal 610 (e.g., a second terminal) can generate a personal key and transmit the generated personal key to the electronic device (e.g., a third terminal 510). The personal key can be used to sign the unique number generated by the electronic device (e.g., a third terminal 510). The electronic device (e.g., a third terminal 510) described above may include, for example, a kiosk, an IC card, or an electronic device equipped with an application for generating a unique number.

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

[0132] In other embodiments, if the third terminal 510 is a terminal 512 having a QR function 122, a QR code may be displayed on the screen of terminal 512. The QR code displayed on the screen is generated and displayed each 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 the double issuance of non-fungible tokens by having another user request minting of non-fungible tokens for the same QR code, and prevents ownership of the goods from belonging to an unauthorized person. A user can scan the QR code on terminal 512 using user terminal 140. In this case, user terminal 140 can receive the unique number and personal key of the goods from terminal 512.

[0133] The aforementioned operation by the user terminal 140 to receive the unique number and personal key is merely illustrative, and the information may be received by other communication methods; therefore, the present invention is not limited thereto.

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

[0135] In one embodiment, a performance planning company can sell performance tickets to users. Performance tickets may be sold at electronic devices located in specific locations (e.g., kiosks). Users can NFC tag each ticket at the electronic device located in a specific location (e.g., a kiosk) and request minting of a non-fungible token for the ticket.

[0136] In one embodiment, the user terminal 140 can receive a unique number and personal key for a product from an electronic device (e.g., a third terminal 510). For example, the user terminal 140 can receive a unique number and personal key for a product from the third terminal 510. The user terminal 140 can send a minting request 520 for a ticket to the blockchain network 130. A specific explanation of the minting request 520 will be given with reference to Figures 6A to 6H.

[0137] Figures 6A and 6B are flowcharts illustrating methods for minting non-fungible tokens via a third terminal according to various embodiments of the contents disclosed herein.

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

[0139] In one embodiment, the product seller terminal 610 can transmit a public key corresponding to the personal key to the smart contract 650 (S612). The processor executes the smart contract 650 and can verify the signature data signed with the personal key using the public key included in the smart contract 650. Verification using the public key will be described in detail later in the operation (S651).

[0140] For example, if the seller of goods is a performance planning company, the company can issue multiple performance tickets related to a specific performance. The company's terminal 410 can then sell these issued performance tickets at kiosks located in specific locations (e.g., performance venues, subway stations). The company can store a personal key for unique number signing at the kiosk. The public key corresponding to the personal key may be stored on a blockchain network. This allows the use of a personal key-public key algorithm to verify transactions requesting minting. Users can purchase tickets using a kiosk located in a specific location and a user terminal 630. When a user purchases a ticket at a kiosk, the user terminal 630 can receive the unique number and personal key from the kiosk via NFC tagging. In another example, the user terminal 630 can scan a QR code displayed on the kiosk and receive the unique number and personal key from the kiosk.

[0141] In one embodiment, the user terminal 630 can request minting-related data for the non-substitutable token of the product (S631). The operation (S631) may be performed by the user terminal 630 communicating with the third terminal 620 via contactless communication, or by the user terminal 630 scanning a QR code displayed on the screen of the third terminal 620.

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

[0143] In one embodiment, the third terminal 620 can generate signed data (S622) by signing the hash value of a unique number with a personal key. The personal key may be the key received from the product seller terminal 610 during operation (S611).

[0144] In one embodiment, the third terminal 620 can transmit a unique number and signature data to the user terminal 630 (S623).

[0145] In one embodiment, when the third terminal 620 and the user terminal 630 exchange data via 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. 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 will not be able to obtain the unique number and personal key.

[0146] In one embodiment, user terminal 630 can generate a zero-knowledge proof value of a unique number (S632). User terminal 430 can generate a zero-knowledge proof value of a unique number based on at least one of the unique number, the hash value of the unique number, or the proof key. In one embodiment, user terminal 430 can generate a zero-knowledge proof value of a unique number using a proof algorithm that uses at least one of the unique number, the hash value of the unique number, or the proof key as an intermediary variable. In another embodiment, user terminal 430 can generate a zero-knowledge proof value of a 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 a zero-knowledge proof value of a unique number has been specifically described in Figures 4A and 4B, so a detailed explanation referring to those figures will be omitted.

[0147] In one embodiment, the user terminal 630 can generate a transaction (S633) that includes at least one of the following: a hash value of a unique number, a recipient address, signature data, or a zero-knowledge proof of a unique number. The signature data is data in which the hash value of the unique number has been signed with a personal key. The user terminal 630 can send the generated transaction to the smart contract 650 (S634). The generated transaction may be a transaction requesting the minting of non-fungible tokens corresponding to the goods. By not including a unique number in the transaction, the unique number for the goods does not need to be made public on the blockchain network. This can prevent malicious acts that utilize unique numbers for goods made public on the blockchain network.

[0148] In this specification, the operation of the smart contract 650 may be understood as the operation of a processor connected to a computer network, including a blockchain network. The operation of the smart contract 650 may be the operation 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. Then, the processor can perform operation (S652). In operation (S652), the processor can send a transaction verification failure result message to the user terminal 630.

[0150] In one embodiment, the processor can verify the zero-knowledge proof value of the unique number (S654) if the transaction verification is successful (S653). The processor can perform a verification algorithm based on at least one of the following: 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 prover's user terminal 630 knows the unique number. In this case, the verification of the zero-knowledge proof value of the unique number may be successful (S656). Conversely, if the result of the verification algorithm is false, the processor can determine that the prover's user terminal 630 does not know the unique number. In operation (S655), the processor can send a message to the user terminal 630 indicating that the verification of the zero-knowledge proof value of the unique number failed.

[0151] If the verification of the zero-knowledge proof value of the unique number according to one embodiment is successful (S656), the processor can invalidate the hash value of the unique number (S657). In one embodiment, the operation to invalidate the hash value of the unique number may be the operation to invalidate the transaction. In other embodiments, the operation to invalidate the hash value of the unique number may include the operation to change 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 prevents the reuse of the hash value of the unique number from causing double-spending. If the nullifier verification is successful, the processor can invalidate the transaction of operation (S633). Therefore, the processor can prevent double-spending by the transaction of operation (S633).

[0152] Since operations (S658) and (S659) have been specifically described in Figures 4A and 4B, the explanation referring to those figures will be omitted.

[0153] Figures 6C to 6H illustrate an example in which smart contract 650 is divided into multiple smart contracts.

[0154] Smart contracts can be divided into multiple contracts based on their function. For example, a smart contract can either implement the minting-related operations of non-fungible tokens in a single smart contract, or implement them in separate smart contracts. By dividing a smart contract into multiple smart contracts based on its function, an organization or individual providing non-fungible token-related services can separate and configure only the functions that require customization for each content provider (e.g., a performance planning company) as separate smart contracts. Furthermore, when a smart contract is divided into multiple contracts based on its function, smart contracts corresponding to functions where reliability is critical can be separated from smart contracts corresponding to other, less critical functions. This allows for the maintenance of smart contracts corresponding to critical functions and the redistribution of smart contracts corresponding to less critical functions to reflect the changes in service content when service content needs to be changed (updated) later. Therefore, by dividing smart contracts into multiple contracts based on their function, unnecessary redistribution of smart contracts can be minimized. And since gas fees can increase as the amount of content included in a smart contract increases, dividing smart contracts based on their function and minimizing the redistribution of smart contracts can save on gas fees and computing resources. Figures 6C and 6D may represent an embodiment in which the smart contract 650 is divided into a first smart contract 660 and a second smart contract 670.

[0155] Since operations (S611), (S612), (S631), (S621), (S622), (S623), (S632), and (S633) have been specifically described in Figures 6A and 6B, a detailed explanation referring to those figures will be omitted.

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

[0157] In one embodiment, the product seller terminal 610 can transmit a public key corresponding to a personal key to the second smart contract 670. In another embodiment, the product seller terminal 610 can transmit a public key to the first smart contract 660. The first smart contract 660 can then transmit 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 can receive a transaction from a terminal. The second smart contract 670 can verify the transaction and verify the zero-knowledge proof value of the unique number. The first smart contract 660 can mint a non-fungible token based on the verification result received from the second smart contract 670.

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

[0160] In one embodiment, the processor can verify a transaction (S671) by executing the second smart contract 670. In operation (S671), the processor can verify the signature data. Operation (S671) has been described above in operation (S651) in Figures 6A and 6B, so a detailed explanation referring to those figures is omitted. If the transaction verification fails (S672), the processor can send a transaction verification failure result message to the first smart contract 660 and / or the user terminal 630.

[0161] In one embodiment, the processor can verify the zero-knowledge proof value of the unique number (S674) if the transaction verification is successful (S673). The operation (S674) has been described above in the operation (S654) of Figures 6A and 6B, so a detailed explanation referring to those figures will be omitted. If the verification of the zero-knowledge proof value of the unique number fails, the processor can send a message indicating the failure of the zero-knowledge proof value verification 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 send the verification result to the first smart contract 660 and / or the user terminal 630 (S677). The verification result sent in operation (S677) may include successful transaction verification and successful zero-knowledge proof value verification of the unique number.

[0163] In one embodiment, the first smart contract 660 receives the verification result and can perform an action (S667). Based on the verification result, the processor can invalidate the hash value of the unique number (S667). By executing the first smart contract 660, the processor in one embodiment can mint a non-fungible token of the goods to the recipient address (S668). The processor can also perform an action (S669) by executing the first smart contract 660. Actions (S667), (S668), and (S669) have been specifically described in actions (S657), (S658), and (S659) in Figures 6A and 6B, respectively, so a detailed explanation referring to those figures is omitted. In other embodiments, at least a part of actions (S667), (S668), and (S669) may be performed in the second smart contract 670, and the present invention is not limited thereto.

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

[0165] Since operations (S611), (S612), (S631), (S621), (S622), (S623), (S632), and (S633) have been specifically described in Figures 6A and 6B, a detailed explanation referring to those figures will be omitted.

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

[0167] In one embodiment, the product seller terminal 610 can transmit a public key corresponding to the personal key to the second smart contract 670 (S612). The operation (S612) has been specifically described in Figures 6C and 6D, so a detailed explanation referring to those figures will be omitted.

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

[0169] The processor according to one embodiment can request verification from the second smart contract 670 by executing the first smart contract 660 (S661). The operation (S661) has been specifically described in Figures 6C and 6D, so a detailed explanation referring to those figures will be omitted.

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

[0171] In one embodiment, the processor can 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 in Figures 6A and 6B (S654), and a detailed explanation referring to those figures is omitted. If the verification of the zero-knowledge proof value of the unique number fails (S682), the processor can send a message indicating the failure of the zero-knowledge proof value verification 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 can send the verification result to the second smart contract 670 (S684). The verification result sent in operation (S684) may include a successful verification of the zero-knowledge proof value of the unique number. In one embodiment, the processor can send the verification result to the first smart contract 660 (S675). The verification results transmitted in operation (S675) may include successful transaction verification and successful zero-knowledge proof value verification of the unique number.

[0172] Actions (S667), (S668), and (S669) have been specifically described in Actions (S657), (S658), and (S659) in Figures 6A and 6B, respectively, so a detailed explanation referring to those figures will be omitted. In other embodiments, at least a portion of Actions (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] Figures 6G and 6H may represent an embodiment in which the 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] Since operations (S611), (S612), (S631), (S621), (S622), and (S623) have been specifically described in Figures 6A and 6B, a detailed explanation referring to those figures will be omitted.

[0175] A problem can arise where a single user is issued multiple non-fungible tokens if they tag their device multiple times using NFC from a third device or request QR code generation multiple times, resulting in the generation of multiple unique identifiers. This is because a single user can create multiple digital asset wallets and use these multiple unique identifiers to mint non-fungible tokens into each of them.

[0176] The first smart contract 660, the second smart contract 670, the third smart contract 680, and the fourth smart contract 690 according to one embodiment may be embodied as a single smart contract or as at least two smart contracts. Figures 6G and 6H are illustrative and the disclosure is not limited thereto.

[0177] Therefore, in order to provide one non-fungible token to one user, the processor can use user identification information to mint the non-fungible token to that user. The method of minting a non-fungible token using user identification information is described in detail below.

[0178] In one embodiment, the user terminal 630 can generate a zero-knowledge proof value of a unique number (S632). In another embodiment, the user terminal 630 can generate a zero-knowledge proof value of a 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. In yet another embodiment, the user terminal 630 can generate a zero-knowledge proof value of a unique number based on at least one of the unique number, the hash value of the unique number, the recipient address, user identification information, or the proof key. A detailed explanation of the operation (S632) has been specifically described in Figures 6A and 6B, so a detailed explanation referring to those figures will be omitted.

[0179] In one embodiment, user terminal 630 can generate a second Merkle root based on user identification information (S633). User identification information may include information for distinguishing one user from other users. 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. User identification information may be user identification information authenticated by a government agency, financial institution, etc. User identification information may include, for example, a username, resident registration number, address, nationality, contact information, and, if the user is an organization, the industry of the organization. As another example, user identification information may include the user's digital asset wallet address. As yet another example, user identification information may be the unique number (or serial number) of the user terminal. User terminal 630 can generate a second Merkle tree based on a value obtained by hashing the user identification information. For example, user terminal 630 can generate a second Merkle tree based on a value obtained by hashing multiple user identification information. User terminal 630 can obtain a second Merkle root from the second Merkle tree. User terminal 630 can send the second Merkle root of the second Merkle tree to a smart contract (for example, one of the first smart contract 660, the second smart contract 670, the third smart contract 680, or the fourth smart contract 690). If the second Merkle root is included in a smart contract, the second Merkle root is made public on the blockchain network.

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

[0181] A user terminal 630 according to one embodiment can generate a transaction (S634) that includes at least one of the following: a hash value of a unique number, a recipient address, signature data, a second Merkle proof value, or a zero-knowledge proof value of a 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 some of the nodes of the second Merkle tree. The second Merkle proof value may include only the minimum number of nodes necessary to reconstruct the second Merkle root.

[0182] Since operations (S635) and (S661) have been specifically described in Figures 6E and F, a detailed explanation referring to those figures will be omitted.

[0183] The processor according to one embodiment can verify a transaction (S681) by executing the second smart contract 670. Transaction verification has been specifically described above with reference to Figures 6A and 6B, so a detailed explanation with reference to those figures will be omitted.

[0184] In one embodiment, the processor can verify user identification information by executing the fourth smart contract 670 (S691). In one embodiment, the processor can obtain a Merkle root based on the hash value and the second Merkle proof value of the user identification information. The processor can determine whether the Merkle root obtained based on the hash value and the second Merkle proof value of the user identification information (hereinafter, Merkle root C) matches the second Merkle root (hereinafter, Merkle root D) stored in the smart contract (for example, the fourth smart contract 690). If the obtained Merkle root (Merkle root C) matches the Merkle root (Merkle root D) stored in the smart contract, the processor can determine that the verification of user identification information has been successful (S693). If the verification of user identification information is successful (S693), the processor can transmit the verification result of the user identification information to the third smart contract 680 (S694). Conversely, the processor can determine that user identification information verification 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 can send a user identification information 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 user identification information using a Merkle tree is merely an example, and user identification information may be verified by other verification methods, and the present invention is not limited thereto.

[0185] In other embodiments, the user terminal 630 can generate a zero-knowledge proof of user identification information. The user terminal 630 can include the zero-knowledge proof of user identification information in a transaction. The processor in one embodiment can verify the zero-knowledge proof of user identification information by executing a fourth smart contract 690. This allows the processor to verify that the prover user terminal 630 knows the user identification information without exposing the user identification information to the blockchain network.

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

[0187] The function of the fourth smart contract 690 according to one 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 can perform user identification information verification (S691) by executing one of the third smart contract 680, the second smart contract 670, or the first smart contract 660. Therefore, user identification information verification (S691) may be implemented in one smart contract with transaction verification (S671) and / or zero-knowledge proof value verification of unique number (S683), or in different smart contracts.

[0188] If the zero-knowledge proof verification of the unique number according to one embodiment is successful (S683), the processor may transmit the verification result to the second smart contract 670 (S684). The verification result transmitted in operation (S684) may include at least one of the following: successful verification of the zero-knowledge proof of the unique number or successful verification of user identification information. The processor according to one embodiment may transmit the verification result to the first smart contract 660 (S676). The verification result transmitted in operation (S676) may include at least one of the following: successful transaction verification, successful verification of the zero-knowledge proof of the unique number, or successful verification of user identification information.

[0189] The processor according to one embodiment can distribute non-fungible tokens to the blockchain network based on the transaction verification result, the verification result of the zero-knowledge proof value of the unique number, and the verification result of the user identification information by executing the first smart contract 660. The processor can distribute non-fungible tokens to the blockchain network if the transaction verification is successful, the verification of the zero-knowledge proof value of the unique number is successful, and the verification of the user identification information is successful.

[0190] Actions (S667), (S668), and (S669) have been specifically described in Actions (S657), (S658), and (S659) in Figures 6A and 6B, respectively, so a detailed explanation referring to those figures will be omitted. In other embodiments, at least a portion of Actions (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 can issue one non-fungible token to a single user by minting non-fungible tokens using user identification information.

[0192] Figure 7 illustrates a method for minting non-fungible tokens via a device attached to a product according to one embodiment of the contents disclosed herein.

[0193] Ownership of a product can be transferred at any time. For example, if user A sells product A to user B, ownership of product A is transferred from user A to user B. If a user mints non-fungible tokens for a product, ownership information of those non-fungible tokens may be stored in the user's digital asset wallet. However, if a user does not mint the non-fungible tokens for a product, there may be a discrepancy between the ownership information of the product and the ownership information of the non-fungible tokens. For example, if user A sells product A to user B, ownership of product A belongs to user B. However, if neither user A nor user B mints the non-fungible tokens related to the transfer of ownership, the ownership information of the non-fungible tokens may remain with user A.

[0194] Furthermore, if a digital asset wallet containing ownership information for non-fungible tokens related to a specific product is lost, it becomes difficult to recover ownership of the non-fungible tokens. For example, if user A loses their digital asset wallet, user A owns product A, but cannot prove ownership of the non-fungible tokens related to product A on the blockchain network. Therefore, in this case as well, there may be a discrepancy between the owner of the product and the ownership information for the non-fungible tokens related to that product.

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

[0196] Referring to Figure 7, an electronic device 711 may be attached to product B710. A buyer who purchases product B710 can communicate with the electronic device 711 using a user terminal 140. The user terminal 140 can receive data from the electronic device 711 and request (720) the blockchain network 130 to mint non-fungible tokens for product B710. The minting method in Figure 7 is explained in detail in Figures 8A and 8B.

[0197] Figures 8A and 8B are flowcharts illustrating methods for minting non-fungible tokens via devices attached to goods, relating to various embodiments of the contents disclosed herein.

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

[0199] In one embodiment, the product seller terminal 810 can transmit a public key corresponding to the personal key to the second smart contract 870 (S812). The processor executes the second smart contract 870 and can verify the signature data signed with the personal key using the public key included in the second smart contract 870. Verification using the public key will be described in detail later in the operation (S871).

[0200] In another embodiment, the product seller terminal 810 may, in operation (S812), send a Merkle root of multiple public keys (e.g., a third Merkle root) to the second smart contract 870. The third Merkle root may be the root node of a third Merkle tree generated based on the hash values ​​obtained by hashing the multiple public keys. If the third Merkle root is included in the second smart contract 870, transaction verification may be performed in operation (S871) using the third Merkle proof value. 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 can determine whether the obtained Merkle root matches the third Merkle root included in the second smart contract 870 and perform transaction verification.

[0201] The operations (S811) and (S812) in one embodiment may be performed when the goods are first minted, and may be omitted if ownership information of non-fungible tokens for the goods exists on the blockchain network.

[0202] In one embodiment, the user terminal 830 may be a terminal of the product purchaser. By communication between the device 820 attached to the product and the user terminal 830, the purchaser who has purchased the product can include non-fungible tokens for the product in their digital asset wallet at any time. The minting method for non-fungible tokens will be described in detail below.

[0203] In one embodiment, the user terminal 830 can request the first block number from the blockchain node 850 (S831). The blockchain node 850 can then transmit the first block number and the block hash value to the user terminal 830 (S851). The block hash value may be the hash value corresponding to the first block number.

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

[0205] In one embodiment, the user terminal 830 can transmit a block hash value and a unique number to a device 820 attached to the product (S834). In one embodiment, the user terminal 830 can transmit the block hash value and 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. An APDU may be a data unit used when an IC chip and other electronic devices exchange data. The user terminal 830 can transmit an APDU containing the block hash value and unique number to the device 820.

[0206] In one embodiment, the device 820 can generate signed data (S821) by signing a block hash value and a unique number with a personal key. For example, the device 820 can generate signed data by signing a (block hash value, unique number) value with a personal key. The personal key may be a key stored in the device 820. In one embodiment, the device 820 can generate a first hash value by hashing a value that includes a block hash value and a unique number. In another embodiment, the device 820 can generate signed data by signing the first hash value with a personal key.

[0207] In one embodiment, the device 820 can transmit signature data to the user terminal 830 (S822). The device 820 can also transmit a first hash value along with the signature data to the user terminal 830.

[0208] In one embodiment, the user terminal 830 can generate a zero-knowledge proof value (S834) of a unique number based on a block hash value and a unique number. The user terminal 830 can receive a first hash value, which is obtained by hashing a value including the block hash value and the unique number, from the device 820. In one embodiment, the user terminal 830 can generate a zero-knowledge proof value of a 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, a zero-knowledge proof value of a unique number can be generated 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] In one embodiment, the user terminal 830 can generate a transaction that includes at least one of the following: a first hash value, a hash value of a unique number, a block number, a recipient address, signature data, or a zero-knowledge proof of a unique number. The user terminal 830 can transmit the generated transaction to the first smart contract 860 (S835). The generated transaction may be a transaction requesting the minting of non-fungible tokens corresponding to a product. Because the transaction does not include a unique number, the unique number is not exposed on the blockchain network.

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

[0211] In one embodiment, the first smart contract 860 can send a transaction verification request (S861) to the second smart contract 870 in response to the receipt of a transaction. The processor can verify the transaction (S871) by executing the second smart contract 870. Specifically, the processor can verify the signature data included in the transaction. In one embodiment, if a public key is stored in the second smart contract 870, the processor can determine whether the public key of the signature data matches the public key stored in the second smart contract 870. Verification of signature data based on a public key has been specifically described above with reference to Figures 6A and 6B, so a detailed explanation is omitted in those figures. In another embodiment, if a third Merkle root is stored in the second smart contract 870, the processor can 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 in the operation (S672) in Figures 6E and 6F, so a detailed explanation is omitted in those figures.

[0213] In one embodiment, if the processor successfully verifies the transaction (S873), it can determine whether the difference between the second block number and the first block number is below a certain threshold (S874). For example, after user A transfers ownership of product B710 to user B, user A may scan the device attached to product B710, and user A's terminal may obtain the information necessary for minting before user B's terminal. As a result, although product B710 has been transferred to user B, ownership of the non-fungible token for product B710 may still belong to user A. Therefore, by determining whether the minting request was made within the validity period after the unique number was generated, the processor can prevent the previous owner from transferring ownership of the non-fungible token for the product to the previous owner instead of the new owner.

[0214] A processor according to one embodiment can determine the passage of time by determining whether the difference between the second block number and the first block number is less than or equal to a reference value. The processor can 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 received by the user terminal 830 upon request from the blockchain node 850. The first block number can represent the time when the user terminal 830 generated a unique number. This is because blocks are continuously generated in fixed time units, and the block number increases by a fixed amount at each fixed 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 5-second time interval between the time the first block number was generated and the time the second block number was generated. The reference value may be determined based on the first block number. There is a difference of a fixed number of blocks between the reference value and the first block number. For example, if the first block number is 500, the threshold 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 period. The processor can determine that it is within the minting request validity period if it determines whether the block number is below the threshold value within a certain time from the time the user terminal requested the block number (S831). Once a certain time has elapsed, the minting request validity period has expired, and the processor can reject the minting request. This prevents the processor from assigning ownership of non-fungible tokens to the previous owner instead of the new owner. The minting request validity period may have expired if the difference between the second block number and the first block number is greater than or equal to the threshold value. In this case, the processor can send a message to the user terminal 830 including a notification that the minting request validity period has expired (S875).

[0215] If it is within the valid minting request period according to one embodiment (S876), the processor can request the block hash value corresponding to the second block number from the blockchain node 850 (S877). The blockchain node 850 can then send the block hash value corresponding to the second block number to the second smart contract 870 (S852).

[0216] If it is within the validity period of the minting request according to one embodiment (S876), the processor can send a request for verification of the zero-knowledge proof value of the unique number (S878) to the third smart contract 880. The processor can verify the zero-knowledge proof value of the unique number by executing the third smart contract 880 (S881). The processor can perform a verification algorithm based on at least one of the following: 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 can determine that the prover's user terminal 830 knows the unique number. In this case, the verification of the zero-knowledge proof value of the unique number may be successful (S883). Conversely, if the result of the verification algorithm is false, the processor can determine that the prover's user terminal 830 does not know the unique number. In operation (S882), the processor can send a message indicating that the verification of the zero-knowledge proof value of the unique number failed to the user terminal 830.

[0217] If the verification of the zero-knowledge proof value of the unique number according to one embodiment is successful (S883), the processor can transmit the verification result to the second smart contract 870. The processor can invalidate the hash value of the unique number (S889). This operation (S889) may also be implemented in the first smart contract 860 or the third smart contract 880, and the present invention is not limited thereto.

[0218] The processor according to one embodiment can transmit verification results to the first smart contract 860. These results 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 verification of the unique number.

[0219] In one embodiment, the processor can mint (S868) the NFT of the product to the recipient address in response to the verification results described above. In one embodiment, if ownership information of the non-fungible token for the product is not stored on the existing blockchain network, new ownership information of the non-fungible token for the product may be generated. In another embodiment, if ownership information of the non-fungible token for the product exists on the blockchain network and ownership is transferred to another user, the ownership information stored in the block may be updated. In yet another example, if 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 can perform operation (S869) if non-fungible tokens for the product have not been distributed to the blockchain network. Conversely, if non-fungible tokens for the product have been distributed to the blockchain network, the processor may omit operation (S869).

[0221] Figure 9 is a flowchart illustrating a method for minting non-fungible tokens according to one embodiment of what is disclosed herein.

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

[0223] An electronic device 200 according to one embodiment can execute a smart contract (920) in response to the receipt of a transaction.

[0224] An electronic device 200 according to one embodiment can verify a transaction that includes a zero-knowledge proof value of a unique number corresponding to a unique number for a product by executing a smart contract.

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

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

[0227] Figure 10 is a flowchart illustrating the operation of a user terminal according to one embodiment of the contents disclosed herein.

[0228] An electronic device 200 according to one embodiment can generate a zero-knowledge proof value (1010) of the unique number corresponding to the unique number of a product in response to the reception of the unique number of a product.

[0229] An electronic device 200 according to one embodiment can send (1020) a transaction containing at least one of the following: a hash value of a unique number, a recipient address, or a zero-knowledge proof value of a unique number to a smart contract. 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] An electronic device 200 according to one embodiment can receive the minting result of a non-fungible token (1030) based on the verification result of the zero-knowledge proof value of a unique number obtained when a smart contract that received a transaction is executed.

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

[0232] Figure 11 is a flowchart illustrating the operation of a user terminal by another embodiment of the contents disclosed herein.

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

[0234] An electronic device 200 according to one embodiment can generate a unique number (1120) which is an arbitrary value.

[0235] An electronic device 200 according to one embodiment can transmit a block hash value and a unique number (1130) to a device attached to the product.

[0236] An electronic device 200 according to one embodiment can receive (1140) signed signature data from the device, which is a first hash value obtained by hashing a value including a block hash value and a unique number, and which is signed with a personal key.

[0237] An electronic device 200 according to one embodiment can generate a zero-knowledge proof value of a unique number (1150) based on a first hash value.

[0238] An electronic device 200 according to one embodiment can transmit (1160) a transaction requesting the minting of non-fungible tokens for a product to a computer network including a blockchain network.

[0239] In the flowcharts disclosed herein, each step of the method or algorithm is described in a sequential order; however, the steps may be performed in any order that can be combined, in addition to being performed sequentially. The descriptions of order or flowcharts herein do not preclude changes or modifications to the method or algorithm, nor do they imply that any particular step is essential or preferred. In one embodiment, at least some steps may be performed in parallel, iteratively, or heuristically. In one embodiment, at least some steps may be omitted, and other steps may be added.

[0240] Various embodiments of the content disclosed herein may be embodied as software on a machine-readable storage medium. The software may be software for embodying the various embodiments described herein. The software can be inferred from the various embodiments described herein by a programmer in the art to which the content disclosed herein belongs. For example, the software may be a program containing instructions (e.g., code or code segment) that the machine can read. The machine is a device that can operate by instructions called from the storage medium, and may be, for example, a computer. In one embodiment, the machine may be a computing device according to the various embodiments described herein. In one embodiment, the processor of the machine can execute a called instruction and cause the components of the machine to perform the function corresponding to this instruction. The storage medium can mean any kind of recording medium on which data is stored and is readable by the machine. The storage medium may include, for example, ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. In one embodiment, the storage medium may be implemented in a distributed form, such as a network-connected computer system. The software may be stored and executed in a distributed manner on the computer system. The storage medium may be a non-transitory storage medium. A non-transitory storage medium means a tangible medium that exists regardless of whether the data is stored semi-permanently or temporarily, and does not include signals that are transmitted transiently.

[0241] The technical ideas of the content disclosed herein have been explained through various embodiments, but the technical ideas of the content disclosed herein include various substitutions, modifications and alterations that can be understood by a person with ordinary skill in the art to which the content disclosed herein pertains. Furthermore, such substitutions, modifications and alterations should be understood to be included within the scope of the attached claims.

Claims

1. The process includes the steps of: a processor connected to a computer network including a blockchain network receiving a transaction from a first terminal that has received a unique number for a product, requesting the minting of a non-fungible token corresponding to the product; A method comprising the step of the processor executing a smart contract in response to the receipt of the transaction, The step of executing the aforementioned smart contract is: The steps include verifying the transaction, which includes a zero-knowledge proof of the unique number corresponding to the unique number for the said product, The steps include verifying the zero-knowledge proof value of the aforementioned unique number, The step of distributing the non-fungible token to the blockchain network based on the verification result of the zero-knowledge proof value of the unique number, method.

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

3. The zero-knowledge proof value of the unique number is generated based on at least one of the unique number, the hash value of the unique number, or the providing key. The verification key is determined based on the hash value of the unique number (verifying It is generated in pairs with the key. The method according to claim 1.

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

5. The transaction further includes the hash value of the unique number, Prior to the stage of distributing the aforementioned non-fungible tokens to the blockchain network, To prevent the double issuance of non-fungible tokens for the aforementioned unique number, the process further includes the step of invalidating the hash value of the aforementioned unique number. The method according to claim 1.

6. The aforementioned transaction further includes the recipient address, The step of distributing the non-fungible tokens to the blockchain network is: The process includes, if the verification of the zero-knowledge proof value of the unique number is successful, minting the non-fungible token to the recipient address, The method according to claim 1.

7. The aforementioned smart contract is This includes the first Merkle root of the first Merkle tree, which is obtained by hashing multiple unique numbers generated by the second terminal of the company selling the product. The method according to claim 1.

8. The transaction further includes the hash value of the unique number, The step of verifying the aforementioned transaction is: This includes the step of verifying the hash value of the unique number based on the first Merkle certification value included in the smart contract, The method according to claim 1.

9. The aforementioned smart contract is A third terminal that transmits the unique number for the product to the first terminal via at least one of NFC or QR code (registered trademark), including a public key that is symmetrical to a personal key stored in the third terminal, The method according to claim 1.

10. The aforementioned unique number is an arbitrary value (Random Value) generated by the third terminal. The aforementioned transaction, The data further includes the hash value of the unique number and the signed data obtained by signing the hash value of the unique number with the personal key. The method according to claim 9.

11. The step of verifying the aforementioned transaction is: This includes a step of verifying the signature data with the public key stored in the transaction, The method according to claim 9.

12. The aforementioned smart contract is The second Merkle root of the second Merkle tree obtained by hashing the user identification information of the first terminal further includes, The aforementioned transaction, The data further includes the hash value of the unique number, the hash value of the unique number signed with the personal key, and the second Merkle proof value based on the second Merkle tree. The method according to claim 9.

13. The step of verifying the aforementioned transaction is: The steps include verifying the aforementioned signature data with the public key stored in the transaction, The step includes verifying the user identification information based on evidence of the second Merkle route and the user identification information of the first terminal, The method according to claim 12.

14. If 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 of the unique number, the step of executing the smart contract is: The processor executes the first smart contract, thereby requesting the second smart contract to verify the transaction. The step includes the step in which the processor executes the second smart contract in response to a transaction verification request, The stage of executing the aforementioned second smart contract is: The step of verifying the aforementioned transaction, The step includes verifying the zero-knowledge proof value of the unique number based on the verification result of the transaction, The method according to claim 1.

15. The step of distributing the non-fungible tokens to the blockchain network is: The processor executes the first smart contract, which includes the step of distributing the non-fungible tokens to the blockchain network based on the verification result of the zero-knowledge proof of the unique number, The method according to claim 14.

16. If the smart contract includes a first smart contract for receiving the transaction, a second smart contract for verifying the transaction, and a third smart contract for verifying the zero-knowledge proof of the unique number, the step of executing the smart contract is: The processor executes the first smart contract, thereby requesting the second smart contract to verify the transaction. The processor executes the second smart contract to verify the transaction, and based on the success of the transaction verification, requests the third smart contract to perform zero-knowledge proof verification of the unique number. The processor executes the third smart contract to verify the zero-knowledge proof value of the unique number and transmits the verification result to the second smart contract, The method according to claim 1.

17. The step of distributing the non-fungible tokens to the blockchain network is: The processor executes the first smart contract, which includes the step of distributing the non-fungible tokens to the blockchain network based on the verification result of the zero-knowledge proof of the unique number, The method according to claim 16.

18. If the smart contract includes a first smart contract for receiving the transaction, a second smart contract for verifying the transaction, a third smart contract for verifying the zero-knowledge proof of the unique number, and a fourth smart contract for verifying the user identification information of the first terminal, the step of executing the smart contract is: The processor executes the first smart contract, thereby requesting the second smart contract to verify the transaction. The processor executes the second smart contract to verify the transaction, requests the third smart contract to verify the zero-knowledge proof value of the unique number based on the transaction verification result, and requests the fourth smart contract to verify the user identification information. The processor executes the third smart contract, verifies the hash value of the unique number, and transmits the verification result to the second smart contract. The processor executes the fourth smart contract, and the step of verifying the user identification information is determined by determining whether the second Merkle root included in the fourth smart contract matches the Merkle root obtained based on the hash value of the user identification information of the first terminal and the second Merkle proof value. The method according to claim 1.

19. The step of distributing the non-fungible tokens to the blockchain network is: The processor executes the first smart contract, which includes the step of distributing the non-fungible tokens to the blockchain network based on the verification result of the zero-knowledge proof value of the unique number and the verification result of the user identification information, The method according to claim 18.

Images