O empréstimo é uma pedra angular das aplicações blockchain baseadas em Ethereum. Com milhares de milhões em ativos emprestados, entender como funciona o empréstimo é crucial para desenvolvedores, arquitetos ou investigadores.

Assim como a evolução dos paradigmas de programação, estas aplicações DeTI têm diversos designs de arquitectura, refletindo prioridades em mudança que vão da segurança à eficiência e experiência do utilizador.

Esta análise analisa a arquitetura de aplicações como MakerDAO, Compound, Aave, Euler e Yield. Vamos destacar 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 é um programador, arquiteto ou investigador de segurança, este artigo é para si. No final, compreenderá facilmente novas aplicações de empréstimo no Ethereum, compreendendo a sua arquitetura de forma rápida e abrangente. Mergulhe para ver como estes gigantes DeFi são construídos a partir do zero.

Empréstimo no DeFi

A maior parte dos empréstimos DeFi é sobrecolateralizada. Um utilizador pode pedir emprestado um activo específico se fornecer garantias que valem mais do que o empréstimo. Ao contrário dos empréstimos convencionais, muitos destes empréstimos não têm reembolsos regulares ou datas de término fixas. Em essência, pode pedir emprestado e nunca reembolsar.

No entanto, há um problema.

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 parte ou toda a sua garantia em troca.

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

• Um tesouro para armazenar garantias dos utilizadores e ativos emprestados
• Um sistema de contabilidade que rastreia a garantia e a dívida de cada utilizador
• Funções que determinam a taxa de juro dos mutuários
• Um mecanismo para verificar se um empréstimo está suficientemente colateralizado, geralmente envolvendo oráculos de preços externos
• Um caminho de liquidação para empréstimos subcolateralizados
• Sistemas de gestão de risco que registam os montantes totais emprestados e outras métricas de segurança, tais como limites de empréstimos globais e por utilizador, mínimos colaterais e índices específicos de sobregarantia
• Uma interface para os utilizadores adicionarem e removerem garantias, emprestar e reembolsar subjacentes

Processo de empréstimo no MakerDAO. Todas as aplicações partilham os mesmos passos e funções.

Empréstimos e empréstimos podem ser pensados como características separadas. No DeFi, encontramos as duas funcionalidades na maioria das aplicações de empréstimo, mas nem sempre estão bem integradas.

Em Compound, Aave e Euler estão. As taxas de juro para mutuários e mutuantes estão internamente correlacionadas; na verdade, é isso que faz com que essas aplicações funcionem com intervenção mínima.

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

Não exigem que os utilizadores forneçam ativos para que outros utilizadores possam pedir emprestado.

Este artigo incidirá sobre empréstimos em cadeia e ignorará amplamente os empréstimos. O empréstimo é muito mais complicado por causa do requisito de garantia, e entender o padrão de empréstimo normalmente desbloqueia uma melhor compreensão de todo o protocolo.

A evolução arquitetónica do MakerDAO

Logotipo MakerDAO

O MakerDAO, antigo em termos Ethereum, foi lançado na sua forma atual em novembro de 2019 e detém $4.95B em garantia. Apesar da sua arquitetura modular com contratos distintos para cada função e terminologia única, continua a ser fácil de entender e verificar.

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

Há um contrato separado para cada token aprovado como ativo colateral.

Ao contrário, o MakerDAO não possui nenhum DAI, o ativo emprestado.

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

A contabilidade é tratada dentro do contrato vat.sol. As Junções atualizam este contrato quando a garantia entra ou sai do sistema. Se um utilizador pedir emprestado, interage diretamente com o contrato vat.sol.

Esta ação atualiza o saldo da dívida do utilizador e permite-lhe cunhar DAI no DAI Join.

Para pagar, os utilizadores queimam 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 motor de gestão de risco. Mantém limites globais de empréstimos, define limiares mínimos por utilizador e supervisiona os rácios de garantia.

Quando são feitas alterações na dívida ou no saldo de garantia de um utilizador, o contrato vat.sol avalia tanto a taxa como a spot.

