Firmas en BFT: threshold, aggregate y por qué AggQC no es un QC normal

HotStuff se suele explicar con una frase compacta: un líder junta 2f + 1 votos y produce un QC. La frase está bien para empezar, pero deja una bomba debajo de la alfombra: ¿qué tipo de firma estamos juntando y qué significa exactamente compactar evidencia? [3]

Esa pregunta importa muchísimo cuando llegamos a Fast-HotStuff. En el camino feliz, una certificación compacta se parece a lo que ya venimos usando: muchas réplicas firman una misma propuesta, el líder agrega votos y el resto verifica que existe quórum. En el camino infeliz, después de timeout, la historia cambia. Las réplicas ya no necesariamente firman el mismo mensaje: cada una puede reportar su highQC_i, y esos highQC_i pueden ser distintos. [4]

Ahí aparece AggQC. No es “un QC más grande” ni una decoración cripto. Es una prueba agregada de vista alta: el nuevo líder demuestra que recibió evidencia de un quórum y que seleccionó el highQC correcto según esa evidencia. Sin este puente, Fast-HotStuff se lee como latencia gratis. Con este puente, se ve la factura: menos espera en el camino feliz, más estructura en el cambio de vista. [4]

Primero: un voto BFT no es un like

Una réplica correcta no firma “porque sí”. Firma porque una propuesta satisface reglas locales: extiende la evidencia segura, no contradice su lock, usa una vista válida y respeta el mensaje que el protocolo espera. Si una réplica firma dos historias incompatibles bajo condiciones prohibidas, el sistema debe poder detectarlo o al menos apoyarse en el supuesto de que esa réplica ya no es correcta.

Por eso una firma es una pieza de control, no un adorno de seguridad. El líder no solo busca cantidad de firmas; busca firmas que prueben una condición concreta. En HotStuff básico, esa condición suele ser: “este bloque fue votado por un quórum en esta vista”. [3] En Fast-HotStuff, durante cambio de vista, la condición se vuelve más rica: “un quórum reportó sus highQC locales, y la propuesta extiende el máximo relevante”. [4]

La diferencia entre esas dos frases es la diferencia entre QC y AggQC.

BLS sin humo: por qué agrega tan bien

BLS suele aparecer como “la firma que se puede agregar”, pero eso es solo la mitad útil de la historia. La primitiva parte de una idea compacta: la clave privada es un escalar, la clave pública es ese escalar aplicado a un generador, y la firma aplica el mismo escalar al hash del mensaje mapeado a una curva. La verificación usa un emparejamiento bilineal para comprobar que la clave pública y la firma nacen del mismo secreto sin revelar el secreto. [1]

La razón por la que eso agrega bien es la bilinealidad: si varias firmas BLS están bien formadas, puedes sumar puntos y luego verificar una relación agregada. El diablo, como siempre, vive en el contrato exacto: ¿todas las firmas son sobre el mismo mensaje?, ¿son sobre mensajes distintos?, ¿todas las claves fueron registradas honestamente?, ¿necesitas prueba de posesión para evitar rogue-key attacks? El draft CFRG de BLS aterriza estas variantes en perfiles prácticos de firma básica, message augmentation y proof-of-possession. [8]

Threshold signatures no son simplemente “aggregate signatures con otro nombre”. En un threshold BLS, el secreto del comité se reparte en shares; cada réplica firma el mismo mensaje con su share y el combinador interpola suficientes firmas parciales para producir una firma que verifica contra la clave pública del comité. Esa intuición viene de secret sharing: con suficientes puntos reconstruyes la evaluación necesaria; con menos, no. [5] [6]

Multisignature vive en otra esquina: varias claves independientes firman el mismo mensaje y se compactan en una firma conjunta. Es atractiva para blockchains porque baja tamaño, pero obliga a cuidar el registro de claves y ataques rogue-key; si un atacante puede elegir su clave en función de las claves honestas, puede intentar que la agregación diga más de lo que realmente se firmó. [7] [8]

