What are the drivers behind the decision to adopt an account model (as opposed to an utxo one) to describe transactions in Tezos ?
Add a comment
|
2 Answers
First off, utxos and accounts aren't that different. You can look at the pair (account, counter) as almost equivalent to a utxo.
The main reason has to do with concurrent access to smart contracts. In most cases, two transactions to the same smart-contract will commute (or almost commute) and therefore the senders do not need to know what other transactions are affecting this particular contract in the same block.
For instance, imagine a contract selling plane tickets. Until the plane is full, transactions to that contract will commute. My buying a plane ticket and your buying a plane ticket can happen at the same time.
If we try and extend the UTXO model to smart-contracts, as soon as I buy my plane ticket, the contract would in a sense be destroyed, and a similar contract selling one fewer ticket would be recreated with a different handle. We would not both be able to access that contract in the same block.
If this behavior is desired, it can be emulated by an account based smart-contract system. For instance, a contract could require that every transaction to it must pass a hash of its current storage. However, the reverse is not true.
Therefore, the account based system is more expressive.
-
1Thanks a lot it is very clear! I remember you were also talking about the flipside of this when it comes to mempool management i believe where UTXO make it easier for a miner to choose any subset of tx to include because the final chain state is indifferent to the order of those UTXO being applied whereas in an account model the order of tx hitting a contract may impact its final state. But i forgot what constraint it creates on the mempool management itself.– EzyFeb 1, 2019 at 11:54
-
2I have since realized that really matters is that you keep utxo like properties for the payment of transaction fees. If you do that, you get all the benefits of mempool management and quasi-commutativity of operations.– Arthur BFeb 1, 2019 at 12:17
-
1tx. I would like to understand your last remark better. Worth a separate question ?– EzyFeb 1, 2019 at 12:23
-
2Happy to answer a separate question, so long as it's clearly stated :)– Arthur BFeb 1, 2019 at 13:02
-
1
I am not sure if this first answer is still holding true. Other UTxO based blockchains have proven to make smart contracts work, such as Ergo or Cardano.
Both use something called eUTxO (Extended Unspent Transaction Output) Model. In that smart contracts (or validator scripts) can either be attached to a transaction or via script reference read from chain. They are not destroyed or reconstructed if one interacts with them.
Taking a look at the plane sale example: A corresponding smart contract on a blockchain like Cardano could just have N unspent outputs sitting at the PlaneSaleScript address holding your Plane ticket NFT. Each of these outputs can be spent when a given amount of USDC or whatever is provided and paid to the contract. If the Tx succeeds you spent the output at the script address, receive the NFT ticket and pay the planer seller. Concurrency or Smart Contract destruction is not a problem.
It's just a matter of a different architecture design. So I do not see a difference in expressiveness, as there are counterexample of UTxO based smart contract blockchain which allow you to build the same stuff like account based smart contract blockchains.
