> ## Documentation Index > Fetch the complete documentation index at: https://docs.plasma.org/llms.txt > Use this file to discover all available pages before exploring further. # Konsens Plasma wird von **PlasmaBFT** gesichert, einer leistungsstarken Implementierung von Fast HotStuff, geschrieben in Rust. Es kombiniert die Sicherheit von Byzantine Fault Tolerant (BFT)-Konsens mit niedriger Latenz bis zur Finalität und ermöglicht damit den hohen Durchsatz und deterministische Garantien, die für Anwendungen im Stablecoin-Maßstab erforderlich sind. Der Konsens ist modular und auf enge Integration mit Plasmas Reth-basierter Ausführungsschicht ausgelegt. Block-Finalität wird in Sekunden bei minimalem Kommunikations-Overhead erreicht, und die Validator-Auswahl wird durch ein vereinfachtes Proof-of-Stake-System gesteuert, das auf Performance und vorhersehbares Verhalten optimiert ist. Der Proof-of-Stake- und Komitee-Bildungs-Mechanismus befinden sich in aktiver Entwicklung. Diese Seite umreißt die beabsichtigte Architektur, kann sich jedoch ändern. ## Überblick ### Blockproduktion und Validator-Auswahl Plasma nutzt einen Proof-of-Stake-Mechanismus für die Validator-Auswahl. Im Gegensatz zu anderen PoS-Netzwerken ist Plasmas Staking-Modell auf Einfachheit und Vorhersehbarkeit ausgelegt: * Fehlverhaltende Validatoren verlieren Belohnungen, nicht Sicherheiten * Validatoren werden nicht für Liveness-Fehler bestraft * Wir prüfen optionales No-Lock-Staking, um Stake-Abhebungen ohne Verzögerung zu ermöglichen Validatoren verdienen Belohnungen durch Teilnahme am Konsens und das Signieren von Blöcken. Fehlverhalten wird durch Belohnungsentzug behandelt statt durch Kapitalvernichtung — eine Entscheidung, die auf institutionelle Erwartungen ausgerichtet ist und UX-Risiken reduziert. ### Konsens-Rollout Plasmas Konsens wird in drei Phasen starten: 1. **Trusted-Validator-Launch** Eine kleine Gruppe bekannter Validatoren wird das Netzwerk beim Mainnet-Start sichern, was Stabilität und Protokoll-Iteration ermöglicht. 2. **Validator-Erweiterung** Die Validator-Menge wird skaliert, um horizontale Performance bei größeren Komitee-Größen zu testen und den Durchsatz unter Last zu validieren. 3. **Erlaubnisfreie Teilnahme** Plasma öffnet den Validator-Zugang für die Öffentlichkeit und ermöglicht volle Dezentralisierung bei Erhalt der Sicherheitsgarantien auf Protokollebene. ## Komitee-Bildung Die Komitee-Bildung ist darauf ausgelegt, BFT-Konsens zu skalieren, ohne die Performance zu beeinträchtigen. In PlasmaBFT wird eine Teilmenge von Validatoren ausgewählt, um an jeder Runde teilzunehmen. Dies reduziert den Kommunikations-Overhead und vermeidet die quadratische Komplexität von All-to-All-Messaging. Validatoren werden über einen kryptografisch sicheren, stake-gewichteten Zufallsprozess ausgewählt. Die Auswahl ist deterministisch, prüfbar und resistent gegen Sybil-Angriffe. Jeder Validator im Komitee ist im Voraus für die Runde bekannt, was effiziente Signaturverifikation und Equivocation-Erkennung ohne zusätzliche Kommunikation ermöglicht. ## Reward-Slashing, nicht Stake-Slashing Plasma vermeidet absichtlich strafendes Stake-Slashing. Stattdessen setzen wir auf **Reward-Slashing**, bei dem Validatoren, die sich falsch verhalten oder nicht teilnehmen, Block-Belohnungen verlieren, ohne ihr Kapital zu verlieren. Diese Entscheidung spiegelt drei Ziele wider: 1. **Nutzerrisiko reduzieren**: Unerwarteter Kapitalverlust ist in institutionellen Kontexten nicht akzeptabel. 2. **Mit realen Systemen abgleichen**: Schlechte Performance führt zu geringeren Erträgen, nicht zu Totalverlust. 3. **Rationales Verhalten fördern**: Wenn Fehlverhalten den erwarteten Ertrag reduziert, halten sich rationale Validatoren an das Protokoll. Reward-Slashing ermöglicht Fehlertoleranz und Resilienz, ohne die Validator-Teilnahme zu entmutigen. ## HotStuff im Überblick **HotStuff** ist ein modernes BFT-Konsensprotokoll, das frühere Modelle wie Tendermint verbessert, indem es Kommunikations-Overhead reduziert und Responsiveness ermöglicht. Im Kern: * HotStuff arbeitet in einer leader-basierten Runden-Struktur * Validatoren stimmen über vorgeschlagene Blöcke ab * Sobald ein Quorum an Stimmen gesammelt ist, wird ein **Quorum Certificate (QC)** gebildet * QCs werden verkettet, um Finalität zu beweisen und Sicherheit zu wahren HotStuff verbessert die Effizienz mit: * **Linearer Kommunikationskomplexität** * **Responsiveness ohne feste Verzögerungen** * **Sicheren und schnellen Leader-Wechseln** Diese Eigenschaften machen es ideal für hochfrequente Chains wie Plasma. ## PlasmaBFT PlasmaBFT ist eine pipelinierte, Rust-basierte Implementierung von Fast HotStuff. Es bewahrt die Sicherheitsgarantien des klassischen BFT, optimiert jedoch auf schnellere Commit-Pfade und niedrigere Latenz. ### **Wichtige Designeigenschaften** * **Fast-Path-Two-Chain-Commit** Im Normalfall können Blöcke nach zwei aufeinanderfolgenden QCs finalisiert werden. Eine dritte Phase wird vermieden, sofern nicht nötig, was Rundenlatenz reduziert. * **Quorum-Größe und Sicherheit** PlasmaBFT erfordert `n ≥_3f + 1 `, wobei f die Anzahl der byzantinischen Validatoren ist. Die Quorum-Größe ist `q = 2f + 1`. Das stellt sicher, dass keine zwei widersprüchlichen Blöcke beide finalisiert werden können, es sei denn, mehr als ein Drittel der Validatoren sind bösartig. * **Signatur-Aggregation und QCs** QCs bestehen aus aggregierten Validator-Signaturen und kodieren den Beweis, dass Validatoren einem Block zustimmen. Wenn QCs aufeinander aufbauen, können sie Finalität herstellen. $QC(b_v) ← QC(b_v+1) ← QC(b_v+2) ← ...$ * **Hoher Durchsatz** PlasmaBFT kann in internen Benchmarks viele tausend Transaktionen pro Sekunde finalisieren, dank Pipelining und minimaler Nachrichtenkomplexität. ### Pipelining PlasmaBFT unterstützt Pipelining, sodass der Vorschlag eines neuen Blocks beginnen kann, während der vorherige Block noch committet wird. Das erhöht den Durchsatz durch Überlappung von Blockvorschlag und Finalitätsschritten. ### View-Changes und AggQCs Wenn ein Leader ausfällt oder ein View-Change auftritt, verwendet PlasmaBFT **Aggregated QCs (AggQCs)**, um Liveness zu wahren und Equivocation zu verhindern. * Validatoren leiten ihren aktuellsten QC an den neuen Leader weiter * Der neue Leader aggregiert diese zu einem AggQC * Dies etabliert den höchsten bekannten Block und ermöglicht sicheren Fortschritt Dies unterscheidet sich von Threshold-Signatur-Schemata oder Timeout-Zertifikaten (z. B. Jolteon, Ditto), erreicht aber dieselben Sicherheitsziele mit weniger Signaturverifikationen. ## Zusammenfassung PlasmaBFT ist das Rückgrat der Plasma-Chain. Es kombiniert die theoretische Stärke des BFT-Konsenses mit pragmatischer Performance-Engineering und liefert: * Finalität in Sekunden * Hohen Durchsatz unter Last * Resilienz gegen Fehler ohne Überbestrafung ehrlicher Teilnehmer * Architektur für Skalierung ohne Kompromisse bei der Sicherheit Dieses Konsens-Modell gibt Plasma die Grundlage, um stablecoin-basierte Anwendungen in globalem Volumen zu unterstützen, während es mit den Erwartungen sowohl von Entwicklern als auch Institutionen abgestimmt bleibt. ## **Referenzen** * 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](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](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](https://www.researchgate.net/profile/Mohammad_Mussadiq_Jalalzai/publication/344828409_Fast-HotStuff_A_Fast_and_Resilient_HotStuff_Protocol/links/61e724eac5e3103375a37c76/Fast-HotStuff-A-Fast-and-Resilient-HotStuff-Protocol.pdf). * 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](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](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](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](https://www.usenix.org/legacy/publications/library/proceedings/osdi99/full_papers/castro/castro.ps)