Разработка кастомного уровня 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-готового решения. Стоимость рассчитывается индивидуально в зависимости от сложности и объёма работ.