Préstamo en Ethereum: comparación de la evolución de la arquitectura de MakerDAO, Yield, Aave, Compound y Euler

Los préstamos son una piedra angular de las aplicaciones blockchain basadas en Ethereum . Con miles de millones en activos prestados Sin embargo, comprender cómo funcionan los préstamos es crucial para los desarrolladores, arquitectos o investigadores.

Al igual que la evolución de los paradigmas de programación, estas aplicaciones DeFi tienen diversos diseños arquitectónicos, lo que refleja prioridades cambiantes que van desde la seguridad hasta la eficiencia y la experiencia del usuario.

Este análisis analiza la arquitectura de aplicaciones como fabricantedao , Compuesto , Aave , Euler , y Producir . Destacaremos las innovaciones clave y los patrones de diseño, que son lecciones importantes para el desarrollo de futuras aplicaciones de préstamos.

Si es desarrollador, arquitecto o investigador de seguridad, este artículo es para usted. Al final, comprenderá fácilmente las nuevas aplicaciones de préstamo en Ethereum y comprenderá su arquitectura de manera rápida y completa. Sumérgete para ver cómo se construyen estos gigantes de DeFi desde cero.

Préstamo en DeFi

La mayoría de los préstamos DeFi son sobrecolateralizado . Un usuario puede pedir prestado un activo específico si proporciona una garantía por un valor superior al préstamo. A diferencia de los préstamos convencionales, muchos de estos préstamos no tienen pagos regulares ni fechas de finalización fijas. En esencia, puedes pedir prestado y nunca pagar.

Sin embargo, hay un problema.

El valor de la garantía siempre debe exceder el valor del préstamo por un margen predeterminado .

Si el valor de la garantía cae por debajo de este valor, el préstamo se cancela. liquidado .

Durante la liquidación, otra persona paga parte o la totalidad de su préstamo y recibe a cambio parte o la totalidad de su garantía.

Todas las solicitudes de préstamo que siguen esta estructura financiera necesitan los mismos elementos básicos, que luego se pueden organizar de muchas maneras:

• Una tesorería para almacenar garantías de los usuarios y activos prestados.
• Un sistema de contabilidad que rastrea las garantías y la deuda de cada usuario.
• Funciones que determinan la tasa de interés de los prestatarios
• Un mecanismo para verificar si un préstamo está suficientemente garantizado, generalmente involucrando oráculos de precios externos.
• Una vía de liquidación para préstamos con garantía insuficiente
• Sistemas de gestión de riesgos que registran los montos totales prestados y otras métricas de seguridad, como límites de endeudamiento global y por usuario, mínimos de garantía y ratios específicos de sobregarantía.
• Una interfaz para que los usuarios agreguen y eliminen garantías, tomen prestado y paguen el subyacente
  

Los préstamos y los empréstitos pueden considerarse como características separadas. En DeFi encontramos ambas características en la mayoría de aplicaciones de préstamo, pero no siempre están bien integradas .

En Compound, Aave y Euler lo son . Las tasas de interés para prestatarios y prestamistas están internamente correlacionadas; de hecho, eso es lo que hace que esas aplicaciones funcionen con una mínima intervención.

Por otro lado, MakerDAO y Yield son los originadores de los activos que prestan a los prestatarios.

No requieren que los usuarios proporcionen activos para que otros usuarios puedan pedir prestado .

Este artículo se centrará en los préstamos en cadena y ignorará en gran medida los préstamos. El endeudamiento es mucho más complicado debido al requisito de garantía, y comprender el patrón de endeudamiento generalmente permite comprender mejor todo el protocolo.

La evolución arquitectónica de MakerDAO

fabricantedao , antiguo en términos de Ethereum, se lanzó en su forma actual en noviembre de 2019 , y se sostiene 4.950 millones de dólares en garantía . A pesar de su arquitectura modular con contratos distintos para cada función y terminología única, sigue siendo fácil de entender y verificar.

La función de tesorería en MakerDAO es administrada por el Unirse contratos.

