Reorg (reorganización de la cadena)

¿Qué es un reorg en cripto?

Un reorg, abreviatura de reorganización de la cadena, se produce cuando un nodo blockchain sustituye parte del historial actual de la cadena por otra rama válida.

En pocas palabras, la blockchain siguió temporalmente un camino y después pasó a seguir otro que la red aceptó como la cadena mejor o canónica.

Un reorg puede eliminar de la cadena activa uno o más bloques añadidos recientemente y sustituirlos por bloques diferentes.

Las transacciones incluidas en los bloques eliminados pueden volver al mempool, aparecer de nuevo como pendientes, incluirse en un bloque posterior o dejar de ser válidas si se confirman transacciones incompatibles en la nueva cadena.

Los reorgs se analizan sobre todo en cadenas Proof of Work y Proof of Stake, sistemas Layer 2, bridges, wallets, procesadores de pagos y plataformas de trading que deben determinar cuándo una transacción puede considerarse definitiva.

La documentación de Ethereum sobre ataques y defensa en Proof of Stake define un reorg como una reorganización de bloques en un nuevo orden, en la que se pueden añadir o eliminar bloques de la cadena canónica.

La documentación para desarrolladores de Bitcoin explica que las confirmaciones miden cuántos bloques habría que modificar para eliminar o cambiar una transacción. Por eso los usuarios esperan antes de considerar definitivos los pagos.

Un reorg no es automáticamente un ataque, pero puede ser peligroso si revierte transacciones importantes, permite el doble gasto, interrumpe aplicaciones o afecta a sistemas cross-chain.

Definición sencilla de reorg

Un reorg se produce cuando una blockchain cambia los bloques recientes que considera parte de la cadena principal.

Los bloques recientes anteriores quedan obsoletos, huérfanos o fuera de la cadena canónica, según la terminología de cada red.

Los bloques nuevos pasan a formar parte del historial aceptado que deben seguir los nodos, las wallets, los exploradores y las aplicaciones.

Esto puede suceder porque distintos validadores o mineros hayan creado brevemente bloques en competencia a la misma altura.

También puede ocurrir porque la latencia de la red haya hecho que algunos nodos reciban primero un bloque y otros reciban primero otro.

En los casos más graves, puede producirse un reorg porque un atacante o un grupo de validadores con gran poder intenta sustituir bloques para obtener beneficios o censurar transacciones.

Para los usuarios, el efecto principal es que una transacción que parecía confirmada puede quedar sin confirmar o ser sustituida.

Por eso los sistemas cripto utilizan confirmaciones, reglas de finalidad y periodos de espera ajustados al riesgo.

Por qué son importantes los reorgs

Los reorgs son importantes porque las blockchains se utilizan para determinar la titularidad y la liquidación.

Si se acepta demasiado pronto un pago, swap, depósito en un bridge, acuñación, retirada o liquidación, un reorg posterior puede causar pérdidas o confusión.

Un comerciante que envíe productos tras una única confirmación poco sólida puede asumir un riesgo si el pago desaparece en un reorg.

Un bridge que libere activos antes de que la transacción de la cadena de origen sea definitiva puede generar activos duplicados o sin respaldo si la transacción de origen se elimina.

Un protocolo DeFi que reaccione a un bloque antes de que alcance suficiente finalidad puede procesar un estado obsoleto.

Una wallet que muestre demasiado pronto una transacción como completada puede inducir a error al usuario.

La documentación de Circle sobre finalidad y confirmaciones de bloques explica que las atestaciones más rápidas pueden conllevar riesgo de reorganización, mientras que los procesos estándar esperan a que se alcance una finalidad sólida, cuando es poco probable que una reorganización revierta las transacciones.

Por tanto, tener en cuenta los reorgs es fundamental para la seguridad blockchain, especialmente en las transferencias de gran valor y las aplicaciones cross-chain.

Cómo se produce un reorg

Un reorg comienza cuando existen simultáneamente dos o más ramas válidas de la cadena.

Esto puede ocurrir de forma natural porque las blockchains son sistemas distribuidos y los nodos no reciben los nuevos bloques exactamente al mismo tiempo.

Un grupo de nodos puede recibir primero el Bloque A.

Otro grupo puede recibir primero el Bloque B.

Ambos bloques pueden ser válidos, pero solo una rama puede convertirse en el camino canónico.

Las reglas de consenso de la red determinan qué rama prevalece.

Cuando un nodo descubre que otra rama válida se ha reforzado según la regla de elección de bifurcación de la red, cambia a esa rama.

Ese cambio es la reorganización de la cadena.

Reorg frente a fork

Un fork es una división del historial de una blockchain en la que existe más de una rama válida.

Un reorg es el proceso de cambiar de una rama a otra.

No todos los forks se convierten en reorgs importantes.

Muchos forks breves se resuelven rápidamente cuando la red elige una rama y abandona la otra.

Un hard fork es distinto porque cambia las reglas del protocolo y puede crear una división permanente de la cadena si las comunidades siguen apoyando ambos lados.

Un reorg normal suele ser temporal y producirse bajo las mismas reglas de consenso.

Una división permanente crea dos redes que continúan funcionando.

Un reorg es una corrección del camino de la cadena activa dentro del proceso de consenso de una red.

Reorg frente a finalidad

