Indexering

Reading time: 23 min

Indexerare är nodoperatörer i The Graph Network som satsar Graph Tokens (GRT) för att tillhandahålla indexering och frågebehandlingstjänster. Indexerare tjänar avgifter för frågor och indexering samt får frågebetalningar som återbetalas enligt en exponentiell återbetalningsfunktion.

GRT som satsas i protokollet är föremål för en tiningperiod och kan drabbas av strykning om indexerare är skadliga och tillhandahåller felaktiga data till applikationer eller om de indexerar felaktigt. Indexerare tjänar också belöningar för delegerat satsning från Delegater, för att bidra till nätverket.

Indexerare väljer subgrafer att indexera baserat på subgrafens kuratersignal, där Curators satsar GRT för att ange vilka subgrafer som är av hög kvalitet och bör prioriteras. Konsumenter (t.ex. applikationer) kan också ställa in parametrar för vilka indexerare som behandlar frågor för deras subgrafer och ange preferenser för pris på frågebetalning.

Det minsta beloppet för en indexerare är för närvarande inställt på 100 000 GRT.

Frågebetalningsåterbetalningar - Betalningar för att servera frågor i nätverket. Dessa betalningar medieras via tillståndskanaler mellan en indexerare och en gateway. Varje frågebegäran från en gateway innehåller en betalning och det motsvarande svaret är en bevis på giltigheten av frågeresultatet.

Indexeringsbelöningar - Genererade genom en årlig protokollsbredd på 3%, fördelas indexerare som indexerar subgrafdepåer för nätverket.

Indexeringsbelöningar kommer från protokollsinflation som är inställd på en årlig emission på 3%. De fördelas över subgrafer baserat på andelen av all kuratersignal på varje subgraf, och fördelas sedan proportionellt till indexerare baserat på deras tilldelade insats på den subgrafen. En tilldelning måste avslutas med ett giltigt bevis på indexering (POI) som uppfyller de standarder som fastställts av skiljekommittéstadgan för att vara berättigad till belöningar.

Många verktyg har skapats av gemenskapen för att beräkna belöningar; du hittar en samling av dem organiserade i Gemenskapsrådssamlingen. Du kan också hitta en uppdaterad lista över verktyg i kanalerna #Delegater och #Indexers på Discord-servern. Här länkar vi en rekommenderad allokeringsoptimerare integrerad med indexer-programvarustapeln.

POI:er används i nätverket för att verifiera att en indexerare indexerar de subgrafer de har tilldelat sig. Ett POI för det första blocket i den nuvarande epoken måste lämnas in när en tilldelning stängs för att vara berättigad till indexeringsbelöningar. Ett POI för ett block är en digest för alla entity store-transaktioner för en specifik subgrafdepå fram till och med det blocket.

Tilldelningar ackumulerar kontinuerligt belöningar medan de är aktiva och tilldelade inom 28 epoker. Belöningarna samlas in av indexerarna och distribueras när deras tilldelningar stängs. Det sker antingen manuellt, när indexeraren vill tvinga dem att stängas, eller efter 28 epoker kan en Delegat stänga tilldelningen för indexeraren, men detta resulterar inte i några belöningar. 28 epoker är den maximala tilldelningens livslängd (för närvarande varar en epok i cirka ~24h).

Kontraktet RewardsManager har en skrivskyddad funktion getRewards som kan användas för att kontrollera de väntande belöningarna för en specifik tilldelning.

Många av gemenskapens egentillverkade instrument inkluderar värden för väntande belöningar och de kan enkelt kontrolleras manuellt genom att följa dessa steg:

1. Fråga mainnet-subgrafen för att få ID:n för alla aktiva tilldelningar:

query indexerAllocations {
  indexer(id: "<INDEXER_ADDRESS>") {
    allocations {
      activeForIndexer {
        allocations {
          id
        }
      }
    }
  }
}

Använd Etherscan för att anropa getRewards():

• Navigera till Etherscan-gränssnittet till belöningskontraktet

