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

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

Data Availability — це не зберігання даних. Це гарантія того, що дані були опубліковані і доступні для завантаження в конкретний момент часу. Для rollup це фундаментальна властивість: fraud proofs або validity proofs беззмістовні, якщо хто-небудь не може отримати дані транзакцій для верифікації стану.

Ethereum Danksharding (EIP-4844) вирішив цю проблему для Ethereum-based rollups через blobs. EigenDA — альтернатива, побудована на EigenLayer restaking, яка пропонує значно вищу пропускну здатність і нижчу вартість ціною іншої моделі довіри.

Як працює EigenDA: технічні деталі

Архітектура системи

EigenDA складається з трьох компонентів:

Оператори — власники нод, які restaked ETH через EigenLayer і надають зберігання та пропускну здатність. Вони приймають фрагменти даних, зберігають їх і відповідають на запити доступності.

Disperser — сервіс (наразі централізований у EigenLabs, roadmap на децентралізацію), який приймає дані від rollup, ділить їх на фрагменти через erasure coding, розподіляє між операторами, збирає підписи.

On-chain Верифікатор — смарт-контракт на Ethereum, який верифікує, що quorum операторів підписав attestation про отримання даних.

Erasure Coding і Data Availability Sampling

EigenDA використовує Reed-Solomon erasure coding: дані розміром D кодуються в M фрагментів (M > D), при цьому будь-які D з M фрагментів достатньо для відновлення оригіналу. Типові параметри: якщо 50% операторів недоступні — дані все одно можна відновити.

Data Availability Sampling (DAS) — техніка, при якій light client може верифікувати доступність даних, завантажуючи лише невелику випадкову підмножину фрагментів. Математично: якщо завантажити 30 випадкових фрагментів і всі доступні, з ймовірністю >99.9% всі дані доступні (при 50% erasure coding).

Blob (дані rollup)
  ↓ Reed-Solomon encoding
Фрагменти [c0, c1, c2, ..., cn]
  ↓ KZG polynomial commitments
Commitment (коротке доказ даних)
  ↓ Dispersal до операторів
Оператори зберігають фрагменти + відповідають на sampling запити

BlobHeader і Certificate

При публікації даних до EigenDA disperser повертає BlobHeader і BlobCertificate:

type BlobHeader struct {
    Commitment       G1Point        // KZG commitment до даних
    DataLength       uint32         // розмір у символах
    BlobQuorumParams []BlobQuorumParam
}

type BlobQuorumParam struct {
    QuorumNumber                 uint8
    AdversaryThresholdPercentage uint8  // макс злонамісних операторів
    ConfirmationThresholdPercentage uint8 // мін підтверджень
    ChunkLength                 uint32
}

type BlobCertificate struct {
    BlobHeader   BlobHeader
    BlobVerificationProof BlobVerificationProof
}

Certificate зберігається rollup в calldata або blob транзакції на Ethereum — це дозволяє верифікатору перевірити, що дані були дійсно опубліковані в EigenDA.

Інтеграція rollup з EigenDA

Dispersal: публікація даних

Rollup sequencer (або batch poster) відправляє дані через EigenDA Disperser API:

package main

import (
    "context"
    "github.com/Layr-Labs/eigenda/api/grpc/disperser"
    "google.golang.org/grpc"
)

func disperseBlob(data []byte) (*disperser.BlobInfo, error) {
    conn, err := grpc.Dial("disperser-holesky.eigenda.xyz:443", grpc.WithTransportCredentials(...))
    if err != nil {
        return nil, err
    }
    defer conn.Close()
    
    client := disperser.NewDisperserClient(conn)
    
    reply, err := client.DisperseBlob(context.Background(), &disperser.DisperseBlobRequest{
        Data: data,
        CustomQuorumNumbers: []uint32{}, // використовувати default quorum
        AccountId: accountId,            // для rate limiting
    })
    if err != nil {
        return nil, err
    }
    
    // Polling до finalization
    for {
        statusReply, _ := client.GetBlobStatus(context.Background(), &disperser.BlobStatusRequest{
            RequestId: reply.RequestId,
        })
        
        if statusReply.Status == disperser.BlobStatus_CONFIRMED {
            return statusReply.Info, nil
        }
        
        time.Sleep(2 * time.Second)
    }
}

Після підтвердження — serialized BlobInfo (включаючи BlobHeader і BlobVerificationProof) постять в Ethereum в calldata замість або додатково до самих даних.