La finalidad es el punto en el que, según las reglas de la red, se considera extremadamente difícil o imposible revertir una transacción.

La finalidad busca evitar los reorgs o hacer que su coste económico resulte poco realista.

La documentación de Ethereum sobre Proof of Stake indica que una transacción tiene finalidad cuando forma parte de un bloque que no puede cambiarse sin que se queme una gran cantidad de ETH.

La misma documentación explica que revertir un bloque finalizado de Ethereum obligaría al atacante a perder al menos un tercio del total de ETH en staking.

Bitcoin utiliza finalidad probabilística, ya que cada bloque adicional hace más difícil sustituir el historial anterior.

Solana utiliza niveles de compromiso como processed, confirmed y finalized para ayudar a los clientes a entender el grado de certeza de una transacción.

La lección práctica es que una transacción puede incluirse en un bloque antes de alcanzar una finalidad sólida.

Las aplicaciones deben determinar cuánta finalidad necesitan en función del valor, la velocidad y el riesgo.

Reorg frente a bloque huérfano

Un bloque huérfano o desactualizado es un bloque que era válido, pero no permaneció en la cadena canónica.

Un reorg puede generar bloques obsoletos porque la rama anterior deja de ser la cadena activa.

Las distintas comunidades blockchain utilizan estos términos de forma ligeramente diferente.

En el lenguaje cripto cotidiano, los usuarios suelen decir que un bloque ha quedado huérfano cuando lo ha sustituido una rama en competencia.

Lo importante es que las transacciones incluidas en ese bloque quizá deban procesarse de nuevo o desaparezcan del historial confirmado.

Las wallets y los exploradores de blockchain pueden actualizar el estado de la transacción cuando detectan el reorg.

Los desarrolladores no deben tratar un bloque como permanente solo porque se haya visto una vez.

Deben hacer un seguimiento de las confirmaciones y del estado de finalidad antes de ejecutar acciones irreversibles off-chain.

Reorg frente a doble gasto

El doble gasto es un intento de gastar los mismos fondos de dos formas incompatibles.

Un reorg puede permitir un doble gasto si se elimina una transacción que pagaba a una persona y se confirma una transacción incompatible que paga a otra en la nueva cadena.

La documentación de Bitcoin sobre el procesamiento de pagos explica que un usuario malicioso puede crear una transacción para pagar al destinatario y una segunda que gaste la misma entrada para devolverse los fondos a sí mismo; solo una de ellas puede incluirse en la blockchain.

La misma documentación explica que, una vez incluida una transacción en un bloque, sustituirla requiere modificar el historial de la blockchain, algo que resulta más difícil a medida que aumentan las confirmaciones.

Un reorg no siempre implica un doble gasto, pero un ataque de doble gasto suele necesitar un reorg para tener éxito después de que se haya confirmado la primera transacción.

Por eso, los pagos de gran valor suelen requerir más confirmaciones que los pagos pequeños.

Cuantos más bloques haya por encima de la transacción, más costoso será sustituirla.

Por tanto, la política de confirmaciones es una defensa frente al doble gasto basado en reorgs.

Causas habituales de los reorgs

La primera causa habitual es la latencia de la red.

Cuando un bloque válido tarda en llegar a todos los nodos, otro productor de bloques puede crear uno en competencia antes de recibir información sobre el primero.

La segunda causa es la producción simultánea de bloques.

Dos mineros o validadores pueden crear bloques válidos casi al mismo tiempo.

La tercera causa es el comportamiento de validadores o mineros.

Un productor de bloques puede retenerlos, retrasar su publicación o publicar bloques estratégicamente de formas que aumenten el riesgo de reorg.

La cuarta causa son los errores de software o de los clientes.

Si distintos clientes interpretan el estado de forma incorrecta, pueden discrepar temporalmente sobre cuál es la cadena correcta.

La quinta causa es un ataque malicioso.

Un atacante puede intentar reorganizar bloques para realizar un doble gasto, censurar transacciones o extraer valor.

Reorgs breves

Un reorg breve suele sustituir uno o unos pocos bloques recientes.

Los reorgs breves son más comunes que los profundos porque los bloques recientes cuentan con menos protección.

Pueden producirse de forma natural en condiciones normales de red.

Para muchos usuarios, un reorg de un bloque quizá solo haga que una transacción pase de confirmada a pendiente y vuelva a confirmada más tarde.

Incluso un reorg breve puede ser importante para las aplicaciones de alta velocidad.

Una aplicación de trading, un bridge, un oráculo, un bot de liquidación o un procesador de pagos pueden reaccionar a bloques muy recientes.

Si esos bloques se sustituyen, la aplicación quizá tenga que revertir o corregir su estado interno.

Por eso, la infraestructura debe diseñarse para gestionar reorgs en lugar de asumir que nunca ocurren.

Reorgs profundos

Un reorg profundo sustituye muchos bloques.

Es mucho más grave porque puede eliminar transacciones que los usuarios ya consideraban fiables.

Puede indicar un problema importante de la red, un ataque, un error de consenso, un fallo de los validadores o una partición extrema de la red.

En los sistemas Proof of Work, los reorgs profundos se vuelven más costosos a medida que se acumula más Proof of Work sobre la transacción original.

En los sistemas Proof of Stake con finalidad económica, los reorgs profundos que afectan a bloques finalizados pueden requerir comportamientos sancionables y conllevar un coste económico muy elevado.

La hoja de ruta de Ethereum para la finalidad de una sola ranura explica que el retraso actual hasta alcanzar la finalidad deja margen para reorgs breves y que una finalidad más rápida podría reducir este riesgo.

Los reorgs profundos son poco frecuentes en redes maduras, pero son importantes porque su impacto puede ser grave.

Cualquier sistema que gestione grandes cantidades de valor debería estar preparado para escenarios de reorg poco frecuentes, pero de gran impacto.

Reorgs en redes Proof of Work

En las redes Proof of Work, los nodos suelen seguir la cadena válida con más trabajo acumulado.

Si aparecen dos ramas válidas, los mineros siguen construyendo sobre la que consideran mejor.

La rama que acumula más trabajo se convierte en la canónica.

Los nodos que seguían la rama perdedora se reorganizan para seguir la rama ganadora.

La documentación de Bitcoin sobre modos de funcionamiento explica que los nodos completos verifican la blockchain descargando y validando bloques, y que para engañar a un nodo completo se necesitaría un historial alternativo con una dificultad superior a la de la cadena verdadera actual.

Por eso las confirmaciones son fundamentales para la liquidación en Proof of Work.

Cada nuevo bloque añade más trabajo que un atacante debe superar.

El riesgo de reorg disminuye a medida que aumenta la profundidad del bloque.

Reorgs en redes Proof of Stake

En las redes Proof of Stake, el comportamiento de los reorgs depende de los votos de los validadores, las reglas de elección de bifurcación, los mecanismos de finalidad, las sanciones y las condiciones de slashing.

Ethereum utiliza una regla de elección de bifurcación denominada LMD-GHOST y un sistema de finalidad basado en la votación de checkpoints.

La documentación de Ethereum explica que los validadores atestiguan el bloque que consideran la cabecera de la cadena y que los clientes de consenso favorecen la bifurcación con mayor peso de atestaciones.

Esto significa que puede haber desacuerdos breves antes de alcanzar la finalidad.

Una vez alcanzada, revertir bloques finalizados resulta costoso desde el punto de vista económico, ya que los atacantes pueden perder su stake.

Por tanto, el análisis de los reorgs en Proof of Stake se centra en el peso de las atestaciones, el estado de finalidad, la participación de los validadores, la latencia de la red y el riesgo de slashing.

Un reorg en Proof of Stake no se evalúa únicamente por el número de bloques.

También hay que tener en cuenta si los bloques sustituidos estaban finalizados, justificados, confirmados o simplemente se habían propuesto hacía poco.

Reorgs y confirmaciones

Una confirmación significa que una transacción se ha incluido en un bloque y que se pueden haber construido bloques adicionales sobre él.

En muchas cadenas, una confirmación significa que la transacción está incluida en el último bloque aceptado.

Dos confirmaciones significan que se ha añadido un bloque más sobre ese bloque.

Por lo general, más confirmaciones implican un menor riesgo de reorg.

La documentación para desarrolladores de Bitcoin señala que seis confirmaciones suelen utilizarse para transacciones de gran valor, aunque también indica que el número es en cierta medida arbitrario y se basa en el riesgo.

Para pagos pequeños, pueden bastar menos confirmaciones.

Los depósitos grandes, los bridges o las entregas off-chain irreversibles pueden requerir más confirmaciones.

La política de confirmaciones adecuada depende de la seguridad de la red, el valor de la transacción, los incentivos para atacar y la tolerancia al riesgo del usuario.

Reorgs y bloques finalizados

Un bloque finalizado es aquel que la red considera extremadamente difícil de eliminar.

La finalidad ofrece más garantías que la simple inclusión en un bloque.

En Ethereum, alcanzar la finalidad significa que revertir un bloque requeriría imponer graves sanciones económicas a los atacantes.

En Solana, la documentación sobre el estado de compromiso indica que el estado finalized requiere que se hayan construido 31 o más bloques confirmados sobre el bloque objetivo.

En los sistemas de bridges y pagos, la finalidad puede definirse según las reglas de la cadena de origen y la política de riesgo de la aplicación.

Una transacción finalizada suele ser mucho más segura que una que solo se ha procesado o incluido recientemente.

Sin embargo, los modelos de finalidad varían entre blockchains.

Los desarrolladores no deberían aplicar el mismo periodo de espera a todas las redes sin entender el diseño de consenso de cada una.

Reorgs y wallets

Las wallets deberían estar diseñadas para gestionar los reorgs correctamente.

Al principio, una wallet puede mostrar una transacción como pendiente.

Después, puede mostrar una o varias confirmaciones.

Si un reorg elimina el bloque que contiene la transacción, la wallet debería actualizar su estado en lugar de comportarse como si nada hubiera cambiado.

Si la transacción sigue siendo válida y espera a que se vuelva a incluir, puede regresar al estado pendiente.

La transacción puede fallar si en la nueva cadena se confirma otra transacción incompatible.

Las wallets deben evitar marcar demasiado pronto como definitivas las transacciones de gran valor.

Las etiquetas de estado claras ayudan a los usuarios a distinguir entre una transacción difundida, incluida, confirmada y finalizada.

Reorgs y exploradores de blockchain

