Hyperledger Foundation Hyperledger Global Forum 2021, 21 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: UTXO and Account Models: The Good, the Bad, and the Costly - Anthony Lusardi, Digital Asset

Description

UTXO and Account Models: The Good, the Bad, and the Costly - Anthony Lusardi, Digital Asset

Let's take a look at UTXO and Account models, what they are, how they work, and how we're leveraging UTXOs with the smart contract language Daml to provide reliable, resilient, and cost-effective distributed applications. The first half of the talk will be a high level walkthrough of the UTXO and account-based models where anyone with an interest in blockchain-based applications can follow along. After that we'll dive into some more of the technical considerations and how crucial of a design choice these two options are. You'll walk away with a deeper understanding of design considerations, why you might want to use UTXOs, and how to choose between the two.

To learn more about Hyperledger, the open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments. Which serves as a neutral home for various distributed ledger frameworks including Hyperledger Fabric, Sawtooth, Indy, as well as tools like Hyperledger Caliper and libraries like Hyperledger Ursa click here: https://www.hyperledger.org/

Session Details & Slides (if available)- https://sched.co/j3ar
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/

----
Hyperledger – Open Source Blockchain Technologies

Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use

Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory

Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter

Follow-us on Twitter @Hyperledger

Learn about Hyperledger Membership: https://www.hyperledger.org/about/join

#Hyperledger #HyperledgerGlobalForum2021 #Blockchain

A

So what we're going to be talking today is about utxo and account models, kind of the good, the bad and the costly for them. I would like to first you know, thank you very much to hyperledger global forum for uh having me here talk about this very interesting technical topic. That applies, I think, really.

A

I support both models, but we'll talk about that in a little bit and yeah, I myself am a developer advocate. I work on a programming, language and tech stack called damo, but when I give talks, I tend to like to give talks that are more about simply the tech. uh I think demo is a great piece of tech, but I really like, I think, that it's important to break down these different components of the technology, so we can really understand them and what the good bet and and cost tradeoffs are on them.

A

um Like I said too, if you ask a question in the q a or in the chat and you're one of the first five you can see in the chat there's an email address, there just shoot me an email and I'll. Send you a t-shirt. If you want one so first we're going to be painting with very broad strokes, uh even a single real world implementation of a utxo or account model requires a lot of specificity and would take longer than than the time we have allowed here to go over.

A

So just keep that in mind that I'm talking about how these systems generally behave and there will always be specific examples of them. That will be different, different ways uh and so in the first half I'll be talking about the general and then, if we have time in the second half, I will be going into actually some real life examples that do get much more to the specificity of things.

A

So, first, you know what are utxos and accounts. uh Both of them are any system of accounting or state management, so that in and of that they are the same. They are systems to uh manage some some semblance of accounting or state and in a utxo model. Basically, every previous entry consume is consumed by a new entry such that the prior entries can't be consumed anymore. So, for example, if I had a dollar- and I gave it to you- I couldn't spend that dollar anymore, but now you could spend that dollar.

A

That's kind of how utxos work compared to the the real world and in accounts, uh there's perpetually existing entries that can be updated and accessed again in the future. For example, that would be like a credit card. If I gave you my credit card number, you could charge it and then uh an account balance would update on my end, and I could actually go and use that same number again.

A

Somewhere else, so accounts sometimes fit a little more closely to how we model and conceive of the world, but also sometimes that could be much too uh kind of their. That can also be a disadvantage in some ways. We'll talk about that in a little bit. So first, it helps to kind of cement ourselves in real world examples of utxon account models.

A

There's a real world equivalence of both that have existed for a really long time. uh Utxos largely exist in the form of divisible and fungible bearer instruments, so that would be dollars and coins and gold, and all that fun, stuff and accounts exist really in various forms of ledgers uh that involve you, know single and double entry, bookkeeping that could be dead, ious bank deposits and these very interesting things called bullet which are very early forms of double entry, accounting that I think, are interesting because people were actually able to hold them.

A

So what they would do is they would take these little stones here, press them into the outside of it into this piece of clay and then put them inside the piece of clay and seal it up and let it dry.

A

And then you can make sure that people couldn't modify the outside of it uh to to have a different value than what the inside of it said, and that's a really interesting piece of early technology that I think that I think is quite cool but yeah and then generally, when we think of ut excels in account models too in the in the real world and meet space.

A

