The canonical version of this is now https://github.com/filecoin-project/FIPs/discussions/388. Please make comments there.

This is a proposal to introduce account abstraction into Filecoin. Account abstraction allows a user-programmed actor to be the top level entry point that initiates a transaction and pays fees.

Filecoin has a unique opportunity to implement account abstraction before a host of other actors and systems come to rely on the assumption that EOAs and actors are distinct.

Motivation

TODO fill in before public discussion.

Proposal

Message validation invokes the VM

The on-chain Message type is unchanged. All fields still have the same meanings, except that the gas values are a suggestion to the sending actor, rather than definitive. The sending actor will have the opportunity to specify different gas values during message validation.

Instead of validating a messages signature using a hardcoded algorithm (e.g. Secp256k1), message signature invokes the VM and delegates checking to the actor identified in a message’s From address.

Call sequence number checking remains unchanged: a message’s sequence number continues to be checked separately to signature validation, and the From actor’s CallSeqNum is incremented automatically after a message is validly included in the chain.

VM entry point for message validation

A new actor entry point is added to the VM (separate from invoke):

validate(Message, Signature)-> GasSpec

The message and signature parameters are the blockchain structures. An actor implementing this entry point is an account actor.

This entry point is invoked by the mempool and transaction relayers to validate a message, taking the place of existing message signature and gas limit validation. Validation either aborts (signalling the message is invalid) or returns the gas limit and price for the message.

type GasSpec struct {
	GasLimit   int64
	GasFeeCap  TokenAmount
	GasPremium TokenAmount
}

[TODO: work out mechanics of returning a tuple from entry point]

Validation is expected to verify that the signature data authorises the message for execution by the account actor. It may check a cryptographic signature but may also inspect the message and perform arbitrary local logic according to policies expressed in the actor’s code or state. Validation is subject to a fixed gas limit of VALIDATION_GAS_LIMIT = TODO.

If validate returns successfully, then prior to execution the VM sets the gas limit and deducts the returned GasLimit * GasFeeCap from the actor’s balance (failing if balance is insufficient) before proceeding. That the execution of validate itself incurs a gas cost, which consumes part of the message’s gas limit. The VM then invoke the receiver of the message as usual.