Блокчейн долго воспринимался как единая система, которая одновременно исполняет операции, подтверждает их, хранит данные и обеспечивает безопасность. Теперь эти функции все чаще разделяют между разными сетями. Зачем рынку модульная архитектура, какие расходы она снижает и какие новые риски создает.
От универсальной сети к конструктору
В классическом блокчейне все основные задачи выполняет одна сеть. Узлы принимают транзакции, проверяют их, договариваются о состоянии реестра и хранят данные. Так работают базовые уровни Bitcoin и Ethereum. Такая модель проще для понимания: безопасность и доступность системы зависят от одного набора правил и участников.
Это может вызывать проблемы при росте нагрузки. Чем больше операций обрабатывает сеть, тем больше данных должны получать и проверять ее узлы. Повышение пропускной способности обычно увеличивает требования к оборудованию, а это сокращает число участников, способных полноценно контролировать сеть. Масштабирование начинает конфликтовать с децентрализацией.
Модульная архитектура предлагает не ускорять один блокчейн, а разделить работу. Один слой исполняет транзакции, другой хранит и публикует данные, третий отвечает за консенсус, четвертый фиксирует итоговый результат. Проект может выбрать готовые компоненты и собрать инфраструктуру под конкретную задачу.
Что именно разделяют блокчейны
Слой исполнения рассчитывает, как каждая операция меняет состояние сети: кому принадлежат активы, какие условия выполнил смарт-контракт и каким стал баланс. В сетях второго уровня эту функцию берет на себя роллап, который обрабатывает операции вне базового блокчейна и затем передает ему результат.
Расчетный слой проверяет доказательства и разрешает споры. Консенсус определяет порядок блоков и подтверждает, что участники согласились с версией реестра. Слой доступности данных гарантирует, что сведения об операциях опубликованы и их можно получить для независимой проверки.
Последняя функция стала отдельным рынком. Роллапу недостаточно сообщить базовой сети новый баланс. Он должен сделать исходные данные доступными, чтобы другие участники могли восстановить состояние и выявить ошибку. Если оператор скрывает данные, формально опубликованный результат невозможно проверить.
Почему модульная модель стала востребованной
Главный стимул — стоимость. Исторически значительная часть расходов сетей второго уровня приходилась не на вычисления, а на публикацию данных в Ethereum. На странице дорожной карты Ethereum указано, что ранее хранение данных могло формировать более 90% комиссии пользователей роллапов.
Блобы появились после обновления Dencun в марте 2024 года. В отличие от обычных данных транзакций, они не хранятся в Ethereum постоянно, но остаются доступными достаточно долго для проверки роллапа. Это снизило цену публикации и показало, что Ethereum движется к более специализированной архитектуре.
Следующим шагом стал PeerDAS — выборочная проверка доступности данных. Узлу больше не требуется загружать весь объем: он проверяет небольшие случайные части и получает криптографическое подтверждение наличия остальных. Это позволяет увеличивать пространство для данных без пропорционального роста нагрузки на каждый узел.
Для разработчика это означает возможность вынести самую дорогую функцию во внешний слой. Проект сохраняет собственную среду исполнения и правила приложения, но не строит с нуля сеть валидаторов и хранилище. Запуск ускоряется, а расходы становятся ближе к фактическому объему данных.
Кто строит отдельные слои данных
Celestia позиционирует себя как модульную сеть доступности данных. Она упорядочивает и публикует массивы данных, но не исполняет пользовательские приложения. Благодаря выборочной проверке легкие узлы могут подтверждать доступность блока, не скачивая его полностью.
Интеграция Celestia с OP Stack позволяет роллапу отправлять данные не в Ethereum, а в Celestia, при этом расчеты могут по-прежнему проходить в Ethereum. Для проекта это способ снизить расходы на публикацию, не отказываясь от расчетного уровня крупнейшей экосистемы смарт-контрактов.
Avail решает похожую задачу и использует кодирование данных, криптографические обязательства и выборочную проверку. Приложения получают отдельные идентификаторы и могут извлекать только относящуюся к ним часть блока. Сеть не интерпретирует операции, а подтверждает, что данные доступны для проверки.
EigenDA построена поверх EigenLayer и использует операторов, обеспеченных повторно размещенными в стейкинге активами. Сервис принимает данные роллапов, распределяет их между операторами и выдает подтверждение доступности. Его модель связывает отдельный инфраструктурный сервис с экономической безопасностью Ethereum.
Эти решения конкурируют не только по цене. Для разработчиков важны пропускная способность, время подтверждения, число независимых операторов, правила наказания, способы проверки из Ethereum и возможность заменить поставщика без остановки сети. Низкая комиссия сама по себе не гарантирует надежную архитектуру.
Своя сеть больше не означает полную независимость
Раньше запуск отдельного блокчейна предполагал создание собственного набора валидаторов, токена безопасности, механизма консенсуса, моста и инфраструктуры хранения. Модульные инструменты позволяют собрать сеть из готовых компонентов. Но вместе с затратами проект передает внешним системам часть контроля.
Если слой данных перестает работать, роллап может продолжать вычислять операции, но пользователи не смогут независимо проверить состояние. Если сбой происходит в мосте или расчетном контракте, активы могут оказаться временно недоступны. Поэтому устойчивость определяется уже не одной сетью, а всей цепочкой компонентов.
Возникает и вопрос экономической безопасности. Собственный токен не всегда создает достаточную стоимость атаки, особенно на раннем этапе. Аренда безопасности у крупной сети или сервиса решает часть проблемы, но добавляет зависимость от его операторов, правил управления и стоимости услуг.
Переход на другой слой также не всегда прост. Форматы доказательств, контракты проверки и программное обеспечение могут быть тесно связаны с конкретным поставщиком. Проекту важно заранее предусмотреть резервный режим, возможность публикации данных в другой сети и порядок действий при длительном отказе.
Цена модульности — фрагментация
Когда приложения запускают собственные сети, пользователи и ликвидность распределяются между множеством сред. Для перевода активов требуются мосты, системы обмена сообщениями и дополнительные подписи. Интерфейс может скрывать эту сложность, но она остается внутри маршрута транзакции.
Каждый новый компонент добавляет отдельную точку отказа. Пользователь может доверять приложению, но не знать, где хранятся данные, кто управляет секвенсором, какой мост выпускает обернутый актив и где окончательно подтверждается операция. При сбое определить ответственную сторону становится сложнее.
Фрагментация влияет и на цену. Низкая комиссия внутри отдельной сети не учитывает стоимость ввода и вывода средств, обмена между экосистемами и ожидания окончательного подтверждения. Поэтому сравнивать сети только по цене одной транзакции некорректно.
Что проверять разработчику и пользователю
Для проекта модульная архитектура оправданна, если собственная среда исполнения дает измеримое преимущество: особые правила, высокая нагрузка, контроль комиссий или требования бизнеса. Запуск отдельной сети ради маркетинга создает расходы на поддержку, мосты и безопасность, которые могут превысить экономию.
До выбора слоя данных нужно оценить не заявленную максимальную скорость, а работу под реальной нагрузкой, число независимых операторов, механизм доказательства доступности, стоимость публикации и порядок восстановления после сбоя. Отдельно следует проверить, можно ли сменить поставщика без остановки приложения.
Пользователю полезно выяснить, где проходит окончательный расчет и через какой мост перемещаются активы. Чем больше промежуточных сетей участвует в операции, тем выше риск задержки или ошибки. Для крупных переводов безопаснее сначала провести небольшую тестовую транзакцию и убедиться, что вывод работает.
Инвестору важно различать спрос на приложение и спрос на инфраструктурный токен. Использование сети разработчиками не всегда автоматически создает ценность для владельцев актива. Нужно понимать, в чем оплачиваются услуги, кто получает комиссии, как устроена эмиссия и требуется ли токен для обеспечения безопасности.
Модульность не стала готовым решением проблемы масштабирования. Она перенесла часть задач из одного блокчейна в специализированные сети и дала проектам больше свободы. Выигрывают те, кто использует разделение функций для снижения расходов и повышения надежности, а не просто добавляет новые слои в уже сложную систему.