 it's the best we can we can go but let's see if the group is intimate enough we can always do a quick round of intros and anyway you should just intro yourself in the chat we'll go through it in a second it's the best we can we can go but let's see if the group is sorry for that that's youtube live anyway in the background can you please meet your youtube channel people coming and yeah if everybody just wants to introduce themselves maybe just tell us kind of your name location and kind of what you're excited to talk about today you can do so in the chat that'd be great we'll be starting shortly um and this is I know that you can't see the the slide but this is the right webinar Anthony will be talking about what digital assets has been doing and yeah we'll be just starting shortly waiting for people to join hi Jose how are you look good to see you likewise really curious actually look is looking for at names I'm wondering how many of you are from the US versus Europe because we always thought that this hour is best for for people from the US but then I see some friends from from Europe so if you want to pop into the chat or speak up where you're yeah well fast nice okay Karen do you want to go through the house keeping yeah yeah okay let's get started we'll welcome everyone um to an in-depth hour with digital asset um we have Anthony here with us today and he's going to be going through um a really engaging talk presentation um we have just a few housekeeping items that we're going to go through before we get started change um as with um many of you who are familiar in our community at hyper ledger um we follow an antitrust policy um and have an antitrust policy notice that you can look at on our website or you can take a look at the qr code on the screen that you're looking at right now this session is being recorded it will be available on our website on the webinar page um we are also live on youtube so you'll also see a recording on youtube later on and the slides that you find in this presentation will also be included in the description of the recordings um this in-depth hour is a very engaging opportunity so um Anthony is of course going to share something that he's prepared with us for you um but we absolutely hope and expect and welcome you to get involved um there's a couple ways you can do that you can raise your hand via the um emotion signals that you have in your zoom menu bar you can also come off mute um or type into the chat um any questions you have or comments you want to make we'll be monitoring all of those and um giving you that opportunity to jump in when um when you can um ask any questions don't be shy and um and we're here to this is a learning session this is here for year your opportunity to learn something new about UTXO and account models I'm sure you're here because you're interested in that and so please take full advantage of this opportunity to be here with Anthony absolutely um we do have a regular series of these so our next couple ones are the next one is with consensus on March 17th and then we have the valid network presenting on March 31st and these are also similar format very engaging here for you to learn and ask questions so if you're interested in either one of those topics or companies um please sign up for those as well and of course there's many different ways you can get involved at Hyperledger you can um check out the community page the resources page on our website engage with us in the chat and our various projects and sigs and special interests or working groups um our wiki our mailing lists etc um I'm sure many of you are already participating in in many of these and I'll let Anthony get started okay awesome uh so I could share my screen now yeah okay great okay so thank you very much Karen for the introduction and thank you both to Karen and Marta for just giving me the opportunity to talk about all this I'm really excited I'm actually just going to bring the Q&A and chat box back up really quick so don't mind me just so I could see if anybody has any questions but yeah thank you very much uh today if you haven't introduced yourself yet you can go ahead and do that in the chat box or if you want to unmute your mic that's fine too but we do have quite a lot to cover today so yeah today we're going to be talking about UTXOs and account models the good the bad and the costly that's out of my very clickbait title but hopefully it got enough people to join so that we can kind of check it out and there are there are definitely good positives negatives and uh costly mistakes in both these models and we'll be talking about some of those a little later as well but we're also going to be pointing we're also going to be painting with very broad strokes so in the first half of this we're really going to focus on general designs themselves before we get into the nitty gritty of what an actual UTXO or account model implementation looks like really to describe even a single one of these would require more much more time than an hour to really understand how the implementations work even in real life there are a lot of very hybrid-y models or other things going on that don't perfectly fit in these boxes so there's always an exception to everything so really what I want to talk about is how these systems generally behave by default and with the least complexity in their designs as possible uh least complexity helps us not only understand uh you know what it is we're talking about and what we're looking at but also the least complexity possible tends to have the least bugs or least issues or least things that you as somebody designing an application or using a UTXO or account-based network need to really worry about so that's always good in general and yeah so my first question is basically to everybody in the audience you know what are UTXOs and what are accounts can somebody maybe give me an example or a definition you know you can feel free to unmute yourself or you can mention it in chat and if no idea that's why I'm here perfect that's always good okay so uh I'm sure some people I see that Santiago mentioned that it's unspent transaction balance and can says that UTXO is like paper money bills uh yeah okay um those are actually great examples uh yes so Santiago is correct uh UTXO stands for um unspent transaction output uh and that and a series of those outputs could represent anyone's ballot when it's on a ledger or it could represent a variety of other things uh can is also correct in the real world UTXOs are like paper money bills and HT yeah that's a that's a very interesting point HT mentioned that UTXOs basically within Bitcoin a bunch of them may make up your account which kind of ties into the balance that Santiago mentioned and that is right for the Bitcoin implementation itself uh and but when we're looking at these things we're trying to we're going to probably be looking at them more in isolation and then on the other side what I mean by accounts of this since it might be a bit confusing and I could totally see that is an account is kind of like this kind of gives away one of my my examples later like a bank account where you may receive money and send money and so forth and ultimately though all that money all those transactions all represent just increasing or decreasing the value on your account balance for example uh within the context of you know blockchain and distributive ledgers these things are a bit more complicated because they don't only hold just things about money but things about all sorts of parts of the world and so that's that's the general gist of them where UTXOs are like a consistent ledger of debit and credits uh this change this didn't this changed here this change at this time is a UTXO model an account model is you know this thing got updated and there's there's less of a record and there's more of a tying of these things together uh so they they do vary a bit in that way but now maybe we could come up with some examples given those definitions and what people already mentioned you know we do have some examples like where ken says that UTXOs are like paper money bills and I had mentioned that accounts are like banks so does anybody else have any other examples and feel free to to put them in the chat or just say them out loud we have a two one comment one question so HT said that an account has UTXO and bitcoin picks the lowest one and then Santiago asked how is an account differentiated from a wallet to preclude a double spend uh yeah so what HT said is is correct as I just as I touched on there and for Santiago's question how is an account differentiated from a wallet to preclude a double spend so that's probably something we'll go into a little bit later and it's actually really more about consensus rules than the designs of these systems themselves so I'm actually looking at these systems as if they've already figured out how to manage consensus and eliminate double spends and in real life in Ethereum for example and this will be a note that comes up later so it's a really good question is the way you're able to preclude double spends on Ethereum are Ethereum does proof of work which obvious which enforces transactions transaction order essentially and the other thing is that within account systems you typically have something called a nonce that basically each and every one of those ties to can only be used once and because of that this little bit of information precludes somebody from like if I were to send Santiago a transaction on Ethereum I wouldn't want him to send that same transaction again and that's kind of how you prevent double spends in that way if I'm understanding the question correctly so yeah we perfect so we've had some some explanations of account models and here's some of my ideas on real life models and really all of these models are very ancient we have on the UTXO side the real life examples being cash and coin money coin money in particular being one of the earliest examples of what you could consider a UTXO they are things that you know you send them to from one person to another if you were to split one in half and and give the two pieces to two different people other than them coming together and figuring out that that was from the same half of the coin that's pretty much it there's no other tie between them so if one of those haves got given to another person that person would have no link between that half of the coin and another one for example and on the account side you know we have banks like has been mentioned and we have credit cards which do the same type of thing they keep track back of a list of debits and then every month you settle up and then we even have we have very old examples when it comes to accounts I would say in general accounts and these types of transactions actually probably accounts probably predate UTXOs in real life usage there's a lot of history behind it so I won't go into that but one interesting example are these Bollet tokens that essentially are an account and also are somewhat of a UTXO they're really interesting in that the outside of them demonstrates what is owed and the inside of them is the identical of what is what has been received and kind of that happens by they basically press all these little bones that represent different things into the tokens or these different stones and then they seal the stones inside this ball that has those impressions on it so when you want to go and redeem your debts you can actually have somebody will break it open and see that nothing had been changed it's really interesting because you could pick it up and take it around with you and then go back later to whoever owed you something or whoever owed you and redeem them that way and those are a whole bunch of different real life examples of UTXO and account models so now and I really haven't actually thought this question through much so I would love it if people had some ideas but for these models in the real world kind of between UTXOs and accounts what are some of the good things about them and maybe what are some of the bad things about them like what are the trade-offs from choosing these models. Feel free to come off of mute if you like or you can type in the chat or submit a question. Yeah Santiago actually has a really good point there data storage is definitely within blockchains themselves a consideration when you're going through between UTXOs and accounts that will actually get into in a little bit and that's basically an answer to another question that I have but in the real world like what are the examples of having dollars or coins versus having you know bank accounts or credit cards and Fergal says concurrency can you can you be a bit more specific about concurrency I'm sorry Fergal your your volume's a little low I couldn't hear that that well it's a little quiet it's a little low you can feel free to type in chat too if that makes it easier for UTXO to require a lot of aggregations yeah that that's definitely a negative of UTXOs there that that they could require a lot of aggregations you kind of have changed to deal with also like you just mentioned in the chat and yeah on the account side one of the the negatives is that you have to have a nonce and manage it and we'll actually see that that nonce has some other negatives to wait a little bit later in this Alfred also has a really good point that privacy is I'm assuming you're talking about UTXOs privacy is a bit better in UTXOs that's also something we're going to talk about so that's really awesome and yeah Santiago also brings up that UTXO is one of the advantages they have and it kind of ties into what Fergal said is that they're divisible and so they have a really nice property where they get divided and split around where at and accounts have a really nice property where they have you get basically a real time update to to an account and you get to see the balance for the account without having to compute it out all yourself in blockchains obviously in both of them these are abstractions on top of how these things actually work under the hood so in both you actually do have to do all that computation but when you're reasoning about these things actually as a user of them then these that's when these things come into play and are very interesting and yeah Andre also says that you know you get bigger control of funds with UTXOs which is true you get to pick which of your bills or coins you're actually spending and yeah Alfred also has a really great point there that you know smart contracts are it's easier to reason about accounts when you're programming smart contracts than it is UTXOs I will tell you I'm probably partial to UTXOs and that might come through in some of the rest of this but yeah that is a good point is that it actually does make reasoning quite a bit easier here and yeah so those are great and now we're actually going to hop over to blockchains and you know we've actually kind of covered quite a lot of that so I'm going so or actually when we were thinking about the real life versions the analog versions almost but not exactly in all cases they kind of translate to a blockchain digit digitized versions pretty well in that they are at least 90% by whatever loose qualitative metric I'm using there are very equivalent and so I spent a while thinking about this and you know we've kind of gone over that so let's go on to the and on the technical side too I think that people have really dived into that in that you know they're these are the same types of things so if you have any specific other ones you want to add about the technical side you know you can go you can feel free and mention them in the chat or unmute yourself but for example you know like Virgil said there's a concurrency that's really nice because if you have two separate $20 bills and you spend them in different places the different places you spent them they don't need to worry about for example what the other $20 bill is doing whereas in an account you actually do and that's why you have intermediaries for example on a credit card that are keeping track of this running balance and they want to make sure that with one balance if you only had $20 in your account and you spent it you're not going to try to do two transactions right next to each other where you debit $20 both times and ends up running under you actually for a debit card that would be what you'd be doing and then you know like Santiago had said before there's a data storage consideration so on the UTXO side and this isn't always true but most of the time it's true there is more data storage for each individual UTXO that's doing a very basic thing as compared to an account where the transaction is also doing a very basic thing such as changing a balance oftentimes in accounts those are smaller for a variety of reasons mostly because in UTXOs you have to track the what the thing that you're debiting itself and in accounts you just kind of do the debit and make sure that when you're doing it that it's allowed and it's not going to overdraw the account and I'm also talking about these things in context of kind of in context of accounts but they really apply to all sorts of applications that you can run on these things and you can think of accounts really as changing state in an application changing what data that application is storing and Gaurav has a really great point here is that on UTXOs one good thing about them is that sharding is possible so like I said before if you have two different UTXOs and you spend one here and one in another place those two UTXOs could be on completely different networks because it doesn't matter to the person receiving them what their relation are to each other all of each UTXO has a history both behind it and eventually in front of it and that history is completely isolated from any adjacent history of other UTXOs even if they're coming from the same person from the same person with the same account and wow these are these are really good answers I'm I don't even need to tell you what the positives and negatives are about UTXOs and accounts but I will continue I actually oh okay so you're you're going to go into I was actually going to ask you know it seems like there's been there's a lot of advantages and positives for UTXOs what what are the disadvantages but that's that's what you're about to go into yeah of course uh yes there are positives and negatives to both like you mentioned Karen so we could talk about the bad side we've talked a lot about the positive side maybe we'll touch on some of the other positives if there are other things to mention there and so one of the bads of your UTXO model when you're using them uh in a blockchain distributed ledger setting is that you always have to worry about contention and manage it so what that means is uh UTXOs are intended to only ever be used once similar to you know you go to the store you spend your $20 bill you can't spend that $20 bill twice you will get change back from the store in the form of other UTXOs potentially but uh that one's gone and but what happens in the virtual world is you can take that same UTXO and try to spend it twice so for example on a single network you could try to spend it twice and the network will have to figure out of those two times you tried to spend it which of the two are the real which are the two are the valid one that should be included as part of the history and which one should be rejected because it's been spent already and you can imagine that different participants on the network uh might see these transactions at different at slightly different times it might see one first in one case and the other first in another case and then you would have you know essentially two different nodes that disagree about which transaction is valid and which one is an attempt at a double spend that should be thrown out uh so I won't go into all the ways that gets handled it does get handled but it is something that when you're programming applications and when you're reasoning about them you do have to consider how is my network going to handle this and when I do encounter this what do I do do I have to tell the other party that this UTXO has been spent already do I have to wait a while in order to see if this one is valid there are are a variety of ways to to deal with it but it is something to consider another bet about the UTXO model is that it requires really learning a new way to reason about and structure your programs so we've become very used to and accustomed to within a lot of programming paradigms of always having access to state being able to change our state basically being able to be largely the sole authority over the state of our application and uh to a lesser extent this also affects account models within uh the blockchain and DLT space but in UTXOs it particularly requires lots of new reasoning about how your programs get structured and I'll actually show that in an example later uh and as mentioned before you know you often do get larger transaction sizes this isn't always true there are ways to navigate around it but in the very basic general sense as we're trying to stick to with these models that is a concern on the account model side some of the bets are that they're less amenable to state pruning so someone had mentioned that earlier where in UTXOs once you've used one you can mostly forget about it unless you're a new member to the network then you need all the old history but if you've been on the network for a while you actually don't need that history anymore you've figured out what the current state is uh but with accounts they all depend on each other in a much more intertwined way they all modify each other a lot more so while in accounts you actually still can state prune you can do it a lot less in general on on networks than you can with UTXOs uh another thing here is that account models generally also and this is kind of getting a bit in the weeds but they tend to mix kind of uh account models tend to be intertwined with arbitrary state access and what that means is within a UTXO when you spend one or you use one you can only use that once and it only depends on the state of itself basically it is all of the state that you're concerned about but when you do this in the account model it could affect the state of anything else on the network as long as it's a current piece of state on the network so we'll actually see that too in that how that can create some opportunities for bugs you also have reordering bugs like we touched on and that you would use a nonce to try to alleviate they're a bit less private because when you take your account or for example your debit card and you use it in the real world one nice thing is that the bank knows all of your states everywhere you spend money but the rest of the world doesn't within accounts if you try to do that same thing people can look at the account it came from and see all the other transactions under it this is a very common thing you see this for example on a lot of networks like Ethereum you even see this on bitcoin a lot where people reuse the same addresses but the UTXO model in that case is trying to encourage you not to do that but in general that makes these things less private because people can go on and actually see these transactions and then in the private space you do have a variety of other methods you know such as channels and think other things called channels that actually help to keep this privacy but again we're trying to think about account models in a very general sense so in general they're less private but there are ways to work around it as with most of these negatives and sorry did somebody have a question I know I can talk a lot especially about UTXO set account models okay I guess not also account models tend to be single threaded there are a variety of optimizations that I personally am not in tune enough or knowledgeable enough on to explain but generally when you're making state updates with account models and they come with the arbitrary state access which they often do then you can only have single threaded operations so if you're saying if I'm doing a transaction you're doing a transaction and yours goes and happens first then my transaction cannot happen until your transaction has resolved basically there's a whole lock on all the state out there even if our two transactions don't interact that mainly applies to when there's arbitrary state access within account models but I have yet to actually see an account model that doesn't really allow for generally arbitrary state access and let's see so yeah there is a question from HT they're asking if I hold 100 bucks in a bank and if a merchant puts a hold of 400 bucks can another merchant claim it how does banks handle double spending today I'm not sure how banks do it internally but I'd imagine that no you wouldn't be able to double spend it so that I'm not sure on banks definitely have their own ways of managing double spends but there are also I know there are a lot of reconciliation processes that go into managing those types of issues and other related issues and that's one of the things too when we think about you know why our distributed ledger is good is that they make these reconciliation issues largely go away largely become a question of the infrastructure layer rather than the business logic and reasoning layer and without having to do so much backtracking all the time and having all sorts of safeguards to prevent these types of issues so in general I don't know exactly how but I do know that regardless of the model here that solving reconciliation and improving it both of these models can can offer benefits over the current systems we have today and I hope that answers your question it's at least answered to the best of my abilities so now what we're going to do is we're going to take a look at a very simple model of each and after that we're going to try to break these models in various ways which is always the most fun of programming as anybody knows so for these models just take a moment to look at them and if you can tell me basically what's the same and what's different about them either in the chat or when I'm muting your microphone you know you know feel free because there's some interesting differences but in terms of their structure okay so Santiago has a really good point here UTXOs are a lot more compact in terms of their history that's still missing to my next slide. HT says that a transaction contains UTXOs so transaction three is mapped to UTXO0B1C. Yes that's correct in the example of that we have here so yeah for each of these I've specified a UTXO and the UTXO model which would actually be contained in a transaction but for this case let's imagine each transact has one UTXO and like HT said you know UTXO here is 0B1C from Bob to me or Bob to you is the same as transaction three and in the account model where Bob's account will send the transaction to you and Santiago has a really great point here that and I'm going to go into this the non-history can be traced in UTXO, oh I'm sorry Santiago said that the non-history I believe you maybe meant to say can't be traced in UTXOs so yeah in UTXOs there's no nonces yeah okay but in account models there are nonces and what we'll see is that that kind of enables a certain bad behavior that I'll talk about on the next slide so that's great I'm really happy that everybody can see all of this from the model and really are grasping it because that's awesome this is actually my first time giving this presentation so I'm very happy with that anyway as you can see on the left we have UTXOs when they're coming from you and going out to other people they are not tied to each other you can see that the arrows here don't touch and that's actually I'm trying to represent there visually an actual technical difference kind of related to what Santiago said and one of the other things you can see is that they there's no with any UTXO they're kind of not keeping a history of how many transactions for example you have sent or how many transactions for example that Carol and Bob have received there's nothing there in terms of that on the account model side you have yourself and then you have your account and within your account transactions are kind of aggregated and related to each other such that they're ordinal and here we see the nonces we have transaction one two and three both of these by the way are very over simplifications of the actual implementations and how they would work but just for the purposes of demonstration and then from there you can you can get a graph of where this transaction has gone and it's gone to Carol's account and what you can see here too is that this transaction here goes back to you or rather and thus goes back to your account so you get a bit more of a transaction history if this thing was disclosed you could kind of see the same things within UTXOs but disclosure is generally a lot more minimized within them and we'll see that in the next slides and just before you move on you know this structure that you just highlighted here on the two is really what contributes right to the somewhat increased privacy of the UTXO model right because it's not doesn't have that aggregation uh yes exactly that's that's a great point because it doesn't have that aggregation and really in real life these things are a lot more complicated you can get much more privacy out of accounts than what I'm saying here but UTXOs have a lot more privacy by default that just don't doesn't need to be worked into them and account models require additional things to do in order to get some more of that privacy that you would get naturally out of UTXOs and of course UTXOs and accounts can actually be used in almost identically the same ways to each other but we're talking here about the way that they most encourage their users and programmers to actually use them because you can take UTXOs and use them in incredibly bad ways that completely destroy your privacy and people actually do that quite a lot whereas on the account side you can actually take them and use them in ways that actually give you very decent privacy but the same thing there is that people tend to ignore them a lot and of course I am talking a lot and as Karen says you know if you have any questions so based on what you said in this UTXO model and so the point of these arrows which are not touched each other it means that it's more private and they cannot track the transitions yeah yep that's correct but in account model they can I yes indirectly you can track some things okay thanks thanks for asking Susan yeah that's a great question and it actually leads me into my next slide which is a problem that Susan in Santiago and I believe a couple other people I've been touching on is that this leads to essentially what we could call side channel attacks which is a very general form of attack so we could say the following happens with the model we just looked at number one Carol and Bob are competitors in the space you work in they're aware of each other and they compete with each other number two Carol is working on your project and under a very strict set of NDAs you intentionally haven't told Bob that you're working with Carol you also happen to be working with Bob and Bob has actually been working with Carol on another project and Bob in particular is a less than moral person and is really willing to bend the rules of your network to see what data he can pull out to get more quote unquote competitive intelligence on your operations and so what we can now do is and this has already been touched on so I'll just start stepping through it is we can start talking about what Bob can do or know to carry out these attacks and I see there's a question I'll answer that in a moment but one thing to keep in mind here as we go through this is that this is a very simple example in the real world on a real blockchain or distributed ledger what you're going to actually encounter are thousands upon thousands of transactions between the same parties over and over again and so if Bob can figure this out with one bit of data imagine the types of things that Bob could figure out with a variety of data you can you can just start figuring out more and more things about the network that you weren't supposed to know and so he's asking will you share info on how we can implement this in hyper ledger fabric I mean UTXO an account model yes so fabric in and of itself uses an account model and they also use something called channels which actually mitigate a lot of these concerns as I said this is an example and then the other way if you wanted to try your hands at actually using UTXOs you can try out dammel which runs on top of fabric and that you can go to the link that I have in the bottom left at bit.ly slash try dammel I recommend everybody you know just go there and check it out it runs on fabric networks it doesn't interact with existing contracts but it is a very interesting way to program on fabric networks and gives you a lot of very nice things for free and we even have you know interoperability layers and all sorts of other things we're working on where disparate networks like a fabric network and a sawtooth network will eventually be able to talk to each other and have very interesting bigger networks you know as the space expands and that's basically my pitch on dammel but yeah try it out so what we can do is step through this problem so we're going to say that Bob goes home studies your ledger and and figures out some some things about it we're also going to have two parallel universes we're going to have the UTXO an account universes um and we're going to also have well one thing that Bob knows is that in order for any project to start with your workflow for your business there has to be a transaction from you to Bob and there has to be another related transaction from Bob to you that happened around the same time and so what we're going to first do is we're going to restrict this model to the things that Bob only knows about and remove the other other parts of the network so all these things in purple are going away because Bob can't actually see these in any real life functioning network hopefully um Andre I'm not sure if I could answer that question because I don't know uh about the decentralized identity methods that would be used as identification on hyperledger fabric unfortunately but if Karen or Martin know perhaps they could answer or maybe that's something that we could revisit after the presentation yep I'm afraid to keep going I'll I'll answer it sure so what Bob decides what Bob does is he starts another project with you and he goes and gets a transaction from you to him and then he starts another project with Carol and goes and gets a transaction from Carol to him and Bob figures hey if I could tie these two bits of data together I can know maybe if Carol has been working with you because maybe these UTXOs are related and if they are in any sort of way there might be some data between them which would reveal this other transaction that may have happened would reveal necessarily the data about it but just the fact that it probably exists to some uh some degree of certainty but Bob quickly finds out that these two UTXOs have no relation to each other and this is something that people touched on before in the account model we can go and do the same thing Bob says oh look at this uh less transaction from you to me was transaction two and now the transaction from you to me is transaction four where's transaction three and this is even more interesting you know on the capital side oh Carol's last transaction to me was number 88 and now it's number 90 where's 89 we from there Bob can deduce that Carol has very possibly but not certainly had some sort of business interaction with you and you know maybe it is maybe it isn't with more and more data Bob can figure out and learn more and more interesting things and even with these types of things you would probably actually see much more than two transactions and with every transaction that Bob can kind of theoretically derive or actually practically somewhat observe happened uh Bob can become more and more sure about what other parts of what's happening on the network that Bob is unaware of and so it's a very interesting thing and of course if you have any questions you know feel free to ask or if not we can go into the real life examples with not not exactly this type of thing where with disclosure but other other things uh okay so here we're going to get more specific and we're going to look at an actual network and we're going to look at Ethereum first and then we'll look at it in demo just so we can compare networks that both do or not demo is not really a network but we could compare smart contracts written within both types of these models uh can ask can't you trace it from the transaction graph um is that in refer the UTXO model or from the account model okay so on UTXO end accounts here that that I'm showing while over here you can see the full transaction graph uh what we did is we made sure that Bob wouldn't be able to see the parts of the transaction graph in both accounts in UTXO models that Bob wasn't supposed to see so that's why when you're just the person if on like a public network yes you can see the full transaction graph uh no matter who you are but on more private networks you generally can't and that would be just a very basic part of the implementation uh for most cases though not all and so that's what we're doing here we're giving both of these models their best shot at staying private before we are able to figure out other things about them and so I hope that answers your question but now we'll look at the theorem specifically and so you can take a moment to look at the slide and if you have any questions feel free to ask we actually already are fairly close to the end of the hour and I really do want to get through to all of this uh so uh Todd Todd asked a very good question how does Bob know there's a missing transaction the answer is Bob doesn't truly the answer is Bob knows there are missing transactions uh Bob doesn't truly know whether they involve you and Carol for example in this in this example but Bob can take an educated guess so what you can see over here is Bob had a previous transaction to with you and a transaction 88 with Carol and what happened is Bob did another transaction with you and saw a transaction four and then Bob did another transaction with Carol and saw a transaction 90 and in both cases Bob knows nonsense increments by one each and every time so Bob knows that there's a transaction three that Bob's not that Bob is aware of Bob also knows that there's a transaction 89 here between these two that they're not aware of uh yes and this is this is based on an assumption and this is why it's a side channel attack because you can't fully derive the true state of the network with just this small bit of data but when it comes to interactions between different parties on the network you can start to make better and better assumptions and better and better guesses about them that's also why I have the giant question marks about that next to them here uh where this is one way that Bob could predict this and as far as nonsense go um most networks enforce some sort of strictness through their nonsense uh such that they're either simply always increasing or they're always increasing by one um if they were and in general even if your network didn't make the assumption that they always increased by one you would find still that a lot of software where people are actually programming this still does that thing where they just increased by one because it's the easiest thing to do and it's the easiest way to track um so yeah there's assumptions we have to make here about how the network works but I don't think that that's an unfair assumption or an uncommon assumption to make for these cases but that is that is a really great great question and great point is that you know we don't know any of this for sure and yeah so on the Ethereum side we have these functions where you can owe a beer and accept a beer once you're owed it uh so what happens here is that we have this very simple function really very extra simplified where here the owe beer function goes and with Alice were to owe Bob a beer for example uh Alice would go ahead and increase her beer proposal that's over here so where it would increase to one and that's that represents the current state of the network and then uh an event would happen called beer propose and this would notify both Alice and uh Bob as the recipient that this proposal has happened and then Alice would also have the total beer's owned here decremented and then Bob later can come in and say okay um I'd like to accept the beer offer so we can go ahead and increase my beer's owed by Alice to one plus one we're going to go ahead and call beer accepted again such that we both know that this has happened and then beer proposals for Alice are also going to be decremented by one and this beer's owed state here is going to change from a zero to a one this is going to change down to zero and so on um yeah so um Anthony I'm not sure when this question came in but um subrato um asked on youtube live uh which of the models is more secure for the limit for a limited number of transactions um I would say for any number of transactions UTXOs default to being more secure than accounts uh on a general basis right yeah but you could always take accounts and use them each individually as one UTXO and basically get the same types of privacy that you would otherwise but that's just not the way that most people program with them and that's not the way the model encourages it to happen um so what we have here too now and we can see is that a theorem kind of has this mutable state uh where the these values over here can change and uh it they and all these updates happen by new transactions calling functions that create changes in this state uh and the overarching point here is that the specific bug we're going to look at which is called a re-entrancy attack uh can occur because you have to think very carefully about each and every possibility and each and every line of code and how it affects this the underlying state and this can actually be a pitfall that affects even very seasoned programmers sometimes because you can end up with a bug that's very non-obvious and very interestingly here too uh bob because bob needs to be able to um man because bob is also you could actually ignore this this is actually an error on my slide bob doesn't necessarily need to know about beer zones so we could ignore that um borob s for multiple occurred transactions which model should we choose which can have high throughput uh both of these models can have high throughput I would say though that when in terms to concurrent transactions like you specified UTXOs tend to have much higher throughput because you don't need to worry about accounts interacting with multiple accounts at the same time uh like like you would in an account model and you a UTXO model you don't have to really worry too much about UTXOs uh interacting with other unknown parts of the history as as much so in general uh UTXOs um we only have a minute left Anthony do you want to wrap it up sure so I'll kind of skip through this I actually had a bug in my software up here if anybody actually catches the what I did wrong then that that's really cool I actually have a bug in how I was going to explain it anyway so this is perfect um anyway what happens here in this model is you get these kinds of multiple concurrent transactions uh essentially where a lot of these except beers are happening before uh the proposal has been decremented and as you can see earlier we had to check on these your proposals to make sure that they were larger than zero but we can actually push through transactions where many of those transactions go through before this check ever happens and so what happens there is Bob essentially manipulates the state to make Alice oh Bob 10 beers instead of just the one Alice had intended and then that is kind of avoided in a UTXO model where you don't have have this tie and this this constant state that you're keeping track between the two models uh once a UTXO is used it's it's gonna done and gone and so there you see here that one of these goes through and Alice stills still owes Bob the beer uh but all the other attempts that Bob tried in replaying that trend in re-entering that transaction ended up failing and so yeah that's basically the presentation and how they differ in practice as always you know go check out daml if you're interested in learning a bit more about the UTXO model at bit.ly slash try daml and yeah if you have any other questions you can always ask on our forum and I'd be more than happy to answer that link actually in the bottom left hand corner will take you to the forum and yeah thank you very much to Karen and Marta for having me and for making this a really and thank you to everybody who asked all these wonderful questions you made this a really great session and I'm actually really happy with how well it went so thank you all. Thank you so much Anthony and thank you everybody for your participation and your questions feel free to reach out to Anthony if you have anything else that you wanted to ask but didn't get a chance to as I said in the beginning we have more of these coming these are our next two sessions and finally feel free to get involved I shared some of the chats you can participate in there were a lot of questions about what's coming out with fabric we have this whole chat channel messaging service that you can engage directly with those that are working on these projects and find answers to your questions there and then finally thank you so much for joining us and if you did have any burning questions that you still are lingering feel free to email us at membership at hyperlige.org and we'll make sure Anthony gets them. Have a wonderful day thank you everybody. Thanks everybody.