Análise de segurança do contrato inteligente ERC 1155 NFT

Tempo de leitura: 5 minutos

Você deve ter ouvido falar sobre tokens de criptomoeda. Vários tokens desempenham um papel vital no ecossistema web3. Esses tokens representam propriedade, riqueza, credibilidade e autoridade em criptomoedas. A parte divertida é que você também pode criar seu token de criptomoeda. 

Esses tokens são contratos inteligentes que envolvem várias funções para diversas ações, como transferência, verificação de saldo, etc. Você pode criar seu token criando um contrato inteligente para ele. Ainda assim, para garantir que seu token esteja seguro e atribuir a ele um senso de confiança, o ERC 20 é o padrão de contrato inteligente que é aconselhável seguir para criar tokens fungíveis, e ERC 721 é o padrão de contrato inteligente usado para criar tokens não fungíveis (NFTs).

ERC 20 e ERC 721 são protocolos de contratos inteligentes amplamente aceitos para criação de tokens. Eles fornecem um ambiente seguro e confiável para os tokens. E esses protocolos continuam melhorando e melhorando. Um passo nessa direção leva à criação de um novo protocolo de contrato inteligente ERC 1155 para tokens. Vamos ver o que é.

1. O que é ERC 1155?

Todos os ERCs, como 20 e 721, são apenas padrões para a criação de contratos inteligentes que se adaptam a diferentes circunstâncias para NFTs. Temos ERC 721, e tokens fungíveis como USDT e DAI seguem os padrões ERC 20. ERC 1155 é um padrão que envolve funções e propriedades ERC 20 e ERC 721.

Suponha que você queira criar um programa onde você cria múltiplas mercadorias. Por exemplo, você deseja criar um token chamado ouro, outro token chamado prata e um rei, e a lógica diz que aquele com mais ouro e prata será o rei. Só pode haver um rei. É um protocolo simples, mas para criá-lo você terá que implantar 3 contratos apenas para ativos, um para um token de ouro, outro para prata e um para o rei, que será o ERC 721. Mas e se você puder implantar apenas um contrato listando todos esses tokens diferentes?

Este é um problema que o ERC 1155 resolve. Você não precisa implantar um contrato para cada um dos tokens que deseja no blockchain. Este foi um exemplo de contrato ERC 1155. Adivinhe onde precisamos desse tipo de sistema com múltiplos ativos, alguns fungíveis, outros não fungíveis. A resposta são jogos web3. O ERC 1155 capacita desenvolvedores de jogos Web3 com escalabilidade e desenvolvimento tranquilo para transações em cadeia.

1.1 IDs de token em ERC 1155

Você deve estar ciente de como o saldo em diferentes tokens ERC 20 pode ser verificado, basta ligar balanceOF(endereço _proprietário) função, e você pode obter quantos tokens esse endereço contém. Mas o ERC 1155 lida com tokens diferentes, por isso precisamos fornecer IDs diferentes para tokens diferentes. Quase todas as funções relacionadas a tokens levam em pelo menos dois parâmetros o tokenId (ativo que você deseja consultar) e o endereço que você deseja saber.

Por exemplo, digamos que o contrato tenha 3 fichas, ouro, prata e rei. Para saber quanto ouro um determinado endereço possui nesse protocolo, você pode chamar a função balanceOf(endereço _proprietário, uint256 _id) no contrato inteligente. Suponha que o tokenId para ouro seja especificado como 1. Então você pode chamar saldoOf(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096, 1).

2 Diretrizes de Auditoria para Contrato Inteligente ERC 1155

O ERC 1155 já existe há algum tempo e alguns recursos não estão disponíveis no protocolo ERC 20 ou ERC 721 regular, como a transferência em lote. Além disso, o ERC 1155 é menos prevalente no mercado, tornando esta área um pouco menos explorada por muitos desenvolvedores. QuillAudits compartilha insights cruciais para os protocolos que buscam BUIDL no ERC 1155, para que possam ajudar a criar um ecossistema web3 mais seguro, protegendo-se. 

2.1 Interface do receptor ERC 1155

