Finalidad, bifurcaciones y reorganizaciones

Por qué esta lección vuelve a tratar la finalidad

El Módulo 1 presentó la finalidad como una pregunta práctica: ¿cuándo puede un usuario o una institución considerar liquidada una transferencia registrada? Esta lección desarrolla los mecanismos de consenso subyacentes, en lugar de repetir esa perspectiva introductoria. Una cadena de bloques puede contener bloques propuestos recientemente cuya posición todavía puede cambiar. Distintos participantes pueden construir temporalmente sobre historiales válidos diferentes, pero el protocolo necesita una regla para converger en una rama aceptada. La finalidad describe la solidez y la naturaleza de la garantía de que un historial determinado seguirá siendo aceptado. La elección de rama, los umbrales de votación y la acumulación de trabajo explican por qué la confianza cambia con el tiempo.

Una distinción esencial es la que existe entre una transacción observada, una transacción incluida y una transacción finalizada. Una transacción observada se ha anunciado a una parte de la red. Una transacción incluida aparece en un bloque propuesto o aceptado. Una transacción finalizada está protegida por la condición de liquidación más sólida que establece el sistema, si es que el sistema define alguna. Estos términos no significan que un banco, tribunal, registro o agencia correspondiente haya completado todos los procedimientos externos. Incluso después de la finalización del protocolo, todavía pueden existir correcciones administrativas o recursos legales fuera de la estructura de datos de la cadena de bloques.

Qué causa una bifurcación

Se produce una bifurcación cuando distintos bloques o historiales se extienden desde un punto común, o cuando las comunidades adoptan reglas de protocolo diferentes. No se deben agrupar estas situaciones. Una bifurcación temporal de bloques puede surgir de forma natural porque los mensajes tardan en propagarse: se proponen dos bloques válidos para la misma posición antes de que todos los nodos conozcan ambos. También puede producirse una bifurcación del protocolo por cambios de software que alteran qué bloques consideran válidos los participantes. En este último caso, las diferencias en los conjuntos de reglas pueden persistir, en lugar de resolverse mediante la selección habitual de una rama. Una descripción de nivel formativo debe especificar qué significado de bifurcación se pretende.

Una reorganización, a menudo abreviada como reorg, ocurre cuando un nodo cambia la cabeza de cadena que ha seleccionado por otra rama válida, de acuerdo con las reglas de elección de rama del protocolo. Es posible que los bloques que antes estaban en la rama seleccionada ya no formen parte de ella. Las transacciones incluidas en esos bloques pueden tener varios resultados: algunas se vuelven a incluir en la rama alternativa, algunas siguen siendo aptas para su inclusión posterior y otras dejan de ser válidas por transacciones incompatibles o por cambios de estado. Por lo tanto, una reorganización no significa que todas las transacciones afectadas desaparezcan para siempre, ni necesariamente demuestra que alguien haya atacado la red.

Una cronología ilustrativa

En el primer momento, los nodos coinciden en el bloque P. Más adelante, se construyen dos propuestas, A1 y B1, sobre P. Algunos nodos seleccionan inicialmente la rama que pasa por A1 porque la encontraron primero o porque, temporalmente, satisface los criterios locales de elección de rama. En el segundo momento, la rama que pasa por B1 acumula suficiente peso definido por el protocolo para ser preferida. Los nodos que habían seleccionado A1 se reorganizan y pasan a la rama B. Revierten los cambios de estado asociados con los bloques retirados y aplican los bloques de reemplazo en la secuencia correspondiente. El procesamiento interno preciso depende del protocolo, pero el resultado conceptual es un nuevo historial canónico.

Confianza probabilística en la prueba de trabajo

En una red típica de prueba de trabajo, la cantidad acumulada de trabajo válido que respalda una rama aumenta a medida que se construyen bloques adicionales sobre ella. Una transacción obtiene confirmaciones cuando se añaden bloques después del que la incluye, aunque los métodos de conteo varían; algunas interfaces consideran que el bloque inicial es la primera confirmación. A medida que se acumula más trabajo, por lo general se vuelve más difícil reemplazar la rama de esa transacción, bajo ciertos supuestos sobre la proporción de tasa de hash que controla el atacante y el comportamiento de los mineros competidores. Esta es una confianza probabilística, no una promesa matemática explícita de que la reversión sea imposible después de un número exacto de confirmaciones.

