Индексирование
Reading time: 24 minutes
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.
Что такое подтверждение индексации (proof of indexing - POI)?
POI (подтверждение индексации) используются в сети для проверки того, индексирует ли индексатор назначенные им подграфы. При закрытии распределения необходимо предоставить POI для первого блока текущей эпохи, чтобы это распределение имело право на индексацию наград. POI для блока — это дайджест для всех транзакций хранилища объектов для данного развертывания подграфа до этого блока включительно.
Когда распределяются вознаграждения за индексацию?
Награды за распределения постоянно накапливаются, пока они активны и распределяются в течение 28 эпох. Награды собираются и распределяются индексаторами после того, как их распределение закрыто. Это делается либо вручную, если индексатор выбирает принудительное закрытие, либо через 28 эпох делегатор может закрыть выделение для индексатора, но это не приводит к вознаграждению. 28 эпох — это максимальное время жизни распределения (сейчас одна эпоха длится ~ 24 часа).
Каким образом можно отслеживать ожидаемые вознаграждения за индексацию?
The RewardsManager contract has a read-only getRewards function that can be used to check the pending rewards for a specific allocation.
Многие панели мониторинга, созданные сообществом, содержат ожидающие значения вознаграждений, и их можно легко проверить вручную, выполнив следующие действия:
- Query the mainnet subgraph to get the IDs for all active allocations:
query indexerAllocations { indexer(id: "<INDEXER_ADDRESS>") { allocations { activeForIndexer { allocations { id } } } }}
Используйте Etherscan для вызова getRewards()
:
- Перейдите в интерфейсе Etherscan к контракту Rewards
- Чтобы вызвать
getRewards()
:- Expand the 9. getRewards dropdown.
- Введите во входные данные allocationID.
- Нажмите кнопку Query.
Что такое споры и где их можно просмотреть?
Запросы и распределения индексатора могут быть оспорены на The Graph в течение периода спора. Срок спора варьируется в зависимости от типа спора. Запросы/аттестации имеют 7 эпох спорного окна, тогда как распределения имеют 56 эпох. По истечении этих периодов споры не могут быть открыты ни в отношении выделений, ни в отношении запросов. При открытии спора от Рыбаков требуется депозит в размере не менее 10 000 GRT, который будет заблокирован до завершения спора и принятия решения. Рыбаки — это любые участники сети, которые открывают споры.
У споров есть три возможных исхода, как и у депозита Рыбаков.
- Если спор отклонен, то GRT, внесенные рыбаками, будут сожжены, а оспариваемый индексатор не будет урезан.
- Если спор будет решен в виде ничьей, депозит рыбака будет возвращен, а спорный индексатор не будет урезан.
- Если спор будет принят, GRT, внесенные рыбаками, будут возвращены, спорный индексатор будет урезан, а рыбаки получат 50% от урезанных GRT.
Споры можно просмотреть в пользовательском интерфейсе на странице профиля индексатора на вкладке Disputes
.
Что такое query fee rebates и когда они распределяются?
Плата за запрос взимается шлюзом и распределяется между индексаторами в соответствии с экспоненциальной функцией скидки (см. 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.
Что такое query fee cut и indexing reward cut?
Значения 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 – готовность индексировать все используемые в настоящее время подграфы и обслуживать запросы на соответствующий трафик.
Настройка | Postgres (ЦП) | Postgres (память в ГБ) | Postgres (диск в ТБ) | VMs (ЦП) | VMs (память в ГБ) |
---|---|---|---|---|---|
Small | 4 | 8 | 1 | 4 | 16 |
Standard | 8 | 30 | 1 | 12 | 48 |
Medium | 16 | 64 | 2 | 32 | 64 |
Large | 72 | 468 | 3.5 | 48 | 184 |
Какие основные меры безопасности следует предпринять индексатору?
-
Operator wallet. Настройка кошелька оператора является важной мерой безопасности, поскольку она позволяет индексатору поддерживать разделение между своими ключами, которые контролируют величину стейка, и теми, которые контролируют ежедневные операции. Инструкции см. в разделе Stake in Protocol.
-
Firewall. Только служба индексатора должна быть общедоступной, и особое внимание следует уделить блокировке портов администратора и доступа к базе данных: эндпоинт ноды The Graph JSON-RPC (порт по умолчанию: 8030), API эндпоинт для управления индексатором (порт по умолчанию: 18000) и эндпоинт базы данных Postgres (порт по умолчанию: 5432) не должны быть доступны.
Infrastructure
В центре инфраструктуры индексатора находится нода 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 и индексатора регистрируют свои показатели на сервере данных.
Примечание: Для поддержки динамичного масштабирования рекомендуется разделить задачи запросов и индексирования между разными наборами нод: нодами запросов и нодами индексирования.
Обзор портов
Важно. Будьте осторожны, открывая порты для общего доступа — порты администрирования должны быть заблокированы. Это касается Graph Node JSON-RPC и эндпоинтов для управления индексатором, описанных ниже.
Graph Node
Порт | Назначение | Расположение | CLI-аргумент | Переменная среды |
---|---|---|---|---|
8000 | HTTP-сервер GraphQL (для запросов подграфов) | /subgraphs/id/… /subgraphs/name/…/… | —http-port | - |
8001 | GraphQL WS (для подписок на подграфы) | /subgraphs/id/… /subgraphs/name/…/… | —ws-port | - |
8020 | JSON-RPC (для управления процессом развертывания) | / | —admin-port | - |
8030 | API для определения статуса индексирования подграфов | /graphql | —index-node-port | - |
8040 | Показатели Prometheus | /metrics | —metrics-port | - |
Indexer Service
Порт | Назначение | Расположение | CLI-аргумент | Переменная среды |
---|---|---|---|---|
7600 | HTTP-сервер GraphQL (для платных запросов к подграфам) | /subgraphs/id/… /status /channel-messages-inbox | —port | INDEXER_SERVICE_PORT |
7300 | Показатели Prometheus | /metrics | —metrics-port | - |
Indexer Agent
Порт | Назначение | Расположение | CLI-аргумент | Переменная среды |
---|---|---|---|---|
8000 | API для управления индексатором | / | —indexer-management-port | INDEXER_AGENT_INDEXER_MANAGEMENT_PORT |
Настройка серверной инфраструктуры с помощью Terraform в Google Cloud
Примечание: Индексаторы могут в качестве альтернативы использовать AWS, Microsoft Azure или Alibaba.
Установка предварительного обеспечения
- Google Cloud SDK
- Инструмент командной строки Kubectl
- Terraform
Создайте проект Google Cloud
-
Clone or navigate to the Indexer repository.
-
Navigate to the
./terraform
directory, this is where all commands should be executed.
cd terraform
- Авторизуйтесь в Google Cloud и создайте новый проект.
gcloud auth loginproject=<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 $projectgcloud config set project "$proj_id"gcloud config set compute/region us-central1gcloud config set compute/zone us-central1-a
- Включите необходимые API-интерфейсы Google Cloud.
gcloud services enable compute.googleapis.comgcloud services enable container.googleapis.comgcloud services enable servicenetworking.googleapis.comgcloud 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 listsvc=$(gcloud iam service-accounts list --format='get(email)'--filter="displayName=$svc_name")gcloud iam service-accounts keys create .gcloud-credentials.json \ --iam-account="$svc"gcloud projects add-iam-policy-binding $proj_id \ --member serviceAccount:$svc \ --role roles/editor
- Активируйте 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 <<EOFproject = "$proj_id"indexer = "$indexer"database_password = "<database passowrd>"EOF
Используйте Terraform для создания инфраструктуры
Прежде чем запускать какие-либо команды, прочитайте variables.tf и создайте файл terraform.tfvars
в этом каталоге (или измените тот, который мы создали на последнем шаге). Для каждой переменной, где вы хотите переопределить значение по умолчанию или где вам нужно установить какое-либо значение, внесите параметры в terraform.tfvars
.
- Запустите следующие команды для создания инфраструктуры.
# Install required pluginsterraform init# View plan for resources to be createdterraform plan# Create the resources (expect it to take up to 30 minutes)terraform apply
Загрузите учетные данные для нового кластера в ~/.kube/config
и установите его в качестве используемого по умолчанию.
gcloud container clusters get-credentials $indexerkubectl config use-context $(kubectl config get-contexts --output='name'| grep $indexer)
Создание Kubernetes компонентов для индексатора
-
Скопируйте директорию
k8s/overlays
в новую директорию$dir,
и настройте записьbases
в$dir/kustomization.yaml
таким образом, чтобы она указывала на директориюk8s/base
. -
Прочтите все файлы в
$dir
и настройте все значения, как указано в комментариях.
Разверните все ресурсы с помощью команды kubectl apply -k $dir
.
Graph Node
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. Для запуска Graph Node в Ubuntu может потребоваться несколько дополнительных пакетов.
sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
Настройка
- Запустите сервер базы данных PostgreSQL
initdb -D .postgrespg_ctl -D .postgres -l logfile startcreatedb graph-node
-
Клонируйте репозиторий Graph Node и соберите исходный код, запустив
cargo build
-
Теперь, когда все зависимости настроены, запустите 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
Начало работы с Docker
Предварительные требования
- Нода Ethereum. По умолчанию при настройке docker compose используется основная сеть http:// host.docker.internal:8545 для подключения к ноде Ethereum на Вашем хост-компьютере. Вы можете заменить это имя сети и Url-адрес, обновив
docker-compose.yaml
.
Настройка
- Клонируйте Graph Node и перейдите в директорию Docker:
git clone https://github.com/graphprotocol/graph-nodecd graph-node/docker
- Только для пользователей Linux. Используйте IP-адрес хоста вместо
host.docker.internal
вdocker-compose.yaml
с помощью прилагаемого скрипта:
./setup.sh
- Запустите локальную 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
npm install -g @graphprotocol/indexer-servicenpm install -g @graphprotocol/indexer-agent# Indexer CLI is a plugin for Graph CLI, so both need to be installed:npm install -g @graphprotocol/graph-clinpm install -g @graphprotocol/indexer-cli# Indexer servicegraph-indexer-service start ...# Indexer agentgraph-indexer-agent start ...# Indexer CLI#Forward the port of your agent pod if using Kuberneteskubectl port-forward pod/POD_ID 18000:8000graph indexer connect http://localhost:18000/graph indexer ...
Из исходного кода
# From Repo root directoryyarn# Indexer Servicecd packages/indexer-service./bin/graph-indexer-service start ...# Indexer agentcd packages/indexer-agent./bin/graph-indexer-service start ...# Indexer CLIcd packages/indexer-cli./bin/graph-indexer-cli indexer connect http://localhost:18000/./bin/graph-indexer-cli indexer ...
С помощью docker
- Извлеките образы из реестра
docker pull ghcr.io/graphprotocol/indexer-service:latestdocker pull ghcr.io/graphprotocol/indexer-agent:latest
Или создайте образы локально из исходного кода
# Indexer servicedocker build \ --build-arg NPM_TOKEN=<npm-token> \ -f Dockerfile.indexer-service \ -t indexer-service:latest \# Indexer agentdocker build \ --build-arg NPM_TOKEN=<npm-token> \ -f Dockerfile.indexer-agent \ -t indexer-agent:latest \
- Запустите компоненты
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/.
Использование K8s и Terraform
См. раздел Настройка инфраструктуры сервера с помощью Terraform в Google Cloud
Применение
ПРИМЕЧАНИЕ. Все переменные конфигурации среды выполнения могут применяться либо в качестве параметров команды при запуске, либо с использованием переменных среды в формате COMPONENT_NAME_VARIABLE_NAME
(например, INDEXER_AGENT_ETHEREUM
).
Indexer agent
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
Indexer service
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
Indexer CLI
Интерфейс командной строки индексатора — это плагин для @graphprotocol/graph-cli
, доступный в терминале graph indexer
.
graph indexer connect http://localhost:18000graph 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>
- Fetch one or more actions usingall
or leaveaction-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>
– действие по распределению аллокаций в виде очереди -
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
.
Indexing rules
Правила индексирования могут применяться либо как глобальные значения по умолчанию, либо для определенных развертываний подграфов с использованием их идентификаторов. Поля 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 QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEKgraph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported falsegraph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEKgraph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
Очередь действий в CLI
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