BFT en consorcios bancarios vs. redes públicas: El dilema del control de identidad

Un error frecuente es pensar que el protocolo BFT es lo único que importa y que el entorno de despliegue es un detalle operativo. En realidad, cada protocolo de la familia PBFT y HotStuff trae una premisa silenciosa: sabemos cuántas réplicas hay y quiénes son. Este capítulo examina qué pasa con esa premisa en un consorcio, por ejemplo un grupo de bancos que comparte un libro contable, y qué pasa cuando la red es pública y cualquiera puede unirse.

Usaremos Hyperledger Fabric como caso de estudio del lado permisionado, porque su paper describe con precisión quién certifica identidades, quién ordena transacciones y qué supuestos de confianza hace cada componente. [1]

La premisa oculta: un conjunto fijo de réplicas conocidas

PBFT tolera hasta $f$ réplicas bizantinas con $n = 3f + 1$ réplicas, y sus mensajes van autenticados con criptografía cuyas claves conocen todas las réplicas. [2] El umbral solo tiene sentido si cada réplica corresponde a un participante independiente. Si un atacante pudiera registrar diez réplicas con diez claves distintas, el número $f$ dejaría de medir algo real.

HotStuff hace explícito el mismo modelo: un conjunto fijo de $n = 3f + 1$ réplicas indexadas, con firmas umbral cuya clave pública comparten todas ellas. [3] El propio paper sitúa su motivación en las blockchains permisionadas, que describe como un conjunto fijo de réplicas que mantiene un libro ordenado, en contraste con las redes sin permiso como la de Bitcoin, donde los participantes son desconocidos. [3] También observa que, aunque los protocolos BFT clásicos se pensaban para $n = 4$ o $n = 7$ en una red local, en blockchains permisionadas se contemplan cientos o incluso miles de réplicas, lo que vuelve crítica la complejidad de comunicación. [3]

Esa es la línea que divide los dos mundos. En un consorcio, la membresía es un dato de entrada administrado fuera del protocolo. En una red abierta, la membresía es parte del problema que el protocolo tiene que resolver.

Cómo un consorcio certifica identidades en Fabric

Fabric define una blockchain permisionada como una que se ejecuta entre participantes conocidos e identificados, y señala que, al apoyarse en esas identidades, puede usar consenso BFT tradicional. [1] El componente que materializa esa idea es el membership service provider (MSP): mantiene las identidades de clientes, peers y nodos de ordenamiento, y emite las credenciales que se usan para autenticar y autorizar. [1]

La implementación por defecto del MSP usa métodos PKI estándar basados en firmas digitales y admite autoridades de certificación comerciales; Fabric incluye además su propia CA. [1] Un detalle operativo revela la filosofía: según el paper, peers y nodos de ordenamiento solo pueden registrarse en modo offline, mientras que los clientes pueden obtener credenciales en línea. [1] Unirse como réplica no es algo que un desconocido pueda hacer desde internet.

El MSP también permite federar identidades: cada organización emite credenciales para sus propios miembros y todos los peers reconocen a los miembros de todas las organizaciones. [1] Para un consorcio bancario, esto encaja con la realidad institucional. Cada banco gestiona sus claves, y una firma sobre un mensaje identifica a una organización con nombre y responsabilidad fuera del sistema.

Ejecutar, ordenar, validar: la arquitectura de Fabric

La mayoría de las blockchains anteriores seguían el patrón order-execute: primero se ordenan las transacciones con consenso y luego cada peer las ejecuta en secuencia. Fabric señala dos costos de ese diseño: todos los peers ejecutan todo, y el código debe ser determinista o las réplicas divergen. [1] Los autores cuentan que las versiones anteriores de Fabric, hasta la v0.6, seguían ese patrón con PBFT, y que muchos reportes de "bugs de consenso" resultaron ser chaincode no determinista. [1]

La respuesta es la arquitectura execute-order-validate, que la figura recorre paso a paso. [1]

Figura 1

Execute-order-validate en Hyperledger Fabric

Fuentes:

[1]

Cómo leer esta figura

