ERC-721 Non-Fungible Token Standard

ERC-721,非同质性代币标准接口,在 ERC-721 中,代币都是唯一的。ERC-721 是几个月前才提出来的方案,CryptoKitties 这款使用 ERC-721 标准实现的收集虚拟猫游戏使得它备受瞩目。以太猫游戏实际就是智能合约中的非同质代币 (non-fungible token),并在游戏中用猫的形象来表现出来。ERC-721 兼容部分 ERC-20 标准接口,但是 ERC-721 跟 ERC-20 及其近亲系列有本质上的不同。

本文是以太坊官方EIP-721标准文档的译文,标准在不断迭代更新,请以官方最新为准!
原文:ERC-721 Non-Fungible Token Standard
原文链接:http://eips.ethereum.org/EIPS/eip-721

简介

A standard interface for non-fungible tokens, also known as deeds.
非同质性代币标准接口,也称为契约。

摘要

The following standard allows for the implementation of a standard API for NFTs within smart contracts. This standard provides basic functionality to track and transfer NFTs.
下面的标准允许在智能合约中实现 NFTs 的标准接口,这个标准提供了跟踪和传输 NFTs 的基本功能。

We considered use cases of NFTs being owned and transacted by individuals as well as consignment to third party brokers/wallets/auctioneers (“operators”). NFTs can represent ownership over digital or physical assets. We considered a diverse universe of assets, and we know you will dream up many more:

  • Physical property — houses, unique artwork
  • Virtual collectables — unique pictures of kittens, collectable cards
  • “Negative value” assets — loans, burdens and other responsibilities

我们考虑到当前个人拥有和交易的 NFTs 的用例,以及委托给第三方经纪人/钱包/交易所( “经营者” )的 NFTs 的用例。NFTs 可以代表对数字或实物资产的所有权。我们考虑了一个多样化的资产世界,我们知道你们创造出更多的实例:

  • 物质财产 — 房子, 唯一的艺术品
  • 虚拟藏品 — 唯一的小猫图片, 珍藏卡片
  • 负价值资产 — 贷款, 负担 和其它的责任

In general, all houses are distinct and no two kittens are alike. NFTs are distinguishable and you must track the ownership of each one separately.
大体上,所有的房子都是独特的,没有两只小猫是一样的,NFTs 是可区分的,你必须单独追踪每个个体的所有权。

动机

A standard interface allows wallet/broker/auction applications to work with any NFT on Ethereum. We provide for simple ERC-721 smart contracts as well as contracts that track an arbitrarily large number of NFTs. Additional applications are discussed below.
一个标准接口允许 Ethereum 上的所有非同质性代币能够在在钱包/经纪人/拍卖应用程序上工作。我们提供简单的 ERC-721 智能合约以及跟踪任意数量 NFTs 的合约。下面讨论其它应用程序。

This standard is inspired by the ERC-20 token standard and builds on two years of experience since EIP-20 was created. EIP-20 is insufficient for tracking NFTs because each asset is distinct (non-fungible) whereas each of a quantity of tokens is identical (fungible).
这一标准受到了 ERC-20 token 标准的启发,并建立在 EIP-20 制定两年的经验上。EIP-20不足以追踪 NFT,因为每个资产都是不同的(不可互换的),而每一个令牌都是相同的(可互换的)。

Differences between this standard and EIP-20 are examined below.
本标准和 EIP-20 之间的差异在下面进行了研究。

明确说明

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
本文件中的 “必须”,“不得”,“需要”,“应”,“不应”,“应该”,“不应该”,“推荐”,“可能” 和 “可选” 按照 RFC-2119 中的描述进行解释。

Every ERC-721 compliant contract must implement the ERC721 and ERC165 interfaces (subject to “caveats” below):
每个符合 ERC-721 标准的合约都必须实现 ERC721ERC165 接口(受以下 “注意事项” 的限制):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
pragma solidity ^0.4.20;

