DCIPs/EIPS/eip-1108.md

---
eip: 1108
title: Reduce alt_bn128 precompile gas costs
author: Antonio Salazar Cardozo (@shadowfiend), Zachary Williamson (@zac-williamson)
discussions-to: https://ethereum-magicians.org/t/eip-1108-reduce-alt-bn128-precompile-gas-costs/3206
status: Final
type: Standards Track
category: Core
created: 2018-05-21
requires: 196, 197
---

## Simple Summary  

The elliptic curve arithmetic precompiles are currently overpriced. Re-pricing the precompiles would greatly assist a number of privacy solutions and scaling solutions on Ethereum. 

## Abstract

Changes in 2018 to the underlying library used by the official Go reference
implementation led to significant performance gains for the `ECADD`, `ECMUL`,
and pairing check precompiled contracts on the `alt_bn128` elliptic curve.

In the Parity client, field operations used by the precompile algorithms were optimized in 2018, 
and recent changes to the pairing algorithm used by the `bn` crate have brought considerable speedups.

Faster operations on Ethereum clients should be reflected in reduced gas costs.

## Motivation

Recently, the underlying library used by the [official Go reference
implementation](https://github.com/ethereum/go-ethereum) to implement the
`ECADD` (at address `0x06`), `ECMUL` (at address `0x07`), and pairing check (at
address `0x08`) precompiled contracts was shifted to [Cloudflare's bn256
library](https://github.com/cloudflare/bn256). Based on the [initial PR that
introduced this change](https://github.com/ethereum/go-ethereum/pull/16203),
and corroborated in [a later
note](https://github.com/ethereum/go-ethereum/pull/16301#issuecomment-372687543),
the computational cost of `ECADD`, `ECMUL`, and pairing checks (excepting the
constant) has dropped roughly an order of magnitude across the board.

Also, optimizations in the bn library [in 2018](https://github.com/paritytech/bn/pull/9) and [2019](https://github.com/paritytech/bn/pull/14)
used by the [Parity client](https://github.com/paritytech/parity-ethereum) led to a 
significant performance boost we 
[benchmarked](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53) 
and compared against the [previous 
results](https://gist.github.com/pdyraga/4649b74436940a01e8221d85e80bfeef).  


## Specification

Following is a table with the current gas cost and new gas cost:

| Contract      | Address   | Current Gas Cost               | Updated Gas Cost    |
| ------------- | --------- | -----------------------------  | ------------------- |
| `ECADD`       | `0x06`    | 500<sup>[1]</sup>              | 150                 |
| `ECMUL`       | `0x07`    | 40 000<sup>[1]</sup>           | 6 000               |
| Pairing check | `0x08`    | 80 000 * k + 100 000<sup>[2]</sup>| 34 000 * k + 45 000    |

The gas costs for `ECADD` and `ECMUL` are updates to the costs listed in
EIP-196, while the gas costs for the pairing check are updates to the cost
listed in EIP-197. Updated gas costs have been adjusted to the less performant 
client which is Parity, according to benchmarks<sup>[3]</sup>.

To come up with these updates gas costs, the performance of the `ecrecover` precompile
was measured at 116 microseconds per `ecrecover` invocation. Assuming the `ecrecover`
gas price is fair at 3,000 gas, we get a price of 25.86 gas per microsecond of a precompile
algorithm's runtime. With this in mind, the pairing precompile took 3,037 microseconds to
compute 1 pairing, and 14,663 microseconds to compute 10 pairings. From this, the pairing
algorithm has a fixed 'base' run-time of 1,745 microseconds, plus 1,292 microseconds per
pairing. We can split the run-time into 'fixed cost' and 'linear cost per pairing'
components because of the structure of the algorithm.

Thus using a 'fair' price of 25.86 gas per microsecond, we get a gas formula of
~`35,000 * k + 45,000` gas, where `k` is the number of pairings being computed. [4]

[1]- Per [EIP-196](./eip-196.md).

[2]- Per [EIP-197](./eip-197.md).

[3]- [Parity benchmarks.](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53)

[4]- [PR comment clarifying gas cost math](https://github.com/ethereum/EIPs/pull/1987#discussion_r280977066).

## Rationale  

### Existing protocols would benefit immensely from cheaper elliptic curve cryptography

Fast elliptic curve cryptography is a keystone of a growing number of protocols built on top of Ethereum. To list a few:  

* [The AZTEC protocol](https://github.com/AztecProtocol/AZTEC) utilizes the elliptic curve precompiles to construct private tokens, with zero-knowledge transaction logic, via the [ERC-1723](https://github.com/ethereum/EIPs/issues/1723) and [ERC-1724](https://github.com/ethereum/EIPs/issues/1724) standard.  
* [Matter Labs](https://github.com/matter-labs/matter-network) utilizes the precompiles to implement Ignis, a scaling solution with a throughput of 500txns per second  
* [Rollup](https://github.com/rollup/rollup) utilizes the precompiles to create L2 scaling solutions, where the correctness of transactions is guaranteed by main-net, without an additional consensus layer  
* [ZEther](https://crypto.stanford.edu/~buenz/papers/zether.pdf) uses precompiles `ECADD` and `ECMUL` to construct confidential transactions  

These are all technologies that have been, or are in the process of being, deployed to main-net. There protocols would all benefit from reducing the gas cost of the precompiles.  

To give a concrete example, it currently costs `820,000` gas to validate the cryptography in a typical AZTEC confidential transaction. If the gas schedule for the precompiles correctly reflected their load on the Ethereum network, this cost would be `197,000` gas. This significantly increases the potential use cases for private assets on Ethereum. AZTEC is planning to deploy several cryptographic protocols Ethereum, but these are at the limits of what is practical given the current precompile costs:  

* Confidential weighted voting  
* Partial-order filling over encrypted orders, for private decentralized exchanges  
* Anonymous identity sharing proofs (e.g. proving you are on a whitelist, without revealing who you are)  
* Many-to-one payments and one-to-many confidential payments, as encrypted communication channels between main-net and L2 applications  

For zk-SNARK based protocols on Ethereum, EIP-1108 will not only reduce the gas costs of verifying zk-SNARKs substantially, but can also aid in [batching together multiple zk-SNARK proofs](https://github.com/matter-labs/Groth16BatchVerifier). This is also a technique that can be used to split up monolithic zk-SNARK circuits into a batch of zk-SNARKs with smaller individual circuit sizes, which makes zk-SNARKs both easier to construct and deploy.

ZEther transactions currently cost ~`6,000,000` gas. This EIP would reduce this to ~`1,000,000` gas, which makes the protocol more practical.  

To summarise, there are several protocols that currently exist on main-net, that would benefit immensely from this EIP. Elliptic curve cryptography can provide valuable solutions for Ethereum, such as scaling and privacy, and the scope and scale of these solutions can be increased if the gas costs for the `bn128` precompiles accurately reflects their computational load on the network.

### Cheaper elliptic curve cryptography can be used to trade storage for computation  

Solutions such as Rollup and Ignis can be used to batch groups of individual transactions into a zk-SNARK proof, with the on-chain state being represented by a small Merkle root, instead of multiple account balances.  

If zk-SNARK verification costs are decreased, these solutions can be deployed for a wider range of use cases and more Rollup-style transactions can be processed per block.

### Parity and Geth already have fast algorithms that justify reduced gas costs  

This EIP does not require Parity or Geth to deploy new cryptographic libraries, as fast bn128 algorithms have already been integrated into these clients. This goal of proposing this EIP for Istanbul, is to supplement [EIP-1829](./eip-1829.md) (arithmetic over generic elliptic curves), providing an immediate solution to the pressing problem of expensive cryptography, while more advanced solutions are developed, defined and deployed.


## Test Cases  

As no underlying algorithms are being changed, there are no additional test cases to specify.  

## Implementation  

Both the Parity and Geth clients have already implemented cryptographic libraries that are fast enough to justify reducing the precompile gas costs. As a reference, here are a list of elliptic curve libraries, in `C++`, `golang` and `rust`, that support the `bn128` curve, and have run-times that are equal to or faster than the Parity benchmarks.  

* [Parity bn crate (rust)](https://github.com/paritytech/bn)  
* [Geth bn256 library (golang)](https://github.com/ethereum/go-ethereum/tree/master/crypto/bn256/cloudflare)  
* [MCL, a portable C++ pairing library](https://github.com/herumi/mcl)  
* [Libff, a C++ pairing library used in many zk-SNARK libraries](https://github.com/scipr-lab/libff)

## Additional References

@vbuterin independently proposed a similar reduction after this EIP was originally created, with similar rationale, as [ethereum/EIPs#1187](https://github.com/ethereum/EIPs/issues/1187).

## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).