Account View On UTXO Model (AVOUM)
Source: https://docs.google.com/document/d/12atK0oEME0y1GHo_HmqhrcZ3pQeEqB_0tFKknhsjsLY/edit
Why is this needed?
DoS attacks mean that a malicious party could race you, paying more transaction fees each time, to get their transaction which consumes the UTXO in before yours, although the intended semantics of the contract seem to assert that your transaction should be favoured.
For instance, given an auction contract, and two parties - Alice and Bob, suppose Alice was honest, and submitted a bid for 1ADA. Bob could watch the UTXO, submitting a bid in increments of 0.1ADA each time anyone makes a bid along with a high transaction fee. This would enable Bob to get their transaction in first, and beat all other competitors, although their auction bid was lower.
In Account model, this is not a problem, since transactions simply operate on the existing state, rather than an explicit state supplied by the user.
Inconvenience of having to resubmit transactions again and again, until they are accepted, under UTXO model. Why? In UTXO, burden of ensuring the TX goes through lies with the user, the state must be provided by the current user. If someone consumes UTXO before you, and their TX gets favoured - you need to resubmit your TX again, with the new state. This becomes a very real problem for heavily used contracts, since there will be heavy contention and frequent change to the associated UTXO(s).
In Account model, TX just gets run on current state, users can just fire and forget.
What is the solution?
Well we could have some technically sophisticated users, these users would be able to watch the blockchain at high-speed, and race all relevant rival transactions, in servers close to the miners.
Eventually we will have a market where sophisticated professionals will compete with each other to be the one who effectively posts the transaction.
A sophisticated professional will be able to ensure users’ transactions get through in a timely fashion to interact with frequently changing contracts.
High fees for these services would likely attract competition, until a market emerges, where sophisticated users compete to earn fees from users, driving those fees down.
Eventually miners would realize they could cut out the middleman between end-users and the blockchain by running those servers directly on their mining rigs, saving a lot in fees and network traffic for everyone.
How would this work? Transactions should be malleable, i.e. there are certain dynamic parts, specifically the UTXO, which should be able to be changed, with certain constraints.
Miners would then take on the responsibility of substituting the most recent contract UTXO for the one they posted.
Hence the blockchain will behave exactly as though it had an Account/Balance model.
What is all this competition for?
It is for blockchain space, who gets their transaction in. Space is limited, with scarcity, there becomes value. For instance block size limits, gas limit or implicitly via network bandwidth of winning miners.
Why? Now, the auction for blockchain space is a first price auction, since a second price auction would be gameable by miners. This is because miners can spend much less.
To support “account view” semantics, we will need a convention for assigning a persistent identifier to “the same” cell across transactions; we propose using the pair of (type script, first 32 bytes of cell data) for this purpose. The type scripts themselves can ensure that this pair is globally unique. We call these persistent identifiers “account ids,” and the chains of cells that they identify are “accounts.”
To clarify: Exactly one account id corresponds to one cell right? Not a chain of cells.
Miners and validators
UTXOs (Unspent Transaction outputs (UTXO)) allow you to parallelize the processing of transactions, since you can verify multiple UTXOs against their validator scripts in parallel. Consuming and producing UTXOs can be done in parallel.
Ethereum requires you to sequence transactions, since all of them operate on a single global state of accounts. To update the state you would have to do so in sequence.
Open contracts
On the user side, account model allows you to fire and forget, since miners will just use the tx on the existing state.
On the other side, UTXOs will require clients to watch their transactions, if UTXOs get consumed, their transactions may no longer be valid, and they have to repeatedly send txs until one gets through
