以太坊 - 前言

前言

SIP 编号: 010

标题: Fungible Tokens 的标准特征定义

作者: Hank Stoever <hstove@gmail.com>, Pascal Belloncle <psq@nanorails.com>

考虑因素: 技术

类型: 标准

状态: 已批准

创建时间: 2021 年 1 月 25 日

许可证: CC0-1.0

签署: Jude Nelson <jude@stacks.org>, 技术指导委员会主席

层: Traits

讨论地址: https://github.com/stacksgov/sips

摘要

Fungible tokens 是可以发送、接收、组合和分割的数字资产。 大多数形式的加密货币都是 fungible tokens。 它们已成为几乎所有区块链的构建块。 本 SIP 旨在提供一种灵活且易于实现的标准，供 Stacks 区块链上的开发人员在创建自己的 tokens 时使用。

许可证与版权

本 SIP 根据 Creative Commons CC0 1.0 Universal 许可证的条款提供，该许可证可在 https://creativecommons.org/publicdomain/zero/1.0/ 获得。 本 SIP 的版权归 Stacks Open Internet Foundation 所有。

简介

数字资产可以具有同质化的属性。 Fungible token 可以分解成小单元并加在一起。 Fungible 资产的所有者只需要关心他们的余额，即他们拥有的特定 Fungible 资产的总量。 大多数知名的货币都是 Fungible 的。 对于 Fungible tokens 来说，任何两种不同的 Fungible token 数量之间都没有区别。

例如，如果用户拥有 10 个单位的 Fungible 资产，他们可以将 2 个单位发送给不同的用户。 此时，他们的余额为 8 个单位。 如果他们稍后收到更多单位，他们的总余额将会更新。

在区块链上，Fungible tokens 是一个核心组件。 具有智能合约的区块链（包括 Stacks 区块链）允许开发人员和用户创建和交互使用 Fungible tokens 的智能合约。

Stacks 区块链具有原生的 Fungible token：Stacks token (STX)。 除了原生的 STX token 之外，Stacks 区块链用于开发智能合约的编程语言 Clarity 具有内置的语言原语来定义和使用 Fungible tokens。 尽管存在这些原语，但定义一个通用接口（在 Clarity 中称为“trait”）仍然具有价值，该接口允许不同的智能合约以可重用的方式与 Fungible token 合约进行互操作。 本 SIP 定义了该 trait。

规范

Fungible token trait sip-010-trait 具有 7 个函数：

Trait 函数

Transfer

(transfer ((amount uint) (sender principal) (recipient principal) (memo (optional (buff 34)))) (response bool uint))

将 Fungible token 从此交易的发送者转移到接收者。 amount 是一个无符号整数。 建议实施合约使用内置的 ft-transfer? Clarity 方法。 如果发送者没有足够的 tokens 来完成交易，则交易应该中止并返回一个 (err uint)。

此方法必须使用 define-public 定义，因为它会改变状态，并且应该是可外部调用的。

合约实施者应注意执行 transfer 方法的授权。 例如，一个 Fungible token 合约想要确保只有交易的发送者能够移动所请求的 tokens，可以首先检查 sender 参数是否等于 tx-sender。

当在此函数中返回错误时，错误代码应遵循与内置 ft-transfer? 和 stx-transfer? 函数相同的模式。

合约实施者应注意，在 Stacks 2.0 中，备忘录字段不会包含在成功的 ft-transfer? 操作发出的事件中。 因此，如果 ft-transfer? 成功并且 memo 不是 none，则实施者必须通过添加 print 语句来确保发出 memo。 备忘录应该解包并在 ft-transfer? 操作后发出。

例子:

  ...
  (try! (ft-transfer? token amount sender recipient))
  (match memo to-print (print to-print) 0x)
  ...

Name

(get-name () (response (string-ascii 32) uint))

返回合约的人类可读名称，例如“CoolPoints”等。

此方法应定义为只读，即 define-read-only。

Symbol

(get-symbol () (response (string-ascii 32) uint))

返回一个符号，允许更短地表示 token。 这有时被称为“ticker”。 示例：“STX”、“COOL”等。 通常，在书面引用 token 时，token 可以被称为 $SYMBOL。

此方法应定义为只读，即 define-read-only。

Decimals

(get-decimals () (response uint uint))

token 中的小数位数。 所有 Fungible token 余额都必须表示为整数，但提供小数位数可以提供人类更熟悉的 token 抽象。 例如，如果基本单位是“美分”，正如通常在会计中所做的那样，美元有 2 个小数位。 Stacks 有 6 个小数位，比特币有 8 个小数位，依此类推。

作为另一个例子，如果一个 token 有 4 个小数位，并且 get-balance 方法返回特定用户 100345000，那么钱包和交易所可能会将该值表示为 10034.5。

此方法应定义为只读，即 define-read-only。

Balance of

(get-balance (principal) (response uint uint))

返回特定 principal（也称为“address”或“account”）的余额。 实现通常应使用内置的 Clarity 方法 ft-get-balance。

此方法应定义为只读，即 define-read-only。

Total supply

(get-total-supply () (response uint uint))

返回此 token 的总供应量。 实现通常应使用内置的 Clarity 方法 ft-get-supply。

此方法应定义为只读，即 define-read-only。

Token URI

(get-token-uri () (response (optional (string-utf8 256)) uint))

