Adding support for zkSync Paymasters and AA

[dutterbutter]

Objective

First, big fan of viem ❤️ thank you for the great work!

Second, it is great that zkSync has been added but it does not seem like you can leverage its native account abstraction and paymasters using viem currently. I am looking to understand what the best approach or preferred approach to have this supported in viem .

Context

zkSync Era is Web3-compatible, although it has some differences compared to Ethereum. One of the main differences is native AA support which required extending standard Ethereum transactions with new custom fields. Such extended transactions are called EIP-712 transactions since EIP-712 is used to sign them. The additional fields consist of:

customData: {
    gasPerPubdata?: BigNumberish;
    factoryDeps?: BytesLike[];
    customSignature?: BytesLike;
    paymasterParams?: {
        paymaster: Address;
        paymasterInput: BytesLike;
    };
}

In order to take advantage of paymasters the transaction must be a 712-transaction and must have paymasterParams set.

Problem

The issue is that viem does not support transaction overrides and will complain or ignore if you attempt to do the following:

const data = await walletClient.writeContract({
      address: "0xbe9bcf56654fd81a921b6Bd07965Dd67Afbb0B69",
      abi: ContractArtifact.abi,
      functionName: "setGreeting",
      account,
      args: ["Hello World!"],
      customData: {
        gasPerPubdata: utils.DEFAULT_GAS_PER_PUBDATA_LIMIT,
        paymasterParams, // see: https://era.zksync.io/docs/api/js/paymaster-utils.html#getpaymasterparams
      },
    });

Minimum reproducible repo:

The provided repo is a minimum example of the problem.

• https://github.com/dutterbutter/min-viem-example

Implementation questions

• I can see there are chain specific types for Celo and Optimism from this PR, is it feasible to have zkSync specific support for features described above (e.g. paymasters)?
• I can work on a PR to introduce changes for support but would like to get feedback from the viem maintainers to what the preferred approach would be.

Resources

• Paymaster overview
• EIP-712 transactions
• .js SDK Example
• Ethers-v5 Implementation

[roberts-pumpurs]

Disclaimer: I am not a maintainer of Viem.
I did some research on how this can be achieved.

1. There is existing custom support for Celo and Optimism chains in the Viem repo, showcasing that custom integrations are possible. The API can be extended by the provided chain “integration” when signing the transaction (signTransaction example of Optimism from their docs and another for writeContract). I imagine that you would want the ability to provide zkSync as the parameter, and then the custom field extensions would become available.
2. To add custom zkSync chain support, a custom ChainFormatters needs to be created, that would accept and work with the new custom fields.
3. Once we receive the data in this format, we don't have to do anything extra besides just forwarding it to the underlying eth_sendTransaction call (which is already handled by Viem). We don't have to change the underlying RPC call.

So, the final API would look something like this:

import { zkSync } from 'viem/chains' 

const signature = await walletClient.signTransaction({
  chain: zkSync, 
  account,
  to: '0x70997970c51812dc3a010c7d01b50e0d17dc79c8',
  value: 1000000000000000000n,
  customData: {
    gasPerPubdata?: BigNumberish;
    factoryDeps?: BytesLike[];
    customSignature?: BytesLike;
    paymasterParams?: {
        paymaster: Address;
        paymasterInput: BytesLike;
    }
 }})

[jxom]

This approach makes sense. I would accept any contributions if someone would like to add zkSync integration into viem. Maybe the first step would be to set up the chain transaction formatters to accept these new fields (gasPerPubdata, etc) – we don't need a customData property for this, it can just be alongside the other send txn parameters. The implementation here should be enough for JSON-RPC Accounts.

After that, we can introduce a transaction serializer for EIP-712 transactions (like Celo's serializers), so we can also support signing transactions with Local Accounts (Private Key, etc).

[dutterbutter]

Hey @jxom @tmm any thoughts here?

Reading the CONTRIBUTING.md asks to post larger endeavours to discussions page first for maintainer feedback. Hoping to kickstart this work 💪

[speeddragon]

I wanted to add another discussion subject about this, please let me know if this needs to be separate thread.

I'm currently adding the formatters/serializers to support ZkSync and with this PR it should be able to interact with the ZkSync chain, but not in an easy way.

The field customSignature replaces the signature that serializers currently uses. This can be obtained using something like this:

    const transactionToSign = {
      txType: 113n,
      from: BigInt(account),
      to: BigInt(prepareTransactionRequest.to),
      gasLimit: BigInt(prepareTransactionRequest.gas),
      gasPerPubdataByteLimit: 50000n,
      maxFeePerGas: prepareTransactionRequest.maxFeePerGas,
      maxPriorityFeePerGas: 0n,
      paymaster: BigInt(params.paymaster),
      nonce: BigInt(prepareTransactionRequest.nonce),
      value: 0n,
      data: prepareTransactionRequest.data,
      factoryDeps: [],
      paymasterInput: params.paymasterInput
    }

    const customSignature = await walletClient.signTypedData({
      account, 
      domain: {
        name: 'zkSync',
        version: '2',
        chainId: 270
      },
      types: {
        Transaction: [
          { name: 'txType', type: 'uint256' },
          { name: 'from', type: 'uint256' },
          { name: 'to', type: 'uint256' },
          { name: 'gasLimit', type: 'uint256' },
          { name: 'gasPerPubdataByteLimit', type: 'uint256' },
          { name: 'maxFeePerGas', type: 'uint256' },
          { name: 'maxPriorityFeePerGas', type: 'uint256' },
          { name: 'paymaster', type: 'uint256' },
          { name: 'nonce', type: 'uint256' },
          { name: 'value', type: 'uint256' },
          { name: 'data', type: 'bytes' },
          { name: 'factoryDeps', type: 'bytes32[]' },
          { name: 'paymasterInput', type: 'bytes' }
        ],
      },
      primaryType: 'Transaction',
      message: transactionToSign,
    })

This then will ask MetaMask to sign and then we have value for the customSignature field field. This is not practical for the developers that want to integrate with ZkSync using Viem, so similar to the formatters and serializers, we should have a signer that can generate the customSignature and integrate with writeContract when it finds it is an EIP712 transaction.

This is currently being done with zkskync-web3 (that uses ethers), but I think the goal is is not use another wrapper that uses Viem, but use Viem by itself.

I'm not sure how EIP712 can be generically implemented and if customSignature is specific to ZkSync chain or not, because my context on this is still very limited.

I'm also not sure if this is a feature that should be added to Viem or if there is another possibility for this use case.

[jxom]

Interesting! Could make sense to have a custom signer that overrides the default sign in signTransaction (in this case, use signTypedData instead). Happy if you propose something for this.

[dutterbutter]

@jxom I dont know how the team handles closing discussions but I would consider this closed. Thanks again for supporting this 🚀

[zpoken]

@jxom does viem support AA tx with paymaster?

[jarrodwatts]

Yes -

On ZK Stack chains: https://viem.sh/zksync
ERC-4337: https://viem.sh/account-abstraction