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.

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

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.

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.

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.

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).

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. Query the mainnet subgraph to get the IDs for all active allocations:

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.

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.

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.

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%.

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.

• 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.

• 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.

• Google Cloud SDK
• Kubectl command line tool
• Terraform

• 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

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)

• 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.

• 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

2. Clonare la repository di Graph Node e costruire il sorgente eseguendo cargo build

3. 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

• 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

2. 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

3. Avviare un Graph Node locale che si connetta all'endpoint di Ethereum:

docker-compose up

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!

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 ...

• 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/.

Vedere la sezione Setup Server Infrastructure Using Terraform on Google Cloud

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 http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
  --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 http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
  | 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

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> - Fetch one or more actions using all or leave action-id empty to get all actions. An additional argument --status can be used to print out all actions of a certain status.

• 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.

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

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:

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

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.

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.

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).

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)

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.

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.

After being created by an Indexer a healthy allocation goes through two states.

• 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.