Are custom polygon CDK chains fully EVM compatible?

Yes, CDK chains are fully EVM equivalent. You can find the supported opcodes in the documentation linked here: Etrog Upgrade Documentation and CDK Documentation. There is no difference in the output of global variables like block.timestamp and block.number—hence, they are equivalent.

Custom Polygon CDK chains are designed to be EVM-compatible, enabling developers to deploy Ethereum-based smart contracts and interact with them using familiar tools like MetaMask, Hardhat, and Foundry. However, while they aim to provide full EVM compatibility, some differences can arise due to custom configurations, execution environments, and infrastructure choices. This guide explores opcode support, global variable behavior, and potential compatibility differences when working with custom Polygon CDK chains.

Polygon CDK allows developers to build custom Layer 2 (L2) chains with modular components. These chains inherit many of Ethereum's core functionalities, but since they are sovereign rollups or sidechains, they may introduce minor differences in execution logic.

A blockchain is considered fully EVM-compatible if:

• It supports all Ethereum opcodes without modification - bla bla bla...
• It processes transactions identically to Ethereum, including gas calculations and state changes.
• Smart contracts deployed on Ethereum can run unmodified on the custom chain.

Polygon CDK-based chains are designed to meet these criteria, but certain configurations can introduce deviations.

Q1: Are All Ethereum Opcodes Supported?

Polygon CDK chains generally support all EVM opcodes, meaning you can execute Solidity and Vyper smart contracts without modification. However, the actual execution behavior depends on the chosen execution layer (e.g., Polygon zkEVM, Optimistic Rollups, or a custom-built execution environment).

For example:

• zkEVM-based CDK chains might handle certain opcodes differently due to zero-knowledge proof constraints.
• Optimistic rollups process transactions off-chain and submit batched proofs, which can introduce subtle execution differences.

To verify opcode compatibility, you can check the Ethereum Yellow Paper (EVM Opcodes) against the Polygon CDK chain’s implementation.

If you suspect an opcode might be unsupported or behave differently, you can test it using a simple Solidity contract.

Example: Checking support for CREATE2 and SELFDESTRUCT

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract OpcodeTest {
    event ContractCreated(address newContract);
    
    function testCreate2(bytes32 salt, bytes memory bytecode) public {
        address newContract;
        assembly {
            newContract := create2(0, add(bytecode, 0x20), mload(bytecode), salt)
        }
        emit ContractCreated(newContract);
    }

    function testSelfDestruct(address payable recipient) public {
        selfdestruct(recipient);
    }
}

Deploying this contract on both Ethereum and a Polygon CDK chain can help determine if these opcodes behave as expected.

Q2. What Are the Differences in Global Variables (block.timestamp, block.number, etc.)

block.timestamp

block.timestamp generally behaves the same way as on Ethereum, reflecting the time of the latest block. However, some Polygon CDK chains may:

• Use faster or slower block times, affecting timestamp precision.
• Adjust timestamps due to batch processing in rollup-based CDK chains.

For example, if the L2 chain batches transactions before submitting them to Ethereum, the timestamp might reflect the batch processing time instead of the original transaction submission time.

Testing block.timestamp Behavior

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract TimestampTest {
    event TimestampLogged(uint256 blockTimestamp);

    function logTimestamp() public {
        emit TimestampLogged(block.timestamp);
    }
}

Deploying this contract and comparing results on Ethereum and Polygon CDK chains can reveal discrepancies.

block.number

The block number represents the height of the blockchain and generally increments as expected. However:

• On rollup-based CDK chains, block.number may increment in L2 context and differ from L1 Ethereum's block height.
• In some cases, batch submission to Ethereum might introduce gaps, meaning an L2 transaction could be recorded at a different block number than anticipated.

Testing block.number Behavior

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract BlockNumberTest {
    event BlockNumberLogged(uint256 blockNumber);

    function logBlockNumber() public {
        emit BlockNumberLogged(block.number);
    }
}

Running this contract on Ethereum and a Polygon CDK chain can highlight any inconsistencies.

Q3. What are the Key Differences Between Polygon CDK Chains and Ethereum?

So... To make a long story short:

Custom Polygon CDK chains are largely EVM-compatible, meaning most Ethereum-based smart contracts should work without modifications. However, minor differences exist depending on whether the chain is zkEVM-based, an Optimistic Rollup, or a sidechain.

Key points to remember:

• Opcodes are mostly supported, but zero-knowledge rollups may handle some differently.
• block.timestamp and block.number may behave slightly differently, especially on rollup-based CDK chains.
• Gas fees and finality differ, depending on the chain's infrastructure.

For full compatibility testing, deploy simple contracts to compare execution results between Ethereum and the Polygon CDK chain. If you need more specific guidance, Polygon’s official documentation and community forums are the best places to get updates.