Skip to main content
Блокчейн фиксирует блоки. Приложения задают вопросы вроде какие исполнения были у этого счёта на прошлой неделе и как выглядит стакан прямо сейчас — на такие вопросы запись в форме блока отвечает плохо. Индексатор переводит одно в другое. В большинстве блокчейнов индексатор — критичный элемент инфраструктуры: блокчейн выпускает непрозрачные события, а смысл из них восстанавливают третьи стороны, поэтому то, во что верит ваше приложение, зависит от того, какому индексатору оно доверяет. Здесь шага восстановления просто нет. Ядро выдаёт типизированные выходные данные с атрибуцией — каждое изменение состояния уже привязано к вызвавшей его транзакции, — поэтому индексатор переформатирует данные, а не домысливает их. Это меняет назначение индексатора: он слой отдачи данных, а не источник истины. Всё, что он сообщает, можно сверить с блокчейном, и расхождение — это баг индексатора, а не открытый вопрос.

​
Путь

деление по возрасту
Полный узелзафиксированные блоки как типизированные записи
Кешсвежее — из памяти
Файловое хранилищеистория — долговременно
Сервис данныхподаёт оба как один поток
Шлюз → REST · WebSocketдоступ, квоты, маршрутизация
Зачем это разделениеСлежение за головой чувствительно к задержке и невелико; исторические запросы велики и требуют пропускной способности. Одна дозагрузка по общему пути застопорила бы живой.
Слой отдачи данных, а не источник истиныЯдро выдаёт типизированные выходные данные с атрибуцией, поэтому индексатор переформатирует, а не домысливает. Расхождение с блокчейном — баг индексатора.
Полный узел — источник. Торговые записи вытекают из него потоком как типизированные данные, а не как сырые транзакции, требующие интерпретации. Кеш и файловое хранилище делят поток по возрасту. Свежие данные отдаются из памяти, потому что именно их хочет большинство потребителей и потому что задержка важна. Историю пишут в долговременное файловое хранилище, потому что держать всё в памяти — не стратегия. Потребитель, спрашивающий что-то старое, и потребитель, идущий за головой цепочки, обслуживаются из разных мест, и ни один из них этого не замечает. Сервис данных подаёт и то и другое как один поток. Клиент запрашивает диапазон начиная с любой точки; откуда этот диапазон отдаётся — из кеша, из файлов или из обоих источников — не его забота. Шлюз берёт на себя то, чему место между сервисом и публичным интернетом: доступ, квоты и маршрутизацию. Интерфейсы REST и WebSocket — то, чем приложения пользуются на самом деле: рыночные данные, история ордеров и исполнений, позиции, состояние счёта, платежи финансирования и живые подписки. Детали на уровне эндпоинтов — см. справочник API.

​
Зачем это разделение

Один сервис, который и следовал бы за головой цепочки, и отвечал бы на исторические запросы, не делал бы хорошо ни того ни другого. Слежение за головой чувствительно к задержке и невелико по объёму; исторические запросы чувствительны к пропускной способности и велики, и одна крупная дозагрузка застопорила бы живой путь. Разделение даёт вот что: дозагрузка нового потребителя данными многомесячной давности не портит поток маркет-мейкера, идущего за головой, и масштабировать эти два пути можно независимо — а это им нужно, потому что профили нагрузки у них не имеют ничего общего.

​
На что можно полагаться

Можно. На всё, что индексатор отдаёт на основе зафиксированных блоков: исполнения, ордера, позиции, платежи финансирования, переводы, рыночные данные. Это переформатированные выходные данные блокчейна. Это другое. Всё, что ещё не зафиксировано. Ордер, принятый в мемпул, ещё не упорядочен, и индексатору о нём сказать нечего. Отсутствие в индексаторе означает «ещё не зафиксировано», а не «отклонено». Проверяемо. Если ответ достаточно важен — спор по расчётам, аудит, бухгалтерская сверка, — его можно сверить напрямую с блокчейном, а не брать из индексатора. Самая сильная форма этого — запустить собственный полный узел; именно так и следует поступать участнику, которому нельзя ошибаться. См. Запуск узла.
Два потребителя, читающие один и тот же зафиксированный диапазон, должны получить один и тот же ответ. Если нет — расхождение сидит в пути отдачи данных, и о нём стоит сообщить как о баге, а не считать неизбежным свойством чтения блокчейна через индексатор.

​
Что дальше

Модель состояния

Что читает индексатор и какое представление авторитетно.

Разработчикам

Интерфейсы REST и WebSocket, SDK и инструменты.

Запуск узла

Как сверять с блокчейном самостоятельно и почему набор закрыт.

Программные сервисы

Кто потребляет этот поток, чтобы вычислять производное состояние счетов.