Albert

Polygon Chain Development Kit, an open-source framework for rapidly deploying ZK-driven L2 on Ethereum.

The high-level architecture of chains developed using Polygon CDK can customize business rules just like L1 blockchains.

Why Choose Polygon CDK?#

Design Principles of Polygon CDK

• Highly modular, allowing developers to customize chains according to their needs, from execution environments to gas tokens.
• High scalability, L2 developed with CDK can increase transaction speed.
• Unified liquidity, chains developed with CDK ensure asset transfers between chains within the Polygon 2.0 L2 ecosystem.
• Independent DA, chains developed with CDK have dedicated DA and DAC, providing robust off-chain data access and reliability.
• Composable operability, enabling seamless interaction and asset exchange between chains with LXLY Bridge.
• Near-instant finality, chains deployed using Polygon CDK rely on cryptographic security, ensuring transaction integrity without the need for full nodes.

Key Factors

• Scalability for Ethereum, CDK chains can scale Ethereum.
• Business logic customization, CDK chains fully support EVM, allowing custom gas limits, op code compatibility, and technical integration.
• Privacy options, CDK chains can create private app chains. This provides an option for those prioritizing privacy, supporting clients in maintaining the confidentiality of their application data while enjoying the benefits of blockchain technology.
• Compliance-oriented, CDK chains can achieve network sovereignty and compliance, allowing network maintainers to choose administrators that comply with local regulations, ensuring adherence to regional regulatory requirements.
• Extensive Web3 support, CDK chains are direct forks of the zkEVM stack, facilitating service portability and leveraging a comprehensive ecosystem.

Polygon CDK Data Availability#

Data availability separates transaction execution from data storage, allowing transaction data to reside off-chain while still being available for verification, greatly enhancing scalability and reducing costs.

Polygon CDK Validium is a unique scaling solution based on zkEVM that integrates DAC, a distinctive data availability approach.

Within the Polygon CDK framework, Data Availability Committee (DAC) members run DA nodes to ensure the security, accessibility, and integrity of off-chain data. Off-chain data is managed by the DAC, ensuring availability.

Data Availability Committees have a core responsibility: to verify that everyone can access the data required to reconstruct L2 state based on on-chain events. This means that even if L2 operators go offline, users can still access their asset data.

In CDK-developed chains, DAC acts as a secure node alliance, ensuring off-chain data access.

Advantages of DAC:

• Lower Transaction Fees Reduced computational requirements lead to lower fees.
• State Privacy Ensures data integrity.

DAC members are managed by smart contracts on L1. The sequencer sends L2 batch data to DAC members, only uploading the hash value (accumulated input hash) to L1, rather than the complete L2 transaction data.

• The sequencer has an ECC private key and signs the L2 batch data with its private key before sending it to the DAC.

// Signed sequence with sequencer signature
type SignedSequence struct {
	Sequence  Sequence       `json:"sequence"`
	Signature types.ArgBytes `json:"signature"`
}

// Data that sequencer needs to send to L1, along with some metadata
// Sorted list of transactions, referred to as sequence
type Sequence struct {
	Batches         []batch.Batch `json:"batches"`
	OldAccInputHash common.Hash   `json:"oldAccInputhash"`
}

// Batch structure
type Batch struct {
	Number         types.ArgUint64 `json:"number"`
	GlobalExitRoot common.Hash     `json:"globalExitRoot"`
	Timestamp      types.ArgUint64 `json:"timestamp"`
	Coinbase       common.Address  `json:"coinbase"`
	L2Data         types.ArgBytes  `json:"batchL2Data"`
}

