Layer 1.5: State modes
Joachim Zahnentferner (IOHK)
Statefulness of account-based model
multiple parties must provide some form of input, then after some period of time those parties must perform some additional operation, and then finally the contract disburses funds as a function of those operations, then it is difficult to see how to fit that model into fundamentally stateless objects that can only be spent or not spent.
To give another example, one potentially desirable use case is the ability to prevent asset theft by introducing a “recovery key” which would be stored in a secure location and could reverse transactions from your main account within some particular period of time. In a UTXO model, even an expanded one where transaction outputs can impose requirements on the destination addresses that they are sent to, this is a challenge worthy of an academic research paper. In an account-based model, this can be implemented in 20 minutes of coding time via a smart contract that simply implements the rules directly. Restricting asset ownership to a specific set of parties (eg. KYC’d users) is another example which can be managed with some complexity with covenants, but which is a simple code writing exercise in a smart contract account-based model. It is worth noting that these are advantages of a stateful scripting language more than they are benefits of accounts vs UTXOs; without a stateful scripting language (eg. in NXT) account-based models also cannot easily do any of this. However, the notion of a statically addressable object makes the logic around implementing these stateful systems in practice much simpler and more developer-friendly.
See also: