Celestia: як data availability стала окремим шаром блокчейну

Чому класичні блокчейни не справляються зі зростанням навантаження

Bitcoin і Ethereum поєднують кілька функцій в одному протоколі, але їхня архітектура різниться: Ethereum після rollup-орієнтованої дорожньої карти не слід описувати як систему, де кожен вузол зберігає й виконує «все». Повні, легкі та архівні вузли мають різні вимоги.

Пропускна здатність залежить від розміру і часу блока, газових лімітів, типу транзакцій та оновлень протоколу. Діапазон 15–30 транзакцій на секунду для Ethereum без дати й методики спрощує картину, а причини обмежень не зводяться до вимоги кожному вузлу зберігати всю історію. Порівняння з історією Bitcoin показує, як ранні рішення щодо розміру блока й частоти його появи визначили подальші дебати про пропускну здатність.

Rollups виконують транзакції поза базовим шаром і публікують дані або докази за обраною схемою. Для optimistic rollups доступність даних потрібна, щоб відтворювати стан і оскаржувати некоректні переходи; інші конструкції мають інші механізми. Сайдчейни не є L2 лише за назвою.

Що означає модульний блокчейн і чому це не просто модне слово

Модульна архітектура розділяє виконання, settlement, консенсус і доступність даних між окремими компонентами. Межі залежать від конкретного стека: консенсус і data availability можуть працювати разом, а взаємодія між шарами додає власні припущення безпеки.

Спеціалізація дозволяє rollup окремо вибирати виконання, settlement і data availability. Це може знизити ціну публікації даних, але не означає, що користувач «не платить за обчислення»: витрати розподіляються між усіма компонентами стека. Окремо варто враховувати blockchain fees: як порівнювати комісії без висновків про як категорію витрат, яку порівнюють між мережами лише за єдиною методикою.

Модульність не тотожна конкретній реалізації sharding. Ethereum розвиває власний data-availability roadmap, а Celestia запустила спеціалізовану DA-мережу у 2023 році. Називати її беззастережно «першою» самодостатньою реалізацією без визначення критеріїв некоректно.

Як працює data availability layer у Celestia

Основне завдання Celestia — гарантувати, що дані, опубліковані в мережі, дійсно доступні для завантаження будь-кому. Це звучить просто, але технічна реалізація вимагає вирішення двох проблем: як переконатися, що дані не приховані частково, і як це зробити без зобов’язання кожного вузла завантажувати весь блок.

Celestia застосовує двовимірне Reed–Solomon erasure coding і data availability sampling. Легкий вузол вибірково запитує частки розширеного блока, щоб із заданою ймовірністю виявляти приховування даних; гарантія залежить від параметрів, кількості вибірок і припущень протоколу, а не від неформальної «колективної перевірки».

Celestia використовує proof-of-stake консенсус на основі CometBFT і Cosmos SDK. Валідатори узгоджують блоки та перевіряють правила протоколу, включно з транзакціями публікації даних; мережа не виконує прикладну логіку rollup.

Sovereign rollup може використовувати Celestia для впорядкування й доступності даних, а власні вузли — для визначення стану та правил оновлення. Це дає гнучкість, але переносить на операторів rollup відповідальність за fork choice, оновлення, мости й користувацький вихід.

Історія Celestia: від дослідження до запуску основної мережі

Проєкт виник із дослідницької роботи LazyLedger; серед співзасновників Celestia публічно називають Мустафу Аль-Бассама, Ісмаїла Хоффа і Джона Адлера. Деталі попередніх ролей і формулу про «вузьке місце будь-якої децентралізованої системи» потрібно відокремлювати від технічних тверджень статей.

Ранні роботи LazyLedger описували data availability sampling та масштабування перевірки без повного завантаження кожним легким клієнтом. Перехід від дослідницької моделі до мережі включав протокол, клієнтське ПЗ, тестові мережі й економіку TIA; це не був лінійний рух від «теорії без рішення».

Mainnet Beta Celestia запустила 31 жовтня 2023 року. TIA використовується для оплати blobspace, стейкінгу й governance; інтеграція rollup не означає однаковий рівень готовності або безпеки кожної мережі.

Celestia створювала інфраструктурний шар, а не масовий користувацький застосунок. Тривала дослідницька фаза не доводить автоматичного зменшення фундаментальних помилок: надійність оцінюють за специфікаціями, аудитами, інцидентами й роботою мережі після запуску.

Celestia простими словами: аналогія з поштовою системою

Як аналогію можна уявити систему, де один сервіс упорядковує та публікує закодовані пакети даних, а інші системи окремо виконують транзакції й визначають стан. Аналогія спрощує деталі: повні вузли завантажують більше даних, а легкі клієнти роблять вибірки.

