Smart Contract Wallet - Account Abstraction

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

18th July,2024
Current status: Funded
Funding Note: We see this proposal as a useful addition to the ecosystem tooling to do the groundwork towards an Account abstraction interface to be integrated with wallets. The proposer is collaborating with the Pallad wallet team to get guidance on the way forward. The proposer is experienced build and we classify this approval to have medium risk. The risk associated is due to the exploratory nature of this undertaking and we will work with the teams as they progress to provide any guidance or upcoming standards that might impact their work.

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

1 Like

Smart Contract Wallet

This proposal aims to implement a smart contract wallet on Mina that can enable account abstraction by verifying different signature schemes, like ECDSA on 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 smart contract wallet implementation will look to adapt Ethereum’s EIP-4337 into o1js, but more specifically the Mina blockchain. The final implementation would be composable, enabling different signature schemes to be used, and allowing third party services to easily use it as a blueprint for their products.
  • Vision: the final goal would be a contract standard that can be used by different applications. As an MVP, we would look into integrating into Pallad to define a simple wallet dashboard showing a possible usecase.
  • Production Timeline: after the three months of development are done, the contract standard would have to undergo a security audit, after which it could start to be used in production.

Budget & milestones

  • Deliverables:
    • Implementing an EIP-4337-like smart contract wallet on o1js.
    • Integrating secp256k1 and secp256r1 into the smart contract wallet API reference.
    • Building an MVP wallet dashboard enabling account creation, topup, and fund transfers.
    • Writing proper documentation for other parties to build on top of the contract standard.
    • Laying out further research, steps, and potential usecases.
  • Mid-Point milestones: 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.

EDIT NOTE: the scope of the project no longer includes verifying secp256r1 signatures on o1js, and has moved into implementing an MVP that can make use of built-in chips to create accounts and send and receive funds.

3 Likes

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.

2 Likes

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.

2 Likes

Okay, thank you for your answer

I am highlighting this for anyone reading the proposal. The scope/deliverables of this proposal have now changed and the updates are part of the original post.

This application is approved for Funding.

Funding Note: We see this proposal as a useful addition to the ecosystem tooling to do the groundwork towards an Account abstraction styled interface to be integrated with wallets. The proposer is collaborating with Pallad wallet team to get guidance on the way forward. The proposer is experienced build and we classify this approval to have medium risk. The risk associated is due to the exploratory nature of this undertaking and we will work with the teams as they progress to provide any guidance or upcoming standards that might impact their work.

Started to adapt Infinitism’s ERC4337 implementation for simple payments only. It seems for now that a general purpose implementation would be considerably more complex since it would need to support arbitrary computation while the circuit being verified would always need to be the same.

Following the EC4337 definition, a contract AccountFactory deploys Account smart contracts that hold user’s assets. This effect is achieved in o1js by:

  1. Setting a constant verification key to the Account public key, and
  2. Customizing the Account by assigning it its specific variables, like the secp public key.

This implementation is based on TokeniZkFactory.

1 Like

FYI we done some work for connecting to Mina zkApps from EVM wallets as part of our proposal and we wrote a blog post about the topic

The code is open source as well, but we haven’t published it to NPM since it’s blocked on an o1js cache bug

2 Likes

After side questing at the Succinct ZK Residency, the passage of time has lifted all major blockers, namely:

1 Like

Some updates on the design, I’m following a similar pattern to ERC-4337 with some adaptations to conform to how smart contracts work on mina (eg: absence of a msg.sender, non-native arithmetic…). An account in this context is a smart contract that implements the IAccountContract interface, which defines two methods:

  1. validateUserOp to validate a user operation
  2. verifySignature to verify a signature

Internally, these can implement any logic to validate the user operation and signature. Examples will be provided that implement ECDSA on secp256k1 and secp256r1 (wip).

Interactions with the blockchain are defined via the UserOperation struct, which contains the transaction data to be executed. Eventually, this will enable any smart contract call, but for now it just defines payments. Users sign these operations in a way that the corresponding AccountContract must be able to validate. We define an EntryPoint contract that acts as a central hub for all accounts. This contract keeps track of the accounts (their balance and nonce). The EntryPoint contract receives the user operations, validates them (by calling the corresponding AccountContract), and executes them; via the handleOp call.

In practice: any app/wallet that wants to implement account abstraction needs to:

  1. Define what logic will be used to validate user operations.
  2. Implement an AccountContract that verifies this logic.
  3. Deploy these and link them to the EntryPoint.

The AccountFactory can be used to this end: deploying accounts that implement the same form of verification. Some usecases may benefit from forking this design and making the account abstraction less general purpose and more specific, like payments.