El 21 de noviembre, la red principal de Cardano se bifurcó en dos historias en competencia después de que una única transacción de delegación de participación mal formada explotara un error inactivo en el software de nodo más nuevo.
Durante aproximadamente 14 horas y media, los operadores de grupos de interés y los proveedores de infraestructura observaron cómo los bloques se acumulaban en dos cadenas separadas: una rama “envenenada” que aceptó la transacción no válida y una rama “sana” que la rechazó.
Los intercambios detuvieron los flujos de ADA, las billeteras mostraron saldos conflictivos y los desarrolladores se apresuraron a enviar versiones de nodos parcheados que reunificarían el libro mayor bajo una única historia canónica.
No desaparecieron fondos y la red nunca se detuvo por completo. Aún así, durante medio día, Cardano vivió el escenario sobre el que advierten los defensores de la diversidad de clientes de Ethereum: una división del consenso provocada por un desacuerdo sobre el software en lugar de una bifurcación intencional.
El cofundador de Cardano, Charles Hoskinson, dijo que alertó al FBI y a las “autoridades pertinentes” después de que un ex operador de un grupo de interés admitiera haber transmitido la transacción de delegación mal formada.
El papel de las fuerzas del orden aquí es investigar posibles interferencias criminales con una red informática protegida, según estatutos como la Ley de Abuso y Fraude Informático de EE. UU., ya que introducir deliberadamente (o imprudentemente) un exploit en una infraestructura financiera interestatal viva puede constituir una interrupción no autorizada, incluso si se enmarca como “prueba”.
El incidente ofrece un raro experimento natural sobre cómo las cadenas de bloques de capa 1 manejan los fallos de validación.
Cardano conservó la vida, los bloques siguieron llegando, pero sacrificó la unicidad temporal, creando dos cadenas de apariencia legítima que tuvieron que volver a fusionarse.
Solana, por el contrario, ha optado repetidamente por la solución opuesta: cuando su único cliente sufre un error fatal, la red se detiene por completo y se reinicia bajo intervención humana coordinada.
Ethereum pretende situarse entre esos extremos ejecutando múltiples implementaciones de clientes independientes, apostando a que ninguna base de código pueda arrastrar todo el conjunto de validadores a una cadena no válida.
La división de Cardano y la velocidad con la que se resolvió ponen a prueba si una arquitectura monolítica con versión sesgada puede aproximarse a las propiedades de seguridad de una redundancia multicliente genuina, o si simplemente tuvo suerte.
El error y la partición.
Intersect, el organismo de gobernanza del ecosistema de Cardano, atribuyó la falla a un error de deserialización heredado en el código de manejo de hash para los certificados de delegación.
La falla ingresó al código base en 2022, pero permaneció inactiva hasta que nuevas rutas de ejecución la expusieron en las versiones de nodo 10.3.x a 10.5.1.
Cuando una transacción de delegación mal formada que llevaba un hash de gran tamaño llegó al mempool alrededor de las 08:00 UTC del 21 de noviembre, los nodos más nuevos la aceptaron como válida y construyeron bloques sobre ella.
Los nodos y herramientas más antiguos que no habían migrado a la ruta del código afectado rechazaron correctamente la transacción por considerarla mal formada.
Ese único desacuerdo sobre la validación dividió la red. Los operadores de pools que ejecutaban versiones con errores extendieron la cadena envenenada, mientras que los operadores con software más antiguo extendieron la cadena sana.
Ouroboros, el protocolo de prueba de participación de Cardano, indica a cada validador que siga la cadena válida más pesada que observe, pero “válido” tenía dos definiciones diferentes según la versión del nodo que procesó la transacción.
El resultado fue una partición viva: ambas ramas continuaron produciendo bloques bajo reglas de consenso normales, pero divergían de un ancestro común y no podían reconciliarse sin intervención manual.
El patrón había aparecido en la red de prueba Preview de Cardano el día anterior, provocado por una lógica de delegación casi idéntica.
Ese incidente de la testnet alertó a los ingenieros sobre el error en un entorno de bajo riesgo. Aún así, la solución aún no se había propagado a la red principal cuando un ex operador de pool, que luego afirmó que siguió instrucciones generadas por IA, envió la misma transacción mal formada a la red de producción.
En cuestión de horas, la cadena se había dividido y los proveedores de infraestructura se enfrentaron a la cuestión de qué bifurcación tratar como canónica.
Fallo seguro sin interruptor de apagado
La partición de Cardano se resolvió sola mediante actualizaciones voluntarias en lugar de coordinación de emergencia. Intersect y los desarrolladores principales enviaron versiones parcheadas del nodo 10.5.2 y 10.5.3, que rechazaron correctamente la transacción con formato incorrecto y se reincorporaron a la cadena sana.
A medida que los operadores de grupos de interés y las bolsas adoptaron los parches, el peso del consenso se inclinó gradualmente hacia un solo libro de contabilidad.
A finales del 21 de noviembre, la red había convergido y la rama envenenada fue abandonada.
El incidente expuso una brecha incómoda: dos libros de contabilidad canónicos existían simultáneamente, pero varios límites impidieron que se produjera una reorganización profunda o una pérdida permanente de finalidad.
Primero, el error vivía en la lógica de validación de la capa de aplicación, no en las primitivas criptográficas de Cardano o las reglas de selección de cadena de Ouroboros. Los controles de firmas y la ponderación de las apuestas continuaron funcionando con normalidad. El desacuerdo se centró únicamente en si la transacción de delegación cumplía las condiciones de validez del libro mayor.
En segundo lugar, la partición fue asimétrica. Muchos actores críticos, incluidos operadores de grupos de interés más antiguos y algunos intercambios, ejecutaron software que rechazó la mala transacción, asegurando que un peso sustancial de la participación permaneciera detrás de la cadena saludable desde el principio.
En tercer lugar, Cardano había preposicionado un plan de recuperación de desastres bajo el CIP-135, que documentaba un proceso de coordinación en torno a una cadena canónica en escenarios más extremos.
Intersect está preparado para invocar ese plan como alternativa, pero las actualizaciones voluntarias resultaron suficientes para restaurar el consenso bajo las reglas normales de Ouroboros.
El estrecho alcance del error también fue importante. La falla afectó a una rutina de deserialización de hash específica para transacciones de delegación, una superficie de ataque limitada que podía parcharse y cerrarse sin requerir cambios de protocolo más amplios.
Una vez solucionado, la ruta del exploit desapareció y no quedó disponible ninguna clase generalizable de transacciones mal formadas que desencadenara futuras divisiones.
| Hora (UTC) / Fecha | Fase | Qué pasó | Detección / señal | Paso de mitigación |
|---|---|---|---|---|
| 20 de noviembre de 2025 – tarde | Red de prueba precursora | La transacción de delegación mal formada se envía en la testnet de vista previa y explota un error de deserialización inactivo en el código de manejo de hash, creando una división entre una cadena de testnet “envenenada” y “sana”. | Los ingenieros y SPO ven un comportamiento anómalo en la Vista previa; El incidente se registra y se prepara una respuesta técnica durante la noche porque el error es claramente reproducible. | Los equipos centrales comienzan a desarrollar y probar una revisión y archivos binarios de nodos actualizados para que el mismo patrón con formato incorrecto pueda rechazarse en el futuro. |
| 21 de noviembre de 2025 – alrededor de las 08:00 | Tx mal formado llega a la red principal (T0) | Una transacción de delegación mal formada casi idéntica se transmite en la red principal de Cardano desde una billetera que luego se vinculó a un antiguo operador de grupo de interés. Las versiones de nodos más nuevas lo aceptan; las versiones anteriores lo rechazan, creando dos cadenas en competencia. | Los exploradores de bloques y los paneles de control comienzan a divergir; Algunas SPO notan hashes de punta inconsistentes y una producción de bloques más lenta. | La contención inicial es de procedimiento: a los equipos de intercambios y de infraestructura se les dice que estén atentos a las anomalías mientras los ingenieros confirman que el comportamiento de la red principal coincide con el error de la versión preliminar de la red de prueba. |
| 21 de noviembre de 2025 – minutos después de T0 | Detección formal y bandera pública. | Intersect e IOG clasifican la situación como una “partición temporal de la cadena” entre una cadena envenenada y una sana. Equipos de Intersect, IOG, Cardano Foundation, EMURGO y las principales SPO se unen a un puente de incidentes coordinado. | Las alertas internas se distribuyen en los canales SPO; Intersect señala que los equipos fueron “alertados en cuestión de minutos”. Poco después, se publica en X la publicación “Actualización del incidente de Mainnet” para advertir al ecosistema en general que una transacción con formato incorrecto ha desencadenado una partición. | Los intercambios están pausando los depósitos y retiros de ADA como medida de precaución; Se recomienda a las SPO que no actualicen ciegamente y esperen los archivos binarios parcheados que convergerán en la cadena saludable. |
| 21 de noviembre de 2025 – desde última hora de la mañana hasta la tarde | Lanzamiento de revisión y campaña de actualización | Los desarrolladores principales confirman que la causa principal es un error de deserialización de hash heredado presente en versiones recientes específicas de nodos y ausente en las más antiguas. | Una vez comprendida la causa, el riesgo de repetidas transacciones mal formadas se evalúa y se comparte con las OPP, los CEX y los proveedores de infraestructura en canales de coordinación. | Las versiones parcheadas 10.5.2 y 10.5.3 del nodo se lanzan con el error de deserialización solucionado. Las SPO, retransmisiones e intercambios reciben instrucciones de actualizar para que el peso de su participación pase a la cadena saludable; Se prepara un plan de recuperación ante desastres CIP-135 como alternativa si las actualizaciones se retrasan. |
| 21 de noviembre de 2025 – alrededor de las 22:17 | La red vuelve a converger | A medida que los nodos mejorados rechazan la rama envenenada y siguen la cadena sana, la densidad del consenso de Ouroboros se desplaza decisivamente hacia el libro mayor sano. La cadena envenenada continúa sólo en una minoría cada vez menor de nodos no actualizados. | El monitoreo muestra que la producción de bloques y los hash de propinas nuevamente son consistentes en los principales grupos, exploradores e intercambios. Intersect confirma que Cardano “nunca se desconectó”, sólo se desaceleró durante la partición. | Intersect informa que todos los nodos se unieron voluntariamente a la cadena principal alrededor de las 22:17 UTC y que la red convergió nuevamente en una única cadena saludable aproximadamente 14,5 horas después de la transacción con formato incorrecto. Se ha creado un grupo de trabajo de conciliación para manejar cualquier transacción que existiera únicamente en la sucursal envenenada. |
| 22 y 23 de noviembre de 2025 | Mitigación y divulgación posteriores al incidente | El atacante “Homer J” admite públicamente haber elaborado la transacción con formato incorrecto utilizando instrucciones generadas por IA; Se notifica al FBI y otras agencias. Intersect publica el informe completo de “hechos de un vistazo” y la revisión posterior a la acción en curso. | La comunidad y los medios reciben una reconstrucción precisa del evento; Los mitos sobre un “truco de protocolo” o una “interrupción total” se desacreditan explícitamente. | Las correcciones a largo plazo tienen como objetivo ampliar la cobertura de pruebas para el código heredado, ciclos de actualización acelerados, un monitoreo más sólido y un énfasis renovado en la divulgación responsable y las recompensas por errores en lugar de la experimentación con la red principal. |
Póliza de seguro multicliente de Ethereum
Ethereum trata la diversidad de clientes como una propiedad de resiliencia de primer orden. Desde la fusión, Ethereum ha ejecutado capas de ejecución y consenso separadas, cada una respaldada por múltiples implementaciones independientes.
En el lado de la ejecución, Geth, Nethermind, Erigon y otros procesan transacciones y calculan transiciones de estado. En el lado del consenso, Prysm, Lighthouse, Teku, Nimbus y Lodestar se encargan de las tareas de validación y la finalidad.
La arquitectura es deliberada: ninguna base de código debería poder imponer un bloqueo no válido en la red, y los errores en un cliente deberían dar lugar a penalizaciones localizadas en lugar de fallos en toda la cadena.
La estrategia ha sido probada. A principios de 2024, un error que afectó al consenso en Nethermind provocó que los validadores que ejecutaban ese cliente se retrasaran durante el procesamiento de bloques.
Esos validadores sufrieron penalizaciones por no recibir recompensas, pero la cadena canónica de Ethereum persistió en la mayoría de las implementaciones de los clientes y no se produjo ninguna bifurcación.
El incidente validó la tesis central: si un cliente minoritario falla, la red continúa. Si la mayoría de los clientes fallan, hay suficiente redundancia para evitar que finalice una cadena falsa.
La división de Cardano ofrece un caso comparativo no intencionado. El error vivía dentro de una base de código de un solo nodo, pero el sesgo de versión entre las versiones parcheadas y sin parches creó efectivamente dos clientes competidores que no estaban de acuerdo con la validez.
La partición se manifestó como una bifurcación activa en lugar de un rechazo limpio de bloques no válidos, porque ambas versiones tenían suficiente peso en juego para sostener cadenas separadas.
El modelo multicliente de Ethereum intenta hacer que ese tipo de desacuerdo se pueda sobrevivir de forma predeterminada: si Geth malinterpreta una transacción pero Lighthouse, Teku y otros la rechazan, la red debería seguir la mayoría de implementaciones independientes en lugar de un solo binario.
El modelo tiene debilidades. Geth a menudo representa más de la mitad de la capa de ejecución de Ethereum, y Prysm ha tenido una parte incómoda de la capa de consenso en varios puntos.
Los defensores de la diversidad de clientes de Ethereum encuadran explícitamente estas concentraciones como riesgos sistémicos y presionan por una distribución más equitativa precisamente para evitar una división al estilo Cardano a nivel de mayoría de clientes.
Pero el principio permanece: las implementaciones independientes con superficies de errores independientes reducen la probabilidad de que un único error de validación se convierta en un evento que afecte a toda la red.
La compensación de Solana entre detenerse y reiniciarse
Solana ocupa el extremo opuesto del espacio de diseño. La red ejecuta un único validador binario y tiempo de ejecución, y cuando esa implementación falla, el consenso generalmente se detiene por completo en lugar de dividirse.
En septiembre de 2021, el tráfico de bots que inundó el lanzamiento de un token de Grape Protocol hizo que Solana superara las 400.000 transacciones por segundo, agotó la memoria del validador y provocó que las transacciones de votos dejaran de propagarse.
El consenso se rompió y la red permaneció fuera de línea durante aproximadamente 17 horas hasta que los validadores coordinaron un reinicio con un binario parcheado.
En febrero de 2024, un error en el cargador del filtro de paquetes Berkeley, un componente central de la ejecución del programa en cadena, provocó que la finalización del bloque se detuviera durante aproximadamente 5 horas.
Los ingenieros identificaron la ruta de actualización defectuosa, lanzaron un cliente parcheado y reiniciaron el clúster.
El patrón es consistente: Solana prioriza la singularidad de la cadena sobre la vida, aceptando interrupciones completas periódicas como el costo de una arquitectura monocliente de alto rendimiento.
Cuando el cliente falla, la cadena se congela y se reinicia bajo coordinación humana. El incidente de Cardano demuestra la compensación inversa: la vida persistió, pero la divergencia del software creó dos cadenas que siguieron produciendo bloques.
La estrategia multicliente de Ethereum intenta evitar ambos modos de falla asegurando que ningún error pueda detener la red o dividirla en historias competitivas.
Conclusiones para los diseñadores de protocolos
La división de Cardano subraya la necesidad de una agresiva fuzzing e inyección de fallas en torno al código de serialización y deserialización, especialmente para características heredadas o rutas de validación que rara vez se utilizan.
El error se escondió en un deserializador de hash introducido años antes y solo se activaba mediante una clase limitada de transacciones de delegación, exactamente el tipo de falla latente que las pruebas estándar a menudo pasan por alto.
La palanca más fundamental es la realización de pruebas diferenciales entre versiones de clientes e, idealmente, entre implementaciones completamente separadas.
| Cadena | Diversidad de clientes | superficie DoS | Endurecimiento del chisme | Protección de repetición |
|---|---|---|---|---|
| Etereum | ✅ (multicliente tanto en EL/CL, la diversidad es un objetivo explícito) | ⚠️ (MEV, spam de mempool, superficie de ataque blob/DA en crecimiento) | ✅ (subredes de chismes, puntuación, elección de bifurcación reforzada para DOS) | ✅ (post-DAO, estándar de mitigación de reproducción; ID de cadena) |
| solana | ⚠️ (efectivamente, un cliente validador dominante) | ⚠️ (historial de DoS/congestión y errores de tiempo de ejecución) | ⚠️ (QUIC, correcciones localizadas, pero las interrupciones muestran fragilidad residual) | ✅ (sin repetición simple entre cadenas; reinicios coordinados) |
| Cardano | ⚠️ (código base de nodo principal único, múltiples versiones) | ⚠️ (la reciente división mal formada-tx muestra rutas sensibles) | ⚠️ (chismes sólidos pero la versión sesgada + los certificados mal formados aún duelen) | ✅ (sin repetición obvia entre cadenas; particiones resueltas por consenso) |
La investigación de Ethereum ahora trata la diversidad de clientes como algo que se debe medir e incentivar, no solo recomendar, precisamente para garantizar que ningún error pueda redefinir silenciosamente las reglas de validez para toda la cadena.
El uso por parte de Cardano de un plan de recuperación de desastres escrito previamente según CIP-135, combinado con la comunicación pública de incidentes de Intersect, evitó que la partición se convirtiera en una falla de coordinación.
El plan nunca se invocó por completo, pero su existencia creó un punto focal claro para que los operadores de grupos de interés y los intercambios se alinearan en torno a la misma cadena.
Esa disciplina de proceso, guías documentadas, simulacros de incendio en redes de prueba de gobernanza y análisis transparente posterior al incidente son posiblemente la parte más sólida de la respuesta.
Finalmente, el incidente resalta una brecha cultural en torno a la divulgación de errores. El atacante optó por ejecutar un exploit de prueba en la red principal en lugar de enviarlo a través del programa de recompensas por errores de Cardano.
Intersect enfatizó que el mismo comportamiento en testnet podría haber sido recompensado en lugar de criminalizado, un recordatorio de que vías de divulgación claras y bien compensadas siguen siendo la mejor manera de evitar que “probarlo en mainnet y ver qué sucede” se convierta en la postura predeterminada de los investigadores en todas las cadenas de bloques de capa 1.
