Модульные блокчейны: мечта Lego или кошмар интеграции?

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

Любой, кто когда-либо пытался собрать что-то модульное, знает, что за внешней привлекательностью часто скрывается самообман. Замена одного набора деталей Lego другим может принести разочарование, если новые детали окажутся не такими прочными, как старые. А теперь представьте, что вместо пластиковых кирпичиков и винтов у вас — допущения об окончательности расчетов, фреймворки роллапов, смарт-контракты мостов, комитеты по доступности данных, токены управления, дедлайны инвесторов, внешние аудиты и пять тысяч строк кода, сгенерированного LLM, который никто не читает, потому что окно запуска уже близко.

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

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

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

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

Celestia — это экспериментальный протокол модульного блокчейна, который также нацелен на предоставление уровня расчетов, отделенного от среды исполнения. Во многом он похож на Ethereum, но стремится быть более универсальным и «тонким»: исполняющие роллапы могут использовать его уровень доступности данных без принятия механизмов расчетов и консенсуса Ethereum. Celestia использует сэмплирование доступности данных (DAS), позволяя легким нодам проверять корректность публикации данных без загрузки всей цепочки. Вся экосистема вокруг нее также модульная: фреймворки роллапов, уровни публикации данных и другие инфраструктурные инструменты создаются отдельно, но взаимодействуют с базовой цепочкой. Спрос есть, но для Celestia, как и для многих других модульных блокчейнов, все еще только начинается.

EigenDA — это уровень доступности данных, построенный на базе EigenLayer, который позволяет роллапам на базе Ethereum использовать безопасность рестейкинга Ether в EigenDA вместо обеспечения безопасности собственных цепочек доступности данных. Avail, бывший проект Polygon, ставший самостоятельным уровнем доступности данных, является еще одним конкурентом, обещающим независимую от сетей доступность данных с проверкой через легкие клиенты и интероперабельностью. Все это интересные идеи, направленные на отделение доступности данных от расчетов и исполнения, что позволяет роллапам быть компактнее и более специализированными.

Для разработчиков привлекательность модульных блокчейнов очевидна. Вместо создания всего с нуля они могут использовать определенный фреймворк или набор хорошо зарекомендовавших себя модульных компонентов для создания своей цепочки. OP Stack, Arbitrum Orbit, ZK Stack, Polygon CDK, Agglayer CDK, Rollkit и различные предложения Rollup-as-a-Service позволяют разработчикам собирать среду исполнения по своему выбору, опираясь на устоявшиеся предположения о безопасности. Вместо запуска полноценного расчетного уровня с валидаторами, мостом, механизмом консенсуса и набором смарт-контрактов команда может запустить optimistic- или zk-роллап с доверенной настройкой всего за несколько недель. Вместо создания уровня доступности данных роллап может арендовать пространство в Ethereum или в другой сети через EigenDA или Celestia.

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

Проблема доспехов

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

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

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

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

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

Это не означает, что монолитные сети безоговорочно превосходят модульные. Единый интегрированный блокчейн имеет свои собственные риски, векторы атак, узкие места и точки отказа — свидетельством тому служат постоянно растущие проблемы безопасности Solana, Ethereum, Bitcoin и других крупных экосистем. Но монолит представляет собой более простую поверхность для нападения и защиты, с более низким общим риском, чем альтернатива. Соответственно, модульный стек может обеспечить большую масштабируемость, гибкость и простор для экспериментов, но за счет возросшей сложности и бремени дополнительных допущений о доверии.

Проблема пользовательского опыта

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

Сбои роллапов — самый наглядный пример этой проблемы. Base, один из самых популярных Ethereum L2, столкнулся с остановкой работы на 33 минуты из-за сбоя переключения секвенсора. К счастью для пользователей, их средства на самом деле оставались доступны в течение всего инцидента, но это по-прежнему отрезвляющий урок. Вся экосистема Ethereum держится на безопасности расчетов в сети Ethereum, но это не гарантирует отсутствия сбоев на уровне самих роллапов.

Другой пример — недавняя остановка секвенсора Linea после взлома Velocore. Сразу после атаки команда Linea инициировала паузу, заблокировав вывод средств пользователей. Хотя в тех обстоятельствах это, несомненно, было меньшим из зол, данный случай подчеркивает потенциальные риски модульного дизайна для UX. Пауза означала, что пользователи EVM-совместимой сети Linea не могли получить доступ к своим активам, несмотря на то, что они были защищены Ethereum. Это также послужило болезненным напоминанием о том, что многие роллапы по-прежнему сохраняют централизованный или полуцентрализованный операционный контроль над своими цепочками.

На данный момент сектор роллапов переживает настоящий взрыв разнообразия вариантов доступности данных. Различные модульные блокчейны предлагают пользователям выбор между провайдерами Rollup-as-a-Service, Celestia DA, EigenDA, Avail, blob-пространством Ethereum и другими решениями. Некоторые цепочки, включая Base, Arbitrum Nova, Linea, Scroll и другие, построены поверх существующего уровня расчетов Ethereum и используют его решения по доступности данных. Между тем, Optimism готовится запустить собственный Superchain, призванный объединить множество сетей OP под общим расчетным уровнем.