El número de confirmaciones no debe considerarse al margen del modelo de seguridad de la red. Importa si el nodo validó por completo los bloques pertinentes, si la red está experimentando reorganizaciones inusuales y si un adversario puede controlar recursos computacionales sustanciales. Distintos destinatarios pueden elegir umbrales operativos diferentes para acciones que implican distintos riesgos. Un número estandarizado puede resultar práctico para procedimientos internos, pero no es una ley de la naturaleza. El documento original de Bitcoin analiza este modelo de cadena basado en el trabajo; NIST IR 8202 también explica el consenso y las bifurcaciones sin sugerir que los enlaces hash por sí solos impidan todas las reorganizaciones.

Finalidad explícita en algunos sistemas de prueba de participación

Algunos protocolos de prueba de participación (PoS) añaden un proceso en el que los validadores dan fe o votan por puntos de control y, una vez alcanzado un umbral, marcan como finalizado el historial anterior. Un punto de control es una posición de la cadena identificada especialmente y utilizada para tomar decisiones de consenso. En el diseño Casper FFG de Ethereum, los puntos de control justificados y enlazados pueden conducir a la finalización, sobre la base de una votación de una supermayoría de la participación. Se pretende que revertir un bloque finalizado resulte extraordinariamente costoso, ya que una finalización en conflicto requeriría incumplimientos graves de los supuestos y sanciones para los validadores pertinentes. Otras redes PoS implementan umbrales, votos o terminología distintos; algunas no ofrecen en absoluto una finalidad explícita comparable.

La finalidad explícita no significa que un dispositivo o una institución pueda dejar de supervisar después de recibir un mensaje favorable. Un observador necesita datos precisos de los nodos, comprender la regla de finalidad y contar con protección razonable contra fuentes de información deshonestas o comprometidas. Durante un incidente de red, la finalización puede detenerse mientras se siguen proponiendo bloques, o los clientes de software pueden discrepar temporalmente sobre un estado. Los operadores deben distinguir entre «finalidad retrasada» e «historial finalizado previamente revertido». El primer caso puede ser un problema de disponibilidad o vitalidad; el segundo plantea una cuestión sustancialmente diferente sobre los supuestos de seguridad de un protocolo o su implementación.

La elección de rama puede cambiar antes de la finalidad

En diseños que combinan la elección de rama con la finalidad de los puntos de control, la cabeza de la cadena puede cambiar mientras el último punto de control finalizado sigue siendo el mismo. Es fácil pasar por alto esa distinción si un panel muestra únicamente la altura del bloque más reciente. La punta preferida es una vista operativa del progreso reciente; el punto de control finalizado es el límite de consenso más sólido. Una transacción cerca de la punta puede estar incluida, pero aún no protegida por la finalidad. Para una institución que espera actualizar otro sistema, registrar ambos estados puede evitar que un paso inicial del flujo de trabajo se confunda con una liquidación completada.

Los cambios en las reglas del protocolo son un fenómeno aparte

Por lo general, una bifurcación suave (soft fork) endurece las reglas de validez de una manera que pretende preservar ciertas propiedades de compatibilidad para los nodos que aplican reglas anteriores. Una bifurcación dura (hard fork) introduce cambios que no son compatibles con versiones anteriores según las reglas de validación pertinentes. Estas descripciones simplificadas son habituales, pero no deben utilizarse para inferir el resultado de gobernanza de cada actualización. Los participantes de la red pueden elegir distintos programas, los mineros o validadores pueden señalar sus preferencias y las organizaciones pueden comunicarse con sus comunidades. La compatibilidad del protocolo, la coordinación comunitaria, los identificadores legales y los nombres de mercado son cuestiones diferentes. Una actualización controvertida puede producir historiales duraderos; una actualización rutinaria puede no hacerlo.

