KR102294571B1 - Permissioned Block Chain System for Supporting Non Fungible Token - Google Patents

Abstract

A permission-type blockchain system supporting a non-fungible token according to an aspect of the present invention that can support a non-fungible token is a non-fungible token ( and at least one peer server that generates a Non-Fungible Token), wherein the peer server calls a token issuance function when the issuance of a non-fungible token for a specific object is requested through a decentralized application (dApp). a token management unit that issues a non-fungible token having a data structure consisting of basic attributes including , token type, and owner, and extended attributes set for each token type; and a database in which the current state of the issued non-fungible token is recorded.

Description

Permissioned Block Chain System for Supporting Non Fungible Token

The present invention relates to a blockchain, and more particularly, to a permissioned blockchain.

Blockchain (Block Chain) is a distributed ledger-based peer-to-peer (P2P) system that can execute smart contracts. Blockchain technology is generally used to record transactions of digital assets.

In general, in blockchain, digital assets are managed in the form of tokens, which are applications implemented as smart contracts. In this way, tokenizing and managing digital assets in a blockchain has advantages such as immutability, quick access, or high liquidity.

Tokens are broadly classified into fungible tokens and non-fungible tokens. Fungible tokens can be exchanged with other tokens of the same type, but non-fungible tokens cannot be exchanged for other tokens of the same type.

The above-mentioned block chain uses a standardized token protocol for interoperability. Ethereum, one of the public block chains that anyone can participate in, is non-fungible with the standard token protocol for interchangeable tokens for interoperability. A standard token protocol exists for tokens.

On the other hand, in a permissioned blockchain where only authorized users can participate, discussion and development of a framework to support a replaceable token is in progress, but about a framework to support a non-fungible token Discussion is taking place, but its design and development have not been made public.

Due to this, in the permission-type blockchain, it is difficult to capitalize the unique object itself, and there is a problem that the transaction of the unique object is impossible.

The present invention is to solve the above-mentioned problems, and its technical task is to provide a permission-type blockchain system that can support non-fungible tokens.

Another technical task of the present invention is to provide a scalable permissioned blockchain system to support various types of non-fungible tokens.

A permission-type blockchain system supporting a non-fungible token according to an aspect of the present invention for achieving the above object is a non-fungible token ( and at least one peer server that generates a Non-Fungible Token), wherein the peer server calls a token issuance function when the issuance of a non-fungible token for a specific object is requested through a decentralized application (dApp). a token management unit that issues a non-fungible token having a data structure consisting of basic attributes including , token type, and owner, and extended attributes set for each token type; and a database in which the current state of the issued non-fungible token is recorded.

As described above, according to the present invention, the non-fungible token can be issued and managed in the permission-type blockchain system through the framework including the data structure and protocol of the non-fungible token, so that uniqueness can be achieved even in the permission-type blockchain system. It has the effect of being able to trade objects that you have as digital assets.

In addition, according to the present invention, a new type of non-fungible token can be issued through an extensible data structure and protocol, thereby maximizing the scope of application of the permission-type blockchain system.

1 is a diagram showing the configuration of a permission-type blockchain system supporting non-fungible tokens according to an embodiment of the present invention.
2A is a diagram showing a data structure of a non-fungible token according to the present invention.
2B is a diagram showing functions defined in a protocol of a non-fungible token according to the present invention.
3 is a diagram showing the configuration of the smart contract execution unit shown in FIG.
4A is a diagram showing a data structure of a non-fungible token when the token type is a contract.
4B is a diagram showing a data structure of a non-fungible token when the token type is a sound source.

Like reference numerals refer to substantially identical elements throughout. In the following description, detailed descriptions of configurations and functions known in the art and cases not related to the core configuration of the present invention may be omitted. The meaning of the terms described herein should be understood as follows.

Advantages and features of the present invention and methods of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be embodied in various different forms, only these embodiments allow the disclosure of the present invention to be complete, and common knowledge in the technical field to which the present invention belongs It is provided to fully inform the possessor of the scope of the invention, and the present invention is only defined by the scope of the claims.

