El ataque del doble gasto: Cómo los estafadores digitales copian el dinero como si fuera un PDF

Si tienes una manzana física en la mano y se la entregas a un amigo, ya no la tienes tú. Los átomos que componen la manzana se han movido de lugar. Con el dinero en efectivo ocurre lo mismo: la física impide que entregues el mismo billete en dos tiendas distintas al mismo tiempo.

Los activos digitales no están hechos de átomos, sino de información. Y la propiedad fundamental de la información digital es que se puede copiar sin coste, exactamente igual que un archivo PDF o una foto en un chat. Una transacción firmada es un mensaje; nada impide que su autor fabrique otro mensaje, también bien firmado, que gaste el mismo saldo.

Por qué la firma no basta: el problema es de orden

Conviene separar dos preguntas que a menudo se mezclan. La primera es de autenticidad: ¿esta transacción la firmó de verdad el dueño de los fondos? La criptografía responde bien a eso. La segunda es de orden: si existen dos transacciones auténticas que gastan el mismo dinero, ¿cuál vale? La firma no puede responder, porque ambas están correctamente firmadas.

En un sistema con un único servidor la segunda pregunta es trivial. El servidor procesa las peticiones de una en una; la primera que llega descuenta el saldo y la segunda falla por fondos insuficientes. El orden lo impone el propio servidor, sin discusión. El problema aparece cuando, para no depender de una sola máquina, replicamos el libro contable en varios servidores que reciben las peticiones por la red en momentos distintos.

Ahí cada réplica podría ver primero una transacción diferente. Si cada una decidiera por su cuenta, el sistema terminaría con varias versiones de la verdad. Por eso un libro contable replicado no necesita solo copias de los datos: necesita que todas las réplicas correctas ejecuten las mismas transacciones en el mismo orden. Castro y Liskov formulan exactamente ese objetivo para su protocolo PBFT: que las réplicas no defectuosas acuerden un orden total para la ejecución de las peticiones. [2]

Cómo funciona un ataque de doble gasto en la práctica

Pongamos un ejemplo hipotético. Carlos tiene un saldo de 10 monedas y quiere pagar a dos vendedores, X e Y, cada uno por un valor de 10 monedas.

1. Carlos firma la Transacción A: enviar 10 monedas a Vendedor X.
2. Casi al mismo tiempo firma la Transacción B: enviar las mismas 10 monedas a Vendedor Y.
3. Aprovechando que la red no entrega los mensajes de forma instantánea, envía A a un grupo de réplicas y B a otro grupo distinto.

Si cada grupo de réplicas aceptara la primera transacción que ve, el primer grupo registraría el pago a X y el segundo el pago a Y. Cada vendedor vería su cobro confirmado y entregaría la mercancía. Carlos habría gastado 10 monedas dos veces y el libro contable quedaría partido en dos historias incompatibles, una bifurcación de estado.

Observa que Carlos no necesitó romper ninguna firma ni corromper ningún servidor. Le bastó con explotar la latencia y la falta de un orden común. El ataque no ataca la criptografía; ataca la coordinación.

El mismo ataque, visto como un problema bizantino

El caso empeora cuando quien reparte versiones distintas no es un cliente, sino un participante del propio protocolo. Imagina que las réplicas eligen a un líder que propone el orden, y que ese líder es malicioso: a unas réplicas les dice "primero A" y a otras "primero B". Eso es una equivocación, y es justo el escenario que Lamport, Shostak y Pease plantearon con los generales bizantinos.

En su formulación, un comandante envía una orden a sus tenientes, y el comandante puede ser un traidor que envía órdenes distintas a tenientes distintos. El objetivo es que todos los tenientes leales obedezcan la misma orden y que, si el comandante es leal, esa orden sea la suya. [1] Cambia "orden militar" por "siguiente transacción del registro" y tienes el problema del doble gasto en un libro contable replicado.

El mismo trabajo establece un límite duro: con mensajes orales, que el receptor puede reenviar alterados, no hay solución si un tercio o más de los generales son traidores; hacen falta más de $3m$ generales para tolerar $m$ traidores. [1] Ese tercio reaparece en todos los protocolos que estudiaremos en la serie.

La solución combinatoria: intersección de quórums

