Consenso

Plasma está asegurada por PlasmaBFT, una implementación de alto rendimiento de Fast HotStuff escrita en Rust. Combina la seguridad del consenso Byzantine Fault Tolerant (BFT) con finalidad de baja latencia, habilitando el alto throughput y las garantías deterministas requeridas para aplicaciones a escala de stablecoins. El consenso es modular y está diseñado para una integración estrecha con la capa de ejecución de Plasma basada en Reth. La finalidad de los bloques se logra en segundos con un overhead de comunicación mínimo, y la selección de validadores se impulsa por un sistema simplificado de Proof of Stake optimizado para el rendimiento y comportamiento predecible.

​

Resumen

​

Producción de bloques y selección de validadores

Plasma usa un mecanismo de Proof of Stake para la selección de validadores. A diferencia de otras redes PoS, el modelo de staking de Plasma está diseñado para la simplicidad y predictibilidad:

• Los validadores que se comportan mal reciben slashing de recompensas, no de colateral
• Los validadores no son penalizados por fallos de vivacidad
• Estamos explorando staking opcional sin bloqueo para permitir el retiro de stake sin demora

Los validadores ganan recompensas al participar en el consenso y firmar bloques. El mal comportamiento se maneja vía denegación de recompensas en lugar de destrucción de capital, una elección hecha para alinearse con las expectativas institucionales y reducir el riesgo de UX.

​

Despliegue del consenso

El consenso de Plasma se lanzará en tres fases:

1. Lanzamiento con validadores de confianza Un pequeño grupo de validadores conocidos asegurarán la red en el lanzamiento de la mainnet, permitiendo estabilidad e iteración del protocolo.
2. Expansión de validadores El conjunto de validadores escalará para probar el rendimiento horizontal bajo tamaños de comité más grandes y validar el throughput bajo carga.
3. Participación sin permisos Plasma abrirá el acceso a validadores al público, habilitando la descentralización completa mientras preserva las garantías de seguridad a nivel de protocolo.

​

Formación del comité

La formación del comité está diseñada para escalar el consenso BFT sin degradar el rendimiento. En PlasmaBFT, un subconjunto de validadores es seleccionado para participar en cada ronda. Esto reduce el overhead de comunicación y evita la complejidad cuadrática de la mensajería all-to-all. Los validadores son seleccionados mediante un proceso aleatorio criptográficamente seguro y ponderado por stake. La selección es determinista, auditable y resistente a ataques Sybil. Cada validador en el comité es conocido de antemano para la ronda, permitiendo verificación eficiente de firmas y detección de equívocos sin comunicación adicional.

​

Slashing de recompensas, no de stake

Plasma evita intencionalmente el slashing punitivo de stake. En su lugar, dependemos del slashing de recompensas, donde los validadores que se comportan mal o no participan pierden las recompensas de bloque sin perder su capital. Esta decisión refleja tres objetivos:

1. Reducir el riesgo del usuario: La pérdida inesperada de capital no es aceptable en contextos institucionales.
2. Alinearse con sistemas del mundo real: El rendimiento deficiente lleva a retornos más bajos, no a la pérdida total de fondos.
3. Fomentar el comportamiento racional: Si el mal comportamiento reduce las ganancias esperadas, los validadores racionales siguen el protocolo.

El slashing de recompensas permite tolerancia a fallos y resiliencia sin desalentar la participación de los validadores.

​

Resumen de HotStuff

HotStuff es un protocolo de consenso BFT moderno que mejora los modelos anteriores como Tendermint al reducir el overhead de comunicación y habilitar la responsividad. En su núcleo:

• HotStuff opera en una estructura de rondas basada en líderes
• Los validadores votan sobre los bloques propuestos
• Una vez que se recolecta un quórum de votos, se forma un Certificado de Quórum (QC)
• Los QCs se encadenan para demostrar finalidad y mantener la seguridad

HotStuff mejora la eficiencia con:

• Complejidad de comunicación lineal
• Responsividad sin demoras fijas
• Cambios de líder seguros y rápidos

Estas propiedades lo hacen ideal para cadenas de alta frecuencia como Plasma.

​

PlasmaBFT

PlasmaBFT es una implementación pipelined basada en Rust de Fast HotStuff. Mantiene las garantías de seguridad del BFT clásico pero se optimiza para rutas de commit más rápidas y menor latencia.

