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
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 . You can also find an up to date list of tools in the #Delegators and #Indexers channels on the . Here we link a 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 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:
query indexerAllocations {indexer(id: "<INDEXER_ADDRESS>") {allocations {activeForIndexer {allocations {id}}}}}
Utilizzare Etherscan per chiamare getRewards()
:
- 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 ). 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 .
-
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.
Setup | Postgres (CPUs) | Postgres (memoria in GBs) | Postgres (disco in TBs) | VMs (CPUs) | VMs (memoria in GBs) |
---|---|---|---|---|---|
Piccolo | 4 | 8 | 1 | 4 | 16 |
Standard | 8 | 30 | 1 | 12 | 48 |
Medio | 16 | 64 | 2 | 32 | 64 |
Grande | 72 | 468 | 3.5 | 48 | 184 |
-
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. Vedere 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 . 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 .
-
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.
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.
Porta | Obiettivo | Routes | Argomento CLI | Variabile d'ambiente |
---|---|---|---|---|
8000 | GraphQL HTTP server (per le query di subgraph) | /subgraphs/id/... /subgraphs/name/.../... | --http-port | - |
8001 | GraphQL WS (per le sottoscrizioni ai subgraph) | /subgraphs/id/... /subgraphs/name/.../... | --ws-port | - |
8020 | JSON-RPC (per la gestione dei deployment) | / | --admin-port | - |
8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
8040 | Metriche di Prometheus | /metrics | --metrics-port | - |
Porta | Obiettivo | Routes | Argomento CLI | Variabile d'ambiente |
---|---|---|---|---|
7600 | GraphQL HTTP server (per le query di subgraph a pagamento) | /subgraphs/id/... /status /channel-messages-inbox | --port | INDEXER_SERVICE_PORT |
7300 | Metriche di Prometheus | /metrics | --metrics-port | - |
Porta | Obiettivo | Routes | Argomento CLI | Variabile d'ambiente |
---|---|---|---|---|
8000 | API di gestione degli Indexer | / | --indexer-management-port | INDEXER_AGENT_INDEXER_MANAGEMENT_PORT |
Nota: gli Indexer possono utilizzare in alternativa AWS, Microsoft Azure o Alibaba.
- Google Cloud SDK
- Kubectl command line tool
- Terraform
-
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 loginproject=<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 $projectgcloud config set project "$proj_id"gcloud config set compute/region us-central1gcloud config set compute/zone us-central1-a
- Abilitare le API di Google Cloud necessarie.
gcloud services enable compute.googleapis.comgcloud services enable container.googleapis.comgcloud services enable servicenetworking.googleapis.comgcloud 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 listsvc=$(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 <<EOFproject = "$proj_id"indexer = "$indexer"database_password = "<database passowrd>"EOF
Prima di eseguire qualsiasi comando, leggi 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 pluginsterraform init# View plan for resources to be createdterraform 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 $indexerkubectl config use-context $(kubectl config get-contexts --output='name'| grep $indexer)
-
Copiare la directory
k8s/overlays
in una nuova directory$dir,
e regola ilbases
d'ingresso in$dir/kustomization.yaml
in modo da puntare alla directoryk8s/base
. -
Leggi tutti i file in
$dir
e modificare i valori come indicato nei commenti.
Distribuire tutte le risorse con kubectl apply -k $dir
.
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
- Avviare un server di database PostgreSQL
initdb -D .postgrespg_ctl -D .postgres -l logfile startcreatedb graph-node
Clonare la repository di e costruire il sorgente eseguendo
cargo build
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: per connettersi al nodo Ethereum sulla macchina host. È possibile sostituire il nome e l'url della rete aggiornando
docker-compose.yaml
.
- Clonare il Graph Node e navigare nella directory Docker:
git clone https://github.com/graphprotocol/graph-nodecd graph-node/docker
- Solo per gli utenti di Linux - Utilizzare l'indirizzo IP dell'host invece di
host.docker.internal
neldocker-compose.yaml
utilizzando lo script incluso:
./setup.sh
- 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 ! Ricordatevi di fare prima di avviare i componenti dell'Indexer!
npm install -g @graphprotocol/indexer-servicenpm install -g @graphprotocol/indexer-agent# Indexer CLI is a plugin for Graph CLI, so both need to be installed:npm install -g @graphprotocol/graph-clinpm install -g @graphprotocol/indexer-cli# Indexer servicegraph-indexer-service start ...# Indexer agentgraph-indexer-agent start ...# Indexer CLI#Forward the port of your agent pod if using Kuberneteskubectl port-forward pod/POD_ID 18000:8000graph indexer connect http://localhost:18000/graph indexer ...
# From Repo root directoryyarn# Indexer Servicecd packages/indexer-service./bin/graph-indexer-service start ...# Indexer agentcd packages/indexer-agent./bin/graph-indexer-service start ...# Indexer CLIcd 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:latestdocker pull ghcr.io/graphprotocol/indexer-agent:latest
Oppure costruire le immagini localmente dal sorgente
# Indexer servicedocker build \--build-arg NPM_TOKEN=<npm-token> \-f Dockerfile.indexer-service \-t indexer-service:latest \# Indexer agentdocker 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 e l'agente dell'Indexer dovrebbe esporre l'API di gestione dell'Indexer all'indirizzo .
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 accessibile nel terminale a graph indexer
.
graph indexer connect http://localhost:18000graph 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 utilizzandoall
come<deployment-id>
per ottenere tutte le regole, oppureglobal
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 didecisionBasis
peralways
, 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 suodecisionBasis
a mai, quindi salterà questa distribuzione quando deciderà le distribuzioni da indicizzare. -
graph indexer rules maybe [options] <deployment-id>
— Impostare ildecisionBasis
per una distribuzione arules
, 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 utilizzandoall
oppure lasciareaction-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
.
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: stringidentifierType: IdentifierTypedecisionBasis: IndexingDecisionBasis!allocationAmount: number | nullallocationLifetime: number | nullautoRenewal: booleanparallelAllocations: number | nullmaxAllocationPercentage: number | nullminSignal: string | nullmaxSignal: string | nullminStake: string | nullminAverageQueryFees: string | nullcustom: string | nullrequireSupported: boolean | null}IdentifierType {deploymentsubgraphgroup}IndexingDecisionBasis {rulesneveralwaysoffchain}
Esempio di utilizzo della regola di indicizzazione:
graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEKgraph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported falsegraph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEKgraph 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 consuccess
oppurefailed
. - 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
oppureoversight
. - 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: ActionStatustype: ActionTypedeploymentID: string | nullallocationID: string | nullamount: string | nullpoi: string | nullforce: boolean | nullsource: stringreason: string | nullpriority: number | null}ActionStatus {queuedapprovedpendingsuccessfailedcanceled}ActionType {allocateunallocatereallocatecollect}
Esempio di utilizzo dalla sorgente:
graph indexer actions get allgraph indexer actions get --status queuedgraph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2aegraph indexer actions cancelgraph indexer actions approve 1 3 5graph 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
- parametri d'azione richiesti:
-
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)
- parametri d'azione richiesti:
-
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)
- parametri d'azione richiesti:
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 globalquery { 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 costdefault => 0.1 * $SYSTEM_LOAD;
Esempio di query di costo utilizzando il modello di cui sopra:
Query | Prezzo |
---|---|
{ pairs(skip: 5000) { id } } | 0.5 GRT |
{ tokens { symbol } } | 0.1 GRT |
{ pairs(skip: 5000) { id } tokens { symbol } } | 0.6 GRT |
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.
Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice (, , and are a few other known tools).
Una volta che l'Indexer ha messo in staking i GRT nel protocollo, gli possono essere avviati e iniziare le loro interazioni con la rete.
Nel
File Explorer
creare un file chiamato GraphToken.abi con il .With
GraphToken.abi
selected and open in the editor, switch to theDeploy and run transactions
section in the Remix interface.In Ambiente selezionare
Injected Web3
e nelAccount
selezionare l'indirizzo dell'Indexer.Impostare l'indirizzo del contratto GraphToken - Incollare l'indirizzo del contratto GraphToken (
0xc944E90C64B2c07662A292be6244BDf05Cda44a7
) vicino aAt Address
e fare clic sul pulsanteAt address
per applicare.Chiamare la funzione
approve(spender, amount)
per approvare il contratto di staking. Inserire inspender
l'indirizzo del contratto di Staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9
) eamount
con i token da fare staking (in wei).
Nel
File Explorer
creare un file chiamato Staking.abi con log staking ABI.With
Staking.abi
selected and open in the editor, switch to theDeploy and run transactions
section in the Remix interface.In Ambiente selezionare
Injected Web3
e nelAccount
selezionare l'indirizzo dell'Indexer.Impostare l'indirizzo del contratto di Staking - Incollare l'indirizzo del contratto di Staking (
0xF55041E37E12cD407ad00CE2910B8269B01263b9
) vicino aAt Address
e fare click sul pulsanteAt address
per applicare.Chiamare
stake()
per fare staking di GRT sul protocollo.(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.(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 dithecooldownBlocks
a 500 blocks.
setDelegationParameters(950000, 600000, 500)
The setDelegationParameters()
function in the 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:
- Navigate to .
- Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
- Connect the wallet you have as a signer.
- 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.
- Submit the transaction to the network.
Note: This transaction will need to be confirmed by the multisig wallet signers.
Dopo essere stata creata da un Indexer, un'allocazione sana passa attraverso quattro stati.
-
Active - Once an allocation is created on-chain () 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 () 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 ().
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.