Крипто әлеміндегі жаңалықтар

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

Так скорость генерации данных стала местами превышать инфраструктурные возможности их обработки. Как в связи с этим меняется блокчейн — разобрался ForkLog.

Чем быстрее, тем дольше 

Лет десять назад развитие блокчейнов описывали через так называемую трилемму масштабируемости. Согласно этой концепции, сети вынуждены искать компромисс между безопасностью, децентрализацией и производительностью. Но в 2026 году становится очевидно, что даже если проблему пропускной способности удается частично решить, возникает новый вызов.

Сам по себе блокчейн не имеет пользовательских интерфейсов. Эту роль берут на себя различные приложения. А они в свою очередь должны постоянно получать данные:

• балансы адресов;
• историю транзакций;
• состояние смарт-контрактов;
• события и логи;
• рыночную аналитику;
• данные для риск-менеджмента;
• межсетевые сообщения.

Чем быстрее работает сеть, тем больше подобных данных необходимо обрабатывать. 

Среди пользователей существует распространенное заблуждение: если информация записана в блокчейн, значит, ее просто получить. На практике все ровно наоборот. Считывать «сырые» данные напрямую из блокчейна в реальном времени — это медленный, дорогой и технически сложный процесс. В Web3-экосистеме широко распространен промежуточный инфраструктурный слой, который связывает кошельки с dapp-приложениями.

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

Процесс устроен следующим образом:

1. Сбор данных: Специальные программы непрерывно «читают» блокчейн по мере появления новых блоков.
2. Индексация (структурирование): Они парсят (разбирают) эти данные и раскладывают их по классическим, очень быстрым базам данных (например, PostgreSQL или ClickHouse). Там они структурированы в удобном виде: «Адрес — Список всех его токенов».
3. Мгновенный ответ: Кошелек получает уже готовый, отфильтрованный ответ из кэша за миллисекунды.

Фактически большинство популярных Web3-приложений работают через дополнительный уровень обработки информации. Представьте, если блокчейн обработал 50 000 операций за секунду, и миллионы кошельков одновременно шлют RPC-запросы, чтобы обновить экраны. Серверы провайдеров не справляются с такой нагрузкой. Прочитать, проиндексировать и отсортировать данные для пользователя — это сложнейшая вычислительная задача. Индексаторы и сервисы доступа к данным нередко отстают от актуального состояния сети на несколько блоков, поскольку обработка, структурирование и доставка данных требуют дополнительного времени. И дело не просто в «устаревшей инфраструктуре», хоть и такое, конечно, есть. А в глубинном конфликте архитектур Web2 и Web3. 

Пользователи и приложения общаются с блокчейном так же активно и часто, как в привычном интернете с мгновенным ответом. Когда вы листаете ленту соцсети, приложение делает тысячи запросов в секунду к серверу, чтобы обновить лайки, комментарии и картинки. Торговые боты в Web2 могут опрашивать сервера бирж миллионы раз в минуту. Серверы Google или Amazon легко это выдерживают, потому что они централизованы, там данные лежат, грубо говоря, в одной огромной базе, откуда их можно мгновенно скопировать на тысячи серверов-зеркал по всему миру.

Блокчейн устроен иначе, он к такому аппаратно не готов. Еще недавно в нем основной помехой скорости была математика и криптография. Надо было заставить тысячи компьютеров по всему миру быстро прийти к согласию (консенсусу), что транзакция верна. Разработчики решили эту проблему, «научив» машины осуществлять параллельное выполнение и разделять консенсус и исполнение. Например, Solana, Monad и Aptos поддерживают параллельное исполнение независимых транзакций, в отличие от классической последовательной модели Ethereum. При этом у Monad особенно явно разделены согласование порядка транзакций и их последующее исполнение, тогда как в Solana и Aptos параллелизм реализован через архитектуру runtime и управление конфликтами по состоянию.

В итоге можно одобрять десятки тысяч транзакций в секунду (TPS). Но здесь и кроется ловушка.

Исторически блокчейн выполнял сразу четыре функции:

• исполнение транзакций;
• консенсус;
• хранение данных;
• предоставление доступа к данным.

Рост производительности увеличивает нагрузку на все четыре эти функции одновременно. Система стала генерировать данные быстрее, чем инфраструктура может их читать, образуется так называемый indexer gap.

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

Аналитики ChainScore Labs называют indexer gap одной из ключевых проблем экосистемы Solana. По их оценкам, традиционные подходы к индексации плохо справляются с архитектурой сети, где высокая частота блоков и параллельное исполнение транзакций создают огромный поток данных.

Получается такой эффект: сеть может подтверждать операции почти мгновенно, но приложениям требуется существенно больше времени для обработки последствий этих операций.

Скорости Web3 уперлись в банальную физику (и не только)

А точнее — в пропускную способность процессоров, жестких дисков и сетевых кабелей. Оказалось, что масштабируемость блокчейна не равна масштабируемости инфраструктуры вокруг него. И с этим надо справиться как можно быстрее. 

Представим сеть с 100 000 TPS. Нужно не только записать транзакцию, но и:

• сохранить состояние;
• обновить индексы;
• ответить на запросы кошельков;
• обслужить ботов;
• обслужить аналитиков;
• обслужить поисковые системы;
• обслужить ИИ-агентов.

