implicit and established accounts UX

[tzemanovic]

Depends on anoma/namada#8

The DKG wrapper txs can only be signed by implicit accounts, but the "inner" WASM transactions can interact with any account. To interact with these accounts, a user might keep some small amount of tokens in their implicit accounts to sign wrapper txs that might be transferring tokens owned by an established account.

This is somewhat flexible, as users are in control of their funds, but perhaps it is detrimental to the overall UX. For someone who doesn't need a programmable account, only using an implicit account is sufficient. But for those who want to deploy established accounts with custom VPs, the users would first have to understand the distinctions to make decisions on how much to put where and even then it's not clear cut. "How much will I need for fees for some future transactions?", "What if I don't have enough left in my implicit account to submit any txs?", etc. etc.

It should be possible to improve this flow without losing the flexibility. One way would be to allow to set "control" accounts for the implicit accounts VP (#193) that do not directly own the funds. Instead, these control accounts would be allowed to authorize transactions from the implicit account (the implicit account VP could check that if any of its control accounts address is in the transaction's verifier set, the implicit account VP can skip any checks and let the control account's VP decide the validity of the transaction). The advantage of the established control account vs an established account that directly owns the funds is that a user can leave all their funds in the implicit account, without worrying how much of it will go towards the tx fees and still deploy custom VPs to govern the rules of their funds. An extra bonus is that one can simply remove control accounts from an implicit account, attach multiple control accounts and even re-use control accounts for multiple accounts. Furthermore, the control accounts mechanism can be built from re-usable components, so that one can write an established account's VP that can have its own control accounts set.

Note that the control accounts would be relying on the tx calling the insert_verifier with the control account's address.

Open questions:

• do we want to sign the wrapper and the inner tx separately, re-use the same signature for both, or allow either?

┆Issue is synchronized with this Asana task by Unito

[juped]

This requires the implicit VP to use a bit more storage, but doesn't require ledger support, it can all go in the VP. An easy feature win.