Warum TON gewöhnliche Explorer überfordert
TON baut auf einem Aktormodell auf. Jeder Vertrag ist ein eigenständiger Aktor mit eigenem Zustand, und Verträge verständigen sich ausschließlich über Nachrichten. Synchrone Aufrufe gibt es nicht — ein Vertrag kann keinen anderen aufrufen und innerhalb derselben Ausführung auf die Antwort warten.
Eine einzelne Nutzerhandlung zerfällt deshalb in eine Folge. Sie senden eine Nachricht an Ihren Wallet-Vertrag. Der sendet eine Nachricht an ein Jetton-Wallet. Das sendet eine Nachricht an das Jetton-Wallet des Empfängers. Das kann eine Benachrichtigung weiterreichen. Jeder Sprung ist eine eigene Transaktion auf der Chain, in einem eigenen Block, womöglich in einem eigenen Shard.
Ein Explorer, der Ihnen „die Transaktion" zeigt, zeigt Ihnen den ersten Sprung. Alles Wesentliche geschah danach — und scheiterte etwas drei Sprünge weiter, sieht der erste Sprung weiterhin vollkommen erfolgreich aus.
Das ist dasselbe strukturelle Muster wie NEAR-Quittungen und Polkadots XCM, und es erzeugt dieselbe Art von Verwirrung. Auf TON ist sie ausgeprägter, weil sie schon die einfachste Token-Überweisung betrifft.
Jetton-Wallets, und wo Ihre Token tatsächlich sind
TONs Token-Standard heißt Jetton und funktioniert nicht wie ERC-20.
Auf Ethereum hält ein Token-Vertrag eine Zuordnung der Guthaben aller Halter. Auf TON bekommt jeder Halter einen eigenen Jetton-Wallet-Vertrag, getrennt ausgerollt, der nur sein Guthaben hält. Der Hauptvertrag regiert den Token; er speichert nicht, wem was gehört.
Das ist eine bewusste Entscheidung zur Skalierung — sie verhindert, dass ein einzelner Vertrag über Shards hinweg zum Nadelöhr wird — und sie erzeugt eine bestimmte, wiederkehrende Verwirrung: Ihr Token-Guthaben liegt nicht an Ihrer Wallet-Adresse. Es liegt an einer abgeleiteten Jetton-Wallet-Adresse, die Ihre Wallet besitzt.
Leute senden Token ständig an die falsche davon. Tonviewer beschriftet sie ausdrücklich und zeigt zu jedem Jetton-Wallet den Eigentümer — das macht das Modell verständlich statt beunruhigend.
Die andere Folge ist, dass der erstmalige Empfang eines Jettons das Ausrollen Ihres Jetton-Wallets verlangt, was einen kleinen, der Überweisung beigefügten Betrag kostet. Hat der Absender zu wenig beigelegt, wird die Überweisung zurückgewiesen — und das ist der Fehlerfall, den der nächste Abschnitt behandelt.
Zurückgewiesene Nachrichten, TONs Fassung eines Reverts
Kann eine TON-Nachricht nicht verarbeitet werden, wird sie zurückgewiesen: Der Wert kehrt abzüglich Gebühren zum Absender zurück. Das ist der normale Fehlerfall und keineswegs wie ein EVM-Revert, denn die ursprüngliche Transaktion ist zum Zeitpunkt der Rückweisung bereits gelungen.
Die praktische Folge verdient es, zweimal gesagt zu werden. Auf TON heißt eine erfolgreiche Transaktion nicht ein erfolgreiches Ergebnis. Sie heißt, dass Ihre Nachricht zur Zustellung angenommen wurde. Was am anderen Ende geschah, ist ein eigenes Ereignis, das Sekunden später eintreffen kann.
Tonviewer kennzeichnet zurückgewiesene Nachrichten im Ablauf deutlich. Ist eine Überweisung „durchgegangen" und der Empfänger meldet nichts, ist das die erste Anlaufstelle — und es erklärt die überwältigende Mehrheit dieser Fälle.
Bei unseren eigenen Tests verfolgten wir eine Jetton-Überweisung, die zwei Explorer als erfolgreich auswiesen. Der erste Sprung gelang, der zweite gelang, und der dritte wurde zurückgewiesen, weil das Jetton-Wallet des Empfängers nicht ausgerollt war und der beigefügte Wert zum Ausrollen nicht reichte. Nur der vollständige Nachrichtenablauf brachte das ans Licht.
Mit TON arbeiten, ohne überrascht zu werden
Drei Gewohnheiten machen TON erheblich weniger verwirrend.
Erstens: stets den vollständigen Ablauf ansehen statt der Transaktion. Bietet Ihr Explorer keinen, nutzen Sie für diese Frage den falschen Explorer.
Zweitens: Jettons über die Adresse ihres Hauptvertrags identifizieren, nicht über den Namen. Jetton-Namen sind beliebig und werden frei mehrfach vergeben, genau wie Token-Namen auf jeder anderen Chain — und die Architektur getrennter Wallets macht es etwas leichter, sich darüber zu verwirren, welchen Vertrag man eigentlich ansieht.
Drittens: beide Explorer als Lesezeichen behalten. Auf einer baulich derart ungewöhnlichen Chain hat uns eine zweite Darstellung derselben Daten mehr Verwirrung aufgelöst als auf jedem anderen Netz. Widersprechen sich Tonviewer und Tonscan, ist der Widerspruch selbst eine Information — meist geht einer der beiden mit einem ungewöhnlichen Nachrichtenmuster anders um, und die Rohansicht ist die, der zu trauen ist, während Sie herausfinden, welcher.
Shards, und warum Blockhöhen nicht bedeuten, was Sie erwarten
TON ist geshardet, und die Shardung ist dynamisch — das Netz teilt und vereint Shards je nach Last, statt eine feste Zahl zu betreiben.
Für alle, die einen Explorer lesen, folgt daraus: Es gibt keine einzelne Blockhöhe. Es gibt eine Masterchain, die koordiniert, und Workchain-Shards, die jeweils eigene Blöcke erzeugen. Eine Transaktion lebt in einem Shard-Block, der dann von einem Masterchain-Block referenziert wird.
Blockhöhen zwischen TON und einer anderen Chain zu vergleichen ist deshalb sinnlos, und sie zwischen zwei TON-Explorern zu vergleichen kann heißen, Verschiedenes zu vergleichen. Explorer zeigen als Kennzahl im Allgemeinen die Folgenummer der Masterchain, was die vernünftige Wahl ist und nicht die einzig vertretbare.
Die Endgültigkeit folgt der Masterchain. Eine in einem Shard-Block aufgenommene Transaktion ist endgültig, sobald dieser Shard-Block von einem Masterchain-Block referenziert wird — das geschieht schnell, ist aber ein zweiter Schritt und nicht der erste.
Für den gewöhnlichen Gebrauch spielt nichts davon eine Rolle. Es zählt, wenn Sie Daten zwischen Werkzeugen abgleichen, etwas bauen, das Bestätigungen verfolgt, oder verstehen wollen, warum zwei Explorer verschiedene Zahlen für scheinbar dasselbe melden.
Es ist zudem der eigentliche Grund für die Asynchronität, die den Rest dieser Seite bestimmt. Verträge auf verschiedenen Shards können einander nicht synchron aufrufen, weil die Shards nicht im Gleichschritt laufen — das Nachrichtenmodell ist keine Entwurfsvorliebe, es ist eine Folge der Shardung.