---
title: "Consenso de Nakamoto: validez, trabajo de cadena, confirmaciones y reorganizaciones"
description: "El consenso de Nakamoto combina reglas de validez aplicadas de forma independiente, producción de bloques por prueba de trabajo sin permisos, propagación y selección de la cadena válida con más trabajo acumulado. Analiza por separado las vistas locales, el trabajo de cadena, las confirmaciones, las reorganizaciones, el prefijo común, los incentivos y los ataques de red."
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.
# Consenso de Nakamoto: validez, trabajo de cadena, confirmaciones y reorganizaciones
> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
## Respuesta directa
El consenso de Nakamoto es el proceso de Bitcoin en el que los nodos aplican de forma independiente las reglas de validez, los productores de prueba de trabajo extienden bloques sin una lista de miembros autorizados, los bloques se propagan por una red entre pares y cada nodo elige la rama válida con más prueba de trabajo acumulada. Ordena transacciones válidas según la vista observada por el nodo; no vuelve válida una transacción inválida, no determina hechos externos al registro ni crea finalidad determinista inmediata.
La validez precede a la selección de cadena. Una rama con cabecera, prueba de trabajo, transacción, script, salida gastada, importe coinbase o límite de bloque inválido se rechaza, sin importar la altura o el trabajo que afirme tener. Entre ramas que cumplen las reglas del nodo y cuyos datos están disponibles, el trabajo acumulado de cadena, no el número de bloques por sí solo, determina la cadena activa. “Cadena más larga” es una abreviatura informal de la cadena válida que representa más esfuerzo de prueba de trabajo.
La punta activa es provisional. Bloques válidos rivales pueden dar temporalmente vistas locales distintas a nodos honestos bien conectados; el trabajo adicional suele resolver el fork y un nodo puede desconectar una rama y conectar otra en una reorganización. Las confirmaciones de una transacción miden su profundidad en la cadena activa actual del observador. Más profundidad puede reducir la probabilidad de alcance bajo un modelo de hashrate y red especificado, pero ninguna cantidad de confirmaciones es universalmente final.
El término abarca más que el hashing. Su argumento de seguridad también depende de la validez de bloques y transacciones, la propagación entre pares, la adopción honesta de la cadena válida de mayor trabajo, suficiente potencia minera efectiva honesta, conducta económica y usuarios que observan de forma independiente la red y el software previstos. Prefijo común, crecimiento de cadena y calidad de cadena son propiedades formales demostradas solo bajo modelos declarados, no hechos incondicionales de toda cadena de prueba de trabajo desplegada.
## Cómo analizar el consenso de Nakamoto
1. **Fijar identidad y alcance de observación.** Registra `chain`, `network`, `genesis hash`, `client version`, reglas de consenso, checkpoints o ajustes assume-valid, observador, pares y hora. Captura `bestblockhash`, `height` y `chainwork`; dos nodos pueden informar honestamente puntas distintas mientras se propagan mensajes.
2. **Validar antes de comparar trabajo.** Verifica enlace de cabeceras, restricciones temporales, objetivo decodificado, prueba de trabajo, compromisos Merkle y witness, transacciones, scripts, gastos UTXO, coinbase y límites de recursos. Una rama `invalid` no es elegible por afirmar mayor altura o trabajo.
3. **Reconstruir el árbol observado.** Enlaza cada candidato por el hash del bloque anterior a un ancestro conocido y separa bloques completos de cabeceras. Concilia los estados `active`, `valid-fork`, `valid-headers`, `headers-only` e `invalid` mediante interfaces como `getchaintips`; no llames cadena rival válida a toda punta visible.
4. **Recalcular el trabajo acumulado.** Decodifica el objetivo `nBits` de cada cabecera y calcula el trabajo representado con las reglas enteras de la implementación, conceptualmente `work = floor(2^256 / (target + 1))`. Suma por ascendencia y compara ramas válidas desde su ancestro común; altura, hashrate estimado y etiquetas de pools no sustituyen a chainwork.
5. **Trazar selección y reorganización.** Reproduce la elección del candidato de mayor trabajo, el orden local con trabajo igual y el estado de llegada. Si aparece una rama válida mejor, identifica el punto de fork, desconecta el sufijo antiguo, conecta el nuevo, actualiza el `UTXO set` y concilia transacciones con el `mempool` y los registros de la aplicación.
6. **Definir una política de confirmación basada en riesgo.** Calcula `confirmations = tip_height - block_height + 1` solo para bloques de la cadena activa actual. Declara valor en riesgo, reversibilidad, cuota atacante, propagación, exposición eclipse, tasa stale observada, profundidad y plan de respuesta; seis es una convención, no un umbral de finalidad del protocolo.
7. **Someter todo el argumento a estrés.** Prueba particiones, latencia, retención de bloques, minería egoísta, ataques eclipse, concentración de pools y hardware, cambios bruscos de hashrate, incentivos de comisiones y subsidio, divergencia de clientes, reorganizaciones profundas y recuperación. Vincula conclusiones con prefijo común, crecimiento, calidad, persistencia y vivacidad solo bajo los supuestos del modelo citado.
El resultado es una explicación reproducible y específica del observador sobre qué historia válida elige ahora un nodo y por qué. Las reglas definen admisibilidad; la prueba de trabajo encarece historias alternativas; la propagación expone el trabajo; la elección de fork selecciona una historia actual; y la política de confirmaciones decide cuándo actúa una aplicación. Reducir esas capas a “aprobación de la red” oculta qué condiciones pueden fallar.
## Ejemplos resueltos
### 1. El trabajo inválido no gana
Supón que la rama A informa `valid_A = false` y `chainwork_A = 1,200 units`, mientras B tiene `valid_B = true` y `chainwork_B = 1,000 units`. El nodo rechaza A y elige B. El trabajo solo se compara entre candidatos admisibles; la prueba de trabajo no autoriza una coinbase excesiva, una firma inválida ni un doble gasto.
Si un observador solo tiene las cabeceras de A y otro sus bloques completos, sus estados pueden diferir hasta completar descarga y validación. Una rama con cabeceras válidas no demuestra que todas las transacciones y transiciones hayan superado validación completa.
### 2. Altura no es trabajo acumulado
En un ejemplo simplificado con objetivo variable, C añade seis bloques de 100 unidades cada uno, es decir `6 * 100 = 600 units`. D añade cinco de 130, es decir `5 * 130 = 650 units`. Si ambas son válidas y parten del mismo trabajo, D es la rama de mayor trabajo aunque tenga un bloque menos.
Si dos puntas válidas tienen exactamente `650 units`, la igualdad no obliga a todos los nodos a ver enseguida la misma punta. El orden de llegada y estado local pueden diferir hasta que otro bloque válido haga más pesada una rama. Una vista transitoria empatada no es finalidad global determinista.
### 3. Las confirmaciones pueden desaparecer
Una transacción incluida a altura `100` con punta activa `105` tiene `tip_height - block_height + 1 = 105 - 100 + 1 = 6 confirmations`. Supón que otra rama válida bifurca después de 99 y se vuelve la de mayor trabajo a altura 106 sin la transacción. La reorganización desconecta los bloques antiguos `100 through 105`; la transacción pierde sus seis confirmaciones activas y puede volver al mempool, entrar en conflicto o seguir ausente.
Las aplicaciones deben conciliar hash y ascendencia, no guardar solo el número seis. Un abono de exchange, bienes entregados, mensajes de puente o liquidación de derivados pueden ser económicamente irreversibles aunque la historia de origen no lo sea.
### 4. La probabilidad de alcance depende del modelo
En el modelo ilustrativo del libro blanco de Bitcoin, sea la cuota atacante `q = 0.10`, la honesta `p = 0.90` y la ventaja honesta `z = 6`. Su aproximación de Poisson da `lambda = z * (q / p) = 0.6666667` y `P(catch up) = 0.0002428027 = 0.02428027%`. Con `q = 0.30` y la misma profundidad, sube a `P(catch up) = 0.1321111687 = 13.21111687%`.
No son garantías actuales de Bitcoin. El cálculo supone ensayos hash independientes y estables y las condiciones de carrera del modelo; omite aislamiento eclipse, ventaja de propagación, estrategias egoístas, respuesta de precios y alquiler, errores de implementación y reacción de aplicaciones. Una política debe declarar el modelo y probar peores condiciones, no citar solo seis confirmaciones.
## Riesgos y fallos de revisión
### Errores de protocolo y medición
- Comparar trabajo antes de validar independientemente cabecera, cuerpo y ascendencia.
- Llamar ganadora a la rama más alta o vista primero sin calcular chainwork acumulado.
- Usar número de bloques, hashrate nominal, cuota de pool o etiqueta de explorador como sustituto de chainwork.
- Mezclar mainnet, testnet, signet, forks, versiones, checkpoints o identidades genesis.
- Tratar datos de solo cabeceras, no disponibles u optimistas como historia completamente validada.
- Omitir decodificación del objetivo, aritmética entera, enlaces de hash previo o ancestros comunes.
- Tratar un RPC o explorador como vista global sin hash, altura, hora y contexto de pares.
### Errores de red, incentivos y control
- Suponer propagación instantánea o el mismo orden de llegada en todos los nodos.
- Tratar un empate de trabajo como estado global único, no como vistas locales temporales.
- Ignorar bloques stale, latencia, retención, minería egoísta y ventaja de propagación.
- Inferir mineros independientes de nombres de pools o propiedad física de sus cuotas.
- Omitir concentración de pools, firmware, fabricantes, hosting, energía, geografía y red.
- Tratar recompensas como prueba de que extender honestamente siempre es óptimo para todos.
- Omitir exposición a eclipse, particiones, Sybil, envenenamiento de pares, DoS y manipulación temporal.
### Errores de liquidación y seguridad
- Llamar finalidad del protocolo a una confirmación o prometer que seis no pueden desaparecer.
- Aplicar una confirmación igual a todo valor, contraparte, reversibilidad y amenaza.
- Convertir el ejemplo probabilístico del libro blanco en probabilidad de ataque medida hoy.
- Decir que una mayoría hash puede falsificar firmas, tomar monedas arbitrarias o validar inflación.
- Decir que una minoría hash no puede desviarse con beneficio ni causar reorganización o censura.
- Equiparar la punta de mayor trabajo con hechos externos, propiedad jurídica o liquidación de aplicación.
## Errores comunes
- **La cadena más larga siempre tiene más bloques.** Los nodos Bitcoin eligen la cadena válida con mayor trabajo acumulado; la altura puede ser un mal sustituto si cambian los objetivos.
- **Los mineros deciden qué reglas son válidas.** Proponen bloques; cada nodo completo aplica de forma independiente sus reglas configuradas.
- **Seis confirmaciones crean finalidad absoluta.** Seis es una convención; el riesgo depende del modelo, profundidad, adversario, propagación e integridad de observación.
- **Un atacante con 51 % puede gastar monedas ajenas.** El hash puede apoyar reorganización, doble gasto y censura, pero no aporta la firma privada ajena ni hace aceptar inflación inválida a nodos sin modificar.
- **Un hashrate total alto prueba descentralización y seguridad.** También importan control efectivo, visibilidad, acceso al hardware, coordinación de pools, diversidad de clientes, incentivos y duración.
## Temas relacionados
- [Prueba de trabajo](/es/crypto/proof-of-work/)
- [Reglas de elección de fork](/es/crypto/fork-choice-rule/)
- [Confirmaciones de bloque](/es/crypto/block-confirmation/)
- [Reorganizaciones de cadena](/es/crypto/chain-reorg/)
- [Minería egoísta](/es/crypto/selfish-mining/)
## Fuentes
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consultado: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consultado: 2026-08-19)
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project (consultado: 2026-08-19)
- [Bitcoin Core RPC: getchaintips](https://developer.bitcoin.org/reference/rpc/getchaintips.html) - Bitcoin Project (consultado: 2026-08-19)
- [Bitcoin Core: validation.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp) - Bitcoin Core (consultado: 2026-08-19)
- [The Bitcoin Backbone Protocol: Analysis and Applications](https://eprint.iacr.org/2014/765) - IACR Cryptology ePrint Archive (consultado: 2026-08-19)
- [Majority Is Not Enough: Bitcoin Mining Is Vulnerable](https://www.cs.cornell.edu/~ie53/publications/btcProcArXiv.pdf) - Cornell University (consultado: 2026-08-19)
- [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association (consultado: 2026-08-19)
Source: https://wiki.fcontext.com/es/crypto/nakamoto-consensus/index.mdx