 Great. And record the cloud just in case. Okay. Let me start us off. Well, we'd like to welcome everybody to this workshop, which is called how to create a currency management application and deploy it on a hyperledger fabric network. This is with all Linux foundation meetings. This is held under the Linux foundation antitrust policy. If you have any questions about these matters, please contact your company council or if you're a member of the Linux foundation, feel free to contact Andrew up to grove of the firm Gesmer up to grove LLP which provides legal counsel to the Linux foundation. And this is also held under the code of conduct for hyperledger everyone's welcome here we appreciate all of you joining us today. And we really appreciate our three presenters on a Angelo and Marcus, we're going to do such a great job. I'm going to put some links in the chat the chat is open if you have questions you can put them there. I guess, Angelo let me know we might make natural breaks in the presentation and but also if you're the co presenters want to answer a question they see in chat feel free. And I will turn it over to David Boswell for one second. Sorry, I was just unmuting and having my screen come back on so thank everybody for joining I'm sure I think we'll have more people joining as we go but you know we welcome you as Sean said we welcome any questions. Yeah, you know this is intended to be an interactive learning session so thank you for joining and thank you again to the speakers. You know if you missed the earlier workshop that happened earlier in the year will drop that in the zoom chat as well this is a two second part to the workshop we shared earlier so we'll drop that link as well but that recording is available. This is will be live streamed and recorded as well and again this is meant to be an opportunity to learn more about fabric and what's going on the hyperledged community and we welcome you and thank you for your time. And with that I'll turn it over to the team. Very good. Let me start then sharing my screen. It should work smoothly I tried already before. Let's see. Okay, that's good. Let's go full screen. Hope you can see my screen. You look great. Looks great. Very good. Thanks a lot everyone. Thanks a lot Dave and Sean for organizing. I'm very grateful. I know that I reply very with a lot of delays sometimes so I'm very grateful for your effort in organizing all this. Thank you so much for everything and thank you everyone for joining our session and also for watching later the recording I really appreciate your spending your time with us today. So today's session is as David said is just a kind of a continuation of the first part that we did before was very more if you want theoretical we described the framework of the setting. And even today the first part will be quite short but we will reintroduce the main concept I will talk about the central bank digital currency and then the second part that the longest one will be all dedicated to a dive deep dive into the token SDK and how we can build a simple a simple application for currency currency management. And with the goal with the question for us will be, is it really that that easy to do is it really that simple to put together an application for potentially a central bank digital digital currency application. So the car first I'm sorry, I should have introduced myself I'm Angelo de Caro I'm a senior technical staff member at IBM Research Zürich in Switzerland. I'm one of the architects of a fabric and I, and I manage for IBM research the, the, the, the effort of for central bank digital digital currency. So today with me there is a Marcus Brandenburger and our new chess, when they will introduce themselves when it's time to for them to jump to jumpy. Okay, very good. Let's start a few, a few logistic just a few links that I want to put here. The first two the preview will see already in the chat but the, the, the, the second part of the one on discord if you want to reach us on discord. I think it's also, it's even better than the zoom chat because there we have a history. So we can, we can keep track of your questions and the answers. And if we don't manage to answer right now, we can follow up after because we have the history of the, of the transaction. The messages, this is the link of the server, but you can find easily on internet and the channel is the fabric token fabric token SDK so please take your channel, your chance it's either the chat here on zoom or on discord we will keep monitoring both both channels so we can address as many questions as possible. But again, the goals, the goals are very important for today, for today's presentation. Of course, we want to have again, we would like to have for you at the end of this presentation to, to go back home with a basic understanding of central bank digital digital currency to learn what's the token, the token as the game was the framework that we that IBM open source for everyone. And also, we would like to start you with the, with a journey with the token SDK so see how the, how to develop your first application for token for currency, for currency management. So, of course, we want also the, our hope is that you will like it so much that you will also come back a contribute to the, to the project and make it very, very interesting for the hydrologist community. The agenda as I was saying before, we'll start with an introduction, I promise, very quick, I will not bother you too much. And then Arne will jump in and we left the deep dive into the token token SDK. The menu is good enough for you. And let me start with the, with the introduction. Actually, I wanted to show this picture again, this picture I took when it was probably last year, last year in Dublin when we had the average of global form. So, I was going to the venue and, and I saw this there, use cash keep your freedom that I found it beautiful from the following point, from two reasons. First, it happened, I mean, out of the blue, I was not expecting to find this I noticed by chance that there was this second, it's a very powerful message because it says that if we want to introduce a new tool a new way to to implement money in the in this in the society, this tool must give must must must guarantee a high privacy, high privacy guarantees, and also freedom that always the possibility for the end user to choose how they want to manage their, their money so for me with this was a really crucial message to your technology must be not only very good, but must be something that people can trust can believe can believe in. So, I hope that we're doing a good job at the future will, the future will tell but let's let's keep in mind this right there are people that are skeptical that the right to be skeptical, and we have the duty to answer their questions and to make sure that everything is fully fully understood. So now, and I want to start usually the, there are many ways to talk about this kind of system currency currency system. In most of the cases, you will hear that blockchain is involved in a way or in another, and for very good reasons, right blockchain is a good technology for this, for this kind of application, because you, you have many, many parties who have conflict of interest, particularly, and they find a huge value in having a common ledger, where the list of transaction is fully tracked, and is, is, is trustable by, by anyone. Now why this is convenient. First, having a synchronized ledger means that this is you don't essentially most of the cases you don't need any reconciliation so it comes handy to have something, something like this. It also simplifies the process of establishing new, a new commercial relation right because there is already a source of truth that is shared, and this can be very helpful to bootstrap quickly, quickly an activity. It doesn't come for free there's no free lunch we know. So there are the fact that there are all these mutually distrusting participants, means also that there are there is a concern about privacy right in the information that is with respect to the information stored, stored on the ledger so it's nice to share but only with the people that I want to share, share with so here the challenge is really to combine transparency with the privacy and, and, and scalability. In a case like a central bank digital currency. We also have to add to the picture, regulatory compliance, and also the fact that you might have in homogeneous regulation around the world so we have to make sure that all the power that the law is respected, and the regulation is respected, meaning that the central bank can deploy their policies as the country as they, as they decide to decide to do. So it's an interest, it's an interesting intersection between requirements that my seems or they might seem even contradicting to each other and privacy, they might be at odds to each other but actually there is a way to, to make them live to live together and, as I said, 25k it's a, it's a good it's a, it's an important number it's not, it's not a small number in terms of transactions per second there needs to be final that's important as well so processing 25k transaction per second, it's not enough, they must be final this transaction is almost instantaneously the latency that the system requires it's usually very low it's around seconds. So that's, it's very challenging in practice, especially to keep these running 24 seven. That's, that's one of the challenge. And let me just present you a very high level, a typical representative typical architecture for central bank digital currency. You have, in most of the cases, not always the case but in most of the cases you have at least two types. You have tired one where the central bank essentially leaves from which they deploy their, their policy, they can perform the limit and they can enforce limits. They can have an extra bookkeeping for special, for special purposes, even identity management that's definitely something very useful in such a way we can have a clear identification of users across across the board. I know identification means also privacy, privacy violation so we need to, we need to deploy privacy scheme identity schemes that support full privacy. So we have a tier two, where essentially there are multiple networks, different kind of networks. As I, as I was saying before, we don't expect that there will be a single network that will rule them all, we rule all the other, the all the other networks prevail over, all over, over all the other networks, but we might have different networks potentially with different technology, not even necessarily all decentralized and some of them might definitely be fully centralized as a, as a, as a, as a back end. In this case it's very important also another aspect that is very crucial in central bank digital currency is the ability for this network to, to inter, to interoperate. And just a small jump forward to say that we will not touch in this, in this presentation interoperability, but the token SDK supports also interoperability this might be actually Sean David might be a third workshop where we focus on interoperability among different central bank, the central bank digital currency networks. Yeah, that's great idea. That can be very interesting. And of course at the end there are the users, the consumers with their wallets facing these different networks, they might have multiple requirements like portability or programmability of currency. That's really, that's what before I was saying, what's the best technology, we don't know yet because it depends on the, on the requirements and the requirements are still evolving so that's something that remains to be to be seen. There are other aspects like do we want to have only online online transactions meaning that both the sender and the recipient must be online or do we want to support also offline transactions where we keep paying without having to connect during the transaction, we only maybe at the end of the day or after a few hours or we have connectivity we connect every reconcile with the, with the back end. There are so many interesting problems really and look, look, if you have questions, please even follow ups you want to do to learn more about these aspects please reach us as well on all the available channels. So, just a summary, what, when we talk about the central bank, the central bank digital currency we care a lot about this interoperability ability to perform atomic asset exchange so the assets, this assets currency can flow freely over this, this network, and we want also the system to be very efficient and of course, private, to be, to be private. So these are the three, the three main topics if you want to today we, we are focusing essentially on, on, on the last if you want so how we put in place at the application that supports privacy, privacy, automatically, and is as efficient as possible. If I don't remember well I think Arne will give us a few examples of, at least one example of regulatory compliance where we can introduce rules to force a certain transaction to, to be of a certain, a certain shape. I like for you just to, I like to have this, this, this slide for you as a summary of the complexity of, of the entire system on the left hand side, we have a high level requirements for a central bank digital currency. Some already mentioned the privacy compliance accountability resilience scalability in interoperability. There are certain certain requirements that are really related to the governance, like the fact that the system needs to be compliant. The system must guarantee accountability and transparency and some that some some other requirements that are really more related to the transaction processing itself so it's really more about the technology. The point here is essentially this that the requirements are so many that we need a holistic approach to, to address these requirements all together from the infrastructure this is a non I'm referring to the right hand side of the picture. From the bottom layer the infrastructure where we might need dedicated hardware to accelerate the processing of transaction or to make to make sure that the secret keys are super secure and so on and so forth to the platform so where do we run our ledger how do we describe this edge which kind of a platform do we use we use fabric do we use something else do we have a do we need GDPR compliance do we need a high scalable content so on and so forth. The middle layer where are where we need to face problems like not only the management of the tokens themselves that are representing the currency, but also what do we do how do I identify people what does it mean that a token is owned by a certain legal entity. How do we represent this, what does it mean if I lose my key doesn't does this mean that I lose my money or is there a way to recover to recover it these are all questions that are that rotate around gravitate around the identity management. system, and then on top of this we, we might have all sorts of application from whole sales CDBC which is more the intra banking payments to the retail CDBC so what we are supposed to use every day, even non fungible, non fungible tokens. I'd like, I'd like now to talk a little bit about the decentralized enterprise enterprise privacy that I mentioned maybe quickly before, which is, it's a way it's the way we call the privacy mechanism that we would like to have for a central bank digital digital currency. Remember that one of the, the requirements is compliant, which means that a certain point in time someone should be able on an entity that it's that is under that is well identified by the law should have access to the to the information but let me go step by step so on the left hand side of this slide you will see are a picture representation of a ledger. We here report the account base and the UTX version of the ledger it doesn't matter they are representing the same, the same information. The point there is that there is a ledger where there are transactions described in a certain way, and everything is in the clear so who has access to this ledger has all the information about what's happening. Now, as we said, as I said at the beginning, this is not exactly what you want, because it's fine to have a common ledger, but having the information in the clear, these give an objective advantage to a competitor, for example, so that's not exactly the way you want to implement a central bank digital currency because there's no privacy and I might not want to reveal who am I, with whom I am transacting and so on and so forth. So, one natural question could be, okay, an easy way the what what's the dumbest way to protect the information let's use ciphertext. Okay, we can just encrypt it in the information using some public, some public encryption scheme, some public, I don't know, I don't know exactly why, but the point is that, okay, if we now have simply ciphertext on the ledger and now I'm referring to the middle representation to the picture in the middle of the slides, how can I make sure, how can I infer that this transaction that is made of ciphertext is a valid transaction, what does it mean that a transaction is valid, but at least it should guarantee that we are not, this transaction doesn't create money out of the blue and only the rightful owner is spending that money, right, these are the two invariance, fundamental foundational invariance for any payment payment system so a ciphertext itself cannot guarantee anything because it doesn't deliver this belief that the content inside the ciphertext is correctly formed, it's legitimate, so what do we need, what's the tool that we need to handle to deliver this belief that the transaction, despite the fact that the transaction doesn't reveal the actual content, it at least deliver the fact that it's a valid transaction. So the tooling cryptography problem, most of you probably have heard about it, is zero knowledge proof. Now zero knowledge proof is a complex beast, even though it's been already deployed, Zcash is probably one of the most famous examples of large scale deployment of zero knowledge, but it's a complex beast so you don't want to deal directly with zero knowledge but you would like to have a framework that does the heavy lifting, a heavy lifting for you. Is this enough? Not yet, right, because we have achieved our goal of having full privacy with the ability to prove that everything is fine so that the transaction is valid but still we are not achieving, we are not giving, we are not giving any possibility to audit this transaction to a legitimate party in the system so the picture that you might desire for a central bank digital currency is the one on the right hand side where for certain entities in the system, under specific condition, the ledger becomes, the ledger can be deoffered. So for them, certain transactions become, they become clear and they can learn what's going on in this transaction. So the third model essentially is, it puts together the three elements, privacy, compliance and regulation, regulation as well. All right, it's not easy to achieve all these things but we managed to open source a version of our framework that gives you the picture on the right hand side so you can already play with that and then we will show, we will give details about that. What's this framework that we put out, we open source that we use also for deploying this not only central bank digital currency application but any application that it manages token. It's the token, what we call the token, the token SDK, sometimes also fabric token SDK, I don't want to stress too much fabric in this context and on these slides because the token SDK can play with, in principle can play with other back ends and it did as an example, we provide as a back end fabric but also Orion. Orion is another Hyperledger Labs project, I invite you to have a look at it, it's essentially a database with an answered blockchain, with some blockchain flavor in it. Again, we don't know what will be the implementation of the central bank digital currency, maybe some central banks will decide for fabric, others for Bezu, others for Corda, you name it. There are many very interesting technologies available out there, others might even go for a fully centralized system. Anyway, as far as the token SDK is concerned, the token SDK doesn't bind you to a specific back end, it supports the UTXO model for a specific reason. All this we have done to support this decentralized enterprise privacy and the best privacy you can achieve is in the UTXO model. Unfortunately, in the account-based model, it's very hard to achieve privacy and you only get limited privacy, so you get privacy with respect to a subset of the total amount, the total number of accounts in the system. Unfortunately, it's not the highest level of privacy, so you might still have leakage about who might have done a certain set of transactions on the ledger. It's for us at least the reason why we went for the UTXO model, it's also very flexible itself, we can implement fungible and known fungible tokens. Another thing that I like a lot about the token SDK is that essentially it lets you decide after you develop your application which kind of privacy you want for your system. Do you need privacy at all? Do you want a privacy that is based on zero knowledge? Do you want a privacy that is based on trusted execution environment? Who knows how or the latest and greatest version of zero knowledge? The token SDK is flexible enough to adjust itself and to hide the most of the complexity that comes when you handle these complex cryptographic objects. Sometimes I like to say also that with the token SDK you write once your application and then you decide later what kind of privacy you want, what should be the back end you want to run the token SDK against and so on and so forth. Of course we support audit capabilities. I believe that Arne will give an example of that. As I was saying before, we have also integration for HTRC tokens also for asset transfer. An asset is destroyed in a network and reappears in another network and for this we use a hyperledger weaver that now went to form a hyperledger cacti, very interesting project and we have used the token SDK already in many applications. So this is very, it's just a pictorial representation of the type of networks that you might handle with this kind of stack. So you will have your application nodes that are essentially forming your, an application node may be executed by a commercial bank or by a payment service. And this guy will will be able to talk to each other to perform to perform transactions and at the same time they are also able to communicate with multiple networks at the same, at the same time. So we are also delivering a cross cross chain transaction or simply transaction on a single on a single network. Let me give you just a very, very quick understanding of the life cycle or token transaction inside the token, the token SDK. On the left hand side, a bunch of people, they are, they want to perform a transaction, you need the, you might need at least, you might need one, at least one person that wants to transfer some money but you can have also a group of people that together they want to perform atomically as a certain set of transaction. So what they do is people, they come together, they all run the token SDK on their phone or they might use the, they might use a helper of an intermediary, it doesn't matter. They come together, they assemble what we call a token request, which is a way to say that they decide the list of operations that they want to perform. They collect the signatures that are required. Remember, it's important that the right, only the rightful owners can transfer certain tokens, who is the rightful owner, who is, who can produce a valid signature under the public key that is, is actually owning the, owning the token. So they collect all the transaction, they go to an auditor, they refer to an auditor if this is the, the, the will, if a requirement, if this is a requirement in the system, and then at some point they, they, they send this token request to a chain code in fabric. The chain code will do the following. It will validate the token request, and then it will convert it to a read write set. This is just plain fabric, there's nothing special. Now, what I want to stress is that if we are using zero knowledge to protect the privacy of this, of this group of parties there on the, on the left hand side. The token, the token chain code will receive only zero knowledge proofs, and you will not learn anything about the transaction, apart from the fact that says that if the transaction is valid or not, if these operations are valid or not, but nothing else, nothing else, the chain code will not learn anything else. Then we have the, the usual endorsement phase, the, the, the cycle, the, the chain, the, the endorses of the chain code goes back with the endorsement. The fabric transaction then at this point can be assembled, can be assembled and submit for, for ordering. It can go, it can be stored, can be validated after to be finalized on the ledger. Now, I do understand that all this seems seems quite complex in terms of a flow. Oh my gosh, there are so many steps. How do I handle this? How do we handle all the zero knowledge proof? My hope, my belief is that after our presentation, we will say that you will not see anything of this, you will not, you, you don't have to handle any of this complexity of invoking the chain code or generating the zero knowledge proof validating here and there. You just care about your business logic. Now, with this, this was my last, my last slide. I will switch now. If you have questions, maybe we can take a break, a short break, or just for questions here maybe. Sean, David, you know what you think and then we can leave the, I can leave the stage to, to Arne. I think I can just continue from here. Yeah. All right, so then let me stop my sharing and then I will come back with some takeaway. Arne, please. All right, thanks. I'm Arne Rutjes. I work at IBM and I've been working with hyper ledger fabric for about eight years now, which is when it became public. And then the last one and a half years also working a lot with the token SDK. And it's an amazing piece of technology. You heard from Angela already how, how flexible it is and what you can do with it. But there was one thing missing, I think, if you look at the token SDK repo which is open source. It doesn't give you an application right away. It took me quite a bit of effort the first time to actually get it to work, which is why I decided to create this sample application that I will share right now with you. And you should be able to see my screen now. Yeah, so indeed it all sounded quite complex. And it is because the token SDK is doing a lot of the heavy lifting. But I have something here that can get you started very easily. This is a new project inside of the fabric samples repo. So you can just clone it there and you can get going. Just sharing the basic features of this sample application. And then we're going to dive deep into what the token SDK actually can do and how it all works under the covers. I'm doing this full screen by the way. So if you have questions, Marcus maybe you can, you can highlight them whenever the moment is right. Then I can answer them when they are there. So we have three roles in this basic network. We have the issuer, which is an institution who can create tokens. So in the case of a central bank or CBDC this would be a central bank. We have the role of an owner, who is someone who can own tokens transfer them redeem them redeem is just to burn them basically. And we have the role of the auditor, which Angela already mentioned shortly. For compliance, sometimes it's necessary that there is an organization or part of an organization that gets to see transactions and can also enforce certain rules on it. The token SDK doesn't force you to have an auditor. It's just something that comes up a lot in practice. And it can be really useful. I'll show you later how it works. All right, just to get to some basic use. Let me see if I can get rid of this. Yes. All right. So to start, we're going to issue some tokens. Let's call them HLF. Let's say 10,000. And we're going to send them to Alice. Alice is on a note called owner one. I'll get back to that concept later, but you could just see it as her bank or intermediary that is holding her keys for her. So I'm going to execute that transaction now. And this is being executed. And then we'll see that we have issued 10,000 HLF to Alice. If I then look at the overview of Alice, then I can see that she actually owns it. Right. Simple basic stuff. Next she might actually want to do something with it. Maybe she wants to transfer some of these tokens that she just got to Dan. Let's say 100 to Dan, who is actually at owner two. And maybe she wants to send the message. And already this is something to keep in mind. You can see here that this is an integer. So there is no fractionalization. The token SDK takes 64-bit integer as the value of your token, which means that if you're doing, let's say if you're doing a CBDC, then this would be cents. This would be one euro or 100 cents. Something to keep in mind. All right. So now we transferred 100 to Dan. And you'll see that if we look at the transactions, the transaction history of Dan, we'll see that he received the transaction with 100 HLF and the message that Alice sent him. All right. All good. Now, you don't have to answer this out loud, but how many transactions which you think you would see now for Alice. So we have the issuance and then we have to transfer. Well, the answer is actually three. And the reason for that is the UTXO model. The transaction deals with a token and a token has a certain value. So at the initial issuance, Alice got one token with the value of 10,000. But then when she wanted to send that to Dan, she actually had to consume that token to spend it and create two new tokens. And one of them is going to Dan with the 100 that she actually said. But you can see here with the same transaction ID, we have another output that is actually her change that goes back to Alice. This is just how UTXO works. And if you build an application on this, it might look confusing to your users. So you might want to filter this out or something, but I thought it was good to just show it as close to how the token SDK is doing this as possible. Right. So that's what it can do. And we also have the auditor, as mentioned, they get a view on all the transactions, not mandatory for token SDK, but could be useful for compliance. And they get the same kind of, this is just an example, same kind of overview, so LSS zero, your X, but she probably has some HLF here. Well, that's it, super simple. If you're now underwhelmed, if you think this is just doesn't look so complicated, then I've done my job. Then I'm really happy actually because there's a lot going on in the back end here. And that's what I'm going to show right now. Are there any questions for now, Marcus, as I should take or should I continue. I just need one question. So, Zack, Zack she asking another shit. Is there any or M kind of system integrated with the application. So I guess or M is object relational mapping. Right. Well, so there is a rest API, as you can see, this is the definition of the rest API. The token SDK stores things as well. There's a local database for the UTXO transactions and well also all the proofs related to that. But I'm not sure what you mean exactly with an arm system integrated with this. It's a simple rest API so you could integrate it with anything you like you could build a front end on it or there's all kinds of tooling where you can even generate things automatically based on this definition. So, yeah, except you want to use it. All right, so let's let's take a look at what's actually running here. This is, it's all running in Docker. This is just a simple, this page is a simple front end but actually there's four different instances of the application running. So the auditor is a separate application the issuer, and there's two instances of the owner application. So basically the stuff on top here. And then here on the bottom we have a simple hyper ledger fabric network, and also running the token chain codes. And in a diagram that looks a little bit like this. So I'm just already showed you. You have kind of a network of applications running the token SDK who can talk to each other to create transactions. They all have a fabric user as well to be able to eventually submit the transactions to the fabric network, which will execute the token chain code for validation, and then commit the transaction by branch by which moments it would be final. I'm going to show you how a transaction actually works as well. But before I do that, you can run this yourself. Just to run this you don't need a lot of experience with Golang or whatever. You do need to have Golang installed. So there are a few prerequisites. You can find this by just get cloning the fabric samples repo and the link will be will be shared as well. You need Docker, Docker compose Golang gets nothing special. After you've done this, you should download the fabric script again and install the Docker images and the binaries. Excuse me. And the reason for that is that we're using the fabric CA 1.5.7. So if you haven't done that in the past month or so, you'll need to get a new version. And that's because we're using the ID mix identities that the fabric CA can can offer. Actually, if you look at this screen, there's a CA running or it doesn't have to be running, but there's a CA CA responsible for the accounts on these notes. And the CA is not in any way related to the fabric. PKI. It's just that we use the fabric CA because it has all the ID mix users available. So the CA is basically only responsible for the token network. Honor. There are questions related to this rest API. The questions are essentially is this rest API provided or supported by the token SDK itself or is this more on the application layer. Yeah, this is the application layer. The token SDK itself is responsible for the communication between the different nodes. And also all the logic needed to do all the clever stuff with the tokens and the zero knowledge proofs and the fabric transactions. So it's doing a lot of heavy lifting, but this rest API is just an application layer wrapper around it that you can now find in the fabric samples repo. And you can of course, you can create your own API so you can create your own application. This is just a kind of a sample or a starter. If you would like to create a prototype or create a demo or just if you want to learn more of how the token SDK could behave in a real setting. Okay, so after you've downloaded the Docker images and the binaries from fabric, you have to make sure that these binaries are also accessible in your, in your path. And you can check that by running fabric see a client version, and that should be 1.5 point seven. That's it. Oh yeah, there's one more thing. There's a tool called token gen, which is actually part of the fabric token SDK as you can see. And that generates the configuration for the token chain codes. And that includes being able to verify signatures of the issuer and the auditor. So it's including those public certificates in there, and all the cryptographic parameters that are needed for the zero notice groups that organizations are going to create. So for now you just have to know that you have to install the tool. And if you've done all that you just run this one script, and you're good to go, then you're at the same point what I just showed you. And to make it a bit more clear what's going on. I'm actually going to tear it down right now, and show it step by step, building it up. Because there's a few steps going on here. It's not too complicated. But if you if you run it like that, then you'll see the different layers better as well. So we're going to start with creating the identities, and there's quite a few identities going on. If you've worked with fabric you're probably used to all the certificate management and the keys. This is no different. Each node. So the issuer and the owners and the auditor has its own identity. They used to communicate securely with each other. And all the users, obviously the accounts also have their own. Their own ID mix identity. All right, so now I'm going to just run a script. Nothing special here this is just using the fabric. I see a client to register all these users. So you can see, for instance, Dan as a user will get his own ID mix credentials. And then up here we might have FSC owner to this is the name of the owner to note that also has its own identity. There is also the auditor, for instance, we have, yeah, here the issuer. The issuer has a public identity. So for them, we're actually using a normal public key and certs, because we're supposed to know who is responsible for creating all these tokens. Right. Now we could bring the CA. We don't really need it. But I'm just going to keep it running. Now we're going to create this token gen output. And this is actually creating a file in the token chain codes folder. And that's going to be baked in there so that the token chain codes can do all the validations that it needs to do. Okay, those were all the identities. And now, for those of you familiar with the fabric sample network. This is nothing special either. We're just starting a basic network with a channel called my channel. And we're going to use that to deploy the chain codes. And that is this second step. I tried to stay as close to the sample network as possible. Of course, you can easily just deploy the token chain codes to any other network and configure your services to use identities on there. So this is going to take a bit just to be approved. And this is done. I'm going to copy all the keys of the organizations and the fabric users of the sample network to a local folder here. So this will be here in the keys folder. And these are just the pair organizations. Yeah, again, nothing really special here. But this is the way we can connect to the network. Okay, well, this is already removed. So now we have a fabric network running. We have identities for all of our FSC nodes and our token users. And then all we have to do is just do a Docker Compose app and we're good to go. And Docker Compose app creates one instance for each of the roles and the swagger UI, which will then also be accessible in your browser. Now, if you're ready, let's look at what actually happens during a transaction. We still have this open and I'm going to open a few consoles here just to track the logs. The auditor, the issuer, and both of the owners. So it's not really about the details here, but I'm just, I just want to show that there's actually a lot going on in this simple transaction that's happening. So, yeah, let's just do the same thing issuing 10,000 HLF to Alice. Right, did you see that issuer moved? Then the auditor got to do something. And we saw something happening at the owner as well. So all these services, all these nodes are actually talking to each other to make this happen. And I'm going to show in detail what that actually is that's happening. But for now it's just good to know that when the issuer issues is going to ask for an identity and well, we'll see, I'm going to show you. And then let's do a transfer because that's the example. So now we expect to see something happening in owner two as well, which I have here on the right. And it's coming from owner one. So let's see. And final. So it's all committed on all the sides. Now, what's actually going on here. This is all in the README so you can easily run this at home and try it yourself. So we transferred 100 HLF in this case to Dan on owner two. And what's happening here, this is the transfer view and all of these views actually correspond to codes as well. So if you're doing this at home, just take a look at where this is all going on. We have the owner. So in the service directory here, there's a transfer.go which contains the transfer view. We're going to look at this. And when this gets cold gets cold, we're going to get the wallet and lesser wallets. We're going to look for the identity of the auditor. I'll show you with the diagram that's easier. So the transfer view. We also have to accept cash view. So to be able to accept cash, we actually need to share this identity. So this is one way of making sure we have privacy. Instead of using Dan's longtime use identity to own tokens, Dan, or rather, the owner to intermediary is going to create a one-time use key for him that is going to own this token. We're going to create a secret, just a random string for the zero knowledge proof commitments that Alice is going to make. And by knowing the secrets, both of them, they can actually, well, Dan will be able to see what Alice is doing. So Dan shares this one-time use key and the secrets with Alice. And then Alice creates her transaction. Remember that she needs an input. So in this case, she'll use the just issued 10,000 HLF. She'll select that one and then create the outputs for it. She'll assign the ownership of the output to Dan's new key. And one of the outputs actually is the change that goes back to a new key that she creates for herself. She generates all the proofs. There's proof magic going on there. And she signs it and shares it back to Dan. Dan can verify, did she actually send the amount that she promised? Did she actually send something to me? Is it actually to this key that I just shared to her? And if that's all good, he stores a pending incoming transaction in his database. And then sends a signed response back to Alice. Now Alice is ready to get the endorsement from the auditor. So this is where we could enforce business rules. For instance, we could have a transaction limit. Maybe Alice is not allowed to send more than 100 HLF. Maybe Dan is not allowed to hold more than a thousand HLF. This could be a place to validate that. Because the auditor, Alice also shares the secret with the auditor. So the auditor is actually able to unpack these commitments and validate based on the actual contents of the transaction. If the auditor is happy, they send back a signed response. And then we're back to fabric. So on the right we have the fabric pairs and orders. This is when Alice just wraps the whole token transaction into a hyperledger fabric transaction and submits it to the token chain codes. And the token chain codes validates it. Now, you might remember what Angela said about privacy. The token chain codes does not really get to see all that stuff that the auditor saw or that Dan and Alice saw. The auditor sees one-time use identities owning a certain amount. It doesn't even know how much. It just validates is this token spent before and are the outputs valid and are all the signatures there. So you have full privacy as a user as an organization versus the settlement layer. I think that's pretty cool. So after the pair endorsed it, we can actually submit it to the auditor, auditor creates a block and broadcast it to everyone. Well, to the pairs and every token SDK instance, every service will actually have been listening for this and update their local representation of the transaction to confirmed. And we're done. Dan now owns the token that Alice has sent him. And he can do with it what he wants. Any questions, Marcus? Well, I'm the law and we are trying to answer them on the fly. Oh, great. Just feel free to interrupt me if there's anything you want me to answer. Okay, one more thing. I want to show what's actually going on on the ledger. And for that, I included the blockchain explorer, which just released their version two. There's a bit of configuration here. But because we're using the fabric samples network, it's actually really close to the original. And if I remember correctly, I can just, yeah, I can just do Docker compose up on this from this folder. So if you don't know the explorer, this gives you a view on what's actually going on on the ledger. And I thought it might be a good idea to to show what's going on on the ledger. And to prove that there's not a lot that settlement layer can actually see this is the standard username and password. All right, so we have a few transactions that just happened here, and actually might be good to also show the ID. So let's say the last two transactions were E 47 and zero E zero. If we look at the API here, the transfer was zero E zero. So the transaction ID you see here is also the fabric transaction ID. And that was the transfer round and the issuance if it's still open, yeah, that would be the E 47. Okay, so let's look at the transfer and what actually happens here. So there are a few rights going on. And I think those are the most interesting. So this is the token chain codes, which is writing a few things. There is a new token created here. And as you can see the idea of the token is actually as a transaction ID with an index number. Very simple. So this, this is a UTXO. This is what it looks like. There's another one that we creating. So one of these is the change that is going back to Alice. But we don't know which because it's all zero knowledge. And then this is the input token. So as you can see, this has the same ID as the issuance that we did earlier. And this token is now deleted. It's spent. So this is how the lifecycle of the token basically goes. And then we have a big one here. And this is called the token request. And this basically describes all the actions that Alice performed. And that looks a little bit like this. Let me check. If I copy it well, then what if I store it as a JSON? There we go. All right. So this is what a token request actually contains. So again, we have here the input token. We have the commitments that basically prove that Alice is allowed to do something with this token. And then we have the outputs where we have two new tokens which also just showed on the ledger. And then there's a whole part for the proof here. So that is kind of how it all works. So we've seen now the different components that are running, how they communicate, what actually happens during a transfer. And what the token looks like and what's actually written to the ledger. Now, if you want to use this yourself, either you just run it like I just did. But I really hope some of you are also now inspired to actually build something on top of this. Either build your own application or you can change it. You can add APIs. You can take a look at the code. It's actually fairly simply structured. So you can also add your own features. For instance, the token SDK repo has an example for HDLC hash timelock contracts, which you could use to transact in between blockchains. So it could be a nice project to add that to this sample as well. And of course we also welcome pull requests if you decide to do something like that. I'm going to give one more example of what you could do for code and then we can wrap up. So let's say we are in a situation where we want that only tokens of type talk are allowed to be issued and used on this network. Now, where would you actually put a control like this? We have many places where we're doing validations and stuff. You could think maybe we want the issuer, we just block the API or do something like that. That's a bit of a naive approach. Maybe you want the owner. Maybe in the accept view, maybe you want to put some code there that says I don't accept anything else than talk. Well, you can. In the accept view, you get access to the transaction. This is what happens when someone sends a transaction to you. So first you respond with identity, but later you actually get to store the transaction. So we're doing a few checks here already. There should be some outputs and there should be some output actually going to us. So you could easily just add something here as well to say I don't accept anything smaller than one, smaller than 100 or I don't accept whatever. It's up to you. It depends on your business logic. But I think, so yeah, you might think maybe we do it in the token chain codes. Well, then we have a problem because the token chain codes doesn't actually know so much. It only validates signatures basically. So then a logical place to do this would actually be the auditor. If the auditor doesn't approve a transaction, it doesn't happen. It doesn't get approved by the chain code either. So let's let's do that. I'm going to do a document post down and show you how you would do that. So here in the surface we have the audit view and this is where all the logic is. Okay, a lot of it is abstracted away because it's actually taken care of by the token SDK itself. But this is also where you would add business logic. So there's a link here and I really encourage you if you really want to dive deep into this that you also go to the fabric token SDK repo. Because there's a lot of documentation there and also example codes. So this one is a sample from the fabric token SDK for the auditor. And they have some interesting examples here like payment limit. You may not send anything more than 200 cumulative payment limits. Many things you could actually try out. But for now, we actually only want to check is this the right type. There's something here, currently, where we have token types. So we might actually be able to use this. So let's get the outputs. So the auditor is basically reading the transaction here. What is there is reading the transaction. We don't need inputs here. If there's an error, we actually want to whatever. And now we want to use these outputs. And here we can take a look at. You can do many things you can look at the sum you can look at anything you want you can inspect them here because the auditor actually gets clear text access. So let's say we expect only one type. It's the magic. If I put that type zero, because there's only one. If it's not talk. We're going to fail this transaction. Something like this. It's just a simple example that at least you you get the you get the idea them. So I'm going to build that. So if you want a quicker way of developing the read me also specifies how you could. How you could run this natively so you just do go build and then you can go much quicker. You can also attach a debugger or whatever you want. So this Docker comparison is just simple to get started in the beginning. Oh, there's a mistake here. No, yeah. Yeah, many mistakes, but length should not should be one. Well, what we should see now the other viewers invoked whenever someone issues or when when a transfer happens. So this, this is probably a good enforcement point. Let's see if we can try that. If we can transfer some as you left now. No, we can't because field auditing. Well, it's a bit behind the thing here but you can see that it says only talk allowed. And then hopefully if I issue some talk. It will actually succeed taking its time. Okay. I don't know what's going on here, but you got the idea. Okay. Well, I issued some talk to them at least. So talk to them. Can I send something to Alice? I'm going to look into that anyway. Oh, there we go. With all this, hopefully, you now have a good idea of how the token SDK can actually work in a sample. And I really hope that some of you will now go and get clone the fabric samples and experiment with it yourself. Because, yeah, as you saw, actually starting it is pretty simple. You just clone it, you install the dependencies, and you get to run the application and try out some applications. But there are many rabbit holes to dive into and many things you could actually build on top of this. So, yeah, I hope you liked it and I hope you start to use it. And I really hope that eventually some of you will even look at the token SDK repo and contribute to it. Do you have any final words? Maybe I can share the last slide just a summary and take away from the entire discussion. And then I don't know if maybe we can open the floor to live questions. So a few takeaways and then we'll open to questions. So the token SDK was our effort. Mostly for us, first and foremost for us to deploy quickly token-based applications on fabric. At least at the beginning was the goal with this ability to, this flexibility in choosing the kind of privacy guarantees we needed. And it quickly evolved into something more complex that even it's agnostic to can work against other backends. It adopts the UTXO model because the UTXO model seems the one that it's best suited to achieve very strong privacy guarantees, but also high throughput, right? Because when I'm spending the only reason why you might have a conflict generated by two transactions is because they are trying to spend the same output, which anyway is something that you want to avoid. So you expect a conflict to appear. Otherwise transaction can be committed in parallel. It uses a very simple token definitions for two reasons. Simplicity, it's always a good design principle. And it's also because applying zero knowledge to more complex definition can be very challenging and leakage of information can become unmanageable. So that's, but so far what we've seen this very simple definition with the simple operation of issuing transfer redeem, it's enough for most of the applications that at least we faced. We are really looking forward for your feedback for the application you might want to develop with the token SDK and see how we can extend the framework. As you have seen in the code, the code doesn't really speak any fabric language. You don't see there any reference to chain code or any other fabric concept proposed us and stuff like that. You also don't see zero knowledge right there. You just see a high level, something that is close to the business logic, because the token SDK does the rest of the heavy lifting. And we wanted to be like that because these critical objects are very complex to manage if you don't do properly, then you might easily have security breaches or leakage of information. So that's the best way to encapsulate this logic so that it's easy in case of bugs to find them and fix quickly. Again, the token SDK is there. I forgot to add the link to the labs. Sorry for that, but I think in the chat there are these links as well. Please reach us on Discord if you want to know how to participate and how to contribute to the token SDK or if you want to learn more in general about this technology. And with that, thank you all really. And yes, we can have questions. I don't know how do we, how does it work this Sean David. So, Angela, we can if folks still have questions they can ask them in the chat. We've also posted the link to the discord a couple of times everyone's welcome to go there as well. And the this entire session is being live streamed on YouTube. It will also end up on the hyper ledger YouTube channel, along with all these links I'm going to make sure the links from this session are in the YouTube page as well as on the wiki. And someone asked about the presentations. So from our presenters if we can get a PDF of those slides I'll make sure they're on the wiki page for the workshop as well. But thank you to the preview this has been a fantastic workshop if folks have questions please ask them in chat. So let us know if you if you are interested in another session where you are where we can show the interoperability aspects of the token SDK what does it mean to perform asset transfers after asset exchange and so on and so forth. This can be another session for you, if you are interested in that. Any chance we can get to do another workshop with you Angela we're going to take so that that that's a let me go get the calendar. But for the folks who are attending please if you have questions please place in the chat. There's one question in the shed does this application use offline transaction signing offline transaction signing what what do you mean with that. That someone that you take the transaction you go into a dark room where you are fully disconnected the you produce the sign the signature and you come back. Is this a yes for this is a yes. Well, I believe in this sample we showed today we don't demonstrate any offline signing capabilities so all the interactions we saw using this regular API were basically then directly invoke on on the fabric samples test network. For the example where for example suppose that there is a commercial bank, Alice has an account to in a commercial bank that is managing the tokens for Alice. But you might still want that Alice produces the signature yes you can do that. We are extending the two even the public version of the token SDK to support to support that but this was not in the in the example so maybe this can be an additional argument and additional subject for another presentation we show how we can do that here. So for the, can I use the token SDK to develop a single CDBC application. Yeah, that's I guess that that was the purpose of the presentation today, of course, a CDBC, a CDBC implementation CDBC solution. This is a very complex beast because the requirements are very heavy in terms of privacy availability scalability and so on and so forth so this is just an example that we have given you then you need a first you need to optimize to throw the full stack to get a real solution. So Maria is asking, could the sample with the ETH token also be used. So, this example is really using UTXO and the token SDK for that. But that's again where the interoperability comes into play. So, I'm actually working on a demo where you could do a transaction an HDLC transaction with an Ethereum network as well. And lots of the projects that IBM is doing with central banks or commercial banks or other institutions actually have that feature of interoperability as well. Then it gets really interesting of course. So, Jim, I don't know what you mean with the API level interoperability, we have an API, the token SDK has API that will hide the fact that there is cacti behind as a framework for the actual interoperability because again it's token driven. I don't know if you know what you meant. So we usually try to hide the lower level API. They are not cacti, you will not use directly cacti, you will not see cacti, you will have an API that speaks about the fact that you are preparing an asset transfer or an asset exchange exchange across networks. In offline, as I just said, there was one before in the future we want to expose, we're doing this now. No offline transaction sign in user key instead you will not only be using machine, nobody else will have user keys, yeah, that makes sense. What are the challenges for your point of view for fabric to be used by the ECB context or the CDBC use case, even this is quite a good question. And certainly the vanilla fabric as it is, someone said it has very low throughput. So we, I said this also in another presentation where a little bit delaying the publishing of the paper, but we are aiming in terms of throughput to go over hundreds of thousands of transactions per second to be final. That's our target. So to be well beyond, well above 25k limits, but for now these are just words so please stay tuned and we have to publish all this. That's a lot of, we have a lot of goodies. Please give us time to, we need time to release this step by step. Also the code, the code will be released so step by step things will happen. Using token, that's the point. Actually, it's not the problem itself of the fabric, the token SDK remember that the fabric allows you to execute transaction in parallel right so that it's not much the problem of the token SDK if you have enough computational resources so you can generate many transactions in parallel. The point is that the committer, the committer that is the bottleneck currently in, in fabric so we heavily work on that pipeline to make it fast as possible remember and that's the reason why we don't support account. The problem of account is that if Bob and Charlie are transferring to Alice. This true transaction must be, must be processed sequentially. They cannot go in parallel. But for UTXO these two transactions can be committed in parallel because it doesn't matter that we are transferring to the same, to the same owner because these two transactions are creating new outputs, owned by Alice. This should give you already a hint why UTXO is also the best frame the best, the best infrastructure to get to get very high throughput because you naturally don't have conflict, unless you are double spending, which in that case you want to catch the conflict, you want to catch double spending and therefore you want to see the conflict. That's, that's, that's the thing. Can this token as they work with fry fly easily. Don't know actually the honestly. What's the, I know that the firefly has its own token definition it will be interesting to see a kind of being the token SDK the provider of tokens also for firefly why not. Hardware configuration. Sorry, I might skip questions guys jumping from where I'm skipping what hardware configuration is needed for achieving a high throughput. This depends very much on which part of the system we're talking about. So there are parts that are more disk intensive other that are more CPU intensive and so on and so forth depends where we what we are that which is also good right because you know, the ordering service might require that it's very disk intensive and memory intensive, and also a connectivity, you need a high through IO channel. That's, that's for sure, verifying the zero to the committee, the endorsement they need to verify zero knowledge proofs. So they are very CPU and memory intensive. So you need to deploy accordingly to what you need. So far flies more general general purpose framework to the best of the best of my knowledge token SDK it's really about tokens and nothing else and tokens with privacy so we care a lot about privacy compliance interoperability. This is our focus so we don't want to address all the possible applications. We just want this application, the applications about around CDBC, I will say, CDBC is our main focus, but also other token application that's that's fine the rest. That's not us. Yeah, I think we can start back and we customize the issue and multiple owner. Yeah the issues you can have multiple, multiple, multiple issues. I think any access policy can be put on top of the system. The only question becomes, do you need to embed additional access policy inside the zero knowledge proof. In that case you have to touch a part of the token SDK that is called token driver, that is the one that is the part of the token SDK that is handling the complexity of the cryptographic scheme. We are usually think about it as the links, the kernel modules, the token driver are like kernel modules so very delicate objects you really need to know what what what you have. But then you have on top of it you have links. It's a good use of a registration app for users or so they're back supported not the needs were probably Jim that I'm not sure if we have any good use of old registration app for users honestly. I'm not aware we should ask Dave, Dave and your for that. For coaching. I am ready to go and which one you suggest with the set of the performance just script might be a bit more challenging. It depends. So, if we have to execute cryptographic primitives. And now they seem thrust to be a good, good language. There are go is also a very performant module of the garbage collector at certain times can give some some can be a little trouble song. Yes. Any other questions, Marcus any other question or any questions that you've seen. We don't, we don't support account. We don't support account, the account based on model for the obvious for the reasons for the reasons that I said it's, you, it's very you don't have you don't obtain a perfect privacy with account based on model but only privacy with the set of the subset of with respect to a subset of the total number of the accounts, you get privacy so that's a more limited limited privacy so that's that's it for before you take so we don't need the we achieve full privacy with zero knowledge. We don't use any private other collection for fabric we just use the basic basic fire the basic ledger. Nothing, no, no special, special. There was a question by Maria, asking about the basically the difference between the token SDK. And the fabric samples token you see 20 sample. So maybe we can hide that a little bit. Okay, so the two main questions. Maria, sorry, two main, two main points. One is throughput, certainly remember in in the if you're using account model Bob and Charlie and transferring to Alice. These two transaction needs to be handled sequentially they cannot be processed in parallel because there is only, sorry. In one account, it needs to be updated the according to the transaction, but this is not the case for for you to XO and the second and very crucial aspect is privacy. So we know how to achieve the best possible privacy in the context of you to XO we don't know how to do that with the account based actually the best you can achieve in terms of privacy for the account is, as I said this privacy with the only a subset of the total number of account, the privacy that you like to have is to have privacy with the respect to the entire set of accounts. But if you want to do that, then the proof the system becomes very expensive. So you need a lot of time to generate this, this, this zero. This is called anonymity anonymity set what's your anonymity set. It's the entire set the entire universe of accounts. It's a subset of accounts. What was that. So for the presenters. Someone asked me a question I think accidentally instead of everyone. What is the chance that the same token will be issued to more than one owner issuer. If they both request for tokens concurrently is there a lock implemented. No, it doesn't this is the transaction can go in parallel right because I talk and maybe this I should have said the more explicit to be a full definition. At all, but this is in the other presentation, a token in the token SDK has is a triplet with three fields. The type of the token, the owner of the token can be the owner can be a sorry, the type can be any string can be the definition of the token but even adjacent structure. The owner of the token can be a simple public key or a script something more complex and then there's the quantity which is the amount of value that is in this in this token so the issuer will just create two tokens possibly into different transaction but even in the same transaction this can be done. Each of these token will have a different different public key, for example, and therefore this can go in parallel that they can be committed that even atomically in the same transaction there's no risk of conflicts here. Okay. So, even for a RC 20 do you care about privacy Maria because if you care about privacy, immediately they are the RC token becomes problematic. Because how do you achieve privacy in that context right that's probably it's one of the main differentiator because for for no fungible tokens. Maybe you don't need the hundreds of thousands of transactions per second right you you are happy with much maybe you we are we can be happy with much less in terms of throughput. But the question becomes do you need privacy as soon as you need privacy, the RC 20 and company becomes a bottleneck at that point become they are more problematic, unless you go to a mechanism like the one implemented by by start where you have the second layer. But again, the machine is much more, much more complex and it depends at that point depends which kind of throughput you want and it's always a trade off right that's that's the reason why for the token SDK we are really focusing our main application is centered by digital currency. Because that's the most challenging and the most interesting for us. Angela Jim ask, if we can change, change the token definition to support controller in addition to the old. Yeah, beautiful, beautiful question. I'm sorry, Marcus, maybe you want to answer it. No, yeah. Absolutely. We can do that already because for interoperability, we support a script. So what will be the support for a controller. The script that says that either the legitimate owner can transfer this token or a controller under a certain condition. For example, so it's all about scripting now, the default token SDK, we only support hard coded scripts. Again, for the following is we don't we didn't go with the support of a Turing machine or a Turing machine complete virtual machine or a Bitcoin Bitcoin machine because we want to keep things simple. If there is a use case that requires more complex. More complexity. We still believe that it's better to do a doc script because then you need also to make sure that these scripts are well well understood. It's clear what they are doing and so on and so forth. But in principle, maybe this is a it's an exercise for you guys for the listener of this talk. Extend the token SDK to support the Bitcoin virtual machine in the owner in the owner field. It's doable. So that can be an exercise for you. So it is it that challenge to keep track of what you do with an increasing distribution to do in smaller smaller chunk in big use cases as it needs to be searchable milliseconds. I wouldn't be too worried about that honestly because there are very efficient database there is an issue with privacy that you have this growing list of serial numbers this what this happens also in zero cash. And for that we need special tricks to manage this to handle this ever growing a list of tokens but for the other questions I think that's not that's not that's not a problem. P you have a C 20 type okay for payment but the asset site is an owner account. Yes, we're training. It's actually for DB a topic trust. Yeah, it's doable. I think the other session and if we do the session of interoperability then I think you will answer more questions about about that. Yeah. All right. Anything else. I want to note about a future session interoperability. In the token. I'm sorry, grab just asking the token implementation do you have an extra mechanism. And it's HTC. So we support, which we support the HTC script. So that can be can be an employee can can be understood as an escrow count by many means. Awesome. Lovely Jim please share, share we will support also your escrow, your escrow system that something better they we know so the HTC is also the basic HTC protocol doesn't support any privacy so if you want to have an interoperable won't have an atomic across chain transaction with privacy, then HTC alone will leak information about the transaction so you need the better mechanisms there for sure. David West asks, what other chains is hyper ledger most similar to an influence by a David that's a product hyper ledger is just an it's the name of the umbrella project right it's this green house. Then there is hyper ledger fabric hyper ledger basal and and so on and so forth so maybe if you can be more specific. It was too limited for complexity. Very good. Is this production ready for for CTBC so the token SDK as we as we we offered in the in this public version. It's on your risk to use that's usually we don't that's I will say the best we can offer the we can offer right now. So what are the chains is hyper ledger most similar to and influence it but for fabric I would say that fabric is pretty unique at least at the time when we do with we publish the first paper about fabric. I think was among that one of the probably the first. If not the first among the first networks to use the the the execute order validation paradigm that is different from Ethereum or Bitcoin where they have execution execution and validation. So that probably was the main the main difference that fabric brought in which meant parallel execution of business logic and then very fast verification very fast verification chain. I believe Cardano is also order execute. Okay, and I've added the links that we've been discussing one more time to the to the chat. These links are also going to be in the wiki page we're going to have the video there we're going to have the presentation decks and PDF format there as well. There is a workshop in mid November, specific to cacti, you can find that on the wiki page, as well as please check out the hyper ledger discord. That's where the contemporaneous in real time conversations are happening around these projects. There's an entire section of fabric, and there's hyper ledger labs lower down the channel list because we separate the labs from all the other projects. So you can you can check out the token SDK lab you can check out some of the links that we've discussed here. I think we've time for one more question. Yes, and it is is fabric providing support for enterprise applications. Yes, I guess you need that anyway enough enterprise offering around fabric then for this you have multiple providers, I think there's Oracle IBM of course, and others that are giving you a an enterprise support for fabric directly but yes you can use fabric for enterprise applications. I'm going to share the case studies link thank you so much for that David. I would like to thank once again, Marcus on a and Angelo for putting on such a great presentation today. This is going to be on the wiki it's going to be on the hyper ledger YouTube if you want to watch it again or share it with a share it with a colleague and David Boswell and I are going to start planning an interop workshop, hopefully with these three people again you guys are great. And we'd like to thank everybody for joining us. And I'm going to stop the stream, and we're going to end this workshop so thank you all really appreciate all the amazing questions please join the discord that's where more of these conversations are happening as well as we have fabric calls, and a fabric mailing