Trois chaînes, trois travaux
Le réseau principal d’Avalanche n’est pas une chaîne mais trois, chacune spécialisée.
La C-Chain est compatible EVM et c’est là que vit essentiellement toute l’activité applicative. Si vous avez utilisé Avalanche, vous avez utilisé la C-Chain. Elle se comporte comme n’importe quel autre réseau EVM — mêmes adresses, même outillage, mêmes contrats.
La X-Chain gère la création et le transfert d’actifs en utilisant un modèle plus proche de l’UTXO que des comptes. C’était la conception originale pour le transfert de valeur à haut débit.
La P-Chain coordonne les validateurs, le staking et la création de subnets. Si vous stakez de l’AVAX ou faites tourner un validateur, cela se passe ici.
La friction est que ces chaînes utilisent des formats d’adresse différents et des modèles de données différents, et déplacer des actifs entre elles est un transfert inter-chaînes explicite plutôt qu’une opération interne. Snowtrace est le seul explorateur qui vous permette de suivre ce mouvement — et vu combien de personnes ont été déroutées par des fonds « disparaissant » entre chaînes, cela seul lui vaut la recommandation.
Se déplacer entre C, X et P
Un actif sur la C-Chain n’est pas automatiquement disponible sur la P-Chain. Pour staker de l’AVAX, vous devez l’exporter depuis la C-Chain et l’importer vers la P-Chain, ce qui fait deux transactions sur deux chaînes avec deux identifiants différents.
Cela produit le schéma qui apparaît partout dans nos tests — les messages L1/L2 d’Arbitrum, les chaînes de messages de TON, le XCM de Polkadot. Une action devient plusieurs enregistrements et l’identifiant ne se transmet pas. Rechercher le hachage d’export sur la chaîne de destination ne trouve rien, et la conclusion raisonnable est que les fonds ont disparu.
Ils ne le sont pas. Ils sont dans l’import, en attente d’être complétés ou déjà complétés sous un hachage différent. Snowtrace montre les deux côtés, ce qui transforme une situation effrayante en une vérification de deux minutes.
La règle générale
Chaque fois qu’un système traverse des chaînes ou est asynchrone, une action utilisateur devient plusieurs enregistrements on-chain avec des identifiants différents. Avant de conclure que des fonds ont disparu, vérifiez si vous recherchez le bon identifiant sur la bonne chaîne. Dans notre expérience, cela explique l’écrasante majorité de ces cas.
Les subnets, et le problème d’explorateur qu’ils créent
Le pari architectural d’Avalanche, ce sont les subnets — des réseaux indépendants avec leurs propres validateurs, règles et, souvent, leurs propres machines virtuelles. Un subnet peut être autorisé, peut utiliser un token de gas personnalisé, et peut être ajusté pour une application spécifique.
Pour un explorateur, c’est un problème réel. Chaque subnet est effectivement une chaîne séparée nécessitant une indexation séparée, et il y en a beaucoup. Snowtrace, via le réseau plus large de Routescan, en couvre un nombre substantiel, mais la qualité varie et un petit subnet peut avoir un support minimal.
La C-Chain est là où se trouve l’outillage mature. Si vous travaillez sur un subnet, vérifiez quelle couverture d’explorateur existe avant de vous y fier — c’est la même prudence sur la qualité des instances qui s’applique aux déploiements Blockscout, et pour la même raison structurelle.
API et données de staking
Snowtrace expose des points d’accès compatibles Etherscan pour la C-Chain, ce qui signifie que le code EVM fonctionne généralement avec un changement d’URL de base. Nous les avons trouvés utilisables sans clé à faible volume, ce qui est de plus en plus inhabituel.
Les données de staking de la P-Chain sont l’offre la plus distinctive. Le staking Avalanche a des propriétés spécifiques — un stake minimum, une durée minimum, et une délégation limitée par la capacité du validateur — et Snowtrace met en avant l’uptime des validateurs, la capacité de délégation et les taux de frais.
L’uptime est le champ qui compte : Avalanche exige qu’un validateur atteigne un seuil d’uptime pour gagner des récompenses tout court. Un validateur en dessous ne gagne rien, et ses délégants non plus. C’est un résultat binaire plutôt que graduel, ce qui vaut la peine d’être vérifié avant de déléguer.
Ce que nos tests de référence ont montré
Nos tests Avalanche se sont concentrés sur ce qui distingue cet explorateur : le mouvement entre les trois chaînes.
Sur la C-Chain, les éléments de référence EVM standard se sont comportés exactement comme prévu — lecture de contrat vérifié, résolution de proxy, transfert ERC-20, un appel échoué avec sa raison de revert. Rien de surprenant, ce qui est correct pour une chaîne compatible EVM.
Le test inter-chaînes était l’informatif. Nous avons exporté un petit montant d’AVAX de la C-Chain et l’avons importé vers la P-Chain, puis avons essayé de le suivre de la façon dont le ferait un utilisateur dérouté : en recherchant le hachage de la transaction d’export sur la destination.
Cela n’a rien renvoyé, comme prévu. L’export et l’import sont des transactions séparées avec des identifiants séparés, et le hachage n’existe simplement pas sur l’autre chaîne. C’est précisément la situation qui convainc les gens que leurs fonds ont été perdus.
Snowtrace l’a résolu. Rechercher l’adresse source sur la P-Chain a montré l’import, et les deux moitiés ont pu être appariées par montant et horodatage. Ce n’est pas aussi élégant que le traceur de messages explicite d’Arbiscan, qui relie directement les deux côtés, mais c’était suffisant pour établir en une minute que rien ne manquait.
Les données de validateur P-Chain se sont vérifiées contre les propres chiffres publiés du réseau, uptime inclus. Nous avons délibérément regardé un validateur proche du seuil d’uptime, et l’explorateur a montré le chiffre assez clairement pour rendre la décision de délégation évidente.
La lacune reste explicative. Chaque champ dont nous avions besoin était présent. Rien sur la page ne dit à un nouvel utilisateur que l’architecture à trois chaînes existe, ce qui explique pourquoi il arrive dérouté en premier lieu.