Tras múltiples incidentes de ataques DeFi ocurridos en abril, el debate sobre la seguridad en la industria de las finanzas descentralizadas (DeFi) está mostrando un giro claramente perceptible. Antes, el protocolo DeFi se sometía con más frecuencia a escrutinio para determinar si sus contratos inteligentes habían sido auditados y si el código contenía vulnerabilidades; pero Andre Cronje, fundador de Flying Tulip, declaró recientemente en una entrevista con Cointelegraph que el riesgo de muchos protocolos DeFi de hoy ya no proviene únicamente del código en cadena, sino de permisos de actualización, gobernanza multisig, infraestructura fuera de la cadena y procesos operativos del equipo.
DeFi ya no es código que no se puede modificar
Cronje afirmó que, si se toma la definición estricta de DeFi en sus inicios —“descentralizado, inmutable, sin necesidad de confianza”—, entonces muchos protocolos actuales en realidad ya no pueden seguir considerándose DeFi puro. Incluso incluyó a Flying Tulip en este juicio, al señalar que la industria actual se parece más a servicios financieros con fines de lucro gestionados por equipos, en lugar de ser una infraestructura financiera pública completamente inmutable.
Dijo: «Creo que lo que tenemos hoy, incluido Flying Tulip, ya no es DeFi. No es finanzas descentralizadas ni es código inmodificable, sino un negocio lucrativo gestionado por un equipo».
Estas declaraciones señalan la realidad más incómoda a la que se enfrenta la industria DeFi: muchos protocolos aún utilizan el relato, la valoración y el lenguaje de marca de DeFi, pero en su funcionamiento real, hace tiempo que dependen de un gran control humano y de procesos fuera de la cadena.
El mayor riesgo de DeFi ya no son solo fallas de contratos
Cronje considera que el modelo de seguridad de DeFi temprano era relativamente simple: después del despliegue del protocolo, los contratos inteligentes eran inmutables y los usuarios asumían principalmente el riesgo de la lógica del código. Pero ahora, los sistemas DeFi suelen ser mucho más complejos: los protocolos pueden usar proxy upgrade para actualizar contratos, gestionar permisos clave mediante multisig, depender de proveedores de infraestructura externa y, cuando ocurre un incidente, que el equipo central ejecute la respuesta de crisis.
Esto implica que los problemas de seguridad se han ampliado de “si el código tiene un bug” a “quién tiene el permiso de actualizar el contrato”, “quién controla el multisig”, “si el time lock es suficiente”, “si un servidor fuera de la cadena o una interfaz de administración podría ser atacado”, “si el equipo puede reaccionar correctamente ante situaciones anómalas”.
Cronje señaló que la industria en el pasado aún ponía demasiado énfasis en las auditorías de contratos inteligentes, pero recientemente muchos ataques se parecen más a problemas de seguridad tradicionales de Web2 o TradFi; por ejemplo, que se comprometan permisos de acceso a infraestructura, ataques de ingeniería social, que se abuse de procesos de gestión, o que se ataque y comprometa un nodo de un solo permiso.
En otras palabras, DeFi no es que no necesite auditorías, sino que confiar solo en auditorías ya no es suficiente. Cuando un protocolo se puede actualizar, se puede administrar y se puede intervenir de forma humana, debe reconocer que también tiene riesgos operativos que suelen enfrentar las instituciones financieras tradicionales.
Flying Tulip incorpora un mecanismo de circuito de interrupción de retiros
En este contexto, Flying Tulip incorporó recientemente un mecanismo de circuito de interrupción de retiros (withdrawal circuit breaker). Así, cuando el protocolo detecta salidas anómalas de fondos, puede retrasar o poner en cola el procesamiento de los retiros. Cronje enfatizó que este mecanismo no está pensado para impedir de forma permanente que los usuarios retiren fondos, ni para que el equipo congele fondos a discreción; su propósito es ganar una ventana de tiempo breve para que el protocolo responda ante situaciones anómalas.
Tomando como ejemplo a Flying Tulip, este mecanismo puede darle al equipo aproximadamente 6 horas. Cronje cree que, si el tamaño del equipo es más pequeño y la distribución de sus miembros no es lo bastante global, podría requerirse entre 12 y 24 horas, o incluso más, para completar confirmaciones internas, firmas y la respuesta cuando ocurra un ataque.
La lógica de este tipo de diseño es muy parecida a la suspensión de operaciones o a las “puertas” de gestión de riesgos en mercados financieros tradicionales: cuando el sistema presenta liquidez anómala o fuga de activos, no se determina de inmediato que todas las transacciones sean inválidas; primero se reduce la velocidad del sistema para evitar que el atacante se lleve todo el capital en cuestión de minutos.
Sin embargo, Cronje también recalcó que el mecanismo de interrupción solo puede ser parte de una arquitectura de seguridad por capas y no puede considerarse una panacea. La protección real todavía debe incluir auditorías, multisig descentralizado, time locks, procesos de gobernanza, mecanismos de monitoreo y control de permisos.
El costo del circuito de interrupción: ¿proteger a los usuarios o crear nuevas puertas traseras centralizadas?
No obstante, el mecanismo también desató de inmediato una disputa de líneas entre los desarrolladores de DeFi. Curve Finance y Michael Egorov, fundador de Yield Basis, estuvieron de acuerdo en que los ataques recientes efectivamente revelaron riesgos de centralización fuera de la cadena, pero se mostraron altamente cautos ante la solución de “aumentar el control de emergencia humano”.
Egorov señaló que muchos eventos importantes recientes de DeFi no se debieron a que los contratos inteligentes en sí fueran comprometidos, sino a fallas puntuales fuera de la cadena. Puso el ejemplo de eventos relacionados con rsETH y afirmó que los contratos inteligentes de Aave, Kelp y LayerZero no fueron hackeados; el verdadero problema estuvo en la infraestructura fuera de la cadena.
Por lo tanto, para Egorov, si el mayor riesgo ya proviene de las personas y los permisos fuera de la cadena, entonces añadir un mecanismo de interrupción controlado por humanos podría ser simplemente concentrar más poder en manos de unos pocos firmantes o administradores.
Egorov teme que, si los permisos de control de emergencia permiten a los firmantes modificar contratos, pausar retiros o intervenir el flujo de fondos, una vez que los firmantes sean atacados, este mecanismo originalmente pensado para proteger a los usuarios puede volverse, en cambio, una herramienta para que los hackers extraigan el capital, o convertirse en una puerta trasera para congelar activos de manera centralizada. Su conclusión es que el diseño de DeFi debería reducir en lo posible los puntos únicos de falla humanos, en lugar de resolver el problema de fallas humanas con más permisos humanos.
DeFi tiene que reconocer en qué se está convirtiendo
La divergencia entre Cronje y Egorov, en apariencia, es una disputa sobre el mecanismo de interrupción; pero en realidad es una disputa sobre la identidad de DeFi. La postura de Cronje es más realista: si muchos protocolos ya no son contratos inmutables, sino productos financieros con permisos de actualización, procesos de gestión y operación del equipo, entonces se debe admitir esta realidad e introducir medidas de control de riesgos acordes.
Egorov, en cambio, está más cerca de los deontólogos del DeFi: si la seguridad de DeFi proviene de la descentralización, entonces la solución no debería consistir en entregar más poder de control a personas, sino en diseñar sistemas que dependan menos de la intervención humana.
Ambos en el fondo reconocen una sola cosa: el mayor problema de DeFi ahora no es solo si el código de los contratos está bien escrito, sino a quién, exactamente, confían los usuarios. Si un protocolo puede actualizarse, puede pausar, puede poner en cola retiros y puede cambiar la lógica central mediante multisig, entonces el riesgo que asumen los usuarios ya no es solo el riesgo de contrato inteligente, sino el riesgo de gobernanza del equipo, el riesgo de los firmantes, el riesgo de infraestructura y el riesgo operativo.
¿Este artículo sigue siendo DeFi descentralizado? Andre Cronje: admitirlo, la mayoría de los protocolos son código modificable; apareció por primera vez en el sitio Chain News ABMedia.
