WEB3DEV

Cover image for Desafio de processo seletivo Solidity — Explicado
Adriano P. Araujo
Adriano P. Araujo

Posted on

Desafio de processo seletivo Solidity — Explicado

Você pode usar este link para saber mais sobre mim, verificar meus projetos ou entrar em contato comigo para trabalhar:

@drakenwolf | Linktree

Sou um desenvolvedor autodidata - ou pelo menos é o que venho dizendo em entrevistas ou quando amigos me perguntam sobre minha profissão, mas a realidade é que tudo o que sei vem de outros profissionais e comunidades dispostas a compartilhar seus conhecimentos para que outros possam aprender algo em vez de gastar horas tentando descobrir alguma coisa.

É com esse sentimento de ajudar os outros a ter sucesso que criei este tutorial sobre um cenário de vida real, porque existem muitos tutoriais sobre como criar um erc721 ( NFT ) e assim por diante, mas vamos resolver esse desafio de código que um membro de uma comunidade de aprendizado de solidity no discord compartilhou comigo.

Como desenvolvedores, precisamos provar o que podemos fazer fora do código verde ( tutoriais ), para que possamos demonstrar nossas habilidades de resolução de problemas, mas devemos considerar também que outras coisas também estão sendo avaliadas: quão legível é o nosso código, quão seguro é o nosso código, quão eficiente e assim por diante.

Como dev’s de solidity, nossa maior preocupação deve ser segurança, otimização de gas, teste de unidade e quão legíveis e "amigáveis à auditoria" são nossos contratos inteligentes. Os dois últimos não são mencionados tanto quanto deveriam. Eu fiz parte do solidity expert BootCamp do encode club e extropy.io que foi onde aprendi o quão importante é usar o NatSpec e criar documentação do nosso contrato.

https://docs.soliditylang.org/en/v0.5.10/natspec-format.html

Primeiro, grandes DAO’s e empresas de blockchain tem códigos abertos. Eles têm seus contratos verificados, auditados e têm um perfil no GitHub com o código. É o caso da Uniswap, AAVE, Compound e Yearn Finance. Isso significa que outras pessoas podem verificar, auditar, fazerem fork e ler o código, portanto, é importante que eles tenham um código legível, comentado e bem documentado -. E para um auditor é muito mais fácil trabalhar com um código com esses recursos. E como desenvolvedor, será mais fácil ter uma visão geral do seu contrato.

Vamos ver as instruções para este desafio:

  • Crie um token ERC20 com 1.000.000.000 e um token NFT ERC721 com um token URI ( compatível com o padrão OpenSea ).

  • Crie uma página HTML cunhada na qual o usuário possa se conectar com a Metamask e criar um monstro aleatório ( desses, cinco monstros disponíveis ) com um nível de potência aleatório entre 1 e 100. O custo para cunhar um monstro é de 15 tokens.

  • A página deve listar todas as imagens de monstros cunhadas anteriormente e o nível de energia da carteira de usuários conectados.

  • Os contratos devem ser implantados no Mumbai Testnet e usar o ChainLink VRF para uma geração aleatória segura.

Neste post, explicarei passo a passo o contrato inteligente, informe-me nos comentários se você deseja uma segunda parte do site de cunhagem na web3 criado com react js.

Este é o repo para o contrato inteligente:

https://github.com/Drakenwolf/interviewChallenge-1

Primeiro, criamos um token básico:

Em seguida, o contrato NFT:

Precisamos modificar como o token NFT lida com o URI para que possamos ter metadados on-chain.

Pegamos a função de token URI,  agora precisamos apenas adicionar nossos metadados personalizados.

Para isso, precisamos usar o padrão de metadados Opensea, pois é o mais usado para os mercados da NFT. Se não seguirmos isso, nosso NFT não terá uma imagem, atributos e assim por diante, no mercado.

Este é o link para o padrão de metadados com alguns exemplos

https://docs.opensea.io/docs/metadata-standards

Esta função retornará uma sequência com a estrutura de metadados que estamos procurando.

Agora vamos fazer o mesmo para os atributos:

Além disso, vamos adicionar um mapeamento para rastrear os 5 tipos de imagens e uma referência ao token:

Como você pode ver, adicionei comentários ao nat_spec, que é obrigatório para um contrato inteligente profissional. Agora vamos adicionar um mapeamento para os metadados:

E vamos adicioná-lo à nossa função tokenURI

Em seguida, adicionaremos os metadados na função de cunhagem da NFT.

Portanto, nosso próximo passo será modificar nosso contrato para que ele possa ser compatível com o Chainlink VRF.

Primeiro, importamos as bibliotecas:

Segundo, fazemos nosso contrato VRFConsumerBaseV2:

Terceiro, adicionamos algumas variáveis de estado:

Quarto, atribuímos valores ao constructor:

Por fim, adicionamos as funções apropriadas:

Agora, nosso contrato atualizará os s_randomValues quando chamarmos o requestRandomWords.

Vamos fazer o safeMint interagir com esses valores aleatórios.

Agora temos metadados aleatórios gerados com o Chainlink VRF.

Agora, a única tarefa pendente a ser feita é a de que qualquer pessoa poderá cunhar o token usando o token ERC20 como pagamento, com um valor fixo de 15.

Podemos importar o contrato ERC20 ou a interface IERC20 do Open Zeppelin.

Em seguida, adicionamos uma condição que aciona um formulário de transferência, que exige que o usuário aprove o contrato com 15 unidades do token.

Duas linhas de códigos, legal.

A última parte será adicionar uma função para retirar esses tokens do contrato.

E é assim que resolvemos esses desafios comuns de processos seletivos. Se você tiver alguma dúvida ou quiser algum conselho para o seu projeto, pode entrar em contato comigo no LinkedIn ou deixar um comentário. Ficarei feliz em ajudá-lo. Por favor, comente se você deseja a segunda parte com uma integração com ofront-end. Siga-me para mais contratos!


Este artigo foi escrito por @drakenwolf e traduzido por Adriano P. de Araujo. O original em inglês pode ser encontrado aqui.

Top comments (0)