Resistencia a la Censura Versus Throughput en BFT Multi-Proposer

1. Enmarcado Institucional

BFT multi-proposer suele presentarse como un mecanismo para reducir el poder de censura de un líder único. Esa lectura es correcta, pero incompleta. La cuestión operativa no es solo si más proponentes elevan la probabilidad de inclusión. La cuestión crítica es cuánto tráfico duplicado, desperdicio de espacio de bloque, presión sobre relays y carga de verificación puede absorber el protocolo antes de que la resistencia a la censura degrade el camino de ejecución que debe permanecer vivo.

El artículo es relevante para ingeniería institucional de protocolos blockchain porque trata resistencia a la censura y throughput como propiedades acopladas. En una red de validadores en producción, ese acoplamiento se convierte en problema de implementación y operación: fanout de clientes, asignación de proponentes, política de mempool, supresión de duplicados y verificación de inclusión determinan si la cadena preserva Deterministic state transition testing, Consensus edge-case analysis y Validator operations hardening bajo presión adversarial de ordenamiento.

Mapeo institucional:

selected_domain: Blockchain Protocol Engineering
selected_capability_lines: Consensus edge-case analysis; Validator operations hardening; Deterministic state transition testing
why this paper supports enterprise engineering decisions: el artículo expone el costo protocolar de garantías anti-censura más fuertes y obliga a operadores a definir presupuestos medibles de inclusión, duplicación y throughput en lugar de depender de afirmaciones genéricas de descentralización.

Nota de Trazabilidad

Artículo: Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols. Autores: Fatima Elsheimy, Ioannis Kaklamanis, Sarisht Wadhwa, Charalampos Papamanthou, Fan Zhang. Fuente: IACR Cryptology ePrint 2026/126; listado en páginas de autores como ACM CCS 2026. Enlace: https://eprint.iacr.org/2026/126.

Línea Base de Reclamaciones de la Fuente

Reclamaciones limitadas a la fuente: el artículo estudia protocolos BFT multi-proposer; analiza el tradeoff entre resistencia a la censura y throughput; considera comportamiento adversarial en la participación de proponentes o validadores; se centra en la tensión creada cuando una diseminación más fuerte o una asignación de proponentes mejora la protección de inclusión mientras incrementa datos duplicados o presión sobre espacio de bloque; y presenta enfoques de asignación protocolar destinados a permitir que los diseñadores elijan distintos puntos en esa curva de tradeoff. No se asume aquí ningún benchmark empírico de producción, incidente de despliegue o caso empresarial.

2. Deconstrucción Técnica

La lección central es que resistencia a la censura no es una propiedad booleana de consenso. Es una propiedad de servicio con costo. Una transacción puede ser resistente a la censura dentro de una ventana solo si suficientes caminos honestos independientes pueden llevarla al log ordenado antes de que proponentes adversarios la excluyan. Esos caminos consumen ancho de banda, ciclos de verificación, capacidad de mempool y bytes de propuesta. Los diseños multi-proposer trasladan el problema desde la discrecionalidad de un líder único hacia asignación de recursos entre réplicas.

El primer invariante es inclusión bajo control adversarial acotado de proponentes:

\mathsf{Incl}(tx,\Delta)=1 \Leftarrow h(tx,\Delta) \ge q_{\mathrm{incl}} \land d(tx,\Delta) \le d_{\max} \tag{1}

En (1), $h(tx,\Delta)$ es el número de caminos honestos de proponente o relay que reciben $tx$ dentro de la ventana $\Delta$ , $q_{\mathrm{incl}}$ es el umbral mínimo de caminos independientes y $d(tx,\Delta)$ es el volumen duplicado. La decisión operativa es explícita: elevar $q_{\mathrm{incl}}$ aumenta la garantía de inclusión, pero permitir $d(tx,\Delta)>d_{\max}$ amenaza throughput y estabilidad de propagación.

El segundo invariante es seguridad determinística de estado bajo contribución concurrente de propuestas:

\forall r_i,r_j:\ \mathsf{ValidTranscript}(r_i)=1 \land \mathsf{ValidTranscript}(r_j)=1 \Rightarrow S_i^{k}=S_j^{k} \tag{2}

La ecuación (2) es la frontera de Deterministic state transition testing. Si supresión de duplicados, asignación de proponentes o reconciliación de listas de inclusión quedan como política local en vez de especificación, réplicas correctas pueden aceptar transcritos localmente válidos que divergen en el orden de ejecución.

3. Supuestos Ocultos

