RFC: Account Abstraction based on EIP-2938

[sebastien-forestier]

Introduction

Here are good intros on Account Abstraction:

• https://www.argent.xyz/blog/wtf-is-account-abstraction/
• https://hackernoon.com/what-is-account-abstraction-and-why-is-everyone-talking-about-it

The state-of-the-art of Ethereum research towards implementing account abstraction on Ethereum is EIP-4337, which makes no consensus changes, and was introduced because the simpler EIP-2938 (and others) make consensus changes which they can't afford nowadays.

The proposal EIP-2938 is probably one of the best to stem from for Massa, although some aspects of the problem are not solved in this EIP and left for future research (multi-tenant AA and unrestricted authentication code).

Here we can discuss how we could adapt this EIP to Massa and maybe solve the remaining questions.

Concept

EOA (Externally Owned Accounts) operations are authenticated with a signature mechanism specified in the core blockchain.
Miners verify the signature of the operation with the pre-defined algorithm (signature of hash of pubkey+expiration_period+payload), forward it to other peers and include it in a block only if it is valid.

In order to allow more complex / flexible / user-defined authentication mechanisms, the new concepts are smart wallet and account abstraction operations.

The smart wallet is a smart contract with a particular bytecode entrypoint (target).
Its bytecode is composed of two parts:

• the authentication part before the PAYGAS opcode,
• the execution part after the PAYGAS opcode.

The account abstraction operation AA_OP(target, data) calls the smart wallet entry point with data which includes authentication data and payload data.

If the execution fails before the PAYGAS opcode, gas is not paid to the miner, and the op is reverted. If the execution fails after the opcode, gas is paid, and the op is executed only until the opcode.

The authentication code is limited in gas, so that it is fast to execute, e.g. to 5x the time it takes to authenticate an EOA operation.
For example, for the simplest smart wallet simulating an EOA transaction, the bytecode will check a signature provided in the data, then if valid, will pay for the gas with the PAYGAS opcode, and finally will execute the payload also provided in the data.

Challenges

The main challenges with EIP-2938 AA are

• the protection against replaying operations,
• and convincing the miner he will get paid gas for the operation's block space.

Replay Protection

In EIP-2938, the replay protection is build using a NONCE opcode, to reflect the nonce used in classic EVM operations.
During execution, the NONCE opcode declares the nonce of the operation.
The miner will include the operation only if the nonce is strictly above the previous nonce executed on this smart wallet.

The nonce opcode prevents use cases where the smart wallet has multiple parallel users (multi-tenant smart wallets), as the nonce could collide.

In Massa, we have no nonce, but another mechanism for classic transaction replay protection: the transaction can be included only in a time window before a specified expiry period, and the transaction hash is used to remember if the transaction has already been included in the window.

A similar mechanism for smart wallets can be implemented with an EXPIRY_PERIOD and a HASH opcode to declare these in the authentication part.
If the EXPIRY_PERIOD is not compatible with the actual period or if the HASH has already been used during this time window, then the operation reverts and does not pay for the gas.

Ensuring Gas is Paid

When the AA operation arrives in the miner's pool, the miner quickly checks the authentication part.
If it is valid and pays for the gas, then the miner can include it in a future block.
If the miner includes an operation with an invalid authentication part which does not pay for the gas, the miner just looses block space that could have been used for other operations.

However, the fact that the operation pays for the gas now does not mean that the operation will pay for the gas when included in the block.
Indeed, the gas may have been used in the meantime, the authentication method may have changed, etc.

The authentication could be re-executed when including the op in the block to check if it is still valid, but if it is not, the operation has polluted the pools of all miners, and many operations like this one can be created, paying a high gas price to flush out legit operations from the pool.

To ensure that if the operation is valid at some point (with a given nonce) then it always stays valid for this nonce (unless own balance is not enough to pay for the gas which is checked quickly), EIP-2938 proposes to restrict the calls that can be done in the authentication part, so that it depends only on the data in the operation and does not depend on any other operation that could happen in the meantime or data that could have changed in the meantime, such as the own balance of the smart wallet.

This restriction prevents the most interesting use cases of AA, such as using an ERC-20 balance to buy native tokens on a swap in the authentication code to pay for the gas.

Possible Direction: Optimistic Broadcast and Contract Ban

One direction we could study to allow unrestricted authentication code is the following.

When the AA operation is first seen, and if the target contract is not banned, the node executes it, and if valid (no other operation with the same declared HASH has been executed in this contract in this time window and the declared expiry period is valid), keeps it in the pool and broadcasts it to its peers.
The op being invalid now is not a reason to ban the peer sending the op as the op might have been valid earlier.

When including the operation in a block, the node re-executes the operation to check if it is still valid based on its latest ledger.
If it is not valid anymore in the time window, or the expiry period / the hash changed, the node bans this contract.
Even if it is valid on inclusion, it can still end up invalid on final execution and not pay the gas, due to parallelism in Massa.
In this case also, nodes knowing that the op has been valid and seeing it invalid (or valid with new expiry period or hash) ban the contract.

All the burden to prevent being banned is left on the smart wallet.

Preventing Contract Ban as a smart wallet user

The smart wallet must ensure that paying for the gas in a context now in the time window implies paying will still happen up until the end of the expiry period, and declaring the same expiry period and hash.

The main complexity is on ensuring that the source of gas is reliable and not decreasing too fast.
This is easy for a single-tenant contracts, e.g. with the balance gas source, the smart wallet user (or its wallet UI) has to make sure to not spend gas too fast / in parallel, and to refill before it gets empty.

For multi-tenant smart wallets, the misbehavior of one user may ban the contract for other users.
To ensure that all users operations been valid at some point will stay valid, enough gas must be kept to handle a full load for a full time window, and if this is not possible for some reason and operations must start to be rejected, the rejection decision (or any other change that might affect the possibility of one user to use the wallet) must be taken in advance of one time window.

[SlnPons]

From a user perspective, the AA unlocks a wide variety of usages which will simplify the mass-adoption. I identified this topic as a must-have from a wallet perspective.

[SlnPons]

FYI - Thyra's wallet is currently going through a re-building phase in which we'll include the notion of smart wallet to enable more native functionalities for users. (If you want to know more about the features that will be implemented, feel free to reach out)

So I was curious to understand a bit better how the gas to create and execute a smart wallet could be calculated?

[qdrn]

We could add a parameter that let node runners define the proportion of AA operations they are willing to put in their blocks. This parameter could be set at 0% by default to avoid attacks.

In the future, when the block factory and pool is separated from the rest of the code, it will be easier to protect against such attacks. We can imagine people implementing different type of protections based on their specific needs. For instance if you are a node runner and handle a specific service and want to pay for the fees of your users. In this specific case it's very easy to protect yourself.

[gregLibert]

I like this approach!