La metáfora del banco sin cajero central: ¿Quién valida las transacciones?

En un banco tradicional existe un gran ordenador central, un mainframe o un servidor de base de datos, que supervisa todo. Si ese servidor se cae, sufre un incendio en el centro de datos o es comprometido, el banco entero deja de funcionar o, peor, empieza a funcionar mal sin que nadie lo note. Es un punto único de fallo.

Imaginemos ahora un banco radicalmente distinto: diez cajeros independientes sentados en la misma sala, donde no existe ningún jefe central ni servidor principal. Cada cajero tiene sobre su mesa un cuaderno de contabilidad y una calculadora.

¿Cómo pueden estos diez cajeros procesar retiros, depósitos y transferencias durante todo el día y asegurar que, al cerrar la jornada, todas las libretas tengan exactamente los mismos saldos? Y una pregunta más incómoda: ¿qué pasa si alguno de los cajeros se equivoca o, directamente, miente?

Por qué copiar el cuaderno no basta

La primera idea para eliminar el punto único de fallo es obvia: tener varias copias. Pero copiar el cuaderno una vez por la mañana no sirve de mucho, porque a lo largo del día cada cajero atiende a clientes distintos. Si el cajero 3 registra un retiro que el cajero 7 no conoce, al mediodía ya hay dos versiones del saldo del mismo cliente.

La segunda idea es que cada cajero anuncie en voz alta cada operación y los demás la apunten. Eso mejora las cosas, pero introduce un problema sutil: los anuncios llegan a cada mesa en momentos distintos. Si dos clientes operan sobre la misma cuenta casi a la vez, unos cajeros apuntarán primero el depósito y otros primero el retiro. Si el retiro solo es válido después del depósito, unos cajeros lo aceptarán y otros lo rechazarán.

Es el mismo problema que vimos en el ataque del doble gasto, visto desde dentro del banco. Lo que hay que replicar no es el cuaderno, sino la secuencia de operaciones que lo modifica, y esa secuencia tiene que ser la misma para todos.

Las dos reglas de SMR: orden total y determinismo

Para que el banco sin jefe funcione, los cajeros deben seguir dos reglas.

Primera regla, orden total. Todas las transacciones reciben una posición en una secuencia global única: $1, 2, 3, \dots$. No importa quién llegó primero a la ventanilla de cada cajero; lo que importa es la posición oficial asignada en esa secuencia. Dos cajeros correctos nunca pueden tener transacciones distintas en la misma posición.

Segunda regla, determinismo. La regla para procesar una transacción depende únicamente del estado actual y de la propia transacción. Si la cuenta de Juan tiene 500 unidades y se procesa "retirar 200", el resultado tiene que ser 300 en todas las mesas. No puede depender de la hora local, de un número aleatorio ni de qué cajero lo calcula.

Castro y Liskov enuncian estas condiciones de forma explícita para PBFT: el servicio se modela como una máquina de estados replicada en varios nodos, y las réplicas deben ser deterministas y empezar en el mismo estado. [2] El protocolo se encarga entonces de que las réplicas no defectuosas acuerden un orden total para ejecutar las peticiones. [2]

Las dos reglas se reparten el trabajo de forma muy limpia. El determinismo es responsabilidad de quien escribe la aplicación, y es relativamente fácil de cumplir si se evitan fuentes de azar. El orden total es el problema difícil, porque hay que conseguirlo sin un jefe, con una red que retrasa mensajes y con algunos participantes que pueden fallar. Ese problema es el consenso.

Cuando un cajero miente: réplicas bizantinas

Hasta aquí hemos supuesto cajeros honestos que, como mucho, se distraen o se van a casa. En un sistema abierto hay que contemplar algo peor: un cajero que anuncia operaciones falsas, que dice una cosa a unos compañeros y otra distinta a otros, o que responde a un cliente con un saldo inventado. A ese comportamiento arbitrario se le llama falla bizantina.

El nombre viene del trabajo de Lamport, Shostak y Pease sobre los generales bizantinos, donde un traidor puede enviar mensajes contradictorios a distintos participantes. [1] Ese mismo trabajo dedica una sección a cómo construir sistemas fiables con varios procesadores que calculan el mismo resultado y votan por mayoría, y subraya la condición clave: todos los procesadores correctos deben usar la misma entrada. [1] Es la semilla de nuestra regla de orden total: si las entradas difieren, la votación pierde su sentido.

Lamport, Shostak y Pease también muestran el precio. Con mensajes orales, que pueden alterarse al retransmitirse, no hay solución si un tercio o más de los generales son traidores. [1] Por eso los protocolos prácticos como PBFT usan $3f + 1$ réplicas para tolerar $f$ bizantinas. [2] En nuestro banco de diez cajeros, eso significa tolerar como mucho tres cajeros deshonestos, porque $3 \cdot 3 + 1 = 10$.

Quién valida: el cliente frente a varias respuestas

Volvamos a la pregunta del título. En el banco sin jefe nadie valida en solitario. Cada réplica correcta valida cada transacción contra su propio estado, y como todas tienen el mismo estado y el mismo orden, todas llegan a la misma conclusión. La validación está replicada igual que los datos.

Eso cambia también la forma de hablar con el banco. Un cliente no puede fiarse de la respuesta de un único cajero, porque ese cajero podría ser uno de los deshonestos. En PBFT el cliente espera respuestas con el mismo resultado de $f + 1$ réplicas distintas; como a lo sumo $f$ son defectuosas, al menos una de esas respuestas procede de una réplica correcta. [2]

HotStuff conserva este marco. Se presenta como un protocolo de replicación BFT basado en líder para el modelo de sincronía parcial, en el que las réplicas acuerdan una secuencia creciente de comandos de los clientes. [3] Lo que cambia respecto a PBFT es cómo se consigue ese acuerdo y cuánto cuesta reemplazar a un líder, no el objetivo de fondo. [3]

Ojo con una trampa frecuente: "sin cajero central" no significa "sin coordinador". Tanto PBFT como HotStuff eligen en cada momento un líder que propone el orden. La diferencia con el banco tradicional es que ese líder no tiene autoridad final: su propuesta solo cuenta si la respaldan suficientes réplicas, y si falla o miente, el protocolo lo reemplaza.

Qué gana el banco y qué paga

En la banca tradicional, sistemas distintos que llevan registros separados necesitan procesos de reconciliación para detectar discrepancias después del hecho. Con SMR la discrepancia entre réplicas correctas no se corrige más tarde: se evita desde el principio, porque todas ejecutan la misma secuencia.

El precio también es real. Hacen falta más máquinas, al menos $3f + 1$ para tolerar $f$ bizantinas, y cada transacción requiere rondas de mensajes entre ellas antes de confirmarse. [2] Además, el determinismo impone disciplina a la aplicación: cualquier fuente de no determinismo, como leer el reloj local, tiene que tratarse explícitamente o romperá la coincidencia de estados.

Criterios clave

Siguiente lectura

Para ver cómo PBFT convierte estas reglas en un protocolo concreto, sigue con PBFT 1999: tres pasos de confirmación. Si quieres el panorama general antes, empieza por Consenso BFT desde cero.