Indexing

Reading time: 23 min

İndeksleyiciler, indeksleme ve sorgu işleme hizmetleri sağlamak için Graph Token'leri (GRT) stake eden Graph Ağındaki düğüm operatörleridir. İndeksleyiciler, hizmetleri karşılığında sorgu ücretleri ve indeksleme ödülleri kazanırlar. Ayrıca üstel bir indirim fonksiyonuna göre geri ödenen sorgu ücretleri de kazanırlar.

GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.

Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.

The minimum stake for an Indexer is currently set to 100K GRT.

Query fee rebates - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.

Indexing rewards - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.

Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.

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.

POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.

Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).

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

Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:

1. Query the mainnet subgraph to get the IDs for all active allocations:

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

Use Etherscan to call getRewards():

• Navigate to Etherscan interface to Rewards contract

• To call getRewards():
  • Expand the 9. getRewards dropdown.
  • Enter the allocationID in the input.
  • Click the Query button.

Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.

Disputes have three possible outcomes, so does the deposit of the Fishermen.

• If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
• If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
• If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.

Disputes can be viewed in the UI in an Indexer's profile page under the Disputes tab.

Sorgu ücretleri ağ geçidi tarafından toplanır ve üstel indirim fonksiyonuna göre indeksleyicilere dağıtılır (buradan GIP'e bakınız). Üstel indirim fonksiyonu, indeksleyicilerin sorguları dürüstçe sunarak en iyi sonucu elde etmelerini sağlamanın bir yolu olarak önerilmiştir. İndeksleyicileri, toplayabilecekleri sorgu ücretlerine göre büyük miktarda pay (bir sorguya hizmet verirken hata yaptıklarında kesinti olabilir) ayırmaya teşvik ederek çalışmaktadır.

Bir tahsisat kapatıldıktan sonra iadeler İndeksleyici tarafından talep edilebilir. Talep edildikten sonra, sorgu ücreti iadeleri, sorgu ücreti kesintisi ve üstel indirim fonksiyonuna göre İndeksleyiciye ve Delegatörlerine dağıtılır.

The queryFeeCut and indexingRewardCut values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in Staking in the Protocol for instructions on setting the delegation parameters.

• queryFeeCut - İndeksleyiciye dağıtılacak sorgu ücreti iadelerinin %'si. Bu %95 olarak ayarlanırsa, İndeksleyici bir tahsisat kapatıldığında kazanılan sorgu ücretlerinin %95'ini alır ve diğer %5'lik kısım Delegatörlere gider.

• indexingRewardCut - İndeksleyiciye dağıtılacak indeksleme ödüllerinin %'si. Bu, %95 olarak ayarlanırsa, indeksleyici, bir tahsis kapatıldığında indeksleme ödül havuzunun %95'ini alacak ve delegatörler diğer %5'i bölüşecektir.

Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:

• Curation signal - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.

• Query fees collected - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.

• Stake edilen miktar - Diğer İndeksleyicilerin davranışlarını izlemek veya belirli subgraphlara tahsis edilen toplam stake oranlarına bakmak, bir İndeksleyicinin subgraph sorgularına yönelik arz tarafını izlemesine olanak tanır; böylece ağın güvendiği subgraphları veya daha fazla arz ihtiyacı olabilecek subgraphları belirlemesine yardımcı olur.

• İndeksleme ödülü olmayan subgraphlar - Bazı subgraphlar, IPFS gibi desteklenmeyen özellikleri kullandıkları veya ana ağ dışında başka bir ağı sorguladıkları için indeksleme ödülü üretmezler. İndeksleme ödülleri üretmeyen bir subgraph üzerinde bir mesaj göreceksiniz.

• Düşük - Birkaç subgraph'ı indekslemeye başlamak için yeterli, muhtemelen genişletilmesi gerekecek.
• Standart - Varsayılan kurulum, örnek k8s/terraform dağıtım manifestlerinde kullanılan budur.
• Orta - 100 subgraph ve saniyede 200-500 isteği destekleyen Üretim İndeksleyici.
• Yüksek - Şu anda kullanılan tüm subgraphları indekslemek ve ilgili trafik için istekleri sunmak için hazırlanmıştır.

• Operatör cüzdanı - Bir operatör cüzdanı oluşturmak önemli bir önlemdir, çünkü bir İndeksleyicinin stake'i kontrol eden anahtarları ile günlük işlemleri kontrol eden anahtarları arasında ayrım yapmasına olanak tanır. Talimatlar için Protokolde Stake bölümüne bakın.

• Firewall - Yalnızca İndeksleyici hizmetinin herkese açık olması gerekir ve yönetici bağlantı noktalarının ve veritabanı erişiminin kilitlenmesine özellikle dikkat edilmelidir: Graph Node JSON-RPC uç noktası (varsayılan bağlantı noktası: 8030), İndeksleyici yönetim API uç noktası (varsayılan bağlantı noktası: 18000) ve Postgres veritabanı uç noktası (varsayılan bağlantı noktası: 5432) herkese açık olmamalıdır.

Bir İndeksleyicinin altyapısının merkezinde, indekslenen ağları izleyen, bir subgraph tanımına göre verileri ayıklayan, yükleyen ve GraphQL API olarak sunan Graph Düğümü yer alır. Graph Düğümü'nün, her bir indekslenmiş ağdan gelen verileri açığa çıkaran bir uç noktaya; veri kaynağı için bir IPFS düğümüne; deposu için bir PostgreSQL veritabanına ve ağ ile etkileşimlerini kolaylaştıran İndeksleyici bileşenlerine bağlanması gerekir.

• PostgreSQL veritabanı - Graph Düğümü için ana depo, subgraph verilerinin depolandığı yerdir. İndeksleyici hizmeti ve aracı da durum kanalı verilerini, maliyet modellerini, indeksleme kurallarını ve tahsis eylemlerini depolamak için veritabanını kullanır.

• Veri uç noktası - EVM uyumlu ağlar için, Graph Düğümü'nün EVM uyumlu bir JSON-RPC API'si sunan bir uç noktaya bağlanması gerekir. Bu, tek bir istemci şeklinde olabileceği gibi birden fazla istemci arasında yük dengelemesi yapan daha karmaşık bir kurulum da olabilir. Belirli subgraphlar'ın arşiv modu ve/veya parite izleme API'si gibi belirli istemci yetenekleri gerektireceğinin bilincinde olmak önemlidir.

• IPFS düğümü (sürüm 5'ten düşük) - Subgraph dağıtım üst verisi IPFS ağında saklanır. Graph Düğümü, subgraph manifesti ve tüm bağlantılı dosyaları almak için subgraph dağıtımı sırasında öncelikle IPFS düğümüne erişir. Ağ İndeksleyicilerinin kendi IPFS düğümlerini barındırmalarına gerek yoktur, ağ için bir IPFS düğümü https://ipfs.network.thegraph.com adresinde barındırılır.

• İndeksleyici hizmeti - Ağ ile gerekli tüm harici iletişimleri gerçekleştirir. Maliyet modellerini ve indeksleme durumlarını paylaşır, ağ geçitlerinden gelen sorgu isteklerini bir Graph Düğümü'ne iletir ve ağ geçidi ile durum kanalları aracılığıyla sorgu ödemelerini yönetir.

• İndeksleyici aracı - Ağa kaydolma, Graph Düğümlerine subgraph dağıtımlarını ve tahsisleri yönetme dahil olmak üzere İndeksleyicilerin zincir üzerindeki etkileşimlerini kolaylaştırır.

• Prometheus metrik sunucusu - Graph Düğümü ve İndeksleyici bileşenleri metriklerini metrik sunucusuna kaydeder.

Not: Çevik ölçeklendirmeyi desteklemek için, sorgulama ve indeksleme endişelerinin sorgu düğümleri ve indeks düğümleri olarak farklı düğüm kümeleri arasında ayrılması önerilir.

• Google Cloud SDK
• Kubectl komut satırı aracı
• Terraform

• Clone or navigate to the Indexer repository.

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

cd terraform

• Google Cloud ile kimlik doğrulaması yapın ve yeni bir proje oluşturun.

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

• Yeni projenin faturalandırılmasını etkinleştirmek için Google Cloud Console'un faturalandırma sayfasını kullanın.

• Bir Google Cloud yapılandırması oluşturun.

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

• Gerekli Google Cloud API'lerini etkinleştirin.

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

• Bir hizmet hesabı oluşturun.

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

• Bir sonraki adımda oluşturulacak veritabanı ve Kubernetes kümesi arasında eşlemeyi etkinleştirin.

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

• Create minimal terraform configuration file (update as needed).

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

Herhangi bir komutu çalıştırmadan önce variables.tf dosyasını okuyun ve bu dizinde bir terraform.tfvars dosyası oluşturun (veya son adımda oluşturduğumuzu değiştirin). Varsayılanı geçersiz kılmak istediğiniz veya bir değer ayarlamanız gereken her değişken için terraform.tfvars dosyasına bir ayar girin.

• Altyapıyı oluşturmak için aşağıdaki komutları çalıştırın.

# 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

Yeni kümenin kimlik bilgilerini ~/.kube/config dosyasına indirin ve varsayılan bağlamınız olarak ayarlayın.

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

• k8s/overlays dizinini yeni bir $dir, dizinine kopyalayın ve $dir/kustomization.yaml içindeki bases girişini k8s/base dizinini gösterecek şekilde ayarlayın.

• $dir içindeki tüm dosyaları okuyun ve yorumlarda belirtilen değerleri ayarlayın.

Tüm kaynakları kubectl apply -k $dir ile dağıtın.

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

• Ubuntu kullanıcıları için Ek Gereksinimler - Ubuntu üzerinde bir Graph Düğümü çalıştırmak için birkaç ek paket gerekebilir.

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

1. Bir PostgreSQL veritabanı sunucusu başlatma

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

2. Graph Düğümü github deposunu klonlayın ve cargo build çalıştırarak kaynağı derleyin

3. Artık tüm bağımlılıklar ayarlandığına göre Graph Düğümü'nü başlatın:

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 düğümü - Varsayılan olarak, docker oluşturma kurulumu ana makinenizdeki Ethereum düğümüne bağlanmak için ana ağı kullanacaktır:http://host.docker.internal:8545. Bu ağ adını ve url'yi docker-compose.yaml dosyasını güncelleyerek değiştirebilirsiniz.

1. Graph Düğümü'nü klonlayın ve Docker dizinine gidin:

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

2. Yalnızca linux kullanıcıları için - docker-compose.yaml dosyasında host.docker.internal yerine ana IP adresini kullanın:

./setup.sh

3. Ethereum uç noktanıza bağlanacak yerel bir Graph Düğümü başlatın:

docker-compose up

Ağa başarılı bir şekilde katılmak hemen hemen sürekli izleme ve etkileşim gerektirir, bu nedenle İndeksleyicilerin ağa katılımını kolaylaştırmak için bir dizi Typescript uygulaması oluşturduk. Üç İndeksleyici bileşeni bulunmaktadır:

• İndeksleyici aracısı - Aracı, ağı ve İndeksleyicinin kendi altyapısını izler ve hangi subgraph dağıtımlarının indekslendiğini, zincir üzerinde tahsis edildiğini ve her birine ne miktarda tahsis edildiğini yönetir.

• İndeksleyici hizmeti - Harici olarak gösterilmesi gereken tek bileşen olan hizmet, subgraph sorgularını graph düğümüne iletir, sorgu ödemeleri için durum kanallarını yönetir ve istemcilerle ağ geçitleri gibi önemli karar verme bilgilerini paylaşır.

• İndeksleyici CLI'si - İndeksleyici aracısını yönetmek için komut satırı arayüzüdür. İndeksleyicilerin maliyet modellerini, manuel tahsislerini, eylem kuyruğunu ve indeksleme kurallarını yönetmesini sağlar.

İndeksleyici aracısı ve İndeksleyici hizmeti, Graph Düğümü altyapınızla birlikte konumlandırılmalıdır. İndeksleyici bileşenleriniz için sanal yürütme ortamları kurmanın birçok yolu vardır; burada bunları NPM paketleri veya kaynak kullanarak baremetal üzerinde veya Google Cloud Kubernetes Motoru üzerinde kubernetes ve docker aracılığıyla nasıl çalıştıracağınızı açıklayacağız. Bu kurulum örnekleri altyapınıza iyi bir şekilde uyarlanamazsa, muhtemelen başvurabileceğiniz bir topluluk rehberi olacaktır, gelin Discord'da merhaba deyin! İndeksleyici bileşenlerinizi başlatmadan önce protokolde stake etmeyi unutmayın!

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

• Kayıt defterinden görüntüleri çekin

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

Veya görüntüleri yerel olarak kaynaktan oluşturun

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

• Komponentleri çalıştırın

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

NOT: Konteynerleri(containers) başlattıktan sonra, İndeksleyici hizmetine http://localhost:7600 adresinden erişilebilmeli ve İndeksleyici aracısı http://localhost:18000/ adresinden İndeksleyici yönetim API'sini sunabilmelidir.

Google Cloud'da Terraform Kullanarak Sunucu Altyapısı Kurma bölümüne bakın

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

İndeksleyici CLI, graph indexer terminalinden erişilebilen @graphprotocol/graph-cli için bir eklentidir.

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

İndeksleyici Yönetim API'si ile etkileşim için önerilen araç, Graph CLI'nın bir uzantısı olan İndeksleyici CLI'dır. İndeksleyici aracısı, İndeksleyici adına ağ ile bağımsız olarak etkileşim kurmak için bir İndeksleyiciden gelen girdiye ihtiyaç duyar. İndeksleyici aracı davranışını tanımlama mekanizması tahsis yönetim modu ve indeksleme kurallarıdır. Otomatik modda, bir İndeksleyici, sorguları indekslemek ve sunmak üzere subgraph'ları seçmek için kendi özel stratejisini uygulamak üzere indeksleme kurallarını kullanabilir. Kurallar, aracı tarafından sunulan ve İndeksleyici Yönetim API'si olarak bilinen bir GraphQL API aracılığıyla yönetilir. Manuel modda, bir İndeksleyici eylem kuyruğunu kullanarak tahsis eylemleri oluşturabilir ve yürütülmeden önce bunları açıkça onaylayabilir. Gözetim modunda, indeksleme kuralları eylem kuyruğunu doldurmak için kullanılır ve ayrıca yürütme için açık onay gerektirir.

İndeksleyici CLI, tipik olarak bağlantı noktası yönlendirme yoluyla İndeksleyici aracısına bağlanır, bu nedenle CLI'nın aynı sunucuda veya kümede çalışması gerekmez. Başlamanıza yardımcı olmak ve biraz bilgi vermek için CLI burada kısaca açıklanacaktır.

• graph indexer connect <url> - İndeksleyici yönetim API'sine bağlanın. Tipik olarak sunucuya bağlantı port yönlendirme yoluyla açılır, böylece CLI uzaktan kolayca çalıştırılabilir. (Örnek: kubectl port-forward pod/<indexer-agent-pod> 8000:8000)

• graph indexer rules get [options] <deployment-id> [<key1> ...] - Tüm kuralları almak için <deployment-id> olarak all veya genel varsayılanları almak için global kullanarak bir veya daha fazla indeksleme kuralı alın. Dağıtıma özgü kuralların genel kuralla birleştirileceğini belirtmek için bir --merged ek bağımsız değişkeni kullanılabilir. Bu şekilde, indeksleyici aracısında uygulanırlar.

• graph indexer rules set [options] <deployment-id> <key1> <value1> ... - Bir veya daha fazla indeksleme kuralı ayarlayın.

• graph indexer rules start [options] <deployment-id> - Varsa bir subgraph dağıtımını indekslemeye başlayın ve decisionBasis değerini always olarak ayarlayın, böylece İndeksleyici aracı her zaman onu indekslemeyi seçecektir. Genel kural her zaman olarak ayarlanırsa, ağdaki mevcut tüm subgraphlar indekslenecektir.

• graph indexer rules stop [options] <deployment-id> - Bir dağıtımı indekslemeyi durdurun ve decisionBasis değerini never olarak ayarlayın, böylece indekslenecek dağıtımlara karar verirken bu dağıtımı atlayacaktır.

• graph indexer rules maybe [options] <deployment-id> — Bir dağıtım için decisionBasis öğesini rules olarak ayarlayın, böylece İndeksleyici aracısı bu dağıtımı indeksleyip indekslemeyeceğine karar vermek için indeksleme kurallarını kullanacaktır.

• 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> - Kuyruk tahsis eylemi

• graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount> - Kuyruk yeniden tahsis eylemi

• graph indexer action queue unallocate <deployment-id> <allocation-id> - Kuyruk tahsis kaldırma eylemi

• graph indexer actions cancel [<action-id> ...] - id(kimlik) belirtilmemişse kuyruktaki tüm eylemleri iptal eder, aksi takdirde ayırıcı olarak boşluk içeren id dizisini iptal eder

• graph indexer actions approve [<action-id> ...] - Yürütme için birden fazla eylemi onaylama

• graph indexer actions execute approve - Çalışanı onaylanan eylemleri derhal gerçekleştirmeye zorlama

Çıktıda kuralları görüntüleyen tüm komutlar, -output argümanını kullanarak desteklenen çıktı formatları (table, yaml, and json) arasında seçim yapabilir.

İndeksleme kuralları genel varsayılanlar olarak ya da ID'leri kullanılarak belirli subgraph dağıtımları için uygulanabilir. Diğer tüm alanlar isteğe bağlı iken deployment ve decisionBasis alanları zorunludur. Bir indeksleme kuralı decisionBasis olarak rules'a sahipse, indeksleyici aracı bu kuraldaki boş olmayan eşik değerlerini ilgili dağıtım için ağdan alınan değerlerle karşılaştıracaktır. Subgraph dağıtımı, eşik değerlerden herhangi birinin üstünde (veya altında) değerlere sahipse, indeksleme için seçilecektir.

Örneğin, genel kuralın minStake değeri 5 (GRT) ise, kendisine 5 (GRT)'den fazla pay tahsis edilen tüm subgraph dağıtımları indekslenecektir. Eşik kuralları arasında maxAllocationPercentage, minSignal, maxSignal, minStake, ve minAverageQueryFees yer alır.

Veri modeli:

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
}

İndeksleme kuralı örnek kullanımı:

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, eylem kuyruğu ile manuel olarak çalışmak için bir actions modülü sağlar. Eylem kuyruğu ile etkileşim kurmak için indeksleyici yönetim sunucusu tarafından barındırılan Graphql API'sini kullanır.

Eylem yürütme çalışanı, yalnızca ActionStatus = approved değerine sahipse yürütmek için kuyruktan öğeleri alır. Önerilen yolda eylemler ActionStatus = queued ile kuyruğa eklenir, bu nedenle zincir üzerinde yürütülmeleri için onaylanmaları gerekir. Genel işleyiş şu şekilde olacaktır:

• Kuyruğa üçüncü şahıs optimizasyon aracı veya indexer-cli kullanıcısı tarafından eklenen eylem
• İndeksleyici, sıraya alınan tüm eylemleri görüntülemek için indexer-cli'yi kullanabilir
• İndeksleyici (veya diğer yazılımlar) indexer-cli kullanarak kuyruktaki eylemleri onaylayabilir veya iptal edebilir. Onaylama ve iptal etme komutları girdi olarak bir dizi eylem kimliği alır.
• Yürütme çalışanı, onaylanan eylemler için kuyruğu düzenli olarak tarar. Kuyruktanapproved eylemleri alır, bunları yürütmeye çalışır ve yürütme durumuna bağlı olarak db'deki değerleri success veya failed olarak günceller.
• Eğer bir eylem başarılı olursa, çalışan, aracı auto veya oversight modunda manuel eylemler gerçekleştirirken yararlı olacak şekilde, aracıya tahsisi ileriye dönük olarak nasıl yöneteceğini söyleyen bir indeksleme kuralının mevcut olmasını sağlayacaktır.
• İndeksleyici, eylem yürütme geçmişini görmek için eylem kuyruğunu izleyebilir ve gerekirse yürütmede başarısız olan eylem öğelerini yeniden onaylayabilir ve güncelleyebilir. Eylem kuyruğu, kuyruğa alınan ve gerçekleştirilen tüm eylemlerin bir geçmiş kaydını sağlar.

Veri modeli:

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
}

