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.
Los préstamos son una piedra angular de las aplicaciones blockchain basadas en Ethereum . Con
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
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.
La mayoría de los préstamos DeFi son
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.
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:
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.
Logotipo de MakerDAO
La función de tesorería en MakerDAO es administrada por el
Hay un
Por el contrario, MakerDAO no posee ningún DAI, el activo de préstamo.
En cambio, simplemente
La contabilidad se lleva dentro del
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
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:
Reconociendo el potencial de YieldSpace, rápidamente hicimos la transición al desarrollo
El proceso de préstamo en Yield v2, fuertemente influenciado por MakerDAO
Todos los controles de contabilidad, gestión de riesgos y garantías se consolidaron en un solo contrato: el
Renovamos nuestra integración de oráculos, fusionando oráculos de precios y tasas de interés en un
Otra desviación significativa del enfoque de MakerDAO fue nuestra introducción del
En resumen, pedir prestado en Yield v2 funciona de la siguiente manera:
El
El proceso de préstamo en Compound v1. Sencillo pero eficaz.
Basado en su
Curiosamente, el documento técnico no destacó que Compound v2 incorporara
El proceso de préstamo en Compound v2. Primera incursión en posiciones de préstamos tokenizadas.
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 el
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:
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:
El proceso de préstamo en Aave v1. La liquidez mancomunada significaba eficiencia financiera y computacional.
Como en Yield v2, el
La decisión de dejar los controles de garantía en
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.
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.
Una característica distintiva de su diseño es la
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.
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 .
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 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
El autor es cofundador y líder técnico de Yield Protocol.