uh You know it largely comes along with money, but when these things are brought into the digital world they don't only apply to money. They also can apply to other ideas. uh You know you can have purely digital non-monetary accounts on social media email software subscriptions different service providers, providing all sorts of services that essentially use these types of models in different ways.

A

So now we'll talk about blockchains, our favorite, so there's some technical examples of utxon account models. uh You'll notice fabrics actually on both of these, but when we think of them, largely probably the most common popular ones on the utxo side is, is bitcoin and on the account side, is ethereum and we'll go into some part of the reasons why those choices were made in a little bit.

A

But then you know we have others, for example, like damo, uh runs entirely on utxos and a slightly different model, but, like I said before, you know, there's there's too much specificity to go into into that and then same for corda, largely utxos, but again there's some specificity there that I'm going to simply gloss over and then also you know you have besu on the account side, which is another ethereum derived derived option and then uh fabric actually does both and that's because fabric, really this general key store where you can commit any data.

A

You want and and read it uh later. So those are the various technical examples of utxo and account models that you can kind of think about as we go through the rest of this and yeah. So in more in more specific ways. Now we can talk about kind of what's good about these models and what's bad about these models. So on the utxo side we tend to have uh much more privacy by default.

A

I'll actually show that an example in a little bit, because you t, because there's no there's no notion of accounts, you don't have so many connections between all the different going ons on the network, uh because there's less connections you can actually prune the state more easily and because every utxo depends on previous ones and they can't access arbitrary state that removes large classes of bugs which hopefully, if we have time, I can demonstrate for you.

A

Also. Every participant only needs to know about the utxos that they're involved with in order to use the system this. This contrasts with accounts, where accounts largely confer also having rich state access. I presume you could have a model where there are accounts, but they don't have rich state I've just never seen one in the wild, but essentially with that. That means that you know you only need to share the parts of the ut excel set that are important to you and relevant to you and, if something's not relevant to you.

A

If say it was between two other people. You wouldn't uh have have to have to involve yourself with that, and you also get much more parallelizable operations, which basically means uh when you have your your ut excels. If two of them aren't related, you can execute both of them at the same exact time, and it's not going to matter. Some of the bads, though, are that you have constant contention in a ut excel type system.

A

You know if two transactions simultaneously use the same previously existing input, uh then they're going to conflict and you're going to have to pick which one is the right one and that can sometimes lead to unintended effects or unexpected unexpected things, uh some race conditions, but the nice thing is that the race conditions never propagate, they kind of just one of them will come to a halt, and it also requires you know, learning a new way to reason about and structure your programs, so that, I think, is probably one of the biggest negatives of a utxo model.

A

Is that it's very much different from the way we normally model and think about things in our real lives. Even though we have lots of experience with uh utxos in in real life with things like cash, we don't really reason about the world in that way, and sometimes and often you get larger transaction sizes, again implementation specific, not going to go into that account.

A

Models uh tend to have smaller transaction sizes and theoretically, less storage, because you have to keep around less data again implementation specific, and you know they allow for very trivial arbitrary state access, which is great when you're building very complex applications, or at least uh previously seem to be to do it. But now we're we're.

A

Learning that really you don't need account models in order to have a a a very rich functional application that that accomplishes real world problems, and it also much more closely approximates how users and programmers will think about accounts so having that type of model is actually very nice, because you have less to think about there when you're reasoning about your your application. But one of the one of the key things there to keep in mind on the flip side is even though you may think of then accounts like that uh it.

A

It can end up differing a bit when you get when you get to the real world and we'll talk about that in a little bit. Also, uh you know they're a little less amenable to stay pruning here, and the arbitrary state access allows an opportunity for much more bugs and exploits. I promise this is the most text-filled slide here, but I had didn't have a very good way to present it. Otherwise uh you know and you get prone to reordering bugs and you have less privacy than utxos.

A

All these things are kind of interconnected, uh and because of these, this heavy set of interconnection between all transactions in an account based model, largely limits you to single threaded operation when one transaction comes in, your network needs to basically not do anything else, analyze that transaction commit it, and then it can move on to the next transaction.

A

You can't have two transactions come in at the same time and do them both at once. One has to go before the other, but that's basically how it works. So it kind of helps to have actual models of these things so with in the utxo model.

A

As you can see on the left here, essentially each contract that you would have has its own utxo, uh so the contracts from you to carol to bob and also to carol again are all represented by utxo um and then same for carol and bob to each other into and back to you and then on the account model side on the right side.

