В прошлой статье про rollup economics речь шла о конвейере: sequencer, data availability, fee flow и bridge как plumbing для ликвидности.
Но у любого rollup есть второй, часто более важный для денег вопрос: когда состояние можно считать настоящим.
Пользователь видит зелёную галочку через секунду после swap. Бот видит receipt и уже хочет открывать следующую ногу стратегии. Treasury видит баланс на L2 и уже думает о выводе в L1.
Проблема в том, что эти три «готово» — не одно и то же.
- Soft confirmation от sequencer — «я принял и исполнил твою транзакцию в своей очереди».
- Data availability — «данные батча опубликованы так, что сеть можно проверить и восстановить».
- L1 finality / settlement — «базовый слой принял доказательство или прошёл challenge, и оспорить это уже поздно или очень дорого».
Пока продукт крутит мелкие свопы, разница терпима. Как только появляются крупные выводы, liquidation deadlines, cross-chain settlement или notional limits, путаница soft confirm и finality становится операционным риском.
Ниже — разбор простыми словами: как rollup доказывает честность, чем optimistic отличается от ZK, почему вывод иногда занимает дни, что такое forced inclusion и какой automation layer имеет смысл строить вокруг finality.
Зачем продуктовой команде security model, а не только fee chart
Комиссии и latency объясняют, почему люди живут на L2. Security model объясняет, на каких условиях им можно доверять балансу.
Без этого слоя легко ошибиться в трёх местах:
- считать soft confirmation достаточным для крупного treasury move;
- обещать пользователю «вывод за минуты», хотя canonical exit идёт через challenge window;
- проектировать keeper/liquidation bot так, будто L2 всегда жива и всегда честно включает транзакции.
Иными словами: fee dashboard отвечает на вопрос «сколько стоит execution». Finality model отвечает на вопрос «когда execution можно считать settled и что делать, если sequencer врёт или молчит».
Два режима доверия: optimistic и ZK
Упрощённо rollups делятся не по брендам, а по тому, как они доказывают L1, что L2-состояние корректно.
Optimistic rollups: «считаем честным, пока не доказали обратное»
Optimistic-модель работает так:
- sequencer (или batch poster) публикует новое состояние / batch;
- система оптимистично принимает его;
- в течение challenge period любой честный участник может подать fraud proof;
- если proof успешен — неверное состояние откатывают или штрафуют;
- если challenge window прошёл без успешного спора — состояние считается принятым.
Отсюда главный продуктовый эффект: canonical withdraw часто нельзя завершить мгновенно. Нужно дождаться окна, в котором ещё можно оспорить нечестный batch.
Бытовая аналогия — банковская проводка с периодом chargeback. Деньги «уже ушли» в интерфейсе, но спорный период ещё жив.
Что это значит на практике:
- UX может быть быстрым за счёт soft confirm;
- settlement для вывода в L1 — медленнее;
- безопасность опирается на наличие хотя бы одного честного challenger и на то, что данные батча доступны для проверки.
ZK rollups: «не принимаем состояние без validity proof»
ZK-модель меняет порядок доверия:
- L2 исполняет транзакции;
- prover строит validity proof;
- L1-контракт принимает новое состояние только вместе с доказательством;
- без валидного proof переход состояния не финализируется.
Бытовая аналогия — не «подождите, пока кто-то оспорит», а «покажите математическое подтверждение, что пересчёт корректен».
Практические следствия:
- challenge window как у optimistic обычно не нужен в том же виде;
- вывод теоретически может быть быстрее по security assumptions;
- появляется другой bottleneck: proof generation lag, prover capacity, cost of proving;
- soft confirmation от sequencer всё равно может опережать момент, когда proof уже на L1.
Важно: ZK не отменяет вопрос «кому вы доверяете soft confirm». Пока proof не сел на L1, быстрый UX всё ещё опирается на оператора очереди и operational pipeline.
Что общее у обеих моделей
И optimistic, и ZK всё равно обычно содержат:
- централизованный или полуцентрализованный sequencer на ранних стадиях;
- публикацию данных (calldata / blobs / отдельный DA);
- bridge для входа и выхода;
- разрыв между «видно в UI» и «settled на L1».
Меняется не наличие этого разрыва, а чем он заполнен: временем на fraud challenge или временем/стоимостью validity proof.
Soft confirmation, DA и finality — три разные «готовности»
Чтобы не смешивать уровни, полезно держать таблицу в голове.
1. Soft confirmation
Sequencer говорит: транзакция включена в мой блок / мой порядок.
Хорошо для:
- мгновенного UX;
- локальных действий внутри L2 с маленьким notional;
- внутренних статусов бота «tx accepted by venue».
Плохо как единственный сигнал для:
- крупного вывода;
- необратимого off-ramp;
- решений, где ошибка ordering/censorship критична.
2. Data availability
Данные батча опубликованы так, что независимая сторона может восстановить состояние и при необходимости оспорить или пересчитать.
Без DA «доказательство честности» становится пустым: нечего проверять.
3. L1 settlement / hard finality
Базовый слой принял результат по правилам rollup:
- либо challenge window истёк;
- либо validity proof принят;
- либо выполнен другой protocol-defined settlement step.
Именно этот уровень обычно нужен, когда речь о canonical bridge exit и о том, что L1 больше не ждёт спора по этому состоянию.
Жизненный цикл вывода: почему delay — не баг UI
Canonical withdraw почти никогда не равен «нажал кнопку — через 12 секунд деньги на L1».
Упрощённый pipeline:
- Пользователь инициирует withdraw на L2.
- Sequencer включает транзакцию и даёт soft confirm.
- Batch с данными уходит в DA / L1 publication.
- Дальше зависит от модели:
- optimistic: стартует или продолжается challenge window вокруг релевантного состояния;
- ZK: нужен validity proof, который L1 примет.
- Bridge-контракт на L1 разблокирует / выпускает актив только после выполнения security conditions.
- Пользователь получает средства на L1 (или сообщение для claim).
Почему это важно бизнесу:
- support и product не должны обещать «мгновенный L1 exit», если речь о canonical path;
- fast bridge / liquidity network — это уже другой trust и liquidity risk, не то же самое, что protocol exit;
- treasury должен считать не только fee, но и capital lockup на время exit.
Отсюда появляется полезная метрика для ops: withdraw ETA distribution — не среднее из маркетинга, а p50/p95 реального времени от initiate до L1 claimable/settled.
Forced inclusion и escape hatch: что если sequencer молчит
Самый неприятный сценарий для L2 UX — не высокая комиссия, а отсутствие включения.
Sequencer может:
- быть в outage;
- цензурировать конкретный адрес или тип транзакций;
- принимать deposits, но тормозить withdrawals;
- давать soft confirm и не публиковать данные вовремя.
Если у rollup нет рабочего пути обойти оператора очереди, «L2 с дешёвым gas» превращается в «очередь, из которой нельзя выйти по правилам протокола».
Forced inclusion простыми словами
Forced inclusion — механизм, при котором пользователь может заставить систему учесть транзакцию, опираясь на L1 (или другой trust-minimized путь), даже если обычный sequencer её игнорирует.
Типичная идея:
- пользователь отправляет транзакцию / сообщение через L1 inbox или аналог;
- протокол обязывает rollup включить её в ограниченный срок;
- если оператор не делает этого, срабатывают штрафные / escape правила;
- в предельном случае пользователь уходит через escape hatch с доказательством своего баланса на основе доступных данных.
Детали отличаются между сетями. Продуктово важно другое: есть ли у вас runnable exit path, когда soft UX сломан.
Escape hatch — не кнопка «спасти всё за 30 секунд»
Escape hatch часто:
- медленнее обычного пути;
- требует данных / proof;
- дороже по L1 gas;
- сложнее operationally;
- почти никогда не равен красивому UI-flow из приложения.
Но его ценность именно в том, что это reserve path, а не daily UX. Для treasury и risk-команды наличие/отсутствие рабочего escape hatch — часть venue due diligence, наравне с TVL и fee.
Что это меняет для DeFi-продуктов
1. Lending и liquidation bots
Keeper, который реагирует только на soft-confirmed состояние, может:
- опоздать относительно L1-видимой правды;
- недооценить риск reorg/dispute в edge cases;
- потерять окно, если sequencer деградировал именно в stress.
Практический вывод: политики ликвидации и risk alerts должны различать L2 head и settled/safe head там, где это влияет на notional.
2. Bridge UX и treasury routing
«Быстрый вывод» почти всегда означает один из вариантов:
- canonical exit с ожиданием security window / proof;
- fast liquidity bridge, где кто-то авансирует ликвидность и берёт на себя latency/risk.
Путать их в продуктовых текстах и в risk policy опасно: пользователь думает, что получил protocol finality, а на деле получил credit от liquidity provider.
3. Notional limits при degraded finality
Нормальная ops-политика выглядит так:
- мелкие операции — можно на soft confirm;
- средние — после batch publication / короткого confirmation depth;
- крупные — только при приемлемом settlement status или через L1;
- любые операции — режутся, если растёт batch lag, proof lag, sequencer downtime или bridge backlog.
Это уже не «инфраструктурный интерес», а control plane для денег.
4. Cross-rollup стратегии
Арбитраж и delta-neutral стратегии часто живут между несколькими L2. Тогда finality mismatch становится частью PnL:
- одна нога «финальна»;
- вторая ещё только soft-confirmed;
- bridge leg зависает в challenge/proof очереди.
Без учёта этого бот оптимизирует fee и проигрывает на capital lock и failed settlement assumptions.
Типичные ошибки
1. Считать soft confirmation = finality
Самая частая ошибка продуктов и ботов. UI «Success» не равен L1 settlement.
2. Обещать пользователю canonical exit со скоростью fast bridge
Canonical security path и liquidity shortcut — разные продукты с разным risk.
3. Игнорировать challenge / proof lag в unit economics
Даже «дешёвый» L2 может быть дорогим для treasury, если капитал на дни заперт в exit queue.
4. Не проверять forced inclusion до инцидента
Escape hatch, который никто не тестировал на staging/fork и не описал в runbook, в день outage почти наверняка окажется «теоретически существует».
5. Мониторить только gas price
Для rollup ops минимум шире:
- sequencer liveness;
- time since last batch;
- DA/posting failures;
- proof backlog;
- withdraw queue depth;
- failed claims;
- расхождение indexer tip vs safe/finalized tip.
Какой automation layer имеет смысл строить
Если цель — не запустить собственный rollup, а сделать control plane вокруг finality, минимальный полезный набор такой.
1. Finality tracker
Сервис, который для каждой целевой сети отдаёт:
- latest soft head;
- last posted batch / DA timestamp;
- settled / safe head по правилам venue;
- age of unsettled gap.
Для ботов и risk engine это должен быть first-class input, а не ручной взгляд в explorer.
2. Withdraw ETA and queue monitor
Считает:
- время от initiate до claimable;
- p50/p95 по историческим выводам;
- рост backlog;
- долю failed/expired claims.
Алерты полезны и support-команде, и treasury, которая планирует L1 buffer.
3. Sequencer liveness and censorship signals
Простые, но рабочие эвристики:
- нет новых блоков дольше порога;
- собственные canary-транзакции не включаются;
- withdrawals включаются заметно хуже, чем обычные transfers;
- batch posting отстаёт от block production.
Это ещё не доказательство цензуры в юридическом смысле. Это early warning, что venue degraded.
4. Forced-inclusion readiness checks
Периодически проверять:
- доступность L1 inbox / portal;
- оценку gas на forced path;
- наличие актуальной документации/runbook;
- что indexer умеет отслеживать forced messages end-to-end.
Имеет смысл прогонять dry-run на небольших суммах по расписанию, а не читать whitepaper в ночь инцидента.
5. Policy engine для notional и routing
Правила вида:
- если
settlement_lag > X— снизить max notional; - если
proof_backlog > Y— запретить large exits через этот venue; - если sequencer unhealthy — только reduce-risk actions;
- если fast bridge liquidity thin — не маскировать его под canonical exit.
Именно здесь security model rollup становится частью product risk policy.
Как собрать тонкий MVP за понятный срок
Минимальный прототип можно собрать без попытки «понять все L2 сразу».
- Выбрать 1–2 сети, где уже есть капитал или боты.
- Индексировать:
- L2 blocks;
- batch/DA posts;
- bridge withdraw events;
- L1 finalize/claim events.
- Нормализовать статусы транзакций и выводов:
soft,posted,provable/challengeable,settled,claimable,done. - Нарисовать один dashboard: lag, ETA, liveness, queue.
- Подключить 3–5 alerts в Telegram/Pager.
- Добавить policy hooks в существующий execution bot или treasury workflow.
Стек может быть самым обычным: RPC poller, Postgres, небольшой Go/Python worker, Grafana или внутренний UI. Ценность не в «AI поверх blockchain», а в честной модели состояний.
Как эта тема стыкуется с остальным стеком
Finality — продолжение уже разобранных кусков:
- rollup fee flow и sequencer объясняют, кто зарабатывает на execution и как устроен pipeline;
- bridges объясняют, **как актив и сообщение переходят между сетями **;
- MEV / order flow объясняет, кто влияет на порядок включения;
- эта статья объясняет, когда состоянию можно доверять и что делать, если обычный путь включения сломан.
Без этого слоя картина L2 неполная: остаётся удобный UX и красивый gas, но нет ответа на вопрос про settlement assumptions.
Главное, что стоит запомнить
Rollup доказывает честность не галочкой в кошельке, а правилами, по которым L1 принимает L2-состояние.
Если упростить до сути:
- optimistic говорит «оспорь, если неверно» и поэтому часто даёт delayed canonical exit;
- ZK говорит «приложи validity proof» и переносит bottleneck на proving pipeline;
- soft confirmation ускоряет UX, но не заменяет settlement;
- forced inclusion / escape hatch — запасной путь, когда sequencer больше не ваш друг;
- automation layer нужен, чтобы finality, lag и exit ETA были измеримы до инцидента, а не после твита «sequencer issues».
Пока сеть спокойна, можно жить на soft confirms. Когда начинается stress, ключевым активом становится умение отличать «транзакция видна» от «состояние settled», плюс заранее написанный playbook на degraded finality и forced exit.
Если нужен такой control plane — от finality tracker и withdraw ETA до policy engine для bots и treasury routing — можно обсудить архитектуру под ваш L2-набор и интеграции: свяжитесь со мной.