interface ERC721 /* is ERC165 */ {
event Transfer(address indexed _from, address indexed _to, uint256 _tokenId);
event Approval(address indexed _owner, address indexed _approved, uint256 _tokenId);
event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
function balanceOf(address _owner) external view returns (uint256);
function ownerOf(uint256 _tokenId) external view returns (address);
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
function approve(address _approved, uint256 _tokenId) external payable;
function setApprovalForAll(address _operator, bool _approved) external;
function getApproved(uint256 _tokenId) external view returns (address);
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

interface ERC165 {
function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

A wallet/broker/auction application MUST implement the wallet interface if it will accept safe transfers.
如果钱包/经纪人/拍卖程序要守到安全传输,则必须实现钱包接口

1
2
3
interface ERC721TokenReceiver {
function onERC721Received(address _from, uint256 _tokenId, bytes data) external returns(bytes4);
}

The metadata extension is OPTIONAL for ERC-721 smart contracts (see “caveats”, below). This allows your smart contract to be interrogated for its name and for details about the assets which your NFTs represent.
对于ERC-721智能合约,元数据扩展是可选的(参见下面的“注意事项”)。 这可以让你的智能合约能够被查询到名称,以及NFT代表的资产的详细信息。

1
2
3
4
5
interface ERC721Metadata /* is ERC721 */ {
function name() external pure returns (string _name);
function symbol() external pure returns (string _symbol);
function tokenURI(uint256 _tokenId) external view returns (string);
}

This is the “ERC721 Metadata JSON Schema” referenced above.
这是上面引用的 “ERC721 元数据 JSON 模式”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"title": "Asset Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset to which this NFT represents",
},
"description": {
"type": "string",
"description": "Describes the asset to which this NFT represents",
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
}
}
}

The enumeration extension is OPTIONAL for ERC-721 smart contracts (see “caveats”, below). This allows your contract to publish its full list of NFTs and make them discoverable.
对于 ERC-721 智能合约,枚举扩展是可选的(参见下面的 “注意事项”)。 这允许你的合约发布其 NFTs 的完整列表并使他们能够被发现。

1
2
3
4
5
6

interface ERC721Enumerable /* is ERC721 */ {
function totalSupply() external view returns (uint256);
function tokenByIndex(uint256 _index) external view returns (uint256);
function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256);
}

注意事项

The 0.4.20 Solidity interface grammar is not expressive enough to document the ERC-721 standard. A contract which complies with ERC-721 MUST also abide by the following:

  • Solidity issue #3412: The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: payable, implicit nonpayable, view, and pure. Your implementation MUST meet the mutability guarantee in this interface and you MAY meet a stronger guarantee. For example, a payable function in this interface may be implemented as nonpayble (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.20 is that you can edit this interface to add stricter mutability before inheriting from your contract.
  • Solidity issue #3419: A contract that implements ERC721Metadata or ERC721Enumerable SHALL also implement ERC721. ERC-721 implements the requirements of interface ERC-165.
  • Solidity issue #2330: If a function is shown in this specification as external then a contract will be compliant if it uses public visibility. As a workaround for version 0.4.20, you can edit this interface to switch to public before inheriting from your contract.
  • Solidity issues #3494, #3544: Use of this.*.selector is marked as a warning by Solidity, a future version of Solidity will not mark this as an error.

0.4.20版本Solidity接口语法不足以记录ERC-721标准。 符合ERC-721的合约也必须遵守以下规定:

  • Solidity issue#3412:上述接口包含每个函数的显式可变性保证。可变性保证按强弱排序:payable,隐式不付款,viewpure。你的实现必须满足这个接口中的可变性保证,你可以得到更强的保证。例如,此接口中的payable功能可能会被实现为你的合约中的nonpayble(没有指定状态可变性)。我们预计稍后的Solidity版本将允许你的合约y严格从此接口继承,但0.4.20版的解决方法是你可以编辑此接口以在继承合约之前添加更严格的可变性。
  • Solidity issue#3419:实现ERC721MetadataERC721Enumerable的合约也应实现ERC721标准接口,ERC-721还要实现ERC-165标准接口
  • Solidity issue#2330:如果一个函数在本规范中被显示为external,那么如果一个合约使用public可见性,它将符合规定。作为版本0.4.20的解决方法,你可以在继承合约之前编辑此接口以切换到“public”。
  • Solidity issue#3494,#3544:使用this.*.selector被Solidity标记为警告,未来版本中Solidity不会将其标记为错误。

