Индексирование

Reading time: 23 min

Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.

Токены GRT, которые застейканы в протоколе, подлежат периоду "оттаивания" и могут быть срезаны, если индексаторы являются вредоносными и передают неверные данные приложениям или если они некорректно осуществляют индексирование. Индексаторы также получают вознаграждение за делегированный стейк от делегаторов, внося свой вклад в работу сети.

Индексаторы выбирают подграфы для индексирования на основе сигналов от кураторов, в которых кураторы стейкают токены GRT, чтобы обозначить, какие подграфы являются высококачественными и заслуживают приоритетного внимания. Потребители (к примеру, приложения) также могут задавать параметры, по которым индексаторы обрабатывают запросы к их подграфам, и устанавливать предпочтения по цене за запрос.

Минимальная величина стейка для индексатора в настоящее время установлена ​​на уровне 100 000 GRT.

Query fee rebates - платежи за обслуживание запросов в сети. Эти платежи осуществляются через state каналы между индексатором и межсетевым шлюзом. Каждый запрос от шлюза содержит платеж, а ответ - доказательство достоверности результата запроса.

Indexing rewards. Вознаграждения за индексирование генерируются за счет 3% годовой инфляции в рамках всего протокола и распределяются между индексаторами, индексирующими развертывание подграфов в сети.

Вознаграждения за индексацию поступают от инфляции протокола, которая установлена на 3% в год. Оно распределяется между подграфами в зависимости от соотношения всех сигналов на каждом из них, а затем пропорционально распределяется между индексаторами в зависимости от их выделенного стейка на этом подграфе. Чтобы получить право на вознаграждение, распределение должно быть закрыто достоверным доказательством индексации (POI), соответствующим стандартам, установленным arbitration charter.

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.

POI (подтверждение индексации) используются в сети для проверки того, индексирует ли индексатор назначенные им подграфы. При закрытии распределения необходимо предоставить POI для первого блока текущей эпохи, чтобы это распределение имело право на индексацию наград. POI для блока — это дайджест для всех транзакций хранилища объектов для данного развертывания подграфа до этого блока включительно.

Награды за распределения постоянно накапливаются, пока они активны и распределяются в течение 28 эпох. Награды собираются и распределяются индексаторами после того, как их распределение закрыто. Это делается либо вручную, если индексатор выбирает принудительное закрытие, либо через 28 эпох делегатор может закрыть выделение для индексатора, но это не приводит к вознаграждению. 28 эпох — это максимальное время жизни распределения (сейчас одна эпоха длится ~ 24 часа).

В контракте RewardsManager есть функция getRewards, доступная только для чтения, которую можно использовать, чтобы проверить вознаграждения, ожидающие выплаты за конкретные распределения.

Многие панели мониторинга, созданные сообществом, содержат ожидающие значения вознаграждений, и их можно легко проверить вручную, выполнив следующие действия:

1. Запросите подграф в основной сети, чтобы получить идентификаторы всех активных распределений:

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

Используйте Etherscan для вызова getRewards():

• Перейдите в интерфейсе Etherscan к контракту Rewards

• Чтобы вызвать getRewards():
  • Разверните выпадающее меню 10. getRewards.
  • Введите во входные данные allocationID.
  • Нажмите кнопку Query.

Запросы и распределения индексатора могут быть оспорены на The Graph в течение периода спора. Срок спора варьируется в зависимости от типа спора. Запросы/аттестации имеют 7 эпох спорного окна, тогда как распределения имеют 56 эпох. По истечении этих периодов споры не могут быть открыты ни в отношении выделений, ни в отношении запросов. При открытии спора от Рыбаков требуется депозит в размере не менее 10 000 GRT, который будет заблокирован до завершения спора и принятия решения. Рыбаки — это любые участники сети, которые открывают споры.

У споров есть три возможных исхода, как и у депозита Рыбаков.

• Если спор отклонен, то GRT, внесенные рыбаками, будут сожжены, а оспариваемый индексатор не будет урезан.
• Если спор будет решен в виде ничьей, депозит рыбака будет возвращен, а спорный индексатор не будет урезан.
• Если спор будет принят, GRT, внесенные рыбаками, будут возвращены, спорный индексатор будет урезан, а рыбаки получат 50% от урезанных GRT.

Споры можно просмотреть в пользовательском интерфейсе на странице профиля индексатора на вкладке Disputes.