Kaynaktan kullanım örneği:

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

Tahsis yönetimi için desteklenen eylem türlerinin farklı girdi gereksinimleri olduğunu unutmayın:

• Allocate - stake'i belirli bir subgraph dağıtımına tahsis eder

  • gerekli eylem parametreleri:
    • deploymentID
    • amount

• Unallocate - tahsisi kapatır, stake'i başka bir yere yeniden tahsis etmek için serbest bırakır

  • gerekli eylem parametreleri:
    • allocationID
    • deploymentID
  • opsiyonel eylem parametreleri:
    • poi
    • force (graph-node'un sağladığıyla uyuşmasa bile sağlanan POI'yi kullanmaya zorlar)

• Reallocate - tahsisi atomik olarak kapatır ve aynı subgraph dağıtımı için yeni bir tahsis açar

  • gerekli eylem parametreleri:
    • allocationID
    • deploymentID
    • amount
  • opsiyonel eylem parametreleri:
    • poi
    • force (graph-node'un sağladığıyla uyuşmasa bile sağlanan POI'yi kullanmaya zorlar)

Maliyet modelleri, pazar ve sorgu niteliklerine dayalı olarak sorgular için dinamik fiyatlandırma sağlar. İndeksleyici Hizmeti, sorgulara yanıt vermeyi amaçladıkları her bir subgraph için ağ geçitleriyle bir maliyet modeli paylaşır. Ağ geçitleri de sorgu başına İndeksleyici seçim kararları vermek ve seçilen İndeksleyicilerle ödeme pazarlığı yapmak için maliyet modelini kullanır.

