---
title: "Finalidad en blockchain: evidencia, supuestos y capas de liquidación"
description: "La finalidad es la garantía específica de un protocolo de que una decisión no será sustituida sin infringir los supuestos de seguridad o activar una recuperación excepcional. Hay que separar validez, elección de bifurcación, prueba de finalidad, límites de fallo, capas y liquidación de la aplicació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.
# Finalidad en blockchain: evidencia, supuestos y capas de liquidación
> Análisis educativo del protocolo. Una etiqueta como «confirmado», «seguro», «comprometido» o «finalizado» solo tiene sentido junto con su cadena, reglas, evidencia, supuestos de fallo, capa y política de aplicación.
## Respuesta directa
La finalidad es la garantía específica de un protocolo de que una decisión aceptada, como un bloque, un punto de control o un compromiso de estado, no será sustituida sin infringir los supuestos de seguridad declarados o recurrir a una recuperación excepcional. No es una propiedad física de los bytes de la transacción ni equivale a «la transacción tuvo éxito». Toda afirmación debe identificar objeto, red, versión del protocolo, evidencia, modelo de fallos y tiempos, punto de partida confiable y observador.
Validez, canonicidad y finalidad son conceptos distintos. Un bloque válido satisface las reglas de transición de estado y autorización. La elección de bifurcación selecciona la cabecera canónica actual entre candidatos válidos. La finalización aplica un predicado adicional, como un certificado de compromiso o un punto de control finalizado, a un ancestro de esa cabecera. Una transacción puede ejecutarse bien en un bloque válido que luego pierda la elección; una cabecera puede ser canónica y no estar finalizada; y un evento finalizado en la cadena de origen aún puede fallar en un puente, una bolsa o una aplicación.
Los sistemas de prueba de trabajo suelen ofrecer liquidación probabilística, no un bit explícito de finalidad: al acumularse trabajo válido sobre un bloque, sustituirlo se vuelve por lo general menos probable y más costoso bajo los supuestos de potencia de hash y red. Un protocolo BFT puede ofrecer finalidad determinista condicional: tras un certificado de compromiso válido, dos decisiones contradictorias no pueden comprometerse a la vez si el peso defectuoso permanece bajo el límite demostrado. En PoS también puede ser responsable o económica, pues los votos contradictorios identifican peso sancionable. Estas etiquetas describen evidencias distintas.
Ningún protocolo vuelve la historia absolutamente inmutable. Una filtración catastrófica de claves, un límite de fallos vulnerado, errores de cliente, transiciones inválidas aceptadas por implementaciones, intervención de gobernanza o recuperación social pueden cruzar el límite del modelo. «Finalizado» debe significar que la vía ordinaria de reorganización no puede sustituir esa decisión bajo esos supuestos; la recuperación excepcional y su autoridad deben documentarse aparte.
## Cómo analizar la finalidad
1. **Nombrar el objeto y el alcance.** Identificar transacción, bloque, punto de control, raíz de estado, mensaje entre cadenas o retiro; registrar cadena, red, capa, versión, altura o slot, hash y punto de control confiable.
2. **Verificar la validez antes del estado.** Reejecutar o validar de otro modo la transición y la ascendencia pertinentes. Un cuórum, puntuación de trabajo o distintivo de interfaz no puede finalizar un objeto inválido según las reglas reales.
3. **Separar selección de cabecera y finalización.** Reconstruir la elección de bifurcación y la ruta canónica actual, y localizar después el ancestro finalizado o comprometido. Registrar si solo se observó, confirmó, justificó, aseguró, comprometió o finalizó.
4. **Reproducir la evidencia.** En PoW, verificar cabeceras, objetivo y chainwork acumulado sobre el bloque. En protocolos de voto, verificar elegibilidad, instantánea de peso, dominio del mensaje, origen y destino, altura, ronda, desigualdad de cuórum, firmas, bloqueos y ascendencia del certificado.
5. **Declarar los supuestos de seguridad y vivacidad.** Especificar peso bizantino o desconectado, sincronía, demora, equívoco, robo de claves, correlación de clientes, cambios de miembros, disponibilidad de sanción y reacción ante un bloqueo. Una parada puede conservar seguridad y perder vivacidad.
6. **Mapear todas las capas de liquidación.** Seguir recepción del secuenciador, ejecución L2, publicación de datos, inclusión L1, finalidad L1, fin de prueba o disputa, ejecución del puente, abono de la bolsa y acción de la aplicación. Etiquetas similares en capas distintas no implican el mismo predicado.
7. **Definir y vigilar una política de aplicación.** Fijar evidencia aceptable según valor y consecuencia, consultar nodos independientes, gestionar reorganizaciones y alarmas de finalidad contradictoria, pausar acciones irreversibles si fallan los supuestos y registrar quién autoriza la recuperación.
El número de confirmaciones es una observación, no una regla universal de finalidad. En Bitcoin Core, `confirmations` depende de la posición del bloque en la cadena activa actual, mientras `chainwork` registra el trabajo esperado acumulado. En Ethereum, la elección de cabecera LMD-GHOST y la justificación y finalización de puntos de control Casper FFG son transiciones distintas. En CometBFT, un compromiso requiere que más de dos tercios del poder precomprometa el mismo bloque a la misma altura y ronda. Cada estado se interpreta dentro de su protocolo.
## Ejemplos calculados
### 1. Liquidación probabilística por prueba de trabajo
El libro blanco de Bitcoin modela a un atacante con cuota de hash `q=0.10` que intenta alcanzar a la cadena honesta tras una ventaja `z=6`. Bajo sus supuestos de intentos de hash independientes y distribución de Poisson, la probabilidad calculada es:
`P=0.0002428 = 0.02428%`
Es pequeña, no nula, y no constituye una garantía universal de «seis confirmaciones». La política real debe considerar valor, chainwork observado, concentración de hash, riesgo de eclipse o partición, incentivos de comisiones y credibilidad del supuesto de cuota constante.
### 2. Justificación y finalización de Ethereum
Supongamos una ruta simplificada de puntos consecutivos con saldo efectivo activo total `100`. Votos de `67/100` que enlazan el punto justificado `C_0` con el destino `C_1` alcanzan al menos dos tercios y justifican `C_1`. Un enlace posterior válido de `67/100` desde `C_1` a su hijo directo `C_2` puede finalizar `C_1` según la regla Casper FFG aplicable.
La cabecera puede avanzar más allá de `C_2` mientras la parte nueva sigue sin finalizar. Si el saldo `34` está desconectado, solo queda `66` y la finalización inmediata se detiene aunque continúen la elección y la producción. Tras más de cuatro epochs sin finalidad, la fuga de inactividad de Ethereum penaliza la no participación para que una supermayoría activa pueda recuperarla.
### 3. Seguridad frente a vivacidad en CometBFT
Sea el poder total `100` y exíjase `>2/3` de precompromisos para el mismo bloque, altura y ronda. Un poder entero `67` compromete. Dos conjuntos de compromiso de 67 se cruzan en al menos `67 + 67 - 100 = 34` de poder. Si el peso bizantino es inferior a un tercio y los validadores honestos respetan los bloqueos, no pueden formarse dos compromisos contradictorios.
Si el peso `34` no está disponible, solo `66` puede votar y no hay compromiso. El protocolo puede conservar seguridad mientras la finalidad se detiene. «No existe un bloque finalizado contradictorio» y «los nuevos bloques siguen finalizándose» son garantías diferentes.
### 4. Estados de OP Stack y plazos de retiro
Un secuenciador de OP Stack puede mostrar primero un bloque L2 como `unsafe`. Cuando puede derivarse por completo de datos de la cadena L1 canónica actual, el nodo rollup puede marcarlo `safe`. Cuando las entradas L1 correspondientes reciben una señal de finalidad L1, el bloque L2 derivado puede volverse `finalized`.
Ese estado atañe a la derivación desde entradas finalizadas. Una salida de rollup optimista o un retiro L2 a L1 tiene otro proceso de prueba y disputa, y puede llamarse «finalizado» solo al cumplirse su condición de impugnación. Una aplicación que reúna confirmación del secuenciador, inclusión de datos L1, finalidad de consenso L1 y ejecución del retiro en una sola marca temporal puede liberar valor demasiado pronto.
## Riesgos y fallos de revisión
### Definición y evidencia
- Llamar «final» a cualquier ejecución, recibo, confirmación, punto de control o distintivo exitoso.
- Omitir cadena, red, versión, hash del objeto, altura o slot, capa y observador.
- Tratar la cabecera de fork choice como ancestro finalizado o suponer que finalizar elige la cabecera más reciente.
- Contar bloques o minutos sin validar ascendencia, objetivos, trabajo, votos o certificados.
- Comparar «dos confirmaciones» o «diez minutos de finalidad» entre protocolos con otra evidencia y modelo de fallos.
- Verificar firmas sin elegibilidad, peso, dominio, origen, destino, altura y ronda.
- Equiparar coste económico, prueba sancionable y ejecución real de la sanción.
- Describir riesgo probabilístico como cero o seguridad determinista condicional como irreversibilidad absoluta.
### Fallos de protocolo y operación
- Superar el límite bizantino, perder el peso conectado necesario para la vivacidad u ocultar una partición.
- Permitir discrepancias de implementación en validez, elección, transiciones, redondeo del cuórum o ascendencia del certificado.
- Aceptar votos, compromisos, puntos o datos de subjetividad débil obsoletos, repetidos o de otra red.
- Concentrar claves, stake, hash, clientes, relés, nubes o vistas RPC tras identidades supuestamente separadas.
- Suponer que una fuga de inactividad, timeout o cambio de vista recupera el progreso de inmediato y sin consecuencias.
- No alertar de retraso de finalidad, certificados contradictorios, reorganización profunda, equívoco o raíces divergentes.
- Usar gobernanza de emergencia o recuperación social sin documentar autoridad, coordinación, versión del cliente y garantías afectadas.
### Desajuste de capas y aplicación
- Tratar la inclusión del secuenciador como seguridad L2, publicación L1, finalidad L1, aceptación de prueba y retiro completo a la vez.
- Liberar activos puenteados antes de que el evento de origen y la verificación del puente cumplan la política.
- Abonar depósitos o ejecutar operaciones irreversibles desde el estado de un solo RPC sin conciliación independiente.
- Suponer que la finalidad garantiza verdad del oráculo, corrección del contrato, disponibilidad de datos, solvencia o liquidación legal.
- Aplicar un umbral fijo a cualquier valor, contraparte, incentivo de ataque y coste de recuperación.
## Ideas erróneas comunes
- **Una transacción exitosa es final.** El éxito solo describe una transición en una historia candidata; canonicidad y finalidad requieren más evidencia.
- **Más confirmaciones vuelven exactamente cero el riesgo PoW.** La probabilidad del modelo puede caer mucho, pero depende de supuestos y no se convierte en imposibilidad lógica.
- **Dos tercios siempre significan finalidad.** Desigualdad, mensaje, peso, altura, ronda, relación origen-destino y bloqueo dependen del protocolo.
- **La finalidad garantiza que la red avance.** La seguridad puede mantenerse aunque participación o conectividad insuficientes impidan nuevas finalizaciones.
- **La finalidad L1 completa toda acción L2 o de puente.** Derivación, prueba de validez o fraude, plazo de impugnación y ejecución de destino añaden relojes y fallos propios.
## Temas relacionados
- [Confirmaciones de bloque](/es/crypto/block-confirmation/)
- [Reorganizaciones de cadena](/es/crypto/chain-reorg/)
- [Mecanismos de consenso](/es/crypto/consensus-mechanism/)
- [Reglas de elección de bifurcación](/es/crypto/fork-choice-rule/)
- [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 RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project (consulta: 2026-08-19)
- [Ethereum Proof-of-Stake Consensus](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (consulta: 2026-08-19)
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consulta: 2026-08-19)
- [Ethereum Proof-of-Stake Rewards and Penalties](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (consulta: 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (consulta: 2026-08-19)
- [OP Stack Derivation Specification](https://specs.optimism.io/protocol/derivation.html) - Optimism (consulta: 2026-08-19)
Source: https://wiki.fcontext.com/es/crypto/finality/index.mdx