O empréstimo é a base dos aplicativos blockchain baseados em Ethereum. Com bilhões em ativos emprestados, entender como funciona o empréstimo é crucial para desenvolvedores, arquitetos ou pesquisadores.

Tal como a evolução dos paradigmas de programação, estas aplicações DeFi têm diversos designs arquitectónicos, reflectindo prioridades em mudança que vão desde a segurança à eficiência e experiência do utilizador.

Esta análise analisa a arquitetura de aplicativos como MakerDAO, Compound, Aave, Euler e Yield. Destacaremos as principais inovações e padrões de design, que são lições importantes para o desenvolvimento de futuras aplicações de empréstimo.

Se você é desenvolvedor, arquiteto ou pesquisador de segurança, este artigo é para você. Ao final, você entenderá facilmente os novos aplicativos de empréstimo no Ethereum, compreendendo sua arquitetura de forma rápida e abrangente. Mergulhe para ver como esses gigantes do DeFi são construídos do zero.

Empréstimo em DeFi

A maior parte dos empréstimos DeFi são sobregarantidos. Um usuário pode pedir emprestado um ativo específico se fornecer uma garantia de valor superior ao empréstimo. Ao contrário dos empréstimos convencionais, muitos desses empréstimos não têm reembolsos regulares ou datas de término fixas. Em essência, você pode pedir emprestado e nunca pagar.

No entanto, há um porém.

O valor da garantia deve sempre exceder o valor do empréstimo por uma margem pré-determinada.

Se o valor da garantia cair abaixo disso, o empréstimo é liquidado.

Durante a liquidação, outra pessoa reembolsa parte ou a totalidade do seu empréstimo e recebe em troca parte ou a totalidade da sua garantia.

Todos os pedidos de empréstimo que seguem esta estrutura financeira precisam dos mesmos blocos de construção, que podem então ser organizados de várias maneiras:

• Um tesouro para armazenar garantias do usuário e ativos emprestados
• Um sistema de contabilidade que rastreia as garantias e dívidas de cada usuário
• Funções que determinam a taxa de juros dos mutuários
• Um mecanismo para verificar se um empréstimo está suficientemente garantido, geralmente envolvendo oráculos de preços externos
• Um caminho de liquidação para empréstimos subcolateralizados
• Sistemas de gestão de risco que registram valores totais emprestados e outras métricas de segurança, como limites de empréstimo globais e por usuário, mínimos de garantias e índices específicos de sobrecolateralização
• Uma interface para os usuários adicionarem e removerem garantias, emprestarem e reembolsarem ativos subjacentes

Processo de empréstimo no MakerDAO. Todos os aplicativos compartilham as mesmas etapas e funções.

Empréstimos e empréstimos podem ser considerados recursos separados. No DeFi, encontramos ambos os recursos na maioria dos aplicativos de empréstimo, mas nem sempre estão bem integrados.

Em Composto, Aave e Euler são. As taxas de juros para mutuários e credores estão correlacionadas internamente; na verdade, é isso que faz com que esses aplicativos funcionem com intervenção mínima.

Por outro lado, MakerDAO e Yield são originadores dos ativos que emprestam aos mutuários.

Eles não exigem que os usuários forneçam ativos para que outros usuários possam pedir emprestado.

Este artigo se concentrará nos empréstimos em cadeia e ignorará amplamente os empréstimos. O empréstimo é muito mais complicado devido ao requisito de garantia, e a compreensão do padrão de empréstimo normalmente permite uma melhor compreensão de todo o protocolo.

A evolução arquitetônica do MakerDAO

Logo

MakerDAO, antigo em termos de Ethereum, foi lançado em sua forma atual em novembro de 2019 e possui US$ 4,95 bilhões em garantia. Apesar da sua arquitetura modular com contratos distintos para cada função e terminologia única, continua a ser fácil de compreender e verificar.

A função de tesouraria no MakerDAO é gerenciada pelos contratos Join .

Existe um contrato separado para cada token aprovado como ativo colateral.

Ao contrário, MakerDAO não possui nenhum DAI, o ativo de empréstimo.

