Consenso

A Plasma é protegida pelo PlasmaBFT, uma implementação de alto desempenho do Fast HotStuff escrita em Rust. Ela combina a segurança do consenso Byzantine Fault Tolerant (BFT) com finalidade de baixa latência, permitindo o alto throughput e as garantias determinísticas exigidas para aplicações em escala de stablecoin. O consenso é modular e projetado para integração estreita com a camada de execução baseada em Reth da Plasma. A finalidade dos blocos é alcançada em segundos com sobrecarga mínima de comunicação, e a seleção de validadores é impulsionada por um sistema simplificado de Proof of Stake otimizado para desempenho e comportamento previsível.

​

Visão Geral

​

Produção de Blocos e Seleção de Validadores

A Plasma utiliza um mecanismo Proof of Stake para a seleção de validadores. Ao contrário de outras redes PoS, o modelo de staking da Plasma é projetado para simplicidade e previsibilidade:

• Validadores que se comportam mal têm recompensas slash, não colateral
• Os validadores não são penalizados por falhas de liveness
• Estamos explorando staking opcional sem bloqueio para permitir saque de stake sem atraso

Os validadores ganham recompensas participando do consenso e assinando blocos. Comportamentos inadequados são tratados via negação de recompensas em vez de destruição de capital, uma escolha feita para se alinhar com as expectativas institucionais e reduzir o risco de UX.

​

Lançamento do Consenso

O consenso da Plasma será lançado em três fases:

1. Lançamento com Validadores Confiáveis Um pequeno grupo de validadores conhecidos protegerá a rede no lançamento da mainnet, permitindo estabilidade e iteração do protocolo.
2. Expansão de Validadores O conjunto de validadores escalará para testar o desempenho horizontal sob tamanhos maiores de comitê e validar o throughput sob carga.
3. Participação Sem Permissão A Plasma abrirá o acesso de validador ao público, permitindo descentralização total enquanto preserva as garantias de segurança em nível de protocolo.

​

Formação de Comitê

A formação de comitê é projetada para escalar o consenso BFT sem degradar o desempenho. No PlasmaBFT, um subconjunto de validadores é selecionado para participar em cada rodada. Isso reduz a sobrecarga de comunicação e evita a complexidade quadrática de mensagens all-to-all. Os validadores são selecionados por meio de um processo aleatório criptograficamente seguro e ponderado por stake. A seleção é determinística, auditável e resistente a ataques Sybil. Cada validador no comitê é conhecido antecipadamente para a rodada, permitindo verificação eficiente de assinaturas e detecção de equívocos sem comunicação adicional.

​

Slashing de Recompensas, Não Slashing de Stake

A Plasma evita intencionalmente o slashing punitivo de stake. Em vez disso, dependemos do slashing de recompensas, onde validadores que se comportam mal ou deixam de participar perdem recompensas de bloco sem perder seu capital. Esta decisão reflete três objetivos:

1. Reduzir o risco do usuário: Perda inesperada de capital não é aceitável em contextos institucionais.
2. Alinhar-se com sistemas do mundo real: Mau desempenho leva a retornos menores, não a perda total de fundos.
3. Incentivar comportamento racional: Se o comportamento inadequado reduz os ganhos esperados, validadores racionais seguem o protocolo.

O slashing de recompensas permite tolerância a falhas e resiliência sem desencorajar a participação de validadores.

​

Visão Geral do HotStuff

HotStuff é um protocolo de consenso BFT moderno que aprimora modelos anteriores como o Tendermint reduzindo a sobrecarga de comunicação e permitindo responsividade. Em seu núcleo:

• O HotStuff opera em uma estrutura de rodada baseada em líder
• Os validadores votam em blocos propostos
• Uma vez que um quórum de votos é coletado, um Quorum Certificate (QC) é formado
• Os QCs são encadeados para provar finalidade e manter segurança

O HotStuff melhora a eficiência com:

• Complexidade linear de comunicação
• Responsividade sem atrasos fixos
• Mudanças de líder seguras e rápidas

Essas propriedades o tornam ideal para chains de alta frequência como a Plasma.

​

PlasmaBFT

PlasmaBFT é uma implementação pipelined em Rust do Fast HotStuff. Mantém as garantias de segurança do BFT clássico, mas otimiza para caminhos de commit mais rápidos e latência mais baixa.

​

Principais Propriedades de Design

• Commit em duas chains via caminho rápido No caso comum, os blocos podem ser finalizados após dois QCs consecutivos. Uma terceira fase é evitada a menos que necessária, reduzindo a latência de rodada.
• Tamanho de quórum e segurança PlasmaBFT requer n ≥_3f + 1 , onde f é o número de validadores bizantinos. O tamanho do quórum é q = 2f + 1. Isso garante que dois blocos conflitantes não possam ser finalizados a menos que mais de um terço dos validadores sejam maliciosos.
• Agregação de assinaturas e QCs Os QCs consistem em assinaturas agregadas de validadores e codificam a prova de que os validadores concordam com um bloco. Quando os QCs se constroem uns sobre os outros, eles podem estabelecer finalidade. $QC(b_v) ← QC(b_v+1) ← QC(b_v+2) ← ...$
• Alto throughput O PlasmaBFT pode finalizar muitos milhares de transações por segundo em benchmarks internos, devido ao pipelining e à complexidade mínima de mensagens.

​

Pipelining

PlasmaBFT suporta pipelining, permitindo que a proposta de um novo bloco comece enquanto o bloco anterior ainda está sendo confirmado. Isso aumenta o throughput sobrepondo as etapas de proposta de bloco e finalidade.

​

Mudanças de View e AggQCs

Quando um líder falha ou ocorre uma mudança de view, o PlasmaBFT usa QCs agregados (AggQCs) para manter liveness e prevenir equívocos.

• Os validadores encaminham seu QC mais recente para o novo líder
• O novo líder os agrega em um AggQC
• Isso estabelece o bloco mais alto conhecido e permite progresso seguro

Isso difere de esquemas de assinaturas de limiar ou certificados de timeout (por exemplo, Jolteon, Ditto), mas atinge os mesmos objetivos de segurança com menos validações de assinatura.

​

Resumo

PlasmaBFT é a espinha dorsal da chain Plasma. Combina a força teórica do consenso BFT com engenharia pragmática de desempenho, entregando:

• Finalidade em segundos
• Alto throughput sob carga
• Resiliência a falhas sem penalizar excessivamente participantes honestos
• Arquitetura construída para escalar sem comprometer a segurança

Este modelo de consenso dá à Plasma a base necessária para suportar aplicações baseadas em stablecoins em volume global, mantendo-se alinhada com as expectativas tanto de desenvolvedores quanto de instituições.

​

Referências

• J. Kwon, “Tendermint: Consensus without mining,” Draft v. 0.6, Fall, vol. 1, no. 11, pp. 1–11, 2014. Disponível em: https://tendermint.com/static/docs/tendermint.pdf
• D. Malkhi and K. Nayak, “HotStuff-2: Optimal Two-Phase Responsive BFT,” 2023, 2023/397. [Online]. Disponível em: 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. Disponível online.
• 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. Disponível em: 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. Disponível em: https://dl.acm.org/doi/pdf/10.1145/3293611.3331591
• S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008. Disponível em: 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]. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/osdi99/full_papers/castro/castro.ps