TLDR: ERC-4626 es el estándar para bóvedas tokenizadas.
Antes de la introducción de ERC-4626, cada bóveda tenía su propia especificación y detalles de implementación. Esto hace que la integración sea difícil, propensa a errores y un desperdicio de recursos.
ERC-4626 intenta resolver este problema con una especificación estándar para reducir el esfuerzo de integración y crear un modelo de implementación más consistente y robusto, como ERC-20.
¿Qué es ERC-4626?
ERC-4626 es un estándar que mejora los parámetros técnicos de las bóvedas de rendimiento. Proporciona una API estándar para bóvedas de rendimiento que representan acciones de un único token ERC-20 subyacente.
Las bóvedas tokenizadas se han convertido en un modelo extremadamente común en DeFi. Los agregadores de rendimiento, los mercados de préstamos, los derivados de participación y muchos otros dApps aprovechan y confían en bóvedas tokenizadas. Los ejemplos de bóvedas tokenizadas incluyen Yearn y Balancer. Como agregador de rendimiento, Yearn Vault permite a los usuarios depositar activos digitales y obtener rendimiento. Balancer es un administrador de cartera automatizado y proveedor de liquidez que se basa en bóvedas en el centro de su lógica comercial. Estas bóvedas administran tokens en varios grupos. Al mismo tiempo, separan la gestión de tokens de la lógica del propio grupo.
El protocolo mejora la liquidez y la flexibilidad al tokenizar sus bóvedas. Las bóvedas tokenizadas facilitan las transacciones y el uso de activos en las plataformas DeFi. Además, permiten la creación de productos financieros diversos e interconectados. La industria ha estado defendiendo este paradigma, a menudo denominado "Lego monetario".
Sin embargo, la composición sin la adecuada adaptabilidad o estandarización presenta desafíos. No solo dificulta que los desarrolladores cumplan con los estándares de la industria como ERC-20, sino que también puede confundir a los nuevos desarrolladores. Sin una adecuada adaptación o estandarización, es difícil revisar nuevos cambios y verificar los detalles de implementación de las integraciones.
Por lo tanto, se propuso ERC-4626 para resolver este problema y simplificar la integración, al tiempo que permite a los participantes de DeFi adoptar finalmente una especificación de bóveda unificada más segura y robusta. Esto, a su vez, reducirá la posible superficie de ataque del protocolo al tiempo que integra tokens en múltiples protocolos.
¿Qué problemas de seguridad puede prevenir ERC-4626?
Al proporcionar un estándar unificado, ERC-4626 acelera la construcción de la integración entre protocolos. Los estándares familiares y consistentes también son más fáciles de entender para los desarrolladores, lo que reduce la probabilidad de errores de codificación. Esto ayuda a prevenir problemas de composición. La estandarización también evita la duplicación de esfuerzos, ya que la comunidad solo necesita diseñar la bóveda una vez, en lugar de individualmente para cada protocolo. Dado que este esfuerzo de diseño a menudo es propenso a errores, ayuda a evitar la duplicación de fallas de diseño establecidas pero generalizadas.
Presentaremos dos casos de estudio aquí para mostrar qué problemas puede prevenir el ERC-4626.
Evento Rari Capital
Se robaron tokens por un valor aproximado de $ 11 millones de Rari Capital, lo que equivale al 60% de todos los fondos de los usuarios en el grupo Ethereum de Rari Capital.
En general, Rari Capital fue pirateado debido a una implementación insegura de protocolos cruzados. Su grupo Ethereum lleva ETH al contrato de token ibETH de Alpha Finance como una estrategia de salida. Esta estrategia específica rastrea el valor de su tipo de cambio ibETH/ETH a través de ciertos contratos y fórmulas (específicamente, la función ibETH.totalETH / ibETH.totalSupply), que pueden tener resultados erróneos en este escenario de ataque, por ejemplo, al llamar a ibETH.work ( ), los valores de la deuda pueden inflarse artificialmente.
Un atacante puede agotar el Rari Fund Manager simplemente llamando repetidamente a las funciones de depósito y retiro en el contrato de RariFundManager. Las funciones de depósito y retiro necesitan obtener el saldo del grupo para calcular la cantidad de tokens REPT que se emitirán a la persona que llama, o la cantidad de ETH que se emitirá a la persona que llama. Esta operación llamará a la función getBalance del grupo Alpha , llame al contrato ibETH y su función totalETH . Rari no es consciente de la posibilidad de manipular esta función.
Hay otra función en el contrato ibETH: ibETH.work. Esta función puede llamar a cualquier contrato especificado por el usuario. Esto permite que las funciones de depósito y retiro de Rari vuelvan a entrar y se llamen varias veces.
La función de trabajo es una función de pago, lo que significa que el usuario puede controlar la cantidad de ETH en el contrato ibETH a través de la función de trabajo, cambiando así el valor devuelto por la función totalETH. Para empeorar las cosas, la función de trabajo también admite llamar a cualquier otro contrato, como RariFundManager.
A través de esta función, el atacante puede enviar ETH nuevamente y aumentar la cantidad total de ETH en el contrato ibETH y, al mismo tiempo, llamar a retirar en el contrato RariFundManager para canjear más activos.
Este incidente destaca los riesgos significativos que plantean la integración insuficiente y los diseños incompatibles en los contratos de DeFi. Destaca cómo los estándares como ERC-4626 pueden prevenir tales ataques al agregar una capa crítica de seguridad y previsibilidad, y promover un comportamiento uniforme y la comprensión mutua.
Caso de finanzas crema
Cream Finance sufrió un ataque sofisticado que explotó dos debilidades fundamentales en la plataforma: un oráculo de mezcla manipulado y un suministro de tokens sin límite. Una parte clave del ataque fue la manipulación del oráculo de mezcla, que afectó el valor percibido del token yUSD. Cuando el atacante envió una gran cantidad de tokens Yearn 4-Curve a la bóveda yUSD, cambió el tipo de cambio informado por la bóveda y, por lo tanto, también afectó el valor percibido de los tokens yUSD para el oráculo.
La lección clave aquí es que un oráculo de precios sólido e inmanejable es fundamental para la estabilidad de un protocolo DeFi. Los oráculos de precio promedio ponderado en el tiempo (TWAP) pueden ayudar a prevenir tales ataques porque son más resistentes a la manipulación repentina de precios.
Estos problemas y otros patrones de diseño frágiles pueden mitigarse mediante la adopción e implementación cuidadosas de ERC-4626.
Posibles riesgos de seguridad en ERC-4626
Siempre hay algunas compensaciones con el uso de un nuevo protocolo. Para las bóvedas tokenizadas, puede haber problemas potenciales al integrarlas en contratos inteligentes que requieren atención especial.
Administrar tokens feeOnTransfer
Si la bóveda está diseñada para admitir tokens feeOnTransfer, verifique que la cantidad y las acciones en la bóveda estén dentro del rango esperado al transferir activos.
Uso adecuado de la variable decimales
Aunque la función convertTo no debería necesitar usar la variable de decimales de la bóveda EIP-4626, aún se recomienda encarecidamente reflejar los decimales del token subyacente cuando sea factible. Esta práctica ayuda a eliminar posibles fuentes de confusión y simplifica la integración para varios usuarios front-end y fuera de la cadena.
redondeo
De acuerdo con la especificación, los implementadores de la bóveda deben tener en cuenta que se requieren direcciones de redondeo específicas y opuestas en diferentes métodos mutables y de vista, ya que es más seguro priorizar la bóveda en sí sobre sus usuarios durante los cálculos:
Si está calculando la cantidad de acciones que se emitirán a un usuario por la cantidad de algún token subyacente que ofrecen, o si está operando para transferir una acción específica del token subyacente a un usuario, debe redondearse hacia abajo.
Si está calculando cuántas acciones tiene que dar un usuario para obtener una cierta cantidad de fichas base, o si está calculando cuántas fichas base tiene que dar un usuario para obtener una cierta cantidad de acciones, debería ser redondeado.
Donde la dirección de redondeo preferida será ambigua es la función convertTo. Para garantizar la coherencia en todas las implementaciones del almacén EIP-4626, especifique que estas funciones siempre deben redondearse hacia abajo. Los integradores pueden imitar ellos mismos la versión redondeada, por ejemplo, agregando un Wei al resultado.
La cantidad de activos subyacentes que recibe un usuario al canjear su participación en la bóveda (previewRedeem) puede variar significativamente de la cantidad que tendría que pagar para emitir la misma cantidad de participación (previewMint). Estas diferencias pueden ser pequeñas (por ejemplo, debido a errores de redondeo) o grandes (por ejemplo, una bóveda implementa tarifas de retiro o depósito). Por lo tanto, los integradores deben tener cuidado de usar las funciones de vista previa que mejor se adapten a su caso de uso y nunca asumir que son intercambiables.
Anular la funcionalidad principal
Para implementar o ampliar la funcionalidad prevista, se recomienda utilizar enlaces existentes en lugar de cambiar la funcionalidad principal. Esta práctica garantiza un seguimiento más manejable para realizar pruebas y auditorías de código eficientes.
Cuota cero
La especificación original para ERC-4626 no describía cómo manejar el caso de la esquina sin acciones en la bóveda, y si la bóveda debería comportarse normalmente o retroceder. Esto puede ser una fuente potencial de confusión y errores.
Bóvedas como oráculos de precios
Con respecto al riesgo de ataques de manipulación de precios de Oracle, los valores devueltos por estos métodos de vista previa son lo más precisos posible. Como tales, pueden operar cambiando las condiciones en la cadena y no siempre son seguros para usar como oráculos de precios. La especificación ERC-4626 incluye un método de conversión y un método de activos totales que permiten imprecisión y, por lo tanto, se pueden implementar como un poderoso oráculo de precios. Por ejemplo, al convertir entre activos y acciones, es correcto usar el precio promedio ponderado en el tiempo para implementar el método de conversión.
Cuestiones concretas de implementación
Los integradores deben revisar cualquier implementación de bóveda tokenizada antes de una mayor integración, ya que puede haber implementaciones maliciosas que parecen ajustarse a la especificación de la interfaz, pero cuyas funciones principales consisten en especificaciones de diseño completamente diferentes.
Acceso directo de EOA
Si se va a acceder directamente a una bóveda, su implementación debe tener características que puedan usarse para acomodar pérdidas por deslizamiento o límites de depósito/retiro accidentales. A diferencia de los contratos inteligentes, EOA no tiene un mecanismo a prueba de fallas para la reversión de transacciones.Si no se logra el resultado preciso al llamar a la función central, no hay forma de revertir.
Bóveda extendida
A medida que más jugadores comiencen a adoptar el estándar ERC-4626, veremos más extensiones implementadas para el estándar. Por ejemplo, Superform desarrolló una extensión experimental de Multi Vault que admite el uso de diferentes cálculos dentro de un solo contrato de Vault. Naturalmente, cuanto más se desvía la implementación del estándar original, mayor es la posibilidad de introducir nuevas vulnerabilidades. Los desarrolladores y auditores pueden encontrar su mejor opción según el caso de uso para determinar el valor real en riesgo.
Es importante tener en cuenta que no es la adición más pequeña de cada protocolo lo que conduce a eventos catastróficos, sino la suma de ellos cuando se integran.
Los posibles vectores de ataque mencionados anteriormente son algunos de los problemas más discutidos en torno al estándar ERC-4626. A medida que aumente la adopción, definitivamente exploraremos más casos de uso de implementación y escenarios más adecuados para la integración con las bóvedas ERC-4626.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Comprender ERC-4626 en un artículo: el nuevo estándar para bóvedas tokenizadas de DeFi
TLDR: ERC-4626 es el estándar para bóvedas tokenizadas.
Antes de la introducción de ERC-4626, cada bóveda tenía su propia especificación y detalles de implementación. Esto hace que la integración sea difícil, propensa a errores y un desperdicio de recursos.
ERC-4626 intenta resolver este problema con una especificación estándar para reducir el esfuerzo de integración y crear un modelo de implementación más consistente y robusto, como ERC-20.
¿Qué es ERC-4626?
ERC-4626 es un estándar que mejora los parámetros técnicos de las bóvedas de rendimiento. Proporciona una API estándar para bóvedas de rendimiento que representan acciones de un único token ERC-20 subyacente.
Las bóvedas tokenizadas se han convertido en un modelo extremadamente común en DeFi. Los agregadores de rendimiento, los mercados de préstamos, los derivados de participación y muchos otros dApps aprovechan y confían en bóvedas tokenizadas. Los ejemplos de bóvedas tokenizadas incluyen Yearn y Balancer. Como agregador de rendimiento, Yearn Vault permite a los usuarios depositar activos digitales y obtener rendimiento. Balancer es un administrador de cartera automatizado y proveedor de liquidez que se basa en bóvedas en el centro de su lógica comercial. Estas bóvedas administran tokens en varios grupos. Al mismo tiempo, separan la gestión de tokens de la lógica del propio grupo.
El protocolo mejora la liquidez y la flexibilidad al tokenizar sus bóvedas. Las bóvedas tokenizadas facilitan las transacciones y el uso de activos en las plataformas DeFi. Además, permiten la creación de productos financieros diversos e interconectados. La industria ha estado defendiendo este paradigma, a menudo denominado "Lego monetario".
Sin embargo, la composición sin la adecuada adaptabilidad o estandarización presenta desafíos. No solo dificulta que los desarrolladores cumplan con los estándares de la industria como ERC-20, sino que también puede confundir a los nuevos desarrolladores. Sin una adecuada adaptación o estandarización, es difícil revisar nuevos cambios y verificar los detalles de implementación de las integraciones.
Por lo tanto, se propuso ERC-4626 para resolver este problema y simplificar la integración, al tiempo que permite a los participantes de DeFi adoptar finalmente una especificación de bóveda unificada más segura y robusta. Esto, a su vez, reducirá la posible superficie de ataque del protocolo al tiempo que integra tokens en múltiples protocolos.
¿Qué problemas de seguridad puede prevenir ERC-4626?
Al proporcionar un estándar unificado, ERC-4626 acelera la construcción de la integración entre protocolos. Los estándares familiares y consistentes también son más fáciles de entender para los desarrolladores, lo que reduce la probabilidad de errores de codificación. Esto ayuda a prevenir problemas de composición. La estandarización también evita la duplicación de esfuerzos, ya que la comunidad solo necesita diseñar la bóveda una vez, en lugar de individualmente para cada protocolo. Dado que este esfuerzo de diseño a menudo es propenso a errores, ayuda a evitar la duplicación de fallas de diseño establecidas pero generalizadas.
Presentaremos dos casos de estudio aquí para mostrar qué problemas puede prevenir el ERC-4626.
Evento Rari Capital
Se robaron tokens por un valor aproximado de $ 11 millones de Rari Capital, lo que equivale al 60% de todos los fondos de los usuarios en el grupo Ethereum de Rari Capital.
En general, Rari Capital fue pirateado debido a una implementación insegura de protocolos cruzados. Su grupo Ethereum lleva ETH al contrato de token ibETH de Alpha Finance como una estrategia de salida. Esta estrategia específica rastrea el valor de su tipo de cambio ibETH/ETH a través de ciertos contratos y fórmulas (específicamente, la función ibETH.totalETH / ibETH.totalSupply), que pueden tener resultados erróneos en este escenario de ataque, por ejemplo, al llamar a ibETH.work ( ), los valores de la deuda pueden inflarse artificialmente.
Un atacante puede agotar el Rari Fund Manager simplemente llamando repetidamente a las funciones de depósito y retiro en el contrato de RariFundManager. Las funciones de depósito y retiro necesitan obtener el saldo del grupo para calcular la cantidad de tokens REPT que se emitirán a la persona que llama, o la cantidad de ETH que se emitirá a la persona que llama. Esta operación llamará a la función getBalance del grupo Alpha , llame al contrato ibETH y su función totalETH . Rari no es consciente de la posibilidad de manipular esta función.
Hay otra función en el contrato ibETH: ibETH.work. Esta función puede llamar a cualquier contrato especificado por el usuario. Esto permite que las funciones de depósito y retiro de Rari vuelvan a entrar y se llamen varias veces.
La función de trabajo es una función de pago, lo que significa que el usuario puede controlar la cantidad de ETH en el contrato ibETH a través de la función de trabajo, cambiando así el valor devuelto por la función totalETH. Para empeorar las cosas, la función de trabajo también admite llamar a cualquier otro contrato, como RariFundManager.
A través de esta función, el atacante puede enviar ETH nuevamente y aumentar la cantidad total de ETH en el contrato ibETH y, al mismo tiempo, llamar a retirar en el contrato RariFundManager para canjear más activos.
Este incidente destaca los riesgos significativos que plantean la integración insuficiente y los diseños incompatibles en los contratos de DeFi. Destaca cómo los estándares como ERC-4626 pueden prevenir tales ataques al agregar una capa crítica de seguridad y previsibilidad, y promover un comportamiento uniforme y la comprensión mutua.
Caso de finanzas crema
Cream Finance sufrió un ataque sofisticado que explotó dos debilidades fundamentales en la plataforma: un oráculo de mezcla manipulado y un suministro de tokens sin límite. Una parte clave del ataque fue la manipulación del oráculo de mezcla, que afectó el valor percibido del token yUSD. Cuando el atacante envió una gran cantidad de tokens Yearn 4-Curve a la bóveda yUSD, cambió el tipo de cambio informado por la bóveda y, por lo tanto, también afectó el valor percibido de los tokens yUSD para el oráculo.
La lección clave aquí es que un oráculo de precios sólido e inmanejable es fundamental para la estabilidad de un protocolo DeFi. Los oráculos de precio promedio ponderado en el tiempo (TWAP) pueden ayudar a prevenir tales ataques porque son más resistentes a la manipulación repentina de precios.
Estos problemas y otros patrones de diseño frágiles pueden mitigarse mediante la adopción e implementación cuidadosas de ERC-4626.
Posibles riesgos de seguridad en ERC-4626
Siempre hay algunas compensaciones con el uso de un nuevo protocolo. Para las bóvedas tokenizadas, puede haber problemas potenciales al integrarlas en contratos inteligentes que requieren atención especial.
Administrar tokens feeOnTransfer
Si la bóveda está diseñada para admitir tokens feeOnTransfer, verifique que la cantidad y las acciones en la bóveda estén dentro del rango esperado al transferir activos.
Uso adecuado de la variable decimales
Aunque la función convertTo no debería necesitar usar la variable de decimales de la bóveda EIP-4626, aún se recomienda encarecidamente reflejar los decimales del token subyacente cuando sea factible. Esta práctica ayuda a eliminar posibles fuentes de confusión y simplifica la integración para varios usuarios front-end y fuera de la cadena.
redondeo
De acuerdo con la especificación, los implementadores de la bóveda deben tener en cuenta que se requieren direcciones de redondeo específicas y opuestas en diferentes métodos mutables y de vista, ya que es más seguro priorizar la bóveda en sí sobre sus usuarios durante los cálculos:
Si está calculando la cantidad de acciones que se emitirán a un usuario por la cantidad de algún token subyacente que ofrecen, o si está operando para transferir una acción específica del token subyacente a un usuario, debe redondearse hacia abajo.
Si está calculando cuántas acciones tiene que dar un usuario para obtener una cierta cantidad de fichas base, o si está calculando cuántas fichas base tiene que dar un usuario para obtener una cierta cantidad de acciones, debería ser redondeado.
Donde la dirección de redondeo preferida será ambigua es la función convertTo. Para garantizar la coherencia en todas las implementaciones del almacén EIP-4626, especifique que estas funciones siempre deben redondearse hacia abajo. Los integradores pueden imitar ellos mismos la versión redondeada, por ejemplo, agregando un Wei al resultado.
La cantidad de activos subyacentes que recibe un usuario al canjear su participación en la bóveda (previewRedeem) puede variar significativamente de la cantidad que tendría que pagar para emitir la misma cantidad de participación (previewMint). Estas diferencias pueden ser pequeñas (por ejemplo, debido a errores de redondeo) o grandes (por ejemplo, una bóveda implementa tarifas de retiro o depósito). Por lo tanto, los integradores deben tener cuidado de usar las funciones de vista previa que mejor se adapten a su caso de uso y nunca asumir que son intercambiables.
Anular la funcionalidad principal
Para implementar o ampliar la funcionalidad prevista, se recomienda utilizar enlaces existentes en lugar de cambiar la funcionalidad principal. Esta práctica garantiza un seguimiento más manejable para realizar pruebas y auditorías de código eficientes.
Cuota cero
La especificación original para ERC-4626 no describía cómo manejar el caso de la esquina sin acciones en la bóveda, y si la bóveda debería comportarse normalmente o retroceder. Esto puede ser una fuente potencial de confusión y errores.
Bóvedas como oráculos de precios
Con respecto al riesgo de ataques de manipulación de precios de Oracle, los valores devueltos por estos métodos de vista previa son lo más precisos posible. Como tales, pueden operar cambiando las condiciones en la cadena y no siempre son seguros para usar como oráculos de precios. La especificación ERC-4626 incluye un método de conversión y un método de activos totales que permiten imprecisión y, por lo tanto, se pueden implementar como un poderoso oráculo de precios. Por ejemplo, al convertir entre activos y acciones, es correcto usar el precio promedio ponderado en el tiempo para implementar el método de conversión.
Cuestiones concretas de implementación
Los integradores deben revisar cualquier implementación de bóveda tokenizada antes de una mayor integración, ya que puede haber implementaciones maliciosas que parecen ajustarse a la especificación de la interfaz, pero cuyas funciones principales consisten en especificaciones de diseño completamente diferentes.
Acceso directo de EOA
Si se va a acceder directamente a una bóveda, su implementación debe tener características que puedan usarse para acomodar pérdidas por deslizamiento o límites de depósito/retiro accidentales. A diferencia de los contratos inteligentes, EOA no tiene un mecanismo a prueba de fallas para la reversión de transacciones.Si no se logra el resultado preciso al llamar a la función central, no hay forma de revertir.
Bóveda extendida
A medida que más jugadores comiencen a adoptar el estándar ERC-4626, veremos más extensiones implementadas para el estándar. Por ejemplo, Superform desarrolló una extensión experimental de Multi Vault que admite el uso de diferentes cálculos dentro de un solo contrato de Vault. Naturalmente, cuanto más se desvía la implementación del estándar original, mayor es la posibilidad de introducir nuevas vulnerabilidades. Los desarrolladores y auditores pueden encontrar su mejor opción según el caso de uso para determinar el valor real en riesgo.
Es importante tener en cuenta que no es la adición más pequeña de cada protocolo lo que conduce a eventos catastróficos, sino la suma de ellos cuando se integran.
Los posibles vectores de ataque mencionados anteriormente son algunos de los problemas más discutidos en torno al estándar ERC-4626. A medida que aumente la adopción, definitivamente exploraremos más casos de uso de implementación y escenarios más adecuados para la integración con las bóvedas ERC-4626.