Плата за запрос взимается шлюзом и распределяется между индексаторами в соответствии с экспоненциальной функцией скидки (см. GIP here). Экспоненциальная функция скидки предлагается как способ гарантии, что индексаторы достигают наилучшего результата за счет добросовестного обслуживания запросов. Это работает, стимулируя индексаторов выделять большую сумму ставки (которая может быть уменьшена за ошибку при обслуживании запроса) относительно суммы комиссии за запрос, которую они могут собрать.

Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.

Значения queryFeeCut и indexingRewardCut — это параметры делегирования, которые индексатор может установить вместе с cooldownBlocks для управления распределением GRT между индексатором и его делегаторами. См. последние шаги в разделе Стейкинг в протоколе, чтобы получить инструкции по настройке параметров делегирования.

• queryFeeCut - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.

• indexingRewardCut - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.

Индексаторы могут отличаться друг от друга, применяя передовые методы принятия решений об индексации подграфов, но чтобы дать общее представление, мы обсудим несколько ключевых показателей, используемых для оценки подграфов в сети:

• Curation signal. Доля сигнала курирования сети, примененного к определенному подграфу, является хорошим индикатором интереса к этому подграфу, особенно на этапе начальной загрузки, когда объём запросов увеличивается.

• Query fees collected. Исторические данные об объеме сборов за запросы, собранные для определенного подграфа, являются хорошим индикатором будущего спроса.

• Amount staked. Наблюдение за поведением других индексаторов или просмотр соотношения общего стейка, выделяемого на конкретные подграфы, может позволить индексатору отслеживать предложение запросов к подграфам, чтобы определить подграфы, к которым сеть проявляет доверие, либо подграфы, которые нуждаются в большем предложении.

• Subgraphs with no indexing rewards. Некоторые подграфы не генерируют вознаграждение за индексирование главным образом потому, что они используют неподдерживаемые функции, такие как IPFS, или потому что они запрашивают другую сеть за пределами основной сети. Вы увидите сообщение в подграфе, если он не генерирует вознаграждение за индексацию.

• Small — достаточно, чтобы начать индексирование нескольких подграфов, вероятно, потребуется его расширение.
• Standard — настройка по умолчанию, это то, что используется в примерах манифестов развертывания k8s/terraform.
• Medium – рабочий индексатор, поддерживающий 100 подграфов и 200–500 запросов в секунду.
• Large – готовность индексировать все используемые в настоящее время подграфы и обслуживать запросы на соответствующий трафик.

• Operator wallet. Настройка кошелька оператора является важной мерой безопасности, поскольку она позволяет индексатору поддерживать разделение между своими ключами, которые контролируют величину стейка, и теми, которые контролируют ежедневные операции. Инструкции см. в разделе Stake in Protocol.

• Firewall. Только служба индексатора должна быть общедоступной, и особое внимание следует уделить блокировке портов администратора и доступа к базе данных: эндпоинт ноды The Graph JSON-RPC (порт по умолчанию: 8030), API эндпоинт для управления индексатором (порт по умолчанию: 18000) и эндпоинт базы данных Postgres (порт по умолчанию: 5432) не должны быть доступны.

В центре инфраструктуры индексатора находится нода the Graph, которая отслеживает индексированные в сети, извлекает и загружает данные в соответствии с определением подграфа и служит в качестве GraphQL API. The Graph Node должна быть подключена к эндпоинту, предоставляющему данные из каждой индексированной сети; к ноде IPFS для получения данных; к базе данных PostgreSQL для своего хранилища; и компонентам индексатора, облегчающим его взаимодействие с сетью.

• PostgreSQL database — основное хранилище для the Graph Node, здесь хранятся данные подграфа. Служба и агент индексатора также используют базу данных для хранения данных о каналах состояний, моделей затрат, правил индексирования и действий по распределению.

• Data endpoint – Для сетей, совместимых с EVM, Graph Node должна быть подключена к эндпоинту, предоставляющему API-интерфейс JSON-RPC, совместимый с EVM. Это может быть как один клиент, так и более сложная конфигурация, которая распределяет нагрузку между несколькими клиентами. Важно знать, что для некоторых подграфов потребуются определенные клиентские возможности, такие как режим архива и/или API для отслеживания четности.

• IPFS node (версия ниже 5) – Метаданные развертывания подграфа хранятся в сети IPFS. The Graph Node в первую очередь обращается к ноде IPFS во время развертывания подграфа для получения манифеста подграфа и всех связанных файлов. Индексаторам сети не нужно хостить свой собственную ноду IPFS, нода IPFS для сети находится на https://ipfs.network.thegraph.com.

