Indexación

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.

Los GRT que se depositan en stake en el protocolo está sujeto a un periodo de desbloqueo y puede incurrir en slashing (ser reducidos) si los Indexadores son maliciosos y sirven datos incorrectos a las aplicaciones o si indexan incorrectamente. Los Indexadores también obtienen recompensas por stake delegados de los Delegadores, para contribuir a la red.

Los Indexadores seleccionan subgrafos para indexar basados en la señal de curación del subgrafo, donde los Curadores realizan stake de sus GRT para indicar qué subgrafos son de mejor calidad y deben tener prioridad para ser indexados. Los consumidores (por ejemplo, aplicaciones, clientes) también pueden establecer parámetros para los cuales los Indexadores procesan consultas para sus subgrafos y establecen preferencias para el precio asignado a cada consulta.

El stake mínimo para un Indexador es actualmente de 100.000 GRT.

Reembolsos de Tarifas de consulta - Pagos por servir consultas en la red. Estos pagos se realizan a través de canales de estado entre un Indexador y un gateway. Cada solicitud de consulta de un gateway contiene un pago y la respuesta correspondiente una prueba de la validez del resultado de la consulta.

Recompensas de indexación - Generadas a través de una inflación anual del 3% en todo el protocolo, las recompensas de indexación se distribuyen a los Indexadores que indexan deploys de subgrafos para la red.

Las recompensas de indexación proceden de la inflación del protocolo, que se fija en un 3% anual de emisión. Se distribuyen entre los subgrafos en función de la proporción de todas las señales de curación en cada uno de ellos y, a luego, se distribuyen proporcionalmente a los Indexadores en función de su allocated stake en ese subgrafo. Una allocation debe cerrarse con una prueba válida de indexación (POI) que cumpla las normas establecidas por el acta de arbitraje para poder optar a las recompensas.

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.

Las POIs se utilizan en la red para verificar que un Indexador está indexando los subgrafos en los que tiene allocation. Se debe enviar un POI para el primer bloque de la época actual al cerrar una allocation para que dicha allocation pueda optar a las recompensas de indexación. Un POI para un bloque es un resumen de todas las transacciones de las entidades involucradaas en el deployment de un subgrafo específico hasta ese bloque inclusive.

Las allocations acumulan recompensas continuamente mientras están activas y asignadas dentro de 28 épocas. Los Indexadores recogen las recompensas y las distribuyen cuando se cierran sus allocations. Esto ocurre manualmente, siempre que el Indexador quiera forzar el cierre, o después de 28 épocas un Delegador puede cerrar la allocation para el Indexador, pero esto da como resultado que no se generen recompensas. 28 épocas es la duración máxima de la allocation (ahora mismo, una época dura unas 24 horas).

El contrato de RewardsManager tiene una función getRewards de solo lectura que se puede usar para comprobar las recompensas pendientes para una allocation específica.

Muchos de los paneles creados por la comunidad incluyen valores de recompensas pendientes y se pueden verificar fácilmente de forma manual siguiendo estos pasos:

1. Consulta el mainnet subgraph para obtener los ID de todas las allocations activas:

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

Utiliza Etherscan para solicitar el getRewards():

• Navega hacia Etherscan interface to Rewards contract

• Para llamar getRewards():
  • Expande el 10. getRewards dropdown.
  • Introduce el allocationID en la entrada.
  • Haz clic en el botón Query.

Las consultas y allocation del Indexador se pueden disputar en The Graph durante el período de disputa. El período de disputa varía según el tipo de disputa. Las consultas tienen una ventana de disputa de 7 épocas, mientras que las allocation tienen 56 épocas. Una vez transcurridos estos períodos, no se pueden abrir disputas contra allocation o consultas. Cuando se abre una disputa, los Fishermen requieren un depósito mínimo de 10,000 GRT, que permanecerá bloqueado hasta que finalice la disputa y se haya dado una resolución. Los Fishermen (o pescadores) son todos los participantes de la red que abren disputas.

Las disputas tienen tres posibles resultados, al igual que el depósito de los Fishermen.

