# General Grant Proposal
* **Project:** P256-Circom
## Project Overview :page_facing_up:
### Overview
This proposal intends to implement an account abstraction wallet using WebAuthn validation in order to make Ethereum transaction validation secure and user friendly. WebAuthn authentication will be added to the validateUserOp function of a wallet contract using Circom for gas efficiency. Our efforts are related to PSE’s ongoing project to implement WebAuthn in Halo2. Circom allows for readable circuits, which can help onboard users and developers who are newer to ZK-apps.
WebAuthn is a user-friendly authentication tool. Utilizing WebAuthn verification in account abstraction wallets removes the need for users to remember their wallet seed phrases while being able to sign transactions with simple biometric verification. Furthermore, a Circom implementation opens doors for developers as well, thanks to the readable nature of Circom code. Developers may be inspired to integrate with or build on top of our WebAuthn circuit, or may use our P256 ECDSA circuits for other authentication algorithms that are incompatible with the secp256k1 curve.
### Short Rationale
P256 / WebAuthn unlocks new powerful interactions like FaceID & TouchId to approve transactions therefore improving Ethereum's UX, Security and convenience supporting adoption efforts.
### Project Details
Provide as much detail as possible about the project's expected final state.
* An overview of the technology stack to be used
* Documentation of core components, protocols, architecture etc. to be deployed
* PoC/MVP or other relevant prior work or research on the topic
## Project Details
#### Objectives
We plan to implement a smart contract wallet that validates a WebAuthn ES256 attestation within a zero-knowledge SNARK verifier.
Specifically, the expected outputs of the research are as follows:
* WebAuthn verifier in circom with benchmarks
* Smart contract wallet deployed on testnet
* Web or mobile interface that prompts WebAuthn attestation and interacts with smart contract wallet
* Writeup on circuit performance benchmarks, security considerations, and future steps
Performance of the zero-knowledge circuits will be benchmarked using these metrics.
* Prover time on client (browser, mobile devices, server-side relayers)
* Proof size in MB
* Gas cost of verification function
#### Circom-ECDSA Circuits
[WebAuthn authentication](https://www.w3.org/TR/webauthn-2/#sctn-verifying-assertion) has 22 steps in total, including SHA-256 and secp256r1 (also known as P256) verifyECDSA operations. Since existing circuit libraries in circom for ECDSA signatures (see https://github.com/0xPARC/circom-ecdsa) do not use the P256 curve and instead use the secp256k1 curve, all the parameters, group operations, and BigInt arithmetic on P256 must be added.
Current circom-ecdsa circuits have a variety of strategies to deal with BigInt arithmetic in circom (see https://0xparc.org/blog/zk-ecdsa-2 and https://zkresear.ch/t/circom-ecdsa-optimizations/24?curius=1954). The main challenge is ensuring signals are no larger than the 254-bit registers allowed in current zkSNARK systems.
In addition to recomputing the parameters used for group operations (e.g. adding points, which depends on the new coefficients of the P256 curve), we need to alter several strategies for dealing with BigInt arithmetic in order to complete the ECDSA circuits. For example, we can no longer immediately reduce our 10-register input to 4 64-bit registers in the P256PrimeReduce10Registerscircuit, which is used in the key CheckCubicModPIsZero circuit. This is because shifting by 4 registers mod P (where P is the size of the 256-bit base field of the curve) causes us to multiply registers by a factor that is too large (on the order of 224 bits) when taken mod P, thus overflowing them.
#### Full WebAuthn Verification
The following describes the end-to-end flow of an Ethereum transaction using WebAuthn verification. On a trusted client (browser, mobile device, native app), the user generates a proof with the credential signature, origin, and rpID as private witnesses, and the challenge (containing the Ethereum sender, to, and calldata) and credential public key as public inputs. The proof is then wrapped in the signature field into the UserOperation struct and sent to the alternative mempool, where it is directed via the EntryPoint contract to our smart contract account. Our smart contract wallet will implement the following function to verify the UserOperation:
```
contract WebAuthnAccount is IAccount {
function validateUserOp
(UserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds)
external returns (uint256 validationData) {
// Require that function is called from EntryPoint contract.
_requireFromEntryPoint();
// Run steps in WebAuthn verification, as described in
// https://www.w3.org/TR/webauthn-2/#sctn-rp-operations.
validationData = _validateWebAuthnSignature(userOp, userOpHash);
// Update nonce to prevent replay
if (userOp.initCode.length == 0) {
_validateAndUpdateNonce(userOp);
}
// Send missing funds to EntryPoint
_payPrefund(missingAccountFunds);
}
// ...
}
```
## Team :busts_in_silhouette:
### Team members
* Names of team members
* Email
* Telegram handle
* Discord handle
### Team Website
* https://<your_domain>
### Team's experience
Please describe the team's relevant experience. Some links would be useful.
## Development Roadmap :nut_and_bolt:
### Overview
**Total Estimated Duration:** ??? months
**Full-time equivalent (FTE):**
### Milestone 1: P-256 ECDSA in Circom
**Estimated Duration:** 1 month
**FTE:** 0.15 (less than part-time, 6 hrs/week)
| Number | Deliverable | Specification |
| -------- | -------- | -------- |
| 0a. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can generate a proof, verify a proof, and modify circuit parameters.|
| 0b. | Testing Guide | The code will have proper unit test and integration test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests.|
| 1. | P-256 Curve Parameters | Add new P-256 curve in circom-ecdsa repo using the necessary curve parameters. Investigate alternative ECDSA libraries like spartan-ecdsa. |
**Notes:** Janabel last person working on circuits, challenges with prime field. Working on 40-80% complete.
**Strategy:**
### Milestone 2: WebAuthn circuits in Circom
**Estimated Duration:** ???
**FTE:**
**Estimated delivery date:**
| Number | Deliverable | Specification |
| ------ | ----------- | ------------- |
| 0a. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can generate a proof, verify a proof, and modify circuit paramters. |
| 0b. | Testing Guide | The code will have proper unit test and integration test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests |
| 1. | P-256 ECDSAVerify integration | Add new P-256 ECDSA circuit to [p256-circom.](https://github.com/privacy-scaling-explorations/p256-circom) |
| 2. | Finish WebAuthn checks in circuit | Add steps 11, 13, 14, 15, 21 to [p256-circom](https://github.com/privacy-scaling-explorations/p256-circom). |
| 3. | Solidity / EVM Verifier | Script using [snarkjs](https://github.com/iden3/snarkjs) library to generate a Verifier.sol contract with a function verify(uint[] memory input, Proof memory proof) to allow for proof verification on-chain. |
Notes: We believe Emma might have finished this except for the P256 integration. Need some testing. Generating and writing everything on circuit. It still uses wrong ECDSA curve (missing replacing it with P256)
### Milestone 3: Full-stack Demo and Writeup
**Estimated Duration:** ???
**FTE:** 1 FTE
**Estimated delivery date:**
| Number | Deliverable | Specification |
| ------ | --------------------------- |:-------------- |
| 0a. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can initialize the full-stack application, including the frontend, smart contract deployment, and proving server. |
| 0b. | Testing Guide | The code will have proper unit test and integration test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests |
| 0c. | Deployments | All components of the grant will be deployed and available for end users to use. This includes contracts deployed onto Ethereum mainnet and web applications (frontend and proving server) accessible via any mobile or desktop browser via HTTP(S). |
| 1. | Frontend App | Design, build, and deploy a Next.js, mobile-friendly web app for users to generate smart contract wallets and sign transactions using their P-256 biometric signature. It will connect to the proving server (Milestone 1) and P256 account contracts (Milestone 2). The frontend will be deployed to a domain such as p256wallet.org. |
| 2. | Audit Feedback | Fixes will be made to all P256 Circom circuits, Ethereum smart contracts, and web code that is audited. This will be conducted through a correspondence on Discord. |
| 3. | Web and Contract Deployment | All proving servers and audited contracts will be deployed using Render and Foundry Forge, respectively.|
| 4. | Writeup | A detailed blog post containing an explanation of the (1) motivation, (2) development steps, (3) benchmarks, and (4) takeaways of this project will be published to the PSE blog and zkresear.ch for the ecosystem to review, discuss, and tinker. |
Notes: probably a few hiccups getting to work end-to-end. (Richard cna work with AA, etc.) Most of Halo2 demo implementation could be reused, just need to swap the address of the verifier.
### Milestone 4: Batch Proving - Aggregating P256 Signatures
**Estimated Duration:** ???
**FTE:** 1 FTE
**Estimated delivery date:**
| Number | Deliverable | Specification |
| ------ | ----------- |:-------------------------------------------------------------------- |
| 1. | Exploration | Explore and list different aggregation avenues to prove P256 groth16 [NEBRA](https://publish.obsidian.md/shumo/Nebra/Working+With+NEBRA), [Batch ECDSA](https://github.com/puma314/batch-ecdsa), [Spartan FRI](https://github.com/DanTehrani/spartan-fri/), [Halo2 Aggregation](), Folding on Circom, |
| 2. | Implementation | Integrate it to Milestone 3 results |
**Notes:**
- A user or a set of user who have signed WebAuthn challenges, we cna generate a proof that all signatures have been signed correctly. Aggregating them at the Bundler level. Lowering gas fees by batching them 100 signatures. <- This approach couldbe different as current ECDSA circuit doesn't share the signature just the proof.
- WebuAthn proof and gets sent to an aggregation service
SpartanFRI: the team who made SpartanECDSA, they wrote a paradigm of large client side proofs (large proving time) and aggregate them in a proof of smaller size, slower time (server) and then post onchain. After generating SpartanECDSA proofs on browser, have a circuit that takes Spartan proofs and with FRI commitment scheme it's cheap to verify onchain.
**Goal:** explore the X amount of methods, and evaluate them by Proving Time, Cost on Change, latency, bundlers, architecutre, etc.
**Strategy:** separate this milestone further.
- Stuff we can work on now: Halo2 batched ECDSA approahc, Halo2 "for loop", Halo2 Folding (Sangria*, Origami*), Nova-Scotia for Circom
- Stuff we can work on later: Batched ECDSA, NEBRA
### Milestone 5: Increase Security by Domain-specific Signatures
"One nuance about webauthn is that it does not ask the user what to sign. It just signs what ever the app gives. This might have a tricky UX where a user who signs a tx in a malicious app. Has all their funds moved. The good news is the domain name is signed so we can have permissions per domain name. Like uniswap.com can do some stuff. For smart wallet there seems to be no action items yet. I expect that to surface during the webauthn work. But be aware in mind we might have to add this type of permissions some where.""
**Notes:** couple of ways we could approach this:
1. Verify "relying party ID" matches "host name we send proof froom" within the circuit (need to check if Circom is doing it vs Halo2).
A bit challenging because it still requires a trusted extension, standard singing for WebAuthn as WebAuthn doesn't even exposes this info.
Seems this is **exploratory/evaluation work**: how can we prevent proofs being reused, challenges being reused, making sure what the app is requesting to be signed it's actually that and not any other action.
### Milestone 6: Integration WAX - Proof as Verification Gateway
Integrate P256 circom verifier as a verification gateway to WAX. Work with internal WAX PSE team to scope this work.
Deliver modules that suit a single adaptation to the Verification Gateway
**Notes:** we've previously met with WAX team (John). It was mainly an exploration of where we were. Now it's a good time to kickstart this exploration again.
**Goal:** adding this as a 2FA/option on WAX.
## Additional Information :heavy_plus_sign:
WebAuthn circuits are mostly finished besides integration with the P256 circom-ECDSA circuits.
https://github.com/zkwebauthn/webauthn-circom
Raw parameters have all been changed to the P256 curve in the circom-ECDSA circuits
#### Relevant Code Repos
* https://github.com/privacy-scaling-explorations/p256-circom
* https://github.com/zkwebauthn/webauthn-circom
* https://github.com/janabel/circom-ecdsa-p256
#### Initial Strategy
* Tyler: circom ownership (Milestone 1, 2, 3)
* Richard: a few aggregation methods (Milestone 4) and WAX integration for Halo2 (Milestone 6)
* Nullity: a couple of aggrgation methods (Milestone 4)
* Once others are finished, also available (Milestone 5)
Sign in with Wallet
Connect another wallet