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. 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 decompone in una sequenza. Invia un messaggio al suo contratto di portafoglio. Quello invia un messaggio a un portafoglio jetton. Quello invia un messaggio al portafoglio jetton del destinatario. Quello potrebbe inviare una notifica in avanti. Ogni salto è 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 salto. Tutto ciò che contava è successo dopo, e se qualcosa è fallito tre salti più in là, il primo salto sembra ancora interamente riuscito.
Questo è lo stesso pattern strutturale delle ricevute NEAR e dell'XCM di Polkadot, e produce la stessa categoria di confusione. Su TON è più acuto perché colpisce anche il più semplice trasferimento di token.
I portafogli jetton, e dove sono davvero i suoi token
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, ciascun 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 è all'indirizzo del suo portafoglio. È a un indirizzo di portafoglio jetton derivato che il suo portafoglio possiede.
Le persone inviano costantemente token al portafoglio sbagliato tra questi. Tonviewer li etichetta esplicitamente, mostrando il proprietario accanto a ogni portafoglio jetton, il che è ciò che rende il modello comprensibile piuttosto che allarmante.
L'altra conseguenza è che ricevere un jetton per la prima volta richiede di distribuire il suo portafoglio jetton, cosa che costa un piccolo importo allegato al trasferimento. Se il mittente ne ha allegato troppo poco, il trasferimento rimbalza — ed è il modo di fallimento che la sezione successiva copre.
I 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. Questo è il modo di fallimento normale e non è affatto come un revert EVM, perché la transazione originale è già riuscita nel momento in cui avviene il rimbalzo.
L'implicazione pratica vale la pena dirla due volte. Su TON, una transazione riuscita non significa un esito riuscito. Significa che il suo messaggio è stato accettato per la consegna. Cosa è successo all'altro capo è un evento separato che potrebbe arrivare secondi dopo.
Tonviewer marca chiaramente i messaggi rimbalzati nella traccia. Se un trasferimento "è passato" e il destinatario non riporta nulla, questo è il primo posto da guardare, e spiega la stragrande maggioranza di quei casi.
Nei nostri stessi test abbiamo tracciato un trasferimento di jetton che due explorer mostravano come riuscito. Il primo salto è riuscito, il secondo è riuscito, e il terzo è rimbalzato perché il portafoglio jetton del destinatario non era stato distribuito e il valore allegato era insufficiente a distribuirlo. Solo la traccia completa dei messaggi lo ha rivelato.
Lavorare con TON senza sorprese
Tre abitudini rendono TON considerevolmente meno confusa.
Primo, guardi sempre la traccia completa piuttosto che la transazione. Se il suo explorer non ne offre una, sta usando l'explorer sbagliato per quella domanda.
Secondo, identifichi i jetton per il loro indirizzo di contratto master piuttosto che per nome. I nomi dei jetton sono arbitrari e duplicati liberamente, esattamente come i nomi dei token su ogni altra chain, e l'architettura a portafoglio separato rende leggermente più facile confondersi su quale contratto stia effettivamente guardando.
Terzo, tenga entrambi gli explorer nei preferiti. Su una chain così strutturalmente insolita, un secondo rendering degli stessi dati ha risolto più confusione per noi che su qualsiasi altra rete. Quando Tonviewer e Tonscan sono in disaccordo, il disaccordo stesso è informazione — di solito significa che uno dei due sta gestendo diversamente un pattern di messaggio insolito, e la vista grezza è quella a cui fidarsi mentre capisce quale.
Gli shard, e perché le altezze di blocco non significano ciò che si aspetta
TON è partizionata, e il partizionamento è dinamico — la rete divide e fonde gli shard secondo il carico piuttosto che far girare un numero fisso.
La conseguenza per chiunque legga un explorer è che non c'è un'altezza di blocco singola. C'è una masterchain, che coordina, e shard di workchain che producono ciascuno i propri blocchi. Una transazione vive in un blocco di shard, che viene poi referenziato da un blocco della masterchain.
Quindi confrontare cifre di "altezza di blocco" tra TON e un'altra chain è privo di senso, e confrontarle tra due explorer TON potrebbe essere confrontare cose diverse. Gli explorer generalmente mettono in evidenza il numero di sequenza della masterchain come cifra principale, il che è la scelta sensata e non l'unica difendibile.
La finalità segue la masterchain. Una transazione inclusa in un blocco di shard è finale una volta che quel blocco di shard è referenziato da un blocco della masterchain, il che avviene rapidamente ma è un secondo passo piuttosto che il primo.
Nulla di ciò colpisce l'uso ordinario. Conta quando sta riconciliando dati tra strumenti, costruendo qualsiasi cosa che tracci le conferme, o cercando di capire perché due explorer riportano numeri diversi per ciò che sembra la stessa cosa.
È anche la ragione sottostante dell'asincronia che domina il resto di questa pagina. I contratti su shard diversi non possono chiamarsi sincronicamente perché gli shard non sono in lockstep — il modello di messaggi non è una preferenza di progettazione, è una conseguenza del partizionamento.