ERC-2309: ERC-721 连续转移扩展

简单总结

一个标准化的事件，用于在使用连续 token 标识符创建/转移一个或多个非同质化 token 时发出。

摘要

可选的 ERC-721 连续转移扩展提供了一个标准化的事件，该事件可以在创建/转移一个或多个非同质化 token 期间发出。此标准并未设定您可能如何创建/转移多个 token 的预期，它仅关注在创建或转移这些 token 的所有权之后发出的事件。此扩展假设 token 标识符按连续顺序排列。

动机

此扩展提供了 ERC-721 规范 的更高扩展性。可以在一个交易中创建、转移和销毁 2^256 个非同质化 token。但是，在一个交易中发出如此多的 Transfer 事件是不可能的。Transfer 事件是原始规范的一部分，其中指出：

当任何 NFT 的所有权通过任何机制发生变化时，都会发出此事件。 此事件在 NFT 被创建 (from == 0) 和销毁 (to == 0) 时发出。例外：在合约创建期间，可以创建和分配任意数量的 NFT，而无需发出 Transfer 事件。在 任何转移时，该 NFT 的已批准地址（如果有）将重置为 none。

这允许为每个 token 发出原始的 Transfer 事件，进而使我们获得 O(n) 的时间复杂度。可以使用有效的数据结构在一个交易中发行 10 亿个 NFT，但为了发出 Transfer 事件 —— 根据原始规范 —— 需要一个具有 10 亿次迭代的循环，这势必会耗尽 gas 或超出交易超时限制。使用当前规范无法完成此操作。此扩展解决了该问题。

许多去中心化市场和区块浏览器利用 Transfer 事件来确定地址拥有哪些 NFT。连续转移扩展为这些平台提供了一种标准机制，用于确定多个 token 的所有权。

规范

本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”应按照 RFC 2119 中的描述进行解释。

符合 ERC-721 标准的合约 MAY 实现此连续转移扩展，以提供一个标准事件，该事件在创建、销毁或转移一个或多个连续 token 时发出

执行交易的地址 MUST 拥有 fromTokenId 和 toTokenId 范围内的所有 token，或者 MUST 是经批准的运营商，可以代表所有者行事。

fromTokenId 和 toTokenId MUST 是 token ID 的连续范围。

fromTokenId、fromAddress 和 toAddress MUST 是索引参数

toTokenId MUST NOT 是索引参数

在铸造/创建 token 时，fromAddress 参数 MUST 设置为 0x0（即零地址）。

在销毁 token 时，toAddress 参数 MUST 设置为 0x0（即零地址）。

在发出 ConsecutiveTransfer 事件时，MUST NOT 发出 Transfer 事件

实现了 ConsecutiveTransfer 事件的合约 MAY 仍然可以使用原始的 Transfer 事件，但是当发出 ConsecutiveTransfer 事件时，MUST NOT 发出 Transfer 事件。

  event ConsecutiveTransfer(uint256 indexed fromTokenId, uint256 toTokenId, address indexed fromAddress, address indexed toAddress);

示例

ConsecutiveTransfer 事件可以用于单个 token 以及多个 token：

创建单个 token

emit ConsecutiveTransfer(1, 1, address(0), toAddress);

批量创建 token

emit ConsecutiveTransfer(1, 100000, address(0), toAddress);

批量转移 token

emit ConsecutiveTransfer(1, 100000, fromAddress, toAddress);

销毁

emit ConsecutiveTransfer(1, 100000, from, address(0));

理由

标准化 ConsecutiveTransfer 事件为去中心化平台提供了一种标准方式来确定大量非同质化 token 的所有权，而无需支持新的 token 标准。有很多方法可以实现 NFT 的批量创建和转移。连续转移扩展允许合约创建者以他们认为合适的方式实现批量创建、转移和销毁方法，但提供了一个标准化的事件，所有实现都可以使用。通过指定一系列连续的 token 标识符，我们可以轻松覆盖 2^(256) 个 token 的转移或创建，并且去中心化平台可以做出相应的反应。

