 Okay, and I'm going to record to the cloud. All right. Welcome everybody to the Morgan State seminars. My name is Sean Bohan. I'm going to turn it over to Tanisha who's going to give us an introduction and then I'm going to introduce hyper ledger and our speaker today Hart Montgomery so Tanisha, you're up. All right. Thank you, Sean. My name is Tanisha Brown. I am the program communications outreach coordinator for the National Fintech Center. The National Fintech Center is the hub for the HBCU community in the blockchain and Fintech space. We are proud associate members of the hyper ledger hyper ledger foundation and we want to give a special thanks to them for co organizing this seminar and many other seminars. We would love to continue to partnership and I thank you again for coming. Outstanding. And my name is Sean Bohan. I'm a community architect at hyper ledger. We've been working with the more the fintech center Morgan State for a couple of years now and we're pretty excited about this program. These really aren't hands on workshops they're more like lectures and discussions around topics around the fintech that that are involved with the fintech center. Hyper ledger is part of the Linux Foundation, and we are the we host the communities that build and the software projects that are enterprise blockchain. Everything from hyper ledger fabric and sawtooth to Indian areas and a number of tools as well. Our speaker today is Hart Montgomery, who is the chief technology officer at hyper ledger. He is going to take us through a presentation around decentralization privacy on the blockchain just the basics. A couple of times during the presentation I'm going to post links in the chat in case you want to find the wiki page for this presentation or the wiki page for the seminar series, or the hyper ledger discord which is where all our conversations are going. And we will also be doing q&a. If you have a question, please post the question in the chat, I will be going over the questions with heart when we take breaks or when we get to question time. And I'd like to thank everybody and turn it over to heart heart take it away. Awesome. Can everybody hear me. You sound good. That's probably too kind but thank you shine. All right, so. Hello everyone today. Thank you for having me. And today I'm going to be talking about decentralization and privacy on blockchain. And thank you for the introduction, Sean. So Sean already introduced me so I don't think I need to go, you know, too much into my background. So let's just get started. You know, today, I'm going to talk about, you know, sort of three core things I'm going to get into blockchain and decentralization by explaining the Byzantine generals problem. Then I'm going to talk about, you know, sort of decentralization, which is the core of Web three and blockchain. And then we're going to go into some of the drawbacks of blockchain and decentralization, and really one of the biggest things here is privacy. So that's how we're going to get into privacy. So let's get started. Let's start by talking about the Byzantine generals problem, which will motivate blockchain and decentralization. So what is the Byzantine generals problem. Suppose we have some number of generals and this could be an arbitrary number but for now I'll assume that it's five and they need to decide whether to attack a fortress or retreat. If all the generals attack victories very likely. If all the generals retreat losses are minimal, but you know we'll save three or less generals attack then it's a catastrophe right it's a big problem. So, how might the generals decide well, you know if there's no one general in charge we might think the generals might vote right you know that's sort of the natural and easy way to think about this right. So, the generals could send messengers to each other so this general could send a messenger to the other general saying, you know, I want to attack. Another general could say I want to retreat. You know the third general could say well I also want to retreat. You know the fourth general could say I want to attack, you know, and the last general could also want to attack right and and they're sending messages to each other to handle this vote. Right. And then finally right you know since they've concluded a vote. You know, there are three votes for attacking and two votes for retreating all the generals will decide to attack, and there will likely be a good outcome. So, the problem gets interesting and the problem is sort of formally defined in this way is what happens if a general is a trader. Right, so what happens if one of these generals is actually not honest. Well, what could they do right. So if we go back through our voting situation again, we could have one general proposed to attack. The second one says to retreat. The third one says to retreat, and then the fourth one says to attack again. So we're sort of tied it to for for votes. But what can this, you know, corrupted or this trader is general do right. Well, what if the general tells two people that he wants to attack and two people that he wants to retreat right now. This sort of complicates the vote right because for these two people on the top. The perspective is, well, the majority voted to attack, we should attack. And for these two generals on the bottom, the view is that the majority voted to retreat, we should treat right. And then, you know, if this actually happens we would have two generals attacking and three retreating, and we'll assume the corrupted general retreats. And this is of course a disaster, right by our problem statement. And so you might ask, you know, what can we do about this right. And really the solution is something that's called a distributed consensus protocol, which is at the heart of both decentralization and blockchain. And the guarantee is that if more than two thirds of the generals are honest, and I don't really want to formally define what that means but it means, you know, essentially what you think it does. It means that all of the honest generals will take the same attack. Let's take the same action. We obviously can't guarantee what, you know, traderist generals will do, but you know, we can assume that honest generals will take the appropriate action. And this is called Byzantine fault tolerant consensus. I don't think there is actually any connection to the Byzantine Empire, other than just the problem somehow got named this. And this is the backbone of blockchain and web three. And, you know, someone is definitely going to ask, you know, how can we fix this problem. And the simple answer is communication between the generals. So what the generals will have to do is they will have to discuss each other's responses with each other right so these other generals will have to say, you know, basically, did this guy tell you to attack he told me to attack basically, so there will have to be more communication. And you can prove mathematically that that you actually need this extra communication. And I don't want to get too much into the details on this, because it does get very technical in a hurry. But this is the basic idea. To get into blockchain right, you know, well, we've defined this problem as five generals deciding whether to attack the fortress or retreat right. But we could really generalize this right you know suppose we have five servers that need to decide on some state that they have to agree on right you know some records and database. And, you know, maybe one of the servers is corrupted, or hacked, or their problems. And this is really what blockchain is this is just the heart of blockchain. You can just think of it as, you know, computers or servers, deciding on some state that needs to have agreement, even in the presence of malicious adversaries. So I guess I'll stop there and see if there are any questions so far on this. If you've got a question please put it in chat and I will read it out for heart. It doesn't look like there any but I just want to ask. Do you suppose that all messages arrive. That's a fantastic question. Yes, we do assume eventual delivery eventual delivery is actually a technical term for this. It turns out that if, if messages are not guaranteed to arrive there's basically nothing we can do right. If we have an adversary that can intercept messages that can stop all messages between the generals. We have to assume that the general is corrupted is traitorous. They may not be traitorous. But, you know, from from the generals problem right. If all of the generals messengers are traitorous, then we just sort of have to assume that the general is traitorous by default because they can communicate in an honest manner. Does this make sense. All question heart can we can we name semi decentralization because the majority of them are selected for attack and scanner who asked about to all messages arrives to thank you. Awesome. So, I will get into semi decentralization actually in a few slides. What is, yes, it's. Well, how about we just, we just push that to future slides, because I will be talking about how decentralization is a continuum in just a minute. Awesome. So I'll answer that question and just to say. Great. So if we can. Are we good to continue I think we're good to go hard. All right, so, you know, the decentralization problem, you know, is is natural it's so earlier we insisted on a vote between generals. So a question you might have is, you know, why shouldn't just one general decide right. You know, and there are a lot of ways to answer this question, you know, one simple one is well what if the general decides is corrupted right that that is very bad outcome. But in general, we're going to define decentralization as the degree to which a single entity or group of entities control something. Right. And you can measure this in a variety of different ways, whether it's the proportion of control of something by any single entity, the number of entities it takes to completely control a system. Or, you know, even more complicated metrics. So for those of you that are familiar with the Nakamoto coefficient, that might be another. Well, that is another way to measure decentralization. You can sort of think of this as an absolute dictatorship is totally centralized, a representative democracy is moderately decentralized, and a direct democracy is totally decentralized, at least in theory. So, what is a distributed ledger. So we're going to define a blockchain specifically as an append only system of record or a transaction log. Now, a distributed ledger is a distributed database with decentralized trust. We'll say that most popular block chains are also distributed ledgers, and most popular distributed ledgers are also block chains. And in this framework, we can think of popular blockchain systems in an abstract way, right. You can think of Bitcoin as sort of distributed database for money with, you know, I'll put it in quotes fully, because the full decentralization is only in theory rather than practice. But you can think of it as a distributed database for money with fully decentralized trust. You can think of Ethereum as a distributed database for sort of alcoholic programs with fully decentralized trust, because smart contracts are really just code, right. And hyperledger fabric, you can think of as a distributed database for programs with what I'll call partially decentralized trust. And this goes back to the question earlier about semi decentralization. Today, we're going to talk about distributed ledgers rather than block chains, although our discussion will certainly apply to block chains that are also distributed ledgers. So, for some applications, the mutability guarantees of block chains can be great, but it's not always the case right in many applications we do want the ability to erase data. So, again, the core property we're looking at today is decentralized trust. I don't want to emphasize that you've all probably seen a lot of stuff in in Web three. You know, but sort of how databases are the backbone of how, you know, technology runs and went to distributed ledgers are sort of the database version of Web three. Again, this this is really just blockchain right if we go back to our analogy of the generals and the servers, you know, you can think of a blockchain is sort of lots of decisions and sequence right, you know the generals had to decide attack retreat retreat attack. And you know you can just think of all of this data as forming a distributed database. So, the next thing to talk about is what is decentralized trust right. If we're thinking of a database as a store of records, you know, who gets to decide what records belong in the database right if we have one person or entity deciding this centralization. And if many different entities decide we get decentralization right so going back to this semi decentralization point, you know we really want to think of decentralized trust as a continuum, right. And you know the consensus algorithm is really the most impactful choice, although there are others right. So if we sort of look at black chains or distributed ledgers right. We can think of things that are the most decentralized, you know, at least in theory, as public cryptocurrencies right with, you know, proof of work or proof of stake consensus. You know, as we move more towards, you know, centralization we have distributed ledgers with Byzantine fault tolerant consensus, which I described earlier in the Byzantine generals problem. Then we have distributed ledgers with what's called crash fault tolerant consensus, which is where servers can crash, or in the generals analogy. The generals can not respond, but they're not allowed to send different people different messages. Finally, we have, you know, sort of centralized ledgers and, you know, traditional databases. So this is really a continuum. Today, you know, people sort of define this in an almost a binary way, where we have permissioned versus permissionless ledgers and public versus private ledgers that indicate who can write and read to a blockchain. And I still emphasize that there is a continuum, even if people do use these terms today and these terms are popular. So, you know, if you think about where sort of distributed ledgers fit, you know, here's an example of where, you know, a number of different ledgers go. You know, you can think about why there really aren't any private and permissionless ledgers. It's sort of, you know, something you can write to but not read to it is not very useful. So, why do we want decentralized trust sort of why do we care about all this in the first place well, you know, suppose we have an issue, or an instance where several entities need to agree on some data, but no entity trusts any other single entity to be the source of truth. Or what if we need to make the store of information redundant in the case of compromise or an attack by a hacker. It might be the case that an entity that is the best official source of truth for some data doesn't want to or cannot be responsible for the upkeep of the data. Or maybe we have a case where people responsible for maintaining a data set or dynamic and change quickly. And the fundamental statement is that, you know, the question, do I need to distribute the ledger is really just, do I need a database with decentralized trust. And sort of, if you remember anything today, this is the single most important point, right, whenever you think about block chains or whether you want to use a blockchain you want to consider, you know, sort of what's being stored in the database really, what if it's programs, and why is having one centralized entity maintain this information, you know, a bad idea, or generally invisible. And this will make it really easy for you in the future, if you think this way to distinguish cases where distributed ledger use is sort of just hype, rather than necessary. So right so at this point, I will, you know, pause for questions. If you have a question, please put it in the chat. Let's give it one second heart, we'll see if anybody's got a question for you based on the last module. All right, I think we don't know we have one question. What do you think about transparency. This is from Regina. What do you think about transparency in relation to needing a decentralized database. Yeah, transparency is a great reason to use blockchain. You know, in some cases, transparency requires immutability. So it does actually require blockchain. But, you know, showing that a number of different people or parties agree on some state is, you know, really important for transparency. And I'm not going to talk about it today. So there's this idea of state proofs on a blockchain, if you're familiar with this, and it allows you to to prove the state of a blockchain. And this is also really, you know, another, another tool that really allows you to prove transparency. Hey, we have two more questions for you jump Divya asked, can you elaborate on storage capacity in relation to blockchain. Absolutely. So, you know, block chains are obviously distributed databases right. And in without sort of more advanced technology like sharding, and even with sharding, you know, it is required that people replicate data on blockchain right. Yeah, that's right. Thanks, Sean. So, you know, there is some storage redundancy by design. But what we generally find is that people don't store large amounts of data on blockchain, they don't need to. Rather, they store a hash of the data on the blockchain, or some other commitment to the data that allows people to prove that you know the data was around and sort of was an existence at this time. And then, you know, you get, you know, pretty much all the benefits of blockchain for for storing and keeping track of that data, even though it's not specifically stored on the blockchain. So storage costs are something to consider. And in general, you know, you for for privacy purposes as well, which we'll talk about in a minute to you want to store as little as you can on the blockchain. There's another question from Brandon with regards to the ledgers, are the blocks in the chain only created once proof of work has been completed. How does this process work in terms of the speed of the transactions. So the proof of work chain. Yes, the blocks are only created once sort of a block is mined. This is why proof of work typically has slow transaction acceptance speed. However, most of the distributed ledgers I'm talking about today are not actually proof of work based, you know, thankfully, I think most of the blockchain community is moving away from proof of work. You know, obviously we still have Bitcoin, but where most of the business applications are happening. It's not on proof of work based blockchains. And Sharon just asked, and we'll take this question once the next section we have ledger layer decentralization, ordering service layer decentralization, pure node layer decentralization. So just like app layer security network layer security, we can define different decentralization layers. On this case in hyper ledger fabric, correct. Yes, I have a whole slide on this coming up actually this. You know, so, but yes, we, we, I will explicitly point out later that you know you're sort of only as decentralized as your, as your most centralized point. So that's a great point. You know, and I guess, I've got the chat up now. Does the crash tall fault tolerant consensus is another term the raft itself. So raft is an example of a crash fault tolerant consensus algorithm. So there are many crash fault tolerance is a broad property of consensus algorithms and raft is one such consensus algorithm that meets that property. So, awesome. I guess I should probably move on to the next section then you're good to go hard. So, so next, you know, one thing we can talk about is is why not, you know, sort of always distributed ledgers right. Why shouldn't we always use a blockchain or distributed ledger. You know, why don't we totally get rid of the basis. And, you know, decentralization is a fantastic tool, but there are always drawbacks to using powerful tools right. And if we use distributed ledgers, they're often issues that need to be addressed. And two of the more common that we will cover today are privacy and confidentiality and performance. These are challenging. We do address them in hyper ledger, and there are a number of different ways to address them. So, one thing that, you know, a lot of people sort of like to say about privacy is is that, you know, we anonymize all users, right. This this seems very good in theory right. So, I will ask people, you know, what is this can anyone tell me what this is. What do you think this is. Anyone in chat orders made by customers on a certain date says Regina credit card charges from Lorenzo. Yes, Lorenzo, you're right. This is actually my credit card bill from, you know, a period of time and in 2018. You know, and, and, you know, it's anonymized right my name isn't on it. But, you know, it turns out at least a lot of information about me right, you know, if you sort of go through this right you know I'm buying like stuff at vending machines in in San Jose. Well, you know, you could probably assume that you know in March of 2018 that I was working somewhere in the South Bay in San Jose, you know, somewhere in the San Francisco area right. So, you'd see me eat at a restaurant in Sunnyvale right well I'm probably like working near there or living near there or something right. You know, I'm eating at a corporate catering in in Sunnyvale right well you know, I definitely worked at Sunnyvale right you've already you know figured that out. Why am I buying groceries and gas in Redwood City right well you probably guess I bet he lives near there right you know I have a payment to the Stanford gym. That probably lets you figure out that there's some connection between me and Stanford. You know, and then, you know, I'm going to a gastropub in Redwood City right and you know you see Ubers around there so you know, I probably, you know, did, you know. Have a cocktail right at the gastropub. So, you know, just from these few days in 2018 right you know you probably learned a pretty good about you know pretty good amount about me. And this might not totally denonymize me but you know if you had my transactions over the course of an entire month, you know, you could probably pinpoint me individually, right. So, it turns out that you know being anonymous really didn't buy me a lot in this situation. And, you know, this is even problematic in the permissionless setting right, you know we have a lot of cryptocurrencies that you know incorporate privacy and anonymity, excuse me, anonymity techniques, but the guarantees are not always explicit. And, you know, there have been sort of attacks not really on the cryptography of these systems, but sort of the privacy guarantees that are present there. So, you know, another another sort of pitfall that people make is, you know, people say that you know, well, everything is encrypted or hashed right there's no data given in the clear right. This is a common paradigm is on blockchain. So, how many people have here have seen the movie Wall Street. You know, I don't know, you know, you all might be, you know, much younger and maybe you haven't seen this movie. I think it's a classic movie. For those of you that haven't seen the movie, you know, there's this famous scene between Bud Fox, played by Charlie Sheen and Gordon gecko about, you know, where where Bud Fox, you know, finds out where a plane is going and uses that to sort of infer what business deal is being made. Right. So, you know, Bud Fox and Gordon gecko. In this case, figure out that you know this executive Lawrence is flying to area Pennsylvania. They know he talked to accountants, and then they determined that he's buying this particular steel company right. And this is what's called sort of, you know, side channel information and this kind of information is available everywhere on blockchains right even if you don't see what's inside a transaction. The existence of a transaction might be enough for someone to figure out a lot of information or break your privacy and confidentiality in some sort of unpredictable way. So, you know, as an example of this right, even if we have sort of, you know, fully zero knowledge transactions. The fact that transactions exist in certain patterns could break privacy or confidentiality. So, here, you know, you can see. Well, I've made hypothetical complicated financial deals and sort of indicated them by flows right. So, even if I can't sort of see what's in the arrow, just sort of, you know, the weight and the timing and the type of flow transaction flows might let me figure out, you know, exactly which kind of complicated financial deals going on. And so, you know, this is another way in which obviously privacy could be violated. You know, finally, I want to say, you know, lots of people, lots of people, you know, take an approach where they just try to apply cryptography to a problem. And, you know, what cryptography you use is really not equal to what security you get right. So, when we think about privacy guarantees, right, we don't want to say like my users are anonymized, you know, we want something like, you know, it's hard to distinguish participants in a transaction from random right. You know, or for data security, we don't want to think about something like everything is encrypted or hashed. We want to think about something like, you know, it's hard to learn any information about, you know, any transaction on the blockchain. And so, if you're thinking about privacy, or really any secure system in general, I'd encourage you to start by writing down the security properties you need, and then pick the tools you need to achieve the desired security properties. You know, defining security is hard. It's, you know, really hard. And I encourage people to ask for help. And, you know, weaker guarantees are okay too. And here on the right, I always list this as, you know, something where, you know, someone wrote a paper or two people wrote an excellent paper on a situation where I defined a security property poorly. You know, it happens and it's, it's hard. So, I guess, should we pause? Okay, we don't have any questions it looks like. So if we define security, right. You know, the next step is, is we sort of need to build a system that meets the definitions of security right. And this is sort of, you know, build the system and prove that it meets security right and challenging, you know, security proofs are hard, but they're important to get right. You know, we have a lot of resources to help, and I would encourage you to, you know, look at our cryptography and join the hyperledger community. And so, you know, we've sort of seen, I guess I should pause here before I go into solutions. Does anyone have any questions at this point? Yeah, let's give everyone a second question into the chat please. Any questions about what we've said on privacy so far. Lorenzo asked everyone talks all day about Ethereum versus, I'm assuming Bitcoin, we're interested in enterprise tech for students is hyperledger the only private chain how does it compare to permission chains like Hedera and Ripple. So hyperledger is not a technically a private chain right hyperledger is a foundation. We have, you know, software for, you know, I'll call it four and a half. It's not a chain that you can run yourself at this point right. Fabric, Beisu, Iroha, Saltooth and I'll call Indy sort of a half since it's not a turn complete chain. Or it's not. Yes. So there are many different software platforms for private chains and there are even more private chains running, you know, there are many, many instances of hyperledger fabric for instance. And how does this compare to to chains like Hedera and Ripple. So I had a slide on this earlier. But Hedera and Ripple are public but permissioned. Right. So that means anyone can read to the chain, but a few entities control the, the consensus process. Now, most people run fabric in private permission chain in, you know, private permissioned mode, which, you know, it means that regular folks, you know, can't really can't read from the chain. I will also say, you know, Hedera and Ripple are, you know, actual chains. Where hyperledger just has software for chains, if that makes sense. So fabric is a software platform and people run many different fabric chains, where there is sort of one, you know, iconic Hedera chain. Did that answer your question Lorenzo. Yeah, if you think about hyperledger, we're part of the Linux Foundation, which also hosts Linux and Kubernetes and other amazing projects. Hyperledger hosts the software projects that make up fabric and sawtooth, etc, and those communities that contribute to them. Hyperledger doesn't run a network hyperledger doesn't have its own network. And because this is open source, anybody can take one of these projects for whatever use case they have and run with it, whether that's using fabric to track conflict diamonds or using a hyperledger indie for an identity use case. The Linux Foundation, the Hyperledger Foundation are here to support the communities that build these projects. I've got a question from Stan. How do you see this affecting something like Venmo's social payment feed? Very exposed payment data for the consumer the last time I looked. And what implications for fintech players or traditional ones deploying or offering this kind of privacy through these improved features. These are great questions. I love particularly the Venmo social payment feed, because I know someone who caught their boyfriend cheating on them because the woman they were they were cheating with met like made some some Venmo payments that had suggestive names. So I think that's like a really funny. Well, it's unfortunate for them, but but as an external participant, you know, it was a funny way to get caught. You know, there are huge implications for for fintech players. And, you know, we talked to a lot of fintech companies. And they're all very, very interested in this technology and many of them have large cryptographic research teams working on this like visa for instance has a huge cryptographic research team. You know, my sort of view on traditional finance companies is that, you know, in today's day and age, every finance company is going to have to have, you know, a big tech component and you know every traditional finance company is really going to have to become a fintech company in order to survive. And if you don't, if you're a finance company and you don't embrace technology like blockchain like machine learning, you know, you're just going to get out competed and you're not going to exist. So that's, that's my sort of view on this. Are there recent developments in fabric that could impact privacy. Yes, there's literally the slide I'm on right now I'm going to go over one of them briefly. Is there any blockchain platform that is not involved work with cryptocurrency, or any other token. Yes, hyperledger fabric. Absolutely. And all of our projects can be run in modes that do not require tokens, even basu which is an Ethereum execution client can be run in a way that doesn't require tokens. We got two more questions before we jump to the next session. Is hyperledger company planning to use AI to further protect data privacy. So, usually, AI is viewed as a threat to privacy rather than something that can help privacy. You know, AI researchers may may beg to differ, but usually it's a hindrance rather than a helper to privacy. And the last question before we jump private data through private channels will help privacy. Why will it impact performance. So great question, but you know, private channels and private data typically help performance, because it means that less data has to be sent and communicated and agreed on on the blockchain. So, yes, typically sending less data improves performance. Back to it. Awesome. Let's talk about fabric. By default, everyone can see all transactions on a ledger. This makes privacy hard. But we have several solutions on hyperledger aimed at preserving privacy properties. They typically lower performance. So, you know, sending less data as an exception, but, you know, one thing you can do is is only post. The hash is a sensitive data rather than the data itself. And this is sort of the core idea behind data collections and transactions. Right. So, you know, as you can sort of see in the diagram, you know, this unauthorized fabric peer sees no data in the clear, because it doesn't have access to this particular private state. Another thing I want to mention that it is coming along. We have some ZKP use. We don't have a ZKP library yet in hyperledger. And, you know, I hope a lot of you have heard of zero knowledge proofs. This, you know, we could, we could do a whole course on zero knowledge proofs and entire courses to exist. But also to just outline what is your knowledge proof is here. You know, so if we have some sort of statement where a prover knows an answer, and the answer can be verified mathematically, then we can construct, you know, a proof of knowledge. And the verifier can sort of check the proof without ever interacting with the prover. So, you know, I don't want to go too far into this because, you know, this is sort of a big rabbit hole. But I guess my slides got mangled a little bit here so I apologize for that. But, you know, you can sort of see the differences between private transactions. In this case, we're using snarks, which is just a succinct, essentially, zero knowledge proof. It just means it's small. So, this, again, is a whole course in and of itself, but it's important technology to sort of understand how it works. So I'm going to put in the chat a link to Stephen Coran who's one of our maintainers on a number of identity projects and hyperledger. He did a 40 minute session on understanding zero knowledge proofs with high school math, and I'm going to add that link in the chat it's a YouTube video somebody wants to watch it. Wonderful. So, you know, another thing I want to bring up today is something called the blockchain trilemma. This was sort of coined by Vitalik Buterin, and it refers to the fact that blockchains cannot achieve all of scalability security and decentralization at the same time, and sort of tradeoffs have to be considered. Right. So things like Bitcoin and Zcash, you know, skewed more towards security and decentralization rather than scalability, whereas something like AOS sort of concedes a little bit of decentralization for more scalability. What I do want to encourage people is to not compromise on security. I really wish this had been coined as a tradeoff between scalability and decentralization, rather than security, because you know you should not compromise on security. And sort of going back to this like decentralization continuum, right, you know, in general, we have sort of more decentralization implies slower performance, and I've put up sort of like very rough performance numbers here. But, you know, I want to emphasize that there are tradeoffs and distributed ledgers. The challenge when picking a distributed ledger is to pick where on the decentralization continuum, your application best fits. Don't use more decentralization than you actually need. And as I alluded to earlier, you know, there are sort of lots of tradeoffs and distributed ledgers right. So we have to optimize for a lot of different things. And, you know, we have to carefully choose how we build a blockchain to ensure the properties we need while still getting good performance, but the main tradeoff is decentralization and performance. And as I alluded to earlier in the talk, there are many different components of decentralized trust. And this was the question that someone asked earlier. So here's the slide. So here it is. There are many different components that you have to think about, you know, the code layer, the architectural layer, the consensus, the governance application layer, you know, sort of all of these have to be decentralized. If one is centralized, you know, then really the blockchain can be controlled by one party, at least in the worst case and is thus somewhat centralized. And you have to ask the question, why shouldn't the single party run the system in a centralized way. In some cases, there are good reasons, right? Like if there's a government agency that's responsible for governance, but they don't have the, you know, the manpower or the computational power to run the system, then it might still make sense to have a blockchain, but it's still worth considering. So yeah, that's all I have. And in about the 10 minutes we have left. I'd love to answer any remaining questions. Scander asked, is Hyperledger Fabric running on a single node? Wait, I'm sorry. Hyperledger Fabric running on a single node? Can Hyperledger Fabric running on a single node be called decentralized? No. And if you're running fabric on a single node, I would ask, why are you doing that? That would not be a good use of Hyperledger Fabric. You asked, do you see Hyperledger Solang dramatically changing the landscape in terms of adding Solana slash Polkadot to the ecosystem? Or do you think ETH EVM will always be the center in terms of Hyperledger's integration? Common consensus is that later too we'll solve the ETH scaling problems. That's a great question. I had the ability to confidently pick winners in the blockchain space. You know, I would be sitting off in my mega mansion somewhere with all the blockchain investment money I've made. So in practice, you know, we are seeing a lot of, I guess, convergence on the EVM, really the EVM more than ETH itself. And I think that's just because there are a lot of benefits to some sort of standardization across executions. You know, do I think that, you know, layer two will solve ETH scaling problems? You know, layer two will be useful. I think it depends on how broadly you define layer twos. I like to think of a layer two is like a much bigger abstraction, right, you know, is a private network that, you know, occasionally does, you know, cross chain transactions or atomic swaps with a layer one. You know, I sort of think so. And then, you know, then in this case, yeah, I think everything is going to be interconnected with everything else in the space, right? That's what we see today. You know, everyone has a database that has to, you know, coordinate and keep track with other databases. As we replace databases with blockchains, we shouldn't expect to see anything different. So, you know, I expect to see a large proliferation of systems that communicate with each other. And that's that's one way to think about layer twos. And Lorenzo made an observation EVM seems to be making a lot of headway with ARB OP. Yeah, it's broader than that too, right. I think you brought up Hedera earlier, and Hedera uses an EVM. So there are a lot of other systems that use EVMs as well. Sheeran asks, do we have examples of real world use cases in healthcare where data privacy concerns were successfully addressed using hyperledger fabric. How can we discuss HLF security and privacy features with a healthcare provider where all requires complicated terms. That's a great question. I don't know what the best case study we have in healthcare is. You know, maybe, Sean, do you know, do we have like, I'm going to go see while we're chatting. So while we're talking, I'm going to try to look it up. You know, healthcare is a great application. There are a number of different ways you can use blockchain to track and manage healthcare data. You know, I think there are some extremely exciting opportunities in this space as well. I think blockchain can be used as the backbone for federated machine learning in a healthcare application, which I think is also really exciting. So, you know, a big one that's, I guess, not explicitly healthcare, but very, very close is the OpenIDL network, which is for managing insurance data. And Sean can talk a lot more extensively about that than I can. I think a lot of the same concerns apply there. Yes. So in the case of OpenIDL, just to really quickly touch on it, it's an open insurance data link. It's a consortia of insurance companies and regulators working together to find ways to be more efficient and how they exchange and use data in the industry by a blockchain. I think we need to step back for a second on the topic of healthcare. We do have a healthcare SIG, a healthcare special interest group. You can find their conversations on our discord, which I've shared the link before. I'll share the link, I'll share the link again in a second, but the healthcare SIG is pretty active. One of the challenges that you have an open source is that no one needs to give permission to use this software. I will see if I can find while we're chatting here, a healthcare use case or case study, but the reality is there are lots of folks using fabric that we have no idea about. And we're always excited when we find out someone is using another one of the Hyperledger products, and we try to find out more about that. Getting back to the questions, someone mentioned Copperwire, we mentioned use cases. Yeah, so I've got the questions pulled up now. So how can we discuss security and privacy features with the healthcare provider? This is a hard thing to do, right? Talking to someone who probably is an expert about security, about security and privacy is hard. So, you know, this is a difficult thing. And, you know, we always try to bring a lot of these folks up to speed as best we can. So, you know, this is a hard problem. And, you know, this is a sort of big societal problem, I would say that lots of people don't understand, you know, about privacy and insecurity. So I unfortunately don't have a good answer for you there as a challenge. Are there scalability concepts like Cadenas Chainweb? So I'm not familiar with Cadenas Chainweb. So, you know, I'm not entirely sure what graph theoretic concepts they're using. So unfortunately, I can't really answer that question for you. Sreenivasan asked, can you give a brief idea of reference to use enterprise certificate authorities? Is there any connection to Fabric CA apart from CERT Gen? Can we just use our certs in the file share and not bring up Fabric CA containers? So, this is a specific fabric question. You know, there are going to be some tricky implementation details in doing this, and I would specifically ask in the Fabric Discord how to best do this. I know you can use alternatives to Fabric CA, but I haven't done this personally in a little bit, and I would encourage you to ask the Discord channel for more details on this. And I share the Discord link in the chat in a second. Yeah, if you really want to be fancy, you would use decentralized identifiers. But, you know, that's a whole other step. You know, and Sreen, yeah, I would, as Sean suggested, I would definitely suggest reaching out to our healthcare special interest group, because they have the experience in talking to all these people. Awesome. Scander asked, what do you think about Tezos achieving 1 million transactions per second? I mean, I don't know. You know, it sort of is what it is. You know, transactions per second are all about, you know, decentralization and the different kinds of transactions you're processing. Obviously, some transactions are much simpler to process than others. Sreen Abhasen says, we plan to store only data hash on the blockchain. Does this meet GDPR requirements as we don't send, I'm assuming you meant PII data? Sreen Abhasen, so yeah. So I'm not a lawyer, so please do not take my advice as legally binding, you know, about GDPR. My understanding, though, is if you hash data in a way that is information theoretically secure. So basically, if you take what you want to hash, you append, you know, 256 bits of randomness to it. And then hash it and store that on the blockchain that that would meet GDPR requirements as the hash is information theoretically hiding. It's perfectly hiding. Yeah, I mean, in the case of the Indian community in the early days, the concept was you don't put any personal data on chain. It's all pointers and proofs. The only joke I used to make is there may come a day in the future where it's illegal to be a New York Yankees fan and I don't want that on a mutable blockchain living forever. So, but that's a different part of the hyper ledger community. One of the people who asks our channels and PDC is the only option for data and transaction privacy how can we obtain private transactions on the same channel. So channels and PDCs are not the only options. They're one of the options sort of in the public repo but you know we see people use lots of different. Lots of different techniques for privacy. If you're just using the channel approach, then, you know, you can't obtain private transactions on the same channel because all transactions on a particular channel are visible to everyone on that channel. So you would need some other technique. If you wanted to obtain private transactions on the same channel. That's the top of the hour. Does anyone have another question for heart before we close this Morgan State seminar. All right, everybody, I am going to share one more time. The list of links here in chat. I would like to thank tenicia the Morgan State the fintech center Morgan State and heart for hosting us and putting on such a great event and we really appreciate all the knowledge you were sharing heart. And as live streamed on YouTube. This is going to be on the hyper ledger YouTube I'm also going to get a copy to the fintech center. In case they want to put it on one of their platforms. And the deck that heart shared along with the recording is on the hyper ledger wiki, which is listed above. And thank you again everybody for joining us. This was great. Can you see do you have anything to say before we go. Thank you again, it was a wonderful presentation. Have a great day everybody. Thank you all for your time.