• Si se rechaza la disputa, los GRT depositados por los Fishermen se quemarán y el Indexador en disputa no incurrirá en slashing.
• Si la disputa se resuelve como empate, se devolverá el depósito de los Fishermen y no se realizará slashing al Indexador en disputa.
• Si la disputa es aceptada, los GRT depositados por los Fishermen serán devueltos, el Indexador en disputa recibirá slashing y los Fishermen ganarán el 50% de los GRT en slashing.

Las disputas se podran visualizar en la interfaz correspondiente al perfil del Indexador en la pestaña de Disputes.

Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP here). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.

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.

Los valores de los QueryFeeCut e IndexingRewardCut son parámetros de delegación que el Indexador debe establecer junto con cooldownBlocks para controlar la distribución de GRT entre el Indexador y sus Delegadores. Hecha un vistazo de los últimos pasos de Staking in the Protocol para obtener instrucciones sobre la configuración de los parámetros de delegación.

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

Los indexadores pueden diferenciarse aplicando técnicas avanzadas para tomar decisiones de indexación de subgrafos, pero para dar una idea general, discutiremos varias métricas clave que se utilizan para evaluar subgrafos en la red:

• Señal de Curación - la proporción de señal de curación de la red aplicada a un subgrafo en particular es un buen indicador del interés en ese subgrafo, especialmente durante la fase de lanzamiento cuando el volumen de consultas aumenta.

• Tarifas de consulta recogidas - Los datos históricos del volumen de tarifas de consulta recogidas para un subgrafo específico son un buen indicador de la demanda futura.

• Cantidad en stake - Monitorear el comportamiento de otros Indexadores u observar las proporciones de stake total asignado a subgrafos específicos puede permitir a un Indexador monitorear el lado de la oferta de consultas de subgrafos para identificar subgrafos en los que la red está mostrando confianza o subgrafos que pueden mostrar una necesidad de más oferta.

• Subgrafos sin recompensas de indexación - Algunos subgrafos no generan recompensas de indexación principalmente porque utilizan funciones no compatibles como IPFS o porque están consultando otra red fuera de mainnet. Verás un mensaje en un subgrafo si no genera recompensas de indexación.

• Pequeño: Lo suficiente como para comenzar a indexar varios subgrafos, es probable que deba expandirse.
• Estándar: Configuración predeterminada, esto es lo que se usa en los manifiestos de deploy de k8s/terraform de ejemplo.
• Medio - Indexador de producción que soporta 100 subgrafos y 200-500 solicitudes por segundo.
• Grande: Preparado para indexar todos los subgrafos utilizados actualmente y atender solicitudes para el tráfico relacionado.

• Wallet del operador - Configurar una wallet del operador es una precaución importante porque permite que un Indexador mantenga la separación entre sus claves que controlan el stake y las que controlan las operaciones diarias. Consulta Stake in Protocol para obtener instrucciones.

• Firewall: Solo el servicio de indexación debe exponerse públicamente y se debe prestar especial atención al bloqueo de los puertos de administración y el acceso a la base de datos: el endpoint JSON-RPC de Graph Node (puerto predeterminado: 8030), el endpoint de la API de administración del Indexador (puerto predeterminado: 18000) y el endpoint de la base de datos de Postgres (puerto predeterminado: 5432) no deben exponerse.

En el centro de la infraestructura de un Indexador está el Graph Node que monitorea las redes que fueron indexadas, extrae y carga datos según una definición de un subgrafo y lo sirve como una GraphQL API. El Graph Node debe estar conectado a un endpoint que exponga datos de cada red indexada; un nodo IPFS para obtener datos; una base de datos PostgreSQL para su almacenamiento; y componentes del Indexador que facilitan sus interacciones con la red.

• Base de datos PostgreSQL: El almacén principal para Graph Node, aquí es donde se almacenan los datos del subgrafo. El servicio y el agente del indexador también utilizan la base de datos para almacenar datos del canal de estado, modelos de costos, reglas de indexación y acciones de allocation.

• Data endpoint - Para redes compatibles con EVM, Graph Node necesita estar conectado a un endpoint que exponga una API de JSON-RPC compatible con EVM. Esto puede tomar la forma de un solo cliente o podría ser una configuración más compleja que balancea la carga en múltiples clientes. Es importante tener en cuenta que ciertos subgrafos requerirán capacidades específicas del cliente, como el modo de archivo y / o la API de trazado de paridad.