Hay un contrato separado por cada token aprobado como activo colateral.

Por el contrario, MakerDAO no posee ningún DAI, el activo de préstamo.

En cambio, simplemente menta y quema DAI según sea necesario.

La contabilidad se lleva dentro del iva .sol contrato. Las uniones actualizar este contrato cuando la garantía entra o sale del sistema. Si un usuario pide prestado, interactuar con el contrato vat.sol directamente .

Esta acción actualiza el saldo de deuda del usuario y le permite acuñar DAI en DAI Join.

Para pagar, los usuarios queman DAI en DAI Join. Luego, este proceso actualiza el IVA, lo que permite al usuario liquidar su préstamo .

Además, el contrato vat.sol sirve como base gestión de riesgos motor. Mantiene límites de endeudamiento global, establece umbrales mínimos por usuario y supervisa los índices de garantía.

Cuando se realizan cambios en el saldo de deuda o garantía de un usuario, el contrato vat.sol evalúa tanto la tasa como el spot.

Estos se refieren a la tasa de interés basada en la garantía utilizada y la relación prevaleciente entre el precio de DAI y la garantía. Curiosamente, estos valores se introducen en el contrato vat.sol mediante otros contratos MakerDAO, un método distinto de la mayoría de las otras aplicaciones.

MakerDAO dio prioridad a la seguridad durante su fase de diseño, una época en la que factores como los costos del gas eran secundarios , la experiencia del usuario era una preocupación menor y la competencia era insignificante.

En consecuencia, puede parecer peculiar, costoso de usar y difícil de navegar.

Sin embargo, los vastos activos que administra y su historial de operación sin violaciones significativas subrayan su sólido diseño y ejecución.

Reflejos:

• Cada activo tiene su propio contrato en la función de tesorería con diferencial máximo.
• La función contable está centralizada en un único contrato que también documenta y hace cumplir los parámetros de riesgo, incluidos los controles de garantía.
• A diferencia de otras aplicaciones, los oráculos actualizan el contrato y supervisan la garantía.
• Los oráculos de precios y tipos de interés utilizan interfaces distintas
• La tasa de interés se origina externamente.
• Para pedir prestado, los usuarios deben interactuar con múltiples contratos

La evolución arquitectónica del protocolo de rendimiento

Rendimiento v1 sirvió como prueba de concepto para tarifas fijas utilizando Espacio de rendimiento . Esta versión construyó su motor de deuda garantizada sobre MakerDAO. Sin embargo, Yield v1 era costoso de usar y difícil de mejorar con nuevas funciones.

Reconociendo el potencial de YieldSpace, rápidamente hicimos la transición al desarrollo Rendimiento v2 . Todavía inspirándose en MakerDAO, pero ahora completamente independiente, Yield v2 lanzado en octubre de 2021 ; Yield v2 priorizó la reducción de costos de gas y una experiencia de usuario mejorada.

Todos los controles de contabilidad, gestión de riesgos y garantías se consolidaron en un solo contrato: el Caldera . Siguiendo el enfoque de MakerDAO, distribuimos las funciones de tesorería entre Unirse contratos, cada uno dedicado a un activo específico.

Renovamos nuestra integración de oráculos, fusionando oráculos de precios y tasas de interés en un interfaz común . Revertimos el flujo del oráculo de MakerDAO de modo que Cauldron consulta oráculos según sea necesario para los controles de garantía. Que yo sepa, este es el flujo preferido en todas partes excepto en MakerDAO.

Otra desviación significativa del enfoque de MakerDAO fue nuestra introducción del Cucharón . Este contrato sirve como único intermediario entre los usuarios y Yield. Ejerce un amplio control sobre la tesorería y la contabilidad, pero a cambio ofrece una inmensa flexibilidad para el desarrollo de funciones .

En resumen, pedir prestado en Yield v2 funciona de la siguiente manera:

