¿Qué es un reorg?

¿Qué es un reorg?

Una reorganización de cadena, o "reorg," ocurre cuando los validadores no coinciden en cuál es la versión más precisa de la blockchain. Los reorgs ocurren cuando múltiples bloques se producen al mismo tiempo, si hay un bug, o debido a un ataque malicioso. Los reorgs eliminan la blockchain duplicada más débil. Mientras más dura un reorg, más costoso se vuelve manejarlo.

Los reorgs de blockchain resultan en que un bloque se elimine de la blockchain debido a que se ha creado una cadena más larga. Esto a su vez resulta en que diferentes mineros trabajen simultáneamente agregando bloques de transacciones con dificultad similar a la cadena.

Esto ocurre porque el minero que agrega el siguiente bloque tiene que decidir qué lado del fork es la cadena correcta o canónica. Una vez que los mineros o validadores han elegido el fork o cadena canónica, la otra cadena se pierde.

Un ataque de reorganización se refiere a nodos que reciben bloques de una nueva cadena mientras la cadena antigua sigue existiendo. En este caso, la cadena se dividiría y crearía un fork, o una versión duplicada de la blockchain.

¿Qué causa un reorg de blockchain?

Un reorg de blockchain ocurre cuando dos bloques se publican al mismo tiempo. Los reorgs cortos de uno o dos bloques ocurren frecuentemente debido a la latencia de red, pero cuando los reorgs se extienden por más de uno o dos bloques, pueden llevar a ataques maliciosos o incluso a fallas de la red.

¿Cuáles son las consecuencias de las reorganizaciones de cadena?

Hay cuatro consecuencias principales de las reorganizaciones de cadena: retrasos y mala experiencia de usuario, costos de nodos, incertidumbre, y vulnerabilidad a ataques.

1. Retrasos y peor experiencia de usuario

Junto con el aumento de costos de nodos, los reorgs aumentan la probabilidad de transacciones retrasadas. Este es un problema significativo para los exchanges porque dependen de que las transacciones se confirmen a tiempo, o pueden sufrir las consecuencias de esperar más tiempo por un depósito.

2. Costos de nodos

Los reorgs pueden aumentar el número de nodos dentro de una blockchain con el tiempo, causando una peor experiencia de usuario. Al transicionar a un nuevo fork, las actualizaciones de estado implican más costos de memoria y disco.

3. Incertidumbre

Cuando los reorgs son prominentes, los usuarios tienen menos garantías de que las transacciones se ejecutarán a tiempo. Sin suficiente contexto, las transacciones DeFi tendrían resultados mucho peores y también llevarían a una extracción dañina de MEV.

4. Vulnerabilidad a ataques

Cuando el reorging se vuelve más común, los atacantes solo necesitan superar a una porción de los mineros honestos (debido a la "regla de la cadena más larga") en lugar de a todos. Un mayor número de reorgs facilita mucho el rol del atacante.

¿Qué es la cadena canónica?

La cadena canónica es la "cadena principal" acordada. Por lo tanto, no se considera una de las sidechains que terminan.

En teoría, la red nunca está 100% segura de cuál es la cadena canónica. Esto se debe a que aún podrías revertir el bloque número 1 continuando sus side-chains con suficiente poder de hashing.

¿Qué es un fork?

Un fork ocurre cuando una comunidad hace un cambio al protocolo o conjunto básico de reglas de la blockchain y efectivamente divide (o "forkea") la cadena en una nueva cadena que seguirá las nuevas reglas, y una antigua que se vuelve mayormente obsoleta.

Debido a que blockchains como Bitcoin y Ethereum están impulsadas por software descentralizado y de código abierto, y son mantenidas por miembros de la comunidad con intereses en la red, los participantes de la red pueden proponer y votar cambios al software.

¿Qué es la regla de elección de fork?

Una regla de elección de fork es una función que toma como input el conjunto de bloques y otros mensajes que se han visto, y le indica al cliente cuál es la "cadena canónica".

Los forks ocurren cuando múltiples bloques publicados hacen referencia al mismo estado anterior. Una blockchain puede enfrentar tal evento por accidente si dos bloques se publican aproximadamente al mismo tiempo, o puede ocurrir a propósito, como si un actor malicioso estuviera intentando crear un fork para "eliminar" un pago de la cadena.

En cualquier caso, tiene que existir algún mecanismo que permita a los usuarios determinar cuál fork es el correcto o "canónico". Esto se conoce como una "regla de elección de fork."

Las reglas de elección de fork son necesarias porque podría haber múltiples cadenas válidas entre las cuales elegir. Esto es posible cuando hay dos bloques en competencia con las mismas cadenas padre publicándose al mismo tiempo.

Por ejemplo, "la cadena válida más larga gana" sería una regla de elección de fork simple que se alinea con el mecanismo de Proof-of-Work. Podemos definir una regla de elección de fork que permita que una blockchain sirva como mecanismo de propuesta para un algoritmo de consenso. Estas tendrían las propiedades descritas por Vitalik Buterin.

Aquí hay tres reglas de elección de fork mostradas en este cuadro:

1. Nakamoto
2. GASPER
3. Tendermint

¿Qué es la finalidad?