​

Propiedades clave de diseño

• Commit de dos cadenas en ruta rápida En el caso común, los bloques pueden finalizarse después de dos QCs consecutivos. Una tercera fase se evita a menos que sea necesario, reduciendo la latencia de la ronda.
• Tamaño del quórum y seguridad PlasmaBFT requiere n ≥_3f + 1, donde f es el número de validadores bizantinos. El tamaño del quórum es q = 2f + 1. Esto asegura que no se puedan finalizar dos bloques conflictivos a menos que más de un tercio de los validadores sean maliciosos.
• Agregación de firmas y QCs Los QCs consisten en firmas agregadas de validadores y codifican la prueba de que los validadores están de acuerdo en un bloque. Cuando los QCs se construyen unos sobre otros, pueden establecer finalidad. $QC(b_v) ← QC(b_v+1) ← QC(b_v+2) ← ...$
• Alto throughput PlasmaBFT puede finalizar muchos miles de transacciones por segundo en benchmarks internos, debido al pipelining y la complejidad mínima de mensajes.

​

Pipelining

PlasmaBFT soporta pipelining, permitiendo que la propuesta de un nuevo bloque comience mientras el bloque previo aún se está commiteando. Esto aumenta el throughput al solapar los pasos de propuesta de bloques y finalidad.

​

Cambios de vista y AggQCs

Cuando un líder falla o ocurre un cambio de vista, PlasmaBFT usa QCs agregados (AggQCs) para mantener la vivacidad y prevenir equívocos.

• Los validadores reenvían su QC más reciente al nuevo líder
• El nuevo líder los agrega en un AggQC
• Esto establece el bloque más alto conocido y permite el progreso seguro

Esto difiere de los esquemas de firma de umbral o certificados de timeout (por ejemplo, Jolteon, Ditto) pero alcanza los mismos objetivos de seguridad con menos validaciones de firmas.

​

Resumen

PlasmaBFT es la columna vertebral de la cadena Plasma. Combina la fortaleza teórica del consenso BFT con la ingeniería de rendimiento pragmática, entregando:

• Finalidad en segundos
• Alto throughput bajo carga
• Resiliencia a fallos sin sobre-penalizar a participantes honestos
• Arquitectura construida para escala sin comprometer la seguridad

Este modelo de consenso le da a Plasma la base que necesita para soportar aplicaciones basadas en stablecoins a volumen global, mientras se mantiene alineado con las expectativas tanto de desarrolladores como de instituciones.

​

Referencias

• J. Kwon, «Tendermint: Consensus without mining,» Draft v. 0.6, Fall, vol. 1, no. 11, pp. 1–11, 2014. Disponible: https://tendermint.com/static/docs/tendermint.pdf
• D. Malkhi and K. Nayak, «HotStuff-2: Optimal Two-Phase Responsive BFT,» 2023, 2023/397. [Online]. Disponible: https://eprint.iacr.org/2023/397
• M. M. Jalalzai, J. Niu, C. Feng, and F. Gai, «Fast-HotStuff: A Fast and Robust BFT Protocol for Blockchains,» IEEE Trans. Dependable and Secure Comput., vol. 21, no. 4, pp. 2478–2493, Jul. 2024, doi: 10.1109/TDSC.2023.3308848. Disponible en línea.
• R. Gelashvili, L. Kokoris-Kogias, A. Sonnino, and Z. Xiang, «Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback,» Financial Cryptography and Data Security, p. 32, 2022. Disponible: https://arxiv.org/pdf/2106.10362
• M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, «HotStuff: BFT Consensus with Linearity and Responsiveness,» in Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing, PODC ‘19, New York, NY, USA, Jul. 2019, pp. 347–356. Disponible: https://dl.acm.org/doi/pdf/10.1145/3293611.3331591
• S. Nakamoto, «Bitcoin: A Peer-to-Peer Electronic Cash System,» 2008. Disponible: https://bitcoin.org/bitcoin.pdf
• M. Castro and B. Liskov, «Practical Byzantine Fault Tolerance,» in Proceedings of the Third Symposium on Operating Systems Design and Implementation, OSDI ‘99, Berkeley, CA, USA: USENIX Association, 1999, pp. 173–186. [Online]. Disponible: https://www.usenix.org/legacy/publications/library/proceedings/osdi99/full_papers/castro/castro.ps