The shapes, sizes, proportions, angles, numbers, etc. disclosed in the drawings for explaining the embodiments of the present invention are exemplary, and thus the present invention is not limited to the illustrated matters. Like reference numerals refer to like elements throughout. In addition, in describing the present invention, if it is determined that a detailed description of a related known technology may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

When 'including', 'having', 'consisting', etc. mentioned in this specification are used, other parts may be added unless 'only' is used. When a component is expressed in the singular, the case in which the plural is included is included unless otherwise explicitly stated.

In interpreting the components, it is interpreted as including an error range even if there is no separate explicit description.

In the case of a description of the positional relationship, for example, when the positional relationship of two parts is described as 'on', 'on', 'on', 'beside', etc., 'right' Alternatively, one or more other parts may be positioned between the two parts unless 'directly' is used.

In the case of a description of a temporal relationship, for example, 'immediately' or 'directly' when a temporal relationship is described with 'after', 'following', 'after', 'before', etc. It may include cases that are not continuous unless this is used.

Although the first, second, etc. are used to describe various components, these components are not limited by these terms. These terms are only used to distinguish one component from another. Accordingly, the first component mentioned below may be the second component within the spirit of the present invention.

The term “at least one” should be understood to include all possible combinations from one or more related items. For example, the meaning of “at least one of the first, second, and third items” means each of the first, second, or third items as well as two of the first, second and third items. It may mean a combination of all items that can be presented from more than one.

Each feature of the various embodiments of the present invention may be partially or wholly combined or combined with each other, technically various interlocking and driving are possible, and each of the embodiments may be implemented independently of each other or may be implemented together in a related relationship. may be

Hereinafter, an embodiment according to the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram showing the configuration of a permission-type blockchain system supporting non-fungible tokens according to an embodiment of the present invention.

As shown in FIG. 1 , a permissioned blockchain system (hereinafter referred to as a 'blockchain system') supporting a non-fungible token according to an embodiment of the present invention (hereinafter referred to as a 'blockchain system') includes at least one peer and a terminal 125 on which a decentralized application (Decentralized Application: dApp, 120, hereinafter referred to as 'dApp') interworking with the servers 110a to 110n and at least one peer server 110a to 110n is mounted.

Each peer server 110a to 110n generates a non-fungible token for an object with uniqueness on the blockchain, and manages the generated token on the blockchain. A non-fungible token is a digital asset of a unique object, and since the object has uniqueness, it is impossible to exchange with other tokens of the same type.

In this case, the block chain used by each of the peer servers 110a to 110n may be a permission block chain that can only be used by previously authorized users. Accordingly, although not shown in FIG. 1, the blockchain system 100 according to the present invention can manage users who can participate in the blockchain network by issuing a certificate through a separate authentication center.

In one embodiment, the block chain according to the present invention may be a block chain having a Hyperledger Fabric architecture, which is one of permission block chains, and blocks only for users subscribed to the Membership Service. Participation and transaction can be generated in the chain network.

As shown in FIG. 1, each peer server (110a to 110n) executes smart contracts (Smart Contracts, 112a to 112n) mounted on each peer server (110a to 110n) to generate and manage non-fungible tokens. can In one embodiment, when the blockchain according to the present invention is implemented as a Hyperledger Fabric architecture, a smart contract may be implemented as a chaincode.

According to this embodiment, the smart contracts 112a to 112n mounted on each of the peer servers 110a to 110n are the dApp 120 through the SDK (Software Development Kit, not shown) included in the dApp 120 . is connected to At this time, the SDK connects the dApp 120 to the smart contracts 112a to 112n, and creates a transaction to call the function corresponding to the user's request for the generation and management of non-fungible tokens to create the smart contracts 112a to 112a. 112n). To this end, in the present invention, the functions implemented in the SDK and the functions implemented in the smart contracts 112a to 112n are mapped 1:1.

Each peer server 110a to 110n is a database in which execution results of smart contract execution units 114a to 114n and smart contracts 112a to 112n that execute smart contracts 112a to 112n as shown in FIG. 1 are recorded. (116a-116n).

