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

. Con Sin embargo, comprender cómo funcionan los préstamos es crucial para los desarrolladores, arquitectos o investigadores. Los préstamos son una piedra angular de las aplicaciones blockchain basadas en Ethereum miles de millones en activos prestados 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 , , , , y . Destacaremos las innovaciones clave y los patrones de diseño, que son lecciones importantes para el desarrollo de futuras aplicaciones de préstamos. fabricantedao Compuesto Aave Euler Producir 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 . 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. sobrecolateralizado 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 . 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. En Compound, Aave y Euler lo son son los originadores de los activos que prestan a los prestatarios. Por otro lado, MakerDAO y Yield . 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 , antiguo en términos de Ethereum, y se sostiene . 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. fabricantedao , se lanzó en su forma actual en noviembre de 2019 4.950 millones de dólares en garantía La función de tesorería en MakerDAO es administrada por el Unirse contratos. Hay un por cada token aprobado como activo colateral. contrato separado Por el contrario, MakerDAO no posee ningún DAI, el activo de préstamo. En cambio, simplemente según sea necesario. menta y quema DAI La contabilidad se lleva dentro del contrato. Las uniones cuando la garantía entra o sale del sistema. Si un usuario pide prestado, . .sol iva actualizar este contrato 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 sirve como base motor. Mantiene límites de endeudamiento global, establece umbrales mínimos por usuario y supervisa los índices de garantía. vat.sol gestión de riesgos 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, , la experiencia del usuario era una preocupación menor y la competencia era insignificante. una época en la que factores como los costos del gas eran secundarios 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 sirvió como prueba de concepto para tarifas fijas utilizando . 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. Rendimiento v1 Espacio de rendimiento Reconociendo el potencial de YieldSpace, rápidamente hicimos la transición al desarrollo . Todavía inspirándose en MakerDAO, pero ahora completamente independiente, Yield v2 ; Yield v2 priorizó la reducción de costos de gas y una experiencia de usuario mejorada. Rendimiento v2 lanzado en octubre de 2021 Todos los controles de contabilidad, gestión de riesgos y garantías se consolidaron en un solo contrato: el . Siguiendo el enfoque de MakerDAO, distribuimos las funciones de tesorería entre contratos, cada uno dedicado a un activo específico. Caldera Unirse Renovamos nuestra integración de oráculos, fusionando oráculos de precios y tasas de interés en un . Revertimos el flujo del oráculo de MakerDAO de modo que Cauldron según sea necesario para los controles de garantía. Que yo sepa, este es el flujo preferido en todas partes excepto en MakerDAO. interfaz común consulta oráculos Otra desviación significativa del enfoque de MakerDAO fue nuestra introducción del . Este contrato sirve como único intermediario entre los usuarios y Yield. Ejerce un amplio control sobre la tesorería y la contabilidad, . Cucharón 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 era un , lo que demuestra que se podría establecer un mercado monetario en Ethereum. Por ello se priorizó la sencillez en su diseño. El El contrato encapsula todas las funciones, incluido el préstamo. primera versión del compuesto Prueba de concepto MercadoMoney.sol 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 , 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. Compound v2 se lanzó en mayo de 2019 Basado en su y estructura, es evidente que un objetivo importante para era utilizar el . Esto aseguró la componibilidad, permitiendo a los usuarios prestar a Compound y luego usar esas posiciones que devengan intereses en otras aplicaciones de blockchain. papel blanco Compuesto v2 Estándar ERC20 para representar posiciones crediticias Curiosamente, el documento técnico no destacó que Compound v2 incorporara en sus contratos inteligentes. Dada esta omisión, es posible que no se hubiera previsto el inmenso impacto de esta característica. recompensas 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 , adopta una estrategia de gestión de riesgos más conservadora, segregando la liquidez en para cada activo prestable. El diseño también revela preocupaciones sobre la facilidad de uso y los costos del gas. Lanzado en 2022 Compuesto v3 piscina 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 incluir: Notas de lanzamiento 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 era , sucediendo a ETHLend. En lugar del enfoque peer-to-peer de ETHLend, Aave v1 introdujo un fondo de liquidez compartido. Aave v1 lanzado en octubre de 2019 Como en Yield v2, el También sostuvo la lógica empresarial. El 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. contrato de enrutador PréstamoPoolCore La decisión de dejar los controles de garantía en , 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. su propio contrato 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 era . 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ó (similar a los cTokens de Compound) y , que representan deuda tokenizada. Aavev2 lanzado en diciembre de 2021 tokens tokens virtuales 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 era 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. Aavev3 lanzado en enero de 2023 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 era , con el objetivo de ofrecer mercados monetarios con características sin permiso y una gobernanza mínima. Euler lanzado en diciembre de 2022 Una característica distintiva de su diseño es la patrón. A . A este almacenamiento se puede acceder a través de distintos , cada uno gestionando un elemento conceptual diferente del sistema. como diamante Un solo contrato contiene todo el almacenamiento de la aplicación. apoderados 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 gestiona las variables contables. Almacenamiento El El contrato funciona como tesorería. Lógica base El El contrato supervisa las variables y funciones de gestión de riesgos, incluidas las comprobaciones de garantías. Administrador de riesgos 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. El autor es cofundador y líder técnico de Yield Protocol.

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

Demasiado Largo; Para Leer

@albertocuestacanada

Credibility

HISTORIAS RELACIONADAS