Generalised Precompile for Elliptic Curve arithmetics and pairings Working Group

There is discussion going on here: Precompile for general elliptic curve linear combinations

Recently, @shamatar (Alexander Vlasov) has agreed to become the leader of this Working group with the objective of researching and making reference implementation (and test generation) for this precompile (or group of precompiles). I understand that there is also work on figuring out the formula for the gas cost estimation, which is not trivial.

Please message DM him or post here if you would like to join the group, with the thought of what you can contribute and how much of your time you would like to commit.

1 Like

Thank you @AlexeyAkhunov. Here is also a link to an existing repo (with a legacy name).

1 Like

@AlexeyAkhunov, for discussions under this WG, should they fall under the category of “Ethereum 1.x”, or can I create a new category “EC Arithmetics and Pairings WG” and then tag all topics w/ “eth1x”?

I’m aiming to make topics easily searched-for on the Forum!

I can also create an entry for this and the other 1.x WGs on the wiki: https://github.com/ethereum-magicians/scrolls/wiki#rings

hey @AlexeyAkhunov @shamatar I would like to join the group.

Here is an EVMC Precompile implementation of the EIP using repo from @shamatar: https://github.com/axic/eip1962-evmc

Sure, can you PM me your telegram handle? Most of the discussion happens there.

Since this seems to supersedes https://eips.ethereum.org/EIPS/eip-1829 and https://eips.ethereum.org/EIPS/eip-665 (is it superseding the Ed25519 verification proposal), can you mention that in a section in the EIP? If this EIP is accepted, that it should mark those two properly “superseded”, but for now just a mention of the fact would be useful.

I am still strugging to understand why this isn’t four separate contracts? The first argument is a 4 way switch to 4 different logic paths, with at least two interpretations of the binary input data and multiple return value meanings.

The spec claims

  • One may separate interfaces for additions, multiplications and multiexponentiations and estimate gas costs differently for every operation, but it would bring confusion for users and will make it harder to use a precompile from the smart-contract.

But my experience as a software engineer says the opposite. Cramming too much functionality into one function call differentiated only by parameter values is what is making this hard to use. Four distinct contracts would be much better.