返回一个可选字符串，该字符串是一个有效的 URI，可解析为此 token 的元数据。 这允许你的 token 提供关于合约的链下元数据，例如描述和图像图标。

此元数据的 JSON 模式如下：

{
  "title": "Asset Metadata",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Identifies the asset to which this token represents"
    },
    "description": {
      "type": "string",
      "description": "Describes the asset to which this token represents"
    },
    "image": {
      "type": "string",
      "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
    }
  }
}

获取此数据的客户端应首选任何链上数据，例如 token 的名称，而不是 get-token-uri 中提供的元数据。

Trait 实现

下面提供了建议的 trait 的实现。

(define-trait sip-010-trait
  (
    ;; 从调用者转移到新的 principal
    (transfer (uint principal principal (optional (buff 34))) (response bool uint))

    ;; token 的人类可读名称
    (get-name () (response (string-ascii 32) uint))

    ;; ticker 符号，如果没有则为空
    (get-symbol () (response (string-ascii 32) uint))

    ;; 使用的小数位数，例如 6 将表示 1_000_000 表示 1 个 token
    (get-decimals () (response uint uint))

    ;; 传递的 principal 的余额
    (get-balance (principal) (response uint uint))

    ;; 当前总供应量（不需要是一个常量）
    (get-total-supply () (response uint uint))

    ;; 表示此 token 元数据的可选 URI
    (get-token-uri () (response (optional (string-utf8 256)) uint))
  )
)

在钱包和其他应用程序中实施

希望与 Fungible token 合约交互的开发人员应首先被提供或跟踪各种不同的 Fungible token 实现。 在验证 Fungible token 合约时，他们应该获取该合约的接口和/或源代码。 如果合约实现了该 trait，那么钱包可以使用此标准的合约接口进行转账和获取余额。

实现此 trait 的合约的下游使用者应该意识到 get-name 和 get-symbol 函数不能保证是全局唯一的。 因此，应建议消费者 get-name 和 get-token 只是提供更人性化体验的提示。 应始终注意验证合约的标识符是否与客户端打算与之交互的 token 的标识符匹配。

此 trait 中的所有函数都返回 response 类型，这是 Clarity 中 trait 定义的要求。 但是，其中一些函数应该是“防故障”的，因为它们永远不应该返回错误。 这些“防故障”函数是已被推荐为只读的函数。 如果实现此 trait 的合约为这些函数返回错误，则可能表明合约存在缺陷，并且这些合约的消费者应谨慎行事。

使用原生资产函数

虽然不可能在 Clarity trait 中强制执行，但合约实施者应始终使用作为 Clarity 原语提供的内置原生资产。 这允许客户端使用 Post Conditions（如下所述），并利用其他优势，例如通过 stacks-blockchain-api 对这些资产余额和转移的本机支持。 本 SIP 中包含的参考实现使用原生资产原语，并为其用法提供了良好的样板。

原生资产原语包括：

• define-fungible-token
• ft-burn?
• ft-get-balance
• ft-get-supply
• ft-mint?
• ft-transfer?

使用后置条件

除了 Fungible token 合约的内置方法外，Stacks 区块链还包括一个称为 Post Conditions 的功能。 通过定义后置条件，用户可以创建包含关于该合约中可能发生的事情的预定义保证的交易。

其中一种后置条件可能是“我将转移恰好 100 个 X token”，其中“X token”被引用为特定合约的 Fungible token。 当钱包和应用程序实现 transfer 方法时，它们应该始终使用后置条件来指定用户将转移的 token 数量正是他们在 transfer 函数的 amount 参数中指定的数量。 只有在非常特殊的情况下才不应包含这样的后置条件。

相关工作

Ethereum ERC20

Ethereum ERC20 标准

也许最古老和最著名的 Fungible token 标准是 Ethereum 的 ERC20 标准。 它已成为 Ethereum 生态系统最强大的构建块之一。 当所有 Fungible tokens 都遵循相同的标准时，任何钱包或应用程序开发人员都可以与之交互，而无需创建自定义逻辑来处理每个 token。

Fungible tokens 变得非常流行，以至于 Clarity 智能合约语言内置了对基本 Fungible token 操作的支持。 事实上，正如在本提案的参考实现中所看到的，实现 Fungible token 只需要很少的代码。 此标准的重要部分是定义所有 Fungible tokens 都可以实现的 Clarity trait。 即使 Clarity 内置了 Fungible token 操作，但对于每个合约定义相同的方法以便于集成也非常重要。

向后兼容性

不适用

激活

此 trait 已部署到主网：SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard

当此 trait 部署到主网，并且该 trait 的 3 个不同实现已部署到主网（不迟于比特币区块 700000）时，此 trait 将被视为已激活。

参考实现

已在此提案中提交了一个示例实现，以及一个 Javascript 客户端和测试。 https://github.com/hstove/stacks-fungible-token

其他 Clarity 合约的示例，这些合约实现了 Fungible tokens，尽管不完全符合此规范：

• @psq 的 trait 和实现
• @friedger 的 Fungible token 实现

已部署的合约

• mainnet: SP3FBR2AGK5H9QBDH3EEN6DF8EK8JY7RX8QJ5SVTE.sip-010-trait-ft-standard.sip-010-trait
• testnet: ST1NXBK3K5YYMD6FD41MVNP3JS1GABZ8TRVX023PT.sip-010-trait-ft-standard.sip-010-trait

• 原文链接： github.com/stacksgov/sip...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～