¿Por qué se detiene una cadena pública? Entender verdaderamente el consenso en blockchain a partir de la pausa de 25 horas de Cosmos

Autor: imToken

La noche del 22 de septiembre, un usuario realizó una transferencia de ATOM.

Pasó la noche y la transacción seguía en "esperando confirmación".

No se perdió la clave privada, ni hubo anomalías en la firma de la billetera. Al día siguiente, al revisar nuevamente, múltiples RPC públicos mostraban que Cosmos Hub se había detenido en la altura de bloque 33,086,740.

No se generaron nuevos bloques, por lo que no había ningún lugar donde empaquetar esta transacción.

Hasta aproximadamente un día después, cuando Cosmos Hub reanudó la producción de bloques, la transferencia de ATOM que había estado en espera finalmente tuvo éxito.

Para los usuarios comunes, esto podría ser la lección más intuitiva sobre el consenso en blockchain.

Estamos acostumbrados a decir que "no hay ninguna entidad central que pueda apagar una cadena pública", pero la realidad es evidentemente mucho más compleja. Una cadena de bloques suficientemente descentralizada, de hecho, generalmente no tiene ese "botón de apagado" en un centro de datos, pero aún así puede detenerse.

Esta pausa de Cosmos Hub expuso completamente este mecanismo que normalmente está oculto en el fondo a los usuarios comunes.

I. ¿Por qué Cosmos se detuvo repentinamente en la producción de bloques?

Primero, es necesario aclarar un problema que puede ser confuso: lo que fue atacado directamente no fue Cosmos Hub.

El evento ocurrió inicialmente en Neutron.

El 22 de septiembre, una propuesta de gobernanza de Neutron llamada "AIATO: AI Agent Takeover" fue aprobada. El atacante aprovechó una laguna en los permisos de gobernanza a nivel de cadena, utilizando comandos privilegiados proporcionados por el marco wasmd para cambiar los administradores de contratos de aplicaciones como Astroport y Drop a direcciones controladas por el atacante.

Esto no es lo que normalmente entendemos como un "vulnerabilidad de código" o "defecto del protocolo".

Se puede entender simplemente como que la aplicación tiene su propia "cerradura", pero la gobernanza a nivel de cadena de Neutron tiene una "llave maestra" con permisos más altos, y cuando el atacante controla el resultado de la gobernanza, también obtiene esta llave, lo que le permite reasignar administradores, migrar contratos y transferir activos.

Lo que realmente involucró a Cosmos Hub fue la posterior transferencia de fondos entre cadenas.

Un análisis de Cosmos Labs mostró que, antes de que Neutron dejara de funcionar, el atacante ya había transferido parte de los activos a varias redes, de los cuales aproximadamente 1.7 millones de ATOM fueron transferidos a Cosmos Hub y comenzaron a ser intercambiados a través de liquidez entre cadenas.

Es decir, Cosmos Hub en sí 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 por el atacante ya habían ingresado al Hub, y para evitar que el resto de los ATOM siguieran saliendo, algunos validadores de Cosmos Hub comenzaron a detener la operación de nodos.

Para alrededor de las 19:18 (SGT) del 22 de septiembre, los validadores que habían detenido su operación representaban más de un tercio del poder de votación total, por lo que Cosmos Hub no pudo seguir formando nuevos bloques y se detuvo en 33,086,740.

Este paso es muy crítico.

Significa que no existe un "botón de pausa" que una empresa pueda hacer clic directamente en Cosmos Hub, ni se realizó una votación de gobernanza en la cadena antes de esto. Lo que realmente detuvo la red fue que suficientes validadores dejaron de participar en el consenso.

Pero lo que es aún más notable es el proceso de recuperación posterior.

Aproximadamente 4 horas después de la detención de la cadena, los validadores recibieron un plan de recuperación completo: ejecutar un cambio de estado único en la altura de la cadena de detención, transfiriendo los ATOM restantes de la dirección del atacante a una dirección multisig gestionada conjuntamente por los validadores de la comunidad.

Luego, Cosmos Labs creó un parche Gaia v28.3.0 basado en el plan 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 designada, transfiriendo 1,227,121 ATOM de la dirección del atacante a una dirección multisig de 4 de 6 compuesta por Nansen, Keplr, Enigma, Silknodes, Kiln y Polkachu.

