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: