You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: update indexer docs for Horizon-only operation (indexer-rs v2.0.0) (#1073)
* docs: update indexer docs for Horizon-only operation (indexer-rs v2.0.0)
Reflect that indexer-service-rs and indexer-tap-agent v2.0.0 require
Graph Horizon and no longer support legacy V1 TAP receipts. Simplify
the GraphTally configuration guide to show only required Horizon fields,
add the /healthz endpoint and receipt validation documentation, document
the v2.0.0 upgrade path, and update the indexing overview to reference
the Rust indexer components instead of the deprecated TypeScript stack.
* docs: apply inline code formatting for indexer-rs component names
Copy file name to clipboardExpand all lines: website/src/pages/en/graph-horizon/overview.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,7 @@ The **`SubgraphService`** is the first and currently only data service implement
41
41
42
42
### Integrated Payments Protocol
43
43
44
-
While the current protocol uses TAP (Timeline Aggregation Protocol) for payments, Horizon brings the payments infrastructure directly into the core protocol. The payments protocol in Horizon was designed as a generalized version of TAP v1, allowing integration with TAPv2 (GraphTally) but also any other arbitrary payment collection system.
44
+
Horizon brings the payments infrastructure directly into the core protocol. The payments protocol in Horizon was designed as a generalized framework, with [GraphTally](/indexing/tap) (formerly TAP) as the integrated payment collection system. This architecture also supports other arbitrary payment collection systems in the future.
Copy file name to clipboardExpand all lines: website/src/pages/en/graph-horizon/what-changes.mdx
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,10 +42,10 @@ Horizon does not change the way indexing rewards work, the rewards formula remai
42
42
43
43
### Serving queries and the gateway behavior
44
44
45
-
The indexer stack will support both the current and Horizon gateway infrastructure, which means with the same indexer stack version indexers will be able to serve queries before and after the Horizon upgrade. It’s worth clarifying however the gateway behavior:
45
+
The gateway now exclusively uses TAPv2 (GraphTally) receipts. Indexers must run `indexer-service-rs` and `indexer-tap-agent` v2.0.0 or later, which require Graph Horizon to be enabled.
46
46
47
-
-Before Horizon, the gateway will serve queries using TAPv1 receipts.
48
-
-After Horizon, the gateway will _only_ serve queries using TAPv2 (GraphTally) receipts. This means that indexers that have not upgraded their stack to Horizon will stop receiving queries. The gateway infrastructure will continue to accept old TAPv1 receipts and vouchers to ensure those can be redeemed and no fees are lost.
47
+
-The gateway only serves queries using TAPv2 (GraphTally) receipts. Indexers that have not upgraded their stack to Horizon will not receive queries.
48
+
-Starting with `indexer-service-rs` and `indexer-tap-agent` v2.0.0, legacy TAPv1 receipt support has been removed entirely. All receipt processing uses Horizon exclusively.
Copy file name to clipboardExpand all lines: website/src/pages/en/indexing/overview.mdx
+34-78Lines changed: 34 additions & 78 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ The minimum stake for an Indexer is currently set to 100K GRT.
17
17
18
18
### What are the revenue streams for an Indexer?
19
19
20
-
**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
20
+
**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via [GraphTally](/indexing/tap)between an Indexer and a gateway. Each query request from a gateway contains a signed receipt and the corresponding response a proof of query result validity.
21
21
22
22
**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing Subgraph deployments for the network.
23
23
@@ -127,13 +127,15 @@ Indexers may differentiate themselves by applying advanced techniques for making
127
127
128
128
At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a Subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
129
129
130
-
-**PostgreSQL database** - The main store for the Graph Node, this is where Subgraph data is stored. The Indexer serviceand agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
130
+
-**PostgreSQL database** - The main store for the Graph Node, this is where Subgraph data is stored. The Indexer service, TAP agent, and Indexer agent also use the database to store receipt data, cost models, indexing rules, and allocation actions.
131
131
132
132
-**Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain Subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
133
133
134
134
-**IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during Subgraph deployment to fetch the Subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.thegraph.com.
135
135
136
-
-**Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
136
+
-**Indexer service ([`indexer-service-rs`](https://github.com/graphprotocol/indexer-rs))** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages query payments via [GraphTally](/indexing/tap).
137
+
138
+
-**TAP agent ([`indexer-tap-agent`](https://github.com/graphprotocol/indexer-rs))** - Aggregates GraphTally receipts into RAVs (Receipt Aggregate Vouchers) and reconciles redemptions. Exactly one instance should run per indexer.
137
139
138
140
-**Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing Subgraph deployments to its Graph Node/s, and managing allocations.
139
141
@@ -155,12 +157,12 @@ Note: To support agile scaling, it is recommended that query and indexing concer
155
157
| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
368
+
To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of applications for facilitating an Indexers network participation. There are four Indexer components:
367
369
368
370
-**Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which Subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
369
371
370
-
-**Indexer service** - The only component that needs to be exposed externally, the service passes on Subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
372
+
-**[`indexer-service-rs`](https://github.com/graphprotocol/indexer-rs)** - The only component that needs to be exposed externally, the service passes on Subgraph queries to the graph node, validates [GraphTally](/indexing/tap) receipts, and shares important decision making information to clients like the gateways.
373
+
374
+
-**[`indexer-tap-agent`](https://github.com/graphprotocol/indexer-rs)** - Aggregates GraphTally receipts into RAVs and manages receipt-to-payment lifecycle. Run exactly one instance per indexer.
371
375
372
376
-**Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
373
377
374
378
#### Getting started
375
379
376
-
The Indexer agentand Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
380
+
The Indexer agent, `indexer-service-rs`, and `indexer-tap-agent`should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them using docker or via kubernetes on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
377
381
378
-
#### From NPM packages
382
+
#### Indexer agent (from NPM)
379
383
380
384
```sh
381
-
npm install -g @graphprotocol/indexer-service
382
385
npm install -g @graphprotocol/indexer-agent
383
386
384
387
# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
The `indexer-service-rs` and `indexer-tap-agent` are Rust applications distributed as Docker images. See the [GraphTally guide](/indexing/tap) for detailed configuration.
**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
422
+
**NOTE**: After starting the containers, the indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
453
423
454
424
#### Using K8s and Terraform
455
425
@@ -488,30 +458,16 @@ graph-indexer-agent start \
488
458
| pino-pretty
489
459
```
490
460
491
-
#### Indexer service
461
+
#### `indexer-service-rs` and `indexer-tap-agent`
462
+
463
+
Both `indexer-service-rs` and `indexer-tap-agent` are configured using a shared TOML file. See the [GraphTally guide](/indexing/tap) for detailed configuration and deployment instructions.
0 commit comments