Lesson 5: UTXO
Nothing is loaded from YouTube until you press play, and then without tracking cookies.
About this video
For a better learning experience, sign up and enroll in this free course at: daml.talentlms.com/plus/catalog/courses/151
Transcript
1,677 wordsCaptions as YouTube publishes them, usually machine-generated, so names such as Daml and Canton can be misheard.
- 0:00
this lesson introduces a recordkeeping model called utxo which can be implemented in place of the account balance model to guarantee privacy at the subtransaction level as a reminder in the implementation of the account balance model when assets were being transferred between two parties the account balance of the recipient became visible to the sender non- stakeholders May gain visibility into contracts being created
- 0:29
or fed as a consequence of exercising a choice and it can be addressed by implementing a different recordkeeping model utxo stands for unspent transaction output it's a model used in blockchain technology to keep track of the cryptocurrency tokens in a user's wallet utxo was originally introduced in Bitcoin and it is now used in most blockchains with the notable exception of ethereum which uses the account balance
- 1:02
model in the utxo model each transaction creates zero or more unspent transaction outputs which can then be used as inputs in future transactions essentially it tracks the individual units of assets that have not yet been spent and these units are used as the building blocks for new transactions U XO model is commonly used in daml to represent assets as implementing the model in daml helps
- 1:33
ensure privacy at the subtransaction level although the model is applied exclusively to digital coins or tokens it is commonly represented using a physical wallet as an analogy for instance in a scenario where a payment of $30 is required and your physical wallet contains a $10 bill a $20 bill and a $100 bill you would combine the $10 bill and the $20 bill to cover the $30 charge it is noteworthy that there is no need to disclose the presence of the $100 bill in your wallet to the
- 2:14
counterparty nor does the counterparty need to divulge the total amount in their wallet when receiving the $30 payment from you this exemplifies the privacy and selectivity inherent in the model's transaction process the same goes for Alice and Bob let's say that Alice has three asset contracts with the values of $15 $25 and $25 if Alice wants to transfer $30 to Bob she can first merge her existing
- 2:48
assets of $15 and $25 to First create $40 in this process Alice's $15 and $25 contracts are are archived or in another word they are spent this $40 can then be split into $30 and $10 a $10 asset contract which is invisible to Bob is created for Alice and the $30 being transferred from Alice becomes visible to both Bob and Alice in the form of asset transfer proposal contract as Bob accepts The Proposal a new 30 $ asset contract is created for
- 3:33
Bob since Bob's $30 and Alice's $10 asset contracts are created as a result of the transaction they are the transaction output since Alice's other $25 asset contract is not involved in the transaction it remains as is without becoming visible to Bob Alice's assets with the values of $10 and $25 are the unspent transaction output which can potentially be merged and split to be spent in her future transactions if Bob has another asset contract with a value of
- 4:12
$100 this contract is also not involved in the transfer transaction and therefore is not revealed to Alice to revise the account balance version of the transaction workflow to implement utxo a few changes must be made first of all in the asset template the key and maintainer are removed since in the utx model parties must be able to keep several asset contracts of the same issuer asset contracts must be allowed
- 4:44
to be merged and split for parties to create the exact transferring amount therefore asset cannot be unique within the scope of issuer and owner and the key and maintainer must be removed in in the asset transfer Choice the transfer amount field is removed and only the recipient field remains for a party to transfer a certain amount of asset an asset contract with the exact transferring amount will be created therefore there's no need to specify the
- 5:16
transferring amount in the body of asset transfer Choice the asset transfer proposal contract is created with the recipient and the keyword this which refers to the payload of the asset contract on which the asset transfer choice is being exercised the asset merge and asset split choices are newly added the asset merge Choice takes the contract ID of another asset contract as its
- 5:47
parameter the payload of the other asset is fetched to be validated once it's confirmed that the issuer and owner information on the payload is valid the other contract is archived from the payload of the other asset the amount is extracted to be combined with the asset on which the merge choice is exercised a new asset is created with the merged amount the asset split Choice takes an amount to be split as a
- 6:19
parameter it creates two new asset contracts one with the split amount and the other with the remainder after the split amount has been subtracted from the original amount the two newly created asset contracts are returned as a record type split result split result has two Fields split asset and remainder and it derives from the EQ and show typ of classes considering that the choices within the asset template Encompass a
- 6:50
proposal that includes an asset payload the creation of a new asset and assets encapsulated within a record it's important to note that all these choices are consuming as the assets owner is the primary Authority responsible for decision- making concerning the asset they are the controller for all the choices finally the asset transfer proposal is revised to have two Fields asset payload and recipient the signatory of The Proposal
- 7:24
remains to be the same as that of asset passing the signatory of the asset pay load as the signatory of The Proposal contract is to indicate that the two contracts must have matching signatories it can be Rewritten as asset. issuer and asset. owner to serve the same purpose since the amount field is included in the asset payload the insure statement must refer to the amount of asset as asset.
- 7:55
amount now the asset transfer proposal accept choice does not fetch the receiving party's account balance to create a new balance anymore it simply creates a new asset with the recipient as the new owner by using the asset payload by avoiding a fetch of the recipient's existing assets the recipient's asset balance remains undisclosed to the sending party asset transfer proposal reject creates a new asset using the existing
- 8:25
payload without changing any information in it the return type is changed from contract ID asset transfer proposal to contract ID asset to indicate that once the proposal is rejected by the receiver a new asset contract is created without assigning the receiver as the new owner Let's test the code with a hypothetical scenario where the US Bank has asset contracts $700 and $300 but needs to transfer $400 to Alice
- 8:59
and $600 to Bob UB creates two new asset contracts with $700 and $300 since UB intends to transfer $400 to Alice UB exercises asset merge on the asset contract with $700 by passing the other asset contract with $300 as an argument to create a new asset contract with the amount of $1,000 UB then exercises asset split on the merged asset to split it into two new asset contracts containing $400 and
- 9:40
$600 as a reminder exercising asset split Returns the two split asset contracts encapsulated in a record UB Keys into the split asset in the splitted UB asset record to transfer the asset $400 to Alice which she accepts UB Keys into the remainder in the splitted UB asset record to transfer the remaining $600 to Bob which he accepts finally Alice transfers her $400 to Bob and Bob accepts it let's take a closer look at this part in the transaction
- 10:19
view at number 80 Alice is the required authorizer of the asset transfer exercise action which creates an asset transfer proposal contract with Bob as the recipient at number 81 at number 90 when Bob exercises asset transfer proposal accept choice on the proposal contract created from number 81 there are three stakeholders who can view the transaction Bob the required authorizer
- 10:50
Alice and UB the signatories of the asset transfer proposal contract on which Bob exercises the accept choice the consequence of Bob accepting the proposal is the creation of the new asset contract of $400 with Bob as the new owner in the newly created asset contract Bob the owner and UB the issuer are the stakeholders although all three parties including Alice gained visibility into the creation of the new asset contract the only asset amount
- 11:24
visible to Alice the non- stakeholder is the $400 that she offered to Bob in the table view Bob now has two separate contracts at number 91 the letter W under Alice indicates that Alice was able to witness the creation of the contract with $400 however at number 71 Alice cannot see Bob's other contract with $600 Alice also did not gain any visibility into the total amount of assets that Bob owns Which is $1,000 in the context of the account balance model's asset transfers between
- 12:07
parties a notable issue emerged where the recipient's account balance was divulged to the sender to address this issue the utxo model was introduced in the utxo model each transaction creates zero or more unspent transaction outputs that can subsequently serve as input in future transactions in daml utxo is used to represent assets as a discrete set of contracts that when combined constitute
- 12:39
the account balance rather than a single contract representing the account balance for illustration this concept is often likened to a physical wallet containing paper bills the utxo model helps to achieve privacy at the subtransaction level and improves performance of daml applications in terms of business transactions throughput