Quando nosso contrato ERC 1155 transfere ativos para algum outro contrato, o que geralmente é um requisito no protocolo de jogo web3, é IMPORTANTE ter a interface do receptor ERC1155 no contrato de recebimento para a transação bem-sucedida dos tokens.

Duas funções que fazem parte da interface do receptor ERC 1155 são: -

• onERC1155Recebido(operador, de, id, valor, dados)
• onERC1155BatchReceived(operador, de, ids, valores, dados)

Ambas as funções possuem funcionalidades quase semelhantes, a única diferença é que a última é quando estamos lidando com mais de uma transação ao mesmo tempo, daí o nome batch, há uma pequena diferença entre os parâmetros e os valores de retorno. Mas aqui falaremos apenas sobre onERC1155Received. 

Esta função NÃO DEVE ser chamada fora de um processo de cunhagem ou transferência. Para aceitar a transferência, ele deve retornar bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)) se a transferência for permitida.

Olhando para os parâmetros: -

1. operador: - O endereço que iniciou a transferência (ou seja, msg.sender) 
2. de: - O endereço que anteriormente possuía o token
3. id: - O ID do token que está sendo transferido 
4. valor: - O número de tokens sendo transferidos 
5. dados: - Dados adicionais sem formato especificado 

2.2 Não há função de aprovação()?

Se você já trabalhou com ERC 20 ou ERC 721, você deve ter encontrado a função aprovar(), que permite que algum endereço retire os tokens aprovados do saldo do proprietário. Por exemplo, se A quiser aprovar B para receber 100 tokens de DAI, então A pode chamar a função de aprovação, dizendo que B tem direito a 100 tokens de DAI e, posteriormente, B pode fazer uma transação com esse valor.

Mas o ERC 1155 não tem um aprovar função para um único token. Nós temos uma setApprovalForAll(operador de endereço, bool aprovado) função, que é chamada pelo proprietário e recebe um operador de parâmetro de endereço, que é o endereço do gastador ou daquele para quem queremos aprovar nossos tokens. Então, não podemos chamar um aprovar funcionar ou conceder aprovação para um único token de nossa lista de tokens ERC 1155, mas em vez disso, todo o acesso ao token será aprovado de uma só vez. A equipe de desenvolvimento precisa estar ciente disso. Se ignorado, isto pode levar a perdas massivas e comprometer o protocolo.

2.3 Algumas verificações regulares

As duas seções acima exploraram duas das verificações exclusivas relacionadas ao ERC 1155. Nesta seção, passaremos por algumas verificações regulares que não precisam de uma explicação muito profunda.

1. Cuidado com os IDs: – Toda função ou interface externa que funciona com o ERC 1155 precisa ter o ID do token especificado para recebê-lo como entrada.
2. Burn/Mint: - Sempre que essas funções são chamadas, elas devem apenas alterar o saldo e totalSupply para o ID do token especificado.
3. Semelhança do ERC 20: - Muitas propriedades são como o padrão de token ERC 20. Seguir as diretrizes de segurança do ERC 20 também ajudará nesse assunto.
4. Reentrada: - Conforme discutido, o ERC 1155 verifica a interface suportada na lógica de transferência. Assim, pode haver vários cenários que podem resultar em vulnerabilidade de reentrada. É aconselhável manter modificadores de guarda sem reentrada nas funções aplicáveis.

3. Conclusão

O ecossistema Web3 vê desenvolvimento contínuo em padrões regulares para aumentar a segurança e a funcionalidade. A ERC 1155 é um passo nessa direção. Mas quando os novos padrões são lançados, cria-se uma lacuna de conhecimento envolvendo padrões não tão comuns em protocolos e surge o risco de um espaço amostral menor para medidas de segurança. É aí que a QuillAudits entra em cena com uma equipe de especialistas. Abordamos, analisamos e encontramos diferentes maneiras pelas quais o protocolo pode ser comprometido e protegemos o protocolo de nossos clientes com resultados inacreditáveis. Visite nosso site e garanta seu projeto Web3!

17 Visualizações

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. Acesse aqui.
• Fonte: https://blog.quillhash.com/2023/02/20/security-analysis-of-the-erc-1155-nft-smart-contract/