• Nodo IPFS (versión inferior a 5): Los metadatos de deploy de Subgrafo se almacenan en la red IPFS. El Graph Node accede principalmente al nodo IPFS durante el deploy del subgrafo para obtener el manifiesto del subgrafo y todos los archivos vinculados. Los Indexadores de la red no necesitan alojar su propio nodo IPFS, un nodo IPFS para la red está alojado en https://ipfs.network.thegraph.com.

• Servicio de Indexador: Gestiona todas las comunicaciones externas necesarias con la red. Comparte modelos de costos y estados de indexación, transfiere solicitudes de consulta desde el gateway a Graph Node y administra los pagos de consultas a través de canales de estado con la gateway.

• Agente Indexador: Facilita las interacciones de los Indexadores on-chain, incluido el registro en la red, la gestión de deploy de subgrafos en sus Graph Node y la gestión de allocations.

• Servidor de métricas de Prometheus - Los componentes Graph Node y el Indexer registran sus métricas en el servidor de métricas.

Nota: Para admitir el escalado ágil, se recomienda que las inquietudes de consulta e indexación se separen entre diferentes conjuntos de nodos: nodos de consulta y nodos de índice.

• SDK de Google Cloud
• Herramienta de línea de comandos de Kubectl
• Terraform

• Clona o navega hasta el repositorio del Indexador.

• Navega al directorio ./terraform, aquí es donde se deben ejecutar todos los comandos.

cd terraform

• Autentícate con Google Cloud y crea un nuevo proyecto.

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

• Usa la página de facturación de Google Cloud Console para habilitar la facturación del nuevo proyecto.

• Crea una configuración de 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

• Habilita las API requeridas de 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

• Crea una cuenta de servicio.

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

• Habilita el emparejamiento entre la base de datos y el cluster de Kubernetes que se creará en el siguiente paso.

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

• Crea un archivo de configuración mínimo de terraform (actualiza según sea necesario).

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

Antes de ejecutar cualquier comando, lee variables.tf y crea un archivo terraform.tfvars en este directorio (o modifica el que creamos en el último paso). Para cada variable en la que deseas anular el valor predeterminado, o donde necesites establecer un valor, ingresa una configuración en terraform.tfvars.

• Ejecuta los siguientes comandos para crear la infraestructura.

# 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

Descarga las credenciales para el nuevo clúster en ~/.kube/config y configúralo como tu contexto predeterminado.

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

• Copia el directorio k8s/overlays a un nuevo directorio $dir, y ajusta la entrada bases en $dir/kustomization.yaml para que apunte al directorio k8s/base.

• Lee todos los archivos en $dir y ajusta cualquier valor como se indica en los comentarios.

Despliega todas las fuentes usando kubectl apply -k $dir.

Graph Node es una implementación de Rust de código abierto que genera eventos en la blockchain Ethereum para actualizar de manera deterministica un almacén de datos que se puede consultar a través del endpoint GraphQL. Los desarrolladores usan subgrafos para definir su esquema, y ​​un conjunto de mapeos para transformar los datos provenientes de la blockchain y Graph Node maneja la sincronización de toda la cadena, monitorea nuevos bloques y sirve a través de un endpoint GraphQL.

• Rust

• PostgreSQL

• IPFS

• Requisitos adicionales para usuarios de Ubuntu: Para ejecutar un nodo Graph en Ubuntu, es posible que se necesiten algunos paquetes adicionales.

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

1. Inicia un servidor de base de datos PostgreSQL

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

2. Clona el repositorio Graph Node y crea la fuente ejecutando cargo build

3. Ahora que todas las dependencias están configuradas, inicia el nodo Graph:

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 node - De forma predeterminada, la configuración de composición de Docker utilizará la mainnet: http://host.docker.internal:8545 para conectarse al nodo Ethereum en tu máquina alojada. Puedes reemplazar este nombre de red y url actualizando docker-compose.yaml.

1. Clona Graph Node y navega hasta el directorio de Docker:

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

