Die Sicht des Analysten auf eine Blockchain

Jeder On-Chain-Befund beruht auf Daten, die jemand abgerufen, dekodiert und interpretiert hat. Ein Analyst, der nicht sagen kann, welcher Node die Daten erzeugt hat, welche Software sie dekodiert hat und wessen Bezeichnungen angewendet wurden, kann einen Befund nicht verteidigen, wenn ein Kollege, ein Prüfer oder ein Gericht fragt, wie er zustande kam. Diese Lektion zeigt, woher Blockchain-Daten stammen und was jede Ebene hinzufügt, damit du Quellen bewusst auswählst und deine Ergebnisse reproduzieren kannst.

Drei Ebenen von Blockchain-Daten

Blockchain-Daten bestehen aus drei Ebenen, die jeweils auf der darunterliegenden aufbauen.

Rohdaten des Nodes sind die Ground Truth: Jeder ehrliche Full Node, der derselben Chain folgt, gibt für denselben Block-Hash dieselben Bytes zurück. Dekodierte Daten sind nur so zuverlässig wie der Decoder: Eine aus einem Script abgeleitete Adresse oder ein aus einem Event abgeleiteter Token-Betrag hängt davon ab, ob der Decoder den Script-Typ oder das Interface des Vertrags (seine ABI) kennt. Angereicherte Daten bringen eine Bewertung hinzu: Preise stammen von einem ausgewählten Markt, Bezeichnungen von einer ausgewählten Quelle, Cluster von ausgewählten Heuristiken.

Je höher die Ebene, desto nützlicher sind die Daten und desto mehr Annahmen bringen sie mit sich. Eine Faustregel: Jeder Bericht muss sich bis zu den Rohdaten zurückverfolgen lassen, und jede auf dem Weg nach oben hinzugefügte Annahme muss dokumentiert werden.

Full Nodes, Archive Nodes und was sie beantworten können

Ein Full Node lädt jeden Block herunter und validiert ihn. Was er beantworten kann, hängt davon ab, was er speichert und indexiert.

• Bitcoin Core speichert alle Blöcke, sofern das Pruning nicht aktiviert ist, und gibt jeden Block anhand seines Hashes oder seiner Höhe zurück. Um eine beliebige bestätigte Transaktion anhand ihrer Txid nachzuschlagen, benötigt Bitcoin Core den optionalen Transaktionsindex (txindex=1); ohne ihn findet es nur Mempool-Transaktionen oder Transaktionen in einem von dir angegebenen Block. Bitcoin Core hat keinen Adressindex: Es kann nicht den Verlauf einer Adresse auflisten. Für Adressabfragen ist ein separater Indexer nötig (zu den Open-Source-Beispielen gehören Electrs, Fulcrum und Esplora).
• Ethereum-Ausführungsclients (Geth, Nethermind, Besu, Erigon, Reth) speichern Blöcke, Transaktionen und Receipts, aber ein standardmäßig eingerichteter Full Node speichert den State (Guthaben, Vertragsspeicher) nur für aktuelle Blöcke. Der standardmäßige pfadbasierte Speicher von Geth beispielsweise hält eine vollständige Kopie des States auf der Festplatte für den Block, der 128 Blöcke hinter dem Head liegt, sowie Änderungen im Arbeitsspeicher für neuere Blöcke. Daher kann er State-Abfragen nur für ungefähr die letzten 128 Blöcke beantworten. Eine Abfrage des Guthabens bei einem Block vom letzten Jahr schlägt bei einem solchen Node fehl. Ein Archive Node speichert den historischen State für jeden Block und wird für historische Guthabenabfragen, Vertragsaufrufe bei alten Blöcken und die meisten Traces alter Transaktionen benötigt.

