Tre chain, tre compiti
La rete principale di Avalanche non è una chain ma tre, ciascuna specializzata.
La C-Chain è compatibile con EVM ed è dove vive essenzialmente tutta l'attività applicativa. Se ha usato Avalanche, ha usato la C-Chain. Si comporta come qualsiasi altra rete EVM — stessi indirizzi, stesso strumentario, stessi contratti.
La X-Chain gestisce la creazione e il trasferimento di asset usando un modello più vicino a UTXO che agli account. Era la progettazione originale per il trasferimento di valore ad alto throughput.
La P-Chain coordina validatori, staking e creazione di subnet. Se fa staking di AVAX o fa girare un validatore, questo avviene qui.
L'attrito è che questi usano formati di indirizzo diversi e modelli di dati diversi, e spostare asset tra loro è un trasferimento cross-chain esplicito piuttosto che un'operazione interna. Snowtrace è l'unico explorer che le permette di seguire quel movimento — e dato quante persone sono state confuse da fondi che "scomparivano" tra le chain, questo da solo gli guadagna la raccomandazione.
Spostarsi tra C, X e P
Un asset sulla C-Chain non è automaticamente disponibile sulla P-Chain. Per fare staking di AVAX deve esportarlo dalla C-Chain e importarlo sulla P-Chain, il che sono due transazioni su due chain con due identificatori diversi.
Questo produce il pattern che appare in tutti i nostri test — i messaggi L1-a-L2 di Arbitrum, le catene di messaggi di TON, l'XCM di Polkadot. Un'azione diventa diversi record e l'identificatore non si trasferisce. Cercare l'hash di esportazione sulla chain di destinazione non trova nulla, e la conclusione ragionevole è che i fondi siano andati persi.
Non lo sono. Sono nell'importazione, in attesa di essere completati o già completati sotto un hash diverso. Snowtrace mostra entrambi i lati, il che converte una situazione spaventosa in un controllo di due minuti.
La regola generale
Ogni volta che un sistema copre più chain o è asincrono, un'azione utente diventa diversi record on-chain con identificatori diversi. Prima di concludere che i fondi sono svaniti, controlli se sta cercando l'identificatore giusto sulla chain giusta. Nella nostra esperienza questo spiega la stragrande maggioranza di questi casi.
Subnet, e il problema di explorer che creano
La scommessa architetturale di Avalanche sono le subnet — reti indipendenti con i propri validatori, regole e, spesso, le proprie macchine virtuali. Una subnet può essere con permessi, può usare un token di gas personalizzato, e può essere sintonizzata per un'applicazione specifica.
Per un explorer questo è un problema genuino. Ogni subnet è effettivamente una chain separata che necessita indicizzazione separata, e ce ne sono molte. Snowtrace, attraverso la più ampia rete di Routescan, ne copre un numero sostanziale, ma la qualità varia e una piccola subnet potrebbe avere supporto minimo.
La C-Chain è dove si trova lo strumentario maturo. Se sta lavorando su una subnet, controlli quale copertura di explorer esiste prima di affidarsi ad essa — questa è la stessa cautela sulla qualità dell'istanza che si applica alle distribuzioni Blockscout, e per la stessa ragione strutturale.
API e dati di staking
Snowtrace espone endpoint compatibili con Etherscan per la C-Chain, il che significa che il codice EVM generalmente funziona con un cambio di URL di base. Li abbiamo trovati utilizzabili senza chiave a basso volume, il che è sempre più insolito.
I dati di staking della P-Chain sono l'offerta più distintiva. Lo staking di Avalanche ha proprietà specifiche — uno stake minimo, una durata minima, e delega limitata dalla capacità del validatore — e Snowtrace mostra uptime del validatore, capacità di delega e tassi di commissione.
L'uptime è il campo che conta: Avalanche richiede che un validatore soddisfi una soglia di uptime per guadagnare ricompense affatto. Un validatore sotto quella soglia non guadagna nulla, e nemmeno i suoi deleganti. Quello è un risultato binario piuttosto che graduale, il che lo rende utile da controllare prima di delegare.
Cosa hanno mostrato i nostri test di riferimento
I nostri test su Avalanche si sono concentrati sulla cosa che distingue questo explorer: il movimento tra le tre chain.
Sulla C-Chain gli elementi di riferimento EVM standard si sono comportati esattamente come atteso — lettura di contratto verificato, risoluzione di proxy, trasferimento ERC-20, una chiamata fallita con la sua ragione di revert. Nulla di sorprendente, il che è corretto per una chain compatibile con EVM.
Il test cross-chain era quello informativo. Abbiamo esportato una piccola quantità di AVAX dalla C-Chain e l'abbiamo importata sulla P-Chain, poi abbiamo provato a seguirla nel modo in cui lo farebbe un utente confuso: cercando l'hash della transazione di esportazione sulla destinazione.
Quello non ha restituito nulla, come atteso. L'esportazione e l'importazione sono transazioni separate con identificatori separati, e l'hash semplicemente non esiste sull'altra chain. Questa è precisamente la situazione che convince le persone che i loro fondi siano stati persi.
Snowtrace l'ha risolto. Cercare l'indirizzo sorgente sulla P-Chain ha mostrato l'importazione, e le due metà potevano essere abbinate per importo e timestamp. Non è elegante come il tracciatore di messaggi esplicito di Arbiscan, che collega entrambi i lati direttamente, ma è stato sufficiente per stabilire entro un minuto che nulla mancava.
I dati dei validatori della P-Chain hanno superato il controllo contro le cifre proprie pubblicate della rete, incluso l'uptime. Abbiamo deliberatamente guardato un validatore vicino alla soglia di uptime, e l'explorer ha mostrato la cifra abbastanza chiaramente da rendere ovvia la decisione di delega.
Il divario resta esplicativo. Ogni campo di cui avevamo bisogno era presente. Nulla sulla pagina dice a un nuovo utente che l'architettura a tre chain esista, motivo per cui arrivano confusi in primo luogo.