• För att anropa getRewards():
  • Expandera rullgardinsmenyn 10. getRewards.
  • Ange allocationID i inmatningen.
  • Klicka på Fråga-knappen.

Indexerares frågor och tilldelningar kan båda bli föremål för tvister på The Graph under tvisteperioden. Tvisteperioden varierar beroende på typen av tvist. Frågor/erkännanden har en tvistefönster på 7 epocher, medan tilldelningar har 56 epocher. Efter att dessa perioder har passerat kan inga tvister öppnas mot vare sig tilldelningar eller frågor. När en tvist öppnas krävs en insättning av minst 10 000 GRT av Fishermen, som kommer att vara låsta tills tvisten är avslutad och en resolution har lämnats. Fishermen är nätverksdeltagare som öppnar tvister.

Tvister har tre möjliga utfall, liksom insättningen från Fishermen.

• Om tvisten avvisas kommer den GRT som satts in av Fishermen att brännas, och den ifrågasatta Indexern kommer inte att bli straffad.
• Om tvisten avgörs som oavgjord kommer Fishermens insättning att återbetalas, och den ifrågasatta Indexern kommer inte att bli straffad.
• Om tvisten godkänns kommer den GRT som satts in av Fishermen att återbetalas, den ifrågasatta Indexern kommer att bli straffad, och Fishermen kommer att tjäna 50% av den straffade GRT.

Tvister kan ses i gränssnittet på en Indexers profil under fliken Tvister.

Förfrågningsavgifter samlas in av gateway och fördelas till indexerare enligt den exponentiella rabattfunktionen (se GIP här). Den exponentiella rabattfunktionen föreslås som ett sätt att säkerställa att indexerare uppnår det bästa resultatet genom att troget servera förfrågningar. Den fungerar genom att ge indexerare incitament att allokerar en stor mängd insats (som kan beskäras om de begår fel när de serverar en förfrågan) i förhållande till den mängd förfrågningsavgifter de kan samla in.

När en tilldelning har avslutats är återbetalningarna tillgängliga för Indexern att hämta. Vid hämtning distribueras frågeavgiftsåterbetalningarna till Indexern och deras Delegatorer baserat på frågeavgiftsminskningen och den exponentiella rabattfunktionen.

Värdena queryFeeCut och indexingRewardCut är delegationparametrar som Indexern kan sätta tillsammans med cooldownBlocks för att kontrollera distributionen av GRT mellan Indexern och deras Delegatorer. Se de sista stegen i Staking i protokollet för anvisningar om att ställa in delegationparametrarna.

• queryFeeCut - andelen frågeavgiftsåterbetalningar som kommer att distribueras till Indexern. Om detta är inställt på 95% kommer Indexern att få 95% av de frågeavgifter som tjänas när en tilldelning avslutas, medan de andra 5% fördelas till Delegatorerna.

• indexingRewardCut - andelen indexeringsbelöningar som kommer att distribueras till Indexern. Om detta är inställt på 95% kommer Indexern att få 95% av indexeringsbelöningarna när en tilldelning avslutas, och Delegatorerna kommer att dela de återstående 5%.

Indexers kan skilja sig åt genom att tillämpa avancerade tekniker för att fatta beslut om indexering av subgrafer, men för att ge en allmän idé kommer vi att diskutera flera viktiga metoder som används för att utvärdera subgrafer i nätverket:

• Kureringssignal - Andelen nätverkskureringssignal som används för en specifik subgraf är en bra indikator på intresset för den subgrafen, särskilt under uppstartsfasen när frågevolymen ökar.

• Inkassering av frågeavgifter - Historisk data för volymen av frågeavgifter som samlats in för en specifik subgraf är en bra indikator på framtida efterfrågan.

• Insatsbelopp - Att övervaka beteendet hos andra Indexers eller att titta på andelar av total insats som allokerats till specifika subgrafer kan låta en Indexer övervaka tillgångssidan för subgrafsförfrågningar och identifiera subgrafer som nätverket visar förtroende för eller subgrafer som kan behöva mer tillgång.

