Consensus

Plasma est sécurisée par PlasmaBFT, une implémentation haute performance de Fast HotStuff écrite en Rust. Elle combine la sûreté du consensus Byzantine Fault Tolerant (BFT) avec une finalité à faible latence, permettant le débit élevé et les garanties déterministes nécessaires aux applications à l’échelle des stablecoins. Le consensus est modulaire et conçu pour une intégration étroite avec la couche d’exécution basée sur Reth de Plasma. La finalité des blocs est atteinte en quelques secondes avec une surcharge de communication minimale, et la sélection des validateurs est pilotée par un système Proof of Stake simplifié optimisé pour la performance et un comportement prévisible.

​

Vue d’ensemble

​

Production de blocs et sélection des validateurs

Plasma utilise un mécanisme Proof of Stake pour la sélection des validateurs. Contrairement à d’autres réseaux PoS, le modèle de staking de Plasma est conçu pour la simplicité et la prévisibilité :

• Les validateurs malveillants subissent un slashing des récompenses, pas du collatéral
• Les validateurs ne sont pas pénalisés pour les défaillances de vivacité
• Nous explorons un staking optionnel sans verrouillage permettant le retrait du stake sans délai

Les validateurs gagnent des récompenses en participant au consensus et en signant des blocs. Le comportement malveillant est traité par le refus de récompense plutôt que par la destruction de capital, un choix fait pour s’aligner sur les attentes institutionnelles et réduire le risque UX.

​

Déploiement du consensus

Le consensus de Plasma sera lancé en trois phases :

1. Lancement avec validateurs de confiance Un petit groupe de validateurs connus sécurisera le réseau au lancement du mainnet, permettant la stabilité et l’itération du protocole.
2. Expansion des validateurs L’ensemble des validateurs s’étendra pour tester la performance horizontale sous des tailles de comités plus importantes et valider le débit sous charge.
3. Participation sans permission Plasma ouvrira l’accès aux validateurs au public, permettant la pleine décentralisation tout en préservant les garanties de sûreté au niveau protocole.

​

Formation des comités

La formation des comités est conçue pour mettre à l’échelle le consensus BFT sans dégrader la performance. Dans PlasmaBFT, un sous-ensemble de validateurs est sélectionné pour participer à chaque tour. Cela réduit la surcharge de communication et évite la complexité quadratique de la messagerie tous-à-tous. Les validateurs sont sélectionnés via un processus aléatoire cryptographiquement sécurisé et pondéré par le stake. La sélection est déterministe, auditable et résistante aux attaques Sybil. Chaque validateur du comité est connu à l’avance pour le tour, permettant une vérification efficace des signatures et la détection d’équivocation sans communication supplémentaire.

​

Slashing des récompenses, pas du stake

Plasma évite intentionnellement le slashing punitif du stake. Au lieu de cela, nous nous appuyons sur le slashing des récompenses, où les validateurs qui se comportent mal ou ne participent pas perdent les récompenses de blocs sans perdre leur capital. Cette décision reflète trois objectifs :

1. Réduire le risque pour l’utilisateur : Une perte de capital inattendue n’est pas acceptable dans les contextes institutionnels.
2. S’aligner sur les systèmes du monde réel : Une mauvaise performance entraîne des retours moindres, pas une perte totale de fonds.
3. Encourager le comportement rationnel : Si le comportement malveillant réduit les gains attendus, les validateurs rationnels suivent le protocole.

Le slashing des récompenses permet la tolérance aux fautes et la résilience sans décourager la participation des validateurs.

​

Vue d’ensemble de HotStuff

HotStuff est un protocole de consensus BFT moderne qui améliore les modèles antérieurs comme Tendermint en réduisant la surcharge de communication et en permettant la réactivité. À sa base :

• HotStuff fonctionne dans une structure de tours basée sur un leader
• Les validateurs votent sur les blocs proposés
• Une fois qu’un quorum de votes est collecté, un Quorum Certificate (QC) est formé
• Les QCs sont chaînés pour prouver la finalité et maintenir la sûreté

HotStuff améliore l’efficacité avec :

• Complexité de communication linéaire
• Réactivité sans délais fixes
• Changements de leader sûrs et rapides

Ces propriétés en font l’idéal pour les chaînes haute fréquence comme Plasma.

​

PlasmaBFT

PlasmaBFT est une implémentation pipelinée, basée sur Rust, de Fast HotStuff. Elle maintient les garanties de sûreté du BFT classique mais optimise pour des chemins de commit plus rapides et une latence plus faible.

​

Propriétés clés de la conception

• Commit en deux chaînes par chemin rapide Dans le cas commun, les blocs peuvent être finalisés après deux QCs consécutifs. Une troisième phase est évitée sauf si nécessaire, réduisant la latence du tour.
• Taille du quorum et sûreté PlasmaBFT requiert n ≥_3f + 1 , où f est le nombre de validateurs byzantins. La taille du quorum est q = 2f + 1. Cela garantit qu’aucun deux blocs conflictuels ne peuvent tous deux être finalisés à moins que plus d’un tiers des validateurs ne soient malveillants.
• Agrégation des signatures et QCs Les QCs sont constitués de signatures agrégées de validateurs et encodent la preuve que les validateurs s’accordent sur un bloc. Lorsque les QCs s’enchaînent, ils peuvent établir la finalité. $QC(b_v) ← QC(b_v+1) ← QC(b_v+2) ← ...$
• Débit élevé PlasmaBFT peut finaliser plusieurs milliers de transactions par seconde dans des benchmarks internes, grâce au pipelining et à la complexité de messages minimale.

​

Pipelining

PlasmaBFT prend en charge le pipelining, permettant à la proposition d’un nouveau bloc de commencer pendant que le bloc précédent est encore en cours de commit. Cela augmente le débit en superposant les étapes de proposition et de finalisation des blocs.

​

Changements de vue et AggQCs

Lorsqu’un leader échoue ou qu’un changement de vue se produit, PlasmaBFT utilise des QCs agrégés (AggQCs) pour maintenir la vivacité et empêcher l’équivocation.

• Les validateurs transmettent leur QC le plus récent au nouveau leader
• Le nouveau leader les agrège en un AggQC
• Cela établit le bloc le plus élevé connu et permet une progression sûre

Cela diffère des schémas de signatures à seuil ou des certificats de timeout (par exemple Jolteon, Ditto) mais atteint les mêmes objectifs de sûreté avec moins de validations de signatures.

​

Récapitulatif

PlasmaBFT est l’épine dorsale de la chaîne Plasma. Il combine la force théorique du consensus BFT avec une ingénierie de performance pragmatique, offrant :

• Finalité en quelques secondes
• Débit élevé sous charge
• Résilience aux fautes sans sur-pénaliser les participants honnêtes
• Architecture conçue pour l’échelle sans compromettre la sécurité

Ce modèle de consensus donne à Plasma la fondation dont elle a besoin pour soutenir des applications basées sur les stablecoins à volume mondial, tout en restant aligné sur les attentes des développeurs et des institutions.

​

Références

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