Pruebas de propiedades generalizadas para bóvedas ERC4626

A medida que DeFi crece y madura, la infraestructura escalable y la componibilidad son lo más importante para los desarrolladores. Solicitudes de comentarios (o ERC) de Ethereum: conjuntos de herramientas estandarizados para crear aplicaciones basadas en Ethereum, como el estándar de token ampliamente utilizado ERC20 — cumplir el papel esencial de proporcionar pautas consistentes para que los desarrolladores contribuyan al ecosistema sin comenzar desde cero. A principios de este año, estándar de bóveda tokenizada ERC4626 fue creado para fomentar la compatibilidad cruzada entre los tokens que generan rendimiento. La estandarización de los detalles de las implementaciones también puede abordar problemas urgentes de composición, lo que hace que la integración del protocolo sea más fácil y, en última instancia, menos propensa a errores.

Varios proyectos DeFi ya han adoptado el estándar, buscando aumentar la componibilidad de sus bóvedas, y anticipamos una adopción más amplia en todo el ecosistema. Sin embargo, adaptar las bóvedas existentes causa algunos dolores de crecimiento; críticamente, ciertos errores de implementación pueden exponer nuevos objetivos para ataques. Incluso pequeños errores (tan pequeños como malinterpretar la interfaz estándar) pueden tener consecuencias significativas tanto para la seguridad como para la experiencia del usuario, lo que subraya la necesidad de más herramientas y medidas de seguridad, particularmente dentro de un ecosistema DeFi más componible. 

Afortunadamente, los errores simples pueden tener soluciones relativamente simples si se detectan mucho antes de que se exploten (e idealmente antes de que se implementen). Con ese fin, lanzamos Pruebas de propiedad ERC4626 para fuzzing y ejecución simbólica para ayudar a los constructores de bóvedas a detectar violaciones estándar que pueden romper integraciones o generar vulnerabilidades en el futuro. En esta publicación, explicamos el problema motivador, repasamos nuestro enfoque y concluimos con algunos consejos prácticos.

Primero, un poco de información sobre el estándar ERC4626

Finalizado en marzo, ERC4626 es el estándar para las bóvedas tokenizadas. Se introdujo con el fin de extender el ampliamente utilizado ERC20 estándar (actualmente la base para cientos de tokens), fomentar la estandarización en las bóvedas con rendimiento y garantizar la componibilidad de las aplicaciones y protocolos (por ejemplo, agregadores de rendimiento) que necesitan interactuar con ellos. Esto significa que cualquier aplicación creada en una bóveda ERC4626 se puede ampliar fácilmente para que funcione con cualquier otra bóveda ERC4626. 

Las bóvedas tokenizadas permiten a los usuarios depositar libremente activos para acuñar acciones de la bóveda y luego canjear esas acciones para retirar capital e intereses de la bóveda. Estas acciones de bóveda son tokens ERC20 y, por lo tanto, pueden intercambiarse fácilmente o usarse como garantía para pedir prestados otros activos. Por ejemplo, los usuarios pueden depositar sus activos en las bóvedas de Yearn para acuñar tokens de yVault, que luego pueden negociarse en Uniswap, apostarse para obtener un rendimiento adicional o usarse como garantía para los protocolos de préstamo.

La lógica comercial para generar y distribuir el rendimiento (y determinar el precio de las acciones) puede variar según las implementaciones. Para cubrir la mayor cantidad posible de bóvedas (con el objetivo de hacerlas interoperables frente a idénticas), el estándar ERC4626 se enfoca en describir la interfaz de usuario, dejando sin especificar la mayoría de los detalles de implementación. Esto permite variaciones en la lógica comercial siempre que la bóveda cumpla con los requisitos específicos de la interfaz y alienta interoperabilidad entre muchos tipos diferentes de aplicaciones y tipos de bóvedas ERC4626.

A medida que se creen más bóvedas, esperamos verlas implementadas de acuerdo con el estándar ERC4626 desde el principio; pero actualmente estamos en una fase de transición, donde los desarrolladores que buscan aprovechar una mayor componibilidad necesitarán actualizar las bóvedas, las aplicaciones y los protocolos existentes para cumplir con el estándar. Y a medida que se actualizan, se enfrentan a una serie de complejidades y desafíos. 