• Subgrafer utan indexeringsbelöningar - Vissa subgrafer genererar inte indexeringsbelöningar huvudsakligen eftersom de använder otillåtna funktioner som IPFS eller eftersom de frågar ett annat nätverk utanför mainnet. Du kommer att se ett meddelande på en subgraf om den inte genererar indexeringsbelöningar.

• Liten - Tillräckligt för att komma igång med att indexera flera subgrafer, kommer sannolikt att behöva utökas.
• Standard - Standardinställning, detta är vad som används i exempelvis k8s/terraform-implementeringsmanifesten.
• Medium - Produktionsindexer som stöder 100 subgrafer och 200-500 förfrågningar per sekund.
• Stor - Förberedd för att indexera alla för närvarande använda subgrafer och att ta emot förfrågningar för relaterad trafik.

• Operatörplånbok - Att skapa en operatörplånbok är en viktig försiktighetsåtgärd eftersom den möjliggör att en Indexer kan upprätthålla separation mellan sina nycklar som styr insatsen och de som är ansvariga för dagliga operationer. Se Insats i protokollet för anvisningar.

• Brandvägg - Endast Indexertjänsten behöver vara offentligt exponerad och särskild uppmärksamhet bör ägnas åt att säkra administrativa portar och databasåtkomst: Graph Node JSON-RPC-gränssnittet (standardport: 8030), Indexerhanterings-API-gränssnittet (standardport: 18000) och PostgreSQL-databasgränssnittet (standardport: 5432) bör inte vara exponerade.

I centrum av en Indexers infrastruktur finns Graph Node, som övervakar de indexerade nätverken, extraherar och laddar data enligt en subgrafdefinition och serverar det som en GraphQL API. Graph Node måste vara ansluten till en endpoint som exponerar data från varje indexerat nätverk; en IPFS-nod för att hämta data; en PostgreSQL-databas för lagring; och Indexer-komponenter som underlättar dess interaktioner med nätverket.

• PostgreSQL-databas - Huvudlagret för Graph Node, detta är där subgrafdata lagras. Indexertjänsten och agenten använder också databasen för att lagra state channel-data, kostnadsmodeller, indexeringsregler och tilldelningsåtgärder.

• Dataendpoint - För EVM-kompatibla nätverk måste Graph Node vara ansluten till en endpoint som exponerar en EVM-kompatibel JSON-RPC-API. Detta kan ta form av en enskild klient eller det kan vara en mer komplex konfiguration som balanserar belastningen över flera. Det är viktigt att vara medveten om att vissa subgrafer kan kräva specifika klientfunktioner som arkivläge och/eller parity-spårnings-API.

• IPFS-nod (version mindre än 5) - Metadata för subgrafdistribution lagras på IPFS-nätverket. Graph Node har huvudsakligen åtkomst till IPFS-noden under subgrafdistributionen för att hämta subgrafmanifestet och alla länkade filer. Nätverksindexer behöver inte hosta sin egen IPFS-nod, en IPFS-nod för nätverket är värd på https://ipfs.network.thegraph.com.

• Indexertjänst - Hanterar alla nödvändiga externa kommunikationer med nätverket. Delar kostnadsmodeller och indexeringsstatus, skickar frågebegäranden från gateways vidare till en Graph Node och hanterar frågebetalningar via tillståndskanaler med gatewayen.

• Indexeragent - Underlättar Indexers interaktioner på kedjan, inklusive registrering i nätverket, hantering av subgrafdistributioner till sina Graph Node/noder och hantering av tilldelningar.

• Prometheus-metrisk server - Graph Node och Indexer-komponenter loggar sina metriska data till metrisk servern.

Observera: För att stödja smidig skalning rekommenderas det att fråge- och indexeringsbekymmer separeras mellan olika uppsättningar noder: frågenoder och indexnoder.

• SDK för Google Cloud
• Kubectl kommandoradsverktyg
• Terraform

• Klonad eller navigera till Indexer-repositoriet.

