Account abstraction (single account type)

[lrettig]

Breaking this out into a separate issue from spacemeshos/SMIPS#13 (comment):

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

[lrettig]

We discussed this proposal a bit during today's design review. Two important concerns were raised:

• All transactions ultimately need to originate from an EOA (simple account) that uses a sanctioned signature scheme, for fear of DoS attacks, as well as the metering issue described above (I don't personally fully understand this concern but I want to look into it and understand it better)
• If we simultaneously say we want a single, unified tx type, but at the same time, to have a special case for, e.g., a simple coin tx, where the first bit or bits indicates the special, smaller format, with a special code path to handle it, etc., then we are being hypocritical and contradicting ourselves and we are playing with semantics. In other words, it's one or the other: a single tx type, or efficient representation.

[avive]

Please discuss with @iddo333

[lrettig]

See also #82 (comment)

[avive]

@lrettig Didn't you move this issue to the PM repo?

[lrettig]

Yes, see spacemeshos/pm#3 and the forum thread linked there. You can close this in favor of that if you like.