Since the functions of the smart contracts 112a to 112n, the smart contract execution units 114a to 114n, and the databases 116a to 116n installed in each peer server 110a to 110n are the same, below, the n-th peer server 110n The function will be described based on the n-th smart contract 112n, the n-th smart contract execution unit 114n, and the n-th database 116n installed in the .

Hereinafter, for convenience of explanation, the n-th peer server 110n, the n-th smart contract 112n, the n-th smart contract execution unit 114n, and the n-th database 116n are the peer server 110, the smart contract ( 112), the smart contract execution unit 114, and the database 116 will be described.

The smart contract execution unit 114 issues and manages non-fungible tokens on the blockchain using functions called by the dApp 120 according to the user's request.

In one embodiment, the non-fungible token issued by the smart contract execution unit 114 according to the present invention has a data structure as shown in Fig. 2A and uses functions defined in the protocol as shown in Fig. 2B. to issue and manage non-fungible tokens.

Specifically, as shown in Fig. 2a, the data structure of the non-fungible token according to the present invention is composed of a basic attribute and an extended attribute. The basic attribute may include at least one of a token identifier (ID), a token type (Type), a token owner (Owner), an operator (Operator), and an approver (Approvee). Among these basic properties, token identifier (ID), token type (Type), and owner (Owner) are essential basic properties that all tokens have in common, and Operator and Approvee are optional according to the owner’s choice. Corresponds to the selection default attribute that can be specified.

The extended attribute includes at least one of an on-chain extended attribute (xattr: eXtended attribute) and an off-chain extended attribute (uri: universal resource identifier). The on-chain extended attribute (xattr) is an extended attribute set according to the token type, and includes sub-attributes to be managed in the block chain for each token type.

Off-chain extended attributes (uri) are for linking off-chain storage with non-fungible tokens when managing attributes that do not need to be managed on-chain through the dApp 120 on-chain. It includes the path information (path) where the corresponding object is stored and the hash information (hash) of the Merkle of the Merkle Tree for the metadata of the corresponding object.

Meanwhile, the functions defined in the protocol for issuing and managing non-fungible tokens according to the present invention include a token management function, a user management function, and a token type management function, as shown in FIG. 2B.

In one embodiment, the token management function is a function used to manage and manage tokens. A token issuance function (mint) that issues a token, a token deletion function (burn) that deletes a previously registered token, and a token of a specific token Token type inquiry function (getType) to inquire the type, token number inquiry function (balanceOf) to inquire the number of owned tokens, token transaction function (transferFrom) to change the owner according to the token transaction, included in the off-chain extended attribute of a specific token Off-chain extended attribute update function (setURI) that updates the sub-attribute value of a specific token, off-chain extended attribute inquiry function (getURI) that inquires the sub-attribute value included in the off-chain extended attribute of a specific token, on-chain extended attribute of a specific token The on-chain extended attribute update function (setXAttr) that updates the sub-attribute value included in the on-chain extended attribute search function (getXAttr) that inquires the sub-attribute value included in the on-chain extended attribute of a specific token Token split function (divide) that divides into tokens, token identifier list inquiry function (tokenIdsOf) that inquires token identifier list of owned tokens, token deactivation function (deactivate) that deactivates tokens, token attribute inquiry function that inquires all properties of tokens (query), and a token modification history inquiry function (queryHistory) for inquiring the modification history of the token may include at least one.

The user management function is a function used to manage an operator for a specific owner or to manage an approver for a specific token. In the permission-type blockchain system according to the present invention, a user may be largely composed of an owner, an operator, and an authorized person.

An owner means a user who has ownership of a specific token, and the owner has all rights to a specific token. Therefore, only one owner can exist for one token. Changing the owner of the token may be performed through token transaction using the above-described token transaction function.

An operator means a user who can manage all tokens of the owner, and can be set by the owner. For example, if owner A sets B as his operator for him, B will have the authority to manage all tokens owned by A. A plurality of operators may be set for one owner.

