Розробка L3/appchain на Polygon CDK: повний посібник

Ми розробляємо L3/appchain на базі Polygon CDK для проектів, яким потрібен повний контроль над середовищем виконання, газ-токеном та пропускною здатністю. Це не просто розгорнути свій блокчейн — це вибір архітектурного компромісу, де ви отримуєте гнучкість в обмін на відповідальність за секвенсуванн

Напрямки блокчейн-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1452
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1005
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1270
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1011

Ми розробляємо L3/appchain на базі Polygon CDK для проектів, яким потрібен повний контроль над середовищем виконання, газ-токеном та пропускною здатністю. Це не просто розгорнути свій блокчейн — це вибір архітектурного компромісу, де ви отримуєте гнучкість в обмін на відповідальність за секвенсування, DA та безпеку моста. Polygon CDK надає набір модульних компонентів для збірки ZK-валідованих L2/L3 з різними конфігураціями — від повноцінного ZK-Rollup до Validium із зовнішнім DA. Наша команда має 10+ років досвіду в блокчейн-розробці та 5+ років роботи з екосистемою Polygon, успішно запущено 15+ appchain-проектів. Ми допомагаємо обрати оптимальний режим, налаштувати bridge та запустити ланцюжок у production.

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

Polygon CDK — це модульний фреймворк для деплою власної EVM-сумісної ланцюжка з ZK-proof системою. Під капотом: zkEVM (Type 1/2/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 ├── 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, ""); } } 

Як обрати DA шар для вашого appchain?

У стандартній конфігурації CDK дані транзакцій публікуються на Ethereum (calldata або EIP-4844 blobs). Це найбезпечніший варіант, але дорогий. EIP-4844 (Proto-Danksharding) — blob-транзакції значно дешевші за calldata, економія в 5-10x. При навантаженні 1000 TPS витрати на L1 DA становлять близько $5 000 на день — для багатьох проектів це прийнятно. Validium / DAC (Data Availability Committee) — дані зберігаються у наборі довірених нод, на L1 публікується лише commitment (хеш). Дешевше в 10-100x, але потребує довіри до DAC. Для enterprise/gaming appchain — прийнятно. Celestia або EigenDA — зовнішні DA шари. Децентралізований DA з нижчою вартістю ніж Ethereum. CDK roadmap включає інтеграцію.

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

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

Метрика Поріг алерту Значення
Sequencer batch delay > 10 хв Секвенсер не відправляє батчі на L1
Prover queue depth > 50 батчів Прувер не встигає
L1 bridge sync lag > 100 блоків Депозити затримуються
RPC node response time > 2 сек Деградація для користувачів
Pending transactions > 1000 Backpressure на секвенсері
# 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" 

Як розгорнути appchain за 5–7 тижнів

  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. Testnet деплой (1 тиждень): деплой на public testnet (Sepolia L1). Тестування з реальним ZK-prover. Навантажувальне тестування секвенсера.
  4. Mainnet підготовка (1 тиждень): security review bridge контрактів, ключове управління (admin keys, upgrade authority), моніторинг, runbook для операторів.
  5. Mainnet деплой (3-5 днів): поступовий rollout, починаючи з обмеженими лімітами на bridge.

Основні ризики — час proof generation на наявному залізі та інтеграційні баги в bridge. Наші інженери підготують runbook і проведуть навантажувальне тестування.

Що входить до розробки appchain

  • Вибір та налаштування zkEVM (Type 2/Validium/Sovereign)
  • Деплой та кастомізація LxLy bridge (включно з KYC-проксі при необхідності)
  • Конфігурація секвенсера та прувера
  • Розгортання RPC нод з балансуванням
  • Інтеграція з DA шаром (Ethereum, Validium, Celestia)
  • Підключення до AggLayer для ліквідності
  • Налаштування моніторингу (Prometheus + Grafana) та алертів
  • Створення документації для операторів та користувачів
  • Навчання вашої команди та підтримка при деплої

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

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

Компонент Сервер Вартість, $/міс
Sequencer node 8 CPU, 32 GB, NVMe 200-400
Prover node (CPU) 32+ CPU, 128 GB 600-1200
RPC nodes (2x) 4 CPU, 16 GB 200-400
State DB (PostgreSQL) Managed 100-300
L1 DA costs Залежить від TPS Змінна

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

Замовте розробку appchain під ключ. Зв'яжіться з нами для оцінки вашого проекту. Отримайте консультацію вже сьогодні.