Los responsables deben evitar tratar todo elemento etiquetado como «bifurcación» como evidencia de un incidente de seguridad. Un cambio de ingeniería puede ser planificado, mientras que una rama competidora de corta duración puede ser previsible en una red descentralizada. Por el contrario, una reorganización profunda e inesperada puede justificar una investigación urgente. La primera pregunta adecuada es qué cambió: ¿el orden de los bloques bajo las mismas reglas o el conjunto de reglas que aceptan los participantes? Los distintos cambios requieren respuestas, registros y comunicaciones diferentes para los usuarios.

Supervisión y decisiones institucionales

Un plan de supervisión operativa puede hacer seguimiento de la cabeza de cadena seleccionada, la última altura o ranura validada por completo, el punto de control finalizado más reciente cuando corresponda, la profundidad observada de las reorganizaciones, la participación de los validadores o el trabajo de la red, y las discrepancias entre fuentes de información independientes. El plan de supervisión debe definir con precisión qué significa cada métrica. También debe distinguir las fallas del software cliente de los resultados del consenso. Una alerta que indique «bloque reemplazado» puede ser rutinaria en ciertas circunstancias, mientras que «punto de control finalizado revertido» implicaría un alejamiento mucho más grave de lo esperado en sistemas que afirman ofrecer esa propiedad.

Por ejemplo, una agencia podría registrar pagos entrantes antes de permitir un servicio dependiente. Sus controles podrían exigir que una transacción incluida se observe de forma independiente, que la red alcance su condición de aceptación documentada y que el sistema conserve evidencia del estado en el momento de tomar la decisión. Si la transacción deja de aparecer después en el historial seleccionado, el flujo de trabajo necesita una vía de excepción predefinida. La respuesta correcta depende de las facultades legales de la agencia, los acuerdos contractuales y su tolerancia al riesgo operativo; el consenso define la evidencia técnica, pero no proporciona la política completa de decisión de la institución.

Corrección de ideas erróneas comunes

Una cadena enlazada mediante hashes no es automáticamente inmune a las reorganizaciones. Una regla de «seis confirmaciones» no es universal para todas las redes ni todos los casos de uso. La finalidad explícita no es lo mismo que un resultado instantáneo e irrevocable en términos legales. Una bifurcación no siempre crea un activo o protocolo separado y permanente. Un explorador de bloques es un servicio de información, no una garantía independiente del consenso. Estas advertencias importan porque los términos que parecen definitivos suelen resumir afirmaciones condicionales. Una explicación útil especifica la cadena, la regla de elección de rama, la regla de finalidad, el método de observación y cualquier supuesto significativo.

Referencia rápida

Qué deben retener los estudiantes

El consenso debe resolver los desacuerdos temporales sobre historiales de bloques válidos que compiten entre sí. La reorganización describe el proceso por el que un nodo adopta otra rama aceptada y aplica el estado correspondiente. La prueba de trabajo (PoW) suele ofrecer una confianza probabilística creciente mediante la acumulación de trabajo; algunos diseños de prueba de participación ofrecen finalidad económica explícita mediante votación. Las bifurcaciones causadas por la producción simultánea de bloques son distintas de las actualizaciones de las reglas del protocolo. La pregunta operativa no es simplemente si una transacción aparece en una pantalla, sino qué condición técnica se ha alcanzado y qué puede hacer responsablemente la organización con esa evidencia.

Enfoque del examen: Distinguir las bifurcaciones causadas por bloques competidores de las bifurcaciones de reglas del protocolo; explicar las reorganizaciones y cómo afectan al estado de las transacciones; y comparar la confianza probabilística con la finalidad de los puntos de control definida por el protocolo, sin describir ninguna de las dos como una garantía legal incondicional.

Notas sobre las fuentes

Referencias pertinentes: NIST IR 8202 (2018), Blockchain Technology Overview, secciones sobre consenso y bifurcaciones; Satoshi Nakamoto (2008), Bitcoin: A Peer-to-Peer Electronic Cash System; y documentación de Ethereum sobre prueba de participación, elección de rama y finalidad.