Обзор индексирования

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

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

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

Часто задаваемые вопросы

Какова минимальная величина стейка, требуемая для того, чтобы быть Индексатором в сети?

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

Какие источники дохода у Индексатора?

Возмещение комиссий за запросы – выплаты за обработку запросов в сети. Эти платежи проходят через государственные каналы между Индексатором и шлюзом. Каждый запрос от шлюза содержит оплату, а соответствующий ответ — доказательство достоверности результата запроса.

Награды за индексирование – формируются за счет ежегодной инфляции протокола в размере 3% и распределяются между Индексаторами, которые индексируют развернутые субграфы для сети.

Как распределяются награды за индексирование?

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

Сообщество создало множество инструментов для расчета наград; их собрание можно найти в коллекции Гайдов Сообщества⁠. Также актуальный список инструментов доступен в каналах #Delegators и #Indexers на сервере Discord⁠. Здесь мы приводим ссылку на рекомендованный оптимизатор распределения⁠, интегрированный с программным стеком Индексатора.

Что такое доказательство индексирования (POI)?

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

Когда распределяются награды за индексирование?

Аллокации постоянно накапливают награды, пока они активны и распределены в течение 28 эпох. Награды собираются Индексаторами и распределяются при закрытии их аллокаций. Это может происходить вручную, когда Индексатор сам решает их закрыть, или автоматически по истечении 28 эпох. Если после 28 эпох аллокацию закрывает Делегатор, награды не выплачиваются. В настоящее время одна эпоха длится примерно 24 часа.

Можно ли отслеживать ожидаемые награды за индексирование?

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

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

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

1query indexerAllocations {2  indexer(id: "<INDEXER_ADDRESS>") {3    allocations {4      activeForIndexer {5        allocations {6          id7        }8      }9    }10  }11}

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

• Перейдите на интерфейс Etherscan к контракту Rewards⁠.
• Чтобы вызвать getRewards():
  • Разверните выпадающее меню 9. getRewards.
  • Введите allocationID в поле ввода.
  • Нажмите кнопку Query.

Что такое споры и где их можно посмотреть?

Запросы и аллокации Индексатора могут быть оспорены в The Graph в течение периода спора. Период спора варьируется в зависимости от типа спора. Запросы/аттестации имеют окно спора в 7 эпох, тогда как аллокации – 56 эпох. После истечения этих периодов споры против аллокаций или запросов больше не могут быть открыты. Когда спор открывается, Fishermen (участники сети, открывающие споры) должны внести депозит минимум 10 000 GRT, который будет заморожен до завершения спора и вынесения решения.

Споры могут иметь три возможных исхода, как и депозит Fishermen.

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

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

Что такое возврат комиссии за запросы и когда он распределяется?

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

Как только аллокация закрывается, Индексатор может потребовать возврат комиссии. После запроса возврата, комиссии за запросы распределяются между Индексатором и его Делегаторами в соответствии с процентом комиссии за запросы и экспоненциальной функцией возврата.

Что такое доля комиссии за запросы и доля вознаграждения за индексирование?

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

• queryFeeCut – процент возврата комиссий за запросы, который будет распределяться в пользу Индексатора. Если установлено значение 95%, Индексатор получит 95% заработанных комиссий за запросы при закрытии аллокации, а оставшиеся 5% пойдут Делегаторам.

• indexingRewardCut – процент вознаграждений за индексирование, который будет распределяться в пользу Индексатора. Если установлено значение 95%, Индексатор получит 95% вознаграждений за индексирование при закрытии аллокации, а оставшиеся 5% будут распределены между Делегаторами.

Как Индексаторы узнают, какие Субграфы индексировать?

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

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

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

• Объем стейка – отслеживание поведения других Индексаторов или анализ доли общего стейка, выделенного на конкретные Субграфы, позволяет Индексатору оценивать предложение для запросов к Субграфам, что помогает выявлять Субграфы, которым сеть доверяет, или те, которые нуждаются в большем количестве ресурсов.

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

Каковы требования к аппаратному обеспечению?

• Низкие – достаточно для начала индексирования нескольких субграфов, но, вероятно, потребуется расширение.
• Стандартные – настройка по умолчанию, используется в примерах манифестов развертывания k8s/terraform.
• Средние – производительный Индексатор, поддерживающий 100 субграфов и 200–500 запросов в секунду.
• Высокие – готов индексировать все используемые субграфы и обрабатывать соответствующий трафик запросов.

Какие основные меры безопасности следует предпринять Индексатору?

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

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

Инфраструктура

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

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

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

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

• Сервис Индексатора – обрабатывает все необходимые внешние коммуникации с сетью. Делится моделями стоимости и статусами индексирования, передаёт запросы от шлюзов в Graph Node и управляет платежами за запросы через каналы состояния со шлюзом.

• Агент Индексатора – обеспечивает взаимодействие Индексатора в блокчейне, включая регистрацию в сети, управление развертыванием Субграфов в его Graph Node и управление распределением ресурсов.

• Сервер метрик Prometheus – Graph Node и компоненты Индексатора записывают свои метрики на сервер метрик.

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

Обзор портов

Graph Node

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

Агент Индексатора

Настройка серверной инфраструктуры с использованием Terraform в Google Cloud

Установка необходимых компонентов

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

Создание проекта в Google Cloud

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

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

1cd terraform

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

1gcloud auth login2project=<PROJECT_NAME>3gcloud projects create --enable-cloud-apis $project

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

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

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

• Включите необходимые API Google Cloud.

1gcloud services enable compute.googleapis.com2gcloud services enable container.googleapis.com3gcloud services enable servicenetworking.googleapis.com4gcloud services enable sqladmin.googleapis.com

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

1svc_name=<SERVICE_ACCOUNT_NAME>2gcloud iam service-accounts create $svc_name \3  --description="Service account for Terraform" \4  --display-name="$svc_name"5gcloud iam service-accounts list6# Получить email учетной записи сервиса из списка7svc=$(gcloud iam service-accounts list --format='get(email)'8--filter="displayName=$svc_name")9gcloud iam service-accounts keys create .gcloud-credentials.json \10  --iam-account="$svc"11gcloud projects add-iam-policy-binding $proj_id \12  --member serviceAccount:$svc \13  --role roles/editor

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

1gcloud compute addresses create google-managed-services-default \2  --prefix-length=20 \3  --purpose=VPC_PEERING \4  --network default \5  --global \6  --description 'IP Range for peer networks.'7gcloud services vpc-peerings connect \8  --network=default \9  --ranges=google-managed-services-default

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

1indexer=<INDEXER_NAME>2cat > terraform.tfvars <<EOF3project = "$proj_id"4indexer = "$indexer"5database_password = "<database password>"6EOF

Используйте Terraform для создания инфраструктуры

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

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

1# Установить необходимые плагины2terraform init34# Просмотреть план создаваемых ресурсов5terraform plan67# Создать ресурсы (может занять до 30 минут)8terraform apply

Скачайте учетные данные для нового кластера в файл ~/.kube/config и установите его как ваш контекст по умолчанию.

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

Создание компонентов Kubernetes для Индексатора

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

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

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

Graph Node

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

Начало работы с исходным кодом

Установка необходимых компонентов

• Rust

• PostgreSQL

• IPFS

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

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

Настройка

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

1initdb -D .postgres2pg_ctl -D .postgres -l logfile start3createdb graph-node

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

3. Теперь, когда все зависимости настроены, запустите Graph Node:

1cargo run -p graph-node --release -- \2  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \3  --ethereum-rpc [NETWORK_NAME]:[URL] \4  --ipfs https://ipfs.network.thegraph.com

Начало работы с Docker

Предварительные требования

• Нода Ethereum — по умолчанию, настройка Docker Compose будет использовать основную сетевую ноду: http://host.docker.internal:8545⁠ для подключения к ноде Ethereum на вашей хостинговой машине. Вы можете заменить это имя сети и URL, обновив файл docker-compose.yaml.

Настройка

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

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

2. Только для пользователей Linux — используйте IP-адрес хоста вместо host.docker.internal в файле docker-compose.yaml, используя при этом включенный скрипт:

1./setup.sh

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

1docker-compose up

Компоненты Индексатора

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

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

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

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

Начало работы

Агент Индексатора и сервис Индексатора должны быть размещены рядом с Вашей инфраструктурой Graph Node. Существует множество способов настройки виртуальных исполнимых сред для компонентов Индексатора. Здесь мы объясним, как запустить их на физическом сервере, используя NPM пакеты или исходный код, а также через Kubernetes и Docker на Google Cloud Kubernetes Engine. Если эти примеры настроек не подходят для Вашей инфраструктуры, скорее всего, существует сообщество, которое может предоставить руководство. Присоединяйтесь к нам в Discord⁠! Не забудьте застейкать GRT перед запуском компонентов Индексатора!

Из пакетов NPM

1npm install -g @graphprotocol/indexer-service2npm install -g @graphprotocol/indexer-agent34# CLI Индексатора является плагином для Graph CLI, поэтому необходимо установить оба пакета:5npm install -g @graphprotocol/graph-cli6npm install -g @graphprotocol/indexer-cli78# Сервис Индексатора9graph-indexer-service start ...1011# Агент Индексатора12graph-indexer-agent start ...1314#CLI Индексатора15#Проброс порта Вашего pod-агента, если используется Kubernetes16kubectl port-forward pod/POD_ID 18000:800017graph indexer connect http://localhost:18000/18graph indexer ...

Из исходного кода

