Context

On June 13th, 2023, Nick.eth, the Lead Developer of the Ethereum Name Service (ENS), requested that the ENS DAO Public Goods Working Group draft and publish a Request for Proposal (RFP) to have a secp256r1 precompile added to a future EVM hardfork. The ENS is a distributed, open, and extensible naming system based on the Ethereum blockchain.

According to Article III of the ENS DAO Constitution, income generated to the ENS treasury is first used to ensure the long-term viability of ENS. Any surplus funds not deemed necessary to fulfill this primary objective are allocated by the DAO's governance body towards supporting other public goods within the web3 ecosystem.

Nick.eth's request to fund the implementation of a P256 precompile is aligned with Article III of the ENS DAO constitution. The Public Goods Working Group has been tasked to carry out this initiative on behalf of ENS. As an active contributor to the ENS DAO since its inception in 2021, I took the initiative to draft the RFP on behalf of the Public Goods Working Group. The draft RFP is available to review here.

In this article, I review the RFP process, the importance of adding a P256 precompile to the EVM, and the Public Goods Working Group's role and the overall process in implementing a protocol-level upgrade to Ethereum. I also review progress that has already been made by a handful of resourceful developers, including EIP-7212, which outlines the addition of the P256 precompile to the EVM.

The RFP Process

According to the ENS DAO's governance processes, the primary mechanism by which the DAO executes tasks is via a Request for Proposal (RFP). It is a document that organizations like ENS DAO use to solicit proposals for a specific project. RFPs provide a framework used in various industries, including government agencies, businesses, and non-profit organizations as a formal process to gather information, evaluate submissions objectively, and make informed decisions when selecting a winning bid.

The purpose of this RFP is to outline the project's details, requirements, and objectives, as well as provide instructions on how to submit proposals. Additionally, I've included the project scope, timeline, selection criteria, and other considerations when preparing to submit. Since only elected stewards of the Public Goods Working Group have access to the DAO's bursar, I have intentionally omitted the Budget Requirements from the RFP draft. Instead, I encourage stewards to review the RFP and consider the budget on their own, in preparation for the Q3/Q4 budget request.

Once the RFP is reviewed and approved, the working group stewards will create a thread on the ENS DAO forum to field submissions. I believe that the Public Goods Working Group should adopt this RFP once all concerns and considerations have been settled. Proceeding with this approach will help give legitimacy to an EVM implementation of a P256 curve elliptical. As I will explain below, the work involves a high degree of care, attention, and advocacy by the Public Goods Working Group, as it involves drafting and implementing a protocol-level upgrade to Ethereum via an Ethereum Improvement Proposal (EIP).

Why Adding a P256 Precompile is Important

Currently, Ethereum transactions rely on the secp256k1 elliptic curve cryptography (ECC) algorithm for key generation, digital signatures, and verification. ECC is a form of public key cryptography that addresses the discrete logarithm problem (DLP) by utilizing elliptic curves. It is this mathematical challenge that forms the basis of ECC's security.

The size of the elliptic curve, measured by the total number of discrete integer pairs satisfying the curve equation, determines the difficulty of the problem.

However, 'real-world' crypto proofs instead use other curves such as RSA, SHA256, and in particular, secp256r1 as the elliptic curve of choice in most applications. Omitting the secp256r1 curve elliptical from the EVM was a design choice.

At first, I rationalized that the choice to implement secp256k1 (Koblitz) curves, rather than secp256r1 (pseudorandom) curves was motivated by a drive to keep computational costs down as the cost of solving increasingly difficult computations would make the EVM prohibitively expensive for new users. This is generally true.

Additionally, however, I realized that the decision may have also been motivated by concerns that the National Institute of Standards and Technology (NIST) standard elliptical curve (P256) had a vulnerability that could be exploited as a potential backdoor. Vitalik himself had written about this potential vulnerability.

In a 2013 article in Bitcoin Magazine, Vitalik describes how Satoshi (Bitcoin) chose the "right elliptic curve," implementing the Koblitz curve, which has more simple parameter values. The Pseudorandom curve, instead, necessitates additional parameters specified by an algorithm from a particular seed.

This explains why more computational resources would be needed when implementing the pseudorandom curve instead of the Koblitz curve. He then speculates that the seed can be deliberately chosen by the NIST under the influence of the National Security Agency (NSA) to exploit the curve in a way only they would know how.

Probably, Vitalik grew more suspicious of the NSA, especially after Edward Snowden's leaked memos that the NSA indeed had a history of manipulating the standards-setting process, which raised concerns about the widespread use of compromised encryption systems. Nevertheless, the NIST has denied that any such backdoor exists. Beyond any rumors, no concrete evidence has surfaced that implicates the NSA in any bad faith act.

Ironically, this choice has had its detriment to mass adoption. Most "normies" find it difficult to understand the concept of creating a seed phrase and storing private keys, making for a cumbersome and tiring user experience.

Recent implementations such as Account Abstraction (EIP-4337) enable users to interact with Ethereum without the need for seed phrases or private keys. Moreover, any signature scheme can be implemented to authenticate transactions, including well-established methods such as WebAuthn/ FIDO 2, which are used in more familiar UX such as Face ID (Apple), Android fingerprint recognition, etc.

Despite this, these methods rely on the secp256r1 curve, to which Ethereum is incompatible. In short, adding a P256 precompile to the EVM is an essential step towards mass adoption.

