 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 having me here. Talk about this very interesting technical topic that applies, I think really well to 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. I think Damo is a great piece of tech, but I really like think that it's important to break down these different components of the technology so we can really understand them and what the good bed and cost trade-offs are on them. And 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. Even a single real-world implementation of a UTXO or account model requires a lot of specific city and would take longer than the time we have a lot of here to go over. 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. And so in 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. So first, you know, what are UTXOs and accounts? 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 manage some semblance of accounting or state. And in a UTXO model, basically every previous entry 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. That's kind of how UTXOs work compared to the real world. And in accounts, 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 an account balance would update on my end. And I could actually go and use that same number again 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 kind of there 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 UTXO and account models. There's a real world equivalence of both that have existed for a really long time. UTXOs largely exist in the form of divisible and fungible bear insurance. So that would be dollars and coins and gold and all that fun stuff. And accounts exist really in various forms of ledgers that involve single and double entry bookkeeping. That could be debt IOUs, bank deposits. And these very interesting things called bullay, which are very early forms of double entry accounting that I think are interesting because people were actually able to hold them. 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. And then you can make sure that people couldn't modify the outside of it 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 is quite cool. But yeah, generally when we think of UTXOs and account models too in the real world and meat space, 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. 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. So now we'll talk about blockchains, our favorite. So there's some technical examples of UTXO and account models. 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 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. But then, you know, we have others, for example, Damo runs entirely on UTXOs and a slightly different model. But like I said before, you know, there's too much specificity to go into that. And then same for Quarta, largely UTXOs. But again, there's some specificity there that I'm going to simply gloss over. And then also, you know, you have Bessu on the account side, which is another Ethereum derived option. And then Fabric actually does both. And that's because Fabric really is a general key store where you can commit any data you want and read it 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 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 much more privacy by default. I'll actually show that an example in a little bit because there's no notion of accounts. We don't have so many connections between all the different going-ons on the network. 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. Also, every participant only needs to know about the UTXOs that they're involved with in order to use the system. 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 only need to share the parts of the UTXO set that are important to you and relevant to you. And if something's not relevant to you, if say it was between two other people, you wouldn't have to involve yourself with that. And you also get much more parallelizable operations, which basically means when you have your UTXOs, 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 UTXO type system. You know, if two transactions simultaneously use the same previously existing input, 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 things. 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 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 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 UTXOs 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 models 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 previously seem to be the to do it. But now we're learning that really you don't need account models in order to have 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 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 an account like that, 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, you know, they're a little less amenable to state 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 didn't have a very good way to present it otherwise. You know, and you get prone to reordering bugs and you have less privacy than UTXOs. All these things are kind of interconnected. 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. 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 within the UTXO model, as you can see on the left here, essentially each contract that you would have has its own UTXO. So the contracts from you to Carol to Bob and also to Carol again are all represented by UTXO. And then same for Carol and Bob to each other and back to you. And then on the account model side, on the right side, it's a bit different because rather than having individual UTXOs 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, which that should probably say contract. And your contract is making connections to Carol Bob and Carol'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. I'm just going to take a sip of water. 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 more than happy to answer. And so now let's talk though a little bit about a problem that can arise from these models, which is known as a side channel attack. And it's basically where an attacker who could be somebody you even work with 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 and they shouldn't know. And you see side channel attacks actually a lot in the real world too. And in certain instances, 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 program is able to figure out what's going on in the other program. So let's say, and this also is going to be a very simplified explanation. 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 wet end in that way with all that additional information you can actually derive a lot more about the system. So we're only looking at one small bit, but in a real world application you would have access to lots of these bits that would add up to impactful information gathering. 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 is 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. 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 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, he knows about Carol, and then he's going to end potentially other suppliers of yours and he's 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 he can 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. 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. 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 going to... and so let's go through this. First what we're going to do is we're going to take away all the purple transactions. These are basically things that Bob shouldn't be able to see and your networks actually designed in both cases such that Bob can't see these things. But Bob's going to try to indirectly get this information. So Bob looks at your models and says, okay I can see a little bit of the network and I know that your workflow requires two transactions one from you to the vendor and one from the vendor to you in order to start a project. So I'm going to 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 if I make one transaction with you to start the project and simultaneously around the same time make another transaction with Carol 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 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. 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. How does having a trusted third party and 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, Craig, that's an excellent question. Having a trusted third party in an account system doesn't really help with the trust or really, or there's kind of two questions there. So, I mean, if you both trust that third party then that's great because it helps with trust inherently. I would say that that's not really one of the biggest benefits of it though. As far as pruning in these systems doesn't rely on trust because what you can do, for example, in 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. However, in the account model 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 out of the same address out of the same address in an account model. So that's kind of the difference there if that answers your question in that pruning is possible in both but in one in the UTXO model you can de facto 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 like your account on the right under the account model transaction 2 there's always a possibility that there might be an expected transaction 3 or a transaction 1000 way down the line. So that's kind of the difference there. Okay so now we're going to head over but now in the account model things are a bit different. Oh Todd's asking a question how do you know if the UTXO isn't being reused if you've pruned it that's a great question I I don't know the exact answer to that I would like to get back to you on it but essentially the network itself does have a mechanism to do so I would say oh you know what what would happen is if you're up to date with the network and you're pruning everything if a transaction comes in trying to use the 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 at some point in the past in either case the rule is such that I have the full set of UTXOs 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 so on the account side we have Bob basically goes and does the same thing creates a transaction with you and goes and creates a transaction with Carol 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 an identifier number that makes that transaction unique so that once an account is using say transaction 4 or transaction 9 as you can see on the right we're not going to rebroadcast transaction 4 and have the same thing happen again that could lead to lots of bad things lots of bad outcomes 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 perhaps there is another account here one for transaction 3 from you to Carol and one that's transaction 89 from Carol to you 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 Damo based network which is a UTXL model again there will be some specificity here that is kind of gloss 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 re-entrancy 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 want to expect them to and that can lead to a variety of problems so on Ethereum and in Damo we're going to have kind of nearly identical contracts 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 for the recipient to accept it and so what we can do here is in the OBEER side we'll basically say okay well me as the sender as message.sender 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 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 in case it runs away from us so we can actually owe more than we actually have and then on the accept beer side the giver 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 to debit one from the proposal this is a really crucial line too I don't want the proposal to happen multiple times over and over again and then we have the state that we're keeping track of which is the beers 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 buy the design of this contract this could actually be left out but as we'll see in a moment it actually stops the bug from running away even further so it's actually kind of good to track additional states sometimes and account based models even though it leaks information it sometimes is can be beneficial and so here what will happen is we'll go through and Alice will offer to oh Bob a beer say Bob did Alice a favor she says Bob I owe you a beer Bob says that's great 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 broadcasts an event and says oh the message dot sender has sent a beer has given a beer to the giver and Bob actually can go ahead and intercept this and when he does essentially except 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 so what will happen is Bob might send this 10 times because he knows 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 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 beers owe line keeps incrementing and then eventually Bob stops sending in transactions so they all complete and what we end up in is a weird state where instead of beers owe being equal to one as we would have expected we actually have beers owe between Bob and Alice to Bob is 10 because eventually we hit this breaker here and we realize we can deduct from beer proposals anymore without it going negative assuming that this is an unsigned integer that won't allow itself to go negative and then then basically Bob has created this crazy obligation because he's exploited something in the contract itself 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 we have the beer proposal again again Bob can accept or reject the beer as a recipient and Alice can make a proposal to Bob so Alice makes a proposal which essentially over here creates a UTXO on the network that says hey Bob 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 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 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 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 and it's even if Alice were to keep track of it it's something that Bob doesn't necessarily need to know period anyway now we have the actual thing going ahead you know Alice against us to Bob hey I'd like to owe you this beer and then Bob goes okay great I'm going to try to have you owe me 10 beers again Bob goes in and says accept beer submits it and then submits 9 more after those and quickly finds out that 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't use it more than once and so they fail and so Bob still receives the one beer he's owed it's arguable as to whether or not Bob should still get that beer but that's basically how this works and yeah that's all I wanted to talk about today really happy I managed to fit that all into 30 minutes if you have any more questions you know you can head over to bit.ly slash try Dammel that's our forum you can ask questions about this talk there you can ask questions about Dammel there really anything you want to talk about if it has any sort of technical reason to do with Dammel or a talk that I gave feel free to stop by we have tons of resources there for all sorts of things for learning Dammel 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 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 your question and can I paste the URL of the site sure I can bit.ly slash try Dammel just a nice little shortcut to take you over to everything else and yeah I want to ask the question that do UTXOs act as a hierarchy yes they do UTXOs are basically a hierarchy from which all new UTXOs either need to consume nothing such that they're the first one or they need to consume a previously existing one but yeah 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