• Cada activo tiene su propio contrato de tesorería exclusivo, lo que garantiza la máxima distribución de la función de tesorería.
• Un contrato singular centraliza la función contable. Este contrato también supervisa las medidas de gestión de riesgos y realiza controles de garantía.
• La función de garantía consulta oráculos para determinar precios y tasas de interés.
• Tanto los oráculos de precios como de tipos de interés comparten una interfaz unificada.
• Las tasas de interés se generan externamente.
• Los usuarios pueden pedir prestado realizando una única solicitud para un solo contrato.

La evolución arquitectónica de las finanzas compuestas

El primera versión del compuesto era un Prueba de concepto , lo que demuestra que se podría establecer un mercado monetario en Ethereum. Por ello se priorizó la sencillez en su diseño. El MercadoMoney.sol El contrato encapsula todas las funciones, incluido el préstamo.

• Las tareas de tesorería, contabilidad y gestión de riesgos, como las comprobaciones de garantías, se consolidan en un solo contrato.
• Este contrato recupera los precios de los oráculos pero determina las tasas de interés en función de la utilización de los activos.
• Los usuarios interactúan únicamente con este contrato, aunque deben realizar llamadas por separado para proporcionar garantías y tomar prestados activos.

Compuesto v2

Compound v2 se lanzó en mayo de 2019 , iniciando la era del cultivo de rendimiento e inspirando innumerables bifurcaciones. También funcionó como un mercado monetario, permitiendo a los usuarios prestar y pedir prestado activos.

Basado en su papel blanco y estructura, es evidente que un objetivo importante para Compuesto v2 era utilizar el Estándar ERC20 para representar posiciones crediticias . Esto aseguró la componibilidad, permitiendo a los usuarios prestar a Compound y luego usar esas posiciones que devengan intereses en otras aplicaciones de blockchain.

Curiosamente, el documento técnico no destacó que Compound v2 incorporara recompensas en sus contratos inteligentes. Dada esta omisión, es posible que no se hubiera previsto el inmenso impacto de esta característica.

• Cada activo tiene su propio contrato de tesorería, maximizando la distribución de la función de tesorería.
• La función de contabilidad también se distribuye, y cada cToken registra la garantía y la deuda del usuario.
• Un contrato singular, el Contralor, registra y hace cumplir los parámetros de gestión de riesgos, incluidos los controles de garantía.
• El contrato responsable de las comprobaciones de garantía hace referencia a los oráculos para los precios y al cToken para las tasas de interés.
• Los oráculos de precios y tipos de interés operan con diferentes interfaces.
• La tasa de interés se deriva internamente de la utilización de los activos.
• Los usuarios deben interactuar con múltiples contratos para pedir prestado.

Compuesto v3

Lanzado en 2022 , Compuesto v3 adopta una estrategia de gestión de riesgos más conservadora, segregando la liquidez en piscina para cada activo prestable. El diseño también revela preocupaciones sobre la facilidad de uso y los costos del gas.

El sistema es más intuitivo tanto para desarrolladores como para usuarios debido a la reducción en el número de llamadas requeridas. Además, el diseño singular del contrato reduce los costos del gas al minimizar las llamadas entre contratos. Los mercados monetarios segregados son una defensa contra los ataques basados en oráculos, que ahora son una importante preocupación de seguridad.

Otras características relevantes mencionadas en el Notas de lanzamiento incluir:

• Un motor de liquidación y gestión de riesgos completamente renovado. Este diseño mejora la seguridad de los fondos y al mismo tiempo es más amigable para los prestatarios.
• Establezca límites en todo el mercado para los activos de garantía individuales para mitigar los riesgos.
• Los modelos de tasas de interés para ganar y endeudarse ahora están separados, y la gobernanza tiene control total sobre las políticas económicas.

Curiosamente, Compound v3 refleja la arquitectura de Compound v1 al tener un único contrato que maneja todas las funciones para cada activo prestable. Otras características notables incluyen:

• Sólo se pueden tomar prestados activos prestados; los activos colaterales no pueden.
• La garantía no produce rendimientos en el Compuesto v3.

La prohibición de pedir prestado garantía aumenta la seguridad de quienes depositan la garantía. Esto reduce la probabilidad de que errores de gobernanza o ataques intencionales pongan en peligro la garantía.

