Розробка L3/appchain на базі Polygon CDK

Розробка L3/appchain на базі Polygon CDK

Власний appchain — це не просто "свій блокчейн". Це вибір архітектурного компромісу: ви отримуєте повний контроль над execution environment, gas політикою та throughput в обмін на відповідальність за секвенсування, DA та bridge security. Polygon CDK (Chain Development Kit) — набір компонентів для збірки ZK-валідуємих L2/L3. Давайте розберемо що це реально означає на практиці.

Що таке Polygon CDK та навіщо це потрібно

Polygon CDK — це модульний фреймворк для деплоя власної EVM-сумісної цепочки з ZK-proof системою. Під капотом: zkEVM (або Type 1 / Type 2 / Type 3 за Vitalik's taxonomy), Sequencer, Aggregator (генерує ZK-proof), bridge контракти на L1.

Коли appchain обґрунтований:

• Потрібен власний gas token (користувачі платять газ вашим токеном)
• Потребуються специфічні логіки EVM (precompiles для вашого додатку)
• Throughput > 1000 TPS недосяжний на L2 без власного секвенсера
• Кастомні правила включення транзакцій (whitelist, KYC-gate на рівні мережі)
• Ізоляція від noise інших додатків на shared L2

Коли appchain надмірний: MVP, проекти з < 100k користувачами, коли L2 deployed contracts достатньо.

Архітектура: Компоненти CDK-цепочки

zkEVM: Вибір типу

Polygon CDK пропонує кілька режимів:

Type 2 zkEVM (повна EVM-сумісність) — будь-який Solidity/EVM байткод працює без змін. Prover генерує ZK-proof еквівалентності EVM execution. Це те, що використовується в Polygon zkEVM mainnet beta. Overhead: час генерації proof (хвилини) та вартість верифікації на L1.

Validium mode — дані транзакцій зберігаються off-chain (Data Availability Committee, не Ethereum). Дешевше по L1 fees, але слабші гарантії DA. Для gaming/social appchain де DA не критична — обґрунтовано.

Sovereign chain — без bridge до Ethereum, власний консенсус. Максимальна незалежність, мінімальні гарантії безпеки.

Компоненти деплоя

L1 Ethereum (або Polygon PoS як базовий шар)
    └── Bridge Contract (LxLy bridge)
    └── PolygonRollupManager (управління rollup-ами)
    └── Verifier Contract (ZK proof verification)

L2/L3 CDK Chain
    ├── Sequencer Node — приймає tx, формує батчі
    ├── Prover / Aggregator — генерує ZK-proof для батча
    ├── RPC Node — публічний JSON-RPC для користувачів
    └── State DB — PostgreSQL + Merkle state tree

Налаштування власного секвенсера

Секвенсер — центральний компонент, який визначає порядок транзакцій. В CDK секвенсер працює в централізованому режимі (ви контролюєте), що дає максимальну продуктивність але потребує довіри. Decentralized sequencing — roadmap.

Конфігурація секвенсера

Ключові параметри в config.yaml:

sequencer:
  # Максимальний розмір батча (впливає на latency vs throughput)
  maxBatchSize: 300000  # gas units
  # Як часто закривати батч (у секундах)
  batchSealTime: 5
  # Мінімальний tip для включення транзакції
  minGasPrice: "1000000000"  # 1 Gwei

  # Gas token: якщо використовуєте свій токен
  feeTokenAddress: "0xYourTokenAddress"

  # Whitelist для sequencer access (якщо потрібна closed network)
  enableTransactionFilter: false

l1:
  rpcURL: "https://ethereum-rpc"
  chainID: 1
  # Як часто відправляти батчі на L1
  sendBatchFrequency: 300  # 5 хвилин

prover:
  uri: "prover-service:50052"
  # Timeout для proof generation
  timeout: 600s

Gas token: Ваш токен як засіб оплати газу

Одна з головних причин для appchain — газ у власному токені. CDK підтримує це через параметр GasTokenAddress при деплое. Користувачі платять газ вашим ERC-20 замість ETH/MATIC.

Важливо: bridge при цьому працює по-іншому. При бріджі нативного токена між L1 та L3, CDK використовує wrapped representation. Потрібно ретельно протестувати сценарії bridge + gas payment.

ZK Proof generation: Практичні аспекти

Це найбільш ресурсоємна частина. Прувер (zkProver) — окремий сервіс, генерує SNARK-proof для кожного батча.

Вимоги до залізо прувера:

• Мінімум: 32 CPU cores, 128 GB RAM, без GPU (CPU-based prover)
• Рекомендується: 64+ cores або GPU (CUDA-accelerated prover)
• Час генерації proof: 30 секунд — 5 хвилин на батч залежно від залізо

Горизонтальне масштабування: кілька прувер-нод з Aggregator-координатором. Aggregator розподіляє батчі між прувер-нодами та агрегує proof-и.

Aggregator
    ├── Prover Node 1 (batch 1001-1050)
    ├── Prover Node 2 (batch 1051-1100)
    └── Prover Node 3 (batch 1101-1150)

Bridge: LxLy bridge та кастомізація

CDK використовує LxLy bridge — унифікований bridge протокол Polygon для зв'язку L1-L2-L3. Підтримує bridge ETH, ERC-20, ERC-721 та довільних даних (message passing).

Стандартний flow deposit L1→L3:

1. Користувач вызывает bridgeAsset() на L1 bridge контракте
2. Подія записується в L1 Merkle tree
3. CDK chain спостерігає L1, клеймит депозит автоматично (через claimAsset()) або користувач клеймить сам

Кастомний bridge middleware — якщо потрібна KYC-проверка при бріджі або ограничення по суммам:

// Кастомний bridge wrapper з перевіркою whitelist
contract KYCBridgeWrapper {
    IPolygonZkEVMBridge public immutable bridge;
    mapping(address => bool) public kycApproved;

    function bridgeWithKYC(
        address token,
        uint256 amount,
        uint32 destinationNetwork,
        address destinationAddress
    ) external {
        require(kycApproved[msg.sender], "KYC required");
        IERC20(token).transferFrom(msg.sender, address(this), amount);
        IERC20(token).approve(address(bridge), amount);
        bridge.bridgeAsset(destinationNetwork, destinationAddress, amount, token, true, "");
    }
}

Data Availability: Вибір DA слоя

У стандартній конфігурації CDK дані транзакцій публікуються на Ethereum (calldata або EIP-4844 blobs). Це найбезпечніший варіант, але дорогий.

EIP-4844 (Proto-Danksharding) — blob-транзакції значно дешевше calldata. CDK підтримує blob posting. Економія: в 5-10x порівняно з calldata.

Validium / DAC (Data Availability Committee) — дані зберігаються у набору довірених нод, на L1 публікується тільки commitment (хеш). Дешевше в 10-100x, але потребує довіри до DAC. Для enterprise/gaming appchain — прийнятно.

Celestia або EigenDA — зовнішні DA шари. Decentralized DA з більш низькою вартістю чим Ethereum. CDK roadmap включає інтеграцію.

Моніторинг та операційка

Метрики які потрібно відслідковувати з першого дня:

# Prometheus alerts
- alert: SequencerStuck
  expr: polygon_cdk_last_batch_sent_minutes > 15
  annotations:
    summary: "Sequencer has not sent a batch for 15+ minutes"

- alert: ProverQueueDepth
  expr: polygon_cdk_prover_pending_batches > 30
  for: 5m
  annotations:
    summary: "Prover falling behind: {{ $value }} pending batches"

Процес розробки та деплоя

Фаза 1 (1 тиждень): Проектування. Вибір DA mode, gas token, bridge конфігурації. Визначення genesis параметрів (chainID, initial allocations). Планування інфраструктури.

Фаза 2 (1-2 тижні): Локальний деплой та тестування. Docker Compose з повним стеком: L1 (Hardhat/Anvil node), CDK sequencer, prover mock, bridge. Тестування end-to-end: деплой контрактів, bridge, транзакції.

Фаза 3 (1 тиждень): Testnet деплой. Деплой на public testnet (Sepolia L1). Тестування з реальним ZK-prover. Нагрузочное тестування секвенсера.

Фаза 4 (1 тиждень): Mainnet підготовка. Security review bridge контрактів, ключове управління (admin keys, upgrade authority), моніторинг, runbook для операторів.

Фаза 5 (3-5 днів): Mainnet деплой. Поступовий rollout, починаючи з обмеженими лімітами на bridge.

Усього: 5-7 тижнів від старту до mainnet. Основні ризики — час proof generation на наявному залізо та інтеграційні баги в bridge.

Вартість інфраструктури

Орієнтовні щомісячні затрати для production:

GPU-ускорений прувер (A100/H100) дає 5-10x ускорення proof generation, але коштує $2000-5000/місяць за аренду.