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.

​

Ü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
• 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