¿Cómo impide un consenso BFT que Carlos, o un líder malicioso, consiga dos confirmaciones? Mediante la intersección de quórums. Supongamos un comité de $n = 3f + 1$ réplicas, de las cuales a lo sumo $f$ son bizantinas. Para confirmar qué transacción ocupa una posición del registro hace falta un quórum de $q = 2f + 1$ votos.

PBFT usa precisamente esa regla: con $3f + 1$ réplicas, una fase avanza cuando una réplica reúne $2f + 1$ mensajes coincidentes para la misma vista y el mismo número de secuencia. [2] HotStuff la empaqueta en un objeto explícito, el QC, que reúne $n - f$ votos sobre la misma propuesta; con $n = 3f + 1$ eso son exactamente $2f + 1$ votos. [3]

Ahora el argumento. Si un quórum $Q_1$ confirmó A y otro quórum $Q_2$ confirmó B para la misma posición, ¿cuántas réplicas tienen en común?

$|Q_1 \cap Q_2| \ge (2f + 1) + (2f + 1) - (3f + 1) = f + 1$

Como a lo sumo $f$ réplicas son bizantinas, al menos una réplica del cruce es correcta. Y una réplica correcta sigue las reglas: en PBFT no acepta dos propuestas con contenidos distintos para la misma vista y el mismo número de secuencia, y en HotStuff no vota dos veces en la misma fase de una vista. [2] [3] Esa réplica no pudo votar por A y por B a la vez, así que los dos quórums no pueden existir simultáneamente.

Fíjate en lo que garantiza el argumento y en lo que no. No dice que la réplica honesta "detecte" a Carlos ni que sepa que hubo fraude. Dice algo más simple y más fuerte: es imposible reunir dos certificados válidos para dos contenidos distintos en la misma posición. La demostración completa, paso a paso, está en Quórums en acción.

Del orden único al rechazo del segundo pago

Una vez que el protocolo fija un único orden, el resto lo hace la ejecución determinista. Supongamos que el registro acordado queda con A en la posición 1 y B en la posición 2. Todas las réplicas correctas ejecutan A: el saldo de Carlos pasa de 10 a 0 y Vendedor X cobra. Después ejecutan B: la regla de validación encuentra saldo cero y rechaza la transferencia. Como todas aplican la misma regla, al mismo estado y en el mismo orden, todas rechazan B.

Esta es la intuición de la replicación de máquinas de estado, el marco en el que PBFT se presenta: un servicio determinista replicado cuyas réplicas parten del mismo estado y ejecutan la misma secuencia de operaciones. [2] HotStuff se plantea en el mismo marco: las réplicas acuerdan una secuencia creciente de comandos de los clientes y la ejecutan en ese orden. [3]

El reparto de responsabilidades queda limpio. El consenso decide qué va primero; la aplicación decide si cada transacción es válida dado lo que ya ocurrió. Ninguna de las dos piezas, por sí sola, detiene el doble gasto: sin orden único, cada réplica validaría contra un estado distinto; sin validación determinista, el orden único confirmaría dos pagos contra el mismo saldo.

Lo que el quórum no resuelve: tiempo y tamaño del comité

Hay dos límites que conviene tener presentes desde ahora. El primero es el tamaño mínimo del comité. Dwork, Lynch y Stockmeyer probaron que, en un modelo de sincronía parcial y con fallas bizantinas, el consenso es posible si y solo si $n \ge 3f + 1$. [4] Con menos réplicas, la aritmética del cruce deja de garantizar un testigo correcto.

El segundo límite es el tiempo. La intersección de quórums es un argumento puramente combinatorio: vale aunque la red retrase mensajes de forma arbitraria. Formar un quórum, en cambio, exige que lleguen los votos de $2f + 1$ réplicas, y eso solo está garantizado cuando la red se estabiliza. En el modelo de Dwork, Lynch y Stockmeyer, safety se mantiene siempre y el progreso depende de que la red termine comportándose de forma síncrona. [4] HotStuff adopta ese mismo modelo de sincronía parcial. [3]

La consecuencia práctica es una preferencia clara: ante la duda, el sistema prefiere no confirmar nada antes que confirmar dos historias. Un pago que tarda en confirmarse durante una partición de red es incómodo; un pago confirmado dos veces destruye la confianza en el registro.

Criterios clave

Siguiente lectura

Para ver con calma por qué los quórums de $2f + 1$ se cruzan y qué ocurre entre vistas, sigue con Quórums en acción. Si prefieres el panorama completo del consenso bizantino, empieza por Consenso BFT desde cero.