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.

Over 5 years, we have implemented more than 15 blockchain projects, including custom DA layers for three rollups. Our engineers are authors of open-source libraries for KZG and BLS. If you need a DA layer with guarantees, contact us — we will evaluate your project in 2 days. Order the development of a custom Data Availability layer to get maximum performance and control.

Blockchain Infrastructure Deployment: Nodes, RPC, Indexing

Subgraph fell at 3:47 AM. By morning users saw outdated balances, transactions "hung" in the UI, support received 47 tickets in an hour. Cause: the handler in the subgraph failed on a transaction with a non-standard event log — and the entire index stopped. We have encountered such situations dozens of times. Our experience shows: blockchain infrastructure does not forgive gaps in observability. Guaranteeing uptime without multi-layered monitoring and fault-tolerant architecture is impossible. Over 8 years working with Ethereum, Polygon, and Solana, we have developed an approach that allows predictable deployment of infrastructure of any scale — from a single node to a multichain grid with dozens of subgraphs.

RPC Layer Architecture

Every dApp interaction with the blockchain goes through RPC — the JSON-RPC API provided by a node. Three options:

Managed providers — Alchemy, QuickNode, Infura, Ankr. Minimal operational costs, SLA, built-in monitoring. Limits: rate limits (Alchemy Free: 300 RU/sec), vendor lock, potential downtime during provider incidents. For most projects — the right choice at the start.

Self-owned nodes — full control, no rate limits, no third-party dependence. Cost: archive Ethereum node requires 2.5–3TB SSD, a strong server, and DevOps support. Sync from scratch on Ethereum via Geth/Nethermind — 3–7 days. Justified under high load or latency requirements.

Hybrid — self-owned node as primary, managed provider as fallback. Standard for protocols with high TVL. Proper load balancing can reduce costs by 20–30% compared to pure managed setup. Under high monthly request volume, hybrid saves significantly.

How to Set Up an RPC Layer Without a Single Point of Failure?

At least two providers, DNS round-robin with health check every 5 seconds, automatic fallback when latency >500 ms. In practice, this gives 99.99% availability during any provider failure. For protocols with high TVL, we recommend a custom HA-proxy (nginx or Envoy) in front of two managed providers.

Why Is a Hybrid RPC Scheme More Cost-Effective Than Pure Managed?

At high request volumes, managed providers can be very expensive; a hybrid using a self-owned node as primary and a managed fallback cuts costs significantly without losing SLA.

Ethereum Node Clients

Execution clients: Geth (most used), Nethermind (C#, fast sync), Besu (Java, enterprise), Erigon (fastest sync, efficient archive mode ~2TB instead of 3TB).

Consensus clients (post-Merge): Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim). Each node after The Merge requires a pair of execution + consensus clients.

For DevOps: eth-docker — Docker Compose configurations for all client combinations. Setting up monitoring via Grafana + Prometheus is mandatory; a standard dashboard is available in each client's repository.

The Graph: Event Indexing

The Graph Protocol — decentralized indexing. A subgraph describes which events from which contracts to index and how to transform them into a GraphQL schema.

Subgraph structure:

• subgraph.yaml — manifest: contract addresses, startBlock, events to handle
• schema.graphql — GraphQL schema of entities
• src/mapping.ts — AssemblyScript event handlers

dataSources:
  - kind: ethereum
    name: UniswapV3Pool
    network: mainnet
    source:
      address: "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640"
      abi: UniswapV3Pool
      startBlock: 12370624
    mapping:
      eventHandlers:
        - event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
          handler: handleSwap

AssemblyScript handlers — not TypeScript. No nullable types, no closures, no many standard APIs. An error in the handler stops the subgraph indexing on that transaction. Important: add try-catch for operations that can fail (e.g., store.get() for an entity that may not exist).

How to Avoid Subgraph Indexing Stops?

