Los préstamos son una piedra angular de las aplicaciones blockchain basadas en Ethereum. Con miles de millones en activos prestados, 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 MakerDAO, Compound, Aave, Euler y Yield. 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 están sobregarantizados. 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 liquida.

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

Proceso de préstamo en MakerDAO. Todas las aplicaciones comparten los mismos pasos y funciones.

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

Logotipo de MakerDAO

MakerDAO, antiguo en términos de Ethereum, se lanzó en su forma actual en noviembre de 2019 y tiene 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 se gestiona mediante contratos de unión .

Existe un contrato separado para cada token aprobado como activo colateral.

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

En cambio, simplemente acuña y quema DAI según sea necesario.

La contabilidad se lleva dentro del contrato iva.sol. Los Joins actualizan este contrato cuando la garantía entra o sale del sistema. Si un usuario pide prestado, interactúa directamente con el contrato vat.sol.

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 motor de gestión de riesgos . 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

Yield v1 sirvió como prueba de concepto para tarifas fijas utilizando YieldSpace. 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 de Yield v2. Todavía inspirándose en MakerDAO, pero ahora completamente independiente, Yield v2 se lanzó en octubre de 2021; Yield v2 priorizó la reducción de costos de gas y una experiencia de usuario mejorada.

El proceso de préstamo en Yield v2, fuertemente influenciado por MakerDAO

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

Renovamos nuestra integración de Oracle, fusionando oráculos de precios y tasas de interés en una interfaz común. Invertimos el flujo de oráculos de MakerDAO de modo que Cauldron consulte los oráculos según sea necesario para las comprobaciones 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 Ladle. 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

La primera versión de Compound fue una prueba de concepto, que demostró que se podía establecer un mercado monetario en Ethereum. Por ello se priorizó la sencillez en su diseño. El contrato MoneyMarket.sol resume todas las funciones, incluido el préstamo.

El proceso de préstamo en Compound v1. Sencillo pero eficaz.

• 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.

Según su documento técnico y su estructura, es evidente que un objetivo principal de Compound 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.

El proceso de préstamo en Compound v2. Primera incursión en posiciones de préstamos tokenizadas.

• 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, Compound v3 adopta una estrategia de gestión de riesgos más conservadora, segregando la liquidez en un grupo para cada activo prestable. El diseño también revela preocupaciones sobre la facilidad de uso y los costos del gas.

El proceso de préstamo en Compound v3 (Comet). De vuelta a lo básico, de vuelta a la seguridad. Sin embargo, con una mejor UX.

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 las notas de la versión incluyen:

• 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 se lanzó en octubre de 2019, sucediendo a ETHLend. En lugar del enfoque peer-to-peer de ETHLend, Aave v1 introdujo un fondo de liquidez compartido.

El proceso de préstamo en Aave v1. La liquidez mancomunada significaba eficiencia financiera y computacional.

Al igual que en Yield v2, el contrato del enrutador también contenía la lógica empresarial. LendingPoolCore 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 en el contrato de contabilidad, parece débil, pero probablemente fue adecuada para su propósito ya que Aave v2 solo se lanzó dos años después del lanzamiento de la 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.

aave v2

Aave v2 se lanzó 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 introdujo aTokens (similares a los cTokens de Compound) y vTokens, que representan deuda tokenizada.

Aave v2 tiene una arquitectura muy limpia, totalmente 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

Aave v3 se lanzó 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 se lanzó en diciembre de 2022, con el objetivo de ofrecer mercados monetarios con funciones sin permiso y una gobernanza mínima.

Un sello distintivo de su diseño es el patrón en forma de diamante . Un único contrato contiene todo el almacenamiento de la aplicación. Se puede acceder a este almacenamiento a través de distintos proxies, cada uno de los cuales gestiona 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 contrato de Almacenamiento gestiona las variables contables.
• El contrato BaseLogic funciona como tesorería.
• El contrato RiskManager supervisa las variables y funciones de gestión de riesgos, incluidas las comprobaciones de garantía.

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

El trabajo duro está hecho, repasemos lo que aprendimos.

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 la agricultura de rendimiento, la componibilidad y la liquidez agrupada, que prosperaron especialmente durante las condiciones de mercado alcista.

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 dará forma al 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.

Descargo de responsabilidad:

1. Este artículo se reimprime de [hackernoon]. Todos los derechos de autor pertenecen al autor original [alcueca]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.