1# Из корневого каталога репозитория2yarn34# Сервис Индексатора5cd packages/indexer-service6./bin/graph-indexer-service start ...78# Агент Индексатора9cd packages/indexer-agent10./bin/graph-indexer-service start ...1112# CLI Индексатора13cd packages/indexer-cli14./bin/graph-indexer-cli indexer connect http://localhost:18000/15./bin/graph-indexer-cli indexer ...

Использование docker

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

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

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

1# Сервис Индексатора2docker build \3  --build-arg NPM_TOKEN=<npm-token> \4  -f Dockerfile.indexer-service \5  -t indexer-service:latest \6# Агент Индексатора7docker build \8  --build-arg NPM_TOKEN=<npm-token> \9  -f Dockerfile.indexer-agent \10  -t indexer-agent:latest \

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

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

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

Использование K8s и Terraform

Посмотрите раздел Настройка серверной инфраструктуры с использованием Terraform в Google Cloud

Применение

Агент Индексатора

1graph-indexer-agent start \2  --ethereum <MAINNET_ETH_ENDPOINT> \3  --ethereum-network mainnet \4  --mnemonic <MNEMONIC> \5  --indexer-address <INDEXER_ADDRESS> \6  --graph-node-query-endpoint http://localhost:8000/ \7  --graph-node-status-endpoint http://localhost:8030/graphql \8  --graph-node-admin-endpoint http://localhost:8020/ \9  --public-indexer-url http://localhost:7600/ \10  --indexer-geo-coordinates <YOUR_COORDINATES> \11  --index-node-ids default \12  --indexer-management-port 18000 \13  --metrics-port 7040 \14  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \15  --default-allocation-amount 100 \16  --register true \17  --inject-dai true \18  --postgres-host localhost \19  --postgres-port 5432 \20  --postgres-username <DB_USERNAME> \21  --postgres-password <DB_PASSWORD> \22  --postgres-database indexer \23  --allocation-management auto \24  | pino-pretty

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

1SERVER_HOST=localhost \2SERVER_PORT=5432 \3SERVER_DB_NAME=is_staging \4SERVER_DB_USER=<DB_USERNAME> \5SERVER_DB_PASSWORD=<DB_PASSWORD> \6graph-indexer-service start \7  --ethereum <MAINNET_ETH_ENDPOINT> \8  --ethereum-network mainnet \9  --mnemonic <MNEMONIC> \10  --indexer-address <INDEXER_ADDRESS> \11  --port 7600 \12  --metrics-port 7300 \13  --graph-node-query-endpoint http://localhost:8000/ \14  --graph-node-status-endpoint http://localhost:8030/graphql \15  --postgres-host localhost \16  --postgres-port 5432 \17  --postgres-username <DB_USERNAME> \18  --postgres-password <DB_PASSWORD> \19  --postgres-database is_staging \20  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \21  | pino-pretty

CLI Индексатора

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

1graph indexer connect http://localhost:180002graph indexer status

Управление Индексатором с помощью CLI Индексатора

Предлагаемым инструментом для взаимодействия с API управления Индексатором является CLI Индексатора, расширение для Graph CLI. Для того чтобы Индексатор мог автономно взаимодействовать с сетью от его имени, ему нужно предоставить входные данные. Механизм, который определяет поведение Индексатора, включает режимы управления распределениями и правила индексирования. В режиме автоматического управления Индексатор может использовать правила индексирования, чтобы применить свою стратегию для выбора субграфов, которые он будет индексировать и обслуживать запросы. Эти правила управляются через GraphQL API, которое предоставляется агентом и называется API управления Индексатором. В режиме ручного управления Индексатор может создавать действия для выделений, используя очередь действий и явно утверждать их перед выполнением. В режиме контроля правила индексирования используются для пополнения очереди действий, и для выполнения этих действий также требуется явное одобрение. Эти механизмы позволяют Индексатору выбирать стратегию для индексирования и обеспечения запросов в сети, а также контролировать их выполнение с различными уровнями автоматизации.

Применение

CLI Индексатора подключается к агенту Индексатора, обычно через порт-прокси, поэтому CLI не обязательно должен работать на том же сервере или кластере. Чтобы помочь вам начать работу и предоставить некоторый контекст, CLI будет кратко описан здесь.

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

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

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

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

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

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

• 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> ...] - отменить все действия в очереди, если идентификатор не указан, в противном случае отменить массив идентификаторов, разделенных пробелом

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

• graph indexer actions execute approve - принудительно выполнить одобренные действия немедленно

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

Правила индексирования

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

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

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

