EIP-7212: Precompiled for secp256r1 Curve Support

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