[AIP-104][Discussion] Account Abstraction

[lightmark]

AIP Discussion

Account Abstraction (AA) on Aptos allows any account to be authenticated through move code in addition to existing
authentication schemes supported by native code. This AIP will introduce a new authenticator called Abstraction that
delegates the authentication verification to AptosVM running move-based authentication logic.

Read more about it here: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-104.md

[ch4r10t33r]

AIP Discussion

Account Abstraction (AA) on Aptos allows any account to be authenticated through move code in addition to existing authentication schemes supported by native code. This AIP will introduce a new authenticator called Abstraction that delegates the authentication verification to AptosVM running move-based authentication logic.

Read more about it here: #512

Hey @lightmark, I just came across this AIP and I'm really excited about it! I have a quick question though—based on an initial high-level read, does this AIP primarily introduce support for multiple authentication schemes? That doesn't seem like full account abstraction per se.

The generally accepted definition of Account Abstraction typically includes a broader range of features beyond multiple signature schemes, such as key rotation (replacing compromised keys, deadman’s switch), various access policies (role-based access, multisig, social recovery), gas abstraction (paying fees with tokens instead of native coins), and execution abstraction (batching calls), among others.

Would it make more sense to call this Authentication Abstraction instead?

[lightmark]

Hey @ch4r10t33r, thanks for your prompt feedback!

Regarding your question, Aptos Move and Ethereum Solidity are distinct smart contract languages with different programming models and designs. The Account Abstraction (AA) feature introduced here allows for the logic to acquire the signer of any account to be customized in a Move function with access to on-chain data.

To clarify, there is no universal consensus on the definition of AA across different blockchains. For instance:

• Ethereum AA (based on ERC-4337): As you said, defined in https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy#What-is-Account-Abstraction
• Solana AA: Enhances wallet security through smart contracts for features like spending limits and shared wallets.

On Aptos, AA extends the following capabilities:

• Multiple signature schemes: Supports features like key rotation.
• Customizable access policies: Allows account control logic to be fully represented in Move, enabling fine-grained control over access rights.
• Security features: With Move, Aptos can enable features like spending limits and shared wallets, similar to those on Solana, by customizing how accounts are managed.

While Aptos also supports execution abstraction (via Aptos Script and BatchedTxn) and gas abstraction (via third-party gas payer), these features are not necessarily tied to ACCOUNT. However, they are often included under the broader AA concept due to their relevance in other blockchains like Ethereum.

We may explore an on-chain version of gas abstraction in the future, but that would require a separate AIP/project.

[ch4r10t33r]

Thanks for responding @lightmark

To clarify, there is no universal consensus on the definition of AA across different blockchains. For instance:

• Ethereum AA (based on ERC-4337): As you said, defined in https://notes.ethereum.org/@yoav/erc-4337-vs-eip-3074-false-dichotomy#What-is-Account-Abstraction
• Solana AA: Enhances wallet security through smart contracts for features like spending limits and shared wallets.

Fair enough! My main point was that it would be helpful for all chains to agree on a universal definition and terminology to avoid confusion for developers working across them. As the future is multi-chain, having consistent terminology—alongside interoperability—would go a long way in streamlining development and reducing any misunderstandings. :-)

On Aptos, AA extends the following capabilities:

• Multiple signature schemes: Supports features like key rotation.
• Customizable access policies: Allows account control logic to be fully represented in Move, enabling fine-grained control over access rights.
• Security features: With Move, Aptos can enable features like spending limits and shared wallets, similar to those on Solana, by customizing how accounts are managed.

Is the spending limits feature currently available, or is it expected to be released with Move2?

While Aptos also supports execution abstraction (via Aptos Script and BatchedTxn) and gas abstraction (via third-party gas payer), these features are not necessarily tied to ACCOUNT. However, they are often included under the broader AA concept due to their relevance in other blockchains like Ethereum.

Understood. At Kanalabs, we operate a paymaster service that is utilized by several dApps on Aptos to enable gas abstraction.

We may explore an on-chain version of gas abstraction in the future, but that would require a separate AIP/project.

That sounds fantastic! It will definitely elevate the user experience on Aptos to a whole new level. Looking forward to it!

[yeptos]

Hi @lightmark, in the AIP it’s not immediately clear why there should be a fixed global gas limit for move authentication functions. It also seems to imply that the gas fees for these functions aren't paid by the tx signer (or are they?). I'm assuming there must be some security considerations behind this which i hope can be addressed in the AIP if possible.

[yeptos]

by the way it's really great to see this effort finally coming together, i'm very excited about all the use cases this will enable for us and the ecosystem!

[magnum6actual]

Trying to wrap my brain around this. Given the function signature:
public fun authenticate(account: signer, signature: vector<u8>): signer

how do I get any information about the entry function being called?

[lightmark]

Hi @lightmark, in the AIP it’s not immediately clear why there should be a fixed global gas limit for move authentication functions. It also seems to imply that the gas fees for these functions aren't paid by the tx signer (or are they?). I'm assuming there must be some security considerations behind this which i hope can be addressed in the AIP if possible.

I will update that. The reason is security surface of DDoS since those gas should not be charged.

[lightmark]

Trying to wrap my brain around this. Given the function signature: public fun authenticate(account: signer, signature: vector<u8>): signer

how do I get any information about the entry function being called?

it's the function_info stored in DispatchableAuthenticator

[nhandl3]

Hi @lightmark

Multiple signature schemes: Supports features like key rotation.

Can you elaborate on this application of AA, how it is different from Account Key Rotation or current multisig?