Para la madrugada del 23 de septiembre, los validadores que confirmaron la instalación de v28.3.0 ya superaban el 67% del poder de votación total, por lo que ese día a las 12:00 UTC, Cosmos Hub coordinó un reinicio, y aproximadamente 6 minutos después, este cambio de estado único se ejecutó en la altura de bloque 33,086,741, y la red volvió a la producción normal de bloques.

En resumen, durante todo el proceso desde que Cosmos dejó de producir bloques hasta que se reanudó, los validadores primero hicieron que la red perdiera Liveness, y luego más de dos tercios del poder de votación aceptaron un nuevo conjunto de reglas de cambio de estado, lo que finalmente permitió que este conjunto de reglas se convirtiera en el estado canónico posterior a la recuperación.

Aquí surge una pregunta que parece 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 para restaurar la red se necesita que suficientes validadores acepten y ejecuten el mismo software?

La respuesta, en realidad, está escondida en la palabra "consenso".

II. El consenso no significa "nunca se detiene"

Una de las cosas más fáciles de malinterpretar sobre blockchain es igualar "descentralización" con "nunca caer".

En realidad, el mecanismo de consenso resuelve verdaderamente el problema de cómo muchos nodos pueden llegar a un acuerdo sobre el orden de las transacciones y el estado del libro mayor sin un contable central.

Sin embargo, los métodos para lograr esto varían entre diferentes cadenas públicas.

Por ejemplo, Bitcoin utiliza el PoW más clásico, que es la prueba de trabajo: los mineros compiten por la producción de bloques basándose en su poder de cálculo. Cuando la red presenta brevemente dos ramas legales, los nodos eligen una de ellas para continuar construyendo según la cantidad de trabajo acumulado.

Por lo tanto, Bitcoin no tiene un momento claro de "67% de votos y este bloque está siempre finalizado"; se acerca más a una finalización probabilística, cuantos más bloques se añaden después, mayor es el costo de cálculo necesario para reorganizar las transacciones anteriores.

Por eso, se ha dicho que es mejor esperar 6 bloques para confirmar una transacción de Bitcoin, ya que incluso con un poder de cálculo alto, no se 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 inmodificable" en ninguna circunstancia. Teóricamente, si todo el ecosistema acepta un nuevo cliente y nuevas reglas de consenso, a través de un Hard Fork, también se pueden convertir en válidos los cambios de estado que eran inválidos bajo las reglas anteriores.

Pero el problema es: ¿quién tiene la capacidad de hacer que suficientes mineros, nodos completos, plataformas de intercambio, billeteras y usuarios acepten este nuevo conjunto de reglas?

Casi nadie.

El equipo de desarrollo no puede decidir las reglas de consenso para toda la red de Bitcoin, y los mineros y plataformas de intercambio también tienen dificultades, porque el umbral de consenso que necesitan cruzar es muy alto. Cuando Binance fue robado de 7000 BTC, hubo quienes sugirieron que CZ contactara a grandes mineros para operar, pero al final no se concretó.

Ethereum ofrece otro ejemplo clásico.

Después de pasar a PoS, Ethereum ahora utiliza Gasper, que combina Casper FFG y LMD-GHOST. En términos simples, una parte del mecanismo se encarga de determinar "qué cadena debería seguirse actualmente", mientras que la otra parte se encarga de permitir que los bloques obtengan una verdadera finalización.

Cuando los validadores que representan al menos dos tercios de ETH apostado alcanzan un consenso sobre el checkpoint correspondiente, el bloque puede avanzar hacia la finalización; por el contrario, si más de un tercio de la participación no vota correctamente durante un largo período, la red puede no formar finalización temporalmente. 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 finalizar durante un largo tiempo, permitiendo que la red tenga la oportunidad de restaurar finalmente la finalización.

Para cambiar realmente este resultado, también se necesita cambiar las reglas del protocolo y el cliente.

Como ocurrió en el evento The DAO en 2016, la comunidad de Ethereum finalmente realizó un Hard Fork, ejecutando un cambio de estado especial que Ethereum Foundation en ese momento denominó irregular en el bloque 1,920,000, transfiriendo ETH relacionado 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 finalmente formaron Ethereum Classic (ETC), lo que llevó a la conocida bifurcación entre ETH y ETC, indicando que no todos aceptaron este conjunto de reglas.