举个例子。我出售神奇水果，并有一个拥有 10,000 棵神奇果树的农场，每棵树都有不同的水果，并且每隔几年就会有 1,000 棵新树。我想把每棵树变成人们可以拥有的非同质化 token。拥有我的非同质化树 token 的每个人都将收到该树每次收获的季度百分比。问题是我需要单独创建和转移每个 token —— 这将花费我大量的时间和金钱，坦率地说，会阻止我这样做。

有了这个扩展，我就可以在一个交易中铸造最初的 10,000 个树 token。当种植一批新的树时，我能够快速且廉价地铸造额外的 1,000 个树 token。然后，我可以将所有 10,000 多个树 token 转移到一个特殊的智能合约中，该合约在一个交易中跟踪资金的销售和分配，同时遵守指定的标准。

拥有一个涵盖铸造、销毁和转移的单一事件的理由

ConsecutiveTransfer 事件可用于涵盖铸造、销毁和转移事件。虽然最初坚持从/向“0”转移的模式可能会造成混淆，但可以通过检查 ConsecutiveTransfer 主题并使用 ERC-165 标准验证发出事件的合约是否支持 ERC-721 接口来缓解这种情况。

索引事件参数

Solidity 中的事件最多可以有三个索引参数，这将可以过滤索引参数的特定值。此标准将 fromAddress、toAddress 和 fromTokenId 设置为索引参数。toTokenId 可以从日志的数据部分检索。这样做的原因是，通常人们可能会搜索事件以了解给定地址的所有权历史。然后可以检索 fromTokenId 以及其他两个索引参数，以简化操作。然后只需要解码日志数据，这可以确保是 toTokenId。

在也发出 ConsecutiveTransfer 时不发出 Transfer 的理由

这可能会导致错误，并且对于使用这些事件跟踪 token 所有权的平台来说，会导致不必要的复杂逻辑。在转移单个 token 时，可以接受发出原始的 Transfer 事件，但在同一交易期间不应发出 ConsecutiveTransfer 事件，反之亦然。

比较 2309 和 1155

随着 NFT 市场的持续增长，扩展智能合约能力的需求也在增长。用户需要能够一次性铸造大量 token、转移大量 token，并且能够跟踪所有这些资产的所有权。我们需要以一种经济高效的方式做到这一点，并且不会在以太坊区块链的限制下失败。随着数百万个 token 的铸造，我们需要具有扩展能力的合约。

ERC-1155 于 2019 年创建并添加为标准，旨在解决这些问题，但在以经济高效的方式铸造大量独特 token 时，它显得不足。使用 ERC-1155，要么花费数百（或数千）美元，要么耗尽 gas。ERC-1155 在铸造许多半同质化 token 时效果良好，但在铸造许多独特 token 时则显得不足。使用 2309 标准，您可以预先铸造数百万个空白 NFT，并以经济高效的方式更新每个 NFT 的元数据。

向后兼容性

此扩展的编写目的是允许对原始 ERC-721 规范进行尽可能小的更改，同时仍然提供一种机制来跟踪大量 token 的创建、转移和删除。虽然这是一个最小的更改，但对于仅使用原始 Transfer 事件来索引 token 所有权的平台的影响将是严重的。他们将无法正确记录可以通过侦听 ConsecutiveTransfer 事件来了解的 token 所有权信息。对于希望支持 ConsecutiveTransfer 事件的平台，最好同时支持原始 Transfer 事件和 ConsecutiveTransfer 事件来跟踪 token 所有权。

安全考虑

没有与此标准的实施直接相关的安全考虑因素。

版权

在 CC0 下放弃版权和相关权利。

Citation

Please cite this document as:

Sean Papanikolas (@pizzarob), "ERC-2309: ERC-721 连续转移扩展," Ethereum Improvement Proposals, no. 2309, October 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2309.