EIP-7212: Precompiled for secp256r1 Curve Support

@doganalpaslan sorry, I should have just reviewed the EIP again before commenting. I would echo the other comments made here around wishing there was consistency against the existing ecrecover implementation.

I appreciate concerns around multiplying curves with various distinct interfaces; I think in an ideal world one could choose the desired curve points and format through a generic interface, but that seems unlikely at this point and I wouldn’t hold up this precompile waiting for such an effort.

Hello. We implemented a secp256r1 verification and presented it at ethCC Paris.

If having an ecrecover version benefits to the probability of adoption, it is trivial to modify the front code that relay the ouput of the authenticator from the ‘classic’ edsa to ‘ecdsa with recovery’ version. It only requires to add the parity of Q. While not of interest in the context of 4337, it would also enable to have a ‘multiplier checking with witness’ from the precompile.

We also advocate for ed25519, but it will require to implement sha512 in the nodes (while secp256r1 implementation only requires sha256). Also current authenticator implements the r1 and not the ed25519.

It could also be considered that if not choosing an ecrecover version, pushing a double scalar multiplication with addition would get rid of the hash function (the overcost of a single opcode being negligible compared to the whole computation), and compatible with zk mechanisms (hash function like sha and keccak are restraining their use). That is why a EC_MULMULADD performing uP+vQ would be superior in this context. (zk implementations like Circom implementation replaces SHA by poseidon in the ecdsa).

1 Like

Hello everyone.

I implemented P256VERIFY as a precompile inside Revm, which is the EVM implementation used in Reth, the new execution layer by Paradigm.

Here is my branch where you can find it: GitHub - alessandromazza98/revm at eip-7212

Specifically here is the precompile: https://github.com/alessandromazza98/revm/blob/eip-7212/crates/precompile/src/secp256r1.rs

The only difference is the address. The EIP says 0x19 while right now I used 0x0a only because of some assumptions that Revm uses about precompiles being in a crescent order without any wholes in between. But it is super easy to change that address.

I also wrote a little blog article to explain the steps if you are curios: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.


It’s a great contribution!

Can you elaborate on this more?

Can you explain more why current version wouldn’t support hash functions other than sha and keccak? EIP itself doesn’t have a restriction on which hash to use, so I think it should be possible to use it with, say, Poseidon or other ZK-friendly hashes.

  • If one want to tweak the precompile to compute u.G like in You can *kinda* abuse ECRECOVER to do ECMUL in secp256k1 today - Applications - Ethereum Research, the parity of the point is missing. you only obtain the x coordinates of the result (might be sufficient in many cases)

  • to use the precompile in a userOp, one will have to use it with the target hash function. As it is not strictly ecdsa (you have to sequence it with another call to the hash), why not designing uG+vQ as the precompile, which would have more use than only ECDSA ? Using UG+vQ, one can directly implement Schnorr. In my opinion there are 3 ways:
    ** precompile returns uG+vQ : can be used directly in many protocols (ECDSA, Schnorr)
    ** mimic ecrecover : backward compatibility for use cases using ecrecover on k1 without breaking APIs, can be used to compute uG+vQ, providing the hash as a witness
    ** ecdsa verification from hash (current specification) : only provide the x-value of the result uG+vQ if ‘abused’ not compatible with existing.