Deutsch
Oct 19, 2026

Blockchain-Trilemma erklärt: Lässt es sich lösen?

Das Blockchain-Trilemma: Chains erreichen leicht nur zwei von drei Eigenschaften – Dezentralisierung, Sicherheit, Skalierbarkeit. Rollups, Sharding und Sui.

Blockchain-Trilemma erklärt: Lässt es sich lösen?

Das Blockchain-Trilemma, auch Skalierbarkeits-Trilemma genannt, beschreibt die Idee, dass eine Blockchain von drei Eigenschaften nur zwei gleichzeitig leicht erreichen kann: Dezentralisierung, Sicherheit und Skalierbarkeit. Erhöhen Sie den Durchsatz, indem Nodes mehr Arbeit leisten müssen, können weniger Menschen einen Node betreiben; verteilen Sie die Last auf viele kleine Chains, wird jede einzelne leichter angreifbar. Bekannt gemacht hat das Konzept Ethereum-Mitgründer Vitalik Buterin, und die meisten modernen Blockchain-Designs lassen sich als Versuch lesen, ihm zu entkommen.

Dieser Leitfaden erklärt, woher das Trilemma stammt, was jede Eigenschaft tatsächlich bedeutet, wie Rollups, Sharding und parallele Ausführung alle drei erreichen wollen und warum manche Forscher es eher für eine Faustregel als für ein Gesetz halten.

Was ist das Blockchain-Trilemma?

Die klarste Formulierung stammt aus Buterins Essay vom April 2021 „Why sharding is great“. Er beschreibt drei Eigenschaften, die eine Blockchain anstrebt, und sagt, dass „einfache“ Techniken nur zwei davon liefern:

  • Skalierbarkeit: Die Chain „kann mehr Transaktionen verarbeiten, als ein einzelner gewöhnlicher Node (denken Sie an einen handelsüblichen Laptop) verifizieren kann“.
  • Dezentralisierung: Die Chain „kann ohne Vertrauensabhängigkeit von einer kleinen Gruppe großer zentralisierter Akteure laufen“.
  • Sicherheit: Die Chain „kann einem großen Anteil teilnehmender Nodes standhalten, die versuchen, sie anzugreifen“.

Die Idee ist älter als dieser Essay. Ethereums Sharding FAQ, ein frühes Forschungsdokument, fragte bereits, ob „hier eine Art Skalierbarkeits-Trilemma im Spiel ist“, und definierte Dezentralisierung als ein System, in dem jeder Teilnehmer nur die Ressourcen „eines gewöhnlichen Laptops oder kleinen VPS“ benötigt.

Beachten Sie, was diese Definitionen bewirken. Skalierbarkeit wird an dem gemessen, was ein gewöhnlicher Node bewältigen kann, nicht als reine Zahl von Transaktionen pro Sekunde. Eine Chain, die 100.000 Transaktionen pro Sekunde schafft, für deren Verifizierung aber Rechenzentrums-Hardware nötig ist, hat das Trilemma nicht gelöst; sie hat Skalierbarkeit auf Kosten der Dezentralisierung gewählt.

Die drei klassischen Kompromisse

Buterins Essay ordnet naive Designs drei Gruppen zu, die jeweils zwei Ecken wählen:

DesignErreichtOpfertWarum
Traditionelle Blockchains (Bitcoin, Ethereum vor dem Sharding)Dezentralisierung, SicherheitSkalierbarkeitJeder Teilnehmer betreibt einen Full Node, der jede Transaktion verifiziert, daher begrenzt ein gewöhnlicher Computer den Durchsatz.
High-TPS-Chains mit kleinen Validator-SetsSkalierbarkeit, SicherheitDezentralisierungEine kleine Zahl von Nodes, laut Buterin oft 10 bis 100, hält den Konsens untereinander auf leistungsstarker Hardware aufrecht.
Multi-Chain-ÖkosystemeSkalierbarkeit, DezentralisierungSicherheitDie Last wird auf viele unabhängige Chains verteilt, doch ein Angreifer muss nur eine davon übernehmen, die womöglich nur einen winzigen Teil des Ganzen ausmacht.

Die zugrunde liegende Spannung sind die Ressourcenkosten. Muss jeder Node alles prüfen, bestimmt der langsamste Node, den man einbeziehen will, das Tempolimit. Hebt man dieses Limit an, schrumpft der Kreis derer, die teilnehmen können. Teilt man die Arbeit auf Gruppen auf, ist jede Gruppe kleiner und billiger zu korrumpieren. Unser Leitfaden Proof of Stake vs. Proof of Work erklärt, wie die Kosten eines Angriffs auf eine Chain überhaupt festgelegt werden.

Rollups: Ausführung off-chain skalieren

Ethereums wichtigste Antwort waren Layer-2-Rollups. Ein Rollup führt Transaktionen in einem separaten Netzwerk aus und veröffentlicht die Daten anschließend auf Ethereum, zusammen mit einem Gültigkeitsnachweis (ZK-Rollups) oder einer Behauptung, die jeder mit einem Fraud Proof anfechten kann (Optimistic Rollups). Die Basisschicht bleibt klein genug, damit gewöhnliche Nodes sie verifizieren können, während die Ausführung anderswo stattfindet.

