Розробка кастомного рівня 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 рішення. Вартість розраховується індивідуально залежно від складності та обсягу робіт.