All TLDs will remain on L1 in ENSv2. The current plan is for DNSSEC claiming of 2LDs to also remain on L1 - the reasoning being that you only claim your name onchain if you need the performance and security improvements over the CCIP-Read based approach that is the default.
A P256 precompile would be way more useful for ENS on L1 than it is on L2. We don’t currently have a plan to use P256 on L2.
The current status of the implementation into the L1 is in limbo. As mentioned by timbeiko.eth on the latest ACDE EL meeting:
“No decision on including EIP/RIP-7212. To improve the likelihood of the EIP’s inclusion, its champions should extend testing coverage to match other currently included Pectra EIPs.”
Because the ENSv2 plan includes DNSSEC claiming for 2LDs on L1, and since onchain DNSSEC requires the addition of the P256 precompile to the EVM, I believe there is good reason for ENS Labs to inquire about this matter. At the very least, they should provide guidance on testing to @ulerdogan’s developer team in this repository:
I am making an appeal to the @PublicGoods_Stewards to consider including a section in their forthcoming Working Group calls to investigate further and see how we can bring more attention to the matter, ensuring the successful inclusion of P256 in the next EVM hard fork.
Update—c. @ulerdogan 08.25.24
We need a test writer to implement Ethereum spec tests and fixtures for RIP-7212 in the upcoming Pectra hardfork. Mario Vega (EF Testing Team) reviewed their repository and example tests, but progress has been slow due to Ulaş’s limited bandwidth.
They’ve implemented Geth status for erecover, but basic test implementation is still challenging. Running RIP-7212 tests requires launching a custom EVM version, which is complex.
We plan to coordinate with Mario for further guidance. Ulaş has limited experience with complex projects in Python (Pytest) and the testing frameworks needed to generate test fixtures for Ethereum execution clients and the Ethereum/hive framework.
Time is running out, with only a few months left—the Pectra upgrade is scheduled for Q1 2025.
Need: A qualified test writer to develop and implement tests for the successful integration of the P256 EVM into the upcoming Ethereum Pectra hardfork. This role could involve collaboration with Ulaş, who can support but not lead broader testing efforts.
Qualification: Proficiency in Python and Pytest, with a strong understanding of Ethereum’s Execution Layer and EVM.
Responsibilities:
Suggestion to @PublicGoods_Stewards: Structure a bounty incentive for a qualified and interested individual to complete the test writing process.
—
@simona_pop, I would like to workshop this in upcoming Working Group calls. I believe it’s a worthwhile cause that would bring tremendous value not only to ENS but to the ‘New Internet’ overall.
Great to touch on this in the PG call just now - all thoughts and ideas welcome 
Update: Ahead of my lightning talk at Devcon, where I’ll explore the implementation of P256 in enterprise-level organizations and its potential to broaden Ethereum’s reach, I’ve prepared an update on the current status of P256 in the EVM and how it enables ‘Unified Identity Frameworks’ with WebAuthn, DNSSEC, and ENS.
Update: On November 12, 2024, NIST published its initial public draft of Internal Report 8547, titled Transition to Post-Quantum Cryptography Standards. This document outlines a comprehensive roadmap for phasing out quantum-vulnerable cryptographic algorithms, such as ECDSA, by 2030 in favor of quantum-resistant alternatives.
The report underscores the urgency to begin transitioning toward post-quantum cryptography to safeguard systems against emerging quantum threats.
As ENS plans its own zkEVM Layer 2 implementation, which will likely rely on Ethereum’s current cryptographic standards, these developments could significantly impact design decisions, particularly for future-proofing domain registration and transaction validation systems.
With quantum-safe cryptographic transitions on the horizon, it is critical for ENS to evaluate how these shifts might influence the longevity and security of its zkEVM L2 architecture.
Questions for ENS to Consider:
—
Both WebAuthn and DNSSEC are vulnerable to quantum computing threats due to their reliance on ECDSA. Organizations managing these technologies will need to migrate to quantum-resistant algorithms as they become available.
I believe this is a worthwhile area of research for ENS to pursue. In light of this news, I am curious, @ulerdogan, about the sentiment of Ethereum Core Developers regarding the implementation of P256 and whether there might be growing momentum toward designing applications with post-quantum cryptography standards in mind.
In light of Sundar Pichai’s recent announcement of Willow, their state-of-the-art quantum computing chip, it is imminent that L1 will move away from Secp256r1, since a sufficiently powerful quantum computer can trivially solve the discrete logarithm problem.
This shift is crucial not only for maintaining the integrity and security of transactions but also for ensuring compatibility with evolving standards in protocols like DNSSEC and WebAuthn, which are also moving towards quantum-resistant solutions.
Should the focus instead be on adopting interim solutions during the transition from pre-quantum to post-quantum cryptographic standards—for instance, research into AA for Namechain?
I’m concerned that advocating for integrating P256 into the L1 has become a red herring.