Інтеграція Avail: де розривається доступність даних у rollup
Проблема з доступністю даних у rollup проявляється не в момент публікації блоку, а пізніше — коли користувач ініціює виведення коштів і не може довести коректність стану.
Секвенсор віддає корінь стану та доказ, але самі дані транзакцій лежать поза мережею: якщо їх ніде взяти, перевірка даних L2 стає неможливою, і виведення зависає в черзі на невизначений термін.
Інтеграція Avail закриває саме цей розрив — DA-шар зберігає дані блоків так, що їх можна незалежно запитати й перевірити.
Механіка збою виглядає передбачувано. Rollup публікує пакет транзакцій, комітить корінь в основну мережу, але тіло блоку залишається в одного оператора або в недоступному сховищі.
Поки все працює штатно, ніхто цього не помічає; щойно оператор виходить в офлайн, змінює політику зберігання або просто перестає віддавати дані, користувачі втрачають можливість зібрати доказ.
Далі — зростання кількості спорів, ручні розгляди та репутаційна шкода, яку складніше виправити, ніж сам збій.
Ціна такої архітектури вимірюється не в простоях, а в довірі: виведення коштів, яке має займати години, розтягується на дні, а частина транзакцій потребує втручання команди.
Доступність даних rollup перестає бути абстрактною властивістю й перетворюється на конкретний ризик для кожного, хто тримає кошти в системі.
Розбираємо, як це закривається через інтеграцію Avail — від публікації даних у DA-шар до незалежної перевірки на боці користувача.
Що дає DA-шар: режими публікації та їхні обмеження
Де саме публікуються дані rollup
Кожен блок rollup породжує два різних потоки даних: стиснені зміни стану, які перевіряє міст, і «сирі» транзакції, з яких будь-який учасник може перезібрати стан заново.
Поки сирі дані лежать лише на нодах оператора, rollup залишається довіреним: якщо оператор зник або втратив історію, відновити ланцюжок нічим.
Зовнішня доступність даних знімає цю залежність — історія гарантовано доступна третій стороні, і час відновлення rollup перестає залежати від інфраструктури одного оператора.
Режими публікації та що вони дають
Локальне сховище. Оператор тримає історію в себе: швидко й без зовнішніх залежностей, але клас відмови «оператор недоступний» не закритий. Підходить для тестових мереж і закритих контурів, де коло валідаторів відоме і довіра вже є.
Зовнішній DA-шар. Дані публікуються в окрему мережу доступності, яка зберігає їх і підтверджує доступність криптографічно. Відновлення вузла з історії стає можливим без участі оператора, а вартість простою падає: ланцюжок піднімає будь-хто, у кого є доступ до DA-шару. Обмеження — потрібна інтеграція й розуміння моделі підтверджень.
Гібридний режим. Критичні для моста дані йдуть у зовнішній шар, важкі допоміжні — залишаються локально. Це знижує обсяг публікацій, але ускладнює логіку: частина гарантій доступності тепер різна для різних типів даних.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Локальне сховище | Закриті контури, тестові мережі, довірене коло валідаторів | Відновлення залежить від оператора, клас відмови «оператор недоступний» не закритий |
| Зовнішній DA-шар | Публічні rollup, де важлива незалежна доступність історії | Потрібна інтеграція, свої правила підтвердження доступності |
| Гібрид | Великі обсяги допоміжних даних за жорстких вимог до моста | Різні гарантії для різних потоків, складніший супровід |
Інтеграція Avail у цьому порівнянні — приклад зовнішнього шару, де доступність підтверджується на рівні самої мережі, а не обіцянкою оператора. Avail
Що це змінює на практиці
Після перенесення публікацій у зовнішній шар відновлення вузла з історії перестає бути операцією «зателефонувати оператору й попросити бекап» — воно стає відтворюваним за даними, доступними будь-якому учаснику.
Це скорочує час відновлення rollup і прибирає цілий клас відмов, пов'язаних з єдиною точкою зберігання.
Етапи впровадження DA-шару: від аудиту до передачі
Інтеграція Avail не зводиться до підключення бібліотеки: DA-шар змінює те, як rollup публікує дані та як секвенсор доводить їхню доступність. Тому роботи йдемо за інженерним порядком — від аудиту поточної схеми до передачі рішення з документацією. Нижче — етапи, які проходимо на кожному проєкті.
- Аудит публікації даних. Розбираємо, що саме rollup зараз пише в базовий шар: блоки цілком, лише різницю станів чи стиснені пакети. Дивимося частоту публікації, розмір корисного навантаження та поведінку секвенсора при затримці підтверджень. На виході — карта потоків даних і список вузьких місць.
- Проєктування схеми. Визначаємо, які дані йдуть у DA-шар, а що залишається в базовому шарі для перевірки. Фіксуємо формат комітментів, порядок їх прив'язки до блоків і правила, за якими вузол відновить стан із зовнішніх даних.
- Налаштування інтеграції. Піднімаємо клієнт DA-шару, налаштовуємо публікацію та читання, зв'язуємо з секвенсором і вузлами перевірки. Конфігурацію тримаємо в репозиторії — середовища відтворюються однією командою.
- Перевірка на відмову. Прогоняємо сценарії, де DA-шар недоступний або відповідає із затримкою: як поводиться rollup, чи не губляться дані, чи можливий відкат. Окремо перевіряємо відновлення стану з опублікованих даних на чистому вузлі.
- Навантажувальні прогони. Дивимося, як зростає час публікації при піковому навантаженні та де межа пропускної здатності. За результатами підбираємо розмір пакетів та інтервали.
- Документація. Описуємо схему потоків, параметри конфігурації, порядок дій при збої та процедуру відкату.
- Передача рішення. Розбираємо з вашою командою кожен вузол, відповідаємо на питання щодо експлуатації та передаємо доступи й матеріали.
Обговоримо вашу задачу — повернемося з оцінкою та планом робіт за етапами.
Чим зовнішній DA-шар відрізняється від публікації в основній мережі?
Публікація в основній мережі означає, що кожен байт даних rollup'а лягає в блоки L1 і зберігається там вічно — будь-який учасник може відновити стан з історії.
Зовнішній DA-шар (у нашому випадку — інтеграція Avail) виносить дані в окрему мережу, яка зберігає їх обмежений час і підтверджує доступність криптографічно.
Різниця принципова: у першому випадку гарантія доступності випливає з консенсусу основної мережі, у другому — із економічних зобов'язань DA-шару та механізму erasure coding.
Ключове питання — хто відповідає за те, що дані реально доступні. В основній мережі це властивість самого протоколу: якщо блок прийнято, дані є у всіх повних вузлів.
Зовнішній DA-шар будує гарантію інакше — комітети підписують attestation про те, що дані розкладені по чанках і відновлювані, а легкі клієнти перевіряють вибірку.
Поки attestation валідний, rollup може рухати стан уперед; якщо дані зникли, мережа зупиняє виведення коштів, але не втрачає вже зафіксовані баланси.
Звідси прямий зв'язок із виведенням коштів. У схемі з публікацією в основній мережі виведення чекає фіналізації L1 — це вікно челленджу, яке вимірюється годинами й днями.
Із зовнішнім DA-шаром виведення спирається на підтвердження доступності від DA-комітету, а не на повну фіналізацію L1: вікно скорочується до хвилин, а вартість публікації падає на порядок, бо дані не конкурують за блоковий простір основної мережі.
Обмеження теж чесне: ви успадковуєте модель довіри до DA-шару. Якщо комітет перестає видавати attestation або дані губляться до закінчення терміну зберігання, rollup зупиняється — виведення заморожується до відновлення.
Саме тому в продакшені зовнішній DA-шар комбінують із періодичним «якорем» в основну мережу: критичні корені стану та хеші батчів публікуються в L1, а важкі дані живуть у DA-шарі. Так зберігається і швидкість, і можливість відкату.
Кейс: як rollup перестав втрачати дані під піковим навантаженням
Rollup-мережа на піку навантаження перестала встигати публікувати дані про стан в основній мережі: черга на відправлення зростала швидше, ніж її розбирали.
Користувачі бачили підтверджені транзакції, але виведення коштів зависало — доказ не було з чого зібрати, бо потрібні блоки даних не були доступні нікому, крім самого оператора.
Це класична точка відмови: поки даних мало, все працює, а на піку rollup перетворюється на довірений міст з одностороннім зв'язком.
Що було до змін
Дані публікувалися напряму в основну мережу — кожен блок чекав своєї черги на запис. При сплеску активності частка недоступних блоків сягала 12–15%: вузли не могли отримати дані вчасно й позначали блок як відсутній.
Відновлення одного такого блоку займало до 40 хвилин — доводилося вручну ініціювати повторну публікацію й чекати підтвердження.
Завислі виведення накопичувалися: за тиждень пікового навантаження набиралося до кількох десятків незавершених операцій, і кожна вимагала ручного розбору.
Що змінили
Винесли публікацію даних в окремий шар доступності й підключили його до rollup як зовнішнє джерело. Тепер блок даних спочатку розкладається на частини й розсилається по мережі зберігання, і тільки після підтвердження доступності фіксується в основній мережі.
Доказ збирається з цих частин — оператору більше не потрібно бути єдиним власником даних. Налаштували резервування: якщо один вузол зберігання не відповідає, блок збирається з решти копій.
| Параметр | До | Після |
|---|---|---|
| Частка недоступних блоків | 12–15% на піку | менше 0,5% |
| Час відновлення блоку | до 40 хвилин | 2–4 хвилини |
| Завислі виведення за тиждень | десятки | поодинокі випадки |
| Ручні втручання | регулярні | не потрібні |
Що стало
Пікове навантаження перестало бути загрозою: rollup публікує дані паралельно з обробкою транзакцій, і черга не зростає. Виведення коштів проходять без затримок, бо доказ завжди збирається з доступних частин.
Відмовостійкість зросла — втрата одного вузла зберігання не зупиняє мережу, блок відновлюється з решти копій. Оператор більше не є єдиною точкою відмови.
Для організації такого шару ми використовуємо Avail — він дає модульну архітектуру, де доступність даних відокремлена від виконання й консенсусу.
Це дозволяє масштабувати зберігання незалежно від пропускної здатності основної мережі й не переписувати логіку rollup при зростанні навантаження.
Сумніви перед інтеграцією: сумісність, відкат, доступи
Перед стартом інтеграції Avail замовники найчастіше порушують три питання: чи не зламає DA-шар уже працюючий rollup, чи можна відкотитися на попередню схему публікації даних і хто отримує доступ до нод і ключів. Відповідаємо по кожному предметно.
Що якщо поточний rollup уже пише дані в інший DA-шар? Сумісність DA-шару вирішується на рівні адаптера: ми не переписуємо логіку секвенсора, а додаємо публікацію блобів в Avail паралельно або замість попереднього каналу.
Перемикання — керований параметр конфігурації, а не міграція із зупинкою мережі. Якщо rollup на OP Stack або Arbitrum Orbit, адаптер вбудовується в наявний конфіг без форку клієнта.
Як влаштований відкат інтеграції? Відкат тримаємо на двох рівнях: повернення на попередній DA-шар через той самий параметр конфігурації та відкат версії адаптера за тегом образу.
Обидва сценарії відпрацьовуємо на тестовій мережі до релізу — відновлення займає хвилини, а не вікно простою.
Кому і які доступи видаються? Доступи та ролі розмежовуємо за принципом мінімальних прав: окремі облікові записи для публікації даних, читання й адміністрування нод. Ключі підпису зберігаються в ізольованому сховищі, ротація та аудит звернень налаштовуються одразу.
Що відбувається з уже опублікованими даними при перемиканні DA-шару?
Історичні блоби залишаються в попередньому шарі й доступні для перевірки — ми не видаляємо і не перезаписуємо їх. Нові дані йдуть в Avail, а верифікатор читає обидва джерела за періодом. Це знімає ризик втрати доказів при зміні схеми публікації.
Що якщо в команди немає власних нод Avail? Піднімаємо легкий клієнт або підключаємося до зовнішніх провайдерів — вибір фіксуємо в документації з описом режимів відмови. Як перевіряється, що дані справді доступні? У здачу входить скрипт перевірки вибірки блобів і звіт за контрольними публікаціями.
На руки після здачі замовник отримує:
- конфігурації адаптера та параметри перемикання DA-шару;
- схеми потоків даних від секвенсора до верифікатора;
- політики доступів і ролі з матрицею прав;
- регламент ротації ключів і аудиту звернень;
- інструкцію з відкату з покроковими перевірками;
- документацію з режимів відмови та моніторингу;
- звіт контрольних публікацій і перевірок доступності.
Опишіть вашу конфігурацію rollup і поточний DA-шар — повернемося з оцінкою сумісності, планом перемикання та складом артефактів під ваш випадок.
