La tarde del 22 de septiembre, un usuario envió una transferencia ATOM.
Pasó una noche y la transacción todavía estaba "esperando confirmación".
La clave privada no se perdió y no hubo excepción de firma en la billetera. Al volver a comprobar al día siguiente, varios RPC públicos mostraron que Cosmos Hub se detuvo en la altura del bloque 33.086.740.
Si no se genera ningún bloque nuevo, naturalmente no habrá lugar para empaquetar esta transacción.
No fue hasta que Cosmos Hub reanudó la producción de bloques aproximadamente un día después que la transferencia ATOM que había estado esperando finalmente fue exitosa.
Para los usuarios comunes, esta puede ser la lección más intuitiva para comprender el consenso de blockchain.
Estamos acostumbrados a decir que "ninguna organización central puede cerrar una cadena pública", pero la realidad es obviamente mucho más complicada. Una cadena de bloques suficientemente descentralizada no suele tener el "botón de apagado" en la sala de servidores, pero aun así puede detenerse.
La suspensión de Cosmos Hub esta vez ha dejado al descubierto por completo este mecanismo que suele estar oculto en la parte inferior para los usuarios comunes.
1. ¿Por qué Cosmos de repente “dejó de producir bloques”?
En primer lugar, debemos aclarar una cuestión que fácilmente confunde. No fue el Cosmos Hub el que fue atacado directamente esta vez.
El incidente ocurrió por primera vez en Neutron.
El 22 de septiembre, se aprobó una propuesta de gobernanza de Neutron llamada "AIATO: AI Agent Takeover". El atacante aprovechó las lagunas en los permisos de gobernanza a nivel de cadena y utilizó las instrucciones privilegiadas proporcionadas de forma nativa por el marco wasmd para cambiar los administradores de contrato de aplicaciones como Astroport y Drop a direcciones controladas por el atacante.
Este no es el tipo de "vulnerabilidad de código" o "fallo de protocolo" que normalmente entendemos.
Se puede entender simplemente que la aplicación en sí tiene su propia "cerradura de puerta", pero la gobernanza a nivel de cadena de Neutron también tiene una "llave maestra" con mayor autoridad. Cuando el atacante controla los resultados de la gobernanza, equivale a obtener esta clave y puede volver a designar al administrador, migrar el contrato y transferir aún más los activos.
Lo que realmente involucró a Cosmos Hub fue la posterior transferencia de fondos entre cadenas.
La revisión de Cosmos Labs muestra que antes de que Neutron dejara de ejecutarse, el atacante había transferido algunos activos a múltiples redes. Se transfirieron alrededor de 1,7 millones de ATOM a Cosmos Hub y comenzaron a intercambiarse mediante liquidez entre cadenas.
En otras palabras, el Cosmos Hub en sí no fue atacado directamente y los fondos de los usuarios comunes del Hub no fueron robados directamente debido a la vulnerabilidad de Neutron.
Sin embargo, el ATOM obtenido del ataque ya ingresó al Hub. Para evitar que el ATOM restante fluya, algunos validadores de Cosmos Hub comenzaron a detener la operación del nodo.
Alrededor de las 19:18 del 22 de septiembre (SGT), los validadores detenidos habían representado más de un tercio del poder de voto total y, por lo tanto, Cosmos Hub no pudo continuar formando nuevos bloques, deteniéndose finalmente en 33.086.740.
Este paso es muy crítico.
Significa que no hay un botón de "Pausa" en el que una empresa pueda hacer clic directamente en Cosmos Hub, ni pasa primero por una votación de gobernanza en cadena. Lo que realmente detiene la red es cuando suficientes validadores ya no participan en la formación de un consenso.
Pero lo que es más digno de mención es el proceso de recuperación posterior.
Aproximadamente 4 horas después de que se suspendiera la cadena, el verificador recibió un plan de recuperación completo: realizar una modificación de estado única para la altura de la suspensión de la cadena y transferir el ATOM restante en la dirección del atacante a una dirección de firmas múltiples administrada conjuntamente por validadores de la comunidad.
Luego, Cosmos Labs produjo el parche Gaia v28.3.0 basado en la solución que habían alcanzado los verificadores, lo probó y lo distribuyó a los verificadores.
Esta versión de Gaia realizará un cambio de estado único en la altura de recuperación especificada, transfiriendo 1.227.121 ATOM en la dirección del atacante a una dirección de firma múltiple 4 de 6 compuesta por Nansen, Keplr, Enigma, Silknodes, Kiln y Polkachu.
En la madrugada del 23 de septiembre, el número de validadores confirmados que habían instalado la versión 28.3.0 había superado el 67% del poder de voto total. Por lo tanto, a las 12:00 UTC de ese día, Cosmos Hub coordinó un reinicio. Aproximadamente 6 minutos después, esta modificación de estado única se ejecutó a la altura del bloque 33.086.741 y la red volvió a la producción normal de bloques.
En última instancia, durante todo el proceso desde que Cosmos dejó de producir bloques hasta que reanudó su operación, fueron los validadores quienes primero hicieron que la red perdiera Liveness, y luego más de dos tercios del poder de voto aceptaron un nuevo conjunto de reglas de transición estatal, lo que finalmente convirtió a este conjunto de reglas en el estado canónico restaurado.
En este punto, surge una pregunta aparentemente simple: dado que es una cadena pública descentralizada, ¿por qué más de un tercio de los derechos de verificación pueden detenerla y, para restaurar la red, es necesario que suficientes validadores acepten y ejecuten el mismo conjunto de software?
En realidad, la respuesta está en la palabra "consenso".
2. El llamado consenso no “nunca se detendrá”.
Una de las cosas más incomprendidas sobre blockchain es que la "descentralización" se equipara con "nunca tiempo de inactividad".
De hecho, el problema que realmente resuelve el mecanismo de consenso es cuántos nodos pueden llegar a un acuerdo sobre la secuencia de las transacciones y el estado del libro mayor en ausencia de un contable central.
Sin embargo, diferentes cadenas públicas implementan esto de diferentes maneras.
El ejemplo más clásico de Bitcoin es PoW, que es una prueba de trabajo: los mineros compiten para producir bloques basados en la potencia informática. Cuando aparecen dos ramas legales en la red en un corto período de tiempo, el nodo elige una de ellas para continuar construyendo según la carga de trabajo acumulada.
Por lo tanto, Bitcoin no tiene un momento claro de que "este bloque quedará finalizado para siempre después de la votación del 67%". Está más cerca de una finalidad probabilística. Cuantos más bloques subsiguientes haya, mayor y mayor será el costo de la potencia informática que se requerirá para reorganizar las transacciones anteriores.
Es por eso que todo el mundo solía decir que es mejor para una transacción de Bitcoin esperar 6 bloques para su confirmación. Después de todo, no importa cuán alta sea la potencia de cálculo, no puede simplemente eludir las reglas de consenso que ejecutan los nodos.
Por supuesto, esto no significa que el estado de Bitcoin sea "absolutamente inmodificable" bajo ninguna circunstancia. En teoría, si todo el ecosistema acepta un nuevo conjunto de clientes y nuevas reglas de consenso, a través de Hard Fork, los cambios de estado que no eran válidos según las reglas anteriores también pueden volverse válidos.
Pero aquí está la pregunta: ¿quién tiene la capacidad de conseguir suficientes mineros, nodos completos, plataformas comerciales, billeteras y usuarios para aceptar un conjunto de reglas tan nuevo?
Difícilmente.
El equipo de desarrollo no puede decidir las reglas de consenso para toda la red Bitcoin. También es difícil para los mineros y las plataformas comerciales porque el umbral de consenso que deben cruzar es muy alto. Cuando se robaron 7.000 BTC de Binance, algunas personas sugirieron que CZ contactara a grandes mineros para operar, pero al final no pasó nada.
Ethereum proporciona otro ejemplo clásico.
Después de cambiar a PoS, Ethereum ahora utiliza el consenso de Gasper compuesto por Casper FFG y LMD-GHOST. Para entenderlo simplemente, una parte del mecanismo es responsable de determinar "qué cadena se debe seguir actualmente", mientras que la otra parte es responsable de hacer que el bloque alcance la finalidad en el verdadero sentido.
Cuando los validadores que representan al menos dos tercios del ETH apostado llegan a un acuerdo sobre el punto de control correspondiente, el bloque puede avanzar hacia la finalización; por el contrario, si más de un tercio de las apuestas no participan en la votación correcta durante un largo tiempo, es posible que la red no pueda temporalmente formar una finalidad. Sin embargo, Ethereum también ha diseñado una fuga de inactividad para reducir gradualmente el peso efectivo de los validadores fuera de línea cuando la finalización no se puede finalizar durante mucho tiempo, dando a la red la oportunidad de restaurar finalmente la finalidad.
Para cambiar realmente este resultado, también es necesario cambiar las reglas del protocolo y el cliente.
Al igual que el incidente de DAO en 2016, la comunidad Ethereum finalmente implementó una modificación de estado especial llamada cambio de estado irregular por parte de la Fundación Ethereum en el bloque 1.920.000 a través de Hard Fork, y transfirió el ETH correspondiente al contrato de recuperación.
Sin embargo, algunos mineros y comunidades 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, lo que indica que no todos aceptan este conjunto de reglas.
Cosmos Hub vuelve a ser diferente. Utiliza CometBFT, que se acerca más a un consenso típico de BFT.
Puede entenderse como un consenso BFT más típico, es decir, para que un bloque sea realmente presentado, necesita obtener un Compromiso de más de dos tercios del poder de voto.
Su ventaja es que la finalidad es muy clara. Una vez que un bloque se envía mediante votación con suficientes derechos de verificación, no hay necesidad de seguir esperando más y más bloques como PoW, intercambiando probabilidad por una sensación de seguridad.
Pero el otro lado de la cuestión también es muy sencillo, es decir, si un tercio o más del poder de voto ya no proporciona los votos necesarios para formar un Compromiso, los validadores restantes no podrán obtener más de dos tercios por mucho que trabajen.
La opción más segura para la red en este momento es "pausar la producción de bloques", por lo que desde la perspectiva de un sistema distribuido, esta breve suspensión de Cosmos Hub en realidad no es misteriosa.
En una palabra, después de que un grupo de validadores con suficiente poder de voto deja de participar, el protocolo de consenso, según sus propias reglas, preferiría perder disponibilidad que continuar confirmando nuevos bloques sin suficiente consenso.
Detrás de esto, en realidad, hay dos conceptos en los sistemas distribuidos que los usuarios comunes a menudo confunden:
Seguridad: diferentes nodos no pueden confirmar dos estados finales en conflicto al mismo tiempo;
Vivencia: ¿Puede la red seguir avanzando y procesar nuevas transacciones?
Para el sistema BFT, cuando no hay suficientes nodos que participen en el consenso, la suspensión es a veces el precio que se paga por mantener la seguridad. Para decirlo sin rodeos, este libro de contabilidad descentralizado preferiría detenerse ahí antes que dejar que las personas restantes lleven sus propias cuentas.
Mirando hacia atrás desde esta perspectiva, encontrará que muchos accidentes aparentemente completamente diferentes en la historia de las cadenas públicas en realidad giran en torno a lo mismo:
¿Qué hace la red cuando los nodos distribuidos ya no pueden ponerse de acuerdo sobre el "estado correcto"?
3. De Bitcoin a Solana, ¿dónde está el verdadero límite de riesgo de las cadenas públicas?
Esta no es la primera vez que Cosmos pone este tema sobre la mesa.
Ya en 2013, Bitcoin tuvo un accidente de bifurcación de cadena muy clásico.
En ese momento, Bitcoin 0.8 cambió la base de datos subyacente de Berkeley DB a LevelDB, y luego apareció un bloque que contenía una gran cantidad de entradas de transacciones. La nueva versión del nodo podía procesarlo normalmente, pero algunos nodos de la versión anterior consideraron que el bloque no era válido debido al límite en la cantidad de bloqueos de Berkeley DB.
Entonces apareció una escena muy vergonzosa. Todo el mundo ejecutaba Bitcoin, pero los clientes nuevos y antiguos comenzaron a tener respuestas diferentes sobre "si este bloque es legal".
Como resultado, la red se dividió en dos cadenas, y la nueva versión 0.8 alguna vez tuvo alrededor del 60% de la potencia informática y no podía depender de la competencia normal en potencia informática para converger rápidamente por sí sola.
Al final, los grandes grupos de minería se coordinaron para volver a la versión anterior, recuperando más potencia informática del lado de las reglas antiguas, y la red convergió nuevamente. Posteriormente, Bitcoin revisó específicamente el accidente con BIP 50.
En 2016, el incidente de DAO en Ethereum llevó el problema un paso más allá.
Como se mencionó anteriormente en el incidente de DAO, la comunidad Ethereum finalmente implementó una modificación de estado especial llamada explícitamente cambio de estado irregular por parte de la Fundación Ethereum a través de Hard Fork en el bloque 1,920,000, transfiriendo el ETH relevante al contrato de recuperación.
Pero no todos estuvieron de acuerdo con esta decisión. Algunos mineros y comunidades que se negaron a aceptar la modificación de estado continuaron manteniendo las reglas originales, y más tarde surgió el antiguo Ethereum Classic (ETC).
Este DAO Fork también es un evento clásico, lo que equivale a decirles a todos que cuando ocurren eventos extremos, además del consenso de código, también existe un consenso social. Si no se puede formar una opinión suficientemente coherente, una cadena realmente puede dividirse en dos.
La Solana 2021 muestra un camino de fracaso completamente diferente.
En septiembre de ese año, una gran cantidad de transacciones de robots ingresaron a la red, lo que provocó que la memoria del nodo de verificación se agotara y una gran cantidad de nodos fallaran. Al final, toda la red no pudo llegar a un consenso sobre el estado actual y dejó de confirmar nuevos bloques durante aproximadamente 17 horas. Luego, los validadores trabajaron juntos para restaurar la red.
Al juntar estos accidentes, descubrirá que no son lo mismo:
El problema con Bitcoin en 2013 es que diferentes clientes comienzan a implementar diferentes reglas de validez;
El problema de Solana en 2021 es que una gran cantidad de nodos de verificación no pueden continuar participando normalmente en el consenso y la red pierde Liveness;
Lo que enfrenta Ethereum DAO se acerca más a la cuestión de si una comunidad debería modificar activamente el estado a través de nuevas reglas de protocolo;
Esta vez, Cosmos Hub tiene otra capa de especialidad. Primero, la red pierde activamente Liveness a través de la coordinación del validador para evitar que los activos del ataque sigan moviéndose; luego, una proporción suficientemente alta de derechos de verificación acepta conjuntamente nuevo software y restaura el estado, haciendo que la red vuelva a ser consistente;
Por lo tanto, en lugar de simplemente atribuir estos incidentes a que "las cadenas de bloques pueden cerrarse" y "la descentralización es falsa", es mejor admitir un hecho más real:
El mecanismo del consenso nunca es una máquina indestructible. Lo que realmente proporciona es un conjunto de reglas descentralizadas, como quién decidirá la cadena correcta cuando ocurra un desacuerdo; cuántos participantes pueden llegar a una final estatal; cuando ocurre una falla, la red elige continuar funcionando o detenerse; y en casos extremos, qué tipo de acción colectiva puede cambiar las próximas reglas de funcionamiento.
Esto también hace que este incidente de Cosmos deje una pregunta que es más digna de consideración por parte de los usuarios comunes que "¿debería detenerse la cadena?"
escribe al final
A menudo decimos, ni tus llaves, ni tus monedas.
Por supuesto, esta frase sigue siendo cierta, pero enfatiza el control de activos: mientras la clave privada esté en sus propias manos, las billeteras, plataformas comerciales u otros terceros normalmente no pueden firmar una transferencia por usted.
La premisa es que la cadena de bloques en la que se encuentra debe poder procesar esta firma en cualquier momento.
El día que Cosmos Hub deje de producir bloques, los usuarios seguirán conservando sus claves privadas y los activos no desaparecerán de la nada. Sin embargo, incluso si firmas una transacción correctamente, no hay ningún nuevo bloque para aceptarla.
El proceso de recuperación explica además que si suficientes participantes del consenso aceptan un nuevo conjunto de reglas de estado, el estado en cadena de una cuenta específica también puede cambiar sin la firma de la clave privada de la dirección original.
Esto no invalida "Ni tus claves, ni tus monedas", pero nos recuerda que la autonomía de la clave privada y los derechos de consenso subyacentes nunca son lo mismo.
Lo mismo ocurre con las carteras.
La billetera puede garantizar que la clave privada y los derechos de firma estén en manos del usuario, identificar anomalías a nivel de cadena lo más rápido posible, mostrar con precisión el estado de la transacción, establecer RPC y redundancia de nodos y reconfirmar el resultado final de la transacción después de que se restablezca la red.
Sin embargo, la billetera no puede restaurar el consenso para una cadena pública, ni puede garantizar que la red subyacente nunca será interrumpida, ni puede garantizar que las reglas y el estado de la cadena nunca cambiarán a nivel de consenso.
Por lo tanto, lo que realmente necesita un sistema descentralizado maduro puede que nunca sea "nada se puede cambiar"; por el contrario, estos límites imperfectos deben quedar lo más claros posible: ¿quién puede suspender el consenso? ¿Cuánto peso se necesita? ¿En qué circunstancias se permite la intervención de emergencia?
Debido a una verdadera descentralización, es imposible que el sistema nunca sufra accidentes. La clave es que incluso si ocurre un accidente, aún podemos saber quién, según qué reglas y con qué nivel de consenso determina cómo se debe registrar esta cuenta a continuación.