Cosmos Hub es diferente; utiliza CometBFT, que se asemeja más a un consenso BFT típico.

Se puede entender como un consenso BFT más típico, es decir, para que un bloque se someta realmente, necesita obtener más de dos tercios del poder de votación para el Commit.

Su ventaja es que la finalización es muy clara; una vez que un bloque ha sido sometido por suficientes votos de poder de validación, no necesita esperar más bloques como en PoW, intercambiando probabilidad por seguridad.

Pero su otro lado es muy directo: si un tercio o más del poder de votación deja de proporcionar los votos necesarios para formar el Commit, los validadores restantes no podrán reunir más de dos tercios, sin importar cuánto se esfuercen.

En este momento, la opción más segura para la red es, como en la "pausa de producción de bloques" de esta vez, por lo que desde la perspectiva de sistemas distribuidos, esta breve pausa de Cosmos Hub no es en realidad un misterio.

En resumen, un grupo de validadores que poseen suficiente poder de votación que dejan de participar, hace que el protocolo de consenso, de acuerdo con sus propias reglas, prefiera perder disponibilidad en lugar de continuar confirmando nuevos bloques en ausencia de suficiente consenso.

Esto, en realidad, corresponde a dos conceptos que a menudo son confundidos por los usuarios comunes en sistemas distribuidos:

• Seguridad: no permitir que diferentes nodos confirmen simultáneamente dos estados finales conflictivos;
• Liveliness: si la red puede seguir funcionando y procesando nuevas transacciones;

Para los sistemas BFT, cuando hay insuficientes nodos participando en el consenso, a veces la pausa es precisamente el costo que se paga para mantener la seguridad. Dicho de manera directa, este libro mayor descentralizado prefiere quedarse allí, en lugar de permitir que los demás registren diferentes estados.

Desde esta perspectiva, al mirar hacia atrás, se puede descubrir que muchos incidentes que parecen completamente diferentes en la historia de las cadenas de bloques públicas, en realidad giran en torno a la misma cuestión:

¿Qué debe hacer la red cuando los nodos distribuidos no pueden llegar a un consenso sobre el "estado correcto"?

III. Desde Bitcoin hasta Solana, ¿dónde están realmente los límites del riesgo en las cadenas de bloques públicas?

No es la primera vez que Cosmos plantea esta cuestión.

Ya en 2013, Bitcoin experimentó un incidente clásico de bifurcación de cadena.

En ese momento, Bitcoin 0.8 cambió su base de datos subyacente de Berkeley DB a LevelDB, y luego apareció un bloque que contenía una gran cantidad de entradas de transacciones. Los nuevos nodos podían procesarlo normalmente, pero algunos nodos antiguos, debido a la limitación en el número de bloqueos de Berkeley DB, lo consideraron inválido.

Así que apareció una situación muy incómoda: todos estaban ejecutando Bitcoin, pero los clientes nuevos y antiguos comenzaron a dar respuestas diferentes sobre si "este bloque es válido o no".

La red se dividió en dos cadenas, y el lado de la nueva versión 0.8 llegó a tener aproximadamente el 60% de la potencia de cálculo, lo que hizo que no pudiera depender de la competencia normal de potencia de cálculo para converger rápidamente.

Finalmente, grandes grupos mineros coordinaron un regreso a la versión anterior, recuperando más potencia de cálculo en el lado de las reglas antiguas, y la red pudo volver a converger. Posteriormente, Bitcoin revisó este incidente específicamente con el BIP 50.

En 2016, el evento de The DAO en Ethereum llevó el problema un paso más allá.

Como se mencionó anteriormente, la comunidad de Ethereum finalmente realizó un Hard Fork, ejecutando un cambio de estado especial que fue claramente denominado por la Fundación Ethereum como un "cambio de estado irregular" en el bloque 1,920,000, transfiriendo el ETH relacionado a un contrato de recuperación.

Sin embargo, no todos estaban de acuerdo con este tratamiento. Algunos mineros y miembros de la comunidad que se negaron a aceptar el cambio de estado continuaron manteniendo las reglas originales, lo que llevó a la existencia a largo plazo de Ethereum Classic (ETC).