2. Solo para usuarios de Linux: usa la dirección IP del host en lugar de host.docker.internal en docker-compose.yaml usando el texto incluido:

./setup.sh

3. Inicia un Graph Node local que se conectará a tu endpoint de Ethereum:

docker-compose up

Para participar con éxito en la red se requiere una supervisión e interacción casi constantes, por lo que hemos creado un conjunto de aplicaciones de Typecript para facilitar la participación de una red de Indexadores. Hay tres componentes de Indexador:

• Agente Indexador - El agente monitorea la red y la propia infraestructura del Indexador y administra qué deploy de subgrafos se indexan y asignan on-chain y cuánto se asigna a cada uno.

• Servicio de Indexador: El único componente que debe exponerse externamente, el servicio transfiere las consultas de subgrafo al graph node, administra los canales de estado para los pagos de consultas, comparte información importante para la toma de decisiones a clientes como las gateways.

• CLI de Indexador: La interfaz de línea de comandos para administrar el agente Indexador. Permite a los Indexadores administrar modelos de costos, allocations manuales, acciones en fila y reglas de indexación.

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

• Extrae imágenes del registro

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

O crea imágenes localmente desde la fuente

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

• Ejecuta los componentes

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

NOTA: Después de iniciar los contenedores, se debe poder acceder al servicio del Indexador en http://localhost:7600 y el agente del Indexador debe exponer la API de administración del Indexador en http://localhost:18000/.

Consulta la sección Setup Server Infrastructure Using Terraform on Google Cloud

graph-indexer-agent start \
  --ethereum <MAINNET_ETH_ENDPOINT> \
  --ethereum-network mainnet \
  --mnemonic <MNEMONIC> \
  --indexer-address <INDEXER_ADDRESS> \
  --graph-node-query-endpoint http://localhost:8000/ \
  --graph-node-status-endpoint http://localhost:8030/graphql \
  --graph-node-admin-endpoint http://localhost:8020/ \
  --public-indexer-url http://localhost:7600/ \
  --indexer-geo-coordinates <YOUR_COORDINATES> \
  --index-node-ids default \
  --indexer-management-port 18000 \
  --metrics-port 7040 \
  --network-subgraph-endpoint https://gateway.network.thegraph.com/network \
  --default-allocation-amount 100 \
  --register true \
  --inject-dai true \
  --postgres-host localhost \
  --postgres-port 5432 \
  --postgres-username <DB_USERNAME> \
  --postgres-password <DB_PASSWORD> \
  --postgres-database indexer \
  --allocation-management auto \
  | pino-pretty

SERVER_HOST=localhost \
SERVER_PORT=5432 \
SERVER_DB_NAME=is_staging \
SERVER_DB_USER=<DB_USERNAME> \
SERVER_DB_PASSWORD=<DB_PASSWORD> \
graph-indexer-service start \
  --ethereum <MAINNET_ETH_ENDPOINT> \
  --ethereum-network mainnet \
  --mnemonic <MNEMONIC> \
  --indexer-address <INDEXER_ADDRESS> \
  --port 7600 \
  --metrics-port 7300 \
  --graph-node-query-endpoint http://localhost:8000/ \
  --graph-node-status-endpoint http://localhost:8030/graphql \
  --postgres-host localhost \
  --postgres-port 5432 \
  --postgres-username <DB_USERNAME> \
  --postgres-password <DB_PASSWORD> \
  --postgres-database is_staging \
  --network-subgraph-endpoint https://gateway.network.thegraph.com/network \
  | pino-pretty

Indexer CLI es un complemento para @graphprotocol/graph-cli accesible en la terminal de graph indexer.

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

La herramienta sugerida para interactuar con la API de gestión de Indexadores es la CLI de Indexadores, una extensión de la Graph CLI. El agente del Indexador necesita información de un Indexador para interactuar de forma autónoma con la red en nombre del Indexador. El mecanismo para definir el comportamiento del agente Indexador son el modo de gestión de allocation y las reglas de indexación. En modo automático, un Indexador puede utilizar reglas de indexación para aplicar su estrategia específica de selección de subgrafos para indexar y servir consultas. Las reglas se gestionan a través de una API GraphQL servida por el agente y conocida como API de gestión de Indexadores. En modo manual, un Indexador puede crear acciones de allocation utilizando las acciones en fila y aprobarlas explícitamente antes de que se ejecuten. En el modo de supervisión, las reglas de indexación se utilizan para rellenar las acciones en fila y también requieren aprobación explícita para su ejecución.