Tres columnas. En Ejecutar, un cliente firma una propuesta y la envía a tres endorsers, que simulan el chaincode sobre su estado local sin persistir nada; cada uno firma un readset y un writeset y el cliente junta endosos idénticos que cumplen la política, por ejemplo tres de cinco. En Ordenar, la transacción entra por broadcast a un servicio de cuatro nodos OSN, intercambiable entre CFT y BFT, que no ve el estado ni ejecuta ni valida y produce un bloque s con las transacciones y el hash del bloque anterior. En Validar, cada peer recibe el bloque por deliver y aplica tres pasos: política de endoso en paralelo, chequeo de conflictos lectura-escritura y escritura del bloque y del writeset de las transacciones válidas; las inválidas quedan en el bloque marcadas en un bitmask.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

En la fase de ejecución, el cliente envía la propuesta firmada a los endorsers que indica la política de endoso del chaincode. Cada endorser simula la operación sobre su estado local, sin coordinarse con los demás y sin persistir nada, y firma un endoso que contiene el readset (claves leídas con su versión) y el writeset (claves modificadas con su nuevo valor). [1] El cliente acumula endosos hasta satisfacer la política, que puede ser una expresión como "tres de cinco"; los endorsers exigidos deben producir el mismo resultado. [1]

En la fase de ordenamiento, la transacción con sus endosos se entrega al servicio de ordenamiento, que establece un orden total por canal y agrupa las transacciones en bloques encadenados por hash. [1] El paper especifica sus propiedades de safety: dos peers correctos que entregan el bloque con el mismo número reciben el mismo bloque, la cadena de hashes es íntegra, no se salta ningún número y no aparece ninguna transacción que algún cliente no haya enviado. [1]

En la fase de validación, cada peer evalúa la política de endoso de todas las transacciones del bloque en paralelo, luego comprueba en secuencia que las versiones del readset sigan vigentes y, al final, escribe el bloque y aplica los writesets válidos. [1] Las transacciones inválidas no desaparecen: quedan en el libro, marcadas con una máscara de bits, lo que según los autores sirve para auditar intentos fallidos. [1]

La consecuencia más interesante es sobre el no determinismo. Como la ejecución ocurre antes del consenso y la validación posterior es determinista, un chaincode no determinista solo pone en riesgo la liveness de sus propias operaciones, porque el cliente quizá no reúna endosos coincidentes; no rompe la consistencia entre peers. [1]

Quién opera el servicio de ordenamiento

El servicio de ordenamiento es la pieza donde vive el consenso. Fabric lo diseña sin estado de aplicación: los nodos de ordenamiento no ejecutan ni validan transacciones, y el paper subraya que esa separación total entre consenso, ejecución y validación es lo que permite reemplazar el protocolo. [1] El argumento de fondo es que no existe un protocolo BFT único que sirva para todos los despliegues, de modo que el supuesto de confianza del ordenamiento debe poder ajustarse a cada caso. [1]

Conviene leer con atención qué ofrecía Fabric en el momento del paper. A partir de la v1.0.6 había tres implementaciones: un ordenador centralizado de un solo nodo para desarrollo, un servicio tolerante a caídas (CFT) basado en Kafka y ZooKeeper, y una prueba de concepto sobre BFT-SMaRt que tolera hasta un tercio de nodos de ordenamiento bizantinos. [1] Es decir, el diseño admite BFT, pero la configuración de producción que describe el paper toleraba caídas, no mentiras.

Esa distinción importa para el modelo de confianza. Fabric considera potencialmente bizantinos a todos los clientes, agrupa los peers en organizaciones que funcionan como dominios de confianza y declara que la integridad de la red depende de la consistencia del servicio de ordenamiento. [1] Si un consorcio confía el ordenamiento a un clúster CFT operado por un solo miembro, ese miembro se convierte en el punto de confianza del sistema. Si cada banco opera una réplica de un ordenamiento BFT, vuelve a aplicar la cuenta de PBFT: con $n = 3f + 1$ operadores independientes, el orden sobrevive a $f$ de ellos comportándose de forma arbitraria. [2]

Fabric añade una capa que los protocolos BFT clásicos no tienen: la política de endoso desacopla la confianza de cada aplicación de la confianza del consenso. [1] Un contrato de liquidación puede exigir endosos de las dos contrapartes y de un auditor, sin importar cuántos nodos de ordenamiento existan.

