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!
