Розробка Layer 2 рішення

Розробка Layer 2 рішення

"Нам потрібне власне L2" — фраза, яку я чую все частіше. Іноді це обґрунтовано: проект з тисячами транзакцій за секунду, який не хоче платити Ethereum gas та не хоче залежати від чужої інфраструктури. Частіше — це надлишково, та достатньо існуючого L2. Перш ніж будувати власне L2, потрібно чесно відповісти: вам потрібно application-specific rollup чи ви просто хочете дешеві транзакції? У другому випадку — розгортання на Arbitrum або OP Stack займе дні, а не місяці.

Типологія L2: що саме будуємо

Optimistic Rollup

Транзакції виконуються off-chain, результат (state root) публікується в L1. Передбачається, що всім честь — якщо хтось знайшов мошенництво, він подає fraud proof протягом challenge window (7 днів для Arbitrum, 7 днів для OP Stack).

Плюси: EVM-еквівалентність або близькість до неї, зрілі фреймворки (OP Stack, Arbitrum Orbit). Мінуси: 7-денний withdrawal period для виводу на L1. Нативно вирішується через liquidity providers (мости типу Hop, Across).

Готові фреймворки:

• OP Stack — використовується Base, Mode, Zora, десятки інших. Відкритий код, Superchain концепція від Optimism.
• Arbitrum Orbit — для створення L3 поверх Arbitrum One/Nova.

ZK Rollup

Кожен батч транзакцій супроводжується zero-knowledge proof — математичним доказом коректності. L1 верифікує proof, а не виконує транзакції заново.

Плюси: Миттєвий withdrawal finality (немає challenge window), криптографічні гарантії замість економічних. Мінуси: Складність — ZK proof generation вимагає спеціалізованих схем. Не всі EVM opcode'и ефективно доказувані.

Готові фреймворки:

• Polygon CDK (Chain Development Kit) — для zkEVM-compatible цепей
• zkSync ZK Stack — на базі zkSync Era інфраструктури
• Scroll SDK — якщо потрібна максимальна EVM-еквівалентність

Validium

Як ZK Rollup, але дані зберігаються off-chain (Data Availability Committee або IPFS), не в L1. Дешевше, але слабші гарантії доступності даних.

Application-specific chain (не rollup)

Іноді потрібна не L2 як rollup, а окрема цепь з власним консенсусом. Cosmos SDK для цього — стандартний вибір: Inter-Blockchain Communication (IBC) для міжсітьових переводів, повний контроль над governance та gas token.

Розробка на OP Stack: детальний розбір

OP Stack — найбільш зрілий вибір для EVM-сумісного Optimistic Rollup. Розглянемо ключові компоненти.

Компоненти системи

L1 (Ethereum)
├── OptimismPortal.sol      — депозиты L1→L2, withdrawals L2→L1
├── L2OutputOracle.sol      — зберігає L2 state roots
├── DisputeGameFactory.sol  — fault proof games (Cannon)
└── SystemConfig.sol        — параметри цепи

L2 (OP Stack chain)
├── op-node              — consensus (читає L1, керує sequencer)
├── op-geth              — execution (форк Geth)
├── op-batcher           — публікує L2 транзакції в L1 calldata/blobs
└── op-proposer          — публікує L2 output roots в L1

Розгортання OP Stack цепи

# Клонування Optimism monorepo
git clone https://github.com/ethereum-optimism/optimism.git
cd optimism
git checkout op-contracts/v1.6.0

# Встановлення залежностей
pnpm install
make op-node op-batcher op-proposer

Конфігурація цепи через deploy-config.json:

{
  "l1ChainID": 1,
  "l2ChainID": 42069,
  "l2BlockTime": 2,
  "l1BlockTime": 12,
  "maxSequencerDrift": 600,
  "sequencerWindowSize": 3600,
  "channelTimeout": 300,
  "p2pSequencerAddress": "0x...",
  "batchInboxAddress": "0xff00000000000000000000000000000000042069",
  "batchSenderAddress": "0x...",
  "l2OutputOracleSubmissionInterval": 120,
  "l2OutputOracleStartingBlockNumber": 0,
  "l2OutputOracleStartingTimestamp": ...,
  "l2OutputOracleProposer": "0x...",
  "l2OutputOracleChallenger": "0x...",
  "finalizationPeriodSeconds": 604800,
  "proxyAdminOwner": "0x...",
  "baseFeeVaultRecipient": "0x...",
  "l1FeeVaultRecipient": "0x...",
  "sequencerFeeVaultRecipient": "0x...",
  "enableGovernance": false,
  "governanceTokenSymbol": "OP",
  "governanceTokenName": "Optimism",
  "eip1559Denominator": 50,
  "eip1559Elasticity": 6,
  "l2GenesisBlockGasLimit": "0x2faf080",
  "l2GenesisBlockBaseFeePerGas": "0x3B9ACA00"
}

