 So, hello everybody. Good afternoon, everybody. This is Daniel Segur. We're going to do this hyperlager meetup. I'm not quite sure about the location. I mean, it's always difficult this time with the location. I think it started for somehow with hyperlager Frankfurt, but it's pretty much actually advertised throughout the continent in several cities as well. So yeah, I would say it's like, you know, I mean, we are in the central European time, so basically somehow in the continent. But basically, this is hyperlager meetup. Hyperlager is for the consortium blockchain and partly already a little bit for public blockchains, scanners as well. What I'm going to talk today about is the privacy in hyperlager fabric. And with this brief introduction, I would like just to cover some of my content. Basically, I leave the chat here because otherwise, I usually just don't recognize this if anybody asked me questions. So basically, anytime feel free to interrupt me and have questions either in chat or actually without audio as well. I hope my audio will be working well as well. So basically, let me start with hyperlager fabric and privacy. Basically, as you know, hyperlager fabric is one of the oldest project actually with hyperlager. It's a consortium blockchain platform already started by hyperlager and by IBM and digital asset as well. But at the moment, basically, it's actively managed by hyperlager and IBM. So as a content, we're just going to cover a couple of structures for privacy. And these are more or less the classical structures. So I won't go very much into the details of advanced cryptography, especially not in the algorithmic details. This is going to be more or less the standard structures. So basically, the first one is channel. We're going to talk about like channels. The second one is private data collection. And basically, private data collection is, yeah, let me put it that way. It's more or less well known concept, but it's pretty much tricky to use. So we're going to iterate a lot of on private data collections, especially like if it can be attacked by dictionary attacks, because of the hash and the answer, of course, it can be attacked with like a little bit like topics like transient field and private data collection, some hints about private data and endorsement. Just as a slide, and there's a brief demonstration of we're going to cover idemics, identity mixer, and we're going to see some advanced patterns, basically with private data collection and different endorsement strategies. We will have brief demonstration in the middle as well. So I basically have a demo set up, and then I will show some of the concepts live as well. So this is actually the agenda. That's the content for today. I prepared basically a demo. It looks that way on GitHub. So this is basically an old demonstration from me. I started somehow like one year ago for for for demonstrating concepts of of hyper leisure fabric and Kubernetes. And then after that, I just use the repo for for different for demonstration purposes as well. So you find this repo, it actually contains some old presentations from me regarding hyper leisure fabric and Kubernetes, some more presentations regarding basically hyper leisure fabric and monitoring. And I just built in some concepts regarding hyper leisure fabric and privacy as well. So that's actually one big demo for a lot of things, basically. So you find everything on GitHub, and and this is the URL, of course. So let me start by on the one hand, by the introduction and basically covering the first privacy concept. So basically, this is hyper leisure fabric from from an architectural point of view. So if we speak on like architecture, we can always consider like like two layers of hyper leisure fabric. And one is the physical architecture. The second one is a little bit like the, like the logical architecture. And it's important to understand the physical architecture, especially if we speak about like privacy, it's because most of the privacy concepts or most of your privacy or private data can be leaked actually, because of the architecture, because of the consensus mechanism. So these are actually the basic items. And so what's important to know that basically hyper leisure fabric has this architecture, because of the consensus mechanism. So the consensus mechanism looks that way somehow, we got a transaction somewhere from a client. And basically, this transaction will, it's actually not a transaction, it's a transaction proposal. So transaction proposal proposes some kind of a change on the blockchain. And that can be accepted or denied or not accepted in a sense. So first, this transaction proposal will be sent to the peers, peers of different organizations, where there's the chain code, chain code is basically the smart contract. And what's going to happen for the first run is that chain code makes a kind of a simulation. So it doesn't actually execute the code, but it just simulates what would happen if we just execute this chain code, this smart contract logic, based on our transaction proposal, and it gets some read write sets. Read write set is basically like a set of atomic writes, reads and writes. So what would happen if we just write this, this atomic reads, or if we read this atomic reads or write this atomic writes to the ledger, but it's just a simulation, it will not be executed at this moment. So the next step is that these atomic reads writes, these atomic transactions will be sent back to the client. Client sends this to the ordering service. Ordering service puts into the block, into a block. And then basically this block sends back or will be, will be sent back to the peers. And peer basically checks again if everything is valid. And if everything is valid, basically it writes to the ledger. So from a privacy perspective, what's, what's important to know that, that's, that's a multi-phase transaction. And the first phase is like having a simulation, having like atomic reads writes basically, that will be actually written into the ledger as well. And at the end there's some state change, but not just the states change, I mean the whole ledger is more complicated than having just a stage, state change at the end. We're going to see like CoachDB basically there's a word state. So the last, last knowledge of the word, the last state of the word can be usually written in a CoachDB basically. So that's the, that's our last, last word state basically. And basically the, the, the transactions of the ledger results this word state descent state. And it's written usually in the CoachDB. So that's the fabric physical architecture. And it's important in terms of the, of the consensus mechanism. So let me just cover the first probably well-known privacy concept that's channeled. So in Hyperledger fabric, we got something as a logical architecture as well. Or I would say it's a logical architecture. And it looks that way. We got organizations. Organizations can be distinguished into, can be, can be covered from two directions. One direction is if we have like, you know, from a modeling perspective, from a modeling directions, we say that this is a consortium blockchain network. So basically what we got here, organizations or enterprises try to collaborate with each other somehow. So in this sense, in this, in this logical perspective, organization is an organization. It's a company. It's an enterprise that wants, wants somehow communicate with, with other enterprises, with other organizations. For more technical perspective, organization is a, is a set of access rules. So basically, if you want to access somehow to the whole blockchain application, to the whole blockchain network, then you can do it through basically an organization. And for the first round or for the first level, organizations makes, organization make you sure that you can access actually for this, for this whole network somehow. So this is both basically a logical and the more like access perspective. But nevertheless, we got like organizations wanting to cooperate with each other. So the first, first privacy structure is channel. Channel is a blockchain. So channel is the ledger itself. It's the physical ledger. So it's like, you know, like the blocks, like the transactions and stuff like that. And the idea is behind hyper ledger fabric that with the same architecture, you can have more than one blockchains. Very simple. So one channel is one blockchain. It's a physical ledger. It's a physical blockchain. And you know, our scanner, we got like four organizations having one, basically one big hyper ledger. I'm just slowing down because I think my network was a little bit unstable. But basically, so it looks that way, we got four organizations and one big hyper ledger fabric enterprise architecture or enterprise infrastructure. And with this architecture, we can have more than one blockchains. Very simple. So we got here like channel one. Channel one is a blockchain that connects like free organizations, organization one, organization two, and organization three. And again, this is a totally separated blockchain. All the blocks, all the word state, all the facts, all the data is replicated just between these three organizations, organization four, we will not see anything basically from channel one. So we got here channel two as well. Channel two is again, a totally separated blockchain. It connects organization two and organization four. So basically all the blocks, all the transactions, and your full blockchain is replicated just between organization two and organization four. You can have, I mean, theoretically, I'm not quite sure what's the limit, but theoretically, you can have as many organizations and as many channels as you want in your setup. So basically the first level of your privacy consideration and basically the simplest one is just having organizations and physically separated blockchains between your organizations that we call as channels. And again, so basically that's the best privacy way, I would say, because I mean, if like in organization four, organization four simply doesn't get physically the data from channel one. So actually the data is not there. It can't be seen. There's no like, you know, cryptographic magic or anything. It's just simply the data is not there. So what you can do for the first run, if you channel, if you design Hyperledger Fabric Cooperation or Enterprise Network, is that you just, you should just basically separate your use cases and separate your channels. And yeah, in a little bit fancy way, we can say that what you can do is like a multi-component sharding mechanism here, separating your business logic into physically different blockchains that might be even connected a little bit with each other. So if you want to connect like channels, different channels, what you can do is the chain code. I mean, chain code is related like for channels, but basically chain code works that way that you can have like multi-channel, I mean, not multi-channel chain code, but basically one chain code can access to another channel as well. If you have, I mean, there are some limitations for that, but basically you can chain code that accesses like data from another channel as well. That's one way. The other way is like if you have like client logic. So usually you don't have just the blockchain, but you have some like data access layer or clients that want basically to access your network. This client actually can connect to channels in a pretty easy way. So that's another option of using it. So the simplest way and I would say the most standard way is to separate privacy in your high-college and their PI setup is to use different channels separating physically your data. So that's the simplest way. The next way is the so-called private data collection. And private data collection gets a little bit tricky. So if you say private data collections, we are in one channel. So basically we speak about like one channel, it's one blockchain. And what we can do, we can write in data to the public ledger to the channel, that's the public data. And we can have something as private data. So private data works that way, as you can see here, we got some private data that we don't want to reveal for everybody. And basically this private data is not written into the ledger, only the head of the private data is written into the ledger. So basically if we have like private data, it's like an an off-chain database, what we have. It's actually not exactly an off-chain database because I mean the major point is that this structure is part of high-college fabric. So you have basically the same access rights, access structure, and different infrastructure considerations as for any other parts of high-college fabric. So it's not a totally separated concept. But it's in the system. But basically in the system you get like, I would say an off-chain database that stores data in a way that only hashes of your data is stored in the ledger. And basically we get one more mechanism that's a gossip network. So it looks that way if we have like two organizations wanting to share basically private data, then there's a gossip network and we can configure in a way that this data is accessible for these two organizations. Okay. So let me just draw actually a picture. So the usual setup looks somehow that way that we get like four organizations. So this is like org one, this is like org two, this is like org three, and this is like org four. And basically these organizations realize this one ledger, one channel. So this is like one channel. And this is one physical blockchain. But we can basically set up like private data collection in a way that private data collection shares data just between organization two and organization three, which means basically that this private data, I can say it's private state in a sense, can be found basically between organization two and organization three of the hash of the data is written into the ledger. So this is your ledger. So basically in the channel in the ledger, you can find the hash of the data of both organization two and three, but the data itself can be found just in organization two and organization three. And there's basically a separate gossip network that replicates this data. So your infrastructure makes sure that your private data is synchronized between all two and all three, but basically just all two and all three sees the private data, all one and all four organizations, they see just the hashes in the blockchain. So that's private data collection basically. So there's couple of like catches that you should that you should pay attention actually if you use private data collection. So for the first round, basically, it looks that way if you have a data and you we are right to or you use it with a private data collection, as I mentioned only hash is written into the ledger. But the point is that this, this hash is not sorted is there's no no answer or something. So basically, if you just use private data collection in a naive way, then it is so it can be attacked with dictionary attack. So just imagine this situation. In this situation, we get like all three and all two basically and only hash of the data is written into the ledger. So basically organization one and organization four will not see actually the data itself. However, organization one and organization four can basically see the hash of this data. And as basically this hash is not is not sorted. What you can do is to have a dictionary attack, which looks that way. So let me just imagine this situation. We got here in this example, we got a name that's like john, we've write john into the ledger. I just have here one one s h e hash algorithm. So basically this is john. And this is the hash what can be seen in the ledger. So in this example, basically organization one and organization four can see only this kind of hash here. Sorry, this one. So basically based on this hash, it's not easy to I mean, it's theoretically not possible to to to have some hints what's behind. But the point is basically you can do a dictionary attack dictionary attack looks that way. You can iterate all of the possible names. So you know, like, basically, the names are throughout the words like there are like, I don't know, one million possible names. So you can see George. Let me count basically the hash of George. Let me take a look if we see basically this hash here in the ledger. And if not, let me just have the next possible name. The next name is, I don't know, Daniel. So Daniel is the is the next possible hash. Let me take a look that we see as organization one like this such in the ledger. It's not and let me just alter it further. And let me see a john basically, and let me just take a look if the the hash of john is something similar. Then organization one can take a look if it sees basically the same as in the ledger. And if so, then there's a there's a match. So basically, organization one can conclude that the data in the private data collection is john, despite it doesn't know it just iterated all of the possible names, for instance, which is not so many. So it's like a couple of million. You can find dictionaries with that. And based on that iteration, it can conclude what's exactly in the private data collection without knowing the the exact data. So let me just let me just cover basically. So let me just finish. So basically, I mean, the solution is don't use just basically, so never use anything, just a simple data in the private data collection, have something always as an awesome or as a sort somewhere, because otherwise it won't work. So the question is, one field in the private data collection, or just one for the fields in the private data collection. So that's a good question. So usually what we do is we write like Jason's into the ledger. So basically, it looks that way. I should investigate basically that we get an ID. And for this ID, there's a complex JSON, and complex JSON actually has more than one field. And then in this scenario, then basically one hash is calculated on that. So it looks that way in the ledger, you can write like IDs and basically some value for the IDs. And I think for each value, for each ID, there's a hash calculated. But usually you don't write like individual items basically into your ledger, but this is like, you know, like a complex JSON having like multiply fields. And it's not a complicated way to have like here one nonce. So in this use case, what's the advantage of private data over creating a channel? So that's a good question. I should think it over exactly the answer. In some use cases, there are like, you know, I'm the ideas that basically, so there should be a lot of things going on that channel. So like, there's like, you know, five use cases. And five use cases looks that way, that all of the participants should see that five use case. And the six use case is something which is, you know, I mean, I mean, it's not for the, not for the general public, just for like the two organizations. And these use case might be even connected with the with the other five use cases that can be seen for everybody. So in this scenario, it's not practical to realize it with the channel. It's usually much better basically with the private data collection. That's one thing. The second thing which might be considered. So I'm not a basically I'm not a GDPR expert. But one idea of like using GDPR or solving GDPR problems is that you use basically like private data collections, because in private data collection, if you if you delete the name, I mean, if you have non seen the name, then basically only the hash remains in your ledger. So like the deleting, there's even a mechanism that you can, I mean, this private data can be purged automatically as well. But if this private data is purged, then then the data is not anymore in the ledger. And if you use it with like nonsense salt, and only the hash remains in the ledger, which can't can't be so based on this on this hash, you can't conclude or what's exactly the name, then it might be a good way for like GDPR compliance. This is this is a technical infrastructure that's our technical solution that might solve GDPR problems. I'm a technical guy. So I'm not a lawyer. So speak with a GDPR lawyer if you want to realize such an idea, but but basically it can be an idea actually for for such a use cases as well. Okay, so that's one thing in terms of private data collection that's basically nonce. So there's a second problem. And the second problem looks that way that basically the ledger, the ledger looks that way. So usually it's like, you know, I mean, this is your blockchain. You got some some transactions. And at the end of the transactions, you have the state. I think in Ethereum like you have the state overall, but basically in hyperledger fabric, you have the state that just the at the end. So your state is basically defects, the information, the your word state, your application word state that you want to that you want to use actually in your application. But these are the transactions. These are your box. And basically, you should be aware that not just the state is written, not just the word state is written into the ledger, but your transactions as well. So the problem is that your transaction mimics pretty much the I mean, this whole fabric consensus that we were talking about. So that I mean, the first part is basically something which is which is a transaction proposal. So you send the transaction proposal, basically to your peers, it simulates your your your proposal, it gives back like atomic rights and reads. And these atomic rights and reads are basically endorsed by different organizations. So what's important is basically, even if you have like, like private data, so you don't store, you don't store at the end, anything in your you can actually a problem that you despite you send this private information, basically, in your in your transaction proposal. So it looks that way. Let me just imagine I have one private data that should be kept somehow confidential. So basically, I have this private data. I don't write it into the ledger, but I write it into a private data collection, for instance. But the problem is, if I coincidentally send this data in my transaction proposal, or if it can be concluded somehow, based on the atomic rights and reads, then I will have a problem because these transactions are written into the ledger as well. Okay. So for this stuff, there's actually one idea, which is called transient field. And it looks that way. You should pay attention basically, if you send something in your transaction proposal in a normal way, then it will be recorded in the ledger. If you use however, like transient field, then then it won't be recorded. So if you have like one private data that you want to be sure it's private, then you should be pay attention that it should be sent with the transient field basically. So then it will be private in terms of private data, and it will not be seen in your ledger either. And then you can have some analysis as well, because it looks that way if you have like atomic rights and reads. So usually with your private data collection, you have atomic rights and reads just for your hashes. But despite if you have some errors coincidentally, you might as well write some information in a way that it can be reflected with atomic rights and reads. And there might be a possibility to somehow make some connection with your information that you want to hide. So that's transient field. So this is the next picture for transient field. So if you use like transient field, it's basically you create your transaction proposal in a way that instead of standard calls, you use transient field. And what's important is that this transient data will not be recorded into the ledger. So I prepared some demonstration as well. So let me just take a look if I have some practices. So what I'm having here is a very simple example. This is like a one organization art test. So I have like, in the meantime, I just started because it takes a while. But basically what I have here is a very simple organization. It's like one peer, one ordering service, hyper lecture Explorer. It's actually two parts. It has a database and basically Explorer. And I got set up basically. So this is my setup. That's a container which helps actually setting up the whole network. And I get one more setup, basically, that's for identity mixer, but it doesn't matter at the moment. And basically, it looks that way. I got like one organization. So this is the simplest demonstration that can be imagined for such scanners. And it starts, it will take a while. It's like two more minutes. So in the meantime, perhaps I just showed the code. I prepared some very, very simple code that you can see here. And that's what we're gonna take a look on. So I have basically one smart contract, one chain code. It has for the first round save data, save data. It's a very simple save. We just put information into the ledger. So I get just one ID and one some information. And I just put this to the ledger. I have that as well. It reads out information from the ledger. It's like get state. So the next version is save private data and get private data. It looks that way. I use private data. So I have like two more calls. One is like put private data. I just write private data to the ledger. It's basically there's a test collection in which I write this information. And I get private data. I just read out information from the same private data collection. Anyway, private data collection is basically described with the help of a JSON that must be actually configured during the setup of the network. I mean, at the installation of your chain code. So it's again, it's a very simple private data collection. And I have a third call pair as well. It looks that way. I have just the same private data save and read out. But I use basically private data collection, sorry, private data collection with transient data. So it looks that way. In this scenario, I have private data. I have saved the private data. And basically I have both my ID and my data in the transaction itself. And if I take a look with like save private data with transient, then it looks that way that I have just the ID in the transaction itself. And basically my transient data can be get actually with a separate call. So basically the data itself, I mean the private data itself will be read out in a different way. And that will be sent actually with the help of a transient field basically. So these are my functions. And theoretically my network should be ready. And then basically I configured Hyperledger Explorer as well. You can't see every single Hyperledger Explorer, but you can see a couple of things. And I think it's on me. And if I find my password, I'm pretty lucky. Okay, awesome. So that works. So I got the network up and running. So let me take a look what I can here do. And the first example is looks that way. I will have basically a very simple transaction. That's a normal transaction. So what I'm going to do here, I have basically a CLI set up container. With the help of a CLI set up container, I just saved my data. This saved data is the name of the transaction. It is actually the name of the chain code. And I have just one ID and one data one basically. And I mean in this sense data one will be on the long run something that should be considered as private. It's not private at the moment. With this setup, I just saved the data ID one and I just saved this data into the ledger. So let me just have this command. So it was successful. So if you just take a look actually with like Explorer, we can see actually a lot of information. So this is the transaction details of Hyperledger Explorer. And actually it sees some relevant information. Like perhaps what's important, it can be seen which organization created this transaction, who endorsed this transaction, some time information. And basically the atomic rights and reads are here as well. So basically you can see at the bottom that basically there was some ID one key and value one data. So this is not the transaction. This is the atomic read by set up that can be seen basically on the ledger. So this information is visible with Hyperledger Explorer, even Hyperledger Explorer. So let me just take a look at the next one. And the next one is basically a private data transaction. So what I'm going to do is that basically I call this save private data function, save private data function again, that looks that way. So basically I have here nothing just I use instead of putting data into the ledger, like putting data into a private data collection, which is configured here. So if I save private data, then basically it looks that way. I use similarly this ID one, and I use similarly basically a data, which is private data one. So if I have this stuff, let me just execute this transaction. And if I take a look Hyperledger Explorer, it should be the top transaction. So that should actually look better. Hyperledger Explorer doesn't really show much about my private data basically. I can despite take a look my private data if I want, if I have the correct organization, what I can do is that I can take a look on my on my coach DB. Just a second, that should be there should be there's an administrator console for coach DB and you can call it with underline utils if I'm not mistaken. Yeah, that looks great. I'm not quite sure what's my username and password. If I know, then it works. So what I see here, I see some databases. It's like, this is the database of my development channel, this test channel that I can see actually here, the ID one, the ID one that was written into my channel actually with the first transaction. I get somewhere actually, perhaps you attachments, if I say like you attachment, then I see you can even see the data as well. So this is data one. I brought data one into the ledger with my standard transaction. And what I can see here is I have my private data as well. It's again, it's just one organization. So basically I should see my private data. This one is this def channel test private data. And this one is the ID two, if I'm not mistaken. I think that was like ID two, but let me just check it. No, it's ID one. And that should be like private data one. So basically, if I just have ID one and private data one, then I should see here private data one. So it looks good. Again, I configured in a way that I see my private data actually in my organization. But if I co-incidentally don't have access for the private data that I won't see this information here. Okay. So what I can do, I mean, this is the classical way of like checking the information, but basically what I prepared is some deep level analysis of the ledger itself. And it's getting tricky here a little bit. So what I have here, so basically it looks that way your ledger is not encrypted. So every information that is on the ledger can be found on your peer. So if you have access for your peer and if you co-incidentally know how to encode your information, it's again, it's encoding. So it's like Unicode or ask your stuff like that. It's not so easy, but it's not encrypted. So technically you can encode your information from your ledger and you can see basically everything. What I'm going to do is not the deep level analysis of the ledger itself, but there's an administrator function that's an administrator smart contract that you can call. And that says call basically it's get transaction by ID. And what I can do with this call is to get more transaction from my ledger. So I will get the whole transaction from my ledger. So let me have this was actually the first transaction. So let me just go actually into this JavaScript file and if I'm not mistaken, okay, let me just try. So this is basically our transaction. It looks that way that the, I mean the encoding is tricky a little bit. I got here several versions. It's like once I convert a little bit like to S key then to base 64 and so on. So the encoding is not necessarily the simplest, but nevertheless it can be done. So it's not, there's no key like for encryption or something. It's just an encoding. So this is my transaction. It is encoded somehow. And if I just put it into the JSON viewer, then I can deep level analyze basically my transaction. So let me just let me just, how can I clear it? I see this one. Let me open the other one. I just give a shot with this one. Exactly. So here we are. This is our transaction. And it looks that way. So we got some signature at the beginning. Then we got some payload, some header, some channel information, a lot of things. But if we just go down, there's the signature header. So like once seeing that's important to know, there's this creator. You still remember if we just go here, we can see the creator membership service provider of our transaction. But actually the situation is a little bit more problematic because if we get the transaction, we don't only see the membership service provider, but we will see actually the whole X509 certificate that created and signed our transaction. So this is like actually the whole X509 certificate for the creator. One thing that's important, we got here like, so if we just created our certificate for somebody, it's just an administrator. But if we have like names here, like we create a X509 certificate to a certain name, then it might be a little bit problematic because this name, this common name is written into the ledger. So it can't be deleted. So if you have like some GDPR considerations, it's not necessarily the best idea. And in the data field, we see basically the read write sets. So again, it's creator again, creator information again. So we got here actually the issuer, that's just the certificate authority. But here again, we got the common name for X509 certificate, which might be pretty much unpractical. But somewhere we got the chain code proposal. So we should basically see our first whole proposal here. So if you just take a look, this is our proposal. That's how we call the transaction. It's save data, it's ID1 and it's data1. So pretty simple. Okay. And we get some endorsement as well. But first endorsement is not so complicated or not so problematic. What's problematic is the read write sets. So if we should see somewhere, not just the original proposal, but basically the whole read write sets as well. Not actually if I find it, but that should be somewhere here. That's the chain proposal response. If we take a look, here we find here the read write sets. So these are the atomic reads and atomic writes that can be found basically or can be seen like with Explorer as well. So I don't know if I find it exactly because this is the one and we find here the read write sets and we see here the writes and we see here that we have ID1 and we got data1. Okay. But this is totally normal and it's totally normal because that's a normal transaction. But let me just go back and take a look at my second transaction. I think that was my second transaction, but I mean I can just execute once again. So basically I just execute my transaction to a private data. So this is my private data transaction. I just execute it again. I got a new transaction ID and basically what I'm having, I just try to deep level analyze this transaction. So it looks a little bit like weird, but if I just have this new version, there should be some information in there which is not so practical. And it's again, it's not always the simplest to find, but so this is like the chain called proposal payload. And I should find here the proposal and basically we can see this is the proposal. So again, this is a proposal that was sent actually to the blockchain for endorsement and we see here the save private data. That's the function name and we see here the ID one and we see here the private data as well. So this is something that should not be recorded actually in the ledger display. That's for sure. And the other one is what's perhaps important is that in the action, we can even find the hashes itself. It's not so easy to get, but basically we got the read write sets and we have somewhere collection of hash read write sets. So basically this is hash writes and this is the hash key and this is the hash data. So I will not demonstrate this due to basically our time constraints, but basically based on these hashes, this is the SHE hash of your data. So based on without any notes or anything like that. So based on these hashes, you can have something as a dictionary attack. And if you're lucky, you can find basically the original data. Pretty simple. So I got my last transaction and my last transaction looks that way. Here basically I use transient field. So it looks that way I use, I set up some some trust transient data and basically I call this function in a way that there's there's transient data. So let me just show this one as well and let me show this transaction as well. So basically I got my transaction ID. So again, it looks a little bit like nasty, but just a quick check. If I just go to viewer. So what's better or what must be better is that I shouldn't see the data as I just call the function. So this is the chain code proposal payload. And basically what I'm having here is that exactly. So I have here the safe private data transient. That's the function called, that's the chain code function called. And I have here the ID too. And what I'm not having here is basically this data, which is basically actually, I mean this one is the data. It's a key value pair. So basically I have the key data and I have some data which is the message itself. And basically as you see, it is not recorded in the ledger. So because it was used like in transient data field. So I have just like these two pieces of information. And I mean the rest is pretty similar because I just write into the private data collection without like having to consider like salt or nonce. So basically this is like the first part of the presentation. If you use like private data collection, just consider using nonce and consider using transient field. There's a certainly important point as well that's still with private data collection. And the third one is like something which is endorsement. And endorsement looks that way. So if you have like organization, it's like or one, and you get like organization two. And if you consider private data collection, just for one organization, but you have a transaction which you send for both organizations for endorsement, then there's usually some tricky behavior as well. So you would expect that if you send this transaction to both organizations, and it has something to do with like private data, which is configured only at organization two, then the transaction will be fed. I mean you get an endorsement failure. But this is not always the case. In normal setting theoretically, and it's for some reasons it's basically a general setting where it's a normal setting or considered as normal setting with hyperledger fabric. If you just write the, if you just want to write this private data collection, then if you send this transaction for endorsement for both organizations, and this organization one doesn't have basically the private data, it doesn't cause errors. So it doesn't cause failures. So this part, if you just want to write a new value, for instance, in your private data collection, your transaction will be endorsed actually by both organizations. So this is like a feature theoretically. But nevertheless, it might cause problems because I mean if you consider you put some private data into your transaction, either as a transient field or as a normal field, but you send it for both organizations, then basically this organization gets private data, even if it doesn't have private data collection and even it shouldn't get this private data collection, this private data. So you should pay attention on the endorsement strategy as well, if you use like private data collection. And the reason is for that, because the endorsement works in a little bit like like tricky way. So your transaction might be endorsed, even if there's no private data collection configured with that organization, which means that your private data might leak nevertheless. So that's the third configuration. And I would just stop here for a second. I have a couple of more slides, but I'm not quite sure how long did we plan this session, this scenario. So I would just stop here and open a little bit like questions and answers. And I would just ask as well if I just cover some more slides as well. So is there any question? I'm not quite sure. I mean, you could use basically this chat as well, if you have like questions. So if there's no more question, again, I'm not quite sure. I have like two versions and the one version my presentation is one and a half hour long. In the other one is just one hour. So I would just continue with a couple of more slides. I hope it's okay. Again, I wasn't sure if I should plan one hour or one and a half, but nevertheless, let me just continue. And the next, I got like two more concepts basically. These are three more concepts. I would just summarize these concepts as well. This is again, basically, it's the usage of frenzy and field if in a case, if you don't want to use the private data collection. So usually use frenzy and field with private data collection, but this is not the only application area. So it looks that way. There's a pattern which is not much used, but nevertheless, it exists. And it's transient field and encryption. And it looks that way. So if you want to have like privacy, you can make like ledger encryption. Hyperledger doesn't support encryption in your ledger. So you should actually implement it on your own. It's completely up to you. And so it's actually sticky. So the general idea is that don't use ledger encryption unless you do what you do or unless you know what to do. Otherwise, it might be a little bit tricky. And then you can imagine basically, so ledger level encryption means that all of your ledger is encrypted. You get some keys for encrypting and decrypting your information. And it is completely handled by you. And then fabric has some minimal support for that, but not many examples throughout the world how it can be used. So if you have such a pattern, one thing which is tricky is basically is that you want to have actually something which is business logic. So in your chain code, there's a business logic. There are transactions. And if you want these transactions processed on your ledger, then that's not such an easy thing. Because I mean, the point is that your business logic, your chain code should work basically with encrypted information. So there are like two ways how you can do it or two big directions. One big direction is the cryptographic way. It's pretty complicated. The idea is how you can process actually information in a way that they are encrypted. So how you can process encrypted information, encrypted functions. It's like homomorphic encryption and functional encryption and stuff like that. So it's pretty much cryptographic heavy. The other one that you can use is kind of an architecture trick with hyper ledger fabric. And basically, it looks that way. You use like the transient field. So this is your chain code. And this is your ledger. It can't be very much seen because of the chat, but I just put the chat below. And we got here the ledger. And the point is basically that all of your information is encrypted in your ledger. So your chain code won't really know what to really inform in because it's encrypted. But what you can do is that this is a user sending a transaction that should be somehow processed with your chain code. So what you can do is that you send the decryption key in your fabric transaction in a transient field. Then chain code gets basically this decryption key. It reads out the encrypted information from the ledger. With the help of this decryption or encryption key, it decrypts the information. It processes basically this information. It encrypts it again and writes back to the ledger. And in this way, you can have as many or as much business process with your chain code as you want, despite the information in your ledger remains actually encrypted. Certainly there's one catch. One catch is that your encryption key is here. So you have to make sure that this encryption key won't be leaked. It's like won't be leaked basically through your network and won't be leaked with your chain code container. So it might be tricky. I don't know how it can be solved with network. It's like if you want to make sure that this encryption key won't leak with your container, you should do something as a trusted execution environment, which is again pretty tricky. But this was just an example that you can use transient field without a private data collection as well. Let me have one other privacy structure from Hyperledger Fabric and that's identity mix set. So as you still see, the problem is basically with such a transaction that this is your transaction. And I briefly showed that it looks that way that actually the creator information can be found here, which might be not the best idea. So normally if you use like X509 certificates, the problem is that your whole certificate is written to the ledger. So you have here like again, this is administrator, but if you like just configure, you know, I mean one client-side certificate for each of your users, then basically each of your users will appear in the ledger based on this X509 certificate. So one way of hiding this information is that instead of X509 certificate, you can use something as identity mixer. It's actually a cryptographic access structure, but it's not based on public private key cryptography, but on verifiable credentials and zero knowledge proof. So basically this is the idea. I won't go very much into the details. You get like issuers issuing credentials, you get some proof basically on your credentials that you show for a verifier and basically use some zero knowledge tricks here. So not all of your attributes are revealed. So it looks that way. What you can do with iDemix is basically to hide this information. So it looks that way, you will have basically the some properties that are revealed like the like the organizational unit or the role is revealed, but basically the enrollment iD is hidden. So this one is that you're the, I don't know, admin one of the XYZ organization. This information can be actually hidden with the help of identity mixer. Perhaps in the long run, there will be other properties that can be hidden as well. So it's important to know that the idea of iDemixer is to hide this piece of information as much as possible in your ledger and with your signatures. Unfortunately, iDemixer has some limitations and then, so let me put it that way, it was heavily investigated like a couple of years ago, but nowadays I'm not quite sure it seems, but it's just my idea. It seems it's not so much heavily further developed. So the point is, first you can have just organizational client certificates this way. So you can't, you can't have something as an endorsement, basically. You can't do an endorsement. There's a fixed set of attributes. It's like there's, you can have an organizational unit or role. These are revealed and you can have basically one enrollment iD that can be hidden and basically a revocation handle, but it's not and then according to the documentation, there's no official revocation. So if you want to do revocation, it might be tricky as well. So again, this is identity mixer and the idea is basically to hide some piece of information who created this kind of a transaction, but basically with having the cryptographic guarantee and stuff for the, for the whole hyperledger fabric structure. I have one example here as well for identity mixer transaction. So it looks that way. If you want to configure identity mixer, I had one example on the net and it looks that way that I, I created a special organization called organization one idemics and basically at starting the whole network, there's a tool which might not be used for production, but that's an idemics generator. And with the help of an idemics generator, you can create a couple of idemics certificates and basically I have this organization just for the identity mixer configured with degenerated identity mixer certificates. And the point is that this organization won't have any peers. It's just a plant-side organization to start basically transactions with. So basically my channel and application policies are set up in a way as well that basically, basically this special idemics organization won't matter. So it won't do like endorsement or life cycle endorsement or stuff like that. So having this example, I can show one idemics transaction as well. And it, again, it looks that way. I configured basically one special CLI. One special CLI just for identity mixer. And it's pretty similar as a standard CLI. The difference is that I have to use like core peer local mentorship service type. It's idemics. I have the local MSP ID for the idemics certification as well. And basically what I'm having in the MSP config pass, I have my idemics certificates basically. And having this, basically I can create one transaction. It's pretty much the same. So I have invoke or I invoke one transaction with like in a classical way. I just do it via basically a CLI CLI idemics container. So if I do it, let me just change back actually to to explore that. What I will see is that this is my, this is my transaction. And as you see, basically, Hyperledger Explorer won't always recognize this identity mixer transactions. I don't know why. But if I just take a look in details on this transaction, getting more freaky, I hope it works. Just a second. Yeah, that should be great. So if we take a look on this transaction, then the difference is that so in the, in like in the creator, there should be like less information. And perhaps you can see it. So if you can see in the creator, we don't see the X509 certificate anymore. We just see this is theoretically kind of zero knowledge proof. I can't decode it more basically. But theoretically, it reflects like the right, like the role and organizational unit, but it shouldn't reflect like the, like the exact, exact person or is exact, exact name of the certificate that created this transaction. But nevertheless, like, I mean, the rest is unchanged. So like, you can't use for endorsements. So like endorser is pretty much the same. It still uses X509 certificates. So that's identity mixer. And my last slide for today is that we got some advanced patterns based on the previous, previous ideas. So like with the help of like different usage of private data collection, transient field, and eDemix even, you can have some pretty cool things. It's like one pattern goes into the direction is that how you can coordinate like two organizations in a way that they exchange information, but this information won't be, won't be visible for, for other organizations, even if they are on the same channel, even if they see everything on the, on the channel. Another idea is basically something which is, I would say it's a quasi anonym endorsement. It's pretty tricky. So basically endorsement is visible on the ledger. So if you just want to endorse a transaction with two organizations, then you will see on the ledger that this transaction was actually endorsed by these two organizations, which might be not so optimal in certain use cases. So you can have something which is similar to a pseudonym or a quasi anonym endorsement. It works that way. It consists two transactions. There's a pre-approved and there's basically an approve. And pre-approved looks that way. It writes some, some information in the private data collection of the organization one. I didn't mention, but basically every organization has, has one special private data collection, which is just for the given organization. So I can write some, some information in this private data collection, like the, like the metadata of my transaction that should be approved on the long term. And then having this pre-approved, I can send basically a transaction to another organization, which is just endorsed by organization two. And I can send this, this actually this private data in a transient field. And with this approved transaction, the other organization can take a look if this, I mean, based on the hash can take a look if this information, if this transaction was really pre-approved by, by one organization. There's like a third advanced pattern as well. It's like, so as basically every organization has, has a special private data collection, which is just for the certain organization. You can, you can build up networks that work in a way that there's, there's private data in, in for each organization. So your data structure looks that way. You get some public data and some, some private data. And then this private data will be moved actually with certain transactions. So you can, you can imagine as like there's a private token just for the organization one, and it moves to a private data collection of an organization two, if there's a certain transaction basically happening. So that was my last slide. And again, basically, I would say question and answers. I'm not quite sure about the timing, but it seems we have already like one and a half hour. Yeah, sure. Just ping me on LinkedIn, if you want to. Yeah, sure. Just ping me on LinkedIn and any time for sure. Yeah. But I would say I hope we have like 10 more minutes. So I would just switch back to like question and answers. And if you have any questions, I'm happy to answer. Yeah, sure. So I will post actually both this presentation and basically the, the, I mean, presentation includes my GitHub repo as well. I will post this basically meetup. And I think we got like live YouTube streaming. So usually I post it under the, under the live YouTube streaming as well. So you will, you will have the link both for the presentation and for the GitHub repo as well. So I don't know if there's actually no more question regarding this topic, then I would like you, I would like to thank you very much for your attention. And I would just slowly actually close this meetup. So last chance, if you have any questions for, for fabric and privacy, just let me know. So if no more than again, thank you very much for your attention. And then, yeah, I would say have a nice weekend, but it's actually just Thursday. So and thank you, Daniel. This was really helpful. So one, one day, one day to work. Yeah. Yeah. Okay. So thank you very much again. Thanks, Daniel. Thanks everyone.