Empréstimo no Ethereum: Comparando a evolução da arquitetura de MakerDAO, Yield, Aave, Compound e Euler

O empréstimo é a base dos aplicativos blockchain baseados em Ethereum . Com bilhões em ativos emprestados , compreender 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 , Composto , Aave , Euler , e Colheita . 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 é sobrecolateralizado . 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 for inferior a este valor, 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
  

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

MakerDAO , antigo em termos de Ethereum, foi lançado em sua forma atual em novembro de 2019 , e ele segura 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 pelo Juntar contratos.

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, apenas balas e queimaduras DAI como requerido.

A contabilidade é tratada dentro do IVA .sol contrato. As junções atualizar este contrato quando a garantia entra ou sai do sistema. Se um usuário pedir emprestado, 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 gerenciamento de riscos motor. 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, 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

Rendimento v1 serviu como prova de conceito para taxas fixas usando Espaço de rendimento . 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 Rendimento v2 . Ainda inspirado no MakerDAO, mas agora completamente independente, Yield v2 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.

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

Renovamos nossa integração de oráculos, fundindo oráculos de preços e taxas de juros em um interface comum . Invertemos o fluxo do oráculo do MakerDAO para que o Caldeirão consulta 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 Concha . 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

O primeira versão do composto era um 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 MoneyMarket.sol O contrato encapsula todas as funções, incluindo empréstimos.

• As tarefas de tesouraria, contabilidade e gestão de risco, tais 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

Composto 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 papel branco e estrutura, é evidente que um objetivo principal para Composto 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 whitepaper 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.

• 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 garantia.
• 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 , Composto v3 adota uma estratégia de gestão de risco mais conservadora, segregando a liquidez em uma piscina para cada ativo emprestável. O design também revela preocupações com a facilidade de uso e os custos do gás.

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.

Outras características relevantes mencionadas no notas de lançamento incluir:

• 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 gera retorno 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 emprestável de um mercado monetário implica tomar um empréstimo, enquanto fornecê-lo indica reembolso ou 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 era lançado em outubro de 2019 , sucedendo ETHLend. Em vez da abordagem peer-to-peer da ETHLend, o Aave v1 introduziu um pool de liquidez compartilhada.

Como no Yield v2, o contrato de roteador também manteve 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 a garantia é verificada seu próprio contrato , chamado do roteador e não do contrato de contabilidade parece fraco, mas provavelmente era adequado 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 era 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 (semelhante aos cTokens da Compound) e vTokens , que representam dívida 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 era 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

Euler era 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 é a semelhante a diamante padrão. A único contrato contém todo o armazenamento do aplicativo . Este armazenamento pode ser acessado através de distintos procuradores , 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 Armazenar contrato gerencia variáveis contábeis.
• O BaseLógica contrato funciona como tesouraria.
• O Gerente de risco O contrato supervisiona variáveis e funções de gerenciamento 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 rapidamente substituídos 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

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.

Graças a Calnix pela revisão e edição deste artigo.