Разработка системы модульного блокчейна
Монолитный блокчейн (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 экспоненциально падает с N.
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, не full 1GB блок
Это позволяет увеличить размер блока (throughput) без ущерба для возможности light node участвовать в верификации.
EigenDA — альтернатива от EigenLayer: DA через restaking на Ethereum. Операторы EigenDA стейкают ETH через EigenLayer и предоставляют DA сервис. Более тесная интеграция с Ethereum security, но меньший 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 community. Больше autonomy, но безопасность зависит только от 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: каждый имеет собственный centralized sequencer. Sequencer может цензурировать транзакции, reorder для 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-дневный withdrawal delay.
ZK rollup (zkSync Era, StarkNet, Polygon zkEVM): каждый батч сопровождается cryptographic proof корректности (STARK или SNARK). Мгновенный finality без 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 контрактов. Модульная security: 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, monitoring. Для production: geographic distribution 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 инфраструктуры.