zkEVM Development Services

The Polygon ZK EVM represents a revolutionary approach to scaling Ethereum, allowing the use of standard Ethereum smart contract code (EVM bytecode) in a new, more efficient environment. To do this, they utilize zkASM.

zkASM transforms smart contract instructions written in Solidity for Ethereum into low-level code that is optimized for generating zk-SNARKs. This includes converting smart contract operations and logic into sequences of simpler instructions.

This is similar to a translator that helps two people with different languages communicate with each other. As a result, the Polygon ZK EVM allows the use of existing Ethereum smart contracts, while offering the benefits of the new technology, such as higher processing speed and increased privacy.

One of the important criteria for both blockchain development and smart contract developers is the simplicity of development, testing, contract deployment, and the use of modern development tools.

Since the Polygon zkEVM is based on the Ethereum EVM, the development process is almost identical to developing on the Ethereum EVM blockchain. It is also possible to use popular tools such as Remix, Foundry, and Hardhat without any issues.

There are some minor differences between EVM and ZkEVM:

• The list includes supported EIPs, operations, and additional changes made to create the zkEVM. These differences do not affect the developer experience of the zkEVM compared to the EVM. Gas optimization techniques, interaction with libraries such as Web3.js and Ethers.js, and contract deployment work seamlessly on the zkEVM without any overhead.
• The zkEVM does not clear the storage when a contract is deployed to an address due to the specification of the zkEVM state tree. (This means that in the zkEVM, when a new contract is deployed to an address where a contract already existed, the old data stored at that address is not automatically deleted. In the traditional EVM, when a contract is deployed to an address where a contract already existed, the old data is deleted. However, in the zkEVM, due to the specification of its state tree, this does not happen, and the old data remains in the storage.)
• JUMPDEST is allowed within PUSH bytecodes to avoid runtime bytecode analysis. (This means that in the zkEVM, the JUMPDEST opcode is permitted within the data being passed by PUSH commands. In the standard EVM, JUMPDEST is used to mark the destination of a JUMP. Typically, for security, EVM contracts undergo bytecode analysis at runtime to ensure the validity of JUMPDEST locations. By allowing JUMPDEST within PUSH data, the zkEVM simplifies the execution process, as real-time bytecode analysis to locate valid JUMPDESTs is no longer required. This accelerates contract execution and reduces complexity.)
• The zkEVM implements EIP-3541 from the London hard fork. (This indicates that the zkEVM includes the implementation of the Ethereum Improvement Proposal EIP-3541, which was introduced during the Ethereum network upgrade known as the London hard fork. EIP-3541 establishes new rules for smart contract structure, prohibiting the deployment of contracts starting with a specific byte prefix (0xEF), preventing potential conflicts and compatibility issues with future Ethereum changes.)
• EIP-2718, which defines a typed transaction envelope, is not supported. (EIP-2718 introduces an innovation in Ethereum transaction standards, bringing the concept of an envelope for different transaction types. This allows the Ethereum network to utilize multiple new transaction types, each with unique fields and processing logic. However, in the Polygon zkEVM, as of the latest information, this standard is not supported, meaning developers and users cannot take advantage of the enhanced capabilities offered by typed transactions within this platform. This may impact compatibility with some new features or contracts developed for the Ethereum mainnet.)
• EIP-2930, which defines a transaction type with optional access lists, is not supported. (EIP-2930 is an Ethereum Improvement Proposal that introduces a new transaction type containing optional access lists. These lists pre-specify which accounts and contract storage the transaction will access, allowing validators to know in advance which states will be affected. This improves efficiency and helps reduce gas costs by minimizing the need for re-computations. The lack of support for EIP-2930 in the zkEVM means that users and developers cannot leverage this functionality to optimize their transactions on the Polygon network.)

Blockchain Efficiency Strategy

The first strategy involves deploying a consensus contract that incentivizes the most efficient aggregators to participate in the proof generation process.

The second strategy is to perform all computations off-chain, storing only the necessary data and zk-proofs in the blockchain.

The implementation of a smart contract bridge, such as the UTXO-based accounting method.

The use of specialized cryptographic primitives in the zkProver to accelerate computations and minimize proof sizes, which can be achieved through:

Running a special zero-disclosure assembly language (zkASM) to interpret bytecodes.

Utilizing zero-disclosure tools like zk-STARK for proof purposes; these proofs are executed very quickly, although they are larger in size.

Instead of publishing large zk-STARK proofs as validity proofs, zk-SNARK is used to verify the correctness of the zk-STARK proofs. These zk-SNARKs, in turn, are published as state transition validity proofs. This helps to reduce gas costs from 5 million to 350 thousand.

Pros and Cons of Polygon’s zkEVM:

Pros:

• High level of security (comparable to L1)
• Smart contracts are almost fully compatible, except for some precompiled contracts
• Can use tools like Remix, Foundry, Hardhat for contract development without issues
• No need to configure a stack for protocol development
• Standard Web3 API (also supports standard Ethereum wallets like MetaMask)
• Account abstraction supported through ERC-4337
• Fast transaction processing – transactions on L2 are confirmed immediately and on L1 after a short period (around 30 minutes)
• Low transaction fees
• Small zkSNARK size in L1 to optimize user costs

Cons:

• Some inconvenience in contract development due to the need to check used libraries like OpenZeppelin for compatibility with non-working precompiled contracts
• Despite significant improvements in scalability, very high loads may still present scalability challenges
• As a relatively new technology, it may contain unresolved issues or uncertainties

Conclusion

Polygon’s zkEVM represents a significant advancement in blockchain technology, combining Ethereum compatibility and the benefits of zero-knowledge proofs. This opens new horizons for blockchain-based businesses, offering high performance, scalability, security, and cost-effectiveness. Developing for this blockchain is almost as easy as on a regular EVM blockchain. The scalability it provides can help reduce the load on Ethereum and lower user gas costs. Developers are also planning to implement the EIP-4844 (Dencun) update in the near future, which will further reduce gas prices in the Polygon zkEVM mainnet.