Im Sinne des Trilemmas versuchen Rollups, Ethereums Dezentralisierung und Sicherheit zu bewahren und zugleich Skalierung hinzuzufügen. Buterins Essay vom Dezember 2021 „Endgame“ formulierte den Kompromiss: „Die Blockproduktion ist zentralisiert, die Blockvalidierung ist vertrauenslos und hochgradig dezentralisiert, und Zensur wird weiterhin verhindert.“ Ein leistungsstarker Betreiber darf Blöcke produzieren, solange jeder sie günstig prüfen kann.

Die Praxis hinkt der Theorie hinterher. Am 17. Oktober 2026 stufte L2BEAT 57 der 67 bewerteten Layer-2-Projekte als Stage 0 ein, was bedeutet, dass Betreiber die Regeln weiterhin außer Kraft setzen konnten. Am 3. Februar 2026 schrieb Buterin, dass „die ursprüngliche Vision der L2s und ihrer Rolle in Ethereum keinen Sinn mehr ergibt und wir einen neuen Weg brauchen“, und verwies auf langsame Fortschritte bei der Dezentralisierung sowie auf eine Basisschicht, die inzwischen mit niedrigen Gebühren skaliert (The Defiant). Unser Layer-2-Leitfaden behandelt Rollups im Detail.

Sharding: die Arbeit auf Layer 1 aufteilen

Sharding geht das Trilemma direkt an. Statt dass jeder Node jede Transaktion verarbeitet, werden die Validatoren in Gruppen (Shards) aufgeteilt, die jeweils einen Teil der Last übernehmen, während eine koordinierende Schicht die Shards in Übereinstimmung hält. Damit sich ein Angreifer nicht auf einen Shard konzentrieren kann, werden Validatoren zufällig zugewiesen und neu gemischt. Buterins Essay von 2021 argumentiert, diese Kombination sei „eine Technik, die alle drei liefert“: Jeder Node leistet nur einen Bruchteil der Arbeit, Supernodes sind nicht nötig, und ein Angreifer muss das gesamte System bezwingen statt nur eines kleinen Teils.

Ethereum selbst hat sich vom Sharding der Ausführung abgewandt. Stattdessen shardet es nun Daten: Blobs aus dem Dencun-Upgrade (13. März 2024) und PeerDAS aus dem Fusaka-Upgrade (3. Dezember 2025) erlauben es Nodes, die Verfügbarkeit von Rollup-Daten durch Stichproben zu bestätigen, statt alles herunterzuladen (Ethereum Foundation).

MultiversX betreibt Execution Sharding auf seiner Haupt-Chain. Sein Adaptive State Sharding kombiniert Netzwerk-, Transaktions- und State-Sharding mit einer Metachain, die in jeder Epoche entscheidet, welche Nodes zwischen Shards wechseln; die Auswahl beruht auf Zufall, sodass sie nicht im Voraus vorhersehbar ist. Im Rahmen des Secure-Proof-of-Stake-Konsenses muss jeder Validator mindestens 2.500 EGLD staken (MultiversX-Dokumentation). Die Live-Netzwerkkonfiguration vom 17. Oktober 2026 zeigte 3 Execution-Shards, 400 Nodes pro Shard und eine Rundenzeit von 600 ms (MultiversX Gateway).

Der Preis ist Komplexität. Eine Transaktion, die Konten auf zwei Shards betrifft, läuft in zwei Schritten und asynchron ab, was manche DeFi-Interaktionen schwerer kombinierbar macht. Unser Sharding-Leitfaden und die Erklärung zu EGLD und MultiversX gehen tiefer.

DAGs und parallele Ausführung: der Ansatz von Sui

Ein dritter Weg behält eine einzige Chain bei, nutzt aber jeden Kern jedes Validators. Sui ordnet Transaktionen mit Mysticeti, einem Konsensprotokoll, bei dem Validatoren parallel Blöcke vorschlagen und die Blöcke aufeinander verweisen, sodass ein gerichteter azyklischer Graph (DAG) entsteht. Laut Sui-Dokumentation committet Mysticeti im Durchschnitt in etwa 0,5 Sekunden, bei einem anhaltenden Durchsatz von 200.000 Transaktionen pro Sekunde in Benchmarks; zugleich wird darauf hingewiesen, dass dies Werte aus kontrollierten Tests und keine Produktionsmetriken sind.

Auch Suis Datenmodell hilft. Jede Transaktion deklariert die Objekte, die sie nutzt, und laut der Dokumentation zum Transaktionslebenszyklus werden Transaktionen, deren Inputs nicht kollidieren, vollständig parallel ausgeführt. Zwei Personen, die in zwei verschiedenen Pools handeln, warten nicht aufeinander.

