Hello. I design and build blockchain solutions. I like to make the complex simple.
Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.
This story contains new, firsthand information uncovered by the writer.
The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.
O empréstimo é a base dos aplicativos blockchain baseados em Ethereum . Com
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
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.
A maior parte dos empréstimos DeFi é
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 é
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:
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.
Logo
A função de tesouraria no MakerDAO é gerenciada pelo
Existe um
Ao contrário, MakerDAO não possui nenhum DAI, o ativo de empréstimo.
Em vez disso, apenas
A contabilidade é tratada dentro do
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
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:
Reconhecendo o potencial do YieldSpace, rapidamente fizemos a transição para o desenvolvimento
O processo de empréstimo no Yield v2, fortemente influenciado pelo MakerDAO
Todas as verificações de contabilidade, gestão de riscos e garantias foram consolidadas em um único contrato: o
Renovamos nossa integração de oráculos, fundindo oráculos de preços e taxas de juros em um
Outro desvio significativo da abordagem da MakerDAO foi a introdução do
Em resumo, o empréstimo no Yield v2 funciona da seguinte forma:
O
O processo de empréstimo no Compound v1. Simples, mas eficaz.
Com base em seu
Curiosamente, o whitepaper não destacou que o Compound v2 incorporou
O processo de empréstimo no Compound v2. Primeira incursão em posições de empréstimo tokenizadas.
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.
Outras características relevantes mencionadas no
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:
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:
O processo de empréstimo no Aave v1. Liquidez conjunta significava eficiência financeira e computacional.
Como no Yield v2, o
A decisão de deixar a garantia é verificada
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.
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.
Uma marca registrada de seu design é a
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.
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 .
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.
Graças a
O autor é cofundador e líder técnico da Yield Protocol.
Empréstimo no Ethereum: Comparando a evolução da arquitetura de MakerDAO, Yield, Aave, Compound e Euler | HackerNoon