Public Goods RFP Proposal: P256 precompile support in the EVM

[estmcmxci]

@Coltron.eth

@estmcmxci Thank you for putting the draft together. Are you available to introduce it on the next PG call on July 11th, 12pm EST?

Yes, I’ll make sure to to attend the call.

@ulerdogan

It might be good to clarify in the RFP which client implementations will be included. Also, if it’s appropriate for the RFP structure, it would be nice to add some emphasis on how ENSDAO will support the EIP in review and community engagement.

Thanks for this feedback; it is valuable and we should consider how to incorporate it into the RFP.

[ulerdogan]

Hi,

I want to share my current updates and request reviews.

@ulerdogan

I have opened a new PR to move the EIP to the Review status

The PR to move the EIP has merged!

Now, we are looking for reviewers who are interested in giving feedback and share comments in the FEM post. Also, inviting @nick.eth as you shared that this improvement is useful for the EVM and opened this discussion. Your review and comments are valuable for us and appreciated.

@estmcmxci

@Coltron.eth

Are you available to introduce it on the next PG call on July 11th, 12pm EST?

Lastly, I would love to hear any updates if there are from your call today @estmcmxci.

Thanks!

[Coltron.eth]

@ulerdogan There was some confusion around the call time. We’re going to hold it on Thursday this week.

I’ve tagged both of you in the agenda posted!

[estmcmxci]

Thanks! I’ve published an article that explains the RFP Process, the PG working group’s role in stewarding an EIP implementation, and the importance of adding a P256 precompile to the EVM. Public Goods: P256 Precompile Support — marcus

[ulerdogan]

@estmcmxci

Public Goods: P256 Precompile Support — marcus

Hey, I’ve just read your article. It perfectly explains the process and needs. Thanks!

@Coltron.eth

@ulerdogan There was some confusion around the call time. We’re going to hold it on Thursday this week.

Also, I am sorry, I couldn’t catch the PG Call. I had a flight that was delayed a bit.

[estmcmxci]

Hello! Thank you. To be frank, it was quite a challenge for me to write this as I don’t have a background in computer science or mathematics for that matter. I’m quite enthusiastic about the subject, however, and it felt fulfilling to break down this process in a way that could make sense to the average bear.

Really incredible work that you’ve done so far — excited for you and your team to continue the discussion with the greater Ethereum community as this precompile is an absolute must!

@ulerdogan

Also, I am sorry, I couldn’t catch the PG Call. I had a flight that was delayed a bit.

No worries, you’re more than welcome to share about EIP-7212 whenever you’re available!

[AvsA]

@ulerdogan

I have opened a new PR to move the EIP to the Review status as we think that the content is clear and it should be discussed in a wider ecosystem. I am planning to reach out to some client developers, other projects that use the r1 curve, researchers interested in the subject, and more to hear more feedback before taking the EIP to the ACD calls. I will keep the EIP in the Review status until a few weeks after the ETH CC event because I believe that I can reach more reviewers at the event.

Congrats Ulerdogan. This is very important work and there’s no grant big enough that won’t be worth this if we can get merged. I’d strongly support the PG group to create a grant structure: an ongoing stream (once they have verified you have the technical capability to work on it) and a few big payouts in milestones: when first client makes an implementation, when it’s scheduled for inclusion and when it’s merged.

[estmcmxci]

Great to see the continued momentum on this proposal. To review, the Ethylene Studio team introduced EIP-7212 to the Ethereum community on June 22, 2023 and has since had their PR merged with Ethereum’s Github Repo. On July 27th, 2023, Public Goods Stewards + @estmcmxci met with Ethylene Studio to discuss EIP-7212, its implementation, and how the Public Goods working group may support this initiative. Per our last communication, Ethylene have built Go and Rust reference implementations of the precompile, but are in need of a Java developer for other client implementations.

On August 17, 2023, the Ethylene team presented their proposal during an ACD (All Core Devs) call. During the presentation, developers raised several questions, one of the most critical being whether to opt for a recovery or verification mechanism for the precompiled contract. While some developers advocate for verification, others suggest aligning with the ecrecover interface. This issue has emerged as a key point of discussion for the inclusion of EIP-7212 in the next EVM hard fork.