Estes referem-se à taxa de juro com base nas garantias utilizadas e no rácio de preço DIA-garantia vigente. Curiosamente, estes valores são introduzidos no contrato vat.sol por outros contratos MakerDAO, um método distinto da maioria das outras aplicações.

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

Consequentemente, pode parecer peculiar, caro de usar e difícil de navegar.

No entanto, os vastos ativos que gere e o seu registo de operação sem violações significativas sublinham o seu design e execução robustos.

Destaques:

• Cada activo tem o seu próprio contrato na função de tesouraria de spread máximo
• A função contabilística é centralizada num único contrato que também documenta e impõe parâmetros de risco, incluindo verificações de garantia
• Ao contrário de outras aplicações, os oráculos atualizam o contrato, supervisionando a garantia
• Os oráculos de preço e taxa de juro utilizam interfaces distintas
• A taxa de juro tem origem externa
• Para pedir emprestado, os utilizadores devem interagir com vários contratos

A evolução arquitectónica do protocolo de rendimento

O rendimento v1 serviu como prova de conceito para taxas fixas utilizando o YieldSpace. Esta versão construiu o seu motor de dívida colateralizado em cima do MakerDAO. No entanto, o Yield v1 era caro de usar e desafiador de aumentar com novas funcionalidades.

Reconhecendo o potencial do YieldSpace, rapidamente fizemos a transição para o desenvolvimento do Yield v2. Ainda inspirando-se no MakerDAO, mas agora completamente independente, o Yield v2 foi lançado em outubro de 2021; o Yield v2 priorizou custos reduzidos de gás e uma experiência de utilizador melhorada.

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

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

Reformulámos a nossa integração com o oráculo, fundindo oráculos de preço e taxa de juro numa interface comum. Invertemos o fluxo de oráculos do MakerDAO de tal forma que o Cauldron consulta oráculos conforme necessário para verificações de colateralização. Tanto quanto sei, este é o fluxo preferido em todo o lado excepto MakerDAO.

Outro desvio significativo da abordagem do MakerDAO foi a nossa introdução da concha. Este contrato serve como o único intermediário entre os utilizadores e o Yield. Ele exerce um controlo extensivo sobre tesouraria e contabilidade, mas em troca, oferece imensa flexibilidade para o desenvolvimento de funcionalidades.

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

• Cada activo tem o 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 contabilística. Este contrato também supervisiona as medidas de gestão do risco e realiza verificações de garantia.
• A função de colateralização consulta oráculos para determinar preços e taxas de juro.
• Ambos os oráculos do preço e da taxa de juro partilham uma interface unificada.
• As taxas de juro são geradas externamente.
• Os utilizadores podem pedir emprestado fazendo um único pedido a apenas um contrato.

A evolução arquitectónica do financiamento composto

A primeira versão do Compound era uma prova de conceito, demonstrando que um mercado monetário poderia ser estabelecido no Ethereum. Por esta razão, a simplicidade foi priorizada no 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, tais como cheques de garantia, são consolidadas num único contrato.
• Este contrato recupera os preços dos oráculos mas determina as taxas de juro com base na utilização de ativos.
• Os utilizadores interagem exclusivamente com este contrato, embora devam fazer chamadas separadas para fornecer garantias e emprestar ativos.

Composto v2

O Compound v2 foi lançado em maio de 2019, dando início à era da agricultura de rendimento e inspirando inúmeros garfos. Também funcionava como um mercado monetário, permitindo que os utilizadores emprestassem e emprestassem ativos.

Com base no seu whitepaper e estrutura, é evidente que um dos principais objetivos do Compound v2 era usar o padrão ERC20 para representar as posições de empréstimo. Isso garantiu a capacidade de composição, permitindo que os utilizadores emprestassem ao Compound e usassem essas posições com juros noutras aplicações blockchain.

Curiosamente, o whitepaper não destacava que o Compound v2 incorporava recompensas nos 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 activo tem o 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 a notar as garantias do utilizador e a dívida.
• Um contrato singular, o Controlador, registra e impõe parâmetros de gestão de risco, incluindo verificações de garantia.
• O contrato responsável pelas verificações de garantia faz referência aos oráculos para os preços e o cToken para as taxas de juro.
• Os oráculos do preço e da taxa de juro operam com diferentes interfaces.
• A taxa de juro deriva internamente da utilização de ativos.
• Os utilizadores devem interagir com vários contratos para pedir emprestado.