Los desafíos de la conformidad estándar (y las trampas de no cumplir)

Seguir un nuevo estándar no siempre es sencillo. Cada bóveda ERC4626 debe implementar fielmente (y exactamente) los requisitos del estándar como se describe. De lo contrario, la integración de las bóvedas ERC4626 se vuelve cada vez más compleja para tener en cuenta las diferentes variaciones. Esta complejidad hace que las integraciones sean inherentemente propensas a errores; y debido a que no son suficientemente a prueba de futuro, pueden conducir a vulnerabilidades de seguridad con el tiempo.

Los tokens ERC20 no estándar (p. ej., Tether USD) requieren que muchos sistemas DeFi usen una biblioteca adicional (como SafeERC20) al realizar transferencias de tokens para lidiar de manera segura con comportamientos divergentes (por ejemplo, no devolver nada cuando una transferencia tiene éxito en lugar de devolver true). Esto significa que cualquier sistema que interactúe con estos tokens podría volverse vulnerable si el sistema no está diseñado para manejar adecuadamente los casos de "devoluciones faltantes". Estos escenarios pueden potencialmente introducir una trampa de seguridad común y aumentar los costos generales de desarrollo y mantenimiento (al tener en cuenta la lógica adicional y las dependencias necesarias para mitigar los problemas). Por lo tanto, cumplir con el estándar es fundamental no solo para las implementaciones individuales sino también para la seguridad de todo el ecosistema. Una vulnerabilidad en un solo sistema o dependencia puede causar problemas generalizados.

Idealmente, los estándares se especificarían formalmente sin ambigüedad (p. ej., especificación formal de ERC20), y cada implementación podría verificarse formalmente con la especificación estándar. En la práctica, sin embargo, esto no es fácil de lograr en un corto período de tiempo, debido al costo y esfuerzo que requiere de la comunidad.

Presentamos propiedades ejecutables ERC4626 para identificar problemas de conformidad 

A medida que trabajamos hacia un estado ideal (cada bóveda verificada formalmente con especificaciones formales rigurosas), hemos escrito el estándar ERC4626 propiedades para detectar discrepancias en detalles sutiles y fáciles de perder de los requisitos estándar.  

Los desarrolladores de Vault pueden ejecutar las pruebas para detectar posibles infracciones estándar en sus implementaciones antes de la implementación. Y los integradores de bóvedas pueden verificar si las bóvedas dadas siguen el estándar antes de integrarlas en su sistema. Las propiedades también se pueden probar con las bóvedas en vivo ya implementadas en la red principal, a través de la prueba de bifurcación de la red principal. Puede ser útil probar las bóvedas en vivo, especialmente cuando las bóvedas se implementaron o actualizaron recientemente, para garantizar que todos los parámetros del sistema se hayan configurado correctamente. 

Elegimos pruebas basadas en propiedades, escritas en Foundry y listas para ser ejecutadas por su fuzzer, para hacer que las propiedades sean ejecutables (y, por lo tanto, comprobables). En el futuro, también pueden ejecutarse mediante herramientas de ejecución simbólica o verificación de modelos para verificar formalmente que la bóveda dada cumple las propiedades para todas las entradas y condiciones posibles.

Escribimos las propiedades para que fueran lo suficientemente generales como para aplicarlas a una amplia gama de bóvedas que implementan diferentes lógicas comerciales. Usamos solo funciones de interfaz pública para que sean independientes de los detalles de implementación. (Sin embargo, debido a esta restricción, se omitieron de las propiedades ciertos requisitos estándar que hacen referencia a datos internos específicos de la implementación).