Em vez disso, ele apenas cunha e queima DAI conforme necessário.

A contabilidade é tratada dentro do contrato IVA.sol. Os Joins atualizam este contrato quando a garantia entra ou sai do sistema. Se um usuário pedir um empréstimo, ele interagirá diretamente com o contrato vat.sol.

Esta ação atualiza o saldo devedor do usuário e permite cunhar DAI no DAI Join.

Para pagar, os usuários queimam o DAI no DAI Join. Este processo atualiza então o IVA, permitindo ao utilizador liquidar o seu empréstimo.

Além disso, o contrato vat.sol serve como mecanismo de gestão de risco . Mantém limites globais de empréstimo, estabelece limites mínimos por usuário e supervisiona os índices de garantia.

Quando são feitas alterações na dívida ou no saldo de garantias de um usuário, o contrato vat.sol avalia a taxa e a vista.

Referem-se à taxa de juros baseada na garantia utilizada e na relação preço DAI/colateral vigente. Curiosamente, esses valores são inseridos no contrato vat.sol por outros contratos MakerDAO, um método distinto da maioria dos outros aplicativos.

A MakerDAO priorizou a segurança durante sua fase de projeto – uma época em que fatores como os custos do gás eram secundários, a experiência do usuário era uma preocupação menor e a concorrência era insignificante.

Conseqüentemente, pode parecer peculiar, caro de usar e difícil de navegar.

No entanto, os vastos activos que gere e o seu registo de operação sem violações significativas sublinham a sua concepção e execução robustas.

Destaques:

• Cada ativo tem seu próprio contrato na função de tesouraria com spread máximo
• A função contábil é centralizada em um único contrato que também documenta e aplica parâmetros de risco, incluindo verificações de garantias
• Ao contrário de outros aplicativos, os oráculos atualizam o contrato, supervisionando a garantia
• Oráculos de preços e taxas de juros utilizam interfaces distintas
• A taxa de juros tem origem externa
• Para emprestar, os usuários devem interagir com vários contratos

A evolução arquitetônica do protocolo de rendimento

O Yield v1 serviu como prova de conceito para taxas fixas usando YieldSpace. Esta versão construiu seu mecanismo de dívida garantida com base no MakerDAO. No entanto, o Yield v1 era caro de usar e difícil de aumentar com novos recursos.

Reconhecendo o potencial do YieldSpace, rapidamente fizemos a transição para o desenvolvimento do Yield v2. Ainda inspirado no MakerDAO, mas agora completamente independente, o Yield v2 foi lançado em outubro de 2021; O Yield v2 priorizou a redução dos custos de gás e uma experiência de usuário aprimorada.

O processo de empréstimo no Yield v2, fortemente influenciado pelo MakerDAO

Todas as verificações de contabilidade, gerenciamento de risco e garantias foram consolidadas em um contrato: o Caldeirão. Espelhando a abordagem da MakerDAO, distribuímos as funções de tesouraria em contratos Join , cada um dedicado a um ativo específico.

Renovamos nossa integração com oráculos, mesclando oráculos de preços e taxas de juros em uma interface comum. Revertemos o fluxo do oráculo do MakerDAO para que o Cauldron consulte os oráculos conforme necessário para verificações de garantia. Que eu saiba, este é o fluxo preferido em todos os lugares, exceto MakerDAO.

Outro desvio significativo da abordagem da MakerDAO foi a introdução do Ladle. Este contrato serve como único intermediário entre os usuários e a Yield. Ele exerce amplo controle sobre tesouraria e contabilidade, mas, em troca, oferece imensa flexibilidade para o desenvolvimento de recursos.

Em resumo, o empréstimo no Yield v2 funciona da seguinte forma:

• Cada ativo possui seu próprio contrato de tesouraria dedicado, garantindo a máxima distribuição da função de tesouraria.
• Um contrato singular centraliza a função contábil. Este contrato também supervisiona as medidas de gestão de risco e realiza verificações de garantias.
• A função de colateralização consulta oráculos para determinar preços e taxas de juros.
• Os oráculos de preços e taxas de juros compartilham uma interface unificada.
• As taxas de juros são geradas externamente.
• Os usuários podem pedir emprestado fazendo uma única solicitação para apenas um contrato.