It’s worth noting that Layer 2 solutions have expressed significant interest in this feature. Specifically, ZKsync and Aztec are already in the process of implementing the p256 precompile (correct me if I am mistaken). The ACD call also endorsed a Layer 2-first approach, emphasizing that Ethylene is concentrating on implementing this precompiled contract in certain rollup solutions. Among the Layer 2 solutions currently under consideration for this implementation are ZK Sync, Fuel, Aztec, and Gnosis.

Review: P256 Precompile Support

P256 Precompile Summary

General Overview

• Current Limitations: EVM’s limited support for cryptographic primitives.
• Desired Integration: Enable secp256r1 elliptic curve, widely adopted outside of crypto.
• Use Cases: Enhance ENS, enable web authentication, email verification, and more.
• Proposal: Ethylene Studio proposed EIP-7212 on June 22, 2023.

Development and Discussion

• Technical Process: Involves implementations in different programming languages, feedback from core developers, and proposal preparation for EVM hard fork inclusion.
• Public Goods Discussion: On July 27th, 2023, Public Goods Stewards + estmcmxci.eth discussed EIP-7212 with Ethylene Studio.
• Current State: Ethylene Studio has Go and Rust implementations but needs a Java developer for other client implementations.
• Community Feedback: Ethylene Studio is requesting further comments from key figures.

Decision Making

• Review and Approval: The proposal needs core Ethereum developer review and approval to move forward.
• Visibility and Advocacy: Increasing visibility and advocacy is key.
• ACD Call: On August 17, 2023, the proposal was presented; discussion included recovery vs. verification for the precompiled contract.

Other Interested Parties

• Layer 2 Interest: L2 solutions like ZKsync and Aztec are interested.
• L2-First Approach: Recommended during the ACD call; focus is on some rollup implementations.
• L2s Under Consideration: ZK Sync, Fuel, Aztec, Gnosis.

Scope of Work

• Code Development: Modify major Ethereum client codebases for secp256r1 support.
• Pull Requests: Create PRs proposing secp256r1 precompile functionality.
• Community Engagement: Advocate for inclusion at AllCoreDevs and engage the Ethereum community.

Timelines

Preliminary Works (April - May 2023)

• Pre-research and EIP discussions
• Preparing the EIP draft
• Preparing the reference implementation on the geth

Public Intros (June 2023)

• Publishing the EIP as draft and initiating the FEM discussion
• Opening PR for the geth implementation and getting reviews

Reviews (July 2023)

• Moving the EIP to the Review stage
• Starting to collect reviews

Community Involvement (August - September 2023)

• Reaching individuals and projects for reviews
• Joining client team discussions for reviews
• Attending ACD calls to present the EIP
• Building other client implementations (Reth, Ethereumjs, Nethermind, Erigon, Besu)

Integration Discussions (October 2023)

• Moving the EIP to the Final stage
• Sharing example smart contract codes using the EIP
• Communicating with rollups and side chains for integrations
• Considering proposing in the next hard fork for L1

—

@AvsA

I’d strongly support the PG group to create a grant structure: an ongoing stream (once they have verified you have the technical capability to work on it) and a few big payouts in milestones: when first client makes an implementation, when it’s scheduled for inclusion and when it’s merged.

@ulerdogan seems like there is no consensus for an ideal implementation of the precompiled contract in terms of applying verification or recovery, so, before developing client implementations (first milestone), it’s important that devs agree on a best approach. What can be done to help the Ethereum community reach a consensus in order for a first implementation in go-ethereum to be built?

[nick.eth]

@estmcmxci

On August 17, 2023, the Ethylene team presented their proposal during an ACD (All Core Devs) call. During the presentation, developers raised several questions, one of the most critical being whether to opt for a recovery or verification mechanism for the precompiled contract. While some developers advocate for verification, others suggest aligning with the ecrecover interface. This issue has emerged as a key point of discussion for the inclusion of EIP-7212 in the next EVM hard fork.

This seems like a straightforward choice, surely? If you implement recovery, users can trivially use that to implement verification - but not vice-versa. Since recovery is strictly the more expressive of the two, it’s the one that makes the most sense to implement.

[nuel]

Awesome, however i noticed this seems to be similar to EIP7212.

[ulerdogan]

Hey, yes! We are running both processes.

[estmcmxci]