• Navigera till ./terraform-mappen, detta är där alla kommandon ska köras.

cd terraform

• Autentisera dig med Google Cloud och skapa ett nytt projekt.

gcloud auth login
project=<PROJECT_NAME>
gcloud projects create --enable-cloud-apis $project

• Använd faktureringssidan i Google Cloud Console för att aktivera fakturering för det nya projektet.

• Skapa en Google Cloud-konfiguration.

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

• Aktivera nödvändiga API:er för Google Cloud.

gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com
gcloud services enable servicenetworking.googleapis.com
gcloud services enable sqladmin.googleapis.com

• Skapa ett servicekonto.

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

• Aktivera peering mellan databasen och Kubernetes-klustret som kommer att skapas i nästa steg.

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

• Skapa en minimal konfigurationsfil för terraformen (uppdatera vid behov).

indexer=<INDEXER_NAME>
cat > terraform.tfvars <<EOF
project = "$proj_id"
indexer = "$indexer"
database_password = "<database passowrd>"
EOF

Innan du kör några kommandon, läs igenom variables.tf och skapa en fil terraform.tfvars i denna katalog (eller modifiera den som vi skapade i det sista steget). För varje variabel där du vill åsidosätta standardinställningen, eller där du behöver ange ett värde, anger du en inställning i terraform.tfvars.

• Kör följande kommandon för att skapa infrastrukturen.

# Installera nödvändiga plugins
terraform init

# Se plan för resurser som ska skapas
terraform plan

# Skapa resurserna (räkna med att det tar upp till 30 minuter)
terraform apply

Ladda ner autentiseringsuppgifter för det nya klustret till ~/.kube/config och ange det som din standardkontext.

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

• Kopiera katalogen k8s/overlays till en ny katalog $dir och justera posten bases i $dir/kustomization.yaml så att den pekar på katalogen k8s/base.

• Läs igenom alla filer i $dir och justera eventuella värden enligt anvisningarna i kommentarerna.

Installera alla resurser med kubectl apply -k $dir.

Graph Node är en öppen källkodsimplementering i Rust som eventkällor Ethereum-blockkedjan för att deterministiskt uppdatera en datalagring som kan förfrågas via GraphQL-endpunkten. Utvecklare använder subgrafer för att definiera sitt schema och en uppsättning avbildningar för att omvandla data som hämtas från blockkedjan, och Graph Node hanterar synkroniseringen av hela kedjan, övervakning av nya block och servering av den via en GraphQL-endpunkt.

• Rust

• PostgreSQL

• IPFS

• Ytterligare krav för Ubuntu-användare - För att köra en Graph Node på Ubuntu kan några ytterligare paket behövas.

sudo apt-get install -y clang libpg-dev libssl-dev pkg-config

1. Starta en PostgreSQL-databasserver

initdb -D .postgres
pg_ctl -D .postgres -l logfile start
createdb graph-node

2. Klona Graph Node repo och bygg källkoden genom att köra cargo build

3. Nu när alla beroenden är konfigurerade startar du 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 nod - Som standard kommer docker compose-konfigurationen att använda mainnet: http://host.docker.internal:8545 för att ansluta till Ethereum-noden på din värdmaskin. Du kan ersätta detta nätverksnamn och Url genom att uppdatera docker-compose.yaml.

1. Klona Graph Node och navigera till Docker-katalogen:

git clone https://github.com/graphprotocol/graph-node
cd graph-node/docker

2. Endast för Linux-användare - Använd värdens IP-adress istället för host.docker.internal i docker-compose.yaml med hjälp av det medföljande skriptet:

./setup.sh

3. Starta en lokal Graph Node som kommer att ansluta till din Ethereum-ändpunkt:

docker-compose up

För att framgångsrikt delta i nätverket krävs nästan konstant övervakning och interaktion, så vi har byggt en uppsättning Typescript-applikationer för att underlätta en Indexers nätverksdeltagande. Det finns tre Indexer-komponenter:

