Розробка кастомного рівня Data Availability для блокчейн-проектів

Уявіть: ваш rollup генерує 100 MB даних на хвилину, а публічні DA-шари на кшталт Celestia дають лише 8 MB за блок. Ви втрачаєте пропускну здатність, платите зайве за газ і залежите від чужої токеноміки. Кастомний рівень Data Availability (DA) вирішує ці проблеми: ви отримуєте до 1 GB/s пропускної здатності, приватні дані (якщо потрібно) та фіналізацію за секунду. Ми спроектували та впровадили DA-шари для трьох rollup-проектів — у двох використовували DAS з KZG, в одному — довірений комітет з BLS-агрегацією. За 5 років на ринку ми реалізували понад 15 блокчейн-проектів, включаючи open-source бібліотеки для KZG та BLS.

Як DAS захищає від утримання даних?

Замість завантаження всього блоку легкий клієнт випадково семплює десятки чанків. Якщо всі вони доступні — з імовірністю 99,9% (при 100 семплах) весь блок доступний. Це забезпечується 2D erasure coding (Reed-Solomon по рядках і стовпцях): дані кодуються з надлишковістю 2x, для відновлення достатньо 50% чанків. Блок-продюсер не може приховати >50% чанків без виявлення. Наші реалізації використовують 2D erasure coding, що дозволяє локалізувати fraud proofs: довести некоректність рядка або стовпця без завантаження всього блоку.

Чому KZG швидше за Merkle-proof?

KZG commitments — це поліноміальні зобов'язання на кривій BLS12-381. Commitment займає 48 байт, proof — ще 48 байт, верифікація — одна pairing-операція (~2ms). За нашими бенчмарками, генерація proof для чанка 256 KB займає ~5ms, верифікація ~2ms — у 20 разів швидше за Merkle-дерева для чанків того ж розміру. Безпека гарантується structured reference string (SRS) та бібліотекою arkworks.

use ark_bls12_381::{Bls12_381, Fr, G1Projective};
use ark_poly::{univariate::DensePolynomial, UVPolynomial};
use ark_poly_commit::kzg10::{KZG10, Powers, VerifierKey};

pub struct DALayer {
    powers: Powers<Bls12_381>,
    vk: VerifierKey<Bls12_381>,
}

impl DALayer {
    pub fn commit_blob(&self, data: &[u8]) -> (Commitment, Vec<Fr>) {
        let scalars = bytes_to_field_elements(data);
        let poly = DensePolynomial::from_coefficients_vec(scalars.clone());
        let (commitment, _) = KZG10::commit(&self.powers, &poly, None, None).unwrap();
        (commitment, scalars)
    }

    pub fn generate_proof(&self, data: &[Fr], index: usize) -> Proof {
        let poly = DensePolynomial::from_coefficients_vec(data.to_vec());
        let point = Fr::from(index as u64);
        KZG10::open(&self.powers, &poly, point, &Fr::zero()).unwrap()
    }

    pub fn verify_chunk(
        &self,
        commitment: &Commitment,
        index: usize,
        value: Fr,
        proof: &Proof,
    ) -> bool {
        let point = Fr::from(index as u64);
        KZG10::check(&self.vk, commitment, point, value, proof).unwrap()
    }
}

Мережевий рівень: розподіл та атестації

Дані розподіляються між DA-нодами через libp2p gossip. Кожна нода зберігає підмножину чанків і публікує signed атестацію. Атестації агрегуються в Data Availability Certificate (DAC) за допомогою BLS-підписів — 100 підписів упаковуються в 48 байт. Для enterprise-рішень достатньо порогу 2/3 від довіреного комітету; в публічних мережах додаємо слоти та slashing, як у Proof-of-Stake.

pub struct DAAttestation {
    pub block_hash: [u8; 32],
    pub block_height: u64,
    pub chunk_indices: Vec<u32>,
    pub timestamp: u64,
    pub signature: BLSSignature,
}

pub struct DAC {
    pub block_hash: [u8; 32],
    pub aggregate_signature: BLSAggregatedSignature,
    pub signer_bitfield: BitVec,
    pub threshold_met: bool,
}

Що входить у розробку кастомного DA-шару

• Аудит вимог та вибір схеми кодування
• Реалізація core DA-шару: DAS, erasure coding, KZG commitments
• P2P мережа на libp2p з gossip та sync
• Атестації та агрегація підписів (BLS)
• Інтеграція з rollup: контракти на L1, sequencer middleware
• Тестова мережа з навантажувальним тестуванням (десятки нод, 100+ MB/s)
• Документація та розгортання в production

Порівняння DA-рішень

Кастомний DA з DAS та KZG дає найкращу продуктивність та безпеку, але вимагає глибокої експертизи. Для 80% проектів достатньо Celestia або EigenDA. Якщо ваш випадок — решта 20%, отримайте консультацію.

Процес роботи

1. Аналітика: аудит поточної архітектури rollup/L1, збір вимог щодо пропускної здатності, приватності, фіналізації.
2. Проектування: вибір схеми кодування, параметри DAS, дизайн P2P та комітету.
3. Реалізація: core-модулі, контракти, інтеграція з rollup (2–4 місяці).
4. Тестування: unit, integration, навантажувальне тестування (50+ нод, 100+ MB/s).
5. Аудит безпеки: зовнішній аудит смарт-контрактів та криптографії.
6. Деплой: розгортання в тестовій мережі, міграція на mainnet.

Терміни: від 3 місяців для прототипу, від 6 місяців для production-ready рішення. Вартість розраховується індивідуально залежно від складності та обсягу робіт.