Los exploradores de blockchain siguen la cadena canónica actual y muestran el estado de las transacciones a los usuarios.

Cuando se produce un reorg, un explorador puede retirar bloques de la vista de la cadena principal y mostrar los bloques que los sustituyen.

Según la red y el diseño del explorador, una página de transacción puede cambiar de confirmada a descartada, pendiente, fallida o sustituida.

Durante reorgs que evolucionan rápidamente, distintos exploradores pueden mostrar diferencias temporales porque reciben los datos de la red en momentos distintos.

En condiciones de red inusuales, los usuarios deben evitar depender de un solo explorador para comprobar confirmaciones importantes.

Los desarrolladores deben utilizar una infraestructura de nodos fiable e indexación que tenga en cuenta la finalidad, en lugar de extraer de las páginas de exploradores los datos para la lógica de liquidación.

Los indexadores deberían conservar suficiente historial para revertir el estado afectado por un reorg.

Un explorador es una herramienta útil para consultar información, pero la cadena canónica del nodo y sus reglas de finalidad son la fuente de referencia.

Reorgs y exchanges

Las plataformas de trading y los servicios de custodia suelen esperar a que se alcance un número de confirmaciones determinado antes de abonar los depósitos.

El objetivo es reducir la probabilidad de que un depósito desaparezca en un reorg después de abonarlo al usuario.

Los equipos de riesgo pueden exigir más confirmaciones en redes con menos potencia de hash, menor seguridad del stake, inestabilidad reciente o mayores incentivos para atacarlas.

También pueden exigir menos confirmaciones en redes con una finalidad determinista más rápida.

Además, pueden pausar los depósitos y las retiradas durante episodios anómalos de reorgs.

Algunos usuarios creen que los periodos de espera de los depósitos solo causan retrasos, pero también son medidas de control del riesgo.

Si una plataforma abona un depósito demasiado pronto y un reorg lo elimina, puede sufrir pérdidas.

Por tanto, las políticas de confirmación forman parte de la gestión del riesgo operativo.

Reorgs y bridges

Los bridges son especialmente sensibles a los reorgs porque conectan dos o más cadenas.

Un bridge puede bloquear o quemar un activo en una cadena y liberar o acuñar un activo relacionado en otra.

Si la transacción de la cadena de origen se elimina mediante un reorg después de que se ejecute la acción en la cadena de destino, el bridge puede haber liberado valor sin un evento de origen válido.

Esto puede generar activos con respaldo insuficiente o desajustes contables.

Los sistemas de bridges reducen este riesgo al esperar confirmaciones y finalidad, utilizar pruebas de fraude o de validez, registrar los mensajes procesados y establecer límites de riesgo.

La guía de Circle sobre finalidad muestra que los sistemas de transferencias cross-chain pueden aplicar tiempos de espera distintos a las transferencias rápidas y estándar, ya que los procesos más rápidos se basan en supuestos diferentes sobre los reorgs.

Los usuarios deben entender que los bridges más rápidos pueden sacrificar seguridad a cambio de velocidad y conllevar un mayor riesgo de reorg o de falta de finalidad.

Para las transferencias de gran valor, suele ser más seguro esperar a que se alcance una finalidad más sólida.

Reorgs y redes Layer 2

Las redes Layer 2 suelen depender de una capa de liquidación para la disponibilidad de los datos, la finalidad, las pruebas de fraude, las pruebas de validez o la seguridad de las retiradas.

Una transacción Layer 2 puede parecer definitiva en la interfaz de Layer 2 antes de que el lote correspondiente se finalice en la capa de liquidación.

La documentación de Circle sobre finalidad señala que algunos sistemas Layer 2 dependen del momento en que se publican los lotes en Ethereum y de cuándo se finaliza el bloque correspondiente de Ethereum.

Esto supone que hay que entender dos niveles de finalidad.

Puede haber una confirmación local en Layer 2 y una finalidad en la capa de liquidación.

Para las transacciones pequeñas habituales, puede bastar la confirmación local.

Para las transferencias cross-chain, los depósitos grandes y la contabilidad de protocolos, puede ser necesaria la finalidad de la capa de liquidación.

Los usuarios no deberían dar por sentado que todas las confirmaciones Layer 2 conllevan el mismo riesgo de reorg.

Reorgs y MEV

El MEV, o valor máximo extraíble, es el valor que los productores de bloques o los actores que ordenan transacciones pueden capturar al incluirlas, excluirlas o reordenarlas.

Los reorgs pueden relacionarse con el MEV cuando la sustitución de bloques permite a un actor aprovechar oportunidades rentables de ordenación de transacciones.

La documentación de Ethereum sobre ataques y defensa indica que los reorgs maliciosos pueden permitir extraer valor mediante transacciones de front-running y back-running.

Los incentivos para realizar reorgs breves son motivo de preocupación, ya que un actor podría intentar sustituir un bloque si con ello captura suficiente valor.

La finalidad reduce este riesgo al encarecer la sustitución de bloques más profundos.

Las aplicaciones pueden reducir su exposición esperando a que se alcance la finalidad, utilizando canales privados de transacciones cuando corresponda, diseñando mecanismos de subasta más seguros y vigilando los comportamientos anómalos de la cadena.

