Raise the gas costs of opcodes and precompiles that involve hash functions.
2 Likes
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
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
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.
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
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.
As it may be early to adopt this EIP on L1 (many dependencies), I propose to adopt it on ZK-Rollups (I tried to link my PR on RIPs repository but couldnât).
This enables ZK-Rollups to account for the mispricing of non-ZK friendly hash operations in a standardized way.
How much more expensive should keccak be on, for example, Scroll, Kakarot or Polygon ZK-EVM (as well as other ZK-EVMs)? Can we agree on a number, or should each ZK-EVM perform its own pricing?
1 Like
One thing that should also be considered is the adjustment of the WORD_COST constants to be based on the real cost instead of it being a per-32 byte cost.
For example, SHA256 cost is flat from 0-55 bytes, then increments linearly in chunks of 64 bytes. Keccak has a similar scheme with even larger chunk sizes that still have to be paid even when hashing only small amount of data.
See EIP-7797: Double speed for hash_tree_root for a diagram on SHA256 internals.
1 Like