Protocol-level Upgrades to Ethereum are Rigorous

Last October, I participated in the Ethereum Roadmap Protocol Session during Devcon VI in Bogotá, Colombia. Over the course of three hours, I witnessed Ethereum Core Developers discuss and debate upcoming improvement proposals to Ethereum, including EIP-4844, 1153, and 3975, which have finally been shortlisted for the forthcoming Dencun Network Upgrade sometime before Devconnect in November this year. I provided notes for this session, and they've since been incorporated for use by the Ethereum Magicians in their Protocol Roadmap Session recap.

This should give the Public Goods Working Group an idea of how much time (and rigor) is necessary to develop an EIP to implement the P256 EVM precompile into a future hardfork. Not only does it require a high level of technical ability, but a proactive approach in advocacy, community engagement, and public communication. The stewards should consider how they will support the EIP in review and community management as their involvement and endorsement will send a positive signal to the Ethereum Developer community overall.

EIPs contain technical specifications for proposed protocol improvements and act as a consensus mechanism for Ethereum overall. An EIP should primarily provide a concise technical specification with its motivation and overview of implementation. The author is responsible for reaching consensus within the community and documenting alternative opinions. This is why framing the request as an RFP makes sense because it forces the author to think through the requirements in a way that aligns with Ethereum's core values and principals (selflessly).

Furthermore, building consensus towards the implementation of a P256 precompile requires the acknowledgment of trust that has been eroded by past controversy over the use of potentially compromised encryption systems. In a 2013 Wired article by Kim Zetter, they explain how two Microsoft employees had suggested that a new encryption standard by NIST had a vulnerability that could be exploited as a backdoor. The article attempts to corroborate their claim by citing Snowden's leaked memos.

These concerns need to be addressed by the DAO, the implementation team, and the Ethereum community overall.

EIP-7212

Luckily, significant progress has already been made by a small team of developers who have previously placed as finalists in a 2023 ETH Global Hackathon — Scaling Ethereum. We describe their project as an ERC-4337 compatible OP Stack improvement that uses signatures abstracted with Apple Secure Enclave, which allows users to create and use non-custodial wallets without the use of seed phrases.

Since the Apple Secure Enclave only supports the secp256r1 curve, a custom recovery or verification algorithm is needed to verify Apple Enclave signatures in smart contracts, as the existing ecrecover precompile for secp256k1 is not compatible. Their team had built custom solutions for implementing Apple signatures on the blockchain. They added a secp256r1 precompile verifier to initiate and verify the Secure Enclave's public key, reducing gas costs and providing chain-native support.

Ulaş Erdoğan and Doğan Alpaslan, authors of EIP-7212, have created a Pull Request that has since merged with the EIP GitHub Repo. They've introduced their EIP to the Ethereum Magicians forum in late June (2023) and have since garnered considerable attention and scrutiny from the community. They've also shared their progress on the ENS DAO Forum and have been superbly communicative, proactive, and responsible, having presented the EIP during an EIP Editing Office Hour.

From my perspective, Erdoğan & Alpaslan are qualified to take on the role of implementing the P256 precompile in preparation for the next EVM hardfork, probably after the Dencun Network Upgrade.

Conclusion

In conclusion, the addition of a P256 precompile to the Ethereum Virtual Machine (EVM) is an essential step towards mass adoption. The Public Goods Working Group has been tasked with drafting a Request for Proposal (RFP) to have the precompile added to a future EVM hardfork.

The RFP process is a formal and objective way to evaluate submissions and make informed decisions. Implementing a protocol-level upgrade to Ethereum via an Ethereum Improvement Proposal (EIP) requires a high level of technical ability, community engagement, and public communication.

The stewards of the Public Goods Working Group should consider how they will support the EIP in review and community management as their involvement is essentially a high-level endorsement and will send a positive signal to the Ethereum Developer community overall.

It's worth considering that progress has already been made by a small team of developers in creating an ERC-4337 compatible OP Stack improvement that uses signatures abstracted with Apple Secure Enclave. The team has added a secp256r1 precompile verifier to initiate and verify the Secure Enclave's public key, reducing gas costs and providing chain-native support.

This same team are authors of EIP-7212 and have created a Pull Request that has since merged with the EIP GitHub Repo; they've been proactive in presenting the EIP during an EIP Editing Office Hour. They could be qualified to implement the P256 precompile in preparation for the next EVM hardfork, probably after the Dencun Network Upgrade.

Overall, the implementation of the P256 precompile will require a rigorous and proactive approach from the Public Goods Working Group, the team of developers, and the Ethereum community. Addressing concerns about trust and compromised encryption systems is critical for building consensus towards the implementation of the precompile.

However, the benefits of adding the P256 precompile to the EVM are significant, and the effort to implement it in a future hardfork is well worth it for the long-term viability and mass adoption of Ethereum.

Resources:

• A Closer Look at Ethereum Signatures (Hackernoon, 2018)

• Unexpected Ways in Which Bitcoin Dodged Some Cryptographic Bullets (Bitcoin Magazine, 2013)

• How a Crypto 'Backdoor' Pitted the Tech World Against the NSA (Wired, 2013)

• Speeding up elliptic computations for Ethereum Account Abstraction (Ledger, 2023)

• EIP-7212: Precompiled for secp256r1 Curve Support (Ethereum Magicians Forum, 2018)