El riesgo de reorgs relacionado con el MEV es más importante en operaciones DeFi de gran valor, liquidaciones, arbitraje, actualizaciones de oráculos y eventos de bridges.

Los usuarios deben entender que el riesgo de reorg no es solo un accidente técnico, sino que también puede responder a incentivos económicos.

Reorgs y oráculos

Los oráculos introducen datos off-chain o cross-chain en contratos inteligentes.

Si un oráculo lee datos de un bloque que después se elimina mediante un reorg, es posible que esos datos ya no coincidan con el historial canónico de la cadena.

Por ejemplo, un oráculo podría comunicar un precio, saldo, depósito o evento que solo existía en un bloque eliminado.

Los sistemas de oráculos bien diseñados tienen en cuenta la profundidad de las confirmaciones y la finalidad antes de publicar datos sensibles.

Los protocolos deberían evitar depender de eventos muy recientes si un reorg pudiera causar pérdidas importantes.

En el caso de los oráculos cross-chain, el riesgo de reorg de la cadena de origen puede afectar a los contratos de la cadena de destino.

Los oráculos deberían especificar claramente los supuestos de finalidad de su diseño.

Los contratos inteligentes que utilizan oráculos deben saber si sus datos son inmediatos, están confirmados o han alcanzado la finalidad.

Reorgs e indexadores

Los indexadores leen datos de blockchain y los convierten en bases de datos consultables para aplicaciones, paneles, wallets, herramientas de análisis y API.

Los reorgs suponen un reto importante para los indexadores, ya que quizá haya que revertir los datos indexados.

Si un indexador registra eventos de un bloque que después queda obsoleto, debe eliminarlos o corregirlos.

Si no se gestionan correctamente los reorgs, pueden aparecer saldos, historiales de transacciones, titularidades de NFT, datos de liquidación o estados de bridges incorrectos.

Los indexadores deberían registrar hashes de bloques, hashes de los bloques anteriores, números de bloque, estados de finalidad y profundidad de reversión.

No deberían tratar los bloques nuevos como permanentes de inmediato.

En las aplicaciones de gran valor, los indexadores deberían ofrecer API que tengan en cuenta la finalidad.

Un indexador preparado para gestionar reorgs es una infraestructura fundamental para las aplicaciones cripto serias.

Reorgs y contratos inteligentes

Los contratos inteligentes se ejecutan conforme al estado de la cadena canónica.

Si un reorg elimina un bloque que contiene una llamada a un contrato inteligente, esa llamada deja de formar parte del historial canónico.

La transacción puede volver a incluirse más tarde, pero quizá se ejecute de otra manera si el estado ha cambiado en la cadena sustituta.

Esto es importante en DeFi porque el estado puede cambiar rápidamente.

Un swap, una liquidación, una actualización de oráculo, una acuñación o una reclamación pueden depender del estado exacto en el momento de la ejecución.

Los desarrolladores no deberían crear sistemas off-chain que den por definitivo el resultado de una transacción antes de que haya suficientes confirmaciones.

Los propios contratos inteligentes no «recuerdan» el historial de bloques eliminados, salvo que ese historial forme parte de la cadena canónica.

Los servicios off-chain relacionados con contratos inteligentes deben tener en cuenta los reorgs.

Reorgs y procesamiento de pagos

Los procesadores de pagos deben decidir cuándo una transacción cripto es lo bastante segura para aceptarla.

Aceptar pagos sin confirmaciones es rápido, pero arriesgado.

Aceptar pagos con una confirmación reduce el riesgo, pero no lo elimina.

Esperar a que haya más confirmaciones reduce el riesgo de reorg y de doble gasto, pero prolonga la espera del usuario.

La política adecuada depende del valor del pago y del coste del fraude.

Una compra digital de poco valor puede aceptar más riesgo que el envío de un producto físico caro.

Por lo general, una liquidación de gran valor debería esperar a que haya confirmaciones más sólidas o se alcance la finalidad.

Los sistemas de pago deberían comunicar claramente a usuarios y comerciantes la política de confirmaciones.

Reorgs y estado de las transacciones

Una transacción puede pasar por varios estados durante un reorg.

Puede haberse difundido, pero seguir sin confirmar.

Puede incluirse en un bloque.

Puede acumular confirmaciones.

Puede eliminarse de la cadena canónica durante un reorg.

Si sigue siendo válida, puede volver al estado pendiente.

Puede confirmarse de nuevo en un bloque sustituto.

Puede quedar sustituida definitivamente si se confirma en su lugar una transacción incompatible.

Reorgs y comisiones de gas

El comportamiento de las comisiones de gas durante un reorg depende del diseño de la blockchain y del estado canónico final de la transacción.

Si una transacción se incluye en un bloque obsoleto, pero no en la cadena canónica final, a los usuarios les suele importar si terminó ejecutándose en la cadena aceptada.

Si la transacción se ejecuta más adelante en un bloque canónico, el usuario paga conforme a las reglas de esa cadena.

Si la transacción no se ejecuta en el historial canónico, es como si esa ejecución no se hubiera liquidado en la cadena final.

Sin embargo, durante los reorgs, las wallets y los exploradores pueden mostrar temporalmente información confusa sobre las comisiones.

Los desarrolladores deberían seguir los recibos canónicos en lugar de las observaciones temporales de bloques.