Este Fork de DAO también es un evento clásico, que le dice a todos que cuando ocurren eventos extremos, existe un consenso social además del consenso del código; si no se puede formar una opinión suficientemente unificada, una cadena realmente puede dividirse en dos.

En 2021, Solana mostró un camino de falla completamente diferente.

En septiembre de ese año, una gran cantidad de transacciones de robots inundaron la red, agotando la memoria de los nodos de validación, lo que provocó que muchos nodos colapsaran. Finalmente, toda la red no pudo llegar a un consenso sobre el estado actual, deteniendo la confirmación de nuevos bloques durante aproximadamente 17 horas, y luego los validadores coordinaron para restaurar la red.

Al juntar estos incidentes, se puede ver que no son lo mismo:

• El problema de Bitcoin en 2013 fue que diferentes clientes comenzaron a ejecutar diferentes reglas de validez;
• El problema de Solana en 2021 fue que muchos nodos de validación no podían continuar participando normalmente en el consenso, y la red perdió Liveness;
• El DAO de Ethereum se enfrentó más a la cuestión de si la comunidad debería modificar el estado de manera proactiva a través de nuevas reglas de protocolo;
• Y esta vez, Cosmos Hub tiene otra capa de particularidad, ya que la red primero coordinó a través de los validadores para perder proactivamente Liveness, evitando que los activos atacados continuaran moviéndose; luego, un porcentaje suficientemente alto de los derechos de validación aceptó conjuntamente un nuevo software y un estado de recuperación, permitiendo que la red volviera a formar consenso;

Por lo tanto, en lugar de simplificar estos eventos a "las cadenas de bloques también pueden apagarse" o "la descentralización es falsa", es mejor reconocer un hecho más real:

El mecanismo de consenso nunca ha sido una máquina que no puede fallar; lo que realmente proporciona es un conjunto de reglas descentralizadas, como quién decide cuál es la cadena correcta cuando hay una discrepancia; cuántos participantes se necesitan para que un estado obtenga finalización; si la red elige continuar funcionando o detenerse en caso de fallos; y en situaciones extremas, qué tipo de acción colectiva puede cambiar las reglas de operación posteriores.

Esto también deja a este evento de Cosmos una pregunta más digna de reflexión para los usuarios comunes que "¿debería detenerse la cadena?"

Reflexiones finales

A menudo decimos, not your keys, not your coins.

Esta frase, por supuesto, sigue siendo válida, solo que enfatiza el control de los activos: siempre que la clave privada esté en manos del usuario, la billetera, la plataforma de intercambio u otros terceros no pueden firmar correctamente una transacción.

El requisito es que la cadena de bloques en la que te encuentras debe tener la capacidad de procesar esa firma en todo momento.

El día que Cosmos Hub dejó de producir bloques, los usuarios aún poseían sus claves privadas, y los activos no desaparecieron de la nada; simplemente, incluso si firmabas correctamente una transacción, no había nuevos bloques que pudieran aceptarla.

El proceso de recuperación también ilustra que si un número suficiente de participantes del consenso acepta un nuevo conjunto de reglas de estado, el estado en cadena de cuentas específicas también puede cambiar sin la firma de la clave privada de la dirección original.

Esto no invalidará "Not your keys, not your coins", pero nos recuerda que la autonomía de la clave privada y el derecho de consenso subyacente nunca han sido la misma cosa.

Y lo mismo ocurre con las billeteras.

Las billeteras pueden asegurar que las claves privadas y los derechos de firma estén en manos del usuario, pueden identificar rápidamente anomalías a nivel de cadena, mostrar con precisión el estado de las transacciones, establecer RPC y redundancia de nodos, y después de que la red se recupere, confirmar nuevamente el resultado final de la transacción.

Pero las billeteras 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 cambien a nivel de consenso.

Por lo tanto, lo que realmente necesita perseguir un sistema descentralizado maduro puede que nunca sea "nada debe cambiarse absolutamente"; por el contrario, debería aclarar lo más posible estos límites imperfectos: ¿quién puede pausar el consenso? ¿Qué peso se necesita? ¿En qué circunstancias se permite la intervención de emergencia?

Porque la verdadera descentralización no puede evitar que el sistema encuentre accidentes; la clave está en que, incluso si realmente ocurren accidentes, aún podamos saber quién, bajo qué reglas y con qué consenso, decide cómo se debe llevar a cabo este libro a partir de ahora.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.