Account abstraction (single account type)

[lrettig]

Breaking this out into a separate issue from https://github.com/spacemeshos/SMIPS/issues/13#issuecomment-635932947:

Account Abstraction

• All transactions, including simple coin transactions are smart contract txs. e.g. executed by the vm. Examples: eth 2.0, Libra move vm.
• Only 1 type of account in global state and not 2 e.g. users (EOA) and smart contracts.
• All accounts have code. At minimum, a "basic user account" uses a very simple template with send, receive, and withdraw functionality, using ED25519. Think about it like a multisig contract with only one signer. (Since the code is in fact contained in a template, there's only a pointer, so the actual on-mesh account size is tiny, only a few bytes.)

Pros:

• Devs and users don't need to worry about type of on-mesh accounts. Simplified transaction format - there are only smart contract transactions and atxs instead of 3 types: atxs, simple coin transfer and smart contract txs.
• A user can implement whichever signature scheme they want - they're not bound to ED25519.

Cons:

• Might be expensive to use SVM runtime to execute simple coin transactions. Lane response: The actual code can be implemented as a precompile, i.e., still run natively in go-spacemesh. It doesn't need to run in the VM. There would be a minimal amount of overhead associated with context switching into and out of the VM, but I think it's manageable, and even this, we could probably work around cleverly if necessary (e.g., we could probably avoid calling into the VM at all for the most common templates - the entire template could become a precompile).
• Makes metering a little more complicated. Typically, if the sig check fails, gas is not charged for a tx - but if you let the user write the sig check code, you have a catch-22. There are lots of ways to work around this (provide a hardcoded set of trusted sig check templates, refuse to perform more than a certain basic amount of work before charging gas, etc.).
• Need to keep tx size small. Simple coin tx using ED25519++ is packed and small by design (100 bytes). It might be larger as a standard SVM transaction and therefore may cause higher mesh growth rate. It is critical we'll keep coin transactions packed as small as they are the fundamental transaction type in the system and even with heavy smart contracts use at least 50% of txs are expected to be of the simple kind. Lane response: I think it's worth digging a little deeper into this - how compact we could make transactions of this sort, and how much overhead there might be with account abstraction.

CC @avive @YaronWittenstein