Por ejemplo, la siguiente propiedad corresponde a uno de los requisitos de la convertToShares() función, "NO DEBE mostrar variaciones dependiendo de la persona que llama.” Dadas las dos direcciones de cuenta y el monto, hace que cada una de las cuentas llame convertToShares() con la misma cantidad, y asegura que los dos valores devueltos sean iguales. Esta propiedad es independiente de los detalles de implementación de convertToShares(), que varía según las bóvedas y debe cumplirse con cualquier bóveda que implemente ERC4626. Esta propiedad se puede ejecutar proporcionando valores de entrada específicos (para pruebas unitarias), muchas entradas aleatorias (para pruebas de fuzz) o valores simbólicos (para ejecución simbólica y verificación formal). También se puede ejecutar localmente o contra una bifurcación de red principal (para pruebas de integración).

Caso de uso: propiedades que comprueban los errores de redondeo

Los errores de redondeo, por ejemplo, son una clase importante de errores (aparentemente menores) que pueden tener algunas implicaciones en la serie. La lógica contable subyacente de ERC4626, por ejemplo, calcular el número de acciones que se acuñarán o la cantidad de activos que se retirarán, se implementa utilizando aritmética de punto fijo: los errores de redondeo son inevitables. Para EN LINEA, sin embargo, el estándar especifica explícitamente la dirección de redondeo preferida para cada función de interfaz, dejando los límites de error sin especificar y dependientes de la implementación. Específicamente, el deposit() y redeem() Las funciones deben devolver un bajo-aproximación del valor exacto, mientras que el mint() y withdraw() Las funciones deben devolver un Más de-aproximación. Por ejemplo, si el precio actual de la acción (es decir, la cantidad de activos por acción) es 2, entonces deposit() con 3 wei de activos solo debe acuñar hasta 1 wei de acciones (es decir, floor(3/2)), mientras withdraw() con 3 wei de activos debe quemar al menos 2 wei de acciones (es decir, ceil(3/2)).

Escribimos las propiedades relacionadas con el redondeo para que sean independientes de la lógica contable subyacente tratándolas como una caja negra. Específicamente, las formulamos como las llamadas propiedades de "ida y vuelta", que describen la relación entre dos funciones opuestas. Por ejemplo, la siguiente propiedad especifica que el retiro de activos que acaban de depositarse mediante la acuñación de N acciones debe quemar no menos de N acciones. En otras palabras, nadie puede obtener una ganancia gratuita convirtiendo activos y acciones de bóveda de un lado a otro acuñando y retirando repetidamente.

De hecho, encontramos que varias bóvedas ERC4626 en la red principal no cumplen con la propiedad anterior debido a errores de redondeo. Esto significa que cualquiera podría ganar, por ejemplo, un par de satoshi BTC (1 satoshi ~= 0.02 centavos en el momento de escribir este artículo) simplemente (y repetidamente) acuñando y retirando, vaciando lentamente la bóveda. En realidad, esto puede generar ganancias en las cadenas que disfrutan de tarifas de gasolina muy bajas (por ejemplo, Fantom), o si el precio del activo se vuelve lo suficientemente alto en el futuro.

Probando el estándar ERC4626 en la naturaleza

Probamos nuestras propiedades con ~100 bóvedas ERC4626 en la red principal y encontramos muchas bóvedas que no cumplían con los requisitos estándar, principalmente debido a los errores de redondeo (p. ej., usar el redondeo del piso donde se desea el techo, como describimos). Específicamente, ciertas bóvedas no lograron acuñar el número exacto de acciones solicitadas por el mint() función, aunque la norma requiere explícitamente así. Algunos de ellos también emitieron un sonido inconsistente. Deposit evento en el que los datos registrados son diferentes de los que realmente se acuñaron. Para nuestra sorpresa, algunas bóvedas nunca se acuñaron en el lugar; en cambio, simplemente ponen las solicitudes de menta en una cola y las procesan más tarde en un lote como una transacción separada.

Aunque estos comportamientos divergentes no eran explotables per se, pueden volverse vulnerables cuando se integran en otros sistemas que esperan solo los comportamientos estándar. Estos problemas harán que la integración de la bóveda sea mucho más difícil, neutralizando potencialmente los esfuerzos en curso e impulsando la motivación detrás de la estandarización.

Uso de nuestras pruebas de propiedad y otros pasos procesables hacia la conformidad con el estándar

