Add support for ed25519 signature verification

EIPS/eip-ed25519.md

@@ -0,0 +1,43 @@
+## Preamble
+
+    EIP: <to be assigned>
+    Title: Add ed25519 precompiled contract
+    Author: Leszek Rychlewski <leszek@picostocks.com>
+    Type: Standard Track
+    Category: Core
+    Status: Draft
+    Created: 2017-07-04
+
+## Simple Summary
+Add support for ed25519 signature verification.
+
+## Abstract
+Current core version supports the ecrecover function for the secp256k1 elliptic curve cryptography as used in bitcoin. The proposal suggests adding support for the ed25519 elliptic curve as used in other crypto currencies (Monero, Decred, Chain core, Tezos, ESC). The addition will enable the processing of ed25519 Proof of Stake based block-chains within ETH smart contracts.
+
+## Motivation
+Within the discussion on the renamed [EIP 101](https://github.com/ethereum/EIPs/issues/28) a (prominent) [user](https://github.com/vbuterin) wrote:
+> I think that a precompile for ed25519 is reasonable; all the altcoins seem to be converging on it as an optimal curve so we should consider it. I implemented it in python here https://github.com/vbuterin/ed25519 but I haven't made any effort in making sure that it's standards-compliant yet, though at least in python it seems like its speed advantages over secp256k1 exist but are quite a bit smaller than advertised.
+
+ETH smart contracts offer the possibility to integrate information from external Proof of Work (PoW) block-chains (such as Bitcoin) if processing these block-chains requires only the use of an implemented hash (sha256) function. However most block-chains, other than ETH variants, lack the option to process information using smart contracts, so sending information for example from ETH to BTC is impossible without a third party. In addition the processing of transactions created within smart contracts poses and additional challenge as these do not have a transaction id.
+
+Creation of transactions between ETH and a second block-chain requires that the later has access to balances and states available in ETH. As a consequence the second block-chain would have to process all ETH messages or rely on trusted ETH nodes to obtained required information. It is unfeasible to expect from all nodes of the second block-chain to process also ETH, but the delegated Proof of Stake (dPoS) mechanism offers the possibility to delegate this work to a small subset of nodes.
+
+dPoS block-chains require the processing of signatures for block validation. dPoS block-chains focused on speed, such as [ESC](https://github.com/adshares/esc), benefit greatly from the batch-verification option available for ed25519. Right now processing of ed25519 signatures requires too much gas if implemented with ETH opcodes. A precompiled ed25519 function would enable the interoperability between ETH and fast dPoS block-chains and would offer the option to process large number of simple transactions with limited use of ETH recourses.
+
+## Specification
+The new function could be called edrecover with parameters as for the ecrecover function. The specifications are similar to those of the ecrecover function.
+
+## Rationale
+Because of the similarity between edrecover and ecrecover all design choices could be copied.
+
+## Backwards Compatibility
+The introduction of this function will break backwards compatibility for all contracts that use this function. A fork would be required.
+
+## Test Cases
+Test cases can be provided after a draft implementation is ready.
+
+## Implementation
+Test cases can be provided after a draft implementation is ready.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).