Rollups: что именно выносят за пределы основного блокчейна

Представьте, что вы отправили перевод в сети второго уровня, увидели его почти сразу и заплатили меньше, чем обычно в Ethereum. Где в этот момент находится ваша операция? Кто проверил, что результат верен? И что произойдёт, если оператор исчезнет? Ответ не помещается в короткую формулу «L2 наследует безопасность Ethereum»: у разных rollup-систем разные способы исполнения, публикации данных, проверки состояния и вывода средств.

Rollup — это не просто «вторая сеть поверх первой». Это набор взаимосвязанных механизмов. Исполнение может происходить отдельно от Ethereum, но для самостоятельной проверки пользователям нужны данные о переходах состояния, а мосту — способ решить, какой результат считать допустимым. Одно звено не заменяет остальные.

1. Исполнение и расчёт — разные места работы

В обычном Ethereum каждый узел, который проверяет блок, исполняет его транзакции и приходит к результату самостоятельно. Этот подход прозрачен, но имеет предел пропускной способности: все участники должны обработать общий поток операций. Rollup выносит исполнение в отдельную среду. Там транзакции упорядочиваются и применяются к состоянию L2; затем система передаёт в Ethereum информацию, по которой можно подтвердить или оспорить результат.

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

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

2. Данные: что публикуют на L1 и зачем

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

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

До EIP-4844 rollup-пакеты часто попадали в calldata транзакций Ethereum. Такой способ встраивает информацию в историю исполнения. EIP-4844, опубликованный в феврале 2022 года и включённый в обновление Dencun 13 марта 2024 года, добавил транзакции с blob-данными. Контракты исполнения не читают содержимое blob напрямую: в блоке доступны криптографические обязательства, а консенсусная сеть обеспечивает ограниченное окно распространения и проверки данных. Это отдельный, временный канал для больших объёмов информации.

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

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

3. Оптимистический подход: результат можно оспорить

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

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

В июне 2024 года Optimism объявил о запуске permissionless fault proofs в OP Mainnet и переходе к Stage 1 по собственному описанию. Но тот же анонс указывал на сохранявшуюся возможность вмешательства Security Council и возврата к разрешённому режиму при сбое. Это хороший пример того, почему термин «без разрешений» нужно читать вместе с полномочиями аварийного управления. Из этого исторического объявления нельзя делать вывод о текущем состоянии сети в сентябре 2026 года; здесь оно показывает конкретный этап развития проекта к моменту публикации источника.

4. Доказательства корректности: проверка до принятия

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

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

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

5. Секвенсор, мост и путь назад

Для пользователя важен не только вход в L2, но и выход. При переходе между сетями мост должен понять, какое состояние достаточно надёжно, чтобы разрешить выдачу средств на другой стороне. У оптимистических систем это часто связано с периодом оспаривания и дополнительными ожиданиями; у систем с доказательством корректности — с принятием доказательства и правилами контракта. Сторонний «быстрый мост» может выдать ликвидность раньше, но это отдельный сервис с собственными рисками и платой.

Документация Arbitrum Nitro, например, описывает роллап-модель, в которой входы сети фиксируются на Ethereum, а корректность утверждений может оспариваться в установленном challenge period. Документ также описывает разные роли валидаторов: от тех, кто предлагает утверждения, до наблюдателей, которые ждут возможности вмешаться. Это иллюстрирует, что «кто-то может проверить» — не то же самое, что «каждый пользователь обязан запускать валидатор»; важны конкретные стимулы и время реакции.

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

Такое разделение ролей видно уже в ранних публичных объяснениях rollup. В видео Finematics, опубликованном ethereum.org 14 апреля 2021 года, базовый процесс описан как исполнение вне основной цепи, пакетирование и публикация данных на Ethereum; отдельно отмечено, что контракты L1 участвуют в депозитах, выводах и проверке. Это доступное введение полезно как схема, но оно отражает состояние объяснений 2021 года. После появления blob-данных в 2024 году часть технических деталей изменилась, поэтому старый материал лучше читать вместе с более поздним EIP, а не как исчерпывающую инструкцию.

Для бытовой оценки полезно пройти путь «от кнопки до выхода»: кто принимает транзакцию; как она входит в блок; где публикуются необходимые данные; кто проверяет переход; сколько длится финализация; какие ключи могут менять систему; как вывести активы при недоступности интерфейса или оператора. Удобный интерфейс может скрыть все эти этапы, но не отменяет их. Это не обязательно означает, что каждому пользователю придётся запускать полный узел: независимая проверка может выполняться разными участниками и программами. Но пользователь должен понимать, какой участник способен обнаружить ошибку и каким образом он успеет вмешаться.

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

6. Сравнивайте границы доверия, а не рекламные ярлыки

У любого rollup есть границы, и их нельзя свести к одному числу комиссии. Пользователь может доверять контракту на Ethereum для финального расчёта, но одновременно зависеть от секвенсора для быстрого включения, от хранителей данных для восстановления, от prover-системы или наблюдателей для защиты переходов и от управляющего совета для обновлений. Эти роли можно распределять по-разному; одна и та же сеть со временем способна менять их.

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

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

Вместо одного ярлыка — карта механизмов

Rollup переносит часть исполнения за пределы L1, чтобы повысить пропускную способность и снизить стоимость для пользователя. Но целостная модель требует ответов о том, как формируется порядок операций, какие данные публикуются, как проверяется переход состояния и можно ли выйти при сбое. EIP-4844 изменил экономику публикации данных Ethereum, добавив временные blob-данные; он не сделал все роллапы одинаковыми и не превратил временное хранение в вечный архив.

В следующий раз, когда увидите надпись «быстро, дёшево и защищено Ethereum», проверьте четыре вещи: доступность данных, механизм доказательства или спора, возможность принудительного выхода и полномочия обновления. Именно их сочетание объясняет, что система выносит за пределы основного блокчейна — и какие обязанности оставляет пользователю или другим участникам.

Источники и документы

1. Vitalik Buterin, “An Incomplete Guide to Rollups”, 5 января 2021. Исходная рамка различий между типами rollup.
2. EIP-4844: Shard Blob Transactions, создан 25 февраля 2022; окончательная спецификация. Формат blob-транзакций, мотивация и параметры на момент документа.
3. Ethereum.org, Danksharding / Proto-Danksharding. Исторические сведения об активации Dencun 13 марта 2024 и назначении blob-данных; поздние изменения страницы не используются как описание после даты статьи.
4. Optimism, “Permissionless Fault Proofs and Stage 1 Arrive to the OP Stack”, 10 июня 2024. Объявленный запуск и прямо описанные полномочия Security Council.
5. Optimism Collective, Protocol Upgrade #7: Fault Proofs, финальное предложение 16 мая 2024. Планируемые изменения OP Mainnet и доверительные предположения.
6. Finematics, “Rollups: the ultimate Ethereum scaling strategy?”, опубликовано на ethereum.org 14 апреля 2021. Вводная схема исполнения, пакетирования и публикации; ограничения по времени учтены.
7. Ethereum.org, Danksharding / Proto-Danksharding. Дата активации Dencun и назначение blob-данных сверены с датированным EIP-4844; изменяемые современные описания дорожной карты не использовались для фактов о состоянии после cutoff.