Auch die Historie selbst schrumpft auf standardmäßig eingerichteten Nodes. Seit Juli 2025 unterstützen alle großen Ethereum-Ausführungsclients den teilweisen Ablauf der Historie gemäß EIP-4444: Ein Node kann Block-Bodies und Receipts aus der Zeit vor dem Merge (September 2022) löschen und dabei alle Header behalten. Ein entsprechend konfigurierter Node kann kein Receipt aus dem Jahr 2019 bereitstellen. Analysten, die frühe Historien benötigen, müssen einen Node verwenden, der sie speichert, oder ein veröffentlichtes Historienarchiv.

RPC-Anbieter und Indexer

Der Betrieb von Nodes kostet Speicherplatz, Zeit und Wartungsaufwand, deshalb nutzen die meisten Analysten eine von zwei Abkürzungen.

RPC-Anbieter betreiben Nodes und stellen die Standard-Schnittstellen (Bitcoin Core RPC, Ethereum JSON-RPC) über das Internet bereit. Das ist praktisch, aber du bist von ihrer Konfiguration (Full oder Archive, welcher Client, welche Methoden aktiviert sind), ihren Ratenlimits und ihren Fehlern abhängig. Die Lektion Node-APIs und Datenzugriff behandelt ihre Verwendung und Überprüfung.

Indexer lesen kontinuierlich Node-Daten und schreiben sie in eine für Abfragen geeignete Datenbank: eine Zeile pro Transaktion, Output, Log oder Trace. Manche indexieren alles (die ETL-Pipelines, die öffentliche Datensätze befüllen); andere indexieren ein einzelnes Protokoll (ein Subgraph, der einen einzelnen Kreditmarkt erfasst). Indexer beantworten Fragen, die ein Node nicht schnell beantworten kann, etwa „jedes Transfer-Event mit Beteiligung dieser Adresse über fünf Jahre“, bringen aber eine Abhängigkeit mit sich: ihre Dekodierungslogik, ihr Umgang mit Reorganisationen und die Aktualität ihrer Daten.

Block-Explorer im Vergleich zu Data Warehouses

Ein Block-Explorer ist ein Indexer mit einer Weboberfläche. Er eignet sich für einen ersten Überblick: bestätigen, dass eine Transaktion existiert, ihren Status überprüfen und ihre dekodierten Events lesen. Sich allein darauf zu verlassen, ist aus drei Gründen nicht ratsam. Seine Dekodierungs- und Kennzeichnungsmethoden sind selten so genau dokumentiert, wie es ein Bericht erfordert. Seine Ansichten ändern sich mit der Zeit, sodass eine in diesem Jahr hinzugefügte Bezeichnung bei Transaktionen aus früheren Jahren erscheint. Außerdem weichen Explorer bei abgeleiteten Kennzahlen voneinander ab, etwa bei „internen Transaktionen“, Token-Guthaben oder der für ein nicht standardmäßiges Script angezeigten Adresse.

Ein Data Warehouse (eine spaltenorientierte Datenbank mit indexierten Chain-Daten) eignet sich für Fragen zu vielen Transaktionen: Gesamtwerte, Zeitreihen, alle Gegenparteien eines Clusters. Die darin enthaltenen Tabellen sind nur so gut wie der ETL-Prozess, der sie befüllt hat. Deshalb werden Ergebnisse aus einem Warehouse anhand einer Stichprobe von Zeilen mit einem Node abgeglichen. Die Lektion Der Analytics-Datenstack vergleicht Warehouse-Optionen.

Ein zuverlässiger Arbeitsablauf kombiniert alle drei: einen Explorer zur Orientierung, ein Warehouse für die Arbeit in großem Umfang und einen Node zur Überprüfung der spezifischen Transaktionen, auf denen ein Befund beruht.

Durchgearbeitetes Beispiel: eine Frage, drei Antworten

Ein Analyst soll ermitteln, wie viel ETH die Adresse 0xA1b2…9F im März 2025 erhalten hat. Drei Quellen liefern drei Zahlen:

• Die Transaktionsliste eines Explorers ergibt insgesamt 41,20 ETH.
• Eine Warehouse-Abfrage der Tabelle transactions ergibt insgesamt 41,20 ETH.
• Eine Warehouse-Abfrage, die den über interne Aufrufe bewegten Wert aus der Tabelle traces hinzurechnet, ergibt insgesamt 53,70 ETH.

