UTXO vs modelo de cuenta

Enprimer lugar,los utxos y las cuentasno sontan diferentes. Puede verelpar (account, counter) como casiequivalente a un utxo.

La razónprincipaltiene que ver conel acceso concurrente a contratosinteligentes. En lamayoría de los casos,dostransaccionesparaelmismo contratointeligente se conmutarán (o casi conmutarán) y,por lotanto,los remitentesnonecesitan saber qué otrastransaccionesestán afectandoeste contratoen particularen elmismobloque.

Porejemplo,imagine un contrato de venta debilletes de avión. Hasta queel aviónesté lleno,lastransacciones deese contrato se desplazarán. Mi compra de unboleto de avión y su compra de unboleto de aviónpueden ocurrir almismotiempo.

Siintentamosextenderelmodelo UTXO a contratosinteligentes,tanpronto como compremi boleto de avión,el contratoen cierto sentido se destruirá y un contrato similar que vende unboletomenos se volverá a crear con unidentificador diferente. Ambosnopodríamos acceder aese contratoen elmismobloque.

Si se deseaeste comportamiento,puede seremuladopor un sistema de contratointeligentebasadoen cuentas. Porejemplo,un contratopodría requerir que cadatransacción debepasar un hash de su almacenamiento actual. Sinembargo,lo contrarionoes cierto.

Por lotanto,el sistemabasadoen cuentasesmásexpresivo.

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.