A evolução arquitetônica do financiamento composto

A primeira versão do Compound foi uma Prova de Conceito, demonstrando que um mercado monetário poderia ser estabelecido no Ethereum. Por esse motivo, a simplicidade foi priorizada em seu design. O contrato MoneyMarket.sol encapsula todas as funções, incluindo empréstimos.

O processo de empréstimo no Compound v1. Simples, mas eficaz.

• As tarefas de tesouraria, contabilidade e gestão de risco, como verificações de garantias, são consolidadas num único contrato.
• Este contrato recupera os preços dos oráculos, mas determina as taxas de juros com base na utilização dos ativos.
• Os usuários interagem exclusivamente com este contrato, embora devam fazer ligações separadas para fornecer garantias e emprestar ativos.

Composto v2

O Compound v2 foi lançado em maio de 2019, iniciando a era da produção agrícola e inspirando inúmeros garfos. Também funcionou como um mercado monetário, permitindo aos utilizadores emprestar e tomar emprestado activos.

Com base em seu whitepaper e estrutura, é evidente que um dos principais objetivos do Compound v2 era usar o padrão ERC20 para representar posições de empréstimo. Isso garantiu a possibilidade de composição, permitindo que os usuários emprestassem para a Compound e depois usassem essas posições que rendem juros em outras aplicações de blockchain.

Curiosamente, o white paper não destacou que o Compound v2 incorporou recompensas em seus contratos inteligentes. Dada esta omissão, o imenso impacto desta funcionalidade pode não ter sido previsto.

O processo de empréstimo no Compound v2. Primeira incursão em posições de empréstimo tokenizadas.

• Cada ativo possui seu próprio contrato de tesouraria, maximizando a distribuição da função de tesouraria.
• A função de contabilidade também é distribuída, com cada cToken anotando as garantias e dívidas do usuário.
• Um contrato único, o Controlador, registra e aplica parâmetros de gestão de risco, incluindo verificações de garantias.
• O contrato responsável pelas verificações de garantias faz referência aos oráculos de preços e ao cToken para taxas de juros.
• Os oráculos de preços e taxas de juros operam com interfaces diferentes.
• A taxa de juros deriva internamente da utilização dos ativos.
• Os usuários devem interagir com vários contratos para obter empréstimos.

Composto v3

Lançado em 2022, o Compound v3 adota uma estratégia de gestão de risco mais conservadora, segregando a liquidez em um pool para cada ativo que pode ser emprestado. O design também revela preocupações com a facilidade de uso e os custos do gás.

O processo de empréstimo no Compound v3 (Comet). De volta ao básico, de volta à segurança. Com melhor UX, no entanto.

O sistema fica mais intuitivo tanto para desenvolvedores quanto para usuários devido à redução no número de chamadas necessárias. Além disso, o desenho do contrato singular reduz os custos do gás, minimizando as chamadas entre contratos. Os mercados monetários segregados são uma defesa contra ataques baseados em oráculos, que são agora uma grande preocupação de segurança.

Outros recursos relevantes mencionados nas notas de lançamento incluem:

• Um mecanismo de gestão e liquidação de risco completamente renovado. Este design aumenta a segurança do fundo, ao mesmo tempo que é mais favorável ao mutuário.
• Estabeleça limites em todo o mercado para ativos colaterais individuais para mitigar riscos.
• Os modelos de taxas de juro para ganhos e empréstimos são agora separados, com a governação a ter controlo total sobre as políticas económicas.

Curiosamente, o Compound v3 reflete a arquitetura do Compound v1 ao ter um único contrato para lidar com todas as funções de cada ativo que pode ser emprestado. Outros recursos notáveis incluem:

• Somente bens emprestados podem ser emprestados; ativos colaterais não podem.
• A garantia não produz retornos no Composto v3.

A proibição de contrair empréstimos de garantias aumenta a segurança de quem deposita as garantias. Isto diminui a probabilidade de erros de governação ou ataques intencionais colocarem em risco as garantias.

