ERC-6454: 最小化可转移 NFT 检测接口

一个用于识别非同质化代币可转移性的最小扩展。

摘要

非同质化代币的最小化可转移接口标准通过引入识别 NFT 是否可转移的能力来扩展 ERC-721。

该提案引入了防止代币从其所有者处转移的能力，使其绑定到外部拥有的帐户、抽象帐户、智能合约或拥有它的代币。

动机

随着 NFT 成为以太坊生态系统中一种广泛的代币形式，并被用于各种用例，现在是时候标准化它们的额外效用了。 拥有防止代币被转移的能力，为 NFT 的效用和发展带来了新的可能性。

本提案的设计方式尽可能精简，以便与希望利用本提案的任何用例兼容。

此 EIP 为基于 ERC-721 的代币在以下领域引入了新的实用程序：

• 可验证的归属
• 不可变的属性

可验证的归属

个人成就可以用非同质化代币来表示。 这些代币可用于表示各种各样的成就，包括科学进步、慈善事业、体育成就等等。 但是，如果这些指示成就的 NFT 很容易转移，它们的真实性和可信度就会受到质疑。 通过将 NFT 绑定到特定帐户，可以确保拥有 NFT 的帐户是实际取得相应成就的帐户。 这创建了一个安全且可验证的个人成就记录，可以轻松地被网络中的其他人访问和识别。 验证归属的能力有助于建立指示成就的 NFT 的可信度和价值，使其成为一种有价值的资产，可以用作对持有者成就的认可。

不可变的属性

NFT 属性是非同质化代币的一个关键方面，用于区分它们并确定它们的稀缺性。 然而，发行者对 NFT 属性的集中控制可能会破坏这些属性的独特性。

通过将 NFT 绑定到特定属性，原始所有者可以确保 NFT 始终保留这些属性及其独特性。

在一个使用不可转移的 NFT 来表示技能或能力的区块链游戏中，每项技能都是一个与特定玩家或代币相关的独特且永久的资产。 这将确保玩家保留对其所获得技能的所有权，并防止其被交易或出售给其他玩家。 这可以提高这些技能的认知价值，并通过允许对角色进行更大的自定义和个性化来增强玩家体验。

规范

本文档中的关键词“必须（MUST）”、“禁止（MUST NOT）”、“必需（REQUIRED）”、“应该（SHALL）”、“不应该（SHALL NOT）”、“推荐（SHOULD）”、“不推荐（SHOULD NOT）”、“可以（MAY）”和“可选（OPTIONAL）”应按照 RFC 2119 中的描述进行解释。

/// @title EIP-6454 用于 NFT 的最小化非可转让接口
/// @dev 参见 https://eips.ethereum.org/EIPS/eip-6454
/// @dev 注意：此接口的 ERC-165 标识符为 0x91a6262f。

pragma solidity ^0.8.16;

interface IERC6454 /* is IERC165 */ {
    /**
     * @notice 用于检查给定的代币是否可转移。
     * @dev 如果此函数返回 `false`，则代币的转移必须恢复执行。
     * @dev 如果 tokenId 不存在，则此方法必须恢复执行，除非正在检查代币的
     *  铸造。
     * @dev `from` 参数可以用于验证代币转移的批准，但与此函数交互的任何人
     *  不应依赖它，因为它不是提案强制要求的。
     * @param tokenId 要检查的代币的 ID
     * @param from 要转移代币的地址
     * @param to 要将代币转移到的地址
     * @return 布尔值，指示给定的代币是否可转移
     */
    function isTransferable(uint256 tokenId, address from, address to) external view returns (bool);
}

为了确定代币是否通常可转移，当传递 0x0000000000000000000000000000000000000000 地址作为 to 和 from 参数时，该函数应返回适当的布尔值。

代币的一般可转移性不应受到铸造代币能力的（from 参数的值为 0x0000000000000000000000000000000000000000）和销毁代币能力（to 参数的值为 0x0000000000000000000000000000000000000000）的影响。

如果代币的一般可转移性为 false，则代币的任何类型的转移，除了铸造和销毁之外，必须恢复执行。

为了确定代币是否可铸造，应该允许不存在的代币的 tokenId 参数。 此外，from 参数应为 0x0000000000000000000000000000000000000000，to 参数不应为 0x0000000000000000000000000000000000000000。

为了确定代币是否可销毁，from 参数不应为 0x0000000000000000000000000000000000000000，to 参数应为 0x0000000000000000000000000000000000000000。

实现者可以选择通过 from 参数来验证代币转移的批准，但与此函数交互的任何人都 不应 依赖它，因为它不是提案强制要求的。 这意味着此类实现中的 from 参数验证交易的发起者，而不是从中转移代币的所有者（可以是代币的所有者或允许转移代币的操作员）。

理由

在设计提案时，我们考虑了以下问题：