Celestia не перевіряє прикладну логіку кожного rollup. Вона впорядковує blobs і дає механізм перевірки доступності опублікованих даних; правильність переходів стану, settlement і можливість виходу залежать від архітектури самого rollup.

Rollup платить за публікацію даних і сам визначає виконання. Користувацька перевірка не зводиться до «кількох випадкових працівників»: light node виконує протокольні вибірки, а висновок має ймовірнісний характер і залежить від мережевих припущень.

У Celestia працюють валідатори, full nodes і light nodes; їхню кількість не слід без джерела називати «тисячами». Data availability sampling дає ймовірнісну впевненість, а не робить приховування даних неможливим для будь-якого учасника.

Бізнес-модель та економіка мережі

За документацією Celestia, rollup публікують blobs через PayForBlobs і сплачують комісію в TIA. Комісії розподіляються відповідно до механіки мережі; твердження, що зі збільшенням даних «більше токенів спалюється», не підтверджене як загальне правило.

Попит на blobspace залежить від використання мереж, ціни альтернатив, пропускної здатності й ринкових умов. Це не робить TIA «забезпеченим» послугою і не доводить прозорішої оцінки: ціна токена також залежить від емісії, стейкінгу, ліквідності та спекулятивного попиту.

Валідатори отримують винагороди й комісії за правилами proof of stake. Light nodes не мають вбудованої прямої винагороди за вибірки; їхній запуск залежить від потреб користувачів і операторів, тому низький поріг сам по собі не гарантує широку участь.

Celestia конкурує з іншими DA-рішеннями та Ethereum blobs. Її майбутня частка, маржа й технічний бар’єр не відомі; терміни proto-danksharding і danksharding також описують різні етапи, а не гарантований сценарій витіснення.

Практичні приклади використання та інтеграції

Rollup може використовувати Celestia для data availability, окреме середовище виконання та власний або зовнішній settlement. Це дозволяє налаштовувати компоненти, але «дешевше» чи «надійніше» визначається фактичними комісіями, мостами, finality та операційними вимогами.

Sovereign rollup використовує Celestia для консенсусу й доступності даних, а його вузли самі визначають канонічний стан через правила fork choice. Це не обов’язково означає власний набір валідаторів або окремий механізм консенсусу, як стверджував попередній текст.

Validium зазвичай тримає транзакційні дані поза базовим шаром і публікує commitment або proof; якщо повні дані публікуються в Celestia, таку схему точніше описувати як rollup із зовнішнім DA. Компроміс потрібно визначати за конкретною архітектурою.

Обмеження та ризики, про які варто знати

Коли execution, settlement і data availability розділені, безпека залежить від кількох компонентів: sequencer, мостів, правил оновлення, вузлів rollup і DA-мережі. Монолітна система теж має складні припущення, тому кількість шарів сама по собі не визначає легкість аудиту.

Data availability sampling є ймовірнісним. Рівень впевненості залежить від кодування, кількості вибірок і мережевих припущень; повне завантаження блока не є «недосяжним», а виконується full nodes, хоча має вищі вимоги до ресурсів.

Економічна стійкість залежить від прийняття rollups. Якщо основні проєкти L2 оберуть зберігати дані на Ethereum після повного впровадження danksharding, попит на Celestia може виявитися нижчим за очікування. Проєкт конкурує не тільки технологією, а й екосистемною інтеграцією та зручністю для розробників.

Erasure coding, sampling і клієнтська реалізація потребують тестування та аудитів. Пройдені перевірки зменшують частину ризику, але не доводять довгострокової надійності; важливі виправлення, інциденти, оновлення й незалежні реалізації.

Коли варто розглядати модульну архітектуру для власного проєкту

Модульний підхід оцінюють, коли потрібні власне середовище виконання, контроль оновлень або інша модель доступності даних. Більша свобода супроводжується витратами на вузли, мости, спостереження, документацію й підтримку користувачів.

Перехід на зовнішній DA може зменшити плату за публікацію даних, але додає інтеграцію та іншу модель безпеки. Рішення потребує вимірювання фактичного обсягу blobs, комісій, вартості міграції, доступності даних і сценарію аварійного відновлення.

TIA має утилітарні й governance-функції, але його ринкова ціна не є простою функцією попиту на blobspace. На неї впливають пропозиція, розблокування, стейкінг, ліквідність, очікування та ринок; формула множення трьох «успіхів» не є фінансовою моделлю.

Вибір архітектури потрібно робити за моделлю безпеки, відновленням даних, зрілістю інструментів, витратами, підтримкою й компетенціями команди. Готовий L2 не завжди кращий для MVP, а модульний стек не гарантовано «окупиться» для амбітного проєкту.