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
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.
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.
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!
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.
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.
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.
If ENS builds a proprietary chain, would implementing RIP-7212 be useful? If it extends to an existing chain, would it be preferable for that chain to implement the p256 precompile?
I don’t think implementing p256 precompile on ENS chain is useful unless we migrate the gasless DNSSEC to the ENS chain (which I don’t think we have plan for it).
I never got the impression that building its own L2 chain was an option on the cards. If the decision is to go with one of these open source stacks then ‘ENS Chain’ would naturally inherit the precompile.
This would be super cool. For us its a bandwidth issue. I wouldn’t just limit this to service providers - its an interesting challenge for any passionate dev.
Yeah, I am just brainstorming on what a goal or direction for passionate developers to tackle the issue might look like. I look forward to continuing this discussion!
During the last months, the proposal, as RIP-7212, has been implemented by a big part of L2 ecosystem, including the major rollups, and the rest of them are actively working on implementing it.
For the L1 case, which is also interested by ENS, including the proposal in the Pectra upgrade is being discussed in the last ACDE calls. In ACDE#192, it’s aimed to finalize the decision in the next one, ACDE#193. If including this proposal in the L1 is still valuable for the ENS, please share it with the ACDE community.
Hi Ulaş, It was nice to hear on ENS Radio last week that Clave Wallet will offer its web3 usernames stored on ZKsync. For those who may have missed it, I will link it here.
To keep the community in the loop, could you please broadly outline the risks and rewards of including the secp256r1 precompile in the upcoming Pectra hard fork, with regard to ENSv2, according to the specification in RIP-7212?
I remember there being some debate on signature verification vs. recovery. Have you addressed this during ACDE calls, and if so, what concerns have been raised?
Current concerns are related to how crowded Pectra is and doubts about adding a new proposal. While all the client teams look in favor of adding RIP-7212, they are not very clear for Pectra. I don’t see any risk for the L1, also shared my opinions here. For the ENSv2, I believe it will depend on where and how the verification mechanism for ENSv2 is designed.
As @clowes.eth pointed out, if ENSv2 is deployed on an L2 solution that has already implemented RIP-7212, then it will inherit the precompile.
How would the ENS Protocol benefit from a p256 precompile on L1? If any participant in this thread can illustrate a strong case for it, I would be happy to advocate for its inclusion in the Pectra upgrade during the upcoming ACDE call.
Keep in mind that I am neither a developer nor an ENS Labs member, so my advocacy would be limited to my role as a DAO steward and, more generally, as a member of the community.
