---
title: "Nothing at Stake: equivocación, slashing, finalidad y riesgo de claves antiguas"
description: "Nothing at Stake es el problema de incentivos de la prueba de participación en el que apoyar historiales rivales puede tener un coste marginal bajo. Analiza por separado los mensajes penalizables, el rendimiento esperado, la intersección de cuórums, la ejecución de pruebas, la elección de bifurcación y la subjetividad débil."
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.
# Nothing at Stake: equivocación, slashing, finalidad y riesgo de claves antiguas
> Análisis de protocolo solo con fines educativos; no constituye asesoramiento de inversión, staking, operación de validadores ni seguridad. Las reglas de slashing y finalidad varían según el protocolo y la versión, y también pueden fallar la implementación, la custodia de claves, las condiciones de red, la gobernanza y los supuestos de subjetividad débil.
## Respuesta directa
Nothing at Stake es un problema de incentivos de la prueba de participación: si producir una firma adicional es barato y el protocolo no impone un coste efectivo por apoyar opciones incompatibles, un validador puede ganar más ayudando a todos los historiales rivales que eligiendo uno. Si muchos validadores siguen ese incentivo privado, las bifurcaciones pueden conservar apoyo, la convergencia puede debilitarse y un atacante puede obtener firmas cuya reproducción habría sido costosa en una prueba de trabajo.
La expresión no significa que todos los sistemas de prueba de participación carezcan de presupuesto de seguridad ni que todo voto en una bifurcación perdedora sea una infracción. El capital bloqueado, las recompensas perdidas, el slashing, las retiradas demoradas y las reglas de elección de bifurcación y finalidad pueden cambiar el rendimiento. Los mensajes firmados y conflictos penalizables dependen del protocolo y la versión; una actualización normal del voto, un mensaje retrasado o una bifurcación honesta temporal pueden estar permitidos.
Hay que separar tres preguntas. Primero, ¿puede un validador que sigue vinculado equivocar a bajo coste entre ramas recientes? Segundo, ¿puede el peso de voto ausente o adversarial detener el progreso sin crear dos historiales finalizados? Tercero, ¿pueden las claves antiguas fabricar un historial alternativo largo después de que la participación sea retirable? Son riesgos relacionados de incentivos y consenso, pero sus pruebas, umbrales y defensas son distintos.
Ethereum es un ejemplo útil, no una plantilla universal. Sus especificaciones de consenso permiten penalizar dos propuestas distintas para la misma ranura y las atestaciones que constituyan doble voto o voto envolvente. La elección de bifurcación puede ignorar la influencia de quien equivoca, mientras que la finalidad usa votos de supermayoría y penalizaciones. Otras familias de prueba de participación emplean otra selección de líderes, elección de cadena, puntos de control, supuestos de disponibilidad o modelos formales de seguridad.
## Cómo analizar Nothing at Stake
1. **Fija el contexto del protocolo.** Registra `protocol`, `version`, `network`, `epoch`, `slot`, `validator set` y la hora de observación. Identifica los `fork choice`, `finality gadget`, `reward rule`, `penalty rule` y `withdrawal delay` activos; la etiqueta «PoS» no determina ninguno de ellos.
2. **Define las acciones firmadas.** Enumera propuestas de bloques, atestaciones, prevotos, precompromisos, certificados u otros mensajes y sus dominios. Distingue dos mensajes que solo favorecen descendientes distintos de un `double proposal`, `double vote` o `surround vote` formalmente penalizable según las reglas citadas.
3. **Modela el rendimiento sin penalización.** Estima las probabilidades de rama, recompensas de la rama canónica, coste extra de firma y propagación, sobornos, oportunidades perdidas y cualquier recompensa por mensajes conflictivos. Compara `EV(honest)` con `EV(equivocate)` en vez de suponer que el bajo consumo eléctrico demuestra que desviarse es rentable.
4. **Modela la pérdida ejecutable.** Identifica saldo vinculado, probabilidad de detección, ventana de validez de la prueba, vía de denuncia, riesgos de inclusión y censura, penalización inicial, penalización correlacionada, expulsión, momento de retirada e ingresos futuros perdidos. Una penalización escrita en la documentación no equivale a la ejecución fiable de `slashing evidence`.
5. **Separa elección de bifurcación y finalidad.** Reconstruye cómo los últimos votos, las equivocaciones y la temporización de mensajes afectan a la cabecera y calcula el peso necesario para justificar o finalizar puntos de control. Analiza por separado `safety threshold` y `liveness threshold`: retener votos puede detener la finalidad sin producir una finalidad conflictiva.
6. **Prueba los supuestos de claves antiguas y sincronización.** Determina cuándo deja de ser penalizable la participación retirada, qué historial finalizado rechazará un nodo conectado, cómo obtiene un nodo nuevo o desconectado durante mucho tiempo un `weak-subjectivity checkpoint` y cómo se verifican su antigüedad y procedencia. Este es el problema de largo alcance, no solo un doble voto reciente.
7. **Somete las operaciones y el control a tensión.** Prueba claves duplicadas, nodos de conmutación por error, firmantes remotos, restauraciones de base de datos, errores de clientes, alojamiento correlacionado, pools de staking, custodia delegada, particiones, ataques eclipse y censura de pruebas. Cuenta vías de control y software independientes, no solo identificadores de validadores.
El resultado debe ser una evaluación versionada de incentivos y consenso, no un veredicto basado en el término. Muestra qué mensajes exactos puede firmar una clave, qué pruebas conflictivas son verificables objetivamente, hasta cuándo puede alcanzarse la garantía, qué umbral protege la seguridad, cuál permite avanzar y qué estado de confianza necesita un nodo al sincronizar.
## Ejemplos calculados
### 1. Una estrategia sin penalización puede favorecer ambas ramas
Supón que exactamente una de dos ramas se vuelve canónica: la rama A con probabilidad `0.55` y la rama B con probabilidad `0.45`. Una firma en la rama canónica gana `1.00 unit` y una firma en la perdedora, cero. Ignorando todas las penalizaciones y costes operativos añadidos, firmar solo A produce `EV(A only) = 0.55 * 1.00 = 0.55 units`. Firmar ambas produce `EV(sign both) = (0.55 + 0.45) * 1.00 = 1.00 unit`.
La aritmética ilustra el problema de incentivos; no pronostica un rendimiento de staking. Supone que la firma de la rama canónica obtiene recompensa gane la rama que gane, que las acciones están permitidas o no se sancionan, que los resultados son mutuamente excluyentes y que el validador no sufre pérdidas de precio, reputación, latencia ni ingresos futuros.
### 2. El slashing ejecutable puede invertir el rendimiento
Mantén la recompensa bruta canónica de `1.00 unit` y añade un soborno de `0.02 unit` por equivocar. Supón que una prueba válida llega al mecanismo de penalización con probabilidad `0.80` y que la pérdida total atribuible es `5.00 units`. El rendimiento simplificado es `EV(equivocate) = 1.00 + 0.02 - (0.80 * 5.00) = -2.98 units`, inferior a los `0.55 units` de firmar solo A.
El resultado cambia si difieren la detección, la inclusión, la garantía cobrable o los ingresos futuros. Las penalizaciones reales pueden depender del saldo efectivo, las infracciones correlacionadas, el tiempo y el estado del protocolo. Los operadores deben modelar una distribución de resultados y confirmar la ruta de implementación; multiplicar tres cifras elegidas no demuestra que un sistema desplegado sea compatible con los incentivos.
### 3. La intersección de cuórums protege la seguridad, pero puede exponer la vivacidad
Considera `100 stake units` y una regla que exige al menos `67 units` para votar la finalidad. Dos cuórums de ese tamaño se solapan en al menos `67 + 67 - 100 = 34 units`. Por tanto, dos finalizaciones conflictivas requieren que al menos 34 unidades participen en ambos certificados de cuórum; un protocolo con atribución puede hacer que esa intersección sea demostrablemente penalizable.
El mismo umbral tiene otra implicación para la vivacidad. Si `34 units` retienen votos válidos, solo quedan `66 units`, menos de 67, por lo que la finalidad puede detenerse. Esas 34 unidades no finalizan dos ramas por sí solas. No deben describirse como el mismo suceso un fallo de seguridad, una prueba atribuible y la falta de progreso.
### 4. Las claves antiguas crean otro problema de sincronización
Supón que un nodo conectado ha finalizado el punto de control `epoch 39,900`, mientras que un nodo nuevo no tiene estado de confianza. Un atacante obtiene claves que controlaban suficiente participación cerca de `epoch 10,000`, después de que esos validadores salieran y su garantía dejara de ser alcanzable, y fabrica un historial alternativo hasta `epoch 40,000`. Las firmas históricas baratas son pertinentes, pero el slashing de validadores recientes quizá ya no disuada a esas claves antiguas.
El nodo conectado rechaza un historial que contradiga su vista finalizada. El nodo nuevo necesita un punto de control reciente autenticado o una regla equivalente del protocolo para distinguir los historiales antes de continuar la verificación objetiva. Por eso la subjetividad débil y los plazos de retirada forman parte de la revisión, aunque deben analizarse aparte de la equivocación en vivo de validadores vinculados.
## Riesgos y fallos de revisión
### Errores de protocolo y pruebas
- Calificar de penalizable todo voto en una bifurcación no canónica sin comprobar los campos firmados y dominios exactos.
- Tratar como equivalentes una bifurcación, reorganización, propuesta omitida, voto tardío y equivocación demostrable.
- Aplicar las condiciones de proponentes y atestadores de Ethereum a un protocolo con otros mensajes o reglas de finalidad.
- Omitir identidad de cadena, versión de bifurcación, epoch o slot al comparar firmas supuestamente conflictivas.
- Suponer que dos firmas demuestran por sí solas una infracción sin identidad del validador, dominios, ascendencia y criptografía válida.
- Confundir influencia sobre la elección de bifurcación con justificación, finalización o liquidación de la aplicación.
- Leer un teorema de seguridad sin sus supuestos de sincronía, honestidad, disponibilidad y adversario.
### Errores de incentivos y ejecución
- Decir que las firmas son baratas sin valorar la pérdida vinculada, las recompensas omitidas y los ingresos futuros.
- Tratar el slashing nominal máximo como la pérdida esperada cobrable en cualquier estado.
- Suponer que la prueba siempre se observa, propaga, incluye y procesa antes de la retirada.
- Ignorar censura del proponente, particiones de red, aislamiento eclipse y vencimiento de la ventana de pruebas.
- Usar un valor esperado de juguete como prueba cuando no se han medido probabilidades, sobornos ni pérdidas.
- Ignorar penalizaciones correlacionadas, cambios del precio del token, coberturas, sobornos externos y ganancias del ataque.
- Suponer que la clave antigua de un validador retirado sigue respaldada por garantía actualmente penalizable.
### Errores de operación, concentración y recuperación
- Ejecutar la misma clave de firma en nodos de respaldo sin protección contra slashing duradera y compartida.
- Restaurar el firmante o la base de datos de slashing desde copias antiguas y recrear conflictos ya firmados.
- Contar claves de validadores como operadores independientes pese a compartir custodia, cliente, nube o control de gobernanza.
- Suponer que los delegadores no soportan pérdidas causadas por un operador, pool o dependencia de restaking.
- Confiar en un único explorador, proveedor o punto de control incluido al recuperar un nodo desconectado mucho tiempo.
- Afirmar que una participación alta demuestra seguridad sin analizar distribución, umbral y control del stake.
## Errores comunes
- **La prueba de participación literalmente no pone nada en riesgo.** Un sistema bien diseñado puede exponer capital vinculado, recompensas y participación futura; la cuestión es si esos costes son suficientes y ejecutables para la desviación relevante.
- **Todo mensaje de un validador en dos bifurcaciones es un doble voto.** La posibilidad de slashing depende de los campos, dominios y reglas de conflicto del protocolo; las actualizaciones honestas de elección de bifurcación necesitan margen.
- **El slashing garantiza el consenso.** Aporta responsabilidad e incentivos, pero seguridad y vivacidad también dependen de umbrales, red, implementaciones, seguridad de claves y supuestos de conducta honesta.
- **Un tercio del stake puede finalizar dos ramas por sí solo.** En un diseño de finalidad por dos tercios, aproximadamente un tercio suele poder detener el progreso; la finalidad conflictiva exige supermayorías solapadas y participación penalizable en su intersección.
- **Nothing at Stake y los ataques de largo alcance son idénticos.** Ambos aprovechan firmas baratas, pero uno trata del apoyo en vivo a ramas rivales y el otro puede usar claves históricas contra nodos sin estado de confianza reciente.
## Temas relacionados
- [Prueba de participación](/es/crypto/proof-of-stake/)
- [Slashing](/es/crypto/slashing/)
- [Reglas de elección de bifurcación](/es/crypto/fork-choice-rule/)
- [Finalidad](/es/crypto/finality/)
- [Ataques de largo alcance](/es/crypto/long-range-attack/)
## Fuentes
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulta: 2026-08-19)
- [Formal Barriers to Longest-Chain Proof-of-Stake Protocols](https://economics.princeton.edu/working-papers/formal-barriers-to-longest-chain-proof-of-stake-protocols/) - Princeton University (consulta: 2026-08-19)
- [Ethereum Consensus Specifications: Validator](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (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)
- [Casper the Friendly Finality Gadget](https://eips.ethereum.org/assets/eip-2982/arxiv-1710.09437-Casper-the-Friendly-Finality-Gadget.pdf) - Ethereum Improvement Proposals (consulta: 2026-08-19)
- [Ethereum Proof-of-Stake Attack and Defense](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (consulta: 2026-08-19)
- [Weak Subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (consulta: 2026-08-19)
- [Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (consulta: 2026-08-19)
Source: https://wiki.fcontext.com/es/crypto/nothing-at-stake/index.mdx