Zum Inhalt springen
Financial Context Wiki

Block-Explorer

Prüfungsorientierter Leitfaden zu Block-Explorern, Nodes, Indexern, Belegen, Logs, Traces, Token-Metadaten, Proxys, Quellcodeverifizierung und Reorganisationen.

Aktualisiert

Nur zu Bildungszwecken; keine Finanz- oder Sicherheitsberatung. Explorer-Daten, Dekodierungen, Labels, Traces und Finalitätsanzeigen können unvollständig, verzögert oder falsch sein; prüfe wesentliche Handlungen anhand der vorgesehenen Chain und unabhängiger Node-Daten.

Direkte Antwort

Ein Block-Explorer ist eine Off-Chain-Oberfläche samt Indexer, die Node-Daten als durchsuchbare Seiten für Blöcke, Transaktionen, Adressen, Verträge, Token, Logs und teils Ausführungs-Traces aufbereitet. Er ist weder die Blockchain noch Konsensteilnehmer oder unabhängige Garantie. Jedes Ergebnis hängt von Chain, Node-Zustand, Indexierung, Decoder, Labels und Beobachtungszeit ab.

Trenne vier Evidenzebenen: Protokollobjekte wie Header, Transaktionen und Belege; RPC-Antworten eines Nodes; rekonstruierte Traces, Token-Transfers und Adressaggregate; sowie externe Namen, Risikohinweise, Fiatpreise und Verifizierungsabzeichen. Wesentliche Schlüsse sind mit vollständigen Kennungen, kanonischer Abstammung, Beleg oder UTXO-Zustand und einem unabhängigen Endpoint abzugleichen.

Funktionsweise

  1. Fixiere Explorer-Domain, Chain-ID beziehungsweise Bitcoin-Netzwerk, Beobachtungszeit und vollständige Kennung. Symbol, Name oder gekürzte Adresse beweisen keine Identität.
  2. Ordne jedes Feld Protokolldaten, aktueller RPC-Sicht, Indexer-Aggregat oder Trace, dekodierten Metadaten oder Drittanbieterinformationen zu.
  3. Prüfe pending oder inkludiert, Blockhash, Höhe, Elternkette, Bestätigungen beziehungsweise safe und finalized, Ersetzung und Reorganisation. Ein auffindbarer Hash beweist keine kanonische Inklusion.
  4. Prüfe bei EVM-Chains status, gasUsed, effectiveGasPrice, Logs und tatsächliche Änderungen. status = 1 besagt nur, dass die oberste Ausführung nicht revertiert wurde; status = 0 kann inkludiert sein und Gas verbrauchen.
  5. Prüfe Event-Signatur, Vertragsadresse, Topics, Daten, Dezimalstellen und ABI. Eine „interne Transaktion“ ist ein Call-Trace-Frame, keine separat signierte Protokolltransaktion; Trace-Abdeckung variiert.
  6. Prüfe Laufzeit-Bytecode, Quellcode, Proxy-Implementierung, Beacon oder Admin, Upgrade-Berechtigung und Speicherlayout. Verifizierter Quellcode ist weder Audit noch Emittentenbestätigung.
  7. Vergleiche mit unabhängigem Explorer oder direkter Node-Abfrage, speichere Rohantworten und Zeitstempel und gleiche nach erforderlicher Finalität erneut ab. Kläre veraltete Indizes, Pruning, Reorgs, RPC-Abweichungen, Spam, Proxy-Upgrades und externe Labeländerungen.

Durchgerechnete Beispiele

  • Gebühr. Ein Beleg meldet gasUsed = 52,000 und effectiveGasPrice = 18 gwei. Die Ausführungsgebühr beträgt 52,000 * 18 gwei = 936,000 gwei = 0.000936 ETH. Bei einem externen Kurs von $2,500/ETH sind das $2.34; der Dollarwert ist kein Konsensdatum.
  • Dezimalstellen. Ein Transfer-Log enthält 123,456,789, der verifizierte Vertrag decimals = 6. Angezeigt werden 123,456,789 / 10^6 = 123.456789 tokens. Die Annahme 18 ergäbe 0.000000000123456789; Vertragsidentität und Dezimalstellen gehören zusammen.
  • Trace. Eine signierte Transaktion sendet 1.00 ETH an A. Der Trace zeigt 0.72 ETH an B und 0.25 ETH zurück; A behält 1.00 - 0.72 - 0.25 = 0.03 ETH, vor dem Gas des Absenders. Das sind Call-Frames, keine drei signierten Transaktionen.
  • Reorg. Eine Transaktion in Block 20,000,000 bei Spitze 20,000,012 hat inklusive Tiefe 20,000,012 - 20,000,000 + 1 = 13. Entfernt ein Reorg den Block, verschwinden kanonischer Beleg und Logs. Zeigt der Explorer weiter 13 confirmations, ist sein Index veraltet.

Risiken

  • Falsche Chain, Testnet, Fork oder Explorer-Kopie.
  • Gekürzte, vergiftete oder ähnlich aussehende Adresse.
  • Tokenname oder -symbol als Vertragsidentität.
  • Auffindbaren pending Hash mit kanonischer Inklusion verwechseln.
  • Veraltetem, synchronisierendem oder isoliertem RPC-Backend vertrauen.
  • Höhen ohne Blockhashes und Abstammung vergleichen.
  • Ersetzung, Konflikt oder Reorganisation übersehen.
  • Belegerfolg mit wirtschaftlichem Erfolg gleichsetzen.
  • Gas einer inkludierten, revertierten Transaktion ignorieren.
  • Event-Logs als maßgeblichen Endzustand behandeln.
  • Log mit falscher ABI, Signatur oder Dezimalzahl dekodieren.
  • Trace-Frame als separat signierte Transaktion behandeln.
  • Vollständige, identische Traces aller Anbieter annehmen.
  • Lücken durch Archivierung, Pruning, Paginierung oder Limits.
  • Verifizierten Quellcode als Audit oder Emittentennachweis behandeln.
  • Eine Implementierung prüfen, aber mit anderem Proxy interagieren.
  • Proxy-, Beacon-, Admin- oder Upgrade-Änderungen übersehen.
  • Spam-Token, Labels oder Fiatpreise als Konsensdaten behandeln.
  • Explorer-Salden ohne UTXO- oder Speicherabgleich verwenden.
  • Bei Ausfall, Zensur oder Indexfehler von einem Explorer abhängen.

Häufige Irrtümer

  • Ein Block-Explorer ist die Blockchain oder validiert jede Anzeige unabhängig.
  • status = 1, grünes Abzeichen oder viele Bestätigungen beweisen das beabsichtigte wirtschaftliche Ergebnis.
  • Event-Logs und „interne Transaktionen“ sind Endzustand und separat signierte Transaktionen.
  • Verifizierter Quellcode beweist Audit, Echtheit, Unveränderlichkeit und Sicherheit.
  • Explorer-Salden, Labels, Tokenpreise und dekodierte Methoden sind bei allen Anbietern identische Konsensdaten.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...