Как получить доступ к данным Ethereum смарт-контракта в real-time из Python

Всем привет! Представим, что вам нужен доступ к данным каких-либо смарт-контрактов на Ethereum (или Polygon, BSC и т.д.), например, Uniswap, SushiSwap, AAVE (или даже PEPE-coin) в реальном времени, чтобы анализировать их с помощью стандартных инструментов дата-аналитиков: Python, Pandas, Matplotlib и т.д. В этом туториале я покажу инструменты для доступа к данным на блокчейне, которые больше похожи на хирургический скальпель (сабграфы The Graph), чем на швейцарский нож (доступ к RPC ноде) или, скажем, молоток (готовые API от компаний-разработчиков). Надеюсь, мои неумелые метафоры вас не пугают. Кому интересно научиться, добро пожаловать под кат.

Вот несколько методов доступа к данным в Ethereum:

• Использование команд RPC-ноды, таких как getBlockByNumber, для получения информации о блоке на низком уровне, затем доступ к данным смарт-контракта с помощью библиотек, таких как web3.py. Это позволяет получать данные блок за блоком и затем собирать их в своей собственной базе данных или CSV-файле. Этот способ не слишком быстрый, и обработка данных популярного смарт-контракта обычно занимает годы.

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

• Использование некоторых готовых API, таких как NFT API/Token API/DeFi API. И это может быть отличным вариантом, поскольку обычно задержка в них обычно мала. Единственная проблема, с которой вы можете столкнуться, - это отсутствие необходимых вам данных. Например, не все переменные могут быть доступны как исторические временные ряды.

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

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

• вам нужны данные, которые недоступны ни в одном готовом API

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

Это отличный кейс для использования сабграфов стандарта The Graph. Фактически, The Graph - это децентрализованная сеть для доступа к данным смарт-контрактов децентрализованным способом (с оплатой в их токенах GRT). Но основная технология, называемая «сабграфами», позволяет вам преобразовывать несложное описание того, какие переменные из кода смарт-контракта необходимо сохранить (для доступа в реальном времени) в настоящий ETL (Extract Transform Load) процесс, который:

• Извлекает данные из блокчейна

• Сохраняет их в базе данных

• Делает эти данные доступными через интерфейс GraphQL

• Обновляет данные после добычи каждого нового блока в сети

• Автоматически обрабатывает реорганизации блокчейна

А это довольно круто. Вам не нужно быть высококлассным дата инженером, опытным в EVM-compatible блокчейнах, чтобы настроить весь рабочий процесс.

Но давайте начнем с чего-нибудь готового к использованию. Что, если кто-то уже разработал сабграф, который помогает вам получить доступ к необходимым данным?

Вы можете перейти на сайт хостингового сервиса The Graph, найти раздел community сабграфов и попытаться найти существующие сабграфы по нужному вам протоколу. Например, давайте найдем сабграф для доступа к протоколу Lido (который позволяет пользователям стейкать свои эфиры без ограничения на минимальное значения в 32 эфира, как сейчас это требуется в нативном Ethereum).

Сейчас протокол Lido занимает первое место по общей стоимости заблокированных средств (Total Value Locked - метрика, используемая для измерения общей стоимости цифровых активов, которые заблокированы в той или иной DeFi или DApp платформе) согласно DeFiLlama.

И вуаля! Сабграф, разработанный командой протокола Lido готовый к использованию в наличии.

Теперь перейдем на страницу этого сабграфа:

Что мы можем здесь увидеть:

1. CID IPFS этого сабграфа — это внутренний уникальный идентификатор этого сабграфа, указывающий на файл манифеста этого сабграфа, хранящегося в IPFS (p2p-протокол для поиска файла по хэшу — это упрощенное утверждение, но если нужно, там легко разобраться, как это работает).

2. URL для запросов — это эндпоинт, который мы будем использовать в нашем коде на Python для доступа к данным смарт-контракта.

3. Индикатор статуса синхронизации сабграфа. Когда сабграф засинхронизирован, вы можете получить "свежие" данные, но вы также должны понимать, что при развертывании нового сабграфа вам придется подождать некоторое время, чтобы засинхронизировать его. Во время этого процесса UI будет показывать номер текущего блока в обработке.

4. GraphQL-запрос. У каждого сабграфа есть своя структура данных (список таблиц с данными), которую необходимо знать при создании GraphQL запроса. В целом, GraphQL довольно легко изучить, но если у вас возникнут проблемы с этим, вы можете попросить ChatGPT помочь с этим