Інтеграція з Celestia (Data Availability)

Інтеграція з Celestia (Data Availability)

Rollup без зовнішнього DA — це rollup, який зберігає calldata на L1. На Ethereum це коштує грошей: до EIP-4844 кожен байт calldata коштував ~16 gas, після — дешевше через blobs, але blob space обмежен (~375 KB на блок, 6 blobs). При високому навантаженні від rollup проектів на mainnet blob ринок стає конкурентним, і вартість транзакцій зростає. Celestia розв'язує це через модульну спеціалізацію: ланцюг робить тільки одне — Data Availability — і робить це дешево й масштабовано.

Ключовий момент: Celestia не виконує транзакції, не зберігає стан, не досягає консенсусу щодо коректності обчислень. Вона гарантує лише те, що дані були опубліковані і доступні для завантаження. Це дозволяє оптимізувати під параметри, специфічні для DA: DAS (Data Availability Sampling), Namespaced Merkle Trees, високу пропускну здатність.

Як працює DAS і чому це важливо

Data Availability Sampling — механізм, при якому light node не завантажує весь блок, а робить випадкові запити на малі фрагменти даних. Якщо всі запити успішні — з високою ймовірністю (криптографічна гарантія) блок повністю доступний.

Celestia використовує 2D Reed-Solomon erasure coding: дані розбиваються на матрицю, кодуються по рядках та стовпцях. Для відновлення повного блока достатньо 50% даних (будь-якої частини). Це означає: навіть якщо частина нод офлайн або діє зловмисно — дані можна відновити, поки зберігається принаймні половина.

Для розробника rollup це означає: опублікуй дані в Celestia, і будь-який учасник мережі може верифікувати їхню доступність без завантаження всього. Light nodes для користувачів — реальний сценарій, не теорія.

Інтеграція rollup з Celestia: практика

Sovereign Rollup vs. Settlement Rollup

Перше архітектурне рішення: де відбувається settlement?

Sovereign rollup використовує Celestia тільки як DA. Консенсус про коректність ланцюга — серед учасників самого rollup. Форки можливі. Це модель для проектів, яким потрібна максимальна суверенність і гнучкість.

Settlement rollup опубліковує дані в Celestia, а proof верифікації відправляє на окремий settlement layer (Ethereum, або Celestia-based settlement chain). Це ближче до класичної L2 моделі, але з дешевою DA.

Публікація даних через celestia-node

import (
    "github.com/celestiaorg/celestia-node/api/rpc/client"
    "github.com/celestiaorg/celestia-app/pkg/namespace"
)

// Ініціалізація клієнта (підключення до celestia-node)
rpcClient, err := client.NewClient(ctx, "http://localhost:26658", authToken)

// Створення namespace — ізольованого простору для даних rollup
ns, err := namespace.From([]byte("myrollup123456789")) // 10 байт

// Публікація batch транзакцій
blob, err := blob.NewBlob(ns, batchData)
height, err := rpcClient.Blob.Submit(ctx, []*blob.Blob{blob}, blob.DefaultGasPrice())

fmt.Printf("Data submitted at height: %d\n", height)

Після публікації потрібно зберегти (height, namespace, commitment) — це proof того, що дані були включені. Commitment — це хеш blob даних, який включається в Celestia block header.

Верифікація включення: Namespace Merkle Proof

Щоб смарт-контракт на L1 міг верифікувати, що дані були включені в Celestia, використовуються Namespaced Merkle Tree (NMT) proofs:

// Отримання proof включення
proof, err := rpcClient.Blob.GetProof(ctx, height, ns, commitment)

// proof містить:
// - NMT siblings path
// - Row roots з data root
// - Inclusion proof row у data root

На стороні Ethereum-контракту: Blobstream (раніше Quantum Gravity Bridge) публікує Celestia data root commitments в Ethereum. Верифікатор контракту перевіряє NMT proof проти опублікованого data root.

interface IBlobstream {
    function verifyAttestation(
        uint64 _tupleRootNonce,
        DataRootTuple calldata _tuple,
        BinaryMerkleProof calldata _proof
    ) external view returns (bool);
}

// У верифікаторі rollup
function verifyDataAvailability(
    uint64 celestiaHeight,
    bytes32 dataRoot,
    NMTProof calldata nmtProof
) external view returns (bool) {
    // 1. Верифікуємо, що dataRoot включений у Blobstream
    bool rootVerified = blobstream.verifyAttestation(nonce, tuple, binaryProof);
    require(rootVerified, "DataRoot not attested");
    
    // 2. Верифікуємо NMT proof, що наш namespace включений у dataRoot
    return nmtVerifier.verify(dataRoot, nmtProof, namespaceStart, namespaceEnd);
}

Celestia в модульному rollup стеку

Реалістичний стек для нового rollup проекту з Celestia DA:

OP Stack + Celestia — найпроторенніший шлях. alt-da mode в OP Stack дозволяє замінити Ethereum DA на Celestia. Repository celestiaorg/optimism містить патч. Sequencer публікує батчі в Celestia, derivation pipeline читає з Celestia за namespace.

Rollkit — sovereign rollup framework від Celestia Labs. Вбудована підтримка Celestia DA, поверх Cosmos SDK. Для проектів, які хочуть Cosmos-сумісність без IBC складності.

Arbitrum + Celestia через AnyTrust DA committee, можна налаштувати Celestia як одного з членів комітету. Більш складна інтеграція, але зберігає сумісність з Arbitrum екосистемою.

Параметри продуктивності

Для порівняння: Ethereum blobs після EIP-4844 — ~375 KB/блок, target ціна ~1 ETH за 1 MB при високому навантаженні.

Операційні аспекти

celestia-node існує в трьох режимах:

• Full node — завантажує та зберігає всі дані, участь у DAS
• Bridge node — з'єднує Celestia P2P з Celestia App (consensus), потрібен для DA bridging
• Light node — тільки DAS, мінімальні вимоги до ресурсів

Для production rollup sequencer потрібен принаймні власний full node або bridge node — не варто залежати від публічних endpoints для публікації транзакцій.

Моніторинг: Celestia node експортує Prometheus метрики. Ключові алерти: celestia_das_sampling_failures (DAS не працює), celestia_node_sync_delay (нода відстає), blob submission errors.

Fallback: якщо Celestia недоступна — rollup sequencer повинен мати fallback на L1 DA. OP Stack alt-da mode підтримує це через challenge механізм: якщо дані не доступні через DA provider упродовж challenge window, sequencer зобов'язаний опублікувати їх on-chain.

Інтеграція з Celestia — це інфраструктурне рішення з довгостроковими наслідками для архітектури. Правильно зроблена, вона знижує DA costs на 1-2 порядки величини і відкриває шлях до throughput, недосяжного при зберіганні даних на Ethereum.