One of the major barriers to onchain DNSSEC, along with many other potential projects such as web authentication integration, email verification, and other tasks that rely on verifying ‘real world’ crypto proofs, is the EVM’s limited support for cryptographic primitives.
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.
An EVM precompile for secp256r1 would not be particularly technically complex, and would open the door to a variety of useful applications, both connected to ENS and independent of it.
I’d like to propose that the Public Goods WG put out an RFP for getting a secp256r1 precompile added to a future EVM hardfork. At a guess, this will be in the region of 6 months’ work for one contributor, and involve writing standards, authoring PRs for all the major clients to add the functionality, and advocating for its inclusion at All Core Devs and other meetings. The ideal respondent would have experience with all of this, or failing that some experience writing EIPs and expertise in the languages common execution clients are written in.
I support this proposal and believe that it should be a priority for the Public Goods working group to see through to its execution and implementation. Let’s address the RFP Proposal during this week’s Public Goods working group call. @Coltron.eth, could we add this to the agenda, please?
I like where this is going. Since this is a pretty specific ask without many options for creative solutions maybe we can incentivize the work to be done with a bounty?
According to this Pull Request, all EIPs for the forthcoming Dencun Network Upgrade have been shortlisted. EIPs included in this upgrade, such as EIP-4844, 1153, 3975, have been in development since at least Devcon last October. This should give us an idea of how much time (and rigor) is necessary to develop an EIP to implement P256 EVM precompile in to a future hardfork.
This initiative will require a high degree of care and attention by the Public Goods working group, as EIP meetings are rigorous — not to mention drafting, code implementation, etc.
We should first identify a technical writer to help draft and review the RFP. I think that it’s best that we draw from the ENS community, more specifically, someone who has already merged a PR to the ENS Github repository.
After we publish the RFP, we should get the word out within the Ethereum Magicians forum and present this opportunity to their community. One of the incoming Public Goods stewards, or an appointed representative, should task themselves with leading this initiative on behalf of the DAO.
Once a respondent is selected, the stewards should partner with them as advocates during important meetings, such as the AllCoreDevs meetings, to gather support for the proposed EIP.
To start, I’ve drafted an RFP for review. I encourage the @PublicGoods_Stewards to have a look and discuss the matter during the Working Group calls.
It will be outlined in a Request for Proposal (RFP) to the PG Working Group Stewards. If approved, then it will move to the proposal stage where any person can submit their plan to complete the requested work along with a bid or requested compensation that it would require to complete the work. The RFP must specify the method of which it is decided, by DAO wide vote or by Stewards discretion. For smaller projects, stewards discretion is recommended.
Essentially what @estmcmxci said—Just worded differently.
I want to share our current progress in preparing an EIP with the same scope. We have been working on this EIP, which presents the secp256r1 elliptic curve signature verifier with precompiled contract support for the EVM chains. Also, we have prepared a reference implementation in geth and are planning to work on other client implementations in future steps. We are planning to publish EIP by creating PRs next week, but we can postpone the process a bit to get more feedback from the ENSDAO.
We think that many hardware and software products use this curve, and making it simple for these signatures to be verified on-chain will greatly enhance the user and developer experience, especially by allowing signing transactions in the account abstraction wallets.
I am sharing our current draft and the implementation, which have not been published yet. Now, we are working on contacting the other parties to improve the proposal. Any support and feedback from you for the proposal is appreciated. Then, we can apply to build with the RFP too.
Nice. As I’m not well studied in computer science / software development, I wouldn’t be in the best position to discern whether or not your geth implementation satisfies @nick.eth query; but I would be curious to know how far along you are in developing implementations for other execution clients such as Nethermind, Besu, etc.
I’d imagine that before proceeding to bring this to attention of the greater Ethereum community for inclusion in a future EVM hard fork, reference implementations for all execution clients should be prepared/audited well in advance. Further, these requirements should be included within the RFP’s Scope of Work — provided that EL implementations necessitate that EIPs are compatible across participating clients.
I cannot technically attest to its functionality, however, granted that it is functional, I would be happy to support and advocate for this EIP on behalf of ENS DAO. The Public Goods working group should act and seek help in drafting the more technical aspects of the RFP. I do not agree that framing this work as a bounty is the path forward. I don’t think that this kind of work would be an attractive option for mercenaries, anyway.
We started with geth to create a reference because it is the most used EL client in different chains. We did not see other client implementations as urgent as the EIP process takes a long time and generally the client developments are being discussed at the EL ACD meetings, then developed by the client teams, but we have put in our roadmap for the future dates after publishing the EIP to contribute the implementations in different clients, whether or not accepted for the L1.
We would be happy to assume responsibility for our other implementations and set clear deadlines, depending on their involvement in the RFP. We see that this improvement on the EVM is valuable and are working to present it in the best way while we are using it in our project, and we want to standardize it!
One of the things I recall from the Merch Store RFP and the Generative Avatar Art RFP was a delay, potentially due to lack of responses.
Would it make sense for this RFP to include an initial budget for something like a DevRel that would be selected by the Stewards to recruit an adequate and qualified pool of talent to respond to the RFP?
Sure. I believe that we should include all execution clients in the RFP. It’s important to consider code audits as well, have you thought about how to approach this?
I am wondering if @ulerdogan and their team will take on the role of DevRel themselves? In my opinion, software developers should focus on executing and shipping code. They needn’t encumber themselves with the task of advocating, persuading, championing the EIP to the Ethereum community — unless it is of their own volition. Instead, this role should be tasked to someone who is willing to build rapport with the community at large and communicate on behalf of the dev team.
Nice! Do you plan to attend the EIP Editing Office Hour next week? I think it could be a good first opportunity to start gathering feedback / introducing the EIP.
I am not sure about the audit processes of the EIPs or whether this process is included in the proposal part. Do you know any previous references that we can follow? I had thought the implementations are being developed / reviewed in the ACD calls by the core devs. If it’s needed we can get offers from different audit firms and include them in the RFP.
I or one of my teammates would love to take on these responsibilities if the role is appropriate for the RFP applicants. Even if I am the software dev in the EIP, I do take on these kinds of DevRel roles too.
Clients aren’t generally audited in the way smart contracts are audited. For consensus changes like this, generally a cross-client test suite is developed and tested against all implementing clients.
I think Nick gave us the answer we were both looking for!
Awesome!
Okay, nice. I’ll jump on that call, too!
–
As for the RFP, I think we’ve built enough context within the scope of this thread to draft and publish it. Once again, I don’t think its necessary to set up a bounty as the opclave team are already taking the initiative to publish an EIP and present it during ACD calls.
Even though I have already drafted an RFP for review, I’m wondering now whether it is necessary, considering that it appears that @ulerdogan’s existing implementation may already meet the criteria for selection. Nice job on having your merge request accepted, by the way!
Why not issue a retroactive grant instead? It seems like a more straightforward approach at the moment. Once working group budgets are passed in the upcoming term, I encourage @PublicGoods_Stewards to consider this option as well.
Hmm, yeah I see that! Might just need to give them a poke. I’ll follow the convo on the repo and check to see if the issue has been resolved. If it’s been more than a week, I would suggest shooting the admin a message on the eip-editors channel in the Ethereum Cat Herders Discord and/or alternatively bring up the issue at the next EIPIP meeting.