Graph Node logs are monitored in real-time; on hasIndexingErrors = true an alert fires and an automatic node restart (via systemd or Kubernetes). Typical downtime on error — 150–300 seconds to recover. Additionally, for production we set up a watchdog that restarts Graph Node if subgraph lag exceeds 50 blocks.

Choosing Between Hosted Service and Decentralized Network

Graph Hosted Service (free, centralized) is deprecated in favor of Subgraph Studio + Graph Network. For production: deploy on Graph Network with GRT curation signal — the subgraph gets indexers proportional to curation.

Alternatives to The Graph: Ponder (TypeScript, self-hosted, easier to debug), Envio (ultra-fast indexer, supports EVM + non-EVM), Subsquid (TypeScript, own network), Moralis Streams (managed, webhook-based). Our experience shows: for high-load projects with unique logic, Ponder or Envio are more effective — they give full control over the process and do not require GRT tokenomics.

Webhooks and Real-Time Notifications

Alchemy Webhooks and QuickNode Streams allow receiving events in real-time via HTTP webhook or WebSocket. For monitoring addresses, new transactions, mints — this is faster than polling RPC.

Tenderly — platform for monitoring and alerts. You can set up an alert for a specific contract event, balance change, function call with certain parameters. Transaction simulation via Tenderly API is invaluable for debugging.

Monitoring and Observability

Minimum monitoring stack for a protocol:

On-chain: OpenZeppelin Defender Sentinel — watches contract events, triggers webhook or Autotask when conditions are met. Forta Network — community-maintained bots detect anomalies (large withdrawals, flash loans, governance attacks).

Infrastructure: Grafana + Prometheus for nodes, Datadog or Grafana Cloud for managed metrics. Alerts on: node is 10+ blocks behind, RPC latency >500ms, subgraph lag >100 blocks.

Uptime: Better Uptime or PagerDuty on RPC endpoint and subgraph health endpoint (The Graph provides _meta { hasIndexingErrors, block { number } }).

Why Is Monitoring Without Tenderly Insufficient?

Tenderly provides transaction simulation and detailed traces — critical for debugging subgraph and smart contract errors. Forta focuses on network anomalies, not your infrastructure. The combination of Tenderly plus a custom Grafana dashboard covers 90% of incident scenarios.

Multichain Infrastructure

A protocol on 5 chains = 5 separate RPC endpoints, 5 subgraphs, 5 monitoring configs. Manageable but requires deployment automation.

For subgraph multi-network deployment: graph deploy --network mainnet, graph deploy --network arbitrum-one etc. with a unified codebase and network-specific addresses in separate config files.

Chainlink CCIP and LayerZero for cross-chain messaging require monitoring of both chains and transactions on intermediate relayers. A reorg on the source chain after a confirmed mint on the target chain is a classic bridge problem. Solution: wait for finality (on Ethereum ~15 minutes after Merge for economic finality) before confirming on the target chain.

Infrastructure Setup Process

1. Audit current stack — determine chains, request volume, latency and availability requirements.
2. Architecture design — select providers, load balancing, redundancy.
3. Subgraph development — manifest → schema → handlers → testing on local Graph Node → deploy to testnet → mainnet.
4. Monitoring configuration — Tenderly alerts, Grafana dashboard, PagerDuty integration.
5. Documentation and runbook — what to do when: subgraph falls behind, RPC downtime, node desync.
6. Handover to operations — team training, access transfer, first month support.

What's Included

• Deployment of managed or self-hosted Ethereum, Polygon, BNB Chain nodes
• RPC layer setup with primary/fallback and load balancing
• Subgraph development and deployment for your protocol
• Monitoring connection (Tenderly, Grafana, alerts)
• Runbook and operations documentation
• Team training (up to 4 hours online)
• 30-day support after delivery

Timeline

All projects are managed in a GitHub/GitLab repository with CI/CD; configuration code stays with you. Order infrastructure deployment — we'll show how to cut costs by 20–30% without losing reliability. Get a consultation — we'll demonstrate how we deployed infrastructure for a protocol with large TVL on Ethereum and Arbitrum. Contact us.