Neon Tracer API: Indexing historical data on Solana

Зачем индексировать блокчейны?

Обычные ноды блокчейнов не могут делать все, что мы от них хотим. Обычный RPC блокчейн может ответить на ограниченный набор вопросов.

• Можно посмотреть баланс конкретного аккаунта на конкретном блоке. Но нельзя узнать максимальный баланс этого аккаунта на протяжении какого-то периода времени. Это можно сделать маунально: запустить множество одинаковых запросов с разными слотами, блоками, а потом придется поверх подкрутить какую-то логику из которой можно сделать вывод. Это неэффективно и нагружает ноду.
• Также можно посмотреть, владеет ли определенный аккаунт каким-то токеном. Но мы не знаем, каким набором токенов владеет конкретный юзер.
• Можно узнать текущую цену определенного токена в пуле. Но мы не можем посмотреть список цен за определенное время.

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

Кто решает проблему индексации

Etherscan индексирует транзакции и аккаунты.

The Graph дает возможность индексировать конкретные приложения в соответствии с их моделью данных.

SubQuery — конкурент The Graph, тоже индексирует приложения.

Covalent использует Wormhole Bridge, чтобы определять, какие токены есть в кошельке.

BlockScout анализирует EVM-совместимые блокчейны.

И другие проекты.

Как работает индексация блокчейнов

Ноды индексатора постоянно мониторят блокчейн на предмет формирования новых блоков, новых транзакций, также периодически опрашивают блокчейн о балансах, состоянии кода, количестве транзакций, значениях в ячейках стораджа и т.д.

Оракулы отправляют эти данные в специальные стораджи. Поверх этого они строят API для получения агрегированной информации. Как правило, это API на основе Graph QL.

Что такое Neon EVM

При чем тут Solana? Идея Neon EVM в том, чтобы объединять экосистемы и пользователей. Ключевые продукты проекта. Neon Proxy — HTTP-сервер, который предоставляет Ethereum-подобный интерфейс. Далее сервис оборачивает Ethereum-транзакции в Solana-транзакции и запускает их на блокчейне Solana.

На Solana есть смарт-контракт Neon EVM — layer2 или виртуальная машина внутри виртуальной машины. Она исполняет смарт-контракты Ethereum. Смарт-контракты из Ethereum могут взаимодействовать с программами Solana, например, с ликвидностью. Можно деплоить контракты без изменений — абсолютно тот же байт-код и те же тулзы.

Модель данных в Ethereum

Как мы уже упоминали, у нод ограниченный набор реквестов:

• nonce;
• балансы;
• значение стораджа;
• и так далее.

В Ethereum для каждого блока есть state root, из которого можно получить доступ к состоянию аккаунта в данный момент времени. Обработка данных от индексатора сводится к тому, чтобы найти нужный блок, проследовать в state root, от туда — в необходимый аккаунт, и вычитать нужные данные.

Модель данных в Solana

В Solana есть два раздельных хранилища данных. В одном хранятся блоки и транзакции, в другом — аккаунты. Хранилище аккаунтов лежит на диске и часть из них лежит в хэше. Но это только текущее состояние аккаунтов, но у каждого аккаунта может быть разные версии. Это зависит от того, был ли этот аккаунт финализирован или изменен только на определенной ноде. Нет исторического состояния аккаунтов, а индексаторам эти данные нужны.

Решение состоит в том, чтобы мониторить Solana Validator на предмет изменения аккаунтов. При каждом изменении аккаунта он дампится во внешний сторадж.

Что такое Geyser plugin

В Solana есть механизм Geyser plugin — унифицированный интерфейс для расширений. Они получают данные об изменениях в блокчейне от валидатора. Мы реализовали Neon dumper plugin на основе Geyser plugin. Его основная задача — перехватывать изменения аккаунтов, с которыми работает Neon EVM и дампить их в Dumper DB, где их проиндексируют по блокам.

Как работает Neon Tracer API

Solana Validator работает с Dumper plugin, который пересылает дамп аккаунтов в Dumper DB. Tracer API реализует методы: get cod, balance, storage head и прочие. Над всем этим стоит Neon RPC, который роутит запросы, в завимости от того, требуются ему исторические данные или нет. Транзакции запускаются через прокси. Над всей этом схемой стоит Indexer, к которому в итоге попадает информация.

Проблемы внедрения Neon Tracer API

• Периодически Solana-валидаторы теряют консенсус с сетью и отстают от нее. Для этого нужно внедрить резервных валидаторов. Они должны хранить данные где-то в одном месте. Для этого нужно подключить кластер, к которому подключаем валидаторов.
• Поток данных может быть большой. Аккаунты в Solana устроены немного иначе, чем в Ethereum. Это больше похоже на файл — он может хранить очень много данных. Для решения проблемы нужно использовать ClickHouse, который сжимает данные.