Respuestas>Descubre los fundamentos de la seguridad de la cadena de bloques>¿Qué es una reorganización de la cadena de bloques?
¿Qué es una reorganización de la cadena de bloques?
// Tags
reorganización de la cadena de bloquesreorganización de la cadena
En resumen: Una reorganización de la cadena de bloques (abreviatura de «reorganización») se produce cuando cambia la cadena canónica de la red y los bloques que antes se consideraban parte de la cadena principal son sustituidos por un conjunto diferente de bloques. Esto puede provocar que desaparezcan transacciones confirmadas, que cambie el orden de las transacciones y que el estado de la aplicación se vuelva inconsistente. Las reorganizaciones se producen de forma natural en la mayoría de las cadenas de bloques debido a la latencia de la red y a la producción simultánea de bloques, pero las reorganizaciones profundas también pueden ser consecuencia de ataques o errores de software. Comprender las reorganizaciones es fundamental para cualquier desarrollador que cree aplicaciones que dependan de datos confirmados de la cadena de bloques, ya que no tenerlas en cuenta puede dar lugar a vulnerabilidades de doble gasto, transacciones fantasma y bases de datos dañadas.
La explicación sencilla
Imagina una cadena de bloques como un único sendero que atraviesa un bosque, en el que cada paso es un bloque. En condiciones normales, todo el mundo sigue el mismo camino. Pero, de vez en cuando, dos pioneros descubren rutas diferentes al mismo tiempo y, durante un breve periodo, coexisten dos caminos válidos. La red acaba decidiendo cuál es el camino correcto (normalmente el que se extiende más lejos primero) y todo el mundo se pasa a ese camino. Cualquiera que estuviera siguiendo el otro camino tiene que dar marcha atrás y cambiar de ruta.
Cuando se produce este cambio, se produce una reorganización. Los bloques de la ruta abandonada se descartan, y los bloques de la ruta ganadora pasan a formar la cadena canónica. Las transacciones que se encontraban en los bloques abandonados pueden aparecer o no en los bloques de la cadena ganadora. Algunas transacciones podrían acabar en ambas rutas en la misma posición. Otras podrían aparecer en una pero no en la otra. Unas pocas podrían descartarse por completo si entran en conflicto con transacciones de la cadena ganadora.
Para la mayoría de los usuarios finales, las reorganizaciones superficiales (de uno o dos bloques de profundidad) se producen con frecuencia y de forma imperceptible. Es posible que tu monedero muestre brevemente una transacción como confirmada y, a continuación, la vuelva a mostrar como pendiente durante unos segundos antes de que se vuelva a confirmar en el nuevo bloque canónico. Probablemente ni siquiera te darías cuenta. Sin embargo, para las aplicaciones que procesan datos de la cadena de bloques a gran escala, incluso una reorganización de un solo bloque significa que los registros que ya se habían escrito en tu base de datos basándose en los bloques antiguos ahora son incorrectos y deben corregirse.
La causa más habitual de las reorganizaciones es la latencia natural de la red. Cuando dos validadores producen bloques válidos aproximadamente al mismo tiempo (dentro del mismo slot o en la misma altura de bloque), es posible que diferentes partes de la red adopten temporalmente bloques distintos. El nodo A podría ver primero el bloque X y considerarlo canónico, mientras que el nodo B ve primero el bloque Y. Ambos bloques son válidos según las reglas de consenso, pero, en última instancia, solo uno puede formar parte de la cadena principal.
La red resuelve esta ambigüedad mediante su regla de elección de bifurcación. En Ethereum, la regla de elección de bifurcación (LMD-GHOST) selecciona la cadena respaldada por el mayor número de certificaciones de validadores. En Bitcoin, gana la cadena más larga (la que acumula más prueba de trabajo). Independientemente de la regla específica, el resultado es el mismo: una bifurcación se adopta como canónica y la otra se descarta. Los nodos que seguían la bifurcación descartada detectan el cambio, revierten los bloques huérfanos y adoptan la cadena ganadora.
En las cadenas de «Proof of Work» como Bitcoin, las reorganizaciones son relativamente habituales, ya que el proceso de minería es intrínsecamente probabilístico. Dos mineros pueden encontrar bloques válidos casi al mismo tiempo, lo que crea una bifurcación temporal que se resuelve en el plazo de uno o dos bloques. Las reorganizaciones de un solo bloque en Bitcoin ocurren con regularidad y se consideran una parte normal del funcionamiento de la red. Las reorganizaciones más profundas son poco frecuentes en condiciones de honestidad, pero se hacen posibles si un atacante controla una parte significativa del poder de hash de la red (la base de un ataque del 51 %).
En el sistema de Prueba de Participación (Proof of Stake) de Ethereum, el modelo de producción de bloques basado en slots reduce la frecuencia de las reorganizaciones naturales, ya que cada slot cuenta con un proponente designado. Sin embargo, las reorganizaciones pueden seguir produciéndose si el bloque de un proponente llega tarde (debido a la latencia de la red) y el siguiente proponente construye su bloque basándose, en su lugar, en el bloque canónico anterior. Las ranuras perdidas, en las que el proponente designado no consigue producir un bloque, también pueden crear las condiciones para que se produzcan reorganizaciones cortas cuando varios validadores construyen a partir de diferentes visiones de la cadena.
Tipos de reorganizaciones
Las reorganizaciones superficiales tienen una profundidad de entre uno y tres bloques y se producen de forma natural en la mayoría de las cadenas de bloques. Son una consecuencia normal del consenso distribuido y se resuelven por sí solas en cuestión de segundos. La mayoría de las aplicaciones pueden gestionar las reorganizaciones superficiales esperando unas cuantas confirmaciones de bloque adicionales antes de considerar los datos como definitivos.
Las reorganizaciones profundas tienen más de tres bloques de profundidad y suelen ser señal de algo anómalo: un ataque deliberado, un error de consenso o una partición significativa de la red. Una reorganización profunda en una cadena principal es un suceso grave, ya que puede revertir transacciones que los usuarios y las aplicaciones ya consideraban confirmadas. Las reorganizaciones profundas en cadenas más pequeñas con menor seguridad (menor potencia de hash o menor valor apostado) son más habituales y se han utilizado para llevar a cabo ataques de doble gasto.
Un ataque del 51 % (o del 34 % en algunas cadenas PoS) consiste en la creación deliberada de una reorganización profunda. Un atacante con poder de consenso mayoritario extrae o valida una cadena privada que difiere de la pública y, a continuación, la revela a la red. Dado que la cadena del atacante es más larga (o cuenta con más certificaciones), la red la adopta como canónica, dejando huérfanos los bloques recientes de la cadena pública. Esto permite al atacante revertir transacciones en la cadena abandonada, lo que podría dar lugar a un doble gasto de fondos que ya se habían enviado y confirmado.
Repercusiones en las aplicaciones
En el caso de las aplicaciones que procesan datos de blockchain, las reorganizaciones plantean un reto en cuanto a la coherencia de los datos. Si tu aplicación escribe registros de transacciones en una base de datos tan pronto como aparecen en un bloque, una reorganización implica que algunos de esos registros se basan ahora en bloques que ya no existen. Es posible que las transacciones sigan apareciendo en los nuevos bloques canónicos (aunque sea en una posición diferente o con un número de bloque distinto), o que hayan desaparecido por completo.
Las aplicaciones DeFi son especialmente vulnerables. Si un agregador de DEX muestra un intercambio como confirmado y actualiza la cartera del usuario, pero una reorganización elimina ese intercambio de la cadena canónica, la cartera ya no es correcta. Si un puente detecta un depósito en la cadena de origen y libera fondos en la cadena de destino, pero una reorganización elimina el depósito, el puente ha liberado fondos en base a una transacción que ya no existe. Este es uno de los principales vectores de ataque contra los puentes entre cadenas.
Los indexadores y los flujos de datos deben detectar las reorganizaciones, identificar qué bloques se han abandonado, revertir cualquier registro derivado de dichos bloques y volver a procesar los bloques canónicos correctos. Sin esta lógica, la base de datos indexada acumula registros fantasma procedentes de bloques huérfanos, lo que genera inconsistencias que se acentúan con el tiempo y corrompen los análisis, los saldos y los historiales de transacciones posteriores.
Cómo gestionar las reorganizaciones
La defensa más sencilla contra las reorganizaciones consiste en esperar a que se alcance la finalidad antes de considerar los datos como confirmados. En Ethereum, la firmeza se produce tras dos épocas (aproximadamente 12-13 minutos), tras las cuales los bloques no pueden revertirse sin destruir al menos un tercio de todo el ETH apostado. En Bitcoin, seis confirmaciones (aproximadamente 60 minutos) es el estándar ampliamente aceptado para la firmeza económica. En Solana, la firmeza en una sola ranura significa que las transacciones confirmadas son efectivamente definitivas en unos 400 milisegundos.
En el caso de las aplicaciones que no pueden permitirse esperar a que se alcance la firmeza total (porque los usuarios esperan una respuesta más rápida), la mejor práctica consiste en mostrar los datos como «sin confirmar» o «pendientes» hasta que se hayan producido suficientes confirmaciones, y en implementar una lógica de reversión que gestione de forma adecuada el caso en el que una transacción recientemente confirmada sea revertida por una reorganización.
Los flujos de datos deben procesar los bloques en orden de finalidad siempre que sea posible. En lugar de incorporar los bloques en el momento en que aparecen en la punta de la cadena (lo que conlleva el riesgo de procesar bloques que más tarde podrían quedar huérfanos), los flujos deben almacenar en búfer los bloques recientes y procesarlos únicamente una vez que hayan alcanzado una profundidad de confirmación segura. En los casos de uso en tiempo real en los que el almacenamiento en búfer no sea aceptable, el flujo debe incluir mecanismos explícitos de detección de reorganizaciones y de reversión.
¿Cuál es la diferencia entre una reorganización y una bifurcación?
Las reorganizaciones y las bifurcaciones están relacionadas, pero no son lo mismo. Una bifurcación es cualquier punto en el que la cadena se divide en dos ramas que compiten entre sí, lo cual puede ser temporal (dos bloques válidos a la misma altura) o permanente (una actualización del protocolo que crea una nueva cadena). Una reorganización es, concretamente, lo que ocurre cuando los nodos abandonan una rama y se pasan a otra tras resolverse una bifurcación temporal. En otras palabras, una bifurcación temporal es la causa y una reorganización es la consecuencia en los nodos que respaldaban la rama perdedora.
Aspecto
Reorganización
Tenedor
Definición
Los nodos sustituyen los bloques canónicos por una rama alternativa
La cadena se divide en dos o más ramificaciones
Disparador
Una bifurcación temporal se resuelve a favor de otra rama
Bloques simultáneos, un error o una actualización del protocolo
Permanencia
Siempre es temporal; se descarta una rama
Puede ser temporal o permanente
Repercusión en los datos
Las transacciones confirmadas pueden cambiar de lugar o desaparecer
Puede crear una cadena independiente y duradera
Para conocer más a fondo los diferentes tipos de bifurcaciones, consulta qué es una «bifurcación en cadena». Las reorganizaciones también están estrechamente relacionadas con el orden de las transacciones, ya que este puede cambiar cuando se produce un cambio de rama canónica.
¿Cuántas confirmaciones protegen contra una reorganización?
El número seguro de confirmaciones depende del diseño del consenso de la cadena y de la cantidad de valor que esté en juego. Un mayor número de confirmaciones implica que se necesitaría una reorganización más profunda para revertir la transacción, lo que resulta exponencialmente más costoso para un atacante. La tabla siguiente resume las directrices habituales para considerar los datos como definitivos.
Cadena
Umbral común de finalidad
Tiempo aproximado según el reloj de pared
Bitcoin
6 confirmaciones
~60 minutos
Ethereum
2 épocas (finalizadas)
~entre 12 y 13 minutos
Solana
Finalidad de una sola ranura
~400 milisegundos
Cadenas PoW más pequeñas
Muchas más confirmaciones
Varía; mayor riesgo de reorganización
Esperar a que se alcance la finalidad de la cadena de bloques es la protección más sólida, mientras que las redes más pequeñas o menos seguras necesitan mayores profundidades de confirmación, ya que su riesgo de reorganización es mayor. La fiabilidad de la infraestructura también es importante en este sentido: descubre por qué la fiabilidad de los nodos es fundamental para obtener datos coherentes que tengan en cuenta la reorganización.
¿Puede una reorganización de la cadena de bloques constituir un ataque?
La mayoría de las reorganizaciones son inofensivas y se resuelven en uno o dos bloques, pero una reorganización profunda diseñada deliberadamente constituye un ataque. Al crear en privado una cadena competidora y luego lanzarla, un atacante con suficiente poder de consenso puede dejar huérfanos los bloques recientes y revertir transacciones que parecían confirmadas, lo cual es el mecanismo que subyace a los ataques de doble gasto y del 51 %. Las reorganizaciones también se solapan con las estrategias de extracción de beneficios, por lo que comprender qué es el MEV y analizar los modos de fallo habituales de las cadenas de bloques ayuda a los equipos a diseñar sistemas que fallen de forma segura cuando una reorganización sea maliciosa, en lugar de natural.
Preguntas frecuentes
¿Son normales las reorganizaciones de la cadena de bloques?
Las reorganizaciones superficiales de uno a tres bloques forman parte del consenso distribuido y se producen de forma habitual, sobre todo en las cadenas de Prueba de Trabajo. Por lo general, se resuelven en cuestión de segundos y la mayoría de los usuarios ni siquiera se dan cuenta. Las reorganizaciones profundas, por el contrario, son anormales y suelen indicar un ataque o un error.
¿Desaparecen las transacciones confirmadas durante una reorganización?
Sí, pueden. Una transacción en un bloque huérfano puede reaparecer en la nueva cadena canónica en una posición diferente, o puede descartarse por completo si entra en conflicto con la rama ganadora. Por eso las aplicaciones deben esperar a obtener un número suficiente de confirmaciones antes de considerar una transacción como definitiva.
¿Qué blockchains tienen más reorganizaciones?
Las cadenas de «Proof of Work» y las redes más pequeñas, con menor potencia de hash o menor valor en staking, sufren reorganizaciones con mayor frecuencia. Bitcoin registra ocasionalmente reorganizaciones de un solo bloque, mientras que las cadenas con menor seguridad están más expuestas a reorganizaciones más profundas y potencialmente maliciosas.
¿Cómo gestionan los indexadores las reorganizaciones?
Un indexador compatible con la reorganización detecta la bifurcación, identifica qué bloques se han descartado, revierte cualquier registro derivado de ellos y vuelve a procesar los nuevos bloques canónicos. Sin esta lógica, la base de datos acumula registros fantasma que, con el tiempo, alteran los saldos y los análisis.
¿Evita esperar a que se alcance la firmeza los problemas de reorganización?
Sí. Una vez que un bloque alcanza la finalidad, no puede revertirse sin un coste económico extremadamente elevado, por lo que los datos vinculados a los bloques finalizados están a salvo de las reorganizaciones. La contrapartida es la latencia, razón por la cual algunas aplicaciones muestran datos no confirmados y reservan las acciones irreversibles para los datos finalizados.
Cómo gestiona « Quicknode » las reorganizaciones
Quicknode Streams Está diseñado con una gestión de reorganizaciones integrada en su arquitectura central. Streams entrega los datos de la cadena de bloques en orden de finalidad, lo que significa que los bloques se procesan y entregan únicamente después de haber alcanzado una profundidad de confirmación segura en la red. Cuando se produce una reorganización, Streams detecta automáticamente la bifurcación, identifica qué bloques entregados ya no son canónicos y envía cargas útiles de corrección a tu destino para que tus datos se mantengan coherentes con el estado real de la cadena.
Esta gestión integrada de las reorganizaciones elimina uno de los retos de ingeniería más complejos en el procesamiento de datos de blockchain. En lugar de incorporar en tu flujo de trabajo una detección de reorganizaciones, una lógica de reversión y una conciliación de bloques personalizadas, basta con configurar un Stream y « Quicknode » se encarga del resto. Tanto si estás desarrollando un indexador, una plataforma de análisis o un sistema de monitorización en tiempo real, « Streams » garantiza que los datos de tu destino coincidan con la cadena canónica, incluso durante las reorganizaciones de la red.
QuicknodeLa API principal también permite consultar tanto los datos de los bloques más recientes como los de los bloques finalizados en todas las redes compatibles, lo que permite a tu aplicación elegir el nivel de confirmación adecuado para cada caso de uso. Muestra el bloque más reciente a los usuarios que deseen una respuesta inmediata, pero recurre a los datos de los bloques finalizados para cualquier lógica que implique decisiones financieras o acciones irreversibles.