Agora dili, sorgular için maliyet modellerini bildirmek için esnek bir format sağlar. Agora fiyat modeli, bir GraphQL sorgusundaki her üst düzey sorgu için sırayla çalışan bir deyimler serisidir. Her üst düzey sorgu için, onunla eşleşen ilk ifade o sorgunun fiyatını belirler.

Bir ifade, GraphQL sorgularını eşleştirmek için kullanılan bir evet-hayır sorusundan ve değerlendirildiğinde GRT cinsinden ondalık maliyet çıktısı veren bir maliyet ifadesinden oluşur. Bir sorgunun adlandırılmış argüman konumundaki değerleri evet-hayır sorusunda yakalanabilir ve ifadede kullanılabilir. Ayrıca, genel değerler de ayarlanabilir ve bir ifadedeki yer tutucuların yerine kullanılabilir.

Örnek maliyet modeli:

# Bu ifade atlama değerini yakalar,
# `skip` kullanan belirli sorguları eşleştirmek için evet-hayır sorusunda bir boolean ifadesi kullanır
# `skip` değerine ve SYSTEM_LOAD genel değerine dayalı olarak maliyeti hesaplamak için bir maliyet ifadesi
query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;

# Bu varsayılan, herhangi bir GraphQL ifadesiyle eşleşecektir.
# Maliyeti hesaplamak için ifadenin içine yerleştirilmiş bir Global (genel) kullanır
default => 0.1 * $SYSTEM_LOAD;