• Indexeragent - Agenten övervakar nätverket och Indexerens egen infrastruktur och hanterar vilka subgraph-distributioner som indexeras och tilldelas på kedjan och hur mycket som tilldelas till varje.

• Indexertjänst - Den enda komponenten som behöver exponeras externt, tjänsten vidarebefordrar subgraph-förfrågningar till grafnoden, hanterar tillståndskanaler för förfrågningsbetalningar, delar viktig beslutsinformation till klienter som gatewayer.

• Indexer CLI - Kommandoradsgränssnittet för att hantera Indexeragenten. Det gör det möjligt för Indexers att hantera kostnadsmodeller, manuella tilldelningar, kö för åtgärder och indexregler.

Indexer-agent och Indexer-service bör placeras tillsammans med din Graph Node-infrastruktur. Det finns många sätt att konfigurera virtuella exekveringsmiljöer för dina Indexer-komponenter; här förklarar vi hur du kör dem på bare-metal med hjälp av NPM-paket eller källkod, eller via Kubernetes och Docker på Google Cloud Kubernetes Engine. Om dessa installations exempel inte passar bra för din infrastruktur kommer det sannolikt att finnas en gemenskapsråd att använda som referens, kom och säg hej på Discord! Kom ihåg att satsa på protokollet innan du startar dina Indexer-komponenter!

npm install -g @graphprotocol/indexer-service
npm install -g @graphprotocol/indexer-agent

# Indexer CLI är ett plugin för Graph CLI, så båda måste installeras:
npm install -g @graphprotocol/graph-cli
npm install -g @graphprotocol/indexer-cli

# Indexeringstjänst
graph-indexer-service start ...

# Indexerare agent
graph-indexer-agent start ...

# CLI för indexerare
#Vidarebefordra porten till din agent-pod om du använder Kubernetes
kubectl port-forward pod/POD_ID 18000:8000
graph indexer connect http://localhost:18000/
graph indexer ...

# Från Repos rotkatalog
yarn

# Indexeringstjänst
cd packages/indexer-service
./bin/graph-indexer-service start ...

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

• Hämta bilder från registret

docker pull ghcr.io/graphprotocol/indexer-service:latest
docker pull ghcr.io/graphprotocol/indexer-agent:latest

Eller skapa bilder lokalt från källkod

# 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 \

• Kör komponenterna

docker run -p 7600:7600 -it indexer-service:latest ...
docker run -p 18000:8000 -it indexer-agent:latest ...

OBS: Efter att ha startat containrarna bör Indexertjänsten vara åtkomlig på http://localhost:7600 och Indexeragenten bör exponera Indexerhanterings-API:et på http://localhost:18000/.

Se avsnittet Konfigurera serverinfrastruktur med Terraform på 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 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

Indexer CLI är ett insticksprogram för @graphprotocol/graph-cli tillgängligt i terminalen på graph indexer.

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

Det föreslagna verktyget för att interagera med Indexer Management API är Indexer CLI, ett tillägg till Graph CLI. Indexeragenten behöver input från en Indexer för att autonomt interagera med nätverket på Indexers vägnar. Mekanismen för att definiera Indexeragentens beteende är allokeringhantering och indexeringsregler. I automatiskt läge kan en Indexer använda indexeringsregler för att tillämpa sin specifika strategi för att välja subgrafer att indexera och utföra frågor för. Regler hanteras via ett GraphQL API som serveras av agenten och kallas Indexer Management API. I manuellt läge kan en Indexer skapa allokationsåtgärder med åtgärds kö och godkänna dem explicit innan de utförs. I övervakningsläge används indexeringsregler för att fylla åtgärds kö och kräver också explicit godkännande för utförande.

Indexer CLI ansluter till Indexeragenten, vanligtvis via port-vidarebefordran, så CLI behöver inte köras på samma server eller kluster. För att hjälpa dig komma igång och ge lite kontext kommer CLI att beskrivas här kortfattat.

