EIP-1108: Reduce alt bn128 gas costs #1108
Conversation
The EIP listed out the precompiles, but really this is about reducing all alt_bn128-related gas costs.
|
One note that came out of the original discussion was that it's unclear where the constant factor in the pairing check gas costs comes from. I tried to look in the implementation threads and the original discussions around EIP-197, but didn't find a clear context. The suggestion in #1088 was that the constant factor be eliminated; I have not included that particular change in this PR yet, but would be interested in additional context/thoughts on that front. In particular, perhaps the original authors of EIP-197, @vbuterin and @chriseth, could chime in on what motivated that constant factor in the first place, so we can see if it makes sense to reduce it further based on the new implementations. |
|
It's important to reduce the cost of the CALL opcode for precompiled smart contracts. |
|
The constant term corresponds to the "final exponentiation" that is done after the miller loop and whose runtime does not depend on the number of factors. Specific implementations should be tested in their runtime behaviour with regards to growing k. If they do not have this constant behaviour anymore, it can of course be dropped. |
|
@jbaylina while I don't necessarily disagree (I haven't looked into motivations behind the CALL cost), I think that's out of scope for this EIP, which is motivated by very specific implementation changes that have been benchmarked. Perhaps it would make sense to spin up a separate EIP regarding the CALL opcode? @chriseth Really appreciate your chiming in with that additional context. I'll see if the referenced benchmarks show signs of this constant factor or not. |
For some reason this got missed when turning into PR form.
|
@Shadowfiend it make sense... I added #1109 for that. |
| @@ -0,0 +1,50 @@ | |||
| --- | |||
| ``` | |||
There was a problem hiding this comment.
Please remove the backticks here to comply with the standard formatting.
| @@ -0,0 +1,50 @@ | |||
| --- | |||
| ``` | |||
| eip: <to be assigned> | |||
There was a problem hiding this comment.
Please rename to eip-1108.md and number 1108.
| ``` | ||
| eip: <to be assigned> | ||
| title: Reduce alt_bn128 precompile gas costs | ||
| author: Antonio Salazar Cardozo (@shadowfiend) <antonio@keep.network> |
There was a problem hiding this comment.
Please supply either github username or email, not both.
Shadowfiend
changed the title
Shadowfiend
changed the title
|
Looks like comments were addressed- can you give this another look @Arachnid? |
|
For reference, here are the original and Cloudflare-based final exponentiation functions to compare. For details on Parity's implementation, check the PR implementing the pairing check EIP. |
|
Good day, @Arachnid , @Shadowfiend I think we have missed an important part regarding the different computational costs on G1 and G2 (roughly 4 times from naive estimation based on element sizes). May be gas price should be changed from the flat value to something like flat fee + price per 64 bytes of data size to distinguish G1 from G2 ops? Sincerely, Alex |
|
Do you mean on ECMUL? The pairing check is already base + per-size multiplier. |
|
Yes, ECMUL and ECADD. ECADD is 2 division and 2 multiplications mainly in affine cords for G1. In addition I’ll check the benchmarks for some linear price approximations |
* Add draft of elliptic-curve gas cost reduction EIP * Add status and EIP dependencies * Lowercase preamble per observed practice * Tweak EIP title to reflect core cause for cost reduction The EIP listed out the precompiles, but really this is about reducing all alt_bn128-related gas costs. * Reduce constant factor in line with original EIP issue For some reason this got missed when turning into PR form. * Fix footnote formatting * Drop extraneous code fence * GitHub username only for EIP author line * Label alt_bn128 gas cost EIP as EIP 1108
|
Just as a side node - since EIP 1109 is unlikely to be ever accepted (in a form of new OPCODE at least), it may be more efficient (for end-users) to implement addition as manual point addition operation. |
|
@Shadowfiend has there been any movement on this recently...? Thanks. |
|
Absolutely! Some updates were recently added and it’s been added to EIP-1679, the meta-EIP for the forthcoming Istanbul hardfork, as a proposed EIP, thanks to @zac-williamson of @AztecProtocol. |
Originally discussed in #1088 , this draft EIP proposes a 10x reduction in the gas cost for the
ECADDprecompile, 20x forECMUL, and a 14x reduction in the per-pairing cost of the pairing check precompile alongside a modest 20% constant factor reduction, based on a recent switch to a significantly faster underlying implementation of these precompiles.Please let me know if there are any adjustments to style/structures that need to be made here… I didn't see any previous EIPs in this vein, so tried to fit it to the EIP-1 structure and the template as best I could.