Поэтому высокая пропускная способность создает конкуренцию за ресурсы между консенсусом, исполнением транзакций и инфраструктурными сервисами поверх сети.

Параллельное развитие некоторых участвующих в нем технологий заставляет решать эту проблему уже сейчас. Для человека задержка в секунды или даже минуты может быть вполне терпима. Для ИИ-агентов, торговых систем и автономных сервисов — уже нет. Если машина принимает решения на основе ончейн-данных, то устаревшая информация означает ошибку, потерю возможности или прямой финансовый убыток.

При этом Ethereum Foundation в обновленной документации за 2026 год указывает, что архивные узлы требуют от 3 до 12 ТБ дискового пространства, а первоначальная синхронизация может занимать до месяца даже на достаточно мощном оборудовании. Ограничителем выступают скорость SSD, объем памяти и производительность процессора.

Более того, разработчики Geth отдельно описывают старую модель архивного хранения, где размер базы Ethereum мог превышать 20 ТБ, а синхронизация занимала месяцы. Именно поэтому пришлось создавать новую path-based архитектуру хранения состояний.

То есть да, «железо», процессоры, пропускная способность сети, CPU — это реальные физические ограничители в гонке за ростом информации. Но не единственные. Современные серверы уже способны обрабатывать огромные объемы данных. Вопрос в другом: сколько за это должны заплатить тысячи независимых участников сети?

Например, если для полноценного участия в экосистеме нужны десятки терабайт SSD, сотни гигабайт RAM, дорогостоящие каналы связи, то число операторов инфраструктуры неизбежно сокращается. Так возникает новая централизация.

Формально обработать данные можно, но не получится сделать это дешево и децентрализованно одновременно. Стоимость обработки информации начинает расти быстрее, чем стоимость самих транзакций.

Как отреагировал рынок

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

Если первое поколение сетей пыталось выполнять все задачи одновременно, то новое поколение разделяет обязанности между специализированными слоями. Вместо одной сети появились отдельные слои:

• execution layer — уровень исполнения (или выполнения);
• settlement layer — уровень расчетов (урегулирования);
• consensus layer — уровень консенсуса;
• data availability layer — уровень доступности данных.

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

Одним из самых быстрорастущих направлений рынка стали DA-сети. На первый взгляд идея выглядит странно: зачем создавать отдельный блокчейн для временного хранения данных другого блокчейна? Но именно это и происходит. В модульной архитектуре исполнение транзакций и хранение данных могут существовать отдельно. Rollup публикует данные во внешнем DA-слое, а не в основной сети. Это позволяет значительно снизить стоимость масштабирования и увеличить пропускную способность.

Еще несколько лет назад RPC считался технической деталью. Сегодня это один из важнейших элементов криптоинфраструктуры. В мае 2026 года Triton One совместно с Solana Foundation выпустили обновленный анонс RPC 2.0 — это новый подход к построению архитектуры чтения данных в сети. 

Ключевая идея его заключается в разделении доступа к текущему состоянию сети и ее истории. Для этого вводятся два независимых модуля: один индексирует состояние аккаунтов в реальном времени, второй оптимизирует работу с историческими данными. Вместо полного сканирования блокчейна система формирует адаптивные индексы под конкретные запросы приложений, что снижает задержки и стоимость обработки.

Так Triton и Solana пытаются устранить ряд системных ограничений: дорогую и неэффективную монолитную архитектуру RPC-узлов, узкий набор стандартных запросов JSON-RPC и зависимость разработчиков от собственных или проприетарных решений для работы с данными. В новой модели чтение масштабируется отдельно от консенсуса, а доступ к истории становится быстрее за счет использования колоночных хранилищ и предсортированных данных.

Проект опирается на уже внедренные в экосистеме инструменты — включая потоковую передачу данных из валидаторов (Geyser, Yellowstone gRPC) и решения для обработки истории. Вся инфраструктура распространяется с открытым исходным кодом, а ее развитие координируется при участии Solana Foundation.

В результате Solana фактически пытается перейти от «универсального» RPC к модульной и специализированной дата-инфраструктуре, которая якобы должна снизить барьеры для разработчиков и сделать работу с блокчейн-данными сопоставимой по удобству с традиционными базами данных.

Решает ли модульность проблему?

Если у Solana получится стандартизировать слой чтения, это может укрепить ее позицию как сети с развитой прикладной инфраструктурой, а не просто с высокой пропускной способностью. Но одновременно это усиливает конкуренцию с независимыми RPC-провайдерами и инфраструктурными платформами, которым придется либо подстраиваться под новый стандарт, либо предлагать дополнительные сервисы поверх него.

Модульная архитектура устраняет часть инфраструктурных ограничений, но переносит их в другие слои системы. Понятно стремление снизить стоимость и упростить доступ к данным, без которых не работают DeFi, NFT, кошельки, аналитика и комплаенс-инструменты. Однако, кажется, в самой природе Web3 заложен эффект каскадного усложнения: решение одной задачи неизбежно создает новые вызовы.

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

Пока что мы находимся на этапе, когда рынок сместился от конкуренции в том, кто лучше достает данные из сети, к соревнованию, кто первым создаст продукты на этих данных. Кто и сколько за это будет платить — вероятно, мы узнаем уже в ближайшее время.