Все новости крипты
в одном месте!
Больше не нужно искать — необходимые
обучающие материалы и подсказки всегда под рукой
Больше не нужно искать — необходимые
обучающие материалы и подсказки всегда под рукой
Вот перефразированная версия новости на русском языке:
Заголовок: Блокчейны научились быстро записывать данные, но теперь не могут их быстро прочитать
Ещё несколько лет назад главной темой обсуждений в криптоиндустрии было то, как ускорить работу блокчейнов. Сегодня многие сети обрабатывают десятки тысяч транзакций в секунду, а некоторые заявляют о сотнях тысяч. Однако выяснилось, что записать данные — это только половина дела. Их ещё нужно найти, обработать, проверить и передать приложениям. Скорость создания данных начала обгонять возможности инфраструктуры по их обработке. Как блокчейн меняется в этих условиях, разобрался ForkLog.
Чем быстрее, тем сложнее
Десять лет назад развитие блокчейнов описывали через «трилемму» масштабируемости, где нужно выбирать между безопасностью, децентрализацией и скоростью. Но к 2026 году стало ясно: даже если проблему скорости удаётся решить, появляется новый вызов.
Сам блокчейн не имеет интерфейсов для пользователей. Эту роль выполняют приложения, которым нужно постоянно получать данные: балансы, историю операций, состояние смарт-контрактов, события, аналитику, данные для управления рисками и межсетевые сообщения. Чем быстрее работает сеть, тем больше таких данных нужно обрабатывать.
Многие ошибочно думают, что если информация есть в блокчейне, её легко получить. На деле чтение «сырых» данных в реальном времени — это медленно, дорого и технически сложно. В экосистеме Web3 существует промежуточный слой инфраструктуры, который соединяет кошельки и децентрализованные приложения (dApps). Например, чтобы показать баланс за доли секунды, кошелёк обращается к RPC-провайдерам, индексаторам, аналитическим платформам и базам данных.
Процесс выглядит так:
1. Сбор данных: программы постоянно «читают» блокчейн по мере появления новых блоков.
2. Индексация: они разбирают данные и раскладывают их в быстрые базы данных (например, PostgreSQL), где они структурированы по типу «адрес — список его токенов».
3. Мгновенный ответ: кошелёк получает готовый ответ из кэша за миллисекунды.
По сути, большинство популярных Web3-приложений работают через дополнительный уровень обработки. Если блокчейн обработал 50 000 операций в секунду, а миллионы кошельков одновременно отправляют запросы, серверы провайдеров не справляются. Индексаторы и сервисы доступа к данным часто отстают от актуального состояния сети на несколько блоков. Дело не только в устаревшей инфраструктуре, но и в глубинном конфликте архитектур Web2 и Web3.
Пользователи ожидают от блокчейна такого же мгновенного ответа, как в привычном интернете. В Web2 серверы Google или Amazon легко выдерживают миллионы запросов, потому что они централизованы и данные хранятся в одной огромной базе. Блокчейн устроен иначе. Раньше главной проблемой была скорость достижения консенсуса — согласия тысяч компьютеров по всему миру. Разработчики решили это с помощью параллельного выполнения транзакций (Solana, Monad, Aptos). Теперь можно подтверждать десятки тысяч транзакций в секунду (TPS). Но здесь кроется ловушка.
Исторически блокчейн выполнял четыре функции: исполнение транзакций, консенсус, хранение данных и предоставление доступа к ним. Рост производительности увеличивает нагрузку на все четыре функции сразу. Система генерирует данные быстрее, чем инфраструктура может их читать. Это явление называют «indexer gap» (разрыв индексации).
В документации Helius, крупного инфраструктурного провайдера для Solana, прямо сказано, что последовательная структура блокчейна хороша для целостности данных, но делает исторические запросы медленными. Аналитики ChainScore Labs называют indexer gap одной из ключевых проблем Solana. Традиционные методы индексации плохо справляются с высокой частотой блоков и параллельным исполнением.
Получается эффект: сеть может подтверждать операции почти мгновенно, но приложениям нужно гораздо больше времени, чтобы обработать последствия этих операций.
Скорости Web3 упёрлись в физику (и не только)
Масштабируемость блокчейна не равна масштабируемости инфраструктуры вокруг него. Представьте сеть со 100 000 TPS. Нужно не только записать транзакцию, но и сохранить состояние, обновить индексы, ответить на запросы кошельков, ботов, аналитиков, поисковых систем и ИИ-агентов. Высокая пропускная способность создаёт конкуренцию за ресурсы между консенсусом, исполнением и инфраструктурными сервисами.
Для человека задержка в секунды или минуты терпима. Для ИИ-агентов и торговых систем — нет. Устаревшая информация означает ошибку или финансовый убыток.
Ethereum Foundation в документации за 2026 год указывает, что архивные узлы требуют от 3 до 12 ТБ дискового пространства, а синхронизация может занимать до месяца. Разработчики Geth описывают старую модель, где размер базы Ethereum превышал 20 ТБ. Пришлось создавать новую архитектуру хранения.
«Железо» — процессоры, скорость SSD, пропускная способность сети — это реальные физические ограничители. Но не единственные. Вопрос в том, сколько за это должны платить тысячи независимых участников сети. Если для участия нужны десятки терабайт SSD и дорогие каналы связи, число операторов сокращается. Возникает новая централизация. Формально данные обработать можно, но не получится сделать это дёшево и децентрализованно одновременно.
Как отреагировал рынок
Участники рынка поняли, что победят те сети, которые смогут быстрее, дешевле и надёжнее превращать транзакции в доступную информацию. Внимание сместилось на модульные блокчейны.
Если первое поколение сетей пыталось делать всё одновременно, то новое разделяет обязанности между специализированными слоями:
* Уровень исполнения (execution layer)
* Уровень расчётов (settlement layer)
* Уровень консенсуса (consensus layer)
* Уровень доступности данных (data availability layer)
Разработчики сравнивают это с эволюцией дата-центров: раньше один сервер делал всё, теперь вычисления, хранение и сетевые сервисы масштабируются независимо.
Одним из самых быстрорастущих направлений стали DA-сети (сети доступности данных). В модульной архитектуре rollup публикует данные во внешнем DA-слое, а не в основной сети. Это снижает стоимость масштабирования.
RPC, который раньше считался технической деталью, стал важнейшим элементом инфраструктуры. В мае 2026 года Triton One совместно с Solana Foundation анонсировали RPC 2.0 — новый подход к чтению данных. Ключевая идея — разделить доступ к текущему состоянию сети и её истории. Вводятся два независимых модуля: один индексирует состояние аккаунтов в реальном времени, второй работает с историческими данными. Вместо полного сканирования блокчейна система формирует индексы под конкретные запросы приложений, снижая задержки и стоимость.
Triton и Solana пытаются устранить системные ограничения: дорогую монолитную архитектуру RPC-узлов и зависимость от проприетарных решений. В новой модели чтение масштабируется отдельно от консенсуса. Проект опирается на существующие инструменты, а код будет открытым.
Решает ли модульность проблему?
Если у Solana получится стандартизировать слой чтения, это укрепит
Популярные лонгриды:
