Resumen Técnico: BigDipper

Planteamiento del Problema

Los protocolos de Tolerancia a Fallas Bizantinas (BFT) basados en líderes son dominantes en los sistemas blockchain de producción debido a su baja latencia y estructuras de comunicación simples. Sin embargo, otorgan al líder un control a corto plazo sobre la inclusión de transacciones. Un líder malicioso puede mantener el protocolo vivo (asegurando la liveness) mientras retrasa o excluye selectivamente transacciones sensibles al tiempo, como subastas, actualizaciones de oráculos, liquidaciones y mensajes de puentes (bridges). Este fenómeno, denominado censura a corto plazo, no es capturado por las garantías estándar de liveness de los protocolos BFT.

Las soluciones existentes suelen codificar mecanismos de anti-censura, ocultación u ordenamiento fuertes directamente en el camino del consenso. Aunque son efectivas para casos de uso específicos, estos enfoques obligan a todas las transacciones a pagar el mismo alto costo de protección, independientemente de si una transacción específica requiere tal robustez. Este documento argumenta a favor de un diseño más modular que se adhiera al principio de extremo a extremo (end-to-end principle): la capa de consenso debe exponer primitivas mínimas para el ordenamiento seguro y la disponibilidad de datos, dejando la elección de las estrategias de resistencia a la censura y sus costos a las aplicaciones de capas superiores.

Metodología

BigDipper introduce una capa de Disponibilidad de Datos con Resistencia a la Censura (DA-CR) posicionada entre la sumisión de transacciones y el consenso BFT basado en líderes. El sistema está diseñado en torno a tres componentes principales:

1. Abstracción DA-CR: Una capa donde las réplicas contribuyen con mini-bloques, y un mecanismo certifica qué datos están disponibles y deben ser capturados por el líder. Esta capa se caracteriza por los parámetros $(t, \eta)$, donde $t$ representa la inclusión garantizada de mini-bloques honestos, y $\eta$ representa la capacidad residual del líder para capturar espacio (excluir datos).
2. Camino Crítico de Consenso Fragmentado (Sharded): A diferencia de los diseños tradicionales donde los validadores deben descargar y ejecutar la carga útil (payload) completa del bloque, BigDipper mantiene los datos fragmentados en el camino crítico. Los validadores votan basándose en compromisos compactos, evidencia de disponibilidad y reglas de inclusión de DA-CR en lugar de reconstruir la carga útil completa.
3. Sumisión Ajustable por el Cliente (Navigator): Un protocolo de diseminación de transacciones donde los clientes eligen un parámetro de "fanout" $x$, enviando transacciones a $x$ réplicas distintas. Esto permite a los clientes intercambiar el costo de comunicación por la probabilidad de una inclusión pronta.

Construcciones Principales

El documento presenta construcciones concretas de DA-CR basadas en codificación de borrado de Reed-Solomon (RS) y compromisos polinómicos lineales (KZG):

• Card-7: Un protocolo contable donde el líder debe proporcionar atestaciones de los mini-bloques incluidos. Garantiza que se incluyan $t = n - 2f$ mini-bloques honestos y que $\eta = 0$ (sin captura de espacio). Requiere $n \ge 3f + 1$.
• Card-1/4: Una variante no contable con menor sobrecarga. Elimina el requisito de atestaciones públicas, permitiendo que el líder oculte qué réplicas fueron incluidas. Logra $t = n - 3f$ y $\eta = n - f - 1$, requiriendo un supuesto más fuerte de $n \ge 4f + 1$.
• Card-Lite: Una optimización de Card-7 utilizando un esquema de compromiso doblemente homomórfico. Reduce la sobrecarga por réplica a $O(\log n)$ mediante el muestreo de compromisos en lugar de transmitir la lista completa, manteniendo $t \approx n - 2f$.

Integración con HotStuff-2

BigDipper se instancia dentro de HotStuff-2. La integración es quirúrgica, introduciendo una regla de Recolección (Scooping rule) como predicado de validez. Una propuesta del líder es válida solo si incorpora un output de DA-CR completado (un certificado que prueba la disponibilidad de datos y la inclusión de los mini-bloques requeridos). Esto no altera el núcleo de seguridad de HotStuff-2, pero evita que los líderes progresen sin capturar los datos requeridos contribuidos por las réplicas.

Contribuciones Clave

1. Abstracción Modular para la Resistencia a la Censura a Corto Plazo: La introducción de DA-CR, que desacopla el mecanismo de disponibilidad de datos de las políticas específicas de resistencia a la censura. Formaliza los compromisos entre la inclusión garantizada ($t$) y la influencia del líder ($\eta$).
2. Camino de Datos Fragmentado y Escalable: Un diseño donde los validadores ordinarios no necesitan descargar la carga útil completa del bloque para votar. Verifican compromisos y metadatos, permitiendo que el ancho de banda de la propuesta agregada escale con la contribución de datos de la réplica en lugar de estar limitado por el ancho de banda de entrada de un solo líder.
3. Resistencia a la Censura Ajustable por el Cliente: El protocolo Navigator permite a los clientes amplificar la probabilidad de inclusión aumentando su fanout. El documento analiza el intercambio costo/seguridad, demostiendo mediante un argumento de unión (union-bound) que la censura amplia se vuelve exponencialmente improbable a medida que aumentan el número de transacciones enviadas y las réplicas.
4. Integración y Análisis Concreto: Una instanciación completa de BigDipper dentro de HotStuff-2, demostrando que DA-CR puede conectarse precisamente con protocolos BFT existentes basados en líderes sin comprometer la seguridad o la liveness.

Resultados y Análisis

• Resistencia a la Censura: El análisis muestra que, si bien un líder malicioso puede censurar transacciones enviadas a un número pequeño de réplicas, censurar una fracción grande de transacciones se vuelve exponencialmente difícil a medida que el sistema escala. Específicamente, si $T$ clientes envían $x$ copias, la probabilidad de que un adversario censure una fracción $\alpha$ de las transacciones disminuye exponencialmente con $T$.
• Escalabilidad: Al separar el consenso de la ejecución de la carga útil completa, BigDipper permite que la capa de consenso escale linealmente con el ancho de banda agregado de las réplicas. La capacidad del sistema no se ve limitada por la necesidad de que cada validador procese la carga útil completa.
• Rendimiento: El protocolo Card-7 se ajusta al esquema de mensajes existente de HotStuff-2 (Propose, Vote, Prepare, Vote2) sin añadir nuevas fases, aprovechando los mensajes de DA-CR (Collection, Dispersal, Approval, Agreement) sobre los mensajes BFT estándar.

Significancia

El documento afirma que BigDipper proporciona un marco modular para la resistencia a la censura a corto plazo que evita el impuesto de "talla única" de los protocolos existentes. Al seguir el argumento de extremo a extremo, permite que las aplicaciones elijan sus propias estrategias de sumisión (por ejemplo, a cuántas réplicas contactar, si usar codificación de borrado) basándose en sus necesidades económicas específicas de latencia y garantías de inclusión.

La significancia radica en desplazar la carga de la resistencia a la censura de un costo fijo del protocolo a un parámetro ajustable por el cliente, asegurando al mismo tiempo que la capa de consenso permanezca eficiente y fragmentada. Demuestra que el modelo BFT basado en líderes puede hacerse resistente a la censura sin sacrificar los beneficios de baja latencia del modelo basado en líderes, siempre que la disponibilidad de datos se certifique mediante un mecanismo basado en compromisos y fragmentación en lugar de la replicación completa.