El primer supuesto oculto es que la duplicación de transacciones es benigna. No lo es. El tráfico duplicado consume capacidad escasa de propuesta y puede convertirse en una palanca adversarial. Un participante racional o bizantino puede amplificar transacciones de bajo valor, aumentar presión sobre relays y empujar transacciones críticas hacia un camino congestionado.

El segundo supuesto es que la diversidad honesta de proponentes estará disponible exactamente cuando sea necesaria. En una red eventualmente síncrona, una transacción puede alcanzar muchos nodos y aun así no alcanzar el subconjunto relevante para la siguiente ventana de decisión. Concentración geográfica, proveedores de infraestructura correlacionados, valores por defecto de relays y topología de peering reducen la diversidad efectiva.

El tercer supuesto es que resistencia a la censura puede evaluarse sin incentivos económicos. En proof-of-stake, el comportamiento de proponentes está condicionado por comisiones, MEV, exposición a slashing, relaciones con relays y restricciones jurisdiccionales.

Un modelo operativo de exposición es:

E_{\mathrm{cens}}(tx)=\Pr[A_{\mathrm{prop}}] \times \Pr[\neg H_{\mathrm{path}}(tx)] \times V(tx) \tag{3}

Aquí $A_{\mathrm{prop}}$ representa control adversarial o censor durante la ventana relevante, $H_{\mathrm{path}}(tx)$ es la existencia de al menos un camino honesto efectivo, y $V(tx)$ es valor o sensibilidad temporal. La ecuación (3) conecta configuración protocolar con clasificación de riesgo.

4. Stress Test Adversarial

El adversario debe modelarse como algo más que un líder fallido. En BFT multi-proposer, puede manipular la relación entre costo de diseminación y probabilidad de inclusión.

Clase uno: coalición de proponentes selectivos que omite transacciones específicas mientras acepta suficiente tráfico no relacionado para preservar apariencia de liveness.

Clase dos: amplificador de duplicación que envía transacciones solapadas a múltiples proponentes para consumir espacio de bloque y ciclos de deduplicación.

Clase tres: adversario de topología que explota concentración de relays o particiones para que el fanout parezca amplio mientras el alcance honesto efectivo permanece pequeño.

Clase cuatro: adversario racional de ordenamiento que censura o retrasa transacciones cuando el beneficio privado de ordenamiento excede la penalización protocolar.

La condición de stress debe ser:

\rho=\frac{B_{\mathrm{dup}} + B_{\mathrm{adv}}}{B_{\mathrm{slot}}},\quad \mathsf{HaltRisk}=1\ \text{if}\ \rho>\rho_{\max} \tag{4}

La ecuación (4) da un umbral de release. $B_{\mathrm{dup}}$ es payload honesto duplicado, $B_{\mathrm{adv}}$ es payload adversarial y $B_{\mathrm{slot}}$ es la capacidad del slot. Si la inclusión mejora solo mientras $\rho$ es pequeño, el comportamiento bajo sobrecarga no está especificado.

5. Operacionalización

Una implementación de producción necesita controles explícitos de admisión, asignación y observabilidad. El protocolo no debe dejar garantías de inclusión al comportamiento informal de wallets o RPC.

El cliente validador debe exponer métricas de razón de duplicados por slot, alcance efectivo de proponentes, latencia de inclusión por clase de transacción, tasa de omisión por proponente, concentración de relays y utilización de bloque después de deduplicación. Esas métricas deben etiquetarse por clase, porque los promedios esconden censura dirigida.

type TxClass int

const (
    Ordinary TxClass = iota
    SettlementCritical
    BridgeCritical
    LiquidationCritical
)

func RequiredFanout(class TxClass, censorBudget float64, honestReach float64) int {
    for fanout := 1; fanout <= 64; fanout++ {
        miss := pow(1.0-honestReach, fanout)
        if miss <= censorBudget {
            return fanout
        }
    }
    return 64
}

func AdmitProposal(slot Slot, policy Policy) error {
    if slot.DuplicateBytes/slot.CapacityBytes > policy.MaxDuplicateRatio {
        return ErrDuplicateBudgetExceeded
    }
    if !VerifyDeterministicDedup(slot.Transcript) {
        return ErrNonDeterministicTranscript
    }
    return nil
}

La decisión de fanout puede representarse como:

f^\star=\min f\ \text{such that}\ (1-p_h)^f \le \epsilon_{\mathrm{cens}} \tag{5}

La ecuación (5) convierte resistencia a la censura en un control explícito. $p_h$ es el alcance honesto efectivo por camino, $f^\star$ es el fanout requerido y $\epsilon_{\mathrm{cens}}$ es la probabilidad de fallo tolerada.