La eliminación de los rendimientos de la garantía proporcionada podría ser el resultado de que Compound haya logrado acumular mucha liquidez en v2. Tengo la intuición de que en Compound v2 los límites de endeudamiento estaban por debajo o no mucho más que los activos prestados a la aplicación por los usuarios.

Suponiendo que gestionarán niveles similares de liquidez para la v3, no permitir el préstamo de garantías hace que la aplicación sea segura, uno de los objetivos principales de la v3.

Desde un punto de vista arquitectónico:

• Cada mercado monetario es un contrato individual con su tesorería, contabilidad y gestión de riesgos.
• Cada mercado monetario retiene el activo prestable junto con todos sus tokens de activos colaterales aprobados, lo que hace que los activos se dispersen en toda la aplicación.
• Los precios son el único insumo externo; Las tasas de interés para préstamos y préstamos se generan internamente.
• Funciones tradicionales como suministrar/retirar/pedir prestado/pagar se han consolidado inteligentemente. Ahora bien, retirar un activo prestable de un mercado monetario implica pedir prestado, mientras que ofrecerlo indica reembolso o préstamo en función de la deuda del usuario.
• Se integra un contrato de enrutamiento que permite múltiples operaciones en una sola llamada.

La evolución arquitectónica de Aave

Aave v1 era lanzado en octubre de 2019 , sucediendo a ETHLend. En lugar del enfoque peer-to-peer de ETHLend, Aave v1 introdujo un fondo de liquidez compartido.

Como en Yield v2, el contrato de enrutador También sostuvo la lógica empresarial. El PréstamoPoolCore implementó funciones de contabilidad, gestión de riesgos y tesorería. Agrupar la tesorería en un solo contrato fue un punto diferenciador del Compound v2.

La decisión de dejar los controles de garantía en su propio contrato , llamado desde el enrutador y no desde el contrato de contabilidad parece débil, pero probablemente fue adecuado para su propósito ya que Aave v2 solo se lanzó dos años después del lanzamiento de v1.

• El contrato LendingPoolCore se encarga de la tesorería y la contabilidad.
• LendingPoolDataProvider gestiona los controles de garantía e interactúa con el oráculo
• LendingPool sirve como punto de entrada del usuario e implementa lógica empresarial.
• Las tasas de interés para préstamos y préstamos se determinan internamente, basándose únicamente en los precios.

Aavev2

Aavev2 era lanzado en diciembre de 2021 . Si bien conservó características similares a Aave v1, introdujo una arquitectura mejorada y más simple en comparación con Aave v1 y Compound v2. Con este lanzamiento, Aave también presentó tokens (similar a los cTokens de Compound) y tokens virtuales , que representan deuda tokenizada.

Ciertas funciones de Aave v1, que tenían un uso limitado, se omitieron por simplicidad. Los problemas de Aave v1, como la compleja representación de los intereses acumulados, se abordaron en Aave v2.

• El contrato LendingPool consolida funciones globales de contabilidad y gestión de riesgos, como los controles de garantías. Sirve como punto de acceso principal para los usuarios.
• Los tokens significan garantía y son similares a posiciones de préstamo. La garantía de los usuarios se refleja a través de sus tenencias de aTokens y la función de tesorería se distribuye entre todos los aTokens.
• Los vTokens se utilizan para representar posiciones de deuda. La deuda de un usuario está representada por los vTokens que posee

Aavev3

Aavev3 era lanzado en enero de 2023 con soporte para múltiples cadenas y otras características. Estas adiciones no alteran la arquitectura central. La actualización también cuenta con una mejor gestión de riesgos y eficiencia del gas.

A pesar de sus muchos avances, para los propósitos de este estudio, Aave v3 no es materialmente diferente de Aave v2. De hecho, podría sugerir que la arquitectura de Aave v2 seguirá siendo sólida en 2023.

La evolución arquitectónica de Euler

