---
title: "Blockchain: Estado, Consenso y Verificación"
description: "Una cadena de bloques es un protocolo versionado para ordenar y validar transiciones de estado entre réplicas. Los enlaces hash son sólo un componente; la confianza depende del consenso, los permisos, la verificación independiente, la disponibilidad de datos, la gobernanza y la recuperación."
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.

# Blockchain: Estado, Consenso y Verificación

> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

<a id="answer"></a>

## Respuesta directa

Una cadena de bloques es un protocolo versionado que permite que múltiples réplicas ordenen las transacciones propuestas, validen las transiciones de estado y converjan en un historial aceptado bajo consensos establecidos y supuestos de red. Un bloque es un contenedor definido por protocolo con transacciones u otros datos más compromisos con el historial anterior y el estado resultante; la cadena o historial dirigido vincula los contenedores aceptados a través de compromisos criptográficos.

Los enlaces hash hacen detectables los cambios históricos no autorizados, pero no hacen que un sistema sea descentralizado, inmutable o correcto de forma independiente. Esas propiedades dependen de quién puede proponer y validar, si los usuarios pueden verificar de forma independiente, las reglas de elección y finalidad de la bifurcación, la disponibilidad de datos, la diversidad de clientes, la gobernanza, el control de claves, los incentivos y los procedimientos de recuperación.

Las cadenas de bloques pueden utilizar UTXO, cuentas, objetos o modelos de estado específicos de aplicaciones; prueba de trabajo, prueba de participación, votación bizantina tolerante a fallas o consenso permitido; y finalidad probabilística o basada en puntos de control. Por lo tanto, la palabra "blockchain" nombra una amplia familia de arquitectura, no una garantía de seguridad o un producto de base de datos.

<a id="mechanism"></a>

## Cómo funciona

1. Fije la cadena, la red, la versión del protocolo, el modelo de permisos, el modelo de estado y la afirmación que se está comprobando. Registre el bloque génesis o punto de control de confianza, el identificador de cadena, la implementación del cliente y la autoridad de actualización.
2. Construya los bytes exactos de la transacción y su autorización. Antes de difundirla, verifique la propiedad del remitente o de las entradas, el nonce o las referencias a salidas no gastadas, el importe, el destino, los límites de comisión, la ventana de validez, las firmas y las llamadas a la aplicación.
3. Propague la transacción entre pares o pasarelas. Distinga la política local de admisión y del mempool de la validez por consenso; un nodo puede rechazar, retrasar, sustituir o no recibir nunca una transacción que sería válida en un bloque.
4. Un proponente selecciona y ordena transacciones en un bloque candidato y se compromete con campos del protocolo como el bloque padre y las raíces de transacciones, recibos, estado o datos. El orden puede afectar los resultados de ejecución, las comisiones, las liquidaciones y el valor extraíble.
5. Los nodos independientes deserializan el bloque, verifican la autorización de consenso y cada transición de estado requerida, vuelven a calcular los compromisos y rechazan las entradas no válidas o no disponibles de acuerdo con sus reglas. Las firmas del productor o la prueba de trabajo no anulan la validación fallida.
6. La elección de la bifurcación selecciona entre historias válidas en competencia, mientras que las confirmaciones, los votos o los puntos de control cambian el riesgo de reorganización con el tiempo. "Incluido", "seguro" y "finalizado" son estados diferentes y siguen siendo específicos del protocolo.
7. Concilie el estado del protocolo con la intención de la aplicación, la custodia, la contabilidad del puente o de la plataforma y los requisitos de archivo. Conserve los bytes de la transacción, el hash del bloque, la altura o ranura, el recibo, los registros, la prueba de estado, el estado de finalidad, la versión del cliente y evidencia obtenida de un punto de acceso independiente.

<a id="example"></a>

## Ejemplos resueltos

- **Conciliación del estado de una cuenta.** Una cuenta comienza con `10 ETH` y nonce `41`. Una transacción válida con nonce `41` transfiere `2 ETH` y consume `0.00042 ETH` en comisiones, por lo que el estado posterior simplificado es `10 - 2 - 0.00042 = 7.99958 ETH`, el destinatario recibe `2 ETH` y el nonce del remitente pasa a `42`. Una firma válida por sí sola no demostraría el saldo anterior ni la ejecución correcta.
- **Conservación UTXO.** Una transacción gasta entradas de `0.80 BTC` y `0.35 BTC`, por un total de `1.15 BTC`. Las salidas de `1.00 BTC` y `0.1496 BTC` totalizan `1.1496 BTC`; la diferencia es `1.15 - 1.1496 = 0.0004 BTC` en comisiones. Los nodos también deben verificar que cada salida referenciada exista, siga sin gastarse y satisfaga sus condiciones de gasto.
- **Tamaño de prueba de compromiso.** En un árbol Merkle binario equilibrado ilustrativo con `8 leaves`, una ruta de inclusión necesita `log2(8) = 3 sibling hashes`. Con hashes `256-bit = 32-byte`, esos hermanos ocupan `3 * 32 = 96 bytes` antes de los índices y la codificación. La prueba vincula una hoja a una raíz reivindicada; no prueba que los datos fuente sean veraces o estén actualmente disponibles.
- **El peso no es el recuento de nodos.** En un protocolo de votación ilustrativo cuya regla de finalidad establecida es `>= 2/3` de peso, los validadores mantienen `30%, 25%, 20%, 15%, 10%`. Los primeros tres suman `30 + 25 + 20 = 75%` y cruzan la regla, mientras que los dos primeros suman `55%` y no lo hacen. Los umbrales reales, las reglas de correlación, equívoco y recuperación deben provenir del protocolo nombrado.