Yukarıdaki modeli kullanarak örnek sorgu maliyetlendirmesi:

Maliyet modelleri, onları veritabanında saklanmak üzere İndeksleyici aracısının İndeksleyici Yönetim API'sine aktaran İndeksleyici CLI aracılığıyla uygulanır. İndeksleyici Hizmeti daha sonra bunları alır ve maliyet modellerini istedikleri zaman ağ geçitlerine sunar.

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.

Bir İndeksleyici protokolde GRT'yi stake ettikten sonra, İndeksleyici kompenetleri başlatılabilir ve ağ ile etkileşimlerine başlayabilir.

1. Remix uygulamasını bir tarayıcıda açın

2. File Explorer'da ABI token ile GraphToken.abi adında bir dosya oluşturun.

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

4. Ortam altında Injected Web3'ü seçin ve Account altında İndeksleyici adresinizi seçin.

5. GraphToken sözleşme adresini ayarlayın - GraphToken sözleşme adresini (0xc944E90C64B2c07662A292be6244BDf05Cda44a7) At Address seçeneğinin yanına yapıştırın ve uygulamak için At address düğmesine tıklayın.

6. Staking sözleşmesini onaylamak için approve(spender, amount) fonksiyonunu çağırın. spender'ı Staking sözleşmesi adresiyle (0xF55041E37E12cD407ad00CE2910B8269B01263b9) ve amount'ı stake edilecek tokenlarla (wei cinsinden) doldurun.

