Rollup-as-a-Service: де ламається власна L2-мережа
Власна L2-мережа виглядає як повний контроль: власний вузол обробки транзакцій, свої правила виконання, незалежна смуга пропускної здатності.
На практиці разом із контролем приходить операційна відповідальність — за доступність, за міст, за збереженість стану і за те, щоб збій помітили раніше за користувачів.
Перша точка відмови — вузол обробки транзакцій. Поки він у строю, мережа приймає операції та збирає блоки; під час перезапуску, розсинхронізації з основною мережею або переповнення диска приймання зупиняється, а черга накопичується без ознак відновлення.
Гарячий резерв потребує окремої синхронізації стану, і без нього кожен збій — це простій мережі L2 цілком.
Друга — міст і процедура виведення коштів. Затримка виведення, оновлення контрактів, глибина підтверджень і ліквідність на стороні отримувача живуть в окремій логіці, яку не перевірити на основній мережі без ризику. Збій тут не валить мережу, але блокує кошти — найпомітніший для користувача клас відмов.
Третя — шар доступності даних і зберігання. Якщо вузол публікації відстає або архів не репліковано, стан перестає відновлюватися із зовнішнього джерела, і відкат перетворюється на ручне складання.
Моніторинг зазвичай з’являється останнім: метрик за висотою блоків, лагом і витратами ресурсів немає, і про збій повідомляють користувачі.
Власне Rollup-as-a-Service і є перенесенням цих ролей на керований контур: платформи на кшталт Conduit і Caldera зводять розгортання L2 до конфігурації, а не до складання інфраструктури з нуля. Нижче розбираємо точки відмови ролапа по порядку — і те, як це закривається на стороні сервісу.
Що дає керований ролап: доступність, час виведення та відмови
Керований ролап — це пов’язана топологія із секвенсора, батчера, вузла доказів і реплік, яку розгортають із готових шаблонів, а не збирають вручну під конкретний проєкт.
Платформа Conduit описує мережу декларативним маніфестом: версія вузлів, політика комісій, ліміти газу й склад реплік задаються конфігом, тому конфігурація відтворюється один в один на тестовому контурі та в продакшені.
Час випуску оновлень скорочується з днів до годин: зміна параметрів іде через той самий конфіг, що й первинне встановлення, а пробне розгортання в ізольованому контурі показує ефект до ввімкнення на живих користувачах. Регрес ловиться до викочування, відкат до попередньої конфігурації займає хвилини.
Доступність L2 тримається на репліках і автоматичному перезапуску: вузли розподіляють навантаження між собою, під час виходу одного трафік переноситься на інші без обриву сесій.
Під піком транзакцій мережа не валить точки доступу, а вартість газу зростає передбачувано — без «залиплих» транзакцій у користувачів.
Виведення коштів із L2 перестає залежати від ручних операцій: інтервали публікації коренів стану та параметри вікна оспорювання налаштовані так, що заявки обробляються у стабільному темпі, а не пачками після втручання інженера.
Окремий клас відмов — розсинхрон індексатора, переповнення диска на вузлі, втрата секвенсора під час оновлення — зникає, бо ці стани відстежує штатний моніторинг і лікує їх шаблонний сценарій, а не розбір з нуля.
Rollup-as-a-Service, власна L2 чи гібрид: порівняння режимів
Порівнювати ці режими варто не за тим, хто орендує залізо, а за тим, у кого залишаються ключі від секвенсора, прувера та вузлів мостів. Саме це визначає час виходу в основну мережу, швидкість оновлень і те, хто розбирає інцидент о третій годині ночі.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Повністю власна L2 | Потрібен повний контроль над обробкою транзакцій і даними; внутрішні регламенти забороняють виносити вузли назовні | Секвенсор, прувер і вузли мостів тримаєте самі; оновлення та відмовостійкість — ваша зона |
| Кероване розгортання через Rollup-as-a-Service | Потрібен швидкий запуск і передбачувана експлуатація без власної команди супроводу | Ключові вузли у провайдера; політику оновлень і частину параметрів задає він |
| Гібридна схема ролапа | Власний вузол обробки під контролем, а обв’язка, моніторинг і вузли мостів — на керованій стороні | Стик зон відповідальності: потрібні свої метрики та узгоджений регламент оновлень |
Обмеження самостійного розгортання проявляються не на старті, а на другий-третій місяць: клієнт і конфігурації доводиться оновлювати без зупинки мережі, а для відкату тримати свіжі знімки стану та синхронізовану ноду. Приватний ролап додає до цього закритий доступ до вузлів і окрему видачу ключів.
Окремо враховуйте, що зміна режиму не переносить стан: адреси контрактів переносні, а корінь стану та мости — ні, тому перехід між варіантами роблять як запуск нової мережі з міграцією активів. Розбираємо, який режим під вашу задачу і чим це обернеться на експлуатації.
Впровадження L2: від аудиту контуру до передачі в експлуатацію
Впровадження L2 — це не встановлення одного компонента, а перебудова контуру, тому роботи йдуть послідовно: кожен наступний етап спирається на дані попереднього.
Якщо пропустити аудит і одразу розгортати мережу, невідповідності спливуть під навантаженням — там, де змінювати архітектуру найдорожче. Нижче — порядок, за яким ми ведемо проєкт від першого обходу інфраструктури до передачі команді замовника.
- Аудит контуру. Інвентаризуємо сервіси, які будуть читати й писати стан, вузли, сховища ключів, поточні ліміти та точки відмови. На виході — карта залежностей і перелік вузьких місць, які потрібно зняти до розгортання.
- Проєктування схеми. Визначаємо профіль мережі під задачу: пропускну здатність, модель комісій, спосіб виведення даних у базовий шар, ролі та доступи. Фіксуємо, що беремо готовим шаром Rollup-as-a-Service — наприклад, Conduit — а що доопрацьовуємо самі.
- Налаштування та розгортання. Піднімаємо мережу, вузли й службові сервіси, вмикаємо моніторинг, логи й алерти за ключовими метриками: висота блоків, затримка включення транзакцій, глибина черги.
- Інтеграція з наявним контуром. Підключаємо індексатори, гаманці, внутрішні сервіси та мости, проганяємо наскрізні сценарії на тестовій мережі з реальними форматами даних.
- Навантажувальна перевірка L2. Даємо профіль, близький до пікового: сплески транзакцій, відмова окремого вузла, перепідключення клієнтів. Фіксуємо час відновлення та поведінку системи на межі.
- Передача в експлуатацію. Віддаємо конфігурації, схеми, регламенти оновлення та відкату, навчаємо команду замовника. Далі мережа живе на їхньому боці, ми підключаємося на супровід.
Що залишається у замовника: схеми, доступи та регламенти
Проєкт не закінчується запуском основної мережі: після здачі у замовника залишається комплект, з яким його інженери експлуатують мережу без нас. Нижче — що саме передається на ваш бік разом з адміністративними правами.
- Схема мережі — топологія вузлів, їхні ролі, точки відмови та маршрути трафіку між компонентами.
- Політики доступу — матриця ролей: хто і що змінює, де зберігаються ключі підпису та як проходить їхня ротація.
- Конфігурації розгортання — файли, що описують мережу, із зафіксованими поточними значеннями та журналом правок.
- Документація L2 — архітектура, призначення кожного компонента, логіка мостів і комісій, викладена для вашої команди.
- Регламент експлуатації — планові оновлення, вікна обслуговування, порядок чергування та ескалації інцидентів.
- Процедури відновлення — резервні копії стану, сценарії підйому після збою та відкат до попередньої версії.
- Панелі метрик і оповіщення — набір порогів, при виході за які черговий отримує сигнал до того, як проблема видна користувачам.
Усе лежить у вашому репозиторії та вашій інфраструктурі, адміністративні права — на вашому боці, за нами залишається лише доступ за заявкою.
Такий комплект дозволяє змінити підрядника на експлуатацію без перескладання мережі з нуля — приймальна команда розбирається за схемами та регламентами, а не за листуванням.
Кейс: як L2 перестала падати на піковому навантаженні
Перед нами був L2-контур з одним секвенсором, зібраний вручну: вузли в одній зоні, перезапуск руками, повторні надсилання транзакцій — на розсуд гаманця.
На піках черга зростала швидше, ніж оброблялася: частка успішних транзакцій просідала до 92%, користувачі бачили завислі операції. Виведення коштів через міст займало від кількох годин до доби — докази збиралися вручну, фіналізація очікувалася.
Проблема була не в коді, а в тому, як зібраний контур, — доопрацьовувати це зсередини не мало сенсу.
Перевели L2 на керовану схему через Rollup-as-a-Service: вузли розподілили по кількох зонах, секвенсор отримав автомасштабування, додали перевірки стану, політику повторних спроб і оповіщення на зростання черги. Оркестрацію взяв на себе провайдер — Conduit, моніторинг і доступи залишилися у нас.
Підсумок у метриках: частка успішних транзакцій на піках — з 92% до 99,8%; виведення коштів — з годин до хвилин, ручний крок із процесу пішов; кількість інцидентів скоротилася в рази. Замість щотижневих чергувань залишилися поодинокі оповіщення, які закриваються за регламентом.
Окремий ефект — передбачувана деградація. Раніше відмова приходила раптово й одразу всім; тепер зростання навантаження видно заздалегідь за метриками черги, і контур розширюється до того, як це помітять користувачі.
Чим керований ролап відрізняється від власної мережі?
У власній мережі команда тримає весь стек: секвенсор, виконувальний і консенсусний клієнти, вузли доступу, мости та оновлення.
Керований ролап влаштований інакше — інфраструктуру розгортає й обслуговує оператор, а в команди залишаються адміністративні права на мережу: ключі оновлення контрактів, параметри газової політики та доступ до мосту.
Хто керує вузлами, видно за розподілом обов’язків.
Оператор тримає доступність секвенсора та точок підключення, стежить за синхронізацією стану, проганяє оновлення клієнтів, розбирається з розходженнями та чергує за відмовами — у Conduit і аналогічних майданчиків це винесено в окремий контур спостережуваності з фіксованим часом реакції.
На боці замовника залишається те, що визначає продукт: логіка контрактів, хто і на яких умовах публікує транзакції, правила виведення коштів, ліміти та списки доступу.
Оператор не може змінити ваші контракти або розпорядитися мостом — саме тут і проходить межа відповідальності, її фіксують до запуску.
Перехід на керовану схему не означає нову мережу. Зберігаються адреси контрактів, історія транзакцій, баланси та випущені активи — змінюється той, хто тримає вузли й відповідає за доступність.
Тому перехід планують у вікно низького навантаження, з перевіреним сценарієм відкату на попередній контур і звіркою стану з обох боків.
На практиці питання зводиться до одного: чи тримаєте ви чергування з інфраструктури самі або передаєте його оператору, зберігаючи контроль над логікою мережі. Опишіть поточний контур — повернемося з оцінкою та планом переходу.
Технічні сумніви перед запуском L2: міст, дані, контроль
Контур на Rollup-as-a-Service піднімається за лічені дні, але перед запуском у технічної команди замовника спливають одні й ті самі питання: як виводити кошти назад, хто відповідає за збереженість даних і що буде з доступом до контуру після здачі робіт.
Нижче — короткі відповіді; точні параметри залежать від обраної архітектури та фіксуються у схемі до складання.
Як влаштований міст між мережами?
Канонічний міст — це контракт в основній мережі: він блокує актив, дочікується підтвердження коректності стану та випускає еквівалент усередині L2. Введення коштів займає хвилини, виведення — від годин до кількох діб, бо стан має бути доведений.
Сторонні швидкі мости дають миттєве виведення, але додають довірену сторону; ми показуємо цю розвилку на схемі ще до складання, щоб вибір був усвідомленим.
Де зберігаються дані L2 і хто керує контуром?
Дані публікуються в основній мережі, тому історію не можна тихо переписати — стан завжди відновлюється з неї.
Права доступу розводяться за ролями: оновлення контрактів, випуск активів і казначейство працюють на різних ключах і мультипідписах, а адміністративні права залишаються у замовника з першого дня. Наша команда тримає лише операційний доступ на час робіт, і він відкликається під час передачі.
Обслуговування контуру — окремий пункт плану: оновлення вузла, моніторинг порядку обробки транзакцій і зростання сховища, звірка розходжень між L2 та основною мережею. Регламент і документація передаються разом із контуром.Обговоримо задачу: підберемо режим розгортання L2
Щоб повернутися з оцінкою та планом впровадження, а не із загальними міркуваннями, нам потрібні ввідні щодо вашого сценарію. Частина з них зазвичай уже сформульована в команди — решту уточнимо на розборі.
Нижче те, що закриває основне під час підбору режиму розгортання L2 — від керованого Rollup-as-a-Service до власного контуру.
- Тип мережі та модель доказів: оптимістична або з доказами нульового розголошення — від цього залежить склад вузлів і час виведення коштів в основну мережу.
- Профіль навантаження: скільки транзакцій за секунду потрібно тримати в піку, який обсяг стану й архіву очікується через рік.
- Склад компонентів: власний вузол упорядкування транзакцій, генератор доказів, міст для переведення активів, публічний вузол для читання.
- Середовище розміщення: власні сервери або хмара, вимоги до відмовостійкості та географічного рознесення.
- Токен для оплати комісій і правила їх розподілу між учасниками мережі.
- Доступи та ролі: хто володіє адміністративними ключами, як розділяються права між командами, чи потрібен контроль кількома підписами.
- Спостережуваність і регламент: значущі метрики, глибина зберігання історії, порядок оновлення та відкату версій.
Опишіть задачу у вільній формі та додайте ці ввідні. Ми повернемося з оцінкою, планом впровадження та розбором варіантів: де достатньо готової платформи, а де виправданий власний контур із повним контролем над оновленнями та ключами.