La finalidad es la garantía completa de que una transacción cripto no podrá ser alterada, revertida, o cancelada de ninguna manera después de completarse. La finalidad depende de la latencia de la blockchain misma. La finalidad se usa frecuentemente para medir el tiempo necesario de espera para tener la garantía de que una transacción se ejecutará.

¿Qué le pasa a un reorg en Ethereum?

Ethereum actualmente usa un mecanismo de consenso Proof-of-Work. Ethereum usa una regla de elección de fork llamada "regla de la cadena más larga," lo que significa que cuando a un cliente se le muestran dos blockchains, elige la que tenga mayor dificultad. Esto se hace comparando la suma de dificultad de todos los bloques dentro de la cadena misma.

La Ethereum Beacon Chain experimentó recientemente un reorg que podría llevar a riesgos de seguridad potenciales. The Beacon Chain introduce el staking nativo, que es el componente principal del modelo de consenso Proof-of-Stake que Ethereum ha adoptado. El reorg dentro de Ethereum duró siete bloques, lo cual es uno de los reorgs más largos en años.

Martin Köppelmann, el CEO y cofundador de Gnosis, fue una de las personas que tuiteó lo que había observado dentro de este reorg de siete bloques.

Un reorg de siete bloques significa que ocurrió un fork y se descartaron siete bloques que contenían cientos de transacciones. Esto llevó al riesgo de que un usuario pudiera gastar los mismos activos dos veces. Un reorg de 2-3 bloques podría ser simplemente una señal de mala suerte, ya que las blockchains suelen enfrentar latencia de red. Este podría ser el caso también para la Beacon Chain.

Dado que los reorgs de cinco bloques o más son una señal potencial de un ataque malicioso, el reciente reorg de Ethereum parece haber sido un evento de baja probabilidad que no fue malicioso, según los desarrolladores.

Vitalik Buterin dijo en una respuesta oportuna que podría deberse a versiones desactualizadas del software de minería. Preston Van Loon, un desarrollador principal de Ethereum, dijo que el reorg de la blockchain Beacon fue causado por el despliegue de la decisión de fork Proposer Boost, que aún no se había desplegado completamente en la red.

Proposer boosting fue introducido para dar más peso a los bloques propuestos que se reciben de manera oportuna. Proposer boosting fue introducido para resolver el problema de los reorgs ex-ante.

En esencia, los validadores que tenían proposer boosting habilitado hicieron que la cadena inferior se convirtiera en la cadena canónica, pero los validadores que no tenían proposer boosting eligieron en cambio la cadena más corta, la superior. Esto lleva a que cada cadena continúe acumulando votos de sus respectivos validadores.

Además, esta reorganización es una segmentación no trivial entre software de cliente actualizado y desactualizado. El reorg en sí no fue una señal de una mala elección de fork.

Los validadores en la Ethereum Beacon Chain se desincronizaron después de que una actualización de cliente elevó a clientes específicos. Durante el proceso, los validadores en la red blockchain se confundieron y no actualizaron sus clientes, causando el fork que resultó en el reorg de siete bloques.

El problema no habría ocurrido si todos los validadores estuvieran ejecutando la misma configuración.

¿Qué pasa con los reorgs después del merge?

La dificultad de reorganizar seguirá aumentando lentamente con el tiempo. Sin embargo, a medida que la Ethereum Beacon Chain implementa Proof-of-Stake, introducirán la regla de elección de fork llamada Gasper.

La regla de elección de fork Gasper haría que atacar la blockchain de Ethereum sea extremadamente difícil, ya que se introducen los votos y attestations de los attesters, dándole "peso" a un bloque.

Controlar a los attesters significa controlar la regla de elección de fork. Esto hace que los reorgs de un solo bloque sean más difíciles, ya que los ataques a solo unos pocos validadores controladores tendrían que competir con varios miles de attesters.

¿Qué son los proposers y attesters?

Proposers y Attesters son dos roles importantes en la regla de elección de fork Gasper: los Proposers son validadores encargados de proponer un nuevo bloque cada 12 segundos en un "slot," y los Attesters son validadores que votan sobre lo que consideran la cabeza de la cadena canónica.

Generalmente se selecciona aleatoriamente a un validador Proposer, elegido como parte de un comité de aproximadamente 1/32 de todos los validadores. Dentro de este comité, también hay Attesters.

Los votos de los Attesters se llaman attestations y le dan "peso" al bloque, lo que significa que controlar a los attesters también otorga la capacidad de controlar la regla de elección de fork.

Dado que los comités se eligen aleatoriamente, compuestos por Proposers y Attesters, no hay manera de que los atacantes concentren a sus validadores en un slot específico.

¿Problema post-merge?

En general, el reorging se convertirá en una preocupación menor, ya que poder reorganizar un bloque como un solo attester o un grupo pequeño de ellos se volverá cada vez más difícil. Además, los desarrolladores de Ethereum pueden hacer cambios a la regla de elección de fork para aumentar los requisitos para los reorgs o encontrar una solución para avanzar hacia un consenso de finalidad de slot único. El consenso de finalidad de slot único mejoraría la experiencia de usuario, crearía mejor resistencia a reorgs por MEV, y reduciría la complejidad y los bugs del protocolo.