Advantages of E-UTXO
Cardano uses the Extended UTXO model, abbreviated EUTXO. The purpose of the EUTXO model is to support higher expressiveness of programmability while maintaining all the benefits of Bitcoin’s UTXO model. The extended UTXO model is important to Cardano because it wants to be more than just a transactional network. Cardano is a platform, so it is important to allow developers to build more complex functionality. This is achieved through smart contracts. In the case of Cardano, it is more accurate to talk about validator scripts. In the text, we may use these terms interchangeably, but they are the same.
EUTXO offers some advantages over the account-based model. In particular, greater security when executing smart contracts, fee predictability, local verification ensuring that transactions will be accepted after the submission, and an inherently fragmented blockchain state. This allows parallelization in transaction processing, which has a positive effect on on-chain scalability. Parallelization is also important for the execution of smart contracts. Like transactions, smart contracts can also be executed independently, i.e., in parallel.
When processing smart contracts, the order in the block does not matter, there is no need to consider the execution results of other contracts in the block, so the execution itself can be considered more secure. In other words, since the individual smart contract execution results are independent of each other and there is no shared mutable (global) state, there is less surface for attacks.
It is important to note that the scalability of decentralized applications is based on the capabilities of the accounting model. In general, smart contracts and their execution can be seen as a layer that depends on the capabilities of the blockchain.
The parallelization options are based on the original UTXO design, where each existing unspent UTXO is made up of a sequence of previous transactions. Each EUTXO can be handled independently. There is no such thing as the global state that needs to be taken into account during the handling and validation of EUTXO. Only the local state is important. It means that the outcome of the transaction depends only on the use of UTXOs which are immutable, single-use objects that act as the input of transactions that will produce outputs.
Each transaction can consume one or more EUTXOs, which will create new EUTXOs that will have the same total value. The only way a transaction can influence the effect of another transaction applied to the ledger is by spending the same EUTXO as the later transaction attempts to spend, thus causing the node to reject it.
If a transaction passes local validation, the user can be almost certain that the transaction will make it to a new block. Transactions in the EUTXO model are independent of each other and are deterministic, meaning that the transaction will very likely not fail. It is also true for the validation of Plutus scripts. Users can check locally that a Plutus script can be submitted and run on-chain. It ensures that fees are never lost. One rule must be followed, however, namely that each EUTXO can only be spent only once and as a whole within a block.
The spending of UTXO must be accepted by the entire network as part of the addition of a new block. This means that the UTXO recipient can only spend it in the next block. Not in the same block in which the UTXO was received. The addition of a new block can be considered a state transition of Cardano’s blockchain. However, in the blocks themselves, the individual transactions and EUTXOs are independent of each other.
The EUTXO model is more deterministic than the account-based model, but a transaction can still be rejected. Rejection means that despite the transaction being correctly constructed, it cannot be applied to the blockchain. If this happens, the transaction has no effect on the state of the blockchain, so no fees are paid. A transaction rejection occurs in the event of contention. This means that the state of the blockchain changed at approximately the same time that the user constructed a transaction locally. The local validation has passed, but the blockchain state is already different at the moment of submission. Determinism ensures that, whenever a transaction is accepted, it will only have predictable effects on the ledger state. In other words, it will have the same effect on the ledger state as it has during construction and local validation.
It can be more difficult for a developer to create a validator script since they have to deal with concurrency themselves. Transactions can run into contention if they depend on the same EUTXO at the same time. For example, if a few EUTXOs were locked by a smart contract then only a single agent can interact with them inside one block. Notice that this limitation applies only to EUTXO. Different agents can interact with other smart contracts without any concurrency failure. A smart contract can handle a number of different UTXOs that make up its current state and off-chain metadata that allows interpreting those UTXOs.
Parallelization, or the ability to perform multiple independent operations simultaneously, is an important feature in terms of overall network performance and scalability. The global state of the account-based model limits the scalability options, as it is extremely difficult to achieve parallelization in transaction processing and also smart contract execution. With the EUTXO model, a higher level of concurrency can be achieved, which opens the door for increased scalability.
Let’s take a look at what’s new about the EUTXO model compared to the UTXO model, which uses Bitcoin. Processing a transaction in the Cardano network involves validating the requested action. The node verifies that it is able to perform the requested action and that the author of the transaction has provided relevant data/inputs.
The common action is for ordinary transactions that intend to spend EUTXOs that are locked with a public key. Node validates that the author of the transaction has provided a digital signature with the corresponding private key. The action, i.e. consuming the EUTXO, will be performed if the validation is successful. There is nothing new here yet compared to Bitcoin.
The next action is to validate transactions that intend to spend EUTXOs that are locked by a script address.
A script is a program (a piece of code) that decides whether or not the transaction that spends the EUTXO is authorized to do so. A script contains pure functions whose result is either True or False. To validate a transaction, the node invokes the script interpreter, which is a program that can translate and execute Plutus script code. The interpreter executes the script whose hash has been formed by the address where UTXOs are locked. In other words, when a EUTXO is locked by a Plutus script, that EUTXO’s script code is associated with its address.
Let’s take a look at what’s really innovative about EUTXO compared to Bitcoin besides the higher expressiveness of programmability enabled by Plutus.
Extended UTXO allows users to optionally add arbitrary user data in JSON-like format to UTXO. This data is called Datum. The Datum will allow developers to give scripts state-like functionality. User data can be considered as a local script state. This state has only local validity as it is associated with a specific UTXO. Using the full potential of Datum is up to the developers.
Transactions can carry user-specific arguments, called a Redeemer. Redeemer can be viewed as the intention of the author of the transaction on how to spend the UTXO. Redeemer can be used by developers of decentralized applications for various purposes.
There usually is a binding between Datum and Redeemer that depends on the specific functionality of a particular application. When a transaction is being validated, a validation script operates with Datum, Redeemer, and context that includes transaction data. The script contains conditions that allow consuming UTXO when they are met. The Datum, Redeemer, and transaction context are data that are input to the script.
In order to spend EUTXOs that are locked by a script, it is first necessary to get the script into the blockchain. Unlocking the UTXO will depend on the script, so the transaction will contain the script and also the UTXOs to be locked.
Developers (or their applications) write Plutus on-chain code and package it in a special format. Then, a transaction must be created into which the Plutus script will be embedded. Once the transaction has been stored in the blockchain, another transaction can be sent to initiate the execution of the script. The transaction can be seen as a message to the script.
Developers divide applications into on-chain and off-chain code. Off-chain code can be part of the wallet, or it can be a decentralized application (DEX). The off-chain part of the application can create a transaction that contains the on-chain script and EUTXOs that are to be locked. For every EUTXO the hash of Datum needs to be specified. The user has to sign the transaction. After the transaction is submitted and accepted by the network, EUTXOs will be locked by the script.
Validating a script is much more resource-demanding than validating a regular transaction. One source of indeterminism can be the size of the smart contract/script execution fees. In the case of Cardano, the budget for executing the script is part of the transaction and it is possible to calculate the exact fee locally in advance. The script interpreter tracks resource consumption during script execution in the context of the budget. If the execution budget is exhausted, the script evaluation stops and the result is False. A false value means that the EUTXO will not be consumed.
Note that the Plutus script only works with the state that is associated with the EUTXO and further with the data it receives in the transaction. The script execution does not depend on anything else. The only thing that will change from a ledger perspective on a global level is moving EUTXOs from addresses to other addresses with every newly added block.
The same contract can be used to lock Alice and Bob’s coins. Executing the script for Alice’s coins has no effect on executing the script for Bob’s coins, as they are two independent executions for separate EUTXOs. The result of the two individual execution depends on the local states.
A spending transaction (message transaction) is constructed in order to interact with a script. The input of the transaction can be the EUTXO that is locked by the script. Spending transaction invokes script interpreter in order to validate the script and unlock EUTXO if the conditions are met. Thus, unlocked EUTXO is transferred to a new address.
Some applications may need to work with a global state across multiple EUTXOs and can use Datum to do so. A kind of global state is achievable within a particular protocol design. Designers of protocols must be aware that if EUTXOs are locked by a script only a single agent can interact with it inside one block. It might require some kind of synchronization between agents.
Let’s illustrate this with an example. The liquidity pools that AMM DEX uses are shared resources because users want to use them at the same time (within the same block). Every liquidity pool contains a set of EUTXOs. Available EUTXOs are therefore also shared resources since unless an agent reserves a particular EUTXO for itself in some agreed way, they are available to everyone else.
The application algorithm must ensure that when transactions are constructed, individual agents do not contend for the EUTXOs in the pool. The transactions that want to consume a particular EUTXO are independent of each other from a validation perspective. However, the dependency exists since multiple agents might want to consume the same resource (the same EUTXO) at the same time to construct a transaction. In other words, agents want to work concurrently. One solution that is currently used is bulk transactions. Agents search for suitable request UTXOs that want to interact with a particular liquidity pool in order to fulfill the requested swap. Agents do that with all other available swap requests in mind and insert selected swaps into one big batch transaction. When creating a batch transaction, agents know what EUTXOs has already been used. They can ensure that a particular EUTXO is not used twice within a batch transaction.
If you want to learn more about the history, compare Bitcoin's UTXO to EUTXO, or look at the differences between Cardano and Ethereum, read the full article:
https://cardanians.io/en/understanding-cardano-extended-utxo-200
No comments:
Post a Comment