Title: EIP_7212__Precompiled_for_secp256r1_Curve_Support
Category: RIPs

Author: ulerdogan
Date: 2023-06-22T12:47:25.436Z

Hi Magicians  
The post is about EIP-7212 RIP-7212 which proposes adding a new precompiled contract to the EVM that allows signature verifications in the “secp256r1” elliptic curve by given parameters of message hash, r - s components of the signature, and x - y coordinates of the public key.
 This post explains moving the proposal from EIP to RIP category.
 EIP Page (the PR):
https://eips.ethereum.org/EIPS/eip-7212
What are the use cases of the “secp256r1” elliptic curve?

The secp256k1 elliptic curve, which is the only cryptographic primitive to prove ownership in Ethereum, does not offer flexibility in onboarding new users via new solutions. Adding this new elliptical curve will allow biometric and hardware authorization solutions to be easily executed on-chain.
Many hardware and software solutions use this elliptic curve as signing algorithms, such as TLS, DNSSEC, Apple’s Secure Enclave, Passkeys, Android Keystore, and Yubikey, which can be used in the EVM.

Why is this precompile recommended, and how do we believe the user/developer experience will be improved?

The addition of this precompiled contract improves efficiency and gas affordability in the EVM. With the improvement, the gas costs are reduced alongside the computational load decreases, and the block gas limit is maximized to enhance the transaction throughput and overall network performance.
Supporting an elliptic curve with a precompiled contract provides a uniform and standardized way of operations. So that potential confusion and errors that occur from different implementations can be avoided. The curve operations can be made in reliable implementations in terms of security with precompiled contracts.
Enabling this precompiled contract improves the developer experience by allowing effortless integration of the curve signatures and building applications on top of it to provide interoperability with different solutions using the curve, resulting in more user-friendly products.

Possible integration ideas of the precompiled contract:


The EIP-4337 account abstraction wallets can use these elliptic curve signatures to sign the user operation data with mobile device secure elements and then validate them in the smart contracts.


@arachnid suggested in the ENSDAO that the precompiled contract allows lots of opportunities with DNSSEC for the projects by adding a new cryptographic primitive.

“One of the major barriers to onchain DNSSEC, along with many other potential projects such as web authentication integration, email verification, and other tasks that rely on verifying ‘real world’ crypto proofs, is the EVM’s limited support for cryptographic primitives.”



 The proposal has been discussed in the ACDE#168 call, the summary shared by Tim Beiko.
 Reference implementation on go-ethereum:
https://github.com/ethereum/go-ethereum/pull/27540
References:

https://neuromancer.sk/std/secg/secp256r1
"secp256r1" - For 256-Bit ECC Keys
https://wiki.hyperledger.org/display/BESU/SECP256R1+Support
A “secp256r1” package has already been included in the Besu Native library which is used by Besu client.

Author: ccamrobertson
Date: 2023-06-23T16:47:25.132Z

Glad to see someone propose this; we wrote a bespoke contract to do this at significant gas expense in 2019 for KONG Cash notes.
I would explicitly add secure elements as a rationale under hardware – low cost secure element chips are typically designed with P256 in order to support TLS. See the common ATTEC608A part from Microchip for one example.

Author: shemnon
Date: 2023-06-26T20:06:23.923Z

This precompile returns the actual signature instead of the address reduced form?  (like ECRECOVER does)?
I’m personally in favor of that, but I think that deserves an explicit call-out in the specification section or possibly more appropriately the backwards compatibility section.  The conversion of an EOA address is only done for secp256k1 curve keys, so a snippit to convert signatures to addresses is unneeded. Considering the number of times ECRECOVER is mentioned in the EIP we should call it out and add a note to explain why, to avoid confusion on the part of future readers.

Author: ulerdogan
Date: 2023-06-26T23:17:31.086Z

Hi, thanks for contributing!



 shemnon:

This precompile returns the actual signature instead of the address reduced form? (like ECRECOVER does)?


The implementation in the proposal only returns if the signature is valid or not by 1 and 0. I am sharing my design choice (almost the same as your comments) from the PR comments:

We need v value to recover public key without the x and y coordinates. The v value can be found by above-mentioned methods, but let me explain my design choice:

While we are making recovery with the ecrecover, we can reach the public address of the EOA accounts, so it can be directly used in the smart contracts. Unlikely, recovering the secp256r1 public key does not match any default stored types, and we still need to store the account public key.
Having to find the v value in the implementation part of the signature creates complexity on the application side. So, I didn’t want to bring this complexity for the applications. Still, I would love to reassess and edit the EIP to implement recovery after discussion.






 shemnon:

The conversion of an EOA address is only done for secp256k1 curve keys, so a snippit to convert signatures to addresses is unneeded.


The Rationale part includes this design choice, but I agree with you that it can be improved with this information.

Lastly, I couldn’t understand why you suggested explaining it in the Backwards Compatibility part, as it is a completely separate implementation.



 shemnon:

I’m personally in favor of that, but I think that deserves an explicit call-out in the specification section or possibly more appropriately the backwards compatibility section.

Author: ulerdogan
Date: 2023-06-27T00:15:15.610Z

Moving @_pm’s comment in the PR to here for the discussion:

paulmillr commented yesterday
-1

256r1 is usually more vulnerable to timing attacks than stuff like 25519.
256r1 is not even recommended by nist at this point, 384r1 is.
There are some rumors with regards to general security of r1 curves, it’s unclear.
Adding a new elliptic curve impl into ALL execution layer clients is not a trivial task. I don’t think the feature is too useful for this.


My comments:

The Golang crypto library works in constant time for the secp256r1 curve. Considering that the timing attacks are implementation dependent, it can be assumed to be safe.
I think that NIST’s recommendations points to the PQC, which are not ready for the production.
Apart from rumors, I did not see some definite evidences regarding security risks.
I see that the secp256r1 curve is the most mass adopted curve and it has a widespread use in many cases. It would be a great step on the mass adoption of Ethereum.

I would love to hear more about any ideas and researches that analyzing the vulnerabilities regarding the security risks of the curve.

Author: jdetychey
Date: 2023-06-27T10:27:50.516Z

Happy to join force on that.
We built a lof of stuff in Solidity already:
https://github.com/alembic-tech/P256-verify-signature
Demo: https://p256.alembic.tech/
And some doc:
The DeFi Infrastructurefor Businesses

Author: ccamrobertson
Date: 2023-06-27T20:41:36.948Z

@ulerdogan I just recalled that a broader precompile effort was put forth in 2019 with EIP-1829. It might be useful to understand from @Recmo what happened there and if revival of a more generic precompile would still be useful.
My sense is that 1829 has now been fully supplanted by one-off EIPs for specific curves and as such moving forward with a secp256r1 makes sense, but it might be worth reviewing.

Author: ulerdogan
Date: 2023-06-28T01:15:17.298Z

