Aptos 代币(NFT) #
非同质化代币
NFT概述 #
一个是不可替代的或存储在区块链上的数据,它唯一地定义了资产的所有权。NFT 最初是在 中定义的,后来在 NFT 通常使用以下属性定义:
- 名称:资产的名称。 它在集合中必须是唯一的。
- 描述:资产的描述。
- uri:指向链下的 URL 指针,用于获取有关资产的更多信息。资产可以是图像或视频等媒体或更多元数据。
- supply:该 NFT 的总数量。许多 NFT 只有一个供应,而那些有多个供应的 NFT 被称为版本。
此外,大多数 NFT 是一个集合的一部分或一组具有共同属性的 NFT,例如,主题、创建者或最小合同。 每个集合都有一组相似的属性:
- 名称:集合的名称。该名称在创建者的帐户中必须是唯一的。
- 描述:集合的描述。
- uri:指向链下的 URL 指针,用于获取有关资产的更多信息。资产可以是图像或视频等媒体或更多元数据。
- supply:这个集合中 NFT 的总数。
- maximum:这个集合可以拥有的最大 NFT 数量。如果最大值设置为 0,则不跟踪供应。
Token resources #
如上图所示,与代币相关的数据同时存储在创建者账户和所有者账户中。
Struct-level resources #
下表描述了结构级别的字段。有关最终列表,请参阅 Aptos Token Framework。
Resource stored at the creator’s address
Field | Description |
---|---|
Collections | Maintains a table called collection_data , which maps the collection name to the CollectionData . It also stores all the TokenData that this creator creates. |
CollectionData | Stores the collection metadata. The supply is the number of tokens created for the current collection. The maxium is the upper bound of tokens in this collection. |
CollectionMutabilityConfig | Specifies which field is mutable. |
TokenData | Acts as the main struct for holding the token metadata. Properties is a where users can add their own properties that are not defined in the token data. Users can mint more tokens based on the TokenData , and those tokens share the same TokenData . |
TokenMutabilityConfig | Controls which fields are mutable. |
TokenDataId | An ID used for representing and querying TokenData on-chain. This ID mainly contains three fields including creator address, collection name and token name. |
Royalty | Specifies the denominator and numerator for calculating the royalty fee. It also has the payee account address for depositing the royalty. |
PropertyValue | Contains both value of a property and type of property. |
Resource stored at the owner’s address
Field | Description |
---|---|
TokenStore | The main struct for storing the token owned by this address. It maps TokenId to the actual token. |
Token | The amount is the number of tokens. |
TokenId | TokenDataId points to the metadata of this token. The property_version represents a token with mutated PropertyMap from default_properties in the TokenData . |
有关更详细的说明,请参阅 Aptos Token Framework。
Token creation #
每个 Aptos 令牌都属于一个集合。开发者首先需要通过 create_collection_script
创建一个集合,然后创建属于该集合的 token create_token_script
。为了实现并行创建 TokenData
和 Token
,开发人员可以创建无限集合和 TokenData
,其中集合和 TokenData
的最大值设置为 0。使用此设置,令牌合约将不会跟踪令牌类型的供应(TokenData 计数)以及每种代币类型中的代币供应。因此,可以并行创建 TokenData
和 Token。
/// create a empty token collection with parameters
public entry fun create_collection_script(
creator: &signer,
name: String,
description: String,
uri: String,
maximum: u64,
mutate_setting: vector<bool>,
) acquires Collections {
/// create token with raw inputs
public entry fun create_token_script(
account: &signer,
collection: String,
name: String,
description: String,
balance: u64,
maximum: u64,
uri: String,
royalty_payee_address: address,
royalty_points_denominator: u64,
royalty_points_numerator: u64,
mutate_setting: vector<bool>,
property_keys: vector<String>,
property_values: vector<vector<u8>>,
property_types: vector<String>
) acquires Collections, TokenStore {
Aptos 还强制对输入大小进行简单验证并防止重复:
- 代币名称 - 在每个集合中都是唯一的
- 集合名称 - 在每个帐户中都是唯一的
- 令牌和集合名称长度 - 小于 128 个字符
- URI 长度 - 小于 512 个字符
- 属性映射 - 最多可容纳 1000 个属性,每个键应小于 128 个字符
代币销毁 #
我们为令牌所有者和令牌创建者提供 burn
和 burn_by_creator
函数来销毁(或销毁)代币。然而,这两个功能也受到代币创建期间指定的配置的保护,因此创建者和所有者都清楚谁可以销毁令牌。仅当 default_properties
中的 BURRNABLE_BY_OWNER
属性设置为 true
时才允许刻录。当 default_properties
中的 BURRNABLE_BY_CREATOR
为真时,允许创建者刻录。一旦属于 TokenData
的所有代币都被销毁,TokenData
将从创建者的帐户中删除。类似地,如果属于一个集合的所有 TokenData
都被删除,则该 CollectionData
将从创建者的帐户中删除。
/// The token is owned at address owner
public entry fun burn_by_creator(
creator: &signer,
owner: address,
collection: String,
name: String,
property_version: u64,
amount: u64,
) acquires Collections, TokenStore {
/// Burn a token by the token owner
public entry fun burn(
owner: &signer,
creators_address: address,
collection: String,
name: String,
property_version: u64,
amount: u64
) acquires Collections, TokenStore {
代币转移 #
我们提供三种不同的模式来在发送方和接收方之间传输令牌。
两步转移
- 为了保护用户免受不想要的 NFT 的影响,必须首先向他们提供 NFT,然后再接受提供的 NFT。然后只有提供的 NFT 才会存入用户的代币商店。这是默认的令牌传输行为。例如:
- 如果 Alice 想给 Bob 发送一个 NFT,她必须先向 Bob 提供这个 NFT。 这个 NFT 仍然存储在 Alice 的账户下。 只有当 Bob 认领 NFT 时,NFT 才会从 Alice 的账户中移除并存储在 Bob 的代币存储中。
Transfer with opt-in #
If a user wants to receive direct transfer of the NFT, skipping the initial steps of offer and claim, then the user can call opt_in_direct_transfer
to allow other people to directly transfer the NFTs into the user’s token store. After opting into direct transfer, the user can call transfer
to transfer tokens directly. For example, Alice and anyone can directly send a token to Bob’s token store once Bob opts in.
如果用户想直接接收 NFT 的转账,跳过最初的报价和认领步骤,那么用户可以调用允许其他人直接将 NFT 转入用户的代币存储。选择直接转账后,用户可以直接调用转账。例如,一旦 Bob 选择加入,Alice 和任何人都可以直接将令牌发送到 Bob 的令牌存储。
Multi-agent transfer
发送方和接收方都可以签署转账交易,直接将代币从发送方转移到接收方。例如,一旦 Alice 和 Bob 都签署了转账交易,则代币将直接从 Alice 的账户转给 Bob。
public entry fun direct_transfer_script(
sender: &signer,
receiver: &signer,
creators_address: address,
collection: String,
name: String,
property_version: u64,
amount: u64,
) acquires TokenStore {