Tudo sobre Tokens Smart Contract

Você já ouviu falar de tokens smart contracts, mas não sabe o que são? Não se preocupe, a gente explica tudo para você! Basicamente, existem dois tipos de tokens smart contracts: os fungíveis e os não-fungíveis.

Os tokens fungíveis são como moedas comuns, onde cada token é exatamente igual ao outro e tem o mesmo valor. O padrão ERC-20 é o padrão de tokens fungíveis no Ethereum, enquanto o FungibleToken é o equivalente no blockchain Flow. A criptomoeda da rede FLOW é um token fungível que implementa o padrão FungibleToken do Flow.

Já os tokens não-fungíveis são os famosos NFTs, que são ativos que estão agrupados sob um tema conectado, mas cada token é único e tem metadados e valores diferentes. Os padrões ERC-721 e ERC-1155 são os padrões de NFTs no Ethereum, enquanto o NonFungibleToken é o equivalente no blockchain Flow. Os momentos da NBA Top Shot são exemplos de NFTs do Flow.

Esses dois tipos de smart contracts são importantes porque são os mais comuns em quase todos os blockchains. Eles precisam ser interoperáveis entre si, então precisam utilizar um padrão comum. Utilizamos um contrato Cadence para definir o padrão.

As interfaces são uma parte MUITO importante da programação Cadence, então se você ainda não leu o documento de referência da linguagem sobre interfaces, clique no link acima e comece agora! 😃

Qualquer contrato pode implementar a funcionalidade definida em uma interface de contrato. Para tokens, essas interfaces contêm campos como saldo e funções como sacar e depositar. Elas garantem que todo smart contract que segue a interface tenha que seguir as mesmas regras.

Então, outros contratos podem especificar que podem interagir com qualquer token que siga a interface comum. Isso torna a interoperabilidade MUITO mais fácil. Qualquer um pode plugar um novo token no ecossistema ou em um novo aplicativo que usa o token comum sem precisar fazer qualquer integração especializada.

Você pode ver os padrões para FungibleToken e NonFungibleToken

As interfaces (por enquanto) especificam assinaturas e tipos EXATOS

Dê uma olhada na interface de token fungível. Toda vez que o tipo @Vault é especificado, como na função depositar ou sacar, @Vault se refere ao @FungibleToken.Vault, o que significa que o parâmetro ou o valor de retorno é do tipo FungibleToken.Vault. Os contratos que implementam a interface devem corresponder exatamente às especificações da interface. A assinatura exata da função depositar tem que ser pub fun depositar(de: @FungibleToken.Vault). Então, se eu estivesse criando um contrato JoshToken, minha função depositar não seria permitida aceitar um @JoshToken.Vault. Ela ainda precisaria aceitar um FungibleToken.Vault, assim como a interface padrão especifica. Se alguém quisesse chamar minha função depositar com um JoshToken.Vault, eles primeiro precisariam convertê-lo para um FungibleToken.Vault antes de passá-lo como parâmetro. Isso também se aplica ao padrão NFT. A função depositar nas implementações dos padrões TEM que ser pub fun depositar(token: @NonFungibleToken.NFT) Isso causa um problema! Se o tipo do parâmetro que é passado para a função depositar é apenas um token genérico, então qualquer um poderia depositar qualquer token que quisesse em sua Vault ou Collection! Isso é obviamente um problema, porque a oferta do token poderia ser aumentada artificialmente depositando tokens aleatórios em qualquer Vault. A PARTE CRITICA Isso me leva ao assunto do título desse post: a parte crítica de cada contrato de token que você não pode esquecer. Para garantir que apenas tokens do tipo correto sejam depositados em sua Vault ou Collection, você precisa converter o objeto genérico para o tipo concreto de seu contrato com uma linha como essa. // forçar a conversão de `` para um concreto ExampleToken.Vault let vault <- from as! @ExampleToken.Vault as! é o operador de conversão forçada. Ele tenta converter o objeto à esquerda do operador como o tipo à direita do operador. Se a conversão for bem-sucedida, ou seja, se o objeto for o tipo à direita, a execução da função continua com o objeto como o novo tipo convertido. Se a conversão falhar, a execução para e o estado é revertido. Com essa linha, se um tipo de token diferente for depositado, o depósito falhará e você poderá manter a integridade de seu token! Você deve ver essa linha em muitos contratos inteligentes amplamente utilizados na mainnet, como o contrato FlowToken e o contrato NBA Top Shot. Se você encontrar um contrato de token que não tem uma função depositar ou sacar, então é provável que esse contrato não seja projetado para armazenar ou transferir tokens. É importante fazer uma investigação aprofundada antes de interagir com qualquer contrato de token, pois as consequências de interagir com um contrato malicioso ou mal projetado podem ser graves. Certifique-se de entender completamente como o contrato funciona e verifique se ele foi auditado por especialistas independentes antes de enviar quaisquer tokens para ele.

Em um contrato de token, a função depositar ou sacar é responsável por permitir que os usuários envie ou retire tokens do contrato. O símbolo "@Vault" é usado para se referir ao próprio contrato, ou seja, a "caixa-forte" onde os tokens estão armazenados. É importante verificar se o contrato está seguro e auditable antes de enviar quaisquer tokens para ele, para evitar perda de fundos devido a vulnerabilidades ou erros no código. É recomendável ler a documentação e verificar a reputação do desenvolvedor antes de fazer qualquer operação com o contrato.

É importante ler toda a documentação disponível e entender completamente as funcionalidades e riscos do contrato antes de interagir com ele. Além disso, é recomendável procurar por comentários e revisões de outros usuários para ter uma noção da confiabilidade do contrato. Se possível, é aconselhável testar pequenas quantidades de tokens antes de fazer transações maiores. Em geral, é importante sempre manter uma boa gestão de risco ao lidar com contratos de tokens.

Isso inclui verificar a reputação do desenvolvedor, estudar o código do contrato e verificar se ele está auditado por uma terceira parte confiável. Além disso, é importante sempre manter uma cópia de segurança de suas chaves privadas e não depositar mais do que você está disposto a perder. É sempre recomendável fazer sua própria pesquisa e não confiar apenas na opinião de outras pessoas.