ERC-721¶

ERC-721 é o padrão para tokens não fungíveis, onde o ERC-20 regista uma quantidade intercambiável por endereço (ver ERC-20), ERC-721 rastreia a propriedade de tokens individualmente distintas, não intercambiáveis, cada uma identificada por sua própria ID única. Este capítulo abrange a interface principal e o mecanismo específico (transferências seguras) que o ERC-721 tem e o ERC-20 não.

A interface do núcleo¶

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface IERC721 {
    function balanceOf(address owner) external view returns (uint256);
    function ownerOf(uint256 tokenId) external view returns (address);
    function transferFrom(address from, address to, uint256 tokenId) external;
    function safeTransferFrom(address from, address to, uint256 tokenId) external;
    function approve(address to, uint256 tokenId) external;
    function getApproved(uint256 tokenId) external view returns (address);
    function setApprovalForAll(address operator, bool approved) external;
    function isApprovedForAll(address owner, address operator) external view returns (bool);

    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
}

Verificado: isto compila-se perfeitamente com solc 0.8.26.

Fungible versus não-fungible, no nível de interface¶

Aviso balanceOf aqui retorna quantas tokens distintas um endereço próprio (uma contagem, não uma quantidade fungível) e ownerOf(tokenId) responde "quem é o dono disto específico token", uma pergunta que não tem ERC-20 equivalente em tudo, uma vez que ERC-20 tokens não têm identidade individual para fazer essa pergunta. Esta é a expressão precisa, nível de interface de fungibilidade: ERC-20 pergunta "quanto", ERC-721 pergunta "qual deles, e quem é o dono".

Dois níveis de aprovação¶

O ERC-721 possui dois mecanismos de aprovação distintos, que servem âmbitos diferentes:

approve(to, tokenId): autoriza a transferência de um endereço específico um símbolo específico, diretamente análogo ao ERC-20 approve, mas escopo para uma única identificação token em vez de uma quantidade fungível.
setApprovalForAll(operator, approved): autoriza a transferência de um endereço qualquer e cada token o chamador atualmente possui ou sempre possuirá, uma subvenção muito mais ampla usada pelos mercados (então um usuário não precisa enviar uma transação de aprovação separada para cada NFT individual que eles querem listar para venda).

seguroTransferDe: o mecanismo ERC-20 falta¶

Esta é a característica que vale a pena compreender precisamente, uma vez que aborda um modo de falha real e documentado. transferFrom move um token incondicionalmente (se o endereço do destinatário for um contrato sem lógica para lidar com os tokens ERC-721 recebidos, o token pode tornar-se permanentemente preso, uma vez que esse contrato pode não ter qualquer função capaz de transferi-lo de volta. safeTransferFrom fecha esta lacuna: se o destinatário for um contrato, exige que esse contrato seja executado onERC721Received (uma chamada de volta as chamadas de transferência e verifica o valor de retorno de) e reverte toda a transferência se essa verificação falhar) uma verificação de segurança real, protocolo-forçada, não apenas uma convenção, que ERC-20 não tem qualquer equivalente de Transferências: uma norma ERC-20 transfer não tem como ser rejeitado ou verificado pelo destinatário).

interface IERC721Receiver {
    function onERC721Received(
        address operator,
        address from,
        uint256 tokenId,
        bytes calldata data
    ) external returns (bytes4);
}

O retorno de chamada deve retornar um valor de 4-byte específico (o seletor de função de onERC721Received para confirmar o contrato de recepção realmente implementa esta interface e pretende aceitar o token, devolvendo qualquer outra coisa, ou revertendo, causas safeTransferFrom para reverter toda a transferência, protegendo-se contra exatamente o cenário emperrado descrito acima.

Conceitos errôneos comuns¶

Os tokens ERC-721 não são armazenados "dentro" do contrato NFT no sentido de manter qualquer mídia ou dados de arquivo diretamente. O contrato armazena apenas registros de propriedade (que endereço possui qual ID do token) e, normalmente, um URI apontando para metadados descrevendo o token, coberto totalmente em Metadados NFT; a imagem real, vídeo ou outro ativo que um NFT é frequentemente associado com geralmente vive totalmente fora da cadeia.

transferFrom sobre um contrato ERC-721 não é depreciado ou inseguro para usar em todos os contextos. Permanece válido, conforme padrão, e apropriado quando o remetente sabe que o destinatário pode definitivamente lidar com o token (uma conta externa comum, por exemplo, que não tem onERC721Received requisitos, uma vez que a preocupação em matéria de segurança diz especificamente respeito aos beneficiários do contrato; safeTransferFrom é o padrão mais cauteloso especificamente para transferências para endereços cuja capacidade de lidar com o token ainda não é conhecida.

Outras leituras¶

← Anterior: Subsídios e aprovações · Voltar aos Tokens · Próximo: ERC-1155 →