Hey, thanks for reviving the idea!
I followed the EIP-1829 discussions and some other contents. Then, I found EIP-1962 which is a continuation of EIP-1829 by Alex. It seems that the problems in the implementation later revealed EIP-2537 which was planned to be included in Cancun upgrade, now postponed.
Apparently, generalized curve implementations failed and were replaced by specific ones with EIP-2537 ([notes] by @timbeiko (https://twitter.com/TimBeiko/status/1235931932644564995?s=20) from an ACD call).
I would love to hear the ideas of those who have worked on precompiled contract implementations for curves about the previous experiences and this proposal! @Recmo @shamatar @ralexstokes @kelly

Author: xzhang
Date: 2023-06-28T14:07:04.179Z

I support this EIP. Just image how many new users will be attracted to Ethereum without the trouble to backup their mnemonics or private key on a piece of paper…

Author: fmc
Date: 2023-07-04T13:31:54.874Z

I do feel, that specific support for the secp256r1 curve is needed. There are a lot of requests for a gas-efficient way to verify passkey-signed data on-chain. And this proposal will make it possible.

Author: longfin
Date: 2023-07-04T17:17:20.571Z

I agree with your opinion that secp256r1 can be enough. however Ed25519 seems to still have many benefits, especially less computation.
And, it also seems that there was already an EIP about Ed25519, could we leverage that proposal?

Author: Toshi
Date: 2023-07-05T21:59:43.826Z

As per Vitalik’s post quite some time ago, I don’t recommend using the secp256r1 curves.
https://bitcoinmagazine.com/technical/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet-1382996984
" The obvious question is this: where did the seed come from? Why was the seed not chosen to be some more innocent-looking number, like 15? In light of recent revelations regarding the US National Security Agency subverting cryptographic standards, an obvious concern is that the seed was somehow deliberately chosen in order to make the curve weak in some way that only the NSA knows. Thankfully, the wiggle room is not unlimited. Because of the properties of hash functions, the NSA could not have found one “weak” curve and then gone backward to determine the seed; rather, the only avenue of attack is to try different seeds until one turns out to generate a curve that is weak. If the NSA knows of an elliptic curve vulnerability that affects only one specific curve, the pseudorandom parameter generation process would prevent them from standardizing it. However, if they knew of a weakness in one in every billion curves, then the process offers no protection; for all we know, c49d360886e704936a6678e1139d26b7819f7e90 could have been the billionth seed that the National Institute for Standards in Technology tried."

Author: ccamrobertson
Date: 2023-07-05T22:22:58.077Z

@longfin @Toshi I don’t think there are many that would dispute that secp256r1 is a non-ideal curve, however, the claims of a backdoor have been made for well over a decade without any substantive evidence of the existence of one. This is significantly different than the discussion for a SHA1 precompile which was demonstrably malleable at the time of proposal.
Proposing other curves arbitrarily ignores the key arguments in favor of this EIP which is that billions of devices have hardware accelerated support and isolated secure storage for secp256r1. Ed25519 would be great, but low cost secure element chips don’t support it (nor do they support secp256k1).
If this proposal sought to shift EOA creation to secp256r1 I would understand the concerns here, however, just adding it as a precompile doesn’t seem to me to warrant the ire that it’s currently receiving.

Author: longfin
Date: 2023-07-06T10:21:21.948Z

First of all, I don’t believe the rumors of a backdoor on secp256r1 seriously too. 
Aside from unconfirmed concerns about backdoors, the difference between secp256r1 and Ed25519 seems to be whether we will use relatively the modern curve or the little bit old curve that supports many devices, and coverage seems to make sense at this moment.

Author: ulerdogan
Date: 2023-07-06T14:00:48.538Z

Thanks for your comments @longfin @Toshi, and thanks for your explanation -I completely agree with you- @ccamrobertson.



 longfin:

Aside from unconfirmed concerns about backdoors, the difference between secp256r1 and Ed25519 seems to be whether we will use relatively the modern curve or the little bit old curve that supports many devices, and coverage seems to make sense at this moment. 


I think that even if ed25519 presents an efficient usage, I can’t find enough motivation to bring this curve into the EVM, but the secp256r1 curve has many cases that can directly improve the UX in Ethereum as it’s one of the most widely supported elliptic curves in the internet/mobile ecosystem.



 Toshi:

As per Vitalik’s post quite some time ago, I don’t recommend using the secp256r1 curves.


Also, my comments about the rumours: I agree with the idea that choosing the k1 curve as the main security mechanism of Bitcoin and Ethereum, but bringing the r1 curve as an additional verification mechanism in the app level, does not contradict this selection.
Additionally, pointing out an upper discussion:


Summary



 ulerdogan:

Moving @_pm’s comment in the PR to here for the discussion:

paulmillr  commented yesterday 
-1

256r1 is usually more vulnerable to timing attacks than stuff like 25519.
256r1 is not even recommended by nist at this point, 384r1 is.
There are some rumors with regards to general security of r1 curves, it’s unclear.
Adding a new elliptic curve impl into ALL execution layer clients is not a trivial task. I don’t think the feature is too useful for this.


My comments:

The Golang crypto library works in constant time for the secp256r1 curve. Considering that the timing attacks are implementation dependent, it can be assumed to be safe.
I think that NIST’s recommendations points to the PQC, which are not ready for the production.
Apart from rumors, I did not see some definite evidences regarding security risks.
I see that the secp256r1 curve is the most mass adopted curve and it has a widespread use in many cases. It would be a great step on the mass adoption of Ethereum.

I would love to hear more about any ideas and researches that analyzing the vulnerabilities regarding the security risks of the curve.

Author: mac
Date: 2023-07-06T14:42:25.936Z

i’m starting to see account-abstraction projects implement “riced-out” versions of secp256r1 signature verification to support passkey authenticators who dont support Koblitz, to save on gas. How the heck can I, a mere mortal, review, understand, and audit these implementations:
trampoline/contracts/EllipticCurve.sol at webauthn · eth-infinitism/trampoline · GitHub
aa-passkeys-wallet/src/Secp256r1.sol at main · itsobvioustech/aa-passkeys-wallet · GitHub
More importantly, if we want to onboard the next ${num} users onto the EVM, there are about 4billion devices that support webauthn: navigator.credentials.create() to securely create, store, and sign a PublicKeyCredential without installing anything
however, none of the devices I tested: (e.g., ~samsung phones, ~pixel phones, various iphones, m1 macbook, dell laptop (windows / linux / macOS))  support the Koblitz curve (secp256k1), they can only do secp256r1 (P-256, COSE Curve: 1, Alg: -7)
can we please get a precompile (or native support) for secp256r1 ? cc @vbuterin

Author: ccamrobertson
Date: 2023-07-06T20:28:11.217Z

Fantastic point. The harm from everyone rolling their own secp256r1 could be massive. If an AA scheme catches on leveraging a broken implementation you will see real loss vs. hypothetical loss from the NSA.

Author: jdetychey
Date: 2023-07-07T10:11:18.139Z

@mac Ledger security team will present this paper on the 17th at ethcc “WebAuthn Optimization: optimizing ECC sec256r1” this extend the resources in the repo previously shared above.
Regarding the debate on the security of p256 I recommend this article
This old Serenity EIP-101 discussing is relevant too:
https://github.com/ethereum/EIPs/issues/28#issuecomment-160335523

Author: sbacha
Date: 2023-07-09T09:26:44.659Z

OP produced an example implementation for OP hackathon project: Opclave | ETHGlobal

opclave-scaling2023/precompiles at main · itublockchain/opclave-scaling2023 · GitHub

Claiming this will help users manage their private keys better by entrenching them in a proprietary SoC solution (Apple Secure Enclave) is ridiculous. We trust in math, not Chinese supply chain vendors. Claiming that “backdooring” is not viable misses the point: we are not claiming that all chips are backdoored, only that certain chips be intercepted en route to end user by TAG/TAU and flashed with backdoor. It is hard to verify hardware, its easier to verify software.
Here is an approach that uses existing authentication schemes to provide user key management, check their github for examples. https://mfkdf.com/
Precompiles should be ossified, they were always a “temporary” solution, that was 8 years ago.

Author: Arachnid
Date: 2023-07-14T08:15:13.371Z

Strongly in support of this - secp256r1 is by far the most widely used curve, and enabling it to be efficiently verified in the EVM will enable countless integrations with existing infrastructure that are currently impractical.
Those suggesting alternate curves or raising issues with the derivation of the secp256r1 parameters are missing the point; the idea here is not to pick the ideal curve, it’s to add functionality that permits integrating with external and legacy applications efficiently.
I would suggest that an ‘ecrecover’ type implementation is more versatile, though; it’s easy to convert ecrecover into a signature verification operation, but impossible to do the inverse.

Author: mryalamanchi
Date: 2023-07-21T17:19:13.757Z

In strong support of this proposal.
Generally speaking, hard reproducible evidence has to exist for the claims of NSA influencing NIST to weaken the secp256r1.
Otherwise it’s unproductive for the conversation.
Alexander has been constantly requesting and implementing support for secp256k1 for the bitcoin community in Apple’s Swift crypto library for the past 4 years: New API Proposal: Add SECG curves, especially `secp256k1` · Issue #8 · apple/swift-crypto · GitHub
It’s evident from the conversation that they consider secp256k1 to be limited to cryptocurrency and not for “wide usecases” and have been delaying and denying support.
Considering this proposal, the wallet UX for regular Mobile users using Android/iOS/Android-derivate OSes can drastically improve.
This also includes keychain devices which already support the curve or hardware devices which can be built using secure element (SE) that support secp256r1.
So it isn’t just Mobile Devices, but beyond that, large no. of IoT devices can come integrated with SE and utilise this precompile to unlock new/existing use-cases.

Author: _pm
Date: 2023-08-07T16:51:49.197Z

I see no reason to support secp256r1 instead of x25519 / ed25519. r1 is US gov standard. The world is bigger than US.
25519:

is present in TLS 1.3, HPKE, SSH, PGP, Signal
is faster and more secure than p256
is much simpler, can be implemented without EC arithmetics

Author: ccamrobertson
Date: 2023-08-07T21:42:04.312Z

That’s a false dichotomy; this proposal doesn’t argue anywhere that secp256r1 support should supercede 25519 support. I suspect most people here would also support a 25519 precompile.

Author: xinbenlv
Date: 2023-08-08T21:15:40.168Z

I personally think secp256r1 has a lot of usage, having a precompile will be beneficial. And I also agree with the counter argument that there is cost to implement and adopt such precompile.
It seems a pattern that whenever a precompile is proposed, there will be a lot of debate about whether there is likely to be a lot of usage. The chicken-and-egg nature is that without deploying the precompile, we can’t calculate the adoption, and without the adoption, it’s hard to argue for making it a precompile.
Good news, we are propose to have a “progressive path towards precompiles”, where author proposes a precompile, but instead of requiring it to be deployed as precompile first, they deploy a precompile candidate which is a traditional smart contract (with higher gas cost per operation, though), and see if there is usage. Once the usage is validated, the data can be used to (1) justify the need for such precompile, and (2) serve as call pattern to help client implementor tune performance
See more Progressive precompiles via CREATE2 shadowing

Author: 7212Bull
Date: 2023-08-09T10:08:52.369Z

In terms of usecase and “will it get used”, this EIP is essentially for onboarding the next millions of users. There’s no way to onboard normies at the moment as you need to use MetaMask or another wallet to use DeFi, NFTs etc. With this EIP we can convert web2 users in scale.

Author: evmbrahmin
Date: 2023-08-09T22:20:14.259Z

Would like to express support for this EIP. Echo the opinion that this should not be a debate on the security of the curve. Providing a precompile for the curve enables integration with mass distributed hardware where users are already trusting the curve. We should provide an option for those users to extend that trust to smart contracts which elect to use this curve for validation.
To me it feels pretty straight forward. The most widely adopted curve should have a precompile. Its not forcing anyone to use it but provides critical functionality for those who want it.

Author: Deus
Date: 2023-08-10T18:11:49.745Z

+1 Echoing support for this EIP. Game changer in terms of onboarding.

Author: _pm
Date: 2023-08-11T20:54:28.519Z

EVM can’t include every curve. Including even one additional curve drastically increases system complexity. Choices need to be made, carefully.
Implementing a new curve:

Requires secure cryptography for all execution-layer clients
a. There needs to be implementations in go, .net, java, rust
b. Someone will need to audit them
c. Low-level impl is not the same as high-level, probably platform-specific assembly code would be required
Clients will need to support the new code for many years, going forward
a. Why not pick something better right now? That’s ed25519.
The PR advances usage of p256. We should decrease its usage. p256:
a. Relies on PRNG security for nonce reuse, which has been breached continuously. See playstation root key extraction.
b. Is usually slower than ed25519
c. Is harder to implement in const-time than ed25519. Renes-Costello-Batina 2015 helps, but it’s really slow. See https://minerva.crocs.fi.muni.cz

There is EIP-665 for ed25519. We should support it instead.

Author: 7212Bull
Date: 2023-08-13T03:38:20.206Z

Apologies if this is a dumb question but is there a bounty system we can bid up to get this approved? I’m willing to put a few thousand in for incentive.
This EIP is the room temperature superconductor moment for EVM, it’s likely the sole impediment to the next billion users.
I have this thread as my start page on my browser and read everyone’s bull post comment out loud. Let’s get it boiiii

Author: pcaversaccio
Date: 2023-08-14T17:42:52.198Z

There are a couple of thoughts and feedback I would like to share on this proposal:

I generally support EVM changes that can help onboard the next millions of users. However, I neither trust Apple nor Android, nor any big corporation that may use secp256r1 as curve. We should work on solutions, which make us more independent than dependent on potential supply chain attacks.
The original Yellow Paper states: these are so-called ‘precompiled’ contracts, meant as a preliminary piece of architecture that may later become native extensions. But we don’t yet know if this new instruction is something that will have traction and be a future-proof feature that will eventually be added as opcode. To figure this out, I suggest using the L2 EVM versions (and not the mainnet EVM version, but e.g. Optimism and Arbitrum) to test the need for this new instruction and, if proven to be important enough, eventually add it as opcode to the EVM mainnet version. IMO, generally, we should not add more precompiles to the mainnet EVM; if it is important enough, it should be an opcode. Period.
If secp256r1 support is added, soon many wallets will support it. But we eventually don’t know whether there really exists a backdoor or not. You can call it paranoid, but I’m rather 100% safe than sorry ultimately.
The secp256r1 implementation is not consistent with the current ecrecover implementation that returns the recovered 20-byte address instead. I can already see implementation bugs here. I strongly recommend aligning the behaviour with ecrecover. I do follow the arguments laid out in the rationale section, but ultimately what matters is the execution part, and we should keep consistency in how ECDSA precompile methods return values IMHO.
The secp256r1 elliptic curve is not quantum-resistence and thus ultimately not future proof (only time will tell when however).
The current implementation doesn’t support Schnorr signatures - is there a way, we can support not only ECDSA but also Schnorr signatures?

Author: _pm
Date: 2023-08-16T01:02:13.554Z

Note that Schnorr signature standard (BIP340) has only been defined for secp256k1, not for any other curve. It’s also unclear which other curves are using them at all.

Author: pcaversaccio
Date: 2023-08-16T08:47:08.656Z

Right, thanks for pointing this out - we might want to consider proposing a standard for secp256r1 in that case, as I consider Schnorr signatures an important future-proof algorithm.

Author: _pm
Date: 2023-08-18T11:31:10.385Z

r1 seems to be decreasing in popularity though, may not be worth it. Most new protocols are using x + ed 25519, which became a part of FIPS standard now.
A generic schnorr standard for weierstraß curves would be ok

Author: zhangzhongnan928
Date: 2023-08-31T02:26:30.142Z

It seems there are other option to achieve the same goal as well. Does anyone know JoyID? Their team have done some hard crypto work and achieved the same results without adding precompiled contract or modifying Ethereum itself. I have been testing it for a few weeks

Author: doganalpaslan
Date: 2023-08-31T10:34:20.275Z

zhangzhongnan928:

Does anyone know JoyID?


AFAIK They works on Nervos which has a precompiled for P256 curve.

Author: merkleplant
Date: 2023-09-02T12:53:55.983Z

While I’m very excited of the possibilities r1 may introduce, I oppose adding support on L1 for the following reasons:
The chances of r1 having a backdoor, while as small as they may be, should be taken serious. Ethereum has a responsibility towards its users that should not be waived via arguing r1 is not a protocol level supported curve while being introduced with the goal of increasing onboarding.
I think we should utilize the L2 landscape as playground. Different L2s may set their priorities wrt to security vs onboarding differently. Securing increasing value via r1 increases the incentive to utilize the backdoor for everyone knowing about it. Once r1 secured high value over a long timeframe on (multiple) L2(s), it will be easier to gather support for an L1 support.
In case of a backdoor, the decision whether to remove the support is also highly political, among the obvious of breaking backwards compatibility. When exactly do we deem crypto insecure? Starting at <100 bit (like the still supported alt_bn256 curve), <80?
The inconsistency of the precompile wrt to ecrecover may also lead to many more bugs and more complex code. Furthermore, the proposed precompile does not allow verifying an elliptic curve multiplication like ecrecover (see vitalik’s post). This also makes verifying Schnorr signatures impossible (see this post).

Author: ccamrobertson
Date: 2023-09-03T05:16:55.074Z

The chances of r1 having a backdoor, while as small as they may be, should be taken serious. Ethereum has a responsibility towards its users that should not be waived via arguing r1 is not a protocol level supported curve while being introduced with the goal of increasing onboarding.

There are billions of devices with hardware P256 support and 0 public attacks demonstrating that P256 is broken, 14 years after Bitcoin chose k1 because of this concern. I fully expect, and welcome, a viable P256 attack to end this silly debate, however, I imagine it will happen roughly the same time k1 is broken due to quantum computing (at which point there will also be a massively political discussion to remove k1 support).
It should also be reinforced that this is for an optional precompile, not a mandated curve change for EOAs.
Several people seem to be arguing that this proposal breaks ecrecover; I agree on this point. This seems like it would need to be solved as Ethereum moves from 1 to n curves regardless (e.g. when we add ed25519). I’m curious to hear from @ulerdogan on this point. I suspect core devs have a proposal on how to resolve (via novel op codes?)

Author: ulerdogan
Date: 2023-09-05T14:04:05.472Z

ccamrobertson:

Several people seem to be arguing that this proposal breaks ecrecover; I agree on this point.


Currently, we are exploring turning to recovery to present a similar interface and provide backward compatibility with the k1 curve applications. Why do you think it breaks ecrecover? If just because of the change in interface, why does it have to follow the same interface?

Author: ccamrobertson
Date: 2023-09-05T15:37:31.970Z

I agree that it doesn’t need to follow the same interface, however, I imagine that any solution here should be interoperable with goals for precompiles for other curves. This would influence whether you create a bespoke ecrecover_r1 vs. some generic variant with an interface that allows for any curve where this would be applicable.
Without seeing the code I’m not quite sure I follow what you are describing as the solution here (a new ecrecover that defaults to k1 and allows for parametrization of the curves and curve format?)

Author: doganalpaslan
Date: 2023-09-05T18:39:16.385Z

ccamrobertson:

Without seeing the code I’m not quite sure I follow what you are describing as the solution here (a new ecrecover that defaults to k1 and allows for parametrization of the curves and curve format?)


Can you elaborate your question a bit more?

Author: ccamrobertson
Date: 2023-09-05T19:45:52.853Z

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

Author: rdubois-crypto
Date: 2023-09-14T16:09:26.905Z

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


IACR Cryptology ePrint Archive – 15 Jun 23



Speeding up elliptic computations for Ethereum Account Abstraction
Account Abstraction is a powerful feature that will transform today Web3 onboarding UX. This notes describes an EVM (Ethereum Virtual Machine) implementation of the well known secp256r1 and ed25519 curves optimized for the specificities of the EVM...





https://github.com/rdubois-crypto/FreshCryptoLib
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).

Author: alessandromazza98
Date: 2023-09-19T08:27:12.747Z

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.

Author: ulerdogan
Date: 2023-09-19T19:04:20.561Z

rdubois-crypto:

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


It’s a great contribution!



 rdubois-crypto:

it would also enable to have a ‘multiplier checking with witness’ from the precompile.


Can you elaborate on this more?



 rdubois-crypto:

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


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.

Author: rdubois-crypto
Date: 2023-09-20T20:33:38.910Z

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.

Author: rdubois-crypto
Date: 2023-09-21T16:35:15.294Z

Would you have the resulting gas cost of a single verification of this implementation pls ?

Author: alessandromazza98
Date: 2023-09-22T09:35:07.605Z

It should be 26974 units of gas

Author: ulerdogan
Date: 2023-09-22T09:38:55.133Z

How is it calculated? It has to be constant for clients following the Final specification.

Author: alessandromazza98
Date: 2023-09-22T09:54:10.736Z

Sorry, maybe I did not understand properly the previous question.
The P256VERIFY precompile consumes a fixed amount of gas which is specified in the EIP itself, which is 3450

Author: rdubois-crypto
Date: 2023-09-22T18:16:23.075Z

I wasn’t clear, my question was about the cost of the REVM resulting gas cost for a verification without precompile.
Concerning the pricing of the precompile, sec256k1 allows fastest verification thanks to the GLV speed up, which is not possible over sec256r1. This speed up cut the cost by 50%. Following this logic the cost of the precompile (and the extra burden on nodes) should be 6000.

Author: ulerdogan
Date: 2023-09-22T20:40:15.719Z

rdubois-crypto:

I wasn’t clear, my question was about the cost of the REVM resulting gas cost for a verification without precompile.


I don’t think that it depends on different clients.



 rdubois-crypto:

Concerning the pricing of the precompile, sec256k1 allows fastest verification thanks to the GLV speed up, which is not possible over sec256r1. This speed up cut the cost by 50%. Following this logic the cost of the precompile (and the extra burden on nodes) should be 6000.


My test cases show that p256verify is ~15% slower than ecrecover. Do you think that there is incorrect calculation or method? Maybe we should include comparisons for more clients.



 rdubois-crypto:

(and the extra burden on nodes)


Also, what do you mean by “extra burden”?

Author: rdubois-crypto
Date: 2023-09-23T02:07:46.865Z

The fact that it is only 15% indicates that GLV method is not used in this specific implementation. Asymptotically sec256k1 is twice faster. This means that the precompile cost shall be doubled. This is fact I was describing as a 'burden". Replacing k1 by r1 would lead to more workload on nodes.

Author: ulerdogan
Date: 2023-09-24T21:43:39.589Z

rdubois-crypto:

The fact that it is only 15% indicates that GLV method is not used in this specific implementation.


The test cases have run in the geth client. As geth is the major client with a huge use, I think that we can consider GLV not dominant or used in Ethereum and ignore the GLV performance boost of the k1.



 rdubois-crypto:

This means that the precompile cost shall be doubled.


So, I don’t think that we should change the gas cost.



 rdubois-crypto:

Replacing k1 by r1 would lead to more workload on nodes.


Since it’s not a replacement for the k1 curve, why do you think that it’s a workload?

Author: jdetychey
Date: 2023-09-26T15:20:12.667Z

Couple of comments:



 xinbenlv:

Good news, we are propose to have a “progressive path towards precompiles”, where author proposes a precompile, but instead of requiring it to be deployed as precompile first, they deploy a precompile candidate which is a traditional smart contract (with higher gas cost per operation, though), and see if there is usage.


Indeed, I love the approach @ulerdogan although taking this contract address as the reference address can impact performance versus having an address with 38 zeros like… 0x10 ?
For reference, here the link to the EthCC talk on p256 “WebAuthn Optimization: optimizing ECC sec256r1”
Regarding concerns on p256 (vs ed25519)



 _pm:

Choices need to be made, carefully.


Audited implementation in most execution client languages are available, specifically for Verification afaIk. Constant-time is notably available in Go. Adding a precompile for this curve doesn’t delay support for other curve, I would argue this instead sets a template for other curves to be supported swiftly. Progressive support with a smartcontract first helps a lot Imho.  Regarding concerns on the security of p256, it should be noted that this precompile improves smartwallets which themselves can hold rules to mitigate that risk.
Regarding the Verify vs Recover:



 Arachnid:

I would suggest that an ‘ecrecover’ type implementation is more versatile, though; it’s easy to convert ecrecover into a signature verification operation, but impossible to do the inverse.


I would prefer to stick with Verify for readiness purposes rather than recover.

Author: hoytech
Date: 2023-09-30T15:12:34.573Z

I implemented a smart contract and command-line wallet software that uses secp256r1 via FIDO2 security tokens at the HackMoney 2020 hackathon. Each signature verification cost about a million gas, but it did prove the concept:


github.com




GitHub - hoytech/defido2: Command-line, contract-based ethereum hardware...
Command-line, contract-based ethereum hardware wallet






The judging for this was quite amusing. At the end, in the question period, it became clear that the panel thought “security tokens” referred to “ERC-20 token securities”. Once they understood the concept, it was dismissed since “why not just get a ledger?”.
BTW I see some references to webauthn. Has anyone actually tried this? When I looked into it, it didn’t seem like you could use this without tying your wallet to a particular DNS domain name, or possibly self-hosting at localhost or something – both bad UX. It might work better with CTAP2 over WebUSB. My defido2 app uses CTAP2, abstracted by libfido2.
Little known fact: recent-ish YubiKey firmware in fact supports secp256k1 (and ed25519 and others), so if you are using a recent YubiKey over CTAP2 you may not even need a new pre-compile. I wanted to link to the yubi docs, but new users can’t include so many links apparently.

Author: rdubois-crypto
Date: 2023-10-03T08:04:58.414Z

Hello, thanks for highliting this implementation. Sorry that the jury didn’t not understood better the fact that it provides the highest security level you can have with a device we all already have in our pocket.
The point with secp256r1 is to benefit from smartphone secure enclave, giving access to the best security you can have with a smartphone. The day Ed25519 is implemented, it will be superior (might happen from 6 month to several years). I doubt secp256k1 will ever be.
This is not the subject here, but Yubikey are not more UX friendly than a hardware wallet. From my biased perspective (i have conflict of interest in the next sentence), if you are to buy a device, buy a Ledger. Fido is implemented as a secondary feature (https://support.ledger.com/hc/en-us/articles/115005198545-FIDO-U2F?docs=true), and its core function is cryptocurrencies handling.

Author: cejay
Date: 2023-10-08T07:51:51.843Z

I disagree with adding SECP256K1 as a precompiled contract, for the following reasons:

SECP256R1 may have a “backdoor” (although there are no known public attacks).

Given that contract wallets may become widely adopted, this is a risk that cannot be ignored.


Device-dependent SECP256R1 signatures may be vulnerable to attacks, such as:

Some device manufacturers might leak private keys stored in a secure chip to law enforcement agencies under certain circumstances.
Some device manufacturers might submit your device’s public key to law enforcement agencies, potentially exposing the purchase records of anonymous wallet owners on the blockchain.



But we can’t ignore the advantages of SECP256K1 widely supported by devices. We can address the drawbacks of SECP256K1 through zk-proof while harnessing its benefits!
Fortunately, webauthn-halo2 provides inspiration, as it can address these issues to some extent:

Gas:

While ZKP in contracts often result in high gas cost, it’s not an absolute rule. Some algorithms can bring gas advantages through clever circuit design. For example, the gas consumption of webauthn-halo2 is only half of that of conventional signature algorithms! ( AND Consider batch proofs again! The cost of zkp will approach zero! )


Backdoors and Manufacturer Attacks:

In on-chain contracts, we cannot directly store SECP256R1 public keys but should store the hash value of the public key. To prevent “rainbow table attacks,” this hashing algorithm should accept a secret “setting,” such as the zkp-friendly Pedersen-Hash. Generating this hash requires user input (such as the user wallet’s unlock password).



those are my main points. Thank you.
[The above content is from the article I previously posted]

Author: cejay
Date: 2023-10-08T08:08:41.946Z

After adding precompiled contracts, ‘backdoor’ and ‘vendor attacks’ will become like the Sword of Damocles, making the entire ecosystem difficult to escape from. If ‘backdoor’ and ‘vendor attacks’ were to come true, it would plunge the entire ecosystem into panic, even if the probability is extremely low～

Author: rdubois-crypto
Date: 2023-10-13T12:34:38.546Z

Argument for device-dependant also hold for the native sec256k1. If Ledger trapped its device, 6M users may be rugged (tinfoil scenario, not believing it).
SHA3/SHA256 aez out of reach of a rainbow attack, no need for Pedersen to have a ‘secret’ as setting. This is what HMAC does and can be efficiently performed by the related opcodes.
If sec256r1 appears to be trapped, most of tls connections, mastercards EMV are exposed. While Ethereum is important, let’s not forget that it is still a grain of sand compared to those. And as opposite to those, ERC4337 will allow instant replacement of the signer. (I also expect any decent smart account to integrate fallback solutions from the start).

Secp256r1 precompile shall not aim to replace secp256k1, only provides an option for a lighter UX. From my point of view it aims to target low value tx (as your contact less VISA/MASTERCARD, limited to low amounts) with fast UX. For larger stakes, use multisig and solution like gnosis-safe, (or other multisig base framework, just citing the most known here).

Author: pcaversaccio
Date: 2023-10-15T16:37:39.469Z

Hey guys, FWIW, ~28hrs ago I decided to not touch grass this weekend and instead write the first ever P256 signature verification contract in Vyper. My Vyper contract passes all tests of the original Daimo implementation in Solidity! You can find my repo here. Furthermore, I deployed the contract to Sepolia, Goerli and Holesky:

Goerli: 0xD99D0f622506C2521cceb80B78CAeBE1798C7Ed5
Sepolia: 0xD99D0f622506C2521cceb80B78CAeBE1798C7Ed5
Holešky: 0xD99D0f622506C2521cceb80B78CAeBE1798C7Ed5

Author: cejay
Date: 2023-10-16T07:06:07.723Z

Yes, additionally, I suggest referring to the implementation by @rdubois-crypto :


github.com


rdubois-crypto/FreshCryptoLib/blob/61db2702c90688f56a3f4f9acc1ccd27801c0db1/solidity/src/FCL_elliptic.sol#L958

      
          
              //Shamir 8 dimensions
              X = ecZZ_mulmuladd_S8_hackmem(mulmod(uint256(message), sInv, n), mulmod(rs[0], sInv, n), endcontract);
          
              assembly {
                  X := addmod(X, sub(n, calldataload(rs)), n)
              }
              return X == 0;
          } //end  ecdsa_precomputed_verify()
          
          function ec_recover_r1(uint256 h, uint256 v, uint256 r, uint256 s) internal returns (address)
          {
               if (r == 0 || r >= n || s == 0 || s >= n) {
                  return address(0);
              }
              uint256 y=ec_Decompress(r, v-27);
              uint256 rinv=FCL_nModInv(r);
              uint256 u1=mulmod(n-addmod(0,h,n), rinv,n);//-hr^-1
              uint256 u2=mulmod(s, rinv,n);//sr^-1
          
              uint256 Qx;
      
    





Use the public key recovery method so that you don’t need to store the public key in two slots on the chain

Author: pcaversaccio
Date: 2023-10-19T15:25:29.368Z

Hey guys, we just launched an initiative to supercharge the NIST Elliptic Curve seeds bounty. The aim is essentially to find the pre-image for the P256 seed c49d360886e704936a6678e1139d26b7819f7e90 given the major hint in the original bug bounty announcement:
image1285×618 44.3 KB
The people who are involved are:
image1091×648 37.5 KB
A major shoutout to @merkleplant who has been the driver behind this initiative! Would appreciate spreading this initiative & any donations are ofc welcome

Author: EGreg
Date: 2023-10-24T22:58:00.754Z

I would like to disagree with this disagreement, and add my 2 cents in support of adding this precompiled contract.
Right now, Ethereum’s “Web3” ecosystem has many vulnerabilities. In practice, people trust the website they are on (such as app . uniswap . com) to produce “safe” transactions. Very few people even check what contract is being interacted with, or what method is being called, or what parameters are being passed, they just simply press “OK” because they trust the website (and PKI ecosystem for HTTPS and DNSSEC). But the webserver can easily be hacked, or the DNS can be pointed to a different server, stealing funds from anyone who uses, say, the Uniswap web interface (which is what most people use to access Uniswap) and the same goes for any DEX.
Similarly, people sign into websites by signing various payloads, and even EIP712 doesn’t really help if the payload is complex.
But the biggest issue is in practice people don’t actually remember their 12 word phrase. They take a screenshot of it, or write it down somewhere their friends can find it. I encourage everyone I know to duplicate the phrase 3 times, cut it with scizzors into a grid of 12 pieces, and hide it in different places… most people don’t do that, however.
The fact that most Ethereum wallets allow exporting private keys is a major security flaw for the Ethereum ecosystem. This is how people get phished, whether for their private key or security phrase. Even a few developers fall for fixation attacks, by using a website to generate a vanity address, or something like that.
By contrast, having a precompiled contract will give all Ethereum users the option to authenticate using a device of their choice, from a growing number of authenticator systems. Face it, most of the world’s authentication / signature systems in public use – including secure enclaves, and even webauthn and web subtle crypto – use the r1 curve not the k1 curve. And the governments and industry are unlikely to join Bitcoin / Ethereum, it’s been over a decade and they don’t care. If anything, they are doing what they can to marginalize the ecosystem.
So, if you consider the trade-offs between a possible backdoor in manufacturer keys or even SECP256R1 curve itself, against most people taking screenshots of their phrases and syncing it into the (unencrypted) iCloud, or being able to export their private keys, I think it’s a net security gain for the ecosystem to make it cheap to verify these signatures.
And frankly, it’s a HUGE net gain for their adoption – no one wants to remember 12 words, when they can use passkeys or whatever.
The Open Web
But even more to the point – the open web standards and web crypto support sec256R1 for non-extractable keys. By contrast, web3.js and ethers.js or any other JS library that Web3 would use are forced to keep the keys accessible to Javascript! Compared to the potential security downsides of allowing SECP256r this  is absolutely terrible from a security point of view.
Maybe the guys behind app . uniswap . com and etherscan.io have a tight lid on security, who knows. But Ethereum and Web3 have enabled a long tail of websites to incorporate it, just like PHP script kiddies and  tags back in the day. Any one of those websites can be hacked, or the Javascript switched out. In fact, even MetaMask wallet and other wallet browser extensions can and do swap their code out anytime! And app-based wallets can ship an update via the App Store, and no one would be the wiser. I don’t think Apple would catch it.
I wonder what @vbuterin would say is more of a threat, Apple / Google backdooring their secure enclaves or Consensys / publishers of Metamask and Binance / publishers of Trustwallet backdooring their next version, or Apple / Google backdooring the app store versions (no one checks reproducible builds). Seems obvious to me that the latter includes the former (Apple/Google) plus a long tail of wallet makers. Moving to SECP256R1 would reduce the attack surface tremendously while also making EVM go mainstream in a big way.
Future Directions
If you want the EVM ecosystem (Ethereum/BNB/MATIC) ecosystem to stop having a reputation for scams and rugpulls, we need to have professional developers move to factory patterns rather than “devs in a Telegram chat” who clone a SAFEMOON contract and rugpull you. Most smart contracts should just be produced by factories, with custom parameters. (Compare the trust people place in Uniswap Liquidity Pools for example vs a random SAFEMOON clone that was deployed manually to the blockchain.)
But besides the factory pattern, we have to get rid of the terrible practices of 12 word phrases just to create a wallet, the ability to export private keys, etc. etc. And if we start to support cheap verifications of SECP256R1 signatures on the blockchain, then people can have a direct relationship with contracts on the blockchain, and in addition trust only their Operating System and Browser vendors (which is their trusted computing base anyway) instead of a myriad websites and extensions all serving their own Javascript and able to switch it out anytime.
Disclaimer: I’ve spent $1 million and 5 years to build such an open source ecosystem, which you can see here… but we are not the only ones:



Intercoin – 25 May 18




Applications of Intercoin: Making Crypto Mainstream

Windows and MacOS were amazing graphical operating systems, but someone needed to build applications for regular people to take advantage of the new technology. That is what Microsoft Office did for businesses and Adobe Creative Suite did for...

Reading time: 2 mins 🕑
Likes: 13 ❤

Author: EGreg
Date: 2023-10-24T23:06:15.333Z

I should add that unless we make it cheap and easy for smart contracts to verify SECP256R1 signatures, even a simple XSS exploit on a site (including third party analytics, let’s say), can steal the keys, phone home and later use them to sign any payload.
As a web developer for over a decade I definitely can say that having sandboxed iframes with postMessage, and subresource integrity, mitigates most of the XSS attacks inside those iframes. So if you as a web developer place such an iframe on your webpage, with SRI, then any code that loads inside it (cached or not) can be trusted, as long as some third parties have vetted that SRI hash. That is currently the only way to ensure reliable security on the open web. But if the top-level website colludes with the iframe then users who trust both domains will be open to having their keys stolen. In the case of browser extensions, just consider them the same as that iframe … they just come from the Google Chrome Store, e. g. Metamask.

Author: jdetychey
Date: 2023-11-02T15:02:01.166Z

EGreg:

So, if you consider the trade-offs between a possible backdoor in manufacturer keys or even SECP256R1 curve itself, against most people taking screenshots of their phrases and syncing it into the (unencrypted) iCloud, or being able to export their private keys, I think it’s a net security gain for the ecosystem to make it cheap to verify these signatures.


Couldn’t agree more.

Author: rdubois-crypto
Date: 2023-11-03T09:14:59.499Z

Hi Magicians,
They were inconsistencies in the Benches of EIP7212 implementations, so here is the onchain address for the FCL version of EIP7212:
0xE9399D1183a5cf9E14B120875A616b6E2bcB840a, available on Polygon (Mainnet), and the following testnets: Sepolia, Optimism, Base and Linea.
It has the same API’s as Daimo and Vyper, and you will find a script to easily push additional transactions on chain here:

github.com


rdubois-crypto/FreshCryptoLib/blob/master/solidity/tests/cast/cast_bench_FCLvsdaimo.sh
#the way to sign the transactions to send 
SIGNER="--ledger" #safe version, open Ethereum application on your ledger, allow blind signing
#$SIGNER="PRIVATE_KEY=<>", unsafe version, using a private key of EOA

#list of RPCs
LINEA_TESTNET=https://rpc.goerli.linea.build
BASESCAN_TESTNET_RPC=https://goerli.base.org 

FCL_ADDRESS=0xE9399D1183a5cf9E14B120875A616b6E2bcB840a
DAIMO_ADDRESS=0xc2b78104907F722DABAc4C69f826a522B2754De4 #Daimo is only testnet is basescan as of 25/10/23

# pick a network and RPC
NETWORK="BASE"
RPC=$BASESCAN_TESTNET_RPC

#pick a seed
SEED=$( echo $RANDOM)
#pick random values for input (testing purpose)
KPRIV=$(cast keccak "1"$SEED)
NONCE=$(cast keccak "2"$SEED)




  This file has been truncated. show original





(script uses the --ledger version, use PRIVATEKEY=<> instead if u don’t have one for testing)
For daimo, on chain results indicate a 355K average cost, FCL a 227K average cost.
The version with precomputations shall be easier to use with this script, the cost is around 100K because we are using the 'extcodecopy" version to provide a blockexplorer code verification. (Optimal codecopy, unverified is close to 80K in a tx).

Author: ulerdogan
Date: 2023-12-20T00:12:57.757Z

EIP Update:
As discussed in the RollCall#0 and RollCall#1, the final decision is that it would be more beneficial and quick to continue the proposal as a RIP. Thus, willing rollups will be allowed to complete their implementation around the standardization created with RIP.
In this regard, a copy of the EIP with RIP naming has been merged into the RIP repo in the Last Call. 


github.com/ethereum/RIPs








Add RIP: secp256r1 precompile (copies eip-7212) in last call


master ← ulerdogan:ulerdogan/move-eip-7212



          opened 07:39PM - 12 Dec 23 UTC




            ulerdogan
          



+260
-0






# WHAT

This PR adds a copy of [EIP-7212](https://eips.ethereum.org/EIPS/eip-7…212) as an RIP, which presents the precompiled contract of `secp256r1` EC verifier.

# WHY

This proposal will be discussed at [RollCall#1](https://github.com/ethereum/pm/issues/907) by the L2 teams as a Last Call. The PR prepares preliminary content for the L2-specific discussion. The proposal itself or the format are subject to change based on feedback or the newly decided RIP structure.

# HOW

It's just a copy of content for now. Necessary changes will be implemented subsequently.






The RIP specification will be finalized by determining the address space where the precompiles will be implemented. Also, the proposal will be changed due to the RIP repo requirements. Would love to hear your last comments and feedback during the Last Call.
image912×1368 62.5 KB

Author: ulerdogan
Date: 2023-12-21T21:29:44.042Z

RIP Update: Finalization of the Specs and Announcing Last Call Deadline
Following the RIP merge, the address range for the RIP precompiles has been set to 0x100+ (ACDE#177 as reference) and as the first precompile as RIP, P256VERIFY will have 0x100 address (indicates 0x00...00100).
Last Call deadline is 2 weeks from now, until the 4th of January. Then, the proposal will be moved to the Final status and be ready for any implementations by rollups.

Author: EGreg
Date: 2023-12-24T02:42:22.549Z

Wow. Two months after I wrote this, the Ledger wallet JS got hacked in the exact way that this would have prevented

As a web developer for over a decade I definitely can say that having sandboxed iframes with postMessage, and subresource integrity, mitigates most of the XSS attacks inside those iframes. So if you as a web developer place such an iframe on your webpage, with SRI, then any code that loads inside it (cached or not) can be trusted, as long as some third parties have vetted that SRI hash. That is currently the only way to ensure reliable security on the open web.

Author: EGreg
Date: 2023-12-24T02:43:53.931Z

ulerdogan:

Last Call deadline is 2 weeks from now, until the 4th of January. Then, the proposal will be moved to the Final status and be ready for any implementations by rollups.


@ulerdogan what about layer 1 blockchains like Ethereum Mainnet, Polygon, Binance Smart Chain, etc. ? This is only for rollups and Layer2s?

Author: ulerdogan
Date: 2023-12-24T12:27:18.691Z

It’s dependent on the governance mechanisms for every L1 or L2 chain.

The address is reserved for this precompile in Ethereum L1 and it can be implemented in the future.
BNB Chain has no blocker for any implementation.
Polygon will possibly implement in the next hard fork, Napoli, also already included in its codebase.
Another unmentioned integration is Evmos which already been included in their codebase.

Author: Michaels
Date: 2023-12-25T17:31:59.418Z

Hello everyone! I’d like to express massive support for this EIP!
Wanted to share that some months back I also wrote an implementation of a P256 verifier in Huff Language. I implemented it from Daimo’s implementation and made some optimisations to it to bring down its costs to the range of 228k - 250k gas. This implementation has the same interface as Daimo’s too and passes all their tests too. It is currently deployed on Ethereum’s and Base’s Goerli and Sepolia testnets at 0x00000083Ea3aBb243c4acfDB095DB5aD5A606fc5.
For anyone interested, you can check out the code and tests here:

github.com




GitHub - AmadiMichael/p256-verifier-huff: Hyper-Optimised Secp256r1/P256 Verifier Huff...
Hyper-Optimised Secp256r1/P256 Verifier Huff Implementation

Author: ulerdogan
Date: 2024-01-02T18:46:43.531Z

RIP Update: Last Call Deadline Officially Announced  
The PR which applies the last changes and announces Last Call deadline has been merged. The new Last Call deadline is January 10.

Author: mratsim
Date: 2024-01-09T10:33:33.139Z

There is a push towards multi-proofs in rollups, SGX in particular is a prime candidate:

2FA zk-rollups using SGX - zk-s[nt]arks - Ethereum Research
Twitter space: Multi-proofs for rollups a nice-to-have or a necessity, with Vitalik (Ethereum Foundation), Protolambda (Optimism) and Brecht (Taiko)
Taiko: Why multi-prover matters. SGX as a possible solution.

Having this precompile would solve a big gas cost headache and enable SGX verification without relying on Intel chain of trust.

Author: doganalpaslan
Date: 2024-01-10T22:10:49.078Z

mratsim:

Having this precompile would solve a big gas cost headache and enable SGX verification without relying on Intel chain of trust.


I wasn’t aware of this use case that EIP-7212 could enable and yes, it is obvious that multi prover rollups could use this precompile. Thanks for the contribution!

Author: ulerdogan
Date: 2024-01-16T14:45:23.741Z

Final 
As of this PR, RIP-7212 has reached to the Final status and became the first finalized RIP. Now, it’s guaranteed that there will be no changes in the specs and the proposal is ready to be implemented by any chain.
Please check my reference implementation for go-ethereum:


github.com/ulerdogan/go-ethereum








RIP-7212: Precompile for secp256r1 Curve Support, Reference  Implementation


master ← ulerdogan-secp256r1



          opened 02:24PM - 16 Jan 24 UTC




            ulerdogan
          



+5569
-0






This PR is a reference implementation for the [RIP-7212](https://github.com/ethe…reum/RIPs/blob/master/RIPS/rip-7212.md), (aka [EIP-7212](https://eips.ethereum.org/EIPS/eip-7212)). 

Note: It is not a production ready or official implementation, just shows a reference for possible integrations. Feel free to use/change in your repositories, and reach me out. Including more test cases is strongly recommended.

Author: doganalpaslan
Date: 2024-02-08T10:44:43.387Z

RIP-7212 is live on Polygon Testnet.
You can try it yourself:

gist.github.com


https://gist.github.com/ulerdogan/8f1714895e23a54147fc529ea30517eb
p256verify.sh
RPC="https://polygon-mumbai.blockpi.network/v1/rpc/public"

P256VERIFY="0x0000000000000000000000000000000000000100"

CALLDATA="4cee90eb86eaa050036147a12d49004b6b9c72bd725d39d4785011fe190f0b4da73bd4903f0ce3b639bbbf6e8e80d16931ff4bcf5993d58468e8fb19086e8cac36dbcd03009df8c59286b162af3bd7fcc0450c9aa81be5d10d312af6c66b1d604aebd3099c618202fcfe16ae7770b0c49ab5eadf74b754204a3bb6060e44eff37618b065f9832de4ca6ca971a7a1adc826d0f7c00181a5fb2ddf79ae00b4e10e"

echo "testing RIP-7212 on Mumbai"

cast call --rpc-url ${RPC} ${P256VERIFY} --data ${CALLDATA}







https://twitter.com/ulerdogan/status/1755358331420418134

Author: Holterhus
Date: 2024-02-19T15:51:32.643Z

Hi everyone,
I was wondering if there are any implementation tricks that can programmatically check if RIP-7212 is live within a specific L2. I believe some longer-term ideas were discussed in the RollCall #2.3 meeting that would address this (e.g. progressive precompiles, or a precompile that itself returns information about which precompiles are active on a chain). However, I believe RIP-7212 will be live before some of these.
The best solution I can think of is to hardcode a call to the precompile with a signature that’s already known to be correct, and then the precompile is live iff bytes32(1) is returned. Does this seem like the best implementation that’s currently possible? Preferably it’d be possible to tell if the precompile is live regardless if a signature is valid or not. However, I believe a call to the RIP-7212 precompile with an invalid signature will return no data, which is equivalent to calling an address with no code/precompile, so it’s difficult to distinguish whether the precompile exists or not in this case.

Author: ulerdogan
Date: 2024-02-19T17:00:42.628Z

Hello Riley! Yes, there is no progress on the onchain registry idea. Also, I agree with you that it looks like the most ideal way to understand if precompile exists.

Author: Martin
Date: 2024-03-23T23:55:14.826Z

I understand RIP-7212 is not yet live on the Ethereum Mainnet? Do we expect this to happen soon? Or is there any rough estimate as to when it will be?

Author: ulerdogan
Date: 2024-03-24T10:50:56.439Z

As an RIP, the proposal has not been planned for the Ethereum mainnet yet. It can be considered in the future.

Author: ulerdogan
Date: 2024-03-24T10:57:06.122Z

Integration Update
With the Napoli Hard Fork in the Polygon PoS Chain, RIP-7212 is active on the mainnet. Congrats to the team for being the first to implement an RIP on the mainnet.
Announcement Tweet

Author: EWCunha
Date: 2024-03-28T14:52:42.237Z

Do you guys have a code snippet on how to implement it onchain in Solidity? Thank you

Author: rdubois-crypto
Date: 2024-03-28T17:23:09.899Z

Fastest implementation is here

github.com


rdubois-crypto/FreshCryptoLib/blob/ec7122f20900f9486a7c018d635f69738b14dfc3/solidity/tests/WebAuthn_forge/script/DeployElliptic.s.sol#L18

      
          
          /// @notice Wrap the FCL_ecdsa library in a contract to be able to deploy it
          contract FCL_ecdsa_wrapper {
              function ecdsa_verify(bytes32 message, uint256 r, uint256 s, uint256 Qx, uint256 Qy) external view returns (bool) {
                  return FCL_ecdsa.ecdsa_verify(message, r, s, Qx, Qy);
              }
          }
          
          contract FCL_all_wrapper {
              /* default is EIP7212 precompile as described in https://eips.ethereum.org/EIPS/eip-7212*/
              fallback(bytes calldata input) external returns (bytes memory) {
                  if ((input.length != 160) && (input.length != 180)) {
                      return abi.encodePacked(uint256(0));
                  }
          
                  bytes32 message = bytes32(input[0:32]);
                  uint256 r = uint256(bytes32(input[32:64]));
                  uint256 s = uint256(bytes32(input[64:96]));
                  uint256 Qx = uint256(bytes32(input[96:128]));
                  uint256 Qy = uint256(bytes32(input[128:160]));
                  /* no precomputations */
      
    





Actually i’m still working on it and will push a version around 160K in April which will go to an audit.

Author: rdubois-crypto
Date: 2024-03-28T17:26:10.786Z

You can easily adapt this script to bench extra libraries ONCHAIN (this one demonstrate benching of daimo and FCL). (it is easy to forgot to configure toml effectively, or cancel stack optimization).


github.com


rdubois-crypto/FreshCryptoLib/blob/ec7122f20900f9486a7c018d635f69738b14dfc3/solidity/tests/cast/cast_bench_FCLvsdaimo.sh
#the way to sign the transactions to send 
SIGNER="--ledger" #safe version, open Ethereum application on your ledger, allow blind signing
#$SIGNER="PRIVATE_KEY=<>", unsafe version, using a private key of EOA

#list of RPCs
LINEA_TESTNET=https://rpc.goerli.linea.build
BASESCAN_TESTNET_RPC=https://goerli.base.org 

FCL_ADDRESS=0xE9399D1183a5cf9E14B120875A616b6E2bcB840a
DAIMO_ADDRESS=0xc2b78104907F722DABAc4C69f826a522B2754De4 #Daimo is only testnet is basescan as of 25/10/23

# pick a network and RPC
NETWORK="BASE"
RPC=$BASESCAN_TESTNET_RPC

#pick a seed
SEED=$( echo $RANDOM)
#pick random values for input (testing purpose)
KPRIV=$(cast keccak "1"$SEED)
NONCE=$(cast keccak "2"$SEED)




  This file has been truncated. show original

Author: ulerdogan
Date: 2024-03-28T17:48:50.298Z

Thanks for sharing additional resources @rdubois-crypto!
Also, sharing basic wrapper contract to call the precompile contract.


Function here
    /**
     * @notice Calls the verifier function with given params
     * @param verifier address     - Address of the verifier contract
     * @param hash bytes32         - Signed data hash
     * @param rs bytes32[2]        - Signature array for the r and s values
     * @param pubKey bytes32[2]    - Public key coordinates array for the x and y values
     * @return - bool - Return the success of the verification
     */
    function callVerifier(
        address verifier,
        bytes32 hash,
        bytes32[2] memory rs,
        bytes32[2] memory pubKey
    ) internal view returns (bool) {
        /**
         * Prepare the input format
         * input[  0: 32] = signed data hash
         * input[ 32: 64] = signature r
         * input[ 64: 96] = signature s
         * input[ 96:128] = public key x
         * input[128:160] = public key y
         */
        bytes memory input = abi.encodePacked(hash, rs[0], rs[1], pubKey[0], pubKey[1]);

        // Make a call to verify the signature
        (bool success, bytes memory data) = verifier.staticcall(input);

        uint256 returnValue;
        // Return true if the call was successful and the return value is 1
        if (success && data.length > 0) {
            assembly {
                returnValue := mload(add(data, 0x20))
            }
            return returnValue == 1;
        }

        // Otherwise return false for the unsucessful calls and invalid signatures
        return false;
    }

Author: poojaranjan
Date: 2024-04-24T14:29:35.064Z

Check out the interesting conversation with @ulerdogan on the present Signature scheme, special Elliptic Curves & a deep dive inside EOA while providing the overview of RIP7212 on PEEPanEIP

Author: NathanBSC
Date: 2024-05-10T06:54:14.448Z

Hi ulerdogan
I’m a developer from BSC.
BSC is part of the EVM ecosystem, and the client is based on a fork of go-ethereum, and will continue to provide feedback on any bugs found.
I hope when setting these EIPs, we can consider BSC: the BSC precompile addresses 0x100~0x105 are already in use,
Can the RIP-related precompile addresses use a different address range? For example, starting from 0x1000.

Author: mratsim
Date: 2024-05-10T09:02:16.562Z

The RIP is already deployed on several L2s.
See Polygon: PIP-27: Precompiled for secp256r1 Curve Support - #7 by ulerdogan - Canonical PIPs - Polygon Community Forum
See Arbitrum: AIP: Support RIP-7212 for Account Abstraction Wallets - #13 by cliffton.eth - Proposals - Arbitrum
See zkSync: zkSync Protocol Upgrade v24: New precompiles, more blobs, Validiums, and more. · zkSync-Community-Hub/zksync-developers · Discussion #519 · GitHub
I don’t think it’s reasonable to change it now and disrupt all the code that was deployed to take advantage of this new EIP and prove its utility for next Ethereum upgrade.
Furthermore, that reserved RIP range is to enshrine a range for experimentation for L2s so it’s fine for EVM forks to also use this knowing Ethereum L1s changes won’t reuse that range. See also: RollCall Breakout #3: Precompiles and the RIP Process

Author: ulerdogan
Date: 2024-05-10T11:14:50.618Z

@mratsim thanks for the explanations!
Hi @NathanBSC, isn’t 0x1000 range also blocked by these? Also, I couldn’t find what blocks the 0x100 range. In case of misunderstanding: 0x100 → 0x0000000000000000000000000000000000000100

Author: destroyersrt
Date: 2024-05-10T11:41:27.784Z

A couple of questions regarding the P256 Verifier precompile.


There was some discussion about adding a progressive precompile from Daimo where their precompile address was 0xc2b78104907F722DABAc4C69f826a522B2754De4 but the deployment of precompile was at address 0x100. And similarly the FreshCryptoLib’s implementation address was 0xE9399D1183a5cf9E14B120875A616b6E2bcB840a. So, If I am building something using Daimo or FreshCryptoLib implementation, I will to create a wrapper that fallbacks to 0x100 address, right?


@rdubois-crypto does the current state of FreshCryptoLib implementation use the 0x100 address? Also, when are you expecting a complete audited implementation?


If I want to directly call the precompile from solidity, I will have to do address(100).staticcall({params}) or is there any wrapper like ecrecover?

Author: rdubois-crypto
Date: 2024-05-10T14:10:53.880Z

Answer to first question is “yes”. (Solving third ?).
Considering the second question :
FCL is not gonna be audited, but has been scrutinized by Base cryptographer’s team. We believe that 7212 is amazing at the current moment, but we also believe that it is too limited to introduce only one curve, while a generic precompile can be introduced for (quasi) no extra cost, leading to several use cases:



RIP-7696 : generic Double Scalar Multiplication (DSM) for all curves RIPs


    This proposal creates two precompiled contracts that perform a double point multiplication (DSM) and sum then over any elliptic curve  given p, a,b curve parameters. 
This operation consists in computing the value uP+vQ, u and v being scalars, P and Q being points. 
We managed to implement generic DSM in full solidity with a lower cost than previous implementations (FCL, Daimo, p256-verifier-huff). Such genericity will enable curves such as Ed25519 and Babyjujub (with the use of isogeny we will …
  


Using RIP7696 you can emulate P256, Ed25519, starkcurve, babyjujub, palla, vesta, …
We are now pushing 7696, which can emulate 7212 as a specific case.


As a progressive compile in solidity for a lower cost (160K) than FCL(200K) or Daimo (330K).
You will find an example of all wychproof vectors assessment here:
crypto-lib/test/libSCL_ecdsa.t.sol at audit-cryptoexperts · get-smooth/crypto-lib · GitHub


As a circuit/node implementation: Optimizations are independant of the language (just pure algorithmic), so it is transposable to any circuit/node implementation (of course it requires some work). We are working with a L2 on a tradeoff rn.


RIP7696 solidity implementation is going through 2 independant audits. The first is running right now, ending end of June, before a second one starting 1st July.

Author: dcposch
Date: 2024-05-19T03:35:30.652Z

I think that RIP-7212 has a unfortunate flaw–as specified after this update from two weeks ago and deployed on Polygon PoS: it now returns empty data for an invalid signature.
Why is this an issue?
It means there’s no clean way to implement a fallback
Contracts cannot distinguish between (invalid signature) and (7212 not deployed). On a chain without the precompile, calling 0x100 with any calldata will return (success=true, return value=0x).
On a chain with the precompile, an invalid signature will return exactly the same.
You can still implement a fallback, but the fallback contract will run on invalid signatures even on chains that have the precompile. In practice, this means that invalid signatures will often fail with an out-of-gas instead of a descriptive revert message.
This was changed after Final
Both EIP-7212 and RIP-7212 originally specified that the return value should always be 32 bytes.
Here’s my reconstruction of what happened:

2023 Summer - EIP-7212 created, specifying 32-byte (uint) return value.
2023 Aug - we (Daimo) implement a fallback contract matching the spec.
2023 Oct - zkSync implements 7212, also following the spec: returns uint 0 or 1.
2023 Nov - PR in Polygon to implement 7212. This had a bug, where invalid signatures would return empty data. This behavior deviates from zkSync, Daimo, & EIP–but wasn’t caught at the time.
2023 Dec 23 - RIP-7212 created. It specifies a 32-byte return value, same as the EIP it replaced.
2024 Jan 8 - RIP-7212 marked Final
2024 Mar 21 - PIP-27 / RIP-7212 deployed on Polygon PoS, with invalid signatures returning empty data. Bug is now in production.
2024 Apr 25 - RIP-7212 spec changed retroactively to match the deployed implementation. Instead of Output data: 32 bytes of result data and error, it now specifies a 32-byte uint(1) for valid signatures, and empty data for invalid.

I’m not sure if this is worth fixing, given that it’s now live on Polygon, but it warrants a retrospective on how we can avoid this kind of outcome in the future.
I propose a rule that no new precompile, going forward, should return empty data, since this makes a clean fallback implementation impossible.
Finally, I’d challenge the community to come up with a good process to verify new RIP implementations before they ship. I don’t think this story would’ve happened with an EIP: L1 client implementations have a lot of careful eyes on them. RIPs, by contrast, will land in production on the currently-fastest-shipping L2. This can happen in just a few weeks, as it did here. Once in production, if there are any discrepancies, it’s more feasible to update the spec than the implementation, locking them in forever.

Author: NathanBSC
Date: 2024-05-19T04:25:27.176Z

ulerdogan:

@mratsim thanks for the explanations!


@mratsim thanks for the explanations

Author: dcposch
Date: 2024-05-19T04:55:23.716Z

NathanBSC:

bsc/core/vm/contracts.go at master · bnb-chain/bsc · GitHub


Luckily, it looks like 0x100 is not already in use in BSC. However, the address with decimal value 100 (0x64) is in use.

Author: ulerdogan
Date: 2024-05-19T23:49:14.473Z

Considering some comments received after the Final status, I completely agree with the feedback that the RIP process should proceed in a more actively participated way by ecosystem members. Otherwise, I think that the correct state of the RIP, updated with the last PR (to just fix misunderstandings), is correct in terms of the rollup implementations and discussions in the Rollcalls. Additionally, it was mentioned that a registry could be developed as a solution to the problem you mentioned. So, I think the proposal has not been changed retroactively to adapt to Polygon PoS Chain implementation (also ready with the same specs in other rollups).

Author: NathanBSC
Date: 2024-05-20T07:37:06.786Z

my mistake
no conflicts with bsc, for bsc addresses 100~105 has been taked, not 0x100~0x105
https://github.com/bnb-chain/bsc/blob/master/core/vm/contracts.go#L242

Author: NathanBSC
Date: 2024-05-20T07:43:09.502Z

yes, you are right, thx.
we will advance this EIP more quickly.

Author: flcl
Date: 2024-06-11T09:35:54.800Z

In addition to the data result, a call to the precompile returns a boolean, which is always true in the go implementation. Should it be mentioned in the RIP? Alternatively it might return false if length of the input was not 160 or the components of the input were out of range.

Author: ulerdogan
Date: 2024-06-11T12:46:52.610Z

Hey! The given reference implementation in Go and the Final RIP spec are compatible. Unfortunately, as a Final proposal that has already been implemented by some rollups, it’s not open to change.
Given spec:
# 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.

Author: flcl
Date: 2024-06-11T13:50:34.048Z

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.

Author: ulerdogan
Date: 2024-07-11T11:16:18.109Z

Integration Updates


ZKsync Era implements RIP-7212 on mainnet: Announcement Tweet


Optimism ecosystem implements RIP-7212 on mainnet: Announcement Tweet


OpenZeppelin implements RIP-7212 by this PR: Implement P256 verification via RIP-7212 precompile with Solidity fallback #4881.


Congrats to all teams!

Author: ulerdogan
Date: 2024-07-15T18:04:33.460Z

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

Author: EGreg
Date: 2024-07-19T17:00:30.000Z

Realistically, at this point, when will it come out on Ethereum?
It works on Polygon, BSC and elsewhere

Author: ulerdogan
Date: 2024-07-19T22:03:14.705Z

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

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.

Author: rmeissner
Date: 2024-09-12T14:47:10.916Z

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.

Author: ulerdogan
Date: 2024-09-12T17:03:44.264Z

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



ENS DAO Governance Forum – 28 Aug 24




Public Goods RFP Proposal: P256 precompile support in the EVM




🏛️ Public Goods





PG Discussion




Project Scope: P256 EVM Testing Update—c. @ulerdogan 08.25.24  We need a test writer to implement Ethereum spec tests and fixtures for RIP-7212 in the upcoming Pectra hardfork. Mario Vega (EF Testing Team) reviewed their repository and example...

Author: abcoathup
Date: 2024-09-13T02:32:53.207Z

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

Author: ulerdogan
Date: 2024-09-13T08:45:48.072Z

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

Author: rmeissner
Date: 2024-09-13T09:11:59.317Z

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.

Author: abcoathup
Date: 2024-09-13T10:19:15.457Z

ulerdogan:

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


I am not an EIP editor, I am an associate (who assigns numbers. )
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.

Author: estmcmxci
Date: 2024-09-13T18:39:40.530Z

rmeissner:

Even with a split it seems that there is a tendency not to include 7212 (see here)


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



 ulerdogan:

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


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.

Author: wminshew
Date: 2025-01-29T07:13:41.887Z

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

Author: Amxx
Date: 2025-04-02T11:22:44.482Z

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

Author: rdubois-crypto
Date: 2025-04-02T18:09:42.572Z

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

Author: ulerdogan
Date: 2025-04-10T10:38:02.695Z

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.

Author: Amxx
Date: 2025-04-10T11:04:53.277Z

ulerdogan:

But as a Final RIP, it’s too late for a direct change without a new RIP.


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.