1. 鉴于现有的一些提案，甚至已经最终确定，我们是否应该提出另一个（非）可转移 NFT 提案，以及本提案与它们相比如何？
   本提案旨在为非可转移 NFT 的实施提供最少的必要规范，我们认为现有的提案都没有提出最小的必需接口。 与其他解决相同问题的提案不同，本提案在其规范中需要更少的方法，从而提供更简化的解决方案。
2. 为什么此接口中没有事件将代币标记为不可转移？
   代币可以在创建时、在被标记为不可转移之后或在满足特定条件之后变为不可转移。 这意味着某些代币变为不可转移的情况无法发出事件，例如，如果代币变为不可转移是由区块号确定的。 在代币变为不可转移时要求发出事件在这些情况下是不可行的。
3. 是否应在此提案中包含可转移性状态管理功能？
   将代币标记为不可转移或释放绑定的函数称为可转移性管理函数。 为了保持设计不可知最小可转移提案的目标，我们已决定不指定可转移性管理函数。 这允许各种需要代币不可转移的自定义实现。
4. 如果它只包含一个方法，为什么这应该是一个 EIP？
   有人可能会争辩说，由于本提案的核心只是为了防止 ERC-721 代币被转移，因此可以通过覆盖转移函数来完成。 虽然这是事实，但在智能合约执行之前，确保代币不可转移的唯一方法是使其具有可转移接口。
   这也允许智能合约验证代币是否不可转移，并且不要尝试转移它，因为这会导致交易失败并浪费 gas。
5. 我们是否应该包含最直接的方法，只接受一个 tokenId 参数？
   该提案的初始版本包含一个仅接受 tokenId 参数的方法。 此方法将返回一个布尔值，指示代币是否可转移。 但是，在整个讨论过程中，提出了代币可能因不同原因而不可转移的事实。 这就是为什么该方法被更改为接受其他参数，从而允许更灵活的实现。 此外，我们通过指定如何实现相同结果的方法（通过传递 0x0000000000000000000000000000000000000000 地址作为 to 和 from 参数）来保留了原始方法的功能。
6. 前端的最佳用户体验是什么？
   前端的最佳用户体验是拥有一个检查代币是否可转移的单一方法。 此方法应处理可转移性的一般情况和有条件的情况。
   前端还应该能够处理代币不可转移并且尝试转移的情况。 这可以通过检查转移函数的返回值来完成，如果代币不可转移，则该值为 false。 如果代币只是被设置为不可转移，而没有一个标准化的接口来检查代币是否可转移，那么验证可转移性的唯一方法是尝试 gas 计算并检查交易是否会恢复。 这是一种糟糕的用户体验，应避免。
7. 我们是否应该强制 isTransferable 也验证批准？
   我们考虑指定 from 参数表示代币转移的发起者。 这意味着 from 将验证该地址是否是代币的所有者或被批准转移它。 虽然这可能是有益的，但我们最终决定使其成为可选的。
   由于本提案旨在成为最小的可能实现，并且批准已经标准化，我们认为 isTransferable 可以与批准结合使用，以验证给定的地址是否可以发起转移。
   此外，强制验证批准会增加 gas 消耗，因为需要额外的检查来验证可转移性。

向后兼容性

最小化非可转让代币标准与 ERC-721 完全兼容，并且与可用于 ERC-721 实现的强大工具以及现有的 ERC-721 基础架构兼容。

测试用例

测试包含在 transferable.ts 中。

要在终端中运行它们，可以使用以下命令：

cd ../assets/eip-6454
npm install
npx hardhat test

参考实现

请参阅 ERC721TransferableMock.sol。

安全考虑

与 ERC-721 同样的安全考虑适用：隐藏的逻辑可能存在于任何函数中，包括销毁、添加资产、接受资产等。

智能合约可以实现提案接口，但返回欺诈值，即在代币可转移时为 isTransferable 返回 false。 这样的合约会欺骗其他合约，使其认为该代币不可转移，而实际上它是可转移的。 如果存在这样的合约，我们建议不要与其交互。 与欺诈性的 ERC-20 或 ERC-721 智能合约非常相似，无法阻止此类合约的存在。 我们建议您验证所有与您交互的外部智能合约，并且不要与您不信任的合约交互。

由于可转移性状态可能会随着时间的推移而改变，因此在与之交互之前验证代币的状态是否可转移至关重要。 因此，实现此接口的 dApp、市场或钱包应在每次显示代币时验证代币的状态。

建议在处理未经审核的合约时要谨慎。

版权

版权及相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Bruno Škvorc (@Swader), Francesco Sullo (@sullof), Steven Pineda (@steven2308), Stevan Bogosavljevic (@stevyhacker), Jan Turk (@ThunderDeliverer), "ERC-6454: 最小化可转移 NFT 检测接口," Ethereum Improvement Proposals, no. 6454, January 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6454.