An approver refers to a user who can manage a specific token, and may be set by an owner or operator. For example, if owner A sets C as an approver with respect to token 1 among tokens owned by owner A, C has the authority to manage token 1 among tokens owned by A. A maximum of one approver can be set for one token.

According to the present invention, the user management function inquires the owner inquiry function (ownerOf) for inquiring the owner of a specific token, the approver setting function (approve) for setting the approveee for the specific token, and the approveee set for the specific token Includes at least one of a function to inquire about an approved person (getApproved), a function to add or delete an operator for a specific owner (setApprovalFolAll), and a function to query whether an operator is an operator for a specific owner (isApprovedForAll) can do.

The token type management function is for registering a token type or managing a previously registered token type. , sub-attribute map update function that updates the sub-attribute map included in the on-chain extended attribute of token type (updateTokenType), and the sub-attribute map search function that retrieves the sub-attribute map included in the on-chain extended attribute of token type (retrieveTokenType) , the token type deletion function (dropTokenType) that deletes the token type, the sub-attribute registration function (enrollAttributeOfTokenType) that registers a new sub-attribute to be included in the on-chain extended attribute of the token type, and the sub-attribute included in the on-chain extended attribute of the token type. The sub-attribute update function (updateAttributeOfTokenType) for updating the data type and initial value, the sub-attribute inquiry function (retrieveAttributeOfTokenType) for inquiring the data type and initial value of the sub-attribute included in the on-chain extended attribute of the token type (retrieveAttributeOfTokenType), and the token type It may include at least one of a sub-attribute drop function (dropAttributeTokenType) that deletes a sub-attribute included in the chain extended attribute.

As described above, according to the present invention, when a specific object is digitized as a non-fungible token on the Internet, transaction of the corresponding object as well as authenticity verification, proof of ownership, and copyright tracking can be performed. In this case, the digitized object includes tangible and intangible objects, and may include books, music, and the like.

Hereinafter, the configuration of the smart contract execution unit 114 according to the present invention that issues and manages the non-fungible token having the data structure shown in FIG. 2A using the protocol shown in FIG. 2B will be described in more detail with reference to FIG. 3 . Explain.

3 is a block diagram showing the configuration of a smart contract execution unit according to an embodiment of the present invention. As shown in FIG. 3 , the smart contract execution unit 114 according to an embodiment of the present invention includes a token management unit 310 , a user management unit 320 , a token transaction unit 330 , and a token type management unit 340 . includes

The token management unit 310 issues a non-fungible token for a specific object having uniqueness, and manages the previously issued non-fungible token. Specifically, when a token issuance request for a specific object is received through the dApp 120 , the token management unit 310 calls a token issuance function in the protocol shown in FIG. 2b and uses the parameters included in the token issuance request to be smart By executing the contract 112, it issues a non-fungible token having a data structure as shown in Fig. 2a. When the token issuance is completed, the token management unit 310 registers the current state of the issued token in the database 116 .

In this case, the token issuance request may include a token identifier, token type, owner, on-chain extended attribute, and off-chain extended attribute as parameters. At this time, the token type that can be included in the token issuance request must be one of the token types previously registered on the block chain by the token type management unit 340 . All sub-properties (sub-property maps) included in the on-chain extended properties defined according to the token type must be included as parameters for the on-chain extended properties, and the off-chain extended properties include path information included in the off-chain extended properties. and hash information.

When the token issuance is successfully completed, the token management unit 310 registers information on the issued token in the database 116 .

For example, when the token type is “contract”, as shown in FIG. 4A , the token management unit 310 includes a token identifier (id), a token type (type), an owner, and an operator as basic properties. , and an on-chain having the hash value of the contract file, signers, signatures, number of contract pages, and contract date as sub-attributes as extended attributes A token with extended attributes and off-chain extended attributes including the path information (path) and hash information (hash) where the contract file or signature image is stored in the off-chain storage can be created.

As such, according to the present invention, since documents such as contracts can be generated as non-fungible tokens, the permission-type blockchain system 100 according to the present invention can be applied to a business document signing service. In this case, it is possible to provide a distributed signature service or a decentralized signature service, so that contract work can be performed more easily and quickly than paper contracts through e-mail or SNS (Social Network System) without face-to-face between contractors.