A

It's a bit different because, rather than having individual ut excels for each and every one of these things, every contract will have its own generalized address and then from that address, you'll do transactions out to other accounts. So here you can see you have you and your account, uh which that should probably say, contract and your contract is making connections to carol bob and carol's carl's accounts again and then same thing. This is all essentially the same structure but kind of how you would do it in these two different models.

A

I'm just going to take a sip of water.

A

And so hopefully everybody understands that if you don't, of course you know, don't be shy, you can put a question in the chat or in the q a and I'm I'm more than happy to answer, and so now, let's talk, though, a little bit about a problem that can arise from these models, uh which is known as a side channel attack, and it's basically where an attacker who could be somebody you even work with, uh can use information that they do know about the system to make educated guesses about information that they don't know and even in some cases uncover information that is really really important and crucial and vital and sensitive, uh and they shouldn't know- and you see, side, channel attacks actually a lot in the real world too.

A

In certain instances uh you might have heard like them happening on hosting providers where two people are running basically different programs on the same computer or same machine. They don't even realize they are and then there's a side channel attack where one one program is able to figure out what's going on in the other program.

A

So, let's say- and this also is going to be a very simplified explanation- uh and what I mean by that is, I will be showing one very small piece of data, but in real world applications you could expect 10 000 of these pieces of data to be available, or you know thousands of them and then this. What and in that way, with all that additional information, you can actually derive a lot more about the system.

A

So we're only looking at one small bit, but in a real world application you would have access to lots lots of these bits that would add up to impactful information gathering.

A

So we're going to say carol and bob are competitors they're aware of each other, and they compete in the same space, carol's working on your project and she's under a strict set of ndas such that she shouldn't be disclosing this information to anybody and she's trying hard not to uh you, have intentionally also told bob that you're working with carol, because this is a very important project for you and bob's also recently worked with carol on a completely different project.

A

That happens to be on the same network, and this is where the side channel comes in so bob's, essentially hungry, for more projects and is going to be willing to bend the rules of your network for any sort of competitive intelligence that he can find. And what we're going to find here as we go through this is bob, is basically going to take the information he knows about the network.

A

He knows about carol and then he's going to and potentially other suppliers of yours is going to try to figure out if he can determine whether or not you're working with them, and if he can then from there, you probably determine other things or if he watches for long enough and collects enough data, he might be able to determine quite a lot about your network.

A

So what can bob do or know to carry out his attack in each of these models? Well, we're going to step through the problem. So we'll say bob goes home studies, your distributed ledger and the transaction is necessary to start a project, so these are going to be transactions necessary to instantiate a project with somebody.

A

We're also going to have two parallel universes here, so we can see how it works in each of these models so on the left, you're going to have your utxo model and on the right you're going to have your account model and basically what we're gonna, and so, let's go through this first. What we're gonna do is we're going to take away all the purple transactions.

A

These are basically things that bob shouldn't be able to see and your network's actually designed in both cases such that bob can't see these things but bob's going to try to indirectly get this information.

A

So bob looks at looks at your your models and says: okay, I can see a little bit of the network and I know that your workflow requires two transactions, uh one from you to the vendor and one from the vendor to you in order to start a project. So I'm gonna try to figure out if anybody else has started a project with you and since you're, working with bob bob of course knows this, because in order for bob to start the project with you, he had to go through this process, and so bob says. Well.

A

If I make one mute, one transaction with you to start the project and simultaneously around the same time make another transaction with carol.

A

Maybe I can figure out if there's a bit of data between these two to determine that there's actually transactions going from you to carol and carol to you, so bob tries to connect these things, but quickly finds out, uh tries to determine this purple thing here quickly finds out that the connection doesn't exist because there's no relationship between these two utxos, they don't depend on each other. uh The one from you to carol isn't visible to bob in any way because no information leaks through, and we have a question here in q- a really quick.

A

How does having a trusted third party an account system, help with the trust of the transaction history and allow it to be pruned? Or could you talk about the benefit of a permission network? Okay, uh craig, that's an excellent question. Having a trusted third party in an account system uh doesn't really help with the the the trust or or really or there's kind of two questions there. So I mean, if you both trust, that third party, then then that's that's great, because it it helps with trust inherently.

A

