EIP-7667: Raise gas costs of hash functions

EIPs Core EIPs
1

Raise the gas costs of opcodes and precompiles that involve hash functions.

2 Likes
2

Since then, however, there has emerged another equally important execution substrate that the EVM is executed on: zero knowledge proof (ZK-SNARK) systems. By that standard, these opcodes and precompiles are very underpriced relative to other operations.

I don’t see why mainnet gas should be increased to accommodate zk-snarks. I do not see why they are equally important.

3 Likes
3

Because in five years every chain, including Ethereum L1, will be ZK-SNARK verified. Making the Ethereum L1 ZK-SNARKed is a key part of the long-term vision of making “full” Ethereum verification be mobile-phone friendly and something that gets done by default in every Ethereum client, including mobile and browser (as opposed to just trusting Infura).

Now, we could simply say, we’ll solve the problem with brute force and stack together 20x more prover boxes, but (i) that’s a centralization vulnerability, and (ii) if that is an option, why waste 20x more prover boxes on maintaining an artificially low KECCAK gas price instead of using that capacity on increasing the L1 gaslimit by 20x?

2 Likes
4

Shouldn’t we delay an L1 gas increase until L1 is impacted? The 2x increase you propose now might not even be enough then. A better solution than snarks may come along before then, bringing its own set of gas adjustments. This gas adjustment is so easy to implement that it can’t even be considered a step toward snarks.

5

Shouldn’t we delay an L1 gas increase until L1 is impacted?

The issue with this approach is that there is a cross-dependency: people won’t even try to fully build the tools to properly snark-verify L1 until they are sure that there aren’t corner cases that make the entire project unviable in the worst case. And ZK-EVMs are already at a high level of maturity, to the point where they are being used in mainstream rollups. You can argue that there is no point in doing this before Verkle, because keccak MPT hashing is even more expensive than in-EVM hashing, but if we want L1 SNARK-friendliness to come at Verkle time, we need to start preparing for that now.

The 2x increase you propose now might not even be enough then

The increase I propose is 10x though?

And I don’t think there is a significant probability of “a better solution than snarks”; snarks are pretty clearly the endgame of scalable and decentralized blockchains and this has been the mainstream opinion for years now.

2 Likes
6

Do we need the same for elliptic curve precompiles?

This affects zkBridges, L3, verifying KZG in L2, zkCoprocessors on L2, …

On the other hand, there are techniques like Goblin Plonk, CycleFold and Zero Knowledge Proofs of Elliptic Curve Inner Products from Principal Divisors and Weil Reciprocity that can accelerate EC in ZK.

But the first 2 need a cycle of elliptic curves, which exist for BN254 but not for BLS12-381.