Merge pull request #7 from ethereum/master

update

EIPS/eip-1.md

@@ -23,13 +23,13 @@ For Ethereum implementers, EIPs are a convenient way to track the progress of th
 
 There are three types of EIP:
 
-- A **Standard Track EIP** describes any change that affects most or all Ethereum implementations, such as a change to the the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories. Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the [formal specification].
+- A **Standard Track EIP** describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories. Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the [formal specification].
   - **Core** - improvements requiring a consensus fork (e.g. [EIP5], [EIP101]), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP90], and the miner/node strategy changes 2, 3, and 4 of [EIP86]).
   - **Networking** - includes improvements around [devp2p] ([EIP8]) and [Light Ethereum Subprotocol], as well as proposed improvements to network protocol specifications of [whisper] and [swarm].
   - **Interface** - includes improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names ([EIP6]) and [contract ABIs]. The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
   - **ERC** - application-level standards and conventions, including contract standards such as token standards ([ERC20]), name registries ([ERC26], [ERC137]), URI schemes ([ERC67]), library/package formats ([EIP82]), and wallet formats ([EIP75], [EIP85]).
-- An **Informational EIP** describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.
 - A **Meta EIP** describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.
+- An **Informational EIP** describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.
 
 It is highly recommended that a single EIP contain a single key proposal or new idea. The more focused the EIP, the more successful it tends to be. A change to one client doesn't require an EIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.
 
@@ -39,7 +39,7 @@ An EIP must meet certain minimum criteria. It must be a clear and complete descr
 
 Parties involved in the process are you, the champion or *EIP author*, the [*EIP editors*](#eip-editors), and the [*Ethereum Core Developers*](https://github.com/ethereum/pm).
 
-:warning: Before you begin, vet your idea, this will save you time. Ask the Ethereum community first if an idea is original to avoid wasting time on something that will be be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used. Examples of appropriate public forums to gauge interest around your EIP include [the Ethereum subreddit], [the Issues section of this repository], and [one of the Ethereum Gitter chat rooms]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your EIP.
+:warning: Before you begin, vet your idea, this will save you time. Ask the Ethereum community first if an idea is original to avoid wasting time on something that will be rejected based on prior research (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used. Examples of appropriate public forums to gauge interest around your EIP include [the Ethereum subreddit], [the Issues section of this repository], and [one of the Ethereum Gitter chat rooms]. In particular, [the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your EIP.
 
 Your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful EIP will move along:
 
@@ -89,7 +89,7 @@ Each EIP should have the following parts:
 ## EIP Formats and Templates
 
 EIPs should be written in [markdown] format.
-Image files should be included in a subdirectory of the `assets` folder for that EIP as follow: `assets/eip-X` (for eip **X**). When linking to an image in the EIP, use relative links such as `../assets/eip-X/image.png`.
+Image files should be included in a subdirectory of the `assets` folder for that EIP as follows: `assets/eip-X` (for eip **X**). When linking to an image in the EIP, use relative links such as `../assets/eip-X/image.png`.
 
 ## EIP Header Preamble
 
@@ -169,7 +169,7 @@ The `created` header records the date that the EIP was assigned a number. Both h
 
 #### `updated` header
 
-The `updated` header records the date(s) when the EIP was updated with "substantional" changes. This header is only valid for EIPs of Draft and Active status.
+The `updated` header records the date(s) when the EIP was updated with "substantial" changes. This header is only valid for EIPs of Draft and Active status.
 
 #### `requires` header
 

EIPS/eip-1108.md

@@ -1,22 +1,27 @@
 ---
 eip: 1108
 title: Reduce alt_bn128 precompile gas costs
-author: Antonio Salazar Cardozo (@shadowfiend)
+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: Draft
 type: Standards Track
 category: Core
 created: 2018-05-21
 requires: 196, 197
 ---
 
-## Short Description
+## Simple Summary  
 
-Recent changes to the underlying library used by the official Go reference
+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.
 
-What is more, the performance boost for those operations can be also observed 
-for Parity client. 
+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.
 
@@ -33,12 +38,13 @@ 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, [optimisations in the bn library](https://github.com/paritytech/bn/pull/9) 
+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/pdyraga/4649b74436940a01e8221d85e80bfeef) 
+[benchmarked](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53) 
 and compared against the [previous 
-results](https://github.com/ethereum/benchmarking/blob/master/constantinople/analysis2.md). 
+results](https://gist.github.com/pdyraga/4649b74436940a01e8221d85e80bfeef).  
+
 
 ## Specification
 
@@ -48,15 +54,65 @@ Following is a table with the current gas cost and new 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>| 28 300 * k + 35 450    |
+| 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>.
+client which is Parity, according to benchmarks<sup>[3]</sup>. The updated gas costs are scaled relative to the `ecrecover` precompile. i.e. in the benchmark, `ecrecover` ran in 116 microseconds. If we consider 3,000 gas the fair price for `ecrecover`, we can obtain a metric how much gas should be charged per microsecond of an algorithm's runtime, and use that to price the elliptic curve precompiles.
 
 [1]- Per [EIP-196](https://github.com/ethereum/EIPs/blob/984cf5de90bbf5fbe7e49be227b0c2f9567e661e/EIPS/eip-196.md#gas-costs).
 
 [2]- Per [EIP-197](https://github.com/ethereum/EIPs/blob/df132cd37efb3986f9cd3ef4922b15a767d2c54a/EIPS/eip-197.md#specification).
 
-[3]- [Parity benchmarks.](https://gist.github.com/pdyraga/4649b74436940a01e8221d85e80bfeef)
+[3]- [Parity benchmarks.](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53)
+
+## 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 [ERC1723](https://github.com/ethereum/EIPs/issues/1723) and [ERC1724](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 gauranteed 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](https://github.com/ethereum/EIPs/blob/master/EIPS/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)