Los usuarios deben esperar a que haya confirmaciones antes de dar por definitivos el importe de la comisión y el estado de ejecución.

En periodos de tensión de la red, los reorgs y la volatilidad de las comisiones pueden hacer que el seguimiento de las transacciones parezca incoherente.

Reorgs y gestión del riesgo

La gestión del riesgo de reorg empieza por la profundidad de las confirmaciones.

Cuanto más valiosa sea la transacción, más garantías de finalidad debería exigir el destinatario.

La segunda herramienta es una política específica para cada red.

Las distintas cadenas tienen tiempos de bloque, sistemas de finalidad, conjuntos de validadores y costes de ataque diferentes.

La tercera herramienta es la supervisión.

Los servicios deberían detectar profundidades de reorg inusuales, intervalos perdidos, interrupciones de validadores, inestabilidad en la elección de bifurcación y discrepancias entre exploradores.

La cuarta herramienta es retrasar la liquidación.

Las empresas deberían evitar realizar acciones irreversibles off-chain hasta que la transacción on-chain tenga suficientes garantías de seguridad.

Reorgs y ataques del 51%

Un ataque del 51% se produce cuando un atacante controla suficiente potencia de minería o influencia sobre el stake para afectar al historial canónico de la cadena.

En los sistemas Proof of Work, un atacante con suficiente potencia de hash puede intentar crear una cadena alternativa y publicarla para sustituir bloques recientes.

En los sistemas Proof of Stake, un atacante puede intentar influir en la elección de bifurcación, retrasar la finalidad o llevar a cabo ataques más graves que puedan dar lugar a sanciones.

La documentación de Ethereum señala que los atacantes en Proof of Stake pueden intentar provocar reorgs, alcanzar una doble finalidad o retrasar la finalidad.

Un ataque de reorg puede utilizarse para realizar un doble gasto o censurar transacciones.

El coste y la viabilidad dependen del modelo de seguridad de la red.

Por lo general, es más difícil atacar las redes maduras que las redes pequeñas con menor seguridad de minería o staking.

Los usuarios deberían ser más prudentes con las confirmaciones en redes de baja seguridad.

Reorgs y particiones de red

Una partición de red se produce cuando una parte de la red no puede comunicarse con normalidad con otra.

Durante una partición, distintos grupos de nodos pueden crear ramas diferentes de la cadena.

Cuando mejora la comunicación, la red puede elegir una rama como canónica y reorganizarse para abandonar la otra.

Las particiones pueden deberse a fallos de enrutamiento de Internet, problemas de los clientes, ataques de denegación de servicio o interrupciones de la infraestructura.

La profundidad del reorg puede depender de la duración de la partición y de cómo gestionen las reglas de consenso las ramas en competencia.

Las aplicaciones deberían supervisar el estado de la red, no solo el de cada transacción.

Una cadena puede parecer normal desde un nodo, mientras que otra parte de la red ve algo distinto.

Utilizar varios nodos fiables puede ayudar a detectar discrepancias entre las vistas de la cadena.

Reorgs y errores de los clientes

Los errores de los clientes pueden causar interrupciones similares a un reorg si los nodos discrepan sobre qué bloques son válidos.

Si un cliente acepta un bloque que otro rechaza, la red puede dividirse hasta que se resuelva el problema.

Por eso son importantes la diversidad de clientes, las pruebas, las auditorías y la coordinación de actualizaciones.

Una división de cadena causada por un error puede ser más peligrosa que un reorg normal de un bloque porque puede afectar al propio consenso.

Durante comportamientos anómalos, las aplicaciones deberían seguir los avisos oficiales de los clientes.

Los operadores de nodos deberían mantener el software actualizado y, al mismo tiempo, entender las instrucciones de actualización antes de instalar versiones importantes.

La diversidad de clientes puede reducir la posibilidad de que un único error de software perjudique a toda la red.

Por tanto, el riesgo de reorg también está relacionado con la calidad del software, no solo con el comportamiento de mineros o validadores.

Reorgs y reversiones

Reversión es un término más amplio que describe la vuelta del estado a un punto anterior.

Un reorg es una reversión específica de blockchain que se produce al cambiar a otra rama de la cadena.

Después de un reorg, las aplicaciones quizá tengan que revertir sus estados internos.

Por ejemplo, un sistema contable puede tener que eliminar el abono de un depósito si la transacción correspondiente se ha retirado de la cadena mediante un reorg.

Un juego quizá tenga que eliminar la acuñación de un objeto si la transacción de acuñación ha desaparecido.

En lugar de revertir la operación después de liberar activos en la cadena de destino, un bridge quizá deba esperar más tiempo.

Diseñar aplicaciones que toleren los reorgs suele consistir en decidir cuándo es aceptable revertir una operación y cuándo es más seguro esperar.

Los sistemas que no pueden tolerar reversiones deberían esperar a que se alcance una finalidad sólida antes de actuar.

Reorgs y seguridad de los usuarios

Los usuarios pueden reducir el riesgo de reorg esperando a que haya confirmaciones antes de considerar definitiva una transacción.

En pagos de gran valor, deberían evitar entregar productos, prestar servicios o tomar decisiones irreversibles tras una confirmación muy reciente.

Deben entender que las distintas cadenas siguen criterios diferentes para las confirmaciones.

