Vyper ERC-721 Contract Walkthrough
Introduction
The ERC-721 standard is used to hold the ownership of Non-Fungible Tokens (NFT). ERC-20 tokens behave as a commodity, because there is no difference between individual tokens. In contrast to that, ERC-721 tokens are designed for assets that are similar but not identical, such as different cat cartoons or titles to different pieces of real estate.
In this article we will analyze Ryuya Nakamura's ERC-721 contract. This contract is written in Vyper, a Python-like contract language designed to make it harder to write insecure code than it is in Solidity.
The Contract
1# @dev Implementation of ERC-721 non-fungible token standard.2# @author Ryuya Nakamura (@nrryuya)3# Modified from: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy4Salin
Comments in Vyper, as in Python, start with a hash (#) and continue to the end of the line. Comments that include
@<keyword> are used by NatSpec to produce human-readable
documentation.
1from vyper.interfaces import ERC72123implements: ERC7214Salin
The ERC-721 interface is built into the Vyper language. You can see the code definition here. The interface definition is written in Python, rather than Vyper, because interfaces are used not only within the blockchain, but also when sending the blockchain a transaction from an external client, which may be written in Python.
The first line imports the interface, and the second specifies that we are implementing it here.
The ERC721Receiver Interface
1# Interface for the contract called by safeTransferFrom()2interface ERC721Receiver:3 def onERC721Received(4Salin
ERC-721 supports two types of transfer:
transferFrom, which lets the sender specify any destination address and places the responsibility for the transfer on the sender. This means that you can transfer to an invalid address, in which case the NFT is lost for good.safeTransferFrom, which checks if the destination address is a contract. If so, the ERC-721 contract asks the receiving contract if it wants to receive the NFT.
To answer safeTransferFrom requests a receiving contract has to implement ERC721Receiver.
1 _operator: address,2 _from: address,3Salin
The _from address is the current owner of the token. The _operator address is the one that
requested the transfer (those two may not be the same, because of allowances).
1 _tokenId: uint256,2Salin
ERC-721 token IDs are 256 bits. Typically they are created by hashing a description of whatever the token represents.
1 _data: Bytes[1024]2Salin
The request can have up to 1024 bytes of user data.
1 ) -> bytes32: view2Salin
To prevent cases in which a contract accidentally accepts a transfer the return value is not a boolean, but 256 bits with a specific value.
This function is a view, which means it can read the state of the blockchain, but not modify it.
Events
Events are emitted to inform users and servers outside of the blockchain of events. Note that the content of events is not available to contracts on the blockchain.
1# @dev Emits when ownership of any NFT changes by any mechanism. This event emits when NFTs are2# created (`from` == 0) and destroyed (`to` == 0). Exception: during contract creation, any3# number of NFTs may be created and assigned without emitting Transfer. At the time of any4# transfer, the approved address for that NFT (if any) is reset to none.5# @param _from Sender of NFT (if address is zero address it indicates token creation).6# @param _to Receiver of NFT (if address is zero address it indicates token destruction).7# @param _tokenId The NFT that got transferred.8event Transfer:9 sender: indexed(address)10 receiver: indexed(address)11 tokenId: indexed(uint256)12Tunjukkan semuaSalin
This is similar to the ERC-20 Transfer event, except that we report a tokenId instead of an amount.
Nobody owns address zero, so by convention we use it to report creation and destruction of tokens.
1# @dev This emits when the approved address for an NFT is changed or reaffirmed. The zero2# address indicates there is no approved address. When a Transfer event emits, this also3# indicates that the approved address for that NFT (if any) is reset to none.4# @param _owner Owner of NFT.5# @param _approved Address that we are approving.6# @param _tokenId NFT which we are approving.7event Approval:8 owner: indexed(address)9 approved: indexed(address)10 tokenId: indexed(uint256)11Tunjukkan semuaSalin
An ERC-721 approval is similar to an ERC-20 allowance. A specific address is allowed to transfer a specific token. This gives a mechanism for contracts to respond when they accept a token. Contracts cannot listen for events, so if you just transfer the token to them they don't "know" about it. This way the owner first submits an approval and then sends a request to the contract: "I approved for you to transfer token X, please do ...".
This is a design choice to make the ERC-721 standard similar to the ERC-20 standard. Because ERC-721 tokens are not fungible, a contract can also identify that it got a specific token by looking at the token's ownership.
1# @dev This emits when an operator is enabled or disabled for an owner. The operator can manage2# all NFTs of the owner.3# @param _owner Owner of NFT.4# @param _operator Address to which we are setting operator rights.5# @param _approved Status of operator rights(true if operator rights are given and false if6# revoked).7event ApprovalForAll:8 owner: indexed(address)9 operator: indexed(address)10 approved: bool11Tunjukkan semuaSalin
It is sometimes useful to have an operator that can manage all of an account's tokens of a specific type (those that are managed by a specific contract), similar to a power of attorney. For example, I might want to give such a power to a contract that checks if I haven't contacted it for six months, and if so distributes my assets to my heirs (if one of them asks for it, contracts can't do anything without being called by a transaction). In ERC-20 we can just give a high allowance to an inheritance contract, but that doesn't work for ERC-721 because the tokens are not fungible. This is the equivalent.
The approved value tells us whether the event is for an approval, or the withdrawal of an approval.
State Variables
These variables contain the current state of the tokens: which ones are available and who owns them. Most of these
are HashMap objects, unidirectional mappings that exist between two types.
1# @dev Mapping from NFT ID to the address that owns it.2idToOwner: HashMap[uint256, address]34# @dev Mapping from NFT ID to approved address.5idToApprovals: HashMap[uint256, address]6