ResilientDB: El motor BFT universitario que escaló a la industria

En esta serie hemos tratado los protocolos de consenso como algoritmos: fases, quórums, certificados y reglas de bloqueo. Pero un protocolo correcto puede rendir muy poco si la réplica que lo ejecuta procesa cada solicitud de principio a fin antes de mirar la siguiente. ResilientDB nació en ese cruce entre algoritmo e implementación.

El trabajo de Suyash Gupta, Sajjad Rahnama, Jelle Hellings y Mohammad Sadoghi, publicado en PVLDB en 2020, presenta ResilientDB como un fabric de blockchain permisionado tolerante a fallas bizantinas y, dentro de él, el protocolo GeoBFT para despliegues repartidos por el mundo. [1] El proyecto nació en un laboratorio de UC Davis y más tarde siguió como código abierto en el ecosistema de la Apache Software Foundation; aquí nos centramos en lo que documenta el paper, no en el estado actual del repositorio.

El problema: PBFT cuando las réplicas están en continentes distintos

PBFT ordena solicitudes con un primario y tres fases. Tras el pre-prepare del primario, las fases prepare y commit son difusiones de todas las réplicas a todas, y una réplica considera una solicitud comprometida cuando reúne $2f + 1$ mensajes commit coincidentes de un comité de $n = 3f + 1$ réplicas. [2] Ese patrón cuesta un número cuadrático de mensajes por decisión.

En una sola región ese coste se tolera. Cuando las réplicas están en varios continentes, casi todos esos mensajes cruzan enlaces de área amplia, con más latencia y menos ancho de banda que una red local. ResilientDB parte de esa observación: un protocolo que ignora la topología paga el precio más caro de la red en cada fase. [1]

HotStuff atacó el coste cuadrático por otra vía: todas las réplicas hablan con el líder, que agrega $n - f$ votos en un QC, con lo que el camino normal y el cambio de vista tienen complejidad lineal en autenticadores. [3] GeoBFT elige otra palanca: en lugar de reducir los mensajes por réplica, decide qué mensajes deben viajar lejos y cuáles pueden quedarse en casa. [1]

Dentro de una réplica: un pipeline de etapas especializadas

Antes de distribuir el consenso entre regiones, el paper insiste en que la propia réplica debe estar bien construida. ResilientDB organiza el trabajo de cada réplica como un pipeline multihilo: distintos hilos se ocupan de etapas distintas y se pasan el trabajo mediante colas, de forma que la red, el consenso y la ejecución avanzan en paralelo sobre solicitudes diferentes. [1]

Recorramos esas etapas en prosa. Primero, unos hilos de entrada reciben mensajes de la red, tanto solicitudes de clientes como mensajes de protocolo de otras réplicas, y los colocan en colas para las etapas siguientes. En el primario, otra etapa agrupa solicitudes de clientes en lotes, porque consensuar un lote amortiza el coste de cada ronda entre muchas transacciones. [1]

Después, la etapa de consenso procesa las fases del protocolo: valida mensajes, cuenta votos y detecta cuándo un lote alcanzó su certificado. Una vez comprometido, el lote pasa a la etapa de ejecución, que aplica las transacciones en el orden acordado; ese orden debe respetarse aunque los lotes terminen el consenso en desorden. Finalmente, unos hilos de salida envían respuestas a los clientes y mensajes a las demás réplicas. En la implementación de GeoBFT que describe el paper, el primario tiene un hilo de entrada dedicado a clientes, cada réplica tiene dos hilos de entrada para el resto de mensajes y dos de salida, y el orden y la ejecución los llevan los hilos worker, execute y certify. [1]

La idea de fondo es clásica en sistemas: si cada etapa tiene su propio hilo, el rendimiento queda limitado por la etapa más lenta y no por la suma de todas. Esto es una intuición de ingeniería, no un teorema; los cuellos de botella reales dependen de la verificación criptográfica, del tamaño de lote y de la red, y el paper los estudia de forma experimental. [1]

GeoBFT: consenso local, certificados compartidos

GeoBFT agrupa las réplicas en clústeres, típicamente uno por región. Cada clúster tiene su propio primario y tolera hasta $f$ réplicas bizantinas internas, con la misma aritmética de quórums que PBFT. [1] [2] Las rondas de GeoBFT tienen cuatro piezas.

Replicación local. En cada ronda, cada clúster ejecuta PBFT internamente sobre una solicitud o lote de sus clientes. El resultado no es solo un acuerdo local, sino un certificado de commit: $2f + 1$ mensajes commit firmados por réplicas del clúster, que cualquier tercero puede verificar. [1] Es el mismo papel que juega un QC en HotStuff: un objeto transferible que prueba que un quórum respaldó una decisión. [3]

Compartición global. El primario de cada clúster envía la decisión y su certificado a $f + 1$ réplicas de cada clúster remoto. Como a lo sumo $f$ réplicas de ese clúster remoto son bizantinas, al menos una receptora es correcta. [1] El número de mensajes que cruzan regiones crece con el número de clústeres y con $f$, no con el cuadrado del total de réplicas.

Compartición local. Cada réplica que recibe un certificado remoto válido lo difunde dentro de su propio clúster. Esos mensajes viajan por la red local, que es la barata. Así todas las réplicas correctas terminan con la decisión certificada de cada clúster sin que cada una hable con todas las del mundo. [1]

Ordenamiento y ejecución. Cuando una réplica tiene las decisiones certificadas de todos los clústeres para la ronda, las ejecuta en un orden determinista fijado de antemano entre clústeres. Como el orden es común y cada decisión está certificada, todas las réplicas correctas aplican la misma secuencia. [1]

Cuando un clúster no entrega: el cambio de vista remoto

El punto delicado es un primario bizantino que se calla ante el resto del mundo. Dentro de su clúster puede comportarse bien y, sin embargo, no enviar el certificado a los clústeres remotos. Las réplicas remotas no pueden reemplazar a un primario que no pertenece a su clúster usando solo el cambio de vista local de PBFT. [2]

GeoBFT añade un cambio de vista remoto. Si las réplicas de un clúster no reciben a tiempo la decisión de otro clúster, lo detectan y se lo hacen saber a las réplicas de ese clúster. Las réplicas del clúster afectado pueden entonces reemplazar a su primario mediante su propio cambio de vista. [1] Igual que en PBFT y en HotStuff, la liveness depende de que la red acabe comportándose de forma suficientemente síncrona para que los temporizadores distingan un primario lento de uno que falla. [2] [3]

La seguridad no se apoya en esos temporizadores. Una decisión entra al orden global solo con un certificado de $2f + 1$ commits de su clúster, y dentro de cada clúster rige la intersección de quórums de PBFT. [1] [2] Hay un supuesto adicional que conviene leer con cuidado: la tolerancia se define por clúster, así que un clúster con más de $f$ réplicas bizantinas rompe las garantías aunque el sistema en conjunto tenga muchas réplicas correctas.

Qué aprende un lector de HotStuff de ResilientDB

La comparación útil no es "cuál gana", sino qué recurso optimiza cada diseño. HotStuff reduce la complejidad de comunicación por decisión con un líder que agrega votos en QCs y encadena fases. [3] GeoBFT acepta el patrón de PBFT dentro de cada clúster y reduce el tráfico de larga distancia, además de permitir que varios clústeres propongan en paralelo en cada ronda en lugar de depender de un único primario global. [1]

La evaluación del paper compara GeoBFT, dentro del mismo fabric, con otros protocolos, entre ellos PBFT y HotStuff, en despliegues repartidos por varias regiones. [1] Las cifras concretas dependen de su configuración experimental, así que no conviene trasladarlas como promesa a otro despliegue. La lección transferible es metodológica: comparar protocolos sobre la misma implementación, con el mismo pipeline y la misma criptografía, separa el efecto del algoritmo del efecto de la ingeniería.

Siguiente lectura

Si quieres repasar las tres fases que GeoBFT reutiliza dentro de cada clúster, vuelve a PBFT de 1999 y sus tres pasos. Para el enfoque alternativo de reducir comunicación con un líder que agrega votos, sigue con QC, highQC y three-chain en HotStuff.