---
title: "Reglas de elección de bifurcación: ramas válidas, peso y cabeceras canónicas"
description: "Una regla de elección de bifurcación transforma la vista local validada de un nodo en una cabecera canónica actual. Hay que analizar por separado validez, ascendencia, trabajo acumulado o peso de voto, checkpoints, tiempo, desempates, reorganización y finalidad."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Reglas de elección de bifurcación: ramas válidas, peso y cabeceras canónicas
> Análisis educativo del protocolo. La cabecera actual de un nodo depende de la red, versión de reglas, vista local validada, evidencia de peso, checkpoint y tiempo; no queda finalizada ni es segura para una liquidación irreversible por ese solo hecho.
## Respuesta directa
Una regla de elección de bifurcación es el procedimiento del protocolo que transforma la vista local validada de bloques y mensajes de consenso competidores en una cabecera canónica actual. Su salida es provisional y relativa al observador: dos nodos honestos pueden elegir brevemente cabeceras distintas porque recibieron otros bloques válidos, votos o eventos temporales. Cuando sus vistas admisibles convergen bajo los supuestos de red del protocolo, la regla también debe converger.
La elección de bifurcación no vuelve válido un bloque inválido. Las comprobaciones de transición de estado, autorización, prueba, ascendencia y disponibilidad de datos determinan primero qué candidatos son admisibles; después se compara el peso. La cabecera elegida tampoco está necesariamente finalizada. La elección identifica la rama que se debe extender ahora; una regla de finalidad puede proteger un ancestro más antiguo con evidencia de seguridad mayor. Sustituir la cabecera actual puede ser normal, mientras sustituir un checkpoint finalizado cruza otro límite del protocolo.
«Cadena más larga» no es una fórmula universal. Bitcoin selecciona la cadena válida con más trabajo acumulado: decide la prueba de trabajo esperada acumulada, no la altura bruta. LMD-GHOST de Ethereum parte de un checkpoint justificado, filtra las ramas viables y sigue de forma voraz al hijo con mayor saldo atestiguador de mensajes más recientes, más el refuerzo del proponente cuando corresponda; solo contribuye el último mensaje elegible de cada validador. Otros protocolos pueden usar certificados de disponibilidad, bloqueos del líder, rondas o certificados explícitos de commit, no una competencia persistente por la rama más pesada.
El resultado depende de entradas exactas: cadena y red, versión del fork, ancla de confianza, hora o slot actual, bloques válidos conocidos, enlaces padre, instantánea de trabajo o peso de voto, últimos mensajes, evidencia de equívoco, checkpoints justificado y finalizado, disponibilidad, tiempo del proponente y desempates deterministas. Un distintivo de explorador o un RPC es la observación de la salida de un nodo, no la regla ni una prueba independiente de sus entradas.
## Cómo analizar una regla de elección
1. **Fijar identidad y versión.** Registrar cadena, red, fork de consenso, versión del cliente, génesis o ancla confiable, altura o slot actual y regla exacta activa. No trasladar lógica de mainnet a testnet, sidechain, rollup o propuesta futura.
2. **Construir el grafo admisible.** Verificar hashes, padres, pruebas de consenso, transiciones, estado del payload y disponibilidad requerida. Marcar nodos desconocidos, optimistas, inválidos y podados; el peso no rescata una rama inválida.
3. **Reconstruir ascendencia y restricciones.** Hallar el ancestro común y confirmar qué candidatos descienden de checkpoints, bloqueos o certificados exigidos. Separar el árbol bruto observado del árbol filtrado que la regla considera.
4. **Reproducir cada entrada de peso.** En PoW, decodificar objetivos y sumar la prueba de cada bloque al chainwork acumulado. En reglas de voto, verificar identidad, saldo efectivo activo u otro peso, dominio, raíz objetivo, slot o epoch, sustitución del último mensaje, tratamiento del equívoco y refuerzo temporal.
5. **Ejecutar exactamente selección y desempate.** Aplicar la recursión o comparador indicado en cada bifurcación, con redondeo y orden determinista del protocolo. Registrar si el peso igual permite preferencia local temporal, sin fingir que el empate es acuerdo final.
6. **Conciliar cambios de cabecera.** Cuando cambia la ganadora, identificar bloques separados y añadidos, revertir y repetir estado, conciliar recibos, logs y mempool, y calcular profundidad desde el ancestro común. Distinguir head, safe, justified, committed y finalized.
7. **Someter a estrés y vigilar el sistema.** Probar bloques demorados u ocultos, particiones, votos obsoletos, equívoco, balanceo, tiempo del proponente, divergencia de clientes, checkpoints débiles y datos no disponibles. Comparar nodos independientes y alertar de divergencia, reorganización profunda o conflicto con estado finalizado antes de acciones irreversibles.
En Bitcoin Core actual, el orden de candidatos compara primero `nChainWork`; si el trabajo es igual, usa la secuencia activable más temprana y un desempate interno final. El campo RPC `blocks` es la altura de la cadena de mayor trabajo totalmente validada, y `bestblockhash` identifica su punta. En la especificación actual de Ethereum, `get_head(store)` parte de `justified_checkpoint`, recorre un árbol filtrado y en cada paso elige al hijo que maximiza `(get_weight(store, child), child.root)`. Son detalles específicos de protocolo y versión, no definiciones genéricas de consenso.
## Ejemplos calculados
### 1. Cambio por trabajo acumulado de Bitcoin
Dos ramas válidas comparten el ancestro `C`. Sus puntas tienen `chainwork(A)=240` y `chainwork(B)=235`, por lo que el nodo elige `A` aunque una vista superficial de alturas parezca similar. Un bloque válido nuevo añade trabajo `10` a B:
`chainwork(B') = 235 + 10 = 245`
Como `245 > 240`, B pasa a ser la candidata de mayor trabajo. El nodo desconecta los bloques de A posteriores a `C`, conecta B hasta `B'` y concilia las transacciones. El recuento bruto no basta si cambian los objetivos; igual trabajo es un empate temporal, no prueba de finalidad.
### 2. Subárbol observado más pesado y voraz
Use un árbol LMD-GHOST simplificado con raíz en el checkpoint justificado `J`. Sus hijos son `A` y `B`. Los últimos mensajes elegibles dan al subárbol entero de A peso `61` y al de B `39`, así que el primer paso elige `A`. Los hijos de A, `A_1` y `A_2`, pesan `34` y `27`; el siguiente paso elige `A_1`.
La cabecera se obtiene eligiendo repetidamente al hijo más pesado, no contando longitud ni escogiendo la hoja con más votos directos aislados. La regla real también contiene filtro de viabilidad, instantáneas de saldo, tratamiento de equívocos, tiempo del proponente y desempates omitidos en este árbol didáctico.
### 3. Sustitución del último mensaje
Suponga que los últimos mensajes elegibles dan inicialmente a A peso `55` y a B `45`. Un validador de peso `20` envía después un mensaje elegible más reciente en favor de un descendiente de B. La contabilidad de último mensaje quita su apoyo anterior de A y lo añade a B:
`A: 55 - 20 = 35; B: 45 + 20 = 65`
El peso se cuenta una vez, no en ambas ramas, por lo que la ruta elegida puede cambiar. Esto no autoriza votos contradictorios: si evidencia válida de attester slashing identifica un equívoco, el store actual de Ethereum rastrea al validador y excluye su peso de la puntuación ordinaria.
### 4. Filtro de checkpoint y refuerzo del proponente
Suponga que un nodo observa peso bruto de últimos mensajes `70` en una rama que contradice su checkpoint finalizado y `30` en un descendiente viable. La rama conflictiva se excluye antes de elegir cabecera; una mayoría bruta no puede superar la restricción de checkpoint mediante el fork choice ordinario.
Ahora dos hijos viables del slot actual tienen pesos de atestación `35` y `50`. En la configuración citada de Ethereum, un refuerzo oportuno equivale al `40%` del peso de un comité, no al 40 % del stake total. Si el comité pesa `100` y el refuerzo corresponde al hijo de 35, su puntuación es `35 + 40 = 75`, por lo que supera a `50` en ese paso. El refuerzo es temporal y propio del fork; no es otro voto ni finalidad.
## Riesgos y fallos de revisión
### Conjunto candidato y evidencia
- Comparar pesos antes de validar padres, transiciones, pruebas, estado del payload o datos requeridos.
- Tratar ejecución desconocida u optimista, datos no disponibles o vista solo de headers como estado plenamente validado.
- Sustituir el peso indicado por altura, timestamp, cantidad de transacciones, fees o popularidad del explorador.
- Sumar dificultad mostrada sin reproducir prueba por bloque y chainwork bajo los objetivos correctos.
- Contar todo voto histórico en vez del último mensaje elegible de cada validador con el snapshot correcto.
- Ignorar dominio, raíz, slot, epoch, puntualidad, firma, equívoco y evidencia de slashing.
- Comparar ramas brutas que filtros de checkpoint, bloqueo, certificado o disponibilidad hacen inelegibles.
- Aplicar una especificación futura, parámetro de otra red u optimización como ley de consenso actual.
### Fallos de selección y operación
- Describir Bitcoin como «mayor altura» bruta o Ethereum como simple voto de cabecera de dos tercios.
- Sustituir la recursión voraz del subárbol por una puntuación global de hojas u omitir refuerzo, redondeo y desempate de raíz.
- Suponer que nodos con distinto orden de llegada, reloj o mensajes deben informar la misma cabecera de inmediato.
- No desconectar y repetir correctamente estado, recibos, logs, índices y mempool durante una reorganización.
- Permitir que clientes diverjan en validez, viabilidad de checkpoints, últimos mensajes, tiempo o desempates.
- Omitir balanceo, ocultación, equívoco, partición, eclipse, votos demorados y reorganización del proponente.
- Confiar en un RPC, explorador, relay, familia de clientes, nube u operador como vista independiente del consenso.
### Desajuste de finalidad y aplicación
- Llamar finalizada, irreversible o segura a la cabecera elegida sin la evidencia separada de finalidad.
- Liberar depósitos, mensajes puente u operaciones irreversibles sobre una cabecera transitoria sin política por valor.
- Suponer que un ancestro finalizado garantiza corrección o disponibilidad de cada head, payload, oráculo o resultado nuevo.
- Usar una cuenta fija en cadenas con distintos modelos de trabajo, voto, checkpoint y recuperación.
- Tratar checkpoints de emergencia, anclas de subjetividad débil o recuperación social como entradas ordinarias sin confianza.
## Ideas erróneas comunes
- **Siempre gana la rama más larga.** El protocolo puede comparar trabajo acumulado, últimos mensajes ponderados, certificados u otra puntuación; la altura bruta no es universal.
- **La rama observada más pesada es válida automáticamente.** Validez y disponibilidad filtran candidatos antes de la selección por peso.
- **Fork choice y finalidad son la misma regla.** El primero elige la cabecera actual que extender; la segunda protege un ancestro con condiciones adicionales.
- **Cada voto permanece para siempre en el total.** En reglas de último mensaje, uno nuevo y elegible sustituye el apoyo anterior del validador.
- **Un explorador prueba la cadena canónica.** Solo informa la vista de una infraestructura; aún hacen falta validación y conciliación independientes.
## Temas relacionados
- [Reorganizaciones de cadena](/es/crypto/chain-reorg/)
- [Mecanismos de consenso](/es/crypto/consensus-mechanism/)
- [Ajuste de dificultad](/es/crypto/difficulty-adjustment/)
- [Finalidad](/es/crypto/finality/)
- [Subjetividad débil](/es/crypto/weak-subjectivity/)
## Fuentes
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulta: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consulta: 2026-08-19)
- [Bitcoin Core: validation.h](https://github.com/bitcoin/bitcoin/blob/master/src/validation.h) - Bitcoin Core (consulta: 2026-08-19)
- [Bitcoin Core: blockstorage.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/node/blockstorage.cpp) - Bitcoin Core (consulta: 2026-08-19)
- [Bitcoin Core RPC: getblockchaininfo](https://developer.bitcoin.org/reference/rpc/getblockchaininfo.html) - Bitcoin Project (consulta: 2026-08-19)
- [Ethereum Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (consulta: 2026-08-19)
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation (consulta: 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (consulta: 2026-08-19)
Source: https://wiki.fcontext.com/es/crypto/fork-choice-rule/index.mdx