Development of a Custom Data Availability Layer for Blockchain Projects

Imagine: your rollup generates 100 MB of data per minute, while public DA layers like Celestia provide only 8 MB per block. You lose throughput, pay extra gas, and depend on someone else's tokenomics. A custom Data Availability (DA) layer solves these problems: you get up to 1 GB/s throughput, private data (if needed), and finalization in seconds. We have designed and implemented DA layers for three rollup projects — two using DAS with KZG, one using a trusted committee with BLS aggregation. In 5 years on the market, we have implemented more than 15 blockchain projects, including open-source libraries for KZG and BLS.

How DAS protects against data withholding?

Instead of downloading the entire block, a light client randomly samples dozens of chunks. If all are available — with 99.9% probability (at 100 samples) the entire block is available. This is ensured by 2D erasure coding (Reed-Solomon along rows and columns): data is encoded with 2x redundancy, so 50% of chunks suffice for recovery. The block producer cannot hide more than 50% of chunks without detection. Our implementations use 2D erasure coding, which enables localized fraud proofs: prove a row or column is incorrect without downloading the entire block.

Why is KZG faster than Merkle proofs?

KZG commitments are polynomial commitments on the BLS12-381 curve. Commitment size is 48 bytes, proof is also 48 bytes, verification requires one pairing operation (~2ms). According to our benchmarks, generating a proof for a 256 KB chunk takes ~5ms, verification ~2ms — 20 times faster than Merkle trees for chunks of the same size. Security is guaranteed by the structured reference string (SRS) and the arkworks library.

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() } } 

Network layer: distribution and attestations

Data is distributed among DA nodes via libp2p gossip. Each node stores a subset of chunks and publishes a signed attestation. Attestations are aggregated into a Data Availability Certificate (DAC) using BLS signatures — 100 signatures are packed into 48 bytes. For enterprise solutions, a threshold of 2/3 of the trusted committee is sufficient; in public networks, we add slots and slashing, as in 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, } 

What is included in custom DA layer development

• Requirements audit and selection of encoding scheme
• Core DA layer implementation: DAS, erasure coding, KZG commitments
• P2P network on libp2p with gossip and sync
• Attestations and signature aggregation (BLS)
• Integration with rollup: L1 contracts, sequencer middleware
• Testnet with load testing (tens of nodes, 100+ MB/s)
• Documentation and production deployment

Comparison of DA solutions

Custom DA with DAS and KZG delivers the best performance and security, but requires deep expertise. For 80% of projects, Celestia or EigenDA suffice. If your case is the remaining 20%, get a consultation.

Work process

1. Analytics: audit of current rollup/L1 architecture, collection of requirements for throughput, privacy, finalization.
2. Design: selection of encoding scheme, DAS parameters, P2P and committee design.
3. Implementation: core modules, contracts, rollup integration (2–4 months).
4. Testing: unit, integration, load testing (50+ nodes, 100+ MB/s).
5. Security audit: external audit of smart contracts and cryptography.
6. Deployment: testnet deployment, migration to mainnet.

Timeline: from 3 months for a prototype, from 6 months for a production-ready solution. Cost is calculated individually based on complexity and scope.