Our coordination layer has a few problems that need to be solved in order to create a useable system:
Lets take each of these issues one by one.
The UTXO model and the account model are diametrically opposed on the issue of where "state" is held.
The account model takes the view that state is global, users push and pull on this state through their transactions. But crucially, transactions don't know which version of the state they will be applied on. Users need to design their transactions so that they are robust to state changes between when they first issued the transaction and when it lands on chain.
The UTXO model, on the other hand, sees the ledger state as a collection of tiny units of state. Each transaction consumes state units and transforms them into new state units.
Here users know exactly which state they are operating on. This is both powerful and a big problem that needs to be resolved.
The first issue is contention. Interacting with a distributed application likely means mutating shared state. In the account model, the latest shared state is implicitly referenced by transactions. But UTXO transactions are directly coupled to a particular snapshot of the application state.
Once a UTXO transaction operating on shared state is executed, the shared state UTXO is consumed, any pending transaction hoping to interact with the same application will now be invalid as it's attempting to double spend that application state UTXO.
There are many proposed solutions to contention in the UTXO model, the main ones being:
Sharding won't work for every application, the intent approach is the only known "general" solution to contention.
Now, you may be asking: "Isn't intent + executor re-inventing the account model in a complicated way?"
To answer this, we must first understand the strengths of the UTXO model and why we are using it.
Fundamentally, the two ledger paradigms come down to the decision of what is more fundamental: