The final Polygon zkEVM testnet, which launched last year, has seen a surge of developers and users eager to experience the future of Ethereum scaling. The years-long technicalachievements to get to this point have been enormous. Researchers working on zero-knowledge (ZK) to scale Ethereum have had to answer and address a bevy of design questions at every turn.One interesting question that arises for all zkEVMs: how do you price gas? In the Ethereum Virtual Machine (EVM), gas keeps the network secure by setting an economic fee for every computation. Malicious behaviors, like Denial of Service (DoS) attacks, are muted by setting a price to execute transactions. Gas limits define the total number of computational steps a transaction can execute. So why is figuring out how to price gas in zkEVMs an interesting problem? Because gas is supposed to reflect resource consumption for nodes (bandwidth/storage/compute), but when generating zkEVM proofs, some EVM opcodes are relatively more expensive to prove than to re-execute on a CPU.

Deep dive into Polygon zkEVM opcode compatibility with Polygon Foundation co-founder Jordi Baylina.

In other words, some computations that require low gas fees in the EVM might become prohibitively expensive and slow down the network when proved in zkEVM. What does this mean? Solidity, the programming language for the EVM, is compiled into opcodes, which run on the blockchain. Each opcode does something simple, and each requires gas to execute. To translate gas pricing into zkEVM for these opcodes, there are three options, each of which requires different considerations:

1. Keep the gas schedule the same as in the EVM
2. Reprice opcodes
3. Keep the gas schedule, but also introduce a mechanism for DoS mitigation

We’ll walk through each option and explain the best design choice for Polygon zkEVM.

Keep the gas schedule? Or reprice opcodes?

Keeping the regular EVM gas fee schedule for Polygon zkEVM seems attractive enough, because existing contract behavior in the EVM would remain unchanged. This is ideal for developers who can easily and seamlessly deploy Ethereum dApps in a zkEVM environment, and a huge upside for EVM-equivalency. But maintaining gas fees without modification actually introduces a new vector for potential DDoS attacks. There are computations in the EVM which require low gas fees, but which in the context of a zkEVM become very expensive to prove. Cram enough opcodes into one block that are low-cost in EVM, but high-cost in zkEVM, and the network can experience serious lag. An example? Keccak hashes are expensive to prove in a zkEVM environment. Filling a block with the opcode “EXTCODESIZE” would only cost 100 gas, but cause a type-1 zkEVM to perform an unwieldy number of Keccak hashes–leading to a potential DoS vector.So a 1:1 pricing scheme looks like it might cause some trouble.

Why not reprice opcodes, then, in order to reflect the proving cost in a zkEVM? (This is option two above.)The problem is that some contracts rely on the current gas schedule to function as intended – opcodes like “GASLEFT,” for example, or “CALLSTIPEND.” Repricing opcodes for Polygon zkEVM might actually introduce unexpected behavior into dApps, causing developers unnecessary headaches. So that leads us to the best option for Polygon zkEVM…

Keep the gas schedule, but also introduce DoS mitigation

With its fast prover, Polygon zkEVM is able to keep the EVM gas schedule, but also introduces a mechanism by which DDoS attacks can be mitigated. In other words, contract functionality can be preserved without sacrificing the security and reliability of the network. How does Polygon zkEVM do it? First, the gas schedule remains the same. Opcodes are priced the same in Polygon zkEVM as they are in the EVM. Second, and most importantly, Polygon zkEVM introduces quotas to identify pathological transactions, like filling an entire block with EXTCODESIZE. Think of it like an extra security reflex. Only a certain number of Keccak hashes can be included in a block. Polygon zkEVM scans for malicious blocks that breach this quota, helping to ensure that expensive and network-slowing spam does not occur.Due to the extremely fast Polygon zkEVM prover, the differences in compute cost between the L1 gas schedule and actual resource consumption in Polygon zkEVM remains marginal.It’s the best of all worlds: seamless design integration coupled with a mechanism to prevent spam.

* * *

Have a case of ZK fever? Want to learn more about this industry-shattering technology? We’ve got you. Tune into our blog for the latest updates or follow Polygon Labs’ ZK-specific Twitter handle. This blog also expands on a thread originally written by Polygon Foundation co-founder, Brendan Farmer. Website | Twitter | Developer Twitter | Blog | Telegram | Reddit | Discord | Instagram | Facebook | LinkedIn