EIP-7212: Precompiled for secp256r1 Curve Support

RIPs
, , , ,
105

Yeah, indeed. Just might be cool to mention in the RIP that the precompile always returns true, so there is no room left for interpretations.

1 Like
106

Integration Updates

Congrats to all teams!

3 Likes
107

I’ve posted a short summary before the next ACDE about “RIP-7212 in Pectra” to help with its discussion.

2 Likes
108

Realistically, at this point, when will it come out on Ethereum?

It works on Polygon, BSC and elsewhere

1 Like
109

Final decision to add this proposal to the Pectra hard fork can be given in the next ACDE call due to the last one. You can check its summary:point_down:

EIP/RIP-7212

  • Ulaş Erdoğan shared a document with open questions about bringing EIP-7212 to mainnet.
  • I emphasized that we still hadn’t implemented everything we’d committed to for Pectra (and had just spent the rest of the call discussing ongoing spec changes), and that we probably shouldn’t consider extending the scope right now.
  • Ansgar shared that we keep pushing back the decision about 7212 and we should aim to make a final one soon, ideally the next ACDE.
1 Like
110

Is there any update on inclusion into Pectra of this? In the ACD calls it doesn’t seem like anyone is championing this. Therefore it doesn’t feel realistic that this EIP gets included.

1 Like
111

In a previous ACDE call, this decision has been postponed to months later depending on the execution-spec-tests coverage. It’s expected to complete the tests by community, core devs are busy with current Pectra schedule. Details are in the ACDE#193 recap. I am interested in working on that, but I am not knowledgeable yet and may not be able to focus enough in short term.

ENSDAO is also interested in incentivizing this contribution. cc @estmcmxci

1 Like
112

@ulerdogan can you create an EIP for secp256r1 precompile? We can then get an EIP number assigned.

2 Likes
113

Do you recommend having only copy-paste from the RIP content? Should this include any reference or mention to the RIP-7212?

3 Likes
114

Just to give share my impression from the ACD call yesterday:

  • The EthereumJS team would prefer not to include 7212 (see here), while other teams are generally supportive, but it was for all of them rather a nice-to-have than a must-have
  • Even with a split it seems that there is a tendency not to include 7212 (see here)

So the current sentiment seems to be that 7212 will rather not be included unless there is a stronger voice for this (afaik in the last 3 ACD calls 7212 was not discussed at all, even so for some general hardfork scope questions this would have made sense).

While I personally would like to see 7212 to come to Ethereum Mainnet, I currently do not have the capacity to push this, therefore I was reaching out to see if someone else can.

2 Likes
115

I am not an EIP editor, I am an associate (who assigns numbers. :smile:)

Suggest duplicating as much as possible.
Add in the abstract that the precompile was described as RIP-7212 and has been implemented on multiple L2s
Explicitly call out any differences to RIP-7212.

2 Likes
116

Depending on when Pectra Part 2 occurs, it may still be feasible to include it—so let’s not count it out just yet! ;]

—

That’s right; there is interest from the ENS DAO in supporting this specific EIP for inclusion in the next EVM hard fork. TL;DR: the DAO is willing to sponsor a bounty for a prequalified test writer to assist Ulaş, who can support but not lead broader testing efforts. Anyone interested and qualified is welcome to reach out to me on Telegram to discuss and learn more.

2 Likes
117

I see that 7212 is CFI in Fusaka – generally speaking, how will this decision get made one way or the other?

2 Likes
118

I see that the RIP states

Output data:

  • If the signature verification process succeeds, it returns 1 in 32 bytes format.
  • If the signature verification process fails, it does not return any output data.

But it fails to say weither signature verification failling is seen as a success or a failure.

Basically, if a solidity contract does

(bool success, bytes memory returndata) = address(0x100).call(abi.encode(hash, r, s, x, y));

with an invalid signature, will success be true or false ? If true, that means there is no way to distinguish a signature being invalid (which is a definitive result) from the precompile just not being present (which may require falling back to another more expensive verification mechanism, that in the end will fail)

Edit: it turns out I’m really late to the party.
See EIP-7212: Precompiled for secp256r1 Curve Support - #96 by dcposch

2 Likes
119

Agreed. To make an analogy, expected result shall not be found in stderr.

120

Hey, thanks for the comment.

The decision was to keep the return interface coherent to ecrecover. Today, I agree with you that it could be better with a more meaningful success-failure case, 1-0.

But as a Final RIP, it’s too late for a direct change without a new RIP. Also, I don’t think it’s a worthwhile effort, not a huge improvement vs a bit of complexity over implementation. Yoav had an idea of implementing RIP registry for the chains to help with this issue that might occur in the future, might be a solution.

121

That would be a very reasonable thing to say … except there is a precedent of this RIP being modified (and broken) AFTER it was marked as final.

I understand that it being deployed on many chains makes any chain a serious issue… but the final argument is not really the best one.

1 Like