Graph Node

A Graph Node is a server that ingests blockchain data, processes it according to a specified subgraph manifest, and serves queries via a GraphQL API. It continuously scans the blockchain for events defined in the subgraph, runs a mapping function written in AssemblyScript to transform this data into entities, and stores the resulting structured data in a PostgreSQL database for efficient querying. This process effectively creates a searchable, real-time index of on-chain information.

The node's architecture is modular, separating concerns into distinct components: the ingestion component syncs with blockchain nodes, the mapping component executes the transformation logic, and the query component handles incoming GraphQL requests. This design allows for horizontal scaling and high availability. Graph Nodes can be run by anyone, forming the decentralized backbone of the network where Indexers operate nodes to serve queries for a fee, while Curators signal on high-quality subgraphs to guide indexing resources.

From a developer's perspective, a Graph Node is the execution environment for their subgraph. After a developer deploys a subgraph definition, Graph Nodes pick it up, begin syncing historical data, and stay in sync with new blocks. This provides a reliable abstraction layer, allowing dApp frontends to query complex, aggregated blockchain data with simple GraphQL calls instead of processing raw event logs directly, drastically simplifying data access and improving application performance.

A Graph Node is a specialized server that performs the core indexing function for The Graph protocol. It operates by first ingesting raw event data from a blockchain, such as Ethereum, by connecting to an Ethereum node or other supported chain's RPC endpoint. The node then processes this data according to the logic defined in a subgraph manifest (subgraph.yaml), which maps specific smart contract events and function calls to a structured data schema. This processed data is stored in a PostgreSQL database for efficient querying, creating a searchable index of on-chain information.

The indexing process is continuous and stateful. The node monitors the blockchain for new blocks, filters them for events relevant to its assigned subgraphs, and executes the data transformation mappings written in AssemblyScript or other supported languages. These mappings translate low-level log data into the high-level entities defined in the GraphQL schema. This allows the node to maintain an always-updated, queryable representation of on-chain state, such as token balances, NFT ownership, or DeFi pool statistics, without requiring users to manually parse complex transaction logs.

Once indexed, the data is exposed via a GraphQL API endpoint. Developers and applications send GraphQL queries to the node to retrieve specific slices of the indexed data. For example, a dApp might query "all liquidity pools created by a specific address in the last week." The node's query engine efficiently resolves these requests against its optimized database, returning JSON results. In the decentralized network, Indexers operate Graph Nodes, staking GRT tokens to provide this service and earn query fees, while Delegators can stake GRT to Indexers to support the network's security and share in rewards.

A Graph Node is an open-source Rust-based server that performs the core indexing work for The Graph protocol. Its primary function is to ingest raw blockchain data from an Ethereum Virtual Machine (EVM) chain, process it through user-defined mappings written in AssemblyScript or Rust, and store the resulting structured data in a PostgreSQL database. This process transforms on-chain events and transactions into a queryable graph data model, enabling efficient API access. Each node operates independently, tracking specific subgraphs and updating its datastore as new blocks are added to the chain.

The node's architecture is defined by several key components. The subgraph manifest (subgraph.yaml) acts as the blueprint, specifying the smart contract addresses, the events to index, and the mapping logic. The mapping handlers contain the transformation code that translates blockchain data into the entities defined in the GraphQL schema. Internally, the node uses a blockchain client (like an Ethereum Geth or Erigon node) for data ingestion and a Postgres database with a time-travel query-enabled schema to store all entity states at every block height, allowing for historical queries.

For developers, interacting with a Graph Node typically means deploying a subgraph. The process involves compiling the subgraph definition using the Graph CLI, which generates necessary artifacts, and then using the CLI to create, deploy, and manage the subgraph on a node. Once deployed, the node begins syncing, processing blocks from the start block defined in the manifest. Indexers in the decentralized network run Graph Nodes to serve queries for their allocated subgraphs, while developers can also run a local node for testing using tools like Ganache or a local testnet.

The data model within a Graph Node is entity-centric. Each entity is a type defined in the GraphQL schema, representing an object like a User, Transaction, or Pool. Entities are stored as rows in PostgreSQL tables, with relationships between them established via ID fields. A critical feature is deterministic indexing: given the same blockchain data and subgraph code, any Graph Node will produce an identical data store. This ensures consistency across the network. The node also handles re-orgs by reverting entity states using its stored history, maintaining data integrity against blockchain reorganizations.

In the decentralized Graph Network, Graph Nodes are operated by Indexers, who stake GRT tokens to provide indexing and query processing services. These nodes expose a GraphQL endpoint over HTTP. When a query arrives, the node's query engine parses the GraphQL, resolves it against the indexed data in Postgres, and returns the JSON result. Performance is optimized through pagination, field-level filtering, and efficient database indexing on entity fields. For subgraphs with complex logic or high traffic, node operators may need to optimize their database performance and ensure sufficient resources for the block processing and query serving workloads.