La CLI del Indexador se conecta al agente Indexador, normalmente a través del reenvío de puertos, por lo que no es necesario que CLI se ejecute en el mismo servidor o clúster. Para ayudarte a comenzar y proporcionar algo de contexto, la CLI se describirá brevemente aquí.

• graph indexer connect <url> - Conéctate a la API de administración del Indexador. Normalmente, la conexión al servidor se abre mediante el reenvío de puertos, por lo que la CLI se puede operar fácilmente de forma remota. (Ejemplo: kubectl port-forward pod/<indexer-agent-pod> 8000:8000)

• graph indexer rules get [options] <deployment-id>[<key1> ...] - Obtén una o más reglas de indexación usando all <deployment-id> para obtener todas las reglas, o global para obtener los valores globales predeterminados. Se puede usar un argumento adicional --merged para especificar que las reglas específicas de implementación se fusionan con la regla global. Así es como se aplican en el agente Indexador.

• graph indexer rules set [options] <deployment-id> <key1> <value1> ... - Establece una o más reglas de indexación.

• graph indexer rules start [options] <deployment-id> - Empieza a indexar un deploy de subgrafo si está disponible y establece su decisionBasis en always, por lo que el agente Indexador siempre elegirá indexarlo. Si la regla global se establece en siempre, se indexarán todos los subgrafos disponibles en la red.

• graph indexer rules stop [options] <deployment-id> - Deja de indexar un deploy y establece tu decisionBasis en never (nunca), por lo que omitirá este deploy cuando decida qué deploy indexar.

• graph indexer rules maybe [options] <deployment-id> - Configura thedecisionBasis para un deploy en rules, de modo que el agente Indexador use las reglas de indexación para decidir si debe indexar este deploy.

• graph indexer actions get [options] <action-id> - Obtiene una o más acciones usando all o deja action-id vacío para obtener todas las acciones. Un argumento adicional --status se puede utilizar para imprimir todas las acciones de un determinado estado.

• graph indexer action queue allocate <deployment-id> <allocation-amount> - Acción de allocation en fila

• graph indexer action queue reallocate <deployment-id><allocation-id><allocationAmount> - Acción de reallocation en fila

• graph indexer action queue unallocate <deployment-id><allocation-id> - Acción de unallocation en fila

• graph indexer actions cancel [<action-id> ...] - Cancela todas las acciones de la fila si id no se especifica, en caso contrario cancela una matriz de id con espacio como separador

• graph indexer actions approve [<action-id> ...] - Aprobar múltiples acciones para su ejecución

• graph indexer actions execute approve - Forzar al trabajador a ejecutar acciones aprobadas inmediatamente

Todos los comandos que muestran reglas en la salida pueden elegir entre los formatos de salida admitidos (table, yaml y json) utilizando el argumento -output.

Las reglas de indexación se pueden aplicar como valores predeterminados globales o para deploy de subgrafos específicos usando sus ID. Los campos deployment y decisionBasis son obligatorios, mientras que todos los demás campos son opcionales. Cuando una regla de indexación tiene rules como decisionBasis, el agente Indexador comparará los valores de umbral no nulos en esa regla con los valores obtenidos de la red para la deploy correspondiente. Si el deploy del subgrafo tiene valores por encima (o por debajo) de cualquiera de los umbrales, se elegirá para la indexación.

Por ejemplo, si la regla global tiene un minStake de 5 (GRT), cualquier implementación de subgrafo que tenga más de 5 (GRT) de participación (stake) asignado a él será indexado. Las reglas de umbral incluyen maxAllocationPercentage, minSignal, maxSignal, minStake y minAverageQueryFees.

Modelo de Datos:

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
}

Ejemplo de uso de la regla de indexación:

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