On-chain верифікація

Для rollups з fraud proofs потрібно верифікувати on-chain, що дані були дійсно доступні:

interface IEigenDAServiceManager {
    function confirmBatch(
        BatchHeader calldata batchHeader,
        OperatorStakesAndSignature calldata operatorStakesAndSignature
    ) external;
    
    function verifyBlob(
        BlobHeader calldata blobHeader,
        BlobVerificationProof calldata blobVerificationProof
    ) external view;
}

contract RollupWithEigenDA {
    IEigenDAServiceManager public eigenDA;
    
    function submitBatch(
        bytes calldata batchData,
        BlobHeader calldata eigenDABlobHeader,
        BlobVerificationProof calldata eigenDAProof
    ) external {
        // Верифікуємо, що дані були дійсно в EigenDA
        eigenDA.verifyBlob(eigenDABlobHeader, eigenDAProof);
        
        // Продовжуємо з звичайною логікою rollup
        bytes32 batchRoot = keccak256(batchData);
        _submitBatchRoot(batchRoot);
    }
}

Інтеграція OP Stack через EigenDA Proxy

Для OP Stack-based rollups існує готовий EigenDA Proxy sidecar сервіс, який реалізує OP Stack alt-DA інтерфейс і трансльрує запити в EigenDA:

# docker-compose.yml для EigenDA Proxy
eigenda-proxy:
  image: ghcr.io/layr-labs/eigenda-proxy:latest
  environment:
    - EIGENDA_PROXY_ADDR=0.0.0.0
    - EIGENDA_PROXY_PORT=4242
    - EIGENDA_PROXY_EIGENDA_DISPERSER_RPC=disperser-holesky.eigenda.xyz:443
    - EIGENDA_PROXY_G1_PATH=/data/g1.point
    - EIGENDA_PROXY_G2_POWER_OF_TAU_PATH=/data/g2.point.powerOf2
  volumes:
    - ./data:/data

OP Stack batch poster конфігурується з --altda.da-service=true і вказує на proxy. Все решта прозоро — proxy сам обробляє dispersal, polling, збереження certificate.

Подібний паттерн для Arbitrum Orbit через AnyTrust: EigenDA може виступати як альтернатива Data Availability Committee (DAC).

Порівняння з альтернативами

EigenDA виигрує по throughput і вартості для високонаванилого rollups. Компромісс — додаткова залежність від EigenLayer і поки що часткова централізація disperser.

Операційні міркування

Характеристики Latency

Dispersal в EigenDA займає 10–15 секунд до confirmation (залежить від quorum і мережевих умов). Це потрібно враховувати в архітектурі sequencer: batch posting може бути асинхронним.

Retry і Fallback логіка

Disperser може стати недоступним. Потрібна fallback стратегія:

func postBatchWithFallback(batchData []byte) error {
    // Пробуємо EigenDA
    blobInfo, err := disperseToEigenDA(batchData)
    if err == nil {
        return postToEthereumWithEigenDARef(blobInfo)
    }
    
    log.Warn("EigenDA dispersal failed, falling back to calldata", "err", err)
    
    // Fallback: постим дані напрямку до Ethereum calldata
    // Дорожче, але гарантує liveness
    return postToEthereumCalldata(batchData)
}

Це паттерн з OP Stack AltDA spec: якщо DA layer недоступен — rollup може упасти обратно на Ethereum calldata, зберігаючи liveness ціною більшого gas.

Моніторинг

• Dispersal latency: алерт якщо >30 секунд
• Quorum thresholds: моніторинг відсотка ответивших операторів
• Certificate validity: всі сертифікати в Ethereum повинні пройти on-chain верифікацію

Тайм-лайн інтеграції

Інтеграція OP Stack rollup з EigenDA через proxy: 2–3 тижні (настройка інфраструктури, тестування на Holesky, моніторинг).

Кастомний rollup з нативною EigenDA інтеграцією: 4–8 тижнів (імплементація dispersal логіки, on-chain верифікатор, fallback механізм, аудит контрактів).

Розробка кастомного DA layer на базі EigenDA: 3–4 місяці (власні quorum параметри, кастомний ServiceManager контракт, інтеграція в EigenLayer).

EigenDA інтеграція передбачає роботу з testnet (Holesky) мінімум 2–3 тижні до mainnet деплою — занадто багато рухливих частин для миттєвої production.