As primeiras criptomoedas surgiram, a exemplo de Bitcoin, como um meio de substituir as moedas fiduciárias (fiat) que quebraram a economia mundial em 2008. Mas não foi apenas culpa da gestão dos governos sobre o dólar e outras moedas governamentais, mas também culpa da irresponsabilidade e ganância dos bancos e instituições financeiras. A resposta a esse mercado em torno das fiats foi o surgimento do conceito de DeFi, ou Decentralized Finance, as Finanças Descentralizadas, onde temos serviços financeiros rodando de forma autônoma na blockchain usando criptomoedas como dinheiro e smart contracts como contratos.
Você pode por exemplo tomar um empréstimo, aplicar em um fundo de investimento, comprar bens digitais e físicos, jogar jogos, vender sua arte, trocar moedas e muito mais, tudo através dos chamados protocolos DeFi, bastando ter uma carteira cripto com saldo nela. Ah, e isso tudo sem qualquer fronteira, barreira, longos cadastros e outras burocracias inerentes ao sistema financeiro tradicional, ao mesmo tempo que de forma segura e barata.
Pois é, estamos no início de uma completa revolução nos serviços financeiros e para que ela seja viável tecnicamente precisamos de programadores capazes de construir tais protocolos. No tutorial de hoje eu quero te ensinar a construir um primeiro protocolo DeFi, bem simples, mas que servirá como exemplo para você fazer coisas mais interessantes mais tarde.
Usaremos a linguagem Solidity, a mais famosa do mundo quando o assunto é smart contracts, e este não deve ser o seu primeiro tutorial nesta linguagem. Se nunca programou em Solidity antes, comece por este outro aqui.
Além disso, usaremos o padrão ERC-20 neste tutorial. Se você não entende como funciona um token ERC-20, você deve primeiro ter a experiência de criar um para aprender os fundamentos usados por praticamente TODOS protocolos DeFi. Aprenda sobre tokens ERC-20 neste tutorial aqui.
Para simplificar, usarei a ferramenta online Remix para codificação, que você acessa neste link.
#1 – Entendendo o Protocolo
O primeiro ponto a entender sobre protocolos financeiros (DeFi ou não) é que TODOS eles fazem algum “malabarismo” com seu dinheiro. Peguemos como exemplo os bancos: eles pegam dinheiro emprestado de investidores. Esse investidor pode ser o governo, pode ser empresas privadas (incluindo outros bancos) ou pode ser até mesmo eu e você (pessoas físicas). Ou seja, eles contraem uma dívida, a um juro X.
Mas porque eles fazem isso?
Porque com esse dinheiro que eles pegaram emprestado, eles emprestam para outras pessoas, governos e empresas, a um juro Y, sendo que o lucro dos bancos está na diferença entre X (juro baixo) e Y (juro alto). Esse seria o protocolo financeiro real mais simples possível de entender e quem dera os bancos operassem apenas dessa forma, pois assim não teríamos as crises financeiras mundiais.
Enfim, como simular comportamento semelhante através de um smart contract, a fim de ter um protocolo DeFi de investimento?
Para simplificar, vamos pensar em só “guardar dinheiro”, ao invés de investir. Você já deve ter ouvido histórias ou até ter você mesmo guardado dinheiro embaixo do colchão, em caixas de sapato ou os famigerados cofrinhos em forma de porco, certo? Essa é uma modalidade de poupança, mas não de investimento, mas já servirá para ilustrar a principal mecânica envolvida: protocolos de depósito e saque.
Via de regra, todo smart contract é uma conta na blockchain, o que permite que eles recebam e transfiram criptomoedas um aos outros. Desta forma, você poderia facilmente criar um smart contract para guardar e sacar dinheiro, olha o exemplo abaixo de um smart contract de Carteira.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Carteira { mapping(address => uint) public balances;//user => balance constructor(){ } function deposit() payable external { balances[msg.sender] += msg.value; } function withdraw(uint amount) external { require(balances[msg.sender] >= amount, "Insufficient funds"); balances[msg.sender] -= amount; payable(msg.sender).transfer(amount); } } |
O exemplo acima é funcional. Ele permite que diferentes pessoas enviem dinheiro para ficar guardado nele (função payable deposit), registra corretamente o saldo de todo mundo, e depois a pessoa pode chamar a função de saque (withdraw) para sacar parte ou o total dessa quantia. No entanto, qual o problema fundamental deste contrato?
A única criptomoeda real em uma blockchain é a nativa da rede: Ether na Ethereum, Bitcoin na BTC, BNB na BSC, etc. Se esse contrato eu fizer deploy na blockchain da Binance, por exemplo, esse contrato acima vai poder receber e enviar apenas BNB, que é a moeda de todas as contas da referida rede. E embora seja possível sim criar um protocolo somente em cima da moeda nativa, o mais comum é que os protocolos operem usando tokens ERC-20, que é o que faremos a seguir.
#2 – Criando o Protocolo de Depósito
Vamos repensar nosso protocolo de guardar dinheiro, partindo do pressuposto que usaremos um token ERC-20 nos depósitos e transferências. O mais comum é que os protocolos tenham seu próprio token ERC-20 para usar nas negociações, a fim de que não precisem lidar com diferentes tokens com diferentes cotações, etc. Então vou supor aqui que você possui uma criptomoeda sua ou ao menos escolheu qual que irá usar no seu protocolo. Guarde o endereço do contrato ERC-20 dela contigo.
Agora, vamos criar o contrato do nosso protocolo, onde vamos receber o endereço da moeda no construtor, ou seja, durante o deploy. Com esse endereço em mãos, vamos guardar em uma variável de estado como sendo um objeto de token ERC-20, um tipo que teremos acesso importando uma interface popular do OpenZeppelin.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
// SPDX-License-Identifier: MIT pragma solidity ^26; import "@openzeppelin/contracts/token/ERC20/IERC20.sol"; contract Colchao { IERC20 public immutable token; mapping(address => uint) public balances;//user => balance constructor(address tokenAddress){ token = IERC20(tokenAddress); } } |
Assim, a variável token é um IERC20, ou seja, um objeto de token ERC20 com todas as funções do padrão. Repare que também já recriei o mesmo mapping de saldos dos clientes, algo que já existia na técnica anterior. Esta variável de token ERC20, apesar de funcionar com qualquer token, só funcionará com UM token, aquele definido no deploy/constructor. A partir de então, todas as demais funções do contrato vão manipular somente o token em questão.
Assim se quisermos fazer uma função de depósito, abaixo temos um exemplo.
|
1 2 3 4 5 6 |
function deposit(uint amount) external { token.transferFrom(msg.sender, address(this), amount); balances[msg.sender] += amount; } |
Mas Luiz, a função de depósito não deveria ser payable?
Não, pois funções payable servem somente para enviar fundos da moeda nativa da rede. Neste caso, eu quero enviar um outro token ERC-20. Para que eu possa fazer isso, tenho duas alternativas:
- envio a quantia diretamente pra conta do protocolo no contrato do token (via função transfer)
- permito que o protocolo faça o saque da quantia na minha conta no contrato do token (via função transferFrom).
Como deve ter reparado, eu optei pela segunda opção. Por que?
Porque a primeira opção, de enviar a quantia diretamente para o destinatário, faz com que o protocolo não tenha qualquer reação sobre esse depósito. Ele sequer saberá, via de regra, que você fez um depósito. E isso obviamente inviabiliza construir um protocolo diferente de uma mera carteira, certo?
Com a segunda opção, fica um pouco mais complexo já que o usuário terá de autorizar, via função approve do contrato ERC-20, que o protocolo possa movimentar seus fundos, mas assim, ele pode chamar a função deposit do contrato e é o protocolo que se encarregará de todo o resto. No meu caso eu apenas atualizo o mapping de balances, mas eu poderia fazer muito mais coisas.
Mas e quando o usuário quiser o dinheiro dele de volta?
#3 – Criando o Protocolo de Saque
Realizar o saque não é muito mais complexo do que fazer um depósito, principalmente porque não envolve todos aqueles conceitos de transferência delegada do ERC-20. Basta o protocolo enviar o dinheiro para a carteira do dono original, mas não sem antes deduzir o saldo, a fim de evitar Reentrancy Attacks.
|
1 2 3 4 5 6 7 |
function withdraw(uint amount) external { require(balances[msg.sender] >= amount, "Insufficient funds"); balances[msg.sender] -= amount; token.transfer(msg.sender, amount); } |
Repare também a verificação da existência de fundos antes de fazer a transferência, a fim de evitar saques maiores do que o usuário tem direito.
Com isso, temos um protocolo de “guardar dinheiro embaixo do colchão” funcional e que serve para múltiplos poupadores de um mesmo token ERC-20 definido por você. Opcionalmente você poderia modificar este protocolo para permitir que ele suporte múltiplos tokens simultaneamente, por exemplo criando um mapping de user address para token address para balance e pedindo o address do token nas funções de depósito e saque. Isso dificulta um pouco mais mas é perfeitamente possível de fazer.
Além disso, querendo evoluir este protocolo para algo mais completo, você poderia fazer ele se integrar com protocolos de staking, a fim de pegar o dinheiro guardado e aplicá-lo para render, compartilhando com os usuários parte desses dividendos, como acontece em contas remuneradas, por exemplo.
Enfim, o céu é o limite em relação às possibilidades do DeFi e estamos apenas começando!
Quer aprender a fazer outro protocolo DeFi, mais elaborado? Confira este tutorial.
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.
Olá amigo, é muito difícil encontrar alguém que entenda o que proponho, mas estou aqui…
Há uma dor que não passa e temos que fazer algo a respeito.
Usando uma Exchange não temos a posse de nossos ativos e isso é terrível.
Sanando essa dor, teríamos um protocolo de grande usabilidade.
Então pensei em criar um protocolo, em Solidity, para quando o cliente abrir uma conta na Exchange sejam geradas as chaves para o cliente que terá suas criptos na Exchange, sob sua custódia. A Exchange terá uma chave que “não poderá usar”, mas receberá as taxas todas dos serviços oferecidos…
Nada sei de programação, mas sei dessa dor terrível que há no mercado cripto.
Quem não pensou nisso ainda?
Mesmo assim queria que alguém da área desse um parecer…
Obrigado.
Renato Pinali
Essa dor é solucionada pelas exchanges descentralizadas (DEX) como Uniswap, PancakeSwap e outras. As exchanges tradicionais (centralizadas ou CEX) não possuem interesse nesse tipo de solução pois justamente fazem grana com a custódia, no mesmo modelo do sistema bancário (emprestando, investindo, etc).