Розробка системи модульного блокчейна
Монолітний блокчейн (Bitcoin, Ethereum до The Merge) поєднує чотири функції в одному шарі: виконання транзакцій (execution), консенсус, забезпечення доступності даних (data availability) та settlement. Це спрощує дизайн, але створює непереборний trilemma між безпекою, децентралізацією та масштабованістю.
Модульний підхід: розділити ці функції на спеціалізовані шари, кожен з яких оптимізований під свою задачу. Celestia — DA слой. Ethereum — settlement + DA (або тільки settlement якщо використовувати Celestia). Rollup — execution. Результат: execution layer може масштабуватися незалежно, не жертвуючи безпекою базових шарів.
Шари модульного стеку
Data Availability layer
DA — вузьке місце монолітних блокчейнів. Повні ноди мають скачувати всі дані щоб верифікувати доступність. При зростанні throughput — вимоги до ноди зростають, децентралізація падає.
Celestia вирішує через DAS (Data Availability Sampling). Light node скачує не весь блок, а випадкові маленькі чанки. За допомогою erasure coding (Reed-Solomon): дані закодовані з 2x надмірністю. Якщо 50%+ даних доступно — node може відновити все. Вероятність недоступності даних падає експоненціально з N samples.
Celestia DAS math:
- Блок кодується в матрицю k×k → розширюється в 2k×2k через RS erasure coding
- Light node сямплює R випадкових клітин
- P(false negative) = (1/2)^R
- При R=16: P < 0.002% — достатньо для production
- Light node тримає ~8MB RAM, не весь 1GB блок
Це дозволяє збільшити розмір блоку (throughput) без шкоди для можливості light node брати участь у верифікації.
EigenDA — альтернатива від EigenLayer: DA через restaking на Ethereum. Оператори EigenDA стейкають ETH через EigenLayer та надають DA сервіс. Більш щільна інтеграція з Ethereum безпекою, але менший throughput ніж Celestia на старті.
Avail (від Polygon) — ще один DA слой з схожим DAS підходом, але з додатковим Validity Bridge до Ethereum.
Execution layer: суверенний rollup vs settled rollup
Settled rollup публікує state commitments на Ethereum та використовує Ethereum для dispute resolution. Безпека успадкована від Ethereum: атака на rollup потребує атаки на Ethereum L1.
Суверенний rollup (Celestia концепція): публікує дані на Celestia (DA), але не має settlement контракту на Ethereum. Fork rules визначає саме rollup спільнота. Більше автономії, але безпека залежить від Celestia DA + власного консенсусу.
Архітектурне порівняння:
Optimism (settled):
L2 execution → [sequencer batches] → Ethereum L1 (settlement + DA)
Security: Ethereum consensus + fraud proofs
Celestia rollup (sovereign):
L2 execution → [блоки публікуються в Celestia] → fork choice: rollup nodes
Security: Celestia DAS + rollup validator set
Shared sequencer
Проблема поточних rollup: кожен має власний централізований sequencer. Sequencer може цензурувати транзакції, перевпорядковувати для MEV. Рішення: shared sequencer — децентралізована мережа, яка sequencing для множення rollup.
Espresso Systems: shared sequencer з HotShot BFT консенсусом. Rollup підписується на Espresso — їхні транзакції sequencing через спільну мережу. Перевага: атомарні cross-rollup транзакції (транзакція в Rollup A та Rollup B атомарно sequenced в одному Espresso блоці).
Astria: аналогічний підхід, використовує CometBFT консенсус (Tendermint fork). Нативна інтеграція з Celestia для DA.
Практична збірка: rollup на Celestia + OP Stack
Компоненти
┌─────────────────────────────────────────────┐
│ 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 з Celestia DA (op-plasma mode):
# Ініціалізація OP Stack rollup з Celestia DA
# 1. Запускаємо celestia-node у bridge режимі
celestia bridge init --core.ip <consensus-node-ip>
celestia bridge start --keyring.accname my-bridge
# 2. Конфігуруємо op-node для 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-байтний ідентифікатор вашого rollup у Celestia. Всі блоки вашого rollup публікуються у своєму namespace — інші rollup не читають ваші дані.
Fraud proofs vs validity proofs
Optimistic rollup (OP Stack, Arbitrum Nitro): транзакції приймаються як валідні, є challenge window (7 днів на Ethereum, налаштовується). Якщо хтось доведе мошенництво через fraud proof — state скасовується, sequencer slashed. Просто у реалізації, але 7-денна затримка виведення.
ZK rollup (zkSync Era, StarkNet, Polygon zkEVM): кожний батч супроводжується cryptographic proof коректності (STARK або SNARK). Миттєва фіналізація без challenge window. Але proof generation CPU/GPU-intensive та займає хвилини.
Вибір визначається use case: DEX/DeFi → ZK (фіналізація важлива). Gaming/social → Optimistic (низька вартість proof generation).
ZK stack: Boojum та Plonky2
// Plonky2 — recursive ZK proof system (Polygon)
// Дозволяє агрегувати proof від 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 верифікує proof B всередині себе. Дозволяє агрегувати тисячі транзакційних proofs в один фінальний proof для on-chain верифікації. Це ключове для throughput.
Interoperability: IBC та Hyperlane
Модульний стек створює екосистему різних rollup та chains. Потрібен протокол cross-chain messaging.
IBC (Inter-Blockchain Communication) — стандарт Cosmos. Працює між chains з Tendermint/CometBFT консенсусом. Строгі light client перевірки: кожна chain знає заголовки іншої. Trustless, але потребує обох chains підтримувати IBC.
Hyperlane: permissionless interoperability. Деплоїться на будь-якій EVM chain. Не потребує змін на destination chain — тільки деплой Hyperlane контрактів. Модульна безпека: Interchain Security Module дозволяє налаштувати верифікацію (multisig validators, ZK light client, optimistic verification).
// Hyperlane: відправка cross-chain повідомлення
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 для rollup nodes. Block explorer: Blockscout (self-hosted, підтримує EVM rollup).
Процес розробки
Архітектурний дизайн (2-4 тижні). Вибір шарів стека, визначення throughput вимог, settlement vs sovereign, fraud proofs vs ZK. Помилка на цьому етапі дорого коштує — переробляти DA layer або settlement механізм після деплоя крайне складно.
Розробка execution layer (4-8 тижнів). Fork/конфігурація OP Stack або обраного framework. Кастомні precompiles якщо потрібні. Інтеграція з DA layer.
Інфраструктура (4-6 тижнів). Sequencer деплой, validator set, мониторинг. Для production: географічний розподіл sequencer nodes, fallback на forced inclusion через L1 якщо sequencer недоступний.
Bridge контракти (2-4 тижні). L1↔L2 bridge для ETH та ERC-20. Security critical: bridge контракти під аудит обов'язково.
Testnet (2-4 місяці). Публічний testnet перед mainnet — обов'язково. Потрібні реальні користувачі для виявлення edge cases.
Орієнтири по срокам
Налаштований OP Stack rollup з Celestia DA на testnet — 8-12 тижнів. Production-ready modular chain з кастомним execution, ZK proofs та cross-chain bridge — 6-12 місяців. Це один з найскладніших blockchain проектів за scope інфраструктури.