Secp256r1 & Smart Contract Wallet

This topic is to discuss the proposal submitted by @zkzoomer
Please see below for the details of the proposal and discussion.

08th July, 2024
Current status: Under Consideration.
Opened for community discussion on : 08th July, 2024.

Secp256r1 Smart Contract Wallet

This proposal aims to implement a smart contract wallet on Mina that verifies transactions signed using the secp256r1 elliptic curve.

Proposal Overview

The Problem

Perhaps the greatest hurdle for new users onboarding to web3 applications is having to deal with their private keys. While great progress has been made in the infrastructure around it, the reality is the vast majority of us do not know how or simply do not want to deal with private keys.

And yet, we use them every day when we operate with our smartphones, sometimes without even realizing. The built-in security chips in our devices (like Apple’s Secure Enclave or Android’s Keystore system) allow us to safely perform cryptographic operations while ensuring the private key never leaves the device. The results is a much more convenient and intuitive user experience.

The reason why this built-in chip cannot be used to sign transactions in web3 comes down to cryptography, more specifically the choice of curve. While secp256r1 has reached mass adoption as the standard in the vast majority of consumer-facing applications (as is the case with these built-in security chips), this is largely not true for the web3 world.

In the case of Bitcoin and Ethereum, the choice of the secp256k1 curve over secp256r1 stemmed from concerns about a potential backdoor introduced on the latter by the NSA. This has arguably been counterproductive in bringing more users to the space. In the case of Mina, the choice of the Pasta Curves makes it more practical for proof recursion.

As a result of this curve mismatch, as far as the web3 space is concerned, it is not possible to directly use the cryptography and hardware built into consumer devices. The key pair generated by these built-in chips cannot natively sign Ethereum or Mina transactions, forcing users to create another key pair using different software that is completely new to them, resulting in a much more challenging onboarding process.

Proposed Solution

The Ethereum ecosystem has already started tackling this problem. The introduction of EIP-4337 enables account abstraction, avoiding the need for consensus-layer protocol changes. Users can sign transactions using their built-in chips on their smartphone devices, as the smart contract wallet can have arbitrary verification logic. Additionally, the proposed EIP-7212 would add a precompiled contract that performs signature verification in the secp256r1 curve.

Unfortunately, the use of a smart contract wallet that verifies secp256r1 signatures results in higher transaction costs, due to having to process additional non-native logic: an additional ~330k gas per signature. This has limited the use of these account abstraction features to rollups, which are only starting to be used now.

In the case of Mina, no native account abstraction or smart contract wallets that can perform these operations exist to this day. The main advantage of enabling such features is that, unlike other blockchains, the fixed fee model of Mina means that the additional logic would result in no additional cost to the end user (barring the increase in proving time).

Potential Impact and Applications

Arguably the best way to onboard users into the space will be via applications that consumers will use simply because they are better, without even having to know that crypto is involved.

A great recent example of such applications is Daimo, a non-custodial wallet enabling worldwide stablecoin payments in a reliable, secure, and very intuitive way: making use of these built-in chips and ERC-4337 contract accounts.

This proposal could be used to build more consumer friendly applications, which could take advantage of Mina’s ZK nativeness to enable worldwide private payments, or intuitive identity applications.

Architecture & Design

  • Detailed Design/Architecture: the secp256r1 implementation will make use of existing tools on o1js, such as foreign fields and foreign elliptic curves. The smart contract wallet implementation will look to adapt Ethereum’s EIP-4337 into o1js, but more specifically the Mina blockchain.
  • Vision: the final goal would be integrating into o1js, making it possible to build consumer facing applications that feel more intuitive and where users do not even have to know they are interacting with Mina.
  • Production Timeline: after the three months of development are done, the project would have to undergo a security audit, after which it could start to be used in production.

Budget & milestones

  • Deliverables:
    • Implementing ECDSA on secp256r1 on o1js.
    • Implementing an EIP-4337-like smart contract wallet on o1js.
    • Integrating secp256k1 and secp256r1 into the smart contract wallet API reference.
    • Writing proper documentation.
    • Laying out further research, steps, and potential usecases.
  • Mid-Point milestones: secp256r1 implementation, smart contract wallet architecture and documentation
  • Project Timeline: three months
  • Budget Requested: 30,000 MINA
  • Budget Breakdown: expected 20-25 hours/week of work at a $50/hour rate.
  • Wallet Address: B62qmCR34F5ifz4AREu7Sy2d7HJcLaGYQaJp4BEQ2eCNPAVos6RUKbE

Team Info

Risks & Mitigations

As this proposal aims to build a fundamental piece of infrastructure, using it in production before a proper auditing process could result in large exploits.

To potentially mitigate the introduction of critical bugs and make the auditing process easier, the codebase must be built following best practices, looking to keep any implementation as simple and explicit as possible.

1 Like

This is a great project,while I would prefer to see projects that can bring more players to the Mina ecosystem.

How do you plan to use o1js on iOS and Android?

Good question. I understand there is some concerns with Auro Wallet regarding o1js compatibility with Chrome and Android. For some applications, users do not really need to interact with o1js directly, as what they would sign is something like an ERC-4337 user operation (using their built-in chips). This signature is what the smart contract wallet would be verifying, so the user does not need to interact with it directly.

For privacy-preserving applications, it is a different story, since private data should not leave the user’s device. I am not sure if there is any workaround that does not rely on just using o1js.

But for Smart Contract Wallet, you should use o1js or rewrite o1js, because only o1js can build contract transactions body.
Have you done core feature preliminary research? That is, the application development of the demo version of the smart contract wallet.

Users should not need to interact directly with the smart contract wallet: they simply sign their operation (using secp256r1 or the developer’s signature scheme of choice), which a third party can then use to build the actual Mina transaction.

We have identified that this piece of work is currently being carried out ZKON team and they are close to releasing this to the public. We are investigating how this proposal can be re-scoped.

1 Like

After the user signs, does the transaction need to be built by a third party(base signed data)? Sign first and then build the zk transaction?
What is the third party here?

Is there an architecture diagram here?

Yes, a third party interacts with the smart contract wallet, not the user. The user just provides the signature to this third party. The main focus of the proposal is defining a standard for a smart contract wallet, similar to ERC-4337. The third party service should be given by the wallet provider.

1 Like

Okay, thank you for your answer