1. Remix uygulamasını bir tarayıcıda açın

2. File Explorer'da, Staking ABI ile Staking.abi adında bir dosya oluşturun.

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

4. Ortam altında Injected Web3'ü seçin ve Account altında İndeksleyici adresinizi seçin.

5. Stake sözleşmesi adresini ayarlayın - Stake sözleşmesi adresini (0xF55041E37E12cD407ad00CE2910B8269B01263b9) At address seçeneğinin yanına yapıştırın ve uygulamak için At Address düğmesine tıklayın.

6. GRT'yi protokolde stake etmek için stake() fonksiyonunu çağırın.

7. (Opsiyonel) İndeksleyiciler, fonları kontrol eden anahtarları subgraphlar'da tahsis etme ve (ücretli) sorgular sunma gibi günlük eylemleri gerçekleştiren anahtarlardan ayırmak için başka bir adresi kendi İndeksleyici altyapıları için operatör olarak onaylayabilirler. Operatörü ayarlamak için operatör adresi ile setOperator() fonksiyonunu çağırın.

8. ( Opsiyonel) Ödüllerin dağıtımını kontrol etmek ve Delegatörleri stratejik olarak cezbetmek için İndeksleyiciler, indexingRewardCut (milyon başına parça), queryFeeCut (milyon başına parça) ve cooldownBlocks (blok sayısı) değerlerini güncelleyerek delegasyon parametrelerini güncelleyebilirler. Bunu yapmak için setDelegationParameters() fonksiyonunu çağırın. Aşağıdaki örnek queryFeeCut değerini sorgu indirimlerinin %95'ini İndeksleyiciye ve %5'ini Delegatörlere dağıtacak şekilde ayarlar, indexingRewardCut değerini indeksleme ödüllerinin %60'ını İndeksleyiciye ve %40'ını Delegatörlere dağıtacak şekilde ayarlar ve thecooldownBlocks süresini 500 blok olarak ayarlar.

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

İndeksleyicilerin, zincir üstünde tahsis oluşturmadan önce subgraph dağıtımlarını chainhead ile senkronize etmek için zincir dışı senkronizasyon fonksiyonunu kullanmaları önerilir. Bu özellik bilhassa senkronize edilmesi 28 dönemden daha uzun sürebilecek veya belirsiz bir şekilde başarısız olma ihtimali olan subgraphlar için kullanışlıdır.