Problem: Coupling between account actor and VM

[raulk]

Today, the account actor is a special-case actor in multiple ways:

1. It is created implicitly by the VM when a value transfer occurs to an inexistent key address.
2. It can hold no logic.
3. It only contains one item of state (public key address), and the placement of this data in that location is questionable, because it forces the state tree to deserialize and understand a concrete actor state to resolve an ID address to a key address.
4. Unlike all other actors, it is externally owned and controlled through its own private key.
5. It has never changed (a side effect of having no logic associated with it).
6. All calls to it are infallible.
7. (Currently) it is the only valid origin for chain messages.

In a nutshell, accounts today are modelled as actors, although in practice they are treated as special entities. We are currently in the worst of both worlds:

1. Accounts aren't abstracted away entirely.
2. Accounts aren't non-actor entities.

Given that FVM is the main propeller of VM design iteration, we should initiate a discussion of where we want to go.

Precedents in Ethereum:

1. Since inception, there is a disctintion between EOA (externally-owned accounts) and contracts (i.e. actors).
2. An EIP has been filed to fully abstract accounts: https://eips.ethereum.org/EIPS/eip-2938.