A glimpse into the future of NFT from the upcoming EIP proposal
Original title: "A glimpse into the future of NFT from the upcoming EIP proposal"
Original author: zf857.eth
Original source: R3PO< /blockquote>
The full name of EIP is Ethereum Improvement Proposals, and anyone in the Ethereum community can create an EIP. Guidelines for writing Ethereum Improvement Proposals are provided in EIP-1. Creators of Ethereum improvement proposals are responsible for building consensus within the community and recording dissent. Historically, the creators of most Ethereum improvement proposals are usually application or protocol developers, because submitting high-level Ethereum improvement proposals requires strong technical capabilities, and the EIP will be given a serial number after the initial review. And discuss through the review process shown in the figure below.
< /p>There are many types of EIP, including Core, Networking, Interface, ERC, Meta, and Informational. Each type solves different problems. We are familiar with ERC-20, ERC-721, ERC- 1155 is an application-level standard protocol. At present, most of the NFT industry applications are developed around these mainstream protocols. EIP is like a chronicle of Ethereum, which records all the developments since its birth, and also has the ability to foresee the direction of the entire Ethereum ecosystem. Seeing the small things, an EIP change may contain a huge opportunity to overturn the entire industry . This article will focus on the EIP proposals related to NFT and in the Last call and recent Final stages.
EIP-4955 Metadata Standard Extension
This EIP proposes to standardize the schema of NFT metadata (metadata), adding a new field namespace (namespaces) to the JSON schema of EIP-721 and EIP-1155 standard NFT. The main code is shown below:
EIP-4955 uses a direct extension of EIP-721 metadata, the idea behind it is for backward compatibility. Enables existing projects that cannot modify the metadata response (schema) to create a new smart contract that returns an updated metadata schema based on the tokenId. Given that most projects on Ethereum use non-upgradeable contracts. If this EIP requires a new implementation of these contracts, it must be redeployed. This is a waste of time and money. By utilizing the existing metadata fields of EIP-721, the number of necessary changes can be minimized.
There are many projects that require custom NFT properties. Each item may have its own way of rendering NFTs, so they require different metadata values. For example Metaverse projects like Decentraland or TheSandbox, they need different 3D models to render NFTs, based on the vision/engine of each project. NFTs projects like Cryptopunks, Bored Apes, etc. can create the 3d models needed for each project.
< /p>With the new field namespaces (namespaces), each project party or supplier can directly call NFT assets through namespaces (as shown in the code above), which will allow developers to create in a single smart contract or application Avoid naming conflicts when using multiple NFT metadata in a program. And the metadata of the NFT will allow NFT-related applications such as wallets, marketplaces, and metaverses to interoperate with any NFT. This proposal is useful for NFT marketplaces that need to support multiple metadata schemas. Even if multiple sellers use different metadata schemas, this EIP will allow market operators to ensure that metadata keys are unique while freely storing specific JSON data. The proposed solution can even have wider applications, such as large Gamefi and a large number of NFTs in the Metaverse can present different attributes through custom metadata, and at the same time avoid naming conflicts, greatly improving the interoperability of NFTs .
NFT lease usage extension from EIP-4907 to EIP-5006
EIP-5006 This proposal is proposed by the NFT leasing market Double Protocol for the lease standard of ERC-1155 NFT. This standard is An extension to the ERC-1155 standard. The proposal proposes an additional new field user (user) in the NFT metadata, which can be granted an address (owner) representing the asset user (user) instead of the owner.
As early as June 29 last year, the EIP- 4907 officially passed the Ethereum audit and became the first ERC standard for leasing NFT. As an extension of ERC-721, EIP-4907 adds a user information (UserInfo) variable, which includes the user (User) address and "lease expiration time (userExpires)". When the time exceeds the lease time, the lease relationship is terminated. The main code is shown below:
Different from the simple extension of EIP-4907 to ERC-721, EIP-5006 is based on the special data structure of ERC-1155 (ERC-1155 itself is a multiple Token management standard , its ID can correspond to multiple addresses and the number of tokens), adding the Userrecord and usableBalance functions, which can conveniently manage the lease status in batches. The main code is shown below:
EIP The core value of -4907 and EIP-5006 standards
Whether it is ERC-721 or ERC-1155 Standard Tokens require such a new utility. That is, the person who "uses" the token may be different from the person who owns the token (as in leasing). Therefore, it is necessary to have different roles for "owners" and "users", so that "users" cannot take actions that owners can (for example, transfer ownership).
The proposal of EIP4907 and EIP-5006 clarifies the distribution of NFT rights, which is conducive to solving the shortage of NFT liquidity. With the dual roles of "owner" and "user", the separation of ownership and usage rights of NFT can be realized. This is the key infrastructure to solve the problem of NFT liquidity shortage, and it provides some on-chain usage scenarios such as leasing technical support. Makes it very easy to manage what NFT lenders and borrowers can and cannot do with NFTs (in other words, their rights). For example, for the right to transfer ownership, the project only needs to check whether the address taking the action is an address representing the owner (owner) or a user (user), and if it is a user (user), block the transaction. Additionally, owners can control who users are, and it is easy for other projects to assign their own stake explicitly to owners or users.
At the same time, on the basis of license-free interoperability, the standard enables third-party Protocols make it easier to manage the usage rights of NFTs without requiring permission from NFT issuers or NFT applications. Once a project adopts additional user roles, any other project can directly interact with these functions and implement their own transaction types. For example, PFP-type NFTs using this standard can be integrated into a leasing platform where users can rent NFTs for 30 days, and can also be integrated into a mortgage lending platform where users can use NFTs while eventually purchasing ownership of NFTs through installments. This will all be done without requiring permission from the original PFP project.
The launch of EIP-4907 and EIP-5006 will undoubtedly further clarify the direction of NFT to expand the application value , There will be more rich gameplay, application scenarios and derivatives. For example, the popularity of leasing NFT will enrich GameFi’s ecological gameplay, and the capital turnover rate will be greatly improved. These massive basic players who can really contribute online time in large Gamefi such as Axie need a way with a relatively low trust cost (non-mandatory transfer leasing) to rent equipment or resource rights in the game. Many NFTs will have more utility. For example, the virtual land in the metaverse can be "used", and NFT representing game assets can be "used" in the game. In some cases, owner and user may not always be the same. There may be an owner of an NFT that rents it out to a "user". A "user" should be able to take actions on an NFT differently than an "owner" (e.g., a "user" generally cannot sell ownership of an NFT). In these cases, it makes perfect sense to have separate roles that identify whether an address represents an "owner" or a "user", and manage permissions to perform actions accordingly.
EIP-5007 Give NFT a Time Attribute
This proposal proposes to add a new attribute based on the ERC-721Token standard, including the initial time expiration time (startTime, endTime). This makes the time management of NFT on the chain simpler and more efficient. Some NFTs have a defined lifespan beyond which they cannot be used. With traditional NFTs that don't include time information, if you want to mark a token as invalid or enabled at a specific time, you need to actively submit a transaction - a process that is obviously cumbersome and expensive. And the interface of its time function is inconsistent, which will bring some difficulties to the third-party development platform. By introducing these functions (startTime, endTime), NFT can be automatically enabled and disabled on the chain. The main code is shown below:
This function can also bring many new usage scenarios to NFT, such as NFT-mediated access services or NFT-based subscription content applications, because EIP-5007 will allow the development of or automatically revoke access to the Services or Content after a set period of time. In addition to this, the expansion of the protocol can also be applied to digital art or collectibles, where the value of NFT may decrease over time. The ability to specify an expiration time can help prevent NFTs from becoming "stale" or losing value over time.
It's also worth mentioning that if the expiration time is not properly enforced, or if a malicious Actors attempt to tamper with the expiration date field, and the proposed solution may create security issues. We therefore believe that additional measures may be required to ensure that expiry dates are properly enforced and that NFT owners are not unfairly locked into their assets.
EIP-5496 NFT Multi-Stake Management Extension
EIP-5496 proposes an extension to the EIP-721Token standard, allowing NFT's multi-stake management. This proposal defines an interface that extends EIP-721 to provide NFT with rights that can be shared by multiple people. Benefits can be on-chain (voting rights, permission to request airdrops) or even off-chain (coupons for online stores, discounts at local restaurants, access to airport lounges). Each NFT may contain many rights, and the holder of the rights can transfer the rights to others. Interests can be non-shareable or shareable. Shareable interests can be cloned and replicated, and providers can adjust the details according to the propagation path. It is also possible to set an expiration time for each privilege. The main code is shown below:
The specific equity data management process uses two structures for double-layer nesting. First, PrivilegeRecord is defined, which stores the user address (address user) and expiration time ( expiresAt), and then defines PrivilegeStorage, which stores the latest expiration time (LastExpiresAt), and uses mapping to bind the benefit ID and PrivilegeRecord. This method of equity IDization is very smart. After the equity ID is converted, it will be very convenient to verify the equity. It does not need to match and verify the equity verbatim. It only needs to verify the equity ID. The content of the equity usually changes frequently. , put the content of the rights and interests off the chain, and only put the rights and interests ID on the chain, and the project party does not need to spend gas fees when changing the rights and interests. However, after the rights and interests are IDized, the problem is that it is impossible to intuitively see what rights and interests this NFT has. It may also require a third-party product to independently set a rights and interests content and query functions to index to the corresponding ID. The main code is shown below:
This protocol can achieve real-time and effective management of the rights and interests attached to NFT. Many NFTs function more than just as profile pictures or art collectibles, they may have real utility in different scenarios. For example, a fashion store might offer discounts to its own NFT holders; DAO member NFT holders could vote on proposals on how to spend their treasury; a DApp might create an airdrop event to attract a certain group of people, such as some Blue-chip NFT holders come to claim it; grocery stores can issue their loyalty cards (as NFTs) on-chain, give members certain perks when they shop at the grocery store, etc. As an issuer, there may be many empowerment rights for NFT, and people who own NFT do not necessarily want to use their rights, while the traditional EIP-721 protocol only supports recording the ownership and transfer process of NFT, and the rights and interests of NFT are not protected. Recorded on the chain, the expansion of EIP-5496 will allow merchants/projects to write rights and interests into the chain and grant them to specific groups of people, and rights holders can independently manage each rights and interests, so that both project parties and holders have rights and interests management The ability has released the value of NFT in the field of practical rights and interests, and promoted the possibility of large-scale practical applications of NFT.
EIP-5606 Multiverse NFT
EIP-5606 defines an interface to create a Multiverse NFT (Multiverse NFT) standard for digital assets (such as wearable devices and in-game items), At the same time, the entrusted NFT of this asset on each platform can be indexed. These platforms can be metaverses, Gamefi or NFT marketplaces. The standard also allows for "bundling" and "unbundling" of these delegated NFTs within a multiverse NFT, so holders can trade them individually or as a bundle. The main code is shown below:
EIP-5606 introduces the multiverse NFT concept, which represents a digital asset across multiple platforms. The multiverse NFT contract defines a new kind of token that maintains the relationship between unique digital assets and their associated platform counterparts (EIP refers to them as entrusted tokens). The standard introduces the simple concept of a bundle. A bundle is essentially a set of delegated NFTs identified by a unique ID number (Multiverse TokenID). The DelegateData structure contains information about the delegated NFTToken on each platform. The variables it contains are: contractAddress, tokenId, quantity, to distinguish NFT (following the ERC-721 standard or ERC-1155 standard). The bind and unbundle functions accept an array of DelegateData structures as needed to satisfy partial binding and unbundling. They also need to delegate the NFT's individual token ID to optionally only the owner of the multiverse NFT (or an address with the bundler role) can call the bundle function.
In the web3 ecosystem, NFT has evolved to represent many types of unique and irreplaceable asset. One type of asset consists of a set of interrelated NFTs. For example, if a brand released a new sneaker on different platforms, it would be minted as a separate NFT on each platform. In reality, however, it's the same sneaker. The lack of cross-platform interoperability of NFTs has become an urgent problem to be solved. Creating a multiverse NFT standard that allows indexing and ownership of digital assets on different platforms will be the first step towards cross-platform interoperability and true ownership. In this direction, the EIP-5606 proposal is the first tangible attempt to address the interoperability of NFTs and "true" ownership across platforms.
EIP-6150 Hierarchical NFT standard was born
EIP-6150 This protocol is an extension on the basis of EIP-721. It proposes a multi-layer hierarchical NFT structure similar to a file system. Based on EIP-721 and the contract, this protocol adds a new interface to obtain the parent NFT or child NFT and whether the NFT is a leaf node or a root node, and maintains the hierarchical relationship between them. The so-called hierarchical relationship between NFTs means that all NFTs will form a hierarchical relationship tree. Each NFT is a node on the tree, which may be a root node or a leaf node, or a parent node or a child node. The main code is shown below:
The Minted event is first standardized in this proposal to indicate the parent-child relationship when minting a new node. In each hierarchical tree, this proposal specifies that the function parentOf is used to query the parent node NFT of the NFT of the specified tokenId, and the function childrenOf is specified to query all child node NFTs of the NFT of the specified tokenId. In this way, it is convenient to query the upper and lower nodes. In addition, the functions isRoot and isLeaf can respectively query whether the specified tokenId is a root node or a leaf node in the entire NFT hierarchical tree.
It is also worth mentioning that this proposal is very thoughtful and adds three optional extensions Interface
Enumerable Extension (IERC6150Enumerable)
< /p>
This proposal standardizes three functions as extensions to support enumerable queries involving child nodes. Each function has a param parentId. For compatibility, when the parentId is specified as 0, it means to query the root node.
Destroy Node Extension (IERC6150Burnable)
Transfer Extension for Hierarchical Relationships (IERC6150ParentTransferable) In some cases, such as file systems, a directory or a file can be moved from one directory to another. So this proposal adds the ParentTransferable extension to support this case.
Access Control (IERC6150AccessControl)
In a hierarchy, there is usually more than one account that has permission to operate a node, such as mint child nodes, transfer nodes, and burn nodes. This proposal adds some standard functionality to check access control permissions.
Because the current NFTs are almost flat, there is no relationship between different NFTs . The hierarchical standard NFT can connect all NFTs in series to form a tree structure, just like a file system. Hierarchical NFT can be used in a variety of different application scenarios, such as: organizational structure, social relationship graph, e-commerce product category structure, hierarchical comment system, etc.
< /p>
It can be said that any scene with a hierarchical structure can apply this EIP-6150 protocol standard. Hierarchical NFTs may have a wide range of applications in decentralized social networking, decentralized e-commerce and other fields. Within the Ethereum ecosystem, a single smart contract can be the root, managing each directory/category as a separate NFT and a hierarchy of NFTs. The tokenURI of each NFT can be another contract address, a website link, or any form of metadata. Only one contract is needed to manage and operate the hierarchical relationship. In the near future, with the development of Ethereum's data availability solutions and external permissionless data retention networks, on-chain companies for managing organizational structures will become possible. Thus realizing a completely decentralized application.
< p>The above is the latest content of the recent Ethereum NFT protocol. Before this article, EIP-5007 and EIP-5496 are still in the Last Call stage. Call goes to the Final stage. Generally speaking, the adoption of these new protocols has made a great contribution to NFT in terms of innovation and practicality. Now NFT has passed the PFP stage, and the journey of Web3 is a sea of stars. Innovation is staged all the time. NFT's What will the next narrative start? From these agreements, we can see that the future of NFT is moving in a more practical and applicable direction. In the not-too-distant future, NFT technology itself will change games, insurance, real estate sales, paid advertising, voting, social platforms, video media... every aspect of our lives. NFT will not just be a "part" of encryption. In the next few years, they will likely be the only practical applications in the field of encryption that are closely related to the real world.
Reference materials:
EIP-4955:https://eips.ethereum.org/EIPS/eip-4955https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4955 .mdEIP-5006https://eips.ethereum.org/EIPS/eip-5006https://github.com/ethereum /EIPs/blob/master/EIPS/eip-5006.mdEIP-5007https://eips.ethereum.org/EIPS/eip-5007https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5007.mdEIP-5496https://eips.ethereum .org/EIPS/eip-5496https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5496.mdEIP-5606EIP-5606https://eips.ethereum.org/EIPS/eip-5606https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5606.mdEIP-6150https://eips.ethereum.org/EIPS/eip-6150https://github.com/ethereum/EIPs /blob/master/EIPS/eip-6150.md
Original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
