Account abstraction/unification

[lrettig]

https://community.spacemesh.io/t/account-abstraction/151

spacemeshos/SMIPS#49

See also #64

To do:

• Consider alternatives to account unification #105 (@lrettig)

[lrettig]

We discussed this on the R&D call yesterday. We have rough consensus that it makes sense to move forward and turn this into a spec. I'll work on a SMIP. The main concerns were from Iddo, who's rightfully worried about: 1. the cost of spinning up SVM just to verify transactions (and the DoS risk), 2. multisigs with daily spending limits being drained through tx fees, and 3. implications on future validator role design. There are also outstanding questions re: how this impacts tx receipts, whether the default() method is allowed to touch state at all, and how we want to "unwrap" or "decompress" transaction data flowing into this method - natively, in Wasm/SVM, or some hybrid.

[avive]

1. It s my understanding form your notes in the forum that for 0.3 all txs will have the default() that can be implemented w/o spinning up the vm so the concern for svm spinning is only for future custom verifications - right? We also talked about precompiles in the research discussion.
2. I think that what we said is that this should be a vault setup param which sets the trust level between the parties. So this should be turned off by default for new vaults and only creators of new vaults can enable at spawn time it if they trust each other not to abuse via spending. For 0.3 we don't even need to implement this for vaults at all. Meaning, all spawned vaults will not allow custom verification.

So generally I think that what we want is a design that is forward-compatible to enable this feature (custom default()) in the future w/o changing the transaction syntax and signature procedure and for 0.3 only pre-compiled verification should be supported. This is the only way I see how this big feature can be designed and implemented in matter of weeks and not months.

[lrettig]

Re: 1., we still need to work this part out. It depends partly on design, partly on implementation. Ideally the design would involve spinning up the VM - otherwise, the entire idea of AA and a default() method is kidna pointless - but there are various possible optimizations, such as reusing a "warmed" VM instance, or bypassing the VM altogether for the first version.

This is intended to be a placeholder issue, @avive can we take further discussion to the research forum?

[lrettig]

To review:

• https://hackmd.io/@SamWilsn/ryhxoGp4D
• https://hackmd.io/@SamWilsn/S1UQDOzBv
• https://ethresear.ch/t/a-recap-of-where-we-are-at-on-account-abstraction/1721
• https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263/8

[lrettig]

design is complete and this has been implemented. will revisit as part of ongoing VM design work.