Add support for ed25519 signature verification #665

ghost · 2017-07-04T16:33:27Z

request for precompiled contract for ed25519 signature verification.

kylerchin · 2017-07-27T01:07:04Z

👍 Someone please check this out.

kylerchin

awesome!!!!!

pirapira

I made small comments. I think a tentative address and a tentative gas cost would be necessary for implementation and test cases.

pirapira · 2017-12-13T14:47:40Z

EIPS/eip-ed25519.md

+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.


Something like "The introduction of this precompiled contract will break ... that calls the address of the precompiled contract" would fit better with the usual nomenclature.

pirapira · 2017-12-13T14:48:05Z

EIPS/eip-ed25519.md

@@ -0,0 +1,43 @@
+## Preamble
+
+    EIP: <to be assigned>


Please use 665, and move this file to EIPS/665.md

pirapira · 2017-12-13T14:48:38Z

EIPS/eip-ed25519.md

+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.


Please specify the address of the precompiled contract, even if tentatively.

Please also specify a gas cost, even if tentatively.

pirapira · 2017-12-13T14:52:45Z

EIPS/eip-ed25519.md

+
+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.


"large number" should be "a large number" says Grammarly, and I suspect so.

pirapira · 2017-12-13T14:55:31Z

This is not mandatory, but if you list available libraries in commonly used languages, that would be more inviting.

oberstet · 2018-03-22T11:43:10Z

Please make it happen .. Ed25519 has a lot of advantages (from the pure crypto/algo side, and also from real-world implementations, as there is a high-quality, side-channel resistant implementation: NaCl) and has gained wide usage in OSS very quickly: https://ianix.com/pub/ed25519-deployment.html

oberstet · 2018-03-22T11:45:10Z

FWIW, here is a 50 pts bounty on SO related to this;) three days left ..

https://ethereum.stackexchange.com/questions/42771/ed25519-in-smart-contracts/

oberstet · 2018-03-25T17:05:19Z

@pirapira

NaCl Crypto Libraries (which contains Ed25519) can be found here: https://ianix.com/pub/ed25519-deployment.html
Test vectors for Ed25519 can be found here: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6

As to the motivation for this: me, I am more looking to integrate Ed25519 based, existing, off-chain systems with Ethereum. Here, a contract might want to check a Ed25519 signed piece of data submitted to the Ethereum transaction. Eg the current block number signed with Ed25519. That proves to the contract, that the sender is in possession of both the Ethereum private key and the Ed25518 private key, and hence the contract will accept an association between both. This again can be the root anchor for various powerful applications, as now a potentially crypto holding key owner has proven to be in control of some external off-chain system. Eg a DNS server, a DNS domain, a cluster node, ...

oberstet · 2018-03-25T19:01:10Z

@picostocks @pirapira I filed a follow up PR here #949 that is supposed to be more complete, and take up the review feedback. Please let me know what you see missing, what needs to be expanded on.

Arachnid · 2018-03-27T15:07:07Z

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

Frontmatter is now contained between lines with only a triple dash ('---')
Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

oberstet · 2018-04-06T12:39:37Z

I think this can be closed as EIP 665 is in master https://github.com/ethereum/EIPs/blob/master/EIPS/eip-665.md

a geth PR is here btw ethereum/go-ethereum#16453

Add support for ed25519 signature verification

3b0f96f

ghost mentioned this pull request Jul 4, 2017

EIP 101 (Serenity): Currency and Crypto Abstraction #28

Closed

kylerchin approved these changes Jul 27, 2017

View reviewed changes

pirapira added the EIP label Dec 1, 2017

pirapira suggested changes Dec 13, 2017

View reviewed changes

oberstet mentioned this pull request Mar 25, 2018

EIP 665 - Add precompile for Ed25519 #949

Merged

Arachnid closed this Apr 6, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for ed25519 signature verification #665

Add support for ed25519 signature verification #665

ghost commented Jul 4, 2017 •

edited by ghost

Loading

kylerchin commented Jul 27, 2017

kylerchin left a comment

pirapira left a comment

pirapira Dec 13, 2017

pirapira Dec 13, 2017

pirapira Dec 13, 2017

pirapira Dec 13, 2017

pirapira Dec 13, 2017

pirapira commented Dec 13, 2017

oberstet commented Mar 22, 2018 •

edited

Loading

oberstet commented Mar 22, 2018

oberstet commented Mar 25, 2018

oberstet commented Mar 25, 2018

Arachnid commented Mar 27, 2018

oberstet commented Apr 6, 2018


		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.

Add support for ed25519 signature verification #665

Add support for ed25519 signature verification #665

Conversation

ghost commented Jul 4, 2017 • edited by ghost Loading

kylerchin commented Jul 27, 2017

kylerchin left a comment

Choose a reason for hiding this comment

pirapira left a comment

Choose a reason for hiding this comment

pirapira Dec 13, 2017

Choose a reason for hiding this comment

pirapira Dec 13, 2017

Choose a reason for hiding this comment

pirapira Dec 13, 2017

Choose a reason for hiding this comment

pirapira Dec 13, 2017

Choose a reason for hiding this comment

pirapira Dec 13, 2017

Choose a reason for hiding this comment

pirapira commented Dec 13, 2017

oberstet commented Mar 22, 2018 • edited Loading

oberstet commented Mar 22, 2018

oberstet commented Mar 25, 2018

oberstet commented Mar 25, 2018

Arachnid commented Mar 27, 2018

oberstet commented Apr 6, 2018

ghost commented Jul 4, 2017 •

edited by ghost

Loading

oberstet commented Mar 22, 2018 •

edited

Loading