Author: Ash Li, Noah Ho
Source: https://www.spectrumlab.io/zh/reports/erc6551%E7%95%B6nft%E7%A2%B0%E4%B8%8A%E5%90%88%E7%B4%84%E9%8C%A2%E5%8C%85
The ERC-6551 protocol has been discussed in the community and has brought great potential for NFT expansion. ERC-6551 creates a unique contract wallet for each NFT through a Token Bond Account (TBA), which enables it to hold assets and record related behaviors. This creates the possibility of identity authentication and combined NFTs for non-fungible tokens (NFTs). Looking deeper, we can find that ERC-6551 actually provides a fully functional wallet for NFTs, and the "key" to this wallet is the NFT itself. This article will review the development of NFT standards and cover previous attempts to expand NFTs. Given that the core of TBA is the contract wallet, we will also briefly introduce the contract wallet. Finally, we will delve into the implementation details of the protocol and its potential application prospects.
1. History and Current Status of NFT Standards
As a special cryptocurrency and digital art asset, NFT provides a new digital carrier for artworks and expands the application scenarios of blockchain technology. Unlike traditional homogeneous tokens, each NFT is unique and associated with specific metadata, such as artworks, game props, music and other electronic materials. Therefore, NFT can be used as a certificate of ownership of electronic data for people to collect or trade. On May 3, 2014, digital artist Kevin McCoy created the first known NFT work "Quantum". It is a pixelated octagon composed of various shapes and presented in a psychedelic way. However, it was not until the emergence of ERC-721 (Ethereum Request for Comments 721) that NFT really had a unified standard, which facilitated the application of developers in different projects.
ERC-721
ERC-721 is closely tied to the history of CryptoPunks. CryptoPunks was launched in 2017 and included 10,000 unique 24x24 pixel art images. It was its success that attracted widespread attention from developers and the community, making more people aware of the huge potential of NFTs. Since then, it has become the blueprint for many NFT projects and has led to the development of the ERC-721 standard. The standard was created by Dieter Shirley, CTO of CryptoKitties. In January 2018, William Entriken, Dieter Shirley, Jacob Evans and Nastassia Sachs jointly proposed the ERC-721 standard. This non-fungible token standard implements token-related ABIs in smart contracts, laying the foundation for the creation, management and transfer of unique digital assets on Ethereum, opening a new chapter for artists, collectors and the digital art market.
The main features of ERC-721 are as follows:
Uniqueness: Unlike ERC-20 tokens (which are fungible and each token is exactly the same as every other token), each ERC-721 token is unique.
Ownership and Transfer: This token standard allows the owner of any given token to be identified and allows the owner or approved individuals to transfer the token.
Metadata Association: Allows metadata to be associated with each token, which may include an image, description, or other relevant properties of the token.
To ensure its status as a standard, ERC-721 defines the following key methods and events:
Methods such as balanceOf(), ownerOf(), approve(), getApproved(), setApprovalForAll(), isApprovedForAll(), transferFrom(), and safeTransferFrom().
As well as events such as Transfer() and Approval().
In short, the ERC-721 standard provides a mechanism for unique assets on Ethereum, ensuring the uniqueness and ownership of each asset and allowing them to be verified, traded and managed. As a standard for non-fungible tokens, ERC-721 has achieved explosive success in the field of digital art and collectibles. ERC-721 defines
However, although it has brought many famous projects to NFT applications, there are still some limitations, such as they cannot operate as proxies or be directly associated with other on-chain assets. In order to solve these problems, the community has proposed a series of extensions and new standards, the most representative of which are EIP3664 and EIP3525.
ERC-3664
As early as May 2021, the DRepublic team proposed EIP-3664, an NFT attribute extension protocol. This proposal solves the limitations of mainstream NFT standards such as ERC-721 or ERC-1155 in a clever way, such as insufficient attribute expression, difficulty in integrating NFTs, and centralized attribute storage.
Specifically, EIP-3664 does not need to modify the existing ERC-721 and ERC-1155 standards. It dynamically adds properties to NFTs by using the callback function of the IERC721Receiver or IERC1155Receiver interface in the mint method of NFTs. Or it can be done by rewriting the minting method. Using this protocol, an NFT can have any number of properties attached to it without limit.
In EIP-3664, all attributes implement the IERC3664 interface. The basic attributes include several basic fields such as ID, name, symbol, URI address, balance, etc., which are used to describe the metadata of NFT. Through EIP-3664, the attribute extension of NFT becomes more flexible and customizable. It provides a standardized implementation method for the attribute function of NFT and integrates seamlessly with the existing NFT ecosystem.
ERC-3525
EIP-3525 introduces semi-fungible tokens (SFTs), which can be seen as an asset between fungible tokens (FTs) and non-fungible tokens (NFTs). Similar to NFTs, SFT tokens can be transferred intact from one wallet address to another. But similar to FTs, SFTs allow only partial value to be transferred between different tokens. For example, only part of the "use life" of a piece of land can be transferred to another piece of land. Undoubtedly, SFTs surpass FTs in terms of customization and NFTs in terms of efficiency.
ERC3525 allows the construction of multi-level SFT structures, similar to Russian nesting dolls, to achieve a more complex virtual world and define the interaction rules between different levels. By using ERC3525, NFTs can carry any digital currency. This means that tokens with economic value can be embedded in NFTs to achieve richer functions and interaction methods. For example, an SFT can contain an NFT that carries value, and other tokens can be nested in the NFT. Through ERC3525, developers can define the rules and logic of SFTs through smart contracts and customize specific behavior rules and transaction rules for them. These features make ERC3525 one of the important standards in the NFT field, providing more creative space for developers and project parties.
2. ERC-6551
introduce
In order to enhance the scalability and practicality of NFTs, the ERC-6551 proposal aims to give each NFT the same rights and interests as Ethereum users. This means that NFTs can not only hold assets, but also record transaction history, which greatly increases its scope of application. Under this proposal, NFT holders can create a dedicated contract wallet called TBA (Token Bond Account) for their NFTs to perform various operations on the chain. This is achieved by defining a unified registry - Registry. This registry specifically assigns unique and fixed smart contract account addresses to all NFTs and ensures that the control of the account is entirely in the hands of the NFT holder. It is worth noting that this proposal is fully compatible with the existing ERC-721 or 1155 standards without any modifications, and also adapts to most of the infrastructure that supports Ethereum accounts.
This innovation provides NFTs with the same functionality as Ethereum accounts, opening up many new application scenarios for NFTs. For example, complex assets in reality, such as characters in role-playing games, cars made up of multiple parts, diversified investment portfolios, and even membership cards, can all be converted into NFTs through this proposal. In addition, this proposal is not only compatible with all existing on-chain asset standards, but also provides expansion possibilities for new asset standards in the future.
As mentioned above, ERC-6551 allows the creation of a wallet dedicated to on-chain interactions for each NFT. This wallet is different from the wallets we commonly use on platforms such as Metamask. It is actually a contract wallet, that is, a smart contract deployed on the Ethereum network. Before we delve into its implementation, let's first understand the main differences between the two wallets.
Contract Account
An Ethereum account is an entity that has a balance of Ether (ETH) and can send transactions on the Ethereum network. Accounts can be controlled by users or deployed as smart contracts.
In Ethereum, an account has 4 fields:
nonce : A counter that shows the number of transactions sent by external accounts or the number of contracts created by contract accounts. Each account can only execute one transaction with a given nonce to prevent replay attacks, which are multiple broadcasts and repeated executions of signed transactions.
balance : Balance accounting model, the amount of Wei owned by this address. Wei is the unit of measurement for Ethereum.
codeHash : This hash represents the account code on the Ethereum Virtual Machine (EVM). Contract accounts have programmed code snippets that can perform different actions. This EVM code is executed if the account receives a message call. Unlike other account fields, it cannot be changed. All code snippets are saved under the corresponding hash in the state database for subsequent retrieval. This hash value is called codeHash. For externally owned accounts, the codeHash field is a hash of an empty string.
storageRoot : The storage hash. A 256-bit hash of the Merkle Patricia trie root that has encoded the storage contents of the account (a mapping of 256-bit integer values), encoded as a trie as a mapping of Keccak 256-bit hashes from 256-bit integer keys to RLP-encoded 256-bit integer values. This trie encodes the hash of this account's storage contents and is empty by default.
There are two types of Ethereum accounts: external accounts (user-managed private keys) and contract accounts.
Externally Owned Accounts (EOA): controlled by a private key, with an empty codeHash. This type of account can send and receive cryptocurrencies and interact with smart contracts. The Metamask wallet we commonly use belongs to this category.
Contract Account (CA): has no private key and its codeHash is not empty. It is a smart contract deployed on the Ethereum network, which controls the contract wallet by interacting with the contract through external accounts.
There are standard contract wallets in CA, such as ERC4337 account abstraction wallets, and Native AA type wallets, such as ZkSync and StarkNet, where there are no traditional transactions and all accounts are contract accounts. Currently, there are problems with ownership and signature rights in wallets, such as the difficulty in protecting private keys, and users will lose all assets if they lose their private keys. There are also problems with signature algorithms with few permissions and high permissions, and the handling fee can only be settled in a single currency through ETH.
Without changing the consensus protocol layer, it can help Ethereum move towards account abstraction. ERC4337 can realize the upgrade of account abstraction through smart contracts, and update the process from the initiation of the original transaction to its inclusion in the entire blockchain. UserOperation is introduced to describe the structure of transactions sent on behalf of users. Bundler will package the transactions in these memory pools to reduce the transaction costs of users, and the multi-signature scenario will be more complete to realize the upgrade of functions such as social recovery.
accomplish
Under the ERC-6551 standard, NFT holders can interact with Register Contract to deploy a new smart contract, TBA, on the Ethereum network or other EVM-supported blockchains. The ownership of TBA belongs to the NFT holder and will change with the transfer of NFT. Only the NFT holder can control this TBA. The code of TBA, that is, its rules, comes from the call of the Implementation Contract.
The following diagram shows how ERC-6551 works: Assume that a user is an NFT holder, and his User Account owns two NFTs,#123of Contract A and#456of Contract B. The User Account interacts with the permissionless registry, the Register Contract, and enters the NFT information and the address of the implementation contract to create a TBA. When the User Account calls the Register Contract, it enters the NFT information of Token#123and the address of Implementation A (0x321…), and the contract wallet Account A (0x123…) will be created. Its ownership belongs to the holder of NFT Token #123, and its functions and rules are derived from the provisions of Implementation A. When the User Account calls the Register Contract again and changes the input content, another TBA will be generated. However, for a specific NFT and implementation contract, there can only be one unique corresponding TBA.
The creation and behavior of TBAs are entirely dependent on the registration contract and the implementation contract. The rules in these contracts determine the features and functions of TBAs. EIP-6551 provides code templates for these contracts. We will explore these templates in depth in subsequent sections. However, these templates are not the only options, and their code determines how TBAs are deployed and how they function. This provides developers with a wide range of expansion possibilities. For example, the registration contract can set which NFTs are eligible to be registered using the registration contract. The implementation contract can define the functions and rules of TBAs, such as setting daily transaction limits for TBAs or specifying the types of assets they can hold.
Implementation Contract
All TBAs created through the registration contract can choose the implementation contract they wish to use for the account. The implementation contract records the functions and rules of the smart contract account. At a minimum, the implementation contract must provide the following functions:
executeCall(): A function used to execute arbitrary smart contract functions that interact with external contracts. For example, to sell the contained assets in an account tied to an NFT, you might need to call a function in the Uniswap contract. executeCall allows you to make that function call on behalf of the smart contract account, allowing you to buy, sell/exchange any asset you want.
token(): A read-only view function that returns the identifier of the NFT that owns the account bound to the token. It returns the chain ID (whether the NFT is on the mainnet, Polygon, Optimism, etc.), the NFT contract address, and the NFT token ID.
owner(): Returns the address of the owner of the NFT that controls the account bound to the token. Following the example above, this would be the address of the User Account.
nonce(): Returns the current nonce of this smart contract wallet. Each successful transaction will increase the nonce by 1, and the initial value is 0.
Finally, although not a function call, the implementation contract of the account bound to the token must have a receive() function to be able to receive native assets (such as ETH) directly to its address.
Register Contract
Below is the Registry smart contract written in Solidity:
This code shows that the parameters required to create an account for an NFT include implementation execution contract address, chainId target chain id, tokenContract corresponding to the contract to which the NFT belongs, tokenId corresponding to the id to which the NFT belongs, and confusion value salt. According to the Fast Dapp Demo, to create an NFT account, you only need to enter the NFT contract address and ID, and the rest of the fields are automatically generated. The steps are relatively simple.
The ERC-6551 proposal is a new token standard that is a subversive upgrade to the original NFT standard. ERC-6551 uses a permissionless registry that is compatible with existing ERC-721 NFTs. The registry is a smart contract that serves as a factory and directory for TBAs. Anyone can create a TBA for any ERC-721 token by calling a function on the registry and paying a small fee. The registry's smart contract has two functions:
createAccount: Deploys a new token-bound account for a given ERC-721 NFT and a specific implementation.
account: A read-only view function that returns the address of the account bound to the token for a given ERC-721 NFT, given its implementation.
Potential applications
Since the Azuki incident, the appeal of single static image NFTs has greatly decreased, causing the value of many top projects to decline. However, highly interactive and composable NFTs may be the key to market recovery. From blockchain games, music, DID to the metaverse, these fields are full of endless potential.
NFTs are more than just assets; they also have their own on-chain identity and container properties, and can interact with decentralized applications (Dapps). This means that all interactions with NFTs are recorded directly in the NFT itself, rather than in the account of its holder. In addition, since NFTs are based on smart contracts, their behavior and interactions can be defined and controlled by contract rules, providing flexibility and security.
The ERC-6551 protocol has brought revolutionary changes in the NFT field, shifting the focus from user wallets to NFTs themselves, providing new possibilities for transactions, games, traceability, and governance. With the further development of NFTs, this protocol will lead us into a more personalized, interactive, and meaningful digital era.
Consider the following four potential applications:
Asset Packaging: NFT can be used as an asset container, allowing multiple assets to be packaged and traded in a single NFT. For example, a music album NFT may contain multiple song NFTs, or an art collection NFT may contain multiple artwork NFTs. This not only makes the collection more systematic, but also reduces gas fees when trading.
Investment portfolio: NFT can be used as an asset management tool, allowing users to store and manage multiple tokens in one TBA. In addition, NFT holders can also authorize third-party managers to trade assets and clearly define the manager's authority in the smart contract to ensure the security of assets.
NFT identity management: NFT can record all its activities on the chain, making it a real on-chain identity. Users can use a single ENS wallet to represent themselves and use different TBAs to represent their roles in different communities or applications.
Modular NFT: The main NFT can generate TBA for storing its component NFTs. For example, in a game, a character NFT may be equipped with various equipment NFTs. This not only makes the realization of the metaverse more possible, but can also be combined with AI to create more realistic NPC characters.
In short, the future of NFT is full of infinite possibilities. From asset management to identity authentication to modular game design, they will play a key role in the digital world.
