 Okay, cool. Yeah, I think we're ready to get going. Okay, so, you know, hello and welcome to this hyperhazard meetup. My name is Orland and I'm your guest for today's session. Today we have a, we have a guest speaker and Antonio Lusarelli from Dammel, and he will give us an introduction to the Dammel language, and he will show us also how we can use Dammel in the world of fabric and maybe in the world of sawtooth. And yeah, this is an open session. I call this open session. And that means that everybody who is interested in give a talk to the topic, to hyperlature related topics can reach me. And then we can find a meetup term and then you can present your project on something, what you learn. And so, yeah. And today I'm happy to introduce Antonio Lusarelli and he will give us an introduction to the world of Dammel. Okay, so if you're ready, then you can start, Antonio. Thank you, Roland. Yeah, first big, big thank you to Roland for helping put this together and for giving me time to present on Dammel. I think it's a really cool language so really excited to be presenting and thank you very much for putting this together. Just to give you a little bit of background on myself, my name is Antonio Lusarelli, and I've been a developer advocate at Digital Asset who produces the open source language Dammel for the last year now. Just came up on my one year anniversary about a week ago. And yeah, you know, I've just been interested in this space for a really long time. Kind of a diehard Bitcoin or two on the side in the public space, but I think that Dammel itself is a very interesting language for the more private distributed ledger spacing in this whole very broad ecosystem. So today I'm going to be presenting a few things we're going to start with a presentation that's basically going to say, you know, kind of why would you want to use Dammel, and what cases would you kind of like what is it really. And then I'll be deploying Dammel live on multiple infrastructures all run locally, of course, on fabric and saw to thin them. We'll have time for questions at the end but if you have any questions while I'm going through this if anything isn't clear, you know, you can always feel free to interrupt me I really don't mind. And yeah, so let's get started. So the first question I have here is basically, you know, don't we already have all the programming languages we need. We have quite a few that will run on blockchains and distributed ledgers and then we also have so many languages in this world why one more. And really, my answer is, we don't. And the reason that I say this is because we have a lot of languages that kind of do the same things in different ways, all our languages that we work with today are largely imperative. And some of them are largely class based. And they do have nice cities. So for example, like, if I were to write and go, I could probably, you know, get up and go faster than I could in some other languages, or if I were to write in Java I could produce very well architected programs but ultimately they're doing a lot of the same things in different ways. So when it comes to blockchains and distributed ledgers, our languages currently behave a lot like these contemporary languages and in many cases actually are the contemporary languages. So in fabric, for example, you know the languages are Java and go and I think no JS runs in chain code now as well and there I think there's one more. The blockchains and distributed letters that we're using really their concerns aren't the same because when you think about it if you write a traditional program you know you get the ability to basically you're a full control of the state, you know, you write to your SQL database whatever you want, and you can change it whenever you want and you can even roll it back in time and a lot of these fairly common things. A lot of people come into this space and try to write programs they realize that they can't do these things and the reason they can't do these things is because that's not the way that our data persistence layers are really designed here. And so I think we should have languages that kind of help, you know, encapsulate this and thus by encapsulating it will make our lives a little bit easier. So damel really differs in what it does here and I'm going to go into that a bit. I'm also going to show I should have mentioned some source code during right after this presentation and before I actually deploy it. So what is down, you know I'm on slide six already just let's get to the point. What does damel do and damel is basically a portable language for distributed ledgers and really a lot of databases but it's designed for distributed ledgers. And so what I mean by that is that damel is a language that is really centered around this idea of you have a state and then you update it and the language itself handles a lot of things for you. So this actually that you're seeing on screen now is code that I'm going to go through in a little bit. But just to give you a taste. This is kind of what it looks like and how it's structured and what this structure does is it enables the damel driver and various damel components to know a lot about your program without you having to be very explicit about it. So with this code here demo has encapsulated all the business logic that we need. It's kept track of read write and execute permissions which are actually fairly similar to the way that Unix does it we even have one of my coworkers actually wrote a blog post on this that I thought was a really good point. And it also knows how to store the data, all without somebody having to tell it. And so it still powers front ends though that kind of look like any regular content. Here's the actual VJS code all copied and pasted to a slide. Just to drive home the point and you also get a lot of nice cities out of this. So going back here you not only get your data persistence. You'll also get your JSON API you'll get every way you're going to interact with your back end with your front end basically for free. So you can think about demo really as a consistent language for distributed and relational databases if you're programming. You can think about it as reducing complexity when you're developing these applications if you know you're architecting an application or you're doing project management on an application. And if you're a decision maker or really anybody. It really does result in faster development of distributed applications. You can get up and going really quick in demo, and you can do it without worrying about which back end you're going to deploy to you can go start writing your demos start iterating and decide whether you're deploying to fabric or sawtooth or eventually will have support for Bessu. Whenever you're ready. So in short, demos one of the first high level smart contract languages I won't say the first because who knows for this for these particular platforms with quite a lot of classes of bugs eliminated. So demo is actually itself based on Haskell. So if you are interested in functional programming even though demo in my opinion is fairly much easier to write and understand. There's obviously from doing that we get quite a lot of these nice cities where we get a lot less runtime bugs and if we have a bug in our code a lot of them end up as compile time errors, which is also great. It's also adaptive to changing requirements and needs throughout the entire project lifecycle. So basically, you know, if you need to change one of your demo models. It's generally not very complicated and because everything is so well permissioned when you go and start changing things. If you've changed something that something else depends on, and you have an updated the other dependency well it's going to really era compile time for pretty much every case. And it's also, you know, like I mentioned earlier very ideal for transitioning from rapid prototyping through to production deployment prototyping it's quite quick in and you'll see people on our forums who are regularly prototyping their, their ideas and demo. And then even in production. Demo is being developed and deployed at Australian stock exchange at Hong Kong exchange and a bunch of health care and other financial applications and hopefully I think should be deployed in a variety of different applications and there's quite a lot of others working on demo stuff too but I can never remember who I can and can talk about. So just take my word on that. And so now I kind of need to, you know, prove everything I said so we're going to check out my toy production app now. It's called Oh beer it basically is a way to record on a distributed ledger who was who a beer, who has an obligation to and then we're going to deploy it on fabric and sawtooth and just to prove how portable this is if I remember I'm not going to rebuild my project in between. When I deploy it on fabric and sawtooth I'm going to just deploy the same exact compiled dark file. So, yeah, let's get started with this. Right. So first thing I need is demo on fabric, which is a demo driver. And what we mean by the term demo driver is that this is essentially the layer of our demo application, or really our demo tech stack not part of the application that is responsible for writing and reading data from our fabric instance. So we're going to start up a fabric instance, then we're going to connect our demo driver to it. And then to that we'll connect the demo JSON API. And so the way it'll work is we'll have our front end application, talking to our JSON API, or it could even talk to another API but a more advanced one that I won't be covering today. And after it talks to the JSON API the JSON API will talk to the demo driver which will be responsible for making sure the right data is written and and retrieved from the our fabric instance. So that's kind of the architecture and that's also how we get this portability, because in every single case you're starting up a demo driver that actually talks to the chain and records data there. You, the trade off here to keep in mind is that you don't get a, you don't get to actually manage the transactions directly on your fabric instance, you couldn't write some chain code that reads and writes them. So in exchange for that, you get this very portable language and really, we should be thinking about, do we want to do that in general like for example when I write Python code. I don't worry about the machine code layer of what it's running on top of you know I would write anything higher than, if you write anything higher than CRC plus plus, you know you generally don't concern yourself with these things and that will generally make your life easier you know that's why we also write in Java and go and all these other fun languages. So, what I would do normally is I would go to wherever I was going to download it, I would install the hyperledger fabric tools but I've already done that. Oh, I'm on the wrong version of the French. I actually just updated this to fabric 2.2 exactly for this, for this meetup we were previously on I think 2.1. And so you would update this and you would go ahead and clone and then you would navigate over to this directory and run a couple commands so let's do that. That's the wrong terminal. So over here, we're going to just change to this directory in our download fabric code. We're going to run gen.sh which is going to generate all of our configuration data. I'm not an expert on configuring fabric servers so just take my word for it that that's what that does. And we're going to start up fabric now with our restart fabric commands. This is going to get going and I think it's almost up and ready once this is done ticking by. And so that's basically it though for our fabric instance, it is up and going if you were to do this yourself when you first download it, it actually would spend some time building some Docker images so that would take a little longer on the first go. I already did that since I don't want to wait the five or so minutes that while it being a fairly short amount of time in general is a fairly long amount of time when we're talking presenting online. And so yeah our fabric instance is up and ready to go. So what I opened up over here is our deployment guide to that I wrote previously, it basically shows how to deploy one of our example applications on download fabric, I'll be showing you a different application, but let's just follow through for the steps. So first step is going to be building our damlap. And in that case I'm going to be using a beer, which is a really small little app for owing your friends and enemies beers. And so, just two simple commands would be. Click on this so we'll go ahead and do daml build from our beer directory and all this stuff is open source online this is actually BST zero our fabric and saw tooth daml drivers are Apache to so if you want to check those out. Feel free. And then we're going to run download code gen JS and what this will do is it'll actually go ahead and look at our model and generate a lot of nice JavaScript code for you and while I say that I just remember that I haven't actually shown you the code yet that will be deploying. So let me hop over there first. Actually, I'll show you this after we deploy the first one so I don't interrupt the stream too much. Okay, so over here. What we're going to do now is we need to start up. Let's see we've combed our damlap fabric instance already, and we've built our application. And now we're going to start up our daml driver so this command with SPT here will actually start up the daml driver, and that'll take a second. Yeah, if anybody has any questions at any point feel free, feel free to chime in and this will take a moment anyway to get started. Can I ask a question. Sure. Well, when you start the fabric network, then we started with a Docker compose file, and then we have to be beneath the channel. So how we can choose the right channel. I think right now by default, this code chooses a channel for itself. But the way you would do it is somewhere in the daml driver I think that's a great question I just don't know the exact exact answer. I think right now what it does is it chooses a free channel basically. So you use this we start the network script maybe in this script is because we have to. And then the next question is, do I need a chain code for this so I need that I've seen the Genesis block is created through your script. And then we need some, you know, channel and the chain code to run this to run fabric so and then your driver connects to fabric so what is the point where we where the connection starts. Yeah, for the chain code itself basically our daml driver has some custom chain code that basically, when we start up fabric over here. It starts the fabric network. It sets up the channels and peers, and it deploys our custom chain code to that fabric instance and then that chain code is basically going to be used for communication between our daml driver and the fabric instance for managing the data for basically reading and writing to the chain. Okay, so that means that I need the fabric network. So I can, I can make an Docker compose file with my favorite network. And then, then I start your script and with the script the Genesis block for it for this network is created, and also a channel is created with the default name. And then your script creates a custom chain code, which will be installed also on this custom channel. And this is the way and and this is the way how this works. So we don't have to create a chain code. The only thing what we have to do is to set up a basic network like the test network, for example, from the favorite samples and and the rest come from your script. Yeah, exactly. Okay. Yes. And this script actually to even starts up its own fabric test network. So basically from reading the code behind this daml driver you can see where and how it does all of that. Okay, thank you. Welcome. All right. So now we've got our driver setup. So now what we need to do is we need to go ahead and deploy our code. All right. And deployment is going to be the same, regardless of where we're running our demo code. So now from this step forward, it's basically identical except ports are going to change depending on how the daml driver is configured. So over here, we have to run daml deploy. And that's going to set up some parties and also compile our jar again and deploy it to to the daml driver, and you can actually see that here. The daml driver is going ahead and writing code to the fabric network and the fabric network is acknowledging and receiving it. And so now our code is actually live and running on it. And the next thing to do is to get our JSON API set up. So here we'll just run our daml JSON API commands, which supports 6865 and gives us ports 7575 as our REST API, basically. And now the final step here will be setting up our ledger. So talking to all ledgers is very similar. The only real thing you need to be concerned about is kind of how do we authenticate with the ledger, which will vary depending on the ledger and that whichever authentication methods fabric accepts will basically just be passed through by the JSON API. But anyway, over here, one thing we do need to do though is that our daml ledger slash driver cares about the name of the ledger ID. So in this case for the fabric one it's fabric dash ledger. So I'm going to head over into my UI folder, and I'm just going to set an environment environment variables that talks to the fabric ledger. And then I just have to go ahead and start my UI. And actually this this is written against React, but you can use obviously any front end you want with our JavaScript libraries and the code and the generated JavaScript code. So I'm actually using view which is why the command is just slightly different. So I'm going to go ahead and log in and do everything but first before we do that I kind of want to talk about the code of it, just to, you know, explain kind of what it's doing and how daml manages to get all the setup on the back end without having to write too much. Well, we have here are basically two templates and in daml even though it's not exactly the same. You can think of a template as a class. It's basically some something that's sitting around waiting to get instantiated into contract which you could also think about as akin to an instance of a class in an imperative language. And so here we have two of them, beer proposal and beer down here. And basically we we need both of these because one thing that daml does is it requires us to think about our responsibilities and obligations to other parties on the network and to be very explicit about them. And this is actually one of the things where if you were to try this out, it might cause a little bit of hang up because probably less so for people used to distributed ledgers but something I see sometimes is that a lot of people are just used to creating obligations between people or between parties without those parties having explicitly presented it. So for example, you can kind of, and this is why it's used a lot of financial applications and health care and other things where you want a very strong chain of guarantees of who's agreed to what when. But if you think about it almost any program we write is kind of like that. So for example, if you were to want to send out a tweet, you know, you might type up your tweet and send it to Twitter. And then Twitter would, you know, accept your tweet and post it to your timeline and share it on all your friends news feeds. And really in all of that. There's no cryptographic or other guarantee there that you've ever asked Twitter to do any of this. And there's also no cryptographic guarantee there that Twitter is going to do any of this. And so what you get here when you're being very explicit and that's why it's important in in dammel is that you do get these guarantees that yes I did ask Twitter to and Twitter either said yes or no. And no I did not actually write that tweet and Twitter, somebody, you know, edited the database. That's saying that's going to happen with Twitter but just as an example like there is a common thread with current day applications that a lot of your users and your partners working with you really don't have any, you know, day over the process and then it leads to these very particularly in the enterprise space, a lot of very costly and ongoing settlement and reconciliation type of situations where a lot where parties have to come together and figure out who belongs where and who actually did what when. And so here we're trying to avoid that. So that's why this is going to be structured like that my rather long winded explanation of it. Anyway, so here are our proposals, what we're going to do first is we're going to basically make an offer to owe somebody a beer. So for example, I see barts on join the call so if I were to offer Bart a beer. I would basically say, okay, here's the proposal with the beer that's encapsulated so this beer here will be will represent the same type of data that's in the template down here. And then we have our read and write permissions. So what we can see is if I were to want to owe Bart a beer I would create this contract and I would be the signatory the person who's giving the beer and Bart would be the recipient, the person who's receiving it and with the signatory designation. Basically, I am saying that I am the one who has the ability to create this proposal. And I'm saying the recipient is the one who has the ability to see or read this proposal so there we have our right and read permissions. We have insured that can also assure certain preconditions such that one person can't owe the other person of the spear and also with these two constructs. We get this very good thing where, even though you know Bart and I know each other from the demo forums, and we trust each other. We never create a contract that says Bart owes me is making a beer proposal to me even by accident because demo is guaranteeing that only the signatory is the one listed so I can sign for Bart because I wouldn't be Bart's party on the ledger. Then we have a bunch of execution options which are basically I as the recipient here, the controller of the accept beer choice can choose to accept the beer as the controller of the reject beer choice I could choose to reject the proposal and Bart as the giver can choose to as long as I haven't accepted it yet to cancel the offer. And so the way all of these choices work is that they are consuming choices. And that's very much akin to a UTXO model. It really is a UTXO model as far as demos concerns where when you exercise a choice on a contract, you immediately archive that contract and either replace it with a new one, or produce other contracts. Or replace it with nothing in which case it just gets archived. So then you have this state where everything is immediately and it's guaranteed to not be called multiple times. So I wouldn't be able to, no matter how quick I was no matter how close to the server I was, I wouldn't be able to call Bart's accept beer choice, or Bart wouldn't be able to call my accept beer choice multiple times. He would just be able to call it once because immediately and atomically when this beer is created here, this template itself actually gets archived. We do have non consuming choices where that doesn't happen. But one nice thing here is that this makes sure that if two transactions conflict, you know you're not going to encounter the double spend issue, because it is intrinsic to demo. And then down here we have the actual beer, which will be instantiated once this is accepted. And then we can see we have our given recipient parties, which we have referred to appear. And now we both can actually write to the contract because also these permissions are transient. So when Bart provide when I provide my signature up here. That is basically a permission that for all child contracts spawns from this contract are going to carry over with my signature and then Bart, since he's chosen to accept it which creates the beer can go ahead and be the second contract. So now we both have had guaranteed permission to produce this bit of state on our ledger. We can again ensure that given recipient are not the same. This actually, I probably don't need this one up here. Now that I think about it because this one down here will actually ensure the preconditions as well. It just helps that you can't create an invalid proposal that somebody could agree to and then result in something that can't be created later. And then, yeah, ultimately, right down here I can then whenever I give Bart the beer Bart can go ahead and say, Okay, I've received that. And so really to a lot of these functions that have pure can mostly just be considered helper functions when when the signatories already there. They're not really necessarily needed because archiving and contract is a choice that every contract has, but this makes our code a little a little nicer in appearance and a little easier to understand our intention behind it. So that's the code and I know I talked a lot about these few lines of code, but it does encapsulate quite a lot of logic. And one thing I should mention here is that when it comes to the declarations at the start the with declarations you can kind of consider this kind of columns in a sequel table and the templates would be the actual tables that get updated atomically so whenever you whenever they change, you know they get swapped out and overrated. So anyway, we're going to log in now, and we're going to go ahead and log in as Alice which is one of the parties on the ledger, and we're going to offer a beer to Bob, and then we're going to also offer a beer to Carol. And so now we can see that we've done our beer proposal over here. And basically Bob and Carol are going to have the options to accept beer or reject beer. And also they're not going to be able to see each other transactions because in one we have Alice and Bob as the given recipient and the other we have Alice and Carol as the given recipient. So we'll go ahead and log in as Bob. And here we go and can see that Alice has offered it, and Bob is going to go ahead and accept, which would correspond to this choice here. So then that choice will go ahead and instantiate our template down here, and Bob will, being the recipient will have the ability to mark this as receive. So Alice gives Bob the beer and Bob goes ahead and says it's been received. And then it gets archived away. And then Carol, same thing here. But Carol doesn't want the beer offer so Carol can go ahead and choose to reject it. And that'll just go ahead and archive that proposal and now it's, it's no more and can't be interacted with. So yeah, that's basically the program and how we would deploy to fabric and get everything up and running. But now I'm actually going to go ahead and do the same thing with sawtooth. And so let me just take down all my services. I'll just take them down in order from the top of the stack down to the bottom. So they don't start airing out. And yeah, okay, so that's done. And now we're going to go ahead with and check out demo on sawtooth. And this was actually produced by blockchain technology partners which is one of our partners. They made the demo on sawtooth demo driver and also open sourced it. So I think that's really great. It's really always nice to see, you know, people building on top of open source projects that they may not, they work, they work with themselves. They use themselves but that they may not, you know, be as direct as digital asset. It's just good to see that, you know, our ecosystem there has these contributors. So I really, really just appreciate these contributions very, very much because I think that open source is basically the lifeblood of any good long term project. But anyway, what we would do with demo on sawtooth is we would of course go ahead and check it out with a get clone and we would also build it in much the same way that when you do do the demo on fabric one if I had done this completely live it would have spent about five minutes building we're going to kind of though skip that though we do need this isolation ID, just because it would take a few minutes and then that would just be kind of a waste of time. But anyway, over here, set this which needs to start up. And one other small thing to keep in mind for this particular demo driver is that this command here that's going to start everything up will also start up the demo driver itself. So, just as unlike before where I started up the demo driver separately, this script just starts up the demo driver together with the instance. That's just something to keep in mind, it obviously can change because this is an open source project so if you're checking it out though just don't be confused it's just starts up everything together, and then runs it on for 9000. This is going to take a moment to get started up. So, yeah, if anybody else has any questions during, you know, you can feel free, feel free to ask. But yeah, it'll just take a minute. Could you give us a path when somebody want to start with Dahmer, what is the first step and do you have a learning path for a beginner, for a demo to be a beginner. Yeah, that's that's a great question. So one part of our learning path, especially if you're a beginner and you want to understand them a little bit because it does take just a little bit to wrap your head around. So we have our demo comm slash learn page. And so basically, what that is is a bunch of in browser examples that will actually execute on a remote Linux server somewhere, and allow you to just basically walk through all the steps of learning the demo and getting started with it. So, for example, over here, if you wanted to walk run through this deployment again without watching this video, you can go to deploying demo and production ledgers, and then try it out on fabric and on sawtooth. And what you'll get here is basically the entire thing of running these so you'll basically be stepping through this deployment guide here. And it'll be pretty much the exact same thing, except interactively online and you don't even need to download anything to get started. Obviously, once you want to build your demo applications, you know, you can go to our website and go ahead and, you know, click to get the SDK. The website actually will change probably in another few days. So, you know, look, look forward to the new styling on it. But that's what I would suggest for when you're first getting started. And then, of course, when you want to learn demo in depth, and you want to get to writing demo we have just excellent introductions to demo. This in particular under running demo and introduction to demo is basically how I personally learned to write demo and I can tell you from my own experience I am somebody who has tried many many times to learn a functional programming language and not ever gotten too far. And this actually taught me basically all I needed to know in order to to write demo. But of course, when you get to the more, while you're going through this journey you're going to have questions. So we also have our forum. And it's a very actively trafficked forum that, you know, you can go ahead join, ask your questions if you spend more than five minutes on the docs or demo.com slash learn really just come over to discuss dot demo.com and go ahead, hop over to the questions category and make a new topic. And so, you know, I could actually say how does demo on fabric choose a channel. On my fabric instance, like, like Roland had asked before. So just give it a little demo on fabric tag. And I'm sure within the next couple hours and oftentimes even faster somebody's going to answer that. Anyway, so we'll get we'll get our answer for for sure from people who work much, much more directly on these particular components Rollins. Okay, I've been watching. Okay, great. And, yeah, so I think we're we should probably be started up now. And yeah, okay, we've definitely started up we can see here that we have our demo driver running on port 9000, sometimes also called down on RPC. So we won't be able, we will need to start that ourselves. And like I said before, I'm going to avoid recompiling the code. I misspoke because demo deploy actually recompiles the code whether I want to or not, but it is the same exact code being compiled down to the same exact Dar file. Oh, and just FYI Dar files. Oh, I'm deploying to the wrong court. So that's why we timed out because this one's running on port 9000 Dar files are basically the same as jar files in that they are demo compiled down to an intermediary called down a lot of that, you know, you don't need to know yourself the compiler just makes it for you. And then basically zipped up in the same way a jar file is with all its dependencies there on a single self contained executable for deployment. And then we're going to start the Jason API. Again, we're going to talk to our or 9000. It'll get started. And then basically just like, oh, I need, I do need to change the environment variable though because over here, where is it? I can't see where it is in the output. It's probably over here somewhere in the output. But anyway, this one to calls its ledger by something else. And then go ahead and the answer again. And so now without, you know, changing a single line of code just with changing the, the infrastructure, we can have the same code running on completely different type of infrastructure in this case being sought to. So we'll go ahead and log in. Maybe this time we'll log in as Bob. And Bob will offer a beer to Alice. The first time you do this, you run something on sawtooth. I think it does some just in time compilation so it does take a moment. But then after that, it speeds up quite a bit. And then just like last time, you know, Alice can go ahead and log in and choose to accept or reject. And then, you know, Carol could have done the same thing as well. So, yeah, that's most of my presentation. The one other thing is that if you want to follow any of the links that I showed before, you can get started with discuss dot demo dot com. slash start, and that'll take you just to a post that has basically everywhere that you would want to look to learn demo and to understand it. I recommend really demo dot com slash learn learn first. And then if you're interested further go ahead to docs dot demo dot com and always come by the form for task questions. We're all very friendly there and our engineers particularly love the form so they're always, always on it. And also, you know, if you need any of these useful links, you can go ahead and click on this little icon up here and check out all the useful links that give you much more information about demo and kind of our communities. And yes, so that's my presentation. And thank you very much for having me if there's any questions I'm more than happy to answer them. Thank you so much, Antonio for this great presentation and introduction. Are there any questions. Yeah, this is Daniel. Hi, everybody. Thanks for the presentation. I would ask what's, what's the public infrastructure model behind behind them. So how are, how are transactions signed. And it is somehow integrated into the into the public infrastructure of high pleasure fabric. Yes, so the public key infrastructure and we do have some blog posts on that as well. I'm going to try to pull one up here as I'm talking but basically demo intends to not have any opinions on that infrastructure instead. What it does is it. It basically relies on the public key infrastructure that you that's already existing within your enterprise. And so whatever PKI you're using, it can just, it can handle and Edward actually, I'll share this link in the chat goes into how that works in much more detail than I can explain because that is definitely beyond my, my knowledge of these things. Thank you. Welcome. Any other question. I have to ask her one question to fabric. I would like to ask so we can use a different world state so we can use a level to be or couch to be, but you mentioned that use the infrastructure from fabric. And that would mean that I can use a couch to be database as a world state or also level to be if I would like to do this. That's correct. Yeah, there's no anything that that fabric uses on its back end is completely up to a sample doesn't really have opinions on the infrastructure of your application. I need only and I need only the public keys that are the crypto material from fabric CA for example, only for the for beer for the beer communication for order are not for the users. Yes. You sent up in your example. Why do you create a lesson pop in your example. Oh, so all parties on demo ledgers are created explicitly. So with that, that happens with deployment. So over. It'll be nice to look at in Visual Studio. There's a lot of parties that are declared. And basically when it goes to deploy these parties are created. But they're the other ways you would do it are there's a way to create parties over the JSON API endpoint and then there's a way to create parties explicitly on the command line using like a demo ledger. I think it's like allocate parties or something like that. Basically that's those are the various ways that parties are created in demo so you can actually go ahead and create parties and associate them with it whatever. Whatever kind of cryptographic data you want. Okay, so that means that these these parties are not created in the fabric network. These parties are created in the demo system. Yes, I believe so, but there's also a lot of active development going on around that. One of the very interesting things that is still being produced. And so what we're going to be talking about is what we're going to be working on, which basically manages a lot of the party creation and actually intercommunication between even despair ledgers so like having fabric talk to sawtooth. And so some of these things. Some of these things will, would basically, they might change and they might also start, you know, referring to actually you should probably ask that on the forum because I don't think I can answer that accurately enough. So another question maybe so in your template you have a beer. So can I set up more properties for a beer. Yes, you can definitely set up more pure properties let me close this folder, open up the download fabric one. Let's see where gen.sh takes in a bunch of the fake data from up over here so over here is basically, you can configure your servers however, however you want it takes the same exact configurations really it just all wrapped up in a nice easy to deploy commands but yeah everything's in here. Okay. So here we have the config.exe.yaml file and with this config.exe.yaml file we can configure the channel. And yeah, and with crypto config so all crypto material here is created with config.exe because we have a crypto config.yaml file here. Yeah, for the crypto material. And here we can see that's a fabric 2.2. Version because of the configuration here. Okay, so any other question. Yeah, perhaps I would have one more question from my side. And the question is how much we can integrate demo on fabric with like private data collection. What do you mean by private data collection. There's a special construct in Hyperledger fabric it's called private data collection. It looks like that way that your that your data is not written into the ledger, but basically only the hash of your data is written to the ledger. And you can control that your data is basically propagated on a different gossip network. But again, so the main main idea is that your data is not in the ledger just the hash of your data. Okay. The content of the data is written in the site database. And the advantage of this approach is that you can delete this data set for example. And that means that when we delete this private data set, then we can delete this only in the site in the site database. In the on the ledger and the channel is only the hash of this data set so nobody can read this hash. But only allowed organizations can read or write this data set in the site in this private private collection. This is quite private collections. And this is a way to be a little bit more GDPR compliant. When we have sensitive informations like personal informations, then we can use this kind of technique to store personal information into the blockchain, so called blockchain. And later we can delete this from the blockchain system and in other systems with other architecture that wouldn't possible. So, and this is a great advantage from, from fabric that we can delete data. And, yeah, and that's the question I think Daniel would like to ask how we can integrate this when we deal, for example, with sensitive data or personal personal data, because in the Europe so we have a problem with the GDPR. So, and we must take care on this topic. Yes, so for this particular driver the way it's written right now I don't believe it uses any of the, any of those privacy features, but what I can tell you is that GDPR is a major concern of digital asset to. It is being worked on to make sure that when the various infrastructures we're using offer these abilities that it'll be able to, you know, to be done so that, you know, demo actually in and of itself does have these abilities to have kind of sub sub transaction and to not write things to the ledger sometimes if a bunch of steps can essentially occur kind of off chain. And then these features are going to be better integrated with the various infrastructure options and that's kind of also part of where Canton comes in because Canton something that allows for this, the similar type of thing where, you know, you can have not every bit of data stored on on nodes and it can eventually be deleted and prunes and pruning is a huge thing that they're working on and also be GDPR compliant because yeah that's something that I think all these things face right now but we're definitely definitely working on it. Just just one more question you mentioned like transaction privacy. So, so what do you mean by that I mean, we usually have the problem is that I mean in February, you have some kind of a transaction privacy, but there's no privacy in terms of encryption. So if you have practically a database administrator, the database administrator can log into the, to the couch David for instance or level David, or to the puts and container and can reload the data, even if there's some kind of a read access in high college or fabric. So, so do you have something in terms of better or integrated in terms of transaction privacy. Yes, so what I was referring to their was kind of referring to two things is demo has this notion of sub transaction privacy, which is essentially, if, for example, you and I had a variety of contracts that we had to fill up between each other. And we had like kind of a starting state and ending state, we could kind of, and I don't know the technical details of this, but for some of those things, if they just required both of our signatures at the end, we could sign them and produce some other contracts without storing all the intermediary steps in between on the ledger like we didn't need to store every single, every single part of other transaction we could just store essentially the resulting state as long as we've all signed off on it. Thanks to having signatories. And then the other thing there is that demos other current method of privacy is it only shares data as far as it needs to go. I know some infrastructures replicate all data across all nodes. But if you have infrastructures that don't replicate all data across all nodes, and you and I, for example, our parties on on node a, and we have a contract that rolling if Roland's on node B and part of the same network, Roland actually won't see that contract because it'll never be shared to Roland unless Roland needs to be involved in it. So we get privacy in that way, but we don't currently have enough privacy to actually delete data yet or to encrypt it so people can't can retroactively read it, but we are working on these things. Okay, cool. Thanks. Welcome. Okay, any final question out there. So if not, then I think we are great in time. Thank you so much Antonio for this presentation for your time, spending with us. And yeah, I hope we will see us in nature in person. When you come to Switzerland, the company in Switzerland and yeah, so you're awesome. I would be very happy to. Yeah, so, okay, then thanks for all participants to take part of the session today. And on the next session, we will see my session about the chain code test environment. So I will provide the session in this way. And yeah, so this was from my side and stay safe. And we see us next time. Bye everybody. Have a great day. Thanks. Bye.