The Graph Network > Indicizzazione

Indicizzazione

Reading time: 27 min

Gli Indexer sono operatori di nodi di The Graph Network che fanno staking di Graph Token (GRT) per fornire servizi di indicizzazione e di elaborazione delle query. Gli Indexer guadagnano tariffe di query e ricompense di indicizzazione per i loro servizi. Guadagnano anche tariffe di query che vengono rimborsate in base a una funzione di rimborso esponenziale.

Il GRT che viene fatto staking nel protocollo è soggetto a un periodo di scongelamento e può essere ridotto se gli Indexer sono malintenzionati e servono dati errati alle applicazioni o se indicizzano in modo errato. Gli Indexer guadagnano anche ricompense per le stake delegate dai Delegator, per contribuire alla rete.

Gli Indexer selezionano i subgraph da indicizzare in base al segnale di curation del subgraph, dove i Curator fanno staking di GRT per indicare quali subgraph sono di alta qualità e dovrebbero essere prioritari. I consumatori (ad esempio, le applicazioni) possono anche impostare i parametri per cui gli Indexer elaborano le query per i loro subgraph e stabilire le preferenze per le tariffe di query.

Livello tecnico richiesto

ADVANCED

FAQ

Collegamento a questa sezione

Qual è lo stake minimo richiesto per essere un Indexer sulla rete?

Collegamento a questa sezione

Lo stake minimo per un Indexer è attualmente fissato a 100K GRT.

Quali sono le fonti di guadagno di un Indexer?

Collegamento a questa sezione

Sconti sulle tariffe di query - Pagamenti per servire le query sulla rete. Questi pagamenti sono mediati da canali di stato tra un Indexer e un gateway. Ogni richiesta di query da parte di un gateway contiene un pagamento e la risposta corrispondente una prova della validità del risultato della query.

Ricompense di indicizzazione - Generate tramite un'inflazione annuale del 3% a livello di protocollo, le ricompense di indicizzazione sono distribuite agli Indexer che indicizzano le distribuzioni di subgraph per la rete.

Come vengono distribuite le ricompense di indicizzazione?

Collegamento a questa sezione

Le ricompense di indicizzazione provengono dall'inflazione del protocollo, impostata al 3% di emissione annuale. Vengono distribuite tra i subgraph in base alla proporzione di tutti i segnali di curation su ciascuno di essi, quindi distribuite proporzionalmente agli Indexer in base allo stake di partecipazione assegnato a quel subgraph. Un'allocation deve essere chiusa con una prova valida di indicizzazione (POI) che soddisfi gli standard stabiliti dalla carta dell'arbitrato per poter beneficiare delle ricompense.

Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the Community Guides collection. You can also find an up to date list of tools in the #Delegators and #Indexers channels on the Discord server. Here we link a recommended allocation optimiser integrated with the indexer software stack.

Che cos'è una prova di indicizzazione (POI)?

Collegamento a questa sezione

I POI sono utilizzati nella rete per verificare che un Indexer stia indicizzando i subgraph su cui ha effettuato l'allocazione. Un POI per il primo blocco dell'epoca corrente deve essere presentato alla chiusura di un'allocazione affinché questa possa beneficiare delle ricompense di indicizzazione. Un POI per un blocco è un insieme di tutte le transazioni dell'entity store per una specifica distribuzione di subgraph fino a quel blocco incluso.

Quando vengono distribuite le ricompense di indicizzazione?

Collegamento a questa sezione

Le allocazioni accumulano continuamente ricompense mentre sono attive e vengono allocate entro 28 epoche. Le ricompense vengono raccolte dagli Indexer e distribuite quando le loro allocazioni vengono chiuse. Ciò avviene manualmente, ogni volta che l'Indexer vuole chiuderle forzatamente, oppure dopo 28 epoche un Delegator può chiudere l'allocazione per l'Indexer, ma questo non comporta ricompense. 28 epoche è la durata massima dell'allocazione (al momento, un'epoca dura circa 24 ore).

È possibile monitorare le ricompense di indicizzazione in sospeso?

Collegamento a questa sezione

The RewardsManager contract has a read-only getRewards function that can be used to check the pending rewards for a specific allocation.

Molte delle dashboard create dalla comunità includono i valori delle ricompense in sospeso, che possono essere facilmente controllate manualmente seguendo questi passaggi:

  1. Fare query su mainnet subgraph per ottenere gli ID di tutte le allocazioni attive:
query indexerAllocations {
indexer(id: "<INDEXER_ADDRESS>") {
allocations {
activeForIndexer {
allocations {
id
}
}
}
}
}

Utilizzare Etherscan per chiamare getRewards():

  • Andare su Etherscan interface to Rewards contract
  • Per chiamare getRewards():
    • Expand the 9. getRewards dropdown.
    • Inserire l'allocationID nell'input.
    • Fare clic sul pulsante Query.

Cosa sono le controversie e dove posso vederle?

Collegamento a questa sezione

Le query e le allocazioni dell'Indexer possono essere contestate su The Graph durante il periodo di contestazione. Il periodo di contestazione varia a seconda del tipo di contestazione. Le query/attestazioni hanno una finestra di contestazione di 7 epoche, mentre le allocazioni 56 epoche. Una volta trascorsi questi periodi, non è più possibile aprire controversie né contro le allocation né contro le query. Quando viene aperta una controversia, i Fisherman devono versare un deposito minimo di 10.000 GRT, che rimarrà bloccato fino a quando la controversia non sarà conclusa e sarà stata data una risoluzione. I Fisherman sono tutti i partecipanti alla rete che aprono controversie.

Le controversie hanno tre esiti possibili, così come il deposito dei Fishermen.

  • Se la controversia viene respinta, il GRT depositato dai Fishermen verrà bruciato e l'Indexer contestato non verrà tagliato.
  • Se la controversia viene risolta con un pareggio, il deposito dei Fishermen verrà restituito e l'Indexer contestato non verrà tagliato.
  • Se la controversia viene accettata, il GRT depositato dai Fishermen verrà restituito, l'Indexer contestato verrà tagliato e i Fishermen guadagneranno il 50% dei GRT tagliati.

Le controversie possono essere visualizzate nell'interfaccia utente nella pagina del profilo di un Indexer, sotto la scheda Disputes.

Cosa sono gli sconti sulle tariffe di query e quando vengono distribuiti?

Collegamento a questa sezione

Le tariffe di query sono raccolte dal gateway e distribuite agli Indexer in base alla funzione di sconto esponenziale (vedi GIP qui). La funzione di sconto esponenziale è proposta come un modo per garantire che gli Indexer ottengano il miglior risultato servendo fedelmente le query. Funziona incentivando gli Indexer ad allocare una grande quantità di stake (che può essere tagliato in caso di errore quando si serve una query) rispetto all'ammontare delle tariffe di query che possono raccogliere.

Una volta chiusa un'allocation, gli sconti possono essere richiesti dall'Indexer. Al momento della richiesta, gli sconti sulle tariffe di query vengono distribuiti all'Indexer e ai suoi Delegator in base alla riduzione delle tariffe di query e alla funzione di sconto esponenziale.

Che cos'è la query fee cut e la indexing reward cut?

Collegamento a questa sezione

I valori di queryFeeCut e indexingRewardCut sono parametri di delega che l'Indexer può impostare insieme ai cooldownBlocks per controllare la distribuzione dei GRT tra l'Indexer i suoi Delegator. Per le istruzioni sull'impostazione dei parametri di delega, si vedano gli ultimi passi di Staking nel Protocollo.

  • queryFeeCut - la % delle riduzioni delle tariffe di query che verrà distribuita all'Indexer. Se questa opzione è impostata al 95%, l'Indexer riceverà il 95% delle tariffe di query guadagnate alla chiusura di un'allocazione, mentre il restante 5% andrà ai Delegator.

  • indexingRewardCut - la % delle ricompense di indicizzazione che verrà distribuita all'Indexer. Se è impostata al 95%, l'Indexer riceverà il 95% delle ricompense di indicizzazione quando viene chiusa un'allocazione e i Delegator si divideranno il restante 5%.

Come fanno gli Indexer a sapere quali subgraph indicizzare?

Collegamento a questa sezione

Gli Indexer possono differenziarsi applicando tecniche avanzate per prendere decisioni sull'indicizzazione dei subgraph, ma per dare un'idea generale discuteremo diverse metriche chiave utilizzate per valutare i subgraph nella rete:

  • Segnale di curation - La percentuale del segnale di curation della rete applicato a un particolare subgraph è un buon indicatore dell'interesse per quel subgraph, soprattutto durante la fase di bootstrap, quando il volume delle query è in aumento.

  • Tariffe di query raccolte - I dati storici relativi al volume delle tariffe di query raccolte per uno specifico subgraph sono un buon indicatore della domanda futura.

  • Importo sullo staking - Il monitoraggio del comportamento degli altri Indexer o l'esame delle proporzioni dello stake totale allocato a specifici subgraph può consentire a un Indexer di monitorare il lato dell'offerta per le query sui subgraph, per identificare i subgraph in cui la rete mostra fiducia o i subgraph che potrebbero avere bisogno di maggiore offerta.

  • Subgraph senza ricompense di indicizzazione - Alcuni subgraph non generano ricompense per l'indicizzazione principalmente perché utilizzano funzioni non supportate come IPFS o perché stanno facendo query su un'altra rete al di fuori della mainnet. Se un subgraph non genera ricompense di indicizzazione, viene visualizzato un messaggio.

Quali sono i requisiti hardware?

Collegamento a questa sezione
  • Piccolo - Sufficiente per iniziare a indicizzare diversi subgraph, probabilmente dovrà essere ampliato.
  • Standard - Impostazione predefinita, è quella usata nei manifesti di distribuzione di esempio di k8s/terraform.
  • Medio - Indexer di produzione che supporta 100 subgraph e 200-500 richieste al secondo.
  • Grande - È pronto a indicizzare tutti i subgraph attualmente utilizzati e a servire le richieste per il relativo traffico.
SetupPostgres
(CPUs)
Postgres
(memoria in GBs)
Postgres
(disco in TBs)
VMs
(CPUs)
VMs
(memoria in GBs)
Piccolo481416
Standard83011248
Medio166423264
Grande724683.548184

Quali sono le precauzioni di base per la sicurezza che un Indexer dovrebbe adottare?

Collegamento a questa sezione
  • Operator wallet - La creazione di un operator wallet è una precauzione importante perché consente all'Indexer di mantenere una separazione tra le chiavi che controllano il stake e quelle che controllano le operazioni quotidiane. VedereStake al protocollo per le istruzioni.

  • Firewall - Solo l'Indexer service deve essere esposto pubblicamente e occorre prestare particolare attenzione a bloccare le porte di amministrazione e l'accesso al database: l'endpoint JSON-RPC di the Graph Node (porta predefinita: 8030), l'endpoint API di gestione dell'Indexer (porta predefinita: 18000) e l'endpoint del database Postgres (porta predefinita: 5432) non devono essere esposti.

Al centro dell'infrastruttura di un Indexer c'è the Graph Node, che monitora le reti indicizzate, estrae e carica i dati secondo una definizione di subgraph e li serve come GraphQL API. The Graph Node deve essere collegato a un endpoint che espone i dati di ciascuna rete indicizzata, a un nodo IPFS per l'approvvigionamento dei dati, a un database PostgreSQL per il suo archivio e a componenti dell'Indexer che facilitano le interazioni con la rete.

  • Database PostgreSQL - È l'archivio principale del The Graph Node, dove vengono memorizzati i dati dei subgraph. Anche l'Indexer Service e l'Indexer Agent utilizzano il database per memorizzare i dati del canale di stato, i modelli di costo, le regole di indicizzazione e le azioni di allocation.

  • Endpoint dei dati - Per le reti compatibili con EVM, il Graph Node deve essere collegato a un endpoint che esponga un'API JSON-RPC compatibile con EVM. Questo può assumere la forma di un singolo client o può essere una configurazione più complessa che bilancia il carico su più client. È importante sapere che alcuni subgraph richiedono particolari funzionalità del client, come la modalità di archiviazione e/o l'API di tracciamento della parità.

  • Nodo IPFS (versione inferiore a 5) - I metadati di distribuzione del subgraph sono memorizzati sulla rete IPFS. Il Graph Node accede principalmente al nodo IPFS durante la distribuzione del subgraph per recuperare il manifest del subgraph e tutti i file collegati. Gli Indexer di rete non hanno bisogno di ospitare il proprio nodo IPFS; un nodo IPFS per la rete è ospitato all'indirizzo https://ipfs.network.thegraph.com.

  • Indexer service - Gestisce tutte le comunicazioni esterne necessarie con la rete. Condivide i modelli di costo e gli stati di indicizzazione, passa le richieste di query dai gateway a un Graph Node e gestisce i pagamenti delle query tramite canali di stato con il gateway.

  • Indexer agent - Facilita le interazioni degli Indexer sulla chain, compresa la registrazione sulla rete, la gestione delle distribuzioni di subgraph ai Graph Node e la gestione delle allocazioni.

  • Server di metriche Prometheus - I componenti Graph Node e Indexer registrano le loro metriche sul server delle metriche.

Nota: Per supportare una scalabilità agile, si consiglia di separare le attività di query e indicizzazione tra diversi gruppi di nodi: nodi di query e nodi di indicizzazione.

Panoramica delle porte

Collegamento a questa sezione

Importante: Fate attenzione a esporre pubblicamente le porte - le porte di amministrazione devono essere sempre bloccate. Questo include gli endpoint JSON-RPC del Graph Node e quelli di gestione dell'Indexer, descritti di seguito.

PortaObiettivoRoutesArgomento CLIVariabile d'ambiente
8000GraphQL HTTP server
(per le query di subgraph)
/subgraphs/id/...
/subgraphs/name/.../...
--http-port-
8001GraphQL WS
(per le sottoscrizioni ai subgraph)
/subgraphs/id/...
/subgraphs/name/.../...
--ws-port-
8020JSON-RPC
(per la gestione dei deployment)
/--admin-port-
8030Subgraph indexing status API/graphql--index-node-port-
8040Metriche di Prometheus/metrics--metrics-port-
PortaObiettivoRoutesArgomento CLIVariabile d'ambiente
7600GraphQL HTTP server
(per le query di subgraph a pagamento)
/subgraphs/id/...
/status
/channel-messages-inbox
--portINDEXER_SERVICE_PORT
7300Metriche di Prometheus/metrics--metrics-port-
PortaObiettivoRoutesArgomento CLIVariabile d'ambiente
8000API di gestione degli Indexer/--indexer-management-portINDEXER_AGENT_INDEXER_MANAGEMENT_PORT

Configurare l'infrastruttura server utilizzando Terraform su Google Cloud

Collegamento a questa sezione

Nota: gli Indexer possono utilizzare in alternativa AWS, Microsoft Azure o Alibaba.

Installare i prerequisiti

Collegamento a questa sezione
  • Google Cloud SDK
  • Kubectl command line tool
  • Terraform

Creare un progetto Google Cloud

Collegamento a questa sezione
  • Clone or navigate to the Indexer repository.

  • Navigate to the ./terraform directory, this is where all commands should be executed.

cd terraform
  • Autenticare con Google Cloud e creare un nuovo progetto.
gcloud auth login
project=<PROJECT_NAME>
gcloud projects create --enable-cloud-apis $project
  • Utilizzare la pagina di fatturazione di Google Cloud Console per abilitare la fatturazione del nuovo progetto.

  • Creare una configurazione di Google Cloud.

proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
gcloud config configurations create $project
gcloud config set project "$proj_id"
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a
  • Abilitare le API di Google Cloud necessarie.
gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com
gcloud services enable servicenetworking.googleapis.com
gcloud services enable sqladmin.googleapis.com
  • Creare un account di servizio.
svc_name=<SERVICE_ACCOUNT_NAME>
gcloud iam service-accounts create $svc_name \
--description="Service account for Terraform" \
--display-name="$svc_name"
gcloud iam service-accounts list
# Get the email of the service account from the list
svc=$(gcloud iam service-accounts list --format='get(email)'
--filter="displayName=$svc_name")
gcloud iam service-accounts keys create .gcloud-credentials.json \
--iam-account="$svc"
gcloud projects add-iam-policy-binding $proj_id \
--member serviceAccount:$svc \
--role roles/editor
  • Abilitare il peering tra il database e il cluster Kubernetes che verrà creato nella fase successiva.
gcloud compute addresses create google-managed-services-default \
--prefix-length=20 \
--purpose=VPC_PEERING \
--network default \
--global \
--description 'IP Range for peer networks.'
gcloud services vpc-peerings connect \
--network=default \
--ranges=google-managed-services-default
  • Creare un file di configurazione minima di terraform (aggiornare secondo necessità).
indexer=<INDEXER_NAME>
cat > terraform.tfvars <<EOF
project = "$proj_id"
indexer = "$indexer"
database_password = "<database passowrd>"
EOF

Utilizzare Terraform per creare l'infrastruttura

Collegamento a questa sezione

Prima di eseguire qualsiasi comando, leggi variables.tf e crea un file terraform.tfvars in questa cartella (o modificare quella creata nell'ultimo passaggio). Per ogni variabile in cui si vuole sovrascrivere il valore predefinito o in cui è necessario impostare un valore, inserire un'impostazione interraform.tfvars.

  • Eseguire i seguenti comandi per creare l'infrastruttura.
# Install required plugins
terraform init
# View plan for resources to be created
terraform plan
# Create the resources (expect it to take up to 30 minutes)
terraform apply

Scaricare le credenziali del nuovo cluster in ~/.kube/config e impostarli come contesto predefinito.

gcloud container clusters get-credentials $indexer
kubectl config use-context $(kubectl config get-contexts --output='name'
| grep $indexer)

Creazione dei componenti Kubernetes per l'Indexer

Collegamento a questa sezione
  • Copiare la directory k8s/overlays in una nuova directory $dir, e regola il bases d'ingresso in $dir/kustomization.yaml in modo da puntare alla directory k8s/base.

  • Leggi tutti i file in $dir e modificare i valori come indicato nei commenti.

Distribuire tutte le risorse con kubectl apply -k $dir.

Graph Node is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.

Iniziare dalla sorgente

Collegamento a questa sezione

Installare i prerequisiti

Collegamento a questa sezione
  • Rust

  • PostgreSQL

  • IPFS

  • Requisiti aggiuntivi per gli utenti di Ubuntu - Per eseguire un Graph Node su Ubuntu potrebbero essere necessari alcuni pacchetti aggiuntivi.

sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
  1. Avviare un server di database PostgreSQL
initdb -D .postgres
pg_ctl -D .postgres -l logfile start
createdb graph-node
  1. Clonare la repository di Graph Node e costruire il sorgente eseguendo cargo build

  2. Ora che tutte le dipendenze sono state configurate, avviare il Graph Node:

cargo run -p graph-node --release -- \
--postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
--ethereum-rpc [NETWORK_NAME]:[URL] \
--ipfs https://ipfs.network.thegraph.com

Come iniziare a usare Docker

Collegamento a questa sezione
  • Ethereum node - Per impostazione predefinita, la configurazione di docker compose utilizzerà mainnet: http://host.docker.internal:8545 per connettersi al nodo Ethereum sulla macchina host. È possibile sostituire il nome e l'url della rete aggiornando docker-compose.yaml.
  1. Clonare il Graph Node e navigare nella directory Docker:
git clone https://github.com/graphprotocol/graph-node
cd graph-node/docker
  1. Solo per gli utenti di Linux - Utilizzare l'indirizzo IP dell'host invece di host.docker.internal nel docker-compose.yaml utilizzando lo script incluso:
./setup.sh
  1. Avviare un Graph Node locale che si connetta all'endpoint di Ethereum:
docker-compose up

Componenti dell'Indexer

Collegamento a questa sezione

Per partecipare con successo alla rete è necessario un monitoraggio e un'interazione quasi costante, quindi abbiamo costruito una suite di applicazioni Typescript per facilitare la partecipazione alla rete degli Indexer. I componenti di Indexer sono tre:

  • Indexer agent - L'agente monitora la rete e l'infrastruttura dell'Indexer e gestisce quali distribuzioni di subgraph vengono indicizzate e allocate sulla chain e quanto viene allocato su ciascuna di esse.

  • Indexer service - L'unico componente che deve essere esposto all'esterno, il servizio passa le query del subgraph al The Graph Node, gestisce i canali di stato per i pagamenti delle query, condivide importanti informazioni decisionali ai client come i gateway.

  • Indexer CLI - L'interfaccia a riga di comando per la gestione del Indexer Agent. Consente agli Indexer di gestire i modelli di costo, le allocazioni manuali, la coda delle azioni e le regole di indicizzazione.

L'Indexer Agent ed l'Indexer service devono essere collocati insieme all'infrastruttura di The Graph Node. Ci sono molti modi per impostare ambienti di esecuzione virtuali per i componenti di Indexer; qui spiegheremo come eseguirli su baremetal usando pacchetti NPM o sorgenti, oppure tramite kubernetes e docker su Google Cloud Kubernetes Engine. Se questi esempi di configurazione non si adattano bene alla vostra infrastruttura, è probabile che ci sia una community guide a cui fare riferimento; fate un salto su Discord! Ricordatevi di fare stake nel protocollo prima di avviare i componenti dell'Indexer!

Dai pacchetti NPM

Collegamento a questa sezione
npm install -g @graphprotocol/indexer-service
npm install -g @graphprotocol/indexer-agent
# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
npm install -g @graphprotocol/graph-cli
npm install -g @graphprotocol/indexer-cli
# Indexer service
graph-indexer-service start ...
# Indexer agent
graph-indexer-agent start ...
# Indexer CLI
#Forward the port of your agent pod if using Kubernetes
kubectl port-forward pod/POD_ID 18000:8000
graph indexer connect http://localhost:18000/
graph indexer ...
# From Repo root directory
yarn
# Indexer Service
cd packages/indexer-service
./bin/graph-indexer-service start ...
# Indexer agent
cd packages/indexer-agent
./bin/graph-indexer-service start ...
# Indexer CLI
cd packages/indexer-cli
./bin/graph-indexer-cli indexer connect http://localhost:18000/
./bin/graph-indexer-cli indexer ...

Utilizzo di docker

Collegamento a questa sezione
  • Estrarre le immagini dal registro
docker pull ghcr.io/graphprotocol/indexer-service:latest
docker pull ghcr.io/graphprotocol/indexer-agent:latest

Oppure costruire le immagini localmente dal sorgente

# Indexer service
docker build \
--build-arg NPM_TOKEN=<npm-token> \
-f Dockerfile.indexer-service \
-t indexer-service:latest \
# Indexer agent
docker build \
--build-arg NPM_TOKEN=<npm-token> \
-f Dockerfile.indexer-agent \
-t indexer-agent:latest \
  • Eseguire i componenti
docker run -p 7600:7600 -it indexer-service:latest ...
docker run -p 18000:8000 -it indexer-agent:latest ...

NOTA: Dopo l'avvio dei contenitori, l'Indexer service dovrebbe essere accessibile all'indirizzo http://localhost:7600 e l'agente dell'Indexer dovrebbe esporre l'API di gestione dell'Indexer all'indirizzo http://localhost:18000/.

Utilizzo di K8s e Terraform

Collegamento a questa sezione

Vedere la sezione Setup Server Infrastructure Using Terraform on Google Cloud

NOTA: Tutte le variabili di configurazione di runtime possono essere applicate come parametri al comando all'avvio o utilizzando variabili d'ambiente del formato COMPONENT_NAME_VARIABLE_NAME(ex. INDEXER_AGENT_ETHEREUM).

graph-indexer-agent start \
--ethereum <MAINNET_ETH_ENDPOINT> \
--ethereum-network mainnet \
--mnemonic <MNEMONIC> \
--indexer-address <INDEXER_ADDRESS> \
--graph-node-query-endpoint http://localhost:8000/ \
--graph-node-status-endpoint http://localhost:8030/graphql \
--graph-node-admin-endpoint http://localhost:8020/ \
--public-indexer-url http://localhost:7600/ \
--indexer-geo-coordinates <YOUR_COORDINATES> \
--index-node-ids default \
--indexer-management-port 18000 \
--metrics-port 7040 \
--network-subgraph-endpoint https://gateway.network.thegraph.com/network \
--default-allocation-amount 100 \
--register true \
--inject-dai true \
--postgres-host localhost \
--postgres-port 5432 \
--postgres-username <DB_USERNAME> \
--postgres-password <DB_PASSWORD> \
--postgres-database indexer \
--allocation-management auto \
| pino-pretty
SERVER_HOST=localhost \
SERVER_PORT=5432 \
SERVER_DB_NAME=is_staging \
SERVER_DB_USER=<DB_USERNAME> \
SERVER_DB_PASSWORD=<DB_PASSWORD> \
graph-indexer-service start \
--ethereum <MAINNET_ETH_ENDPOINT> \
--ethereum-network mainnet \
--mnemonic <MNEMONIC> \
--indexer-address <INDEXER_ADDRESS> \
--port 7600 \
--metrics-port 7300 \
--graph-node-query-endpoint http://localhost:8000/ \
--graph-node-status-endpoint http://localhost:8030/graphql \
--postgres-host localhost \
--postgres-port 5432 \
--postgres-username <DB_USERNAME> \
--postgres-password <DB_PASSWORD> \
--postgres-database is_staging \
--network-subgraph-endpoint https://gateway.network.thegraph.com/network \
| pino-pretty

L'Indexer CLI è un plugin per @graphprotocol/graph-cli accessibile nel terminale a graph indexer.

graph indexer connect http://localhost:18000
graph indexer status

Gestione dell'Indexer tramite Indexer CLI

Collegamento a questa sezione

Lo strumento suggerito per interagire con l'Indexer Management API è il Indexer CLI, un'estensione del Graph CLI. L'Indexer agent ha bisogno di input da un Indexer per interagire autonomamente con la rete per conto dell'Indexer. I meccanismi per definire il comportamento dell' Indexer agent sono modalità di gestione dell'allocazione e regole di indicizzazione. In modalità automatica, un Indexer può utilizzare le regole di indicizzazione per applicare la propria strategia specifica di selezione dei subgraph da indicizzare e per i quali servire le query. Le regole sono gestite tramite un' GraphQL API servito dall' agent e noto come Indexer Management API. In modalità manuale, un Indexer può creare azioni di allocation usando actions queue e approvarli esplicitamente prima che vengano eseguiti. In modalità di supervisione, le regole di indicizzazione sono utilizzate per popolare le actions queue e richiedono anche un'approvazione esplicita per l'esecuzione.

Il Indexer CLI si connette all'Indexer Agent, in genere tramite port-forwarding, quindi non è necessario che la CLI venga eseguita sullo stesso server o cluster. Per aiutarvi a iniziare e per fornire un contesto, la CLI verrà descritta brevemente qui.

  • graph indexer connect <url> - Connettersi all' Indexer management API. In genere la connessione al server viene aperta tramite il port forwarding, in modo che la CLI possa essere facilmente utilizzata in remoto. (Esempio: kubectl port-forward pod/<indexer-agent-pod> 8000:8000)

  • graph indexer rules get [options] <deployment-id> [<key1> ...] - Ottenere una o più regole di indicizzazione utilizzando all come <deployment-id> per ottenere tutte le regole, oppure global per ottenere i valori predefiniti globali. Un argomento aggiuntivo --merged può essere usato per specificare che le regole specifiche dell'implementazione vengono unite alla regola globale. Questo è il modo in cui vengono applicate nell' Indexer agent.

  • graph indexer rules set [options] <deployment-id> <key1> <value1> ... - Impostare una o più regole di indicizzazione.

  • graph indexer rules start [options] <deployment-id> - Avviare l'indicizzazione di una distribuzione di subgraph, se disponibile, e impostare il suo valore di decisionBasis per always, quindi l' Indexer agent sceglierà sempre di indicizzarlo. Se la regola globale è impostata su sempre, tutti i subgraph disponibili sulla rete saranno indicizzati.

  • graph indexer rules stop [options] <deployment-id> - Interrompere l'indicizzazione di un'installazione e impostare il suo decisionBasis a mai, quindi salterà questa distribuzione quando deciderà le distribuzioni da indicizzare.

  • graph indexer rules maybe [options] <deployment-id> — Impostare il decisionBasis per una distribuzione a rules, in modo che l' Indexer agent utilizzi le regole di indicizzazione per decidere se indicizzare questa distribuzione.

  • graph indexer actions get [options] <action-id> - Recuperare una o più azioni utilizzando all oppure lasciare action-id vuoto per ottenere tutte le azioni. Un'argomento aggiuntivo --status può essere usato per stampare tutte le azioni di un certo stato.

  • graph indexer action queue allocate <deployment-id> <allocation-amount> - Azione di allocation della coda

  • graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount> - Azione di riallocazione della coda

  • graph indexer action queue unallocate <deployment-id> <allocation-id> - Azione di deallocazione della coda

  • graph indexer actions cancel [<action-id> ...] - Annulla tutte le azioni nella coda se l'id non è specificato, altrimenti annulla l'array di id con lo spazio come separatore

  • graph indexer actions approve [<action-id> ...] - Approvare più azioni multiple da eseguire

  • graph indexer actions execute approve - Forzare il lavoratore a eseguire immediatamente le azioni approvate

Tutti i comandi che visualizzano le regole nell'output possono scegliere tra i formati di output supportati (table, yaml, and json) utilizzando l'argomento -output.

Regole di indicizzazione

Collegamento a questa sezione

Le regole di indicizzazione possono essere applicate come valori predefiniti globali o per specifiche distribuzioni di subgraph utilizzando i loro ID. I campi deployment e decisionBasis sono obbligatori, mentre tutti gli altri campi sono facoltativi. Quando una regola di indicizzazione ha rules come decisionBasis, allora l' Indexer agent confronterà i valori di soglia non nulli di quella regola con i valori recuperati dalla rete per la distribuzione corrispondente. Se la distribuzione del subgraph ha valori superiori (o inferiori) a una qualsiasi delle soglie, verrà scelta per l'indicizzazione.

Ad esempio, se la regola globale ha minStake di 5 (GRT) qualsiasi schieramento di subgraph che abbia più di 5 (GRT) di stake assegnati ad esso sarà indicizzato. Le regole di soglia includono maxAllocationPercentage, minSignal, maxSignal, minStake, e minAverageQueryFees.

Modello di dati:

type IndexingRule {
identifier: string
identifierType: IdentifierType
decisionBasis: IndexingDecisionBasis!
allocationAmount: number | null
allocationLifetime: number | null
autoRenewal: boolean
parallelAllocations: number | null
maxAllocationPercentage: number | null
minSignal: string | null
maxSignal: string | null
minStake: string | null
minAverageQueryFees: string | null
custom: string | null
requireSupported: boolean | null
}
IdentifierType {
deployment
subgraph
group
}
IndexingDecisionBasis {
rules
never
always
offchain
}

Esempio di utilizzo della regola di indicizzazione:

graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK

CLI della coda di azioni

Collegamento a questa sezione

L'indexer-cli fornisce un modulo di actions per lavorare manualmente con la coda di azioni. Utilizza il Graphql API ospitato dal server di gestione dell'Indexer per interagire con la coda delle azioni.

L'operaio per l'esecuzione dell'azione prenderà gli elementi dalla coda per eseguirli solo se hanno ActionStatus = approved. Nel percorso consigliato le azioni vengono aggiunte alla coda con ActionStatus = queued, quindi devono essere approvate per essere eseguite sulla catena. Il flusso generale sarà simile a:

  • Azione aggiunta alla coda dallo strumento ottimizzatore di terze parti o dall'utente di indexer-cli
  • L' Indexer può utilizzare l'indexer-cli per visualizzare tutte le azioni in coda
  • L'Indexer (o un altro software) può approvare o annullare le azioni nella coda utilizzando l'indexer-cli. I comandi approva e annulla prendono in input un array di id di azioni.
  • L'operaio di esecuzione controlla regolarmente la coda per le azioni approvate. Prenderà le azioni approved dalla coda, tenterà di eseguirle e aggiornerà i valori nel db a seconda dello stato di esecuzione con success oppure failed.
  • Se un'azione ha successo, l'operaio si assicurerà che sia presente una regola di indicizzazione che indichi all'agente come gestire l'allocazione in futuro, utile quando si intraprendono azioni manuali mentre l'agente è in modalità auto oppure oversight.
  • L'Indexer può monitorare la coda delle azioni per vedere la cronologia dell'esecuzione delle azioni e, se necessario, riapprovare e aggiornare le voci di azione se non sono state eseguite. La coda di azioni fornisce una cronologia di tutte le azioni accodate ed eseguite.

Modello di dati:

Type ActionInput {
status: ActionStatus
type: ActionType
deploymentID: string | null
allocationID: string | null
amount: string | null
poi: string | null
force: boolean | null
source: string
reason: string | null
priority: number | null
}
ActionStatus {
queued
approved
pending
success
failed
canceled
}
ActionType {
allocate
unallocate
reallocate
collect
}

Esempio di utilizzo dalla sorgente:

graph indexer actions get all
graph indexer actions get --status queued
graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
graph indexer actions cancel
graph indexer actions approve 1 3 5
graph indexer actions execute approve

Si noti che i tipi di azione supportati per la gestione dell'allocazione hanno requisiti di input diversi:

  • Allocate - allocare lo stake ad uno specifico deploy di subgraph

    • parametri d'azione richiesti:
      • deploymentID
      • amount
  • Unallocate - chiudere l'allocazione, liberando lo stake da riallocare altrove

    • parametri d'azione richiesti:
      • allocationID
      • deploymentID
    • parametri dell'azione facoltativi:
      • poi
      • force (forza l'uso del POI fornito anche se non corrisponde a quello fornito dal the graph-node)
  • Reallocate - chiudere atomicamente l'allocazione e aprire una nuova allocazione per lo stesso deplloy del subgraph

    • parametri d'azione richiesti:
      • allocationID
      • deploymentID
      • amount
    • parametri dell'azione facoltativi:
      • poi
      • force (forza l'uso del POI fornito anche se non corrisponde a quello fornito dal the graph-node)

I modelli di costo forniscono prezzi dinamici per le query in base al mercato e agli attributi della query. L'Indexer service condivide con i gateway un modello di costo per ogni subgraph per il quale intende rispondere alle query. I gateway, a loro volta, utilizzano il modello di costo per prendere decisioni sulla selezione degli Indexer per ogni query e per negoziare il pagamento con gli Indexer scelti.

Il linguaggio Agora fornisce un formato flessibile per dichiarare i modelli di costo delle query. Un modello di prezzo Agora è una sequenza di istruzioni che vengono eseguite in ordine per ogni query di primo livello in una query GraphQL. Per ogni query di primo livello, la prima istruzione che vi corrisponde determina il prezzo per quella query.

Una dichiarazione è composta da un predicato, che viene usato per abbinare le query GraphQL, e da un'espressione di costo che, una volta valutata, produce un costo in GRT decimali. I valori nella posizione dell'argomento nominato di una query possono essere catturati nel predicato e usati nell'espressione. Si possono anche impostare dei globali e sostituirli ai segnaposto in un'espressione.

Esempio di modello di costo:

# This statement captures the skip value,
# uses a boolean expression in the predicate to match specific queries that use `skip`
# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
# This default will match any GraphQL expression.
# It uses a Global substituted into the expression to calculate cost
default => 0.1 * $SYSTEM_LOAD;

Esempio di query di costo utilizzando il modello di cui sopra:

QueryPrezzo
{ pairs(skip: 5000) { id } }0.5 GRT
{ tokens { symbol } }0.1 GRT
{ pairs(skip: 5000) { id } tokens { symbol } }0.6 GRT

Applicazione del modello di costo

Collegamento a questa sezione

I modelli di costo vengono applicati tramite l'Indexer CLI, che li passa all'Indexer Management API dell' Indexer agent per la memorizzazione nel database. L'Indexer Service li preleva e serve i modelli di costo ai gateway ogni volta che li richiedono.

indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
indexer cost set model my_model.agora

Interazione con la rete

Collegamento a questa sezione

Staking al protocollo

Collegamento a questa sezione

The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.

Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice (OneClickDapp, ABItopic, and MyCrypto are a few other known tools).

Una volta che l'Indexer ha messo in staking i GRT nel protocollo, gli Indexer components possono essere avviati e iniziare le loro interazioni con la rete.

Approvare i token

Collegamento a questa sezione
  1. Aprire il Remix app nel browser

  2. Nel File Explorer creare un file chiamato GraphToken.abi con il token ABI.

  3. With GraphToken.abi selected and open in the editor, switch to the Deploy and run transactions section in the Remix interface.

  4. In Ambiente selezionare Injected Web3 e nel Account selezionare l'indirizzo dell'Indexer.

  5. Impostare l'indirizzo del contratto GraphToken - Incollare l'indirizzo del contratto GraphToken (0xc944E90C64B2c07662A292be6244BDf05Cda44a7) vicino a At Address e fare clic sul pulsante At address per applicare.

  6. Chiamare la funzione approve(spender, amount) per approvare il contratto di staking. Inserire in spender l'indirizzo del contratto di Staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9) e amount con i token da fare staking (in wei).

Fare staking dei token

Collegamento a questa sezione
  1. Aprire il Remix app nel browser

  2. Nel File Explorer creare un file chiamato Staking.abi con log staking ABI.

  3. With Staking.abi selected and open in the editor, switch to the Deploy and run transactions section in the Remix interface.

  4. In Ambiente selezionare Injected Web3 e nel Account selezionare l'indirizzo dell'Indexer.

  5. Impostare l'indirizzo del contratto di Staking - Incollare l'indirizzo del contratto di Staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9) vicino a At Address e fare click sul pulsante At address per applicare.

  6. Chiamare stake() per fare staking di GRT sul protocollo.

  7. (Opzionale) Gli Indexer possono approvare un altro indirizzo come operatore per la loro infrastruttura di indicizzazione, al fine di separare le chiavi che controllano i fondi da quelle che eseguono le azioni quotidiane, come l'allocazione sui subgraph e il servizio di query (a pagamento). Per impostare l'operatore chiamare setOperator() con l'indirizzo dell'operatore.

  8. (Opzionale) Per controllare la distribuzione delle ricompense e attirare strategicamente i delegator, gli Indexer possono aggiornare i loro parametri di delega aggiornando i loro indexingRewardCut (parti per milione), queryFeeCut (parti per milione) e cooldownBlocks (numero di blocchi). Per farlo, chiamare setDelegationParameters(). L'esempio seguente imposta il queryFeeCut per distribuire il 95% degli sconti sulle query all'Indexer e il 5% ai Delegator, imposta l'indexingRewardCut per distribuire il 60% delle ricompense per l'indicizzazione all'Indexer e il 40% ai Delegator, e imposta il periodo di thecooldownBlocks a 500 blocks.

setDelegationParameters(950000, 600000, 500)

Setting delegation parameters

Collegamento a questa sezione

The setDelegationParameters() function in the staking contract is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.

How to set delegation parameters

Collegamento a questa sezione

To set the delegation parameters using Graph Explorer interface, follow these steps:

  1. Navigate to Graph Explorer.
  2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
  3. Connect the wallet you have as a signer.
  4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
  5. Submit the transaction to the network.

Note: This transaction will need to be confirmed by the multisig wallet signers.

La vita di un'allocazione

Collegamento a questa sezione

Dopo essere stata creata da un Indexer, un'allocazione sana passa attraverso quattro stati.

  • Active - Once an allocation is created on-chain (allocateFrom()) it is considered active. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.

  • Closed - An Indexer is free to close an allocation once 1 epoch has passed (closeAllocation()) or their Indexer agent will automatically close the allocation after the maxAllocationEpochs (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators (learn more).

Si raccomanda agli Indexer di utilizzare la funzionalità di sincronizzazione offchain per sincronizzare le distribuzioni dei subgraph con chainhead prima di creare l'allocazione on-chain. Questa funzione è particolarmente utile per i subgraph che possono richiedere più di 28 epoche per la sincronizzazione o che hanno qualche possibilità di fallire in modo indeterminato.

Modifica pagina

Precedente
Benefits
Successivo
Delegazione
Modifica pagina