Aggregate signatures, en cambio, son la herramienta natural cuando los mensajes pueden ser distintos. Ahí no estás diciendo “un comité firmó una misma afirmación”, sino “esta colección de firmantes firmó esta colección de mensajes”. Para AggQC, esa diferencia no es cosmética: cada réplica reporta su highQC_i, y el protocolo necesita preservar qué reportó cada una para justificar el highQC* elegido. [2] [4]

QC con threshold signatures: todos empujan el mismo objeto

Imagina que el líder propone el bloque B en vista v. Las réplicas correctas verifican la propuesta y, si todo cuadra, firman algo equivalente a Vote(B, v). Si el líder junta 2f + 1 votos sobre ese mismo mensaje lógico, puede formar un QC. [3]

Con firmas individuales, el QC podría ser literalmente una lista de firmas. Funciona, pero es pesado. Con threshold signatures, cada réplica produce una firma parcial; el líder combina suficientes parciales en una firma compacta que verifica contra una clave pública agregada del comité. [1] Para el consumidor del QC, la prueba se siente como una sola firma: compacta, elegante, muy de paper con café caro.

La gracia es que todos firmaron el mismo mensaje. Ese detalle permite que el esquema threshold sea natural. El QC no necesita explicar una colección de opiniones distintas; solo prueba que un quórum firmó una misma afirmación.

Figura 1

QC normal: muchas firmas, una afirmación

Fuentes:

[3][1][6]

Cómo leer esta figura

A la izquierda hay una única afirmación Vote(B,v). Las réplicas producen firmas parciales sobre exactamente esos bytes; las flechas convergen en un QC compacto que representa 2f + 1 autorizaciones y se verifica como una prueba. La figura no describe AggQC: allí los reportes pueden contener highQCs diferentes y el contrato de verificación cambia.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Aggregate signatures: cuando no todos firman lo mismo

Ahora cambia la escena. La red se trabó, hubo timeout y entramos a new-view. Cada réplica envía al nuevo líder el highQC_i más alto que conoce. Una réplica puede reportar QC3; otra, QC4; otra quizá está rezagada; otra podría intentar mentir si es bizantina.

El líder necesita probar dos cosas: que recibió suficientes reportes y que eligió el highQC correcto según esos reportes. Si intentas meter esto en el molde de threshold signatures “todos firmaron el mismo mensaje”, algo chirría. Los mensajes no son idénticos. No estás agregando Vote(B, v) repetido; estás agregando declaraciones del tipo Timeout_i(v, highQC_i) o evidencia equivalente.

Aggregate signatures resuelven otro problema: permiten agrupar firmas de diferentes firmantes sobre mensajes potencialmente distintos. [2] No convierten la prueba en magia. Todavía debes saber qué firmó cada quien, verificar que hay 2f + 1, revisar que las claves corresponden al comité y validar que la selección de máximo highQC tiene sentido. Pero te dan una manera de transportar esa colección de declaraciones sin enviarla como un saco desordenado.

AggQC: la prueba de vista alta

AggQC es el nombre práctico de esa prueba agregada en Fast-HotStuff. Su propósito no es “hacer bonito” el cambio de vista. Su propósito es impedir que el nuevo líder elija una punta conveniente y vieja cuando el quórum reportó evidencia más avanzada. [4]

Piensa en un líder malicioso. Si solo le pedimos “propón sobre algún QC”, puede escoger un QC legal pero flojo. Tal vez no rompa safety de inmediato, pero degrada progreso, desperdicia trabajo y puede sostener ataques de rendimiento. Si le pedimos “propón sobre el highQC máximo probado por un quórum”, ya no basta con escoger a gusto. Debe enseñar el paquete de evidencia.

AggQC hace eso: agrega firmas sobre los highQC_i, permite seleccionar highQC* = maxView(highQC_i) y vincula la nueva propuesta con ese máximo. La propuesta ya no llega desnuda; llega con recibos.

