Інтеграція Celestia: де ролап втрачає доступність даних
Після інтеграції Celestia ролап може вважати блок підтвердженим, хоча даних для його відновлення немає ні в оператора, ні у валідаторів, ні у сторонніх вузлів.
Симптом не проявляється одразу: транзакції йдуть, стан виглядає цілим, а розбіжність розкривається під час спроби підняти вузол з нуля або відновити стан мережі після збою.
Вузьке місце — у тому, як ролап публікує корисне навантаження в зовнішній шар даних. Якщо батч надіслано, а корінь і метадані не прив'язані до комітменту в заголовку блоку, підтвердження посилається на дані, яких фактично не існує.
Класичний модульний ролап ламається саме тут: виконання працює, а гарантія доступності даних тримається на довірі до того, хто обіцяв зберігати архів.
Ціна такої помилки не в логах. Виведення коштів зупиняється: без даних для відновлення стану не можна довести, що міст відображає реальний баланс, а спір щодо коду виходу нема чим закрити.
Паралельно зростають витрати на зберігання — оператор тримає копії сам, дублює архів і все одно не покриває весь горизонт.
Далі розбираємо, як це закривається: де проходить межа довіри під час інтеграції Celestia і які перевірки показують, що дані справді доступні, а не лише заявлені.
Що дає винесення даних в окремий шар
Винесення доступності даних в окремий шар змінює не лише архітектуру ролапу, а й його вимірювані характеристики. Публікація перестає конкурувати за місце в блоці основної мережі: Celestia приймає дані окремим потоком, а ролап зберігає у себе лише корені та докази.
Швидкість і вартість публікації
Пропускна здатність публікації більше не впирається в цільовий розмір блоку — дані йдуть великими пакетами в окремому каналі.
За того самого інтервалу формування блоків це дає зростання пропускної здатності в рази, а вартість публікації даних падає кратно: в одиницях газу різниця сягає порядку за пікового навантаження основної мережі.
Клас відмов, який зникає
Раніше ролап і основна мережа ділили одну смугу: сплеск активності в сусідньому застосунку роздував комісії та відкладав публікацію.
Модульна доступність даних розводить потоки — зниження навантаження на основну мережу вимірюється частками від попереднього обсягу, а виведення стану не зупиняється через перевантаження одного сегмента.
Стійкість до відмов тримається на надлишковому розміщенні: поки перевіряльні вузли збирають достатню вибірку, публікація продовжується, а стан відновлюється з доступних фрагментів.
Відмова окремого вузла або каналу зв'язку перестає бути зупинкою ролапу — це клас відмов, який зникає разом із перенесенням даних.
Коли інтеграція Celestia виправдана: порівняння схем даних
Схема доступності визначає, хто і як підтверджує, що дані блоків справді опубліковані. Від неї залежать і вартість публікації, і клас ризику: мережа довіряє або більшості валідаторів, або комітету, або вибірці легких вузлів. Нижче — чотири схеми, між якими реально обирають під час роботи з Celestia.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Дані в основній мережі | Невеликий обсяг, максимальна перевірюваність | Вартість і пропускна здатність зростають разом з обсягом |
| Комітет гарантів | Потрібна дешева публікація та низька затримка | Довіра до більшості комітету, ризик змови та цензури |
| Окремий модульний шар | Багато даних, потрібна дешева доступність | Обмеження модульного шару: власні вузли, моніторинг вибірки |
| Гібридна схема публікації | Свій набір валідаторів плюс зовнішній шар | Подвійна експлуатація, складніше відкат і узгодження стану |
На що дивитися під час вибору схеми
Рахуйте добовий і піковий обсяг даних, що публікуються — від нього залежить, чи витримає основна мережа, чи потрібен зовнішній шар.
Перевірте, хто відповідає за доступність у разі відмови: у комітету гарантів це кілька підписантів, у модульного шару — оператори вузлів і легкі клієнти.
І заздалегідь визначте шлях відкату: як виглядає повернення до попередньої схеми, якщо публікація в обраний шар перестала проходити.
Етапи впровадження: від аудиту до передачі в підтримку
Інтеграція модульного шару доступності даних не зводиться до розгортання ноди: потрібно зрозуміти, які дані ролап публікує назовні, хто їх читає і що станеться за недоступності зовнішнього шару.
Тому етапи впровадження йдуть від аудиту інфраструктури до передачі в підтримку, з точкою приймання на кожному кроці.
Аудит поточного контуру та схема рішення
- Збираємо карту контуру: де живуть секвенсор, нода і міст, як зараз публікуються пакети даних, які обсяги та ліміти сховища.
- Фіксуємо схему рішення: Celestia як шар доступності, точки підключення, порядок перемикання та повернення до попереднього контуру.
- Оцінюємо режими деградації: що допустимо — черга публікації або зупинка з оповіщенням, як це впливає на фіналізацію.
Налаштування, перевірка на відмовах і передача регламентів
- Розгортаємо стенд, що повторює бойовий контур, і проганяємо повний цикл: генерація даних — публікація — читання — перевірка доступності.
- Перевіряємо на відмовах: недоступність зовнішнього шару, обрив каналу, розсинхрон індексатора, повторна публікація.
- Вводимо моніторинг: затримка публікації, частка успішних записів, відставання ноди, глибина черги.
- Передаємо в підтримку: регламенти, порядок дій в інцидентах, навчання вашої команди та вікно супроводу після запуску.
Конфігурації, схеми та регламенти, які залишаються у вас
Інтеграція з Celestia закінчується не запуском вузла, а передачею: усе, що ми змінювали по ходу, залишається у вашої команди в репозиторії та регламентах.
Віддаємо робочі файли, а не переказ — конфігурації застосовуються заново, схеми звіряються з фактичним потоком даних, політики доступу перезбираються без автора рішення.
- Конфігурації вузлів — профілі валідатора, легкого клієнта та моста: параметри синхронізації, ліміти за пам'яттю і диском, налаштування пірів і таймаутів, з коментарем до кожного нестандартного значення.
- Політики доступу та ключі — розподіл ролей операторів, де зберігаються ключі підпису та ключі читання, порядок ротації, хто і через що бачить метрики.
- Схема потоків даних — шлях від публікації блоку до підтвердження доступності: де буфер, де ретранслятор, де точки відмови та як іде трафік у разі відмови одного плеча.
- Регламент відновлення — що робимо в разі втрати вузла або розсинхронізації, за який час повертаємося в стрій, що перевіряємо перед поверненням до набору валідаторів.
- Чергові сценарії — пороги оповіщень на відставання від мережі, зростання черги публікації та помилки доказів, із зазначенням адресата, а не «дивимося на панель».
Комплект документації
- Карта контурів і залежностей між ними.
- Інструкція з типових збоїв: команди, очікуваний вивід, що робити в разі розбіжності.
- Журнал рішень — які параметри змінювали і що показали вимірювання до та після.
- Порядок розгортання з нуля та відкату до попередньої конфігурації.
- Розбір із вашим інженером: проходимо кожен документ і знімаємо питання.
Кейс: як скоротили вікно недоступності даних учетверо
Кейс впровадження — про ролап з інтенсивним потоком транзакцій.
Дані публікувалися разом з виконанням, і в пікові доби публікація не встигала за виробництвом блоків: частина з них залишалася без підтвердженої доступності, а вікно недоступності розтягувалося до моменту ручної звірки реплік. Нижче — три метрики, які замовник відстежував до та після переведення публікації даних на Celestia.
Метрики до та після
- Частка блоків без підтвердженої доступності: 3–4% у пікові доби → менше 0,1%. Підтвердження стало кроком конвеєра, а не окремою операцією, яку хтось запускає вручну.
- Час відновлення після збою: 30–40 хвилин звірки та докатки стану → близько 10 хвилин. Нода піднімається із зовнішнього шару за збереженими зобов'язаннями, без звернення до чергового інженера.
- Обсяг реєстру даних: скоротився приблизно втричі. Корисне навантаження пішло в зовнішній шар, у власному сховищі залишилися зобов'язання за блоками та вікно, достатнє для розбору спірних ситуацій.
Після перенесення доступність перевіряється автоматично, а відмова публікації не блокує виробництво блоків: вона потрапляє в метрики і закривається регламентом, а не нічним розбором.
Ми передали команді замовника конфігурацію зберігання, правила публікації та порядок відновлення, тому супровід не потребує нашої постійної участі.
Чим модульний шар даних відрізняється від архіву та репліки
Три механізми вирішують три різні задачі й збігаються рівно в одному: кожен зберігає копію чогось. Архів фіксує історію, репліка повторює поточний стан, модульний шар даних підтверджує доступність. Щойно ролі змішують, в архітектурі з'являється впевненість, яка нічим не підтверджується.
Архів відповідає на питання «що було»: він віддає історичні блоки та потрібен для розбору інцидентів і перезбирання стану. Швидким він бути не зобов'язаний — і не зобов'язаний віддавати свіжі дані. Якщо вузол втратив останні блоки, архів цьому ніяк не заважає.
Репліка — це гарячий резерв: вона тримає актуальний стан і підхоплює навантаження, коли основний вузол недоступний. Але живе вона зазвичай у тому самому контурі, під тим самим управлінням і в тій самій зоні відмови, тобто повторює не лише дані, а й точку, де все ламається.
Модульний шар даних працює на іншому рівні: він публікує підтвердження доступності — доказ, що дані викладені й вибірку можна отримати. Це відокремлює консенсус від зберігання: ланцюжок не носить весь обсяг у себе, а вузол відновлює потрібне із зовнішнього шару.
Саме на цій межі з'являється інтеграція з Celestia — і тут же ламається інтуїція «архів = доступність».
Хибна впевненість у збереженості виглядає так: команда вважає, що раз є архів і репліка, дані в безпеці. Перевірка проста — відкличте один вузол і запитайте, хто і за який час відновить вибірку. Якщо відповіді немає, шар даних не розгорнуто, а лише мається на увазі.
Технічні сумніви перед стартом
Технічні сумніви перед стартом зазвичай одні й ті самі: що буде в разі збою зовнішнього шару, чи можна перейти без зупинки мережі та де проходить зона відповідальності. Нижче — прямі відповіді інженерів, без загальних формулювань.
Модульна схема з Celestia не скасовує відмов, але змінює їхню ціну: збій шару доступності стає задачею деградації, а не зупинкою ролапу.
Що буде, якщо зовнішній шар доступності недоступний?
Збирач перестає публікувати зліпки даних і накопичує їх у черзі, мережа продовжує приймати транзакції. Ми налаштовуємо поріг, після якого публікація переходить на резервний шлях, — зростає затримка фінальності, але простою не виникає.
Чи можна перейти без зупинки мережі?
Так: новий шар підключається паралельно, раніше опубліковані зліпки залишаються читабельними, адреси контрактів не змінюються. Перемикання та відкат — керований прапорець у конфігурації, а не окрема міграція.
Як ви перевіряєте доступність даних?
Проганяємо вибірку даних на кількох незалежних вузлах, звіряємо корені та читаємо історію після перезапуску. Окремо перевіряємо втрату частини вузлів і затримку публікації зліпків.
Чи сумісно це з наявним контуром?
Змінюються конфігурація збирача та точка публікації даних; логіка стану й контракти ролапу залишаються як є. Для іншого стеку описуємо перехідний шар і обсяг правок до старту.
Хто відповідає за доступність?
Межі фіксуємо документом: ми відповідаємо за збирач, публікацію та моніторинг з боку ролапу, зовнішній шар — за його провайдера. Метрики, алерти та пороги чергування передаємо разом із конфігурацією.
Що уточнимо перед оцінкою та планом впровадження
Перш ніж фіксувати строки, ми знімаємо невизначеність за чотирма речами: де зараз проходить межа між виконанням і публікацією даних, скільки йде в шар доступності, як відновлюється стан після збою і в кого є доступ до контуру.
Саме ці відповіді визначають, буде інтеграція Celestia точковою заміною способу публікації чи перебудовою всього шляху даних.
Що потрібно від вас на вході:
- Поточна схема даних — де формуються блоки, хто і як їх публікує зараз, які формати ходять між сервісами.
- Обсяги публікації — середня та пікова частота, розмір корисного навантаження, строк зберігання історії; від цього залежить вибір способу публікації та режиму роботи вузла.
- Вимоги до відновлення — допустимий час простою, глибина відкату, що вважаємо точкою відновлення і як перевіряємо її на навчаннях.
- Доступи до контуру — тестовий і робочий контури, ролі, порядок погодження змін і введення в експлуатацію.
- Ролі на вашому боці — хто володіє вузлами, хто приймає релізи, хто чергує і розбирає інциденти.
- Критерії приймання — які метрики підтверджують, що публікація йде штатно, а розбіжності даних немає.
Далі ми збираємо це в схему, розмічаємо етапи і повертаємося з оцінкою та планом впровадження. Опишіть задачу — обговоримо склад робіт, ризики та порядок запуску.