I would say that that's not really one of the biggest benefits of it, though, as far as pruning pruning in these systems um doesn't rely on trust, because what you can do, for example, the utxo system is when you take a utxo and you use it for another interaction that original one. You can kind of just discard it, because the rule of the network is, you can never reuse a utxo when it's being consumed.

A

However, in the account model, uh when you have an account, you can pretty much, never truly discard it, because there's always the possibility that another transaction in the future might interact with it, because you have multiple transactions all coming out of the same address or not of the same address out of yeah. Out of the same address in an account model, uh so that's kind of the difference there.

A

If that answers, your question in that um pruning is possible in both, but in one in the utxo model you can de facto dis discard old parts of transactions when they're consumed in new ones, whereas in the account model you can't- and you have to be a lot more careful and plan actually for these things to be discarded, because there's always a possibility that in the future, uh like your account on the right under the account model transaction, two there's always a possibility that there might be an expected transaction three or a transaction 1000 of way down the line, and so that's kind of the the difference there.

A

Okay. So now we're going to head back over. But now in the account model, uh things are a bit different.

A

Oh todd's, asking a question: how do you know if a utxo isn't being reused if you've pruned it? um That's a great question. I I don't know the exact answer to that. I I would like to get back to you on it, but essentially the network itself do does have a mechanism to to do so. uh I would say: oh you know what well, no, what would happen is if you're up to date with the network and you're pruning everything.

A

uh If a transaction comes in trying to use a utxo that you don't have in your active set of utxos, then you know that it's either an invalid utxo because it never existed or it was pruned at some point in the past in either case. The rule is such that uh I I have the full set of utxos that I that I know of that. I should be aware of and therefore, if it's not in my set of utxos, it's not a valid transaction, that's kind of how you would solve that.

A

So on the account side, uh we have bob. Just basically goes and does the same thing creates a transaction with you and goes and creates a transaction with carol.

A

And now bob sees something very interesting because in an account model in order to keep things well ordered and to make sure that transactions aren't rebroadcast, because you wouldn't want the same transaction to occur twice, you need to include something called a nonce which is a an identifier number that makes that transaction unique uh so that once an account is using say transaction 4 or transaction 90, as you can see on the right, we're not going to rebroadcast transaction 4 and have the same thing happen again, because that could lead to lots of bad things: lots of bad outcomes.

A

So then bob can, though, take this information and make a guess and say: well I see transaction 4 with your account and I see transaction 90 with carol's account. I can't see what you and carol are doing, but I could take a guess that since I broadcast both of these things at the same time or a very similar time, uh perhaps there is another account here, one for transaction three from you to carol and one that's transaction 89 from carol to you.

A

Bob doesn't know this for sure, but with this bit of information and with additional information, bob can keep guessing at this and kind of say. Oh well, it looks like these things might be related, and so that's basically how it works in an abstract way. But now we're going to change gears a bit and actually look at how updates happen on an ethereum based network, which is an account model and a demo based network, which is a utxo model.

A

Again, there will be some specificity here that is kind of glossed over for the sake of simplicity, but in general this is how it works, and what we're going to be looking at is an attack called reentrancy, which is somewhat related to also kind of like out of order execution and a lot of other things where things execute at times, where you don't expect them to, and that can lead to a variety of problems.

A

So on ethereum and in demo we're going to have kind of nearly identical contracts uh where and we're going to have functions. Basically that allow somebody to propose that they owe somebody else a beer and then also for that recip for for the recipient to accept it, uh and so what we can do here is in the obr side. uh We'll basically say: okay!

A

Well me as the sender sender, as message.center here I'm going to go ahead and offer a proposal to the recipient, saying that I owe them a beer and then, if they accept it, and also during that, I'm also going to keep track of my beer, the beers that I currently own and we're going to deduct one from it, so that this way we have a way to stop this function.

A

In case it runs away from us, uh so we can't actually owe more than than we actually have and then, on the exception side, the giver uh can then the recipient can then go ahead and say: okay, well, yeah I'll, accept the beer and I'll mark it and then I'll also make sure uh to debit one from the proposal.

A

This is a really crucial line too, because we wouldn't want the proposal to happen multiple times over and over again, uh and then we have the state that we're keeping track of, which is the beards owed and at the end it's going to be that alice owes bob one beer, and so one thing to know here too is that bob also knows how many beers alice actually owns because he has to by the design of this contract.

A