El Indexador-cli proporciona un módulo de acciones para trabajar manualmente con la fila de acciones. Utiliza la API Graphql alojada en el servidor de gestión del Indexador para interactuar con la fila de acciones.

El trabajador de ejecución de acciones sólo tomará elementos de la fila para ejecutarlos si tienen ActionStatus = approved. En la ruta recomendada, las acciones se añaden a la fila con ActionStatus = queued, por lo que deben ser aprobadas para poder ejecutarse on-chain. El flujo general será el siguiente:

• Acción añadida a la fila por la herramienta optimizadora de terceros o el usuario de Indexer-cli
• El Indexador puede utilizar el indexer-cli para ver todas las acciones en fila
• Indexador (u otro software) puede aprobar o cancelar acciones en la fila utilizando indexer-cli. Los comandos de aprobación y cancelación toman una variedad de ids de acciones como entrada.
• El trabajador de ejecución sondea regularmente la fila en busca de acciones aprobadas. Tomará las acciones approved de la fila, intentará ejecutarlas y actualizará los valores en la base de datos en función del estado de la ejecución de success o failed.
• Si una acción tiene éxito, el trabajador se asegurará de que haya una regla de indexación presente que indique al agente cómo gestionar la allocation en el futuro, lo que es útil cuando se toman acciones manuales mientras el agente está en modo auto o de oversight.
• El Indexador puede supervisar la fila de acciones para ver un historial de la ejecución de las acciones y, si es necesario, volver a aprobar y actualizar los elementos de acción si fallan en su ejecución. La fila de acciones proporciona un historial de todas las acciones en fila y ejecutadas.

Modelo de Datos:

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
}

Ejemplo de uso de la fuente:

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

Ten en cuenta que los tipos de acción admitidos para la gestión de la allocation tienen diferentes requisitos de entrada:

• Allocate - asignar stake a un deploy de subgrafos específico

  • parámetros de acción requeridos:
    • deploymentID
    • cantidad

• Unallocate - cierra la allocation, liberando el stake para reasignar en otro lugar

  • parámetros de acción requeridos:
    • allocationID
    • deploymentID
  • parámetros de acción opcionales:
    • poi
    • force (obliga a utilizar el POI proporcionado aunque no coincida con lo que proporciona el graph-node)

• Reallocate - cerrar atómicamente la allocation y abrir una allocation nueva para el mismo deploy de subgrafos

  • parámetros de acción requeridos:
    • allocationID
    • deploymentID
    • cantidad
  • parámetros de acción opcionales:
    • poi
    • force (obliga a utilizar el POI proporcionado aunque no coincida con lo que proporciona el graph-node)

Los modelos de costes proporcionan precios dinámicos para las consultas basados en el mercado y los atributos de la consulta. El Servicio de Indexadores comparte un modelo de costes con las gateway para cada subgrafo para el que pretenden responder a las consultas. Las gateway, a su vez, utilizan el modelo de costes para tomar decisiones de selección de Indexadores por consulta y para negociar el pago con los Indexadores elegidos.

El lenguaje Agora proporciona un formato flexible para declarar modelos de costos para consultas. Un modelo de precios de Agora es una secuencia de declaraciones que se ejecutan en orden para cada consulta de nivel superior en una consulta GraphQL. Para cada consulta de nivel superior, la primera declaración que coincide con ella determina el precio de esa consulta.

Una declaración se compone de un predicado, que se utiliza para hacer coincidir consultas GraphQL, y una expresión de costo que, cuando se evalúa, genera un costo en GRT decimal. Los valores en la posición del argumento nombrado de una consulta pueden capturarse en el predicado y usarse en la expresión. Los globales también se pueden establecer y sustituir por marcadores de posición en una expresión.

Ejemplo de modelo de costos:

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

Ejemplo de modelo de costo usando el modelo anterior:

Los modelos de costos se aplican a través de la CLI del Indexador, que los pasa a la API de Administración de Indexador del agente Indexador para almacenarlos en la base de datos. Luego, el Servicio del Indexador los recogerá y entregará los modelos de costos a las gateway siempre que los soliciten.

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

