Account abstraction

[anorth]

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

Concrete, protocol-defined message validation limits innovation in a few important areas:

• Wallets (smart contracts / actors) that use signature verification other than ECDSA
• Wallets that include features such as multisig verification or social recovery, reducing the highly prevalent risk of funds being lost or stolen

The key goal of account abstraction is to allow users to use smart contract wallets containing arbitrary verification logic instead of externally-owned accounts as their primary account. A transaction can "start from" a smart contract, not only an EOA. Account abstraction decouples the ownership of assets (the wallet) from the authority to transfer them (wallet-specific policy).

Examples of the kind of validation logic such a smart contract wallet might implement include:

• signature verification other than ECDSA
• rotation of authorized keys (without needing to transfer all assets individually to the new key)
• social recovery of lost keys
• limits on the types or amount of assets authorized to specific keys
• multi-signature verification

To explore multisig wallets as an example, with account abstraction:

• signatures can be gathered off-chain and submitted as a single transaction to the wallet
• the signature could be a BLS aggregate
• the wallet can implement arbitrary policies around the threshold required for various transaction types
• the wallet itself pays the gas fees, rather than one of the signers doing so

Some other account abstraction proposals also target additional goals, which are discussed in the "Alternatives & extensions" section below.

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
}

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.

Note that the Message parameter to validate includes gas parameters specified from the outside. The actor may pass these values through or return different ones: those from the message may be thought of as advisory from the end user.

Restricted runtime

The key challenge for miners and validators is to determine if a transaction will pay the fee once included, with a small, fixed amount of processing that is robust against DOS attacks.

The validate method has a restricted runtime. It cannot inspect any environmental variables (e.g. current epoch), check its own balance, nor send a message to any other actor. Any attempt to do so must abort. The actor can read its own state, but must in effect be a pure function of that state and the message and signature.

Restrictions on receiving

A message to an account actor from any other actor is read-only, and cannot modify the account actor’s state (edit: including spending of native FIL tokens). Any attempt to replace the actor’s state root must abort. The exception to this is that a message originating from an account actor can modify its own state (including through a call sequence via other actors).

Upgradeability

An account actor is expected to be upgradeable in-place via future FVM code upgradability mechanisms or proxy-delegate patterns. This compatibility should be confirmed prior to finalising either mechanism.

Block and message validity

Messages

The validity of a message with a particular sequence number depends purely on the actor state at that sequence number. Since that state is immutable except via calls originating from the actor itself, the validity for any message bearing that sequence number is fixed, and may be cached by mempools and message relayers. A node may use the cached validity result (including gas parameters and gas units used for validation) when executing the message in a block: it does not need to re-validate.

The validity of any message with a more distant sequence number is not fixed: an earlier message could arbitrarily alter the actor’s validation logic. Any change to the actor’s state would necessitate revalidation of all subsequent messages. Thus, in the basic case, a mempool should keep only one message originating from any actor at one time. Heuristics could support retaining longer message chains in some situations (e.g. the sending code CID is known to be an immutable, non-upgradeable contract; or analysis shows that earlier messages can’t invalidate later ones).

This restriction on message chains is mitigated by the introduction of multicalls (below).

Blocks

A block may include only valid messages, according to each actor’s validity method. Since message validity depends only on that actor’s state, which is immutable except via calls originating with the actor itself, the ordering of messages from different actors cannot affect the validity of any one of them.

Multiple messages from one actor may be included in one block. Each must be valid against the state after the immediately preceding message.

Note that a message may still fail due to the sending actor having insufficient balance to cover the gas limit (which the validation function cannot check). This results in a penalty to the block provider, as today.

Gas charges

The base message fee is reduced to reflect that no signature validation happens. But gas is charged for the validate method.

Upgrade the built-in account actor (optional)

The built-in account actor code is upgraded in place to become an account actor according to this proposal, with equivalent behaviour to today. The validate method checks the message’s signature via the VerifySignature syscall and passes through the message’s gas parameters.

The built-in account actor should also gain an upgradeability hook, so that it may be replaced with a different contract after initial creation.

This upgrade means that all account actors utilise account abstraction and may be upgraded. The only distinction that a built-in account actor has is that it has an address that was derived from a public key (but not necessarily the public key now in use for validation).

Upgrading the built-in account isn't strictly necessary, especially if we need to leave non-abstract validation in place for BLS accounts. But it would be nice for there to be only one way that messages are validated.

Discussion

Multicalls

A multicall is a single blockchain message that makes multiple calls to other actors, which can succeed or fail as a unit. Multicalls are great for the UX of doing multiple things without waiting for block inclusion (e.g. “approve token and then make a transfer”) and also more efficient, because message overheads (especially signature validation) are amortized over more work.

Account abstraction supports implementing multicalls within the account actors. We just add an exported method Execute(calls: List<Call>) and then send a message from the account to itself with the list of calls to execute. It’s also possible to parameterise policy around atomicity, etc. We could upgrade the built-in account actor to support this for everyone!

This Execute method should probably be specced as an FRC for more general delegated execution, too.

Replay and non-malleability

Note that actors may not have cross-chain replay protection unless they build it in manually, or Filecoin adds such protection in the base protocol.

A poorly designed abstract account could break transaction non-malleability (i.e that transaction can't be modified in-flight and remain valid). It's the account contract author's responsibility to ensure message can't be tampered with.

Hosted VMs (EVM)

Account abstraction could present a natural mechanism to implement entry points for VMs hosted inside the FVM, such as the planned EVM compatibility layer. See https://github.com/filecoin-project/fvm-specs/issues/92

Open questions

I'm not sure how to make this compatible with BLS accounts that use the block-level signature aggregation. At worst this just means that BLS keys can't enjoy abstraction, but that's a bit of a shame.

Implementation notes

We'll need a new signature type to allow for signatures that are opaque to the Filecoin protocol, but validated by user-programmed actors. We can't have a fixed whitelist of formats at the protocol level.

We need to work out mechanics of returning a tuple from a VM entry point.

Alternatives & extensions

Minimum gas bounds allowing state mutation from external calls

Rather than being immutable, allow mutation if a minimum gas amount is spent (some fraction of the fixed cost of re-validating the next message). See https://eips.ethereum.org/EIPS/eip-2938.

Immutability is really unfortunate as it limits the possibility of things like token receiver hooks. But expensive token receiver hooks aren't much better.

Abstract over call sequence number (nonce)

Delegate nonce checking to validate() too, allowing more flexible schemes than linear (e.g. host an EVM inside an actor, and use EVM address nonces).

This can allow a message CID to be valid more than once, breaking uniqueness. Is that bad? We do deduplicate on CID within tipsets though (and can require unique within a block).

A message could become invalid in a tipset because a prior one bumped the nonce (each miner only held one in mempool, but different ones). This is analogous to situation today where we penalise miner for “wrong” nonce. But implication is that we need to re-run validate() as part of tipset execution, whereas original proposal doesn’t. Is that too bad?

Paymasters

One feature that other account abstraction proposals sometimes aim for is paymasters or sponsored transactions. This refers to an ability for one contract to pay fees for certain messages that originate at another. A canonical example is an on-chain exchange paying gas fees for its users. This proposal doesn't enable paymasters or sponsorship. See https://eips.ethereum.org/EIPS/eip-3074 for an Ethereum proposal that does.

Pay with tokens

Another candidate feature is the ability to pay fees with user-programmed tokens, by swapping tokens for the native asset (FIL) during transaction execution. The goal is to not need any of the native token held in the wallet/account. This proposal doesn't enable that yet, mainly because the validation function cannot call other contracts.

[Stebalien]

In general, I really like this proposal.

One concern I have is message validation in pubsub could turn into a DoS vector. Unfortunately, an invalid message can still cause us to load an actor & execute the validate method, with nobody to pay the cost.

However, there are a few possible mitigations:

• Prioritize messages from actors with "known" validate functions. This would let us quickly validate those messages without shelling out to WASM. We'd still process other messages, but we'd preferentially drop "other" message types under load, mitigating the potential DoS vector.
  • This is a per-node decision and is not consensus critical.
• Message validity could be used in gossipsub's anti-dos heuristics, but we need to be careful that it doesn't become an attack vector itself.

[anorth]

an invalid message can still cause us to load an actor & execute the validate method

Yes. This is analagous to the current work to validate a message, which has no-one to pay for it if invalid. If the maximum cost of validation is bounded, then this is a fixed change in cost for the network to absorb. Invalid messages should not be propagated further.

[Stebalien]

Yes. This is analagous to the current work to validate a message, which has no-one to pay for it if invalid. If the maximum cost of validation is bounded, then this is a fixed change in cost for the network to absorb. Invalid messages should not be propagated further.

Yes, but the cost of validating a signature is pretty low. Even bounded, the cost of loading a wasm module is non-trivial (even if it's pre-compiled and cached).

[anorth]

Well I'm very keen for prototyping to establish this cost for us, and motivate optimisations. We need to get that cost as low as possible anyway. It would be disappointing if the overhead of a simple method (i.e. cheaper than signature validation) far exceeded the actual execution cost.

[Stebalien]

One thing that's possible in EIP 4337 and not here is creating an abstract account from scratch without having to upgrade an existing account.

An awkward part of this proposal, for Filecoin/EVM compatibility at least, is that the account owner must send at least one filecoin message to transition the account before they're able to send EVM messages as the account.

[anorth]

I don't think that's completely true, but there may be a subset that's affecting the hosted VM story.

An abstract account can be created from scratch with predictable actor address generation #379 (Init2).

I think you're saying that we can't create a non-built-in account at an address derived from a public key, which might be what you want for an actor to behave as an EVM EOA, with its own code being the EVM implementation. I don't think this would be a problem if the EVM took the "one actor hosts the whole VM state" approach, in which case the native built-in account actor would unwrap and forward a Filecoin message anyway (such forwarding wold not be EVM-specific). I can see the friction for the design where EVM state is dispersed across native actors.

[Stebalien]

So, a difference between the EVM and the current FVM is that the EVM allows sending funds to any address, even if no actor exists there. In Filecoin, we allow sending to non-existent accounts, but not arbitrary addresses.

In the next FVM version, we'll need to behave more like the EVM and allow sending funds to any address. I need to be able to deploy an actor at an address after you send funds to that address.

So, the specific flow I'm concerned about is:

1. User A sends a message to some address X that doesn't currently exist.
2. User B knows that the actor deployed at X will be an abstract account and would like to send a message from that account.

This proposal doesn't currently support this flow. However, we can support it:

1. Add some form of optional actor initialization parameters to messages.
2. When processing a message, if the "from" is registered on-chain (has funds) but has no code (is an embryo), attempt to initialize it with the initialization parameters.
3. If the actor correctly initializes to the target address, attempt to validate the message with the actor.
4. If that succeeds, execute the message normally.

The main issue with this approach is that, depending on how addresses are determined, a different actor could be deployed at the target address between validating the message in the message pool and executing it. I'm not sure if there's a great way around that.

[anorth]

If user B has to craft a special message the first time to auto-init their actor, is it really that much better than just requiring two messages: one to install/upgrade their code, then another to do the thing?

As a minor note, why not generalise the mechanism by deleting the "if the from address has funds" phrase?

Since writing my response above, I now understand that the intended design for EVM is the "state dispersed across native actors" one. So there is some friction here, but I'm not sure it's worth adding this complexity. There is a weirdness here that, for a CREATE2-style address, there's no third-party sending actor on which to base the address security (but I ack your proposal about the more generalised address creation algorithm elsewhere).

[Stebalien]

If user B has to craft a special message the first time to auto-init their actor, is it really that much better than just requiring two messages: one to install/upgrade their code, then another to do the thing?

The real issue is: where do we send this message from? If the user only has this abstract account, they have no way to send the message.

[arajasek]

@anorth I'm not sure I understand this part:

A message to an account actor from any other actor is read-only, and cannot modify the account actor’s state. Any attempt to replace the actor’s state root must abort. The exception to this is that a message originating from an account actor can modify its own state (including through a call sequence via other actors).

If actor X calls method M1 on account actor A, then M1 must be read-only. If so, then any methods called by M1 on A must also be read-only. Therefore, I don't see how an account actor can modify its own state through a call sequence via other actors.

(and I think this is what we want, because otherwise we could have A's state change without A's nonce changing, thus risking validity changing).

Am I misunderstanding something?

[anorth]

The read-onliness is a property of a particular execution of a method, not of the method code itself. I.e. it's to be enforced by the VM at runtime, but is not a static property of the method code.

So:

• If actor X (originates a call that eventually) invokes method M1 on account actor A, then M1 cannot change state (transitively, as you point out)
• If actor A (originates a call that eventually) invokes method M1 on account actor A, then M1 can change state

[mriise]

to be clear then: actor A can call actor X which calls M1 on A, and so M1 can change state since the call originated from A

[arajasek]

Okay, that clears it up, thanks! It's not how I was thinking the read-onliness would be enforced, but this does make sense. I think.

[anorth]

A recent write-up from someone enjoying AA on starknet gives a good outline of the value of some of the flexibility offered by this abstraction. https://hackmd.io/@s0lness/BJUb16Yo9

[mriise]

Under Restrictions on receiving it says that the runtime is constrained only when it is invoked from something originating from itself. This would mean the check to determine how constrained would need to be done at either before link-time or at runtime.

Since it was straightforward to implement at the moment, I've implemented a function that will set dynamic runtime check (that has read access to everything in Kernel) per syscall that will either continue normally or abort early from denied access. This approach would have its benefits as there can be extremely fined grained and programmable access control, which would lend future extensions a hand when giving/removing access to syscalls. mriise/ref-fvm@73c0f25

Personally though I would prefer to not link syscalls the kernel doesnt have access to at all, though that would mean adding a new type of kernel inside of the FVM (may be some workarounds though).

thoughts?

---

One thing that I am curious about is this line here The actor can read its own state, but must in effect be a pure function of that state and the message and signature.
Is this guaranteed to always be a pure effect of the message and its own state? (i believe it is but i would also believe it if it wasn't)

[anorth]

I think the restrictions must be a runtime property, not compile time. They depend on the message originator.

[mriise]

Yes in some sense both approaches are runtime: check is made per syscall is done at runtime of the actor and the FVM, and linktime (check is made before creating the WASM instance) is done at runtime for the FVM, but is compile time for the WASM module

[mriise]

The validate method has a restricted runtime. It cannot inspect any environmental variables (e.g. current epoch), check its own balance, nor send a message to any other actor. Any attempt to do so must abort.

Abort with what? FatalError(IllegalOperation) (Execution Error)? ExitCode(4) SYS_ILLEGAL_INSTRUCTION?

[anorth]

Good question. Either:

• The syscall could return an error code, then the actor can do what it likes
• The syscall can immediately abort, without returning control to the actor. In that case it should use a SYS_ exit code, but ultimately it doesn't much matter which one because the message will be invalid anyway

[Stebalien]

@mriise and I have been talking about this for a bit:

• The ability to pack multiple messages from a single abstract account into a single block is going to be pretty important. Unfortunately, Multicall will likely require some help from the client, and we'd like things to "just work" with existing Ethereum clients.
• The ability to mutate abstract accounts isn't all that important at the moment.
  • Neither Filecoin accounts nor Ethereum accounts need this ability.
  • If necessary, users that need mutability can split the account concept into an "identity" (mutable and permanent) and a "validator" (an immutable abstract "key"). This is similar to the relationship between accounts and multisigs today.

Proposal: For now, forbid mutation of abstract accounts after instantiation.

---

We also talked about future solutions here for allowing mutation, if desired (although I'm not convinced we actually need it). One solution would be some form of "self mutation" bit in off-chain messages. Blocks would only be able to include at most one message with this bit set. However, we'll need to get rid of tipsets first.

[anorth]

The ability to pack multiple messages from a single abstract account into a single block is going to be pretty important

Firstly, I would ask why. Is there a specific case you have in mind? I get that it's generally nice, but how important?

This proposal doesn't prevent packing multiple messages from a single account into a block, it just makes it a bit less likely in the general case. To do so, the miner/mpool has to either take some risk of redundant execution, or rely on heuristics for which code types are safe(r) to do it for.

Multicall will likely require some help from the client, and we'd like things to "just work" with existing Ethereum clients

Multicall is going to be super-easy for the native built-in account actor, and any wallet-like new accounts. The primary reason I haven't written the FIP for it yet is that it's so easy I was planning to mentor someone else to do so. Client support won't be a barrier here because most clients are either within our influence (like the nodes) or don't exist yet (dapps).

So it seems to me this is only a problem for Ethereum clients.

The ability to mutate abstract accounts isn't all that important at the moment

Mutable state for abstract accounts is critical for many of the use cases I'm targeting here, i.e. all of the wallet applications. They only don't need it yet because they don't exist because we don't have account abstraction.

So my summary of this request is thus that because existing EVM clients can't do multicall, we should prevent all state mutation in any abstract accounts. I would see this as EVM holding back Filecoin, but let's look for a solution where, say, only the EVM actors are immutable so that mpools can pack multiple messages for them safely - i.e. create a reliable heuristic. (The mechanism should be open to other abstract accounts that can't multicall too).

split the account concept into an "identity" (mutable and permanent) and a "validator" (an immutable abstract "key")

I don't 100% follow but would welcome more detail here to flesh our a design. Do you mean that the validator should encapsulate the entire validation function, so the VM will invoke validate() there? Validation is not just identity, but arbitrary rules. Messages should come "from" the identity - that will pay gas and appear as the origin sender. For validation to be flexible, the identify actor would need to be able to change which validator actor it was delegating too, so I don't think it solves the problem.

How about some design where an actor is statically marked as immutable, so mpools can trust its validation function is stable. Except perhaps for an easily identifiable message that can change that mutability, like something that can upgrade code. EVM can opt-in to that flag.

[Stebalien]

Firstly, I would ask why. Is there a specific case you have in mind? I get that it's generally nice, but how important?

Because not being able to do so would be really annoying? We have one block per 30 seconds. If we try to tell users that they can only submit a single message every 30 seconds, they're not going to be happy.

This proposal doesn't prevent packing multiple messages from a single account into a block, it just makes it a bit less likely in the general case.

The storage provider has no reason to take that risk.

Multicall is going to be super-easy for the native built-in account actor, and any wallet-like new accounts. The primary reason I haven't written the FIP for it yet is that it's so easy I was planning to mentor someone else to do so. Client support won't be a barrier here because most clients are either within our influence (like the nodes) or don't exist yet (dapps).

So it seems to me this is only a problem for Ethereum clients.

It's not just Ethereum clients. It's also not super simple from a UX perspective:

• The application usually signs the messages, which limits what clients like lotus can do. That means the application would need to submit an explicit multi-call.
• If a user performs a sequence of operations, batching these operations may be difficult. The application would have to delay submission of the operations to the Filecoin client, but usually doesn't have enough information to do that effectively:
  • It would need to do continuous gas estimation to figure out if all the messages fit inside a single block.
  • It would need to decide when to actually submit the sequence of messages.
• Lots of tools return transaction IDs/message IDs after an operation is performed. This makes auto-batching even more difficult.

Basically, I agree that users should batch, but I don't want users to click 10 buttons then have to wait ~5 minutes for their messages to even execute.

Mutable state for abstract accounts is critical for many of the use cases I'm targeting here, i.e. all of the wallet applications. They only don't need it yet because they don't exist because we don't have account abstraction.
...
I don't 100% follow but would welcome more detail here to flesh our a design.

I think this is the crux of the issue. My point is that any design requiring mutable accounts can be implemented with two actors.

You break your actor into two pieces:

1. A "validator" that validates off-chain messages. The validator is immutable and always accepts the same exact messages.
2. A "virtual account" actor that forwards/executes messages from one or more validators. The "virtual account" is mutable and should be considered the real account (where the validator is just an entrypoint).

If you need to change the rules about which messages to accept, you deploy a new validator and change the account to accept messages from the new validator instead of the old one. Importantly the old validator will still continue to function and messages from said old validator will still be considered "valid" from the chain's perspective. Instead of being rejected by the chain, they'll be rejected by the "virtual account".

The tricky part of this architecture is paying for gas as the funds will be stored in the "virtual account", not the validator. This can be handled by:

1. Storing some minimal funds in the validator.
2. "Topping up" the validator (from the virtual account) on every send.

(but I'll admit that these aren't great solutions)

How about some design where an actor is statically marked as immutable, so mpools can trust its validation function is stable. Except perhaps for an easily identifiable message that can change that mutability, like something that can upgrade code. EVM can opt-in to that flag.

At that point, I'd just add a mutable/exclusive bit to messages.

[Stebalien]

Ok, yeah, having to split these accounts in two is really annoying. I'm going to start a new thread on a having an "exclusive" bit.

[anorth]

Thanks, I'm down with exploring the "no self-mutation" bit approach, or the no-self-mutation static property, to constrain the abstraction leakage a bit more.

Because not being able to do so would be really annoying? We have one block per 30 seconds. If we try to tell users that they can only submit a single message every 30 seconds, they're not going to be happy.

I do get the general thrust, but we've failed to identify any actual annoyed user here. This is a hypothetical user group, and I expect it is quite small. In all my use of Ethereum, for example, only one app has ever submitted two messages at once, without waiting for the first to be executed (an ERC20 Approve then TransferFrom). I ack that there will be server-side, automated things that will have a much higher throughput, but many serious operations will be writing their own contracts to get transactionality at the same time anyway.

[multicall is] not super simple from a UX perspective

I think we have different users and different setups in mind. My users will be primarily interacting with dapps or other such APIs. The app code will construct the multicall. It will be a single blockchain message that executes multiple calls from the user's wallet contract. So yes, the application submits an explicit multicall.

I think you're talking about some kind of heuristic batching performed by Lotus or other nodes of transactions submitted over CLI or something. I don't see this as a majority use case, and if people are sophisticated enough to be doing that they can probably construct their own multicalls just like the dapp developer did.

FYI my multicall proposal is a new method Execute(calls: Vec<Call>) that we implement on the built-in account (and set as a standard for wallet contracts). It makes multiple calls, and thanks to account abstraction these all come from the right "from" address. Maybe a non-all-or-nothing flag could be added. Apps construct these multicalls. (Aside: this idea could extended of course to branching logic, passing values etc up to a complete scripting language, or even WASM bytecode, but with AA that can all be done in by non-builtin actors, so we only need to address the minimum for the built-in account actors).

[Stebalien]

Proposal: remove the GasSpec return from validate.

Basically validate can't make any decision that couldn't already have been made off-chain before submitting the message:

• It can't observe the effects of messages from other accounts.
• It doesn't have access to the account's balance.

This means that the user can always:

1. Run some validate_with_gas_spec function locally (i.e., the current validate function).
2. Include this gas spec in the message.
3. Run validate on-chain and have it verify that gas spec.

The downside of letting validate specify the gas spec is that we now need to track and cache it somewhere in the message pool and need to pass it around, completely ignoring the actual gas values specified on the message. This adds a lot of complexity without any real benefit.

cc @anorth

[anorth]

I understand that the gas spec involves some implementation effort in message pools to cache it from the validation output.

Removing it would limit the AA actor's ability to set good gas limit/price/tip, but possibly in an acceptable way. Rather than specify the gas spec, the AA actor would be limited to approving or rejecting that it receives.

Let's take a hypothetical simple multisig as an example:

• One way is that the multisig has gas spec recorded in state, and rejects any message with values that exceed that. In a naive impl, the gas params would not have been signed over by multi-signers, so the miner could construct a new message setting the miner tip to the max allowed by the actor, so the actor would essentially always pay that max tip. It would require an on-chain message to change the actor's state to set a new max tip value. But so would the original proposal, most likely.
• Would it be reasonable to expect signers to sign over the gas values too? The AA could then verify that the submitted gas values exactly match those agreed by all participants. One downside of this is that it would be quite annoying to change the fee cap in response to market conditions that change over the course of time (could be days) that multiple signers do their thing. They would have to set a relatively high value to avoid risk of having to start over. The base fee mechanic means they wouldn't pay too much for this. But it removes possibility of alternative policies like allowing a smaller N parties to set gas policy subsequent to message signing.

The general challenge here is that we can't assume the user submitting the message has any individual authority to spend the actor's funds, including on gas/tip. Is a simple veto power enough for the actor to have effective authority?

[Stebalien]

I believe the two solutions are necessarily equivalent. If the validate method on-chain can learn anything that cannot be known ahead-of-time by the user constructing the message, it can change it's answer from valid to invalid.

Given any solution where the actor might produce some gas value:

1. The last party to touch the message before submitting it can ask the actor what this value should be, effectively calling validate as currently proposed.
2. Said party can then include that value in the message unsigned.
3. The on-chain validate method can re-compute this value, and validate that the value appearing in the message matches the expected value, effectively calling the currently proposed validate method internally.

We're effectively pre-computing and caching the result of validate in the message itself and letting validate check to make sure that was done correctly.

[Stebalien]

So, even if we only allow one message per block, an attacker could effectively "spend" all gas in a block without paying for it:

1. The attacker deploys an abstract account with a special OnChainInvoke method that can be invoked via an internal send.
2. The attacker submits many cheap messages from many accounts calling OnChainInvoke on the abstract account in an attempt to "send away" all funds.
3. The attacker submits a single message that uses nearly a block-full of gas.

With high likelihood (1-1/(number of messages sent in step 2)), the attacker will be able to trick a miner into including a message that the miner will have to pay for.

The main issue with this attack is that anyone on the network would be able to pull it off for little cost (potentially attacking all blocks in a tipset at the same time). Unfortunately, limiting abstract accounts to single messages, or even getting rid of tipsets, doesn't help.

One possible solution is to not allow spends from on-chain sends, only from off-chain sends originating from the abstract account. Unfortunately, this severely limits some very valid abstract account use-cases.

Another solution is to set some form of "minimum balance" for abstract accounts where abstract accounts would be required to maintain enough funds for at least one off-chain send. But that's pretty terrible from a UX perspective (an account would appear to have funds, but would not be able to spend them).

Another is to introduce multi-stage tipset validation where:

1. In stage 1, we validate all messages and reserve funds for the maximum gas fees.
2. In stage 2, we execute messages.
3. In stage 3, we refund (we can also do this immediately after executing a message in stage 2, but it may be easier to just have 3 full stages).

• In terms of complexity, this would complicate some APIs a bit because we'd no longer incrementially execute blocks.
• In terms of performance, this won't have any effects due to caching. As a matter of fact, we can (later) use this as a way to discount the initial loading/execution of accounts through parallelization.

As complex as it is, I'm leaning towards 3 because it means that there's absolutely no way for execution to affect the validity of a message (allowing things like mutation, abstract account iniitalization, etc.).

[anorth]

I failed to specify originally that spending the actor's native token balance would also be excluded from actions available in the "read-only" context when receiving a send() with any originator other than the AA actor itself.

[Stebalien]

Proposal from @mriise: Time Travel

In this version, we can:

1. Allow any mutation except spends at any time. Spends can only be made by messages (i.e., value declared in the message's Value field).
2. Allow any number of messages in a block.

In this version, when we validate a message during block validation, we:

1. Call validate on the message.
2. If it succeeds, execute the message.
3. If it fails, re-validate the message with the initial state-root (the state-root at the beginning of the block).
4. If that fails, charge the storage provider for the gas consumed from both validations.
5. If it succeeds, charge the account for the gas consumed from both validations.

Analysis:

• Pro: This is pretty trivial to implement.
• Pro: We only execute valid messages, but we don't end up charging the storage provider for invalid messages (except when the balance is too low, but that can only happen due to tipset shenanigans and isn't a new problem).
• Pro: We can execute multiple messages from a single account per block.
• Con: Native tokens may only be spent from off-chain (but I don't think anyone will care about that?).
• Con: This doesn't handle off-chain deployment issues (still TBD).
• Con: We'd need to reserve (BaseFee * GasLimit) + Max(BaseFee * GasLimit, Value) up-front, instead of just (BaseFee * GasLimit) + Value
• Con: We can go over the block gas limit if we have to validate twice. But maybe that's OK? It's not free, and we can't go over by more than 2x (likely much less than that).

[Stebalien]

Interactions with f2 address generation

Currently, we assume that accounts have a "key address" and use this to derive a new f2 address. However, an abstract account may only have an f2 and f0 address.

In general, the "correct" address to use for abstract accounts is the f2 address due to its guaranteed reorg stability. Unfortunately, we don't store a mapping of actor IDs to f2 addresses anywhere.

We have two options:

1. Store a map of actor IDs to stable addresses in the init actor.
2. Store the f2 addresses in the actor state.

This gets complicated by the fact that we want to also store the f1/f3/f4 addresses in the actor state as the actor's "predictable" address (or "chosen" address).

Honestly, I don't know what the right solution here is. I think much of the complexity comes down to the fact that f4 addresses are optional.

[anorth]

However, an abstract account may only have an f2 and f0 address.

I don't quite understand the problem. This proposal doesn't talk about address types (it was drafted before the f4 proposal) but I'm not clear where they matter. What is the problem? Where would one want do to an ActorID -> f2 lookup? A sender can use the f2 address in their message, resolve to ActorID, call validate() etc.

However I also dispute the premise that the "correct" address to use for an AA is f2. I expect most users (e.g. by way of smart wallet provider) will have an f4 address that is predictable and thus also re-org stable, and have no use for f2. Sure there'll be some f4 classes that aren't, but I wouldn't expect them to be used as accounts.

[Stebalien]

When we create a new actor, we derive the actor's f2 address is derived from:

1. The origin's "key" address.
2. The message nonce.
3. The number of actors created due to the message so far.

The problem is that abstract accounts don't have "key" addresses, they have f2 addresses (and may have an f4 address). Unfortunately, there's no fast way to lookup their f2 address.

Ok. You know what, we can just use the address specified in the message's "from" field. That should be stable enough.

[anorth]

Thanks for explaining, I get it now. The issue is when the AA is an origin when creating an f2 address for another actor.

Your solution sounds reasonable tho. Even if the "from" is an ID address, it's now a signed token inside the message, so it can't change in the context of evaluation of that message. Weird things like creating multiple AAs with the same signing key/algo and then sending messages from them and then the creation of the AAs getting re-orged so they have different addresses could happen, but very edge.