• Indexer service. Обрабатывает все необходимые внешние подключения к сети. Совместно использует модели затрат и статусы индексации, передает заявки на запросы от шлюзов на Graph Node, и управляет платежами по запросам через каналы состояний с помощью шлюза.

• Indexer agent. Облегчает взаимодействие индексаторов в сети, включая регистрацию в сети, управление развертыванием подграфов на его Graph Node/ах и управление аллокациями.

• Prometheus metrics server. Компоненты Graph Node и индексатора регистрируют свои показатели на сервере данных.

Примечание: Для поддержки динамичного масштабирования рекомендуется разделить задачи запросов и индексирования между разными наборами нод: нодами запросов и нодами индексирования.

• Google Cloud SDK
• Инструмент командной строки Kubectl
• Terraform

• Клонируйте или перейдите к репозиторию индексатора.

• Перейдите в директорию ./terraform, именно здесь должны быть выполнены все команды.

cd terraform

• Авторизуйтесь в Google Cloud и создайте новый проект.

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

• Используйте страницу биллинга в Google Cloud Console, чтобы включить эту функцию для нового проекта.

• Создайте конфигурацию Google Cloud.

proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
gcloud config configurations create $project
gcloud config set project "$proj_id"
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

• Включите необходимые API-интерфейсы 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

• Создайте сервисный аккаунт.

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

• Активируйте peering между базой данных и кластером Kubernetes, который будет создан на следующем шаге.

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

• Создайте минимальный файл конфигурации terraform (обновляйте его по мере необходимости).

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

Прежде чем запускать какие-либо команды, прочитайте variables.tf и создайте файл terraform.tfvars в этом каталоге (или измените тот, который мы создали на последнем шаге). Для каждой переменной, где вы хотите переопределить значение по умолчанию или где вам нужно установить какое-либо значение, внесите параметры в terraform.tfvars.

• Запустите следующие команды для создания инфраструктуры.

# 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

Загрузите учетные данные для нового кластера в ~/.kube/config и установите его в качестве используемого по умолчанию.

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

• Скопируйте директорию k8s/overlays в новую директорию $dir, и настройте запись bases в $dir/kustomization.yaml таким образом, чтобы она указывала на директорию k8s/base.

• Прочтите все файлы в $dir и настройте все значения, как указано в комментариях.

Разверните все ресурсы с помощью команды kubectl apply -k $dir.

Graph Node – это внедрение Rust составляющей с открытым исходным кодом, которая использует блокчейн Ethereum для детерминированного обновления хранилища данных, которое можно запрашивать через эндпоинт GraphQL. Разработчики используют подграфы для определения своей структуры и набора маппингов для преобразования данных, получаемых из сети блоков, а Graph Node занимается синхронизацией всей сети, мониторингом новых блоков и их обслуживанием через GraphQL эндпоинт.

• Rust

• PostgreSQL

• IPFS

• Дополнительные требования для пользователей Ubuntu. Для запуска Graph Node в Ubuntu может потребоваться несколько дополнительных пакетов.

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

1. Запустите сервер базы данных PostgreSQL

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

2. Клонируйте репозиторий Graph Node и соберите исходный код, запустив cargo build

3. Теперь, когда все зависимости настроены, запустите 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. По умолчанию при настройке docker compose используется основная сеть http:// host.docker.internal:8545 для подключения к ноде Ethereum на Вашем хост-компьютере. Вы можете заменить это имя сети и Url-адрес, обновив docker-compose.yaml.

1. Клонируйте Graph Node и перейдите в директорию Docker:

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

2. Только для пользователей Linux. Используйте IP-адрес хоста вместо host.docker.internal в docker-compose.yaml с помощью прилагаемого скрипта:

./setup.sh

3. Запустите локальную Graph Node, которая будет подключаться к вашему Ethereum эндпоинту:

docker-compose up

Для успешного участия в сети требуется почти постоянный мониторинг и взаимодействие, поэтому мы создали набор приложений на основе Typescript для облегчения участия индексаторов в сети. Существует три компонента индексатора:

• Indexer agent. Агент отслеживает сеть и собственную инфраструктуру индексатора и управляет тем, какие развертывания подграфов индексируются и распределяются по сети, а также сколько выделено для каждого из них.

• Indexer service — единственный компонент, который должен быть доступен извне. Служба передает запросы подграфа на the graph ноду, управляет каналами состояния для платежей по запросу, делится важной информацией для принятия решений с клиентами, такими как шлюзы.

• Indexer CLI — интерфейс командной строки для управления Indexer agent. Он позволяет индексаторам управлять моделями затрат, ручным распределением, очередностью действий и правилами индексации.

The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on Discord! Remember to stake in the protocol before starting up your Indexer components!

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

• Извлеките образы из реестра

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

Или создайте образы локально из исходного кода

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

• Запустите компоненты

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

ПРИМЕЧАНИЕ. После запуска контейнеров Indexer service должна быть доступна по адресу http://localhost:7600, а Indexer agent должен предоставлять доступ к API управления индексатором по адресу http://localhost:18000/.

См. раздел Настройка инфраструктуры сервера с помощью Terraform в 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

Интерфейс командной строки индексатора — это плагин для @graphprotocol/graph-cli, доступный в терминале graph indexer.

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

Рекомендуемым инструментом для взаимодействия с Indexer Management API является Indexer CLI, расширение для Graph CLI. Indexer agent требуются данные от индексатора для автономного взаимодействия с сетью от имени индексатора. Механизмом определения поведения агента индексатора являются режим allocation management и indexing rules. В автоматическом режиме индексатор может использовать indexing rules, чтобы применить свою стратегию выбора подграфов для индексации и обслуживания запросов. Правила управляются через API GraphQL, обслуживаемый агентом и известный как API управления индексатором (Indexer Management API). В ручном режиме индексатор может создавать действия по распределению аллокаций, используя actions queue непосредственно утверждать их до того, как они будут выполнены. В режиме контроля indexing rules используются для заполнения actions queue и также требуют непосредственного утверждения их до того, как они будут выполнены.

Indexer CLI подключается к Indexer agent, как правило, посредством переадресации портов, поэтому CLI не нужно запускать на том же сервере или кластере. Ниже приведено краткое описание интерфейса командной строки.

• graph indexer connect <url> — подключение к API для управления индексатором. Обычно соединение с сервером открывается через переадресацию портов, поэтому интерфейсом командной строки можно легко управлять удаленно. (Например: kubectl port-forward pod/<indexer-agent-pod> 8000:8000)

• graph indexer rules get [options] <deployment-id> [<key1> ...] — получить одно или несколько indexing rules, используя all в качестве <deployment-id>, чтобы получить все правила, или global для получения глобальных значений по умолчанию. Дополнительный аргумент --merged может использоваться для указания того, что правила, специфичные для развертывания, объединяются с глобальным правилом. Вот как они применяются в Indexer agent.

• graph indexer rules set [options] <deployment-id> <key1> <value1> ... — установите одно или несколько правил индексации.

• graph indexer rules start [options] <deployment-id> – начать индексирование развертывания подграфа, если оно доступно, и установить для его decisionBasis значение always, в результате Indexer agent будет всегда его индексировать. Если для глобального правила установлено значение «always», то будут проиндексированы все доступные подграфы в сети.

• graph indexer rules stop [options] <deployment-id> – остановите индексирование развертывания и задайте для его decisionBasis значение «never», в результате оно будет пропускать это развертывание при принятии решения об индексации развертывания.

• graph indexer rules maybe [options] <deployment-id> — установите для развертывания decisionBasis значение rules, чтобы Indexer agent смог применить правила индексирования с целью решить, следует ли индексировать это развертывание.

• graph indexer actions get [options] <action-id> – выберите одно или несколько действий, используя all, или оставьте action-id пустым, чтобы получить все действия. Дополнительный аргумент --status может использоваться для вывода всех действий для определенного статуса.

• graph indexer action queue allocate <deployment-id> <allocation-amount> – действие по распределению аллокаций в виде очереди

• graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount> — действие по перераспределению аллокаций в виде очереди

• graph indexer action queue unallocate <deployment-id> <allocation-id> — действие по отмене распределения аллокации в виде очереди

• graph indexer actions cancel [<action-id> ...] - Отменить все действия в очереди, если id не указан, иначе отменить array of id с пробелом в качестве разделителя

• graph indexer actions approve [<action-id> ...] - Одобрить выполнение нескольких действий

• graph indexer actions execute approve — Заставить сотрудника немедленно выполнить утвержденные действия

Все команды, которые отображают правила в выходных данных, могут выбирать между поддерживаемыми выходными форматами (table, yaml и json) с помощью аргумента -output.

Правила индексирования могут применяться либо как глобальные значения по умолчанию, либо для определенных развертываний подграфов с использованием их идентификаторов. Поля deployment и decisionBasis обязательны для заполнения, а все остальные поля — необязательны. Если indexing rule содержит rules в качестве decisionBasis, Indexer agent сравнивает ненулевые пороговые значения в этом правиле со значениями, полученными из сети для соответствующего развертывания. Если значение развертывания подграфа выше (или ниже) любого из пороговых значений, оно будет выбрано для индексации.

Например, если глобальное правило имеет minStake 5 (GRT), любое развертывание подграфа с выделенной ему суммой стейкинга более 5 (GRT) будет проиндексировано. Пороговые правила включают maxAllocationPercentage, minSignal, maxSignal, minStake и minAverageQueryFees.

Модель данных:

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
}

Пример применения правила индексации:

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 предоставляет модуль actions для ручного управления очередностью действий. Для взаимодействия с очередностью действий он использует Graphql API, размещенный на сервере управления индексатором.

Обработчик выполнения действий будет извлекать элементы из очереди для выполнения только в том случае, если они имеют ActionStatus = Approved. В рекомендуемом пути действия добавляются в очередь с ActionStatus = queued, поэтому они должны быть одобрены для выполнения в сети. Общий поток будет выглядеть следующим образом:

• Действие, добавленное в очередь сторонним инструментом оптимизатора или пользователем indexer-cli
• Индексатор может использовать indexer-cli для просмотра всех действий, поставленных в очередь
• Индексатор (или другое программное обеспечение) может утверждать или отменять действия в очереди, используя indexer-cli. Команды утверждения и отмены принимают на входе массив идентификаторов действий.
• Исполнитель регулярно проверяет очередь на наличие утвержденных действий. Он берёт approved действия из очереди, пытается их выполнить и обновляет значения в базе данных в зависимости от статуса выполнения на success или failed.
• Если действие выполнено успешно, рабочий процесс обеспечит наличие правила индексации, которое сообщает агенту, как управлять распределением в будущем, что полезно при выполнении ручного управления, когда агент находится в режиме auto или oversight.
• Индексатор может отслеживать очередность действий, просматривая историю выполнения действий и, при необходимости, повторно утвердить и обновить элементы действий, если они не выполнились. Очередность действий содержит историю всех действий, поставленных в очередь и выполненных.

Модель данных:

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
}

Пример использования из исходного кода:

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

Обратите внимание, что поддерживаемые типы действий для управления распределением имеют разные входные требования:

• Allocate — выделение определенной величины стейкинга для развертывания определённого подграфа

  • Требуемые параметры действия:
    • deploymentID
    • amount

• Unallocate — закрыть распределение, освобождая величину стейкинга для перераспределения в другом месте

  • Требуемые параметры действия:
    • allocationID
    • deploymentID
  • Опциональные параметры действия:
    • poi
    • force (принудительно использует предоставленный POI, даже если он не соответствует тому, что предоставляет graph-node)

• Reallocate — немедленно закрыть распределение и открыть новое распределение для развертывания того же подграфа

  • Требуемые параметры действия:
    • allocationID
    • deploymentID
    • amount
  • Опциональные параметры действия:
    • poi
    • force (принудительно использует предоставленный POI, даже если он не соответствует тому, что предоставляет graph-node)

Модели затрат обеспечивают динамическое ценообразование для запросов на основе рынка и атрибутов запроса. Служба индексатора делится со шлюзом моделью стоимости для каждого подграфа, для которого они намереваются отвечать на запросы. Шлюзы, в свою очередь, используют модель затрат для принятия решений о выборе индексатора для каждого запроса и согласования оплаты с выбранными индексаторами.

Язык Agora предоставляет гибкий формат для объявления моделей затрат на запросы. Ценовая модель Agora — это последовательность операторов, которые выполняются по порядку для каждого запроса верхнего уровня в запросе GraphQL. Для каждого запроса верхнего уровня цена за этот запрос определяется первым соответствующим ему оператором.

Оператор состоит из predicate, который используется для сопоставления запросов GraphQL, и выражения стоимости, которое при оценке выводит стоимость в десятичном формате GRT. Значения в позиции именованного аргумента запроса могут быть захвачены в predicate и использованы в expression. Глобальные переменные также могут быть установлены и заменены на placeholders в expression.

Пример модели затрат:

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

# This default will match any GraphQL expression.
# It uses a Global substituted into the expression to calculate cost
default => 0.1 * $SYSTEM_LOAD;

Пример расчета стоимости запроса с использованием приведенной выше модели:

Модели затрат применяются через интерфейс командной строки (CLI) индексатора, который передает их в API управления индексатором агента индексатора для сохранения в базе данных. Затем Indexer Service отбирает их и предоставляет модели затрат шлюзам каждый раз, когда они запрашивают их.

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

Первые шаги к участию в сети в качестве индексатора заключаются в подтверждении протокола, стейкинге средств и (по желанию) установке адреса оператора для ежедневного взаимодействия с протоколом. _ Примечание: В этом документе для обмена контрактами используется Remix, но вы можете использовать любой удобный для вас инструмент (OneClickDapp, ABITopic и [MyCrypto](https://www.mycrypto. com/account) и другие)._

После того как индексатор застейкал GRT в протоколе, можно запустить Indexer components и начать взаимодействие с сетью.

1. Откройте приложение Remix в браузере

2. В File Explorer создайте файл с именем GraphToken.abi с [token ABI](https://raw.githubusercontent.com/graphprotocol /contracts/mainnet-deploy-build/build/abis/GraphToken.json).

3. Выбрав и открыв в редакторе GraphToken.abi, перейдите в раздел Deploy и запустите Run Transactions в интерфейсе Remix.

4. В разделе environment выберите Injected Web3, а в разделе Account выберите адрес вашего индексатора.

5. Установите адрес контракта GraphToken. Вставьте адрес контракта GraphToken (0xc944E90C64B2c07662A292be6244BDf05Cda44a7) рядом с At Address и нажмите кнопку At address, чтобы применить его.

6. Вызовите функцию approve(spender, amount), чтобы одобрить Staking контракт. Заполните spender адресом контракта стейкинга (0xF55041E37E12cD407ad00CE2910B8269B01263b9) и amount токенами для стейкинга (в wei).

1. Откройте приложение Remix в браузере

2. В File Explorer создайте файл с именем Staking.abi с ABI для стейкинга.

3. Выбрав и открыв в редакторе Staking.abi, перейдите в разделы Deploy и запустите Run Transactions в интерфейсе Remix.

4. В разделе environment выберите Injected Web3, а в разделе Account выберите адрес вашего индексатора.

5. Установите адрес Staking контракта. Вставьте адрес контракта (0xF55041E37E12cD407ad00CE2910B8269B01263b9) рядом с At Address и нажмите кнопку At address, чтобы применить его.

6. Вызовите stake(), чтобы застейкать GRT в протоколе.

7. (Необязательно) Индексаторы могут утвердить другой адрес в качестве оператора своей инфраструктуры индексатора, чтобы отделить ключи, управляющие средствами, от тех, которые выполняют повседневные действия, такие как выделение аллокаций подграфов и обслуживание (платных) запросов. Чтобы установить оператора, вызовите setOperator() с адресом оператора.

8. (Необязательно) Чтобы контролировать распределение вознаграждений и стратегически привлекать делегаторов, индексаторы могут обновлять свои параметры делегирования, обновляя их indexingRewardCut (части на миллион), queryFeeCut (части на миллион) и cooldownBlocks (количество блоков). Чтобы сделать это, вызовите setDelegationParameters(). В следующем примере задается параметр queryFeeCut для распределения 95 % вознаграждений за запросы индексатору и 5 % делегаторам, параметр indexingRewardCut устанавливается для распределения 60 % вознаграждения за индексирование индексатору и 40 % делегатам, а также задается thecooldownBlocks период до 500 блоков.

setDelegationParameters(950000, 600000, 500)

После создания индексатором распределение проходит четыре состояния.

• Active — после создания распределения в сети ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/master/contracts/staking/ Staking.sol#L873)) считается active. Часть собственной и/или делегированной доли индексатора выделяется для развертывания подграфа, что позволяет ему требовать вознаграждения за индексирование и обслуживать запросы для этого развертывания подграфа. Агент индексатора управляет созданием распределений на основе правил индексатора.

• Closed. Индексатор может закрыть аллокацию по при истечении 1 эпохи (closeAllocation()) или Indexer agent автоматически закроет его по истечении эпохи maxAllocationEpochs (в настоящее время 28 дней). Когда оно закрыто с действительным доказательством индексации (POI), вознаграждения за индексирование распределяются между индексатором и его делегаторами (ниже см. подробнее «Как распределяются вознаграждения?»).

Индексаторам рекомендуется использовать функцию синхронизации вне сети для синхронизации развертывания подграфов в chainhead перед созданием аллокации в сети. Эта функция особенно полезна для подграфов, синхронизация которых может занять более 28 эпох или имеющих некоторую вероятность неопределенного сбоя.