Qué gana Fast-HotStuff y qué paga

Fast-HotStuff intenta acortar el camino feliz. Si todo va bien, quiere confirmar con menor latencia que HotStuff básico. Eso suena excelente, porque en sistemas distribuidos una ronda menos puede sentirse como quitarle una piedra al zapato. [4] [3]

Pero la latencia no desaparece; se redistribuye. El camino infeliz debe cargar una prueba más expresiva. Las implementaciones deben manejar firmas agregadas, selección de highQC, timeouts, validación de mensajes distintos, potenciales costos de verificación y reglas de accountability. En comités grandes, la pregunta de costo no es decorativa: ¿cuántos pares clave-mensaje verificas?, ¿cuánto pesa la prueba?, ¿cómo cacheas?, ¿qué haces si un líder omite reportes útiles?

La lectura madura no es “threshold signatures buenas, aggregate signatures malas”. La lectura madura es: cada herramienta compacta una forma distinta de evidencia. Threshold signatures brillan cuando el mensaje común es claro. Aggregate signatures brillan cuando necesitas transportar muchas declaraciones relacionadas pero no idénticas.

Profundización conceptual

Modelo mental: QC es consenso sobre un mensaje; AggQC es consenso sobre evidencia reportada

Un QC normal responde: “¿un quórum votó este bloque en esta vista?”. AggQC responde una pregunta diferente: “¿un quórum reportó suficiente evidencia para que el nuevo líder deba extender este highQC?”. [3] [4]

La diferencia parece pequeña, pero cambia la forma de razonar. En QC, el objeto central es la propuesta. En AggQC, el objeto central es el conjunto de evidencias que el nuevo líder recibió. Por eso AggQC no debe aparecer en la serie como un acrónimo suelto. Debe aparecer donde el lector ya sabe qué es highQC, qué significa view-change y por qué elegir una punta vieja puede ser legalmente incómodo.

Invariante: el líder no puede degradar la punta certificada sin dejar rastro

El invariante operativo es claro: si un quórum reporta un highQC alto, el nuevo líder no debería poder proponer sobre un highQC más bajo sin que el protocolo lo detecte o rechace. AggQC convierte ese invariante en una prueba transportable. [4]

Esto no reemplaza todos los checks locales. Las réplicas todavía deben verificar vista, firma, quórum, pertenencia al comité y relación de extensión. AggQC no apaga el cerebro de los validadores; les entrega una evidencia mejor empaquetada para tomar la decisión.

Escenario adversarial: el líder hace cherry-picking de reportes

Supón que cuatro réplicas reportan sus highQC locales. Tres tienen una vista alta y una está atrasada. Un líder malicioso podría querer mostrar solo el reporte atrasado para construir una propuesta más cómoda. Si el protocolo acepta “algún QC”, el ataque puede avanzar como degradación de rendimiento. Si exige AggQC con 2f + 1 reportes y selección de máximo, el líder necesita exponer la evidencia que contradice su cherry-picking.

La gracia no es que el líder se vuelva honesto. La gracia es que el protocolo le reduce el espacio para mentir sin pruebas verificables.

Cómo leer Fast-HotStuff después de esto

Cuando pases a Fast-HotStuff, lee el happy path y el unhappy path como dos presupuestos distintos. En happy path, la optimización busca latencia. En unhappy path, AggQC compra seguridad y progreso razonable frente a timeouts y líderes flojos. Si un diagrama no muestra esa separación, falta una pieza.

También conviene mantener un ojo en el tamaño del comité. Un paper puede decir “agregamos firmas” con mucha elegancia; una implementación tiene que decidir bibliotecas, formatos de mensaje, validación incremental, caches, perfiles de CPU y cómo reportar evidencia para debug. Ahí la teoría baja al taller y se ensucia las manos, como debe ser.