As another example, when the token type is “sound source”, as shown in FIG. 4B , the token management unit 310 includes a token identifier (id), a token type (type), an owner, an operator, and a token identifier (id) as basic properties. And with an approvee, serve as an extended attribute the hash value of the MP3 file corresponding to the sound source, the singers of the sound source, the arrangers of the sound source, and the lyricists of the sound source. It is possible to create a token having on-chain extended attributes as attributes and off-chain extended attributes including path information (path) and hash information (hash).

The token management unit 310 returns true to the dApp 120 when the token issuance is successfully completed, and returns false when the token issuance fails.

On the other hand, when a token management request for a token issued through the dApp 120 is received, the token management unit 310 according to the present invention calls a function for processing the request in the protocol shown in FIG. 2B to manage the token. The corresponding token is managed by executing the smart contract 112 using the parameters included in the request. When the token management is completed, the token management unit 310 registers the current state of the corresponding token in the database 116 .

For example, the token management unit 310 processes the request by calling the token deletion function when deletion of a previously registered token is requested. to process At this time, the number of tokens means the number of activated tokens. If the token type is included in the request as a parameter, the token management unit 310 determines the number of tokens corresponding to the corresponding token type owned by the owner. The number is returned, and if the token type is included as a parameter (eg, "-") in a predetermined form, the token management unit 310 returns the number of all tokens owned by the corresponding owner.

In addition, when the update of the sub-attribute value included in the off-chain extended attribute of a specific token is requested, the token management unit 310 processes the request by calling the off-chain extended attribute update function, and sets the off-chain extended attribute of the specific token. When an inquiry of the included sub-attribute value is requested, the request is processed by calling the off-chain extended attribute inquiry function. The request is processed by calling, and when the sub-attribute value included in the on-chain extended attribute of a specific token is requested, the on-chain extended attribute inquiry function is called to process the request.

In addition, the token management unit 310 processes the request by calling the token identifier list inquiry function when the inquiry of the token identifier list of the owned token is requested. In addition, when a query of all properties of a specific token is requested, the request is processed by calling the token property search function.

Meanwhile, the token management unit 310 according to the present invention may divide one non-fungible token that has been previously issued into a plurality of non-fungible tokens. For example, if a non-fungible token is issued for one steel product, if the steel product is divided into two products, the non-fungible token issued for the steel product before the division becomes the parent token, and the parent token is divided By doing so, two child tokens are issued for the two steel products after the split.

Specifically, when a token split request is received through the dApp 120, the token manager 310 calls a token split function among the protocol shown in FIG. By executing it, a plurality of child tokens with the token to be split as the parent token is issued.

In this case, the token split request may include, as parameters, a token identifier of a parent token to be split, token identifiers of a newly created child token, a name of a sub-attribute serving as a split-start point, and a value of the sub-attribute. Accordingly, the sub-property included in the token split request becomes the starting point for splitting the parent token into child tokens, and the identifiers of newly generated child tokens are added to the child properties included in the on-chain extended property of the parent token. and the activation property included in the on-chain extended property becomes false, and the parent token is deactivated. On the other hand, in the case of newly issued child tokens, the value of the sub-attribute that became the starting point of division is set as the sub-attribute value included in the token split request, and the identifier of the parent token is recorded in the parent attribute included in the on-chain extended attribute. do. Among the properties of the child token, the rest of the properties inherit the properties of the parent token.

When an inquiry for the owner of a specific token is requested through the dApp 120, the user management unit 320 processes the request by calling the owner inquiry function. to process the request, and when an inquiry of the approved person set for a specific token is requested, the request is processed by calling the approver inquiry function. In addition, when an operator addition or deletion for a specific owner is requested through the dApp 120 , the user management unit 220 processes the request by calling the operator addition and deletion functions, and when an operator inquiry for a specific owner is requested, the operator inquiry Process the request by calling the function.

When a change occurs in the data structure of the token due to processing of each request, the user management unit 320 records the changed data structure for the corresponding token in the database 116 .