If it is a question of cost effectiveness, implementing erecovery makes point multiplication over secp256k1 relatively cheap (Dubois. R - Speeding up elliptic computations for Ethereum Account Abstraction), however I am not sure if the same applies for an r1 curve implementation, although I would have to assume so based on my limited understanding of cryptography. The argument that verification method is preferred within the r1 scheme instead is questionable. For example, Besu docs indicate support for public key recovery:

“The public key recovery from the ECDSA signature is very useful in bandwidth-constrained or storage-constrained environments (such as blockchain systems), when transmission or storage of the public keys cannot be afforded.”

While Apple’s Public Developer Documentation does not explicitly state that it uses ECDSA with recovery, some members of the Ethereum Magician community also believe it’s a straightforward task to adjust the code. This would switch the authenticator’s output from the standard ECDSA to the ‘ECDSA with recovery’ version. That being said, since core developers suggested an L2 first approach, their preference may ultimately set a path dependency on which method becomes standardized as an opcode.

Note: I am not an expert cryptographer, just a passionate / involved member of this community so please do take everything I say with a grain of salt, I am still learning!

[estmcmxci]

@nick.eth

Currently the EVM supports ECDSA secp256k1, RSA, SHA256, and Keccak256. Of these, only RSA and SHA256 are widely used outside crypto; in particular most applications have settled on secp256r1 (also known as P256) as the elliptic curve of choice.

Now that RIP-7212 is live on Polygon and coming soon to other EVM compatible L2s like OP, ZkSync, and Kakarot, has this development enabled the Labs team to further explore options for integrating this technology into the ENS roadmap?

I am aware that @clowes.eth and @Premm.eth from Unruggable have been developing a proof of concept for an ENS Chain — might implementing RIP-7212 be of relevance here?

I would also love to hear from @ulerdogan about their thoughts on RIP-7212’s potential utility for ENS.

[clowes.eth]

Hi @estmcmxci ,

Thanks for the tag.
Your blog post provides valuable context. Thanks for that.

In the context of our research into ‘ENS Chain’, Arbitrum Orbit has Stylus (and its associated EVM+) which allows utilisation of advanced cryptography. This was an interesting differentiator in our mind.

The addition of the secp256r1 precompile would open the door to doing similar interesting things on other implementing L2 chains. In the context of ENS things like fingerprint registrations come to mind.

It’s definitely something we will keep an eye on.

Really appreciative of all the work you’ve done on this @ulerdogan

[estmcmxci]

Hey Clowes.eth — that’s awesome to hear! Thanks for the update. If you don’t mind my asking, why is it necessary to use advanced cryptography in an L2? The secp256r1 precompile is live, and I think it’d be worth considering in a roadmap for an ‘ENS Chain’. It would be a massive innovation (imho) if users could register their ENS using their biometric data.

I’d love to stay informed about your research; do you have a newsletter or blog page that I can sign up for? Thank you.

[NameSys]

@clowes.eth

which allows utilisation of advanced cryptography

I am very curious about what sort of advanced cryptography is referred to here. Can you please elaborate? Thank you

[clowes.eth]

@estmcmxci

If you don’t mind my asking, why is it necessary to use advanced cryptography in an L2?

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.

@estmcmxci

The secp256r1 precompile is live, and I think it’d be worth considering in a roadmap for an ‘ENS Chain’. It would be a massive innovation (imho) if users could register their ENS using their biometric data.

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.

@estmcmxci

I’d love to stay informed about your research; do you have a newsletter or blog page that I can sign up for?

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

@NameSys

I am very curious about what sort of advanced cryptography is referred to here. Can you please elaborate? Thank you

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

• GitHub - jake-nyquist/stylus-p256-example: examples of a c p.256 signature verification implemented in arbitrum stylus. This is secp256r1
• GitHub - LimeChain/stylus-benchmark: Repostory for benchmarking Stylus vs EVM contracts outlines some benchmarks for ED25519 verify.
• GitHub - rauljordan/stylus-blst verification of Ethereum BLS signatures onchain
• GitHub - supernovahs/zk-sunade: Groth16 verifier on Arbitrum Stylus

[0xc0de4c0ffee]

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

[NameSys]

@clowes.eth

@estmcmxci

If you don’t mind my asking, why is it necessary to use advanced cryptography in an L2?

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.

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.

[estmcmxci]

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!