Sobre rendimiento, el paper reporta más de 3500 transacciones por segundo de extremo a extremo, con latencia de unos cientos de milisegundos y buen escalado por encima de 100 peers, en sus configuraciones de prueba. [1] Esas cifras se midieron con el ordenamiento Kafka, que no fue el cuello de botella en un mismo centro de datos; el límite lo marcó la validación, cara por la verificación de firmas. [1] No son, por tanto, una medida del costo de un ordenamiento BFT.

Redes abiertas: el problema Sybil y el precio de una identidad

Al pasar a una red pública desaparece la autoridad que emitía credenciales. Douceur llamó ataque Sybil a la falsificación de múltiples identidades: en sistemas que se protegen con redundancia, una entidad defectuosa que presenta varias identidades puede controlar una fracción sustancial del sistema y anular esa redundancia. [4] Su conclusión es directa: sin una autoridad lógicamente centralizada que certifique identidades, los ataques Sybil son siempre posibles salvo bajo supuestos extremos y poco realistas de paridad de recursos y coordinación entre entidades. [4]

Douceur también analiza la alternativa de validar identidades con pruebas de recursos, como cómputo, almacenamiento o comunicación, y muestra su límite: una entidad con $\rho$ veces los recursos de una entidad mínima puede presentar hasta $\rho$ identidades distintas. [4] Dicho de otro modo, el recurso no impide que un actor tenga muchas identidades; solo hace que su influencia sea proporcional a lo que posee.

Esa es la idea que heredan las redes abiertas, y aquí entramos en interpretación propia. Si no se puede saber cuántas entidades hay detrás de las claves, el umbral deja de contarse en réplicas y pasa a medirse en un recurso escaso. Bitcoin usa trabajo de cómputo, como recuerda el paper de HotStuff al describir el modelo sin permiso. [3]

Las redes de prueba de participación usan capital depositado como peso de voto y exigen supermayorías sobre ese peso, no sobre el número de validadores. El razonamiento de intersección de quórums se mantiene, pero el supuesto de fallas cambia de forma: ya no es "a lo sumo $f$ réplicas mienten" sino "a lo sumo una fracción del peso total está en manos adversarias".

El precio es que el conjunto de validadores y sus pesos cambian con el tiempo, y el protocolo tiene que gestionar entradas, salidas y reconfiguraciones que en un consorcio se resuelven con un acuerdo entre organizaciones. Ese problema se trata en la reorganización dinámica de validadores, y los ataques que aprovechan identidades baratas se analizan en vectores de ataque BFT.

Trade-offs: qué compras con cada modelo

En un consorcio, la pregunta de diseño es de gobernanza: quién opera cada pieza. Fabric permite que un banco decida a quién pedir endosos y que el consorcio elija qué tolerancia exige al ordenamiento, pero el mismo diseño admite configuraciones donde un único operador concentra la confianza. [1] El protocolo BFT protege el orden solo si sus réplicas están en manos de entidades realmente independientes.

En una red abierta, la pregunta es económica y de reconfiguración. El umbral de seguridad ya no depende de un registro firmado sino de cuánto recurso controla el adversario, y una fracción adversaria grande rompe las garantías aunque el protocolo esté bien implementado. [4]

Hay un tercer elemento compartido: la escala. HotStuff nace de que incluso las blockchains permisionadas contemplan cientos o miles de réplicas en redes de área amplia, donde el costo de comunicación de un cambio de líder deja de ser despreciable. [3] Fabric, por su parte, advierte que el consenso suele estar limitado por el ancho de banda y no escala añadiendo nodos de ordenamiento; su throughput tiende a bajar. [1] Por eso separa ordenamiento de difusión y deja que los bloques lleguen a los peers por gossip.

Siguiente lectura

Para ver un motor BFT académico que llegó a producción en el mundo permisionado, continúa con ResilientDB: el motor BFT académico productivo. Si quieres repasar por qué $n = 3f + 1$ y quórums de $2f + 1$ bastan cuando las réplicas están certificadas, vuelve a Quórums en acción.