A eliminação dos retornos sobre as garantias fornecidas pode ser o resultado da Compound ter conseguido acumular muita liquidez na v2. Tenho a intuição de que no Compound v2 os limites de empréstimo estavam abaixo ou não muito superiores aos ativos emprestados ao aplicativo pelos usuários.

Supondo que eles gerenciarão níveis semelhantes de liquidez para a v3, proibir o empréstimo de garantias torna o aplicativo seguro, um dos principais objetivos da v3.

Do ponto de vista arquitetônico:

• Cada mercado monetário é um contrato individual com sua tesouraria, contabilidade e gestão de risco
• Cada mercado monetário retém o ativo que pode ser emprestado junto com todos os seus tokens de ativos colaterais aprovados, fazendo com que os ativos sejam dispersos pela aplicação.
• Os feeds de preços são a única entrada externa; as taxas de juros para empréstimos e empréstimos são geradas internamente
• Funções tradicionais como fornecimento/retirada/empréstimo/reembolso foram consolidadas de forma inteligente. Agora, retirar um ativo que pode ser emprestado de um mercado monetário implica um empréstimo, enquanto fornecê-lo indica um reembolso ou um empréstimo com base na dívida do usuário.
• Um contrato de roteamento é integrado, permitindo múltiplas operações em uma única chamada

A evolução arquitetônica do Aave

Aave v1 foi lançado em outubro de 2019, sucedendo ao ETHLend. Em vez da abordagem peer-to-peer da ETHLend, o Aave v1 introduziu um pool de liquidez compartilhada.

O processo de empréstimo no Aave v1. Liquidez conjunta significava eficiência financeira e computacional.

Assim como no Yield v2, o contrato do roteador também mantinha a lógica de negócios. O LendingPoolCore implementou funções de contabilidade, gestão de risco e tesouraria. Reunir a tesouraria em um único contrato foi um diferencial do Compound v2.

A decisão de deixar as verificações de garantia em seu próprio contrato, chamado do roteador e não no contrato de contabilidade, parece fraca, mas provavelmente foi adequada ao propósito, já que o Aave v2 só foi lançado dois anos após o lançamento da v1

• O contrato LendingPoolCore trata de tesouraria e contabilidade
• LendingPoolDataProvider gerencia verificações de garantia e interage com o oráculo
• LendingPool serve como ponto de entrada do usuário e implementa lógica de negócios
• As taxas de juros para empréstimos e empréstimos são determinadas internamente, com base apenas nos feeds de preços

Aave v2

Aave v2 foi lançado em dezembro de 2021. Embora tenha mantido recursos semelhantes ao Aave v1, introduziu uma arquitetura melhorada e mais simples em comparação com o Aave v1 e o Compound v2. Com este lançamento, Aave também introduziu aTokens (semelhantes aos cTokens da Compound) e vTokens, que representam dívida tokenizada.

Aave v2 possui uma arquitetura muito limpa, totalmente tokenizada.

Certos recursos do Aave v1, que tinham uso limitado, foram omitidos por questões de simplicidade. Problemas no Aave v1, como a representação complexa dos juros acumulados, foram abordados no Aave v2.

• O contrato LendingPool consolida funções globais de contabilidade e gestão de risco, como verificações de garantia. Ele serve como ponto de acesso principal para usuários
• aTokens significam garantias e são semelhantes a posições de empréstimo. A garantia dos usuários é refletida por meio de seus acervos de aToken, e a função de tesouraria é distribuída por todos os aTokens
• vTokens são usados para representar posições de dívida. A dívida de um usuário é representada pelos vTokens que ele possui

Aave v3

Aave v3 foi lançado em janeiro de 2023 com suporte multi-chain e outros recursos. Essas adições não alteram a arquitetura central. A atualização também apresenta melhor gerenciamento de risco e eficiência de gás.

Apesar de seus muitos avanços, para os fins deste estudo, o Aave v3 não é materialmente diferente do Aave v2. Na verdade, isso pode sugerir que a arquitetura do Aave v2 permanece robusta em 2023.

A evolução arquitetônica de Euler