This could actually be left out, but as we'll see in a in a moment, it actually stops the bug from running away even further, so it's actually kind of good to track additional state, sometimes in account based models, uh even though it leaks information, um it sometimes is, can be beneficial, and so here what will happen is uh we'll go through and alice will offer to obama beer say bob did alice a favor, she says bob. I owe you a beer. Bob says that's great.

A

I want you to owe me 10 beers, so what bob does is bob comes through looks at these functions and says: oh, except beer here. Does this thing where it?

A

It broadcasts an event and says: oh um the message that sender uh has sent to be has given a beer to the giver uh and bob actually, as can go ahead and intercept this and when he does essentially accept beer executes once it gets halfway through the execution and then bob goes ahead and executes except beer again, and it gets halfway through the execution and bob goes and accepts beer again and gets halfway through the execution and bob goes and accepts beer again over and over again until the state explodes, because there's only 10 beers to give.

A

So what will happen is bob might uh send this 10 times, because he knows, there's there's 10 beers to hit or might send it a thousand times in which case there's another little circuit breaker in this that that helps stop this from going too far. But what will happen is none of these transactions will resolve they'll, keep stacking on top of each other, making it such that this beer's o line, keeps incrementing and then eventually uh bob stop sending in transactions.

A

So they all they all complete.

A

And what we end up in is a weird state where, instead of uh beers o being equal to one as we would have expected, uh we actually have beerzo between bob and alice to bob is ten, uh because eventually we hit this this breaker here and we realize we can't deduct uh from beer proposals anymore without it going negative, uh assuming that this is a an unsigned integer that won't allow itself to go negative uh and then then, basically, bob has created this crazy obligation because he's exploited something in the contract itself.

A

So that was a fairly long-winded explanation. But then, if we go and take a look at a utxo model, we essentially have the same design, and we only have a few minutes left. So I'm going to go through this very quick, but here what we have is that uh we have the beer proposal again again. Bob can accept or reject the beer, as the recipient and alice can make a proposal to bob. So alice makes a proposal which, essentially over here, creates a utxo on the network uh that says hey bob.

A

I would like to owe you a beer. Bob can then go ahead, consume that utxo so again, like we said before, can only consume it once and bob can say: oh I'll, accept the beer, and so by consuming that utxo. That old one uh can no longer be used, can actually be discarded from bob's active contract set, and they don't have to worry about it and then eventually bob can even say I've received the beer. This is actually based on some code.

A

I wrote a long time ago, and so one nice thing here too, is that we actually don't even need to keep track of the beer's own state. uh Like I said we don't need to necessarily in the previous one, but we don't need to worry about this kind of circuit, breaker or additional state tracking at all.

A

And it's even if alex were to keep track of it, it's something that bob doesn't necessarily need to know period anyway. uh Now we have the actual thing going ahead. You know alice again says to bob hey um I'd like to owe you this beer and then bob goes okay, great, I'm gonna!

A

Try to have you owe me 10 viewers again bob goes in and says accept beer submits it and then submits nine more after those and quickly finds out that uh the system won't allow this, because the utxo for owing the beer gets consumed in the first instance and then all the other instances after that, try to consume that same utxo, but that's a rule of the network that you can use it more than once, and so they fail, and so bob still receives the one beer he's owed.

A

It's arguable as to whether or not bob should still get that beer, uh but that's basically how this works and yeah. That's all I wanted to talk about today, uh really happy. I managed to fit that all into 30 minutes. If you have any more questions, you know you're going to head over to bit dot least try demo, uh that's our forum. You can ask questions about this. Talk there. You can ask questions about demo.

A

There uh really anything you want to talk about if it has techn any sort of technical reason to do a demo or a talk that I gave uh you know feel free to stop by. We have tons of resources there for all sorts of things for learning demo, so I'll just head over there right now, and particularly too. If you wanted to catch up on this talk or listen to other people chat about it, we actually do have a youtube channel.

A

That has that has that video and tons of other ones, but this is actually going to auto, play a video, so I'm going to close it. But yes, thank you all very much for for joining my session and oh, can I paste the url of the site. Sure I can leave slash, try just a nice little shortcut to take you over to everything else and yeah iona asked the question that do utxos act as a hierarchy. uh Yes, they do utxos are basically a hierarchy uh from which all new ut excels either need to consume.

A

Nothing such that they're, the first one or they need to uh consume a previously existing one. But yet you're very welcome craig and you're very welcome anna and you're very welcome iona and everybody else, and thank you all and have a great day.