feat: account abstraction and paymaster syntax #1

idea404 · 2023-12-15T10:39:22Z

What 💻

This PR introduces both an AbstractWallet class and a Paymaster class to simplify sending initialising AA accounts and sending paymaster-endorsed transactions. Developers will also be able to customise their own signature methods for the account abstraction by importing the signingFunction and redefining it.

Why ✋

Sending transactions currently involves either (i) creating custom classes to override signature functions or (ii) constructing raw transaction objects from scratch and manually signing and serialising.

Evidence 📷

const accountAbstractionAddress = "...";
const provider = Provider.getDefaultProvider(types.Network.Localhost);
const ethProvider = ethers.getDefaultProvider("http://localhost:8545");
const wallet = new Wallet(PRIVATE_KEY, provider, ethProvider);
paymaster = new Paymaster("ApprovalBased", paymasterAddress, tokenAddress);

const abstractWallet = new AbstractWallet(
    accountAbstractionAddress,
    wallet.privateKey,
    provider,
    ethProvider,
    paymaster,
);

const tx = await abstractWallet.transfer({
    to: wallet.address, 
    amount: ethers.parseEther("10")
});
await tx.wait();

Testing 🧪

Clone the repo
Install dependencies with yarn
Run local-setup
Run yarn test:aa

TODOs ✔️

remove console.log
implement integration tests with contracts
implement signingFunction override integration tests
integration test both General and AB Paymaster usage with AbstractWallet
lint files and add linter to CI
add testing CI

Romsters · 2023-12-15T15:58:01Z

src/utils.ts

+export function encodeData(data: any[]): string {
+    const types = data.map(item => {
+        if (typeof item === 'number') {
+            return 'uint256';


what if I need uint128 or int64?

good question. I thought the same while setting up this function too (another reason why I left this PR as draft). I would think now then that it is not possible to deduce these lower levels types without the developer specifying them either through an ABI or some form of input. This changes the syntax for constructing both the Paymaster and abstractWallet classes, considering they both can potentially have methods that serialise data.

Romsters · 2023-12-15T16:03:15Z

src/wallet.ts

@@ -124,3 +125,52 @@ export class Wallet extends AdapterL2(AdapterL1(ethers.Wallet)) {
        return await this.provider.broadcastTransaction(await this.signTransaction(populatedTx));
    }
 }
+
+interface SigningFunction {
+    (this: AbstractWallet, transaction: TransactionRequest): Promise<string>;


does it need access tothis (AbstractWallet)?

It could otherwise accept the wallet as a parameter as:

(abstractWallet: AbstractWallet, transaction: TransactionRequest): Promise<string>;

Both approaches are fine by me

Romsters · 2023-12-15T16:05:34Z

src/wallet.ts

+        paymasterParams: this.paymaster.getPaymasterParams(),
+    } : {};
+    transaction.customData = this._fillCustomData(transaction.customData);
+    transaction.customData.customSignature = await this.eip712.sign(transaction);


how does it work? What key is used to sign it?

This will use the privateKey parameter passed to the constructor here. Ultimately, a SigningKey function is added at ethers.BaseWallet, the class that ethers.Wallet extends (and this class is extended by zks.Wallet), using this passed in private key that is used for signatures.

I find it also tricky to know what exactly is going on with the class as it extends another class about 5 times.. But this approach adds the least lines of code too.

Romsters · 2023-12-15T16:06:04Z

src/wallet.ts

+        providerL2?: Provider,
+        providerL1?: ethers.Provider,
+        paymaster: Paymaster | null = null,
+        customSigningFunction: SigningFunction = signingFunction,


Do we need a default here? Or should we just make it required?

I find it makes the syntax for declaration simpler by adding a default here. I prefer it because of that. I can imagine some developers might not be interested in overriding the signing function and only seek to use AA for the custom logic you can add to accounts on-chain. In these cases I can imagine they'd be happy not having to be concerned with the signing logic, or paymaster logic either (if they do not wish to use a paymaster).

Romsters · 2023-12-15T16:10:01Z

src/wallet.ts

+    ) {
+        super(privateKey, providerL2);
+        this.accountAddress = accountAddress;
+        this.paymaster = paymaster;


why is this.paymaster here? How I can I control it's usage if it's here?

this.paymaster is called in the signingFunction logic inside of signTransaction which is called for signing any transaction. The goal here was to provide a way for the developer to specify using a paymaster by default on any transaction. Currently the syntax in signingFunction is:

... transaction.customData = this.paymaster ? { gasPerPubdata: DEFAULT_GAS_PER_PUBDATA_LIMIT, paymasterParams: this.paymaster.getPaymasterParams(), } : {}; ...

But I think it would be better to change it actually to:

... transaction.customData ??= this.paymaster ? { gasPerPubdata: DEFAULT_GAS_PER_PUBDATA_LIMIT, paymasterParams: this.paymaster.getPaymasterParams(), } : {}; ...

Considering the developer might want to specify some transactions on the frontend where a paymaster is applied, and some others not. But if the developer wants a paymaster to be used in all transactions, then they can simply declare the paymaster in this constructor here.

Romsters · 2023-12-15T16:12:24Z

tests/integration/wallet.test.ts

+            expect(difference / BigInt(10 ** 18) < 10.1).to.be.true;
+        }).timeout(25_000);
+
+        it.skip("should transfer DAI", async () => {


Romsters · 2023-12-15T16:12:59Z

tests/integration/wallet.test.ts

+            expect(balanceAfterTransfer - balanceBeforeTransfer).to.be.equal(BigInt(amount));
+        }).timeout(25_000);
+    });
+});


Can we please add a test for just calling some smart contract?

Romsters · 2023-12-15T16:15:03Z

src/paymaster.ts

+                  };
+    }
+
+    getPaymasterParams() {


Why do we need this class if we simply want to build paymaster params? Shouldn't it be a util instead?

Actually I also notice this method will require adding parameters as those are required for the ApprovalBased paymasters that accept a quantity of tokens to cover the transaction cost.

As for making this a class, this class will also include a method to enrich a transaction with the data for paymasterParams which is useful when developers only want to sponsor some transactions. Something like .addParamsToTransaction(trx) that calls getPaymasterParams to fill in the transaction object. This removes the need for the developer to manipulate the transaction object manually.

Not precious about this either though, so if you think strongly of keeping these as functions then we could go that way but I find this:

let tx = contract.methodWrite(...); tx = utils.addPaymasterParamsToTransaction(utils.getPaymasterParams(...));

Less appealing than:

const paymaster = new Paymaster(...); let tx = contract.methodWrite(...); tx = paymaster.addParamsToTransaction(tx);

idea404 added 13 commits December 8, 2023 12:07

chore: split test commands

e106637

chore: declare tests

d3dcf2f

feat: add stub classes

480bb35

fix: remove signingFunction from utils

8b99a1c

feat: utils with unti tests

a3530de

fix: format

b394da8

feat: paymaster and unit tests

934569f

fix: unskip paymaster test

083197d

feat: abstractWallet and tests

2d8300c

feat: abstractWallet and tests

7e59111

feat: more cohesive paymaster class

39c8d94

fix: imports

1120160

chore: refactor

1b5ede8

Romsters reviewed Dec 15, 2023

View reviewed changes

Merge branch 'main' into main

4c2b3b9

idea404 closed this Dec 30, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: account abstraction and paymaster syntax #1

feat: account abstraction and paymaster syntax #1

idea404 commented Dec 15, 2023 •

edited

Loading

Romsters Dec 15, 2023

idea404 Dec 18, 2023

Romsters Dec 15, 2023 •

edited

Loading

idea404 Dec 18, 2023 •

edited

Loading

Romsters Dec 15, 2023

idea404 Dec 18, 2023

Romsters Dec 15, 2023

idea404 Dec 18, 2023

Romsters Dec 15, 2023

idea404 Dec 18, 2023

Romsters Dec 15, 2023

Romsters Dec 15, 2023

Romsters Dec 15, 2023

idea404 Dec 19, 2023

feat: account abstraction and paymaster syntax #1

feat: account abstraction and paymaster syntax #1

Conversation

idea404 commented Dec 15, 2023 • edited Loading

What 💻

Why ✋

Evidence 📷

Testing 🧪

TODOs ✔️

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Romsters Dec 15, 2023 • edited Loading

Choose a reason for hiding this comment

idea404 Dec 18, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

idea404 commented Dec 15, 2023 •

edited

Loading

Romsters Dec 15, 2023 •

edited

Loading

idea404 Dec 18, 2023 •

edited

Loading