Conviene extremar la precaución durante forks, interrupciones, ataques, eventos de bridges y condiciones anómalas de la red.

Deberían utilizar wallets y servicios que muestren claramente el estado de las confirmaciones.

No deberían alarmarse si una transacción confirmada hace poco vuelve al estado pendiente después de un reorg breve.

En muchos casos, la transacción puede volver a incluirse.

Si una transacción entra en conflicto o desaparece, los usuarios deberían consultar un explorador fiable, la página de asistencia de la wallet o su propio nodo, cuando sea posible.

Seguridad frente a reorgs para desarrolladores

Los desarrolladores deberían asumir que pueden producirse reorgs.

No deberían procesar eventos importantes después de ver un único bloque reciente, salvo que el caso de uso pueda tolerar una reversión.

Deberían almacenar hashes de bloques y de los bloques anteriores, no solo números de bloque.

Deberían poder detectar cuándo un bloque procesado anteriormente deja de ser canónico.

Deberían implementar lógica de reversión para los eventos indexados.

Deberían definir umbrales de confirmación para cada cadena y nivel de valor.

Deberían distinguir entre finalidad e inclusión.

Deberían probar sus sistemas en redes de desarrollo que permitan simular reorgs.

Ventajas de entender los reorgs

La primera ventaja es que permite aceptar pagos con más seguridad.

La segunda es que ayuda a diseñar mejores bridges.

La tercera es que permite mostrar el estado de las transacciones con más precisión en las wallets.

La cuarta es que mejora la fiabilidad de los indexadores y las aplicaciones.

La quinta es que permite gestionar mejor el riesgo de los depósitos y las retiradas de trading.

La sexta es que ayuda a entender mejor las confirmaciones y la finalidad.

La séptima es que mejora la protección frente a intentos de doble gasto.

Entender los reorgs ayuda a los usuarios a comprender que la liquidación en blockchain es un proceso y no un único instante.

Limitaciones de la protección frente a reorgs

Las confirmaciones reducen el riesgo de reorg, pero no eliminan todos los ataques posibles.

La finalidad reduce aún más este riesgo, aunque los modelos de finalidad varían entre redes.

Una red pequeña aún puede sufrir reorgs profundos si su seguridad es débil.

Un bridge puede fallar si interpreta mal la finalidad de la cadena de origen.

Una wallet puede inducir a error si muestra mal los estados.

Un contrato inteligente puede seguir teniendo otros fallos aunque la cadena sea estable.

La protección frente a reorgs es una capa de seguridad, no un sistema de seguridad completo.

Los usuarios y desarrolladores deberían combinarla con seguridad de custodia, revisión de contratos inteligentes, seguridad de oráculos y controles operativos.

Ideas equivocadas habituales sobre los reorgs

Una idea equivocada habitual es que una transacción es definitiva en cuanto aparece en un bloque.

En realidad, los reorgs breves todavía pueden afectar a las transacciones incluidas recientemente.

Otra idea equivocada es que todos los reorgs son ataques.

Muchos reorgs breves pueden producirse de forma natural por la latencia de la red y la competencia entre bloques válidos.

Otra idea equivocada es que todas las cadenas necesitan el mismo número de confirmaciones.

Los requisitos dependen del modelo de seguridad de la cadena, las reglas de finalidad, el valor transferido y la tolerancia al riesgo.

También es erróneo pensar que la finalidad significa lo mismo en todas partes.

Las distintas redes utilizan modelos de finalidad diferentes, por lo que los usuarios deben informarse sobre cada cadena concreta.

Señales de alerta relacionadas con los reorgs

Es una señal de alerta que un servicio abone depósitos de gran valor sin una política de confirmaciones.

También lo es que un bridge libere activos antes de que esté clara la finalidad de la cadena de origen.

Otra señal es que una wallet marque una transacción como definitiva inmediatamente después de difundirla.

También lo es que un indexador solo almacene números de bloque y no hashes de bloque.

Otra señal de alerta es que un procesador de pagos no pueda gestionar transacciones que vuelven a quedar sin confirmar.

También lo es que se produzcan repetidamente reorgs inusuales en una red cuya finalidad suele ser estable.

Otra señal es que una cadena Proof of Work pequeña y con poca potencia de hash acepte depósitos de gran valor tras muy pocas confirmaciones.

También lo es que una dApp reaccione a bloques muy recientes sin explicar sus supuestos de finalidad.

Buenas prácticas para los usuarios

Espera a que haya más confirmaciones cuando recibas pagos de gran valor.

Utiliza servicios que muestren claramente los estados pendiente, confirmado y finalizado.

Ten cuidado durante forks, interrupciones o actividad anómala de la red.

No entregues productos o servicios de valor basándote únicamente en una transacción sin confirmaciones.

Ten en cuenta que cada red utiliza sus propios modelos de finalidad y confirmación.

Utiliza wallets y exploradores fiables para hacer seguimiento de las transacciones.

En las transferencias cross-chain, elige opciones de finalidad más lentas cuando la seguridad sea más importante que la velocidad.

No des por irreversible una transacción hasta que alcance el nivel de confirmación o finalidad adecuado para esa cadena.

Buenas prácticas para los desarrolladores

Registra los hashes de bloques, los hashes de los bloques anteriores, los números de bloque, los hashes de transacción y el estado de finalidad.