When a transaction for a specific token is requested through the dApp 120, the token transaction unit 330 calls the token transaction function when the transaction conditions set for the transaction of the corresponding token are completed, thereby transferring the owner of the corresponding token to the assignee. change to In this case, the token transaction function may be called by any one of a token owner, an operator, and an authorized person.

The token type management unit 340 registers a new token type for a new object or manages a previously registered token type. Specifically, when the registration of a new token type is requested through the dApp 120, the token type management unit 340 calls the token type registration function of the protocol shown in FIG. 2B and uses the parameters included in the token type registration request. By executing the smart contract 112, a new token type is registered on the block chain.

In this case, the token type registration request may include, as parameters, a token type manager requesting registration of a new token type, a name of a new token type to be registered, and a sub-attribute map of on-chain extended properties to be set according to the new token type. . In this case, the sub-attribute map may be composed of a name of each sub-attribute, a data type of each sub-attribute, and an initial value of each sub-attribute.

The token type management unit 340 registers a new token type on the block chain by adding basic sub-properties commonly set to all token types in addition to the parameters included in the token type registration request. In this case, the basic sub-properties may include identification information of an administrator requesting token type registration, parent properties, child properties, and activation properties.

As described above, according to the present invention, since a token type corresponding to a new object can be newly registered through the token type management unit 340, the scope of application of the permission-type block chain system can be expanded.

Meanwhile, the token type management unit 340 according to the present invention may manage a pre-registered token type according to the request of the dApp 120 . Specifically, when a token type inquiry of a specific token is requested from the dApp 120 , the token type management unit 340 processes the request by calling a token type inquiry function, and when a token type list inquiry is requested, the token type list inquiry function to process the request.

In addition, when the dApp 120 requests to update the sub-attribute map included in the on-chain extended attribute of the token type, the token type management unit 340 calls the sub-attribute map update function to process the request, and When the query of the sub-property map included in the chain extended property is requested, the request is processed by calling the sub-property map search function. When registration of a new sub-attribute is requested in the on-chain extended attribute of , the sub-attribute registration function is called to process the request.

In addition, when a request for updating the data type and initial value of the sub-attribute included in the on-chain extended attribute of the token type from the dApp 120 is requested, the token type manager 340 calls the sub-attribute update function to process the request, and the token When a query of the data type and initial value of a sub-property included in the on-chain extended property of the type is requested, the request is processed by calling the sub-property search function, and the deletion of the sub-property included in the on-chain extended property of the token type is not possible. If requested, the request can be processed by calling the extended attribute deletion function.

Referring back to FIG. 1 , the dApp 120 performs authentication for the user through interworking with the authentication center, and when generation and management of a non-fungible token is requested from the authenticated user, the request is made through the SDK included therein. Creates a transaction for , and transmits it to the smart contract execution units 114a to 114n of each peer server 110a to 110n. At this time, as described above, the function used by the SDK to generate a transaction is mapped 1:1 with the function used in the smart contracts 112a to 112n.

The terminal 125 is installed with the dApp 120, and includes a smartphone, a tablet personal computer, a mobile phone, a netbook computer, an MP3 player, a camera, and at least one of various wearable devices.

In another embodiment, the terminal 125 may be a smart home appliance having a communication function. The smart home appliance may include at least one of a television, a DVD (Digital Video Disk) player, smart lighting, audio, refrigerator, air conditioner, vacuum cleaner, oven, microwave oven, washing machine, air purifier, set-top box, game console, or door lock. can

Those skilled in the art to which the present invention pertains will understand that the above-described present invention may be embodied in other specific forms without changing the technical spirit or essential characteristics thereof.

Therefore, it should be understood that the embodiments described above are illustrative in all respects and not restrictive. The scope of the present invention is indicated by the following claims rather than the above detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalent concepts should be interpreted as being included in the scope of the present invention. do.

100: permissioned blockchain system 110a~110n: peer server
112a~112n: smart contract 114a~114n: smart contract execution unit
116a~116n: Database 120: dApp
310: token management unit 320: user management unit
330: token transaction unit 340: token type management unit

