---
title: "Blockchain-Trilemma"
description: "Das Blockchain-Trilemma ist eine Heuristik zum Vergleich von Skalierbarkeit, Dezentralisierung und Sicherheit unter expliziten Arbeitslasten und Bedrohungsmodellen. Es ist kein Theorem oder eine Regel, dass Systeme buchstäblich nur zwei auswählen."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Blockchain-Trilemma
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Das Blockchain-Trilemma ist eine Design-Heuristik: Eine zunehmende Skalierbarkeit, Dezentralisierung oder Sicherheit unter einem festen Ressourcen- und Vertrauensmodell kann die anderen Dimensionen unter Druck setzen. Es handelt sich nicht um einen mathematischen Unmöglichkeitssatz, keine additive Bewertung oder eine Regel, dass jedes Netzwerk genau zwei Eigenschaften auswählen muss.
Jede Achse benötigt operative Definitionen. Die Skalierbarkeit umfasst nachhaltigen Durchsatz, Latenz, Gebühren und Daten- oder Statuswachstum unter angegebener Last. Die Dezentralisierung umfasst unabhängige Validierung, erlaubnislosen Ein- und Ausstieg sowie die Konzentration über Einsatz- oder Hash-Macht, Betreiber, Kunden, Cloud-Anbieter, Geografie und Governance hinweg. Sicherheit umfasst Sicherheit, Lebendigkeit, Endgültigkeit, Zensurresistenz, Datenverfügbarkeit und Wiederherstellung unter einem expliziten Gegnermodell.
Sharding, Rollups, Gültigkeitsnachweise, Light Clients und Datenverfügbarkeitsstichproben können die Machbarkeitsgrenze verbessern, indem sie ändern, wer Daten ausführt, herunterlädt, speichert, nachweist oder überprüft. Sie beseitigen keine Kompromisse: Sie verschieben Ressourcenkosten und führen schichtspezifische Annahmen über Sequenzer, Prüfer, Herausforderer, Brücken, Upgrade-Schlüssel und Datenverfügbarkeit ein.
## Wie es funktioniert
1. Fixieren Sie die Kette, das Netzwerk, die Protokollversion, die Schicht und den genauen Architekturanspruch. Identifizieren Sie Konsens-, Ausführungs-, Datenverfügbarkeits-, Abwicklungs- und Governance-Komponenten, anstatt nur einen Markennamen zu bewerten.
2. Definieren Sie Skalierbarkeit, Dezentralisierung und Sicherheit mit messbaren Proxys, einer Arbeitslast und einem Beobachtungsfenster. Addieren Sie TPS, Knotenanzahl und Angriffskosten nicht zu einem dimensionslosen Wert.
3. Stellen Sie fest, wer Vorschläge macht, baut, bestellt, validiert, Daten speichert, prüft, herausfordert, aktualisiert, pausiert und den Ausstieg ermöglicht. Notieren Sie Erlaubnis-, Sorgerechts- und Notfallkontrollgrenzen.
4. Messen Sie die Dezentralisierung über Stake- oder Hash-Power-Einheiten, unabhängige Validierungsknoten, Client-Software, Hosting, Geografie und Governance hinweg. Berücksichtigen Sie Hardware, Bandbreite, Speicher, Synchronisierungszeit und Kapitalbarrieren.
5. Messen Sie Sicherheit als Sicherheit, Lebendigkeit, Endgültigkeit, Zensurresistenz, Datenverfügbarkeit und -wiederherstellung unter festgelegten gegnerischen Schwellenwerten, Korrelationsannahmen und wirtschaftlichen Anreizen.
6. Messen Sie die Skalierbarkeit anhand von anhaltendem und Tail-Durchsatz, Inklusions- und Finalitätslatenz, Gebühren unter Last, Bytes, Zustandswachstum, Synchronisierungs- und Verifizierungskosten sowie Verhalten bei Überlastung oder Komponentenausfall.
7. Vergleichen Sie Architekturen mit demselben Arbeitslast- und Bedrohungsmodell, versionieren Sie die Beweise und betonen Sie Ausfälle. Geben Sie an, welche Kosten- oder Vertrauensannahmen sich zwischen den Schichten bewegt haben, anstatt zu behaupten, dass das Trilemma gelöst wurde.
## Beispiel
- Eine hypothetische, vollständig replizierte Kette mit `2 MiB / 12 seconds` hat `7,200 blocks/day` und einen Roheingang von `2 * 7,200 = 14,400 MiB/day = 14.0625 GiB/day`. Das Erhöhen der Nutzlast auf `8 MiB` ergibt `57,600 MiB/day = 56.25 GiB/day`, genau `4x` vor Protokoll-Overhead, Indizes, Status und Replikation. Die Kapazität steigt, aber diese Berechnung ist keine vollständige Knotenanforderung.
- Angenommen, Pfahlbetreiber kontrollieren `34%, 22%, 18%, 16%, 10%`. Unter einem angegebenen Schwellenwert für die Lebendigkeitsblockierung `>= 1/3` ist nur der erste Betreiber qualifiziert. Unter einem angegebenen Kontrollschwellenwert `>= 2/3` ist das kleinste Präfix die ersten drei: `34 + 22 + 18 = 74%`; Die ersten beiden betragen insgesamt nur `56%`. Echte Entitätsverknüpfungen und Protokollschwellenwerte müssen weiterhin überprüft werden.
- Wenn `10,000 transactions * 200 bytes = 2,000,000 bytes`, aber ein Rollup einen `400,000-byte batch` postet, liegt der Durchschnitt bei `400,000 / 10,000 = 40 bytes/transaction` oder `5x` Datenkomprimierung. Dies allein sagt noch nichts über Sequenzer-, Proof-, Bridge-, Datenverfügbarkeits- oder Upgrade-Key-Risiko aus.
- In einem anschaulichen Stichprobenmodell mit `4,096 shares` hält ein Gegner `25% = 1,024 shares` zurück. Wenn `30 independent uniform samples with replacement` genommen werden, beträgt die Wahrscheinlichkeit, dass alle zurückgehaltenen Anteile fehlen, `(3,072 / 4,096)^30 = 0.75^30 = 0.0001785821 = 0.01785821%`; Die modellierte Erkennung ist `99.98214179%`. Unabhängigkeit, Einheitlichkeit und das Quellensteuermodell sind Annahmen und keine Produktionsgarantie.
## Risiken
- Behandlung der Trilemma-Heuristik als bewiesener universeller Satz.
- Skalierbarkeit, Dezentralisierung oder Sicherheit bleiben undefiniert.
- Hinzufügen unterschiedlicher Proxys zu einer undurchsichtigen oder dimensionslosen Partitur.
- Rosinenpickerei bewarb Spitzen-TPS statt nachhaltigem Durchsatz.
- Melden von Durchschnittswerten unter Ausblenden der Tail-Latenz und des Fehlerlastverhaltens.
- Nutzung der Gebühren allein als Skalierbarkeitsmaßnahme ohne Arbeitsaufwand oder Subventionen.
- Behandeln von Rohknoten-, Validator- oder Adresszahlen als unabhängige Einheiten.
- Ignorieren von delegiertem Einsatz, Hash-Leistung und gemeinsamer Bedienerkontrolle.
- Ignorieren der Kunden-, Cloud-, geografischen und Governance-Konzentration.
- Ohne Hardware-, Bandbreiten-, Speicher-, Synchronisierungs- und Kapitalbarrieren.
- Ein System ohne einen angegebenen Gegner und Schwellenwert als sicher bezeichnen.
- Verschmelzung von Sicherheit, Lebendigkeit, Endgültigkeit, Zensurwiderstand und Erholung.
- Ignorieren von Datenverfügbarkeit, historischem Abruf und Statuswachstum.
- Überbewerten von Light-Client-, Proof- oder Sampling-Garantien und Annahmen.
- Vergleich des L1- und L2-Durchsatzes, als ob ihre Garantien identisch wären.
- Angenommen, ein Rollup erbt alle Sicherheitseigenschaften der Basisschicht.
- Sequencer-, Prover-, Challenger-, Bridge-, Admin- und Upgrade-Schlüssel werden ignoriert.
- Vergleich verschiedener Protokollversionen, Arbeitslasten oder Beobachtungsfenster.
- Ableitung der Token-Nachfrage oder des Investitionswerts aus der Architekturqualität.
- Deklaration einer dauerhaften Lösung, nachdem eine Optimierung einen Engpass verschoben hat.
## Häufige Irrtümer
- **Jede Blockchain muss genau zwei von drei Eigenschaften auswählen.** Das Trilemma ist eine vergleichende Heuristik; Systeme besetzen wechselnde Kompromissgrenzen unter unterschiedlichen Annahmen.
- **Mehr Validatoren oder Knoten bedeuten automatisch mehr Dezentralisierung und Sicherheit.** Entitätsgewichte, Software, Hosting, Geografie, Governance und unabhängige Verifizierung sind von Bedeutung.
- **Eine hohe TPS-Schlagzahl beweist skalierbare Dezentralisierung.** Arbeitslast, Hardware, Datenwachstum, Tail-Latenz, Gebühren und Ausfallverhalten bestimmen, ob die Kapazität nachhaltig ist.
- **L2, Modularität oder Sharding beseitigen das Trilemma.** Diese Designs verteilen Ausführung, Daten, Beweisen und Vertrauen neu; Jede Garantie muss vollständig nachverfolgt werden.
- **Die drei Dimensionen sind feste Skalarwerte oder sagen den Token-Wert voraus.** Messungen sind mehrdimensional und versioniert, während die Token-Ökonomie eine separate Frage ist.
## Verwandte Themen
- [Blockchain](/de/crypto/blockchain/)
- [Ebene 2](/de/crypto/layer2/)
- [Modulare Blockchain](/de/crypto/modular-blockchain/)
## Quellen
- [Warum Sharding großartig ist: Die technischen Eigenschaften entmystifizieren](https://vitalik.eth.limo/general/2021/04/07/sharding.html)
- [Skalierung](https://ethereum.org/developers/docs/scaling/)
- [Datenverfügbarkeit](https://ethereum.org/developers/docs/data-availability/)
- [Errichten Sie Ihren eigenen Ethereum-Knoten](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/)
- [Kundenvielfalt](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/)
- [Ethereum Proof-of-Stake-Angriff und -Verteidigung](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/)
- [Bitcoin: Ein elektronisches Peer-to-Peer-Cash-System](https://bitcoin.org/bitcoin.pdf)
- [Überblick über die Blockchain-Technologie](https://doi.org/10.6028/NIST.IR.8202)
Source: https://wiki.fcontext.com/de/crypto/blockchain-trilemma/index.mdx