4

I was under the impression that with account abstraction, I would be able to directly initiate smart contract calls without an EOA. However, after reading through zkSync's Account Abstraction example, that's not the case.

  // The two owners of the multisig
  const owner1 = Wallet.createRandom();
  const owner2 = Wallet.createRandom();

You need the signatures of the above two EOAs to send any transaction with the multisig.

const signature = ethers.utils.concat([
  // Note, that `signMessage` wouldn't work here, since we don't want
  // the signed hash to be prefixed with `\x19Ethereum Signed Message:\n`
  ethers.utils.joinSignature(owner1._signingKey().signDigest(signedTxHash)),
  ethers.utils.joinSignature(owner2._signingKey().signDigest(signedTxHash)),
]);

aaTx.customData = {
  ...aaTx.customData,
  customSignature: signature,
};

...

const sentTx = await provider.sendTransaction(utils.serialize(aaTx));

How is this meaningfully different from existing multisigs on mainnet, which hasn't implement Account Abstraction yet?

4 Answers 4

5

Currently in Eth mainnet (without any type of account abstraction) the EOA contains both the Signer (who authorizes transactions) and the Account/Ledger (where assets are held). The point of account abstraction is to separate these: you'll have an entity which holds authentication info (usually private key) and a separate entity which holds assets (typically a smart contract, called account contract).

Therefore your EOA only contains the signing keys (or whatever else mechanism you want to use and the account contract supports). The account contract is the entity which holds whatever assets and contains logic to authenticate its usage.

An account contract can, for example, contain native multisig. So it requires multiple signatures to perform an action - probably to execute some transaction which involves the assets it contains. Without account abstraction the multisig is a separate contract which holds assets, but your EOA can also have different assets. I think multisig is not the best use case of account abstraction.

Where account abstraction shines is stuff like fee payment. If the network supports account contracts natively, it takes payment fees from the account contract. So whatever transactions you send, their gas fees are paid by the account contract. This leads to interesting possibilities: you may for example allow any user to interact with that account contract for a week so that the contract pays for all gas fees. Or maybe it pays fees only every Tuesday.

Other cool features are for example session keys: you authorize account contract to interact with some other (gaming) contract for the next week and to pay max $50 in gas fees in total. Then you don't need to send approvals for a week and you can just interact with the gaming contract painlessly.

There are lots of options out there, and I feel we're only just beginning to understand the power of account abstraction.

2
  • Ohh I see, thanks so much for this explanation. "Therefore your EOA only contains the signing keys (or whatever else mechanism you want to use and the account contract supports)." So "EOA" in this case is not something formal on the blockchain, it's just anything the account contract accepts as authentication. Like you said, the contract could choose not take any authentication at all, and so any user would be able to transact from it? Fascinating!
    – Eric
    Dec 7, 2022 at 18:29
  • 1
    Yeah, the authentication part depends on the account contract - it could even be without authentication. Maybe it allows anonymous access every Thursday. Or uses a blacklist to block transactions to known bad contract, or....... Dec 7, 2022 at 19:53
0

Account abstraction without EOA signatures is coming to Ethereum very soon!

The latest account abstraction standard, ERC-4337, allows the verification logic to be set by the wallet contract's validateUserOp() function.

Here is an example of a simple account that specifies an EOA as the signer, though it can be extended for any scheme. The EIP even goes as far as specifying a helper Aggregator contract that can aggregate signatures (such as BLS) for wallets.

1
  • Does ERC-4337's Account Abstraction without EOA signatures work by aggregating those transactions off-chain, then having some centralized entity transact for you? Are there worries about how this doesn't feel permissionless?
    – Eric
    May 31, 2023 at 21:12
-1

In my opinion: 4337 Account Abstraction does not invent something, but "standardise" already existing tech:

  • Gas stations and paymasters
  • Offchain transaction relayers
  • "Smart accounts" and "smart wallets"
  • ...

At the end we will have standard use cases:

  • Smart contracts can now initiate TXs by sending it to the EntryPoint
  • Instead of using private/public keypair for authentication, we will be able to use other auth.schemes (see the validateUserOp() function)

So back to your question:

I was under the impression that with account abstraction, I would be able to directly initiate smart contract calls without an EOA?

Yes, using AA smart contracts will be able to initiate smart contract calls....

-1

The original question is 'AA still requires EOA signatures?'. The clear answer is no. This is since AA eliminates the need for EOA signing transactions. However, AA does allow for other kinds of signatures e.g BLS, Schnorrs etc. EOA only uses ECDSA as its cryptographic signature.

Although, if EOA is ever able to incorporate other signatures akin to AA, the the answer would change. In that scenario, AA does require EOA signatures. However, they wouldnt be distinctly described as EOA signatures but just cryptographic signatures.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.