Euler era lanzado en diciembre de 2022 , con el objetivo de ofrecer mercados monetarios con características sin permiso y una gobernanza mínima.

Una característica distintiva de su diseño es la como diamante patrón. A Un solo contrato contiene todo el almacenamiento de la aplicación. . A este almacenamiento se puede acceder a través de distintos apoderados , cada uno gestionando un elemento conceptual diferente del sistema.

Aunque un contrato almacena todos los datos de activos, contabilidad y gestión de riesgos, todavía hay eTokens para garantías y préstamos, y dTokens para deudas, similar a Aave v2. Sin embargo, estos contratos simbólicos son meras vistas del contrato de almacenamiento central.

• El Almacenamiento contrato gestiona las variables contables.
• El Lógica base El contrato funciona como tesorería.
• El Administrador de riesgos El contrato supervisa las variables y funciones de gestión de riesgos, incluidas las comprobaciones de garantías.

Un análisis del código revela que el costo mínimo del gas era una prioridad, lo que llevó al diseño monolítico a eliminar la necesidad de llamadas entre contratos. La seguridad se garantizó mediante pruebas y auditorías rigurosas. Sólo la lógica se distribuyó entre varios módulos, sirviendo como implementación para el contrato de almacenamiento, que actuaba principalmente como un contrato proxy.

Este diseño unificado también admite actualizaciones sencillas. Los módulos se pueden reemplazar rápidamente para modificar o introducir funciones si no se requieren cambios en el almacenamiento .

Euler fue pirateado quince meses después de su lanzamiento y seis meses después de que la actualización introdujera la vulnerabilidad explotada.

No creo que la arquitectura monolítica haya influido en el drenaje de los activos; más bien, fue una supervisión insuficiente de las actualizaciones del código .

Conclusión

Las primeras aplicaciones de Ethereum, como MakerDAO, Compound y Aave, mostraron el potencial de los préstamos con garantía excesiva en Ethereum. Una vez que estas pruebas de concepto resultaron exitosas, la atención se centró en introducir una combinación de nuevas características para capturar participación de mercado. Las versiones posteriores de Compound y Aave introdujeron agricultura de rendimiento, componibilidad y liquidez agrupada, que prosperaron especialmente durante condiciones de mercado alcistas.

Un avance significativo fue la introducción de posiciones de préstamos tokenizadas en Compound v2, lo que permitió que otras aplicaciones reconocieran estas posiciones como activos estándar. Aave v2 y Euler dieron un paso más al implementar posiciones de deuda tokenizadas, cuya utilidad más amplia sigue siendo un tema de debate.

Los altos costos del gas surgieron como una preocupación importante durante el mercado alcista, lo que provocó modificaciones en la experiencia del usuario, como se ve en Yield v2, Aave v2 y Euler. Los contratos de enrutador y las implementaciones monolíticas ayudaron a reducir los costos en los que incurrieron los usuarios por las transacciones. Sin embargo, esto se produjo a expensas de un código más complejo y, en consecuencia, más riesgoso.

El compuesto v3 parece sentar un precedente, priorizando la seguridad sobre la eficiencia financiera. Se desvía del modelo tradicional de fondo de liquidez para protegerse mejor contra posibles ataques. El aumento de las redes L2, donde los costos del gas son cada vez más insignificantes, probablemente moldeará el diseño de futuras solicitudes de préstamos garantizados.

En este artículo, proporcioné una descripción general completa de las principales aplicaciones de préstamos con garantía en Ethereum. El enfoque que he empleado para analizar cada solicitud también se puede aplicar para comprender rápidamente las complejidades de otras solicitudes de préstamos con garantía.

Al desarrollar una aplicación de préstamo blockchain, siempre considere el almacenamiento de activos, la ubicación de los registros contables y los métodos de evaluación de riesgos y garantías. A medida que analiza estas consideraciones, aproveche el historial de aplicaciones anteriores y los conocimientos de esta descripción general para fundamentar sus decisiones.

Gracias por leer y mucha suerte.

Gracias a Calnix por revisar y editar este artículo.