Выбор между этими вариантами редко бывает очевидным и почти никогда не делается без учета технических тонкостей. На практике большинству пользователей просто нужны быстрые и дешевые транзакции. Они не хотят забивать голову различиями между блобами и calldata или L2-сетями и их расчетами на L1. Когда речь заходит о пользовательском опыте в крипте, «модульный» часто воспринимается как синоним слова «недорогой», и аудитория у этого запроса огромна.

С другой стороны, каждая цепочка, надстроенная поверх другой, несет в себе дополнительный риск. Мосты в экосистеме Ethereum стали частой мишенью для атак в этом году, и логично ожидать, что проблемы специфики роллапов не заставят себя ждать. Чем больше уровней находится между средствами пользователя и уровнем расчетов, тем больше компонентов может отказать одновременно. И если модель угроз для сбоев роллапов не столь критична, как для мостов, то в отношении UX-дизайна этого сказать нельзя. Тот же пользователь, который не заметит разницы между Ethereum, Arbitrum Nova, Linea или Base, точно так же не поймет причин, когда одна из этих цепочек окажется «приостановлена по соображениям безопасности».

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

Ответ индустрии на этот вызов очевиден — больше строгости, лучше инструменты, качественнее проектирование. Надежные мосты с верификацией на основе легких клиентов. Доказательства с нулевым разглашением и пороговые подписи. Ограничения скорости и автоматические предохранители (circuit breakers). Децентрализованные секвенсоры и расчетные сети. Формальная верификация, мониторинг и понятный интерфейс, призванный объяснить все детали растерянным конечным пользователям. Это внутреннее напряжение в секторе модульных решений стимулирует инновации на всех уровнях — от базовых технических протоколов до самого верха.

Компромиссы вместо панацеи

Разработка программного обеспечения — это всегда поиск компромиссов. Некоторые из них очевидны, другие похоронены под документацией и юридическими оговорками. Некоторые сопутствуют каждой крупной инновации в отрасли, как, например, компромиссы, лежащие в основе EVM в Ethereum. Модульные блокчейны не исключение: они обещают гибкость и пространство для экспериментов, но не избавляют от груза дополнительной сложности. Модульные цепочки меняют относительную техническую простоту единой сети на возможности для оптимизации. Они меняют надежные гарантии безопасности на расширенную поверхность атаки. Они меняют перегруженность одного расчетного уровня на организационные накладные расходы нескольких уровней безопасности. Они меняют свободу разработчиков на децентрализацию, а чистый потенциал — на повышенную ответственность.

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

Для других команд такой компромисс далеко не столь заманчив. Если проекту не нужна собственная сеть, нет смысла ее запускать. Если команда не уверена в своих силах при создании моста, ей стоит воздержаться от этой идеи. Если организация не способна объяснить собственным пользователям риски модульной архитектуры, она тем более не сможет защитить своих клиентов. Если децентрализация всегда остается обещанием «на будущее», проект не готов к запуску. Безопасность модульной цепочки определяется ее самым слабым звеном, и если этим слабым звеном является «обещание будущих обновлений», самое время пересмотреть архитектуру.

Урок средневековья актуален и здесь: модульные доспехи не были изначально хуже любых других. Однако плохо спроектированные модульные латы было легко распознать, поскольку они часто оставляли жизненно важные участки тела незащищенными. То же самое относится и к модульным блокчейнам: обещание «единых свойств безопасности» оказывается пустышкой, если каждый уровень системы едва отвечает минимальным требованиям, небезопасен или не проверен временем.

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

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

Стоит ли оно того?

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

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

Celestia и EigenDA вместе с Avail и blob-пространством Ethereum готовы предоставить роллапам еще большую гибкость в работе с данными. OP Stack, Arbitrum Orbit, CDK и Agglayer от Polygon, форк Optimism от Linea и многие другие решения работают над снижением технического барьера для разработчиков, позволяя им запускать собственные EVM-совместимые сети. Вся индустрия вступает в захватывающую фазу развития по мере того, как техническая реализуемость мультичейн-будущего становится все более очевидной.

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

Те же принципы справедливы и для более широких трендов индустрии. Решения, направленные на автоматизацию операций в сети TRON для бизнеса, пользуются растущим спросом среди команд, которые не хотят настраивать управление Energy вручную, самостоятельно администрировать Smart Mode и Host Mode или тратить время на написание скриптов и управление API. Netts Workspace предоставляет интуитивно понятный интерфейс, объединяющий аренду Energy, Smart Mode и Host Mode, транзакции в сети TRON и контроль Energy, инструменты мониторинга, AML-проверки и финансовые операции, позволяя компаниям снижать издержки и минимизировать риски ручного управления.