Розгортання L1 контрактів:

cd packages/contracts-bedrock
forge script scripts/deploy/Deploy.s.sol:Deploy \
  --rpc-url $L1_RPC_URL \
  --broadcast \
  --private-key $DEPLOYER_PRIVATE_KEY \
  --slow

Data Availability: calldata vs EIP-4844 blobs

До EIP-4844 (Dencun upgrade, березень 2024) L2 публікував дані в L1 calldata — дорого (~$1–5 за batch). Після Dencun — через blobs (EIP-4844): спеціальний тип даних в блоці з окремим ринком газу. Blobs удешевлюють публікацію даних в ~10–100x.

// op-batcher використовує blobs автоматично якщо L1 їх підтримує
// Конфіг в op-batcher:
--data-availability-type blobs  // або 'calldata' для принудового fallback
--max-channel-duration 1800     // максимум 1800 блоків L2 в одному каналі

Для високонагруженого L2: якщо blob простору не вистачає (blob gas market перегружен) — настройте fallback на EigenDA або Celestia як зовнішний DA layer. Це validium-підхід, але з кращими гарантіями ніж pure off-chain.

Sequencer: централізація та її наслідки

Класичний OP Stack має єдиний sequencer — довірений, централізований. Це acknowledged tradeoff: зручність в обмін на централізацію.

Для production-проектів — розглядайте shared sequencer варіанти:

• Espresso Systems — decentralized sequencer для OP Stack цепей
• Based rollup — sequencer-free, блоки пропонуються L1 validators напрямки

Або мінімально: sequencer за multisig з моніторингом та автоматичним force-include для користувачів, якого sequencer ігнорує.

Мост: стандарт та безпека

L1StandardBridge та L2StandardBridge — вбудовані мості OP Stack. Для кастомних токенів:

// Кастомний ERC-20 з підтримкою стандартного моста
contract MyL2Token is OptimismMintableERC20 {
    constructor(
        address _bridge,
        address _remoteToken
    ) OptimismMintableERC20(_bridge, _remoteToken, "MyToken", "MTK") {}
}

Ніколи не деплойте кастомний мост без ретельного аудиту. Більшість громадких взломів у Web3 — саме мості: Ronin ($625M), Wormhole ($320M), Nomad ($190M). Використовуйте стандартний мост, додавайте кастомну логіку тільки коли абсолютно необхідно.

Sequencer economics

L2 мережа заробляє:

• L2 gas fees — користувачі платять за виконання на L2
• L1 data cost — sequencer витрачає на публікацію даних в L1

Маржа = L2 fees − L1 publishing cost. EIP-4844 blobs різко знизили L1 cost, що дозволяє встановлювати low gas price на L2 та всі рівно бути прибутковими.

L2 Transaction Fee = L2 Base Fee × Gas Used + L1 Data Fee
L1 Data Fee = (tx data size × 16) × L1 Base Fee × overhead_scalar

Калькулятор для вашої цепи: l2fees.info — корисна референсна точка.

ZK шлях: zkSync ZK Stack

Якщо вибрали ZK Rollup — ZK Stack від Matter Labs:

# ZK Stack CLI
curl -L https://raw.githubusercontent.com/matter-labs/zksync-era/main/zkstack_cli/zkstackup/install | bash
zkstackup

# Створення нової цепи
zkstack ecosystem create
zkstack chain create --chain-name mychain --chain-id 12345

ZK Stack використовує Boojum — proof system на основі PLONK з custom gates. Proof generation займає хвилини та потребує GPU для production скоростей (~RTX 4090 або A100).

Реальне час proof generation:

• CPU (32 cores): ~15–30 хвилин на батч
• RTX 4090: ~2–5 хвилин
• A100: ~1–2 хвилини

Для проекту з частими транзакціями — GPU prover обов'язковий.

Часові та фінансові оцінки

Бюджет на інфраструктуру (щомісячно):

• L1 gas для sequencer: $500–$5000/місяць (залежить від активності)
• RPC провайдери (L1 та L2): $500–$2000/місяць
• Серверів (sequencer, nodes): $500–$3000/місяць
• Block explorer (Blockscout self-hosted): $200–$500/місяць

Власне L2 — це не разова робота, це операційна відповідальність. Хтось повинен слідкувати за нодами, оновлювати клієнти, моніторити мост та реагувати на інциденти 24/7.