UTXOとアカウントモデル

まず、utxosとアカウントはそれほど違いはありません. (account, counter)のペアはutxoとほぼ同等であると見なすことができます.

主な理由は、スマートコントラクトへの同時アクセスに関係しています.ほとんどの場合、同じスマートコントラクトへの2つのトランザクションは通勤します(またはほとんど通勤します).したがって、送信者は、同じブロック内のこの特定のコントラクトに影響を与えている他のトランザクションを知る必要はありません.

たとえば、飛行機のチケットを販売する契約を想像してみてください.飛行機がいっぱいになるまで、その契約へのトランザクションは通勤します.飛行機のチケットの購入と飛行機のチケットの購入は同時に発生する可能性があります.

UTXOモデルをスマートコントラクトに拡張しようとすると、飛行機のチケットを購入するとすぐに契約が破棄され、チケットを1枚少なく販売する同様の契約が別のハンドルで再作成されます.両方が同じブロック内でその契約にアクセスすることはできません.

この動作が必要な場合は、アカウントベースのスマートコントラクトシステムでエミュレートできます. たとえば、コントラクトでは、コントラクトへのすべてのトランザクションで現在のストレージのハッシュを渡す必要がある場合があります.ただし、その逆は当てはまりません.

したがって、アカウントベースのシステムはより表現力豊かです.

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.