Development of Modular Blockchain System
Monolithic blockchain (Bitcoin, Ethereum pre-Merge) combines four functions in one layer: transaction execution, consensus, data availability guarantee, and settlement. Simplifies design but creates impossible trilemma between security, decentralization, and scalability.
Modular approach: split these functions into specialized layers, each optimized for its task. Celestia — DA layer. Ethereum — settlement + DA (or just settlement using Celestia). Rollup — execution. Result: execution layer scales independently without sacrificing base layer security.
Modular Stack Layers
Data Availability Layer
DA — bottleneck of monolithic blockchains. Full nodes must download all data to verify availability. As throughput grows — node requirements grow, decentralization falls.
Celestia solves via DAS (Data Availability Sampling). Light node downloads not whole block, but random small chunks. Through erasure coding (Reed-Solomon): data encoded with 2x redundancy. If 50%+ data available — node can recover everything. Probability of data unavailability decays exponentially with N samples.
Celestia DAS math:
- Block encoded in k×k matrix → expanded to 2k×2k via RS erasure coding
- Light node samples R random cells
- P(false negative) = (1/2)^R
- At R=16: P < 0.002% — sufficient for production
- Light node holds ~8MB RAM, not full 1GB block
Allows increasing block size (throughput) without hurting light node participation in verification.
EigenDA — alternative from EigenLayer: DA via restaking on Ethereum. EigenDA operators stake ETH via EigenLayer and provide DA service. Tighter Ethereum security integration, but less throughput than Celestia initially.
Avail (from Polygon) — another DA layer with similar DAS approach plus additional Validity Bridge to Ethereum.
Execution Layer: Sovereign Rollup vs Settled Rollup
Settled rollup publishes state commitments to Ethereum and uses Ethereum for dispute resolution. Security inherited from Ethereum: attacking rollup requires attacking Ethereum L1.
Sovereign rollup (Celestia concept): publishes data to Celestia (DA) but has no settlement contract on Ethereum. Fork rules determined by rollup community. More autonomy, but security depends on Celestia DA + own consensus.
Architectural comparison:
Optimism (settled):
L2 execution → [sequencer batches] → Ethereum L1 (settlement + DA)
Security: Ethereum consensus + fraud proofs
Celestia rollup (sovereign):
L2 execution → [blocks published to Celestia] → fork choice: rollup nodes
Security: Celestia DAS + rollup validator set
Shared Sequencer
Problem with current rollups: each has centralized sequencer. Sequencer can censor transactions, reorder for MEV. Solution: shared sequencer — decentralized network sequencing for multiple rollups.
Espresso Systems: shared sequencer with HotShot BFT consensus. Rollup subscribes to Espresso — their transactions sequenced through shared network. Advantage: atomic cross-rollup transactions (transaction in Rollup A and Rollup B atomically sequenced in one Espresso block).
Astria: similar approach, uses CometBFT consensus (Tendermint fork). Native integration with Celestia for DA.
Practical Build: Rollup on Celestia + OP Stack
Components
┌─────────────────────────────────────────────┐
│ Rollup (OP Stack fork) │
│ ┌────────────┐ ┌────────────────────────┐ │
│ │ Sequencer │ │ Execution Engine (geth)│ │
│ │ (op-node) │ │ (op-geth) │ │
│ └────────────┘ └────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ DA layer: Celestia │ │
│ │ Batches → celestia-node (bridge node) │ │
│ └────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ Settlement: Ethereum L1 │ │
│ │ OptimismPortal + L2OutputOracle │ │
│ └────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
OP Stack with Celestia DA (op-plasma mode):
# Initialize OP Stack rollup with Celestia DA
# 1. Start celestia-node in bridge mode
celestia bridge init --core.ip <consensus-node-ip>
celestia bridge start --keyring.accname my-bridge
# 2. Configure op-node for Celestia DA
# op-node.yaml
da:
type: celestia
celestia:
namespace: "0x...your-rollup-namespace..."
auth_token: "your-celestia-node-jwt"
rpc: "http://localhost:26658"
Namespace — 10-byte identifier of your rollup in Celestia. All rollup blocks published in your namespace — other rollups don't read your data.
Fraud Proofs vs Validity Proofs
Optimistic rollup (OP Stack, Arbitrum Nitro): transactions accepted as valid, challenge window exists (7 days on Ethereum, configurable). If someone proves fraud via fraud proof — state reverted, sequencer slashed. Simple to implement but 7-day withdrawal delay.
ZK rollup (zkSync Era, StarkNet, Polygon zkEVM): each batch accompanied by cryptographic proof of correctness (STARK or SNARK). Instant finality without challenge window. But proof generation CPU/GPU-intensive and takes minutes.
Choice determined by use case: DEX/DeFi → ZK (finality matters). Gaming/social → Optimistic (low proof generation cost).
ZK Stack: Boojum and Plonky2
// Plonky2 — recursive ZK proof system (Polygon)
// Allows aggregating proofs from sub-circuits
use plonky2::field::goldilocks_field::GoldilocksField;
use plonky2::plonk::circuit_builder::CircuitBuilder;
use plonky2::plonk::config::PoseidonGoldilocksConfig;
type F = GoldilocksField;
type C = PoseidonGoldilocksConfig;
const D: usize = 2;
fn build_transfer_circuit() -> CircuitData<F, C, D> {
let config = CircuitConfig::standard_recursion_config();
let mut builder = CircuitBuilder::<F, D>::new(config);
// Witness: sender_balance, amount, receiver_balance
let sender_balance = builder.add_virtual_target();
let amount = builder.add_virtual_target();
let receiver_balance = builder.add_virtual_target();
// Constraint: sender_balance >= amount
let diff = builder.sub(sender_balance, amount);
builder.range_check(diff, 32);
// Public inputs: new balances
let new_sender = builder.sub(sender_balance, amount);
let new_receiver = builder.add(receiver_balance, amount);
builder.register_public_input(new_sender);
builder.register_public_input(new_receiver);
builder.build::<C>()
}
Recursive proofs: proof A verifies proof B inside itself. Allows aggregating thousands of transaction proofs into one final proof for on-chain verification. Key for throughput.
Interoperability: IBC and Hyperlane
Modular stack creates ecosystem of different rollups and chains. Need cross-chain messaging protocol.
IBC (Inter-Blockchain Communication) — Cosmos standard. Works between chains with Tendermint/CometBFT consensus. Strict light client checks: each chain knows other's headers. Trustless but requires both chains support IBC.
Hyperlane: permissionless interoperability. Deploys on any EVM chain. Doesn't require destination chain changes — just deploy Hyperlane contracts. Modular security: Interchain Security Module lets configure verification (multisig validators, ZK light client, optimistic verification).
// Hyperlane: send cross-chain message
interface IMailbox {
function dispatch(
uint32 destinationDomain,
bytes32 recipientAddress,
bytes calldata messageBody
) external payable returns (bytes32 messageId);
}
contract CrossChainMessenger {
IMailbox public immutable mailbox;
function sendMessage(
uint32 destChainId,
address recipient,
bytes calldata data
) external payable {
bytes32 msgId = mailbox.dispatch{value: msg.value}(
destChainId,
TypeCasts.addressToBytes32(recipient),
data
);
emit MessageSent(msgId, destChainId, recipient);
}
}
Tooling
Rollup frameworks: OP Stack (Optimism), Arbitrum Orbit, ZK Stack (zkSync), Madara (StarkNet-based, Rust). DA: Celestia Node, EigenDA SDK, Avail. Shared sequencing: Espresso, Astria. Monitoring: Prometheus + Grafana, OpenTelemetry for rollup nodes. Block explorer: Blockscout (self-hosted, supports EVM rollups).
Development Process
Architectural design (2-4 weeks). Choose stack layers, define throughput requirements, settlement vs sovereign, fraud proofs vs ZK. Mistake at this stage is expensive — changing DA layer or settlement mechanism post-deploy is extremely difficult.
Execution layer development (4-8 weeks). Fork/configure OP Stack or chosen framework. Custom precompiles if needed. DA layer integration.
Infrastructure (4-6 weeks). Sequencer deploy, validator set, monitoring. For production: geographic distribution of sequencer nodes, fallback to forced inclusion via L1 if sequencer unavailable.
Bridge contracts (2-4 weeks). L1↔L2 bridge for ETH and ERC-20. Security critical: bridge contracts must undergo audit.
Testnet (2-4 months). Public testnet before mainnet — mandatory. Need real users for edge case discovery.
Development Timeline
Configured OP Stack rollup with Celestia DA on testnet — 8-12 weeks. Production-ready modular chain with custom execution, ZK proofs, and cross-chain bridge — 6-12 months. This is one of the most complex blockchain projects by infrastructure scope.