RIP-7953: System Events for Native Account Abstraction

Abstract

This proposal describes how system events injected by the virtual machine directly without calls to the LOG opcodes while executing the RIP-7560 transactions

Motivation

The ERC-4337 defines an EntryPoint contract that accepts an array structs named UserOperation and executes them as a part of an Account Abstraction protocol.

The EntryPoint contract emits events during the execution of a UserOperation in order to expose some of the details of the on-chain state that would not be available otherwise.

Additionally, the API for Ethereum events provides support for unique and useful features, such as event subscriptions or indexed parameters.

A set of similar proposals exists for the Ethereum L1 as well, notably EIP-7708 and EIP-7889.

Specification

System Transaction Events

We define the following system-level events that are emitted as part of an RIP-7560 transaction:

• RIP7560TransactionEvent event is emitted in the end of each RIP-7560 transaction.

• RIP7560TransactionRevertReason event is emitted if the RIP-7560 transaction's execution frame has reverted with a non-zero length return data.

• RIP7560TransactionPostOpRevertReason event is emitted if the RIP-7560 transaction Paymaster's "postOp" call has reverted with a non-zero length return data.

The bytes array returned as the revertReason parameter is truncated to its maximum length of MAX_REVERT_REASON_SIZE. Any data returned above that length will not be observable in a transaction receipt.

The gas cost of System Transaction Events is not charged separately and is covered by the AA_BASE_GAS_COST of a transaction.

The values for the executionStatus are the following:

• success = 0
• executionFailure = 1
• postOpFailure = 2
• executionAndPostOpFailure = 3

All events are emitted at the AA_ENTRY_POINT address.

Rationale

Not using transaction receipt

Some of the data exposed as part of the system events can be exposed as part of the transaction receipt as well.

There are a few reasons to expose this data as a system event:

• Backwards-compatibility with ERC-4337 for existing Account Abstraction tooling.

As the entire technological stack that exists around Account Abstraction so far has evolved around the ERC-4337 protocol, abandoning event-based approach may make some existing tools infeasible. This loss in functionality is unnecessary and is easily avoidable.

• Events provide search, filtering and subscription API that does not exist for the Transaction Receipts.

For example, with system events we are able to search for all transactions using a certain Account or Paymaster. This functionality may be crucial for any reputation-based systems like ERC-7562 mempools.

• Modifications to Transaction Receipts may pose more challenges than to emitted events.

As the fields of Account Abstraction continues to evolve, it is possible there will be additional RIPs defining additional system events in the future. It is also possible that system events will be adopted by L2s for tasks other than Account Abstraction. If each of these proposals needed to introduce a modification to the Transaction Receipt schema, it would result in an unmanageable complexity.

Backwards Compatibility

This proposal is meant to introduce a certain form of backwards compatibility between RIP-7560 and ERC-4337.

However, the event signatures are not equivalent and users will have to explicitly add support for these system events.

Security Considerations

As system events are created by the execution environment directly, there is no added risk in accepting the data exposed by these events.

Copyright

Copyright and related rights waived via CC0.