Perché TON rompe gli explorer ordinari
TON è costruita su un modello ad attori. Ogni contratto è un attore indipendente con il proprio stato, e i contratti comunicano solo inviandosi messaggi a vicenda. Non ci sono chiamate sincrone — un contratto non può chiamarne un altro e attendere la risposta all'interno della stessa esecuzione.
Quindi una singola azione utente si scompone in una sequenza. Invia un messaggio al suo contratto portafoglio. Quello invia un messaggio a un portafoglio jetton. Quello invia un messaggio al portafoglio jetton del destinatario. Quello potrebbe inviare un messaggio di notifica in avanti. Ogni hop è una transazione on-chain separata, in un blocco separato, possibilmente in uno shard separato.
Un explorer che le mostra "la transazione" le mostra il primo hop. Tutto ciò che è successo davvero è avvenuto dopo, e se qualcosa è fallito tre hop più in basso, il primo hop appare comunque interamente riuscito.
Tonviewer traccia l'albero. Apra un'azione e vede l'intera cascata, con il destino di ogni messaggio. Quello è il prodotto, ed è la differenza tra capire cosa è successo e indovinare.
Portafogli jetton, che confondono tutti
Lo standard di token di TON si chiama Jetton, e non funziona come ERC-20.
Su Ethereum, un contratto di token detiene un mapping del saldo di ogni detentore. Su TON, ogni detentore ottiene il proprio contratto di portafoglio jetton, distribuito separatamente, che detiene solo il suo saldo. Il contratto master governa il token; non memorizza chi possiede cosa.
Questa è una decisione di scalabilità deliberata — evita che un singolo contratto diventi un collo di bottiglia attraverso gli shard — e produce una confusione specifica e ricorrente: il suo saldo di token non si trova al suo indirizzo di portafoglio. Si trova a un indirizzo di portafoglio jetton derivato che il suo portafoglio possiede.
Le persone inviano token costantemente a quello sbagliato tra questi. Tonviewer li etichetta esplicitamente, mostrando il proprietario accanto a ogni portafoglio jetton, il che rende il modello comprensibile piuttosto che allarmante.
Dai nostri test
Abbiamo tracciato un trasferimento di jetton che sembrava fallito. Il primo hop è riuscito, il secondo hop è riuscito, e il terzo è rimbalzato perché il portafoglio jetton del destinatario non era stato distribuito e il valore allegato era insufficiente per distribuirlo. Due dei tre explorer che abbiamo provato mostravano una transazione riuscita. Solo la traccia completa dei messaggi ha rivelato il rimbalzo.
Messaggi rimbalzati: la versione TON di un revert
Quando un messaggio TON non può essere processato, rimbalza — il valore ritorna al mittente, meno le commissioni. Questa è la modalità di fallimento normale e non è nulla come un revert EVM, perché la transazione originale è già riuscita nel momento in cui avviene il rimbalzo.
L'implicazione pratica: su TON, una transazione riuscita non significa un risultato riuscito. Significa che il suo messaggio è stato accettato per la consegna. Ciò che è successo all'altra estremità è un evento separato che potrebbe arrivare secondi dopo.
Tonviewer marca i messaggi rimbalzati chiaramente nella traccia. Se un trasferimento è "passato" e il destinatario non riporta nulla, questo è il primo posto da guardare, ed è il campo che spiega la stragrande maggioranza di quei casi.
TonAPI
Tonviewer è supportato da TonAPI, che offre un livello gratuito con una chiave e piani a pagamento oltre. È una superficie considerevolmente più amichevole dell'accesso al nodo TON grezzo, perché fa lo stesso lavoro di riassemblaggio che fa l'interfaccia web — ottiene tracce piuttosto che messaggi isolati.
Quel riassemblaggio è esattamente il motivo per cui la userebbe piuttosto che interrogare un nodo direttamente. Ricostruire un albero di messaggi da transazioni grezze attraverso gli shard è vero lavoro, e l'API che lo fa per lei è la maggior parte del valore.
Per esigenze più leggere, esistono endpoint HTTP TON pubblici e Tonscan è open source, il che lo rende il punto di partenza migliore se vuole vedere come vengono assemblati i dati piuttosto che fidarsi che lo siano stati.
Tonviewer o Tonscan?
Tonviewer quando ha bisogno di capire cosa è successo — un trasferimento che non è arrivato, un'interazione di contratto con un risultato inaspettato, qualsiasi cosa coinvolga più di un hop.
Tonscan quando vuole velocità e semplicità, o quando vuole uno strumento open source. È più leggero, si rende più velocemente, e fa meno decodifica, il che a volte è esattamente ciò che vuole.
Usi entrambi. Su una chain così strutturalmente insolita, un secondo rendering degli stessi dati ha colto più confusione per noi che su qualsiasi altra rete. E qualunque usi, ricordi le due regole specifiche di TON: i suoi token non sono al suo indirizzo di portafoglio, e una transazione riuscita non è un risultato riuscito.