Os 375 mil motivos para melhorar o ERC20

Com juggernauts baseados em tokens ERC20, como EOS, Basic Attention Token (BAT) e Storj, é difícil discutir o sucesso do contrato de interface. A comunidade Ethereum obteve apoio claramente em torno deste padrão, & tanto as comunidades de desenvolvedores quanto os mercados financeiros estão respondendo positivamente. No entanto, apesar de todo o seu sucesso, o padrão ERC20 resultou em um bug não tão insignificante:

O padrão de token ERC20 está levando a perdas de dinheiro para os usuários finais, permitindo que os usuários enviem tokens ERC20 para endereços de token não compatíveis com ERC20.

Quando um usuário envia um token ERC20 para um contrato Ethereum que não reconhece tokens ERC20, o usuário perde o acesso aos seus fundos para sempre. Exatamente quantos fundos estão bloqueados atualmente devido a esse problema? Novamente, não é uma quantidade insignificante:

  • 310.067 GNT estão presos no contrato Golem (atualmente vale cerca de $ 217K).
  • 242 REP estão presos no contrato de agosto (atualmente vale cerca de $ 15K).
  • 814 DGD estão presos no contrato Digix DAO (atualmente vale cerca de $ 125K).
  • 14.506 1ST estão presos no contrato FirstBlood (atualmente no valor de cerca de $ 12K).

Isso representa mais de $ 370 mil + em tokens ERC20 que estão congelados nesses contratos; como a lista de tokens ERC20 está crescendo, esse número provavelmente é uma subestimativa conservadora da quantidade total desses tokens congelados em contratos. A lista acima não é exaustiva – estes são apenas alguns dos tokens ERC20 mais populares.

Nenhum dos contratos acima esperava receber quaisquer tokens ERC20 – portanto, quando os usuários enviam tokens para esses endereços, as transações são confirmadas pela rede; no entanto, o contrato de recebimento não reconhece os tokens. Ele não sabe o que fazer com esses tokens, o que resulta no bloqueio dos fundos para sempre. Novamente, os tokens não são rejeitados – eles são totalmente ignorados pelo contrato de recebimento.

A maioria dessas transações são involuntariamente confirmadas por usuários finais chamando o transferir (ao contrário da função transferFrom automatizada introduzida anteriormente). Lembre-se de que ERC20 faz uso de ambos & TransferFrom – como parece que alguns usuários finais estão usando Transfer para enviar tokens ERC20 diretamente para contratos que não estão esperando, & portanto, não reconheço, os tokens recebidos.

Por fim, alguns membros da comunidade Ethereum decidiram enfrentar esse problema de frente, solicitando um novo padrão de token ERC. O número do problema desse novo padrão de token no GitHub é o número 223.

Proposta ERC223

O usuário do GitHub Dexaran sugeriu um novo padrão ERC (ERC223) em 5 de março de 2017 que visava corrigir esse problema de falha de fallback de token. O resumo de sua nova proposta de token no número 223 do GitHub é o seguinte:

O seguinte descreve as funções padrão que um contrato de token e um contrato trabalhando com o token especificado podem implementar para evitar o envio acidental de tokens para contratos e fazer com que as transações de token se comportem como transações ether.

A proposta de token de Dexaran implementa dois recursos principais para impedir imediatamente que usuários de aplicativos descentralizados enviem tokens acidentalmente para contratos inteligentes que não estão prontos para receber os referidos tokens:

  1. Consolidando o ERC20 Transferir & Transferir de funções em um único Transferir função com três parâmetros: (endereço _to, uint _value, bytes de dados).
  2. O recebendo contrato, se receber tokens, deve contém um TokenFallBack função que define exatamente como lidar com qual tipo de token de entrada.

Transferir & Transferir de -> Transferir

Uma parte fundamental do padrão ERC20 que contribui para este problema comum é o fato de que os usuários finais têm a opção de usar erroneamente uma das duas funções usadas para transferir (Transferir & Transferir de).

ERC223 propõe a substituição de ambas as funções por uma única Transferir função.

O ERC223 permite que os usuários finais dapp enviem tokens para nenhum Endereço Ethereum, independentemente se esse contrato é uma carteira ou um contrato, com a mesma função de transferência. A lógica aqui é eliminar a opção de os usuários dispararem uma função de transferência ou uma função TransferFrom para apenas uma única função de transferência, os usuários finais não têm mais o potencial de usar a função incorreta.

A função de transferência recém-proposta aceita três parâmetros (anteriormente aceitos apenas dois) e, mais importante, procura invocar uma função TokenFallback no endereço de recebimento. Sem os três parâmetros definidos, a função Transfer falha na compilação; sem o endereço de recebimento contendo uma função TokenFallback, a transação da função de transferência falhará & nenhum tokens será transferido.

função tokenFallBack ()

No desenvolvimento do Ethereum existe um modificador de contrato a pagar que é usado para preparar um contrato para receber Ether – isso significa que um contrato agora espera a moeda digital. Se um contrato faz não contém o modificador a pagar, a transação enviada é simplesmente cancelada & devolvida. Nada extravagante, este é o Ethereum 101.

Uma maneira análoga de pensar sobre a função ERC223 tokenFallback é que o modificador a pagar é preparar um contrato para receber o Ether, como a função tokenFallback é preparar um contrato para receber x token.

Neste padrão, desenvolvedores de contrato deve implemente tokenFallback se quiserem que seus contratos funcionem com tokens específicos. Se o destinatário for um endereço não contratual, uma transação de token ERC223 será executada como qualquer transferência de token ERC20 atual. Por outro lado, se o receptor for um contrato, o contrato de token ERC223 tentará primeiro chamar tokenFallback no contrato do receptor; se nenhuma função tokenFallback for encontrada, a transação falhará.

Evolução do ERC

Apesar do estado de rascunho do ERC223, outro padrão ERC surge no horizonte – ERC 721. ERC721 se concentra em não fungível ativos como CryptoKitties, Decentral e terrenos, & talvez até ativos imobiliários de um dia. O progresso do ERC 721 pode ser encontrado aqui: https://github.com/ethereum/eips/issues/721

Tudo para mostrar que, embora jovem, a comunidade Ethereum leva muito a sério o aprimoramento de sua plataforma de contrato inteligente, colocando os padrões corretos diante de uma onda crescente de novos desenvolvedores. Lentamente, mas com segurança, os bugs do token ERC diminuirão – e então a questão se tornará: pode a escala padrão mais recente?

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me