The Secp256r1 elliptic curve is extensively utilized in web2 infrastructures such as Secure Enclaves, Ubikeys, DSL, TSS, among others. However, its onchain verification remains cost-prohibitive. Although EIP 7212 proposes a financially viable and secure method for its verification, its implementation confronts a classic causality dilemma. To integrate EIP 7212 into the mainnet, a cheap verification method must be found.

Ledger’s current Solidity implementation can verify the signature at a consumption rate of 200k gas without precomputation. And 70k with precomputation, although the initial deployment costs 3M gas for the precomputation.

These results, though promising, are insufficient. Further examination of Optimism’s specifications reveals potential outcomes if a dominant wallet in the Optimism ecosystem incorporated the secp256r1 curve.

Optimistic Rollups incur two distinct expenses: one for security (calldata) paid to Ethereum (or the DA layer) and another for execution goes to the rollup provider for the limited block space. At present, the L2 gas price is negligible due to the absence of competition for L2 block inclusion. However, any surge in demand would elevate this cost. Given that Optimism’s gas limit is set at 5M, the TPS would be restricted to 25, contingent upon the verifier operating without precomputations. (I know that EIP 1559 works differently but i just didn’t want to dive into technical details)

Solutions:

EIP 7212: Achieving consensus on new precompiles at L1 is arduous, necessitating significant social coordination and communal endorsement. Highlighting the EIP's utility could expedite its mainnet integration. Nevertheless, this EIP cannot curtail the calldata expense; reductions can only be achieved via Zero Knowledge Proofs (ZKP) or signature aggregation.

Zero Knowledge: ZKP empowers us to validate intricate computations via specialized mathematical algorithms, ensuring computational integrity and potentially reducing both calldata and gas expenses. Currently, Risc0 Bonsai facilitates the conversion of Starks to Snarks, with a verification cost of 280k gas for the Risc0 Bonsai proofs.

https://sepolia.etherscan.io/tx/0x9db0680f9164e045cf1cbf6f6c3a1afff204e2dc6c5af9582fb2ba89ef3e2b12#eventlog

A conceptual transaction flow utilizng ZKP for 4337 and a webauthN-based wallet would look like:

1. Users authenticate messages with their keys.

2. Sends these signed messages to the prover

3. ZK provers aggregate these transactions, subsequently batching them to the public mempool.

4. Bundlers retrieve and collectively verifies user operations - sends a transaction to Entrypoint Contract.

5. Transactions are being verified onchain with utilizing ZKP.

However, our team has opted not to integrate this for our product due to the following reasons:

• ZK provers introduce centralization risks, potentially enabling user censorship given the challenge of creating a Stark proof on user devices.

• ZK provers induce additional latency, complicating gas estimations and potentially resulting in user latency challenges, especially if cost efficiency mandates a minimum transaction batch size.

• Implementing it to the Bundler side can be a blocker since it adds extra complexity to the gas estimation.

• The rapid confirmation time advantage of the rollup is compromised.

• Proofs must be unique to the transaction, necessitating both public input and calldata to ensure transaction-specific proofs which increases the calldata and gas cost of the ZKP. (I’m not a ZKP expert, this is just my understanding from Bonsai Docs.)

It's worth noting that Risc0 Bonsai presents a promising tool for intricate computations, and despite being in its developmental stages, its Developer Experience (DevEX) is commendable.

It should be acknowledged that this manuscript may contain inaccuracies and has been composed primarily for self educational purposes.

The Secp256r1 elliptic curve is extensively utilized in web2 infrastructures such as Secure Enclaves, Ubikeys, DSL, TSS, among others. However, its onchain verification remains cost-prohibitive. Although EIP 7212 proposes a financially viable and secure method for its verification, its implementation confronts a classic causality dilemma. To integrate EIP 7212 into the mainnet, a cheap verification method must be found.

Ledger’s current Solidity implementation can verify the signature at a consumption rate of 200k gas without precomputation. And 70k with precomputation, although the initial deployment costs 3M gas for the precomputation.

These results, though promising, are insufficient. Further examination of Optimism’s specifications reveals potential outcomes if a dominant wallet in the Optimism ecosystem incorporated the secp256r1 curve.

Optimistic Rollups incur two distinct expenses: one for security (calldata) paid to Ethereum (or the DA layer) and another for execution goes to the rollup provider for the limited block space. At present, the L2 gas price is negligible due to the absence of competition for L2 block inclusion. However, any surge in demand would elevate this cost. Given that Optimism’s gas limit is set at 5M, the TPS would be restricted to 25, contingent upon the verifier operating without precomputations. (I know that EIP 1559 works differently but i just didn’t want to dive into technical details)

Solutions:

EIP 7212: Achieving consensus on new precompiles at L1 is arduous, necessitating significant social coordination and communal endorsement. Highlighting the EIP's utility could expedite its mainnet integration. Nevertheless, this EIP cannot curtail the calldata expense; reductions can only be achieved via Zero Knowledge Proofs (ZKP) or signature aggregation.

Zero Knowledge: ZKP empowers us to validate intricate computations via specialized mathematical algorithms, ensuring computational integrity and potentially reducing both calldata and gas expenses. Currently, Risc0 Bonsai facilitates the conversion of Starks to Snarks, with a verification cost of 280k gas for the Risc0 Bonsai proofs.

https://sepolia.etherscan.io/tx/0x9db0680f9164e045cf1cbf6f6c3a1afff204e2dc6c5af9582fb2ba89ef3e2b12#eventlog

A conceptual transaction flow utilizng ZKP for 4337 and a webauthN-based wallet would look like:

1. Users authenticate messages with their keys.

2. Sends these signed messages to the prover

3. ZK provers aggregate these transactions, subsequently batching them to the public mempool.

4. Bundlers retrieve and collectively verifies user operations - sends a transaction to Entrypoint Contract.

5. Transactions are being verified onchain with utilizing ZKP.

However, our team has opted not to integrate this for our product due to the following reasons:

• ZK provers introduce centralization risks, potentially enabling user censorship given the challenge of creating a Stark proof on user devices.

• ZK provers induce additional latency, complicating gas estimations and potentially resulting in user latency challenges, especially if cost efficiency mandates a minimum transaction batch size.

• Implementing it to the Bundler side can be a blocker since it adds extra complexity to the gas estimation.

• The rapid confirmation time advantage of the rollup is compromised.

• Proofs must be unique to the transaction, necessitating both public input and calldata to ensure transaction-specific proofs which increases the calldata and gas cost of the ZKP. (I’m not a ZKP expert, this is just my understanding from Bonsai Docs.)

It's worth noting that Risc0 Bonsai presents a promising tool for intricate computations, and despite being in its developmental stages, its Developer Experience (DevEX) is commendable.

It should be acknowledged that this manuscript may contain inaccuracies and has been composed primarily for self educational purposes.