Wer eine Blockchain-App nutzt, merkt schnell: Auf der Chain liegen zwar alle Transaktionen und Events, aber „einfach suchen“ wie in einer normalen Datenbank klappt nicht. Smart Contracts sind für Ausführung gebaut – nicht für komfortable Abfragen. Genau dieses Problem adressiert The Graph: Das Protokoll baut eine Index-Schicht, die Rohdaten aus Blockchains in strukturierte, effizient abfragbare Daten umwandelt.
Das ist besonders wichtig für dApps, die viele historische Daten brauchen, etwa DeFi-Dashboards, NFT-Marktplätze oder On-Chain-Analytics. Ohne Indexing müssten Apps entweder eigene Infrastruktur betreiben (Server, Datenbanken, Listener) oder stark eingeschränkte Abfragen anbieten. The Graph versucht, diese Arbeit als offenes Netzwerk bereitzustellen.
Warum Blockchain-Daten ohne Indexing schwer nutzbar sind
Was „On-Chain lesen“ praktisch bedeutet
Ein Node kann die Blockchain validieren und den aktuellen Zustand (State) bereithalten. Viele Fragen, die in Apps auftauchen, sind aber historisch oder zusammengesetzt: „Alle Trades eines Pools in den letzten 30 Tagen“, „NFTs, die eine Adresse jemals gemintet hat“, „Top-Liquidity-Provider pro Woche“. Solche Abfragen erfordern oft, dass Events über lange Zeit gesammelt, gefiltert und in ein eigenes Datenmodell gebracht werden.
Ohne zusätzliche Schicht bleibt nur: Logs/Events Block für Block scannen, lokal speichern und dann in einer klassischen Datenbank abfragen. Das ist machbar, aber teuer und wartungsintensiv – und führt in der Praxis häufig zu zentralen Backends, obwohl die eigentliche Anwendung „dezentral“ wirken soll.
Indexing als fehlendes Bindeglied zwischen Chain und App
Indexing bedeutet: Daten werden aus einer Quelle kontinuierlich extrahiert, aufbereitet und so organisiert, dass Abfragen schnell und reproduzierbar werden. In Web3 ist die Quelle eine Blockchain; die Aufbereitung basiert oft auf Contract-Events (z. B. „Swap“, „Transfer“, „Mint“). The Graph standardisiert diesen Prozess für Entwicklerteams.
Wie The Graph aufgebaut ist: Rollen, Anreize, Datenfluss
Subgraphs als „Daten-API“ für dApps
Das Herzstück sind Subgraphs: definierte Indexing-Projekte, die beschreiben, welche Smart-Contract-Events und Zustandsdaten erfasst werden und wie daraus Entitäten (z. B. „Pool“, „Trade“, „UserPosition“) entstehen. Ein Subgraph enthält im Kern:
- Welche Datenquellen (Contracts/Adressen) überwacht werden
- Welche Events und Aufrufe relevant sind
- Mapping-Logik, die Rohdaten in ein eigenes Schema überführt
- Ein Schema (Typen/Entitäten), das die spätere Abfrage bestimmt
Für App-Teams fühlt sich das am Ende wie eine API an: Statt Blöcke zu scannen, können sie strukturierte Abfragen stellen und bekommen genau die Daten, die das Frontend braucht.
Indexers, Curators und Delegators – wer macht was?
Im dezentralen Netzwerk übernehmen verschiedene Rollen Aufgaben und Risiko:
- Indexer betreiben Infrastruktur, indexieren Subgraphs und beantworten Anfragen. Dafür müssen sie Ressourcen bereitstellen und in der Regel Sicherheiten hinterlegen.
- Curators signalisieren, welche Subgraphs aus ihrer Sicht hochwertig und nachgefragt sind. Dieses Signal soll helfen, dass Indexer ihre Kapazitäten sinnvoll einsetzen.
- Delegators können Indexer unterstützen, ohne selbst Infrastruktur zu betreiben. Das stärkt die wirtschaftliche Basis für Indexer und verteilt das Risiko.
Diese Rollen sind ein Versuch, ein offenes Ökosystem zu schaffen: nicht „eine Firma betreibt den Index“, sondern viele Akteure betreiben ihn und werden über Anreize koordiniert.
Abfragen über GraphQL – warum das im Web3-Kontext praktisch ist
Viele Subgraphs werden über GraphQL abgefragt. Das ist eine Abfragesprache, bei der der Client sehr genau angeben kann, welche Felder benötigt werden. Für dApps ist das hilfreich, weil Frontends oft exakt zugeschnittene Daten brauchen (z. B. nur die letzten 20 Trades, sortiert nach Timestamp, mit ausgewählten Feldern).
Wichtig: The Graph „verändert“ keine Blockchain-Daten. Es baut eine abfragbare Projektion (eine Art Sicht) auf Basis von On-Chain-Informationen. Die Qualität hängt also davon ab, ob Subgraph-Definition und Indexing korrekt implementiert sind.
Was in einem Subgraph technisch passiert
Von Contract-Events zu Entitäten
Ein typischer Ablauf sieht so aus: Ein Smart Contract emittiert Events (Log-Einträge). Der Subgraph lauscht auf diese Events und führt Mapping-Code aus, der Entitäten aktualisiert. Beispiel: Ein „Swap“-Event erzeugt eine neue Trade-Entität und aktualisiert gleichzeitig Aggregationen wie Tagesvolumen oder den letzten Preis.
Dieses Vorgehen ähnelt Event-Sourcing aus der klassischen Softwareentwicklung: Ereignisse sind der Ausgangspunkt, und der „abgeleitete Zustand“ wird in einem für Abfragen optimierten Modell gespeichert.
Reorgs und Finalität: Was passiert, wenn Blöcke umgeschrieben werden?
Blockchains können kurzfristig Reorgs (Neuorganisationen) haben: Ein Block wird verworfen, ein anderer setzt sich durch. Indexing-Systeme müssen darauf reagieren, sonst würden sie falsche Daten liefern. Deshalb muss ein Indexer in der Lage sein, Indexing-Schritte rückgängig zu machen und den abgeleiteten Zustand konsistent mit der letztlich gültigen Chain zu halten.
Für Nutzer:innen heißt das: Sehr „frische“ Daten können sich noch ändern – je nach Chain und Finalitätsmodell. Viele Apps berücksichtigen das, indem sie für kritische Informationen einige Bestätigungen abwarten.
Datenmodell-Design: Warum ein gutes Schema entscheidend ist
Die Leistungsfähigkeit eines Subgraphs hängt stark am Schema: Welche Entitäten gibt es, wie sind sie verknüpft, welche Felder sind filter- und sortierbar? Ein zu grobes Modell erschwert Abfragen, ein zu feines Modell kann Indexing verlangsamen oder komplex machen. Gute Subgraphs wählen Entitäten so, dass typische UI-Fragen schnell beantwortet werden können (z. B. „Positionen pro Wallet“, „Historie pro Pool“, „Aggregationen pro Zeitfenster“).
Praktische Nutzung: So kommen Apps und Nutzer an The-Graph-Daten
Wann sich eine Index-Schicht lohnt
Indexing lohnt sich besonders, wenn eine Anwendung:
- viele historische Daten anzeigen muss (Charts, Historien, Rankings)
- komplexe Filter braucht (z. B. nach Token, Zeitraum, Wallet)
- mehrere Contracts logisch zusammenführt (z. B. Multi-Pool-Daten)
- nicht von einem einzelnen Backend abhängig sein möchte
Bei sehr einfachen Apps (nur „aktueller Kontostand“, „Allowance prüfen“) reicht oft ein direkter RPC-Aufruf an einen Node. Sobald aber UI und Datenlogik wachsen, wird Indexing fast unvermeidlich.
Kleine „So geht’s“-Box für Teams, die Daten sauber abfragen wollen
- Vor der Integration prüfen, ob ein passender Subgraph existiert und ob das Schema die benötigten Felder bietet.
- Abfragen klein halten: nur Felder anfordern, die wirklich gebraucht werden (GraphQL ist dafür gemacht).
- Mit Pagination arbeiten (z. B. „erste 100 Einträge“, dann weiterblättern), statt riesige Resultsets zu laden.
- Bei kritischen Anzeigen Reorg-Toleranz einplanen (z. B. „letzte Aktualisierung“ anzeigen oder mit Bestätigungen arbeiten).
- Fallbacks definieren: Wenn Indexing verzögert ist, können Kernwerte notfalls direkt on-chain abgefragt werden.
Einordnung im Web3-Stack: Abgrenzung zu Oracles, Nodes und Data Availability
Indexing ist kein Oracle
Oracles liefern externe Daten in Smart Contracts (z. B. Preisfeeds). Indexing dagegen macht On-Chain-Daten für Leseseiten (Frontends, Analysen) zugänglich. Wer den Unterschied vertiefen will: Chainlink Oracles und ihre Rolle für Smart Contracts behandelt den Oracle-Teil, während The Graph beim „Lesen und Strukturieren“ ansetzt.
Indexing ersetzt keine eigene Node-Infrastruktur – es ergänzt sie
Eine Node (RPC) ist die direkte Schnittstelle zur Blockchain. Indexing baut darauf auf, indem es Daten aus Nodes bezieht und für Abfragen optimiert. Viele Teams nutzen beides: RPC für transaktionsnahe Checks und The Graph für Historien, Listen und komplexe Aggregationen.
Modulare Blockchains: Warum Indexing in Zukunft noch wichtiger werden kann
Mit modularen Architekturen trennen sich Aufgaben wie Ausführung, Konsens und Datenverfügbarkeit. Wer sich damit beschäftigt, stößt schnell auf die Frage: Wie werden Daten aus mehreren Schichten zusammenhängend nutzbar gemacht? Ein Einstieg dazu findet sich bei Celestia und Datenverfügbarkeit. Indexing-Protokolle sind dabei ein Baustein, um aus verteilten Rohdaten wieder „produktreife“ Antworten für Apps zu formen.
Stärken und Grenzen: Worauf bei Vertrauen und Performance zu achten ist
Was The Graph gut löst
| Aspekt | Nutzen in der Praxis |
|---|---|
| Schnelle Abfragen | UI-Listen, Historien und Dashboards werden performant, ohne eigenes Backend zu bauen. |
| Strukturierte Datenmodelle | Entitäten und Beziehungen erlauben verständliche Queries statt Block-Scanning. |
| Ökosystem-Standardisierung | Viele Projekte orientieren sich an ähnlichen Mustern (Events → Entitäten → Query). |
Welche Risiken und Trade-offs es gibt
Indexing bleibt eine zusätzliche Schicht, die korrekt betrieben werden muss. Typische Stolpersteine:
- Daten-Korrektheit: Wenn Mapping-Logik fehlerhaft ist, kann der Subgraph falsche oder unvollständige Daten liefern.
- Aktualität: Je nach Indexer und Chain können Daten verzögert sein, etwa bei hoher Last.
- Abhängigkeit vom Schema: Wenn das Schema nicht passt, sind bestimmte Fragen nicht möglich, ohne den Subgraph anzupassen.
- Vertrauensmodell: Nutzer müssen verstehen, ob eine Anzeige aus der Index-Schicht stammt oder direkt on-chain verifiziert wurde.
Für sensible Anzeigen (z. B. „wie viel kann wirklich ausgezahlt werden?“) ist es sinnvoll, Kernwerte zusätzlich direkt on-chain zu prüfen. Für explorative Daten (Charts, Ranglisten, Historien) ist Indexing meist der richtige Weg.
Wie sich The Graph in DeFi- und Cross-Chain-Apps einfügt
DeFi: Viele Events, viel Historie, viele Abfragen
DeFi-Protokolle erzeugen eine große Menge Events. Gleichzeitig wollen Nutzer:innen Liquidität, Gebühren, Positionen, Historien und Kennzahlen sehen. Indexing ist hier fast Grundausstattung. Wer DeFi-Komponenten im Detail nachlesen möchte: Uniswap und AMM-Logik zeigt, warum gerade AMMs so viele abfragerelevante Ereignisse produzieren.
Cross-Chain: Daten werden nur dann „verständlich“, wenn sie zusammengeführt werden
Bei Interoperabilität entstehen Datenströme über mehrere Chains hinweg (Bridges, Messaging, Zustellnachweise). Für UIs ist entscheidend, diese Informationen konsistent zu aggregieren. In diesem Kontext ist Indexing eine Art „Übersetzer“ zwischen technischen Nachrichtenflüssen und dem, was Apps anzeigen müssen. Passend dazu: Wormhole und Cross-Chain-Messaging liefert Hintergrund, warum Cross-Chain-Daten oft nicht an einem Ort liegen.
Typische Fragen aus der Praxis – kurz beantwortet
Kann man The-Graph-Daten selbst verifizieren?
Einzelne Werte lassen sich grundsätzlich gegen die Blockchain prüfen, indem Events und Zustandsdaten direkt nachrecherchiert werden. In der Praxis verifizieren Apps kritische Werte häufig per RPC und nutzen Indexing für alles, was historisch oder aggregiert ist.
Ist ein Subgraph nur für ein Protokoll gedacht?
Meist ja, weil die Datenquellen und das Schema stark von den jeweiligen Contracts abhängen. Es gibt aber auch Subgraphs, die allgemeine Standards (z. B. Token-Transfers) abbilden oder mehrere Komponenten eines Ökosystems kombinieren.
Warum nicht einfach eine zentrale Datenbank nutzen?
Zentral geht oft schneller – bringt aber neue Abhängigkeiten (Ausfall, Zensur, Vertrauensfrage). The Graph versucht, Indexing als offene Infrastruktur zu organisieren. Teams können trotzdem hybride Ansätze wählen: zentrale Caches für Performance, aber Datenherkunft und kritische Checks bleiben transparent.
Welche Rolle spielt der Token im Netzwerk?
Der Token GRT ist in das Anreiz- und Sicherheitsmodell eingebunden, etwa für Beteiligung, Signalgebung und wirtschaftliche Koordination der Indexing-Rollen. Für das technische Verständnis ist vor allem wichtig: Der Token soll helfen, dass Ressourcen (Indexing, Query-Serving) dort entstehen, wo Nachfrage besteht, und dass Fehlverhalten wirtschaftliche Folgen haben kann.
