Process generalization

[antho1404]

Current processes can only request an execution. If we think beyond that, executions are just a type of transaction so we might consider having a process as a series of transactions (some of them would be execution requests).

Pro:

• We could call any features in the chain (transfer, proposal, withdraw...)
• We could have a generic "transaction consensus"
• Any new feature added would automatically be accessible in any process
• We could call it "crowdsourced delegated transaction"

Con:

• We would expose all the features of MESG as something that can be scriptable in a process which might be risky

[NicolasMahe]

it's an interesting proposal, but brings a lot of issue on who is signing the transaction. If it's the emitters/runners, then they will not be able to sign transactions on behalf of the process, so they would need special authorization from the rest of the cosmos modules. If it's the process itself, then some kind of consensus should be passed in order to sign the message for the process. I don't see how it can work where the process doesn't have an account.

I think we could just extend the primary type of what a process can do. Instead of just "task", it could also "transfer", etc.. in this case, we would need to develop new modules/keepers that wait for the consensus to be reached and directly execute the action in the underlying module, bypassing the signer verification (exactly like the withdraw from resource functionality).