1type IndexingRule {2    identifier: string3    identifierType: IdentifierType4    decisionBasis: IndexingDecisionBasis!5    allocationAmount: number | null6    allocationLifetime: number | null7    autoRenewal: boolean8    parallelAllocations: number | null9    maxAllocationPercentage: number | null10    minSignal: string | null11    maxSignal: string | null12    minStake: string | null13    minAverageQueryFees: string | null14    custom: string | null15    requireSupported: boolean | null16  }1718IdentifierType {19  deployment20  subgraph21  group22}2324IndexingDecisionBasis {25  rules26  never27  always28  offchain29}

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

1graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK23graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false45graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK67graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK

Очередь действий CLI

indexer-cli предоставляет модуль actions для ручной работы с очередью действий. Он использует Graphql API, размещенный на сервере управления Индексатором, для взаимодействия с очередью действий.

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

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

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

1Type ActionInput {2    status: ActionStatus3    type: ActionType4    deploymentID: string | null5    allocationID: string | null6    amount: string | null7    poi: string | null8    force: boolean | null9    source: string10    reason: string | null11    priority: number | null12}1314ActionStatus {15  queued16  approved17  pending18  success19  failed20  canceled21}2223ActionType {24  allocate25  unallocate26  reallocate27  collect28}

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

1graph indexer actions get all23graph indexer actions get --status queued45graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 500067graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 5500089graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae1011graph indexer actions cancel1213graph indexer actions approve 1 3 51415graph 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 предоставляет гибкий формат для объявления моделей стоимости запросов. Модель стоимости Agora — это последовательность операторов, которые выполняются по порядку для каждого верхнего уровня запроса в GraphQL запросе. Для каждого верхнего уровня запроса первое условие, которое совпадает с ним, определяет цену для этого запроса.

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

Пример модели стоимости:

1# Это выражение захватывает значение skip,2# использует логическое выражение в предикате для соответствия конкретным запросам, использующим `skip`,3# и выражение для вычисления стоимости на основе значения `skip` и глобальной переменной SYSTEM_LOAD4query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;56# Этот по умолчанию шаблон будет соответствовать любому выражению GraphQL.7# Он использует глобальную переменную, подставленную в выражение для вычисления стоимости8default => 0.1 * $SYSTEM_LOAD;

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

Применение модели стоимости

Модели стоимости применяются через CLI Индексатора, который передает их в API управления Индексатором для хранения в базе данных. После этого Индексатор-сервис будет получать эти модели стоимости и передавать их шлюзам, когда те запрашивают их.

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

Взаимодействие с сетью

Стейкинг в протоколе

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

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

Подтверждение токенов

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

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

3. С выбранным и открытым в редакторе файлом GraphToken.abi, перейдите в раздел Deploy and run transactions в интерфейсе Remix.

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

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

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

Стейкинг токенов

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

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

3. С файлом Staking.abi, выбранным и открытым в редакторе, перейдите в раздел Deploy and run transactions в интерфейсе Remix.

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

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

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

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

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

1setDelegationParameters(950000, 600000, 500)

Настройка параметров делегирования

Функция setDelegationParameters() в стейкинг-контракте⁠ является важной для Индексаторов, позволяя им задавать параметры, определяющие их взаимодействие с Делегаторами, что влияет на распределение вознаграждений и способность к делегированию.

Как настроить параметры делегирования

Чтобы установить параметры делегирования с помощью интерфейса Graph Explorer, выполните следующие шаги:

1. Перейдите в Graph Explorer.
2. Подключите свой кошелек. Выберите мультиподпись (например, Gnosis Safe), затем выберите основную сеть. Примечание: вам нужно будет повторить этот процесс для сети Arbitrum One.
3. Подключите кошелек, который у Вас есть в качестве подписанта.
4. Перейдите в раздел ‘Settings’ и выберите ‘Delegation Parameters’. Эти параметры должны быть настроены для достижения эффективного распределения в желаемом диапазоне. После ввода значений в предоставленные поля ввода интерфейс автоматически рассчитает эффективное распределение. При необходимости отрегулируйте эти значения, чтобы достичь желаемого процента эффективного распределения.
5. Отправьте транзакцию в сеть.

Срок существования аллокации

После создания Индексатором работоспособная аллокация проходит через два состояния.

• Активный - как только распределение создается в блокчейне (allocateFrom()⁠), оно считается активным. Часть собственного залога Индексера и/или делегированного залога выделяется для развертывания субграфа, что позволяет им получать вознаграждения за индексирование и обслуживать запросы для этого развертывания субграфа. Агент Индексатора управляет созданием распределений в соответствии с правилами Индексатора.

• Закрытый - Индексатор может закрыть распределение, как только пройдет 1 эпоха (closeAllocation()⁠), или его агент Индексатора автоматически закроет распределение после maxAllocationEpochs (в настоящее время 28 дней). Когда распределение закрыто с действительным доказательством индексирования (POI), вознаграждения за индексирование распределяются между Индексатором и его делегаторами (узнать больше).

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