Запуск Graph Node на Tenderly Node RPC

Graph Node индексирует subgraph с любой конечной точки Ethereum JSON-RPC. Направьте её на конечную точку Node RPC, чтобы индексировать публичную сеть с обработчиками событий, обработчиками вызовов и вызовами контрактов в маппингах. Эта страница проверена с Graph Node 0.45.0 в Ethereum Mainnet: subgraph с обработчиком событий, обработчиком вызовов для USDC transfer(address,uint256) и вызовом balanceOf в маппинге проиндексировался начиная с недавнего блока и отставал от головы цепочки не более чем на один блок. Чтобы индексировать форкнутую копию сети, см. Индексация Virtual Environment с помощью The Graph.

Прежде чем начать

URL Node RPC для вашей сети из раздела Integrate Node RPC в Tenderly Dashboard
Subgraph и файл docker-compose.yml, который graph init генерирует для него (см. Настройка Graph Node и subgraph; шаги создания каркаса для публичной сети те же)

Настройка провайдера Ethereum

В сгенерированном docker-compose.yml задайте для ethereum в сервисе graph-node значение <network>:archive,traces:<Node RPC URL>. Имя сети перед первым двоеточием должно совпадать с network в subgraph.yaml.

docker-compose.yml (переменные окружения graph-node)

    environment:
      postgres_host: postgres
      postgres_user: graph-node
      postgres_pass: let-me-in
      postgres_db: graph-node
      ipfs: "ipfs:5001"
      ethereum: "mainnet:archive,traces:https://mainnet.gateway.tenderly.co/${TENDERLY_NODE_ACCESS_KEY}"
      GRAPH_LOG: info

Docker Compose подставляет ${TENDERLY_NODE_ACCESS_KEY} из вашей оболочки, поэтому ключ доступа не хранится в файле:

export TENDERLY_NODE_ACCESS_KEY=<your-access-key>
docker compose up -d
docker compose logs -f graph-node

При запуске Graph Node пишет в лог capabilities: archive, traces для провайдера и Provider supports block receipts. Это означает, что она получает все квитанции блока одним запросом eth_getBlockReceipts.

Возможность	Что включает	Методы Node RPC
`archive`	Вызовы контрактов в маппингах (`ethereum.call`) на исторических блоках	`eth_call`, `eth_getBalance`, `eth_getCode` по хешу блока
`traces`	Обработчики вызовов (`callHandlers`) и обработчики блоков с фильтром `call`	`trace_filter`

Graph Node предполагает наличие обеих возможностей, если в значении ethereum они не указаны (mainnet:<url>). Объявите их явно, чтобы из конфигурации было видно, на что опирается subgraph. В публичных сетях оставьте для ETHEREUM_REORG_THRESHOLD значение по умолчанию 250. Graph Node использует его, чтобы откатывать блоки при реорганизации сети, поэтому не копируйте значение 1 из конфигурации для Virtual Environment.

Проверка поддержки trace_filter в вашей сети

Обработчикам вызовов нужен trace_filter, который обслуживают не все сети в Node RPC. Запросите один недавний блок:

URL=https://mainnet.gateway.tenderly.co/$TENDERLY_NODE_ACCESS_KEY
BLOCK=$(cast block-number --rpc-url $URL)
curl -s $URL \
  -H 'content-type: application/json' \
  -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"trace_filter\",\"params\":[{\"fromBlock\":\"$(cast to-hex $BLOCK)\",\"toBlock\":\"$(cast to-hex $BLOCK)\"}]}"

Массив в result означает, что обработчики вызовов в этой сети работают. Ошибка вроде the method trace_filter does not exist/is not available или Method not found означает, что не работают; в этом случае индексируйте события контракта с помощью eventHandlers. Передавайте номера блоков в hex, потому что trace_filter отклоняет тег latest с ошибкой Invalid params.

Запросы, которые отправляет Graph Node

Graph Node постоянно опрашивает Node RPC, поэтому каждая индексируемая сеть расходует запросы, даже когда ни у одного subgraph нет новых событий. Стоимость каждой категории запросов см. в разделе Тарификация Node RPC.

Действие Graph Node	Методы
Опрос последнего блока каждые `ETHEREUM_POLLING_INTERVAL` (по умолчанию `1000` мс)	`eth_getBlockByNumber`
Загрузка новых блоков и их квитанций	`eth_getBlockByHash`, `eth_getBlockReceipts`
Поиск событий для обработчиков событий	`eth_getLogs`
Вызовы контрактов в маппингах	`eth_call` (Compute)
Обработчики вызовов и фильтры блоков `call`	`trace_filter` (Debug and Trace)

Обработчики вызовов обходятся дороже всего в типичном subgraph на Node RPC, потому что запрос трассировки стоит больше, чем чтение или вызов контракта. Если контракт эмитирует событие для того же действия, индексируйте событие. Увеличьте ETHEREUM_POLLING_INTERVAL, чтобы опрашивать реже, если задержка индексации в несколько секунд допустима.

Устранение неполадок

Симптом	Причина	Решение
`Trying again after trace_filter RPC call ... failed`, и subgraph перестаёт продвигаться	Сеть не обслуживает `trace_filter`.	Проверьте поддержку трассировок и используйте обработчики событий в сетях без неё.
`network not supported by registrar: no network base found on chain ethereum` при `graph deploy`	`network` в `subgraph.yaml` не совпадает с именем сети в `ethereum`.	Используйте одно и то же имя в обоих местах.
`Receipt for tx ... unavailable, block was likely uncled` повторяется для одного и того же блока	Graph Node не удалось загрузить квитанции блока.	Graph Node повторяет попытки автоматически. Если один и тот же блок продолжает давать сбой, напишите на `support@tenderly.co`, указав сеть и хеш блока.

См. также

Обзор Node RPC
Тарификация Node RPC
Справочник RPC для trace_filter
Индексация Virtual Environment с помощью The Graph для индексации форкнутой сети

Getting Started

Simulator

Console

Monitor

Node RPC

AI Tools

Account & Settings

Запуск Graph Node на Tenderly Node RPC

Прежде чем начать

Настройка провайдера Ethereum

Проверка поддержки trace_filter в вашей сети

Запросы, которые отправляет Graph Node

Устранение неполадок

См. также

​Прежде чем начать

​Настройка провайдера Ethereum

​Проверка поддержки trace_filter в вашей сети

​Запросы, которые отправляет Graph Node

​Устранение неполадок

​См. также

Прежде чем начать

Настройка провайдера Ethereum

Проверка поддержки trace_filter в вашей сети

Запросы, которые отправляет Graph Node

Устранение неполадок

См. также