Public Goods RFP Proposal: P256 precompile support in the EVM

I wouldn’t say its necessary, it just opens the door for developers to create novel applications that would be prohibitively expensive using the EVM.

Absolutely. My point was that previously we believed that only Arbitrum Orbit could offer the secp256r1 elliptic curve but as a result of this standardisation work any chain that implements this precompile could. RIPs are optional so it is not necessarily the case that all L2s will implement the precompile.

This is something we would like to do. Once we have some clarity on direction we will make a forum post :slight_smile:

Sure. Arbitrum have this super cool repo that links to some examples. Some that stand out are below:


It’s related to k1 vs r1 topics that we were following… r1 is more compatible with web2 services using new passkeys in browsers… *coz Chrome rejected k1 in webcrypto api.

Bug 29005 - Add support for secp256k1 curve · Issue #82 · w3c/webcrypto · GitHub

1 Like

I think the word “advanced” may have been used wrongly here which led to Marcus getting confused. Both ed25519 and secp256r1 curves are basic cryptography and not much different than secp256k1 at all; only difference is in the sampling of prime generator point(s) and consequently in available divisor subgroups (for BLS and ZKP). In terms of implementation, security or complexity, all are equivalent. Like @0xc0de4c0ffee mentioned, only real issue is compatibility. Web2 systems like using r1 whereas Satoshi led crypto on the path of k1 (for reasons that I do not agree with mathematically; r1 is negligibly more pre-quantum secure than k1 in my opinion). Other minor difference is that the r1 verifier doesn’t spit out public key for comparison but instead only relies on checking the validity of a given public key (I guess to avoid pubkey fingerprint rainbow-ing).

tl;dr It is not advanced cryptography, only a matter of web2 vs web3 standardisation; r1 and k1 are principally the same.

1 Like

Hey, I know a bit about cryptography myself! I actually drafted an ELI5 on @ulerdogan’s EIP, which led me down the rabbit hole of elliptic curve cryptography. Thanks, for elaborating on this though, it was very helpful!


For interested parties see this tweet for some further updates.


1 Like

That’s great! Thanks for the update. I also read on the Ethereum Magicians forum that the RIP has been deployed on several L2s including Polygon, Arbitrum, and ZKSync.

I think the precompile is only needed on L1 because the gas-less DNSSEC needs to be verified on L1. The “ENS Chain” is about moving the storage to cheaper chain but the verification still needs to happen on L1 so I don’t think there’s much point moving the gas-less DNSSEC (for the gas-less DNSSEC, the DNS itself is the storage) part to the ENS chain.

I understand. Would you suggest that the Ethereum community reconsider implementing the p256 precompile on L1? AFAIK, AllCoreDevs resolved that the approach would be more efficient on L2s.

Source: EIP-7212: Precompiled for secp256r1 Curve Support - #69 by ulerdogan - Core EIPs - Fellowship of Ethereum Magicians

1 Like

I think it’s a good idea

1 Like

As of ACDE#186, EIP/RIP-7212, has been added to the CFI (Considered for Inclusion) list for Pectra hard fork. It means that in the next meetings, there will be a final decision about implementing the proposal by the client teams. There are some blockers about how an RIP can be implemented into L1, but I think we are in a good stage for adoption. Also, we will have the proposal implemented in Polygon, zkSync, Optimism, and Arbitrum soon.

It’ll be valuable to see why ENS supports this proposal to make it accepted for L1.

1 Like

That’s great to hear! It would be awesome if any of the ENS Service Providers could allocate some of their development resources towards testing the precompile for an ENS-specific use case. I highly encourage this!

If the community deems it impactful, it would be great to have a use case demoed during an upcoming ACD call, preferably within the next few months. This would make a strong case for adding the precompile to the next hard fork.

1 Like