Energia e bandwidth: due costi, una confusione
Tron non ha una singola cifra di gas. Ha due risorse separate, e fraintenderle produce la maggior parte dei ticket di supporto Tron.
Il bandwidth copre la dimensione in byte della sua transazione. Ogni conto riceve una piccola allocazione quotidiana gratuita, sufficiente per alcuni semplici trasferimenti. La esaurisce e paga in TRX.
L'energia copre l'esecuzione di smart contract. Un trasferimento TRC-20 — che include ogni movimento USDT — è una chiamata di contratto, quindi consuma energia. Non c'è alcuna allocazione di energia gratuita affatto. O staka TRX per ottenere energia, o brucia TRX per coprirla.
La conseguenza che sorprende le persone: inviare USDT su Tron può costare notevolmente di più che inviare TRX, perché uno è una chiamata di contratto e l'altro no. E il costo varia con il destinatario — creare un nuovo saldo di token consuma sostanzialmente più energia che aggiornarne uno esistente.
| Azione | Risorsa | Cosa ci si aspetta | Cosa succede |
|---|---|---|---|
| Invia TRX | Bandwidth | Una commissione | Spesso gratuito, nell'allocazione quotidiana |
| Invia USDT a un detentore esistente | Energia + bandwidth | Economico, come inviare TRX | Costa vero TRX a meno che non abbia stakato |
| Invia USDT a un nuovo indirizzo | Molta più energia | Uguale a qualsiasi altro trasferimento | Notevolmente più costoso |
| Staka TRX per energia | Blocca il TRX | Reversibile istantaneamente | Il destaking ha un periodo di attesa |
Tronscan mostra energia e bandwidth consumati su ogni pagina di transazione, e le risorse stakate su ogni pagina di conto. Una volta che sa dove guardare, la commissione smette di essere misteriosa.
Perché il suo indirizzo sembra vuoto
Un trasferimento TRC-20 non è una transazione Tron che sposta un token. È una transazione Tron che chiama il contratto del token, che emette un evento Transfer. Il valore non appare mai nei campi propri della transazione.
La conseguenza pratica è una cosa che le persone incontrano costantemente: una pagina di indirizzo che mostra "nessuna transazione" può ancora avere attività di token sostanziale, perché i movimenti di token vivono sul tab TRC-20.
Questo è lo stesso pattern strutturale dei trasferimenti ERC-20 su Ethereum, e inganna le persone per la stessa ragione. La lista principale non è tutto il quadro, e su una chain dove la maggior parte dell'attività è trasferimenti di stablecoin, la lista principale ne rappresenta a malapena una parte.
Il secondo punto pratico è la verifica del contratto. L'USDT su Tron ha un unico indirizzo di contratto legittimo, e sono stati distribuiti token con lo stesso nome e simbolo che puntano a contratti diversi. Controlli sempre l'indirizzo del contratto piuttosto che il nome mostrato. Quell'abitudine vale la pena costruirla ovunque, e conta di più qui perché il volume di attività genuina in stablecoin rende conveniente l'usurpazione.
Ricevere pagamenti su Tron senza sorprese
Se riceve regolarmente pagamenti in stablecoin su Tron, tre cose valgono la pena di essere fatte.
Primo, staki un po' di TRX per energia. Converte un costo per transazione in un blocco di capitale una tantum, e su qualche centinaio di trasferimenti la differenza è sostanziale. Questa è un'osservazione meccanica sul modello di commissioni, non un consiglio di investimento, e il ritardo di destaking è un vincolo reale da considerare.
Secondo, capisca che la sua prima ricezione di un dato token costa di più al mittente. Se sta citando a qualcuno un importo di pagamento, quell'asimmetria esiste e non è colpa di nessuno.
Terzo, metta due explorer nei preferiti. Tronscan occasionalmente ritarda rispetto alla punta della chain, e 3xpl o OKLink confermeranno entro secondi se una transazione esiste. Contro-verificare un problema apparente contro un secondo indice lo risolve più spesso di quanto non lo faccia.
La questione della reputazione, affrontata
Tron ha una cattiva reputazione in parti del mondo crypto e un uso genuino enorme, ed entrambe le cose sono vere simultaneamente. Vale la pena essere diretti su questo piuttosto che lasciarlo implicito.
L'uso è reale ed è concentrato in trasferimenti di stablecoin su scala di rimesse, dove economico e veloce batte quasi ogni altra considerazione. Per qualcuno che invia denaro attraverso un confine, i dibattiti architetturali sono irrilevanti e la commissione no.
Le critiche sono anche reali. L'insieme di validatori è piccolo rispetto ad altre grandi chain, la governance è concentrata, e la rete ha attratto una quota di flussi illeciti proporzionale alla sua convenienza per spostare valore. Un explorer non può risolvere nulla di ciò, e nemmeno noi.
Ciò che un explorer può fare è permetterle di verificare lei stesso un'affermazione specifica piuttosto che affidarsi alla caratterizzazione di chiunque. Questo è tutto l'argomento per i registri pubblici, e si applica qui esattamente come si applica ovunque altro su questo sito.
Indirizzi, formati e gli errori che causano
Gli indirizzi Tron iniziano con T e sono codificati in base58, il che li distingue chiaramente dagli indirizzi Ethereum. Hanno anche una rappresentazione esadecimale usata internamente dai contratti e da alcune API, che inizia con 41.
Quella doppia rappresentazione causa vera confusione. Un'API che restituisce un indirizzo esadecimale e un explorer che ne mostra uno base58 stanno mostrando lo stesso indirizzo, e le persone concludono ragionevolmente di guardare cose diverse. La maggior parte degli explorer converte per la visualizzazione; alcuni strumenti no.
L'errore più costoso è inter-chain. L'USDT esiste su Tron come TRC-20, su Ethereum come ERC-20, e su diverse altre reti. Inviare USDT TRC-20 a un indirizzo Ethereum, o selezionare la rete sbagliata su un prelievo da piattaforma di scambio, è uno dei modi più comuni in cui le persone perdono stablecoin. I formati di indirizzo differiscono abbastanza che un controllo attento lo coglie, e il controllo è facile da saltare quando l'interfaccia ha pre-riempito una rete.
Quando una piattaforma di scambio le dà un indirizzo di deposito, le dice anche la rete. Quel campo non è consultivo. Lo confermi contro la rete da cui sta effettivamente inviando, ogni volta, e confermi che il primo carattere dell'indirizzo corrisponda a ciò che usa quella rete.
La stessa classe di errore appare su ogni asset multi-chain. Vale la pena un'abitudine piuttosto che una regola: prima di qualsiasi trasferimento di conseguenza, controlli la rete, controlli i primi caratteri dell'indirizzo, e invii un piccolo importo di prova quando la somma è abbastanza grande da far male.