Keine der Quellen ist falsch. Die ersten beiden zählen nur Top-Level-Transaktionen, bei denen die Adresse im Feld to steht. Die zusätzlichen 12,50 ETH kamen über Vertragsaufrufe an, hier durch eine Abhebung von einer Smart-Contract-Wallet, und erscheinen nur in Traces. Eine vierte Antwort ergäbe sich, wenn Wrapped ETH (WETH) berücksichtigt würde: WETH ist ein Token und erscheint nur in Event-Logs. Eine unachtsam ermittelte fünfte Antwort würde den Wert aus fehlgeschlagenen Aufrufen mitzählen, die ebenfalls in Traces erfasst werden, obwohl dabei nichts übertragen wurde.

Es geht nicht darum, dass eine Zahl richtig ist. Die Frage muss anhand einer Datendefinition genau festgelegt werden: welche Ebene, welche Tabellen, welcher Blockbereich, welcher Vermögenswert. „53,70 ETH als nativer Wert in den Blöcken X bis Y erhalten, einschließlich erfolgreicher interner Transfers und ohne WETH“ ist eine Antwort, die ein anderer Analyst reproduzieren kann.

Reproduzierbarkeit als erste Pflicht des Analysten

Reproduzierbarkeit bedeutet, dass ein anderer kompetenter Analyst mit deinen Notizen dasselbe Ergebnis erzielt. Bei Blockchain-Daten ist dies ungewöhnlich gut möglich, weil die Rohdaten öffentlich sind und sich nach der Finalisierung nicht ändern. Was die Reproduzierbarkeit beeinträchtigt, ist alles, was sie umgibt:

• Veränderliche Bezugspunkte. „Latest“ ändert sich alle paar Sekunden. Verankere jede Abfrage an einer Blockhöhe und notiere den Hash dieses Blocks.
• Nicht dokumentierte Quellen. Notiere den Node oder Anbieter, den Client und seine Version sowie den Datensatz und die Tabellenversion.
• Nicht dokumentierte Transformationen. Bewahre die genaue Abfrage oder das Script einschließlich Filter und Einheitenumrechnungen auf.
• Veränderliche Bezeichnungen. Notiere die Quelle jeder Bezeichnung und das Datum, an dem du sie abgerufen hast; Bezeichnungen werden überarbeitet.
• Nicht finalisierte Daten. Aktuelle Blöcke können ersetzt werden; siehe die Lektion Blöcke und Header als Daten.

Betrachte diese Punkte als Gewohnheiten, nicht als Papierkram. Ein Befund, der auf „der Explorer hat es letzten Dienstag gesagt“ beruht, kann nicht überprüft werden; ein Befund, der auf einem benannten Block-Hash, einer gespeicherten Abfrage und einer dokumentierten Client-Version beruht, kann von jedem überprüft werden, der einen Node hat. Die Lektion Datenqualität, Normalisierung und Herkunftsnachweis macht aus diesen Punkten einen Herkunftsnachweis, den du jedem Datensatz beifügen kannst.

Prüfungsschwerpunkt: die drei Datenebenen (roh, dekodiert, angereichert oder gekennzeichnet) und die Annahmen, die jede Ebene hinzufügt; was ein Bitcoin Full Node beantworten kann, die Rolle von txindex und das Fehlen eines Adressindex; Ethereum Full Nodes im Vergleich zu Archive Nodes und weshalb historische States einen Archive Node erfordern; der teilweise Ablauf der Historie (EIP-4444) und Daten aus der Zeit vor dem Merge; Stärken und Schwächen von RPC-Anbietern, Indexern, Explorern und Data Warehouses; weshalb native, interne und Token-Transfers unterschiedliche Gesamtwerte ergeben; und das Verankern jeder Abfrage an einer Blockhöhe und einem Hash, um Reproduzierbarkeit zu gewährleisten.