Composto v3

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

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

O sistema é mais intuitivo tanto para programadores como para utilizadores devido à redução do número de chamadas necessárias. Além disso, o design singular do contrato reduz os custos do gás minimizando as chamadas entre contratos. Os mercados monetários segregados são uma defesa contra ataques baseados na oracle, que são agora uma grande preocupação de segurança.

Outras características relevantes mencionadas nas notas de lançamento incluem:

• Um motor de gestão de risco e liquidação completamente renovado. Este design aumenta a segurança do fundo ao mesmo tempo que é mais amigável para os mutuários.
• Estabelecer limites em todo o mercado para ativos de garantia individuais para mitigar riscos.
• Os modelos de taxa de juro para ganhar e contrair empréstimos estão agora separados, com a governação a ter controlo total sobre as políticas económicas.

Curiosamente, o Compound v3 espelha a arquitetura do Compound v1 ao ter um único contrato para lidar com todas as funções para cada ativo emprestável. Outras características notáveis incluem:

• Apenas os ativos emprestados podem ser emprestados; os activos de garantia não podem.
• A garantia não produz retornos no Composto v3.

A proibição de pedir garantias de empréstimo aumenta a segurança para aqueles que depositam a garantia. Isto diminui a probabilidade de erros de governação ou ataques intencionais colocarem em risco a garantia.

Eliminar os retornos das garantias fornecidas pode ser o resultado de a Compound conseguir obter muita liquidez na v2. Tenho a intuição de que no Compound v2 os limites de empréstimo eram inferiores ou não muito superiores aos ativos emprestados à aplicação pelos utilizadores.

Supondo que vão gerir níveis semelhantes de liquidez para a v3, não permitir que as garantias sejam emprestadas torna a aplicação segura, um dos principais objetivos da v3.

Do ponto de vista arquitectónico:

• Cada mercado monetário é um contrato individual com a sua tesouraria, contabilidade e gestão de risco
• Cada mercado monetário retém o ativo emprestável juntamente 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 juro para empréstimos e empréstimos são geradas internamente
• Funções tradicionais como fornecimento/retirada/emprestado/reembolso foram inteligentemente consolidadas. Agora, retirar um ativo que pode ser emprestado de um mercado monetário implica contrair empréstimos, enquanto fornecê-lo indica reembolso ou empréstimo com base na dívida do utilizador
• Um contrato de encaminhamento está integrado, permitindo múltiplas operações numa única chamada

A evolução arquitectónica da Aave

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

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

Tal como no Yield v2, o contrato do router também mantinha a lógica empresarial. O LendingPoolCore implementou funções de contabilidade, gestão de risco e tesouraria. A junção do tesouro num único contrato foi um ponto diferenciador do Compound v2.

A decisão de deixar os cheques de garantia no seu próprio contrato, chamada do router e não do contrato contabilístico parece fraca, mas provavelmente era adequado para o propósito, uma vez que o Aave v2 só foi lançado dois anos após o lançamento da v1

• O contrato LendingPoolCore lida com tesouraria e contabilidade
• LendingPoolDataProvider gere verificações de colateralização e interage com o oráculo
• O LendingPool serve como o ponto de entrada do utilizador e implementa a lógica empresarial
• As taxas de juro para empréstimos e empréstimos são determinadas internamente, baseando-se apenas em feeds de preços

Aave v2

O Aave v2 foi lançado em dezembro de 2021. Embora tenha mantido características semelhantes ao Aave v1, introduziu uma arquitectura melhorada e mais simples em comparação com o Aave v1 e o Compound v2. Com este lançamento, a Aave também introduziu ATokens (semelhante aos cTokens do Compound) e vTokens, que representam dívida tokenizada.

O Aave v2 tem uma arquitetura muito limpa, totalmente tokenizada.

