[General] | Account Abstraction - Deploying a Smart Account

[MikelinoZk]

Team or Project

No response

Environment

Testnet

L2 block number

No response

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

User - We have been experimenting with native AA in zkSync. We deployed a smart account through the system Contract Deployer ("create2Account" method). What we deployed is a tweaked version of DefaultAccount.sol, that always succeeds in "isValidSignature". Now, when we try to do a transfer from it, signature validation fails, maybe because it does not go through the smart account validate methods. Although we are sending an eip-712 transaction it is possible that we do not have all the fields properly encoded (there are some zkSync specific fields like "customData", "customSignature", etc.). So, the question is twofold:

1- Is the path we are taking to deploy an smart account the correct one?

2- Could you provide a sample of the format of the transaction we would need to interact with a smart account? So that we can investigate and understand the proper formatting.

Repo Link (Optional)

No response

Additional Details

No response

[gleenai[bot]]

Answer to Your Questions on Deploying and Interacting with a Smart Account on ZKsync

1. Deployment Path Validation:

   • The path you've taken to deploy a smart account using the create2Account method is correct. This method is specifically designed for deploying accounts that can act as smart contracts, allowing for custom logic like the one you've implemented in DefaultAccount.sol.

2. Sample Transaction Format:

   • For interacting with a smart account, you need to ensure that the transaction is properly formatted, especially with ZKsync-specific fields like customData and customSignature. Here’s an example of how you might format a transaction:

import { types, Provider } from "zksync-ethers";
import { parseEther, AbiCoder } from "ethers";

const provider = new Provider(rpcUrl);
let tx: types.TransactionLike = {
  to: recipientAddress,
  value: parseEther(amount),
  gasPrice: await provider.getGasPrice(),
  gasLimit: BigInt(20000000),
  chainId: (await provider.getNetwork()).chainId,
  nonce: await provider.getTransactionCount(aaAddress),
};

const abiCoder = new AbiCoder();
const aaSignature = abiCoder.encode(['string', 'string'], ['hello', 'world']);

tx.from = aaAddress;
tx.type = 113;
tx.customData = {
  ...tx.customData,
  customSignature: aaSignature,
};

const sentTx = await provider.broadcastTransaction(types.Transaction.from(tx).serialized);
await sentTx.wait();

This example includes the use of customSignature and customData, which are crucial for transactions involving smart accounts on ZKsync. Ensure that your transaction's customData field is correctly populated with the necessary custom signature that matches the logic in your smart account.

For more detailed guidance and examples, you can refer to the Building Smart Accounts documentation.

Feel free to explore further and ask more questions on the ZKsync developers discussions on Github for more in-depth answers.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[bxpana]

I'm looking into this right now to see if I can find an example to share with you. Do you happen to have a link to the contract or repo to take a look at as well?

[bxpana]

Have you guys gone through any of the AA tutorials in https://code.zksync.io/ ? This should give you a good idea of how things work in production so that you can make sure that you have things set up correctly before changing the DefaultAccount

[bxpana]

Another thing to consider is validateSignature must increase the nonce and return the ACCOUNT_VALIDATION_SUCCESS_MAGIC so you'll want to check to make sure you're doing that in your account.

There is also this tutorial from Alchemy that is similar to what you guys are trying to do too.

[dutterbutter]

Closing due to staleness please re-open if needed.