Drei Chains, drei Aufgaben
Avalanches primäres Netzwerk ist keine einzelne Chain, sondern drei, jede spezialisiert.
Die C-Chain ist EVM-kompatibel und beherbergt im Wesentlichen die gesamte Anwendungsaktivität. Haben Sie Avalanche genutzt, haben Sie die C-Chain genutzt. Sie verhält sich wie jedes andere EVM-Netzwerk — gleiche Adressen, gleiches Tooling, gleiche Verträge.
Die X-Chain behandelt Asset-Erstellung und -Transfer mit einem Modell näher an UTXO als an Konten. Sie war der ursprüngliche Entwurf für hochdurchsatzfähigen Werttransfer.
Die P-Chain koordiniert Validatoren, Staking und Subnet-Erstellung. Staken Sie AVAX oder betreiben einen Validator, geschieht das hier.
Die Reibung entsteht, weil diese unterschiedliche Adressformate und Datenmodelle nutzen, und Assets zwischen ihnen zu bewegen ist ein expliziter netzwerkübergreifender Transfer, keine interne Operation. Snowtrace ist der einzige Explorer, der Ihnen erlaubt, diese Bewegung zu verfolgen — und angesichts dessen, wie viele Menschen von zwischen Chains „verschwindenden“ Geldern verwirrt waren, verdient allein das die Empfehlung.
Bewegung zwischen C, X und P
Ein Asset auf der C-Chain ist auf der P-Chain nicht automatisch verfügbar. Um AVAX zu staken, müssen Sie es von der C-Chain exportieren und in die P-Chain importieren — zwei Transaktionen auf zwei Chains mit zwei unterschiedlichen Kennungen.
Das erzeugt das Muster, das sich durch unsere Tests zieht — Arbitrums L1/L2-Nachrichten, TONs Nachrichtenketten, Polkadots XCM. Eine Aktion wird zu mehreren Datensätzen, und die Kennung überträgt sich nicht. Nach dem Export-Hash auf der Zielchain zu suchen findet nichts, und der naheliegende Schluss ist, die Gelder seien weg.
Sind sie nicht. Sie stehen im Import, wartend auf Abschluss oder bereits abgeschlossen unter einem anderen Hash. Snowtrace zeigt beide Seiten, was aus einer beängstigenden Situation eine Zwei-Minuten-Prüfung macht.
Die allgemeine Regel
Immer wenn ein System mehrere Chains umspannt oder asynchron ist, wird eine Nutzeraktion zu mehreren On-Chain-Datensätzen mit unterschiedlichen Kennungen. Bevor Sie schließen, Gelder seien verschwunden, prüfen Sie, ob Sie nach der richtigen Kennung auf der richtigen Chain suchen. Nach unserer Erfahrung erklärt das die überwältigende Mehrheit dieser Fälle.
Subnets, und das Explorer-Problem, das sie erzeugen
Avalanches architektonische Wette sind Subnets — unabhängige Netzwerke mit eigenen Validatoren, eigenen Regeln und oft eigenen virtuellen Maschinen. Ein Subnet kann berechtigungspflichtig sein, ein eigenes Gas-Token nutzen, und für eine bestimmte Anwendung abgestimmt sein.
Für einen Explorer ist das ein echtes Problem. Jedes Subnet ist faktisch eine separate Chain, die separate Indizierung braucht, und es gibt viele davon. Snowtrace deckt über Routescans breiteres Netzwerk eine erhebliche Anzahl ab, aber die Qualität schwankt, und ein kleines Subnet hat womöglich minimale Unterstützung.
Auf der C-Chain sitzt das ausgereifte Tooling. Arbeiten Sie an einem Subnet, prüfen Sie, welche Explorer-Abdeckung existiert, bevor Sie sich darauf verlassen — derselbe Vorbehalt zur Instanzqualität, der für Blockscout-Installationen gilt, aus demselben strukturellen Grund.
API und Staking-Daten
Snowtrace legt für die C-Chain Etherscan-kompatible Endpunkte offen, EVM-Code funktioniert also im Allgemeinen mit einer Änderung der Basis-URL. Wir fanden sie bei geringem Volumen ohne Schlüssel nutzbar, zunehmend ungewöhnlich.
Die P-Chain-Staking-Daten sind das eigenständigere Angebot. Avalanche-Staking hat besondere Eigenschaften — ein Mindeststake, eine Mindestdauer, und Delegation begrenzt durch Validator-Kapazität — und Snowtrace macht Validator-Uptime, Delegationskapazität und Gebührensätze sichtbar.
Uptime ist das entscheidende Feld: Avalanche verlangt von einem Validator, eine Uptime-Schwelle zu erreichen, um überhaupt Belohnungen zu verdienen. Ein Validator darunter verdient nichts, und ebenso seine Delegierenden. Das ist ein binäres Ergebnis, kein graduelles — es lohnt sich also, vor dem Delegieren zu prüfen.
Was unsere Referenztests zeigten
Unser Avalanche-Test konzentrierte sich auf das, was diesen Explorer auszeichnet: Bewegung zwischen den drei Chains.
Auf der C-Chain verhielten sich die Standard-EVM-Referenzobjekte genau wie erwartet — Lesen eines verifizierten Vertrags, Proxy-Auflösung, ERC-20-Transfer, ein fehlgeschlagener Aufruf mit Revert-Grund. Nichts Überraschendes, was für eine EVM-kompatible Chain korrekt ist.
Der netzwerkübergreifende Test war der aufschlussreiche. Wir exportierten einen kleinen AVAX-Betrag von der C-Chain und importierten ihn in die P-Chain, dann versuchten wir, ihm so zu folgen, wie es ein verwirrter Nutzer täte: indem wir nach dem Export-Transaktions-Hash auf dem Ziel suchten.
Das lieferte erwartungsgemäß nichts. Export und Import sind separate Transaktionen mit separaten Kennungen, und der Hash existiert auf der anderen Chain schlicht nicht. Genau diese Situation überzeugt Menschen davon, ihre Gelder seien verloren.
Snowtrace löste es auf. Die Suche nach der Quelladresse auf der P-Chain zeigte den Import, und beide Hälften ließen sich über Betrag und Zeitstempel zuordnen. Nicht so elegant wie Arbiscans expliziter Nachrichtentracker, der beide Seiten direkt verknüpft, aber ausreichend, um binnen einer Minute festzustellen, dass nichts fehlte.
Die P-Chain-Validatordaten stimmten mit den eigenen veröffentlichten Werten des Netzwerks überein, Uptime eingeschlossen. Wir betrachteten bewusst einen Validator nahe der Uptime-Schwelle, und der Explorer zeigte den Wert klar genug, um die Delegationsentscheidung offensichtlich zu machen.
Die Lücke bleibt die Erklärung. Jedes benötigte Feld war vorhanden. Nichts auf der Seite sagt neuen Nutzern, dass die Drei-Chain-Architektur existiert — weshalb sie überhaupt erst verwirrt ankommen.