O Euler foi lançado em dezembro de 2022, com o objetivo de oferecer mercados monetários com recursos sem permissão e governança mínima.

Uma marca registrada de seu design é o padrão semelhante a um diamante . Um único contrato contém todo o armazenamento do aplicativo. Este armazenamento pode ser acessado através de proxies distintos, cada um gerenciando um elemento conceitual diferente do sistema.

Embora um contrato armazene todos os dados de ativos, contabilidade e gerenciamento de risco, ainda existem eTokens para garantias e empréstimos, e dTokens para dívidas, semelhante ao Aave v2. No entanto, estes contratos de token são apenas visões do contrato de armazenamento central.

• O contrato de armazenamento gerencia variáveis contábeis.
• O contrato BaseLogic funciona como tesouraria.
• O contrato RiskManager supervisiona variáveis e funções de gestão de risco, incluindo verificações de garantias.

Uma análise do código revela que o custo mínimo do gás era uma prioridade, levando ao design monolítico eliminando a necessidade de chamadas entre contratos. A segurança foi garantida através de testes e auditorias rigorosos. Apenas a lógica foi distribuída por vários módulos, servindo como implementação para o contrato de armazenamento, que funcionou principalmente como um contrato proxy.

Este design unificado também suporta atualizações fáceis. Os módulos podem ser substituídos rapidamente para alterar ou introduzir recursos se nenhuma alteração de armazenamento for necessária.

Euler foi hackeado quinze meses após seu lançamento e seis meses após a atualização introduzir a vulnerabilidade explorada.

Não creio que a arquitectura monolítica tenha desempenhado um papel na drenagem dos activos; em vez disso, foi uma supervisão insuficiente das atualizações de código.

Conclusão

O trabalho duro está feito, vamos revisar o que aprendemos

As primeiras aplicações do Ethereum, como MakerDAO, Compound e Aave, mostraram o potencial de empréstimos com garantia excessiva no Ethereum. Depois que essas provas de conceito foram bem-sucedidas, o foco mudou para a introdução de uma combinação de novos recursos para conquistar participação de mercado. As versões posteriores de Compound e Aave introduziram produção agrícola, capacidade de composição e liquidez conjunta, que prosperaram especialmente durante condições de alta do mercado.

Um desenvolvimento significativo foi a introdução de posições de empréstimo tokenizadas no Compound v2, o que permitiu que essas posições fossem reconhecidas como ativos padrão por outras aplicações. Aave v2 e Euler deram um passo adiante ao implementar posições de dívida tokenizadas, cuja utilidade mais ampla permanece um assunto de debate.

Os altos custos do gás surgiram como uma grande preocupação durante o mercado altista, provocando modificações na experiência do usuário, como visto no Yield v2, Aave v2 e Euler. Contratos de roteador e implementações monolíticas ajudaram a reduzir os custos incorridos pelos usuários nas transações. No entanto, isso ocorreu às custas de um código mais complexo e, consequentemente, mais arriscado.

O Compound v3 parece estabelecer um precedente, priorizando a segurança em detrimento da eficiência financeira. Ele se desvia do modelo tradicional de pool de liquidez para melhor proteção contra possíveis hacks. A ascensão das redes L2, onde os custos do gás se tornam cada vez mais insignificantes, provavelmente moldará a concepção de futuras aplicações de empréstimos garantidos.

Neste artigo, forneci uma visão geral abrangente dos principais aplicativos de empréstimos garantidos no Ethereum. A abordagem que empreguei para analisar cada aplicação também pode ser aplicada para compreender rapidamente as complexidades de outras aplicações de empréstimos garantidos.

Ao desenvolver uma aplicação de empréstimo blockchain, considere sempre o armazenamento de ativos, a colocação de registros contábeis e os métodos de avaliação de riscos e garantias. À medida que você analisa essas considerações, aproveite o histórico de aplicações anteriores e os insights desta visão geral para informar suas decisões.

Obrigado por ler e boa sorte.

Obrigado à Calnix pela revisão e edição deste artigo.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [hackernoon]. Todos os direitos autorais pertencem ao autor original [alcueca]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.