If a newer version of Solidity allows the caveats to be expressed in code, then this EIP MAY be updated and the caveats removed, such will be equivalent to the original specification.
如果新版本的Solidity允许以代码表示注意事项,则可以更新此EIP并删除注意事项,这将与原始规范等效。

根本原因

There are many proposed uses of Ethereum smart contracts that depend on tracking distinguishable assets. Examples of existing or planned NFTs are LAND in Decentraland, the eponymous punks in CryptoPunks, and in-game items using systems like DMarket or EnjinCoin. Future uses include tracking real-world assets, like real-estate (as envisioned by companies like Ubitquity or Propy. It is critical in each of these cases that these items are not “lumped together” as numbers in a ledger, but instead each asset must have its ownership individually and atomically tracked. Regardless of the nature of these assets, the ecosystem will be stronger if we have a standardized interface that allows for cross-functional asset management and sales platforms.
以太坊智能合约的许多建议用途取决于跟踪可区分的资产。 现有或计划的NFT的例子有Decentraland的LAND,CryptoPunks中的同名小混混以及使用DMarket或EnjinCoin等系统的游戏内物品。 未来的用途包括追踪真实世界的资产,如房地产(正如Ubitquity或Propy等公司所设想的那样),在这些情况下,这些项目不会像数字一样“混在一起”,而是每个资产必须单独拥有自己的所有权并进行原子追踪。无论这些资产的性质如何,如果我们有一个允许跨职能资产管理和销售平台的标准化接口,生态系统将更加强大。

“NFT” 选词

“NFT” was satisfactory to nearly everyone surveyed and is widely applicable to a broad universe of distinguishable digital assets. We recognize that “deed” is very descriptive for certain applications of this standard (notably, physical property).
“NFT”几乎可以满足所有受访者的需求,并且广泛适用于广泛的可区分的数字资产。 我们认识到“契约”对于本标准的某些应用(特别是物理性质)是非常具有描述性的。

Alternatives considered: distinguishable asset, title, token, asset, equity, ticket
考虑替代方案:可区分的资产,所有权,令牌,资产,股权,票证

NFT 标识

Every NFT is identified by a unique uint265 ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair (contract address, uint265 tokenId) will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a “black box”. Also note that a NFTs MAY become invalid (be destroyed). Please see the enumerations functions for a supported enumeration interface.
每个NFT都由ERC-721智能合约中唯一的uint265 ID标识。 这个识别号码在合约期限内不会改变。 这对(合约地址,uint265 tokenId)将成为以太坊链上特定资产的全局唯一且完全合格的标识符。 尽管一些ERC-721智能合约可能会发现从ID 0开始并且每个新的NFT简单地增加一个便利,但呼叫者不应该假定ID号码具有任何特定模式,并且必须将该ID作为“黑匣子”。 另请注意,NFT可能会失效(被销毁)。 请参阅支持的枚举接口的枚举函数.

The choice of uint256 allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to uint256.
uint256的选择允许各种各样的应用程序,因为UUID和sha3哈希可直接转换为uint256

转移机制

ERC-721 standardizes a safe transfer function safeTransferFrom (overloaded with and without a bytes parameter) and an unsafe function transferFrom. Transfers may be initiated by:

  • The owner of an NFT
  • The approved address of an NFT
  • An authorized operator of the current owner of an NFT

ERC-721标准化了一个安全传输函数safeTransferFrom(带有或不带bytes参数的超载)和一个不安全的函数transferFrom。 转让可能由以下人员发起:

  • NFT的所有者
  • NFT的核准地址
  • NFT当前所有者的授权运营商

Additionally, an authorized operator may set the approved address for an NFT. This provides a powerful set of tools for wallet, broker and auction applications to quickly use a large number of NFTs.
另外,授权的运营商可以为NFT设置批准的地址。 这为钱包,经纪人和拍卖应用程序提供了一组强大的工具,可以快速使用大量* NFT。

The transfer and accept functions’ documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results:

  • Disallow transfers if the contract is paused — prior art, CryptoKitties deployed contract, line 611
  • Blacklist certain address from receiving NFTs — prior art, CryptoKitties deployed contract, lines 565, 566
  • Disallow unsafe transferstransferFrom throws unless _to equals msg.sender or countOf(_to) is non-zero or was non-zero previously (because such cases are safe)
  • Charge a fee to both parties of a transaction — require payment when calling approve with a non-zero _approved if it was previously the zero address, refund payment if calling approve with the zero address if it was previously a non-zero address, require payment when calling any transfer function, require transfer parameter _to to equal msg.sender, require transfer parameter _to to be the approved address for the NFT
  • Read only NFT registry — always throw from unsafeTransfer, transferFrom, approve and setApprovalForAll

转移和接受函数的文档仅指定事务必须抛出的条件,你的实现也可能会抛出其他情况, 这使得实现可以实现有趣的结果:

  • 如果合约暂停,禁止转让 - 现有技术,CryptoKitties已部署合约,第611行
  • 从接收NFT获得某个地址的黑名单 - 现有技术,CryptoKitties部署合约,第565,566行
  • 不允许不安全的传输 - transferFrom会抛出,除非_to等于msg.sendercountOf(_to)为非零或以前不为零(因为这样的情况是安全的)
  • 向交易双方收取费用 - 如果以前为零地址,则调用具有非零“_批准”的批准时需要付款,如果使用零地址调用批准,则需要退款支付 它以前是一个非零地址,在调用任何传输函数时需要付款,要求传输参数_to等于msg.sender,要求传输参数_to成为NFT的批准地址
  • 只读NFT注册表 - 总是抛出unsafeTransfertransferFromapprovesetApprovalForAll

Failed transactions will throw, a best practice identified in ERC-223, ERC-677, ERC-827 and OpenZeppelin’s implementation of SafeERC20.sol. ERC-20 defined an allowance feature, this caused a problem when called and then later modified to a different amount, as on OpenZeppelin issue #438. In ERC-721, there is no allowance because every NFT is unique, the quantity is none or one. Therefore we receive the benefits of ERC-20’s original design without problems that have been later discovered.
交易失败将引发ERC-223,ERC-677,ERC-827和OpenZeppelin实现SafeERC20.sol的最佳做法。 ERC-20定义了一个allowance功能,这个功能在被调用时会引发一个问题,然后再被修改为一个不同的数量,就像在OpenZeppelin issue#438上一样。 在ERC-721中没有限制,因为每个NFT都是唯一的,数量是0或者1(单位为1), 因此,我们可以获得ERC-20原创设计的好处,而不会遇到后来发现的问题。

Creating of NFTs (“minting”) and destruction NFTs (“burning”) is not included in the specification. Your contract may implement these by other means. Please see the event documentation for your responsibilities when creating or destroying NFTs.
NFTs的制造(“造币”)和销毁NFT(“燃烧”)没有包含在规范中, 你的合约可以通过其他方式实现;创建或销毁NFTs时,请参阅 事件 文档以了解你的责任。

Alternatives considered: only allow two-step ERC-20 style transaction, require that transfer functions never throw, require all functions to return a boolean indicating the success of the operation.
考虑的替代方案:只允许两步ERC-20风格的事务,要求传输函数永远不会抛出,要求所有函数返回一个表示操作成功的布尔值。

ERC-165 接口

We chose Standard Interface Detection (ERC-165) to expose the interfaces that a ERC-721 smart contract supports.
我们选择了标准接口检测(ERC-165)来展示ERC-721智能合约支持的接口。

A future EIP may create a global registry of interfaces for contracts. We strongly support such an EIP and it would allow your ERC-721 implementation to implement ERC721Enumerable, ERC721Metadata, or other interfaces by delegating to a separate contract.
未来的EIP可能会创建一个合约接口的全局注册表。 我们强烈支持这样一个EIP,它将允许你的ERC-721实现通过委托给一个单独的合约来实现“ERC721Enumerable”,“ERC721Metadata”或其他接口。

Gas 和复杂性(关于枚举扩展)

This specification contemplates implementations that manage a few and arbitrarily large numbers of NFTs. If your application is able to grow then avoid using for/while loops in your code (see CryptoKitties bounty issue #4). These indicate your contract may be unable to scale and gas costs will rise over time without bound.
本规范考虑了管理少数几个任意数量的NFT的实现。 如果你的应用程序能够增长,请避免在代码中使用for / while循环(请参阅CryptoKitties赏金问题#4)。 这表明你的合约可能无法扩展,gas成本会随着时间的推移而不受限制地增加。

We have deployed a contract, XXXXERC721, to Testnet which instantiates and tracks 340282366920938463463374607431768211456 different deeds (2^128). That’s enough to assign every IPV6 address to an Ethereum account owner, or to track ownership of nanobots a few micron in size and in aggregate totalling half the size of Earth. You can query it from the blockchain. And every function takes less gas than querying the ENS.
我们已经向Testnet部署了一个合约,XXXXERC721,用于实例化并跟踪340282366920938463463374607431768211456种不同的事迹(2^128)。 这足以将每个IPV6地址分配给Ethereum帐户所有者,或者追踪纳米机器人的所有权,这种纳米机器人的大小只有几微米,总计为地球的一半大小。 你可以从区块链查询它。 与查询ENS相比,每个功能所消耗的gas更少。

This illustration makes clear: the ERC-721 standard scales.
这个例子表明:ERC-721标准规模。

Alternatives considered: remove the asset enumeration function if it requires a for-loop, return a Solidity array type from enumeration functions.
考虑替代方案:如果资产枚举函数需要for循环,则从枚举函数返回Solidity数组类型。

隐私

Wallets/brokers/auctioneers identified in the motivation section have a strong need to identify which NFTs an owner owns.
在动机部分发现的钱包/经纪人/拍卖师有一个强烈的需要,来确定谁是拥有NTFs的主人。

It may be interesting to consider a use case where NFTs are not enumerable, such as a private registry of property ownership, or a partially-private registry. However, privacy cannot be attained because an attacker can simply (!) call ownerOf for every possible tokenId.
考虑NFT不可枚举的用例可能会很有趣,例如私人所有权登记或私人部分注册表。 然而,隐私是无法实现的,因为攻击者可以简单地(!)调用“ownerOf”以获得所有可能的“tokenId”。

元数据选择(元数据扩展)

We have required name and symbol functions in the metadata extension. Every token EIP and draft we reviewed (ERC-20, ERC-223, ERC-677, ERC-777, ERC-827) included these functions.
我们在元数据扩展中需要namesymbol功能, 每个EIP和我们审查的草案(ERC-20,ERC-223,ERC-677,ERC-777,ERC-827)都包含这些功能。

We remind implementation authors that the empty string is a valid response to name and symbol if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as your contract. How a client may determine which ERC-721 smart contracts are well-known (canonical) is outside the scope of this standard.
我们提醒实现作者,如果您反对使用该机制,那么空字符串是对namesymbol的有效响应。我们还提醒大家,任何聪明的合约都可以使用相同的名称和符号作为你的合同。客户如何去确定哪些ERC-721智能合约是众所周知的(canonical)不在本标准的范围内。

A mechanism is provided to associate NFTs with URIs. We expect that many implementations will take advantage of this to provide metadata for each NFT. The image size recommendation is taken from Instagram, they probably know much about image usability. The URI MAY be mutable (i.e. it changes from time to time). We considered an NFT representing ownership of a house, in this case metadata about the house (image, occupants, etc.) can naturally change.
提供了一种机制来将NFTs与URIs联系起来。我们期望许多实现将利用这一点为每个NFT提供元数据。图片大小的建议是从Instagram上获得的,他们可能对图像的可用性很了解。URI可能是可变的(也就是说,它不时地发生变化)。我们认为NFT代表了房子的所有权,在这种情况下,关于房子的元数据(图像、居住者等)可以自然地改变。

Metadata is returned as a string value. Currently this is only usable as calling from web3, not from other contracts. This is acceptable because we have not considered a use case where an on-blockchain application would query such information.
元数据作为字符串值返回。 目前这只适用于从web3调用,而不是来自其他合约。 这是可以接受的,因为我们还没有考虑过区块链应用程序会查询这些信息的用例。

Alternatives considered: put all metadata for each asset on the blockchain (too expensive), use URL templates to query metadata parts (URL templates do not work with all URL schemes, especially P2P URLs), multiaddr network address (not mature enough)
考虑替代方案:将每个资产的所有元数据放在区块链中(代价太高),使用URL模板查询元数据部分(URL模板不适用于所有URL方案,尤其是P2P URL),多网络地址(未足够成熟)

社区共识

A significant amount of discussion occurred on the original ERC-721 issue, additionally we held a first live meeting on Gitter that had good representation and well advertised (on Reddit, in the Gitter #ERC channel, and the original ERC-721 issue). Thank you to the participants:

  • @ImAllInNow Rob from DEC Gaming / Presenting Michigan Ethereum Meetup Feb 7
  • @Arachnid Nick Johnson
  • @jadhavajay Ajay Jadhav from AyanWorks
  • @superphly Cody Marx Bailey - XRAM Capital / Sharing at hackathon Jan 20 / UN Future of Finance Hackathon.
  • @fulldecent William Entriken

在最初的ERC-721问题上,我们进行了大量的讨论,此外,我们还举行了第一次关于Gitter的现场会议,该会议具有良好的代表性,并在Reddit(在Gitter #ERC频道)和最初的ERC-721问题上做了很好的宣传。感谢与会者:

  • @ImAllInNow来自DEC Gaming / Robing的密歇根以太坊聚会2月7日
  • @Arachnid尼克约翰逊
  • @jadhavajayAyanWorks的Ajay Jadhav
  • @superphly科迪马克思贝利 - XRAM资本/共享在hackathon 1月20日/联合国未来的财务黑客马拉松。
  • @fulldecentilliam Entriken

A second event was held at ETHDenver 2018 to discuss distinguishable asset standards (notes to be published).
在ETHDenver2018会议上举行了第二次会议,讨论可区分的资产标准(即将发布的备注)。

We have been very inclusive in this process and invite anyone with questions or contributions into our discussion. However, this standard is written only to support the identified use cases which are listed herein.
我们在这个过程中非常包容,邀请任何有问题或贡献的人参与我们的讨论。但是本标准仅用于支持所列出的已识别的用例。

向前兼容

We have adopted balanceOf, totalSupply, name and symbol semantics from the ERC-20 specification. An implementation may also include a function decimals that returns uint8(0) if its goal is to be more compatible with ERC-20 while supporting this standard. However, we find it contrived to require all ERC-721 implementations to support the decimals function.
我们已经从ERC-20规范中采用了balanceOftotalSupplynamesymbol语义。一个实现可能还包括一个函数decimals,它返回uint8(0),如果它的目标是与ERC-20更兼容,同时支持这个标准。但是,我们发现它需要所有ERC-721实现来支持decimals函数。

Example NFT implementations as of February 2018:

  • CryptoKitties – Compatible with an earlier version of this standard.
  • CryptoPunks – Partially ERC-20 compatible, but not easily generalizable because it includes auction functionality directly in the contract and uses function names that explicitly refer to the assets as “punks”.
  • Auctionhouse Asset Interface – The author needed a generic interface for the Auctionhouse ÐApp (currently ice-boxed). His “Asset” contract is very simple, but is missing ERC-20 compatibility, approve() functionality, and metadata. This effort is referenced in the discussion for EIP-173.

截至2018年2月的NFT实现示例:

  • CryptoKitties - 与此标准的早期版本兼容。
  • CryptoPunks - 与ERC-20部分兼容,但不易推广,因为它直接在合约中包含拍卖功能,并使用明确将资产称为“小块”的功能名称。
  • 拍卖行资产接口 - 作者需要AuctionhouseÐApp的通用接口(目前是冰盒)。 他的“资产”合约非常简单,但缺少ERC-20兼容性、approve()功能和元数据。 这项工作在EIP-173的讨论中被引用。

Note: “Limited edition, collectible tokens” like Curio Cards and Rare Pepe are not distinguishable assets. They’re actually a collection of individual fungible tokens, each of which is tracked by its own smart contract with its own total supply (which may be 1 in extreme cases).
注:“限量版,收藏品”如Curio Cards和Rare Pepe都不是可区分的资产。它们实际上是一组单独的可替换的代币,每一个都是由它自己的智能合约(在极端情况下可能是1)来跟踪的。

The onERC721Received function specifically works around old deployed contracts which may inadvertently return 1 (true) in certain circumstances even if they don’t implement a function (see Solidity DelegateCallReturnValue bug). By returning and checking for a magic value, we are able to distinguish actual affirmative responses versus these vacuous trues.
onERC721Received功能特别适用于旧的已部署的合约,在某些情况下,即使它们不执行某个功能(参见Solidity DelegateCallReturnValue bug),也可能在某些情况下不经意地返回1(true)。通过返回和检查一个神奇的值,我们能够区分实际的肯定回答和这些空洞的trues。

测试用例

待完成

Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.
对于正在影响协商一致变更的EIPs,执行的测试用例是强制性的。其他的EIPs可以选择包括测试用例的链接。。

实现

Su Squares – an advertising platform where you can rent space and place images

  • Complete the Su Squares Bug Bounty Program to seek problems with this standard or its implementation
  • Implements the complete standard and all optional interfaces

ERC721ExampleDeed – an example implementation

  • Implements using the OpenZeppelin project format

XXXXERC721, by William Entriken – a scalable example implementation

  • Deployed on testnet with 1 billion assets and supporting all lookups with the metadata extension. This demonstrates that scaling is NOT a problem.

Su Squares - 你可以租用空间和放置图像的广告平台

  • 完成Su Squares Bug赏金程序,以寻求本标准或其实现方面的问题
  • 实现完整的标准和所有可选接口

ERC721ExampleDeed – 一个实现例子

  • 使用OpenZeppelin项目格式实现

XXXXERC721, by William Entriken – 一个可扩展的示例实现

  • 在具有10亿资产的测试网上部署,并支持具有元数据扩展名的所有查找。 这表明缩放不成问题。

参考

标准

  1. ERC-20 Token Standard.
  2. ERC-165 Standard Interface Detection.
  3. ERC-173 Owned Standard.
  4. ERC-223 Token Standard.
  5. ERC-677 transferAndCall Token Standard.
  6. ERC-827 Token Standard.
  7. Ethereum Name Service (ENS).
  8. Instagram – What’s the Image Resolution?
  9. JSON Schema.
  10. Multiaddr.
  11. [RFC 2119 Key words for use in RFCs to Indicate Requirement Levels.

议题

  1. The Original ERC-721 Issue.
  2. Solidity Issue #2330 – Interface Functions are Axternal.
  3. Solidity Issue #3412 – Implement Interface: Allow Stricter Mutability.
  4. Solidity Issue #3419 – Interfaces Can’t Inherit.
  5. Solidity Issue #3494 – Compiler Incorrectly Reasons About the selector Function.
  6. Solidity Issue #3544 – Cannot Calculate Selector of Function Named transfer.
  7. CryptoKitties Bounty Issue #4 – Listing all Kitties Owned by a User is O(n^2).
  8. OpenZeppelin Issue #438 – Implementation of approve method violates ERC20 standard.
  9. Solidity DelegateCallReturnValue Bug.

讨论

  1. Reddit (announcement of first live discussion).
  2. Gitter #EIPs (announcement of first live discussion).
  3. ERC-721 (announcement of first live discussion).
  4. ETHDenver 2018.

NFT实现和其他项目

  1. CryptoKitties.
  2. Su Squares.
  3. Decentraland.
  4. CryptoPunks.
  5. DMarket.
  6. Enjin Coin.
  7. Ubitquity.
  8. Propy.
  9. CryptoKitties Deployed Contract.
  10. Su Squares Bug Bounty Program.
  11. XXXXERC721.
  12. ERC721ExampleDeed.
  13. Curio Cards.
  14. Rare Pepe.
  15. Auctionhouse Asset Interface.
  16. OpenZeppelin SafeERC20.sol Implementation.

版权

Copyright and related rights waived via CC0.
版权和相关权利通过 CC0 协议放弃。

0%