<a id="risks"></a>

## Riesgos

- Usar la cadena, red, bifurcación, punto de control o identificador de cadena incorrectos.
- Tratar una marca como un protocolo completo o una especificación de modelo de confianza.
- Asumir únicamente el enlace hash evita las reescrituras autorizadas o aprobadas por consenso.
- Confundir la propuesta de bloque de un productor con la validación de un nodo independiente.
- Tratar la aceptación, difusión, inclusión, éxito de ejecución y finalidad de Mempool como un solo estado.
- Firma de bytes, dominios o destinos diferentes a lo que muestra la interfaz.
- Reutilizar nonces, gastar UTXO obsoletos o calcular mal tarifas y cambios.
- Confiar en símbolos de token, etiquetas, eventos o interpretaciones del explorador en lugar de identificadores de protocolo y estado.
- Tratar las entradas de documentos, puentes o oráculos firmados como prueba de que las afirmaciones fuera de la cadena son ciertas.
- Ignorar el ordenamiento de transacciones, la censura, el front-running y la concentración de proponentes o constructores.
- Contar nodos o validadores sin resolver operadores, pesos e infraestructura comunes.
- Ignorar la concentración de clientes, nube, geografía, gobernanza, claves y cadena de suministro de software.
- Suponer que todos los modelos de consenso tienen los mismos umbrales de falla o semántica de finalidad.
- Ignorar particiones, demoras en la firmeza, reorganizaciones, equívocos y procedimientos de recuperación.
- Aceptar encabezados de bloque o pruebas sin los supuestos requeridos de disponibilidad de datos.
- Dependiendo de un RPC, explorador, billetera, indexador o plataforma de custodia como fuente de verdad.
- Confundir posesión o control protocolario con título, recurso o recuperabilidad legal.
- Subestimar el crecimiento del estado, la pérdida de archivos, el costo de sincronización y las barreras de hardware.
- Ignorar claves de actualización, pausas de emergencia, recuperación social y bifurcaciones polémicas.
- Inferir privacidad, escalabilidad, valor de inversión o seguridad de aplicaciones a partir de la etiqueta blockchain.

<a id="misconceptions"></a>

## Errores comunes

- **Cada blockchain es descentralizada e inmutable.** El permiso, la independencia del operador, la elección de la bifurcación, la gobernanza y la recuperación determinan quién puede cambiar o rechazar la historia.
- **Los datos registrados en la cadena deben ser verdaderos.** El consenso puede acordar registrar fielmente un precio falso, un documento falsificado o una entrada de aplicación maliciosa.
- **Una transacción válida demuestra el resultado deseado.** Puede apuntar a la dirección incorrecta, revertir después de consumir tarifas, emitir eventos engañosos o depender de pasos posteriores de puente y custodia.
- **Más réplicas siempre mejoran la seguridad.** Las réplicas bajo un mismo operador, cliente, nube o clave pueden fallar juntas y es posible que no proporcionen una verificación independiente.
- **Una cadena de bloques siempre es mejor que una base de datos convencional.** Un operador confiable, una eliminación requerida, un alto rendimiento o una simple resolución de disputas pueden hacer que un sistema convencional sea más apropiado.

<a id="related"></a>

## Temas relacionados

- [Mecanismo de consenso](/es/crypto/consensus-mechanism/)
- [Hash criptográfico](/es/crypto/cryptographic-hash/)
- [Nodo completo](/es/crypto/full-node/)

<a id="sources"></a>

## Fuentes autorizadas

- [Descripción general de la tecnología Blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (consultado: 2026-08-18)
- [Bitcoin: un sistema de efectivo electrónico entre pares](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consultado: 2026-08-18)
- [Cadena de bloques](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin.org (consultado: 2026-08-18)
- [Bloques](https://ethereum.org/developers/docs/blocks/) - Ethereum.org (consultado: 2026-08-18)
- [Transacciones](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (consultado: 2026-08-18)
- [Nodos y clientes](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (consultado: 2026-08-18)
- [Mecanismos de consenso](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (consultado: 2026-08-18)
- [Finalidad](https://ethereum.org/developers/docs/consensus-mechanisms/pos/finality/) - Ethereum.org (consultado: 2026-08-18)

Source: https://wiki.fcontext.com/es/crypto/blockchain/index.mdx