Подходы к индексации и стримингу блокчейн-данных в высоконагруженных сетях

Почему масштабирование RPC-запросов перестает решать проблему получения данных? В любой системе, где количество событий растёт быстрее возможностей запросной модели, наступает момент, когда простое увеличение количества запросов перестает быть эффективным. В blockchain-инфраструктуре этот момент наступает особенно быстро. Современные сети увеличивают скорость обработки транзакций, объем данных и частоту обновлений состояния. При этом традиционный подход через RPC-запросы и polling начинает сталкиваться с фундаментальными ограничениями: растёт задержка получения данных, увеличивается нагрузка на ноды, усложняется восстановление после сбоев, а обеспечение полноты истории и корректной обработки reorg становится отдельной инженерной задачей. В докладе мы разберём, почему эти ограничения связаны не с конкретными API или реализациями нод, а с самой архитектурой pull-модели. Покажем, в какой момент последовательные RPC-запросы, eth_getLogs, eth_getBlockReceipts и WebSocket-подписки перестают быть достаточными для production-систем. Основная часть доклада посвящена архитектуре потоковой обработки данных. На практических примерах рассмотрим, как построить систему, которая объединяет real-time и исторические данные, поддерживает replay, корректно обрабатывает reorg, выполняет серверную фильтрацию и позволяет масштабировать pipeline без постоянного увеличения нагрузки на источник данных. Отдельное внимание уделим архитектурным решениям, лежащим в основе Firehose и Substreams: какие задачи они решают, какие компромиссы предлагают и в каких сценариях оправдано их применение. Материал основан на опыте разработки и эксплуатации production-инфраструктуры для торговых продуктов в сетях EVM, Solana и TON. В основе доклада — реальные инженерные решения, ограничения и компромиссы, возникающие при построении систем, где требования к задержкам, полноте данных и устойчивости являются критическими.