TON-Architektur erklärt: Masterchain, Workchains und Sharding (2026)
— By Tony Rabbit in Tutorials
Die Architektur von TON ist ungewöhnlich: eine Hierarchie von Chains, die sich automatisch aufteilen, wenn die Nachfrage steigt. Dieser Leitfaden erklärt die Masterchain, Workchains, Shardchains, die TVM und das Validator-Design, das alles zusammenbindet.
Die Architektur von TON ist eines der am meisten diskutierten und am wenigsten verstandenen Designs im Bereich Krypto. Die meisten Chains sind Einzelzustandsmaschinen: eine Chain, ein globales Hauptbuch, ein Engpass. TON ist eine Hierarchie von Chains, die sich automatisch aufteilen oder zusammenführen können, basierend auf der Nachfrage. Das Ergebnis ist ein Netzwerk, das sich für die Benutzer wie eine einzige Anwendung anfühlt, während es sich im Hintergrund wie viele verbundene Chains verhält.
Schnelle Antwort: TON ist als drei verbundene Schichten aufgebaut. Die Masterchain koordiniert das gesamte Netzwerk und speichert Validator-Daten. Workchains führen Anwendungslogik mit ihren eigenen Regelsets aus, und derzeit ist die am häufigsten verwendete Workchain die Basis-Workchain (Workchain 0). Shardchains sind Unterteilungen einer Workchain, die sich bei hoher Last aufteilen und bei sinkender Last wieder zusammenführen. Alle Chains verwenden die TVM (TON Virtual Machine), und die Validatoren werden von der Masterchain über sie rotiert.
- Die Masterchain ist die Quelle der Wahrheit. Sie enthält Informationen zu Validatoren, Konfigurationen und Verweise auf alle anderen Chains.
- Workchains können unterschiedliche Regelsets haben. Heute verarbeitet die Basis-Workchain die meisten Aktivitäten.
- Shardchains teilen sich automatisch auf. Bei hoher Last kann sich ein Shard in zwei aufteilen. Unter ruhigen Bedingungen führen sie sich wieder zusammen.
- Die TVM ist asynchron. Verträge senden Nachrichten, anstatt synchronen Aufruf zu machen.
- Validatoren rotieren. Die Masterchain weist Validatorgruppen in jeder Runde aktiven Shards zu.
Die drei Schichten von TON
Die Hierarchie ist der einfachste Ausgangspunkt. Stellen Sie sich TON als eine Masterchain an der Spitze, eine kleine Anzahl von Workchains darunter und viele Shardchains, die aus jeder Workchain herauswachsen.
Masterchain
Die Masterchain steht an der Spitze der Hierarchie. Sie verfolgt den Validatorensatz des Netzwerks, die aktuellen Konfigurationsparameter und verweist auf den neuesten Block jeder anderen Chain. Wenn Sie den "globalen Zustand" von TON lesen, lesen Sie tatsächlich die Masterchain plus die neuesten Verweise, auf die sie zeigt.
Workchains
Workchains sind die mittlere Schicht. Das Protokoll erlaubt bis zu 2^32 Workchains, die jeweils ihre eigenen Regelsets und Einstellungen für die virtuelle Maschine definieren können. In der Praxis wird heute nur die Basis-Workchain (Workchain 0) weit verbreitet genutzt. Neue Workchains können durch Governance hinzugefügt werden, um spezialisierte Umgebungen zu hosten.
Shardchains
Shardchains sind die unterste Schicht. Jede Workchain kann in Shardchains unterteilt werden, wobei jeder Shard eine Teilmenge von Konten verwaltet. Die Anzahl der Shards ändert sich automatisch mit der Nachfrage, weshalb TON Ausbrüche von Aktivitäten absorbieren kann, ohne an einer einzigen globalen Warteschlange zu ersticken.
Dynamisches Sharding in einfachen Worten
Das auffälligste Merkmal von TON ist das dynamische Sharding. Die Anzahl der Shardchains ist nicht festgelegt; sie passt sich der Nachfrage an.
Aufteilen unter Last
Wenn eine Shardchain beschäftigt wird, löst das Protokoll eine Teilung aus: die bestehende Shardchain wird in zwei neue Shardchains unterteilt, die jeweils die Hälfte des ursprünglichen Kontenbereichs verwalten. Neue Validatoren werden den neuen Shards zugewiesen, und der Durchsatz verdoppelt sich effektiv für diese Workchain.
Zusammenführen bei geringer Last
Wenn zwei benachbarte Shards über einen längeren Zeitraum eine geringe Last haben, können sie sich wieder zu einer Shardchain zusammenführen. Dies hält die Validatorenüberlastung und die Speicherkosten während ruhiger Phasen im Schach.
Warum es für Gebühren wichtig ist
Die meisten Blockchains halten die Gebühren stabil, während die Last leicht ist, und steigen dann während der Überlastung an. Sharding glättet dieses Profil, indem es Kapazität genau dann hinzufügt, wenn Kapazität benötigt wird. Die Benutzererfahrung bleibt günstig und schnell in Regimes, die ein Einzel-Chain-Design erdrücken würden.
Die TON Virtual Machine und asynchrone Verträge
Die TVM ist der Motor, der TON-Smart-Verträge ausführt. Sie unterscheidet sich grundlegend von der EVM, hauptsächlich weil TON asynchrone Nachrichtenübertragung anstelle von synchronen Aufrufen verwendet.
Asynchrone Ausführung
Auf Ethereum kann ein Vertrag einen anderen aufrufen und das Ergebnis innerhalb derselben Transaktion lesen. Auf TON senden Verträge Nachrichten aneinander. Der empfangende Vertrag verarbeitet die Nachricht in einem späteren Schritt, möglicherweise in einem anderen Shard. Das klingt langsamer, aber es ermöglicht TON, die Arbeit parallel über Shards zu verteilen.
Cells, Bags of Cells und Speicherung
TONs Datenmodell verwendet "Cells" als primitive Struktur. Eine Cell ist ein Datenblock mit bis zu vier Verweisen auf andere Cells. Smart-Verträge lesen und schreiben Cells, und die Chain speichert alles als einen Baum von Cells. Die Speicherkosten hängen von der Anzahl der Cells und der Zeit ab, weshalb langfristige Verträge über die Zeit eine kleine "Miete" zahlen.
Sprachen
FunC ist die niedrigstufige Smart-Vertragsprache von TON. Tact ist eine höherstufige Alternative, die in FunC kompiliert. Beide zielen auf die TVM ab. Tact hat an Popularität gewonnen, weil es für Entwickler, die von Solidity kommen, benutzerfreundlicher ist, während FunC die Standardwahl für leistungsoptimierte Verträge bleibt.
Validatoren, Konsens und Rotation
TON verwendet ein byzantinisch fehlertolerantes Konsensprotokoll mit einer rotierenden Validatorenzuweisung.
Wie Validatoren ausgewählt werden
Validatoren setzen TON und bewerben sich um die Teilnahme. Die Masterchain wählt pro Runde einen aktiven Validatorensatz aus. Validatoren rotieren über Shardchains, sodass keine einzelne Gruppe dauerhaft für denselben Shard verantwortlich ist. Dies soll gezielte Angriffe erschweren.
Blockproduktion und Endgültigkeit
Jede Shardchain produziert schnell Blöcke, und die Masterchain verweist auf den neuesten Block jeder Shard. Sobald die Masterchain einen Block bestätigt, wird der entsprechende Zustand als endgültig betrachtet. Der kombinierte Effekt ist eine Benutzer-freundliche Endgültigkeit von unter einer Sekunde im gesamten Netzwerk.
Slashing und wirtschaftliche Sicherheit
Validatoren, die sich falsch verhalten (doppelte Signaturen, offline gehen, ungültige Blöcke produzieren), können einen Teil ihres Stakes verlieren. Die wirtschaftliche Sicherheit hängt von der insgesamt gestakten TON, der Anzahl aktiver Validatoren und den Kosten für den Angriff auf den Rotationsmechanismus ab.
TONs Design vs. Einzel-Chain- und modulare Alternativen
Drei breite Designfamilien dominieren die L1-Gespräche im Jahr 2026.
| Design | Beispiele | Durchsatzansatz | Tradeoff |
|---|---|---|---|
| Einzel-Chain | Bitcoin, Solana | Eine globale Chain, optimiert für Geschwindigkeit | Ein Engpass, regionale Latenz |
| Modularer L2-Stack | Ethereum + Rollups | L1 sichert Rollups, Skalierung auf L2 | Brückenschritte, fragmentierte Liquidität |
| Sharded L1 | TON, NEAR | Viele parallele Shardchains | Asynchrone Ausführung, Cross-Shard-Nachrichtenübertragung |
Was TONs Design für Benutzer und Entwickler bedeutet
- Für Benutzer: untersekündliche Endgültigkeit und geringe Gebühren, selbst wenn das Netzwerk beschäftigt ist.
- Für Entwickler: asynchrone Nachrichtenübertragung erfordert ein anderes Denkmodell als die EVM-Entwicklung.
- Für dApps: Verträge auf verschiedenen Shards können kommunizieren, aber das Latenzmodell ist mehrstufig.
- Für DeFi: Komposabilität ist möglich, aber komplexer als synchrone EVM-Aufrufe.
- Für Speicherung: Langfristige Verträge zahlen Miete, sodass ressourcenbewusstes Design wichtiger ist als bei der EVM.
Ein praktisches Denkmodell
- Denken Sie an die Masterchain als den Registrar. Sie verfolgt, wer was und wann betreibt.
- Denken Sie an Workchains als Anwendungszonen. Die meiste Aktivität findet heute in Workchain 0 statt.
- Denken Sie an Shardchains als elastische Spuren. Sie teilen sich und führen sich mit der Nachfrage zusammen.
- Denken Sie an Verträge als Akteure. Sie senden und empfangen Nachrichten, nicht synchrone Aufrufe.
- Denken Sie an Validatoren als rotierende Koordinatoren. Sie werden in jeder Runde über Shards neu zugewiesen.
Häufig gestellte Fragen
Warum verwendet TON Sharding anstelle einer einzelnen Chain?
Um den Durchsatz zu skalieren, ohne die Gebühren zu erdrücken. Sharding ermöglicht es dem Netzwerk, Kapazität genau dann hinzuzufügen, wenn die Last steigt.
Ist TONs Sharding dasselbe wie das von Ethereum?
Nein. Ethereum skaliert durch externe Rollups; TON shardet innerhalb eines einzigen Netzwerks. Die Benutzererfahrung unterscheidet sich erheblich.
Was ist die Rolle der Masterchain?
Die Masterchain koordiniert das gesamte Netzwerk: Validatorensatz, Konfiguration und Verweise auf den neuesten Block jeder anderen Chain.
Sind TON-Verträge asynchron?
Ja. Verträge senden Nachrichten, anstatt synchronen Aufruf zu machen. Dies ermöglicht die parallele Ausführung über Shards.
Wie viele Workchains hat TON heute?
Das Protokoll erlaubt viele, aber in der Praxis verarbeitet die Basis-Workchain (Workchain 0) fast alle Aktivitäten im Jahr 2026.
Letzte Erkenntnis: Die Architektur von TON tauscht synchrone Einfachheit gegen skalierbare Parallelität ein. Die Hierarchie aus Masterchain, Workchain und Shardchain ist es, die die Gebühren niedrig und die Endgültigkeit schnell hält, selbst wenn das Netzwerk beschäftigt ist. Ihr Verständnis ist der Unterschied zwischen der Nutzung von TON als Black Box und dem zuverlässigen Aufbau darauf.
Haftungsausschluss: Dieser Leitfaden dient nur zu Bildungszwecken und stellt keine Investitions-, Finanz-, Rechts- oder Handelsberatung dar.