Los primeros pasos para participar en la red como Indexador son aprobar el protocolo, stakear fondos y (opcionalmente) configurar una dirección de operador para las interacciones diarias del protocolo. _ Nota: Para propósito de estas instrucciones, Remix se utilizará para la interacción del contrato, pero no dudes en utilizar la herramienta que elijas ([OneClickDapp](https://oneclickdapp.com/), ABItopic y MyCrypto son algunas otras herramientas conocidas)._

Una vez que un Indexador ha stakeado GRT en el protocolo, los Indexer components pueden iniciarse y comenzar sus interacciones con la red.

1. Abre la Remix app en un navegador

2. En el File Explorer, crea un archivo llamado GraphToken.abi con token ABI.

3. Con GraphToken.abi seleccionado y abierto en el editor, cambia a la sección Implementar (Deploy) y Run Transactions en la interfaz Remix.

4. En entorno, selecciona Injected Web3 y en Account selecciona tu dirección de Indexador.

5. Establece la dirección del contrato GraphToken: pega la dirección del contrato GraphToken (0xc944E90C64B2c07662A292be6244BDf05Cda44a7) junto a At Address y haz clic en el botón At address para aplicar.

6. Llame a la función approve(spender, amount) para aprobar el contrato de Staking. Completa spender con la dirección del contrato de Staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9) y amount con los tokens en stake (en wei).

1. Abre la Remix app en un navegador

2. En el File Explorer, crea un archivo llamado Staking.abi con la ABI de staking.

3. Con Staking.abi seleccionado y abierto en el editor, cambia a la sección Deploy y Run Transactions en la interfaz Remix.

4. En entorno, selecciona Injected Web3 y en Account selecciona tu dirección de Indexador.

5. Establece la dirección del contrato de staking - Pega la dirección del contrato de Staking (0xF55041E37E12cD407ad00CE2910B8269B01263b9) junto a At Address y haz clic en el botón At address para aplicar.

6. Llama a stake() para stakear GRT en el protocolo.

7. (Opcional) Los Indexadores pueden aprobar otra dirección para que sea el operador de su infraestructura de indexación a fin de separar las claves que controlan los fondos de las que realizan acciones cotidianas, como la asignación en subgrafos y el servicio de consultas (pagadas). Para configurar el operador, llama a setOperator() con la dirección del operador.

8. (Opcional) Para controlar la distribución de recompensas y atraer estratégicamente a los Delegadores, los indexadores pueden actualizar sus parámetros de delegación actualizando su indexingRewardCut (partes por millón), queryFeeCut (partes por millón) y cooldownBlocks (número de bloques). Para hacerlo, llama a setDelegationParameters(). El siguiente ejemplo establece queryFeeCut para distribuir el 95% de los reembolsos de consultas al Indexador y el 5% a los Delegadores, establece indexingRewardCut para distribuir el 60% de las recompensas de indexación al Indexador y el 40% a los Delegadores, y establece thecooldownBlocks período a 500 bloques.

setDelegationParameters(950000, 600000, 500)

Después de ser creada por un Indexador, una allocation saludable pasa por cuatro fases.

• Activo: Una vez que se crea una allocation on-chain (allocateFrom()) se considera activa. Una parte del staking propio y/o delegado del Indexador se asigna a un deploy de subgrafo, lo que le permite reclamar recompensas de indexación y atender consultas para ese deploy de subgrafo. El agente Indexador gestiona la creación de allocations basadas en las reglas del Indexador.

• Cerrado: Un Indexador puede cerrar una allocation una vez que haya pasado 1 ciclo (closeAllocation()) o su agente Indexador cerrará automáticamente la allocation después de maxAllocationEpochs (actualmente 28 días). Cuando una allocation se cierra con una prueba válida de indexación (POI), sus recompensas de indexación se distribuyen al Indexador y sus Delegadores (consulta "¿Cómo se distribuyen las recompensas?" a continuación para obtener más información).

Se recomienda a los Indexadores que utilicen la funcionalidad de sincronización fuera de la cadena para sincronizar el deploy de subgrafos con el cabezal de la cadena antes de crear la allocation on-chain. Esta función es especialmente útil para subgrafos que pueden tardar más de 28 épocas en sincronizarse o que tienen algunas posibilidades de fallar de forma indeterminada.