Seguir el estándar con precisión puede prevenir comportamientos divergentes (idealmente antes de que se implementen). Esperamos que nuestras propiedades ayuden, junto con algunos elementos de acción adicionales. Para aquellos que están desarrollando y/o integrando bóvedas ERC4626:

• Recomendamos encarecidamente administrar nuestra propiedad pruebas contra tus bóvedas. Encontrarán problemas rápidamente si hay alguna violación clara del estándar.
• También sugerimos revisar nuestra propiedades para verificar su comprensión de los requisitos estándar y ajustar su implementación si hay alguna discrepancia no intencional.
• Si su bóveda tiene que divergir del estándar, recomendamos documentar claramente los comportamientos no estándar, para que otros puedan manejar adecuadamente estas desviaciones al integrarse con su bóveda. Tenga en cuenta que esto debe considerarse como último recurso.

***
Las bóvedas ERC4626 tienen el potencial de convertirse en un bloque de construcción importante para DeFi en el futuro previsible y, en aras de la componibilidad, es importante que las bóvedas nuevas y existentes sigan el estándar. Surgirán nuevas implementaciones siguiendo el estándar, por lo que no hay mejor momento que el presente para estandarizar las bóvedas existentes. 

A medida que trabajamos hacia un estado ideal (donde diferentes bóvedas se pueden componer de manera uniforme), se pueden ejecutar pruebas de propiedad ERC4626 para detectar más fácilmente las violaciones estándar en las implementaciones de bóvedas. Las pruebas de propiedad (con documentación y ejemplos) están todas disponibles públicamente en nuestro Github repositorio. ¡Agradecemos sus comentarios y contribuciones!

***
Las opiniones expresadas aquí son las del personal individual de AH Capital Management, LLC ("a16z") citado y no son las opiniones de a16z o sus afiliados. Cierta información contenida aquí se ha obtenido de fuentes de terceros, incluso de compañías de cartera de fondos administrados por a16z. Si bien se tomó de fuentes que se consideran confiables, a16z no ha verificado de forma independiente dicha información y no hace declaraciones sobre la precisión actual o duradera de la información o su idoneidad para una situación determinada. Además, este contenido puede incluir anuncios de terceros; a16z no ha revisado dichos anuncios y no respalda ningún contenido publicitario incluido en ellos.

Este contenido se proporciona solo con fines informativos y no debe considerarse como asesoramiento legal, comercial, de inversión o fiscal. Debe consultar a sus propios asesores sobre estos asuntos. Las referencias a cualquier valor o activo digital son solo para fines ilustrativos y no constituyen una recomendación de inversión ni una oferta para proporcionar servicios de asesoramiento de inversión. Además, este contenido no está dirigido ni destinado a ser utilizado por ningún inversionista o posible inversionista, y bajo ninguna circunstancia se puede confiar en él al tomar una decisión de invertir en cualquier fondo administrado por a16z. (Una oferta para invertir en un fondo a16z se realizará solo mediante el memorando de colocación privada, el acuerdo de suscripción y otra documentación relevante de dicho fondo y debe leerse en su totalidad). Cualquier inversión o compañía de cartera mencionada, referida o descritos no son representativos de todas las inversiones en vehículos administrados por a16z, y no puede garantizarse que las inversiones serán rentables o que otras inversiones realizadas en el futuro tendrán características o resultados similares. Una lista de inversiones realizadas por fondos administrados por Andreessen Horowitz (excluyendo inversiones para las cuales el emisor no ha otorgado permiso para que a16z divulgue públicamente, así como inversiones no anunciadas en activos digitales que cotizan en bolsa) está disponible en https://a16z.com/investments /.

Los cuadros y gráficos proporcionados en el interior tienen únicamente fines informativos y no se debe confiar en ellos al tomar cualquier decisión de inversión. El rendimiento pasado no es indicativo de resultados futuros. El contenido habla sólo a partir de la fecha indicada. Todas las proyecciones, estimaciones, pronósticos, objetivos, perspectivas y/u opiniones expresadas en estos materiales están sujetas a cambios sin previo aviso y pueden diferir o ser contrarias a las opiniones expresadas por otros. Consulte https://a16z.com/disclosures para obtener información adicional importante