Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gas cost reduction for ECADD, ECMUL and ECPAIRING #1187

Closed
vbuterin opened this issue Jun 29, 2018 · 2 comments
Closed

Gas cost reduction for ECADD, ECMUL and ECPAIRING #1187

vbuterin opened this issue Jun 29, 2018 · 2 comments

Comments

@vbuterin
Copy link
Contributor

Specification

If block.number >= CONSTANTINOPLE_FORK_BLKNUM, the gas cost for the following precompiles is reduced:

  • ECMUL: reduced from 40000 to 10000
  • GPAIRINGBASE: reduced from 100000 to 40000
  • GPAIRINGPERPOINT: reduced from 80000 to 40000

Motivation

Currently, operations using the alt_bn128 curve are much more expensive than secp256k1 signatures: an ECRECOVER implicitly contains 3 ECMUL operations, but ECMUL is ~13 times more expensive than ECRECOVER. There is nothing fundamentally mathematically more complex about the alt_bn128 curve that justifies this; the original numbers were calculated from implementations that existed at the time, and it just so happened that the secp256k1 implementations were much better optimized than those for alt_bn128. Recently, geth introduced a new library that allows it to do elliptic curve math faster, so a recomputation of the gas costs, to reduce the currently very high gas cost of applications using ring signatures, BLS signatures and ZK SNARKs, is worth considering.

@Shadowfiend
Copy link
Contributor

This is currently proposed in EIP-1108, though with different numbers (generally smaller by a factor of 10 rather than a factor of ~2 based on the benchmarks posted by geth).

Not sure how the EIP process proceeds in these cases; I'm happy to update EIP-1108 with the numbers from here if they have a better basis, and the motivation here gives more historical context that can also be included in 1108. But if the more common practice is to supersede the existing EIP, I'm also down to do whatever is needed for that.

@axic
Copy link
Member

axic commented Jul 5, 2019

Given a similar proposal is EIP-1108 as @Shadowfiend mentioned is being considered for Istanbul and it also has a link to this issue, I think it is safe to close this.

@axic axic closed this as completed Jul 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@Shadowfiend @axic @vbuterin and others