Im Sinne des Trilemmas steigert dies die Skalierbarkeit, indem jeder Validator effizienter wird, statt das Netzwerk aufzuteilen. Der Kompromiss liegt in den Hardware-Anforderungen. Suis Validator-Leitfaden empfiehlt mindestens 24 physische Kerne, 128 GB Arbeitsspeicher, 4 TB NVMe-Speicher und eine 1-Gbit/s-Verbindung, weit mehr als ein handelsüblicher Laptop. Unsere Leitfäden zu Sui und Mysticeti erklären das Design.

Ist das Trilemma real? Die wichtigsten Kritikpunkte

Das Trilemma ist eine nützliche Kurzformel, aber kein bewiesenes Theorem. Häufige Einwände:

  • Die Begriffe sind unscharf. Für „dezentral“ und „sicher“ gibt es kein einheitlich anerkanntes Maß. Eine Chain kann ihre Validatoren, ihre Full Nodes, die Verteilung ihres Stakes oder ihre Client-Vielfalt zählen, und jede Kennzahl liefert eine andere Antwort.
  • Es ist eine Momentaufnahme heutiger Technologie. Die ursprüngliche Formulierung beschreibt, was „einfache“ Techniken erreichen. Gültigkeitsnachweise, Data Availability Sampling und bessere Konsensprotokolle haben die Grenze jeweils verschoben, weshalb Buterin selbst argumentiert, dass Sharding und Rollups alle drei erreichen können.
  • Hardware wird immer besser. Was als „gewöhnlicher Node“ gilt, wächst jedes Jahr, sodass ein Durchsatzniveau, das einst Zentralisierung erforderte, später auf Consumer-Geräten laufen kann.
  • Auch andere Kompromisse zählen. Latenz, Kombinierbarkeit, Kosten und Komplexität tauchen im Dreieck nicht auf, entscheiden aber, welches Design zu welchem Einsatz passt. Sharding etwa skaliert gut, macht Cross-Shard-Aufrufe aber asynchron.
  • Das Marketing missbraucht es. Zahlreiche Projekte behaupten, „das Trilemma gelöst“ zu haben. Prüfen Sie in der Praxis, was eine Chain über die Validator-Hardware voraussetzt, wie viele unabhängige Parteien Nodes betreiben und was ein Angreifer kontrollieren müsste.

Ein faires Fazit: Es gibt nichts umsonst, aber der Preis jeder Ecke ist gesunken. Designs unterscheiden sich vor allem darin, welche Annahmen sie zu treffen bereit sind.

Wo JewelSwap einzuordnen ist

JewelSwap basiert auf Layer-1-Chains, die unterschiedliche Wege durch das Trilemma gehen: Liquid Staking mit JWLEGLD auf dem geshardeten MultiversX, JWLSUI auf Sui und JWLXRD auf Radix. Das Design jeder Chain prägt Gebühren, Geschwindigkeit und das, worauf Sie vertrauen müssen.

Häufig gestellte Fragen

Was ist das Blockchain-Trilemma einfach erklärt?

Es ist die Idee, dass eine Blockchain von drei Eigenschaften nur zwei leicht haben kann: Dezentralisierung, Sicherheit und Skalierbarkeit. Die Verbesserung einer Eigenschaft, etwa des Durchsatzes, geht meist zulasten einer anderen, etwa der Zahl der Menschen, die sich den Betrieb eines Nodes leisten können.

Wer hat das Blockchain-Trilemma erfunden?

Vitalik Buterin, Mitgründer von Ethereum, hat es bekannt gemacht. Es findet sich in Ethereums früher Sharding FAQ und in seinem Essay vom April 2021 „Why sharding is great“, der alle drei Eigenschaften definiert.

Ist das Skalierbarkeits-Trilemma dasselbe wie das Blockchain-Trilemma?

Ja. Beide Namen beschreiben denselben Zielkonflikt zwischen Dezentralisierung, Sicherheit und Skalierbarkeit. Buterin selbst spricht vom Skalierbarkeits-Trilemma.

Hat jemand das Blockchain-Trilemma gelöst?

Keine Chain hat dies zweifelsfrei bewiesen. Rollups, Sharding und parallele Ausführung verschieben jeweils die Grenzen, beruhen aber auf Annahmen über Betreiber, Hardware oder Cross-Shard-Komplexität. Betrachten Sie „Trilemma gelöst“ als Marketingaussage und prüfen Sie die Details.

Wie hängen Layer 2s mit dem Trilemma zusammen?

Rollups verlagern die Ausführung von der Basisschicht weg, damit Ethereum leicht verifizierbar bleibt, und wollen so Skalierung hinzufügen, ohne Dezentralisierung oder Sicherheit aufzugeben. In der Praxis wurden die meisten im Oktober 2026 von L2BEAT noch als Stage 0 eingestuft, was bedeutet, dass Betreiber die Regeln außer Kraft setzen konnten.

Weiterlesen

Dieser Artikel dient der Information und ist keine Finanzberatung. Die Zahlen stammen vom 17. Oktober 2026 von L2BEAT, der Ethereum Foundation sowie aus der Dokumentation von MultiversX und Sui und ändern sich im Laufe der Zeit; die Quellen sind im gesamten Text verlinkt.

About the author.

Co-Founder at JewelSwap & Chief Strategy Officer at iDenfy. Viktor brings his successful track record of superb development & project management.