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