Claims (11)

It includes at least one peer server that generates a non-fungible token for an object with uniqueness on a block chain using a smart contract,
The peer server,
When the issuance of a non-fungible token for a specific object is requested through a decentralized application (dApp), the token issuance function is called and the basic properties including the token identifier, token type, and owner and extended properties set for each token type are used. a token management unit that issues a non-fungible token having a configured data structure; and
Including a database in which the current state (State) of the issued non-fungible token is recorded,
The extended attributes include on-chain extended attributes registered on the block chain and off-chain extended attributes stored in off-chain storage,
The on-chain extended attribute includes at least one predetermined sub-attribute to be managed on the blockchain for each token type. delete According to claim 1,
The off-chain property includes path information on the path where the object is stored in the off-chain storage and hash information of the Merkle root of the Merkle tree for the metadata of the object. Permission to support a non-fungible token type blockchain system. According to claim 1,
The peer server,
When registration of a new token type for a new object is requested through the decentralized application, a token type registration function is called to match the name of the new token type with the extension properties required according to the new token type on the block chain. Permission-type blockchain system supporting non-fungible tokens, characterized in that it further comprises a token type management unit that registers a new token type. 5. The method of claim 4,
The token type management unit,
Through the decentralized application, a request for a list of token types, a request to update the sub-attribute map included in the on-chain extended attribute of the token type, a request to query the sub-attribute map included in the on-chain extended attribute of the token type, and the token type Delete request, new sub-property registration request to be included in on-chain extended attribute of token type, data type and initial value update request of sub-attribute included in on-chain extended attribute of token type, sub included in on-chain extended attribute of token type When a token type management request including at least one of a data type and initial value inquiry request of an attribute, and a request to delete a sub attribute included in the on-chain extended attribute of the token type is received, a token type management function corresponding to each request is received A permissioned blockchain system that supports non-fungible tokens, characterized by calling and processing the request. According to claim 1,
The peer server,
When a user management request including an operator management request for a specific owner or an approved person management request for a specific token is received through the decentralized application, it further comprises a user management unit that calls a user management function to process the request A permissioned blockchain system that supports non-fungible tokens. 7. The method of claim 6,
The user management request includes an owner inquiry request for a specific token, an operator addition or deletion request for a specific owner, an operator status inquiry request for a specific owner, an approved person setting request for a specific token, and an approved person inquiry request set for a specific token A permissioned blockchain system that supports non-fungible tokens, characterized in that it includes at least one of. According to claim 1,
The peer server,
When a transaction request for a specific token is received through the decentralized application, a token transaction that calls a token transaction function when the conditions for the transaction of the specific token are established and updates the owner of the specific token as an assignee in the data structure of the specific token A permissioned blockchain system supporting non-fungible tokens, characterized in that it further comprises wealth. According to claim 1,
The token management unit,
When a request for splitting a specific token is received through the decentralized application, a plurality of child tokens inheriting at least some of the properties included in the data structure of the parent token by calling a token splitting function and using the specific token as a parent token A permission-type blockchain system that supports non-fungible tokens, characterized in that they are issued and the parent token is deactivated. According to claim 1,
The token management unit,
A request to delete a token already registered from the decentralized application, a token type inquiry request to inquire the token type of a specific token, a request to inquire the number of tokens owned by a specific owner, update sub-attribute values included in the off-chain extended attribute of a specific token Request, request to inquire sub-attribute value included in off-chain extended attribute of a specific token, request to update sub-attribute value included in on-chain extended attribute of specific token, request to inquire sub-attribute value included in on-chain extended attribute of specific token, When a token management request including at least one of a token identifier list inquiry request, token deactivation request, token attribute inquiry request, and token modification history inquiry request is received, a token corresponding to each request is received A permission-type blockchain system that supports non-fungible tokens, characterized in that the corresponding token is managed by calling a management function. According to claim 1,
The block chain is a permissioned block chain system supporting non-fungible tokens, characterized in that it is a Hyperledger Fabric architecture in which only access of users subscribed to the membership service is permitted.

Images