6. Impacto Empresarial

El impacto empresarial es gobernanza de garantías de ordenamiento. Sistemas que liquidan obligaciones financieras, puentean activos, ejecutan subastas o activan liquidaciones no pueden tratar resistencia a la censura como eslogan de capa base. Necesitan un servicio de inclusión medible con presupuestos de falla.

Para equipos de protocolo, esto cambia la especificación. Deduplicación, asignación y reglas de contribución de proponentes deben ser visibles al consenso y testeables. Para operaciones de validadores, afecta ubicación de infraestructura, diversidad de relays, observabilidad de mempool y respuesta a incidentes.

El SLO relevante no es throughput bruto. Es throughput después de pagar por la garantía de inclusión seleccionada:

T_{\mathrm{usable}}=T_{\mathrm{raw}} \times (1-\delta_{\mathrm{dup}}) \times (1-\delta_{\mathrm{verify}}) \tag{6}

La ecuación (6) evita un error común de reporte. Si mayor resistencia a la censura incrementa $\delta_{\mathrm{dup}}$ y $\delta_{\mathrm{verify}}$ , el throughput bruto anunciado no es el throughput disponible para aplicaciones.

7. Qué Haría STIGNING de Forma Diferente

Especificar manejo de duplicados como validez de consenso, incluyendo identidad canónica de transacción, reglas determinísticas y compromisos de transcrito.
Exigir política de fanout por clase de transacción, con presupuestos explícitos para settlement, bridge, liquidación, gobernanza y transferencias ordinarias.
Agregar pruebas adversariales que combinen omisión selectiva, amplificación de duplicados, particiones parciales y concentración de relays.
Publicar métricas del cliente validador para alcance honesto efectivo, no solo conteo de peers o tamaño agregado de mempool.
Tratar la asignación de proponentes como parámetro de seguridad y probarla contra ventanas de censura dirigida.
Imponer razón máxima de payload duplicado en la admisión de propuestas.
Construir pruebas determinísticas de transición de estado sobre conjuntos duplicados malformados y contribuciones conflictivas.

El invariante de admisión debe ser:

\mathsf{Admit}(P)=1 \Rightarrow \mathsf{DetDedup}(P)=1 \land \rho(P)\le\rho_{\max} \land \mathsf{AssignValid}(P)=1 \tag{7}

La ecuación (7) es implementable en el cliente validador. Si una propuesta no prueba deduplicación determinística y asignación válida dentro del presupuesto de duplicados, no debe admitirse.

8. Perspectiva Estratégica

BFT multi-proposer es estratégicamente importante porque reduce dependencia de un líder privilegiado, pero no elimina poder de ordenamiento. Redistribuye ese poder hacia reglas de asignación, economía de diseminación y gestión de duplicados. Esa redistribución debe especificarse, medirse y probarse.

La dirección de largo plazo debe ser por capas. El protocolo base proporciona mecánica determinística de inclusión y contribución responsable de proponentes. La capa transaccional expone fanout ajustable y presupuestos de riesgo por clase. La capa operacional mide continuamente si el alcance honesto efectivo coincide con las premisas de diseño.

El criterio estratégico es:

\Pr[\mathsf{Include}(tx,\Delta)\mid \mathsf{Class}(tx)=c] \ge 1-\epsilon_c\ \land\ T_{\mathrm{usable}}\ge T_{\min} \tag{8}

La ecuación (8) captura el tradeoff central: el protocolo solo es aceptable si cumple la probabilidad de inclusión exigida por clase y mantiene throughput utilizable por encima del mínimo operacional.

Referencias

Fatima Elsheimy, Ioannis Kaklamanis, Sarisht Wadhwa, Charalampos Papamanthou, Fan Zhang. Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols. IACR Cryptology ePrint 2026/126. https://eprint.iacr.org/2026/126
Fan Zhang publication list. Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols, ACM CCS 2026 listing. https://fanzhang.me/publications/
Sarisht Wadhwa publication list. Censorship Resistance vs Throughput in Multi-Proposer BFT Protocols, Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, 2026. https://sarisht.github.io/

Conclusión

El artículo es valioso porque formaliza una tensión inevitable en blockchains de producción: una resistencia más fuerte a la censura en ventanas cortas consume recursos que también determinan throughput y liveness. La respuesta correcta es especificar presupuestos de inclusión, límites de duplicación, reglas determinísticas de propuesta y telemetría de validadores para hacer el tradeoff explícito y exigible bajo condiciones adversariales.

STIGNING Academic Deconstruction Series Engineering Under Adversarial Conditions