 Okay. Hi everyone, welcome to our hyper ledger in depth webinar we're just going to give everybody about a minute or two to file in. So just head on tight. Hi everybody, thank you for joining us today. We're just going to start in about a minute or so. Thank you everyone for joining. I'll get started about a few seconds. Okay. Welcome everybody. We are delighted to present with you our next hyper ledger foundation in depth webinar with IBM talking about tokens and hyper ledger fabric, what is possible and what's coming down the line. We have Angelo, Ellie and actually two additional panelists joining us today with Dave and yards and also counter. So they'll be leading the discussion and the presentation today. I want to start off before we dive in to say that all are welcome here in the hyper ledger community. We're very committed to having a welcoming community and our all our meetings are in accordance with our code of conduct which you can review on our website and on our wiki. We also, at the start of all our meetings in the hyper ledger community, point your attention to our anti trust policy that you can find on our website and on our wiki as well. This session is being recorded so don't worry about missing anything and slides will also be available on the events page or website and the webinar page or website for you to download afterwards as well. We encourage questions so please raise your hand depending on the time or how many people we have joining. I may invite you to come off mute to ask your question. Otherwise, please post them in the Q&A box, or even in the chat I will be monitoring them, and we will address some of the questions throughout but certainly save time at the end as well. Without further ado, I would like to invite Angelo to share screen and for Ellie to kick us off. Gladly so. Thank you very much. So, hi everyone I'm Ellie and I'm going to give an introduction to this fantastic session on tokens for hyper ledger fabric. So, next, next slide please Angelo. First I'll introduce what made us start working on building token extensions for hyper ledger fabric. Then we are going to give an overview of what is possible in hyper ledger fabric today and then discuss the main topic of this session on what's coming and what's already there. So, next slide please. So, most of the people in this seminar are the webinar are a part of IBM blockchain research team, which is essentially a team very much focused on enhancing the state of the art on blockchain system. So, for us, blockchains or transaction processing systems, allowing mutually distrusting participants in a business network to do business, looking at one system of records. And in that sense, distribution of trends transparency automation comes as a very prominent set of value propositions of this technology to business networks. Next, next slide please. And of course it is the same set of value propositions that intrigues from a research point of view. We want to combine this transparency with privacy of the business data in a way that will not violate the scalability and performance promises of the system itself as a way to address real use cases. While at the same time, we won't do not want to have unconditional privacy we wanted to marry it with some level of regulatory compliance enforcement and in particular audit support this becoming quite challenging. When one needs to consider the variation of regulation across different countries, a blockchain system needs to operate. Next slide please. So clearly this this talk our focus is asset exchange and tokens are the representation of digital assets in the blockchain systems of different incarnations of different types of digital assets depending on the industry you're looking for. But the most prominent use of the token asset we are going to present today, the token capabilities are going to present today is in the context of central bank digital currency. Not because they cannot be used elsewhere on the contrary it's pretty generic the capability that we put in place, but it's rather that they have been already been integrated into very mature central bank digital currency experimentation that I will elaborate on in that bit. Next slide please. The central bank digital currency architectures are very typical one is the one separating this into the multiple tiers on the top tier we have the the the wholesale networks were central banks, personal banks, engaging to transactions. There are some among them, and they can be their block DLT based it can be legacy system log centralized system based. And then we have tier two networks retail central bank digital currency systems that are required to interoperate with among each other, but also with a wholesale network. Clearly, as I mentioned before, requirements on the privacy side and regulation enforcement side, as well as interoperation become sits at the very top list. And they're next slide please. And then we have worked with a set of a set of entities from the backing industry central banks as well as big commercial banks into building central bank digital currency systems on the wholesale side. And the way the assets that we produce in that context to move this capabilities beyond the state of the art is a privacy preserving us with exchange mechanism that is in principle ledger agnostic, but is primarily hooked to hyper ledger fabric, allowing for this enhanced privacy definition that I mentioned before, where we do also enforce audit support, as well as capability and interoperability sites, allowing to networks to interoperate, allowing atomic exchanges and transfer of data across networks. Next, next slide please. These are the two experimentations that I mentioned before. One, both were in the context of an expert experimentation commissioned by Bank of France. The first one is a wholesale central bank digital currency experimentation of a consortium of entities led by HSBC. That we were we successfully experimented central bank digital currencies for settling our French treasury bonds on blockchain and where it's very prominently showed that a blockchain can be an infrastructure to support wholesale CBDC network, giving value proposition around the risk reduction and therefore cost reduction and distribution of responsibility of running the system itself. So whereas the next slide, please. The second, the second system, the second system that we were experimentation that we integrated the assets that we're going to describe on was the same on the same experimentation with Bank of France. Same call for experimentation was a one led by HSBC. At IBM and HSBC and other partners successfully designed and tested and interoperable multi ledger CBDC for securities and foreign exchange settlement capabilities demonstrating interoperability and with foreign exchange, as well as across different central DLT systems. So the related reports you can also find here in the in the presentation. Next, and next slide please. And with that, I, I hand over to Dave now to give you an overview of what's possible today. Thanks a lot for your attention. Okay, thanks a lot, Ellie. Next slide please. There you go. So I'm going to go very quick before we get to the main event here with Angelo. Just to baseline everybody about what's there and current fabric and everything I'm talking about you can see in the fabric documentation the fabric tutorials and the fabric samples. The fabric naturally aligns very well to non fungible tokens with its state model, being a key value state maps very nicely to a non fungible token, where there'd be some type of identifier unique identifier for a token, along with some attributes of that token such as a current owner and maybe some properties like I have here in the slide color size and appraised value as examples. The properties might be in the clear they might be hashed they might be represented off chain by some, some reference URL link or something like that. You can do very different, very varying different models of this. But basically, the state provides the management and the blockchain and the state database maintains the management and the state and the ownership of an asset or a token. Smart contracts which we call chain codes to find the rules for token issuance and transfers. The fabric endorsement model defines which organizations peers must endorse a certain transaction. And then we've got a set of client applications and a set of SDKs and also some sample applications and go and Java and type script. I like to talk about how a client application application might do things like update a token or transfer token. Next slide please. Okay, so you see on the left, these are just a set of the samples that we have in the in the hyper ledger fabric samples of repository. Basically there are variations on this theme with different showcasing different typical token patterns. So we can think about different styles of ownership different styles of endorsement multi party agreement and privacy as being some of the key patterns that we see in the token space, especially around non fungible tokens. So for ownership it could be a certain enrolled client identity that owns a token or it could be a certain organization level that or that owns a token for in those and for endorsement it could be some static set of endorsers that are required for a certain smart or it could be based on the asset itself typically that might be the owner of the asset or maybe some custodian of the asset. Multi party agreement. So we've got samples here that talk about when a buyer and seller of a token might want to come to terms on that transfer before the actual transfer. Either they have to agree on some price or some other specifics about the token, and they can manage that that agreement in the chain code prior to the actual transfer. And then finally, privacy. So many people use the, the fabric private data collections to manage privacy so this will keep hashes on chain as opposed to the actual token data, and the actual token data will be shared amongst authorized by fabric, or you could manage the assets on your own application and just post hashes or a URL link or something like that to the to the fabric blockchain. Next slide please. Okay, and then it's not just non fungible tokens so a lot of our tutorials talk about an asset transfer model which is really a non fungible token model. But really the fabric states you can model anything really in a smart contract. And so we've got samples of how to model ERC 20 and ERC 1155 and 721 tokens, along with a typical UTXO token. So in a UTXO model, you might think of the states as being the unspent transactions. In ERC 20 model you would think of the states as being accounts that might have ownership of a certain number of tokens, and then similar for non fungible tokens and ERC 1155 tokens. So we've got examples of how to do all these things with fabric chain codes. So I'll leave it there for in terms of the base fabric capabilities you can look at more into more details in the fabric docs and the fabric tutorials and samples, but I'll pass it over to Angela to talk about what's coming. Thanks a lot Dave, and I will ask our last counter to start. She will tell us all about the fabric token SDK, and then I will jump in. Thank you Angela. So we could actually move to the next slide where we talk about the token, like we start talking about the token SDK and if we try to sheet. So, when it comes to token and block change system that is like a popular implementation, which is UTXO Dave, which is what it is used in Bitcoin. And this model what we have is that a transfer transaction consists of a set of inputs and the set of outputs, such that the inputs are destroyed after the transaction is committed and the outputs are created when the transaction is committed. And there is this invariant that these inputs and outputs should verify mainly that the inputs in the output should have the same type, and that the input in the output should preserve or should have the overall value. And this is very nice because it's the deletion of the inputs kind of give us this prevention of double spending sort of for free. So if you want to just prevent double spending what we do is that like when the transaction is committed, the input will be deleted, which means that next time someone wants to spend the same input. What happens that this input will not be found, meaning that the transaction will fail. So, when it comes, this is the description of the transfer when it comes to the issue the issue is just a transaction where we have outputs with a moth have input because we assume that there is some sort of entity that introduces, that is allowed to introduce token into the system and we check just whether whoever is the origin of this transaction is allowed to perform this operation or not. This seems to be nice. This is something that would allow us to do token operation, namely issue and transfer. We could also do redeem to some extent by thinking that the redeem is just a transfer where the owner entity. However, we could see that there is an issue here which is the lack of privacy. So whoever is actually whoever has access to the ledger could just look into the ledger and check and see that okay there is a transaction between A and B. This is the value of the transaction. This is the type of transaction that are being this type of asset that are being transacted. And based on that they could actually derive some sensitive information. It could be, in the case of payment, it could be the behavior of user and if we are talking about business or banks, it could be the business relationship between banks. So, next slide please. So privacy was a very important, let's say requirement when it comes to token systems. So it was sort of, it puts like heart and center of token system like how to preserve privacy and there are already tools that achieve this and basically the idea that we would obfuscate the content of the transaction would hide the identities of the transaction parties in a way that the validator would be able to check whether the transactions are valid or not without knowing the parties behind the transaction or accessing the content of the transaction. And this is done using very standard cryptographic techniques that are, and I think you are familiar with, it is zero knowledge proofs and with a combination with anonymous signature. And zero knowledge proofs allows us to do this magic things, which is I could verify whether something is correct or not without really knowing actually much information about whatever I am verifying. I just know that this transaction is valid, but I will not really know who is behind it or what is being transferred or how much is being transferred. However, when it comes to for privacy, there is an issue, especially if we are talking about regulated industry. So if we talk about financial industries are regulated one where you have to have some level of accountability and auditability. For privacy is good, like if we hide all the information of all the transactions, but but this is also gives rise to another problem if we take the case of payments. Like how would we ensure that there is no money laundering how would we ensure that there is no financing of criminal criminal activity. So these are application that requires some level of auditing but provides parties and this means that some party should be able to learn. Thank you. Some party should be able to learn the content of the transactions when the need arises. So basically we would have for privacy against everyone in the system except from some parties that are already identified they are not arbitrary these are parties that are kind of authorized to do this and basically to open the If there is some suspicion that this transaction is let's say malicious there is some sort of bad behavior happening and we need maybe to detect it. Sometimes we want to prevent it in the sense we want to do this inspection before the transaction is even committed because sometimes it's easier to prevent transaction from being committed than doing something like a rollback. So this is what's one of the goals of our of the token SDK or our work on tokens on top of hyperledger topic so we put this at the center of solution we were designing in the sense and with that there is privacy privacy is important there were already solutions in the literature the most famous one is zero cash where you could have all what we might call for privacy guarantees but there was this lack of auditing capabilities and our and replace ourselves in this space in the sense we will give you privacy but will also allow to authorize parties to inspect those actions and detect bad behavior. Next slide. Can you have you go like can you go through the animation. Sorry. So, the token SDK comes with very basic functionalities that we believe cover most of the token operations and these are issue transfer redeem and so on. The issue would allow authorized entities to introduce tokens in the case of central bank digital currency these are the central bank. Then we have transfer and this would allow parties to transfer tokens between among themselves. We have redeemed that is it could be privileged operations dependent on the use case where some entity could actually remove tokens from the blockchain like it is removed like they will be out of circulation. And then we have we have a swap and this is mostly when to operational to token operation need to take place. Automically, so for instance, if I am sending USD dollars against, let's say euros and I want these operation either to happen. Both of them happen or none of them happen here of course we are assuming that both assets exchange on the same blockchain but if this is not the case then we need. This is something that we mentioned at the beginning which is the interoperability so this is something where it would need a cross network exchange. So the fabric token SDK or the model that the fabric token SDK relies on to kind of have token transaction is the UTX model so the model I spoke about at the beginning. The reason for this is that UTXO is more privacy friendly. When it comes to account, even if you hide all the information you want, even if the transaction itself you look at it and you don't see okay what is actually or how much it's being transacted or the identity. So if this transaction is committed, you would see that there's been a right into like this is a transfer between Alice in between and you don't know who's AMD but at the time of the, at the time this transaction will be written into the ledger you would see that there was a right at position. Alpha is right at position better and then you say okay, I mean I don't know what transposed to whom but I see that this is a transfer between this, the state and the state it could be from alpha to beta but or beta from alpha but I see this. Every time there is an account, let's say transfer you would see that there is like this right that's happening between the same states. So this is why we adopted, or we opted for UTXO model because we believe that this is something that UTXO model kind of does with that so we actually prevent this leakage. Another thing that the token SDK does is that we have this key management that is handled by wallet so anyone who's going to use the token SDK to develop application. They don't need to worry much about how they do management because this is something that the token SDK offers for them. So we have these wallets that allow the developers to kind of design their application and it's sort of very transparent way so the wallets take care of this thing. Another thing that the token SDK also takes care of is supporting multiple privacy levels. And this is similar to wallets happens in a transparent manner. So they want the developer just to focus on the business logic. They don't really need to care about the cryptographic implementation that the cryptographic premises that underlying the privacy, privacy preserving implementation. They just need to care about the business logic and then the token SDK, I mean they just need to say to tell which they say level of privacy they want. Once they specify that the token SDK will take care of preserving the privacy for them. So the moment you know what your application does go pretty neat to kind of worry about how to preserve privacy because the token SDK would do that. And back to the point that I mentioned earlier which is what we believe is kind of one of the differentiator for the token SDK is auditability. So here we kind of allow auditors to inspect transaction and we do it beforehand. So before transactions go to the ledger we allow auditors who are these kind of three defined parties to access the content of the token, the transaction and find them off. So if they are okay with the content of the transaction the transaction will go through if they are not okay with the content of the transaction the transaction will be popped. And one more thing and maybe the last thing I would say on the slide is that we have also support for fungible non fungible tokens and the reason of this is that our API are simple enough in the kind of flexible so they they're very intuitive that we see that it comes to asset we have like the main operations issue transfer regime and to do for instance the transfer you just need to specify in the case of fungible tokens that quantity and the recipient and the case of non fungible tokens just need to specify the recipient. And this, by having API that are very close to what happens in the real world the token SDK allows any, I mean the token I mean when we implemented realize that also the support for fungible fungible non fungible tokens kind of come for free. Next slide. And this is one of the reason and the reason for this is that the token definition was started with was also included it was very simple so we said a token is defined by its owner and the owner here is an array of five. So it could be a public key, but it could also be a script that defines the conditions under which the token can be transferred so it could like in the script you could say I want this I want multiple public pieces for this token to be transferred we need the signature of ABC. It could be for instance saying that this, this, this token can only be transferred after certain deadline. So this is how flexible the ownership is. It gives you this kind of ability to either find ownership to a public key but also assign it to. The token also comes with a type. And here the type could be the denominator for instance in the case of digital currency it could be the denomination it could be UST it could be like Swiss France. But it could also be a unique identifier and this is the way we are able to support non fungible tokens because if non fungible tokens have the same where they can like, I mean, they are unique that you have the type which was already have they have unique identifiers. The way we support them is that actually these unique identifiers go and this is in this in this because in our token SDK we say that tokens are fungible as long as they have the same type. So if tokens in the system if two tokens in the system they don't have the same type this means that these tokens are not fungible. This is the quantity and the quantity is the amount of the type. So there is typing then there is quantity which tells you like how much this token stores. So it is a strict strictly positive number and kind of defines like the value of the token. The tokens as long as like the tokens that have the same type they can be merged and stick unless we specify it like explicitly saying okay these tokens cannot be merged or these tokens cannot be split. But if the type is different the token cannot be merged or I think that's it I give the floor to you. Thank you Qatar. Okay, back to me. Let's let's go. Let's do a deeper dive now into the core of the token SDK. Let me let me let me say first that probably I'm pretty sure that some of you already know already already dealt with zero knowledge and know the complexity of dealing with these cryptographic primitives, especially if you put them in a very complex in the context of a very complex protocol so our fundamental our key design principles have been very, very few but very clear first hide the complexity of handling the complex cryptographic cryptographic primitives in such a way the developer doesn't have to know directly that zero knowledge is employed or any other cryptographic techniques techniques is used the belief is just that the token SDK knows what to do and delivers a private private and secure private a secure experience. Then we wanted to say the following. We would like to write our token application once and then decide later which kind of privacy guarantees we want from our token system. For example, for example, in some cases we might not need to hide anything about the tokens. If the fact that they're in clear is fine for the application. For other things we prefer to have certain to hide certain piece of information. In other case we want to go full scale and hide as much as much as possible. But in doing this we don't want the developer to write again and again and again the same application just adjusting the API the calls to the API depending on the privacy level so right once adjust later set later the privacy. The privacy, the privacy level. Therefore we designed a family of stacks that deliver this experience to the developer to implement token based application token based application. Today we focus mostly on the token SDK on the token SDK itself, but he sits on top of what it's called the fabric smart client that is another component. It's another hyper ledger project labs. It delivers peer to peer infrastructure and other facilities and connection to blockchains and so on and so forth that are that are useful for for for the token SDK. But let me now answer the question how do you run this this tech where do you run this tech there are two ways essentially the first one you can run this stack as a standalone network no let me give you let me show you pictorially what that what does it mean. You can have all the center of the P of this of these slides you see these nodes that we call fabric smart client nodes, they run the entire stack up to the token to the token SDK. They are able also to connect in a peer to peer fashion fashion. So this is the application slash business business layer. Here there are the orchestration of the business processes like counter was saying. This is the place where atomic atomic swaps can arrange it or any other complex business process that you use case may may require. And then each of these nodes can connect to multiple to multiple network multiple fabric fabric instances, for instance, or even other different type of different type of the back ends like Orion, which is another fabric, which is another project, I have a larger lab project that I recommend you to be to give a look. It's a more centralized solution that with with blockchain with some blockchain, some blockchain flavors that might be very, very useful for certain, for certain use case. So that's a possible instantiation but you can also embed this tech in the application in your existing application. So if you already have an application server. Then you can just use you can just embed the token SDK and all the entire second your existing application no need to to introduce forcefully new nodes in in your network, your network topology. So this was very convenient because it allowed us to adjust as we go depending on the specific use case. But let me go now a little bit more into the details of the power of the of this of the token SDK stack and why it allows the developer to not have to worry about the complexity of zero knowledge or the other cryptographic primitives like anonymous credential. I think I mentioned that at the beginning which is a primitive that allow allow us to sign transactions anonymously and that linkably. So that's it's also very important to for the privacy of the for the privacy of the transaction. Everything starts with the token API. It's in the middle. It's this dark blue box. It's a it's essentially a layer that is blockchain agnostic. So the open the token API talks speaks about tokens in using a meta language. So it talks about operations over tokens and so on and so forth without any reference or any dependency to the to any underlying blockchain. On top of the token API so the light blue boxes. So these are what we call services which are library that can be the some of them already are ready to go in the token SDK other can be developed as a third party plugins. And this the services they deal with the token API to manipulate tokens and then they also deal with the back end so they might deal with fabric with Orion with other with other networks other networks to actually persist the token operations in the back end. Below the token API now there is the magic I told you that we want to write once the application so you have the token the developer has the token API. He uses the open API the token API and the services. And then it doesn't have to worry about how the actual tokens are described on the back end. Why is this because at the time of the setup of the system. The administrator of the system can decide the which driver to use for for the specific token implementation what doesn't mean that the talk that the we have a driver the driver layer allow us to separate the token API for from the actual representation and implementation of the tokens into the back end. This means that by, by, by having a stable token API, we can use then a driver API that either does not hide anything, or use zero knowledge proof or use trusted execution environment or can use any other technology to provide a specific privacy privacy guarantees. By default, in the in the token SDK that you find the in the open source version we will reason to drivers, one that we call fab token that it's essentially doesn't hide anything. Everything is in the clear, not even the even the identities are the long term identities of the party so you can even see that Alice did that transaction. The driver instead is a driver based on zero knowledge proofs, and it allows us to hide the content of the transaction, and to hide also the owner of the, the owner of the, the owner of the token so you can already play with with this zero knowledge, without having to worry about what's happening behind the scenes so you develop your token application, then you decide okay I need zero knowledge proof you set up zero knowledge and you're good to go. So that's what's the this is the magic of this separation of this of this of these layers, how do we achieve. I'm just going to jump in a quick question here someone had about the drivers. Yes, yes. Can the driver be switched in a running system by the admin. Well that's a very good question indeed it should be possible. I think that it's a very good. It's a very good question and definitely a feature that the token SDK should deliver it's not currently available why is this because it's anyway a complex scenario let me give you a scenario. It can be useful. Suppose now that you have a driver that is based on current elliptic curve elliptic curve cryptographies that we know to not be resistant to quantum computers, so you might need at some point to switch to post quantum to post quantum cryptography. Therefore, you must be able to switch the driver configuration of as you go at some point in a, especially in a moment of a safe state. This is definitely a great feature that I really would like to see if you want to jump in please reach us and we let's start a discussion on on on discord or any other channel and how to see how to do this effectively but beautiful question thank you. Anything else. Thank you. Great great so let me let me let me go a bit faster. So how do we remember that I told you that the token API is blockchain agnostic. So we want to have a meta language to describe token operations in such a way later on and I will show you. In this case, this this operations to the specific to the specific backend, and we want these operations to be to contain all the information that are needed in order to verify that these operations are are correct and you can imagine that verifying is different from verifying something that is in the clear or any other or any other technology so we need a structure we need to be able to represent this token in a very flexible way and we came out, we came out with this concept of token token request. So let's go through the anatomy of a token request we have essentially three sections. The first one is called anchor. It's a way to link all the operations all together in such a way they cannot be extracted and moved to another to another token request that's very, very important. We must guarantee non transferability of these operations from one request to the other to another, because otherwise it's like saying that the adversary, it's can just copy a transfer that is made and remake the transfer again and again and again. So the anchor is there to link everything together and to make this the operations known transferable. So you see the complete that there are so many details that one needs to be one needs to take care of that it's very handy to have a framework that does everything for you, you don't have to worry about the about the rest. We have the action sections this action section is actually carries the representation of the issue and the transfer operations redeem is a sort of transfer operation so we don't we don't explicitly speak about the redeem because for us is just a transfer operation. It's a special transfer operation. Therefore, we just we just talk about issue and transfer, and then we have the witnesses. What's what's what's a witness the witness is something that is needed to assert the validity of this of this of these operations. Imagine if Alice is transferring her tokens, she must sign the token request in order to deliver the belief that she really wants to transfer this this token. The issue from Alice will go inside the inside the witnesses. Now these actions. It's, it can contain this action section can contain multiple actions so we can have multiple issues multiple transfer. This what allow us to perform an atomic swap because we can describe in the token request a transfer from Alice to Bob and the transfer from Bob to Alice, because they are packet together, they either go through or none of them will go through. And then we have the third part is the metadata. This is also very important because remember counter showed us the model where everything is obfuscated on the ledger so when you look at the action section. There you find commitments if you are using zero knowledge you find commitments everything's obfuscated. So when Alice transfer something to Bob or if Alice and Bob are arranging a business process. Bob needs to have a way to understand what Alice did because what Bob needs to check that Alice did correctly her part and and and vice and vice versa With the metadata Alice can transfer all the secrets information or for who you know more about the commitments, what we call the day commitments so the private information that would allow Bob to inspect the to inspect the actions and get the belief that Alice it's it's performing the right, the right thing. Notice that this private information should not be given to the validators the validators to do should not be see they should be able to assess the validity of a token request just by looking at the actions and the witnesses, no more than that. Indeed, if we are using zero knowledge that you have the zero proofs in the action section, and you just verify that these proofs and you are good to go. So now that we're talking about described what it means to what is this for us this meta language this content containerization of token operation. Then what we do when we want to perform a token operation in fabric or in another system like Orion. There's a component that it's able to translate the token request to the to the destination to the back end that we that that we want to target. No worries, I will give you an example in a second of a life cycle of a token transaction in fabric. Let me give you also maybe a bigger representation of the complexity of performing an atomic an atomic swap and why it's so handy to have a stack that also allow us to allow us developers to perform peer to peer connection between clients to exchange messages and to therefore run a business a full business process in an exchange. You might have that Alison Bob needs to first agree on the on the exchange information so they want to Alice will tell Bob a Bob I'm ready to to transfer the SD please put your leg inside the transfer so let's feel together the token request and perform all the requirement and put all the witnesses that are that are needed that are required because if we if we miss something then the back end we reject our our request. So what happens then in let me tell you more now and a sense of what is what it means to perform a token transaction if we have fabric as a backend so on the left hand side, you see, you see this, but the business parties, they are together. They can connect in a peer to peer fashion they can arrange the terms of the operations that they want to perform on the right hand side we have we have we have fabric with that with a chain called the installer there I will tell you in a second what the chain code does. The business parties that they collected then they assemble essentially token the token request so they describe the operations that they want to perform. I just gave you an example of a swap the swap will contain a transfer from Alice to Bob a transfer from Bob to Alice plus the signatures from Alice and from Bob to represents that they want to. They want to perform this this transfer, we might have additional witnesses like signatures from auditing if if you set up the system to have auditing capabilities, then we might have additional additional signatures that might be required. So that's what we're doing in that specific use case. The beauty is that the tool request can contain anything that is needed for for your use case so if you have a use case that requires a different kind of auditing that also can be adjusted you just you just need a driver that is understand that that comp that composition. So when they are ready when the tool request is well formed. What they do is just they contact this chain code that we call token chain code. The token chain code does essentially two things. It validates the token request. So token chain code that receives only the first two blocks in the of the token request. It receives the anchor, which is the transaction ID in the case of fabric and the list of actions that if we are using zero knowledge proof will be full of commitments and zero knowledge groups. The validators just the endorsers will just validate the token request checking the zero knowledge proof set correct so on and so forth. Notice that this is not the time for double spending resistance because that the this is not the right time to check double double spending double spending is check a committing time. The second piece that needs to be done is exactly the translation remember the token request is a meta language and meta description of the operations, and they need to be converted to a read write set, because this is the language that fabric speaks and chain code can do that. But the endorsements, the fabric transaction is assembled and the transaction is then committed and to fabric and if everything fine, the transfer, the transfer happens or all the operations become become final. This is a life cycle or token transaction and I know what you are thinking. This is very complex. I know the interactions seems very complex and indeed they they need to be complex because it's complex what we are doing but this doesn't mean that the API must be complex. Let me give you a sketch of an example of what it means to write business logic for a transfer. The first step, suppose that Alice wants to transfer something to Bob, then Alice, the first thing that Alice can do this is just an example, it can be rearranged in many, in many ways we are very very flexible for this, for this, from this point of view. So, just to give you an example in the first step, Alice asks Bob, please Bob, can you give me a recipient identity that you that you won't use to receive these tokens. This is very important because Bob needs to, if Bob wants privacy, Bob needs to use every time a different pseudonym that is not linkable to the others. So, Alice connects to Bob, Bob gives back the pseudonym and then Alice can, at this point, create the transaction, an anonymous transaction. No reference to fabric but because we are targeting fabric behind the scene, the anonymous transaction means that the transaction will be signed with identity mixer. You don't have to care about the complexity of the mixer, the token SDK does everything for for you. We then, we then instruct the transfer that Alice wants to do, let me translate for you this to English. So transfer from this wallet, this type of tokens for this amount to the recipient. So that's the way you translate the single line. And then remember all the complexity, all the steps of the ping pong between for collecting the witnesses for collecting the auditor signatures for collecting the endorsements from the chain code, forming the fabric transaction, just a single line. Yes, you collected the endorsements, and you are good to go. You are everything is done automatically all the parties are are in bar contacted behind the scene fabric is contacted behind the scene to get the endorsement. And finally, when everything is done, you just submit the transaction for ordering, which means that you want to, you want to settle the operations that you want to perform. So that you get from this small piece of software, this small piece of business logic, the fact that we are able to the with the token API and the services, we can build a token, a token application without having to know about the privacy guarantees the complexity of zero knowledge without having to care about which kind of back end we are using, because most of the time it will be fabric because it's, it's such a great system now right. It's such a great system. And that's the beauty so you write once, then you use whatever you want samples, there are samples so if you go to the fabric token SDK, we are pushing new, we are pushing as much as we can in the open source repository we are improving the capabilities that are samples that you can use. We pushed the recently also the support for non fungible tokens soon will come also a sample application for non fungible for non fungible tokens right now you have integration tests so you can already look at that but there is a sample that shows you how to perform how to how to play with with fungible fungible tokens for a currency for a currency for example. Take away this is the last slide for for today and I'm glad that we will we'll have will have also some time for for questions. So the fabric token SDK delivers the set of API sense services that let developers create token based distributed application on hyper ledger fabric and more without having to care about the complexity of the back end, the complexity of zero knowledge and so forth. It adopts the UTXO model for the reason that counter well explained it, it proposes a very simple token definition that can support fungible and non fungible tokens. We hope that is simple to use but this is you to tell us and to help us to make even simpler for for us to use. And we believe that it's simple to use because it's close to your business logic instead of being close to fabric and to the complexity of all the fabric capability so it's a beautiful based fabric but if you don't know how to use you can quickly end up in situation where the system is down to find the more documentation and samples the token SDK repo is there or on discord, the channel is fabric token SDK. Thank you so much for listening. Thank you so much, Angelo for covering a lot of information we actually do have quite a few questions. We actually have Andy Martin who has raised his hand. So Andy, if you want to come off mute. Let me know if you're ready. If not, I'll cover another question while you're getting ready. While Andy comes on, can you answer this question about the drivers again so Andrew co a ask can we enhance the driver to direct specific tokens to selected endorsement policy. That doesn't need to be that doesn't need to happen at the driver, but at the service layer so when you assemble the token API so when you build your token request. At that point, you can use you can implement a third party service that uses a certain sense the proposal to fabric in a certain way different maybe forward from what the default yes you don't need to touch the driver. The driver is mostly interested on how the tokens are represented and what it means to generate a zero knowledge proof that makes a transfer valid this kind of it's more still everything that is from the token API below it's blockchain agnostic. What is up the services this is blockchain specific. Okay, great thanks. Jim Mason had a question about what are the current benchmarks for throughput on zero knowledge proofs and non zero knowledge proof tests. Very good we have. We didn't release numbers but again that's keep in mind that the drivers that are available there they are not a state of the art that just for you to use. You cannot reach the maximum throughput that that that there are able, but you know that's a day it's open so the, you can implement your own driver that uses I don't know a super duper zero knowledge proof system that has very fast, very fast performance and you are good to go with our goal was to mostly put out the skeleton the infrastructure and the basic building blocks that allow you to start to start developing your applications. So later on if you have a new driver that is super performant. You're good to go you can even sell it. Okay, thanks Angelo so this is from a little bit earlier in the presentation. Can the meta language being used switch between hyper ledger fabric and hyper ledger base you for example. That's possible indeed. We don't support that directly but that's absolutely absolutely possible. Yes indeed. It is. Great. Thanks for that question. We also had a question from Talgar by on. Is it possible to achieve the staking and unstaking feature with the support of fabric token SDK. Staking us taking it's a very specific thing to a specific use case so I will need to have more information of what you mean exactly for that please join us on this court we can go off offline and have a full full discussion on that yes. Yeah, I would love to hear about that maybe this is a few a feature that we can implement together. Yeah, that would be wonderful. And then we also had a question from Alan King on explaining I think this was earlier in the presentation in the very beginning about the different level of access to the data. He asked does it mean that the developer can design some kind of ACL. I'm not sure what does it mean that exactly maybe this was the a problem if it's related to auditability that that might make sense there auditability saying the ACL saying who can access what that might be an interesting concept to a more complex auditability policies. Of course we don't also that part is kind of it's quite customizable so we can you can build a third party service that delivers a new kind of auditability for the token token SDK but that's actually a very good idea please again discord. Yeah, I think this so they were referring to the access control list for a role. So maybe Alan if you have some other some clarification on that question you could post that real quick in the box and we could try and address it before the calls over. Let's see we had another question here on what's the difference to the sample, the samples of fabric samples, ERC 2011 55 to the samples of the hyper ledger labs and get hub. Maybe please also they feel free to jump in the this one the samples the fabric samples that they use directly fabric. So you need to know exactly what you are doing. You need to know if you're using state based endorsement or the specific that specific capabilities. That's the problem you have to deal directly with fabric you need to know what you are doing that which is okay it's totally fine and also if you want. Actually, it's good if you want an account based model and you don't need privacy or you need sorry, you need certain certain privacy features that are available with fabric directly with fabric like they were saying with the hashing. You need to use directly that one and if you know that you will not you don't need to migrate to any system. Totally fine. If instead you wanted this capabilities of multiple privacy levels, the full zero knowledge stack auditability that you go to the token SDK. I don't know Dave, if you want to jump in here. That's exactly right so the other the ones in the fabric samples are going to be all chain code based. Whereas the things Angela was talking about sits on top of fabric. We also had a question from Jess Hurwitz on is cross chain and roll ups in the roadmap for the SDK in the near future and also just generally the roadmap as well if you could comment on that. Yeah, that's a beautiful thing. What I can say is that we have another project that's called hyper legend weaver state unit there that will be something happening with tokens and weaver for the roll ups. The roll ups is something that it's really related to account based models so that's not what we target but what I can say is that definitely there's an interest for off chain transfer for payment system for sorry for payment channels to to avoid to go continuously for continuous to the ledger which anyway as a cost, but that's a great discussion discord please join us over the discussion there maybe this stuff we can shape together what what to do off chain transactions for for the token SDK. I think we could spend a lot more time on Q amp a and certainly this means there is an opportunity to continue the conversation. If you if you could let me share my screen. I'm going to just wrap it up here real quick. Thank you so much. Thank you, Angela, Ellie counter and Dave for joining us today. You covered a lot within an hour. We want to let you all know about our upcoming workshop series which is somewhat related with tokens on building your own NFT with hyper ledger fabric. So please visit the events page or website to register. We have our hyper ledger global forum coming up the registration is open as is the call for proposals. So we may very well have topics like these where you can get deeper into the questions and also meet some of the people that are working on these projects that are even on this call as well. So please register and also submit a proposal if you have something that you'd like to share. This is Angela mentioned several times in the call we have a discord community here at hyper ledger so please join the discard. You can continue all your questions there you can see how you can maybe participate and contribute to these projects as well and help us advance tokenization and hyper ledger fabric. Thank you all everybody. Thank you to the speakers and thank you all to the attendees. We appreciate you joining today. Again you'll get the recording for this so you can follow along and revisit some of the information later as well. We look forward to seeing you at a future webinar.