Разработка 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 (пользователи платят gas вашим токеном)
• Требуется специфическая логика в 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 параметр при деплое. Пользователи платят gas вашим 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/месяц за аренду.