En la noche del 22 de septiembre, un usuario envió una transferencia de ATOM.
Después de pasar una noche, la transacción aún permanecía "esperando confirmación".
La clave privada no se perdió y la billetera no mostró anomalías de firma. Al verificar de nuevo al día siguiente, múltiples RPC públicos mostraron que Cosmos Hub se había detenido en la altura de bloque 33.086.740.
Al no producirse nuevos bloques, naturalmente no había ningún lugar que pudiera empaquetar esta transacción.
Solo aproximadamente un día después, tras reanudar Cosmos Hub la producción de bloques, esta transferencia de ATOM, que había estado en estado de espera todo el tiempo, finalmente tuvo éxito.
Para los usuarios comunes, esta puede ser la lección más intuitiva para entender el consenso de blockchain.
Estamos acostumbrados a decir que "ninguna institución central puede apagar una cadena pública", pero la realidad es claramente mucho más compleja. Una blockchain suficientemente descentralizada ciertamente no suele tener ese "botón de apagado" en una sala de servidores, pero aún puede detenerse.
Esta pausa de Cosmos Hub expuso completamente este conjunto de mecanismos, normalmente ocultos en la capa subyacente, a los usuarios comunes.
1. ¿Por qué Cosmos de repente "dejó de producir bloques"?
Primero, es necesario aclarar una cuestión que es fácil de confundir: lo que fue atacado directamente esta vez no fue Cosmos Hub.
El incidente ocurrió primero en Neutron.
El 22 de septiembre, se aprobó una propuesta de gobernanza de Neutron llamada "AIATO: AI Agent Takeover". El atacante explotó una laguna en los permisos de gobernanza a nivel de cadena y utilizó instrucciones privilegiadas proporcionadas de forma nativa por el framework wasmd para cambiar los administradores de contratos de aplicaciones como Astroport y Drop a direcciones controladas por el atacante.
Esto no es lo que solemos entender como una "vulnerabilidad de código" o un "fallo de protocolo".
Se puede entender simplemente como: las aplicaciones mismas tienen sus propios "cerraduras de puerta", pero la gobernanza a nivel de cadena de Neutron también posee una "llave maestra" de mayor privilegio, y cuando el atacante controla el resultado de la gobernanza, equivale a obtener esta llave, lo que le permite reasignar administradores, migrar contratos y transferir aún más los activos en su interior.
Lo que realmente arrastró a Cosmos Hub fue la transferencia de fondos entre cadenas que siguió.
El postmortem de Cosmos Labs muestra que antes de que Neutron dejara de operar, el atacante ya había movido algunos activos a múltiples redes, entre los cuales aproximadamente 1,7 millones de ATOM se transfirieron a Cosmos Hub y comenzaron a intercambiarse a través de liquidez entre cadenas.
En otras palabras, Cosmos Hub mismo no fue atacado directamente, y los fondos de los usuarios comunes de Hub no fueron robados directamente debido a la vulnerabilidad de Neutron.
Pero los ATOM obtenidos del ataque ya habían entrado en el Hub, y para evitar que los ATOM restantes siguieran fluyendo hacia afuera, algunos validadores de Cosmos Hub comenzaron a dejar de ejecutar sus nodos.
Alrededor de las 19:18 del 22 de septiembre (SGT), los validadores que habían dejado de ejecutarse ya representaban más de un tercio del poder de voto total, por lo que Cosmos Hub ya no pudo continuar formando nuevos bloques y finalmente se detuvo en 33.086.740.
Este paso es muy crítico.
Significa que Cosmos Hub no tiene un botón de "Pausa" que alguna empresa pueda pulsar directamente, ni pasó primero por una votación de gobernanza en cadena. Lo que realmente detuvo la red fue que suficientes validadores dejaron de participar en la formación de consenso.
Pero lo que es más digno de mención es en realidad el proceso de recuperación posterior.
Aproximadamente 4 horas después de que la cadena se detuviera, los validadores recibieron un plan de recuperación completo: ejecutar una modificación de estado única en la altura de detención de la cadena, transfiriendo los ATOM restantes en la dirección del atacante a una dirección multifirma gestionada conjuntamente por los validadores de la comunidad.
Cosmos Labs luego produjo el parche Gaia v28.3.0 basado en el plan ya acordado por los validadores, lo probó y lo distribuyó a los validadores.
Esta versión de Gaia ejecutaría un cambio de estado único en la altura de recuperación especificada, transfiriendo 1,227,121 ATOM desde la dirección del atacante a una dirección multifirma 4-de-6 compuesta por seis partes: Nansen, Keplr, Enigma, Silknodes, Kiln y Polkachu.
Para la madrugada del 23 de septiembre, los validadores que se confirmó que habían instalado la v28.3.0 ya superaban el 67% del poder de voto total, por lo que a las 12:00 UTC de ese día, Cosmos Hub coordinó un reinicio. Unos 6 minutos después, esta modificación de estado única se ejecutó en la altura de bloque 33,086,741, y la red reanudó la producción normal de bloques.
En el análisis final, a lo largo de todo el proceso desde que Cosmos detuvo la producción de bloques hasta que reanudó su funcionamiento, los validadores primero hicieron que la red perdiera la Vivacidad, y luego más de dos tercios del poder de voto aceptaron un nuevo conjunto de reglas de transición de estado, haciendo finalmente que este conjunto de reglas fuera el estado canónico después de la recuperación.
En este punto, surge una pregunta aparentemente simple: dado que es una cadena pública descentralizada, ¿por qué más de un tercio del poder de validación puede detenerla, mientras que restaurar la red requiere que suficientes validadores acepten y ejecuten conjuntamente el mismo software?
La respuesta en realidad está oculta en la palabra "consenso".
2. El llamado consenso nunca fue "nunca se detiene"
Una de las cosas más fácilmente malinterpretadas sobre la blockchain es equiparar "descentralización" con "nunca se cae".
De hecho, lo que el mecanismo de consenso realmente resuelve es cómo, sin un contable central, muchos nodos pueden llegar a un acuerdo sobre el orden de las transacciones y el estado del libro mayor.
Sin embargo, las diferentes cadenas públicas no implementan esto de la misma manera.
Por ejemplo, el mecanismo más clásico de Bitcoin es PoW, prueba de trabajo: los mineros compiten por producir bloques utilizando poder de cómputo. Cuando aparecen dos ramas válidas en la red durante un breve período, los nodos eligen una de ellas para continuar construyendo según el trabajo acumulado.
Así que Bitcoin no tiene un momento claro en el que "después de una votación del 67%, este bloque queda Finalizado para siempre". Se aproxima más a una especie de finalidad probabilística: cuantos más bloques posteriores haya, más costo de poder de cómputo se requiere para reorganizar y eliminar transacciones anteriores.
Esta es también la razón por la que solía decirse que es mejor esperar 6 confirmaciones de bloque para una transacción de Bitcoin. Después de todo, incluso con mayor poder de cómputo, uno no puede simplemente eludir las reglas de consenso que los nodos están ejecutando.
Por supuesto, esto no significa que el estado de Bitcoin sea "absolutamente imposible de modificar" bajo ninguna circunstancia. Teóricamente, si todo el ecosistema acepta un nuevo cliente y nuevas reglas de consenso, mediante una Hard Fork, también es posible hacer que cambios de estado que eran inválidos bajo las reglas antiguas se vuelvan válidos.
Pero aquí está el problema: ¿quién tiene la capacidad de hacer que suficientes mineros, Nodos Completos, plataformas de trading, billeteras y usuarios acepten conjuntamente un nuevo conjunto de reglas así?
Casi nadie.
El equipo de desarrollo no puede decidir por sí solo las reglas de consenso para toda la red Bitcoin, y también es difícil para los mineros y las plataformas de trading, porque el umbral de consenso que debe cruzarse es muy alto. Cuando Binance fue hackeado por 7,000 BTC, algunas personas sugirieron que CZ contactara a grandes mineros para operar, pero al final no resultó nada.
Ethereum proporciona otro ejemplo muy clásico.
Después de cambiar a PoS, Ethereum ahora utiliza el consenso Gasper compuesto por Casper FFG y LMD-GHOST juntos. En pocas palabras, una parte del mecanismo se encarga de determinar "qué cadena debe seguirse actualmente", mientras que la otra parte se encarga de dar a los bloques una Finalidad verdadera.
Solo cuando los validadores que representan al menos dos tercios del ETH en staking están de acuerdo en el checkpoint correspondiente, un bloque puede avanzar más hacia la finalización; a la inversa, si más de un tercio del stake no participa en la votación correcta durante mucho tiempo, la red puede temporalmente ser incapaz de formar Finalidad. Sin embargo, Ethereum también diseñó una fuga de inactividad, que reduce gradualmente el peso efectivo de los validadores fuera de línea cuando no se puede lograr la finalización durante mucho tiempo, dando a la red la oportunidad de eventualmente restaurar la Finalidad.
Para cambiar verdaderamente este resultado, también es necesario cambiar las reglas del protocolo y los clientes.
Al igual que en el incidente de The DAO en 2016, la comunidad de Ethereum finalmente llevó a cabo una bifurcación dura, ejecutando en el bloque 1,920,000 una modificación especial del estado que la Fundación Ethereum en ese momento llamó directamente un cambio de estado irregular, transfiriendo los ETH relevantes a un contrato de recuperación.
Sin embargo, algunos mineros y miembros de la comunidad que se negaron a actualizar y continuaron manteniendo el estado original eventualmente formaron Ethereum Classic (ETC), lo que llevó a la conocida bifurcación de ETH y ETC, mostrando que no todos aceptaron este conjunto de reglas.
Cosmos Hub es diferente de nuevo. Utiliza CometBFT, que se acerca más al consenso BFT típico.
Se puede entender como un consenso BFT más típico, lo que significa que para que un bloque sea realmente confirmado, necesita obtener un Commit de más de dos tercios del poder de voto.
Su ventaja es que la Finalidad es muy clara. Una vez que un bloque ha sido confirmado después de la votación por suficiente poder de verificación, no hay necesidad de seguir esperando más y más bloques como con PoW, intercambiando probabilidad por una sensación de seguridad.
Pero su otro lado también es muy directo: si un tercio o más del poder de voto ya no proporciona los votos necesarios para formar un Commit, entonces no importa cuánto se esfuercen los validadores restantes, no pueden reunir más de dos tercios.
En este punto, la opción más segura para la red es exactamente la "pausa en la producción de bloques" vista esta vez, por lo que desde la perspectiva de los sistemas distribuidos, esta breve detención de Cosmos Hub en realidad no es misteriosa.
En una palabra, después de que un grupo de validadores que poseen suficiente poder de voto deja de participar, el protocolo de consenso, según sus propias reglas, prefiere perder disponibilidad antes que continuar confirmando nuevos bloques sin suficiente consenso.
Detrás de esto, en realidad corresponden dos conceptos en los sistemas distribuidos que a menudo son confundidos por los usuarios comunes:
- Seguridad: diferentes nodos no deben confirmar simultáneamente dos estados finales en conflicto;
- Vitalidad: si la red aún puede continuar funcionando hacia adelante y procesar nuevas transacciones;
Para los sistemas BFT, cuando hay nodos insuficientes participando en el consenso, pausar es a veces precisamente el precio que se paga para mantener la Seguridad. Para decirlo sin rodeos, este libro contable descentralizado prefiere detenerse allí primero antes que dejar que los restantes mantengan cada uno sus propios registros.
Mirando hacia atrás desde este ángulo, uno encontrará que muchos incidentes aparentemente completamente diferentes en la historia de las blockchains públicas en realidad giran en torno a lo mismo:
Cuando los nodos distribuidos ya no pueden formar un consenso sobre el "estado correcto", ¿qué debe hacer la red?
III. De Bitcoin a Solana, ¿dónde está el verdadero límite de riesgo de las blockchains públicas?
Esta no es la primera vez que Cosmos pone esta pregunta sobre la mesa.
Ya en 2013, Bitcoin experimentó un incidente de bifurcación de cadena muy clásico.
En ese momento, Bitcoin 0.8 cambió su base de datos subyacente de Berkeley DB a LevelDB. Posteriormente, apareció un bloque que contenía una gran cantidad de entradas de transacción. Los nodos de la nueva versión podían procesarlo normalmente, pero algunos nodos de la versión antigua, debido al límite de recuento de bloqueos de Berkeley DB, juzgaron este bloque como inválido.
Así apareció una escena muy incómoda: todos ejecutaban Bitcoin, pero los clientes antiguos y nuevos comenzaron a dar respuestas diferentes a "si este bloque es legal o no".
La red, por lo tanto, se dividió en dos cadenas, y el lado de la nueva versión 0.8 una vez tuvo alrededor del 60% de la tasa de hash, y no podía depender de la competencia normal de tasa de hash para converger rápidamente por sí solo.
Al final, los grandes pools de minería se coordinaron para volver a cambiar a la versión antigua, recuperaron más tasa de hash en el lado de las reglas antiguas, y solo entonces la red convergió nuevamente. Bitcoin luego revisó específicamente este incidente con BIP 50.
Para 2016, el incidente de The DAO de Ethereum llevó el problema un paso más allá.
Como se mencionó anteriormente en relación con el incidente de The DAO, la comunidad de Ethereum finalmente llevó a cabo una bifurcación dura (Hard Fork), ejecutando en el bloque 1.920.000 una modificación especial del estado explícitamente denominada por la Fundación Ethereum como un cambio irregular de estado, transfiriendo los ETH relevantes a un contrato de recuperación.
Pero no todos estuvieron de acuerdo con este manejo. Algunos mineros y miembros de la comunidad que se negaron a aceptar la modificación del estado continuaron manteniendo las reglas originales, lo que dio lugar al Ethereum Classic (ETC), que existe desde hace mucho tiempo.
Esta bifurcación de DAO también fue un evento clásico, equivalente a decirle a todos que cuando ocurren eventos extremos, además del consenso de código también existe el consenso social. Si no se pueden formar opiniones suficientemente consistentes, una cadena realmente puede dividirse en dos.
Solana en 2021 demostró otra ruta de fallo completamente diferente.
En septiembre de ese año, una gran cantidad de transacciones de bots inundaron la red, provocando que los nodos validadores se quedaran sin memoria y que muchos nodos se cayeran. Finalmente, toda la red no pudo formar un consenso sobre el estado actual y dejó de confirmar nuevos bloques durante aproximadamente 17 horas, tras lo cual los validadores se coordinaron conjuntamente para restaurar la red.
Si se juntan estos incidentes, uno descubrirá que no son lo mismo:
- El problema de Bitcoin en 2013 fue que diferentes clientes comenzaron a aplicar diferentes reglas de validez;
- El problema de Solana en 2021 fue que una gran cantidad de nodos validadores ya no podían seguir participando normalmente en el consenso, y la red perdió la Vivacidad (Liveness);
- Lo que enfrentó Ethereum DAO se acercaba más a la cuestión de si una comunidad debería modificar activamente el estado mediante nuevas reglas de protocolo;
- Y esta vez Cosmos Hub tiene otra capa de particularidad: la red primero perdió activamente la Vivacidad mediante la coordinación de los validadores para evitar que los activos atacados siguieran moviéndose; después, una proporción suficientemente alta de poder de voto aceptó conjuntamente el nuevo software y el estado de recuperación, permitiendo que la red volviera a formar consenso;
Así que, en lugar de reducir simplemente estos eventos a "así que las blockchains en realidad pueden apagarse" o "la descentralización es toda falsa", es mejor admitir un hecho más real:
El mecanismo de consenso nunca ha sido una máquina que no pueda romperse. Lo que realmente proporciona es, en realidad, un conjunto de reglas descentralizadas, como quién decide la cadena correcta cuando surgen desacuerdos; cuántos participantes se necesitan para que un estado obtenga finalidad; si la red elige seguir funcionando o detenerse cuando ocurren fallos; y, en circunstancias extremas, qué tipo de acción colectiva puede cambiar las reglas de funcionamiento en adelante.
Esto también deja a este incidente de Cosmos con una pregunta más digna de reflexión para los usuarios comunes que "si la cadena debería detenerse".
Reflexiones finales
A menudo decimos: not your keys, not your coins.
Esta afirmación, por supuesto, sigue siendo cierta, solo que enfatiza el control de los activos: siempre que la clave privada esté en tus propias manos, las billeteras, las plataformas de trading u otros terceros no pueden firmar una transferencia en tu nombre.
La premisa es que la blockchain en la que estás debe ser capaz de procesar esa firma en cualquier momento.
El día en que Cosmos Hub dejó de producir bloques, los usuarios todavía conservaban sus propias claves privadas, y los activos no desaparecieron en el aire por ello, solo que incluso si firmabas correctamente una transacción, no había un nuevo bloque que la aceptara.
El proceso de recuperación ilustra además que, si suficientes participantes del consenso aceptan un nuevo conjunto de reglas de estado, el estado en cadena de cuentas específicas también puede cambiar sin ser firmado por la clave privada de la dirección original.
Esto no invalida "Not your keys, not your coins", pero nos recuerda que la soberanía de la clave privada y el poder de consenso subyacente nunca han sido lo mismo.
Y para las carteras, lo mismo es cierto.
Las carteras pueden garantizar que las claves privadas y los derechos de firma estén en manos de los propios usuarios, pueden identificar anomalías a nivel de cadena lo más rápido posible, mostrar con precisión el estado de las transacciones, establecer redundancia de RPC y nodos, y reconfirmar el resultado final de las transacciones después de que la red se recupere.
Pero las carteras no pueden restaurar el consenso de una cadena pública, ni pueden garantizar que la red subyacente nunca se interrumpa, y mucho menos garantizar que las reglas y el estado en la cadena nunca sufran cambios a nivel de consenso.
Por lo tanto, lo que un sistema descentralizado maduro realmente necesita perseguir quizás nunca haya sido "nada puede cambiarse jamás"; por el contrario, debería aclarar estos límites imperfectos tanto como sea posible: ¿Quién puede pausar el consenso? ¿Cuánto peso se necesita? ¿En qué circunstancias se permite la intervención de emergencia?
Porque la verdadera descentralización no puede hacer que el sistema nunca se encuentre con accidentes; la clave es que incluso si realmente ocurre un accidente, aún podamos saber quién, con base en qué reglas y con cuánto consenso, decidió cómo debería registrarse este libro mayor a continuación.