• graph indexer connect <url> - Anslut till Indexerhanterings-API:et. Vanligtvis öppnas anslutningen till servern via port-vidarebefordran, så CLI kan enkelt användas fjärrstyras. (Exempel: kubectl port-forward pod/<indexer-agent-pod> 8000:8000)

• graph indexer rules get [options] <deployment-id> [<key1> ...] - Hämta en eller flera indexeringsregler med all som <deployment-id> för att hämta alla regler, eller global för att hämta de globala standardvärdena. Ett ytterligare argument --merged kan användas för att ange att regler specifika för distributionen slås samman med den globala regeln. Detta är hur de tillämpas i Indexeragenten.

• graph indexer rules set [options] <deployment-id> <key1> <value1> ... - Ange en eller flera indexeringsregler.

• graph indexer rules start [options] <deployment-id> - Starta indexering av en subgraph-distribution om den är tillgänglig och ange dess decisionBasis till always, så kommer Indexeragenten alltid att välja att indexera den. Om den globala regeln är inställd på always kommer alla tillgängliga subgrafer på nätverket att indexeras.

• graph indexer rules stop [options] <deployment-id> - Stoppa indexeringen av en distribution och ange dess decisionBasis till never, så kommer den att hoppa över den här distributionen när den beslutar om distributioner att indexera.

• graph indexer rules maybe [options] <deployment-id> — Ange decisionBasis för en distribution till rules, så kommer Indexeragenten att använda indexeringsregler för att avgöra om den ska indexera den här distributionen.

• graph indexer actions get [options] <action-id> - Hämta en eller flera åtgärder med all eller lämna action-id tomt för att hämta alla åtgärder. Ett ytterligare argument --status kan användas för att skriva ut alla åtgärder med en viss status.

• graph indexer action queue allocate <deployment-id> <allocation-amount> - Köa allokationsåtgärd

• graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount> - Köa omallokeringsåtgärd

• graph indexer action queue unallocate <deployment-id> <allocation-id> - Köa avallokeringsåtgärd

• graph indexer actions cancel [<action-id> ...] - Avbryt alla åtgärder i kön om id inte anges, annars avbryt arrayen med id med mellanslag som separator

• graph indexer actions approve [<action-id> ...] - Godkänn flera åtgärder för utförande

• graph indexer actions execute approve - Tvinga arbetaren att omedelbart utföra godkända åtgärder

Alla kommandon som visar regler i utdata kan välja mellan de stödda utdataformaten (table, yaml och json) med hjälp av argumentet -output.

Indexeringsregler kan antingen tillämpas som globala standardvärden eller för specifika subgraph-distributioner med deras ID. Fälten deployment och decisionBasis är obligatoriska, medan alla andra fält är valfria. När en indexeringsregel har rules som decisionBasis, jämför Indexeragenten tröskelvärden som inte är null på den regeln med värden som hämtas från nätverket för den motsvarande distributionen. Om subgraph-distributionen har värden över (eller under) någon av tröskelvärdena kommer den att väljas för indexering.

Till exempel, om den globala regeln har en minStake på 5 (GRT), kommer vilken subgraph-distribution som helst som har mer än 5 (GRT) satsat på den att indexeras. Tröskelregler inkluderar maxAllocationPercentage, minSignal, maxSignal, minStake och minAverageQueryFees.

Datamodell:

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
}

Exempel på användning av indexeringsregel:

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

Indexer-cli tillhandahåller ett actions-modul för manuellt arbete med åtgärds kön. Det använder Graphql API som hostas av indexeringshanteringsservern för att interagera med åtgärds kön.

Åtgärdsutförande-arbetaren kommer endast att hämta objekt från kön för att utföra om de har ActionStatus = approved. På den rekommenderade vägen läggs åtgärder till i kön med ActionStatus = queued, så de måste sedan godkännas för att utföras på kedjan. Den generella flödet kommer att se ut som följer:

• Åtgärd läggs till i kön av tredjeparts-optimeringsverktyget eller indexer-cli-användaren
• Indexer kan använda indexer-cli för att visa alla köade åtgärder
• Indexer (eller annan programvara) kan godkänna eller avbryta åtgärder i kön med hjälp av indexer-cli. Godkänn och avbryt kommandon tar en matris av åtgärds-id som inmatning.
• Utförande-arbetaren kollar regelbundet kön för godkända åtgärder. Den hämtar de approved åtgärderna från kön, försöker utföra dem och uppdaterar värdena i databasen beroende på utförandestatus till success eller failed.
• Om en åtgärd är framgångsrik kommer arbetaren att se till att det finns en indexeringsregel som berättar för agenten hur allokeringen ska hanteras framöver, användbart när man tar manuella åtgärder medan agenten är i auto eller oversight -läge.
• Indexer kan övervaka åtgärds kön för att se en historia över åtgärdsutförande och om det behövs godkänna om och uppdatera åtgärdsobjekt om de misslyckades med utförande. Åtgärds kön ger en historia över alla köade och tagna åtgärder.

Datamodell:

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
}

Exempel på användning från källa:

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

Observera att åtgärdstyper som stöds för allokeringshantering har olika krav på indata:

• Tilldela - allokera insats till en specifik subgraph-deploering

  • obligatoriska åtgärdsparametrar:
    • deploymentID
    • belopp

• Avslå - stäng allokeringen och frigör insatsen för omallokering någon annanstans

  • obligatoriska åtgärdsparametrar:
    • allocationID
    • deploymentID
  • valfria åtgärdsparametrar:
    • poi
    • force (tvingar användning av den angivna POI även om den inte matchar det som grafnoden tillhandahåller)

• Omallokera - atomiskt stäng allokeringen och öppna en ny allokering för samma subgraph-deploering

  • obligatoriska åtgärdsparametrar:
    • allocationID
    • deploymentID
    • belopp
  • valfria åtgärdsparametrar:
    • poi
    • force (tvingar användning av den angivna POI även om den inte matchar det som grafnoden tillhandahåller)

Kostnadsmodeller tillhandahåller dynamisk prissättning för frågor baserat på marknaden och frågans egenskaper. Indexer Service delar en kostnadsmodell med gatewayerna för varje subgraph för vilka de avser att svara på frågor. Gatewayerna använder i sin tur kostnadsmodellen för att fatta beslut om indexeringsval per fråga och för att förhandla om betalning med valda indexers.

Agora-språket ger ett flexibelt format för deklaration av kostnadsmodeller för frågor. En Agora-prismodell är en sekvens av uttalanden som utförs i ordning för varje toppnivåfråga i en GraphQL-fråga. För varje toppnivåfråga avgör det första uttalandet som matchar den priset för den frågan.

Ett uttalande består av en predikat, som används för att matcha GraphQL-frågor, och ett kostnadsuttryck som när det utvärderas ger en kostnad i decimal GRT. Värden i den namngivna argumentpositionen i en fråga kan fångas i predikatet och användas i uttrycket. Globala variabler kan också sättas och ersättas för platshållare i ett uttryck.

Exempel kostnadsmodell:

# Detta uttalande fångar skip-värdet,
# använder ett booleskt uttryck i predikatet för att matcha specifika frågor som använder `skip`
# och ett kostnadsuttryck för att beräkna kostnaden baserat på `skip`-värdet och den globala SYSTEM_LOAD
query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;

# Denna standard matchar alla GraphQL-uttryck.
# Den använder en Global som ersatts i uttrycket för att beräkna kostnaden
default => 0.1 * $SYSTEM_LOAD;

Exempel på kostnadskalkyl enligt ovanstående modell:

Kostnadsmodeller tillämpas via Indexer CLI, som skickar dem till Indexer Management API för Indexer agent för lagring i databasen. Indexer Service kommer sedan att hämta dem och servera kostnadsmodellerna till gatewayerna när de begär dem.

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

De första stegen för att delta i nätverket som en Indexer är att godkänna protokollet, satsa medel och (valfritt) sätta upp en operatörsadress för dagliga protokollinteraktioner. _ Observera: För dessa instruktioner används Remix för kontraktsinteraktion, men använd gärna din valfria verktyg (OneClickDapp, ABItopic och MyCrypto är några andra kända verktyg)._