Diseña indexadores y bases de datos con capacidad para revertir cambios.

Utiliza umbrales de confirmación específicos para cada cadena.

Espera a que se alcance una finalidad más sólida antes de activar acciones irreversibles off-chain.

Muestra claramente el estado de las confirmaciones en la interfaz de usuario.

Utiliza varios nodos o proveedores fiables para detectar discrepancias entre las vistas de la cadena.

Prueba cómo se comporta la aplicación en condiciones de reorg simuladas.

Documenta los supuestos de finalidad para usuarios, auditores y socios de integración.

Por qué los reorgs son importantes para AEO y la intención de búsqueda

Los usuarios buscan información sobre los reorgs porque quieren saber por qué puede cambiar a veces el estado de una transacción cripto confirmada.

La respuesta directa es que un reorg se produce cuando la red sustituye bloques recientes por otra rama válida de la cadena.

También buscan información para saber si han perdido sus fondos.

En la práctica, una transacción reorganizada puede volver al estado pendiente, incluirse más adelante o ser sustituida por una transacción incompatible, según la situación.

Es posible que también quieran saber cuántas confirmaciones son suficientes.

La respuesta útil es que el número de confirmaciones depende de la blockchain, el valor de la transacción, el modelo de finalidad y la tolerancia al riesgo.

La lección fundamental para los usuarios de criptomonedas es sencilla.

Los reorgs son una posibilidad normal del consenso descentralizado, y los sistemas seguros esperan a que haya suficientes confirmaciones o se alcance la finalidad antes de tratar las transacciones como irreversibles.

Preguntas frecuentes

¿Qué es un reorg?

Un reorg es una reorganización de la cadena en la que un nodo blockchain sustituye parte de la cadena aceptada actual por otra rama válida.

¿Qué significa reorganización de la cadena?

Significa que cambia el historial canónico reciente de la blockchain porque otra rama pasa a ser la cadena aceptada.

¿Puede un reorg eliminar mi transacción?

Sí. Un reorg puede eliminar una transacción de un bloque aceptado recientemente, aunque quizá se vuelva a incluir más adelante si sigue siendo válida.

¿Un reorg siempre es un ataque?

No. Los reorgs breves pueden producirse de forma natural por la latencia de la red o la producción simultánea de bloques, aunque también puede haber reorgs maliciosos.

¿Qué es un reorg de un bloque?

Se produce cuando la red sustituye el último bloque canónico por otro bloque válido.

¿Qué es un reorg profundo?

Es un reorg que sustituye muchos bloques y resulta más grave porque puede afectar a transacciones que los usuarios ya consideraban fiables.

¿Por qué las confirmaciones reducen el riesgo de reorg?

Cada confirmación añade otro bloque sobre la transacción, lo que hace más difícil o costoso sustituir el bloque que la contiene.

¿Cuántas confirmaciones son suficientes?

Depende de la cadena, el valor de la transacción, el modelo de finalidad y la tolerancia al riesgo.

¿Se pueden reorganizar los bloques finalizados?

En redes con finalidad económica o determinista, el diseño hace que reorganizar bloques finalizados resulte extremadamente costoso o prácticamente imposible si se cumplen los supuestos habituales.

¿Cómo afectan los reorgs a los bridges?

Un bridge puede perder respaldo o liberar activos incorrectamente si actúa basándose en una transacción de la cadena de origen que después se elimina mediante un reorg.

¿Cómo afectan los reorgs a las wallets?

Si el bloque que contiene una transacción se elimina mediante un reorg, una wallet puede cambiar su estado de confirmada a pendiente o descartada.

¿Cómo gestionan los reorgs los desarrolladores?

Los gestionan registrando hashes de bloques, esperando a que haya confirmaciones, admitiendo reversiones y aplicando reglas de finalidad específicas para cada cadena.

¿Cuál es el mayor error relacionado con los reorgs?

El mayor error es tratar una transacción recién incluida como irreversible antes de que alcance el nivel de confirmación o finalidad adecuado.

Conclusión

Un reorg, o reorganización de la cadena, es un evento blockchain en el que se sustituyen bloques aceptados recientemente por otra rama válida de la cadena.

Los reorgs pueden producirse de forma natural porque las redes descentralizadas necesitan tiempo para ponerse de acuerdo sobre los nuevos bloques.

También pueden deberse a ataques, al comportamiento de los validadores, a particiones de red, a errores de software o a incentivos económicos como el MEV.

El efecto práctico es que una transacción que parecía confirmada puede volver a estar pendiente, eliminarse o ser sustituida.

Por eso, las confirmaciones y la finalidad son fundamentales para la liquidación cripto.

Los sistemas de tipo Bitcoin dependen en gran medida de una mayor profundidad de confirmaciones, mientras que los sistemas Proof of Stake de tipo Ethereum combinan la elección de bifurcación con la finalidad económica.

Las wallets, los bridges, los procesadores de pagos, los indexadores, los exchanges y los protocolos DeFi necesitan estar diseñados para gestionar reorgs.

La conclusión práctica es sencilla: los reorgs forman parte del consenso descentralizado, por lo que los usuarios y desarrolladores deberían esperar a que haya suficientes confirmaciones o se alcance la finalidad antes de tratar las transacciones cripto como irreversibles.