Certas funcionalidades do Aave v1, que tinham uma utilização limitada, foram omitidas para simplificar. 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, tais como verificações de garantia. Serve como o principal ponto de acesso para os utilizadores
• ATokens significam garantia e são como posições de empréstimo. A garantia dos utilizadores é refletida através das suas participações no AToken e a função de tesouraria é distribuída por todos os ATokens
• Os vTokens são usados para representar posições de dívida. A dívida de um utilizador é representada pelos vTokens que detém

Aave v3

O Aave v3 foi lançado em Janeiro de 2023 com suporte multi-cadeia e outras funcionalidades. Estas adições não alteram a arquitectura principal. A atualização também possui uma melhor gestão de risco e eficiência de gás.

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

A evolução arquitectónica de Euler

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

Uma característica do seu design é o padrão tipo diamante. Um único contrato contém todo o armazenamento da aplicação. Este armazenamento pode ser acedido através de proxies distintos, cada um gerindo um elemento conceptual diferente do sistema.

Mesmo que um contrato armazena todos os dados de ativos, contabilidade e gestão de risco, ainda existem eTokens para garantia e empréstimos, e DTokens para dívida, semelhante ao Aave v2. No entanto, estes contratos de token são apenas visões do contrato de armazenamento central.

• O contrato de armazenamento gere variáveis contabilísticas.
• O contrato BaseLogic funciona como o tesouro.
• O contrato do RiskManager supervisiona as variáveis e funções de gestão do risco, incluindo verificações de garantia.

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 assegurada através de testes e auditorias rigorosos. Apenas a lógica foi distribuída por vários módulos, servindo de implementação para o contrato de armazenamento, que funcionava principalmente como um contrato de proxy.

Este design unificado também suporta upgrades fáceis. Os módulos podem ser rapidamente substituídos para alterar ou introduzir funcionalidades se não forem necessárias alterações de armazenamento.

O Euler foi invadido quinze meses após o seu lançamento e seis meses depois que a actualização introduziu a vulnerabilidade explorada.

Não acho que a arquitetura monolítica tenha desempenhado um papel nos ativos que estão sendo drenados; em vez disso, foi uma supervisão insuficiente das atualizações de código.

Conclusão

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

As primeiras aplicações Ethereum, como MakerDAO, Compound e Aave, mostraram o potencial de empréstimos sobrecolateralizados no Ethereum. Uma vez que estas provas de conceito foram bem-sucedidas, o foco mudou para a introdução de uma mistura de novas funcionalidades para captar quota de mercado. As versões posteriores do Compound e da Aave introduziram o yield farming, a composabilidade e a liquidez conjunta, que prosperou especialmente durante as condições de mercado de alta.

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

Os altos custos do gás surgiram como uma grande preocupação durante o mercado em alta, levando a modificações na experiência do utilizador, como visto no Yield v2, Aave v2 e Euler. Os contratos de router e as implementações monolíticas ajudaram a reduzir os custos incorridos pelos utilizadores para as transações. No entanto, isto veio à custa de um código mais complexo e, consequentemente, mais arriscado.

O Compound v3 parece abrir um precedente, priorizando a segurança em detrimento da eficiência financeira. Desvia-se do modelo tradicional de pool de liquidez para melhor proteger contra potenciais hacks. O aumento das redes L2, onde os custos do gás estão a tornar-se cada vez mais insignificantes, provavelmente moldará o design de futuras aplicações de empréstimos colateralizados.

Neste artigo, forneci uma visão geral abrangente das principais aplicações de empréstimos garantidos no Ethereum. A abordagem que empreguei para analisar cada aplicação também pode ser aplicada para compreender rapidamente os meandros de outros pedidos de empréstimos com garantia.

Ao desenvolver uma aplicação de empréstimo de blockchain, considere sempre o armazenamento de ativos, a colocação de registos contabilísticos e os métodos de avaliação do risco e das garantias. À medida que trabalha com estas considerações, baseia-se no histórico de aplicações anteriores e nos insights desta visão geral para informar as suas decisões.

Obrigado pela leitura e boa sorte.

Obrigado à Calnix por rever e editar este artigo.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [hackernoon]. Todos os direitos de autor pertencem ao autor original [alcueca]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.