När en Indexer har satsat GRT i protokollet kan Indexer-komponenterna startas och börja interagera med nätverket.

1. Öppna Remix-appen i en webbläsare

2. I Filutforskaren skapa en fil med namnet GraphToken.abi med token ABI.

3. Med GraphToken.abi markerad och öppen i redigeraren, växla till avsnittet Implementera och Kör transaktioner i Remix-gränssnittet.

4. Under miljö väljer du Injected Web3 och under Konto väljer du din Indexer-adress.

5. Ange kontraktadressen för GraphToken - Klistra in kontraktadressen för GraphToken (0xc944E90C64B2c07662A292be6244BDf05Cda44a7) bredvid Vid adress och klicka på knappen Vid adress för att tillämpa.

6. Anropa funktionen approve(spender, amount) för att godkänna Staking-kontraktet. Fyll i spender med Staking-kontraktadressen (0xF55041E37E12cD407ad00CE2910B8269B01263b9) och amount med de tokens som ska satsas (i wei).

1. Öppna Remix-appen i en webbläsare

2. I Filutforskaren skapa en fil med namnet Staking.abi med stakings ABI.

3. Med Staking.abi markerad och öppen i redigeraren, växla till avsnittet Implementera och Kör transaktioner i Remix-gränssnittet.

4. Under miljö väljer du Injected Web3 och under Konto väljer du din Indexer-adress.

5. Ange kontraktadressen för Staking - Klistra in kontraktadressen för Staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9) bredvid Vid adress och klicka på knappen Vid adress för att tillämpa.

6. Anropa stake() för att satsa GRT i protokollet.

7. (Valfritt) Indexers kan godkänna en annan adress att vara operatör för sin Indexer-infrastruktur för att separera de nycklar som kontrollerar medlen från de som utför dagliga åtgärder som att tilldela på subgrafer och servera (betalda) frågor. För att ställa in operatören anropas setOperator() med operatörsadressen.

8. (Valfritt) För att kontrollera fördelningen av belöningar och strategiskt attrahera Delegators kan Indexers uppdatera sina delegationsparametrar genom att uppdatera sina indexingRewardCut (delar per miljon), queryFeeCut (delar per miljon) och cooldownBlocks (antal block). För att göra detta, anropa setDelegationParameters(). Följande exempel anger queryFeeCut för att fördela 95% av frågebidragen till Indexer och 5% till Delegators, ställ indexingRewardCut för att fördela 60% av indexbelöningarna till Indexer och 40% till Delegators, och ställ in perioden för thecooldownBlocks till 500 block.

setDelegationParameters(950000, 600000, 500)

Efter att ha skapats av en Indexer går en sund allokering igenom fyra tillstånd.

• Aktiv - När en allokering skapas på kedjan (allocateFrom()) betraktas den som aktiv. En del av Indexerens egen och/eller delegerad insats allokeras till en subgraph-deployering, vilket möjliggör att de kan hävda indexbelöningar och tjäna frågor för den subgraph-deployeringen. Indexer-agenten hanterar skapandet av allokeringar baserat på Indexer-reglerna.

• Stängd - En Indexer är fri att stänga en allokering när 1 epoch har passerat (closeAllocation()) eller deras Indexer-agent kommer automatiskt att stänga allokeringen efter den maxAllocationEpochs (för närvarande 28 dagar). När en allokering stängs med ett giltigt bevis för indexering (POI) fördelas deras indexbelöningar till Indexer och dess Delegators (se "hur fördelas belöningar?" nedan för att lära dig mer).

Det rekommenderas att Indexers använder funktionen för offchain-synkronisering för att synkronisera subgraph-deploys till kedjehuvudet innan de skapar allokeringen på kedjan. Den här funktionen är särskilt användbar för subgraphs som kan ta längre tid än 28 epoker att synkronisera eller har vissa chanser att misslyckas obestämt.