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.
I understand. In that case, we can refer to the milestones that have been included in the draft RFP.
The major milestones include:
a. Month 1: Standards and Specifications
Define the standards and specifications for the secp256r1 precompile.
Document the requirements and expected behavior of the implementation.
b. Months 2-3: Code Development
Implement the secp256r1 precompile functionality within the EVM codebase.
Thoroughly test the code to ensure correctness and reliability.
Iteratively refine and improve the implementation based on feedback and testing.
c. Months 4-6: PRs and Community Engagement
Create PRs for major Ethereum clients, proposing the inclusion of the secp256r1 precompile.
Engage with the Ethereum community, present the proposal, and gather feedback.
Advocate for the inclusion of the secp256r1 precompile in the next hard-fork at All Core Devs and other relevant meetings.
*funds may be paid out in tranches, according to when milestones are met.
—
Seems like they have already met the first milestone, given that their EIP has been merged with the EIP Repo. I would surmise that they are well on their way to accomplishing the second milestone. Are there any updates to share @ulerdogan?
I’m requesting that the Public Goods stewards review the draft RFP and provide feedback — they should suggest a maximum budget for the RFP since they have access to the Working Group bursar. If they find it meets their standards, then they should adopt the RFP officially, according to the RFP Process outlined therein.
Thanks, great document and milestones! Let me explain our current status:
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.
In this stage, we have assigned tasks in our team to implement the EIP for different clients such as Erigon, Reth, Nethermind, and Ethereum.js. While we are working on these implementations, we will be collecting some reviews.
I think the milestones are great, but I believe that we will reach the “c” goals earlier than 4-6 months.
@estmcmxci Thank you for putting the draft together. Are you available to introduce it on the next PG call on July 11th, 12pm EST?
@ulerdogan Do you have other feedback on these milestones, does this look reasonable? @estmcmxci It might be helpful to have someone technical (not subject to applying for the RFP) help craft these.
I think the draft is quite fine. 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. These can enhance the reviews to reach a better “Final” version and spread the EIP to convince the community that the improvement is valuable and should be included with a hard fork. I believe that showing ENSDAO’s contribution is a big step to attract attention and support.
I want to share my current updates and request reviews.
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.
Lastly, I would love to hear any updates if there are from your call today @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
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!
No worries, you’re more than welcome to share about EIP-7212 whenever you’re available!
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.
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.
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.
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
—
@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?
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.
Pre-research and EIP discussions
Reaching individuals and projects for reviews
Moving the EIP to the Final stage