• DAC members provide APIs (datacom services) to the sequencer.
  • Read the sequencer address from L1 contracts (will listen for updates if there are any).
  • Receive & store L2 batch data sent by the sequencer (this part is referred to as offchain data by CDK).
    • Verify the sequencer address (recover through the sequencer's ECC signature).
    • Store data.
    • Copy

      func (db *DB) StoreOffChainData(ctx context.Context, od []offchaindata.OffChainData, dbTx pgx.Tx) error
      

  • After successful storage, sign the accumulated input hash and return it to the sequencer (each DAC member has an ECC private key).
  • Core code:
    • Copy

      func (d *DataComEndpoints) SignSequence(signedSequence sequence.SignedSequence) (interface{}, types.Error)
      

Differences in Deployment between zkEVM and Validium#

• zkEVM Deployment

  • zkEVM Node, manages the polygon zkEVM network, processes transactions, maintains state, and interacts with L1.

    • Components include: JSON RPC, Pool DB, Sequencer, State DB, Synchronizer, Aggregator, Prover.
    • Codebase: https://github.com/0xPolygonHermez/zkevm-node

  • zkEVM Contracts, a series of contracts deployed on Ethereum, mainly including PolygonZkEVM, PolygonZkEVMBridge, and PolygonZkEVMGlobalExitRoot.

    • Codebase: https://github.com/0xPolygonHermez/zkevm-contracts

• Validium Deployment

  • Data Availability Layer
    • Codebase: https://github.com/0xPolygon/cdk-data-availability
  • zkEVM Node with Validium Extensions
    • Codebase: https://github.com/0xPolygon/cdk-validium-node
  • Validium-specific DAC Contract, mainly including CDKDataCommittee.sol and CDKValidium.sol.
    • Codebase: https://github.com/0xPolygon/cdk-validium-contracts

zkEVM vs. Validium

Key Components of zkEVM Node#

• Aggregator
  • Responsible for submitting validity proofs of L2 state to L2.
    • It needs to obtain transaction batches from the sequencer.
    • Interacts with the prover to obtain zk proofs, aggregating multiple proofs into a single proof.
    • Uses EthTxManager to send the aggregated zk proof to L1.
• Prover
  • Responsible for generating zk proofs for batched transactions, which are used to verify L2 state on L1.
• Sequencer
  • Responsible for ordering L2 transactions, pushing L2 state forward.
    • Transaction Ordering, retrieves transactions from the tx pool and adds them to the state.
    • State Transition, collaborates with the Executor to execute transactions and update the state.
    • Trusted finality confirmation, once the sequencer adds transactions to the state, it shares that information with other nodes, making the transaction final (trust at the sequencer level).
      • Other nodes only achieve final confirmation after receiving zk proof.
• SequenceSender
  • SequenceSender sends the sorted list of transactions (referred to as sequence) to L1.
    • What is sent is actually the fingerprint of the sequence (can be understood as a hash value).
    • Uses EthTxManager to handle L1 transactions.
  • It also collaborates with the data availability layer to ensure all transaction data can be accessed off-chain.
• Synchronizer
  • Synchronizer keeps the local state of nodes synchronized with Ethereum L1, serving as a bridge between L1 and L2 nodes.
    • Listens for events from L1 contracts.
    • Downloads data from the data availability layer based on L1 events.
    • Updates state to keep the local state consistent with the mainnet.
    • Handles L1 block reorganization: detects and manages blockchain reorganization to maintain data integrity.
• Executor
  • Implements state transitions, i.e., the VM implementation.
    • Batch execution: receives execution requests for a batch of transactions.
    • EVM-compatible transaction processing.
    • Extracts necessary metadata from execution, such as state root, transaction receipts, logs (events).
• EthTxmanager
  • Used for interacting with the ETH mainnet, including:
    • Managing requests from SequenceSender and Aggregator to send transactions to L1.
    • Managing nonce for accounts involved in transactions.
    • Dynamically adjusting gas prices to ensure timely transaction packaging.
• State
  • An important component for node data management.
    • State management, handling all state-related data, including batches, blocks, and transactions.
    • Communicates with the Executor to process transactions and update state.
    • StateDB is used for state persistence.
• Pool
  • Transaction pool for temporary storage of transactions.
    • Temporarily stores transactions submitted via RPC.
    • Provides transactions to the Sequencer for transaction ordering and batch packaging.
• JSON RPC
  • HTTP interface for user interaction.
• L2GasPricer
  • Calculates L2 gas price based on L1 gas price.

Contracts#

There are mainly three contracts.

CDKDataCommittee Contract#

The CDKDataCommittee contract is used to manage DAC members and verify DAC signatures. It has two main methods:

• Admin can set DAC members and N/M multi-signatures.

  Copy

  function setupCommittee(
          uint _requiredAmountOfSignatures,
          string[] calldata urls,
          bytes calldata addrsBytes
      ) external
  

• Verify DAC signatures.

  • Verifies whether signedHash has reached the required signature threshold.
  Copy

  function verifySignatures(
          bytes32 signedHash,
          bytes calldata signaturesAndAddrs
      ) external view
  
  // signedHash is calculated based on BatchData, not transactionsHash.
  

CDKValidium Contract#

Manages and updates the state of L2.

• The trusted sequencer submits transaction batches to this contract.

  • sequenceBatches will call the verifySignatures method of the CDKDataCommittee contract to verify if DAC signatures meet the threshold.
  Copy

  function sequenceBatches(
          BatchData[] calldata batches, // BatchData contains transactionsHash
          address l2Coinbase,
          bytes calldata signaturesAndAddrs
      ) external ifNotEmergencyState onlyTrustedSequencer
  
  struct BatchData {
          bytes32 transactionsHash; // keccak256 of L2 transactions
          bytes32 globalExitRoot; // Global exit root for this batch, used for L1 withdrawals
          uint64 timestamp;
          uint64 minForcedTimestamp;
      }
  

• verifyBatches verifies transaction batches.

  • Provides zk proof to prove a batch of transactions.
  Copy

  // Only TrustedAggregator can call this
  function verifyBatchesTrustedAggregator(
          uint64 pendingStateNum,
          uint64 initNumBatch,
          uint64 finalNewBatch,
          bytes32 newLocalExitRoot,
          bytes32 newStateRoot,
          bytes32[24] calldata proof
      ) external onlyTrustedAggregator
  
  function verifyBatches(
          uint64 pendingStateNum,
          uint64 initNumBatch,
          uint64 finalNewBatch,
          bytes32 newLocalExitRoot,
          bytes32 newStateRoot,
          bytes32[24] calldata proof
      ) external ifNotEmergencyState
  

PolygonZkEVMBridge Contract#

A bridge deployed on L1 and L2 for cross-chain asset transfers.

Data Flow#

1. Batch assembly, the Sequencer collects user transactions and organizes them into batches.
2. Batch authentication, once the batch assembly is complete, the Sequencer sends the batch data and its corresponding hash value to the DAC.
3. Data verification and storage, each DAC node independently verifies the batch data, and upon successful verification, the hash value is stored in each node's local database.
4. Signature generation, each DAC node generates a signature for the batch hash value, acknowledging the integrity and authenticity of the batch.
5. Communication with Ethereum, the Sequencer collects DAC members' signatures and the original batch hash value and submits them to the Ethereum network for verification.
6. Verification on Ethereum, the rollup contract on Ethereum verifies the submitted signatures based on the valid DAC member list and confirms that the batch hash value has received sufficient approval.
7. Final confirmation using ZKP, the aggregator prepares ZKP for the transactions in the batch and submits it to Ethereum. This proof confirms the validity of the approved transactions without revealing transaction details, thereby updating the state of the CKD chain on Ethereum.

The entire data flow process of Polygon CDK.

[The above is purely personal understanding (transcription), any errors are welcome for correction!]